[00:40] <lifeless> StevenK: hey
[00:40] <lifeless> StevenK: how is the audit service coming along; do you need any input on it ?
[01:08] <james_w> any zope experts around?
[01:09] <lifeless> !ask
[01:16] <james_w> I've lost my question now
[01:16] <james_w> I think grokcore.component.global_adapter(DjangoLocation, IDjangoLocation, ILocation) isn't doing anything
[01:16] <james_w> but I don't know how debug that
[01:24] <StevenK> lifeless: Input would be awesome
[01:43] <james_w> hmm, it's not that it seems
[01:44] <james_w> it's "directives.location_interface(IDjangoLocation)" whatever that means
[01:49] <james_w> ah, it seems my requests don't implement IWebServiceLayer
[01:55] <james_w> no, that's not either
[02:05] <james_w> marvellous
[02:05] <james_w> it was a zope.traversing version incompatibility
[02:07] <james_w> http://pypi.python.org/pypi/zope.traversing/3.13 breaks lazr.restful it seems
[02:50] <nigelb> wgrant: Nice!
[02:55] <huwshimi> wgrant: Hi, the change you made to the line height on Loggerhead seems to have created a mismatch between the code and the line numbers.
[02:57] <wgrant> huwshimi: Which browser? The only one I've heard bad things about is whatever iOS has.
[02:58] <huwshimi> wgrant: Oh right. This is with Chromium 17.0.963.79 (Developer Build 125985 Linux) Ubuntu 12.04
[02:59] <wgrant> Hmm, indeed.
[03:00] <huwshimi> wgrant: It looks fine on Firefox
[03:00] <huwshimi> (whatever version I have)
[03:00] <wgrant> Yeah, Opera and IE too.
[03:00] <wgrant> Just WebKit is broken.
[03:00] <huwshimi> :(
[03:00] <wgrant> I'm sure I tested it in Chromium, though. Maybe it was an old version.
[03:02] <nigelb> maybe the version number updated right after you checked... :P
[03:03] <huwshimi> wgrant: My guess is that it has something to do with the <pre>
[03:04] <huwshimi> wgrant: You might be able to do it without the <pre> and use .viewLine a { display: block;}
[03:04] <wgrant> It's the line-height on the pre
[03:04] <wgrant> Dropping that makes it work everywhere.
[03:04] <wgrant> Just makes it slightly more obese in Firefox
[03:05] <huwshimi> ah right
[03:12] <lifeless> StevenK: if you want a chat or whatever, I'm free
[03:13] <StevenK> lifeless: Chat works
[03:14] <lifeless> skype then?
[03:14] <StevenK> I knew you were going to say the evil s word
[03:14] <nigelb> hahah
[03:14] <lifeless> ♥ skynet
[03:14] <nigelb> I thought Mumble was more evil anyway?
[03:15] <lifeless> its technically poorer thats for sure
[03:15] <wgrant> You know, it would be really awesome if testing in OS X and iOS browsers didn't require purchasing Apple hardware.
[03:15] <StevenK> Hahaha
[03:15] <nigelb> wgrant: need help with testing?
[03:15] <StevenK> lifeless: Let me get a cup of tea and setting up skype
[03:15]  * nigelb is on the mac.
[03:16] <wgrant> Nah, I'll just hope that Win32 Safari is vaguely similar.
[03:17] <wgrant> Thanks for the offer, though :)
[03:17] <nigelb> :)
[03:17] <bigjools> not sure if hangouts are more evil either
[03:18] <wgrant> hangouts are a binary plugin that I have yet to convince to not hang Firefox or Chromium.
[03:18] <wgrant> They are more evil than Skype.
[03:18] <wgrant> And that's saying something.
[03:19] <bigjools> I never had any probs like that with it
[03:19] <nigelb> heh
[03:19] <nigelb> skype on linux is good. BUt on mac it's severly pita.
[03:19] <bigjools> well both are closed source... which do you trust more? :)
[03:19] <bigjools> sound quality on skype is bloody excellent though
[03:19] <wgrant> TBH I trust Microsoft more than Google right now...
[03:20] <bigjools> their echo cancellation is something to behold
[03:20] <nigelb> lol, me too.
[03:20] <nigelb> and skype scales better than google hangout.
[03:20] <StevenK> wgrant: BugsInformationTypeMigrator is getting blocked a lot
[03:20] <bigjools> my data usage under hangouts has been insane
[03:21] <wgrant> StevenK: Sure, but surely not all weekend.
[03:23] <StevenK> wgrant: Pretty much
[03:23] <StevenK> VACUUMs, backups, PRF and retry_depwait
[03:24] <wgrant> Hmm
[03:55] <wgrant> Sigh
[03:55] <wgrant> Loggerhead's YUI is an embedded copy of 3.0.0pr2
[03:56] <wgrant> Truly the pinnacle of good practice and modern technology.
[03:57] <wgrant> bigjools: How is MaaS handling its YUI3 dep?
[03:57] <wgrant> I don't see it packaged in Ubuntu.
[03:57] <bigjools> convoy
[03:57] <wgrant> How does it get into convoy?
[03:58] <rick_h> it's in precise now and I uploaded it to pypi on friday finally
[03:58] <bigjools> files are in maas
[03:58] <wgrant> O_O
[03:58] <rick_h> rvba said it's going into precise
[03:58] <bigjools> python-django-maas
[03:58] <wgrant> Embedding JS libraries... aaaaaaaaaaaaaa
[03:59] <bigjools> until they're packaged.... any better idea?
[03:59] <wgrant> Package it so you don't have to embed multiple copies of 400KLOC JS libraries? :)
[04:00] <wgrant> I'm surprised the archive admins let that through.
[04:00] <bigjools> meanwhile, in the real world
[04:00] <wgrant> StevenK: I am sad.
[04:00] <StevenK> wgrant: Why this time?
[04:01] <wgrant> StevenK: Your kin let MaaS through NEW with an embedded third-party 400KLOC JS library.
[04:01] <StevenK> lol
[04:02] <StevenK> python-django-maas is not a source package ?
[04:03] <wgrant> Source is just maas
[04:04] <huwshimi> wgrant: We wanted to have our js libraries as dependencies, but we need security audits etc. and there's just not the time\
[04:04] <wgrant> $ du -sh
[04:04] <wgrant> 34M	.
[04:04] <wgrant> $ rm -r src/maasserver/static/jslibs/yui
[04:04] <wgrant> $ du -sh
[04:04] <wgrant> 1.9M	.
[04:05] <bigjools> meanwhile, in the real world.... people need to get work done
[04:05] <wgrant> huwshimi: I'm not sure that gluing multiple packages together is an accepted way to bypass security audits :)
[04:06] <StevenK> bigjools: And it's that attitude in 2007 that got LP into the state it's in. So think very carefully.
[04:06] <wgrant> It's similar to the Go static linking crap a couple of weeks back.
[04:06]  * bigjools sighs heavily
[04:06] <bigjools> you think we don't know this?
[04:06] <bigjools> you think we're stupid?
[04:07] <StevenK> Oh clearly, that's *exactly* what I'm saying.
[04:07] <bigjools> please, feel free to package it for us then, while meeting all the deadlines we have
[04:08] <StevenK> Last time I offered suggestions on your packaging, you told me to shut up, so I don't think so.
[04:08] <bigjools> thought not
[04:08] <huwshimi> wgrant: Actually, it seems like exactly the way to bypass all that :)
[04:08] <wgrant> huwshimi: It certainly works, but it's not accepted :)
[04:10] <huwshimi> wgrant: Sure, we all wanted to do this properly (in fact I spent this morning ripping out a js dependency and putting it in our tree). But with 4 days to go, it's become unavoidable.
[04:15] <huwshimi> wgrant: So I've done EXACTLY what you're talking about, but I can't be in control of the packages in main.
[04:16] <wgrant> Things that security corners shouldn't be cut on, in descending order of importance:
[04:16] <wgrant>  1) Platforms for managing your corporation's entire computing infrastructure.
[04:16] <wgrant>  2) Everything else :)
[04:16] <StevenK> huwshimi: Sure you can. If it's not in main, file a MIR
[04:17] <lifeless> what this really shows is that maas is the first YUI using thing we've got for main inclusion
[04:17] <StevenK> There is a process for how source and binary packages move between components
[04:18] <huwshimi> StevenK: I know there's a process for getting it into main, but that doesn't mean we have the time to get it done
[04:19] <StevenK> huwshimi: It takes about an hour to write the MIR, and you can talk to someone in ubuntu-mir about an urgent request
[04:19] <huwshimi> lifeless: It's not just YUI
[04:20] <huwshimi> StevenK: The people responsible for packaging MAAS have already told us we don't have enough time (on top of all the packages we already have to get included).
[04:23] <StevenK> lifeless: objects.find() you say?
[04:47] <lifeless> StevenK: erm, I think Imeant filter.
[04:47] <lifeless> StevenK: https://docs.djangoproject.com/en/dev/topics/db/queries/
[04:48] <lifeless> https://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.models.query.QuerySet.get vs https://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.models.query.QuerySet.filter
[04:49] <StevenK> lifeless: Yeah, I've figured that out
[04:50] <StevenK> Now I'm trying to work out why I can't pass lists or tuples as the value of a thing to search by
[04:50] <StevenK> It seems to get forced to unicode
[05:11] <mwhudson> StevenK: what are you trying to do?
[05:12] <mwhudson> ah, bad time to offer help, i'm about to run away
[05:13] <StevenK> Haha
[05:21] <lifeless> StevenK: Entry.objects.filter(id__in=[1, 3, 4])
[05:21] <StevenK> lifeless: Yes, I got that bit.
[05:22] <lifeless> StevenK: so whats the code that is going wrong look like ?
[05:22] <StevenK> lifeless: My issue is c.get('/fetch/', {'operation': ['foo', 'bar']}) ends up with request.GET['operation'] == u'bar'
[05:22] <wgrant> Yes.
[05:23] <lifeless> StevenK: hangon, is this webservice marshalling, or ORM stuff ?
[05:23] <wgrant> Lists of HTTP GET arguments are serialised as operation=foo&operation=bar
[05:26] <StevenK> lifeless: The former
[05:27] <lifeless> StevenK: as wgrant says, HTTP params should be listified by the django framework; what are you using to submit the request ?
[05:28] <StevenK> Django's Client class
[05:28] <wgrant> You may have to use a special syntax instead of request.GET['operation']
[05:28] <wgrant> Or you may have to call with [('operation', 'foo'), ('operation', 'bar')]
[05:30] <StevenK> It wants a dict, though
[05:30] <wgrant> What is the generated URL?
[05:31] <StevenK> How do I pull that out of Client?
[05:32] <wgrant> request.GET.getlist('operation') is what you want.
[05:34] <StevenK> Indeed. Thanks.
[05:38] <StevenK> It even works, neat.
[05:43] <huwshimi> I love that you can decide that the code you're working on should be in a new branch and you can just add a new pipe and all your uncommitted changes get pushed into a new branch
[05:48] <bigjools> yeah I get the same thing with co-located checkouts
[06:24] <wgrant> Slow TALES is slow.
[06:41] <stub> wgrant: I have built a Slony package under Lucid for PG9.1. I neglected to rename the source package. Do things explode if I copy the built packages across to the Launchpad PPA?
[06:48] <wgrant> stub: Let me see.
[06:49] <wgrant> stub: It appears to be built for both 8.4 and 9.1, which is probably want we want
[06:49] <wgrant> (looking at 2.0.7-3ppa1 in ppa:stub/launchpad)
[06:49] <wgrant> s/want we want/what we want/
[06:49] <stub> wgrant: Gah - debversion
[06:51] <wgrant> stub: It won't blow up, but it will be difficult to update either of them and be very confusing and leave orphaned binaries around.
[06:51] <wgrant> So I would rename.
[06:51] <wgrant> As, IIRC, I did with 8.4 for oneiric.
[06:51] <stub> Ok. Ta.
[06:51] <stub> Yer, just realized on the weekend. I did it last time (when I built under Oneric and copied back to Lucid, which was a #fail)
[07:32] <lifeless> wgrant: you could try pybars
[07:33] <lifeless> StevenK: unless the internet, or #isd, have answers, you'll need to step through with pdb
[07:40] <wgrant> lifeless: It's actually the TALES in browser:url that's upsetting me right now.
[07:43] <wgrant> (canonical_url on a person can take more than 200µs in a LaunchpadSecurityPolicy environment, 80µs in PermissiveSecurityPolicy, and about 25µs of that goes away when I replace the TALES-based IPerson browser:url with a Python adapter.
[07:44] <wgrant> And it takes 500µs to load a single Person from a DB result :/
[07:45] <wgrant> So to generate two links to a person you've got 1ms :)
[07:45] <wgrant> Speedy Zope is speedy.
[07:47] <lifeless> canonical_url is known for its lightning fast speed and efficient operation
[08:56] <adeuring> good morning
=== almaisan-away is now known as al-maisan
[10:29] <stub> Getting a bzr error with a recipe build: http://paste.ubuntu.com/890439/
[10:47] <jelmer> stub: you have  tag that's pointing at a revision that doesn't exist
[10:47] <jelmer> stub: it's trying to export that tag to create the upstream tarball
[10:48] <stub> htf did I manage that I wonder?
[10:48] <stub> Oh - push --override might do that?
[10:48] <jelmer> yeah, it won't push history that's not related to the branch tip
[10:49] <stub> Should there be a bug on this?
[10:49] <stub> (push --override leaving old tags pointing to revisions that no longer exist?)
[10:50] <jelmer> it's not necessarily wrong to leave that tag around - the revision is still accessible in your local branch
[10:50] <jelmer> it just won't be pushed along
[10:50] <jelmer> there's a few bugs about tag handling in this regard already
[10:52] <jelmer> it would be nice to file a bug about the bzr-builder error though, it should at least tell you what tag it tried to resolve
[11:07] <stub> huh - cosmic ray. "bzr: ERROR: Corruption while decompressing repository file, zlib: Error -3 while decompressing data: incorrect data check" but repeating the command, works fine
=== al-maisan is now known as almaisan-away
[11:52] <czajkowski> jtv: morning
[11:52] <jtv> Good morning czajkowski
[11:52] <czajkowski> jtv: would you have some time free to help me with 2 lanauge questions either now or later on
[11:52] <czajkowski> please
[11:52] <jtv> Let's get it done quickly, since night just fell here.
[11:52] <jtv> Where are they?
[11:53] <czajkowski> jtv: https://answers.launchpad.net/launchpad/+question/191090
[11:53] <czajkowski> https://answers.launchpad.net/launchpad/+question/173909
[11:53] <czajkowski> the latter had a bug linked to it and has been released but they are still having issues.
[11:53] <jtv> czajkowski: the first one is for Ubuntu, not for us.
[11:53] <czajkowski> grand
[11:55] <czajkowski> jtv: thanks for the help. Also does this make sense to you?  https://bugs.launchpad.net/launchpad/+bug/957884
[11:55] <jtv> czajkowski: the second one, I think, may need manual intervention from someone more knowledgeable such as sinzui.  I did propose something that would resolve a lot of these problems in practice, but it was considered too radical.
[11:56] <czajkowski> nods
[11:56] <czajkowski> I'll bring it up later as the fix that is currently in place isn't fixing things
[11:58] <jtv> Yes, IIRC the bug is about not producing dangling membership requests any more.  Which is not the same as dealing with existing ones.
[11:58] <czajkowski> jtv: thanks for the help.
[11:58] <jtv> Good luck :)
=== benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: benji | Firefighting: - | Critical bugtasks: 4*10
[12:03] <deryck> Morning, all.
[12:04] <czajkowski> deryck: howdy doody
=== almaisan-away is now known as al-maisan
[12:52] <wgrant> czajkowski: A timeout on production is always a bug.
[12:52] <wgrant> Triaged/Critical/timeout
[12:53] <wgrant> qastaging/staging are slow and non-production, so it doesn't apply there.
[13:32] <deryck> adeuring, abentley, rick_h -- coming for standup, just taking a second to fire up hangout
[13:40] <abentley> adeuring: Can we chat?
[13:40] <adeuring> abentley: sure. mumble?
[13:40] <abentley> adeuring: sure.
[14:05] <mrevell> Hey deryck, czajkowski kindly pointed me to bug 138775. Some bug mail is going out with truncated subjects, so no bug summary shows. czajkowski says that complaints about this issue have increased since Wednesday, suggesting something may be making it worse. Any thoughts?
[14:07] <deryck> mrevell, hey, let me look at the bug.
[14:08] <deryck> mrevell, hmmm, I have no idea what could have changed to make it worse.  Let me look around a minute or two.
[14:08] <deryck> mrevell, do you know if it's just watched bugs, or happening on any kind of bug?
[14:08] <mrevell> czajkowski has just gone on lunch. I'm guessing she'll see her name highlighted when she gets back. She can probably fill you in better than I can.
[14:10] <czajkowski> deryck: happens a lot on https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/190848
[14:11] <czajkowski> deryck: and https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/926379
[14:11] <czajkowski> <-- running out door
[14:11] <deryck> ok, thanks czajkowski
[14:12] <tumbleweed> poke: https://code.launchpad.net/~stefanor/wadllib/datetime-924240/+merge/97099
[14:13] <tumbleweed> I'm about to apply that patch in Debian (it works fine for me) but would obviousuly prefer it if it was already merged into trunk
[14:15] <deryck> tumbleweed, benji is the on call reviewer.  perhaps he could look at that branch for you?
[14:15] <deryck> tumbleweed, rick_h would have an interest in this, too, since he did some of the original work but he isn't around right now.
[14:15] <tumbleweed> deryck: yeah, I see LP made him the reviewer
[14:36] <deryck> czajkowski, so I don't see anything recent that could be to blame for the increased instances of this....
[14:36] <deryck> czajkowski, and this seems related to freedesktop.org watched bugs, based on your two examples....
[14:36] <deryck> czajkowski, so either something changed on their end to make this worse....
[14:37] <deryck> czajkowski, or else it's always been happening and the importance or attention given to these bugs is making it seem more common.
[14:37] <deryck> czajkowski, so I'd suggest getting some of the mails showing this attached to the bug report.  I've subscribed to stay informed.
[14:38] <deryck> czajkowski, but if I don't reply timely enough, another ping to me if fair and appreciated :)
[14:38] <deryck> s/if/is
[14:44] <czajkowski> deryck: thanks for the help
[14:44] <czajkowski> I've taken a screen capture of my bug mail
[14:44] <czajkowski> and added it to the bug
[14:48] <deryck> czajkowski, can you add full emails with headers and all?
[14:52] <czajkowski> deryck: done I think
[14:53] <deryck> czajkowski, thanks.  I'll try to dig in more later.
[14:54] <czajkowski> cheers
[15:15] <czajkowski> deryck: you about?
[15:16] <czajkowski> I'm pretty sure I just made a large boo boo error :/
[15:19] <deryck> czajkowski, hey, yes, I'm around.  what's up?
=== al-maisan is now known as almaisan-away
[15:26] <czajkowski> and heart failure over
[15:40] <rick_h> deryck: tumbleweed sorry for the delay, it's on my todo for today. I need to get py3 setup to retest it out.
[15:40] <rick_h> tumbleweed: did you run the tests on both py2 and 3?
[15:40] <rick_h> tumbleweed: we had to hack that in to get things happy on both sides and if that fixes it, we should probably add a test to verify it works with the right date strings on both versions of python
[15:44] <tumbleweed> rick_h: np
[15:44] <tumbleweed> yes, ran it on py2 and 3
[15:45] <tumbleweed> yeah, it could definitly use a test case, but I don't know the code well enough for that
[15:54] <abentley> adeuring: I am working on adding Celery & dependencies to the download cache.  I don't think you need to do it in your branch.
[15:54] <adeuring> abentley: cool
[16:19] <jcsackett> benji: can i throw https://code.launchpad.net/~jcsackett/launchpad/sharing-details/+merge/98223 on to your queue?
[16:43]  * jelmer wished testr gave some progress output..
[17:09] <benji> jcsackett: I'm back from lunch and will look at your MP shortly.
[18:15] <rick_h> abentley: ping, I'm trying to see how I update/get lp-dev-utils correctly?
[18:15] <abentley> rick_h: Okay, how can I help?
[18:15] <rick_h> abentley: so this doesn't appear to be a python pacakge, or a .deb package?
[18:16] <rick_h> abentley: so do I just download it somewhere and add it to path? I'm a bit confused on how it's meant to be used/run
[18:16] <abentley> rick_h: Right, it's a bzr branch.  lp:lp-dev-utils.
[18:16] <abentley> rick_h: Yes, you download it somewhere, and add it to a path.
[18:16] <rick_h> abentley: ok, so it's not meant to set itself up then, just up to me to add it somewhere I can assess it
[18:16] <rick_h> abentley: ok, gotcha, thanks
[18:17] <abentley> rick_h: I have a symlink to ~/launchpad/lp-dev-utils/ec2 in ~/bin
[18:17] <rick_h> abentley: thanks, just wanted to make sure I wasn't missing some package or something
[19:03] <deryck> abentley, hey, man. Since you started to look at it the first time, would you be willing to review my preload people branch now it's ready again?
[19:03] <abentley> deryck: sure.
[19:03] <deryck> abentley, thanks!  https://code.launchpad.net/~deryck/launchpad/buglistings-preload-people-901122/+merge/97041
[19:10] <abentley> deryck: r=me
[19:11] <deryck> abentley, awesome, thanks!
[19:14] <abentley> deryck: I've written dict(foo.id, foo for foo in bar)  a lot, too.
[19:23] <abentley> I'm getting a repeated assertion failure when I do "make run_all".  Anyone else seeing this?  http://pastebin.ubuntu.com/891134/
[19:27]  * deryck heads out for the day with family
[20:44] <sinzui> benji, do you have time to review https://code.launchpad.net/~sinzui/launchpad/project-notify-3/+merge/98282
[20:44] <benji> sinzui: sure
[20:49] <benji> sinzui: done
[20:49] <sinzui> wow. Thank's benji
[20:50] <benji> sinzui: anything to keep me from thinking about performance reviews
[20:53] <sinzui> benji, Indeed. I was depressed writing mine last week. benji Keep in mind that the most important thing you did was help your squad and the Lp team. All personal goals are not more important than the group goals. One year my team missed our personal goals, but it was okay because we responded to the group goals that emerged during the year
[20:54] <benji> sinzui: thanks for the encouragement
=== benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10
[22:03] <lifeless> flacoste: did you want a call ?
[22:16]  * jelmer is reminded why he contributes to launchpad in bursts
[22:19] <salgado> lifeless, we seem to have encountered a weird issue with db updates not being flushed by storm before it executes a query... if you have a couple minutes to help us, it's at https://code.launchpad.net/~linaro-infrastructure/launchpad/notify-workitems-changes/+merge/98231
[22:19] <lifeless> jelmer: because of the excruiating overheads?
[22:20] <lifeless> salgado: looking
[22:22] <jelmer> lifeless: yeahp
[22:22] <lifeless> salgado: the transaction.commit() in prod code is a problem
[22:22] <lifeless> salgado: as in, its a blocking problem; it will cause incorrect behaviour on retries
[22:22] <salgado> lifeless, right, we're not keeping that
[22:23] <lifeless> ok
[22:23] <lifeless> so I have a few thoughts so far
[22:23] <lifeless> firstly, event based email sending is terrible.
[22:23] <lifeless> I do mean that literally, it isn't hyperbole.
[22:23] <lifeless> its a wonderful concept that performs poorly and is hard to customise, extend and reason about
[22:24] <lifeless> salgado: that said, I can see you're building on an existing hook, which means you'd have work to do to change things
[22:25] <salgado> yeah, and probably a lot of work given that this is blueprints
[22:25] <lifeless> (also, the object delta stuff in lazr.restful is a direct cause for dozens of different timeouts)
[22:25] <salgado> heh
[22:26] <lifeless> because doing an in python diff to determine that one message was added to a bug loads multiple MB's of data in an inefficient manner, to reconstruct the knowledge that the API layer had discarded about what it did.
[22:26] <lifeless> I have sketched a new subscriptions API
[22:26] <lifeless> on the list
[22:26] <lifeless> noone has implemented it, and its a bit big to slide into what you're doing, your awesome notwithstanding
[22:27] <lifeless> salgado: anyhow, the diff on that page has a commit() and no flush calls
[22:27] <lifeless> salgado: what happens if the commit is removed?
[22:28] <salgado> lifeless, https://code.launchpad.net/~linaro-infrastructure/launchpad/notify-workitems-changes/+merge/98231/comments/212211
[22:28] <salgado> "Now, it looks like the work item changes are not always flushed to the DB when notify_specification_modified is fired (as the pdb session below shows), so that would explain why the diff looks wrong in some cases."
[22:28] <lifeless> salgado: IIRC the only reason a select wouldn't see new objects is if both the select and the store.add for the objects *both* happen within a block_implicit_flushes() decorator
[22:29] <salgado> it does!
[22:29] <salgado> the subscriber has that
[22:29] <lifeless> well
[22:29] <lifeless> that will cause the behaviour you see :)
[22:30] <lifeless> you might want to figure out why it has that decorator
[22:30] <lifeless> :cn
[22:30] <lifeless> a quick grep shows a lot of event subscribers having it
[22:30] <lifeless> this bothers me
[22:31] <salgado> yeah, all the blueprints-related ones have it
[22:32] <lifeless> and karma
[22:33] <lifeless> this smells to me of some bug patched over
[22:33] <lifeless> if it was e.g. a truism that all event handlers must not permit implicit flushes, we'd have glued it into the event subscription code to avoid the repetition
[22:36] <lifeless> salgado: I would look in annotate for the commit adding the decorator and see what it was part of; look at the MP too probably; and definitely try removing the decorator and seeing what happens
[22:36] <salgado> there seems to be plenty of subscribers not using that
[22:36] <salgado> lifeless, it was added when we migrated to storm, I'm pretty sure
[22:37] <lifeless> sure, but why :)
[22:42] <lifeless> salgado: ok, I'm going to context switch, if you want more chat, ping me again :)
[22:42] <salgado> lifeless, with the reorganization of the code, how I'd go about finding the revision where that was introduced?  the latest commits that touched that code were actually just moving files around... is there a way I can find the first commit which contains a block_implicit_flushes?
[22:42] <lifeless> well, file renames won't affect annotate
[22:43] <lifeless> but code copies will
[22:43] <lifeless> so you can jump back - gannotate will let you do this easil, or you can annotate -r before:lastcommityouknowabout filename
[22:44] <salgado> lifeless, ok, will try that.  thanks a bunch
[22:48] <lifeless> no worries
[22:48] <lifeless> you can also pass a regex to bzr log (and a filename too)
[22:48] <lifeless> or use bzr-search if you have a search index built
[22:55] <salgado> lifeless, I've found, but it doesn't say anything about why it was needed so I emailed the list
[22:59] <wallyworld_> sinzui: bug 959784
[22:59] <_mup_> Bug #959784: Cannot add access to new information type without destoying existing 'Some' access <disclosure> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/959784 >
[23:07] <wgrant> sinzui: https://code.launchpad.net/~wgrant/launchpad/sharing-help-fixes/+merge/98300
[23:07] <sinzui> r=me
[23:09] <wgrant> Thanks.