#launchpad-dev 2010-04-19
<jtv> wgrant: nothing blew up with the slave build cookies so far?
<wgrant> jtv: I haven't tested it aggressively, but it seems to be OK.
<jtv> wgrant: cool!
<jtv> wgrant: I felt a bit bad about having an extensive national holiday after dropping a potential bombshell into the codebase, but I have have gotten lucky.  :)
<wgrant> jtv: Heh.
<lifeless> argh, lplib is _so slow_
<jtv> high time for lunch!
<adeuring> morning
<jml> hizello
<wgrant> JoÃ±eaux!
<mrevell> Morning
<jml> wgrant: :D
<jml> mrevell: good morning
<mrevell> How jml
<spm> heyo jml the cruel
<jml> spm: what! I found it for you, didn't I? :P
<spm> lol
<spm> take 3 points for the comment; lose 3 for the cruelty. ;-)
<jml> wuu! it's like Fable 2
<wgrant> How is it in the realms of ash today?
<jml> the usual: grey
<jml> but it's been awesome watching the tree outside my window slowly grow leaves and flowers
<wgrant> Heh.
<deryck> Morning, all.
<deryck> Hi, intellectronica.  I believe bug 566351 might be related to recent bug heat changes.  If not, it relates to heat calculation performance work you're doing.
<mup> Bug #566351: Unable to mark a bug as private (times out) <Launchpad Bugs:New> <https://launchpad.net/bugs/566351>
<intellectronica> deryck: ok, will investigate.
<deryck> intellectronica, thanks
<intellectronica> deryck: i don't think it's related to that change (which is annoying, because if it isn't then why are we starting to see this now?)
<intellectronica> that is, i don't think it's related to heat at all. the thing that times out is trying to subscribe the person marking the bug as private, and that happens before we do anything heat-related
<deryck> intellectronica, I saw those 63 select bugjob statements, which seems to be where the timeout is.  So I thought it must be related to heat.  Or am I misreading that?
<intellectronica> deryck: ah right, maybe it is heat-related, in that the job creation is triggered by adding a subscription. but it's not related to the immediate heat calculation (also i can reproduce on staging, which still doesn't have this change).
<wgrant> The distroseries index seems really slow now.
<wgrant> OOPS-1570EB719
<deryck> intellectronica, ok, cool.  so not new, but perhaps heat related then.
<intellectronica> yes
<wgrant> bigjools: Bug #253509?
<mup> Bug #253509: Security contact subscribed when moving tasks <Launchpad Bugs:Confirmed> <https://launchpad.net/bugs/253509>
<bigjools> careful, you'll get called mpt soon :)
<wgrant> Nah, I filed this one.
<bigjools> yeah was gonna say
 * bigjools sighs at the desktop getting slower the longer it's used
<wgrant> So, the security notification breakage is being fixed?
<wgrant> bigjools: Lucid?
<bigjools> yes
<wgrant> With a GEM-using graphics driver?
<bigjools> GEM?
<wgrant> grep "object bytes" /sys/kernel/debug/dri/0/gem_objects
<bigjools> no such file ...
<bigjools> it's nvidia
<wgrant> OK, so not the big GEM leak then.
<wgrant> Ah.
<bigjools> it also decides it can't start when I boot and goes to the "reconfigure X" dialog :/
<wgrant> <3 proprietary drivers
<bigjools> I doubt this is a proprietary driver bug
<bigjools> it's a setup bug
<bigjools> the slowness, I dunno, however
<wgrant> bigjools: Can I somehow get hold of one of the new timestamped cron.publish-ftpmaster logs?
<bigjools> wgrant: yeah, one sec
<leonardr> james_w, where are you on updating bzr-builddeb to avoid using the 'beta' service? i don't see any recent branches from you for that package
<james_w> leonardr: it's done
<leonardr> james_w: great. do you think we're ready to push the new version of launchpadlib to lucid?
<james_w> done as well
<james_w> must have dropped you from CC, sorry
<james_w> the only issue I've seen is with the launchpad bzr plugin
<james_w> its hacked up version of web_link broke
<leonardr> james_w: is that also fixed?
<james_w> not yet
<leonardr> i'm checking whether the software-properties problem is fixed
<wgrant> bigjools: Thanks.
<leonardr> it is fixed, great
<bigjools> welcome
<wgrant> bigjools: Also, any progress on the PPA log parser script setup?
<bigjools> wgrant: waiting on the RT
<wgrant> bigjools: Ah, great. Thanks!
<bigjools> will poke some people about that today
<wgrant> 2010-04-17 23:05:32 DEBUG   Sorting sources...
<wgrant> 2010-04-17 23:07:51 DEBUG   Dominating sources...
<wgrant> Wow.
<wgrant> That really doesn't need to take more than a second.
<wgrant> bigjools: Hm, the log stops rather abruptly.
<bigjools> wgrant: yeah it gets synced over to a different maching, they clashed
<bigjools> machine*
<wgrant> Ah :(
<wgrant> Still, apt-ftparchive is really extraordinarily slow.
<bigjools> yes, yes it is
<bigjools> if we can get the soyuz publisher to handle extra overrides, we'd be able to do a direct comparison
<bigjools> right, lunch time
<wgrant> bigjools: A direct comparison will make you cry.
<wgrant> NMAF is probably around an order of magnitude slower.
<deryck> sinzui, ping
<sinzui> hi deryck
<wgrant> bigjools: Shouldn't uploads to obsolete series in PPAs be rejected?
<bigjools> wgrant: cprov always maintained after you take everything into account, they were comparable
<bigjools> that's why I want full comparisons :)
<bigjools> and yes obsolete series should refuse PPA uploads
<wgrant> It's pretty easy to get NMAF up to around 6000 stanzas per second locally by caching them. But I'm not sure how much of a penalty extra overrides will be -- we can't safely cache them.
<mars> danilos, ping, did you get a chance to try the ec2 test patch?
<danilos> mars, yes, see email
<mars> danilos, ah, thanks!
<danilos> mars, in short works fine :)
<mars> and a big "ARGH" goes towards my busted mail filters
<mars> sinzui, do you remember what version of zope we were using before the 3.4.??? upgrade?
<mars> sinzui, it was 3.2somethingbeta I believe?
<sinzui> 3.2 + patches
<sinzui> mars: it was not an official release
<mars> sinzui, ok, thanks
<bigjools> wgrant: I expect it can be further improved quite easily, cStringIO etc and other critical parts compiled
<deryck> adeuring, so the only surprise from running expiring script on staging was script perms?  Does that mean none of the staging bugs got set EXPIRED?
<BjornT> gary_poster: ping
<leonardr> jml: i'd like your opinion on a couple new potential performance improvements
<gary_poster> BjornT: pong
<leonardr> https://dev.launchpad.net/Foundations/Webservice/Performance#line-184 and the section beneath it
<BjornT> gary_poster: i'm trying to add http://pypi.python.org/pypi/repoze.sphinx.autointerface/0.3 to our buildout config, so that i can use that plugin in sphinx
<jml> leonardr: thanks. I'll take a look, but I'm on the phone from now until tomorrow :(
<leonardr> jml, no rush
<BjornT> gary_poster: however, it requires Sphinx >= 0.6.1, and even though i have 0.6.2 installed in the system python, buildout doesn't find it
<BjornT> gary_poster: anyway to tell buildout that "i actually have this package already", instead of adding sphinx and its dependencies to buildout?
<gary_poster> BjornT: no, buildout should not use eggs from system Python.  It only allows the underlying site-packages to be available.  Doing anything else was even more rickety than what we are already doing.  So, in this case, either get the repoze package in our PPA or something, or use Sphinx from a package buildout manages
<BjornT> gary_poster: ok, thanks
<gary_poster> np
<BjornT> gary_poster: do you know who would be able to package a python module quickly? i guess it should be easy, but slow if you haven't done it before.
<gary_poster> BjornT: I think you are right about "should be easy". :-) and Python packages in particular are tricky, I believe, maybe even esp. those with namespaces.  I know U1 does it a lot.  Maybe noodles775 would have other ideas?  I unfortunately do not have experience with it myself, though I'd like to.
<jml> BjornT: I'd ask someone from U1
<henninge> Hi all! Does this ring any bell?
<henninge>         context = gpgme.Context()
<henninge>     GpgmeError: (32, 176, 'Unknown error code')
<kfogel> adeuring: if you will be around in ~45 min, I'd like to talk about getting a good query for persons/teams in https://bazaar.launchpad.net/~kfogel/tuolumne-lp-configs/patches-time-to-closing/revision/40 .
<kfogel> henninge: nope, sorry
<jelmer> henninge: yes; it's fixed in lp:~launchpad-pqm/pygpgme/devel, but that hasn't landed yet because of other errors
<henninge> jelmer, kfogel: thanks, good to know ;)
<bigjools> henninge: bzr pull the pygpgme sourcecode
<bigjools> then run make in the same dir, then in the devel dir, make clean
<bigjools> then it WFM
<henninge> bigjools: cool, thanks
<maxb> jelmer: About those other errors - do you have a plan?
<bac> hi leonardr, i'm having problems using lplib against a dev instance.  have you seen anything like this before: http://paste.ubuntu.com/418662/ ?
<leonardr> bac: no, take a look at how the sock object is created
<bac> leonardr: sorry to bother you
<bac> turns out my apache wasn't running
<leonardr> ok
<kfogel> adeuring: ping
<deryck> hi kfogel.  I think he might be unavailable for a little while.
 * deryck pinged earlier forgetting that
<kfogel> deryck: thx
<jml> g'night all
<adiroiban> is make iharness working ? I'm trying to create a view and it enters an infinite loop
<samgee> is there anything I could do to help solve https://launchpad.net/bugs/549041 or is that something ubuntu admins need to fix? (I'm not familiar with soyuz in any way [yet].)
<mup> Bug #549041: don't de-index source packages until they're due to be removed from disk <soyuz-publish> <Soyuz:Triaged> <https://launchpad.net/bugs/549041>
<bac> hi leonardr, i'm trying to write some launchpadlib pagetests and i'm discovering some things that work as expected in an interactive lplib session but do not work in the test environment.
<bac> collection = lp_anon.project_groups.search(text="Apache")
<bac> throws a 405
<leonardr> bac, can you paste the full httperror dump?
<bac> http://paste.ubuntu.com/418829/
<leonardr> bac: given that 'allow' contains pretty much every http method there's probably something wrong with the http transport
<leonardr> can you also set httplib2.debuglevel = 1 and see what is sent?
<bac> leonardr: ok
<cody-somerville> Is there a non-admin launchpad.dev account that I can log in to?
<cody-somerville> I suppose I could just set a password for the cprov account or something like that, right?
<bac> leonardr: here is the output but the httplib2 debug was not generated for the call.  it was shown for the call to login_anonymously but not the search.  https://pastebin.canonical.com/30870/
<leonardr> bac: 1. push your branch so i can try it
<leonardr> 2. do you know if other launchpadlib actions result in httplib2 dumps?
<bac> leonardr: 2) in the interactive env the search does generated debug output
<bac> 1) will do
<leonardr> bac: for 2) can you do something other than run this search and see if there's output?
<bac> sure
<bac> leonardr: lp:~bac/launchpad/bug-524778
<bac> leonardr: bin/test -vv  -t lp-proj.txt
<leonardr> ok
<bac> leonardr: no, i put in just a call to lp_anon.project_groups to get the collection and debug output wasn't shown
<leonardr> but lp_anon.project_groups worked?
<bac> yes
<bac> it works but the search() does not
<leonardr> ok
<thumper> morning
<leonardr> bac, i suspect the request is never making it into lazr.restful code. you could test this with breakpoints in HTTPResource.do_GET. i suspect something about the way the test env is hooked up is to blame
<leonardr> i'm eod but i will look at this tomorrow if you're still stuck. i will probably need to do another launchpad branch
<bac> leonardr: ok, i think you're right.  other than your launchpadlib.txt i don't think this has been exercised much
<bac> thanks for your help and i'll talk to you tomorrow
<lifeless> leonardr: hi
<lifeless> leonardr: launchpadlib seems to make HTTP requests on every object traversal; is there some way to make it cache things and avoid querying each time ?
<leonardr> lifeless: yes, at the cost of the client sometimes having out-of-date information
<leonardr> https://dev.launchpad.net/Foundations/Webservice/Performance#line-184
<maxb> jelmer: Around? (Regarding pygpgme and lucid)
<lifeless> leonardr: we're in a 1-a-minute cron job, and its doing some absurd amount of lookups - 1000's perhaps.
<lifeless> bwah
<thumper> sinzui: ping
<james_w> lifeless: you can try the twisted client, it forces you to request the lookups
<james_w> lifeless: it's still experimental though, so it may well require some contribution for it to work for you
<lifeless> james_w: sounds interesting; at least for now though I can't justify the time - this is a slack-time project to get rid of 'pqm-submit'
<james_w> right
<lifeless> james_w: and production code really wants package deployed dependencies etc
<james_w> lifeless: sure, it's not ready yet. However, given that you mentioned async lplib yesterday, and now asked about a feature you get with it, I thought I would mention it :-)
<lifeless> james_w: I appreciate that
<lifeless> james_w: where is it btw ?
<james_w> lazr.restfulclient.tx
<james_w> on a well-known open source hosting platform
<lifeless> :P
<thumper> james_w: what? github?
<james_w> mais oui
<mwhudson> buzzword fail!
<mwhudson> james_w: you meant *colloboration* platform!
<mwhudson> except with better spelling
<james_w> no, I think I probably meant colloboration, it's late here
#launchpad-dev 2010-04-20
<wgrant> mwhudson, thumper: Isn't that recipe deletion work going to explode horribly if a build has succeeded and produced a SourcePackageRelease?
<mwhudson> wgrant: i think you should ask abentley that question
<thumper> wgrant: explode horribly is a bit drastic, oops perhaps
<abentley> wgrant, I don't have enough data.
<thumper> but I don't think any thing will explode
<wgrant> Well, it's the sort of object that is impossible to delete, and nulling the FK is dangerous, so there is probably no good solution.
<abentley> wgrant, do you have any suggestions about which things should be deleted and which things should be nulled?
<wgrant> abentley: Deleting the SPRB for an SPR removes all indication of who uploaded the package. Having an SPRB hanging around without a recipe sounds like a recipe for trouble. And having a recipe hanging around without its branches also doesn't sound very good.
<lifeless> monring poolie :P
<poolie> hi there
<mwhudson> grr
<mwhudson> AssertionError: result must be a Zope result object, not <testtools.testresult.real.MultiTestResult run=0 errors=0 failures=0>.
<mwhudson> this is probably using a new ec2 test with an old branch :(
<mwhudson> in particular: new ec2-test-remote
<mwhudson> haaaaaaaate
<cody-somerville> mwhudson, My ec2 instance is no longer active but I didn't get any e-mail nor did my merge proposal get marked as merged.
<mwhudson> cody-somerville: :(
<mwhudson> that happens sometimes
<cody-somerville> errr... is anyone working on fixing it?
<mwhudson> i don't think it's well understood
<mwhudson> cody-somerville: you could run it attached with -p and see what happens at the end
<cody-somerville> so no one is working on it? Not very LEAN :P
<mwhudson> cody-somerville: well more that i don't have the status of every infrastructure issue launchpad development faces embedded in my brain
<cody-somerville> I figured the fact that this bug has a very measurable cost to every time it occurs, I figured folks would be motivated to fix it.
<mwhudson> actually, i think one potential cause has been fixed
<mwhudson> so if it's happening again, more investigation has been required
<wgrant> OOPS-1571H345
<wgrant> Can someone please give me a traceback for that one?
<lifeless> oops 1571H345
<lifeless> oops OOPS-1571H345
<lifeless> bah
<wgrant> mup is sad.
<wgrant> Or maybe only ubottu does them.
<lifeless> timeout
<lifeless> 20000.0  1  launchpad-main-master  SELECT PackageUpload.archive, PackageUpload.changesfile, PackageUpload.date_created, PackageUpload.distroseries, PackageUpload.id, PackageUpload.pocket, PackageUpload.signing_key, PackageUpload.status FROM PackageUpload WHERE packageupload.distroseries = 103 AND packageupload.archive IN (1, 534) AND packageupload.status IN (0) ORDER BY PackageUpload.id DESC LIMIT 7 OFFSET 0
<wgrant> lifeless: Was that rendering the index, or performing the accept?
<lifeless> +queue
<lifeless>  /srv/launchpad.net/production/launchpad-rev-9191/lib/lp/soyuz/browser/../templates/distroseries-queue.pt
<lifeless> Line 19, Column 4
<lifeless>    - Expression: <PathExpr standard:u'view/decoratedQueueBatch|nothing'>
<wgrant> Right, but which action was called? (alternatively just pastebin the traceback)
<wgrant> Hmmm. That's odd.
<lifeless> wgrant: patience kemosabe ;P
<lifeless> I'd say db locking issue
<wgrant> Ah.
<lifeless> that queury which I pasted took 20000 seconds and was interrupted
<lifeless> but it looks like a normally very fast query
<wgrant> I thought that was during an accept, though, which should not actually be rendering that at all.
<wgrant> Unless it was after the redirect.
<lifeless> its on +queue
<lifeless> so after the redirect, I think
<wgrant> +queue performs actions too, though.
<lifeless> oh
<lifeless> no args
<wgrant> If you POST to +queue, it will do stuff then redirect you back to +queue.
<lifeless> it was a post
<wgrant> So WTF is it trying to render anything... gah.
<wgrant> lifeless: Thanks.
<lifeless> anyone know how to get 'me' with launchpadlib ?
<lifeless> bah, I see it.
<adeuring> good morning
<mrevell> Morning
<jpds> What's the difference between @cachedproperty and @property ?
<bigjools> jpds: @cachedproperty is only called once, its return value is cached
<jpds> bigjools: I should so be using that for the mirror listings.
<bigjools> jpds: it comes with many caveats, you should have a pre-imp with someone about it
<jtv> henninge: for now, I want to set up a pottery-capable branch in a project on staging.
<jtv> henninge: if we can have the config change cowboyed in there, we can verify that pushing changes will generate the jobs we want.
<jtv> henninge: it should produce triples of Job, BranchJob, and BuildQueue.
<henninge> jtv: how do we see jobs? sql?
<jtv> henninge: yes
<jtv> Then on dogfood, we manually recreate those triplets.
<henninge> jtv: have we figured out the branch pulling part?
<henninge> I mean, getting the branch unto dogfood?
<jtv> henninge: "unto"?  Very biblical.
<henninge> ;-)
<henninge> yes, I read my scriptures in English atm ... ;)
<jtv> The good news there is that we can create jobs referring to branch URLs on staging.  The bad news is, we probably still need to give the slaves permission for that bit of traffic.
<jtv> (But the URLs themselves are already usable)
<jtv> That Gideon guy again?  Goes around the world from hotel to hotel, and _always_ forgets his bible.
<henninge> In Dallas he also forgot a Book of Mormon - which I only noticed on the last night ...
<jtv> Personally I wouldn't pay any attention to the reading recommendations of someone who's this consistently sloppy.
<jtv> Also, you'd think he'd know the thing by heart now.  Why bring a bible on every single trip?
<jtv> Get a new book, for God's sake!
<wgrant> jtv: How do you propose to reference branches on staging?
<jtv> wgrant: IIRC I just tried it once and found that it worked.  Production would work as well here though.
<henninge_> jtv: daily  reconnect. I'll have to move that to some other time of the day ...
<wgrant> jtv: dogfood's config references production codehosting (ie. the branch prefix is lp:, not lp://staging/ or similar).
<wgrant> So any recipes will have lp:-prefixed branches.
<jtv> henninge_: "at" + "curl" to your modem should do the trick once.  Or cron + curl to make it repeatable.
<jtv> wgrant: this feature deliberately generates http branches
<jtv> URLs, I mean.
<wgrant> jtv: Oh, right, I was thinking of recipes, which use lp: URLs.
<jtv> wgrant: that's something I always forget to ask about.  We implemented a way to ask for a specific schema (http by default) for this, and maybe recipe builds should just do the same.
<wgrant> jtv: Why? lp: works just fine?
<wgrant> s/?$/./
<jtv> wgrant: you just pointed out where it didn't
<wgrant> jtv: Well, dogfood is broken, so I don't think it can be used as a counterexample.
<jtv> Not production, I know, but still valuable.
<jtv> wgrant: predictable http URLs eliminate the "use whatever the lp: schema maps to in this case" concern as well.
<jtv> henninge: do you happen to know any specific (and preferably small) branches on LP that pottery will work for?  I'm using gedit at the moment.
<jtv> Haven't yet verified that the pottery compatibility check and template generation actually work on it though.
<henninge> jtv: I never looked for branches on Launchpad
<henninge> I used gimp, though (apt-get source) because it has multiple templates.
<jtv> henninge: to copy that branch to staging, you can bzr push -d lp:gedit lp://staging/~jtv/my/branch --use-existing-dir
<jtv> henninge: shall I start a wiki page for the staging/dogfood testing?
<henninge> jtv: that would be great
<jtv> henninge: and once we have it, maybe you can add a simple recipe for checking that a branch is suitable?
<henninge> jtv: it's supposed to be any intltool branch.
<jtv> henninge: oh, that's niceâI thought it was only the more recent intltool setups for now.  In any case, it would be nice to know for sure.  If the code decides not to generate for a particular branch, it doesn't say why.
<henninge> jtv: you no more about different versions of intltool setup than I do, then.
<jtv> henninge: unlikely.  :)  But there was mention of multiple possible setups in Belgrade, and how we were aiming for only the most modern setup initially.
<henninge> jtv: the best way to find out is to try it out ... ;-)
<jtv> henninge: that doesn't tell me what the different setups are, and trying them all out would probably not be the best way there.
<wgrant> I didn't manage to find a branch that Just Worked.
<wgrant> I had to hack GETTEXT_PACKAGE into configure.ac or something like that.
<henninge> jtv: so, there is only one supported setup, then.
<jtv> wgrant: speaking as a complete n00b on this subject, doesn't that default to autoconf's regular notions of what package it's setting up?
<wgrant> jtv: Not when pottery is grepping through it, AFAICT.
<wgrant> But I didn't look hard.
<wgrant> I just looked at the code and poked things until it worked.
<jtv> wgrant: so that may well be a bug in pottery?
<wgrant> jtv: I try to remain blissfully ignorant of autofoo.
<jtv> Well, sorely missing feature anyway  :)
<jtv> wgrant: funny how people think of drugs as things that make you stupid, when they actually are a way to obtain bliss without ignorance
<wgrant> Heh.
<jtv> wgrant: a bit like saying "if you think the glass is half empty, you're a pessimist" when in reality it's just being forward-thinking.
<jtv> henninge: first piece of page is up on the wiki.  https://dev.launchpad.net/Translations/GenerateTemplatesOnTestServers
<jtv> I've renamed the one for local machines from Build[...] to Generate[...] to avoid confusion.
<jtv> (I love how changes "to avoid confusion" always create immediate confusion no matter how appropriate they may be)
<jtv> wgrant: by the way... you mentioned how dogfood refers to production codehosting.  I guess that also means we must be careful not to push test branches to dogfood!
<wgrant> jtv: Well, if you tried it would fail, since there isn't even a bazaar.dogfood.launchpad.net.
<wgrant> noodles775: Hi. I want to present package diffs on +queue. Do you have any UI ideas?
<noodles775> wgrant: I'd suggest creating something (with balsamiq?, but up to you), and then getting feedback from the people like StevenK/ScottK (but cc'ing the dev list)?
<noodles775> wgrant: It may not be relevant, but we started collecting use-cases etc., for the queue page during 3.0, but never got the time to do anything with it. https://dev.launchpad.net/SoyuzDistroSeriesQueuePage
<noodles775> But if you think it's worthwhile, you could add a use-case there too.
<noodles775> wgrant: but if it's a very straight-forward change, and you already have a good knowledge of the use-cases for the queue page, just a simple mockup will be perfect (balsamiq or screenshot).
<wgrant> noodles775: Yeah, it's a really simple change. The data is all there already, just not exposed anywhere. I plan to just add another row to the upload file table linking to the diff -- mainly wondering about the text.
<noodles775> View the [link]difference from the previous package[/link]? Or simpler, without the "View the"? What had you thought of so far?
<wgrant> noodles775: The other files just give a filename and its size.
<deryck> Morning, all.
<jml> bigjools: hi
<jml> deryck: good morning
<bigjools> jml: helleau
<jml> bigjools: let's talk about timeouts.
<bigjools> jml: there's already a timeout test in test_manager.py and it doesn't use clock
<bigjools> but happy to talk more and learn!
<jml> bigjools: it's probably wrong :)
 * jml brandishes the confidence of the ignorant
<bigjools> hehe
<jml> yeah
<bigjools> I have found a load of bugs in the manager tests though :/
<jml> it's not wrong per se, but why wait five seconds when you can wait almost none
<bigjools> jml: I agree
<jml> we can use a clock for this, but I need to page in the code again
<bigjools> jml: notice how test_resumeHost_timeout uses addErrBack
<bigjools> so if the code doesn't fail as expected, the test still passes :)
<jml> :(
<bigjools> and the config doesn't get popped .... but, all easy to fix
<jml> :(
<jml> I wrote assertFailure for precisely this reason.
<jml> or maybe I didn't, maybe someone else did
<bigjools> jml: so we can use assertFailure instead of assertIsInstance( ...
<jml>  yeah, d = self.slave.resumeSlave()
<jml> d = self.assertFailure(d, ProcessTerminated)
<jml> d.addBoth(lambda ignored: config.pop)
<jml> return d
<jml> actually, hmm
<bigjools> nope, addCleanup FTW :)
<jml> awesome
<jml> good. because the addBoth I described was buggy :)
<bigjools> lol
<bigjools> yes, it is :)
<bigjools> anyway it's not returning Failure any more
<bigjools> there's that three-tuple with the stdout/err/exit code
<jml> oh right.
<jml> that kind of makes sense though, doesn't it?
<bigjools> yes it's what we want
<bigjools> I'm nearly done with the tests now
<bigjools> and if we can improve the timeout one to use clock, that'd be awesomw
<jml> so I figured it out
<jml> reactor implements a clock interface
<jml> so does twisted.internet.task.Clock
<jml> make clock an optional parameter to whatever is doing the .callLater() calls
<jml> pass in a t.i.task.Clock from your tests
<jml> and then call clock.advance(seconds) to magically go forward in time
<bigjools> schweet
<jml> and then, when clock isn't passed in, default to using the reactor.
<jml> lp.services.twistedsupport.tests.test_task has some examples.
<lifeless> wouldn't it be simpler to pass in a reactor
<bigjools> cool, I'll slap that in when I get the rest of the tests passing :)
<lifeless> then you can modify that, and do controlled interactions of other sorts too
<lifeless> jml: ^ bigjools: ^
<lifeless> a small decorator would let you pass in the installed reactor with a custom clock
<bigjools> lifeless: sounds OTT for this test, but I can lookl
<bigjools> thanks
<lifeless> http://jcalderone.livejournal.com/51888.html suggests passing in a reactor to things, FWIW
<jml> lifeless: that's what I'm describing.
<lifeless> jml: it didn't sound like it.
<bigjools> didn't to me either
<lifeless> jml: it sounds like you were suggesting passing in a IHasClock, which wouldn't implement callLayer etc
<jml> lifeless: uaoesnthuiaoesndaoe-ucaonseiudht
<lifeless> jml: EPARSE
<jml> lifeless: t.i.task.Clock implements callLater
<jml> lifeless: reactor implements callLater
<lifeless> oh wow
<lifeless> jml: perhaps you are describing it in a round-about way, or perhaps we mean something different.
<lifeless> if we agree that jcalderone's blog post sounds good, we can assume violent agreement and move on
 * jml does so
 * bigjools bitches about spawnProcess's stupid arguments
<bigjools> jml: clock.advance FTW!
<jml> bigjools: sweet
<bigjools> jml: interested in reviewing this if you have time.  I don't mind if you want to punt.
<bigjools> err there should be a "?" in there somewhere ...
<jml> bigjools: if I do, it'll be later in the day
<leonardr> bac, i am recreating your error and i noticed that i am using the system httplib2 (0.4.0), not the 0.6.0 packaged with launchpad
<leonardr> i don't see how that could be causing the problem, but it's a problem i don't understand right at the point of the error
<leonardr> are you also using 0.4.0?
<leonardr> bac, because of the 0.4.0 problem i can't see what's happening in httplib2. i'm going to put off work on this until i hear from you
<bac> leonardr: i'm not sure which version i was using.  it should be in the traceback.  let me find that paste...
<leonardr> i didn't see it
<leonardr> because your error didn't happen in httplib2
<leonardr> i'll paste mine
<leonardr> i don't get as far as you
<bac> oh, you're right, httplib2 was not involved in the traceback
<leonardr> bac, http://pastebin.ubuntu.com/419239/
<bac> leonardr: well, i see you're not using the LP version of lazr.restfulclient either
<leonardr> bac: i get the same error when i do. use-0.6.0 was an attempt at putting a httplib2>=0.6.0 requirement in lazr.restfulclient itself, in addition to the launchpad one
<bac> leonardr: oh
<bac> File "lib/lp/registry/tests/../doc/launchpadlib/lp-proj.txt", line 35, in lp-proj.txt
<bac> Failed example:
<bac>     print httplib2.__file__
<bac> Differences (ndiff with -expected +actual):
<bac>     + /home/bac/launchpad/lp-sourcedeps/eggs/httplib2-0.6.0-py2.5.egg/httplib2/__init__.pyc
<bac> so i am picking up the correct one
<leonardr> aargh
<leonardr> bac: why would i be picking up the site-packages 0.4 version?
<bac> leonardr: i don't know.  i recently fought some problems and it was caused b/c i had an old storm package in site-packages and it was getting it
<bac> sounds like a foundations issue to me.  :)
<leonardr> yeah, if only anyone who knew about this stuff was around
<leonardr> bac: ah, i've just got an egg file lying around in my site-packages
<leonardr> it's not even unzipped
<leonardr> $#%!$#5
<bac> leonardr: you conjured up gary_poster quite nicely
 * gary_poster will not look for trouble, but will be happy to help if needed
<leonardr> well, let's see what happens now
<leonardr> bac: i got a little further. now getting AttributeError: 'Parameter' object has no attribute 'options'
<leonardr> which could indicate a problem with the wadl
<leonardr> bac, do me a favor
<leonardr> put a breakpoint in lazr.restfulclient resource.py, right before send_as_is_params is defined
<leonardr> or rather, have it print out this value:
<leonardr> [x.name, x.options for x in params]
<leonardr> bac: dammit, nm
<leonardr> i'm using an old wadllib
<leonardr> i must have accidentally installed the launchpadlib ubuntu package or something
<leonardr> bac: ok, i can now duplicate your error
<bac> progress.
<leonardr> bac: if i had to guess i'd say that request is going into the xml-rpc request handler, not the web service request handler
<leonardr> bac: ok, here's the problem
<leonardr> (Pdb) method
<leonardr> 'get'
<leonardr> (Pdb) self.getAcceptableMethods(environment)
<leonardr> ['GET', 'HEAD', 'POST', 'PATCH', 'PUT', 'DELETE', 'OPTIONS']
<leonardr> (Pdb) method in self.getAcceptableMethods(environment)
<leonardr> False
<bac> so it's just case?
<henninge> danilos: We are dealing with the current behaviour for pofile export to replace the plural information with that information from the language record, right?
<leonardr> bac: yes. i believe if the request goes all the way through httplib2, it gets uppercased
<henninge> danilos: only, I cannot see where that is happening.
<leonardr> but since wsgi_intercept handles the request, that code doesn't run
<leonardr> bac, if i do a new release of lazr.restfulclient, will you integrate it into launchpad?
<leonardr> i think l.r is the place to fix this
<bac> leonardr: sure
<danilos> henninge, right
<danilos> henninge, let me take a look
<danilos> henninge, gettext_po_parser.py look for getRawHeader() 'plural-forms' key handling
<henninge> danilos: I have been there ...
<henninge> getRawContent
<henninge> danilos: but that is what POHeader parsed originally
<henninge> danilos: I think its here:
<henninge> lib/lp/translations/model/pofile.py:1723:            number_plural_forms = None
<henninge> lib/lp/translations/model/pofile.py:1731:                number_plural_forms = self._pofile.language.pluralforms
<henninge> lib/lp/translations/model/pofile.py:1735:            translation_header.number_plural_forms = number_plural_forms
<danilos> henninge, sounds right :)
<ricotz> bigjools, hello
<leonardr> bac: i think this would be a better solution, since normally lazr.restfulclient + wsgi_intercept doesn't have the problem
<leonardr> http://pastebin.ubuntu.com/419325/
<leonardr> put that in your launchpad branch
<mrevell> Night all
<salgado> wgrant, is there anything that would prevent https://code.edge.launchpad.net/~wgrant/launchpad/emailauthentication.txt-2.6-fix/+merge/23449 from landing?  I'd be happy to take it from there and do the changes suggested by Michael if you don't have time for it
<jml> g'night all
<thumper> morning
<wgrant> salgado-afk: noodles wanted a bug reference for the Python bug.
<wgrant> salgado-afk: I don't think one exists, so I was digging deeper, but then uni caught up with me.
#launchpad-dev 2010-04-21
<mwhudson> yay windmill tests have hung for me in ec2
<cody-somerville> thumper, mwhudson: I think that was my problem as well yesterday.
<thumper> cody-somerville: interesting
<thumper> cody-somerville: and sucky at the same time
<poolie> mwhudson: istm that you could usefully ask for things to be cached for a short time even without revalidation
<poolie> as long as user-forced refreshes do go through to the real server
<mwhudson> poolie: very likely
<poolie> mwhudson: and can you see errors logs from codebrowse now directly, or through a losa?
<mwhudson> poolie: i can still log in to the machine it runs on
<poolie> we should hand that over
<mwhudson> yeah
<poolie> and do you use that for anything else?
<mwhudson> i have this script i use to get the tracebacks out of core files
<mwhudson> but that actually works now, so we should be able to get the losas to do taht
<spm> mwhudson: don't we drag the codebrowse logs onto devpad?
<mwhudson> spm: pass
<spm> heh, looks...
<adeuring> good morning
<bigjools> wgrant: Happy birthday :)
<wgrant> bigjools: Thanks!
<spm> wgrant: so... 11? 12? years old?
<wgrant> spm: Heh. 19.
<spm> :-) Happy Birthday man, enjoy it eh!
<bigjools> spm: lol
<thumper> wgrant: yeah, happy birthday. Facebook told me earlier today but I just clean forgot
<bigjools> yay for the kernel thinking I don't have any USB ports any more
<wgrant> Really no USB ports, or just not detecting mass storage devices?
<wgrant> I've had the latter problem on and off; I think I need to reinstall.
<bigjools> well my keyboard stopped working
<wgrant> Niice.
<bigjools> and unplugging/re-plugging makes no difference
<deryck> Morning, all.
<mrevell> intellectronica, ping
<intellectronica> mrevell: ahoi
<mrevell> intellectronica, Sorry, unping
<intellectronica> mrevell: np, unahoi
<mrevell> :)
<henninge> danilos: Can you look at this and tell me if I included all the cases we discussed? http://paste.ubuntu.com/419756/
<henninge> danilos: I'll be out to lunch soon, actually.
<danilos> henninge, western-plural-form can probably be '!(n>1)' or similar as well
<henninge> ok, I'll add that
<danilos> henninge, it'd be nice to filter out our list using this code to see what's left :)
<henninge> good idea, I'll try that after lunch
<danilos> henninge, cool, thanks
<danilos> henninge, btw, !(n>1) is not really the same one, so ignore that
<mrevell> intellectronica, I've created a branch with a help pop-up to explain how bug heat is calculated -- https://code.edge.launchpad.net/~matthew.revell/launchpad/bug-heat-help-bug-544799 -- (lib/lp/bugs/help/bug-heat.html) -- I'd love your thoughts before I proceed.
<intellectronica> mrevell: i'm just about to break for lunch, but will have a look as soon as i'm back
<mrevell> thanks intellectronica
<mrevell> I too am breaking for lunch
<bac> leonardr: i applied your patch yesterday and it worked
<leonardr> bac, great
<deryck> BjornT, ping
<BjornT> deryck: i'm on the phone
<deryck> BjornT, ok.  I want some phone time, when you are available. :-)
<deryck> perhaps gmb can help.  :-)  gmb, do you have time for a mid-imp type of discussion?
<mars> leonardr, seen this? http://www.mikealrogers.com/archives/695
<leonardr> mars, no, glad we're using simplejson
<leonardr> or maybe i should have hoped we were using stdlib json so we could easily get a huge speedup
<mars> hehe
<gmb> deryck, Sure.
<mars> leonardr, worth glancing at the comments as well.  People explain why and where things are going.
<deryck> gmb, cool, thanks!  mumble?
<gmb> deryck, Yep.
<deryck> gmb, for reference see the diff on the mp for bug 494257.
<mup> Bug #494257: Users not notified in email when subscribed by someone else <email> <qa-bad> <ubuntu-qa> <Launchpad Bugs:Fix Committed by deryck> <https://launchpad.net/bugs/494257>
 * gmb looks
<gmb> deryck, eggs/zope.event-3.4.1-py2.5.egg/zope/event/__init__.py
<deryck> heh.
<deryck> zope.event.notify is called *a lot*
<maxb> salgado: Your last wiki edit to PythonMigrationStatus makes very little sense in multiple ways :-)
<salgado> maxb, other than the order of the link/text in [[link|text]]?
<maxb> that's one :-)
<maxb> the other is that I certainly didn't create a launchpad branch based on a shipit branch
<salgado> oops
 * salgado reverts all that
<salgado> thanks for spotting it, maxb
<maxb> thanks for sorting pygpgme :-)
<allenap> Is anyone fixing the failures in the latest lp buildbot run?
<leonardr> lifeless: how much data is in the 'message' you're passing in to createContent?
<leonardr> you're more likely to get a timeout if you pass a huge chunk of text
<leonardr> for instance, i'm passing in a 68k string and it's been about 10 minutes with no response
<mrevell> hey intellectronica
<intellectronica> hey mrevell
<intellectronica> mrevell: so, i asked deryck to have a look at it too, since i can't decide about the table
<mrevell> Ah okay
<deryck> intellectronica, I can look now.
<bac> reviewers meeting starting now
<intellectronica> mrevell: i have another concern. how do we make sure that the help text stays current when the implementation chnages?
<kfogel> adeuring: if you have some time today or tomorrow, I'd like to chat (skype even?) about parallelizing work on some queries.  I know this is kind of not in your regular schedule, so if you're booked please feel free to push back.
<intellectronica> mrevell: other than that, ask anything you might want about linking it r whatever :)
<adeuring> kfogel: no, let's talk
<kfogel> adeuring: great.  I'll turn on skype.
<kfogel> one sec
<kfogel> jtv: just fyi I subscribed you to bug #567689
<mup> Bug #567689: Have a deterministic way to check OOPS generation in tests. <Launchpad Foundations:New> <https://launchpad.net/bugs/567689>
<adeuring> kfogel: sorry, could we delay the chat until the LP reviewer meeting finishes?
<jtv> kfogel: oh good more mail, just what I needed  :)
<kfogel> adeuring: sure!  just ping me here when ready
<adeuring> I'm bad in multitasking ;)
<kfogel> adeuring: np
<adeuring> kfogel: ok, I'll ping you
<kfogel> jtv: hey, want me to unsub you?
<kfogel> jtv: oh wait, I probably can't do that...
<kfogel> jtv: (hmmm, asymmetry in the UI there...)
<jtv> kfogel: I think I'll unsubscribe myself.  Bjorn is right, but I have no _particular_ interest in seeing this through.
<mrevell> intellectronica, wrt you concern ... I get asked that pretty much every time I document something in this level of detail, and I don't have an answer other than that I hope that my efforts to speak regularly with the team leads will mean I pick up on such changes. With so many potential changes, I'm not sure there's a way of tracking them all.
<kfogel> jtv: ok sorry about that
<intellectronica> mrevell: sounds like quite a problem to me. one thing i think is worth doing is adding reminders to update the documentation in the code and in the doctest documenting bug heat. i can help you do that. other than that i guess your alertness is the best we've got :)
<jtv> kfogel: no worries... is the test itself fixed now?
<intellectronica> and of course the alertness of anyone working on bug heat
<mrevell> That's a great suggestion, thanks intellectronica. Your help adding those reminder would be really useful. What would you suggest?
<mrevell> SOmething in bugheat.py, presumably.
<kfogel> jtv: no, I have not fixed the test.  I don't _think_ anyone else has.  I would like to.  I have some kind of urgent stuff on my plate.  On the other hand, this isn't so hard to fix.  Sigh :-).
<kfogel> jtv: it'll be my bonus today if I can get this other stuff done
<jtv> kfogel: don't leave it on your plate too long or someone'll eat it
<intellectronica> mrevell: something like "# Don't forget to change the documentation of heat calculation in /path/to/file.html if the implementation changes". i'll find the relevant places for you (or i can just give you a patch).
<mrevell> intellectronica, At the risk of sounding lazy, a patch would rock :)
<intellectronica> mrevell: ok, but don't be surprised if this is reflected in your 360 review!
<kfogel> watching mrevell and intellectronica escalate :-)
<mrevell> Haha
<mrevell> intellectronica, Who says I'll ask for your input? :) Okay, seriously, if you have time I'd be interested in learning where would be the best place to do this, rather than just getting a patch.
<kfogel> mrevell: I was assuming the place where the bug-heat.html doc points to?
<mrevell> kfogel, Yeah, that's what I thought. I was thinking maybe in the comment on the BugHeatCalculator class. Sound right intellectronica?
<intellectronica> mrevell: yes indeed. also i think there's a doctest somewhere. let me find it for you.
<intellectronica> mrevell: actually, it's a unit test. lib/lp/bugs/scripts/tests/test_bugheat.py (so a python comment there too)
<mrevell> Ah, thanks intellectronica. I'll update the branch. Before I do that, can you tell me more about you concerns wrt the table approach? Is it misleading?
<deryck> intellectronica, mrevell -- did either of you have specific spots for me to look at, or just a general glance over the doc?
<intellectronica> mrevell: no, in fact, i think it's too detailed. i'm still of the opinion that most users shouldn't care much about the underlying algorithm for bug heat, and that the help we want to give them is by abstracting away from it a bit and just explaining what they can expect (with a link to the code for those geeky users that really want to know how it works).
<mrevell> deryck, I just want to make sure that the help doc (lib/lp/bugs/help/bug-heat.html or https://pastebin.canonical.com/31061/) is accurate.
<intellectronica> deryck: mainly what i just described
<deryck> intellectronica, ah, ok.  maybe an overview with a link to the code is ok.  but remember some power users will want to work out exactly what the heat for a certain bug is.
<deryck> intellectronica, I don't mind this detailed description personally.
<adeuring> kfogel: I'm ready
<intellectronica> mrevell: but i accept in advance that i may be in a minority here, and if you prefer to have it spelled out then at the very least i can say that it's accurate and well presented
<kfogel> adeuring: ok, let me get headset on
<deryck> mrevell, we do actually display the number in the tooltip for the flames currently.
<kfogel> intellectronica: think of it as a way to offload questions -- the minority of users who *do* care will now have something to look at, and not bug us :-).
<kfogel> adeuring: one sec, setting up some stuff
<adeuring> kfogel: np
<mrevell> deryck, Ah, I thought we were removing that. I'll correct that, thanks.
<mrevell> intellectronica, I don't see the value in not explaining it. I can't imagine too many people wanting to game the system. I do think that curious people will want to understand how it works and that many of those will be unwilling or unable to read the Python.
<mrevell> intellectronica, But I'm not in the bugs team, so I defer to you guys.
<kfogel> adeuring: just for context: https://pastebin.canonical.com/31062/  (query you dug up for me the other day)
<kfogel> adeuring: ready
<deryck> mrevell, intellectronica -- I understand intellectronica's concerns for the average user, but I think adding this help doc is mostly for the advanced users. :-)  So I would describe it completely.
<intellectronica> mrevell: toss a coin :)
<intellectronica> there you go
<mrevell> heh
<mrevell> Okay, so I'll add the comments reminding people that the help needs updating if the calculation changes.
<deryck> so I like the mrevell's doc here is general to start with -- the normal user will ready the first few lines and bail.  but goes into some detail throughout.
<mrevell> And also remove the inaccurate thing about not displaying the actual number.
<deryck> yup, that's my only comment
<mrevell> Thanks deryck
<mrevell> intellectronica, So, adding a link to the flame images. Is that straightforward?
<intellectronica> mrevell: should be, yes. let me find for you the place where it's rendered
<kfogel> adeuring: https://pastebin.canonical.com/31064/
<intellectronica> mrevell: see bugtask_heat_html in lib/lp/bugs/browser/bugtask.py
<kfogel> adeuring: you're fading
<mrevell> intellectronica, Thanks
<intellectronica> mrevell: yer welcome
<henninge> allenap: Hi!
<allenap> henninge: Hi!
<henninge> allenap: I just saw that you edited the PythonStyleGuide today about  multiline function definitions.
<henninge> I just found out that you just moved those line.
<henninge> ;-)
<allenap> henninge: Yes, I didn't change the rule, just moved it and added a comment.
<henninge> allenap: I just wrote a similar piece as was discussed last week, so I'll delete that old incarnation of the rule. Just so you know. ;-)
<henninge> allenap: https://dev.launchpad.net/PythonStyleGuide?action=diff&rev2=12&rev1=11
<allenap> henninge: Ah, jolly good :)
<allenap> bac: I have two time zones set in gcal, but I can't seem to actually use them anywhere. Am I missing something?
<bac> allenap: perhaps.  i have mine set to show UTC and US/East but i have my preference set to UTC so scheduled meetings don't move around with DST
<allenap> bac: You can't set or change the time zone of a meeting, it's always in the primary time zone?
<bac> allenap: i think that is right
<allenap> bac: Thanks.
<salgado> allenap, who would be the best person to help me getting lp.bugs.scripts.tests.test_checkwatches to pass on python2.6?  https://dev.launchpad.net/PythonMigrationStatus#LaunchpadZopelessLayer is where it fails
<allenap> salgado: Probably me.
<salgado> allenap, would you have some time now?  or maybe just some pointers for me to start?  I currently have no idea what could've caused that
<allenap> salgado: I'll take a look.
<salgado> allenap, I'm stepping through the failing code path and it seems to be making requests to bugzilla.gnome.org.  am I misunderstanding something or is that expected?
<allenap> salgado: That should be stubbed out, so something's going wrong there.
<allenap> salgado: I'm still waiting for my branch to build :)
<salgado>   File "/home/salgado/devel/launchpad/python2.6/lib/lp/bugs/externalbugtracker/xmlrpc.py", line 101, in request
<salgado>     request.get_full_url(), he.code, he.msg, he.hdrs)
<salgado> ProtocolError: <ProtocolError for http://bugzilla.gnome.org/xmlrpc.cgi: 503 Service Temporarily Unavailable>
<salgado> ------------
<salgado> allenap, that's what I got when I aliased bugzilla.gnome.org to my IP address
<salgado> so I guess the stubbing doesn't work on 2.6
<allenap> salgado: Cool.
<allenap> salgado: xmlrpclib changed quite a bit between 2.4 and 2.5, so I wouldn't be surprised if it has changed again.
<deryck> allenap, so I'm not confident of my test for bugnotification for subscribe someone else on the view anymore.  I was doing select * from bugnotification.
<deryck> allenap, but I reverted to devel before my change and the view doesn't create an entry there.  but I know it worked before, since someone subscribed me via the view and I got notified.
<allenap> deryck: Have you seen bugnotification-sending.txt? It uses get_email_notifications() to see what has been sent. Perhaps that's of use?
<deryck> allenap, yeah, the cronscript uses that and passes in an IBugNotificationSet.  I forgot that.  So that means the bugnotification table has to be populated.
<deryck> i.e. IBugNotificationSet is just a set from bugnotification, no?
<deryck> yeah, it is.  he says answering his own question. :-)
<allenap> deryck: Cool :) Sorry, I've got too many things stacked up in my head to be very useful right now.
<deryck> allenap, no worries.  Chatting out loud helps. :-)
<kfogel> BjornT: in https://bugs.edge.launchpad.net/malone/+bug/130902/comments/5 you write that there should be a header in bug notification emails indicating the reporter.  But I don't see any such header in (e.g.) notifications I receive for bug 558657, even though I am the reporter.  What header were you thinking of?
<mup> Bug #130902: Notifications don't tell you whether you're a bug's reporter <email> <ubuntu-qa> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/130902>
<mup> Bug #558657: mouse usage causes Xorg CPU usage to spike, and mouse pointer becomes less responsive <apport-bug> <i386> <lucid> <lucid-upgrade-testing> <linux (Ubuntu):Incomplete> <linux (Ubuntu Lucid):Incomplete> <xserver-xorg-video-nouveau (Fedora):Unknown> <https://launchpad.net/bugs/558657>
<salgado> allenap, I can't seem to find where the stubbing occurs.  I can clearly see checkwatches.updater.externalbugtracker.get_external_bugtracker being monkey patched, but that doesn't seem to be what I'm looking for, is it?
<allenap> salgado: Mmmm, neither can I. I'm about to ask gmb.
<kfogel> BjornT: (not that it should matter whether I'm the reporter or not -- every notification anyone receives should indicate the reporter)
<gmb> Whut?
<allenap> gmb: A test for bug 496988 is failing in the python2.6 branch that salgado's looking at.
<mup> Bug #496988: KeyError in checkwatches cause the script to abort <bugwatch> <current-rollout-blocker> <oops> <Launchpad Bugs:Fix Released by gmb> <https://launchpad.net/bugs/496988>
<gmb> Ahhhh
<allenap> gmb: It's actually contacting the GNOME Bugzilla.
<gmb> Now then, someone asked me about this last week.
<allenap> gmb: And I have no idea why.
<gmb> rockstar perhaps; I don't remember.
<allenap> gmb: I mean, I have no idea why it works in 2.5.
<gmb> OH!
<gmb> It was wgrant that asked.
<gmb> And ISTR it's because something changed in the way the XML-RPC code works from 2.5 to 2.6
<gmb> salgado, allenap: Lemme check my logs.
<salgado> gmb, very likely to be wgrant; he's helping us get LP to run on 2.6
<allenap> gmb: When salgado asked I assumed that remote calls, i.e. XML-RPC, were being stubbed out, but they're not.
<allenap> gmb: That was my first thought.
<kfogel> BjornT: oh, I think I understand: you meant that it would be good for us to implement this, not that it *has* been implemented
<allenap> gmb: But I don't think it's the case.
<gmb> Buggeration. I had logging turned off in xchat. Let me check the proxy logs...
<salgado> gmb, I confirmed the test is hitting bugzilla.gnome.org by aliasing that host to localhost and seeing the test fail with a service unavaliable error instead of https://dev.launchpad.net/PythonMigrationStatus#LaunchpadZopelessLayer
<BjornT> kfogel: right, we should add such a header :)
 * gmb has a log; cleaning it up now
<kfogel> BjornT: agreed
<gmb> allenap, salgado, Log of my conversation with wgrant: https://pastebin.canonical.com/31077/
<gmb> The solution I suggested was to monkeypatch get_external_bugtracker
<gmb> salgado, But I think there was some suggestion that we'd have problems with headers and XMLRPC in 2.6. I'm a bit fuzzy on the remembering though.
<salgado> gmb, I'd like to find what's causing the tests to connect to bugzilla.g.o on 2.6.  this might be affecting other tests that are not failing just because on my system they can access bugzilla.g.o, but if that's the case they'll fail when run on buildbot
<gmb> salgado, What's causing it is a shoddy test. The real question is: why doesn't it happen in 2.5?
<allenap> gmb: I'm going to guess that buildbot can reach gnome-bugs.
<gmb> allenap, Horrible as it is, that sounds probable.
<allenap> gmb: That's why it's working on 2.5. The header thing is because 2.6 is stricter.
<gmb> In which case it's just a shoddy test.
 * salgado tries to confirm that hypothesis
<gmb> brb
<salgado> allenap, gmb, confirmed.  on 2.5 it also hits bugzilla.g.o
<allenap> salgado: Here's a fix http://pastebin.ubuntu.com/419909/
<gmb> Right
<salgado> allenap, r=me, and I'll be happy to land it on your behalf if you'd like
<allenap> salgado: Do you want to land it, or shall I?
<allenap> salgado: Yes please :)
<salgado> allenap, will do after lunch.  thanks!
<maxb> gosh. We're dangerously close to actually being able to run on py2.6
<allenap> salgado: A better fix: http://paste.ubuntu.com/419914/ <-- the setUp() and tearDown() for TestCheckwatchesWithSyncableGnomeProducts and TestCheckwatchesWithoutSyncableGnomeProducts had become the same, so I collapsed them together.
<salgado> allenap, cool, will use that one
<james_w> yay: http://paste.ubuntu.com/419962/
<james_w> not the most impressive demonstration though :-)
<mars> james_w, you get a +2 for creative script output, in the proudest of hacker tradition :)
<james_w> http://jameswestby.net/scratch/offline-lp.ogv <- that's a more effective demonstration
<jml> james_w, awesome!
<james_w> jml: all done with twisted for extra awesome!
<jml> james_w, is this your twisted launchpadlib thingy?
<james_w> yeah
<jml> james_w, I should really have a play with that.
<james_w> I wrote a caching wrapper for Agent, plus an ICache implementation over desktopcouch, and put them together for the demo
<jml> james_w, it stores the data in couch?
<james_w> it's all local at the moment, as it requires a patch to twisted, and a bunch of other experimental stuff
<james_w> yeah
<jml> james_w: still, very cool.
<jml> james_w, can I help you land that patch to Twisted?
<james_w> it's not my, it's exarkun's
<james_w> jml: you can though, it's awaiting review :-)
<jml> james_w, ticket number?
<bigjools> james_w: that's rather nice!
<james_w> 4023
<jml> james_w, thanks. I've just waded through the discussion. Time to look at the code!
<ehmdotmicro>  I am currently unable to log into staging.launchpad.net. A bug has been filed here: https://bugs.launchpad.net/canonical-identity-provider/+bug/566778. Can anyone help?
<mup> Bug #566778: login.staging.launchpad.net crashes on login <Canonical SSO provider:New> <https://launchpad.net/bugs/566778>
<jml> james_w, review done :)
<jml> leonardr, I think I've let some stuff that you asked for slide.
<jml> leonardr, lackwit that I am, I've forgotten what it was
<leonardr> jml: we were going to talk about web service performance?
<jml> ahh yes.
<jml> leonardr, how about I book a time for a call tomorrow? are you working regular East Coast hours?
<leonardr> jml: yes, i usually get up a little early
<jml> leonardr, you don't use google calendar, I take it
<leonardr> jml: not really, but if it's easier for you to schedule something with my google username i can write it down on a piece of paper
<jml> leonardr, heh, no, that's fine :)
<jml> leonardr, 1500UTC ok for you?
<leonardr> that should be fine
<leonardr> the latest is here: https://dev.launchpad.net/Foundations/Webservice/Performance
<leonardr> lifeless said on irc earlier today that he had some ideas
<jpds> Are bug assignees treated like subscribers?
<jpds> sinzui: I seem to recall you talking about this a few days ago...
<jml> jpds, they get an extra serving of stale bread with their gruel and water
<jml> leonardr, cool. I'll make sure I read up before then.
<jml> leonardr, given TZ, it'll be easier for you to talk directly w/ lifeless
<leonardr> jml, did you or lifeless move? i thought you two were nearby
<jml> leonardr, I live in London
<jml> leonardr, since September :)
<leonardr> all is clear now
<jml> leonardr, obviously you don't blogface my tweetermail feed
<leonardr> i prefer to spacetweet
<jml> leonardr, I hear all the cool kids atomdent
<jml> leonardr, anyway, that's in my calendar, so it will happen.
<leonardr> can't spacedent from a 64-character alphanumeric beeper!
<sinzui> jpds, no, an assignee is not an actual subscriber, so assigning a private bug to a person is cruel
<jpds> sinzui: Thanks.
<sinzui> jpds, well Launchpad is cruel to put users in an impossible situation
<adeuring> kfogel: https://pastebin.canonical.com/31112/
<adeuring> (untested...)
<kfogel> adeuring: well, then I'll test it!
<kfogel> adeuring: thanks
<kfogel> adeuring: when the person is a team, I can just put the team name for 'xxxxxxxxxxxx' and it should all still work, right?
<adeuring> kfogel: regarding our disscussion about multiple bug task status changes between completed/ in progress: We should already get more than one result with the existing queries, the only thing we have to do is to find the shortest and longest times
<kfogel> adeuring: ah, beautiful, gotcha
<adeuring> kfogel: yes, though i think you shold try first with a person name
<kfogel> adeuring: oh, I will
<adeuring> kfogel: I think for teams, bug comments won't make much sense. but the other queries should be fine
<kfogel> adeuring: yeah.  a team can own, and be assigned to, and subscribe to, right?
<adeuring> right
<kfogel> adeuring: I suspect "subscribed to" is the most important relation to, here.  when a team visits ~teamname/+patches, all (?) the bugs that come back are ones that team is subscribed to
<kfogel> right?
<adeuring> right
<kfogel> adeuring: heh, it got 0 results for 'kfogel' of course, but that's only b/c no bugs *with patches* assigned to me right now.  I'm visiting ~kernel-bugs/+patches now to get some better usernames
<kfogel> adeuring: so, hmm, when I do the first query (person assignee) with 'mgedmin' as the person, why doesn't bug 47775 show up?  It has a patch, and one of its bug tasks was marked as Fix Released *after* the patch...
<mup> Bug #47775: [dapper] xrandr freezes the system (radeon, MergedFB) <ati> <xorg> <xserver-xorg-driver-ati:Fix Released> <Ubuntu:Invalid> <xorg (Ubuntu):Fix Released by ubuntu-x-swat> <xserver-xorg-video-ati (Ubuntu):Fix Released by ubuntu-x-swat> <xorg (Ubuntu Dapper):Confirmed for ubuntu-x-swat> <https://launchpad.net/bugs/47775>
<adeuring> kfogel: mgedmin is not an asignee for the tasks of this bug, or am ii missing something?
<kfogel> adeuring: oh duh, he's reporter, my fault
<kfogel> adeuring: sorry
<james_w> jml: thanks
<kfogel> adeuring: works for ~ubuntu-x-swat.  33 rows returned in 4386.230 ms, fwiw.
<adeuring> kfogel: great
 * thumper waits for wgrant
<wgrant> thumper: Hm?
<thumper> wgrant: we need to update the buildd thingy with a new bzr-builder version
<thumper> wgrant: and none of us on the code team know what to do
<thumper> wgrant: I'm guessing you might
<wgrant> thumper: It just relies on a new package being in the archive.
<wgrant> There is no solution for that at the moment -- the though in Wellington was that we'd have a special PPA.
<wgrant> But it's not there yet.
<thumper> wgrant: I don't grok it
<thumper> we have new lp code that is needed I believe
<thumper> to make use of the changes to bzr-builder
<wgrant> Oh.
<wgrant> So not a new bzr-builder, but new stuff in lib/canonical/buildd?
<thumper> we have a branch that adds this
<thumper> both
<wgrant> The former you cannot do.
<thumper> former what?
<thumper> and why can't we do it?
<wgrant> You can't upgrade bzr-builder.
<thumper> why?
<wgrant> Because you cannot upload to the Ubuntu primary archive, and there is no other archive that is used by all recipe builds.
<thumper> can't we just have it installed on the xen builder image?
<wgrant> It needs to be installed inside the chroot, which is downloaded from LP each time.
<mwhudson> does bzr-builder run in the chroot?
<mwhudson> right
<wgrant> So, we are probably going to quickly hack in support for a celebrityish PPA which recipe builds will get. Then when we need a new bzr-builder, someone just has to push it into that PPA, and recipe builds will see it.
<mwhudson> is bzr-builder installed via apt-get for recipe builds today?
<wgrant> mwhudson: It is.
<mwhudson> huh, i had no idea
<wgrant> See lib/canonical/buildd/buildrecipe
 * mwhudson sees
<wgrant> Huh.
<wgrant> https://bugs.launchpad.net/bugs/567652 was solved quite remarkably.
<mup> Bug #567652: Launchpad Login System is not FOSS <ubuntu-community:Fix Released> <https://launchpad.net/bugs/567652>
<wgrant> ... except accessing the private branch 403s.
<wgrant> Er, public branch.
<mwhudson> um
<wgrant> (<Branch u'~canonical-isd-hackers/canonical-identity-provider/2.x-trunk' (326293)>, 'unique_name', 'launchpad.View')
<wgrant> Hum.
<mwhudson> i wonder if it's stacked
<wgrant> I was thinking that, but then that Unauthorized doesn't make much sense.
<wgrant> Oh, right, I guess it might revoke launchpad.View in that case.
<mwhudson> yeah it's stacked
 * mwhudson fixorates
<wgrant> Thanks.
<mwhudson> wgrant: try now
<wgrant> mwhudson: It works! Thanks.
<wgrant> I wonder if that deserves a warning on the branch page, though...
<mwhudson> public stacked on private?
<mwhudson> it's very unlikely to be the thing you want
<wgrant> Exactly.
<thumper> builders suck
<thumper> soyuz makes me want to cry
<wgrant> thumper: It's not Soyuz any more. It's your problem now too :P
<wgrant> thumper: What are they doing to you?
<thumper> wgrant: I'm comfortable refactoring the datamodel for code where necessary
<thumper> wgrant: but soyuz has *so* much that needs to be fixed
<wgrant> eg?
<wgrant> The data model is being redesigned at the moment, you know?
<thumper> no, I didn't know
<thumper> builds primarily
<wgrant> noodles is currently turning http://people.ubuntu.com/~wgrant/launchpad/buildfarm/current-build-model.png into http://people.ubuntu.com/~wgrant/launchpad/buildfarm/new-build-model-again.png.
<wgrant> What do you see as wrong with the current one?
<mwhudson> wgrant: https://bugs.edge.launchpad.net/launchpad-code/+bug/568128
<mup> Bug #568128: the page for a public branch stacked on a private one should shout at you <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/568128>
<james_w> Now we're getting somewhere: http://jameswestby.net/scratch/offline-lp2.ogv
<wgrant> mwhudson: Perfect. Thanks.
<wgrant> thumper: So, if you have any specific concerns, raise them now before we design the model badly.
<thumper> wgrant: yes, just make it not suck
<wgrant> ...
<mwhudson> specific advice is always the best!
<thumper> wgrant: please unify builds and jobs
<wgrant> thumper: Done.
<wgrant> Well, in progress.
<thumper> \o/
<wgrant> Did you look at the diagrams I linked to?
#launchpad-dev 2010-04-22
<thumper> no
 * thumper is pretending to be buys
<thumper> busy even
<abentley> wgrant, SourcePackageRecipeBuildJob seems like it could be eliminated by putting a "job" column on "SourcePackageRecipeBuild"
<wgrant> abentley: SPRBJ is gone in the new model: http://people.ubuntu.com/~wgrant/launchpad/buildfarm/new-build-model-again.png
<abentley> wgrant, Where is Job?
<wgrant> abentley: No longer involved in the build farm.
<abentley> wgrant: please unify builds and jobs
<wgrant> abentley: The current model is reasonably close to that...
<abentley> By "current", you mean "without the changes shown in the diagram"?
<wgrant> Right, the one that was implemented in Wellington.
<wgrant> http://people.ubuntu.com/~wgrant/launchpad/buildfarm/current-build-model.png
<wgrant> Why do you want Job involved?
<wgrant> It's not awfully useful.
<abentley> wgrant, I want common data to be represented in a common place in a consistent way, so that I can view it and address it by Job.id.
<wgrant> I guess we could fairly simply replace some of BFJ's columns with delegations to Job.
<wgrant> At least the other classes no longer have to care.
<wgrant> Hm, so most of the columns in the job table aren't in IJob. Does that mean that they're not used anywhere, so Job looks less suitable than it actually is?
<wgrant> abentley: What is a Job's lifetime?
<wgrant> Does it persist after it completes?
<abentley> wgrant, yes.
<wgrant> Hrm hrm.
<abentley> wgrant, what are the columns whose lack of exposure makes Job seem less suitable?
<wgrant> Sounds like you need to argue with Soyuz.
<wgrant> abentley: All that stuff like reason, next_report_due, scheduled_start, lease_expires, progress, attempt_count, max_retries...
<abentley> wgrant, some of the columns you mention are exposed.  Others haven't been exposed yet due to YAGNI.
<abentley> wgrant, if there's now a need, we could expose them.
<wgrant> abentley: No, no, my point was that it makes it look more specific than it actually is.
<wgrant> Their existence in the schema, that is.
<abentley> wgrant, I see.
<abentley> wgrant, So, reason, next_report_due, progress, attempt_count and max_retries are currently unused to my knowledge.
<wgrant> abentley: attempt_count is actually used, but only internally.
<abentley> wgrant, we record it, but I don't think we ever read it.
<wgrant> abentley: Right.
<abentley> scheduled_start is optional; if NULL, we attempt it as soon as we can.
<thumper> wgrant: yeah, I agree with abentley that BuildFarmJob should defer many columns to Job
<thumper> wgrant: and it should be a job type
<thumper> also
<thumper> it may well make sense to have a json_data blob on the BuildFarmJob table too for extra meta-data that is never queried against like the BranchJobs
<thumper> it may make TranslationTemplateJob and SourcePackageRecipeJob as unnecessary
<wgrant> thumper: Sounds like you need to talk to noodles/bigjools about this.
<wgrant> None of that has been implemented yet, so it can be easily changed.
 * thumper sighs
<thumper> wgrant: how to we make the builders add ppa:dailydebs-team/bzr-builder to its sources?
<thumper> wgrant: the second thing we'd need to do is to get an updated bzr-builder in that ppa
<mwhudson> oh yay
<mwhudson> ec2 test is completely broken
<wgrant> thumper: Wellington discussion suggested that we would add an attribute to IDistribution specifying an extra archive to include for recipe builds.
<wgrant> But it hasn't been discussed in three months.
<wgrant> If so, that's really really easy to do -- we just need to make a decision.
<thumper> wgrant: oh kay...
<thumper> wgrant: feel free to reply to the email to remind everyone
<wgrant> thumper: Replied.
<wgrant> thumper: Did the copy of the email that went directly to you have more than just the list CC'd? I replied to all, and the other addresses were in the email that left my laptop... I'm wondering whether it was mailman or a braindead uni SMTP server that stripped the extra CC addresses.
<thumper> wgrant: yes it did
<wgrant> Why, then, does the copy on the list not... grr.
<thumper> wgrant: because the list copy tries to determine if the people you sent it to are on the list
<thumper> wgrant: it is a feature:)
<wgrant> thumper: Ah, like the "feature" where it doesn't send me a copy through the list if I'm addressed directly?
<thumper> something like hat
<thumper> s/hat/that/
<cody-somerville> Soyuz is acting up.
<wgrant> cody-somerville: What's it doing?
<wgrant> Or not doing?
<mwhudson> cody-somerville: best to say "losa" when you say that?
<mwhudson> or wgrant
<cody-somerville> builds for multiple packages are getting rejected because it can't find the source package
<spm> logs?
<cody-somerville> oh wait, maybe the packages did get superseded but the error messages are very ugly.
<wgrant> That error message is ugly, yes.
<wgrant> But normal.
<cody-somerville> ah, false alarm.
<cody-somerville> Got jumpy because I got so many emails about it
<spm> we did just have a glitch on apache/ppa due to a new cronjob that was ... um.... *badly* behaved. so possibly cause and effect there.
<cody-somerville> Looks like just a sloppy engineer in this case
<spm> heh
<wgrant> spm: My new cronjob? :/
<wgrant> Did it eat all of germanium's RAM for lunch, or something else?
<spm> wgrant: if it's called parse-ppa-apache-access-logs.py ? yes.
<spm> it was at 2.5Gb RSS when I had to kill it as it had caused apache to be swapped out
<wgrant> Argh.
<wgrant> Anyway, /me -> exam.
<spm> anyone who says ram is cheap at this point, will get a smacked bottom. :-P
<spm> good luck!
<mwhudson> spm: is it cheaper than disk? :)
<StevenK> spm: RAM *is* cheap ... to allocate
<thumper> spm: I think RAM is cheap
<thumper> spm: how much to you need?
<spm> thumper: I think RAM is cheap, therefor I am RAM?
<thumper> spm: WFM
<adeuring> good morning
<jtv> hi adeuring
<adeuring> hi jtv!
<mrevell> Hello
<bigjools> wgrant: hello
<bigjools> dunno if you spoke to spm but FYI, the log parsing script gobbled >2.5GB RSS so had to be stopped.
<wgrant> bigjools: I saw that, yeah. I suppose the librarian one would do that too if it had a huge volume of logs too.
<wgrant> Not sure what to do, unless we convince it to stop after some millions of lines.
<wgrant> The comment in the librarian parser suggests store._cache.clear().
<wgrant> But I doubt that's the problem here.
<jml> good morning Launchpadders?
<bigjools> wgrant: salgado said he'd fixed the issue so you might want to catch up with him
<bigjools> wgrant: or you could copy the publisher process_in_batches stuff
<wgrant> bigjools: It's either the dict getting fricking huge, or StupidCache being really stupid. I don't know which.
<bigjools> yes
<wgrant> bigjools: Do we have a traceback, or was it killed harder than that?
<bigjools> wgrant: dunno, I didn't see one, I think they just killed it when it got big as apache was dying
<wgrant> bigjools: Do you know how big the logs tend to be? I really have no idea what sort of size we're talking about here.
<jml> james_w: which one of you should I be talking to?
<bigjools> wgrant: otp right now, will check in a bit
<jml> james_w``: hello?
<wgrant> bigjools: OK, thanks.
<james_w> hi jml
* mrevell changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 2 of 10.04 | PQM is open | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in irc://irc.freenode.net/#launchpad-reviews | Use http://paste.ubuntu.com/ for pastes
<mrevell> intellectronica, Hi, got five minutes?
<intellectronica> mrevell: sure
<mrevell> Thanks intellectronica. I wanted to ask you about adding a pop-up help link to the bug heat flames, wherever they're displayed.
<mrevell> intellectronica, I can dive in and take a look at the templates first, if you prefer.
<intellectronica> mrevell: i thought we already discussed it yesterday? any difficulties?
<intellectronica> i'm also happy to add the link myself if you prefer that
<mrevell> intellectronica, Sorry, yeah, you directed me to the right place. If I make the change, could you take a look at my diff, please? It's my first change of this kind.
<intellectronica> mrevell: of course
<mrevell> Thanks intellectronica -- http://pastebin.ubuntu.com/420319/
<intellectronica> mrevell: the code looks fine. does the result look ok?
<mrevell> intellectronica, Thanks. An apt-get autoremove seems to have just wiped out launchpad-developer-dependencies; not sure why. Just reinstalling everything I need to make run :)
<intellectronica> mrevell: whoops
<jtv> wgrant: are the slave build cookies now _only_ checked when rescuing a lost builder?
<wgrant> jtv: I believe so.
<jtv> wgrant: any idea how we'd simulate verification for Q/A?
<wgrant> jtv: You could get two builds running on dogfood, then swap the BQ.builder values in the DB.
<jtv> wgrant: nasty
<wgrant> Or you could possibly use a fake builder.
<jtv> wgrant: sorry for the long silences; some big distractions going on.
<deryck> intellectronica, hi.  The board suggests bug 567375 has been merged, but the MP doesn't.  Has it merged?
<mup> Bug #567375: Degrade bug heat daily <story-bug-heat> <Launchpad Bugs:In Progress by intellectronica> <https://launchpad.net/bugs/567375>
<intellectronica> deryck: i think it has. at least, i've got a success email, let me check.
<intellectronica> deryck: damn, looks like it didn't, so something must have happened between EC2 and the submission. will merge now.
<deryck> intellectronica, ok, cool.  Thanks
<deryck> intellectronica, and then the bugs remaining would be the activity points idea and then garbo-daily to garbo-hourly, right?
<intellectronica> deryck: yes, i've just submitted the last branch for review.
<deryck> intellectronica, ah, nice!  Can you add cards to the board for these two?  Are am I just missing where they are?
<intellectronica> deryck: sorry, no, i need to create them. let me just get that review going and that branch merged and i'll add them
<deryck> intellectronica, ok, great thanks.  Sorry to throw so many at you.  Just house cleaning before being on leave tomorrow. :-)
<intellectronica> no worries. should have really done that when creating the bugs. old dog etc'...
<mars> mrevell, should the underline problem be visible on launchpad.dev Bug #1?
<mup> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Invalid> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <OpenOffice:Invalid by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:Incomplete by sabdfl> <ubuntu-express (Ubuntu):Invalid by jahyire2006> <Ubuntu Jaunty:In Progress
<mars> argh
<mrevell> mars, No. The underline shouldn't appear on any of the bug flame images.
<mars> mrevell, ok, what page should I view to see the problem?
<mrevell> mars, I'm sorry. I misunderstood. Yes, if you visit bug one on launchpad.dev you'll see the dotted underline on the flame icon.
<wgrant> salgado: Did you have python-tdb installed when running the test suite?
<wgrant> salgado: That causes those import errors.
<wgrant> '#
<wgrant> Do not have python-tdb installed, which otherwise causes bzr-hg and bzr-git to behave in ways the tests do not expect. '
<salgado> wgrant, all I have is libtdb1
<wgrant> salgado: Your sourcecode bzr-git is up to date?
<salgado> crap, I missed that (and a few others) because I ran my hack to update sourcecode/ branches under lib/
<salgado> wgrant, thanks for catching that; I'll update the wikipage
<wgrant> AFAIK everything is now fixed apart from the valid_absolute_url thing.
<wgrant> Although I didn't see the fix for the bugtracker failure.
<wgrant> Ah, there.
<wgrant> So, yes, apart from the valid_absolute_url issue it all looks good.
<wgrant> Yay.
<mars> mrevell, I do not see the underline on this branch.
<mars> mrevell, just in my team standup call, and I have something high priority I need to switch to.  Perhaps someone else can help squish it?  sinzui and noodles775 are also good with CSS.
<mrevell> Thanks for looking mars
<mrevell> Do you have a moment noodles775?
<mars> no problem, sorry I can't help more
<noodles775> mrevell: sure, I'm just finishing off a CP-review. Say in 2 mins?
<mrevell> noodles775, top of the hour okay for you? That's after my stand-up.
<noodles775> mrevell: sure.
<mrevell> thanks noodles775 :)
<noodles775> mrevell: I'm guessing you've got uncommitted changes locally in your branch? I've merged it from LP, but it just adds the help file without linking the bug heat to it, afaics?
<mrevell> noodles775, Oh, odd. I thought it had pushed, lemme check
<mrevell> noodles775, I've just pushed a new version up
<noodles775> Great, looking now...
<noodles775> mrevell: and you want it just without the underline, is that right?
<noodles775> (well, the dotted bottom border from a.help)
<mrevell> noodles775, Yeah, no underline at all.
<mrevell> noodles775, I tried playing with a style="text-decoration: none" on the <a> and the <img> but to no avail.
<noodles775> mrevell: yeah, inspecting it (using the chromium debugger) shows that a.help is actually adding a bottom-border: 1px dotted...
<noodles775> So you might have more luck with style="bottom-border..."
 * noodles775 tries.
<mrevell> Ahhh
<noodles775> er, border-bottom ;)
<noodles775> mrevell: yep, that works...http://pastebin.ubuntu.com/420447/
<mrevell> noodles775, Thanks, just got it up here on my local instance too :) Cheers!
<noodles775> Great.
<mrevell> noodles775, Is that acceptable, adding an inline stlye like that?
<noodles775> mrevell: From my point of view, if it is a complete exception for a help link to not have the normal style, then I would rather it here than in the stylesheet (sinzui might differ?). On the other hand, something general like a .no-border class could be reusable?
 * noodles775 checks to see if something like that exists already.
<sinzui> I think exceptional rules do no belong in a global stylesheet. I also question why we need exceptions since the user has no context for what the presentation meens
<sinzui> means
<mrevell> sinzui, I'm not sure what you mean by the user having no context for what the presentation means.
<sinzui> mrevell, We know a green link is a js-action because it is used consistently in launchpad. If I have never seen a presentation style, I do not know what to expect.
<noodles775> mrevell: why do you want the exception here? Is it just because the bug heat icon looks ugly with the underline? Or would images in general look ugly with an underline, in which case http://pastebin.ubuntu.com/420455/ would also work.
<noodles775> s/images in general/images within a help text link in general/
<mrevell> noodles775, When Deryck and I were discussing the implementation we were concerned that the underline would be overly distracting; the link is of secondary importance and not directly related to the purpose of the flames, so we felt too much attention shouldn't be drawn to their being a link.
<sinzui> mrevell, , noodles775, right. No image should be underlined and we have rules for it. are the rules in the css bad, or is the markup bad
 * mrevell looks at the pastebin
<noodles775> sinzui is right in that you can't tell it's a help link without the underline until you then hover over it, but as you said, that's ok here.
<noodles775> sinzui: it's a border-bottom that is used by a.help (see the previous paste).
<mrevell> noodles775, Your suggestion in the pastebin would work very well, actually, as I wouldn't want the dotted underline on any pop-up help image.
<noodles775> Great.
<mrevell> noodles775, The only other time I can imagine using a help link on an image, and wanting people to be absolutely sure it was a help link, would be with a help icon, so that'd be fine without the underline as I think it's self-explanatory.
<noodles775> Yep.
<mrevell> Thanks noodles775, I'll apply that icing change and then pop it in for review.
<noodles775> k.
<noodles775> oh, mrevell, while you're at it, could you move those help links from style.css into style-3-0.css.in?
<noodles775> s/help links/help styles/
<mrevell> noodles775, sure
<jml> leonardr: hi. I'll be with you in a bit.
<leonardr> hi jml
<jml> leonardr: which voice medium best suits you
<leonardr> jml: i can do mumble or skype
<henninge> danilos: hey, still around?
<henninge> I have an approved branch that is a CP candidate.
<danilos> henninge, yes
<danilos> henninge, have you gotten approval from flacoste as well?
<henninge> I did branch it off production-stable but now I don't know were to put it.
<henninge> danilos: that's what I was wondering.
<henninge> danilos: does it go directly into production-devel?
<henninge> thinking about it ... yes, obviously
<danilos> henninge, yeah, you should land it on production-devel once it's approved
<danilos> henninge, have you ran the full test suite?
<flacoste> henninge: and have you QA-ed it yet?
<henninge> danilos: no, I was going to ec2 land it
<danilos> henninge, if there was no full test run, it's not going to be ready for CP before 2200 UTC
<henninge> danilos: I was not going to CP it yet, I was just asking for the procedure.
<henninge> flacoste: so, to QA it I need to land it on (db-)devel first?
<danilos> henninge, right, it might not make much sense to CP it if we can't make it in time for the language pack generation
<flacoste> henninge: yes
<danilos> henninge, there's always cowboying into staging
<henninge> danilos: right, when does that start?
<flacoste> that also
<danilos> henninge, that starts at 2200 UTC, so I don't think we can make it in time (two full test runs will take ~8h, and CP to loganberry will take some time as well)
<henninge> danilos: oh, I kind of forgot about that ... sorry
<danilos> henninge, I'd suggest you land it in the regular way and I'll let dpm know about it so he can let Lithuanian translators know; he'll tell us when they plan to do next language pack update
<danilos> henninge, we might not need to CP it anymore
<henninge> danilos: could we not short-cut it if it's only loganberry?
<danilos> henninge, how would we cut it short?
<henninge> once it's passed ec2 and QA'ed on staging, cowboy it onto loganberry?
<danilos> henninge, (in general, "no", but I am interested in your idea :)
<henninge> danilos: just to save one ec2 run
<danilos> henninge, huh, it's not that critical an issue
<henninge> danilos: ok, then I am not that worried ... ;)
<danilos> henninge, that would be possible if all hell was breaking loose and things are falling apart; otherwise, let's not even think about doing something like that :)
<henninge> is it possible that ec2 is not working on a production branch atm?
<henninge> I always get this on "ec2 test", right after the instance has started:
<henninge> SFTPError: Garbage packet received
<henninge> instance shutting-down
<james_w> you'll get that if you are using an ec2 script from before the ec2test -> ubuntu user transition, but that's not necessarily the reason
<henninge> james_w: possible, as I said, I have a branch based on production-stable.
<henninge> but actually, tha is not necessary anymoew, might as well merge devel.
<henninge> right, danilos? ^
 * henninge gives up for today
<mrevell> make run is complaining about something annoying, so I'm taking that as a hint to give in for now. See you tomorrow.
<bac> adiroiban: finally(!) your branch has landed
<adiroiban> bac: thanks :)
<bac> adiroiban: np.  sorry it took so long.
<adiroiban> bac: don't worry... from my point of view it was fast , and it was not a critical branch
<maxb> salgado: hi, w.r.t. your valid_absolute_url change on the python2.6 branch - wgrant and I were leaving that unfixed as a reminder that the database constraint needed thought
<maxb> What are your thoughts on this?
<maxb> I think it is pretty horrible that "valid_absolute_url" includes some implicit filtering on schemes
<salgado> maxb, what filtering?
<maxb> The py2.5 behaviour of valid_absolute_url was to only succeed for registered netloc schemes
<salgado> right, and the new one follows the rfc
<maxb> I believe this may have been being (ab)used to constrain file:/// urls to not be entered in the DB
<maxb> or something like that
<salgado> maxb, I think we have more restrictive field validators to take care of that.  we *should* be doing that, at least
<salgado> in the case of DistributionMirror.http_base_url & co, for instance, I'm sure we do
<maxb> announcement.url branch.home_page_url branch.url builder.url distributionmirror.*_base_url productseries.releasefileglob specification.specurl codeimport.url
<maxb> ^ fields using this validator
<maxb> erm, constraint
<salgado> right, I know which ones use that, but my point is that these fields should have the more restrictive validators that may not be trivial to write as DB constraints
<salgado> they should not rely on DB constraints doing their work.  if they do, they're broken
<NCommander> anyone around who can help me figure out how to talk to the LP database properly? I'm having issues writing a converter script for changelogs, and I'm scratching my head on why I'm getting None as a result
<salgado> maxb, I just realized it may not be clear what I meant above.  I was talking about field validators like what you get by using URIField
<salgado> valid_absolute_url is just a safety net; we can't rely on DB constraints for our input validation
<salgado> sinzui, is it known that on https://edge.launchpad.net/udd the page scrolls down to the bottom right after loading?
<sinzui> salgado, I have observed that. It is because of the Packages in Ubuntu portlet
<salgado> yep
<salgado> sinzui, want a bug for it or is there one already?
<salgado> or c) none of the above? ;)
<sinzui> No, I suspect javascript may be in play
<sinzui> salgado, I usually fix the issue by selecting a package. I am waiting for a db review to land the option that lets users say the project is not packaged,
<salgado> sinzui, oh, ok, cool
<sinzui> salgado, while this is annoying behaviour, it has encouraged me to link more that 50 packages in the last month
<salgado> sinzui, yeah, I see the value in it too.  I'd do the same if this project were packaged
<sinzui> yes. my projects are not in ubuntu. I really want to land my fix
<sinzui> salgado, I think the portlet problem is cause by the setFocusByName() call. I think we can disable that. did you report a bug?
<salgado> sinzui, nope.  want me to?
<sinzui> salgado, I'll do it now
<sinzui> bac: do you want me to restart the lp builder that lost the slave
<wgrant> flacoste: Regarding the bzr-builder thing: the builders are virtualized and we run arbitrary user code on them.
<wgrant> Does the IS-controlled archive restricton still apply?
<flacoste> wgrant: it seems so, i've asked IS
<wgrant> Well, we can't just install it on the builder.
<wgrant> We need an archive somewhere.
<wgrant> I guess we could have an IS-controlled PPA.
<wgrant> But it seems utterly pointless.
<flacoste> wgrant: we do have non virtualized builders btw
<wgrant> flacoste: Not for recipe builds.
<wgrant> They explicitly run only on virtual builders.
<flacoste> for the time being
<flacoste> and i don't know how much of the buildd infrastructure is shared between virtualised and non-virtualised build
<flacoste> and the point still stand: we do run arbitrary user code on all of the builders
<flacoste> virtualised or not
<wgrant> Except that the non-virt ones are only used by Canonicalers, but yes.
<flacoste> hmm, as far as i know, universe bulds will also use the non-virtualised ones
<flacoste> which mean that MOTUs builds aren't virtualised
<flacoste> at lest on some architectures
<wgrant> Well, yes, Canonical and trusted Ubuntu people.
<wgrant> But not randoms.
<persia> Note that there are plenty of core-devs that aren't Canonical, and plenty of Canonical folks who aren't core-dev.  main/universe is not useful in this context.
<mwhudson> gary_poster: hey
<gary_poster> hey mwhudson
<mwhudson> gary_poster: is there a way to say "don't security proxy instances of this class" ?
<mwhudson> gary_poster: for context
<gary_poster> mwhudson, yes
<mwhudson> gary_poster: awesome, you can probably guess my next question
<gary_poster> mwhudson, look at bottom of zope/security/checkers.py...will see if I see the pertinent bits quickly
<mwhudson> i'm adding IBranch['getBzrBranch'] and don't want the bzrlib.branch.Branch to get wrapped
<gary_poster> mwhudson: ...ever?  Usually the mechanism is for things that can't be mutated by naughty code
<gary_poster> like strings
<mwhudson> gary_poster: well
<mwhudson> probably yes
<gary_poster> ok :-)
<mwhudson> 'real' mutations to branches are disk operations and they are defended against by other mechanisms
<gary_poster> ah, I see
<mwhudson> basically, i don't want to write zcml for all the eleventy million bzr classes and their attributes
<gary_poster> mwhudson, not sure it is what you want, but BasicTypes?  See _basic_types, beneath it.  You could use zope.security.BasicTypes.update with a dict of {your_class_here: zope.security.NoProxy}
<gary_poster> you could do that in lp_sitecustomize.py
<mwhudson> gary_poster: ok, let me try that
<gary_poster> ok
<mwhudson> gary_poster: doesn't seem to have had an effect
<mwhudson> gary_poster: here's what i tried http://pastebin.ubuntu.com/420696/
<gary_poster> mwhudson: hm. a bit surprising and disappointing.  Is that the entire diff--that is, if I apply the patch I should be able to dupe?
<mwhudson> gary_poster: um, this is on the end of a very long pipe :)
<gary_poster> I thought it might be :-)
<gary_poster> um
<mwhudson> gary_poster: i should be able to cook up a diff you can apply
<gary_poster> mwhudson: ok cool.  I have to go really soon, but I'll try to hang on
<mwhudson> gary_poster: http://en.wikipedia.org/wiki/Bunny_hopping
<mwhudson> haha
<mwhudson> gary_poster: http://pastebin.ubuntu.com/420699/ <- this one :)
<mwhudson> stupid firefox
<gary_poster> lol
<mwhudson> gary_poster: i think i want zope.security.defineChecker ?
<gary_poster> that does sound more familiar.  This part of the machinery is just a bit rusty in my mind...
<mwhudson> that also doesn't work :(
<gary_poster> mwhudson: sanity checking and optimism: http://pastebin.ubuntu.com/420702/
<mwhudson> gary_poster: hmm, is it possible the checkers get reset in tests or something?
<gary_poster> mwhudson, they definitely do--see the bottom of checker.py
<mwhudson> gary_poster: i don't think my lp_sitecustomize is being executed :/
<gary_poster> oh! hm.
<gary_poster> uh, ever?
<mwhudson> at least not for bin/py
 * gary_poster thought he had tests for that
<gary_poster> mwhudson, some print statements are working for me in site-customize
<gary_poster> mwhudson: younger son is imploding and it is my EoD, need to save wife
<mwhudson> gary_poster: ok, i'll fight a bit with this
<mwhudson> gary_poster: have a nice evening
<gary_poster> mwhudson, will check back later.  this should work, and the various component parts of it are for me.  Sorry to run
<mwhudson> somehow it seems not to work for Branch ??
<mwhudson> gary_poster: run
<mwhudson> gary_poster: ok i know part of the problem, and have a different question (when you're back)
<mwhudson> gary_poster: is there a way of saying don't wrap _subclasses_ of a given class?
<mwhudson> gary_poster: also, i think import errors from lp_sitecustomize are suppressed somehow
<mwhudson> yes, definitely
<mwhudson> i think the answer to my subclass question is "no"
<bdmurray> not qa-needstesting but qa-done right?
<mwhudson> bdmurray: qa-ok
<rockstar> sinzui, ping
<sinzui> hi rockstar
<rockstar> sinzui, so, do you know much about how Launchpad does breadcrumbs?
<sinzui> I think I do
<rockstar> sinzui, so, with source package recipes, our current breadcrumb says "User >> Branches >> recipe-name"
<rockstar> I'd like to modify it to be "User >> Recipes >> recipe-name"
<rockstar> So I've modified hierarchy so that I can optionally remove the "Branches" part, but inserting another item in there is proving to be difficult.
<sinzui> rockstar, You want to create a BreadCrumb adapter for IRecipe.
 * sinzui looks for small example of implementation and test
<rockstar> sinzui, well, for ISourcePackageRecipe itself, I'm using the adapter for NameBreadcrumb.
<rockstar> And I tried to create a SourcePackageRecipeHierarchy with which I'm (hackily) trying to get another object in the list of things that need breadcrumbs.
#launchpad-dev 2010-04-23
<rockstar> It's not been happiness.
<sinzui> rockstar, you just need a breadcrumb adapter, but since you are messing with the hierarchy, I think my many title-like examples do not help
<rockstar> sinzui, I don't specifically NEED to mess with hierarchy, but I didn't see another way.
<rockstar> If you have a better way, I are happy to hab it.
 * rockstar has a mushy brain before lunch time
<sinzui> rockstar, I cannot find the hack I did for team membership. It has two parents based on context, and I used a breadcrumb adapter for it. The test is not in the registry/browser/test_breadcrumbs as I recall
<rockstar> sinzui, ah, two parents would be perfect.  I already have a working breadcrumb that will do this.
<rockstar> sinzui, where's that adapter at?
<sinzui> rockstar, there are many. I am looking for one that change more than  the text
<rockstar> sinzui, I need to change the text and the url basically.
<sinzui> rockstar, look at registry/browser/milestone and ./tests/test_breadcrumbs for  MilestoneBreadcrumb
<sinzui> that will get you started while I look for a glorious hack
<rockstar> sinzui, yeah, I was on my way to a glorious(ly bad) hack when I pinged you. :)
<rockstar> I suspected it would require something hacky.
<rockstar> sinzui, I don't see anything in milestone.py that would affect breadcrumbs
<sinzui> rockstar, MilestoneBreadcrumb defines the text and you can redefine the url property
<sinzui> rockstar, to change the order or items in the breadcrumb, you need to hack Hierarchy.objects in a subclass that is registered for the recipe. The default object are those that are traversed. you want to mutate self.request.traversed_objects or consider monkeying with .items to mutate one of the breadcrumbs
<rockstar> sinzui, ah, okay.  It looks like I was already on that track then.
<sinzui> BranchHierarchy is the only good example I know of
<sinzui> The teammembership issue was solved indirectly by the fact the views are ancient and I could hack the class the provide breadcrumb info
<sinzui> Edwin-lunch, ping
<EdwinGrubbs> sinzui: hi
<sinzui> EdwinGrubbs, I do not think setPrefered email address should create an account.
<sinzui> EdwinGrubbs, I do not think it should change an account
<sinzui> EdwinGrubbs, It may need to check that the email address has the account *and* person we expect. Consider if we are setting the person email address and the account is missing, we could add that (but I do not know of a case where this is a real issue)
<EdwinGrubbs> sinzui: do you mean you don't think createPersonAndEmail() should activate an account? I'm already removing that functionality from setPreferredEmail.
<sinzui> EdwinGrubbs, right no changing the account
<sinzui> EdwinGrubbs, I think there is a test that says it should doc/account?
<sinzui> EdwinGrubbs, That test predates SSO
<EdwinGrubbs> ok\
<abentley> wgrant, it appears that I cannot pass archives as parameters into a launchpadlib request, due to some evil with a RedirectionView.  Have you encountered this?
<abentley> wgrant, similarly, calling launchpad.load on a PPA's URL leads to infinite redirects.
<gary_poster> mwhudson: back for a sec.  errors in site-customize (and site.py) are swallowed generally in Python IIRC--that's what you are encountering in that regard.
<gary_poster> And no, there is not a way to register something for a class and all subclasses.  The only mechanism right now would be for you to do the registration yourself, iterating over the subclasses.
<gary_poster> A way to get somewhat similar effect but in a way that is a bit ugly is monkeypatch the root class you care about and say "__Security_checker__ = DummyChecker()" and define DummyChecker as something that allows all names with the zope.security.CheckerPublic permission.  That would mean that things were still proxied but they'd allow access very quickly.
<gary_poster> Alternatively...we're in "propose a change to zope.security" land, which I'd be happy to help with, but would require the usual extra care for use cases that are not your own, and coding and social energy that might not pan out.
<mwhudson> gary_poster: registering all subclasses seems to work for me for now
<mwhudson> gary_poster: thanks for the follow up
<gary_poster> cool
<gary_poster> night all
<cody-somerville> Where does registry keep its tests for webservice API stuff? I don't see anything in lib/lp/registry/doc/product.txt for example.
<mwhudson> cody-somerville: it might be lib/lp/stories/webservice
<mwhudson> uh
<sinzui> stories/webservice/project-registry.txt
<mwhudson> with registry in there
<sinzui> ^ cody-somerville  stories/webservice/project-registry.txt
<sinzui> I still need to find a sane location for api tests
<cody-somerville> sinzui, Should I export newSeries as new_series or newSeries? I notice newProject is exported as new_project and addFile as add_file but getSeries is exported as getSeries.
<sinzui> cody-somerville, I think new_series is right.
<cody-somerville> sinzui, Should I test new_series as extensively as new_project?
<sinzui> I think we need to verify only that it can be accessed using the correct permission and that a series was created. Any other test would duplicate the model teasts
<sinzui> tests
<cody-somerville> sinzui, FYI add_file doesn't seem to be tested for correct permissions
<sinzui> cody-somerville, I may not have been clear...
<sinzui> cody-somerville, permissions are defined else where for the web but the api commonly exposes items that are not in the web...
<cody-somerville> sinzui, ah, you only want me to test that it can be used with the correct permission, not that it can't be used with incorrect permissions
<cody-somerville> But considering that incident with the soyuz API, doesn't it make sense to test?
<sinzui> so if *anyone* can see the method/data, then use the anon helper, other login as the correct user and verify the driver can create a series.
<sinzui> I do not think testing something twice is good. I still want to run the tests on my computer in less than 30 minutes.
 * persia is a big fan of both positive and negative tests related to authorisation
<sinzui> cody-somerville, test a driver and some other user to verify only the person that needs to access that method can
<cody-somerville> I'm confused. Do you want me to test permission or not? :P
<sinzui> I have a lot of confidence that newSeries sane permissions. I care that a project driver can create a series. Testing that someone else cannot can be done, but I think that would be testing a lazr.restful failure, not a zcml or developer failure
<cody-somerville> sinzui, hmmm... looking at the apidoc, new_series looks out of place compared to all the other post methods on Project.
<sinzui> The posts use methods names: newSeries?
<cody-somerville> sinzui, looking through the API doc, most methods are camelCase
<sinzui> Then I think camelCase is nicest for users.
<cody-somerville> I agree.
<cody-somerville> sinzui, https://code.edge.launchpad.net/~cody-somerville/launchpad/export-newSeries-via-api/+merge/23978
<sinzui> cody-somerville, r=me. short and to the point. Do you want me to land this now?
<thumper> rockstar: replace -- breadcrumb = queryAdapter(obj, IBreadcrumb)
<thumper> with
<thumper> breadcrumb = IBreadcrumb(obj, None)
<thumper> sinzui: did you write breadcrumbs?
<sinzui> salgado did
<thumper> sinzui: ok, do you agree with the above replacement?
<sinzui> thumper, yes. i agree
<jtv1> wgrant: heya!  I ran a first test of our buildfarm jobs.
<mwhudson> bug 352800
<cody-somerville> sinzui, I can land it myself but you're welcome to if you'd like.
<cody-somerville> sinzui, landing
<wgrant> jtv: How did it go?
<jtv> wgrant: ran into a known buildmaster/soyuz bug.
<jtv> bug 496574
<mup> Bug #496574: buildd-manager fails to deal with "Fault 8002" errors <buildd-manager> <soyuz-build> <Soyuz:Triaged> <https://launchpad.net/bugs/496574>
<jtv> Of course that means the build still failed; probably a matter of getting the firewall settings right
<wgrant> jtv: Yes, but what caused the slave fault?
<wgrant> Ah, right.
<jtv> wayyy ahead of you
<wgrant> You sure it was actually a job failure? There was nothing else in the buildd-manager logs?
<adeuring> good morning
<wgrant> Whenever mine failed I got a more descriptive traceback.
<bigjools> wgrant: what's wrong with having bzr-builder in the chroots?
<wgrant> bigjools: It pulls in a whole tonne of crap on top of the minimal buildd environment, which will probably cause some builds to not work properly, and others to work when they should not.
<bigjools> wgrant: what crap, exactly?
<wgrant> bigjools: bzr-builder, bzr, lots of Python...
<bigjools> sigh
<wgrant> Stuff which is not Build-Essential, so has no business being in our minimal chroots.
<bigjools> wgrant: having it in a PPA is crack
<wgrant> bigjools: Why?
<bigjools> we need a new chroot for daily builds
<bigjools> because it's more shit to maintain
<wgrant> Maintain two packages in a PPA, or maintain 6 new chroots...
<wgrant> (chroots that need that PPA anyway)
<bigjools> huh? one will suffice for daily build chroots
<bigjools> they'll be i386
<wgrant> * many series
<bigjools> lucid only?
<bigjools> or maverick only
<wgrant> Why?
<bigjools> this is for crack-of-the day, which is on the dev release
<wgrant> Didn't someone just implement multi-series support a couple of weeks ago?
<bigjools> anyway, even if we did 6 more chroots I don't see what the big deal is
<wgrant> All, crack-of-the-day isn't only the dev release, is it?
<wgrant> bigjools: Where do those chroots get their packages?
<wgrant> A PPA, probably.
<wgrant> So a PPA has to be maintained anyway.
<bigjools> ?!
<bigjools> the package would be installed in the chroot
<wgrant> Yes.
<wgrant> But what builds the package?
<mrevell> Howdy
<maxb> What's wrong with having bzr-builder in a PPA and installing it on every build? That's exactly analogous to an existing package build.
<wgrant> Exactly my point.
<bigjools> there are 2 issues, not necessarily problems but things to think about:
<bigjools> 1. it's slower to do that
<bigjools> 2. it's another external dependency to maintain, which can go wrong and block builds
<bigjools> if the IS people who will run it decide that it's ok to do that, then I don't mind
<bigjools> ultimately they will decide
<bigjools> but I want to consider all options before diving into the first one we think of
<jml> good morning
<jml> you know #haskell gets a lot of traffic
<mrevell> Hey noodles775, can I bug you again about that underline on the help images?
<noodles775> mrevell: sure
<noodles775> Can anyone point me to where I can read about supporting different API versions? It's not at https://dev.launchpad.net/API/ImplementingAPIs
 * noodles775 reads the source in the meantime.
 * noodles775 finds lazr/restful/example/multiversion
<didrocks> jml: can you think we can have someone on the Launchpad side for this spec (https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-quickly), to speak about proper way for gpg/ssh upload
<jml> didrocks: by "spec" you really mean UDS discussion session, right?
<didrocks> jml: right
<jml> didrocks: yeah. It's possible that the right people to speak on the topic aren't going to be at UDS
<didrocks> jml: oh, you told me the contrary when we saw the gpg/ssh issue :/ do you think there could be a way to advance on the subject?
<jml> didrocks: we can get them in remotely
<didrocks> jml: otherwise, I'll do the ugly hack as groundcontrol do with screenscrapping
<didrocks> that's the easy solution, but well :/
<jml> didrocks: I'll ask around.
<didrocks> thanks :)
<jml> didrocks: do you remember the bug report about all of this
<didrocks> jml: I guess the gpg and ssh key were closed, even if not 100% feature-full (only the consultation part is achieved)
<jml> didrocks: still, the bug would be helpful
<didrocks> jml: do I create one for ssh, one for gpg?
<jml> didrocks: you mean there aren't bugs already? sure, one for each please.
<didrocks> jml: I can reopen the old bug, but they were closed one we pushed the read branches
<didrocks> jml: will do, one sec
<jml> didrocks: I think we might also need to have a separate discussion at UDS regarding bug 532055
<mup> Bug #532055: Provide a user-friendly way of authorizing desktop, GUI launchpadlib applications <launchpadlib :Triaged> <https://launchpad.net/bugs/532055>
<didrocks> jml: that would be great
<jml> didrocks, emphasis on _separate_
<didrocks> jml: yeah, that's a big discussion ;) Ok, filed bug #568981 and bug #568982
<mup> Bug #568981: Enable uploading a public gpg key using the API <Launchpad Registry:New> <https://launchpad.net/bugs/568981>
<mup> Bug #568982: Enable uploading a public ssh key using the API <launchpadlib :New> <https://launchpad.net/bugs/568982>
<sinzui> didrocks, why is sshkeys targeted to launchpadlib? ssh key code is in launchpad-registry
<didrocks> sinzui: my bad, retargetting
<didrocks> I took the other bug as a reference and mis-middle click :)
<didrocks> fixed
 * jml lunches
<maxb> Staging broken?
<mars> maxb, looks down to me
<maxb> We could really use a status page for staging & edge autoupdate
<mars> maxb, it is on my personal todo list
<mars> the question is finding time to personally do it :)
<mars> I don't have time outside of work for hacking
* ChanServ changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 2 of 10.04 | PQM is open | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in irc://irc.freenode.net/#launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | staging is down!
<mhall119> is there currently any work being done to add a wiki to Launchpad?
<mhall119> it looks like there used to be blueprints for it
<bigjools> jml: ^^ :)
<jml> mhall119, there's no funded work going on
<jml> mhall119, some of the Launchpad developers are working on something like it in their spare time
<mhall119> jml: do you know which ones?
<jml> mhall119, thumper, mostly
<mhall119> thumper: are you still working on a Launchpad Wiki component?
<jml> mhall119, it's 1:30am where thumper is
<mhall119> oh, nevermind then
<mhall119> maybe I'll catch him tonight
<mhall119> I'm hoping it'll be like bitbucket's wiki, only with bzr instead of hg
<jml> mhall119, I'm not sure that thumper is being inspired by bitbucket, but I'm pretty sure it's a bzr-backed wiki
<jml> mhall119, we've been talking about this for a very long time
<mhall119> cool
<mhall119> I like being able to work on a wiki offline, or mass-edit with CLI tools, then merge it back in
<persia> lp:wikkid is the link posted earlier, if someone wants to look at WIP
<mhall119> often times I've wished I could do that with wiki.ubuntu.com
<persia> (posted in #launchpad about 12 hours back)
<persia> mhall119: editmoin
<mhall119> persia: thanks, but I don't think that's quite the same
<persia> heh, true.
<mhall119> I'm branching wikkid right now though
<mhall119> thanks for that refference
<persia> #launchpad is an informative channel : I recommend it's backscroll.
<henninge> allenap, adeuring, gmb: Can either of you resolve the two merge conflicts in lib/lp/bugs/scripts/checkwatches/tests/test_core.py, please?
<henninge> lib/lp/bugs/scripts/checkwatches/tests/test_core.py
<henninge> http://paste.ubuntu.com/421058/
<henninge> There it is ^
<allenap> henninge: I'll look.
<allenap> henninge: Is this when merging from devel into db-devel?
<henninge> allenap: into production-stable, yes.
<allenap> henninge: production-devel into production-stable?
<henninge> allenap: sorry ;-)
<allenap> henninge: There's stuff in there that shouldn't be anywhere near production yet.
<henninge> allenap: I have a branch based on production-stable but now I want to merge it into devel, so I am merging devel into it.
<henninge> was a c-p candidate originally.
<allenap> henninge: Why not start a fresh devel branch and merge the production-stable branch into it?
<allenap> henninge: Oh I guess it's much the same.
<henninge> allenap: that was my next option but I was down to two conflicting files, so I thought might as well resolve those.
<henninge> allenap: the result will be merged in to devel (just to be clear).
<allenap> henninge: Can you point me to your production-stable branch? I can help you fix the conflicts, but I want to understand *why* it's conflicting. IIUC, it shouldn't.
<henninge> sure
<bac> hi thekorn, do you know how to call a destructor on a lplib object?  bug 534363 implies there is a trick.
<mup> Bug #534363: no easy way to call destructor <usability> <launchpadlib :Triaged> <https://launchpad.net/bugs/534363>
<henninge> allenap:  https://code.edge.launchpad.net/~henninge/launchpad/bug-565294-nplurals
<allenap> henninge: Thanks.
<sinzui> allenap, do you have time to read and reply to my proposal to fix the needs-packaging timeouts?
<allenap> sinzui: I read it a couple of times but I didn't really take it in very well. I'll look again today, and get back to you. Will that be okay?
<sinzui> allenap, yes. I picked you because I am extending the not-so-temporary table you added. You may have thoughts about how to make it untemporary and maybe a cron process is wrong
<thekorn> bac, sorry, I don't know anything about launchpadlib and DELETE, and I also don't think there are any DELETE methods eposed through the API yet
<allenap> sinzui: IIRC, bigjools had some ideas about that at the time.
<thekorn> I think all destructors are POST methods until now
<allenap> henninge: If you take a fresh branch of devel, the following will merge your changes without conflict: bzr merge -r 9192.. lp:~henninge/launchpad/bug-565294-nplurals
<sinzui> bac: maybe we should unexport delete  milestone and declare victory
<bac> thekorn: thanks.  there are some, and i'm trying to fix one.  the ones that already exist don't appear to work, though.
<bac> sinzui: can i haz my week back?
<allenap> henninge: You probably know this now, but CPs are less hassle when landed in devel first. I have made that mistake before. Or was there a reason?
<henninge> allenap: no, no other reason.
<henninge> allenap: so you mean, land in devel, then merge the revisions into a production branch and hand that of for cp?
<henninge> allenap: In this case I was trying to avoid using a new devel branch so that all the mp and qa automatic keeps working.
<sinzui> bac: all work is about scope management. Always state how much your time is worth when you start, fix the core problem first, them incorporate tech-debt for good karma as time allows
<henninge> but oh well, can't have everything ...
 * sinzui will not work on any trivial bug for more than 1 hour
<allenap> henninge: Yes. I suspect the policy is there to make sure the code is landed so that we don't regress next release.
<allenap> henninge: Eurgh :)
 * henninge googles that ... ;)
<allenap> henninge: Fwiw, https://wiki.canonical.com/Launchpad/PolicyandProcess/EmergencyChange says to land in devel first too.
<henninge> wow, should have read that page first ...
<henninge> allenap: thanks
<henninge> allenap: so can you resolve the file or should I go the new-devel-branch road?
<allenap> henninge: Please go the new-devel road. It merges cleanly which has got to be a good thing, especially as gmb is doing some major refactoring in the checkwatches package.
<henninge> allenap: ok, np. Have a nice weekend! ;)
<allenap> henninge: I think it makes sense to have a separate merge proposal anyway (and you can link back to the first one), and if the auto-qa-tagging thing doesn't understand the situation then it's a bug in the auto-qa-tagging machinery.
<allenap> henninge: You too :)
<henninge> ah, right
<cody-somerville> I'm a bit confused by setBugSupervisor. Why does it take two arguments?
<jpds> cody-somerville: Permission checking in userCanAlterSubscription() ?
<cody-somerville> jpds, I think you're guessing
<james_w> cody-somerville: the second is the person doing the setting
<james_w> call_with(user=REQUEST_USER) over the API
<mrevell> night
<sinzui> EdwinGrubbs, didn't we fix the shadowing issue described in bug 567583 6 months ago?
<mup> Bug #567583: API collections shadow the default traversal <Launchpad Registry:New> <https://launchpad.net/bugs/567583>
<jml> james_w, how do I use lazr.restfulclient.tx without installing it?
<jml> python really isn't built for namespace packages :\
<cody-somerville> sinzui, for LP #444266, where would I write the tests for that? There doesn't appear to be any good existing doctest to add to in lp/bugs/stories/webservice/
<mup> Bug #444266: Expose project bug supervisor and security contact via API <api> <oem-services> <Launchpad Bugs:In Progress by cody-somerville> <https://launchpad.net/bugs/444266>
 * sinzui thinks
<sinzui> cody-somerville, I think you want to create a new test for the api. hasbugsupervisor maybe?
<sinzui> in lp/bugs/stories/webservice/
<cody-somerville> is the security contact a part of registry or bugs?
<sinzui> bugs
<sinzui> That has a separate interface
<sinzui> maybe we can add a bugtarget.txt doctest to that directory to cover both
<EdwinGrubbs> sinzui: no, we didn't solve the underlying cause. I just changed the name of the "releases" series that was colliding with IProduct.series. I then assigned bug 432766 to leonard.
<mup> Bug #432766: instance name can shadow object attributes <Launchpad Foundations:Triaged by leonardr> <lazr.restful:Triaged> <https://launchpad.net/bugs/432766>
<sinzui> cody-somerville, I expect those fields to be visible to anon api
<sinzui> EdwinGrubbs, thanks.
<EdwinGrubbs> sinzui: I marked the bug as a duplicate
<sinzui> even more gratitude
<cody-somerville> sinzui, The only interfaces that have a security_contact field exist in registry.
<sinzui> cody-somerville, yes. that interface is a problem. it is design has proven to be an issue when we try to make a single page to set bug configuration
<jml> how do I get the JSON dict from a launchpadlib object?
<sinzui> cody-somerville every bugtarget is also a registry object, but the security contact is only used by bugs.
<sinzui> cody-somerville, you can only set that field is bug tracking is enabled. I think that is stupid.
<jml> lpobj._wadl_resource.representation does the trick
<jml> don't worry, I don't intend to let anyone else use this code
<cody-somerville> sinzui, In fact, the only interface I see that has a security_contact field is series and that just says it references the parent security contact.
<sinzui> cody-somerville, I am telling you the truth. bugtarget is the answer. There is a long history of application wrongly placing attributes on common objects. This makes refactoring difficult, the modules are long, and confuses new hackers who do not know who really owns the feature.
<sinzui> cody-somerville, think of it this way, if an application does not use launchpad bugs, it cannot have a security contact or a bug supervisor. if we got rid of that application the fields would not be used. Thus those fields are the domain of Launchpad Bugs.
<cody-somerville> sinzui, I understand that
<cody-somerville> sinzui, I'm asking you though, where is the actual interface that these models are implementing that has the security_contact field so I can decorate it?
<sinzui> I do not recall since I do not work with it. I bet based on its age that is canonical.launchpad.interfaces.launchpad.IHasSecurityContact
<cody-somerville> sinzui, good call
<sinzui> Maybe 3 years it too long to work on a project when you can take a blind stab at an answer and nail it
<cody-somerville> sinzui, Now, what prevents someone without the correct permissions from modifying bug supervisor/security contact? Just the view?
<sinzui> I think permission on the implementer state who can change the field.
 * sinzui looks
<sinzui> security_contact: launchpad.Edit
<sinzui> setBugSupervisor: launchpad.Edit
<sinzui> cody-somerville, The permissions are on the object and restful will enforce that
<cody-somerville> awesome
<cody-somerville> I remember reading something about permissions and views and wanting to make it apply automatically to restful stuff? What was that all about?
<sinzui> zope.Public is the an implicit permission in some cases on objects/views. Restful ignored that, and the consequence is that some objects/attributes cannot be viewed via anonymous access. We need to add permission to security.py to explicitly allow those objects to be visible to anonymous users. IDistributionMirror is an example
<cody-somerville> sinzui, How do I export bug_supervisor as readonly? I thought I could pass readonly=True to exported but that doesn't appear to be true.
<sinzui> It is read only I think
<cody-somerville> you think it already is?
<cody-somerville> or the argument is called just 'read'?
<sinzui> cody-somerville, there is no set_attributes declaration for bug_supervisor. No callsite can change the value without getting stripping the security wrapper
<sinzui> cody-somerville, have you verified in a test that someone can change that attribute?
<sinzui> A launchpad view running for an admin would get a forbidden error if it tried to change that field
<cody-somerville> I guess I'll generate the apidocs and see what it says
<cody-somerville> sinzui, the bug supervisor stuff doesn't show up in apidocs. security_contact does though. I think its because IProduct does not inherit IHasBugSupervisor whereas it does IHasSecurityContact.
<sinzui> cody-somerville, yes. I suspected one of these would be a problem. I assumed that is why it was not exported in the past
<sinzui> I think IHasSecurityContact needs to be exported too. It may need a url defined since restful cannot access anything without a URL.
<cody-somerville> sinzui, security_contact shows up fine. I just exported security_contact field in IHasSecurityContact like normal.
<sinzui> I think this is like the issue we had with IDistributionMirror. We added a checker to security.py and a browser:url to browser/configure.py as well as exporting the base interface
<sinzui> does the interface also have this: export_as_webservice_entry()
<cody-somerville> sinzui, no
<sinzui> Add that, I think you do need to add a security checker and a url.
<cody-somerville> sinzui, For IHasSecurityContact? why would we want this to be a webservice entity?
<sinzui> cody-somerville, I am off to rescue my children from the state institution. you can cargo cult IDistributionMirror examples from security.py and browser/configure.zcml to get the two missing parts
<cody-somerville> sinzui, IProject inherits IHasSecurityContact so why would IHasSecurityContact need to be its own webservice entity?
<thumper> gary_poster: I'm wanting to be able to turn a canonical_url into a list of traversed objects (attached to a request even better)
<thumper> gary_poster: but I couldn't find the right hooks in the publisher code
<thumper> gary_poster: instead of getting too frustrated, I thought I'd just ask you
<thumper> gary_poster: as I have a feeling you'll know where to look
<thumper> gary_poster: it is for testing breadcrumbs more easily
<thumper> gary_poster: the current way requries passing in the traversed objects list
<gary_poster> thumper :-) I'll try at least.
<thumper> gary_poster: but I think that should really be unnecessary
<thumper> gary_poster: we should be able to say "create me the breadcrumbs for this object"
<thumper> gary_poster: and have the test hook into the publisher then create the view
<thumper> I have to go get the girls up now, but I'll check back later
<gary_poster> thumper, in classic Zope 3 you'd walk up the __parent__ list.  OK, cool, I'll look at code for a sec, and then confer with flacoste if I don't see anything
<gary_poster> s/list/pointers
<gary_poster> OK I've read it three times and I think I understand what you want.  looking...
<cody-somerville> why does IHasBugSupervisor subclass IStructuralSubscriptionTarget?
<james_w> jml: I had to use a mess of virtuaenv and symlinks
<gary_poster> thumper: I reacquainted myself with some of the pertinent code, and though I'm still not confident I understand what you mean, I'm not optimistic.  Maybe point me to a concrete example of what's going on now, with an example of what you want, and I'll give it another whirl?
<gary_poster> james_w, fwiw, as they exist now, namespace packages won't work if the namespace package actually has code in it.  If you actually wanted to release lazr.restfulclient.tx, it would need to be lazr.restfulclient.plugins.tx, or something, where "plugins" has no code.  I don't remember if the PEP for namespace packages lifts that restriction or not, but that is the case for now, anyway.
<gary_poster> lazr.restfulclient-tx?
<gary_poster> dunno what it is
<james_w> Gary_poster: thanks for the tip. I'll probably end up changing the name.
<gary_poster> cool
<james_w> It's a fork of lazr.restfulclient based in twisted with some experiments thrown in.
<gary_poster> oh!  experiments good, fork, boo :-/
<gary_poster> is there something we could do to not encourage a fork?
<thumper> gary_poster: I'm wanting to create the +hierarchy view for an object, however the request for create_initialized_view has no traversed objects, and the hierarchy view uses those
<thumper> gary_poster: I want to check the items of that view to check the breadcrumbs for any object
<thumper> gary_poster: so... given any object, get the canonical_url for it, work out the traversed objects, and create a request with that to pass into create_initialized_view
<thumper> gary_poster: for simple breadcrumb testing
<thumper> gary_poster: I'm sure a method to get the traversed objects for any given other object would be a very helpful testing function
<gary_poster> ok, thumper.  Maybe.  Looking.
<gary_poster> so, thumper, a test request is not just ok but good, right?
<thumper> gary_poster: yes
<gary_poster> k
<james_w> gary_poster: we can refactor lazr.restfulclient so that we can share code, but it has a lot of sync assumptions and the API makes no sense for twisted.
<gary_poster> thumper, the best I can come up with is to suggest that you refactor the code in canonical_url.  It does most everything you want, I think, but discards the parts you care about.
<thumper> gary_poster: hmm...
<thumper> gary_poster: ok, I'll take a look monday
<thumper> gary_poster: thansk
<gary_poster> cool, thumper
<gary_poster> np
<thumper> gary_poster: although I was hoping that we could hook into the publishTraverse somewhere
<thumper> gary_poster: I don't think we'd get exactly the same answer
<gary_poster> thumper: understood.  there's a reason that canonical_url is so messy though. :-/
<thumper> not all the time anyway
<gary_poster> james_w: I'm a big +1 on Twisted support, very understanding of the differences necessary for async, and unhappy if there is a lot of code duplication between the original and the fork, as I think there would be.  If you (and jml?) had suggestions on a refactoring to make code sharing easy, I'd be eager to come to an agreement and incorporate them, rather than see a fork develop.
<james_w> art_poster: I'm not happy with a fork either, and it's huge duplication right now. its also just a toy right now, if it has legs then I'll push for sharing what we can.
<james_w> Sorry, crappy phone keyboard :)
<gary_poster> LOL
<gary_poster> james_w: OK, great sounds good
<cody-somerville> How do I fix 'zope.configuration.config.ConfigurationConflictError: Conflicting configuration actions'?
<mars> cody-somerville, sinzui may know.  He wrote our configuration libraries.
<sinzui> mars, no, cody-somerville is talking about ZCML
<cody-somerville> sinzui, you're back :)
<sinzui> cody-somerville, I have experienced that. You have added a duplicate permission rule for an object/attribute. ZCML allows only one rule.
<sinzui> cody-somerville, Search for the Interface or attribute you added to locate the current rule and update that rule instead
<cody-somerville> I didn't touch ZCML
<sinzui> oh?
<sinzui> yuck
 * sinzui thinks
<sinzui> cody-somerville, did you add a browser:url?
<cody-somerville> Nope
<cody-somerville> I started getting that error when I made IProductPublic inherit IHasBugSupervisor.
<cody-somerville> I noticed a bunch of methods and what not for IStructuralSubscriptionTarget and then noticed IHasBugSupervisor inherits IStructuralSubscriptionTarget and so does IProduct
<cody-somerville> so I made IHasBugSupervisor just inherit from Interface and it reduced the complaining to just the bug_supervisor and setBugSupervisor attribute and method respectively.
<wgrant> cody-somerville: So, basically, Zope security ZCML sucks.
<wgrant> Instead make IProduct inherit IHasBugSupervisor, not IProductPublic.
<wgrant> Unless you want to split IHasBugSupervisor into two.
<sinzui> I agree with wgrant's first assertion and first suggestion
<cody-somerville> okay
<wgrant> (if you look in lib/lp/registry/configure.zcml, you'll see that those two attributes already have manual declarations for IProduct and IDistribution)
<cody-somerville> Is it correct to make IHasBugSupervisor subclass Interface instead of IStructuralSubscriptionTarget? I can't understand why it would.
<cody-somerville> (why it would subclass IStructuralSubscriptionTarget that is)
<sinzui> cody-somerville, I think you may want to remove the ZCML rules on the pillar for bug_supervisors. define the rules just on IHasBugSupervisor
<wgrant> sinzui: Aren't permissions applied to classes, not interfaces?
<wgrant> cody-somerville: Some of the bug supervisor stuff might touch structural subscriptions.
<wgrant> Grep around, I guess.
<sinzui> cody-somerville, removing IStructuralSubscriptionTarget as a base will break subscription behaviour I think
<cody-somerville> Why?
<cody-somerville> IProduct inherits IStructuralSubscriptionTarget
<wgrant> It won't break it.
<cody-somerville> and IHasBugSupervisor should have nothing to do with IStructuralSubscriptionTarget - the fact that the bug supervisor creates a bug subscription is an implementation detail, right?
<wgrant> But it might be wrong.
<sinzui> cody-somerville, did you check every object that inherits IHasBugSupervisor?
<cody-somerville> sinzui, Not yet.
<cody-somerville> Why does setBugSupervisor in IHasBugSupervisor have self as an argument? I thought interfaces didn't need 'self'?
<sinzui> cody-somerville: I think lint will tell you you are right
<wgrant> s/didn't need/cannot have/
<wgrant> A verifyObject test will probably start failing if you don't fix that.
<sinzui> cody-somerville, I think you can can make every product and distribution inherit from both IStructuralSubscriptionTarget and IHasBugSupervisor, then make IHasBugSupervisor descend from Interface
<cody-somerville> woot. got make to work now.
<cody-somerville> I should probably make bug_supervisor read only but will that break anything or does it only affect the the webservice API?
<wgrant> It may affect forms too.
<wgrant> You should also not export setBugSupervisor directly -- instead export it as the mutator for bug_supervisor.
<sinzui> cody-somerville, If you copied the original permission, the attribute is read-only
<wgrant> gary_poster: Um, so you're going to be sending privileged cookies over HTTP?
<wgrant> Even if they have a short lifetime, that is...... um.....
<gary_poster> wgrant, yup
<wgrant> ............
<wgrant> Does this come under 'who could possibly think that was a good idea?', or am I missing something?
<gary_poster> wgrant, the question is a matter of balance, as usual.  Right now, the plan is that identity uploads and private teams, projects etc. would be over HTTPS (with their own separate cookies).  The rest would be on HTTP.
<gary_poster> HTTPS costs around 30-40% of a typical download cost for our pages.  We feel that there are large swaths of actions working on normal public content that don't need HTTPS.  github is a competitor (sorta) I'm familiar with; they feel similarly, apparently.
<gary_poster> It's been discussed internally, but if you wanted a debate it would be reasonable and healthy.  If I don't convince you quickly, we should take it to the list.
<wgrant> gary_poster: You know there are Launchpad POSTs on public objects that can publish code to many millions of users?
<wgrant> Making Launchpad less secure should not be a priority.
<gary_poster> Making it faster is.
<wgrant> It guards things that are vastly more important than anything GitHub has direct access to.
<gary_poster> That's the single biggest change we can make to do that.
<wgrant> Serve public reads over HTTP, sure.
<wgrant> Include an unprivileged cookie in these requests so you can render the pages as if they were authenticated.
<wgrant> But writes over HTTP? Ew.
<gary_poster> wgrant: That's the plan, and it is certainly not without precedent.  We have discussed adding an additional level of protection for projects, in addition to "private": "protected".  This would be public, but forced over HTTPS.  This would be opt-in.
<gary_poster> Your point of sending bunches of email is a good one though
<wgrant> gary_poster: So you are seriously going to allow insecure write requests?
<flacoste> what is the "bunches of email" point?
<wgrant> I made no bunches of email point.
<wgrant> I made a "bunches of malware" point, though.
<flacoste> wgrant: the first goal is to allow HTTP for read-only public stuff
<gary_poster> I misread the comment.  If you are discussing PPAs, granted.
<elmo> flacoste: no one's objecting to that
<elmo> flacoste: it's the writes that the problem
<flacoste> wgrant: we'll consider write over HTTP in a second iteration after a proper risk-analysis
<wgrant> gary_poster: Launchpad has one very large project: Ubuntu.
<wgrant> Not just PPAs. Much, much worse.
<wgrant> flacoste: OK, good to know.
<gary_poster> wgrant, yes.
<flacoste> wgrant: there are multiple place where write over http wouldn't be a problem from a RA perspective: filing and commenting on bugs for example
<wgrant> flacoste: That is a security issue.
<wgrant> Projects use bugs for admin requests.
<flacoste> everything is security issue
<wgrant> eg. Ubuntu uses them for sync requests.
<flacoste> that's why you have risk analysis
<wgrant> OK, an *actual security problem*, then.
<flacoste> that's interesting, so you can trigger a Debian sync from an email to Launchpad?
<flacoste> GPG-signed of course
<elmo> I suspect some of the exposed archive stuff would also be an interesting avenue for serious abuse
<wgrant> Not automatically, but yes.
<wgrant> elmo: Oh yes.
<wgrant> A quick syncSource here and there...
<flacoste> anyway, we aren't opening those gates yet
<flacoste> but thanks for verifying that a RA was on our plan before we did :-)
<wgrant> U1 manages to do AJAX over HTTPS with <500ms from here.
<wgrant> There's no reason for your writes to take much longer than that.
<wgrant> So I really don't see the benefit in throwing security out the window.
#launchpad-dev 2010-04-24
<wgrant> OOPS-1575B227
<wgrant> Probably a DB locking issue.
<wgrant> Can somebody please tell me the problematic statement?
<wgrant> Alternatively it could be taking ages to close the several bugs attached.
<wgrant> It would be handy to know which.
<cody-somerville> wgrant,  TimeoutError: 'SELECT PackageUploadSource.id, PackageUploadSource.packageupload, PackageUploadSource.sourcepackagerelease FROM PackageUploadSource WHERE PackageUploadSource.packageupload = %s ORDER BY PackageUploadSource.id', [<storm.variables.IntVariable object at 0x2aaaadddca28>]
<wgrant> Gnargh not that one again.
<wgrant> cody-somerville: How long did it take?
<wgrant> That particular query, that is.
<cody-somerville> As long as what ever the timeout value is I assume
<wgrant> cody-somerville: Basically I'm wondering if that query was the straw that broke the camel's back, or if it took a long time on its own.
<cody-somerville> wgrant, It doesn't show up in the long SQL statements list.
<cody-somerville> wgrant, although it does show up in the repeated SQL statements
<cody-somerville> and its a subselect for a lot of repeated queries too
<wgrant> cody-somerville: Can you see how long the final statement in the query log took?
<cody-somerville> 4ms
<wgrant> OK. Thanks.
<cody-somerville> "SELECT BugJob.json_data, BugJob.bug, BugJob.id, BugJob.job, BugJob.job_type FROM BugJob, Job WHERE BugJob.bug = %s AND BugJob.job_type = %s AND BugJob.job = Job.id AND Job.id IN (SELECT Job.id FROM Job WHERE Job.status = %s AND (Job.lease_expires IS NULL OR Job.lease_expires < (CURRENT_TIMESTAMP AT TIME ZONE 'UTC')) AND (Job.scheduled_start IS NULL OR Job.scheduled_start <= (CURRENT_TIMESTAMP AT TIME ZONE 'UTC'))) LIMIT 1" a
<cody-somerville> ppears very costly. 432.0 and repeated 7 times.
<wgrant> Ahhh.
<wgrant> so it *is* the bugs.
<wgrant> But 432ms each? Seriously?
<cody-somerville> thats the average
<cody-somerville> some take longer
<cody-somerville> one took 632ms
<cody-somerville> 'TypeError: Only a read-only field can have a mutator method' <-- I guess sinzui was wrong about bug_supervisor being read only already :P
<wgrant> cody-somerville: He was right, and I was right.
<wgrant> There are two aspects to read-onlyness:
<wgrant>  - the schema in the interface. Currently writable, and what lazr.restful looks at.
<wgrant>  - The attribute security, in configure.zcml. Currently read-only.
<cody-somerville> Did I mention I hate zope?
<wgrant> It goes without saying.
<wgrant> Although, well, for what LP is it could be worse.
<cody-somerville> but clearly in the context I was talking about earlier I was referring to the former and not the attribute security.
<cody-somerville> but maybe it doesn't matter and he just assumed I'd understand what he meant.
<wgrant> He was clearly misunderstanding and speaking about the ZCML, though.
<cody-somerville> oh well, in the end it meant I learnt something new so all good.
<cody-somerville> so I assume if I set the attribute to readonly its not going to cause problems since the attribute security already makes it readonly?
<cody-somerville> doh, I was afraid I'd run into this: TypeError: A mutator method must take one and only one non-fixed argument. setBugSupervisor takes 2
<wgrant> That's OK.
<wgrant> You just need to use something (operation_parameters()? I forget) to pre-populate the second argument with REQUEST_USER.
<wgrant> grep around for REQUEST_USER if you're unsure of details.
 * wgrant lunches.
<cody-somerville> wgrant, I already do
<cody-somerville> wgrant, @call_with(user=REQUEST_USER)
<wgrant> cody-somerville: You removed the incorrect self argument?
<cody-somerville> wgrant, yup
<wgrant> cody-somerville: paste(bin) all your decorators and the method definition itself?
<cody-somerville> wgrant, https://pastebin.canonical.com/31276/
<wgrant> cody-somerville: EPERM
<cody-somerville> oops
<cody-somerville> http://pastebin.ubuntu.com/421428/
<wgrant> cody-somerville: You might need to export_write_operation too, and all the other examples I'm looking at have mutator_for first (ie. executed last)
<wgrant> Anyway, really lunching now.
<cody-somerville> true true
<cody-somerville> looks like that works
<cody-somerville> woot. works. Now I just need to write tests.
 * wgrant returns.
<mwhudson> woo all tests pass in no-hosted-area
<wgrant> mwhudson: Nice!
<mwhudson> not sure the very last test fixes will pass review but i guess there's monday for that
<thumper> mwhudson: congrates
<thumper> :)
<thumper> please ignort that last typo
<thumper> had almost a bottle of wine
<mwhudson> haha
<magcius> Where exactly in the code is the source for the launchpad.net landing page and project pages on there? What is the "app" name for the "Overview" section of a project page?
<adiroiban> magcius: launchpad.net landing page? Can you please add an URL of that page?
<adiroiban> I don't know exactly about what page are you talking about
<magcius> adiroiban: something like http://launchpad.net or http://launchpad.net/bzr
<adiroiban> http://launchpad.net/bzr
<magcius> adiroiban: what subapp is that?
<adiroiban> is the IProduct +index page
<adiroiban> it should be registry
<magcius> ah, registry
<adiroiban> I am not sure about the launchpad.net start page ... let me check
<adiroiban> I usualy just look at some text on that page
<adiroiban> and do a full text search on all files
<magcius> heh
<magcius> what I'm really looking for is the timeline graph JavaScript code
<adiroiban> magcius: the one under âSeries and milestonesâ ?
<magcius> adiroiban: yes
<adiroiban> registry/templates/timeline-macros.pt
<adiroiban> magcius: that should be the starting point... then look for javascript code in lib/canonical/launchpad/javascript/registry
<magcius> adiroiban: alright, thank yo
<adiroiban> or if it was moved... in lib/lp/registry/javascsript
#launchpad-dev 2010-04-25
<mwhudson> thumper: did you do anything to do with import bzr format upgrades recently?
<mwhudson> for some reason all subversion-via-cscvs imports seem to be failing
<thumper> mwhudson: no, not done anything
<thumper> mwhudson: I'm guessing someone came along and tried to upgrade
<mwhudson> thumper: yeah, something like that, it's a bit off
<mwhudson> odd
<mwhudson> will dig tomorrow i guess
<thumper> yeah
<thumper> possibly jelmer
<jelmer> thumper: not me
<nigelbabu> is there a way to find who submitted a patch on a bug via API?
<nigelbabu> i.e. the author of the patch.  Do we have something for that?
<mwhudson> morning
<thumper> mwhudson: morning
<thumper> mwhudson: I want to head down to fluid to work for the morning
<thumper> mwhudson: however it has the slight problem of no internet
<mwhudson> thumper: how long will you be away for?
<mwhudson> thumper: my morning tasks basically involve "preparing branches for you to review", but it's going to take a while I guess
<thumper> mwhudson: actually, I may just head down for an hour or so
<thumper> I'll ping you when I'm back
<mwhudson> thumper: ok, i'm going into town in a bit (seeing accountant at 11) but i'll get online somehow or other
<mwhudson> thumper: k
 * mwhudson afk for a bit
#launchpad-dev 2011-04-18
<thumper> ok
<thumper> sort_order is only for iteration
<thumper> and comparison
<thumper> inside the enum code itself
<thumper> used primarily for ordering the enum values inside drop down lists et al
<thumper> nothing to do with the db queries
<thumper> or the db_value
<lifeless> right
<lifeless> so I think the thing to do then is to change from mid 30's for the INCOMPLETE_WITH_RESPONSE and INCOMPLETE_WITHOUT_RESPONSE
<lifeless> and insert them adjacent to the existing INCOMPLETE value
<thumper> ah... sure
<lifeless> thumper: is the default sort order numeric ?
 * thumper tries to recall
 * thumper looks at the code
<thumper> lifeless: the enum item has a sortkey value that is numeric
<thumper> the sort_order is used to recreate the sortkey values
<lifeless> so if its absent its numeric
<lifeless> cool
<lifeless> hmm
<poolie_> hi
<wallyworld> lifeless: i have a test which calls DocTestMatches. It fails if "matchee" is unicode but passes if I encode to utf-8 as in: self.assertThat(markups[1].encode('utf-8'), DocTestMatches(expected_item_1, self.doctest_opts))
<wallyworld> lifeless: the error is
<wallyworld>   File "/var/launchpad/tmp/eggs/testtools-0.9.10-py2.6.egg/testtools/matchers.py", line 169, in _with_nl
<wallyworld>     result = str(actual)
<wallyworld> UnicodeEncodeError: 'ascii' codec can't encode character u'\u2026' in position 2121: ordinal not in range(128)
<wallyworld> lifeless: should DocTestMatches be fixed? is it broken? ie should str(actual) be replaced with actual.encode('utf-8')?
<wallyworld> lifeless: this is an existing test that broke when a change to made to what was rendered on a page. it was not previously being passed a unicode string
<lifeless> wallyworld: I don't remember if its a doctest limitation or a shallow bug in testtools
<lifeless> it seems reasonable to me that we'd support self.assertThat(u'fo', DocTestMatches(u'bar'))
<wallyworld> lifeless: ok. for now i can amend the test with the .encode() and file a testtools bug or look up and existing one and include a XXX in the test?
<lifeless> certainly file a test tools bug
<wallyworld> will do
<lifeless> encoding to utf8 is a tolerable workaround, though it will break if someone runs the lp test suite on a cp* or shift-jis system [but it wouldn't be the only thing to break that]
<wallyworld> unless there's another workaround i can use?
<lifeless> you could fix the bug :)
<wallyworld> lifeless: sure. but i want to get my branch landed without the blockage caused by having to land a testtools update
<wallyworld> or i guess i could do them together
<lifeless> In terms of fixing it, I think something like:
<lifeless> if type(foo) is unicode:
<lifeless>  ...
<lifeless> else:
<lifeless>   foo = str(foo)
<lifeless>    ...
<lifeless> [that is, special case handling of foo]
<lifeless> it won't be entirely correct unless you also handle both sides being conditionally unicode
<wallyworld> yes
<wallyworld> i wish my unicode foo was better
<lifeless> Its not you, its python.
<wgrant> Python, and all of the people who refuse to use UTF-8.
<wgrant> wallyworld: I think we need to disable the YUI tests :(
<wallyworld> wgrant: i saw another failure :-(
<wgrant> Yeah.
<wallyworld> well it was worth a try
<wgrant> Definitely.
<wgrant> it was a useful test.
<wallyworld> we need to look at perhaps another harness to run them besides windmill
<wgrant> wallyworld: YUITestLayer?
<wallyworld> wgrant: i think so
<wgrant> WTF
<wgrant> Unity just went insane.
<lifeless> â½just ?
<wgrant> It all worked fine, except that any window that you clicked on disappeared.
<wgrant> Then reappeared when I clicked again.
<wallyworld> KDE is rock solid :-P
<lifeless> but you loose 30K pixels. Thats got to hurt.
<huwshimi> wallyworld: That's irrelevant. So is Gnome, XFCE etc.
<wallyworld> huwshimi: i was just stirring
<wgrant> https://code.launchpad.net/~wgrant/launchpad/disable-yuitestlayer/+merge/58058
<wgrant> Bug #763604 sounds like a browser bug...
<_mup_> Bug #763604: Cannot remove attachment when reporting new bug <Launchpad itself:New> < https://launchpad.net/bugs/763604 >
<wgrant> Isn'
<wgrant> t most of the point of that widget to not be manipulatable except by the user?
<poolie_> lifeless: https://bugs.launchpad.net/ubuntu/+source/schroot/+bug/764086 is a slightly interesting example of your task unification thing
<_mup_> Bug #764086: dchroot.conf parser uses deprecated key "location" <schroot (Ubuntu):New> < https://launchpad.net/bugs/764086 >
<poolie_> like many bugs it's already fixed in natty but we really want to say, to start with, 'please fix it in lucid-updates'
<poolie_> and there are two ambiguous ways to do it: nominate for lucid, or target the main task to lucid-updates
<lifeless> indeed
<lifeless> so this is something I think a clueful user would reasonably file directly on lucid
<poolie_> i agree it is something they would want to file directly on lucid
<poolie_> can you do that in lp today?
<wgrant> No.
<dobey> a script could nominate for release and target milestone to lucid-updates, but you can't do it on the web
<dobey> i guess
<lifeless> interestingly
<lifeless> apport tags bugs as
<lifeless> natty
<lifeless> etc
<lifeless> the nomination stuff is intended to stop incorrect bugtasks
<lifeless> more precisely
<lifeless> on a frozen series
<lifeless> developers opt in to having tasks
<lifeless> and non-priviliged folk can suggest where a task should be using nominations
<lifeless> there is an unresolved tension between 'bug exists' and 'task to work on the bug'
<poolie_> what's the semantic difference between nominating for lucid, and targeting to lucid-updates?
<lifeless> theres a few
<lifeless> firstly you can't target to lucid-updates, that isn't a series.
<lifeless> you can target to lucid, if you have access
<lifeless> nominating to lucid would write a proposal that it should be targeted against lucid
<poolie_> there is a milestone called 'lucid-updates' and you can target it
<lifeless> ah
<lifeless> so 'target' and milestone are different again
<poolie_> the milestone ui says 'target to milestone' :)
<lifeless> right
<lifeless> 'bug tasks' have a 'target' field
<lifeless> which is the IBugTarget that the bug is for
<lifeless> bah
<lifeless> bugtask is for
<poolie_> so, in your proposed change
<lifeless> which can be a product/productseries/distro/distrosourcepackagename/distroseries/distroseriessourcepackagename
<poolie_> the default bugtask target would be the current development series, natty
<dobey> what i find really annoying, is that it is impossible to remove a bugtask from a bug
<poolie_> and then it would be obviously silly to have a natty series milestone called lucid-updates
<lifeless> dobey: yes, we're going to do something about that.
<dobey> you can only change the project/package
<dobey> cool
<lifeless> dobey: one proposed thing is to hide 'Invalid' status tasks, unless *all* the tasks are invalid.
<lifeless> dobey: what do you think of that?
<poolie_> !
<poolie_> seems like that  would make it hard to undo some changes
<lifeless> poolie_: it might; its a discussion point at the moment
<dobey> lifeless: it's not so much the web ui that bugs me, so much that i continue to get unneccesary e-mail
<lifeless> dobey: there is a separate bug I filed about that :)
<lifeless> poolie_: so the common case is one task per bug
<dobey> i would really like to be able to remove a bugtask; but shouldn't be able to if there's only one task on a bug
<lifeless> poolie_: in that case, the task would just show as invalid
<lifeless> poolie_: not show up by default in searches (thats the current behaviour anyway)
<lifeless> poolie_: in there are two tasks, and one is invalid and one is (say) wontfix.
<poolie_> yeah, i can imagine
<poolie_> the case i was thinking of is, suppose it's affecting 'bzr (Ubuntu)' and 'bzr'
<poolie_> and a cosmic-ray commenter changes 'bzr' to invalid
<poolie_> i suppose you would just click 'also affects project' again
<lifeless> you would fix this by saying 'also affects'
<lifeless> yup
<poolie_> would that resurrect the existing task?
<lifeless> something equivalent to
<poolie_> i would like the dates to remain accurate
<poolie_> such as they are
<poolie_> rather than actually deleting it
<lifeless> open question is whether the dates etc /should/ be preserved or not
<poolie_> mm
<lifeless> note that this question applies whether we reuse invalid to hide, or have a new 'deleted' status.
<poolie_> anyhow, i can see how it would be a tidy implementation
<poolie_> right
<dobey> but only allow driver/owner/maintainer/whatever to remove tasks, and not arbitrary users
<poolie_> right, the job of arbitrary users is to _add_ more task lines :)
<lifeless> the only time that this question doesn't apply is if we actually delete things - which presupposes that we've concluded the dates not mattering, and that the error rate on deletes would be low enough to not need an undo facility.
<poolie_> a la http://pad.lv/410407
<poolie_> hm
<poolie_> i think of .status as being something like a member variable of the task
<poolie_> it's pretty much presented that way in the ui and api
<poolie_> whereas deleting a task, such that you'll need to create a new one later, is more like a method
<lifeless> thats a display issue
<lifeless> we could:
<lifeless> (agurably a display issue)
<lifeless> we could:
<lifeless>  - show a button to delete
<lifeless>  - hide invalid except when there is only one task
<poolie_> i think it would be weird if, over the api
<poolie_> bt.status=invalid;bt.lp_save(); bt.status=confirmed
<poolie_> did not work
<lifeless> I agree
<lifeless> I see no reason it wouldn't
<lifeless> what is weird is that bt.lp_delete(); bt.status=confirmed;bt.lp_save() would work.
<lifeless> if we chose to expose it as a semantic delete.
<poolie_> why not just delete it?
<lifeless> destructive delete is harder to undo
<lifeless> and users make lots of mistakes
<poolie_> both true
<lifeless> that combined with a 300GB database is a pretty powerful trifecta
<lifeless> wgrant: https://launchpad.net/ubuntu/+bugtarget-portlet-tags-content (Distribution:+bugtarget-portlet-tags-content)
<lifeless>        OOPS-1933A810, OOPS-1933J816
<lifeless> bah
<dobey> if delete was restricted to privileged users though, would they really make that many mistakes?
<lifeless> fail font in chromium, I read that as JB for a second
<wgrant> dobey: Hahahah
<lifeless> dobey: privilege correlates to experience not accuracy ;)
<dobey> could preserve the history before the delete.
<lifeless> thats what this proposal does.
<dobey> lifeless: heck, i'd be happy if it was only available via API even. :)
<poolie_> well, marking the object 'deleted' or whatever is a classic way to all it to be undone
<poolie_> i guess you could start by even just hiding invalid tasks from the bug page, or not sending mail about them
<poolie_> in fact the second case is interesting
<poolie_> bug is marked invalid, then a person replies to say 'no it really is valid'
<poolie_> hm, or they change the existing task to point at the project with the invalid task
<wgrant> Past proposals have suggested that invalid tasks get bugmail when no tasks are valid.
<poolie_> and otherwise it's the job of whoever is getting the bugmail to make decisions about it?
<dobey> problem is, i don't want the bugmail :)
<wgrant> poolie_: Right.
<wgrant> poolie_: Just like if the task was retargetted.
<wgrant> Retargeted meaning having its target changed, not being targeted to a series, or targeted to a milestone.
<wgrant> lifeless: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1933A108
<wgrant> lifeless: lazr.restful's exception handling is buggy in other ways too :(
<lifeless> dobey: yes, me too
<lifeless> dobey: long list of things to fix
<lifeless> wgrant: thank you so -very very very- much for getting even this much
<wgrant> lifeless: Erm, the fix isn't landed yet, but yeah.
<lifeless> wgrant: though that looks pretty ok
<wgrant> lifeless: This isn't a timeout, so the data is fine.
<lifeless> oh of course
<lifeless> mea culpa
<wgrant> lifeless: But the traceback is obliterated by lazr.restful explicitly reraising the exception object.
<lifeless> yes
<wgrant> (in 2.7 this would work fine)
<wgrant> Er, 3.x.
<wgrant> Not backported to 2.7, is it...
<lifeless> works fine in 2.x if include the backtrace
<lifeless> 3 arg raise
<lifeless> its just poor python
<wgrant> Yeah.
<lifeless> GRAH
<lifeless> whoever thought a bug couldn't have 1000 actions
 * lifeless puts on the positive face
<wgrant> Actions as in BugActivity?
<lifeless> ROM BugActivity
<lifeless> WHERE BugActivity.bug = 659052
<lifeless> ORDER BY BugActivity.id LIMIT 1001
<lifeless> thats whats triggering the shortlimit
<wgrant> what.
<wgrant> At least there was shortlist() there to warn.
<lifeless> I think it is
<lifeless> lets check
<lifeless> yup
<jtv> hi wgrant
<wgrant> Hi jtv.
<jtv> Had a chance to look at the updated publish-ftpmaster script?
<wgrant> Not enough.
<jtv> Which, on a sidenote, I found may actually have been slower than it needed to be all this time.
<wgrant> Oh?
<jtv> I tried not to work during the holidays, honest.
<jtv> You see, it tries to update these two directories from each other using hardlinks.
<jtv> Far as I can tell, it does that by passing rsync the -H option.
<jtv> Which says "try to figure out whether there are any hardlinks within the source, and recreate those in the destination."
<jtv> Whereas what I think is really wanted is --link-dest.
<wgrant> Hmmm, -H makes sense, but I'm not sure --link-dest is what we want.
<wgrant> -H is there to not undo fdupes.
<wgrant> It's possible that --link-dest would be faster than what we have now, bit it really depends.
<jtv> Oh, so there are "meaningful" hardlinks in the publishing directory?
<wgrant> s/bit/but/
<jtv> (Besides faster, it'd also be much more space-efficient of course)
<wgrant> Saving about a megabyte, I believe, yes.
<wgrant> Right.
<jtv> There's only a megabyte in the dists directories?
<wgrant> No, I mean the current hardlinking done by dsync link-dupes saves about a megabyte.
<jtv> Oh
<jtv> But are the hardlinks significant?  Or are they still just a space-saving measure?
<wgrant> Not significant AFAIK.
<wgrant> Total space saved by merging 28.1kb. 577 files affected.
<wgrant> Oooh yeah.
<wgrant> I guess it saves inodes and a trivial amount of space.
<jtv> wgrant: it sounds pretty insignificant compared to what we could save on not duplicating the dists directory itself.
<wgrant> jtv: Indeed.
<wgrant> Although the rsync only takes 23 seconds.
<jtv> In that case, why do we go to all the trouble of re-using that directory?
<wgrant> Copying the whole thing would take much longer.
<wgrant> Hard-linking maybe not so much.
<jtv> Exactly.
<jtv> It'd even save the time of reading files.
<wgrant> Yeah. But we have to hope that nobody uses O_APPEND :)
<jtv> I guess
<jtv> Except
<jtv> no
<jtv> All the risks are from re-using the directory.
<jtv> Hmm
<wgrant> No...
<jtv> It depends on when, I guess.
<jtv> Changing a hardlinked file and then rolling back the publication would cause trouble.
<wgrant> If they're hard-linked and someone writes a file without first unlinking it, your archive is borked.
<jtv> So the risk is that publish-distro or one of the publish-distro plugin scripts might modify a file.
<wgrant> s/might/probably do/
<wgrant> In lots of places.
<jtv> Oh
<jtv> Well never mind that then.
<wgrant> Just about nothing explicitly unlinks first...
<lifeless> pop quiz
<lifeless> nvm
<lifeless> we already expose it ;0
<wgrant> jtv: Release file generation, for example.
<wgrant>         f = open(os.path.join(
<wgrant>             self._config.distsroot, suite, "Release"), "w")
<wgrant> Bye.
<jtv> Well never mind that then.
<lifeless> actually
<lifeless> here is a question
<lifeless> should we still expose an unqualified 'incomplete'
<wgrant> Yes.
<lifeless> where ?
<wgrant> Needed for backwards compatibility.
<wgrant> And stuff does use it.
<wgrant> (good luck with that)
<lifeless> wgrant: outside of migration support
<lifeless> where do you you think we should expose it?
<wgrant> I personally think that s/New/Unconfirmed/ and merge "Incomplete with response
<wgrant> " into that.
<wgrant> There's very little useful distinction.
<lifeless> wgrant: while I'm pro that thats a larger discussion to do
<lifeless> what I'm doing is materialising an inferred status
<wgrant> We're going to need to break API clients at least once.
<lifeless> so that we can aggregate it sensible.
<wgrant> Let's do it only once.
<lifeless> separate problem
<lifeless> I'm hoping not to break anything at all
<wgrant> Ah.
<wgrant> OK.
<lifeless> I'm talking about UI
<lifeless> like
<lifeless> show 'incomplete' but set to incomplete-without-response
<lifeless> thats a place I think showing incomplete is useful
<lifeless> but
<lifeless> a bug that is incomplete
<lifeless> cannot be asked for more input without toggling to new and back to incomplete.
<lifeless> this is nuts
<lifeless> so if we show the bug status as incomplete-with-reponse and show incomplete in the list
<wgrant> I guess. I am fairly strongly against making any UI changes without fixing it properly, though.
<lifeless> folk can trivially set it back to incomplete-without-response [by choosing incomplete]
<wgrant> Since this is just going to be awkward.
<lifeless> one option is to not change the ui at all
<wgrant> That would be my preference.
<wgrant> Your proposal is less awkward than the status quo, but the change is probably more awkward.
<lifeless> is getInitialValuesFromSearchParams dead code ?
<lifeless> please-say-yes-please-say-yes-please-say-yes
<wgrant> It seems to be... but that's very odd.
<lifeless> \o/
<lifeless> I'd kind of like to expose the actual status
<lifeless> why do you say a change would be awkwards
<lifeless> I wonder how many folk set 'incomplete' and *then* make a comment using ajax saying 'please tell us more'
<lifeless> thus defeating the incomplete-without-response entirely.
<wgrant> lifeless: Change to a bad solution is awkward, even if the solution is better than what we have now.
<wgrant> Particularly since we're planning to change this again in the next 12 months.
<lifeless> why is it awkward though?
<wgrant> We have a status field that doesn't show the status.
<lifeless> thats what we have now
<wgrant> It has the same idea of 'status' as most of the rest of the UI.
<lifeless> the bug search form shows two incomplete statuses
<lifeless> the drop down widget to change a bug status shows one
<wgrant> The with/without reponse statuses only show up on the search form.
<lifeless> and the bug portlet exposes that there are two in yet another way by doing incomplete(can expire) but searching for a variant again
<wgrant> On the advanced search form, even.
<lifeless> bug expiry discusses this in the various bits of help
<lifeless> so I don't know that I accept your assertion about most of the ui pretending their is one such status
<lifeless> s/their/there/
<wgrant> Mmm.
<wgrant> Well, it's a terrible mess at the moment.
<lifeless> agreed.
<lifeless> I want to understand what is awkward about reducing the amount of inconsistent UI here - by accepting that we have two incompletes and starting to propogate them.
<lifeless> we can do a totally hidden thing, I'm sure.
<wgrant> Aaaa
<wgrant> aaaaaaaaaaaaaaaaa
<lifeless> ECAT ?
<wgrant> process-accepted is crap.
<wgrant> It goes through all pending uploads.
<wgrant> processing them.
<wgrant> logging errors if they fail.
<wgrant> That sort of thing.
<wgrant> But it doesn't do any transaction stuff.
<lifeless> \o/
<wgrant> So a failed upload gets the partial state left uncommitted, so it gets committed at the end.
<wgrant> (and library files created in early uploads aren't accessible to later ones)
<wgrant> This is the sort of thing that you *really really* want to be transactional :/
<lifeless> headdesk
<lifeless> Bug.permits_expiration
<wgrant> Hmmmmmm.
<wgrant> Our Referer parsing sucks.
<wgrant> OOPS-1934A83
<wgrant> Grar.
<wgrant> Web browsers suck.
<wgrant> Backslashes are not legal URI characters, please don't send them.
 * wgrant stabs Chromium in the eye.
<wgrant> And Firefox.
<wgrant> Stop autocorrecting my backslashes to slashes.
<lifeless> wgrant: which browser ?
<wgrant> lifeless: Chromium and Firefox appear to both happily send backslashes in URLs.
<wgrant> Despite RFC2396 excluding them.
<wgrant> Why don't people follow specs :(
<wgrant> And why does Chromium insist on treating URLs as non-opaque entities to be autocorrected unoverridably?
<wgrant> Huh.
<wgrant> Firefox encodes it correctly if it's in the path, but not if it's in the query string.
<wgrant> Yeah, that's pretty clearly illegal.
<wgrant> Gah.
<wgrant> Can we please delete the Web and start over?
<lifeless> oh yay
<lifeless> unwise turns up exactly twice in 2396
<wgrant> lifeless: It's only documenting the rationale for the exclusions.
<lifeless> yeah
<lifeless> but its really strange to use a BNF rule to do that
<wgrant> It is.
<lifeless> and then not reference that elsewhere
<wgrant> Oh hmm.
<lifeless> query = *uric
<lifeless> uric = reserved | unreserved | escaped
<lifeless> reserved      = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
<lifeless>                       "$" | ","
<lifeless>       unreserved    = alphanum | mark
<lifeless>       mark          = "-" | "_" | "." | "!" | "~" | "*" | "'" |
<lifeless>                       "(" | ")"
<wgrant> Yes.
<lifeless> so yues
<lifeless> clearly FUBAR
<wgrant> In this case the URL actually comes from apport, not generated from a form.
<wgrant> However, it still sends bad stuff if you type it in the address bar :/
<lifeless> user input cannot be trusted.
<lifeless> Thats like rule 1 of programming, right ?
<lifeless> which reminds me
<lifeless> need to talk to pitti about apport + privacy.
<lifeless> but now, grocery shopping
<wgrant> Except apport generates the URL with the backslash urlencoded.
<lifeless> are you sure we aren't double decoding somewhere ?
<lifeless> -> gone
<wgrant> Other stuff is still encoded.
<16WAAA4BV> StevenK: i have 2 mp's to fix the failing windmill tests if you are interested...
<16WAAA4BV> https://code.launchpad.net/~wallyworld/launchpad/picker-textfield-plugin/+merge/57819
<16WAAA4BV> https://code.launchpad.net/~wallyworld/launchpad/fix-windmill-tests/+merge/58066
<StevenK> 16WAAA4BV: Have you seen your nick? :-)
<16WAAA4BV> yes, just now :-/
<16WAAA4BV> StevenK: sadly, those windmill tests, if run, would have prevented a ui regression :-(
<16WAAA4BV> and it's not letting me change my nick back
<StevenK> 16WAAA4BV: The windmill tests are run on Jenkins? Do you check the results?
<16WAAA4BV> looks like wallyworld is known as '16WAAA4BV' :-)
<16WAAA4BV> StevenK: i did today, but because they are not in-process, stuff got landed and merged without the failure being noticed
<16WAAA4BV> and if i had checked earlier, it would not have prevented the bad landing
<StevenK> 16WAAA4BV: Identify to NickServ as wallyworld and then release
<16WAAA4BV> we gotta get these tests reliable
<StevenK> 16WAAA4BV: I'm not comfortable enough with my JS to approve the first one, but r=me for the second.
<16WAAA4BV> StevenK: ok. i'll get someone to look at the first one later tonight. that's the real bad one which breaks the picker :-(
<StevenK> 16WAAA4BV: You could ask lifeless or wgrant to review it?
<StevenK> Or thumper if he's unbusy
<16WAAA4BV> still trying to figure out how to fix my nick
<16WAAA4BV> stupid quassel
<StevenK> wallyworld1: What error do you get if you try to change to wallyworld?
<wallyworld1> no error it just doesn't accept it. but let me try something else
<StevenK> wallyworld1: If you get the nick is in use, I daresay services has taken over your nick and you need to instruct it to release its lockout
<wallyworld1> StevenK: how do i do that?
<wgrant> StevenK: What?
<StevenK> wallyworld1: Open a query window to Nickserv and identify to it by "identify wallyworld <your password>" and then "release"
<wgrant> Oh, if you've got that extra protection on, right.
<StevenK> wgrant: And I'm not comfortable with my JS for https://code.launchpad.net/~wallyworld/launchpad/picker-textfield-plugin/+merge/57819
 * wallyworld has the right nick again
<StevenK> wallyworld: \o/
<wallyworld> StevenK: thanks for the help. i've registered it this time too :-)
<StevenK> wallyworld: You should have registered it quite some time ago :-)
<wallyworld> StevenK: yes, such a noob that i didn't know i had too
<StevenK> Registered : Oct 28 14:46:18 2000 (10
<StevenK>           years, 24 weeks, 5 days, 14:11:07 ago)
<StevenK> Bloody hell
<wallyworld> wtf? 10 years.
<StevenK> That's mine
<wallyworld> realise that :-)
<StevenK> I've been around free software for a long while
<wallyworld> StevenK: you don't look that old :-)
<StevenK> Hm, I think that's the era that #debian-devel was still on this network
<ajmitch> StevenK: not bad
<StevenK> I was ... 19.
<StevenK> wgrant still beats me, since he was 12.
<ajmitch> StevenK: funnily enough, my nick was registered 3 weeks later than yours
<wgrant> StevenK: 14 :(
<wgrant> lifeless: Aha.
<StevenK> wgrant: Which was what, 2008? :-P
<wgrant> lifeless: I grepped appserver logs.
<StevenK> ajmitch: Heh, nice.
<ajmitch> bug 434244 annoys me :(
<_mup_> Bug #434244: No search method on bugs collection in API <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/434244 >
<spm> my first patches accepted were in 1990. I had no idea was the GPL was. Opensource as a phrase was years in the future. It was just "code" and it didn't work the way I wanted on the hardware I was using; so played around with the signals generation/timing and got it mostly working.
<lifeless> wgrant: any?
<wgrant> lifeless: Well, I thought I'd found something. But just realised I was one level of encoding off.
<StevenK> spm: Patches to what, out of interest?
<wgrant> lifeless: I think the initial request was somewhat mangled by OpenID, and then subsequent requests were mangled by the browser (firefox and chromiuim show %5c as \ in the address bar, and put \ into the clipboard when it's copied)
<StevenK> "Tear down canonical.testing.layers.AppServerLayer in 3 minutes 0.709 seconds." :-(
<wgrant> But there's still an initial bug in the OpenID stuff somewhere.
<spm> gawd. wonder if I can recall what it was called. it was a graphical game that was played on X workstations. a clone of balderdash? from memory. Plus I think there were some to another game xconq. Not sure if the work we were doing on the VMS port of ISODE ever went back in as patches either. suspect didn't.
<wgrant> spm: How's it going?
<spm> still pushing
<wgrant> Looks like we may have to give up :(
<wgrant> â¦â¦â¦
<wgrant> lifeless: Have a look at form_args in lib/canonical/launchpad/webapp/login.py
<wgrant> (peril sensitive sunglasses may inhibit your viewing ability)
<LPCIBot> Project windmill build #186: STILL FAILING in 10 min: https://lpci.wedontsleep.org/job/windmill/186/
<lifeless> wgrant: thanks for the warning.
<StevenK> Can haz review from someone?
<StevenK> https://code.launchpad.net/~stevenk/launchpad/dsd-packagediff/+merge/58070
<wgrant> lifeless: So, there's the non-browser part of our problem :/
<lifeless> wgrant: the UnicodeDammit thing ?
<lifeless> ' Thanks Diogo; If LP can digest these URLs now, it seems I don't need to
<lifeless> > change anything in apport.'
<lifeless> ><
<lifeless> bad urls are bad
<wgrant> lifeless: No... it gets the values from request.form (they're decoded), and puts them back into a URL.
<wgrant> Decoded.
<lifeless> wgrant: oh. ha. ha. ha.
<lifeless> wgrant: I just saw key=value and didn't glue that to 'and those will be used in urls.'
<jtv> StevenK: I'm looking at the generate-contents script, but the /srv/launchpad.net/ubuntu-contents directory it's supposed to create isn't on mawson.  Any idea why that is?
<StevenK> Because it would take until the heat death of the universe to run on mawson.
<jtv> StevenK: this universe heat death you mentionâ¦ is it expected anytime soon?
<StevenK> I dunno
<StevenK> jtv: I doubt we've ever run generate-contents on mawson.
<jtv> Well, that certainly answers that question.  Thanks.
<lifeless> mmm corn chowder with basil.
<lifeless> nice fresh soup
<StevenK> wgrant: Bah, my clever hack doesn't work
<wgrant> StevenK: Oh?
<StevenK>         if not any((
<StevenK>             self.source_pub, self.parent_source_pub, self.base_source_pub)):
<StevenK>             return
<lifeless> bah, thai internets
<wgrant> StevenK: not all
<wgrant> StevenK: But anyway, that's wrong.
<wgrant> StevenK: You can still create a diff if just parent or source are missing.
<StevenK> This is just looking for diffs, but fair point
<StevenK> wgrant: No other tests in that file need to create SPPHs. :-(
<wgrant> :(
<wgrant> Still, you need to do it twice there, and it is ugly. Helper method.
<StevenK> wgrant: I can move the test to the job integration tests, which does have a helper method already\
<wgrant> StevenK: That sounds suboptimal.
<lifeless> what does the helper do ?
<lifeless> stub: hi there
<lifeless> oh cool, jtv is back too.
<jtv> Yes.  Hi.
<lifeless> stub: jtv: How well do array types get indexed in pg ?
<jtv> ur
<lifeless> specifically, searching for bug tags is slow
<lifeless> I'm wondering if we'd be better having them as arrays on bug
<lifeless> (rather than the key-value table they are
<jtv> Sounds like a potential win, yes
<lifeless> doing a simple foo AND bar search is triggering seq scans
<jtv> You may not be able to avoid that though.
<lifeless> jtv: perhaps you'd like to have a poke at the plans ?
<jtv> lifeless: sure
<lifeless> bug 750445 and bug 757426
<_mup_> Bug #750445: MaloneApplication:+bugs timeout on 'any tag {pcert, blockshwcert}' <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/750445 >
<_mup_> Bug #757426: Distribution:+bugs timeout with combinator ALL <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/757426 >
<lifeless> our fk for official bug tags is the text of the tag
<lifeless> so we've no referential integrity issues that I can see with moving this around
<jtv> Just about impossible to read these queriesâ¦
<stub> Yo
<StevenK> wgrant: Do you also want to review https://code.launchpad.net/~stevenk/launchpad/drop-psc/+merge/57807 ?
<stub> lifeless: There is decent support using GIN indexes. Landscape uses this. There are special operators for stuff like item in array etc.
<stub> GiST indexes too, but we prefer GIN due to low write, high read.
<wgrant> lifeless: Could you please mentor https://code.launchpad.net/~stevenk/launchpad/drop-psc/+merge/57807?
<stub> lifeless: But faster than a separate table mapping bug -> tag? Dunno.
* henninge changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: henninge | https://code.launchpad.net/launchpad-project/+activereviews
<lifeless> wgrant: can you please leave a space after urls ? :)
<wgrant> lifeless: ? on the end of a URL shouldn't matter...
<wgrant> But OK.
<jtv> lifeless: still just scanning the information, butâ¦ wouldn't an index on BugTask(importance DESC, status) take away part of the pain?
<stub> Today is the day I (literally) get off my arse and build a temporary standing desk.
<jtv> lifeless: still just scanning the information, butâ¦ wouldn't an index on BugTask(importance DESC, status) take away part of the pain?
<StevenK> wgrant: Can you have another look at https://code.launchpad.net/~stevenk/launchpad/dsd-packagediff/+merge/58070 ?
<StevenK> wgrant: I think I've addressed everything.
<jtv> lifeless: also, the queries would be tremendously easier to read if they just did "SELECT *" instead of repeating a full page of mis-indented and inconsistently capitalized column names every time!
<jtv> This is the first thing I change when I copy queries from oopses.  It really helps.
<jtv> I'm guessing you're either trying out various different phrasings for optimization, or profiling different scenarios.
<lifeless> jtv: I've found that that can mess up the timings because we have some tables with multi-MB text fields
<lifeless> jtv: I may be being overly cautious
<lifeless> stub: \o/
<wgrant> StevenK: Rereviewed. Looks mostly good.
<stub> lifeless: SELECT * performs the same as SELECT [every column in excruciating detail]
<StevenK> Mostly good? :-(
<stub> lifeless: SELECT Person.*, TeamParticipation.* for prejoins etc. too.
<lifeless> stub: yeah, but thats not the same as SELECT table1, table2
<lifeless> stub: bingo :)_
<jtv> lifeless: shouldn't matter as long as (1) you're consistent and (2) you only change the list of columns in your query, as opposed to the list of tables.
<lifeless> stub: but also factor in columns in the db that storm doesn't know about
<StevenK> wgrant: Right, so I should revert to Storm?
<wgrant> StevenK: Hmm? Use PackageDiffSet.getDiffBetweenReleases.
<stub> lifeless: That is pretty rare, and either the column shortly dropped or Storm DB class shortly extended.
<StevenK> wgrant: But how can I be sure it returns the right diff?
<wgrant> StevenK: *Between*, not To.
<lifeless> stub: fti vectors
<StevenK> wgrant: OH!
<StevenK> wgrant: Sorry
<stub> I guess. That will slow down the transmission to client time, but I don't think it slows down the query time
<StevenK> wgrant: Damn function names are too close
<lifeless> stub: remember when we were debugging that packagerelease.changelog thing or whatever it was
<lifeless> stub: the plan was much faster than the timing reported by the client
<lifeless> stub: until we actually selected the right columns
<lifeless> all I'm saying is once-bitten twice shy
<StevenK> wgrant: Er, I can't see IPackageDiffSet.getDiffBetweenReleases() defined?
<stub> analyze reports the query time, \timing reports time as seen by the client
<lifeless> stub: yup
<wgrant> StevenK: That should be but a temporary hindrance :)
<lifeless> stub: and its the \timing that matters for fixing a page; the analyze is crucial data in figuring out how to reducing the timing, but its the timing we need to care about
<StevenK> wgrant: Well, clearly one of us is wrong. I'm just trying to work out who.
<jtv> lifeless: anyway, I'd just try the indexed-array approach on staging and see what it does.  If it's too costly to add the column, consider a linking table of (bug_id, [tags])
<wgrant> StevenK: Hmm? it doesn't exist, but it should.
<lifeless> jtv: can make a temporary table with all the constraints and indices but without FK relationships quite happily.
<lifeless> jtv: its how I played with the fact table for doing aggregates
<jtv> Great.
<StevenK> wgrant: But why would you suggest a function that doesn't exist? :-)
<jtv> lifeless: How did that fact table play out, by the way?
<wgrant> StevenK: I said you should use it. I didn't say you wouldn't also have to write it ;)
<wgrant> StevenK: Basically, it's generally useful, model-specific, and longish. Should be factored out.
<StevenK> I can't use it if it's doesn't exist.
<lifeless> jtv: can do our existing 3+ second queries in 0.5s including privacy at the cost of overcounting private bugs
<lifeless> jtv: jml & flacoste are convinced that as an incremental fix-performance step this is ok and I've mailed stakeholders@ for objections.
<lifeless> jtv: anonymous user lookups it answers in 0.1s
<jtv> lifeless: I saw at least some of the list discussionâ¦ it's nice, though once you go this radical, it'd be nicer if it could be done in negligible time.
<lifeless> jtv: the table could possibly be trimmed more by discarded bugs we don't show in the portlet
<jtv> Not that 0.1s isn't about negligible!
<lifeless> the nice thing is that its 0.5seconds *cold*
<lifeless> or if not totally cold then at least lukewarm
<jtv> So that's lukewarm taken care ofâ¦ what about tepid?
<jtv> And more importantly, how fast is it at scalding?
<stub> Performance decreases when the server is on fire.
<jtv> That's scorching.  Let's not get confused here.
<spiv> stub: but a server on fire is red, and everyone knows red goes faster!
<jtv> Yeeees, but red also attracts more fines.  It's scienceâ¢.
<jtv> Interesting that so many words for temperatures should have been invented on an island that has so few.
<lifeless> jtv: so, 0.5s was when I left it overnight and tried in the morning with my test user + ubuntu
<lifeless> test user being someone in 200 teams
<jtv> So a fairly difficult case.
<lifeless> yes
<lifeless> man, the way we compile status checks is -so- bogus
<lifeless> stub: could you time this on prod - http://pastebin.com/jBbVgP8J please ?
<lifeless> I know its crap
<lifeless> its interim while we migrate crap to be less crap so the query can be less crap
<stub> After the performance drive, we can have a crap purging. Launchpad Enema.
<stub> lifeless: you want an explain or an explain analyze?
<stub> slow, slow, slow.
<stub> http://pastebin.com/vJySZ6Jb
<stub> lifeless: ^^^
<lifeless> stub: I've edited it - try again ?
<stub> lifeless: still crap
<lifeless> stub: 9.4 seconds still ?
<stub> lifeless: http://pastebin.com/03sAFpYk
<stub> Less crap, but crap
<lifeless> wow
<lifeless> stub: http://pastebin.com/B5fg7fsH
<lifeless> bah
<lifeless> failed edit
<lifeless> stub: it was the same, so that less crap is query variation
<lifeless> stub: ok, - http://pastebin.com/j62T5HyY
<lifeless> stub: nearly done - http://pastebin.com/JSad5jbs and
<stub> http://pastebin.com/KVqUabau is the first one
<lifeless> last variant - http://pastebin.com/MYU1WKFA
<stub> http://pastebin.com/2znv9HBp is the second
<adeuring> good morning
<StevenK> wgrant: Another look at https://code.launchpad.net/~stevenk/launchpad/dsd-packagediff/+merge/58070 , please?
<stub> lifeless: http://pastebin.com/bB1KXJ2S is the last variant
<lifeless> stub: thanks!
<stub> bouncy bouncy thai internet
<lifeless> stub: interesting that that triggers qual seq scans
<lifeless> stub: even though its semantically identical
<stub> qual?
<lifeless> dual
<lifeless> though bug is already being sequentially scanned
<stub> The simplest version is generally best to see how well the planner can do without help.
<lifeless> stub: the > < being the simplest version ?
<stub> When thinking about a BugSearch table containing denormalized bug information, I was thinking of using arrays for tags etc.
<stub> lifeless: Dunno. I wasn't reading the queries apart from ensuring you were not bobby tabling me :)
<lifeless> stub: :)
<lifeless> stub: I wonder if we can improve BugTask in situ
<lifeless> Bug + BugTask I guess I mean
<lifeless> anyhow, thanks for those tests
<lifeless> it says that doing compatible searches won't be a disaster
<lifeless> but sadly also that the result won't be magically faster once we migrate.
<wgrant> bigjools: Morning.
<bigjools> morning
<wgrant> bigjools: Bug #761439.
<_mup_> Bug #761439: Delayed copy publication sometimes crashes when reading changes file content <oops> <soyuz-publish> <Launchpad itself:In Progress by wgrant> < https://launchpad.net/bugs/761439 >
<wgrant> bigjools: process-accepted's transaction management is awful.
<bigjools> colour me surprised
<wgrant> bigjools: But I'm not quite sure how to fix it.
<wgrant> I'm not sure we can safely abort a transaction that encounters an exception.
<bigjools> hang on, just having to file a bug about my network card driver
<wgrant> Hah. Sure.
<lifeless> _getUnconfirmedBugCondition - so if one target expires, the entire bug gets expired.
<StevenK> wgrant: *prod*
<lifeless> ><
<wgrant> StevenK: 'tis done.
<wgrant> lifeless: Hah, fun.
<StevenK> wgrant: Thanks
<bigjools> I guess it's the kernel I need to file it on
<lifeless> that implies that a single incomplete task cannot expire if any task is valid
<lifeless> or something
<wgrant> lifeless: Want to mentor https://code.launchpad.net/~stevenk/launchpad/dsd-packagediff/+merge/58070?
<wgrant> lifeless: That's intended behaviour, yes.
<wgrant> lifeless: Tasks should will not expire if the bug is known to be valid.
<lifeless> wgrant: that means that as a developer of project X and a bug with an added task, I cannot say 'hey, tell me if X so I can see if its relevant here' and have it expire out of my project.
<lifeless> wgrant: if the bug also has a task on Y, which I don't care about.
<wgrant> lifeless: Sure, I didn't say it was reasonable behaviour.
<StevenK> wgrant: I can't remove the intermediate use, they're set if either SPPH is None
<lifeless> !hah
<wgrant> StevenK: if blah: self.parent_package_diff = None; else: self.parent_package_diff = ...
<StevenK> Bleh
<StevenK> But okay
<wgrant> StevenK: Really you want a ternary statement. But I think they were only allowed into Python with a syntax so abhorrent that nobody could use them.
<StevenK> Haha
<lifeless> trueclause if condition else falseclause
<bigjools>  /vomit
<lifeless> nowhere near a strong enough reaction
<lifeless> personally I think this was a huge troll on guidos part
<lifeless> like
<wgrant> lifeless: That was my point, yes.
<lifeless> how bad can we make things in the name of backwards compat
<wgrant> He only permitted them with an utterly atrocious syntax.
<wgrant> Just to spite people.
<wgrant> To stop them complaining about the lack of it.
<lifeless> and then that can be used to get leverage to make py3k break compat
<wgrant> Hah
<StevenK> Ooooh, languages features as a stick
<wgrant> Ahhh py3k.
<wgrant> Such a wasted opportunity :(
<bigjools> wgrant: can you describe  the scenario in that bug
<bigjools> is the whole session in a single txn?
<wgrant> bigjools: The entire script run, yes.
<bigjools>  /vomit
<wgrant> bigjools: So, what happens here is that there are two delayed copies of the one source.
<wgrant> bigjools: THe first one unembargoes the files, including the changes file.
<wgrant> The second one sees the new changes file LFA, tries to read it.
<StevenK> lifeless: Can haz mentor of https://code.launchpad.net/~stevenk/launchpad/dsd-packagediff/+merge/58070 ?
<wgrant> Not committed yet, so not accessible from the librarian.
<wgrant> Boom.
<bigjools> wgrant: yay
<bigjools> wgrant: so what's the issue with adding transactions?
<wgrant> bigjools: I could just commit after each PU. But I'm not sure if we should abort on failure instead.
<wgrant> bigjools: Since part of a PU could have hit disk.
<wgrant> eg. the source could be published.
<bigjools> wgrant: it sounds like we need either commit() or abort() after processing each queue item
<wgrant> So the file is on disk, but the abort would revert the status from published to pending.
<wgrant> Right.
<wgrant> But I'm not sure if abort() is safe.
<bigjools> why?
<bigjools> if it's not, we've got much bigger problems :)
<wgrant> We do have much bigger problems, yes, but I'm not sure if they're actually that much of a problem.
 * bigjools cries: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/764334
<_mup_> Bug #764334: Network card driver failure, stack trace <linux (Ubuntu):New> < https://launchpad.net/bugs/764334 >
<wgrant> I guess worst case there is a bit of cruft left on disk if we screw up manual cleanup.
<bigjools> you might as well just do it, it seems wrong otherwise
<wgrant> Yeah.
<bigjools> and any abort should probably reject the queue item as well
<wgrant> No. That's exactly what we don't want to do.
<bigjools> well if it's going to crash and crash it will stick there for ever
<wgrant> That *will* leave bad cruft on disk forever.
<wgrant> Since we don't have a transactional FS.
<bigjools> what will get left?
<wgrant> eg. we're processing a delayed copy.
<wgrant> We publish the source to disk.
<wgrant> It gets set to Published.
<wgrant> Then publishing a binary crashes, so the transaction is aborted and the PU gets set to Rejected.
<bigjools> ok
<wgrant> Now we have the source file on disk forever, while there is no publishing record.
<bigjools> I keep forgetting that p-a puts stuff on disk :/
<wgrant> Yeah.
<wgrant> We need diskless archives :(
<bigjools> it is somewhat concerning that kpackagekit has been waiting for grub to install for 5 minutes now :/
<wgrant> Or just transactional filesystems.
<wgrant> Which only really Windows has :(
<bigjools> oh FFS, server down AGAIN
<bigjools> that should not make dpkg hang
<wgrant> Yay
<bigjools> it's rather sad that I need to use reisub on my server all the time
<mrevell> Good morning -devers
<wgrant> bigjools: Ew. What sort of hardware is it?
<bigjools> wgrant: built-in skge gigabit
<bigjools> going meh
 * StevenK attempts to get lifeless' attention again
<StevenK> lifeless: Clearly, not important enough to get your attention. :-P
<lifeless> StevenK: hmm?
<StevenK> [18:14] < StevenK> lifeless: Can haz mentor of  https://code.launchpad.net/~stevenk/launchpad/dsd-packagediff/+merge/58070 ?
<StevenK> lifeless: I've been attempting to get your attention for 35 minutes with little success
<lifeless> StevenK: I have it open in a tab
<lifeless> StevenK: its 8:40 at night; I have a mild headache
<bigjools> StevenK: https://code.launchpad.net/~julian-edwards/launchpad/schema-distro-parents/+merge/57898
<bigjools> stub: can you look at that --^ too please, it needs DB review-fu
<bigjools> lifeless: feel free to look from an architect pov
<stub> jtv: I discovered your notes on the pqxx wiki more up to date than the ones I was working from, so am making progress on dropping branchrevision.id
<bigjools> stub: do I need to buy you cookies or ammo to get a db review? :)
<stub> depends on the code quality. Will I need a beer or ammo after seeing it?
<bigjools> hopefully not both
<stub> schema-distro-parents?
<stub> Oh yay. A derived distro can have multiple parents?
<bigjools> stub: tes
<bigjools> yes*
<jtv> stub: oh!  that's great news
<jtv> bigjools: buy him beer first.  His shooting may be less accurate given enough of that.
<stub> jtv: Only issue I'm seeing is that final update is updating 0 rows... will investigate after review. Perhaps you where using an existing UNIQUE constraint and the index I've picked isn't one?
 * jtv looks up his own wiki
<bigjools> jtv: that was my worry, he'll start hitting stuff
<jtv> stub: quite possible, yes
<jtv> bigjools: and by the way, for the last time: I made him write down the bit about ammo.  He's not the gun nut.
<stub> I'll try with the other index later - it doesn't matter *that* much which one I run with.
<stub> I wouldn't hurt a fly.
<jtv> #$%@ bug spam
<bigjools> jtv: I know, but you didn't have the guts to stand up and do the presentation
<stub> You won't feel a thing.
<bigjools> ;)
<jtv> I would hurt a spammer
<jtv> bigjools: classic misdirection.
<stub> bigjools: So we don't need a priority or something to tell which parent overrides which if there are conflicts?
<bigjools> stub: conflicts in what?
<stub> I dunno. I was thinking a derived distro is a set of packages inherited from a parent, with overrides.
<bigjools> normally the higher package version wins
<stub> Excuse my naivety :)
<bigjools> excused :)
<bigjools> it's a hard feature this
<bigjools> the package conflicts will be dealt with elsewhere anyway
<wgrant> bigjools: Hm, so it's going to inherit from -updates and stuff?
<stub> So If I inherit from two distros, one of which has a policy where packagex is pinned at version 2.0, then I'll end up with the newer version of packagex unless I somehow pin it too?
<wgrant> eg. natty is going to show maverick-updates?
<bigjools> wgrant: no
<bigjools> won't work like that
<bigjools> unless you're stupid enough to set it up like that
<wgrant> Well, how will it not?
<wgrant> How do we have a maverick->natty relationship?
<bigjools> it's a single inheritance
<bigjools> besides
<jtv> stub: my impression is that if that last update didn't update anything, the index may have been created by a unique constraint in the database you're working with.
<bigjools> natty does does not inherit from maverick
<stub> I don't quite understand what 'initialized' does, but you are reasonably sure a boolean is suitable rather than an enum?
<wgrant> bigjools: It was initialised from maverick.
<wgrant> bigjools: And the relation needs to be stored in the DB.
<bigjools> wgrant: nope :)
<wgrant> bigjools: for at least createMissingBuilds.
<bigjools> it was initialised from Debian
<wgrant> Ubuntu was.
<wgrant> Natty was not.
<bigjools> yes, it was
<bigjools> in our model
<wgrant> So IDS does not initialise?
<bigjools> initialisation happens once
<wgrant> What does IDS do, then?
<bigjools> adding a new series is not quite the same thing, although it looks similar
<bigjools> it's semantics
<wgrant> Since it apparently doesn't initialise.
<wgrant> Anyway, apart from semantics, how is this going to be modelled?
<wgrant> Natty has two parents, only one of which should show up on +localpackagediffs.
<wgrant> This table doesn't support that.
<bigjools> stub: yes, should be, we just use it to indicate to various parts whether it was initialised or nto
<bigjools> natty does not have 2 parents
<stub> What are nattys parents btw.? Debian (mumble) and Maverick?
<bigjools> it inherits from Debian, end of story.
<stub> Cool.
<wgrant> bigjools: But LP code needs to know that it inherits from maverick too.
<bigjools> where?
<bigjools> and why?
<bigjools> we've already discussed this in the team
<wgrant> getBuildForArch traverses the tree to avoid creating builds where one exists in an earlier series.
<wgrant> That's the only case I know of off-hand.
<wgrant> (that's used by createMissingBuilds)
<bigjools> it doesn't need parent_series to do that
<wgrant> (so please don't break it
<wgrant> Oh?
<bigjools> it's fairly trivial to iterate over series ...
<bigjools> (in the same distro)
<wgrant> Um, ew.
<bigjools> dude
<wgrant> What about Debian?
<bigjools> sigh
<wgrant> Debian isn't a series of series.
<wgrant> We need to think carefully about this before we throw away a relationship that code needs!@
<stub> This is an implicit relationship because we don't have derived distros at the moment?
<wgrant> It's explicit. DistroSeries.parent_series.
<wgrant> natty's parent_series is maverick.
<wgrant> etc.
<stub> The patch is not throwing that away yet.
<wgrant> It's not.
<wgrant> But it seems to be suggested that this new table will supersede it.
<wgrant> When it cannot.
<wgrant> (without extension)
<stub> Right. But if you two can't agree atm, then code can talk. Or are we talking about a more fundamental change to the data model to add in the relationship you say we need?
<wgrant> I think that it's probably a good idea to get the DB patch correct now, since correcting it is slow, hard, and migrating data sucks.
<bigjools> nothing is changing with parent_series right now, please stop talking about it.  We're moving the concept of *tracking derived distros* to a separate table
<lifeless> bigjools: is there any precedence rules between parents ?
<henninge> bigjools: I just reviewed your branch for that, please have a look.
<wgrant> ... to a table named DistroSeriesParent, but OK.
<bigjools> henninge: not seen your review yet I am just fixing the security adapter BTW :)
<bigjools> lifeless: no
<henninge> bigjools: ;-)
<stub> If the data model needs extension, would it actually get as far as accumulating production data? I would have thought the test suite would pick up the lack.
<lifeless> wgrant: getBuildForArch has to stay in the same archive right ?
<wgrant> lifeless: At the moment.
<wgrant> lifeless: It's not clear how it works in a multi-archive world.
<lifeless> for the use case of avoiding builds of something already in the archive
<lifeless> (createMissingBuilds)
<wgrant> Right.
<wgrant> Probably.
<wgrant> Except maybe not.
<lifeless> that seems to be a definitional thing
<lifeless> like
<wgrant> createMissingBuilds is overcomplicated crack with triplicated checks.
<lifeless> it should be 'grab the archive; for all series in the *archive* check for existing builds*'
<wgrant> The behaviour in this case is not well defined.
<bigjools> lifeless: the use case is that OEM will make sure packages don't get duplicated
<wgrant> That may be the solution.
<lifeless> bigjools: as in they will scream if we get it wrong ? ;)
<wgrant> But we need to have some idea that there is an alternate solution before we go making changes that can only be fixed once a month.
<bigjools> lifeless: *they* get it wrong you mean? :)
<lifeless> wgrant: I grant you that
<lifeless> wgrant: OTOH the field in question isn't gone yet
<henninge> bigjools: I assume you are just fixing the one adapter, not all uses of check_permission?
<lifeless> wgrant: its when *that* is proposed I'll start getting the padded underwear if we don't have answers for key questions
<bigjools> lifeless: they have checks already to see when critical packages are superseded somewhere else, and they act on that
<lifeless> wgrant: I agree that data modelling and migration is expensive
<bigjools> henninge: just the one
<henninge> bigjools: ok, I'll whip up a branch for a general fix.
<wgrant> lifeless: I figured I might as well raise the potential issues now rather than in two months when deadlines are approaching and the data model cannot be fixed in a sufficiently timely fashion.
<lifeless> wgrant: but I think putting a lot of stress on this patch isn't needed because there isn't any modelling or migration to do yet.
<bigjools> henninge: you're a star
<lifeless> wgrant: its good to have the conversation
<lifeless> wgrant: I think it can be a little less stressful
<lifeless> bigjools: I suspect we'll need to iterate on this a little; I also suspect that its got a potential boobytrap built in which is that:
<lifeless>  - we want an ordering of series in an archive (don't we?)
<bigjools> lifeless: we already have that
<lifeless>  - DistroSeriesParent is cross-archive
<bigjools> intentionally
<lifeless> bigjools: will we still have that if we go forward and supersede .parent_series with DSP ?
<lifeless> bigjools: right, I get that DSP is (and needs to be) cross-archive.
<bigjools> parent_series may or may not get superseded by DSP, it's completely orthogonal to this
<lifeless> bigjools: your cover letter was a bit more gung ho about that :)
<bigjools> it was? :)
<lifeless> 'This will eventually replace DistroSeries.parent_series as we need to track more than one parent for a derived series'
<bigjools> s/will/may/ :-)
<lifeless> ahhh :)
<bigjools> well
<bigjools> it's taken in the wrong context
<wgrant> Ahh. I read it as "this is going to replace parent_series as soon as we can migrate the code"
<bigjools> everyone stop
<bigjools> we are currently using parent_series for 2 things
<bigjools> that was a mistake
<bigjools> I am migrating the 2nd usage to a separate table
<bigjools> hence the language in the MP
<bigjools> which I can see was rather confusing
<bigjools> so my apologies for that
<lifeless> bigjools: no worries
<lifeless> I'm a hearty +1
<bigjools> :)
<bigjools> there will be some issues around precendence I expect
<lifeless> yes
<bigjools> precedence, too
<lifeless> but its a small table
<stub> review is already in anyway :)
<bigjools> but only when the versions are the same
<lifeless> and you know the db deploy schedule :)
<bigjools> yes :)
<lifeless> a more interesting question for me is the impact on queries
<lifeless> but as we haven't got this live at all its hard to tell
<lifeless> you may find you want an array in DistroSeries instead.
<lifeless> EFUTURE
<bigjools> henninge: grar, unused setup!  forgot to remove that
<henninge> bigjools: I thought so
<bigjools> lifeless: array column?
<bigjools> *gibber*
<wgrant> It's less slow.
<wgrant> But a bit more evil.
<stub> wgrant: You assuming or have some evidence? I haven't tested anything with arrays yet.
<bigjools> henninge: for my own info, how can a separate user happen when using check_permission in the adapter?
<wgrant> stub: Well, for some queries it will be quicker. If you can grab the field directly rather than joining. But for this case it shouldn't matter unless your code is terrifyingly naÃ¯ve.
<henninge> bigjools: I think it is more a theoretical possibility.
<henninge> bigjools: still, I find it a waste that we already know the user and make the machinery go through all that again.
<bigjools> henninge: it certainly has me scratching my head as to how
<bigjools> yes, that is a far better reason :)
<bigjools> it'll be quicker to do it that way
<henninge> bigjools: could not some-one come up with code that calls checkAuthenticated directly, to check permission for another user?
<henninge> In that case the adapter would still check his own permissions.
<henninge> So it is also a bad interface because it pretends to do something (check permission for a given user) which it doesn't.
<bigjools> I think I'd need to see an example
<bigjools> but don't worryu
 * bigjools thinks the "insert" button needs to hang in hell
<lifeless> henninge: bigjools: separate user cannot happen in *lp*, can happen in *zope*
<lifeless> we cripple the interaction model somewhat
<wgrant> But we can still call IAuthorization adapters with something other than the requesting user.
<lifeless> I'd actually like to uncripple it so that we can have impersonation
<bigjools> ah ok
<lifeless> night all
<wgrant> Night lifeless.
<deryck> Morning, all.
<wgrant> Hi deryck.
<wgrant> Do you have any more insight into the windmill timeouts? I had to turn off YUITestLayer :/
<deryck> wgrant, I don't, sorry.  Was on vacation most of last week, so haven't really had time to look into it yet.
<wgrant> Ah, sure.
<LPCIBot> Project devel build #648: FAILURE in 5 hr 0 min: https://lpci.wedontsleep.org/job/devel/648/
<henninge> lifeless, bigjools: either of you want to review my branch for this?
<henninge> https://code.launchpad.net/~henninge/launchpad/devel-764406-security-adapters/+merge/58109
<danilos> henninge, hi, I've got a nice oversized JS branch up for review :)
<danilos> henninge, https://code.launchpad.net/~danilo/launchpad/bug728370-action-display/+merge/58108 if you think you'll have time for it
<henninge> Hi danilos!
<stub> jtv: So that final update is incorrect, because with BranchRevision the existing UNIQUE indexes are linked to UNIQUE constraints. The end result is a table that looks and smells like it has a primary key, but the pg_constraint table contains no contype='p' rows for the branchrevision table.
<wgrant> henninge: Do you have any suggestions for answering the question in #launchpad?
<jtv> stub: hang on, looking up the page againâ¦ did that last update constrain for contype='p'?
<jtv> I thought the last update was for dependencies?
<stub> jtv: Oh... it isn't the final query that is the problem.
 * jtv is slightly less confused now
<jtv> stub: what query is then?
<stub> I'll need to step through this some more tomorrow. At some point, the 'p' row in pg_constraint disappears.
<stub> jtv: Ahh... it disappears when I drop the id column.
<jtv> Hmm
<jtv> I thought I transferred it to the new key.
<stub> jtv: pebkac. Think I should stop now :)
<jtv> stub: we should have T-shirts with a gunsight aimed at a foot (toes pointing away from the gun) and some inspirational slogan.
<lifeless> 'I /hack/ on Launchpad'
<bigjools> well, we have a team meeting coming up, maybe mrevell-lunch can do the bizness :)
<stub> jtv: So now I end up with an index that is used by both a UNIQUE and a PRIMARY KEY constraint :)
<jtv> ooh kewl
<jtv> see if you can start a fire in the DC
<stub> This is only visible in the pg_constraint table so non-obvious
* benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: henninge, benji | https://code.launchpad.net/launchpad-project/+activereviews
<bigjools> stub: around?
<bigjools> I can't remember if unreferenced LFAs get GCed
<wgrant> bigjools: Yes.
<wgrant> After some timeout.
<bigjools> so setting the expiry is not necessary, great
<wgrant> One of the timeouts is a week, the other 24 hours. Can't remember which is which.
<bigjools> expiry is a week
<wgrant>     This is the second step in a full garbage collection sweep. We determine
<wgrant>     which LibraryFileAlias entries are not being referenced by other objects
<wgrant>     in the database and delete them, if they are expired (expiry in the past
<wgrant>     or NULL), and if they have not been recently accessed (last_access over
<wgrant>     one week in the past).
<wgrant> I always forget that detail about the expiry field.
<wgrant> NULL is now. expiry is used to *extend* lifetime, not restrict it.
<bigjools> fun
<deryck> henninge, standup ping
<henninge> oh
<henninge> deryck: ...
<henninge> coming
<henninge> deryck: notebook hang :(
<jcsackett> sinzui: per chat on friday, i'm available for mumbling through permissions whenever is good for you.
 * jcsackett sees sinzui is not online. stops talking.
<deryck> it feels weird sinzui not being online, doesn't it?
<benji> henninge: if you get a chance, I have a branch up for review: https://code.launchpad.net/~benji/launchpad/direct-personal-subscription-actions-scaffolding/+merge/58124
<bigjools> henninge: I replied to your review
<henninge> benji: did you take danilos?
<danilos> henninge, he did
<henninge> danilos: sorry, lunch and other things got in the way ...
<danilos> but I've got another one up: https://code.launchpad.net/~danilo/launchpad/duplicate-pillars-subscriptions/+merge/58135
<adeuring> henninge, benji: could one of you please have a look at this mp: https://code.launchpad.net/~adeuring/launchpad/api-query-permissions-on-object/+merge/58136 ?
<danilos> heh, it's getting crowded :)
<henninge> danilos: I'll have a look after I replied to bigjools and looked a benji's.
<danilos> henninge, thanks
<jcsackett> sinzui: per chat on friday, i'm available for mumbling through permissions whenever is good for you.
<deryck> sinzui, I'd like to voice chat sometime today when you have time.  no rush.  Since Orange is joining Green on maintenance.
<adeuring> henninge, benji, ping
<henninge> bigjools: r=me, thank you ;)
<henninge> adeuring: yes?
<sinzui> deryck: fab, I'll be available in 15 minutes
<henninge> benji: thanks for your review
<benji> my pleasure
<adeuring> can you have a look at this MP: https://code.launchpad.net/~adeuring/launchpad/api-query-permissions-on-object/+merge/58136
<adeuring> henninge: , benji: ^^^
<bigjools> henninge: and thank *you* :)
<deryck> sinzui, ok, cool.  Thanks!
<henninge> adeuring: benj's is first
<henninge> ;-P
<adeuring> henninge: sure ;)
<allenap> henninge, benji: Will either of you have time to review a 240-line branch? https://code.launchpad.net/~allenap/launchpad/no-diffs-for-underprivileged-bug-760648/+merge/58137
<benji> allenap: I'm sure one of us will.
<allenap> Cheers :)
<henninge> benji: spaces as seperator for feature flag fields work just as well.
<benji> henninge: cool, I didn't know that; thanks
<benji> we should ditch the tabs then; they're especially irritating in text boxes
<bac> benji or henninge: could you have a look at https://code.launchpad.net/~bac/launchpad/bug-761124/+merge/58140 please?
<benji> bac: sure
<danilos> benji, how's the review coming along? I am about to leave so if you've still got a long way to go, I am sure gary_poster can pick it up for me :)
<danilos> ah, it's there :)
<benji> :)
<danilos> benji, as for the whitespace, I noticed that gary_poster and I have different practices :)
<benji> it's the story of our lives
<danilos> benji, also, the thing jslint complains about is var not being at the top of function definition with "for (var index in ...)"; does that make sense to you as well?
<LPCIBot> Project windmill build #187: STILL FAILING in 1 hr 1 min: https://lpci.wedontsleep.org/job/windmill/187/
<benji> danilos: I'm not sure why it complains about that one, but I'm a make-lint-happy-unless-I-have-a-really-good-reason kind of guy, so I'd go along with it
<benji> danilos: as I said, I'll be doing a big lint branch today, so no need for you to change anything
* henninge changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: benji | https://code.launchpad.net/launchpad-project/+activereviews
<henninge> benji: I see how things are piling up but I have to run... sorry
<benji> henninge: no problem, I'll plow through them
<henninge> cool, thanks
<henninge> ;)
<sinzui> deryck: mumble?
<deryck> sinzui, indeed.  Firing it up now.
<deryck> sinzui, meet me in the orange 1 o 1, please.
<bigjools> to anyone who knows about our appserver innards, I'm seeing a request going to dogfood that is crashing out with a database IntegrityError, but no oops is generated and Apache returns a 502 proxy error.  Why would it not oops?
<adeuring> abentley: fancy a review of this branch: https://code.launchpad.net/~adeuring/launchpad/api-query-permissions-on-object/+merge/58136 ? (seems that henninge and benji are quite busy.)
<LPCIBot> Project devel build #649: STILL FAILING in 5 hr 3 min: https://lpci.wedontsleep.org/job/devel/649/
<bigjools> good night all
<abentley> adeuring: still around?
<adeuring> abentley: yes
<abentley> In your branch, why are you raising Unauthorized yourself instead of providing a permission checker?
<abentley> adeuring: On line 78, you mention "bug xxxxxxxxx".  Have you filed a bug for that?
<adeuring> abentley: gahhh, forgot that. Let me do it now...
<abentley> adeuring: Also, could you use ILaunchBag.user rather than interaction.participations[0].principal?
<adeuring> abentley: that was a suggestion from gary
<gary_poster> argument: he is actually dealing with security machinery, so look at security machinery for value.
<gary_poster> don't feel strongly about it
<gary_poster> but still seems reasonable to me
<gary_poster> could make for better unit tests
<abentley> gary_poster: counter-argument: I've never dealt with interaction.participations[0].principal and would have to guess what it meant.
<gary_poster> abentley: you are the reviewer, your call.  :-) adeuring is dealing with low-level Zope security machinery here, so it seems appropriate to do what I suggested: Launchpad's overlay relly is irrelevant.  <shrug>
<gary_poster> really
<abentley> gary_poster: If ILaunchBag.user can differ from interaction.participations[0].principal then I guess I need to understand when and how.  If it can't, then I don't see why we would deviate from our usual idiom.
<gary_poster> abentley, it should not within LP.  "don't see why":I'll defer to you.
<abentley> adeuring: please change it to ILaunchBag.user per "There should be one-- and preferably only one --obvious way to do it."
 * gary_poster can't stop himself: obvious according to whom?
<adeuring> abentley: ok, I don't that much. (sorry for silence, had a phone call)
 * gary_poster goes away
<abentley> gary_poster: Dutch people, apparently.
<gary_poster> :-)
<abentley> gary_poster: jelmer's dutch, should I ask him?
 * gary_poster is half Dutch
<abentley> adeuring:  In your branch, why are you raising Unauthorized yourself instead of providing a permission checker?
<adeuring> abentley: oops. right...
<adeuring> abentley: but then I'll finish the branch as late as tomorrow ;)
<abentley> adeuring: That's okay.  I've got other fish to fry today.
<adeuring> ok
<jcsackett> benji: super short review for you, if you have the time: https://code.launchpad.net/~jcsackett/launchpad/bug-expiration/+merge/58168
<benji> jcsackett: sure
<benji> jcsackett: done
<jcsackett> benji: thanks!
<mrevell> Night all
* lifeless changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: benji | https://code.launchpad.net/launchpad-project/+activereviews
<abentley> lifeless: injecting the permissions into the json cache only helps at page load time.
<abentley> lifeless: We also need to evaluate the permissions when we retrieve the objects over the web service.
<lifeless> abentley: that surprises me
<lifeless> abentley: can you help me understand why thats needed ?
<abentley> lifeless: A +sharing-details page may start with no productseries associated with the sourcepackage.  When the user adds a productseries, we need to know whether the user can change the branch associated with the productseries.
<lifeless> ok
<lifeless> adding a productseries is a named method right ?
<abentley> lifeless: yes.
<lifeless> so, I can suggest alternative implementations here
<lifeless> such as return the permissions with the result of the add
<lifeless> or do a separate lookup (though latency is a pain)
<abentley> lifeless: Yes, the reason I asked for them to be properties was to avoid latency.
<lifeless> I understand - and sympathise - the problem though is simply that lazr evaluates -all- properties every time
<lifeless> and permission checks are often very expensive
<abentley> lifeless: another option would be to use the json cache and then provide a way to get an updated version of the json cache.
<lifeless> abentley: that sounds like an interesting approach
<lifeless> because the json cache is tailored to the page AIUI
<abentley> lifeless: it would slay a lot of other latency concerns I have, too.
<abentley> lifeless: The json cache is tailored per-view.
<lifeless> abentley: excellent!
<abentley> lifeless: well, except that it's scope-creepy.
<lifeless> in terms of feature delivery? I guess yes :(
<abentley> lifeless: Originally, we were just going to expose Person.canWrite etc.  But that doesn't work because lazr.restful doesn't support dynamic typing.
<lifeless> yeah, I saw the comment
<lifeless> its a shame, that would have been fairly pithy
<lifeless> would still have incurred a round trip for you
<lifeless> abentley: I don't want to leave you & your team hanging
<lifeless> abentley: would doing a separate round trip be tolerable for the page? If so that seems like low development overhead (change the property to a method)
<abentley> lifeless: We could certainly start there.
<abentley> lifeless: I have no idea what the performance of the page is like on production.
<lifeless> only one way to find out
<abentley> lifeless: about 2 seconds.
<abentley> lifeless: for natty/bzrtools on qastaging
<lifeless> abentley: thats from choosing the productseries till it shows up in the form, or the initial page load?
<abentley> lifeless: the former.
<lifeless> if you unset it
<lifeless> and set it again
<lifeless> it may be faster
<lifeless> qastaging only holds about 5% of the prod DB in RAM
<abentley> lifeless: I did actually.
<abentley> lifeless: that time's from the second run.
<lifeless> ah
<lifeless> doh !
<lifeless> possibly too many collections on the object being altered
<lifeless> lazr restful snapshots can be reallly expensive
<abentley> lifeless: You mean that the object in question has too many collections, making snapshotting expensive?  You don't mean altered collections?
<lifeless> right
<abentley> lifeless: It looks like one of the AJAX requests is 1.2 seconds, but I can't tell what the request was.
<lifeless> yeah
<lifeless> thats coming
<lifeless> using the chromium or firefox debug tools can give better insight, if you know you need it
<abentley> lifeless: looks like setPackaging is the big delay, and that's not exactly optional...
<lifeless> ah
<lifeless> I'm on a call now - sorry
<LPCIBot> Project windmill build #188: STILL FAILING in 1 hr 1 min: https://lpci.wedontsleep.org/job/windmill/188/
<thumper> morning
* benji changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews
<sinzui> flacoste: are you serious should be accepted  bug 728408? Lp's font size is the same as other canonical sites and the user who reported the bug did not know how to zoom his browser
<_mup_> Bug #728408: Launchpad font is far too small <Launchpad itself:Triaged> < https://launchpad.net/bugs/728408 >
<sinzui> flacoste: I think huw and UX may be the only people who can say it is a bug
<mwhudson> thumper: huh, the boost import failures are obscure
<thumper> mwhudson: yeah
<thumper> NFI what is going on there
<thumper> mwhudson: any idea how we can bootstrap it?
<mwhudson> thumper: if i had to guess, i would say some kind of DOS prevention on the server
<mwhudson> thumper: not really
<thumper> I'll look to see if they have an anon svn protocol server
<thumper> that'd be faster
<flacoste> sinzui: then be my guest and mark it as invalid
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project devel build #650: FIXED in 5 hr 14 min: https://lpci.wedontsleep.org/job/devel/650/
<sinzui> jcsackett: mumble
<sinzui> ?
<lifeless> flacoste: btw
<lifeless> flacoste: bug expiry should be fixed in a day or so
#launchpad-dev 2011-04-19
<jcsackett> sinzui: seems i was disconnected from my irc bouncer earlier. you want me to join the 7pm standup to catch up?
<sinzui> If you want time
<jcsackett> sinzui: i'm at my computer now anyway. :-)
<wgrant> sinzui: Can we increase the WIP limit on Development/Coding, given the squad is now larger?
<hassan1990> hi there, I need some help about creating a branch based on another person branch on launchpad using bazaar.
<spiv> hassan1990: #launchpad is a better channel.  The quick answer is "bzr branch lp:~another-person/proj/branch lp:~/proj/branch"
<LPCIBot> Project windmill build #189: STILL FAILING in 1 hr 11 min: https://lpci.wedontsleep.org/job/windmill/189/
<poolie> lifeless/whoever, what do you think about bug 745801?
<_mup_> Bug #745801: system-based authorization doesn't store useful credentials in gnome-keyring <amd64> <apport-bug> <natty> <launchpadlib :Triaged> <python-launchpadlib (Ubuntu):Triaged> < https://launchpad.net/bugs/745801 >
<poolie> hm, that's a lame question
<poolie> a better one is, if i proposed just disabling keyring integration, would you merge it?
<poolie> it seems highly flaky in launchpadlib in natty
<lifeless> my problem here is I don't know who the stakeholders are.
<lifeless> *I* was certainly happy with what we had before.
<lifeless> gary or flacoste or jml may know more.
<lifeless> prior to the reorg changes to dependent libraries don't seem to have been as visible to jml as I'd like them to be
<poolie> _i_ would like this to progress because
<poolie> well, it breaks me nearly every time i run feed-pqm
<poolie> and secondly because it hurts vorlon and jamesw
<poolie> i realize it's already critical
<poolie> maybe i should mail -stakeholders?
<poolie> i realize too there are a lot of critical bugs
<lifeless> so
<lifeless> I'm easy
<lifeless> uhm
<lifeless> gaining traction on this
<lifeless> probably need to talk to skaet (rm of ubuntu, its -very- late to be rolling an API break back)
<poolie> oh
<poolie> you might think i'm talking about a different bug
<poolie> this is not the api break one
<poolie> i think that horse has bolted
<lifeless> also need to talk to the stakeholders that wanted it in the first place (because if this is a feature goal for ubuntu, its a Big Deal to disable it)
<poolie> this is that lplib tries to use gnome keyring but gets it wrong
<lifeless> I don't know if they are directly on -stakeholders, but I would expect -stakeholders to know who they are
<poolie> of course we could just fix it
<lifeless> that would be good too
<poolie> i don't want to spend days on it
<poolie> we don't know exactly what the problem is and so that makes it a bit hard to estimaet
<lifeless> james seems to have a pretty solid direction towards isolating it
<poolie> should i do this, or do you think an lp dev will get to it?
<lifeless> our bias is oldest-first of criticals
<lifeless> I think if you do it it will happen a lot faster than otherwise
<poolie> k thanks, i'll take a break then have a quick shot at it
<poolie> ta
<LPCIBot> Project windmill build #190: STILL FAILING in 1 hr 2 min: https://lpci.wedontsleep.org/job/windmill/190/
<wgrant> lifeless: https://code.launchpad.net/~wgrant/launchpad/unbreak-api-timeouts/+merge/58226
<lifeless> https://bugs.launchpad.net/launchpad/+bug/745799/comments/7
<_mup_> Bug #745799: DistroSeries:+queue Timeout accepting packages <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/745799 >
<wgrant> lifeless: Yup.
<wgrant> lifeless: I glanced at it over the weekend and saw it looked like strucsubs.
<wgrant> Yay.
<lifeless> wgrant: :( - you could have commented !
<wgrant> It was a glance, not a useful analysis like that.
<wgrant> It wasn't in oops-tools at that point, so I couldn't get much useful out of it.
<wgrant> Beyond "oh look, lots of structsub queries. what a surprise"
<lifeless> :)
<jtv> This is our mission, right here.  To fix this: http://theoatmeal.com/blog/fix_computer
<wgrant> Javaâ½ Now that's just low.
<wgrant> lifeless: Thanks.
<huwshimi> Why icing for the css + junk folder? What's the history there?
<lifeless> huwshimi: context?
<wgrant> The CSS and JS is just icing on top of the HTML.
<jtv> wgrant: congratulations, you spotted what was wrong with the Linux picture!  And not just Java, but Java _after you already know C++_
<lifeless> huwshimi: are you asking why its named that ?
<huwshimi> lifeless: yeah
<huwshimi> wgrant: but the javascript isn't really there, and the images are up a level.
<wgrant> huwshimi: It all ends up served from that. it was mostly there initially, but got split up (eg. for sprites)
<wgrant> Or to go in /@@
<lifeless> huwshimi: other projects call it static
<lifeless> huwshimi: the key point is we compile it once and write to the front end servers so the appservers never see it
<huwshimi> wgrant: incidentally there is javascript up a level too, and it has css in it
<wgrant> Yay
<wgrant> The tree is a mess :(
<huwshimi> wgrant: yeah that's what I'd like to solve
<lifeless> wgrant: any idea how '   1 /    0  https://bugs.launchpad.net/openoffice/+bug/1/comments/325' ?
<_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:I
<wgrant> lifeless: Must be a lock, surely. Do you have the ID?
<lifeless> nope
<wgrant> CL220
<lifeless> thats from the oops report
<wgrant> 00155-15181@SQL-launchpad-main-master SELECT BugMessage.bug, BugMessage.bugwatch, BugMessage.id, BugMessage.index, BugMessage.message, BugMessage.remote_comment_id, Message.datecreated, Message.id, Message.owner, Message.parent, Message.raw, Message.rfc822msgid, Message.subject, Message.visible, MessageChunk.blob, MessageChunk.content, MessageChunk.id, MessageChunk.message, MessageChunk.sequence FROM BugMessage, Message, MessageChunk WHERE ...
<wgrant> ... Message.id = MessageChunk.message AND BugMessage.message = Message.id AND BugMessage.bug = 1 ORDER BY BugMessage.index, MessageChunk.sequence
<jtv> StevenK, wgrant: the generate-contents script wants overrides.  Is there an easy way to produce those for a test distro I create on the fly?
<spm> jtv: that translate deleteion script thingy on LPS - all done, worked a champ. was done in ~5-10 mins.
<jtv> spm: wow, I thought it had fossilized
<jtv> Was that the one about Puerto Rican Spanish translations or something along those lines?
<wgrant> jtv: They're created by FTPArchiveHandler... so not really.
<jtv> wgrant: any way I can convincingly fake them?  I just need enough to convince apt-ftparchive that Contents files ought to be written.
<jtv> spm: ISTR we had a follow-up request for that waiting in the wings.  I'm looking it up.
<wgrant> jtv: See if you can ask FTPArchiveHandler to, otherwise just write some fake ones. They're really trivial.
<wgrant> Could probably even be empty.
<spm> jtv: np
<wgrant> I don't think Contents generation is likely to use them much...
<jtv> Gah!  No Unity, I want a new browser window in my current workspace, not to switch to another workspace where I had a page open.  I thought we were supposed to focus on documents instead of applications now.
<jtv> wgrant: well I'm not getting Contents files and apt-ftparchive is spewing out lots of messages about not being able to open overrides files.
<wgrant> jtv: You're so behind the times. The world has given up on WMs... everything has to use tabs now.
<wgrant> jtv: touch them and see what happens, I s'pose.
<jtv> That's fine with me.  But why does the tab have to be in a different workspace just because I happen to have a page open in the same app somewhere else?
<jtv> wgrant: so an empty file would be a valid overrides file?
<wgrant> jtv: Yes.
<wgrant> it just has no overrides in it.
<jtv> Grr where did my compose key go?  I had it working earlier.
<jtv> Thanks.
<jtv> spm: found it.  Expect a follow-up request for a script run soon.
<spm> np
<jtv> (And thanks for running the request, of course)
<jtv> Unity, you're not telling me there is no way to open a second gvim window from the GUI?
<poolie> jtv: :!gvim&
<lifeless> wgrant: hey, quick question
<lifeless> wgrant: do you know if anything in downtime queries bugs with a status filter [of the form ...or status = .. or status=
<lifeless> wgrant: *and* looks for INCOMPLETE bugs
<wgrant> lifeless: I doubt it.
<wgrant> lifeless: Soyuz doesn't.
<wgrant> lifeless: And I hope Codehosting doesn't.
<wgrant> And the librarian certainly doesn't.
<lifeless> cool
<lifeless> in which case, I am nearly done.
<lifeless> grrr
<lifeless>   File "/home/robertc/launchpad/lp-sourcedeps/eggs/storm-0.18.0.99_lpwithnodatetime_r392-py2.6-linux-x86_64.egg/storm/properties.py", line 67, in __set__
<lifeless>     obj_info.variables[column].set(value)
<lifeless>   File "/home/robertc/launchpad/lp-branches/working/lib/canonical/database/enumcol.py", line 39, in parse_set
<lifeless>     self._enum.name, value.enum.name))
<lifeless> TypeError: DBItem from wrong type, 'BugTaskStatus' != 'BugTaskStatusSearch'
<wgrant> Yay
<lifeless> *hate*
<lifeless> I bet this is going to be painful
<wgrant> Yes.
<lifeless> TypeError: Comparisons of Items are only valid with other Items
<lifeless> >>> from lp.bugs.interfaces.bugtask import BugTaskStatus, BugTaskStatusSearch
<lifeless> >>> BugTaskStatus.INCOMPLETE == BugTaskStatusSearch.INCOMPLETE
<lifeless> not freaking helpful.
<lifeless> I'm quite literally amazed that the existing subclass scheme is working * at all *.
<lifeless> oh joy, its in a different project.
<lifeless> ahh
<lifeless> use_template(BugTaskStatus, exclude=('UNKNOWN'))
<lifeless> rather than subclassing.
<lifeless> headdesk headdesk headdesk
 * spm hands lifeless an asprin
<lifeless> thumper: hey, whats up with bug 154556 ?
<_mup_> Bug #154556: Bug searches should be case-insensitive with respect to status values <feeds> <infrastructure> <lp-bugs> <lp-foundations> <oops> <Launchpad itself:Triaged> <lazr.enum:In Progress by thumper> < https://launchpad.net/bugs/154556 >
<thumper> lifeless: stalled, boot me tomorrow
<lifeless> thumper: willdo
<wgrant> wallyworld: Hi.
<rvba> lifeless: Hi Rob, I saw this morning that you "Fix Committed => Fix Released" a few of "my" bugs ... should I be responsible to do that (i.e. followup my bugs all the way to the release)?
<wgrant> rvba: Generally he or I will close them (whichever of us a requested the rollout)
<rvba> wgrant: all right then, thx.
<poolie> hi rvba
<rvba> poolie: hi
<StevenK> rvba: If you notice your bugs getting Fix Released, you can update the Kanban board by moving the cards to Done-Done
<rvba> StevenK: will do.
<adeuring> good morning
<lifeless> rvba: whomever asks for a rollout will followup on the rollout and ->In Progress or -> Fix Released or (don't touch) as appropriate.
<lifeless> rvba: you're welcome to ask for rollouts and do this yourself :)
<rvba> lifeless: well, all I did so far is behind a feature flag (hum...) so I confess I never encountered the need to do a rollout ... but I'll keep it in mind. Thanks Rob.
<lifeless> rvba: when you have beta users I imagine it will start to matter on a personal basis
<rvba> lifeless: right.
<lifeless> rvba: but there is also the team matter of having the deploy queue short, which we can all help with.
<wgrant> Yes, once ScottK is on your back :P
<poolie> rvba i was just thinking of you today when i saw bug mail from you
<poolie> i hope you're actually enjoying lp
<poolie> since i recommended it to you
<wgrant> poolie seems to be most efficient at quietly recruiting people.
<StevenK> Hehe
<rvba> poolie: so far so good ... and thanks a lot for the recommendation ... I'll owe you a beer for that in Dublin :)
<poolie> i hope eventually lp's ui will be as beautifully formatted as his resumÃ©
<poolie> good :)
<rvba> poolie: :)
<bigjools> poolie: huh, had no idea it came from you :)
<mrevell> Morning!
<poolie> hi mrevell
<lifeless> I pity the reviewer for this
<LPCIBot> Project windmill build #191: STILL FAILING in 1 hr 0 min: https://lpci.wedontsleep.org/job/windmill/191/
<bigjools> umm is the timeout on staging really ~5 seconds?!
<wgrant> bigjools: It's 11s/
<wgrant> https://staging.launchpad.net/+feature-rules
<bigjools> well, the page is timing out after 5
<wgrant> Which?
<wgrant> You mean +localpackagediffs, which is OOPSing instead?
<bigjools> hmmm about 8-9 now
<lifeless> argggh
<lifeless> heat updating uses OFFSET to get bugs to process.
<stub> jtv: Your TOT connection bouncing?
<jtv> stub: no, no, not at all
<jtv> This is my 3BB connection bouncing.
<stub> Mine is bouncing :-(
<jtv> The problem could be at CAT
<jtv> "International connections?  And they do nothing for minutes at a time?  GC them!"
<jtv> It's been particularly crappy for me since the beginning of Songkran.
<jtv> I tunnel one of my connections through ssh with protocol keepalives just to stop that from happening.
<stub> Fine here until today apart from by ADSL connection not being able to authenticate just before Songkran
<jtv> Water everywhere & no staffâ¦
<jtv> stub: is it your DSL connection that's bouncing?  Or something at a higher level such as TCP?
<jtv> I had some router trouble myself; maybe it was just the heat.
<adeuring> lifeless: still around?
<lifeless> \o/ lp:~lifeless/launchpad/bug-759467
<lifeless> adeuring: a little
<stub> jtv: Upstream. ADSL link was fine.
<adeuring> lifeless: can you have a look at my comment on https://code.launchpad.net/~adeuring/launchpad/api-query-permissions-on-object/+merge/58136 ?
<bigjools> jtv, is someone riding a space hopper over your connection?
<lifeless> any reviewers around ?
<lifeless> https://code.launchpad.net/~lifeless/launchpad/bug-759467/+merge/58262
<lifeless> adeuring: I've replied
<adeuring> lifeless: thanks
<lifeless> adeuring: as long as we don't penalise *every* read, I'm happy with most anything :)
<adeuring> ok ;)
<lifeless> wallyworld: is https://bugs.launchpad.net/launchpad/+bug/761494 landable ?
<_mup_> Bug #761494: picker doesn't save selected value into associated textfield <regression> <ui> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/761494 >
<wallyworld> lifeless: being ui reviews as we speak. hope to sort it out tonight
<lifeless> wallyworld: it needs UI review?!
<wallyworld> lifeless: someone said it needed one on account of the javascript
<lifeless> meh
<lifeless> ui reviewer set is one person at the moment
<lifeless> we have many more folk fluent in js
<wallyworld> lifeless: i sort of meant js when i said ui
<lifeless> yah, curtis - the one ui reviewer - has proposed disbanding ui reviews
<lifeless> wallyworld: ok, I've also read it now
<lifeless> I haven't cross referenced YUI
<lifeless> but this is a major issue ; please land
<lifeless> skip ec2
<lifeless> 22:59 < lifeless> wallyworld: ok, I've also read it now
<lifeless> 22:59 < lifeless> I haven't cross referenced YUI
<lifeless> 22:59 < lifeless> but this is a major issue ; please land
<lifeless> 23:00 < lifeless> skip ec2
<wallyworld__> lifeless: ack
<lifeless> I think we should consider cherrypicking it in fact, as it seems to be broken across everything
<lifeless> s/cherrypicking/cowboying
<wallyworld__> lifeless: yeah :-( if only windmill tests were not disabled, would have picked it up during ec2
<wallyworld__> lifeless: not having windmill leaves a huge hole in our testing safety net
<deryck> Morning, all.
<lifeless> wallyworld__: ack.
<lifeless> mrevell: you have mail
<mrevell> Thanks lifeless
<lifeless> mrevell: if you want to chat about it, I'm around for another 20 with the first 5 doing house stuff
<mrevell> lifeless, I'll reply to the email, don't worry, it's not an urgent thing. I take your point and mostly agree with you, but I'll reply fully in the email.
<wallyworld__> lifeless: fyi ec2 land has succeeded
<lifeless> mrevell: cool
<lifeless> wallyworld: ec2 land? or bzr lp-land ?
<lifeless> wallyworld: the former seems pointless with windmill disabled
<lifeless> and will take 8 hours before its on qastaging
<wallyworld> lifeless: ec2 land. bollocks. should have done lp-land
<wallyworld> lifeless: i'll still do a lp-land now?
<lifeless> wallyworld: yeah
<wallyworld> lifeless: done and done
<lifeless> \o/
<lifeless> night all
<LPCIBot> Project windmill build #192: STILL FAILING in 1 hr 2 min: https://lpci.wedontsleep.org/job/windmill/192/
<LPCIBot> Project devel build #653: FAILURE in 5 hr 0 min: https://lpci.wedontsleep.org/job/devel/653/
 * StevenK glares at Jenkins
<StevenK> Ah, no, that racy test *again*.
<deryck> adeuring, henninge -- https://dev.launchpad.net/MaintenanceRotationSchedule
<lifeless> *yawn* really sleep time
<jkakar> G'night lifeless. :)
<jcsackett> can i get a review for https://code.launchpad.net/~jcsackett/launchpad/add-security-audit-utility/+merge/58199 from someone?
<wgrant> https://code.launchpad.net/~wgrant/launchpad/quickly-drop-shipit/+merge/58312 would like a semi-urgent review.
<benji> wgrant: I'll do it. and then jcsackett's
<jcsackett> benji: thanks!
<wgrant> benji: Thanks.
<benji> wgrant: done
<wgrant> Thanks.
<benji> jcsackett: I'm done with https://code.launchpad.net/~jcsackett/launchpad/add-security-audit-utility/+merge/58199.
<jcsackett> thanks, benji.
<rvba> Hi henninge, I'd like to ask you something about your change in security.py (forwardCheckAuthenticated).
<henninge> rvba: sure
<rvba> I've got a test failing with "ValueError: ('Undefined permission id', <Distribution 'Distribution883444' (distribution883444)>)" (full stacktrace http://paste.ubuntu.com/596071/)
<rvba> ./bin/test -cvv distroseriesdifference test_package_diff_request_link
<rvba> I think the call (in forwardCheckAuthenticated) to check_permission_is_registered(permission, obj) should be check_permission_is_registered(obj, permission)
<rvba> http://paste.ubuntu.com/596075/
<rvba> but maybe I'm wrong ... because if I'm right your fix would not have passed ec2 :)
<rvba> henninge: what am I missing?
<henninge> rvba: I'd be surprised if that was the case because the test suite did not notice it.
<henninge> rvba: looking
<henninge> rvba: oops
<henninge> rvba: so the adapters I changed are not being exercised by the test suite ...
<henninge> rvba: is that a new adapter?
<rvba> henninge: from a few days ago
<bigjools> he got pwned
<rvba> arg
<rvba> henninge: "./bin/test -cvv distroseriesdifference test_package_diff_request_link" uses the very adapter you mention in your email: EditDistroSeriesDifference
<henninge> that is very strange
<rvba> indeed
<henninge> rvba: I had failing tests but I re-ran them all locally and they passed.
<henninge> that one was not amont them, though.
<henninge> I guess that whole ec2 run was broken ;(
<henninge> rvba: anyway, thanks. I'll submit a fix quickly.
<rvba> henninge: great thanks :)
<rvba> henninge: it would be nice to understand how this appended though ...
<henninge> rvba: let me see if I still have that mail. It was very large so I might have deleted it.
 * rvba tests test_package_diff_request_link on a fresh branch
 * rvba confirms the test is failing on a fresh checkout of devel
<bigjools> did someone with microscopes for eyeballs set the latest font size?
<benji> there's some sort of Moore's law of web font sizes, they halve every 18 months
<bigjools> ha
<timrc> just set your resolution 800x600, problem solved
<bigjools> or ctrl-mouseup!
<henninge> rvba: I still have the test output. The failure did not happen on that run.
<henninge> http://paste.ubuntu.com/596085/
<rvba> hum ...
<rvba> the mystery persists
<jelmer> deryck: HI
<deryck> Hi jelmer
<jelmer> deryck: Sorry, I mean: hi
<jelmer> deryck: just saw your bug report; are you using the natty daily ppa?
 * deryck doesn't mind shouting hello :-)
<deryck> jelmer, yes, I think so.  just added it via add-apt-repository on natty.
 * deryck looks
<deryck> jelmer, yeah, http://ppa.launchpad.net/bzr/daily/ubuntu natty main
<jelmer> deryck: hmm, odd
<jelmer> deryck: thanks
<deryck> jelmer, np
<cody-somerville> bigjools, press ctrl + 0 to restore default zoom
<bigjools> cody-somerville: then it turns into something the size of a sparrow's arse
<cody-somerville> bigjools, Firefox or Chromium?
<bigjools> both
<cody-somerville> What font size do you have set in Edit > Preferences, Content
<bigjools> but them I am 40, so my eyes ain't what they used to be :)
<cody-somerville> ?
<cody-somerville> bigjools, lol
<bigjools> no default font size
<sinzui> jcsackett: mumble?
<allenap> Is qastaging deploying or is it broken?
<mrevell> Night!
<LPCIBot> Project devel build #654: STILL FAILING in 5 hr 0 min: https://lpci.wedontsleep.org/job/devel/654/
<benji> if anyone feels like reviewing a 600 line lint branch, this is your lucky day: https://code.launchpad.net/~benji/launchpad/lint/+merge/58371
<flacoste> abentley: i suggest you send an email about bug #766337 to launchpad-dev
<_mup_> Bug #766337: Should be possible to reload JSON cache <Launchpad itself:Triaged> < https://launchpad.net/bugs/766337 >
<flacoste> given JS-heavy work done in feature squad, it would be likely that one of the feature squad could do it as part of their work
<flacoste> it's an elegant solution to a common problem
<abentley> flacoste: Okay.
<sinzui> allenap: I am looking at the qastaging issue. The error looks like the the lp tree was updated, but qastaging did not get the lp-production-config update
<jcsackett> sinzui: do you know a good place for me to go digging into some of the specifics of how our exceptions are turned into OOPses? or who might be best to bug to figure that out?
<jcsackett> i've realized that what i knew about for cron scripts tied to logging errors--if an exception occurs that isn't caught and logged, the logging oopshandler obviously isn't going to come into play. :-/
<sinzui> jcsackett: A quick mumble will sort this out
<jcsackett> sinzui: works for m.
<jcsackett> s/m./me.
<lifeless> can has review? https://code.launchpad.net/~lifeless/launchpad/bug-759467/+merge/58262
<allenap> lifeless: I'll do it.
<allenap> leedsliam: Hello chap :)
<lifeless> evening allenap
<allenap> Evening lifeless :)
<timello> hi! Is there any launchpad method in the api that can do a search in packages like https://launchpad.net/ubuntu/+search does?
<lifeless> Probably not, that search returns many different types of results and our api is (sadly) a bit difficult around heterogynous interfaces
<timello> :/
<lifeless> https://launchpad.net/+apidoc/devel.html is our development api doc
<lifeless> replace devel with 1.0 to see the stable version
<timello> lifeless, yeah, I've being looking at this reference
<lifeless> sinzui: hi
<lifeless> bug 766561 - could that be related to our team notify change, or perhaps its more likely to be in gary_poster's baliwick ?
<_mup_> Bug #766561: person in team A which is a subteam of team B not getting bug email for bugs team B is subscribed to <Launchpad itself:New> < https://launchpad.net/bugs/766561 >
<gary_poster> it doesn't sound like us, fwiw
<lifeless> gary_poster: hi; btw - bug 745799 - that is you :)
<_mup_> Bug #745799: DistroSeries:+queue Timeout accepting packages (bug structural subscriptions) <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/745799 >
<sinzui> I changed merge notifications. Are teams not being notified about merges?
<lifeless> sinzui: ah right, I thought we changed a helper function in there.
<sinzui> I did, but nothing but merge ever used it
<sinzui> It will be months or years before we make everything queue messages
<lifeless> gary_poster: so a couple/few weeks ago this team stopped getting mail
<lifeless> gary_poster: they are utterly confused as to why
<gary_poster> lifeless, I have the rest of the week to get our feature ready for review, and then two weeks for bug fixes after that.  Could you help me prioritize these within that context?
<gary_poster> (no frustration there, just rrying to be clear with my situation)
<lifeless> gary_poster: yup. I think we need to determine if this is real (e.g. are we -not- sending brad & others in that team email)
<lifeless> if we are sending the mail, its at his end, phew, move along.
<gary_poster> lifeless, IOW, drop everything?
<lifeless> if we aren't, its a regression and I think its reasonable to say a maintenance squad should look at it
<gary_poster> oh ok, drop everything to investigate?
<lifeless> but if it turns out to be related to your feature work, I think its probably better at that point to hand it over to you as you'll know whats changed recently.
<gary_poster> sure, I'm completely fine with that
<lifeless> gary_poster: someone should; as its near your EOD I will either look myself or coordinate it
<gary_poster> but I would prefer to not have it affect my time this week
<lifeless> I think the next step is log trawling :)
<gary_poster> heh
<gary_poster> I'm looking at the timeout too
<gary_poster> I assume any oops is a reasonable starting point
<lifeless> gary_poster: yeah; I've analyzed one in detail for repeated queries; the strucsub ones summed to 2.2 seconds
<lifeless> from ~20 separate queries. I suspect its a per-bug potato programming issue that has been exacerbated by the [slight] increase in cost of determining structural subscription
<lifeless> gary_poster: I'
<lifeless> I don't think you should drop anything to work on the timeout
<lifeless> it was a preexisting problem
<lifeless> the mail-not sending however may well need dogpiling.
<lifeless> I'm looking in logs myself now.
<gary_poster> lifeless, ok.  if we do have to work on reducing the structural subscription queries themselves, which I would understand in the abstract, it may require some...significant thinking.  If this is some page-specific thing exacerbated by some potato programming there specifically, I'd be much happier.
<gary_poster> lifeless, re bug 76651, are you looking for 759176 in logs
<gary_poster> ?
<_mup_> Bug #76651: Comment on change is lost when the bugtask change form returns with errors. <lp-bugs> <Launchpad itself:Invalid> < https://launchpad.net/bugs/76651 >
<lifeless> gary_poster: well, what we'll need is a way to do email notifications for N bugs all at once
<lifeless> gary_poster: +queue accepts uploads that may close some number of bugs
<gary_poster> lifeless, I see
<lifeless> gary_poster: so we need to be able to process a 'fix released' status change for N bugs in the space of one webapp transaction (+ the actual accept logic itself)
<lifeless> gary_poster: not actually spool the mail - the deferred sending etc is still used AIUI
<gary_poster> gotcha
<gary_poster> sure
<lifeless> one way would be to handoff the post to a script
<lifeless> or we could batch better in the webapp, etc etc etc
<gary_poster> sure
<allenap> lifeless: r=me.
<allenap> Good night all.
<lifeless> allenap: thanks! gnight
<lifeless> gary_poster: yes I'm grepping
<lifeless> now I've unwedged my carob link
<lifeless> brads name is not there
<gary_poster> lifeless to build a "process structural subscriptions for batches of bugs" would require a new set of functions, as you might guess...and the logic is generally very bug specific so that will be interesting.  I'm sure we can increase the possible N within a given timeframe, but it would be work specific to that page
<gary_poster> and depending on how big N needs to be, asynchronous will be necessary eventually
<lifeless> gary_poster: we have feature requests for batch actions on bugs, so perhaps not all that specific. Anyhow, I think we agree that this is an exacerbation not a direct regression; I'm fine with it being looked at holistically with performance rather than zomging it in your squad
<gary_poster> cool thanks
<gary_poster> I'm particularly happy to look at it once we are on bug rotation :-)
<gary_poster> so as far as the other bug goes
<gary_poster> your log search suggests that the bug is in fact in LP mail sending
<lifeless> yup
<lifeless> we're choosing not to send to him
<lifeless> I'm checking teamparticipation
<gary_poster> ah cool thanks
<lifeless> https://launchpad.net/~brad-figg/+participation has 'the dell team'
<gary_poster> lifeless, for scheduling, could I schedule investigation of that bug for Thursday, or does our QoS need to be higher for this?
<lifeless> I think we should treat this as a showstopper
<lifeless> its pretty key functionality
<gary_poster> well, I'm reasonably confident we have tests for the basic functionality
<gary_poster> I would certainly hope so anyway :-/
<gary_poster> that's not a feature we would have developed, of course
<gary_poster> so I suspect that this is an edge case
<gary_poster> "private bug" is our current red flag there
<gary_poster> so, would this be acceptable:
<gary_poster> 1) Verify ASAP that we have tests that show that the basic story of that bug is working.  If not, add test and fix.
<gary_poster> 2) If #1 did not reveal a problem, on a more scheduled timetable, investigate this particular edge case.
<gary_poster> [stop]
<gary_poster> Perhaps 1.5, investigate if "private bug" is the kicker
<gary_poster> since that's obvious ATM
<lifeless> I hate that ''https://launchpad.net/api/1.0/~dell-team'' in a web browser is ~ useless
<lifeless> gary_poster: teamparticipation shows brad-figg as a member of dell-team
<lifeless> in prod
<lifeless> is there some way to get e.g. https://launchpad.net/api/1.0/~dell-team/+sub-teams to render the json ?
<gary_poster> lifeless, tomorrow morning, I'll have someone on the squad investigate the bug.  My goal will be to fix or show in a LP test that basic team subscription sends emails as expected; and to fix or show that basic team subscription sends emails as expected for private bugs.  If neither of those are a problem, I will postpone further work unil next week unless you tell me otherwise (like, say, now ;-) ).
<gary_poster> render the json...I think I have tried horrible webclient hacks in the past but I have no recipe atm
<lifeless> gary_poster: its team-team-person
<lifeless> gary_poster: I would wager we only really test team-person
<gary_poster> lifeless, yeah, sorry, understood.  only really test team-person: maybe so.  If so, we'll find it quickly
<gary_poster> lifeless, I'm running away in minute or so btw.
<lifeless> ok, ciao
<lifeless> I will continue coordination
<gary_poster> thanks
<lifeless> suspiciously, the send-bug-mail script optimisation is in the suspect range.
<sinzui> wallyworld: ping
<wallyworld> sinzui: hi
<sinzui> wallyworld: I will not be available for the stand up in 30min. My daughter demands that I pick her up from soccer.
<wallyworld> sinzui: been there :-)
<sinzui> wallyworld: Can you convey my apologies.
<lifeless> do teams provide IPerson?
<wallyworld> sinzui: will do. we could have it now?
<lifeless> if so we have some rather confused code
<sinzui> wallyworld: if member so no mind
<wallyworld> sinzui: ack
<sinzui> lifeless: teams are IPerson with the addition of ITeam
<sinzui> lifeless: They are IPerson until we execute __init__ in Person then they get the extra interface
<lifeless> yeah, I thought so
<lifeless> thanks
<lifeless> I'm looking into this notification bug
<lifeless> no joy so far
<lifeless> it should end up in _get_recipients_for_team which is unchanged since before the issue
<lifeless> at least, the webapp generation should do that
<lifeless>  i suppose its possible the mail sending backend is doing something special
<maxb> Any obvious reasons why a dev instance of launchpad would be rendering links to https://launchpad.dev/+icing/revNone/.... (which of course 404) ?
<lifeless> run make
<lifeless> IIRC its a make rule to update the revno
#launchpad-dev 2011-04-20
<wallyworld> thumper: wgrant: standup?
<thumper> yeah, I have a few minutes
<LPCIBot> Project devel build #655: STILL FAILING in 5 hr 0 min: https://lpci.wedontsleep.org/job/devel/655/
<wgrant> Anyone looking at the buildbot failure?
<wallyworld> wgrant: looking now. been fighting with recordmydesktop this morning :-(
<wgrant> wallyworld: I've just pushed.
<wgrant> So don't worry about it.
<wallyworld> wgrant: ok. what was the issue?
<wgrant> wallyworld: The check_permission changes in security.py. EditStructuralSubscription now relies on launchpad.Edit being defined for all IStructuralSubscriptionTargets.
<wgrant> It was not defined for DistributionSourcePackage.
<wallyworld> ack. thanks
<lifeless> yay side effects
<jcsackett> is anyone available to look at https://code.launchpad.net/~jcsackett/launchpad/bug-expiration-doesnt-oops/+merge/58412?
<poolie> hi all
<poolie> re bug 766149\
<_mup_> Bug #766149: bzr from daily ppa blocks python 2.6 install on natty using site-packages <packaging> <Bazaar:Confirmed> <bzr (Ubuntu):Invalid> < https://launchpad.net/bugs/766149 >
<poolie> is this just deryck trying something, or is lp as a whole planning to move to natty before you move to py2.7?
<wgrant> poolie: LP doesn't quite run on 2.7 yet, so it's hardcoded to 2.6 for devs who are running natty.
<lifeless> poolie: company policy - we should all be running natty around now.
<wgrant> (eg. me)
<lifeless> poolie: but lp /cannot/ move to py2.7 until its backported to lucid and so on.
<poolie> well, company policy would not (aiui) prevent you running lp in a chroot
<wgrant> poolie: No, but there's very little reason to.
<wgrant> poolie: Given that it works fine on natty.
<wgrant> (mostly)
<poolie> :)
<lifeless> I do my dev in a lucid vm fwiw
<poolie> shall we update https://dev.launchpad.net/Running then?
<lifeless> but thats different tradeoffs to in-place, and higher friction in some ways
<wgrant> poolie: It's not completely tested, but maybe.
<poolie> anyhow, i don't mind, i just had not heard of anyone running natively on natty yet
<poolie> if everyone was going to switch that bug would be a bit more urgent
<lifeless> I'd expect a rash of migrations in the next week or two
<wgrant> poolie: I've been running since November or so.
<wgrant> Without much trouble in recent months.
 * wallyworld___ heads off to dentist with laptop and 3g modem. who knows how long i'll be stuck in the waiting room :-/
<wallyworld_> poolie: huwshimi: http://people.canonical.com/~ianb/filebug.ogv    ps. browser back button also works
<poolie> you legend
<wallyworld_> poolie: assignee picker also works on Chrome :-)
<poolie> is this by having the fields statically present but hidden?
<wallyworld_> poolie: i think the fading of the details entry fields works ok. full rational in partially completed mp https://code.launchpad.net/~wallyworld/launchpad/filebug-loses-data/+merge/58410
<wallyworld_> poolie: essentially yes
<poolie> yes
<poolie> choirs of angels sing thee to thy rest
 * wallyworld_ now has to write js and windmill tests that won't be run anyway :-(
<wallyworld_> poolie: there's a lot of duplicate bugs filed about this one :-)
<wallyworld_> poolie: plus xss holes that will be plugged
 * wallyworld_ goes to climb onto dentist chair. yeow :-(
<lifeless> 39 /    6  RootObject:+login
<lifeless> >< what now
<wgrant> Perhaps our friendly chÃ¦ doesn't have SSO access.
<wgrant> Hmm.
<wgrant> No, various prefixes.
<wgrant> Possibly traversal + locks.
<lifeless> DS, AU, CP
<wgrant> wut
<lifeless> prefixes
<wgrant> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1935DS606
<wgrant> Yes.
<wgrant> But look at the OOPS.
<wgrant> I blame SSO.
<wgrant> 10059ms gap.
<lifeless> we have missing instrumentation
<lifeless> do we make *http* calls to SSO ?
<wgrant> Yes.
<lifeless> okies
<lifeless> a) exception time
<wgrant> Right in that location, too.
<lifeless> and b) critical bug on sso time.
<wgrant> Well, no, it's probably an issue on our end.
<wgrant> But it's with the request to SSO.
<lifeless> and c) instrumentation
<lifeless> wgrant: nah, login is /slow/
<lifeless> I've been suspecting it for weeks
<lifeless> but had nodata
<wgrant> :( dapper
<lifeless> oh
<lifeless> and we need to qa to unbreak bug assignment etc
<thumper> lifeless: https://code.launchpad.net/~thumper/lazr.enum/release-1.1.3/+merge/58420
<thumper> lifeless: then I'll make a lazr.enum release
<thumper> add it to our download cache
<thumper> and fix the bug
<thumper> lifeless: can you upload to pypi?
<thumper> I don't think I can
<lifeless> thumper: its per-project
<lifeless> thumper: any of the existing uploaders can add you
<thumper> hmm...
<thumper> I wonder who it is
<lifeless> login to pypi, it will show you
 * thumper should get a pypi login
<lifeless> thumper: you can use openid
<wgrant> You don't even need to log in.
 * thumper is using openin
<lifeless> thumper: does lazr.enum already have the changes needed ?
<thumper> openid even
<thumper> lifeless: yes
<thumper> in the last trunk revision
<wgrant> lifeless has privs.
<lifeless> thumper: this is most *definitely* a self review case
<thumper> :)
<lifeless> oh I do, how about that.
<lifeless> hah, 1.1.1
<lifeless> I'm so glad we keep it up to date
<lifeless> thumper: don't add it to the download cache, I'll get a tarball out as a result of doing sdist upload --signed
<lifeless> thumper: otherwise we'll have different tarballs and thats just a nuisance
<thumper> Package Index Owner: barry, gary, flacoste, leonard, lifeless
<thumper> lifeless: do you want to add me on
<wgrant> Having different tarballs is justification for homicide by distribution engineers.
<thumper> and I can upload it?
<lifeless> sure
<thumper> I'm thumper on pypi too
<lifeless> ok, you have owner on all the lazr.* things I have owner on
<lifeless> use it well
<lifeless> oh ffs
<lifeless> SMTPError: SMTP error: 552 5.2.3 Your message exceeded Google's message size limits. Please visit
<lifeless> 5.2.3 http://mail.google.com/support/bin/answer.py?answer=8770 to review
<lifeless> 5.2.3 our size guidelines. e37sm215844vbm.5
<thumper> lifeless: yeah, saw that, thanks
<lifeless> I really *must* finish the subunit post stuff for lp
<thumper> lifeless: also... can sdist do the pypi upload too?
<lifeless> you change them togeter
<lifeless> sdist upload --signed
<lifeless> IIRC
<lifeless> s/change/chain/
<thumper> ack
 * thumper tries
<thumper> :(
<thumper> lifeless: how do identify with pypi from the command line?
<thumper> for sdist upload?
<lifeless> cat ~/.pypirc
<lifeless> [server-login]
<lifeless> username:lifeless
<lifeless> password:
<thumper> um... I don't have a password though, I use openid
<thumper> I could add one I suppose
<lifeless> I don't know how to do it for openid
<lifeless> there are good docs around that I read before openid was added, I suspec they have been upgraded
<thumper> I just added a password to my account
<thumper> all is good
<thumper> 1.1.3 on pypi now
<lifeless> ok, opinions please
<lifeless> should the request timeline flatten recursive actions into a pair of start/stop actions automaticlaly
<lifeless> or only when the might-nest action has indicated this is expected
<lifeless> the latter seems more robust to me if a little more thought required to use.
<lifeless> can has review? https://code.launchpad.net/~lifeless/launchpad/bug-766786/+merge/58430
<StevenK> lifeless: Broadly okay, I'm a little unsure why a bunch of your tests don't seem to test anything
<lifeless> StevenK: they run code which before the change will break
<lifeless> StevenK: thats a test
<lifeless> the idea that a test needs an assert in it is a cruel meme perpetuated on the unwary
<StevenK> lifeless: Okay, fine. r=me
<lifeless> thanks!
<spm> lifeless: "the idea that a test needs an assert in it is a cruel meme perpetuated on the unwary" <== brief expansion on the why? for personal curiosity/learning than anything profound.
<lifeless> so the argument is that a test case has to make an assert or its not making a statement about any particular thing being expected/not expected
<lifeless> related to this there is an argument that a test case should make one and only one assertion
<spm> right
<lifeless> now, the latter is more easily shown to be nuts, if you compare the LOC (and relatedly clarity) to curry a multi-attribute assertion vs 2 or 3 separate assertions
<lifeless> its a spectrum, *sometimes* good sometimes bad.
<lifeless> with the latter disposed of - we have merely to cover the what about 0 case?
<spm> perhaps one of those, here's the rule, so you think about it when you break it, cases?
<lifeless> and for that, we go back to basics:
<wgrant> StevenK: Bug #746376 needs QA.
<_mup_> Bug #746376: When DSD is created it needs to check for existing packagediff and set DSD diff properties <derivation> <qa-needstesting> <Launchpad itself:Fix Committed by stevenk> < https://launchpad.net/bugs/746376 >
<lifeless>  - tests exist to help us deliver fit for purpose code
<lifeless>  - if it helps with that, great. And we should aim for clear expression of whatever thing we want to ensure does/does not happen
<huwshimi> wallyworld: That screencast looks good.
<lifeless>  - one aspect of clarity is checking for a single -conceptual- issue in a test case (vs a single 'assertion') because that helps with correcting problems: you can see all the intentions that are violated and fix those.
<lifeless> spm: and thus, if being able to run code that you couldn't before is a useful thing to be able to do, it can be a test in and of itself.
<lifeless> spm: in C i would have written those tests with assertions
<StevenK> wgrant: Indeed, I've been mulling how to do that while working on another branch
<lifeless> because C doesn't have exceptions, I would have had to be returning error values.
<lifeless> spm: and I'd want to know that it hadn't errored; in python it will throw for me, so the test is simpler.
<wgrant> StevenK: It's fairly safe and the code doesn't run in prod yet, so qa-untestable is reasonable.
<spm> lifeless: right. and that's where I've typically come from with the very little unit testing I've done. if I plug in this value do I get back the desired answer.
<lifeless> spm: right; and thats exactly this case - plug in some code, desired answer is a lack of exceptions.
<spm> I think the point you make about conceptual issue testing, is a powerful one.
<lifeless> spm: its a rule of thumb again though :)
<StevenK> wgrant: Done.
<spm> tricky, but powerful.
<wallyworld> huwshimi: cool. i'm fixing the tests which broke due to the different html and writing new ones
<lifeless> hmm
<lifeless> 'cve reports' should really be in the bug count portlet
<huwshimi> Anyone getting "ImportError: No module named nestingtimedaction" on 'make schema'?
<lifeless> not inthe 'configure this product for bugs' portlet.
<lifeless> hahha I suck.
<lifeless> huwshimi: don't use my last landing.
<lifeless> I failed to add the new files.
<huwshimi> lifeless: Are you going to land a fix soon or should I revert?
<lifeless> its landing now
<huwshimi> lifeless: Ah sweet. I'll wait. Thanks
<lifeless> mwhudson: hey
<poolie> lifeless: fyi bug 766757 was filed after a discussion with james
<_mup_> Bug #766757: creating mps for collisions isn't helpful <canonical-bazaar> <Ubuntu Distributed Development:Confirmed for canonical-bazaar> < https://launchpad.net/bugs/766757 >
<lifeless> mwhudson: is canonical.launchpad.webapp.login.CookieLogoutPage your beastie ?
<poolie> as what seemed like the most likely string to pull on
<lifeless> poolie: coolio
<poolie> it is obviously not the full solution
<lifeless> poolie: I was (wrongly) concerned then :)
<poolie> np, i probably should have said i'd spoken to him
<poolie> you can see why i am concerned by some part-of-the-picture lp bugs :)
<lifeless> naturally
<lifeless> sorry if I caused any confusion or noise on the bug
<poolie> no problem at all
<poolie> i appreciate your interest
<poolie> just letting you know
<lifeless> thanks
<lifeless> I do trust that you know the domain
<poolie> not as well as i would like :/
<lifeless> I guess I feel that there is stuff possibly missing given the previously distro heavy design
<lifeless> poolie: I'll keep commenting on such things then :)
<poolie> "previously distro heavy design" meaning what?
<lifeless> \o/ 1-character bugfixes
<lifeless> poolie: well a lot of the design about how it should work was just done by doing + small conversations here and there amongst distro folk (which I count myself as for this purpose)
<lifeless> it was often written up into mail or wiki but not always
<lifeless> and it was spread over several years
<lifeless> so its hard to have a cohesive hold of all of the bits :)
<poolie> ah yes
<lifeless> can has review? https://code.launchpad.net/~lifeless/launchpad/bug-112776/+merge/58434
<wgrant> lifeless: I guess that's OK now, since we end up at the OpenID provider anyway?
<wgrant> Previously it was meant to return you to the current page, logged out.
<poolie> makes sense to me too
<lifeless> wgrant: right
<lifeless> now we redirect to bazaar.launchpad.net
<lifeless> and from there to the openid sso
<poolie> that's a pretty popular bug
<wgrant> Yup.
<wgrant> (ew)
<wgrant> StevenK: Could you mentor?
<wgrant> Terribly difficult.
<LPCIBot> Project windmill build #193: STILL FAILING in 1 hr 2 min: https://lpci.wedontsleep.org/job/windmill/193/
<StevenK> lifeless: Only if you promise you didn't miss any files this time
<poolie> i wanted to have a beer-type conversation with you about testing sometime
<lifeless> StevenK: I make no such promises
<poolie> i was noticing some of bzr's tests were making things hard to change rather than easier
<poolie> no rush though
<lifeless> poolie: sure
<StevenK> wgrant: Done
<poolie> i think some things we've been doing cause a skew towards tests that depend on internals
<wgrant> StevenK: Thanks.
<wgrant> wallyworld: Hi.
<wallyworld> wgrant: 1 min. otp
<poolie> sometimes just things that are not strictly internals, but external to a narrow layer
<lifeless> poolie: I meant, sure, I'd like that too + no rush :)
<wgrant> wallyworld: Sure.
<poolie> anyhow, some other time
<StevenK> lifeless: Typical :-P
<poolie> drop by some time :)
<lifeless> I have the miles :)
<lifeless> hmm, actually I wonder if I do on qantas; have to fly every year with them I think; I do on air nz
<poolie> every 18m to keep them iirc
<wgrant> They changed it to 18 months a couple of years ago.
<wgrant> :(
<StevenK> Yes, this is a *bug*.
<wgrant> Probably an effective one, however
<StevenK> Along with their recent fuel increase.
<wgrant> I never really saw any validity in a fuel surchage.
<poolie> pricing opacity
<StevenK> And jet fuel is quite expensive
<wgrant> That's business rationale, not validity :)
<poolie> i am so happy with Amaysim because they have simple transparent linear pricing
<wallyworld> wgrant: free now
<poolie> none of this 1c/MB for the first 1000, then 100c
<wgrant> wallyworld: There are two remaining Windmill test failures.
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project devel build #656: FIXED in 5 hr 24 min: https://lpci.wedontsleep.org/job/devel/656/
<lifeless> amaysim ?
<poolie> an australian optus mobile reseller
<wallyworld> wgrant: the only ones i saw were due to the picker issue.
<wgrant> wallyworld: One of them is for inline non-contributor assigning, which works fine AFAICT.
<lifeless> poolie: ah, I saw the optus thread
<lifeless> didn't catch the reseller name
<wallyworld> wgrant: i fixed that test a day or 2 ago
<wgrant> wallyworld: It just failed again a few minutes ago (in db-devel)
<wallyworld> wtf
<wgrant> https://lpci.wedontsleep.org/job/windmill/193/testReport/junit/lp.bugs.windmill.tests.test_bug_inline_assignment/TestInlineAssignment/test_inline_assignment_non_contributor/
<wgrant> https://lpci.wedontsleep.org/job/windmill/193/testReport/junit/lp.translations.windmill.tests.test_sourcepackage_sharing_details/TestSharingDetails/test_set_branch/ also, but that's a bitrotten test that I might try to fix now.
 * StevenK kills gnome-do, hopefully to stop the wrong indicator popups
<wallyworld> wgrant: well, the error message shows the code is as per my fix and it worked fine locally :-(
<wgrant> :(
<wallyworld> wgrant: i'll get my current work done and then i'll take a look
<wgrant> wallyworld: Thanks.
<wallyworld> wgrant: just check my email - the picker fix has gone through \o/
<wgrant> wallyworld: Yup, and it works.
<wgrant> Thanks.
<wgrant> We'll deploy after the next buildout run finishes.
<wgrant> Since there's another regression fix in there right now.
<wallyworld> wgrant: i'm pissed that i broke it but windmill tests would have caught it :-( it's becoming risky to make js/ui changes without  the proper test coverage :-(
<wallyworld> in-process windmill tests as part of ec2 land i mean
<wgrant> wallyworld: Right.
<wgrant> wallyworld: I can reproduce the assignment test failure locally, hmm.
<wgrant> It seems to be legit, but it works on qas.
<wallyworld> wgrant: i'll look into it. it worked locally when i put it up for review etc
<wallyworld> wgrant: maybe something has changed and is affecting it
<wallyworld> wgrant: i've had that happen before. ie worked locally but broke after other stuff got merged in
<wgrant> wallyworld: I hope that with deryck on maintenance we will soon be able to make progress.
<wgrant> And get Windmill or its replacement back in soon.
<wallyworld> +1
<wgrant> And maybe even get it to work on natty.
<lifeless> I sure hope someone does bug 80902 soon :)
<_mup_> Bug #80902: Can't target bug report from project to distribution, or vice versa <bugs> <escalated> <javascript> <linaro> <lp-bugs> <questions> <ubuntu-qa> <Launchpad itself:Triaged by launchpad-green-squad> < https://launchpad.net/bugs/80902 >
<lifeless> oldest critical
<wallyworld> wgrant: yeah. still some remaining (weird) ff4 issues to fix for natty
<wallyworld> lifeless: i can look at that one next
<lifeless> wallyworld: if curtis is cool with it that would rock
<wallyworld> lifeless: i'll convince him :-)
<lifeless> \o/
<wgrant> He was looking at that himself a few weeks ago.
<wallyworld> lifeless: i've been hacking in bugs lately anyway. i'm still far from an expert but i know more than i used to
<wallyworld> wgrant: maybe he has solved it already. well, one can hope :-)
 * wallyworld runs bin/test --layer=BugsWindmillLayer. now to watch my laptop thrash the disk for 30 minutes and acquire lots of zombie processes that refuse to die :-(
 * lifeless hammers staging to its knees
<wgrant> lifeless: Oh?
<wgrant> wallyworld: I've hopefully fixed the translations test.
<wallyworld> wgrant: excellent :-)
<wgrant> wallyworld: I wonder if the bugs one is related to the odd proxying that Windmill does.
<wallyworld> wgrant: not sure. i'm running the tests locally to check for breakages due the to filebug stuff i'm doing
<lifeless> wgrant: doing an analysis of the error rate for oe
<lifeless> m
<lifeless> for bugsummary
<wgrant> Ah.
<wgrant> lifeless: Well, staging is down, so you have the whole thing :)
<wgrant> thumper: Is any QA necessary for your stacking change?
<wgrant> thumper: Given that we won't be deploying codehosting tonight?
<wgrant> wallyworld: 'node.one(".no_button") is null' :/
<wgrant> But it created the node just there :(
<wallyworld> wgrant: that's the sort of stuff i've been fighting of late with windmill. takes me ages to do something which should be simple. :-(
<lifeless> wgrant: stacking change?
<wgrant> lifeless: [r=bac][bug=377519] Change the default stacking location to use the branch id alias.
<wgrant> wallyworld: Ah, it helps if I test in the right browser.
<wallyworld> wgrant: you mean it's broken in ff4?
<wgrant> Reproducible outside Windmill in Firefox *3*.
<lifeless> wgrant: what rev?
<thumper> wgrant: yes
<thumper> wgrant: it is xmlrpc
<lifeless> thumper: I thought we were not going to land that till poolie acked it works ok with bzr ?
<thumper> so it'll be live
<wallyworld> wgrant: but works in ff4?
<wgrant> lifeless: r12874, in buildbot now.
<thumper> lifeless: I've qa'ed it to my satisfaction
<wgrant> lifeless: Ahead of the bugmail fix.
<lifeless> thumper: I'd like poolies ack
<lifeless> thumper: he has expressed nervousness about this
<wgrant> wallyworld: Not sure.
<thumper> sure
<lifeless> thumper: its the least we can do
<wgrant> wallyworld: I think so, though...
<wallyworld> wgrant: this all just makes me sad :-(
<lifeless> poolie: has your team tested the id based stacking by hand yet ?
<wgrant> wallyworld: Ja.
<wgrant> wallyworld: We really need to get cross-browser Windmill working..
<wallyworld> wgrant: yep. i'd be happy if *one* browser worked reliably
<wgrant> Grumble.
<wgrant> Huh.
<wgrant> It creates yes_button, but not no_button.
<wgrant> I wonder if FF 3 disagrees with self-closing buttons.
<wgrant> Chromium disagrees with self-closing divs, I know.
<wgrant> Yup, that's it.
<wgrant> Web, I hate you.
 * wallyworld cries
<wgrant> Anyway, both fixed now.
 * wgrant lands.
<wallyworld> wgrant: what was the fix?
<wgrant> -              '<button class="yes_button" type="button"/>',
<wgrant> -              '<button class="no_button" type="button"/>',
<wgrant> +              '<button class="yes_button" type="button"></button>',
<wgrant> +              '<button class="no_button" type="button"></button>',
<wgrant> Yes, seriously.
<wallyworld> wgrant: wtf. i'm stunned
<wgrant> That works fine in Chromium and Firefox 4, but Firefox 3 chokes if you self-close the button.
<wgrant> Chromium goes crazy if you don't close a div.
<StevenK> Does type="button" /> work?
<wgrant> StevenK: I fucking hope not.
<wgrant> But possible.
 * wgrant tries.
<StevenK> Haha
<wgrant> Fortunately not.
<poolie> lifeless: it has not broken but i have not manually tested it by renaming branches etc
<poolie> but i guess you have already done that
<wgrant> wallyworld: https://code.launchpad.net/~wgrant/launchpad/translations-windmill-testfix/+merge/58441
<wgrant> Now that the spurious failures seem to have disappeared when running only WindmillLayer, I guess we should try to keep Jenkins' Windmill builder green.
 * wallyworld looks
<wallyworld> wgrant: too bad we can't hook jenkins into ec2 and
<wallyworld> land
<StevenK> I'd like to
<wallyworld> StevenK: jenkins seems more reliable at running wm tests?
<wgrant> wallyworld: Only when in a separate job.
<wgrant> When running in the main job it's just as unreliable.
<wgrant> (which is extremely interesting, yes)
<wallyworld> wgrant: so why don't we run the wm tests isolated in ec2?
<wgrant> wallyworld: Because nobody has done that yet, and I didn't believe this could be the case until recently.
<wgrant> But it has held true for a month or so now.
<wgrant> So it may be a good thing to try.
<wgrant> Not sure quite how easy it will be, though.
<wallyworld> yep
<wallyworld> StevenK: wgrant: can we get jenkins to run the yui test layer too?
<wallyworld> now that it is separate
<wgrant> wallyworld: Good point.
<wgrant> StevenK: Could you make it run YUITestLayer too?
<wgrant> --layer=(WindmillLayer|YUITestLayer) should do it, I think.
<wallyworld> yep
<wgrant> Yeah, that works.
<StevenK> I was wondering about that
<StevenK> sudo -u hudson -H make TESTOPTS="--subunit --layer=(WindmillLayer|YUITestLayer)" check | subunit2junitxml -f -o test-results.xml
<wgrant> Should work.
<StevenK> Done.
<wgrant> Thanks.
<wgrant> So, can has review?
<wgrant> buildbot will finish soon.
<StevenK> wgrant: r=em
<StevenK> *me
<wgrant> Thanks.
<StevenK> wgrant: I'd say "Self-review for something that trivial.", but you can't. :-(
<wgrant> Yeah.
<wgrant> It's a little sad.
<wgrant> wallyworld: Is test_TextFieldPickerPlugin_selected_item_is_saved new today?
<wallyworld> wgrant: yes
<wgrant> wallyworld: It fails locally.
<lifeless> woo
<wgrant> I wonder if it hasn't hit db-devel yet.
<lifeless> the error rates ar elow
<wallyworld> wgrant: i added it to test the regression. there's a similar test in lazr-js but we need our own also
<lifeless> 243 -> 248
<lifeless> 103 -> 108
<lifeless> 12 -> 12 (with the occasional 13)
<wallyworld> wgrant: fails how?
<wgrant> wallyworld: Oh, is it YUITestLayer?
<wallyworld> wgrant: yes
<wgrant> Yes, yes it is.
<wgrant> Broken in Firefox 3, yay.
<wallyworld> hmpf
<wgrant> And Windmill didn't catch it 'cause it wasn't running them until 5 minutes ago.
<wgrant> AssertionError: Failure in lp/app/javascript/tests/test_picker.html.test_TextFieldPickerPlugin_selected_item_is_saved: test_TextFieldPickerPlugin_selected_item_is_saved: failed.
<wgrant> focus didn't go to the search input.
<wgrant> Expected: true (boolean)
<wgrant> Actual: false (boolean)
<wallyworld> wgrant: hmmmm. i lifted most of the code from lazr-js for that test
<wallyworld> ported theirs across
<wgrant> wallyworld: Let's see what happens if I run it outside Windmill.
<StevenK> I've been pondering use of Jenkins -- use Tarmac, which fires off a Jenkins paramatised build, and if the tests pass, merges it to devel. A devel build to stable could work the same way.
<wallyworld> wgrant: or perhaps in ff4
<wgrant> wallyworld: How do I run it?
<StevenK> wgrant: Does Windmill work with FF4?
<wgrant> StevenK: That's how the new build infrastructure is meant to work, exception doing the build inside tarmac.
<wallyworld> wgrant: one sec. phone just rang
<wgrant> StevenK: Not for me, but for wallyworld it does.
<StevenK> Because I've had a thought -- if we could get FF4 onto Lucid, I could convince the windmill tests to run twice -- once for 3 and once for 4
<wgrant> StevenK: I was going to talk to deryck about that some time this week.
<wgrant> And Chromium too.
<wgrant> wallyworld: It turns out that having JS built in the relevant branch helps.
<wgrant> I can see the failure outside Windmill now.
<wgrant> Works in Chromium, not FF3.
<StevenK> Hm, it would have to be a seperate builder inside Jenkins, which makes me sad.
<lifeless> matrix build ftw
<wgrant> Unexpected error: simulateMouseEvent(): Invalid target.
<StevenK> lifeless: Yes, that was my plan
<wgrant> StevenK: Why is that sad?
<wgrant> It's how it should be, I think.
<wallyworld> wgrant: to run outside wm you need to open the html file in a browser
<StevenK> Because it would be almost-but-not-quite the same as the lucid builder
<wgrant> Ah.
<wgrant> wallyworld: nth-child(2)
<wgrant> I bet that's it.
<wallyworld> wgrant: the html files is in the same dir
<wgrant> "Hmm... according to this page Firefox 3.0 does not support :nth-child"
<wallyworld> wgrant: that expr will pick the no button
<wallyworld> if it exists :-)
<wallyworld> wgrant: that's fooked. does it say what to use instead?
<wgrant> Hmm. It at least somewhat supports it.
<wgrant> But not completely.
<wallyworld> wgrant: there must be an alternative you'd think. btw, jquery and windmill don't play well together :-(
<wgrant> wallyworld: Oh?
<wallyworld> i've reverted to using xpath most times now :-(
<wgrant> Ah, right.
<wallyworld> wgrant: yeah, waitsForElement gives false positives
<wgrant> Awesome.
<wallyworld> ?
<wgrant> Erm.
<wgrant> nth-child(1)?
<wgrant> Doesn't that mean every child?
<wallyworld> that picks the yes button
<wgrant> I forgot the 'n' syntax.
<wgrant> So yes, you're right.
<wallyworld> first time for everything
<wgrant> wallyworld: Turns out those nth-child failures were from devel, not my fixed branch. But I can't reproduce the test_TextFieldPickerPlugin_selected_item_is_savedÂ failure outside Windmill... I guess I'll run it again once this full WindmillLayer|YUITestLayer run finishes.
<StevenK> The current Jenkins run is in the depths of make compile
<wgrant> Yeah.
<wgrant> It'll hopefully fail a few tests.
<wgrant> Or at least four.
<wallyworld> wgrant: i wish we knew why stuff that appears ok breaks inside windmill
<lifeless> thumper: ah, I didn't realise you'd chatted with poolie already - we're gtg
<lifeless> wgrant: stacking needs qa yes, and we should check its good after the deploy just-in-case.
<lifeless> -> cooking
<wgrant> lifeless: I hadn't looked hard enough to determine it was an XML-RPC change.
<LPCIBot> Project windmill build #194: STILL FAILING in 25 min: https://lpci.wedontsleep.org/job/windmill/194/
<wgrant> Erm.
<wgrant> StevenK: I wonder if it needs more quotes.
<StevenK> Haha
<StevenK> wgrant: '' sprinkled in, build scheduled
<wgrant> Thanks.
<LPCIBot> Project windmill build #195: STILL FAILING in 3 min 44 sec: https://lpci.wedontsleep.org/job/windmill/195/
<StevenK> Erm
<wgrant> Even worse.
<StevenK> Can we specify --layer more than once?
<wgrant> Don't think so. I suggest escaping the quotes.
<wgrant> Or the parens.
<wgrant> And the pipe.
<wgrant> I wonder how many levels of shell this is going through...
<StevenK> At least one :-)
<StevenK> wgrant: More escaping!
<StevenK> \\\" ...
<jtv> StevenK, wgrant: I'm trying to get a grip on what my next task means.. we need to run publish-distro -A, once, on a distroseries after we create it.  Could you help me grok?
<StevenK> wgrant: It's working!
<jtv> Specifically: is there a risk of it running more than once?  Are there known risks associated with interrupting and restarting it?  Does it take too long to incorporate in the normal scripting?
<jtv> StevenK: if you got shell escaping fixed, my hat's off to you!
<jtv> Well, helmet technically
<thumper> lifeless: I haven't talked to poolie in several days
<StevenK> jtv: 1. publish-distro -A can't run while any other publisher is running. 2. It will take a while to run.
<wgrant> jtv: It takes a while.
<wgrant> Yeah.
<wgrant> StevenK: Any other publisher *for that archive*.
<jtv> I guess this is the very step that also takes the bulk of the publish-ftpmaster time.
<wgrant> Yes.
<wgrant> Precisely.
<StevenK> And if you're testing on mawson. It will take an eon to finish.
<wgrant> Not any more.
<wgrant> More like 25 minutes.
 * jtv grins evilly
<wgrant> jtv: How are you doing it? A dirty suite flag?
<jtv> Well I'm still trying to figure that out.
<jtv> The bit about concurrent runs is one of my bigger worries: do we need a global archive FS write lock perhaps, rather than script locks?
<poolie> thumper: we talked last week though
<poolie> i'm pretty sure
<thumper> poolie: if you're happy with it, I'm happy
<poolie> i'm happy with what you described
<jtv> StevenK, wgrant: Come to think of it, the new publish-ftpmaster invokes run_publisher directly so we may have a concurrency hazard there already.
<poolie> if you can think of anything you want me to test i can
<wgrant> jtv: Why?
<wgrant> jtv: I mean, yes, but why does that in paticular make it a hazard?
<wgrant> Because it doesn't share the publish-distro.py lock?
<jtv> Right, that's in the script presumably, not in run_publisher.
<wgrant> This is indeed bordering on dire peril.
<mrevell> Hi!
<jtv> hi mrevell!
<adeuring> good morning
<jtv> wgrant: it might help for me to be aware of what global operations may mess with archives...  I take it there's database state and filesystem state that must stay in sync?
<jtv> hi adeuring!
<adeuring> hi jtv!
<StevenK> jtv: Absolutely must, yes.
<wgrant> jtv: Yes. process-accepted, publish-distro and process-death-row maintain the disk state.
<StevenK> Otherwise we can get corrupted archives, and then wgrant will kill you.
<wgrant> jtv: Those three can run in parallel, but more than one instance of each will cause grave damage.
<jtv> wgrant: that smells very much like more than should be managed by a script lock.
<wgrant> jtv: Most probably.
<wgrant> But lots of things in Soyuz smell.
 * jtv discreetly looks the otherway
<wgrant> Some admittedly smell less bad, as they can't directly destroy an archive used by many millions of machines.
 * jtv still looks the other way, but now starts blushing a bit as well
<jtv> I hear Kazakhstan has some openings for software engineers who like to get away from it all.
<jtv> wgrant: publish-ftpmaster also runs process-accepted I believe, so that's yet another locking hazard.  I'll file some bugs.
<wgrant> That's correct.
<stub> If you need more granular locks over the network, feel free to use PG advisory locks.
<wgrant> Although parallel runs of p-a are less likely to have immediately devastating effects.
<jtv> There's an idea.
 * jtv rages at browser that's failing to connect to LP
<jtv> wgrant: I'd rather maintain correctness overall than just avoid those.  Or are you trying to discourage me from trying it on the basis that immediately devastating effects are what I'm hoping for?
<wgrant> jtv: No, both should be avoided.
<jtv> Good, good.  Glad to know we're all on the same page.
<jtv> Or would be, if LP would load over this connection.
<jtv> wgrant: would you mind filing either one or two bugs about this?  The new, pythonized publish-ftpmaster script neglects to lock around run_publisher and ProcessAccepted.
<jtv> stub's still bouncing
<jtv> not a mental image I had hoped to evoke today
<jtv> Do these Three Singletons of Death operate on different bits of filesystem?  Or do they just do things in some other way happen not to affect each other?
<wgrant> jtv: They all work in archiveroot.
<wgrant> But doing different tasks.
<poolie> jelmer: https://bugs.launchpad.net/launchpad/+bug/761664
<_mup_> Bug #761664: Import from git does not update <branch-scanner> <branches> <Launchpad itself:Triaged> < https://launchpad.net/bugs/761664 >
<LPCIBot> Project windmill build #196: STILL FAILING in 41 min: https://lpci.wedontsleep.org/job/windmill/196/
<wgrant> StevenK: Success, thanks.
<wgrant> (well, failure, but the expected amount of failure)
<henninge> wgrant: Hi!
<wgrant> henninge: Hi.
<henninge> wgrant: I am surprised that you find that check_permission allows unregistered permissions.
<henninge> wgrant: because I copied that code in forwardCheckAuthenticated from check_permission ...
<wgrant> henninge: Our check_permission?
<henninge> hm, I thought so
 * henninge checks
<wgrant> Zope's checkPermission doesn't.
<wgrant> Huh.
<wgrant> our check_permission explicitly checks that.
<henninge> exactly
<wgrant> Perhaps it was not using our check_permission.
<wgrant> It was...
<wgrant> Huh.
<wgrant> Well, the fix worked :/
<wgrant> So I am very confused.
<henninge> ...
<henninge> I know the feeling
<wgrant> Oh.
<wgrant> I see.
<wgrant> I think. Maybe.
<wgrant> I see something that is wrong.
<wgrant> But that wouldn't break this...
<wgrant> henninge: forwardCheckAuthenticated fails to raise a ValueError when the permission is not specified.
<wgrant> henninge: I wonder if ValueError is caught somewhere and taken as if checkAuthenticated had returned False?
<henninge> wgrant: you mean not specified as a parameter and not specified as self.permission?
<wgrant> henninge: If it is specified as self.permission then it doesn't do the registration check.
<wgrant> henninge: This is wrong if the object is a different interface.
<henninge> wgrant: oh, right
<wgrant> I think that's the problem here.
<wgrant> But something hideous is converting the ValueError into a False.
<henninge> I had assumed that the permission has already been checked but missed the changed object dimension.
<henninge> that sounds bad.
<wgrant> Ah, not quite.
<wgrant>             # The IAuthorization is a named adapter from objecttoauthorize,
<wgrant>             # providing IAuthorization, named after the permission.
<wgrant>             authorization = queryAdapter(
<wgrant>                 objecttoauthorize, IAuthorization, permission)
<wgrant>             if authorization is None:
<wgrant>                 return False
<wgrant> In LaunchpadSecurityPolicy
<wgrant> So if the adapter isn't there it returns False, indeed.
<wgrant> So, two bugs.
<wgrant> The self.permission check is bad, as I outlined earlier. That's definitely a bug.
<wgrant> But it's not clear if the ValueError behaviour is desired here.
<wgrant> Hard to say.
<henninge> wgrant: can you please file the first bug?
<wgrant> Sure.
<jtv> rvba: I'll go and relocate now, hopefully before rain and/or resumed heat.  After that, review!
<rvba> jtv: great https://code.launchpad.net/~rvb/launchpad/fix-already-computed-pckdiff-request/+merge/58257
<jtv> ta
<henninge> wgrant: to be clear, we are talking about this change, right? http://paste.ubuntu.com/596466/
<wgrant> henninge: Bug #766955
<_mup_> Bug #766955: forwardCheckAuthenticated doesn't check existence if a permission is not specified <Launchpad itself:Triaged> < https://launchpad.net/bugs/766955 >
<wgrant> Yes.
<wgrant> That is probably the fix.
<henninge> wgrant: cool, thanks
<LPCIBot> Project windmill build #197: STILL FAILING in 41 min: https://lpci.wedontsleep.org/job/windmill/197/
<lifeless> back
<henninge> wgrant: I also think that it should use queryAdapter and return False if that fails, just like checkPermission in the Policy. Ist that what you identified as the second bug?
<wgrant> henninge: Probably. I'm not sure I like that behaviour, but it would be more consistent.
<henninge> yes, it is. I'll include that.
<poolie> hi mrevell!
<mrevell> Hey poolie
<poolie> will get that for you in a sec
<mrevell> Oh thanks. I'm just curious to see what people are using and how much.
<poolie> me too
<poolie> mrevell: what's your current gpg key id?
<lifeless> night all
<poolie> night lifeless
<wgrant> Why are we making do_copy async?
<wgrant> allenap: ^^?
<allenap> bigjools: ^
<bigjools> because the moon is made of cheese
<stub> Hmm... lp-propose-merge just popped up chromium for my web browser instead of firefox. I think I need to twiddle something in this KDE thingy, but I know not what.
<bigjools> stub: you're using KDE? :)
<stub> Yeah - giving the new version a try. Looking good, although still haven't managed to fully purge those ayatana scrollbars yet.
<bigjools> what are those?
<bigjools> and did you figure out the default browser change?
<stub> bigjools: no
<bigjools> fire up System Settings
<bigjools> then look in Workspace Appearance and Behavior -> Default Applications
<stub> bigjools: The new scrollbars that appear when you hover over the right spot - I think GTK only? Anyway... pain to use with this trackball or maybe it is just me.
<bigjools> oh you might be able to get rid of those, let me see
<poolie> huh i just got something odd
<bigjools> in the System Settings, have a looksee around Common Appearance...
<bigjools> -> Application Appearance
<poolie> the ajax dupe deally sasy "472201 is not a valid bug number or nickname."
<poolie> really?
<stub> bigjools: Hmm... so that will fire up firefox for all URLs, including the ones firefox can't handle like ssh: etc.
<stub> bigjools: It isn't a KDE thing - can't see anywhere to configure it anyway. There is a package you can uninstall... oh... maybe it is still in effect because I haven't rebooted.
<bigjools> stub: the GTK widgets under KDE are not really GTK widgets, they're gtkqt or something, so you can theme them
<bigjools> try fiddling with the settings in Application Appearance.  I don't get the Ayantana stuff but I'm not sure what I set :)
<stub> Its not there :) You have tomboy? Check out your scrollbar in a tomboy note.
<bigjools> stub: the "web browser" setting is only for http/https
<bigjools> stub: tomboy using normal scrollbar here
<stub> I'll reboot.
<poolie> nighta ll
<bigjools> nn poolie
<stub> aha... you have to remove both overlay-scrollbar and the liboverlay-scrollbar packages. The latter seems to be used by mono apps even when the overlay-scrollbar package has been removed.
<bigjools> fun
<jam> What is the correct protocol for getting someone to reconfigure a branch? We have a (very old) branch that has a bad stacked-on location, and I'd like to still get the new data.
<jam> (I used my leet bzrlib skills to get at the data anyway, but it would be nice to fix it)
<abentley> henninge-lunch: stand-up?
<henninge> abentley: oh sorry, forgot ...
<henninge> abentley: I guess you are done?
<abentley> henninge: no, it was just me and abel, so we decided to wait for you.
<abentley> henninge: ready now?
<stub> bigjools, rvba: So for this derivatives stuff, we have a parent/child relationship between distroseries but the is_overlay flag is going on the distribution for all its series?
<rvba> stub: correct
<bigjools> yes
<bigjools> potentially it should be on the archive actually
<bigjools> mm,m
<stub> So the owner of the parent distribution controls how people can derive from it?
<henninge> abentley: getting there ;)#
<stub> c/owner/driver/
<bigjools> stub: no, the person making a new distro sets whether it's an overlay or not
<bigjools> but I am wondering if this bool should be on IArchive instead
<henninge> abentley: do you know which port mumble uses?
<bigjools> then it can be used for PPAs
<stub> oh yeah... the flag says 'these distroseries inherit from parents'
 * henninge installed a new firewall
<abentley> henninge: Not immediately.  Lemme see...
<stub> bigjools: ok. I'll hold off reviewing that branch until tomorrow.
<abentley> henninge: I think the client may not have a default port.
<bigjools> rvba: it's probably a lot of work to move that flag to IArchive...  but I think it's better placed there.
<bigjools> you may curse me
<abentley> henninge: The server port is 64738, but that shouldn't be relevant.
<rvba> bigjools: that's ok;)
<henninge> abentley: I'll try that
<rvba> bigjools: we will talk about it later this afternoon (I may curse you at this occasion)
<abentley> henninge: try "force TCP mode" too.
<henninge> I see my lips turn red ...
<gary_poster> allenap, do you happen to know if bug heat calculations causing timeouts when trying to subscribe to a bug (https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1936QASTAGING50) is a known problem?  https://bugs.launchpad.net/launchpad/+bugs?field.searchtext=bug+heat doesn't show anything particularly relevant
<allenap> gary_poster: I've never heard of that problem before.
<gary_poster> ok thanks allenap
<wgrant> gary_poster: We often see that on qastaging due to cold cache issues.
<wgrant> gary_poster: It's fine on prod.
<gary_poster> wgrant, ah ok.  I have been trying various workarounds, and not succeeding.  I was about to create my own project to try and workaround.  Do you know any better approaches?
<wgrant> gary_poster: Get a project with fewer bugs, I guess :/
<wgrant> Or refresh a few hundred times.
<gary_poster> heh, ok thank you wgrant :-)
<wgrant> Oddly, staging seems to be mostly immune to this.
<wgrant> Despite residing on the same DB server.
<cr3> hi folks, would it be reasonable to create a team called ~launchpad-results to work on the launchpad-results project as defined in the ResultsTracker LEP?
<wgrant> henninge: +text is nowadays strongly discouraged, fwiw. We want to drop it since it can show an unbounded an often immense volume of data.
<henninge> wgrant: I see. Do we have a bug for that?
<bigjools> wgrant: rvba has a branch adding is_overlay on IDistribution but I'm looking at moving that to IArchive as I think it's better placed there.  Do you have any comment?
<wgrant> bigjools: Do we know what it does yet?
<wgrant> I think IArchive is probably better.
<wgrant> But it really depends on how it is going to work.
<bigjools> wgrant: the thing we discussed the other week; it adds the extra sources.list entry to the builders
<wgrant> bigjools: That's all it needs to do?
<bigjools> if it's on IArchive it means we can remove hard-coded PPA check
<wgrant> Not exactly.
<bigjools> yup
<wgrant> Since the default dependency is customisable.
<wgrant> You can change the used components/pockets.
<bigjools> I did say "one"
<wgrant> I'm not sure a flag is the Right Wayâ¢
<bigjools> doing something on IArchive is nearly always the right way instead of IDistribution
<wgrant> Sure.
<wgrant> It's definitely better than on IDistribution.
<wgrant> But I'm not sure either is actually good.
<wgrant> It doesn't directly help the PPA case.
<wgrant> Since in the overlay distro case it has to use the parent series, for PPAs it has to not use the parent series.
<wgrant> So it's still hard-coded.
<wgrant> So it's not a benefit.
<bigjools> things are very black and white to you huh
<wgrant> Well, it's clear that there are possibly better options.
<wgrant> That may clean this whole thing up quite spectacularly.
<wgrant> Remove the default dependency hardcoding, that sort of thing.
<wgrant> I'm trying to think how it would work with the parent relationship...
<bigjools> yeah that was always a bit of a hack
<bigjools> I wonder if, instead of a flag, we add an ArchiveDependency record at creation time
<wgrant> bigjools: Does it always overlay on top of a single distroseries?
<wgrant> Right.
* abentley changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: abentley | https://code.launchpad.net/launchpad-project/+activereviews
<wgrant> That was going to be my suggestion, once I'd worked out how the cross-distro stuff works.
<wgrant> But I think we just have to have a flag :(
<wgrant> On the archivedependency.
<wgrant> To say that we're using the parent instead.
<wgrant> But ew :/
<wgrant> Still, it lets us unify the systems.
<bigjools> not sure we need a flag
<bigjools> hmm
<wgrant> What, automatically use the parent if it's cross-distro?
<wgrant> I guess that could work...
<bigjools> the other way around
<wgrant> Hm?
<bigjools> use the parent if it's in ArchiveDependency
<bigjools> no changes required anywhere in the code, I think
<bigjools> other than adding the AD at distro setup/edit
<wgrant> bigjools: ArchiveDependency specifies an archive. We would need to detect in the code that the dependency Archive is for an alternate Distribution, and use parent_series in that case.
<wgrant> Otherwise it will try to use the child distroseries name.
<wgrant> In the parent archive.
<bigjools> ah right
<wgrant> If you have multiple parents in one distribution you're screwed, but let's hope that never happens.
<wgrant> Hmm.
<bigjools> unless we add series to archivedependency!
<wgrant> Ah, yes, this could work.
<wgrant> No.
<wgrant> So, here's an idea.
 * bigjools waits
<bigjools> rvba, you following this?
<rvba> yes
 * rvba waits too
<wgrant> When expanding each ArchiveDependency, if it's for a foreign distribution we generate one entry for each matching DistroSeriesParent.
<wgrant> So for each DistroSeriesParent where the child matches and the parent is in the dependency's distribution.
<wgrant> This way things can change between series without a problem.
<wgrant> No flag required.
<wgrant> No elaborate parent_series hack required.
<wgrant> If the archive is for the wrong distribution, it just won't be used.
<wgrant> Because there are no DistroSeriesParents for that distribution.
<wgrant> This seems reeeeasonably clean.
<abentley> rvba: do you want me to review https://code.launchpad.net/~rvb/launchpad/distro-overlay-758908/+merge/58304 or is someone else doing that?
<bigjools> FSVO clean
<rvba> abentley: please don't review it now
<rvba> abentley: I'll set it to WIP ...
<bigjools> abentley: I'm looking at it, sorry I forgot to claim it yet
<abentley> rvba: cool, thanks.
<rvba> abentley: thanks for the offer though ;)
<wgrant> bigjools: Otherwise we have to presume there's only one parent distribution, or something like that.
<wgrant> bigjools: This also allows us to easily set some parents as fully inherited, and others as overlays.
<wgrant> By adding a flag on DistroSeriesParent.
<wgrant> It's no longer Distribution- or Archive-wide, so it can change over time if necessary.
<bigjools> the overlay is the other way around really
<wgrant> Hm?
<bigjools> either my distro is an overlay or it isn't
<wgrant> Is it?
<bigjools> but ISWYM
<wgrant> I might be an overlay over Ubuntu, but I want to fully customize the OEM base overlay.
<wgrant> Without having to fully inherit Ubuntu.
<wgrant> So I have a full inheritance DSP to OEM base, and an overlay DSP to Ubuntu.
<wgrant> Hmm.
<wgrant> This is difficult.
<jtv1> bigjools: I'm thinking the publish-distro run for a new series wants to be a DistributionJob.  What needs to be done to the distroseries before we get to it?
<bigjools> yes, it's difficult :)
<bigjools> jtv1: it needs to be initialized
<wgrant> bigjools: What issues do you see in my DSP-based pplan? I think we'd have to basically implement the same thing with your proposal, except it would be a lot more hardcoded and less flexible. It may even be slightly uglier, particularly if we have to extend it later.
<bigjools> jtv1: but I need to think through the workflows again
<wgrant> bigjools: Do we know how publishing is going to be triggered for derivation in general?
<wgrant> Manual crontab editing is probably suboptimal.
<wgrant> And the solution seems fairly relevant to jtv1's problem...
<jtv1> Quite.
<bigjools> wgrant: we need  a job runner to kick it off, based on a schedule configured in the DB
<bigjools> I don't want to re-implement cron though
<jtv1> So... a cron job that runs publish-distro for all "eligible" series?
<wgrant> bigjools: It's difficult, because these jobs will take half an hour to run :(
<bigjools> wgrant: so the presence of an AD will cause us to add one sources.list for each DSP for a foreign distro
<wgrant> bigjools: For that distro, yes.
<bigjools> wgrant: possibly
<wgrant> bigjools: We'll go through all the ADs. For archives for the same distribution, we just spit out an entry for the build series.
<wgrant> For archives for other distributions, we look up all parents in that distribution, and spit out entries for them all.
<bigjools> right
<bigjools> we don't need a flag, but we do need a way of changing these dependencies
<wgrant> Yeah.
<bigjools> rvba: call? :)
<rvba> bigjools: sure
<wgrant> bigjools: We basically have to do the DSP lookup anyway, regardless of how we do this (unless we include series in the AD, which seems a bit bad).
<wgrant> bigjools: So we might as well do it this way, I think.
<bigjools> wgrant: it seems reasonable
<bigjools> we don't need any booleans now
<wgrant> Right.
 * bigjools OTP to rvba
 * wgrant -> sleep.
<bigjools> nn
<jtv1> night wgrant!
<jtv1> bigjools: I'm thinking of calling it a night as well.  I don't think I can get canonadmin to understand our latest plans; probably not worth the hassle.
<bigjools> jtv1: ok :/
<jtv1> bigjools: do let me know if you have any epiphanies or wishes about the distroseries workflow.  YWIMC.
<abentley> henninge: I'm trying to read https://wiki.canonical.com/Launchpad/Translations/ImportQueueReview but I can't tell what I need to do to assess an import.
<henninge> abentley: I have not read that document ... ;)
<henninge> abentley: I cleared the qeueu yesterday. Let's see what we have today.
<henninge> or on Monday?
<abentley> henninge: I only see two, and one may yet be auto-approved.
<henninge> abentley: I never wonder about that, I just do them all.
<henninge> abentley: so, the first one is an old aquiantance. OpenERP has tons of templates and they keep adding more.
<henninge> also, they have multiple project series.
<henninge> abentley: click on the edit icon and you'll see.
<henninge> https://translations.edge.launchpad.net/+imports/5463816
<henninge> abentley: at the bottom is some general information about the project.
<henninge> 323 templates ...
<henninge> abentley: with a project that already has templates, I assume that they get the file format right, so I don't check the file itself.
<henninge> abentley: you can have a look at existing template names (the drop-down box) but this one should not be in there.
<henninge> abentley: so this is a new one. The preset name is good to use, you can just hit "Approve"
<abentley> henninge: Okay.
<henninge> oh, the queue just grew ;)
<abentley> But those might be auto-approved.  In fact, looks likely.
<henninge> abentley: yes, let's not worry about them.
<henninge> abentley: but the next one won't, I guess.
<henninge> https://translations.edge.launchpad.net/+imports/5464373
<henninge> abentley: If you click on "1 template" in the footer, it will take you to the templates list.
<henninge> abentley: so there is alread y template of that name. Click on  "Edit"
<henninge> abentley: this is the only way to check the path of the template.
<henninge> abentley: it is "po/xcsoar.pot" which is different from "xcsoar.pot" in the entry.
<henninge> abentley: that's why it's not approved because the auto approver matches by path.
<abentley> Spelling error on that page: "its status", not "it's status"
<henninge> true
<henninge> abentley: you have two options now: Change the path of the template here and wait for the auto approver to pick it up, or ...
<henninge> approve the entry, leaving the path as it is.
<abentley> I don't know what the implications of changing the path are.
<henninge> The latter will *not* update the path of the template entry, so subsequent uploads will get stuck in the same way.
<henninge> abentley: the implication is about how future uploads will behave and it's about guessing if the file name which is in the queue entry is a one-off or if the uploader actually changed it.
<abentley> henninge: I see.
<henninge> abentley: it's all a lot of guess work, I admit ... :(
<abentley> It's not possible to have two templates with the same basename in a project, right?
<henninge> abentley: paths with directories are either from a tarball uplaod or a branch upload.
<flacoste> bigjools: that's a lot of diffs!
<bigjools> flacoste: yup!
<henninge> abentley: it is not possible to have two templates with the same name.
<henninge> abentley: that is not even possible with gettext.
<sinzui> jcsackett: do you have time to mumble. I am making no progress with bug 751995
<_mup_> Bug #751995: person-transfer-job,  ProgrammingError: permission denied for relation account <oops> <teams> <Launchpad itself:In Progress by sinzui> < https://launchpad.net/bugs/751995 >
<jcsackett> sinzui: sure.
<henninge> because with gettext name == translation domain and that needs to be unique
<henninge> abentley: btw, that spelling mistake is most likely in the interface IPOTemplate.
<bigjools> flacoste: ubuntu stops syncing a couple of months before release - that's all the packages that debian continues to change in the meantime
<abentley> henninge: does it make sense for the auto-approver to check on path if basenames are unique?
<bigjools> flacoste: see the new portlet on https://staging.launchpad.net/ubuntu/natty/
<henninge> abentley: a lot of things don't make sense with the auto-approver.
<henninge> abentley: it needs to be rewritten or more likely replaced badly.
<henninge> abentley: ah! xcsoar imports from a branch!
<abentley> henninge: curiouser and curiouser.
<henninge> abentley: and there is po/xcsoar.pot dated 2011-04-20 ...
<flacoste> bigjools:
<flacoste> 2772 packages in Sid.
<flacoste> 2289 packages in Natty.
<flacoste> i find those label unclear
<bigjools> yes
<flacoste> only in Sidf
<bigjools> there's a bug about that :)
<flacoste> only in Natty
<flacoste> cool
<flacoste> !
<flacoste> and that's great!
<sinzui> jcsackett: http://pastebin.ubuntu.com/596578/
<LPCIBot> Project windmill build #198: STILL FAILING in 1 hr 3 min: https://lpci.wedontsleep.org/job/windmill/198/
<bigjools> flacoste: I just need my RT fixing up to add the crontabs I requested and it'll all start updating properly when requesting diffs and syncing packages
<henninge> abentley: so it looks like the maintainer got impatient and uploaded the file manually.
<henninge> abentley: although it was updated in the branch this morning AFAICT.
<henninge> abentley: anyway, just approve it as it is, don't change the path. Usually it should get updated from the branch. I just wonder what is going wrong here.
<abentley> henninge: done.
<henninge> abentley: for the remaining three I agree that they should get approved automatically.
<abentley> henninge: cool.
<henninge> abentley: the real queue review happens when projects import their first template.
<henninge> abentley: Here I check for:
<henninge> - Is the template a proper gettext potemplate with header?
<henninge> - Does it use English as the source language?
<abentley> henninge: I can't do that.
<henninge> abentley: it's just about if it looks correct, not an acutal parsing.
<henninge> the importer will reject it if is wrong.
<henninge> Anyway, since I check the source language, I look at the file.
<henninge> - Is the project open source?
<abentley> henninge: I really don't feel like I could recognize a proper potemplate with a header.
<henninge> oh
<henninge> look at one, then ;-)
<abentley> henninge: :-P
 * henninge clicks master_utf8.pot in the queue
<henninge> argh, chromium recognizes POT as Powerpoint TEmplate ...
<henninge> abentley: the header is the first record with an empty msgid.
<henninge> abentley: after that follow msgid/msgstr pairs.
<henninge> abentley: the msgid contain English.
<henninge> that's all.
<abentley> henninge: And since this is a template, the msgstr is usually empty?
<henninge> s/usually//
<henninge> although you are right, it would not hurt AFAIK. We'd just ignore that information.
<henninge> abentley: yes, that is correct
 * henninge has to remember to communicate clearly.
<abentley> henninge: not empty for header, though.
<henninge> ;)
<henninge> abentley: exactly, the header is special because here the msgid is empty.
<henninge> abentley: to continue on the check list:
<abentley> henninge: firefox makes that mistake too.  Suggests maybe Launchpad's using the wrong MIME type.
<henninge> - Is the project open source? Since we cannot really remove translations, we like to double check if they are allowed to use LP for free and if the strings are not likely to be coprighted.
<henninge> although, it would not hurt *that* much.
<henninge> - More interesting: Is the project maintainer really representing the project? Does the project really want to use Launchpad for translations?
<henninge> We do not want to ask translators to translate stuff that will never be accepted by the upstream project. Waste of their time.
<henninge> It also creates bad feelings with projects that host their translations elsewhere and we don't want that either.
<abentley> henninge: Okay.
<henninge> - Finally: can you figure out a template name? If it is just "messages.pot" you could use the project name, else use the file name.
<henninge> And that's all I have to say about that. ;-)
<abentley> Okay, good to know.
<mrevell> Hey, anyone know why I might be getting a 404 on Packages.gz when I add a new PPA to my system?
<bigjools> mrevell: the PPA is not published yet perhaps
<bigjools> is it a new one?
<bigjools> it also needs packages in it to get published
<mrevell> bigjools, They're both fairly well established PPAs (libreoffice/ppa and gtg/ppa) with packages in them.
<bigjools> mrevell: it's probably pebkac then :)
<jcsackett> can anyone qa bug 377519? i'm not sure how to go about it.
<mrevell> Maybe I've just been unlucky with both PPAs. I'll try another
<_mup_> Bug #377519: Stacked on location breaks if the stacked upon branch is renamed <branch-stacking> <lp-code> <qa-needstesting> <Launchpad itself:Fix Committed by thumper> < https://launchpad.net/bugs/377519 >
<bigjools> mrevell: paste me the error
<mrevell> bigjools, heh, I don't see how I can get add-apt-repository wrong :) here's the error: http://pastebin.ubuntu.com/596596/
<bigjools> mrevell: well, you did.  Look at the URL ...
<bigjools> "pp"
<mrevell> pp, yeah, I spotted that
<mrevell> but ... maybe hrm
<mrevell> erm
<mrevell> bigjools, Does this prove my innocence? http://pastebin.ubuntu.com/596597/
<bigjools> mrevell: weird.  What does sources.list.d/thing.list have in it?
<mrevell> bigjools, deb http://ppa.launchpad.net/libreoffice/ppa/ubuntu maverick main
<mrevell> deb-src http://ppa.launchpad.net/libreoffice/ppa/ubuntu maverick main
<bigjools> !
<bigjools> wth is going on then
<mrevell> Odd, eh
<bigjools> is it repeatable?
<mrevell> bigjools, Yes, so far with the two PPAs and both through Software Centre and the terminal. I'll try a third if you like.
<bigjools> mrevell: I mean, does the apt-get update do the same thing next time
<mrevell> bigjools yeah
<bigjools> mrevell: well if sources.list is correct then it's an apt bug
<bigjools> but there must be something else, I can't see that being wrong
<mrevell> bigjools, Interestingly all my other PPAs are fine.
<bigjools> mrevell: there's no weird crontrol char in the sources.list file is there?
<mrevell> Ah crap, I've just done a dist-upgrade and didn't spot that it was planning to remove all of OOo. Why would it do that? That's an aside, though. Let me check for weird control chars.
<bigjools> mrevell: conflicts
<benji> abentley: after screwing up the MP a couple of times, I have a very small branch for review: https://code.edge.launchpad.net/~benji/launchpad/fix-help-link-3/+merge/58524
<abentley> benji: looking...
<mrevell> bigjools, I don't see anything odd. I've cleared out all the entries relating to these buggered PPAs from sources.list.d and I'm gonna try again.
<bigjools> k
<mrevell> bigjools, Okay, I don't know what's going on but I just re-added the libreoffice PPA and pulled down the index fine. I'll keep a look out to see if anything similar happens in future.
<bigjools> !
<abentley> benji: why db-devel?
<benji> abentley: the branch that introduced the link is db-devel and it hasn't been deployed yet
<abentley> benji: did you consider making can_edit a function?  That way you can avoid repeating the code.
<benji> abentley: +1 I'll do that.
<abentley> benji: aside from that, r=me
<benji> cool, thanks
<adeuring> abentley: https://code.launchpad.net/~adeuring/launchpad/api-query-permissions-on-object/+merge/58136
<adeuring> could have a look?
<abentley> adeuring: happy to.
<abentley> adeuring: you have two "canWrite(productseries..." calls.  Why not combine them?
<adeuring> abentley: dou you mean in setPackagingReturnSharingDetailPermissions()? That's what we discussed: The calls check for different actions.
<adeuring> The result is at present the same for both calls, I know
<abentley> adeuring: Right.
<abentley> adeuring: But why are you defining canWrite to be variadic and then calling it twice?
<adeuring> abentley: that was a suggestion from Gary. It might make sense in other circumstances to check several attributes at once.
<abentley> adeuring: why not canWrite(productseries, 'branch', 'translations_autoimport_mode') ?
<gary_poster> yeah, I said that might be nice.
<abentley> adeuring: You imply that it doesn't make sense in these circumstances to check several attributes at once.  Is that what you mean?
<adeuring> abentley: well, if you prefer that, we can do it that way. They idea for the separation was "just in case that the attributes will in the future have different permission settings"
<gary_poster> I didn't know if it made sense to implement it now
<abentley> adeuring: I'm not suggesting that you should check only one of the attributes.
<abentley> I'm suggesting you should check two at once.
<adeuring> ok let's do it.
<gary_poster> (well, lazily and them I assume)
<abentley> adeuring: canWrite returns a list, right?  So you're returning 1-entry lists in the dict?  Is that what you intend?
<adeuring> abentley: no, it return simply True or False
<abentley> adeuring: Oh, with this all thing.
<abentley> gary_poster: did you intend to OR the permissions?
<abentley> gary_poster: actually, I guess that's AND?
<gary_poster> abentley: yes, AND
<gary_poster> abentley, though it's entirely driven by use case in my own mind
<gary_poster> It was a brainstorm at the time
<gary_poster> if it is more useful to do something else, then, maybe
<gary_poster> but AND seems nice and simple
<gary_poster> and works if you only have a single permission
<gary_poster> I'd be tempted to say that canWrite should always return a single bool
<gary_poster> if you want a list of bools, make another method
<abentley> gary_poster: IMO, the list is more general.
<adeuring> well, that would not buy us much compared to list comprehensions
<gary_poster> abentley, IMO, the bool is easier to use in the common case :-)
<gary_poster> but I'm saying that if I'm wrong, then there you go, go with a list
<abentley> gary_poster: and there's a case to be made for doing multiple lookups at once to improve performance.
<gary_poster> but otherwise I'd advocate separate methods
<gary_poster> abentley, yes.  They seem like both useful approaches to me, both of which could be used for improving performance.  Admittedly, the list approach could be used more generally, but at the cost of, IMO, awkwardness in the kind of case I'm imagining.  Again, I'd be driven by use cases, and I only have ones that I'm imagining.
<abentley> gary_poster: in which case, YAGNI.  Especially because if you ever encounter those cases, you can extend it without changing the existing callers.
<gary_poster> YAGN what?
<adeuring> [user.canWrite(obj, attr) for attr in 'a', 'b'] does the same as returning a list
<abentley> gary_poster: You Ain't Gonna Need It.
<adeuring> in that case I#d prefer a single argument
<gary_poster> abentley, I mean, what does "it" refer to it in your statement
<abentley> gary_poster: variadic behaviour for canWrite.
<abentley> adeuring: I prefer a single argument, too.
<adeuring> well, ok...
<abentley> adeuring: sorry, about the earlier suggestion.  I misunderstood why canWrite accepted multple arguments.
<gary_poster> abentley, yeah, that's what I was saying at the time to adeuring.  variadic was interesting, but nothing to explore unless we discover we need it.  If there's already a use case, yay.  If not, let's move on.
<gary_poster> The only point to consider then, though, is that if we are going that way, then we are saying that canWrite returns a bool.  That contract can be continued in a hypothetical variadic future if results are ANDed together.
<gary_poster> but I'm thrilled to defer that conversation to a later time.
<abentley> gary_poster: right, that's what I meant by "if you ever encounter those cases, you can extend it without changing the existing callers."
<gary_poster> cool, I think we're on the same page then abentley.
<sinzui> Ursinha: ping
<Ursinha> sinzui, pong
<Ursinha> hi
<Ursinha> what's broken
<Ursinha> ?
<sinzui> Ursinha: I am trying to reproduce an oops. This one indirectly involved you: https://lp-oops.canonical.com/oops/?oopsid=OOPS-1935REPORTIFSEEN298
 * Ursinha looks
<sinzui> Ursinha: I do not think you got an email about Rodrigo Catto  joining https://launchpad.net/~ubuntu-br-rj, which you are an admin for via https://launchpad.net/~conselhobrasil/+members
<Ursinha> sinzui, let me see, I archive all those emails without reading them
<sinzui> Ursinha: do you know if any of the admin members changed something about their email address or the team itself https://launchpad.net/~conselhobrasil
<sinzui> I have created what I see, but do not get an oops :(
<adeuring> abentley: new version pushed
<Ursinha> sinzui, the team has no contact email
<Ursinha> which is wrong
<Ursinha> grrr
<Ursinha> I should be admin of that team
<sinzui> Ursinha: I testing a NEW email address for the team, but that did not cause an oops either
<Ursinha> maybe the owner changed that, but he said anything
<Ursinha> I can try to contact him
<sinzui> thanks Ursinha
<Ursinha> np, sorry not being more helpful
<abentley> adeuring: documentation needs to be updated to refer to a single attribute, not "all given attributes of the object"
<adeuring> gahh, sure
<adeuring> done
<abentley> adeuring: In "test_canAccess__anonymous", are you sure we're not already logged in as a user?  I thought that was part of the standard TestCase setup.
<adeuring> abentley: I'm quite sure that we aren't
<abentley> adeuring: okay.
<Ursinha> sinzui, one of the members changed the contact address for the ubuntu-br-rj team
<abentley> adeuring: This looks good.
<abentley> adeuring: r=me.
<adeuring> thanks
<abentley> adeuring: one grammar nitpick
<abentley> adeuring: "but return a dictionary which tells if the current user" => "but returns a dictionary which says whether the current user"
<adeuring> whopps, I'll fix it
<abentley> adeuring: intransitively, "tell" means something like "determine".  "I can tell it is raining when I look outside" vs "I will tell adeuring that it is raining."
<mrevell> Night all
<LPCIBot> Project windmill build #199: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill/199/
<sinzui> Ursinha: I solved the issue I with the oops. I had setup the admining team with members wrong. I reproduced the oops and now have a fix
<Ursinha> ah, cool
<jcsackett> lifeless: i made the changes you suggested on https://code.launchpad.net/~jcsackett/launchpad/bug-expiration-doesnt-oops/+merge/58412, if you would care to take another look at somepoint today.
<jcsackett> thanks for the catch, by the way. i clearly didn't think that one through. :-P
<lifeless> jcsackett: :)
<sinzui> Oh Empathy, how you continue to disappoint
<sinzui> abentley: I cannot see the topic be Empathy hates this one channel. Are you reviewing and if so, do you have time to review https://code.launchpad.net/~sinzui/launchpad/person-transfer-permission-0/+merge/58561
<abentley> sinzui: Yes and yes.
<abentley> sinzui: did you consider testing for DB permissions by just running the code using the correct database user?
<sinzui> abentley: I did not
<benji> abentley: are you ready for the most exciting MP you'll review all day? https://code.edge.launchpad.net/~benji/launchpad/update-sampledata/+merge/58563
<abentley> benji: actually, I'm trying to ascertain the scope of an operational issue atm.
<benji> abentley: well, if you can resist that incredible branch, then go ahead
<jcsackett> benji, abentley: i'll take a look at it so abentley can focus on the ops issue.
<benji> jcsackett: much obliged
<abentley> flacoste: we seem to have some busted pickers on production.  http://pastebin.ubuntu.com/596682/
<abentley> flacoste: So far, Questions and Sprints, but not bugs or translation sharing seem to be affected.
<abentley> flacoste: Busted means when you select a choice from the picker, absolutely nothing happens.
<abentley> flacoste: no javascript error, nada.
<abentley> flacoste: joey reported it and says it's affecting Linaro track leads.
<jcsackett> benji: r=me.
<benji> jcsackett: thanks!
<sinzui> jcsackett: do you have time to mumble about some oopses I am looking at
<jcsackett> sinzui: sure.
<abentley> lifeless: ^^ I think this is a critical isssue.  Do you agree?
<flacoste> abentley: yes, it does
<flacoste> it's a regression
<flacoste> is there a bug filed yet?
<abentley> flacoste: No.  I was going to start an incident report next.
<flacoste> abentley: good
<flacoste> abentley: it's sounds like a regression from wallyworld fix to the assignee widget on the bugs page
<flacoste> sinzui: ^^^wdyt?
<lifeless> abentley: busted how?
<abentley> flacoste: I have no active line manager.  Will you nominate an owner for the incident report?
<lifeless> abentley: if its that they aren't working, it should be ready for deploy
<abentley> lifeless: when you select an entry using the picker, the picker disappears, but nothing further happens.
<lifeless> the fix is in https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html
<lifeless> Revision 12868 can be deployed: qa-ok
<lifeless> Fixes: Bug:761494
<abentley> lifeless: https://wiki.canonical.com/IncidentReports/2011-04-20-LP-Broken%20pickers#preview
<flacoste> sinzui: since deryck is out sick, can you take care of this incident?
<lifeless> and Revision 12880 can not be deployed: needstesting
<lifeless> so the next thing to do is to complete qa and check its working on qastaging
<lifeless> Ursinha: also - see rev 12879 in https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html - bug not linked
<abentley> lifeless: could we deploy 12868?  That seems like it would solve the critical issues.
<lifeless> we need 12880
<lifeless> I'm just qaing it now
<sinzui> jcsackett: Question:+huge-vocabulary
<sinzui> oops
<sinzui> jcsackett:  https://devpad.canonical.com/~lpqateam/oops-summaries/production-2011-04-18.html
<abentley> lifeless: I think we should post this issue in identica.  Do you agree?
<lifeless> bah
<lifeless> it would be nice if the battery applet told me *before* running out of battery.
<lifeless> ok, we should be completely qaed when the next run goes through
<lifeless> queuing up a deploy request
<abentley> sinzui: can you please act as communications liason for this incident?
<sinzui> abentley: I will take it
<abentley> sinzui: thank you.
<abentley> sinzui: I've updated the #launchpad topic only, so far.
<abentley> lifeless: I am approaching EOD.  Can you take it from here?
<lifeless> abentley: sure
<abentley> lifeless: thanks.
* abentley changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews
<Ursinha> lifeless, I believe I found out the problem, working on a fix
<lifeless> Ursinha: cool
* lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews
<lifeless> flacoste: ah that was it
<lifeless> flacoste: the ppr is failing to write output again
<flacoste> lifeless: yes, i saw that on the lpstats view
<lifeless> https://devpad.canonical.com/~lpqateam/ppr/lpnet/daily_2011-04-17_2011-04-18/
<flacoste> lifeless: i'll look into this, it's my next target
<lifeless> I don't know why
<lifeless> flacoste: that would be awesome; if you are too busy though I can ask stub to do so
<lifeless> flacoste: I mentioned the error rates for private bugs right ?
<lifeless> flacoste: you may find this interesting again - https://devpad.canonical.com/~lpqateam/dbr/last-15-mins.txt
<lifeless> bloat reports
<sinzui> lifeless: flacoste I was looking at an older ppr report today, and the oops reports. It is time to send question emails async. That will fix 8 of the top 10 durations
<lifeless> sinzui: yes! yes! yes! omg yes!
<lifeless> sinzui: also perhaps send less mail on 'convert to question'.
<sinzui> yes
<lifeless> sinzui: Relatedly, why do I get mail from questions that were turned into bugs when the bug changes status ?
<lifeless> sinzui: I'm already subscribed to the bug...
<sinzui> I just had my initial implement talk with jcsackett about that
<sinzui> lifeless: answers and bugs are separate apps with separate email mechanisms
<lifeless> sinzui: is it desired though?
<lifeless> or a bug?
<sinzui> No one wants duplicate emails, but we do not yet have a mechanism that can check that you do not
<lifeless> sinzui: what changes on a bug are meant to trigger question notifications ?
<lifeless> sinzui: [could we consider the question a 'team' subscribed to the bug, and have the main email code handle things]
<sinzui> We would need an identifier for every event and store it with who got it. We can then  say Robert was sent email about x. All things that want to send email need to check the log to verify it is not a duplicate
<sinzui> lifeless: I think the IBugLink creates a subscriber. The bug link could be to a question, branch, or spec
<lifeless> sinzui: what I mean is, if we remove the question event listener and instead treat the question as a source of direct subscriptions *with a filter for the events important to questions*
<lifeless> then the new bug notification stuff will:
<lifeless>  - handle the mail async for us
<lifeless>  - only send one notification to folk subscribed via both paths
<lifeless>  - (or send none if they have muted the bug etc)
<sinzui> That may work, so long as the bug code is also changed to dedupe you. It does not at this time
<lifeless> sinzui: sure it does
<lifeless> sinzui: I was reading the code yesterday
<lifeless> lib/lp/services/mail/notificationrecipientset.py
<lifeless> add()
<lifeless> if you are subscribed directly, and via two different teams, bugs only mail you once
<sinzui> That does not know you are getting email from a team with an email address
<sinzui> and if the address is an lp mailing list
<lifeless> thats true, but thats not the case thats bothering me with lp questions :)
<lifeless> its also a problem for lp questions
<lifeless> anyhow, this isn't critical
<lifeless> it just struck me the other day when I closed a bug which had an attached question
<lifeless> I have 'do not mail on own actions' turned on
<sinzui> You reported a bug about it about 2 years ago
<lifeless> heh, probably :)
<sinzui> so did jml from another path
<lifeless> I wonder if a breakdown of bug reporters in lp would be interesting.
<sinzui> I do not think anyone will challenge mpt
<sinzui> Wgrant tried
<lifeless> hmm, missed gary
<lifeless> sinzui: anything I can do for you guys today?
<sinzui> lifeless: Getting ian's fix released is my immediate concern
<lifeless> its in the automatons hands now
<lifeless> sinzui: could I perhaps ask you|ian to do the incident report ?
<sinzui> lifeless: we will
<lifeless> coo
<lifeless> l
<LPCIBot> Project windmill build #200: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill/200/
<lifeless> sinzui: deployed
<sinzui> thanks. I was just sending the annoucement
<lifeless> cool!
<lifeless> 10626231 renders by the lpnet zope appservers, excluding xmlrpc, including operational stats gathering.
<lifeless> its a little sad that 3M requests are basically nagios and haproxy whinging
<lifeless> but shrug
<mwhudson> lifeless: is that daily?
<lifeless> mwhudson: yes
<lifeless> https://devpad.canonical.com/~lpqateam/ppr/lpnet/latest-daily-categories.html
<mwhudson> cool
<lifeless> 1.64 99th percentile today
<lifeless> so even midweek we're still stable down low
<lifeless> I don't believe this category - Bugs - Bug Page
<lifeless> ^https?://bugs\.[^/]+/.+/\+bug/\d+$ 5738
<lifeless> we can't possibly do only 5.7K bug renders a day
<thumper> lifeless: so what are the popular pages?
<james_w> lifeless, that doesn't count bug task renders, which is what you get redirected to from that url isn't it?
<LPCIBot> Project windmill build #201: STILL FAILING in 41 min: https://lpci.wedontsleep.org/job/windmill/201/
<lifeless> james_w: it should match tasks
<lifeless> https://bugs.launchpad.net/udd/+bug/767711
<_mup_> Bug #767711: some kde4libs bugfix branches not visible on the bug page <Launchpad itself:Incomplete> <Ubuntu Distributed Development:New> < https://launchpad.net/bugs/767711 >
<lifeless> is a typical final url
<lifeless> thumper: https://devpad.canonical.com/~lpqateam/ppr/lpnet/latest-daily-top200.html
<lifeless> 500K https://launchpad.net/codehosting/translatePath
<lifeless> 200K https://launchpad.net/mailinglists/getMembershipInformation
<thumper> haha
<thumper> pushing branches :)
<lifeless> 350K https://api.launchpad.net/beta/ubuntu
<lifeless> 150K https://launchpad.net/+access-token
<lifeless> 1.1K https://bugs.launchpad.net/bugs/766412/+bug-portlet-subscribers-content
<lifeless> (yes, that specific portlet is top-200)
<lifeless> 1.1K https://bugs.launchpad.net/ubuntu/+bugtarget-portlet-bugfilters-stats
<lifeless> 1.1K https://bugs.launchpad.net/ubuntu/+bugtarget-portlet-tags-content
<lifeless> https://devpad.canonical.com/~lpqateam/ppr/lpnet/latest-daily-pageids.html is the interesting one in terms of templates
<lifeless> Bug:EntryResource 588039
<lifeless> 550K DistroSeries:EntryResource
<lifeless> 500K CodehostingApplication:CodehostingAPI
<lifeless> 411K Unknown
<lifeless> (yes, thats a wtf)
<lifeless> 400K Person:EntryResource
<lifeless> 370K RootObject:+login
<lifeless> 300K Distribution:EntryResource
<lifeless> 270K SourcePackage:EntryResource:getBranch
<lifeless> 230K MailingListApplication:MailingListAPIView
<lifeless> 200K Distribution:EntryResource:
<lifeless> getSeries
<lifeless> 200K BugTask:+index
<lifeless> so logging in following by bugtasks are our two highest visibility end user pages
<lifeless> highest frequency I mean
 * thumper nods
<lifeless> I suspect something off in the login case too
<lifeless> e.g. the bug with edge losing credentials for users.
#launchpad-dev 2011-04-21
<lifeless> sinzui: jcsackett: security.cfg
<lifeless> I have a suggestion
<sinzui> do tell
<lifeless> why don't we sort the permissions in each section
<sinzui> That was my suggestion too
<lifeless> analagously to what we do with imports
<lifeless> sinzui: win!
<sinzui> exactly
<sinzui> We cannot trust merge if we do not wort
<sinzui> sort
<lifeless> we could do a merge plugin
<lifeless> but sort is easier.
<lifeless> we need to check renames are solid now
<lifeless> and then trigger the mass update script
<lifeless> poolie: branch id is the default for stacking now
<poolie> great
<lifeless> no reports of zomg yet
<lifeless> I imagine tim will organise the migration script to run early next week
<lifeless> thumper: ^ not before teh weekend plox :)
<thumper> plox?
<thumper> I'm currently writing a blog post about it
<thumper> I'm happy to have the migration script run next week
<lifeless> thumper: slang for please
<lifeless> thumper: cool; I just don't want emergencies on friday:) - which is unlikely, but touching hundred-thousand plus objects...
<wgrant> This is also the worst Friday ever.
<wgrant> Since it is a 4 or 5 day weekend for most of the world.
<thumper> :)
<spiv> wgrant: ITYM best, not worst :)
<wgrant> True, true.
<spiv> If not best, then it's at least good ;)
<poolie> lifeless, there's a 9m lag between bug comments being posted and mail being sent
<poolie> do you want a bug about it?
<poolie> or not want a bug
<wgrant> No bug yet.
<wgrant> Do you have a feeling about how long this has been happening?
<poolie> i think for a week or so?
<poolie> i remember noticing lag next week and checking for a problem at my end, and whether lp was sending to the wrong address
<poolie> you can see the problem in the gap between the Date header (which i guess comes from the bug message date) and the first Received header
<wgrant> poolie: It's meant to be 5 minutes, but can reasonably be up to 8.
<poolie> well wth, i'll file and you can always close it
<poolie> oh ok
<poolie> a 5-min interval cronscript
<wgrant> Not quite.
<wgrant> We batch up to 5 minutes of events.
<wgrant> So each comment is not sent until 5 minutes have expired.
<wgrant> And the cronjob is */3 IIRC.
<wgrant> (it has been this way since at least 2006)
<wgrant> Hmm.
<wgrant> send-bug-notifications is */5 now.
<wgrant> That's less than ideal.
<wgrant> Should really be */1, I think.
<poolie> ok, so if it waits for 5m and then just-misses the next cronjob, that'd be 9m
<poolie> i'll leave it then
<poolie> rebooting for natty
<wgrant> See you next week.
<poolie> :)
<LPCIBot> Project windmill build #202: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill/202/
<nigelb> wgrant: Happy Birthday :-)
<wgrant> nigelb: Thanks.
<lifeless> wgrant: ditto
<poolie> happy birthday!
<poolie> is the 'opinion' status going to go away some time?
<poolie> i thought i'd heard that it would
<lifeless> jml will know; last I heard he was getting an ack from mark
<poolie> i hit a couple of bugs where people were confused what it meant
<poolie> probably not worth filing about
<lifeless> I need a sanity check
<lifeless> the current sample data creates the  bugtask on jokosher for bug 11 with status 10
<_mup_> Bug #11: Rosetta says there are untranslated strings, but it isn't <lp-translations> <Launchpad itself:Fix Released by carlos> < https://launchpad.net/bugs/11 >
<lifeless> which is NEW
<lifeless> nvm
<lifeless> doc fraking tests
<lifeless> facepalm
<lifeless> we expire bugs that re INCOMPLETE_WITH_RESPONSE
<lifeless> does this seem wrong ?
 * lifeless doesn't have his optimistic mojo on today
<lifeless> huwshimi: have you mailed warthogs? the rule is live
<huwshimi> lifeless: Will do now
<wgrant> Thanks lifeless, poolie.
<wgrant> lifeless: I believe bugs do expire if they have a response but then nobody touches them for two months, yes.
<wgrant> Which happens all the time in Ubuntu.
<wgrant> Looks like the expire-bugtasks unbreakage worked.
<lifeless> wgrant: I think this sucks
<wgrant> lifeless: Yes.
<StevenK> Bad machine! No cookie for you.
<lifeless> helpful : https://bugs.launchpad.net/launchpad/+bug/484712/+activity
<_mup_> Bug #484712: Potential synchronisation of comments between Launchpad bugs via remote bug trackers <bugwatch> <lp-bugs> <Launchpad itself:Expired> < https://launchpad.net/bugs/484712 >
<lifeless> spot when it became incomplete
<wgrant> Must have been filed Incomplete.
<wgrant> ** Affects: malone
<wgrant>      Importance: High
<wgrant>      Assignee: Graham Binns (gmb)
<wgrant>          Status: Incomplete
<wgrant> So, yes.
<lifeless> -win-
<lifeless> I've assigned it to him now :>
<lifeless> what to do, what to do.
<lifeless> expiry still going :)
<poolie> wgrant: isn't bug 767084 a regression?
<_mup_> Bug #767084: "Mark as duplicate" popup gives an unhelpful error when attempted to dupe against a dupe <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/767084 >
<poolie> i distinctly recall that transitive bug marking worked a few weeks ago
<wgrant> poolie: In one direction, yes.
<wgrant> It will work if you mark a bug that has dupes as a dup.e
<wgrant> But not if you try to dupe against a bug that is a dupe.
<poolie> ah, right
<poolie> but it used to give better errors, surely?
<wgrant> Not that I've ever seen.
<wgrant> And that hasn't changed in a Long Time.
<poolie> hm
<poolie> if you say so
<jtv> StevenK: I may be missing something... I don't actually see publish-distro do any locking at all currently.
<wgrant> jtv: The script infrastructure does it.
<wgrant> Hm.
<wgrant> That's interesting.
<wgrant> It doesn't actually use the script infrastructure.
<jtv> 'zacly
<wgrant> Created new stacked branch referring to /+branch-id/24637.
<wgrant> That's a bit ugly :(
<spiv> wgrant: :(
<wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/purge-shipit-cruft/+merge/58616
<StevenK> !
<wgrant> https://code.launchpad.net/~wgrant/launchpad/exterminate-shipit-admins/+merge/58618
<spiv> I suppose the best fix there is finally figure out how to translate the paths we report back to clientsâ¦
<lifeless> we could include the project
<lifeless> /proj/+branch-id/24637
<lifeless> and ignore /proj/ on input
<StevenK> wgrant: Only niggle with the second branch is why do you assume no-priv is female? :-)
<wgrant> Bah.
<StevenK> wgrant: First branch is good, r=me
<StevenK> wgrant: Is that all of it?
<wgrant> StevenK: Yes, apart from DB cruft.
<wgrant> Which is waiting for stub.
<StevenK> Purging shipit has not felt as good as I thought it would. Can we add it back so we can remove it again?
<wgrant> We haven't reached the good stuff yet.
<wgrant> Like deleting Account.
<wgrant> But that's ages away :(
<wgrant> Damn Criticals.
<StevenK> Hold on, can't we delete parts of canonical now that shipit isn't holding them in?
<wgrant> I moved all of that to lp.shipit a couple of months ago.
<spiv> lifeless: that sounds like a nice cheap workaround
<lifeless> spiv: care to file a bug for it ?
<lifeless> thumper might even get to it next week before he completely goes
<StevenK> wgrant: canonical.mumble.widgets is sticking in my head for some reason, can haz check?
<wgrant> StevenK: That's what triggered me to move everything to lp.shipit.
<thumper> lifeless: for what?
<wgrant> canonical.widgets is now gone.
<spiv> lifeless: ok
<lifeless> thumper: 17:35 < wgrant> Created new stacked branch referring to /+branch-id/24637.
<lifeless> 17:35 < wgrant> That's a bit ugly :(
<lifeless> 17:46 < spiv> I suppose the best fix there is finally figure out how to translate the paths we report back to clientsâ¦
<lifeless> 17:45 < spiv> wgrant: :(
<lifeless> 17:46 < lifeless> we could include the project
<lifeless> 17:52 < spiv> lifeless: that sounds like a nice cheap workaround
<lifeless> 17:46 < lifeless> /proj/+branch-id/24637
<lifeless> 17:46 < lifeless> and ignore /proj/ on input
<lifeless> 17:52 < lifeless> spiv: care to file a bug for it ?
<thumper> lifeless: yes it is a bit ugly, but I always said that
<lifeless> 17:53 < lifeless> thumper might even get to it next week before he completely goes
<thumper> no, I won't get around to it
<lifeless> thumper: what do you think of the workaround I suggest
<lifeless> ok
<thumper> I've pretty much finished
<lifeless> no worries
<wgrant> Why do I have no MP mail...
<StevenK> wgrant: My DSD.parent_series branch is massive. :-(
<wgrant> StevenK: Oh?
<spiv> lifeless: https://bugs.launchpad.net/launchpad/+bug/768068 filed
<StevenK> wgrant: Since it also moves DSD and DSDJ to using DSP
<lifeless> wgrant: btw, if you're going to do the BFJ refactoring this cycle, it probably has to be started on wed
<lifeless> wgrant: (per sinzui saying it would be amongst the next work started)
<lifeless> s/cycle/before may 4th deploy
<wgrant> Hm, indeed.
<StevenK> wgrant: 924 lines, +179/-162
 * wgrant stabs adelie.
<wgrant> Stop delaying my email by 20 minutes, thanks.
<wgrant> Oh, actually, may have been loganberry.
<wgrant> Bad loganberry and adelie, BAD.
<StevenK> Can haz review?
<StevenK> https://code.launchpad.net/~stevenk/launchpad/db-use-dsp/+merge/58624
<StevenK> It's a little over-sized, will compensate with cookies (but not cake)
 * StevenK looks at spm
<spm> depends on the cookies. and you need more.
<StevenK> spm: The point was the reviewer couldn't have cake, since that's reserved. :-)
<spm> good lad; you may still get a losa xmas card (ie IOU losa's $X Cake)
<lifeless> poolie: you still up for virtual beer-chat in a bit ?
<lifeless> poolie: If so, I'm going to : pop out and grab a beer (stocks are low :P), dinner for lynne, a quick eow call with stub and then I'm up for it
<poolie> haha
<poolie> sure, why not
<poolie> let's use some kind of less echoey telephony device though
<lifeless> sure, will do
<jtv> StevenK, wgrant: got time to discuss the archives locking issue?
<wgrant> jtv: Sure.
<jtv> Thanks.
<jtv> I was thinking: we have script that work on multiple archives,
<jtv> and we may have distros sharing arhives.
<wgrant> Don't you ever say that again.
<jtv> No?
<jtv> Just mindlessly repeating what StevenK told me.
<wgrant> Well, certainly not in the current model.
<wgrant> Archive.distribution exists.
<wgrant> I guess it's possible. But it's a reasonably big change.
<wgrant> But we need to lock per-archive.
<wgrant> So distributions don't matter here at all.;
<jtv> So that brings us to the same conclusion anyway.
<jtv> Next: block or fail?
 * jtv coughs lungs out, along with pieces of chili
<wgrant> Probably fail.
<jtv> If we block, there's a risk of deadlocks.  If we fail, there's a risk of failure halfway through a script and I'm not so sure it's all idempotent.
<jtv> So:
<jtv> grab all relevant locks right at the outset, in some pre-determined global order.
<wgrant> I'd hope there'd only be one lock.
<wgrant> Except for the PPA publisher.
<wgrant> Hmm.
<jtv> Hmm.
<jtv> Or publish-ftpmaster.
<wgrant> True, now it is one.
<jtv> But we want to be able to operate on multiple distros concurrently.
<wgrant> In a single process?
<jtv> No, in concurrent processes.
<jtv> Plus some script runs operate on multiple archives concurrently, of course.
<jtv> Sorry!  I meant "sequentially" there.
<jtv> The advantage of grabbing all relevant locks is that there'll be no locking surprises later on in the script.  They can act pretty much as a single lock, except you get overlap of lock sets rather than competition for a single lock.
<jtv1> 13:56:48) wgrant: In a single process?
<jtv1> (13:56:55) jtv: No, in concurrent processes.
<jtv1> (13:57:24) jtv: Plus some script runs operate on multiple archives concurrently, of course.
<jtv1> (13:58:03) jtv: Sorry!  I meant "sequentially" there.
<jtv1> (13:59:28) jtv: The advantage of grabbing all relevant locks is that there'll be no locking surprises later on in the script.  They can act pretty much as a single lock, except you get overlap of lock sets rather than competition for a single lock.
<jtv1> (14:00:53) jtv: Grabbing them in a globally total order eliminates deadlock and livelock hazards: nobody's going to be holding the lock you want while trying to grab one of yours (or waiting for somebody who is).
<wgrant> jtv1?: Won't each job be for a single archive?
<wgrant> Once publish-ftpmaster.py dies.
<jtv1> publish-ftpmaster calls publish-distro for multiple archives, both in its old incarnation and the new.
<wgrant> For now.
<jtv1> ?
<jtv1> What's going to change?
<jtv1> For all I know it's just going to get worse once we start publishing Debug.
<jtv1> salut rvba
<jtv1> "le stigue"
<LPCIBot> Project windmill build #203: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill/203/
<wgrant> jtv1: Won't it eventually replaced with publishing jobs?
<wgrant> +be
<rvba> Hi jtv1!
<jtv1> wgrant: who am I to say?  But life in the hard school of Launchpad has taught me to be wary of "eventually."
<wgrant> jtv1: True.
<jtv1> We have real problems now.  Piling requirements onto the Final Solution is just going to make it take longer.
<jtv> So I think we can't get around concurrency plus multiple sequential locks that mustn't fail.
<wgrant> wom 3
<wgrant> Grah.
<jtv> What is this mysterious language you speak?
<wgrant> An unintended keyboard offset.
<jtv> Were you trying to type "some"?
<wgrant>  /win 3
<jtv> ah
 * jtv washes chili off hands before it causes keyboard damage
<jtv> wgrant: if a script operates on just one archive in isolation, then it should be fine for it to block.
<wgrant> jtv: Do we want it to block?
<jtv> Of course we don't want multiple instances of the same cron job to pile up, *but* if we have a non-blocking lock for the script itself then we'll only have one instance waiting at most.
<jtv> So then, blocking will help get the job done.
<jtv> We wouldn't want, for instance, cron script A failing every single time because cron script B comes in first and grabs a lock that A also wants.
<jtv> A blocking lock would help sort that out (or at least signal failure to sort it out).
<jtv> For manual scripts I'd prefer failing over blocking.
<jtv> wgrant: the 3 Singletons of Doom were publish-distro, process-accepted, and death-row, right?
<wgrant> jtv: That's correct.
<jtv> Does each of those modify the archive's database state?
<wgrant> Yes.
<wgrant> But they're meant to be safely concurrent.
<wgrant> There is probably a slight race between process-death-row and publish-distro, but it's very unlikely and never happened TTBOMK
<jtv> Well we could conceivably address that with whatever solution we come up with here.
<jtv> If all three SOD change the archive's db state, then db locking would be a possibility.
<jtv> (If they didn't, we might want to deploy them without master db access)
<wgrant> They all write to the DB.
<jtv> Right
<jtv> wgrant: what concurrency requirements do we have on PPAs when it comes to these scripts?
<lifeless> stub: around ?
<stub> Yup.
<lifeless> skype in 5?
<stub> Sure.
<stub> I'll need to let the maid in in a few mins.
<wgrant> jtv: We do them serially at the moment.
<wgrant> jtv: No significant reason for that.
<jtv> wgrant: which of these scripts operate on PPAs?
<wgrant> jtv: All of the above, when given the --ppa option.
<jtv> And you're saying two instances of the same one can operate on the same PPA at the same time?
<wgrant> No. At most one instance of each of those scripts can operate on a particular archive at a time.
<lifeless> stub: ready?
<jtv1> wgrant: So we need the same locking for PPAs that we do for distro archives... then what is the "we do them serially at the moment" that we have no significant reason for?
<stub> lifeless: yo
<lifeless> jtv1: incremental development not incremented
<spm> o/ stub
<jtv1> lifeless: huh wha?
<wgrant> jtv1: We have exactly the same locking requirements, yes. At the moment each run of the Three processes all pending PPAs serially, but there's no reason they couldn't run multiple instances of, say, publish-distro, couldn't run simultaneously in separate runners over different PPAs.
<jtv1> wgrant: ah you're saying one script could process multiple PPAs concurrently?
<wgrant> jtv1: Right.
<jtv1> Sounds nice.
<lifeless> mup poke lifeless
<jtv1> wgrant: I wonder if this should be a LEP.
<jtv1> I've got some slightly more systematic notes now, and an idea of what we want; I'll draft a rough design.
<lifeless> jtv1: I think it should be a lep if you don't know why you're doing it
<lifeless> jtv1: if you're merely trying to sort out how to do it, I don't know that LEP adds much
<lifeless> jtv1: the question for me is why do you want to change this?
<jtv1> lifeless: two separate things, arguably: an existing concurrency risk where we assumed there was a lock but there doesn't seem to be one, and second as part of derivation, we want to support multiple distros.
<jtv1> Which means that slightly freeer concurrency is needed.
<lifeless> jtv1: I don't understand the linkage
<jtv1> The linkage is incidental.  We want looser locking, but also we discovered that one lock was missing altogether.
<lifeless> unless there is an assumption we want to publish N *distros* into one archive which would be a little questionable
<jtv1> AIUI there is no such requirement just now, so we could get by with "distro _or_ archive" locking.
<jtv1> (Currently all we have is per-script locking, which turns out to be broken)
<jtv1> I'm not sure "lock this distro or archive" is better than "lock these archives" though.
<jtv1> And it's not unthinkable that we'll move to a pure per-archive model anyway, if I understood correctly.
<jtv1> So I think a LEP would be helpful for laying down what requirements we have now, and which ones we see coming.
<jtv1> Makes it easier to challenge those assumptions.
<lifeless> mrevell: your blog theme de jour: bug expiry is now *really* working
<mrevell> Hello
<jtv1> "du"
<jtv1> unless he blogs as Mr Hyde by night
<mrevell> lifeless, Oh, cool. Is there any more detail on that? I don't see anything on the list.
<lifeless> mrevell: was a simple bug
<lifeless> script was barfing
<wgrant> It expired 2000 bugs this afternoon.
<mrevell> blimey
<lifeless> mrevell: I'm on a call, but I'm sure wgrant or someone can help you come up with good blurb
<mrevell> Hey wgrant, happy birthday.
<wgrant> Thanks mrevell.
<jtv1> oh!
<jtv1> many happy returns, wgrant
<mrevell> wgrant, Do you know how long bug expiry was busted?
<wgrant> mrevell: Well, it's been busted for just about ever.
<wgrant> Since it was turned back on.
<wgrant> AFAICT.
<wgrant> scriptactivity might be able to tell us, though.
<mrevell> wgrant, Any detail on what was wrong?
<wgrant> mrevell: A missing database permission combined with a broken OOPS handler, so it wasn't logging the errors anywhere that we could see.
<wgrant> And I guess we don't have scriptactivity monitoring for it.
<lifeless> wgrant: it did a weeks run or something ok
<lifeless> and then we refactored
<adeuring> good morning
<wgrant> lifeless: Ah, I see.
<mrevell> Okay, so 2,000 bugs expired in the space of a few hours ... lots of bug mail gone out. I think it's worth a status update and a post to -users but I'm not sure it needs a blog post. I'm willing to be persuaded otherwise.
<wgrant> I agree.
<lifeless> mrevell: 'feature we said was working now works'
<lifeless> mrevell: Thats the focus I was suggesting, the # of emails is incidental
<lifeless> shiny-new really working, is more relevant
<bigjools> positive spin, lifeless should work for the gubmint
<lifeless> bigjools: shhh
<lifeless> mrevell: not that I mind, but you *did* want blog material
<mrevell> lifeless, Yes, absolutely, and thanks for thinking of the blog :) I agree that this needs announcing ... it's just that I reckon a blog post requires some explanation and hand-wringing etc in this sort of situation and I'm not sure I have a lot to say other than, "Oops, we made a mistake, didn't notice and now we've fixed it." That feels like a status message to me, not a blog post. Bah, it's too early for me to th
<mrevell> ink about this. I'll write something short and simple for the blog just in case people come there expecting an explanation.
<lifeless> up to you :)
<lifeless> I wouldn't hand wring much myself.
<lifeless> I'd say 'you may have wondered why X which we blogged about 3 months as working, was not working... it was failing and due to a second bug our alerts were not alerting. We have fixed both bugs and the service is now running well, ....
<wgrant> lifeless: And a third bug.
<wgrant> lifeless: No scriptactivity monitoring :(
<mrevell> Thanks lifeless
<lifeless> mrevell: but thats me; not saying it must be a blog or not.
<lifeless> mrevell: I know we want the home page blog posts to be a bit of advertising
<lifeless> mrevell: but being transparent and open about issues is part of who we are, and is valuable to our users, so we shouldn't be afraid of talking about things we [messed up]|[have fixed]
<mrevell> lifeless, Yeah, I agree we must be open etc. but I think the line between operational status updates on identi.ca and something requiring a blog post is pretty blurry. Having tried to write an identi.ca update I reckon it's pretty clear we need a blog post too :)
<mrevell> hey henninge, do you have time today for a call? I want to talk about the translations sharing announcement.
<henninge> mrevell: I guess I could spare the time but I'd rather do it next week, if that is OK?
<henninge> mrevell: I still need to finish the feature before we can announce it ;-)
<mrevell> henninge, I have a call scheduled with deryck to day so I can speak to him and then email you if I need any further detail.
<mrevell> Oh, right, heh, fair enough :)
<henninge> mrevell: thanks ;)
<wgrant> stub: So, ShipIt is now gone from prod. The DB can be deplagued at your leisure.
<stub> \o/
<stub> I get to delete stuff.
<stub> That is going to fsck my bloat reports :)
<stub> Person table, 90% bloat.
<wgrant> Heh.
<lifeless> validpersoncache may stop sucking
<stub> The tables will be small enough to pack them next upgrade anyway... maybe live too.
<wgrant> stub: Have the Personless Accounts all been purged yet?
<wgrant> I suspect not :(
<StevenK> allenap: https://code.launchpad.net/~stevenk/launchpad/db-use-dsp/+merge/58624
<stub> No, because they were tied up with shipit.
<stub> Almost all the personless accounts were shipit users.
<StevenK> stub: ^, too, since I need a DB review
<wgrant> stub: Ah, I guess so. So the SSO-only Accounts are still around?
<allenap> StevenK: Cheers :)
<stub> yup
<jtv1> wgrant: yhm about locks
<rvba> allenap: could you review this https://code.launchpad.net/~rvb/launchpad/add-help-initseries/+merge/58641
<allenap> rvba: Sure.
<rvba> allenap: thanks.
<allenap> rvba: I'm doing StevenK's right now, but straight after that.
<StevenK> stub: Erk, sorry, I hadn't added you as a reviewer.
<rvba> allenap: splendid. It's a very small fix.
<wgrant> Could someone please review https://code.launchpad.net/~wgrant/launchpad/bug-766742/+merge/58643?
<lifeless> try:finally: missing
<wgrant> lifeless: Bah. True.
<lifeless> a context manager/fixture would make this more obvious for simple cases
<wgrant> I was initially going to turn it into a context manager, but decided it wasn't worth it.
<wgrant> Right.
<wgrant> lifeless: As for the None thing, it gets written out as '00235-00235@openid-association-complete-stop None', which looks OK to me.
<lifeless> ok, sure
<bigjools> lifeless: around?
<bigjools> lifeless: http://pastebin.ubuntu.com/596858/
<bigjools> lazr.restful bug?
<lifeless> yes
<lifeless> lazr.restful.error appears to assume that str() works always
<lifeless> which it doesn't
<lifeless> in particular, if the context only defines __unicode__ or whatever you'll get ascii encoding happening, which is fail
<lifeless>  basically anything using str() on arbitrary objects is broken
<bigjools> so this only just started being a problem on DF
<lifeless> Rapha\xebl
<bigjools> there was a lazr.resful update
<bigjools> coincidence? :)
<lifeless> we also hired a dude with a unicode name
<bigjools> heh
<wgrant> lazr.restful hasn't been upgraded significantly in a few week.s
<wgrant> But the error handling changed a couple of months ago.
<bigjools> something just changed in the sourcecode deps, damn I forgot which
<wgrant> lazr.enum.
<lifeless> anyhow
<wgrant> Triviall change.
<bigjools> ah
<lifeless> I wouldn't worry about how we got here
<bigjools> I wonder why this is breaking now
<lifeless> we are here, and its got clearly bong code.
<bigjools> indeed
<lifeless> its trying to thow one exception
<lifeless> and its failing and barfing its internals
<lifeless> (thats a WAG)
<lifeless> anyhow, I'm not here ;)
* allenap changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: allenap | https://code.launchpad.net/launchpad-project/+activereviews
<stub> StevenK, bigjools, wgrant, rvba: So the model for derived distros is now clear? I've got this review here from StevenK for DistroSeriesDifference.parent_series
<bigjools> stub: yes, this new column allows for multiple parents for the same derivation
<wgrant> stub: I have no objections to the addition of that column.
<wgrant> The other stuff is less clear.
<stub> "The distribution series which identifies the parent series with the difference."
<stub> Is that English?
<bigjools> barely
<bigjools> s/which/that/ maybe
<stub> I would have thought the parent_series column would reference the parent distro series, not a distro series that references the parent distro series through unspecified means.
<bigjools> or that
<jtv1> jml: https://wiki.ubuntu.com/NewReleaseCycleProcess step 11 says to have you or james_w create "the branches" for a new Ubuntu series.  What branches are those?  Are they an Ubuntu thing or would this happen for derived distros as well?
<bigjools> jtv1: package branches
<jtv1> bigjools: thanks.  Making an inventory of things that look like we could chuck into an automated initialization process.
<bigjools> jtv1: that is one of them for sure, but out of scope for us ;)
<jtv1> Wasn't planning to do them all today.  :)
<jtv1> bigjools: I do have something of an ulterior agenda in looking ahead a bit though... the process involves manual work by the Rosetta team.  :-)
<jtv1> wgrant, you'd know this: when we create a new Ubuntu series, we create override files for restricted as links pointing to the ones for main.  Do initialise-from-parent and publish-distro require that?
<wgrant> jtv1: I admit that I don't entirely understand that bit.
<jtv1> then all is lost
<wgrant> The a-f stuff is one of the few bits of Soyuz I'm quite happy to lalalallalaimnotlistening about.
<deryck> Morning, all.
<jtv> hi deryck
<wgrant> jtv: I believe it's from germinate, thought.
<bigjools> jtv: i-f-p does not, p-d does
<wgrant> jtv: I guess germinate creates one file, but a-f wants one for each component.
<wgrant> Right.
<bigjools> the override files start out as the same as the previous series
<wgrant> i-f-p doesn't care about a-f crap.
<bigjools> the override files are a freaking nightmare
<wgrant> bigjools: I'm not sure that's the case here.
<jtv> So this is ubuntu-specific on the one hand, but on the other it's required for the initial index generation?
<wgrant> This is more-extra.
<wgrant> more-extra is generated by germinate.
<wgrant> So they probably only exist on the second run.
<wgrant> Since NRCP doesn't say to copy, just to create the links.
 * jtv just keeps getting dizzy when trying to follow these conversations
<bigjools> wgrant: they have to exist or ln -s will fail
<lifeless> deryck: why does expiry expiry INCOMPLETE_WITH_RESPONSE bugs?
<wgrant> bigjools: No...
<wgrant> bigjools: It will be a dangling link.
<bigjools> ye gads
<bigjools> that's horrid
<wgrant> It's fine.
<wgrant> a-f will just see the file doesn't exist and there will be no Task headers.
<bigjools> the fact that ln lets you link to an nonexistent file I mean
<wgrant> Until the second run.
<wgrant> It's very useful!
<wgrant> It's essential here, for example.
<bigjools> I'd at least like a warning!
<jtv> Sissy.
<wgrant> ls -l -> OMG RED
<bigjools> typos are part of my life
<wgrant> UNIX doesn't do typos.
<deryck> lifeless, it's based on date of recent activity... so if the response falls outside the 60 days without activity, then it expires.  which can happen if it's been awhile since expiry has run.
<jtv> apt-get remove --purge adobe-anything ; ln -s foo<tab><tab> etc
<bigjools> ln -s importantfile overrides.mainwgrantsucks.natty
<bigjools> oops!
<lifeless> deryck: I think I'm not clear
<lifeless> deryck: we have in the UI two versions of INCOMPLETE
<lifeless> one is INCOMPLETE_WITHOUT_RESPONSE
<lifeless> and one is INCOMPLETE_WITH_RESPONSE
<deryck> right
<deryck> these are to help people find bugs they need to act on.  they have nothing to do with the rules for expiry actually.
<lifeless> the workflow we sortof suggest is that 'put the bug into incomplete, when someone responds a search for INCOMPLETE_WITH_RESPONSE will show it, and you can take it from there.
<deryck> and that is all correct.
<lifeless> myself and several others today were surprised to figure out that expiry expires both WITH and WITHOUT cases
<lifeless> so I'm not asking about the implementation, I'm asking about the intent :)
<jtv> wgrant: what exactly is "more extra" anyway?
<deryck> people assume that means expiry won't get it if there is a comment.  but that's not true, if the comment itself is also over 60 days old.
<deryck> lifeless, I don't actually no the intent from way back.  the implementation is intent at this point. :-)
<lifeless> deryck: so /why/ do we do this.
<deryck> lifeless, but I went through all this with bdmurray and ubuntu qa when we re-enabled this.  and everyone felt comfortable this was ok, and works as expected.
<lifeless> deryck: I see; I propose to file a bug then, because I think its surprising to discriminate on has/has not responded in one part of the UI but not the other.
<deryck> lifeless, actually....
<lifeless> deryck: I'll happily run it past ubuntu qa
<wgrant> jtv: We write append/prepend/something it to the extra overrides.
<deryck> lifeless, if we fix this, I'd propose we just toggle out of incomplete and drop the whole incomplete with response stuff
<deryck> there's a bug about that already
<lifeless> deryck: that would be good
<wgrant> jtv: So we generate overide.*.extra.* ourselves, then append more-extra (which is generated by cron.germinate)
<lifeless> I've nearly got a patch landed to store WITH/WITHOUT directly in the db
<jtv> wgrant: oh, so it's specifically for publish-distro to use, not e.g. food for a debian script?
<deryck> lifeless, nice
<wgrant> jtv: It is food for a Debian script, but it goes via ftparchive.py.
<lifeless> one more round of ec2 should see the last failures gone and it landed - purely an optimisation for the DB
<wgrant> jtv: So we can do with it what we wish, I guess.
<lifeless> makes task.status a property, and folds it in/out as needed
<jtv> wgrant: when you're not intimately familiar with the debian scripts it's very helpful if you can see what a file does from looking at just the LP python code.
<wgrant> jtv: Heh. You can't understand the content, but you can understand what's done with it.
<jtv> wgrant: exactly.  I don't need to understand the content for what I'm doing.
<wgrant> jtv: Although the more-extra handling is untested, IIRC.
<jtv> I very earnestly hope.  :)
<jtv> (Oh man I love moving windows in unity without dragging!  Just a 3-fingered drag)
<wgrant> My T400 touchpad doesn't do multi-finger :(
<wgrant> My 5 year old Dell does, though :(
<jtv> On recent macbooks it's already required because that's how you simulate multiple mouse buttons.
<jtv> Next, easy scrolling would be nice.
<jtv> bigjools: : I don't suppose a derived distro would be wanting the more.extra links?
<wgrant> They probably will.
<bigjools> the definitely will
<bigjools> they*
<wgrant> They should be allowed to have them.
<bigjools> Ubuntu for starters :)
<wgrant> Their hooks will create them, though.
<bigjools> yeah, I think this sort of thing should all go in hooks
<lifeless> bigjools: any reason we shouldn't set a currentseries for every distro, and require one ? (Like we require a currentseries for all products)
<lifeless> (bug 277118 would be rendered obsolete by doing this)
<wgrant> jtv, bigjools: Perhaps cron.germinate should maintain the links itself.
<_mup_> Bug #277118: +upstreamreport oopses for some distributions <lp-bugs> <oops> <ubuntu-upstream-relations> <Launchpad itself:In Progress by adeuring> < https://launchpad.net/bugs/277118 >
<wgrant> Since it's conceivable that distros may want different files for each.
<bigjools> lifeless: a db column or property?
<lifeless> bigjools: the existence of a distroseries that can match the 'development_focus' rules
<lifeless> bigjools: so nither a db column or a property - there already is a property
<jtv> wgrant: does cron.germinate facilitate such customization?
<wgrant> jtv: Hm?
<bigjools> wgrant: interesting idea
<wgrant> And it removes some stupidity from i-f-p.
<wgrant> And that can only be a good thing.
<bigjools> lifeless: is nither neither or either?
<jtv> "er... either?"
<lifeless> neither
<lifeless> the property already exists ;)
<bigjools> lifeless: so you can use that?  or am I missing something?
<jtv> wgrant: one small thing though: I think the current release procedure creates the links _before_ cron.germinate gets to run.
<lifeless> bigjools: there are distros that don't have a currentseries
<bigjools> oh you want to enforce it?
<lifeless> yes
<wgrant> jtv: Yes.
<bigjools> hmm
<wgrant> jtv: But it will just ignore them if they don't exist.
<lifeless> we do for product
<wgrant> jtv: 'it' being ftparchive.py
<lifeless> and it makes a lot of code simpler.
<bigjools> lifeless: it only really means something for soyuz-maintained distros
<lifeless> you can assume that there is a trunk (whatever its name) and that its usable and sane.
<bigjools> which is only one distro
<jtv> wgrant: won't that cause any trouble for the initial publish-distro runs that create the indexes?
<bigjools> lifeless: there's no concept of current series for the others because we don't maintain them in LP
<lifeless> bigjools: the same argument can be made about products registered in LP but not maintained in LP
<bigjools> true
<lifeless> bigjools: but we do it there, and its not really an issue - we just create trunk when the product is registered
<lifeless> no user questions or anything
<wgrant> jtv: The first run will lack the germinate output (Task headers), yes.
<lifeless> just don't let them delete it if its the last one present
<wgrant> jtv: But that's already the case, AFAICT.
<lifeless> bigjools: the context for this is:
<wgrant> jtv: NRCP creates the links, but they are dangling.
<lifeless>  - my simplifying the bugtask model post
<wgrant> jtv: Because more-extra.override.DSN.main doesn't exist yet.
<lifeless>  - and bugs like the one adeuring is looking at
<bigjools> lifeless: I don't think anything will break if we add series to other distros
<jtv> wgrant: so I needn't be worried about whether these links exist when I automate the publish-distro -A runs?
<wgrant> jtv: No. That's just to get the empty indices out there.
<wgrant> Empty indices -> no packages to look for extra overrides for.
<bigjools> lifeless: the code seems to just pick the first series it can find if it's not in one of the known "current" states
<wgrant> Except for the release pocket, which will be updated anyway in an hour.
<wgrant> With cron.germinate this time.
<lifeless> bigjools: yeah
 * jtv is slightly worried that what wgrant just burbled through the smoke of mystical herbs starts to make sense to him
<bigjools> lifeless: the states are not set by soyuz
<lifeless> bigjools: I'll suggest this to adeuring & deryck as a way to fix it
<bigjools> but they change its behaviour significantly
<bigjools> lifeless: yeah it should be ok
<lifeless> bigjools: but we don't use soyuz there, so shrug :) \o/
<bigjools> indeed
<jtv> bigjools: thanks for the review.  I shoot for tests that are short and well-named enough not to require docs.  Useful goal I hope, even if that doesn't imply realistic.  :)
<bigjools> :)
<lifeless> bigjools: https://bugs.launchpad.net/launchpad/+bug/277118/comments/3
<_mup_> Bug #277118: +upstreamreport oopses for some distributions <lp-bugs> <oops> <ubuntu-upstream-relations> <Launchpad itself:In Progress by adeuring> < https://launchpad.net/bugs/277118 >
<lifeless> deryck: ^
<adeuring> lifeless: sorry, was out for a few minutes. What about this bug?
<lifeless> adeuring: just that one way to fix it - one that is inline with other parts of the code base - is to ensure that currentseries always returns a series
<adeuring> lifeless: ah, right
<bigjools> lifeless: it begs the question, why does that page need to know what the currentseries is?
<lifeless> bigjools: because packages don't live in distros
<lifeless> bigjools: they live in distroseries.
<bigjools> lifeless: not entirely
<bigjools> the report is distro specific, there's no series in the URL
<lifeless> bigjools: I konw
<lifeless> but its deriving data from the current series
<lifeless> which is reasonable because:
<lifeless>  - we don't care about things not in the current series
<lifeless>  - nope, just one key reason
<bigjools> you don't need to know the series, you can just take the latest published version
<deryck> lifeless, we can look at the bug during standup and get one of us on it.
<lifeless> deryck: adeuring is already on it; I'm merely suggesting a possible impl strategy
<lifeless> bigjools: Module canonical.launchpad.browser.distribution_upstream_bug_report, line 161, in __init__
<lifeless>     self.packaging_url = canonical_url(self.dssp) + "/+edit-packaging"
<lifeless>   Module canonical.launchpad.webapp.publisher, line 370, in canonical_url
<lifeless>     urlparts = [urldata.path
<lifeless>   Module canonical.launchpad.webapp.publisher, line 325, in canonical_urldata_iterator
<deryck> lifeless, ah, ok.
<lifeless>     raise NoCanonicalUrl(obj, current_object)
<lifeless> NoCanonicalUrl: No url for None because None broke the chain.
<bigjools> because it's using a DSSP
<bigjools> hmph
<bigjools> well you can get the series from the latest publication
<lifeless> a possibly better question is htf these distros have publications without a currentseries
<bigjools> lifeless: it seems like the page is implemented weirdly
<bigjools> they should not, indeed
<lifeless> forcing currentseries to return something is similar to the null pattern object, but without the code duplication or the friction one has in zope (e.g. see the rather horrid (and now dead) NullBugTask)
<lifeless> whup, nearly midnight. ciao.
<bigjools> we need to look deeper at this rather than papering over the problem
<bigjools> nn lifeless
<adeuring> lifeless: Distribution.currentseries returns None no series exists at all. So, should we enforce the creation of a series?
<lifeless> bigjools: I'm not suggesting papering; I'm suggesting that there are a bunch o freasons to want currentseries to always work.
<lifeless> adeuring: yes, precisely.
<lifeless> bigjools: there may well be other problems in that page.
<adeuring> ok
<lifeless> adeuring: on staging, make a new product
<lifeless> note that it comes with a series
<lifeless> and you can't get rid of it
<adeuring> right
<bigjools> adeuring: lifeless: if therer is no current series, there can be no packages.  So there can be no upstream report.
<lifeless> you can't obsolete etc etc
<lifeless> adeuring: so I'm suggesting the same rule apply to distributions
<lifeless> bigjools: I agree that for this report there may well be other headaches in the page.
<adeuring> bigjools: well, don't ask me for details, but somehow the upstream report page breaks...
<lifeless> anyhow, must go. Have a great easter.
<bigjools> nn again :)
<adeuring> at the crash really caused by a missing series
<bigjools> adeuring: we need to look at how it thinks there are packages in a distro that is not soyuz-maintained
<bigjools> because there should be none
<adeuring> ah, ok
<bigjools> the upstream report should be empty
<bigjools> AIUI anyway :)
<adeuring> bigjools: yeah, I see it now. https://launchpad.net/archlinux is a completely empty distro, but the upstream report page crashes
<deryck> https://dev.launchpad.net/MaintenanceRotationSchedule
* jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: allenap, jcsackett | https://code.launchpad.net/launchpad-project/+activereviews
<LPCIBot> Project windmill build #204: STILL FAILING in 1 hr 3 min: https://lpci.wedontsleep.org/job/windmill/204/
<jcsackett> allenap: can you take a look at https://code.launchpad.net/~jcsackett/launchpad/remove-duplicate-settings/+merge/58529 for me?
<allenap> jcsackett: Sure.
<jcsackett> thanks!
<deryck> jam, hi.  Did you mean to target bug 437003 to lp series 2.1 and 2.2?
<_mup_> Bug #437003: Failure to autopack because of 'missing inventories' <missing-inventory> <mysql> <packs> <Bazaar:Fix Released by jameinel> <Bazaar 2.0:Fix Released by jameinel> <Launchpad itself:New> <Launchpad itself 2.1:New> <Launchpad itself 2.2:New> < https://launchpad.net/bugs/437003 >
<allenap> jcsackett: r=me
<jcsackett> allenap: thanks.
<deryck> bigjools, hi.  I'm not sure if bug 767258 is really a bug or if we just changed something?  it's about ppa stats being different since feb. 10.
<_mup_> Bug #767258: weird PPA stats before Feb 10 <Launchpad itself:New> < https://launchpad.net/bugs/767258 >
 * bigjools looks
<wgrant> deryck: I need to get hold of logs to investigate.
<wgrant> There was significant changes deployed on that date.
<bigjools> deryck: it would be a good idea to check other packages in other PPAs - it could be a genuine jump in his stats
<wgrant> I *think* the new ones are correct.
<wgrant> But I need to grab logs from both ends to verify manually.
<deryck> wgrant, bigjools -- ok, cool.  I'll triage it then.  Thanks!
<bigjools> ctrl-q FTL
<deryck> jam, I see your other bug now.  nevermind. :-)
* flacoste changed the topic of #launchpad-dev to: We have a 9s timeout!!! (2 months early | https://dev.launchpad.net/ | On call reviewer: allenap, jcsackett | https://code.launchpad.net/launchpad-project/+activereviews
* flacoste changed the topic of #launchpad-dev to: We have a 9s timeout!!! (2 months early!) | https://dev.launchpad.net/ | On call reviewer: allenap, jcsackett | https://code.launchpad.net/launchpad-project/+activereviews
<bigjools> flacoste: \o/
<abentley> henninge-afk: we were supposed to chat, right?  When would you like to do that?
<flacoste> bigjools: yep, we did it! it was 20s last year
<bigjools> flacoste: so are we going to aim for something lower before Dublin? ;)
<wgrant> We have 260 criticals :(
<jcsackett> wgrant: no raining on the parade. :-P
<benji> 20s to 9s is indeed an achievement
<flacoste> bigjools: nope, we now need to fix all the remaining critical bugs
<flacoste> wgrant: thanks for the shipit cleanup! much appreciated
<flacoste> no more proprietery links in our code base
<flacoste> well, apart our branding of course :-/
<wgrant> flacoste: Heh, yes. I think it's all gone now, apart from the DB stuff.
<bigjools> it'll be interesting to see how we hold up around ubuntu release time
<wgrant> There's no ShipIt to destroy us this time (that's happened at least twice).
<wgrant> Hmmmm.
<magcius> I want to make UI enhancements to bugs... who should I talk to?
<magcius> jam, oh, and I haven't given up on https://bugs.launchpad.net/569355 -- I'm trying to think some things through.
<jam> magcius: That bug shows as 404, is there a different number?
<magcius> https://bugs.launchpad.net/loggerhead/+bug/569355
<_mup_> Bug #569355: Left margin in code view. <loggerhead:Triaged by jstpierre> < https://launchpad.net/bugs/569355 >
<magcius> gah, you apparently need the +bug
<magcius> That's dumb.
<magcius> Bug numbers are global!
<jam> magcius: http://pad.lv/569355
<jam> :)
<wgrant> https://launchpad.net/bugs/569355
<_mup_> Bug #569355: Left margin in code view. <loggerhead:Triaged by jstpierre> < https://launchpad.net/bugs/569355 >
<magcius> One or the other, not both!
<jam> mines shorter, wgrant
<magcius> The URL is your UI too!
<wgrant> jam: Mine's real :P
<magcius> https://bugs.launchpad.net/569355 should work, no matter what.
<magcius> But that's a separate bug.
<jam> wgrant: both are redirects, I don't see how your's is more real than mine
<wgrant> jam: Well, mine is official.
<magcius> The most information I can see on that page.
<magcius> Is in the smallest font size possible.
<magcius> "John A Meinel: Needs Fixing on 2011-04-14"
<magcius> Not to mention it's "Ready for review"... even though it's already reviewed.
<magcius> If a reviewed branch is linked to a bug, then you should be able to see the comments in there.
<jam> magcius: there is a link to the review page. Usually they are different discussions
<magcius> A link that's in the smallest font on the page.
<magcius> It took me four or five minutes to find the comments I've been receiving through email..
<jam> magcius: I set it back to WiP for you
<magcius> Additionally, screenshot: http://i.imgur.com/ATjMV.png
<magcius> I see three knobs: This bug affects me, Unsubscribe, and the (-) button next to my name in subscriptions.
<magcius> How are they different?
<magcius> Additionally, why is the status in the "Affects" grid -- doesn't a bug have one status?
<jam> magcius: a bug may have different statuses in different projects, distributions, release series, etc.
<magcius> How?
<jam> loggerhead may have be suffering for something in bzr
<jam> and we fixed it in bzr
<jam> but loggerhead hasn't updated to use the new funciton
<jam> function
<magcius> That's not the same bug... is it?
<jam> or we released a fix in bzr-2.3 but it isn't in bzr-2.2
<magcius> I'm confused.
<magcius> How can a bug be "Fix Commited" in one project, but not in another?
<magcius> There's more than one bug if there's more than one fix.
<jam> magcius: because to finish off the bug it requires updating 2 code fixes
<jam> magcius: only for someone who ties Issues 1:1 with code drops
<jam> and even if you say different code bases need a different bug (I don't)
<jam> you still have multiple versions of a code base within one project
<magcius> "This isn't working"
<magcius> "That's because bzr has a bug in this... bug 12345"
<_mup_> Bug #12345: isdn does not work, fritz avm (pnp?) <isdnutils (Ubuntu):Fix Released by doko> < https://launchpad.net/bugs/12345 >
<jam> (the one in Maverick, the one in Natty, the one in Debian-sid, the one in...)
<jam> magcius: I it may be fixed by *Debian* patches, and not upstream
<magcius> jam, sure, then use the distro bug feature, not the project bug feature.
<magcius> But meh.
<magcius> Not worth fighting.
<magcius> So... there's "Affects"
<magcius> and right above it, it says the bug affects me.
<magcius> Why?
<jam> magcius: As a way to avoid "Me too" comments
<magcius> OK, sure.
<magcius> So a bug can affect users and projects.
<magcius> And there's two different UIs for each.
<magcius> er, a UI for each
<magcius> What's the difference between "Unsubscribe" and clicking the (-) next to my name in Subscriptions?
<magcius> I assume the user "affects" is just an accumulator, wheras Subscriptions is like the CC list in Bugzilla/
<magcius> Sorry for complaining, but I'm really confused after staring at this UI now.
<jam> magcius: If you say "Affects me" I believe it adds you to the list, but doesn't email you when other people comment on the bug. Subscribing sends an email for any modification. I assume the (-) is the same as Unsubscribe, not sure, though.
<magcius> OK, so we should remove the Unsubscribe and Subscribe other people
<magcius> and keep the (-) and add a new "Add user..." button
<wgrant> (-) was added to all subscriptions you can remove. This includes you and your teams. yes, it is duplicated with the (-) Unsubscribe link.
<magcius> OK.
<magcius> The fact that it displays incorrectly is a separate bug.
<magcius> Additionally, I'd like to dump the breadcrumbs under the bug title: "loggerhead >> Bugs >> Bug #569355
<magcius> "
<_mup_> Bug #569355: Left margin in code view. <loggerhead:Triaged by jstpierre> < https://launchpad.net/bugs/569355 >
<magcius> That data isn't really useful at all, and it's already in the URL if we fix the URL :D
<jam> magcius: I personally find the breadcrumbs very useful.
<magcius> Really?
<jam> yep
<magcius> How?
<jam> it is consistent between views as a way to "go up, but not all the way to the top"
<magcius> Do you find it more useful than clicking on "Overview" or "Bugs"?
<jam> magcius: It isn't huge when you are one deep. But stuff like: http://bazaar.launchpad.net/~daker/dexter-rolodex/fix.688511/view/24.1.5/data/media/background.png has breadcrumbs for the directory entries
<magcius> (also, I'd like to either get rid of Overview and/or make the title clickable)
<magcius> Oh, that's fine.
<jtv> allenap: want to do a very simple review?  https://code.launchpad.net/~jtv/launchpad/db-bug-768342/+merge/58685
<magcius> The breadcrumbs look completely different.
<magcius> Well, they're not consistent between the "View" and "Files" views, but that's a separate bug.
<allenap> jtv: Sure!
<jtv> Thanks :)
<magcius> But I have to click on the words "On hold" to get to the review comments/.
<magcius> From the bug.
<deryck> abentley, I'm reading bug 766242 as a bzr-builder issue, not launchpad.  Am I reading that wrong?
<_mup_> Bug #766242: Launchpad bzr builder can't build from some ubuntu source branches <bzr-builder:New> <Launchpad itself:New> < https://launchpad.net/bugs/766242 >
<abentley> deryck: no, it looks like a problem with the content of the branch.
<abentley> deryck: per james' comment.
<deryck> abentley, something we're doing to mess up the branch content?  Or just in the branch itself?  I'm not clear if it's a bug or not.
<abentley> deryck: So that might be a package-importer bug.  Not sure the provenance of the branch.
<abentley> deryck: Neither am I, because I don't know whether the package-importer is at fault.
<deryck> abentley, can you ask for more info then and set to incomplete?
<abentley> deryck: james knows much more about this, and he's already involved, so I'd rather leave it to him.
<deryck> abentley, fair enough.
<abentley> james_w: do we know whether the broken contents of lp:ubuntu/cloud-init are a bug in our code?
<james_w> abentley, bzr-builder, it isn't, other code, possibly, depends how it got that way
<abentley> james_w: e.g. the package importer could have created the branch?
<james_w> yes
<abentley> james_w: how could we tell?
<james_w> abentley, look at the committer of the last few revisions
<abentley> james_w: it is Scott Moser.
<james_w> or really, the first revision where the patches are applied but there is no .pc directory
<jam> deryck: speaking of which, I have no way to *actually* target bzr-2.1 and bzr-2.2 on that bug, now that I've added Launchpad
<jam> anything I can do?
<jam> (There is only one Target to Series link, and it is doing the wrong thing)
<abentley> james_w: for cloud-config-mcollective.txt, that is revno 90.
<abentley> james: that's where it's created at least.
<abentley> james_w: revno 90 also has no .pc directory.
<james_w> abentley, this looks very much like a person error
<abentley> james_w: Thanks for your help.
<deryck> jam, can you not switch to the bzr context and it work?
 * deryck is late for lunch with daughter and has to go now....
<deryck> sorry
<henninge> abentley: let's chat in like 20 minutes, ok?
<abentley> henninge: sure.
<magcius> ok, i'm just playing around with the design
<magcius> http://i.imgur.com/FYY40.png
<magcius> vs. http://i.imgur.com/ATjMV.png
<magcius> oh whoops, I forgot the "me too" button
<jtv> allenap: I'll have to be off very soon
<henninge> abentley: actually, let's chat right now ... ;)
<henninge> abentley: if that's ok?
<abentley> henninge: sure.
<allenap> Sorry jtv, for some reason that branch slipped from my memory :( I'll do it before I finish today. Sorry again.
<jtv> allenap: no worries, I can get back to it tomorrow.  Thanks.
<sinzui> jcsackett: can you review  https://code.launchpad.net/~sinzui/launchpad/dsp-question-permissions-0/+merge/58705 ... Oh can we mumble first though. I want to talk about how hard queue question emails is.
<jcsackett> sinzui: i can mumble, and then i will be happy to review the branch.
<bigjools> ec2 is borked then ... :(
<benji> bigjools: some of it is: http://status.aws.amazon.com/?a
<benji> I wonder how hard it is to retarget to the North California region.
<bigjools> I can't start my instance :(
<bigjools> heh, it's kinda funny that the US-EAST status updates are timestamped in PDT
<benji> heh, yeah I thought the same thing
<bigjools> what defines which region we use for ec2 land?
<allenap> bigjools: I /think/ it uses the default region as defined in boto.
 * bigjools ponders a hack
<gary_poster> mrevell, hi, are we chatting?
<mrevell> hi gary_poster, yes. Mumble?
<gary_poster> mrevell sure
<allenap> bigjools: ISTR that env variables can be used to override. I'm looking now.
<bigjools> ah cool
<bigjools> BOTO_CONFIG
<bigjools> ?
<magcius> OK, I know nobody is responding, but meh: http://i.imgur.com/5cdow.png
<allenap> bigjools: In ~/.boto, add a [Boto] section, and ec2_region_name. It defaults to us-east-1.
<allenap> s/and/and set/
<bigjools> coolio
<bigjools> allenap: now, to figure out what the valid values are
<bigjools> ah, the default one just started ...
<bigjools> looks like eu-west-1 would work
<allenap> bigjools: ap-northeast-1, ap-southeast-1, eu-west-1, us-east-1, us-west-1
<bigjools> you're a veritable mine of data
<allenap> bigjools: python -c 'import boto; print ", ".join(sorted(rg.name for rg in boto.connect_ec2().get_all_regions()))'
<jcsackett> sinzui: i'm confused about one thing in your tests on the branch. the second test added says it's about an indirect contact being able to reject a question, but it looks to me like it's testing that the answerer can't reject. i assume i am misunderstanding something?
 * sinzui checks diff and hopes he did not commit the verification that the assert will not fail
<dobey> hey guys
<sinzui> jcsackett: self.assertTrue(
<sinzui> 83	+            getattr(self.question, 'reject'),
<dobey> does anyone have any idea what the best way to give a "bot user" on LP permissions to view the members list of a private team would be?
<sinzui> 84	+            "Answer contact cannot reject question.")
<jcsackett> Ah, yes.
<sinzui> jcsackett: ^ If the assert fails you will see who cannot access the reject method
<jcsackett> i was reading "assertEqual." so less misunderstanding, more visually imparied.
<jcsackett> sinzui: r=me, and i think i need glasses. :-P
<sinzui> dobey: I do not know the answer, but I know other teams have done that. I think some have also give them bot access to scripts via oauth. I do not think anyone has documented how to do this
<sinzui> dobey: I think users are creating a profile (with an unique email address) for the bot. The bot uses LP API for manage resources. The bot owner does all the initial email confirmations and oauth approvals
<dobey> sinzui: hrmm. so tarmac has this awesome feature that some awesome hacker wrote, where it can check that contributors are members of certain teams, for use with contributor agreement requirements. but as we're using it in u1, it only works half-heartedly right now, because one team we really need it to read, is private; and the bot isn't (nor should it be) a member of said team
<dobey> sinzui: right. i alreaady have such a user, and have been using it for a while now. but there is a private team it needs to view member list of, without being a member itself
<henninge> abentley: I have all checks reverting correctly now except for the first one (the productseries). What could be missing?
<henninge> abentley: the branch is lp:~henninge/launchpad/devel-759606-ajaxify-delete-link if you want to have a look.
<sinzui> dobey: That is a common problem. You cannot do it at this time. We often describe it as the owner is not a member problem, but your phrasing is closer to the disclosure feature that will start in a few weeks. There the goal is to allow owners to grant access to users without granting membership/control
<sinzui> dobey:  at this time, only a team member or owner can see all the members. The bot must be a member, or a member pulls information to a secure locate that the bot can access.
<dobey> sinzui: is there any magical workaround we could use in the meantime?
<dobey> hmm
<abentley> henninge: I'll look at it in a minute.
<mrevell> deryck, hey, bdmurray has an interesting comment on the blog. I think we have a help page clash ... I've been treating https://help.launchpad.net/Bugs/Expiry as the canonical bug expiry help page. I have to run now, but I'll fix this Monday ... if you have any comments though deryck, please do email me. Cheers.
<mrevell> Bye all. I'll be back Monday.
 * deryck looks at the blog, though mrevell will never know
<deryck> bdmurray is correct
<bdmurray> \o/
<abentley> henninge: set_productseries needs an else clause that calls clear_link() like set_branch.
<henninge> abentley: ah, thanks
<henninge> abentley: I just pushed a new rev that shows the project link in the overlay.
<abentley> henninge: Until now, it didn't need to handle the case where the link had a value but was being unset.
<abentley> henninge: also, you don't need to explicitly call that.update_check(productseries_check); in set_checks.
<henninge> abentley: Yeah, all working now! ;-)
<abentley> henninge: great!
<henninge> Well, I guess I should add some tests, too.
<LPCIBot> Project windmill build #205: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill/205/
 * magcius sighs
<abentley> allenap or jcsackett: could you please review https://code.launchpad.net/~abentley/launchpad/translation-sharing-details-permissions/+merge/58746 ?
<jcsackett> abentley: sure.
<abentley> jcsackett: thanks.
<jcsackett> abentley: r=me.
<abentley> jcsackett: thanks.
<gary_poster> magcius did you ever get a reply?
<gary_poster> lifeless, ping?
<gary_poster> lifeless, in  lp.registry.browser.tests.test_milestone.TestProjectMilestoneIndexQueryCount.test_more_private_bugs_query_count_is_constant there's a comment that we should not increase the query count.
<gary_poster> I'd already adjusted my change (in code that this page, and others, call) to only increase the query count by 1, but I don't see a way to reduce the number further.
<gary_poster> I was hoping you had some ideas on decreasing that query count quickly, so I can land my very small and very loosely related branch (https://code.launchpad.net/~gary/launchpad/owner_administrator/+merge/58683).
<gary_poster> I don't see any, with a quick zoom through the code; all of the low hanging and some of the middle-hanging fruit that I can see have been picked.
<lifeless> gary_poster: hi, its easter here :)
<lifeless> gary_poster: I'll have a quick look though
<gary_poster> magcius, if you see this, I suggest that you contact Jonathan Lange <jml@canonical.com> (who is out this week) and possibly also Huw Wilkins <huw.wilkins@canonical.com> (I don't know is availability)
<gary_poster> thank you lifeless, and sorry to bother you
<lifeless> gary_poster: can you pastebin the queries you see (should be an attachment to the failure)
<gary_poster> lifeless sure 1 sec
<gary_poster> lifeless http://pastebin.ubuntu.com/597156/
<gary_poster> lifeless line 15 is the new query fwiw
<lifeless> so, one thing I see there is 5 separate person lookups after the initial user lookup
<lifeless> gary_poster: an alternate reason suggests that the meat starts at line 20
<gary_poster> the meat of what?
<magcius> gary_poster, thanks.
<magcius> I'm working on making it into tangible HTML right now.
<lifeless> gary_poster: the page
<gary_poster> magcius awesome.  Cool, I think Jonathan and Huw will be the ones who will have the perspective/authority to figure out how to run with your ideas.
<lifeless> gary_poster: after the session update traversal is complete
<gary_poster> lifeless, ah ok.  So, I think I actually see what I can do.  I think I can make the function I was working on issue less SQL.  I'm not sure it will be a big win, but it would keep us under the numbers.  Would you be alright with me landing the current branch, which I don't think will kill kittens, and then make a new bug and branch to start tomorrow to try and reduce the numbers for that one function?
<lifeless> gary_poster: so you need to raise it by 1 ?
<gary_poster> lifeless, yeah
<gary_poster> static 1
<lifeless> gary_poster: sure, that ssounds fine
<gary_poster> ok thanks lifeless.  have a great holiday and thanks for help
<lifeless> query count is just a proxy for efficiency
<lifeless> so a reasoned change is always fine
<gary_poster> cool
<LPCIBot> Project windmill build #206: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill/206/
* jcsackett changed the topic of #launchpad-dev to: We have a 9s timeout!!! (2 months early!) | https://dev.launchpad.net/ | On call reviewer: allenap | https://code.launchpad.net/launchpad-project/+activereviews
* jcsackett changed the topic of #launchpad-dev to: We have a 9s timeout!!! (2 months early!) | https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews
<cody-somerville> ubuntuone-client 1.6.1-0ubuntu3 finished building on amd64 7 hours ago but hasn't published. Is this because natty is in pre-release freeze?
<maxb> It looks published at https://launchpad.net/ubuntu/+source/ubuntuone-client/1.6.1-0ubuntu3/+buildjob/2490924
<maxb> Ah, I reckon this close to release the publisher cronjobs are probably in manual mode
<maxb> That's certainly borne out by the timestamps at http://gb.archive.ubuntu.com/ubuntu/project/trace/
<maxb> cody-somerville: ^
#launchpad-dev 2011-04-22
<Ursinha> lifeless, hi?
 * Ursinha is a sad panda
<jpds> maxb: Investigating.
<maxb> cody-somerville: ^
<jpds> Found the problem.
<magcius> hey jam
<magcius> what do you think of pulling a github and doing: http://i.imgur.com/lhCVP.png
<lifeless> Ursinha: hi? Its easter here ...
<lifeless> Ursinha: but I hate the idea of you being sad :)
<magcius> gah
<magcius> trying to follow the instruction at https://dev.launchpad.net/Running
<magcius> $ make scehma
<magcius> Missing ./download-cache.
<magcius> Developers: please run utilities/link-external-sourcecode.
<magcius> how am I supposed to run link-external-sourcecode?
<magcius> oh
<magcius> I see what happened
<Ursinha> lol
<Ursinha> lifeless, sorry to disturb you
<lifeless> Ursinha: no problem
<lifeless> Ursinha: whats up ?
<Ursinha> lifeless, was about a qa-tagger branch to review
<Ursinha> can wait until Monday, don't worry
<Ursinha> happy easter for you :)
 * wgrant curses AWS.
<LPCIBot> Project windmill build #207: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill/207/
<lifeless> Ursinha: kk
<jtv> hi lifeless!
<jtv> lifeless: I just had another silly thought about offsetless batch navigation.
<jtv> It's about presentation issues though, not performance.  Let me know if you're interested.
<lifeless> jtv1: I'm pretty much always interested ;)
<jtv1> lifeless: cool!  Okay, here's the thought: the style of batching I propose has some weirdness with the first page.
<jtv1> It's actually better, not worse, than our current offset-based weirdness, but more noticeable:
<jtv1> you may not get a full batch on the first page, just like you may not get one on the last page.
<jtv1> We could fill it out with items that were also on the previous page.
<jtv1> That means there's overlap, but maybe we could turn that into a virtue.
<jtv1> Maybe it'd be helpful if every batched page would show a bit of overlap with its adjacent pages, in a visually distinct style.
<jtv1> Think grey background or something.
<jtv1> So if you follow a "previous" link to a first page, and it needs to be filled out with overlapping data from the page you just visited, you'd instantly recognize it as overlap â just a bit more of it than usual.
<jtv> In principle we could do the same with our existing batching, but there we don't even have a way to display the items that slip through the cracks between batches.
<jtv> (Plus, come to think of it, we don't even have a notion of item identity across pages)
<jtv> So imagine seeing a first page in a batched series: the bottom item has a grey background.
<jtv> You follow the "next" link, and get to a page with a grey item from the first page, followed by regular items, and closed off by another grey item from the next page.
<jtv> If you then follow "previous" and some items have disappeared off that page, you'd still get a full batch.  But more items at the end would be grey, because they're from page #2 which you just saw.
<stub> jtv: That is a builtin feature of Zope batching. I forget the term.
<jtv> Ah!
<stub> (not the greying out, but the overlap between batches)
<jtv> Oh
<jtv> Well it'd have to be visually distinct in some way, I think.
<jtv> But it wouldn't be much use IMO if the batching has no reliable knowledge of the overlap.
<stub> It might be nice, but it doesn't have to be as I've seen it work well without it - people instinctively understand the overlap.
<stub> But that was with consistent overlap.
<jtv> Yes, and that's not always easy to get.
<jtv> And the converse, disappearing items, is much harder to understand.
<jtv> Here's a problem we've had:
<jtv> you're viewing a translation, filtering to show untranslated messages only.
<jtv> You translate all the messages you see, and hit the button that submits and takes you to the next page.
<jtv> Two things would happen:
<jtv> your offset would be increased by one batch,
<jtv> and the messages you just translated would drop out of the batch query's "WHERE" clause.
<jtv> So you just skipped a full batch!
<jtv> The fix for that is ugly and brittle.
<jtv> The batching style I outlined in Dallas naturally eliminates this complication.
<stub> Yup.
<jtv> I've got similar problems with the translations import queue: I filter for items with a given status.  I change their statuses using ajax widgets, or from forms I open in separate browser tabs.  And now the "next" link has become a Mystery Prize button.
<stub> Although I'm not sure why you skip a batch with the existing offset method. Because you are iterating over 'translatable items without translations' or something?
<jtv> Exactly.
<stub> ok
<jtv> But the same thing will happen if someone else is translating concurrently.
<stub> Right. So maybe you need a better set to iterate over. Or the 'translation torrent' idea that I don't think ever happened.
<jtv> It gets complicated and my confidence in our compensation offsets is limited.  It's fine for the scenarios it handles, but does it handle them all?
<stub> 'give me a page of strings to translate'
<jtv> What would constitute a better set though?  I think forms that show items in a given state and let you change that state are a useful pattern.
<stub> Why create a batch and step through it? Why not just a page that gives me '20 strings to translate'.
<jtv> With an "I don't like these, give me some other ones" button?
<jtv> Pick random ones each time?
<stub> If you want to do them in some order, you could pin or reserve them using a shared temporary table or even memcache. Or just return an arbitrary set and use the laws of probability and how many remaining strings to determine the likelyhood of collision.
<stub> It would be great if 10 people could sit down in a room for a day and translate some app completely.
<stub> Translation sprints might happen.
<jtv> Well there are good reasons to maintain ordering.
<jtv> Context, basically.
<jtv> I'm not sure reserving strings is a good idea, because it's hard to tell whether someone's browsing, translating, or somewhere inbetween.
<stub> Unless they told you.
<stub> You don't need one mega form that does everything.
<jtv> Have a look at the translation teams out there.  Compare them to actual contributions.
<lifeless> jtv: batchnav 1.2.4 supports contraint based batching
<lifeless> jtv: I don't understand the suggestion that the first batch is wonky - it isn't
<jtv> In id-based batching, it is.
<lifeless> I'm not sure what you mean by id based batching
<jtv> The alternative to offset-based batching.
<jtv> So the scheme I suggested in Dallas.
<lifeless> so I describe what you described in dallas as constraint based batching
<jtv> Ah ok.
<lifeless> because one uses db constraints rather than offsets to find the given batch
<lifeless> the 'page number' becomes entirely cosmetic
<jtv> Good.
<lifeless> I have a branch that switches us to batchnav1.2.4; it has some [minor] test failures
<lifeless> once thats landed (and if you want to pick it up and land it be my guest - I'm on leave till tuesday with easter)
<jtv> On urgent feature mission currently.  :/
<lifeless> then we can write adapters for a given collection to do the constraint (for db) and nonce (for the web client to hand back to us) generation
<jtv> It'd be really cool to see this.
<jtv> But I maintain that the first batch is wonky: you have to show either an incomplete batch or overlap.  Which accept as a matter of course with offset-based batching, but could be a bit misleading once overlap is otherwise completely eliminated.
<stub> SELECT * FROM Foo WHERE id > 0 LIMIT 50;
<stub> SELECT * FROM Foo WHERE id > 89 LIMIT 50;
<jtv> Now delete a few rows with id â¤ 89, and then browse backwards.
<stub> Delete all the rows with id < 89 and browse backwards - iterating over a mutating list always has problems.
<jtv> That's the point: constraint-based batching only seems to have this one.
<jtv> You have to show either an incomplete batch, or overlap with the page the user came from.
<jtv> But overlap and missed items disappear completely otherwise.
<stub> Browsing backwards, when something has deleted items that were in the previous batch, will show an incomplete batch.
<jtv> Or overlap.
<stub> Actually - it will likely show overlap.
<jtv> Why are we going in circles?
<stub> Yes.
<jtv> Anyway, this is all old hat.
<stub> I don't think anyone thinks the behaviour is a problem.
<jtv> Glad to hear you haven't run into the same users I have.
<stub> The existing OFFSET code has the same problem.
<jtv> It has much worse problems.
<jtv> What I'm saying is that given that we can eliminate those (and looking at what Robert's doing, pretty easily!) it'd be a bit misleading to leave one of them in one particular scenario by showing overlap, and it'd be a bit ugly to show an incomplete batch instead.  So showing grey overlap might be a way of dealing with that.
<jtv> The easy and consistent thing to do I think is show an incomplete batch.
<jtv> lifeless: I'd be curious to know how batchnav deals with navigating backwards!  Does it have knowledge of ordering?
<stub> Sure. Just another parameter to pass. I personally am not sure what is less surprising to users. I suspect nobody actually cares, as the existing batching systems have always had this problem and nobody has bothered to fix it.
<jtv> There's that.
<stub> lifeless' update to batchnav lets you step through using a key, ordered.
<jtv> stub: You do get situations where the top page is "latest events," and people click around a lot on the top 2 pages.  But I guess partial batches look pretty natural there.
<jtv> The reason I ask about browsing backwards is that AFAICS you need to reverse the query order at that point, for LIMIT, but then restore your "regular" order for display.
<stub> 'latest events' generally don't get deleted until they are not-so-latest-events on latter pages.
<jtv> No, but they get added.
<jtv> What happens there is: you go "next" from page 1 to page 2.
<jtv> You go "previous" from page 2 to page 1.
<jtv> Which now shows a "previous" link that takes you to... page 0.
<jtv> As I said, I guess partial batches work out to be pretty natural for that case.
<stub> If a batch knows the previous id, it can step back one batch. That batch won't know the previous id, so to step back another batch will require falling back to the OFFSET code path I suspect. Unless we maintain a list of all previous batches traversed.
<jtv> That'd give us the worst of both worlds.
<stub> (which would scale to human sized number of batches, so might be sane. Just don't show 'previous' links if we go into hundreds of batches, as then we are dealing with a bot)
<stub> Or just skip 'previous' links altogether and let users make use of that 'back' button on their browser ;)
<jtv> Maintaining a list of previous batches just opens the door to more complexity and weirdness on any page when browsing backwards.
<stub> There will always be weirdness browsing back over a mutated list.
<stub> Doctor, it hurts when I do this...
<stub> There will always be the case that all previous items have been removed after a 'previous' link has been rendered, making that link go to an empty page, the same page, or an error page.
<jtv> Yes, but we can have less weirdness with less complexity.
<stub> We are primarily interested in speed. If we can reduce weirdness and complexity without sacrificing query speed, great.
<jtv> And yes, we can.
<jtv> You can browse backwards by reversing the constraint and the sort order; it's just that then you need to put the rows inside the batch back into displayable order.
<jtv> Ahhhh
<jtv> Maybe they use cursors for that.
<stub> That method of stepping backwards looks good. I don't see why you would end up with partial batches or overlap though, except the first batch would become partial. And I don't think that is a problem.
<stub> I'm not sure what lifeless implemented in his batchnav update, but I doubt it would be much work to add your logic if he didn't.
<stub> It might make indexes more complex if we are iterating by something like 'id DESC, version' (which we are on some pages I've seen)
<jtv> The partial batches other than the first or last one only come in when you do what you suggested earlier: keep track of previous batches (which may have grown or shrunk) or fall back on OFFSET.
<jtv> Not with OFFSET, actually, but there you get overlap again.
<jtv> But anyway.
<jtv> Yes, we may have to re-consider a lot of indexes...
<stub> I suspect the solution is worse than the problem. I don't think the partial batches are a problem warranting the extra complexity or effort. We certainly don't want to fallback to OFFSET if we can avoid it since our nice 1s pages might suddenly spike to OOPS timeouts.
<jtv> Which problem and which solution are you talking about now?
<jtv> (Since we're going through so many)
<stub> maintaining a list of previously seen batch starts
<jtv> Oh, right, that's what I've been telling you all along.  :)
<jtv> However I think what you say also applies to what I said originally:
<jtv> partial batches at the head aren't a problem worth solving.  My idea wouldn't carry its weight.
<stub> I don't see how we can allow stepping backwards an arbitrary number of batches without your approach, or without falling back to slow queries.
<stub> (was that a triple negative?)
<jtv> I don't know, I'm too confused.
<stub> Step 1) Land lifeless' code.
<stub> Step 2) Improve on it if lifeless didn't think of it already.
<jtv> Well like I said, I'm curious to know how they dealt with the question of how to step backwards.  What I have right now requires an ability to invert the condition.  But I guess that knowledge is needed anyway, because the batcher needs to formulate constraints.
<jtv> But with a cursor, I suspect there's no need to invert ordering as I thought previously.
<stub> Maybe we just dropped previous links :) We certainly are not using a cursor across transactions from the webapps, because we don't have server affinity.
<jtv> No, you wouldn't want to do this across transactions.  But they could be used as a way to simulate "LIMIT from the end of the result backwards."
<jtv> Not sure that's actually better than offset-based batching performance-wise, though.
<jtv> Example:
<jtv> if your regular, forwards-facing queries go "SELECT * FROM foo WHERE id > x LIMIT 10"
<stub> I don't think SQL lets you do "LIMIT -100" :-)
<jtv> Hmmm
<jtv> Might be nice if it did.
<stub> switching that to "SELECT * FROM foo WHERE id < x ORDER BY id DESC LIMIT 10" is certainly the better performing method except on the smallest batch sizes, and then it won't be noticeably slower.
<jtv> But I guess you can simulate it with DECLARE cur FOR SELECT * FROM foo WHERE id < x ; MOVE ALL IN cur ; MOVE -10 IN cur ; FETCH ALL IN cur
<jtv> Right.
<jtv> That's going to be the more efficient way, but of course you have to put the rows back into display order afterwards.
<jtv> Hence my interest in how batchnav solves this.
<lifeless> jtv: stub: so , going 2 batches requires the key + offset
<jtv> Both!?
<lifeless> right
<jtv> By the way, when you say "going 2 batches"...
<jtv> Typo?
<lifeless> say we're on  batch N, which has as its upper row key K
<lifeless> to get batch N+2
<jtv> Ah
<lifeless> we select where keycols > K OFFSET batchsize LIMIT batchsize+1
<jtv> Yes, that's a harder problem â which we haven't even looked at so far.
<jtv> (Not _that_ much harder of course: this is basically just a shortcut for skipping batches in a result set while it's guaranteed not to change)
<lifeless> we may need to do a batchnav 1.2.5 when we start doing contraint based batches for vocabularies (which show N,N+1,N+2..N+M links at the top for some bizaare reason.
<lifeless> now, going backwards is easy
<jtv> Here it comes!
<lifeless> say we're on batch N which has as its lower row key K
<lifeless> and that the normal query is select .. order by keycols desc
<lifeless> the prior batch is obtained by
<lifeless> seleect where <=K order by keycols asc
<lifeless> (limit batchsize +1)
<lifeless> now, in the case of a concurrently edited batch, this *can* give a short batch at the start of the sequence
<lifeless> so if we get a short read
<lifeless> we do a second query to fix it up
<lifeless> and discard any excess
<jtv1> What a time for my connection to drop.
<lifeless> 17:42 < jtv> Here it comes!
<lifeless> 17:42 < lifeless> say we're on batch N which has as its lower row key K
<lifeless> 17:43 < lifeless> and that the normal query is select .. order by keycols desc
<lifeless> 17:43 < lifeless> the prior batch is obtained by
<lifeless> 17:43 < lifeless> seleect where <=K order by keycols asc
<lifeless> 17:44 < lifeless> (limit batchsize +1)
<lifeless> 17:44 < lifeless> now, in the case of a concurrently edited batch, this *can* give a short batch at the start of the sequence
<lifeless> 17:44 < lifeless> so if we get a short read
<lifeless> 17:44 < lifeless> we do a second query to fix it up
<lifeless> 17:44 < lifeless> and discard any excess
<lifeless> 17:45 -!- jtv1 [~jtv@58.136.24.13] has joined #launchpad-dev
<lifeless> 17:45 < jtv1> What a time for my connection to drop.
<jtv1> Thanks.
<lifeless> de nada
<stub> jtv1: Skype for me still sucked this morning
<lifeless> have a look at lazr.batchnav trunk if you're interested in the gory details
<jtv1> I'm on True right now; TOT and 3BB have been horrible lately.
<stub> jtv1: Crap connection for 4 days now?
<lifeless> I wrote a slice based adapter to generate the existing queries, and tested the interface reasonably comprehensively.
<jtv1> Longer.  I think I heard something about plans to make the censorship infrastructure more like China's, a few months back.
<jtv1> lifeless: so far it's pretty much all what one would guess, but it leaves me with a few questions:
<jtv1> 1. The reason I asked was that I was curious about batchnavigator's knowledge of your query's ordering.  Where does the natural order get restored?  In SQL, in the batch navigator, in the app..?
<lifeless> (oh, and the page #'s can be -totally- bogus during this :)
<jtv1> 2. Why "id <= x" and batchsize+1?
<lifeless> jtv1: in the collection slice factory
<lifeless> batchsize + 1 is due to an attempt to avoid calling count(*) on the collection
<jtv1> Oh, to see if there should be a "prev" link?
<lifeless> and next, yes.
<jtv1> Right ho.
<lifeless> its mostly defeated because we show a last link
<lifeless> if we dropped 'last' and showed 'reverse order' instead, we would be better off.
<lifeless> that becomes more of a win once we're not using OFFSET, so I imagine we will get to it eventually.
<jtv1> Well isn't "last" simply always a reverse batch without constraint?
<lifeless> right
<lifeless> but the url has the *predicted* count offset in it, because batchnav wasn't designed for mutating collections.
<lifeless> Which is a bit of an oversight in a webapp :)
<jtv1> I would've expected a change in parameters there!
<jtv1> But that's the whole problem of course: most of this is pretty easy, _apart_ from the thicker interfaces.
<lifeless> the concept of 'batch N' is deeply embedded.
<lifeless> I wanted to solve the 'we can avoid OFFSET for expensive cases' problem in this iteration.
<lifeless> we have more work to do to eliminate COUNT(*), batch #'s and so forth.
<jtv1> That'd just blow me away.
<jtv1> Still curious: when you say that the slice factory does the re-sorting of reverse batches, do you mean it generates some kind of SQL wrapper to reverse the batch, or a python sort, or what?
<lifeless> for instance I think we could (say its ordered by heat) identify the 'Nth batch'  (in the UI) as 'now showing bugtasks with less than 40 heat and bug id 45+' or something, and have it make sense to users
<lifeless> jtv1: best if you read the code at this point
<lifeless> ISliceFactory
<jtv1> \o/
<jtv1> I have this feeling there's a fascinating rabbit hole waiting behind the question of how batching should be presented.
<jtv1> (Freudian slip: my fingers tried to turn that into "how batching should be prevented")
<stub> jtv1: list.reverse() isn't expensive for a 100 item list.
<jtv1> I sometimes want "search, but don't filter the set; just take me to the right point in the batch" or "give me a little tree so I can go to 25%-or-so in one click"
<jtv1> Ah!  Just reversing the list.  How blindingly obvious.
<jtv1> And here I was thinking of all these complicated things.
<jtv1> lifeless: we also have some pretty weird behaviours for nonexistent batches past the end of the set (which people can actually reach in good faith because of concurrent changes, but we seem to pretend they must be playing doctor with their URLs or something)
<jtv1> With constraint-based nav, could we fix that to show the last batch?  I'm sure you see where I'm going with this.
<jtv1> And then of course, make the "last" links point to the batch starting at inf.
<jtv1> No new parameter, but no count query either.
<jtv1> (At least not for the "last" link)
<jtv-eat> lifeless: on the off chance that this might solve anything ^^^
<al-maisan> jtv-eat: guten Appetit :)
<lifeless> jtv-eat: uhm
<lifeless> jtv-eat: so the counting aspect is the problem for last; the actual data is retrieved by selecting from the end in reverse sort order
<lifeless> jtv-eat: constraint based batching will handle 'last' better always, but handling ' empty results because past end-of-collection' different would be fine; I think its orthogonal though
<lifeless> I do see the link you present between that and knowing the page number, but the page number is already weakened with contraint based queries.
<LPCIBot> Project windmill build #208: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill/208/
<jtv1> lifeless: I'm not sure I expressed myself as well as I might have.  I mean: AIUI you need a count query just to provide an offset for the "last" link.  If past-end-of-set pages were to show the last n items (whatever the real set size is), then you no longer need to compute anything meaningful for the "last" link.  Just give a very large number and the viewer will end up on the last page.
<jtv1> [where n is batch size, of course]
<lifeless> jtv1: the number is cosmetic
<lifeless> jtv1: page 1 of N
<lifeless> jtv1: while we show it, folk will be confused by it if it goes to 10000000 when there are 120 results ;)
<lifeless> jtv1: we show the number of results as well
<lifeless> jtv1: until we have answers for /all/ the places the collection size is shown, we can't eliminate the count
<lifeless> at the moment the count is cached on the object, so we only pay it once (but we do pay it)
<lifeless> I guess I'm saying - yes, that would avoid the mechanical reason for *that* triggering of count, but its not sufficient to eliminate the count, and its also a fairly ugly ui unless we make other changes concurrently  (and if we do that, we don't need to show a high N number at all)
<jtv1> lifeless: yeah I'm not considering page number _display_ at all here.  Then again, maybe "showing last page of about 256" would be enough for display.
<lifeless> jtv1: right, the trouble is until we've solved all the causes we haven't solved the issue ;)
<jtv1> then don't let me keep you :)
<jtv1> Seriously: great that you jumped on top of this.
<jtv1> If that expression makes any sense in English.
<jtv1> And doesn't make it sound lugubrious or salacious.
<wgrant> rvba: Hi.
<rvba> wgrant: Hi!
<wgrant> I'm not here today, and I guess Julian probably isn't either... I think we probably need to discuss this more. ArchiveDependencies are per-archive, not per-series, so I'm not sure exactly what this UI is meant to do.
<rvba> I know that the dependencies are for archives ... but since the parent/child relationship is on series, the problem you have with the UI might only be something cosmetic
<wgrant> Well, what does it mean?
<wgrant> What does the UI do if I have two series for one distro, one checked and one not?
<rvba> actually, that was my next question :)
<wgrant> We probably need a flag on DSP.
<wgrant> And we need transitive archive deps, I think :(
<jtv1> wgrant: julian shouldn't be here either, no
<jtv1> oh, hi rvba!
<rvba> hi jtv1
<lifeless> jtv: I refer you to my early perf tuesday mails where I said I would be data driven :)
<rvba> wgrant: by transitive archive you mean that one archive could depend on an archive ... depending on another one?
<lifeless> jtv: once we started to see slow-offset queries as a high fraction of timeouts, this became important to do :)
<jtv> lifeless: just saying someone else might have decided it was too hard and we'd have been the poorer for it.
<wgrant> rvba: Right. It's most obviously important for PPAs.
<lifeless> jtv: thanks :)
<wgrant> rvba: Since if they just have a dependency on their distribution's primary archive, they're not going to work well if that's an overlay archive.
<rvba> wgrant: right
<rvba> wgrant: I could look at the code but how is this supported today for PPAs?
<rvba> hardcoded some way?
<wgrant> rvba: We don't have transitive dependencies. But lib/lp/soyuz/adapter/archivedependencies.py has a _get_default_primary_archive_dependencies function that's used for non-primary archive if they don't have an ArchiveDependency for the primary archive.
<wgrant> rvba: We want to remove that hardcoding, so PPAs will start with an ArchiveDependency on the primary archive.
<wgrant> But... if the primary archive then becomes an overlay archive, we have to add new dependencies to every PPA.
<wgrant> Unless ArchiveDependencies are transitive.
<rvba> Understood.
<rvba> wgrant: since you're not here today, I don't want to bother you too much with this, I think perhaps the best thing to do is to try to summarize the things that we (well, mostly you) think about this and send an email to the 3 of us.
<rvba> I'll focus on something else today.
<wgrant> rvba: That sounds like a good idea.
<rvba> wgrant: but basically the UI (you should have received a mockup yesterday) is meant to be able to configure the archive dependencies for an archive.
<wgrant> It's a thorny issue that we need to talk through a lot.
<wgrant> JFDI is often good, but it's not going to work here :(
<rvba> perhaps the stupid part is listing the *series* instead of the *archives*
<wgrant> Except we do need to sometimes set it per-series.
<rvba> +1 for the not JFDI on this one :)
<wgrant> So, the ArchiveDependency could always exist, but DSPs are only used if they have the overlay flag set.
<wgrant> Anyway, let's discuss this on Tuesday or so.
<rvba> wgrant: all right.
<rvba> wgrant: thanks for the chat ;).
<magcius> ok
<magcius> i'm deving launchpad
<magcius> is there a way i can either add all the certificate exceptions to firefox in bulk?
<magcius> or run it in not-https mode?
<stub> I don't know how to add certificate exceptions in bulk, but there are only half a dozen domains.
<magcius> OK
<magcius> So, let's say I want to make http://bugs.launchpad.net/12345 work
<magcius> and "do the right thing"
<magcius> I think I've found the right place -- lib/lp/bugs/browser/malone.py
<magcius> OK -- how does the subdomain system work?
<magcius> Do different subdomains get different ZCMLs, and that's it?
<stub> IIRC everything is actually one big tree, and there is some magic vhosting hacked in to make /bugs (or /+bugs or /malone or whatever) work for bugs.launchpad.net. But long time since I saw that code.
<magcius> I'm just curious.
<magcius> It looks like the vhosts don't do anything different at all.
<magcius> for instance, https://blueprints.launchpad.net/ubuntu/+bug/1 works
<_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:I
<stub> yes. Your jumping into some of the oldest and cruftiest code in the codebase :)
<magcius> Yeah, the traversal stuff looks pretty ugly.
<stub> Everything used to be off  one domain, and the subdomains tacked on later.
<magcius> You depend on the MRO of all the classes.
<magcius> basically, all of the subclasses of Navigation.
<magcius> also, what is "vostok"?
<stub> One of the production servers - can't recall what its purpose is. No reason for it to be referenced in the code base.
<magcius> It's a whole other codebase.
<magcius> lp.vostok.publisher.VostokRoot
<magcius> complete with its own root object
<stub> Sounds like an internal service designed to run on a single host.
<wgrant> vostok was a former production server. lp.vostok is unrelated.
<magcius> OK.
<magcius> what is lp.vostok then?
<wgrant> It was originally to be an alternative UI for a subset of Launchpad, of which many instances would be run.
<wgrant> That never eventuated, so its purpose is approximately null.
<magcius> OK.
<magcius> So it's not running at all.
<magcius> OK.
<magcius> Is there an open bug about fixing the traversal system with respect to vhosts?
<wgrant> Fixing?
<magcius> Yes.
<wgrant> The vhosts will likely vanish soon.
<magcius> Ah.
<wgrant> But traversal with respect to them is not broken.
<magcius> Well, each vhost doesn't get its own RootObject.
<wgrant> That's correct, and intended.
<wgrant> That doesn't make it broken.
<magcius> Really?
<magcius> Well, that means that you can't do something like I described, without some serious hackery.
<magcius> as I said above, http://bugs.launchpad.net/12345 should *work*, dammit.
<wgrant> The intention of the vhosts was not to do things like that.
<wgrant> => they are not broken for the purpose for which they were introduced.
<magcius> I don't care how they were introduced, I'd expect it to be the right behavior.
<magcius> but, eh.
<wgrant> They were not introduced to change the traversal hierarchy.
<magcius> What was the purpose if not to isolate the services?
<wgrant> So having an inflexible traversal hierarchy *is* the right behaviour.
<wgrant> To provide different default views, and permit facet-specific views on some vhosts but not others.
<magcius> I don't see how you can't look at "bugs.launchpad.net" and see "things related to bugs should always go here"
<wgrant> Right, but that doesn't mean the traversal hierarchy needs to differ.
<magcius> well, that means that http://blueprints.launchpad.net/ubuntu/+bug/1 shouldn't work
<_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:I
<magcius> has the goal of faceted views been realized?
<wgrant> That would be achieved by renaming Bug:+index to Bug:+bugs-index, and setting it as a view for just the bugs facet.
<lifeless> we're currentlt reviewing the separate domains with an eye to removing them
<wgrant> Right.
<lifeless> because
<lifeless>  - slow (more ssl handshakes)
<lifeless>  - confusing
<lifeless> jml keeps asking me when / how hard :)
<lifeless> gnight
<magcius> right -- it's stupid, ugly and confusing when you can have a large number of URLs for the same bugs
<jam> magcius: honestly, I like it quite a bit, except you have to be able to combine adjacent regions so you don't overflow the text regions so much.
<jam> So if your sections 1-4 were one big box
<jam> then you could fit lots of text on the left
<jam> without causing it to overflow in weird ways
<jam> it also lets you shrink it a bit, because wrapping text on the left won't break the code lines on the right, etc.
<magcius> jam, sections 1-4?
<deryck> Morning, all.
<magcius> jam, http://i.imgur.com/9o0g5.png
<LPCIBot> Project windmill build #209: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill/209/
<magcius> jam, I forgot to re-set the border styles... I was debugging.
<jam> magcius: so I think if the contents is left justified the header should be for Revision. And I think it is using a bit too much space, but yes, I like that style
<magcius> Oh, right, that.
<jam> I also notice that you didn't actually allow the contents for the first revision to move into line 2
<magcius> I didn't even notice the right-aligned revision.
<jam> line 1 is still wider than normal
<jam> (taller)
<magcius> Yeah, that's because of how the table system works.
<jam> same for line 7
<magcius> I should probably use rowspan.
<jam> magcius: Isn't there some sort of "span" ability?
<magcius> We don't use it currently.
<jam> or do you have to nest the tables to get it
<magcius> Nah, there's rowspan.
<jam> magcius: right, so *with* rowspan, I like it, quite a bit
<jam> I don't think it is going to be particularly more costly to pull out the revision comments than it is to compute the annotation
<jam> so as long as you have to explicitly ask for annotation
<jam> I'm not as worried about performance of this
<magcius> yeah, it's "change.comment.splitlines[0]"
<magcius> The problem with rowspan is that I need to calculate the number of rows 'til the next change
<magcius> Which means that I need to refactor the annotation generator.
<jam> magcius: how is it being computed now?
<magcius> One at a time.
<magcius> In a Python generator.
<jam> (given that it is already knowing how many lines before it needs to output the same info)
<magcius> What do you mean?
<magcius> We just set a flag "new_rev"
<magcius> right now
<jam> magcius: it already omits lines if they are the same as the previous entry
<magcius> Right, there's a "new_rev"
<jam> I don't think there is much gained by using a generator here
<jam> tbh
<magcius> Right.
<jam> I think just returning lists would be fine, and let you do the work we actually want
<magcius> Right.
<jam> we already loaded *tons* of file content to do the annotation
<magcius> OK
<magcius> I'm confused about TAL
<magcius> I have a dict of lineno => Container
<magcius> and I want to access it from TAL
<magcius> I thought
<magcius> python:annotated[path(repeat/line/number)]
<magcius> would work
<magcius> WARNING:simpleTALES.Context:Exception occurred evaluating python path, exception: unsupported operand type(s) for /: 'dict' and 'unicode'
* bac changed the topic of #launchpad-dev to: We have a 9s timeout!!! (2 months early!) | https://dev.launchpad.net/ | On call reviewer: bac | https://code.launchpad.net/launchpad-project/+activereviews
<danilos> bac, when we are done with the call: https://code.launchpad.net/~danilo/launchpad/bug-761257/+merge/58801 :)
<bac> danilos: ok
<magcius> jam, http://i.imgur.com/eHfVJ.png
<jam> magcius: I really like the left border, but the width seems way too wide.
<magcius> jam, I don't understand tables at all.
<magcius> O
<magcius> I'm not sure how to say "use the minimum size possible with the least amount of wrapping"
<jcsackett> bac: i humbly request a review for https://code.launchpad.net/~jcsackett/launchpad/comment-display-rules/+merge/58760.
<bac> jcsackett: ok.  you're next.
<jcsackett> thanks, bac.
<danilos> bac, thanks
<magcius> jam, I'm getting closer.
<jam> magcius: I don't know it either. but even just saying "25 ex" or something might be reasonable
<danilos> magcius, there is min-width, max-width CSS properties in recent browsers (and CSS2 I think) that can help you with some of the stuff, but tables are generally pretty smart
<magcius> white-space: nowrap;
<magcius> http://i.imgur.com/6qBAO.png
<magcius> I did some other tweaks as well.
<danilos> magcius, I think you'd get the best result for a table itself if you didn't have width:100% on it, then it'd take the minimum space necessary
<danilos> magcius, (or equivalent of width: 100%)
<magcius> But then the width wouldn't be fixed.
<danilos> magcius, right
<magcius> That'd be even uglier :(
<danilos> magcius, how come?
<magcius> The files would be all over the place/.
<magcius> An empty file would be small
<magcius> vs. a file with a lot of big history
<danilos> magcius, oh, you have multiple tables?
<magcius> Of course. One per file.
<danilos> magcius, heh, sorry then, the screenshot seems to be one-table-per-web-page :)
<magcius> That's what I meant.
<danilos> magcius, then I don't understand what did you mean with 'the width wouldn't be fixed'?
<danilos> magcius, across different web pages?
<magcius> Yes.
<magcius> Going between tabs and pages, the files would be inconsistent.
<magcius> Or at least more inconsistent than width: 100%;
<danilos> magcius, well, I'd prefer that over the too-wide first column, but it's just a personal preference :) cheers
<danilos> bac, hi, do you happen to have any questions regarding a review?
<bac> danilos: i just got to watch your screencast for the bug.  thanks for doing it!  nice dance track.
<bac> danilos: no questions yet
<danilos> bac, heh :)
<danilos> thanks
<bac> danilos: the old method named 'unsubscribe_current_user' is misnamed now, no?
<bac> you are using it to unsubscribe a team
<danilos> bac, yes, there is a bunch of things like that in the code
<danilos> bac, I was thinking of tackling that in the follow-up branch
<bac> danilos: ok, i think that's a good idea
<bac> thanks
<danilos> bac, many of the methods have not even been renamed when mute functionality was introduced, so they sometimes do things related to that as well :/
<bac> danilos: also, to get around the team names clashing with other actions, perhaps we could prefix the team names with something that is not allowed and then strip it when we process the submission
<danilos> bac, yeah, that's an option as well (and we could even prepend the '/~' making them actual API paths that need no processing)
<bac> danilos: +1
<danilos> bac, it's still a separate bug that gary_poster said we should look into later
<bac> danilos: i agree
<bac> i think this branch is fine.  let me add some comments
<danilos> bac, it's a nice idea though!
<danilos> bac, great, thanks
<danilos> bac, thanks again for the review, off to land this
<bac> np danilos.  have a nice weekend
<danilos> cheers
<LPCIBot> Project windmill build #210: STILL FAILING in 1 hr 6 min: https://lpci.wedontsleep.org/job/windmill/210/
<sinzui> bac: do you have time to review https://code.launchpad.net/~sinzui/launchpad/bugtask-create-question-1/+merge/58826 today
<bac> sinzui: of course
<sinzui> thanks
<bac> sinzui: are you in a rush?  mind if i eat lunch first?
<sinzui> thats good. I want to have lunch now too
<bac> cool
<benji> bac: I've been waiting on the diff for https://code.edge.launchpad.net/~benji/launchpad/bug-768336/+merge/58830 to update before asking you to look at it, but it hasn't so...
<sinzui> jcsackett: are you about to mumble?
<benji> bac: the diff's up now
<bac> benji: ok. i've got to do sinzui's branch first
<benji> np
<jcsackett> sinzui: i am available for mumble.
<jcsackett> sinzui: feel free to ping me or just say hello if/when you are available again.
<bac> sinzui: done.
<sinzui> thank you bax
<sinzui> bac
<benji> bax: (noun, plural) one or more bac
<magcius> Using default stacking branch /+branch-id/10062 at lp-81385104:///~jstpierre/loggerhead
<magcius> Created new stacked branch referring to /+branch-id/10062.
<magcius> yay, completely useless information!
<maxb> hmm, that's not entirely optimal
<maxb> on the other hand, yay for stacking that doesn't break when branches get renamed
<magcius> I have no idea what that's supposed to mean.
<magcius> But yeah, branches renaming is dumb too
<magcius> maxb, https://bugs.launchpad.net/bzr/+bug/569361
<_mup_> Bug #569361: Remembering an URL different from the one the user entered is surprising <Bazaar:Confirmed> < https://launchpad.net/bugs/569361 >
<maxb> magcius: as it happens, that bug is actually fixed
<maxb> ish, at least where launchpad is concerned
<magcius> OK
<magcius> What's the standard thing that implements IPerson?
<magcius> I've looked all through the .zcml and .py files
<magcius> I can't find a single implements(IPerson)
<magcius> aha, lp.registry.model.person
<magcius> should have looked harder
<magcius> LocationError: (<lazr.restful.tales.WebLayerAPI object at 0xce6ee10>, 'json')
<jcsackett> magcius: what's the context for that?
<magcius> wow that's a terrible error message for what I did :P
<magcius> I accidentally changed something on Person, and it spit out that
<magcius> I'll try to get a full traceback.
<jcsackett> based on the error, i'm assuming you're working with the API?
<magcius> No, I'm working with the LP code.
<magcius> web code
<magcius> I assume something ate the error.
<jcsackett> magcius: ah, dig.
<magcius> http://paste.pocoo.org/show/376548/
<magcius> It's working now, I assume.
<magcius> I had typo'd the "mugshot" property as "mugsoht" and got a terrible message.
<jcsackett> yeah, you scared zope's traversal, i think.
<magcius> I assume something ate the traversal message, and then the traversal was all fudged up.
<magcius> How do you guys usually dev the server?
<magcius> Do you "make run" and then ^C and run it again when you make changes?
<magcius> ForbiddenAttribute
<magcius> WTF?
<jcsackett> magcius: yes, "make run" and then either ctrl+c or if you're running it in the background "make stop"
<magcius> can I tell zope.security to shut up?
<jcsackett> magcius: ForbiddenAttribute happens when you're accessing something that a) does not exist (e.g. attribute error), b) something that doesn't exist in the associated interface, or c) something you don't have permission.
<magcius> jcsackett, OK, I didn't know if you had some magic to make it restart on code changes.
<magcius> jcsackett, what if I don't have an interface?
<jcsackett> magcius: can you show me the traceback?
<magcius> http://paste.pocoo.org/show/376548/
<magcius> there's a simple diff right there
<magcius> and http://paste.pocoo.org/show/376555/
<magcius> is the traceback
<jcsackett> magcius: this is pulling in a lot of browser behavior into the model.
<magcius> Is there somewhere else I should change it?
<magcius> tales.py perhaps?
<jcsackett> magcius: you might have more luck adding an attribute like "has_gravatar" to the model, and then using that to inform the views that use mugshot that they should render the gravatar stuff instead of pulling a mugshot from the librarian.
<magcius> realistically, I don't want it to be an option, I'd rather that we remove the user-configured setup entirely and switch over to gravatar globally
<magcius> but the flag-inistas are never going to fall for it
<jcsackett> magcius: not everyone has gravatar accounts, nor should we likely require them.
<magcius> there can be a link: change your gravatar by clicking here
<magcius> everybody else has adapted to a gravatar
<jcsackett> which requires people to sign up for a service they may not be interested in.
<jcsackett> i don't think all services use gravatar, magcius. :-)
<jcsackett> i agree that providing users the option of using gravatar would be cool.
<magcius> jcsackett, I don't know any service that doesn't at this point.
<magcius> and if you are one of the three people that hasn't signed up for gravatar, well, i doubt you're going to be inclined to upload a custom image with a widget either
<magcius> so you can be content with /@@/person-mugshot
<magcius> sorry, sorry, i just really hate the "A or B? Option for either!" mantra
<jcsackett> magcius: i understand. frequently, i agree.
<jcsackett> in this instance, i don't. :-)
<magcius> i don't see what the loss is, though
<magcius> is there anybody who would use a different mugshot/logo than they would use for gravatar?
<magcius> jcsackett, OK, what about: gravatar by default, with the default being the librarian image?
<magcius> that way it's a graceful fallback
<jcsackett> magcius: quite probably. mugshots on launchpad are usually actual pictures of the user.
<magcius> if you don't have a gravatar image, you fall back to the librarian
<magcius> So, why does it give me a ForbiddenAttribute here?
<magcius> Technically.
<benji> It makes more sense to have it the other way around: we use your general purpose gravatar image unless you go to the trouble of uploading a launchpad-only image.
<magcius> either way is fine with me
<magcius> I'm just playing around with the Launchpad code for now
<jcsackett> magcius: i think it's probably b/c the mugshot attribute is getting proxied, and there's no interface or security definitions for the gravatar objects.
<jcsackett> but i'm not 100% certain of that.
<magcius> How is it getting proxied?
<jcsackett> mugshot is part of person, persons are enclosed in zope security voodoo.
<magcius> Right, notice that I took the Storm field out and replaced it with a property.
<magcius> But ouch, zope voodo.
<magcius> o.
<magcius> is there some decorator I can add?
<magcius> Eventually, I want to hack up LP bugs so I can go from this: http://i.imgur.com/awyVF.png
<magcius> to this: http://i.imgur.com/2by4O.png
<magcius> (there's also a WIP here: http://i.imgur.com/Y0MiW.png)
<jcsackett> magcius: responding to your question about a decorator. i don't know of one per se, but you can (temporarily) get rid of proxies by using removeSecurityProxy from zope.security.proxy
<jcsackett> you might hack up tales.py where the error is raised for right now to do that, see if what your'e doing is at least on the right path, and then you can hunt down what you have to do to make zope security happy.
* bac changed the topic of #launchpad-dev to: We have a 9s timeout!!! (2 months early!) | https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews
<magcius> ok
<magcius> I have a feeling it's something to do with the mugshot/mugshotID in interfaces/person.py
<jcsackett> magcius: very possibly.
<magcius> Is there someone who knows that code better?
<magcius> OK, I'm still getting that ForbiddenAttribute error
<magcius> http://paste.pocoo.org/show/376624/ is my latest patch
<lifeless> magcius: hi
<lifeless> magcius: uhm, just to let you know, I am strongly against anything like avatars causing per-person lookups inside a webapp
<lifeless> magcius: we show thousands of persons at once on some pages, and the overhead is simply intolerable.
<lifeless> magcius: I can't tell if you need to do that for gravatar or not, but if you do its a problem
<lifeless> magcius: the second thing is that we must not disclose email addresses on anonymous views of pages (and urls with email addresses in them will disclose it)
<lifeless> magcius: finally we have many many users that have selected 'do not show at all' for their email, and the same issue will apply.
<magcius> lifeless, gravatar uses an md5 hash of the email
<lifeless> magcius: the reason you are having trouble is you are replacing DB columns with properties.
<magcius> ForbiddenAttribute: ('getURL', <lp.registry.model.person.GravatarLogo object at 0xb351fd0>)
<magcius> There's nothing forbidden about that!
<lifeless> well, that too
<magcius> I explicitly allowed it in the ZCML!
<lifeless> I can see that
<magcius> http://en.gravatar.com/site/implement/hash/
<magcius> So no, there's no email leakage.
<magcius> Unless you consider MD5 to be too unsafe
<lifeless> its not reversible
<lifeless> so that concern is addressed
<lifeless> there is another
<magcius> Which is?
<magcius> What we're doing is replacing http://launchpadlibrarian.net with http://gravatar.com/
<lifeless> we need to make sure we generate size info so the page can render if gravatar is blocked/down/ or just slow
<magcius> "size info"?
<lifeless> img href width height
<magcius> You request a size from gravatar.
<lifeless> ok
<magcius> In the case of a mugshot, it's 196x196
<magcius> So, I'd send along https://www.gravatar.com/gravatar/md5?s=196
<magcius> if we want to fall back to /@@/person-mugshot
<magcius> you specify 'd'
<lifeless> jcsackett's question around making this optional etc is something I think needs discussion with jml
<magcius> See http://en.gravatar.com/site/implement/images/
<magcius> Sure, I'm just using this as an example of hacking LP's code.
<magcius> And I'm not having much success.
<magcius> I don't expect this to land tomorrow or anything.
<lifeless> I'm not sure why you are getting forbidden attribute there
<magcius> I'm not either.
#launchpad-dev 2011-04-23
<lifeless> except
<lifeless> thats a gravatar logo
<lifeless> not a gravatar source
<magcius> Right.
<magcius> GravatarLogo extends from GravatarSource
<magcius> which implements IGravatarSource
<magcius> Does zope not check the MRO?
<lifeless> try adding both the concrete classes to the zcml
<magcius> Either way, it's a good thing to try.
<magcius> Thanks.
 * magcius is a bit disgusted at how long "make run" takes
<lifeless> ditto :)
<magcius> You don't have a process where it will re-load changed classes with inotify or something?
<lifeless> thats horribly unreliable in python
<magcius> paste does it
<lifeless> particularly when you have class references outside the module
<magcius> but yeah
<magcius> reload() is terrible, I know
<magcius> AttributeError: 'EmailAddress' object has no attribute 'lower'
<magcius> grah
<lifeless> doing it and doing it reliably are entirely different things :)
<magcius> sure
<magcius> but does bin/compiletemplates need to be run every time?
<lifeless> I'm not sure
<magcius> do I really need to start that xmlrpc server?
<lifeless> optimising this is pretty low on the pile
<lifeless> the xmlrpc service is free timewise
<lifeless> its just another listener
<magcius> meh, I'm not sure what's taking up time before the DEBUG OH NOES
<magcius> warning
<magcius> and the HTTP server starting
<lifeless> zcml
<magcius> yay zope
<magcius> you looked into grok?
<lifeless> aware of it
<lifeless> lp's code base priorities are getting performance in shape (which is mainly destroying the assumption that objects are cheap - a deeply held zope assumption); then test performance
<lifeless> the other stuff
<lifeless> win -stable message links +date based sorting - https://bugs.launchpad.net/launchpad/+bug/736012
<_mup_> Bug #736012: Person:+mailinglist-moderate timeout <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/736012 >
<lifeless> [this is a good thing, stable links were asked for a lot]
<LPCIBot> Project windmill build #211: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill/211/
<magcius> gah, gravatar is stupid
<magcius> and they don't have a bug tracker
<magcius> they strip all "@" from the default URL for some stupid reason
<lifeless> heh
<lifeless> personally I don't like gravatar *because* its the same avatar everywhere
<magcius> I like that.
<magcius> Because then I only have to change it *once*.
<lifeless> if you want the same one all over
<lifeless> which I don't
<lifeless> I want close friends to see a photo
<lifeless> colleagues to *perhaps*
<lifeless> folk I game with to see a game related brag
<lifeless> folk in the open source community to see something stylised
<lifeless> and everyone else to not see anything at all
<magcius> there's people not in the open source community?
<lifeless> huge swathes of em :)
<lifeless> google have done some research into the overlap of communities and social networks; it suggests that desires like mine may be very very common
<LPCIBot> Project windmill build #212: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill/212/
<LPCIBot> Project windmill build #213: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill/213/
<LPCIBot> Project windmill build #214: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill/214/
<cr3> is there a way to re-upload a package to my ppa with the same version? I tried deleting my package from the ppa yesterday and uploaded it again today, but I get: " uploaded version has different contents". I'm surprised Launchpad keeps a history of uploaded version of deleted packages for such a long time
<lifeless> its deliberate
<lifeless> perhaps misguided
<lifeless> but apt archive *clients* cannot be assumed to not have the package
<lifeless> and have no invalidate-this-version protocol
#launchpad-dev 2011-04-24
<lifeless> also commitfromnews probably needs an enhancement to deal with the split out bzr NEWS files
<jelmer> lifeless: was that meant for #bzr?
<lifeless> jelmer: yeah, blah :)
<cr3> lifeless: thanks for the explanation. at first, I was thinking that making sure versions were sane should be the responsibility of the people managing the ppa rather than launchpad. however, I can see how for some subtleties it might be useful for launchad to step in and "help"
<wgrant> cr3: It simplifies thigns on Launchpad's end, and hopefully prevents people from doing stupid things.
#launchpad-dev 2012-04-16
<lifeless> wgrant: StevenK: one of you may wish to tag or tag n dup bug 982539
<_mup_> Bug #982539: Losing access to private bugs recently <Launchpad itself:New> < https://launchpad.net/bugs/982539 >
<lifeless> wgrant: I believe 163 TypeError: <DBItem InformationType.PUBLIC, (1) Public> is not JSON serializable is yours ?
<wgrant> lifeless: StevenK's and harmless.
<lifeless> wgrant: its in the report, if its expected it shouldn't, otherwise it should be fixed.
<lifeless> s2n fail otherwise
<lifeless> StevenK: ^
<wgrant> Of course.
<wgrant> But it's harmless so it's not being fixed as utmost priority.
<StevenK> lifeless: Not working today.
<lifeless> kk
<StevenK> lifeless: The bug has been marked as disclosure, so it's on our roadmap. I expect Curtis will get me to fix it after I finish the bug transistion to information type.
<huwshimi> Something is broken with mp comments
<huwshimi> The first time I submitted some comments it updated the page with my comments, but lost them on page refresh
<huwshimi> When I returned and rewrote my comments and submitted it updated the page correctly again, but this time on refresh it had double submitted my comments (I only pressed Save Comment once)
<huwshimi> oh and the text was different between the two submissions so the double paste wasn't just my old text appearing
<huwshimi> oh wait, I'm lying
<huwshimi> ignore me :)
<huwshimi> something weird is going on with caching or something
<huwshimi> I'll get me coat
<czajkowski> aloha
<adeuring> good morning
<rick_h> morning
<mpt> lifeless, hey, remember I told you last week that there was a really obscure difference in behavior between Invalid and Won't Fix, but I couldn't remember what it was? I just found it -- it's described in bug 196500.
<_mup_> Bug #196500: Unexplained that only "Won't Fix" series status makes main bug status changeable <confusing-ui> <docs> <lp-bugs> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/196500 >
<wgrant> mpt: Interesting that even you forget that one!
<mpt> wgrant, you mock me
<gary_poster> jml, do you have any predictions for when your recent testtools MPs will land?  We are working from them for our own changes and relying on them.  Having them merged would be ideal; failing that, having you maintain a fully merged and up-to-date version of those three branches would be nice; failing that we will plan to do it. https://code.launchpad.net/~jml/testtools/tagger/+merge/101904 , https://code.launchpad.ne
<gary_poster> t/~jml/testtools/wrap-result-in-concurrent-suite/+merge/101902 , https://code.launchpad.net/~jml/testtools/tsfr-fixup/+merge/101898
<rick_h> abentley: is there a way to get a nice list of files changed with bzr diff?
<StevenK> rick_h: bzr st
<rick_h> StevenK: ah cool, bzr diff --help only shows --stat-dir
<abentley> rick_h: as StevenK says, you want "bzr stat" for that.  I prefer the --short output, which is also more scriptable.
<abentley> rick_h: Actually, it says "see also: status"
<rick_h> abentley: ah true. but bzr diff --stat --old=... works but isn't in the list
<rick_h> but yea, gotcha
<abentley> rick_h: which list?  the see also list?
<abentley> rick_h: bzr diff --stat does not work for me.
<rick_h> abentley: the Option: in --help
<rick_h> bzr diff --stat --old=../devel just got me some info
<rick_h> looks like a lot more than I changed though so looking at what it's grabbing
<abentley> rick_h: which version of bzr are you using?
<rick_h> abentley: 2.5.0 it looks like
<rick_h> abentley: 2.5.0 it looks like
<abentley> rick_h: bzr status -r ancestor:../launchpad-trunk
<wgrant> bzr st -rsubmit: :)
<rick_h> nice, thanks guys, exactly what I was looking for
<rick_h> time to add an alias
<czajkowski> sinzui: hello :D
<czajkowski> I swear one of these days I won't come looking for you over privacy bugs
<sinzui> hey, IRC really works. I think my ISP is disabling DNS when U1 sync on enabled
<rick_h> sinzui: at the packet level?
<sinzui> not sure
<rick_h> sinzui: or just your isp dns servers don't like to respond to you?
<rick_h> as in just set your own dns to 8.8.8.8 or whatever to get around?
<sinzui> The who house was affected. I yesterday and today was fixed by me disabling u1 on all the computers
<rick_h> strange
<jml> gary_poster: they are blocked on lifeless
<jml> ish
<czajkowski> sinzui: know the feeling when in ireland i disbale U1 sync as it kills my connect :/
<jml> gary_poster: but I can land them tomorrow, I guess.
<czajkowski> roll on when I go back to uk it'll all be up to date again
<sinzui> czajkowski, did you try limiting the upload to 50kb/s
<czajkowski> yup doesnt really help not a great connection but does the job just not for U1 syning without killings things badly
<czajkowski> sinzui: one for you https://bugs.launchpad.net/launchpad/+bug/982539
<_mup_> Bug #982539: Losing access to private bugs recently <Launchpad itself:New> < https://launchpad.net/bugs/982539 >
<sinzui> czajkowski, this must be related to the regression where th proper people are not subscribed
<sinzui> czajkowski, you will need to follow up with the reporter to as an admin to subscribe the bug supervisor to the bugs. I will add this issue to the purple squad's queue
<czajkowski> okie dokie thanks sinzui
<czajkowski> sinzui: next monday I promise no privacy bug issues :)
<sinzui> czajkowski, I am updating the bug to ask if this has happened in the last 8 hours...we released a change to address the previous regression
<sinzui> maybe this bug is aa dupe
<czajkowski> k
<sinzui> czajkowski, oh, I see jcsackett has not landed the fix
<sinzui> jcsackett, what is blocking Bug #967115
<_mup_> Bug #967115: Cannot set a bug private is the bug supervisor is not set <bugs> <disclosure> <privacy> <regression> <Launchpad itself:In Progress by jcsackett> < https://launchpad.net/bugs/967115 >
<jcsackett> sinzui: a host of tests that i missed that i need to read through to update/delete.
<jcsackett> in the process of that now.
<sinzui> thank you.
<czajkowski> sinzui: jcsackett thanks folks
<gary_poster> jml, tomorrow would be great, thanks
<jml> gary_poster: if lifeless reviews the branches during his working day, that would be the ideal for me.
<jml> gary_poster: but I'll land either way
<gary_poster> jml, cool thanks
<cjwatson> jtv: if you have a minute, review of my fix for my screw-up in https://code.launchpad.net/~cjwatson/launchpad/remove-query-distro-pending-suites/+merge/102129 would be great
<jtv> cjwatson: you realize it's close to 23:00 on a public holiday?  :)
<cjwatson> No :-)
<cjwatson> Feel free to say no then ;-)
<cjwatson> I find timezones are a disease I frequently develop immunity to, and so often forget the exact ways in which other people are afflicted.  Doubly so for holidays.
<jtv> Are inoculations available?
<jtv> Anyway, the new code looks to my eye suspiciously like what I suggested, but the old code looks suspiciously like what it said _before_ the branch I reviewed.  What gives?
<cjwatson> http://www.whittard.co.uk/coffee
<jtv> Ah, the distroarchseriesID column on the model class.
<cjwatson> 'distroarchseries_id' => 'distroarchseriesID' was more or less the change from your review to my first merge; then in the second merge, add the missing [] and add the ID to the interface
<cjwatson> http://bazaar.launchpad.net/~cjwatson/launchpad/remove-query-distro-pending-suites/revision/15104 is the difference
<jtv> ahh
<cjwatson> (I couldn't find any documentation of these magic ID attributes, and had to zen it from the surroundings.)
<jtv> Yeah, it's pure cargo cult I'm afraid.
<jtv> Anyway, I've filed my review.
<cjwatson> mkay, thanks
 * cjwatson fixes and goes to land
<cjwatson> (Can I set it to Approved myself once it has an Approve review and I'm ready to land it?)
<cjwatson> Oh, there we go, my logs say I asked about that a few months back
<cjwatson> 2011-12-20.log:14:02 <benji> cjwatson: generally the MP initiator sets it to approved, sometimes they might be getting a DB review too or a UI approval
<cjwatson> 14:07 <cjwatson> benji: ah, and I can't set the MP to Approved because I'm not in ~launchpad
<cjwatson> So could somebody set https://code.launchpad.net/~cjwatson/launchpad/remove-query-distro-pending-suites/+merge/102129 to Approved for me so that I can land it, please?
<jtv> cjwatson: OK, I'll do it
<cjwatson> Thanks - I do have landing access now, but not ~launchpad
<SpamapS> webops ping  Hi I want to make launchpad.net/charms series 'precise' the dev focus now, I need a LOSA to do that. Thanks!
<thedac> SpamapS: so you want /charms/precise set to "Active development" correct?
<SpamapS> thedac: right, I was told this is the process for that: https://wiki.canonical.com/InformationInfrastructure/OSA/LPHowTo/BranchUbuntu
<thedac> SpamapS: ah, ok
<SpamapS> thedac: one thing I'm a little nervous about...
<SpamapS> thedac: it won't overwrite branches that already exist for the target series, will it?
<thedac> SpamapS: I would not think so but that may be a question for another LP dev
<SpamapS> thedac: I'll read the script.. please standby
<thedac> sounds good
<SpamapS>             except BranchExists:
<SpamapS>                 pass
<SpamapS> on the surface, looks good
<olli> hiho
<olli> is it possible to have a private distribution in LP
<SpamapS> thedac: ok, looks good
<SpamapS> thedac: so I think it would be smoething like './branch-distro.py -v charms oneiric precise
<thedac> SpamapS: ok, one moment
<lifeless> olli: not at the moment
<lifeless> olli: you can have private PPAs which may be enough
<thedac> SpamapS: I am getting a connection error: https://pastebin.canonical.com/64350/
<thedac> checking now
<SpamapS> thedac: reading
<thedac> SpamapS: connectivity to the dbs looks good. I am not sure why that is failing
<SpamapS> thedac: haven't seen the error yet, had to go get my phone for 2factor auth ;)
<thedac> ok
<SpamapS> thedac: whoa, does that have to be run on the db master directly?
<SpamapS> oh wait thats pgpool right?
<thedac> port 5432 is postgres 5433 would be pgbouncer
<SpamapS>         connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
<SpamapS> wouldn't that be.. a local server?
<thedac> so it must not be picking up the correct config
<thedac> we probably need an LPCONFIG=... before the command
<thedac> SpamapS: that was it is running now
<SpamapS> thedac: sweeeet
<thedac> SpamapS: completed: https://pastebin.canonical.com/64352/
<SpamapS> thedac: thanks. There must be some other process to make precise the active (not Experimental) series
<thedac> Yes, I can set that in the UI. That was my first question
<SpamapS> is it just that a LP admin needs to change it?
<thedac> SpamapS: ok, the precise series is now active
<SpamapS> perfect
<SpamapS> thedac: so.. some last step is missing. lp:charms/* is still oneiric
<SpamapS> anybody know?
<SpamapS> hm maybe not
<thedac> SpamapS: yeah, I am not sure what needs doing at this point
<SpamapS> thedac: never mind that seems to be good, lp:charms/* is in fact precise now
<thedac> ah, cool
<SpamapS> The only weird thing now is that under "Active series and mielstones" only 11.10 shows
<thedac> SpamapS: I suspect this is a timing problem. Let's give it 15 minutes and check back
<SpamapS> thedac: sounds good :)
<rick_h> deryck: ping
<deryck> rick_h, hey hey
<rick_h> deryck: ok, stuck again, but this should be the last one
<rick_h> deryck: http://paste.mitechie.com/show/620/ chasing down the oauth bits and how they work
<deryck> rick_h, don't worry about it.  looking....
<rick_h> deryck: let me know if it would be easier to hop on a call
<rick_h> basically trying to find when new oauth tokens take flight, and having issues tracing where the person bit comes into play
<rick_h> it *appears* that not until it's been reviewed/ok'd by the user, but that doesn't make sense else how does the user see their list of unapproved tokens
<deryck> rick_h, ok, let me look at this paste and code....
<rick_h> deryck: rgr
<deryck> rick_h, have you seen lib/lp/services/oauth/stories/authorize-token.txt ?
<rick_h> deryck: no was working my way from code -> test
<rick_h> deryck: but this seems nice and step by step'd so will go through it
<rick_h> thanks
<deryck> rick_h, np.  you can also grep zcml for +authorize-token to find the view.
<rick_h> yea, I went from teh view into the model bits
<czajkowski> salgado: ping
<salgado> hi czajkowski
<czajkowski> salgado: are you still working on bllueprints?
<czajkowski> salgado: not sure if you are https://bugs.launchpad.net/launchpad/+bug/983309
<_mup_> Bug #983309: Cannot read blueprints'  titles when the dependecy tree is  large <Launchpad itself:New> < https://launchpad.net/bugs/983309 >
<beuno> czajkowski, u1 has captured salgado and has no plans of releasing him again
<czajkowski> beuno: ello and good evening to you
<salgado> czajkowski, not anymore, no
<czajkowski> salgado: grand job
<salgado> czajkowski, the Linaro infrastructure team is still on the hook for any issues related to work-items in LP, but I don't think this would qualify
<czajkowski> nods
<salgado> czajkowski, however, that bug was filed by someone from Linaro so they might end up fixing it too
<salgado> czajkowski, jamestunnicliffe has taken over the work-items stuff, btw
<czajkowski> salgado: good to know
<mwhudson> i'm pretty sure that bug is a duplicate fwiw
<mwhudson> https://bugs.launchpad.net/launchpad/+bug/576807
<_mup_> Bug #576807: blueprint dependency graph is too small and unreadable <lp-blueprints> <Launchpad itself:Triaged> <NULL Project:Invalid> < https://launchpad.net/bugs/576807 >
<m_3> thedac: hi, I'm working with SpamapS to promote our charms up to precise
<m_3> thedac: we've still got some problems with the branch names after what you/clint did a couple of hours ago
<m_3> thedac: do you have a sec to help with that?
<thedac> m_3: sure
<m_3> so the lp aliases are lp:charms/<charm-name> which now points to lp:~charmers/charms/precise/<charm-name>/precise
<m_3> they should be pointing instead to lp:~charmers/charms/precise/<charm-name>/trunk
<m_3> I can push them to .../trunk and then promulgate which updates the alias to point to the correct branch
<thedac> ok, let me see if I can do anything in the UI
<m_3> however, that results in the alias pointing to .../trunk which is stacked on top of .../precise
<m_3> then it won't let me remove the .../precise branches
<m_3> thedac: I'm not sure what to do with it... I would guess that we could fix the aliases if we just had a mass rename of the aliased branches to .../trunk
<m_3> lp:charms/sbuild is an example of one I tried to fix manually
<thedac> m_3: I am not seeing a way for me to change that. I would guess the update script did this.
<thedac> Anyone else have an idea what we can do? ^^^^
 * m_3 really clueless about that... lp newb
<maxb> It sounds likely that branch-distro would have set things up this way
<maxb> Give me a charm name that hasn't had manual fixing attempts to look at?
<m_3> lp:charms/mongodb
<m_3> it used to point to lp:~charmers/charms/oneiric/mongodb/trunk for the oneiric versions
<m_3> clint ran some branch-distro script and now it points to lp:~charmers/charms/precise/mongodb/precise
<maxb> Right, that'd be branch-distro at work
<m_3> gotcha
<maxb> Does it matter that the branch name is <series-name> rather than "trunk" ?
<m_3> gustavo's charm store looks exclusively for .../trunk branches though
<maxb> ah
<maxb> Well, fixing it all up ought to be fairly easy with a launchpadlib script
<maxb> And you'd need to get a fix into branch-distro for the q-series opening
<m_3> oh, ok...  I'll go read up on launchpadlib.  The manual changes created .../trunk stacked on .../precise which left dangling branches around that I couldn't clean up.  I assumed that launchpadlib would just do the same basic thing
<maxb> m_3: Presumably after you pushed the sbuild/trunk you did something to make it the official branch for precise?
<maxb> Well, you don't want to use launchpadlib to create new branches, you want to use it to rename the existing ones
<m_3> maxb: yes... our promulgate script (have to look to see what it does)... essentially creates the lp:charms/sbuild alias for the branch
<m_3> maxb: ok, looking for rename
 * m_3 and hoping clint returns from lunch soon :)
<m_3> maxb thedac: thanks!
<thedac> m_3: no problem
<maxb> m_3: can you "re-promulgate" the ~charmers/charms/precise/sbuild/precise branch and delete the current .../trunk one?
<m_3> maxb: sure... one sec
<m_3> maxb: done
<m_3> lp:charms/sbuild points to lp:~charmers/charms/precise/sbuild/precise again
<maxb> If you have a "Change branch details" link in the right-hand portlet of https://code.launchpad.net/~charmers/charms/precise/sbuild/precise you can use that to change the name to trunk
<SpamapS> Oh
<SpamapS> there's a rename?!
<maxb> yes :-)
<m_3> maxb: ok, did that... poking around now
<SpamapS> fantastic
<SpamapS> can we map that to launchpadlib calls?
<maxb> Give me 5 minutes, I'll whip up a launchpadlib script to do the rest in bulk
 * SpamapS has just noted that maxb is his hero
<m_3> SpamapS: can you try out sbuild from the store for precise now?
 * m_3 no free envs atm
<m_3> SpamapS: actually, nevermind... that worked!
<SpamapS> m_3: woot
<maxb> Give http://paste.ubuntu.com/933212/ a try .... a little difficult for me to test without a fake Launchpad, but I think it should work
<maxb> it successfully complains about me not having access to edit the charms branches, anyway :-)
<wgrant> SpamapS, m_3: Why do you have the custom naming scheme?
<wgrant> branch-distro is not designed to do that.
<wgrant> Why doesn't juju use the alias?
<m_3> maxb: Yikes... it did a couple, then I got an IntegrityError
<wgrant> m_3: There's probably already one with that name.
<m_3> wgrant: right... excepting that case
<SpamapS> wgrant: I don't know why the custom name is needed
<m_3> wgrant: no idea on the name
<SpamapS> m_3: probably statusnet
<SpamapS> wgrant: Something about using get_branch_tips, which I don't believe shows the aliases
<maxb> m_3: ok, my script is only acting on branches matching ~charmers/charms/precise/*/precise, so just manually resolve the duplication issue for that particular charm, then re-run; it won't go back over ones it has already renamed
<SpamapS> wgrant: also we do actually use the name to specify charms to deploy via the store or not for non-official charms.
<maxb> I agree with wgrant that using the aliases would make far more sense, but this way we can work with the existing hardcoded assumptions for now
<SpamapS> wgrant: so lp:~clint-fewbar/charms/precise/puppet/trunk is a signal to the charm store to pick that charm up, but lp:~clint-fewbar/charms/precise/puppet/in-progress would not be published
<wgrant> wtf
<wgrant> That is, um, intriguing.
<maxb> SpamapS: That seems a bit.... wrong. LP already has a concept of official-ness, which is what drives the aliases. Why not use that, rather than some odd naming convention?
<SpamapS> I would prefer that we use the branch metadata, and only ship 'Mature' branches
<SpamapS> maxb: we want users to be able to say something is official without access to the whole distro
<SpamapS> maxb: its only official in their personal namespace.
<SpamapS> so it becomse cs:~clint-fewbar/precise/puppet
<SpamapS> (cs is the charmstore)
 * maxb has trouble grappling with the idea of "official in a personal namespace"
<SpamapS> maxb: think PPA
<wgrant> I suspect it means "stable"
<wgrant> Which is what Mature means
<SpamapS> its as official as a package pushed to a PPA
<SpamapS> which means, not very :)
<SpamapS> I think we should move it to using the Mature status instead
<m_3> ok, script ran... only a couple of pre-existing branches
<maxb> Surely "trunk" is exactly the wrong name to use to mean "Mature" ? :-)
<SpamapS> and drop the trunk thing altogether
<SpamapS> maxb: depends on whether you are dev or ops ;)
<maxb> I'm devops :-)
<SpamapS> then you ship trunk, after it passes tests
<lifeless> s/trunk/ripe/ perhaps
<m_3> thedac maxb wgrant: thanks!
<maxb> m_3 / SpamapS: Well, I guess you'll figure something out... just remember that branch-distro is going to copy whatever is marked as official to a branch named <whatever-q-series-turns-out-to-be> next cycle
<StevenK> sinzui: http://pastebin.ubuntu.com/933230/
<SpamapS> maxb: I'm opening a bug that we should ship all "Mature" branches, not just those named 'trunk'
<SpamapS> bug #983530 to be exact
<_mup_> Bug #983530: charm store should publish all 'Mature' branches. <juju:New> < https://launchpad.net/bugs/983530 >
<maxb> There appear to still be 5 branches named ~charmers/charms/precise/*/precise, btw
<maxb> Also, branch-distro has its own ideas of how it should manipulate branch lifecycle status, so you'll want to watch out for that
<[reed]> who is an appropriate contact for launchpad's bugzilla integration nowadays?
<sinzui> StevenK, wgrant, wallyworld, jcsackett: http://blog.launchpad.net/general/a-tale-of-two-travesties
<SpamapS> maxb: Right, I noticed they all are set to 'Development', which makes sense.. we really want them to be Mature if the one they copied from was Mature.
<SpamapS> maxb: we might need some alternative behavior flags for our use case... but I bet it takes us a year before we have a patch for LP ;)
<maxb> SpamapS: Fortunately all the code you care about here is localized in one file, eliminating much of the usual scaryness of chasing around the LP codebase
<maxb> lib/lp/codehosting/branchdistro.py ftr
<SpamapS> maxb: its more about the scariness of chasing down our time to get 'er done
<maxb> Aww. It's really just a fairly simple Python script once you learn to look past the "Eek! Launchpad!" factor :-)
<SpamapS> so I think this is a bug in branch-distro
<SpamapS> if I push to lp:charms/somethingnew
<SpamapS> I get lp:~myuser/charms/precise/somethingnew/trunk
<SpamapS> I should reasonably expect that branch-distro would duplicate that behavior, and not call a copy of that by the series name, but 'trunk' again.
<maxb> hm
<maxb> You do rather have a point there, that the two components of Launchpad ought to at least be consistent
<SpamapS> this is causing enormous pain now because the official branches for things like rabbitmq-server were forked, and already existing as lp:~something/charms/precise/foo/trunk
<SpamapS> which were not seen as BranchExisting errors. :-P
<maxb> why is this causing enormous pain? A mild discomfort akin to a stone in your shoe, I would have thought :-)
<wgrant> SpamapS: Ubuntu doesn't use the push-to-alias code, so it doesn't work well for distros.
<wgrant> SpamapS: That's designed for projects.
<wgrant> s/push-to-alias/push-to-new-alias/
<SpamapS> indeed, I think we are breaking new ground.. and have happily found an inconsistency :)
<SpamapS> wgrant: I assume the package importer does the new branch creation manually then.
<wgrant> SpamapS: Right.
<SpamapS> so either push to new alias code should use series name in distros, and we should fix the charm store (seems the low impact way) or branch-distro should have a new option --branch-name to override the default of $series
<StevenK> I do *not* like the idea of hacking branch-distro. It is utterly the wrong place.
<SpamapS> Even better would be that a new flag would be added to the distro object to note that it has charms in it, and change the behavior.
<SpamapS> Because there are other things that look weird in launchpad.net/charms because we're not storing packages there
<SpamapS> like, it would be cool to be able to say +charm instead of +source ..
<SpamapS> and to drop the warnings about a package that has never been published
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/forbid-proprietary-api/+merge/102201 since we're off the call.
<wgrant> SpamapS: I objected pretty strongly to using distros in the first place :)
<wgrant> StevenK: Won't that break like a million tests?
<StevenK> Hm. Maybe a few.
<SpamapS> wgrant: you'd prefer we have each charm as a project? Or a giant single bzr branch of all the charms?
<cjwatson> When I've done QA for r15103 (which will be tomorrow) and everything up to there is deployable, should I remove that deployment exception entry from LaunchpadProductionStatus on the grounds that any future deployment will be >=15103, or is there some other protocol for letting people know that that deployment exception can go away?
<SpamapS> wgrant: we've already used the cross-charm capability to track bugs that affect multiple charms. And each charm in a branch gives us the ability to delegate permissions very effectively.
<wgrant> cjwatson: Leave it there, just in case.
<maxb> Other than the fact we have vast precedent, why does it make sense to use the series name as the branch name for default distro branches?
<wgrant> cjwatson: Although I'll likely be deploying 15103 before you wake up.
<cjwatson> Oh, there's a Comments column
<cjwatson> wgrant: ah, well, if you want to do the obvious QA on it then fine by me
<wgrant> maxb: I like to think that one day we will make project and distribution branch models not gratuitously divergent.
<wgrant> maxb: Probably by removing the distroseries from the URL
<maxb> um?
<wgrant> This would make that easier, although it's probably not the reason.
<wgrant> maxb: The distro branch namespace is divided up by series. Project branch namespaces aren't.
<wgrant> If we ever want to make these consistent, it's possibly handy to keep the branch names fairly unique like that.
<maxb> Oh, I see what you mean now
<jelmer> wgrant: +1
<wgrant> (of course I basically completely disagree with how distro branches work, but it's probably a bit late to make big changes)
<wgrant> But this change is reasonably inoffensive and sensible, so might happen in a few years.
<maxb> It would be the incompatible change from hell, but it has a certain sense to it
<jelmer> wgrant: what's your fundamental problem with them, just that they're so different from project branches?
<SpamapS> for the record, as an ubuntu developer and charm developer, I really like the way distro branches work :)
<SpamapS> though I would prefer to have automatic population of -updates and -proposed for ubuntu so merge proposals for SRU's works properly
<maxb> I'm not sure I'd want -updates and -proposed to pop into existence for every package with identical content to the release pocket, for *every package*
<cjwatson> we sort of want them to autovivify when pushed to.  which is not exactly trivial.
<maxb> On the other hand, if you don't do that, you kind of need the ability to file a merge proposal onto a target branch which doesn't exist yet
<SpamapS> I'd be happy if they were just seen as aliases to the main package, until they were actually published/pushed to
<cjwatson> pushed to> or otherwise referenced as an lvalue
<cjwatson> if I may shamelessly borrow terms
<maxb> It's a good term :-)
<wgrant> jelmer: They make collaboration between distros hard -- in reality they will eventually just be minor branches of the upstream code, but they're all completely segregated and invisible to the upstream project.
<wgrant> jelmer: Most packages would do fine without a separate namespace in the distro.
<wgrant> They could just be specially linked branches in the project.
<jelmer> wgrant: that doesn't seem like a fundamental problem though, mostly a presentation issue
<maxb> The hard split between debian and ubuntu isn't great
<maxb> On the other hand, yes, it's really just a presentation problem
<wgrant> Perhaps.
<jelmer> .. and an issue with the importer, which doesn't take upstream links into account when it generates file ids or ancestry
 * SpamapS wonders if we'll ever get all these worms back in the can
<jelmer> with sensible heuristics, and perhaps some support for handling parallel imports there is a lot we can do
<jelmer> that's a nontrivial amount of work though
<StevenK> wgrant: I think you're right that it will break a few tests. But I'd like it to break for users. :-(
<wgrant> StevenK: Also, that error message is entirely useless.
<wgrant> I can't transition to proprietary because I can't transition to proprietary :(
 * StevenK isn't sure how to check if it's from the API.
<StevenK> In fact, I'm not certain if you can.
<wgrant> You can't directly.
<StevenK> Hm, can't think of a way to solve this then. That's disappointing.
<wgrant> You could add a from_api argument or something
<timrc> lol @ <wgrant> But this change is reasonably inoffensive and sensible, so might happen in a few years.
<StevenK> wgrant: Or I could fix it differently and allow it only if the pillar has private_bugs.
<jelmer> timrc: you've not met wgrant before?
<wgrant> StevenK: But that's wrong.
<jelmer> timrc: :P
<StevenK> wgrant: I thought that was the plan?
<timrc> jelmer, No, I hope he takes his comedy act on the road though :) jk
<wgrant> StevenK: "plan" being the important word here
<wgrant> StevenK: Future.
<StevenK> Keeping in the mind the plan is somewhat elastic. :-)
<wgrant> The plan is fairly well defined in only slightly conflicting ways in the minds of sinzui and myself.;
#launchpad-dev 2012-04-17
<lifeless> fjlacoste: oh hai
<lifeless> fjlacoste: if you want to catch up in the evening or whatever, just let me know
<fjlacoste> lifeless: i think i'll pass today, sorry
<lifeless> fjlacoste: is cool
<lifeless> fjlacoste: hows the conf ?
<fjlacoste> lifeless: pretty good
<StevenK> wgrant: Can haz another look?
<wgrant> StevenK: Done
 * StevenK looks for "This is terrible."
<StevenK> OMG, referencing a bug that *isn't* bug 933766.
<_mup_> Bug #933766: Update bug to use information_visibility_policy <bad-commit-14986> <bugs> <disclosure> <qa-untestable> <Launchpad itself:In Progress by stevenk> < https://launchpad.net/bugs/933766 >
 * wallyworld stabs thunderbird. using 3GB of memory and thrashing disk trying to get up to date with qastaging inbox. still waiting.....
<StevenK> wallyworld: Using Thunderbird to read the staging inbox? Ha. Hahaha. HAHAHAHAHAHA
<wallyworld> yeah, i know now it is a bad idea :-(
<rick_h> lifeless: ping, if you have a sec can you peek at the MP for the email notice stuff. I've got two failing tests to fix, but shouldn't change much. https://code.launchpad.net/~rharding/launchpad/email_notice_959482
<StevenK> wallyworld: Seriously, though, turn off the agressive caching, since Thunderbird loves to cache the entire message.
<rick_h> lifeless: the gpg and oauth adjustments are in a follow up branch I'm still working on getting
<wallyworld> StevenK: is there a better alternative like pine or something worth considering?
<StevenK> Hahaha, pine.
<rick_h> offlineimap + mutt ftw!
<StevenK> Is your knowledge of MUAs like 10 years old?
<wallyworld> never used those but perhaps i need to
<rick_h> I'm a big mutt user
<cjwatson> mutt's generally fine for large mailboxes but do enable its header cache.
<rick_h> yea, definitely
<rick_h> http://blog.mitechie.com/2011/11/20/an-updated-email-config-2-offlineimap-mutt-and-dovecot-ftw/
<cjwatson> Exactly my combination
<StevenK> wallyworld: I think the staging inbox howto thingy shows how to configure offlineimap
 * StevenK tends to be evil, and just uses wgrant to look at the staging inbox for him ...
<wallyworld> StevenK: yes, i think it does. i never figured it would be mandatory to use it :-)
<rick_h> my license plate is 'cli4lif' :)
<wallyworld> funny
<StevenK> wallyworld: It depends if you have 48GiB of RAM available and 3 days to wait? :-P
<wallyworld> StevenK: i only have 4GB :-(
<StevenK> And a crappy i7 Atom that randomly reboots.
<StevenK> But that's what you get for buying a laptop based on the fact that it has a numeric keypad. :-P
<wallyworld> it hasn't done that the past couple of days, touch wood
<wallyworld> i bought it because it has a decent screen resolution
<wallyworld> 1600x900
<StevenK> wallyworld: My X201 is 1280x800, but I spend my time working on a 24" 1080p LCD.
<wallyworld> StevenK: my main monitor is a 23" display but i also like to have a decent laptop screen too
<StevenK> Oh bugger, I put off voting in the DPL elections so long they elected zach without me.
<wgrant> StevenK: That's Disclosure Supreme, Flawless, and Marvellous Plan to you.
<StevenK> Haha
<StevenK> Tempted to raise that on the call tomorrow. :-)
 * StevenK stabs Banshee four or five times.
<StevenK> I plug my mp3 player in, start Banshee, it spews 200 lines or so of Mono garbage tracebacks and then segfaults.
<spm> "feature"
<StevenK> And the Banshee devs complained when we switched the default away?
<StevenK> There is a reason I use Quod Libet as my music player.
<spm> exaile here. used to be a die hard amorak fanboi, but around a year or 3 ago they made me cry. so I gave up.
<StevenK> I gave up on amorak when it caused my (at the time) dual Athlon to melt into a puddle.
<spm> i think it was the crashing everytime I asked it to do something complex like "play this tune" that was the main kicker for me
<StevenK> Haha
<spm> much like how my previous smartphone would lock dead requiring a hard reset with complex tasks like receiving an SMS
 * wgrant just uses Rhythmbox :)
<StevenK> Rhythmbox started acting very strange for me last release so I went back to the loving Python embrace of Quod Libet.
<spm> is that the current default? if Y, I'm sure I tried it, and gave up on it rather quickly
<wgrant> I used Banshee while it was the default, since Rhythmbox was indeed pretty broken.
<StevenK> I remember trying Exaile for a day (I think it was 0.22) and giving up in disgust, but I can't recall why.
<lifeless> StevenK: just think, your vote would not have changed anything
<wgrant> But switched back in early Precise.
<StevenK> lifeless: Meh, thank you for making me feel SO much better.
<spm> heh
<lifeless> StevenK: I failed to vote too
 * StevenK goes to buy lunch and probably drown.
 * wgrant stabs GIST in the face
<StevenK> wgrant: Oh?
<wgrant> Everything goes fine on dogfood until I try to FTI
<StevenK> I didn't drown, but it was a close run thing. Apparently, Sydney is going to get 140mm of rain over the next two days.
<wgrant> Heh
<wgrant> Ahaaa
<wgrant> Once the index is hot, fti is fast
<wgrant> StevenK: You probably have insane team memberships
<wgrant> StevenK: How do https://bugs.dogfood.launchpad.net/ubuntu/+bugs?field.searchtext=kernel and https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=kernel compare for you?
<lifeless> (Error ID: OOPS-71f5806d495ce2928a38ecae3e91b757)
<lifeless> and
<lifeless>     At least 47 queries/external actions issued in 2.00 seconds
<wgrant> Erm
<wgrant> 2s?
<wgrant> Should be at least 6
<wgrant> Oh, that's a prod oops
<lifeless> 2s on dogfood
<wgrant> Right, that makes more sense.
<wgrant> So, success? :)
<wgrant> (this early version of the feature flag has prejoining disabled, so there's a bit of death by a thousand queries still in play, so it will really be faster)
<lifeless> wgrant: nice
<StevenK> wgrant: I was lunching, do you still want me to check?
<wgrant> StevenK: More data is always nice.
<wgrant> Even though the data so far suggests that the Disclosure Supreme, Flawless, and Marvellous Plan lives up to its title.
<StevenK> wgrant: Hah, so. Timeout on prod, and 29second on DF
<wgrant> StevenK: What if you retry?
<wgrant> The fti and most of the table had probably dropped out of DF's cache
<wgrant> Given they're like 2GB all up, and DF has 4GB...
<StevenK> wgrant: 9.01 seconds on prod and 2.76 seconds on DF.
<wgrant> That's more like it.
<StevenK> I thought 9.01 should have timed out.
<wgrant> It must have ticked over 9 right after the timeout check.
<wgrant> StevenK: What are the timings for the two BugTaskFlat queries?
<wgrant> in the DF query log
<StevenK> Sigh, mawson is all the way over there.
<wgrant> No
 * StevenK reaches for it.
<wgrant> Click link at top of page
<wgrant> "XX queries/external actions"
<wgrant> it's a link
<wgrant> expands query log
<lifeless> only if you're logged in and in the lp dev group there
<StevenK> 509ms and 1202ms.
<wgrant> Which StevenK is
<wgrant> Huh
<wgrant> Slow
<wgrant> k
<StevenK> lifeless: Pft, I'm a duck on DF.
<wgrant> Burn!
<StevenK> Burn which bit?
<wgrant> You
<wgrant> You're a witch :)
<StevenK> Really?
<StevenK> wgrant: Looks like my team memberships and such are a bit more insane than lifeless'?
<wgrant> Or lifeless may not have been logged in
<wgrant> Although
<wgrant> Yours should be faster...
<lifeless> I wasn't logged in
<wgrant> since you're a duck
<wgrant> It will ship all the perm checks
<wgrant> skip
<wgrant> Sigh
<wgrant> need more ram
<wgrant> My desktop has 4x more than mawson :(
<lifeless> hah, sso puts a spurious : after the fields in the what-fields-you-get confirmation form
<wgrant> Yeah
<wgrant> Has for ages
<wgrant>  /ever
<StevenK> wgrant: But your desktop was manufactured sometime this century. :-)
<lifeless> wgrant: 143 queries/external actions issued in 11.12 seconds
<lifeless> AJAX Log â
<wgrant> Yeah, DF doesn't do so well with a cold cache
<lifeless> 1895ms 	
<lifeless> SQL-main-slave: SELECT * FROM ((SELECT Person.account
<wgrant> I've just been browsing Launchpad's bugs, so Ubuntu will be long gone
<wgrant> Heh
<wgrant> So that's just listing your team administerships
<lifeless> 2248ms 	
<StevenK> I think mawson's disks have begun to fossilize
<lifeless> SQL-main-slave: SELECT BugTaskFlat.bugtask FROM
<wgrant> :(
<lifeless> 4991ms 	
<lifeless> SQL-main-slave: SELECT COUNT(*) FROM BugTaskFlat
<lifeless> 143 queries/external actions issued in 5.14 seconds
<lifeless> AJAX Log â
<wgrant> I guess I should fix the last few tests failures and get this onto qas.
<lifeless> lots of SQL-main-slave: SELECT TeamParticipation.id, TeamParticipation.person, TeamParticipation.team FROM TeamParticipation WHERE TeamParticipation.person = 2980965 AND TeamParticipation.team = 430914
<lifeless> 1606ms 	
<lifeless> SQL-main-slave: SELECT BugTaskFlat.bugtask
<wgrant> Yeah, those aren't even my fault :/
<lifeless> 1764ms 	
<lifeless> SQL-main-slave: SELECT COUNT(*) FROM BugTaskFlat WHERE BugTaskFlat
<lifeless> 60ms 	
<lifeless> SQL-main-slave: WITH teams AS (SELECT team from TeamParticipation WHERE person=2)SELECT combinedbugsummary.distroseries
<lifeless>  :)
<wgrant> lifeless: I think those TP checks might be subscriptions
<wgrant> Deciding whether you're subscribed or not
<wgrant> Pretty hilarious way to go about it, which is why it's completely plausible.
<lifeless> why would that page care ?
<wgrant> lifeless: It has the new bug subscriptions stuff on it.
<wgrant> Anything touched by that is cursed forever.
<wgrant> To be 500ms slower than it would otherwise be.
<StevenK> wallyworld: Can haz QA for r15100?
<wallyworld> StevenK: still waiting for my qas inbox to finish syncing
 * StevenK grumbles about having to feature flag the UI changes.
 * wallyworld grumbles about yui tests in lxc core dumping :-(
<wgrant> wallyworld: You've enabled X forwarding in SSH?
<wgrant> Down to 92000 messages in the staging inbox...
<wgrant> Nearly there
<wallyworld> wgrant: i don't use ssh with the lxc setup is use, i just sudo lxc-start -n lpdev and get a login prompt directly
<wgrant> wallyworld: Ah, that would do it.
<wgrant> wallyworld: No X server
<wgrant> wallyworld: Perhaps try xvfb-run
<wallyworld> ah right. will do thanks.
<wgrant> wallyworld: Did you make any progress on QAing poolie's size limit?
<wallyworld> wgrant: *still* waiting for fucking qas inbox to download everything
<wgrant> wallyworld: I just deleted 430000 mails from it
<wgrant> You might want to restart thunderbird
<wgrant> It's got like 4000 now.
<wallyworld> already have. i can delete about 50000 at once. it's been swapping all day :-(
<wgrant> I did 100000 at a time. Just had to click Continue about 100 times.
<wgrant> Make sure you disable the message pane when doing bulk operations.
<wgrant> Otherwise it will try to render a list of threads.
<wallyworld> that would help
<wallyworld> i've lost count of the number of "script has stopped" dialogs i've clicked on
<wallyworld> plus when the disk thrashes, the desktop stops accepting mouse clicks :-( not sure whether to blame unity or X or compiz
<wgrant> Sounds like you're swapping heavily :)
<wgrant> Need moar rams
<wallyworld> yeah. normally get by fine with what i have
<wgrant> 4GiB?
<wallyworld> yep
<wallyworld> wgrant: i see you sent a large email to qas.
<wallyworld> my qas inbox finally cuaght up
<StevenK> It only took all day.
<StevenK> Is your laptop still thrashing?
<wallyworld> yeah :-(
<wallyworld> no
<wallyworld> just finished
<wallyworld> after 1000000 thunderbird restarts and clicking on Continue dialogs
<StevenK> Maybe you'll use offlineimap next time. :-P
<lifeless> I've just purged it
<lifeless> 42K messages, 0 need for them
<wallyworld> StevenK: well, i didn't think i needed to :-)
<lifeless> you don't
<lifeless> if folk delete as they qa
<wallyworld> too bad we don't clear qas inbox more often
<StevenK> lifeless: You tell funny jokes.
<lifeless> StevenK: apparently so
<wallyworld> why don't we automatically purge once every couple of days?
<wgrant> lifeless: Did you just delete *everything*?
<StevenK> lifeless: Suprised you didn't make a ruling in terms of non-LP members doing QA.
<wgrant> I'd already deleted most of them.
<lifeless> noone has gotten theactivation energy up to do it
<wgrant> And I think you nuked my test mail :(
<wallyworld> wgrant: i read it, looked ok
<lifeless> wgrant: there were 42K messages there, I wasn't selective
<wgrant> wallyworld: Ah, thanks.
<wallyworld> wgrant: i marked the bug as qaok
<wgrant> lifeless: I usually leave everything from the last 24 hours
<wgrant> wallyworld: Even better.
<wgrant> wallyworld: I get "NotFound: Object: None, name: u'index.html'"
<wgrant> wallyworld: Nothing about a default view
<wallyworld> wgrant: i was going by the string handed to the exception constructor in the base class. but anyway, it still refers to index.html which implies a page is expected
<wgrant> wallyworld: That's correct.
<wgrant> When browsing to an object in a browser, it will try to render the default view.
<wgrant> The default view is index.html unless overriden.
<wgrant> This is normal.
<wgrant> Eg https://launchpad.net/package-sets
<wgrant> Same for any object that doesn't have views
<wallyworld> in this case i don't think it is because i see it as a case on an incomplete url
<wallyworld> like lp/net/launchpa
<wallyworld> typo
<wallyworld> . not /
<wgrant> Structurally it is a complete URL.
<wgrant> Overriding as you've done is of minimal utility and breaks the convention around the rest of the codebase and every other ZTK app.
<wallyworld> oh alright. not worth arguing about. i'll change it
<wgrant> To a user the difference is 0
<wgrant> They don't see the traceback.
<wgrant> Hah
<wgrant> I'm going to accidentally fix the bug where milestones are duplicated on the advanced search page.
<wgrant> How convenient.
<lifeless> oh noes
<lifeless> we can't have less bugs
<lifeless> bugs are currency
<StevenK> You would say that.
<lifeless> YHBT HAND HTH
<bigjools>  
<bigjools> bwaha
<czajkowski> I need a dictionary for lifeless
<bigjools> it's funny because that's what StevenK trots out
<lifeless> czajkowski: urban dict probably has them all
<lifeless> czajkowski: or perhaps the new new hackers dict
<czajkowski> lifeless: would you mind haveing a look at juju bug against lp please. https://bugs.launchpad.net/launchpad/+bug/983530
<_mup_> Bug #983530: "charms" needs branch name consistency <juju:Invalid> <Launchpad itself:New> < https://launchpad.net/bugs/983530 >
<czajkowski> lifeless: a swift google was helpful
<lifeless> SpamapS: hey ^
<czajkowski> my brain doesnt seem to want to fucntion at this hour of the morning
<lifeless> SpamapS: what is the problem ?
<wgrant> lifeless: See backscroll
<adeuring> good morning
<wgrant> From about 8 hours ago
<SpamapS> lifeless: in charms, we often use 'bzr push lp:charms/foo' to create new charms.
<SpamapS> lifeless: this creates lp:~yourname/charms/series/foo/trunk
<SpamapS> lifeless: however, when branch-distro is run to copy forward and do the stacking jitterbug, it uses lp:~yourname/charms/series/foo/series
<SpamapS> lifeless: the charm store code specifically targets 'trunk' because we need users to be able to have a way to say "this is my personal published version of foo"
<lifeless> wait, what ?
<SpamapS> lifeless: so we can't really use branch metadata becaus we can't have two foo's for any one user
<SpamapS> or rather we can't have two foo's for any one user+series
<lifeless> how does that impact the blessed charms ?
<SpamapS> lifeless: the charmstore maps lp:~auser/charms/precise/foo/trunk to 'juju deploy cs:~auser/precise/foo'
<SpamapS> lifeless: the blessed charms do have a 1:1 series<->charmname mapping, so I did suggest that we should just use that to workaround this. But it stands to reason that branch-distro should probably agree with push-to-create
<lifeless> SpamapS: are they able to say cs:~auser/precise/foo/trunk, if they want to ?
<SpamapS> lifeless: no
<SpamapS> lifeless: though I believe that is desired
<SpamapS> its not part of the store *now*
<lifeless> so for users, this is irrelevant, because its only the blessed charms that are branched
<SpamapS> right
<lifeless> the blessed charms should be listed as the development focus branch, in LP's package metadata
<lifeless> so they shouldn't be affected either
<lifeless> unless the charm store isn't using that pointer (which it should)
<SpamapS> it is to map lp:charms/foo -> cs:foo
<SpamapS> (which is the default, so 'juju deploy foo'
<SpamapS> lifeless: the troubling part is the inconsistency
<SpamapS> lifeless: I know we can mold the charm store loader to just load the dev focus branches as blessed regardless of their name. but they'll still have weird names
<SpamapS> lifeless: also when copying forward, one thing that happened was any charms that were manually ported forward to precise were named 'trunk', and so were not detected as already existing.
<wallyworld> wgrant: can haz +1 on that review?
<wgrant> wallyworld: Ah, sure. Was just waiting for the diff to update, then forgot.
<wallyworld> wgrant: np. thanks. i am trying to make the next bb run :-)
<StevenK> cjwatson: It matters little, but spot the duplication in your most recent landing:
<StevenK> 120	+ distro = bpph.distroseries.distribution
<StevenK> 121	+ script = self.makeScript(bpph.distroseries.distribution)
<cjwatson> StevenK: reasonable point; I was copying from test_getDirtySuites_returns_suite_with_pending_publication and test_getDirtySuites_ignores_suites_without_pending_publications and didn't notice
<cjwatson> doesn't seem worth another landing to fix though, really?
<lifeless> SpamapS: ok, so I think that the bug may need some fine tunuing ;)
<lifeless> gnight
<StevenK> cjwatson: Nah. Like I said, it matters very little. If you care, you can do a drive-by in your next branch. Or you don't care, either is fine.
<StevenK> czajkowski: :-(
<czajkowski> StevenK: now what have I done.
<StevenK> czajkowski: Your G+ reply, you bad person.
<czajkowski> StevenK: hi we've clearly never met if you're only realising that now :)
<czajkowski> I blame the blessed charms for todays corruption!
<StevenK> Hah
<StevenK> Which makes it SpamapS fault.
<StevenK> And the universe makes sense again.
<dpm> hi all, could someone help me with an issue with translations? We've got the calligra source package in Ubuntu and its translations do not seem to get imported. Here are the details:
<dpm> The imports queue is empty save for some manual uploads:
<dpm> https://translations.launchpad.net/ubuntu/precise/+source/calligra/+imports
<dpm> The po files were uploaded separately with the calligra-l10n package:
<dpm> https://translations.launchpad.net/ubuntu/precise/+source/calligra-l10n/+imports
<dpm> It's a KDE translation, which makes it a bit special and means the PO files will not be imported into any calligra-l10n template, but rather on the corresponding template in the calligra source packad
<dpm> *package
<dpm> So my question is whether someone could help me determine whether the PO files will end up in the right package or whether I should start to worry
<dpm> I know there is a check somewhere in the LP code to determine if an upload corresponds to a KDE package and then takes care of all this, but I'm not familiar with the code other than knowing that this function exists
<dpm> I just want to ensure the calligra translations end up in the right place and can be shipped in the language packs
<adeuring> abentley: standup?
<rick_h> dpm: hmmm, so there are imports on that l10n going back to Jan it looks like, 4k of them?
<rick_h> jtv: ping, I'm told you might be a translations master and know something about how this works?
<dpm> rick_h, yeah (not sure about the translations part, though :). Back then the calligra package did not have any templates, so the translations were uploaded but had nowhere to go, as PO files only get imported if there is a corresponding template. Last week the templates were created and a new upload was made, which should in theory solve the issue. The way LP works, the 4k old translations will remain there, I believe, as there is no template associate
<dpm> d with them.
<rick_h> dpm: ok, so there were some imports done after the 4/11 imports that didn't have a template?
<dpm> rick_h, the templates were created last week (on the 10th or 12th, I think). All of the uploaded PO files before that date will remain in Needs Review (forever, I believe), whereas the PO files uploaded after should in theory get associated with a template and should be imported. And the "should get imported" part is what I'm trying to figure out :)
<rick_h> dpm: ok, I've ping'd jtv, I'm not sure atm how the imports work like this and asking in our stand up didn't get me much further. Let's see if he gets back to us and if not I'll try to find more help/guidance.
<dpm> rick_h, ok, thanks for your help. jtv is on his day off, I think
<gary_poster> jml, are you still hoping to merge your three testtools branches today?  We're already making our own rollup branch, but we'd still love to have an official merge, let alone an official release.
<gary_poster> We'll need to do similar dances for testrepository (we have one MP with no reply, with another on its way) and subunit (we need a release of the trunk in order to get some tag support changes that Robert added recently).
<jml> gary_poster: yes. about to do so now.
<jml> gary_poster: sorry about the muck-around
<gary_poster> awesome thanks jml.
<jml> gary_poster: I'm going to apply lifeless's suggestion from the yellow testr review
<jml> gary_poster: and parametrize wrap_result
<gary_poster> cool jml, thanks
<gary_poster> benji ^^
<jml> gary_poster: that will cause a conflict for you when you merge, but hopefully nothing too tough
<jml> fwiw, my excuse is that I moved house yesterday (taking the day off) and still don't have home internet today.
<gary_poster> jml, ugh!  moving house is never easy, and sometimes difficult for months or years later. :-) thank you very much for getting this through
<jml> having fast Internet changes *everything*
<gary_poster> :-)
<jml> gary_poster, benji: tagger, tsfr-fixup and wrap-result-in-concurrent-suite all merged & pushed (lp:testtools r253). Let me know if there are problems.
<gary_poster> thank you very much jml
<jtv> rick_h: sorry, I'm not doing any more work tonight!
<salgado> jamestunnicliffe, you'll need to ask one of the LP tech leads to approve a feature flag change to enable the view to members of Linaro
<salgado> the feature flag will be something like "team:linaro registry.upcoming_work_view.enabled 1" (need to check the correct syntax/order)
<sinzui> jcsackett, how goes the bug subscriber branch?
<salgado> sinzui, maybe you can approve that feature flag (^) change?
<jcsackett> sinzui: i spent some time reading through the whole of the various subscription code last night, so i've been able to iron out those inconsistencies and am making progress.
<jcsackett> there are some tests regarding the DB triggers i haven't gotten to looking at yet--there's a very good chance i'll be pinging you when i hit those. i expect they're going to be complicated.
<sinzui> salgado, sure, is the entry on the osa page?
<salgado> sinzui, not yet. should I add it?
<jcsackett> sinzui: would've pinged you earlier, but i was excited once i had things sorted out and just sort lost myself in fixing things.
<sinzui> jcsackett, okay, please ping me to talk if you are getting frustrated. I can listen and sympathise, and sometimes help fix
<jcsackett> sinzui: will do, and thanks. :-)
<sinzui> salgado, add it the the ff section on https://wiki.canonical.com/InformationInfrastructure/OSA/LaunchpadProductionStatus
<sinzui> you can add me as the approver now since I agree that linaro needs to see the feature work
<salgado> jamestunnicliffe, so, that (^) is what needs to be done, but the wiki page is internal-only so the next time you need to do it you'll just need to ask whoever approves the feature flag to add it to the wiki page as well
<salgado> thanks sinzui!
<jamestunnicliffe> thanks salgado!
<jamestunnicliffe> (and sinzui)
<czajkowski> sinzui: oh wise one, should a bugs description be editabled after a fix released so in theory it's closed be allowed to happen ?
<jml> bac: hi
<jml> bac: I've had a bit of a look at https://code.launchpad.net/~bac/testrepository/bug-949950/+merge/102317. Do you want to discuss it here, or would you rather a put some notes on the MP?
<bac> hi jml
<bac> jml: here is fine, as long as it is summarized on the MP
<sinzui> czajkowski, yes it should be editable so that confusing text is removed
<jml> bac: can do.
<jml> bac: I downloaded it and gave it a try. It looks like you'll only get test failures and start & end timestamps in the subunit stream.
<bac> jml: oh, really
<jml> bac: yeah
<bac> that isn't great
<jml> bac: I didn't think it was what you wanted.
<bac> jml: any thoughts on why that happens?
<jml> bac: it's not very obvious, but 'run' delegates to 'load'
<jml> bac: and 'load' uses the make_result() that your patch changes
<jml> to make something called 'output_result', which is the result responsible for UI output (which makes sense, I hope)
<bac> yes
<jml> immediately below that, is this:
<jml>         filtered = TestResultFilter(output_result, filter_skip=False)
<jml> and it's that 'filtered' result that gets used from then on
<jml> so output_result never even gets the events for successful tests
<jml> (sorry for dragging this out, I'm figuring it out as I go along)
<bac> jml, np
<jml> I think the right thing to do is to push that TestResultFilter call down into the UI make_result
<jml> because, really, choosing which results to display is a UI decision.
<bac> jml: makes sense
<jml> bac: there'll probably be a bunch of annoying test fallout from that.
<jml> bac: sorry.
<bac> jml: and you're suggesting not applying the filter when we select --subunit?
<jml> bac: uhh, yes, I think so.
<jml> umm sort of
<jml> bac: there's a part of me that thinks there should be another option that controls whether only failures are shown vs full results
<jml> bac: and that the default should stay as is regardless of whether the output is the pretty text output or a subunit stream.
<czajkowski> sinzui: even after the bug has been fixed released?  surely editing the description then is confusing
<bac> jml: so grow a '--full-results' (modulo spelling).  would that be only for the run command?
<czajkowski> sinzui: an example is https://bugs.launchpad.net/launchpad/+bug/272826  which was edited today
<_mup_> Bug #272826: "Ubuntero" inappropriate for female contributors <lp-registry> <Launchpad itself:Fix Released by barry> <Ubuntu Website:Fix Released by newz> <Ubuntu:Fix Released by communitycouncil> < https://launchpad.net/bugs/272826 >
<jml> bac: run & load yes.
<bac> jml: ok.  so if you'll disapprove that MP i'll look at doing that this afternoon
<jml> bac: the other point of my feedback was going to be that load should have the option too. I think that's pretty trivial to code up.
<jml> bac: will do that, and put my notes there now.
<bac> jml: cool, thanks
<jml> bac: thank you!
<sinzui> czajkowski, it is not a bug. Bug descriptions often need to be updated to distinguish past behaviours from modern ones, or provide proper urls, tests, or work arounds so that users do not report a new bug or reopen the existing one
<czajkowski> sinzui: I suppose if it were called a bug summary it wouldb't be as bad, I guess calling it a descrption is just rather misleading in this case.
<sinzui> czajkowski, that is different issue. The bug title is not a title either
<czajkowski> indeed
<maxb> Is there any known breakage with package copies at the moment? I'm trying to copy reusing binaries from natty to oneiric within a single PPA, and I'm getting a spurious binary conflict
<czajkowski> maxb: there was lp servers rebooted there at 16:00 UTC
<czajkowski> for about 10 mins
<maxb> I'm getting a specific logic error, rather than a downtime-related issue
<rick_h> abentley: ping do you have time for a quick review? https://code.launchpad.net/~rharding/launchpad/email_notice_extras_959482/+merge/102341
<rick_h> abentley: some drive by linting at the top makes it look bigger than it is
<jml> Can someone please land https://code.launchpad.net/~jml/launchpad/expose-commercial-on-create-ppa/+merge/101907
<rick_h> jml: sure thing, will pull that down
<jml> rick_h: thank you
<rick_h> jml: onto ec2 ok
<jml> rick_h: \o/
<abentley> rick_h: Sorry, was lunching.
<rick_h> abentley: np, no hury
<abentley> rick_h: LOC rationale?
<rick_h> abentley: sorry, it's been ok'd in the dep branch by lifeless as small hit to fix security issue
<abentley> rick_h: r=me
<rick_h> abentley: ty
<sinzui> jcsackett, r=me
<jcsackett> sinzui: thanks.
<dobey> can i beg someone to make a +downlaod page work for each series, and not have only the generic one for a project?
<sinzui> dobey, We don't have any requirements for what +download should do anymore. It is truly fucked. I will not make anymore changes until someone provides the use case for it. It was once about packagers...and it certainly is not now
<sinzui> dobey, Why does a series need +downloads?
<dobey> sinzui: for packagers :)
<sinzui> dobey, shouldn't the series page show the current release tarball then?
<sinzui> does it need to show anything more?
<dobey> i suppose it could just be on the series page if uscan can handle that
<sinzui> ah
<dobey> http://launchpad.net/ubuntuone-storage-protocol/+download .*/ubuntuone-storage-protocol-([0-9.]+)\.tar\.gz
<dobey> that's what is in debian/watch for example
<sinzui> I already reported a bug specifically for that situation, but some how it became unimporant and I stopped trying to please everyone
<dobey> but it wants to grab 3.0.0 which is for precise, even though i'm doing an SRU for oneiric, for example :)
<sinzui> https://bugs.launchpad.net/launchpad/+bug/231797
<_mup_> Bug #231797: no sensible way to use debian/watch files with launchpad hosted tarballs (no simple url-and-link list of all downloads) <lp-registry> <packaging> <releases> <Launchpad itself:Triaged> <devscripts (Ubuntu):Invalid> < https://launchpad.net/bugs/231797 >
<dobey> being able to specify the series would be brilliant, but there's no way to do that right now
<dobey> you can specify a link to a specific milestone, which isn't the same
<sinzui> I think we just want a permalink that is obvious from the url structure to support it. It is only for debian/watch case, so no one can screw it up again
<dobey> or can i use the series page perhaps?
<dobey> i guess i should try that
<sinzui> dobey, https://launchpad.net/gdp/0.5.x shows the current release
<sinzui> eg a real url with a tarball in it
<dobey> right
<sinzui> but I personally would not trust it since it is not designed for uscan
<dobey> and +download is?
<dobey> it has the exact same links on it, but it's paginated and has everything ever released
<sinzui> +downloads is a semi0orderd list of all releases from all series. It is not clear who needs it since obsolete series are listed and it seams to encourage end-users to download and compile lots of tarballs
<sinzui> The pagination was added to support some odd case were someone want to get old data, possibly because someone uploaded a .exe
<sinzui> Once end-users were using that page and it was paginated to do fuck-knows-what, the people who needed it most were cut out. The whole mess it the result of a handful of well-meaning developers adding features without really verifying why if they accomplished something meaningful
<lifeless> wouldn't it be nice if we could test for that
<sinzui> dobey, do not trust anything in a "downloads" portlet it shows the latest uploaded thing, not the tarball, and not the actual version...again, there is not clear use-case for it. I think the intent was to encourage end-users to learn how gcc works
<lifeless> sinzui: how are things; is there anything you want to catch up on - its been a few weeks since we last spoke
<dobey> sinzui: well it it shows the latest uploaded thing for the series. i presume i can halfway trust it if i control what gets uploaded and when :)
<sinzui> lifeless, we are not facing any technical issues, we are just struggling to to step on each other to get the UI ready for beta
<dobey> sinzui: so probably safe enough to use for packages for projects i maintain? or should we get some more reasonable thing set up like a +download page for series?
<sinzui> dobey, you can trust it if you trust the maintain who uploads. The portlet is correct for my work because I really do want packagers to the right thing..but I have the advantage oh having read the code and bug reports. I am still bitter as you can tell
<dobey> heh
<sinzui> I propose something special and testible for bots so that it is clear the feature is not to address someone's feelings...bot just need the correct data and nothing more
<dobey> sure. sounds good
<lifeless> sinzui: ok cool
<lifeless> wgrant: you were asking about job clearing on restores...
<lifeless> wgrant: I suspect we don't, systematically - [STAGING] Cron <launchpad@gandwana> $LP_PY /srv/staging.launchpad.net/staging/launchpad/cronscripts/process-job-source.py IPlainPackageCopyJobSource -q --log-file=INFO:/srv/staging.launchpad.net/staging-logs/process-job-source.IPlainPackageCopyJobSource.log
<lifeless> 2012-04-17 20:39:30 ERROR   Unhandled exception
<lifeless>  -> http://staging.launchpadlibrarian.net/99588237/gYMKrWK5lzGeNC4Db0iVcuSdQWW.txt (ERROR:  No such user
<lifeless> )
<wgrant> lifeless: Was I?
<lifeless> wgrant: s/asking/speculating/ yesterday
<[reed]> hey, I'm not sure where exactly I should be filing this... https://bugs.launchpad.net/launchpad/+bug/984415
<_mup_> Bug #984415: Launchpad bugzilla integration causes Bugzilla-side warnings <Launchpad itself:New> < https://launchpad.net/bugs/984415 >
<[reed]> is that the right place?
<lifeless> thats fine yes.
<lifeless> whats happening ?
<[reed]> lifeless: getting errors on Bugzilla's side every 10 min. when launchpad hits it :)
<[reed]> trying to track down what's causing them
* StevenK changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: StevenK | Firefighting: - | Critical bugtasks: 4*10^2
<wgrant> rick_h: Did you get a text review of your new email template this time? Also, "security_field_changed" isn't a valid method name.
<wgrant> There are also various text issues in the notification strings in the code.
<lifeless> wgrant: whats invalida bout it ?
<lifeless> wgrant: being pep8?
<wgrant> lifeless: Yes
<wgrant> That bit of PEP 8 illegal in Launchpad.
<wgrant> +is
<lifeless> ahh well, life is too short
<lifeless> I wrote that method
#launchpad-dev 2012-04-18
<wgrant> à² _à² 
<wgrant> Yay
<wgrant> BugTaskFlat now passes all bug search tests./
<lifeless> sweet
<wgrant> 3000 lines of refactoring later
<wgrant> StevenK: Good evening.
<wgrant> Some of <https://code.launchpad.net/~wgrant/launchpad/bugtaskflat-search--1/+merge/102416>, <https://code.launchpad.net/~wgrant/launchpad/bugtaskflat-search-0/+merge/102417>, <https://code.launchpad.net/~wgrant/launchpad/bugtaskflat-search-1/+merge/102419>, <https://code.launchpad.net/~wgrant/launchpad/bugtaskflat-search-2/+merge/102421> may be of interest
<jtv> huwshimi: g'day!  Had you seen this bug?  https://bugs.launchpad.net/maas/+bug/965058
<_mup_> Bug #965058: Long error throws add-node form off balance <ui> <MAAS:Triaged> < https://launchpad.net/bugs/965058 >
<StevenK> wgrant: -1 and 0 approved
<wgrant> StevenK: I wouldn't go so far as to say "good".
<wgrant> "not terrible", perhaps
<wgrant> It's all preeeetty ugly
<StevenK> But *fast* :-)
<wgrant> And temporary :)
<lifeless> ?
<huwshimi> jtv: I think that bug is invalid as we no longer use an overlay.
<huwshimi> (Unless I'm missing something.)
<jtv> huwshimi: maybe I got the terminology wrong.
<jtv> I _thought_ it was an overlay but whatever it is, it didn't stretch well.
<jtv> I need to go afk for a bit.
<wgrant> lifeless: Around?
 * StevenK stabs Zope form handling.
<bigjools> it's already dead, that won't help
<wgrant> lifeless: In 7675.1045.191 you declared that Bug.id and BugTask.bugID are unambiguous sort columns, when that's clearly false.
<wgrant> Do you recall why you did that?
<StevenK> bigjools: The stabbing is merely therapeutic.
<wgrant> Therapeutic stabbing? That's a new one.
<StevenK> Therapeutic for *me*.
<bigjools> Dexter Kowalik
<nigelb> "Stabbing a dead Zope"
<StevenK> wgrant: http://pastebin.ubuntu.com/934982/ since I'm obviously missing something.
<bigjools> oh yay now my adsl is syncing at 2mb
<bigjools> *stab*
<wgrant> StevenK: What's not working?
<StevenK> wgrant: I get an OOPS:
<StevenK>     return self.__FormFields_byname__[name]
<StevenK> KeyError: 'information_type'<br />
<lifeless> wgrant: hi
<StevenK> bigjools: I'm not so sure I want to watch Dexter.
<lifeless> wgrant: that was contextual - I had to bend my head to get it
<lifeless> wgrant: in a single context, bug.id is unambiguous, otherwise it isn't
<wgrant> lifeless: Right, but there was already an 'if unambiguous_context: add(Bug.id)' block afterwards
<wgrant> So I'm confused
 * StevenK revokes his 1024D key.
<wgrant> StevenK: Bah, nasty lifeless distracted me by answering my question.
<lifeless> wgrant: I have no idea
<wgrant> StevenK: What's the traceback? is it the custom widget declaration?
<wgrant> lifeless: It'll affect index use, so I'll just remove it for BugTaskFlat.
<lifeless> fbm
<lifeless> we'll see what happens
<wgrant> Yeah
<wgrant> Also
<StevenK> wgrant: http://pastebin.ubuntu.com/934992/ is the traceback, and I've +1'd 1.
<wgrant> What does everyone think about the assignee-visiblity thing?
<lifeless> doowop
<lifeless> wgrant: what about it ?
<wgrant> That is, currently there's a special case where the assignee can see a bug even if they don't have a subscription.
<wgrant> Seems like that should go away.
<StevenK> wgrant: I've reviewed -1, 0 and 1. I'd prefer you find another review for 2.
<lifeless> they should get a grant; we should forcibly unassign if the grant is removed.
<wgrant> StevenK: Sure, thanks.
<wgrant> Meh, until we do that they just don't get access when BugTaskFlat is in use :)
<wgrant> StevenK: Um
<StevenK> wgrant: Hm?
<wgrant> StevenK: Is that a conditional in the root of a class?
<wgrant> That's slightly unconventional.
<wgrant> However, I suspect the error is because the schema's field names end in _field, but field_names' do not.
<StevenK> wgrant: But it works with the flag off for private and security_related.
<StevenK> wgrant: So I'm confused too.
<StevenK> Right, simple test written for it.
<StevenK> Bah, Vim needs M-x comment-region
<lifeless> StevenK: ^V,select,:s/^/#
<StevenK> wgrant: Changing class schema just have information_type_field = copy_field() makes the new test pass (and all of the current tests blow up :_)
<wgrant> StevenK: That's not surprising.
<wgrant> The class isn't defined in the function as I initially thought.
<wgrant> It's a conditional in a class in a class.
<wgrant> So the feature flag is evaluated at module load time.
<StevenK> Oh, right.
<StevenK> So I can't use schema?
<wgrant> I'd define two
<StevenK> How do I tell the form the right schema?
<wgrant> @property
<wgrant> def schema(self):
<wgrant>    return foo if getFeatureFlag('blah') else bar
<wgrant> or similar
 * StevenK stabs FreeNode.
<wgrant> freenode
<huwshimi> jtv: If you get a chance can you try and reproduce that bug and if so attach a screenshot to the bug?
<jtv> Sure
<StevenK> wgrant: It works when I define two classes in the schema property
<wgrant> Or if you define them outside it :)
<StevenK> If I define them outside it, I get NameError
<wgrant> Then fix the NameError.
<jtv> huwshimi: ahh, I see now: the form extends to the right-hand edge of the page already.  So the bug couldn't occur in the form I reported.
<jtv> (But why does it let me create two nodes with the same hostname?)
<StevenK> wallyworld: I've moved two of your cards from Deployment-Ready to Done-Done due to the NDT, can you check the other two cards?
<StevenK> wgrant: http://pastebin.ubuntu.com/935014/
<wgrant> StevenK: self
<StevenK> Oh, doh, of course.
<huwshimi> jtv: I think I remember there being a bug for that.
<jtv> Maybe it's normally an error coming from the backend.  I was running against a fake pserv.
<StevenK> wgrant: Last step is to add in the vocab, which requires defeating AssertionError: The vocabulary must implement IEnumeratedType
<StevenK> wgrant: And adding implements(IEnumeratedType) hasn't helped
<jtv> [wild unsolicited guess] classProvides?
<StevenK> It's strange. If I use vocabulary='InformationTypeVocabulary' or vocabulary=InformationTypeVocabulary() I get the AssertionError. If I use vocabulary=InformationTypeVocabulary I get a TypeError in the guts of itemwidget.
<wallyworld> StevenK: ok
<StevenK> And none of classProvides, implements or alsoProvides changes the AssertionError. :-(
<adeuring> good morning
* StevenK changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2
<wgrant> Hm
<wgrant> Test failures
<nigelb> Isn't there something tricky about bug status?
<nigelb> It's not exactly attached to a bug, is it?
<nigelb> aha. bug_task.
<rick_h> is the smtp server running on qa staging?
<wgrant> rick_h: qastaging and staging outbound email is captured in the staging mailbox.
<rick_h> wgrant: ok, thanks. will look for that on the wiki.
<wgrant> https://wiki.canonical.com/InformationInfrastructure/OSA/LPHowTo/ConnectToStagingMailbox
<rick_h> ty
<wgrant> jcsackett: Hi, around yet?
<wgrant> I guess not, rich_h is just strange :)
<rick_h> yea, I tend to start early for most US based people I think
<czajkowski> rick_h: you really do
<rick_h> I like it that way, start early, hit the road early.
<rick_h> time with the boy and all that jazz :)
<rick_h> meanwhile...my thunderbird hate grows...
<bac> jml: when you have time can you look at this updated MP for testrepository?  i've included your suggestions from yesterday.  https://code.launchpad.net/~bac/testrepository/bug-949950-2/+merge/102383
<jml> bac: soon
<jml> bac: sorry for the delay
<bac> jml; np, it wasn't ready until late my afternoon y'day
<StevenK> Is it sad when I saw "y'day", I immeadiately thought it was something like "y'all" ?
<jml> bac: I've got to head to a call now, but I've looked at your patch, like it and am trying to figure out something better than checking the return type
<deryck> Morning, everyone.
 * deryck lives!
<rick_h> woot!
<rick_h> blame the kids deryck, it's what I do.
<deryck> oh, it was absolutely the little one's fault. :)
<rick_h> jml: ping, looks like landing failed
<jml> rick_h: in what fashion?
<rick_h> jml: tests passed, but the commit was rejected, this bug it's tied to is listed as fix released on teh 14th
<rick_h> so guessing it had no [bug=] and it wasn't set [no-qa]
<jml> ah ok.
<rick_h> http://paste.mitechie.com/show/624/ for the full output
<rick_h> so do we need to mark the bug as open again? Is that the right bug?
<rick_h> and I can pqm submit it under that?
<jml> rick_h: yes it's the right bug
<rick_h> ok, so going to open back up as triaged and then pqm submit, it'll go through qa/etc again then
<jml> rick_h: that sounds like a good idea
<wgrant> jcsackett: Hi
<rick_h> jml, ok, pqm seems satisfied now.
<jml> rick_h: yay
<jml> crap
<czajkowski> jml: thats never good to see after silence, you just know things aren't going well
<jml> czajkowski: just realized I'd forgot about bac's branch
<czajkowski> :/
<czajkowski> hmm wgrant is it possible to change the registered by in a team ?
<sinzui> czajkowski, NO. The SQL uses to tamper with the database causes issues later.
<sinzui> I would sooner remove the registered information from projects then tamper with it
<adeuring> abentley: fancy a review? https://code.launchpad.net/~adeuring/launchpad/celery-config/+merge/102535
* abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: abentley | Firefighting: - | Critical bugtasks: 4*10^2
<abentley> adeuring: sure.
<adeuring> thanks
<rick_h> deryck: ping for call
<abentley> adeuring: I think we want the timeout to be 5 minutes.  That's what it's currently set to, and it will ensure that ~99% of tasks run in the fast lane.
<adeuring> abentley: yeah, I suspected that I got the timeout values wrong ;) So, 300 seconds for the fast lanes.
<adeuring> abentley: I am also not 100% conviced that a timeout of one day for slow jobs is reasonable...
<abentley> adeuring: Somewhere between an hour and a day seems reasonable.  I think we'll need to experiment.
<adeuring> right
<abentley> adeuring: It's generally a bad idea to assume that sys.argv is defined.  It won't be when Python is loaded as an extension.
<abentley> adeuring: I've been bitten by that in Launchpad work before.
<adeuring> abentley: ok, we can avoid this -- but is this a real concern here, in a test?
<adeuring> abentley: gahhh
<abentley> adeuring: You are doing it in lib/lp/services/job/celeryconfig.py which is not a test.
<adeuring> ups, right
<abentley> adeuring: Can you access Celery's interpretation of the config instead?  Or is that applied after loading celeryconfig?
<abentley> adeuring: I mean  Can you access Celery's interpretation of the *arguments*
<adeuring> abentley: no, the celery config is not yet available when this module is loaded. this is the reason why I used sys.argv
<abentley> adeuring: That is a shame, but if you must use sys.argv, you need to handle the case where it's not defined.
<adeuring> abentley: ok, I'll do this
<abentley> adeuring: Is there value in defining the binding key explicitly when it's the same as the queue name?
<adeuring> abentley: not really. But I wanted to explicitly defined the set of known queues (for sanity checks), and having the binding key available might make sense if we want a more complex rabbitmq setup (but I am not sure if we will ever have such a setup :)
<adeuring> abentley: diff so far: http://paste.ubuntu.com/935579/
<abentley> adeuring: I have difficulty anticipating what facilities we would want if we made it more complex, so let's keep it simple for now.
<adeuring> abentley: ok, so, something like [job_queues] queues: job, jobslow,... ?
<abentley> adeuring: Right.
<abentley> adeuring: I think set() is the natural type for linked_queues, since we only care about whether a queue is already present in it.
<adeuring> abentley: I think a list has the avdantage that you can see where the circle "closes".
<abentley> adeuring: okay.
<adeuring> abentley:  current diff: http://paste.ubuntu.com/935587/
<abentley> adeuring: I think it would be nicer if configure accepted "argv" and returned a dict.  Then you could do "globals().update(configure(getattr(sys, 'argv', [''])))" to actually set it.
<abentley> adeuring: That would make it easier to test, and also shorter.
<abentley> adeuring: You could even pull the function into a different module so that testing didn't have to actually set the globals.
<adeuring> abentley: well, ok...
<abentley> adeuring: check_job_specific_celeryd_configutartion is misspelled.
<adeuring> fixed
<jml> gary_poster: have just merged bac's branch into testr. you guys should be good to go.
<bac> jml: sweet
<jml> bac: oh cool, you're here :)
<abentley> adeuring: Could you give ConfigurationError a docstring?  That will remove the need for the "pass".
<gary_poster> jml, thank you!  Is there a place where subunit is in a PPA somewhere?  We need revno 158 and I *think* that's not officially released yet; double checking.  But ISTR that there is a PPA for this stuff...?
<adeuring> done
<jml> gary_poster: https://launchpad.net/~testing-cabal
<gary_poster> jml, ah-ha, I thought it was something like that. :-) thanks again
<jml> gary_poster: if it's not up to date, probably best to hassle jelmer
<gary_poster> ok
<jml> gary_poster: if it's not up to date, probably best to hassle jelmer
<bac> jml: your test additions are quite an improvement.  thanks.
<jml> one piece of software thatI use has a bug where sometimes the middle part of my screen gets covered by a a white block :(
<gary_poster> me too!  I suspect chrome
<gary_poster> jelmer, IWBNI the testing cabal had the newest subunit in its PPA.  No biggie though; I'll make one myself for ours.
<jelmer> gary_poster: requested a new build
<gary_poster> thank you very much jelmer
<adeuring> abentley: another look?
<gary_poster> subunit builds fail becuse of test failures :-/
<rick_h> 553343
<jelmer> gary_poster: testing cabal PPA build seems to have succeeded
<jelmer> (including tests)
<abentley> adeuring: sure.
<abentley> adeuring: Is the tearDown still necessary?
<adeuring> abentley: argh, sure, that method can go....
<rick_h> lifeless: ping when you get in, trying to figure out how to get the oops tools LP talking nice. oops-tools seems fine, but LP isn't dumping messages on the queue and wonderingif I'm missing a step of setup on the LP side.
<czajkowski> rick_h: would matsubara be able to help
<rick_h> czajkowski: well I guess anyone that knows how LP dumps oops to the rabbit queue would be cool
<rick_h> just know lifeless has the keys so lighting up his IRC :)
<rick_h> lifeless: czajkowski ok, got it hacked to just use my main rabbitmq instance and got oopses processed so in business I think
<gary_poster> jml, if you are around, https://launchpadlibrarian.net/102495365/buildlog_ubuntu-precise-i386.python-testtools_0.9.14%2Bbzr253~ppa37~precise1_FAILEDTOBUILD.txt.gz shows that testtools is not building because py3 does not support destructuring in args ("def _merge_tags(existing, (new_tags, gone_tags))").  Fix is easy, of course (http://pastebin.ubuntu.com/935815/ for instance, if it speeds things along).  However, ht
<gary_poster> tp://pastebin.ubuntu.com/935822/ suggests that the build will still fail--and I don't see a python3.2-bzrlib.  I think I'm going to pursue making a branch locally that does not try to support py 3.
<lifeless> rick_h: hi
<rick_h> lifeless: hey
<lifeless> rick_h: the oopssetup doc on the wiki covers this
<rick_h> sorry, I was referencing the readme since that seeme dto have all the setup
<rick_h> lifeless: so yea, I went through these, but the issue I was running into was that the LP rabbit instance isn't what my rabbit is running at. e.g. default 5672 port vs 56720
<rick_h> lifeless: so I had to tweak the rabbit-server stuff to use the existing running rabbitmq instance.
<rick_h> lifeless: I think this is because of the install issues I had around the rabbit mgt package stuff in precise
<rick_h> lifeless: so I got things running, but basically by telling LP not to start up rabbit, but use the one already running from the system.
<lifeless> make run starts a local rabbit
<rick_h> the oops-tools stuff went peachy
<lifeless> so my notes (referenced from that wiki page) link oops-tools to that rabbit
<lifeless> 6/1 1/2 of the other
<rick_h> lifeless: right, I want to look at it better because I couldn't tell how to have things like rabbitctl point to a second rabbit instance
<rick_h> part of the issue in debugging was trying to figure out if the queu exist/was getting populated and rabbitctl list-queues showed nothing because that was talking to the rabbit on 5672
<rick_h> I don't see it accepting a --port parameter, so I didn't realize LP was firing off a second one, etc
<lifeless> rabbitctl is influence by environment variables
<rick_h> ah
<lifeless> it talks to a erlang multiplexer
<lifeless> which talks to potentially multiple rabbits
<lifeless> its fugly.
<lifeless> but there it is
<rick_h> gotcha, and I fell down that 'rabbit-hole' and yea I went there
<rick_h> :)
<lifeless> here - starting point : https://dev.launchpad.net/QA/OopsToolsSetup
<lifeless> links to my notes https://lists.launchpad.net/launchpad-dev/msg08183.html
<rick_h> got those, thanks!
<sinzui> jcsackett, lets qa bug 982539 to verify your branch also fixed it
<_mup_> Bug #982539: Losing access to private bugs recently <bugs> <disclosure> <privacy> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/982539 >
<benji> lifeless: if you have a minute today I would appreciate your comments on https://code.launchpad.net/~benji/testrepository/add-worker-id-tagging/+merge/102574
<lifeless> benji: I'll give it a shot
<lifeless> I've a bit of review debt again
<benji> thanks
* abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2
<deryck> night, everyone.
<sinzui> jcsackett, mumble?
<wgrant> sinzui, jcsackett: lib/lp/bugs/stories/bug-privacy/xx-bug-privacy.txt and lib/lp/bugs/doc/initial-bug-contacts.txt fail intermittently with jcsackett's rev
<sinzui> StevenK, is this the branch: lp:~stevenk/launchpad/bugs-information_type-ui-secrecy
<StevenK> sinzui: That is the first one, yes.
#launchpad-dev 2012-04-19
<sinzui> StevenK, I am tempted to write a an enum class that is feature flag aware, but I see your vocab is pretty complicated...have you explored removing the only two asserts in our code? i do not see why the vocabs have to be enums
<sinzui> StevenK, I do not see why LaunchpadRadioWidgetWithDescription need to be IEnumeratedType, maybe we can make an exception for the special voab
<sinzui> vocab
<sinzui> EnumChoiceWidget's might also get an exception to the rule because it passes to vocabulary_to_choice_edit_items which  can take extra functions to render the items.
<StevenK> sinzui: And here I was thinking the vocab was simple-ish
<StevenK> sinzui: I hadn't thought about changing itemwidget, TBH.
<sinzui> I am thinking with it. I still do not see what it needs...it is not calling any of the four attrs that IEnumeratedType define :(
<StevenK> sinzui: I'm currently knee-deep in tests for the next pipe, are you trying, or do you want me to dump state and look with you?
<sinzui> I am playing with it. Don't loose focus
<StevenK> wgrant: Can you join #ubuntu-arm on freenode?
<StevenK> wgrant: Unping
<wgrant> StevenK: I was there already, just noticed slightly too late :)
<StevenK> No ubuntu/member for me :-/
<wgrant> Odd
 * StevenK stabs official_malone
 * StevenK tries to work out how to get the bug that was just filed from the +filebug view
<StevenK> (In a test, so I have a initialized view)
<wgrant> StevenK: It should have returned a redirect to it
<StevenK> Oh, I have to call the view
<StevenK> wgrant: It does indeed.
<sinzui> StevenK, Here is your fix in as few lines as possible: http://pastebin.ubuntu.com/936319/
<sinzui> StevenK, There were three things that needed consideration: 1. Enums are classes that act like instances...they do not need to be instantiated. 2. vocabularies are either instantiated by you, or you register a factory in zcml to do it for you. 3. The test was passing what the user sees, not what the browser posts, so the form always has errors that were not checked
 * sinzui tends to children
<StevenK> sinzui: Thanks, that's awesome
<StevenK> wgrant: Have you seen anything like http://pastebin.ubuntu.com/936341/ ?
<wgrant> StevenK: data is None
<wgrant> StevenK, wallyworld: https://code.launchpad.net/~wgrant/launchpad/bugtaskflat-search-3/+merge/102615
<StevenK> wgrant: Yeah, looks like zope does not love it when initial_values returns None
 * wallyworld looking
<wgrant> wallyworld: Thanks.
<wgrant> StevenK: Yeah, should probably return {}
<StevenK> wallyworld: Thanks, I'm trying to polish off this branch before lunch.
<wallyworld> np
<wallyworld> wgrant: 'BugTaskFlat.information_type IN (1, 2)' - can we use enum.value here instead
<wallyworld> wgrant: also, i'm not sure we should turn on the ff if assignees cannot see their bugs. is it intended this will be fixed before we turn this on?
<wgrant> wallyworld: It's probably a misfeature that has been deliberately used about twice ever.
<wgrant> I don't consider it to be a significant concern. It's not documented anywhere.
<wgrant> wallyworld: And yes, I meant to fix that enum thing but forgot.
 * wgrant fixes.
<wallyworld> wgrant: i think assignees should be able to see all the bugs assigned to them. what am i missing?
<wgrant> wallyworld: Documentation and history says that you can tell who has access to a bug by looking at the subscriber list.
<wallyworld> what do we indent to do when someone assigns a user to a bug but that user cannot see it?
<wgrant> Same as we did until 6 months ago.
<wgrant> They can't see it.
<wgrant> Until we make these rules consistent, so assignment requires a grant.
<wallyworld> that sucks
<wgrant> Rather than what it does now: exist as a horrible undocumented special case that kills performance
<wallyworld> we should automatically create a grant then
<wgrant> Yes.
<wgrant> That's the intention.
<lifeless> wallyworld: we should have visibility and assignment matched
<wgrant> But it's going to be far far easier to do that once we've made bug visibility not insane.
<lifeless> wallyworld: however, its better, I think, to special case assignment (force unassigns) than to special case visibility
<wallyworld> sure. my concern was reverting the existing behaviour ie taking something away that's now there
<wgrant> It's existing undocumented inconsistent behaviour.
<wgrant> That isn't fully implemented.
<lifeless> wgrant: you may find http://vimeo.com/2723800 interesting
<wallyworld> but there could be people who are working on bugs that all of a sudden they can't see
<lifeless> their supervisors can fix that
<wgrant> There's going to be a bit of that at various points throughout the migration.
<wgrant> It's unfortunate, but I'm not sure it's worth working around it.
<wgrant> We can check how many cases there are.
<wgrant> My guess is "not many at all"
<wgrant> And most of the cases that do exist will be unintentional leaks/
<wallyworld> hmmm. alright. my objections have been raised. we'll see what happens
<wallyworld> i wouldn't have said anything if the behaviour wasn't there and we weren't removing it all of a sudden
<wgrant> This behaviour has an interesting history.
<wgrant> For several months it was partially implemented.
<wgrant> You could see the bugs in listings.
<wgrant> But the bug page would OOPS
<wgrant> We had a total of two bugs filed about that.
<wallyworld> sure, but now it's fixed and people may rely on it
<wgrant> Then for a while the bug page would render, but had no tasks.
<wgrant> We had one bug about that.
<lifeless> wgrant: you could add grants for all current non-accessible asasignees
<wgrant> Then a few months ago it was fixed properly and we didn't tell anyone.
<wgrant> lifeless: I could, but that makes the temporary mirroring triggers slower and more complicated.
<lifeless> wgrant: nono
<lifeless> wgrant: so, a) make assigning add a grant if the person doesn't already have access
<lifeless> b) do a one-off check and add
<lifeless> c) profit
<wgrant> That's the final solution.
<wgrant> Could add a *subscription* now.
<wgrant> But can't add a grant directly.
<lifeless> what stops it being used now ?
<lifeless> isn't the schema live?
<wgrant> It is.
<wgrant> But the mirror triggers own all grants related to bugs.
<lifeless> so what stops that solution being used now ?
<wgrant> Every time the bug is touched, they will force the mirrored data into compliance.
<wgrant> ie. delete the manual assignee grants
<lifeless> ah
<lifeless> kk
<wgrant> (bugtaskflat's triggers are permanent, so they're a bit more selective. but the legacy mirroring stuff is not)
<wgrant> erm
<wgrant> https://lpstats.canonical.com/graphs/PPR/
<lifeless> yay registry
<wgrant> :)
<wgrant> Hmm
<wgrant> I might delete 2/3 of the bug search tests, I think
<wgrant> Or 7/8, even
<mwhudson> lifeless: the main lesson from that zed shaw talk is "i'm very glad i work for canonical"
<wgrant> Yep
<mwhudson> much as the main lesson from "release it" is "i'm glad i don't program in java"
<nigelb> mwhudson: where was this talk? Video or in person?
<mwhudson> nigelb: video, lifeless posted a link
<lifeless> mwhudson: hah
<mwhudson> <lifeless> wgrant: you may find http://vimeo.com/2723800 interesting
<lifeless> mwhudson: release spends -maybe- 10% on java disfunction
<lifeless> mwhudson: as for that talk, the discussion on addressing acls was why I linked it
<mwhudson> lifeless: yeah, but all the case studies were "this external service fell over and our thread pool ran out of threads and everything gummed up"
<mwhudson> or at least, enough of them were that it made quite an impression
<mwhudson> re: acls, yes, i realize
<lifeless> mwhudson: applies to non-java, applies to non-java
<nigelb> mwhudson: thanks :)
<mwhudson> lifeless: sure, to a large extent
<lifeless> mwhudson: e.g. blog.launchpad.net failing, and the concurrency limit we hit in one of the twisted services a while back
<nigelb> bah. 1 hour talk. My connection is being throtled this week :/
<mwhudson> nigelb: it's not /amazingly/ interesting, i'd say
<lifeless> moderately entertaining
<lifeless> about a 1/2 page on how to do scalable things that look a bit like ACLs
<lifeless> which has some relevance to the work purple are doing
<nigelb> Interesting. I'll queue it up for next week when I'm slated to do some boring stuff.
<spm> o/ nigelb
<lifeless> nigelb: moved yet ?
<nigelb> Evening spm o/
<nigelb> lifeless: Nope. Just send in all the documents to the consultant.
<nigelb> Another 8 to 12 weeks at least :(
<nigelb> lifeless: I hear you'll be keynoting at kiwipycon? :)
<StevenK> Sigh. That vimeo video isn't available for download.
<mwhudson> nigelb: where are you (trying to?) moving to?
<nigelb> mwhudson: Near you! (sory of) Auckland.
<nigelb> *sort of
<lifeless> nigelb: yes, I should get onto my talk
<mwhudson> ah heh
<mwhudson> nigelb: nice :)
<nigelb> :)
<nigelb> lifeless: \o/ Hopefully, I can make it :)
<StevenK> wgrant: I'm getting a failure in xx-bug-privacy.txt with - Mark Shuttleworth (Unsubscribe), is that related to jcsackett's change?
<wgrant> StevenK: Yes
<wgrant> StevenK: That rev is reverted now
<StevenK> wgrant: Excellent.
<StevenK> Hmmm, the feature flags don't seem to impact the vocab :-(
 * StevenK blames the class-inside-another-class definition
<wgrant> StevenK: When is the flag evaluated?
<StevenK> wgrant: In __init__ of the vocab
<wgrant> That's where
<wgrant> When is the vocab instantiated?
<StevenK> wgrant: In the class information_type_schema in BugSecrecyEditView
<wgrant> Is the class defined directly inside BugSecrecyEditView, not in a method?
<StevenK> wgrant: Yes
<wgrant> Remember that the class body is executed immediately.
<StevenK> I had inside the schema method, and you said it could be outside.
 * StevenK moves it back
<wgrant> Not if you're evaluating the flag in the class definition.
<wgrant> My statement yesterday relied on the flag being used to select a class.
<StevenK> It's okay, I wrote a test for it.
<StevenK> wgrant: I'm more comfortable about the vocab use that I have a test for all 3 feature flags.
<StevenK> wgrant, wallyworld: https://code.launchpad.net/~stevenk/launchpad/bugs-information_type-ui-secrecy/+merge/102624
<StevenK> Finally!
<StevenK> What the hell? I've managed to create 3 MPs?
<StevenK> This button down thing is idiotic
 * wallyworld looks
<StevenK> wallyworld: Thanks.
<wallyworld> StevenK: self.assertIn('Private', html) etc - i think that's too generic. can we use BeautifulSoup and search for a tag with content
<StevenK> wallyworld: Sure, with the slight problem that I think BeautifulSoup is terrible. :-)
<wgrant> It can't be terrible!
<wallyworld> it's all we have though
<wgrant> We only have 4 copies of it.
<StevenK> Where are the 4?
<wgrant> lib/, we used to have an egg (possibly not any more), the system one, and one in mechanize.
<StevenK> Why it is in lib? :-(
<wgrant> Because someone is strange.
<StevenK> I'm tempted to remove it in a different branch, toss it at ec2 and see what happens.
<StevenK> wallyworld: Do you have any other comments while I work out HTF to use BeautifulSoup?
<wallyworld> StevenK: no, looks pretty good. the only other nitpicky thing is i would define a string constant for the ff names but i was going to ignore that
<StevenK> wallyworld: I'm hoping the flags are short lived.
<wallyworld> yeah, me too :-)
<wallyworld> so don't do anything
<wgrant> Anyone up for reducing some test coverage? :)
<StevenK> ... and doing what?
<StevenK> wallyworld: Does you approve? http://pastebin.ubuntu.com/936472/
 * wallyworld looks
<wallyworld> StevenK: i think you should be able to use find() and compare to None or a single object rather than a list
<StevenK> wallyworld: http://pastebin.ubuntu.com/936477/
<wallyworld> StevenK: looks ok, thanks for doing the change
<wgrant> https://code.launchpad.net/~wgrant/launchpad/trim-bugtask-search-tests/+merge/102628 is a pretty simple one if someone has a sec
<StevenK> At +180/-161 ?
<wgrant> Mostly moved tests
<wgrant> The real diff is about 40 lines
<wgrant> Everything else is just splitting one base class into two.
<wgrant> With no code changes.
<StevenK> wgrant: r=me
<wgrant> Thanks.
<wgrant> Tomorrow I'll cut it by another 60% :)
<StevenK> wallyworld: Can haz approve?
<wallyworld> diff there? let me look
<StevenK> wallyworld: Yes, it's updated.
<wallyworld> it's been really slow of late
<StevenK> It did the initial diff very quick
<StevenK> I'm still slightly annoyed that I somehow managed to create 3 MPs
<wallyworld> i reckon my last few mps have taken aaaaggges
<wallyworld> r=me anyway
<StevenK> wallyworld: Are the changes in http://pastebin.ubuntu.com/936490/ actually testable?
<wallyworld> StevenK: for starters i'd move all the js to a yui module and out of the tal
<wallyworld> then you may be able to test something
<wallyworld> otherwise no
<wallyworld> what i've seen done (/me shudders) is to test that the tal/generated html contains a specific js snippet
<wallyworld> but, ew
<wgrant> That makes people like me very sad :)
<wallyworld> yep, me too :-(
<StevenK> wallyworld: It deserves a large refactor, but I don't want to do it now.
<StevenK> The filebug macros template is disgusting
<wallyworld> StevenK: sure, but at least put the js in a js file
<wallyworld> even if no tests are added etc
<StevenK> wallyworld: Sorry, but I don't want to. Bug:+filebug is a house of cards on a bed of quicksand.
<wallyworld> ok, you're the one doing the work so i can't make you :-)
<wallyworld> i would have
<wallyworld> better get it done before tomorrow when i'm ocr :-P
<StevenK> Hah
<wallyworld> StevenK: i'm putting up a branch which fixes those DBType JSON errors so hopefully those oops will disappear soon. gotta get the new lazr.json code reviewed also so it won't hit prod till next week
<StevenK> \o/
<adeuring> good morning
<StevenK> Hmm, where am I supposed to get rabbitmq-server 2.6.1?
<lifeless> 2.7.1?
<czajkowski> morning all
<czajkowski> lifeless: the blessed juju charm bug is back - https://bugs.launchpad.net/launchpad/+bug/983530
<_mup_> Bug #983530: "charms" needs branch name consistency <juju:Invalid> <Launchpad itself:New> < https://launchpad.net/bugs/983530 >
<maxb> czajkowski: But we've got ~6 months before anyone needs to run branch-distro again, so no rush :-)
<StevenK> Unlikely
<maxb> ?
<maxb> oh, the version question
<StevenK> maxb: Won't we run it for q?
<StevenK> In two weeks
<maxb> oh, perhaps I'm extrapolating wrongly
<maxb> It seemed that juju only branched for precise recently
<maxb> It's still no big deal, I already wrote them a 5 line launchpadlib script to fix things up after branch-distro
<jml> hey ho
<czajkowski> herro
<jml> my branch failed buildbot: https://lpbuildbot.canonical.com/builders/lucid_lp/builds/1994/steps/shell_6/logs/summary
<wgrant> jml: There was an intermittent failure
<jml> I haven't done any serious probing yet, but I've got no idea how that failure is related to my change
<wgrant> jml: It should be on qastaging now
<jml> wgrant: oh. hmm.
<wgrant> I reverted the problematic revision several hours ago
<wgrant> With the minor issue that qastaging appears to be down
<wgrant> Like, not accepting connections
<wgrant> It worked a minute ago..
<wgrant> There we are
<jml> are you guys going to serialize landings again once parallel testing is up?
 * jml is guessing not, but you know, a boy can dream
<wgrant> Not initially
<wgrant> It wouldn't have helped this time, either.
<wgrant> The first two test runs passed.
<wgrant> But my 6 ec2 runs hit various combinations of the two flaky tests failing.
<jml> wgrant: right. intermittent failures are the devil.
<wgrant> jml: qastaging's apidoc says createPPA has a commercial argument, so it looks to be there
<wgrant> Yeah
<jml> oh hey, I wrote a script
<wgrant> No idea how these are happening; need to poke jcsackett.
<jml> .huh
<jml> as best as I can tell, createPPA() returns a dict of the attributes of the person that the ppa is being created on
<jml> which, uhh, is weird
<wgrant> jml: You can't say lp.me.foomethod
<wgrant> Because lp.me is a redirect
<wgrant> And POSTs aren't allowed to follow redirects
<wgrant> So lp.me is reasonably useless.
<jml> yes.
<jml> but only marginally more so than the rest of lazr.rest*
<wgrant> :)
<jml> jml is not allowed to make commercial PPAs
<jml> \o/
<wgrant> Oh, I thought you were already a commercial-admin
<jml> ok. now I need to go away before I start thinking too hard about createPPA's brokenness
<wgrant> What's borked?
<jml> You had to ask.
<jml>             role = IPersonRoles(person)
<jml>             if not (role.in_admin or role.in_commercial_admin):
<jml> does that work if 'person' is a team?
<jml> If 'person' is in admin but the team they are creating the ppa for is not then presumably that check won't pass
<wgrant> It should always be checking on the current user, not the person who is being operated on.
<jml> as validatePPA() is called by createPPA with the person being operated on
<wgrant> Now, it probably isn't, because a lot of our code is fucking moronic.
<wgrant> But it *should* be.
<jml> wgrant: yeah, that's the brokenness I was talking about
<jml> wgrant: and, uhh, well put.
<jml> another part of the problem is that there are all of these rules, but they are expressed imperatively (not great), spread out in a bunch of different places (worse), and often partially and imperfectly duplicate one another (rotten, but a natural consequence of the first two)
<wgrant> Mmm
<wgrant> Being imperative isn't the problem. Being inconsistent and distributed and buggy and otherwise generally horrid is.
<jml> it's not *the* problem, no.  but if you could express your permission rules as data, I'm pretty sure a lot of other things would fall into place
<wgrant> That's true.
<jml> we were talking a bit about this when we did one of these recent branches
<jml> zcml security has no way of expressing "passing in private as True to this method is restricted"
<wgrant> Right.
<wgrant> That has plagued us forever.
<jml> and even if you kludged around it by having a createPrivate method, that wouldn't be enough
<wgrant> And then there are things like "privilege X must be held on this argument"
<jml> because you would need a new permission
<wgrant> Traditional Zope security is pretty much useless for anything.
<wgrant> Counterproductive, even.
<jml> e.g. I can create branches in ~jml/+junk, but no one else can. I cannot create private branches.
<wgrant> Because it is based entirely on the (object, attrname)
<jml> it's a good type checker? maybe?
 * jml doesn't really believe that.
<jml> wgrant: can I get commercial-admin on qastaging?
<wgrant> webops: please add jml to commercial-admins on qastaging
<jml> ta
<jml> (although, huh, what a colossal waste of their time when they could be deploying my software)
<mthaddon> jml, wgrant: done
<wgrant> Heh
<wgrant> mthaddon: Thanks
<jml> mthaddon: thanks.
<jml> and there was much rejoicing.
<jml> wgrant: did you watch the "Simple made easy" talk that Gary shopped around?
<wgrant> jml: No. Should I?
<jml> wgrant: I think so.
<wgrant> I think I recall the email
<jml> wgrant: although reading my blog post about it is probably an almost acceptable alternative.
<wgrant> Your blog posts are often quite acceptable indeed.
<jml> personally I'd rather digest things as text rather than audio
<jml> wgrant: thank you :)
<jml> but it is a pretty good talk.
<wgrant> Yeah, reading is a tad faster than listening to an hour of waffling..
<wgrant> I wish everything came with transcripts :)
<wgrant> jml: Care to leave commercial-admins now you're done?
<jml> +1
<wgrant> It's a reasonably powerful team, so the fewer unneeded members the better.
<jml> wgrant: sure.
<wgrant> Thanks.
<jml> the whole point of this exercise is to reduce the need to be a member.
<jml> \o/
<jml> I think I've just isolated this bug.
<benji> jml: would that be the tag leakage?
<jml> gary_poster: hi
<jml> benji: yes indeed.
<benji> cool
<gary_poster> hey jml
<gary_poster> sounds like you have addressed both of y concerns from last night :-) thank you
<jml> well, the tag filtering thing is still wip
<benji> I'm a little jealous, it looked like a fun one to tackle.  The downside of multi-timzone cooperation, I guess. ;)
<jml> I have to page it back in and remember what needs to be done for that.
<jml> lp:~jml/testrepository/tag-leakage/ has my steps to isolation
<jml> going to knock up a patch to testtools now
<jml> benji: I probably should have left it. :\
<gary_poster> jml, for tag filtering, we're happy to help, as you'd expect.  I'd love to see if we can get a rough version in our PPA though, if it works
<jml> gary_poster: cool.
<benji> jml: do you think your branch is suitable for us to play with in our PPA
<jml> benji: no idea, I'm afraid.
<jml> benji: I didn't deliberately put any remote root exploits in it.
<benji> heh
<benji> jml: do you want us to pick up the torch on the tag leakage or are you just about done?
<jml> benji: just finishing up.
<benji> great!
<jml> am going to merge without review.
<jml> hmm.
<jml> merge and pushed
<jml> :(
<jml> ok, I think filter-tags will need a little bit of work.
<jml> the ideal thing to do is release testtools and then burn subunit.TestResultDecorator
<gary_poster> heh
<jml> but that would mean a lock-step upgrade and we don't like those
<gary_poster> though doable
<jml> I'm not sure if it makes sense for you guys to pick up on it, tbh.
<jml> yeah
<jml> I'd like to spend a bit more time paging all of this in so I'm clearer on the release/dependency issues
<gary_poster> ok, understood.  it's blocking us, which I hate to admit. um.
<jml> gary_poster: sure. I'll get to it post food then.
<gary_poster> jml, wow, thank you.  I was contemplating nasty hacks.
<gary_poster> that would be fabulous.
<jml> gary_poster: my pleasure.
<jml> gary_poster: somewhat relatedly, I'm sure my manager always enjoys hearing nice things about me.
<gary_poster> jml, lol, can do
<jml> leaving this cafe for another one with better food.
<deryck> Morning, everyone.
<benji> jml: am I reading your comment at https://code.launchpad.net/~benji/testrepository/add-worker-id-tagging/+merge/102574/comments/221132 correctly in that without the ExtendedToOriginalDecorator you get correctly-tagged output?  I'm trying to figure out if ExtendedToOriginalDecorator is needed, and it doesn't look like it.
* jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: jcsackett | Firefighting: - | Critical bugtasks: 4*10^2
<jml> benji: I get that test failure without it. Because addSuccess() is passed details but LoggingResult doesn't implement it.
<benji> jml: right, I've fixed the test failure (I had hacked the testtools I was using, but I now have a test fix that doesn't require that hack).  I'm now interested in whether or not I'll need the ExtendedToOriginalDecorator to get correct output.  I don't think we do.
<jml> benji: basically only use it if you don't control the result that goes in.
<benji> jml: right, that's what I was thinking; since we control the entire stack of results there, we should be good
<jml> benji: ok.
<jml> benji: if the tests pass.
<benji> indeed they do
* rick_h changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: jcsackett, rick_h* | Firefighting: - | Critical bugtasks: 4*10^2
<rick_h> jcsackett: bah, sorry completely missed it was thurs
<jcsackett> rick_h: all good. :-)
<sinzui> jcsackett, do you have a few minutes to talk?
<jcsackett> sinzui: sure. lemme go find my phone and i'll get on G+.
<jcsackett> sinzui: ready when you are.
<deryck> abentley, hi.  chat time now ok?
<abentley> deryck: sure.
<sinzui> jcsackett, I an in the g messenger hangout
<jcsackett> huh. so am i. i'll quit and come back in.
<deryck> abentley, https://plus.google.com/hangouts/_/extras/d030c97575c1cc09b3ba584164c3d8e5baf17a0e
<sinzui> jcsackett, http://pastebin.ubuntu.com/936950/
<sinzui> jcsackett, r=me for the privacy adapter branch
<benji> jml: any hints on running the subunit tests?  runtests.py gives me an import error and I don't see anything in the README about any neccesary setup
<jelmer> benji: have you tried 'make check' ?
<benji> jelmer: yep, not a make target
<benji> there is a Makefile.am and configure.ac that look tantalizing, if I knew what they wanted me to do with them
<jelmer> benji: autoreconf -i && ./configure && make && make check
<benji> jelmer: ah, autoreconf
<bac> has launchpad-developer-dependencies gone away?
<bac> nm, i see it is built as part of launchpad-dependencies in the ppa
<sinzui> rick_h, do you have time to review https://code.launchpad.net/~sinzui/launchpad/project-notify-5/+merge/102734
<rick_h> sinzui: sure thing
<rick_h> sinzui: ping, question for you
<sinzui> hi rick_h
<rick_h> sinzui: so shuoldn't there be some code that creates these jobs?
<rick_h> or is that a follow up?
<rick_h> I would imagine there's something that queries for upcoming expiring projects to deactivate via a query somewhere?
<sinzui> per the cover letter, I ran out of room and time
<sinzui> My next branch will deal with that
<rick_h> ah gotcha, sorry. Read that but thuoght of it as something different
 * deryck heads home now
<sinzui> Instead of fixing a trivial bug that affects a few users, I found a non-trivial bug that indicates our sprites will break in all browsers in the future.
<sinzui> I am going to look for something to delete instead
* jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2
<lifeless> sinzui: sounds fun ?
<lifeless> sinzui: you found a dupe
<sinzui> well. I pleased to have accomplished something
<lifeless> sinzui: \o/
<sinzui> This issue is not about asymeteric packing though. It really is about the size of the image. I agree it can be a dupe because one fix is needed.
<wgrant> StevenK, wallyworld: A quick one if someone has a sec: https://code.launchpad.net/~wgrant/launchpad/bugtaskflat-join-removal/+merge/102780
<wgrant> 39 lines (+8/-7) 1 file modified
<nigelb> Morning.
<wgrant> Morning nigelb.
<nigelb> 0430 is awfully early to be awake :/
 * wallyworld looks
<wallyworld> wgrant: all the tests pass?
<wgrant> wallyworld: Yes.
<wallyworld> wgrant: was flat_bug_join already defined?
<wgrant> wallyworld: Yeah, it's used in the sorts higher up.
<wgrant> flat_bug_join = (Bug, Join(Bug, Bug.id == BugTaskFlat.bug_id))
<wgrant> flat_bugtask_join = ( BugTask, Join(BugTask, BugTask.id == BugTaskFlat.bugtask_id))
<wallyworld> ok, r=me
<wgrant> Thanks.
#launchpad-dev 2012-04-20
<wallyworld> sinzui: around?
<wallyworld> wgrant: StevenK: on the sharing details page, we show bugs and branches in the one table. there's a (3rd party) sorttable.js bug wrt row colspans which means sorting is broken. i can work on fixing the bug but i think we perhaps should be showing branches and bugs in different tables in any case. you agree?
<lifeless> wallyworld: why different tables?
<lifeless> wallyworld: we have lots of artifact types, having one table per is really just a manual pre-defined facet search.
<wallyworld> lifeless: like we do for milestones with blueprints and bugs i think it is
<wgrant> wallyworld: Well, you know how I feel about sorttable on that page at all :)
<wallyworld> different things therefore different ables
<wallyworld> i can keep everything in the one table
<wallyworld> i'll fix the sorttable bug
<wallyworld> but i'm not sure how much sense sorting makes if we are sorting on bug nr and branch name
<wallyworld> that's why i was thinking separate tables, unless we think sorting on bug nr, branch name is silly
<StevenK> wgrant: I wonder if the >20 minute tests branch I approved had a wildly different time in ec2.
<wgrant> StevenK: Quite possibly. Those tests are rather DB-heavy.
<lifeless> wallyworld: why have js sorting anyway? db can sort more efficiently
<wallyworld> sure, but why enforce a round trip just to sort 20 rows by information type for example
<wallyworld> i think js sorting definitely has a place
<lifeless> wallyworld: if the page doesn't show /all/ the content
<wallyworld> then js sorting should be disabled
<wallyworld> it's not currently, and i don't think we do that elsewhere, but i think we should
 * StevenK tries to get his head around YUIXHR tests and feels his brain slowly dribbling out of his ears.
<StevenK> loltpg
<adeuring> good morning
<czajkowski> aloha
<RfADdlS> I was upload the package and get error on build "Can't exec "qmake": No such file or directory at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 215." How to fix it? Full log http://goo.gl/nxYFz
<StevenK> RfADdlS: We don't support PPAs in this channel, but you're missing a Build-Depends.
<RfADdlS> StevenK: where should I write? I pointed out in debian/control all depends.
<jelmer> RfADdlS: #ubuntu-packaging is the right channel for questions about packaging
<RfADdlS> StevenK: jelmer: thank you
<jml> blooop
<jml> http://paste.ubuntu.com/938096/
<wgrant> Heh
<czajkowski> thats definately a blooop and not a blip
<wgrant> jml: Is that really all of them?
<wgrant> It's excluding tests obviously
<wgrant> But I would have expected more
<jml> wgrant: excluding tests and doc#@$!s
<jml> bzr grep -n 'removeSecurityProxy\(' |grep -v test |grep -v '\.txt'
<jml> also excludes 'testing'
<jml> which accounts for about 100
<wgrant> Ah
<wgrant> The lack of testing would do it, indeed.
<jml> gary_poster: https://code.launchpad.net/~jml/subunit/filter-tags/+merge/102840 up for review and I'm happy for it to land.
<jml> gary_poster: jelmer or vila are valid reviewers.
<gary_poster> jml, fantastic thanks.  jelmer or vila, if you have time to review soon it would help us a lot.
<gary_poster> jml. did benji sufficiently address https://code.launchpad.net/~benji/testrepository/add-worker-id-tagging/+merge/102574 for you to approve it?
<jml> gary_poster: haven't looked. will do so now.
<gary_poster> thank you
* adeuring changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: adeuring | Firefighting: - | Critical bugtasks: 4*10^2
<jml> merged.
<jml> there's definitely some releasing that needs to be done
<jml> gary_poster: once you guys are actually using this new stuff in anger and getting value from it, let me know, and I'll release the bits I can.
<gary_poster> awesome thanks jml.  We already have the tagging stuff in place for our ec2 parallel tests, thanks to our ppa, so those parts are being used successfully in anger.  this has given us subunit results that we can now analyze with your subunit-filter changes.
<jml> gary_poster: cool. I guess once you've done such an analysis and learnt something, I'll do a release.
<jml> and maybe I'll do a testtools release today anyway.
<gary_poster> cool.  I intend/hope to have such that analysis today; will ping you about it one medium or another when I do
<rick_h> abentley: hey, can I bug you pre stand up for a call to help with this bug stuff?
<abentley> rick_h: Sure.  Bug me with your bug stuff.
<rick_h> awesome, normal stand up hangout?
<abentley> rick_h: Okay.
<jam> flacoste: are you around? Are we still chatting today?
<abentley> adeuring: The lazr.jobrunner release HOWTO says "Test the generated source distribution in dist/".  How do I do that?
<adeuring> abentley: good question... I don't know. The text stems from creating a template for the buildout machinery...
<abentley> adeuring: Oh, okay.  Maybe we'll remove that text for 0.4, then :-).  I wondered why it didn't mention anything about Launchpad...
<flacoste> jam: yes
<adeuring> abentley: what you can do: create the tar ball, unpack it somewhere and run "make develop; make check"
<flacoste> jam: hang out?
<flacoste> jam: let me get you an invite
<jam> flacoste: google hangouts makes it sound like I'm talking under water according to everyone I've tested with.
<jam> but I'll try it again
<flacoste> jam: let's skype then
<flacoste> jam: or voip
<flacoste> either works for me
<jam> JohnArbashMeinel on skype
<flacoste> jam: yes, let me switch input
<jam> flacoste: ok
<flacoste> jam: i need to hang up
<abentley> adeuring: Makefile isn't included in the tarball.  Should it be?
<deryck> hi flacoste.  wb!
<abentley> adeuring: Neither is bootstrap.py.
<adeuring> abentley: hmmm... the usual "python -S bootstrap.py; bin/buidout" should be enough, but sure, bootstrap.py should be included...
<abentley> adeuring: And buildout.cfg?
<adeuring> abentley: yes, of course...
<abentley> adeuring: I guess we can fix that for 0.4, too.
<adeuring> abentley: right
<gary_poster> jml, hey.  we think the new subunit-filter might be broken.  Are we maybe doing something wrong?  Examples:
<gary_poster> cat ~/Downloads/testrepo-0.txt | env PYTHONPATH=python ./filters/subunit-filter -s --with-tag='worker-0' | head -n 300
<gary_poster> this gives us all tests irrespective of worker-0
<gary_poster> cat ~/Downloads/testrepo-0.txt | env PYTHONPATH=python ./filters/subunit-filter -s --with-tag='worker-0' --without-tag='zope:layer' | head -n 300
<gary_poster> this gives us...something weird.  Will pastebin, one sec
<gary_poster> http://pastebin.ubuntu.com/938332/
<gary_poster> oh, easier to read there
<gary_poster> without-tag may have worked
<gary_poster> but it did not for benji
<gary_poster> he tried --without-tag worker-3
<gary_poster> and got worker-3
<abentley> adeuring: Can you please authorize me to upload packages for lazr.jobrunner to pypi?
<adeuring> abentley: if you can tell me to do that, sure ;)
<adeuring> abentley: found it. what is your pypi user name?
<abentley> adeuring: abentley
<adeuring> abentley: done
<abentley> adeuring: Thanks, works.
 * deryck does the post-update reboot
<jml> gary_poster: ok, that sucks. Will try adding more tests.
<jml> gary_poster: can you give me a small snippet that has worker-0 tags, zope:layer tags and tests with neither?
<gary_poster> jml, we are futzing with it within timebox.  10 minutes left.  tag leakage appears to be the problem.
<gary_poster> jml, will send after 10 minutes :-)
<jml> gary_poster: tag leakage should be fixed as of testtools r254 :(
<gary_poster> jml, yes, different tag leakage
<jml> \o/
<gary_poster> our output does not have tag leakage
<gary_poster> from the testrun
<gary_poster> but when the tag predicate compares with-tags with existing tags
<gary_poster> the existing tags gradually grows
<gary_poster> within the logic of subunit-filter
<jml> harumph.
<jml> gary_poster: which revno of filter-tags are you using?
<gary_poster> jml 184
<jml> gary_poster: that's the correct one... dammit.
<gary_poster> jml, ok, our futzing time's up.  benji is putting up a pastebin of a small output you can use
<benji> jml: http://paste.ubuntu.com/938374/
<jml> \o/
<gary_poster> jml, that is a testrepository run, not LP, but that means it is complete, fwiw, and he duped my experiences
<gary_poster> --with-tag='worker-0' or --without-tag='worker-0'
<jml> intriguing.
<jml> subunit-filter trunk (and 0.0.7) both don't seem to parse that correctly
<jml> even when I strip out tags.
<jml> :(
<abentley> adeuring: r=me
<adeuring> abentley: thanks!
<jml> benji: when I download that, it has dos line endings. Is that the case for you?
<benji> jml: I don't think it did on my end, I'll check in a second
<benji> jml: I just emailed you the stream as an attachment so we can be sure it isn't being mangled by the pastebin
<jml> ok.
<jml> I've figured it out
<jml> I learned about the local / global distinction partway through implementing this branch and messed up the tag tracking in _PredicateFilter
<jml> :(
<jml> What I wouldn't give for a solid fortnight and a reviewer to hand.
* mpt changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: adeuring | Firefighting: - | Critical bugs: 3.47*10^2
* adeuring changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 3.47*10^2
 * jml twirls his pen, clicks it twice, stands up with both arms high in the air and shouts "I am invincible!"
<jml> benji, gary_poster: r186 seems to work for me.
<jml> the rot in tags goes deep
<jml> this is the first time that it's actually been used for anything, afaict.
<jml> I've got to head now. Keep in touch if there's any problems or any successes.
<benji> thanks jml; I'll see if I'm not using r186 or something
<gary_poster> thank you jml
<jcsackett> weird. bin/py -t buildmailman is blowing up in my face on `make run` now. anyone seen this before?
<sinzui> jcsackett, no.
<jcsackett> sinzui: yeah, i thought i had just trashed a config, but stashing some changesets shows it's actually some code i changed in publisher.
<jcsackett> which is weird.
<jcsackett> sinzui: and solved. import of `Breadcrumb` apparently fubared things. i'm guessing circular import issues, since moving the import to the clause where i need it works.
<sinzui> jcsackett, I agree with your assessment
<jcsackett> sinzui: weird though that would break the mailman build step though...or is that more tightly coupled than i thought?
<sinzui> jcsackett, it is very coupled because we import Lpism in moneypatches
<jcsackett> aaah.
<jcsackett> ok.
<jcsackett> well then, as long as i'm not nuts. :-)
<sinzui> Mailman 3 promises better decoupling
<gary_poster> abentley, hi.  hallyn from the server team would really like some assistance getting qemu-kvm and libvirt bzr trees auto-importing again.  He was hoping that someone would be at UDS to help him, but I will have to tell him no.  Would you be able to help him sometime in the next few days or weeks, or could you give another suggestion for him to talk to?
<abentley> gary_poster: Let me have a quick look.
<gary_poster> thanks abentley
<abentley> gary_poster: The problem is that these git branches use submodules, and Bazaar does not have an equivalent feature.
<gary_poster> abentley, ah :-(
<gary_poster> abentley, so this will not be fixed anytime soon, if ever, given the current state of things, is what I should report, right?
<abentley> gary_poster: More complicated than that.
<gary_poster> ok
<abentley> gary_poster: If the git trees don't actually use submodules and just have some revisions in the past that did, then there's a workaround.
<abentley> gary_poster: Although I'm not sure if it's accessible to users.  Probably not, now that I think of it.
<gary_poster> abentley, but in that scenario, you, or someone else with the proper direction, would be able to help him?
<abentley> gary_poster: I think we'd have to get webops hand-upgrading branches in the code import branch store.  I don't know if that would fly.
<gary_poster> abentley, ah, ok.  it's a remote possibility at best then, I guess.  thank you very much for looking into it, abentley.
<abentley> gary_poster: np.
<jelmer> bug 402841 is (IIRC) the relevant bug
<_mup_> Bug #402841: file-roller crashed with SIGSEGV in memmove() <apport-crash> <apport-failed-retrace> <i386> <file-roller (Ubuntu):New for desktop-bugs> < https://launchpad.net/bugs/402841 >
<jelmer> hmm no, bug 402814 ?
<_mup_> Bug #402814: Importing revisions with submodules is not supported <lp-code> <udd> <Bazaar:Triaged> <Bazaar Git Plugin:Fix Released> <cloudfoundry:Confirmed> <Launchpad itself:Triaged> < https://launchpad.net/bugs/402814 >
<abentley> jelmer: I tried it locally, and it died with this: http://pastebin.ubuntu.com/938863/
<jelmer> ah, so it's more than just bug 402814
<_mup_> Bug #402814: Importing revisions with submodules is not supported <lp-code> <udd> <Bazaar:Triaged> <Bazaar Git Plugin:Fix Released> <cloudfoundry:Confirmed> <Launchpad itself:Triaged> < https://launchpad.net/bugs/402814 >
<jelmer> abentley: bug 963525
<_mup_> Bug #963525: signed tag support <Bazaar Git Plugin:Triaged> <Dulwich:Triaged by jelmer> <Launchpad itself:Triaged> < https://launchpad.net/bugs/963525 >
<abentley> gary_poster: So even if we were lucky on the first issue, there's a second bug: 963525 which definitely requires code to fix.
<gary_poster> abentley, ack. passing along.  thank you.
#launchpad-dev 2012-04-22
<lifeless> sometimes I hate python
<lifeless> >>> os.path.normpath('//home/robertc')
<lifeless> '//home/robertc'
<lifeless> >>>
<lifeless> robertc@lifeless-64:~$ pydoc os.path.normpath
<lifeless> Help on function normpath in os.path:
<lifeless> os.path.normpath = normpath(path)
<lifeless>     Normalize path, eliminating double slashes, etc.
<nigelb> This works
<nigelb> >>> os.path.normpath('/home//nigel')
<nigelb> '/home/nigel'
<nigelb> But yeah, bug.
<lifeless> nigelb: deliberate
<lifeless> nigelb: but the docs do not tell you :<
<nigelb> lifeless: Katie Cunningham said this part of her pycon talk - The documentation always lies. Because developers write it and we lie.
<lifeless> nigelb: http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11
<lifeless> nigelb: 'A pathname that begins with two successive slashes may be interpreted in an implementation-defined manner, although more than two leading slashes shall be treated as a single slash.'
<nigelb> lifeless: Ha.
<nigelb> How much time did you spend searching for that?
<lifeless> to show you? < 120 seconds
<lifeless> after seeing the code? 0, I didn't care enough to do anything other than work around it.
<nigelb> heh
<lifeless> evil genius at work
<lifeless> second version can be good, this version just has to rock
<nigelb> I will admit to looking at LP source when I've gotten confused with the apidoc. It is vastly easier.
<wgrant> lifeless: You're around tomorow?
<wgrant> +r
<lifeless> wgrant: AFAIK yes
<nigelb> wgrant: I thought you were giving him a review. Bah. +r r+.
<wgrant> lifeless: Great.
<wgrant> lifeless: Will probably need a bit of live index creation.
<lifeless> anzac day is wednesday
<lifeless> stub is back too
<wgrant> I intend to enable BugTaskFlat for ~launchpad tomorrow
<wgrant> Ah, true.
<lifeless> sweet
<wgrant> Yeah, Anzac Day is Wed here too
<lifeless> so lets not enable stuff tuesday :)
#launchpad-dev 2013-04-15
<StevenK> wgrant: Do you want to help me with my YUI3 Calendar branch?
<StevenK> wallyworld_:  82 files changed, 48 insertions(+), 26310 deletions(-)
<wallyworld_> StevenK: what did you delete?
<StevenK> wallyworld_: YUI2
<wallyworld_> \o/
<wallyworld_> at last
<wallyworld_> how's lp going?
<StevenK> Yeah, but my YUI3 calender has a few problems
<wgrant> StevenK: I don't know much YUI, but I can try
<StevenK> Maybe I'll turn wallyworld_ upside down and shake him until some clues fall out
<wallyworld_> StevenK: what calendar implementation did you use?
<StevenK> wallyworld_: Y.Calendar from YUI 3.9.1
<StevenK> (Which is now the YUI version used on LP if you're a beta-tester)
<wallyworld_> it's been so long since i did yui i didn't even realise/remember they had a std calendar widget
<wgrant> It's new. That was part of the motivation for the upgrade.
<wallyworld_> what sort of issues are there?
<StevenK>      * Looks like rubbish, and is transparent
<StevenK>      * Needs an X to dismiss
<StevenK>      * Need to handle time input
<StevenK>      * Clicking Choose will create a new calendar
<StevenK>      * The selection function does not fire
<StevenK> Those are my current issues
<wallyworld_> so just minor glitches then :-)
<wallyworld_> with the (x) to dismiss, you could look at how the lazr overlays are done
<StevenK> I'm happy to push up the branch, but it's *massive* due to YUI2 dying
<wallyworld_> the lazr overlays add an (x) if i recall correctly
<StevenK> wallyworld_: It's a node that calls div_node.hide(); on click, I just haven't done it
<wallyworld_> what's the main bit you are stuck on?
<StevenK> http://wedontsleep.org/~steven/new-calendar.jpg
<StevenK> That's what I've spent Friday afternoon and this morning chasing
<wgrant> Is there Y.Calendar CSS that you have to include?
<StevenK> Done so
<StevenK> +++ buildout-templates/bin/combine-css.in	2013-04-12 04:38:34 +0000
<StevenK> +    'yui/calendar/assets/calendar-core.css',
<StevenK> +    'yui/calendar/assets/skins/sam/calendar.css',
<StevenK> +    'yui/calendar/assets/skins/sam/calendar-skin.css',
<wallyworld_> are there any examples to work from? surely the transparency is just a misapplied style or something?
<wallyworld_> with the selection issue, does the registered click handler get called? can you firebug that issue?
<StevenK> wallyworld_: The calendar machinery creates an enclosing <div> for the calendar, but I couldn't figure out what style/class to set
<StevenK> wallyworld_: I've set breakpoints inside the function that is supposed to fire, but it doesn't happen. I was going to read the JS to see if I can work out what events it emits.
<wallyworld_> from memory, with the lp pretty overlays etc, we define our own css using selectors based on the full generated yui class names
<wallyworld_> perhaps you could try something simple like a red background to ensure you selectors are correct (use fb to look at the exact class names to define your selector)
<wallyworld_> the function that is supposed to fire - is that an onclick handler or something?
<StevenK> calendar.on('selectionChange', function(e) {
<wallyworld_> is there a yui calendar api you are using to register it, or it is a construction attribute, or...?
<StevenK> wallyworld_: http://yuilibrary.com/yui/docs/calendar/
<StevenK> And in calendar-base:         this.fire("selectionChange", {newSelection: this._getSelectedDatesList()});
<wallyworld_> you used this example? http://yuilibrary.com/yui/docs/calendar/calendar-simple.html
<wallyworld_> does a debug print inside your selection function print out?
<wallyworld_> are there any yui errors? since they may prevent the handler from registering
<StevenK> wallyworld_: Changing the style to include background-color:red; impacts the page so that works at least
<wallyworld_> the page or the calendar itself?
<StevenK> The <div> that contains the calendar
<StevenK> Hm, maybe that is the answer.
<wallyworld_> and the style you changed was in lp css?
<StevenK> wallyworld_: No, the style tag when the <div> is created
<wallyworld_> there's default styling that comes with the widget, and for that you need to say <div id="lpcal" class="yui3-skin-sam"  ....
<wallyworld_> but i think in lp we use our own css stuff
<wallyworld_> but for starters, see if adding the yui3-skin-sam style works
<wallyworld_> classname i mean
<wallyworld_> if that works, you could copy the default yui styling into a lp css file and rebrand as required
<StevenK> wallyworld_: class="yui3-skin-sam" on the div has no effect
<StevenK> style="position:absolute;background-color:white;" makes it non-transparent, but then it doesn't look like a usual LP popup
<wallyworld_> you sure the yui3 skin css is being packaged in with the lp stuff?
<StevenK> .yui3-skin-sam button.lazr-btn{background:transparent
<StevenK> That could be a large clue
<wallyworld_> where did you get that line from?
<StevenK> combo.css
<wallyworld_> it still seems that the combos.css is missing the calendar css stuff
<wallyworld_> is the yui3 calendar source in the lp tree?
<wallyworld_> and have you checked the build scripts to ensure the calendar css is being included?
<wallyworld_> StevenK: see combine-css.in
<StevenK> wallyworld_: I've changed that in this branch, see the four line of +... I pasted above
<wallyworld_> ah right
<wallyworld_> and you used fb to double check the rendered class name for the containing div is as required to pick up the styles from the combo.css?
<wallyworld_> or you could use fb to see what styles are actually being applied
<wallyworld_> and if the ones from the calendar.css are not there, then there's a problem with the class names being used
<StevenK> Ugh
<StevenK> My plan to create a PrettyOverlay and then render the calendar inside that is not going well
<adeuring> good morning
#launchpad-dev 2013-04-16
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/xmlexport-all-specs/+merge/159061
<wgrant> StevenK: k
<StevenK> Bleh
<StevenK> If I Y.Node.create('<div/>') and then calendar.render(), the div gets added to <body>
<wgrant> StevenK: <div/> won't work in some browsers
<StevenK> But I want the <div> inside the overlay :-(
<wgrant> StevenK: <div></div> is more compatible.
<StevenK> wgrant: Sure, but the issue is where it is
<wgrant> StevenK: That might not be irrelevant
<wgrant> I don't remember which browser it was
<wgrant> Maybe IE8
<wgrant> but it did really really strange shit when trying to create a void div
<StevenK> I've switched to <div></div>, but it still gets added right at the top
<wgrant> :(
<StevenK> wallyworld_, wgrant: Getting closer: http://wedontsleep.org/~steven/new-calender-1.jpg
<StevenK> http://wedontsleep.org/~steven/new-calendar-1.jpg even
<wallyworld_> E404
<wallyworld_> looking better
<wallyworld_> needs sone css lovin'
<wallyworld_> some
<StevenK>      * Too wide, and needs to be positioned correctly
<StevenK>      * Need to handle time input
<StevenK>      * The selection function does not fire
<wgrant> :)
<wallyworld_> selection function - did you debug in fb?
<StevenK> I tried
<StevenK> Setting a break inside it doesn't fire
<wallyworld_> i reckon there would be an onclick inside the calendar js
<wallyworld_> which then fires the onselect event
<wallyworld_> perhaps debugging in there will be useful
<StevenK> And in calendar-base:         this.fire("selectionChange", {newSelection: this._getSelectedDatesList()});
<wallyworld_> is this line called?
<StevenK> Doesn't seem to be
<StevenK> Still digging
<StevenK> wallyworld_: If calendar says it requires calendar-base, does my module also need to pull in calendar-base?
<wallyworld_> no, bit calendar base should be added to the combo loader config
<wallyworld_> but
<wallyworld_> i forget exactly what needs doing for that
<StevenK> Yeah, -base is dragged in
<wallyworld_> i would expect errors on the console if there were any dependency issues
<wallyworld_> i can't see any other option other than to look at the calendar js source and see how the button click is transformed to the firing of the selection event
<wallyworld_> and start debugging from there
<wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/bug-1169441/+merge/159086
<StevenK> wgrant: One niggle is to change the AccountStatus.DEACTIVATED, AccountStatus.NOACCOUNT wrapping, but if you don't want to, it's fine. r=me.
<wgrant> StevenK: Thanks
<wgrant> I've been seeing these oopses for a while, but thought I'd caught all the cases
<wgrant> Evidently not.
<adeuring> good morning
<cjwatson> I could use some help with query optimisation (happy to wait until .au is around).  I have http://paste.ubuntu.com/5713139/ so far, but lp.soyuz.browser.tests.test_queue.TestQueueItemsView.test_query_count is giving me "queries do not match: 54 != 59", and I can't see how to optimise that.  You can see my attempt at optimisation in lib/lp/soyuz/browser/queue.py in that diff, but that change made no difference.
<james_w> cjwatson: so the template change caused the test failure, and you tried the code change to adjust?
<cjwatson> Yes
<cjwatson> I was expecting the template change to cause that particular test failure initially
<james_w> ah, ok
<james_w> it didn't look like a change that would affect the queries
<wgrant> cjwatson: Isn't it likely that those extra 5 queries are your preloading queries?
<wgrant> Which is fine
<wgrant> As long as the query count doesn't scale with the batch size.
<cjwatson> wgrant: That seems odd given that there were an extra five before I did any preloading
<wgrant> cjwatson: Not at all odd if the test only showed one PCJ row
<cjwatson> I suppose it's possible no preloading is necessary and I just misfired
<wgrant> You'd expect there to be the same number of queries.
<cjwatson> Ah, I should check that
<wgrant> If one row has to grab data from 10 tables, you're probably going to have to preload from 10 tables still
<wgrant> You just do it all in one hit.
<wgrant> Not once per row.
<james_w> hi wgrant
<james_w> wgrant: is there a tarmac instance for oops stuff?
<wgrant> I'm about to disappear again, but I suspect that if you add an extra PCJ to the queue you'll see that it's fine
<wgrant> james_w: I don't remember if it ever ended up working...
<wgrant> But I'm gone
<wgrant> Will be back in an hoursh
<james_w> so I should land https://code.launchpad.net/~james-w/python-oops-datedir-repo/new-publisher-api/+merge/152924 by hand?
<wgrant> james_w: The last few commits to trunk aren't even merges.
<wgrant> james_w: I think python-oops-tools is (was?) tarmac-managed, but datedir-repo isn't.
<wgrant> In general, if you're able to modify the branch then it's not managed by PQM or Tarmac.
<james_w> ok
<james_w> I'll land manually
<wgrant> Great
<james_w> wgrant: would you then do a release or give me pypi rights please?
<wgrant> james_w: What's your PyPI username?
<james_w> wgrant: jamesw
<wgrant> james_w: Done
<james_w> thanks
<cjwatson> Hmm.  Bug 851562 is harder than it looks.  Generating the diff in time is easy (actually easier than doing it in its current position, I think), but showing it is hard because diffs are linked to SPRs and PCJs don't have a fixed SPR.  Would it be terrible to just add an SPR reference to the PCJ table?  I've never quite understood why we mess about with the source package name and version when we already have the SPR in hand.
#launchpad-dev 2013-04-17
<wgrant> lifeless: Upgrading from fixtures 0.3.10 to 0.3.11 generates some garbage. Any ideas why?
<wgrant> Tests generated new (2) garbage:
<wgrant> [<io.TextIOWrapper object at 0x12781bec>, <io.BytesIO object at 0x1185392c>]
<StevenK> wgrant: You've really been on an upgrade kick ...
<wgrant> StevenK: Well, we're 3-4 years behind on most things
<wgrant> Last week we upgraded Zope and YUI, this week I'm upgrading everything else.
<StevenK> We weren't that far behind on YUI
<StevenK> Maybe we need to downgrade to 2 or something
<StevenK> containing_div_node.addClass('yui3-skin-sam');
<StevenK> Which doesn't help
<StevenK> Calendar, you're beginning to annoy me
<lifeless> wgrant: garbage?
<wgrant> lifeless: gc.garbage that remains after a gc.collect()
<wgrant> Presumably due to reference cycles
<lifeless> I don't know why that isn't collected, TextIOWrapper -> BytesIO is a one way ref.
<wgrant> Yeah, that's what it looks like :/
<wgrant> Maybe the TextIOWrapper is referenced elsewhere
<wgrant> But then it shouldn't be garbage
<czajkowski> Gooooooood morning
<wgrant> Morning czajkowski
<lifeless> wgrant: so the Q is can you reproduce it.
<lifeless> Gnight.
<wgrant> lifeless: It's easy to reproduce as part of a particular LP test, but I was going to check if you knew anything before isolating.
<wgrant> Will do so
<czajkowski> cjwatson: when you're about can you give me a shout please, I seem to have broken something on my machine and in need of your assitance, for this I shall send you cake and biscuits :)
<cjwatson> czajkowski: Hi
<cjwatson> wgrant: So, I think I ended up not using fmt:link here because an earlier version rendered a link for primary archives as well (and I've reverted to that version per your feedback) and there's no link implementation for Archives other than PPAs
<cjwatson> wgrant: And as a result the TAL ended up being annoyingly cumbersome with fmt:link, rather than simpler as it's meant to be
<wgrant> cjwatson: Oh, it just leaves primary archives unlinked?
<wgrant> And copy archives too?
<czajkowski> cjwatson: shall move to kernel and fill you in there
<czajkowski> or is foundation better?
<cjwatson> czajkowski: What's it about?
<cjwatson> There's no foundations channel, intentionally
<czajkowski> ahh
<cjwatson> And I'm not a kernel developer, so I doubt that's appropriate :)
<czajkowski> cjwatson: on start up this morning I'm http://ubuntuone.com/1REKSBU0jU7XITkpfBK0RQ
<cjwatson> wgrant: Trying to use fmt:link on a primary archive raises NotImplementedError
<wgrant> cjwatson: Well that's a bit crap.
<cjwatson> wgrant: Maybe I should add a generic link implementation for archives that does <a class="sprite distribution" etc>?
<wgrant> Yet easily fixed, and it probably makes sense
<wgrant> Yeah
<wgrant> Copy archives should probably use the PPA icon, but primary/partner can use the distro one
<cjwatson> And we can use that for all other archives, and probably delete some insane TAL elsewhere
<wgrant> They could even link directly to the distro
<cjwatson> czajkowski: Nothing wrong with that - you might get the menu when you don't normally if a previous boot failed
<cjwatson> But just press Enter and carry on
<czajkowski> cjwatson: aye I did then I went to ubuntu advanced and moved down to recovery kernel. but no matter how many reboots I still up at that screen :/
<cjwatson> recovery kernel won't count as a successful boot
<cjwatson> the point of this is to show the menu when people seem to be having trouble
<cjwatson> now, if you see it after a non-recovery boot, that's a bit odd and we can investigate in #ubuntu-devel
<czajkowski> ahhhh
<czajkowski> cheers cjwatson  :)
<cjwatson> wgrant: Do <adapter /> directives in lib/lp/app/browser/configure.zcml magically pick the closest match somehow, or do I need to take inheritance into account?
<cjwatson> Also, I happened to notice that https://bazaar.launchpad.net/~launchpad/+junk/dbpatches/view/head:/allocated.txt seems to be missing 2209-43-0
<wgrant> cjwatson: It should pick the closest adapter
<wgrant> So an IPPA adapter will override one for IArchive for PPAs
<cjwatson> OK.  Though, hmm, I wonder how "closest" is defined given that IPPA is only done by alsoProvides
<wgrant> Oh, true
<wgrant> That's a good question...
<cjwatson> Maybe it'd be clearer to turn PPAFormatterAPI into ArchiveFormatterAPI and do the checks explicitly
<wgrant> Quite likely.
<cjwatson> wgrant: Copy archive icon - using the PPA icon would be inconsistent with ArchiveImageDisplayAPI.icon ("ArchivePurpose.COPY: '/@@/distribution'").  Do you want that changed?
<wgrant> cjwatson: I'd forgotten there was precedent, so go with that.
<cjwatson> wgrant: Is there any precedent anywhere for what to do when trying to render a copy from an inaccessible private PPA?  The current version is 'Sync from <tal:archive content="source_archive/displayname" />, ...'; if I do the naÃ¯ve thing and replace that with 'Sync from <a tal:replace="structure source_archive/fmt:link" />, ...', I end up with "Sync from , ..." in the output which is less than ideal
<cjwatson> I guess something like SourcePublishingRecordView.linkify_source_archive
<wgrant> cjwatson: For private teams we say <redacted>, IIRC
<wgrant> Should probably do a similar thing here.
<cjwatson> At the moment I think we must show the archive displayname
<cjwatson> But I suppose arguably that's wrong
<cjwatson> Perhaps also "Building private job" as precedent
<wgrant> Yeah, maybe
<cjwatson> So it's tempting to say "Sync from private archive"
<wgrant> Indeed
<cjwatson> wgrant: OK, would you mind re-reviewing https://code.launchpad.net/~cjwatson/launchpad/queue-copy-archive-links/+merge/159250 ?  I know you approved already, but the changes are fairly substantial.
<cjwatson> I suspect I'll have some doctest damage, which I'll let EC2 catch
<wgrant> cjwatson: That looks fine. Thanks.
<cjwatson> Now, I wonder why my EC2 setup is busted ... http://paste.ubuntu.com/5715669/
<wgrant> cjwatson: Seems to be a change in python-boto. http://paste.ubuntu.com/5715687/ seems to fix it
<cjwatson> Hm, the python-boto package hasn't changed since last May
<cjwatson> I wonder if it's an EC2 change tickling an existing bug
<wgrant> Could be
<wgrant> I use it so infrequently that I didn't bother to do more than hack it to work.
<cjwatson> wgrant: Much better, thanks
<cjwatson> Grr, these failures didn't show up in ec2, probably because the test runner there apparently hung :-/
<cjwatson> Oh well, should be easy enough to fix
<cjwatson> https://code.launchpad.net/~cjwatson/launchpad/queue-copy-archive-links-testfix/+merge/159442 - test fixes, could use a review
#launchpad-dev 2013-04-18
<StevenK> cjwatson: r=me. I'll land it if you haven't already when I return from breakfast.
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/dump-top-level-yui/+merge/158837 I can't see anything in the deployment stuff that needs the top-level directory
<StevenK> Unsure about buildbot
<wgrant> StevenK: That seems fine, if anything breaks then we'll fix it.
<wgrant> StevenK: You'll want to check that the tree on carob doesn't have it
<wgrant> But I think clean_buildout should remove it, so that'll be fine
 * wgrant disappears for lunch for an hour or so
<StevenK> wgrant: Added a clean_js rule to remove it, with a comment
<StevenK> wgrant: Not landed it yet, I don't know where the built tree on carob is
<wgrant> StevenK: /home/warthogs/archives/rocketfuel-built
<wgrant> IIRC
<StevenK> Right, it has an empty yui directory
<StevenK> wgrant: Strangely, there's a full LP tree under ~lpqateam
<StevenK> Revision 108xx
<wgrant> StevenK: That was used to run the PPR until yesterday
<wgrant> I think it's unused now
<wgrant> It had to be out of date because the PPR was moved to lp-dev-utils
<StevenK> Ah
<wgrant> Yesterday I fixed the lp-dev-utils version and changed the crontab to use it
<StevenK> Ah
<StevenK> wgrant: Should I remove it, or that can wait a few days?
<wgrant> StevenK: Check that nothing in the crontab uses it, and then kill it I guess
<StevenK> DBR=/home/lpqateam/launchpad/utilities/report-database-stats.py -U devpadreports -d launchpad_prod_master -H lp-prod-pgbouncer.internal --limit=30
<StevenK> Not exactly
<wgrant> Ah, that is unfortunate.
<wgrant> So leave it, I guess :)
<StevenK> Yeah, it's not like carob is currently begging for space
<StevenK> wgrant: How does a branch to promote 3.9.1 sound?
<wgrant> StevenK: It's been almost 48 hours, so sounds good.
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/391-by-default/+merge/159546 trivial
<wgrant> StevenK: k
<StevenK> I do not get why the CSS rules are not applied
<wgrant> StevenK: Do you have a branch?
<StevenK> wgrant: For this YUI calendar? Nope
<StevenK> wgrant: I can push one up if you'd like to have a play and hopefully fix some of it
<wgrant> I can hopefully at least fix the CSS
<StevenK> "Note: be sure to add the yui3-skin-sam classname to the page's <body> element or to a parent element of the widget in order to apply the default CSS skin."
<StevenK> Which I've done, but it doesn't help
<StevenK> wgrant: lp:~stevenk/launchpad/new-yui3-calendar it's based off devel as of last week, so you'll likely get an easy to resolve conflict in Makefile
<wgrant> StevenK: I'd avoid destroying yui2 in the same branch, simply to avoid confusing things, but let's see.
<StevenK> I can probably do that pretty easily
<StevenK> wgrant: So we continue building it, but drop it from the combo loader and yuixhr?
<wgrant> StevenK: I'd drop it all in one hit
<wgrant> Dropping it is not a prereq for adding the new calendar.
<StevenK> True
<wgrant> If I want to see what your calendar changes were in a year, I don't want to have to wade through 30000 lines of YUI2 diff that are in the same rev for no reason :)
<StevenK> But I live to make your life hard ... :-P
<wgrant> I know :)
<StevenK> wgrant: Right, done. I can delete current branch and push this small and clean up if you wish
<wgrant> I imagine it's about 1% of the size :)
<wgrant> But I've got your existing one running now
<StevenK> 9.5%
<StevenK> 257 lines versus 26808
<StevenK> wgrant: In the depths of calendar.js, I create a container_div where I set the classes. That was testing a theory, which turned out to be false, but I'm not certain if we care about another level of <div>'s
<StevenK> The Calendar docs do say parent node, but I'm not clear if that's immeadiate parent or up the chain
<wgrant> StevenK: I make that 0.95%, not 9.5%
<StevenK> Oh
<StevenK> Missed a zero
<wgrant> StevenK: Fixed
<StevenK> wgrant: What is the fix?
<wgrant> StevenK: The main CSS is in calendar-base, not calendar
<wgrant> +    <link rel="stylesheet" type="text/css" href="/+icing/yui/calendar-base/assets/skins/sam/calendar-base.css" />
<wgrant> +    <link rel="stylesheet" type="text/css" href="/+icing/yui/calendar-base/assets/skins/sam/calendar-base-skin.css" />
<wgrant> It's still ugly and the nav buttons are oddly unthemed, but it's a bit of an improvement
<StevenK> wgrant: We can include them directly in combo.css if you wish
<wgrant> that might need calendarnavigator stuff
<wgrant> StevenK: Yes, that's what we'll want to do eventuall
<wgrant> Once we work out which bits we need.
<wgrant> Or we could comboload them somehow
<wgrant> Ah
<StevenK> wgrant: It's an extra 130 lines
<wgrant> They get merged.
<wgrant> build/js/yui/assets/skins/sam/calendar-base.css and build/js/yui/calendar-base/assets/skins/sam/calendar-base.css are the same file
<wgrant> So we probably just want to include all the calendar stuff under yui/assets
<wgrant> Oh, only the skin bits end up under there
<wgrant> So we need calendar-core.css and calendar-base-core.css from elsewhere
<StevenK> assets/skins/sam/calendar{,-base,navigator}.css ?
<wgrant> I assume navigator is needed for the month switching arrows
<wgrant> Checking now
<wgrant> The -skin variants seem to be minified
<wgrant> I should probably read some documentation
<wgrant> I wonder if the stuff in yui/assets/skins/sam is concatenated core and skin
<wgrant> Yeah
<StevenK> I think it's tiny enough to go into combo.css
<wgrant>     <link rel="stylesheet" type="text/css" href="/+icing/yui/assets/skins/sam/calendar-base.css" />
<wgrant>     <link rel="stylesheet" type="text/css" href="/+icing/yui/assets/skins/sam/calendar.css" />
<wgrant>     <link rel="stylesheet" type="text/css" href="/+icing/yui/assets/skins/sam/calendarnavigator.css" />
<wgrant> That should be all we need
<wgrant> Though the navigator buttons have now entirely disappeared, that's possibly because they're not enabled?
<wgrant> Ah, no, the skin replaces the < and > with background images that don't display, because the nodes end up contentless
<wgrant> StevenK: Are you more on track now?
<wgrant> StevenK: And do you understand how skins work now? Each component's -core and -skin files are combined into a single file that ends up under yui/assets/skins/foo
<StevenK> Right
<StevenK> Why don't the background images display?
<wgrant> I suspect because the sole node inside them is display: none, so the node has no size.
<wgrant> It may work better if the core sam stuff is loaded
<wgrant> But it's not clear whether we actually want to use that.
<wgrant> StevenK: Ah
<wgrant> I think it's our obsolete grid CSS
<wgrant> Setting display: inline-block gets the images to show
<StevenK> Are they both on the left and cut off?
<wgrant> (we're still using 3.0.0preSOMETHING grids, I assume because 3.0.0 final changed them incompatibly)
<wgrant> StevenK: Not if you set display: inline-block on the header
<StevenK> You're hacking that in using firebug?
<wgrant> StevenK: Using Chromium's dev tools I added .yui3-u { display: inline-block }
<StevenK> Ah.
<StevenK> If I edit the header div to add style="display: inline-block" I get both buttons, but they're both on the left
<wgrant> StevenK: Yes, due to how inline-block works it needs to be on the parent.
<wgrant> I think the only yui3-u might be the "April 2013" header text
<wgrant> So try setting it there.
<StevenK> No, the two a's are also yui3-u
<wgrant> So they are.
<wgrant> Oh
<wgrant> We can probably include the modern CSS
<wgrant> The modern cssgrids CSS, that is
<wgrant> Since it's all yui3-*
<wgrant> Whereas our old embedded copy is YUI2-style cssgrids, with yui-*
<StevenK> Huh, so it is
<wgrant> I thought they were incompatible
<wgrant> But it seems not
 * StevenK sprinkles in yui/cssgrids/cssgrids.css
<wgrant> A significant improvement
<StevenK> BAH
<StevenK> I had a make run backgrounded
<StevenK> Caught it early enough that it didn't spew processes
<StevenK> wgrant: Indeed, that looks great
<wgrant> StevenK: It's still obese, but that might just be the overlay being too wide to start with?
<StevenK> It looks pretty much exactly like the example
<wgrant> Yeah, setting a width on the yui3-calendar-content makes it much more sensible.
<StevenK> To what?
<wgrant> The main difference is the background colour and the centred ths, and at least the latter is CSS specific to the example page
<wgrant> StevenK: I just set it to 300px to see if it worked.
<StevenK> wgrant: The width can be set for the widget on creation
<wgrant> Ah, right
<wgrant> Indeed, I now see width: 340px on the example.
<cjwatson> StevenK: thanks
<StevenK> cjwatson: Happy to help
<cjwatson> Hmm, is it intentional that, after I upgraded dogfood, https://dogfood.launchpad.net/ubuntu/raring/+queue?queue_state=1 no longer has expanders?
<StevenK> cjwatson: Did you leave the combo_url hack in place?
<cjwatson> yes
<StevenK> cjwatson: Restart the webapp, the JS should work
<StevenK> cjwatson: The combo_url hack includes a revision number which qas doesn't have any more
<cjwatson> thanks, I did wonder if it might be something like that but wasn't sure what the correct target would be
<cjwatson> also: lxc is actually rather tasty once I've got it set up for testing in place of schroot
<cjwatson> I expected it to be more work but more accurate/better; I didn't expect it to actually be less work
<StevenK> I've ignored lxc. My only experience has been with fiddling the Jenkins setup to make use of it
<StevenK> Maybe we should just get +combo configured on mawson
<StevenK> Then we can drop that horrid hack
<cjwatson> ok, why am I getting 503 on everything after restarting the server ...
<cjwatson> ah, I just didn't wait long enough
<cjwatson> yep, expanders back, thanks
<StevenK> cjwatson: Yes, mawson's webapp takes an eon to actually start serving requests
<StevenK> cjwatson: I tend to tail -f the nohup file just so I can know when it's actually going to answer
<cjwatson> when do deployments lock down for Ubuntu release?
<cjwatson> (I actually think that caution is rather less necessary now than it used to be, but perhaps now isn't the time for that debate)
<StevenK> cjwatson: We tend to not want to deploy during release week
<StevenK> But given it's NDT, it might be okay
<wgrant> Deployments are safe now
<wgrant> I wouldn't even suggest avoiding fdts during release week
<wgrant> It's been a very long time since something broke badly
<czajkowski> wgrant: lets not jinx it ;)
<wgrant> cjwatson: Did you use /Running/LXC?
<cjwatson> wgrant: Yes
<StevenK> wgrant: I seem to recall you objecting to +combo on mawson
<cjwatson> wgrant: No hitches at all
<wgrant> StevenK: Only in that I needed it working earlier than I could convince ops to set up convoy
<wgrant> cjwatson: Great, wasn't sure if that still worked
<StevenK> wgrant: convoy is on mawson
<wgrant> StevenK: Installed
<cjwatson> With a raring host, for the record
<wgrant> But not configured in apache
<StevenK> wgrant: Right, but we can probably just get the snippet from qas clagged into mawson
<wgrant> cjwatson: btw, I think that any Ubuntu developer who isn't using LXC is probably missing out
<StevenK> With a path change or two
<wgrant> StevenK: Probably
<wgrant> Feel free to convince ops to do it :)
<cjwatson> Well, it depends what you're doing, but it does seem pretty useful.  I used it seriously for the first time yesterday to debug an Upstart problem
<cjwatson> stgraber has been pimping it at us for a year or more
<wgrant> Until 9 months ago or so it was dreadfully buggy and unstable
<wgrant> But it's great now
<StevenK> wgrant: Sure, but I've forgotten how qas is set up :-)
<czajkowski> cjwatson: the bug you just commented on that seb128 filed is that something you will be working on
<czajkowski> if so waht way do you want it triaged
<cjwatson> not immediately since it has some complex dependencies
<cjwatson> feel free to triage as you would normally do
<wgrant> That's Low at highest
<wgrant> It's tempting to introduce a new priority just to use that :)
<wgrant> A new, lower priority :)
<cjwatson> it's not entirely unimportant for us
<cjwatson> since it just caused a big argument on -release :)
<cjwatson> as I say I personally think we should do this by (a) get build cancellation working reliably (b) make builds auto-supersede cleanly even before the new source publishes, which would be lovely anyway both for Ubuntu and PPAs (c) change our queue handling policy to accept all the uploads for a source at once
<cjwatson> there are a few other possibilities but I think that's the least broken
<wgrant> Quite possibly, but the auto-superseding before the publisher bit will be problematic.
<cjwatson> I assumed it wasn't easy or we'd already be doing it
<cjwatson> But even so :)
<StevenK> wgrant: The overlay seems very attached to being wide
#launchpad-dev 2013-04-19
<StevenK> wallyworld_, wgrant: http://wedontsleep.org/~steven/new-calendar-2.jpg
<wallyworld_> so close
<wallyworld_> pity is has to be inside the overlay though
<wgrant> I think that time thing is in a yui3-g without being inside a yui3-u
<wallyworld_> is there no way it can just be a calendar without needing the overlay?
<StevenK> wallyworld_: The calendar doesn't handle hiding and such, it is designed to be shown in a page
<StevenK> wgrant: I should set the class of the time div to yui3-u?
<wallyworld_> ok. pity. yui's fault i guess
<StevenK> wallyworld_: The docs for Y.Calendar say that popup functionality will be added later
<wgrant> StevenK: Right, if it's inside a yui3-g it needs to be wrapped in a yui3-u (or yui3-u variant)
<wallyworld_> ah ok
<wgrant> yui3-g changes text spacing to make the grid bits fit together better
<wgrant> yui3-u resets it to actually be sane for text
<StevenK> That looks much better
<StevenK> The only thing left on my list is the overlay is too wide
<StevenK> Setting a width below about 415px is ignored
<wgrant> You also really want to remove the calendar outline and background
<wgrant> And centre it in the overlay
<StevenK> wgrant: That's done by a yui3-calendar-content div, can I select it and remove it?
<StevenK> With its children being re-parented, that is
<wgrant> StevenK: Or override the skin
<StevenK> wgrant: For that one div?
<wgrant> StevenK: Probably.
<wgrant> StevenK: I forgot how much is the skin and how much is core
<wgrant> It may be worth just not using the skin at all
<StevenK> wgrant: Removing the skin from the containing div seems to have little effect
<wgrant> StevenK: What do you mean "removing the skin"?
<StevenK> div class="yui3-g" rather than "yui3-skin-sam yui3-g"
<wgrant> Isn't the yui3-skin-sam class on the <body>?
<StevenK> wgrant: There is one on the body as well, yes
<StevenK> That may impact far more than just the calendar
<wgrant> StevenK: Didn't you just add it to the body?
<wgrant> Or was it there originally?
<wgrant> StevenK: Removing it from the div won't do anything if it's on the body.
<wgrant> Any ancestor counts
<StevenK> wgrant: I didn't add it to the body, no
<wgrant> Ah, right, a few of our widgets and the accordion use it
<wgrant> StevenK: Perhaps just add some rules to override the border away
<wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/sharing-icon-fix/+merge/159751
<StevenK> wgrant: The grantee_row.one means it would only find the first and not act on the others?
<wgrant> StevenK: Right. And unlike Storm's .one(), it won't crash if there's more than one.
<StevenK> Right
<StevenK> wgrant: I thought the +sharing stuff had fairly good JS tests, can haz?
<StevenK> wgrant: I am a bad person. "Y.one('.yui3-calendar-content').removeClass(
<StevenK> 'yui3-calendar-content');
<wgrant> StevenK: Won't that completely destyle it?
<wgrant> I'd prefer just adding some LP CSS rules to override the styles
<StevenK> wgrant: No? http://wedontsleep.org/~steven/new-calendar-3.jpg
<wgrant> Ah, I guess the other styles must be on yui3-calendar-header and the like
<StevenK> Yeah
<wgrant> StevenK: Even so, that's far more evil than just overriding the style
<StevenK> But it's evil that works!
<StevenK> wgrant: And I suspect due to the way we are putting the CSS in the METAL macro the calendar CSS is loaded after combo.css
<wgrant> StevenK: You could limit the selector to calendars within an overlay
<wgrant> That both makes sense and should increase the specificity
<wgrant> So your rule overrides even though it's earlier
<StevenK> wgrant: .yui3-pretty-overlay.yui3-calendar-content { ... ?
<wgrant> StevenK: They're not on the same element, are they?
<StevenK> wgrant: No
<wgrant> StevenK: Then that doesn't make sense
<wgrant> You at least need a space :)
<StevenK> ".yui3-pretty-overlay .yui3-calendar-content {
<StevenK> That gets listed second and as overridden by firebug
<wgrant> StevenK: What's the selector on the rule that overrides it?
<StevenK> .yui3-skin-sam .yui3-calendar-content {
<wgrant> Ah
<wgrant> Add .yui3-skin-sam and it will work
<StevenK> Still convinced CSS is black magic
<StevenK> wgrant: Indeed, looks great
<wgrant> A style attribute always wins. After that, basically a tuple of (number of ID references, number of class references, number of element references) is generated for each selector, and the greatest one wins.
<wgrant> So #foo > .foo bar.baz > .foo .baz > .foo > bar
<StevenK> wgrant: Right, so in this case, my background: none, border: none win out, and the selector from calendar-base isn't applied since it would trump a higher rule?
<wgrant> StevenK: The grouping of rules wihin a single selector doesn't matter.
<wgrant> The winner is calculated on a per-attribute basis.
<StevenK> Right
<StevenK> wgrant: Now we just need to center the calendar and I think we're good
<wgrant> So if I have "a {text-align: left; font-weight: bold}; a.normal {font-weight: normal};", an <a class="normal"> will get text-align: left; font-weight: normal;
<wgrant> StevenK: Indeed
<wgrant> A margin: auto; somewhere should do the trick.
<StevenK> style="text-align:center" on the enclosing div?
<wgrant> I'd avoid text-align here, probably.
<wgrant> But it might work.
<wgrant> I haven't looked at the structure created by the calendar widget.
<wgrant> But text-align might work if the container is an inline-block
<StevenK> I'll try margin: auto; on the overlay's body div
<StevenK> wgrant: margin: auto; does not help
<wgrant> StevenK: Are you sure that's on the right element?
<wgrant> It needs to be the top-level uncentered element, and it needs to be a block inside a block
<StevenK> It's the container, which has the calender inside it
<StevenK> The container is then the bodyContent for the overlay
<StevenK> wgrant: Clear as mud?
<wgrant> Poke around and see what works :)
<StevenK> wgrant: In terms of margin: auto, nothing
<StevenK> I've put it on the calendar div itself, the container div, the yui3-overlay-bd div and the yui3-pretty-overlay-content div
<wgrant> StevenK: I've pushed up a test (and fixed an existing test which would have always passed)
<wgrant> StevenK: Thanks.
<StevenK> wgrant: Sorry, got distracted by a phone call, but it did get marked as approve?
<wgrant> Yep
<StevenK> Right, excellent
 * cjwatson tries to understand https://launchpad.net/ubuntu/raring/i386/ubuntuone-couch
<cjwatson> Was that a change-override accident or something?
#launchpad-dev 2013-04-20
<wgrant> cjwatson: https://launchpad.net/ubuntu/raring/amd64/ubuntuone-couch
<wgrant> cjwatson: It was overridden then reverted
<wgrant> But only amd64 got the third pub, apparently.
<wgrant> Hm, no, overriden twice the same way
<wgrant> This is what you get when you write RDBMS-based code that assumes exclusive access...
<stokachu> im trying to do an api call on a search task for a project and its giving me an 400 URL must be absolute error http://paste.ubuntu.com/5723110/, this seems to only happen when i use the assignee query param with a uri encoded self link
<stokachu> do i not include the api url in there?
<wgrant> stokachu: Why's there no leading / on that whole URL?
<wgrant> 'ubuntu-advantage' is not a valid path
<wgrant> '/ubuntu-advantage' is
<stokachu> thats just the query params
<stokachu> ah
<stokachu> the entire url is https://api.launchpad.net/1.0/ubuntu-advantage....
<wgrant> Ah
<wgrant> An odd way to construct it :)
<stokachu> i think it gets dropped during the debug output
<stokachu> it works if i drop assignee=...
<wgrant> That URL works fine
<wgrant> So your code is probably double-encoding it before sending it, or something
<wgrant> https://launchpad.net/api/devel/ubuntu-advantage?assignee=https%3A%2F%2Flaunchpad.net%2Fapi%2Fdevel%2F~adam-stokes&ws.size=5&ws.op=searchTasks
<wgrant> Try that in a browser
<stokachu> hmmmmm so it does work
<stokachu> i bet you i am encoding it twice
<stokachu> but the query params look correct in the debug output... i need to investigate further
<wgrant> However
<wgrant> That HTTP status looks like it's talking about the path, not the query string.
<wgrant> Regardless, I'd dump the request that I sent and fix the obvious problem with it.
<stokachu> ok ill do that, thanks for the second set of eyes
<cjwatson> wgrant: Can you think of a way to resurrect ubuntuone-couch short of a new upload?
<wgrant> cjwatson: Delete and copy
<wgrant> Or just copy
<wgrant> It'll pick all the built binaries that were every published.
<wgrant> ever
<stokachu> OOPS-674f4d9f8243733af32d6ca81c67fc10
#launchpad-dev 2013-04-21
<nigelb> wgrant: Happy Birthday!
#launchpad-dev 2014-04-17
<Felix_Lin> Nice to meet you all in the launchpad-dev channel
<Felix_Lin> I am Felix_Lin from CKT test team
<Felix_Lin> ha, everybody is busy. Have a good day.
#launchpad-dev 2014-04-20
<xnox> why is launchpad's wadl not like everybody else's wadl? =)
#launchpad-dev 2015-04-13
<sil2100> cjwatson: yaay, saw the getLatestSourcePublication() merge getting approved and merged, finally I get get rid of all my http-abusing workarounds
<sil2100> Thanks guys
<sil2100> :)
<cjwatson> sil2100: excellent :)
<cjwatson> git fanfic: http://hirez.livejournal.com/497893.html
<lifeless> blink
#launchpad-dev 2015-04-15
<wgrant> cjwatson: pkgbinarymangler's dpkg-deb is checking for debian/control, but shouldn't it be DEBIAN/control?
<cjwatson> wgrant: It'd have to do something fancier to get the source name in that case.
<cjwatson> dpkg-parsechangelog relies on being in the source directory.
<wgrant> Oh, right, it assumes it's running in the source dir.
<wgrant> That is awful!
<cjwatson> We should be able to get that from DEBIAN/control just as well, though.
<cjwatson> But that would be a pitti thing, and we'd have to SRU that ...
<wgrant> It's not fatal, just noisy.
<wgrant> I guess we could adjust sbuild to pretend to have a source dir.
<cjwatson> Or we could hack it to set NO_PKG_MANGLE or whatever it is.
<wgrant> True.Oh, yeah, it does checkit at the top.
<wgrant> I guess we might as well do that in vivid too?
<cjwatson> wgrant: Possibly.
<cjwatson> wgrant: It feels icky because it's an Ubuntu-specific thing.
<cjwatson> Would be nice to find some other way ...
<cjwatson> (Assuming you mean the sbuild change)
<wgrant> Yeah
<wgrant> But how?
<cjwatson> Make pkgbinarymangler get that information from DEBIAN/control instead and not rely on being run from a source directory.
<cjwatson> And either SRU that everywhere or not care about the noise.
<wgrant> Well, yeah, but SRUs :)
<wgrant> Right
<cjwatson> Or we could just put this in LP's sbuild.
<cjwatson> Dunno what I think of a one-line fork there.
<wgrant> It's the only local change we appear to need, apart from the backport bits.
<wgrant> And it doesn't seem unreasonable to have an Ubuntu-specific change in Ubuntu's sbuild...
<cjwatson> Yeah
<cjwatson> Maybe.  But I'd been hoping to be able to sync sbuild once we figured out how to deal with the debfoster thing.
<cjwatson> Which there's a Debian bug about as well, because people want to run sbuild-createchroot for Ubuntu on Debian.
<wgrant> Fixing pkgbinarymangler is clearly the correct solution.
<wgrant> And I guess we could just not care about old series.
<cjwatson> NO_PKG_MANGLE is harmless on Debian, I just like to be cautious about introducing Ubuntuisms ...
<wgrant> Yup.
#launchpad-dev 2015-04-16
<blr> cjwatson: +bug/1445017 if you'd like to link your recent branches
<mup> Bug #1445017: Support for Launchpad Git merge proposals  <branches> <git> <lp-code> <Launchpad itself:New> <https://launchpad.net/bugs/1445017>
<cjwatson> blr: I have bug 1444591 for subscriptions, but will probably use yours once I get out of things I can describe as part of that
<mup> Bug #1444591: Allow Git repository subscriptions <Launchpad itself:In Progress by cjwatson> <https://launchpad.net/bugs/1444591>
<cjwatson> blr: if you're watching dbupgrade.log, 2209-53-9 is going to take ages to apply, but that's OK because it was done live with CONCURRENTLY
<blr> cjwatson: ah, was wondering why it was a bit slow
<cjwatson> partly also that it did a staging code update first
<cjwatson> 2015-04-16 16:21:27,217 INFO    2209-61-3 applied just now in 0.3 seconds
<cjwatson> so anyway that's fine
<blr> cjwatson: something would be very wrong if that patch didn't apply quickly! :)
<cjwatson> should be on the deployment report shortly, and then you can mark that qa-ok
<cjwatson> http://lpqateam.canonical.com/qa-reports/deployment-db-stable.html
<blr> cjwatson: excellent, thanks
#launchpad-dev 2017-04-18
<newbie> Hi guys... I want to setup a local Launchpad server for production.. are there any instructions???.. I have found this: https://dev.launchpad.net/Running.. but it only seems to be for development....
#launchpad-dev 2017-04-19
<rajsagar> hello everyone
<master__> hello
<newbie|9> Hi guys...   I want to setup a local Launchpad server for production.. are there any instructions???..   I have found this: https://dev.launchpad.net/Running.. but it only seems to be for development....
<newbie|9> When trying to set it up, I get a: /opt/test/stable/lib/lp/app/browser/../templates/root-index.pt
<newbie|9> Line 72, Column 14
<newbie|9> Expression: <PathExpr standard:u'view/apphomes'>
<newbie|9>    - Names:
<newbie|9>       {'args': (),
<newbie|9>        'context': <lp.services.webapp.publisher.RootObject object at 0x7f1877d0b810>,
<newbie|9>        'default': <object object at 0x7f187e0e8430>,
<newbie|9>        'loop': {},
<newbie|9>        'nothing': None,
<newbie|9>        'options': {},
<newbie|9>        'repeat': {},
<newbie|9>        'request': <lp.services.webapp.servers.LaunchpadBrowserRequest instance URL=https://launchpad1.phaseone.com/index.html>,
<newbie|9> Anyone here???
<cjwatson> newbie|9: I can only really repeat what I said on launchpad-dev: https://lists.launchpad.net/launchpad-dev/msg09809.html
<cjwatson> I'd need to see the full traceback to debug whatever you're currently seeing (in a pastebin or something, not just pasted into IRC)
<newbie|9> Pastebin: https://pastebin.com/QH01TpjV
<newbie|9> <-- traceback
<newbie|9> Seems like it can be traced back to the canonical_url function..
<newbie|9> I think I read something, someplace, that the "base" ubuntu branch has to be set in some way???
<cjwatson> If you're running with a completely empty database then you're probably missing some of the "celebrities" that the Launchpad code relies on.
<cjwatson> The "ubuntu" distribution is indeed one of those.
<newbie|9> ahhh... ok.. and how do I generate these???
<newbie|9> I have just run the "make schema"
<cjwatson> make schema will give you sampledata, which is insecure for a new production instance.  I'm not aware of any documentation on setting up a new non-development instance entirely from scratch.
<cjwatson> It would probably involve manual fiddling with psql ...
<newbie|9> But "make schema" should provide the celebrities????
<cjwatson> lib/lp/app/utilities/celebrities.py has the list of celebrities that exist.
<cjwatson> It will, yes, but it will also provide other things that aren't suitable for an instance on the internet.
<newbie|9> We'll sort that out, but apparently the celebrity is still not there...
<cjwatson> Like a bunch of template accounts ...
<cjwatson> I've never seen anyone sort that out successfully when starting from sampledata.
<cjwatson> What are you actually trying to do?
<newbie|9> for now, just setting up the development...
<newbie|9> and then hardening...
<cjwatson> Right, but what's your actual goal?
<cjwatson> Having your own Launchpad instance is a pretty gigantic sledgehammer, and most nuts can be cracked with something a bit smaller.
<newbie|9> For our Red Hat customers we are using COPR, for our SLES customers we are using OBS.. So we just want something similiar for our Ubuntu Customers
<cjwatson> So, like I said on launchpad-dev, our practical purpose in open-sourcing Launchpad was mainly to make it easier for people to help with improving launchpad.net.  For setting up your own instance you're basically on your own.
<cjwatson> It might be worth inserting 'import pdb; pdb.set_trace()' into the apphomes method in lib/lp/app/browser/root.py and seeing where it's going wrong exactly.
<cjwatson> Then e.g. trying to evaluate getUtility(ILaunchpadCelebrities).ubuntu to see if it's that.
<cjwatson> If it actually is something inside canonical_url then you can step into that and try to narrow it down a bit.
<cjwatson> Given that you've started from sampledata it's probably something fairly simple, since that normally does work out of the box.
<newbie|9> Ok.. so where did you what to enter getUtility(ILaunchpadCelebrities).ubuntu??
<cjwatson> At the pdb prompt after you make a request
<cjwatson> 'import pdb; pdb.set_trace()' is a breakpoint
<newbie|9> And I would do that, just before using canonical_url?? or in the canonical_url method
<cjwatson> Before.
<cjwatson> The idea is to try to figure out which part of the apphomes method is raising an exception.
<cjwatson> If you don't already know how to drive pdb, you are going to need to learn.
<newbie|9> ok.. thanks...
<newbie|9> I get a: "expected a string or other character buffer object" on getUtility(ILaunchpadCelebrities).ubuntu)... line 111 in lib/lp/app/browser/root.py...
<cjwatson> p repr(getUtility(ILaunchpadCelebrities).ubuntu)
<newbie|9> (Pdb) p repr(getUtility(ILaunchpadCelebrities).ubuntu)
<newbie|9> *** TypeError: TypeError('expected a string or other character buffer object',)
<cjwatson> uh
<MrMEEE> ? a little weird?
<cjwatson> from lp.registry.interfaces.pillar import IPillarNameSet
<cjwatson> p getUtility(IPillarNameSet).getByName('ubuntu')
<cjwatson> (should print "<Distribution 'Ubuntu' (ubuntu)>")
<MrMEEE> (Pdb) from lp.registry.interfaces.pillar import IPillarNameSet
<MrMEEE> (Pdb) p getUtility(IPillarNameSet).getByName('ubuntu')
<MrMEEE> None
<MrMEEE>  
<MrMEEE> nope
<cjwatson> Then I don't believe that you're running against the database produced by make schema.
<cjwatson> Have a look with psql (the default database name is launchpad_dev, but you should check with psql -l in case you're actually using something else): SELECT id FROM distribution WHERE name = 'ubuntu';
<cjwatson> sampledata contains that with id 1
<cjwatson> The database name is set in the [database] rw_main_master and rw_main_slave keys in launchpad-lazr.conf
<MrMEEE> Haven't touched it after..... Ipostgres=# \c launchpad_dev
<MrMEEE> You are now connected to database "launchpad_dev" as user "postgres".
<MrMEEE> launchpad_dev=# SELECT id FROM distribution WHERE name = 'ubuntu';
<MrMEEE>  id
<MrMEEE> ----
<MrMEEE> (0 rows)
<MrMEEE>  
<cjwatson> Well, you'll need to work out why make schema didn't put sampledata in place then
<cjwatson> Or else inject the right set of celebrities yourself
<MrMEEE> I got this first...: https://pastebin.com/7eY17e3c
<MrMEEE>  
<MrMEEE> and then I ran "sudo -u postgres make create"
<MrMEEE> but ok... I'll look into the sampledata
<cjwatson> Ah.  That would have been useful to know an hour ago.
<cjwatson> You shouldn't run make schema as root.
<cjwatson> In general you shouldn't run anything Launchpaddish as root.
<MrMEEE> Ok.. sry.. It just said that I could run "sudo -u postgres make create"...
<MrMEEE> so I presumed that it didn't matter
<cjwatson> Yeah, but it shouldn't have failed in the first place.
<cjwatson> And the message is a bit misleading.  It's only saying how to make that *particular* bit of the Makefile work, but there's more to it than 'make create'.
<MrMEEE> Ok.. I'll try as a normal user... and see what happens
<MrMEEE> Thanks
<cjwatson> Anyway, utilities/launchpad-database-setup sets things up with a DB user corresponding to the mortal user you run it as.
<cjwatson> You should run that (as non-root) if you haven't already.
<cjwatson> And you'll probably need to chown all sorts of things now ...
<cjwatson> I suspect your problem is in fact not having run launchpad-database-setup ...
<MrMEEE> ok
#launchpad-dev 2017-04-20
<jlh> Hey guys
<jlh> I'm trying to get the dev version running
<jlh> but I get this error
<jlh> 192.168.20.168 - "" "192.168.20.163:8085" [20/Apr/2017:13:01:20 +0200] "GET /@@/search HTTP/1.1" 404 10463 3 0.0857479572296 12 0 "" "" "http://192.168.20.163:8085/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0"
<jlh> ------
<jlh> 2017-04-20T13:01:20 ERROR SiteError http://192.168.20.163:8085
<jlh> Traceback (most recent call last):
<jlh>  File "/home/bob/launchpad/devel/eggs/zope.publisher-3.12.6-py2.7.egg/zope/publisher/publish.py", line 132, in publish
<jlh>    result = publication.callObject(request, obj)
<jlh>  File "/home/bob/launchpad/devel/lib/lp/services/webapp/servers.py", line 1535, in callObject
<jlh>    raise NotFound(self, '', request)
<jlh> NotFound: Object: <lp.services.webapp.servers.ProtocolErrorPublication object at 0x7fa7c034acd0>, name: ''
<wgrant> jlh: LP uses vhosts extensively, so you can't access it by IP address.
<jlh> I'ts running on my vm
<jlh> So I use the IP to access the vm
<wgrant> You'll need to configure your /etc/hosts or DNS server to point at least launchpad.dev and testopenid.dev at that IP address.
<jlh> I did, on the VM
<wgrant> That's not going to do you much good if you're doing the lookups from a browser outside the VM.
<jlh> launchpad.dev is a real thing? not just for my local instance?
<wgrant> launchpad.dev is the default vhost that a development Launchpad instance expects the browser to ask for.
<jlh> Oh!
<jlh> I'll try that. Thanks! I'll return in a bit
<wgrant> The setup scripts add that to /etc/hosts, but that doesn't help if you're running it in a VM.
<jlh> Thank you for your time wgrant
<wgrant> jlh: np
<jlh> wgrant: It works!
<jlh> You are a wizard
<wgrant> jlh: Excellent.
#launchpad-dev 2017-04-21
<MrMEEE> Hi guys.. I have deployed the locally hosted launchpad.dev (tried to change the hostname) and now get an error when I try to login with the admin@canonical.com user.... https://pastebin.com/BFXnZxaC..  basically the error is: ForbiddenAttribute: ('developers', <Product at 0x7fa410fde5d0>)... any ideas???
<wgrant> MrMEEE: You've changed the code. That line should specify celebrities.launchpad_developers, not celebrities.launchpad.developers.
<MrMEEE> ahhh. thank...
<MrMEEE> wrong search-replace
#launchpad-dev 2020-04-15
<tomwardill> some more words to make the people merge page a bit less scary (to me at least): https://code.launchpad.net/~twom/launchpad/+git/launchpad/+merge/382274
<cjwatson> tomwardill: LGTM, couple of additional suggestions
<tomwardill> ah, ta
 * tomwardill fixes
<tomwardill> changed and landing
<cjwatson> pappacena: http://lpbuildbot.canonical.com/builders/lp-devel-xenial/builds/1183/steps/shell_9/logs/summary (skipping the transient failure) is yours I think
<cjwatson> tomwardill: There may actually be zero test fallout from fixing getUniqueURL to use .test or similar.  None of the matches for domain.com look like they were generated by it
<tomwardill> cjwatson: excellent, I'll do that after I've done this credentials work then
<cjwatson> tomwardill: https://tools.ietf.org/html/rfc2606.html is the canonical reference for this kind of thing if you don't have it already
<tomwardill> cjwatson: how do I create a new distribution in my test instance?
<tomwardill> ah, no matter, did it
<tomwardill> ( /distros/+add for future travellers )
<cjwatson> Didn't know offhand anyway :)
<cjwatson> tomwardill: Could you request a new build of https://dogfood.paddev.net/~twom/ubuntu/+oci/test-oci-project-1/+recipe/test-oci-recipe-2, and tell me when you've done so so that I can get in quickly and strace it?
<cjwatson> Not sure if this will work but let's see
<tomwardill> on it now
<tomwardill> cjwatson: requested
<cjwatson> Bother, too slow
<cjwatson> I'll make my own version :)
<cjwatson> Better than bothering you all the time
<tomwardill> righto :)
<tomwardill> I think only the API exists on that version to create an OCI Project
<cjwatson> I used the same project
<cjwatson> same OCI project rather
<tomwardill> ah, of course
 * tomwardill tries to work out how to create a DAS for a new distribution
<wgrant> tomwardill: +addseries, then +addport on that
<tomwardill> wgrant: hmm, that gets me a series/distro page that looks right, but no architectures selectable when I try and create a build from my recipe
<wgrant> tomwardill: Ah, you might need to set supports_virtualized on the Processor (needs DB hackery), or unset require_virtualized on the recipe
<wgrant> It's also possible we check presence of a chroot to create the checkboxes, but I forget.
<cjwatson> tomwardill: Well, it's definitely sending correct-looking proxy basic auth.  Will need to dig through the proxy rules
<cjwatson> Ah, I think this is just that the staging proxy was out of date with the spec
<cjwatson> tomwardill: https://dogfood.paddev.net/~cjwatson/ubuntu/+oci/test-oci-project-1/+recipe/test-oci-recipe-1/+build/5
<cjwatson> Worked fine once I upgraded the staging proxy to have https://bazaar.launchpad.net/~canonical-launchpad-branches/canonical-mojo-specs/trunk/revision/284.  Production was done a while ago (https://portal.admin.canonical.com/C122738/)
<tomwardill> wwooo!
<tomwardill> well, that's quite exciting
<cjwatson> pappacena: Did you see my message earlier about the buildbot failure?
<pappacena> uhm, I think I missed it. I'll check buildbot
<cjwatson> Probably a one-liner :)
<pappacena> It seems so. :-)
<pappacena> I'll open a MP
<pappacena> Quick review? https://code.launchpad.net/~pappacena/launchpad/+git/launchpad/+merge/382316
<pappacena> Well, since it's simple test change, I'll self-approve it. The test is running find on my machine now.
<tomwardill> hah, I was just looking at it pappacena :)
<cjwatson> Sorry, was reviewing another thing of yours :-)
<tomwardill> my laptop is not the fastest to load a page atm
<cjwatson> Self-approving trivial test fixes like that is fine
<pappacena> tomwardill, cjwatson. Thanks :-)
<tomwardill> cjwatson: bit lost in the ObjectModifiedEvent change, what would be the changed fields on a build for a create() method?
<tomwardill> oh, wait, there's an ObjectCreatedEvent, that seems more like what I'd be after
<tomwardill> or could do ObjectModifiedEvent with field of status
<tomwardill> which hooks better into the rest of the lifecycle
<cjwatson> tomwardill: create should use ObjectCreatedEvent, yes
<cjwatson> Assuming the notified object is the object being created
<tomwardill> cjwatson: as in 'the object that we are notifying a subscriber about'?
<tomwardill> I can't quite parse that sentence
<tomwardill> okay, think I got it
<cjwatson> Right, if you're doing notify(SomeEvent(obj)) and the notification is to the effect that obj was just created, then ObjectCreatedEvent is right
<tomwardill> yeah, that makes sense
#launchpad-dev 2020-04-16
 * tomwardill gets lost in a maze of webhooks
<tomwardill> some of these are alike, but not all
<cjwatson> Oh it would probably help if the lp-signing charm ran DB migrations, such as the one to create the DB
<cjwatson> However I was about to want to change a bit of the schema anyway ...
<cjwatson> Quite convenient
<tomwardill> hahaha
<tomwardill> Ran 1 tests with 0 failures, 0 errors, 0 skipped in 1.176 seconds.
<tomwardill> a working lifecycle, notify and webhook test!
<cjwatson> for recipes?
<tomwardill> registry upload job
<tomwardill> with the ObjectModifiedEvent and _do_lifecycle changes you suggested
<cjwatson> Ah right, was just wondering how you were managing to test webhooks
<cjwatson> Given that we don't have OCI recipe webhooks yet
<tomwardill> we do for OCIRecipeBuild
<tomwardill> which is enough here
<cjwatson> Oh, so we do, ignore me
<cjwatson> Completely forgot even doing that myself
<tomwardill> hah :)
<cjwatson> Top programming tip: base64.b64encode != base64.b64decode
<tomwardill> done the same thing, many times :)
<tomwardill> i find those really hard to read/parse
<cjwatson> https://code.launchpad.net/~cjwatson/lp-signing/+git/lp-signing/+merge/382413   in which Colin cheats at databases
<tomwardill> errr... https://pastebin.canonical.com/p/KNRZm3Qwvj/
<cjwatson> A single recipe might have multiple registry upload jobs, no?
<cjwatson> A single recipe build, even
<tomwardill> cjwatson: it can, but it definitely does not in this case (the raising code is: self.assertContentEqual([job], ocibuild.registry_upload_jobs) )
<cjwatson> Hopefully pdb will enlighten
<tomwardill> yeah, turned out to be an error elsewhere
<tomwardill> ironically it was failing in the _run_fails test
<tomwardill> but not in a way I wanted
<tomwardill> cjwatson: https://code.launchpad.net/~twom/launchpad/+git/launchpad/+merge/381981 is ready again
<cjwatson> Thanks, will look
<tomwardill> starting to feel a lot more complete now the lifecycle stuff is hooked up
<tomwardill> but there is still plenty missing, I'm sure.
<tomwardill> it occurs to me that might need a rebase
 * tomwardill does that
<tomwardill> (first, tea)
<tomwardill> it does, it needs teh getFileByName changes
 * tomwardill does them
<tomwardill> (now, with tea)
<cjwatson> ilasc: One remaining comment on https://code.launchpad.net/~ilasc/turnip/+git/turnip/+merge/377045; after that I think it can land, since the LP side is on production
<ilasc> cool, thanks Colin
<tomwardill> branch rebased
<tomwardill> cjwatson: if my local instance is generating OOPS (from running a job), is there any way I can see them?
<cjwatson> tomwardill: See if they're in /var/tmp/lperr
<cjwatson> tomwardill: If they aren't, try setting error_exchange: none in [error_reports] in the config
<cjwatson> tomwardill: If all else fails, grit your teeth and strace, but it shouldn't normally be needed
<tomwardill> {"repositories":["busybox","pjdc/registry-2","registry","test-wget-image","twom/base_with_curl","twom-test/test-wget-image"]}
<tomwardill> and that's an image on staging rocks
<tomwardill> (multiple times in fact, because tomwardill is an idiot sometimes)
<tomwardill> cjwatson: getting "amqp.exceptions.AccessRefused: Exchange.declare: (403) ACCESS_REFUSED - operation not permitted on the default exchange" running tests, any ideas?
<cjwatson> tomwardill: which TestCase class are you using?
<tomwardill> it's happening to tests that worked perfectly well a couple of hours a go (including most of the existing oci tests)
<cjwatson> Um.  Bounce rabbitmq-server in your container maybe?
<cjwatson> Check for stray processes?
<tomwardill> I just restarted the whole container
<tomwardill> this is a bit weird
<cjwatson> Or that
<cjwatson> I'm not very good at administering rabbit; I tend to just nuke it from orbit if it gets weird
<tomwardill> I've tried a complete reboot and a `sudo pkill -f rabbit`, still got the same problem
<cjwatson> (The reason I ask about TestCase is stuff like https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/376996)
<cjwatson> Oh also did you perhaps leave error_exchange: none in your config?
<tomwardill> oooh
<tomwardill> that'd do it
<cjwatson> It's a bit of a pain.  I assume it would be possible to handle some other way by running bits of python-oops-amqp or something ...
<tomwardill> yep, that'd do it
<tomwardill> working now
<tomwardill> ta
<cjwatson> I usually just try to reproduce in the test suite instead because then CaptureOops takes care of it
<tomwardill> well, the tests are broken, but broken in a way that I now understand
 * cjwatson tries to get through another review before EOD
<tomwardill> as much as I like mock, it's not the easiest thing int he world to assert against it's call arguments
<cjwatson> Yeah, almost all of those things involve digging through stacks of tuples
<tomwardill> follow on MP that adds auth handling to registry push: https://code.launchpad.net/~twom/launchpad/+git/launchpad/+merge/382439
<tomwardill> except that security.cfg change should be in the prerequisite
 * tomwardill moves it
<tomwardill> except, no it probably doesn't need to exist, it's due to the subscriber bug :)
<tomwardill> okay, fixes made and branch pushed
 * tomwardill calls that EOD
#launchpad-dev 2020-04-17
<tomwardill> cjwatson: if you get 5 mionutes, can you have a look at https://git.launchpad.net/~twom/launchpad/commit/?id=8215dfdeeafb07ed27722bcf51b93450df6bbd92 and check I've not done a silly before I merge it
<cjwatson> tomwardill: looks exactly right
<tomwardill> cool, landing that then, the RT for the DB users went in over night
<tomwardill> s/went in/completed
<cjwatson> Could anyone review https://code.launchpad.net/~cjwatson/lp-signing/+git/lp-signing/+merge/382413 for me please?
<cjwatson> Maybe wgrant actually, since it is crypto
<cjwatson> crypto *and* a cheaty DB change
<SpecialK|Canon> heh
<wgrant> I already judged you for the sneaky DB change this morning, don't worry
<wgrant> I'll look in a bit
<cjwatson> Thanks
<tomwardill> landing the push credentials branch
<tomwardill> and with that, modulo some api/ui bits, we should be able to end-to-end an OCI image into ROCKS
 * tomwardill finds the rum
<cjwatson> \o/
<cjwatson> Mainly just Ioana's push rule UI stuff at this point, right?
<tomwardill> yep, think so
<tomwardill> I'll start on the API side of that this afternoon/monday
<tomwardill> okay, with some buildbot poking, both of those branches should be landed
<pappacena> Anyone available for a quick review to fix a broken test? It's just one line affecting 4 small test cases, but I would like more eyes on it, to make sure I didn't miss anything: https://code.launchpad.net/~pappacena/launchpad/+git/launchpad/+merge/382506
<tomwardill> pappacena: I'm not familiar with the code, but would altering the factory method to set the BugAttachement owner to be the given bug's owner also work?
<cjwatson> I'm a bit suspicious of a requirement for the bug attachment owner to be the bug reporter
<cjwatson> It doesn't seem to totally make sense
<cjwatson> So I don't think that would be a good factory default
<cjwatson> Let me look at the test failures ...
<pappacena> It's failing because it tries to change attachment's title with another user (it used to be allowed, and now it's not)...
<pappacena> I can just change that specific test to login with bug attachment's owner, I think...
<cjwatson> pappacena: Instead of this, try changing login_person(self.bug_owner) on line 43 to login_person(self.bug_attachment.owner)
<cjwatson> I think that would be cleaner
<cjwatson> pappacena: Oh and also on line 63
<pappacena> Yes, that was my second option... :)
<pappacena> Let me do it
<cjwatson> (It is unfortunate that the bug reporter is called "owner")
<pappacena> uhm... actually, changing line 63 doesn't seem to be needed... the test passes today oO
<cjwatson> Yeah, I'm not sure why
<cjwatson> Might be worth a brief bit of debugging
<cjwatson> Oh, I see
<cjwatson> createToken is on View, not Edit, so ViewBugAttachment applies
<cjwatson> And the bug "owner" is currently always allowed to view attachments
<cjwatson> So yeah, I think it's OK to leave 63 alone
<pappacena> Good. Let me just fix the line 43, them
<pappacena> n
<pappacena> Done: https://code.launchpad.net/~pappacena/launchpad/+git/launchpad/+merge/382506
<cjwatson> r=me
