#launchpad-dev 2010-01-18
<wgrant> al-maisan: Why do you need SPRBJ.gettitle now?
<wgrant> Ther's an implementation in the integration branch, IIRC.
<al-maisan> because the db-devel branch as it stands fails a test
<wgrant> Huh.
<al-maisan> Just doing a testfix
<wgrant> (wireless laaaaaaaaaag)
<al-maisan> the failing test is test_makeJob
<al-maisan> SourcePackageRecipeBuildJob does not implement getTitle()
<wgrant> Ahh.
<wgrant> We need to get the other couple of unreviewed integration pieces landed.
<wgrant> But Internet here sort of sucks.
 * al-maisan could not agree more
<jml> jelmer, al-maisan: my conference bag is in the hotel lobby
<jml> al-maisan, jelmer: are either of you there?
<thumper> oops
<thumper> I'm not there
<jml> ...
<jml> thumper, hmm.
<jml> maybe I can go there & return before mwh gets to the talk.
<thumper> jml: do you remember monty's nick?
<jml> problem solved
<jtv> al-maisan, that branch I promised to refer you to: lp:~jtv/launchpad/bug-499405-translationtemplates-buildmanager
<al-maisan> jtv: thanks, will take a look.
<mrevell> hi
<thumper> hey
<beuno> hello
<vila> hey guys, is loggerhead down or is it just me ?
<vila> see http://bazaar.launchpad.net/~spiv/bzr/per-file-merge-hook-491711/revision/4905
<beuno> vila, seems its down, a user just reported ut
<beuno> in #launchpad
<vila> rhaa, one more channel to track :-}
<vila> beuno: thks, will wait
<deryck> Morning, all.
<magcius> Woah, found this: http://bitbucket.org/RonnyPfannschmidt/anyvc/
<magcius> It's another Leaky AbstractionÂ®, but whatever.
<kfogel> gmb or anyone: 'make build' failing in a recently-updated branch of db-devel for us -- see http://paste.ubuntu.com/358557/.  Any ideas?  "ImportError: No module named builder.recipe"
<kfogel> maxb: random build issue, you might have seen before?  'make build' failing in a recently-updated branch of db-devel for us -- see http://paste.ubuntu.com/358557/.  Any ideas?  "ImportError: No module named builder.recipe"
 * kfogel some how associates "maxb" with "understands all sorts of config & build problems"
<gmb> intellectronica, bdmurray: Here's the top 100 hot bugs that the abortive staging run produced: https://pastebin.canonical.com/26558/
<maxb> kfogel: hah :-)   /me is grinning.  Not seen that one though
<kfogel> maxb: we never did figure it out -- we just routed around :-).  Sigh.
<maxb> my vague thought is: relative import which shouldn't be?
<kfogel> jml: https://code.edge.launchpad.net/~kfogel/launchpad/509194-506514-bug-heat-db-fixes/+merge/17597   easy review, if you feel like, you know, a break from whatever you're doing :-)
<intellectronica> looks like there's a new dependency in db-devel, on the bzr builder plugin. because of that you can no longer build a fresh branch from db-devel. anyone knows anything about this?
<intellectronica> this is probably related to the recent build-from-branch work, b.t.w
<bdmurray> make schema is failing for me due to sourcecode/mailman should that be there?
<bdmurray> I think I found it
<allenap> gmb: https://code.edge.launchpad.net/~allenap/launchpad/stop-checkwatches-hammering-products-bug-506158/+merge/17601
<allenap> gmb: https://code.edge.launchpad.net/~allenap/launchpad/stop-checkwatches-hammering-products-bug-506158/+merge/17602
<thumper> intellectronica: update your sourcecode dir and download cache
 * thumper waves at the devs
<bigjools> hello thumper
<thumper> bigjools: hey
<thumper> bigjools: it will be 22 degrees C here today and sunny :)
<bigjools> bastards
<thumper> now the conf has tarted
<thumper> started that is
<bigjools> thumper: I am not sure how you keep doing 30+ hour flights and remain sane
<thumper> bigjools: you assume I'm still sane
<bigjools> it's all relative
<thumper> :)
<goundy> Hi guys
<goundy> Something new about wiki support in LP guys ?
<jamalta> Hi, what's the proper way to reload the server so browser code gets re-executed?
<jamalta> Is closing and re-running make run the only way?
<thumper> jamalta: I think so
<thumper> it is what I do
<jamalta> thumper: alright thanks.. annoying but at least it works
<thumper> yeah
<thumper> could be worse
<jamalta> heh yeah
<jamalta> thanks for the input
<wgrant> bigjools: Hm, publisher is broken? Did we delete something that we shouldn't have?
<bigjools> wgrant: tell you in a sec
<bigjools> fixing it
<bigjools> wgrant: someone managed to copy from a private to a non-private PPA
<bigjools> and p-a thought it was a delayed copy
<wgrant> bigjools: Ah, good. So it's not something terrible.
<bigjools> I'm guessing the API was used since he couldn't see it in the ui
<wgrant> So the PPA was actually still private?
<bigjools> in what terms?
<bigjools> the target ppa was not private and it had a packageupload with no signing key
<jamalta> is there a list of user logins for dev?
<jamalta> can't find it in the wiki
<wgrant> Hm, private source builds are sadly broken in trunk.
<wgrant> I wonder why there are no tests for that.
<allenap> rockstar: Hello, are you versed in the ways of the IJob?
<rockstar> allenap, I believe I can be classified as "brown belt"
<allenap> rockstar: I wondered why the job.reason column is unused?
<allenap> rockstar: gmb and I are wondering if we can bend it to our will.
<rockstar> allenap, so I don't know the reason (no pun intended)
<wgrant> jml: Why was _sendFileToSlave moved from Builder to BuilderSlave?
<allenap> rockstar: :) Do you think abentley will know? I'd like to check before I either use it or create a new table.
<bigjools> wgrant: I feared that a lot of stuff would be broken after last week
<bigjools> what's bust?
<rockstar> allenap, abentley is the architect of the job stuff, and I remember him telling me the purpose, but I don't remember the specifics.
<allenap> rockstar: Okay, I'll email him about it. Thank you for your help :)
<mwhudson> allenap: is there anything in commets.sql about it?
<allenap> mwhudson: Tip top idea. "The reason the job was created, if applicable" (thanks to gmb).
<maxb> <bigjools> the target ppa was not private and it had a packageupload with no signing key
<maxb> Isn't that what happens if you copy a synced-from-Debian upload from the ubuntu primary archive to a public PPA? And that works fine.
<bigjools> maxb: well in this case the problem is that in combination with the private archive it came from, it triggered the bug
<maxb> ok - just saying that public->public with no signing key works just fine
<bigjools> ok thanks
<jml> wgrant, because AIUI, BuilderSlave is the LP-side representation of the slave
<jamalta> Well, since I haven't received a reply I'm assuming it doesn't exist..
<jml> wgrant, sendFile seems like a meaningful operation on that object
<jamalta> mind if I make a page on dev.launchpad.net that lists login for dev accounts?
<jml> jamalta, sounds like a good idea to me
<wgrant> jml: Somwhat, but it's marked private, accessed from other places, and there is another implementation of that interface.
<jml> wgrant, it was already accessed from places other than Builder
<wgrant> I think there's a README somewhere in the tree that lists dev redentials.
<jml> wgrant, multiple implementations of the BuilderSlave interface?
<wgrant> lib/canonical/launchpad/pagetests/README.txt
<wgrant> jml: Yes. There's RecordingSlave, which is actually used by builddmanager.
<jamalta> wgrant: ah ok
<jml> wgrant, then it seems to me that the interface needs to be tweaked a bit
<jamalta> wgrant: is it ok if i post that ont he wiki? i guess that's where i should have looked, but it will make it easier for people not to come here asking like idiots (aka, me ;)
<wgrant> jamalta: I dont like duplicatng information. Perhaps reference the file alongside the existing provided credentials on the wiki.
<wgrant> jml: Probably.
<wgrant> A lot of interfaces need tweaking :(
<jamalta> wgrant: understood
<gmb> jml: Could you take a squizz at https://code.edge.launchpad.net/~gmb/launchpad/add-bugheatjob-table/+merge/17620 when you have  a second please? It's a branch to add a BugHeatJob table to the DB.
<jamalta> should i still make a table of the current users and reference the file as well?
<jml> gmb, the diff is empty
<wgrant> jamalta: I think just reference the file.
<jamalta> wgrant: ok
<gmb> jml: That's because I'm an idiot.
<gmb> jml: I've re-pushed with the change actually committed... don't know when the diff will update.
<jml> gmb, "soon"
<jml> gmb, thanks.
<gmb> Kewl
<jamalta> wgrant: thanks
<jml> gmb, got it
<jml> gmb, the approach that the branch jobs take is to have one table for BranchJobs and have an enum type & json metadata
<jml> gmb, rather than a new table per type of job
<jml> gmb, what do you think about renaming the table to BugJob?
<gmb> jml: wfm, sure.
<gmb> jml: Thus: https://pastebin.canonical.com/26732/
<gmb> ?
<jamalta> running a test, i got a "2 import policy violations" notice.. but this isn't from anything i changed. Is it safe to ignore this, or could it be something I broke?
<jamalta> the test in question is lib/lp/soyuz/stories/ppa/xx-copy-packages.txt
<gmb> jml: Fixed in the branch and pushed.
<maxb> https://edge.launchpad.net/~launchpad/+archive/ppa/+build/1452706 https://edge.launchpad.net/~launchpad/+archive/ppa/+build/1452707 ... Could a Canonical person hit the retry button on those? Unfortunately my "uploader" access apparently doesn't imply "retry" access :-/
<bigjools> maxb: done
<maxb> thanks
<bigjools> fwiw there's a bug open about that
<bigjools> right, bed time, g'night
<gmb> jml: I've assigned the review to you for posterity, FWIW.
<maxb> Another interesting edge case is that uploader doesn't implied "can delete" - though that one's more up for debate
<kfogel> jml: (we redid this trivial db patch to be from db-devel instead of devel; this supersedes the earlier merge proposal which you were asleep during anyway :-) ):
<kfogel> https://code.edge.launchpad.net/~kfogel/launchpad/509194-506514-bug-heat-db-fixes/+merge/17625
<wgrant> We beokr more than I thought :(
<wgrant> (that was 'broke' with about 20s lag)
<EdwinGrubbs> salgado-afk: ping
<jml> hello? what?
<jml> kfogel, gmb: which reviews do I need to look at?
<kfogel> jml: one sec
<kfogel> https://code.edge.launchpad.net/~kfogel/launchpad/509194-506514-bug-heat-db-fixes/+merge/17625
<kfogel> jml: there you go
<kfogel> jml:  there will be another Really Easy one in about five minutes
<jml> I've just done my LCA talk
<gmb> jml: The one you were looking at before: https://code.edge.launchpad.net/~gmb/launchpad/add-bugheatjob-table/+merge/17620
<gmb> If you pleases.
<jml> kfogel, Gabriella Coleman's talk was great. thanks for the recommendation.
<wgrant> It was really good, yeah.
<jml> BjornT is doing his talk right now.
<kfogel> jml: glad you liked it!  I'll tell her she pleased at least one person :-).
<jml> BjornT, sorry for reviewing db patches while you are talking -- these guys are sprinting
<kfogel> wgrant: make that two people
<kfogel> wgrant: she has such a different perspective from the coders, it's really enlightening
<kfogel> heh
<wgrant> Yup.
<jml> gmb, approved. You need an approval from stub.
<jml> die sample date die die
<jml> data.
<gmb> jml: Thankee.
<jml> kfogel, "The heat bin in which this bugtask appears" -- that doesn't seem correct any more, given the current design
<jml> kfogel, it's more like a score than a bin, right?
<jml> hmm. maybe I misunderstand.
<kfogel> jml: interesting point.  let me ask others here, who know more about the bin terminology
<kfogel> jml: I think it's still correct -- that is, it seems there's this other thing going on whereby heat scores may be grouped into various bins, and that's what this is about.  That may be obsolete now (gmb says, as allenap looks slightly sick next to him), but in any case their possible obsolescence is not related to this patch.
<jml> kfogel, ok.
<jml> kfogel, approved.
<jml> kfogel, gmb: stub's pretty prompt w/ db reviews, but I'll poke him later today to have a look at these.
<gmb> jml: Thanks
<kfogel> jml: thanks.  We'll send the next one to stub (btw, I'm working with adeuring not gmb -- dunno this gmb guy, never heard of him; his name is suspiciously short).
<jml> kfogel, there are two db patches
<jml> kfogel, he has a middle name, that makes him extra trustworthy in alabama
<kfogel> jml: we're about to submit the next one, actually
<jml> kfogel, although judging by his accent, I suspect he's from north of the Mason-Dixon line.
<kfogel> jml: gmb said the "Welcome to Alabama" sign on the highway coming in from Atlanta airport (in Georgia, the next state over) had bullet holes in it.  Yee-haw!
<kfogel> jml: https://code.edge.launchpad.net/~kfogel/launchpad/505845-affects-me-too-from-dups/+merge/17633
<jml> kfogel, looking
<kfogel> jml: thanks
<kfogel> jml: afk for a bit, will be back to answer questions after
<Ursinha> ae
<jml> ei
<Ursinha> this rain won't let me down!!
<jml> down from where?
<jml> kfogel, reviewed. happy to talk further.
<kfogel> jml: we're reading now
<jml> kfogel, \o/
<maxb> I've just been trying to update-sourcecode, and I've noticed a couple of things:
<maxb> (1) it breaks if you have bzr-git installed
<maxb> (2) to make it work on lucid we'll need to have bzr in the launchpad PPA _or_ make it run with python 2.6
<jml> maxb, that first one surprises me.
<maxb> jml: It's because bzr sees the test git repositories within dulwich as branches, and update-sourcecode tries to delete them as obsolete :-)
<mwhudson> aaraaarsadhjk
<mwhudson> let's not use find_branches
<jml> maxb, look, you broke mwhudson
<jml> maxb, I hope your sorry.
<jml> you're. dammit.
<Ursinha> jml: it's raining like it's the end of the world here
<maxb> Yeah, bzr-<other-vcs> is cool, but I wish it could read your mind to figure out when to run :-)
<jml> Ursinha, :(
<maxb> You can imagine the interesting edge cases I run into with bzr-svn installed, where my homedir is a svn wc.....
<maxb> So.... soliciting thoughts on which is the lesser evil? Add bzr to the set of things we have to rebuild to work with the Launchpad blessed Python version, or run devscripts stuff under a possibly different python to launchpad?
<elmo> *blink* devscripts has python things in it?
<mwhudson> maxb: why does bzr need to be rebuilt?
<maxb> Because update-sourcecode imports bzrlib
<elmo> maxb: I don't see any python in devscripts?
<maxb> I mean lib/lp/devscripts/
<mwhudson> maxb: i think update-sourcecode being run with the system /usr/bin/python
<mwhudson> would be fine
<maxb> uh, lib/devscripts/
<mwhudson> possibly not the best choice of package name i guess
<maxb> Oh, this is going to be pulling on a thread which unravels ridiculously, isn't it :-/
<jml> if only we had a vcs that supports renaming
<wgrant> Wasn't devscripts stuff running on 2.5 long before LP was ported?
<jml> maxb, everything on LP worth doing is like that. stick with it.
<wgrant> So it shouldn't be too hard.
<elmo> jml: are you crazy?  eventually the whole cloth will come apart if you do that!
<maxb> I'm just worrying about any deps wanted from eggs for devsscripts
<wgrant> (disclaimer: Launchpad difficulty ratings may differ wildly from generally accepted standards.)
<jml> elmo, but think of the long, useful (dare I say light-weight & flexible) yarn
<maxb> mm.... do nothing in devscripts looks to be using any launchpad custom code, but some of the launcher scripts in utilities do use it after an "import _pythonpath"
<kfogel> jml: responded in merge proposal.  we're about to enter sprint wrapup, so I may not be able to respond till later
<maxb> But update-sourcecode can't do that because it is run from rocketfuel-get, which is run from rocketfuel-setup
<jml> hi ho
<jml> I'm back
<jml> kfogel, I'll take a look.
#launchpad-dev 2010-01-19
<bdmurray> allenap: we said 7:30 yes?
<allenap> bdmurray: Yep.
 * jml is back
<bdmurray> Is anyone running launchpad on lucid?
<bdmurray> I'm having an issue with make schema and tickcount not importing
<jml> bdmurray, maxb is, I think
<jml> I guess I ought to upgrade.
<jml> bdmurray, wgrant might be running on lucid too
<wgrant> I'm running lucid.
<wgrant> bdmurray: Make sure that you have the ~launchpad PPA for lucid activated.
<wgrant> That should work, although you might need to downgrade python-pkg-resources and python-setuptools to their karmic versions (if you get errors about 'distribute')
<bdmurray> wgrant I do have the launchpad ppa
<wgrant> bdmurray: Which version of python-tickcount do you have installed?
<bdmurray> 0.1-0ubuntu10launchpad1
<wgrant> Hmmm.
<bdmurray> I think it has to do with the python path
<wgrant> It's more likely that your python-support hates 2.5.
<bdmurray> and tickcount being in /usr/lib/pyshared?
 * wgrant checks stuff.
<wgrant> bdmurray: What if you remove and reinstall python-tickcount?
<wgrant> python-support should be happy :(
<bdmurray> wgrant: I tried downgrading to the one in universe and installing the ppa one would that count?
<wgrant> bdmurray: Probably, but maybe not.
<wgrant> bdmurray: Which versions of python-defaults and python-support do you have?
<maxb> Hmm, that reminds me, I should merge my python-defaults change forward to lucid
<maxb> Need to reboot into lucid to test that properly, though :-/
<bdmurray> wgrant: I've got to run but that didn't sort it either
<bdmurray> wgrant: thanks though
<stub> 11 hours is a little long for a test run....
 * stub wonders wtf his ec2 instance has been doing all night.
<jml> stub, wrt kfogel's master_affects patch, I think they were also going to use it to correctly calculate the number of users affected by a bug
<jml> stub, which isn't an offline task
<stub> It still isn't necessarily a performance issue
<stub> It is a use case for PG 8.4's hierarchical queries though...
<stub> w00t. My ec2 instance looks crashed. ssh and http unresponsive, but still listed as running in elasticfox.
<stub> jml: There is already the Bug.users_affected and Bug.users_unaffected cache columns, so affected counts don't need to be calculated on the fly.
<maxb> Can someone hit retry on this for me, please? https://edge.launchpad.net/~launchpad/+archive/ppa/+build/1453105
<spm> maxb: done
<wgrant> I have a small branch from last week that makes some tests fail (inheriting from a new interface for security reasons, while the class still doesn't implement some of the attributes). Can I get that reviewed on its own now, and just land the subsequent branch which unbreaks things? Together they exceed the limit, and will be somewhat more difficult to review.
<stub> wgrant: I think two separate merge proposals is encouraged, and the 'dependent branch' field when registering a merge proposal added to make things even easier.
<wgrant> stub: Yep, I made a lot of use of that field last week...
<wgrant> Thanks.
<bdmurray> wgrant: so a new python-support fixed it
<wgrant> bdmurray: Great.
<stub> Bah. Too many devs infecting my timezone. PQM is backed up :-P
<stub> GET OFF MY LAWN!
<al-maisan> :)
<stub>     ImportError: No module named builder.recipe
 * stub kicks db-devel, and wadl generation in general
<mrevell> Morning
<stub> Anyone else seen that? db-devel won't build locally for me.
<bigjools> I'll try
<bigjools> wgrant: around?
<bigjools> stub: fails for me too
<stub> bigjools: No idea why it is working for buildbot.
<bigjools> me neither
<bigjools> stub: starting up dogfood gives me "database does not have a main_slave key."
<bigjools> que?
<bigjools> and "main_master"
<stub> bigjools: Sounds like you need to update the config file, but I'm not sure how you would get that particular error - if those keys are not set, you should be pulling in the defaults from lib/canonical/config/schema-lazr.conf (which would attempt to connect you to the production database, and fail)
<bigjools> so I guess someone added config items and forgot about DF
<bigjools> I have a bad feeling about this week
<stub> This is old though...
<bigjools> really?
<stub> Yer - since we have had replication. Months and months.
<bigjools> it only started happening after I just pulled db-devel into DF
<bigjools> I last did that last Friday
<bigjools> or maybe Thu
<stub> since it because a pain in the bum to restore the db dumps in fact, so I know those keys have been needed on df before.
<stub> Hmmm...
<stub> The losas might remember the magic command to dump the full config with all the inheritance exploded. That might show the issue?
<bigjools> lsconfig iirc
<mthaddon> ./utilities/lsconf.py
<stub> Do you have a traceback and can confirm which widget it spitting out the error?
<bigjools> awesome.  lsconf falls over with the same error
<bigjools> http://pastebin.ubuntu.com/358941/
<mthaddon> I wonder if this is related to the work on rw_ and ro_ prefixes for those values
 * bigjools updates configs and tries again
<mthaddon> dunno what's landed yet
<mthaddon> yep, looks like it's landed
<stub> mthaddon: Perhaps. That landed...
<bigjools> well, this is a rollout blocker, I can't test any of last week's extremely invasive changes :/
<mthaddon> bigjools: I'm about to submit a branch that should fix lp-production-configs
<mthaddon> https://code.edge.launchpad.net/~mthaddon/lp-production-configs/read-only-text-file/+merge/17581
<bigjools> mthaddon: oh, you know the problem already?
<mthaddon> yeah
<bigjools> mthaddon: excellent
 * bigjools hacks the diff locally
<stub> I'm off to pay my health insurance then
<bigjools> required for working on LP? :)
<mthaddon> bigjools: you can see what changes are needed?
<bigjools> mthaddon: yes, I've changed the DF config on DF itself and it seems to be getting further now
<mthaddon> cool
<stub> :-) Or maybe tomorrow since they close in 10 mins
<bigjools> when it finishes generating the ****ing wadl I'll find out
<mthaddon> welcome to my world
<bigjools> :)
<bigjools> I also want to scream every time I see combine-css running
<bigjools> even when doing "make stop"
<bigjools> it really needs a Makefile predicate
<mthaddon> try make initscript-stop instead
<bigjools> argh
<bigjools> thanks
<bigjools> stub: db-devel is fine on dogfood, which adds to the confusion
<stub> I'm suspecting a missing launchpad-dependency that happens to be installed on the production boxes.
<stub> But haven't looked closely.
<bigjools> stub: the only one I remember us adding was python-debian
<bigjools> bzr-builder was added to sourcedeps
<henninge> stub: something LP-related ;)
<henninge> stub: what is the best approach to updating many rows with different values each?
<henninge> stub: LIke, I have a list of select criterias that select an entry each and I want to set a value in each entry.
<henninge> a different value for each entry.
<henninge> My naiv approach would be an update request per row. Is there a better solution?
<stub> UPDATE foo SET bar=sub.baz FROM (SELECT foo_id, bong FROM baz WHERE ....) AS baz WHERE foo.id = baz.foo_id;
<stub> I could make a more comprehensible example with more explicit information
<henninge> stub: sorry ;)
<henninge> stub: I want to set priority on potemplate and have this list: http://people.canonical.com/~dpm/template-priorities/karmic-templates-priorities.csv.txt
<stub> As the source isn't in PG, better to just do one query per entry
<henninge> stub: ok, I can write a script for that.
<stub> You *could* load all the data into a temporary table and use that in the FROM clause of the UPDATE statement, but there isn't that much data...
<henninge> 1298 lines ...
 * stub shrugs
 * henninge expected that
<stub> pfft. You have other scripts trashing *millions* of rows.
<henninge> I know, I know.
<bigjools> stub: utilities/update-sourcecode does the trick in db-devel
<stub> So rocketfuel-get is busticated?
<bigjools> rf-get doesn't touch db-devel does it?
<bigjools> only trunk
<stub> Hmm... so sourcedeps.conf has been modified on db-devel and not devel? That is going to mess staging and production.
<stub> Or is is just that devel changes haven't leaked through to db-devel yet?
<bigjools> I think update-sourcecode doesn't get run on db-devel automatically, that's all
<bigjools> hmmm actually
<stub> ok
<bigjools> you're right
<bigjools> devel doesn't have the updated sourcedeps
<stub> yer - I only have one sourcedeps. Everything else is symlinked.
<henninge> stub: can you tell me the id for karmic?
<henninge> stub: like "select id from distroseries where name = 'karmic'" ?
<stub> (SELECT id FROM distroseries WHERE name='karmic') is better than hardcoding the id :)
<stub> But it is 97 if this is a one of script to only run against staging and production
<henninge> stub: yes, just once.
<henninge> thanks.
<henninge> stub: does that look ok? http://paste.ubuntu.com/358965/
<henninge> stub: or more like this http://paste.ubuntu.com/358966/
<stub> yer
<stub> UPDATE potemplate
<stub> SET priority=100
<stub> FROM sourcepackagename, distroseries
<stub> WHERE
<stub>     potemplate.sourcepackagename = sourcepackagename.id
<stub>     AND sourcepackagename.name = 'moin'
<stub>     AND potemplate.name = 'moinmoin'
<stub>     AND potemplate.distroseries = distroseries.id
<stub>     AND distroseries.name = 'karmic';
<henninge> ah!
<henninge> thanks!
<henninge> stub: This assumes that no other distribution in the db will have a 'karmic' series. I'll add the distribution.
<stub> henninge: Correct. Overkill at the moment, but correct :)
<henninge> danilos: are you alive here? ;-)
<bac> barry: ping
<barry> bac: pong
<bac> barry: hi.  i was trying to use your stop() debugging tip but need to do so in a browser/test not a pagetest.  it's not in the doctest globs but i redefined it.  i find that *some* of the setup data is available when i hit launchpad.dev but not all -- mainly the stuff i want.  any ideas?  any reason it wouldn't work in that test env?
<barry> bac: hmm.  the only thing i can think of is that the non-page tests don't always commit the transaction, whereas each request in the page test should commit the transaction.  try sprinkling "transaction.commit()" calls in the non-page tests and see if that helps
<bac> barry: ah, good idea.  i tried flushing the db but didn't commit.  duh.
<bac> barry: cool, that was it
<barry> \o/
<barry> bac: wow, and i haven't even had my coffee yet this morning :)
<bac> barry: but i have.  :(  well, tea.
<barry> yeah, tea for me too :)
<bac> barry: any reason stop() can't be made available in systemdocs globs?
<barry> bac: nope.  in fact it should
<kfogel> gmb: https://code.edge.launchpad.net/~kfogel/launchpad/505845-affects-me-too-from-dups/+merge/17633
<gary_poster> mars or BjornT, did you have any thoughts on thumper's question to the list about the buildbot Windmill test failures in lp:~thumper/launchpad/js-play?  (subject of email is "OK, I'm stumped")
<leonardr> flacoste, do you have a minute to talk about multi-version?
<flacoste> leonardr: i do
<flacoste> gary_poster: BjornTwill be sleeping
<leonardr> flacoste: i've run into a problem which i can push off for a little while but not indefinitely. let me paste you a diff
<gary_poster> flacoste: ack, thanks.
<leonardr> flacoste: http://pastebin.ubuntu.com/359066/
<leonardr> the problem is that the IWebServiceConfiguration utility is not available until after the web service has been built and the code has run
<leonardr> but that utility is what defines the versions in use
<leonardr> first, do you see what i want to do? do you have questions about that specific code?
<mars> gary_poster, I haven't looked at that branch specifically
<gary_poster> mars, fair enough.  Do you have any next-step analysis steps to suggest to thumper?
<mars> gary_poster, alas, no.  But I can try the branch locally while I work on it.
<mars> work on other things
<mars> oh, wait
<gary_poster> mars: ok thank you.  ok, waiting. :-)
<mars> ah.  gary_poster, I will try that later, when I have my laptop... oh, wait.
<gary_poster> lol, being asked to wait a lot ;-)
<mars> so, my new desktop hard drive doesn't have lp-dev on it.  My laptop, which runs Jaunty, has a broken lp-dev on it.
<adiroiban> danilos: hi.
<adiroiban> danilos, henninge : one more question regarding. +edit page for potemplate. When changind domain name, the date_last_updated is also changed
<adiroiban> should I make it available for edit in +edit?
<EdwinGrubbs> barry: ping
<barry> EdwinGrubbs: pong
<mars> gary_poster, I'll see what I can do when I finish more of the pyslow reporting.  I don't want to switch to a system reinstall right now.
<henninge> adiroiban: no, I think not. It should be updated automatically when the data changes, like it does now (I presume).
<adiroiban> well... not it is not updated on edit
<gary_poster> mars, agree.  Could you reply to thumper with a "I acknowledge your pain" message then, and say that you'll look into it if someone else doesn't beat you to it once you are able to sort out your LP issues?  Maybe that will ping BjÃ¶rn to help if he can.
<adiroiban> henninge: changing the description of a potemplate... will not touch the last_update_date
<henninge> adiroiban: hm, it should definitely not be edited manually.
<adiroiban> but changing the domain_name will do
<henninge> adiroiban: I see.
<henninge> Don't know if that is a bug or if it's intentional.
<adiroiban> so I should remove security proxy
<adiroiban> ?
<adiroiban> just for the edit page?
<adiroiban> and for that field?
<adiroiban> not sure how this can be solved
<adiroiban> s/be/should/
<henninge> adiroiban: how does the field get updated at the moment?
<adiroiban> henninge: at the moment there is no translation domain in +edit page :)
<adiroiban> my branch will add the field
<flacoste> leonardr: why do you need to push the earliest_version?
<leonardr> flacoste: i have to push something so that the very first annotations will have a name. it doesn't have to be earliest_version
<flacoste> leonardr: you could simply use a marker 'THIS_IS_THE_EARLIEST_VERSION'
<leonardr> right, that's what i'm doing for now
<henninge> adeuring: so when you said "When changind domain name, the date_last_updated is also changed" earlier, what were you referring to?
<leonardr> but soon i'm going to have to handle @webservice_version('1.0')
<flacoste> leonardr: and then replace that marker with the correct name (if needed) in the generate_pass
<leonardr> flacoste: ok, that's what i was looking for, i think
<flacoste> generate_pass: actually, that might be a proble
<flacoste> m
<leonardr> when generate_* runs, the utility will be available?
<flacoste> no
<flacoste> well
<flacoste> maybe
<flacoste> but there is no garantee
<flacoste> that code will need to run when the utility is registered
<flacoste> we could add an event for that
<flacoste> but you might want to see if you can get away with simply using a marker
<flacoste> maybe you don't need to replace it
<flacoste> with the proper name
<flacoste> you could do it the other way round
<henninge> adiroiban: so when you said "When changind domain name, the date_last_updated is also changed" earlier, what were you referring to?
<flacoste> leonardr: replace 'whatever_the_earliest_version_is' with THIS_IS_THE_EARLIEST_VERSION_MARKER when doing lookup
<flacoste> leonardr: see how this evolves
<flacoste> gary_poster: might have other clever suggestions
<leonardr> flacoste: i can get away with not mentioning what specifically the earliest version is. i'm concerned about specific versions named in the annotations
 * gary_poster looks around in attempt to find something to be clever about
<adiroiban> henninge: updating translation_domain from the +edit page, will automaticaly change date_last_updated
<leonardr> at some time before i create and register the web service adapter classes, i'll need to check whether or not '1.0' is a valid version number
<henninge> adiroiban: right and where does that happen?
<adiroiban> henninge: right now, there is only 'description' field, and changing it from +edit will not change date_last_updated
<adiroiban> henninge: this happens on my new branch for bug 340662
<mup> Bug #340662: "Change details" for POTemplate should allow maintainers some more freedom <qa-bad> <ui> <Launchpad Translations:Fix Committed by adiroiban> <https://launchpad.net/bugs/340662>
<adiroiban> henninge: this is the MP https://code.edge.launchpad.net/~adiroiban/launchpad/bug-340662-take-2/+merge/17598
<leonardr> gary: i can walk you through it if that'll get you up to speed faster
<danilos> adiroiban, henninge: we should probably not change last_updated_date on translation domain change
<adiroiban> henninge: or maybe we should change to code so that changing translation_domain will not change date_last_updated
<kfogel> flacoste: https://pqm.launchpad.net/ seems crashed, just fyi
<flacoste> kfogel: nah, that's just the web interface
<danilos> adiroiban, henninge: however, this is likely needed for langpack updates, so...
<danilos> adiroiban, henninge: I'd just keep it in
<kfogel> flacoste: that's what I was referring to, sorry if not clear
<kfogel> not "PQM" but "pqm.launchpad.net"
<adiroiban> danilos: langpack updates are using Launchpad.Edit ?
<flacoste> kfogel: it will clear itself out at some point
<gary_poster> leonardr, so, you are doing something (setting up the BleedThroughDict with version information) during zcml processing that wants the zcml to already be processed?  A standard-ish way to handle something like this is to (1) leverage the two-stage zcml processing and/or (2) make a requirement that a certain utility is registered in zcml before other things are called.
<kfogel> flacoste: ah, ok
<danilos> adiroiban, henninge: one would have to check language pack delta generation code to see if it's using potemplate.last_update_date
<flacoste> kfogel: it's usually because of a specific job which chokes the web ui
<leonardr> gary: how would i do the latter?
<danilos> adiroiban, ha, no, but "incremental updates" are using dates of export to figure out what needs exporting
<kfogel> flacoste: that's... interesting :-).  But real-time PQM reporting is not a vital service, I guess.
<flacoste> leonardr: well, you don't really need to care about the specific version either, unless for validation purpose
<flacoste> leonardr: and that you can do later also
<gary_poster> leonardr: simply fall over if it is not registered when you need it to be with a hopefully helpful error message.
<danilos> adiroiban, if we don't update the date here, it might break and you won't be able to fix wrong translation domains in ubuntu without getting a full language pack export
<adiroiban> danilos: ah. I see :)
<danilos> anyway, off now
<gary_poster> leonardr: in stage one of zcml processing, collect information
<danilos> adiroiban, fwiw, that's just my guess, it would have to be confirmed through code
<flacoste> gary_poster: the code that he's showing happens before ZCML
<gary_poster> leonardr: in stage two of zcml processing, require that the desired utility is already registered
<flacoste> gary_poster: this is interface declaration code
<flacoste> gary_poster: happens whenever the module is imported
<flacoste> so he can't rely on any ZCML being registered at this point
<gary_poster> flacoste, can he do the actual registrations in stage two of ZCML processing?
<adiroiban> danilos, henninge: well, when changing translation_domain, I think we should update the last_update_date
<flacoste> gary_poster: there is no registration happening either, in that stage you should only collect the annotations
<flacoste> gary_poster: registration happens when the special ZCML directive is called
<adiroiban> even if langpack delta is not using the fields... maybe in the future we will need this
<leonardr> flacoste: ok, you're saying that at some point i can just fall over and say 'you defined a really big web service with no problems, but its versions don't match up with the versions in the config utility, so aaaargh"
<gary_poster> flacoste: oh ok.  So, can't we just demand that the desired utility be registered when the special ZCML directive is called, in stage 2, and do validation then?
<flacoste> gary_poster: yep, that would work
<leonardr> gary: what's the syntax for demanding that?
<gary_poster> leonardr: um, try to get the utility (e.g. zope.component.getUtility or queryUtility)?  If it fails, fall over, maybe with a more helpful message than just "the component isn't registered," by raising an error
<gary_poster> leonardr: am I missing something?
<leonardr> gary: i'm missing something
<leonardr> i know how to fall over if the utility isn't there. in fact, right now it happens automatically
<leonardr> i don't know how to make the utility be there
<gary_poster> leonardr: right
<gary_poster> ah
<gary_poster> leonardr, so, (1) make sure that the zcml to register the desired utility comes before the zcml to do your registration and validation, when reading the zcml depth-first (that is, following zcml imports). (2) Make sure that your registration and validation happen in the second stage of ZCML processing (that is, not when the zcml directive is supposed to insert functions and discriminators, but within the function that it reg
<gary_poster> that is done correctly already.
<gary_poster> leonardr: did that make sense?  if not, happy to try Skype
<leonardr> gary: i understand in principle but i don't know how to make sure something happens in the second stage
<leonardr> i'm going to leave this part alone for now
<gary_poster> leonardr: ok.  let me know when you want to tackle.
<leonardr> knowing that if all else fails i can compare the versions when the utility is defined, and fall over if they don't match
<leonardr> hm, i also see a problem with defining a single 'webservice_version' function that can annotate a field, a method, an entry, or an interface
<leonardr> i may just give them different names for now
<henninge> adiroiban: When I was asking about "where" I meant "where in the code". ;-)
<henninge> adiroiban: so it's in POTemplateEditView.change_action, isn't it?
<adiroiban> henninge: yes
<henninge> adiroiban: so there is no need to actually expose it in the form.
<henninge> adiroiban: and that is what I understood when you said " should I make it available for edit in +edit?"
<adiroiban> henninge: no. But I don't know how we should solve the permission problem.
<henninge> adiroiban: you only need to change permissions on the *object*. You do that in lp/translations/configure.zcml
<henninge> adiroiban: or you could use removeSecurityProxy, too, like you suggested.
<henninge> removeSecurityProxy(context.date_last_updated) = datetime.datetime.now(UTC)
<adiroiban> henninge: what do you suggest? should I add date_last_updated to Launchpad.Edit for IPOTemplate, or just use removeSecurityProxy ?
<gary_poster> leonardr: do you see wadl generation thread on launchpad-devel?  Could you jump in, please?
<henninge> adiroiban: I am not sure, actually ... danilos, what do you think? ^^
<leonardr> gary, sure
<gary_poster> thanks
<adiroiban> henninge: I am not aware of posible side effects...
<henninge_> adiroiban: did my last line come through?
<henninge_> adiroiban: I am not sure, actually ... danilos, what do you think? ^^
<gary_poster> leonardr, uh, wait a sec.  gmb, I think this means that someone updated (added) a dependency to sourcecode?  And didn't update ec2 images?  leonardr, I guess this doesn't have anything to do with wadl really, unless you tell me I'm wrong
<adiroiban> henninge_: i think Danilo is away
<henninge_> adiroiban: but using removeSecurityProxy might be ok here. Do that and see what bac says about it ... ;-)
<gary_poster> (other than it being the point of failure for what appears to be a problem somewhere else)
<henninge_> adiroiban: so will I be very soon ;)
<adiroiban> henninge_: :)
<leonardr> gary: my guess is that the error happens in wadl generation because that's the first time a new launchpad install is started up
<leonardr> gary: because we need the wadl to generate the static html apidoc
<gmb> gary_poster, leonardr: The builder.recipe thing? There's a thread about it on launchpad-dev.
<gmb> It's been tracked down to some buildout config weirdness, I think.
<gary_poster> leonardr: right agree, sorry for bothering you, I don't this has anything to do with you
<leonardr> np
<henninge_> adiroiban: my reasoningn for removeSecurityProxy would be that the owner should not really be able to set it, just in this specific context.
<gary_poster> gmb: well, the build, not buildout per se, but yes.  If I understand correctly, this is exactly the kind of situation that buildout fixes, and we don't get the win because these are branches in sourcecode
<gmb> gary_poster: Ah, right. So this needs an ec2 image update for db-devel branches to be runnable there again?
<jamalta> if i need to reset my database, do i just run make schema again?
<gmb> jamalta: Yes
<gary_poster> gmb: I think it is nastier than that.  IIUC, we would need an image for db-devel and an image for devel, given the current state.  ...I *think* the right/easy thing to do is to make devel's sourcedeps.conf have the same two lines that stub identified in db-devel
<gmb> Ah, right.
<jamalta> gmb: alright, thanks
<gary_poster> flacoste, have you followed along with the "db-devel wadl generation broken" thread?  My thought is that, for an easy solution, we should have a devel branch in which we add the two lines that are in db-devel that stuart identifies (for bzr-builder and bzr-hg)
<gary_poster> The other approach is to fix all of our scripts to handle this situation, but I think thta's a rabbit hole
<adiroiban> henninge_: can I use removeSecurityProxy for just an attribute?
<henninge_> adiroiban: oh, sorry, no.
<henninge_> removeSecurityProxy(context).date_last_updated = datetime.datetime.now(UTC)
<adiroiban> henninge_: hm... I did this
<adiroiban>             date_last_updated = removeSecurityProxy(context.date_last_updated)
<adiroiban>             date_last_updated = datetime.datetime.now(UTC)
<adiroiban> and somehow the tests were ok
<henninge_> adiroiban: maybe it does work ...
<henninge_> adiroiban: zope never ceases to amaze me ... ;-)
<adiroiban> henninge_: it's just that you can not assign to a function call
<adiroiban> henninge_: I think this was the only reason why removeSecurityProxy(context.date_last_updated) = datetime.datetime.now(UTC) , is not working
<henninge_> adiroiban: probably
<leonardr> gary: given that you're busy with the db-devel problem, i've found another place where i'll need to do utility lookups to do multiversion, so i'd like to hear more about the two-pass proposal you mentioned earlier
<henninge_> adiroiban: I'll be off now. See you tomorrow!
<adiroiban> henninge_: have a nice day. thanks for the help :)
<henninge_> you, too
<gary_poster> leonardr: ok.  I'm writing an email to the list about the db-devel thing, then will be available
<gary_poster> leonardr: ok, could you point me to the current lazr.restful code that processes the zcml?
<leonardr> gary: sure, it's in src/lazr/restful/metazcml.py
<gary_poster> ok
<leonardr> the problematic zcml handler is 'register_webservice'
<leonardr> i actually have a plan and i want to see if it makes sense, but take a look at that code
<gary_poster> ok
<leonardr> the XXX in that method is where the problem is
<gary_poster> leonardr: so, take a look at register_exception_view in that module
<leonardr> gary: sure
<leonardr> is that kind of hook setting stuff up for the second pass?
<gary_poster> leonardr: it is registering a discriminator, a callable, and args for the callable.  This means that ``register_exception_view`` is the first pass and, yeah, ``handler`` is the second pass
<leonardr> ok, then i think my plan will work and is similar to what you were saying i should do
<leonardr> take a look at that xxx
<leonardr> i want to specify a more appropriate interface method than IWebServiceClientRequest
<leonardr> but that requires looking up a named utility using version number as the name
<gary_poster> ah
<leonardr> so what i plan to do is define a subclass of zope.component.handler
<flacoste> gary_poster: well, i'm not sure about that, there is no garantee that the tests will pass with these two updated deps
<flacoste> gary_poster: it's a more general problem of having different sourcode deps in different branches
<leonardr> and call context.action with callable=my new handler
<gary_poster> flacoste: are the updated or added?  I thought they were added?
<flacoste> gary_poster: devel and db-devel being the most common case
<leonardr> and args=something like this
<flacoste> gary_poster: if they are added, it should be fine
<flacoste> gary_poster: but i think what might require is one sourcecode directory per root-branch
<flacoste> gary_poster: where root branch are devel, db-devel and production-devel
<flacoste> and make sure that the scripts picks the one appropriate for the parent branch
<leonardr>             args=('registerAdapterForVersion',
<leonardr>                   factory, interface, '1.0', provides, '', context.info),
<leonardr>             )
<gary_poster> flacoste: I think it is added.  What you describe sounds good for a later change, particularly if we still don't think we're discarding sourcecode anytime soon
<leonardr> call that multiple times, matching each interface to the version *name*, and then have the custom handler 1) do the lookups, and 2) fall over if invalid versions are specified
<gary_poster> flacoste: I'd like someone (which may mean me) to just add the deps for now though
<gary_poster> (if they are added)
<flacoste> gary_poster: go ahead
<gary_poster> leonardr: that sounds fine to me, though I hope that the ``callable`` really just has to be a callable--so, if it makes sense to subclass the handler, then sure, but otherwise you could just pass in your own function that does what you want and not try to be unnecessarily general
<leonardr> gary: that sounds good
<leonardr> ok, i feel better about this now
<flacoste> gary_poster: discarding sourcecode: we are mostly down to the irreductible core: bzr plugins, c-i-p and shipit
<gary_poster> leonardr: :-) ok cool
<flacoste> gary_poster: c-i-p will be gone in a month or two
<flacoste> gary_poster: shipit never really poses a problem which leaves the bzr plugins, not sure about those
<gary_poster> flacoste: Martin Pool mentioned that they were interested in making the bzr plugins setuptools-friendly.  I don't know how doable that is either
<flacoste> gary_poster: ideally they should support eggs installation, but given lifeless stance on setuptools not sure what are the chance of this happening
<gary_poster> He wanted to talk it over with me when we were at the last team lead sprint
<flacoste> gary_poster: ah, that'd be great!
<jamalta> i'm getting these pylint notices and just wanted to make sure that they are safe to ignore (they are not referencing anything i changed)
<jamalta> http://paste.ubuntu.com/359102/
<gary_poster> jamalta: definitely the lazr.*; less sure about the email.*
<jamalta> gary_poster: let me get a diff of what i've done
<gary_poster> k
<jamalta> it's just two strings changed around :)
<gary_poster> :-)
<jamalta> http://bazaar.launchpad.net/~jamalta/launchpad/newtag-statement-redundancy/revision/10195
<jamalta> gary_poster: ^
<gary_poster> jamalta: yeah, I think you are off the hook :-)
<jamalta> gary_poster: awesome, thanks :)
<gary_poster> np
<jamalta> gary_poster: mind if i throw your name in my proposal? just saying you confirmed that they are not issues caused by me
<jamalta> or i could instead just say it was confirmed in #launchpad-dev
<gary_poster> jamalta: name is fine
<jamalta> gary_poster: thanks so much
<mrevell> night all :)
<wgrant> Does anybody know what bigjools wanted?
<wgrant> Ah, looks like he might be back later.
<wgrant> And he emailed me. Even bette.r
<jamalta> well that's a bust, i guess i can't see the buildbot results if i'm not a canonical employee?
<maxb> jamalta: Indeed :-(. They say they're working on it
<jamalta> maxb: Well, at least we have some hope :)
<jamalta> Maybe they should give buildbot access to people who have signed the contributors agreement?
<jamalta> Who knows what will be decided...
<maxb> Anonymous read-only viewing of buildbot and pqm status would be a good start
<jamalta> maxb: +1
<wgrant> That's difficult for a couple of reasons: 1) buildbot needs upgrading to remove XSS vulnerabilities and 2) PQM (and soon buildbot) manage production-devel, which needs to remain private for security fixes.
<thumper> gary_poster: hi
<gary_poster> thumper: hey
<thumper> gary_poster: BjornT had a look with me before I sent off the email and had no idea either
<gary_poster> thumper: ah :-( .  I think I saw someone else reply...
<thumper> gary_poster: yeah, rockstar replied
<thumper> gary_poster: if I run the windmill tests just using the test runner they all pass
<thumper> gary_poster: if I run `make jscheck` they fail
<thumper> no idea why
<thumper> got things like 'already disconnected error'
<rockstar> thumper, I suspect timing issues, but I'm doing other things right now.
<rockstar> thumper, I basically spent an 8 hour flight trying to figure out why they were failing, and it was all voodoo
<gary_poster> thumper: right.  I don't know either, and rockstar, BjornT and mars all know more than I.  mars said he would look into it soon; he's my last best hope for now.
<gary_poster> but he has other items he needs to tie up
<thumper> ack
<rockstar> I'm willing to bet that if I land this, it won't fail in buildbot...
<rockstar> thumper, you should try first...  :) ^^^
<thumper> no
<gary_poster> thumper: the only other thing I know of is to try to rockstar's comment that the Windmill tests are not ready yet to block landings.  That would be something to take up with BjÃ¶rn, and maybe Maris.
<BjornT> thumper: i would merging in latest devel, and try again. r10192 contains a possible fix
<thumper>  BjornT: ok
<salgado> thumper, if you run 'make jscheck' on a devel branch, do they fail as well?
<thumper> salgado: haven't tried
<salgado> thumper, that'd indicate something in your setup is not playing along nicely with windmill tests, but only worth trying if stub's change doesn't get rid of the failures you saw
<BjornT> gary_poster, rockstar: as to whether to block landings. when/how do you propose we fix issues like these? if not now, then we'll probably never will be able to do it, since this is the first time i've seen it (and i've run quite a few tests). we have to go through some level of pain to make it stable. the other alternative would be to not have windmill tests at all, but i don't want us to go there yet
<rockstar> BjornT, well Windmill tests have jumped leaps and bounds since we started on them.  That was inspired by pain.
<rockstar> BjornT, however, I have a high priority bug that needs to land this cycle, and the tests are preventing it from landing.
<gary_poster> BjornT: I'm not advocating, merely observing that this was thumper's other alternative approach.  I agree with your logic, and particularly that they deserve much more of a chance.
<BjornT> rockstar: did you send a mail to the list about your problems, for others to look at?
<rockstar> BjornT, thumper beat me to it, with the same issue.
<rockstar> I detailed what I was seeing in my response.
<rockstar> BjornT, the simple fact is that the tests are not reflecting real breakages.  All the functionality is still intact.
<BjornT> rockstar: fwiw, we had much bigger problems when starting using buildbot. i think the main problem here is that no one knows how to debug it. it's difficult, since the errors seem to be in the app server, not in windmill.
<BjornT> i might have some time to look at it today
<rockstar> BjornT, that would be appreciated.  It's really frustrating, and I haven't had much time to look at it.
<wgrant> bigjools: Does buildd-manager work even with that odd message?
<rockstar> BjornT, when we had the problems with buildbot, they were more-or-less "stop the presses" kind of problems.  I don't think these are stop-the-presses issues, considering that most of Launchpad is non-js.
<BjornT> rockstar: well, a lot of our js is stop-the-presses issues. for example, what if peple can't comment on bugs or mps? what if they can't change statuses? those are quite critical issues that we don't want our users to experience.
<rockstar> BjornT, yeah, but in this case, the functionality isn't broken, just the tests.
<BjornT> rockstar: yes, and it was the same thing with buildbot in the beginning. would you rather have us not spend time fixing those problems, and instead have gone back to using pqm to run the tests?
<rockstar> BjornT, so maybe the issue is that we need to get a swat team together to kick down the door and clear the room when we have these problems, and they drop everything else for that.
<rockstar> BjornT, I'd be willing to be on that team if thumper was agreeable.
<BjornT> rockstar: yeah. there is the problem that i probably knows the most about theses issues, and i'm busy atm.
<BjornT> i wonder if gary_poster could spare someone from his team to work on windmill issues?
<rockstar> BjornT, yeah, I'm also trying to get some work in today so I can spend the rest of the week QAing.  It's likely I can spend tomorrow really looking into this.
<gary_poster> BjornT: are you asking generally or now as an emergency?  generally, I think, on the Foundations team, mars already has the best handle on this part of the world.  salgado might be a good choice as well, in the future.  For this week, mars could have a bit of time at the end of this week maybe, and more next week; I'd rather not take salgado off his task ATM.  For today, right now, I don't have anybody.
<Ursinha> hello people
<Ursinha> what do I have to do to add stuff in lp.dev sample data? is there a procedure somewhere?
<rockstar> Ursinha, my general answer to that is "don't."
<Ursinha> rockstar: right, why?
<rockstar> Ursinha, it usually causes more problems for me than it fixes.
<rockstar> Ursinha, I bet salgado has a better answer though.
<Ursinha> rockstar: right... I'll ask him when he's available, thanks
<Ursinha> rockstar: I'll try to go another way to test what I want
<rockstar> Ursinha, I have a script that I made that creates sample data for my specific use cases when I'm using make run.
<Ursinha> rockstar: can I see that? :)
<rockstar> Ursinha, do you know about make harness?
<Ursinha> rockstar: yes
<rockstar> Ursinha, so you should have a factory in make harness.  Use that factory like you would in your tests.
<Ursinha> rockstar: right
<rockstar> Ursinha, that's how I did it.  I can't seem to find that script right now.  I think it might be on my desktop computer.
<BjornT> gary_poster: i guess both. mainly now for the emergency, but also for the future, in case it breaks again.
<Ursinha> rockstar: wait, doing that isn't the same as writing the tests?
<Ursinha> rockstar: my problem is that I need to test a change in a page, and I'd need one more series in the project I'm using for it to work
<Ursinha> rockstar: that's why I'm asking about the sample data
<rockstar> Ursinha, oh, if you're needing test sample data, then the answer is really "don't"
<rockstar> Ursinha, create the sample data you need in the test itself, using the factory.
<rockstar> Ursinha, that would mean creating a project and a couple of serieses in your case.
<Ursinha> rockstar: yeah, I guess I found what to do here
<gary_poster> BjornT: OK.  maybe you and mars can work together a bit next week to give him some more familiarity.  He might have some availability tomorrow.
<Ursinha> thanks rockstar
<bdmurray> I'm having an issue running tests with GoogleServiceLayer and a "Socket poll time exceeded."
<intellectronica> gary_poster: do you maybe know anything about this? ^^^^^
<gary_poster> intellectronica: not off hand, and on call
<rockstar> bdmurray, does it happen repeatedly?
<bdmurray> rockstar: yes
<wgrant> bdmurray: Interesting. I have recently had that occasionally when trying to run LaunchpadFunctionalLayer tests.
<wgrant> I wonder if it's actually reproducible, and I just haven't noticed.
<bdmurray> it stopped happening now
<mwhudson> bdmurray: have a look for stuck python processes?
<wgrant> canonical.testing.layers.LayerInvariantError: Both Zopefull and Zopeless CA environments setup
<wgrant> Huh?
<mwhudson> fun
<elmo> you may be hopeful, but I think it's hopeless
<al-maisan> ^^ a candidate for the quotes page :P
#launchpad-dev 2010-01-20
<jml> wgrant, there's still a BRANCH.TODO in that patch
<wgrant> jml: I was about to fix that.
<wgrant> I must have used the wrong prereq.
<jml> :)
<wgrant> r something.
<jml> I'll review the branch then.
<wgrant> Thanks.
<wgrant> Ah, yeah, I based it on the integration branch, but forgot ther was still that one change remaining.
 * wgrant pushes.
<wgrant> jml: Diff is fixed now.
<jml> wgrant, cool.
<wgrant> Hm, odd import diff.
<jml> wgrant, I've reviewed it. Thanks for the patch :)
<wgrant> jml: Why not 'queueBuild'?
<jml> wgrant, that could work. Took me a moment to see that 'queue' was a verb though...
<jml> wgrant, but it is a better name. :)
<wgrant> _estimateDuration was private before, so it wasn't on the interface.
<jml> ahh ok.
 * mwhudson stabs buildmailman in the lungs
 * mwhudson widens his stabbing to the build process in general
 * elmo joins in the stabbing from the sidelines
 * wgrant stabs both the Launchpad and Soyuz build processes.
<jml> gargling stabby lungs
<wgrant> jml: Want to review the second bit? It's 500ish lines
<jml> wgrant, sure. It'll be a couple of minutes before I start though.
<jml> wgrant, ok. ready
<jml> woot.
<wgrant> This is landable, as thefinal in a series of three unmerged branches.
<wgrant> The first is noodles', and was reviewed last week.
<wgrant> (that's the remaining unmerged bit of the integration branch)
<jml> wgrant, why the new tests in lib/lp/soyuz/tests/test_sourcepackagerecipebuild.py ?
<jml> wgrant, also, is there a bug filed for the bad names?
<wgrant> jml: There is a bug filed. Shall I add it there with an XXX?
<jml> wgrant, that'd be nice, thanks.
<wgrant> The new tests are because there are new bits on the interface that have been implemented.
<jml> wgrant, ah, I see now.
<jml> wgrant, r=jml
<wgrant> jml: Thanks. I'll add the XXX, then convince you to ec2 land it.
<jml> wgrant, ok.
<wgrant> jml: OK, pushed (also with the year corrected in all of my XXXs. oops)
<wgrant> Can you please ec2 land it?
<jml> wgrant, sure. got a commit message on the MP?
<wgrant> jml: Yep.
<jml> wgrant, just to be clear, I'm landing lp:~wgrant/launchpad/ibuildbase-compliance right?
<wgrant> jml: That's the one.
<jml> cool.
<wgrant> jml: How's your process-upload branch?
 * jml does some local make build crap
<jml> I had forgotten about it.
<wgrant> That's all that's unlanded, apart from my Friday afternoon hacks which I'm isolating now.
<jml> ok.
<jml> wgrant, ec2 land is broken :(
<jml> wgrant, or maybe I am.
<wgrant> jml: What went wrong?
<jml> I gave it the url of the branch, not the mp
<jml> it raised a stupid error message
<wgrant> Ah.
<jml> process-upload-checks had some conflicts
<jml> I've resolved them fairly brainlessly, but I think correctly
<wgrant> So, bug #507783, bug #507784 and bug #507363 remain as blockers for a full run-through.
<mup> Bug #507783: RecipeBuildBehaviour has no security declarations <wellington> <Soyuz:Triaged by jelmer> <https://launchpad.net/bugs/507783>
<mup> Bug #507784: SourcePackageRecipeBuild.getLogFilename() is not implemented <wellington> <Soyuz:Triaged> <https://launchpad.net/bugs/507784>
<mup> Bug #507363: Generalise rescueBuilderIfLost <wellington> <Soyuz:New> <https://launchpad.net/bugs/507363>
<wgrant> Yeah, it was trivial to merge that.
<wgrant> jml: Since jelmer's branch has landed, somebody should probably sneak that first one in.
<jml> wgrant, the process-upload-checks branch is waiting for a review, but no one has
 * wgrant fixes the middle one.
<wgrant> jml: Ah. I guess that's probably a bigjools thing.
<jml> yeah
<jml> wgrant, I think my branch fixes bug 507783
<mup> Bug #507783: RecipeBuildBehaviour has no security declarations <wellington> <Soyuz:Triaged by jelmer> <https://launchpad.net/bugs/507783>
<jml> 12 conflicts encountered.
<jml> :(
<wgrant> jml: Your p-u-c?
<jml> yeah, after merging db-stable in
<wgrant> jml: Merge ibuildbase-compliance into it. It is reasonably up-to-date.
<wgrant> (and will be landed soon... maybe)
<jml> the instance is up & running, fwiw.
<wgrant> Great, thanks.
<jml> merging your branch in doesn't really help
<wgrant> Hmmm.
<jml> I'll do db-stable & get that going
<jml> I have nfi why I get code import conflicts
<jml> criss-cross ftl
<wgrant> Yay criss-cross?
<wgrant> Yeah.
<wgrant> jml: I need a common base class for BuildFarmJobs that have an associated BuildBase. Any hints for names that don't suck?
<jml> wgrant, start by picking a non-crappy name for BuildBase, I guess.
<wgrant> Julian's against renaming that for the foreseeable future.
<jml> wgrant, such BFJs are building package stuff, right?
<wgrant> jml: Yes.
<wgrant> SourcePackageRecipeBuildJob and BuildPackageJob, but not TranslationsRecipeBuildJob or whatever they call it.
<jml> wgrant, PackageBuildFarmJobs?
<jml> oh wait
<wgrant> They're not necessarily building packages, but all the current candidates do.
<jml> BuildPackageJob is _also_ terribly named
<wgrant> It is.
<wgrant> We intend to rename it.
<wgrant> to BinaryPackageBuildJob.
<jml> wgrant, what's the thing they have in common?
<jml> other than building packages?
<wgrant> jml: {SourcePackageRecipeBuildJob,BuildPackageJob}.build is an IBuildBase
<jml> _handleStatus_OK should be on Build, right?
<wgrant> No, it should be on BuildBase.
<wgrant> Well, until somebody else needs a different implementation.
<jml> wgrant, yeah, but conceptually -- you say they aren't necessarily for building packages?
<wgrant> Right.
<wgrant> I don't want to make the inheritance hierarchy more horrible than is necessary.
<wgrant> If somebody wants to add a BuildBase derivative that doesn't do package stuff, they can create another layer.
<jml> what could they possibly be for other than building packages?
<wgrant> jml: Is there anything package-specific on IBuildBase?
<wgrant> Just about any other job running in an archive context could use it.
<jml> wgrant, I guess not.
<jml> wgrant, there's nothing about archives there either.
<wgrant> jml: Not in trunk. Check my branch.
<jml> wgrant, I'll take your word for it :) I want to resolve these conflicts before digging into even more code.
<wgrant> Ah, yeah, good idea.
<jml> wgrant, perhaps the name should have something to do with archives.
<wgrant> It also has distroseries, pocket, etc.
<jml> yeah. that sounds pretty package-y to me.
<jml> or at least, very focused on stuff to do with debian-derivatives.
<wgrant> Mm, possibly.
<wgrant> Yeah.
<wgrant> Hmm.
<wgrant> We actually have some build-specific stuff in BuildFarmJobBehaviorBase.
<wgrant> Julian suggested that when we asked him about a name for the build-specific version of that.
<wgrant> I wonder if we should do the same here.
<jml> another thing to consider is that maybe our current object/class model is forcing us to choose bad names.
<jml> on db-stable, which is correct:
<jml>         specific_class = self.specific_job_classes[self.job_type]
<jml>         specific_class = specific_job_classes()[self.job_type]
 * jml picks one
<jml> OK. After that bloody merge, I'll run the tests.
<jml> hmm. I should have done that merge in the 'wellington' branch.
<wgrant> Possibly.
<jml> or I should abandon the branch.
<wgrant> Once my branch lands, the branch is merged.
<jml> fair enough.
<jml> I'll abandon it then.
<wgrant> So probably best to abandon it.
<wgrant> Yep.
 * jml goes back to gtg hacking
<wgrant> jml: Before you vanish, do you have anything more to say on the naming thingy?
<jml> wgrant, I think I'd give it a name that emphasises the archive-y or package-y nature of it.
<wgrant> jml: OK. Thanks.
<jml> wgrant, I also think that once the translation stuff lands, it would be worth writing a document that explains the current system, and how to add a new type of job
<wgrant> Probably, yes.
<jml> wgrant, by seeing all of the cruft described to other humans, we'll all suddenly get good ideas on how to make it better.
<jml> (also, subclassing for code sharing sucks)
<wgrant> What's a better solution?
<jml> wgrant, often composition is a better solution.
<jml> wgrant, but also sometimes just having different kinds of objects :)
<wgrant> True.
<jml> C++ folks have some sort of proverb for this, IIRC. thumper might know.
<thumper> jml: for what?
<freim> Hi. I have installed launchpad as described on launchpad.net and it seems to be running correctly. I do however start to wonder if I got the right branch build since everything seems hardcoded to launchpad.dev, has dummy data in it, mail configured to only go to local root, etc. Should I use a different branch for a production server?
<spm> freim: no you have the right code - same as what we use on the prod servers; you should (I believe) have a file configs/README.txt that should take you thru some of the config stuff and vaguely how it all works. The defaults are all wired for .dev as you've noticed.
<freim> spm: ok, thanks
<freim> guess I need to learn zope then :)
<wgrant> Anybody around who can check if PQM knows about my branch?
<wgrant> An ec2test started 5 hours ago, but I haven't been emailed either way yet.
<wgrant> jml: ^^?
<wgrant> Yay, landed.
<al-maisan> Yep!
<wgrant> This leaves jml's branch, my other branch, and two more diff hunks until trunk can do an end-to-end recipe build.
<al-maisan> hmm..
<al-maisan> wgrant: maybe it would be worthwhile sending a bigjools an email outlining what you just said i.e. what branches are still outstanding and mee
<al-maisan> .. and need to land
<wgrant> I might, yeah. i'm just proposing my latest branch now.
 * al-maisan goes back to packing
<wgrant> Oh, yeah, you're leaving :(
<al-maisan> yup, tomorrow, bright and early :)
<wgrant> 6am?
<al-maisan> from the hotel, yes.
<jml> wgrant, hi
<adiroiban> henninge: Hi, regarding bug 507498 , any idea why the bug was not catched by xx-potemplate-index.txt test ?
<mup> Bug #507498: AttributeError on potemplate page <oops> <Launchpad Translations:In Progress by adiroiban> <https://launchpad.net/bugs/507498>
<jml> wgrant, my branch has broken zcml, so doesn't get past the build step
<jml> wgrant, I'll look at it tomorrow or maybe later tonight, off to dinner now.
<wgrant> jml: OK, thanks.
<henninge> Hi adiroiban!
<adiroiban> henninge: hi. I'm investigating why the bug 507498 was not prevented by the current tests (xx-potemplate-index.txt)
<mup> Bug #507498: AttributeError on potemplate page <oops> <Launchpad Translations:In Progress by adiroiban> <https://launchpad.net/bugs/507498>
<henninge> adiroiban: yes, I am looking at that
<henninge> adiroiban: it's because that permission got only checked on a corner case that the page test does not cover.
<henninge> adiroiban: it is only checked if the project has rosetta *not* enabled and the template is *not* active (current).
<adiroiban> henninge: but why. I can see the potemplate-index, is accessing a POTemplateSubset (+pots) using anon_browser
<henninge> adiroiban: then, in the check itself the owner check was only done if the potemplate was not for a productseries.
<henninge> adiroiban: consider these two lines:
<henninge>         if ((official_rosetta and potemplate.iscurrent) or
<henninge>             check_permission('launchpad.Edit', potemplate)):
<henninge> adiroiban: check_permission will only be called if on of official_rosetta iscurrent is false.
<henninge> s/on/one/
<henninge> (there was a term for that but I forget)
<adiroiban> henninge: thanks. got it now :)
<adiroiban> so normal user are not linked to that page... wondering how Diogo spoted this bug
<henninge> adiroiban: also, for anon_browser, checkAuthenticated will not be called at all.
<henninge> adiroiban: Diogo is just looking at oopses that occur on the production, edge and staging servers.
<henninge> adiroiban: so this did not happen to Diogo but a user on edge.
<adiroiban> :)
<adiroiban> yes, but since that page is not linked from any other page visible to normal users
<adiroiban> then is should have been a webcrawler or such :)
<adiroiban> thanks for the explanations :)
<henninge> adiroiban: or a book mark or a user hacking the url ...
<wgrant> bigjools: Morning.
<bigjools> morning
<wgrant> Did that buildd-manager warning actually cause any problems/
<bigjools> not that I can tell
<wgrant> hmm.
<bigjools> but I wasn't paying much attention
<wgrant> Might just be the generally broken logging.
<bigjools> yeah the logging is pitiful
<wgrant> I mean, we broke it somehow last week.
<wgrant> It works in the tests, but not in real life.
 * wgrant hunts for a reviewer for https://code.edge.launchpad.net/~wgrant/launchpad/bug-507784/+merge/17722
<mrevell> Hi!
<bigjools> eyup mrevell
<mrevell> bigjools, Back in GMT yet?
<bigjools> mrevell: yeah since sunday
<wgrant> He abandoned us.
<bigjools> well - my body is in GMT
<mrevell> bigjools, Yeah, I meant your mind, rather than your body :)
<bigjools> I've been waking up at 5am every day since sunday
<mrevell> nice
<bigjools> wgrant: how's lca?
<wgrant> bigjools: Pretty good. Some very interesting talks.
<bigjools> and do you have any unlanded branches from last week?
<wgrant> And the wireless even works now.
<bigjools> gosh
<wgrant> bigjools: Three branches landed a couple of hours ago.
<wgrant> One is outstanding -- the one I linked 15 minutes ago.
<bigjools> ok
<wgrant> Then jml's needs to land (he's requested a review from you, but the diff looks utterly broken), and somebody needs to fix rescueBuilderFromSlave.
<bigjools> E_too_many_new_classes
<wgrant> Then everything is merged.
<wgrant> YES.
<bigjools> I'll review his todau
<bigjools> today even
<jml> bigjools, thanks.
<bigjools> was busy fixing that private build cockup yesterday
<wgrant> jml: Any idea what's wrong with the diff?
<wgrant> bigjools: What was the actual problem? Private->public PPA copies worked fine here...
<bigjools> jml: no problem Stephen
<jml> wgrant, no, I'm working on other more interesting failures right now
<bigjools> wgrant: the bug you reported about the missing _sendFileToSlave
<jml> bigjools, :)
<wgrant> bigjools: Oh, that one.
<bigjools> yes that one :)
<jml> bigjools, I was saying to wgrant (re the too many classes thing) that it'd be good to write a doc on how to add a new build farm job after this & the translations one are done
<jml> bigjools, such a doc would show us quite clearly the bits where it's All Too Hard
<bigjools> +1
<bigjools> I want to document all the new classes separately
<bigjools> and then we can rename them if needed
<bigjools> it's too bloody confusing
<wgrant> Yep.
<wgrant> And we can shuffle stuff out of lp.soyuz. Once everything is merged.
<bigjools> jml: where do we normally put mixin classes in our hierarchy?
<bigjools> yep
<wgrant> At least the Translations jobs seem to be keeping to lp.translations
<jml> bigjools, well, a "how to" guide might show you why some of them don't need to be separate (or exist!) at all. Or maybe not.
<jml> bigjools, probably lp.services normally. lp.buildmaster seems a good place for a lot of these though.
<bigjools> well wgrant has added one in the model dir.  I question if that taints the purity of everything actually being a model class
<wgrant> I suspect that lp.buildmaster actually wants to go to lp.services.buildfarm eventually.
<bigjools> or just rename buildmaster -> buildfarm
<jml> oh right
<jml> bigjools, on the 'model' or not, opinion is divided
<jml> bigjools, I personally think that the word 'model' means more than just "db wrappers"
<bigjools> well I don;t mind either way, as long as it's clear :)
<bigjools> and that we all know where to put them and look for them
<jml> bigjools, probably 'model'
<jml> hardly anyone actually uses the 'adapters' subpackage
<bigjools> apart from Soyuz :/
<bigjools> which wasn't my doing
<jml> also, lp.services.buildfarm would better fit the intent of the new tree than lp.buildfarm. But I'll save that argument for when someone gets around to moving it. :)
<bigjools> I don't like lp.services
<bigjools> it seems ill-defined
<wgrant> If the build farm isn't a service, what is?
<bigjools> what's a service?
<wgrant> Good question.
<bigjools> wgrant: ok I'll approve your branch - is jml landing it?
<jml> bigjools, lp.services is supposed to be stuff that the rest of Launchpad uses that isn't really worthy of an external library
<jml> it's a terrible name
<bigjools> yeah
<jml> but I haven't heard anyone come up with a better one, or a better place to put generally useful code.
<bigjools> lp.stuff would even be better :)
<wgrant> bigjools: I've not organised a landing.
<wgrant> I wonder if I should sneak the fix for bug #507783 in with it, given that it wasn't included in jelmer's branch.
<mup> Bug #507783: RecipeBuildBehaviour has no security declarations <wellington> <Soyuz:Triaged by jelmer> <https://launchpad.net/bugs/507783>
<bigjools> feel free
<jml> wgrant, it's in my branch.
<jml> (I think)
<jml> I remember fixing it at the sprint anyway
<wgrant> jml: You attached a patch to the bug.
<jml> oh.
 * wgrant checks your branch, though.
<wgrant> I didn't see it when I merged it earlier.
<jml> no, that makes sense.
<jml> bigjools, wgrant: ok. I'm running my branch through ec2 test, now that its zcml is fixed
<wgrant> bigjools: OK, security stuff there. Can you ec2 land it?
<wgrant> jml: Great.
<bigjools> wgrant: I can't ec2 land it :)
 * wgrant will look at rescueBuilderIfLost tomorrow.
<wgrant> bigjools: Oh, true.
 * bigjools runs into the house and turns on the beast
<bigjools> wgrant: so the branch I just reviewed, you added zcml stuff?
<wgrant> bigjools: Right. http://bazaar.launchpad.net/~wgrant/launchpad/bug-507784/revision/10203
<bigjools> ok
<wgrant> Stolen from jml's diff.
<bigjools> I guess I should sort my ec2 access out
<wgrant> It's pretty handy.
<wgrant> jml: Is it expected that I didn't receive an email about the earlier test completion?
<jml> wgrant, umm. no.
<wgrant> It looks like I normally do, but this time I did not.
<jml> wgrant, I didn't get one either.
<wgrant> Odd.
<jml> yeah.
<jml> I'm not going to debug ec2 test / land now though
<wgrant> Good policy.
<wgrant> I suppose we should fix the data model this week.
 * wgrant considers the whole sleeping thing.
<bigjools> wgrant: you can sleep when you're dead
<adiroiban> hi. any idea why factory.makeProduct() is getting an error for wikiurl, when running from make harness ? http://paste.ubuntu.com/359492/
<bigjools> jml: still around?
<mars> BjornT, what format was the js-play.prof file that you took?  Firebug Profiler?
<bac> hi henninge_
<henninge> Hi bac!
<bac> hi henninge -- i'm re-reviewing the branch adi worked on yesterday.  he had a problem with date_last_updated
<henninge> yes
<bac> henninge: i recall you advised him to use removeSecurityProxy instead of updating the permission
<bac> henninge: problem is you can't set the new value using rSP
<bac> i was wondering why not just move date_last_updated to use lp.Edit
<henninge> bac: The reason I opted for rSP is that date_last_updated should only be changed in that context.
<bac> henninge: right, but it just doesn't work.  :)
<bac> a = removeSecurityProxy(b)
<bac> a = new_value
<bac> does not change b
<henninge> bac: but if that 's not possible, allowing lp.Edit is ok.
<henninge> bac: hm, something about flushing or comitting?
<bac> henninge: ok, i just wanted to run it by you to ensure i wasn't missing something
<bac> henninge: on the phone be right
<henninge> adiroiban: what's the login on that virtual machine?
<adiroiban> henninge: good question :)
<adiroiban> something like d3v3l0p3r
<adiroiban> user: developer
<bac> henninge: nm, i found out what he was doing wrong
<henninge> bac: oh, what was it?
<bac> henninge: he was calling rSP(context.date_last_updated) ... getting an unwrapped attribute not the unwrapped object
<henninge> bac, adiroiban: oh, I thought we had talked about that.
<henninge> adiroiban: the login was correct
<adiroiban> bac: thanks
<bac> adiroiban, henninge:  http://pastebin.ubuntu.com/359563/
<henninge> bac: yes, that's what I would have expected.
<mars> ok, I'm a bit confused by our setup docs here.  maxb, around?
<maxb> hello
<mars> hi maxb.  Do you have a moment to help untangle the docs for a system reinstall?
<mars> maxb, I'm trying to figure out why the 'launchpad-developer-dependencies' package isn't mentioned anywhere in the setup docs
<mars> and it is no longer in the ~launchpad PPA?
<maxb> !
<maxb> 'launchpad-developer-dependencies' is a binary package built by the 'launchpad-dependencies' source package. the PPA webpages display source packages
<maxb> It is in the PPA
<mars> ah
<mars> that makes sense
<mars> I know I have to install 'launchpad-dependencies' as a dep of lp-dev-deps, but I didn't know they came from the same source
<adiroiban> bac: I've pushed the change
<bac> adiroiban: ok, i'm including a few other bits in my review.
<mars> maxb, cool, thanks.  You wouldn't happen to know if installing the ~launchpad PPA, and then installing launchpad-developer-dependencies must be done *before* running rocketfuel-setup?
<mars> maxb, because the docs don't even mention the ~launchpad PPA
<mars> hmm
<maxb> Unless you're missing something really fundamental, like bzr, it should be fine to let rocketfuel-setup add the PPA
<mars> ah, it does?
 * mars checks the source again
<bac> adiroiban: MP updated
<mars> maxb, got it, ~line 177 in rf-setup.  Cool, thanks for the help!
<mars> "2 packages upgraded, 153 newly installed, 0 to remove and 11 not upgraded.
<mars> Need to get 310MB of archives. After unpacking 737MB will be used."
<mars> !
<mars> ^ that is the launchpad dev system footprint.
<bigjools> tell me about it, my nice lean VM image ballooned after installed the deps :(
<mars> well, that nixes the idea of downloading a full VM.  You'll have to grow the VM from a seed image.
<bigjools> yep
<bigjools> I have a script to make one
<mars> bigjools, how big is a 'lean' VM?
<bigjools> I can't really remember
<bigjools> at a guess it was about 30MB
<bigjools> maybe less
<mars> wow
<mars> big size difference there
<mars> gary_poster, ^ so that makes the story around "downloading a seed VM for LP developers" sound a little more appealing, eh?
<mars> argh.  rocketfuel-setup went without a hitch, but 'make schema' barfed on a CSS error: make: *** [css_combine] Error 1
<gary_poster> mars, yes.  bigjools, is that lean vm something we could offer to open source devs?  Or does it at least show us a way we could do it?
<bigjools> yeah we could
<mars> bigjools, and what does your "script to make one" do?  Build the VM, or the VM+lp-dev ?
<bigjools> I was using the vmbuilder script to make mine
<bigjools> just the VM, running rf-setup obviously bloats it
<mars> just the VM
<bigjools> however we could work out a minimal set of scripts that sets up basic stuff
<mars> and then some sort of easy way to run rf-setup inside of it
<bigjools> then let the dev run rf-setup
<bigjools> or a subset of it
<bigjools> it's very easy to set up with vmbuilder
<mars> bigjools, how do you access the vm from your local system?  Fuse?
<gary_poster> bigjools: I hadn't heard of vmbuilder.  That's cool.  What does the vm run in?
<bigjools> mars: I run it as a VM and ssh into it
<gary_poster> oh, I guess, many of them...
<bigjools> gary_poster: any vm manager :)
<mars> bigjools, how do you hack on the source tree then?
<bigjools> I used qemu
<gary_poster> yeah, nice little script!
<bigjools> mars: it's COW
<mars> surely you don't run the editor in the VM
<bigjools> what editor?
<mars> bigjools, "I need to hack on this feature, then run the branch".  How do I hack the branch with my local editor, but run the branch using the VM?
<mars> fuse is one way to do it
<mars> seamless integration
<bigjools> I think I was pulling off my host, or pushing to the VM
<gary_poster> I use fuse for my vm stuff.  It is nice.
<bigjools> I guess you can use fuse
<bigjools> but if the VM is running...
<mars> right, if the branch resides on the VM, then it needs to be running
<gary_poster> bigjools, I don't understand how the vm is only 30M.  Does it rely on the Ubuntu source hanging around?
<mars> but if the branch resides locally, and fuse pulls it into the VM...
<bigjools> gary_poster: it's only that size until you install the lp deps
<bigjools> and yes it pulls in a load of packages to build it in the first place
<bigjools> it helps if you have apt-proxy
<bigjools> for repeated runs!
<mars> bigjools, trying to work on your xvfb problem.  Does 'make css_combine' work in your copy of trunk?
<bigjools> mars: let me check
<bigjools> mars: yep it's fine
<mars> crap
<bigjools> mars: my big problem now is that I can't even run my tests using bin/test :(
<bigjools> it won't start the browser over an ssh-proxied X session
<mars> bigjools, yeah.  Did you see my reply?
<bigjools> oh not yet
<bigjools> mars: I replied to your reply, I have a different problem
<bigjools> unless you replied to my reply to your reply
<mars> bigjools, maybe an xset command is called for?
<kfogel> gmb: when you get a chance, take a look at our fix for that "XXX" in https://code.edge.launchpad.net/~kfogel/launchpad/505845-affects-person-from-dups/+merge/17721 (which I've resubmitted, so you should get a new diff)
<bigjools> mars: to do what?
<bigjools> I mean, other X stuff works fine over ssh
<bigjools> it's very odd
<mars> hmm
<bigjools> I think we should remove js tests from blocking landings until this is all resolved
<gmb> bigjools: +1.
<bigjools> gmb: do you find it flaky as well?
<gmb> bigjools: Not on this system, but I've had it do weird things to me last week (which I got around nicely by just killing the Windmill process)
<mars> bigjools, is that the correct display number in your error message?  10:0 ?
<Ursinha> bigjools: hello :)
<Ursinha> bigjools: is this a known error? https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1480EC819
<bigjools> mars: yes, it's the ssh proxy
<bigjools> Ursinha!
<bigjools> Ursinha: hmmm that's odd
<bigjools> Ursinha: someone is copying between private/public yet again
<bigjools> it's not really tested
<bigjools> I need to disable it :(
<Ursinha> bigjools: :(
<Ursinha> bigjools: may I file a bug about it?
<bigjools> I already have one
<bigjools> Ursinha: bug 509333
<mup> Bug #509333: LP should not allow a user to copy from a private to a public PPA <Soyuz:Triaged by julian-edwards> <https://launchpad.net/bugs/509333>
<bigjools> you can add the oops there if you like
<Ursinha> bigjools: just did that :)
<Ursinha> bigjools: thank you very much
<bigjools> thank you
<mars> bigjools, I'm wondering if some debugging info in test_on_merge.py, around line 140, may be in order
<bigjools> mars: happy to help
<mars> bigjools, perhaps a call to subprocess.call(['/usr/bin/bash'], shell=True) ?
<mars> to open a shell on the terminal
<mars> bigjools, either that, or a print statement
<bigjools> mars: which? :)
<mars> bigjools, still reading.  does the xvfb-run script use xauth?
<bigjools> mars: looks like it
<mars> bigjools, can you call something like "xvfb-run -s '-screen 0 1024x768x24' /usr/bin/xclock" on the local/remote sysytem?
<mars> bigjools, run xclock in the same way that windmill would run
<bigjools> mars: it just exits with no error
<mars> bigjools, I guess it would have to run on the remote system, because that is where test_on_merge.py is run
<bigjools> I tried local and remote
<mars> bigjools, how about: xvfb-run -s '-screen 0 1024x768x24' /home/ed/canonical/lp-branches/missing-slave-method-bug-509383/bin/test -vv
<bigjools> mars: same thing, it just exits
<mars> bigjools, no processes left over?
<bigjools> and leaves an xvfb running in the background
<mars> no test process, eh?
<mars> bigjools, ok.  So you get a "cannot connect to display" error when running bin/test on the remote system
<mars> and 'make check' fails on the remote system when you use the xvfb-run step
<bigjools> mars: yes, after about 3 hours when it starts the windmill layer tests
<mars> :)
<bigjools> so I landed the fucker anyway :
<mars> bigjools, 'make jscheck' on the remote system does... ?
<mars> heh
<bigjools> one sec
<bigjools> mars: working fine over the ssh tunnel
<bigjools> my screen is full of FF
<mars> hmmm
<mars> bigjools, reading man xvfb-run:  The following command should execute successfully: "$ xvfb-run --auto-servernum --server-num=1 xlogo"
<mars> bigjools, if it does not, grab the exit code
<mars> echo $?
<bigjools> one sec
<bigjools> mars: exit code is 1
<mars> ok, perhaps something with the way that xvfb-run is using server numbers
<mars> bigjools, I had to ^C that call on my local system, and it gave an exit code of 130
<bigjools> both my remote and local boxes have the problem here
<bigjools> I suspect you have a package installed I don't
<mars> bigjools, does it say anything in the terminal?  ""Xvfb failed to start" >&2
<mars> bigjools, you do have the xlogo program on your system, right?
<mars> the remote system
<bigjools> yes :)
<bigjools> mars: ok this is weird, now it works locally
<bigjools> but nothing in the terminal for the remote system that fails
<mars> bigjools, ok, "$ cp /usr/bin/xvfb-run $home/xvfb-run", edit the script, around line 182 add 'echo "Return value: $RETVAL"'
<mars> bigjools, then chmod +x $home/xvfb-run && bash $home/xvfb-run
<mars> er
<mars> and finally, run it with: $ xvfb-run --auto-servernum --server-num=1 xlogo
<mars> bigjools, that should give you /something/ in the terminal
<mars> there is a slight confounding of the script return variables at work here
<mars> I can't tell if xvfb-run is failing, or if the command you are passing to it is failing
<bigjools> mars: on a call now, I'll be intermittent, one sec
<mars> ok
<bigjools> mars: line 182 is "exit 1", is that the right place?
<mars> bigjools, uhm, no.  "exit 1" is line 175 on my system
<mars> $ apt-cache policy xvfb
<mars> xvfb:
<mars>   Installed: 2:1.6.4-2ubuntu4.1
<mars> bigjools, ^ ?
<bigjools> 2:1.6.4-2ubuntu4
<mars> running lucid?
<bigjools> hell no :)
<mars> ah, wait
<bigjools> ah but wait!
<mars> 2:1.6.4-2ubuntu4.1 is greater than 2:1.6.4-2ubuntu4
<mars> bigjools, so it looks like there is at least some teeny, tiny ten line difference between our xvfb-run scripts.  I wonder what the .1 package version bump did?
<bigjools> mars: I have that version in an update
<bigjools> let me try again
<mars> I lack the apt-fu to pull the change from the command line
<bigjools> mars: ok line 182 is "set -e"
<mars> bigjools, ok, then please add: echo "Proxied command return value: $RETVAL"
<mars> bigjools, and then you should be able to see if command failed, or if xvfb-run failed, or if Xvfb failed
<bigjools> well it doesn't fail any more
<bigjools> lol
<bigjools> mars: https://edge.launchpad.net/ubuntu/+source/xorg-server
<bigjools> see the changelog for karmix
<bigjools> it was published 14 mins ago and fixed xvfb
<mars> 'Universal Troubleshooting Process, Step 1: "Is your system up to date?"'
<mars> bigjools, what?!
<bigjools> quite :)
<mars> ok, next up: converting Bjorn's .prof file to KCacheGrind
<leonardr> flacoste, gary: we have declarations @operation_returns_entry and @operation_returns_collection_of
<leonardr> we do not have @operation_returns_nothing_in_particular
<leonardr> which means that in a multiversion scenario you can go from returning nothing in particular (ie. nothing the wadl needs to know about) to returning an entry, and then to returning a collection, but you can't go back to returning nothing in particular
<leonardr> should i define @operation_returns_nothing_in_particular as part of this work, or just mention it in case we need it later?
<gary_poster> leonardr: I don't really understand.  flacoste is away.  What does the wadl not need to know about?  Is this for the case of a function that returns None?  Or...
<leonardr> gary: if a named operation returns a data model object, we put that information into the wadl
<leonardr> otherwise it's assumed that the operation returns arbitrary json
<gary_poster> leonardr: but if it returns a scalar we do not?
<gary_poster> ah
<leonardr> and launchpadlib does not make any attempt to wrap the json in a launchpad object
<gary_poster> leonardr, so, @operation_returns_json
<leonardr> so we're talking about the unlikely case where a named operation returns a data model object in one version and arbitrary json in the next
<leonardr> yeah
<leonardr> good name
<leonardr> except it doesn't even have to be json
<gary_poster> example?
<leonardr> it could return html (assuming the client requested html)
<gary_poster> OK, I'm assuming we have these already.  It sounds like these methods are specifically for returning to the webservice?  @webservice_operation?  @direct_webservice_operation?  If it is easy to do this, it seems reasonable to do this now.  If it takes more than an hour, and we don't need it, move on.
<gary_poster> with a note
<gary_poster> leonardr: ^^^
<leonardr> gary: we do have such methods already
<gary_poster> ack
<leonardr> it's somewhat likely that they will trend towards returning data model objects
<leonardr> it's less likely that anything will go in the opposite direction
<leonardr> but it should be easy to add
<gary_poster> leonardr: are the methods typically specifically for the webservice?
<leonardr> gary: yes, these declarations only apply to methods _as published in the webservice_
<leonardr> now that i think about it, if a method changes that heavily, it's more likely that we'll define two different methods and expose them as the same name in different versions
<leonardr> we've got a similar problem with @mutator_for. what if the method stops being a mutator?
<gary_poster> leonardr: I don't think that's what I mean.  Yes, operations_* describe the webservice.  However, typically, they are annotating methods that are often used in other ways, yes?  They are often just internal API methods for which we say "expose this".  My question was whether these methods that return JSON or HTML are methods that are typically written for the webservice, rather than merely exposed by the webservice.  ...If i
<gary_poster> important, then whatever.
<leonardr> gary: in a multi-versioned environment you will not longer be able to just 'expose this'
<leonardr> depending in how serious you are about backward compatibility you will have to keep old code around
<leonardr> gary: i'm leaning towards just implementing a general @not_exported or @reset declaration, which i believe i was going to implement anyway
<leonardr> yes, it's @no_longer_exported
<gary_poster> leonardr: ok sounds good
<leonardr> gary: so you can use @no_longer_exported to stop it, and then if you want to be really crazy you can use @export_*_operation again to bring it back
<gary_poster> +1
<gary_poster> Is anyone around who can tell me how bzr-builder is supposed to be knit into the db-devel tree?
 * maxb knows nothing, but really hopes it's the same way as the other bzr plugins
<wgrant> gary_poster: Run update-sourcecode.
<wgrant> Before yesterday you would have needed to run it in db-devel, but the changes seem to have been pushed into devel yesterday as well.
<gary_poster> wgrant: yeah, I was the one who pushed them into devel to work around lameness in some of our test scripts.  what I actually need to know is how bzr-builder is supposed to find its way into optionalbzrplugins, because db-devel is failing, I've duped locally, and it is because bzr-plugins is not importable, and I can't figure out how it should have gotten into optionalbzrplugins, or the python path.  do you know?
<gary_poster> eh, should have been a period after "is failing."  Blame it, and other run-on constructions, on writing too fast :-)
<maxb> I thought it was in bzrplugins, not optionalbzrplugins?
<gary_poster> (to be clear, my two concrete observations are that I don't see it in optionalbzrplugins, though I assume it should be there; and it is not importable by lib/lp/soyuz/model/sourcepackagerecipedata.py during wadl generation)
<gary_poster> maxb: ah, yes, builder is in bzrplugins, and hg, git, and the like are in optionalbzrplugins
<mwhudson> builder should be in bzrplugins
<mwhudson> oh
<mwhudson> maybe you have to import lp.codehosting before you import it?
<mwhudson> goddamn import order dependencies
<gary_poster> mwhudson, ok will try :-/
<wgrant> Is buildbot happy now?
<gary_poster> wgrant, no it is sad
<gary_poster> mwhudson: no, did not solve
 * mwhudson actually looks at buildbot
<gary_poster> mwhudson: will try looking at python path before import...
<mwhudson> gary_poster: i think bzrlib.plugins.__path__ is also worth looking at
<gary_poster> mwhudson: ack, that would be more pertinent thanks
<gary_poster> disabling SHHH would help...
<gary_poster> ...sigh, or maybe not...
<mwhudson> gary_poster: 'make' in db-devel works for me, of course
<gary_poster> :-) of course
<gary_poster> mwhudson: here is the recipe that worked for me fwiw
<gary_poster> get db-devel
<mwhudson> though that's perhaps because i have bzr-builder installed in ~/.bazaar...
<gary_poster> oh, maybe
<mwhudson> nope
<gary_poster> ok, so to continue recipe, link-external-dependencies
<gary_poster> rm the symlinks to the new packages (bzr-hg and bzr-builder) in sourcecode
<gary_poster> run update-sourcecode-dependencies
<gary_poster> and, if you are me or buildbot, fail when you try to run make
 * mwhudson tries
<gary_poster> mwhudson (and any others): http://paste.ubuntu.com/359690/ shows sys.path followed by bzrlib.plugins.__path__
<mwhudson> bzrlib.errors.BzrError: xmlrpc protocol error connecting to https://xmlrpc.edge.launchpad.net/bazaar/: 302 Found
<mwhudson> yay hotel internet!
<gary_poster> mwhudson: so, bzrplugins/builder/ is empty for me
<mwhudson> !?
<gary_poster> it is also a real, not symlink
<gary_poster> hard
<gary_poster> I am guessing it should be a symlink?
<mwhudson> yes
<gary_poster> mwhudson, who was supposed to put it there?
<mwhudson> !?
<mwhudson> i _did_ put it there
<gary_poster> heh
<mwhudson> but it seems db-devel 8894 unsymlinked it
<gary_poster> oh!
<mwhudson> kind changed:
<mwhudson>   bzrplugins/builder@ (symlink => directory)
<gary_poster> mwhudson: I assume that should be a symlink to sourccode/bzr-builder?  Would you like me to do the honors?
<gary_poster> Or I can go have lunch :-)
<mwhudson> gary_poster: i would like to go and have breakfast, so if you could...
<gary_poster> mwhudson: sure.  Thanks so much for your help
<mwhudson> fwiw it was gmb in db-devel r8889.1.1 that done it
<gary_poster> yeah, I saw :-)
<mwhudson> i guess related to the general sourcecode confusion
<mwhudson> oh well
<gmb> gary_poster, mwhudson: sry.
<mwhudson> gmb: not to worry, at least it's easy to fix :)
<gmb> :)
<gary_poster> absolutely :-)
 * mwhudson goes to see if loggerhead explodes over the kind change
<mwhudson> hm, doesn't display it usefully, but at least it doesn't go bang
 * mwhudson breaks fast
<gary_poster> ok, not out of woods yet, fwiw
<gary_poster> Changing the symlink reveals the following
<gary_poster> http://paste.ubuntu.com/359700/
<gary_poster> of which the important bit is ImportError: No module named debian_bundle
<gary_poster> oh
<gary_poster> duh
<gary_poster> I bet I need to update my dependencies
<mwhudson> yes
<mwhudson> that's in python-debian which is depended on by launchpad-dependences 0.62
<gary_poster> yes, should have done that first, sorry
<mwhudson> np
<flacoste> so the failure was because of a bad merge conflict resolution i guess
<gary_poster> yeah
 * mwhudson really goes away
<gary_poster> :-)
<gary_poster> flacoste: actually, probably because gmb was trying to get things to work before devel had the sourcecode branches, and did so by mutating the tree
<gmb> Yep.
<bac> rockstar: hi, you're the only one from the asiapac reviewer meeting who's around, right?  what say we cancel this week?
<bac> gary_poster: do we have a build engineer this month?
<gary_poster> bac: no.  Considering canceling the program.  Maybe will ask for volunteers for next cycle, give it one more whirl, then discuss.
<bac> gary_poster: so your team would just pick it up?
<gary_poster> bac: yes.
<bac> gary_poster: ok.  i may hunt you down for a  pre-imp call for a fix i want to do to ec2 in my spare time.
<gary_poster> bac: cool
<jamalta> so is login_anonymously gone from launchpadlib?
<jamalta> i can't find it in help() and it tells me the method doesn't exist
<jamalta> or is it a new feature that isn't in the karmic version of launchpadlib?
<salgado> jamalta, it's brand new
<jamalta> salgado: ah ok, thanks
<dobey> how do i get a bug_target for a project, with launchpadlib? i don't see how in the +apidoc on edge
<wgrant> dobey: A project *is* a bug_target.
<dobey> ok, well i didn't know that, and it's in no way clear from the documentation that it is the case
<wgrant> "Examples include an IDistribution, an IDistroSeries and an IProduct.
<wgrant> "
<dobey> yes
<thumper> wgrant: perhaps it should say "examples include distributions, series, and projects"
<dobey> there are only vague insinuations that IProduct == "project" in other places in the doc. nothing concrete, or that makes me say "oh, a project, ok"
<dobey> thumper: indeed. i'm seeing lots of places where the docs could be clearer in that respect :)
<wgrant> Probably. A lot of Launchpad docstrings are awful.
<thumper> :)
<wgrant> Even moreso when exposed over the API.
<dobey> guess i'll file bugs about them
<thumper> dobey: DO IT!
<wgrant> thumper: Why does make run_all sometimes clobber my push branches?
<thumper> wgrant: I dunno
<thumper> look at the Makefile
<dobey> i will. have to file all these bugs to track my own work first, since i barely have enough time to get it all done by feature freeze :)
<jamalta> regarding, https://help.launchpad.net/API/launchpadlib
<dobey> thanks
<jamalta> you can't bzr branch lp:oauth
<jamalta> because it doesn't have a main branch
<thumper> jamalta: should it have?
<jamalta> thumper: well, the instructions in the wiki say to branch lp:oauth
<jamalta> but you can't
<thumper> I'm looking at it
<thumper> although I'm tempted to change the trunk branch to use bzr-svn
<jamalta> thumper: to pull from code.google.com?
<thumper> jamalta: yeah, currently the import is using cscvs
<thumper> but we'd have to change our launchpad branch if I did that
<thumper> I'll take it to the dev list
<jamalta> thumper: cool :)
<jamalta> also, it seems that lazr.restfulclient is broken (or my pull is)
<jamalta> it fails to import from lazr.restfulclient.authorize
<jamalta> http://paste.ubuntu.com/359738/
<wgrant> Can somebody please ec2 land https://code.edge.launchpad.net/~wgrant/launchpad/bug-507784/+merge/17722, since it looks like bigjools ran into issues last night?
<thumper> jamalta: email sent
<jamalta> thumper: thanks :)
<thumper> jamalta: are you on the launchpad dev list?
<jamalta> thumper: yeah
<thumper> ok
<jamalta> should i just report a bug for the lazr.restfulclient issue?
<thumper> jamalta: yep
<jamalta> thumper: thanks
<dobey> thumper: i think leah might have moved the "canonical" trunk for python-oauth to github now
<jml> eoasuheoasuheoauseoathisuaheosnideoasuhaei
<jml> !!!##!$$#@!#!$!$#@#!
<jml> I'm unhapppy.
<leonardr> gary: i think the next step is to start building multiversioned adapter classes for named operations
<gary_poster> leonardr: cool, sounds good
<leonardr> jml, why unhappiness?
<jml> because merging db-devel into my branch has 16 conflicts
<jml> even though I merged db-stable in yesterday and resolved about the same number of conflicts.
<wgrant> Morning jml.
<jml> it makes me very upset.
<wgrant> More criss-crosses?
<jml> wgrant, good morning
<jml> yes.
<jml> ok, down to ten with some smarter merging.
 * wgrant violates the mandatory community pre-imp call rule and puzzles over how to do rescueBuilderIfLost.
<gary_poster> heh
<wgrant> Can someone please ec2 land https://code.launchpad.net/~wgrant/launchpad/bug-507784/+merge/17722?
<wgrant>         channel = logging.StreamHandler(log.StdioOnnaStick())
<wgrant> Huh?
<jml> almost done
<jml> wgrant, what's the huh about?
<wgrant> jml: StdioOnnaStick
 * wgrant finds it.
<jml> it's a Twisted thing
<wgrant> I see.
<jml> on the whole, I think it's a better name than SourcePackageRecipeJobBuild
<wgrant> s/JobBuild/BuildJob/
<wgrant> But yes.
<wgrant> How bad were the conflicts?
<jml> wgrant, some of them were the same as the ones I fixed the other day
<wgrant> Fun.
<jml> wgrant, lots of them were because of your renames to stuff in my branch.
<wgrant> Ah :(
<mwhudson> darn it, --headless should just be the default for ec2 test
<jml> pain pain pain.
<mwhudson> jml: good morning
<jml> mwhudson, pain
<jml> zcml is such a terrible, terrible idea
<wgrant> Martian, Martian, Martian.
<mwhudson> jml: i see
<jml> someone added zcml declarations for the classes added in my branch in the same file but a different location
<ajmitch> jml: is zcml causing you a world of pain?
<BjornT> mwhudson: you know a lot about pdb and python. if i have a multithreaded app that is using 100% CPU, is there an easy way of seeing which thread is busiest, and what it is doing atm?
<mwhudson> BjornT: you can attach to it with gdb and wangle your way to a (python) stack trace
<BjornT> mwhudson: do you have time to show me how?
<mwhudson> if one thread is using 100% cpu, it's pretty likely to be the one that you get when you attach, i guess
<mwhudson> BjornT: even better, it's documented on wiki.c.c i think
<mwhudson> BjornT: https://wiki.canonical.com/InformationInfrastructure/OSA/LPHowTo/BacktraceFromCoredump
<mwhudson> BjornT: going offline for a bit now, biab
<BjornT> ok, let me try that
<BjornT> mwhudson: hmm, didn't work. when doing apply pystack, it complains with: No symbol "t_bootstrap" in current context
<wgrant> Arrrrgh massive doctests kill kill kill.
<jml> jelmer_, how do you feed testr failing stuff into ./bin/test
<jelmer_> wgrant: good morning to you too :-)
<jelmer_> jml: ./bin/test --subunit | testr load
<jml> the other way around
<jml> run the tests that just failed
<jelmer_> jml: Oh, I haven't done that
<jml> ok. me neither.
<jelmer_> I'm not aware of a way to do that yet
<wgrant> Morning jelmer_
<BjornT> mwhudson_: hmm, didn't work. when doing apply pystack, it complains with: No symbol "t_bootstrap" in current context
<mwhudson_> hm
<mwhudson_> that means threading isn't loaded
<mwhudson> BjornT: are you connecting to the right process?
<mwhudson> there's a bit of a forest in make check
<mwhudson> alternatively,,,
<mwhudson> BjornT: try this .gdbinit instead: http://pastebin.ubuntu.com/359793/
<BjornT> mwhudson: i think so. i'm running bin/test manually. i'm attaching to it with 'gdb /usr/bin/python2.5 $procid'
<mwhudson> BjornT: just gdb -p $pid should be enoough
<mwhudson> BjornT: i guess you can check which process is hogging the cpu in top...
<BjornT> mwhudson: right. i'm attaching to the process with 100% CPU. with the new .gdbinit i get this output, which i guess isn't expected: http://pastebin.ubuntu.com/359796/
<mwhudson> BjornT: which gdbinit is that with?
<BjornT> mwhudson: http://pastebin.ubuntu.com/359793/
<mwhudson> BjornT: try the one from the wiki page
<jml> what's the right way to make a distroarchseries?
<wgrant> jml: In a test?
<jml> wgrant, yeah.
<wgrant> jml: I think there's IDistroSeries.newArch
<jml> wgrant, thanks.
<wgrant> But normally we just use sample data.
<BjornT> mwhudson: with the one from the wiki page i get: http://pastebin.ubuntu.com/359798/
<wgrant> (yes, evil, but so is the Soyuz data model)
<mwhudson> BjornT: :(
<mwhudson> maybe it's a 2.4/2.5 difference or something
<mwhudson> BjornT: where are you?
<mwhudson> i can come and try to help in person after the talk
<jml> wgrant, the problem is that the test_recipebuilder tests no longer work now that processor info is used :)
<mwhudson> BjornT: oh
<mwhudson> BjornT: do you have python2.5-dbg installed?
 * jml pounds away
<wgrant> jml: Ah :(
<BjornT> mwhudson: i'm in the main auditorium now. although, i don't have that package installed... let me try installing that
<mwhudson> BjornT: i'm in renouf1 so it should be easy enough to meet up after the talks if needed
<mwhudson> although i'm running out of battery
<BjornT> mwhudson: ok. i'll try to grab you after the talks. installing python2.5-dbg mad things better, but still no information from pystack :(
<mwhudson> bah
<jml> is it too late to say "don't use threads"?
<mwhudson> jml: yes
<deryck> sinzui, ping
<mwhudson> BjornT: catch you in a bit
<mwhudson> enobatter
<jml> :( :(
<jml> mwhudson, str(self.build.recipe.builder_recipe) doesn't do what I thought it should do
<sinzui> hi deryck
<deryck> sinzui, so I have a failing registry test in a new branch for me, that I think we should remove...
<deryck> sinzui, see http://pastebin.ubuntu.com/359803/
<jml> all of these tests passed last week
<deryck> sinzui, the work flow is no longer supported because of my changes.  if a project doesn't use LP for bug tracking, there is only a message on the bugs page saying "you don't use LP for bug tracking, enable bug tracking here." type link
<deryck> sinzui, and this is well tested in the bugs tests.  so I think we should kill the bits I show you in the paste.  you okay with this?
<sinzui> deryck: great: I was writing that I think that test is a bogus exercise of a form
<deryck> sinzui, excellent.  thanks, sir!
<sinzui> deryck: the registry team will re-invent the set bug tracker forms in March as a part of our effort to improve drive-thru-registration
<deryck> sinzui, sounds good
<jml> lifeless, do you have any thoughts on making test selection better?
<jml> does anyone have any idea at all about this error? http://pastebin.ubuntu.com/359816/
#launchpad-dev 2010-01-21
<jml> lifeless, have you seen the recent T-I-P post?
<jml> lifeless, there's a python-ideas thread on introducing setUpClass to the stdlib
<mwhudson> jml: noooooooooooooooooooooooooooooooooooooooooooooooooooooo
<jml> yeah, I know.
<jml> I have to follow python-ideas now :(
<mwhudson> well
<mwhudson> isn't it basically a write-only mailing list?
<jml> yeah, but Michael Foord kind of likes the idea, from scanning.
<jml> http://article.gmane.org/gmane.comp.python.ideas/6715
<jml> I'm not sure how to actually reply.
<jml> since I'm not subscribed
<mwhudson> oh dear
<mwhudson> jml: maybe a small tactical nuclear weapon
 * mwhudson stabs the interwub
<lifeless> jml: I've seen it, no time to fire appropriate responses.
<lifeless> jml: the argument I'd present is that class is the wrong scope.
<jml> ok. replied.
<mwhudson> to python-ideas?
<wgrant> jml: Um, I'm getting that LocationProxy thing now.
<jml> mwhudson, yes
<jml> wgrant, change launchpad.Admin to zope.Public in the zcml (or merge my branch again)
<jml> wgrant, this is for adapters specifically
<wgrant> jml: Ew. OK.
<wgrant> jml: I suspect that this is symptomatic of a deeper issue, though...
<jml> wgrant, yes.
<jml> wgrant, BjornT understands
<wgrant> Ah, good.
<wgrant> So I'll fix that in my earlier branch, then.
<wgrant> Actually, I might as well just drop the permission entirely if it's in yours.
<jml> wgrant, yeah. it's probably worth merging mine in again.
<jml> does anyone know how I can use buildout to manage a library that includes Python stuff but is built with autotools?
<BjornT> jml: this might help: http://pypi.python.org/pypi/zc.recipe.cmmi
<jml> BjornT, thanks! there's also a bug filed on subunit https://bugs.edge.launchpad.net/subunit/+bug/499775
<mup> Bug #499775: build easy_install/pip installable packages at release time <subunit:Triaged> <https://launchpad.net/bugs/499775>
 * mwhudson has an impossible failure in his bzr-2.1c1 integration branch
<jml> :(
<wgrant> Do people get spammed if I create an in-progress MP?
<mwhudson> i think currently yes
<mwhudson> wgrant: why don't you ask halfway through thumper's talk, coming up next?
<mwhudson> :)
<wgrant> jml: Lots of conflicts merging from you :(
<jml> :(
<wgrant> jml: Want to review my hopefully final non-slave branch?
<jml> wgrant, sure.
<jml> wgrant, I've done the review (although not changed the status)
<wgrant> jml: OK, thanks. I don't have an email yet, oddly.
<jml> wgrant, let's see if we can get it approved before thumper's talk ends
<wgrant> ... where did you ask the questions?
<wgrant> I see no questions.
<jml> (I honestly can't believe that he chastised people for not having good cover letters!)
<jml> wgrant, via email
<wgrant> Ah, it's there now.
<lifeless> argh
<jml> lifeless, ?
<lifeless> p-i
<jml> BjornT, that recipe thing hurts my brain.
<rockstar> stub, hi, you around?
<stub> like a donut
<rockstar> stub, :)
<rockstar> stub, I accidentally landed a branch on devel that I wanted to land on db-devel instead (don't want it rolling to edge).  Can I have you rs to revert it on devel and re-land on db-devel?
<stub> Sure
<rockstar> stub, cheers.
<mrevell> Morning
<henninge> Hi all!
<henninge> I have updated the  launchpad-dependencies package in the launchpad ppa for karmic.
<henninge> https://dev.launchpad.net/LaunchpadPpa tells me that I should now copy it to the other series on +copy-packages.
<wgrant> Why is intltool a dependency now?
<henninge> never mind
<henninge> wgrant: for the automatic template generation code.
<wgrant> I suspected that.
<wgrant> But that's wrong, then.
<wgrant> intltool is run inside the chroot, on the slave.
<henninge> wgrant: oh
<wgrant> Not outside the chroot, on the master.
<henninge> wgrant: ah yes, but  the code has tests in the test suite.
<henninge> wgrant: I could not land my code so far because the test won't pass on ec2
<henninge> wgrant: what other option could I have?
<wgrant> Hmmm, I see.
<wgrant> I guess that's not too unreasonable, then.
<henninge> wgrant: maybe we need to add "lp-slave-dependencies" and "lp-test-dependencies" ?
<henninge> to get this more fine-grained
<henninge> btw, I managed to copy the ppa to all series now
<wgrant> It's not a slave dependency; the script needs to install it itself.
<wgrant> I think lp-test-dependencies' purpose is fulfilled by lp-dev-dependencies, but I'm not quite sure of that.
<henninge> wgrant: you mean that the ec2 test code pulls in lp-dev-dependencies?
<henninge> then I guess that would suffice
<wgrant> I believe so.
 * henninge wonders where to find that out.
<wgrant> ec2test images do, but I'm not sure about buildbot.
<stub> BjornT: So I'm creating a stub in scripts/page-performance-report.py which bootstraps code in pageperformancereport.py. Where should pageperformancereport.py live.
<wgrant> jml: That ec2 test seems to have fallen into an abyss. This time it hasn't landed or emailed.
<bigjools> wgrant: hey
<wgrant> bigjools: Hi.
<bigjools> what's up with not landing aaron's branch?
<wgrant> bigjools: You suggested that it shouldn't land until it's all been well tested on dogfood.
<wgrant> Which, AFAICT, it has not.
<wgrant> And it doesn't actually matter much whether the slave is merged...
<bigjools> ok
<bigjools> well it doesn't matter if it is, either, because it's rolled out separately
<wgrant> Right.
<bigjools> actually do you know if the 58~1 image had these changes in?
<bigjools> because these are 58~0
<bigjools> and I tested 58~1 on DF
<wgrant> 'these are'?
<wgrant> I think 58~1 contains the latest recipe changes.
<bigjools> these changes
<bigjools> so the MP has the changelog bumped to 58~0, so I am guessing I have tested that branch
<wgrant> So they are. I wonder if that last increment just didn't get committed.
<wgrant> Anyway, I need to sleep.
<bigjools> I don't see 58 in the committed code
<bigjools> it's up to 54
<bigjools> so who has ~1
<wgrant> https://code.edge.launchpad.net/~abentley/launchpad/build-recipe
 * wgrant 's internet connection is about to die.
<wgrant> That doens't have the ~1 changelog entry, but it is the latest code.
<bigjools> hmm ok
<bigjools> so wtf did the ~1 come from!
<beuno> good morning
<mars> morning beuno
<mars> BjornT, around?  Trying to investigate the windmill speed issue as well
<mars> BjornT, around yet?
<mars> or salgado?
<salgado> mars, ?
<mars> hi salgado.  Just looking through the css_combine makefile target, to look at removing Mochikit from the JS rollup
<mars> salgado, for excluding an individual file, I'm guessing an exception in buildout-templates/bin/combine-css.in, correct?
<salgado> mars, erm, you talking about css roll up or JS roll up?
<mars> salgado, nm, looking at the JS combination would help :)
<salgado> mars, just remove Mochikit.js from the jsbuild target in the Makefile
<mars> salgado, ah, I see, Mochikit.js is explicitly included in the Makefile, in the jsbuild step.  So excluding it there should kill it
<mars> ?
<mars> salgado, so I'll assume you agree :)
<salgado> heh
<Ursinha> Chex, gary_poster, rockstar, bigjools, sinzui, allenap: hi, are you able to join the prod. meeting that should happen in 30 minutes?
<sinzui> I am
<gary_poster> Ursinha: I am not
<Ursinha> gary_poster: do you have a replacement? :)
<gary_poster> Ursinha: not yet :-) I'll try to arrange one
<Ursinha> thanks gary_poster :)
<bigjools-afk> Ursinha: yep
<allenap> Ursinha: I'm sprinting, but I'll watch for pings, if that's okay?
<Ursinha> allenap: sure, thanks :)
<Ursinha> Chex, someone from foundations, jtv, rockstar, bigjools, sinzui, allenap: prod. meeting in 8 min. @ #launchpad-meeting
<rockstar> Has anyone done anything about the failed build on devel buildbot?
<Ursinha> Chex, someone from foundations, jtv, rockstar, bigjools, sinzui, allenap: prod. meeting now @ #launchpad-meeting
<Ursinha> s/jtv/henninge/ :)
<jtv> Ursinha: s/ indeed
<salgado> matsubara-afk, come back, dude, you've got a meeting to run. ;)
<salgado> Ursinha, is there a bug for https://lp-oops.canonical.com/oops.py/?oopsid=1479S1000 ?
<leonardr> gary: i just discovered something odd
<leonardr> i can use type() to define a class whose name contains invalid characters like periods
<gary_poster> not surprised :-) leonardr.  on call, though
<leonardr> gary: np, just thought i'd mention it
<allenap> Ursinha: gmb and I are creating a new job-based cronscript to calculate bug heat, and we wondered if we needed to give it a specific oops_prefix? It's set to none in schema-lazr.conf for now.
<Ursinha> salgado: I don't think so
<Ursinha> allenap: matsubara would be the best person to ask
<Ursinha> allenap: he's out today but might return later, I can ask him
<allenap> Ursinha: Thanks.
<Ursinha> allenap: no problem, sorry not being more helpful
<allenap> Ursinha: As far as I'm concerned, that's very helpful :)
<Ursinha> allenap: :) I meant now :)
<salgado> Ursinha, the typeerror OOPS is bug 403281
<mup> Bug #403281: public xmlrpc requests broken during read only period <oops> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/403281>
<salgado> it happened because mthaddon was testing the new read-only switch on staging
<Ursinha> salgado: oh, I see
<Ursinha> thanks for investigating
<salgado> np
<beuno-lunch> rockstar, ping
<beuno-lunch> re: upgrade icon
<rockstar> beuno-lunch, pong
<rockstar> beuno-lunch, I was gonna ping you about that, I swear.
<beuno-lunch> rockstar, the icon I had made before, wasn't *that* for upgrading a branch?
<beuno-lunch> or do I need to find better quality crack?
<rockstar> beuno-lunch, you told me it was for when a branch already had an upgrade in process.
 * beuno-lunch looks
<rockstar> beuno-lunch, I thought one with a red exclamation point where the green animated arrow is would be good.
<beuno-lunch> rockstar, I'm worried that something like that conveys that something is wrong
<beuno-lunch> like a warning
<rockstar> beuno-lunch, on another note, do you have balsamiq mockups for current pages?  Something I can build off of?
<beuno-lunch> and not hthe positive action of "Upgrade it!"
<rockstar> beuno-lunch, well, according to kiko, something is wrong.  The branch needs upgrading.
<rockstar> beuno-lunch, personally, I think a big red button would be the best.  "This branch is out of date and should be upgraded!"
<beuno-lunch> right
<beuno-lunch> so we can use the standard warning icon
<rockstar> "If you don't upgrade, we're going to come to your house and give you two slap."
<beuno-lunch> "This branch is using an old format. _Upgrade now_"
<rockstar> beuno-lunch, essactly.
<beuno-lunch> so no special icon for that, and use the current icon for "This branch is currently upgrading"
<beuno-lunch> rockstar, will branches be read-only while upgrading?
<rockstar> beuno-lunch, nope.
<beuno-lunch> rockstar, shouldn't they be?
<rockstar> beuno-lunch, nope, not according the mark.
<rockstar> beuno-lunch, this is the reason it's taken so long.
<beuno-lunch> ok, as long as people don't get into trouble for using it the the meantime
<beuno-lunch> so, we can decide wether to use the icon for "Upgrade now" or "Upgrading"
<rockstar> beuno-lunch, basically, it upgrades on the side, pulls in all the revisions that have been committed, and then replaces the branch.
<beuno-lunch> maybe upgrading is better, although it will be rarely seen
<rockstar> beuno-lunch, yes, and then, wherever we use the icon, we need another icon for the other.
<beuno-lunch> rockstar, I think we don't
<kfogel> beuno-lunch: see new screenshot at end of https://bugs.edge.launchpad.net/malone/+bug/506018 when you get a chance
<mup> Bug #506018: Need a "+patches" view: report lists patches attached to bugs. <story-patch-report> <Launchpad Bugs:In Progress by kfogel> <https://launchpad.net/bugs/506018>
<beuno-lunch> rockstar, in fact, we may not need any icon at all. We could use the standard warning and info icon
<rockstar> beuno-lunch, okay.  If we don't do you have a proposal?  I'm installing balsamiq right now to make a mockup.
<beuno-lunch> rockstar, as for balsamiq, in the balsamiq branch, I committed all the mockups I have
<rockstar> Where's the balsamiq branch?
<beuno-lunch> rockstar, I don't think I have mocked anything up
 * beuno-lunch looks for the branch and looks at kfogel's screenshot
<beuno-lunch> kfogel, I worry that it may be hard to click on the overlay
<beuno-lunch> is that actual code?
<kfogel> beuno-lunch: yeah, that's in our branch right now
<kfogel> beuno-lunch: may be hard to click on the link in the box?
<beuno-lunch> kfogel, it's an overlay, right?
<beuno-lunch> rockstar, https://code.edge.launchpad.net/~launchpad/launchpad/ui-wireframes
<kfogel> beuno-lunch: hey, one sec, we'll give you a live page you can play with, would that help?
<rockstar> beuno-lunch, great, thanks.
<beuno-lunch> kfogel, that would be awesome
<beuno-lunch> rockstar, feel free to commit to it
<rockstar> beuno-lunch, okay, will do.
<beuno-lunch> so we can all share  :)
<kfogel> beuno-lunch: does this load for you? http://www.red-bean.com/kfogel/canonical/patches-view-popup.html
<beuno-lunch> I'll check
<beuno-lunch> yes
<beuno-lunch> no CSS though
<beuno-lunch> so it breaks a lot  :)
<beuno-lunch> the CSS links to launchpad.dev
<kfogel> beuno-lunch: oh, heh, yeah.  is it useable?
<beuno-lunch> well, it is, but I can't tell if the overlay will work or not  :)
<kfogel> beuno-lunch: (start up a launchpad.dev instance?  you don't need it to be our branch, just to get the CSS loading)
<rockstar> beuno-lunch, in branch listings, should we also show a warning icon for out of date branches?
<beuno-lunch> kfogel, I'll try that. Did you add any CSS?
<beuno-lunch> rockstar, yes, but only for people who have permissions to upgrade it  :)
<kfogel> beuno-lunch: no, just some javascript in the page itself (which you should get via the page, of course)
<beuno-lunch> starting up an instance...
<kfogel> beuno-lunch: so, enjoying that lunch? :-)
<rockstar> beuno-lunch, okay.
<beuno-lunch> kfogel, it's looking good on the table
<beuno-lunch> tasty, but I can't say that for certain yet  :)
<beuno-lunch> making schema is slow
<kfogel> beuno-lunch: (there's a throughout-Launchpad problem whereby in a vertical list, a popup on one item blocks you from mousing down to the next row's item.  It happens on ~person/branches page too, for example.  It would be nice if the popup could pop up somewhere else other than the mouse pointer -- that's exactly the place where the popup is most likely to get in the way :-) ).
<beuno-lunch> kfogel, yeah, that's why I asked  :)
<beuno> I'll stop pretending I'm going to eat lunch
 * kfogel hopes we get to fix that bug in the default popup behavior
<kfogel> beuno: we can wait, go eat
<kfogel> beuno: it's not like we don't have other stuff to do.
<beuno> kfogel, I'd rather unblock you
<beuno> kfogel, it feels ok
<beuno> just add some padding between the borders of the bos and the content
<beuno> and, it comes up when hovering the row, not the link
<beuno> making it a bit suprising
<beuno> and it's not intuitive, so if we can think of something that points to there being information, cool. Otherwise, file a bug for the future  ;)
<kfogel> beuno: thanks.  what's a "bos", btw?
<kfogel> beuno: for pointing to there being information, I was thinking: let's put that patch band-aid icon to the right or left of the patch age, and do the popup only on the icon?
<beuno> s/bos/box
<kfogel> beuno: got it.  we've fixed that already by using class="listing"
<beuno> kfogel, I think that's a good idea. You can see that information on the page you click on anyway, so it's just a convinience thing to have the popup
<kfogel> beuno: based on Bryce's reactions, I think the popup may be a bit more than a convenience optimization.  The users are expected to have a very much scan-and-only-tentatively-dive-in kind of workflow.
<beuno> super
<beuno> this is great work kfogel
<kfogel> beuno: thank abel, sitting next to me :-)
 * beuno waves at abel
<leonardr> gary: the goal is in sight, i have one more zope problem i'd like to sort out with you when you have time
<gary_poster> leonardr: cool.  maybe on call soon?
<leonardr> whenever you're ready
<leonardr> it's code-intensive so i think starting out in irc would be better
<gary_poster> ok
<mrevell> night!
<leonardr> it's code-intensive so i think starting out in irc would be better
<dobey> is it me, or is launchpad having some issues right now?
<rockstar> mars, ping
<mars> hi rockstar
<rockstar> mars, where are we with the js issue?
<mars> rockstar, I am slicing the Mochikit code out of launchpad.js, with the intent on pulling the code in only on pages that need it
<rockstar> mars, is that going to land today?  I have a rather urgent branch that is being held up by this issue.
<mars> rockstar, need to figure out context, but I can work with you to figure this out
<mars> rockstar, so you can't land your branch because windmill will go nuts and block everything if you do?
<rockstar> mars, apparently, yes.
<mars> ok
<rockstar> mars, if I run the tests that fail on ec2, they fail locally.  However, if I run with -D, they all pass.
<mars> rockstar, two options: wait for me to finish excising Mochikit, or put your JS in a separate file that is not part of the rollup.  I  assume you are landing JS, correct?
<mars> eh?
<mars> rockstar, oh, a different issue from Bjorns then
<mars> rockstar, then lets work on your problem
<rockstar> mars, no, I think it's the exact same issue.
<rockstar> thumper and I were working on parallel branches, and we both saw the problem at the same time.
<mars> rockstar, can you successfully run the windmill tests in trunk?  or a subset of them?
<rockstar> mars, yes.
<mars> interesting
<mars> rockstar, do a subset of the tests, such as a single test, fail?
<rockstar> mars, in my branch?  Yes.
<rockstar> Unless I run with -D, in which case it passes swimmingly.
<mars> rockstar, and they fail locally?  Tim and Bjorn can both run them fine locally.
<mars> afaik
<rockstar> I think it's all fishy.
<mars> lol
<mars> ok
<rockstar> mars, technically, the tests SHOULD pass, as they pass if I work through them interactively.  The functionality is fine, windmill just pukes.
<rockstar> Nothing's technically broken.
<rockstar> ...'cept Windmill's ability to find out if it's broken.
<mars> why would *any* test you run on your system fail?
<mars> rockstar, do they fail because of... what?
<mars> please elaborate
<rockstar> mars, I can't.  Windmill is just weird.
<rockstar> I don't know why Windmill thinks they fail.  I am 99% sure this is the same issue that Bjorn and thumper are seeing.
<mars> rockstar, do the individual test assertions time out?
<rockstar> mars, I guess.  It waits for elements that I can see show up, but it just decides they aren't there.
<rockstar> And it spikes my CPU.
<mars> ok
<mars> rockstar, if it is the same issue as Bjorn and Tim, then the workarounds I proposed still stand
<rockstar> mars, yes, but the workarounds aren't too much of an option, since I'm editing a file already in the rollup.
<mars> rockstar, what is the scope of the code? Page, App, or Core?
<mars> the scope of the code you added
<rockstar> Page.  Branch merge proposal page specifically.
<beuno> intellectronica, by any chance, is there any log of the people who say me too?  dates they clicked?
<wgrant> bigjools: I presume that the ~1 changelog entry is an uncommitted change on abentley's laptop.
<mars> rockstar, then if you have to land it ASAP, you can probably split out the code you added into a new, non-rollup module.  Or, you could include it inline on the page itself.
<mars> rockstar, the latter option works very well in a pinch
<rockstar> mars, so can I pull it out of the existing rollup, and how do I go about that?
<mars> rockstar, I assume you have a diff
<mars> since you changed something to trigger this bug :)
<rockstar> mars, yes, lemme find it.
<bigjools> wgrant: it could also be a version bump after we'd already installled ~0 as I remember them wanting to poke a tweak in
<wgrant> bigjools: Possibly.
<wgrant> Hmm, I think all the necessary master code is now in db-devel.
 * wgrant tries a recipe build on that.
<bigjools> dogfood is pretty much up to date as well
<bigjools> I can try and poke something in there
<rockstar> mars, https://code.edge.launchpad.net/~rockstar/launchpad/update-review-table-on-comment/+merge/17439
<wgrant> bigjools: Does it have a local codehosting setup?
<wgrant> I don't think it does.
<bigjools> anyone here use a Logitech Harmony remote and got the software running in wine?
<mars> rockstar, so comment.js is core: but this functionality in particular is only used on the MP page?
<bigjools> wgrant: why does it need that?
<bigjools> it can pull from staging
<wgrant> bigjools: Well, it references branches in the DB.
<bigjools> oh.  cock.
<rockstar> mars, well, the one line in comment.js needs to be there.  The other stuff should be moved to a lp-code javascript space.
<bigjools> bb in 10m
<mars> rockstar, is anything in comment.js used anywhere else?
<mars> ah ha!  lp.CodeReviewComment!  So I assume "no"? :)
<rockstar> mars, I think the bug comments use it as well.
<mars> rockstar, ok
<wgrant> Hm, what did I break in db_lp?
<mars> rockstar, this is a simple refactoring then: extract lp.CodeReviewComment to a new module.
<mars> rockstar, that new module should not be part of the rollup by default.
<rockstar> mars, where's the rollup code?  This has all seemed like magic to me.
<mars> rockstar, don't worry about minification or any of that junk if you want it to land.  Just refactor, test, and go.
<rockstar> mars, so I create a js file and then include it in the bmp page itself, and not in the main template.  Is that correct?
<EdwinGrubbs> sinzui: ping
<mars> rockstar, ah, wait a minute, looking at the rollup code: Makefile:124
<sinzui> Hi EdwinGrubbs
<mars> rockstar, confused: why is there an '-s' argument, and then a bunch of positional args...
<rockstar> mars, hellifiknow.  I don't know how this stuff works.
<mars> rockstar,  maybe '-s' is "grab everything", and the positional args are cherry-picked files?
<mars> rockstar, just thinking out loud.  mumbling doesn't work so well in text-based mediums...
<rockstar> mars, no, I see what you're saying.
<rockstar> mars, I always just thought that I put a js file in the folder, it gets rolled up.  Apparently, that was a correct assertion.
<mars> ok
<mars> so.. hm
<mars> rockstar, jsbuild takes a '-x' option....
<rockstar> mars, yeah, I saw that.  I should probably add an XXX comment.
<mars> rockstar, so refactor to extract the module, then use the -x option on it.
<mars> rockstar, first test the -x option with something benign, see if it does what you need
<mars> rockstar, pick any JS file in the rollup that you don't need on your MP page, pass it through -x, see that it is excluded.  Then run windmill on one previously failing test: the new, smaller rollup should pass, right?
<rockstar> mars, I'll go on an adventure.
<mars> rockstar, if it isn't too much bother, could you please try the fix first?  :)
<rockstar> mars, that's the adventure.
<bigjools> wgrant: so since DF is a copy of production from just before Christmas, it will have branches in the DB
<beuno> I love seeing the patch icon in bugs
<beuno> it's so much clearer now
<sinzui> damn. This stupid last bread crumb bug is killing my test
<wgrant> bigjools: I wonder how the config is set up, though.
 * wgrant checks.
<wgrant> Hm, it might just work.
<wgrant> It looks like it doesn't override the production codehosting URLs.
<wgrant> So lp: URLs in recipes should Just Work.
<intellectronica> beuno: i'm not sure i understand exactly what you're looking for. we don't save the dates in the db but i suppose we could mine it from the web logs if we really want
<beuno> intellectronica, dates on the db
<beuno> there's a bug someone filed and I commented on
<beuno> sinzui triaged it
<sinzui> I am sure it is on the first page of malone bugs
<lifeless> jml: the setUpClass discussion is making me sad
<bigjools> wgrant: when you tested copying private<->ppa copies did you select source only?
<wgrant> bigjools: I tried both, I think.
 * wgrant tries agao.
<wgrant> s/o/in/
<bigjools> wgrant: the original problem was when the guy selected rebuild
<bigjools> dunno if that's a coincidence
<wgrant> bigjools: The target was ~ubuntuone/ppa?
 * bigjools plays hunt the oops
<wgrant> ~ubuntuone/beta, sorry.
 * bigjools fails
<bigjools> I think it was from memory
<jml> lifeless, :(
<jml> wgrant, your revision looks like 8903
<wgrant> Although I guess you probably had to destroy the history to fix the publisher.
<jml> bigjools, hi
<wgrant> jml: Yeah, it landed 20 minutes after I asked. Very, very late.
<jml> wgrant, late how, I wonder.
<wgrant> ~5.5 hours after you kicked it off.
<wgrant> And it doesn't look like it was stuck in the queue, unless PQM was landing to something other than (db-)devel
<mars> rockstar, let me know if you have any luck with the refactoring
<jml> wgrant, that's about the same time as the other one.
<intellectronica> beuno, sinzui: yeah, saw the bug. i have no opinion about this right now, and i'll defer to deryck to decide how to triage and schedule it, but no, we don't have that now
<bigjools> jml: hi - I'm not really here
<jml> maybe the test suite has become three hours longer :(
<jml> bigjools, hi
<jml> bigjools, I guess this means I'm not going to be able to land the branch before the week 4 freeze
<bigjools> wassup?
<bigjools> meh, it's friday
<bigjools> there
 * deryck looks at the bug intellectronica beuno and sinzui are discussing....
 * wgrant looks at bug #507751 and wonders if we can slip that in.
<mup> Bug #507751: New ISourcePackageRecipeBuild fields <wellington> <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/507751>
<sinzui> I marked it low because it is not essential to linking ubuntu to upstream. It is somewhat on topic though. The model change is a deterrent from classifying it as trivial and giving it a bump in priority
<sinzui> ^ deryck, intellectronica, beuno
<deryck> sinzui, right
<deryck> sinzui, beuno -- I also wonder if we really want this, or if heat is an indication of last affected time?  Tangentially it is, I realize, but I wonder if that isn't good enough?
<deryck> intellectronica, see my suggestion/question above, too. ^^
<intellectronica> yes, i also can't see that it's very useful and would rather weigh age into heat instead
<sinzui> beuno: I just fixed the last item in the breadcrumbs is linked bug. It would have been fixed 6 months ago if I understood that it was trivial.
<beuno> deryck, I think heat may help, but it's hard to tell "since my last release"
<beuno> sinzui, woooooo!
<beuno> which one?
<sinzui> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/83613 and https://bugs.edge.launchpad.net/launchpad-foundations/+bug/480473
<mup> Bug #83613: last breadcrumb item shouldn't be a link if you're there already <locationbar> <ui> <Launchpad Foundations:In Progress by sinzui> <https://launchpad.net/bugs/83613>
<mup> Bug #480473: Breadcrumb underlines include trailing whitespace <post-3-ui-cleanup> <Launchpad Foundations:In Progress by sinzui> <https://launchpad.net/bugs/480473>
<jml> gror batteries :(
<deryck> beuno, I don't disagree that it's nice to know.  Just wondering if the heat indication is enough.
<deryck> beuno, do you have a UI idea for how to expose the info?
<sinzui> beuno: My test was broken by presence of a pointless link. The bug had to be fixed to satisfy my test-sensibilities
 * deryck has to go.... phone.... sorry
<beuno> deryck, I think it's not enough, no.  I'd show it in the activity log.
<lifeless> jml: what patch can't you land?
<jml> lifeless, huh?
<deryck> beuno, ok, can you update the bug with that recommendation, i.e. activity log?  And we'll schedule it during bug Q&A, where it kind of makes sense, I think.
<lifeless> 07:16 < jml> bigjools, I guess this means I'm not going to be able to land the branch before the week 4 freeze
<lifeless> jml: I'm just being curious
<jml> lifeless, bigjools just reviewed a branch of mine that I submitted last week, and he needs an answer before it lands
<jml> lifeless, I won't be able to reply for the next couple of hours
<beuno> deryck, yes, thank you
<bigjools> jml: can you reply today and I'll get to it in an hour or so
 * bigjools brb
<jml> lifeless, thanks. but my laptop is almost dead.
<EdwinGrubbs2> sinzui: sorry I didn't see your reply earlier. It seems like I can make most of the tests for +addpackage work with +ubuntupkg except where packagings are created for non-ubuntu distributions. Is there any other reason to keep PackagingAddView around?
<sinzui> I can think of one case...
<sinzui> EdwinGrubbs That view is the only view that allows someone to specify the INCUDES type of packaging. Ubuntu does not care about it, so I am think we can really ignore it
<sinzui> EdwinGrubbs2: If my assumption is wrong, we can resurrect the Packaging field as an advanced option on the ubuntu form.
<EdwinGrubbs2> sinzui: I can probably get it into review in about an hour. Do you want to look at my current changes or review it later? I can always ask rockstar, who owes me.
<sinzui> EdwinGrubbsI will be happy to review it
<sinzui> maybe we can trade, I am putting the second branch of my +needs-packaging view into review
<mars> wow. rockstar, you were right, it /does/ spike the CPU.  But on my dual-core system, the tests can still pass I guess.
<mars> rockstar, tried unbundling MochiKit, and the CPU usage is much lower.
<rockstar> mars, I'm an dual and quad core systems.  I suspect there's a timing issue.
<rockstar> mars, why do we still need mochikit?
<mars> when I pulled a test run into the debugger I found the majority of time was spent spinning on socket.read
<mars> rockstar, a bit of code in Bugs mostly
<mars> old code
<mars> and some in Translations
<rockstar> mars, yea, socket issues are hard to track down.
<rockstar> mars, maybe we need to set a higher priority on getting rid of Mochikit entirely?
<mars> at least, the JS was for Translations.  The original integration point could be dead now.
<beuno> KILL MOCHIKIT
<mars> rockstar, if you want to give it a shot, merge this branch: lp:~mars/launchpad/unroll-mochikit
<rockstar> mars, okay, I'll see what happens.
<mars> beuno, we're getting there, don't worry :)
<mars> we just needed a gentle stab in the back to get moving
<rockstar> mars, I think this is as good as any stab in the back.
<rockstar> I bet all the MochiKit code is untested anyway.
<jml> hi
<mars> hi jml
<mwhudson> jml: good morning
<mwhudson> jml: apologies for the incoherent text messages last night
<rockstar> mwhudson, are you working today?
<jml> mwhudson, I didn't notice any incoherence :)
<mwhudson> jml: there may be several non-mutually exclusive reasons for that :-)
<jml> mwhudson, heh heh
<mwhudson> jml: it would be hard for me to have given sensible directions in any case -- i'm not sure i could find my way back :-)
<jml> :D
<mwhudson> rockstar: well, it's the last day of LCA, so "sort of"
<mwhudson> right, /me --> talk
<rockstar> mwhudson, just wondering.  I didn't expect anyone to be around today.
<lifeless> Ã¥aa
<Ursinha> sinzui: I see that the updated file is in https://devpad.canonical.com/~lpqateam/burndown/test-plan-report-10.01.html
<Ursinha> sinzui: the script that runs in cron generates them in there
<mwhudson> bah, still at "14 failures, 72 errors" for the bzr upgrade :/
<sinzui> Ursinha: I see that the numbers are correct now
<Ursinha> sinzui: in devpad.canonical they are, but not in people.canonical
<sinzui> Ursinha: I did not see my untested items for two days and assumed the script was broken by the move from rookery
<Ursinha> sinzui: oh, I see
<sinzui> Ursinha: I link to the people.canonical.com pages so that users can see the milestone QA progress from all the projects I am managing
<Ursinha> sinzui: got it
<sinzui> Oh, that is the reason, the server moved
<Ursinha> :)
<rockstar> Is anyone working on a fix for db-devel's buildbot failure?
<wgrant> What is the failure?
<wgrant> I seem to be the only one to blame.
<rockstar> test_min_time_to_next_builder (lp.soyuz.tests.test_buildqueue.TestMinTimeToNextBuilderMulti)
<wgrant> Full exception?
<mwhudson> hmmm
 * mwhudson thinks his emacs is failing to do the right thing with branches made with --hardlinks
<rockstar> wgrant, http://pastebin.ubuntu.com/360283/
<jml> mwhudson, yeah, mine was for a while -- stopped using hardlinks
<mwhudson> hm
 * mwhudson stops
<wgrant> Hmmm.
<rockstar> Ursinha, where are the test plans being held now?  I don't see them on the wiki.
<Ursinha> rockstar: they're in the same place, I guess
<rockstar> Ursinha, I looked.  They aren't there.
<rockstar> Ursinha, oh, they're labled 10.01, which threw me off.
<Ursinha> rockstar: https://dev.launchpad.net/CodeTeamTestPlans/
<Ursinha> rockstar: yeah, according to the name of this cycle we're at the moment :)
<rockstar> Ursinha, yeah, it didn't match my mental heuristics of what I would have thought this cycle was called.
<wgrant> I cannot reproduce that db_lp failure.
<mars> rockstar, any luck?
<rockstar> mars, still running tests.
<mars> ok
<intellectronica> i can't seem to reproduce it either
<wgrant> My branches didn't really touch that area, either.
<mwhudson> timing dependent?
<mars> rockstar, so you may be interested to know that LP has 380 lines of Mochikit-dependent JS.  But a fair bit of it is overlapping functionality: 3 ways to do it, instead of one :(
<sinzui> I was thinking the problem was timing dependant
<mars> rockstar, so there are two issues there: rewrite to YUI, and have 3 ways to do it in YUI
<wgrant> mwhudson: Actually, it's possible.
<wgrant> IIRC 2min is the time we use when a build has exceeded its estimated duration.
<mars> rockstar, and then pull together the 3 ways to do it into one function in the LP JavaScript core.
<mwhudson> biab
<rockstar> mars, well, however it gets done, it just needs to get done.
<mars> yep, that's why it should be in 2 steps - bite-sized chunks
<rockstar> mwhudson ported all the Mochikit in loggerhead to yui-3 quite quickly.
<jml> I'd like to change Launchpad to depend on subunit trunk
<jml> but subunit trunk has an incompatible repository format to the subunit fork that we're using.
<mars> jml, I thought you are subunit core contributor? can't you bend the project's CM system to something more compatible?
<jml> mars, no.
<jml> mars, we're doing it right. Launchpad's fork is doing it wrong.
<mars> jml, so why can't we change Launchpad?
<jml> mars, I don't know how.
<mars> that is an excellent reason
<jml> I think maybe I can get away wit hit by hacking the update-sourcecode script to detect incompatible repo errors and just blow the old branch away
<jml> but I don't know if that will fly in production.
<intellectronica> is it time to force the buildbot out of testfix mode? several devs can't reproduce the problem, and we've got heaps of branches to land
<wgrant> +1. I don't see how my change could have broken anything, and it hasn't happened before.
<intellectronica> oright, forced a build
<jml> lunch plans?
<mwhudson> well, i've just had breakfast :)
<spm> mwhudson: sounds like you'd be ready for lunch then!
<mwhudson> heh heh
<rockstar> mars, I'm just going to merge your branch and submit through ec2 - The Windmill tests take for freaking ever.
#launchpad-dev 2010-01-22
<jml> mwhudson_, you around?
<mwhudson_> jml: yeah
<jml> mwhudson_, I'd like to bounce an idea off you
<mwhudson_> jml: listening to rusty be silly
<mwhudson_> jml: ok
<jml> mwhudson_, I want to make launchpad use subunit trunk
<jml> mwhudson_, but it's in 2a and ours is in 1.6 or something
<mwhudson_> jml: gragh
<jml> mwhudson_, if I make update-sourcecode just blow away old versions in the case of format errors?
<mwhudson_> jml: talk to spm i guess
<jml> mwhudson_, will that work on production?
<jml> or will I need to talk to spm
<jml> hmm.
<spm> jml: ?
<jml> spm,  I want to make launchpad use subunit trunk
<mwhudson_> spm: i think deployment doesn't use update-sourcecode
<jml> spm, but it's in 2a and ours is in 1.6 or something
<jml> spm, which means a simple 'pull' won't work.
<spm> oh yukness
<spm> yeah...
<jml> (thanks bzr!)
<jml> spm, so what should I do?
<spm> jml: how urgent is this? ie MUST be in the release next week?
<jml> spm, no, it's entirely optional.
<spm> jml: oki; I'd submit an RT asking for the branch we use to be upgraded RSN, such that when you push - stuff should "just work"; tho it'd be nice is bzr did that for us automagically (dig dig dig)
<spm> we may need to verify what/where that branch is etc. but that's details you don't need to worry about.
<jml> spm, well, I'd also like us to use a different branch. I'm not entirely sure why we have our own pqm-managed fork of subunit anyway
<spm> Ah. that gets mildly more complicated - will need to config-manager update - you should be able to fix that one yourself. the branch in Q is open to ya'll
<spm> well - partially fix - we still need to fix our local copy of.
<jml> hmm. hmm. hmm.
<jml> this is all too hard.
<spm> welcome to our world! :-)
<jml> I'm going to trick gary into walking me through making this an egg.
<mwhudson_> why is that hard?
<jml> mwhudson_, subunit uses autotools!
<jml> yay
<mwhudson_> oh riiiiiiiiiight
<mwhudson_> yay indeed
<spm> ??? why is that hard? isn't the idea of autotools to make this stuff easy?
<wgrant> jml: Do you think we can reasonably get bug #507751 done this release?
<mup> Bug #507751: New ISourcePackageRecipeBuild fields <wellington> <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/507751>
<wgrant> spm: Not for making eggs...
<jml> spm, and the idea of eggs is that they also make this stuff easy
<jml> spm, but in a completely different way!
<spm> oh yay. more wheel reinventions. lovely.
<ajmitch> only the tip of the iceberg
<jml> wgrant, I'm not going to do it.
<jml> wgrant, but there's probably time if someone were keen. :)
<wgrant> jml: It's trivial except for the contention around SourcePackageRecipeBuildJobUpload.
<wgrant> bigjools thinks that it should exist.
<wgrant> I don't think anybody else does.
<jml> wgrant, well, I'm basically reserving my opinions until I can see the whole thing.
<wgrant> jml: What whole thing?
<jml> wgrant, "building stuff on the build farm"
<jml> wgrant, that thing. :)
<wgrant> An explanation of everything?
<jml> wgrant, yeah, but more just having the whole thing in my head. (which probably is going to require me writing a doc).
<wgrant> Possibly.
<wgrant> But it would be nice to not have to land everything on db-devel next cycle.
<jml> wgrant, sure. so just do things the way bigjools says, and then we can fix it the cycle after next  :)
<wgrant> It's unclear how the bigjools model is meant to work.
<jml> wgrant, ahh, I see.
<wgrant> Basically, we currently don't use the SPRBJUpload at all. It is there so you can upload the result of one build to multiple archives.
<wgrant> Rather than copying from one archive to the rest.
<jml> oh right.
<wgrant> It is not clear that uploading it to multiple places is going to work, has many useful applications, or is better than copying.
<wgrant> It's also much harder, both UI- and code-wise.
<jml> indeed.
<jml> OK, I'm going to call yagni on this.
<jml> let's worry about SPRBJUpload when we have a use-case
<wgrant> Right.
<wgrant> We can easily migrate to it later if we need.
<jml> yeah.
 * wgrant JFDIs.
<mwhudson> heh
<mwhudson> i tried to call yagni way back when
<jml> mwhudson, sorry, I should have listened harder.
<mwhudson> np
<jml> hmm.
<jml> can I somehow get subunit trunk into pack-0.92 so I can just pqm-submit this change?
<wgrant> Doesn't the rich root barrier make that impossible?
<jml> yeah, it looks like it
<wgrant> Hmm, I see that process-upload.py doesn't actually link the produced SourcePackageRelease to the SourcePackageRecipeBuild :(
<jml> huh what?
<jml> that sucks.
<wgrant> It's unclear how that would best be done (link on the PackageUpload, or the PackageUploadSoure, or the SPRelease, or the SPRB).
<wgrant> But that can be fixed laaaater.
<wgrant> mwhudson: Do you happen to know why SourcePackageRecipeData has a reference back to SourcePackageRecipe, rather than the other way around?
<jml> wgrant, what are the issues?
<mwhudson> sourcepackagerelease has a sourcepackagebuild column now
<wgrant> jml: Nothing. It just seems like a very strange way of doing things.
<mwhudson> wgrant: you can write more useful constraints that way around
<wgrant> mwhudson: Oh, so it does.
<jml> oh sorry, I must have missed something
<jml> carry on.
<mwhudson> (stub made me do it)
<wgrant> mwhudson: OK.
<jml> wgrant, I'm looking at ec2test-remote.py
<jml> wgrant, which is the thing that would have to be screwing up in order for the emails to not be sent.
<wgrant> jml: You didn't get an email for this one either?
<jml> wgrant, which one?
<jml> wgrant, I'm looking at the code trying to make it attach a subunit log to the mails it sends.
<wgrant> jml: The one that landed late last night.
<jml> wgrant, no, I didn't.
<wgrant> Aha.
<wgrant> jml: There are conflicts between your branch and db-devel again.
<jml> fuck
<wgrant> And you should probably revert the move of BuildBase.build_log_url
<jml> why
<wgrant> Because it is really implemented on BuildBase now.
<wgrant> (and it will be used by view code RSN)
<jml> wgrant, ok.
<jml> I'm very angry that the delay in reviewing my branch has caused me to do all of this work that would have been unnecessary were it reviewed promptly.
<jml> Sadly, I don't think I can fairly direct this anger to any one person.
<jml> (or even any set of people)
<mwhudson> it's society that's to blame!
<rockstar> mwhudson, do you have a second?
<mwhudson> rockstar: yes
<rockstar> mwhudson, this is my test: http://pastebin.ubuntu.com/360426/
<mwhudson> rockstar: ok
 * wgrant finds more gaps in the implementation.
<rockstar> The only change that has occurred is the contextManager calling get_scanner_server instead of get_multi_server - When I create the branch and pdb into it, it reports as lp-mirrored:///blah but when I actually try and run the job, I get an NotABranch oops.
<rockstar> mwhudson, I'm not sure where the disconnect is.
<mwhudson> rockstar: which url does the BranchScanJob try to open?
<rockstar> mwhudson, I'm assuming the lp-mirrored one, since that's what oopses on the NotABranch error.
<mwhudson> hm
<rockstar> The BranchScanJob basically just instantiates a BzrSync instance with the db branch instance as it's only argument.
<mwhudson> oh
<mwhudson> i have memories of terrible things marching out of my hind brain
<rockstar> mwhudson, that makes me sad.
<mwhudson> rockstar: can you check config.codehosting.internal_branch_by_id_root in the test?
<rockstar> Sure, one sec.
<mwhudson> rockstar: i think it will be file:///var/tmp/bzrsync/
<rockstar> mwhudson, yeah, I seem to remember seeing an error like that as well.
<rockstar> file:///var/tmp/bzrsync/
<mwhudson> rockstar: try changing it to file:///var/tmp/bazaar.launchpad.dev/mirrors ?
<rockstar> mwhudson, this is where I do the config pushing stuff, right?
<mwhudson> rockstar: i'd just change it in lib/configs/testrunner/launchpad-lazr.conf
<rockstar> mwhudson, okay.
<rockstar> mwhudson, that worked.
<mwhudson> rockstar: yay
<rockstar> I have no idea why it worked, but it did.
<mwhudson> rockstar: oh
<mwhudson> rockstar: i can explain the details i guess, but then you'll want to kill yourself
<mwhudson> rockstar: run the lp.codehosting.test.test_rewrite tests, they might need updating
<rockstar> mwhudson, okay.
<rockstar> mwhudson, so is this a permanent config change?
<mwhudson> rockstar: i think it causes a small decrease in overall insanity
<rockstar> mwhudson, okay.
<nigel_nb> barry, ping
<nigel_nb> I'm looking for some guidance with launchpadlib with regard to connecting the subscribers/commentors of a bug with the bug
<nigel_nb> flacoste, got a minute?
* henninge changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 3 of 10.01 | PQM is open | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | Channel logs: http://irclogs.ubuntu.com/
<mrevell> hi
<nigel_nb> hi mrevell
<nigel_nb> mrevell, do you have a min? I have a doubt in launchpad lib
<mrevell> Hi nigel_nb, I'm probably not the best person to help with launchpad_lib. But let's talk and, if I can't help directly, I'll find someone who can :)
<nigel_nb> mrevell, I have been struggling for the past 3 hours
<nigel_nb> I'm trying to build a script that will list all the bugs that I have commented or subscribed and are incomplete
<nigel_nb> I have a sort of beginning point here http://paste.ubuntu.com/360520/
<nigel_nb> I dont know how to search all ubuntu bugs, i.e., all bugs in a distribution
<nigel_nb> I've been playing with launchpad.distributions['ubuntu'].searchTasks
<nigel_nb> but it just prints and object and I dont know how to actually perform a search... any clue?
<wgrant> launchpad.distributions['ubuntu'].searchTasks(bug_subscriber=launchpad.me, status='Incomplete')
<nigel_nb> wgrant, thank you!
<wgrant> Actually, you might need status=['Incomplete'], but one of those should work.
<nigel_nb> so how does searchtasks work?
<nigel_nb> you use ( bracks and then sub-criteria inside '['?
<bigjools> jml: still there?
<wgrant> bigjools: He's probably still at the Penguin Dinner or associated events.
<wgrant> nigel_nb: The parentheses are just Python function call syntax.
 * bigjools boggles at what a penguin dinner could be
<wgrant> bigjools: The final dinner for professional LCA delegates.
<bigjools> ah so they're not eating penguins
<wgrant> Sadly not.
<nigel_nb> wgrant, oh okay.  I've ben wondering how to pass args to searchTasks :)
 * nigel_nb high fi's wgrant :)
<wgrant> bigjools: Do you still feel strongly that we want SPRBUpload?
<bigjools> yes
<wgrant> Argh.
<wgrant> I discussed it with jml earlier.
<wgrant> And he seems to think that we don't.
<bigjools> it has parallels with PackageUpload
<wgrant> Why do we want that?
<wgrant> Binaries have nothing like it.
<bigjools> PackageUploadBuild ...
<wgrant> And PackageUploadSource.
<wgrant> PackageUpload(Build|Source) just tie things together.
<wgrant> They serve a different purpose from SPRBU
<bigjools> true
<bigjools> but I want it to stay
<bigjools> because from experience I just know that in the future we'll be doing more with this stuff
<wgrant> Why would we ever want to do that rather than copy?
<wgrant> You say that copying is bad, but I haven't seen a concrete reason.
<bigjools> I didn't say that at all
<bigjools> I said I wanted to retain options
<wgrant> Hmmm.
<wgrant> Have you ever had a similar need for binary uploads to multiple places?
<wgrant> What do SPRBUs mean?
<wgrant> How on earth does this make it into the UI?
<wgrant> Isn't it going to be easier to split the data out later rather than try to badly wire in this ill-defined concept now?
<bigjools> uploading is an orthogonal action to building, conflating the two in the model is ridiculous
<bigjools> and not everything needs a direct UI mapping
<wgrant> It's barely orthogonal.
<wgrant> A build finishes by uploading.
<wgrant> There is no such thing as a non-volatile un-uploaded build result.
<wgrant> The upload is represented by the PackageUpload.
<bigjools> wgrant: so explain to me what the problem is right now with having the table?
<wgrant> bigjools: We must either start using it now, and therefore work out what it actually means, or we need to put some of its columns on SPRB.
<bigjools> so there's no problem as such, it's a philosophical issue?
<wgrant> It is a problem, in that the code needs one of those solutions nowish. The second solution will probably not be accepted whilst SPRBU still exists, and the first means working an over-complicated data model into code that cannot handle it and probably never will.
<bigjools> "over-complicated data model" is an opinion.  Why "code that cannot handle it" ?
<wgrant> There has been no use-case given for this model, AFAICT. The code will need quite some work to support uploading to multiple places.
<wgrant> And the migration from the everything-in-SPRB model to the SPRBU model is near-trivial, if somebody eventually desires to implement it.
<wgrant> So involving SPRBU is probably unnecessary complexity.
<bigjools> well there is a use case :)
<wgrant> Is there?
<bigjools> bug 235064 to some extent and bug 245594
<mup> Bug #235064: Implement multi-release support for packages <ppa> <soyuz-upload> <Soyuz:Triaged by cprov> <https://launchpad.net/bugs/235064>
<mup> Bug #245594: Rebuilds of binary packages without source changes <feature> <motu> <Soyuz:Triaged> <https://launchpad.net/bugs/245594>
<bigjools> it's not a complete solution but it would be one way
<bigjools> however
<wgrant> I don't think that's a reasonable solution (even partial) to either.
<bigjools> it's not a solution
<bigjools> it's a model
<bigjools> that would support a solution
<wgrant> I don't see what it has to do with either.
<bigjools> https://bugs.edge.launchpad.net/soyuz/+bug/245594/comments/5
<mup> Bug #245594: Rebuilds of binary packages without source changes <feature> <motu> <Soyuz:Triaged> <https://launchpad.net/bugs/245594>
<wgrant> We need to either change the source version, or do a binNMU and just change the binary version.
<wgrant> Neither situation is helped by allowing multiple uploads of the same source.
 * wgrant reads.
<wgrant> Right, that's the first solution.
<wgrant> And since it involves changing the source, and thus a new SPRB, multiple SPRBUs are not useful here.
<bigjools> well, again, it depends how it's done
<wgrant> And since we don't know how it is going to work, I don't think we should be unnecessarily complicating the model in ways that might not assist, and even if they do will still need alteration.
<bigjools> you seem to feel strongly about it
<bigjools> so I will talk more with jml when he's back
<wgrant> Not a bad idea, although he probably won't be around for a couple of days.
<bigjools> well, that's the weekend then :)
<wgrant> True.
 * bigjools is going to an FA Cup game tomorrow
<bigjools> wgrant: so that build has no Job row
<bigjools> err BQ row
<wgrant> It must.
<wgrant> It has two builders.
<wgrant> And it is being repeatedly dispatched.
<wgrant> And it had a logtail, which is stored on buildqueue.
<wgrant> Although it is all gone now. Was it superseded deliberately?
<bigjools> nope
<bigjools> it's gone because he uploaded a new one, darn
<bigjools> which explains the lack of BQ
<wgrant> There wasn't a DB dump in the meantime that will land on staging tomorrow?
<wgrant> There was a > 7 hour window.
<bigjools> stub, what time is the dump for staging done?
<wgrant> You've confirmed that cesium is still appropriately patched?
<bigjools> yes it us
<wgrant> Arrrrrgh.
<bigjools> there's a weirdo in the data I did see. one sec
<bigjools> http://pastebin.ubuntu.com/360597/
<stub> bigjools: Finishes on wildcherry about 05:30 UTC
<bigjools> stub: ah cool
<stub> Starts at 0100 UTC if that is what you are asking
<wgrant> How long does it take?
<wgrant> Ah.
<wgrant> It will have probably just been too early :(
 * bigjools looks
<bigjools> yeah it's not there
<mars> BjornT or mrevell, around?  Did you have a chance to try that patch?
<mrevell> mars, I merged from RF again and the test-suite passed for me last night.
<mars> mrevell, \o/
<mrevell> :) Just need PQM to come out of RC mode now :)
<mars> I wonder if rockstar's branch merged my patch?
<mars> no, it did not get merged
<bac> sinzui: monring
<bac> sinzui: that's apropos...
<flacoste> nigel_nb: i have now
<jml> hello
<jml> db-devel has been broken by a bugs test.
<jml> anyone fixing it?
<flacoste> jml: seems that no one fixed it yet
<flacoste> jml: stub reported the failure, but didn't claim he was fixing it, and there was no [testfix] landing
<jml> flacoste, ok, thanks.
<jml> flacoste, my taxi arrives in 15 mins, so I probably shouldn't start fixing it.
<jml> but I really want to land this branch. :\
<jml> maybe when I get to Sydney.
 * jml is off.
<sinzui> bac: Here is some info about hacking the button slot in a form: http://pastebin.ubuntu.com/360696/
<bac> thanks sinzui
<intellectronica> sorry everyone for the db_lp failure. not quite sure how that happened, fixing now
<rockstar> BjornT, yes, I merged your branch into mine, landed it.
<rockstar> Er, mars ^^
<mars> rockstar, ok. I have an emergency fix to land then :)
<rockstar> mars, oh?
<mars> rockstar, yep, check line 826 of https://code.edge.launchpad.net/~mars/launchpad/unroll-mochikit/+merge/17870
<mars> (we should link those diff line numbers)
<mars> rockstar, missing 'replace="nothing"', so the comment shows up on every page as a result.
<rockstar> mars, ah.  Well, the fix is only on db-devel.
<mars> for now, yes :)
<rockstar> I thought that with a risky patch like that, we probably want to test it a lot.
<mars> yep.  wait, rockstar, db-devel only?  Not devel?
<rockstar> mars, well, after today, we'll only be merging into db-devel.
<rockstar> mars, yes, only db-devel.
<mars> ok
<mars> so, was staging updated...
<mars> nope
<rockstar> mars, yeah, I tried to get it updated, but it ended up being really complicated.
<sinzui> EdwinGrubbs: how goes your packaging branch and secured vocab fix?
<EdwinGrubbs> sinzui: I'm getting pretty close with the vocab fix.
<sinzui> I will review it. We appear to be missing reviewers
<sinzui> I think I will do some reviews instead of start a new branch to give some people a chance to land their work
<rockstar> mars, db-devel 8911 is where your patch is at.
<mars> rockstar, ok, thanks
<dobey> hey all
<mars> hey dobey
<dobey> do the unit tests for lp use mechanize and the zope testbrowser stuff, and alter the User-Agent to test output changes?
<mars> gary_poster, the Zope wizard, ^ ?
<gary_poster> dobey: yes to the first half, not sure to the second.
<dobey> hrmm. i'm wondering, because i'm trying to implement some user-agent dependent code in u1, and the "documented" way to do it doesn't seem to be working for me :-/
<mars> rockstar, care to review this patch? https://code.edge.launchpad.net/~mars/launchpad/unroll-mochikit-patch-hardening/+merge/17894
<gary_poster> dobey, I've dug pretty deep in there in the past but I'm afraid I don't have the knowledge at hand.  One thing that has made a big difference in the past for edge-case usages is to make sure you have the newest versions of testbrowser and mechanize, but you may already be up-to-date, and it might not make a diff.  If you send me an isolated example I can try to take a look at it today
<rockstar> mars, r=rockstar
<mars> rockstar, thanks
<mars> rockstar, any special flags needed to land on db-devel?
<rockstar> mars, bzr pqm-submit -m '[r=kermit][ui=none] Fix the frobnob.' --submit-branch=bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel
<mars> rockstar, nope, thanks!
<mars> gary_poster / Release Manager, would you happen to know when the next staging roll will be, so we may commence QA?
<rockstar> gary_poster / Release Manager - is it possible we could bump the staging roll?
<rockstar> (I'm actually on leave today, but so excited to do my QA!)
<mars> lol
<gary_poster> mars, rockstar, after intellectronica gets his branch in, we are out of testfix, I land lp:~stub/launchpad/pending-db-changes , and I've asked the losas to kick staging.  My hope is within 2 hrs
<rockstar> gary_poster, woo hoo.
<mars> gary_poster, cool, thanks
<EdwinGrubbs> sinzui: do you want to review my tiny patch? http://pastebin.ubuntu.com/360736/
<dobey> gary_poster: hrmm, a bit more poking and i figured it out. the documentation is wrong :)
<sinzui> EdwinGrubbs: is there already a test for ICountableIterator?
<EdwinGrubbs> sinzui: I don't think there is a specific test case for this, but now it will blow up if you try to use a subclass without the right permission, whereas previously it could mostly work because __getslice__ wasn't called that often.
<sinzui> How do we know this fixes the oopes in the two vocab?
<sinzui> Are the two vocabs subclasses of ICountableIterator
<EdwinGrubbs> sinzui: the SourcePackageName uses the SourcePackageNameIterator that subclasses ICountableIterator.
<sinzui> EdwinGrubbs: And the same is true for canonical.launchpad.database.binaryandsourcepackagename.BinaryAndSourcePackageNameIterator ?
<EdwinGrubbs> sinzui: yes
<sinzui> EdwinGrubbs: okay. r=me
<EdwinGrubbs> sinzui: thanks
<nigel_nb> flacoste, thanks, but I got it solved.  I was playing around with launchpadlib and got stuck :)
<flacoste> nigel_nb: ok, nice to know it got solved!
<nigel_nb> :)
<sinzui> deryck: I am looking at bug 182830. It looks like it is inline with out goals. Is there a tag or milestone I can use to keep it in your sight?
<mup> Bug #182830: Linking package to bug report doesn't suggest checking upstream <Launchpad Bugs:New> <https://launchpad.net/bugs/182830>
 * deryck looks at bug
 * deryck was out lunch
<deryck> sinzui, story-bug-a-and-a would work well for ones like that.  I've tagged that one since I was on it.
<sinzui> okay thanks
<intellectronica> deryck, sinzui: story-bug-q-and-a?
<deryck> heh
<sinzui> I like ask and answerd
<deryck> intellectronica, yeah, sorry.  sinzui -- me typoed.  See intellectronica's correction.
<deryck> bug 182830
<mup> Bug #182830: Linking package to bug report doesn't suggest checking upstream <bugwatch> <story-bug-q-and-a> <ubuntu-upstream-relations> <ui> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/182830>
<deryck> at least the bug is right :-)
<kfogel> intellectronica: https://code.edge.launchpad.net/~kfogel/launchpad/506018-patch-report
<kfogel> intellectronica: https://bugs.launchpad.dev/ubuntu/+patches
<kfogel> intellectronica: https://bugs.launchpad.dev/patches-view-test/+patches
<kfogel> intellectronica: in the above, ubuntu is a distro obviously, patches-view-test is a product we created.  I had to create a bunch of bugs and give them patch attachments and bugtasks and stuff, naturally.
<wgrant> sinzui: If you're around, could you land that branch for me please?
<sinzui> I will
<wgrant> Thanks.
<gary_poster> deryck, rockstar, mars, et al: OK, (finally) you have through r8904 (devel r10208) running on staging.  We're starting another update now since buildbot has just blessed r 8913 (devel r10215) so you will have that in about 1.5 hours.
<mars> gary_poster, ok, thanks
<rockstar> gary_poster, yea, I need the latter.  Thanks for shepherding this.
<rockstar> (today is technically my day off)
<deryck> gary_poster, excellent.  many thanks!
<deryck> gary_poster, should staging be available now?  I get "please try again" error.
<deryck> gary_poster, ohnever mind
<deryck> gary_poster, I see, another update message now
<jamalta> hm... i just got a buildbot failure but i'm not sure which branch it is for :(
<jamalta> or why
<gary_poster> jamalta: looking
<gary_poster> jamalta: it was a failure to update dependencies.  Don't worry about it.  I'll restart.
<gary_poster> IOW it was a breakage in our testing system, not the branch
<jamalta> gary_poster: oh ok, thanks :)
<kfogel> deryck: https://code.edge.launchpad.net/~kfogel/launchpad/506018-patch-report
<deryck> got it
<gary_poster> To Whom It May Concern, the glaring XXX on staging is already addressed in r8915.  It should be gone Monday.
<gary_poster> Also, deryck, fwiw, staging is at 8913, which is as far as we'll get till Sunday/Monday
<deryck> gary_poster, great, thanks for the update.
<gary_poster> np
<Ursinha> mars: hi
<Ursinha> mars: are you around? if so, is that XXX on the top of every page in staging on purpose?
<mars> Ursinha, no
<mars> Ursinha, staging was cut two revisions too soon :)
<mars> Ursinha, the fix is in db-devel r8915, staging has r8913 deployed
<Ursinha> mars: oh, I see :)
#launchpad-dev 2010-01-23
<jml> are we still in testfix?
<mars> jml, looks like maybe "out and back in again" since you last signed off :(
<jml> mars, actually not the case. see my email.
<jml> mars, although, yes, we are back in test fix now.
<jml> but we weren't at half-past the hour :)
<jml> ok, now for my next trick, I need subunit in ec2test-remote.py
<jml> mwhudson, hi
<jml> mwhudson, why can't I import subunit in ec2test-remote.py?
<jml> mwhudson, the answer is that ec2test-remote.py is run without any of Launchpad's non-package-based dependencies in the sys.path
<jml> I'm not sure why _that_ is, but doubtless there is a reason.
<kfogel> gmb: ping
<kfogel> gmb-mobile: hey
<kfogel> gmb-mobile: heading down to lounge to meet up w/ mrjazzcat
<gmb-mobile> kfogel: cool. i'm in the lobby atm. assuming I'll see you on your way through :)
<jml> I've got to run
<jml> but if anyone is bored, test out bzr+ssh://bazaar.launchpad.net/~jml/launchpad/subunit-by-default and see if it attaches a subunit log to test result messages, and that the attached file is named after the branch being tested.
 * jml -> off to London
<kfogel> \o/ jml is going back to london
<kfogel> I will get to speak to him again.
<wgrant> Oh, wow. Automated bug closing on release.
<wgrant> sinzui wins.
<GabydeWilde__> hi
<GabydeWilde__> any chance for feeds in the mailin list?
<henninge> Is PQM really still open or is the topic lying?
<elmo> the topic is lieing
* henninge changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 3 of 10.01 | PQM is closed | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | Channel logs: http://irclogs.ubuntu.com/
<wgrant> sinzui: hm, you didn't get around to landing that branch?
<sinzui> wgrant: I think I landed it
<sinzui> staging did not update because of a test failure that deryck fixed...then there was a merge conflict that gmb indicated he was looking into
* sinzui changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 3 of 10.01 | PQM is closed | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | Channel logs: http://irclogs.ubuntu.com/ | Edge bugs searching is timing out, use lpnet
<wgrant> sinzui: It doesn't look merged.
<wgrant> And it needs an RC now :/
<sinzui> gary and flacoste can issue RCs
<sinzui> wgrant: that was to land in db-devel right?
<wgrant> sinzui: It is, yes.
<sinzui> I have no running instances,
<wgrant> Hmmmm.
<sinzui> There will be no issues getting it approved to land.
<sinzui> wgrant: I submitted your branch about 15 minutes before my release-love branch. I saw a success. I do not recall getting a a PQM reject notice which is what I expect to get if PQM closes
<sinzui> I really wish I had submitted your branch instead of asking if you needed assistance
<sinzui> wgrant: ask for an RC from gary.
#launchpad-dev 2010-01-24
<lifeless> jml: ping?
<dhillon-v10> hi all, hope everyone is doing good, I am working on this spec here: https://blueprints.launchpad.net/launchpad-answers/+spec/automatic-reply and Francis told me to talk to people here, so what do you guys think
<lifeless> dhillon-v10: I suggest the mailing list is an even better place to ddiscuss during the weekend many folk won't be around here.
<dhillon-v10> lifeless: I did mail the list, but will do again, I guess that's a better place to discuss this and may be on a metting :)
<jml> lifeless, hello
<jml> lifeless, I've just arrived home
<lifeless> jml: welcome home
<_Groo_> dput upload is coming to a crawl... does launchpad accepts http instead of ftp?
<_Groo_> hi/2 all
#launchpad-dev 2011-01-17
<gmb> https://dev.launchpad.net/LEP/BetterBugSubscriptionsAndNotifications
<gmb> https://bugs.edge.launchpad.net/launchpad-project/+bugs?field.tag=story-better-bug-notification
<pcjc2> wrong forum, I know.. but why does the Ubuntu One not yet use the new Ubuntu branding and font?
<lifeless> pcjc2: no idea sorry :)
<lifeless> #ubuntuone might be better
<lifeless> http://sqlformat.appspot.com/
<lifeless> stub: ^
<gmb> allenap`: Around?
<thumper> leonardr: https://bugs.launchpad.net/launchpad/+bugs?field.tag=recipe
<timrc> is it possible to contact a launchpad team (the functionality +contactuser provides) via e-mail?
<wgrant> timrc: Yes -- but only if you are in the team, and the team does not have a contact address set.
<timrc> wgrant: cool.. so it would just be <team>@launchpad.net
<gmb> gary_poster, danilos, bac, benji: lp:~gmb/+junk/subscription-widget-mockups/
<lifeless> thumper: now if you're interested
<wgrant> timrc: Ah, I misunderstood you. You can't use an email client to do it; you have to do it from within Launchpad itself.
<timrc> wgrant: ah darn
<thumper> lifeless: nah
<thumper> lifeless: I'll abstain
<jtv> allenap`: http://pqxx.org/development/libpqxx/wiki/AllSoftwareIsBroken
<lifeless> danilos: hey, do you know the bug # about the lp ui not being translated?
<james_w`> lifeless, bug 3896
<_mup_> Bug #3896: Launchpad itself is not translatable in Launchpad <infrastructure> <lp-foundations> <Launchpad itself:Won't Fix> < https://launchpad.net/bugs/3896 >
<lifeless> thanks!
<StevenK> Has anyone seen mars?
<elmo> StevenK: he's with dragnob
<StevenK> elmo: Thanks!
<deryck> james_w`, bug 12345 has all the statuses grayed out for me.  So that fix is released.
<_mup_> Bug #12345: isdn does not work, fritz avm (pnp?) <isdnutils (Ubuntu):Fix Released by doko> < https://launchpad.net/bugs/12345 >
 * deryck is looking for bug number
<james_w`> deryck, excellent
<james_w`> deryck, do you want to email marjo?
<deryck> james_w`, yeah, I'll email him.  Thanks for letting me know he was wondering about that.
<thumper> leonardr: uncaught exception: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIDOMHTMLElement.appendChild]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: https://bugs.staging.launchpad.net/+icing/rev10138/build/launchpad.js :: anonymous :: line 3607" data: no]
<bac> huwshimi: available for some UI guidance?
<huwshimi> Sure are
<huwshimi> bac: shall I come find you?
<bac> huwshimi: i'll meet you at the snack cart
<huwshimi> bac: deal
<lifeless> thumper: btw; reminder: https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html
<lifeless> jelmer: btw there is a bug for lp://qastaging
<allenap> thumper: Yo, you've got three bugs in the stable deployment report that are blocking roll-out. I had a look at them, but I don't know how to check them. Could you? Pretty please, I have a few branches right after yours that I want to deploy :)
<gary_poster> https://dev.launchpad.net/Foundations/ComponentHelp
<gary_poster> danilos: ^^^
<jelmer> lifeless: I didn't know - thanks
<thumper> allenap: ok... RSN
<lifeless> jtv: hi
<lifeless> jtv: can you qa your long running xact patch please?
<jtv> hi lifeless
<jtv> when do you want it done?
<lifeless> jtv: as soon as possible, we've  abacklog
<jtv> ah so
<jtv> I'll need a losa
#launchpad-dev 2011-01-18
<mbarnett> who knows where you could find one of those!?
<LPCIBot> Project db-devel build (278): FAILURE in 5 min 10 sec: https://hudson.wedontsleep.org/job/db-devel/278/
<LPCIBot> Project db-devel build (279): STILL FAILING in 0.47 sec: https://hudson.wedontsleep.org/job/db-devel/279/
<LPCIBot> Project db-devel build (280): STILL FAILING in 0.47 sec: https://hudson.wedontsleep.org/job/db-devel/280/
<LPCIBot> Project db-devel build (281): STILL FAILING in 0.46 sec: https://hudson.wedontsleep.org/job/db-devel/281/
<LPCIBot> Project db-devel build (282): STILL FAILING in 0.47 sec: https://hudson.wedontsleep.org/job/db-devel/282/
<LPCIBot> Project db-devel build (283): STILL FAILING in 0.46 sec: https://hudson.wedontsleep.org/job/db-devel/283/
<LPCIBot> Project db-devel build (284): STILL FAILING in 1.3 sec: https://hudson.wedontsleep.org/job/db-devel/284/
<LPCIBot> Project db-devel build (285): STILL FAILING in 0.46 sec: https://hudson.wedontsleep.org/job/db-devel/285/
<LPCIBot> Project db-devel build (286): STILL FAILING in 0.49 sec: https://hudson.wedontsleep.org/job/db-devel/286/
<LPCIBot> Project db-devel build (287): STILL FAILING in 0.48 sec: https://hudson.wedontsleep.org/job/db-devel/287/
<LPCIBot> Project db-devel build (288): STILL FAILING in 0.49 sec: https://hudson.wedontsleep.org/job/db-devel/288/
<LPCIBot> Project db-devel build (289): STILL FAILING in 0.48 sec: https://hudson.wedontsleep.org/job/db-devel/289/
<LPCIBot> Project db-devel build (290): STILL FAILING in 0.46 sec: https://hudson.wedontsleep.org/job/db-devel/290/
<LPCIBot> Project db-devel build (291): STILL FAILING in 0.48 sec: https://hudson.wedontsleep.org/job/db-devel/291/
<LPCIBot> Project db-devel build (292): STILL FAILING in 1.9 sec: https://hudson.wedontsleep.org/job/db-devel/292/
<LPCIBot> Project db-devel build (293): STILL FAILING in 0.48 sec: https://hudson.wedontsleep.org/job/db-devel/293/
<LPCIBot> Project db-devel build (294): STILL FAILING in 0.46 sec: https://hudson.wedontsleep.org/job/db-devel/294/
<LPCIBot> Project db-devel build (295): STILL FAILING in 0.48 sec: https://hudson.wedontsleep.org/job/db-devel/295/
<LPCIBot> Project db-devel build (296): STILL FAILING in 0.48 sec: https://hudson.wedontsleep.org/job/db-devel/296/
<LPCIBot> Project db-devel build (297): STILL FAILING in 0.49 sec: https://hudson.wedontsleep.org/job/db-devel/297/
<LPCIBot> Project db-devel build (298): STILL FAILING in 0.47 sec: https://hudson.wedontsleep.org/job/db-devel/298/
<LPCIBot> Project db-devel build (299): STILL FAILING in 0.46 sec: https://hudson.wedontsleep.org/job/db-devel/299/
<LPCIBot> Project db-devel build (300): STILL FAILING in 0.47 sec: https://hudson.wedontsleep.org/job/db-devel/300/
<LPCIBot> Project db-devel build (301): STILL FAILING in 0.46 sec: https://hudson.wedontsleep.org/job/db-devel/301/
<LPCIBot> Project db-devel build (302): STILL FAILING in 0.46 sec: https://hudson.wedontsleep.org/job/db-devel/302/
<LPCIBot> Project db-devel build (303): STILL FAILING in 0.45 sec: https://hudson.wedontsleep.org/job/db-devel/303/
<LPCIBot> Project db-devel build (304): STILL FAILING in 2.5 sec: https://hudson.wedontsleep.org/job/db-devel/304/
* lifeless changed the topic of #launchpad-dev to: Launchpad Development Channel | 11.01 Release Week 4 | PQM is open | firefighting: build is broken | Get the code: https:/â/âdev.launchpad.net/âGetting
<LPCIBot> Project db-devel build (305): STILL FAILING in 0.48 sec: https://hudson.wedontsleep.org/job/db-devel/305/
<wgrant> Hmm.
<wgrant> I wonder if telling it to wipe out its workspace will work.
<LPCIBot> Project db-devel build (306): STILL FAILING in 0.45 sec: https://hudson.wedontsleep.org/job/db-devel/306/
<LPCIBot> Project db-devel build (307): STILL FAILING in 0.46 sec: https://hudson.wedontsleep.org/job/db-devel/307/
<LPCIBot> Project db-devel build (308): STILL FAILING in 0.49 sec: https://hudson.wedontsleep.org/job/db-devel/308/
<LPCIBot> Project db-devel build (309): STILL FAILING in 0.47 sec: https://hudson.wedontsleep.org/job/db-devel/309/
<LPCIBot> Project db-devel build (310): STILL FAILING in 0.46 sec: https://hudson.wedontsleep.org/job/db-devel/310/
<LPCIBot> Project db-devel build (311): STILL FAILING in 0.47 sec: https://hudson.wedontsleep.org/job/db-devel/311/
<Ursinha> lifeless, tell me four bugs that annoy you in qa-tagger
<jelmer> thumper: niiiice
<thumper> jelmer: there are some wording changes on the qastaging copy
<thumper> but the view is the same
<jelmer> like many of the other recipe builds it would be nice if the last successful build or at least whether the last build was successful could be shown
<lifeless> Ursinha: 674829 671809 681099 688073(but really just about usability in the report)
<Ursinha> lifeless, cool
<Ursinha> bug 674829 bug 671809 bug 681099 bug 688073
<_mup_> Bug #674829: Deployment report for db-stable is broken. <qa-tagger:Fix Committed by ursinha> < https://launchpad.net/bugs/674829 >
<_mup_> Bug #671809: bug mail should use the header from the bug thread rather than 'Bug fixed by a commit' <qa-tagger:Triaged> < https://launchpad.net/bugs/671809 >
<_mup_> Bug #681099: bug=1234 merges without lp metadata don't show up in the deployment report <qa-tagger:Triaged> < https://launchpad.net/bugs/681099 >
<_mup_> Bug #688073: qa-needstesting revisions should not be greyed out <deployment-qa> <qa-tagger:Triaged> < https://launchpad.net/bugs/688073 >
<Ursinha> lifeless, now the big ones
<Ursinha> lifeless, I don't plan to abandon qa-tagger, it's my child :P
<lifeless> Ursinha: \o/
<lifeless> Ursinha: Hopefully you will welcome assistance from the team though :>
<Ursinha> hehe, lifeless, of course :)
<lifeless> wgrant: https://bugs.launchpad.net/launchpad/+bug/704585
<_mup_> Bug #704585: canonical_url performs poorly <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/704585 >
<jelmer> StevenK: https://code.launchpad.net/~jelmer/ubuntu/natty/paramiko/randompool+addressfamilies/+merge/46669
<StevenK> jelmer: https://code.launchpad.net/~stevenk/launchpad/more-thunder/+merge/46406
<gmb> gary_poster: http://pastebin.ubuntu.com/555534/
<lifeless> gmb: sooooooooo
<lifeless> gmb: there is a bug you should see
<gmb> lifeless: Just one? Win.
<gmb> Link me.
<LPCIBot> Project db-devel build (312): STILL FAILING in 4 hr 55 min: https://hudson.wedontsleep.org/job/db-devel/312/
<lifeless> gmb: bug 507603
<_mup_> Bug #507603: checkwatches on non-debian debbugs instances do not work <bugwatch> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/507603 >
 * gmb looks
<gmb> lifeless: Noted. And thanks for pointing out that it's a different debbugs DB. I was apparently suffering from an acute uptake-grasping deficiency disorder on the day when I first responded to that bug.
<lifeless> is that a hard thing to do
<lifeless> like
<lifeless> did we need special arrangements to sync the db
<jml> thumper: reviewed your patch.
<allenap> rvb: http://wiki.bazaar.canonical.com/BzrPipeline
<lifeless> matsubara: hi
<matsubara> hey lifeless
<lifeless> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1844B1523 is on disk on devpad, web ui is refusing to show it
<lifeless> how do I debug whats going on ?
<matsubara> working on it
<matsubara> lifeless, I rolled out some code yesterday which broke the OopsLoader
<lifeless> kk
<wgrant> Ah, I was about to ask about that myself.
<gmb> lifeless: Yes, we need to make arrangements to sync the DB to some place on loganberry. We don't support > 1 debbugs DB, either; the code is written for just the one of them.
<lifeless> yeah
<lifeless> so code change + a faq
<gmb> lifeless: Yes.
<gary_poster> mars, yoo hoo....  anyone seen a mars?
<jml> gary_poster: he's here, getting trained in some hiring software
<bigjools> jelmer: are you busy?
<allenap> sinzui: Do you generate a web page of the XXXs in the code?
<sinzui> I used to
<sinzui> I may still
 * sinzui looks
<bigjools> it was on devpad IIRC
<wgrant> There's a script in utilities/
<wgrant> stub: Bug #526890 is probably fixed now that the auth store is gone, right?
<_mup_> Bug #526890: Oops on export page: LocationError: (None, 'email') <lp-translations> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/526890 >
<sinzui> allenap, I do not the script to create the xxx report is in./utilities
<stub> closed
<wgrant> Thanks.
<jelmer> bigjools: hi
<bigjools> jelmer: heyhey.  Can we talk about your outstanding bugs/branches?
<jelmer> bigjools: yes, sure. where are you?
<bigjools> jelmer: presidente
<gmb> I want it noted that JS is hateful and should be shot.
<gmb> Can we implement in-browser LISP at some point? It'd be more fun.
<jtv> Did we just land any changes to how we tally Rosetta usage?  The translatable-projects listing on qastaging is over a thousand projects short.
<dobey> gmb: http://kybernetikos.github.com/Javathcript/
<mwhudson> dobey: i bet he started that because he came up with the project name and then couldn't resist implementing it
<lifeless> gmb: oh also
<lifeless> flags in the api; we need to talk- I think you're on crack
<gmb> lifeless: I'm open to the idea of being on crack.
<gmb> When I filed the bug I was feeling quite punchy about using feature flags with JS features. I haven't thought in depth about the arguments for not doing it, though.
<lifeless> oh in js is great
<lifeless> I'd just set the variables you need in the .pt
<lifeless> or does that not work?
<dobey> mwhudson: heh
<gmb> lifeless: It works; it felt like a hack.
<gmb> lifeless: But if you're happy for it to be done that way, let's do it that way. I'm all for uncomplicated solutions.
<gmb> My frustration wasn't helped by bugtask_index.js shenanigans that I told you about on Sunday.
<gmb> So feel free to mark that as BugTaskStatus.REPORTER_ON_CRACK.
<matsubara> wgrant, lifeless: OopsLoader is fixed and it's now catching up. that oops should be available soon
<wgrant> matsubara: Thanks.
<matsubara> np
<lifeless> matsubara: awesome thanks
<lifeless> leonardr: hey
<lifeless> leonardr: I'd like to learn a little more about how launchpadlib api authentication happens
<lifeless> do you think you can spare a few minutes to teach me?
<leonardr> lifeless: yes, i need a minute though
<leonardr> we can do it on irc or irl
<lifeless> I'm in the plenary room
<leonardr> ok, be there soon
<jtv> allenap: is there any innate ordering to bug subscriptions?  Seems I/we broke bugsubscription.txt line 866, in the ordering of getDirectBugSubscriptions() output.
<jtv> rvb: interested in doing that translations bugfix I mentioned?
<allenap> jtv: Interesting. Bug.getDirectSubscriptions() returns a newfangled BugSubscriptionSet object.
<allenap> jtv: Which is a subclass of frozenset.
<allenap> jtv: It has a .sorted property that might help you.
<jtv> allenap: but the breakage is entirely arbitrary and the test is wrong to depend on the ordering of a frozenset, right?
<allenap> jtv: Yes. I assume I missed the ordering problem when changing getDirectSubscriptions recently.
<jtv> help(frozenset) doesn't tell me anything about "sort"
<allenap> jtv: BugSubscriptionSet is special :)
 * jtv winces at that word
<allenap> jtv: It's special in a nice way.
<rvb> jtv: sure
<jtv> rvb: I'm in the plenary roomâ¦ want to come over or do you have a better spot?
<rvb> I'll come over in just a sec
<jtv> jcsackett: find anything interesting in the translated-projects code?
<jcsackett> jtv: haven't actually had a chance to look at it, to be honest, but as i need a break from what i'm doing i'll take a look right now.
<jtv> jcsackett: cool, thanks!
<rvb> jtv: I'm sorry it's taking longer than I tought ... I'm working on a bug with Julian
<jtv> rvb: no worriesâI can also just go ahead and get it done, if you don't feel you'll get around to it.
<poolie> is it a known bug about 'POST /+request-token' failing with 403?
<poolie> or maybe this is my bug
<StevenK> poolie: Is it POSTing to edge?
<wgrant> matsubara: Is the oops thingy still broken, or just not caught up yet?
<matsubara> wgrant, not caught up. almost there.
<rvb> jtv: If you have other things to do right now, I'll be happy to be on you side while you fixe this bug really
<jtv> rvb: plenty of things to doâ¦ maybe I'll just concentrate on the workaround first.
<jtv> (I'll ask an admin to grant the required extra database permission first)
<poolie> StevenK, yes it was
<poolie> i've updated it but it still seems like a bug
<wgrant> poolie: Ugh what?
<wgrant> launchpadlib?
<poolie> yes
<wgrant> Ugh.
<poolie> bug 704664
<_mup_> Bug #704664: 403 on post to edge /+request-token <Launchpad itself:New> < https://launchpad.net/bugs/704664 >
<matsubara> wgrant, it's available now
 * bigjools has Launchpadlurgy
<wgrant> matsubara: Indeed, thanks.
<wgrant> bigjools: Already? :(
<bigjools> already
<bigjools> the Berocca is not quite doing the trick
<jml> are you pumped?
<jml> are we running the latest bzr-builder on our slaves?
<jml> (also, how would I find out without asking here)
<bigjools> jml: ask a buildd admin (ie lamont)
<Ursinha> is it possible to set a merge proposal to a status other than "approved" or "rejected" using the email interface?
<jml> hmm.
<Ursinha> jml, I totally forgot you used to be a code guy
<jml> Ursinha: heh
<jml> Ursinha: actually, I have no idea. I just looked at https://help.launchpad.net/Code/Review#Email%20interface :)
<Ursinha> jml, :) that page only has approve and reject
<bigjools> jml: he's responsible for what's installed on the builders
<jml> bigjools: ok, thanks.
<lifeless> how do we tell if karma isn't updating?
<wgrant> scriptactivity spam is spammy.
<spm> it should be silent.....
<sinzui> wgrant, https://bugs.launchpad.net/launchpad/+bug/697441
<_mup_> Bug #697441: buildmailman fails under natty <build-infrastructure> <mailing-lists> <python-upgrade> <Launchpad itself:Triaged> < https://launchpad.net/bugs/697441 >
<allenap> lifeless: https://wiki.canonical.com/Launchpad/Strategy/DesignDiscussionDallas2011
<wgrant> gmb: bin/kill-test-services
<gmb> wgrant: Ooh, that's a start. Ta.
<wgrant> Also, the librarian fixture branch that someone should be landing soon.
<gmb> wgrant: Bum. No, that didn't help any. I'll leave it for now; I'm going square-eyed. Thanks anyway.
#launchpad-dev 2011-01-19
<lifeless> sinzui: bug 704662
<_mup_> Bug #704662: karma is not updating <Launchpad itself:Triaged> < https://launchpad.net/bugs/704662 >
<spiv> james_w`: Awesome: http://package-import.ubuntu.com/status/libbase-openoffice.org.html#2011-01-19%2001:13:13.621831
<spiv> In fact it appears the package importer is encountering lots of issues...
<LPCIBot> Project db-devel build (313): STILL FAILING in 5 hr 12 min: https://hudson.wedontsleep.org/job/db-devel/313/
<kb9vqf> Soo...if my Postgresql database has suddenly sprouted duplicate rows after a disk failure, what is the best way to remove them>
<kb9vqf> ?
<kb9vqf> ^^^ This is in libraryfilealias
<kb9vqf> I had been attempting to use this (gleaned from a repair article online) but execution never terminated: http://ubuntu.pastebin.com/53SXyuBq
<kb9vqf> Any help is greately appreciated :-)
 * kb9vqf cannot type tonight; sorry
<spm> if you've had a disk failure, would you be better off going back to a known good state from backups?
<spm> not sure I'd ben keen to trust any database state after a disk failure has corrupted it.
<lifeless> kb9vqf: if you have a corrupt db, I'd definitely restore :)
<kb9vqf> spm: Yes, if the most recent backups weren't several months old :-P
<lifeless> rolling forward is likely to be World Of Pain
<kb9vqf> The backup script failed silently
<kb9vqf> So far the only table with damage is libraryfilealies
<lifeless> well
<kb9vqf> And I wonder if the damage is limited to the indecies
<lifeless> the only table you can *tell* has damage so far
<kb9vqf> Yes
<kb9vqf> I've been running this install with the damaged tables for a while and I haven't noticed any malfunctions
<kb9vqf> The only thing is that the reindex always fails
<kb9vqf> (due to the duplicate rows)
<kb9vqf> Is there a way to clear the Postgresql indexes?
<lifeless> we're really not postgresql gurus
<spm> drop and recreate, but the data being used to generate them is corrupt; so... :-/
<lifeless> our approach to such corruption and failure would be a restore
<lifeless> #postgresql is much more likely to have folk that can give more sophisticated solutions
<kb9vqf> OK, thanks :-)
<kb9vqf> I appreciate the pointers
<kb9vqf> lifeless: If it comes up here again, the solution is to use pgAdmin III (or other admin tool) to make an SQL dump of the database, then drop the database in single-user mode and reload it with psql
<kb9vqf> As long as this is done BEFORE the system tables are reindexed, it will work
<maxb> Hmm. I think it would be useful to have another state for code imports
<maxb> We currently have Failed Suspended and Invalid
<maxb> It would be nice to subdivide Failed into new failures and triaged failures
<maxb> Neither fit in Suspended/Invalid, because any user should be able to retry a triaged failed import
<thumper> maxb: I think the intent was that triaged failures are suspended
<thumper> maxb: and thanks for the continued import help :)
<maxb> I guess so - the problem being that having just looked at a couple of imports and found that they are failing because someone's dyndns.org address is currently offline, I don't want to suspend them and bar them from initiating a retry
<thumper> ah...
<thumper> maxb: can't you just leave it as failed?
<maxb> can do. But we're doing pretty well at driving the "Failed" status for bzr-svn/git down to "things we should fix"
<lifeless> matsubara: btw lp-oops web ui is a bit gnarly right now
<matsubara> lifeless, will look into it after breakfast
<poolie> lifeless, i would love to hear your thoughts on my twisted api braindump
<lifeless> poolie: where is it?
<poolie> on launchpad-dev
<poolie> uh "notes towards async api clients"
<cody-somerville> poolie, I hope your idea isn't to replace the current launchpadlib with that.
<bac> https://docs.google.com/a/canonical.com/document/d/19nOrInYTuwrIFiL5WS7PSqz-GnoStrr5LbBr_avDf-I/edit?hl=en#
* jcsackett changed the topic of #launchpad-dev to: Launchpad Development Channel | PQM is open | firefighting: build is broken | Get the code: https:/â/âdev.launchpad.net/âGetting
<LPCIBot> Project db-devel build (316): FAILURE in 5 hr 7 min: https://hudson.wedontsleep.org/job/db-devel/316/
<LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12226
<LPCIBot> included.
<james_w`> mpt, jml: http://people.canonical.com/~jamesw/workitems/natty.old/
<matsubara> lifeless, https://lp-oops.canonical.com/oops.py/ works again
<lifeless> thanks!
<jml> huwshimi: https://dev.launchpad.net/IssueTracker
<jcsackett> jml: the issuetracker idea doesn't include answers?
<jml> jcsackett: not yet
<jcsackett> jml: huh. that's how it keeps being explained to me. was surprised to see it's not part of the entry.
<thumper> leonardr: https://code.launchpad.net/~leonardr/lazr.restful/fix-remove-recipe/+merge/24423
<thumper> leonardr: https://code.launchpad.net/lazr.restful/+activereviews
<leonardr> benji: do you know that https://code.launchpad.net/~benji/lazr.restful/bug-539070/+merge/40003 wasn't merged into lazr.restful?
<leonardr> gary: same for you, for https://code.launchpad.net/~gary/lazr.restful/bug691841/+merge/46312
<leonardr> i'm happy to merge both of those if you say the word--i'm assuming you're not holding off for some reason
<gary_poster> looking leonardr
<gary_poster> leonardr: you can land mine, thank you
<leonardr> will do
<benji> leonardr: I was vacillating between adding a little bit more to it or landing it as is, but it's gone long enough that it should just be landed.  If you feel inclined to land it, I would appreciate it.
<lifeless> btw - https://code.launchpad.net/launchpad-project/+activereviews - all our reviews
<leonardr> benji: will do
<leonardr> benji, gary, you are merged
<benji> leonardr: thanks!
<lifeless> jam: did you find dendrobates?
<jam> lifeless: I did not
<lifeless> mtaylor: ping
<jam> I found his user name on #ubuntu-devel but no response
<gmb> leonardr: I'm having some trouble exposing something in the WS API, do you have a second to let me pick you brain?
<leonardr> gmb, sure, i need a minute
<leonardr> where are you? i'll come over
<gmb> leonardr: Vinoy
<gmb> Thanks.
<lifeless> hey
<soren> o/ again.
<lifeless> so the user is 'sleepsonthefloor'
<soren> Let me check our Hudson/tarmac box.
<soren> Oh.
<lifeless> I'm told it looks openstack related
<lifeless> its connecting once every 6 seconds or so
<soren> Very likely is. sleepsonthefloor is one of the NASA guys.
<soren> Crikey.
<soren> What's the IP?
<lifeless> jam: ^
<soren> It's not our Hudson box.
<lifeless> soren: thats good to know
<soren> lifeless: I'm trying to get a hold of him
<lifeless> jam did the investigation, he'll know the ip or where to look; gimme a sec to chase him down
<jam> soren: 173.203.89.94
<lifeless> ah^ there we go
<spiv> lifeless: I chased him down first :P
<spiv> lifeless: admittedly he's right next to me so I had a wee bit of a head start...
<soren> lifeless, jam: I'll chase down some people.
<lifeless> we don't mind being used...
<jam> soren: thanks. I don't think it is a problem if there is a real need (many launchpad services connect about 4k times per day)
<jam> but it seemed odd to go from about 5 connections per day to 11k for a given user
<soren> jam: Oh, these are not 11K open connections?
<soren> But 11K over the course of a day?
<jam> soren: right
<lifeless> soren: serial, yes
<soren> Oh, ok.
<lifeless> soren: seems like something in a tight loop
<jam> I'm not sure if it is strictly serial, vs small concurrency
<lifeless> ^
<jam> soren: Looking over the logs by eye I don't see concurrent connections yet
<soren> Probably not.
<soren> It seems it's a build server that polls in a tight loop. They're waiting for sleepsonthefloor to get back from lunch to fix it :)
<lifeless> soren: can they tune it down a little? They could subscribe to the branch to get a notification when it changes (so little need to poll at all)
<lifeless> would be delighted to talk requirements with them
<soren> lifeless: I'm sure it's a mistake.
<lifeless> cool
<jam> we could give an HTTP url for the branch/last_revision file that you could also monitor, more cheaply than ssh handshaking :)
<lifeless> as jam says if its needed, we can figure out how to support it
<soren> lifeless: ...but when you say subscribe, you mean subscribe to e-mail notifications? Or something cooler?
<lifeless> soren: today sadly I just mean email
<lifeless> I *want* to do PSHB
<soren> lifeless: Ok :)
<soren> lifeless: Yeah.
<gary_poster> stub: https://code.launchpad.net/~gary/launchpad/structuralsubscriptions/+merge/46822
<bigjools> gary_poster: is ++profile++ working on staging/qastaging?
<gary_poster> bigjools: no, only on devel.
<bigjools> ok thanks
<lifeless> bigjools: future work that gary_poster was mentioning late last week
<gary_poster> yeah
<gary_poster> not that hard
<gary_poster> want to make ++profile++download
<gary_poster> but not necessary
<bigjools> lifeless, wgrant: have you looked at reducing the query count in the package copier perchance?
<lifeless> wgrant was in fact looking around that area
<bigjools> I am wondering whether to tackle it now or leave it if someone already started
<wgrant> bigjools: I have some ideas.
<wgrant> I know roughly what needs to be don.
<benji> gary_poster: https://dev.launchpad.net/yellow/Subscriptions
<mpt> huwshimi, https://dev.launchpad.net/AlertMessages
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project db-devel build (317): FIXED in 5 hr 10 min: https://hudson.wedontsleep.org/job/db-devel/317/
<LPCIBot> * Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12229,
<LPCIBot> 12230 included.
<LPCIBot> * Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12227,
<LPCIBot> 12228 included.
<leonardr> rockstar, do i remember you working on bug 316694 around the time of the prague meeting?
<_mup_> Bug #316694: Add web_link property to resources <launchpadlib :Triaged> < https://launchpad.net/bugs/316694 >
<leonardr> if so, what happened to it?
<rockstar> leonardr, I may still have the branch around here.  I made the change, but it broke a bunch of tests that you said were very low-level, and that's where it died (because the week ended, and I lost "free time")
<leonardr> rockstar: ok, we are starting to feel the need again. can you find the branch for me?
<rockstar> leonardr, yeah, it's going to be on an old backup unless I've pushed it.  Let me do some mining.
<leonardr> rockstar, thanks
<leonardr> just knowing where to start would be helpful
<mpt> Daviey, are you the one who's maintaining the UDS scheduler tool now?
<mpt> Or am I confusing you with someone else/
<mpt> ?
<lifeless> danilos: ping
<lifeless> danilos: could you eyeball bug 705129 and suggest whether its operational or a bug ?
<_mup_> Bug #705129: Nightshade import queue don't work <Launchpad itself:New> <Nightshade:New> < https://launchpad.net/bugs/705129 >
<danilos> lifeless, it's kinda both... it's a bug that LP doesn't automatically approve the files with the names it exports them with (which are those in the queue), but when people come to us we can fix this quickly through the UI for them (so it's operational as well)
<lifeless> danilos: are there docs somewhere for lp devs? (e.g. what should I do here?)
<danilos> lifeless, https://help.launchpad.net/Translations/YourProject/ImportPolicy though you might not have permissions to act on it operationally
<danilos> lifeless, we can add everyone in LP team to rosetta-admins to solve that though
<lifeless> danilos: perhaps add the ~launchpad team itself ?
<danilos> lifeless, right, that's what I meant
<lifeless> kk
<lifeless> danilos: might be nice to describe where the queue is on that wiki page (for admins)
<danilos> lifeless, yes, there's still quite some work for the hand-off of this that previous translations team needs to do
<lifeless> gmb: danilos: hi
<lifeless> please don't use Storm
<lifeless> we need the same invalidator SQLBase has.
<lifeless> I'm updating the wiki page now.
<danilos> lifeless, if we need to use cachedproperties on that object, I'd say yes... if not, I don't think why we should pretend to know what are we going to do with this object; fwiw, it's easier to switch stuff back to SQLBase than it is to switch it to Storm
<Daviey> mpt, I am a commiter, but i've been trying to hand over the burden somewhat.
<lifeless> I guess I'm worried that folk will use cachedproperty on any model class thinking its safe - becuase it is safe with any SQLBase class
<mpt> Daviey, could you give me the URL of the LP project? I've forgotten it since UDS. :-)
<lifeless> It would be nice to have it safe for all model classes, which just needs a similar base class to SQLBase, and us to not directly use s.b.Storm
<lifeless> OTOH you're right that its unnecessary overhead if we're not using it.
<Daviey> mpt, lp.net/summit :)
<mpt> ahhhh, summit
<mpt> I knew it was summit like thaht
<danilos> lifeless, why not have a SafeStorm (stupid name, but you get the idea) which just provides that for any cachedproperties
<mpt> thanks Daviey
<lifeless> danilos: Do you think folk will remember to look at the base class?
<danilos> lifeless, not too sure about that
<lifeless> danilos: My *tendancy* would be to have a SafeStorm and use it everywhere by default; using raw Storm if we have a reason to do so.
<lifeless> danilos: what do you think?
<StevenK> StormBase or ... (bad pun incoming) Cloud
<lifeless> StormCloud!
<StevenK> I like it!
<Daviey> mpt, I bet you have a metric tonne of usability bugs, right? :)
<mpt> Daviey, none at all. The biggest annoyance I have with Summit is where people hide the meaningful words in a session title toward the end of the title.
<mtaylor> lifeless: pong
<danilos> lifeless, yeah, +1 on that
<danilos> lifeless, not the Cloud naming though :))
<danilos> lifeless, CloudyStorm, perhaps...
<sinzui> huwshimi, http://pastebin.ubuntu.com/556006/
<leonardr> rockstart: ping, hope you haven't been mining this whole time
<leonardr> rockstar -^
<rockstar> leonardr, no, but I have been.  I found a bug in Launchpad's search as well.  :)
<leonardr> is this it? https://code.launchpad.net/~rockstar/lazr.restful/web_link
<rockstar> leonardr, web_link! Yes, that's it.
<rockstar> I was looking for a launchpad branch for some reason.
 * leonardr just went to your page of lazr.restful branches
<rockstar> Of course, it's one of the few lazr.restful branches I've ever had...  :)
<leonardr> ok, i'll take a look
<leonardr> rockstar: you don't have any _revisions_ to that branch
<leonardr> it's just trunk (as of when you pushed it)
<StevenK> wgrant: I just noticed something amusing. Remember that bit of the doctest I was asking about?
<rockstar> leonardr, okay, lemme get in the backup.
<lifeless> danilos: could you perhaps add that in your branch? r=me for it, and then noone else needs to think. I'll happily update the wikipage with whatever name you choose
<StevenK> wgrant: It has oldest_spr = publisher.getPubSource(...) -- except that getPubSource() returns an SPPH :-)
<lifeless> danilos: I hate to ask you to add this but it makes me nervous is all
<lifeless> mtaylor: see discussion w/soren
<danilos> lifeless, we have other Storm classes, and I think it'd be better to have a single push to have them all fixed
<danilos> lifeless, preferably in the same branch, and definitely not in this one; if I was exactly sure how to achieve what you want, I'd probably do it before we sign off for the day
<mtaylor> lifeless: ok.
<danilos> lifeless, I'd be happy to be convinced tomorrow to do it, so let's talk tomorrow morning about it
<mtaylor> lifeless: well. I certainly support some form of non-email notification... and I'm _still_ trying to get someone to fund someone to write a lpapi java binding so I can use lp-api to check things from hudson (but it seems to keep getting lost in corporate land somewhere)
<wgrant> StevenK: Heh.
<allenap> mpt: With some help from a friendly DBA, I figured out that the figures in several of those tables are counts of all specifications, not just those in the last year. Would you prefer the all-time counts for the top-50-specs-users-in-the-last-year, or the last-year counts?
<mpt> allenap, last-year for everything would be most helpful I think
<allenap> mpt: Cool, will have that soon.
<mpt> thank you allenap
<rockstar> leonardr, just pushed the changes.
<leonardr> rockstar, great
<leonardr> rockstar: thanks, this looks exactly like what i was writing
<leonardr> so, let's see what's the deal w/the tests
<rockstar> leonardr, great.
<rockstar> leonardr, if you fix this, you'll help us remove a significant amount of code in Tarmac.
<leonardr> rockstar: this doesn't look too bad? do you remember anything else i said about the test failures?
<rockstar> There are test failures, as I recall.  The failures were caused in tests that were testing at a very low level, I think.
<leonardr> i guess webservice.txt is pretty low level
<leonardr> but ultimately i think the fix is pretty simple
<leonardr> i'll give it a try
#launchpad-dev 2011-01-20
<leonardr> yeah, one little change got rid of most of the errors
<jml> g'night all
<lifeless> jml: ciao
<lifeless> === Top 10 Time Out Counts by Page ID ===
<lifeless>     Hard / Soft  Page ID
<lifeless>      283 / 2484  Distribution:EntryResource:searchTasks
<lifeless>      103 /  242  BugTask:+index
<lifeless>       94 /  209  Distribution:+bugs
<lifeless>       52 / 4427  Archive:+index
<lifeless>       38 /   85  Branch:+index
<lifeless>       23 /    3  ProjectGroup:+milestones
<lifeless>       15 /  258  Question:+index
<lifeless>       11 /    1  Distribution:+builds
<lifeless>       10 /    1  DistributionSourcePackage:+filebug
<lifeless>        8 /    2  Person:+bugs
<LPCIBot> Project db-devel build (318): FAILURE in 4 hr 54 min: https://hudson.wedontsleep.org/job/db-devel/318/
<LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12231,
<LPCIBot> 12232 included.
<Ursinha> lifeless, have a minute for a review?
<Ursinha> https://code.launchpad.net/~ursinha/qa-tagger/681099-consider-untestable-bugs/+merge/46870
<lifeless> Ursinha-afk: done
<Ursinha> thanks lifeless
<lifeless> de nada
<Ursinha> :)
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project db-devel build (319): FIXED in 5 hr 15 min: https://hudson.wedontsleep.org/job/db-devel/319/
<LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12233,
<LPCIBot> 12234 included.
<lifeless> \o/
<al-maisan> hmm .. this channel used to be livelier
<lifeless> its < 8am where everyone in the team is
<lifeless> sprint time :)
<al-maisan> ah, I see :)
<lifeless> jml: are you going to show testr/tribunal?
<jml> lifeless: yes
<jml> lifeless: testr, tribunal, subunit, fixtures, testdoc, etc.
<lifeless> \o/
<Ursinha> leonardr, is bug https://bugs.edge.launchpad.net/launchpad/+bug/486974 actually fix released?
<_mup_> Bug #486974: no API documentation of Person <bugjam2010> <lp-foundations> <qa-ok> <Launchpad itself:Fix Released by leonardr> < https://launchpad.net/bugs/486974 >
<Ursinha> it was marked as fix released so the qa-tagger is ignoring it
<Ursinha> leonardr, it's not actually released yet, as production doesn't have it, right? can I change it back to Fix Committed?
<leonardr> ursinha: yeah, sure
<leonardr> sorry
<Ursinha> leonardr, no problem, really
<Ursinha> jcsackett, is the partial fix of bug 618400 ok to be deployed?
<_mup_> Bug #618400: Distribution:+archivemirrors timing out in 1% of requests <lp-registry> <mirror> <pg83> <timeout> <Launchpad itself:In Progress by jcsackett> < https://launchpad.net/bugs/618400 >
<Ursinha> as in it doesn't need qa or it won't break anything
<jcsackett> ursinha: yeah, i took a look at the affected pages last night--all seems groovy.
<Ursinha> jcsackett, cool. I'll mark it as qa-ok :)
<Ursinha> thanks!
<jcsackett> np.
<jcsackett> with luck, full fix will land today.
<thumper> huwshimi: please can I talk to you at the start of squad time?
<huwshimi> thumper: Will it take long. I need to have a meeting with someone else and have that scheduled straight up
<thumper> huwshimi: I just want to point to some styling bugs in LP
<thumper> huwshimi: should just be 1 or 2 minutes
<huwshimi> thumper: ok no problems then
<vanguard> is this the right address if I fail to build a source package?
<thumper> vanguard: it is good enough, what's up?
<vanguard> I just fell for the - and _ in the orig.tar.gz name
<jml> huwshimi: we might have to reschedule. I wasn't expecting this talk.
<vanguard> now I got another problem, I have  Depends: default-jre (>= 1.6) in my control file
<vanguard> when I run debuild, it tells me that (>= 1.6 is no valid version
<thumper> wgrant: can you help?
<vanguard> where did that ) go?
<thumper> or bigjools
<wgrant> vanguard: Please pastebin your control file.
<vanguard> sure
<vanguard> http://pastebin.ubuntu.com/556236/
<james_w`> vanguard, you need a comma before default-jdk on the Build-Depends line
<thumper> huwshimi: bug 705548
<_mup_> Bug #705548: Multiline editor needs CSS tweaks <css> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/705548 >
<huwshimi> thumper: Thanks for that
<thumper> np
<vanguard> james_w`: okay, there is .deb now. I have to check it out
<vanguard> the package is opened by gdebi, but in the file list is nothing of my project. How do I tell debuild to pack the .jar file into the .deb?
<vanguard> sry, g2t
<vanguard> g2g
<jml> mpt:
<jml> mpt: http://people.canonical.com/~jml/convergence/
<vanguard> I build a source package, but after "debuild", I have a package that only contains the changelog and stuff, but not my actual .jar file. How do I add it?
<bigjools> vanguard: try #ubuntu-motu for packaging questions
<LPCIBot> Project db-devel build (321): FAILURE in 5 hr 10 min: https://hudson.wedontsleep.org/job/db-devel/321/
<LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12239,
<LPCIBot> 12240, 12241 included.
<pcjc2> hi, lifeless - rather than just fix the cve case, I've started a search for all dubious SQL which employs a sub-select
<pcjc2> my search is based on grep and manual checking so far, but if I come up with a list, I'll file a meta-bug for the issue
<pcjc2> bugtask.py is looking like a strong culprit
<pcjc2> Any chance you could paste me some sanitized stats on where I might most usefully look to fix first?
<pcjc2> In case it is of interest to anyone, my commit hook robot code:
<pcjc2> (WIP)
<pcjc2> http://pastebin.com/8m2cWXZ3
<pcjc2> and the git part: http://pastebin.com/ahF1U3RX
<pcjc2> It is a two-part hook / update process, the hook uses git shell commands to populate a sqlite DB
<pcjc2> The update process pulls work items out of the sqlite DB and uses launchpadlib to make updates to bugs
<pcjc2> The only snag so far is that it can't handle private bugs, for the project as it is not subscribed to them. I could add the robot to our developers team, but I can't handle the extra email it would generate - the robot's email address forwards to me
<pcjc2> So far I've found 11 candidates in the code-base for SQL improvement
<pcjc2> (And that is with the very crude search assuming the appropriate statements are on the same line)
<pcjc2> http://pastebin.com/3Ln9z4qg
<pcjc2> https://bugs.launchpad.net/launchpad/+bug/705582
<_mup_> Bug #705582: Metabug: Inefficient sub-select SQL in LP causes performance issues <Launchpad itself:New> < https://launchpad.net/bugs/705582 >
<pcjc2> Not much chat in here at the moment - wrong time-zone, or is there a conference or something
<maxb> The canonical folks are all still at their sprint, IIRC
<pcjc2> ah, that would explain their absence
<pcjc2> I just found this: http://www.markshuttleworth.com/archives/239
<pcjc2> That video mockup is pretty amazing - is that the shape of things to come?
<pcjc2> (I realise the post is old)
<spiv> pcjc2: adding nice ajax-y stuff to improve usability?  Yes
<lifeless> pcjc2: hi :) want to see more crazy sql ?
<vanguard> is a subselect something that performs another select based on every single result from the first query?
<lifeless> thats a correlated subquery
<lifeless> a subselect is a form of subquery
<lifeless> whether its correlated or not depends on whether it depends on any variables in the containing query
<pcjc2> hi lifeless - fire away with the SQL
<pcjc2> I'm not promising I'll fix them all - just felt bad for not filing the bugs after I discovered those other cases
<pcjc2> I'm thumb-twiddling whilst I wait for our project's "maintainer" / founder to get on and test my LP update robot scripts no his server.
<pcjc2> Absentee landlord is no fun - and he's the only one with root / admin access on that server
 * pcjc2 is like a child with ADHD demanding constant attention - likes feedback soon, does not like waiting 2 or more days to test the code he's just finished writing
<lifeless> pcjc2: :)
<pcjc2> The video here.. http://www.markshuttleworth.com/archives/239
<lifeless> bug 705224 was entertaininy
<_mup_> Bug #705224: Distribution:EntryResource:searchTasks timeout <dba> <regression> <timeout> <Launchpad itself:Triaged by lifeless> < https://launchpad.net/bugs/705224 >
<pcjc2> was that a "live" mockup witih real AJAX, or heavily edited?
<pcjc2> was the regression in bug 705224  related to my recent change to fix the timeout searching for -* tags?
<_mup_> Bug #705224: Distribution:EntryResource:searchTasks timeout <timeout> <Launchpad itself:Triaged by lifeless> < https://launchpad.net/bugs/705224 >
<lifeless> I think it was a manual mockup
<lifeless> certainly we don't have that yet
<lifeless> pcjc2: it was related yes, thats why I mention it to you :)
<pcjc2> I'll take a look
<lifeless> pcjc2: the relation is that the UNIONs before used to be a single query over the tags
<lifeless> pcjc2: oh, its fixed.
<lifeless> pcjc2: but sure, have a look at the fix if you're interested
<pcjc2> I did wonder if we ought to be combining the multiple tag queries inside the WHERE clause
<allenap> rvb: me!
<rvb> allnap: same name on lp?
<pcjc2> lifeless - are tags gauranteed unique?
<pcjc2> if so, "might" be able to optimise the all tags case too, abusing count
<pcjc2> (SELECT COUNT(*) FROM (SELECT TRUE FROM BugTag WHERE BugTag.bug = Bug.id AND BugTag.tag IN ('foo', 'bar', 'baz')) = 3)
<pcjc2> assuming the input tags are all distinct (could write some python to ensure that if necessary), the query should return an equal number of rows to the number of tags we asked for IFF all those tags exist
<pcjc2> question is... would this "hack" / creative use of SQL give any useful speed-up for any real-world queries being seen?
<pcjc2> I presume that if this was a regression - the DB engine was doing a better job of merging the uncorrelated UNION subqueries
<rvb> allenap: I'm browsing through trivial bugs. Many of them look like they've been fixed already ... can you check this one https://bugs.launchpad.net/launchpad/+bug/298288 to make sure I'm not completely wrong about this?
<_mup_> Bug #298288: Feature Request: PPA file display should allow sort by header <lp-soyuz> <ppa> <trivial> <Launchpad itself:Triaged> < https://launchpad.net/bugs/298288 >
<allenap> rvb: Yeah. Do you want to mark it Invalid?
<rvb> allenap: I'll do it
<rvb> allenap: and to a few others bugs as well
<allenap> rvb: Cool :)
<pcjc2> http://people.canonical.com/~jkakar/storm/storm.sqlobject.SQLObjectBase.html#selectOne
<pcjc2> Undocumented
<pcjc2> What kind of SQL fragment does selectOne expect? (Or what kind of query would it expand to?) *** (checks storm sources)
<wgrant> pcjc2: You should ideally not use selectOne, since that's part of the legacy SQLObject compat layer.
<wgrant> grep around for '.one()'
<wgrant> That's the new Storm WayÂ®
<pcjc2> not new code - I was just looking to see if I could identify an SQL optimisation
<bigjools> depends on what type of result set he's got
<bigjools> consistency FTW
<pcjc2>        job = CodeImportJob.selectOne(
<pcjc2>             """id IN (SELECT id FROM CodeImportJob
<pcjc2>                WHERE date_due <= %s AND state = %s
<pcjc2>                ORDER BY requesting_user IS NULL, date_due
<pcjc2>                LIMIT 1)"""
<wgrant> bigjools: .selectOne is a method on a SQLObject class.
<wgrant> Not a resultset.
 * bigjools needs more coffee
<pcjc2> The question in theory - is whether that expands to something which gets correlated against for lots of rows
<wgrant> .... huh?
<wgrant> Does that make any sense?
<wgrant> id IN (SELECT id ...)
<pcjc2> given that line of code... does it produce a horribly inefficient query, as was the cause for bug 501945
<wgrant> I'd use this:
<pcjc2> I wasn't convinced it would do anything other than return TRUE or FALSE
<pcjc2> which seemed like an odd kind of thing to pass to a method which allegedly selects one result
<pcjc2> lp/code/model/codeimportjob.py line 134
<pcjc2> It happened to be the first on my list of suspicious SQL things I found and noted in Bug #705582
<wgrant> job = IStore(CodeImportJob).find(CodeImportJob.date_due <= whatever, CodeImportJob.state == whatever).order_by(Desc(CodeImportJob.requesting_user), CodeImportJob.date_due).first()
<_mup_> Bug #705582: Metabug: Inefficient sub-select SQL in LP causes performance issues <Launchpad itself:Invalid> < https://launchpad.net/bugs/705582 >
<pcjc2> I'm going to file bugs for all cases where I can determine some better SQL, but without being able to link these to real issues people are seeing, change for the sake of change seems like regression potential
<pcjc2> IStore is part of storm?
<lifeless> pcjc2: perhaps; we're not seeing timeouts on the 'all' case atm
<lifeless> pcjc2: we have -very- good feedback on slow queries, so I'm kindof inclined to change broken things only.
<pcjc2> sounds fair enough
<lifeless> that siad, CIJ had some issues
<pcjc2> Any matchup between the ones I noted and the hit-list of bad SQL?
<lifeless> and that select seems a workaround for separation between clause and results
<pcjc2> That code-import fragment I posted has me confused to what it even does
<pcjc2> id IN (...) should evaluate to TRUE or FALSE, right?
<lifeless> it acts as a where clause that sqlobject will use reasonably
<lifeless> yes
<lifeless> pcjc2: or NULL perhaps, I'd need to check.
<pcjc2> job = CodeImportJob.selectOne(<something which evaluates to TRUE or FALSE>) seems like an odd bit of code to run
<wgrant> pcjc2: It selects the single row that matches the condition.
<lifeless> yeah, its odd because of an old layer we're migrating from
<pcjc2> so it is a WHERE clause gragment?
<pcjc2> fragment, sorry
<lifeless> its a where clause
<pcjc2> SELECT ... WHERE id IN (...)
<lifeless> sqlobject is magic and special
<pcjc2> so it could be "CodeImportJob.id = id AND date_due <= %s AND state = %s ORDER BY requesting_user IS NULL, due_date LIMIT 1"
<lifeless>  no
<lifeless> not with sqlobject
<lifeless> needs to be stormified
<pcjc2> is sqlobject pretending to execute SQL on something which is not in the DB?
<lifeless> no, its pretending not to execute sql
<lifeless> its a complex story
<lifeless> best thing is to move to Store.find(CIJ, ....) instead
<lifeless> with .one()
<pcjc2> I doubt I can do anything truly useful here, but I will file a bug for someone with area-knowledge to triage
<pcjc2> I don't think code-import is something I'll be able to test very easily locally
<lifeless> so that doesn't look like a bug
<lifeless> its oddly written
<lifeless> but should be fast
<lifeless> why do you think its a bug?
<wgrant> lifeless: It's actually .first(), not .one(), I think. But it's spelt as a selectOne with a subquery that only matches the first.
<lifeless> meh, yes.
<StevenK> lifeless: Like pcjc2 is saying, he is following a pattern that a badly-written subselect was causing timeouts, so maybe others do the same.
<pcjc2> all depends on row count really - bugtags is probably a very high count table, at about 700k rows
<lifeless> StevenK: thanks; I meant why does he think *this* one is a problem.
<huwshimi> deryck: Available when you're ready
<StevenK> I suspect it just happens to be the first one on the list.
<lifeless> pcjc2: this query is already constrained though: note that the query is looking for next thing due
<lifeless> its answerable from index.
<deryck> huwshimi, ah, cool.  give me 5 minutes to wrap and we can.
<deryck> huwshimi, shall I come to you or you to me?
<pcjc2> yes, just first on list - it seemed odd, and I still can't quite map what SQL it ends up executing
<pcjc2> you are right though - work from known timeouts, rather than poking at supposed problems
<huwshimi> deryck: Great. I can come to you. Everyone is working quietly here so lets not disturb them :)
<pcjc2> IStore, etc.. is Storm?
<deryck> huwshimi, ok, first room on left going down left-side hallway.
<huwshimi> deryck: ok see you soon
<pcjc2> Hmm - example from storm docs:
<pcjc2> store.find(Person, Person.name == u"Joe") and store.find(Person, name=u"Joe")
<pcjc2> Seems like unholy magic to me
<pcjc2> 'Person.name == u"Joe"' is somehow passed as argument, not evaluated immediately to give True / False?
<StevenK> It is passed as an argument and Storm intreprets it
<leonardr> thumper, the javascript side of things is in lib/canonical/launchpad/icing/build/bugs/bugtask_index.js and it's pretty hairy
<jelmer> lifeless: resubmitted.
<huwshimi> deryck: Just held up here for a bit, will be over soon
<pcjc2> StevenK, I need to go read up more on Python... the fact it is somehow an argument and not evaluated before the call is magical to me
<deryck> huwshimi, no worries
<pcjc2> does it have anything to do with lazy evaluation?
<mwhudson> pcjc2: the implementation of the == operator doesn't have to return true or false...
<pcjc2> ah - so it IS evil magic going on ;)
<pcjc2> And presumably the "Person" object in the example is typed such that the == operator has a specific implementation?
<StevenK> It's likely done via SQLObject *and* Storm so that both implement __eq__
<pcjc2> I'm reading the code, and I'm still non the wiser how it works
 * StevenK is fairly ignorant of Storm internals
<pcjc2> NM though.. it will keep me entertained trying to learn how.. Evil evil magic is still my best guess
<pcjc2> Is it a design choice to go more ORM style, and less explicit SQL queries?
<lifeless> jelmer: thanks
<lifeless> pcjc2: operator overloading
<lifeless> pcjc2: yes, its evil
<pcjc2> It seems pretty evil
<lifeless> ORM is a bit of a mistake; late evaluation leads to death-by-single-row-retrieval
<pcjc2> I'm sure someone more knowledgeable than I has decided it is a good idea though
<lifeless> long term goal is a mapping layer that answers service-point entire answers
<pcjc2> service-point is for example, http://lp.net/project/+bugs  ?
<lifeless> a search page, sure
<pcjc2> launchpadlib API is a "sort" of ORM type affair?
<pcjc2> I found that very intuitive to work with
<lifeless> sort of yes
<lifeless> its why its so slow ;P
<pcjc2> can't have everything I guess
<pcjc2> When people are not so busy sprinting, I'd love to have a chat about various ideas
<pcjc2> Mostly feature-request stuff, but the kind most usefully bounced of other people before just filing a bug titled "wouldn't this be nice..."
<lifeless> sure
<lifeless> anytime is good
<pcjc2> I was thinking that LP might usefully grow a "person" type object for automatons / robots
<pcjc2> (I've been writing one recently, so it is in my mind)
<pcjc2> They would be owned by a person or team, but delegate contact via that team - not requiring their own Email address or OpenID login / whatever
<pcjc2> IE.. a way to auth against LP for API use which doesn't require setting up a pretend person to do it
<allenap> jtv: From the API, a list of Bugzilla trackers can be obtained with: [bt for bt in root.bug_trackers if bt.bug_tracker_type == 'Bugzilla']
<pcjc2> Have also been thinking about controls to navigate collections of bug search results from within the bug page. UI still going through my head though
<dobey> pjdc: you could call the object IRobot
<pcjc2> might be a TM on that one
<lifeless> so, in page refresh is definitely already desired
<dobey> what would be awesome is a way to use the API with basaic auth
<dobey> basic even
<dobey> or digest anyway
<lifeless> I have extremely mixed feelings about that
<pcjc2> https://launchpad.net/~gpleda-launchpad-robot
<pcjc2> The fact that the robot is a person doesn't map well to our usage
<pcjc2> It needs to get subscribed to security bugs so it can close them
<pcjc2> but I _dont_ want it to get bugmail
<dobey> i don't want *me* to get bugmail
<pcjc2> that too ;)
<lifeless> ok
<pcjc2> I understand that is a WIP regarding bugmail granularity though
<lifeless> so we have an answer for this already
<lifeless> yeah
<lifeless> its well advance
<lifeless> if you ask gary_poster nicely you may be able to be in the alpha
<pcjc2> ok, will do
<dobey> lifeless: what reservations re: basic/digest auth?
<lifeless> dobey: well, we use ssl so on that front its fine
<lifeless> handshaking with canonical-identity-provider / other openid environments is darn tricky.
<pcjc2> In page refresh would be awesome - I was thinking about remembering the "view" or "search query" / whatever, you were doing when you clicked on the bug, and giving "Next" "Prev" controls
<lifeless> in terms of standards... there are none
<lifeless> pcjc2: that would be awesome too
<pcjc2> In page update when people comment (reverse AJAX push) would be amazing, but perhaps a corner case
<dobey> yeah i know, which is why doing oauth is so horribly painful
<dobey> i guess that launchpad isn't exactly the openid provider any more though, so basic/digest auth is trickier now
<pcjc2> OpenID seems like a nice proposition
<dobey> openid/oauth are solutions looking for a problem
<pcjc2> if it were my server / wiki, I would re-write the auth for our project's wiki to link to user's LP OpenIDs
<pcjc2> We could tie the permissions to team membership on LP
<mwhudson> teams in openid are some launchpad specific extension though aren't they?
<mwhudson> which is a bit of a shame
<pcjc2> I'll admit I don't fully understand OpenID,
<pcjc2> I looked at oauth, and it seemed a vaguely sensible way for an API to authenticate
<dobey> i just don't want to have to authenticate my browser twice
<leonardr> dobey: can you be more specific about "authenticate my browser twice"?
<pcjc2> I assume dobey is talking about having to login to the SSO / login.launchpad.net, and then auth launchpad.net to those credentials
<lifeless> dobey: right, we no longer maintain an authentication db
<dobey> leonardr: i want to make an extension for my browser that uses lp api to do certain things when viewing certain launchpad pages, and having to authenticate that separately is weird
<pcjc2> weird, but IMO necessary
<dobey> i don't think it's necessary
<dobey> it is however, cumbersome and painful
<leonardr> dobey: if you're in the browser, you can use the same-domain version of the web service that the ajax application uses, which will carry over the browser's authentication
<leonardr> but it depends on how close your code is to the browser
<dobey> leonardr: if i'm in the browser, or "if i'm in the JS" ?
<leonardr> dobey: if you have access to the Cookie header being sent by the browser
<dobey> by "extension" i mean "c, python, similar"
<dobey> leonardr: so i can just re-use the sessionid cookie to talk to the api?
<leonardr> dobey: that's what the web browser does
<dobey> leonardr: so i can pass that cookie through launchpadlib?
<leonardr> no
<dobey> :(
<leonardr> but that's what allows the browser to make these requests
<leonardr> we could add that functionality but it would immediately be abused by everyone who's not writing a browser extension
<leonardr> and it would have all sorts of bad edge cases surrounding logout
<dobey> i really do not want to reimplement launchpadlib :(
<leonardr> dobey: does it make you feel better to know that in natty, all desktop-wide apps will use the same oauth authorization?
<dobey> no
<leonardr> dobey: do you understand my position?
<pcjc2> How will they share that auth token? DBus or something?
<pcjc2> gnome-keyring-manager?
<leonardr> pcjc2: keyring-manager by default
<dobey> ubuntu-sso-client
<dobey> which is per-app, not per-target
<dobey> but anyway
<dobey> leonardr: i understand what you're saying, but i don't think it's a particularly strong argument for doing it the way it's currently done. it wouldn't really take much more effort to abuse the browser stuff as it is, it seems. although it's tedious enough that i might not bother with it myself
<dobey> brb
<leonardr> dobey: "tedious enough that i might not bother with it myself" is the only hurdle i need to clear
<mrevell> huwshimi, with reference to bug 263652, you rock
<_mup_> Bug #263652: {i} and other icon codes no longer work on help wiki <Launchpad Help Wiki Moin theme:Fix Committed> < https://launchpad.net/bugs/263652 >
<dobey> leonardr: yes, but everyone isn't an old bitter and jaded developer like me :)
<leonardr> dobey: i just need to stop this code from getting into supported ubuntu packages
<leonardr> dobey: i think you can implement Cookie: passing pretty easily by overriding some methods in Launchpad
<leonardr> and implementing your own Http subclass
<dobey> leonardr: i don't want to touch javascript
<leonardr> i mean the Launchpad class of launchpadlib
<dobey> ah ok
<leonardr> if this is code for yourself then that's fine, but if you want to put it into ubuntu we will have to reach some other compromise
<dobey> i'm writing a browser, and would like to keep everything contained within it
<leonardr> dobey: if you're writing the whole browser, you should be able to intercept launchpadlib's webbrowser.open call and open that page in your already-authenticated browser, avoiding the second authentication
<leonardr> does that make any sense?
<dobey> slightly
<leonardr> dobey: i have absolutely no problem helping you with this, if this is the way you want to go
<dobey> i'm a long way from that point still, but it will require a lot more thought
<huwshimi> mrevell: Yeah no problems. Still needs to be pushed live at some stage
<leonardr> dobey: ok, ping me. i think we can get a solution that makes us both happy
<dobey> ok
<dobey> cheers for now
<bigjools> lifeless: allenap just did an experiment with TAL to see if that macro re-evaluation was true, and it doesn't seem to re-eval if it's an int at least.  Maybe it's only for complex objects.
#launchpad-dev 2011-01-21
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project db-devel build (322): FIXED in 4 hr 52 min: https://hudson.wedontsleep.org/job/db-devel/322/
<BjornT_> losa: is codehosting down again?
<LPCIBot> Project devel build (382): FAILURE in 4 hr 32 min: https://hudson.wedontsleep.org/job/devel/382/
<LPCIBot> * Launchpad Patch Queue Manager: [r=sinzui, stevenk,
<LPCIBot> thumper][ui=none][bug=663857] Fixes timeout on $product/+packages
<LPCIBot> page, for real.
<LPCIBot> * Launchpad Patch Queue Manager: [r=leonardr][ui=none][bug=423149] Allow editing of the recipe's daily
<LPCIBot> build PPA
<LPCIBot> * Launchpad Patch Queue Manager: [r=allenap][ui=none][bug=660433] Update support-timeframe info for
<LPCIBot> NEW packages. Thanks to Michael Vogt.
<lifeless> BjornT_: its up for me
<BjornT_> lifeless: yep, works for me now as well. previously i had the same symptoms as when it was down earlier today
<lifeless> what were those symptoms
<lifeless> i was approximately asleep
<lifeless> === Top 10 Time Out Counts by Page ID ===
<lifeless>     Hard / Soft  Page ID
<lifeless>      231 / 2453  Distribution:EntryResource:searchTasks
<lifeless>      136 /  287  BugTask:+index
<lifeless>      106 /  238  Distribution:+bugs
<lifeless>       67 / 4407  Archive:+index
<lifeless>       28 /    1  Distribution:+builds
<lifeless>       20 /   69  Branch:+index
<lifeless>       18 /    8  ProjectGroup:+milestones
<lifeless>        8 /   18  DistroArchSeries:+index
<lifeless>        8 /    4  Person:+bugs
<lifeless>        7 /    9  Cve:+index
<lifeless> thumper: https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html - I'm not sure how to qa the next few
<lifeless> which are you
<thumper> lifeless: done
<lifeless> thanks!
<poolie> mrevell, http://blog.launchpad.net/general/code-hosting-offline - you can edit if you wish, or forward that to the list
<mrevell> Thanks poolie. Looks great. I've sent a less detailed note to the launchpad-announce list.
<lifeless> Ursinha: https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html - see rev 12232
<lifeless> its shown twice. Is there a bug about that ?
<wgrant> lifeless: It has two bugs.
<Ursinha> as wgrant said
<lifeless> wgrant: I know it does; and I can guess at the cause. But is there a bug about it happening
 * bigjools thinks we should qa revisions, not bugs
<lifeless> bigjools: indeed; see the LEP, timeliness etc
<bigjools> :)
<Ursinha> lifeless, this is a known reported bug
<lifeless> ok, thanks
<lifeless> oh foo, qatagger needs codehosting up :(
<wgrant> We need multiple frontends :(
<StevenK> So does much of our development process -- buildbot, pqm, hudson ....
<lifeless> wgrant: and backends
<lifeless> wgrant: this is on the server with DAS
<wgrant> lifeless: Right, multiple frontends sort of implies a shareable backend.
<lifeless> wgrant: but sharable isn't sufficient ;)
<wgrant> Preferably a redundant SAN :)
<bac> http://typewith.me/eF5FgNClQv
<gary_poster> what was the link again, please?
<lifeless> 04:55 < bac> http://typewith.me/eF5FgNClQv
<gary_poster> thank you
<seiflotfy> gary_poster,
<seiflotfy> got a moment
<seiflotfy> i get
<seiflotfy> bzr branch -r78 lp:zeitgeist-dataproviders totem-zg
<seiflotfy> ssh: connect to host bazaar.launchpad.net port 22: Connection timed out
<seiflotfy> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<gary_poster> seiflotfy: codehosting had a machine failure.
<seiflotfy> gary_poster, so i can use it again soon
<gary_poster> I understand it will be fixed < 2 hrs but that's my hearsay
<lifeless> http://blog.launchpad.net/general/code-hosting-offline
<gary_poster> ty
<gary_poster> flacoste: is there a way to force the blog message to show up on https://launchpad.net/ ?
<flacoste> gary_poster: memcached
<lifeless> I think the tag is 'frontpage' or something
<lifeless> we can delete the key from memcache
<flacoste> lifeless: it's memcached
<flacoste> yep
<gary_poster> is that a losa task?
<lifeless> would need a losa; also needs some figuring out of the means, its not something we've documented before
<gary_poster> ah, k :-/
<flacoste> gary_poster, lifeless: i'm not sure how to find out which keys it is
<gary_poster> stub might
<lifeless> we can disable memcache trivially
<gary_poster> just kick it, even?
<gary_poster> that front page stuff actually makes a diff AFAIK
<lifeless> add a rule: memcache default 0 disabled
<gary_poster> ops channel: Topic changed to "codehost off fire"
<gary_poster> seiflotfy: retry?
<seiflotfy> gary_poster, works
<gary_poster> great
* lifeless changed the topic of #launchpad-dev to: Launchpad Development Channel | PQM is open | firefighting: - | Get the code: https:/â/âdev.launchpad.net/âGetting
<wgrant> lifeless: Any idea what's up with the buildbot failures?
<lifeless> wgrant: codehosting crashed
<wgrant> lifeless: That's not it.
<wgrant> lifeless: There were librarian failures before crowberry melted down.
<lifeless> wgrant: 12242 was broken
<lifeless> 12245 backed that out
<lifeless> 12245 built ok
<lifeless> 12247 built ok
<lifeless> 12252 crowberry killed
<StevenK> 12252 has a failing test in Hudson, which I can reproduce locally.
<wgrant> In particular, build 540
<wgrant> https://lpbuildbot.canonical.com/builders/lucid_lp/builds/540/steps/shell_6/logs/summary
<wgrant> No codehosting issues, but two errors and one failure.
<StevenK> I'm happy to consider the errors spurious
<StevenK> I've forced a build, just to get PQM unlocked and to see if they really are.
<wgrant> They're not.
<wgrant> They've occurred 2 or 3 times.
 * wgrant checks Henkins.
<StevenK> They didn't occur on Hudson
<StevenK> Hudkins? :-P
<wgrant> Interesting.
<wgrant> Maybe the buildbot slave is boken again.
<StevenK> Like I say, a build is in progress
<jcsackett> i got those errors back on an ec2 run after updating from devel.
<lifeless> so its one of 12248->52
<wgrant> Hudson doesn't see the librarian issues, though, and they showed up before xx-person.txt.
<wgrant> So I think the buildbot slave might have librarian issues.
<mpt> matsubara, https://wiki.ubuntu.com/QATeam/PerformingSRUVerification
<Ursinha> mpt, https://wiki.canonical.com/OEMServices/QA
<matsubara> mpt, http://iso.qa.ubuntu.com/
<gmb> allenap: Remind me: where does the code for security stuff (like defining what launchpad.Admin means for an object) live?
<allenap> gmb: Search for security.py; there are several.
<gmb> allenap: Ta.
<allenap> gmb: You need to combine that with the zcml for the object's interfaces.
<gmb> allenap: Right. I was just thinking that it would be nicer to use that than adding a mutator for BugSubscription.bug_notificaiton_level
<allenap> gmb: Yeah.
<allenap> gmb: I did some stuff around that recently.
<allenap> gmb: Ah, I did it on IStructuralSubscription; I broke it up into *Public and *Restricted interfaces.
<gmb> allenap: Right. This is somewhat simpler, thankfully.
<wgrant> leonardr: http://paste.ubuntu.com/556600/
<wgrant> danilos: Er, did you merge stable, or devel?
<wgrant> danilos: devel is broken, so you probably just broke db-devel too :(
<wgrant> Except that looks more like stable, contrary to the commit message.
<danilos> wgrant, unless my branch is broken, it's not
<danilos> wgrant, I merged just *my* revision ;)
<danilos> wgrant, commit message is an obnoxious lie
<wgrant> Ahhh, the commit message says that you merged devel.
<wgrant> Heh.
<danilos> sorry
<wgrant> Good.
<huwshimi> Anyone available to review a js fix (bug #687564): https://code.launchpad.net/~huwshimi/launchpad/licence-widget-overlap-687564/+merge/47084
<_mup_> Bug #687564: license widget sections overlaps on projectgroup +newproject and projects/+new <bug-1> <javascript> <lazr-js-upgrade> <lp-registry> <regression> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/687564 >
<wallyworld_> lifeless: can you let me know when you have a minute to show me the sql stuff we discussed?
<thumper>     if IObject.providedBy(field) and not IReference.providedBy(field):
<thumper>         raise TypeError("Object exported, should be a Reference.")
<leonardr> thumper, https://code.launchpad.net/~leonardr/lazr.restful/stop-using-object/+merge/47106
<leonardr> gary, benji , quick question. how do i set up a global download cache for buildout? i got a new computer and am now fetching packages every time i need to build
<benji> leonardr: http://pastebin.ubuntu.com/556662/
<poolie> jml, could you read https://dev.launchpad.net/LEP/BuildFromBranchIntoMain#preview for me?
<lifeless> wallyworld_: will do
<StevenK> lifeless: WTB Data::Dumper for Python
<jml> poolie: sure.
<jelmer> StevenK: pprint ?
<jml> flacoste: ping
<lifeless> StevenK: pprint!
<jml> poolie: looks like a good start.
<leonardr> it looks like bin/kill-test-services is broken
<leonardr>   File "bin/kill-test-services", line 39, in <module>
<leonardr>     from canonical.librarian.testing.server import LibrarianTestSetup
<leonardr> ImportError: cannot import name LibrarianTestSetup
<StevenK> lifeless: pprint is a poor replacement.
<leonardr> the class is not present in the file--maybe it was renamed?
<wgrant> It's not clear what kill-test-services means now.
<wgrant> But yes, it is broken.
<jcsackett> does anyone know why a branch made via factory.makeBranch doesn't show up if you're then connecting via the testing launchpadlib instance?
 * jcsackett hopes he's just doing something stupid.
<lifeless> leonardr: yes it was - sorry
<lifeless> untested code is broken code ;)
<lifeless> its now LibrarianServerFixture
<james_w> jcsackett, commit needed?
<jcsackett> james_w: as in transaction? tried that, no dice. :-/
<james_w> hmm
<jml> poolie: can you add the constraints that prevent us from just making a trivial recipe and using bzr-builder?
<jml> james_w: btw, you also might like to scribble over https://dev.launchpad.net/LEP/BuildFromBranchIntoMain
<james_w> certainly
<leonardr> thumper: bug 706099
<_mup_> Bug #706099: Move bug-specific fields out of lp.services.fields <refactoring> <thunderdome> <Launchpad itself:New> < https://launchpad.net/bugs/706099 >
<thumper> just running the webservice tests now
<thumper> I think we are going to be good
<jml> which spelling is less surprising:
<jml> MatchesSetWise or MatchesSetwise
<leonardr> the second one
<jml> What about MatchesListwise
<bigjools> what about MatchesByList or is that semanticaly different?
<bigjools> <speeling mistaks are not mine>
<thumper> [testfix] landing
<jml> hmm. it's a thing that takes a list of matchers [A, B, C] and then matches them against a list of things [a, b, c], such that 'a' must match 'A', etc.
<LPCIBot> Project devel build (383): STILL FAILING in 4 hr 55 min: https://hudson.wedontsleep.org/job/devel/383/
<jml> e.g. self.assertThat([1, 2, 3], MatchesByList(Equals(1), Equals(2), Equals(3)))
<mtaylor> you guys use rabbitmq for something, don't you?
<jml> flacoste: hi
<lifeless> we will
<lifeless> canonical does
<lifeless> lp not yet
<wgrant> mbarnett: Hi.
<flacoste> jml: hi, i'm Riviere
<mbarnett> o/ wgrant
<mtaylor> lifeless: oh, ok. so I should bug statik then...
<wgrant> mbarnett: Where are you? thumper wishes to visit.
<lifeless> mtaylor: 'sup?
<mtaylor> lifeless: I'm trying to figure out how to launch and then stop a rabbitmq in a sandbox not as root
<lifeless> oh
<mbarnett> wgrant: thumper: i am currently up in the tech room, but i can wander down.  should i be bringing my computer or is this just to chat?
<mtaylor> I've got launching down - but there doesn't seem to be any way to inform rabbitmqctl about having launched rabbit on a different port
<lifeless> I'm not sure
<lifeless> :P
<wgrant> mbarnett: Bring your computer -- he's in the Bazaar Sprint room.
<jelmer> there is a Bazaar sprint room?
<thumper> jelmer: well, it says that on the door
<jelmer> interesting
<StevenK> The room is Esmeralda
<wgrant> thumper: Oh, right, we're not actually in testfix at the moment.
<wgrant> So it may have been your missing QA tags.
<leonardr> i don't know if this is related to my earlier librarian complaint, but now i can't start up librarian to run tests, and it is the same class as earlier
<leonardr>   File "/home/leonardr/canonical/lp-branches/web-link/lib/canonical/librarian/testing/server.py", line 81, in setUp
<leonardr>     self.config_fixture.add_section(self.service_config)
<leonardr> AttributeError: 'NoneType' object has no attribute 'add_section'
<poolie> what's meant to be in 'sourcecode' within m ylp branch directory?
<poolie> symlinks to ../../lp-sourcedeps/sourcecode
<leonardr> poolie: yes
 * leonardr thinks he has the librarian problem figured out
<leonardr> it only happens when i set LP_PERSISTENT_TEST_SERVICES
<LPCIBot> Project devel build (384): ABORTED in 1 hr 43 min: https://hudson.wedontsleep.org/job/devel/384/
<LPCIBot> * Launchpad Patch Queue Manager: [r=sinzui][ui=none][bug=705469, 705489,
<LPCIBot> 705564] Fix a few more download-missing and performance bugs in the
<LPCIBot> PPA Apache log parser.
<LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][ui=none][no-qa] Convert StructuralSubscription to native
<LPCIBot> Storm class.
#launchpad-dev 2011-01-22
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project devel build (385): FIXED in 4 hr 31 min: https://hudson.wedontsleep.org/job/devel/385/
<LPCIBot> * Launchpad Patch Queue Manager: [r=julian-edwards][ui=none][bug=691478] Convert
<LPCIBot> ArchiveView.latest_updates to be a cachedproperty to remove 2
<LPCIBot> 800ms queries from the archive index page.
<LPCIBot> * Launchpad Patch Queue Manager: [rs=thumper][ui=none][no-qa] Fix the xx-person.txt due to webservice
<LPCIBot> changes, and associated fallout.
<thumper> yay
<lifeless> Ursinha: btw - https://devpad.canonical.com/~lpqateam/qa_reports/logs/output-launchpad-stable.log - looks like perhaps the cron job is disabled or something ?
<lifeless> wgrant: bug 706200 may interest you, both as its near to your heart, and the actual cause of slowdown
<_mup_> Bug #706200: Archive:EntryResource:getPublishedBinaries timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/706200 >
<lifeless> ola
#launchpad-dev 2011-01-23
<lifeless> wgrant: when is your flight (if you're not flying already)
<lifeless> moin moin
<jelmer> lifeless: ohai
<lifeless> jelmer: hola!
#launchpad-dev 2012-01-16
<StevenK> nigelb: Yes
<nigelb> StevenK: fun! same flight as poolie?
<rick_h__> ouch, fortunately no delays on my end. Closer to feeling like normal finally
<nigelb> They had a baggage truck run into an A380.
<rick_h__> that sounds fairly not good
<nigelb> I like was poolie said - "Sounds expensive"
<rick_h__> StevenK: what's the latest/greatest for taking a setup.py into a .deb?
<nigelb> Whats the commandline way to propose a merge? I forget.
<mwhudson> nigelb: lp-propose i think?
<jelmer> mwhudson: hey, did you see my email about feature flags?
<mwhudson> jelmer: no, i don't think so
<mwhudson> jelmer: subject/list?
<jelmer> mwhudson: the subject was something about feature flags too
 * jelmer looks through his mail
<mwhudson> jelmer: when did you send it?
<mwhudson> pretty sure i don't have it, anyway
<jelmer> somewhere last week I think
<jelmer> I think there's just something that's been eating my mail anyway
<mwhudson> ah
<mwhudson> fun :/
<jelmer> mwhudson: basically, I was wondering how to use the new awesome XML/RPC feature flag server you added
<jelmer> I couldn't find any examples of existing users
<mwhudson> oh right
<mwhudson> i don't think there are any uses yet
<jelmer> that would explain why I couldn't find any :)
<nigelb> mwhudson: Strange. It isn't autocompleting for me.
<nigelb> Command not found.
<mwhudson> nigelb: what isn't ?
<mwhudson> oh, lp-propose
 * mwhudson shouldn't be relied on for lp dev advice really any more :)
<nigelb> heh
<nigelb> I'll just wait for everyone to wake up after their long week.
<rick_h__> nigelb: for me the ones that autocomplete are lp-propose-merge lp-propose and lp-submit
<rick_h__> but I've not setup a MP from the cmd line
<nigelb> rick_h__: lp-propose works? can you do a which lp-propose and tell me where the binary is?
<rick_h__> nigelb: it's part of a bzr command
<rick_h__> bzr lp-propose
<rick_h__> is where I was completing it from
<nigelb> ah
<nigelb> rick_h__: Thanks! Its been a while since I did LP work and I forgot how to do it :)
<rick_h__> nigelb: np
<jelmer> mwhudson: I'd like to use the feature flags XML/RPC server in codehosting, but I'm not entirely sure where to start. Any recommendations on where to look for inspiration?
<mwhudson> jelmer: from a bzr serve process or the ssh server?
<jelmer> mwhudson: from the ssh server
<mwhudson> it's all reasonable simple i hope -- sp = ServerProxy(config.whatever); sp.getFeatureFlag('codehosting.feature')
<mwhudson> t.w.Proxy & callRemote then?
<mwhudson> jelmer: ff for the forking process?
<jelmer> mwhudson: yeah, forking process and git support
<mwhudson> ah right
<mwhudson> i guess i'd stuff that in during authentication
<jelmer> mwhudson: whoa, that seems a lot simpler than I was going for
<jelmer> mwhudson: during, rather than after ?
<mwhudson> jelmer: i'm sorry i didn't make it more complicated :)
<mwhudson> jelmer: mm don't know i guess
<jelmer> mwhudson: np, thanks for the hints. I think this should be sufficient to get me started
<mwhudson> jelmer: i guess it depends a bit on the appropriate api where you want to make the decision supporting having a deferred returned
<nigelb> I wonder if anyone out in the east is working today
<lifeless> 'today'
<nigelb> heh
<nigelb> lifeless: I *think* I fixed the url bug. I created 2 new methods for it. Would that work?
<nigelb> (one for logo and one for mugshot)
<lifeless> I saw the patch, haven't read it yet.
<lifeless> will talk later
<jtv> morning folks
<nigelb> Hey jtv! "Morning" :)
<jtv> Hi!  I'm in Europe, so a bit weird with timezones.
<nigelb> Oh!
<nigelb> I thought you'd be home. Indeed, I was confused.
<jtv> Not your fault, of course.
 * SpamapS is in the US, but still pretty much on EU timezones. :)
<nigelb> Are you in the gang that's in Vienna?
<jtv> No
<jtv> SpamapS: enjoy the spontaneous early mornings while you can!
<nigelb> Unless you're the west coast and up at 2 am :P
<nigelb> correction, 12 am.
<SpamapS> jtv: I slept from 01:00 - 06:00, then again from 09:30 - 14:00 .. now its 00:14 and I'm wide awake. :-P
<jtv> Hmm maybe not so convenient then.
<nigelb> Morning rvba. Up for reviewing today? :)
<SpamapS> especially confusing since "today" is supposed to be a holiday... but I came away from the rally with more TODO's than I went into it with... ;)
<nigelb> haha
<nigelb> that happens to me at UDSes ;-)
<nigelb> Even when I'm not actaully there.
 * SpamapS cannot complain though, it was 19C today in LA ... :)
<nigelb> I'm guessing Budapest was really cold :D
<SpamapS> 1C - 5C for the duration.. not awful.. but not warm.
<nigelb> UDS was pleasant 20s except for the Sunday before.
<SpamapS> The hotel's covered courtyards make it hardly matter.. was possible to get "sun" without leaving.
<nigelb> Heh
<nigelb> I'm glad we were lucky to be there in the summer.
<rvba> Hey nigelb, sure.
<nigelb> https://code.launchpad.net/~nigelbabu/launchpad/logo-links-713873
<rvba> I'll have a look.
<nigelb> I'm also curious to know what I can test here.
<rvba> nigelb: I've got an urgent matter to sort out right now but I'll take a look at your branch right after I've sorted it.
<rvba> :)
<nigelb> rvba: no worries, take your time :)
<danhg> morning everyone
<rvba> Morning frankban, danhg.
<danhg> Did you get home OK guys?
<frankban> morning
<rvba> Flight ok, crappy plane ;).
<danhg> Who did you fly with?
<danhg> I slept all the way on mine :)
<rvba> Malev
<danhg> ah, OK
<rvba> Did you have a direct flight?
<StevenK> Last I heard, wgrant was still en-route.
<rvba> Damn!
<danhg> I wouldn't be surprised
<StevenK> 17 hour delay in LHR for him
<danhg> ah no
<danhg> nightmare
<rvba> StevenK: looks like the French lesson paid off, you're using French expressions now ;)
<nigelb> Yeah, poolie's gang stole their flight apparently.
<nigelb> StevenK: wallyworld as well.
<StevenK> That was poolie and me
<nigelb> Aha. Right.
<nigelb> They got a hotel room, dinner, breakfast, and money for calls.
<StevenK> So QF32 is an A380, and as we boared the pilot said that someone has hit an engine with a baggage cart
<StevenK> So poolie and I got delayed by 5 hours due to that.
<danhg> 'hit an engine with a baggage cart' - thats a new one
<nigelb> You guys got the next A380 and they had to wait for a new one I guess?
<StevenK> We "borrowed" another A380, which was for QF10 -- so wgrant and his gang got delayed 13 hours (as well as the original 5 hour layover)
<bigjools> I used to think LHR could not get worse but they continue to prove me wrong
<nigelb> danhg: That was my first thought as well.
<StevenK> We flew into Singapore at midday local time, at which point we couldn't leave due to the curfew at Sydney.
<danhg> Was your train OK bigjools?
<StevenK> So I had seven hours in Singapore
<nigelb> StevenK: curfew?
<nigelb> oh, at Sydney.
<bigjools> danhg: yup
<danhg> What's the curfew?
<StevenK> nigelb: Planes can not land or take off in Sydney between 11pm and 6am
<nigelb> bigjools: Wait, you took a train from Budapest?
<nigelb> StevenK: what!?!?!
<danhg> Woah
<bigjools> nigelb: !  no, from the airport to my house
<nigelb> bigjools: I'd have been extra jealous if that was the case :P
<bigjools> LHR has the same curfew
<nigelb> That's an interesting curfew.
<danhg> Haven't heard of these before
<nigelb> Is it because its in a residential area?
<bigjools> yes
<StevenK> So my original arrival date was 15/1 8:30pm. I landed it Sydney at 16/1 6:20am
<danhg> Did you have a productive day? lol
<nigelb> That explains that. Bangalore airport is 40 km away from "Bangalore".
<adeuring> good morning
<StevenK> danhg: I don't know, what day is it?
<nigelb> heh
<StevenK> It took me 40 hours to get from the hotel in Budapest to my house.
<StevenK> wgrant is likely pushing 50
<danhg> Tuesday, 4th March
<StevenK> RAOF may well hit 60.
<danhg> Maybe we could covert travel hours into karma points
<danhg> convert^
<nigelb> lol
<StevenK> danhg: Every Australian at the sprint gave up two full weekends to travel.
<StevenK> nigelb: pitti had to catch one train to get home from Budapest.
<StevenK> nigelb: Mind you, it took eight hours.
<danhg> Morning mrevell
<mrevell> Hey morning
<danhg> We're comparing delay nightmares :)
 * bigjools starts upgrade to precise on desktop machine
<mrevell> danhg, Oh? Not a good journey home?
<nigelb> StevenK: Hey I love trains. The longer the better.
<danhg> No mine was fine, apart from a huge taxi due to the tubes being screwed. The Aussies seem to have had a bit of a nightmare tho
<nigelb> StevenK: 8 hours on a train sounds better than 50 hours in airports + flights anyway
<danhg> Where was your train to?
<StevenK> mrevell: Some numpty at LHR drove a baggage cart into an A380 engine.
<nigelb> Forver, this sprint will be remembered as the one where "someone drove a baggage cart into an A380".
<StevenK> mrevell: Caused 13 hours of delays for poolie and I, and about 22 for wgrant and cohorts.
<bigjools> "You have to download a total of 1402 M."
<mrevell> StevenK, Blimey. A380 engines seem to be a bit of a problem. That's awful. 22 hours!
<StevenK> mrevell: It took me 40 hours of travelling from the hotel to my place -- with about 4 hours sleep.
<StevenK> I'm not even sure if wgrant is even home yet.
<nigelb> You guys should just move all LP meetings to Singapore :P
<mrevell> StevenK, In which case, get off IRC and get to bed :)
<StevenK> mrevell: No, I need to push through and get to bed at a normalish time
<StevenK> Otherwise I'm just screwed jetlag wise
<nigelb> that must suck.
<nigelb> the whole "stay up till its dark so you don't screw your sleep cycle" bit.
<StevenK> Welcome to living in Australia.
<StevenK> bigjools, are you taking notes?
<nigelb> haha
<nigelb> wait, bigjools is moving?
 * bigjools is
<nigelb> wow
<nigelb> Canonical office in Australia soon? ;)
<mrevell> Does anyone know how badly huwshimi was affected by the delay?
<StevenK> I think he's with wgrant
<nigelb> I know wallyworld is with wgrant
<StevenK> So after they get to Melbourne, there is another flight to Hobart
<StevenK> mrevell: Worse than I was, I'd wager.
<mrevell> Lord, that's crazy.
<nigelb> Reason #1343 why you shouldn't live in Australia :P
<wgrant> Evening.
<wgrant> wallyworld transferred to a flight to Brisbane.
<wgrant> RAOF was not so lucky.
<wgrant> But I am home.
<wgrant> After 48 hours.
<StevenK> wgrant: Ouch
<soren> So you guys left Budapest (presumably) on Saturday morning-ish and got home Monday evening?
<wgrant> soren: Yeah
<wgrant> Left the hotel at 10:30am
<soren> Good grief.
<stub> Who got stuck in transit?
<wgrant> stub: RAOF is stuck in Melbourne for the night.
<wgrant> As he missed the last Hobart flight.
<wgrant> But everyone else is on their final flight, AFAIK.
<soren> How much of those 48 hours were you airborne?
<wgrant> soren: 23
<soren> Good grief.
<stub> My record for delays is only 8 hours IIRC. They finally gave up trying to fix the plane, shuffled us to a hotel, and woke us all up 1 hour later. Cheap idiots.
<nigelb> wgrant: Ah, you got home!
<soren> These are completely regular planes, right? Coach is as dreadful as on any other plane? For 23 hours?
<wgrant> soren: Well.
 * soren gets back aches just thinking about it.
<wgrant> Yes
<wgrant> But I got randomly upgraded to Business for the last 8 hour leg.
<soren> \o/
<wgrant> Which was very nice.
<nigelb> wgrant: Where in Australia are you? Sydney?
<wgrant> Melbourne.
<nigelb> aha
<wgrant> It's the Sydney bastards that stole our plane :)
<nigelb> haha
<nigelb> wgrant: when did you get home? Just now?
<wgrant> nigelb: 40 minutes ago
<nigelb> wow.
<danhg> You must have aged 10 years on such a journey.
<danhg> You must look 25 or something.
<wgrant> Heh
<danhg> :)
<nigelb> Wait, so he looks 15 "normally"? :P
<danhg> Don't get too excited Nigel
<jtv> What was the key combination for getting at my system menu again?  I need to reboot to get my mouse pointer back but now the regular <alt>-<shortcut> menu access stopped working.
<jtv> Oh well, there's always the text console.
 * cjwatson wonders if anyone has done initial assessments of the dependency tree for porting Launchpad to Python 3
<bigjools> I can guess who *might* have done that
<jelmer> cjwatson: I'm not sure if that's really worth the effort just yet, until zope has been ported
<rick_h__> yea, I'm curious. But if you look at the py3 wall of shame you see a ton of zope stuff on there
<rick_h__> though I agree with Chris and others that the wall of shame kind of sucks
<cjwatson> no immediate need or anything, just curious whether it might inform our priorities for providing ports in Ubuntu
<frankban> hi everybody, can anyone figure out what happened here? https://pastebin.canonical.com/58178/ Something went wrong while applying db patches in qastaging, the same patches are correctly applied in devel.
<jtv> frankban: that sounds badâ¦ you may want to ask stub tomorrow.
<frankban> jtv-afk: thanks
<lifeless> is there a bug about the bugcolumns showing 'tags: None' when there are no tags on a bug ?
<abentley> lifeless: I believe there was.
<lifeless> cool
<abentley> lifeless: bug 894734
<_mup_> Bug #894734: "Assignee: None" and "Tags: None" clutter bug listings <bug-columns> <Launchpad itself:Triaged> < https://launchpad.net/bugs/894734 >
<lifeless> abentley: thanks
<abentley> james_w: Any idea about this? https://bugs.launchpad.net/launchpad/+bug/914634 note it says 'cStringIO.StringI'!
<_mup_> Bug #914634: AttributeError: 'cStringIO.StringI' object has no attribute 'split' in parse_changelog <Launchpad itself:Confirmed> < https://launchpad.net/bugs/914634 >
<james_w> abentley, https://bugs.launchpad.net/launchpad-buildd/+bug/915505
<_mup_> Bug #915505: bzr: ERROR: exceptions.AttributeError: 'cStringIO.StringI' object has no attribute 'split' <Launchpad Auto Build System:New> < https://launchpad.net/bugs/915505 >
<james_w> jelmer is the knower of all things
<abentley> james_w: thanks.
<lifeless> anyone noticed that saving tags now requires 2-3 presses of the tick ?
<lifeless> flacoste: wlecome back :)
<lifeless> flacoste: want to catch up?
<flacoste> lifeless: unless there is anything urgent, i'd postpone to tomorrow
<flacoste> trying to finish setting up work items for this Maas project
<lifeless> sure thing
<jelmer> abentley, james_w: we're still waiting for python-debian to be updated on the builders
<lifeless> uds was the only thing I have as a needs-disucssio
<flacoste> right
<lifeless> that and
<lifeless> I plan to sweep into RT after I wrap up bugs
<abentley> jelmer: how big is the impact?
<lifeless> any objection / themes you'd like me to honour ?
<jelmer> abentley: it only impacts version 0.4 recipes (which have never worked - because they require this new python-debian version)
<flacoste> lifeless: no objections, theme: the old "making sure staging is up to what we need" might be useful to re-assess
<lifeless> flacoste: will do
<lifeless> abentley: I've generated a new oops for bug 908886 for you
<abentley> jelmer: Okay, I'm gonna mark it "high" rather than "critical", then.
<_mup_> Bug #908886: OOPS on loading bug page <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/908886 >
<abentley> lifeless: Oh, you shouldn't have :-)
<lifeless> abentley: :) least I could do :P
<abentley> lifeless: I did not get an oops with the link given, so it must be a borderline timeout.
<lifeless> abentley: it may be group related
<lifeless> abentley: I'm in Ubuntu bugcontrol, you are not.
<lifeless> abentley: which means I can do nominations.
<abentley> lifeless: could be.
<lifeless> abentley: I had a brief nosy round the oops; data is in the bug if you are looking into it. If not, it is there for the next person.
<abentley> lifeless: I was just triaging.
<lifeless> abentley: no worries then :)
<StevenK> wallyworld: You got home okay?
<StevenK> lifeless: Did you get any delays/knock-on effects from the fun that at least wgrant and I endured?
<wallyworld> StevenK: finally. took around 50 hours door-door
<wallyworld> StevenK: i think your plane was the one that got hit?
<StevenK> wallyworld: Yes, QF32's A380 was the one that got hit with the baggage cart.
<jelmer> abentley: any chance you can mark bzr-pipeline as supporting bzr 2.5? The test suite seems to work fine with 2.5b5 (the last beta for 2.5)
<wallyworld> StevenK:  so why did "our" plane get repurposed :-(
<wallyworld> StevenK: how long did your final journey take? i think you were delayed about 5 hours in london?
<StevenK> wallyworld: I'm not sure -- QF32's staff said they were sourcing a "spare" A380. I don't think it was spare so much as waiting ...
<wallyworld> .... for "ours" to arrive from melbourne
<StevenK> wallyworld: 40 hours door-to-door. I was delayed by 5 hours in London and 7 in Singapore.
<wallyworld> 7 in singapore? why?
<wallyworld> did they look after you?
<StevenK> Curfew in Sydney
<wallyworld> ah, how stupid is that
<StevenK> And yeah, they farmed us out to a hotel in the CBD
<wallyworld> no european airport has a curfew i don't think
<StevenK> LHR does, according to Julian
<wallyworld> well, they are stupid too
<StevenK> wallyworld: So Sydney airport is surrounded by residental development.
<StevenK> Well, on three sides.
<StevenK> The other side is water
<wallyworld> and people who buy next to airports know there will be noise
<StevenK> wallyworld: Right, but the noise carries a fair way -- how long distance wise do you think a plane takes to climb and descend?
<wallyworld> a long way, but for most of it it is relatively high and only in a narrow corridor
<wallyworld> curfews are not too evil unless one is delayed 7 hours by one :-)
<StevenK> wallyworld: Keep in mind the corridor can only really support one, maybe two planes.
<StevenK> And Sydney has 3 runways, so you're looking at six, possibly seven corridors
<wallyworld> yeah, i was trolling somewhat. lack of sleep makes me mean
<wallyworld> have only been home 10 hours
<StevenK> wallyworld: I was Zombie Steve yesterday
<wallyworld> did you find any yummy brains to suck
<StevenK> Nope
<StevenK> wallyworld: BAH
<StevenK> wallyworld: You took the last card on the board
<lifeless> StevenK: no, different carrier :P
<StevenK> lifeless: Air NZ?
<lifeless> yep
<StevenK> But still via LHR and SIN?
<lifeless> HK
<lifeless> LHR->HK->AKL->CHC
<StevenK> Oh, wow
<lifeless> I walked in the door at 1530 yesterday
<StevenK> wallyworld, lifeless: Announcement on BA865 from Budapest to London: "We'd like to offer all of you duty free for purchase. However, the cabinet is locked. So if any one of you has a pair of bolt-cutters with them, we'd first like to congratulate you on getting them through security, and if you could please make them available to us."
<wallyworld> StevenK: surely you jest?
<StevenK> wallyworld: It's what they said. The entire plane laughed.
<wallyworld> at least they have a sense of humour
<wallyworld> security in budapest is pretty lax though
<lifeless> StevenK: wicked
<lifeless> StevenK: I was on 869 I think, they didn't say that :P
#launchpad-dev 2012-01-17
<nigelb> Morning!
<nigelb> StevenK: haha, airline staff with a sense of humour! Nice :)
<abentley> jelmer: sure.
<lifeless> wgrant: is hotness qa-ok ?
<wgrant> lifeless: No idea, been doing other stuff since it appeared on qas.
<wgrant> Will QA now.
<wgrant> lifeless: Is the bounty removal not done?
<wgrant> IIRC all that was left was the DB schema, which I removed months ago.
 * wgrant greps
<wgrant> Nope, all gone.
<wgrant> lifeless: Yes
<wgrant> Actually
<wgrant> Should do ppa/ftpmaster tonight.
<wgrant> Ursinha's DB patch and garbo job tomorrow
<wgrant> Then EmailAddress.account dies on whatever the day after that is.
<wgrant> Lies.
<StevenK> Hm?
<wgrant> canonical/launchpad/mars :)
<StevenK> Ahh
<StevenK> wgrant: I agree with ppa/ftpmaster tonight for FDT, FWIW.
<wgrant> !FDT
<wgrant> But yes
<StevenK> The FDT window, you pendant. :-P
<wgrant> fdt refers to the DB update. We've had mistakes in the past around this confusion.
<wgrant> So we need to be clear.
<wgrant> lifeless: Can you remind me why we can't use GIN yet?
<nigelb> wgrant: OCRing today?
<wgrant> Oh, bah, it's Tuesday now.
<wgrant> Maybe.
<StevenK> Haha
<nigelb> Did you work through the night?
<wgrant> nigelb: rvba reviewed your branch last night, AFAICT.
<wgrant> No
<nigelb> He did?
<nigelb> bah
<nigelb> dammit, how did I miss that email :|
<nigelb> Interesting. My email doesn't think Lp reviews are priority anymore.
 * nigelb changes that.
<lifeless> wgrant: table scans
<lifeless> StevenK: 'pedant'
<nigelb> I did wonder about pendant :P
 * StevenK hits lifeless's engine with a baggage cart, stranding him in Heathrow.
<nigelb> heh
<wgrant> lifeless: Confused
<wgrant> Clearly the index is not being used properly if it invokes a table scan.
<wgrant> Ah, it doesn't support full index scans, I see.
<wgrant> Bug #119780 ftr
<_mup_> Bug #119780: bug comment full text search is disabled - GIN indices in pg 8.2 do not support table scans <lp-bugs> <search> <Launchpad itself:Fix Released by stub> < https://launchpad.net/bugs/119780 >
 * StevenK stares at Storm
<StevenK> The validator insists 'depends-on+987' is not a valid name.
<wgrant> "The validator"?
<StevenK> valid_name SQL function
<wgrant> Ah, so nothing to do with Storm.
<wgrant> You sure you don't have a newline or space or something in there?
<StevenK> wgrant: http://pastebin.ubuntu.com/807006/
<wgrant> Oh
<wgrant> valid_tag is not valid_name
<StevenK> CONSTRAINT valid_tag CHECK (valid_name(tag))
<wgrant> Ah, but it is.
<wgrant> Perhaps it wants a list?
<wgrant> What's the SQL that it generates?
<wgrant> I suspect it may be splitting on + or similar
<StevenK> It uses for tag in tags, which does it per char for a string
<StevenK> Which is ... handy
<StevenK> NoCanonicalUrl: No url for None because None broke the chain.
<StevenK> Bah
<wallyworld> bollocks. latest NDT breaks javascript on merge proposal pages
<wallyworld> and also on code index page
<nigelb> whats's NDT?
<wgrant> nigelb: nodowntime deployment
<wgrant> wallyworld: Hm, what's the impact
<wgrant> ?
<wgrant> MP pages don't have much non-beta JS
<nigelb> AHA.
<wgrant> And code index JS is not used much
<wallyworld> wgrant: the code index breaks such that the branch filter drop downs don't work
<wgrant> Indeed.
<wallyworld> wgrant: it's becuase a mochikit method connect() is being used in the tal
<wgrant> I suspect that is used little, however. If the fix is simple, I suggest fixing rather than rolling back.
<wallyworld> so i can work on that
<wallyworld> haven't looked at the mp breakage yet
<wallyworld> yes, i agree we should try and fix
 * wallyworld hates stupid embedded javascript in the tal page templates :-(
<wgrant> MP JS seems to be entirely broken, but the fallbacks all work fine.
<wallyworld> yep, the js breaks early on in the load/parsing phase
<wgrant> Ah
<wgrant> It looks for div#add-comment-form
<wgrant> But on MPs it's form#add-comment-form
<wgrant> I think bug commenting is broken too :)
<wgrant> lib/lp/app/javascript/comment.js has an undefined trim()
<wgrant> Perhaps it means Y.Lang.trim
<wallyworld> wgrant: that's fallout from deryck's work to sort out bug comments last week
<wallyworld> i can fix that also
<wgrant> But we need to revert
<wgrant> spm: ^^
<wgrant> Since it breaks after the fallback is disabled.
<spm> revert what/where?
<StevenK> Revert the NDT we just did
<StevenK> Just the appservers is fine
<wgrant> Right.
<wgrant> wallyworld: http://paste.ubuntu.com/807058/ fixes the bug comment thing. It's the last trim() callsite AFAICT.
<wallyworld> wgrant: otp, just give me a sec
<wallyworld> wgrant: cool. i'm currently fixing the remaining uses of mochikit connect
<wallyworld> then there's just the form#add-comment vs div#add-comment thing
<wgrant> MPs fixed
<wgrant> Yeah
<wgrant> Just s/div// fixes it
<wgrant> Looking for other breakage
<wallyworld> wgrant: no, the div was put there to make something else work
<wallyworld> so the solution is not as simple as s/div//
<wallyworld> i'll look into it
<wgrant> -        this.comment_input = Y.one('[id="field.comment"]');
<wgrant> +        this.comment_input = Y.one(
<wgrant> +            'div#add-comment-form [id="field.comment"]');
<wgrant> is the relevant diff
<wgrant> The div was not added -- the whole first selector was.
<wgrant> We also have something on the MP page trying to set patting-bottom
<wgrant> But I assume that's unrelated.
<wallyworld> yes, any arse patting is unrelated
<StevenK> wgrant: http://pastebin.ubuntu.com/807064/ :-(
<wgrant> Work out what the object is.
<wgrant> Debuggers are handy :)
<wgrant> AND IDES ARE NOT MANDATORY
<spm> itt, wgrant admits to using ed for all his editing needs
<StevenK> Haha
<wgrant> Nah, was an inb4 pycharm from wallyworld.
<wallyworld> not mandatory but a shit load more productive for anything but simple debugging work
<StevenK> wgrant: Sadly obj is None
<wgrant> StevenK: Right -- you'll probably want a conditional breakpoint on the parent calculation
<StevenK> Breaking in canonical_urldata_iterator() the first obj is a IBug
<wgrant> Do you know if that's the same call?
<wgrant> The most common thing to generate that error is a bugmessage.
<wgrant> Not a bug.
<StevenK> Grabbing obj from the iterator gives a whole bunch of things then:
<StevenK> <BugTask for bug 16 on <Product at 0xff1b890>>
<StevenK> None
<_mup_> Bug #16: "Swedish" and "Swedish (Sweden)" should be the same language <lp-translations> <Launchpad itself:Fix Released by daf> < https://launchpad.net/bugs/16 >
<spm> wgrant: reverted to 14664 on the appservers
<StevenK> spm: Thanks!
<wgrant> spm: Thanks
<StevenK> Bloody MochiKit
<StevenK> wgrant: Don't get it :-(
<wgrant> StevenK: Trace through where it's obtaining the None.
<StevenK> wgrant: The menu code is implicated. Which hooks into TAL, and debugging that is madness.
<StevenK> wgrant: Since it looks like MenuBase._init_link_data() is called twice, once where self.context is Product, and again where it is None
<StevenK> Calling <lp.bugs.browser.bug.BugContextMenu object at 0x1036e810>.initLink('affectsmetoo', 'http://launchpad.dev/')
<StevenK> And that menu's context is None, which gets into canonical_url
<wgrant> wallyworld: How go the fixes? We should either fix it all or readd mochikit and fix the div#comment-add-form thing within 45 minutes.
<wgrant> Or we'll miss the next buildbot run.
<wallyworld> wgrant: i thought we were doing a rollback?
<StevenK> We rolled back prod
<StevenK> Not the rev
<wgrant> wallyworld: Production is reverted, but all deployments are now blocked.
<wgrant> And there is some very interesting stuff which now cannot be deployed.
<wgrant> => fixing this is top priority
<wallyworld> that's what i'm doing
<StevenK> wgrant: How does this menu stuff work? :-(
<wgrant> StevenK: Not very well
<wgrant> StevenK: But you're probably instantiating the view incorrectly, or using the wrong layer.
<wallyworld> but i have to refactor to make it yui compatible, and that has issues the way the js is embedded
<wgrant> If it's going to go past EOD, we need to revert the relevant revisions.
<wgrant> I think all but one issue is fixed by readding mochikit.
<wallyworld> i'll get it fixed soon
<StevenK> wgrant: Looks the same as everything else in that test?
<rick_h__> wallyworld: the JS stuff ok? Anything you need a hand with real quick?
<wallyworld> rick_h__: no, i've got it under control. just mindless refactoring. thanks for asking. only a couple of places left to change
<rick_h__> wallyworld: ok cool. back to bed then. Thanks!
<wallyworld> see ya
 * StevenK stabs this test
<lifeless> poolie: another interesting thing to look at - https://secure.phabricator.com/
<wgrant> Why do all of their buttons look like Facebook?
<lifeless> because facebook made it ?
<wgrant> Ah
<lifeless> http://www.phabricator.com/docs/phabricator/
<wgrant> wtf
<wgrant> cannot access it at all without logging in.
<lifeless> http://phabricator.org/ has an overview
<poolie> that's a bit creepy
<wgrant> It's a bit Facebook.
<poolie> > Facebook engineers rave about Phabricator, describing it with glowing terms like "okay" and "mandatory".
<poolie> nice
<poolie> yeah looks a bit locked to their approach
<poolie> i wish lp's bug search ui was a bit like  https://secure.phabricator.com/maniphest/?g=o
<wallyworld> wgrant: https://code.launchpad.net/~wallyworld/launchpad/more-mochikit-fallout/+merge/88814
<wgrant> poolie: I think a less crap search UI can be built on top of the new sort UI.
<nigelb> heh, I search and I see all of you on top :)
<wgrant> (in 2015)
<poolie> i was thinking about eventually doing power search
<poolie> ie "assigned:wgrant status:inprogress"
<nigelb> wgrant: (in 2015). Hah.
<poolie> .. i feel i would just about know how to do it
<poolie> not at the top of my queue
<wgrant> poolie: I think that was proposed in 2005
<poolie> yes, i know
<nigelb> One of the things I like about bugzilla is awesome search.
<poolie> by tim and me, in at least one of the proposals
<poolie> wgrant, however search is timing out so much of the time.. i think that ought to be fixed first
<wgrant> wallyworld: Isn't LPS deprecated?
<wgrant> wallyworld: Or did you renege on that?
<poolie> it would also be neat, though less urgent, to do some kind of machine-learning-based estimation of how far in the future a bug will be closed
<wgrant> poolie: Bah, it's only like 90% of our timeouts.
<wallyworld> wgrant: it is, but i thought we were still using it until we cut over. i'll check
<wgrant> wallyworld: I really have no idea. I just heard discussion last week.
<wallyworld> wgrant: we use it for now
<wgrant> kk
<lifeless> poolie: that estimate is easy: never; correct for 99% of bugs :P
<poolie> haha
<wallyworld> wgrant: it means there will be a little cleanup when the new stuff needs to get merged ie one mor ecase to port
<wgrant> wallyworld: So, MP pages now turn green, bug commenting works, and branch filtering/sorting works?
<poolie> but, not true in at least some contexts
<poolie> a bit over half of valid bzr bugs have been fixed
<wgrant> There's also an XSS you can fix here, if you want :)
<wallyworld> wgrant: yes. with mp, i created one and ensured i could add a comment
<wgrant> Oh, in fact that's the one that was reported a couple of weeks back.
<wallyworld> wgrant: point me to the xss
<wgrant> It's left as an exercise for the reader.
<wgrant> (you correctly translated a setting of innerHTML to setContent, which has the same escaping behaviour: none at all. And then user input is passed into that)
<wallyworld> i thought i was fixing a xss by doing that ie that setContent did the escaping. i think i need setText then
<wallyworld> i always get them mixed up
<wgrant> Right, that would work.
<wgrant> YOu also need to change the default name to '<name>' in that case.
<wgrant> setContent is to be deprecated and replaced with setHTML, I believe.
<wallyworld> i saw the xss and tried to fix it, but clearly didn;t quite get it right
<wgrant> Because it's a hilariously deceptive name, as we see here.
<wgrant> http://yuilibrary.com/projects/yui3/ticket/2531467
<wgrant> So, set('text', foo)
<wallyworld> yep
<wgrant> Bug 911635
<StevenK> I wonder if pycharm did that to him.
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/calculateOldBinaries-use-denorm/+merge/88816 if you're still reviewing.
<wgrant> StevenK: For that I would review any time :)
<wgrant> Intriguing.
<StevenK> wallyworld_: I didn't know pycharm had a "Kill Quassel" button.
<wallyworld_> StevenK: it doesn't but precise does :-(
<StevenK> wgrant: I'm still wondering if the if len(name_ids) test is even needed any more.
<StevenK> wgrant: And which bit is?
<wgrant> StevenK: The fact that wallyworld_ has a tail
<wgrant> Despite the old one quitting before it.
<wgrant> Oh, it only parted.
<StevenK> wgrant: Removing the if len(name_ids) short circuit works, and drops the diff to +23/-32
<wgrant> StevenK: The short-circuit is tiny optimisation, but still an optimisation.
<wgrant> I don't know if it's still a major win, though.
<wgrant> It's cheap to keep, so keep it for now.
 * StevenK rewrites it to if not name_ids
<StevenK> wallyworld_: What killed Quassel, anyway?
<wgrant> No.
<wallyworld_> StevenK: no idea. i closed and reopened it because it lost its network
<wgrant> StevenK: implicit bool() on sequences when resultsets (which often lack a useful __nonzero__) are involved is a little worrying.
<wgrant> StevenK: Why do you still join against BPN?
<wgrant> For that matter, why was it joined against BPN in the first place/
<wgrant> Oh
<StevenK> Haha
<wgrant> Because that's what it's actually getting.
<StevenK> Right
<wgrant> Carry on then.
<StevenK> wgrant: The status = ( ... definition in the method made me go O.o
<wgrant> Approvalised, anyvay.
<wgrant> Now, you probably want to try this out somewhere like DF
<wgrant> And work out what indices would help.
<StevenK> Really?
<wgrant> eg. possibly one on bpph(archive, distroarchseries, status, binarypackagename)
<wgrant> Although it's probably not quite smart enough to know to use that.
<StevenK> The indices on BPPH make me cry.
<wallyworld_> wgrant: thanks for reviewing. i'll throw it as ec2 and hopefully by morning it will be throught bb also
<wgrant> wallyworld_: No
<wgrant> wallyworld_: lp-land
<wallyworld_> wgrant: i changed code, so i want to send it via ec2 to be sure
<wgrant> wallyworld_: This is unlikely to break tests, and even if it does break them we're no further behind.
 * StevenK waits for postgres on mawson
<wgrant> We cannot deploy until this is landed.
<wallyworld_> ok. but if bb breaks....
<wgrant> Then we still can't deploy until it's fixed.
<wgrant> But the US people will know what the failures are.
<wgrant> It's not dependent on you being awake and responsive.
<wgrant> If buildbot doesn't break, we've saved 5 hours.
<StevenK> wallyworld_: Given buildbot didn't fail this when mochi was killed makes me think it isn't tested.
<wgrant> If it does break, we have to fix it before we can deploy either way.
<wgrant> The only mitigating factor is that buildbot takes 1.5h longer than ec2
<wallyworld_> ok
<StevenK> Come ON, mawson
<wgrant> StevenK: I probably murdered its caches.
<StevenK> I want cold data anyway
<wgrant> Not *that* cold.
<StevenK> So I was going to SELECT * from BranchRevision for about 5 minutes before I switch queries.
<wgrant> I just did a few full bug+bugsubscription reads and a few million writes to new tables.
<wgrant> So there's probably not much cache left anyway.
<wallyworld_> wgrant: can you lp-land it for me. bzr blew up just now when i tried with a AttributeError: 'BranchConfig' object has no attribute 'get' error
<wgrant> wallyworld_: Awesome
<wgrant> Sure
<StevenK> How did you run it?
<wallyworld_> thanks. url is https://code.launchpad.net/~wallyworld/launchpad/more-mochikit-fallout/+merge/88814
<poolie> wallyworld_, that sounds like a plugin version mismatch
<wallyworld_> bzr lp-land
<poolie> depending on th tb
<wallyworld_> poolie: only thing i've done today is delete a local installed xmloutput plugin so that the packaged one is used
<poolie> please pastebin the traceback?
<wallyworld_> poolie: https://pastebin.canonical.com/58207/
<jelmer> wallyworld_: that seems like an outdated bzr-pqm plugin
<wallyworld_> jelmer: i've never installed bzr-pqm manually, only via the packaged debs
<poolie> jelmer, ah, passing the wrong config object in to smtpconnection?
<wallyworld_> i upgraded to precise last friday
<jelmer> poolie: yep
<wallyworld_> it worked before then
<jelmer> wallyworld_: ah, hmm
<wallyworld_> sorry, just been called up for dinner. will check back a bit later
<StevenK> wgrant: http://pastebin.ubuntu.com/807139/
<StevenK> wgrant: New query with the same data is *massively* faster.
<wgrant> Huh?
<wgrant> 9s->4s is not massively faster :)
<wgrant> It's still two orders of magnitude off what it should be.
<StevenK> wgrant: 405783 / 112251 versus 16705 / 3792
<StevenK> That could be because mawson is still cache starved.
<wgrant> Erm
<wgrant> Those plans are the same.
<wgrant> One is hot.
* wgrant changed the topic of #launchpad-dev to: devel broken until r14681 | https://dev.launchpad.net/ | On call reviewer: [] | Firefighting: - | Critical bugtasks: 3*10^2
<StevenK> wgrant: Indeed. Editor fail
<StevenK> wgrant: http://pastebin.ubuntu.com/807144/
<wgrant> StevenK: That is slightly more like it :)
<wgrant> Still terrible, but not OMGIWANTTODIE
<StevenK> Haha
<wgrant> What's the query?
<wgrant> I shall hoptimise.
<StevenK> wgrant: http://pastebin.ubuntu.com/807147/
<wallyworld_> jelmer: anything i can do to help diagnose the problem?
<wgrant> StevenK: 64ms
<wgrant> Let's see if I can go lower.
<jelmer> wallyworld_: I think I know what needs to happen
<jelmer> wallyworld_: we'll need to upload a new bzr-pqm to unstable/precirse
<wallyworld_> jelmer: ok. thanks :-)
<wallyworld_> good to find this stuff early i guess
<poolie> jelmer, i guess we could consider it a break in the smtp library and support the old interface
<poolie> ie if isinstance etc
<wgrant> StevenK:     "temp_binarypackagepublishinghistory" btree (archive, distroarchseries, status, binarypackagename)
<wgrant> StevenK: And add a DISTINCT to the query
<wgrant> 30-50ms on DF
<wgrant> Which is still slightly high, but not bad.
<StevenK> wgrant: .config(distinct=True) , right?
<wgrant> StevenK: Correct.
<StevenK> wgrant: I'll toss that at ec2. We can hit up stub for the index
<wgrant> Yeah
<tvoss> Good morning
<mrevell> Hello devils
<nigelb> Morning mrevell
<jelmer> hello mr revell
<adeuring> good morning
<wgrant> lifeless: accesspolicyartifact.policy as an integer[] with intarray and gist == fast
<lifeless> sweet
<wgrant> (intarray's in contrib, though)
<lifeless> I've been meaning to test tags as an array
<lifeless> wgrant: contrib stuff is ok, we ran fti that way for a while
<wgrant> I suspect it would be fast.
<wgrant> But you'd need to intify them
<lifeless> oh, gist only takes ints?
<wgrant> intarray only takes ints
<wgrant> You'd need a separate GiST implementation for strings.
<lifeless> anyhow, night
<wgrant> GIN would work better, but has the same issues as with fti
<wgrant> Night!
<StevenK> wgrant: I guess r14680 is untestable
<wgrant> StevenK: Both taken care of.
<allenap> wgrant: Do you know how I can land lp:~takluyver/lazr.uri/py3? I tried PQM and I tried just approving it (hoping there was a Tarmac somewhere), but without success.
<wgrant> allenap: Hmm
<wgrant> We can commit directly to it.
<wgrant> But it looks like PQM was used at one point.
<wgrant> [/home/pqm/archives/rocketfuel/lazr.uri/trunk]
<wgrant> published_at=bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/lazr.uri/trunk
<wgrant> PQM is still configured for it, but trunk has been moved...
<wgrant> I'd just commit directly.
<allenap> wgrant: Cool. Thank you :)
<rick_h__> morning
<lifeless> wgrant: http://www.pgsql.cz/index.php/PostgreSQL_SQL_Tricks#xpath_function_indexing
<Laney> can somebody help me move https://code.launchpad.net/~laney/launchpad/spph-sponsor along?
<jcsackett> sinzui: thanks for doing my qa, and sorry i forgot about it.
<sinzui> Laney, Only lifeless can approve the branch for db-devel. I expect lifeless to be available in 5 hours
<sinzui> jcsackett, np. I have a habit of checking the state of Lp when I wake up every day
<sinzui> though today required hacks to lp's dev scripts because bzr has changed api in precise
<jcsackett> fun times.
<rick_h__> jcsackett: weren't you saying I needed to do to prep for review mentorship? Mail a list/check a box? I don't see anything in the wiki
<jcsackett> rick_h__: i'm composing an email to you; it's actually not prep work.
<jcsackett> just time slot, and then on thursday i'll walk you through reviewing over skype/mumble in the morning.
<jcsackett> rick_h__: also, is this your preferred irc nick, or do you have trailing underscores today for nick collision reasons?
<rick_h__> jcsackett: rick_h is the preferred, but yea I get trailing undercsores usually
<rick_h__> I'm actually registered under an old name, but changed to rick_h for ease of figure out who I am
<jcsackett> dig.
<jcsackett> rick_h__: so, i'll be sending you an email and emailing the dev list to let people know you're on rotation just as soon as my mail client finishes grinding on some short-sighted batch email moves i told it to do. :-P
<rick_h__> jcsackett: sounds like a plan, thanks
<jcsackett> yw.
<deryck> abentley, I'm actually starting on your review now. no applause please. ;)
<abentley> deryck: :-)
<deryck> abentley, also, I added a card for the branch.  I want to be a bit stricter about that over the next couple months, just for stats tracking curiosity on my part.
<abentley> deryck: okay.
<Laney> sinzui: hm? the docs say stub can do it too, and he has approved the proposal
<sinzui> Laney, I see. Are you asking for someone to merge your branch? I think I can do that
<Laney> sinzui: Yes I suppose so. I believe it also has to be QAed somehow before it is deployed too (ec2?).
<sinzui> Laney, I will send it to ec2 and when all the tests pass it will be merged and run though buildbot. When all builders are successful, the staging.launchpad.net will be updated for qa
<Laney> Sounds fun. Can I follow this process anywherE?
<sinzui> well maybe I cannot. ec2 land does not want to work with precise and Lp
 * sinzui tries test
<Laney> heh
<deryck> abentley, r=me.  looks great.
<abentley> deryck: thanks.
<deryck> abentley, np!
<rick_h> bac: heads up, commercial request for canonical sizzle project coming your way from RT
<cjwatson> Laney: The URLs I use to follow this are https://lpbuildbot.canonical.com/waterfall and http://lpqateam.canonical.com/qa-reports/deployment-stable.html.  I suspect you can see the latter but not the former.
<Laney> correct
<cjwatson> Laney: The buildbot isn't really terribly interesting though.  In practice you wait for a few hours for EC2 to finish, you get an e-mail saying the branch is merged, you wait for another eon or so for buildbot to finish, and a bit after it lands on qastaging the deployment report updates and a bot flips the bug status to Fix Committed and adds the qa-needstesting tag.
<cjwatson> Laney: Once you get the bugmail for that last bit you can do QA.
<Laney> ah, OK, it's all reflected in the merge proposal / bug
<Laney> as it's a DB patch I guess it doesn't need QAing per-se
<Laney> but after it's been applied to (qa)staging I can ask for the real branch to be reviewed or something
<cjwatson> IIRC QA on a DB patch is mostly about whether it can apply fast enough hot, and maybe whether related views still work - https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess
<cjwatson> You can ask for progress on the real branch once there's been a fastdowntime deployment with your DB patch
<cjwatson> Which should show up by way of it disappearing from http://lpqateam.canonical.com/qa-reports/deployment-db-stable.html (note slight difference from previous URL)
<Laney> great, thanks for the tips
<Laney> Guess I'm waiting to for sinzui to figure out ec2 land :-)
<sinzui> I started up an old computer and just updated it to run Lp
 * Laney gets back to this paper review in the meantime
<Laney> oh, rock
<jcsackett> ...always fun to discover you've been disconnected from irc for who knows how long ...
<lifeless> flacoste: I'm around $whenever though from +30 to +50 I'll be out getting meds for cynthia
<flacoste> lifeless: ok, ping me when you are back
<mwhudson> jelmer: _now_ i have a mail from you about feature flags :)
<jelmer> \o/
<jelmer> I wonder what void it has been spending its time in.
<mwhudson> jelmer: "ganieda.lan" apparently
<jelmer> *confused*
<jelmer> that's the hostname of my old laptop
<mwhudson> jelmer: haha
<mwhudson> jelmer: http://paste.ubuntu.com/807804/
<jelmer> hmm
<Ursinha> what does this mean when trying to start a local launchpad instance? "Exception: Timeout waiting for RabbitMQ server to start."
<Ursinha> except the obvious :P
<mwhudson> it's possible postfix still thinks it's hostname is ganieda if you just transplanted /etc? :)
<jelmer> mwhudson: yeah, that appears to be the case (not sure why, I think I did a clean install)
<jelmer> mwhudson: either way, glad it finally surfaced. I'm still planning to have a look at using those feature flags in the codehosting ssh server some time.
<jelmer> Ursinha: I remember seeing that at some point, but I don't recall what the cause was I'm afraid..
<mwhudson> jelmer: cool
<flacoste> lifeless: back yet?
<mwhudson> jelmer: i guess you don't actually need a reply to the mail :)
<jelmer> mwhudson: nope, thanks
<flacoste> lifeless: on the phone with gary
<lifeless> flacoste: kk
<lifeless> Ursinha: it means the obvious; did you get a trace with a log file or anything like that ?
<flacoste> lifeless: call back
<StevenK> sinzui: http://pastebin.ubuntu.com/807933/
<StevenK> wallyworld: Let me know how you go with convoy, by the by
<wgrant> lifeless: I'd like your thoughts on https://code.launchpad.net/~wgrant/launchpad/hardcoded-password/+merge/88966
<sinzui> StevenK, you are a launchbag victim
<sinzui> add this to your test after you create the bug
<sinzui> getUtility(ILaunchBag).add(bug.default_bugtask)
<StevenK> RARGH, LaunchBag
<sinzui> StevenK, maybe you need to get angry and take a knife to all uses of launchbag in browser.bugtask
<sinzui> I cannot think of a legitimate reason that the context object does not provide what we want
<StevenK> sinzui: I have considered that option, but I'm not sure 1) What browser.bugtask is using ILaunchBag for, and 2) What the fallout would be
<sinzui> StevenK, how many hours has this team spent debugging launchbag. I think we can take a few to replace anything that uses it with the object in scope, then send the branch to ec2.
<sinzui> If you accidentally pass the -s switch and with [r=sinzui][no-qa] you might get a pleasant surprise
 * sinzui looks at code
<StevenK> sinzui: You'd like me to kill ILaunchBag entirely, or just where it hit me?
<StevenK> OH DAMN IT
 * StevenK resigns his .changes with his old key and uploads it to DF
<sinzui> StevenK, I think it is worth an hour to replace as must as possible...
<sinzui> 1. LaunchpadView.user == bag user
<sinzui> 2. if the context is a bug, the use the bug.default_bugtask
<sinzui> Oh, and you may need to pass the user as the principal when if the test added the user to the bag
#launchpad-dev 2012-01-18
<StevenK> steven@liquified:~/launchpad/lp-branches/kill-launchbag-with-fire% bzr grep ILaunchBag | wc -l
<StevenK> 555
<StevenK> :-(
<StevenK> wgrant: QA done
<wgrant> StevenK: Thankyou sir.
<StevenK> sinzui: XMLRPC is implicated, which concerns me
<sinzui> skip it then. change the ones that keep slowing us down
<sinzui> StevenK, I looked at the template that makes the bug links
<StevenK> lib/lp/xmlrpc/application.py:        caller = getUtility(ILaunchBag).user
<sinzui> I think the view's .unofficial_tags and .official_tags could make make sane links instead of the template. That would be easier to test
<StevenK> lib/lp/app/browser/launchpad.py:        self.user = getUtility(ILaunchBag).user
<StevenK> Bah
<sinzui> StevenK, just focus on bugtask and maybe bugnomination
<sinzui> StevenK, the bag is not 100% 20% is useful. We get stuck when it is used instead of the context information.
<StevenK> BugTasksAndNominationsView.current_bugtask == return getUtility(ILaunchBag).bugtask
<StevenK> sinzui: http://pastebin.ubuntu.com/808023/
<wallyworld> StevenK: could you "bin/ec2 land" this for me? my precise system is borked https://code.launchpad.net/~wallyworld/launchpad/subscription-policy-text-912159/+merge/88808
<sinzui> StevenK, I think it needs some checking. For example I see in configure.zcml that IBugNomination is the thing that is passed to some the nomination views
<sinzui> StevenK, and why would get_assignee_vocabulary_info have self.user, it is an 8 line function
<sinzui> StevenK, the two callsites of get_assignee_vocabulary_info are Lp views and do know the user, so they should pass the user with the context
<StevenK> sinzui: Right, which I just did.
<StevenK> sinzui: http://pastebin.ubuntu.com/808035/ is a updated diff
<sinzui> StevenK, BugListingBatchNavigator is not an Lp view. it I think we could use request.user though
<StevenK> wallyworld: It has been tossed at ec2.
<wallyworld> StevenK: thanks. looking at your use-combo branch now
<StevenK> use-*convoy*
<sinzui> StevenK, the other option is the make some of the classes inherit from UserAttributeCache which provides .user to lp views
<wallyworld> yeah, typo
<StevenK> sinzui: Using request.user sounds fine to me
<StevenK> I thought after create_initialized_view(), you could call view() to get the actual HTML out?
<StevenK> sinzui: If you think my launchbag diff is good I can commit, push and create an MP
* StevenK changed the topic of #launchpad-dev to: devel broken until r14681 | https://dev.launchpad.net/ | On call reviewer: StevenK | Firefighting: - | Critical bugtasks: 3*10^2
<sinzui> StevenK, I think the bug nomination changes will break the bugtask ones might work
<StevenK> cjwatson: r=me for https://code.launchpad.net/~cjwatson/launchpad/archive-copy-packages-source-series/+merge/87942 , shall I land it for you?
<wallyworld> StevenK: use-convoy doesn't load the yui stuff properly for me, looking to find out why
<StevenK> wallyworld: Did you 'make clean' and 'make'?
<wallyworld> StevenK: yep
<wallyworld> it appears the bootstrap yui.js file is not loaded because of a wrong url
<lifeless> wgrant: I'd be happier if authenticateUsingBasicAuth wasn't *called* outside the test runner
<StevenK> wallyworld: Which wrong URL?
<StevenK> wallyworld: OH!
<StevenK> wallyworld: You to run sudo make copy-apache-config
<wgrant> lifeless: It isn't
<wgrant> lifeless: Which is why it crashes.
<wallyworld> StevenK: right, i'll do that
<wgrant> lifeless: See the next hunk, which adds an config.isTestRunner() check to the call
<lifeless> wgrant: ok, so uhm, comment there that it shouldn't be called
<cjwatson> StevenK: yes please, thanks
<wgrant> Sure.
<lifeless> I was thinking we could put something in the test runner zcml
<lifeless> but I see its not componentised
<wgrant> I considered that, but it would need a bit of refactoring.
<wallyworld> StevenK: apache restart fails with: Invalid command 'WSGIScriptAlias'
<wallyworld> missing module
<StevenK> wallyworld: Install libapache2-mod-wsgi
 * wallyworld does that
* wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK | Firefighting: - | Critical bugtasks: 3*10^2
<StevenK> cjwatson: Right, I've reviewed all four of your branches, I'll toss them all at ec2.
<cjwatson> StevenK: neat, thanks
<wallyworld> StevenK: still issues, trying make clean again
<lifeless> wgrant: anyhow, I don't have anything significant to say
<lifeless> obviously there is a risk
<wallyworld> StevenK: i assume we need to include the libapache2-mod-wsgi package as a launchpad dep now
<StevenK> wallyworld: That can be done at the same time we add convoy
<rick_h> wallyworld: I don't think so
<rick_h> it'll be a convoy dep
<StevenK> Mmmmm
<wgrant> I don't think convoy should depend on it.
<wgrant> It can be run in any WSGI server...
<rick_h> ah, right. and we're serving out of the same apache anyway
<wgrant> lifeless: I think we should eliminate it eventually, but there are so many tests to migrate.
<wgrant> And it's not clear what's best to migrate to.
<wallyworld> StevenK: so, still broken. i'll see if there's anything in the apache logs
<StevenK> wallyworld: What does wget --no-check-certificate https://launchpad.dev/combo?yui/yui/yui-min.js give you?
<wgrant> +combo, please
<wallyworld> StevenK: will try that. btw, saw this in apache error log
<wallyworld> Traceback (most recent call last):
<wallyworld>   File "/home/ian/projects/lp-branches/devel-sandbox/scripts/branch-rewrite.py", line 15, in <module>
<wallyworld>     import _pythonpath
<wallyworld> ImportError: No module named _pythonpath
 * StevenK stabs wgrant
<StevenK> wallyworld: Unrelated
<rick_h> wgrant: I'm going to start working on the convoy parsing the path tomorrow. I'll see if I can get the +combo going. I want to try to keep consistant somewhat with the other teams using it
<wallyworld> StevenK: it gets me a file containing
<wgrant> rick_h: Right.
<wgrant> rick_h: LP is sort of special, though, in that our top-level namespace is user-controlled.
<StevenK> rick_h: I can switch to +combo pretty easily
<wallyworld> StevenK: https://pastebin.canonical.com/58279/
<rick_h> wgrant: yea, I need to look into the best way to parse the url our to split on host/$disk_path/$ignoreme_or_something
<rick_h> wallyworld: ok that means that it can't find the files on disk you asked for
<StevenK> wallyworld: find /var/tmp/convoy -type f
<wallyworld> rick_h: yeah, figured as much
<rick_h> wallyworld: but that means it did get served via the combo loader application
<rick_h> so yay for partial success
<StevenK> Sucessful failure!
<rick_h> lol, that's what we decided to call it wasn't it
<wallyworld> rick_h: StevenK: i suspect the yui tarball is not being unpacked correctly. i think my/deryck's last buildout mods are missing, looking now
<StevenK> wallyworld: We do that ourselves
<StevenK> wallyworld: Using bin/combo-rootdir
<wallyworld> ah ok. our buildout mods are for the legacy launchpad.js then
<StevenK> Yes.
<StevenK> And therefore pointless
<StevenK> Since LP has no hope to build against 3.4.1
<StevenK> rick_h: /+combo changes pushed
<wallyworld> StevenK: rick_h: so here's what's under /var/tmp/convoy/yui: https://pastebin.canonical.com/58280/
<wallyworld> StevenK: the idea was that we would just unpack from the tarball the yui build dir
<wallyworld> which is all the combo loader needs IIUC
<wallyworld> ie we don't want to copy across all the src etc
<wallyworld> so we may have a slight disconnect here
<wallyworld> since what is under /var/tmp/convoy now is not what i was expecting to see
<wallyworld> /var/tmp/convoy/yui i mean
<StevenK> wallyworld: Well, everytime I tried to get involved, deryck told me to shush
<wallyworld> he did didn't he
<StevenK> wallyworld: bin/combo-rootdir is built from a buildout template, and it will unpack the yui in versions.cfg
<StevenK> wallyworld: Oh, and be careful running bin/combo-rootdir
<StevenK> If you run it with no arguments, it will attempt to remove /*
<wallyworld> StevenK: so, why that script and not a buildout recipe?
<StevenK> wallyworld: Because buildout recipes are a pox
<wallyworld> but we have one that works
<wallyworld> that we were expecting to be used
<wallyworld> that unpacks the yui files in downlaod cache - the versions we wan tto switch between
<StevenK> wallyworld: Then you and deryck made lovely assumptions
<wallyworld> so we can use the feature flag to switch between yui versions on the fly
<StevenK> And now you get to keep both pieces
<wallyworld> StevenK: we talked with rick_h about it, and i thought you as well?
<lifeless> wgrant: I have a suggestion
<StevenK> wallyworld: I think that work is premature -- we can't switch to 3.4.1 until we are using the combo loader anyway
<lifeless> wgrant: in BaseLayer set a global variable somewhere.
<wallyworld> StevenK: exactly, that's what we were prepping for
<lifeless> wgrant: on nmodule load have it initialize to None
<lifeless> wgrant: IFF it is set, it is the basic password
<lifeless> wgrant: if it is not set, basic auth cannot work
<rick_h> honestly wallyworld, I don't think StevenK and I "got" what you guys were headed towards at the time
<StevenK> wallyworld: In either case, you need to debug what bin/combo-rootdir is doing
<wgrant> lifeless: I don't think that will work for testrunner-appserver
<rick_h> wallyworld: since we were honestly figuring out things ourselves as far as the plan for the on disk layout/setup
<StevenK> rick_h: Given deryck kept shushing me, I kept my opinions to myself.
<lifeless> wgrant: well, set it in the config then
<lifeless> wgrant: *that* will work using the same thing we do for transient rabbit etc
<wallyworld> StevenK: rick_h: ok. i'll debug it. seems like there was a communications fail there
<rick_h> wallyworld: definitely
<rick_h> wallyworld: sorry about that
<wallyworld> rick_h: no need to apologise - it was a collective failure
<rick_h> wallyworld: I had hoped to get that stuff merged in to "see" what it was up to while we were together but ran out of time
<wallyworld> rick_h: StevenK: although, i'm trying the use-convoy branch "out of the box" and it's still failing
<wallyworld> ie it should work as is
<StevenK> It can't, so far
<wallyworld> but i'll find out what's happening in the process of trying to fit the other stuff in
<StevenK> It needs changes to lp-meta-deps
<lifeless> wgrant: this then does not depend on the config name, it only depends on us not setting the global basic password in production configs
<lifeless> something I think we can manage
<wallyworld> StevenK: what changes? so far, i've installed tne missing deb and updated the apache configs, other than that, it's the vanilla use-convoy branch
<StevenK> wallyworld: It's *very* rough, currently
<wgrant> lifeless: Right, but then we depend on lazr.config's somewhat ambiguous behaviour of mapping 'none' -> None
<wgrant> But I guess
<wgrant> (I still don't know how that works)
<StevenK> wallyworld: And installed mod-wsgi
<lifeless> wgrant: you don't want to.
<wallyworld> StevenK: yes, that's the deb i was referring to
<lifeless> wgrant: you can check 'if basic_password and basic_password.upper() != 'NONE':'
<rick_h> wallyworld: yea, something is up with your paths for the yui files that got unpacked. I don't think "yui-yui3-f332140/src/" should be in the path
<StevenK> wallyworld: There's two -- convoy and mod-wsgi
<lifeless> wgrant: if you want less reliance
<wgrant> lifeless: That's what I was planning.
<wgrant> But still, ew.
<rick_h> StevenK: he's getting successful requests from convoy via apache
<wallyworld> StevenK: ah right, sorry. that's what i meant
<rick_h> StevenK: it's just saying that it can't find the .js files
<wallyworld> rick_h: yes, the unpacking of the tarball appears wrong, or incompatible with what the combo loader expects
<StevenK> rick_h, wallyworld: I've pushed a small change to bin/combo-rootdir that will blow up if you run it with no arguments, rather than attempting to remove /*
<rick_h> wallyworld: the lp and the yui2 directoryes look right from that pastebin
<wallyworld> rick_h: yes, agreed
<wallyworld> StevenK: thanks
<rick_h> wallyworld: but the yui3 isn't correct, I'm not sure why off the top of my head. I've not pulled StevenK's latest stuff yet. On the docket for tomorrow
<StevenK> I'm not looking forward to merging devel
<wallyworld> rick_h: StevenK: so, the buildout recipe unpacks the yui tarballs to build/js/yui
<rick_h> wallyworld: right, which should now be /var/tmp/convoy/yui
<wallyworld> and then i expect this will be what's copied over to /var/tmp/convoy
<StevenK> All tarballs?
<wallyworld> StevenK: yes, so we can switch between them
<wallyworld> using the js.yui-version feature flag
<StevenK> At the moment, we don't deal with multiple yui versions in our use of the combo loader
<StevenK> This is why I said it's premature
<StevenK> We haven't even figured out all the pieces and stuff is moving out from under us
<wallyworld> ok, for now we just need to get it working with the expected version for prod
<wallyworld> but one of the value props here is the ability to easily test qastaging against another yui version for example
<StevenK> Sure
<wallyworld> or locally as well of course
<StevenK> But let's get the combo loader working first before we start changing other stuff
<wallyworld> that was my plan for now :-)
<rick_h> and a fine plan that is
<rick_h> wallyworld StevenK, I'm going to head offline in a bit for the night. Shoot me an email with where things are so I can pick them up tomorrow. I've got a call with deryck to go over the details on where to head from here
<wallyworld> rick_h: StevenK: so, i don't think i'll have to do much - just take the tarball unpacking out of combo-rootdir and replace with a copy from the buildout stuff
<wallyworld> rick_h: np. goodnight. thanks
<rick_h> wallyworld: ok, let me know where that's at once working and I'll make sure to pull that in locally as well
<rick_h> wallyworld: or get StevenK to update his branch with it before EOD for you guys
<StevenK> wallyworld: build/js/yui/yui-3.3.0 is empty for me
<wallyworld> rick_h: will do.
<wallyworld> StevenK: let me poke a bit on my disk to have a look
<wallyworld> StevenK: my dir has all the expect yui stuff. try rm .installed.cfg and rerun buildout
<StevenK> wallyworld: make clean and make results in the jsbuild stuff being unable to find lib/canonical/launchpad/icing/yui/yui/yui.js
 * wallyworld scratches head
<wallyworld> StevenK: did you rm .installed.cfg to force buildout to run from scratch?
<StevenK> wallyworld: Yes
<wallyworld> StevenK: maybe try manually rm the yui dir in icing?
<wallyworld> i'm not sure what's happening to be honest. i'm running directly off the use-convoy branch
<StevenK> wallyworld: lib/canonical/launchpad/icing/yui links to build/js/yui/yui-3.3.0 which is empty
<wallyworld> StevenK: is your download cahce up to date?
<wallyworld> StevenK: the tarball has been renamed
<StevenK> Which was a pointless renaming
<wallyworld> there's a yui-3.3.tar.gz and also a yui-3.3.0.tar.gz    the 3.3.0 version is new
<wallyworld> StevenK: no, not pointless. the contents are different
<wallyworld> the 3.30 version is hand packed to contain just the yui build files
<wallyworld> the 3.3 version i mean
<wgrant> à² _à² 
<wgrant> à² _à² 
<wgrant> à² _à² 
<wgrant> à² _à² 
<wallyworld> the 3.3.0 version is a direct download off github and the untar cmd is modified
<wgrant> à² _à² 
<StevenK> wallyworld: Which is why bin/combo-rootdir is broken
<wallyworld> ah, that makes sense
<StevenK> So you changed all this stuff out from under me, complains when it breaks, and you didn't tell me any of this?
<wallyworld> StevenK: so we wanted to eliminate the need for a manual packaging step. better to just download straight of github
<wallyworld> StevenK: no, it would have worked if your download cache was up to date
<wallyworld> i think?
<wallyworld> or maybe not
<StevenK> The make would have worked.
<wallyworld> this was done last thing friday and we ran out of time for a proper wrap up :-(
<StevenK> But then my convoy rootdir would be wrong, like what you see.
<wallyworld> if we had not lost 5 hours on thursday.....
<StevenK> wallyworld: What annoys me is that you didn't tell me anything
<wallyworld> all this is a symptom of rushing to get stuff done right at the end :-(
<StevenK> Right, I finally have a test case
<wallyworld> StevenK: it wasn't deliberate
<StevenK> We really don't handle tags with a + in them
<wallyworld> we really needed to have another few hours on the day
<StevenK> wallyworld: Anyway, I'm looking
<wallyworld> StevenK: i don't mind hacking on it
<wallyworld> i can get it work with the buildout stuff
<StevenK> steven@liquified:~/launchpad/lp-branches/devel% bin/ec2 ls | tail -n 1
<StevenK> Summary: running: 5
<wallyworld> if you want
<StevenK> wallyworld: Just waiting for my download-cache, and I'll push
<wallyworld> ok
<wallyworld> sorry about the confusion
<StevenK> wgrant: So my test fails, we do just spit out unencoded tag names and slap it into a generated URL in TAL.
<wgrant> StevenK: Of course :)
<StevenK> wgrant: ${tag} => ${tag/fmt:url} ?
<wgrant> It's not an fmt:url.
<StevenK> wgrant: Or am I better off doing this in the view?
<wgrant> lifeless: It's all in the config now.
<wgrant> StevenK: Probably the view.
<StevenK> wgrant: cgi.escape, or will that make you kill me?
<wgrant> It won't even do what you want :)
<StevenK> wgrant: urllib.urlencode? Or is that wrong too?
<wgrant> That sounds more likely.
<wgrant> Or urllib.quote if you just want to use it to generate the value, not the full k-v list
<lifeless> wgrant: great
 * wgrant stabs postgres in the eye.
<nigelb> Morn[B24
<nigelb> err
<nigelb> Morning!
<nigelb> Clearly, I need coffee.
<StevenK> wallyworld: use-convoy fixed
<wallyworld> StevenK: i'm just about to push a change to fix it also
<wallyworld> using the new buildout stuff
<wallyworld> StevenK: how about i push my change and you have a look
<wallyworld> StevenK: there's a few issues in the console logs i was looking at
<wallyworld> the sorttable js is not being loaded
<wallyworld> nor are some of the lazr-js assets
<wallyworld> StevenK: lp:~wallyworld/launchpad/use-convoy https://pastebin.canonical.com/58281/
<StevenK> wallyworld: You can't use ln
<wallyworld> ?
<wallyworld> works for me
<StevenK> Oh, I see what you've done
<StevenK> I shall ponder that
<wallyworld> it's sort of an interim step, till we support specifying the yui version
<wallyworld> not sure why the sorttable stuff isn't getting found
<wallyworld> that's under lp
<wallyworld> and i think we're missing copying some of the lazr-js stuff across
<wallyworld> StevenK: also, merge in trunk so you get the last of the mochi fixes from yerterday
<wallyworld> there will be a few LPS usages to change
<wallyworld> StevenK: ah, sorttable.js doesn't have a requires
<wallyworld> do you want to add an empty one?
<wallyworld> in your branch?
<wgrant> StevenK: Could you find some time to review https://code.launchpad.net/~wgrant/launchpad/hardcoded-password/+merge/88966 and https://code.launchpad.net/~wgrant/launchpad/no-passwords/+merge/88971 this afternoon?
<mwhudson> is sorttable stuff broken on production currently?
<mwhudson> because it certainly isn't working for me
<wgrant> It's not meant to be, but it quite possibly is.
<mwhudson> e.g. try to sort by assignee on https://launchpad.net/lava/+milestone/2011.12
<wgrant> Hm
<wgrant> WFM
<wgrant> In Firefox
<mwhudson> hm
<wgrant> More attractive than the old version, too.
 * wgrant fires up Chromium.
<mwhudson> messed up in both chrome and ff for me
<mwhudson> well chromium
<StevenK> wgrant: Does lifeless still have objections?
<wgrant> StevenK: Doesn't seem to.
<wgrant> mwhudson: Oh
<wgrant> mwhudson: It's all off by one column.
<mwhudson> hah yes
<wgrant> wallyworld, StevenK: ^^ sorttable regression
<mwhudson> well
<mwhudson> it's off by one for the blueprint listing
<mwhudson> not sure about the bug listing, that seems a bit more random
<wgrant> Hm, indeex.
<wgrant> Importance sorts by summary, status by project.
<wgrant> s/indeex/indeed/
<StevenK> wgrant: Do we need to revert prod again?
<wgrant> Not if we fix this now.
<mwhudson> there was a change to de-mochi sorttable or something recently?
<wgrant> Yes
<mwhudson>   [r=deryck][no-qa] Make sorttable a proper YUI module. Also updates to
<mwhudson>    latest version, which fixes sorttable on our site for Chrome users.
<mwhudson> 14671
<wgrant> Yes, the origin of the breakage was reasonably obvious :)
<wgrant> It's just not clear why it's broken.
<wgrant> Or how wide it is.
<StevenK> Hmmm
<StevenK> Why can't I save MP comments?
<wgrant> Oh no not again.
<StevenK> Oh, there we go. Just took *ages*
<wgrant> It does that sometimes :/
<wgrant> I think it's unrelated.
<StevenK> wgrant: r=me * 2, but you may want to wait until we sort this crap out
<mwhudson> chrome's developer tools doesn't like launchpad.js very much
<StevenK> I wonder why that is. :-P
<StevenK> Who would have thought a 3.3MiB JS file was a good idea.
<StevenK> wgrant: I fear my lack of JS knowledge won't help debugging sorttable
<wgrant> It's unlikely to be a very javascripty sort of thing.
<wallyworld> a brand new version of upstream sorttable was used
<wallyworld> since the previous one was broken in chrome
<StevenK> s/\(JS\)\(.*\)\(sortable\)/\3\2/
<wgrant> The new one doesn't seem to handle colspan at all.
<mwhudson> aaah
<mwhudson> that would explain some things
<wallyworld> looks like it works on the new bugs listings
<wallyworld> but those pages perhaps use their own sorting
<wgrant> They don't use sorttable.
<mwhudson> my money is on wgrant's observation
<wallyworld> explains that then
<wgrant> o_O
<mwhudson> -        colspan = td.getAttribute("colspan");
<mwhudson> -        if (colspan) {
<mwhudson> -            SORT_COLUMN_INDEX += parseInt(colspan) - 1;
<mwhudson> -        }
<wgrant> The new one doesn't even respect sortkey
<wgrant> It's useless.
<mwhudson> with no corresponding +s
<wgrant> (they were local patches, AFAIK)
<mwhudson> ah
<mwhudson> so um
<wgrant> timestamp: Mon 2007-03-19 17:14:53 -0300
<wgrant> message: Fix for bug 62495: Milestone bug list doesn't sort properly. Make the Javascript sorting code cope with COLSPANs. Based on a patch by BjornT. Also adds a sortkey to ensure that the sorting by bug number works.
<_mup_> Bug #62495: Milestone bug list doesn't sort properly <lp-bugs> <Launchpad itself:Fix Released by kiko> < https://launchpad.net/bugs/62495 >
<mwhudson> rewrite it in YUI?
<wallyworld> wgrant: so you saying we did local patches to upstream?
<wgrant> wallyworld: Yes
<wgrant> This apparently wasn't checked before we upgraded.
<mwhudson> http://www.kryogenix.org/bugs/sorttable/colspan-rowspan.html
<wallyworld> we could port those to the current version
<mwhudson> maybe we can just set fire to the west midlands!
<wgrant> That may be the best plan for now.
<wallyworld> mwhudson: we ultimately want to go all yui, but were not planning on a rewrite just now
<mwhudson> it's only 450 lines, and would be ~200 with yui?  but sure
<mwhudson> i'm certainly not going to fix it :)
<wallyworld> mwhudson: it's just that we have no bandwidth atm
<mwhudson> sure
<wallyworld> we are supposed to be working on disclosure - the sorttable stuff came up with the move to a combo loader, a project meant to be completed at last week's Epic
<StevenK> wallyworld: sinzui said we should work on stuff from last week so it actually gets finished.
<wallyworld> StevenK: sure, but not a rewrite in yui, that's all i meant
<wallyworld> i just was saying we could do the minimum - port the previous fixes
<wgrant> Dammit Ubuntu, why do you have so many bugs :(
 * wallyworld has got the sorttable diff from r 3970 and will port across
<wgrant> wallyworld: There are two
<wgrant> At least
<wgrant> sortkey and colspan
<wgrant> Diff from the original version.
<wallyworld> sure
<wgrant> Hmm
<wgrant> The diff is 316 lines :)
<lifeless> StevenK: objections t ?
<lifeless> *to*
<lifeless> -> dinner for familty
<wallyworld> wgrant: quick look at this? https://code.launchpad.net/~wallyworld/launchpad/sorttable-fix/+merge/88982
<wallyworld> bah, just saw a mistake, fixing
<wallyworld> fixed
<wgrant> wallyworld: It works for sorting by dates, and on milestone pages (which have complex columns)?
<wallyworld> wgrant: the branch listing has date columns and the first header has colspan = 2. but i could see any milestone pages with data on lp.dev
<wallyworld> couldn't
<wgrant> wallyworld: Firefox apparently has some.
<wallyworld> so i thought
<wallyworld> i'll see if i can some something
<wgrant> ha ha hahahhahhah
<wgrant> Been debugging a test for ages.
<wgrant> Query count ends up larger with hardcoded-passwords
<wgrant> Turns out it was authenticating with 'test' as the password before, but that was in fact incorrect.
<wgrant> So it was inadvertantly making an anonymous request.
<wallyworld> wgrant: i creaed some sample data and it appears ok sorting blueprints and bugs tables on a milestone page
<wgrant> wallyworld: With all columns? Great.
<wallyworld> yep
<wallyworld> wgrant: if you +1 it could you please lp-land since lp-land is broken on my precise atm
<wgrant> wallyworld: Will land.
<wgrant> Seems like it would be about 80% smaller in YUI, though.
<StevenK> lifeless: Bah. We're the Purple squad
<wallyworld> wgrant: yes, yui would be better. but no time. thanks for landing
<wgrant> Actually just going to test it a bit more first.
<wallyworld> StevenK: i already sent a correction :-)
<wgrant> But it looks good.
<wallyworld> yeah, there was a corner case of two due to the new codebase
<wgrant> Hm
<StevenK> wallyworld: So lp-land is broken. Why is ec2 land broken?
<wgrant> No point ec2 landing that
<wallyworld> StevenK: same issue
<wallyworld> missing method
<StevenK> Strange
<StevenK> wallyworld: Just read your MP for your fix to the ITeam:+edit bug I reported -- the screenshot looks awesome
<wallyworld> StevenK: thanks.
<wgrant> wallyworld: I don't think sortkey is working properly.
<wgrant> eg. modify a few branches on https://code.launchpad.dev/firefox 30s apart
<wgrant> (just change the description)
<wgrant> You'll see that "a moment ago" sorts between "33 seconds ago" and "2007-12-06"
<wallyworld> it will use the sortjey if one is provided
<wallyworld> sortkey
<wgrant>         <td>
<wgrant>           <span class="sortkey">2012-01-18 08:50:13 SAST</span>
<wgrant>           <span title="2012-01-18 08:50:13 SAST">a moment ago</span>
<wgrant>         </td>
<wallyworld> hmmm.  not sure why it's misinterpeting it then
<wallyworld> will have to look
<wallyworld> i tested the sortkey stuff with enum columns eg bug status
<wallyworld> bah, the whole code structure around guessing column types is different
<wallyworld> more work needed
<wgrant> How much more?
<wgrant> It may be worth landing this anyway.
<wallyworld> just had a more thorough look. i think it just may be a change to the re used to guess that a column is a date
<wallyworld> it doesn't like datettimes
<wallyworld> i think worth landing now, with another landing to fix the dates
<wgrant> submitted
<wallyworld> thanks!
<wallyworld> mwhudson: fix for sorttable is merged into trunk. date columns still need a little work but other than that it's ok i think
<wallyworld> hopefully will be out of buildbot etc by tomorrow
 * wgrant is confused about bug #918037
<_mup_> Bug #918037: launchpad: please enable some shorter URLs for bugs <Launchpad itself:New> < https://launchpad.net/bugs/918037 >
<lifeless> StevenK: bah, sorry.
<StevenK> stub: Sorry, channel fail
<StevenK> stub: If you have a look at the branch linked to bug 909240, you can see that I've rewritten the query that the method uses.
<_mup_> Bug #909240: Can't display New queue due to timeouts <qa-ok> <queue-page> <soyuz-core> <timeout> <Launchpad itself:Fix Committed by stevenk> < https://launchpad.net/bugs/909240 >
<stub> Yay. Loaded a LP page and firefox crashes
<StevenK> stub: wgrant and I did some investigation and we both think the a new index on BPPH will speed up the query a lot. I have a WIP MP at https://code.launchpad.net/~stevenk/launchpad/db-add-bpph-index/+merge/88824
<stub> StevenK: ok. That looks fine. Got an example query handy for me to test?
<stub> Or have you already done tests on staging and know the new index wins out over the existing index just on binarypackagename?
<wgrant> stub: I tried on dogfood, and it cut it down to 30ms.
<wgrant> I don't remember exactly what it was without the index, but it was more than 10x that.
 * wgrant digs up the query.
<stub> Ok.  Sounds like we just want to land it and apply live then.
<stub> MP is WIP though... what still needs to happen?
<wgrant> http://pastebin.ubuntu.com/807147/
<cjwatson> StevenK: I'm failing to comprehend that failure mail about archive-copy-packages-source-series
<cjwatson> Tests hung, but doesn't seem to be related to my change?
<StevenK> cjwatson: Let me have a dig.
 * StevenK nails bigjools to IRC.
<StevenK> Stay!
<bigjools> precise hates me
<bigjools> usb kernel module crashes which takes out the mouse and keyboard
<nigelb> StevenK: lol
<StevenK> cjwatson: Hm, that is strange.
* StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 3*10^2
<StevenK> cjwatson: Nothing is jumping out to my flu-alded brain, sorry.
<StevenK> stub: MP is WIP because I wanted to talk to you, if you came up with a better index or so
<StevenK> bigjools: It seems my nail helped. Did I catch any important bits? :-P
<cjwatson> StevenK: is it worth throwing it against the wall again, or is this unlikely to be transient?
<wgrant> Where was the hang?
<cjwatson> successful: lp.testing.tests.test_zope_test_in_subprocess.TestZopeTestInSubProcessLayer:tearDown
<cjwatson> WARNING: A test appears to be hung. There has been no output for 600 seconds.
<cjwatson> last real test was lp.translations.utilities.tests.test_superfastimports.TestSuperFastImports.test_query_timeout
<cjwatson> (which succeeded)
<StevenK> stub: I shall fiddle with the MP and toss it at db-devel
<wgrant> Hmm
<wgrant> I haven't seen that one in a long time.
<wgrant> Probably over a year.
<wgrant> Throw it at ec2 again, I say.
<cjwatson> http://people.canonical.com/~cjwatson/tmp/archive-copy-packages-source-series-r14656.subunit.gz
<StevenK> cjwatson: Link me the MP again and I'll re-toss it along with my db patch
<cjwatson> StevenK: https://code.launchpad.net/~cjwatson/launchpad/archive-copy-packages-source-series/+merge/87942 - ta
<StevenK> Which just got hit with FDT
<adeuring> good morning
<Laney> since the dev wiki seems to be joining the blackout, what do I need to do to QA my db change branch which has landed on qastaging?
<wgrant> Laney: Hm, works for me.
<Laney> yeah, back now
<Laney> was down for at least 30 minutes :-)
<wgrant> But DB change branches don't land on qastaging, but staging itself. For this sort of thing we mostly just check that it applies.
<wgrant> I'll check once fdt is over.
<Laney> oh, http://lpqateam.canonical.com/qa-reports/deployment-db-stable.html says qastaging
<wgrant> It's a lie :(
<Laney> boo
<wgrant> 2012-01-18 05:44:34 INFO    2209-02-0 applied just now in 5.5 seconds
<wgrant> qa-ok
<wgrant> A little on the slow side, but it'll do.
<Laney> tidy
<wgrant> Laney: The dev wiki issue was a firewall misconfiguration that lasted about 15 minutes, I believe.
<wgrant> Laney: I've scheduled that patch for deployment tomorrow
<Laney> wgrant: Oh OK, thanks. How will I know when it's done? The bug will be flipped to Fix Released?
<wgrant> I'll comment and flip the bug back to In Progress.
<wgrant> Since it requires further landings.
<Laney> bonus, thanks a lot.
<Laney> Maybe I'll look into UI for creator and sponsor next ...
<Laney> but that would probably require figuring out how to get test data into my local instance.
<wgrant> Filling in sponsor is probably more important than displaying it.
<wgrant> Since there's not much to display at present :)
<StevenK> Ursinha: Your patch is now live on production, so if you need help with the code, or anything, give me a prod.
<Laney> it would be nice to have it on +source
<wgrant> Laney: Indeed.
<Ursinha> \o/
<Ursinha> thanks StevenK
<rick_h> morning all
<wgrant> Morning rick_h.
<cjwatson> allenap: would it be worth doing a lazr.uri release?  It, er, doesn't seem to get changed very often ;-)
<allenap> cjwatson: Yes, a very good idea. I am waiting for flacoste to appear so he can authorize me on PyPI.
<deryck> Morning, all.
<rick_h> party on
<flacoste> allenap: what package?
<flacoste> lazr.uri
<flacoste> on it
<flacoste> allenap: what's your pypi username?
<allenap> flacoste: gavinpanella
<allenap> Thanks!
<flacoste> allenap: done
<allenap> flacoste: Right, now to try and remember the runes, thanks.
<deryck> wallyworld, you around still?
<deryck> rick_h, wallyworld says in email we need "apache wsgi lib" in dependencies.... he means mod_wsgi?  Or something else?
<rick_h> deryck: right, libapache2-mod-wsgi
<deryck> rick_h, right, ok, cool.
<rick_h> it's not currently a dep since LP doesn't use it yet in the default setup
<deryck> rick_h, I'm about to paste you my notes for remaining work, and if it looks good, we can coordinate on launchpad-dev list.
<rick_h> deryck: ok, sounds good. I'm working on getting their changes from last night up and running
<rick_h> deryck: they hit issues getting your branch and ours to combine/work
<deryck> rick_h, my branch being the multi-yui buildout stuff?
<rick_h> deryck: right
<rick_h> deryck: honestly StevenK and I weren't sure what you guys were up to and we never got to merge them before we left
<rick_h>  deryck looks like they got it sorted out last night though, so merging with devel, StevenK, and wallyworld right now to build a super branch with everything together
<deryck> rick_h, right, that's what I was going to say.... I read wallyworld's email as saying it was sorted out now.
<rick_h> deryck: yea, just need to see it to believe it at this point lol
<deryck> rick_h, ok, so here's my notes:  http://pastebin.ubuntu.com/808615/
<deryck> rick_h, we can discuss on list, but generally, does it look like I've got everything there.  anything glaringly missing?
<rick_h> deryck: looking, sec
<allenap> cjwatson, flacoste: lazr.uri 1.0.3 is out.
<cjwatson> allenap: cool.  shall I file a Debian bug or have you already done so?
<rick_h> bah, is there really no way in the pastebin to reply/change a paste without manually copying/pasting?
<deryck> nope
<allenap> cjwatson: I didn't realise I had opened a can of worms ;) I haven't filed a bug and I don't really know the form for doing so; I'd be grateful if you could do it.
<cjwatson> allenap: it's not a can of worms, just the next step - OK, I'll take care of it
<cjwatson> done
<allenap> cjwatson: I was joking, but I started this thinking "I know, I'll do a quick review". I'm happy that it's progressing.
<rick_h> deryck: http://pastebin.ubuntu.com/808625/
<deryck> abentley, adeuring -- http://pastebin.ubuntu.com/808615/
<bigjools> jelmer: how does dailydeb find upstream tarballs?
<jelmer> bigjools: by tags in the branch
<jelmer> bigjools: generally speaking, recipe builds should be native
<bigjools> jelmer: ah ok, I won't worry then, thanks
<cjwatson> allenap: hey, *I* started thinking "I know, I wonder what I can do to help port launchpadlib to Python 3" ...
<cjwatson> still a fair bit left in that stack
<allenap> Haha :)
 * bigjools chortles
* abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: abentley | Firefighting: - | Critical bugtasks: 3*10^2
<jcsackett> sinzui: have a few moments to chat?
<sinzui> yes
<abentley> rick_h: Why do you say to test in google chrome, when the bug is Firefox?  Google Chrome is not available on Ubuntu AFAIK.
<rick_h> abentley: sorry, just force of habit. I ran the updated tests in both browsers and copied the last command I ran
<rick_h> abentley: updated
<rick_h> deryck: is there anything we can do to help https://answers.launchpad.net/launchpad/+question/184522 by manually touching the data?
 * deryck looks
<rick_h> deryck: he's in #launchpad asking and the book is still in progress, but not finding any way to help him right now
<deryck> rick_h, I think we need to refer him to ubuntu-sso.  sinzui, can you confirm that? (from ^^ question)
<rick_h> /book/bug/
<abentley> rick_h: r=me
<rick_h> abentley: ty much
<deryck> rick_h, I'll take over on IRC and handle it.
<rick_h> deryck: ok, thanks
<stub> deryck: I'm the person who has to fix the data in these cases. We had one of these at the Epic and wgrant tracked down and filed bugs on why these problems keep happening.
<deryck> stub, ah, ok.  Can I assign you the question then?
<stub> deryck: Sure
<deryck> stub, awesome!  Thanks!
<stub> Just email me if you do that in the future as I seem to never see emails from Questions for some reason I haven't been bothered to investigate.
<deryck> stub, will do.
<rick_h> deryck: fyi, I've done all the merging/conflict resolution and pushed to my use-convoy branch in case you want to shortcut all that
<deryck> rick_h, ok, will do, thanks.
<deryck> rick_h, and your branch is different from StevenK's branch now?
<rick_h> deryck: yea, it's merged with devel and the js branch from wallyworld, etc
<deryck> rick_h, oh, ok.  I thought StevenK had already done that in his branch.
<deryck> rick_h, np, though.  we just need to let him know.  Almost done with my coordination email.
<bac> hi sinzui, you doing lp development on precise?
<sinzui> bac, in a manner of speaking. I am about to put a branch up for review that permits me to run lp and the the test suite.
<bac> sinzui: what did you do about python-tickcount, which precise only packages for 2.7
<bac> sinzui: i'll be happy to review your branch
<sinzui> bac, this is my hack http://pastebin.ubuntu.com/808705/
<gary_poster> sinzui, wow, so LP works with 2.7 with your branch?
<sinzui> gary_poster, walks, not runs
<gary_poster> :-)
<gary_poster> very cool
<sinzui> gary_poster, bac: some tests do fail
<gary_poster> good start then
<bac> sinzui: your makefile patch does not work for 2.7.  it returns 'pythonpython2.6'
<sinzui> bac: damn. I gave you the non-commited change to support lucid.
<bac> sinzui: oopsie
<sinzui> it does not work
<sinzui> bac: this one includes the anchors to only match the full string
<bac> sinzui: cool.  so you have a diff?
<sinzui> http://pastebin.ubuntu.com/808739/
<sinzui> ^ That is my entire change to make my branch and run tests
<sinzui> bac: if my hack works for you, maybe you can approve this so that I can send it to ec2 https://code.launchpad.net/~sinzui/launchpad/precise-makefile-python/+merge/89074
<allenap> lifeless: Any chance of a testresources release? I'd like FixtureResource and use of super().
<bigjools> allenap: you expect lifeless to be awake at 6am in NZ? Oh, wait ...
<allenap> bigjools: Precisely.
<bigjools> Pangolin
<bac> sinzui: done, with one question
<lifeless> allenap: yes, sure
<rick_h> so let's just say someone accidentilly blew away their lp-branches directory...
<rick_h> and they recreated it using a normal bzr branch as they find in the rocketfuel-setup script
<rick_h> but now making branches takes forever and a day
<rick_h> what would someone look at? to get things back where a branch wasn't such a big deal?
<lifeless> you need a shared repository
<lifeless> lp-branches should be 'bzr init-repository [--no-trees] lp-branches'
<rick_h> ah, up a level. Ok, was searching branch options
<lifeless> then bzr branch lp:launchpad lp-branches/devel
<lifeless> and you're back to the starting point
<rick_h> rgr, running that now. Thanks lifeless
<lifeless> the --no-trees thing is largely personal preference - whether you want to run multiple wokring trees, or one that you switch between
<lifeless> the rf default is with trees
<rick_h> yea, I still need to spend some time on my bzr setup to find a happy place
<abentley> rick_h: If you're starting again, I recommend using bzr-colo instead.  Been using it for weeks.
<abentley> rick_h: It implements the git-style layout where you have one working tree and many branches.
<allenap> lifeless: Thanks.
<abentley> rick_h: Also, it can fluidly switch to using pipelines.
<lifeless> deryck: hey
<deryck> hi lifeless
<lifeless> deryck: a thought on pages that were timing out and don't when we reevaluate; might like to still check for warning signs
<lifeless> deryck: like high query counts (> 30), slow page (multi second rendering)
<lifeless> deryck: when I'm not ill, I would also like to catch up w.r.t. root-cause-fix-opportunities, but probably next week is best
<deryck> lifeless, ok, sure.  I did a basic assessment like that.  but re: the 30 count page, we have many that are more than that, right? in fact most, no?
<lifeless> deryck: I wouldn't say most
<lifeless> deryck: many pages have a fixed amount of content and a high query count; they generally don't get better or worse; things with batches on them are where it gets bad rapidly
<deryck> ok, I'm just going by the query count at the top of the page.  I don't find a page with 30 queries or less.
<lifeless> deryck: aiee :P So, pick a number, 70 then :)
<deryck> lifeless, also, I'd love to catch up about the root-cause opportunities stuff as you say.
<lifeless> deryck: the main thing is the number should be less than the rows in a batch
<deryck> lifeless, ah, I follow now.  gotchas.
<rick_h> abentley: thanks, I'll check out the colo stuff.
<abentley> rick_h: Cool.  Let me know if you have any questions.
<jcsackett> sinzui: do you know why we have both test_team and test_team_view in browser/tests? they seem to be a random selection of browser tests in each.
<sinzui> jcsackett, both tests were created in separate places, then apocalypse happened
<sinzui> jcsackett, They can be merged, and maybe checked for duplication
<jcsackett> sinzui: hurray!
 * jcsackett goes to collapse files.
 * sinzui did the same for personset a few weeks ago
* abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 3*10^2
<huwshimi> Hello Precise users, how do I resolve the import errors when doing rocketfuel-get?
<huwshimi> (I'm assuming these are standard issues)
<wgrant> huwshimi: sinzui was working on that.
<wgrant> huwshimi: But try hacking Makefile to use python2.7 instead of python2.6
<wgrant> Then make clean && make
<wgrant> lifeless: Around?
<huwshimi> wgrant: OK thanks. It's definitely a version thing because the packages exist
<wgrant> huwshimi: Yeah, Precise doesn't really do python2.6
<huwshimi> wgrant: Ah I see
<wgrant> wallyworld_: Worked out the sorttable date sorttkey stuff?
<wallyworld_> nope. on my agenda after breakfast
<wgrant> Great.
<wgrant> That's a good idea, actually.
<wallyworld_> yeah, can't work when hungry
<wallyworld_> at least sorting is mostly fixed after next NDT
<wgrant> Yeah
<wgrant> Should be done soon.
<wgrant> lifeless: Am I likely to be slain if I combine three marginally related DB patches into one for deployment efficiency?
<wgrant> (-AccountPassword, -EmailAddress.account, +Person.account_status)
<huwshimi> wgrant: The make clean and make worked fine but rocketfuel-get is still failing. Is there another way I can update that might work or something?
<wgrant> huwshimi: How's it failing?
<huwshimi> wgrant: Sometimes it fails with "ImportError: No module named bzrlib"
<wgrant> huwshimi: Hm
<huwshimi> wgrant: and others it fails with ImportError: No module named tickcount or something like that
<wgrant> Sounds like it's still running with python2.6
<huwshimi> wgrant: I modified the Makefile in devel
<huwshimi> wgrant: And did the make clean/make there
<huwshimi> wgrant: Is that what I was supposed to do?
<wgrant> So, rocketfuel-get basically just: bzr pull -d ~/launchpad/lp-branches/devel; bzr up ~/launchpad/lp-sourcedeps/download-cache
<wgrant> And then make
<wallyworld_> StevenK: we should land your use-convoy branch today. with your latest change, we should use ${buildout:yui-directory} instead of hardcoding to build/js/yui
<huwshimi> wgrant: Well that all appeared to work
<huwshimi> wgrant: So now how do I do the equivalent hackery instead of doing rocketfuel-branch?
#launchpad-dev 2012-01-19
<wallyworld_> StevenK: also, any reason why you didn't go with the symlink? i really think we should have each yui version explicitly untarred into a dir reflecting the version so it's obvious what's what
<huwshimi> wgrant: Hmm... actually it looks like it is branching just not running the make or something so I should be able to just fix the makefile and I'll be fine
<StevenK> wallyworld_: *Land*?
<wallyworld_> StevenK: yes, without the ff, the original launchpad.js will stil lbe used. did you see deryck's email?
<wgrant> huwshimi: bzr branch devel some-branch
<wgrant> cd some-branch
<StevenK> wallyworld_: Not yet
<wgrant> utilities/link-external-sourcecode ../devel
<wgrant> make
<wallyworld_> StevenK: ok. will let you have a read
<wgrant> That's basically all rf-branch does
<wgrant> I've never used rf-branch
<huwshimi> wgrant: Great, thanks
<StevenK> wallyworld_: The apache config is set in my use-convoy branch -- that's why you had to 'sudo make copy-apache-config'
<wallyworld_> StevenK: yeah, that's cool, all sorted yesterday. i think the email was just a summary for everyone else to being them up to speed
<wallyworld_> StevenK: so for testing, my plan is to unpack all the yui tarballs to build/js/yui and symlink by default to the prod version. the html files will be updated and tests run by default against prod version
<wallyworld_> but we can easily run yuitests locally against another yui version by changing the symlink
<wallyworld_> with the combo loader, we can do the same thing, use a symlink for now or just put the yui version in the path in the base-layout-macros tal
<StevenK> I don't like hacking the base-layout-macros template
<huwshimi> wgrant: OK, hopefully my final issue, but any idea what's up with make run? http://paste.ubuntu.com/809206/
<wallyworld_> it would be hacking - we use a ${yui-version} string substitution
<wallyworld_> wouldn't
<StevenK> You want to edit the template during buildout?
<wallyworld_> no, it's done at runtime
<wallyworld_> based on the yui version feature flag
<wgrant> huwshimi: Looks like memcached is not installed
<huwshimi> wgrant: Oh, a few things did get removed with the upgrade
<wgrant> huwshimi: Try to reinstall launchpad-developer-dependencies
<wgrant> You may need to reenable ppa:launchpad
<wgrant> The upgrade probably disabled it.
<StevenK> wallyworld_: Right
<huwshimi> wgrant: launchpad-developer-dependencies : Depends: launchpad-messagequeue-dependencies (= 0.103~precise1) but it is not going to be installed
<huwshimi> wgrant: I did re-enable the ppa but it 404s
<huwshimi> wgrant: I guess I need to use the oneiric ppa for now?
<wgrant> huwshimi: Hm, everything should be in precise. What's the 404?
<wgrant> I fixed it up for wallyworld last week.
<wallyworld_> StevenK: so originally we were going to just use a "yui" dir for the prod version, but i do want to use versioned dir names
<huwshimi> wgrant: Oh, nevermind that was for bzr and a couple of other things
<wallyworld_> i think that will be much better
<StevenK> wallyworld_: Right.
<wallyworld_> StevenK: so, you could use your "cp -a" and my symlink stuff in rootdir script
<huwshimi> wgrant: So when I try to install the dependencies it gives me the previous error and also says "E: Unable to correct problems, you have held broken packages."
<wgrant> huwshimi: sudo apt-get -f install
<StevenK> wallyworld_: Right
<wallyworld_> StevenK: so, once your stuff lands, i'll hook off that and update the yui test stuff as proposed above. sound like a plan?
<huwshimi> wgrant: Didn't help
<wgrant> huwshimi: sudo apt-get install launchpad-messagequeue-dependencies
<huwshimi> wgrant: Oh, that fails because it requires "rabbitmq-management" which doesn't exist
<wallyworld_> StevenK: and then another next step would be to update rocketfuel to do the apache config mod, and we can also just disceminate how to do it manually also
<wgrant> huwshimi: Ahh, of course. Give me a moment.
<poolie> hi all
<wallyworld_> hellooooo
<StevenK> wallyworld_: Like I keep saying, we don't need to.
<StevenK> wallyworld_: I've updated the config -- rf-setup will just pick that up, but people with a development environment already set up will need to do the sudo make I mentioned.
<wallyworld_> ok
<wallyworld_> ok
<rick_h> hey wallyworld_ and StevenK how goes?
 * StevenK is Ubuflu'd
<wallyworld_> rick_h: hi. goes good. we are just discussing landing the use-convoy branch
<StevenK> Thinking about complex problems is making me feel worse
<rick_h> wallyworld_: cool!
<rick_h> wallyworld_: StevenK did the email summary from deryck make sense?
<wallyworld_> StevenK: hopefully no more thinking required :-) just one more tweak to combo-rootdir and the tal
<wallyworld_> rick_h: yes
<wallyworld_> it reflects my understanding of where we are at
<rick_h> wallyworld_: ok cool
<StevenK> I am concerned that our LPS -> YUI change has impacted launchpad.js
<wgrant> huwshimi: That should be fixed if you apt-get update in about 5 minutes
<rick_h> StevenK: very good point
<huwshimi> wgrant: Sweet. Thanks a lot
<rick_h> StevenK: so what the LPS thing did was set the config variables, and carry that on to everyong using LPS()
<StevenK> We've been so focused on the combo loader that we haven't checked if it's safe to land
<rick_h> StevenK: so now that we set YUI_config and all LPS. are changed to YUI().
<wallyworld_> StevenK: rick_h: we attempted to make out YUI replacement functionally equivalent to LPS, no?
<rick_h> StevenK: we shold be ok
<StevenK> wallyworld_: So, what do I need to do?
<rick_h> StevenK: we should be good where we are at currently. As long as the YUI_config is set with the old optoins passed into the LPS() call, we're ok
<wallyworld_> StevenK: i can do the work locally, push up to my branch, and you can just merge if you like
<rick_h> StevenK: which the feature flag switch does
<StevenK> rick_h: Right, which we did.
<rick_h> StevenK: if you turn off the feature flag and try out the site it should work just peachy still as is with the YUI()
<wallyworld_> StevenK: i also need to merge in trunk and update those new cases of LPS usage
<StevenK> wallyworld_: So I'm waiting for you?
<rick_h> Right, LPS just goes away
<rick_h> for both launchpad.js and the combo loader
<wallyworld_> StevenK: yes. i'll do it now and ping you when done
<wallyworld_> rick_h: and hopefully by SOD for you it will be merged
<rick_h> wallyworld_: excellent, so reading the traceback the apache stuff is in place?
<rick_h> wallyworld_: can you note that step in the email exchange for deryck and I?
<StevenK> It has been since last week
<rick_h> that was the only thinking keeping me from getting it running today
<wallyworld_> well, packaging deps need to be done too etc
<rick_h> wallyworld_: right
<StevenK> wallyworld_, rick_h: We need to get it reviewed too?
<wallyworld_> yes
<rick_h> StevenK: did you see the branch of convoy I've got with the directory parsing stuff?
<rick_h> I chatted with rockstar about it and either he or another guy will review it soon hopefully
<StevenK> rick_h: I saw that it existed, I've not looked at it
<wallyworld_> StevenK: i can review if you do the mp if you want
<rick_h> StevenK: yea, I think I'd like to get a final run of it locally and run it through some paces as review before we pushed
<wallyworld_> rick_h: part of my review would also have been to test locally
<rick_h> and I'm sure there must be a test or two somewhere that will blow up
<rick_h> wallyworld_: gotcha, ok cool
<rick_h> getting nervous myself now :)
<wallyworld_> rick_h: tests won't use combo loader to start with
<rick_h> wallyworld_: right, but I'm assuming something goes boom. Maybe we get lucky :)
<wallyworld_> rick_h: hope so. we'll find out soon enough when we do the final pre-land testing
<wallyworld_> rick_h: worst case, we hand off something to you because we find issues today
<wallyworld_> and you/deryck can land tomorrow
<rick_h> ok awesome
 * rick_h crosses fingers for you guys
<wallyworld_> or if we get nervous and wimp out, we wil lhand off also :-)
 * wallyworld_ goes to set up in a cooler room. it's hot here today
<StevenK> 24 here
<wallyworld_> coolish here but *humid*
<StevenK> But due to Ubuflu, I feel like I'm burning up
<wallyworld_> StevenK: i'll try not to bother you anymore. you should go away from keyboard and lie down
 * StevenK is sorely tempted
<StevenK> I could also walk to the doctors, but that may require too much effort
<wallyworld_> go do that. i'll do everything from here and put up the mp. and it can be review by the us guys tomorrow
<wallyworld_> bah. plugged laptop into dock and mouse all fucked up. can't click anywhere
<wallyworld_> rick_h: i'll email where we get to today
<wallyworld_> StevenK:
<rick_h> wallyworld_: ok, sounds like a plan. I'm hacking with some guys on other stuff tonight for the next couple of hours. Ping me if you need anything
<wallyworld_> rick_h: will do. having trouble typing now. need to reboot :-(
<wallyworld_> random windows getting focus
 * StevenK kicks wallyworld_ for top-posting
<wallyworld_> StevenK: sorry, my keyboard and mouse got all stuffed up
<wallyworld_> and the wrong window captured by Enter keypress
<StevenK> wallyworld_: https://code.launchpad.net/~stevenk/meta-lp-deps/use-convoy/+merge/89174 but the diff isn't generating
 * wallyworld_ looks if ff would start without consuming 100% cpu
<wallyworld_> love the description
<huwshimi> wgrant: Awesome. Dependencies installed and make run is working. Thanks for you help :)
<wallyworld_> StevenK: so that looks ok to me. should we land it now?
<StevenK> meta-lp-deps? No
<cjwatson> Hmm.  importfascist still has database_root = 'canonical.launchpad.database', and is thus presumably ineffectual
<StevenK> I think utilities/migrater can die too
<sinzui> StevenK, I started on that. I am porting rename_module because it provides refactoring goodness
<StevenK> Heh. I just put up a branch and MP that removes it
<wallyworld_> StevenK: you are supposed to be sick remember
<sinzui> cjwatson, importfascist does not know about model or the many security checkers. It needs an overhaul
<StevenK> wallyworld_: Silence.
 * wallyworld_ happy that there were only 2 conflicts merging trunk into use-combo branch
<StevenK> sinzui: Oh, right, your tool is seperate. I shall land it then
<sinzui> yes.
<wallyworld_> bazaar.lp.net seems to be having several timeouts atm
<sinzui> I used my own tool, <not a euphanism> to refactor my plugins over the weekend, then thought, I should incorporate it into the plugins when I am sure it works
<wgrant> huwshimi: Great.
<wgrant> StevenK: rename-module is important. Must keep that
<wgrant> cjwatson: Yeah, most of the fascist is useless nowadays.
<wgrant> cjwatson: There were rumours a couple of years back that we were going to steal landscape's import guardian.
<wgrant> StevenK: Are you arranging for someone to apply the index live today?
<StevenK> wgrant: I was going to talk to stub about it now that the patch has landed.
<wgrant> OK. It need to be today or tomorrow morning.
<StevenK> To not impact on FDT?
<lifeless> wgrant: combining those three into one is fine; as long as we land; qa; etc one patch, I don't really care how big it is (textually that is :P)
<wgrant> StevenK: Yes
<wgrant> Although I may end up doing ppa/ftpmaster tomorrow night instead, depending on what happens.
<StevenK> wgrant: No, you should destroy EmailAddress.account harder
<wgrant> StevenK: Need a ppa/ftpmaster deployment first.
<StevenK> Pity.
<StevenK> BAH, using Link doesn't work.
<StevenK> Why is this bug so hard? It should be easy. :-(
<wgrant> Which?
<wgrant> Tags?
<StevenK> Yup
<StevenK> <span id="tag-list">\n              &lt;lp.services.webapp.menu.LinkData object at 0x113c1850&gt;\n
<wgrant> Why are you trying to use Links?
<wgrant> They're for menus.
<StevenK> I should build the entire <a href=... in the view property?
<wgrant> Or just the URL.
<StevenK> Oh, a dict of tag: url?
<wgrant> Possibly, yes.
<StevenK> wgrant: I can't say tal:repeat="tag url view/official_tags" for a dict?
<wgrant> Recall that iterating over a dict gives the keys.
<StevenK> Right, what I'm unsure about is how to get out the value in the tal
<wgrant> You may have to use python:
<wgrant> Unless you can unpack the tuple from .items() in TAL
<StevenK> Maybe we just make a list of 2-tuples
<wgrant> That provides no benefit over .items
 * StevenK tries .items()
<StevenK> zope.tal.taldefs.TALError: Invalid variable name "official_tags.items()" in expression u\'url view/official_tags.items()
<wgrant> Do you mean view/official_tags/items?
<wgrant> This is TALES, not Python.
<StevenK> Everytime I learn something about TALES, my brain rejects it as pure crack.
<StevenK> zope.tal.taldefs.TALError: Invalid variable name "items" in expression u\'url view/official_tags/items\'
<StevenK> wgrant: tal:repeat="tag view/official_tags/items" throws a KeyError of items
<wgrant> StevenK: Is it a dict?
<StevenK> view/official_tags is, yes
<wgrant> In devel it's not.
<StevenK> It is in this branch I'm hacking on
<wgrant> Can you pastebin the diff or push the branch?
<StevenK> wgrant: http://pastebin.ubuntu.com/809335/
<wgrant> StevenK: Oh, of course.
<wgrant> StevenK: It's a dict, so it tries to look up the 'items' key rather than looking up an attribute.
<StevenK> Hah
<StevenK> tal:repeat="tag url view/..." didn't work either. I guess tal only wants one item
<wgrant> ZPT doesn't do tuple unpacking, no.
<wgrant> But we can't even get to that stage, since we can't call items()
<wgrant> So, iterate of the keys and then do lookups.
<wgrant> s/of/over/
<StevenK> I'm unclear how to do the lockups
<StevenK> *lookups, sigh
<wgrant> view/official_tags/?key
<wgrant> ? uses the rest of the path segment as a variable name.
<StevenK> wallyworld_: Can haz review? https://code.launchpad.net/~stevenk/launchpad/link-bug-tags-correctly/+merge/89187
<wallyworld_> StevenK: one sec otp.
<wgrant> sinzui: Do you mean [ `lsb_release -c -s` = "precise" ] ? :)
<wallyworld_> StevenK: canonical_url you can pass +bugs as the view_name
<wallyworld_> StevenK: does "view/unofficial_tags/?tag" do a dict lookup?
<StevenK> wallyworld_: Fixed locally. And yes, it does.
<StevenK> Because TAL is just fucked.
<wallyworld_> cool. i didn't know that
<StevenK> wallyworld_: [15:17] < StevenK> Everytime I learn something about TALES, my brain rejects it as pure crack.
<wallyworld_> lol
<wallyworld_> StevenK: i'll go in and +1 it
<wallyworld_> StevenK: i've found and fixed a number of things with the use-combo branch, just a couple more to go
<StevenK> wallyworld_: Excellent. I shall commit and push the view_name change.
<StevenK> rick_h: WRT to your convoy MP, I was expecting we'd have /+combo/r14335/ and then something like /+combo/r14436/ ?
<StevenK> wallyworld_: I've tossed that branch at ec2. Thanks for +1.
<StevenK> wallyworld_: I've also tossed a Lucid package of convoy at my PPA.
<wallyworld_> StevenK: np. excellent. it's all coming together :-)
<poolie> wallyworld_, is it now the case that private bugs can have only one task?
<wallyworld_> poolie: yes, unless you are in oem or whatever the team is we have excluded form that
<wallyworld_> from
<poolie> k
<wallyworld_> poolie: is that ok? do you have a case where it's not?
<StevenK> wallyworld_: I thought sinzui said the footgun was no longer required?
<poolie> it's fine
<poolie> i have a thing affecting a private project that will also affect another
<poolie> but it's fine to create a second bug
<poolie> in fact better
<wallyworld_> StevenK: the current implementation still has the restriction
<wallyworld_> poolie: when "we" do bug linking, a lot of the reasons for any bugs to have more than one bug task should hopefully be a lot less
<poolie> yep
<wallyworld_> poolie: did you see that translation question in #bzr
<StevenK> wallyworld_: What sort of issues have you seen, by the way?
<wallyworld_> StevenK: calendars were broken. there was a case where a conflict resolution cut out a bunch of tal. milestone timelines were broken. some legacy js issues resulting in yui load errors with the rejigging in the tal
<wallyworld_> that sort of stuff
<StevenK> wallyworld_: With the FF disabled or enabled?
<wallyworld_> there's now just a build issue wrt a symlink and all those cannot load sam-asset messages
<wallyworld_> StevenK: disabled
<StevenK> wallyworld_: I misunderstood your use of the symlink, so feel free to make that change.
<StevenK> wallyworld_: Although I don't like the idea of putting the yui versions in buildout.cfg
<wallyworld_> StevenK: i think its a different issue
<poolie> can a superuser please change the maintainer of /awsproxy from ~jelmer to ~awsproxy-core?
<wallyworld_> StevenK: we can iterate on that
<wallyworld_> StevenK: i've best testing with ff off so we can deploy asap. most of the issues found would also have been there with ff on
<wallyworld_> s/deploy/land
<StevenK> Right
 * wallyworld_ needs to go and buy more coffee
<wgrant> Hi stub.
<stub> yp
<stub> yo even
<wgrant> Can you live-apply that new index some time today?
<wgrant> It has landed.
<stub> ok
 * StevenK stabs the messaging indicator
<jtv> morning folks
<jtv> wgrant: I see that TTBJ.updateBuild_WAITING lacks read-write transaction policy.
<wgrant> jtv: Quite possibly.
<wgrant> But I thought there was a bug on that.
<cjwatson> Anyone mind if I upgrade dogfood?
<wgrant> cjwatson: Go ahead
<adeuring> good morning
<mrevell> Hi
<jtv> Why is the oops-tools project deactivated in Launchpad?
<wgrant> jtv: Because it was replaced by python-oops-tools
<jtv> Ah
<jtv> thanks
<wgrant> (which is a continuation of the same codebase, but without the proprietary history)
<nigelb> OMG.
<nigelb> The new oops page is *AMAZING*
<wgrant> It's the DB outage page. Sadly the OOPS page hasn't been upgraded to be pretty yet.
<wgrant> All huwshimi's work.
<nigelb> :)
<nigelb> I should find him and give him a hug.
<nigelb> If that's the baseline for how launchpad will be in the near future, I'm going to be very happy :)
<Laney> the sad face page?
<nigelb> Yeah.
<Laney> yeah, that's cute
<nigelb> Its got a fresher UI than *cough* most of Launchpad
<nigelb> wgrant: did we ever switch LP monospace fonts to ubuntu font?
<wgrant> nigelb: Yeah, because we have bugs about how small it is :)
<wgrant> But I don't think we use webfonts for them.
<nigelb> Webfonts is what I meant.
 * nigelb contemplates doing that after finshing existing branches
<wgrant> Laney: Your DB patch is deployed.
<wgrant> And now in devel.
<Laney> cool
<Laney> what is next? Trying to land the other one?
<wgrant> The code that uses the patch? Yep?
<wgrant> s/?$/./
<nigelb> Laney: https://dev.launchpad.net/Contributions \m/
<nigelb> (look at 16)
<Laney> heh
<nigelb> Eventually, someone will beat wgrant :P
<wgrant> I hope so :)
<nigelb> If only I had more free time.
<jml> hey, did I hear that longpoll was done?
<wgrant> It works, but it has one remaining major bug.
<wgrant> Which is pretty easily fixable.
<wgrant> (client-side per-host connection limits suck)
<wgrant> So if you open a few MPs, all Launchpad requests hang.
<wgrant> Because the browser tries to avoid DoSing.
<nigelb> dammit.
<nigelb> That's counterproductive :)
<jml> wgrant: heh, so it's a matter of fixing the bug and then flicking a switch for MPs?
<wgrant> jml: Yup
<wgrant> jml: Well, more of a gradual dial.
<jml> wgrant: heh :)
<jml> wgrant: that's cool.
<wgrant> We have little idea how this will scale.
<jml> yeah, fair enough.
<rick_h> morning folks
<wgrant> Morning rick_h.
<nigelb> Morning rick_h!
<rick_h> howdy nigelb
<wallyworld_> rick_h: i sent you a big email, let me know if there's anything needed clarification
<rick_h> wallyworld_: yea looking. I was curious if the not loading messages were due to http://yuilibrary.com/projects/yui3/ticket/2530983
<rick_h> but that's for 3.4 so guess not
<rick_h> wallyworld_: did you see if the modules were missing from the combo'd file?
<cjwatson> sigh, this QA is going to involve comparing three getPublishedSources calls on dogfood
 * cjwatson snoozes
<bigjools> cjwatson: why not qastaging?
<wallyworld_> rick_h: i'm almost sure they were there. but that ticket looks suspiciously familair to others i saw. i think the warnings in our case are bogus
<cjwatson> hmm, I suppose Archive.copyPackages mght work on qas?
<rick_h> wallyworld_: I'm hesitant to go with the LP_YUI change because it's not what's going on in U1 and I've not seen that as a regular pattern. So I'm wondering if there's something else that's the root in there
<rick_h> wallyworld_: right, that's what I'm wondering if the warnings are more a YUI bug than our bug
<wallyworld_> rick_h: i don't understand why we would want to incur the cost and overhead of instantiating multiple yui instances, plus the not loaded warnings/errors are a direct result of doing that
<rick_h> wallyworld_: I guess I'd be curious if we upgraded to 3.4 and ran to see if they still occurred
<rick_h> wallyworld_: right, but there's potential for one LP_YUI instance to change a config/setting that blows up down the road
<wallyworld_> in our usage, i don't think that's an issue
<rick_h> wallyworld_: so it's the old cost of keeping the blocks independant other than the global config, or running into potential issues chasing bugs in one .pt files that's caused by something somewhere else entirely
<wallyworld_> moving forward, we would want to consolidate all those little snippets anyway
<rick_h> wallyworld_: and we're not hitting any performance issues atm anyway
<rick_h> wallyworld_: true
<wallyworld_> rick_h: remember that till now, we've always operated on asingle YUI instance
<rick_h> wallyworld_: ok, I'll peek at it. Thanks for the hard work and the summary.
<wallyworld_> so we are just sticking with our current modus operendi
<rick_h> wallyworld_: right, I'm just trying to "do the right thing" if we're heading down this path anyway
<wallyworld_> np
<rick_h> while we're blowing up the world, blow it up all the way :)
<wallyworld_> agreed, we do need to start adopting best practice
<rick_h> I'll peek at what I can find. It might be the best thing to do, just saying my initial reaction is "ugh, that doesn't seem right"
<wallyworld_> but  i don't follow how creating all these yui objects is best practice
<rick_h> like I was saying, each YUI() sets up it's own wrapped JS world that
<rick_h> no other YUI() should be able to interfere with another
<rick_h> so you're safe to defined your own requires, your own settings, etc. No global leakage, etc.
<rick_h> it's not a ton since really there's 3-6 of those a page
<rick_h> so 3-6 new JS objects per page isn't going to cause any issues
<wallyworld_> agreed. but in our case, all these little snippets really belong together i nthe one sandboc
<rick_h> yea, eventually we'd want to have some sort of system for injecting JS/requires into a single YUI()... block on each page
<wallyworld_> it would be ok ig yui didn't pollute the console with all these bloody errors
<wallyworld_> hard t know if they're really genuine :-(
<rick_h> wallyworld_: right. thanks for the heads up. We'll get it worked out.
<wallyworld_> ok :-)
<StevenK> I wonder if there is a way to get the template name in a global tal macro
<StevenK> And then include <template name>.js or something
<StevenK> Probably complete crack
<rick_h> StevenK: that's close to the idea I'm heading towards long term. That there's an bugs.app.js that includes the code for the bugs pages that need to run
<rick_h> and you'd setup "views" in there that get init/run on page load
<rick_h> and all JS goes into that view
<rick_h> that way you get one single combo loaded JS file for all bugs pages
<rick_h> and it's easier to see/reuse code across there
<rick_h> and no more chasing JS in .pt files :)
<StevenK> rick_h: Well, if you want to make our JS story not be crack cut with draino, more power to you
<rick_h> but that's long way from here
<rick_h> StevenK: we've got to do something. I mentioned to my coding group last night that our fancy JS paging buglisting code was going to go live soon and the first thing someone thought was "like that cool github code tree thing?" which I had to say..."um, not quite"
<rick_h> we need the pretty JS
<adeuring> morning rick_h, fancy a review? https://code.launchpad.net/~adeuring/launchpad/bug-904461/+merge/89230
<rick_h> oh right, sure thing adeuring
<adeuring> rick_h: thanks!
<rick_h> wallyworld_: it looks like that our code is requiring modules that don't exist
<rick_h> wallyworld_: there is no such thing as widget-position-ext that I can find in the yui3.3 src
<rick_h> Topic for #launchpad-dev: https://dev.launchpad.net/ | On call reviewer: rick_h* | Firefighting: - | Critical bugtasks: 3*10^2
<wallyworld_> rick_h: widget-position-ext is in the loggerhead src. so i suspect it's leftover from an older version of yui
<wallyworld_> and we just didn't migrate properly or something
<rick_h> ok, I'll make sure to check through our src. thanks
<wallyworld_> rick_h: lib/loggerhead/static/javascript/yui
<rick_h> wallyworld_: right, so that wouldn't be part of our combo loader
<rick_h> wallyworld_: since we don't copy that dir into our build dir
<wallyworld_> that's not where the errors in lp would be from i don't think, but merely evidence that we may have left over crap in places
<rick_h> wallyworld_: right, I've got more poking to do. I'm on reviews for my first time today so might be slow going through it
<wallyworld_> ok. have fun. hopefully you won't get too many :-) so we can get this sorted :-)
<cjwatson> Does qastaging process PackageCopyJobs created on it?
<bigjools> yes
<cjwatson> I'm beginning to empirically conclude it doesn't
<cjwatson> hmm
<bigjools> easy to check
<cjwatson> oh, unapproved queue, not new
<cjwatson> I *was* checking, I was just looking in the wrong place :-)
<bigjools> :)
<Laney> https://code.launchpad.net/~laney/launchpad/add-sponsor-field-to-spph/+merge/87930 needs review, if anyone feels like it. Be aware that this is my first (real) LP branch so gremlins may lurk.
<rick_h> adeuring: ok, posted comments on the review. Let me know what you think. I've requested the follow up review from jcsackett before final ok
<adeuring> rick_h: ok, thanks
<rick_h> let me know if anything's not right so I can learn for my next review. Speaking of...
<rick_h> Laney: ok, will take a peek. Between your first branch and my first day of reviews, we'll make a fun day out of this yet
<Laney> :-)
<adeuring> rick_h: well spotted issues. I'll fix them
* jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: rick_h*, jcsackett | Firefighting: - | Critical bugtasks: 3*10^2
<rick_h> Laney: ok, only comment is that test. jcsackett will make sure I didn't miss anything else.
<Laney> OK. I wondered that, but didn't know if there was only supposed to be one assert per test
<Laney> thanks
<bac> hi bigjools, do you have access to kde on natty?
<deryck> Morning, all.
<abentley> deryck: morning
<bigjools> bac: I don't, I'm all upgraded to almost new
<bac> bigjools: poo.
<bigjools> sorry old bean
<rick_h> bac: what do you need? I might know a kde using friend in our loco on natty
<bac> rick_h: thanks, i may take you up.  just some testing for an SRU.  i don't think it'll be required but i'll keep it in mind.
<rick_h> bac, ah ok
<jcsackett> laney: i've reviewed your MP--i would really like the test duplication resolved. you can mash the tests together, but i have an alternate, somewhat preferable (to me at least) approach in my comment on your MP.
<Laney> jcsackett: absolutely. Thanks for that. It'll have to wait until I get home but that sounds reasonable to me.
<jcsackett> laney: cool. if i'm still on when you make the change, ping me then and i can approve.
<Laney> 3-4 hours time
<jcsackett> Laney: then i'll be here. :-)
<Laney> awesome
<adeuring> rick_h: i pushed new revision of the branch
<adeuring> care to take a look?
<rick_h> adeuring: sure thing, will check it out in a sec. Thanks
<adeuring> thanks!
<rick_h> mwhudson: ping, question for you on https://code.launchpad.net/~mwhudson/loggerhead/bug-321325/+merge/87881, why was file_id param removed?
<rick_h> doh, always check location first.
 * jcsackett wonders why he gets gnomekeyring errors when using ec land in tmux ...
<rick_h> jcsackett: haven't seen that myself
<jcsackett> it just started happening recently, but i can't remember any updates that would be relevant.
<adeuring> jcsackett: thanks for your review!
<jcsackett> adeuring: you're welcome. sorry i forgot to ping you when i was done. :-P
<rick_h> adeuring: awesome, thanks. Sorry on the docstring, I didn't think to check the interface. r=me
<adeuring> rick_h: thanks!
<ayan> i'm new to python and the launchpad api.
<ayan> i'm having trouble extracting the next item in a series given a series name.
<ayan> so if i have:
<ayan> ubuntu = lp.distributions['ubuntu']
<ayan> and i want the series after 'maveric'.
<ayan> how can i use ubuntu.series to extract 'natty'?
<bigjools> ayan: you can just do ubuntu['natty']
<bigjools> IIRC
<ayan> bigjools: i don't know the series after maveric.
<ayan> well -- *I* do, but I'd like to determine the next series programaticly.
<bigjools> ayan: you need to iterate then
<ayan> i can iterate over ubuntu.series but i was wondering if there was a simpler way.
<ayan> right.
<bigjools> there's no better way really
<cjwatson> >>> [series for series in ubuntu.series if series.parent_series is not None and series.parent_series.name == 'maverick'][0]
<cjwatson> <distro_series at https://api.launchpad.net/1.0/ubuntu/natty>
<cjwatson> or a less densely packed version if you prefer :)
<cjwatson> but indeed the API only links it in that direction not the other way round
<rick_h> cjwatson: ? re https://code.launchpad.net/~cjwatson/launchpad/split-ftpmaster/+merge/89193
<rick_h> cjwatson: on the  warned_database_imports. I'm not 100% what that's for, but you removed ftpmaster, but none of the new modules qualified to take its place?
<cjwatson> rick_h: possibly true; it's hard to say because the importfascist is broken anyway so I can't quite tell what it's supposed to warn about
<rick_h> cjwatson: ok
<cjwatson> rick_h: I guess maybe obsolete_distroseries?
<cjwatson> rick_h: I've added that - I suppose it can do no harm
<rick_h> cjwatson: ok, sorry I'm not helpful. Trying to figure out what this is intended to do
<cjwatson> https://bugs.launchpad.net/launchpad/+bug/706129
<_mup_> Bug #706129: import fascist is now ineffective and should be either reenabled or deleted <easy> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/706129 >
<rick_h> ah, that makes sense
<cjwatson> It's probably my duty not to make it any worse when doing something not essentially related
<rick_h> cjwatson: so I'd expect to see something touching the database to be in the warnings there, but I'm not seeing any of the code doing a query/etc?
<rick_h> cjwatson: I guess it's more for other code importing ftpmaster though, so nvm.
<salgado> I'm getting "You attempted to reach launchpad.dev, but the certificate that the server presented has been revoked by its issuer." on chrome 17.0.963.33 beta when accessing launchpad.dev and the only option I'm given is to go back.  does anybody know if there's a way to tell chrome to ignore it or at least give me another option to proceed regardless?
<salgado> I used to be given the option to proceed regardless, so maybe this is a new chrome feature?
<salgado> the " Check for server certificate revocation" checkbox doesn't seem to change anything
<salgado> firefox doesn't seem to think the certificate is revoked -- only that it is self-signed.  maybe chrome's change in behaviour is because it thinks the certificate is revoked?
<salgado> hm, nevermind, seems to be working now
<cjwatson> rick_h: I think it's any imports, so the UTC_NOW that ended up in obsolete_distroseries.ppy [D[D[Dwould have triggered it at one point
<cjwatson> gah, ignore lag-induced junk there
<Laney> jcsackett: Just implementing your changes now (actually there are rather more opportunities to pull that code out of). Shall I implement rick_h's suggestions too (merging the new tests into existing ones)?
<jcsackett> laney: i think these are legitimately new tests, so the tests themselves should remain separate. just pull out the repetitive boilerplate.
<Laney> ack, I thought the same
<jcsackett> cjwatson: i have finished reviewing rick_h's review. all looks good, given you addressed his one issue.
<jcsackett> i am guessing you need landing assistance? :-)
* jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett | Firefighting: - | Critical bugtasks: 3*10^2
<Laney> jcsackett: pushed. I'm sure there's more that can be done, but this is at least better.
<jcsackett> Laney: i see several places where you've now deleted the line where a change_log_entry is set, but the _setup_copy function doesn't set that. have you verified these changes all pass without that line?
<Laney> jcsackett: yes, I reran that entire file
<jcsackett> deryck: the mp you've claimed may be the largest i have seen during my review times. certainly it is the largest i can remember.
<Laney> seemed to be c+p
<deryck> jcsackett, yeah, biggest I've done too.
<jcsackett> Laney: awesome. r=me.
<jcsackett> Laney: i assume you need/want landing assistance on this?
<Laney> jcsackett: yes please. I can't do it myself.
<jcsackett> oops, Laney, sorry if i got your hopes up. i see it's dependent on another branch hitting production, which hasn't happened yet.
<jcsackett> when that does, we can get this branch out to land.
<Laney> jcsackett: the db branch? AFAIK it rolled out in FDT today (or at least that's what wgrant told me)
<jcsackett> Laney: according to the deployment report, it's clear to be deployed, but i don't think it has been yet.
<Laney> 19/01 10:10:07 <wgrant> Laney: Your DB patch is deployed.
<Laney> 19/01 10:10:13 <wgrant> And now in devel.
<jcsackett> Laney: hrm. lemme go run this down.
<jcsackett> Laney: yup, i see that the FDT through 11307 happened. alright, out this one goes.
<Laney> awesome
<sinzui> That replacement private team debacle has set me on edge. I cannot write an announcement about privacy/disclosure terminology.
 * sinzui looks for a trivial bug to feel productive
<deryck> ah, sorry, sinzui
<sinzui> deryck, no need to apologise. I lead the commercial admin team and I have not been very good at documenting how to extract users from Lp privacy morass
<deryck> yeah, I just hate you lost your day to it.
<sinzui> yes. I am disappointed. Still one of the bugs I reported is definitely a social-private-teams defect that must be fixed in the next two weeks. I think we chose the wrong vocab to get the list of teams you can transfer a branch to
<sinzui> deryck, You can set aside your guilt My trivial fix to allow changing a branch owner to a private team also fixes other bugs.
<deryck> sinzui, ah, nice!
<deryck> something good from the day then!
<wallyworld_> deryck: hi. thanks for the review! just to confirm - should we prefer YUI.use or YUI.add?
<deryck> wallyworld_, hey man.
<wallyworld_> g'day
<wallyworld_> we seem to use YUI.add in our js, and YUI.use in the tal
<wallyworld_> more or less
<deryck> wallyworld_, sorry, I wasn't clear... if it's a use block, it should be "YUI().use" -- if it's add, it should be "YUI.add"
<wallyworld_> np. i sort of read the review comment in email and didn;t look back at code - i wanted to try and quickly catch you before youi eod
<wallyworld_> so it was probably a stupid question based on lack of info
<deryck> yeah, the spots we use then look right to me.  it's just YUI.use should become YUI().add and if there are any YUI().add they should be YUI.add.  if that makes sense. ;)
<wallyworld_> ah right. yes it does. thanks. should be easy to fix. we have our standup soon and i'll do it asap after that. can't wait to land this
<wallyworld_> that console noise suck though
<wallyworld_> deryck: also, sinzui said in email that we used a single LPS instance previously to resolve some browser issues. are we sure there won't be an issue using YUI() all over?
<deryck> I'm sure.
<sinzui> wallyworld_, deryck. I recall the issue was between solid sandboxing and page rendering times. We (and landscape) chose the later
<deryck> sort of.
<deryck> it was browser issues, it was the only way to set a global config, before the global config option we have now....
<deryck> so we passed in those 4 or 5 issues to prevent trying to connect to Yahoo's CDN, which helped performance.
<deryck> that was "wasn't" browser, not was.
<wallyworld_> ah, ok. and rendering times should be better now with the combo loader :-)
<deryck> indeed.
<wallyworld_> also, i justed emailed you guys directly rather than the list - we can do an email to the list once this lands
<deryck> and we have all the global config options we need now too.
<deryck> GlobalConfig didn't exist back when we did LPS.  That's what I was trying to say.
<wallyworld_> deryck: so, if you are able to check back in say 90 minutes or so, hopefully i'll have made the changes. depends on how long our standup goes. then we can send to ec2 today \o/
<deryck> wallyworld_, yay!
<wallyworld_> thanks :-)
<deryck> wallyworld_, I'll will check back in between 1.5-2 hours from now.
<deryck> np!
<deryck> so before raid night. ;)
<wallyworld_> ok. i know it's a large mp. but i expected one of us to review and we were all across the implementation
<wallyworld_> yep :-)
<deryck> yeah, I wasn't worried about the size.
<deryck> it's really a clean diff anyway.  2000 lines are the global LPS replace stuff.
<wallyworld_> deryck: i'll raise a bug also so we have a qa trigger. is there one already that you can recall?
<wallyworld_> i was just commenting on the concern expressed in the mp :-)
<sinzui> deryck, thank you for your keen memory. BTW, why are you here? Have you run away from home
<deryck> wallyworld_, no, there's not.  just make a "we should use a combo loader" bug.  and I think this in incr fix.
<deryck> wallyworld_, we can finally close the bug when we switch it live.
<deryck> sinzui, I start later and stay later now.
<deryck> my EOD is in 5 minutes.
<wallyworld_> deryck: sounds good. i just want to make sure we do all the due diligence we can :-)
<deryck> indeed :)
<wallyworld_> i really hope qa goes ok. i dpon't want to rollback :-/
<rick_h> wallyworld_: do we need to get the path business on convoy setup before this lands?
<rick_h> wallyworld_: since we'll need to be able to do upgrades and such with webops going forward?
<wallyworld_> rick_h: no. lets just get this in as is, we won't switch on the combo loader till we are ready
<wallyworld_> we will iterate
<rick_h> ok, just wamted to be sure
<wallyworld_> rick_h: see above discussion for YUI() vs LP_YUI and reasons for originally using LPS
<wallyworld_> we will be going with YUI() as you wanted
 * wallyworld_ fires up mumble and hopes it works this time
<cjwatson> jcsackett: landing> yes please, thanks
<StevenK> sinzui, wgrant: http://pastebin.ubuntu.com/810147/ :-(
* jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 3*10^2
<jcsackett> cjwatson: your branch is off to land. :-)
<wgrant> StevenK: Ah, because it's a str, not an int. You may have to use python: after all :(
<cjwatson> jcsackett: cool, thanks
<deryck> Night all.
<sinzui> wgrant, https://bugs.launchpad.net/launchpad/+bug/556680
<_mup_> Bug #556680: attempting to create a new account with an existing team email address at login.ubuntu.com oopses <isd-logging-sprint> <lp-foundations> <openid> <Canonical SSO provider:Incomplete by stuartmetcalfe> <Canonical ISD QA:New> <Launchpad itself:Triaged> < https://launchpad.net/bugs/556680 >
 * sinzui adding the missing openid tag
<StevenK> sinzui: https://code.launchpad.net/~stevenk/launchpad/kill-bugtask-launchbag-with-fire/+merge/89357 but no diff yet
<StevenK> That was quick.
<StevenK> Something must be broken.
<wgrant> sinzui: Ah
<wgrant> sinzui: As I thought, the email address gets stolen from the team.
<wgrant> In the old code.
<sinzui> I raised the bug to critical, you can mark it as a dupe. Now we have a really TB to look at.
<sinzui> wgrant, you can fix this if you think you have the opportunity
<wgrant> Hm
<wgrant> I think that same thing would actually have taken a person's last email address in some situations.
<sinzui> wgrant, in the case of a team, the last email address could be an Lp hosted list. That would be very strange. I think there is an assumption in Lp code somewhere that lists.launchpad.net is a team
<StevenK> sinzui: Thanks for the review, I'll toss it at ec2 after breakfast.
<wallyworld_> rick_h: you there?
<rick_h> wallyworld_: here, what's up?
<wallyworld_> my reading of the yui3 docs is that there's no config option to allow setting the logLevel in the GlobalConfig object :-(
<wallyworld_> you can go YUI({logLevel: 'info'}) but that's not a global setting
<rick_h> wallyworld_: ok, I'll take a peek
<wallyworld_> thanks, i may have simply missed the option
<wallyworld_> i did try it in GlobalConfig despite the docs saying it wasn't an option and of course it didn;t work
<rick_h> yea, not sure. I've not tried it
<wallyworld_> we may just have to have a noisy console
<rick_h> right, I think it won't take long to clean up
<rick_h> I fixed the one locally on the widget-position-ext
<rick_h> so I can merge that once this is landed right away and then it's just a matter of fixing the css ones
<rick_h> and it's only for people behind the feature flag until I find the rest
<rick_h> I didn't have much time to look into it today with reviews
<wallyworld_> yeah, plus the lp.xxxxxx naming inconsistencies etc
<rick_h> I'm a bit slow on them atm
<rick_h> right, that was my fault. I thought the lp.xxx module name had to match the directory structure
<rick_h> so I changed the one module deryck pointed out
<wallyworld_> rick_h: the noisy console is with or without the ff
<wallyworld_> it's due to us moving to YUI() all over instead of a sinlge instance
<rick_h> wallyworld_: ah, that's right sorry
<rick_h> but I can fix it, just need to find the issues and correct them one at a time
<wallyworld_> rick_h: np. plus, the work last week introduced a critical regression bug 918901
<_mup_> Bug #918901: bug page html is unparseable by XMLHttpRequest <Launchpad itself:New> < https://launchpad.net/bugs/918901 >
<rick_h> and they show up as warnings, both chrome/FF have a filter on the debug tools to choose the level absoulte worst case
<wallyworld_> this was part of the general cleanup stuff from lp.js was moved into tal
<wallyworld_> i'm onto that bug next
<rick_h> oh hmm, ok. well should be able to through the page html at a validator and see what it hates on
<wallyworld_> it hates the unquoted & and < etc
<wallyworld_> shit happens
<wallyworld_> i didn't realise we were doing anything naughty
<rick_h> where is the unquoted &/< ?
<wgrant> Search for ' < ' on any LP app page.
<wallyworld_> not sure - haven't looked yet tbh. wgrant raised the issue on today's standup
<wgrant> Cry
<rick_h> ah ok
<wallyworld_> apparently it's all @$%@!$%! the fault if IE
<wallyworld_> s/if/of
<wgrant> Yup
<wgrant> If IE didn't exist we could just use XHTML :/
<rick_h> hmm, the only one I see is in JS code on a sample bug page
<wgrant> rick_h: RIght
<wgrant> rick_h: That's the problem.
<wgrant> LP pages have traditionally been both HTML and XHTML.
<rick_h> orly? having the           for (i = 0; i < nodes.length; i++) {
<rick_h> in a JS tag is bad?
<wgrant> They're no longer valid XHTML.
<wgrant> Yes.
<wgrant> It's invalid XML.
<rick_h> ok, well worst case we can go back to the plan of pulling out the plain JS methods back out of the template. I figured putting them there just made it obvious since they were a bit hidden before
<wgrant> And you can't escape using &gt;, because that doesn't work in HTML4.
<rick_h> right, that's not valid JS at that point and it'd fail I'd expect
<wgrant> No.
<rick_h> really? you can use &gt; in JS and it'll parse/execute?
<wgrant> You're not using &gt; in JS.
<rick_h> that's where I see it at
<wgrant> You're using &gt; in XML or SGML
<wgrant> Which happens to have JS encoded in it.
<rick_h> ah, gotcha
<wgrant> The problem is that HTML4's subset of SGML is stupid.
<wgrant> eg. if I have JS with a string containing '</script>', I can't represent that in HTML4.
<wgrant> Because I can't encode it to &gt;/script&lt;, because HTML4 browsers won't decode it.
<rick_h> lovely, well have to love that this little project is a demonstation of how many ways to break something :)
<wgrant> It's similar to the problem of including ]]> in an explicit CDATA section.
<wgrant> Except that XML is sensible, so you can just end the section, write ]]> literally, then restart it.
<wgrant> It will still be the same text node.
<wgrant> But for script tags in HTML4 we have no such luxury.
<wallyworld_> so if we land the use-convoy branch, it will rebreak any fixes to trunk. i'm tempted just to fix in use-convoy since we are landing that today
<StevenK> wgrant: <tal:official_tags tal:content="structure/view/official_tags" /> seems to not work
<wgrant> StevenK: 'structure ', not 'structure/'
<StevenK> Ah
<wgrant> Just do a list of tuples, though.
<wgrant> Much safer.
<StevenK> We couldn't -- remember?
<wgrant> python: isn't the end of the world.
<wgrant> It's close, but not quite.
<wgrant> rick_h: Ideally you should remove the JS from the page, but otherwise you can wrap it in commented CDATA tags
<wgrant> To make XML parsers happy.
<StevenK> I have it working with the tags in the view. I'm happy with it.
<wgrant> You've said 'structure'
<wgrant> The most that can make you is "awkwardly compromising"
<StevenK> That's what sinzui suggested.
<wgrant> By no means can that make a reasonable person in any way happy.
#launchpad-dev 2012-01-20
<rick_h> wgrant: yea, if we move it to it's own JS file we can just make sure it gets built into launchpad.js and then for the feature flag users make it a seperate request for now
<rick_h> wallyworld_: does that make sense? To create a .js file in lib/lp/app/javascript/plain.js or something?
<StevenK> wgrant: I have the tests passing, so I can redo the work, and move back to list of tuples or commit and land the use of structure
<rick_h> and the builder should pick it up for launchpad.js automatically still
<rick_h> since it searches in there right?
<StevenK> It runs find over the tree
<rick_h> and then we'll manually add the url as a new script tag for feature flag users?
<wgrant> StevenK: "redo the work" is about ten lines of code, but I guess it's OK
<rick_h> until I can get a chance to run through it and YUI-ize it?
<wallyworld_> rick_h: i was just going to wrap in a CDATA tag for now - we already do that all over the place
<wallyworld_> essentially a 2 line change to the mp
<rick_h> wallyworld_: ok then. I've never done that so that was the less comfy way for me
<rick_h> wallyworld_: but awesome, works for me
<wgrant> Make sure that the CDATA tags are commented.
<wgrant> Or IE's JS parser will choke
<wallyworld_> of course
<wallyworld_> i cut n pasted :-)
<wgrant> The web needs to die.
<wallyworld_> from elsewhere
<wallyworld_> no, IE needs to die
<wgrant> Holy shit
<wgrant> IE9 supports XHTML
<rick_h> yea, IE9 is the first real browser in a long time
<rick_h> IE10 actually might make me not hate it..but until then
<wgrant> Only 12 years late :)
<rick_h> IE9 is still missing html5 history/geo location/etc that everyone else has now
<rick_h> wallyworld_: ok, so looking at: http://yuilibrary.com/yui/docs/api/files/yui_js_yui-log.js.html#l36
<StevenK> wgrant: Compilation failed', "zope.tal.taldefs.TALError: invalid syntax (<string>, line 1) in expression u'python:${tag/1}', at line 148, column 15"
<rick_h> the logging is looking for a setting in Y.config.debug = false
<wgrant> StevenK: python: tag[1]
<StevenK> Sigh, TALES.
<wgrant> you can hardly say python: and then give it TALES instead.
<wallyworld_> rick_h: that's for the src filters - include and excluded modules
<rick_h> wallyworld_: and looking at how the YUI instance is setup, if you were to add config: { debug: false } to the list in YUI.GlobalConfig that would work
<StevenK> wgrant: Silence. :-P
<rick_h> wallyworld_: it wraps the whole thing
<rick_h> if the debug is false it bypasses all logging
<wallyworld_> rick_h: but we still want errors logged in prod
<rick_h> wallyworld_: the whole method does nothing but return the Y instance at the end
<rick_h> wallyworld_: ok, then we'll have to set the config.logExclude filters for warning?
<rick_h> nvm, those are for the source, we need on log level, looking me
<wallyworld_> rick_h: my understanding is that the include/exclude filetrs are for modules
<rick_h> looking more :/ can't type
<wallyworld_> afaict, we need logLevel but that's not a global option sadly
<rick_h> wallyworld_: the problem is that's on the console module
<rick_h> we want to touch the raw log included in yui.js
<rick_h> they're different, the loglevel would do us no good here
<wallyworld_> yep :-(
<wallyworld_> that's the conclusion i camr to as well
<rick_h> wallyworld_: I still say we turn off debug. This is the YUI log module. Any JS errors are exceptions that go around this
<StevenK> wgrant: I had to set tal:content to python: tag[0] too, but I think I have it working.
<rick_h> wallyworld_: the only errors this would eat are places where we willingly do Y.log.error()
<wgrant> StevenK: Of course
<wallyworld_> rick_h: sounds like a reasonable plan i think
<rick_h> or sorry, Y.log(msg, "error")
<wallyworld_> yeah, knew what you meant :-)
<StevenK> wgrant: So I have your blessing to toss it at ec2 and find something else to do?
<wgrant> StevenK: If it doesn't use structure, I have no objection.
<wgrant> Because the worst you can do is break the links :)
<rick_h> wallyworld_: so I'm not sure which of these you need: http://paste.mitechie.com/show/505/
<wallyworld_> rick_h: i knew 30 minutes ago when i read the docs :-)
<wallyworld_> i'll sort it
<wallyworld_> short term memory is broken, brain too full, it hurts to think
<rick_h> wallyworld_: I *think* it's the first but not 100% sure
<rick_h> but anyway, if it fails jsut a heads up you might need the other
<wallyworld_> np, will find out in about 3 minutes
<wallyworld_> rick_h: it's just "debug: true|false"
<rick_h> wallyworld_: yea, the check in the code is if (!c.debug)
<rick_h> sorry, if (c.debug)
 * StevenK has been seeing some wierd behaviour today
<StevenK> Refreshing MP pages "Shows transferring data" for a good long while until I get bored and stop it
<wallyworld_> StevenK: bazaar.lp.net was sloooow yesterday
<wallyworld_> timed out a lot
<wallyworld_> rick_h: now all i need is deryck to come back online and +1 the fucker :-)
<StevenK> rick_h: WRT to your convoy MP, I was expecting we'd have /+combo/r14335/ and then something like /+combo/r14436/ ?
 * StevenK stabs the messaging indicator more
<wallyworld_> StevenK: the use-convoy mp is/will be linked against 2 bugs. if i land with --incr, both bugs will remain in progress, right?
<StevenK> I believe so
<wallyworld_> that makes me sad, since one will be fixed
<wallyworld_> i guess we can close manually
<StevenK> Right, we don't really deal with that case
<poolie> i can do recipe builds from private branches, right?
<StevenK> You can not.
<poolie> ah, foo, i thought i'd seen it
<poolie> maybe i was thinking of private ppas
<jelmer> StevenK: do you remember what prevents them?
<wgrant> jelmer: Builders don't have SSH keys
<poolie> was this connected to mwh's thing of allowing ssh with a limited-time token?
<wgrant> Precisely.
<jelmer> wgrant: oh, right
<wallyworld_> jelmer: sorry to bother you - is there anything i can do to get lp-land etc working in precise?
<jelmer> wallyworld_: can you tell me what package version of bzr-pqm you have installed?
<wgrant> wallyworld_: Do you really have to conflate those two changes into a single branch?
<wallyworld_> jelmer: 1.40-bzr80-1
<wgrant> wallyworld_: One is almost guaranteed to include regressions and need rolling back at least twice, while the other is a critical regression fix.
<wallyworld_> wgrant: i could land in devel but then there will be merge conflicts for the other one
<wgrant> Ah
<wallyworld_> "at least twice" - you so such a pessimist
<wgrant> How safe is use-convoy with the flag off?
<wgrant> This sort of stuff has an exceptionally bad track record.
<wallyworld_> it uses ye old launchpad.js as before
<wgrant> Sure, but there are presumably some changes.
<wgrant> And none of this has tests.
<wallyworld_> minor ones - mainly going to multiple YUI instances instead of a single instance
<wallyworld_> all the yui tests pass
<wgrant> The YUI tests don't use launchpad.js
<wallyworld_> true, but i diffed launchpad.js from trunk and it was the same
<wallyworld_> as the branch
<jelmer> wallyworld_: the easiest thing to do is probably to run "bzr branch lp:bzr-pqm ~/.bazaar/plugins/pqm"
<wallyworld_> accounting for expected skew
<wallyworld_> jelmer: thanks! looks ok. i'll know for sure when i land the next branch
<wgrant> wallyworld_: Ah, OK
<wgrant> I guess it's somewhat reasonable, then :)
<wallyworld_> wgrant: i bloody hope so at least. i've done a lot of smoke testing.
<wallyworld_> but lp is soooo big it's impossible to touch everything
<rick_h> StevenK: no, the other way around. /$revno/+combo
<rick_h> that way we can have as many paths as we want in there to start
<wallyworld_> wgrant: if my optimisim ^H^H^H^H^H blind hope proves false, i'll do a separate fix for the bug straight away
<rick_h> StevenK: so if the files were in /var/convoy/build/js we could set the root to /var/convoy and make the app provide /build/js/$revno/+combo as the url
<wgrant> wallyworld_: Sounds good.
<StevenK> rick_h: Really? The icing stuff is icing/<revno>
<StevenK> rick_h: And lifeless said he wanted it like it
<rick_h> StevenK: right, well I don't think the order matters. In this way it's easier for me to regex since I can basically match anything up until the last item and make that a path (supporting multiple levels if required) and combo or +combo don't matter so we don't have to deal with changing upstreams usage
<StevenK> rick_h: But it does matter
<rick_h> StevenK: I think this gets the effect we want (changing the paths at run time based on the LP instance) without making too many changes
<rick_h> why?
<StevenK> rick_h: Since /+combo is proxied off in the apache config
<StevenK> So the URL has to *start* with /+combo
<rick_h> right, but we can't change that check to combo$?
<StevenK> I really don't want to do regex matches in the apache config
<rick_h> ok, shoot me a couple of urls we want to match and I'll see if I can change the regex to support what we want and what U1 and Landscape are doing at the same time
<rick_h> I didn't realize we had the limitation so I was merely trying to add directory support
<StevenK> rick_h: So, I'd make it configurable -- turn it on with a parameter in combo_app()
<rick_h> StevenK: so you're thinking a config of "allow_paths" or something that turns on/off grabbing path info from the url?
<rick_h> and then just if set do it the LP way?
<StevenK> rick_h: And I was expecting something like /+combo/r12456/yui/yui/yui-min.js or /+combo/r14858/lp/registry/timeline.js
<StevenK> rick_h: Right, exactly.
<rick_h> ok, so I want to match /(toss)/(some)/(path)/(hints)/?... then right?
<rick_h> ok, I think I can reverse the regex for that in convoy. I'll update the tests and push a new one tomorrow then
<StevenK> Right, so what you want to do for /+combo/r12456/?yui/yui/yui-min.js is actually return <root>/r12456/yui/yui/yui-min.js. Not really important, but I'd prefer the comment showing the filename didn't include the revno dir
<rick_h> right, all good
<rick_h> I follow, sorry, just was thinking normal url with path first, file end
<rick_h> should be an easy adjustment
<wgrant> sinzui: Still around to discuss the SSo issue a bit?
<sinzui> I am about
<wgrant> sinzui: Do you think the emailaddress-stealing code is still useful?
<sinzui> wgrant, I do. I recall users being very confused about the email mismatch
<sinzui> wgrant, but I really think the issue is that users expect synced email addresss to be synced
<wgrant> sinzui: More confusing than when they get logged into a different account, and then can't find their original account because it no longer has an email address to search by?
<sinzui> wgrant, If the l.lp.net did not lie about what/who it was, the sync issue might be mitigated
<wgrant> sinzui: We should certainly inform affected users that something is up.
<sinzui> wgrant, yes.
<wgrant> But I think that automatically "fixing" it is harmful.
<wgrant> Because in most cases the second SSO account is mistake.
<wgrant> And transferring the address to the second LP account just exacerbates the mistake.
<wgrant> I think we should rather warn on login.
<wgrant> That $otherperson has the primary address, see this wiki page for details.
<sinzui> We could explain we think identities are mismatched. We could let the user choose the transfer the email address (without email confirmation)
<wgrant> Right.
<wgrant> In fact, I was thinking that we could only really do this with addNotification.
<wgrant> But +openid-callback could prompt directly.
<wgrant> Add an extra step to the login.
<sinzui> Do we know enough info when this happens to advise the user to go back to SSO and sort the matter out? Do we know enough to tell the user about the two identities in Lp that are criss-crossed?
<sinzui> We sort of know in the case of Ubuntu. I do not think so in the case of another SSO provider
<wgrant> We can identify the other persoin in LP.
<wgrant> In the case of another SSO provider it doesn't matter.
<wgrant> Because we don't trust their email addresses.
<wgrant> So we *can't* do reassignment.
<sinzui> Well, Do I (me) really trust Ubuntu SSO at the moment.
<wgrant> We want to reassignment purely because login.launchpad.net confuses people by looking like Launchpad.
<wgrant> Heh
<wgrant> No.
 * sinzui looks if he can delete email address now
<wgrant> You can now.
<wgrant> For a few months now.
<StevenK> kill-bugtask-launchbag-with-fire => devel  [FAILED]   (up for 1:38:25) i-568d8234
<StevenK> :-(
<wgrant> StevenK: Which test?
<StevenK> I haven't looked yet
<wgrant> sinzui: So, I think that if an identifier is known we should trust it. If the email address isn't known by Launchpad, we add it to their person. If it *is* known by Launchpad but is on another account, we log them in but tell tham what's going on and how to fix it.
<wgrant> sinzui: They (and we) can do the proper fix then.
<wgrant> Because we can present the primary email addresses of both people.
<sinzui> Ubuntu is almost as bad as google. If I leave Canonical, my primary identity is compromised. People leave their employers more often then they change the personal addresses.
<wgrant> Whereas now we silently steal the conflicted primary email address, making it very hard to work out what the original state was, and how to recover.
<sinzui> I still do not trust
<wgrant> This also moves us towards a workflow for external providers.
<wgrant> Where logging in will create an invalid person, because it has no verified email addresses.
<wgrant> This same post-login workflow process could be used to verify an address.
<sinzui> wgrant: +1. Fixing bad data is always harder than letting a user know that something is wrong
<wgrant> sinzui: Right. And this situation only arises when a mistake has already been made, because just about nobody has a reason to have two SSO accounts.
<sinzui> wgrant, the mistake was ours I think. We made no distinction between imported identities and those users claimed and were active
<sinzui> SSO should purge ever address that that was not active when received from Lp and only accept those that are given my users
<wgrant> sinzui: Until last week SSO still had emailaddresses for Launchpad teams.
<wgrant> But we deleted those.
<wgrant> I don't know if it still has NEW ones.
<sinzui> including @lists.launchpad.net? That is an obvious imposability
<wgrant> I've endeavoured to understand the situations in both DBs and codebases.
<wgrant> But it is complicated.
<wgrant> I believe all @lists.launchpad.net addresses should be gone from SSO's DB now, unless they are associated with a proper account.
<wgrant> Which is a bit crazy, but possible I suppose.
<wallyworld_> rick_h: StevenK: use-combo is in ec2 :-)
<rick_h> yay!!!
<sinzui> wgrant, when Lp sees a mismatched email address. What can Lp do for the user? Transfer the email? I think Lp should suggest a merge instead. Since SSO does not have merging, I do not think we can explain how to make the identities the same if sso has 2+ identities for the user
<wgrant> sinzui: Right, I'm not sure.
<wgrant> sinzui: I've also just realised a complication.
<sinzui> Its a lost of email deletion and reclaiming I suspect
<wgrant> sinzui: If we don't steal the address, how do we deal with reactivating a deactivated account?
<wgrant> We don't have a preferredemail :/
<wgrant> So I have a deactivated account, and log in with its OpenID, but the SSO preferredemail is on a different account.
<wgrant> The only way out is a logintoken.
<wgrant> Either to do the merge, or to validate and select a new preferredemail.
<sinzui> well, I think you are proposing a fix to an unreported bug. User complain we did not deactivate their account because they can login again. If Lp asked the user he wants to proceed, he would not compain
<wgrant> It gets even more complicated when we consider SCA
<wgrant> Which relies on the implicit reactivation behaviour.
<wgrant> And cannot have user interaction.
 * wgrant dies violently.
<sinzui> You mean we make a Frankenstein identity from other identities, log the user in and say...Your Alive! Click here to die if you do not want to be a gestalt
<wgrant> Until last week the only way getOrCreateByOpenID could fail was if the account was suspended.
<wgrant> Currently it will fail if the provided email is owned by a team.
<wgrant> And ideally it would not return a valid person if it had to reactivate.
<wgrant> But SCA assumes it does.
<wgrant> And SCA involves money :)
<sinzui> I am not keen on suspending another 3000 spam profiles...screw SCA
<wgrant> I wonder if lifeless has jurisdiction over CA
<wgrant> Which owns SCA nowadays.
<wgrant> Ah, no, they're under OS
<wgrant> Sad.
<wgrant> I guess SCA is pretty similar to SSO
<wgrant> In that they both touch Launchpad in completely inappropriate ways.
<wgrant> I'm just less sure about how to fix SCA.
<wgrant> Because it relies on being able to obtain a Launchpad person for any unsuspecting SSO account.
<sinzui> Do we need to fix it now. Do users want us to fix it?
<wgrant> The problem is I broke it last week.
<wgrant> And fixing this cleanly will break it further.
<sinzui> Telling users we can fix SCA by doing what we do now and locking you out of part of your identity
<wgrant> Perhaps I should just restore the old behaviour of stealing the team address, however distasteful that may be.
<wgrant> This doesn't fix any of the other problems, though.
<wgrant> SCA prevents us from fixing the corruption issues :(
<wgrant> Although bug #901336 is encouraging.
<wgrant> It already breaks in some cases.
<wgrant> So maybe we can break it more and nobody will complain :)
<sinzui> Stealing a team address is very bad. We know every team address is a one that is being used. We delete any team address that the user does not indicate is being used
<sinzui> Lp has to tell the user that the address belongs to a  team. The options are to remove the address (confirm via email to do it), login as the owner and delete the team, or go that to SSO and remove the badness
<wgrant> Sure.
<wgrant> That's clearly the correct solution.
<wgrant> But SCA relies on being able to get or create an LP person for any SSO account.
<wgrant> Without user interaction.
<wgrant> We probably want to decide to break that.
<sinzui> I do not think SCA advocates identity theft. Surely they have some guidelines for when to not honour the operation
<wgrant> The XML-RPC API that they use pretty much just calls getOrCreateByOpenIDIdentifier directly.
<wgrant> And the only way that could fail was in the case of a suspended account.
<wgrant> Although I guess if they getOrCreate the person early, they can fail before the transaction.
<wgrant> sinzui: So, I think for now I will fix it to steal team addresses again. But I will obtain the SCA code and talk to CA people about how it can do better.
<sinzui> okay
<wgrant> The quick fix is probably just to attempt to get the person right before payment.
<wgrant> That way there's only a small race, which probably already exists.
<wallyworld> StevenK: bollocks. we need to get a new ec2 image with convoy packaged or else make fails
<wgrant> wallyworld: Or just add it to launchpad-developer-dependencies, and ec2 should auto-install it.
<wallyworld> wgrant: of course, much easier
<wallyworld> StevenK: ^^^^ can you do that? i have no idea how and want to get this fucker though ec2
<wallyworld> actually, i think there's already a partial branch for it
<wgrant> Ah, buildbot will need a manual upgrade too, actually.
<wallyworld> how do we do that?
<wgrant> webops :)
<wallyworld> thought that may be the case
<wallyworld> i'll wait for StevenK to pop up and we can get it sorted in one go
<wgrant> Oh, blah.
<wgrant> That means convoy will need catification
<wallyworld> you mean whiskers and a saucer of milk?
<wallyworld> :-)
<wgrant> Close enough.
<StevenK> Oh, right
<StevenK> wgrant: You don't like that idea?
<StevenK> wallyworld: O hai -- https://code.launchpad.net/~stevenk/meta-lp-deps/use-convoy/+merge/89174
<wallyworld> StevenK: you want a review?
<StevenK> wallyworld: I do, yes.
<StevenK> wallyworld: I have to wait for convoy to publish in the LP PPA anyway.
<wallyworld> looks ok to my untrained eye, will _1
<wallyworld> +1
<wallyworld> StevenK: so what's the next step? looks like i can't ec2 land today?
<StevenK> You could, but it would then fail buildbot
<wallyworld> bollocks
 * StevenK sees if convoy is installable from the PPA
<wallyworld> so we could get your ppa installed on bb?
<StevenK> Only if you want a GSA to visit you personally with some sharp implements
<StevenK> wallyworld: Jump on mumble, and I'll outline it
<wallyworld> StevenK: ok. i may have to reboot so if i drop off, i'll be back in a bit
<wgrant> wallyworld: So, I'd suggest ec2 testing today
<wgrant> If it works, then get convoy into cat and onto bb
 * StevenK glares at mumble
<StevenK> 3 copies?!
 * StevenK wields kill
<lifeless> not to be landing such think on friday
<StevenK> lifeless: WCPGW!
<wallyworld> sinzui: +1 on that mp if you want to send it to ec2 before you go to bed
<StevenK> wallyworld: meta-lp-deps changes merged, waiting for the recipe builds -- they should kick off automatically in the next 1-2 minutes
<wallyworld> \o/ thanks :-)
<wgrant> StevenK: Did you just make them uninstallable in the DC? :)
<StevenK> wgrant: Huh?
<StevenK> wgrant: But buildbot doesn't update from the PPA?
<wgrant> StevenK: No.
<wgrant> StevenK: But making the dependency packages uninstallable on buildbot is pretty unpleasant.
<StevenK> wgrant: I was of the opinion that the dependencies packages had to get copied to CAT
<wgrant> Ah, true.
<StevenK> Oh, damn it.
<StevenK> My launchbag branch failed with a message so large my mail server rejected it.
<nigelb> lol
<StevenK> And I think the instance has just killed itself.
<wgrant> StevenK: Locally run bin/test -cvvt lp.bugs?
<StevenK> Yes, I was planning on
<StevenK> wallyworld: Right, meta package updated.
<StevenK> Strangely, apache2 is a Suggests of developer-dependencies
<StevenK> It's forcibly installed by rf-setup
<wallyworld> wonder why
<StevenK> Because it's not required to run the tests
<wallyworld> ok
<StevenK> So people will have to install libapache-mod-wsgi when they want to test the combo loader
<StevenK> wallyworld: In either case, you can toss your branch at ec2 test
<StevenK> Sigh, libapache2-mod-wsgi
 * wallyworld tosses
<StevenK> wallyworld: It should have built, can you run 'bin/ec2 ls --show-urls' and see what the log shows
<wallyworld> StevenK: ah, bollocks. i didn't look back at the console after i ran and there was an error. trying again
<StevenK> What error?
<wallyworld> i pasted in the mp url instead of the branch
 * wgrant tries not to be sick.
<StevenK> wgrant: Hmm?
<wgrant> StevenK: https://bugs.launchpad.net/launchpad/+bug/556680/comments/5 and https://bugs.launchpad.net/launchpad/+bug/881019/comments/15
<wgrant> Beware, there is OpenID.
<StevenK> The novel you posted to bug 556680 is impressive.
<wallyworld> wgrant: can has quick review? https://code.launchpad.net/~wallyworld/launchpad/sortable-dates-fix-918892/+merge/89380
<wgrant> wallyworld: Ah, heh.
<wgrant> r=me
<StevenK> wallyworld: I won't ask how long *that* took to track down.
<wallyworld> thanks. took me ages to find the problem. seems really simple now
<wallyworld> about 4 #@%@^ hours
<wallyworld> my brain hurts sooooo much today. this week it has done a lot of cogitating
<wallyworld> wgrant: could use lp-land for me? pretty please. ec2 land now works but lp-land still is broken
<wgrant> Good to see you living dangerously :)
<wallyworld> well, there are no tests for it
<wgrant> Heh
<wallyworld> and it's broken anyhow
<wgrant> Submitted
<huwshimi> wallyworld: What's wrong with you lp-land?
<huwshimi> *your
<wallyworld> huwshimi: an api change in precise
<wallyworld> one of the bzr libs
<huwshimi> wallyworld: Oh, awesome
<wallyworld> various get_foo methods replaces by get('foo'), or something like that
<wallyworld> it's known
<StevenK> wgrant: Total: 3223 tests, 112 failures, 99 errors in 56 minutes 38.785 seconds.
<StevenK> I think I see why the failure mail was 15MiB.
<StevenK> wallyworld: I wonder if pqm-submit works for you
<wallyworld> StevenK: use-convoy => devel  [FAILED]   (up for 0:37:03) i-e81c158a.... waiting for the email to arrive to see what happened
<StevenK> That will take another 3+ hours
<StevenK> You can add --show-urls and open the URL it shows
<wallyworld> StevenK: actually, i updated bzr-pqm earlier today so perhaps it will work
<wallyworld> StevenK: failures due to doc test errors. extra lines like "import site' failed; use -v for traceback"
<StevenK> Hm
<StevenK> You may have to run them locally
<wallyworld> so with that extra output, most all doc tests break. but other tests appear fine
<wgrant> It's of course possible that ec2 only runs apt-get upgrade, so it won't have installed convoy...
<wallyworld> how is import site related to convoy being installed?
<wgrant> Is there much else it could be related to?
<wgrant> They're not obviously related, but it's the only thing that comes to mind.
<wallyworld> no, but i don't get the correlation
<wgrant> site overrides our pythonpath and various other evil things.
<StevenK> wgrant: The make was successful, so it has
<wgrant> Hmm
<StevenK> upgrade will install new dependencies of already installed packages that are to be upgraded
<wgrant> Except sometimes it doesn't.
<StevenK> Depends on the situation
<wallyworld> yes, without convoy installed, make failed
<StevenK> apt has some funny ideas
<wgrant> Frequently eg. linux-generic gets held back, despite just requiring installation of new ABIed packages.
<wallyworld> i tried locally a test and i got a different error
<wallyworld> 'import sitecustomize' failed; use -v for traceback
<wallyworld> similar but different
<StevenK> wgrant: ec2 does aptitude update and aptitude -y full-upgrade
<StevenK> Yay for pointlessly different package resolution
<wallyworld> i get 'import sitecustomize' failed; use -v for traceback whenever devel/bin/py runs
<wallyworld> everything that doesn;t try and match text against stdout like doc tests do seems to work
<StevenK> Let's delete all doctests.
<StevenK> I can't see anyone disagreeing with that plan.
<wallyworld> i'd still like to know wtf is going on
<wallyworld> doctests are useful if they are used as doco plus examples to show how to use the apis
<wgrant> use -v for traceback :)
<StevenK>     self.user = request.user
<StevenK> AttributeError: 'LaunchpadTestRequest' object has no attribute 'user'
<StevenK> RARGH!
<StevenK> Hmm
<StevenK> request.principal ?
<wallyworld> python 2.7 related error it seems https://pastebin.canonical.com/58488/
<wgrant> StevenK: request.user should be right, but maybe LTR doesn't provide it.
<StevenK> It would seem it does.
<StevenK> Er, does not
<StevenK> wgrant: lbr.user == AttributeError: 'LaunchpadBrowserRequest' object has no attribute 'user' / lbr.principal == None
 * StevenK shakes his fist at LaunchBag
 * StevenK is concerned that we don't any production OOPS report from today.
<wgrant> StevenK: postgres was restarted for an upgrade, so it's not entirely surprising.
<StevenK> Ah
<wgrant> The amqp2disks died, but I restarted them.
<StevenK> wgrant: http://www.flickr.com/photos/telekon/6718360105/
<adeuring> good morning
<danhg> Morning guys
<rick_h> morning
<jml> Does anyone know where lifeless's list of architecture values lives on the web? (ISTR "visible" and "fast" being two of them)
<cjwatson> jml: http://launchpad.readthedocs.org/en/latest/values.html ?
<cjwatson> or http://launchpad.readthedocs.org/en/latest/strategy.html
<cjwatson> (https://dev.launchpad.net/ -> "Documentation in the Launchpad tree" -> ...)
<rick_h> we've got RTD? didn't know that
<jml> cjwatson: thanks, but those are more functional / user-level values. (Also, those are the ones I wrote :))
<jml> hmm. actually, I think it's in a slide somewhere.
<cjwatson> ah, heh
 * cjwatson goes to teach granny to suck eggs, too
<jml> cjwatson: heh heh
<jml> rick_h: yeah, I set it up in a fit of effort for making the codebase more approachable through more navigable docs
<rick_h> cool, /me markes the buildout doc as must read sometime today
<jml> I guess people still rely more on code and the oral tradition.
<jml> rick_h: I'm biased, but the README is pretty fun.
<jml> found it: https://docs.google.com/a/canonical.com/present/view?id=0AR8DGdpwOJuiZGdwZGNmbjlfN2t2ZHBxanhx&hl=en_US
<cjwatson> Code gets less out of date :-/
<jml> oh huh, https://dev.launchpad.net/ArchitectureGuide/
<rick_h> yea, and code you can test/run with. Often I find I end up chasing one doc to another for hours.
<rick_h> it's like getting sucked into wikipedia
<jml> cjwatson: yeah.
<jml> actually, well, sort of.
<jml> one thing LP suffers from is that the way of doing things changes, but not all of the instances of the old way are updated
<jml> or are partially updated
<jml> and then when you go to use some existing code as a reference, you have little clue as to whether it's a good quality reference.
<rick_h> +1 to that
<cjwatson> Yep.  The existence of deprecated functions that have no external API ...
<cjwatson> JFD(elete)I
<jml> or multiple variant spellings of displayname, date_created etc.
<jml> Oh how I'd love to go to Launchpad with a sharp knife and a clean conscience.
<cjwatson> the piles of sqlobject stuff still around are particularly confusing for this newcomer
<jml> this old timer too.
<StevenK> cjwatson: I get quite scared about moving some of the Soyuz stuff from SQLObject to Storm since some of the queries are on a knife-edge as it is ...
<bigjools> yeah, there's loads of preloads going on in the old-style queries that will be affecting code used in completely different placves
<bigjools> bit of a shambles
<wgrant> A lot of it is already so slow that it doesn't really matter, though.
<wgrant> It's not *that* bad.
<jml> StevenK: I guess if you're reluctant to do something useful because of uncertain negative consequences, then the thing to do is find some way of safe experimentation.
<jml> StevenK: there's such a thing as paralysis from lack of analysis
<StevenK> On the other hand, I did just change a query in BPPH from SQLObject to Storm and due to having a bit of denormalised data and a new index, it dropped from 6000ms to about 30.
<jml> woot
<Laney> What's the right way to run doctests? I'm just getting NameError for everything.
<rick_h> Laney: which doctests are you trying to run? the filename?
<Laney> bin/test -cvv -t soyuz/doc/publishing.txt
<StevenK> No path
<StevenK> Just publishing.txt
<Laney> ah
<wgrant> Well
<wgrant> -t takes a regex
<Laney> yeah, still fails
<wgrant> what's the error?
<Laney> if HTTP was working I could show you ...
<Laney> wgrant: http://paste.debian.net/152951/ and others like it
<wgrant> Those are cascading from a real failure at the top.
<Laney> do I need to set up the database somehow?
<wgrant> You need to find the first error.
<wgrant> Setting copied_binary failed at some point.
<Laney> 1s.
<wgrant> doctests are a bit awesome like that -1
<wgrant> Er
<wgrant> The -1 option used to show only the first error.
<wgrant> But that broke a year or so ago :(
<jml> buh bow
<Laney> yes, yes, I see it now. Somewhat buried.
<jml> for the parallel testing stuff, I guess you're going to stick w/ z.testing?
<wgrant> jml: Yep
<Laney> do they use a different database?
<wgrant> jml: Just with testr + LXC on top of it
<wgrant> Laney: Each time the testrunner starts it creates a fresh DB from launchpad_ftest_template, named launchpad_ftest_$PID
<Laney> right, so I need to patch the template. ta.
<rick_h> anyone give me a hint what I'm looking for with this question in #launchpad? http://paste.mitechie.com/show/507/
<rick_h> the thing says "published 17hrs ago" and I'm not seeing a queue or something else that's pending
<jml> wgrant: makes sense. still, would be nice to ditch zope.testing, or at least be not using a fork of an old version.
<wgrant> jml: Indeed.
<Laney> https://code.launchpad.net/~laney/launchpad/add-sponsor-field-to-spph just fixed the test failures â stupid omission â and would appreciate another go at ec2
 * cjwatson finds
<cjwatson>     # A helper for the common case.  IWBNI we had Python 2.5 because
<cjwatson>     # then we could just use functools.partial().
<rick_h> Laney: sure thing, will fire it off
<wgrant> cjwatson: At least it's only in a test.
* bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: bac | Firefighting: - | Critical bugtasks: 3*10^2
<cjwatson> It's OK to rely on switch_dbuser committing the transaction, right?
<Laney> rick_h: thanks
<wgrant> cjwatson: Yes. But you should normally be using 'with dbuser', probably.
<wgrant> cjwatson: You can also use it from FunctionalLayer now, rather than just ZopelessLayer.
<wgrant> You'll still see some tests around saying they're ZopelessLayer so they can change DB users, but I fixed that a few months ago.
<cjwatson> wgrant: Right, I just found an old thing that said it had to commit because switching DB users did transaction.abort.  I'll kill that.
<wgrant> cjwatson: That used to be the case, but 10 refactoring branches later and it's a bit more sensible.
<wgrant> with dbuser: does commit/switch/yield/commit/switch, which is usually what you want.
<cjwatson> Yup.
<cjwatson> Or with lp_dbuser.
<deryck> Morning, all.
<bigjools> howdy kirkland
<kirkland> bigjools: howdy :-)
<bigjools> practising my Texan
<kirkland> bigjools: okay, so we have a commercial LP license
<bigjools> anyway! I think it's fine
<kirkland> bigjools: well done :-)  You wear the jersey, already :-)
<bigjools> provided that it's done only for private PPAs
<bigjools> yes I've been indoctrinated with Burnt Orange
<kirkland> bigjools: heh, well, i'm all aggie, but i won't hold that longhorn affliction against you ;-)
<bigjools> also it should be opt in on the +edit page and only enabled if the PPA is private
<bigjools> however there are some repercussions of doing this
<kirkland> bigjools: okay, so a "publish source", as an option, default to true for legacy compatibility
<bigjools> aggie? I've been told that you guys shag sheep!
<bigjools> vicious rumours I'm sure
<kirkland> bigjools: :-P
<bigjools> moving on ...
<bigjools> if we don't publish sources, they will remain as PENDING forever
<bigjools> which slows down the publisher
<kirkland> bigjools: can we publish them and then purge them immediately?
<bigjools> so I will need to look at a way around that
<bigjools> well the other option is to mark them PUBLISHED but not actually publish
<kirkland> bigjools: okay
<bigjools> kirkland: can you file a bug about this so we can discuss there and I can subscribe wgrant who will no doubt have a strong opinion
<kirkland> bigjools: any idea of how hard or complex this would be?
<kirkland> bigjools: sure, against launchpad itself?  or another component?
<bigjools> not particularly hard at all for someone with LP experience
<bigjools> yes lp
<bigjools> you need a schema change, a model change, view code changes and a publisher change
<bigjools> it's the latter that needs careful attention
<bigjools> for example, if we mark them PUBLISHED and they are not and you change your mind with the flag, then you can never publish those sources
<kirkland> bigjools: https://bugs.launchpad.net/launchpad/+bug/919241
<_mup_> Bug #919241: provide an option to no publish sources in a private ppa <Launchpad itself:New> < https://launchpad.net/bugs/919241 >
<bigjools> there's currently a method that fetches all PPAs with pending publications, and it does that by UNIONing two queries, one for sources one for PPAs.  It could be split into two methods and optionally unioned by the main publisher if sources are needed
<bigjools> kirkland: I'll comment on there with my thoughts.
<kirkland> bigjools: perfect, thanks
<bigjools> fixed the bug title :)
<kirkland> bigjools: okay, perhaps this is a bit over my head, then
<bigjools> no really, it's not too bad
<bigjools> as far as LP patches go :)
<bigjools> I'll describe a proposed change
<kirkland> bigjools: rockin'
<kirkland> bigjools: I've subscribed two of my colleagues (who are also in #launchpad)
<kirkland> bigjools: its their work that is currently blocking on this bug
<bigjools> cool
<kirkland> bigjools: we're doing some really ugly work arounds in the mean time
<kirkland> bigjools: and it's just not pretty
<bigjools> I bet
<kirkland> bigjools: last thread of questions...  walk me through the dev process for getting something like this implemented
<bigjools> one sec
<kirkland> bigjools: does it need to land in a blueprint or a sprint or work its way through a backlog?
<bigjools> kirkland: no, none of that is needed.  JFDI.
<kirkland> bigjools: cool
<bigjools> someone will be happy to mentor you although I am not sure how much time I will personally have
<kirkland> bigjools: okay, any pointers to suitable mentors for this one?
<bigjools> so anyone can guide you through the landing process, but you need a soyuz expert to review the changes
<kirkland> bigjools: can you give me a few l33t soyuz nicks?
<bigjools> which is basically me, wgrant, StevenK and jtv to some extent as he has worked on the publisher. He might kill me for saying that though :)
<kirkland> bigjools: :-)
<jtv> bigjools: this is where the "hey let's get together sometime in the coming weeks" becomes useful.
<bigjools> once my question in the bug is answered, this is a really easy change
<jcsackett> Laney: did you see your branch test results?
<rick_h> jcsackett: yea, she fixed it and I'm rerunning the tests for her
<rick_h> jcsackett: hope you don't mind, I responded to the loggerhead reviews and attached you for follow up review since we talked/started looking at those yesterday
<jcsackett> rick_h: don't mind at all.
<rick_h> deryck: in checking the diff of devel vs use-convoy I'm seeing a bunch of python -> python2.6 hard coded?
<rick_h> hmm, must be generated because I don't see it in the MP diff
<deryck> rick_h, that's a buildout thing. I did wonder if python version mattered, based on my quick look at the error
<rick_h> deryck: yea, sending an email back with my findings so far
<rick_h> in case it jogs anything in your head
<rick_h> but forgot to add the -dev list
<sinzui> deryck, do you have a few minutes to discuss some incomplete widget javascript
<deryck> sinzui, sure.
<deryck> hangout or mumble?
<sinzui> I will try hangout
<deryck> k
<sinzui> Looks like I can start a hangout from my phone if I send a message to you
<deryck> ah ok, I started one and invited you.
<deryck> I'll kill mine.
<deryck> sinzui, you don't show up for me.  I don't mind jumping to mumble instead.
<sinzui> you start and I will join
<sinzui> I am still learning this
<sinzui> deryck, https://bugs.qastaging.launchpad.net/launchpad/+bug/583392
<_mup_> Bug #583392: IntegrityError raised setting a branch for a project series. <branches> <easy> <lp-code> <oops> <series> <Launchpad itself:Triaged> < https://launchpad.net/bugs/583392 >
<wgrant> kirkland: It's far harder than it seems.
<wgrant> kirkland: Because private PPA builds get the source files from the published archive.
<wgrant> kirkland: I suspect what you really want is to be able to copy binaries without sources into another PPA
<kirkland> wgrant: okay
<wgrant> But that is a terrifying proposition.
<kirkland> wgrant: *that* would be phenomenal
<kirkland> wgrant: we're happy with our builds
<kirkland> wgrant: but we *only* want to publish the debs
<kirkland> wgrant: for some projects
<kirkland> wgrant: why is that a terrifying proposition?
<kirkland> bearing in mind that i hate non-free software as much as the next guy
<kirkland> (the next guy in this channel)
<wgrant> kirkland: I was ignoring the non-free bit. It's terrifying because pretty much all of Soyuz is based around being able to have the sources there as well.
<kirkland> wgrant: urgh
<wgrant> I'm not quite sure how to model this.
<wgrant> It's certainly doable.
<wgrant> And the basics would be easy to get working.
<kirkland> wgrant: maybe we need to just run our own archive.gazzang.com and just mirror the debs from the private ppa
<wgrant> But lots of stuff would probably break down the line.
<kirkland> wgrant: bummer
<abentley> bac: Could you please review https://code.launchpad.net/~abentley/launchpad/bugcomment-as-icomment/+merge/89497 ?
<bac> abentley: sure
<abentley> bac: Thanks.
<bac> abentley: nice.  very clear branch.
<abentley> bac: Thanks.
<sinzui> bac: are you still reviewing? do you have time for https://code.launchpad.net/~sinzui/launchpad/dsp-vocab-fixes/+merge/89505
<bac> sinzui: sure
<bac> sinzui: done
* bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 3*10^2
<sinzui> thank you bac.
 * sinzui spell checks test module
#launchpad-dev 2012-01-21
<rick_h> if anyone's around would really love a quick review on this so I can get it through ec2 over the weekend and hopefully part of first deploy of hte week. https://code.launchpad.net/~rharding/launchpad/resizing_textarea_919299/+merge/89515
<Laney> ah, qastaging deployment doesn't happen during the weekend?
<cjwatson> qastaging should do, since it's automatic
<cjwatson> Unless buildbot falls over
<rick_h> Laney: sorry, need to ping you. tests pass but pqm hated me so it's not merged
<rick_h> Laney: just manually submitted it to pqm, see if it takes this time
<lifeless> quit
<Laney> qastaging is suspiciously broken, and I rather suspect the blame might lie with me.
<Laney> OOPS-bd50292c15319089fb6182e0346d2160
<Laney> similarly getPublishedSources is non-functional
<Laney> OOPS-84d056de56eb3a3d663f5ca691aad0ef is from a getPublishedSources call
<nigelb> Laney: Achivement Unlocked!
<Laney> ._.
<nigelb> You get the "I broke something with a branch" badge.
<nigelb> I once I had to do 3 tries to get my branch to work.
<nigelb> (that's the one that gives the bug title when you mouse over a bug)
<Laney> being able to see inside the OOPS would be helpful
<Laney> it's not this broken locally :(
<Laney> hold me
<nigelb> Ouch
<nigelb> Laney: Some of the few launchpadders who look at IRC on weekends are the australians. So you'll have to look for wgrant tomorrow, or maybe lifeless.
<james_w> Laney, qastaging doesn't have the db patch applied, or doesn't have the right patch, or something
<james_w> ProgrammingError: column sourcepackagepublishinghistory.sponsor does not exist
<Laney> james_w: huh, weird, but OK that's not so bad as far as I'm concerned then â¦
<Laney> can I get python-launchpadlib to poke api.launchpad.dev somehow?
<james_w> Laney, yeah, just set the service_root to launchpad.dev
<james_w> service_root='dev' should work
<Laney> tidy.
#launchpad-dev 2013-01-14
<StevenK> wgrant: Something about cleanup? Or should I keep searching for a critical?
<wgrant> StevenK: I'm arranging the cleanup. I suspect another critical would be a good idea
<StevenK> wgrant: Bug 1087896 is timing out on making suggestions for things to translate. I can recall ripping that out, but I'm not sure what pageid it was for.
<_mup_> Bug #1087896: timeout when I click on "Translations" on my personal page <lp-translations> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1087896 >
<StevenK> r16212, Remove ITranslationsPerson.suggestReviewableTranslationFiles() and the parts of Person:+translations that call it.
<wgrant> Yeah
<wgrant> That was for review suggestions
<wgrant> This is about translation suggestions, I think
<StevenK> Yeah, the implicated method is ITranslationsPerson.suggestTranslatableFiles()
<StevenK> The two faster queries that are run fetch things the person has translated, so small data set.
<wgrant> What does this one do?
<StevenK> Find a bunch of POFiles that the user has not touched, ORDER BY random()
<wgrant> Hah
<wgrant> How helpful
<StevenK> Right, it's another anti-join
<StevenK> Like suggestReviewableTranslationFiles
<plomme> hey guys, I'm brand new, I'm trying to find view(s) for the graphed timelines on overview pages (or anything related). I've just literaly openned the API, figured I would ask as it would save me some time
<plomme> nvm got it
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/remove-suggested-translation-files/+merge/143058
<wgrant> StevenK: Have you considered how this will affect the list?
<StevenK> wgrant: It will still list the top ten, but less than that if the translator hasn't been so active
<wgrant> StevenK: Not quite
<StevenK> wgrant: What will happen to the list, then?
<wgrant> StevenK: It looks to me like it will consist of at most 6 items
<StevenK> Hm
<StevenK> wgrant: http://pastebin.ubuntu.com/1529859/
<wgrant> StevenK: There's also an unused 'fetch =' in that method
<wgrant> And you eliminate the sole _composePOFileTranslatorJoin call, but don't eliminate the method AFAICT
<wgrant> Ah, yes you do
<StevenK> http://pastebin.ubuntu.com/1529867/
<StevenK> I suspect this results in more test fallout, so let's see
<wgrant> That looks more reasonable.
<wgrant> Have you checked around for docstrings that describe the old behaviour?
<wgrant> eg. your MP description didn't actually mention the effect of the change at all
<StevenK> wgrant: I've corrected the MP description
<StevenK> And I think I've fixed all of the test docstrings
<wgrant> StevenK: r=me
<StevenK> wgrant: Thanks
<StevenK> Looks like I refreshed as you were submitting
<wgrant> StevenK: That's a rather dishonest commit message :)
<plomme> quick question regarding JS
<plomme> there are regular and minified files
<plomme> I also noticed that my changes in JS files were reset after make run (not sure about this. either that or I forgot to save my changes)
<plomme> what's the correct procedure when modifying JS files? should I port my changes to the min version as well?
<plomme> or is there another layer above those (and that's what I should be editing)
<wgrant> plomme: Edit the original JS files under lib/, then run 'make jsbuild' to build the minified and unminified versions in build/
<StevenK> wgrant: How so?
<plomme> great thanks =)
<wgrant> StevenK: You're removing some random results from the list of suggestions
<wgrant> You're not removing the suggestions :)
<StevenK> wgrant: Do you think we have a plan re: MixedVisibilityError?
<wgrant> Not at this stage
<wgrant> Ignore
<StevenK> BranchRevision is still waiting, or do you have a half-formed plan?
<wgrant> BranchRevision is going to be the largest change we have to make to fix any critical
<wgrant> I'm sure there's a more practically sized one that you can find :)
<StevenK> wgrant: Ah, but that doesn't answer the question
<wgrant> There's a semi-formed semi-plan
<StevenK> wgrant: I laugh at https://bugs.launchpad.net/launchpad/+bug/983766/comments/1
<_mup_> Bug #983766: Error when uploading screenshot incl. a question mark in url <404> <bugs> <webapp-infrastructure> <Launchpad itself:In Progress by wgrant> < https://launchpad.net/bugs/983766 >
<wgrant> I did :)
<wgrant> But that resulted in a need to followup with more people
<StevenK> wgrant: I can recall the issue in https://oops.canonical.com/?oopsid=OOPS-a4c5d1fa67a0f9de6b1cb8d8149499fc , from some wacky method that is trying to generate names, but I thought that was fixed.
<wgrant> StevenK: It was never fixed, just diagnosed
<StevenK> wgrant: What's the method?
<wgrant> It's not in the traceback?
<wgrant> The OOPS is still loading for me
<wgrant> I'm just assuming that it's the person name conflict resolver issue
<StevenK> Oh, _is_nick_registered
<wgrant> That will be the one making the queries
<wgrant> But it's _is_nick_registered's callsite that has the bug
<StevenK> generate_nick, then
<StevenK> wgrant: I fixed the commit message before landing, too
<wgrant> :)
<StevenK> I thought it had landed, but I got distracted by being asked to switch machines
<StevenK> wgrant: So, uh, how do I fix this terribleness?
<StevenK> I can recall you and Curtis discussing it, but not the solution.
<wgrant> StevenK: We need to decide what we want to do
<wgrant> Do you understand the problem?
<StevenK> We don't want to include the e-mail domain in the nick, we can't have nick collision, and we don't want to loop 1000 times?
<wgrant> Those are the key constraints, yes
<StevenK> And the name can not be blacklisted
<wgrant> But why is it looping 1000 times?
<StevenK> It wants a unique name, at a guess
<wgrant> Right, but why does it take so many loops to get one?
<StevenK>         while attempts < 1000:
<StevenK> Based on the number of OOPSes, we never even get close.
<StevenK> Perhaps 750 iterations
<wgrant> That's why it's limited to 1000, but that doesn't explain why the collision resolution ends up trying so many
<StevenK> I'm still trying to grok the call chain
<StevenK> wgrant: I have a theory. They start with a blacklisted name, and it doesn't matter what we do to the name, it still ends up blacklisted
<StevenK> Like, adding a prefix means it's still blacklisted, or adding a suffix
<wgrant> A reasonable theory
<wgrant> But if you look at the method, you'll see it also eventually permutes the characters of the original name
<wgrant> Which surely gets past any blacklisting
<StevenK> The queries in this OOPS just keep adding suffixes
<StevenK> So we have launchpad-<137 * random alphanumerics>
<wgrant> WHERE Person.name = E'78luphr0rnk2nuqimstywepozxn9kl19tqh0tx66b5dki1x-phn5h7o65-a811i2i3ytqlsztthjth0svbccw8inm65tmkqp9sarr553j'
<wgrant> launchpad has become phn5h7065
<wgrant> s/0/o/
<StevenK> wgrant: Look at the query after that one, though
<StevenK> Just before the transaction is marked Doomed
<wgrant> StevenK: Sure
<wgrant> The next attempt at creating a name attempts to extend the suffix
<StevenK> And includes the nickname again
<wgrant> The order of attempts is suffix, prefix, mutation
<wgrant> So it will add a suffix, then a prefix, then a mutation
<wgrant> If none of those work, it will extend the suffix
<wgrant> Then apply an extended prefix
<wgrant> Then apply an extended mutation
<wgrant> etc
<wgrant> But once it moves onto a new iteration it will start from an untainted name
<wgrant> So if suffix, prefix and mutation all fail to yield a new name, it will go back to just a suffix, adding more characters onto the suffix from the previous round
<StevenK> wgrant: Until it grows to monstrous size?
<wgrant> Right
<wgrant> But why would all the hundreds of names fail?
<StevenK> All of them are invalid?
<wgrant> They're all not valid names for a new person for some reason
<StevenK> Which is odd
<wgrant> Not terribly so
<StevenK> Oh, this thing is always seeded with the same value, and so will always try the same steps?
<wgrant> Bingo
<wgrant> There's one very simple fix
<StevenK> Change the seed
<wgrant> Right
<wgrant> But it still needs to be testable
<StevenK> So use a well-known one for testing
<wgrant> You could
<wgrant> And use a random one on prod?
<wgrant> I can see a better possibility
<StevenK> Which sort of defeats the point of the test, right
<StevenK> wgrant: What's that?
<wgrant> Spoilers!
<StevenK> wgrant: We stop doing this whole random garbage?
<wgrant> No
<wgrant> If you recall the history here, we used to include the domain
<StevenK> Indeed, yes.
<StevenK> And then people said stop doing that
<wgrant> eg. my test account would be me+testing-williamgrant, rather than me+testing
<wgrant> Right
<wgrant> So collisions used to be much more unlikely
<wgrant> Now, we can't include the domain in the nick
<wgrant> But we could include it somewhere else
<StevenK> How does that help us generate a nick, though?
<wgrant> We can't help the uniqueness of the original nick
<wgrant> But we can help the uniqueness of the collision resolution
<StevenK> Oh, use the domain as a random seed or so?
<wgrant> Exactly, we could seed the RNG with the entire email address, like the old days
<StevenK> Mmmmm
<StevenK> And means it's still testable
<wgrant> Exactly
<wgrant> It also means that someone can verify their guess for the email address if the user has an autogenerated and collided username
<wgrant> But I'm not sure that's a huge concern
<StevenK> email_addr + current timestamp, but that means it's hard to test
<stub> We don't use that many signups - you could just use a sequence in the db for a globally unique number.
<stub> Not that it really helps when someone signs up using 'launchpad@example.com' and .*launchpad.* is blacklisted.
<StevenK> launchpad_dogfood=# SELECT COUNT(name) FROM person WHERE name LIKE 'launchpad-%%'; => 629
<wgrant> and that's less than a third of them
<StevenK> SELECT COUNT(name) FROM person WHERE name LIKE '%%launchpad%%'; => 6215
<wgrant> I'd just seed from the email address and be done with it
<StevenK> wgrant: I'll have a branch for you to review in a few seconds
<StevenK> If it scans
<StevenK> wgrant: Do we have a bug, or should I file one?
<wgrant> Not sure
<wgrant> StevenK: r=me
<StevenK> wgrant: Thanks
<StevenK> I was distracted by filing a bug
<StevenK> It's High, but bump it to Critical if you think its warranted
<wgrant> It's timing out
<wgrant> Doesn't that make it critical?
<StevenK> wgrant: Trying to not increase the critical count :-P
<stub1> If the existing blacklist code is slow btw, we could compile it in entirety into a single regexp. Last I looked it was 'good enough' though.
<StevenK> stub1: Random seed plus stepping plus random transforms.
<lifeless> StevenK: it is what it is.
<StevenK> lifeless: "that that is is that that is not is not is not that it it is"
<lifeless> hah
<StevenK> Grrr
<StevenK> I dislike losing buildbot bingo
<StevenK> stub: It's not slow queries that's causing the timout, it's doing 800 loops to find a name that doesn't clash.
<StevenK> *timeout
<stub> StevenK: Yah, but that also means 800 db queries atm I think. if you did need to do it 800 times, we could do it client side. But you don't, so don't bother.
<wgrant> The collision resolution code was never meant to run more than a few times
<wgrant> It's just that the consistent seed meant it always resolved identically.
<StevenK> For the same localparts, at least.
<StevenK> wgrant: Heh, there is an interesting question as how to QA it ...
<wgrant> StevenK: I'd wait until it gets onto staging, create a temporary email alias and create an account for it on staging SSO, then log in and see what happen
<wgrant> launchpad@ or ubuntu@ should do
<wgrant> Maybe admin@
<adeuring> good morning
<czajkowski> jtv: ping any idea what could trigged translation import queue going from 0 -> 874 in less than an hour ?
<jtv> czajkowski: typically a large upload...  possibly pulled in from branches.
<czajkowski> never seen that many
<jtv> Whose import queue exactly?
<czajkowski> usually get 10-15 in a go
<czajkowski> https://translations.launchpad.net/+imports/+index?field.filter_target=[PRODUCT]&field.filter_status=NEEDS_REVIEW&field.filter_extension=pot
 * czajkowski is going to be at this all day 
<jtv> czajkowski: simply a KDE upload, I suspect.
<czajkowski> wow
<czajkowski> ok thanks
<jtv> KDE translations aren't bundled into the packages.
<czajkowski> if anyone is looking for me today I shall be giving myself RSI doing this reviews
<czajkowski> :/
<jtv> Instead, they have separate translation packages that will contain, for instance, *all* Greek translations for KDE main.
<czajkowski> 869 and counting
<jtv> Let me have a look.
<czajkowski> cheers
<jtv> czajkowski: be sure to give the auto-approver some time to do as much as it can automatically!
<czajkowski> nods
<jtv> I'm surprised to see KDE uploads for projects rather than for Ubuntu.
<jtv> Oh God, they set up a Bosnian translation for "universe."
<jtv> As a project.
<jtv> That shouldn't happen.
<jtv> I mean it's admirable that they translate universe, but this isn't the way.  Before you know it, you're inviting the world to come to your project and translate everything to their own languages.
<jtv> Which is not likely to do much good if the project is really only there for one language.
<czajkowski> nods
<jtv> Yup.  They set it to Open.  :(
<jtv> And with Launchpad Translators as the translation group.
<jtv> That means: "we do Bosnian translations for universe here.  Come on, everybody, submit translations for your own languages and the Launchpad translation group people will review them, and then they will go nowhere because we're only running this project for one language."
<jtv> This needs some kind of effort to avoid duplication of effort.
<czajkowski> ugh
<jtv> They've already attracted some Italian and Spanish translations, I think.
<jtv> And especially Turkish.
<czajkowski> can we delete all of these imports?
<jtv> czajkowski: I'd suggest setting them to Needs Information, after emailing the owners about this problem.  I don't know if there are any efforts for Universe translations underway, but if so, they ought to try and coÃ¶rdinate with it.  If not, maybe if Milo / David agree, it might be an idea to promote the project to a general universe translation group.
<czajkowski> dpm: ^^^^
<jtv> In any case Launchpad Translators wouldn't be quite the right translation group for this â it's Ubuntu, not Launchpad.
<czajkowski> Gwaihir: cheers
<Gwaihir> hello!
<czajkowski> Gwaihir: a team has set up Bosnian trnaslation for universe as a project
<czajkowski> we now have over 869 pots to review :)
<czajkowski> 12:15 < jtv> czajkowski: I'd suggest setting them to Needs Information, after emailing the owners about this problem.  I don't know if  there are any efforts for Universe translations underway, but if so, they ought to try and coÃ¶rdinate with it.  If not,  maybe if Milo / David agree, it might be an idea to promote the project to a general universe translation group.
<Gwaihir> uhh... awesome
<Gwaihir> there were discussion about opening up translation for universe, and also some suggested packages, but I think nothing was move forward
<czajkowski> someone was eger
<Gwaihir> I have to look into what will happen to those translations, if they will ever be exported and used by ubuntu, otherwise it is a void task
<czajkowski> exactly
<Gwaihir> I would rather set them as "need info" for now and touch base with the Bosnian team, I have to do some research on what's the status with universe translations
<wgrant> Regardless, a language-specific project is wrong
<jtv> Exactly.  And it'd be nice to resolve that in a forwardly direction that makes everyone happy.  Too often in the past have we just told people "you can't do that."
<czajkowski> Gwaihir: ok will mark them all as needs info
<czajkowski> Gwaihir: will you make contact
<dpm> Gwaihir, jtv, czajkowski, enabling universe translations is basically on hold. We tried to enable them and contacted some interested upstreams. Banshee was one of them, and we enabled translations in Launchpad. Everything was working fine up to the export part, which we only realised after the next language pack creation
<Gwaihir> czajkowski, yup, not a problem, I will ping the other translators too about the status of opening up universe fro translations
<dpm> https://bugs.launchpad.net/launchpad/+bug/1048556
<_mup_> Bug #1048556: Language pack translations export needs to add universe packages to domain map <langpack> <lp-translations> <Launchpad itself:Triaged> <Ubuntu Translations:Triaged> < https://launchpad.net/bugs/1048556 >
<czajkowski> cheers folks
<Gwaihir> thanks dpm!
<dpm> So that bug is currently stopping us from shipping universe translations for selected packages
<dpm> it seems 99% of it is working, but the translations are not listed in the text file the export generates, and they are thus ignored by langpack-o-matic (the tool that fetches the Launchpad translations export and creates the actual language packs)
<czajkowski> that bug is on the low list of LP maintenace work and more than likely will not get fixed any time soon
<jtv> :(
<czajkowski> well we're down to 2 people on maintenance folks
<czajkowski> and they are doing criticals
<wgrant> s/maintenance/LP/
<czajkowski> well 2 of ye and one of me :)
<czajkowski> and I don't break anything :p
<jtv> Except hearts, I'm sure!
<jtv> Ahem.
<czajkowski> lol
<wgrant> Though I don't really see why the domain map doesn't include them
<wgrant> As long as POTemplate.languagepack is set
<jtv> You're thinking maybe a tiny step in the right direction to make the goal just a little bit more tempting?
<czajkowski> wgrant: can you answer in lp am at 848 on a roll here!
<dpm> jtv, any ideas on that bug ^^?
<jtv> dpm: It's been long enough that I feel the other commenters are more current with it now.  :(
<wgrant> dpm: Do you have an example of a package that was not exporting?
<dpm> wgrant, we've disabled the templates, so we won't find it in any langpack-o-matic logs. I remember we first noticed it with banshee, let me see if I can think of any other.
<wgrant> dpm: banshee in precise?
<dpm> wgrant, let me check, I think we even tried to add a special case for it in the langpack-o-matic code
<wgrant> 'cause https://translations.launchpad.net/ubuntu/precise/+source/banshee/+pots/banshee/+admin doesn't have the langpack flag set
<wgrant> Which would explain it
<wgrant> It's set in raring, but there's no raring export yet
<wgrant> dpm: The flag is set in quantal, and I see 'banshee banshee' in the mapping.txt from the export in October.
<wgrant> And banshee is in universe in quantal
<wgrant> So I think that bug is wrong :)
<dpm> hm, that's really weird
<dpm> wgrant, we even implemented a workaround in Quantal for banshee and gnome-panel. Here's the diff of the modification pitti did on langpack-o-matic
<dpm> http://pastebin.ubuntu.com/1530750/
<dpm> those were two packages that weren't in the mapping.txt file we looked at when we first noticed the issue
<dpm> unfortunately, I don't have that particular file anymore
<wgrant> They're certainly both there now
<wgrant> So I wonder if someone set the flag on those templates between then and now
<wgrant> Well
<wgrant> Then and October
<dpm> I guess we'll have to give another try at universe packages in raring :)
<wgrant> banshee should be there in the first raring export
<wgrant> Since it has a template that's marked for langpacks
<czajkowski> 537
<czajkowski> Gwaihir: only another 387 to go, you mailed the user?
<Gwaihir> czajkowski, nope, not yet, BTW, do you have a link to the project they set up?
<czajkowski> https://translations.launchpad.net/bosnianuniversetranslation/trunk
<czajkowski> https://launchpad.net/~megaribi
<czajkowski> user
<czajkowski> all 874 pots reviewed and marked needs info
<czajkowski> dont think my hand will talk to me agian
<mgz> czajkowski: due to a pot surfeit?
<czajkowski> eager pots!
<czajkowski> mgz: https://answers.launchpad.net/launchpad/+question/218961  would his issue go away if the bzr builders got the update like the rT from Friday ?
<mgz> yup, that's the one that's fixed in bzr 2.5 but the builders are on 2.4.0
<mgz> so, the guy's last comment is accurate
<Gwaihir> czajkowski, user contacted
<czajkowski> Gwaihir: cheers
<plomme> hey guys. I've corrected a bug and would like to know where to go from here on
<czajkowski> plomme: a lp bug?
<plomme> I'm filling in the agreement form but will need a contact
<plomme> yes
<plomme> https://bugs.launchpad.net/launchpad/+bug/1097770
<_mup_> Bug #1097770: The series timeline does not distinguish between active and inactive milestones <javascript> <milestones> <projects> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1097770 >
<plomme> not so much corrected as offered a solution
<czajkowski> plomme: you'll best leave a comment on the bug
<czajkowski> wgrant: or StevenK will then see it and be able to give advice on it
<plomme> shall I just leave a comment owithout pushing the change?
<czajkowski> you can push the change
<plomme> ok
<czajkowski> it'll still be reviewed by them anyways
<plomme> do I leave the bug status as is? I just comment?
<czajkowski> yes for the time being please
<czajkowski> then wgrant and StevenK can review and comment
<plomme> faire enough. thanks a lot
<czajkowski> np
<wgrant> StevenK: Ah
<wgrant> You don't actually depend on the built egg
<wgrant> StevenK: http://pastebin.ubuntu.com/1532797/
<StevenK> Ah ha, success
#launchpad-dev 2013-01-15
<StevenK> wgrant: So I'm thinking of adding a accepter/rejecter exported property onto IPackageUpload that will back onto auditor, thoughts?
<wgrant> StevenK: Maybe
<StevenK> wgrant: Do you object
<StevenK> ?
<wgrant> StevenK: It will need thought
<wgrant> How will it perform, how will it behave if the backend service is missing, etc.
<StevenK> wgrant: It should perform pretty epically on staging with no data
<StevenK> wgrant: http://pastebin.ubuntu.com/1533266/
<StevenK> That change should at least be enough groundwork and allows us to properly test the auditor on staging when it's up and configured
<wgrant> By "epically" you mean failure?
<wgrant> Remember what you worked on last week? :)
<StevenK> Silence.
<StevenK> wgrant: http://pastebin.ubuntu.com/1533369/
<wgrant> StevenK: Did you copy the branch triggers?
<wgrant> They are more relevant than the bug ones
<StevenK> Yes
<StevenK> It's a copy of branch_denorm_access -- including it's comment from 16-6.
<StevenK> Which I've just fixed.
<wgrant> Right
<StevenK> wgrant: Only concern I have with the branch is owner.id isn't in access_grants
<wgrant> StevenK: Why would it be?
<StevenK> It was for branch
<wgrant> Erm
<wgrant> Really?
<wgrant> Are you sure?
<wgrant> Doesn't seem to be
<StevenK> steven@undermined:~/launchpad/lp-branches/devel% tail -n 4 lib/lp/code/tests/test_branch_access_policy_triggers.py | head -n 1
<StevenK>         self.assertAccess(branch, ap.id, [owner.id])
<wgrant> Oh
<wgrant> In a test :)
<wgrant> That's probably because the owner gets subscribed to the branch by default
<StevenK> RIght
<StevenK> wgrant: If you have no concerns, let me push this branch up
<wgrant> It sounds reasonable, particularly if it works
<StevenK> The tests I wrote pass, at least :-)
<StevenK> wgrant: Did the bug you filed about specification checks get closed?
<wgrant> Demoted
<wgrant> I think
<wgrant> Bug #1067616
<StevenK> I can't find it, if it's open
<_mup_> Bug #1067616: Blueprints could use a denormalized schema for improved performance <private-projects> <specifications> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1067616 >
<StevenK> Bah, forgot to update sampledata
<wgrant> StevenK: It should not be updated yet
<wgrant> It'll be updated by the garbo job that you'll land afterwards
<StevenK> I had to update sampledata for the er, branch branch
<wgrant> We weren't backfilling then, were we?
<wgrant> I thought we did the branch denorm before we started adding AAG and APAs.
<StevenK> Hm, possibly
<StevenK> I'll leave it, and if buildbot blows up, we can testfix
<wgrant> Anyway, the key point is that prod data is all going to be empty
<wgrant> So sampledata should be too
<StevenK> Sampledata isn't going to have the columns for existing specs
<wgrant> Sure, but that's no problem if the columns are nullable.
<StevenK> Right
<StevenK> stub: https://code.launchpad.net/~stevenk/launchpad/db-specification-new-access-policy/+merge/143230
<stub> Yeah, that's why I need the coffee.
<StevenK> Haha
<StevenK> Sorry
<czajkowski> Gwaihir: thanks for the mail, jtv have you read the reply from the large POT import yesterday
<jtv> czajkowski: don't see it, no.  Where should I look?
<czajkowski> have forwarded it on
<jtv> Thanks, I have it now
<jtv> czajkowski: I absolutely don't want to get in these people's way.  They want to contribute, and our worry is not to let that go to waste.  A very simple thing we could do is set up a new, dedicated translation group for them that has only a Bosnian translation team; ask their people to join that team; and set translation permissions to Restricted.
<jtv> That would stop e.g. the Turkish contributions that currently seem to be going to waste.
<jtv> If they would be willing to take on more, it would be possible to grow the project (and translation group) into a broader Universe translation project.
<czajkowski> nods
<czajkowski> Gwaihir: ^^^
<Gwaihir> jtv, czajkowski, yep, agree too
<czajkowski> does this mean he's going to reimport those 800+ pots again ?
<czajkowski> jtv: which TZ are you in btw?
<czajkowski> Gwaihir: so the guy has reimported 445 pots today
<cjwatson> wgrant: What do you think about my thoughts on LP implementation in https://wiki.ubuntu.com/PhasedUpdates?  This is the most compact way I can think of to implement the spec
<wgrant> cjwatson: That doesn't sound entirely unreasonable.
<czajkowski> wgrant: morning
<wgrant> Morning czajkowski
<cjwatson> wgrant: OK, good - I'll probably have a go at that soon then.  It'll probably generate a fair few publications, but there aren't so many things in -updates that it'll get prohibitive, and inventing another scheme for this seems unnecessarily complex
<cjwatson> And it'll reasonably automatically give us a view of what phase an update was set to in the past, which could be handy
<wgrant> cjwatson: Yeah, and it shouldn't be too many different levels, should it?
<wgrant> Plus we batch +publishinghistory now :)
<wgrant> And we already have a lot of publications.
<wgrant> So I think that should be fine.
<cjwatson> wgrant: Not sure how many.  I think they want the phase to be a percentage, but I assume that there's little chance of the curve being shallow enough for it to take on e.g. all integers from 0 to 100
<wgrant> cjwatson: Exactly, yeah
<cjwatson> So it more depends how frequently they want to update that, and I can probably negotiate that with the errors.u.c cabal :)
<StevenK> wgrant: r15461
<StevenK> I win
<wgrant> Aha
<StevenK> It was even rewritten for being too slow, and you don't remember that?
<wgrant> Oh right
#launchpad-dev 2013-01-16
<StevenK> steven@undermined:~/launchpad/lp-branches/drop-populate-specification-aag% bzr di | diffstat -s
<StevenK>  2 files changed, 1714 insertions(+), 1712 deletions(-)
<StevenK> wgrant: ^ :-(
<wgrant> StevenK: :(
<wgrant> StevenK: How?
<wgrant> Oh, sampledata
<wgrant> But that's quite a lot
<wgrant> postgres order change?
<StevenK> pg_dump jumped from 9.1.6 to 9.1.7
<wgrant> Right
<wgrant> So probably some reordering
<wgrant> Or an arch change
<wgrant> Or something like that :)
<StevenK> Lots of blank lines
<StevenK> http://pastebin.ubuntu.com/1536113/
<wgrant> Our sorting thing doesn't coalesce blank lines, but I'm not sure what's with that order change
<StevenK> I'm not even sure if we have any specs that are non-public in sampledata
<wgrant> Heh, probably not, no
<StevenK> Then it might not even matter
<StevenK> wgrant: Do you know which revno added the dependency stuff?
<StevenK> My pawing through bzr log hasn't turned it up
<wgrant> StevenK: r16333
<wgrant> from bzr log lib/lp/blueprints
<wgrant> StevenK: Looking
<StevenK> I think it needs a fix
<StevenK> I've been pondering for a few minutes
<wgrant> The AP nullness check is pointless
<StevenK> Oh?
<wgrant> Also, I'd probably do it with one query per batch
<wgrant> You're walking up by ID, and the function is idempotent
<wgrant> You might as well just run over all of them, rather than playing planner roulette.
<wgrant> (AP will be left null in almost all cases, because almost all of them are public)
<wgrant> There's also no need to call reconcileAccess here
<StevenK> But we check information_type
<wgrant> Right, but there's no point
<wgrant> Just iterate in batches from spec 1 to MAX(spec.id)
<wgrant> Calling specification_denorm_access on each batch
<wgrant> The spec reconcileAccess was never needed, because there was no legacy privacy to migrate
<StevenK> wgrant: http://pastebin.ubuntu.com/1536441/
<wgrant> StevenK: I'm not sure if that tuple expansion will work, but if it does then great
<StevenK> It does not
<StevenK> It works for id 1, and then it tries for set of more than one id
<StevenK> wgrant: http://pastebin.ubuntu.com/1536494/ even works
<wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/registry-view-accounts/+merge/143438
<StevenK> wgrant: r=me
<StevenK> wgrant: So, pastebin peering?
<wgrant> StevenK: If it works
<wgrant> You could also do execute(Select('specification_denorm_access(id)', tables=[Specification], where=[Specification.id.is_in(blah)]))
<wgrant> But it doesn't matter much
<StevenK> Do not understand these test failures
<StevenK> wgrant: The diff is updated
<StevenK> wgrant: But I think I should reset Specification.access_policy to NULL before the second runHourly due to triggers
<wgrant> StevenK: Indeed
<StevenK> And since Specification.access_policy doesn't exist, I'm sort of stuck how to reset it
<wgrant> StevenK: Create it?
<wgrant> This isn't a DB branch; you're allowed to make model changes
<StevenK> Sure, but I've managed to get this far with doing so :-)
<wgrant> SQL!
<StevenK> Hmm
<StevenK> The second runHourly is ignoring the spec since it's already seen it, too
<wgrant> Ah, yeah
<wgrant> You'll have to nuke the memcache record
<wgrant> Or create one public, one private, nuke access_policy across specification, then do a single runHourly
<StevenK> Bleh, it looks like .specifications is supposed to filter out inactive projects and it's broken, and I don't see how
<StevenK> wgrant: Diff updated
<wgrant> StevenK: r=me
<StevenK> I know, let's land it :-P
<wgrant> Bad StevenK
<StevenK> wgrant: Diff is at http://pastebin.ubuntu.com/1536676/ ; test failures at http://pastebin.ubuntu.com/1536679/
<StevenK> wgrant: You lose buildbot bingo
<wgrant> Indeed
 * StevenK facepalms at himself re bug 1100061
<_mup_> Bug #1100061: BranchSubscriptionAddOtherView rejects open teams even for public branches <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1100061 >
<wgrant> Ah, so it was you :)
 * StevenK taps his foot waiting for BMPJ
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/fix-branch-subscription-for-public/+merge/143441
<plomme> hey guys
<wgrant> plomme: Hi
<plomme> I'm new to submitting patches for lp I wante'd to know what the procedure was.
<wgrant> plomme: Is your change in bug #1097770 still desirable if we remove the private releases restriction?
<_mup_> Bug #1097770: The series timeline does not distinguish between active and inactive milestones <javascript> <milestones> <projects> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1097770 >
<wgrant> It was added in error, and was never intended to exist
<wgrant> The intent was to prevent release *files* from being added, but not the releases themselves
<plomme> no actually
<plomme> if proprietary projects can handle releases then the bug correction is mute
<wgrant> Right, that's what I thought.
<wgrant> StevenK or I can probably arrange that early next week.
<wgrant> And it's likely a better solution than the somewhat hacky inactive thing
<plomme> yeah
<plomme> I agree
<plomme> thanks a lot for looking into it! It's been somewhat of a thorn in our foot =)
<wgrant> No worries, sorry about the inconvenience. There was a bit of a miscommunication around the addition of that check.
 * StevenK peers at wgrant
<wgrant> I feel like I'm being watched.
<StevenK> wgrant: I linked you an MP :-)
<wgrant> I know, but then plomme appeared :)
<plomme> haha I can get distracting sometimes
<wgrant> Heh
<wgrant> Done now, anyway :)
<plomme> :)
<plomme> brb
<DMill> ok back.
<adeuring> good morning
<czajkowski> jtv: how wise/easy is it to remove a name from a LP  translations?
<jtv> czajkowski: a person's name?
<czajkowski> yup
<jtv> From translated strings?
<czajkowski> https://support.one.ubuntu.com/Ticket/Display.html?id=28061
<czajkowski> do you still have access to the RT ?
<jtv> czajkowski: seems like... trying to get to the ticket
<jtv> Checking out the links the user posted...
<jtv> czajkowski: that's a tough one.
<jtv> The remove-translations script may work for this.
<jtv> czajkowski: you'll have to remove the user's translations from those PO files to get this done.  Have a look at scripts/rosetta/remove-translations-by.py.
<jtv> IIRC we never quite got around to making it work properly with user names, so you may have to look up the user's id.
<StevenK> getUtility(IPersonSet).getByName() wants a word.
<czajkowski> jtv: never gone near those scripts before
<czajkowski> this should be *interesting*
<StevenK> czajkowski: WCPWG
<StevenK> WCPGW, even
<jml> bzr: ERROR: Server sent an unexpected error: ('error', 'xmlrpclib.Fault', "<Fault -1: 'Unexpected Zope exception: DisconnectionError: ERROR:  pgbouncer database is disabled\\n'>")
<jml> just fwiw
<czajkowski> StevenK: you say this...
<lifeless> jml: nice timing :)
<lifeless> jml: I'm just guessing, but I smell a FDT, and you hit the what 5 second window?
<czajkowski> lifeless: bingo
<jml> lifeless: that's my guess
<czajkowski> it finished at 10:01
<StevenK> Yeah
<wgrant> lifeless, jml: 3.2s, actually
<wgrant> That's quite some luck
<czajkowski> jtv: is there a wiki page on this somewhere in the vast quanties of wiki pages ?
<jtv> czajkowski: no, I don't think we have a wiki page on that particular script...
<cjwatson> wgrant: Could I have a patch number for adding a phase column to BPPH, please?
<gmb> bac, benji, gary_poster, frankban, teknico: Do any of you guys have time to review a proposed merge for lp2kanban? If not, no worries; I'm just hoping to get someone with context knowledge to take a glance.
<benji> gmb: I can.  Also, bac was working on it earlier today so he might be primed to do so as well.
<gary_poster> thanks
<gmb> benji, That would be wonderful, thank you: https://code.launchpad.net/~gmb/lp2kanban/cards2workitems/+merge/143543
 * benji looks.
<bac> benji: actually i didn't touch lp2kb directly but our tarmac configs
<benji> bac: ah; you're off the hook then ;)
<gmb> Oo, $0.33 AWS bill for December. Crikey, better sell some silverware...
<gary_poster> :-)
<benji> gmb: the branch looks good, I had a few thoughts about things you brought up in the MP description/comment and a couple small code suggestions
<gmb> benji, Thanks :)
<gmb> benji, How does the linking-to-multiple external sources work?
<benji> gmb: I have no idea. :)  The code is either in lp2kanban or in a custom script we use to interface between MPs linked to Reitveld and kanban.
<benji> if you look at the Juju GUI board you can right click on some of the cards in review or done-done and look at the "Link to" menu item to see multiple external links
<benji> gmb: ^^
<gmb> benji, Ah, I don't think it's in lp2kanban; that only supports one external link at a time... I shall have a poke around.
<gmb> THanks for the tip :)
<benji> cool, glad to help
<gmb> benji, Ah, cards don't support multiple external links - the ones on the juju gui board have an external_system_url and an external_card_id (the second automatically links to LP, of course).
<gmb> So the MP-nukes-blueprint problem still stands, but is solvable.
<gmb> (in another branch :)
<gmb> )
<benji> gmb: maybe it is a different mechanism, but there is some way of having unlimited (named) links on a card
<gmb> benji, Hmm, maybe I'm missing something.
 * gmb goes to find LKK API docs
<benji> gmb: hmm, I'm looking for it, but I can't find it; you may be right that there can be only one.  I could have sworn that you can have as many as you want.
<gmb> benji, Yeah, I was under the impression at first that you could (not including putting HTML in the description field).
<gmb> Hmm, found this feature request, but no answer: http://support.leankit.com/entries/20414932-multiple-external-links-on-a-card
<gmb> benji, ^^
<gmb> Anyway, EoD time.
<benji> Benji's Rules for Web Apps #231: If your application allows the user to enter one link related to an application entity, they should be able to enter multiple links related to an application entity.
<gmb> benji, Darn tootin'.
<benji> and since their suggestion app uses different credentials than their application propper, that suggestion will never get any votes from me because I can't log in and will not be forced to work that hard to suggest they make their app better
<lifeless> benji: but its web2.0
<benji> heh
<lifeless> benji: what could POSSIBLY be wrong with embedding another app in your apps process space with no controls ?
<benji> lifeless: we should start an industrial espionage agency; the fruit hang so low
<lifeless> benji: lol :)
<tumbleweed> rr *sounds
<tumbleweed> (excuse that, high latency--)
<wgrant> cjwatson: That seems like a pretty bad name
<cjwatson> wgrant: Suggestions?
<cjwatson> BPPH.phased_update_percentage, I suppose, to go with the control field name
<wgrant> Once the control field is finalised that would sound reasonable
<cjwatson> It is finalised
<cjwatson> Already implemented in update-manager
<wgrant> It's a lot clearer to someone who hasn't seen it before than "phase", and it isn't going to be referenced a huge amount
<wgrant> Aha
<wgrant> That was quick
<cjwatson> mvo overachieved and did it last cycle in advance of the server side
<wgrant> Ah
<cjwatson> It just wasn't documented until I looked it up earlier this week
<cjwatson> Or at least not consistently documented
<wgrant> cjwatson: 2209-36-1 is yours
<cjwatson> Thanks
 * cjwatson attempts to discern a rationale in the choice of second component
<cjwatson> Sorting by owner?
<wgrant> If there's a series of minor standalone patches we will tend to just reuse a minor number per owner, yeah
#launchpad-dev 2013-01-17
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/drop-populate-specification-aag/+merge/143627
<wgrant> StevenK: Self-review?
<StevenK> wgrant: Happy to do, wondering if you agree with deciding to not run it against sampledata.
<wgrant> StevenK: I forget -- will it un-null access_grants if it's public?
<wgrant> If it will, then it's not a no-op and should be run
<wgrant> But IIRC it leaves access_grants null in that case, so it will be a no-op
<StevenK> wgrant: http://pastebin.ubuntu.com/1540007/
<wgrant> Right, no-op
<wgrant> StevenK: Need any help with the model branch?
<StevenK> wgrant: Yes
<wgrant> Push branch, show test failures :)
<StevenK> wgrant: http://pastebin.ubuntu.com/1540093/ is the diff; test failures are http://pastebin.ubuntu.com/1536679/
<StevenK> wgrant: I can push the branch if you'd prefer that to a diff.
<wgrant> StevenK: Have you replicated the Product.active check that was in visible_specification_query?
<StevenK> Oh god
<StevenK> That's so not the place for it
<wgrant> Mmm, it was not unreasonable
<wgrant> Given that the spec search stuff isn't in a single place, like bugtasksearch is
<StevenK> Now I will have to revert the tables bit :-(
<StevenK> My query seems to fail
<StevenK> It won't return distribution specs :-(
<wgrant> StevenK: You failed to left join properly
<wgrant> You need to left join product and then say (product.active IS NULL or product.active)
<wgrant> StevenK: Did you see danilos' confirmation of my suspicion this morning?
<wgrant> The deps thing is indeed a regression from the privacy work, so your rewrite will fix it
<StevenK> I'm not sure if my rewrite is brutal enough for that yet
<StevenK> Anyway, looking at that next.
<StevenK> wgrant: And yes, I saw it because Curtis asked me about it.
<wgrant> Well
<wgrant> The rewrite involves reverting all the previous changes
<wgrant> So it will be :)
<StevenK> It does not
<wgrant> :(
<StevenK> There are fair amount of changes which are required, like passing users around
<wgrant> Ah, of course
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/use-specification-aag/+merge/143630
<wgrant> StevenK: r=me with a comment, but please check performance on DF first
<StevenK> wgrant: I think I need a LeftJoin in sharingjob, too
<wgrant> StevenK: Ah, yes, so you do
<StevenK> wgrant: So http://pastebin.ubuntu.com/1540213/
<wgrant> In fact sharingjob shouldn't be considering product.active at all
<StevenK> wgrant: I can change it to only append privacy_query[-1], but that's a bit horrid
<wgrant> Yeah, that's not a solution :)
<wgrant> I guess do the left join but otherwise leave it as it is
<StevenK> I can shift out the product stuff out of get_specification_privacy_filter and do it all callsites bar that one, but I like that even less
<StevenK> wgrant: DF has been patched, and has actually swapped back in enough to render pages.
<StevenK> wgrant: The main query of blueprints.dogfood.l.n/~ takes 240ms
<StevenK> The old query on prod is roughly the same, but prod is a lot faster than DF
<StevenK> For https://blueprints.dogfood.launchpad.net/nova , the query is 10ms
<wgrant> StevenK: Grab an explain analyze of the slow query
<StevenK> On DF, or prod?
<wgrant> DF
<wgrant> We know that prod's is terrible :)
<StevenK> wgrant: http://pastebin.ubuntu.com/1540253/
<StevenK> wgrant: And the query http://pastebin.ubuntu.com/1540256/
<wgrant> StevenK: Right, that looks fine.
<wgrant> It's terrible, but that's not the fault of your changes
<StevenK> Heh
<StevenK> Distribution is quick, but that doesn't involve the new columns at all, Product is like 10ms
<wgrant> Hm, it should involve the new columns
<StevenK> Distribution doesn't filter at all
<StevenK> By access_policy/grants, I mean
<StevenK> No private distributions, ergo no private blueprints for any distribution.
<wgrant> :/
<wgrant> It just assumes that they're all public
<wgrant> Doesn't even check
<StevenK> I can fix that, if you wish
<StevenK> Which would involve Storm-ifying it
<wgrant> Which is not a bad thing at all :)
<wgrant> Ideally we'd unify blueprint search like bug search is
<StevenK> Well, I can do that too ...
<wgrant> That's probably a bit more of an effort
<wgrant> But maybe
<StevenK> wgrant: http://pastebin.ubuntu.com/1540277/
<wgrant> StevenK: orlf
<wgrant> have you looked at the query log for Person:+specs?
<StevenK> Yeah, I glanced it
<wgrant> First it checks if there are any specs
<wgrant> Then it gets the specs
<wgrant> Then it counts the specs
<wgrant> Then it checks if there are any specs
<wgrant> StevenK: You could get ops to check the new query on prod
<StevenK> Haha
<wgrant> Given it's all populated there now
<StevenK> wgrant: The EXPLAIN or just run the query for timing?
<wgrant> explain analyze
<wgrant> but oh god have you tried the old query on DF?
<wgrant> Your eyes may burn
<StevenK> Show me?
<wgrant> 1.4s with tonnes of merge joins
<StevenK> Haha
<wgrant> http://paste.ubuntu.com/1540286/
<wgrant> The new one could be considered to be a marginal improvement
<StevenK> Haha
<StevenK> Did you spot your typo in the name field?
<wgrant> yes, before I submitted but I'm sick enough that I really couldn't be bothered fixing it
<StevenK> wgrant: So, specificationsearch, or leave it?
<wgrant> Depends on what sort of callsites we have
<StevenK> Bah, is_not_in doesn't exist
<wgrant> Not(...is_in)
<StevenK> Yeah
<StevenK> wgrant: http://pastebin.ubuntu.com/1540315/ works, do you want it in the branch?
<wgrant> StevenK: Can Specification.completeness_clause now be Stormified?
<wgrant> Not sure what other non-Storm callsites there would be
<wgrant> +                clauses.append(
<wgrant> +                    SQL('Specification.fti @@ ftq(%s)' % quote(constraint)))
<wgrant> fti_search is a helper for that, IIRC
<StevenK> wgrant: Yeah, I just switched to that
<StevenK> Distribution, DistroSeries, Product and ProductSeries want it
<wgrant> Are they all stormified?
<StevenK> Sorry, DistroSeries, ProductSeries and ProjectGroup
<StevenK> And all three are not
<wgrant> Hee hee
<wgrant> I'll leave the explanation of that to the reader
<StevenK> "When we get around to specificationsearch"
<StevenK> Which I'm getting dangerously close to just starting
<StevenK> Because this is just pathetic
<wgrant> Ah
<wgrant> Not actually exploitable, sadly
<wgrant> Since permissions for private specs don't seem to be precached
<wgrant> So you just get a 403
<wgrant> (but that also means there's probably a timeout bug on any page that lists lots of private specs)
<wgrant> StevenK: So, how do you feel about doing specificationsearch? :)
<wgrant> 'cause what we have today is sort of buggy as shit
<StevenK> wgrant: So, guess what I started about 5 minutes ago
<wgrant> StevenK: Bug #1100617 is relevant
<_mup_> Bug #1100617: Blueprint searches don't precache permission checks <blueprints> <fallout> <private-projects> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1100617 >
<czajkowski> morning
<stub1> link to online help on the recipe page seems to have disappeared
<gmb> benji, gary_poster, bac: So, in a fit of giddiness I tried to get around the only-one-external-link-in-a-card problem; if you have time to look at it, see https://code.launchpad.net/~gmb/lp2kanban/cards2workitems/+merge/143543 for the latest update. If not, I'll just land yesterday's work and make a new branch for the new stuff.
<benji> gmb: cool; I may have time later today to look at it
 * gary_poster on call
<gmb> benji, Okay; in that case I'll land yesterday's work (I'm hoping to be able to show this off to people in Austin) and make a fresh branch and merge proposal.
<benji> k
<gmb> benji, New merge proposal is here for your delectation when you get a chance: https://code.launchpad.net/~gmb/lp2kanban/dont-rely-on-external_system_url/+merge/143700
<benji> gmb: cool
<cjwatson> Hm - is it just me or is lib/lp/soyuz/templates/binarypackagepublishinghistory-listing-detailed.pt dead?  I can't actually see a way to get at it, short of URL-hacking to add +listing-details
<cjwatson> Maybe it is there somewhere and I'm just too stupid to find it.
<czajkowski> I'd hardly think you could you of all people cjwatson are stupid !
<deryck> cjwatson, my approach to that if I can't find any real reference to it is to remove the zcml that hooks up the template, run tests, and see what breaks. you're probably right.
<lifeless> czajkowski: LP sets a pretty high bar on smarts-needed-to-tell-whats -used :)
<wgrant> cjwatson: I think DASBPR:+index used to use it, but hasn't since 3.0
<wgrant> It's unused now, and I think the only callsite of its source counterpart is DSSPR:+index
<wgrant> Everywhere else uses +listing-archive-extra
<wgrant> IIRC
<cjwatson> Argh, you know unused code is old when bzr log goes back to a Mark commit
<cjwatson> (Not the same thing)
<wgrant> Heh, yes.
<wgrant> cjwatson: What was it?
<cjwatson> lib/lp/soyuz/browser/publishedpackage.py - removing it as part of my current branch
 * cjwatson wonders if database/schema/launchpad.html still has a useful purpose
<cjwatson> Aside from indicating that publishedpackage was once "a very large view"
<cjwatson> wgrant: How do I actually get to a BinaryPublishingRecordView in the webapp?  I can't come up with a suitable URL
<wgrant> Huh
<wgrant> How has publishedpackage survived...
<wgrant> I deleted some related bits years ago
<wgrant> But apparently missed the browser stuff
<wgrant> I guess I didn't think it existed :)
<wgrant> Ah
<wgrant> And it doesn't actually mention 'publishedpackage' anywhere in it, so a grep would have failed
<wgrant> launchpad.html can probably die
<cjwatson> $ wc -l database/schema/launchpad.html
<cjwatson> 30685 database/schema/launchpad.html
<wgrant> Indeed
 * cjwatson removes :)
<wgrant> cjwatson: Also, https://launchpad.net/~wgrant/+archive/ppa/+binarypub/25603241/+record-details
<cjwatson> Ah.  Are there no more polished paths that use stuff from there?
<cjwatson> This is in aid of trying to figure out which bits of the webapp I need to update to show phased_update_percentage
<wgrant> cjwatson: That's the only URL, but ZCML could reference those views.
#launchpad-dev 2013-01-18
<cjwatson> Seriously?  celeryd log rotation interrupts any branches being scanned at the time?
<cjwatson> Oh, no, there it goes
<wgrant> It wouldn't surprise me.
<cjwatson> Just exceptionally confusing log output
<cjwatson> (It starts up another poolworker of the same name, I think)
<cjwatson> Aha, https://launchpad.net/ubuntu/raring/i386/man-db et al is what I'm looking for
<cjwatson> I always find that tremendously difficult to locate
<wgrant> cjwatson: Yeah, I've never been sure how to get there without URL hacking
<wgrant> I believe there is a way
<wgrant> But like https://launchpad.net/ubuntu/raring/+package/man-db it is rather difficult to find
<cjwatson> That's what I always go for first and it's much less useful (to me anyway)
<cjwatson> https://launchpad.net/ubuntu/raring/i386 has a search box that times out a lot
<cjwatson> Maybe it would return something useful if it ever succeeded
<cjwatson> Hm, no, takes me to the DASBPR
<cjwatson> The package relationship links on DASBPR:+index go to DASBP:+index, though
<cjwatson> So that's one way, albeit convoluted
<wgrant> Yeah
<wgrant> By DASBP you mean DSBP?
<wgrant> Ah, no
<wgrant> Nevermind
<cjwatson> I don't think so
<wgrant> StevenK: How's the rewrite?
<StevenK> Painful
<wgrant> Think of all the code you can delete
<StevenK> Not sure I'm at all happy with it
<StevenK> % bzr di | diffstat -s
<StevenK>  10 files changed, 266 insertions(+), 423 deletions(-)
<wgrant> And that's just the start :)
<cody-somerville> StevenK: whatcha doin'?
 * wgrant breaks the build farm
<StevenK> cody-somerville: Rewriting specification search
<StevenK> As well as questioning my sanity as of 4:30pm yesterday.
<wgrant> What did you do?
<StevenK> 4:30pm is approximately when I talked myself into starting specificationsearch.
<wgrant> Heh
<StevenK> wgrant: http://pastebin.ubuntu.com/1543444/
<wgrant> :)
<StevenK> Oh, so you don't wildly object?
<StevenK> % subunit-stats < lp.log | grep Failed
<StevenK> Failed tests:     93
<StevenK> Hmmm
<wgrant> It's a good start
<wgrant> Even better once the tests pass!
<wgrant> Removing this duplication can only be a good thing
<StevenK> I've not done {Distro,Product}Series either
<wgrant> StevenK: What about ProjectGroup?
<wgrant> I didn't really look at the deletion bits of the diff hard enough to notice
<StevenK> ProjectGroup has been subsumed
<wgrant> Ah
<StevenK> % testr failing --list | wc -l
<StevenK> 46
<wgrant> What sort of failurs?
<StevenK> Most of them have been thinko/things I missed while shifting tons of code around
<wgrant> Right :)
<StevenK> % testr failing --list | wc -l
<StevenK> 26
<StevenK> Progress!
<StevenK> % testr failing --list | wc -l
<StevenK> 11
 * StevenK sighs at the specification code using 'filter' everywhere, which neatly masks an internal function
<wgrant> Huh
<wgrant> I didn't break buildbot
<wgrant> Incredible
<Bert_2> Hi, I sort of forgot how I can change the number of e.g. blueprints there are displayed on a project's blueprintspage per page, anyone know this by hard cause I couldn't find it using grep
<Bert_2> s/hard/heart/
<Bert_2> woops
<cjwatson> ?batch=50
<cjwatson> (etc.)  but if you raise it too high it will probably time out
<cjwatson> ah, or tell you that the maximum is 300
<Bert_2> cjwatson: and where do I set that?
<cjwatson> at the end of the URL
<Bert_2> cjwatson: but that's not a permanent solution now is it
<Bert_2> I was able to raise it from 10 to 20 before
<Bert_2> but I don't remember how the hell I did that xD
<cjwatson> wait, is this your own LP instance?
<Bert_2> cjwatson: yeah
<cjwatson> it would be helpful to say that rather than making us guess :P
<Bert_2> yeah sorry, I guessed you'd expect that based on the fact this is the dev chanel, sorry man
<cjwatson> it's default_batch_size in launchpad-lazr.conf
<Bert_2> cjwatson: awesome, thx :D
<Bert_2> so silly I couldn't remember
<Bert_2> thought it was in some template, so I went looking there
#launchpad-dev 2015-01-13
<mwhudson> how can i "configure a project's bug tracker" to point at github?
<wgrant> mwhudson: You can't at the moment. We should really add at least linking support.
<wgrant> Though syncing should be doable as GitHub has a sensible API nowadays.
<mwhudson> thanks
<blr> wgrant: this makes me sad https://github.com/Pylons/pyramid_xmlrpc/pull/3
<blr> wgrant: actually, I may be looking at the wrong module
<blr> yep! carry on :P
<cjwatson> wgrant: Any reason I shouldn't release at least lazr.sshserver today?
<wgrant> cjwatson: No objections from me. Looks great, thanks.
<cjwatson> wgrant: lazr.sshserver released and in lp-source-dependencies; https://code.launchpad.net/~cjwatson/launchpad/split-lazr.sshserver/+merge/245647 ready for review
<wgrant> cjwatson: Yay
<cjwatson> Ta
<wgrant> lifeless: Could you please add me as an owner on PyPI for: lazr.batchnavigator lazr.config lazr.delegates lazr.enum lazr.exportedfolder lazr.lifecycle lazr.restful lazr.uri oops oops_amqp oops_datedir2amqp oops_timeline oops_twisted oops_wsgi wadllib launchpadlib
<cjwatson> OK, time to release txpkgupload as well I think.
<lifeless> wgrant: I don't have exportedfolder
<lifeless> wgrant: whats your pypi user id?
<lifeless> wgrant: done for all the ones I had
<wgrant> lifeless: Thanks.
#launchpad-dev 2015-01-14
<thomi> morning
#launchpad-dev 2015-01-16
<rpadovani> launchpad on duckduckgo :D
<rpadovani> https://duckduckgo.com/?q=lp+%231&ia=launchpad
<cjwatson> rpadovani: says "More at Launchpad.com" which is a domainsquatter and not us.
<cjwatson> but good to see explicit support
<rpadovani> cjwatson, ops, I reported it in the MR, they didn't fix it :/ I report it to the developer
<rpadovani> (again)
<cjwatson> The link goes to the right place, it's just the text
<cjwatson> wgrant: Do you happen to remember why accessartifact_maintain_denorm_to_artifacts_trig is redefined in database/schema/patch-2209-28-6.sql, apparently identically to its definition in database/schema/patch-2209-16-6.sql?  Is it because the PL/pgSQL function needs to be recompiled to refer to the new definition of accessartifact_denorm_to_artifacts?
<cjwatson> (I'm guessing so, but wanted to check)
<rpadovani> fixed launchpad.com on ddg
<rpadovani> https://github.com/duckduckgo/zeroclickinfo-spice/pull/1423/files
<cjwatson> thanks!
<wgrant> cjwatson: Seems pretty pointless to me.
<cjwatson> wgrant: OK, so PL/pgSQL PERFORM looks up the other function by name rather than having a precompiled handle to it or something?
<wgrant> Oh right, I remember the history here.
<wgrant> I can't see why the function was redefined, though. Might be worth deleting it from the patch and running the spec privacy tests.
<wgrant> https://bugs.launchpad.net/launchpad/+bug/1067616 ftr
<mup> Bug #1067616: Blueprints could use a denormalized schema for improved performance <private-projects> <qa-ok> <regression> <specifications> <tech-debt> <Launchpad itself:Fix Released by stevenk> <https://launchpad.net/bugs/1067616>
<wgrant> I don't think I reviewed any of this series because reasons.
<wgrant> Oh, I did.
<wgrant> Just not the DB patch.
<cjwatson> Yeah, I'd found that bug.
<cjwatson> OK, will experiment if you don't know off the top of your head.
<wgrant> cjwatson: lp.blueprints tests still pass with that removed, as expected.
<cjwatson> Oh good.  Thanks.
<wgrant> I would have been rather scared if they didn't.
#launchpad-dev 2015-01-17
<blr> wgrant: might give circus a go at any rate, easy enough to move it to upstart if it isn't working for us
<blr> although realistically we have a good amount of time with upstart
<stub> cjwatson: yes, compiled form of functions and views references objects by object id and will often need to be recreated like this. Its a wart.
<stub> cjwatson: You get to ignore it until PG throws an error in your face, at which point you copy pasta.
<wgrant> stub: CREATE OR REPLACE FUNCTION preserves the OID.
<wgrant> Also, I'm pretty sure the plan only survives for the life of the connection.
<wgrant> Otherwise a function referencing a temp table would never work.
<wgrant> Hm.
<wgrant> "Once PL/pgSQL has made an execution plan for a particular command in a function, it will reuse that plan for the life of the database connection."
<wgrant> "Note: In PostgreSQL 8.3 and later, saved plans will be replaced whenever any schema changes have occurred to any tables they reference. This eliminates one of the major disadvantages of saved plans. However, there is no such mechanism for function references, and thus the above example involving a reference to a deleted function is still valid."
<stub> Its executing the compiled form of the function though, so things like NEW can fail because the definition of the table has changed, and it is trying to stuff a square shaped row in a round struct.
<stub> But I always forget and forget the rules, and just deal when PG spits an error at me.
#launchpad-dev 2015-01-18
<cjwatson> wgrant,blr: Mon evening UK / Tue morning APAC possibly works a bit better than Tue evening UK / Wed morning APAC for our meeting this week; we have a guest round on Tue evening
<cjwatson> (works better for me, that is, I think last week you were both easy)
<blr> cjwatson: have my 1-1 with ev between 8-8:30 tuesday NZST but free after that
<cjwatson> OK
<wgrant> cjwatson, blr: Works for me. Moved.
#launchpad-dev 2016-01-21
<AlecTaylor> hi
<AlecTaylor> Okay, got a commit waiting and ready
 * AlecTaylor is following https://dev.launchpad.net/PatchSubmission
<AlecTaylor> bzr: ERROR: extra argument to command push:
<AlecTaylor> :\
#launchpad-dev 2018-01-17
<tsimonq2> Hm, does Launchpad have the ability to do something similar to the Debian bug tracker where on a Git commit with an LP bug number it will leave a comment or automatically link the branch to the bug?
<tsimonq2> If not, can I add it to my growing list of Things To Implement in Launchpad after finals are over with? :)
<cjwatson> tsimonq2: Only if there's also a merge proposal
<cjwatson> tsimonq2: https://help.launchpad.net/Code/Git#Linking_to_bugs
<cjwatson> tsimonq2: Doing it on just any commit is ... extremely challenging.  The Debian implementation is external and knows which branches are significant
<cjwatson> tsimonq2: (and really there isn't just one implementation, it's ad-hoc hooks and such)
<tsimonq2> cjwatson: What might make it extremely challenging? On the Launchpad side, couldn't a default hook be implemented to grep for the regex and then deal with the bug using the same sort of interface as implemented in merge propossals? Maybe I'm misunderstanding it here :)
<cjwatson> tsimonq2: A commit can be in the ancestry of an arbitrarily large number of refs, and we also don't want to have to scan the entire history.
<cjwatson> tsimonq2: Consider the case where somebody decides to push Linux to a new repository.
<tsimonq2> cjwatson: Hm, ok.
<tsimonq2> Oh, right.
<cjwatson> tsimonq2: We compromised on merge proposals signalling intent and being cheap.
<tsimonq2> cjwatson: I see, alright.
<cjwatson> tsimonq2: Anything more would have to have some kind of arrangement where you nominate a specific branch to be watched for a specific bug target (which is really what the Debian implementation is like)
<cjwatson> (Well, maybe or maybe not for a specific bug target, but definitely branch-limited.)
<tsimonq2> Right, I get what you mean.
<tsimonq2> I might just either use the Debian tooling or write my own for select Lubuntu repositories to do that then, and only *after* the initial upload would I set up the hook.
<cjwatson> (Totally doable to do the same external thing that Debian is doing using webhooks, of course ...)
<tsimonq2> Right :)
<tsimonq2> Thanks cjwatson, gotta go study for my last round of finals ;)
<cjwatson> Good luck
<tsimonq2> Thanks
#launchpad-dev 2020-01-16
<jelmer> cjwatson: does launchpad currently rely on the Python 2 version of Breezy, or are there any plans to rely on the Python 2 version?
<cjwatson> jelmer: codehosting (though not codeimport) in master currently relies on the Python 2 version of breezy
<cjwatson> jelmer: If possible it would be helpful if the issues blocking codeimport were fixed before breezy dropped Python 2 support, so that we have an overlap period; though another possibility is to split out codeimport
<cjwatson> jelmer: I'm expecting to deploy the codehosting/breezy work to production tomorrow
<jelmer> cjwatson: ack, thanks
<jelmer> cjwatson: FWIW we're not in a hurry, just trying to figure out what constraints we have
<cjwatson> jelmer: We've made some pretty substantial progress on dependencies in the last few months, but there's still a lot of code to port and a few complicated remaining dependencies (notably lazr.authentication/lazr.restful is going to need some fiddling)
<sil2100> Hello! I have a small MP I'd like someone from the LP-team to take a look at, since I'm really bad at naming stuff - this is all needed for some stuff we'd like to have for 18.04.4 images:
<sil2100> https://code.launchpad.net/~sil2100/launchpad-buildd/pass_build_id/+merge/377635
<cjwatson> sil2100: Yep, saw it, in the middle of a sprint at the moment but it's on my list
<cjwatson> I agree it's likely to need to be something other than build_id, but will have a think
<cjwatson> sil2100: When is 18.04.4?
<cjwatson> Still 2020-02-06 as scheduled?
<sil2100> cjwatson: yes ;)
<sil2100> cjwatson: thank you!
<sil2100> cjwatson: I renamed it to image_build_id for now so that it doesn't conflict with the in-code build_id
<sil2100> It'll usually be a timestamp, but I'd also like it to be an arbitrary identifier that someone can push to a build if needed
<sil2100> On cdimage it has many names ;p
<cjwatson> sil2100: Isn't that already --datestamp?
<cjwatson> Passed as NOW?
<sil2100> cjwatson: I don't know, I mean, at least it's not passed via cdimage for sure - I don't know what for --datestamp is used, but the build_id that I want to pass is the cdimage build/publish timestamp identifier, and that's not always a strict timestamp
<sil2100> Since it can be DATE.1, DATE.2 depending on how many builds a day there were
<sil2100> I see that datestamp is pushed as NOW into the environment, so I could be a bit worried that this not being an actual timestamp might cause trouble
<sil2100> But yeah, I actually never used NOW
 * sil2100 looks at livecd-rootfs code
<sil2100> I guess it's only used there to do `echo "BUILDSTAMP=\"$NOW\"" >> config/binary`, so I guess in theory I could use that? I'm just worried as the variable/parameter names can confuse people
<sil2100> And BUILDSTAMP is then used for ubuntu-cpc builds to populate /etc/cloud/build.info
<sil2100> hm, good to know that, maybe I should poke the CPC guys to know if I can hijack this
<cjwatson> DATE.1, DATE.2 is exactly what we already use datestamp for
<cjwatson> I think
<cjwatson>         args["datestamp"] = build.version
<cjwatson> The naming is a mess, but it exists and we shouldn't add another thing that does the same thing
<cjwatson> It's true that cdimage doesn't pass it; it's the optional version argument to livefs.requestBuild
<cjwatson> When I wrote this I never intended it to be required to be an actual timestamp
<sil2100> cjwatson: agreed! Yeah, I guess I missed it since I looked at cdimage first
<cjwatson> Name notwithstanding
<sil2100> Excellent
<cjwatson> (I think some of the naming was live-build's fault, but it's been a while)
<sil2100> Thanks for pointing that out!
<sil2100> I shall use it in that case ;)
<sil2100> Since it's actually perfect, since it means there's less stuff that needs to land
<sil2100> In the best case I'll just have to tweak cdimage to pass it, and the rest should just work - since livecd-rootfs already populates /etc/cloud/build.info with it, so that's what we can use!
#launchpad-dev 2020-01-17
<cjwatson> https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/377767
<cjwatson> (Remove PPA root in PackageUploadTestCase.tearDown)
<tomwardill> I wrote some bash. https://code.launchpad.net/~twom/launchpad/+git/launchpad/+merge/377768
