[00:35] <bdmurray> allenap: we said 7:30 yes?
[00:35] <allenap> bdmurray: Yep.
[00:55]  * jml is back
[01:20] <bdmurray> Is anyone running launchpad on lucid?
[01:20] <bdmurray> I'm having an issue with make schema and tickcount not importing
[01:21] <jml> bdmurray, maxb is, I think
[01:21] <jml> I guess I ought to upgrade.
[01:21] <jml> bdmurray, wgrant might be running on lucid too
[01:21] <wgrant> I'm running lucid.
[01:22] <wgrant> bdmurray: Make sure that you have the ~launchpad PPA for lucid activated.
[01:22] <wgrant> That should work, although you might need to downgrade python-pkg-resources and python-setuptools to their karmic versions (if you get errors about 'distribute')
[01:23] <bdmurray> wgrant I do have the launchpad ppa
[01:23] <wgrant> bdmurray: Which version of python-tickcount do you have installed?
[01:24] <bdmurray> 0.1-0ubuntu10launchpad1
[01:24] <wgrant> Hmmm.
[01:24] <bdmurray> I think it has to do with the python path
[01:25] <wgrant> It's more likely that your python-support hates 2.5.
[01:25] <bdmurray> and tickcount being in /usr/lib/pyshared?
[01:25]  * wgrant checks stuff.
[01:26] <wgrant> bdmurray: What if you remove and reinstall python-tickcount?
[01:27] <wgrant> python-support should be happy :(
[01:28] <bdmurray> wgrant: I tried downgrading to the one in universe and installing the ppa one would that count?
[01:28] <wgrant> bdmurray: Probably, but maybe not.
[01:28] <wgrant> bdmurray: Which versions of python-defaults and python-support do you have?
[01:29] <maxb> Hmm, that reminds me, I should merge my python-defaults change forward to lucid
[01:30] <maxb> Need to reboot into lucid to test that properly, though :-/
[01:31] <bdmurray> wgrant: I've got to run but that didn't sort it either
[01:31] <bdmurray> wgrant: thanks though
[02:05] <stub> 11 hours is a little long for a test run....
[02:05]  * stub wonders wtf his ec2 instance has been doing all night.
[02:08] <jml> stub, wrt kfogel's master_affects patch, I think they were also going to use it to correctly calculate the number of users affected by a bug
[02:08] <jml> stub, which isn't an offline task
[02:08] <stub> It still isn't necessarily a performance issue
[02:11] <stub> It is a use case for PG 8.4's hierarchical queries though...
[02:11] <stub> w00t. My ec2 instance looks crashed. ssh and http unresponsive, but still listed as running in elasticfox.
[02:16] <stub> jml: There is already the Bug.users_affected and Bug.users_unaffected cache columns, so affected counts don't need to be calculated on the fly.
[03:04] <maxb> Can someone hit retry on this for me, please? https://edge.launchpad.net/~launchpad/+archive/ppa/+build/1453105
[03:17] <spm> maxb: done
[03:17] <wgrant> I have a small branch from last week that makes some tests fail (inheriting from a new interface for security reasons, while the class still doesn't implement some of the attributes). Can I get that reviewed on its own now, and just land the subsequent branch which unbreaks things? Together they exceed the limit, and will be somewhat more difficult to review.
[03:31] <stub> wgrant: I think two separate merge proposals is encouraged, and the 'dependent branch' field when registering a merge proposal added to make things even easier.
[03:31] <wgrant> stub: Yep, I made a lot of use of that field last week...
[03:31] <wgrant> Thanks.
[03:39] <bdmurray> wgrant: so a new python-support fixed it
[03:40] <wgrant> bdmurray: Great.
[07:04] <stub> Bah. Too many devs infecting my timezone. PQM is backed up :-P
[07:04] <stub> GET OFF MY LAWN!
[07:20] <al-maisan> :)
[08:49] <stub>     ImportError: No module named builder.recipe
[08:49]  * stub kicks db-devel, and wadl generation in general
[08:49] <mrevell> Morning
[08:59] <stub> Anyone else seen that? db-devel won't build locally for me.
[09:01] <bigjools> I'll try
[09:11] <bigjools> wgrant: around?
[09:12] <bigjools> stub: fails for me too
[09:25] <stub> bigjools: No idea why it is working for buildbot.
[09:27] <bigjools> me neither
[09:35] <bigjools> stub: starting up dogfood gives me "database does not have a main_slave key."
[09:35] <bigjools> que?
[09:36] <bigjools> and "main_master"
[09:37] <stub> bigjools: Sounds like you need to update the config file, but I'm not sure how you would get that particular error - if those keys are not set, you should be pulling in the defaults from lib/canonical/config/schema-lazr.conf (which would attempt to connect you to the production database, and fail)
[09:37] <bigjools> so I guess someone added config items and forgot about DF
[09:38] <bigjools> I have a bad feeling about this week
[09:38] <stub> This is old though...
[09:38] <bigjools> really?
[09:38] <stub> Yer - since we have had replication. Months and months.
[09:38] <bigjools> it only started happening after I just pulled db-devel into DF
[09:38] <bigjools> I last did that last Friday
[09:39] <bigjools> or maybe Thu
[09:39] <stub> since it because a pain in the bum to restore the db dumps in fact, so I know those keys have been needed on df before.
[09:39] <stub> Hmmm...
[09:40] <stub> The losas might remember the magic command to dump the full config with all the inheritance exploded. That might show the issue?
[09:40] <bigjools> lsconfig iirc
[09:41] <mthaddon> ./utilities/lsconf.py
[09:42] <stub> Do you have a traceback and can confirm which widget it spitting out the error?
[09:42] <bigjools> awesome.  lsconf falls over with the same error
[09:43] <bigjools> http://pastebin.ubuntu.com/358941/
[09:44] <mthaddon> I wonder if this is related to the work on rw_ and ro_ prefixes for those values
[09:44]  * bigjools updates configs and tries again
[09:44] <mthaddon> dunno what's landed yet
[09:45] <mthaddon> yep, looks like it's landed
[09:45] <stub> mthaddon: Perhaps. That landed...
[09:45] <bigjools> well, this is a rollout blocker, I can't test any of last week's extremely invasive changes :/
[09:45] <mthaddon> bigjools: I'm about to submit a branch that should fix lp-production-configs
[09:45] <mthaddon> https://code.edge.launchpad.net/~mthaddon/lp-production-configs/read-only-text-file/+merge/17581
[09:46] <bigjools> mthaddon: oh, you know the problem already?
[09:46] <mthaddon> yeah
[09:46] <bigjools> mthaddon: excellent
[09:47]  * bigjools hacks the diff locally
[09:47] <stub> I'm off to pay my health insurance then
[09:48] <bigjools> required for working on LP? :)
[09:48] <mthaddon> bigjools: you can see what changes are needed?
[09:48] <bigjools> mthaddon: yes, I've changed the DF config on DF itself and it seems to be getting further now
[09:48] <mthaddon> cool
[09:48] <stub> :-) Or maybe tomorrow since they close in 10 mins
[09:49] <bigjools> when it finishes generating the ****ing wadl I'll find out
[09:49] <mthaddon> welcome to my world
[09:49] <bigjools> :)
[09:50] <bigjools> I also want to scream every time I see combine-css running
[09:50] <bigjools> even when doing "make stop"
[09:50] <bigjools> it really needs a Makefile predicate
[09:51] <mthaddon> try make initscript-stop instead
[09:52] <bigjools> argh
[09:52] <bigjools> thanks
[10:08] <bigjools> stub: db-devel is fine on dogfood, which adds to the confusion
[10:08] <stub> I'm suspecting a missing launchpad-dependency that happens to be installed on the production boxes.
[10:08] <stub> But haven't looked closely.
[10:09] <bigjools> stub: the only one I remember us adding was python-debian
[10:10] <bigjools> bzr-builder was added to sourcedeps
[10:20] <henninge> stub: something LP-related ;)
[10:20] <henninge> stub: what is the best approach to updating many rows with different values each?
[10:21] <henninge> stub: LIke, I have a list of select criterias that select an entry each and I want to set a value in each entry.
[10:22] <henninge> a different value for each entry.
[10:22] <henninge> My naiv approach would be an update request per row. Is there a better solution?
[10:23] <stub> UPDATE foo SET bar=sub.baz FROM (SELECT foo_id, bong FROM baz WHERE ....) AS baz WHERE foo.id = baz.foo_id;
[10:24] <stub> I could make a more comprehensible example with more explicit information
[10:30] <henninge> stub: sorry ;)
[10:30] <henninge> stub: I want to set priority on potemplate and have this list: http://people.canonical.com/~dpm/template-priorities/karmic-templates-priorities.csv.txt
[10:31] <stub> As the source isn't in PG, better to just do one query per entry
[10:31] <henninge> stub: ok, I can write a script for that.
[10:32] <stub> You *could* load all the data into a temporary table and use that in the FROM clause of the UPDATE statement, but there isn't that much data...
[10:32] <henninge> 1298 lines ...
[10:32]  * stub shrugs
[10:33]  * henninge expected that
[10:33] <stub> pfft. You have other scripts trashing *millions* of rows.
[10:33] <henninge> I know, I know.
[10:33] <bigjools> stub: utilities/update-sourcecode does the trick in db-devel
[10:34] <stub> So rocketfuel-get is busticated?
[10:34] <bigjools> rf-get doesn't touch db-devel does it?
[10:34] <bigjools> only trunk
[10:36] <stub> Hmm... so sourcedeps.conf has been modified on db-devel and not devel? That is going to mess staging and production.
[10:36] <stub> Or is is just that devel changes haven't leaked through to db-devel yet?
[10:36] <bigjools> I think update-sourcecode doesn't get run on db-devel automatically, that's all
[10:37] <bigjools> hmmm actually
[10:37] <stub> ok
[10:37] <bigjools> you're right
[10:37] <bigjools> devel doesn't have the updated sourcedeps
[10:44] <stub> yer - I only have one sourcedeps. Everything else is symlinked.
[10:45] <henninge> stub: can you tell me the id for karmic?
[10:45] <henninge> stub: like "select id from distroseries where name = 'karmic'" ?
[10:45] <stub> (SELECT id FROM distroseries WHERE name='karmic') is better than hardcoding the id :)
[10:46] <stub> But it is 97 if this is a one of script to only run against staging and production
[10:46] <henninge> stub: yes, just once.
[10:46] <henninge> thanks.
[10:55] <henninge> stub: does that look ok? http://paste.ubuntu.com/358965/
[10:57] <henninge> stub: or more like this http://paste.ubuntu.com/358966/
[10:58] <stub> yer
[10:58] <stub> UPDATE potemplate
[10:58] <stub> SET priority=100
[10:58] <stub> FROM sourcepackagename, distroseries
[10:58] <stub> WHERE
[10:58] <stub>     potemplate.sourcepackagename = sourcepackagename.id
[10:58] <stub>     AND sourcepackagename.name = 'moin'
[10:58] <stub>     AND potemplate.name = 'moinmoin'
[10:58] <stub>     AND potemplate.distroseries = distroseries.id
[10:58] <stub>     AND distroseries.name = 'karmic';
[10:58] <henninge> ah!
[10:59] <henninge> thanks!
[11:02] <henninge> stub: This assumes that no other distribution in the db will have a 'karmic' series. I'll add the distribution.
[11:02] <stub> henninge: Correct. Overkill at the moment, but correct :)
[12:03] <henninge> danilos: are you alive here? ;-)
[13:08] <bac> barry: ping
[13:09] <barry> bac: pong
[13:10] <bac> barry: hi.  i was trying to use your stop() debugging tip but need to do so in a browser/test not a pagetest.  it's not in the doctest globs but i redefined it.  i find that *some* of the setup data is available when i hit launchpad.dev but not all -- mainly the stuff i want.  any ideas?  any reason it wouldn't work in that test env?
[13:12] <barry> bac: hmm.  the only thing i can think of is that the non-page tests don't always commit the transaction, whereas each request in the page test should commit the transaction.  try sprinkling "transaction.commit()" calls in the non-page tests and see if that helps
[13:13] <bac> barry: ah, good idea.  i tried flushing the db but didn't commit.  duh.
[13:15] <bac> barry: cool, that was it
[13:15] <barry> \o/
[13:15] <barry> bac: wow, and i haven't even had my coffee yet this morning :)
[13:16] <bac> barry: but i have.  :(  well, tea.
[13:16] <barry> yeah, tea for me too :)
[13:27] <bac> barry: any reason stop() can't be made available in systemdocs globs?
[13:31] <barry> bac: nope.  in fact it should
[15:19] <kfogel> gmb: https://code.edge.launchpad.net/~kfogel/launchpad/505845-affects-me-too-from-dups/+merge/17633
[15:30] <gary_poster> mars or BjornT, did you have any thoughts on thumper's question to the list about the buildbot Windmill test failures in lp:~thumper/launchpad/js-play?  (subject of email is "OK, I'm stumped")
[15:35] <leonardr> flacoste, do you have a minute to talk about multi-version?
[15:37] <flacoste> leonardr: i do
[15:38] <flacoste> gary_poster: BjornTwill be sleeping
[15:39] <leonardr> flacoste: i've run into a problem which i can push off for a little while but not indefinitely. let me paste you a diff
[15:39] <gary_poster> flacoste: ack, thanks.
[15:41] <leonardr> flacoste: http://pastebin.ubuntu.com/359066/
[15:42] <leonardr> the problem is that the IWebServiceConfiguration utility is not available until after the web service has been built and the code has run
[15:42] <leonardr> but that utility is what defines the versions in use
[15:43] <leonardr> first, do you see what i want to do? do you have questions about that specific code?
[15:43] <mars> gary_poster, I haven't looked at that branch specifically
[15:44] <gary_poster> mars, fair enough.  Do you have any next-step analysis steps to suggest to thumper?
[15:45] <mars> gary_poster, alas, no.  But I can try the branch locally while I work on it.
[15:45] <mars> work on other things
[15:45] <mars> oh, wait
[15:45] <gary_poster> mars: ok thank you.  ok, waiting. :-)
[15:45] <mars> ah.  gary_poster, I will try that later, when I have my laptop... oh, wait.
[15:46] <gary_poster> lol, being asked to wait a lot ;-)
[15:46] <mars> so, my new desktop hard drive doesn't have lp-dev on it.  My laptop, which runs Jaunty, has a broken lp-dev on it.
[15:46] <adiroiban> danilos: hi.
[15:47] <adiroiban> danilos, henninge : one more question regarding. +edit page for potemplate. When changind domain name, the date_last_updated is also changed
[15:47] <adiroiban> should I make it available for edit in +edit?
[15:47] <EdwinGrubbs> barry: ping
[15:47] <barry> EdwinGrubbs: pong
[15:48] <mars> gary_poster, I'll see what I can do when I finish more of the pyslow reporting.  I don't want to switch to a system reinstall right now.
[15:48] <henninge> adiroiban: no, I think not. It should be updated automatically when the data changes, like it does now (I presume).
[15:49] <adiroiban> well... not it is not updated on edit
[15:49] <gary_poster> mars, agree.  Could you reply to thumper with a "I acknowledge your pain" message then, and say that you'll look into it if someone else doesn't beat you to it once you are able to sort out your LP issues?  Maybe that will ping Björn to help if he can.
[15:49] <adiroiban> henninge: changing the description of a potemplate... will not touch the last_update_date
[15:49] <henninge> adiroiban: hm, it should definitely not be edited manually.
[15:49] <adiroiban> but changing the domain_name will do
[15:50] <henninge> adiroiban: I see.
[15:50] <henninge> Don't know if that is a bug or if it's intentional.
[15:50] <adiroiban> so I should remove security proxy
[15:50] <adiroiban> ?
[15:50] <adiroiban> just for the edit page?
[15:50] <adiroiban> and for that field?
[15:51] <adiroiban> not sure how this can be solved
[15:51] <adiroiban> s/be/should/
[15:51] <henninge> adiroiban: how does the field get updated at the moment?
[15:51] <adiroiban> henninge: at the moment there is no translation domain in +edit page :)
[15:51] <adiroiban> my branch will add the field
[15:52] <flacoste> leonardr: why do you need to push the earliest_version?
[15:52] <leonardr> flacoste: i have to push something so that the very first annotations will have a name. it doesn't have to be earliest_version
[15:53] <flacoste> leonardr: you could simply use a marker 'THIS_IS_THE_EARLIEST_VERSION'
[15:53] <leonardr> right, that's what i'm doing for now
[15:53] <henninge> adeuring: so when you said "When changind domain name, the date_last_updated is also changed" earlier, what were you referring to?
[15:53] <leonardr> but soon i'm going to have to handle @webservice_version('1.0')
[15:53] <flacoste> leonardr: and then replace that marker with the correct name (if needed) in the generate_pass
[15:53] <leonardr> flacoste: ok, that's what i was looking for, i think
[15:53] <flacoste> generate_pass: actually, that might be a proble
[15:53] <flacoste> m
[15:53] <leonardr> when generate_* runs, the utility will be available?
[15:53] <flacoste> no
[15:53] <flacoste> well
[15:54] <flacoste> maybe
[15:54] <flacoste> but there is no garantee
[15:54] <flacoste> that code will need to run when the utility is registered
[15:54] <flacoste> we could add an event for that
[15:54] <flacoste> but you might want to see if you can get away with simply using a marker
[15:54] <flacoste> maybe you don't need to replace it
[15:54] <flacoste> with the proper name
[15:55] <flacoste> you could do it the other way round
[15:55] <henninge> adiroiban: so when you said "When changind domain name, the date_last_updated is also changed" earlier, what were you referring to?
[15:55] <flacoste> leonardr: replace 'whatever_the_earliest_version_is' with THIS_IS_THE_EARLIEST_VERSION_MARKER when doing lookup
[15:55] <flacoste> leonardr: see how this evolves
[15:55] <flacoste> gary_poster: might have other clever suggestions
[15:56] <leonardr> flacoste: i can get away with not mentioning what specifically the earliest version is. i'm concerned about specific versions named in the annotations
[15:56]  * gary_poster looks around in attempt to find something to be clever about
[15:56] <adiroiban> henninge: updating translation_domain from the +edit page, will automaticaly change date_last_updated
[15:57] <leonardr> at some time before i create and register the web service adapter classes, i'll need to check whether or not '1.0' is a valid version number
[15:57] <henninge> adiroiban: right and where does that happen?
[15:57] <adiroiban> henninge: right now, there is only 'description' field, and changing it from +edit will not change date_last_updated
[15:57] <adiroiban> henninge: this happens on my new branch for bug 340662
[15:57] <mup> Bug #340662: "Change details" for POTemplate should allow maintainers some more freedom <qa-bad> <ui> <Launchpad Translations:Fix Committed by adiroiban> <https://launchpad.net/bugs/340662>
[15:59] <adiroiban> henninge: this is the MP https://code.edge.launchpad.net/~adiroiban/launchpad/bug-340662-take-2/+merge/17598
[15:59] <leonardr> gary: i can walk you through it if that'll get you up to speed faster
[16:00] <danilos> adiroiban, henninge: we should probably not change last_updated_date on translation domain change
[16:01] <adiroiban> henninge: or maybe we should change to code so that changing translation_domain will not change date_last_updated
[16:01] <kfogel> flacoste: https://pqm.launchpad.net/ seems crashed, just fyi
[16:01] <flacoste> kfogel: nah, that's just the web interface
[16:01] <danilos> adiroiban, henninge: however, this is likely needed for langpack updates, so...
[16:01] <danilos> adiroiban, henninge: I'd just keep it in
[16:02] <kfogel> flacoste: that's what I was referring to, sorry if not clear
[16:02] <kfogel> not "PQM" but "pqm.launchpad.net"
[16:02] <adiroiban> danilos: langpack updates are using Launchpad.Edit ?
[16:02] <flacoste> kfogel: it will clear itself out at some point
[16:02] <gary_poster> leonardr, so, you are doing something (setting up the BleedThroughDict with version information) during zcml processing that wants the zcml to already be processed?  A standard-ish way to handle something like this is to (1) leverage the two-stage zcml processing and/or (2) make a requirement that a certain utility is registered in zcml before other things are called.
[16:02] <kfogel> flacoste: ah, ok
[16:02] <danilos> adiroiban, henninge: one would have to check language pack delta generation code to see if it's using potemplate.last_update_date
[16:02] <flacoste> kfogel: it's usually because of a specific job which chokes the web ui
[16:02] <leonardr> gary: how would i do the latter?
[16:03] <danilos> adiroiban, ha, no, but "incremental updates" are using dates of export to figure out what needs exporting
[16:03] <kfogel> flacoste: that's... interesting :-).  But real-time PQM reporting is not a vital service, I guess.
[16:03] <flacoste> leonardr: well, you don't really need to care about the specific version either, unless for validation purpose
[16:03] <flacoste> leonardr: and that you can do later also
[16:03] <gary_poster> leonardr: simply fall over if it is not registered when you need it to be with a hopefully helpful error message.
[16:03] <danilos> adiroiban, if we don't update the date here, it might break and you won't be able to fix wrong translation domains in ubuntu without getting a full language pack export
[16:03] <adiroiban> danilos: ah. I see :)
[16:03] <danilos> anyway, off now
[16:03] <gary_poster> leonardr: in stage one of zcml processing, collect information
[16:03] <danilos> adiroiban, fwiw, that's just my guess, it would have to be confirmed through code
[16:04] <flacoste> gary_poster: the code that he's showing happens before ZCML
[16:04] <gary_poster> leonardr: in stage two of zcml processing, require that the desired utility is already registered
[16:04] <flacoste> gary_poster: this is interface declaration code
[16:04] <flacoste> gary_poster: happens whenever the module is imported
[16:04] <flacoste> so he can't rely on any ZCML being registered at this point
[16:04] <gary_poster> flacoste, can he do the actual registrations in stage two of ZCML processing?
[16:05] <adiroiban> danilos, henninge: well, when changing translation_domain, I think we should update the last_update_date
[16:05] <flacoste> gary_poster: there is no registration happening either, in that stage you should only collect the annotations
[16:05] <flacoste> gary_poster: registration happens when the special ZCML directive is called
[16:05] <adiroiban> even if langpack delta is not using the fields... maybe in the future we will need this
[16:06] <leonardr> flacoste: ok, you're saying that at some point i can just fall over and say 'you defined a really big web service with no problems, but its versions don't match up with the versions in the config utility, so aaaargh"
[16:06] <gary_poster> flacoste: oh ok.  So, can't we just demand that the desired utility be registered when the special ZCML directive is called, in stage 2, and do validation then?
[16:06] <flacoste> gary_poster: yep, that would work
[16:07] <leonardr> gary: what's the syntax for demanding that?
[16:09] <gary_poster> leonardr: um, try to get the utility (e.g. zope.component.getUtility or queryUtility)?  If it fails, fall over, maybe with a more helpful message than just "the component isn't registered," by raising an error
[16:09] <gary_poster> leonardr: am I missing something?
[16:09] <leonardr> gary: i'm missing something
[16:09] <leonardr> i know how to fall over if the utility isn't there. in fact, right now it happens automatically
[16:10] <leonardr> i don't know how to make the utility be there
[16:10] <gary_poster> leonardr: right
[16:10] <gary_poster> ah
[16:12] <gary_poster> leonardr, so, (1) make sure that the zcml to register the desired utility comes before the zcml to do your registration and validation, when reading the zcml depth-first (that is, following zcml imports). (2) Make sure that your registration and validation happen in the second stage of ZCML processing (that is, not when the zcml directive is supposed to insert functions and discriminators, but within the function that it reg
[16:12] <gary_poster> that is done correctly already.
[16:13] <gary_poster> leonardr: did that make sense?  if not, happy to try Skype
[16:14] <leonardr> gary: i understand in principle but i don't know how to make sure something happens in the second stage
[16:15] <leonardr> i'm going to leave this part alone for now
[16:15] <gary_poster> leonardr: ok.  let me know when you want to tackle.
[16:15] <leonardr> knowing that if all else fails i can compare the versions when the utility is defined, and fall over if they don't match
[16:17] <leonardr> hm, i also see a problem with defining a single 'webservice_version' function that can annotate a field, a method, an entry, or an interface
[16:17] <leonardr> i may just give them different names for now
[16:24] <henninge> adiroiban: When I was asking about "where" I meant "where in the code". ;-)
[16:25] <henninge> adiroiban: so it's in POTemplateEditView.change_action, isn't it?
[16:26] <adiroiban> henninge: yes
[16:26] <henninge> adiroiban: so there is no need to actually expose it in the form.
[16:28] <henninge> adiroiban: and that is what I understood when you said " should I make it available for edit in +edit?"
[16:28] <adiroiban> henninge: no. But I don't know how we should solve the permission problem.
[16:29] <henninge> adiroiban: you only need to change permissions on the *object*. You do that in lp/translations/configure.zcml
[16:29] <henninge> adiroiban: or you could use removeSecurityProxy, too, like you suggested.
[16:30] <henninge> removeSecurityProxy(context.date_last_updated) = datetime.datetime.now(UTC)
[16:31] <adiroiban> henninge: what do you suggest? should I add date_last_updated to Launchpad.Edit for IPOTemplate, or just use removeSecurityProxy ?
[16:31] <gary_poster> leonardr: do you see wadl generation thread on launchpad-devel?  Could you jump in, please?
[16:32] <henninge> adiroiban: I am not sure, actually ... danilos, what do you think? ^^
[16:32] <leonardr> gary, sure
[16:32] <gary_poster> thanks
[16:32] <adiroiban> henninge: I am not aware of posible side effects...
[16:33] <henninge_> adiroiban: did my last line come through?
[16:33] <henninge_> adiroiban: I am not sure, actually ... danilos, what do you think? ^^
[16:33] <gary_poster> leonardr, uh, wait a sec.  gmb, I think this means that someone updated (added) a dependency to sourcecode?  And didn't update ec2 images?  leonardr, I guess this doesn't have anything to do with wadl really, unless you tell me I'm wrong
[16:34] <adiroiban> henninge_: i think Danilo is away
[16:34] <henninge_> adiroiban: but using removeSecurityProxy might be ok here. Do that and see what bac says about it ... ;-)
[16:34] <gary_poster> (other than it being the point of failure for what appears to be a problem somewhere else)
[16:34] <henninge_> adiroiban: so will I be very soon ;)
[16:34] <adiroiban> henninge_: :)
[16:35] <leonardr> gary: my guess is that the error happens in wadl generation because that's the first time a new launchpad install is started up
[16:35] <leonardr> gary: because we need the wadl to generate the static html apidoc
[16:35] <gmb> gary_poster, leonardr: The builder.recipe thing? There's a thread about it on launchpad-dev.
[16:35] <gmb> It's been tracked down to some buildout config weirdness, I think.
[16:35] <gary_poster> leonardr: right agree, sorry for bothering you, I don't this has anything to do with you
[16:35] <leonardr> np
[16:35] <henninge_> adiroiban: my reasoningn for removeSecurityProxy would be that the owner should not really be able to set it, just in this specific context.
[16:37] <gary_poster> gmb: well, the build, not buildout per se, but yes.  If I understand correctly, this is exactly the kind of situation that buildout fixes, and we don't get the win because these are branches in sourcecode
[16:37] <gmb> gary_poster: Ah, right. So this needs an ec2 image update for db-devel branches to be runnable there again?
[16:37] <jamalta> if i need to reset my database, do i just run make schema again?
[16:38] <gmb> jamalta: Yes
[16:39] <gary_poster> gmb: I think it is nastier than that.  IIUC, we would need an image for db-devel and an image for devel, given the current state.  ...I *think* the right/easy thing to do is to make devel's sourcedeps.conf have the same two lines that stub identified in db-devel
[16:39] <gmb> Ah, right.
[16:40] <jamalta> gmb: alright, thanks
[16:41] <gary_poster> flacoste, have you followed along with the "db-devel wadl generation broken" thread?  My thought is that, for an easy solution, we should have a devel branch in which we add the two lines that are in db-devel that stuart identifies (for bzr-builder and bzr-hg)
[16:41] <gary_poster> The other approach is to fix all of our scripts to handle this situation, but I think thta's a rabbit hole
[16:41] <adiroiban> henninge_: can I use removeSecurityProxy for just an attribute?
[16:42] <henninge_> adiroiban: oh, sorry, no.
[16:42] <henninge_> removeSecurityProxy(context).date_last_updated = datetime.datetime.now(UTC)
[16:42] <adiroiban> henninge_: hm... I did this
[16:42] <adiroiban>             date_last_updated = removeSecurityProxy(context.date_last_updated)
[16:43] <adiroiban>             date_last_updated = datetime.datetime.now(UTC)
[16:43] <adiroiban> and somehow the tests were ok
[16:43] <henninge_> adiroiban: maybe it does work ...
[16:43] <henninge_> adiroiban: zope never ceases to amaze me ... ;-)
[16:44] <adiroiban> henninge_: it's just that you can not assign to a function call
[16:45] <adiroiban> henninge_: I think this was the only reason why removeSecurityProxy(context.date_last_updated) = datetime.datetime.now(UTC) , is not working
[16:45] <henninge_> adiroiban: probably
[16:45] <leonardr> gary: given that you're busy with the db-devel problem, i've found another place where i'll need to do utility lookups to do multiversion, so i'd like to hear more about the two-pass proposal you mentioned earlier
[16:45] <henninge_> adiroiban: I'll be off now. See you tomorrow!
[16:45] <adiroiban> henninge_: have a nice day. thanks for the help :)
[16:46] <henninge_> you, too
[16:48] <gary_poster> leonardr: ok.  I'm writing an email to the list about the db-devel thing, then will be available
[16:58] <gary_poster> leonardr: ok, could you point me to the current lazr.restful code that processes the zcml?
[16:59] <leonardr> gary: sure, it's in src/lazr/restful/metazcml.py
[16:59] <gary_poster> ok
[16:59] <leonardr> the problematic zcml handler is 'register_webservice'
[16:59] <leonardr> i actually have a plan and i want to see if it makes sense, but take a look at that code
[16:59] <gary_poster> ok
[17:00] <leonardr> the XXX in that method is where the problem is
[17:01] <gary_poster> leonardr: so, take a look at register_exception_view in that module
[17:02] <leonardr> gary: sure
[17:02] <leonardr> is that kind of hook setting stuff up for the second pass?
[17:02] <gary_poster> leonardr: it is registering a discriminator, a callable, and args for the callable.  This means that ``register_exception_view`` is the first pass and, yeah, ``handler`` is the second pass
[17:03] <leonardr> ok, then i think my plan will work and is similar to what you were saying i should do
[17:03] <leonardr> take a look at that xxx
[17:03] <leonardr> i want to specify a more appropriate interface method than IWebServiceClientRequest
[17:03] <leonardr> but that requires looking up a named utility using version number as the name
[17:03] <gary_poster> ah
[17:04] <leonardr> so what i plan to do is define a subclass of zope.component.handler
[17:04] <flacoste> gary_poster: well, i'm not sure about that, there is no garantee that the tests will pass with these two updated deps
[17:04] <flacoste> gary_poster: it's a more general problem of having different sourcode deps in different branches
[17:04] <leonardr> and call context.action with callable=my new handler
[17:04] <gary_poster> flacoste: are the updated or added?  I thought they were added?
[17:04] <flacoste> gary_poster: devel and db-devel being the most common case
[17:04] <leonardr> and args=something like this
[17:04] <flacoste> gary_poster: if they are added, it should be fine
[17:05] <flacoste> gary_poster: but i think what might require is one sourcecode directory per root-branch
[17:05] <flacoste> gary_poster: where root branch are devel, db-devel and production-devel
[17:05] <flacoste> and make sure that the scripts picks the one appropriate for the parent branch
[17:05] <leonardr>             args=('registerAdapterForVersion',
[17:05] <leonardr>                   factory, interface, '1.0', provides, '', context.info),
[17:05] <leonardr>             )
[17:06] <gary_poster> flacoste: I think it is added.  What you describe sounds good for a later change, particularly if we still don't think we're discarding sourcecode anytime soon
[17:06] <leonardr> call that multiple times, matching each interface to the version *name*, and then have the custom handler 1) do the lookups, and 2) fall over if invalid versions are specified
[17:06] <gary_poster> flacoste: I'd like someone (which may mean me) to just add the deps for now though
[17:06] <gary_poster> (if they are added)
[17:08] <flacoste> gary_poster: go ahead
[17:08] <gary_poster> leonardr: that sounds fine to me, though I hope that the ``callable`` really just has to be a callable--so, if it makes sense to subclass the handler, then sure, but otherwise you could just pass in your own function that does what you want and not try to be unnecessarily general
[17:09] <leonardr> gary: that sounds good
[17:09] <leonardr> ok, i feel better about this now
[17:09] <flacoste> gary_poster: discarding sourcecode: we are mostly down to the irreductible core: bzr plugins, c-i-p and shipit
[17:09] <gary_poster> leonardr: :-) ok cool
[17:09] <flacoste> gary_poster: c-i-p will be gone in a month or two
[17:10] <flacoste> gary_poster: shipit never really poses a problem which leaves the bzr plugins, not sure about those
[17:10] <gary_poster> flacoste: Martin Pool mentioned that they were interested in making the bzr plugins setuptools-friendly.  I don't know how doable that is either
[17:10] <flacoste> gary_poster: ideally they should support eggs installation, but given lifeless stance on setuptools not sure what are the chance of this happening
[17:10] <gary_poster> He wanted to talk it over with me when we were at the last team lead sprint
[17:10] <flacoste> gary_poster: ah, that'd be great!
[17:11] <jamalta> i'm getting these pylint notices and just wanted to make sure that they are safe to ignore (they are not referencing anything i changed)
[17:11] <jamalta> http://paste.ubuntu.com/359102/
[17:11] <gary_poster> jamalta: definitely the lazr.*; less sure about the email.*
[17:12] <jamalta> gary_poster: let me get a diff of what i've done
[17:12] <gary_poster> k
[17:12] <jamalta> it's just two strings changed around :)
[17:12] <gary_poster> :-)
[17:12] <jamalta> http://bazaar.launchpad.net/~jamalta/launchpad/newtag-statement-redundancy/revision/10195
[17:12] <jamalta> gary_poster: ^
[17:12] <gary_poster> jamalta: yeah, I think you are off the hook :-)
[17:12] <jamalta> gary_poster: awesome, thanks :)
[17:12] <gary_poster> np
[17:14] <jamalta> gary_poster: mind if i throw your name in my proposal? just saying you confirmed that they are not issues caused by me
[17:14] <jamalta> or i could instead just say it was confirmed in #launchpad-dev
[17:15] <gary_poster> jamalta: name is fine
[17:15] <jamalta> gary_poster: thanks so much
[18:03] <mrevell> night all :)
[18:55] <wgrant> Does anybody know what bigjools wanted?
[18:56] <wgrant> Ah, looks like he might be back later.
[18:57] <wgrant> And he emailed me. Even bette.r
[19:27] <jamalta> well that's a bust, i guess i can't see the buildbot results if i'm not a canonical employee?
[19:34] <maxb> jamalta: Indeed :-(. They say they're working on it
[19:35] <jamalta> maxb: Well, at least we have some hope :)
[19:35] <jamalta> Maybe they should give buildbot access to people who have signed the contributors agreement?
[19:35] <jamalta> Who knows what will be decided...
[19:36] <maxb> Anonymous read-only viewing of buildbot and pqm status would be a good start
[19:37] <jamalta> maxb: +1
[19:39] <wgrant> That's difficult for a couple of reasons: 1) buildbot needs upgrading to remove XSS vulnerabilities and 2) PQM (and soon buildbot) manage production-devel, which needs to remain private for security fixes.
[20:00] <thumper> gary_poster: hi
[20:01] <gary_poster> thumper: hey
[20:01] <thumper> gary_poster: BjornT had a look with me before I sent off the email and had no idea either
[20:01] <gary_poster> thumper: ah :-( .  I think I saw someone else reply...
[20:01] <thumper> gary_poster: yeah, rockstar replied
[20:02] <thumper> gary_poster: if I run the windmill tests just using the test runner they all pass
[20:02] <thumper> gary_poster: if I run `make jscheck` they fail
[20:02] <thumper> no idea why
[20:02] <thumper> got things like 'already disconnected error'
[20:02] <rockstar> thumper, I suspect timing issues, but I'm doing other things right now.
[20:03] <rockstar> thumper, I basically spent an 8 hour flight trying to figure out why they were failing, and it was all voodoo
[20:03] <gary_poster> thumper: right.  I don't know either, and rockstar, BjornT and mars all know more than I.  mars said he would look into it soon; he's my last best hope for now.
[20:03] <gary_poster> but he has other items he needs to tie up
[20:03] <thumper> ack
[20:04] <rockstar> I'm willing to bet that if I land this, it won't fail in buildbot...
[20:04] <rockstar> thumper, you should try first...  :) ^^^
[20:04] <thumper> no
[20:04] <gary_poster> thumper: the only other thing I know of is to try to rockstar's comment that the Windmill tests are not ready yet to block landings.  That would be something to take up with Björn, and maybe Maris.
[20:06] <BjornT> thumper: i would merging in latest devel, and try again. r10192 contains a possible fix
[20:06] <thumper>  BjornT: ok
[20:07] <salgado> thumper, if you run 'make jscheck' on a devel branch, do they fail as well?
[20:07] <thumper> salgado: haven't tried
[20:08] <salgado> thumper, that'd indicate something in your setup is not playing along nicely with windmill tests, but only worth trying if stub's change doesn't get rid of the failures you saw
[20:09] <BjornT> gary_poster, rockstar: as to whether to block landings. when/how do you propose we fix issues like these? if not now, then we'll probably never will be able to do it, since this is the first time i've seen it (and i've run quite a few tests). we have to go through some level of pain to make it stable. the other alternative would be to not have windmill tests at all, but i don't want us to go there yet
[20:09] <rockstar> BjornT, well Windmill tests have jumped leaps and bounds since we started on them.  That was inspired by pain.
[20:10] <rockstar> BjornT, however, I have a high priority bug that needs to land this cycle, and the tests are preventing it from landing.
[20:10] <gary_poster> BjornT: I'm not advocating, merely observing that this was thumper's other alternative approach.  I agree with your logic, and particularly that they deserve much more of a chance.
[20:11] <BjornT> rockstar: did you send a mail to the list about your problems, for others to look at?
[20:11] <rockstar> BjornT, thumper beat me to it, with the same issue.
[20:11] <rockstar> I detailed what I was seeing in my response.
[20:12] <rockstar> BjornT, the simple fact is that the tests are not reflecting real breakages.  All the functionality is still intact.
[20:16] <BjornT> rockstar: fwiw, we had much bigger problems when starting using buildbot. i think the main problem here is that no one knows how to debug it. it's difficult, since the errors seem to be in the app server, not in windmill.
[20:16] <BjornT> i might have some time to look at it today
[20:18] <rockstar> BjornT, that would be appreciated.  It's really frustrating, and I haven't had much time to look at it.
[20:19] <wgrant> bigjools: Does buildd-manager work even with that odd message?
[20:21] <rockstar> BjornT, when we had the problems with buildbot, they were more-or-less "stop the presses" kind of problems.  I don't think these are stop-the-presses issues, considering that most of Launchpad is non-js.
[20:25] <BjornT> rockstar: well, a lot of our js is stop-the-presses issues. for example, what if peple can't comment on bugs or mps? what if they can't change statuses? those are quite critical issues that we don't want our users to experience.
[20:26] <rockstar> BjornT, yeah, but in this case, the functionality isn't broken, just the tests.
[20:27] <BjornT> rockstar: yes, and it was the same thing with buildbot in the beginning. would you rather have us not spend time fixing those problems, and instead have gone back to using pqm to run the tests?
[20:28] <rockstar> BjornT, so maybe the issue is that we need to get a swat team together to kick down the door and clear the room when we have these problems, and they drop everything else for that.
[20:28] <rockstar> BjornT, I'd be willing to be on that team if thumper was agreeable.
[20:29] <BjornT> rockstar: yeah. there is the problem that i probably knows the most about theses issues, and i'm busy atm.
[20:29] <BjornT> i wonder if gary_poster could spare someone from his team to work on windmill issues?
[20:31] <rockstar> BjornT, yeah, I'm also trying to get some work in today so I can spend the rest of the week QAing.  It's likely I can spend tomorrow really looking into this.
[20:35] <gary_poster> BjornT: are you asking generally or now as an emergency?  generally, I think, on the Foundations team, mars already has the best handle on this part of the world.  salgado might be a good choice as well, in the future.  For this week, mars could have a bit of time at the end of this week maybe, and more next week; I'd rather not take salgado off his task ATM.  For today, right now, I don't have anybody.
[20:39] <Ursinha> hello people
[20:40] <Ursinha> what do I have to do to add stuff in lp.dev sample data? is there a procedure somewhere?
[20:42] <rockstar> Ursinha, my general answer to that is "don't."
[20:42] <Ursinha> rockstar: right, why?
[20:42] <rockstar> Ursinha, it usually causes more problems for me than it fixes.
[20:43] <rockstar> Ursinha, I bet salgado has a better answer though.
[20:44] <Ursinha> rockstar: right... I'll ask him when he's available, thanks
[20:44] <Ursinha> rockstar: I'll try to go another way to test what I want
[20:45] <rockstar> Ursinha, I have a script that I made that creates sample data for my specific use cases when I'm using make run.
[20:46] <Ursinha> rockstar: can I see that? :)
[20:47] <rockstar> Ursinha, do you know about make harness?
[20:47] <Ursinha> rockstar: yes
[20:49] <rockstar> Ursinha, so you should have a factory in make harness.  Use that factory like you would in your tests.
[20:49] <Ursinha> rockstar: right
[20:50] <rockstar> Ursinha, that's how I did it.  I can't seem to find that script right now.  I think it might be on my desktop computer.
[20:51] <BjornT> gary_poster: i guess both. mainly now for the emergency, but also for the future, in case it breaks again.
[20:52] <Ursinha> rockstar: wait, doing that isn't the same as writing the tests?
[20:52] <Ursinha> rockstar: my problem is that I need to test a change in a page, and I'd need one more series in the project I'm using for it to work
[20:53] <Ursinha> rockstar: that's why I'm asking about the sample data
[20:53] <rockstar> Ursinha, oh, if you're needing test sample data, then the answer is really "don't"
[20:53] <rockstar> Ursinha, create the sample data you need in the test itself, using the factory.
[20:54] <rockstar> Ursinha, that would mean creating a project and a couple of serieses in your case.
[20:54] <Ursinha> rockstar: yeah, I guess I found what to do here
[20:58] <gary_poster> BjornT: OK.  maybe you and mars can work together a bit next week to give him some more familiarity.  He might have some availability tomorrow.
[20:59] <Ursinha> thanks rockstar
[21:28] <bdmurray> I'm having an issue running tests with GoogleServiceLayer and a "Socket poll time exceeded."
[21:29] <intellectronica> gary_poster: do you maybe know anything about this? ^^^^^
[21:29] <gary_poster> intellectronica: not off hand, and on call
[21:33] <rockstar> bdmurray, does it happen repeatedly?
[21:34] <bdmurray> rockstar: yes
[21:40] <wgrant> bdmurray: Interesting. I have recently had that occasionally when trying to run LaunchpadFunctionalLayer tests.
[21:40] <wgrant> I wonder if it's actually reproducible, and I just haven't noticed.
[21:50] <bdmurray> it stopped happening now
[21:51] <mwhudson> bdmurray: have a look for stuck python processes?
[22:40] <wgrant> canonical.testing.layers.LayerInvariantError: Both Zopefull and Zopeless CA environments setup
[22:40] <wgrant> Huh?
[22:41] <mwhudson> fun
[22:42] <elmo> you may be hopeful, but I think it's hopeless
[22:43] <al-maisan> ^^ a candidate for the quotes page :P