#launchpad-dev 2009-12-07
 * jml is back.
<jml> my headset snapped :(
<jml> I wonder if there's an equally compatible headset that travels better.
<jml> poolie, hi
<jml> spm, hi :)
<spm> jml: hey hey!
<spm> jml: you're (relatively) in town?
<jml> spm, indeed. I'm in Tassie.
<spm> ahh. for christmas, of course
<jml> spm, christmas and a wedding.
<spm> I was going to say, you'll miss a white christmas; and then I remembered what the weather is like in tas. ;-)
<jml> spm, haha
<jml> spm, it's not precisely summer weather right now, but it's a damn sight better than London weather.
<spm> gee the bar's low there! ;-)
<jml> :D
 * spm recalls a coworker back in the 90's describing driving from Hobart to Lancestion (I think it was... whatever). in winter. drivers door open; him looking straight down at the double lines to know if he was still on the road or not. total snow whiteout.
<spm> the trip in question would have been in the 60's or 70's.
<jml> :)
<jml> spm, every trip through the midlands is a trip through the 70s, so to speak.
<spm> dear $deity. it must have been like the 1800's back then then!!!! ZOMG!
<jml> spm, the 1800s in Tasmania were pretty scary.
<spm> canberra wasn't much chop either ;-)
<jml> heh
<jml> probably had fewer cannibals.
<spm> and jml scores the conversation point with that *perfect* one liner
<jml> spm, :)
<maxb> wgrant: btw, I had an added postinst script in my python-defaults for karmic. I think we still want it in lucid
<poolie> hello jml, spm
<spm> hey poolie
<mwhudson> jml: so what is bug q&a?
<jml> mwhudson, questions on the bug page designed to guide the bug toward completeness.
<mwhudson> jml: ah ok
<jml> mwhudson, when would be a good time for that call?
<mwhudson> jml: i guess in about 2 minutes would be good for me
<jml> cool.
<wgrant> jml: It is far too summery, TYVM.
<wgrant> spm: Since it's post-release, are you going to have time at some point to update the buildbot AMIs?
<mwhudson> jml: sorry about that, go again?
<jml> mwhudson, sure
<spm> wgrant: if and when they need new lp-deps etc, yes. we petard'ed nicely on the last updated as we rebuilt with lp-deps being behind; which broke (or would have) edge
<wgrant> spm: This particular update isn't necessary for appservers at all -- does launchpad-dependencies still need a versioned dep?
<wgrant> Only a few of the production machines are likely to have this, I suspect.
<thumper> mwhudson: you free to talk to?
<mwhudson> thumper: was on with jml, free now
<spm> wgrant: sorry - wasn't ignoring you; just caught up on other stuff. I suspect I'm not understanding the Q; what needs to be updated - exactly - and why? if it's not in lp-deps; and thus doesn't need to go on (all) LP servers; it shouldn't be on the buildbots either. They're the smoketest as it were.
<wgrant> spm: It's dpkg-dev. It's needed by the test suite, cocoplum, germanium, iron, and the buildds.
<wgrant> spm: Nothing will break if those machines don't have it -- they will just reject the new formats.
<wgrant> But the test suite verifies that it works.
<spm> then it needs being in lp-devs, and rolled out to all machines. else we set ourselves a timebomb.
<wgrant> I don't really see how it's a timebomb if it just pleasantly rejects new source formats, but OK.
<spm> in that down the track some porr sysadmin is going to be trying to debug why the "was working" servers are now pleasantly rejecting new source formats. Not good. :-)
<wgrant> Perhaps.
<wgrant> Do all the servers to which you deploy use the ~launchpad PPA?
<spm> if we need it to do X; it's in the deps. else it becomes an undocument timebomb.
<spm> we have an internal version of; but all lp servers need lp-deps; yes.
<spm> in fact we blew up on the release on Fri with one server that was missing same. so...
<wgrant> I mean, where do I need to get the new dpkg in order to not break the world when the versioned dep is added to lp-deps?
<thumper> mwhudson: bzr merge -i :next
 * jml -> lunch
<spm> wgrant: ahh I see what you're you're getting at. aiui, the versions in the PPA's are essentially what we use on the servers. I believe lamont does some magic to make it work for us; but I've not yet had the pleasure of exploring that. I expect that to change RSN.
<wgrant> spm: So the world will end (and edge updates will break) if launchpad-dependencies grows a new versioned dpkg dependency now, won't it?
<wgrant> ISTM that the lamont magic should probably be done first.
<spm> I guess so. but if it doesn't pass buildbot - which should fail it first - it shouldn't break edge or staging; if it does, then that's a fail somewhere that needs fixing.
<wgrant> So, do I poke lamont about this, or is there some predefined process that would best be performed by somebody real?
<spm> wgrant: at risk of getting smacked by him for throwing him in the hotseat; lamont will have a far better idea of process for these than I do. :-(
<wgrant> And I suppose he EODed a couple of hours ago.
<mwhudson> wgrant: i don't think he works sundays
<wgrant> mwhudson: Um, that too.
<mwhudson> hm, branch page css is very odd on launchpad.dev
<mwhudson> i guess a prophylactic 'make clean build' is worth a go
 * jml back
<thumper> arse
<thumper> I've hit an unexpected failure
<thumper> but I'm cooking dinner now
<thumper> I'll be back later to fix it
<mwhudson> hm, dinner, that's an interesting idea
<jml> pshaw.
 * mwhudson biab too
<adeuring> good moring
<mrevell> Morning
<Daviey> and what a miserable one it is mrevell :)
<mrevell> Daviey, Very dark and damp
<maxb> sinzui: Rude? Why is changing a bug title to be more accurate rude!?
<maxb> [bug 400643]
<danilos> henninge, btw, do you think "Low Saxon" is a decent enough name for Low German so it's not easily confused by German in LP? (i.e. see bug 433645)
<mup> Bug #433645: The difference between "German" and "German, Low" is not clear enough. <Launchpad Translations:Fix Released by danilo> <https://launchpad.net/bugs/433645>
<henninge> danilos: I have read that term before and always wondered what the language had to do with Saxony.
<henninge> ;)
<danilos> henninge, I only trusted Wikipedia, if you think 'Low German' is good enough, let's just go with that
<henninge> danilos: Well, I think to those that know the language, "Low German" is much more easily recognisible.
<danilos> henninge, as for what it has to do with Saxony, it's just an area that is "low on Saxoners" :)
<henninge> lol
<henninge> Yes, definitely.
<henninge> danilos: I just read the corresponding German wikipedia entry and it does not mention "NiedersÃ¤chsisch" as a name for the language.
<danilos> henninge, I guess that comes from the Dutch "Nedersaksisch"
<henninge> danilos: I'd prefer Low German. We could add the native name "PlattdÃ¼Ã¼tsch" to make it clear to speakers.
<danilos> henninge, if we start adding native names, we should do it for all languages, and make them preferred in the UI, thus making for very fun listings :)
<henninge> danilos: yes, I read that but as we also have a German state called "Niedersachsen", that term is not used for the language with is used in a much wider area.
<henninge> danilos: hang on ...
<danilos> henninge, I've changed it to Low German, I think that's good enough for now
<henninge> cool
<danilos> henninge, come on, you've got a state for everything!
<deryck> Morning, all.
<henninge> Morning, one.
<henninge> ;)
<deryck> heh.
<wgrant> Hmm.
<wgrant> Some BRANCH.TODO changes just landed on devel.
<wgrant> I didn't think that was meant to be possible.
<salgado> possibly my fault
 * salgado checks
<salgado> it is possible because PQM doesn't run the test suite anymore.  it will fail later on buildbot
<wgrant> Ah.
<BjornT_> danilos: did you try applying that patch mars gave you, to fix the failing windmill test?
<BjornT_> salgado: could you (or someone else that knows a bit about packaging, maxb maybe?) review this patch to meta-lp-deps? https://code.edge.launchpad.net/~bjornt/meta-lp-deps/windmill-headless/+merge/15749
<BjornT_> it only adds a few dependencies, but i've never done it before, so i'd like someone to double check that everything is ok
<maxb> I'll look at it once LP gets round to making the diff :-)
<BjornT_> maxb: thanks :)
<danilos> BjornT_: I am going to do that today, it's up on my long list of things to do today :)
<BjornT_> danilos: cool :)
<maxb> BjornT_: Hardy, of course, only has Firefox 2... is that adequate?
<BjornT_> maxb: yes, that's fine. i'm quite sure that's what the jscheck buildbot slave is using when running the windmill tests.
<maxb> In that case, amend the changelog to mention which of the three packages you are adding the dependencies to, and r=me
<BjornT_> maxb: cool, i'll do that. thanks!
<BjornT_> maxb: will the dput command in https://dev.launchpad.net/LaunchpadPpa work without having a .dput.cf file?
<maxb> Yes, the needed config is included in /etc/dput.cf since ... um, intrepid maybe
<BjornT_> maxb: cool. so https://help.launchpad.net/Packaging/PPA/Uploading should probably be updated then
<BjornT_> bigjools, mrevell: ^^^
 * mrevell looks
<mrevell> so maxb, should I update the help doc to recommend using /etc/dput.cf instead of ~/.dput.cf?
<maxb> /etc/dput.cf is shipped in the dput package
<maxb> On any recent Ubuntu, people should be advised that they don't need to do anything with config files at all
<maxb> Just dput ppa:theiruserid/theirppaname
<mrevell> cool, thanks maxb
<flacoste> morning launchpadders
<bigjools> morning flacoste
<sinzui> Chex: ping
* mrevell changed the topic of #launchpad-dev to: This is Launchpad Development Channel | Week 1 of 3.1.12 | PQM is open for srs bsns | I am Zero OOPS and So Can You! http://is.gd/4fkLl |   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 | This channel is
<sinzui> mthaddon: ping
<Chex> sinzui: hello
<sinzui> Chex : can you choose the Delete action for this series and confirm the page says you cannot because it has translations: https://staging.launchpad.net/do/trunk
<mthaddon> sinzui: hi
<sinzui> mthaddon: unping,
 * mthaddon wanders 
<Chex> sinzui: This series cannot be deleted because it has translations. :: looks correct, then.
<sinzui> Chex: thanks. There is now one less way to shoot-yourself-in-the-foot
<gmb> FAIL: http://people.canonical.com/~gbinns/timeout-fail.png
<gmb> So, anyone know of a page that's guaranteed to timeout on LP? If not, does anyone know of a good way to cause a timeout in lp.dev?
<Chex> sinzui: I'm all in favour of that! Thanks..
<gmb> Hurrah for bug #1 on staging!
<mup> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Confirmed for compscibuntu-bugs> <easypeasy Overview:In Progress by ramvi> <Ichthux:Confirmed for raphink> <JAK LINUX:Confirmed> <OpenOffice:Confirmed for lh-maviya> <Tabuntu:Confirmed for tinarussell> <Tivion:Confirmed for shakaran> <Ubuntu:In Progress by sabdfl> <ubuntu-express (Ubuntu):Invalid by jahyire2006> <Ubuntu Jaunty:In
<sinzui> Chex: ping
<Chex> sinzui: hello
<sinzui> Chex: Can you change a word in this team's description and choose save? I am test that that the page does not oops because it has a zillion members: https://staging.launchpad.net/~locoteams/+edit
<sinzui> EdwinGrubbs: Can you test the IE7-8 activator bug? Do we need help from matsubara-lunch or Ursinha?
<Chex> sinzui: no such luck: Sorry, something just went wrong in Launchpad.
<sinzui> Chex: may I see the oops report? I want to see if it related to
<sinzui>     ShortListTooBigError: Hard limit of 5000 exceeded.
<EdwinGrubbs> sinzui: it can't be tested on staging or edge, since I only fixed it lazr-js, and launchpad disables all YUI with its on if-statement that checks whether the browser is IE.
<Chex> sinzui: sure: here is the pastebin of it: https://pastebin.canonical.com/25438/
<sinzui> Chex: excellent, we have fixed enough of the problem to discover another bug
<sinzui> EdwinGrubbs: Do you think we should move the activator item to the?? section on https://dev.launchpad.net/RegistryTeam/RegistryTestPlans/3.1.12
<EdwinGrubbs> sinzui: sure, I'll do that.
<bac> Chex: can you redo the same test you did for sinzui on edge:  https://edge.launchpad.net/~locoteams/+edit  - just making an innocuous change to the team name.
<bac> displayname, i should say
<sinzui> bac: the change did work on staging. They descriptions are difference
<bac> sinzui: yeah, but i was curious if the timeout happens on edge
<sinzui> bac: the staging issue as the members portlet
<bac> sinzui: ok
<bac> sinzui: on an unrelated note, did you know https://edge.launchpad.net/ubuntu/karmic/+packaging is always timing out
<sinzui> bac: yes I did, where were you during our standup what I talked abut the branch I have in review that adds a batch navigator and does not render links to non-distroseries packages?
<bac> sinzui: mars
<sinzui> bac: abentley approved it. I am sending to ec2 now
<sinzui> I expect that page to be much smaller tomorrow
<bac> good
<mrevell> night all
<sinzui> bac: EdwinGrubbs: release planning in 2 minutes. https://blueprints.edge.launchpad.net/launchpad-registry/+spec/ubuntu-link-to-upstream
<bac> oops
<sinzui> bac: EdwinGrubbs:
<sinzui> https://edge.launchpad.net/bzr/+packages
<sinzui> bac: EdwinGrubbs: https://edge.launchpad.net/ubuntu/lucid/+source/bzr
<sinzui> bac: EdwinGrubbs: https://edge.launchpad.net/ubuntu/lucid/+source/gimp-help
<sinzui> https://edge.launchpad.net/ubuntu/lucid/+source/tomboy
<sinzui> bac: EdwinGrubbs: https://edge.launchpad.net/ubuntu/+upstreamreport
<bac> EdwinGrubbs: this one: https://edge.launchpad.net/ubuntu/lucid/+source/gimp-help/+edit-packaging
<thumper> morning
<thumper> anyone following #launchpad that knows about translations?
<thumper> rockstar, abentley: I forgot to mention in the standup, we have a new location for code related exception classes: lp.code.errors
<thumper> currently only in db-devel
<thumper> but this is a short cycle
 * thumper feels like he is talking to himself today
<rockstar> thumper, great, thanks.
<adiroiban> how is new testdate added to the testrunner database? what is the process?
<wgrant> adiroiban: 1) Realise that you don't want to do that, and you should generate the data yourself at test-time.
<wgrant> (sample data for tests is deprecated)
<adiroiban> wgrant: :) ok
<adiroiban> thanks
<adiroiban> and there are no exception from this policy ?
<wgrant> adiroiban: It's not a strict policy. But why do you want to violate it?
<adiroiban> I need to add a person for a new role
<wgrant> Ah, that's a rather different case.
<mwhudson> adiroiban: have you seen the LaunchpadObjectFactory?
<adiroiban> and there will be many test for this new person
<adiroiban> mwhudson: nope. I'm lookink now
<adiroiban> there is scarce info on the wiki
<mwhudson> yes
<mwhudson> lib/lp/testing/factory.py
<adiroiban> mwhudson: thanks. I should be able to handle it. Is just that I was not sure about the process
<mwhudson> adiroiban: certainly adding to sample data is discouraged now
<mwhudson> adiroiban: if you're adding a new celebrity (as in ILaunchpadCelebrities) then maybe this could be relaxed...
<adiroiban> mwhudson: is not about a celebrity :). I will create that person/role in the pagetest
<mwhudson> cool
<tshirtman> hi, is there launchpad admins here?
 * mwhudson points at mbarnett or Chex 
 * wgrant guesses that henning didn't get through feedback@ yesterday.
<tshirtman> it's about an issue we spoke about on launchpad but a friends told me it was better to tell it here
<wgrant> tshirtman: Did you email it as suggested?
<tshirtman> we discussed with henning but the probleme is still there
<wgrant> But yes, here is good.
<tshirtman> well we did not wanted to let it be too public (so not in the tracker)
<tshirtman> it's about that kind of "projects" https://launchpad.net/~accusatoriauaer
<tshirtman> its spam with porn, and possibly child porn
<jml> good morning launchpadders
<tshirtman> we found a bunch of these earlyer
<McPeter> i send two email with list bad account
<McPeter> (sorry â¦ hi )
<tshirtman> sent*
<tshirtman> it was yesterday
<McPeter> thanks tshirtman :)
<tshirtman> (we are french)
<tshirtman> so it was only to be sure somebody had the time to handle that
<tshirtman> because we feel it's a bit urgent because of the possible child pornography, and the possible malware (website send random exe files on links)
<jml> poolie, good morning
<mwhudson> jml: were you really online about 5:30 am your time?
<jml> mwhudson, I was awake, but I don't think I was online. Why do you ask?
<mwhudson> jml: notify-osd told me you were online
<jml> I might have checked my phone then, I seriously hope it wasn't transmitting bytes
<mwhudson> jml: good morning, anyway
<jml> oh yeah. connected the home wifi. tis ok
<jml> it's less than Â£6 / MB
<jml> mwhudson, hi :)
<mwhudson> roaming data rates just seem utterly insane
<jml> yes.
<jml> even by the standards of someone used to Australian internet
<mwhudson> heh
<mwhudson> if they were a bit less insane, it's possible that somebody somewhere might actually use them
<jml> indeed
 * tshirtman has a 3G connexion for 30â¬/month in france, 1G with good bandwith, and then unlimited with low bandwidth
<mwhudson> tshirtman: but if you were to use that connection from, say, the uk, you would be charged something nuts i expect
<tshirtman> oh yes
<jml> which is ridiculous
<tshirtman> ^
<jml> europe should be one country for the purposes of mobile phone usage, dammit.
<mwhudson> at least in nz there's an obvious reason for internet to be a bit slow and expensive :)
<tshirtman> we had some people near of french border who accidentaly switch to foreign network, and got insane fees
<mars> jml, have you looked at getting a SIM from a virtual mobile network provider?
<ajmitch> mwhudson: a bit slow & expensive yes, but not this extortionate :)
<mwhudson> ajmitch: right
<thumper> abentley: where are we with https://bugs.edge.launchpad.net/launchpad-code/+bug/436325 ?
<mup> Bug #436325: Diffstat generation chokes on binaries (and others) <oops> <Bazaar:Fix Committed by abentley> <Bazaar 2.0:Fix Committed by abentley> <Launchpad Bazaar Integration:Triaged by abentley> <https://launchpad.net/bugs/436325>
<abentley> thumper: I dunno, we have committed something, but it doesn't completely solve it, and I don't know why.
<thumper> abentley: ok
<thumper> abentley: is that malformed hunk header one?
<abentley> thumper: Yes.
<thumper> ah ok
<jml> back
 * mwhudson lunches
<adiroiban> after running rocketfuel-get do I need to manualy merge the db changes?
<adiroiban> i got this error canonical.database.revision.InvalidDatabaseRevision: patch-2207-10-0.sql has not been applied to the database
<ajmitch> I think that requires 'make schema', doesn't it?
<adiroiban> ajmitch: thanks! up and running now :)
#launchpad-dev 2009-12-08
<mwhudson> thumper, jml: either of you available for a call?
<thumper> mwhudson: I'm around
<mwhudson> i just want to rent an opinion
<jml> mwhudson, me too
<thumper> mwhudson: you have a choice :)
<mwhudson> thumper answered first i guess
<thumper> :(
<thumper> just found some untested code
<thumper> that I'm pretty sure that I wrote
<jml> :)
<thumper> jml: what is our tech-debt tag?
<thumper> jml: do we have an official one?
<jml> thumper, I thought it was tech-debt
<thumper> ok
<thumper> that was what lept to mind to me too
<thumper> but I haven't used it yet
<thumper> jml: just found another untested method
<thumper> gee I must have been slack
<thumper> or clueless
 * thumper files another bug
<jml> thumper, well, you can spread the blame at least as far as your reviewer :)
<thumper> ah
<thumper> I didn't look in doctests
<thumper> yep
<thumper> there it goes
 * thumper hurls
<thumper> not particularly extensive testing though
<ajmitch> thumper: the ugly code was that bad?
 * jml waits for bazaar.launchpad.net to resolve :(
<thumper> ajmitch: a single test in a doc test isn't good testing IMO
<wgrant> jml: <3 Australian Internet?
<jml> wgrant, rural Australian over-priced crappy-plan bigpond internet.
<thumper> mwhudson: got a minute for a pre-impl call?
<mwhudson> thumper: ok
 * mwhudson eods
<cody-somerville> wtf
<cody-somerville> syncSources copied from lucid when I specifically passed it hardy primary as the from_archive
<cody-somerville> or I thought I did
<wgrant> cody-somerville: An archive is not per-series.
<cody-somerville> ubuntu.getSeries(name_or_version='hardy').main_archive doesn't seem to do quite what I would have hoped
<cody-somerville> wgrant, I want to copy a package from backports into a PPA.
<wgrant> cody-somerville: Specify the name and version.
<wgrant> cody-somerville: (or, since bigjools isn't watching, use the web UI)
<cody-somerville> I guess I'll have to use syncSource instead of syncSources
<wgrant> cody-somerville: Can't you specify the series?
<cody-somerville> to copy to but not to specify from
<wgrant> Well, that's stupidly useless.
<wgrant> File a bug.
<cody-somerville> I would but it times out when I try :)
<cody-somerville> Oh, here we go
<cody-somerville> wgrant, Whats the url for the forbidden web UI for copying from Ubuntu?
<wgrant> cody-somerville: https://launchpad.net/ubuntu/+archive/primary/+copy-packages
<wgrant> cody-somerville: But you'll need to pre-filter that.
<wgrant> cody-somerville: eg. search for the relevant package in a PPA, then use that query string on the above URL.
<cody-somerville> ty
<jml> adiroiban, fwiw, I'm updating those exceptions to mention 'make schema'
<adiroiban> jml: thanks :)
<jml> danilos, I'm looking at bug 487628
<mup> Bug #487628: Running bin/test with a windmill layer doesn't indicate when DB revision is incorrect <build-infrastructure> <Launchpad Foundations:In Progress by jml> <https://launchpad.net/bugs/487628>
<jml> danilos, what made you think that it has anything to do with the db revision?
<jml> or windmill, for that matter.
<jml> danilos, never mind, making progress.
<adeuring> good morning
<mrevell> hi
<jml> mrevell, hi
<deryck> Morning, all.
<wgrant> bigjools: Hi.
<danilos> henninge-lunch, congrats, you've got yourself revision 10000 on devel :)
<salgado> danilos, did that windmill test change of yours fix the failing test?
<danilos> salgado, it failed last night due to testfix when ec2 test was done, so I just re-landed it ~30 minutes ago
<danilos> salgado, it's only in devel 10001 now
<salgado> oh, ok
<henninge-lunch> danilos: whoohoo!
 * henninge-lunch relocates
<salgado> but it looks like we have a second windmill failure now
<danilos> salgado, from the last run it seems we've got 3... the one my fix should fix is productseries_templates
<salgado> indeed; the previous run had only 2 failures, but the last one has 3
<danilos> hum, grids.css is gone in devel, meaning that our grids are broken
<danilos> well, our layouts
<danilos> anyone knows anything about missing grids.css? well, they are available on https://launchpad.dev/+icing/rev9962/yui/3.0.0pr2/build/cssgrids/grids.css, but it tries to fetch them from https://launchpad.dev/+icing/rev9962/yui/current/build/cssgrids/grids.css ("current" vs "3.0.0pr2"): not surprising since they were removed from YUI 3.0 final
<salgado> danilos, what layouts do you see broken?
<danilos> salgado, basically all, i.e. on launchpad.dev/~rosetta-admins right-hand box with action links and such is below the content
<danilos> salgado, I might need to do a make clean, I guess
<salgado> danilos, do you see that on production as well?
<danilos> salgado, no, if you are talking about either edge or launchpad.net
<salgado> danilos, ./cssgrids/grids.css is still there in lazr-js, so you should just need a 'make clean && make'
<danilos> salgado, right, I'll try that, not sure why just 'make' didn't pick it up
<BjornT_> danilos: there's a bug in the js build system, where it doesn't update symlinks. it only checks that a symlink exists, not that it points to the right place. maybe that's why it didn't pick it up.
<danilos> BjornT_, right, I'll check that
<BjornT_> danilos: you could try to confirm that by removing the symlink, and then run make again
<danilos> BjornT_, I tried removing "rm lazr-js/build/yui lib/canonical/launchpad/icing/yui" and re-running make, but it didn't help
<danilos> BjornT_, ok, the second one was a bad idea to remove, I bzr reverted it and it works now (I've also cleaned up bzr-version-info.py just in case, so that might have helped as well, but I didn't watch too closely)
<allenap> noodles775: Do you have time to look at some very simple UI ideas I had for displaying the number of affected users in bug pages? https://bugs.edge.launchpad.net/malone/+bug/494040
<mup> Bug #494040: Display the number of affected users in bug pages <bug-page> <Launchpad Bugs:Triaged by allenap> <https://launchpad.net/bugs/494040>
<allenap> beuno: Do you have time to look at some very simple UI ideas I had for displaying the number of affected users in bug pages? https://bugs.edge.launchpad.net/malone/+bug/494040
<mup> Bug #494040: Display the number of affected users in bug pages <bug-page> <Launchpad Bugs:Triaged by allenap> <https://launchpad.net/bugs/494040>
<beuno> allenap, I'm on leave, but if there's a screenshot attached I'll do it
<allenap> beuno: Thanks, but don't worry about it then. deryck has since looked at it and thinks it needs big changes :)
<allenap> beuno: Thanks anyway, have a good break.
<beuno> :)
<beuno> thanks
 * deryck waves at beuno while he's on leave but still on IRC
 * beuno winks at deryck 
<cornwall> Hi, there, I was wondering if anyone on the dev team has acknowledged this bug as it is supremely annoying: https://bugs.launchpad.net/launchpad/+bug/440519
<mup> Bug #440519: Launchpad sends me useless e-mail <Launchpad itself:Confirmed for launchpad> <https://launchpad.net/bugs/440519>
<cornwall> not the most helpful title, but...
<mars> cornwall, a few of the devs would also like to see the mail volume reduced.  I don't know if anyone has devoted time to it though.
<cornwall> mars, would the launchpad mailing list be the best place to get this moving? (if there is one)
<mars> cornwall, for interests sake, just what type of information about a bug do you consider as "critical, need to know"?
<cornwall> well, for certain, not what I, myself, do. LP really doesn't need to send me an email telling me what I did.
<cornwall> IMO it should by default do everything it does now except notify what we do and bug dupes, but have an option to not receive status changes
<cornwall> mars, sorry, didn't use your name :)
<mars> cornwall, np, I'm still watching.  Just looking up the list addresses on the wiki.  There should be a nice, central page for them all
<mars> cornwall, found it: https://dev.launchpad.net/FixBugs
<cornwall> excellent, thank you, mars
<mars> cornwall, no problem.  As far as features go, the UI side should be easy: a simple toggle on the profile page
<cornwall> mars, sure, it's actually kind of baffled me how people like canonical employees have dealt with all the email notifications.... If I get a boatload a day, I wonder what they get...?
<mars> cornwall, someone on the Registry team would be able to mentor the fix for the mail notification code
<mars> cornwall, good/lots of mail filters
<cornwall> :(
<cornwall> well, thanks a lot mars, I'll shoot them an email.
<cornwall> see you later
<mwhudson> good morning
<rockstar> abentley, you can disregard the email I just sent you.  I've worked around my IRC breakage.
<abentley> rockstar: I tried to reach you on jabber about two hours ago, also.
<rockstar> abentley, ah, I see that now.  GTalk was logged in on my phone, but it doesn't notify me correctly.
<abentley> Ah.
<rockstar> flacoste, who do I have to harass about l-d-d being broken?
<abentley> rockstar: so, didja wanna chat?
<rockstar> abentley, sure!
<mwhudson> i see henning got r10000
<bac> hi EdwinGrubbs, sinzui has asked me about the team vocabularies and privacy validation.  i just responded to his email.
<bac> EdwinGrubbs: am i correct that you didn't change the vocabs at all with this branch?
<EdwinGrubbs> bac: right. The vocabs still filter out private teams that you aren't allowed to know about, and the PublicPersonChoice just tells you when a private team you do know about is not valid for a given form field.
<bac> EdwinGrubbs: and how does that differ from the previous implementation?
<EdwinGrubbs> bac: the error message that PublicPersonChoice gives is clearer. Sorry about just regurgitating an explanation I remember writing for the mp.
<flacoste> rockstar: someone in Foundations
<bac> EdwinGrubbs: right, i saw how you made the error messages better - great.  so regarding sinzui's question there is no difference in the vocabs so there should be no performance hit.
<wgrant> bigjools: How is that backport going?
<bigjools> wgrant: it's installed on dogfood but I don't have time to play with it while I am fixing this retry-depwait nastiness
<bigjools> if you want to upload some junk to it and watch it, be my guest, I need to merge your branch first
<wgrant> bigjools: Apparently I need to create a launchpad-soyuz-dependencies metapackage with a versioned dep on dpkg.
<wgrant> Then I can get it into the buildbot image, and the merge is unblocked.
<bigjools> ok
<wgrant> So, I'm going to create launchpad-soyuz-dependencies (depended upon by launchpad-developer-dependencies), so we can depend upon an unconfortably recent dpkg on only the Soyuz machines. Should I maybe move the germinate and devscripts deps from launchpad-dependencies there too, since they're not needed on non-Soyuz machines?
<bigjools> can do I guess, makes sense to group them
<wgrant> maxb: How do the hardy/trunk meta-lp-deps branches interact?
<maxb> hardy is (temporarily?) abandoned for the moment
<maxb> As in, hardy in the PPA is using builds from trunk
<maxb> This was accomplished by sacrificing enforcement of a python2.4-compatible python-support
<wgrant> maxb: Ah, that explains it.
 * wgrant continues the abandonment, and just patches trunk.
<maxb> btw, when you did the lucid python-defaults and python-support - did you just base them on lucid's own?
<maxb> there are some changes in my karmic versions which should be carried forward, I think
<wgrant> maxb: I just based them on Lucid's. What are the changes?
<maxb> python-support: Add Provides so that launchpad-dependencies can enforce a suitable version
<maxb> python-defaults: trigger bytecompile/linking for the older version when re-introducing support
<maxb> I'll do some merging
<wgrant> maxb: Ah, that latter one is very handy.
<wgrant> Thanks.
 * wgrant hunts for a reviewer for https://code.edge.launchpad.net/~wgrant/meta-lp-deps/lp-soyuz-deps/+merge/15836
<maxb> wgrant: Should I take your word for it that nothing sneakily uses germinate/devscripts other than soyuz?
<wgrant> maxb: Probably. A grep didn't find anything, but LP seems unhappy on Lucid so I can't run the tests.
<wgrant> maxb: Do you get "Error: Couldn't find a distribution for 'distribute'.
<wgrant> ?
<wgrant> bootstrap.py does that to me now :(
<maxb> I've only managed to get my netbook onto lucid so far
<wgrant> Ah.
<wgrant> It worked for a few days, but then broke.
<maxb> I was planning to shuffle some partitions and try to update my laptop in the next few days
<wgrant> maxb: I've just kicked off an ec2test without launchpad-soyuz-dependencies, and I'll see if anything unexpected fials.
<wgrant> Or maybe not. The instance just died silently.
 * mwhudson afk for lunch
#launchpad-dev 2009-12-09
<jml> hello
<jml> sorry to miss the NZ crew
<spm> hey jml
<spm> excellent! jscheck failed. I can shortly bounce builtbot without inflicting (excessive) pain on someone.
<jml> spm, hi :)
<spm> FYI. stopping/restarting buildbot on prasÃ©
<jml> spm, thans
<jml> ks
<spm> heh
<jml> I'm about to submit something to PQM, actually :)
<spm> build forced as well. accidently did lp tho; have done db too now.
<wgrant> spm: So it's easier to use an accent than to type the full praseodymium?
<spm> wgrant: inhouse joke actually. :-)
<wgrant> Ah.
<spm> myself and mwhudson were talking back and forth about 'prase' one day; james jumped in and said at least call it 'prasÃ©'. so we did.
<wgrant> Heh.
<spm> istr the vibe was around show some respect and be nice - kinda thing. don't cheapen the name so much. :-D
<spm> and tbh. even prasÃ© is easier to type than praseodymium each time!
<jml> hey, what's that thing you do to a launchpadlib error to get the actual interesting error message?
<wgrant> jml: except HTTPError, e: print e.message
<wgrant> Or e.content. One of them works, but I forget which.
<jml> wgrant, isn't e.message just str(e)?
<jml> wgrant, I think content, but I'll do an experiment maybe.
<wgrant> jml: I think so too.
<jml> how often is launchpadlib released?
<adeuring> good morning
<mrevell> Morning!
<jml> mrevell, good morning
<mrevell> Hi jml!
 * jml is off for the evening
<james_w> OOPS-1439L1839
 * james_w does it the hard way instead
<beuno> sinzui, when you're up
<beuno> how about we make the turnk branch of a projects' font 7 times bigger?
<wgrant> Do the buildbot AMIs get their packages from the ~launchpad PPA, or from some internal archive that nobody seems to know about?
<flacoste> morning launchpadders (from a Montreal covered in snow)
<flacoste> expecting 20cm today!
<jamalta> flacoste: wow that's crazy
<jamalta> although, i really don't know what that's like.. it doesn't snow where i live lol
<noodles775> Wow! I wish Berlin got snow like that :)
<flacoste> jamalta: that's only the beginning, first real snow storm of the year
<jamalta> flacoste: really? isn't snow supposed to start earlier than december?
<jamalta> sorry if I sound a bit ignorant, i really have no clue
<flacoste> jamalta: we do and did receive some snow flakes in november, but nothing that sticks
<bigjools> flacoste: is it too flat to ski in Montreal?
<jamalta> flacoste: ah i see
<flacoste> bigjools: in Montreal, it is, but we have many ski center in the mountains surrounding it
<flacoste> bigjools: but when you are used to skiing in the alps, these mountains are really hills
<bigjools> flacoste: near enough for me to emigrate? :)
<flacoste> biggest one will have 600m of slope
<flacoste> bigjools: oh, really near, they are all within 1h drive
<adeuring> noodles775, beuno: could one of you please ui-review this branch. https://code.edge.launchpad.net/~adeuring/launchpad/bug-344054/+merge/15857 ?
<bigjools> flacoste: yeah that's kinda tiny, but then you do have much better places to ski on in the west!
<flacoste> bigjools: when i was a kid, when went to the ski center every week
 * bigjools is very jealous
<flacoste> bigjools: we do, but that's not within driving range :-)
<flacoste> bigjools: the experience is very different than in the Alps, all ski slopes are cut through the woods, and some mountains have a lot under-the-wood
<flacoste> it can be very challenging
<flacoste> although it won't take you more than 5-10 minutes to go downhill
<bigjools> flacoste: now you're just rubbing my nose in it
<flacoste> lol
<sinzui> EdwinGrubbs: stand-up in 2 minutes
<lfaraone> Hey, where can I find the code in malone which is responcible for rendering +choose-affected-product (the template) ?
<lfaraone> Nevermind, found it. (I didn't want the template, actually, I wanted lp-branches/devel/lib/lp/bugs/model/bugtracker.py)
<salgado> lfaraone, the actual code for the page is in lib/lp/bugs/browser/bugalsoaffects.py
<sinzui> barry_: have you submitted your fix for bug 394848 to ec2?
<mup> Bug #394848: Add inline editing of a project's use of LP services <story-guided-project-registration> <Launchpad Registry:In Progress by barry> <https://launchpad.net/bugs/394848>
<danilos> matsubara-lunch, btw, would it be possible to get per-team oops summaries exported regularly?
<sinzui> bigjools: ping
<bigjools> sinzui: hello
<sinzui> bigjools: does the DistroseriesPackageCache for Ubuntu contain partner packages?
<bigjools> sinzui: should do yes
<sinzui> bigjools: I ask because I think this might be the *fastest* means to identify packages in Ubuntu when looking up packaging links
<bigjools> no doubt
<sinzui> bigjools: My filtering on current version (in python) made +packaging timeouts worse. I was filtering out ppas
<bigjools> sinzui: yes, I could have told you that!  You're issuing an extra query per package
<bigjools> mayeb 2
<bigjools> can you restructure it to issue a single query that gathers data for everything at once?
<sinzui> bigjools: I was thinking of modifying the model.distroseries to always join to DistroseriesPackageCache when the series.distribution is Ubuntu
<bigjools> that sounds a bit hackish
<sinzui> bigjools: How do you propose we support distros that do not use soyuz?
<sinzui> or projects that want to register their packages in debian that we have not gotten yet
<bigjools> if you want to check for publishing status, we can't
<sinzui> Right, so Ubuntu gets a separate rule
<bigjools> bummer
<sinzui> We could revise the feature to only mean Ubuntu. One or two users will be disappointed and will send me hate mail, but I have already disappointed them
<dobey> is something mucked with launchpad merge proposals at the moment? i seem to keep getting 404/oops error paage when trying to change a commit message
<matsubara> danilos, yes, I just disabled it in the last few days as I'm trying to fix a race condition
<danilos> matsubara, cool, it's not a race, but they were very useful :)
<matsubara> danilos, :-)
<henninge> adiroiban: ping
<thumper> barry, gary_poster: can either of you tell me our current status w.r.t. python 2.6?
<thumper> is there a list of things that need to be fixed somewhere?
<gary_poster> thumper: we are not planning on returning to Python upgrade until Lucid
<gary_poster> thumper: is that a problem?
<thumper> gary_poster: I know we aren't, but there was some community effort around it, and I got asked about it yesterday by a guy interested in helping out
<gary_poster> thumper, ah ok.  The page about it is here: https://dev.launchpad.net/PythonMigrationStatus .  We have no compelling reason to migrate ATM and it is a risk and a deployment cost that we don't want to pay, so I recommend that either people should not work on this, or they should work on changes that can work in both 2.5 and 2.6 (and so can be merged now, without waiting for our appetite to change when Lucid comes around).
<thumper> having changes that work with 2.5 and 2.6 sounds sensible to me
<gary_poster> +1
<thumper> gary_poster: given that lucid isn't that far away, and we don't want to be too close to the wire, when is this work scheduled for?
<gary_poster> thumper: The release is 29 April 2010...I'm not scheduling that far away, both because I don't, and because Francis will be back at the helm in early February.  I suspect we'll want a concentrated effort in April, with some exploratory work before then.
<lfaraone> My patch is a really simple string fix. (remove 4 letters from a URL) Do I still need to sign a Contrib. Agreement?
<cody-somerville> lfaraone, No
<cody-somerville> lfaraone, Unless you want to
<lfaraone> cody-somerville: well, I do plan on contributing more in the future, so I guess why not. I poked Edwin in -reviews and he's looking at the change now.
 * cody-somerville nods.
<lfaraone> cody-somerville: granted, contracts aren't legally binding on minors in the UK, I thought. (I'm sub-18)
<cody-somerville> lfaraone, Its not a contract.
<cody-somerville> lfaraone, Although it may still be void in the UK, I'm not a lawyer.
<lfaraone> mk.
<cody-somerville> lfaraone, Infact, it could very well be a contract. As I said I'm not a lawyer.
<wgrant> Am I allowed to merge branches into lp:meta-lp-deps? It's owned by launchpad-committers, so I am technically able.
<jelmer> wgrant: I think so (as long as somebody has approved the change, of course)
<wgrant> jelmer: Three people, in fact. Thanks.
 * wgrant merges.
<poolie> hi jelmer!, wgrant
<wgrant> Morning poolie.
<jelmer> hi poolie
<jml> I'm declaring today "jml gardens the wiki" day
<jml> (man, I wish I could use Bazaar to do it)
<wgrant> Can somebody please copy launchpad-dependencies 0.60 from https://edge.launchpad.net/~wgrant/+archive/launchpad/+copy-packages?field.name_filter=launchpad-dependencies&field.status_filter=published&field.series_filter=karmic to hardy, karmic and lucid in ~launchpad/ppa?
<wgrant> (possibly jaunty too, if we support that)
#launchpad-dev 2009-12-10
<lifeless> mars: http://code.google.com/webtoolkit/speedtracer/get-started.html
<mars> lifeless, yep, took it for a spin.  Didn't help me diagnose anything.  It doesn't tell you what is going on, just "Your page is slow right about... here!"
<lifeless> mars: oh ;(
<lifeless> the web page showed pretty graphs
<lifeless> so I thought it might be usefuk
<mars> lifeless, it is nice to see exactly that "a script block at line 224 is slow", but I would like if it told me things such as "when was DOMContentReady fired?"
<mars> lifeless, thanks for sending the link though.  someone just beat you to it :)
<lifeless> no worries, I'll console myself with a croissant & a sapporo
<mars> lifeless, we'll have to wait and see if this prods the Firefox team into adding proper profiling hooks to the Gecko engine.
<mars> IE got it right the first time, Google spent money to make Webkit right, now Firefox has to catch up.
<thumper> clucking bell
 * thumper wishes for a date_last_modified on merge proposals
<mars> thumper, isn't there an activity log for them?
<mars> like on bugs?
<thumper> mars: no
<thumper> mars: I have a db patch, but I'm not happy with it
<thumper> mars: for the activity log that is
<wgrant> Can someone please copy (with binaries) launchpad-dependencies 0.60 from https://launchpad.net/~wgrant/+archive/launchpad to hardy, karmic and lucid in the ~launchpad PPA?
<jml> wgrant, I don't know how to do that
<jml> wgrant, but if you tell me how, I'll try.
<jml> wgrant, also, do you know whether or not the "Rebuild testing in Launchpad" on https://dev.launchpad.net/Ubuntu/InfrastructureNeeds is done?
 * jml -> lunch
 * thumper does a little dance
<wgrant> jml: Go to https://edge.launchpad.net/~wgrant/+archive/launchpad/+copy-packages?field.name_filter=launchpad-dependencies&field.status_filter=published&field.series_filter=karmic, select the package, select 'Copy binaries', select 'PPA for Launchpad Engineering', select Hardy. Repeat the process but select Karmic and then Lucid
<wgrant> jml: It's sort of done.
<wgrant> But it's not exactly a complete implementation.
<wgrant> jml: The status given on that page (with the URL involving my nick) remains current.
<fungalicious> jml: ping
<jml> hmm.
<jml> I wonder who fungalicious was
<wgrant> I've seen him around here before.
<wgrant> I think.
<thumper> jml: it was kfogel at a friends place
<jml> thumper, ahh ok.
<wgrant> jml: Can you please copy those packages?
<jml> wgrant, I'll load the page & see what I can do.
<jml> wgrant, "PPA for Launchpad engineering"?
<jml> wgrant, "copy", not "rebuild", right?
<wgrant> jml: Yes, 'Copy existing binaries'.
<jml> wgrant, I'm on it like a leper messiah
<wgrant> Aha, it worked.
<jml> for hardy...
<jml> The following source cannot be copied:
<jml> launchpad-dependencies 0.60 in karmic (same version has unpublished binaries in the destination archive for Karmic, please wait for them to be published before copying)
<wgrant> What if you copy from the ~launchpad PPA to itself/
<wgrant> Otherwise try again now, and it will work.
<wgrant> (the binaries would have been publishing right as you pasted that error)
<jml> done
<jml> great success
<jml> wgrant, now, I would like you to answer a million questions about https://dev.launchpad.net/Ubuntu/InfrastructureNeeds :)
<wgrant> jml: Thanks!
<wgrant> Ask away.
<jml> There's one called "Rebuild testing in Launchpad"
<jml> wgrant, Is it still current?
<wgrant> jml: The comment there about the lack of publishing is current.
<wgrant> So, yes.
<jml> wgrant, ok. that's good. I'll chase up that RT then.
<jml> wgrant, do you know the best person, in general, to talk to about this page?
<wgrant> jml: What *is* that RT? The code isn't there yet.
<jml> wgrant, the text of the wiki page makes it sound like the code is there :(
<wgrant> jml: It does, but it is wrong.
<wgrant> Odd.
<wgrant> It certainly requires significant sysadmin intervention too, though.
<wgrant> spm: So, feel like building a buildbot image?
<wgrant> I think all the pieces are together now.
<jml> wgrant, it's mostly just this conversation: http://paste.ubuntu.com/338470/
<wgrant> Ah, yes, that one.
<spm> wgrant: sure; but not today; probably not tomorrow. monday is more likely/possible.
<wgrant> Argh, OK.
<wgrant> Is the release the usual time?
<spm> 2200 next week? ~9am here? I assume so. haven't hear otherwise so far.
 * wgrant must somehow arrange testing of the v3 branch on dogfood tonight, since it's not going to be merged long before release :/
<jml> wgrant, anyway, I want to start linking up that page: make sure there next action on each item is clear, and probably have a contact person for each thing (or just for the page as a whole)
<wgrant> jml: Sounds good.
<wgrant> "The current activity log in the Launchpad bug tracking system does not capture milestone changes." <- that is false
<wgrant> Unless source packages are special.
<wgrant> It certainly works for products.
<jml> wgrant, so, for the rebuild thing
<jml> wgrant, do you know of anything that needs to happen other than the RT?
<wgrant> jml: Besides all the sysadminy stuff, it probably just needs a rebuild archive mode to be added to process-accepted.py, publish-distro.py, etc.
<wgrant> There's little additional code required, now I think about it.
<jml> wgrant, could you please file a bug for it -- I wouldn't be able to describe what's needed as well as you could.
<wgrant> jml: Sure.
<jml> thanks
<wgrant> jml: Are you going to BFB/LCA?
<jml> indeed.
<jml> wgrant, are you confirmed to go?
<wgrant> jml: Waiting on flight confirmation from the travel agent.
<cody-somerville> What is BFB/LCA?
<wgrant> cody-somerville: BFB == build-from-branch sprint in January
<wgrant> LCA == linux.conf.au
<cody-somerville> Is it intentional that you can target a bug task to a milestone that doesn't belong to the series the bug task is targeted to?
<wgrant> I'm not sure that anybody knows how series targets are meant to work.
<danilos> cody-somerville, wgrant: the problem with series is that you can't untarget it, at least not that I know off
<jml> internet sucks.
<jml> danilos, hello
<wgrant> danilos: Correct, you cannot.
<danilos> jml, good morning
<danilos> jml, perhaps now is a good time to talk about https://dev.launchpad.net/VersionFourDotO/Roadmap
<jml> danilos, that's exactly what I was thinking.
<lifeless> danilos: yuou can decline, but not delete the record.
<danilos> lifeless, but if you accepted it (for mistakenly thinking you can deal with it in the series), there's no way to decline it
<danilos> lifeless, in those cases, I just mark them as 'won't fix' for the series, though it still is ugly
 * jml gone
<adeuring> good morning
<wgrant> bigjools: Morning.
<mrevell> Guten morgen!
<bigjools> moin all
<wgrant> bigjools: How close is dogfood to v3-ready? It looks like I'll finally be able to get the branch merged on Monday (once a LOSA updates the buildbot AMI), but it would be nice to test this week.
<bigjools> wgrant: it's ready now
<bigjools> I threw a load of old style stuff at it yesterday and it seemed ok
<wgrant> bigjools: Even with the branch merged?
<wgrant> Excellent.
<bigjools> ah there's one more to merge isn;'t there?
<wgrant> Right. distroseries-source-format-selection, which cannot be merged until buildbot has dpkg >= 1.15.4
<bigjools> I'll merge that now
<wgrant> Thanks.
<bigjools> on DF I mean :)
<wgrant> Right.
<wgrant> While you're there, can you enable 3.0 (native) and 3.0 (quilt) for Lucid?
<bigjools> ok
<wgrant> Then I'll try to upload stuff to my PPA, if that's possible from out here.
<bigjools> wgrant: I'm not sure if lamont updated the builders yet though
<wgrant> bigjools: Ah, that could be a little inconvenient, although it would still allow all the Soyuz code to be tested.
<bigjools> yep
<bigjools> wgrant: ok it's ready
<bigjools> buildd-manager is not running but poppy is
 * wgrant tries to remember the host from the PPA beta days.
<wgrant> Hm, I guess it's all mawson anyway.
<bigjools> I'll run process-upload on demand
<bigjools> yes ppa.df.l.n
<wgrant> bigjools: There should be an upload sitting there. I believe it should be accepted.
<bigjools> wgrant: ok gimme 10m
<bigjools> OTP
<wgrant> bigjools: Sure.
<bigjools> wgrant: you might want to use an upload path that works :)
<wgrant> bigjools: Oh, right, I copied my lpdev stanza.
<wgrant> bigjools: That should work a bit better.
<bigjools> wgrant: it worked
<wgrant> bigjools: There's now a Karmic upload, which should be rejected for being an unsupported format.
 * bigjools runs p-u
<bigjools> rejected, yup
<bigjools> "ftplib_3.1-1-8~wgrant1.dsc: format '3.0 (quilt)' is not permitted in karmic.
<wgrant> bigjools: Perfect.
<bigjools> so we just need to beat up lamont now
<wgrant> I'll find something 3.0 (native)  and another with some component origs in a sec. But yes, then we need a lamont.
<wgrant> bigjools: Two more uploads for you.
<bigjools> ok
<bigjools> both ok
<wgrant> Indeed. Thanks.
<wgrant> And one more to test component orig sharing. I think that's it.
<bigjools> it went in ok
<wgrant> Also, do you have the appropriate stuff for testing syncs there?
<wgrant> Would be good to be sure about that.
<bigjools> hmmm not entirely sure
<wgrant> Or archive admins will break down my door and lynch me.
<wgrant> Although I guess most of the sync-related scripts are owned by ~ubuntu-archive, so they can always be hacked post-release.
<wgrant> I know that sync-source.py itself works.
<bigjools> ok
<bigjools> that's the only thing I know about
<wgrant> They have a whole set of secret scripts that will probably break in obscure ways, but we'll find out on Thursday...
<wgrant> This is new. Reporting Mandriva bugs against launchpad.
<deryck> Morning, all.
<wgrant> bigjools: You suggested last week that I move getBinaryPackageFormat from c.l.helpers to lp.soyuz.scripts.gina.handlers. But the only tests for that function are doctests in the docstring, and l.s.s.gina.handlers doesn't have anything looking for doctests in it. I suppose I could add a test module that just adds a DocTestSuite over that module -- does that sound OK?
<bigjools> wgrant: if you feel sufficiently motivated, yep!
<wgrant> bigjools: There's also an unused getBinaryPackageExtension there which uses the same constant, so I'll remove that...
<bigjools> ok
<bigjools> wgrant: lamont has installed the dpkg on ferraz so we can punt some 3.0 builds through it
<wgrant> bigjools: Awesome.
<wgrant> Except for the big queue which will have to be eliminated.
<bigjools> I'll make you a buildd admin
<bigjools> then you can rescore as you wish
<wgrant> Ah, that would be handy. Thanks.
<bigjools> wgrant: done
<wgrant> bigjools: Thanks.
<wgrant> bigjools: Since ferraz seems non-virtual, can you non-virtualise my PPA?
<bigjools> wgrant: or I can make ferraz virtual
<bigjools> in fact you can do that :)
<wgrant> bigjools: As long as it's a no-op reset trigger, I guess.
 * wgrant tries.
<wgrant> bigjools: Is buildd-manager running?
<bigjools> wgrant: no... I'll start it
<wgrant> bigjools: Ah, that would do it. Thanks.
<bigjools> wgrant: ok it's off and running
<wgrant> bigjools: buildd-manager is quite happy to deactivate ferraz due to an architecture mismatch, but won't start a build when the architecture is correct.
<bigjools> missing chroot probably
<wgrant> Ah, possibly :(
<bigjools> I'm checking
<wgrant> Thanks.
<bigjools> wgrant: you're building lucid right?
<wgrant> bigjools: Yes. lucid i386, since ferraz thinks it's i386 ATM.
<bigjools> ok will sort it shortly
<bigjools> it's actually amd64, it's getting fixed
<wgrant> Ah.
<bigjools> wgrant: ok I'm running queue-builder, we'll get your build dispatched soon ish
<wgrant> bigjools: Why do you need queue-builder?
<bigjools> wgrant: your source upload won't have had a build created for lucid without the chroot
<wgrant> bigjools: The chroot exists, but the librarian file does not (I suspect).
<wgrant> The builds are very much there.
<bigjools> oh right, fair enough, I thought the lot was missing
<bigjools> so why isn't it dispatching :/
<bigjools> ah I see
<bigjools> ok off itgoes
<wgrant> What was wrong with it?
<bigjools> when you flip to virtual you need to set the vm_host
<wgrant> Oh.
<wgrant> Oops.
<bigjools> which is the same as the real host since it's not a virtual machine
<wgrant> Right.
 * bigjools goes to lunch whiile it builds
<wgrant> Should I flip it to manual so it doesn't start trying to build stuff that doesn't exist in the dogfood librarian?
<wgrant> Argh fuck.
<wgrant> post-Karmic dpkg + unpatched lp-buildd == fail
<wgrant> (https://bugs.edge.launchpad.net/launchpad-buildd/+bug/476036/comments/1)
<mup> Bug #476036: sbuild needs to run dpkg-source inside the chroot <Launchpad Auto Build System:Triaged> <https://launchpad.net/bugs/476036>
<sinzui> Chex: ping
<Chex> sinzui: hello
<sinzui> Chex: Can you merge lp:~sinzui/launchpad/false-packages on staging so that I can verify it fixes a performance bug?
<Chex> sinzui: yes sure, let me take a look
<Chex> sinzui: All changes applied successfully.
 * sinzui eagerly awaits the restart
<bigjools> wgrant: gah, pqm will be closed on monday for the release, so we could do with these AMIs getting updated quicker
<wgrant> bigjools: That's what I thought. But the new launchpad-soyuz-dependencies requirement delayed things a bit.
<wgrant> But that's all done now. It just needs the AMI to be upgraded.
<bigjools> wgrant: what exactly does it need, just the dpkg change or just a rebuild with the new meta-package update?
<wgrant> bigjools: All it actually needs is the new dpkg(-dev). But I was told it should really have the metapackage too.
<bigjools> yeah that's what I think
<bigjools> so if the l-d-d meta package is updated it should all be ready?
<wgrant> bigjools: It's all there and in the ~launchpad PPA.
 * bigjools files an RT
<Chex> sinzui: staging restarted for you now.
<wgrant> (launchpad-soyuz-dependencies 0.60 is sufficient)
<sinzui> Chex: thanks
<bigjools> wgrant: l-d-d depends on that though right? so updating l-d-d should DTRT
<wgrant> bigjools: Right.
<bigjools> parfait
<wgrant> bigjools: Although I'm not sure what apt sources the AMIs use.
<bigjools> me neither
<wgrant> But the relevant dpkg is in both the PPA and somewhere in CAT, and l-d-d won't upgrade without it, so it should be fairly obvious to anybody who knows how to upgrade them.
<flacoste> morning launchpadders
<bigjools> flacoste!
<sinzui> bac: Bug #495051 [UnboundLocalError editing proposed team membership]
<mup> Bug #495051: UnboundLocalError editing proposed team membership <oops> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/495051>
<sinzui> EdwinGrubbs: ping
<EdwinGrubbs> sinzui: pong
<sinzui> EdwinGrubbs: As you can see on https://staging.launchpad.net/ubuntu/lucid/+source/grub2, grub2 has been published 2 times in lucid, and the DistroSeriespackageCache has three entries. That is why +packaging lists the entry more than once. I think bac's suggestion of using DISTINCT is the correct fix.
<EdwinGrubbs> sinzui: that shouldn't cause any problems
<wgrant> sinzui: I'm confused about bug #495084. You say that hwtest is shown as not being in Lucid, and then cite a release of checkbox as evidence to the contrary. But those are different packages.
<mup> Bug #495084: source package +index says there is no current release <package-link> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/495084>
<sinzui> wgrant: https://staging.launchpad.net/ubuntu/lucid/+search?text=hwtest lists the packages that are in lucid
<wgrant> sinzui: Those are binaries.
<sinzui> Yes, and https://staging.launchpad.net/ubuntu/lucid/+source/hwtest
<sinzui> says there is not source (wrong I think since the source came from karmic) and the Releases in Ubuntu look wrong because of this
<wgrant> sinzui: There is no source.
<wgrant> There are just binaries from the new (checkbox) source with the same name as the old source.
<wgrant> hwtest hasn't existed as a source package since early Jaunty.
<sinzui> wgrant I think the warning message is misleading. It is often pointed to in bugs as an indication that the package is not in the series.
<wgrant> sinzui: But the package is not in the series, so pointing to it as an indication of that is perfectly valid.
<wgrant> bigjools: Do you think an AMI rebuild will be possible in time?
<henninge> sinzui: Hi!
<bigjools> wgrant: it's on the losas radar, I'm trying
<sinzui> wgrant: I agree with the points of your argument, but I am still dissatisfied. I think the message on the +source The source *must* be in lucid because I cannot rebuild lucid without it
<sinzui> hi henninge
<wgrant> sinzui: What do you mean "I cannot rebuild lucid without it"?
<wgrant> bigjools: Thanks.
<henninge> sinzui: I'd call bug 165146 fixed, isn't it?
<sinzui> wgrant: I think this works in lucid:
<sinzui>     apt-get source hwtest
<mup> Bug #165146: lp admins cannot deactivate accounts <Launchpad Registry:Triaged> <https://launchpad.net/bugs/165146>
<wgrant> sinzui: Because 'apt-get source' looks up binaries if a matching source cannot be found.
<sinzui> oh, I may have fixed that when I exposed accounts to LOSA
<wgrant> sinzui: Note that 'apt-get source hwtest' will download a source package named 'checkbox'
<sinzui> henninge: maybe not. I think you need to ask a  LOSA. They can deactivate the account, but I am not certain they can deactivate the profile (which will be renamed ~name-deactivated)
<henninge> sinzui: I was about to ask who the account - profile split comes into play.
<henninge> sinzui: so this is not bug 49676?
<henninge> mup: bug 49676
<wgrant> It's private.
<henninge> ah, right
<henninge> "Administratively disable account"
<sinzui> henninge: accounts are official SSO now. The foundations teams still works with them. The registry team manages the Launchpad profile . The admin in this case only want to deactivate the profile.
<sinzui> Yes, that bug is private. It has user info that should not be public
<henninge> sinzui: so when a LOSA goes to IPerson:+review and deactivates the user, what happens?
<sinzui> The status of the account is changed
<henninge> sinzui: what is the rationale for only letting LOSAs do that?
<sinzui> Deactivating a profile renames the profile and unlinks the Person from many object
<sinzui> henninge: SUSPEND
<matsubara> Chex, gary_poster, rockstar, bigjools, danilos, sinzui, allenap: LP production meeting in 4 @ #launchpad-meeting
<gary_poster> thx
<henninge> sinzui: ?
<bigjools> ok
<sinzui> henninge: a suspended account can be reactivated if we are in error or the user proves he will not do bad things again
<henninge> sinzui: and that is what's happening on +review, right?
<henninge> and we don't have a UI to completely deactivate a profile, right?
 * sinzui starts dev and looks
<sinzui> henninge: +review allows a LOSA to change the user name and standing
<wgrant> sinzui: anyway, the hwtest source has never existed in Lucid. https://edge.launchpad.net/ubuntu/+source/hwtest/+publishinghistory shows that.
<gmb> Anyone: What's the quickest way to the the URL of the current rootsite (i.e. bugs.launchpad.net blueprint.launchpad.net, etc.?)
<henninge> sinzui: my core question is: why is that a LOSA task?
<wgrant> And it is 3am, so I should sleep.
<sinzui> henninge: +reviewaccount allows the LOSA to set the account status and passowrd
<henninge> wgrant: good night, thanks for all your help
<sinzui> henninge: it is NOT a losa task.
<sinzui> henninge: The bug points out that the user does not know how to find the link
<henninge> sinzui: sorry, LP admin
<sinzui> henninge: do you know where the link is?
<henninge> sinzui: it is at the bottom of "Edit details"
<henninge> that is were the user can deactivate his own account
<sinzui> correct. many users do not want to change their details, they want them removed.
<sinzui> henninge: And the core bug is still open. Foo Bar cannot deactivate a profile....403 is raised
<henninge> sinzui: huh? I can select "Deactivated account" on +reviewaccount and the user is deactivated.
<henninge> sinzui: that is what spm does when you ask him to deactivate a user.
<sinzui> account is NOT profile
<sinzui> profile = Person, account =Account
<henninge> sinzui: ok, so my question is "Why does it take a LOSA to deactivate an Account?"
<sinzui> to stop spammer
<sinzui> henninge: I think you have a fundmental misunderstanding.
<henninge> sinzui: Exactly!
<henninge> sinzui: no, we are right were I was on Monday ;-)
<sinzui> henninge: We adding this feature so that admins could see the SSO data and address spammers.
<henninge> sinzui: I had 10 spam accounts and had to wait for spm's shift to get them deactivated.
<sinzui> henninge: The feature needs to move to SSO
<henninge> sinzui: again, what is the ratinale for having *only* admins to be able to do that?
<sinzui> henninge: escalate it to another LOSA. That is what I do when I see spam
<sinzui> henninge: THIS IS FUCKING SSO. THIS IS UBUNTU
<henninge> sinzui: Quoting tom "spm is handling LP requests this week."
<sinzui> henninge: we do not own this data
<henninge> sinzui: ok, so for spam accounts, I'd be happy if I could just remove homepage_content.
<sinzui> henninge: I know *you* want to fix this, but *you* are not thinking of the consequences of other systems and their owners
<henninge> sinzui: I get it, the account is not really Launchpad data.
<henninge> but the homepage_conent is.
<sinzui> true
<sinzui> the issue here is that answers is really for user requests. This is OUR request, and it needs prompt attention. check, or mthaddon can addresses
<henninge> sinzui: maybe it would be easiest to just rotate the current CHR into Launchpad Admins so that he can remove spam more easily.
<henninge> sinzui: so you know about the close-account.py script?
<sinzui> I know it, not its contents
<henninge> It does some sql magic to completely remove a profile (and an account).
<henninge> stub agreed, though, that it might fail on more complex data but luckily that is not the case for spam accounts.
<sinzui> henninge: I think we just want a safe and easy what to mark an account suspended. The profile and account can be restored if we were is error
<henninge> sinzui: and isn't +reviewaccount such a way?
<sinzui> henninge: and to be clear, we have unsuspended user accounts after the user verified their machines were disaffected
<sinzui> henninge: +reviewaccount is the only *correct* way
<henninge> sinzui: so could we not open it up to the CHR in some way? That would make processing quicker and save LOSA time.
<sinzui> henninge: you and I do not have the rights to see the openid
<sinzui> or the password
<henninge> its not in clear text, is it?
<henninge> another great feature would be "Resend registration mail."
<sinzui> henninge: The form needs to select the available field and info based on ~admin or ~somethingelse that is not all ~launchpad
<henninge> ~registry
<sinzui> henninge: the password is not ever shown, but the password can be changed
<sinzui> ~registry is traditionally project, not person.
<henninge> ok, so we create a new team?
<sinzui> henninge:  we are forbidden to create new teams/permission types without going before flacoste and his tribunal of standard bearers
<henninge> lol
<henninge> sinzui: so, the whole IPerson code is in registry, why not just use ~registry?
<sinzui> That may be right, I ponder what will happen with teams which are also IPerson
<henninge> sinzui: they don't have an account, so they are not affected by changes to +reviewaccount, are they?
<sinzui> They do not have an account, but the permission change may give me other powers, like merge!
 * sinzui may want merge powers
<henninge> sinzui: great, one thing less to delegate to the LOSAs
<sinzui> henninge: The reason we have not exposes team merging id because it often fails with timeouts
<sinzui> henninge: it often fails with profiles that have been used...
<henninge> sinzui: you see, I always thought we were delegating tasks to LOSAs because they required SQL magic.
<sinzui> henninge: barry's profile will take 22+ efforts to complete a merge
<henninge> sinzui: but for stuff that has a UI, why do the LOSAs have to do the clicking?
<sinzui> dude!
<henninge> sinzui: document it on the CHR wiki ... ;)
<sinzui> You've seen my list of stuff my team has to do, and surely you know that 1/3 of my work is personal contributions, and that I have landed more CHR features than anyone!
<sinzui> merging is really hard
<henninge> sinzui: wonderful, I am not critizing you!
<henninge> or am I?
<sinzui> read the blueprint https://blueprints.edge.launchpad.net/launchpad-registry/+spec/cleansing-deactivated-accounts
<gary_poster> bigjools: replied to your question about buildbot. summary: ignore, proceed with what you and muharem were already doing
<sinzui> henninge: merging truly sucks. The feature was designed for unclaimed profiles. But users are using it for active profiles. You and all CHR users are welcome to work on this.
<sinzui> henninge: It really is hard.
<henninge> sinzui: I understand.
<sinzui> henninge: My rule is to let users do anything needed to correct their mistakes. I do not put CHR/LOSA barriers in the way. But features created 5 years ago still have those barriers.
<bigjools> gary_poster: ah I missed the sourcecode pull fail, thanks
<henninge> I see.
<gary_poster> cool, np
<henninge> sinzui: so, originally we did not talk about merging, we talked about deactivation. As a quick and easy way to get rid of spam accounts.
<henninge> sinzui: You are saying, that exposing this might also expose the merge functionality of teams, right?
<sinzui> henninge: We do not deactivate bad accounts because they can be reactivated by the user. we SUSPEND bad accounts
<henninge> sorry, suspend ;)
<henninge> sinzui: could we not do as you suggested and make +reviewaccount select data to display and make the reduced version available for ~registry?
<sinzui> henninge: Since we are not adding new levels of permission to security.py, the implementation implies that ~registry is being added to IPerson launchpad.Admin. That gives you a lot of power over people and teams
<henninge> right
<sinzui> henninge: as I said, adding celebrity teams or levels requires approval from others
<henninge> yeah, got that ...
<flacoste> sinzui: could we use launchpad.Moderate instead of launchpad.Admin for suspending an account?
<flacoste> sinzui: and give ~registry launchpad.Moderate permission
<henninge> flacoste: I was just about to suggest that.
<sinzui> flacoste: henninge The checker is ReviewByRegistryExpertsOrAdmins
<henninge> or rename launchpad.ProjectReview to launchpad.Review and use that.
<flacoste> sinzui: checkers for launchpad.Moderate or launchpad.Admin?
<sinzui> We use that for launchpad.ProjectReview because launchpad.moderate is taken by something else
<henninge> I think that is for ProjectReview
<flacoste> iirc, there was a technical difficulty in merging ProjectReview and Review
<henninge> flacoste: I don't see an existing launchpad.Review
<henninge> My itention was to broaden the scope of lp.ProjectReview
<sinzui> henninge: in security.py add
<sinzui> class ModeratePerson(ReviewByRegistryExpertsOrAdmins):
<sinzui>     permission = 'launchpad.moderate'
<sinzui>     usedfor = IPerson
<sinzui> then change EditAccount to
<sinzui> class EditAccount(ModeratePerson):
<sinzui> henninge: I am mistaken I think. The user needs access to his account (to deactivate it) so the permission may need to remain launchpad.Edit
<sinzui> henninge: lp.ProjectReview is correct. There is a conflict with FAQ moderate that blocks us from using the permission
<henninge> sinzui: yes, so the XXX says.
<henninge> sinzui: remain lp.Edit for EditAccount?
<henninge> ok, I'll put that in a bug.
<sinzui> henninge: I think so
<sinzui> henninge: I think the code needs to look like this: http://pastebin.ubuntu.com/338783/
<sinzui> wgrant: beuno: bigjools:I am have a very difficult time fixing +packaging because of the special case where we know exactly what is published in Ubuntu.  The problem is that users are creating packaging links for packages in PPAs, not the primary archive.
<adiroiban> can I use YUI3 event-keys for Launchpad ?
<bigjools> sinzui: do you need to know the publishing state of PPA packages as well?
<beuno> sinzui, sinzui if you give me a little bit more context, I can try to help out
<sinzui> wgrant: beuno: bigjools: I am very tempted to add Ubuntu validation rules that prevent users from creating such links. I could then purge the PPA links from the DB, and remove the filter used in +packaging that ensure we only make links to published packages
 * bigjools has to go in 5 minutes
<sinzui> bigjools: I really do not care about the publishing state. I want to avoid an ubuntu contributor seeing a link from lucid/+packaging to a lucid/+source that is not really in lucid
<bigjools> sinzui: ok, so simply using Ubuntu state will suffice, no?
<sinzui> bigjools: I pushed the filtering into model, but it breaks tests that are very hard to reconstruct knowing that we hide packaging links
<beuno> sinzui, you will not get an opposition from me to get ubuntu-specific rules in Launchpad
<beuno> in reality, there are no other distros really using Launchpad
<sinzui> beuno: I am also tempted to remove debian and all the other distros from the packaging form
<bigjools> sinzui: you could make it generic actually, if you look for something published in an archive with a purpose in (main_archive_purposes)
<sinzui> making the feature Ubuntu specific is not project friendly, but to be clear, the only use for it is Ubunut
<bigjools> if you use my suggestion you're guaranteeing that we only link to packages in distros that Soyuz publishes
<sinzui> bigjools: I use that in the filter. I would reuse it for validation if we decide packaging links are not for ppas or other archive in cyberspace
<bigjools> sinzui: I have to run now, but perhaps I can take a longer look at this tomorrow
<bigjools> and see if I can offer more help
<sinzui> beuno: look at the Packages by distribution section of https://staging.launchpad.net/bzr-gtk/+packages
<beuno> sinzui, yes...
<sinzui> By making packaging links Ubuntu specific, we will remove about 100 links to Debian and other distros
<beuno> sinzui, how did those links get created?
<sinzui> Project create the links from this same page to communicate to users that their software has packages for distributions
<beuno> sinzui, one thing to do there, I think, would be to not have empty sections for the unlinked
<sinzui> beuno: click (+) Link package under a series
<sinzui> beuno: but we need the section to allow someone to create a link
<beuno> sinzui, yes, we can try and solve that in a different way
<beuno> sinzui, you could show Ubuntu by default
<sinzui> beuno: we talks about that.
<beuno> and offer "Other distributions" separately
<sinzui> beuno: We agreed it should should the current series by default
<beuno> in the +addpackage I mean
<beuno> sinzui, ok, then we need to fix the UI
<beuno> make it a one liner
<beuno> probably drop the "No packages..."
<sinzui> beuno: Yes, that is what we talked about in August. The challenge is to remove/hide the complexity of the package, and to show the Ubuntu packaging history....
<sinzui> beuno: ... so that we merge the common form with the special ubuntu form: https://staging.launchpad.net/bzr-gtk/0.93/+ubuntupkg
<beuno> sinzui, in the  +addpackage?
<sinzui> beuno: To be clear, there are two form, one to link ubuntu and one for everyone else. User do not link the ubuntu one because they want to create links to show historical information
<sinzui> beuno: so we discussed merging the forms last August to do the right thing by default, but allow users to record historical/other-distro info if they want to
<beuno> sinzui, right. And the problem you are trying to solve now is...?
<sinzui> beuno: but we did not realise at the time that users are using this to indicate that packages are available in PPAs, not in the default distro release
<beuno> aha
<beuno> sinzui, and how do they say in which PPA?
<sinzui> and we can only verify Ubuntu, so we must have two rules, or desupport other distros
<sinzui> about 1/3 of lucid packaging links are for PPAs, not primary+partner
<sinzui> beuno: the user does not say it is a PPA. We do not let projects indicate when ppas they are packaged in
<beuno> sinzui, ah, ok, I'm starting to understand then
<beuno> so, links to PPAs is something people really really super want
<sinzui> beuno: and the project pages talk about packages, not packages that are default in distros
<sinzui> a link would be super
<beuno> so we either make the linking to PPAs something we support (ie, let them say where)
<beuno> or not support that use case
<beuno> and bump the linkage feature  :)
<sinzui> beuno: This is a great example of a feature we designed for Ubuntu, that is co-opted by projects to do something else.
<sinzui> I favour making this feature only about Ubuntu. Then allow projects to indicate their PPAs, which already list the supported distros
<sinzui> beuno: also, Ubuntu only cares about primary packaging. If we only support Ubuntu, we can remove the nasty part of the form
<beuno> sinzui, I'm a bit uneasy about dropping support for debian specifically
<sinzui> beuno: this is what will be dropped: https://staging.launchpad.net/debian/sid/+packaging
<beuno> sinzui, ok, kill it
<beuno> if we find a sensible use case for it, we can always bring it back in better shape
<sinzui> Yes, if we want other distros to use it, it needs a different feature set
<mrevell> night all
<bac> sinzui: ping
<sinzui> hi bac
<bac> sinzui: call soonish?
<sinzui> I am ready now
<bac> me2
<sinzui> bac: I am looking at https://bugs.edge.launchpad.net/launchpad-registry
<sinzui> bac: https://bugs.edge.launchpad.net/launchpad-registry/+bug/296927
<mup> Bug #296927: checking menu links <feature> <tech-debt> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/296927>
<sinzui> https://edge.launchpad.net/launchpad-registry/+milestone/series-3.1
<thumper> morning
<adiroiban> when creating a MP, is there a way to link it to a bug so that the bug will be updated to fix-commited on merge, and fix release later.
<adiroiban> the branch is already linked to the bug
<sinzui> adiroiban: no, the important link is between the bug and the branch
<adiroiban> sinzui: ok. so I have to manually update the bug status?
<sinzui> adiroiban: The bug subscribers will be notified with the bug is merged. There is no automatic status change because the branch may only partially fix a bug
<adiroiban> sinzui: thanks for the info. yep I was notified when the branch was landed
<sinzui> adiroiban: I am contemplating a rule to automatically mark bugs that are fix-committed to fix-released when when a milestone is released...but I need to hack bug karma to make sure the bug assignee get the credit
<adiroiban> sinzui: :) I don't care about karma, but it would be nice to have some magic help at updating bug status
<adiroiban> like bzr --fixes
<sinzui> The karma rule is what is stopping me from doing this. it is important to some people. I stopped marking bugs fix-released when we do released because it steals karma
<adiroiban> :(
<adiroiban> well... life suck :)
<adiroiban> sinzui: no problem. many thanks for the support. I can live with it
<wgrant> sinzui: Do you now understand what I was explaining last night?
<sinzui> No not really. I am certain the SP must be in the distro when we copy from the parent
<wgrant> lamont: Hi. Do you have an lp-buildd with https://bugs.edge.launchpad.net/launchpad-buildd/+bug/476036/comments/1 fixed?
<mup> Bug #476036: sbuild needs to run dpkg-source inside the chroot <Launchpad Auto Build System:Triaged> <https://launchpad.net/bugs/476036>
<wgrant> sinzui: What tells you that?
<sinzui> apt-get source
<sinzui> disregard the example of hwtest
<wgrant> Have you another example?
<sinzui> bzr apparently was not published in edgy or fiesty. yet apt-get source will get it.
 * sinzui looks for karmic example
<wgrant> sinzui: It *was*, but is no longer.
<sinzui> why rewrite History? that sounds like a bug
<wgrant> sinzui: Edgy and Feisty are no longer supported, so they were copied to old-releases.ubuntu.com, then all their publishings were removed from LP to save disk space on mirrors and the archive machine.
<wgrant> History hasn't been rewritten; the publishing records are just now set to Obsolete.
<sinzui> The page says it wasn't ever published though
<wgrant> Right, that's not ideal.
<wgrant> Although the message is true.
<sinzui> https://edge.launchpad.net/ubuntu/edgy/+source/bzr
<sinzui> ^ That does not look right. There is a bug and am not certain what it is
<wgrant> It's true.
<wgrant> Edgy has no packages left.
<wgrant> Edgy is obsolete, so its packages have been removed.
<wgrant> However that message could make that more obvious.
<lamont>                         $dir = $1 if /^dpkg-source: (?:info: )?extracting \S+ in (\S+)/;
<sinzui> maybe we should not show that message at all for obsolete series
<lamont> wgrant: ^^ that change in 2 places
<wgrant> Obsolete isn't like Superseded and Deleted (the two more normal removal states).
<lamont> but no, not quite packaged yet, will have it on dogfood for testing sometime tonight or tomorrow
<wgrant> lamont: Right, I know the diff, but ferraz doesn't have it.
<wgrant> lamont: Ah, great, thanks.
<lamont> right
<lamont> wgrant: is it blocking you?
<wgrant> lamont: Not really. As long as it happens in the next day or two it's fine.
<lamont> if so, I can smash it onto ferraz in a couple of hours, otherwise it'll just come as part of things on prolly monday (I want to test over the weekend)
<wgrant> The Soyuz code works, so that's no longer blocked on testing.
<lamont> cool
<wgrant> OK, sure.
<lamont> oh hey - if you're done with dogfood, could you toss a no-change binutils upload at it?
<lamont> with ddeb exporting turned off
<wgrant> I can't upload to main.
<lamont> even on dogfood?  how rude
<bigjools> I can fix that
<lamont> ta - I need to go afk for about an hour or so, then I get to put in another long night
<lamont> bigjools: the intention is to make sure that the pkgmanglebinary in the tarball I gave you earlier won't break production lp when binutils (e.g.) builds
<bigjools> which would be nice
<lamont> yeah - there have been complaints about time served and all that
<lamont> must run
<bigjools> wgrant: you're now in core-dev on DF
<wgrant> bigjools: Thanks.
<sinzui> wgrant: I think this page is bong I think the reason is that zope3 existed for a short time in karmic: https://edge.launchpad.net/ubuntu/karmic/+source/zope3
<sinzui> wgrant: in which case we should state the package is was discontinued and we do not need an alert because this is not extraordinary
<wgrant> sinzui: Right.
<bac> hi sinzui
<sinzui> Hi bac. Do you need me to break something?
<bac> sinzui: no, but can you look at a query and run it on staging?
<bac> http://paste.ubuntu.com/338974/
 * sinzui does
<bac> sinzui: ah, wait.  i need to look for .tar.bz2 also
<bac> hmm, i wonder if my branch handles those...
<sinzui>  bac: http://paste.ubuntu.com/338987/
<bac> sinzui: run this one instead http://paste.ubuntu.com/338986/
<sinzui> yes master
<bac> just the select, not the update
<bac> thanks
<sinzui> I worked that out after getting nasty errors when blind pasted it into the terminal
<sinzui> pgsql hates that query
<bac> really?
<bac> hmm
<sinzui> wow that is a  very large response
<bac> my sql fu is limited
<sinzui> 4713 rows
<sinzui> bac: i'm getting a full report. pastbin hates me
<sinzui> bac: I sent the report by mail because it killed FF when I tried to pastebin it
<bac> sinzui: ok, thanks
<sinzui> about 1/3 are plain/text
<bac> sinzui: could you do it again with a 'mimetypes = 'text/plain' ?  those are really the ones we're interested in.
<sinzui> okay
<bac> i hate stumbling around via you as a proxy
<sinzui> bac: http://paste.ubuntu.com/338993/
<sinzui> doesn't look like anyone is using lp to distribute porn
<bac> whee
<bac> sinzui: i think the update at http://paste.ubuntu.com/338986/ is ready to run on staging.
<bac> i'll see if i can get chex to do it
<sinzui> spm: certainly can, he's got mad skilz
<bac> oh, i forgot spm was about
<bac> except he isn't
<sinzui> he's mysterious like that
<sinzui> hmm
<thumper> where is spm today?
<sinzui> looks like packaging-views.txt is predicated of the current behaviour that projects link to source packages that are not published. This may require a total rewrite.
<wgrant> Yay for unrealistic tests.
<sinzui> it is very realistic. I want to change reality. Link to Ubuntu or get stuffed
<sinzui> I doubt this will make this release. Maybe a pot of coffee will help me fix this
<sinzui> wgrant: do you care about packaging links between projects and debian?
<wgrant> sinzui: Not particularly, no. Packaging links aren't useful for much.
<wgrant> The only thing we use them for is defaulting to the correct upstream project when we click 'Also affects project'
<sinzui> they should be
<wgrant> And we don't do that for Debian.
<wgrant> sinzui: Why do you ask?
<wgrant> I think, ideally, we would say that our upstream is the Debian package, and Debian would say that their upstream is the project, and the relationship would be transitive.
<wgrant> But that sounds hard.
<sinzui> wgrant: +ubuntupkg only permits users to link to the current Ubuntu development series. Project seem to prefer +addpackage because it lets them record that their project is packaged in an older Ubuntu series, and in a rare case Debian
<wgrant> sinzui: Ah, you're dealing with the multiple view madness?
<sinzui> I do not think debian is ideaa because they will not fix the bug or sync the translations. We want the links so that users and tools can send bugs and translations upstream, and for Ubuntu to have upstreams tip.
<sinzui> wgrant: It is madness, because I think users co-opted the feature to report that they made a PPA.
<wgrant> sinzui: Debian does fix bugs. Lots of them.
<wgrant> sinzui: But yes, the PPA situation is a bit stupid.
<wgrant> That needs a fix, but I'm not sure how.
<sinzui> Letting projects link to ppas would help.
<wgrant> It would, but it's not perfect.
<wgrant> I'm not sure that forbidding creation of packaging links to unpublished sources is a good idea. Sure, do not display them, but it might be useful for eventually providing an automatic list of PPAs for a project, much like https://launchpad.net/ubuntu/+source/dpkg does now.
<sinzui> exactly what I have been think!
<sinzui> yet the work of preventing links to unpublished packages in a series is process intensive
<wgrant> Yes :(
<wgrant> I think somebody needs to go through all the use cases before much more can be done.
<wgrant> At the moment packaging links are pretty pointless, but they have the potentially to be very very handy.
<sinzui> wgrant: If we had some process to guide a user from making a PPA, to getting it into universe, it would make more sense to allow the links to be made first
<sinzui> All the canonical launchpad developers are focused on making those links useful. My first problem is that users are not using them as we intended them.
<wgrant> sinzui: But has work been done to work out what they mean? What they should mean?
<wgrant> It seems nobody is sure how they are going to be changed to be more useful.
<wgrant> And I think it would be handy to know that before an attempt is made.
<sinzui> wgrant: That is something I need solved by the end of January
<sinzui> wgrant: A link is only useful of the launchpad knows the project's bug-tracker, development branch, and is setup for translation syncing. We need a message that explain why this import. Projects and packages need to state what is missing. We can suggest links too because in most cases, the project and source package have similar names
<sinzui> s/of launchpad/if launchpad/
<wgrant> sinzui: But packaging links should be useful the other way too.
<sinzui> I have not found may compelling reasons for the other way.
<wgrant> sinzui: If I go to a project page, it should tell me where I can packages.
<wgrant> +get
<sinzui> well
<wgrant> If I click on a release, it should tell me where I can get packages of that particular release.
<sinzui> I suggested that we should emphasise that downloads is overrated. My argument is not favoured
<sinzui> I suggested that we should emphasise that.   Downloads is overrated. My argument is not favoured
<wgrant> Has the community been asked for ideas on how to improve things?
<sinzui> I do not think so
<wgrant> That seems like a bad thing.
<sinzui> The registry is working the the other teams this series. code, translations, and bugs need the links. They do not care how they get there, they just need to links in place to enable their systems
<wgrant> But you need to consider all the possible uses before you make a potentially short-sighted model change.
<sinzui> indeed. I have not made model changes because I have not talks to anyone
<sinzui> All these features I am discussing already exist. the issues are user experience, and the fundamental question should they exist?
 * thumper lunching
#launchpad-dev 2009-12-11
<spm> bac: sinzui: heyo (sorry was driving up to sydney) did you still need me to apply something?
<jml> wuu Sydney
<thumper> \o/ bzr-svn success https://code.staging.launchpad.net/~thumper/pydoctor/bzr-svn
<jml> thumper, excellent :)
<thumper> spm: hey, can losas turn a project into a project group?
<spm> thumper: I believe so. not sure the rules around that atm...
<spm> thumper: huh, chr can do them now as well.
 * jml is back
<bac> thumper, spm: you cannot convert a project into a project group.  CHR can now create project groups but the name must be free already, i.e. project of same name cannot exist
<spm> ahh. ta, thanks bac
<thumper> bac: it would be pretty cool to have a script that renames the project, makes the project group and copies across descriptions and things like that
 * thumper EODs
<jml> thumper, g'night.
<jml> g'night all
<adeuring> good morning
<mrevell> Mornin' all
<adiroiban> henninge: hi, is there a page listing all templates in Launchpad with the same name? I'm working at bug 435165 and beside a link to other templates from the source package, I would like to add a link to all templates with the same (if there is such page)
<mup> Bug #435165: Make it easier to navigate to the full list of templates in source packages <trivial> <ui> <Launchpad Translations:In Progress by adiroiban> <https://launchpad.net/bugs/435165>
<henninge> adiroiban: no, there is no such page.
<henninge> adiroiban: but I know that on a templates page there is a list with links to templates with the same name.
<henninge> * a template's page *
<adiroiban> henninge: yes... but i think only first 4 tempaltes are listed
<henninge> adiroiban: sure but it means that there is already such a query in the code. You could make the limit optional.
<adiroiban> henninge: :) I don't like options :) ... there is still the UI problem how to display 30 templates
<adiroiban> henninge: I think i will just go with solving that bug :)
<adiroiban> without other changes
<bigjools> wgrant: did you see a  build go through on DF of a 3.0 package?
<wgrant> bigjools: I didn't. Is the builder fixed?
<bigjools> should be
<wgrant> bigjools: lamont suggested it wouldn't be done until today or Monday.
<wgrant> bigjools: (lp-buildd needs patching for Karmic's dpkg)
<bigjools> mmm oh, I thought he said he'd done it
 * wgrant retries.
<henninge> I think I have seen "AttributeError: 'thread._local' object has no attribute 'interaction'" before but cannot remember what is missing here: http://paste.ubuntu.com/339130/
<wgrant> henninge: You're not logged in.
<henninge> Anybody got an idea?
<henninge> argh!
<henninge> thanks wgrant, now I remember
<henninge> ;)
<bigjools> wgrant: "Couldn't find directory of bar_1.0-1.dsc in dpkg-source output"
<wgrant> bigjools: Yep, that's the bug.
<wgrant> (and as you can probably see, I forgot to flip it back to manual in time. oops)
<bigjools> wgrant: that's what happens without the right dpkg?
<wgrant> bigjools: dpkg-source's output changed in Karmic.
 * wgrant finds the bug.
<bigjools> ah
<wgrant> https://bugs.edge.launchpad.net/launchpad-buildd/+bug/476036
<deryck> Morning, all.
<bigjools> wgrant: I am going to bash a load of builds through DF to stress test some stuff, I'll need to make the builder auto again
<bigjools> morning deryck
<wgrant> bigjools: But the builder does not work (even for 1.0 sources)
<bigjools> wgrant: oh, fuck sake
<bigjools> this is not good
<bigjools> pqm closes today and I need to QA stuff
<wgrant> bigjools: The fixes are trivial, if you can get a sysadmin to either alter the regexps as lamont says, or downgrade dpkg
<noodles775> bigjools: closes on Sunday I think, but not much different.
<bigjools> noodles775: I worked every waking hour this week already, I don't want to work the weekend too :)
<noodles775> totally. I was just clarifying when pqm closes :)
<lamont> wgrant: applied, fwiw
 * bigjools will test it when dogfood decides to wake up
<bigjools> why does FF have to reload a page when going back one in the history.... ridiculous
<lamont> "work offline", "back", "work online" maybe?
<bigjools> apt-get install chromium maybe ;)
<bigjools> well, not the game
<henninge> sinzui: Hi!
<sinzui> hi henninge
<henninge> sinzui: ping, again
<sinzui> hello
<henninge> Hi
<henninge> sinzui: I am not sure if I missunderstood something or if I just haven't grasped the workings of the zope/LP security system yet.
<henninge> sinzui: but I am stuck and I wondered if you could help me.
<sinzui> I hope I can
<sinzui> you want to give ~registry launchpad.Edit on IAccount so that the status can be set to SUSPENDED?
<henninge> I guess. Here is what I have done so far: http://paste.ubuntu.com/339233/
<henninge> sinzui: what did we plan to use launchpad.Moderate for, then?
<henninge> sinzui: so far I am only dealing with views
<henninge> the page test is failing
<henninge> like this: http://paste.ubuntu.com/339192/
<sinzui> henninge: That was flacoste's suggestion. To introduce a new permission, you need to modify the IAccount interface, separate the items you want ~regisrty to manage to a new interface. Add the new permissing and interface to the ZCML
<sinzui> henninge: the paste looks like the ZCML rules are missing
<henninge> sinzui: I only changed ther permission for +reviewaccount
<sinzui> but not the underlying object
<henninge> yes, the zcml requires lp.Edit for IAccount.
<sinzui> you can load that view so long as the code/template does not access the attributes
<henninge> I am trying to understand the error message
<henninge> It says "launchpad.Moderate" is required to access this view but you don't have that.
<henninge> right?
<sinzui> The last text of the last line indeed says that
<sinzui> Henning add this to account.zcml
<sinzui>         <require
<sinzui>             permission="launchpad.moderate"
<sinzui>             interface="canonical.launchpad.interfaces.IAccountPublic" />
<sinzui> oop
<sinzui> do not do that
<sinzui> Separate the attributes that you want ~registry to manage to an new interface named IAccountModerate, and add this to ZCML.
<sinzui>         <require
<sinzui>             permission="launchpad.Moderate"
<sinzui>             interface="canonical.launchpad.interfaces.IAccountModerate" />
<henninge> sinzui: don't I need a new interf...
<henninge> ah, yes
<henninge> sinzui: ok, I will do that.
<henninge> but what about the error message?
<henninge> If that was the problem here, I'd expect a message about IAcount, not about the view.
<sinzui> henninge: the message says there is no launchapd.Moderation
<henninge> so, the view is for IPerson, requiring launchpad.Moderate
<henninge> doesn't ModeratePerson in security.py apply to that?
<sinzui> henninge: It might be. Accounts are not exposed in the UI, and we do not want to.
<sinzui> henninge: the first thing  you should be doing is testing the redefinition of the intreface in doc and unit tests. You got ahead of yourself
<henninge> sinzui: I see.
<henninge> ok, let me do that and then we take it from there
<flacoste> morning launchpadders
<abentley> deryck: lib/lp/bugs/tests/../doc/bug.txt is failing for me on an unmodified copy of stable.  Any ideas? http://pastebin.ubuntu.com/339243/
 * deryck looks
<abentley> deryck: test_bugs_webservice is also failing: http://pastebin.ubuntu.com/339246/
<deryck> abentley, no idea what that's about.  pulling a copy of stable, too.
<deryck> looks like sample data is out of sync with the test maybe.  those look like sample data-based tests to me.
<abentley> deryck: I ran make schema earlier, but I'll run it again.
<abentley> deryck: Yeah, make schema didn't help.
<deryck> abentley, yeah, they fail for me too in stable.  I can look into it, but it will have to wait a bit.  Have a call coming up.
<BjornT_> gary_poster: maybe you could review a small patch? https://code.edge.launchpad.net/~bjornt/launchpad/bug-495397/+merge/16007
<abentley> deryck: Thanks for looking into it.
<deryck> abentley, np
<gary_poster> BjornT_: looking
<adiroiban> is there a way to see exceptions from a view method?
<adiroiban> I can see LocationError but I don't know why
<henninge> sinzui: I had to move things around in IAccount* to accomodate for the fact that status is part of two interfaces. http://paste.ubuntu.com/339260/
<sinzui> Correct. You do need to do that
<matsubara> sinzui, let me know when finish editing LaunchpadTestPlan/3.1.12
<matsubara> please
<sinzui> matsubara: done
<sinzui> henninge: I am surprised this works. I recall that the ZCML validator will scream if there are two permission for an attribute.
<matsubara> thanks sinzui
<henninge> sinzui: it still does :(
<sinzui> henninge: I recall needing to ensure an attribute was listed just once, then updating the permission checkers in security.py to to ensure that each level of responsibility was included eg, launchpad.Moderate must  allow the owner and admin to change them too
<henninge> sinzui: verifyObject is failing for IAccount. I don't kno why it does not see the Attributes from IAccountModerated.
<sinzui> interesting
<henninge> http://paste.ubuntu.com/339309/
<sinzui> status_comment is defined in IAccountModerated?
<henninge> sinzui: I think the checkers are ok : http://paste.ubuntu.com/339313/
<henninge> sinzui: yes
<sinzui> hmm that is bad
<sinzui> ModerateAccount must check for registry_expert(user) , edit must check be admin. I think you need to revert EditAccount
<sinzui> henninge: my recommendation to change EditAccount was based on giving ~registry Edit. Since you create Moderate, we need separate checking rules
<sinzui> henninge: I think the error you are seeing relates to the interface and zcml. Can I see those
<henninge> sinzui: but isn't the current situation more permissive to when I change it
<henninge> ?
<sinzui> henninge: whay are you creating Moderate when Launchpad.Edit uses is_admin_or_registry_expert(user)
<henninge> sinzui: lp:~henninge/launchpad/bug-495126-deactivate-users
<henninge> codebrowse is down ...
<henninge> let me paste it
<henninge> sinzui: account.zcml http://paste.ubuntu.com/339317/
<henninge> sinzui: interfaces http://paste.ubuntu.com/339320/
<sinzui> henninge: revert EditAccount. Those rules are not changing because you are creating launchpad.Moderate. ModerateAccount checks uses is_admin_or_registry_expert(user) . In fact, I think ModerateAccount() may look exactly like how you wrote EditAccount
<sinzui> henninge: As I said earlier, I do not think you can have IAccountStatus because you are defining it twice. That look wrong and I recall ZCML will hate you for it
<henninge> sinzui: no, the current setup doesn't.
<henninge> sinzui: IAccountEdit and IAccountModerate don't share any attributes.
<henninge> sinzui: that is what zcml was complaining about in the first version I did.
<sinzui> henninge: IAccountPublic and IAccountModerate both have status, then you give it to IAccount
<sinzui> so Iaccount has status, but two permission rules for it
<henninge> IAccount does not inherit from IAccountPublic but from IAccountBase
<henninge> there is one rule for reading and one for setting
<henninge> sinzui: found it!
<henninge> sinzui: there is no read rule for the two attributes in IAccountModerate, only a set rule.
<sinzui> henninge: yes I see that.
<henninge> sinzui: test is passing now again, all is well. But interfaces/account.py has gained some weight.
<sinzui> henninge: There are several unreviewed projects that were setup by spammers
<henninge> sinzui: I did not get to reviewing projects this week, I am sorry
<sinzui> No one has reviewed projects for several weeks. there are about 450 projects
 * sinzui approves the obvious ones so that only the challenging ones need review.
<Daviey> Hey, i'm interested in adding a boolean people[].mugshot.isValid to the API - to return if there is a mugshot for that person/team?  Does anyone have any guidance
<Daviey> afaics it's currently only possible by using .open()
<Daviey> which is less than ideal, because it looks like it downloads the image
<beuno> Daviey, sinzui can probably give you a nod
<Daviey> sinzui: ping ^^
<sinzui> Daviey: we do not *add* to the API, We expose what is there. So the questions we ask it does the application need to know this, and if so add it. Otherwise we make changes to the application so that users get that information some other way, Do you want to do this because mugshot blows up when you try to get it?
<Daviey> sinzui: I just want a sane way to find out if a person/team has a mugshot or not :(
<Daviey> programtically
<beuno> isn't there such logic in Launchpad today?
<Daviey> beuno: i've spent quite alot of time trying to find out.. i'll be really pleased if you know of one :)
<beuno> Daviey, I don't, but Launchpad finds out somehow, so either that needs to be exposed, or something needs to be created
<sinzui> Daviey: In python we would test for this by
<sinzui>     if person.mugshot:
<sinzui> or to be pedantic
<sinzui>     if person.mugshot is None:
<sinzui> Daviey: I think the problem is not that you cannot know that the user has a mugshot, but that there is a problem in how it was exposed: bug 336943
<mup> Bug #336943: requesting user's mugshot via api OOPS when user is using the default one <api> <registry-people> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/336943>
<Daviey> sinzui: I was just testing the above code, for a moment i was feeling rather silly.
<sinzui> Daviey: The logic should return None instead of dying
<sinzui> I do not think Launchpad should return the default url when there is none.
<Daviey> sinzui: what i'm currently doing is try mugshot.open(), catch HTTPError
<Daviey> which makes me feel very dirty.
<sinzui> Daviey: I agree. I do not know what is going. The API uses this:
<sinzui> http://pastebin.ubuntu.com/339365/
<Daviey> hmm
<sinzui> Daviey: I think the problem is in lib/canonical/launchpad/fields/__init__py I see BaseImageUpload requires default_image_resource to be set...but never uses it!
<Daviey> sinzui: You obviously know this better than i do, but would that cause a BOOM?  Having data that isn't used?
<Daviey> launchpad web app looks like it uses default_image_resource
<sinzui> Well if the default is not being used, the field is processing None, which will cause an error. I think the field should check that there is an image to work. If there is not one, return the default
<Daviey> sinzui: Is this something you'll have time to work on, or should i look at trying to submit it myself?
<sinzui> Daviey: I do not see a test that shows that the mugshot attribute works when access via the API. A test of any test user will work since non have mugshots set
<sinzui> I do not have time to work on it. That is why the bug is low
<Daviey> >>> people['davewalker'].mugshot
<Daviey> <lazr.restfulclient.resource.HostedFile object at 0xa8d130c>
<Daviey> I have no mugshot
<Daviey> sinzui: thanks for your time
<sinzui> Daviey: I updated bug 336943 with my thoughts
<mup> Bug #336943: requesting user's mugshot via api OOPS when user is using the default one <api> <registry-people> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/336943>
<Daviey> \o/
<sinzui> Chex: ping
<Chex> sinzui: hello there
<mars> oops.  launchpadlib threw up when I ran the simple example on the wiki :(
<adiroiban> when doing pagetest, and using find_tag_by_id, is there a function for getting links withing that tag?
<adiroiban> like browser.getLink?
<mars> adiroiban, it uses beautiful soup under the hood, and soup can do that, so maybe check the find_tag_by_id() function definition.
<maxb> mars: Here's my personal gathering of things I've played around with launchpadlib: http://paste.ubuntu.com/339440/ - hope it's useful
<mars> maxb, thanks
<mars> turns out it was my user pythonpath being loaded over the system libraries
<mars> nice
<mars> excellent!  you can pull raw API JSON using a call launchpad._browser.get()
#launchpad-dev 2009-12-12
<MTecknology> Can the LP API be used to log into a service from the cli without too much effort?
<MTecknology> hm.. maybe not api.. but I know cli is possible
<wgrant> bigjools: Thanks for landing that.
#launchpad-dev 2009-12-13
<mwhudson> morning
<mwhudson> 724 unread :(
<Pilky> mwhudson: that sounds painful
<thumper> mwhudson: morning
<thumper> mwhudson: I only had 150
<thumper> down to 17 now
 * thumper makes coffee after a slow start
<thumper> jelmer: as I understand it we are going to have just one url field in code import now
<thumper> jelmer: and change the svn, git, hg, and maybe cvs to use it
<mwhudson> thumper: you worked thursday and friday though
<thumper> mwhudson: yes, yes I did
<thumper> mwhudson: ping me when you want to talk
<jelmer> thumper: When is that change going to land?
<thumper> mwhudson: or when you get sick of filtering email
<mwhudson> thumper: ok
<thumper> jelmer: I believe that work is blocked on you fixing the patch now :)
<thumper> although it is significantly less trivial than before
<mwhudson> thumper: stub's branch didn't include any python-level changes
<mwhudson> i think
<thumper> mwhudson: yeah, I think it was just the patch, but now if we are going to unify, then code changes are needed
<jelmer> thumper: IIRC stub said he was going to make the required DB change
<thumper> jelmer: unfortunately it is much more than just a db change
<mwhudson> well not necessarily much more
<mwhudson> you could put @properties on the CodeImport object
<thumper> mwhudson: as long as there was an XXX and a bug to go along with those properties...
<mwhudson> thumper: ready to call now?
<thumper> mwhudson: ok
<mwhudson> thumper: skype?
<thumper> yep
<wgrant> Is PQM really still open?
<thumper> wgrant: shouldn't be
<thumper> wgrant: I think spm is closing it when he starts
<jml> hello all
<mwhudson> jml: hello
 * jml back in ~1.5 hrs.
<spm> thumper: wgrant: per a request from danilo, to be closed in ~ 30mins from now. 0000 UTC
<wgrant> spm: Ah. Thanks.
<wgrant> spm: Do you know how bigjools was able to land my new-dpkg-requiring branch yesterday? Did the builbot AMI end up getting updated early?
<spm> no idea. have only read the most urgent emails at this stage - fixing all the w/e brokenness
<wgrant> Ah, right.
<spm> gimme... maybe 1-2 hours and I should be up to speed.
<spm> "mondays. I love the smell of nagios alerts in the morning" to badly misquote "apocolypse now".
 * danilo__ is asleep (at least going, really going), but...
<danilo__> wgrant, buildbot images were updated on Friday by mthaddon, so bigjools just got it into the queue which was stuffed because of the CP request for retry-depwait fix, so it landed sometime on Saturday or Sunday :)
<danilo__> fwiw
 * danilo__ is off
<wgrant> danilo__: Ahh, thanks for the explanation.
<wgrant> And yes, sleep!
<spm> rightio. closing pqm....
#launchpad-dev 2010-12-13
<wallyworld> thumper: do you need to change the overall mp status to Approve, or i can....?
<thumper> wallyworld: well, someone does
<StevenK> wallyworld: You should be able to
<wallyworld> thumper: i know i can - just wasn't  sure what the correct protocol was
<wallyworld> thanks
<thumper> wallyworld: if you have the reviews, you can change the overall status
<thumper> that's fine as protocol goes
<wgrant> spm: How should I coerce you into adding my key to PQM?
<StevenK> wgrant: Via an RT
<wgrant> :(
 * wgrant dislikes RT.
<wgrant> Mostly because it's Perl.
<StevenK> wgrant: Then check out http://jifty.org/view/FAQ
<thumper> OMFG
<thumper> launchpad.dev is seriously borked
<thumper> how do I turn of dev mode?
<wgrant> thumper: The 500 JS requests per page?
<thumper> wgrant: yeah
<wgrant> thumper: configs/development/launchpad.conf
<wgrant> s/devmode on/devmode off/
<wgrant> Reduces it to a nice fast one request.
<StevenK> wgrant: You didn't just review your lunch due to that web page? :-)
<thumper> I remember deryck saying that devmode had a problem, but that is just absurd
<wgrant> StevenK: I am immune to such things.
<wgrant> thumper: It is just about unusable, yeah.
<wgrant> Fortunately, devmode is not important.
<thumper> no, it is unusable
<wgrant> It does load *eventually*.
<StevenK> wgrant: Wait until Wednesday
<wgrant> After firing off 500 requests through a single-threaded slow appserver, generating dozens of oopses in the process.
<wgrant> StevenK: Oh?
<StevenK> And then I'll see how immune you are in person :-)
<wgrant> Ah, right.
 * thumper screams a little
<thumper> gah
<StevenK> thumper?
 * wgrant is reminded of Wellington, where thumper spent most of the time muttering "fuck fuck fucking fuck"
<StevenK> -            return "You already have a PPA named '%s'." % proposed_name
<StevenK> +            return "A PPA named '%s' already exists." % proposed_name
<StevenK> thumper: Does that address your concerns re: bug 682548?
<_mup_> Bug #682548: Archive.validate has poor wording for matching team ppas <confusing-ui> <ppa> <trivial> <Soyuz:Triaged> <https://launchpad.net/bugs/682548>
<thumper> StevenK: I would have preferred two different errors depending on whether the PPA is for me or a team I'm a member of
<thumper> perhaps "You already have a PPA named '%s'." % proposed_name for me
<thumper> and "%s already has a PPA named '%s'." % (owner.display_name, proposed_name)
<thumper> for a team
<thumper> that's much nicer
<StevenK> I can abstract that easily
<StevenK> ... maybe
<thumper> yes you can
<thumper> I looked at it when I was making the related  change
<thumper> but decided not to get too distracted
<thumper> I'm still dealing with the other branch actually
<thumper> right now
<StevenK> thumper: I have a branch for this change, so I'm happy to fix it
<thumper> good :-)
<thumper> wallyworld: ping
<wallyworld> thumper: pong
<thumper> wallyworld: have you landed your built-packages-listing branch yet?
<thumper> because I want you to delete some whitespace
<wallyworld> thumper: it's in ec2 now
<wallyworld> thumper: can i pull it from ec2?
<thumper> wallyworld: what about the filter follow up?
<wallyworld> thumper: no, i was going to land the base branch first
<wallyworld> thumper: i can make the changes in the 2nd one
<thumper> wallyworld: you have space between the open brace and the hyperlink
<thumper> wallyworld: (<a href="blah">
<thumper> wallyworld: followed by a newline, then 'some text'
 * wallyworld looks
<thumper> wallyworld: will give a blank space between ( and some text
<thumper> to avoid that, you need the text to be hard against the closing > of the anchor tag
<wallyworld> thumper: you mean it should be:  .....ourceBuilds">Lean more about....  ?
<thumper> yep
<wallyworld> thumper: ok. will fix in the filter branch. thanks for letting me know. i didn't notice the extra space
<StevenK> thumper: If I look at https://bugs.launchpad.net/soyuz/+bug/680889 and then click the diff link from the linked MP, the floating diff box starts at line 123 and I can't dismiss it
<_mup_> Bug #680889: Needs to handle "all linux-any" like "linux-any" <qa-needstesting> <soyuz-build> <Soyuz:Fix Committed by wgrant> <https://launchpad.net/bugs/680889>
<lifeless> === Top 10 Time Out Counts by Page ID ===
<lifeless>     Hard / Soft  Page ID
<lifeless>       86 / 4920  Archive:+index
<lifeless>       56 /  194  BugTask:+index
<lifeless>       32 /    0  Person:EntryResource:retractTeamMembership
<lifeless>       29 /  366  POFile:+translate
<lifeless>       15 /  234  Distribution:+bugs
<lifeless>       12 /  112  ProjectGroupSet:CollectionResource:#project_groups
<lifeless>        6 /  251  Distribution:+bugtarget-portlet-bugfilters-stats
<lifeless>        5 /    5  ProjectGroup:+milestones
<lifeless>        4 /   12  DistroArchSeries:+index
<lifeless>        4 /    7  NullBugTask:+index
<lifeless> someone should do a deploy ;)
<wgrant> lifeless: A couple of my other revs are blocking it.
<wgrant> I would QA them if I had DF access :)
<lifeless> wgrant: you don't need df access
<lifeless> wgrant: you can ask spm or another losa to do superuser stuff involved in qa
<wgrant> lifeless: ROFL
<spm> hmmm?
<lifeless> wgrant: but also please ensure you file bugs/rts so that we can qa such things on qastaging in the future
<StevenK> lifeless: Can be summed up as "Please run soyuz services on qastaging"
<StevenK> But that's rofl-tastic at the moment, given asuka's load
<lifeless> StevenK: needs to be more specific or it won't happen.
<lifeless> StevenK: please help it happen.
<lifeless> as for load, there's another box coming, don't wait to describe (in detail) whats needed for that box.
<wgrant> It's also not clear how staging Soyuz should work.
<wgrant> Given that staging doesn't have the archives.
<lifeless> the goal is simple.
<wgrant> Sure.
<wgrant> But Soyuz isn't :)
<lifeless> everything else I happily delegate to folk working :)
<wgrant> Heh.
<lifeless> seriously. We need an archive on a box running soyuz stuff against qastaging? RT IT.
<lifeless> -now- -please-.
<wgrant> We need to first work out if it's possible.
<lifeless> wgrant: huh? no.
<lifeless> wgrant: that would be backwards.
<lifeless> I've tried rting this and got back a 'huh, please spell out whats not running' - staging *is* running all soyuz services according to the losas.
<wgrant> staging is running buildd-manager.
<wgrant> I don't think qastaging is.
<lifeless> qastaging isn't yet.
<wgrant> And AFAIK they're not running anything else.
<lifeless> but you can qa on staging too.
<lifeless> wgrant: if they aren't, RT IT
<lifeless> or tell me, and I will file an RT, in all caps, because I'm having to repeat silly, obvious, clearly sensible things on my holiday :)
<lifeless> james and charlie both want the work queue for losas/sysadmins present in rt, not in our heads to be filed when its become top priority.
<spm> and for us too - makes it easier to get a scope for work and what's important vs what can wait
<lifeless> we know we want this, and we know that theres stuff to do to make it work, so what stops us from rting the specifics today?
<lifeless> I *can't* because I don't know the specifics.
<lifeless> wgrant: StevenK: ^ seriously.
<wgrant> I think Soyuz people (since we're about to blink out of existence) need to talk about what makes sense, given experiences with dogfood. Until then we do not know specifics.
<lifeless> how can you not know specifics?
<lifeless> I don't mean *how*, I mean *what*
<wgrant> Ah, so the general specifics, I see :P
<lifeless> service foo-bar talking to qastaging db
<lifeless> thats specific
<lifeless> what machine? - losa choice
<lifeless> soyuz folk are of course welcome to talk to bigjools and so forth, but its not a question of what makes sense: we /need/ to be able to qa /everything/ on [qa]staging
<lifeless> dogfood as a place to do major experimentation and stress testing is great.
<lifeless> blocking deployments because a patch happens to be to the foo-bar component and that only runs on dogfood - thats a huge problem
<wgrant> Sure.
<lifeless> it partitions the codebase, blocks the whole team, increases the risk of subsequent deploys.
<lifeless> So all I'm asking is that the missing services be:
<lifeless>  - enumerated
<lifeless>  - in an RT
<lifeless>  - or a bug
<lifeless> and I'm totally  baffled what is hard/objectionable/unworthy in that request.
<lifeless> can you help me understand?
<wgrant> The publisher will explode at the slightest problem. For example, staging won't have any of the archives on disk. What will the publisher do? Boom. What if something that the publisher wants is deleted from the production librarian? Boom.
<wgrant> I'm sure there are others.
<wgrant> How do we test ftpmaster-tools changes?
<lifeless> ask a losa to run the command
<wgrant> What if we need to test override behaviour?
<wgrant> Hmm.
<lifeless> if you need the archives on disk, ask for that in the rt
<lifeless> thats *exactly* the sort of thing I'm asking be written down and made explicit
<wgrant> That's an awful lot of data to be copying around.
<lifeless> having a good solid QA pipeline is fundamental to continuous deployments
<lifeless> are you worried about cost or somethinhg?
<lifeless> if so, say so!
<wgrant> And practicality of syncing that regularly.
<lifeless> how often does it need syncing?
<spm> chuckles
<lifeless> I would say once a week when the db is reset
<lifeless> more importantly
<lifeless> wgrant: this is a guess, but are you trying to make sure it will all work before asking for it ?
<wgrant> lifeless: Yes.
<wgrant> Asking for impossible things is not something I want to do!
<lifeless> wgrant: thats a particularly bad antipattern
<lifeless> please stop
<lifeless> teamwork depends on clearly articulating and socialising the needs *before* solutions are arrived at.
<lifeless> its only impossible until a solution is arrived at
<lifeless> and no discussion on sollutions can happen until the requirements and constraints have been articulated
<lifeless> you should feel *no shame* at asking for a dozen impossible things before breakfast [assuming they are things we want to do that will help us]
<spm> wgrant: fwiw? you'd be hardpressed, REALLY hardpressed to outdo lifeless for impossible RT's and impossible numbers of same.
<wgrant> So, I don't see how discussing this on an RT ticket will help, when it mostly needs thought within Soyuz. Perhaps I misunderstand your use of RT.
<lifeless> soyuz is only a fraction of the solution space
<spm> it's both discussion, task request, please help, everything
<lifeless> the gsas
<lifeless> and losas
<lifeless> are the ones that will be:
<lifeless>  - provisioning
<lifeless>  - admining
<lifeless>  - maintaining
<lifeless>  - implementing
<lifeless>  - supporting
<lifeless> it
<lifeless> its TOTALLY premature to have any discussion about *how* without them being involved, and their *requested* forum is RT.
<spm> and loling at it's crackfullness. don't forget this one.
<lifeless> spm: yeah but you do that on your sekret comments
<spm> not always
<lifeless> true
<wgrant> lifeless: We don't know what we want.
<spm> sometimes we practice democratic and open crackful sharing
<lifeless> anyhow, this is way depressing for my holidays.
<lifeless> wgrant: I know what we want.
<lifeless> wgrant: I just don't know how to enumerate it.
<lifeless> wgrant: and I'm feeling sad that I'm not getting much support on that.
<lifeless> wgrant: anyhow, I'll leave you be, and will sit on all ex-soyuz folk at the epic and get this written down
<lifeless> unless one of you takes pity on me and writes it up
<wgrant> Do we have goals for the Epic yet?
<lifeless> broadly yes
<lifeless> there will be some presentations - e.g. a ta update, strategy update, tl update
<lifeless> and we'll be settling into the new team structure
<StevenK> Hudson, damn it!
<StevenK> WANT!
 * spm notes the prior comments about crack
<spm> spm 1, stevenk 0
<StevenK> Hudson is far less crackful than buildbot
<spm> spm 2, stevenk 0
<spm> (was a nil response, auto win. sorry)
<StevenK> And doesn't require writing PYTHON to teach it how to build a project
<wgrant> Just a lot of XML?
<lifeless> no
<wgrant> But JAVA!
<spm> yes.
<lifeless> pretty nice, I know
 * spm has supported jvm's before. it's not pretty.
<lifeless> fast though
<spm> until a GC comes along, then you freeze for a second or more.
<poolie> hm
<lifeless> well you want to avoid stop the world gcs
<lifeless> which current gc engines are pretty good at, if tuned to the workload
<poolie> you would think so
<spm> I remain... sceptical. based on prior experience.
<StevenK> spm: Given current buildbot, or java, which would you prefer?
<poolie> are we talking about Hudson for testing lp?
<spm> strawman choice :-)
<StevenK> Just so I know if I'm pushing uphill or down
<poolie> if that has occasional pauses it shouldn't really matter
<spm> ha. no. this is personal opinion not pushback. if LP decides it want's hudson, that's cool.
<lifeless> we're considering a java db for some stuff
<lifeless> (cassandra)
<poolie> how about using jvm based things like Flume for logging? or cassandra
<lifeless> no problem
<lifeless> there are several considerations of course
<lifeless> canonical runs some jvm services internally already
<poolie> well, my question was more "do the SAs fear it"
<lifeless> AIUI the biggest consideration is the preffered tech mandate for best-of-breed fungible components
<poolie> iow trying to decide if they're the best option to be used everywhere?
<lifeless> bringing in something different to whats already used, for instance
<poolie> right, the "is it worth changing/diverging" conversation
<lifeless> with the first of a kind
<spm> I'm not too fussed myself over what tech you choose. just saying that my experiences with JV< is that it does have some nasty side effects. and GC under load is a biggie.
<lifeless> we can get into a bit of an overoptimisation discussion
<poolie> mm
<poolie> i mean of course erlang and python use gc too
<spm> not that you'd notice from some of the "leaks" we see... :-)
<poolie> so the thing would have to be whether the jvm is worse at it (whihc seems a bit unlikely) or whether the application architecture exacerbates the problem
<lifeless> the reason you don't notice the pauses in python is because its never fast to start with
<spm> haha
<poolie> :) or indeed gil
<spm> just at $job-1 we were running via a j2ee. wit hextra gc logging. and the amount of time lost to gc's was truly astonishing.
<poolie> well, you probably don't know how much time we're losing to gc inside python :)
<poolie> i'm just saying it might be even more
<poolie> (though it's probably not)
<spm> that would make me a sad panda
<poolie> it might have just been more visible with extra logging one
<lifeless> gill + gc would exceed stop the world gc + object moving overheads IMO
<poolie> *on
<spm> can/should we be tuning python for that in any way? just thinking that with jvm you can tweak a fair bit to optimise for your load and usage.
<lifeless> spm: yes, rt #idunnoitsmyholiday
<lifeless> spm: 'single threaded appservers'
<spm> hahahaha
<lifeless> spm: wins on two counts
<lifeless> firstly one thread
<spm> ok, so you guys are worrying about that then already. /me washes hands.
<lifeless> secondly smaller memory footprint so overhead per-cpu of gc time is reduced
<lifeless> even though the total time on the machine is increased, if that makes sense
<spm> yeah that was the unobvious killer - you can't just throw memory at a jvm, that can make things worse.
<lifeless> you might like the cassandra slides I sent around
<spm> shrug. I have a .procmail From: lifeless >> /dev/null
<spm> it saves time.
<spm> :-P
<lifeless> s/null/rw/
<spm> read-only surely?
<lifeless> raid warning :P
<spm> hahaha
<poolie> spm i think the "can't throw memory at it" problem is kind of related to it insisting on the whole app being inside a single OS process
<poolie> which is an example of an architectural limit
<poolie> and kind of the opposite of robert's single-thread appserver experiment
<spm> yeah, I'd go with that
<spm> certainly we did notice that we could only get so much out of a single process, then it made more sense to fire up more on the same (4 cpu, not cores, cpu) server
<spm> the process couldn't use the h/w resources it had available.
<spm> mind you... coldfusion code; which gets interpreted by the CF interpreter, which itself is a jvm/j2ee container. wheee.
<poolie> right, that's just what i mean
<poolie> python obviously has this effect to an even higher degree, because of only really using one core at a time
<spm> so poolie, you'll write a fix for python for us ... today?
<poolie> better minds than mine have failed
<poolie> the best idea is to run more processes
<spm> :-)
<poolie> this is kind of good for horizontal scaling and robustness anyhow
<spm> yeah, it's a nice match there.
<spm> if frustrating.
<poolie> why frustrating?
<spm> in that, eg, we don't fire up multiple squids or apaches etc to max h/w out. they can just make use of it. recognising I'm comparing apples with fish, so a tad unfair.
<poolie> !?
<poolie> but apache at least does spawn multiple processes
<poolie> and squid does that too for some specific bits, last time i looked
<spm> yeah - it's handled internal to itself. it's not a start apache1 through 200 thing.
<poolie> ah, yes
<poolie> maybe we could fix that
<spm> ha. from rambling discussions comes "hey that's a problem, we should look at fixing that" :-D
<poolie> do you really manually start 200 things?
<poolie> it seems it could at least be scripted
<poolie> anyhow, that could be good to file bugs about
<spm> we have, more or less, apps 1-16 ish, plus edge 1-5. each with their own separate configs and such. so sorta. 200 is more for how many apache processes I've enabled previous with a single trivial change.
<spm> which is also about 20 different init.d scripts :-/
<poolie> sheesh
<poolie> that definitely seems worth fixing
<lifeless> theres a pending MP from me with a config autogenerator
<lifeless> which is a first step at reducing the insanity
<spm> how would/could you fix the multiple procs per server thing? idly curious.
<lifeless> me? i wouldn't.
<spm> :-)
<lifeless> I'd make the variation per configured proc 0
<lifeless> and then use existing sysadmin tools to dial the number of processes desired
<poolie> +1
<lifeless> last thing I want to maintain is another process-manager implementation :)
<spm> :-)
<spm> oh bother stubs not around. and staging update failed in a rather impresive and interesting way.
<wgrant> spm: WTF, but OK.
<wgrant> Thanks.
<spm> wgrant: yes. :-)
<spm> the cleanup of the allowed email addresses is painful. all these ... funky ones.
<lifeless> wtf?
<wgrant> "Note that due to PQM's finnkiy nature, all submissions must come from the 1st/default address."
<spm> pqm - only accepts the 1st email in a gpg key
<lifeless> gpgv
<spm> send from another, even if in the allowed key, fail.
<lifeless> oh
<lifeless> so there are two discrete things
<lifeless> gpgv
<lifeless> and email addresses used for per project/branch permissions
<lifeless> gpgv ensures you own the email address
<lifeless> and the email address is what the policy check is done on.
<lifeless> trivial to list N addresses for a person if you want to
<lifeless> just a config issue
<spm> you're kidding. gnnnnnnnnnnnngh.
<lifeless> no
<lifeless> noone has ever asked me
<spm> hahahahaahhaha
<spm> we thought you knew :-D
<lifeless> nope
<spm> so where/how?
<lifeless> just throw any additional emails you want folk to support in the email list for the group
<lifeless> done
<spm> ahh. code change?
<lifeless> no
 * spm notes to self, rob is on HOLIDAYS... let it go......
<lifeless> you can even turn off email checking entirely if you just have one group
<lifeless> keep verify_sigs on though :)
<spm> we do have others, but I don't think they're really used. and could possibly be dropped safely.
<lifeless> I do object to the 'finnkiy nature' bit
<lifeless> when its a config issue:)
<StevenK> Let's just switch to tarmac
 * StevenK hides
<wgrant> Isn't that almost done?
<spm> lifeless: that's still finicky (now spelt with more correct)
<mrevell> Morning
* mrevell changed the topic of #launchpad-dev to: Launchpad Development Channel | BUG JAM!  | PQM open for business | firefighting: - | Get the code: https:/â/âdev.launchpad.net/âGetting
<wgrant> Does anyone know what's up with the lucid_db_lp?
<wgrant> It looks force-worthy.
<deryck> Morning, all.
<danilos> gary_poster, hi :)
<gary_poster> heh, hey danilos
<danilos> gary_poster, so, canonical/launchpad/versioninfo.py loads bzr-version-info.py using imp.load_source('...', 'bzr-version-info.py') and that tries to read it from the cwd
<gary_poster> huh
<danilos> gary_poster, that means that none of our cronscripts which are run like $LP_PY /path/to/lp/tree/cronscripts/blah.py get a reasonable value of version info data
<danilos> gary_poster, small script to demonstrate the problem: https://pastebin.canonical.com/40858/
<danilos> gary_poster, I figure we can run our scripts using (cd $LP_ROOT && $LP_PY ...) to work-around the problem, but that'd probably be ugly for the future and we'd want to fix versioninfo to read LP_ROOT/bzr-version-info.py instead
<gary_poster> danilos: /me wonders if a symlink into lib is not a reasonable colution
<gary_poster> s
<danilos> gary_poster, I have no particular opinion, I basically want to solve bug 682186 and ensure nobody else runs into it themselves :)
<_mup_> Bug #682186: X-Generator: Launchpad (build Unknown) <Launchpad Translations:Triaged> <https://launchpad.net/bugs/682186>
<danilos> gary_poster, btw, I've tried that (symlinking into lib) and that doesn't work for me
<gary_poster> danilos, duped, weird
<gary_poster> danilos: I'll futz around for a sec and get back to you if I find something I think is reasonable
<danilos> gary_poster, imp.find_module can find it then though
<danilos> gary_poster, anyway, thanks, got a call now :)
<gary_poster> flacoste: do you happen to know why Steve A used the imp module to implement and canonical/launchpad/versioninfo.py's import of bzr-version-info.py?  His checkin message is "add revno to main template". :-)
<gary_poster> Seems like a simpler, more robust approach would be to symlink that file from the top of the tree into lib (as an importable name) and then do try: ... except ImportError: in canonical/launchpad/versioninfo.py .
<gary_poster> Any idea why it is the way it is, historically or otherwise?  symlinks were supported in bzr at the time, as far as I can tell from a quick web search.
<bigjools> mthaddon: how's the script doing?
<mthaddon> bigjools: have done a few more runs - all still taking an hour or so
<bigjools> mthaddon: that's weird, I'd expect it to finish to completion with the limit you used.  Maybe it is finishing to completion, it's just genuinely taking that long
<bigjools> can I take a peek at the log?
<mthaddon> bigjools: devpad:~mthaddon/2010-12-13-ppa-log-parser*.log
<bigjools> mthaddon: so it looks like it's hitting the limit each time
<bigjools> I'd be tempted to remove that
<EdwinGrubbs> lifeless: ping
<mthaddon> bigjools: I'd rather not - I really don't think there's any point to running a script as long as the last run we did - I'm fine to do it batches like this until we catch up
<mthaddon> bigjools: do we have any way of estimating how far from catching up we are?
<bigjools> mthaddon: roughly, it's processing around the "Tue Sep 21" date range
<bigjools> so it has a long way to go
<mthaddon> ok
<bigjools> mthaddon: huh actualy scratch that
<bigjools> it's processing files in some weird ordering
<bigjools> so I have NFI how long it will take, especially when it logs lines like "Finished parsing <gzip on 0x8722e18>"
<bigjools> :/
<gary_poster> danilos: http://pastebin.ubuntu.com/543094/ is smallest change that works locally.  http://pastebin.ubuntu.com/543095/ is in the direction of a cleanup, IMO (would also maybe want to change bzr-version-info.py name or something).
<gary_poster> Next steps: maybe check with losas to see if they read bzr-version-info.py from some surprising place, or if it is always in the root of the tree.  I think it is always in the root of the tree, including in production.  Then choose one of those two, apply, and do something else. ;-)
<flacoste> gary_poster: no idea
<gary_poster> ack flacoste thanks
<danilos> gary_poster, hey, done with a call, let me look at that
<danilos> gary_poster, I don't mind either solution, I'd be happy to drive the fix forward, but I am not sure where'd I put a test for it :) and whether it would be a useless test (i.e. more of a baggage test that takes long time to run since I'd have to use popen or something to make sure python is outside the tree)
<gary_poster> danilos, that would be great if you would drive it forward, though you can also ask me to.  For test, a popen.call from an alt directory calling the equivalent of "bin/py -c 'from canonical.launchpad.versioninfo import revno; print revno is not None'" might be good enough.
<gary_poster> and should be pretty fast.
<danilos> gary_poster, right, that's what I was thinking, but popen is an order of magnitude slower than a bare unit test or something, that's what I meant by "slow"
<gary_poster> sure
<danilos> gary_poster, anyway, I'll go with your second (symlink) option and only add a test to that, how does that feel to you?
<gary_poster> danilos: sounds good to me, cool
<gary_poster> thank you
<danilos> gary_poster, no worries, it solves a bug for me as well :)
<gary_poster> :-)
<danilos> gary_poster, do you think it's ok to move versioninfo to lp.app or lp.services along the way?
<danilos> gary_poster, (I'll do it only if it doesn't cause too much work, but just wondering)
<gary_poster> danilos: I think that would be another nice cleanup, yeah.  maybe app?  <shrug>
<gary_poster> (lp.app I mean)
<danilos> gary_poster, yeah, that's what I lean to as well
<gary_poster> cool
<jcsackett> did something land to speed up ec2 test recently? i just noticed runs are taking like 3.5 hours, where they used to take 4-5 hours for me.
<jcsackett> i suppose this could have happened awhile ago, and i've just been oblivious.
<bigjools> did windmill get turned off?
<mars> that could do it
<mars> windmill takes 40 minutes to run
<bigjools> I noticed it's not running locally for me
<danilos> bigjools, is it perhaps crawling locally for you?
<bigjools> danilos: more of an amble
 * bigjools EODs
<deryck> jcsackett, it is windmill being turned off that saved the time.
<jcsackett> deryck: ah, cool. glad that happened. 3.5 hours for results is way better.
<lifeless> EdwinGrubbs: ?
<lifeless> jml: ping
<lifeless> flacoste: ping
<jml> lifeless: hi
<jml> lifeless: wassup?
<flacoste> hi lifeless
<lifeless> oh hai, I pinged, then remembered you're on leave now, right ?
<lifeless> so I mailed flacoste instead :)
<lifeless> flacoste: hi
<jml> lifeless: ok :)
<lifeless> so one thing I was very worried about in the bugjam was that we'd close stuff we shouldn't, and I've forwarded you a particular mail that triggered those fears, along with a plea for some guidance to the jammers
<lifeless> jml: I was wondering with your testtools open bug
<lifeless> jml: if it was a threading correctness issue that python-on-linux handles better
<Ursinha> hi abentley, is it possible to the owner of an mp to set its status to Approved? even if the person isn't a reviewer?
<lifeless> no
<abentley> Ursinha, no, and we certainly don't want it.
<lifeless> Ursinha: if this is for tarmac, its a problem - we need to be using the merge queues facility, not the old 'lands stuff that is approved' hack
<Ursinha> mars, ^
<Ursinha> abentley, I see I'm able to change the status of the mp to approved
<Ursinha> and I'm not a reviewer
<abentley> Ursinha, which mp?
<Ursinha> abentley, this one: https://code.launchpad.net/~ursinha/launchpad/add-ec2land-rules-orphaned-branches-no-conflicts/+merge/31386
<lifeless> Ursinha: you are
<Ursinha> lifeless, a launchpad reviewer?
<Ursinha> no
<lifeless> yup
<lifeless> Ursinha: yes, you are in ~launchpad
<lifeless> which is in ~canonical-launchpad-reviewers
<lifeless> and ~launchpad-reviewers
<Ursinha> lifeless, ~launchpad is a subgroup of the other two, and not the inverse?
<Ursinha> that makes no sense...
<lifeless> sure it does
<lifeless> as far as LP is concerned, all canonical lp staff are permitted to land things and review.
<lifeless> we use social glue for the process of learning, not technical.
<Ursinha> lifeless, right
<lifeless> maybe not optimal, but thats a different discussion.
<Ursinha> lifeless, this is for tarmac
<lifeless> as far as lp is concerned, you are a reviewer for lp:launchpad and lp:launchpad/db-devel/trunk
<Ursinha> we're discussing changing lp-land to set the mp to approved, so tarmac can handle it
<lifeless> tarmac shouldn't need that
<lifeless> with the merge queue stuff
<Ursinha> lifeless, is that implemented already?
<lifeless> and lp-land is the wrong time to set it, as aaron says.
<lifeless> Ursinha: I don't know. I shouldn't be here anyway :)
<abentley> Ursinha, lp-land is all about PQM.  Are you planning to make Tarmac read emails the way PQM does?
<EdwinGrubbs> lifeless: I was just going to ask if there was a workaround for when somebody forgets to use [rollback=] in the pqm commit message that was better than just marking the bug qa-untestable temporarily.
<lifeless> EdwinGrubbs: no; as you can see from abentley's excellent LEP we have a lot of polish to go on the deployment magic
<Ursinha> abentley, no, just use the same mechanism to make people able to be part of the simplify merge machinery beta
<lifeless> EdwinGrubbs: I deliberately closed my eyes and went 'lalalala' at the start, so that we'd have *some* deployments rather than still be building up infrastructure now :)
<lifeless> EdwinGrubbs: you just need to manually do the arithmetic when someone forgets a tag like that at the moment.
<EdwinGrubbs> ok, thanks
<abentley> Ursinha, Tarmac currently uses an "approved" review as a signal that it should perform a merge, right?
<Ursinha> abentley, I believe it uses the mp status
<abentley> Ursinha, I mean a status of "approved" on the whole proposal.
<Ursinha> abentley, ah, yes
<abentley> Ursinha, so this is not going to be any kind of smooth transition.  Because we don't use the Approved status that way.
<Ursinha> abentley, is the Approved status used in any way today?
<abentley> Ursinha, yes.  It's set when the last reviewer approves it.
<Ursinha> abentley, and what does that mean?
<abentley> Ursinha, it means that the reviewer has no major objections to landing it, but there may be some requested changes.
<Ursinha> abentley, wait, you're talking about the queue_status or the vote status?
<lifeless> queue status
<lifeless> well
<lifeless> mp status
<Ursinha> right
<lifeless> queue status is orthogonal
<abentley> Ursinha, I'm talking about the merge proposal status.
<Ursinha> that's the name of the property, I don't know why is that called this way
<lifeless> I'm going to leave this discussion in abentley's more than capable hands, and go play some wow. enjoy!
<abentley> Ursinha, we could change Tarmac, or we could change our practice.  I think changing our practice would be expedient.
<abentley> Ursinha, So we would be changing it such that the reviewer never marks it "Approved".  The submitter would do that.
<abentley> Ursinha, that would give them a window to make any suggested changes.
<abentley> Ursinha, and if the submitter isn't a reviewer, they would need to ask a reviewer to do that, just as they need to get a committer to land on PQM.
<abentley> Ursinha, But if we're changing our practice anyway, I don't see value in using lp-land to land merge proposals.
<Ursinha> abentley, right, so you suggest changing the practice by marking mps Approved with a different meaning, and doing that manually
<abentley> Ursinha, right.
<Ursinha> I agree lp-land isn't the right place to do that, we're trying to find more automated ways to test the smm changes
<abentley> Ursinha, lp-land only exists because pqm isn't well integrated with Launchpad.
<Ursinha> abentley, right
<lifeless> one final note
<lifeless> a team of 30 is slow to change
<Ursinha> lifeless, what do you suggest?
<lifeless> you may find that new instructions will not be followed immediately, so plan for that happening.
<lifeless> Ursinha: myself, I'd help rockstar finish merge queues.
<lifeless> My understanding was that that was the plan.
<abentley> lifeless, indeed, that is planned and will result in a better system.  Only question is "when".
<lifeless> anyhow, I only popped back to make that note about inertia; folk will do the old process for some time after a change is announced
<lifeless> so if the system would be fragile, were someone to do the old process, then thats a risk that needs some consideration.
<Ursinha> lifeless, one of the ideas of using ec2 land / bzr lp-land to set things up was to help with that, afaik
<abentley> Ursinha, the problem is that "Approved" is already being used with a laxer meaning.  If people follow current practise, lp-land can't help with that.
<abentley> Ursinha, because by the time they run "lp-land" the change will already be merged.
<Ursinha> abentley, right, got it
<deryck> benji, ping
<benji> hey deryck, what's up?
<deryck> benji, hey, is revno 12032 in devel users?  Something about smoke test script?
<benji> deryck: I'm afraid I can't parse the quesiton "is revno 12032 in devel users?"
<benji> revno 12032 does contain a librarian smoke test script
<deryck> benji, sorry I fail.  "yours" I meant.  Is it your rev in devel?  Did you land it?
<benji> oh, yes, I did
<deryck> benji, can I ask for qa from you for that? :-)  If it gets marked qa-ok, I can deploy a revno we need and get a feature out.
<benji> deryck: sure; I'd say that it's untestable, so I'll mark it thusly
<deryck> awesome.  easy peasy then.
<deryck> benji, thanks!
<benji> deryck: done
<deryck> cool
<wgrant> sinzui: Uh, how did my rev roll back yours? :/
<wgrant> It's not in the diff.
* flacoste changed the topic of #launchpad-dev to: Launchpad Development Channel | BUG JAM! | New starter this week: wgrant  | PQM open for business | firefighting: - | Get the code: https:/â/âdev.launchpad.net/âGetting
<wgrant> Morning all.
<mwhudson> morning
<mars> morning
<wallyworld_> abentley: thumper: mumble?
<abentley> wallyworld_, thumper may be delayed.
<abentley> wallyworld_, see his email.
<wallyworld_> abentley: ok. we can do it later
<wallyworld_> abentley: my stupid pulse audio was not working again too, so it's reboot time :-(
<jcsackett> sinzui: question for you on bug 684151. you say we can just change the name to remove '-secondary', but then won't it clash with the form instance at the top of the page?
<_mup_> Bug #684151: Search field at the bottom of a search results page never works <trivial> <launchpad-web:In Progress by jcsackett> <https://launchpad.net/bugs/684151>
<sinzui> jcsackett, no, field names are not unique
<sinzui> jcsackett, the error is making the names unique because the ids are unique
<sinzui> the ids do need to be unique
<jcsackett> sinzui: okay. question the second; how does one go about testing this, since the usual create_initialized_view and pass in "field.text" approach isn't sure to hit the right form?
<jcsackett> the only tests for this i see are launchpad-search-pages.txt, which all go via "+search", which isn't specific to the form being used. :-/
<sinzui> jcsackett,  get the second form by id and verify its input type="text" element have a sane name attr
<sinzui> jcsackett, It can be done using the beautiful soup instance returned by get_tag_by_id()
<jcsackett> ah, so just test the name instance, don't bother testing function from that form?
<jcsackett> that's much easier. :-P
<sinzui> jcsackett, Correct. We can test the contracts provide rather than the view's processing of the data
<jcsackett> sinzui: dig. thanks!
<thumper> well that took longer than expected
<spm> thumper: this is your haircut you left for, yesterday morning?
<thumper> spm: heh, no
<thumper> spm: my daughter's class was going for a walk this morning
<spm> oh lovely
<thumper> spm: and I went to help thinking it would be all over in 1.5 hours
<thumper> spm: but no
<spm> but no.
<thumper> spm: delayed further by a tree falling down on the route we took
#launchpad-dev 2010-12-14
<thumper> wallyworld: mumble?
<wallyworld> thumper: ok
<wallyworld> thumper: https://pastebin.canonical.com/40914/
<sinzui> wgrant, wallyworld ping
<sinzui> wgrant, wallyworld. I suspect the build that just started will fail. A test I landed broke when I merged tip. I landed a branch to reconcile the security change, but it was too late. I will try to stay up to restart the test if needed, but I am sick and do not trust myself.
<wallyworld> sinzui: i can have a look for you.
<wallyworld> sinzui: if it fails. you can go to bed if you like :-)
<sinzui> wallyworld, Since the revision missed the start, I think someone needs to land branch with testfix in it.
<sinzui> wallyworld, the branch can have a trivial text change
<wallyworld> sinzui: do you have the details you can tell me?
<sinzui> wallyworld, I may have my wits when the cold medicine wears off
<wallyworld> sinzui: ok. just let me know what you need me to do. i'll look out for any build failure
<lifeless> sinzui: if you have a fix already landed
<lifeless> sinzui: it will correct itself automaticallly
<lifeless> you need to land with [testfix] if the fix is not in the system.
<sinzui> lifeless, maybe I should find the trivial fix now and land a branch with [testfix].
<lifeless> sinzui: why? it sounds like you've already landed a branch with a fix?
<lifeless> ' I landed a branch to reconcile the security change'
<sinzui> lifeless, I did not land it with [testfix] because buildbot was not in testfix mode
<lifeless> sinzui: why does that matter?
<lifeless> sinzui: it *did* land, didn't it?
<sinzui> yes it landed
<lifeless> then bb will sort itself out
<lifeless> landing something with [testfix] now wouldn't stop us going into testfix mode.
<sinzui> lifeless, r12060 landed 30 minutes ago
<LPCIBot> Project devel build (292): FAILURE in 3 hr 11 min: https://hudson.wedontsleep.org/job/devel/292/
<LPCIBot> * Launchpad Patch Queue Manager: [r=abentley][ui=none][bug=669249][bug=151290] Remove
<LPCIBot> MailingListManager permission. Update the MailingList __repr__.
<LPCIBot> * Launchpad Patch Queue Manager: [r=EdwinGrubbs][ui=none][bug=645702] restore devel r11685 that was
<LPCIBot> lost in db-devel r9875.
<LPCIBot> * Launchpad Patch Queue Manager: [r=benji][ui=none][no-qa] Update lazr.restful to use the new version
<LPCIBot> with faster WADL generation.
<LPCIBot> * Launchpad Patch Queue Manager: [r=allenap][ui=none][bug=48464,
<LPCIBot> 305856] Move incoming mail handlers out of the canonical.launchpad
<LPCIBot> tree.
<LPCIBot> * Launchpad Patch Queue Manager: [r=henninge][ui=none][bug=687676] Allow registry admin to delete
<LPCIBot> teams with super teams.
<wgrant> What's the cowboy policy these days?
<lifeless> wgrant: if its a crisis, do it. + incident report
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project devel build (293): FIXED in 3 hr 11 min: https://hudson.wedontsleep.org/job/devel/293/
<LPCIBot> * Launchpad Patch Queue Manager: [r=sinzui][ui=none][no-qa] Added removeSecurityProxy to fix a test
<LPCIBot> that will break when another revision is merged.
<LPCIBot> * Launchpad Patch Queue Manager: [r=thumper][ui=none][bug=671262] Add filtering to built packages
<LPCIBot> listing to allow all recent builds or only those within last 30
<LPCIBot> days to be selected.
<LPCIBot> * Launchpad Patch Queue Manager: [r=abentley][ui=none][bug=683115] Fix bug 683115 by treating reported
<LPCIBot> Google totals of less than 0 as 0.
<LPCIBot> * Launchpad Patch Queue Manager: [r=abentley][ui=none][bug=48464] Treat target domains on incoming
<LPCIBot> mail without regard to case.
<_mup_> Bug #683115: ValueError raised getting length of batch results <oops> <qa-untestable> <Launchpad Foundations:In Progress by gary> < https://launchpad.net/bugs/683115 >
<lifeless> === Top 10 Time Out Counts by Page ID ===
<lifeless>     Hard / Soft  Page ID
<lifeless>      155 / 5598  Archive:+index
<lifeless>       82 /  258  BugTask:+index
<lifeless>       28 /  228  Distribution:+bugs
<lifeless>       14 /   13  Cve:+index
<lifeless>       12 /  117  ProjectGroupSet:CollectionResource:#project_groups
<lifeless>        7 /  229  Distribution:+bugtarget-portlet-bugfilters-stats
<lifeless>        7 /   22  DistroSeriesLanguage:+index
<lifeless>        5 /    7  ProjectGroup:+milestones
<lifeless>        4 /   71  Distribution:+bugs-index
<lifeless>        4 /    5  Person:+bugs
<bigjools> morning
<mrevell> Howdy bugjammers
<gmb> allenap: Am I remembering correctly when I think that bug-import.py has no tests?
<allenap> gmb: Je ne sais pas.
<gmb> allenap: Okay. I'm going to guess that there aren't any, since I don't remember ever seeing any.
<gmb> allenap: Or, there could be tests in, say, test_bugimport.py. Who'da thunk?
<allenap> gmb: Cool :)
<lifeless> gmb: it has tests
<gmb> lifeless: I know, I found them.
<gmb> grep FTW.
<lifeless> : )
<deryck> Morning, all.
<allenap> deryck, gmb: Have you encountered bug 86352 after a bug import this year? I haven't, so I'm tempted to close it Invalid or maybe Fix Released.
<_mup_> Bug #86352: SchoolTool imported bugs have invalid reporters <oops> <tech-debt> <Launchpad Bugs:Triaged> < https://launchpad.net/bugs/86352 >
 * deryck looks
<gmb> allenap: No, I haven't seen it as far as I recall.
<deryck> allenap, I haven't seen that either
<allenap> Cool, thanks.
* flacoste changed the topic of #launchpad-dev to: Launchpad Development Channel | BUG JAM! http://mumak.net/lp-bugjam-2010/ | New starter this week: wgrant  | PQM open for business | firefighting: - | Get the code: https:/â/âdev.launchpad.net/âGetting
* flacoste changed the topic of #launchpad-dev to: Launchpad Development Channel | BUG JAM! http://mumak.net/lp-bugjam-2010/ 33 so far | New starter this week: wgrant  | PQM open for business | firefighting: - | Get the code: https:/â/âdev.launchpad.net/âGetting
<jcsackett> sinzui: is there anything besides app/browser/stringformatter to work with on the linkifying?
<sinzui> jcsackett, I do not understand your question?
<jcsackett> sinzui: the linkifying code is restricted to the stringformatter file, right? just verifying what the find utility is telling me.
<jcsackett> sorry, the first version of my question is pretty ambiguous.
<sinzui> jcsackett, yes. it is registered as fmt:linkify I think
<jcsackett> sinzui: cool. thanks.
<jcsackett> sinzui: you were right about the regex. dang, that's a big one. :-P
<sinzui> There are some doctests that show the expect links and non-links
<sinzui> mrevell, ping
<mrevell> sinzui, hi
<sinzui> mrevell, My computer tells me I have an eye examine in 10 minutes. I cannot meet :(
<sinzui> mrevell, can we talk tomorrow at 16:30 UTC
<mrevell> sinzui, No problem. Good luck with the eye exam ... the answer is A E B U I O
<mrevell> :)
<flacoste> sinzui: https://lpbuildbot.canonical.com/builders/lucid_lp/builds/436/steps/shell_6/logs/summary
<lifeless> flacoste: ping
<wallyworld_> abentley: thumper: mumble?
<wgrant> Does anyone know what's going on with bug #629804? It was marked qa-bad four days ago, and nothing's happened since.
<_mup_> Bug #629804: remove workaround for private Librarian files for launchpadlib clients <qa-bad> <Launchpad Foundations:In Progress by lifeless> < https://launchpad.net/bugs/629804 >
<thumper> wgrant: sorry, no
<lifeless> wgrant: read abels comments, sounds like it needss more work
<lifeless> wgrant: roll it back, see the dev wiki for howto
<wgrant> lifeless: Or I guess I could fix it.
<lifeless> wgrant: yes!
<elmo> don't you have to fix that timeout lifeless keeps whinging about first? ;-)
<wgrant> I fixed that last week.
<wgrant> This bug is blocking the rollout :P
<lifeless> wgrant: I would rollback
<lifeless> wgrant: and fix
<lifeless> but the rollback can be shipped of immediately
<lifeless> and will unblock things.
<lifeless> We should rollback more often.
 * StevenK rollbacks to rev1
<poolie> hi all
<wgrant> Morning poolie.
<poolie> >>  we
<poolie> didn't consider that a cronjob needs to get credentials without any user
<poolie> input.
<poolie> seriously?
<wgrant> I'm pretty sure that is the most common use-case.
<james_w> "...the first time you run it I assume."
<james_w> get an request token and exchange it for an access token without user input
<james_w> I don't believe they would be planning to require user input on every use of launchpadlib
<poolie> it's bug 686690
<_mup_> Bug #686690: 1.8.0 breaks login_with() API compat with existing credentials files, and forces keyrings <desktop-integration> <regression> <launchpadlib :Triaged by benji> < https://launchpad.net/bugs/686690 >
<poolie> iiuc they ... well, the subject is pretty selfexplanatory
<poolie> it makes it hard to use noninteractively
<james_w> ah, sorry, I remembered that phrase occurring later in the conversation
<poolie> i was just reading the thread now
<poolie> i guess the end state is ok
#launchpad-dev 2010-12-15
<thumper> mwhudson: ping
<mwhudson> thumper: pong
<thumper> mwhudson: remember that RT we had ages ago for a machine to test multiple codehosting front ends talking NFS?
<thumper> mwhudson: feel like getting involved with the testing of said issue?
<mwhudson> thumper: yeah, i'm subscribed to the RT
<mwhudson> i wouldn't have a problem getting involved, i should probably ask linaro management if they do though :-)
<thumper> mwhudson: ok
<thumper> mwhudson: we want to test it but I don't have the resources to put people on it right now :-(
<james_w> what do you estimate the investment to be?
<james_w> and what do we get out of it?
<thumper> we get better front end scalability for codehosting connections
<thumper> and kill a single point of failure
<thumper> not sure on time estimate
<lifeless> more tolerance of high load
<thumper> I'm not sure on the time investment
<thumper> I have a feeling that mwhudson would be able to give a better guess than me
<lifeless> less downtime
<mwhudson> simple testing should be simple
<lifeless> [rephrased]
<james_w> heh
<mwhudson> if it all works fine, it's not long
<mwhudson> although i don't know how one would test production like load safely
<james_w> IS have provided the test rig, it's just hammering on it for a while?
<mwhudson> yeah, & figuring out details of deployment i guess
<james_w> sounds like something we can invest in, because I can certainly see the appeal
<james_w> obviously if it starts to escalate we will have to look again
<mwhudson> is jam's forking service stuff deployed yet?
<spiv> I don't think so
<thumper> mwhudson: I don't think it is being used yet
<thumper> merged but unused
<mwhudson> :(
<mwhudson> somewhat tangential to the issue at hand of course
<mwhudson> james_w: so you'd be ok with me spending tomorrow morning say on this?
<james_w> mwhudson, sure. Let me know if it adds up to more than a day of your time.
<mwhudson> tbh, i'm a little bit unsure what to work on as i have less than 2.5 days work left before being off for xmas, seems a bad time to start something big
<james_w> yeah, this seems like a good stocking filler
<james_w> though I might advocate for getting the dead code in use and only tackling one big infrastructure change at a time
<spiv> I think jam's thing is stuck at RT 42199, the qastaging for it?
<lifeless> james_w: have you become a team lead ?
<james_w> lifeless, yes, but things are still in flux
<lifeless> congrats
<stub> Anyone else looking at the devel->db-devel conflict?
<poolie> hi lifeless
<poolie> and stub
<stub> yo
<poolie> thumper: are you around?
<thumper> yeah
<poolie> do any of you want to talk to me about bug 605775, and showing file content within loggerhead?
<_mup_> Bug #605775: Loggerhead doesn't support linking to the raw content <loggerhead:In Progress by mkanat> < https://launchpad.net/bugs/605775 >
<poolie> i'm wondering what fits best in lp
<poolie> i guess i should go by analogy to bug attachments which is that we'll serve anything, but we must serve it from a separate domain
<poolie> to avoid/reduce xss
<thumper> poolie: I think that the option defined at the end of 2) to only support text/plain or application/octet-stream should mitigate the need for a separate domain
<thumper> is ok
<thumper> poolie: or at least have it a configurable option
<thumper> as some people may want to run loggerhead locally and have it serve images
<thumper> but launchpad doesn't
<thumper> although...
<thumper> if we did get around to adding wikkid into LP there would be similar problems
<thumper> perhaps we don't care that much?
<poolie> which "2"?
<poolie> oh, i see
<poolie> you have to pick from the list in my last post though :)
<thumper> I was referring to the description
<thumper> I haven't read the entire thread
<thumper> is it necessary?
<poolie> probably not
<poolie> i kinda feel someone wearing a security hat ought to agree to it
<thumper> agreed
<thumper> depending on the size of the hat, you might get different answers :)
<lifeless> thumper: applicaiton-octet stream is insecure and must not be used the lp domains
<lifeless> (for user supplied content)
<thumper> poolie: see...
<lifeless> s/the/in the/
<poolie> yes, i know
<poolie> i'm trying to decide on the best alternative
<lifeless> I thought I put it in the bug already
<thumper> I didn't read the entire thread
<lifeless> ah, I think my comments were in the merge proposal
<poolie> you commented on the bug
<lifeless> https://code.launchpad.net/~mkanat/loggerhead/raw-controller/+merge/42675
<lifeless> is where I linked to the documented ie behaviour
<lifeless> anyhoo, I'm not here today. ciao
<poolie> so we agree on lp we will only serve them from a separate domain?
<poolie> ciao
<mwhudson> well
<mwhudson> oh nm
<mwhudson> showing raw content from private branches also sounds fun
<mwhudson> probably needs a different hostname per branch or something :/
<wgrant> Like we do for the restricted librarian.
<mwhudson> yeah, and for the same reasons
<wgrant> The Web is bad.
<wgrant> :(
<mwhudson> maybe we can use websockets somehow
<mwhudson> (note: heavy sarcasm)
<thumper> this all just makes me want to cry
<thumper> if only people decided not to be evil
<thumper> the world would be a nicer place
 * thumper relocates back to his home
<poolie> ok, we'll do the same as there
<lifeless> poolie: its a little complex to do right now
<lifeless> by do, I mean discuss
<lifeless> as mwhudson and wgrant are talking about
<mwhudson> refusing to do it for private branches at all is an option too
<lifeless> poolie: my suggestion to mkanat to get a discussion going in the lp dev list remains as my best suggestion for moving forward
<poolie> i agree too
<lifeless> I'm sure that if a proposal gets forged in that fire, it will be rock solid
<wgrant> We need an insecure domain.
<lifeless> I'm worried that landing an unsafe branch on trunk will make trunk un-upgradable to by LP
<wgrant> To stick stuff like the librarian and branches under.
<lifeless> wgrant: launchpadlibrarian.net :P
<poolie> i am not going to let him land something that is unsafe by default
<mwhudson> wgrant: the problem is not the insecure domain
<lifeless> coolio
<poolie> even for non-lp users i think that would be a poor choice
<lifeless> have fun y'all
<mwhudson> wgrant: the problems are the "slightly secure" domains
<wgrant> mwhudson: Right, but we sitll need an insecure domain.
<mwhudson> let's confused the user and use lauchpad.net
<StevenK> Even mis-spelt?
<poolie> thanks for your contribution
<poolie> :P
<stub> thumper: Even if we restrict what mimetypes or extensions we serve from the Librarian, we want it on a separate domain because web browsers have bugs.
<spm> StevenK: wgrant: thee builder scores for PPA's - are they meaningless these days? or still relevant? istr some discussion a while back about no longer using those. ?
<wgrant> spm: They're still relevant.
<wgrant> We don't want to use them.
<wgrant> But there's nothing else yet.
<StevenK> We just can't stop
<StevenK> Right, because that
<StevenK> spm: Someone is asking for a bump?
<spm> well no. someone has a bump already - 12K and counting. but apparently not being built.
<spm> that's a built in bump. I've not touched a thing.
<wgrant> Hmm.
<wgrant> We are running low on buildds.
<wgrant> And there are some long builds running.
<poolie> i'll do a patch for rlimits
<poolie> spm i think robert would agree that if you have to kill/restart things by hand, there's at least two bugs
<poolie> one underlying bug and one that it's not killed automaticalyl
<mwhudson> launchpad is pretty hostile to the casual developer
<spm> poolie: agreed. I did like the idea of the feature flag - but accept the challenges there :-/
<mwhudson> i guess this isn't really news
<poolie> spm do you have any idea what would be a reasonable limit? how much ram does that machine have?
<poolie> shall we say 3G? or 2G?
<spm> 64K?
<poolie> things were easier then
<spm> it has 8, but shares with some very big, and slow processes. it's not a single thing that gets bad per-se, it's the multiples that make it struggle.
<spm> I'd aim for 1.2->1.5, and see how often we abort. work from that?? (to open negotiations)
<poolie> ok
<poolie> this is another case where it would be great to set rlimits through flags so they could be tweaked
<poolie> one step at a time
<spm> istr mwhudson did similar with the other whatsits, try and find a sweet point.
<spm> actually....
<spm> I can have a look thru the last week and *give* you an idea of how much is normal.
<poolie> doing new code rollouts seems like a tedious way to titrate it
<spm> right
<mwhudson> wallyworld: wow, that's a strange test failure
<wallyworld> mwhudson: yeah :-(
<mwhudson> wallyworld: i think i know the problem though: for the tests in TestPullerMonitorProtocol, TestCase.setUp is being called twice
<wallyworld> any ideas?
<mwhudson> wallyworld: why this causes the symptoms it does.... no idea
<wallyworld> oh
<wallyworld> mwhudson: i'll just switch back to that branch and have a look
<mwhudson> wallyworld: it's something like, the testcase's _recordOops method is registered as an @adapter(ErrorReportEvent)
<mwhudson> wallyworld: and something about registering it twice means that it doesn't get deregistered properly
<wallyworld> mwhudson: well, removing the dup setup worked \o/
<wallyworld> i was too busy looking for something non obvious and complicated :-)
<wallyworld> thanks for finding it :-)
<mwhudson> well, it was a good one for a set of fresh eyes i think
<mwhudson> wallyworld: duplicating the line
<mwhudson>         self.useFixture(ZopeEventHandlerFixture(self._recordOops))
<mwhudson> in TestCase.setUp brings the error back
<wallyworld> ok. interesting that it hasn't come up before now
<mwhudson> yeah
 * wallyworld fires up ec2 again :-)
<mwhudson> i would like to know why the failure mode is just that strange
<mwhudson> but i would also like to go home and have dinner
<poolie> mwhudson: https://code.launchpad.net/~mbp/launchpad/690021-rlimit/+merge/43733
<poolie> but don't let it spoil/delay your dinner
<wallyworld> mwhudson: enjoy your dinner. thanks again :-)
<mwhudson> poolie: approved, you'll need to find someone else to land it though
<mwhudson> (unless you can do that now?)
<poolie> i probably have permission; i might need some hand holding
<poolie> are there black box tests for this?
<poolie> or, can i interactively test it?
 * mwhudson points poolie at wallyworld :-)
<mwhudson> poolie: yeah, there are blackbox tests
 * wallyworld looks
<wallyworld> poolie: i can help you land it but am not sure about testing it
<poolie> i will see what i can do
 * poolie fights with source code
<LPCIBot> Project db-devel build (217): FAILURE in 3 hr 34 min: https://hudson.wedontsleep.org/job/db-devel/217/
 * StevenK glares at Hudson
 * wgrant glares back at StevenK.
<wgrant> You borked it!
<wgrant> Although I was watching :(
<LPCIBot> Project db-devel build (218): ABORTED in 12 min: https://hudson.wedontsleep.org/job/db-devel/218/
<LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12071,
<LPCIBot> 12072 included.
<spm> poolie: "<spm> I can have a look thru the last week and *give* you an idea of how much is normal." <== 99.55% are < 400Mb. 99.90% < 800Mb. then it jumps into crazy territory. I'd suggest starting with 600Mb.
<poolie> spm, ok
<poolie> so i put it up at 2gb
<spm> shrug that works.
<lifeless> === Top 10 Time Out Counts by Page ID ===
<lifeless>     Hard / Soft  Page ID
<lifeless>       30 /  173  BugTask:+index
<lifeless>       10 /  112  ProjectGroupSet:CollectionResource:#project_groups
<lifeless>        9 / 2622  Archive:+index
<lifeless>        9 /  230  Distribution:+bugs
<lifeless>        7 /  235  Distribution:+bugtarget-portlet-bugfilters-stats
<lifeless>        6 /   16  Archive:+copy-packages
<lifeless>        6 /    7  Person:+bugs
<lifeless>        5 /  195  POFile:+translate
<lifeless>        5 /    6  ProjectGroup:+milestones
<lifeless>        4 /    0  https://api.edge.launchpad.net
<jelmer> 'morning
<spm> heya jelmer!
<lifeless> wgrant: bug 690484 is a dup of #?
<_mup_> Bug #690484: "Start in 1 minute" shown for hours despite 12505 points <Soyuz:New> < https://launchpad.net/bugs/690484 >
<wgrant> lifeless: It may not be a dupe.
<wgrant> The underlying problem was not fixable until very recently.
<spm> lifeless: there's a basic summary in #is from about 90 mins ago. fwiw.
<lifeless> wgrant: I thought there was a bug for queue estimating already
<lifeless> oh, I see
<lifeless> PEBCAK
<wgrant> It's not really an estimate issue.
<spm> right. it's not an estimate problem.
<wgrant> It's publisher latency + people clicking things that they shouldn't.
<lifeless> so, someone will updates it?
<spm> if anything the estimate was accurate.
<wgrant> I will talk to Julian about it this evening.
<spm> just... wrong. :-)
<wgrant> Since it's now feasible to fix.
<spm> wgrant: so the estimate would be "Never. This PPA is unable to publish" or words similar?
<wgrant> spm: No -- private PPAs need no longer wait for publication.
<spm> ah. even better.
<wgrant> They can use the public restricted librarian.
<poolie> hy bryce
<poolie> how do i actually land something through pqm?
<poolie> i don't need ec2 testing
<wgrant> bzr lp-land, or bzr pqm-submit.
<wgrant> lp-land takes an MP, pqm-submit requires you to specify the source, destination and commit message manually.
<poolie> ok
<poolie> bryceh: so my current theory as i said in mail is that for some tests there are two database connections present
<poolie> and two transactions
<bryceh> ok
<poolie> this may be bs
<poolie> i was hoping someone would answer that it was true :)
<bryceh> poolie, http://pastebin.com/JFiz4mga
<bryceh> wait, nevermind that
<bryceh> (ran the wrong test)
<poolie> iow i'm wondering if the test is running in a different storm context from the code under test
<poolie> or something like that
<bryceh> here we go - http://pastebin.com/UghMbtsJ
<poolie> bear in mind it's only installed per-thread
<bryceh> note down towards the bottom Features: {'bugtracker_components': None}
<bryceh> I assume that should show as something other than None once the feature flag is seen
<poolie> right
<poolie> that does show that at least your template/view checked the flag
<poolie> in -1 seconds!
<poolie> way to go
<bryceh> hehe
<poolie> i see that create_view does setFirstLayer etc
<poolie> i wonder if that gives it a new db connection?
<poolie> or maybe this is a different kind of layer?
<bryceh> I tried doing this, but same error:
<bryceh> Store.of(self.bug_tracker).add(FeatureFlag(
<bryceh>                 scope=u'default', flag=u'bugtracker_components',
<bryceh>                 value=u'on', priority=1))
<poolie> hm
<poolie> actually if my theory is true you'd expect that no uncommitted changes are seen by the view
<poolie> but in fact it's very common that they all are
<poolie> can you make your view print its threadid and print the tid from the test code?
<bryceh> you mean like:
<bryceh>         print view.threadid
<bryceh>         print self.tid
<bryceh> ?
<poolie> no i think
<poolie> threading.currentThread()
<bryceh> _MainThread(MainThread, started -1219778880)
<poolie> the same in both?
<bryceh> hmm, I can't figure out how to get the view to print its threadid
<poolie> ok
<poolie> bryceh: i need to go and cook
<poolie> the next thing i would try is to get all the feature control rules
<poolie> and see if there is one in there that's not being bmatched
<poolie> ok good night all
<poolie> bryceh: if you learn anything else (or don't), please send a followup to the dev list
<bryceh> poolie, ok thanks for trying
<poolie> oh you could also search the archives
<bryceh> this feature flag stuff has been a huge headache
<poolie> somebody, maybe deryck, hit something similar before
<poolie> sorry :(
<poolie> for testing, or generally?
<bryceh> generally
<poolie> if you can send a mail explaining where the problems have been i'd appreciate it
<bryceh> was hard to figure out how to get it set up and working in the first place, now its hard to figure out how to get it to work in tests
<bryceh> poolie, that's easy - the documentation is really confusing
<poolie> ok, that should be fixable then
<poolie> anything else?
<poolie> well, if you think of anything, let me know
<thumper> wallyworld_: ping
<wallyworld_> thumper: hi.
<thumper> wallyworld_: https://code.qastaging.launchpad.net/+daily-builds
<thumper> wallyworld_: can you land a patch rs=me to remove the distro from the first column?
<wallyworld_> i know. the filtering doesn't work :-(
<thumper> wallyworld_: just the distribution fmt:link
<wallyworld_> i'm fixing it now
<thumper> wallyworld_: this isn't the filtering
<wallyworld_> i'll include your change in the same branch
<thumper> wallyworld_: thanks
<wallyworld_> yeah, i was just letting you know i was already looking at it
<wallyworld_> i'll do it tonight and the mp will be in your inbox tonmorrow morning
<wallyworld_> thumper: i assume the distro is to be removed because it's always Ubuntu?
<thumper> wallyworld_: yep
<thumper> wallyworld_: perhaps in the future if it isn't always ubuntu, we may change it
<wallyworld_> thumper: i was just typing that question :-)
<thumper> :)
<wallyworld_> thumper: mw found the codehosting issue too :-)
<thumper> wallyworld_: awesome
<thumper> mwhudson: I owe you a drink next time we are together in the same place :)
<wallyworld_> thumper:  there was a bad test that called setup twice - been there a while, unrelated to my changes. not sure why it showed up the way it did
<thumper> oh well
<thumper> good to clean it up
<wallyworld_> yep. it's in ec2 again as we speak. it was such a simple error - i was looking for something really complicated
<thumper> :)
 * thumper afk again
<wallyworld_> wood, tree and all that
<mrevell> Hello
<wgrant> Does anybody have any objections to a reversion of r12041 (the Bugs restricted LFA API change, which has been qa-bad and untouched for four days)?
<gmb> wgrant: ISTR abel doing some work on that, but he's got a bad back and won't be working for the rest of the week. Probably best to check with deryck, who I think knows what's happening there.
<wgrant> gmb: k, was wondering where he was.
<wgrant> Thanks.
<wgrant> Will check with deryck when he appears.
<gmb> Cool.
<jelmer> has anybody else tried ec2 land in natty yet? From the first look of it it looks broken here.
<wgrant> I was going to upgrade this weekend. Maybe I should not.
<gmb> Anyone know off the top of their heads how I can persuade a widget to sprout a tabindex? Or should I just poke around until Zope blows up in my face, as usually happens with widgety things.
<gmb> Nice. I'm so smart I ask the question and then /part the channel. I'm obviously going to have a winner of a day.
 * gmb decides to just go an shove things in templates. It works better.
<wgrant> As long as you don't use BeautifulSoup...
<wgrant> Do we have reports of script runtimes somewhere?
<gmb> Ah, BeautifulSoup, the thing that made syncing with Sourceforge possible for a short while.
<wgrant> IIRC it was also involved in generation of the code import registration form.
<gmb> wgrant: IDK; mthaddon might know. There may be something at https://lpstats.canonical.com.
<mthaddon> we don't - it's in the DB, but I don't believe we graph it
<mthaddon> (scriptactivity table)
<wgrant> Hmm.
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project db-devel build (219): FIXED in 3 hr 35 min: https://hudson.wedontsleep.org/job/db-devel/219/
<allenap`> gmb: Do you know what the deal is with revision 12041 on https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html?
<gmb> allenap`: wgrant already wondered about that. I don't know where abel was up to with fixing it. deryck might; if it's okay with him we'll back it out.
<wgrant> gmb: It turns out that bigjools managed to get a rev after it rolled out anyway, so I am no longer strongly desiring its removal.
<gmb> wgrant: Righto. Worth pursuing anyway, elsewise it'll make things confusing.
<bigjools> there was a rev that backed it out, no?
<lifeless> bigjools: I sure hope so, or apport is broke again :)
<wgrant> It was only rolled out to Soyuz.
<wgrant> It's not been rolled back, AFAICT.
<deryck> Morning, all.
<stub> Is the thing that generates diffs for merge proposals single threaded? No update for 8 mins on https://code.launchpad.net/~stub/launchpad/pending-db-changes/+merge/43763
<jelmer> fwiw that MP still hasn't been updated - and it's 39 minutes ago now
* flacoste changed the topic of #launchpad-dev to: Launchpad Development Channel | BUG JAM! http://mumak.net/lp-bugjam-2010/ 35 so far | New starter this week: wgrant  | PQM open for business | firefighting: - | Get the code: https:/â/âdev.launchpad.net/âGetting
<bac> abentley, adeuring, allenap , bac, benji, danilo, sinzui, deryck, EdwinGrubbs, flacoste, gary, gmb, henninge, jelmer, jcsackett, jtv, bigjools, leonard, mars, mrevell: Reviewers Meeting ping
<deryck> ack, thanks for the ping
 * gary_poster is ready with my "me"
<bac> allenap`: ^^
<allenap> Thanks bac.
<mrevell> Hey sinzui, do you have time for our call now?
<sinzui> mrevell, I will be free in a few minutes
 * sinzui otp
<mrevell> np
<gmb> gary_poster: Do you know if it's possible to give a widget or action button a tabindex using Zope? (Sorry if that's repeated; I lost conn)
<gmb> gary_poster: I'm asking in the context of https://bugs.launchpad.net/malone/+bug/558419
<_mup_> Bug #558419: +filebug page really should have tabindex for "Submit Bug Report" Button <bugjam2010> <dhrb> <escalated> <story-ajaxify-dupe-finder> <Launchpad Bugs:In Progress by gmb> < https://launchpad.net/bugs/558419 >
<gary_poster> gmb: I'm pretty sure it is one of the knobs.  Lemme see if see any docs...
<sinzui> mrevell, mumble
<gmb> gary_poster: Thanks.
<gary_poster> gmb: "extra" is a string that is just dumped in the widget tag, I believe.  you can set it up with the usual customwidget bits
<gary_poster> is that enough to get you going, or should I try for more detail? :-)
<gmb> gary_poster: Brilliant, thanks for the tip.
<gary_poster> cool
<gmb> gary_poster: That's fine. I'll poke around til something works - or breaks.
<gary_poster> :-)
<bigjools> flacoste: so I am not sure after that call as to whether jml's bugjam counter is looking for the tag or not, what was the consensus?
<flacoste> bigjools: sinzui thinks it is, i'm not sure
<flacoste> bigjools: looking at the code would clear doubts
<flacoste> but i'm not sure where the code lives
<bigjools> it would. but ... exactly
<flacoste> putting the tag on is safe anyway
<bigjools> where is it running
<flacoste> and good practices
<flacoste> on his server i think
<flacoste> it's on mumak.net
<flacoste> an API script
<bigjools> yeah, I just went through 20-odd bugs adding the tag
<bigjools> let's see if the count changes
<flacoste> bigjools: it doesn't to seem to run that often either
<flacoste> but we'll see
<bigjools> and on that note, it's good night from me
<beuno> abentley, hai! I wants lp-propose!  where do I get it from?
<jelmer> beuno: it's in the launchpad plugin
<jelmer> so if you have bzr you should have itg
<jelmer> s/itg/it/
<beuno> orly?
<beuno> zomg!
<beuno> that is awesome
<beuno> thanks jelmer
<gary_poster> gmb: hoping to have a bugs team review on a revert I'm doing of an adeuring branch.  You happen to be around for such a thing?  I think you are the only candidate
<thumper> abentley: ping?
<abentley> thumper, pong
<thumper> abentley: mumble?
<lifeless> flacoste: win: https://bugs.launchpad.net/launchpad/
<flacoste> lifeless: nearly complete
<flacoste> lifeless: now it's complete!
<flacoste> blog post and identi.ca updated
<wgrant> ... I didn't think that was happening yet.
<flacoste> it's actually 5 days late
<flacoste> was supposed to happen before the opening of the Jam
<thumper> poolie: you'll be happy to know I've just fixed bug 523019 for the bugjam
<_mup_> Bug #523019: can't save comment on mp til you click in the text field <ajax> <chrome> <code-review> <confusing-ui> <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/523019 >
<poolie> nice
<wgrant> jelmer: Hi.
<jelmer> wgrant: g'morning
<wgrant> jelmer: Evening.
<wgrant> jelmer: How is SyncPackageJob going?
<jelmer> wgrant: tagged needs-landing
<jelmer> wgrant, I've been almost done with it for about a week but keep being interrupted by other things
<wgrant> jelmer: How usable will it be for Debian->Ubuntu in the near future?
<jelmer> wgrant, The UI won't be relevant, but I've created the actual job with Debian->Ubuntu syncs in mind.
<poolie> jelmer, we should talk sometime before christmas
<poolie> but, i see it's late for you now - maybe tomorrow morning your time, or next week?
<poolie> i'm going to be on leave tomorrow (just for friday)
<jelmer> poolie: now would be fine actually, I'll probably be around for another hour
<jelmer> poolie, but I'll be around next week as well
<wgrant> jelmer: OK, great.
<poolie> jelmer: irc/skype/pots/mumble/..?
<jelmer> mumble ?
<poolie> great
<bac> thumper, mwhudson, stevenk, wallyworld, wgrant: reviewers meeting?
#launchpad-dev 2010-12-16
<wallyworld> bac: ack
<StevenK> bac: Sorry, we were afk discussing a feature
<wallyworld> do i recall correctly that there is no need for GoogleServiceLayer anymore? ie we are not using any google apis anywhere?
<wgrant> We still use it for search.
<wgrant> Just not for maps.
<wallyworld> ok. thanks. a test i was running timeout out waiting for setup() so i was just wondering
<poolie> can someone answer out of hand abentley's question on https://code.edge.launchpad.net/~mbp/launchpad/690021-rlimit/+merge/43733
<poolie> if a scan branches job aborts unexpected (is killed by rlimit) what will happen?
<poolie> will the jobs be failed, or re-run?
<poolie> wallyworld: ^^ do you know?
<wallyworld> poolie: i think any branches that haven't been scanned yet would need to be rescanned, but i'm not 100%
<wallyworld> poolie: the scan branches job is just a cron script so shouldn;t any branches not scanned when the job is killed be picked up next time the job is run?
<poolie> i would have thought so
<poolie> i guess they may just fail repeatedly
<poolie> if it scans multiple branches in a single process invocation this might mean that we get stuck with none being scanned?
<poolie> this is probably still an improvement over the whole machine bogging down though
<wallyworld> i'm wondering about the same thing myself
<wallyworld> poolie: each python BranchScanJob instance works on a single branch but i'm not sure how these are invoked from the calling script ie if one fails, does it continue with the others
 * poolie looks
<poolie> yeah it's not obvious to me yet
<poolie> it looks to me like if we kill the process, it will still be seen as running
<poolie> oh i guess we could just look at what has actually happened recently to the scanner
<poolie> i don't suppose there are docs of the lp jobs system?
<poolie> ah, some in https://dev.launchpad.net/Foundations/JobSystem
<wallyworld> poolie: tim would be able to provide an immediate answer but he is away till monday
<poolie> i will request a review from him and sit on this until then
 * wallyworld sad - lost power, huge thunder storm, limited internet connectivity :-(
<spiv> wallyworld: http://www.bom.gov.au/products/IDN65152.shtml has a fun diagram
<mwhudson> heh yes
<wallyworld> spiv: yeah, and my wife has the car and it can't be put under cover :-(
<wallyworld> lucky i got a 3G modem for these type of emergencies
<wallyworld> the rain here is pissing down
<wgrant> "This thunderstorm is very dangerous"
<wgrant> Not something I thought I'd hear from the BoM.
<spm> wallyworld: aarnet lost au.mirror... so you're not alone
<wallyworld> spm: sucks for them and me :-(
<wgrant> I want a storm :(
<wgrant> Maybe not quite that big.
<wgrant> But it's getting disappointingly warm down here.
<wgrant> lifeless: Hah, I win. Soyuz is out of the top-10 timeouts.
<wallyworld> wgrant: where are you?
<wgrant> I am safe for now.
<wgrant> wallyworld: Melbourne.
<wgrant> it's been nice and rainy the last couple of weeks.
<wgrant> But this week is fairly warm.
<poolie> huge thunderstorm here too
<wallyworld> wgrant: well you know what they say about mne - 4 seasons in one day - careful what you wish for
<poolie> *by sydney standards, would be a shower in bne
<wgrant> True, true.
<wallyworld> poolie: :-)
<wallyworld> worst part about having no power - it's way past my afternoon coffee time :-(
<StevenK> wallyworld: Coffee shop?
<wallyworld> i think the whole suburb is out
<wallyworld> it would be a looong drive and the window doesn't win up properly on my 2nd car which is a bomb
<wallyworld> s/win/wind
<lifeless> wgrant: till jan 17th
<wgrant> lifeless: :(
<lifeless> wgrant: something real small would be to add a garbo job populating bugmessage.index
<wgrant> lifeless: Sadly Steve and I hae something real big.
<lifeless> fun times!
<wgrant> s/hae/ha[tv]e/
<StevenK> Hate seems more appropos
<StevenK> apropos, even
 * wallyworld about to disappear. laptop battery almost dead :-(
 * nigelb congratulates lp folks on new team structure :)
<poolie> :)
<wgrant> wallyworld: You have power again?
<wallyworld> wgrant: yeah. i decded to go out and find a coffee shop with power (there were several suburbs without) and when I got back, it was on again \o/
<wallyworld> just turned out the cricket to take a peek - not good for us :-(
<wgrant> Excellent!
<wgrant> And I don't care about cricket :P
<wallyworld> what? shame on you!
<mrevell> Hi
<danilos> bigjools, hi, do you have a minute to chat about bug 685624?
<_mup_> Bug #685624: Translation template build jobs should use the new BuildFarmJob <lp-soyuz> <lp-translations> <Launchpad itself:New> < https://launchpad.net/bugs/685624 >
<bigjools> danilos: 60 seconds and counting
<henninge> danilos: I was just about to ping you ...
<danilos> bigjools, I am hoping for a mumble chat
<bigjools> danilos: ok give me 5 mins
<danilos> henninge, should be quick, I am on a countdown
<danilos> henninge, heh, so, what's up with you while I am on hold for Julian? :)
<henninge> danilos: the test for setCurrentTranslation is failing and i don't understand why this is supposed to work this way.
<danilos> henninge, I am guessing because of makeCurrentUbuntu/makeCurrentUpstream changes
<henninge> danilos: no, it is related to my "fix" in setCurrentTranslation I believe.
<danilos> henninge, oh, you should not have changed setCurrentTranslation lightly
<henninge> danilos: line 183 in test_setcurrenttranslation.
<henninge> danilos: well, it is pretty isolated to other_side sharing but that is what is failing now.
<danilos> henninge, some of the decisions in setCurrentTranslations are relatively arbitrary (i.e. we could have gone either way since it doesn't matter too much), but most of the critical ones are not
<henninge> danilos: I don't understand why "the sharing policy has no effect"
<danilos> henninge, I'll have to thing carefully about this particular case though
<henninge> danilos: please do ;)
<danilos> henninge, so, just to confirm we are looking at the same thing, it's test_c_None__n_None__o_shared__follows
<henninge> right
<henninge> danilos: but there are a couple more failing
<henninge> danilos: all with "__follows"
<henninge> that's what sets "share_with_other_side" on setCurrentTranslation
<henninge> sets to *True*, obviously
<bigjools> danilos: wake up
<danilos> bigjools, coming
<danilos> henninge, be right back
<deryck> Morning, all.
<danilos> henninge, ok, back to you
<danilos> henninge, well, you did invert the logic in setCurrentTranslation completely for a few things :)
<danilos> henninge, well, maybe not
<danilos> henninge, I see you tried to move makeCurrent stuff into it though
<henninge> danilos: what do you mean?
<danilos> henninge, btw, I think your change for translation credits is wrong as well: translation credits does need to read explicitely from the upstream side
<danilos> henninge, well, unsetting of the flag that makeCurrent* methods used to do
<danilos> henninge, so, here's what I think we should do: keep makeCurrent* methods and switch them to the new model by using explicit UPSTREAM for getImportedTM and UBUNTU for getCurrentTM methods
<danilos> henninge, note that we should not make those calls side-sensitive since it's obvious makeCurrent methods are already using the new model (just like the translation credits message is)
<danilos> henninge, they are only using getCurrent/getImportedTM methods in a low-level way (explicit side requests, not expecting them to be side-aware)
<henninge> danilos: hm, getCurrentTM *is* explicit about sides anyway.
<henninge> danilos: I am not sure about keeping makeCurrent around.
<henninge> danilos: I just think that my change to setCurrentTranslation was not correct
<danilos> henninge, well, makeCurrent* is directly used by setCurrentTranslation (I didn't know that), which means that it's an integral part of the setCurrentTranslation design
<danilos> henninge, please, don't try to fix setCurrentTranslation *now*
<danilos> henninge, if you remember, we spent days on designing, implementing and providing tests for it
<danilos> henninge, so, if shareIfPossible and makeCurrent* are used by it, they are "new model" methods and we should keep them
<henninge> danilos: but I, too, remember that makeCurrent* was a temporary solution.
<danilos> henninge, perhaps, but as a step from, if you remember, DB triggers!
<danilos> henninge, they are still improvement enough over DB triggers
<danilos> henninge, and we can worry about getting rid of them later, they are not critical and require much careful consideration which I'd rather not do right now :)
<danilos> henninge, if you feel you can do that, make sure you do it without changing any setcurrenttranslation tests :)
<henninge> danilos: well, I see which part of my change makes that test fail.
<henninge> I just still don't understand why it's supposed  to work this way.
<danilos> henninge, and make sure you back out this change: https://pastebin.canonical.com/41104/
<danilos> henninge, the problem with how setCurrentTranslation is supposed to work is that it has many different conditions and they are hard to get unless you consider the whole picture
<henninge> danilos: ah yes, I was guessing there ...
<danilos> henninge, that's why we have constructed a matrix of things that need to happen, and you can read it on https://dev.launchpad.net/Translations/Specs/UpstreamImportIntoUbuntu/FixingIsImported/setCurrentTranslation
<henninge> danilos: actually, reading the code for setCurrentTranslation last night helped me better undstand what is going on there.
<danilos> henninge, I am sure it did, but some of it will not be clear from reading the code, because we 'unified' different matrix cells when what we wanted was for the same things to happen
<danilos> henninge, if you really want to get rid of makeCurrent, you'll have to modify A and B actions in the matrix (which call setFlag)
<danilos> henninge, good side of that approach would be that you should already have all the relevant messages that you might need to unset
<henninge> danilos: test_setcurrenttranslation is passing again ;)
<henninge> without makeCurrent* and just one line change in setCurrentTranslation
<danilos> henninge, heh, did you remove it? :P
<danilos> henninge, which one line is that? :)
<danilos> henninge, don't forget there's a possibility that we forgot some tests even though there's like a million of them :)
<henninge> https://pastebin.canonical.com/41106/
<henninge> Remove a flag before setting it.
<henninge> Without that it is causing erros elsewhere (withoug makeCurrent*)
<henninge> danilos: I reverted the canges to the '*' action but that is the one I don't understand yet.
<henninge> danilos: I don't see why I'd need to change 'A' and 'B' actions because they just unset flags.
<henninge> danilos: what we lose by not using makeCurrent* is the unsetting of flags.
<danilos> henninge, right
<danilos> henninge, sorry, my bad :)
<henninge> that' ok ;)
<danilos> henninge, so, I guess you should go on with removing makeCurrent* methods then :)
<danilos> henninge, it is basically a missing method if we compare it with the wiki page
<danilos> henninge, btw, I'd say it'd probably be a good idea to mention https://dev.launchpad.net/Translations/Specs/UpstreamImportIntoUbuntu/FixingIsImported/setCurrentTranslation in the comments of _setTranslation somewhere
<danilos> henninge, and look through "Capture the flag" section on that wiki page to understand why is '*' like it is
<henninge> danilos: ah yes, I remember reading about "Capture the flag"
<henninge> don't think I understood it back than, either :-P
 * henninge tries harder this tim
<henninge> e
<danilos> henninge, do not forget that action '*' or '+' happen only after A/B/Z and a numbered action has gone through
<henninge> yes, thanks.
<danilos> henninge, that's why the need for makeCurrent* is removed in all other actions, but seems jtv only forgot to implement the line you are adding
<henninge> danilos: Reading through the "guiding principles" I see that it may conflict with the sharing policy we discussed at a higher level.
<henninge> danilos: I was asking you yesterday "when it comes to calling setCurrentTranslation, the decission if this new translations should be shared has already been made"
<henninge> "it is passed into setCurrentTranslation as share_with_other_side"
<danilos> henninge, yes, exactly
<henninge> We had discussed that uploads on the upstream side would automatically update Ubuntu translations but not the other way round.
<danilos> henninge, it should still worry about unsetting the flags, I just forgot a few bits of the design myself :)
<danilos> henninge, yes, that's how it should be implemented today
<henninge> setCurrentTranslation prevents that by design, though, AFAIUI
<henninge> "stealing the flag" only happens if the other side is untranslated.
<henninge> otherwise "share_with_other_side" is ignored.
<henninge> I think.
 * henninge needs to read to the end.
<henninge> danilos: oh sorry, I think I found my error in thinking
<henninge> Upstream uploads only update Ubuntu translations if they were not changed on the Ubuntuside.
<henninge> I forgot about that. Never mind my rambling ...
<henninge> ;-)
<danilos> henninge, heh, don't worry
<danilos> henninge, anyway, try to get that branch into landable state asap, I want it behind us today :)
<henninge> danilos: I am currently re-running lp.translations tests on it. See what's left.
<henninge> I am also going to revert the the renaming of getImportedTranslationMessage to reduce the branch size.
<danilos> henninge, cool
<henninge> only two failures left ...
<pcjc2> Hi, One of our users uses a text based web-browser, and whilst LP works really well on my local instance with that browser, the Launchpad OpenID provider causes it problems
<pcjc2> Is the code for the LP OpenID provider available somewhere?
<pcjc2> The bug is pretty trivial actually.. the "Continue" button on the login page is served up with a "<button>" element, rather than an "<input ....  type=button>", which that web browser doesn't support
<pcjc2> The dummy OpenID provider in the LP checkout does not have that problem
<benji> pcjc2: I think a bug has been filed for that; let me see if I can find it
<benji> pcjc2: https://bugs.launchpad.net/launchpad/+bug/523229
<_mup_> Bug #523229: The Continue button isn't selectable in w3m for sso login <iso-testing> <lp-foundations> <Canonical SSO provider:Won't Fix> <Launchpad itself:Triaged by gary> < https://launchpad.net/bugs/523229 >
<pcjc2> ok, shame its wontfix
<pcjc2> ah - just in the SSO provider, never mind
<gary_poster> pcjc2: work-around is to install elinks.  Use it with env variable (BROWSER=elinks).  The change I'm trying to get is to have the w3m <button> support in natty backported to maverick and lucid.
<pcjc2> A question of user preference I'm afraid... but thanks though - I've pointed the user at the bug report, and hopefully he'll be able to find the newer package. He's in Debian I believe
<gary_poster> cool pcjc2 .
<pcjc2> It was just one nit in the process of moving our projects bugs to LP - some of our users might come off as "strange" in their preferences for softwar
<pcjc2> e
<gary_poster> :-) I know the same could be said of me
<pcjc2> One refuses to use anything modern, and back-ports everything to some old UNIX variant with ~1 user in the world
<gary_poster> heh
<pcjc2> (This wasn't the guy in question.., but I believe the reporter of the W3M issue is still running on a 486 or something)
<gary_poster> heh
<pcjc2> (Hell - I have BBC micros in the loft for the sake of nostalgia, but I don't try to do work on them any more ;))
 * benji shovels coal into his steam-powered laptop.
<danilos> henninge, hi, how is the branch coming along?
<henninge> danilos: I am was just about to prepare the mp.
<danilos> henninge, cool
<pcjc2> OT: Just a quote which came in today from that user  - "I read all my mail raw exactly as it comes across the wire, without using *any* MUA that does any decoding behind my back.  I have a little program I wrote myself that decodes base64, but it's a major PITA."
<pcjc2> "Hence if mail arrives in base64 and neither its source nor its subject line give a strong signal that it's important, it usually gets deleted by the firmware in my fingers without ever reaching my eyeballs.  Any responses to this message that are encoded in base64 are likely to receive such fate."
<pcjc2> We tend not to pander to him too much ;)
<henninge> danilos: but I don't think it still fits the bug ... or the kanban card.
<danilos> henninge, oh well, I wouldn't worry about that too much
<danilos> pcjc2, sounds very "smart", what does he do if I use my real name in Cyrillic when I try to email him? "unknown sender, delete" :)
<pcjc2> No idea.. He's Russian I believe.. but he believes all computers should be in English, and no time wasted on i18n
<pcjc2> He's a nice enough guy... just a reminder that you can meet some very strange people on the interweb
<danilos> bigjools, IBuildFarmJob doesn't specify .build at all, I am very much surprised to see it being required
<bigjools> danilos: it's delegated I think
<danilos> bigjools, to what?
<bigjools> specific_job
<bigjools> IIRC
<pcjc2> Is it normal for "bin/test bugimport" to take about 35-40 seconds?
<danilos> bigjools, but what interface are specific_jobs supposed to implement?
<danilos> bigjools, afaics, BuildFarmJobDerived delegates to BuildFarmJob but none of them implement .build
<bigjools> danilos: see lib/lp/soyuz/model/buildpackagejob.py
<bigjools> danilos: looks like it's not in the interface.
<danilos> bigjools, that doesn't answer my question: what should .build be at all
<bigjools> danilos: it's either a binarypackagebuild or a sourcepackagerecipebuild for the other job types
<bigjools> does that map to the ttbj jobs?
<danilos> bigjools, I am not sure it does, and that is the whole problem
<bigjools> ah :/
<danilos> bigjools, well, we do have translationtemplatesbuild job but that is an IBuildFarmJob (BuildFarmJobDerived) as far as I can see
<danilos> bigjools, it sounds weird for it to link to itself via .build
<danilos> bigjools, that's why we probably have this confusion in the first place
<danilos> bigjools, and it seems PackageBuild is also inherits from BuildFarmJobDerived
<bigjools> this whole model is a nightmare at the moment
<bigjools> loads of it is still there to support non converted jobs but I don't know what any more
<danilos> bigjools, right, this is what sounds weird: BuildPackageJob inherits from BFJD (BuildFarmJobDerived), and .build points at a BinaryPackageBuild which inherits from BFJD as well
<danilos> bigjools, so, it seems as if we are either using the same data structure for two different things or that I am very confused :)
<danilos> bigjools, if we simply implemented .build to point at self in TranslationTemplatesBuild, I wonder what would happen :)
<danilos> bigjools, basically, the problem is that we don't need that much indirection in translations
<danilos> bigjools, maybe we do because of the buildmaster design, but it seems neither noodles nor abentley are around today :(
<bigjools> danilos: the indirection is there because it's trying to support the old model as well
<bigjools> we need to remove it and it will all become simpler
<bigjools> but right now I have not been involved enough in that to sort it out
<bigjools> we could ask wgrant to take a look
<danilos> bigjools, right, so basically, I think that we just need to remove that and start using the new TranslationTemplatesBuild classes instead of the old ones
<danilos> bigjools, perhaps the way to simplify this in translations is to put .build on *old* translation build class pointing to the new translation build class
<danilos> would that be correct?
<bigjools> I can't say with any certainty
<bigjools> sorry to be useless
<danilos> bigjools, heh, you probably have at least a better idea than I do, that sounds like an easy thing to do, and I'll ask around (email noodles and abentley to see if that's correct)
<bigjools> danilos: noodles would be the best start
<danilos> bigjools, right, thanks
<bigjools> do we have any tests for the front page?
<bigjools> mrevell, when you've changed it before did you need to fix tests?
<mrevell> bigjools, No, certainly not for when I did what's new, but I think flacoste made the most recent big change to the front page so he may have more recent info on test coverage.
<bigjools> I can't see anything referencing the "Getting started" section either.  I guess for such a simple page it's hardly worth tests.
<jam> jml are you around? Or really anyone with twisted experience
<jam> I should mention that my above load test contrasts with being exactly 0.98 to the ssh loopback at any load level.
<EdwinGrubbs> bigjools: ping
<bigjools> EdwinGrubbs: 'sup
<EdwinGrubbs> bigjools: I'm working on the bug to prevent a person/team from being merged while it has a ppa.
<bigjools> ok
<EdwinGrubbs> bigjools: in your comment on the bug, you said that it could have the same restriction as for renaming a person, which is to prevent renames if the person has a ppa with published packages.
<EdwinGrubbs> bigjools: sinzui and wgrant pointed out that the ppa might show up in searches, and that the ppa would have to be in a DELETED status before it is merged, since it uses the user name to determine the directory that it will delete, and merge persons have "-merged" appended to the name.
<bigjools> EdwinGrubbs: yes, the code that is used in renaming can be re-used for blocking merging, it does that already
<EdwinGrubbs> bigjools: but shouldn't we block merges even if the ppa does not have a published package?
<bigjools> EdwinGrubbs: the code that's used in renaming DTRT
<bigjools> either (has publications and is DELETED) OR (has no publications ever)
<sinzui> EdwinGrubbs, bigjools read the last comments on bug 684112
<_mup_> Bug #684112: Link to PPA merged owner from +archivesubscriptions is broken <404> <lp-registry> <merge-deactivate> <tales> <trivial> <Launchpad itself:Triaged> < https://launchpad.net/bugs/684112 >
<sinzui> EdwinGrubbs, bigjools I think my suggest is bad. I suspect that the clean up proc will never remove the directories because the user/team names have changed
<bigjools> sinzui: indeed, I had overlooked that
<bigjools> it needs a manual cleanup to get the orphaned PPA repos
<sinzui> bigjools, the list is small. could re prepare a shell script to remove them?
<bigjools> should be fairly trivial, we just get a list of all repos and check that they are valid in LP
<EdwinGrubbs> bigjools: another question: since a ppa in DELETING status says that it is "Deleted", it will be annoying and confusing that they still can't merge the person, because the ppa needs to be in DELETED status. How long should I tell the user to wait before trying to merge again?
<bigjools> EdwinGrubbs: 5-10 minutes, we need to wait for the publisher cron job to run
<EdwinGrubbs> ok, thanks
<bigjools> gee, a message queueing system would sure be useful :
<jcsackett> sinzui: we're generally trying to clean up use of "assert something" and actually do proper exception raising these days, right?
<sinzui> jcsackett, yes
<jcsackett> okay, thanks.
<jcsackett> henninge: when you return, there are comments/questions on your MP.
<jcsackett> ...wrong channel.
<deryck> later on, all.
<salgado> bac, I'm jealous of you; I wish I could've deleted all that poll code
<bac> salgado: yeah, i know
<salgado> and then close all those bugs as won't-fix/invalid
<salgado> it must've felt good. :)
<bac> salgado: it is kind of sad, though.  i wish it would've been a viable feature
<salgado> indeed, but this was yet another feature we directed too much time that would be better spent improving other things. IMHO
<bac> salgado: oh, i agree killing it off at this point was the right thing.
<lifeless> once we get on top of things
<lifeless> fast
<lifeless> easy to use
<lifeless> etc
<lifeless> we can revisit these little-apps
#launchpad-dev 2010-12-17
<wallyworld> can anyone tell me, given a BranchRevision object, the correct way to figure out if the revision was from merging in another branch and what that other branch is? Do you look for some attribute of any revision parents?
<StevenK> wallyworld: wgrant says "lol"
<wallyworld> why lol?
<wallyworld> did i say something funny?
<wgrant> You may be able to use look at the revision's parents' getBranch method.
<wgrant> s/look at //
<wallyworld> that's what i'm doing now - i get the first parent and use getBranch() on that
<wallyworld> i wasn't sure if that was the correct thing to do or not
<wallyworld> i don't have any good data to check
<wallyworld> that my theory is correct that it is the right thing to do
<lifeless> I suggest discussing this with tim / a bazaar dev
<lifeless> I would, but its too much like work
<wallyworld> lifeless: and you are on HOLIDAYS
<lifeless> exactly
<wgrant>  /abr lifeless
<lifeless> abr
<lifeless> ?
<wallyworld> lifeless: so shut down your irc client :-)
<StevenK> OUT, DAMN SPOT
<wgrant> lifeless: auto op, ban, remove, de-op.
<lifeless> wgrant: thats an odd thing to suggest
<lifeless> wallyworld: On leave != uninterested :)
<lifeless> wallyworld: just relaxed :>
<wallyworld> lifeless: well i hope you have a beer in hand or something :-)
<lifeless> I'm playing wow :)
<lifeless> wallyworld: while you are here
<lifeless> bug 691343
<_mup_> Bug #691343: OOPS page should reflect new bug filing location <Launchpad itself:New> < https://launchpad.net/bugs/691343 >
<lifeless> would be easy and extremely useful to fix :)
<wallyworld> lifeless: ok. i'll take a look
 * wallyworld assigns bug ^^^^ to himself
<mrevell> Hello
<danilos> wgrant, hi, are you perhaps still around?
<wgrant> danilos: Hi.
<wgrant> danilos: You're wondering about TTBJ.build?
 * StevenK looks for a reviewer in here as well ...
<StevenK> wgrant: Doesn't that just link to the Build table?
<wgrant> danilos: I think it should link to the TTB.
<wgrant> danilos: But that whole part of the model is being ripped out when I get bored.
<wgrant> Which may end up being next week.
<wgrant> StevenK: Down to 9.1EB yet?
<StevenK> 9223372036695 MB
<wgrant> :(
<StevenK> wgrant: You have 23 hours 55 minutes to get here and download the entire Internet
<lifeless> wtf
<StevenK> lifeless: So, internet here said I had 500MB download limit. I logged in again after it disconnected me for hitting the limit, and it seems my limit is now 9.2EB
<wgrant> The limit also decreased as we used it.
<wgrant> It seems to be counting properly.
<lifeless> wheeee
<wgrant> Despite being 9.2EB of 500MB.
<jpds> How odd.
<StevenK> I suspect an overflow bug of some kind
<lifeless> === Top 10 Time Out Counts by Page ID ===
<lifeless>     Hard / Soft  Page ID
<lifeless>       59 /  242  BugTask:+index
<lifeless>       31 /  267  ProjectGroupSet:CollectionResource:#project_groups
<lifeless>       25 / 3459  Archive:+index
<lifeless>       25 /  289  Distribution:+bugs
<lifeless>       18 /  237  POFile:+translate
<wgrant> jpds: Yet remarkably convenient.
<danilos> wgrant, that's right (sorry, phone and emails :)
<lifeless>       12 /    1  Bug:EntryResource
<lifeless>        8 /  120  Question:+index
<wgrant> lifeless: Nooooooo.
<lifeless>        6 /   18  DistroSeriesLanguage:+index
<lifeless>        6 /    0  Person:+leave
<lifeless>        5 /    2  Person:+bugs
<lifeless> StevenK: overflow would count down :P
<StevenK> Haha, Person:+leave
<StevenK> lifeless: It does count down as it use it ...
<lifeless> sorry, I meant up
<lifeless> overflows would be in 2's complement
<StevenK> Yes. It's very strange
<danilos> wgrant, also, do you think we could just switch getCurrentBuildFarmJob to get the new-style jobs directly thus not needing to add it for the TranslationTemplateBuildJob?
<lifeless> I suspect an unsigned where it should be signed ;)
<StevenK> And I don't want to tell them, since then they might fix it
<lifeless> meep
<wgrant> danilos: If you can find a way to do that, sure.
<lifeless> filebug is borked in prod
<lifeless> on chromium
<wgrant> danilos: I'm not sure it's possible yet.
<lifeless> apparently if you click 'just so', worked when  retried.
<wgrant> I forget if BuildFarmJob.builder is set during the build.
<wgrant> And at 9:20pm after just getting home from a sprint, I'm not entirely sure that I want to find out.
<StevenK> Like the sprint was that hard, you slacker
<lifeless> wgrant: 900ms queries
<wgrant> danilos: It looks like BuildFarmJob.builder is not set during the build, so you probably can't do it.
<lifeless> wgrant: *, well, 15
<wgrant> danilos: You have to go through the BuildFarmJobOld
<wgrant> lifeless: I fail at interpreting OOPS reports. How do I find an OOPS for that pageid?
<lifeless> wgrant: you start on the oops summary, sent to canonical-launchpad
<lifeless> wgrant: then, you look for bugs tagged timeout, and you find (just filed) bug 691478
<_mup_> Bug #691478: Archive:+index timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/691478 >
<lifeless> wgrant: and in there, click on the link :)
<danilos> wgrant, tbh, I don't really understand most of this, so I am just seeing if there's anything that we really need to do to make it possible for you guys to finish the migration
<wgrant> danilos: I don't know exactly what is necessary, sorry. I need to swap that all back in.
<wgrant> It's been a few months.
<lifeless> wgrant: oh, to find the entry in the report, search for the pageid in the summary report.
<wgrant> lifeless: Hm, OK. Thanks.
<danilos> wgrant, right, so perhaps just adding the build property to the TTBJ should solve what we can do on our side, and I'll let you worry about the rest
<wgrant> lifeless: Ow.
<danilos> wgrant, though, I am not sure how do we switch buildmaster to use new TTBs instead of TTBJs for translation jobs, but I guess that's easy enough
<danilos> wgrant, also, what happens with all the BFJOld info like score and such, I don't see that in BFJs anymore
<wgrant> danilos: The new classes (TTB, BPB, SPRB, etc.) are mostly just used for storing data for histories.
<wgrant> Most control is still performed by the BFJOld.
<wgrant> The score is on BuildQueue.
<wgrant> I want to merge BuildQueue into BuildFarmJob, but some others do not.
<wgrant> Score will remain there for now.
<wgrant> And BuildQueue will link to BuildFarmJob.
<danilos> wgrant, ah, ok, so we are still pretty far off from being able to completely switch to the new model if I got that correctly
<wgrant> danilos: Not *really*.
<wgrant> Just needs some code moved around, basically.
<danilos> wgrant, heh, ok, then I didn't get that correctly :)
<wgrant> But I need to work out what.
<wgrant> The job-specific schema changes are done.
<wgrant> Apart from deleting the old tables.
<danilos> wgrant, right, so do you think it makes the most sense for you to deal with that? would it help if TTBJ.build was provided and pointed at TTB?
<wgrant> danilos: Do that for now, since it makes the buildd-manager log sad.
<danilos> wgrant, ok, I hope I'll be able to come up with a nice simple query to get that (i.e. I am hoping a TTBJ has enough information to do it)
<danilos> wgrant, thanks for the input
<wgrant> danilos: Sorry I can't be more help.
<wgrant> But uni pushed all that stuff way down.
<danilos> wgrant, yeah, don't worry, it's just that _that_ bigjools guys is pushing us to implement stuff that I believe we mostly implemented :)
<wgrant> danilos: It's all a bit of a mess, yes.
<wgrant> We are really close now, though.
<danilos> wgrant, and I don't know enough to tell him off, so I am trying to learn all about this in a few hours which turns out is not the simplest thing around ;)
<danilos> wgrant, not to mention that TTBJ is at the same time a BFJOld and a BranchJob, just to make it more interesting :)
<wgrant> danilos: Yeah, I like to blissfully forget that detail.
<danilos> hey bigjools, I was just gossiping about you, but if I tell you what it was, it won't be proper talk-behind-the-back stuff
<lifeless> hmm, we should probably log returned rows in the oops query history
<wgrant> lifeless: The number of returned rows?
<lifeless> yeah
<wgrant> Indeed.
<lifeless> so we can see slow but fast per row
<lifeless> vs fast but few rows
<lifeless> vs slow and few rows
<danilos> wgrant, yeah, I hate that, and I am hoping we can soon just make TTBJ a BranchJob and let any buildd stuff live in TTB
<wgrant> danilos: I will hopefully be deleting TTBJ.
<wgrant> Although it may end up staying, but not as part of the build farm model.
<danilos> wgrant, well, we can't delete the branchjob stuff, that's what schedules the build
<wgrant> Right.
<danilos> wgrant, right, we should just rename it
<wgrant> TTB will probably know about it, but nothing else.
<lifeless> wgrant: there wqere some dups
<lifeless> wgrant: but only 2.5 seconds worth
<wgrant> lifeless: yeah, max of 3 reps.
<wgrant> Not 100.
<lifeless> wgrant: max of 26 perhaps
<lifeless> row 4 of duplicates
<danilos> wgrant, right, though perhaps not even that (i.e. we use it to add a TTB to the queue, but that should be it)
<lifeless> ah nope, wrong column
<lifeless> wgrant: so I think we've still got a per-row-in-ui just-in-time query being triggered
 * bigjools is not here
<wgrant> lifeless: Possibly. Can I see recent OOPSes for Archive:+packages somehow?
<wgrant> I want to compare them to Archive:+index.
<lifeless> wgrant: log into devpad, grep.
<wgrant> Yay.
<wgrant> I will just trigger new ones instead.
<wgrant> On DF.
<lifeless> wgrant: or
<lifeless> OOPS-1811H1896
<lifeless> 25 seconds!
<lifeless> (top 10 durations in the lpnet summary)
<wgrant> Minimal reps.
<wgrant> Just... very slow.
<wgrant> Hm.
<wgrant> That OOPS must be wrong.
 * wgrant blames the GIL.
<wgrant> 5s gap after a 200ms query.
<lifeless> there's a bug for getting per thread times
<lifeless> just needs tuits
<wgrant> And a couple of other similar ones.
<lifeless> wgrant: large row counts coming back through storm can legitimately show up as that, fwiw
<wgrant> Oh, that +index OOPS is the same.
<wgrant> Multi-second gaps after ~200ms queries that wouldn't return that many rows.
<lifeless> heh
<wgrant> Like <100.
<lifeless> well, someone should merge my single threaded appserver branch :)
<henninge> danilos: do you know about LaunchpadWriteTarFile?
<danilos> henninge, now I do :)
<henninge> danilos: it's in lp.translations.utilites.translation_export
<henninge> but I think it belongs under lp.testing.
<danilos> henninge, right, and it might, though testing does sound weird, let me look
<henninge> danilos: oh, right. I thought it was only used in tests
<danilos> henninge, it might make sense to move it to lp.services though
<henninge> but the language pack exporter uses it, too.
<henninge> danilos: yes, I agree.
<henninge> danilos: I'll put it in lp.services.tarfile
<danilos> henninge, sure, though you might want to avoid using the same name as the global tarfile module imho :)
<henninge> ok
<henninge> lptarfile
<henninge> ?
<danilos> henninge, i.e. you can't do "from lp.services import tarfile" and "import tarfile" then
<danilos> henninge, I don't know, it's also only for writing
<henninge> I would not recommend taht anyway
<henninge> importing the module, I mean.
<henninge> tarfile_helpers
<danilos> henninge, heh, I am not saying I'd recommend it, it's just that it'd be unobvious to a reader of the code which tarfile module is being used in that case
<henninge> true
<henninge> danilos: how is tarfile_helpers?
<danilos> henninge, probably good enough, go with that and see if your reviewer thinks otherwise
<henninge> cool, thanks
<deryck> Morning, all.
<maxb> *blink*   Is PPA +copy-packages supposed to offer o-series and p-series as destinations?
<jelmer> maxb, there's a bug open about that
<jelmer> maxb, we previously didn't really support distro series that were present but not initialized
<gmb> gary_poster: Are you the right person to talk to about making lxml a dependency for Launchpad?
<gary_poster> gmb, I guess
<gmb> gary_poster: I ask because I've got a branch in review that depends on it; bac has pointed out that we don't necessarily have it on our appservers.
<gary_poster> gmb, lxml is notoriously annoying to build as a Python egg.  Is the Deb-packaged version acceptable?  Also...
<gmb> gary_poster: There's now some discussion in launchpad-reviews about this...
<gary_poster> ISTR that we have had an lxml dependency in the past
<gmb> ORLY.
<gary_poster> yeah, I saw, gmb, I'm not entirely sure where to write :-)
<gmb> Over there. There are more people paying attention :)
* flacoste changed the topic of #launchpad-dev to: Launchpad Development Channel | BUG JAM! http://mumak.net/lp-bugjam-2010/ 73 so far | New starter this week: wgrant  | PQM open for business | firefighting: - | Get the code: https:/â/âdev.launchpad.net/âGetting
<maxb> gmb: Remember to tag the launchpad-dependencies branch :-)
<gmb> maxb: Done, thanks for the reminder. There are two sets of instructions for maintaining that .deb and on of htem is wrong.
<gmb> I'll update it now...
<maxb> gmb: where is the second?
<gmb> maxb: Well, the first is here: https://dev.launchpad.net/Hacking#Changing%20the%20launchpad%20dependency%20debs (and was wrong). The second (correct; or at least more up-to-date) version is here: https://dev.launchpad.net/LaunchpadPpa#launchpad-dependencies
<gmb> I'd got all the way through the process before finding hte second.
<gmb> I've updated /Hacking to point at the LaunchpadPPA page.
<maxb> hah, nice. I never knew of the first, when I wrote the second
<maxb> Neither did anyone who was asking me if there were any instructions for doing it :-)
<gmb> Heh.
<gmb> Well, they were similar enough that I didn't screw things up. The first just used the old, non-bzr-builddeb way.
<henninge> danilos: fxing bug 619121
<_mup_> Bug #619121: Inactive template in rosetta: Confusing wording <bugjam2010> <lp-translations> <trivial> <ui> <Launchpad itself:In Progress by henninge> < https://launchpad.net/bugs/619121 >
<henninge> danilos: do you agree with "Template active?" instead of "Accept translations?"
<danilos> henninge, yes
<danilos> henninge, or "Template is active"
<henninge> without the '?'
<henninge> I think I like that even better
<danilos> henninge, I don't, I think it should just be "???"
<henninge> ;-)
<henninge> danilos: bug 670821
<_mup_> Bug #670821: translator comment formating lost <lp-translations> <trivial> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/670821 >
<henninge> do you know of any reason not to use a <pre> here?
<danilos> henninge, well, one: comments in PO files commonly have some whitespace padding as in:
<danilos> #.   This is all so cool
<danilos> #.     that it doesn't make sense at all
<danilos> (imagine those two were aligned: basically, we'd need equivalents for "rectangle whitespace" handling)
<danilos> henninge, but, it's probably an improvement to just use <pre>, which is why it's 'trivial' :)
<henninge> danilos: but doesn't <pre> give us that?
<danilos> henninge, well, my point was that it'd be nice to strip initial spaces (same amount from every line) and then put it into <pre>
<danilos> henninge, i.e. think of a case like this as well:
<danilos> #.    numbered items:
<danilos> #.      1. one
<danilos> #.      2. two
<danilos> henninge, it'd be nice if we stripped those 4 leading spaces from each line, but not a big deal imo
<henninge> no, not really. ;)
<danilos> henninge, yeah, so go for the trivial :)
<henninge> we can do that when we redesign the +translate page ... ;)
<danilos> henninge, heh, right, "when" :)
<henninge> meaning 'if'?
<danilos> henninge, well, meaning "we" :)
<danilos> or rather, "we?" :)
<henninge> they!
<danilos> MutatedCelebrityError :(
<maxb> hah
<maxb> that is an AMAZING classname :-)
<danilos> :)
<danilos> I'd probably enjoy it more if we didn't get ~800 OOPSes with that :)
<benji> I'm reminded of the TemporalParadox raised when you tried to edit a past version of an object in the Zope 2 history tab.
<LPCIBot> Project db-devel build (231): FAILURE in 3 hr 38 min: https://hudson.wedontsleep.org/job/db-devel/231/
<LPCIBot> Project devel build (313): FAILURE in 3 hr 13 min: https://hudson.wedontsleep.org/job/devel/313/
<LPCIBot> Launchpad Patch Queue Manager: [r=bac][ui=none][bug=685624] Provide
<LPCIBot> TranslationTemplatesBuildJob.build property linking to
<LPCIBot> TranslationTemplatesBuild objects to stop polluting
<LPCIBot> build-manager logs.
#launchpad-dev 2010-12-18
<wgrant> StevenK: Hudson seems to have lost its executors.
<lifeless> === Top 10 Time Out Counts by Page ID ===
<lifeless>     Hard / Soft  Page ID
<lifeless>       51 /  228  BugTask:+index
<lifeless>       30 / 3668  Archive:+index
<lifeless>       27 /  240  POFile:+translate
<lifeless>       24 /  267  Distribution:+bugs
<lifeless>       16 /  181  ProjectGroupSet:CollectionResource:#project_groups
<lifeless>       14 /  282  Distribution:+bugtarget-portlet-bugfilters-stats
<lifeless>       11 /    0  Bug:EntryResource:markUserAffected
<lifeless>        9 /    0  BinaryPackageBuild:+retry
<lifeless>        7 /    3  ProjectGroup:+milestones
<lifeless>        7 /    0  Person:EntryResource:retractTeamMembership
<wgrant>                                                          Hash Cond: (libraryfilealias.id = binarypackagefile.libraryfile)
<wgrant>                                                          ->  Seq Scan on libraryfilealias  (cost=0.00..443715.96 rows=17121496 width=45)
<wgrant> *Awesome* plan.
<lifeless> wgrant: thats on dogfood?
<wgrant> lifeless: Yeah.
<lifeless> a tad, whats the word. Fucked.
<wgrant> Was trying to preemptively QA one of my changes, noticed that the publisher was slow, EXPLAIN'd a query, and...
<lifeless> wgrant: same as Archive:+index ?
<wgrant> lifeless: No.
<lifeless> :(
<lifeless>  :)
<wgrant> This is through a view that a need to destroy.
<wgrant> I wonder if that will help.
<wgrant> s/a need/I need/
<lifeless> it may
<wgrant> I think I have a branch that does that somewhere.
<wgrant> Yay, lazr.restful is broken in python2.7.
<wgrant> Or ZTK.
<wgrant> One of them.
<lifeless> \o/
<lifeless> good to know
<lifeless> I develop in a vm for a reason though ;)
<wgrant> Time to go diving in lazr.restful, I think.
<wgrant> ...ah.
<wgrant> >>> class IFoo(Interface):
<wgrant> ...    pass
<wgrant> ...
<wgrant> >>> inspect.isclass(IFoo)
<wgrant> False
<wgrant> In Python 2.6 that returns True.
<wgrant> How very, very odd.
<lifeless> \o/
<wgrant> Sigh.
<wgrant> 2.6's isclass returns true if it's an instance of ClassType, or if it has a __bases__ attribute. 2.7's uses only the first criterion.
<lifeless> is there a python issue on this?
<wgrant> It's probably deliberate.
<wgrant> And, more importantly, correct.
<wgrant> lazr.restful works now, so maybe LP will too...
<wgrant> Looks like we won't even need a ZTK upgrade this time!
<StevenK> wgrant: Has it found some again?
<wgrant> StevenK: No.
<StevenK> wgrant: I've noticed, let the face-stabbery start
<wgrant> Heh, thanks.
<wgrant> archivepublisher and mawson, you both suck.
<StevenK> wgrant: Hudson diagnosed; / is full, fixing it after eating and figuring out where the heck I am
<wgrant> StevenK: Ah, that would do it. Thanks.
<StevenK> wgrant: Hudson fixed, {,db-}devel kicked off
#launchpad-dev 2010-12-19
<wgrant> Why, precisely, does Python feel the need to change the default float rounding length.
<wgrant> I think they must be just trying to break doctests.
<lifeless> maxb: ping
<spiv> wgrant: why, precisely, did people write tests that asserted things about the default float rounding length? ;)
<lifeless> spiv: because somebody thought doctest was a good idea
 * spiv awards lifeless a gold star and an early mark.
<lifeless> .
<wgrant> Morning all.
<jelmer> g'morning William
<thumper> wallyworld_: morning
<wallyworld_> thumper: hello
<wallyworld_> thumper: mumble?
<thumper> yeah
<thumper> let me plug bits in
<wallyworld_> http://people.canonical.com/~ianb/br1.png
<wallyworld_> thumper: ^^^^^
<wallyworld_> thumper: bug 334336
<_mup_> Bug #334336: Show which branch and bug are related to a revision <bugjam2010> <lp-code> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/334336 >
<wgrant> Oooooh.
<jelmer> wallyworld_: Looks nice!
<thumper> not happening
<thumper> partly because we can't work out the parent
<wallyworld_> jelmer: too hard to figure out what branch was merged in thumper says
<wallyworld_> jelmer: the screenshot is a prototype
<jelmer> thumper, wallyworld_: Not possible performance-wise ? I can think of ways to work out the relevant MPs but not using a reasonable database query.
<wallyworld_> jelmer: we don't have the info to determine the branch, but mp may be possible
 * thumper goes to town to take the car in (again)
<thumper> and now, another attempt to leave the laptop
<thumper> this gravity well is just too string
<thumper> strong
#launchpad-dev 2011-12-12
<wgrant> lifeless: Is security.py going to end up in lazr-postresql too?
<lifeless> no
<wgrant> :(
<lifeless> or at least, not in this arc
<wgrant> How're you going to manage security?
<lifeless> wgrant: for scriptactivity ? in the db patches themselves probably.
<wgrant> Ah
<lifeless> we have three types of patches in the new system
<lifeless> std (goes via slonik)
<lifeless> direct (applies to each node separately in a xact)
<lifeless> concurrent (applies to each node separately outside of a transaction)
<wgrant> lifeless: Right.
<lifeless> thus doing create role & grant on all the nodes is straight forward
<wgrant> Yeah, which security.py can do :)
<wgrant> Just needs to be made fully nodowntime, which I didn't quite get around to last week.
<lifeless> I eagerly await this shiny.
<lifeless> for now, minimal is good.
<wgrant> True, true.
<wgrant> But minimal LP is better :)
<lifeless> we could just ditch security.py
<lifeless> and success - https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-c63bba67bbc99ffb6e41ba383cd87c88
<lifeless> tomorrows oops report should indeed have bazaar soft timeouts
<wgrant> I fear it.;
<lifeless> they will be soft timeouts
<wgrant> I still fear it.
<lifeless> and as you can see, w/no timeline, its pretty opaque data at the moment
<wallyworld_> wgrant: i think there's a bad rev on qas but i'd like a 2nd opinion to ensure i've set things up correctly
<wallyworld_> do you have a moment?
<wgrant> wallyworld_: The person limitedview thing?
<wallyworld_> wgrant: yes
<wgrant> What's the issue?
<wgrant> Hmm
<wgrant> Interesting.
<wallyworld_> i have a private team with a ppa. i have subscribed someone to the ppa. but theu can'
<wgrant> Something is broken, yeah.
<wallyworld_> t get to it
<wallyworld_> team is ~private-foobarx
<wallyworld_> i have subscribed xgy-ian to the ppa
<wallyworld_> but when i login as xgy-ian, i get Unauthorized on https://qastaging.launchpad.net/~private-foobarx/+archive/ppa
<wallyworld_> that's wrong, right?
<wgrant> Should be, yes.
<wgrant> Let me just fetch my testing account.
<wallyworld_> ok
<wallyworld_> there's 2 bugs
<wallyworld_> one is not any worse, so is technically qa-ok
<wallyworld_> but i hate marking a bug that doesn;t fix the issue as qa-ok :-(
<wgrant> Hmm
<wgrant> I think traversal may be failing.
 * wgrant checks.
<wallyworld_> yes
<wallyworld_> that's my suspicion
<wgrant> eg. if you go to https://qastaging.launchpad.net/api/devel/~private-foobarx?ws.accept=application/json you get an Unauthorized for account_status
<wgrant> Which is checked during traversal.
<wallyworld_> when i went on leave, the 2 branches i had were wip but curtis landed them with some fixes
<wgrant> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-40786f88f5a5251bc6910b6f6b1ad083
<wgrant> Traversal is indeed failing.
<wgrant> qa-bad
<StevenK> Hm, it looks like Curtis fixed my branch but didn't land it.
<wallyworld_> wgrant: should i mark both bugs as qa-bad
<wallyworld_> even though one of them is just as borken as before
<StevenK> wallyworld_: qa-bad and bad-commit-<rev>
<wallyworld_> ok
<wgrant> "just as borken" == "people who are subscribed to branches owned by other private teams still can't see them"?
<StevenK> I need to smack people for not adding bad-commit-<>
<wallyworld_> wgrant: yes
<wgrant> wallyworld_: Doesn't really matter.
<wgrant> If they're the same rev.
<wallyworld_> i marked it as qa-ok by mistake
<wallyworld_> StevenK: how was your week off?
<StevenK> It was excellent.
<wallyworld_> stayed home?
<StevenK> Yeah, I stayed home and played games all week.
<wallyworld_> excellent. i went to the beach. limited internet so very relaxing :-)
 * wallyworld_ goes to rollback the bad rev
 * StevenK goes for lunch, with a plan to look carefully at the ec2 failure mail from this branch.
<lifeless> wgrant: I know you are not here, but are you doing to land your config changes?
<wgrant> lifeless: Two are in PQM now.
<wgrant> One conflicts with mthaddon.
<wgrant> And the last conflicts with the two that are landing now, so I'll merge and submit once they've landed.
<lifeless> cool, thanks
<lifeless> I was going to do the production datedir2amqp consolidation
<lifeless> give spm something to do
<lifeless> but I'll wait for your things to percolate through
<wgrant> Do you want to switch (qa)staging to one-config-per-user first?
<wgrant> Rather than migrating prod twice?
<lifeless> no
<lifeless> we have have debt here atm with the rsync copy backup dirs
<lifeless> I want that solved before I go on leave
<lifeless> or it will be hanging over our heads through EOY
<wgrant> Ah, true, forgot you were running off.
<lifeless> one config per is nice, but refactoring vs fixing issue
<wgrant> Yeah.
<wgrant> Forgot we only had a couple of days.
<lifeless> says he that has already run off :P
<wgrant> Silence, fool.
<wgrant> One landed.
<spm> lifeless: just about at the point where only cocobananas is left to do.
<lifeless> wgrant: btw the initial lazr-postgresql code is on LP if you are interested
<wgrant> lifeless: So I saw.
<wgrant> lifeless: How will this integrate will full-update.py? We'll just use lazr-postgresql's upgrade.py?
<lifeless> wgrant: we'll either call upgrade.upgrade directly
<lifeless> wgrant: from a new buildout console_script; which will let us use the lazr config enabled connect() in the LP tree
<wgrant> Right.
<lifeless> wgrant: or we will have an extension point to call local hooks
<lifeless> for now, for simplicity, I'm expecting to add an upgrade (devmode) and full_upgrade(prod) buildout script.
<lifeless> wsyt
<lifeless> bah
<lifeless> wdyt
<wgrant> Sounds reasonable.
<wgrant> wallyworld_: Did you intend to submit the rollback twice?
<wallyworld_> wgrant: no. i hadn't gotten any merge email so thought it didn't go through as happens when bb is broken and it just disappears into the ether
<wgrant> wallyworld_: Ah, no, PQM was just spending a while chewing on my config branches.
<wgrant> You can see the queue at pqm.launchpad.net.
<wallyworld_> ah ok
<wallyworld_> so do i need to correct anything?
<wgrant> The second one will hopefully fail.
<wgrant> Should be fine.
<wallyworld_> just got the email just now
<wallyworld_> and a failure for the 2nd one
<wgrant> Great.
<StevenK> wallyworld_: Check the queue, if someone submits a prod-config branch it will take 45 minutes.
<wallyworld_> StevenK: rightio. i was used to it taking a minute or two
<StevenK> Sure, which it does for devel branches :-)
<wgrant> I optimised (db-)devel landings from 45 minutes to 45 seconds. But configs are harder and rarer, so I didn't fix them.
<wgrant> lifeless: lp:~wgrant/lp-production-configs/cleanup will be landed in 30ish minutes, or you can start working off it now.
<wgrant> That's only #3, but #4 is reasonably uninvasive.
<lifeless> I have to wonder if we should slony-I all the dev environments
<StevenK> You must really hate developer CPUs, then
<lifeless> no
<wgrant> Single-node slony with no slons?
<lifeless> two-node local cluster
<StevenK> To what end?
 * StevenK is confused.
<lifeless> same reason local dev environment is postgresql, so its close to prod
<StevenK> sinzui didn't land my branch, but fixed the test failures and then set the bug to fix released.
<StevenK> wgrant: ^ Can you explain that?
<wgrant> Test fixes go in, bug status changes go out. Can't explain that.
<wgrant> But no.
<wgrant> No clue what's going on there :/
<StevenK> From what I can see, the bug isn't fixed, so I'm tempted to set it back and toss my branch at ec2.
<wgrant> Probably a good plan.
<StevenK> Bah, conflict
 * StevenK fixes first
<wgrant> lifeless: The configs are all yours.
<lifeless> thanks
<lifeless> anyone around up for a tiny review?
<wallyworld_> lifeless: can i help?
<lifeless> I ended up self reviewing :)
<lifeless> it was lp:~lifeless/oops-tools/own-oopses, if you wanted to do a post landing review
<lifeless> its horribly uninteresting though
<wallyworld_> lifeless: np. just thought i'd ask since i glanced at irc between tasks and saw your reuqest
<lifeless> thanks!
<lifeless> jtv: /winm 58
<lifeless> bah
<adeuring> good morning
<lifeless> night all
<mrevell> Que pasa?
<bigjools> morning
<danhg> Morning all
<jtv> morning
<Guest52098> hai, I'm from indonesia
<rick_h_> morning party people
<StevenK> Can haz someone from maintaince look at why db-devel went bang on buildbot?
<rick_h_> heh, wouldn't expect to see a .jar error on there
<bigjools> StevenK: maintenance is gary this week, so wait now() + 2.5 hours
<wgrant> Hmmm?
<wgrant> buildbot breakage is a $everybody event.
<bigjools> it is not a "drop what I am doing right now event"
<nigelb> rick_h_: I've been having "fun" with SqlAlchemy today :)
<nigelb> Its not so bad after a while :P
<rick_h_> nigelb: heh, let me know if you need a hand with anything
<cjwatson> I've done (among other things) http://paste.ubuntu.com/767818/; can anyone explain why I get this ForbiddenAttribute exception? http://paste.ubuntu.com/767819/
<cjwatson> Given that IndexStanzaFields isn't a database-backed class, this is surprising
<StevenK> That's probably zope in your way, then
<cjwatson> StevenK: no doubt, but I don't understand how it's getting there or how to fix it
<StevenK> Can you pastebin a traceback?
<StevenK> cjwatson: If you 'type()' is it a proxy or a real object?
<bigjools> cjwatson: probably because it's being returned from a method on a proxied object
<bigjools> if you give it an interface it'll work
<bigjools> having said that, you are running non-zopeless tests again? :)
<cjwatson> No, this is in LaunchpadZopelessLayer
<cjwatson> StevenK: http://paste.ubuntu.com/767819/ (above) is the traceback I have
<StevenK> LaunchpadZopelessLayer is not really zope-less sadly.
<cjwatson> yeah, it's a proxy
<bigjools> indeed
<bigjools> ZopelessDatabaseLayer is what you need
<bigjools> for publisher stuff
<bigjools> I hate layers
<cjwatson> But I need a librarian, unfortunately
<cjwatson> In any case the actual site of the problem is not in a test so I need to deal with the proxy thing regardless
<bigjools> we need a LibrarianZopelessDatabaseLayer :)
<bigjools> (you see why I hate layers)
<cjwatson> or a non-borked fakelibrarian
<cjwatson> I think I'll shove in an interface
<nigelb> rick_h_: Its mostly been okay so far. I took some time to get used to handling relationships. I have the manual open for the most part (which is excellent btw), so that's helping :)
<rick_h_> nigelb: yea, docs are A+ imo, at least once you get past terminology
<bac> sinzui:  i have about ten vouchers -- are there any projects that really need them?
<bac> sinzui:  also, do you have access to niobium?
<sinzui> bac: search project review for proprietary projects without a commercial subscriptions. There are some pmteam projects that need vouchers
<sinzui> bac: I do not have access to niobium
<sinzui> bac /sarasa also needs a license
<sinzui> We do not need to worry about ezncrypt until February
<lifeless> morning everyone
<jcsackett> lifeless: it throws me when you say morning and it's actually my morning. but good morning. :-)
<lifeless> trust me, it throws me too :)
<lifeless> EBABY
<nigelb> jcsackett: lifeless says morning in my morning and night.
<nigelb> Confuses the heck out of me.
<bac> thanks sinzui
<abentley> deryck: It really throws me that we default to ascending order when clicking the losenges. If we default to descending order, we'll see most-important-first, recently-updated-first, most-bug-heat-first.  Can and should we change this?
<jcsackett> abentley: that sounds entirely logical to me. i always want sort to work that way.
<rick_h_> abentley: +1 on that
<deryck> abentley, I think we should make it losenge-specific actually.  title makes more sense ascending, for example. I think each on should have it's own starting default...
<deryck> abentley, but if not that, then yes, ascending probably works better for most then descending.
<deryck> sorry, descending probably works better.
<abentley> deryck: cool.
<deryck> my head hurts trying to track ascending vs. descending for some reason. :)
<abentley> deryck: Does YUI provide a way to test that something is logged?  I'm changing a Y.error to a Y.log, but it only seems right to test the log.
<deryck> hmmm, I don't know.  Thinking....
 * deryck is looking at how YUI tests logging
<rick_h_> If the 'debug' config is true, a 'yui:log' event will be dispatched
<rick_h_> can you watch that event to verify via test?
<rick_h_> or do tests not run with debug? I don't recall
<deryck> ah, that's a good idea.  And easy enough to change to debug config if not.
<abentley> rick_h_: Okay, I can do that.
<rick_h_> my turn, abentley deryck if I wanted to install a package for dev purposes (ipdb in this case) what's the *right* way to get it available?
<deryck> abentley, rick_h_ and debug is true by default, so that event hook should work.
<rick_h_> I've tried installing into the eggs dir, adding to versions.cfg
<abentley> rick_h_: You put the tarball in download-cache/dist, add it to setup.py, and update versions.cfg, IIRC.
<deryck> rick_h_, this is only something you want to use yourself?  or trying to add it for all lp devs to have access?
<rick_h_> which I don't want to do since it's a bzr tracked file anyway
<rick_h_> deryck: just me for prettier pdb
<rick_h_> abentley: ah, ok. I'll try that route, thanks
<abentley> rick_h_: bzr branches can be put in sourcecode/
<abentley> rick_h_: They are configured using utilities/sourcedeps.conf and updated with utilities/update-sourcecode
<rick_h_> abentley: cool, thanks for the heads up
<deryck> rick_h_, can you not install it normally via apt-get and use it as you wish?  I didn't think we did any sort of virtualenv stuff that prevent importing from system python.
<rick_h_> deryck: well this is a pip install'd package
<rick_h_> and isn't in the path from the buildout stuff it appears
<rick_h_> deryck: so I was trying to cheat it in, but it's still not picking it up and not sure if I'm doing it wrong or buildout/make is being overly helpful
<deryck> rick_h_, where does pip want to put it?  And could you just not manually much about with PYTHONPATH exports?
<rick_h_> deryck: so figured I'd see if there was a standard practice for this kind of personal tool thing.
<deryck> rick_h_, there is, what abentley said.  but you'll have to be more careful to not commit that. So just thinking how to do it without going through lp.
<rick_h_> deryck: yea, I installed it system wife /usr/local.. dist-packages
<rick_h_> deryck: and yea, I tried just to manually symlink it into the egg directory with no success
<rick_h_> deryck: definitely, don't want to muck with the official files, but figured I need to start with getting it to work, and then work on backing it out of bzr tracking
<abentley> rick_h_: well, we don't really have a practise for stuff we're not intending for other devs to use.  Aside from the standard ways of administering your system.
<rick_h_> abentley: ok, just checking
<deryck> rick_h_, try export PYTHONPATH=$PYTHONPATH:/path/to/other/stuff then do your make run.
<deryck> rick_h_, I'm not a pip user, though, which I know may be blasphemy to some. ;) So maybe others here have better ideas for how they manage their system with pip and running launchpad.
<rick_h_> deryck: ok, thanks
<lifeless> gary_poster: thanks for updating the lxc page; btw feel free to edit the main page as you go - probably easier than merging concurrent changes later
<abentley> deryck or bac: There's no OCR, could one of you review https://code.launchpad.net/~abentley/launchpad/distro-structural-subscription/+merge/85356 ?
<deryck> abentley, I can.
<abentley> deryck: thanks.
<deryck> np!
<deryck> abentley, nice test, btw. That's a good way to do that.  glad rick_h_ suggested that.
<deryck> abentley, in terms of code, I have no complaints.  Looks good!  I do wonder why we even need the logging, if we don't need the error.  I guess it doesn't hurt, thoughâ¦.
<deryck> abentley, but why dirty up the console for would could be a normal operation?  i.e. why not just do nothing and move on?
<abentley> deryck: It's hard to say.  What's Y.log for, if we only use the console for errors?
<deryck> abentley, it's usually a debugging tool, right?  so it implies, we're logging something unexpected or unusual. in this case, we'll log on every juju page, which maybe is unneeded.
<deryck> log for unusual or debugging corner cases, error for when we want the page to blow up because the tool is being used wrong.
<deryck> (and I more asking here, than that I think this is wrong to do.  I'm not sure myself and wanted to discuss it.)
<abentley> deryck: This is an unusual case.  On Friday, bac actually thought the link should never be missing.
<deryck> right
<lifeless> I want us to grab oopses from failed js
<abentley> deryck: And the code assumed that too, of course.
<lifeless> in that scenario a log of things that went odd in the page could be helpful
<deryck> I'd like that too, lifeless
<abentley> lifeless: me three.
<deryck> lifeless, in that case Y.error makes sense, I think.  This is a case were we changed to Y.log since it's not an exceptional situation.
<deryck> abentley, right.  and sense we can have cases where the link isn't present, I wonder if we shouldn't do nothing and move on.  That's our normal approachâ¦ sniff for something in the dom, nothing there?, them do nothingâ¦..
<abentley> deryck: but it would be great if Y.error was reporting an oops, and we'd fixed the problem months ago.
<deryck> abentley, so I don't really mind the log, I just wonder what it buys us?
<deryck> abentley, indeed!  agreed there.
<abentley> deryck: I guess it would make things clearer for someone debugging a structural subscription issue.
<abentley> deryck: But I'm fine with killing it entirely.
<deryck> abentley, fair point.  I'm arguing with myself right now and trying to form a consistent opinion here. :)
<abentley> deryck: there's also the option of logging it with a low priority, e.g. debug.
<deryck> abentley, let's do it lower priority, so we can turn it on if we need, but we're not logging on every request for these pages.  I like that.  That work for you?
<abentley> deryck: Okay.
<deryck> abentley, thanks!  Sorry to make more work for you.  I'll note our discussion in the MP.
<adeuring> deryck: got some time to talk about the sort issues?
<deryck> adeuring, I'm about to get on a call.  Can I ping you after that?
<adeuring> deryck: sure
<abentley> adeuring: I believe you've addressed bug #894745
<_mup_> Bug #894745: No sort on bug listing for most recently changed <bug-columns> <Launchpad itself:Triaged> < https://launchpad.net/bugs/894745 >
<adeuring> abentley: right, thanks for the nocitce :)
<jelmer> I'm getting OOPSes during "make sync_branches", but none of those OOPses actually seem to end up anywhere
<lifeless> jelmer: /var/tmp/lperr/
<jelmer> lifeless: other OOPSes end up there, but not the ones generated by the branch scanner
<lifeless> it may be firing up rabbit
<lifeless> if so, follow my notes to setup a local exchange, and you can suck them out using amqp2datedir (either the main one or the oops-tools one, if you have oops-tools setup as well
<jelmer> lifeless: I'll have a look - thanks
<james_w> launchpad records timestamps for bug reports and bug last changed right?
<james_w> bug reported I mean
<rick_h_> james_w: looking at the db I see a date_last_updated
<deryck> james_w, yeah, we do.  but bug last changed doesn't include comments.  so you have to do the more recent of date_last_updated and date_last_message.
<lifeless> deryck: erm, i seem to recall it does. IMBW
<deryck> lifeless, maybe it does now.  Or maybe I'm completely remembering wrong. :)
 * deryck will look here in a sec
<lifeless> deryck: I am a little concerned at wontfix ing the sort-by-date-of-task bug
<lifeless> deryck: because date of task is the record of 'bug in context'
<deryck> lifeless, ok.  we'll need to either break our basic design premise and stick a sort option on the bar that can never be removed, or add some display info that represents "bug in context age" (or some such)
<lifeless> a quick diversion if you will
<lifeless> let me grab a couple bug numbers
<lifeless> deryck: actually, might be simpler to switch to voice, if you have a few minutes
<lifeless> (ETIRED)
<deryck> lifeless, I don't actually.  About to jump on another call.  And I've been on calls quite a bit today already.
<lifeless> fair enough
<lifeless> I'll blather on here a bit, give you as much context as I can
<lifeless> and you can decide after your calls ;)
<deryck> ok, cool
<lifeless> I can't find the darn bug
<lifeless> so I'll describe it
<lifeless> when a bug has 2 tasks
<lifeless> and you have a search that returns both
<lifeless> we show both
<lifeless> so our collections show tasks, not bugs.
<lifeless> There is a bug about that
<lifeless> for sorts on task columns, the two rows can be widely separated.
<lifeless> for sorts on bug columns they will be adjacent
<lifeless> related to this is our heuristic logic for when-to-show-context (e.g. we show 'project' when searching bugs in a project group, or on a users person +bugs page
<lifeless> so -> seems to me that showing task-created as an optional column should be easy and preserve the design premise (which is pretty nice!)
<deryck> yeah, I guess I have no issues with task-created as an extra piece of visible info.  It's creating it as a sort option in isolation that I don't support.
<deryck> I think it's a bit hard to sum up simply in UI, but maybe just "Task age" as the label.
<lifeless> I think the argument of 'cannot sort on it if you cannot see it' makes a great deal of sense
<lifeless> at least for this data
<lifeless> there is of course one exception - 'relevance', which is a bit hard to show as a column with any meaning
<deryck> right
<deryck> but if we had that, it makes more sense as a sort option that never goes away.
<lifeless> separately, you know what would be sexy. Having closed bugs disappear out of the list in real time
<lifeless> long poll subscribe to all the bugs shown on the batch.
<deryck> lifeless, do you mind re-opening that bug and repurposing it to say "add display info and sort option for bug task age"?  if not, I can grab it later.
<lifeless> re-evaluate their inclusion on the client when they are touched
<deryck> lifeless, and indeed!  I'd love that.
<lifeless> deryck: not at all, I will do that for you
<deryck> lifeless, thanks, man!  And thanks for the discussion.
<lifeless> np!
<lifeless> btw today is my last day for the year
<lifeless> so if you have stuff you want my input on... today is the day :)
<deryck> ok, I have nothing today.  But I'm sure I will tomorrow or the next day. ;)
<lifeless> of course :)
<lifeless> I will probably still be around, things with long tails getting tweaked.
<lifeless> but I won't 'be here' here, if that scans
<deryck> yup, I follow.
<lifeless> https://bugs.launchpad.net/launchpad/+bug/896539
<_mup_> Bug #896539: bug task creation date is not selectable for display and thus can no longer be sorted by <bug-columns> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/896539 >
<lifeless> hows that for a new title
<deryck> perfect! :)
<lifeless> I've added a note about the reopening too. Catch you later.
<james_w> rick_h_, deryck: thanks
<james_w> very useful attributes if exposed over the API
<deryck> rick_h_, are you still around, or EOD'ed?
<rick_h_> deryck: I'm here
<rick_h_> in/out for a few min
<deryck> rick_h_, I'll get those queries now.
<rick_h_> deryck: ty much
<deryck> rick_h_, https://pastebin.canonical.com/57002/
<rick_h_> deryck: sorry had a typo in the id s/1007773/1007731 https://pastebin.canonical.com/57003/
<deryck> rick_h_, better?  https://pastebin.canonical.com/57004/
<rick_h_> deryck: awesome, thanks. That looks more like what I was looking for
<deryck> rick_h_, cool
<bac> hi sinzui
<bac> sinzui: gary and i were talking about bug 480123 and whether the relaxing of the db constraint regarding milestone uniqueness should apply to distros too.  thoughts?
<_mup_> Bug #480123: Milestone names/version should be unique to series <escalated> <linaro> <lp-registry> <Launchpad itself:In Progress by bac> < https://launchpad.net/bugs/480123 >
<sinzui> bac, yes. the rules for distros are the same for projects...there can be only one release version in the history to prevent confusion and security vulnerabilities
<bac> sinzui: right but is relaxing those rules for distros something that bug addresses?
<bac> sinzui: so your previous 'yes' was to that question?
<sinzui> bac I do not think that is what the bug is about. We are not in the business of making it easy to exploit a release.
<sinzui> I think the issue is about making it possible to create an aggregate report of milestones in a project group's sub projects
<sinzui> We do not need to change the constraints if we introduce a group_version that might make pg milestones faster and accurate since there will not no guessing.
<sinzui> bac: but too you question, distros and product must have the same behavior
<gary_poster> sinzui, could we have a call with you anytime soon?
<lifeless> sinzui: whats the exploit ??
<lifeless> s/??/?
<sinzui> lifeless, If there is a defect in one of two version of the same name, how can I be certain I have the fixed version
<lifeless> sinzui: if we show the full name consistently
<lifeless> sinzui: precise/beta1 is not the same as oneiric/beta1
<sinzui> lifeless, correct
<sinzui> lifeless, consider the case of releasing from trunk!
<lifeless> sinzui: so is the issue 'if we make milestone names only unique for a series, we have to audit the UI to be sure we always show the series' ?
<lifeless> sinzui: indeed, and on trunk I can't imagine multiple 'beta' unqualified names being anything other than confusing
<lifeless> sinzui: but someone releasing from trunk could do 0.1-beta1 and we'd be ok with that AIUI
<sinzui> Most project do release from trunk and create series for backporting, so users creating a release want foo-5.beta
<gary_poster> sinzui, but we would still have a constraint that milestones must be unique within a series.  Does that affect your argument?
<sinzui> no, but the UI gets harder.
<lifeless> hmm,also we can't permit whatever our join character is in the milestone name
<sinzui> consider that I can move milestones between series and we support the feature because projects need a mechanism to reorganise themselves when hey grow, or advance
<lifeless> otherwise the milestone 'foo-5.beta' on trunk and 'beta' on 'foo-5' might be hard to tell apart
<sinzui> Moving a released milestone does not change the release version
<sinzui> Users do move released milestones from trunk to a supported series for example
<sinzui> I believe the current proposal support project that use leading series and milestones, which is not the norm. Most work on trunk/master, and use series for supported version
<sinzui> Since the underlying issue is about a project group report, I think we need to be certain we are really solving that issue, and if we solve the timeouts too, instead of exacerbating the,, great
<sinzui> gary_poster, bac, lifeless: project group milestones are the most prone to timeout because the listing grows too long. A good solution will reduce timeouts be making it easier to know which milestones compose the virtual project group milestone
<bac> sinzui: it sounds like you are suggesting a different solution than the one originally discussed in the bug.  a new way to model linaro's grouping using something different from a milestone.  is that right?
<sinzui> yes
<sinzui> The chose to escalate a bug that "sounded" like the solution to their problem
<sinzui> When I looked at the issue and the performance concerns, I seriously considered dropping support for project group milestones...which make matters worse for them
<sinzui> Bac: the non-unique milestone bug is not about reporting, it is about normalising the milestone/release version from the series
<bac> sinzui: but it does allow their report to be generated...
<sinzui> yes. but at the cost that you must move the guard of duplicate releases from the early act of milestone creation to the late act of creating a release. An early mistake is easy to fix, a late mistake is not.
<bac> sinzui: curtis do you have time to for a call with gary and me nowish?
<sinzui> As I said before, no, I am meeting with my team
<bac> sinzui: sorry, i missed your reply.  maybe early tomorrow?
<sinzui> sure. I am free in the morning and isn the late afternoon
<bac> sinzui: ok, great.  we're sprinting and cannot start until 9 am.  10am good for you?
<sinzui> perfect
<bac> thanks.
<cjwatson> wgrant: Hmm.  Was bug 669404 perhaps fixed by your fix for bug 680889?
<_mup_> Bug #669404: support linux-any and similar expansions in Packages-arch-specific <lp-soyuz> <soyuz-build> <soyuz-core> <Launchpad itself:Triaged> < https://launchpad.net/bugs/669404 >
<_mup_> Bug #680889: Needs to handle "all linux-any" like "linux-any" <lp-soyuz> <qa-ok> <soyuz-build> <Launchpad itself:Fix Released by wgrant> < https://launchpad.net/bugs/680889 >
<cjwatson> Could somebody with appropriate privileges mark bug 51763 as Won't Fix?  I left a comment explaining why.
<_mup_> Bug #51763: Add effective tests for archive-cruft-check-ng.py <lp-soyuz> <Launchpad itself:Triaged> < https://launchpad.net/bugs/51763 >
<lifeless> cjwatson: marked it invalid for you
<lifeless> (there is no actual defect..)
<cjwatson> fair enough
<StevenK> sinzui, wallyworld_, jcsackett: http://pastebin.ubuntu.com/768422/
<lifeless> incoming
<mwhudson> jelmer: hey, does the "Always load foreign plugins" change mean we can switch to putting lp:bzr-git in sourcecode?
<lifeless> mwhudson: where is it now ?
<wgrant> cjwatson: I don't think so, but possibly...
<wgrant> cjwatson: Doesn't look like it. P-a-s interpretation is pretty separate.
<wgrant> It's in the same file, but it's handled very different.
<wgrant> differently
<jelmer> mwhudson: it's already in sourcecode, isn't it?
<mwhudson> jelmer: we have some hack to support deregistering don't we?
<jelmer> mwhudson: ah, right. that's no longer necessary
<wgrant> wallyworld_: buildbot is about to fail, with account_status inaccessible.
<wallyworld_> wgrant: ok. i'll deal with it. curtis landed the branch last night so i'll try and figure out why it got past ec2
#launchpad-dev 2011-12-13
<sinzui> wallyworld_, wgrant. yes it is my fault https://lpbuildbot.canonical.com/builders/lucid_lp/builds/1647/steps/shell_6/logs/summary
<wallyworld_> sinzui: np. i'll fix
<wgrant> Were the two branches landed in the wrong order?
<sinzui> wgrant, bingo
<wallyworld_> so no fix required, just restat bb?
<wallyworld_> restart
<sinzui> but they are both in place I  think, but they were landed independent too
<wallyworld_> so it's my fault for messing up the dependencies :-)
<wgrant> I guess run the tests locally to confirm.
<wallyworld_> i had to resubmit both mps due to the first failure
<wallyworld_> and something messed up i guess
<sinzui> wallyworld_, we want to move account status to IPersonPublic...
<wallyworld_> sinzui: from iPersonRestrictedView from memory
<sinzui> this is another case were I considered placing it there since teams do not have accounts, then thought no, I do not want to clutter the interface
<wallyworld_> oh for person and team to be separated properly
<sinzui> wallyworld_, iPersonRestrictedView probably work, I was thinking public based on a from a discussion with flacoste. Public are attrs that are obvious from the knowledge that the team exists. It is as team, it is valid, and it does not have accounts (in this case)
<wallyworld_> sinzui: just looked at the stdout - ec2 did indeed flag the tests as failing i think
<wallyworld_> sinzui: i agree with the rationale you just outlined. IPersonPublic seems thebest place i think
<sinzui> yep, I was watching buildbot independent of wgrant since I believed the issue was a cause by the branch landing before its dep
<wgrant> sinzui, wallyworld_: It needs to public.
<wgrant> Otherwise traversal to a private team will 403 instead of 404.
<wallyworld_> sinzui: so given there's a code change, can i just to a testfix and lp-land, or do i need to rollback and do the ec2 dance again?
<sinzui> land it as a testfix, but you need to do it after the failure
<wallyworld_> please don't make me rollback again :-)
<wallyworld_> sure
<sinzui> buildbot does not notice a pre-emptive testfix :(
<wallyworld_> understood. the wait will give me time to get it prepared
<wgrant> sinzui: It should notice it.
<sinzui> wallyworld_, and pqm-submit it
<wallyworld_> sinzui: yes, i just do a bzr lp-land in such cases
<wgrant> Even if it doesn't, you can just force.
<sinzui> wgrant, I tried a preemptive fix a few months ago and it did not work
<wgrant> sinzui: Hmm.
<wallyworld_> wgrant: aren't you meant to be awol?
<wgrant> sinzui: You have to add [no-qa], but it should work.
<sinzui> wgrant, noted
<mwhudson> wallyworld_: i don't think it's possible to be meant to be awol :)
<wallyworld_> mwhudson: semantics!
<mwhudson> wallyworld_: yes!
<mwhudson> (sorry)
<wallyworld_> i was being very lose with my use of the english language :-)
<wallyworld_> no need to apologise, i'm normally a stickler for that sort of thing
<wallyworld_> eg i HATE how the word "decimate" is misused all the time
<sinzui> wallyworld_, once the tests are fixed, you can do this to skip the 4-6 hours in ec2: http://pastebin.ubuntu.com/768498/
<wallyworld_> sinzui: bzr lp-land does the same thing :-)
<sinzui> I did not know
<mwhudson> wallyworld_: you are an epicentre of linguistic correctness!
 * mwhudson hides
 * wallyworld_ lols
<sinzui> anything else I need to know wgrant, wallyworld_. Perhaps something about how to make buildbot complete in 1 hour?
<wallyworld_> mwhudson: i bet you can't say that last sentence you just typed 10 times quickly :-D
<wallyworld_> sinzui: the parallelisation of the test suite should help :-P
<sinzui> PS. when I say awesome, Id not not mean as in hotdogs with mustard, I mean god-fearing awe
<wallyworld_> noted :-)
<StevenK> sinzui: Removing 80% of the test suite would get buildbot to an hour.
<wallyworld_> i reckon the layer startup/teardown times contribute to a large slice of the time taken too, no?
<lifeless> over the whole test suite, not so much
<StevenK> Like 6 minutes of 4+ hours?
<lifeless> the per-test setup/teardown overheads are pretty large though
<wallyworld_> yes :-(
<wallyworld_> sinzui: i think account_status_comment should also move, just to keep it with account_status. agree?
<wgrant> "Total duration of profiled methods 3152.6 seconds."
<wgrant> So there's only a little under an hour of layer (test)?{setup,teardown}
<wgrant> DatabaseLayer.testTearDown                    13721 calls taking 2051.7s.
<StevenK> An hour of setup and teardown? Faaaark
<StevenK> 35 minutes removing and creating databases. Thanks lifeless.
<wgrant> Not lifeless' fault.
<wgrant> He only changed the names.
<StevenK> Aw
<wgrant> And added an extra template.
<wallyworld_> StevenK: that setp/teardown is what i was alluding to earlier
<huwshimi> erm http://blog.launchpad.net/
<wallyworld_> lifeless: private team. i am the owner. i make someone else the owner, but in so doing i cannot see the team anymore. so at the end of the process, the owner has changed but i see a "you are not authorised" page. should we display a one-off "this has succeeded but you cannot see the team anymore" page?
<wallyworld_> btw, this is after a change to allow owners to view the private team even if they are not members
<lifeless> wallyworld_: just show the page normally; same as for bugs
<lifeless> wallyworld_: erm, or actually, just redirect to launchpad.net/
<lifeless> wallyworld_: perhaps with a notification explaining why
<wallyworld_> lifeless: right. good idea. thanks
<StevenK> So I have a private team. I have invited a public team to be a member. That should show up as a pending invitation, should it not?
<wallyworld_> StevenK: i would have thought so
<wallyworld_> what does it do in actuality?
<wallyworld_> bear in mind i've discovered a few things today about team behaviour by reading to code so my knowledge is patchy
<StevenK> wallyworld_: It doesn't seem to show it at all
<StevenK> I'm wondering if that is expected before I dive into our security adapter
<wgrant> It's expected.
<lifeless> if the private team invites a public team, the private team should be listed on the public teams invitations list.
<wgrant> Only members, private PPA subscribers and Launchpad admins can see private teams.
<wgrant> That's changing.
<lifeless> it won't be showing today, but it it should. :)
<lifeless> there is a bug for this
<wgrant> lifeless: But only shown to the public team's admins?
<lifeless> right
<lifeless> optional the public teams members too
<lifeless> but not to the general public
<wgrant> Right, which is not what you said :)
<lifeless> (by optionally, I mean whatever falls out of the code cleanest)
<lifeless> wgrant: EBRAINISTOAST
<wgrant> Yeah.
<lifeless> my config change has landed
<lifeless> \o./
<wallyworld_> ii thought when StevenK said "pending invitation" it mean that the private team would see a list of invitees who had not accepted yet. but is it the other way around?
<wgrant> But you've seen what happens when one doesn't make completely unambiguous statements about privacy.
<lifeless> hilarity?
<wgrant> Pretty much.
<lifeless> wallyworld_: both directions gain visibility
<wallyworld_> ok
<lifeless> slightly different rules about who sees what
<lifeless> members can see superteams
<lifeless> admins can see subteams
<lifeless> something mumble mumble
<lifeless> there is a bug
<wallyworld_> several perhaps
<StevenK> wgrant: Okay, so I'm seeing expecting behaviour -- I can test for it, or I can fix it.
<StevenK> lifeless: ^
<lifeless> EPARSE
<wgrant> lifeless =1
<wgrant> +1
<nigelb> wgrant: Did you just reassign lifeless? :P
<nigelb> Also, Morning!
<wgrant> A regrettable mistake.
<wgrant> Afternoon.
<StevenK> wgrant: So, fix it?
<wgrant> StevenK: I don't understand what you mean.
<StevenK> wgrant: So, I have two choices. I can test that the current behaviour is correct. Or, I can fix it so that pending private teams are shown to the team admins and write tests for that case.
<wgrant> Or you can leave the behaviour undefined until we finish defining the complete set of new private team behaviours.
<StevenK> No test at all?
<StevenK> Fair enough.
<StevenK> This branch should fix the Person:+index MixedVisibilityErrors as it stands.
<StevenK> Guido van Rossum  -  11:05 AM (edited)  -  Public
<StevenK> Why do Python classes have both _mro_ and mro() ? What was I thinking at the time? Does anyone remember?
 * StevenK laughs.
 * StevenK breaks buildbot into small pieces
<StevenK> Can haz review? https://code.launchpad.net/~stevenk/launchpad/person-index-mixed-visibility/+merge/85427
<wallyworld_> StevenK: looking now
<wallyworld_> StevenK: you should use  "if check_permission('launchpad.LimitedView', team)" in your super_teams method
<wallyworld_> since this by default delegates to launchpad.View
<wallyworld_> and is the required permission to know of a team's existence
<StevenK> Why LimitedView?
<wallyworld_> with LimitedView, a user can know of a team's existence and name, displayname etc
<wallyworld_> but not any other private details
<wallyworld_> so for bug subscribers etc, i precache launchpad.LimitedView permissions
<StevenK> But these are super teams -- teams that the team in question is a member of
<wallyworld_> ah, ok
<StevenK> If you can see the team, you can see everything, so .View is the right choice
<wallyworld_> yes, sorry. i think you are right
<wallyworld_> so what was the issue before your branch?
<StevenK> wallyworld_: People would see <public team>, <hidden>, <hidden>, <public team>
<StevenK> When I added MixedVisibilityError, those <hidden> started raising them
<wallyworld_> if the team in question (the one being viewed) is a member of those <hidden> teams, why weren't they visible?
<StevenK> The person viewing the team page may not have permission to see the team
<StevenK> But members of the team view their own page do.
<wallyworld_> ok, so the user is viewing a public team that may be a member of a private team?
<wallyworld_> and the user may not be able to see that private team
<wallyworld_> ?
<wallyworld_> so in that case we would render <hidden>?
<StevenK> And raise a MixedVisibilityError, yes.
<wallyworld_> if my assertions above are correct, i do think we should be using LimitedView permissions then
<StevenK> The formatter uses View, and gives a link
<wallyworld_> since moving forward, we will be looking to allow a user to view the existence of a private team that is in any public relationship the user can see
<wallyworld_> the formatter should change to use limitedview
<StevenK> And not link them?
<wallyworld_> limitedview by default just delegates to view, so it's the same net effect
<wallyworld_> they should still be linked
<StevenK> And the user gets a 404 when they click the link?
<wallyworld_> but for now, if a user with just limitedview clicks on the links, they get a 404
<StevenK> That's what I'm trying to prevent
<wallyworld_> we are yet to solve that one
<wallyworld_> there's 2 issues - not rendering <hidden>, and making the link work
<StevenK> Besides, the private team isn't in a public position
<StevenK> It just has a public team as a member
<StevenK> It doesn't have to be disclosed by that action
 * wallyworld_ thinks
<wallyworld_> which is different to a private team subscribing to a bug? yes, perhaps?
<wallyworld_> or maybe not, since members of the public team should be able to know who the parent team is?
<StevenK> It is, yes
<wallyworld_> ok, so let's leave it as view for now and we can revisit later if required?
<StevenK> I'm happy with that
<wallyworld_> thought you'd say that :-)
<wallyworld_> i thought it better to ask the question though just in case....
<lifeless> or clarity 'disclosed' is -always- contextual
<lifeless> you can disclose to the public, disclose to a team, disclose to project etc
<wallyworld_> so here we are possibly disclosing to a team i guess
<lifeless> anytime in a discussion if someone says 'disclose' unconditionally, you all have to drink.
 * StevenK finishes his glass of water
<StevenK> Is that what you had in mind?
<StevenK> lifeless: What time is your flight, out of interest?
<lifeless> StevenK: tomorrow?
<StevenK> lifeless: Yah
<lifeless> 0955 departure
<lifeless> but I route via akl
<lifeless> I arrive 1430
<StevenK> It's what, 30 minutes to AKL?
<lifeless> at which point I will be tearing vodafone a new hole amongst other .au business
<StevenK> ... why?
<lifeless> because, a year after I closed my postpay account with them and moved countries, they started emailing me invoices
<StevenK> Haha
<lifeless> now, 1 month after, I could understand, and would have paid without much thought.
<lifeless> a year later? WTF.
<lifeless> actually 14 months or some odd number.
<lifeless> Anyhow, lots.
 * lifeless is extremely unimpressed
<lifeless> I woul dhave rung from here, but their phone system is worse than loading a 3d game on a 16Kb spectrum
<lifeless> I didn't want to use all my skypeout credit for a year while on hold
<wallyworld_> StevenK: with the test_private_superteams_shown() test, i'd like to see another team created that would be <hidden> but is filtered out, since the other tests simply check if the portlet is there or not
<wallyworld_> i guess the tales does that though
<wallyworld_> ie indirectly tests that code path
<StevenK> lifeless: When I moved to Parramatta, I called Telstra and cancelled the landline service, as well as getting a new service for the new place. Fast forward two months, and I get a bill for the landline at the old place, filled with calls after I moved out.
<lifeless> StevenK: win
<StevenK> lifeless: I rang up and said "Please explain" and was told that they "forgot" to action my cancelation
<StevenK> As way of apology, they wrote off the entire bill, which had one charge for the new landline on it.
<StevenK> wallyworld_: So the TALES won't even show the portlet if there are no visible super teams
<wallyworld_> StevenK: yes, i came to that conclusion too so i think it's ok
<wallyworld_> StevenK: for a "proper" unit test, the super_teams() property on the view object really should be tested
<wallyworld_> rather than relying on the template logic to indirectly test it
<StevenK> wallyworld_: I'm happy to add an assert for that
<StevenK> self.assertEqual([], view.super_teams) effectivelty
<StevenK> *effectively
<wallyworld_> StevenK: that would be great; hopefully there's an existing unit test for the view object you can add to simply
<wallyworld_> ah, yes, that works too
<wallyworld_> StevenK: r=me
<cjwatson> wgrant: P-a-s> ah, OK, thanks.  Maybe if I get some time over the holidays ...
<wgrant> cjwatson: That's likely the only way it's going to get fixed unless I get bored, yeah.
<wgrant> :/
<adeuring> good morning
<mrevell> Mornin;
<mrevell> oh, I fail at typing
<jtv> allenap: ndt deployment request underway.  Liam is on it.  Thanks for dealing with that branch.
<allenap> jtv: Tip top, ta :)
* gmb changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: gmb | Critical bugtasks: 3*10^2
<cjwatson> oh my, I didn't realise that maintenance-check.py relied on http://people.canonical.com/~ubuntu-archive/germinate-output/
<cjwatson> I think I'll need to convert that to python-germinate as well for sanity and testability
<cjwatson> bigjools: is it possible that r11088 fixed bug 599412?  It looks as though it ought to have done
<_mup_> Bug #599412: populate-archive --component main doesn't work <derivation> <lp-soyuz> <Launchpad itself:Triaged> < https://launchpad.net/bugs/599412 >
<bigjools> cjwatson: yes, the commit msg says so :)
 * bigjools fixorates
<cjwatson> refers to bug 600165 instead, actually, so unnoticed dup
<_mup_> Bug #600165: COPY archive creation ignores the specified component <derivation> <lp-soyuz> <qa-ok> <Launchpad itself:Fix Released by julian-edwards> < https://launchpad.net/bugs/600165 >
<bigjools> yeah
<bigjools> thanks for noticing
 * cjwatson has been looking through soyuz bugs for things that might improve Ubuntu's life that are accessible to me to fix
<bigjools> sounds like you need a rotation :)
<cjwatson> the thought has crossed my mind, but I think I want to remain focused on things specifically beneficial to Ubuntu rather than LP as a whole; plus Steve might object :)
<cjwatson> might consider it in a year or so
<StevenK> cjwatson: I won't object, but I know you don't mean me. :-)
<jtv> StevenK: actually I was wondering why you would ever object!
<jtv> So a good thing you said it.
 * cjwatson tests germinate 2.3 on mawson and confirms that the only differences are as expected
<cjwatson> so I've followed up to that ticket to say that it's OK to upgrade cocoplum/germanium
<cjwatson> jtv: can https://code.launchpad.net/~cjwatson/launchpad/refactor-cron-germinate/+merge/84624 be Status: Approved as well as having your Approved review?  It's still waiting on a buildbot upgrade before we can land it, but apart from that ...
<jtv> cjwatson: coming
<jtv> cjwatson: done
<sinzui> I think I need to rollback 3 non-sequential revisions :(
<cjwatson> jtv: ta
<jtv> bigjools, wgrant: care to review?  https://code.launchpad.net/~jtv/launchpad/bug-903688/+merge/85485
<bigjools> jtv: I can
<jtv> That'd be great, thanks
<jtv> Anyone know why I would get this error during "make schema" on a db-devel branch?  duplicate key value violates unique constraint "launchpaddatabaseupdatelog_pkey"
<nigelb> someone broke something?
<nigelb> I hope no one broke sampledata.
<jtv> nigelb: maybe I did â don't know.
<jtv> But I re-generated the updated sampledata based on db-devel sampledata, and it doesn't help.
<jelmer> benji: hi
<benji> hi jelmer
<jelmer> benji: Are you still working on bug 808930 ?
<_mup_> Bug #808930: Timeout running branch scanner job <escalated> <linaro> <oops> <Launchpad itself:In Progress by benji> < https://launchpad.net/bugs/808930 >
<jelmer> I've got a bug fix in that area, and I'd like to make sure our changes don't clash.
<benji> jelmer: gmb has taken the helm of that one
 * benji goes to fix the assignee in LP.
<jelmer> gmb: Hey!
<jelmer> benji: thanks
<benji> np
<gmb> jelmer: Hi. I'm only just getting up to speed on this bug, so it may well be that I have to tap on benji's shoulder a couple of times. But anyway.
<jelmer> gmb: ok
<jelmer> gmb: I've got a fix for the branch scanner which should at least make the bzr part of things no longer O(size-of-branch-history)
<jelmer> gmb: that should help with the bug, but it will also likely clash with any changes you've already made
<gmb> jelmer: Okay. So, I'd be inclined to tell you to get your branch landed; I'm not ready to land anythign yet, so I'm happy to clean up any clashes.
<jelmer> gmb: Great, thanks.
<jtv> Anyone know what would make a "make schema" on a db-devel branch violate unique constraint launchpaddatabaseupdatelog_pkey?
<abentley> deryck: Do you think now is the right time to generalize ListingNavigator as we discussed with wallyworld?
<deryck> abentley, jumping on callâ¦. give me a minute to think about that.
<abentley> deryck: sure.
<deryck> abentley, I'm sorry, but I'm blanking on remembering the discussion with wallyworld_.  is this an email discussion?
<abentley> deryck: Yes.  Let me see if I can dig up the subject.
<abentley> deryck: "batch navigation question"
 * deryck is looking at email
<deryck> abentley, ok, right.  I absolutely think now is the time to do that work.
<abentley> deryck: cool.
<deryck> there are a couple minor bugs we still need to fix, but these are fairly shallow.  I may see if rick_h_ can be enlisted for this, to keep you free for this.
<stub> (21:21:48) stub: jtv: Hmm... might need to add a step to reset the sequence.
<stub> (21:22:19) stub: jtv: The value of the sequence would have been set from production with the new baseline?
<stub> (21:24:45) stub: jtv: Although 'make schema' shouldn't care because the table will be empty...
<stub> (21:25:24) stub: jtv: Have you rebuilt sample data and ended up with the contents of launchpaddatabaseupdatelog in it? That would make it explode (and would be a bug - need to exclude that table from sampledata too, along with launchpaddatabaserevision)
<nigelb> wow. I did guess right. sampledata has some brokeness.
<jtv> stub: yes, on two occasions I did âmake newsampledataâ and both times got 1 record for launchpaddatabaseupdatelog per database.
<jtv> I'm about to try it with an unmodified db-devel schema.
<stub> thought the sequence reset magic would take care of it?
<jtv> Frankly I can't even find where the table gets created.
<jtv> Whoops â the sampledata I build from db-devel is broken.
<stub> jtv: The table is in the db baseline - launchpad-2209-00-0.sql
<jtv> Looked there.  It's basically empty.
<jtv> I figured the guts had moved somewhere else.
<jtv> stub: broken baseline?
<jtv> I thought the baseline used to be in that patch â but now I don't see that for 2208 either.
<jtv> Ah wait â launchpad-2209-00-0.sql.  I was looking at patch-2209-00-0.sql.
<stub> If you are on db-devel, 2208 shouldn't exist
<stub> yer
<jtv> I was just cross-checking with devel.
<jtv> stub: fwiw I also looked for launchapddatabaseupdatelog in the sample data for devel & db-devel and did not find any mention.
 * stub waits for trees to sync
<jtv> bigjools: my buildfarm fix has passed soyuz & buildmaster tests.  Think that's enough for a landing?
<bigjools> jtv: yes
<jtv> Yee-haw.
<bigjools> well - code perhaps
<jtv> OK, running that too.
<stub> jtv: So with a fresh tree and make schema, I get LaunchpadDatabaseUpdateLog with one entry with id 1 (from patch-2209-00-2.sql) and nextval('launchpaddatabaseupdatelog_id_seq') is 2.
<jtv> I get the entry; haven't tried the sequence.
<jtv> Presumably that's the part that's wrong.
<jtv> But didn't you say that the table shouldn't be in the sample data at all?
<stub> jtv: There is no need for it to be there.
<jtv> Then how did it get there?
<stub> jtv: I neglected to add it to the blacklist filter in database/schema/Makefile.
<jtv> Is that something you could fix at the moment?
<stub> sure
<stub> jtv: So patches get applied, then we load sampledata. And if the sampledata contains rows they will conflict with any created by upgrade.py
<sinzui> bac: gary_poster is it time to discuss milestones?
<bac> sinzui: yes, sorry, our call ran long.  i'll skype you now
<jtv> stub: thanks for working it out.  Got branches blocked on this, and tomorrow's my last day for the year.
<stub> http://paste.ubuntu.com/769038/ should be the fix
<stub> jtv: Want me to land that?
<jelmer> gmb: actually, looking at the only OOPS for bug 808930 that I can find, it seems like that is in the access of the bzr graph
<_mup_> Bug #808930: Timeout running branch scanner job <escalated> <linaro> <oops> <Launchpad itself:In Progress by gmb> < https://launchpad.net/bugs/808930 >
<jtv> stub: yes please, assuming it's correct.  :)
<jtv> stub: is the whitespace you removed significant?
<gmb> jelmer: benji's theory, AIUI, is that the OOPS is a death-by-SQL problem.
<stub> jtv: You can apply that locally and rebuild your sampledata while waiting to confirm (and even revert the change afterwards - the problem with your branch is the generated sampledata and you can land it without the makefile fix)
<jtv> Right.  I'll try that.
<gmb> jelmer: So I'm not sure whether your fix will help or not...
<jelmer> gmb: yeah, that seems like the most likely cause indeed.. storing a giant (HUUUUGE) graph in a SQL table seems like a bad idea
<stub> jtv: Seems to be working. I'll do a self approved landing now.
<gmb> jelmer: Ssssh, you'll make whoever came up with that idea feel silly....
<sinzui> bac: https://launchpad.net/glade/3.10
<sinzui> bac: https://launchpad.net/grub/grub2
<jelmer> gmb: IIUC it's that way because that's how bzr originally behaved
<gmb> Yeah, I think that's the case.
<jelmer> gmb: I'm sure you've seen https://dev.launchpad.net/Code/BranchRevisions ?
<gmb> jelmer: Yes, I had. (I had repressed it)
<jelmer> hehe
<sinzui> bac: lifeless reported this https://bugs.launchpad.net/launchpad/+bug/644977
<_mup_> Bug #644977: ProjectMilestone is inconsistent, confusing ui, can we just delete it? <confusing-ui> <lp-registry> <Launchpad itself:Triaged> < https://launchpad.net/bugs/644977 >
<rick_h_> benji: ping, have some time to do a voice chat on an api bug: https://bugs.launchpad.net/launchpad/+bug/808952
<_mup_> Bug #808952: NoCanonicalUrl using api to fetch bug comments <api> <oops> <Launchpad itself:Triaged by rharding> < https://launchpad.net/bugs/808952 >
<allenap> gmb: Got time for a tiny review? https://code.launchpad.net/~allenap/launchpad/bugnomination-timeout-bug-874250-heat-death/+merge/85497
<gmb> allenap: Sure thing
<allenap> Ta
<benji> rick_h_: sure.  Skype?
<rick_h_> benji: sure, mitechie is my username
<benji> rick_h_: calling
<jelmer> gmb: Do you have time to review that avoid-revision-history branch? It should now be up at https://code.launchpad.net/~jelmer/launchpad/avoid-revision-history-2/+merge/85501
<gmb> jelmer: I'll take a look once I've finished with allenap's.
<jtv> stub: I seem to have working sample data now, thanks
<stub> np. by branch has landed too.
<sinzui> bac: https://launchpad.net/launchpad-project/+milestones is a mess
<sinzui> while your idea is about declaring them to prevent the cruft from appears
<jelmer> gmb: Merci
<gmb> jelmer: De rien.
* gmb changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 3*10^2
<jtv> bigjools: lot of blockers on the deployment report tonight.  If we're going to get my fix out, looks like we'll have to cowboy.
<bac> sinzui: regarding vouchers, the API they provide is not showing you having anything, which is consistent with the db dump neil provided.  so it looks like a problem between the shop and salesforce
<sinzui> bac: I was replying to that. I was even going to take a screencap of a check out, but I cannot do that at the moment.
<bac> sinzui: i'll buy some too and see if they materialize
<sinzui> Maybe the ridiculous free gift has broken checkout for users that redeem vouchers
<jtv> bigjools: arrrrgh.  Broken test in archiveuploader.  The ordering of a two-item recipients list on a notification email has changed.  :(
<bigjools> hmmm
<bigjools> sounds spurious, which is worse
<jtv> Oh, yes it is worse: I was accidentally running that one on devel!
<jtv> lp.archiveuploader.tests.test_uploadprocessor.TestUploadProcessor.testUploadToFrozenDistro
<bigjools> yay?
<jtv> bigjools: is that the sort of yay that conveys no joy at all?
<bigjools> jtv: Archeryay
<jtv> Ah, _that_ yay
<jtv> Absolutely correct.
<rick_h_> deryck: I've gotten this the last two times I tried to land the inline editor stuff: +bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel
<rick_h_> deryck: the test email comes back success, but that's the PQM test email?
<rick_h_> deryck: sorry, bad paste https://pastebin.canonical.com/57048/
<deryck> rick_h_, you need to look at the log file attached to the email from pqm.
<deryck> rick_h_, either testfix or merge conflict most likely.
<rick_h_> deryck: my bad, totally missed the attachments
<deryck> given buildnot's record, you can guess what you'll get ;)
<rick_h_> ah, actually getting that it doesn't like my commit message. Will check it out then. Thanks, blind today
<deryck> rick_h_, can you look into bug 894726?  Should be trivial to linkify the tags listed.
<_mup_> Bug #894726: Tags not linked on bug listing <bug-columns> <Launchpad itself:Triaged> < https://launchpad.net/bugs/894726 >
<rick_h_> deryck: sure thing
<deryck> mrevell, for that bug ^^ do you care if we just link to the tag list from the new feature lists?
<deryck> rick_h_, that's what I'm thinking, a simple link, rather than all the fancy filtering talk in the bug.
<rick_h_> deryck: ah ok. Yea I was thinking that it's a bit more to do that.
<sinzui> bac, did you succeed in checking out?
<cjwatson> jtv: oh!  good, it's yay for me, it means that it isn't the fault of my new-python-apt branch
<deryck> rick_h_, the link is just "?field.tag=$TAGNAME" -- though we *may* have some helper method to get you the link.
<rick_h_> deryck: ok, I'm finishing getting my notes together for this bug report and I'll peek at it in a few
<cjwatson> jtv: soyuz-set-of-uploads and xx-queue-pages fail for the same reason, and are harder to work around since they're doctests.
<deryck> rick_h_, ok, thanks!
<jtv> cjwatson: I fixed the test that broke for me.  With doctests I usually just sort to get deterministic output.
<jtv> bigjools: I also ran tests for translations and archiveuploader, since they had (mentions of) BuildFarmJob.  Still, having that one test fail made me nervous about landing without waiting for the outcome of the full test run.
<deryck> rick_h_, I'm also going to assign bug 894740 to you.  Should be a shallow js error fix.
<_mup_> Bug #894740: bug heat contextual help opens in a new tab in chromium <bug-columns> <exploratory-testing> <regression> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/894740 >
<rick_h_> deryck: sounds good
<cjwatson> jtv: yeah, it's just awkward in this case since the doctests are testing the entire formatted e-mail
<deryck> adeuring, do we have a bug yet for the "only showing one order by button" bug?
<bac> sinzui: trying now
<rick_h_> deryck: benji just fyi, summary of the findings: https://bugs.launchpad.net/launchpad/+bug/808952
<_mup_> Bug #808952: NoCanonicalUrl using api to fetch bug comments <api> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/808952 >
<mrevell> deryck, re tags: Yeah, that seems like a good solution.
<deryck> mrevell, thanks!
<bac> sinzui: did you report the broken checkout?  mine broke too
<adeuring> deryck: no, not yet, but I'll file one
<deryck> adeuring, thanks!
<cr3> is it supposed to take a while, like hours, after stopping emails for a subscription to actually stop receiving mail from that subscription?
<lifeless> cr3: it could, under exceptional circumstances. More likely is that you have multiple subscription paths to the mails you are getting
<jtv> cjwatson: got another spurious failure â archivesubscription-views.txt.  What happened?
<cr3> lifeless: I've been cross checking with the Launchpad-Rationale in the email header, so I think I have the multiple subscription problem down. I'll be a bit more patient and check again tomorrow
<cjwatson> jtv: that's odd, I don't think I got that failure and I ran all the soyuz tests
<deryck> abentley, adeuring, rick_h_ -- FWIW, I'm done with looking over the bugs again (boy, did that take longer than expected!)
<deryck> abentley, adeuring, rick_h_ -- and short of a few little UI issues that are easy to fix, we're in pretty good shape.
<abentley> deryck: Yes, I agree.  Looked over them yesterday myself.
<jtv> cjwatson: I'm not getting it on my local system either, or running just the soyuz tests in EC2.  Sounds like isolation problem.
<abentley> deryck: A lot of the bugs are $foo is not linked.  Do we know if we actually want to link everything?
<deryck> abentley, I don't think we know, so those are all marked low, except the tags one.  I don't think we should worry about them, unless mrevell and company have design ideas.
<deryck> abentley, as I understand it, product team pushed back on linking everything, not knowing how to style the links.
<benji> rick_h_: was eating lunch, looking now
<rick_h_> benji: np, let me know if you think I should add anything else. Basically the type of object going in there was just Message and nothing else like I had hoped
<jtv> bigjools: I landed my fix on devel as revision 14499.  But there's some real weirdness going on: a test that shouldn't have been affected failed for me once in EC2, and I can't seem to reproduce it.  I'll need to pack it in for the night though.
<benji> rick_h_: so which branch in message_to_canonical_url_data is taken?
<rick_h_> benji: it's the bugs.count() branch
<rick_h_> benji: IMessage has a bugs property
<bigjools> jtv: ok, get some sleep, rest well
<jtv> thanks, see you tomorrow!
<benji> rick_h_: so... the message isn't associated with a bug?  That seems strange.
<sinzui> benji, that is historic cruft I think
<rick_h_> benji: right, most messages are extended and assiciated through a tying table, bugmessage, butattachment do the tying to a bug
<rick_h_> benji: but these are just plain messages created for the record it appears
<benji> hmm, if we can figure out a way for message_to_canonical_url_data to figure out which bug is related then it could return an BugMessageCanonicalUrlData instance and all would be right with the world
<abentley> benji: these messages aren't bug comments.  Are you sure they have (or should have) URLs?
<benji> abentley: they don't now, but exposing them to the REST API may be the thing to do to fix this bug
<rick_h_> abentley: benji yea, I mean they are messages viewable via the web and while not bug comments, might be useful/might expose kind of things
<abentley> benji: I don't think we really want to track all the notifications that e.g. a bug status changed in the API.
<benji> abentley: you might be right; in that case we'll have to figure out how to hide the notifications from the part of the API that can "see" them now (which is the source of the bug rick_h_ is working on)
<bigjools> webops: when qastaging updates, does the bzr server restart? I already established that the librarian does not ...
<bigjools> echan
<thedac> bigjools: I will check
<rick_h_> what's the right replacement for dir() on an object instance I can use to interrogate things?
<abentley> rick_h_: dir(zope.security.proxy.removeSecurityProxy())
<rick_h_> abentley: cool thanks
<abentley> deryck: I'm thinking of switching "var namespace = Y.namespace('lp.app.listing_navigator');" to "var module =â¦" for consistency with the test code.  Thoughts?
<rick_h_> abentley: does the server side mustache stuff allow for the {{#field}}{{.}}{{/field}} syntax?
<abentley> rick_h_: Yes, AIUI, the dot is supported.
<deryck> abentley, yeah, I like module better than namespace.
<lifeless> abentley: deryck: so, after using moustache for a bit; do you like it? has it saved time / costed time but added features / <other> ?
<deryck> lifeless, I find it tremendously easier to edit than tal. that seems time saving to me.
<deryck> lifeless, it has it's own syntax oddities to me.  but generally, I've liked using it a lot.
<abentley> lifeless: Like JavaScript, I like the capability it gives, without being a big fan of the language itself.  Both the JavaScript and Python implementations have bugs that entail pretty gross hacks, and the JavaScript implementation is noticeably slow.
<lifeless> abentley: do we need to fix those before we advocate for wider use; or should we look for a better alternative with the same capabilities?
<rick_h_> the nice thing is that handlebars (mustache improved) will be included in YUI 3.5 as Y.handlebar and the 3.5 PR1 was released today
<abentley> lifeless: The JavaScript slowness is potentially a dealbreaker.  Other than that, I'd cautiously recommend it.
<rick_h_> I'm not sure though on a pure python implementation
<abentley> rick_h_: There's no pure Python implementation, AFAICT.
<lifeless> of handlebars ?
<abentley> rick_h_: I would be very reluctant to use handlebars on the client side while using mustache on the server side.
<abentley> lifeless: right.
<rick_h_> abentley: agree
<lifeless> how big is the delta? could we sensibly tweak moustache (python) into handlebars (python) ?
<deryck> I thought handlebars was the same as mustache,  but more performant.  that compatibility-wise they were the same.
<abentley> lifeless: handlebars is a superset of moustache, if what I've read was true.
<abentley> lifeless: So the risk would be accidentally using handlebar-specific features.
<abentley> lifeless: And then having them break server-side.
<lifeless> http://thinkvitamin.com/code/getting-started-with-handlebars-js/ is a post from the handlebars author
<lifeless> it appears to be totally separate but inspired by
<rick_h_> lifeless: well the front page of handlebars says "Mustache templates are compatible with Handlebars, so you can take a Mustache template, import it into Handlebars, and start taking advantage of the extra Handlebars features."
<rick_h_> but yea, you'd get used to all the good bits of handlebars and then lose them on the server side
<lifeless> intruiging
<lifeless> so the question to me, is how big is that delta
<rick_h_> so might not work out after all, I had secretly hoped there was something server side for it
<rick_h_> lifeless: I'm going to guess a bit since handlebars allows things like moving up/down the call stack
<lifeless> we could use node.js on the server
<rick_h_> just skip the server side initial rendering ;-)
<lifeless> thats harder to swallow
<lifeless> per code.google.com/web/ajaxcrawling/docs/getting-started.html which flacoste dug up the other day
<lifeless> one thing we could do is dev/test with moustache.js but use handlebars as an accelerator in [qa]staging+prod
<lifeless> that has its own risks, of course
<rick_h_> I still think the answer isn't to get the bug listings crawled, but the bugs themselves and that there should be a way to get that information to a crawler without being visible
<rick_h_> a paginated list of bugs is going to change around over short periods of time and not be a good landing/search page result anyway
<lifeless> yes and no
<lifeless>  /+bugs is reasonably constant
<lifeless> and we want its changes to be indexed anyhow because of 'heat'
<lifeless> other arbitrary searches - yeah, 'meh'. OTOH they don't have much juice today.
<rick_h_> I thought that was going away/getting altered though
<lifeless> what is a concern though is ensuring that the bugs get indexed
<lifeless> rick_h_: its been less special cased.
<lifeless> rick_h_: but as a page its not going away
<lifeless> gotta run. great chatting - sounds like fun stuff to play with. Ciao.
<rick_h_> ic, I'll have to look sometime though. I wonder if there's a better way to note/point the robot to something like a canonicalurl for all bugs on the page
<rick_h_> have fun lifeless
<deryck> gah!  I just want to run tests in lazr.batchnavigator and have no clue how to build it.  it hates me.
<deryck> gary_poster, perhaps you can help here ^^ ?
<deryck> just looking for simple build instructions for a lazr package.
<benji> deryck: I think it's buildout-based, you'll want to bootstrap it and then run bin/buildout and then bin/test will run the tests
<gary_poster> deryck, I dunno that package.  we used to have instructions to put a file on how to build the package
<gary_poster> deryck, and it would link to this wiki page:
<deryck> benji, yeah, I tried that.  both with symlnks to download-cache and eggs and not.  it blows up regularly and angrily :)
<gary_poster> deryck, https://dev.launchpad.net/HackingLazrLibraries
<deryck> benji, I think it's expecting something installed system wide and I can't work out what.
<gary_poster> deryck, I think the file was HACKING.txt
<deryck> gary_poster, thanks for the link.  looking....
<gary_poster> Dunno if that is there
<gary_poster> welcome
<benji> deryck: it may actually be the opposite, it may be assuming that you're using a clean Python (or virtualenv)
<deryck> ah hmmmm
<rick_h_> abentley: doesn't appear that it supports the {{.}}, had to convert things to a dict and use the key and that works
<wallyworld_> sinzui: jcsackett: can we make the standup 30 minutes earlier today? i have a denist appt with the kids i need to get to
<sinzui> wallyworld_, sure
<sinzui> wallyworld_, 1. the nasty rollback is in build bot
<sinzui> wallyworld_, 2. I have sent of the non-feature test refactoring to ec2
<sinzui> wallyworld_, 3. i have reproduced the traversal issue I saw in qastaging
<sinzui> wallyworld_, do you have time to mumble now about how we want to test this non-obvious issue in the future
<deryck> benji, that was it!  Had to use virtualenv for clean env, and all is well.  Thanks!
<benji> deryck: cool; many buildout-based projects are like that, depending on a clean environment for sane reproducable builds
<wallyworld_> sinzui: sorry, just was having breakfast. we can discuss on the call
<sinzui> okay
<sinzui> jcsackett, mumble?
<jcsackett> sinzui: oh, right. be on in just a moment.
#launchpad-dev 2011-12-14
<jtv> Really looking forward to parallel builds.  One thing I really hate in the morning is finding that the branch I landed last night hasn't been through Buildbot yet.
<StevenK> jtv: Oh yeah
<StevenK> jtv: "I've been ignoring IRC and stuff for over 12 hours, and buildbot hasn't passed once!"
<jtv> I'm surprised to find myself saying it, but that fact would have been more comforting if at least a build had failed in the meantime.
<jtv> Well, db-devel did of course, but that aside.
<StevenK> buildbot is up to ~ 6 hours a run, too
* StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK | Critical bugtasks: 3*10^2
<StevenK> Might as well put myself in the topic, given it's my last OCR for the year
<jtv> StevenK: I'll just join you, for the same reason.
* jtv changed the topic of #launchpad-dev to:  https://dev.launchpad.net/ | On call reviewer: StevenK, jtv | Critical bugtasks: 3*10^2
<jtv> There's been no visible progress in Q/A either
<jtv> wallyworld_: I see sinzui landed a branch for youâ¦ it's just one of many Q/A blockers right now, but any chance you could get it out of the way?
<wgrant> jtv: The one that's bad and rolled back?
<wallyworld_> jtv: i'll have a look. i didn't realise it was out of buildbot
<jtv> wgrant: no, the first blocker on the list.
<wgrant> Revision 14489 is bad: possible blocker.
<wgrant> bad, not needstesting
<jtv> wallyworld_: we were just discussing how it does take far too long for a branch to come out of buildbot
<jtv> Argh, yes, must be the lack of coffee.
<jtv> wallyworld_: never mind â it seems to be broken.
<jtv> In which case: do you know whether a fix is in the works?
<wallyworld_> jtv: yes, bb is too slow. what we are waiting for now is the fix to get through bb
<wallyworld_> the rollback in fact
<jtv> Ah.
<wallyworld_> there's a new mp which is approved which should sort it all out
<StevenK> The MP has been merged onto DF
<StevenK> Julian's wrath be damned
<wallyworld_> StevenK: have you tried anything yet?
<StevenK> Not much, to be honest.
<StevenK> wallyworld_: Have at it
<wallyworld_> np. will do
<wgrant> Should all be easily reproducible locally.
<poolie> wgrant, iwnbni there was a "content is private" ff
<poolie> ff scope
<wgrant> Perhaps if we had a way to determine privacy...
<huwshimi> Does anyone here have permission to edit http://blog.launchpad.net/ ?
<wgrant> Yes.
<poolie> in the context of thanks buttons you can do a context.is-private
<poolie> *is_private
<poolie> huwshimi, me
<wgrant> poolie: For some things.
<huwshimi> Could one of you take a look and see if there's a bunch of blank lines at the end of the latest post?
<wgrant> That is a lot of nbsps;
<wgrant> Fixed.
<poolie> openid requires you attempt to click this button
<huwshimi> wgrant: Thankyou!
<wgrant> np
<poolie> huwshimi, how about if i just make you an editor?
<huwshimi> poolie: That would be great
<poolie> please thank you mum for giving you an easily greppable name
<huwshimi> I thought I was
<huwshimi> poolie: hah
<poolie> *your
<poolie> try now?
<huwshimi> poolie: Ah great, thanks heaps
<sinzui> StevenK, wallyworld_, archive access looks correct on dogfood. Have you tried it?
<wallyworld_> sinzui: no. i'm just writing up a mp and will try it as soon as i hit "enter"
<wallyworld_> i can try now though
<StevenK> sinzui: I had a bit of a look. I can have a closer look if you wish.
<wallyworld_> sinzui: as me, i went to the link as suggested in the mp and it renders ok
<sinzui> StevenK, I have tried a few ppas. I think this is good. I can see the build, which could be argued as a no-no, but that is already visible to subscribers
<StevenK> wallyworld_: s/qastaging/dogfood/ ?
<wallyworld_> StevenK: dogfood
<wallyworld_> sorry, ambiguous
<StevenK> I can see the private team and the archive
<sinzui> StevenK, you can see the index page?
<StevenK> Of the team, yes
<sinzui> I cannot see the team page.
<sinzui> StevenK, are you playing admin again?
<StevenK> Oh, bloody hell, I think I have a duck
<wallyworld_> StevenK: in qas, i get an unauthorised error
<wallyworld_> for that link
 * StevenK looks for his duck
<sinzui> StevenK, I removed myself from commercial admins to be sure I could not see private teams I was not a member of
<wallyworld_> which makes sense since the rollback hasn't landed
<StevenK> Right, I have unducked myself
<StevenK> Okay, I can see the archive
<StevenK> I can not see +packages
<StevenK> But that is expected
<StevenK> And I can't see the team
<StevenK> Land it!
<sinzui> I think I will
<StevenK> sinzui: I'm very tempted to delete PersonGPGView for being a crime against humanity.
<sinzui> It does have its probelms
 * wallyworld_ crosses his fingers for 3rd time lucky with this branch
<StevenK> sinzui: Do you have a suggestion for what I can spend the rest of the day on?
<sinzui> StevenK, I have been pondering a desktop tool that lets me manage keys and signings without visiting Lp pages. gpg, coc, ssh all suck
<StevenK> Oh, the gpg edit page lies too
<StevenK> If you deactivate your key it warns it will deactivate your CoC signature too. But it doesn't.
<sinzui> StevenK, I wonder if your permission changes for nominations makes this bug any easier to solve https://bugs.launchpad.net/launchpad/+bug/297528
<_mup_> Bug #297528: Permissions not checked properly when deciding whether to present "Target" or "Nominate" link <lp-bugs> <trivial> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/297528 >
<StevenK> Hmmm
<sinzui> This annoys me too, but I think this is not really related to our recent permission changes: https://bugs.launchpad.net/launchpad/+bug/892025
<_mup_> Bug #892025: Forbidden following link to configure code hosting <403> <trivial> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/892025 >
<sinzui> StevenK, There is actually a featurette I would like to have fixed. I want a page or portlet that lists all the teams I own. i usually cheat and query staging
<StevenK> sinzui: In terms of the last one, we should not show the link if the user can't see trunk?
<sinzui> StevenK, I do not think privacy is the issue. I think the user is not an owner or driver so has no permission to set the series branch
<StevenK> Right. We can actually cheat for that
<StevenK> BugTask.userHasDriverPrivs(project, user)
<StevenK> If that's false, no link
<sinzui> StevenK, Given the misadventures with private teams. I really do not think any of us should work on the social private teams until the branch is qa-ok
<StevenK> Agreed.
 * StevenK tries to work out which template adds that link
<sinzui> StevenK, than said I would like to know more about this https://bugs.launchpad.net/launchpad/+bug/611617
<_mup_> Bug #611617: private teams cannot be package maintainers <disclosure> <lp-soyuz> <privacy> <teams> <Launchpad itself:Triaged> < https://launchpad.net/bugs/611617 >
<wgrant> I really have no clue how to solve that one.
<sinzui> StevenK, If everything is private there should be no issue, but I think the issue here is that I could copy the package to a public archive
<StevenK> That is a tough one
<StevenK> SPR's inherient their privacy from the archive
<StevenK> I think we should allow it for private archives
<StevenK> But that then makes copying the SPR out even worse
<StevenK> Perhaps we should just reject it with a better message
<wgrant> StevenK: With the minor issue that then you can detect private teams.
<wgrant> This is why our model is so hilariously broken.
<StevenK> Right
<StevenK> sinzui: Shall I revert your branch off DF?
<sinzui> Oh, yes please. Has it clear buildbot?
<StevenK> PQM, or buildbot?
<wgrant> (the current approach to social private teams is even more of a trainwreck than legacy disclosure -- it's going to be just about impossible to tell who can see what, which is exactly the problem we're trying to solve)
<StevenK> I think we should just disclose all private teams.
<StevenK> The feature is called 'disclosure' after all.
<wallyworld_> lol
<StevenK> sinzui: Right, that configure codehosting thing is easy.
<sinzui> StevenK, wgrant: I added a comment about how we enforce the spr.maintainer restriction and muse about the options: https://bugs.launchpad.net/launchpad/+bug/611617
<_mup_> Bug #611617: private teams cannot be package maintainers <disclosure> <lp-soyuz> <privacy> <teams> <Launchpad itself:Triaged> < https://launchpad.net/bugs/611617 >
<StevenK> sinzui: If the team is private, they will be disclosed if the SPR is copied to a public archive
<wgrant> Perhaps private teams can't have email addresses.
<StevenK> And then they can't be maintainers
<wgrant> Exactly.
<sinzui> wgrant, I have considered such a restriction, I am not sure we can stop it
<wgrant> sinzui: Oh?
<sinzui> wgrant, I think users would rebel
<wgrant> Users can be told that they are wrong :)
<wgrant> We need to consider the usecases.
<wgrant> And then counter all of them :)
<sinzui> I should know how many private teams set the contact address, and how many of those are not an lp list
<StevenK> I think we should just forbid it
<wgrant> There are difficulties.
<wgrant> eg. package maintained by $RANDOM_OEM_TEAM_ADDRESS -- what do we show in LP?
<wgrant> However, we already have tonnes of unclaimed teams anyway...
<StevenK> Yes, farming for private team names being prime among them
<wgrant> A few more won't kill us.
<lifeless> yo hohoho
<StevenK> lifeless: How was your flight(s)?
<StevenK> Sigh. Timeouts on DF
<lifeless> inebriated
<StevenK> Oh, you've started drinking already? :-P
<wallyworld_> StevenK: why does the configure_codehosting method return False? I would have expected to see None
<adeuring> good morning
<rvba> Hello adeuring.
<adeuring> hi rvba!
<danhg> Morning
<jtv> wgrant: I couldn't manage to trigger a build on dogfood last time; maybe I just dput it wrong.  On phone now; will see if I can get help
<wgrant> jtv: You don't have to upload something new.
<wgrant> You can copy or retry.
 * jtv retries
<jtv> wgrant: I wonder if I could reproduce the problem by retrying builds somehow.
<wgrant> jtv: That would be the easiest way, yes.
<jtv> Question is: what do I retry?
<wgrant> Any old failed build that is superseded.
<jtv> Superseded by a successful build?
<wgrant> Doesn't matter.
<wgrant> As long as the source is superseded.
<jtv> How do I tell?
<wgrant> Just find an old version of something in Ubuntu that has a failed build.
<jtv> There's a whole bunch of old test uploads for "hello" on dogfood: https://dogfood.launchpad.net/builders/concordia/+history
<jtv> Can I just retry a bunch of those?
<cjwatson> jtv: All the sysadmin bits are done now; do you think you could send https://code.launchpad.net/~cjwatson/launchpad/refactor-cron-germinate/+merge/84624 to EC2 for me?
<cjwatson> http://paste.ubuntu.com/769864/ is my ~/.dput.cf for dogfood, BTW
<cjwatson> pretty sure I uploaded at least one of those 'hello' versions
<jtv> cjwatson: I'm afraid I can't.
<jtv> Long story, but basically won't work.
<jtv> wgrant: maybe you could land colin's branch?
<jtv> wgrant: Also, can I just retry one of those "hello" test uploads?
<wgrant> If the corresponding source is superseded, sure.
<wgrant> Which it may not be because of the lack of regular DF publisher runs.
<wgrant> I can only run ec2 from my lucid container, which I swore not to start up for at least a few days after EOY.
<jtv> wgrant: I can just run the publisher I guess.  Question is: will that definitely supersede the hello uploads?
<wgrant> If they're in the same domination context.
<jtv> They're all identical except in version number.
<wgrant> Or you could just find a failed build from dapper or something.
<wgrant> The packages don't matter.
<wgrant> The location does.
<jtv> These are the only builds I see for this builder.  The other builders are disabled
<wgrant> Is that relevant?
<wgrant> Things will build on any builder that's configured correctly.
<wgrant> And for our purposes we can configure concordia and clementine any way we want.
<jtv> OK
<jtv> linux and gnome-shell may be a bit much to build here.
<jtv> Ah!  base-files.
<jtv> wgrant: base-files on ferraz had some older, failed builds.  Will that work?
<wgrant> I'm not sure how that would affect anything.
<jtv> Discuss.
<wgrant> The builder isn't relevant.
<wgrant> We don't even really care to any significant degree if the build succeeds or not.
<wgrant> We care that builds still dispatch, and that builds are correctly marked superseded when they are superseded.
<jtv> Right.  My concern right now is to try and get builds marked superseded, to see if that works.
<jtv> What I'm trying to get out of you is which build I could retry at this point to trigger that code path.
<wgrant> Retry any build for a superseded source.
<wgrant> If it doesn't immediately start building, check the builder configuration.
<wgrant> And reassign one of the builders to match the build's config.
<wgrant> Even if it's for like powerpc or something.
<wgrant> Because we don't care if it fails.
<jtv> Can I enable some builders?
<cjwatson> bigjools: would you be available to send https://code.launchpad.net/~cjwatson/launchpad/refactor-cron-germinate/+merge/84624 to EC2 for me?  Neither jtv nor wgrant can, at the moment
<bigjools> cjwatson: sure
<wgrant> jtv: Only if "some builders" â {ferraz,rubidium,concordia,clementine}
<jtv> Aren't those the only ones we have on dogfood atm?
<wgrant> Nothing else is accessible.
<jtv> Also, why a _proper_ subset?
<wgrant> Sure, but the others can be revived on DF if someone is sufficiently misguided or creative :)
<wgrant> Because I am lazy at tracking down Unicode characters :)
<wgrant> â if you must
<cjwatson> bigjools: hooray
<jtv> Thank you.
<cjwatson> (Hmm.  Do we think there'll be an opportunity for a cocoplum rollout after this at some point before the end of the year, what with lots of people being away?)
<jtv> I certainly hope so.
<jtv> We've got some fixes lined up for it.
<wgrant> If we can deploy the poppy fix in the next day or two, future cocoplum rollouts should be relatively harmless and require minimal supervision.
<wgrant> Whereas all Soyuz rollouts at the moment require close observation.
<jtv> You call it observation, I call it disaster tourism.  Looks like some builds on dogfood are now stuck in the uploading phase.
<wgrant> jtv: There's a cron job for that.â¢
<bigjools> jtv: you need to run a script
<wgrant> Probably disabled, though.
<bigjools> it is
<wgrant> Don't enable that, or bigjools will SMACK YOU ON THE HEAD
<bigjools> DF doesn't have enough coal
<jtv> bigjools: thank you, I'll just run a script then shall I?
<bigjools> jtv: perfect :)
<wgrant> bigjools: Well, more than puppet steals all of the little coal that DF has...
<bigjools> tell me about it
<jtv> But... but... what about its _carbon footprint_?  :)
<jtv> bigjools: any script in particular..?
<bigjools> jtv: it needs to be bigger
<wgrant> bigjools: That's also behind most of the recent PPA builder unreliability, it turns out.
<jtv> bigjools: run a bigger script?
<wgrant> bigjools: puppet is causing the hosts of several builders to OOM
<bigjools> jtv: "crontab -l" and find the process-upload that deals with builds
<jtv> âIt's Puppet!  Help!â
<bigjools> wgrant: \o/
<bigjools> nobody pays attention to memory usage when coding these days
<wgrant> and also ruby.
<bigjools> that's the tradeoff with GCed languages
<wgrant> Well.
<wgrant> Python is particularly bad.
<wgrant> And Ruby is far worse than Python.
<wgrant> It's not really the GCedness.
<bigjools> let me guess... puppet is Python?
<wgrant> Puppet is Ruby.
<soren> Ruby
<jtv> Python is mostly bad in how much memory it uses in the first place.
<wgrant> jtv: Right.
<bigjools> well when you start doing your own new/malloc, you are very aware of memory :)
<wgrant> The GC is not a problem.
<jtv> process-upload --builds has finished
<bigjools> depends on the problem
<jtv> All serious programmers should go through stages of manual memory allocation.  And preferably machine code, to teach them how useful structured programming is.
<bigjools> how many GCs are there for Java? :)
<bigjools> jtv: +1
<jtv> bigjools: java is different.  It produces more garbage.
<bigjools> I was horrifed a school teaching kids how to use MS products in an "IT" lesson
<bigjools> fix grammar as appropriate --^
<jtv> IObjectCreationFactory object_creation_factory = new ObjectCreationFactory(); IMyObject my_object = object_creation_factory.makeObject();
<wgrant> bigjools: That's pretty universally nowadays.
<wgrant> Computing courses are MS + Java.
<bigjools> wgrant: an Aussie school :/
 * jtv prefers informatics over information technology, really
<wgrant> bigjools: Oh, you mean like a primary or secondary school?
<bigjools> I handed them my business card and talked about Ubuntu
<bigjools> primary
<wgrant> IT classes involve teaching Microsoft Office
<bigjools> exactly
<wgrant> And old versions of Dreamweaver.
<wgrant> Or FrontPage 2000.
<wgrant> Although my old high school recently started teaching VB6 in year 8.
<wgrant> Let's just ignore that VB6 was superseded 9 years ago.
<wgrant> At least it's something.
<jtv> wgrant: "year 8" as in "2003 years ago"?
<wgrant> 2003 was year 7, tyvm.
<jtv> Well they were 1-based then.
<jtv> As can still be observed in VB6.
<wgrant> Heh
<jtv> Apparently Dijkstra once proposed the compromise of having arrays start at 0.5.
<wgrant> Although my uni teaches Python, then goes into C, then Java, then Haskell and Prolog.
<wgrant> No C++, which is odd.
<jtv> It's not a great teaching language today.
<cjwatson> Mine started with ML on the grounds that more or less nobody knew it already so it created a level playing field.
<wgrant> Huh, interesting choice.
<jtv> It's supposed to be pretty good, no?
<rvba> IIRC IÂ started with OCaml based on the same assumption I guess.
<cjwatson> It's not a bad language.
<cjwatson> Not that I've retained very much of it.
<wgrant> Oh, sure, it's not bad. Just a rather unconventional choice for a first, I would have thought.
<wgrant> jtv: How goes the dogfood wrangling?
<cjwatson> Right, it was because the course population was part self-taught-programmers and part people starting from scratch.
<wgrant> cjwatson: Ah.
<jtv> wgrant: still building an old hello.  But I'm not sure it's properly superseded.
<wgrant> cjwatson: These days they tend to just ignore the self-taught people and let them rot.
<cjwatson> Speaking as a self-taught programmer, I liked our approach. ;-)
<wgrant> And then they go and do stuff like spend implausible amounts of time on Ubuntu and LP instead.
 * bigjools was taught algol68...
<cjwatson> My MUM was taught Algol 68
<bigjools> thankfully I had already taught myself C
<cjwatson> On punched cards
<bigjools> is this turning into a your mum joke? :)
<cjwatson> No, I'm actually serious :-)
<bigjools> I know :/
<cjwatson> Oh, maybe it was 60
<bigjools> my uni was so up to date
<wgrant> bigjools: .au schools are unlikely to do anything except Microsoft, because all the state education departments have hugely expensive contracts with Microsoft which give unlimited licenses of just about every product to primary and secondary schools.
<bigjools> wgrant: I'll see about that when I get there
<jtv> Getting a $100 discount on a $150 license must be better than a $0 discount on a free license.
<bigjools> I already converted my local school here :)
<wgrant> jtv: The schools have to pay nothing.
<bigjools> it's insidious MS practice
<wgrant> jtv: The state government pays it all.
<wgrant> And it's not cheap.
<jtv> bigjools: So THAT's it.  You're done here, time to move to the next one
<wgrant> Exactly.
<wgrant> It's a very effective abusive Microsoft tactic.
<wgrant> So all the schools see is that all this Microsoft software is completely free!
<wgrant> No licensing concerns whatsoever.
<wgrant> jtv: That source doesn't look very superseded.
<wgrant> However, the build succeeded, so that's one case tested...
<wgrant> Is the publisher still going, or has the dominator broken?
<wgrant> There's like 40 versions of hello published in precise-release, which is somewhat unconventional.
<gmb> stub, I've updated https://code.launchpad.net/~gmb/launchpad/openid-data-integrity-bug-894390/+merge/84750; could you take a look when you get a second?
<jtv> wgrant: yay!  The other build I was waiting for says "Build for superseded Source."
<wgrant> jtv: That sounds qa-ok if there's no traceback around.
<jtv> Where would I find the traceback?
<jtv> The builder went back to idle, by the way, as it should.
<wgrant> /srv/launchpad.net/dogfood-logs/buildd-manager.log or something like that.
<wgrant> That's a good sign.
<wgrant> jtv: Looks like this is close to deployable.
<wgrant> (the bad rev has an untagged rollback in r14500)
<jtv> wgrant: a few things that _might_ be bad in the logs, though I'm hoping they're not:
<jtv> Builder 'clementine' rescued from 'bb672c8535728724706a9b7885dba0c11f084c5b': 'No job assigned to builder'
<jtv> Builder 'clementine' being cleaned up from ABORTED
<bigjools> that's ok
<jtv> This is after some no-route-to-host errors for clementine.
<wgrant> That's fine.
<wgrant> Just clementine being clementine.
<jtv> concordia logs some frightening but, on closer inspection, probably okay stuff: ***** RESULT ***** etc.
<wgrant> That's normal.
<wgrant> Soyuz likes stars.
<jtv> No tracebacks.
<jtv> I have to leave very soon.  bigjools, is this enough for you to carry on with?
<bigjools> jtv: did you retry a failed, superseded build?
<bigjools> that's all you need
<jtv> Yes.
<bigjools> then it's ok
<jtv> I marked it qa-ok.
<wgrant> Two tiny bits of abentley QA, then you can deploy.
<wgrant> Oh, and jelmer.
<jtv> When does db-devel get updated?
<jelmer> oh, hullo
<wgrant> jtv: At the next */10 after buildbot completes.
<wgrant> jtv: Why?
<jtv> Got a db-devel branch waiting to land, once a particular devel revision has been merged in.
<wgrant> Ah.
<jtv> Won't pass tests without that revision.
<wgrant> Really?
<wgrant> Oh.
<wgrant> Right.
<jtv> It's the test, mind you, not the "real" code
<wgrant> Because the populator tests will create them unset.
<wgrant> Never mind me.
<jtv> Exactly.
<jtv> bigjools: I left instructions on bug 849683.  Would be most grateful if you could pursue.
<_mup_> Bug #849683: {B,S}PPH Populator are temporary <disclosure> <qa-untestable> <Launchpad itself:In Progress by jtv> < https://launchpad.net/bugs/849683 >
<jtv> Please let me know now if I left anything out!
<bigjools> jtv: ok!
<jtv> It looks as if, if I wanted to play things fast & loose, I could pqm-submit the second branch right now.  Butâ¦
 * jtv is off.  HNY!
 * cjwatson tries to bisect that test problem jtv mentioned yesterday (swapped e-mail addresses in a few soyuz tests)
<wgrant> cjwatson: I have a suspicion it's arch differences.
<wgrant> I've only seen it on i386 so far.
<wgrant> buildbot/ec2 are amd64
<cjwatson> It started somewhere between r14434 and r14450
<cjwatson> (Because I didn't see it while working on refactor-cron-germinate, which I branched from r14434)
<wgrant> Ah, hm.
<wgrant> Interesting.
<cjwatson> Although I'll verify that in a bit ...
<cjwatson> wgrant: Sorry, I'm wrong.  I must just not have run those tests.
<cjwatson> Ah
<cjwatson>     recipients = [
<cjwatson>         format_address_for_person(person)
<cjwatson>         for person in filter(None, set(candidate_recipients))
<cjwatson>             if person.preferredemail is not None]
<cjwatson> So that's non-deterministic because it depends on what order set(candidate_recipients) happens to iterate in
<StevenK> Is that in notify() ?
<cjwatson> lib/lp/soyuz/adapters/notification.py:get_upload_notification_recipients
<StevenK> Because it looks horrifingly familar
<StevenK> It is
<cjwatson> Maybe TestMailer.send should sort?
<StevenK> That's notify(), effectively
<cjwatson> Rather than imposing sorting on production
<bigjools> IIRC something sorts somewhere
<cjwatson> Doesn't seem to here
<cjwatson> reject_changes_file calls get_upload_notification_recipients and passes the answer to send_email
<StevenK> cjwatson: Most of that code is my fault.
<cjwatson> er, send_mail
<StevenK> cjwatson: However, you should have seen it before I hacked it to pieces.
<cjwatson> How about I file a bug and ignore to-address ordering failures in the branch I'm working on?
<StevenK> cjwatson: So, to-address ordering is actually causing you issues?
<cjwatson> Yes
<cjwatson> Let me file this bug and point you to it rather than repeating it all :-)
<cjwatson> StevenK: bug 904220
<_mup_> Bug #904220: Soyuz tests with lists of e-mail addresses are non-deterministic <Launchpad itself:New> < https://launchpad.net/bugs/904220 >
<StevenK> Hmmm, I see.
<StevenK> Interesting how set() behaves differently on i386 vs amd64.
<wgrant> Hardly.
<wgrant> The ordering is undefined.
<StevenK> Well, *I* find it interesting. You may not.
<bigjools> in a testicle scratching kind of way
<StevenK> bigjools: While I remember, it looks like the instant diff works fine!
<bigjools> yay!
<StevenK> bigjools: However, it doesn't AJAX-ify the other information that creating a diff shows
<bigjools> there's a bug about that
<StevenK> bigjools: Such as "Diff against target". Is there a bug?
<StevenK> Ah
<bigjools> look for tag "longpoll"
<bigjools> this is why only ~launchpad can see it for now
<StevenK> bigjools: How are you breaking Kindle screens so easily?!
<bigjools> StevenK: I have no idea
<bigjools> but they are happy to keep sending replacements
<StevenK> I read a blog post about this recently. How Kindles started as expensive electronics device and was treated with kid gloves and so on, and has declined to, "Oh, whatever, it's like $80."
* StevenK changed the topic of #launchpad-dev to:  https://dev.launchpad.net/ | On call reviewer: jtv | Critical bugtasks: 3*10^2
* bigjools changed the topic of #launchpad-dev to:  https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 3*10^2
<cjwatson> bigjools: I'd like to fix bug 619088; it's been annoying me for a while.  Is there likely to be any problem with just changing FTPArchiveHandler to remove a slew of "are there any udebs to publish" conditionals?
<_mup_> Bug #619088: d-i indices in -proposed appear and disappear <lp-soyuz> <soyuz-publish> <Launchpad itself:Triaged> < https://launchpad.net/bugs/619088 >
<cjwatson> (Also bug 118227 and probably bug 240965.)
<_mup_> Bug #118227: main/debian-installer missing from Release files <feature> <lp-soyuz> <soyuz-publish> <Launchpad itself:Triaged> < https://launchpad.net/bugs/118227 >
<_mup_> Bug #240965: publisher doesn't deal with pockets becoming empty <lp-soyuz> <soyuz-publish> <Launchpad itself:Triaged> < https://launchpad.net/bugs/240965 >
<bigjools> cjwatson: hard to say without looking in more detail but it can't be that hard
<cjwatson> I don't know why it was made conditional in the first place; I'm assuming it was a misplaced sense of tidiness
<sinzui> gmb, do you have time to review my branch fixes https://code.launchpad.net/~sinzui/launchpad/builds-without-component-0/+merge/85400
<gary_poster> hi mrevell. bac sent out an email yesterday to launchpad-dev titled "Milestone tags".  It is in response to an escalated request from Danilo.  This affects you because our current proposed solution will (minimally) add a relatively small feature to milestones (you can tag them) and project groups (you can see a report of blueprints and bugs filtered by the milestones that have a given tag).  sinzui has given his blessing for this idea, and indeed
<gary_poster> it began with his brainwave.  We'd like to proceed with this on the sprint right now.  May we?  Would you like a call to discuss?
<sinzui> I think danilo also blessed the proposal
<gary_poster> (mrevell, Danilo has given his blessing on the general approach, and we are working on mockups now
<gary_poster> )
<cr3> hi folks, I would appreciate some assistance with the concept of bug subscriptions in Launchpad. yesterday, I unsubscribed to the dell-team bugs as can be seen from the following screenshot but I'm still being emails with the X-Launchpad-Message-Rationale set to "Subscriber @dell-team": http://people.canonical.com/~cr3/bug_subscriptions.png
<gary_poster> right sinzui, thank you
<cr3> might there be something I'm not understanding about this feature?
<mrevell> gary_poster, otp. I saw the email, have been in solid calls today so far. Will ping when I'm free.
<gary_poster> thanks mrevell.
<sinzui> cr3 a feature is new behaviour that requires guidance and acceptance by stakeholders
<cr3> sinzui: this is new behavior, as far as I can tell, and it's not getting my acceptance so far :(
<sinzui> :)
<cr3> sinzui: but it does require guidance though, so I'm all yours :)
<gary_poster> cr3, it is still possible to to get emails.  If you look at that page and expand all reasons why you get emails, it should give you a reason.  If not, AFAIK this is a recent regression
<cr3> sinzui: I had been looking forward to this feature for a while to reduce the volume of bug mail I receive and simplify my procmail rules, without having to unsubscribe from teams to preserve access to their online bugs, branches, etc.
<cr3> gary_poster: I toggled the "other subscriptions" link, my screenshot is the only item in the list
<sinzui> cr3 we know something is a bug because there are already rules from stakeholders/someone that we can see are contradicted. When a bug is escalated, we should not need to treat the fix as a feature. In some cases, a bug is escalated because the stakeholder believes it will achieve their goal, but it does not, Understanding the motive for the escalation cane reveal a feature-like issue
<gary_poster> cr3, then correct, you should not be getting anything from this list.  We have tests for the behavior and it has been in the wild for some time now without complaints I know of, so this may be an odd regression
<cr3> gary_poster: here's the full page screenshot: http://people.canonical.com/~cr3/bug_subscriptions_full.png
<gary_poster> (sinzui, you know cr3 is talking about bug subscriptions and not milestone tags, right?)
<cr3> gary_poster: this applies to a bunch of lists, not only dell-team. I receive a *lot* of email
<sinzui> gary_poster, I do not :)
<cr3> gary_poster: do your tests cover private teams/bugs?
<gary_poster> sinzui :-)
<gary_poster> cr3, yes, I think so.  the page you showed me shows that there is a reason you still receive email.
<gary_poster> cr3, the first box under "Other subscriptions" is the explanation
<cr3> gary_poster: but it says: You do not receive emails from this subscription.
<gary_poster> cr3, and the way to address it is to follow the advice on the right
<gary_poster> cr3, that is a separate subscription
<gary_poster> cr3, that is *your* subscription in the second box
<gary_poster> cr3, the first box is a subscription for a team of which you are a part
<gary_poster> cr3, that gets into mailman sending stuff
<gary_poster> cr3, we can't control at that level
<gary_poster> cr3, so you need to ask the Dell team to unsubscribe generally (or disable your emails from that list I guess)
<cr3> gary_poster: ok, so I absolutely need to contact the administrator of the team so that I don't receive bug mail anymore, right?
<gary_poster> cr3, yes.
<gary_poster> cr3, and the request will be this:
<gary_poster> cr3, could we no longer be subscribed as a team, so I can control what emails I receive?
<cr3> gary_poster: can I find instructions to do this, I'm not finding such an option in the +edit page of a team of a team I can obviously edit :)
<gary_poster> cr3, sorry was on call.  You are not an administrator of the team, or else the action links on your subscription page would show you what you could do about this.  As it is, the action (right-hand) link for that box gives you the only option you have: contact the administrators.  I suggest that you do this.  The link there takes you straight to the contact page and you can send them an email.  Give them a link to the page you are on now.  For admi
<gary_poster> nistrators, when they look at the full list of "Other subscriptions" they will be able to see and disable these subscriptions from this page.
<gary_poster> cr3, actually...
<gary_poster> cr3, it looks like they are *directly subscribed* to this bug.  This is different that the blanket structural subscription.  Again, this page should explain to the administrator why this has happened, and what they can do about it,
<gary_poster> .
* abentley changed the topic of #launchpad-dev to:  https://dev.launchpad.net/ | On call reviewer: abentley | Critical bugtasks: 3*10^2
<abentley> adeuring: lay it on me.
<adeuring> abentley: https://code.launchpad.net/~adeuring/launchpad/bug-903852/+merge/85651
<cr3> gary_poster: so I need to edit how a team is subscribed to all bugs while looking at the +subscriptions page of a specific bug as an administrator, right? if so, sounds like this option should be provided from the team overview or the team bugs landing page...
<cr3> gary_poster: so, I'm looking at a +subscriptions page as an administrator and I see what you mean: Edit this subscription. however, this seems to give me the option of changing the volume of bug mails sent, not whether the members of the team can unsubscribe themselves. might I be misunderstanding something?
<abentley> adeuring: Our style guide recommends "!Y.Lang.isUndefined()" (or isValue) rather than "!== undefined"
<adeuring> abentley: ah, ok, I'll change it
<abentley> adeuring: For the loop that's causing a lint error, you could use Y.each.  It's a pretty nice interface.
<adeuring> abentley: ok
<flacoste> sinzui: i have another potential gotcha for you around the LimitedView permission
<sinzui> oh dear
<flacoste> sinzui: it's not a big deal really, more of a polish thing
<flacoste> well, maybe, it's more than polish
<flacoste> but it's fairly easy to solve
<flacoste> the LP API uses the launchpad.View permission to check if should give the link to an object
<sinzui> ah
<flacoste> otherwise, the link will be the tag:redacted-....
<flacoste> one
<sinzui> Ian and I discussed that...well we guessed that
 * sinzui reports bugs
<abentley> adeuring: did you consider making SORT_KEYS a mapping?  Seem that would make the lookup simpler.
<adeuring> abentley: the data must be sorted: the order in the object defines the order of the sort buttons on the listing pages
<flacoste> sinzui: simply changing the configued permission to check would to the trick
<flacoste> sinzui: as this is only an optimizaiton to see if the user will be able to get anything out of the object
<flacoste> sinzui: actually marshalling catches exception Unauthorized exceptiond substitutes the redacted tag
<abentley> adeuring: JavaScript associative arrays actually are ordered, but I'm quite happy not to depend on that fact.
<adeuring> abentley: yes, but now the original dat is defined in Python...
<gary_poster> cr3, sorry was on call again.  Could you give me another screenshot of the +subscriptions page with you as an administrator?
<cr3> gary_poster: http://people.canonical.com/~cr3/bug_subscriptions_admin.png
<abentley> adeuring: This looks like a nice improvement r=me.
<adeuring> abentley: thanks!
<gary_poster> cr3, that's a different bug
<gary_poster> cr3, the options show depending on how you are subscribed
<cr3> gary_poster: indeed, one for which I'm an administrator :)
<gary_poster> cr3, and who you are
<gary_poster> cr3, right, but it's a completely different situation
<gary_poster> well, a different situation
<gary_poster> cr3, on http://people.canonical.com/~cr3/bug_subscriptions_full.png it says that you are subscribed because the dell team is directly subscribed to the bug.
<cjwatson> bigjools: damnit.  working on that failing test in refactor-cron-germinate now ...
<gary_poster> cr3, so the things you want to do there are (less importantly) unsubscribe the team from that bug and (more importantly) figure out why the dell team was subscribed to that bug, and if it was automatic, change things so that it is not automatic
<gary_poster> only admins can do that kind of thing, and will get info about it
<cr3> gary_poster: I'm pretending that I'm the person that I will be contacting with the message you suggested: could we no longer be subscribed as a team, so I can control what emails I receive?
<cr3> gary_poster: hm, I don't think that will happen, I think logs of bugs are still going to be assigned to the dell-team and many other teams I happen to be a member of because that's how they work
<gary_poster> cr3, I'm on a sprint.  I want to help you.  Maybe we could go faster on a call so I can get back to the sprint?  Skype would be easiest for me.  I have voip set up but I haven't tried it
<sinzui> abentley, can you review https://code.launchpad.net/~sinzui/launchpad/builds-without-component-0/+merge/85400
<abentley> sinzui: sure thing.
<cr3> gary_poster: thanks for the offer, very nice of you. I now understand the feature better and it seems to require changes on the side of the teams about their policy for bugs
<gary_poster> cr3, right
<gary_poster> cr3 (which the page can help them with, fwiw, but policy changes can require discussion)
<gary_poster> cr3 (fwiw, Launchpad has disabled most of these team subscriptions so that people can get the emails they want.  some team emails can be controlled by LP, but if a mailing list is involved, or if a direct subscription is involved, there's only so much we can do))
<sinzui> I see test_view_with_component has a rubbish comment. Sorry
<cr3> gary_poster: yeah, I now have a much better understanding of what's going on. I wish there was a way to communicate this more clearly somehow in the web interface so that you don't have to deal with people like me trying to wrap their brains around the problem :)
<gary_poster> cr3, me too :-) there probably is, but this was the best the mockup/user testing process came up with for this time around.  It's a complex situation
<cjwatson> bigjools: Test fixed.  Sorry about that!  Would you mind resubmitting?
<bigjools> cjwatson: yes, can you remind me of the MP URL please?
<cjwatson> bigjools: https://code.launchpad.net/~cjwatson/launchpad/refactor-cron-germinate/+merge/84624 - it's still thinking about the updated diff, but the fix was http://bazaar.launchpad.net/~cjwatson/launchpad/refactor-cron-germinate/revision/14471
<abentley> deryck: could you review the refactoring? https://code.launchpad.net/~abentley/launchpad/cleanup/+merge/85689
<deryck> abentley, look at you asking me before the diff is upâ¦. ;)
<abentley> deryck: diff is up now.
<deryck> abentley, ah, only 1500!  That's baby diff in js! :)
<deryck> abentley, sure, I'll do it.
<abentley> deryck: Thanks.
<rick_h__> abentley: have a sec for that assistance?
<abentley> rick_h__: sure.
<rick_h__> abentley: diff: https://code.launchpad.net/~rharding/launchpad/link_tags_894726/+merge/85673 and I seemed to have killed the test here: https://pastebin.canonical.com/57117/
<rick_h__> abentley: but in looking at the test that fails I don't see it hitting this BugTaskListing stuff at all
<abentley> rick_h__: looking...
<abentley> rick_h__: nothing looks obviously wrong in that regard.
<rick_h__> abentley: ok, updating devel and going to run the test there to see if it's not me
<rick_h__> abentley: any other suggetsions on how to generate the urls I should rethink?
<rick_h__> abentley: it feels a litlte bit dirty in the model like that, but works
<abentley> rick_h__: So you're assuming that the URL doesn't have a query, but I don't know why that would be true.
<rick_h__> abentley: the thought was this was a partial solution /easy hack. It doesn't remember things, just resets you to that tag view
<rick_h__> abentley: so it's not cascading the options through the tag link click
<abentley> rick_h__: But isn't it going to generate URLs like http://bugs.launchpad.net/bzr?order_by=importance?field.tag=bar ?
<abentley> rick_h__: Anyhow, to generate these urls, you do canonical_url(bugtask)
<abentley> rick_h__: No, wait.
<rick_h__> abentley: no, the getURL() doens't seem to have the query params
<rick_h__> abentley: and the tag link isn't in relation to the current bugTask item
<abentley> rick_h__: So, canonical_url(target, rootsite=bugs) should generate the url for a listing page.
<rick_h__> abentley: target_context?
<abentley> rick_h__: maybe.
<abentley> rick_h__: What does the existing code do?
<rick_h__> the current code builds a string of the tags and sets it to the tags property of the model build
<rick_h__> abentley: ^
<abentley> what
<abentley> rick_h__: is the model build?
<rick_h__> abentley: sorry, meant the tag attr of the model property that's built
<abentley> rick_h__: No, what does the existing code that generates URLs for tags do?
<rick_h__> abentley: oh, so I just needed to build a url like the ones built in the .pt files: tal:attributes="href string:${context/target/fmt:url}/+bugs?field.tag=${tag}">tag</a>
<rick_h__> abentley: so in order to get at the url of the current request, I found self.request.getURL() which seems to return a nice base url for the current request
<rick_h__> abentley: and I manually build the ?field.tag=$tag onto the end of the url and return it as part of the model
<rick_h__> abentley: so in order to do that I had to make the request argument to the BugTaskListingItem required vs an option kwarg
<abentley> rick_h__: So the literal translation of that is something like canonical_url(bugtask.context.target, view_name="+bugs") + "field.tag=" + tagname
<rick_h__> abentley: ok, I'll try that out and then back out the request argument changes
<rick_h__> abentley: thanks
<abentley> np
<abentley> rick_h__: I'm somewhat surprised to see that canonical_url doesn't support specifying query params.
<abentley> rick_h__: It looks like there's potential for XSS here.
<rick_h__> abentley: right, since it doesn't go through the tal filter?
<rick_h__> abentley: looks like context is a protected attribute as well so looking at how to put this together
<abentley> rick_h__: I think the issue is that <>& are not going to be escaped if you just do "+tagname"
<rick_h__> abentley: right, checking mustache's escaping options
<abentley> rick_h__: But they're escaped by mustache, so that should be fine.
<rick_h__> abentley: are they? ok cool
<abentley> {{}} escapes, {{{}}} doesn't.
<rick_h__> abentley: gotcha, works for me
<bac> flacoste: i've created bug 904335 and moved the 'escalated' tag to it
<_mup_> Bug #904335: Project groups need  a way to aggregate project milestones <escalated> <linaro> <Launchpad itself:Triaged> < https://launchpad.net/bugs/904335 >
<flacoste> bac: did you remove the escalated tag from the other one as well?
<bac> flacoste: i did
<flacoste> bac: thanks! and for testing the -proposed candidates
<bac> flacoste: np
<deryck> abentley, r=me with some minor formatting things I'll mention in my comment.
<sinzui> jcsackett, are you really about with net, or 3g?
<jcsackett> sinzui: i still have net atm.
<sinzui> jcsackett, do you have few minutes to discuss limitedview pages on mumble
<jcsackett> sinzui: certainly, just a moment whilst i fire up mumble.
<abentley> deryck: thanks.
<deryck> abentley, np!
<drunk_rambler> needed leads on how i can start of contributing to ubuntu
<rick_h__> abentley: have time to review? https://code.launchpad.net/~rharding/launchpad/link_tags_894726/+merge/85673
<abentley> rick_h__: sure.
<rick_h__> abentley: ty
<abentley> rick_h__: since bugtask.target is not going to vary, it seems strange to call canonical_url(self.bugtask.target, view_name="+bugs") more than once.
<rick_h__> abentley: true
<abentley> rick_h__: Here again we have the unfortunate pystache scoping bug.  It would be nice to do { "mustache_model": {tag_url_base: canonica_url(target)}, bugtasks[â¦]}, but tag_url_base wouldn't be visible in a loop.
<rick_h__> abentley: right, I'm pushing a change to generate a tag_base_url and then the completion just takes that + tag string to generate the url
<rick_h__> abentley: but yea, the wasted iterations :(
<abentley> rick_h__: Do we still need tags, or can tag_urls replace it?
<abentley> rick_h__: what's the &nbsp for?
<rick_h__> abentley: we don't use tags, I guess I thought it made sense to keep as part of the model
<rick_h__> abentley: but if I moved tag_urls onto tags perhaps that would be best and you could get at the tag strings easily
<abentley> rick_h__: No, if we don't use it in the mustache template, we shouldn't have it in the mustache model.
<rick_h__> abentley: the &nbsp; was just because of lint I had to newline the {{tags}}{{/tags}} and I wanted to be sure we always get the space seperation
<rick_h__> abentley: ok, I'll move the tags_urls to just tags then
<abentley> rick_h__: The newline after </a> should ensure that we get space separation, without imposing extra spacing.
<rick_h__> abentley: yes, the &nbsp; was just the most clear way to indicate a space MUST be here
<rick_h__> abentley: updates pushed
<abentley> rick_h__: I think the changes to lib/lp/bugs/browser/cvereport.py are unnecessary.
<abentley> rick_h__: other than that, this looks fine.
<rick_h__> abentley: ok, thanks
<abentley> rick_h__: I note that the review is marked "work in progress".  Is that done now?
<rick_h__> abentley: yes, I just marked the bug in progress. I had forgotten to do that earilier
<rick_h__> abentley: guess it flipped the status
<rick_h__> abentley: ah nvm, wrong 'in progress'
<lifeless> benji: / gary_poster: did jtv nab you guys to talk translation stats jobs ?
<gary_poster> lifeless, I've asked benji to investigate and connect with jtv.  AIUI, he is hoping to talk to gmb, because benji believes that some of those scripts are still being run
<gary_poster> lifeless, that's benji's top priority ATM
<lifeless> cool.
<gmb> benji, gary_poster, et. al.: I'm finally back online and available to talk should I be needed.
<lifeless> Its my understanding that the new job is a good step but missed a couple of key bits from the analysis done on /one/ of the earlier bugs
<lifeless> I wanted to say that its great to see things being made more incremental, and even if more work is needed to get it fully covering the issues etc - its great to see it being tackled.
<gary_poster> lifeless, that's what I got from jtv's bug too.  the other key bits *may* be handled elsewhere.  gmb, thanks.  benji knows the questions he needs to ask you better than I.
<gary_poster> lifeless, on an unrelated note, I have gotten my lxc stuff in a very broken state.  When I try to use lxc-create it doesn't succeed because the container does not have network access.  This is despite having the local.conf per your instructions, and ifconfig reporting a virbr0 around.  Do you know any resources I have to get some help with this?  I doubt this is something I can contact normal Ubuntu support with
<gary_poster> note that this was working fine earlier on the same machine. :-/
<lifeless> gary_poster: hallyn or spamaps in #ubuntu-server will be good contacts.
<gary_poster> ok thanks
<lifeless> that said, can you paste the exact config you are using, and the output of
<lifeless> sudo brctl show
<lifeless> ip route
<abentley> deryck: A further tweak: https://code.launchpad.net/~abentley/launchpad/cleanup-2/+merge/85731
<lifeless> gary_poster: I will reply to the tag thing after I've had a few more hours to cogitate and recover from last nights party
<deryck> abentley, ok, about to go to lunch for my dentist appointment.  I'll look when I get back.
<abentley> deryck: sure.
<lifeless> gary_poster: would you mind moving your draft onto the original LXC page? Its confusing to me to have two pages to worry about updating
<gary_poster> lifeless, sure, yeah.  You don't mind losing the natty info?
<lifeless> gary_poster: We don't need natty instructions at all now
<gary_poster> ok cool
<lifeless> gary_poster: only needed it until O was released.
<gary_poster> I'll do it in just a sec.  call
<lifeless> staff need to be running lucid/O/P anyhow; and community contributors can always look in the page history if they want old docs.
<gary_poster> ack
<jtv> cjwatson: I'm unexpectedly temporarily back... I see you're in dogfood.  Mind if I upgrade it?  Involves a restart of its launchpad instance, buildmaster etc.
<gary_poster> jtv, hi!  benji, look, I see jtv!
<lifeless> lol
<jtv> No you don't.
<gary_poster> oh, it was a mirage...
<jtv> Yes.
<lifeless> 'I see absent people'
<gary_poster> Have uyou seen any droids?
<jtv> Go back to work.  You'll forget this ever didn't happen.
<cjwatson> jtv: just a screen session doing nothing of importance; feel free.  Will that be up to r14516?
<jtv> This isn't the jtv you're looking for.
<lifeless> we have to update our 500 page
<gary_poster> :-)
<lifeless> http://www.flickr.com/photos/girliemac/6509400855/in/set-72157628409467125 courtesy mwhudson
<jtv> cjwatson: it'll be the latest, uh, devel I think.
<benji> jtv: hi, have a second to talk about bug 903532?
<jtv> benji: I would say "yes" but your second is already up.  :)
 * jtv throws an impatient look at the resident bugbot
<jtv> Ah, that one.
<jtv> Yes, I'll give you a whole minute if you want.
<gary_poster> lifeless, hee hee :-)
<cjwatson> jtv: Excellent, that'll include the thing I'll need to QA RSN, then.
<mwhudson> http://www.flickr.com/photos/girliemac/sets/72157628409467125/ has been posted to twitter 546 times in the last day
<mwhudson> (according to isitold.com)
<gary_poster> heh
<cjwatson> jtv: (Incidentally: is upgrading dogfood just a matter of running 'upgrade-dogfood-launchpad'?)
<jtv> Yes, it should be.
<jtv> I'm doing that right now, in fact.
<benji> jtv: first, I can't find evidence (other than the statistics not being right) that verify-pofile-stats-daily and verify-pofile-stats have been disabled; of course, verify-pofile-stats had collapsed under its own weight some time ago, as I understand it
<jtv> It used to be a bit more depends-on and now-run-the-other but I don't like that stuff.  Looks too much like work.
<jtv> benji: I didn't find them in the cron tabs.
<benji> jtv: where are the cron tabs?
<jtv> lp:lp-production-crontabs I think.
<jtv> bzr+ssh://bazaar.launchpad.net/%2Bbranch/lp-production-crontabs/
<jtv> jelmer, frankban: do you think you'll be able to finish your pending Q/A soon?
<benji> jtv: that's exactly what I was looking for, thanks!  we need to get those reinstated -- well verify-pofile-stats-daily, my understanding is that verify-pofile-stats is essentially useless now
<jtv> Correct on both counts.
<jtv> Unfortunately we still _need_ verify-pofile-stats!
<sinzui> abentley, can you see this branch https://code.qastaging.launchpad.net/~private-registry-test-team/+junk/newtest2
<abentley> sinzui: yes.
<sinzui> fab. thanks abentley
<gary_poster> jtv, we need it but reinstating will accomplish nothing without more work, right jtv?
<jtv> gary_poster: that follows logically, yes.
<benji> jtv: can you unpack that a bit, the ghost of Danilo thinks otherwise, see comment #9 on bug 781274
<_mup_> Bug #781274: rosetta-pofile-stats script takes more than a week to complete <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/781274 >
<frankban> jtv: yes I will finish my QA work within an hour
<jtv> frankban: great, thanks
<jtv> benji: that would only apply if the bug it refers to had been fully fixed.
<jtv> Instead, we now have a partial implementation.
<jtv> What the bug specified (with a bit of excessive detail that I would argue with, which I'll skip over for now) is âdo the statistics updates in a separate job, and have each job update not just a single POFile but its entire sharing set.â
<jtv> The latter part is not implemented AFAICS.
<jtv> Which leaves us without the biggest thing the statistics script did for us: patch up statistics for POFiles that were affected by changes in shared translations.
<benji> jtv: gotcha, that leads me to the second half; I can't say that I completely understand the details of how the shared translations need to be updated when an individual POFile is changed; will you outline that for me?
<jtv> It's not so much that shared translations need to be updated, but that they _are_ updated and the statistics need to reflect that.
<jtv> A template can share translations with a bunch of other templates.
<jtv> Therefore, a POFile can share translations with other POFiles: those whose templates share with its template, translated to the same language.
<jtv> Say POFile A shares with POFile B.
<jtv> They are both completely untranslated.
<jtv> Going through the UI for POFile  A, I translate POTMsgSet x.
<jtv> But x is also shared with B's template.
<jtv> We always updated statistics for A at this point,
<jtv> but B obviously also needs its statistics updated because it is no longer completely untranslated.
<jtv> There was no code to do that immediately; too complex and too costly.
<jtv> Instead, we relied on the statistics updater that was already in place.
<jtv> And so, in the current design, the pofilestatsjob needs to look up a full set of sharing POFiles and update all their statistics.
<jtv> In my opinion the current design is not that great for template imports, where we'd basically have to look up the sharing set twice (and once in the critical path).  But that's another topic.
<jtv> benji: still with me?
<benji> jtv: I have a glimmer of understanding of the words you are saying.  Do you know of a place in the code which we already "full set of sharing POFiles"?
<jtv> You're hitting a sore spot there.
<jtv> No, we don't have that.
<jtv> What we have is code to look up a full set of sharing templates.
<jtv> So you'd have to go over the full set of sharing templates (POTemplateSharingSubset IIRC), and for each, look up their POFile for the language you're interested in.
<jtv> Also, the template import code needs to do this for all languages that any of the sharing templates are translated to.  Which is why I would have preferred for POFileStatsJob to refer to a POTemplate and an optional language, rather than a POFile.
<jtv> A POFile is basically a tuple of a POTemplate and a language.  But who's to say there's always a POFile?
 * benji considers buying a very large whiteboard.
<benji> jtv: so... it looks like I need to make the job use POTemplateSharingSubset.getSharingPOTemplates(POFile_this_job_is_about.template) to get a set of templates and then call updateStatistics on each of those templates
 * benji crosses his fingers.
<jtv> benji: you'll be happy to hear that that is almost entirely correct.  The only small missing detail is in what you call updateStatistics on:
 * deryck hates going to the dentist
<jtv> for each of those sharing templates you need to find the POFile (if any) that translates it to POFile_this_job_is_about.language.  And if there is one, call updateStatistics on that POFile.
<benji> oh! yeah; I need to go from the templates to... /some/ set of POFiles, right?
<jtv> deryck: speak up!  Can't hear what you're saying with that novocaine jaw.
<jtv> benji: yes, and tragically there's no direct support for that.  Not that it'll be _very_ hard, but still.
<benji> jtv: thanks much
<jtv> HTH
<gary_poster> thank you jtv and benji.  jtv, sorry to drag you into this...early in the morning?  late at night?...but much appreciated.
<jtv> gary_poster: pretty much exactly inbetween.  Just got off an 8-hour bus ride, hence the weird times.
<gary_poster> oof, jtv.  ok, well...rest well? :-)
<jtv> Thanks
<jtv> Don't feel guilty; I was awake anyway and chose to log in.
<gary_poster> :-) thanks
<deryck> abentley, r=me on that mechanical name change.
<abentley> deryck: thanks.
<sinzui> jcsackett, http://curtis.hovey.name/2011/09/12/misadventures-with-gnome-javascript/
<jtv> hi sinzui â is there any prospect of getting deployment unblocked?  I see there's no rollback for that bad revision yet.
<cjwatson> jtv: There is, it just didn't have the rollback tag
<jtv> Odd actually: the deployment report says 14490 is both deployable and bad.
<cjwatson> jtv: r14500
<jtv> Thanks.
<jtv> That's right after mine, actually.
<cjwatson> But I guess we need r14491 QAed first ...
<jtv> Yes.  Been up there for a while.
<jtv> jelmerrrrr!
<cjwatson> jtv: Oh, do we still have a tree from a little before r14516 on mawson somewhere?  My QA procedure for refactor-cron-germinate involves doing a timed publisher run with the old code
<jtv> cjwatson: if only we had a technology to manage multiple revisions of source code somehow  :)
<cjwatson> Hm, which might involve switching /srv/launchpad.net/codelines/current back for a while
<cjwatson> I'm less than convinced that trying to run the publisher from any other path will work
<jtv> The publisher is just a script â I would've thought you could run that from any tree.
<cjwatson> e.g. LAUNCHPADROOT=${TEST_LAUNCHPADROOT:-/srv/launchpad.net/codelines/current}
<cjwatson> in cron.germinate
<cjwatson> so yes I can override it there ...
<cjwatson> Oh, actually, that looks like the only place.
<jtv> Once you get into publish-ftpmaster there shouldn't be any hard-coding of paths.  You may want to check the configs though.
<cjwatson> Where should I look?
<jtv> Mainly for the runparts directories I guess.
 * jtv digs
<jtv> cjwatson: my best guess so far is /srv/launchpad.net/codelines/lp-production-configs
<cjwatson> ./dogfood-publish/launchpad-lazr.conf:run_parts_location: cronscripts/publishing/distro-parts
<cjwatson> so I think that part is OK
<jtv> cjwatson: my system suddenly shut down.  Last I see in my log is where you found the config for the run-parts stuff.  In practice though I don't think dogfood-publish is maintained; I always just run the publisher under the dogfood config.
<cjwatson> jtv: Unfortunately dogfood doesn't have a run_parts_location, which is rather important here.
<jtv> If none is set up, I think the script uses the one from the source tree it's running from.
<jtv> But don't take my current word for it; I documented whatever it does.  :)
<cjwatson> # Location where the run-parts directories for publish-ftpmaster
<cjwatson> # customization are to be found.  Absolute path, or path relative to the
<cjwatson> # Launchpad source tree, or "none" to skip execution of run-parts.
<cjwatson> dogfood ultimately inherits "none"
<cjwatson> dogfood-publish does seem to mostly inherit from dogfood, though
<jtv> I think it's broken, but may be worth trying.
<cjwatson> I should be able to run the publisher from r14515 without putting that tree's database in place, I guess
<cjwatson> (I have a built tree in /srv/launchpad.net/codelines/r14515)
<cjwatson> I think I might wait for garbo-hourly to finish before trying to time anything, though.
<cjwatson> Hmm, that might take a while ...
<lifeless> probably want to kill it, it will take the whole hour I expect
<lifeless> it runs out of time on a 4-way box
<lifeless> or is it 6. Much cpuness anyhow
<cjwatson> Is that going to interfere with anyone's plans for dogfood?
<cjwatson> I guess not.  Killing
<cjwatson> 2011-12-14 22:44:26 DEBUG   Querying which suites are pending publication...
<cjwatson> publisher on mawson has been sitting at that for five minutes - I know mawson is slow but is it that slow?
<cjwatson> Maybe I should just run cron.germinate in isolation, at this rate
<cjwatson> (That would be just as good for QA.)
<cjwatson> I'll do that rather than growing old.
<jtv> cjwatson: it's not supposed to be that slow, no.
<cjwatson> cron.germinate itself doesn't need lp-query-distro.py pending_suites, only other lp-q-d operations that complete quickly, so I can avoid whatever the problem is.
<cjwatson> Hmm.  This is a bit awkward.  I can't QA this on dogfood because it has suites that don't have seeds ...
<jtv> Can't you limit it to specific suites?
<cjwatson> No, that doesn't make sense.
<cjwatson> What's going on ...
<cjwatson> * Downloading http://people.canonical.com/~ubuntu-archive/seeds/ubuntu.rusty/STRUCTURE
<jtv> Bear in mind though that the dogfood archive isn't complete.
<jtv> Anyway, the horizon is turning grey.  Time to get those few more hours.  Good luck!
<cjwatson> find_operable_series is apparently producing different results from lp-query-distro.py development
<cjwatson> Which is sad.  This might be qa-bad, but I'll look some more
<cjwatson> Is there any problem with me using anoint-dogfood-admin on myself so that I can investigate this?  I think it might actually not be a production problem, but I need to change the status of a couple of dogfood Ubuntu series to make sure of that
<cjwatson> (dogfood has multiple Ubuntu series in status DEVELOPMENT or FROZEN; production will only ever have one)
<StevenK> cjwatson: It is not a problem, you can make yourself an admin.
<cjwatson> Thanks
<poolie> hi all
#launchpad-dev 2011-12-15
<poolie> sinzui, hi, i don't really understand your comment on bug 801242
<_mup_> Bug #801242: no way to request membership in a private team - can only be added <privacy> <teams> <Launchpad itself:Triaged> < https://launchpad.net/bugs/801242 >
<cjwatson> How come the QA bot hasn't got round to doing its thing on bug 899972 yet?
<_mup_> Bug #899972: cron.germinate is very slow <Launchpad itself:In Progress by cjwatson> < https://launchpad.net/bugs/899972 >
<StevenK> cjwatson: Which revision?
<lifeless> cjwatson: qastaging isn't running it yet
<lifeless> cjwatson: look at qastaging, bottom right corner.
<cjwatson> Ah
<cjwatson> StevenK: r14516
<StevenK> cjwatson: That revision hasn't passed buildbot, so it's not in stable.
<cjwatson> Ah, I keep forgetting how many stages are involved :-)
<StevenK> The QA tagger should get it's grubby hands on the bug in about 3-3.5 hours
<cjwatson> I've just posted my QA notes in the bug.  In the unlikely event that the deployment pipeline gets that far between the tagger getting to it and me noticing that, it can be marked qa-ok.
<StevenK> I still need to sort out the deployment report
<StevenK> It's still hung up on r14489 being bad
 * StevenK tries to understand bzrlib.gpg and goes cross-eyed
 * StevenK finds the right option, finally.
 * wallyworld_ goes for a coffee run
 * nigelb realizes he hasn't written LP code in a while.
<StevenK> nigelb: Fix it!
<nigelb> StevenK: Yeah, I need to find an interesting bug to fix. Updating my tree now.
 * StevenK kicks the qa-tagger
<StevenK> Bloody rollback tags
<StevenK> ARGH
<StevenK> I fix r14489 and r14490 and now r14491 is bad
<StevenK>  /wrists
<StevenK> poolie: Ping
<poolie> pong
<StevenK> poolie: Do you know what is going on with bug 509016?
<_mup_> Bug #509016: Please load bzr-git, bzr-svn and bzr-hg in loggerhead <bad-commit-14991> <lp-code> <qa-bad> <trivial> <Launchpad itself:Fix Committed by jelmer> < https://launchpad.net/bugs/509016 >
<StevenK> Can I roll it back so we actually deploy?
<StevenK> cjwatson: Thanks for your exhaustive QA notes, I've tagged your bug qa-ok.
<poolie> StevenK, i don't know anything beyond what's in the bug etc
<poolie> what is breaking?
<StevenK> poolie: Can we mumble?
<StevenK> It will be quicker
<poolie> after counting futzing with mumble?
<poolie> can i just call you?
<StevenK> Haha
<StevenK> Sure
<StevenK> Landline in the directory
<nigelb> lol
<StevenK> mumble works perfectly for me, so I don't know why poolie has to fiddle with it
<nigelb> I've seen people complain about all 3 calling things at some point.
<nigelb> mumble/skype/google hangout
<StevenK> jelmer: Are you still around, by chance?
<wgrant> StevenK: I think we should revert it.
<StevenK> I'm just preparing a revert
<StevenK> And buildbot started like 90 minutes ago.
<wallyworld_> StevenK: should we just restart bb?
<StevenK> Probably not.
<wallyworld_> :-(
<StevenK> DAMN IT, lp-land, use the correct key
<nigelb> lol
<StevenK> nigelb: I'm moving to a 4096 bit RSA key
<wgrant> StevenK: Set gpg_signing_key in bazaar.conf
<StevenK> I did
<StevenK> That fixed ec2land, but lp-land is still wanting my DSA key's passphrase.
<StevenK> And bzrlib.gpg is nearly incomprehensible
<StevenK> Thanks lifeless!
<nigelb> heh
<poolie> StevenK, oops, i got totally distracted
<StevenK> Heh
<StevenK> poolie: I have a rollback prepared, just having trouble landing it since lp-land insists on signing with my 1024bit DSA key.
<poolie> wgrant, in other news, i think python-markdown is tolerably safe
<StevenK> Even though gpg_signing_key is set in bazaar.conf
<wgrant> poolie: Hm, that is good news.
<wgrant> poolie: Is that what GitHub uses, or do they have their own thing?
<poolie> i think they use ruby
<poolie> so different implementation, same format
<wgrant> Probably.
<poolie> similar format
<wgrant> Yeah, I knew it was markdownish, but I thought they used Python in places.
<wgrant> Perhaps not.
<poolie> so, obviously any software can have bugs however
<poolie> the code is not obviously silly
<wgrant> Yep
<poolie> it does have options for safety against xss etc
<nigelb> wgrant: They use github-flavored markdown
<nigelb> Btut they use a ruby thing
<poolie> and it's fairly widely used for this
<nigelb> to do the conversion
<wgrant> Ah, that's what I was thinking of. They use pygments.
<mwhudson> yes
<mwhudson> you can tell, because it has the same performance bugs pygments has :-)
<mwhudson> they cap the amount of cpu it can use though
<StevenK> poolie: http://pastebin.ubuntu.com/770798/ explains the issue
<nigelb> mwhudson: heh
<poolie> StevenK, that might be bug 904550?
<_mup_> Bug #904550: gpg signing key doesn't default to 'email' anymore <release-blocker> <Bazaar:Confirmed> < https://launchpad.net/bugs/904550 >
<poolie> or just coincidental
<poolie> um
<poolie> StevenK, so try something like
<poolie> echo merge bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel | gpg --clearsign -u abcd1234 |mail -s 'commit message' launchpad@pqm.canonical.com
<poolie> something like this
<StevenK> Right, which just submits it manually
<poolie> yes
<poolie> if you're stuck, that's how i'd get unstuck
<StevenK> PQMException: 'Failed to verify signature: gpgv exited with error code 1'
<StevenK> :-(
<poolie> ah pqm
 * StevenK waits for logs to sync
<poolie> ah
<poolie> you need gpg -a too
<StevenK> -a is the default if the output is a tty
<StevenK> (Which it was in this case)
<poolie> isn't the output a pipe to mail?
<poolie> or you were pasting it
<StevenK> Pasting it into Thunderbird and sending
<StevenK> poolie: I fixed it with an enormous sledgehammer.
<jtv-zzz> poolie: Hi!  Any luck with Q/A?  We've got a nasty qa-bad blocking some really urgent stuff, and I'm concerned about other pending Q/A holding up the rollback we need for the bad branch.
<jtv> I thought openid was no longer supposed to send us to the wrong pages.  :(
<jtv> poolie: superficially there's only 7 branches waiting for your Q/A and it's not the blocker yet, but if we need a rollback, that adds the 18 revisions that are blocked behind his.
<jtv> Behind jelmer's, that is.
<wallyworld_> jtv: StevenK is onto it
 * jtv breathes out
<jtv> thanks
<wallyworld_> jtv: don't forget to breath in again
<wallyworld_> and then out
<wallyworld_> and then in
 * jtv tries that
<jtv> wallyworld_: thanks, that's really helping.  But we can't keep going this way all day, can we?
<jtv> Maybe I should write a script.
<StevenK> I did not do the QA.
<wgrant> jtv: That rev is rolled back.
<wgrant> 'twill be some days before you can deploy.
<jtv> Which revision is rolled back?  jelmer's?
<wgrant> Yes.
<StevenK> Yes
<jtv> I don't suppose we have a way of marking rollbacks as such after landing, just so the deployment report can be fixed?
<StevenK> Only when it hits qas
<jtv> no entiendo
<jtv> StevenK, wgrant: isn't the buildfarm breakage something of a bad thing though?
<wgrant> jtv: What's broken?
<jtv> Oh, was my buildfarm fix rolled back?
<wgrant> We rolled it back <5 minutes after it was discovered.
<jtv> Ah!
<wgrant> The world would have been on fire for days otherwise.
<jtv> Didn't know that.
<jtv> Right.
<jtv> Wish I'd known that before working nights and holidays.
<wgrant> Well.
<wgrant> Distro hadn't nuked you from orbit yet, so it should have been reasonably obvious :)
<jtv> Explicit is better than implicit.
<jtv> wgrant: what's the procedure with that rollback?  Am I responsible for undoing it once the fix is ready to deploy?
<wgrant> jtv: Someone (likely Julian, since AIUI both you and I are away for some time) needs to request a deployment.
<jtv> Are you talking about the obvious deployment (of the fix), or some extra deployment?
<wgrant> The obvious deployment.
<wgrant> There's nothing special about this sort of rollback -- it's just flipping the symlink back to an older tree and restarting services.
<wgrant> So a normal deployment will clobber it.
<jtv> OK
<jtv> Well I was going to request the rollback anyway if nobody else beat me to it â which is why I'm chasing Q/A blockers in my free time.
<huwshimi> A CSS/UI review for someone kind enough to do so: https://code.launchpad.net/~huwshimi/launchpad/inline-fields/+merge/85798
<adeuring> good morning
<mrevell> Hi
<nigelb> Morning mrevell
<bigjools> StevenK: do you know if there's a bug for adding package_name to SPPH/BPPH?
<StevenK> bigjools: It's not package_name
<bigjools> whatever then
<gmb> Someone remind me: Are DB patches that are just constraints meant to go into devel or db-devel?
<wgrant> gmb: db-devel
<wgrant> They generally require exclusive table locks, which requires downtime.
<gmb> wgrant, Thanks.
<rick_h__> morning
<bigjools> anyone know if there's a way of specifying that a parameter to @operation_parameters is for a particular api version?
<bigjools> or do I need to repeat the whole lot using @operation_for_version?
* jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett | Critical bugtasks: 3*10^2
 * benji assumes jtv isn't around.
<bac> hi abentley, frankban and i are using 'bzr lp-propose' but the template is not being populated.  i have the lpreview-body plugin installed as part of lp-dev-dependencies.  any idea what is missing?
<abentley> bac: I expect it's not detecting that you're targetting a Launchpad branch.  Let me refresh myself....
<bac> abentley: the contents of the editor are http://pastebin.ubuntu.com/771213/ -- so it does appear to know it is a LP branch
<abentley> bac: the target branch needs to match this regex: lp:(~launchpad-pqm/)?launchpad(/(db-)?devel)?
<abentley> bac: Sorry, it needs to match 'bzr\+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/(db-)?devel'
<bac> abentley: it looks like i have the full bzr+ssh URL in my locations.conf file but the shorthand is being used and thus not matching the regex
<abentley> bac: If your submit branch is a local branch, you need to specify the bzr+ssh URL as its public location.
<bac> abentley: here is 'bzr info' for my branch and my devel branch -- http://pastebin.ubuntu.com/771217/
<abentley> bac: That looks like it would work.
<abentley> bac: But also, it should be raising an exception if it's getting lp:launchpad as the target, and it's not doing that either.  So I'm not sure what's going on there.
<bac> abentley: ok, i'll experiment on my dev machine at home and see if it still works and compare the differences
<abentley> bac: The target branch is selected by lp-propose, so I'd stick a pdb somewhere in that code.
<bac> ok
<cr3> hi folks, you guys know there's a problem with bazaar.launchpad.net, right?
<cr3> oops, not anymore. thanks for fixing it so quickly :)
* gary_poster changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett | Firefighting: codehosting connection problems | Critical bugtasks: 3*10^2
<adeuring> jcsackett: could you please review this MP https://code.launchpad.net/~adeuring/launchpad/bug-901016/+merge/85902 ? (100 lines diff)
<rick_h__> abentley: have a sec? my changes for this bug run right into your refactor
<abentley> rick_h__: OTP
<rick_h__> abentley: ok
<jcsackett> adeuring: sure thing.
<adeuring> jcsackett: thanks!
<jcsackett> adeuring: looks good. r=me.
<adeuring> jcsackett: thanks!
<abentley> rick_h__: back.
<rick_h__> abentley: I've got it. Your changes got merged so updated with devel and redoing the changes
<rick_h__> bzr issues making it a bit slow, but think I'm set, thanks abentley
<abentley> rick_h__: Cool.
<abentley> deryck[lunch]: http://blog.launchpad.net/general/new-approaches-to-new-bug-listings
<rick_h__> jcsackett: ping, got a sec to peek at: https://code.launchpad.net/~rharding/launchpad/heat_help_894740/+merge/85901 ?
<jcsackett> rick_h_: sure, in just a moment. :-)
<jcsackett> rick_h__: r=me.
<rick_h__> jcsackett: ty much
<mrevell> Night all
<deryck> abentley, thanks!  looks good.
<abentley> deryck: np.
<rick_h__> deryck: did you have some 'next bugs' in your mind? It seemed during the stand up you had some targets
<deryck> rick_h__, yeah, any of the high bugs with the tag bug-columns would be good. see: http://tinyurl.com/d9nevd9
<rick_h__> deryck: ok cool. I'm going through them but wanted to make sure you didn't have specific next items in mind
<deryck> rick_h__, nah.  just ask me if you have questions about specific bugs.
<rick_h__> deryck: abentley looking at: https://bugs.launchpad.net/launchpad/+bug/900900
<_mup_> Bug #900900: navigation links are missing from bug listing bottom if there is only a single batch. <bug-columns> <Launchpad itself:Triaged> < https://launchpad.net/bugs/900900 >
<rick_h__> deryck: abentley but the batching code specically calls out that "Only render bottom navigation links if there are multiple batches."
<rick_h__> so are we looking to change that site-wide?
<abentley> rick_h__, deryck: I think we should change it site-wide.  It's confusing.
<deryck> I agree.  it might makes sense for some defined small number, i.e. 1-5 results.  but anything over half a screen we certainly need bottom links, so....
<rick_h__> abentley: I think the argument would be that in small nubmers, doubling the batch ui would clutter the interface
<deryck> to really simplify, I say always have bottom links.
<rick_h__> deryck: ok, will do then. Thanks
* gary_poster changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett | Firefighting: - | Critical bugtasks: 3*10^2
<sinzui> Hi jcsackett. I have a few questions about your branch in review
<jcsackett> sinzui: shoot.
<sinzui> Line 41 of the diff adds an extra space to the text and the test verifies it.
<sinzui> This message does not cover the case when a private team is subscribed to a bug or branch. Can we make the message more general?
<jcsackett> sinzui: good catch on the typo, and yeah, we can generalize the message.
<sinzui> "This action will reveal this team's name to the public. (Choose again) (Continue)
<sinzui> jcsackett, we avoid yes/no button because they require a re-reading of the question.
<flacoste> abentley: nice post!
<sinzui> jcsackett, My concerns are just the text and labels. The implementation is great
<abentley> flacoste: thanks.
<jcsackett> sinzui: thanks; i'm pushing up the text changes now.
<sinzui> fab!
<sinzui> jcsackett, I also wanted to have a mid-implementation conversation about base-layout. I have rudimentary version working with tests. I think I want to change the macro used to prevent the main and side slots from rendering
<jcsackett> sinzui: sure, one sec while i hop on mumble.
<rick_h__> deryck: is this something I could probably just self-review? https://code.launchpad.net/~rharding/launchpad/batch_nav_900900/+merge/85935
<deryck> rick_h__, you can't self review your own stuff yet, until you're a graduated reviewer yourself.
<rick_h__> deryck: ah, makes sense.
<deryck> rick_h__, lots of "self" there, but I hope you get the idea.
<rick_h__> deryck: right, need to get rid of the "training" badge first. Understand
<rick_h__> jcsackett: see you're doing some call, if you get a sec after that please? https://code.launchpad.net/~rharding/launchpad/batch_nav_900900/+merge/85935
<sinzui> jcsackett: http://pastebin.ubuntu.com/771461/
<jcsackett> rick_h__: looking now. :-)
<deryck> I also have something for review jcsackett.  https://code.launchpad.net/~deryck/launchpad/avoid-extra-buglist-count-901124/+merge/85940
<rick_h__> jcsackett: ty
<jcsackett> rick_h__: i've left questions on your MP.
<deryck> jcsackett, did you see my ping about a branch for review?
<jcsackett> deryck: i did not, i will go grab your branch from the queue now.
<deryck> jcsackett, cool, thanks man!
<jcsackett> deryck: looks good; nice workaround the COUNT issue. :-)
<deryck> jcsackett, thanks!
* jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 3*10^2
 * huwshimi must. not. reload. mp.
<benji> heh
<lifeless> mwhudson: are your tags queries all copacetic?
<mwhudson> lifeless: i don't know what that word means
<lifeless> http://en.wiktionary.org/wiki/copacetic
<mwhudson> well, i've written some queries that pass all my tests
<lifeless> cool
<lifeless> ftr what we do in lp is a little / moderately bloody
<lifeless> I've been meaning to refactor
<lifeless> e.g. to use an array equality
<lifeless> the mathematical way is using intersections, of course
<mwhudson> my approach is basically count(tags in a that are not in b) == 0
<mwhudson> lifeless: where is the code in lp?  lp/bugs/model/bugtask?
<lifeless> counting works, though wouldn't you just count(found tags) == len(wanted tags) ?
<lifeless> mwhudson: yes
<mwhudson> lifeless: well, not much difference really i guess
<mwhudson> lifeless: ah so part of my fun is that the list of tags to search for is retrieved by another part of the query
<lifeless> in one query ?
<lifeless> can you share ?
 * mwhudson rummages
<mwhudson> lifeless: http://paste.ubuntu.com/771702/
<lifeless> mwhudson: oh, did I tell you that there is django glue in oops-wsgi now ? courtesy jamesh
<lifeless> mwhudson: so, uhm right
<lifeless> how to stop unity raising the active window to the front.
<mwhudson> lifeless: ah yes, will look at oops-wsgi
<lifeless> mwhudson: so, slight diversion to re-re-tweak my de
<lifeless> lava-scheduler-app-device-tags lists tag, device
<lifeless> testjob tags lists tags for tests
<lifeless> so you're grabbing the count of test tags that are not in the device tag list
<lifeless> what you want to state is, I think, 'test jobs that have at least the devices tags'
<lifeless> a first tweak would be 'has_tags': 'select count(*) = 0 from ...'
<lifeless> meh, it works, and you're querying one device, shrug :)
<lifeless> you could add a CTE if your tag table isn't well indexed.
<mwhudson> it's django i assume there are no indexes :)
<mwhudson> but easy to add though
<mwhudson> the primary key on id is probably enough here though...
* wallyworld_ changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld | Firefighting: - | Critical bugtasks: 3*10^2
#launchpad-dev 2011-12-16
<StevenK> poolie: :-( You have two revisions that are marked needstesting
<poolie> StevenK, is that bad?
<StevenK> poolie: Means we can't deploy unless you or someone else does the QA.
<poolie> StevenK, fixed
<wgrant> jtv's is untestable, and wallyworld's is wallyworld_'s.
<wgrant> and that should be it.
<wgrant> Finally.
<StevenK> I think now-ish is as late as I want to deploy.
<wgrant> Given that it's like 40 revs, yeah
<wallyworld_> i'm just finishing something for landing and will then do my qa
<StevenK> Bleh
<StevenK> jelmer has marked the bug qa-ok, but my bad-commit tag is hurting the tagger
<jelmer> I suck
<jelmer> I didn't realize I had to remove the tag, sorry
<StevenK> jelmer: It's more the tagger sucks
<StevenK> Since it landed as bad, was rolled back and now is fine
<wgrant> You should never remove bad-commit tags. But it is sometimes necessary when the rollbacks are complex or untagged.
<jelmer> that was my thought.. if somebody becomes qa-ok later, you still don't want to deploy just the old commit.
<wgrant> The problem is that we have an interlinked chain of rollbacks here, which qa-tagger doesn't handle well.
<StevenK> And the tagger wasn't tracking some of them due to missing rollback tags
<StevenK> And my no-configure-codehosting branch doesn't work on qas
<wgrant> But is it bad?
<StevenK> No, it doesn't break.
<StevenK> It just doesn't hide the link.
 * StevenK waits for the tagger
<wallyworld_> sinzui: fyi, that inTeam issue was trivially fixed for the merge proposal view which was failing. i've done a dependent branch, cancelled the ec2 landing of the original, and will land the downstream one
<wallyworld_> https://code.launchpad.net/~wallyworld/launchpad/protect-inTeam-against-misuse/+merge/85977
 * wallyworld_ shakes fist at ec2 - using ElasticFox to cancel my ec2 run show 4 running instances from november WTF??!!
 * wallyworld_ is now scared to look at credit card bill :-(
<StevenK> wallyworld_: There's an ec2 kill command
<wallyworld_> StevenK: i would have used it if i had known they were still running. i don't know how they stayed active when all my ec2 land commands completed etc
<wallyworld_> so i had no suspicion anything was wrong
<StevenK> wallyworld_: You know about 'bin/ec2 ls' right?
<wallyworld_> StevenK: yeah, but because everything completed ok i had no incling that anything was wrong
<StevenK> wallyworld_: rvb has a cron job that runs bin/ec2 ls at midnight and mails him if something is running
<wallyworld_> StevenK: that's a brilliant idea
<wallyworld_> i must ask him for a copy
<StevenK> wgrant: The tagger insists that r14491 is undeployable still :-(
 * StevenK goes back to qa-bad bad-commit-
<wgrant> StevenK: 14519
<StevenK> Right, setting qa-bad bad-commit-14491 gets us to r14521
<StevenK> But r14522 and r14523 are deployable too. Not sure how to convince the tagger otherwise.
<wgrant> StevenK: HOpefully fixed.
<wgrant> There we are.
<StevenK> Indeed
<StevenK> Writing a deployment request
<cjwatson> https://code.launchpad.net/~cjwatson/launchpad/soyuz-test-mail-ordering/+merge/85979 should fix the i386-specific test breakage we noted the other night
<StevenK> wgrant: The NDT removes the need for cowboys on germanium/cesium?
<cjwatson> StevenK: not deploying to cocoplum as well?
<cjwatson> I guess that has to be in a downtime window
<StevenK> cjwatson: Right.
<cjwatson> Do we have one of those later today?
<StevenK> We can do, I think.
<cjwatson> I think the ftpmaster-relevant stuff is basically just Julian's poppy fix and my cron.germinate rewrite, so if anything goes wrong it'll be in UK time.
<cjwatson> Well, except for cocoplum being all the way back on 14263 right now ...
<wgrant> StevenK: Hopefully, but it needs to be watched carefully.
<wgrant> StevenK: It has fixes for all three rollbacks, but ppa/ftpmaster can only be deployed with downtime.
<wallyworld_> StevenK: should db_devel bb be forced?
<wallyworld_> looks like it lost connection for some reason
 * wallyworld_ stabs it
<huwshimi> A small review for someone: https://code.launchpad.net/~huwshimi/launchpad/gear-icon-visibility-894729/+merge/85986
<StevenK> wallyworld_: Doing it wrong
<StevenK> release-critical is a review tag
<wallyworld_> ah ok. i wanted to force the merge to ensure the regression was fixed asap and %@!$%$%! dbdevel bb was busted :-(
<StevenK> That's [testfix]
<StevenK> Or just force the build and wait ten minutes
<wallyworld_> but it wasn't a testfix for devel
<wallyworld_> oh, so i could have just waited?
<StevenK> We'll be in testfix if either branch has failed
<huwshimi> wallyworld_: Thanks for the review :)
<StevenK> Yes, the buildbot-poller runs every ten minutes, and looks at the state of buildbot.
<wallyworld_> StevenK:  i thought testfix  was for a checkin to fix an issue with the specific builder that was broken
<wallyworld_> huwshimi: np
<wallyworld_> anyways, i'll just wait next time
<StevenK> wallyworld_: You seem to be a little unclear. I can explain this in about 40 seconds via voice
<wallyworld_> ok, let's mumble
<huwshimi> A review for the faint-hearted (+1/-0): https://code.launchpad.net/~huwshimi/launchpad/order-button-heights-904751/+merge/85987
<StevenK> Haha
<huwshimi> wallyworld_: https://code.launchpad.net/~huwshimi/launchpad/one-bug-breakage-887571/+merge/85989
 * wallyworld_ looks
<huwshimi> wallyworld_: (+1/-0) again :)
<wallyworld_> i'm getting the hard ones today
<huwshimi> wallyworld_: I'm keeping you busy
<huwshimi> wallyworld_: Distracting you from the cricket
<wallyworld_> huwshimi: i wish there were cricket. i'm fighting with storm and it's stupid non-verbose error reporting
<wallyworld_> huwshimi: all approved
<huwshimi> wallyworld_: Well there was cricket...
<huwshimi> wallyworld_: which did not end well
<huwshimi> hmmm... how can I create a bunch of bugs for dev (enough to test paging)?
<wallyworld_> don't remind me :-(
<wallyworld_> huwshimi: there's a harness you can run
<huwshimi> wallyworld_: That's why I'm keeping you busy :)
<wgrant> bin/harness
<wgrant> product = self.factory.makeProduct()
<wgrant> print product.name
<wgrant> for i in range(150): self.factory.makeBug(product=product)
<wgrant> transaction.commit()
<wgrant> s/self.//
<StevenK> wallyworld_: ^ That was I meant on the call yesterday, too
<wallyworld_> StevenK: yeah, i already had a look at it
<huwshimi> wallyworld_: Should creating the bugs take a while?
<wgrant> Yes :/
<wgrant> The factory is slow as hell.
<huwshimi> wgrant: :(
<wallyworld_> huwshimi: you can also dick with the config to reduce the batch size
<wallyworld_> in devel the batch sizes are small anyway
<huwshimi> wallyworld_: This seems to be working for now, I'll wait for it to finish and see if I need to do anything else
<wallyworld_> ok
 * wallyworld_ is off to a surpise 75th birthday party. I have the defibrillator and ambulance on standby
* wallyworld_ changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 3*10^2
<huwshimi> hah! it was hung
<huwshimi> ok that was very quick
<huwshimi> A review for someone: https://code.launchpad.net/~huwshimi/launchpad/bug-listing-spinner-position-904416/+merge/85997
<mwhudson> "14527 revisions were removed from the branch."
<mwhudson> what happened there? :)
<huwshimi> mwhudson: Wait, you're not talking about my MP are you?
<mwhudson> ah
<mwhudson>   [r=stevenk][rollback=14502] Revert r14502. It causes issues with
<mwhudson>    scanner speed and branch mail.
<mwhudson> huwshimi: no
<huwshimi> mwhudson: Good, I was a little worried for a second there :)
<wgrant> mwhudson: Yeah, that was the very email that alerted me to the issue.
<mwhudson> wgrant: when i read it i was scared that i would have 14527 emails ...
<wgrant> mwhudson: Yeees.
<wgrant> I still don't know what the actual problem is.
<wgrant> It does seem to be iterating over the revisions in reverse order, but that doesn't explain what appears to be the null revision appearing.
<adeuring> good morning
<mrevell> Bonjour
<danhg> Morning
<allenap> Does anyone know if Launchpad development works with Precise?
<wgrant> allenap: Sort of.
<wgrant> allenap: But your best bet is to use LXC
<wgrant> Which works pretty well in Oneiric onwards.
<wgrant> https://dev.launchpad.net/Running/LXC
<wgrant> Things go a bit wrong running it natively on oneiric/precise, because the default python is 2.7.
<cjwatson> schroot works too if you didn't need the matching network services in your host system
<wgrant> Indeed.
<wgrant> Unlike LXC it doesn't take over your TTYs occasionally either :/
<cjwatson> Hm, is anyone working on fixing it for 2.7?  I thought that had already been done
<cjwatson> If it's just a matter of fixing tests ...
<wgrant> Most stuff works. I think I have an unlanded branch with some more fixes.
<wgrant> But timeout.txt hangs.
<wgrant> And there are a couple of others that I never got to the bottom of.
<cjwatson> How appropriate
<allenap> Haha.
<wgrant> Ah, indeed, a 4.5-month-old unlanded branch.
 * wgrant sends it off to ec2.
<allenap> wgrant, cjwatson: So, would running running Precise and using an <=Oneric schoot/lxc be sensible, or vice-versa?
<wgrant> Although some of these are in code that I deleted months ago...
<wgrant> allenap: I use a lucid container on precise
<cjwatson> allenap: I run precise and do drive-by LP development in a lucid schroot.  But I'm not really an LP developer :-)
<cjwatson> (And I already had schroot set up for other things.)
<cjwatson> gmb: Don't know if you saw, but I supplied QA instructions on https://code.launchpad.net/~mvo/launchpad/maintenance-check-precise/+merge/82125
<gmb> cjwatson: I hadn't seen but I'll take a look today. Thank you.
<ajmitch> is there a way to turn off the dynamic bug listings without leaving the beta-testers team? I'm getting bitten by JS errors
<wgrant> ajmitch: There aren't known errors left, AFAIK. Have you filed a bug?
<ajmitch> yeah, just filed bug 905228
<_mup_> Bug #905228: Cannot use pagination links on bug listings <bug-columns> <Launchpad itself:New> < https://launchpad.net/bugs/905228 >
<wgrant> There's no way to disable them without leaving the team.
<ajmitch> ok
<ajmitch> I'll check that bug in firefox, but it's a bit annoying not being able to see more than 75 bugs in chromium
* adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: adeuring | Firefighting: - | Critical bugtasks: 3*10^2
<rick_h__> morning
<allenap> Morning rick_h__ :)#
<allenap> s/#/
<rick_h__> adeuring: can you peek at this once it loads, it's causing broken buglisting for chrome users on prod and I want to get moving asap please https://code.launchpad.net/~rharding/launchpad/pagination_905228/+merge/86033
<adeuring> rick_h__: sure
<rick_h__> adeuring: ty sir
<adeuring> rick_h__: r=me
<rick_h__> adeuring: ty
<rvba> adeuring: could you please have a look at https://code.launchpad.net/~rvb/launchpad/builders-timeout-903827/+merge/86029 ?
<adeuring> rvba: sure
<rvba> thx
<adeuring> rvba: in line 112/113 of the diff, a loop can be terminated early. Is this correct, or "return" be replaced with a "continue"?
<rvba> good spot adeuring, it needs to be a "continue".
 * rvba fixes it.
<adeuring> rvba: cool, thanks!
<adeuring> rvba: very nice branch, r=me
<rick_h__> adeuring: ping, hey I had a MP that was approved and went into QA.
<adeuring> rick_h__: yes?
<rick_h__> adeuring: in QA found an issue, so marked it qa-bad
<rvba> Thanks a lot adeuring.
<rick_h__> adeuring: so now that I've pushed a fix, do I run a new MP? update the old one that's already marked 'merged'?
<adeuring> rick_h__: A new MP is fine, I think
<rick_h__> adeuring: ok, thanks
<rick_h__> adeuring: ok, we're going to keep you busy this morning :) https://code.launchpad.net/~rharding/launchpad/link_tags_894726/+merge/86045
<rick_h__> adeuring: when you get a second please
<adeuring> rick_h__: sure, I'll you ;)
<adeuring> rick_h__: r=me
<rick_h__> adeuring: ty
<flacoste> rick_h__: if you can qa revision 14526, we can roll-out a bunch of issues for the new custom bugs listing
<flacoste> rick_h__: sorry, i just saw that it was marked bad
<flacoste> rick_h__: it needs a rollback?
<rick_h__> flacoste: yes sorry, I've got a second MP landing that fixes it
<flacoste> ok, we should roll-out 14525 then
<flacoste> as it fixes an annoying bug
<flacoste> and we won't be able to roll-out your change today
<flacoste> anyway
<rick_h__> flacoste: ok, looking, is 14525 the chrome bug?
<flacoste> rick_h__: no, it's the sort buttons for advanced search sort order
<rick_h__> flacoste: ah ok. We'll want to get the chrome bug fix rolled out asap as well since it breaks it for all chrome users
<flacoste> rick_h__: is it landed yet?
<rick_h__> flacoste: was going to bring it up on the stand up but deryck is behind.
<rick_h__> flacoste: no, in process of going through ec2 land
<flacoste> rick_h__: that will be deployed next week then
<rick_h__> flacoste: bug just came up a few hours ago
<flacoste> as until the rollback/fix of 14526 is blessed, we can't roll anything after it
<rick_h__> https://bugs.launchpad.net/launchpad/+bug/905228
<_mup_> Bug #905228: Cannot use pagination links on bug listings <bug-columns> <fallout> <Launchpad itself:Triaged by rharding> < https://launchpad.net/bugs/905228 >
<flacoste> and it's not going to be blessed until this afternoon
<flacoste> which is too late for deployment
<rick_h__> flacoste: ok
<flacoste> rick_h__: why is it bad? (there is no comment on the bug)
<rick_h__> flacoste: the JS is broken for all chrome users so no paging/sorting can occur
<rick_h__> it's the same issue we had a couple of weeks ago that we paused the beta for
<flacoste> ah ok
<flacoste> rick_h__: just that to clarify, the "chrome bug fix rolled out asap" you were talking, it's the problem with your qa-bad revision?
<rick_h__> no
<rick_h__> flacoste: seperate issues
<flacoste> ah, ok
<flacoste> so there is an existing chrome issue live in prod now
<rick_h__> flacoste: I was more thinking since we'll have to roll out the chrome issue my qa-bad might get fixed in a hurry anyway since they're landing so close together hopefully
<flacoste> right
<flacoste> but given the delays with buildbot
<rick_h__> flacoste: yes, in prod now
<flacoste> we won't be able to deploy today
<rick_h__> flacoste: ok
<flacoste> because we don't deploy on Friday late afternoon, when everybody is going away
<rick_h__> flacoste: understand, still learning the schedules and such...and I completely forgot today is fridayu
<flacoste> i guess that's a good thing ;-)
<rick_h__> well groggy morning when I see my bad qa issue, broken js on production, so been a bit hectic this morning fixing things :)
<gmb> sinzui, There are currently two Person/EmailAddress combos in the production DB where Person.account and EmailAddress.account don't match. I want to make this problem go away before landing my constraint patch to prevent it from happening again. Which should I use as the canonical source for .account? EmailAddress.account or Person.account?
<gmb> (Sodomy non sapiens is a valid answer here)
<bigjools> is that the gmb translation of bugger off?
<gmb> bigjools, Means I'm buggered if I know :)
<gmb> (In pig latin)
<cjwatson> adeuring: I could use review of https://code.launchpad.net/~cjwatson/launchpad/weaken-xz-dpkg-requirement/+merge/86056 and https://code.launchpad.net/~cjwatson/launchpad/background-scandium/+merge/86058, if you get a chance
<cjwatson> (actually I have six branches in the review queue at the moment but those are the two most urgent ...)
<adeuring> cjwatson: I'll look
<cjwatson> thanks
<deryck> gah, I suck today.  adeuring, rick_h__ Hi! Standup in 10 ok?
<adeuring> deryck: ok
<rick_h__> deryck: we've got a checkpoint call at 11? is that CST?
<deryck> rick_h__, I thought it was 10 CST.
<rick_h__> deryck: nvm...stand up "in 10" not at "10"
<deryck> rick_h__, right :)
<rick_h__> deryck: ignore me...all good
<deryck> ok
<deryck> rick_h__, http://lpqateam.canonical.com/qa-reports/deployment-stable.html
<bigjools> hi benji, can I bug you about lazr.restful, I've got some hassles
<deryck> rick_h__, https://dev.launchpad.net/QA/
<benji> bigjools: sure, what's up?
<bigjools> benji: thanks!  I am amending an existing method, IArchive.getAllPublishedBinaries() and noticed that its tests are specifically using "beta"
<bigjools> I am adding a new parameter, which ought to be "devel"
<bigjools> benji: is it supposed to default to devel?
<bigjools> the tests don't pass if they use it
<bigjools> and there's no explicit declaration in the interface
<benji> we've tried to transition away from defaults, I don't remember what the default is now, if it's even possible to have a default; I think most have an explicit version
<benji> let me see if I can find one for that
<benji> bigjools: I think line 715 of lib/canonical/launchpad/interfaces/_schema_circular_imports.py is where the beta is coming from
<bigjools> !
<bigjools> that explains a lot
<bigjools> benji: I want to do something like this http://pastebin.ubuntu.com/772320/
<deryck> mrevell, just me and rick_h__ joining for Orange for the upcoming checkpoint.
<mrevell> thanks deryck
<bigjools> benji: and declare two signatures, one for beta and one for devel
<bigjools> someone recently added a new one to "beta" which I think is wrong
<benji> bigjools: "a new one" being "signature"?  If it has a default, then it might not be totally wrong, but I agree that not touching beta would be more hygenic.
<bigjools> benji: sorry I meant a new parameter
<bigjools> it's tainted beta, it needs to be on devel
<bigjools> I guess it doesn't *really* matter, but ...
<benji> then your approach sounds perfect
<bigjools> benji: do you know why schema_circular_imports.py has got that line it it when we have decorators@
<bigjools> ?
<bigjools> I can remove it from circ_imports anyway, and do it in the decorators
<benji> bigjools: since we were bad about using as_of (and it might not have even existed in early versions of lazr.restful, I can't remember), that line sets the default for the entry.  as_of is preferred now and the patch_entry_explicit_version call could be removed if all the methods were given explicit versions
<bigjools> benji: ah makes sense, thanks
<deryck> mrevell, flacoste -- high and criticals for the feature: http://tinyurl.com/79opoad
<deryck> Just FYI for the checkpoint
<mrevell> thanks deryck
<mrevell> flacoste, deryck, rick_h__, danhg, matsubara: I'm about to start the Skype conference.
<deryck> firing up Skype now
<flacoste> mrevell: go ahead
<matsubara> mrevell, i'm online
<sinzui> gmb, sorry, I did not see your question. I think the email address must honour the account to get a proper login.
<adeuring> cjwatson: r=me (both MPs)
<cjwatson> adeuring: thanks!  I'm not in ~launchpad - would you be able to send them to EC2 for me?
<adeuring> cjwatson: sure
<cjwatson> ta
<gmb> sinzui: Ah, perfect. Thankyou.
<matsubara> mrevell, can you send a link to the bug listing?
<mrevell> https://bugs.launchpad.net/launchpad/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.importance%3Alist=CRITICAL&field.importance%3Alist=HIGH&assignee_option=any&f
<mrevell> ield.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=bug-columns&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.h
<mrevell> as_no_blueprints.used=&field.has_no_blueprints=on
<sinzui> Oh, I have no sound from IRC, that is why I missed the message
 * sinzui fixes sound
<deryck> adeuring, the beta banner will go away magically when we turn the flag on for "default" right?  (i.e. for everyone)
<adeuring> deryck: yes
<deryck> adeuring, ok, thanks
<bigjools> benji: one more problem! all my tests work apart from the ones specifying the beta api, which complain that there's no IEntry for the beta version.  Do you know how I can work around this?  I tried removing the as_of but it complains it's required.
<benji> bigjools: is that with or without the patch_entry_explicit_version call?
<bigjools> benji: same either way
<bigjools> I removed it in favour of as_of
<bigjools> but was the same before
<rvba> adeuring: I've got two tiny MP up for reviews if you still have time: https://code.launchpad.net/~rvb/launchpad/builder-history-bug-890326/+merge/86050 https://code.launchpad.net/~rvb/launchpad/builder-history-lfa/+merge/86071
<adeuring> rvba: sure
<benji> are "my tests" new tests?
<bigjools> benji: nearly, one of them is new, one of them I moved from beta to devel
<rvba> adeuring: ta
<bigjools> the one left using beta is failing
<benji> hmm, it sounds like something (the IArchive entry itself maybe?) isn't represented in the beta version any more
<benji> maybe a diff would help me
<bigjools> that's what I figured too.  I thought I'd ask in case it's a bug
<bigjools> sure, one sec
<bigjools> benji: partial diff: http://pastebin.ubuntu.com/772367/  and the whole branch is here:  lp:~julian-edwards/launchpad/unordered-getpubbin-bug-904344
<benji> bigjools: I can't see anything wrong with the diff.  I'll try building the branch.  What test invocation will show the failures?
<bigjools> benji: bin/test -cvv test_archive_webservice TestgetPublishedBinaries
<bigjools> thanks for looking
<benji> np
<adeuring> rvba: r=me * 2
<rvba> Thanks adeuring.
<gary_poster> bigjools, could you answer https://answers.launchpad.net/launchpad/+question/182085 or tell me how to?
<bigjools> gary_poster: yup, let me loolk
<gary_poster> thank you
<bigjools> gary_poster: hmm that was affecting bzr earlier too
<benji> bigjools: heh, those tests pass for me <shrug>
<bigjools> benji: argh!
<bigjools> I'll rebuild the wadl
<gary_poster> bigjools, ok I'll check with him to see if it still a problem
<bigjools> gary_poster: I answered already
<gary_poster> cool thanks bigjools
<bigjools> np
<bigjools> benji: it still fails here.... this is weird
<benji> bigjools: maybe try a fresh checkout/build?
<bigjools> benji: did you merge my diff?
<bigjools> it's not pushed up
<benji> bigjools: nope, just checked out the branch; oh!, that's probably it
 * benji patches.
<bigjools> I am not going mad then.... well just a bit
<bigjools> benji: ah it complains at the wadl-making stage
<deryck> adeuring, can you comment on https://code.launchpad.net/~deryck/launchpad/avoid-extra-buglist-count-901124/+merge/85940 before you EOD?
<adeuring> deryck: ah, sure, sorry, I forgot...
<deryck> np
<benji> bigjools: I've found that if I remove the self.ws_version = 'beta' line from test_getPublishedBinaries, it passes
<bigjools> benji: did you re-generate the wadl?
<benji> nope, let me try again after doing that
<bigjools> it passes because it's in devel
 * bigjools wonders how IHasBugs does this
<bigjools> it has the same thing I am doing here
<benji> bigjools: I get an UnknownEntryAdapter, which is probably what you get
<bigjools> benji: yup
<benji> bigjools: the "Encountered as a result of the entry interface None, field ''." bit looks funny
<bigjools> benji: I wonder if it's the @operation_returns_collection_of(Interface)
<bigjools> being in two entries?
<benji> <shrug>
<bigjools> lib/lp/bugs/interfaces/bugtarget.py / IHasBugs is doing this exact same thing.  I must be missing something but .... trees for woods :(
<benji> bigjools: I really need to get some lunch, but I think the "interface None, field ''" thing is a clue; maybe one of the Interface references isn't being correctly patch to the right interface in a circular import module
<bigjools> benji: yes, I suspect it's to do with the multiple versions as well
* adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 3*10^2
<bigjools> thanks for your help so far
<mrevell> Night all
<Noldorin> hi folks
#launchpad-dev 2011-12-17
<cjwatson> Anyone care if I upgrade dogfood?
<cjwatson> May as well get my QA done.
<cjwatson> https://lpbuildbot.canonical.com/waterfall looks a bit confused.
<cjwatson> ("slave lost")
<cjwatson> OK, upgrading mawson now.
<wgrant> cjwatson: Go ahead.
 * wgrant pokes buildbot.
<wgrant> Ah, it was restarted.
<cjwatson> mawson r14517 -> r14539.
<cjwatson> Can anyone tell if there's something wrong with https://dogfood.launchpad.net/ubuntu/+source/libunicode-collate-perl/0.87-1/+build/2802211?  It seems to be taking ages to upload.  I don't see anything of interest in mawson:~launchpad/poppy.log.
<cjwatson> I uploaded the source to dogfood so presumably poppy was at least somewhat working at some point.
<cjwatson> Oh, maybe process-upload.py -C buildd
<cjwatson> There it is.  Sorry to bother.
<wgrant> cjwatson: That doesn't go via poppy.
<wgrant> You can re-cron the process-upload for a while if you want.
<wgrant> It doesn't run all the time because puppet.
<wgrant> Hm
<wgrant> Someone didn't run milestonetag through ec2.
 * wgrant reverts.
<lifeless>  thanks
<wgrant> Actually, I'll just fix it.
<wgrant> Missing UPDATE permissions for person merging.
<lifeless> I'm not sure its the right answer to the problem
<wgrant> Oh?
<wgrant> It's not in a UNIQUE, so it doesn't need to be a 3-parter.
<lifeless> tagging milestones, I mean
<wgrant> The existing merge code in devel will handle it fine.
<wgrant> Ah.
<wgrant> So should I revert it by pretending the fix isn't trivial? :)
<lifeless> well, I think you should be on leave, as I am
<lifeless> :)
<wgrant> True, true.
<lifeless> I have an email thread to reply to about it
<lifeless> I'm glad the squad moved forward
<lifeless> ETRICKY
<wgrant> It'll be on prod on Wed or Thu if you don't argue soon.
<wgrant> Well.
<wgrant> I guess that assumes that people remember to do fastdowntime.
<wgrant> Which seems unlikely, but we'll see :)
<lifeless> stuart will be on leave
<lifeless> soon
<lifeless> we have 2 FDT's to do before this could be a candidate
<wgrant> Yes.
<wgrant> Although I think we could really sensibly do the first one live.
<lifeless> if it lands, and we decide it was wrong, its not a huge deal
<wgrant> It's a very low-use table.
<wgrant> True.
<lifeless> wgrant: if anything references the table, it will get related PK row locks taken out on updates even if the table isn't mentioned in the query
<wgrant> Sure.
<lifeless> which table is it again?
<wgrant> sourcepackagerecipedata
<wgrant> Which should only be referenced by sourcepackagerecipedatainstruction.
<wgrant> Oh, and build.
<wgrant> Inconvenient.
<lifeless> :)
#launchpad-dev 2011-12-18
<rick_h__> wgrant: ping
<wgrant> rick_h__: Hi
<rick_h__> wgrant: hey, saw your bug. I've got a fix I'm trying to land for that, but it got rejected by pqm for a bad commit message regex
<wgrant> rick_h__: PQM is in testfix because of a bad db-devel landing.
<rick_h__> with the lack of rollouts over friday/weekend it was decided to not rollback, just land
<rick_h__> ah, so that's what it's saying
<wgrant> OK.
<wgrant> Let's cheat.
<wgrant> If we force db-devel to build, you can land stuff until it fails again.;
<rick_h__> wgrant: https://code.launchpad.net/~rharding/launchpad/link_tags_894726 has the fix
<wgrant> It's forced -- try landing again at :21 or so
<rick_h__> wgrant: ah ok. Will get that ready then
<rick_h__> now this is just via a pqm land right? bypassing ec2?
<wgrant> Yep
<wgrant> Use bzr lp-land
<wgrant> Or bzr pqm-submit directly, if lp-land doesn't work.
 * rick_h__ hasn't tried that out yet
<rick_h__> will do
<wgrant> Use bzr lp-land just like ec2 land
<wgrant> Or pqm-submit like 'bzr pqm-submit -m "[r=foo][bug=bar] blah blah blah"'
<rick_h__> ok, will try bzr lp-land in a few then.
<wgrant> Great.
<rick_h__> wgrant: "bzr: ERROR: No PQM submission email address specified for" quick search finds a request to add a feature to bzr, nothing in dev.lp.net?
<wgrant> rick_h__: Hm, if you're using the directory structure generated by rocketfuel-setup that should work.
<wgrant> Otherwise --public-location=bzr+ssh://bazaar.launchpad.net/~rharding/launchpad/link_tags_894726 --submit-branch=bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel
<rick_h__> yea, that's how I got things started...ok will poke at it.
<wgrant> Give those two options to pqm-submit as well.
<rick_h__> wgrant: ok, running
<rick_h__> yea, same email error
<rick_h__> sorry, that's from the bzr pqm-submit, let me try the other
<wgrant> Oh.
<wgrant> email address
<wgrant> Hm
<wgrant> You are running it from the right directory, right? :)
<rick_h__> yea, same...grr
<rick_h__> /home/rharding/launchpad/lp-branches/link_tags_894726
<wgrant> Hmm
<wgrant> Does your ~/.bazaar/locations.conf have a 'pqm_email' set?
<rick_h__> no, nothing there
<wgrant> Huh
<wgrant> rocketfuel-setup should have set that up.
<wgrant> I think.
<wgrant> Maybe not.
<wgrant> http://pastebin.ubuntu.com/773959/ is what I use
<rick_h__> yea http://doc.bazaar.canonical.com/plugins/en/pqm-plugin.html seems to imply I need a bunch of stuff
<wgrant> You probably already have the second part of that.
<rick_h__> yea, just missing the email bits
<rick_h__> ok, got something going. lp-land still hates me, but the manual command with paths ran
<wgrant> Heh
<rick_h__> can I manually change the tag then on the bug from qa-bad?
<wgrant> It's complicatedâ¢
<wgrant> It's technically not qa-bad.
<wgrant> Because we already deployed it, but disabled the feature.
<wgrant> So yes, it's no longer qa-bad.
<rick_h__> yea, I seemed to have done this a bit wrong from the start unfortunately :/
<wgrant> qa-tagger will automatically reset it to qa-needstesting once this lands.
<rick_h__> ah ok then
<wgrant> Meh, our QA workflow was designed before feature flags.
<wgrant> Nobody is quite sure how it works in this situation :)
<rick_h__> I wasn't sure if pqm would even try this since it was qa-bad already
<wgrant> PQM doesn't know about any of that.
<rick_h__> gotcha, still figuring out the moving parts. Just a few of them :)
<wgrant> Yeah :/
<rick_h__> It's nice to have the whole process, but sometimes miss $ ssh server && git pull
<wgrant> Yeeeeeees.
<rick_h__> thanks for the help wgrant and the link to the pystache fix. I had missed that.
<wgrant> np
<rick_h__> I really hate that thing, but can't find anything else with both server/clide side use :(
<wgrant> Yeah :/
<wgrant> It seems to work mostly.
<rick_h__> yea, but it's got a lot of issues to watch out for like this
<rick_h__> love that there's a branch named "spec-compliant"
<wgrant> Heh
<rick_h__> kind of would hope that would be called ...oh... "master"
<rick_h__> sweet, pqm emails say merged
<wgrant> You would think so :)
<wgrant> Excellent!
<lifeless> right, mail sent
<wallyworld_> lifeless: you around for a quick question?
<wgrant> wallyworld_: He's not here this week.
<wgrant> StevenK: around?
<wallyworld_> wgrant: you weren't online yet :-) i just wanted to know, how to fix the deployment report to link rev 14540 as fixing qa-bad rev 14526
<wgrant> That's a trick question.
<wgrant> 14526 isn't really qa-bad
<wallyworld_> it's marked as qa-bad
<wgrant> But it's a lie :)
<wgrant> Hmm.
<wgrant> Perhaps not.
<wallyworld_> if it were qa-bad, and a subsequent rev was landed without the correct tag, how do we fix that?
<wgrant> rick_h__ confused me yesterday.
<wgrant> I thought the bug listing beta was disabled so we could deploy that revision anyway.
<wgrant> But that revision is not deployed.
<wallyworld_> ie to say that once 14540 is ok, so too is 14526
<wgrant> Which must mean there's another bad revision that caused the beta bug listings to be disabled.
<wgrant> wallyworld_: There's no way to do that.
<wgrant> You have to lie that one of them is qa-ok, or just pretend that the deployment report is green.
<wallyworld_> normally, landing a subsequent rev is rollback-xxx is the right thing to do, no?
<wallyworld_> s/is/with
<wallyworld_> rollback=xxx i mean
<wallyworld_> i'm keen to get my rev 14528 deployed since it fixes a regression
<wgrant> "normally"" == if you want to wait 13 hours
<wgrant> Which you don't.
<wgrant> So normally doesn't apply here.
<wallyworld_> what i meant was, rev 14540 should have been landed with rollback=14526
<wgrant> Ah, yes, probably.
<wgrant> But I was under the impression that the earlier rev was already deployed.
<wallyworld_> and since it wasn't i wanted to fix but it seems we can't do that from what you said above
<wgrant> You can't, no.
<wallyworld_> and it seems we can't deploy for a while then since there's a lot on un-qaed revs between 14526 and 14540
<wallyworld_> so my regression fix will have ot wait :-(
<wgrant> I also don't know why the bug listings are disabled.
<wallyworld_> i thought there was an issue (which i can't recall) hence they were to only be for ~launchpad-beta
<wallyworld_> are they now disabled for everyone?
<wgrant> They're disabled for everyone.
<wgrant> They're not out of beta yet.
<wgrant> Still ages away from being ready.
<wallyworld_> wgrant: so there must have been an issue then that cause them to be turned off since i joined the team which allowed me to see them
<wallyworld_> and they are due out of beta this week afaik
<wgrant> due, yes :)
<wgrant> Many things have been due out of beta before.
<wallyworld_> we'll see then i guess. it did appear to all be under control
#launchpad-dev 2012-12-10
* wgrant changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: - | Firefighting: - | Critical bugs: ~160
<StevenK> Hmmmm
<StevenK> Not really happy with this query
<StevenK> And it seems BulkUpdate does not love list types
<wgrant> Indeed, probably not
<StevenK> I don't like the NULLs, either
<wgrant> ?
<StevenK> wgrant: http://pastebin.ubuntu.com/1422314/
<wgrant> Right, those will want to be removed.
<wgrant> (potentially by coalescing the potentially null array with an empty one)
<StevenK> Hmmmm, can I just use COALESCE for that?
<wgrant> Yes
<StevenK> Hmmm, it will only return the first, though
<wgrant> Hm?
<StevenK> "The COALESCE function returns the first of its arguments that is not null."
<StevenK> If I feed it an array of {NULL,0.9,1:0.9} ...
 * StevenK plays
<wgrant> Hmmmm?
<wgrant> You'd either remove NULL from the resultant array, or coalesce a null array
<wgrant> Not coalesce an array that contains null
<StevenK> So my query as it stands is okay?
<wgrant> Perhaps something like https://pastebin.canonical.com/80039/
 * StevenK searches for his phone for 2FA
<StevenK> [(1, '{0.9}')]
<StevenK> Looks like success to me
<StevenK> Except for that quoting
<wgrant> It's probably because it's a debversion[], not a text[], so psycog2 doesn't know what to do with it
<StevenK> TypeError: Expected unicode, found <type 'str'>: '{'
<StevenK> That's the error I'm getting from the BulkUpdate
<StevenK> But searchable_versions = List(type=Unicode()) because type=StringCol() didn't look right
<wgrant> BulkUpdate may not cope with lists
<wgrant> You'll need to check
<StevenK> Yeah, I'm about to dig in and see what UPDATE statement it is creating, but I wasn't sure if my List() defintion was sane
<StevenK> Hmmm
<StevenK> Perhaps it's my fault, since it's barfing over my values list
<StevenK> [[<storm.variables.IntVariable object at 0xa39b050>, <storm.variables.ListVariable object at 0x88cc738>]]
<StevenK> Well, that's very handy, storm. Thanks.
<bigjools> there's something oddly satisfying about typing "dput -fu"
<lifeless> bigjools: you need to get out more :)
<wgrant> poppy deserves it
<StevenK> wgrant: I think you might be right.
<bigjools> lifeless: said without a trace of irony :)
<StevenK> (Pdb) p values[0][1]._value
<StevenK> '{0.9}'
<StevenK> Me thinks a ListVariable wants something more list-like
<bigjools> trevormosey must be really famous
<wgrant> bigjools: Heh, yes
<wgrant> There's a bug for that
 * bigjools blames the dput ppa script
<bigjools> putting in that ~ by default was a huge mistake
<StevenK> That always trips me up too
<wgrant> bigjools: Well
<wgrant> bigjools: It probably comes from the ppa.launchpad.net HTTP layout
<wgrant> That was the first place to drop the tilde
 * StevenK doesn't like the thought of results[1][1:-1].split(',')
<wgrant> StevenK: No
<wgrant> StevenK: Perhaps try casting the array to a text[]
<wgrant> See if psycopg2 interprets it then
<wgrant> If you manually parse the array I will strangle you :)
<StevenK> wgrant: You'll have to get in line behind me
<StevenK> I will strangle myself first
<bigjools> wgrant: that was also stupid :(
<wgrant> bigjools: Certainly
<bigjools> my fault, sadly
<wgrant> Really?
<wgrant> It was very early in your time...
<bigjools> I had the opportunity to fix it when we added multi-ppas
<wgrant> True
<StevenK> wgrant: ARRAY[]::text[] == bang
<wgrant> StevenK: Bang?
<StevenK> If that's what you mean
<wgrant> That seems like casting the empty array
<bigjools> yeah it was early in my time
<wgrant> Which will fail because you're trying to append it to a debversion[]
<wgrant> Cast the entire result array
<wgrant> Multi-PPAs would indeed have been the best time to add them
<wgrant> Although I thought that feature was somewhat influenced by the initial implementation that was removed before PPAs were released.
<wgrant> If I recall correctly from my bug...
<StevenK> Hmmmm
<StevenK> http://pastebin.ubuntu.com/1422367/
<StevenK> Holy fuck, it works
<StevenK> Perhaps I shouldn't be so surprised
<wgrant> Oh, so my BulkUpdate hacks just worked with a list when the type was correct?
<StevenK> wgrant: So it seems
<wgrant> I'm disappointed
<StevenK> I put the entire block in ()::text[]  which I thought was dubious at best, but worked
<wgrant> Well, we're stuffing them into a text[] column in the end, and we don't want to perform version comparisons on them
<wgrant> So it's the right thing to do
<StevenK> wgrant: Right, but I've not had to do manual casting in postgres before, so I was guessing
<wgrant> Ah
 * StevenK ponders commiting evil on DF
<StevenK> wgrant: Didn't we have a PQM check that you couldn't modify anything outside database/ in a DB branch? Or did that die?
<wgrant> StevenK: Sometimes you need to modify tests and similar
<wgrant> We rely on people thinking about deployment
<wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/improved-html_escape/+merge/138902
<StevenK> 52-56 can be done without my eyes bleeding, surely?
<wgrant> Not really.
<wgrant> How?
<StevenK> Looping over replacements?
<wgrant> Mmm, it'll be slightly shorter.
<StevenK> wgrant: What about invalid unicode for line 51?
<wgrant> (or longer)
<wgrant> StevenK: It's hideous but I didn't change it
<StevenK> So you didn't
<wgrant> We assume that all messages are a unicode or an ASCII bytestring.
<StevenK> Because WCPGW, right?
<wgrant> No
<wgrant> Because what else can you do?
<StevenK> Well
<StevenK> Be sane
<wgrant> It's a reasonable assumption, and it will crash if it's not valid
<wgrant> Which is all that it's reasonable to do
<StevenK> % bzr grep 'import cgi' | wc -l
<StevenK> 30
<StevenK> I guess they're next on the chopping block?
<wgrant> Indeed
<wgrant> But it's a big diff
<wgrant> So it's a separate branch
<wgrant> two weeks ago I moved this stuff into its own module
<wgrant> This branch makes it usable generally
<wgrant> The next two branches eliminate the other four escaping mechanisms
<StevenK> wgrant: r=me
<wgrant> Thanks
<StevenK> wgrant: Adding "I will be destroying all other escaping mechanisms in terms of LoC gain in a future branch" would have been nice, but meh
<StevenK> Dear mawson, where does it hurt?
<wgrant> Well
<wgrant> that's a few more test failures than I expected
<StevenK> On buildbot?
<wgrant> Yeah
<wgrant> 110 or so
<wgrant> Mostly due to apostrophes
<StevenK> Oh yes, aren't you a naughty boy
<StevenK> wgrant: You're working on the 111 bad tests?
<wgrant> Yes
<StevenK> wgrant: How do you feel about reviewing my +298,-60 garbo branch? :-)
<wgrant> I may end up reverting, but I suspect I'll be able to fix the tests before anyone else wants to land stuff
<wgrant> Maybe :)
<StevenK> It depends on 40-1 being deployed before it can land, but I can work on making it wgrant-approved first
<StevenK> 2012-12-10 05:28:29 DEBUG2  [PopulatePackageUploadSearchableVersions] Iteration 591 (size 2155.0): 5.698 seconds
<StevenK> Daaaaaaaaaaaamn
<wgrant> Right, no trigram indices and the rows should be much smaller :)
<wgrant> Trigram indices are awful
<wgrant> So they should only be used where necessary
<StevenK> I am incredibly curious just how long it will take to create the index on DF when the columns are fully populated
<wgrant> Yeah
<StevenK> wgrant: They're awful for performance? But in this case good for searching performance?
<wgrant> You'll probably want a GIN index on the searchable_versions
<wgrant> StevenK: They perform awfully in all respects
<wgrant> They're just less awful than a seq scan when doing a substring match
<wgrant> That's the only respect in which they have any value
<StevenK> Oh. So they're totally awful, but they're best we have for the problem.
<wgrant> Right
<wgrant> And it's not feasible to get much better
<wgrant> It's a hard problem
<wgrant> So it should be avoided
<wgrant> By not supporting substring matches unless it's unavoidable
<StevenK> wgrant: I don't have branches for the indicies yet, only a diff that gives me the TGRM for searchable_names
<wgrant> Right
<StevenK> wgrant: Hmmm, since searchable_versions is TEXT[], can I ask for rows where that column has more than one value?
<wgrant> StevenK: Why do you want them?
<StevenK> wgrant: Curosities sake, not for code
<StevenK> Was wondering if there was a short cut
<wgrant> a GIN index won't do that for you. You'd have to index array_length(searchable_versions) directly to do that efficiently.
<StevenK> wgrant: You misunderstand. I only want to check rows on DF manually, not in the code at all
<wgrant> Ah
<StevenK> However WHERE array_length(searchable_versions) > 1 will probably work then
<wgrant> WHERE array_length(searchable_versions) > 1?
<wgrant> Yeah
<StevenK> ERROR:  function array_length(text[]) does not exist
<StevenK> ... but it's an array, you still DBMS?
<wgrant> Oh
<StevenK> s/still/silly/
<wgrant> array_length(searchable_versions, 1)
<wgrant> Needs a dimension
<wgrant> (and it's 1-based, because who needssanity)
<StevenK> Database developers are all insane, anyway
<wgrant> blarfgghergherger
<wgrant> manual escaping ftl
<wgrant> some of these errors have been being double-escaped for years
<wgrant> Applause
<StevenK> Hm?
<wgrant> Well
<wgrant> LaunchpadValidationError is used by lots of fields
<wgrant> It HTML-escapes all errors pushed through it, so you can push through markup if you need to
<wgrant> But the fields are also used by eg. XML-RPC and email interfaces
<wgrant> Where HTML-escaping is not right
<wgrant> This has historically gone largely unnoticed, as only <, >, & were escaped globally
<wgrant> And they're relatively rare characters
<wgrant> s/And/As/
<wgrant> For now I'm going to take the easy way out and change the error message to not contain an apostrophe...
<wgrant> :)
<StevenK> Naughty
<wgrant> I try.
<nigelb> TMI.
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/populate-searchables-for-pu/+merge/138906
<wgrant> 17 to go...
<StevenK> Failures?
<wgrant> Yes
<wgrant> Ooh
<wgrant> A real bug, finally
<wgrant> 1920 lines of diff later and all but three should be fixed...
<StevenK> Haha
<StevenK> That's going to be fun to review
<wgrant> StevenK: Do you perhaps want to split the garbo job into a separate branch?
<wgrant> So it can be more easily reverted later
<wgrant> And to make it easier to review
<wgrant> (also, I'd say "addSearchableName" rather than "appendSearchableNames")
<wgrant> addBuild is hideous; pls rewrite
<wgrant> appendSearchable* will want to check that the given string isn't already in there
<wgrant> It's probably best to parse the string into a set, then add the new names and reserialise
<StevenK> wgrant: I can split out the two garbo jobs if you wish, but they're very well contained
<wgrant> This is true
<wgrant> They could also use a comment or two :)
<StevenK> They have two each, I though?
<StevenK> Well, the tests do. :-)
<wgrant> Doesn't seem to
<wgrant> It's just;
<wgrant> MASSIVE BLOB OF THE MOST HIDEOUS SQL KNOWN TO MAN
<wgrant> MASSIVE BLOB OF STORM MOLESTATION
<wgrant> fin
<wgrant> :)
<wgrant> Although I guess they'll be gone soon
<StevenK> s/BLOB/TEMPORARY BLOB/
<StevenK> wgrant: I'm quite proud of the two SQL statements we cooked up.
<wgrant> Speaking of which
<StevenK> They are HIDEOUS and eat babies, but they work and are performant
<wgrant> Why not do them both at once?
<wgrant> THey're going to be rewriting the same rows
<wgrant> Might as well do it in one hit
<StevenK> wgrant: Because I went to change the SQL statement in Populate...SearchableNames and it nearly bit my hand off
<wgrant> You should just be able to keep the two expressions separate, but in the same findspec.
<StevenK> Mmmmm
<StevenK> Right, so your complaints are: addBuild is terrible, and I should fix it, appendSearchable* should be renamed and parse the existing values if any to a set and then add the new bits, the garbo jobs should be put on a diet, IE, from two to one, and the new one could use some comments?
<wgrant> Right
<StevenK> Anything else?
<wgrant> The comments are going to be useful for people wanting to write similar garbo jobs in future
<wgrant> It otherwise looks sensible
<StevenK> Except the comments will die shortly
<wgrant> Though the bit that sets searchable_* from the PCJ could do with a comment saying the rest will be added when the PU. is added
<wgrant> StevenK: Sure, but they'll be in history
<StevenK> Perhaps I should put the comments in the caching job?
<StevenK> Since that is sticking around
<wgrant> Perhaps so
<StevenK> wgrant: The rest will be added when the PU is? EPARSE
<wgrant> StevenK: The PU[SBC]
<StevenK> I don't think we call any of the three add methods on a PCJ'd PU
<StevenK> The binaries from any builds will get a new PU
<wgrant> Is that method only used for PCJs?
<StevenK> Yeah
<wgrant> Indeed
<wgrant> That's fine, then
<nigelb> Ooh.
<nigelb> I finally upgraded.
<nigelb> This means I can setup LP in an LXC.
<StevenK> Haha
<StevenK> I guess "Warning: Permanetly added the RSA host key for IP address '<IP of taotie>' to the list of known hosts." means my laptop hasn't hit up LP for a long while
<cjwatson> wgrant,StevenK: we don't have a use case for substring matching on versions in the upload queue, but we do have a use case for exact matching.  Are you preserving that facility, or are we going to need to perpetrate a workaround?
<wgrant> cjwatson: Exact matching is easy and cheap and is being preserved
<cjwatson> Excellent
<wgrant> I will strongly resist any attempt to preserve substring matching :)
<cjwatson> (That use case being "queue accept -e packagename/version")
<wgrant> yep
<cjwatson> Which reminds me, I should flip the -e default in the queue client, maybe after all this lands
<StevenK> After I'm done, source='foo', version='bar', exact_match=False will do a substring match for foo, but an exact match for bar
<cjwatson> That's fine for our needs, yes
<cjwatson> And I think what we were expecting to happen anyway
<StevenK> It doesn't right now
<wgrant> exact_match=True should be the default everywhere
<wgrant> If your client does not already, pls fix :)
<cjwatson> I know, it only doesn't because:
<cjwatson> (a) it was a translation of the LP script which was insane
<wgrant> Heh
<wgrant> Yeah
<wgrant> LP has some bad history there
<wgrant> eg. getPublishedSources, IIRC
<cjwatson> (b) exact matching actually turns out to be quite inconvenient without SPN matching on build uploads
<StevenK> cjwatson: I'll be fixing b
<wgrant> Ah, indeed
<cjwatson> Exactly, so I should be able to flip the default after this lands
<StevenK> 'This'
<StevenK> It's a mess of seven branches :-)
<cjwatson> I scoff at your attempt to impose reality on my grammatical choices
<StevenK> Hah
<czajkowski> aloha
* benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: benji | Firefighting: - | Critical bugs: ~160
<benji> I am going to assume that bcsaller is not in this morning and that we can clear up any remaining issues with his review of https://codereview.appspot.com/6909046/ later and land my branch.
<benji> and I am going to talk about it in the wrong channel, is that cool with everyone?
<rick_h_> benji: that's cool and I approve
<benji> rick_h_: good, now I have an excuse for my crosstalk
<gmb`> benji, Morning. Is there any reason for me to not mark BjornT's merge proposal for lp2kanban as approved so Tarmac can land it: https://code.launchpad.net/~bjornt/lp2kanban/bugs-to-cards/+merge/135909
<gmb`> ?
<benji> gmb`: not that I know if.  I believe it is good to go.
<gmb`> Awesome.
 * gmb kills the imposter
<nigelb> Oh dear.
<gary_poster> gmb, as a poster I find that concerning.  on another note, are you helping BjornT land his lp2kanban branch?  If not I can try to do so
<gmb> gary_poster, I thought lp2kanban was all Tarmac goodness these days.
<gmb> If not, then I'm happy to take care of it.
<gary_poster> gmb, dunno, forgot.  I was going to try to add BjornT to whatever group he needed to be in in order to land the code...
<gary_poster> looking to see what that would be...
<gmb> gary_poster, ~launchpad.
<gary_poster> oh :-/
<gmb> (Well, that's who owns the trunk branch)
<gary_poster> right
<gmb> So I'll land it now.
<gary_poster> ok thanks gmb
<gmb> Wow, rocketfuel-get takes a while... Remind me, why did we write all this code/
<gmb> ?
<sinzui> gmb, that reminds me...
<sinzui> gmb, gary_poster is there a rule to remove tarballs from lp-sourcecode deps? I went to remove a few last week, then panicked when I realised other projects (not ~launchpad) use it
<gmb> sinzui, Really? Which projects?
<sinzui> oops tools
<sinzui> maybe others
<gmb> Urgh.
<gary_poster> sinzui, I know of no rule.  The proper solution has always been to not use a branch and instead have tarballs hosted somewhere internally and never delete anything.
<gary_poster> yeah I think other projects too
<gary_poster> Robert wanted them to be shared
<gary_poster> This is an unintended downside, I think
<gmb> bac, I've added a section for Green Squad to the lp2kanban config; can you update it on the Canonistack instance please?
<bac> gmb: sure, in an hour or two.  on standup now
<gmb> bac, Sure, that's fine. Thanks.
<bac> gmb: actually the config should be added to lp-tarmac-configs project not lp2kanban
<bac> gmb: the one in lp2kanban is an example only
<gmb> bac, lp-tarmac-configs is the one I've updated.
<gmb> Sorry, didn't make that clear.
<bac> gmb: just for fun, you could login, poweroff, and then bin/startmeup.  would be nice for someone else to exercise that path.
<gmb> bac, I would if I could remember to what I should ibe logging in.
<jcsackett> benji: you have time to review https://code.launchpad.net/~jcsackett/launchpad/no-private-releases/+merge/139092 ?
<sinzui> benji, do you have time to review https://code.launchpad.net/~sinzui/launchpad/person-owned-teams/+merge/139091
<rick_h_> jcsackett: wins!
 * jcsackett laughs
<benji> jcsackett and sinzui: sure, but first you invoked the rarely used simultanious review smackdown
<sinzui> I am wearing glasses
<sinzui> You cannot hit a four-eyed developer even if he is complete an utter bastard
<jcsackett> sinzui: i am also four eyed. i think that nixes it. :-P
<jcsackett> however, i like sinzui. if i must hit him to be reviewed first, i'll wait to be second. :-P
<rick_h_> ok, then sinzui must hit you to be reviewed first
 * jcsackett laughs
<rick_h_> there must be smack in the smack down
<sinzui> how?
<sinzui> I shall invoke the one-hand clapping smack
<jcsackett> tell you what. sinzui can drive down hear to smack me. in the meantime, benji can review my branch. :-P
<jcsackett> s/hear/here/
 * sinzui claps
<benji> heh
 * sinzui has pulled a muscel and may have broken a nail
<benji> jcsackett and sinzui: both of your branches are reviewed.  I won't tell you which I did first.
<sinzui> thank you benji
<benji> my pleasure
<jcsackett> thanks, benji.
<benji> any time
<lifeless> OOPS-3de41986b624ef0f542b92653ce1cfe8 <- ?
<sinzui> lifeless, timout inserting a bug. looks like a row lock
<lifeless> \o/
<lifeless> bugs 1088650 and 1088651 appear either private or missing, to me
<lifeless> I tried again and got ...2
<sinzui> lifeless, I can see the first, not the second, and I don't have power to confirm if the private-is-404 rule
<lifeless> interesting, cool.
<lifeless> I am suffering cat-in-lapsy
<lifeless> it is very distracting
<wgrant> deryck: Hi
* benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: - | Firefighting: - | Critical bugs: ~160
<deryck> hi wgrant
<wgrant> deryck: I see that a couple of your DB changes have model changes as well.
<wgrant> That's forbidden because we can't confirm it's safe (we don't deploy DB and app changes at the same time)
<wgrant> In particular, one of your branches makes a column not null at the same time as it sets a default in the model.
<deryck> wgrant, I don't think my revs do.  but maybe abel's does.  I didn't look at his honestly, sorry.
<wgrant> Ah
<lifeless> 'royal your' :P
<wgrant> Well, yes :)
<deryck> wgrant, ah, no that is mine.  I checked with stub and thought it was cool.
<deryck> wgrant, we already protect against in the model, and I did some query checks to make sure we were safe.
<wgrant> zAh
<wgrant> It's actually safe, because there's a default in the DB
<wgrant> But we forbid model changes in the same branch to avoid any confusion
<wgrant> And ensure that the devel code and db-devel DB can coexist
<wgrant> Rather than having to reason about it manually
<deryck> wgrant, ok, sorry about that. I assume it's okay to deploy this time, so long as I don't do it again? :)
<wgrant> Indeed.
<deryck> ok, thanks.  sorry again.
<wgrant> abel's branch is also OK to deploy, but it's unnecessarily mixing DB and app changes, so it has to be manually verified.
#launchpad-dev 2012-12-11
<StevenK> wgrant: Even worse block of SQL is strange. Running it by hand returns 3 columns, but only two turn up in list(results)
<wgrant> StevenK: What does the Python look like?
<StevenK> wgrant: Ugh, the diff is horrible
<StevenK> wgrant: I can pastebin the diff, but it's nigh on unreadable. Or I can pastebin the garbo's __call__
<wgrant> The latter would be nice
<StevenK> wgrant: http://pastebin.ubuntu.com/1424454/
<wgrant> StevenK: It looks like that SQL is all one big string
<wgrant> Which is not going to work very well
<StevenK> wgrant: I need to split it up? Postgres deals ...
<wgrant> StevenK: But Storm has no idea that there's going to be an extra column.
<wgrant> It needs to be two separate items in the findspec
<StevenK> wgrant: So (PackageUpload.id, SQL(...), SQL(...)) ?
<wgrant> Yes
<StevenK> Hmm, that's a little bit of a trap
<StevenK> But it makes sense
<StevenK> wgrant: I currently have seperate tests for searchable_names and searchable_versions, shall I pull those together too?
<wgrant> Might as well
 * wgrant plays buildbot roulette again
<StevenK> I wonder if you'll lose as hard today :-)
<wgrant> Hopefully not
<wgrant> These are more isolated changes
<wgrant> 1 failure so far...
<StevenK> wgrant: When you're finishing sharpening knives for buildbot, testrespository and/or subunit, https://code.launchpad.net/~stevenk/launchpad/populate-searchables-for-pu/+merge/138906 is ready for a second close-up.
<wgrant> Just fixing 18 doctests
<wgrant> will be a few minutes
<StevenK> wgrant: Where a few is ten or more? :-)
<wgrant> shh
<StevenK> Or more like 30 ...
<wgrant> The first 16 were easy :)
<wgrant> The last two are some odd double-escaping...
<StevenK> Haha
<wgrant> Ah
<wgrant> Hmm
<wgrant> The URL linkification regexp is the problem here
<wgrant> It's run over the HTML, not the text
<wgrant> But it pretends it's running over text
<StevenK> Hmmmmmm
<wgrant> It has historically works because & and ; are unreserved characters
<wgrant> But ' is now escaped as &#x27;, and # is not unreserved
<StevenK> I think the set() magic used by add{Source,Build,Custom} doesn't happen in the garbo job
<wgrant> But we don't care about the specific parsing of the structure of the URL
<wgrant> So I'm just going to pretend that # is unreserved too
<wgrant> StevenK: What do you mean?
<StevenK> wgrant: Consider ' 1780947 | libfile-finder-perl libfile-finder-perl               | {0.53-1}
<wgrant> Ah
<wgrant> Ah
<wgrant> The source and binary have the same name, of course
<StevenK> Right
<StevenK> And our magic query doesn't do that
<wgrant> Might as well throw in a 'SELECT DISTINCT name FROM unnest([... the array expression ...]) ORDER BY name' or similar, I guess
<StevenK> In which bit?
<StevenK> Oh, around the array_to_string()
<StevenK> No, wait
<wgrant> Inside the array_to_string
<wgrant> unnest() is rather special
<wgrant> It converts an array into a set of rows
<wgrant> So you can perform operations on it as if it was a table
<StevenK> We already have array_to_string( (...) || (...) || (...) || (...))
<wgrant> Right, but before you convert it to a string you want to make it unique and ordered.
<StevenK> ... I think I have the brackets right
<StevenK>             array_to_string(SELECT DISTINCT name FROM unnest(
<StevenK>             (SELECT array_agg(
<StevenK> ProgrammingError: syntax error at or near "SELECT"
<StevenK> LINE 2:             array_to_string(SELECT DISTINCT name FROM unnest...
<wgrant> At that point you might as well use string_agg directly, I guess. SELECT string_agg(DISTINCT name ORDER BY name) FROM unnest(...)
<wgrant> Oh right
<wgrant> Atom is stupid
<wgrant> Feed content is *meant* to be double-escaped...
<StevenK> reference = u'binarypackage-102763 unique-from-factory-py-line3339-102754'
<StevenK> actual    = u'unique-from-factory-py-line3339-102754 binarypackage-102763'
<StevenK> Bleh
<StevenK> I guess we do not care about the order at all, just as long as they're both there
<wgrant> Mmm
<wgrant> Ideally it would be ordered
<wgrant> And it's easy
<StevenK> That's from add{Source,Build,Custom}
<wgrant> Ah
<wgrant> Still easy
<wgrant> sorted()
<wgrant> done
<wgrant> :)
<StevenK> >>> ' '.join(set(['b']) | set(['a']))
<StevenK> 'a b'
<StevenK> So I think it is sorted already
<StevenK> Just the test assumes SPR first
<wgrant> Oh, so the reference/actual are swapped?
<StevenK> So it would seem, because:
<StevenK>          names = '%s %s' % (
<StevenK> -            upload.builds[0].build.source_package_release.name, bpr.name)
<StevenK> +            bpr.name, upload.builds[0].build.source_package_release.name)
<StevenK> Blah
<StevenK> ./2012-12-06/OOPS-f4b0427a8f57ec8a0619d40b49fc93c8 exists on neem, but the string 'OOPS' does not
<StevenK> Oh, it does, just that less doesn't admit to it, which is handy
<StevenK> ProgrammingError: syntax error at or near "' '"
<StevenK> LINE 50:         )), ' '),
 * StevenK whimpers
<StevenK> Hmmmm
<StevenK> I *think* r15555 fixed bug 835645
<_mup_> Bug #835645: DistroSeries:+queue timeout paginating <lp-soyuz> <queue-page> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/835645 >
<wgrant> StevenK: Unlikely, why?
<StevenK> wgrant: Because r15555 changed get_all() to use a DRS
<wgrant> Hmm
* frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: frankban | Firefighting: - | Critical bugs: ~160
<bac> gmb: did you get your kanban issue fixed?
* rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: frankban | Firefighting: - | Critical bugs: ~160
* rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: frankban, rick_h | Firefighting: - | Critical bugs: ~160
<jcsackett> rick_h_: mp for you, when you have a moment: https://code.launchpad.net/~jcsackett/launchpad/no-releases-for-projectmilestone/+merge/139221
<rick_h_> jcsackett: will do
<rick_h_> jcsackett: r=me, but man I hate when something doesn't have what the interface says it has and it implements the interface
<jcsackett> rick_h_: does it make you feel better that product_release *isn't* on the interface?
<jcsackett> :-P
<czajkowski> sinzui: thoughts on https://bugs.launchpad.net/launchpad/+bug/1088959
<_mup_> Bug #1088959: launchpad.net crashes webkitgtk browsers. <Launchpad itself:New> < https://launchpad.net/bugs/1088959 >
<sinzui> I will look into it. I think it is bogus. Midori and Epiphany are very reliable and I have not experienced any issues.
<czajkowski> nods
<czajkowski> sinzui: how's you today? very quiet
<sinzui> I have a bug just about fixed, but I got distracted a 403 when looking at code imports, bug 1089023
<_mup_> Bug #1089023: Proprietary branches break code import listing <403> <branches> <regression> <sharing> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1089023 >
<czajkowski> ah nice one to fix
<sinzui> rick_h_, do you have time to review https://code.launchpad.net/~sinzui/launchpad/allow-vcs-imports-to-rename-a-branch/+merge/139270
<rick_h_> sure thing sinzui
<rick_h_> sinzui: r=me thanks
<sinzui> thank you rick_h_
<timrc> hm one of our scripts caused LP to return a 500... no bueno
<rick_h_> timrc: burn that script, it's faulty clearly :P
<timrc> rick_h_, clearly :)
<timrc> rick_h_, how do I look up an oops again? ID OOPS-b69df532ee375ff926e1605527d0b7d6
<rick_h_> https://oops.canonical.com/
<rick_h_> so https://oops.canonical.com/?oopsid=OOPS-b69df532ee375ff926e1605527d0b7d6
<rick_h_> timrc: hmm, that change was reverted.
<rick_h_> timrc: so that should be corrected now, but looks like you hit it while it was broken early this morning/overnight
<czajkowski> that was fixed hours ago.
<rick_h_> timrc: so maybe you can keep the script around a little longer since it was our fault
<timrc> czajkowski, OK, the problems were reported to me while on vacation on the 10th
<timrc> you guys should wait to introduce bugs when I'm not on vacation, jeez
<rick_h_> shoot, but how will I meet my 'break timrc's stuff' quota for the year?
<czajkowski> timrc: most odd but tis working now, it stopped last UK time yesterday and was fixed early UK time today
* frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: rick_h | Firefighting: - | Critical bugs: ~160
<timrc> czajkowski, do you have an LP bug # handy by any chance?
<czajkowski> timrc: we didnt log a bug this morning we just reverted the patch
<czajkowski> what are you trying to do timrc ?
 * czajkowski is also attempting to run out the door as past EOD but just so I can point you in the right direction
<timrc> czajkowski, I'm trying to document what went wrong in our bug for the users affected by the regression
<czajkowski> timrc: hmm there may be some confusion then, I assumed rick_h_ was referring to your oops which was like this mornings, where people could not create projects
<czajkowski> what is your current issue
<timrc> czajkowski, no, I think we're talking about the same thing... a user logged a bug saying as much and I wanted to respond with details of the problem... but if there was no bug filed against LP, that's fine
<rick_h_> timrc: so it was a deploy that had a bug and was reverted.
<rick_h_> there wasn't a bug file and the deploy is getting re-tested and worked on before being attempted again.
<timrc> rick_h_, thanks
<sinzui> wgrant, StevenK, can you one you look at the pastebin in the last comment: https://bugs.launchpad.net/launchpad/+bug/1077351
<_mup_> Bug #1077351: SourcePackageRecipeBuild:+index LocationError build <oops> <recipe> <soyuz-build> <Launchpad itself:In Progress by sinzui> < https://launchpad.net/bugs/1077351 >
<StevenK> wgrant: http://pastebin.ubuntu.com/1426332/
<StevenK> wgrant, sinzui: http://www.youtube.com/watch?v=BgAlQuqzl8o
<wgrant> StevenK: http://pastebin.ubuntu.com/1426362/
<wgrant> I didn't fix the indentation, but the code is right
<StevenK> wgrant: TypeError: Expected unicode, found <type 'str'>: '{'
<StevenK> wgrant: I guess I need to cast back to text[], I'm just not sure where
<StevenK> wgrant: SELECT array_agg(..)::text[] FROM (... at a guess?
<mwhudson> and i thought i abused postgres as a hobby
#launchpad-dev 2012-12-12
<StevenK> mwhudson: Haha
<wgrant> StevenK: Ah, yes, you'll need the cast
<StevenK> wgrant: Yeah, it's working
<StevenK> Turns out my guess was right
<wgrant> mwhudson: This isn't particularly great
<wgrant> evil
<wgrant> I've done much worse :)
<mwhudson> i'm sure
<mwhudson> wgrant: did i show you http://voices.canonical.com/michael.hudson/2012/09/02/using-postgres-array_agg-from-django/ ?
<wgrant> I might need popcorn
<wgrant> Hah
<wgrant> So not too hacky
<mwhudson> the bit with decimalfield was pretty awful
<mwhudson> but otherwise, no
<wgrant> Yeah
<StevenK> aggregate.field = DecimalField() # vomit
<StevenK> Haha
<mwhudson> how did lp upgrade from postgres 8 to 9?
<mwhudson> can you slony between 8 and 9?
<StevenK> We dropped slony too
<mwhudson> yes
<mwhudson> but that was afterwards :-)
<StevenK> During, in fact
<wgrant> mwhudson: That's like saying Ubuntu 10 and Ubuntu 11 :)
<mwhudson> hm
<mwhudson> wgrant: heh well
<wgrant> We upgraded 8.4 to 9.1 with Slony
<wgrant> Then dropped slony for our internal replication
<wgrant> We will use slony again for the 9.1 -> 9.2 upgrade
<wgrant> Then drop it immediately afterwards
<mwhudson> so you had a pg 8.4 master talking to a 9.1 slave, then rotated the 9.1 slave to be the master?
<wgrant> Right
<mwhudson> ok
 * mwhudson finally read http://www.postgresql.org/docs/9.1/static/pgupgrade.html properly and didn't like it much
<wgrant> If your system can go down for a while, it's better to just pg_upgrade during a bit of downtime
<mwhudson> heh
<StevenK> I recall the master pivot being a little messy, but we worked out the issues with it and the second pivot back was cleaner
<wgrant> IIRC we pg_upgraded the slaves
<wgrant> StevenK: That was with native replication around the move -- unrelated.
<wgrant> mwhudson: So, if you can tolerate downtime and your DB is small then just pg_upgrade
<wgrant> And be done :)
<mwhudson> i guess i should figure out how pg_upgrade works properly
<mwhudson> wgrant: yeah
<wgrant> There are occasionally caveats, but it's usually the best way
<wgrant> If the 9.2 pg_upgrade is fast enough we might even just go RO for a couple of minutes and avoid slony entirely
<mwhudson> i'm a little confused about clusters i guess
<StevenK> wgrant: With pivoting or without?
<mwhudson> will pg_upgrade try to destroy my existing 9.1/main cluster?
<wgrant> mwhudson: It has two modes: copy and hardlink
<wgrant> The latter will destroy the original cluster
<wgrant> Copy will create a copy, which is probably OK unless your DB is LP-sized
<mwhudson> wgrant: sure, i get that bit
<mwhudson> wgrant: where will it put the copy though?
<mwhudson> or do i get to decide that?
<mwhudson> the db is small enough that i download copies of it for development ...
<wgrant> IIRC you specify the source and target paths
<wgrant> It doesn't manage the clusters itself
<wgrant> Yeah
<mwhudson> ah yeah
<wgrant> You create the new cluster and then use pg_upgrade to replace its data
<StevenK> mwhudson: I have dreams about database's that small
<mwhudson> argh
<mwhudson> pg_upgrade is packaged as part of postgres-xc apparently
<mwhudson> but postgres-xc appears to install its own version of everything
<mwhudson> mwhudson@narsil:non-default-database$ sudo -u postgres initdb -D /var/lib/postgresql/9.1/upgrade
<mwhudson> initdb: Postgres-XC node name is mandatory
<StevenK> pg_upgradecluster ?
<StevenK> mwhudson: /usr/lib/postgresql/9.1/bin/pg_upgrade
<wgrant> pg_upgradecluster is a Debian wrapper in PATH
<wgrant> /usr/lib/postgresql/9.1/bin/pg_upgrade is the real binary
<mwhudson> ahh
<mwhudson> oh ffs
<mwhudson> now postgres-xc's maintainer scripts are failing and not letting me do anything
<wgrant> Hee hee
<lifeless> mwhudson: you're running clustered ?
<StevenK> mwhudson: sudo vi  and 'exit 0' ?
 * mwhudson should probably not have been allowed sudo today
<mwhudson> StevenK: that's what i'm thinking
<StevenK> Hahaha
<mwhudson> well this was a little adventure i wasn't in the mood for
<lifeless> mwhudson: how well does postgres-xc work?
<mwhudson> lifeless: installing it appears to mess everything up completely
<mwhudson> and haha of course postgres-8.4 isn't installable in quantal ;-)
<lifeless> mwhudson: lxc ftw
<mwhudson> yeah
<mwhudson> There were problems executing "/usr/lib/postgresql/8.4/bin/pg_ctl" -w -l "/dev/null" -D "/var/lib/postgresql/8.4/main"  stop >> "/dev/null" 2>&1
<mwhudson> Failure, exiting
<mwhudson> :(
<wgrant> :(
<mwhudson> particularly nice to pipe any error messages away
<mwhudson> oh
<lifeless> spethial
<mwhudson> turns out -l fixes the errors go away problem
<mwhudson> now i think it's that ubuntu puts the config not in the cluster but rather in /etc
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/populate-searchables-for-pu/+merge/138906 is ready for another look
<StevenK> wgrant: And https://code.launchpad.net/~stevenk/launchpad/squash-archivesubscriptionerror/+merge/139382
<wgrant> StevenK: What does set_archive_and_user do that can't be achieved by setting archive and user?
<StevenK> wgrant: I can't set self.user directly
<wgrant> You don't set self.user at all, because that's the request user
<wgrant> But can't you set self.current_user directly?
<wgrant> The helper seems pointless
<wgrant> Also, I'd perhaps say context_user
<StevenK> wgrant: If I try and set self.user = ... in the view, I get horrible errors
<wgrant> Sure
<wgrant> self.user is special
<wgrant> You shouldn't be setting it
<wgrant> Also, self.archive is a bit odd, as it's reasonable for some other view to use that name
<wgrant> Perhaps sources_list_archive and sources_list_user?
<wgrant> Also, on line 101 of that diff you use the request user's displayname, but the context user's name
<StevenK> Oh, hah, I missed one
<StevenK> wgrant: http://pastebin.ubuntu.com/1426820/
<wgrant> context_archive and context_user are still sort of overly generic for a very specific widget
<StevenK> You suck, and I hate you.
<wgrant> Oh, it already used self.archive?
<wgrant> current_user needs to change, but if it's already using self.archive then it's probably safest not to change that
<wgrant> Because current_user is precisely not the current user :)
<StevenK> wgrant: http://pastebin.ubuntu.com/1426826/
<wgrant> Much clearer :)
<StevenK> And less buggy, too boot
<wgrant> StevenK: I still don't see any value in set_archive_and_user over setting the archive and user
<wgrant> And the Nones might as well be defined in the class definition, rather than __init__
<StevenK> Oh, I can do that in the views if you wish
<StevenK> wgrant: http://pastebin.ubuntu.com/1426839/
<StevenK> Sorry, I didn't realise you were still pushing back
<wgrant> Great
<lifeless> what is he, a plane?
<StevenK> wgrant: Diff updated
<StevenK> wgrant: I wonder if we can forbid import cgi in the fascist
<wgrant> cgi.parse_qs and friends are still useful
<wgrant> And there's only one callsite of cgi.escape left in the entire tree
<wgrant> So there's no bad examples left for anybody to copy
<StevenK> \o/
<wgrant> So I doubt any more will sneak in
* wgrant changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: - | Firefighting: - | Critical bugs: ~150
<StevenK> wgrant: You fail at buildbot bingo again.
<StevenK> wgrant: I thought sets were sorted?
<StevenK> wgrant: And there is no normal add mechanism for PCJ'd PU's.
<wgrant> StevenK: sets aren't sorted
<wgrant> StevenK: That function isn't just used for PCJs
<wgrant> It's used to create all PUs
<StevenK> >>> set(['b']) | set (['a'])
<StevenK> set(['a', 'b'])
<StevenK> >>> set(['c', 'd', 'b']) | set (['a'])
<StevenK> set(['a', 'c', 'b', 'd'])
<StevenK> Even
<StevenK> wgrant: Right, but there isn't a addPCJ method on PU
<StevenK> Either we have one, or we don't.
<StevenK> I can call setSearchable* in the constructor if package_copy_job
<wgrant> StevenK: Oh, I meant that you should call addSearchable*, yes
<wgrant> Not addPCJ
<StevenK> wgrant: In PU's constructor?
<wgrant> >>> list(set(['foo', 'bar', 'baz']))
<wgrant> ['baz', 'foo', 'bar']
<wgrant> Yes
<StevenK> Hmmm
<StevenK> I will add sorted()
<wgrant> sets are by definition unordered
<lifeless> they have a sort order. Its the internal datastructure iteration order
<lifeless> which is effectively random
<StevenK> wgrant: appendSearchable*? Since that's what it does.
<wgrant> Sure
<lifeless> in that you can't depend on it, in any regard
<wgrant> But it's undefined
<wgrant> So they're unordered :)
<wgrant> StevenK: It doesn't strictly append, but the order doesn't matter. So I'd say add
<wgrant> cjwatson: Do you want to retract https://code.launchpad.net/~cjwatson/launchpad/queue-filter-source/+merge/119225 now that we have a less disastrously unperformant solution?
<StevenK> wgrant: PackageUpload has no __init__
<StevenK> And I don't want to step on SQLBase's toes
<wgrant> There's no __init__, no
<wgrant> But there is a factory method somewhere
<wgrant> That you edited in that branch already
<StevenK> That doesn't help code that creates PCJs
<wgrant> I am confused
<wgrant> What doesn't work for what and why?
<StevenK> wgrant: A PCJ may not require a PU. If it does, it calls createQueueEntry(). The factory methods for creating a PCJ don't touch that bit of the code, they have the job system do it
<StevenK> And I'm not sure how I can call addSearchables* if there is no __init__, and no add{Source,Build,Custom} variant.
<wgrant> Why not?
<wgrant> The method on DistroSeries creates the PackageUpload and returns it
<wgrant> It can, between creating and returning it, call addSearchable*
<StevenK> Oooh
<wgrant> Or the __init__ could, if you want to define an __init__
<wgrant> (it's not uncommon to define an __init__ that just passes through the args and kwargs to super, then performs some operations afterwards)
<StevenK> wgrant: http://pastebin.ubuntu.com/1426974/
<wgrant> StevenK: And now you can add a comment to __init__ about how they get added for other cases :)
<wgrant> Also, consider how this is going to work when the two columns are NOT NULL
<StevenK> They can not be.
<wgrant> You'll need to have a sensible default, and you might as well arrange that now
<wgrant> Why not?
<wgrant> They have logical defaults: '' and []
<StevenK> Ah
<StevenK> wgrant: http://pastebin.ubuntu.com/1426981/
<wgrant> That's wgrant Compliantâ¢
<mwhudson> wgrant: in other wtf news, pg_upgradecluster appears to use pg_dump/pg_restore under the hood, not pg_upgrade
 * mwhudson fumes
<mwhudson> ah
<mwhudson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682938
<cjwatson> wgrant: Sure, retracted now
<cjwatson> and reassigned the bug to StevenK
<StevenK> Just need to wait for my DB patch. And fix my test failures. And then wait for the garbo job to populate on all four instances ...
<StevenK> And then two more DB patches. :-(
<czajkowski> is that all :)
<StevenK> czajkowski: Nope. Then I have to land the branch that makes uses of the new columns.
<sinzui> ha. keyboard navigation is broken in the bugs subscriptions widget because it stomps on the content of it's overlay widget.
<sinzui> Now the question is, can I fix this without spending a 2 days remaking it as a true widget.
 * rick_h_ sends sinzui lots of luck
<sinzui> This module is a crime
<rick_h_> yea, my general rule in JS stuff is rewrite first ask questions later
<timrc> Is there a way to correlate a build with package_upload? I'm trying to see if I can calculate various wait time statistics between upload and build for our ppas
<StevenK> A PackageUpload may link to a build, a source or a custom upload. I'm not certain if the property is exported.
<sinzui> StevenK, can you triage this: https://bugs.launchpad.net/launchpad/+bug/1089615
<_mup_> Bug #1089615: Source builds fail for packages with "3.0 (quilt)" format and unapplied patches <Launchpad itself:New> < https://launchpad.net/bugs/1089615 >
#launchpad-dev 2012-12-13
<timrc> It is possible to get the Ubuntu series from the build record? I don't see an obvious way to do it :(
<wgrant> Indeed, apparently the distroarchseries attribute is not exported
<timrc> doh
<timrc> current_source_publication.distro_series I think could work
<StevenK> wgrant: This reached out and slapped me yesterday evening:
<StevenK>      def test_displayarchs_for_copy_job_is_sync(self):
<StevenK> -        # For copy jobs, displayarchs is "source."
<StevenK> +        # For copy jobs, displayarchs is "sync."
<StevenK> wgrant: Can triage https://bugs.launchpad.net/launchpad/+bug/1089615 , by the way?
<_mup_> Bug #1089615: Source builds fail for packages with "3.0 (quilt)" format and unapplied patches <Launchpad itself:New> < https://launchpad.net/bugs/1089615 >
<wgrant> StevenK: https://rt.admin.canonical.com/Ticket/Display.html?id=46345 will hopefully fix that
<StevenK> wgrant: How are bzr-builder and 3.0 (quilt) related?
<timrc> Hm, is the "Date finished" part of the description for 'date_first_dispatched' a copy-paste error? (see, https://launchpad.net/+apidoc/devel.html#build)
<wgrant> StevenK: Because that's an SPRB
<wgrant> SO it uses bzr-builder
<wgrant> timrc: Yes
<timrc> wgrant, Thanks... one last question... does the time between 'datecreated' and 'date_first_dispatched' represent the time the build spends waiting to build?
<wgrant> timrc: Usually, yes. But for private PPAs it will also include the publication latency, as the build will not be dispatched until its source is published
<timrc> or would it be more accurate to use the package_upload.date_created timestamp inconjunction with 'date_first_dispatched'?
<timrc> ah, that's a useful bit of info
<wgrant> The source package_upload.date_created and build.datecreated should usually be identical for PPA packages
<timrc> wgrant, Okay, thanks
<StevenK> wgrant: http://pastebin.ubuntu.com/1428915/
<StevenK> wgrant: Have you seen buildbot's waterfall? It looked like it lost its mind
<wgrant> StevenK: What was wrong with it?
<wgrant> prasÃ© had some disk issues and was offline for a while overnight
<StevenK> wgrant: The pastebin? I don't like the line "+        if kind in ([], [u'']):"
<wgrant> I was speaking of the waterfall
<wgrant> Looking at the diff now
<StevenK> Ah
<wgrant> Why does that line exist?
<wgrant> It should never be called with an empty string
<StevenK> Because u''.split(' ') == [u''] :-(
<wgrant> Ah, right
<StevenK> wgrant: Yes, it was masking a bug
<wgrant> kind has to be the worst name ever
<StevenK> If I don't split and we call addBuild() twice, then searchable_names becomes 'a c f g h j newname'
<StevenK> wgrant: s/kind/existing/ ?
<wgrant> Yes
<wgrant> So, you would perhaps do well to simply exclude elements that evaluate to False
<StevenK> [u''] != False
<StevenK> >>> u'' == False
<StevenK> False
<wgrant> This isn't JavaScript or PHP
<wgrant> By "evaluate to" I mean in the context of a boolean expression
<wgrant> ie. an if statement or clause of a list comprehension
<StevenK> >>> bool(u'')
<StevenK> False
<wgrant> Yes
<StevenK> Hmmm, can't we that using filter() or map() ?
<wgrant> If you want, but I'd just say [x for x in existing if x]
<wgrant> Mostly because Guido hates lambdas
<StevenK> Construct a list from those elements of iterable for which function returns true. iterable may be either a sequence, a container which supports iteration, or an iterator. If iterable is a string or a tuple, the result also has that type; otherwise it is always a list. If function is None, the identity function is assumed, that is, all elements of iterable that are false are removed.
<StevenK> filter(None, ...)
<wgrant> Oh, didn't know about that special case
<wgrant> How hideous
<StevenK> Does that mean I can't use it? :-)
<wgrant> You can
<StevenK>     def _appendSearchables(self, existing, new):
<StevenK>         return sorted(filter(None, set(existing) | set(new)))
<StevenK> BUILDBOT
<StevenK> wgrant: Or is that function now hideous? :-)
<wgrant> That's fine
<nigelb> What's the link for the LXC setup?
<nigelb> Ah, nvm. Found it.
<StevenK> nigelb: apt-get install lpsetup ; lp-setup install-lxc or so
<nigelb> oh
<nigelb> that's all?
<lifeless> nigelb: not quite
<lifeless> nigelb: need to add the lp ppa first I think
<nigelb> oh right.
<nigelb> but I was in the middle of doing it the all fashioned way from the LXC page.
<wgrant> I use lp-setup on my laptop. It seems to work.
<nigelb> should I stop that and do this? or does lp-setup accomplish the same thing?
<wgrant> They're pretty much equivalent
<wgrant> lp-setup just sets things up slightly unconventionally and in a more automated fashion
<wgrant> The instructions on Running/LXC are what I use on my main dev machine, so I know they work fine :)
<nigelb> ok :)
<StevenK> wgrant: Hmm, I am stupid and thought contains_string for searchable_versions would work :-(
<wgrant> Oh
<wgrant> You landed a DB patch without working out whether you could actually use it? :)
<StevenK> Surely postgres has a function for that
<StevenK> And then we SQL() in it
<wgrant> 'foover' = ANY(searchable_versions) with a GIN index should work, but testing now
<wgrant> Nope, the ANY doesn't get indexed
<wgrant> SELECT * FROM packageupload WHERE ARRAY['1.2.3'] <@ searchable_versions;
<wgrant> works, though
<wgrant> (the index now exists on DF)
<StevenK> And no tgrm
<wgrant> The trgm index has been building for a few minutes
<wgrant> Must be nearly done
<wgrant> There we are
<wgrant> As expected the queries aren't exactly fast, but it's better than what we have now
 * wgrant tries a composite
<nigelb> The LXC is lucid.
<StevenK> Intended behaviour
<wgrant> Hopefully only for another month or so, though :)
<nigelb> woo.
<nigelb> So, I have python-virtualenv and virtualenv wrapper.
<nigelb> They aren't in Lucid yet :)
<nigelb> Oh, I still need to let launchpad take over my machine. just that it'll be the LXC that it'll take over.
<wgrant> Right
<wgrant> Hmm
<wgrant> I wonder how big the biggest queue is
<wgrant> Oh, <200k items
<wgrant> So it may not be worth indexing either of the search columns at all
<wgrant> Although the table won't be hot
<StevenK> wgrant: Oh?
<wgrant> Oh
<wgrant> The tsearch2 prefix matching stuff from years ago actually got merged
 * wgrant experiments
<wgrant> So we may be able to ts2 this nicely rather than having to hack up a custom GIN operator
<wgrant> (this is a shortcut that will let us quickly do prefix matching on each name, which is probably roughly as useful as the current exact_match behaviour, but much much faster)
<StevenK> Neat
<wgrant> (GIN indices are basically just btree indices which know how to do stuff like split an array up into multiple keys, so they can obviously internally be used for prefix searching on keys. But utilising that functionality through SQL can be a problem, and you sometimes have to end up defining your own GIN operator classes.)
<StevenK> wgrant: So, do we want to deploy?
<StevenK> It will drop us below 150 total criticals
<wgrant> Is the db-stable merge through?
<wgrant> Should be by now, I guess
<StevenK> Yeah, it is
<wgrant>  Total runtime: 55.598 ms
<wgrant> But does it actually work...
<wgrant> Yes
<wgrant> Well that makes things easy
<wgrant> As long as cjwatson agrees we can live with just prefix matching on each name, rather than full substring matching
<StevenK> wgrant: I have a deployment request ready, if you have no objections?
<wgrant> StevenK: doit
<wgrant> Oh
<wgrant> It was only added in 8.4
<wgrant> So I don't have to feel like a complete idiot :)
<wgrant> StevenK: SELECT * FROM packageupload WHERE (to_tsvector('simple', searchable_names) @@ to_tsquery('simple', 'ubiquity:*')) AND distroseries = 103 AND archive IN (1, 534) AND status = 3;
<wgrant> Is a prefix match on ubiquity
<wgrant> Drop the :* for exact match
<StevenK> Hmmm
<StevenK> Neat
<wgrant> (the 'simple' makes lexeme conversion a no-op, so no stemming and such)
<wgrant> Are the columns fully populated on DF?
<StevenK> No
<wgrant> :(
<wgrant> Still, this should be rather fast
<StevenK> I think some of the customs probably have NULL versions
<wgrant> Ah
<wgrant> But the names should be populated?
<StevenK> Not fully
<wgrant> :(
<StevenK> ~ half the table is done
<StevenK> I was planning to sorched earth the two of them and start it again
<StevenK> *scorched
<StevenK> And probably hack out the timeout
<wgrant> I think a composite index might be more successful here
<wgrant> Trying
<wgrant> (prefixing the trigram index with (archive, distroseries) was not effective, simply because the index has so many entries)
<wgrant> Hm, no, doesn't work
<wgrant> How odd
<wgrant> Still, fast enough without it :)
<StevenK> Using ts2?
<wgrant> Yes
<wgrant>     "temp_pu5" gin (to_tsvector('simple'::text, searchable_names))
<StevenK> And just GIN on searchable_versions?
<wgrant> Yeah
<wgrant>     "temp_pu" gin (searchable_versions)
<wgrant> Its selectivity estimates are even pretty good
<wgrant> http://paste.ubuntu.com/1429076/
<StevenK> rows=0, though?
<wgrant> BitmapAnd nodes lie sometimes
<wgrant> Look at the end of the plan
<wgrant>  Bitmap Heap Scan on packageupload  (cost=1062.97..1424.58 rows=4 width=135) (actual time=5.810..5.835 rows=7 loops=1)
<wgrant> rows=7
<StevenK> Yeah
<StevenK> That looks pretty awesome
<StevenK> exact match drops it to 3.3ms
<wgrant> Well, yeah
<wgrant> Once you include a version match it's going to be pretty much trivial
<wgrant> A long enough search string on a trigram index can take a couple of seconds, but I'd be surprised if this ever exceeded 100ms
<StevenK> wgrant: So shall I scorched earth searchable_* and garbo them up?
<StevenK> Which I think requires the indicies die
<wgrant> These indices shouldn't have a huge impact on performance, but it's probably still worth it to nuke them
<wgrant> garbo performance, that is
<wgrant> They only take about 5 minutes to regen afterwards, so feel free to delete temp_*
<StevenK> wgrant: I was going to DROP COLUMN/ADD COLUMN because it's MUCH faster
<wgrant> Ah, right
<wgrant> k
<wgrant> Hmm
<wgrant> We may actually want to skip to_tsquery and to_tsvector at this point
<wgrant> And instead just cast directly to tsquery and tsvector
<wgrant> Since we don't eg. want to separate lexemes by -
<StevenK> 2012-12-13 05:48:20 DEBUG2  [PopulatePackageUploadSearchables] Iteration 4 (size 26.8): 0.658 seconds
<wgrant> Hopefully it'll accelerate...
<StevenK> It will, it just takes a while
<wgrant> Just be glad we're no longer doing that inline in searches :)
<StevenK> Haha
<wgrant> StevenK: Hm, it seems to be pretty slow
<wgrant> Only 15k done
<StevenK> Yeah
<StevenK> If last run is anything to go by, the first 800 iterations are very slow
<StevenK> Then it speeds up massively
<wgrant> O_o
<StevenK> 2012-12-13 06:04:04 DEBUG2  [PopulatePackageUploadSearchables] Iteration 264 (size 144.6): 4.541 seconds
<wgrant> Hm
<wgrant> Still surprisingly awful
<wgrant> But I guess it'll get there ventually.
<wgrant> Only 4.6 million to go
<wgrant> StevenK: Oh
<StevenK> Oh?
<wgrant> Should be faster now
<wgrant> By a factor of several
<wgrant> Can you confirm?
<StevenK> Indeed, it just sped up
<StevenK> 2012-12-13 06:18:37 DEBUG2  [PopulatePackageUploadSearchables] Iteration 523 (size 1284.2): 4.860 seconds
<wgrant> Lovely
<wgrant> That's more like it
<StevenK> And you did what?
<wgrant> Magic
<wgrant> aka. ANALYZE
<StevenK> ANALYZE packageupload ?
<wgrant> The stats for the nullness of searchable_* were bad
<wgrant> Yes
<StevenK> Oh
<StevenK> Right
<wgrant> So it was doing a seqscan to find them
<StevenK> Because I've been bad
<wgrant> Rather than an index scan on id
<wgrant> Right, that's a little bit faster
<StevenK> Right. Happily, that will affect us not at all on prod.
<wgrant> Um
<wgrant> It might
<wgrant> But a vacuum would probably have fixed it in an hour or so anyway
<StevenK> If we deploy 40-1 tonight, the earliest the garbo job will hit prod is tomorrow morning
<wgrant> Sure
 * StevenK waits for staging to finish building
* StevenK changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: - | Firefighting: - | Critical bugs: <150
<cjwatson> wgrant: hmm.  I've definitely used full non-prefix substring matching in the not too distant past.  I'm not certain whether all of those were purely workarounds for lack of SPN.
<wgrant> I can't think of many circumstances in which it would actually be useful, assuming all the names are searchable
<cjwatson> Mostly surprising because all other non-exact matches in LP (AFAIK) are substring, not prefix
<wgrant> There aren't very many non-exact matches in LP
<wgrant> (and most of those that do exist should not :))
<wgrant> There's no real use-case for getPublishedSources(exact_match=False), for example
<wgrant> Full substring matches are extremely expensive
<cjwatson> So, we'd have to document it, and it's a tad surprising, but we can live without full substring matches given the other improvements
<wgrant> Mmm
<wgrant> It's not really surprising
<wgrant> Only because people didn't think at all before introducing substring matching in the first place
<cjwatson> It's potentially surprising to people who've been using it
<cjwatson> Which I don't think is often, but now and again
<wgrant> Right
<cjwatson> Mostly in "oh, I need to reject these three packages and they happen to be the only ones containing 'splotnib'" kinds of ways, probably
<wgrant> Hopefully everyone will now ask themselves "is this is any way not stupid" when designing their next webservice API :)
<wgrant> 'cause in any database context, substring matching is pretty much entirely impractical and not all that useful :(
<wgrant> I dream that one day the argument can be removed from getPublishedSources and getPublishedBinaries, perhaps letting those API methods actually be possibly sustainable.
<jtv> jam: got a moment for a maas-hardware-db question?
<jtv> Want to know how you pull the lshw output out of the maas database.  Is it all in the maas codebase, or do you have something else somewhere?
<jtv> Oh, is it the special case for "01-lshw" that's in the metadataserver api.py?
<jtv> allenap: think I found the answer to your question ^  :)
<jtv> It's in the diff.
<allenap> jtv: Ta!
<mgz> jtv: it's in maas, basically there's an api for getting the lshw output, which exists as the db is on the region controller but we want the cluster controllers to do the work
<jtv> mgz: I guess it's the bit in the metadata API then, where the node calls "signal" and the API has a special-case check for "is the name of the file 01-lshw.out?"
<mgz> that's for putting it *into* the db
<jtv> We may be talking about different "the" dbs.
 * jtv resists the temptation to get pedantic about the definition of Database
<jtv> (Would have been a cheap dig at mongo)
<timrc> sinzui, Hi, out of curiosity, do proprietary and embargoed projects hide membership details now as well?
<sinzui> timrc, team are not proprietary/embargoed
<sinzui> timrc, if you mean Private teams, no one can see them by default, if they are placed in a  public relationship like a bug subscription, only the Launchpad id, name, and icons are revealed
<sinzui> so members are never shown to non-private-team-members
<timrc> sinzui, ok
<timrc> sinzui, so if a project is set to proprietary or embargoed and the client attempting to access it is not authenticated or authorized will it 404?
<sinzui> It will 404...it does not exist to non-shared users
<timrc> sinzui, good to know, that's what I'd expect
* jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: jcsackett | Firefighting: - | Critical bugs: <150
* jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: - | Firefighting: - | Critical bugs: <150
<sinzui> oh sweet, Lp will call focus() on <input type="hidden"/>
<jml> sinzui: :D
<timrc> It's known (or maybe it isn't) that our use of PPAs is a little unorthodox.  Specifically we really only use them to build packages.  When the package is built and published, it gets funneled into another repository which in turn is used to build Ubuntu images.
<timrc> One architectural problem with this design is that a user has the ability to upload or copy-rebuild the same package in multiple PPAs.  If they do this, it will cause a package collision "downstream", as the archive they're going to has a shared pool, and so only one copy of the package can exist there.
<timrc> What would be nice, for us, at least, is if we could at least disable copy-rebuild.  That does not completely solve the problem, but it solves the most common cause for us.
<timrc> Does anyone have outright objections to doing this?
<lifeless> sinzui: radical honesty in bugs? zomg :)
<sinzui> yes. the number is true
<lifeless> sinzui: oh, I know. I'm just waiting for the slashdot now :)
<sinzui> I doubt the 90 days remaining to get the list to zero though. Maybe I am too pessimistic. I fixed 7 last week, so there are still 1-day bug fixes
<timrc> sinzui, So, we have Bug sharing policy set to "Proprietary, can be public" for a project and they want to use 'also effect another project' option but can't... this seems odd if the bugs are configured to share the same way for both projects... what am I missing?
<timrc> hm actually the other project has the Bug sharing policy as "Proprietary" not "Proprietary, can be public"
<sinzui> timrc, I think you found the problem
<timrc> sinzui, thanks and sorry for disturbing ya :)
<maxb> timrc: Re your PPA thing above.... surely this comes down to ensuring the users understand the tools?
<timrc> maxb, you'd think
<timrc> maxb, it's been an on going problem for us for the last 2 years... it turns out people don't like to read documentation and / or periodic PSA's on our lists are not enough
<timrc> it is sort of a weird thing to consider when using a PPA, so I don't exactly blame people for doing it... also the default is to rebuild, so the opportunity for human error is greater
<maxb> Copying packages between PPAs isn't usually something novice packagers do - what's different about your workflow that makes it more likely that people do it without the experience to understand the consequences?
<maxb> (Though I do agree that the default is probably the wrong way around)
<sinzui> wgrant, StevenK, Do you want to deal with this: https://answers.launchpad.net/launchpad/+question/216665
<StevenK> wgrant: SELECT regexp_matches(json_data, 'package_version": "([^"]+)') FROM packagecopyjob;
<StevenK> SELECT regexp_matches(json_data, 'package_version": "([^"]+)"') FROM packagecopyjob;
<StevenK> Now we can scare wallyworld_
<StevenK> SELECT regexp_matches(json_data, '"package_version": "([^"]+)"') FROM packagecopyjob;
<wallyworld_> i'm not scared yet
<StevenK> wallyworld_: regex matches on a JSON field in a SQL statement? :-)
<wallyworld_> is regexp matching new?
<StevenK> Nope
<StevenK> Was around in 8.3, at least
<wallyworld_> does lp use it much?
<StevenK> Not at all, I think.
<wallyworld_> but it does now :-)
<StevenK> For a short time. That is going into a garbo job.
<wgrant> SELECT (regexp_matches(json_data, '"package_version": "([^"]+)"')::debversion[])[1] FROM packagecopyjob;
<wgrant> StevenK: Indices done
<wgrant> EXPLAIN ANALYZE SELECT * FROM packageupload WHERE (searchable_names::tsvector @@ 'ubiquity:*') AND distroseries = 103 AND archive = 1 AND status = 3 AND searchable_versions @> ARRAY['2.1.0'];
#launchpad-dev 2012-12-14
 * StevenK stabs sampledata
<StevenK> I guess my testfix is to run the garbo job against sampledata
<wgrant> Indeed
<wgrant> Also, i'm not sure we can actually optimise the SET NOT NULLs
<wgrant> postgres is a bit stupid
<StevenK> :-(
<wgrant> It doesn't actually use indices at all
<StevenK> Wow
<wgrant> When you add a new NOT NULL constraint to a table, it goes through every tuple and verifies that every NOT NULL constraint is satisfied
<StevenK> We can probably do it in two patches
<StevenK> But it will still make those two FDTs 5 seconds long
<wgrant> Nah, best to do it in one patch
<wgrant> One statement can alter two columns.
<wgrant> So we can do both in two seconds
<wgrant> (on DF)
<StevenK> Oh
<StevenK> It's just a comma?
<wgrant> Right
<wgrant> launchpad_dogfood=# ALTER TABLE packageupload ALTER COLUMN searchable_names SET NOT NULL, ALTER COLUMN searchable_versions SET NOT NULL;
<wgrant> ALTER TABLE
<wgrant> Time: 2210.737 ms
<wgrant> (or we could just manually set attnotnull, I guess :))
<wgrant> That's probably not too evil
<StevenK> Hahaha
<wgrant> I'm serious
<wgrant> It's a reasonable thing to do
<StevenK> That won't check each tuple?
<wgrant> No
<wgrant> Huh, in fact, manually setting attnotnull was the only way back in 7.0
<StevenK> Heh
<wgrant> Yeah, that would work fine, looking at the code and some tests. But that would want to wait until stub is back :)
<StevenK> Does attnotnull take a full table lock?
<StevenK> Right, so my sampledata changes do fix that test
<wgrant> That was the only failure?
<StevenK> And one whole container failed to come up, it seems
<StevenK> Maybe not, given the count
<StevenK> One 'Launchpad failed to start in 60 attempts' old chestnut
<wgrant> One could set attnotnull without taking a full table lock, given that we know the data is good, but that seems a bit evil. ALTER TABLE ... ALTER COLUMN ... SET NOT NULL takes a full access exclusive lock to avoid any null tuples being inserted under its nose, and also to avoid any potential plan changes on other mid-flight queries, but neither is relevant here.
<StevenK> Indeed
<StevenK> The columns won't be created NULL, and nothing else is reading it
<wgrant> But we could probably just pay the 2s
<StevenK> Well, Storm will be, but it won't be paying attention
<StevenK> wgrant: And yes, only one failure
<StevenK> wgrant: Self-review? It runs the garbo job against dev,test-playground
<StevenK>  2 files changed, 30 insertions(+), 30 deletions(-)
<wgrant> Fine
<StevenK> Right, testfix landed
 * StevenK stabs buildbot
<StevenK> wgrant: I wonder if postgres isn't using indicies because they can be out of date. Is that completly wrong, and it should use indicies if they exist?
<wgrant> Given an access exclusive lock as it takes now, an index should be usable.
<StevenK> So it's arguably a bug that it won't check an index?
<wgrant> Not a bug.
<wgrant> A potential future optimisation.
<StevenK> Which may get filed as a bug ... :-)
<StevenK> Buildbot is finally done
<StevenK> Now to wait for qas to update
<sinzui> jcsackett, rick_h_, do either you you have time to look at my WCAG fix for  the structural subscription widget: https://code.launchpad.net/~sinzui/launchpad/bugs-subscriptons-wcag-love/+merge/139812
<jcsackett> sinzui: i can look.
<jcsackett> sinzui: r=me. and bonus points for using OMG in the cover letter. :-)
<sinzui> thank you
<timrc> sinzui, if I change the bug sharing policy, it only applies to new bugs... it won't retroactively apply to existing bugs?
<sinzui> correct
<sinzui> timrc, I have a script that walks over all bugs and branches and tries to change the into type. Would you like a copy in cases where you do want to change them all?
<timrc> sinzui, sure, I'd be interested in that script
<timrc> I think we have people going rogue and screwing around with their sharing policies... do you have a script that slaps people too? :)
<timrc> sinzui, OK, I think I see the error of my ways.  So when I create a bug in a project with a proprietary bug sharing policy, the new bug defaults to proprietary.  To make it sharable between projects it has to be changed to private...
<sinzui> yes. Someone needs to vet the information to be certain the bug can be shared with another project how can also choose to make it public
<sinzui> timrc, as for slapping user who screw up the policies, I am open to suggestion for punishment so long as it is equal to the burden they inflict upon others...
<sinzui> I still see people not sharing with ~canonical, so we are locked out and we need to stop work and fix the project.
#launchpad-dev 2012-12-16
<cjohnston> is "Error: unable to find the ip address of the LXC container" the same as bug #1019181
<_mup_> Bug #1019181: lpsetup expects lp-lxc-ip to be in /usr/bin; setup.py install it in /usr/local/bin <lpsetup:In Progress by gmb> < https://launchpad.net/bugs/1019181 >
<rick_h_> cjohnston: not sure. what are you doing/running to get the error about the ip address?
<cjohnston> rick_h_: I installed lpsetup, then the very first commandthat you run
<cjohnston> I'm onmy phone now so I don't engender what it was
<cjohnston> I an lp-setup install-lxc
<cjohnston> s/an/ran
<StevenK> Hmmmm, \d output lies.
<StevenK> psycopg2.ProgrammingError: syntax error at or near "::"
<StevenK> LINE 10:     USING gin (searchable_names::tsvector)
<wgrant> Indeed
<wgrant> You need an extra set of parens
<wgrant> IIRC
<StevenK> Not to mention a ';'
<StevenK> wgrant: http://pastebin.ubuntu.com/1444243/
<wgrant> wtf comments
<StevenK> wgrant: They will die, they're still hanging around in case I need them
<wgrant> Ah
<wgrant> I thought their purpose was to make the diff completely unreadable, particularly when there's a commented line in the middle of a statement :)
<StevenK> Not exactly, no ...
<wgrant> But that looks reasonable otherwise
<StevenK> wgrant: I was going to check that qas/staging/prod are done and then propose my garbo killing branch
<StevenK> Then I can put up this one
<StevenK> sqlvalues of u"'" doesn't escape :_(
<wgrant> Doesn't escape hwhat?
<StevenK> ProgrammingError: syntax error in tsquery: "'"
<StevenK> LINE 1: ...chive IN (16) AND ((searchable_names::tsvector @@ '''')) ORD...
<wgrant> Confused
<wgrant> That is escaped
<wgrant> It's just not valid tsquery syntax
#launchpad-dev 2013-12-09
<stub> lifeless: I'll release it GPL any day now - just need to sync that release with the juju charm merge proposal for reasons.
<lifeless> stub: ah, Reasons!
<Spads> http://zork.net/~nick/pix/reasons.svg <-- lifeless
<lifeless> Spads: thanks :)
<cjwatson> wgrant: I just noticed that all recipes are going to fail under scalingstack, because buildrecipe specifically checks for Xen.  What would your preferred fix for that be?  virt-what looks promising, but it isn't in hardy so there's a bootstrapping problem.  Maybe add a check for whether /proc/cpuinfo contains "QEMU Virtual CPU"?
<wgrant> cjwatson: My preferred fix is to delete the check because it's stupid.
<cjwatson> Ha
<cjwatson> I'll prepare you a branch for that then ..
<wgrant> If I want to compromise a non-virt builder that's accidentally running virt jobs, I can almost as easily escape from a binary build chroot
<cjwatson> Yeah
<cjwatson> I hadn't realised it was added as an alleged security mechanism, but you're right, bug 662664
<_mup_> Bug #662664: recipe builds should ensure they run only under xen <lp-code> <qa-untestable> <recipe> <Launchpad itself:Fix Released by abentley> <https://launchpad.net/bugs/662664>
<cjwatson> https://code.launchpad.net/~cjwatson/launchpad-buildd/delete-virt-check/+merge/198242
<wgrant> cjwatson: Yeah, I tried to explain that chroots weren't root-safe anyway, but that didn't get very far :)
<cjwatson> Any objection to a launchpad-buildd deployment soon, then?
<cjwatson> (Obviously I should organise some QA first)
<wgrant> I forget what's pending
 * wgrant looks
<wgrant> I wonder if infinity has anything else.
#launchpad-dev 2013-12-10
<StevenK> wgrant: So, something about JS
<wgrant> StevenK: Have you looked over it properly?
<StevenK> wgrant: More than one
<StevenK> *once
<wgrant> StevenK: I can't see any more obvious holes. Have you tried exploiting in in practice?
<StevenK> I have not
<cjwatson> wgrant: would you object to me getting started on the master side of livefs building, or do you already have something in progress there?  I was thinking of a DB structure along the lines of http://paste.ubuntu.com/6551720/
<cjwatson> "project" is a bit unfortunate in an LP context, perhaps, but it matches the terminology in the image-building tools
<wgrant> cjwatson: Did you base that on the existing base launchpad-2209-00-0.sql?
#launchpad-dev 2013-12-11
<StevenK> wgrant: Running through some examples from http://sage.math.washington.edu/home/wstein/www/home/agc/lit/javascript/xss.html I don't get the JS executed.
<StevenK> Whoa. The iframe works
<StevenK> That is to say, a comment of '<IFRAME SRC="javascript:alert('XSS');"></IFRAME>'
<wgrant> There's a good reason I asked you to test it :)
<wgrant> It may be a bug in your code that I missed, but it's also reasonably likely that there's a buggy librarian involved.
<wgrant> I do not trust the library authors :)
<StevenK> The <iframe> JS popup has been the only one that has fired
<wgrant> Have you tracked down where the leak is?
<StevenK> Nope
<StevenK> Something about bubbling
<cjwatson> wgrant: Er, in as much as I do any of my DB patches.  I'm not sure I understand the question
<wgrant> cjwatson: It looks like the schema from 12 months ago, before it was adjusted so performance wasn't terrible.
<wgrant> cjwatson: Is there value in splitting LiveFilesystem and LiveFilesystemBuild?
<cjwatson> I think I just thought that was how it was done based on recipes and translations.  But don't we need separate records for The Thing and A Build Of The Thing?
<wgrant> TTBs don't have two halves
<wgrant> Recipes are a bit different
<wgrant> A SourcePackageRecipe may have many SourcePackageRecipeBuilds over years
<cjwatson> Right, and that's true here too, surely
<cjwatson> I don't want to have to put the livefs configuration in place (which is basically what LiveFilesystem is) for every daily build
<wgrant> Er yeah, I was apparently not particularly paying attention when I read that paste.
<wgrant> Right, other way around, that makes more sense.
<cjwatson> It's a bit of an unpleasant grab-bag, and possibly it makes more sense to try to have more of those passed per-build from cdimage
<wgrant> However, you still need to make it look more like binarypackagebuild/sourcepackagerecipebuild/translationtemplatesbuild do today
<wgrant> The BuildFarmJob table is now an optimisation, mirroring columns from the concrete job table.
<wgrant> So LiveFilesystemBuild has date_started, status, etc.
<cjwatson> ok, I may have failed to follow that through.  is there a simple-ish way to get a consolidated dump of the current db structure rather than having to read all the patches in sequence?
<wgrant> Those properties are defined on BuildFarmJobMixin in the code
<wgrant> \d binarypackagebuild
<wgrant> Or you can use pg_dump to get the CREATE TABLE, I guess
<wgrant> Also, LiveFilesystem probably wants an archive column there somewhere.
<wgrant> And I'd really like to not overload "project", though it's not too bad here I suppose.
<wgrant> What is that proposed boolean?
<wgrant> Is it perhaps really a pocket instead?
<cjwatson> maybe we could spell it image_project for this purpose
<wgrant> That would probably be better, yeah
<wgrant> I'm wondering if there's some better name than LiveFilesystem
<wgrant> Since it sounds like the result of the build
<wgrant> That's what had me first
<wgrant> But I guess it's less confusing when you're actually paying attention :)
<cjwatson> proposed> hm, maybe.  the image doesn't go *into* the pocket, though, it's more like a PPA's archive dependencies
<cjwatson> (though maybe the image *should* go into the pocket)
<wgrant> Right, but proposed = true doesn't put it anywhere different either.
<cjwatson> LiveFilesystem - yeah, was the best name I could think of but I'm not totally happy with it, better suggestions appreciated
<wgrant> Setting PPA dependencies to -backports doesn't mean the binaries don't end up in release :)
<wgrant> What're they called in the current infrastructure?
<cjwatson> I think proposed probably ought not to be in the db and ought rather to be a flag passed per-build
<wgrant> Right, that probably makes sense.
<cjwatson> since that corresponds well to how it works in the current infra
<cjwatson> we basically call them live filesystems :-)
<wgrant> I guess archive could equally be on the build, potentially.
<cjwatson> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/ e.g.
<cjwatson> the things that need to be in the db are probably those things that distinguish different livefs types we want to continue building alongside each other, and gc etc.
<cjwatson> archive
<cjwatson> ?
<wgrant> Hm?
<cjwatson> 11:14 <wgrant> I guess archive could equally be on the build, potentially.
<wgrant> It would seem unwise to hardcode the Ubuntu primary archive; experience have shown that such a decision is often to be regretted.
<cjwatson> oh, right, um, that would require teaching lp-buildd about that too
<cjwatson> I take your point; a problem here is that live-build generates the sources.list itself
<wgrant> Oh, it doesn't use the normal lp-buildd sources.list infrastructure?
<wgrant> Forgot that detial.
<cjwatson> we don't really get to insert a full one, it's easier to tell it how to tweak it
<wgrant> Anyway, best to store an archive now anyway, makes it easier to treat like the rest of the archive-related builds
<wgrant> Even if the slave implementation means it doesn't completely work right now
<cjwatson> ok
<wgrant> So, LiveFSBuild probably wants (id, livefs, archive, distroarchseries, pocket, processor, virtualized, date_created, date_started, date_finished, date_first_dispatched, builder, status, log, failure_count, build_farm_job), plus maybe some denormed attributes for querying later, but those are easy to add.
<wgrant> Oh, and some way to actually store the results :)
<cjwatson> er, yeah, *cough*
<wgrant> Since there are multiple files, I guess just a trivial (livefsbuild, lfa) link table?
<cjwatson> maybe a notion of type as well
<wgrant> Unless you want to be more intelligent and stick each type in a separate LFA column on LFB itself
<wgrant> If there's one of each
<cjwatson> I'd like to be able to say "give me the latest manifest for livefs <x>"
<wgrant> But it's been a long time since I looked at cdimage code :)
<wgrant> Right
<cjwatson> but also "download all the latest files for livefs <x>"
<cjwatson> (preferably in a way that doesn't race if it crosses another build)
<wgrant> But you could then just ask for the latest build for livefs X, then look at its list of files
<cjwatson> right
<wgrant> Since lp-buildd doesn't know what files it returns today, and it doesn't seem to provide much benefit for LP to know about them, AFAICT
<wgrant> I may well be wrong.
<cjwatson> I also want to be able to make livefs-build-logs keep working, as a permanent archive of all livefs build logs ever, so that'd be "get latest log for all livefses"
<cjwatson> yeah, possibly it could reasonably just be keyed by filename
<wgrant> Right, though that's easier, since the log is already privileged.
#launchpad-dev 2013-12-12
<stub> Updated the swift config branch, tests still pass
<stub> .. and the large file branch updated too.
#launchpad-dev 2013-12-13
<cjwatson> wgrant: Is there any sensible way to search for code that preloads DAS?
<cjwatson> It doesn't seem to have much in the way of unique reference attribute names
<cjwatson> And there are 827 matches for DistroArchSeries in lib/lp
<wgrant> cjwatson: I doubt anything does, as there usually aren't too many referenced by a batch.
<wgrant> Possibly build lists.
<wgrant> Oh
<wgrant> But they'll not access processor anyway
<wgrant> derp
<cjwatson> 81 files after I exclude tests etc. - maybe I can just read through those
<wgrant> in this case we only care about something that returns a collection of DASes through the webservice
<cjwatson> Which is just distro_series.architectures AFAICS
<wgrant> Very probably.
<cjwatson> That doesn't seem to bother preloading anything right now
<wgrant> Indeed
<wgrant> As we never have more than a few
<cjwatson> Plain references to DAS don't matter?
<cjwatson> (I don't know the raw representation very well)
<wgrant> No, they'll just be serialised as a link
<wgrant> That's why launchpadlib is dreadfully slow
<wgrant> Reference(Choice)s are serialised as links, Lists as lists of links, Collections as links to lists of representations.
<wgrant> So only Collections are a concern here
<cjwatson> Right, so this should be fine but I should make sure to try fetching DS.architectures in QA
<wgrant> Right
<cjwatson> thanks
<wgrant> cjwatson: Ah, I guess you'll need to override processor to readonly=False in the add form
<cjwatson> hmph, right
<wgrant> Forgot that, sorry
<cjwatson> will sort
#launchpad-dev 2013-12-14
<wgrant> cjwatson: Heh
<wgrant> gpg: gpg-agent is not available in this session
<wgrant> Enter passphrase:
<wgrant> I got most of the way through pqm-submitting an almost identical testfix several hours ago
<cjwatson> heh
<cjwatson> well, either way, as you wish
#launchpad-dev 2014-12-11
<cjwatson> wgrant: Do you think it would be reasonable to add navigation by archtag to DistributionSourcePackageReleaseNavigation.traverse_build?  There isn't necessarily a unique answer, but it could redirect you to the newest build for that architecture.  I'm thinking of how to make the build links on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html more useful.
<cjwatson> At the moment we have to just point them at the DSPR itself because we can't construct a direct link to the build without talking to LP.
<cjwatson> (And it could redirect to the DSPR if there isn't a build for that architecture.)
<wgrant> Yeah, that sounds reasonable.
#launchpad-dev 2015-12-08
<mpt> I love it when someone assigns a bug to themselves, and I go look at their profile page, and see that that is the only thing theyâve ever done in Launchpad
<mpt> I wonder whatâs going through their minds when they do that
<xnox> mpt, assign means subscribe in some languages
<mpt> ahhhhhh
<cjwatson> proper fix is probably to translate the LP UI.  running away now
<xnox> universal click to translate would be amazing though
<xnox> is there any upper limit on how ofter the publisher runs?
<cjwatson> it only tries to start every five minutes
#launchpad-dev 2015-12-09
<wgrant> cjwatson: I'm tempted to whitelist sub-delims in librarian URLs too.
<wgrant> Mostly for +.
<wgrant> I guess it's conceivable that we might use semicolons or commas as parameter delimeters in future (see eg. Bazaar colocated branches). But + seems pretty safe.
<lifeless> wgrant: the fix for that chrome thing would be to renormalise no?
<wgrant> lifeless: That's what I'm doing, but I'm also changing the canonical form.
<lifeless> cool
<lifeless> glad its finally getting tackled
<wgrant> Last two commits in https://code.launchpad.net/~wgrant/launchpad/bug-677270
<wgrant> I guess it's easy enough to change again later. I'll just do + on top of the ones the RFC calls out. It's the only other one that shows up often in filenames.
#launchpad-dev 2015-12-10
<wgrant> cjwatson: Do you intend to flip turnip's default VCS?
<cjwatson> wgrant: Oh yes, let's do that now.
<cjwatson> Done.
<wgrant> cjwatson: Just noticed you put the /+git URL on the wiki page, which won't be necessary once the default is flipped.
<cjwatson> Indeed.
<wgrant> Thanks.
#launchpad-dev 2016-12-14
<cjwatson> doh, sorry
