[12:43] <zul> heylo
[12:45] <mjg59> BenC: Ok, no problem
[11:04] <purpleidea> the newest updates to dapper flight 4 seem to WORK with a brand new inspiron 9400 laptop and SMP is available. don't know if it was you, but if you want me to send you some lovely debugging output, let me know, or i'll also be on the laptop testing team
[11:04] <crimsun> meaning kernel 2.6.15-17.26?
[11:06] <purpleidea> actually .24 although i hadn't played with it in a week or so because of exams so i'm not explicitly saying .24 was the first to work. but it hadn't been for a lot of people for a while
[11:17] <airlied> fg
[11:17] <airlied> doh..
[11:17] <airlied> fg
[12:24] <Lathiat> Hi guys - can anyone clarify the reason for the 2/2 address space split?
[12:26] <crimsun> https://lists.ubuntu.com/archives/kernel-team/2006-February/000678.html
[12:28] <Lathiat> thanks
[03:54] <Mithrandir> BenC: 27862 ; why can't it be built-in?
[03:55] <BenC> because having them built-in is against our whole modular kernel design
[03:56] <BenC> if it's built-in and it is causing a problem, it cannot be unloaded
[03:56] <BenC> or blacklisted
[03:59] <Keybuk> if it's not built-in, it can't be loaded automatically though
[03:59] <Keybuk> which means we force-load it through things like /etc/modules
[03:59] <Keybuk> which ignores the blacklist
[04:06] <Mithrandir> and on the live cd in a way which means there's no way around it.
[04:06] <Mithrandir> it's not a problem to just load it, I'm just not sure it's a good idea
[04:09] <mjg59> BenC: So the 2+2 split seems to be breaking other stuff as well
[04:09] <mjg59> I think we ought to go back to 3+1 and then try to fix hibernate
[04:13] <BenC> yeah, I'm doing that for 18.27, since it's an ABI bump anyway
[04:15] <BenC> Keybuk, Mithrandir: building it in is, IMO, worse than it not loading, or having to force load it through /etc/modules
[04:15] <BenC> there are a lot of mac sound chips that aren't really supported, and loading it causes all kinds of weirdness when it attempts to access false gpio's
[04:16] <BenC> it doesn't really make things really bad off when it loads under those chips, but it looks really bad (lots of stuff in kern.log) and would be impossible to get rid of if built-in
[05:45] <mjg59> BenC: Looks like getting the smart battery driver in was a good move - the Macbooks have them


[02:00] <AimHere26>                   _..._
[06:52] <RoBz13>   ________________ _      .    ____      *
[06:56] <jelly26>             ))))))))(__/~;;\
[06:56] <jelly26>               (((((((((((((\
[06:56] <jelly26>               |           |
[07:03] <ffernand0>                      _..._
[09:03] <ikonia> acheronuk: hello
[09:03] <acheronuk> ikonia: hi. I have about 2 min
[09:03] <acheronuk> mins
[09:04] <Unit193> ikonia: He's Kubuntu op.
[09:04] <ikonia> it's ok - I was just saying hi as I don't think we've spoken
[09:04] <ikonia> yes,
[09:04] <Unit193> Oops, sorry then!
[09:04] <ikonia> no no, it's fine
[09:04] <acheronuk> ikonia: right. nice gesture, but bad timing :P
[09:04] <ikonia> I saw the nick change,
[09:04] <ikonia> acheronuk: that's utterly understandable
[09:05] <ikonia> clearly it's nothing urgent
[09:06] <acheronuk> the server my BNC was connected to got taken down for maintenance, and on reconnect I obviously got the _ on my normal nick
[09:06] <acheronuk> bbl
[12:22] <SolarAquarion27>                      _..._


[00:00] <leonardr> in 'beta', a @mutator_for method is a mutator but it's also published as a named operation
[00:00] <leonardr> so you can set bug.status or you can invoke transitionToStatus
[00:00] <leonardr> post-'beta', a @mutator_for method is only a mutator
[00:01] <leonardr> there was no way to describe this behavior with annotations, so i had to add a new feature to lazr.restful
[00:01] <lifeless> ok
[00:02] <leonardr> i don't know how it might be happening but i have a suspicion that feature is interfering with what we're doing here
[00:02] <lifeless> is that because annotations are per export ?
[00:02] <leonardr> annotations can make something not be a mutator anymore, but they can't change what it means to *be* a mutator
[00:08] <lifeless> ok
[00:08]  * leonardr does what he should have done in the first place and looks at lazr.restful unit tests
[00:14] <leonardr> thumper: the second @operation_for_version is not necessary. @operation_removed_in_version("1.0") automatically bumps the version counter up to 1.0
[00:20] <leonardr> by taking that out i can get setRecipeText to show up in 1.0, but if i make it a mutator in devel it disappears from 1.0
[00:20] <leonardr> so i think there is a lazr.restful bug
[00:22] <leonardr> let me try to duplicate within lazr.restful where it's more convenient
[00:23] <poolie> leonardr, i may well be wrong but i thought i saw lp:kanban give me an edge url to create a token
[00:23] <poolie> even though i updated it to request not to use edge
[00:23] <poolie> it may be something weird here
[00:23] <leonardr> poolie: i'm happy to take a look, but i'm long past eod already
[00:23] <leonardr> and i have this other problem to look into
[00:23] <poolie> np just letting you know
[00:23] <leonardr> k
[00:23] <poolie> if i can reproduce it i'll file a bug
[00:23] <poolie> i may well have just had an out of date tree or something
[00:23] <leonardr> sounds good
[00:33] <wallyworld_> anyone want to claim a code review? https://code.launchpad.net/~wallyworld/launchpad/request-build-popup/+merge/48864
[00:40] <lifeless> wgrant: 4 seconds spent doing portlet calculations AFAICT
[00:41] <lifeless> wgrant: I think I'm going to disable ilike temporarily, announce that, and then work on the portlet after I finish bugtask:+index landing
[00:46] <poolie> wallyworld_, weak +1 on that
[00:47] <wallyworld_> poolie: ?
[00:49] <poolie> your mp looks good to me but i'm not very familar with what you're changing
[00:49] <StevenK> wallyworld_: Why are you moving from .builds to builds_for_recipe()? That change looks spurious to me.
[00:51] <wallyworld_> StevenK: it's needed because there's now 2 places (soon to be 3) that need to call that. and so moving it off SourcePackageRecipeView to a helper method that can be called elsewhere supports that
[00:51] <poolie> leonardr, if you're reading scrollback, it was in fact another reference to edge from kanban
[00:52] <leonardr> poolie: you mean you reproduced the problem?
[00:52] <wallyworld_> StevenK: SourcePackageRecipeView and SourcePackageRecipeRequestBuildsAjaxView use it
[00:52] <poolie> i did, and it's a bug in kanban not lplib
[00:53] <StevenK> wallyworld_: Why can't they just use self.context.builds ?
[00:54] <wallyworld_> StevenK: self.context is a recipe and the builds() logic is in the view
[00:54] <LPCIBot> Project devel build (445): STILL FAILING in 6 hr 26 min: https://hudson.wedontsleep.org/job/devel/445/
[00:55] <StevenK> wallyworld_: .builds for a recipe should still DTRT?
[00:57] <wallyworld_> StevenK: different requirements. recipe has getBuilds() and getPendingBuilds(). the view builds() calls these in order to show all the pending builds and 1-5 recent builds
[00:57] <StevenK> wallyworld_: Hmmmm
[00:59] <wallyworld_> StevenK: the logic to construct the contents of the builds table was already there before my mp. i'm just using it to implement a view that returns just the builds table separately instead of the entire recipe index page
[00:59] <wallyworld_> StevenK:  so that an ajax call can do stuff and then refresh the builds table with the latest info without needing a page refresh
[01:01] <leonardr> thumper: i'm fairly sure there is a lazr.restful bug but i can't reproduce it within lazr.restful
[01:02] <leonardr> i can come back to this in the morning if that's all right
[01:24] <thumper> leonardr: sure
[01:29] <wallyworld_> thumper: the request daily build stuff all working but requires js. do we want to just not show the link if js is disabled?
[01:30] <thumper> wallyworld_: it should be quite possible to have it working without js too
[01:31] <thumper> wallyworld_: pretty trivially even
[01:31] <wallyworld_> thumper: ok.
[01:32] <wallyworld_> thumper: also, where did you want the link? currently i've put it just below the build schedule field (just below where it says "daily build")
[01:33] <thumper> wallyworld_: got a pic?
[01:33]  * wallyworld_ fires up ksnapshot
[01:36] <wallyworld_> thumper: http://people.canonical.com/~ianb/request-daily-build.png  (I don't like the + icon)
[01:37] <wgrant> Can I suggest s/daily/manual/?
[01:37] <thumper> wallyworld_: why do you have a + icon?
[01:37] <wgrant> Requesting a daily build doesn't make a huge amount of sense.
[01:37] <thumper> wallyworld_: how about (build now)
[01:37] <lifeless> how about 'immediate'
[01:37] <lifeless> or now
[01:37] <wgrant> yeah.
[01:37] <wgrant> That.
[01:38] <wallyworld_> thumper: i wanted to put an icon there but am unsure which one is best. perhaps we don't need an icon at all. i think it looks plain without one. but that's just me
[01:38] <wallyworld_> thumper: the + icon is a placeholder
[01:38] <wgrant> It needs an icon. But I don't know of an appropriate one.
[01:38] <thumper> what build icons do we have?
[01:38] <cody-somerville> ugh
[01:38] <wallyworld_> wgrant: while i have your attention - want to be release manager for 11.03? :-)
[01:38] <wgrant> The milestone icon is almost right, maybe.
[01:38]  * wallyworld_ looks
[01:39] <thumper> wgrant: the clock?
[01:39] <wgrant> thumper: Yes.
[01:39] <cody-somerville> Clicking 'Find...' next to 'Assign to:' field when filing a bug takes you to https://bugs.launchpad.net/people/ - making you loose your bug report.
[01:39] <thumper> seems reasonable
[01:39] <wgrant> cody-somerville: I filed that a year or so ago.
[01:40] <thumper> wallyworld_: can you try with the clock icon, and the text: Build now
[01:40] <thumper> wallyworld_: then lets look at the picture
[01:41]  * cody-somerville just had a funny image of flacoste using a spinner from twister to randomly select teams to assign to bugs.
[01:41] <wallyworld_> thumper: i can't see the clock icon in lib/canonical/launchpad/images??? have i missed seeing it or am i looking in the wrong place?
[01:41] <wgrant> wallyworld_: milestone.png
[01:41]  * wallyworld_ nods
[01:42] <wgrant> It is not optimal to overload the icon's meaning. It's mostly used for milestones and series at the moment. But it's the most appropriate thing we have.
[01:44] <wgrant> Although for a lot of daily builds the flame icon might be appropriate...
[01:44] <thumper> heh
[01:45] <thumper> wgrant: there is the "building" icon
[01:45] <thumper> the animated one
[01:46] <wgrant> thumper: But it's animated :(
[01:46] <wgrant> and I don't really like it much.
[01:50] <wallyworld_> hmmm. icon='milestone' in the Link() constructor doesn't work. still get the + icon
[01:50] <wgrant> What's the HTML?
[01:53] <thumper> wallyworld_: it should end up being an anchor with the class="sprite milestone"
[01:54] <wallyworld_> thumper: yeah, still has "sprite add" though. so Link('+request-daily-build', 'Build now', icon='milestone') doesn't seem sufficient
[01:55]  * wallyworld_ tries a make clean
[01:56] <thumper> wallyworld_: you need to restart to see view changes
[01:56] <wallyworld_> thumper: already tried that :-)
[01:58]  * thumper goes to collect the girls
[01:58] <wgrant> OOPS-1872BZR108821
[01:58] <wgrant> That is a lot of OOPSes.
[01:58] <wgrant> And a strange OOPS.
[02:00] <mwhudson> wgrant: is that from a smart server process?
[02:01]  * StevenK blinks at the oops report for Soyuz
[02:05] <wgrant> mwhudson: I presume so.
[02:05] <wgrant> StevenK: Hmm, that's a bit concerning.
[02:05] <wgrant> dpkg accepted the version...
[02:05] <StevenK> Pity it doesn't contain any more information.
[02:06] <wgrant> I will find the upload.
[02:07] <wgrant> 2011-02-15 19:40:56 DEBUG   Verifying source file vdr-plugin-xinemediaplayer_.11-1easyVDR1.tar.gz
[02:07] <StevenK> Neat
[02:07] <wgrant> I'm surprised dpkg-source accepted that.
[02:07] <StevenK> Same.
[02:07] <StevenK> At the very least, that also warrants a dpkg bug.
[02:07] <wgrant> Although maybe not.
[02:08] <wgrant> Why should dpkg-source check the version string?
[02:08] <wgrant> On extraction, that is.
[02:08] <wgrant> On building, maybe.
[02:08]  * wgrant tries.
[02:09] <wgrant> The source package builds fine.
[02:09] <wgrant> I wonder if binaries do.
[02:10] <wgrant> Yup, and dpkg installs them.
[02:10] <wgrant> Baaaaaaah
[02:10] <wgrant> The upstream_version may contain only alphanumerics[33] and the characters . + - : ~ (full stop, plus, hyphen, colon, tilde) and should start with a digit.
[02:10] <wgrant> "should"
[02:12] <wgrant> StevenK: I guess valid_version may want to be fixed. Although we could decide that we don't want to support that, since it's apparently never been done before...
[02:12] <wgrant> What do you think?
[02:13] <wgrant> Interesting.
[02:13] <wgrant> .1 > 1
[02:14] <wgrant> In fact it seems to be greater than just about anything.
[02:14] <wgrant> So it's probably a good idea to reject it.
[02:24] <wgrant>   41 ProtocolError: <ProtocolError for http://downforeveryoneorjustme.com/http://bugs.opencompositing.org/xmlrpc.cgi: 405 Method Not Allowed>
[02:24] <wgrant> Awesome.
[02:27] <lifeless> erm wtf
[02:28] <wallyworld_> thumper: http://people.canonical.com/~ianb/request-daily-build.png
[02:29] <wallyworld_> i don't like the green text with that icon
[02:29] <wallyworld_> blue would be better imho
[02:30] <wgrant> Once we have pervasive JS that might be good.
[02:30] <wgrant> But we'd need to change globally.
[02:30] <thumper> wallyworld_: hmm...
[02:30] <thumper> I don't like that icon
[02:31] <wallyworld_> what about the copy icon?
[02:31] <thumper> wallyworld_: try "yes"
[02:31] <thumper> which is the copy icon?
[02:32] <thumper> do we have any gear icons?
[02:33] <wgrant> thumper: The copy icon is the edit icon.
[02:33] <wgrant> It sucks.
[02:33] <thumper> no, that blows
[02:33] <thumper> sucks and blows at the same time
[02:33] <wgrant> We have a gear icon. But it flashes.
[02:33] <wallyworld_> thumper: hit refresh
[02:33] <wgrant> build-success-publishing.gif
[02:33] <thumper> wallyworld_: that's a maybe
[02:34] <thumper> wgrant: which is that?
[02:34] <wgrant> It's used on Archive:+packages to indicate builds that have finished but are not yet published.
[02:36] <lifeless> grr flakey code
[02:39]  * thumper was looking for that page that shows all the images
[02:41] <wgrant> thumper: +graphics
[02:41] <wgrant> Possibly for the sole purpose of making it ungreppable.
[02:41] <thumper> thanks
[02:42] <lifeless> yay for race condition bugs
[02:42] <lifeless> goes to show, don't make things faster.
[02:42] <wgrant> lifeless: A race on BugTask:+index?
[02:42] <lifeless> wgrant: bug message
[02:42] <wgrant> Ah.
[02:43] <lifeless> see bugcomment.py - group_comments_with_activity
[02:43] <thumper> wallyworld_: what about just using the source-package-recipe icon?
[02:43] <lifeless> if you have two bug comments in the same datetime - and the test can generate 7 in the same datetime sometimes - then the sort order depends on sorted() being stable
[02:43] <lifeless> but its not guaranteed stable
[02:43] <wgrant> Hah.
[02:43] <wgrant> That code was changed recently.
[02:43] <wgrant> The window was just added.
[02:44] <lifeless> orly?
[02:44]  * wallyworld_ looks
[02:44] <wgrant> Previously it only grouped things at the same second.
[02:45] <lifeless> wgrant: I think you misunderstand
[02:45] <lifeless> wgrant: bug comments ordering is the question
[02:46] <LPCIBot> Yippie, build fixed!
[02:46] <LPCIBot> Project db-devel build (369): FIXED in 6 hr 28 min: https://hudson.wedontsleep.org/job/db-devel/369/
[02:46] <lifeless> wgrant: same datetime - doesn't matter if its per second or per day or per ms grouping
[02:46] <lifeless> wgrant: race still exists, need to disambiguate by message.index
[02:46] <lifeless> (though of course, thats *wrong* if we don't fix the bugimporter to use the date of import not the date on the remote tracker.
[02:47] <lifeless> but I'll leave that for the next person that comes in and goes wtf.
[02:49] <lifeless> anyhow, Iwas getting that one time in 3, but I think I've fixed it
[02:49] <lifeless> the race that is
[02:51]  * wallyworld_ needs to add source-package-recipe entry to style-3-0.css.in
[02:53] <lifeless> lp:~lifeless/launchpad/bug-607935 seems to be passing all tests, fingers crossed.
[03:06]  * lifeless waits for diff to update
[03:07]  * thumper shelves current work to wait for LP.client.cache updates
[03:12] <lifeless> I can has review? https://code.launchpad.net/~lifeless/launchpad/bug-607935/+merge/49915
[03:16] <wgrant> lifeless: https://bugs.launchpad.net/bugs/7217/+watch/68410
[03:16] <_mup_> Bug #7217: epiphany-browser: epiphany crashes trying to print <epiphany-browser (Ubuntu):Fix Released by seb128> <epiphany-browser (Debian):Fix Released> < https://launchpad.net/bugs/7217 >
[03:16] <wgrant> We record errors along with their message and the relevant OOPS.
[03:17] <wgrant> I think I will clarify the message and drop the OOPS for most known failures.
[03:17] <wgrant> Perhaps "clarify" is not the correct term for expanding on "Unknown"
[03:20] <wgrant> Except that most of the exceptions appear at the bugtracker level, not the bugwatch level.
[03:20] <wgrant> Argh.
[03:27] <lifeless> wgrant: cool
[03:27] <wgrant> No, not cool.
[03:27] <lifeless> wgrant: easy answer - show the bugtracker health against the bugwatch
[03:27] <wgrant> lifeless: Against all 20000 bugwatches?
[03:28] <lifeless> wgrant: when rendering in a bug
[03:28] <lifeless> they are related, no?
[03:28] <wgrant> Well, sure. But I was hoping for a solution that didn't require DB changes :)
[03:28] <wgrant> But I need new enum values for bugwatch warnings anyway.
[03:28] <wgrant> So we might as well just do this properly.
[03:29] <lifeless> tis always a tradeoff
[03:29] <lifeless> you could squelch the oops, log at info or whatever so there is a record, and file a bug for future improvements.
[03:29] <lifeless> right now users are equally badly off in this proposal.
[03:29] <wgrant> We need a new BugTrackerActivity table and BugWatchActivityStatus.WARNING
[03:30] <wgrant> Once we have those we can notify users adequately.
[03:30] <lifeless> what would the table store ?
[03:30] <wgrant> It would store bugtracker-wide errors.
[03:31] <wgrant> Because of the batch update mechanism, most of the exceptions don't have an associated bugwatch.
[03:33] <wgrant> Has the description textarea on +filebug shrunk, or is it just me?
[03:34] <lifeless> wgrant: do we know the bugwatch(es) that we're /trying/ to update?
[03:34] <lifeless> wgrant: anyhow, such a schema change sounds reasonable
[03:34] <lifeless> wgrant: I only suggest a lower key thing to keep in the spirit of maintenance vs features
[03:35] <wgrant> lifeless: We don't.
[03:36] <lifeless> wgrant: so the api just triggers 'changes since date' or some such?
[03:36] <thumper> wallyworld_: how's that image going?
[03:36] <wgrant> Something like that. I forget the details.
[03:36] <wallyworld_> thumper: &^!@^!@! make was failing
[03:37] <lifeless> seems to me we know then - that case would be 'all bugs'
[03:37] <lifeless> [for that tracker]
[03:37] <wgrant> lifeless: That is a lot of bugwatchactivities.
[03:37] <wallyworld_> thumper: turn out you have to make sprite_image separately or else it all falls in a heap
[03:37] <wgrant> wallyworld_: The sourcepackagerecipe icon wasn't already a sprite?
[03:37] <wgrant> Wait, what is the sourcepackagerecipe icon?
[03:37] <wgrant> Oh, right. Package with a branch.
[03:38] <wallyworld_> wgrant: no. not a sprite already
[03:38] <wallyworld_> but why isn't the sprite_image target invoked for a make clean build or even a make build?????
[03:38] <wallyworld_> if i commit this change, then others will have the same issue, no?
[03:39] <wgrant> The sprite image is committed to the tree.
[03:39] <wgrant> Because it changes once in a fairly long time.
[03:39] <wallyworld_> oh ok
[03:40] <wallyworld_> i didn't realise that. surely though commiting binary blobs that are generate from source is bad :-(
[03:40] <wgrant> Plus the location calculation is not entirely deterministic.
[03:40] <wgrant> Yes, it is.
[03:40] <wgrant> Rather bad.
[03:40] <wallyworld_> it's not as if sprite_image takes more than asecond or so to run either
[03:40] <wgrant> But people don't seem to mind including large trees of other people's code in our tree.
[03:41] <wgrant> So what's a small blob? :)
[03:41] <wallyworld_> so why the fark don't we just run it as part of make
[03:41] <wallyworld_> i just wasted a looong time figuring this out :-(
[03:41] <wallyworld_> wgrant: one small blob is a blob too many :-(
[03:43] <wallyworld_> thumper: http://people.canonical.com/~ianb/request-daily-build.png
[03:44] <wallyworld_> thumper: can we/i fix the !!@%@!^& makefile?
[03:44] <wgrant> wallyworld_: You may want to check with a LOSA.
[03:44] <wgrant> Also make the positioning stuff deterministic.
[03:44] <wallyworld_> or do you agree with commtting the sprite image blob?
[03:44] <spm> hrm?
[03:44] <wgrant> When I rebuilt it Monday a couple of things changed order.
[03:45] <wallyworld_> wgrant: so what did you do to account for the ordering change
[03:45] <wgrant> spm: Where is 'make build' done on production?
[03:45] <wgrant> wallyworld_: Nothing, because I didn't end up committing my changes.
[03:45] <spm> on each prod server
[03:45] <wallyworld_> spm: we are committing a binary blob (the sprite image file) when imho it should be built
[03:45] <wgrant> wallyworld_: We need to be careful that we don't end up with different files across the frontends, I think.
[03:46] <wgrant> Or caching may get a bit odd.
[03:46] <wallyworld_> wgrant: so how did you know things changed order?
[03:46] <spm> wallyworld_: by sprite - this is a picture?
[03:46] <wgrant> wallyworld_: icon-sprites.positioning changed.
[03:47] <wallyworld_> spm: yeah, it's a binary blob of all our little icons that are displayed next to links etc - a combination of the individual png files if you like
[03:47] <wallyworld_> wgrant: so in that case both files would need to be committed and it should just work
[03:47] <spm> so why do you want to build that on each server? it'd be pretty static - build and control it yourself?
[03:48] <wgrant> wallyworld_: Which files?
[03:48] <spm> esp aiui, this'd only need building on 2 servers - can you get the granularity down such that it *only* builds on 2 of the 30 odd?
[03:48] <wallyworld_> spm: committing blobs which are built from source artifacts is imho fundamentally wrong and bad practice
[03:49] <spm> building on 30 servers, something needed on 2, is also ... wrong. :-)
[03:49] <wallyworld_> spm: make build should do it
[03:49] <wallyworld_> it only takes a second
[03:49] <wallyworld_> spm: the makefile targets should only build what's required
[03:50] <wallyworld_> for each deployment target
[03:50] <spm> yesssss. so does every other little build. which is why  a nodowntime rollout takes from 60-90 minutes.
[03:50] <wallyworld_> s/target/environment
[03:50] <wallyworld_> spm: it could be done before rollout though - part of creating the rollout directory image
[03:51] <wallyworld_> oh, you said nodowntime
[03:51] <spm> actually - step back a bit here - *what* builds this? what tools are needed?
[03:51] <wallyworld_> spm: make sprite_image builds it
[03:52] <spm> does that need imagemagik or something?
[03:52] <spm> I guess - how often do these change?
[03:52] <wallyworld_> its a tool in the bin directory which also does other sprite related stuff (css file generation etc)
[03:52] <wgrant> It uses PIL.
[03:52] <wgrant> So it should be fine.
[03:53] <wallyworld_> spm: they don't change often
[03:53] <spm> just checking we don't suddenly introduce a bunch of crackful deps to add to prod. :-)
[03:53] <wallyworld_> it's more a philosophical thing, plus i just wasted shitloads of time cause i expected make to build what it needed
[03:53] <spm> heh
[03:54] <wallyworld_> by philosophical, we are talking about what consistutes best practice etc
[03:54] <spm> ha. don't make me pull out the page on argument fallacies. ;-)
[03:54] <spm> I guess in the overall scheme of things, go for it. add it to the makefile.
[03:55] <wallyworld_> spm: i likely won't change the makefile, once i build a bridge and get over my frustration
[03:55] <wallyworld_> spm: clearly oeple smarter than me did it that way for a reason :-)
[03:56] <spm> rules are there so you think about breaking them. not to be followed blindly. :-)
[03:56] <wallyworld_> :-)
[03:57] <wallyworld_> try telling that to my wife
[03:57] <spm> wives are an exception to all rules, except their own. QED.
[03:57] <wallyworld_> you are a wise man
[03:57] <poolie> hi spm
[03:57] <spm> heya poolie
[03:59] <spm> wallyworld_: my 2c for something like this: that doesn't change often and all, denormalise - commit the binary blob and wear the overhead there - to get a bigger saving in prod/deploy/build. but each case has exceptions.
[03:59] <wallyworld_> spm: fair enough
[04:00] <poolie> +1 for naked juggling
[04:00] <wallyworld_> poolie: ha de ha ha
[04:00] <spm> if it had funky deps on code changes and such? then you make build on each server per normal; but if it's largely standalone. shrug.
[04:00] <wallyworld_> poolie: i don't think you really would want to see that
[04:00]  * spm afks to fetch lad from school
[04:03] <wallyworld_> thumper: you around?
[04:18] <wgrant> Daily builds for this recipe will not occur.
[04:18] <wgrant> There is no PPA.
[04:18] <wgrant> That sounds a little dramatic.
[04:19] <wgrant> wallyworld_: Do you know much about the daily build archive widget?
[04:19] <wallyworld_> wgrant: depends on what you want to know :-)
[04:20] <wgrant> wallyworld_: The picker popup needs spinners.
[04:20] <wgrant> The list takes a while to load, leaving the popup empty for a couple of seconds.
[04:20] <wallyworld_> wgrant: because it takes time to load them up?
[04:20] <wgrant> Then when you move to another page the number changes immediately, but the contents take a couple of seconds.
[04:20] <wgrant> In both cases I think the contents should be replaced with a spinner.
[04:20] <wgrant> Or something like that.
[04:20] <wallyworld_> wgrant: yeah, i just wrote a popup form and added a "Loading..." spinner for the same reason
[04:21] <wgrant> Also there is a vast amount of padding at the bottom of the popup.
[04:21] <wgrant> Ah, because there is an unused footer slot.
[04:21] <wgrant> Deleting that makes things marginally more sensible.
[04:22] <wgrant> It seems to be a general picker issue.
[04:22] <wgrant> is that lazr-js?
[04:22] <wallyworld_> wgrant: i think the best thing is to file a bug so it's in the system
[04:22] <wgrant> wallyworld_: Sure, I'm just wondering where to file it.
[04:22] <wgrant> Is it LP, is it Code, is it lazr-js?
[04:22] <wallyworld_> wgrant: yeah, the base picker.js is in kazr-js from memory
[04:23] <wgrant> Otherwise the AJAXyness of SourcePackageRecipe:+index is pretty awesome.
[04:23] <wallyworld_> wgrant: i'd file against launchpad since the issue manifests itself in the recipe area. that's imho
[04:24] <wallyworld_> wgrant: once my mp lands it will have even more ajax
[04:24] <wallyworld_> the request builds link uses a popup form with a no-pageload refresh of the current builds table
[04:24] <wgrant> wallyworld_: Ah, other pickers have a search widget where the search icon turns into a spinner.
[04:25] <wgrant> The daily builds ones do not.
[04:25] <wgrant> I will file against launchpad.
[04:25] <wallyworld_> wgrant: that was my thinking - that the root cuase lay in how the picker was being used, hence a lp issue
[04:40] <wgrant> wallyworld_: bug #719785, bug #719788, bug #719795
[04:40] <_mup_> Bug #719785: Recipe owner and archive pickers need spinners <recipe> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/719785 >
[04:40] <_mup_> Bug #719788: Recipe archive picker has an empty footer <recipe> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/719788 >
[04:40] <_mup_> Bug #719795: Recipe archive picker items are twice the required height <recipe> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/719795 >
[04:40] <wallyworld_> wgrant: thanks. thumper will be ecstatic :-)
[04:41] <wgrant> Heh.
[04:43] <wgrant> I also have some suggestions for the builds table, but I think they might cause thumper to leap over the Tasman and strangle me.
[05:10] <thumper> hmm....
[05:11] <thumper> wgrant: I'm open to suggestions
[05:11] <thumper> wgrant: do the pickers not have any spinners?
[05:11] <wgrant> thumper: They don't :(
[05:11] <thumper> wgrant: that's a problem
[05:12] <wgrant> thumper: I'd prefer the builds table to be more like Archive:+packages. A single row per source, only showing binaries if they are not yet built or have failed.
[05:13] <StevenK> wgrant: Hm, do you know off-hand if the sampledata has another account enabled except<EMAIL_ADDRESS>[05:13] <wgrant> Archive:+packages' implementation is rather flawed. But you have the opportunity to experiment and improve upon that.
[05:13] <thumper> wgrant: not really
[05:13] <thumper> wgrant: we are moving off recipes into maintenance shortly
[05:14]  * thumper goes to make dinner
[05:14] <wgrant> StevenK<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>[05:14] <wgrant> thumper: :(
[05:15] <StevenK> wgrant: Thanks
[05:15] <StevenK> Not allowed here reproduced for recipes with a disabled archive.
[05:15] <StevenK> Which is a little O.o
[05:16] <StevenK> Oh, let me guess. The security proxy is such that if the archive is disabled, only the owner can see it?
[05:16] <wgrant> That's right.
[05:16]  * StevenK grumbles
[05:17] <StevenK> I'll fiddle the browser code to give us 'Disabled archive' rather than unathorized
[05:21] <lifeless> wgrant: are you talking the +dailybuilds thing, or the per-user recipes list?
[05:21] <wgrant> lifeless: SourcePackageRecipe:+index
[05:26] <lifeless> thumper: will the daily builds page we spoke about get fixed before you rotate off?
[05:27] <wgrant> Can I search through OOPSes for a particular exception without grepping through $lots?
[05:27] <lifeless> not yet
[05:32] <wgrant> Oh, I can see lp:oops-tools now. That is handy.
[05:33] <wgrant> Ahhhh
[05:34] <wgrant> Most of these OOPSes used to be in a warnings subsection of the checkwatches OOPS report.
[05:34] <lifeless> still covered by zop
[05:35] <wgrant> Should they be?
[05:35] <wgrant> Remember we have UFD and go.
[05:35] <wgrant> *co
[05:36] <wgrant> OffsiteFormPostError, UnexpectedFormData, InvalidBatchSizeError all OOPS but are in a separate section of the report.
[05:36] <wgrant> Still, some of these checkwatches OOPSes record no information beyond what is put in the DB, so they can go.
[05:37] <lifeless> unless we're going to take action on it, they shouldn't be logged.
[05:37] <lifeless> We have significan space issues with oops
[05:37] <wgrant> Oh, do we?
[05:37] <lifeless> yes
[05:37] <wgrant> :(
[05:37] <lifeless> plus rsync overhead, processing on devpad etc
[05:38] <wgrant> True.
[05:38] <lifeless> oops should be things /we/ need to take action on
[05:43] <spm> ^^ this! :-)
[05:49] <wgrant> lifeless: Caps!@
[05:50] <wgrant> Also, bug #28506 is probably not the one you are looking for...
[05:50] <_mup_> Bug #28506: It should be possible to install xchat instead of xchat-gnome <ubuntu-meta (Ubuntu):New> < https://launchpad.net/bugs/28506 >
[05:51] <lifeless> wgrant: context?
[05:51] <lifeless> do you mean 268508 ?
[05:53] <wgrant> lifeless: Your blog post says 28506
[05:53] <lifeless> grah
[05:53] <lifeless> edit-fail
[05:53] <lifeless> the right link is earlier
[05:54] <lifeless> fixed
[05:55] <lifeless> wgrant: thanks
[05:55] <wgrant> lifeless: I'd also retitle it something like "Bug searches no longer match target names", I think.
[05:55] <wgrant> But perhaps not.
[05:56] <lifeless> thats more accurate and less relevant or understandable IMO - I did consider it
[05:56] <lifeless> but something like 99.9% of multi context searches will be package related
[05:56] <wgrant> s/target/source package/, then.
[05:56] <lifeless> that would be a lie
[05:56] <wgrant> But caps and short is important.
[05:59] <wgrant> Thanks.
[05:59] <wgrant> If it didn't show up on https://launchpad.net/ I would not be so pedantic.
[06:02] <poolie> wgrant, i agree
[06:02] <poolie> 'read the blog' is bad style too
[06:36] <lifeless> 'read the blog'?
[06:38] <wgrant> Down the bottom of the recent blog post listing.
[06:39] <wgrant> I don't have much of a problem with that, though.
[06:41] <LPCIBot> Project devel build (446): STILL FAILING in 5 hr 47 min: https://hudson.wedontsleep.org/job/devel/446/
[06:41] <LPCIBot> * Launchpad Patch Queue Manager: [r=jtv][bug=710591] Fix translation import script to use old-style
[06:41] <LPCIBot> imports on source packages if no upstream project is configured.
[06:41] <LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][no-qa] Split portlet setup for subscriber widgets from
[06:41] <LPCIBot> bugtask-index.js.
[06:41] <LPCIBot> * Launchpad Patch Queue Manager: [r=jtv][ui=none][bug=716586] Allow converging diverged translation
[06:41] <LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][bug=718849] Do not escape revision author if the name and
[06:41] <LPCIBot> email are None.
[06:41] <LPCIBot> * Launchpad Patch Queue Manager: [r=leonardr][bug=719162] Make buildd pointer check regexes work on
[06:41] <LPCIBot> natty
[07:58] <lifeless> grrrrah
[07:58] <lifeless> series_buglistings makes me sad
[08:01] <thumper> lifeless: probably not...
[08:01] <thumper> lifeless: but on the bright side, if it is a timeout, it'll get addressed early
[08:44] <poolie> hi jml?
[08:45] <jtv> gahmorning folks
[08:46] <poolie> hi jtv
[08:46] <henninge> Hi jtv!
[08:46] <poolie> are you in nl?
[08:46] <jtv> yes
[08:46] <jtv> hi henninge!
[08:46] <lifeless> stub: if you have time, would appreciate a review of https://code.launchpad.net/~lifeless/launchpad/bug-607935/+merge/49915
[08:46] <stub> k
[08:47] <jtv> hey stub
[08:47] <stub> jtv: Tell me about your standing desk and where you got it.
[08:47] <poolie> i'd like to know that too
[08:47] <stub> 1) Fly to Bangkok
[08:47] <jtv> stub: HomePro—it's not a desk and I've seen the same equipment in other countries.
[08:48] <jtv> Basically built myself a rack.
[08:48] <stub> Assemble it yourself stuff?
[08:48] <stub> Or some sort of stackable shelving?
[08:55] <lifeless> does anyone know of existing statistics apis within lp ?
[08:55] <StevenK> lifeless: As in download statistics? More information?
[08:56] <lifeless> as in 'get the open bug counts for all the active series of ubuntu'
[08:56] <lifeless> I mean in the source tree, not the json APIs
[09:01] <mrevell> Hello
[09:02] <poolie> hi mrevell
[09:02] <poolie> would you like to have a look over https://dev.launchpad.net/LEP/BuildFromBranchIntoPrimary for me?
[09:05] <mrevell> poolie, Sure. With a view to user testing?
[09:06] <adeuring> good morning
[09:09] <poolie> yes, or communication/announcement/etc
[09:09] <poolie> well, more communication
[09:11] <StevenK> bigjools, wgrant: I suspect allenap could use a hand to QA r12383.
[09:12] <allenap> Indeed. I don't have the foggiest about how to QA that one.
[09:12] <bigjools> we need to get mup to show commit messages when it sees rNNNNN
[09:13] <allenap> Well, apart from saying dogfood.
[09:13] <bigjools> pedigree chum to the rescue
[09:13] <allenap> bigjools: Good idea.
[09:13] <mrevell> Thanks. I'll take a look later  my morning  poolie and email you some proposals.
[09:13] <allenap> Who's the mupmaster?
[09:14] <bigjools> gustavo IIRC
[09:14] <poolie> thanks
[09:15] <poolie> ok i've got to go, may be on again later
[09:16] <bigjools> allenap: I'm not sure that's QA-able.  I don't recall seeing any weird effects in production from the bug  - although I expect the memory would grow.
[09:16] <wgrant> Aha.
[09:17] <allenap> bigjools: We would need to add builders after starting the buildmaster, then observe how often they're scanned. But that sounds pretty hard to do.
[09:17] <bigjools> allenap: yes
[09:17] <allenap> The code change is a single line so perhaps we can rely on visual inspection alone.
[09:18] <wgrant> It is not at all hard to do.
[09:18] <wgrant> Add a new virtual builder that does not exist.
[09:18] <wgrant> It will remain enabled.
[09:18] <wgrant> Despite the scans failing.
[09:18] <allenap> Interesting :)
[09:19] <bigjools> you would need to rely on the log output
[09:19] <wgrant> In other news, I have a bzr-sftp locally with 6 fifos opened without connections.
[09:19] <wgrant> I may have reproduced the leak.
[09:19] <wgrant> Yay.
[09:19] <wgrant> poolie: Around?
[09:20] <poolie> wgrant, yay, that's greaot
[09:20] <poolie> i have to go out now
[09:20] <poolie> may be back in about an hour
[09:20] <poolie> vila is here
[09:20] <wgrant> k
[09:22] <vila> *blink*
[09:22] <vila> paramiko leaks ?
[09:23] <wgrant> vila: No, I am trying to reproduce the forking service disaster.
[09:23] <vila> got that, and no, paramiko may leak threads, not sockets (IIRC)
[09:23] <vila> when you say fifo you mean pipes ?
[09:24] <wgrant> Right.
[09:24] <vila> k, np, just checking
[09:38] <vila> wgrant: did you check with jam ? I think it was working on it yesterday
[09:41] <wgrant> vila: it seems that I may have actually exceeded the FD limit for a moment, so it crashed and failed to close sockets for a few seconds, which I initially missed due to the logs going by so quickly :(
[09:41] <wgrant> So the FD leak was because we were already exhausted.
[09:41] <wgrant> Still, we should probably avoid leaking in that case.
[09:42] <vila> that's my understanding yes, the symptom is hitting the FD limit but the cause is the leak
[10:10] <stub> bigjools: Where you working on dropping sourcepackagename/binarypackagename links for a few selected cases, or across the board?
[10:15] <bigjools> stub: otp
[10:15] <bigjools> one mo
[10:15] <stub> np
[10:22] <bigjools> allenap: I'll QA that buildd-manager change for you
[10:23] <bigjools> allenap: although there is a buildd-manager on staging so you could do it with some losa fu
[10:54] <danilos> stub, hi, is there any better (as in less intrusive) way to change a DB column default value other than with a DB patch?
[10:55] <danilos> stub, (I guess I can use the constructor, but that kinda sucks)
[10:55] <stub> danilos: The only way to change the DB column default is with a DB patch. If you are using the constructor, you are doing something different.
[10:56] <danilos> stub, right, I understand that, thanks
[10:57] <bigjools> stub: since changing everything is such a ridicuously massive and invasive change, I was planning on adding a name column to spr/bpr for now, and then gradually migrating certain things
[10:57] <stub> If you put a default value into Python code for some reason, we should update the DEFAULT on the column too or else confusion will happen.
[10:57] <bigjools> we may never be able to get rid of BPN/SPN because of bug targets
[10:57] <stub> bigjools: I thought one or two tables at a time might be best.
[10:58] <stub> bigjools: You dropping the foreign key too?
[10:58] <bigjools> which FK?
[10:58] <stub> bigjools: The existing references to the spn/bpn tables
[10:59] <bigjools> stub: where possible, yes, I need to analyse
[10:59] <stub> bigjools: There is no point having both a TEXT column containing the name, and a foreign key reference to the (hopefully identical) name in spn/bpn.
[10:59] <bigjools> quite
[11:00] <bigjools> it depends on what code needs it and how easy it is to fix
[11:00] <stub> bigjools: So if there is a db patch adding the new TEXT column and not dropping the old spn/bpn references, open a bug and have XXX's referencing it in the model code.
[11:01] <bigjools> mais oui
[11:01] <bigjools> I need to audit all the stuff that uses bpr.name / spr.name
[11:02] <danilos> stub, that's why I was asking if there was a less intrusive change, just changing it in python is effective for our tests, but I'd like to fix the default in DB as well
[11:03] <stub> Don't consider it intrusive :-)
[11:04] <dpm> jtv, would you have some minutes to see how we can recover the en-US.xpi Lucid + Maverick template and reupload it now that the Firefox bug in LP has landed?
[11:05] <jtv> dpm: ah yes… can we do that after lunch?
[11:05] <danilos> stub, heh, it's intrusive to my development process: I can land entire branch onto devel, and this one little bit (DB patch) has to go to db-devel :)
[11:05] <dpm> jtv, sure, I'll ping you later on then
[11:05] <stub> danilos: The db patch doesn't have to be part of the same branch.
[11:06] <stub> But yeah, two branches to land vs. one.
[11:34] <danilos> stub, so, can you please take a look at https://code.launchpad.net/~danilo/launchpad/db-bug-718809/+merge/49952 ? :)
[11:35] <stub> k
[11:36] <stub> danilos: So what do we do with the 1.3 million entries that have been set to the previous default of True ?
[11:38] <stub> (And 131 people have already twiddled their knob)
[11:39] <danilos> stub, we want to keep it as is
[11:40] <danilos> stub, at least that's my understanding: we do not want to change values for existing users, just for new ones
[11:41] <stub> So existing users keep the original behavior (unless they twiddle the setting), and new users default to no selfgenerated notifications?
[11:41] <danilos> stub, and I believe that's pretty explicit in bug 718809 description
[11:41] <_mup_> Bug #718809: New users should default to not receiving email for their own actions <story-better-bug-notification> <Launchpad itself:In Progress by danilo> < https://launchpad.net/bugs/718809 >
[11:41] <danilos> stub, that's right
[11:43] <stub> r=stub
[11:44] <danilos> stub, cheers
[11:44] <danilos> stub, do you think I should update the sample data before landing?
[11:45] <stub> danilos: I wouldn't. I don't think changing the default for new users warrents changing the sampledata (by definition, contains existing users).
[11:46] <stub> Matches production better too ;)
[11:46] <danilos> stub, right, but 'make lint' issues a warning already, so I somehow suspect that somebody has failed to update it after running all the DB patches (probably some which migrate data)
[11:47] <danilos> stub, so I am only asking if I should re-make sampledata after a clean 'make schema' :)
[11:47] <stub> Up to you then. I'm not fussed myself.
[11:47] <danilos> stub, cool, I'll just ignore it then and leave it for someone who actually does a more invasive patch :) ta
[11:47] <stub> If you are landing now, go for it to minimize future conflicts.
[11:49] <danilos> stub, heh, ok then
[11:55] <danilos> stub, actually, the differences seem irrelevant: http://paste.ubuntu.com/567629/
[11:55] <danilos> stub, should I file a bug against the schema linter about this?
[11:56] <stub> If you want. Seems benign enough. I don't know what is doing the check or how easy it is to modify.
[11:57] <stub> danilos: Maybe not - we actually do want it to bitch in this case, to ensure devs keep up to date with PG releases and in particular are using the correct major release.
[11:58] <danilos> stub, oh, I thought you'd be the one who has implemented the check: the lint warning is very long and kind of annoying as you can see in the MP :)
[11:58] <stub> (different releases causing ordering to be different and making diffs huge)
[11:58] <stub> Not me :-)
[11:58] <danilos> stub, right, but this is a minor rev and that sucks :)
[11:58] <stub> Think I run lint? Ha!
[11:58]  * stub runs
[11:58] <danilos> stub, haha
[12:04] <danilos> now, how does an OCR find a reviewer? :)
[12:06] <deryck> Morning, all.
[12:20] <danilos> deryck, good morning :)
[12:32] <bigjools> danilos: (or any translations dude), is this valid or a dupe?  https://bugs.edge.launchpad.net/launchpad/+bug/719903
[12:34] <danilos> bigjools, it is definitely a bug, but it's likely related to the recent translations work; henninge, do you know if it's a dupe?
[12:34] <danilos> deryck, or perhaps you? :)
[12:35] <henninge> danilos: dunno, busy atm
[12:39]  * deryck looks at bug
[12:40] <deryck> bigjools, danilos -- not a dupe that I know of.
[12:41] <bigjools> any code people around?  this one's a bit weird https://bugs.edge.launchpad.net/launchpad/+bug/719901
[12:41] <_mup_> Bug #719901: No web access to lp:language-selector <Launchpad itself:New> < https://launchpad.net/bugs/719901 >
[12:41] <bigjools> https://code.launchpad.net/~ubuntu-core-dev/language-selector is fine but  https://code.launchpad.net/~ubuntu-core-dev/language-selector/ubuntu is not
[12:48] <wgrant> bigjools: Probably the private bug.
[12:48] <wgrant> I can see it fine.
[12:48] <wgrant> Because I can see apport bugs.
[12:49] <wgrant> What is the traceback you see?
[12:50] <bigjools> meh didn;t think to look down there, yeah it's a bug
[12:51] <bigjools> wgrant: why can you see apport bugs then?
[12:52] <wgrant> bigjools: Because I'm in ~ubuntu-dev.
[12:52] <bigjools> ah right
[13:13] <gary_poster> Can anyone be my bzr pipeline mentor at the moment? :-)  sync-pipeline didn't work, as Aaron warned me privately it might not since I used reconfigure-pipeline.  I got
[13:13] <gary_poster> Creating new pipe at lp:~gary/launchpad/bug164196/.bzr/pipes/bug164196
[13:13] <gary_poster> bzr: ERROR: Permission denied: "~gary/launchpad/bug164196/.bzr/pipes/bug164196/": : Cannot create branch at '/~gary/launchpad/bug164196/.bzr/pipes/bug164196'
[13:13] <gary_poster> I then tried lp-propose
[13:13] <gary_poster> and that seems to want to propose everything for the same push branch
[13:14] <gary_poster> which doesn't seem to work so well either
[13:14] <gary_poster> danilos, do you happen to have any wisdom for me?  I think you use pipelines
[13:16] <jml> easy documentation branch up for review: https://code.launchpad.net/~jml/launchpad/silence-sphinx-errors-and-warnings/+merge/49965
[13:16] <danilos> gary_poster, hum, you can always deal with branches individually, and perhaps even remove the branch from LP (if it has no MPs already) and then re-push (or maybe even just bzr push --overwrite)
[13:17] <gary_poster> danilos, so just bzr push branch 1, then bzr next and bzr push branch 2 to someplace explicitly?
[13:17]  * gary_poster tries
[13:19] <danilos> gary_poster, well, you should have separate branches in the repo as well, so you should be able to access them; not sure how it works if you are using a shared repo with working dirs included
[13:19] <danilos> jml, I'm taking a look
[13:19] <danilos> jml, what does double colon do?
[13:20] <jml> danilos: signals that the indented bit up ahead is quoted text.
[13:20] <jml> http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#literal-blocks
[13:20] <danilos> jml, ok, was it the intention to remove it on line 22?
[13:20] <danilos> jml, thanks
[13:21] <jml> danilos: yes, because that's a list.
[13:21] <jml> let me double check the output
[13:21] <jml> yeah, looks right.
[13:23] <danilos> jml, r=me, thanks, looks much better like this :)
[13:23] <jml> danilos: thanks.
[13:24] <danilos> bigjools, btw, I am somehow guessing your removal of a tag from deryck is unintentional: https://bugs.edge.launchpad.net/launchpad/+bug/719903 :)
[13:26] <bac> hi mrevell
[13:32] <jml> build is broken.
[13:32] <mrevell> hi bac
[13:49] <bac> hi leonardr
[13:49] <leonardr> hi bac
[13:50] <bac> leonardr: regarding my merge proposal from yesterday, the whole point was simply to add the 3rd party stuff and update the tools.  i should've been more explicit, but after 'make jsbuild' you'll see the gallery-accordion is included in launchpad.js and the accordion CSS is included in combo.css
[13:51] <leonardr> bac: ok, r=me
[13:52] <bac> thanks leonardr
[14:06] <abentley> deryck, sorry I'm late.  Did I miss the whole meeting?
[14:07] <deryck> abentley, yeah.  it was only adeuring and I, since henninge_ is also away momentarily.
[14:07] <abentley> ah, okay.  Well, we've got our chat in an hour, right?
[14:09] <deryck> abentley, sorry, crashed.  if I missed anything else you said.
[14:10] <abentley> deryck, no worries.  I just said "Well, we've got our chat in an hour, right?"
[14:10] <deryck> abentley, yes.  we can catch up then.  Thanks!
[14:10] <bigjools> danilos: crossing edits.... we *really* need to fix that :/
[14:15] <wallyworld> gary_poster: hey, can you recommend anyone in your squad who i could persuade to be the next release manager? :-)
[14:16] <jml> om nom nom
[14:16] <gary_poster> wallyworld, thanks for reminding me.  I was going to actually poll them, after reading your well-penned email of the past 12 hours.  Let me do so...
[14:17] <wallyworld> gary_poster: thank you. i lied about being able to ride a unicycle
[14:18] <wallyworld> gary_poster: i've asked a few people (not from your squad) already but haven't had any luck so far
[14:18] <bigjools> wallyworld: I can ride a unicycle
[14:19] <wallyworld> bigjools: i don't believe you - prove it. go on, i double dare you
[14:19] <bigjools> heh, shall I sent you a picture?  I need to take it first of course.
[14:20] <wallyworld> bigjools: you mean you'll need to google it and the fire up gimp
[14:20] <gary_poster> wallyworld, my world is ruined by your lack of unicycle-riding!
[14:20] <wallyworld> gary_poster: is there anything else i can do naked to make up for it?
[14:20] <bigjools> wallyworld: I don't need to use gimp of course, google will find everything you ask for :)
[14:20] <gary_poster> I've heard of bigjools' vaunted unicycle riding prowess for years now, but it actually has not been proved in my presence, I now realize
[14:20] <bigjools> heh
[14:21] <gary_poster> wallyworld lol no really that's fine :-)
[14:21] <wallyworld> hmmm. but he does know how to wield a gun. i've seen it with my own eyes
[14:21] <bigjools> wallyworld: are you threatening to go naked?  I'm sure that'll get a new RM pretty quick actually
[14:22] <wallyworld> bigjools: well, i was going to attach a photo but the super macro lens on the camera broke so you couldn't see anything anyway
[14:22] <bigjools> ouch :)
[14:24] <gary_poster> wallyworld, benji has gracefully acquiesced to being volunteered.  I don't think he's hoping for any of the naked activities in recompense, but you can clarify that with him directly.
[14:24] <benji> to be perfectly clear: "naked activities" void the offer
[14:25] <gary_poster> lol
[14:25] <wallyworld> benji: i've never said this to another man when i haven't been drunk, but i love you :-)
[14:25] <benji> heh
[14:25] <benji> I have that effect on people.
[14:25]  * gary_poster enjoys laughing
[14:25] <bigjools> get a room guys
[14:26] <benji> :)
[14:26] <wallyworld> bigjools: it's room 216 at the Shady Pines if you're interested
[14:26] <bigjools> I'll take my cameras out
[14:27] <wallyworld> you have a macro lens then?
[14:29] <bigjools> I think I'd better stop here before I get into trouble :)
[14:30] <bigjools> sinzui: is it possible to turn a project into a project group?
[14:30] <sinzui> No
[14:30] <bigjools> thanks
[14:31] <henninge> deryck: back ;-)
[14:32] <deryck> hi henninge.  wb! :-)
[14:34] <leonardr> danilos, please review https://code.launchpad.net/~leonardr/lazr.restful/promote-write-operation-to-mutator/+merge/49976
[14:34] <leonardr> i'm here if you have questions
[14:36] <allenap> Is the removal of colour on the "Report a bug", "Ask a question", etc. links intentional?
[14:37] <allenap> The "Get Involved" links.
[14:38] <bigjools> and bug title
[14:38] <bigjools> as someone said the other day, did someone die? :)
[14:39] <gary_poster> flacoste, putting benji as release manager helps out the team, but hurts the squad's feature development.  Should the RM be on a bug rotation squad, or should the decision ignore current rotations?
[14:39] <bigjools> gary_poster: I had that very discussion with my team this morning
[14:39] <flacoste> gary_poster: i say ignore rotations
[14:40] <gary_poster> ok thanks flacoste
[14:40] <flacoste> i don't think it should come from bug rotation as a rule
[14:40] <jml> allenap: yes.
[14:42] <allenap> jml: I was quite fond of the colour :-/
[14:42] <sinzui> allenap: yes
[14:42] <jml> allenap: of which one exactly?
[14:42] <sinzui> allenap: but there is an open discussion about whether to use an official Lp colour for these special links
[14:43] <sinzui> we do not have any official colours
[14:43] <jml> allenap: in any case, it's a work-in-progress. there was some discussion about this yesterday on either this channel or #launchpad
[14:43] <jml> allenap: I'll ask huwshimi to send an email about it all to the list.
[14:43] <sinzui> allenap: before we return to colour, we want to get the font-sizes corrected. I have a work-in-progress
[14:44] <allenap> jml: I was fond of all of them. I just wondered if it was an accident really. If someone has a plan then I don't really want to bikeshed, tempting though it is.
[14:45] <allenap> sinzui: Interesting.
[14:45] <jml> also, the build has been broken for about an hour now.
[14:48] <adeuring> henninge: could you help me with qa for bug 702468?
[14:48] <_mup_> Bug #702468: First upstream translation does not replace Ubuntu-only translation <qa-needstesting> <upstream-translations-sharing> <Launchpad itself:Fix Committed by adeuring> < https://launchpad.net/bugs/702468 >
[14:49] <henninge> adeuring: I am currently doing something similar for my fix, so I don't think you need to do anything. It requires l o s a help for imports and such.
[14:50] <henninge> I will cover that in my QA.
[14:50] <adeuring> henninge: cool, thanks!
[14:56] <danilos> leonardr, back from lunch, taking a look now
[14:56] <leonardr> tx
[15:01] <gary_poster> danilos and abentley, https://code.launchpad.net/~gary/launchpad/bug164196-1/+merge/49973 https://code.launchpad.net/~gary/launchpad/bug164196-2/+merge/49977 and https://code.launchpad.net/~gary/launchpad/bug164196-3/+merge/49980 are available for review.
[15:01] <gary_poster> abentley, thank you for your pipeline help.  I had used reconfigure so I ran into the problem you described with sync.  For now I just pushed individually.  Next time hopefully I'll start without reconfigure
[15:02] <gary_poster> Then I can wee what the expected behavior is :-)
[15:02] <abentley> gary_poster, you're welcome.
[15:02] <gary_poster> heh, see
[15:12] <danilos> leonardr, I assume there are tests for mutators working correctly otherwise? (since your test only "proves" that it stops providing a method)
[15:13] <leonardr> danilos: yes, there are. a mutator is just a write operation that doesn't show up in lookups
[15:14] <leonardr> i could add a test that the mutator works in 3.0
[15:16] <danilos> leonardr, right, thanks
[15:16] <danilos> leonardr, if there are already tests for that elsewhere, no need to imho
[15:17] <danilos> leonardr, just one more question: is it still possible to keep a method and make it a mutator? (i.e. have set_value keep working in 3.0)
[15:18] <leonardr> danilos: no, because there's no point in having a named operation that duplicates the effects of a mutator
[15:18] <leonardr> the situation we have here is where we made a mistake--this should have been a mutator method all along
[15:19] <leonardr> but we can't change an old version for backwards compatibility reasons
[15:19] <danilos> leonardr, well, I can imagine someone wanting to keep both so you don't have to port client code, no?
[15:20] <danilos> leonardr, maybe that'd be hidden by things like launchpadlib instead, so I am just wondering
[15:20] <leonardr> danilos: this falls into the category of 'if you don't want to port code, don't use the new version'
[15:20] <leonardr> it's an easy change to make
[15:21] <danilos> leonardr, ok, as long as it's recognized as being a use-case (or not), I think it's fine; some explicit documentation might be useful, if you agree
[15:22] <danilos> leonardr, anyway, with that considered, r=me
[15:22] <leonardr> thanks
[15:22] <danilos> leonardr, thanks for the fix! :)
[15:23] <danilos> leonardr, oh, are you also getting lazr.restful updated for LP as well?
[15:23] <danilos> abentley, have you started on any of Gary's branches?
[15:24] <abentley> danilos, no, was on a call.
[15:24] <leonardr> danilos: that's next. i'm going to do a release and thumper will incorporate the new version with his branch that needs the fix
[15:24] <danilos> abentley, ok, I am starting with the first one, and I'll make sure to claim the one that I am working on
[15:24] <danilos> leonardr, excellent, sounds good
[15:24] <abentley> danilos, cool.
[15:30] <danilos> gary_poster, re -1, in lib/lp/bugs/model/bug.py you modify addCommentNotification to add activity parameter, but you don't modify addChange which I believe does a similar thing for non-comment changes — is that intentional or not?
[15:31] <gary_poster> danilos, intentional.  addChange uses change objects, which handle activities themselves.
[15:31] <danilos> gary_poster, ok, cool
[15:35] <danilos> gary_poster, r=me on the non-DB stuff, and I am guessing stub will give you patch number 45 :)
[15:36] <gary_poster> danilos, cool, thank you :-)
[15:41] <abentley> gary_poster, re: your other branch, it seems like you're changing the meaning of date_emailed to be "date_processed".  Did you consider changing that in your patch?
[15:43] <abentley> gary_poster, did you consider making is_omitted a "status" enumeration instead?  Values could include PENDING, SENT, SKIPPED.
[15:44] <danilos> abentley, whoops, I just claimed that one as well, perhaps gary_poster will have to request another review from you
[15:44] <gary_poster> abentley, date_emailed: you are quite right.  I didn't consider it for very long, because I didn't think the win merited the database disruption.  In the abstract, I'd agree 100%, and if stub said that I shouldn't worry about the disruption, I'd be fine with it.
[15:44] <abentley> gary_poster, I see.
[15:45] <abentley> danilos, hmm.  You shouldn't have been able to claim the review after I did.  Stale page?
[15:45] <danilos> abentley, perhaps
[15:45] <gary_poster> danilos, abentley, atually things are fine.  danilos is on -2 and abentley is on -3
[15:46] <danilos> gary_poster, ah, ok :)
[15:46] <abentley> gary_poster, danilos: confirmed.
[15:48] <gary_poster> abentley, enumeration: I didn't, and I suppose this is a "in for a penny, in for a pound" sort of thing.  By that I mean that I questioned the wisdom of including the flag now at all, without proof of its necessity, but I leaned towards wanting it anyway.  An enum would be cleaner, and I'd be fine with that if you wanted to request it.
[15:49] <abentley> gary_poster, since we're creating a field either way, I recommend doing a status enum.
[15:50] <gary_poster> abentley, cool, +1
[15:54] <abentley> gary_poster, in the doctest, why are you reversing the order of the notifications?
[15:54] <gary_poster> abentley, so that you see them in the order they happened in the doc test
[15:55] <gary_poster> we get the last eiht
[15:55] <gary_poster> eight
[15:55] <gary_poster> but then they are in reverse chronological order
[15:55] <abentley> gary_poster, ah.  Missed the meaning of "-" in "-id".
[15:57] <abentley> gary_poster, I think ResultSets support slicing.  If so, getting a ResultSet might be clearer.
[16:02] <jtv> henninge: we've been seeing some problems with the branch approver not approving templates that it can't figure out a decent name for.  How about we let the domain default to the project name?  (The approver will back off when it sees duplicate names anyway)
[16:02] <henninge> jtv: sounds reasonable
[16:03] <henninge> jtv: glad you found the reason for those non-approvals.
[16:03] <gary_poster> abentley, ok, I agree in principal, and will see if I can figure out what needs to be done.
[16:03] <jtv> henninge: I thought this case was covered somehow, but AFAICT it was simply something we hadn't gotten to yet.
[16:03] <abentley> gary_poster, cool.  I don't feel strongly about these changes, so r=me.
[16:03] <gary_poster> ok, thank you very much abentley
[16:05] <danilos> gary_poster, fwiw, the variable name "person_causing_change" was chosen as the most descriptive one, after my reviewer (bac, I think) had trouble following code, so perhaps "actor" is not the best choice :)
[16:05] <gary_poster> danilos :-P :-) ok, I can revert that part
[16:06] <gary_poster> it just helped with line length
[16:06] <danilos> gary_poster, not necessarily if you think you'd find it obvious who 'actor' is when you first look at the code
[16:07] <bac> gary_poster, danilos: i think it changed from "person" so "actor" is still an improvement.
[16:07] <danilos> bac, true
[16:08] <danilos> gary_poster, bac, it's just hard for me to say if it's clear enough with so much background already
[16:08] <danilos> gary_poster, so, I'd say it's up to you
[16:08] <jam> vila, wgrant: From what I've been able to piece together, hitting the FD limit causes us to half-create connections, which then leak handles for future connections
[16:08] <gary_poster> ok, cool, bac, danilos.  I'll see if I can fit the longer version in nicely, and if it is annoying, I'll leave it with "actor".  Thank you
[16:08] <jam> so hitting the limit is both a symptom and a cause
[16:09] <benji> leonardr: I sent a general email to the -dev list, but I want to bring https://dev.launchpad.net/yellow/JavaScriptAPIAccessDraft to your attention specifically in case you have things to add.
[16:09] <vila> jam: but you shouldn't even approach the FD limit or you can't scale right ?
[16:09] <leonardr> benji, will take a look
[16:09] <danilos> gary_poster, now, a more relevant question: is there no better way to figure out if a change is of a certain type than process activity.whatchanged? it kind of looks fragile to me
[16:09] <jam> vila: well, what I don't understand is why the existing code doesn't have the same problem. However, we can't serve more than 200 concurrent connections from a single process anyway.
[16:10] <vila> jam: so I thought you were approaching it *because* you had leaks
[16:10] <jam> It looks like this might be a little bit less
[16:10] <leonardr> benji: it occurs to me that we might be duplicating some work. do you know about blue squad's project to make things more widget- and event-oriented?
[16:10] <jam> vila: nope, just more connections than we thought
[16:10] <jam> somebody mentioned that there might be *5* handles per child
[16:10] <jam> which would only give us 200 max connections, instead of 250
[16:10] <jam> and the issue is that if we hit 200 for a second, then we leak a couple of handles
[16:10] <jam> so that then our max becomes 180
[16:10] <jam> then 150, then ...
[16:10] <jam> etc
[16:11] <vila> what's the point of forking if you don't keep the fd local to the forked process but not in the parent ?
[16:11] <jam> vila: wrong fork
[16:11] <jam> there are 3 processes involved
[16:11] <jam> 1 is the master Conch twisted ssh process
[16:11] <benji> leonardr: nope, I wasn't aware.  I was mostly writing down how things are, but I didn't know that a project to improve it was ongoing.
[16:11] <jam> which handles taking SSH encrypted data over the socket
[16:11] <jam> and turns it into stdin/stdout for a child process
[16:11] <jam> this has always been a single process
[16:12] <jam> though it used to "exec" a new bzr child
[16:12] <vila> O_o
[16:12] <jam> (subprocess.Popen)
[16:12] <jam> what seems to have changed
[16:12] <jam> sec
[16:12] <jam> what *I* changed
[16:12] <jam> is that instead of "subprocess.Popen()"
[16:12] <jam> now connect to this existing service
[16:12] <jam> and ask it to fork
[16:12] <jam> so that it already has all the state ready for the response
[16:13] <jam> What may have also changed
[16:13] <jam> is that when we hit the fd limit
[16:13] <jam> we don't fail gracefully
[16:13] <jam> and that we may have more handles per-child now
[16:13] <gary_poster> danilos, gmb gave acivities to me as the best way around, if I linked the notifications and activities as I did in the first branch.  whatchanged is the raw source for the (new, computed) attributes "attribute" and "target".  Using them would be more apt, perhaps, but arguing that it was more robust would be...doable but not super strong, IMO.  The argument would have to be that target and attribute were actually
[16:13] <gary_poster> what we cared about, and by pointing at those two, if there were changes, we'd at least be pointing at the semantically correct values so maybe they would have a higher chance of being robust in the future.  Actually...
[16:13] <jam> though we shouldn't.
[16:13] <leonardr> benji: ok, i'll look at your document, our system will build on top of what you're describing rather than replacing it
[16:13] <jam> If we do, then it is probably a bug for me.
[16:14] <jam> vila: And the way we will scale up is by putting more Conch SSH process behind an HAProxy load balancer
[16:14] <jam> which we want to do anyway
[16:14] <gary_poster> ...danilos, what I could do is move the normalization of duplicateof into the computed attributes
[16:14] <gary_poster> that would be more correct
[16:14] <gary_poster> and then I could rely on target and attribute
[16:14] <gary_poster> rather than whatchanged
[16:14] <gary_poster> which are really one and the same, but, eh, maybe it is better :-)
[16:15] <benji> leonardr: is what you're working on similar to the PATCHPlugin?  I.e., it integrates with the YUI widget machinery to let you do REST calls as the result of widget/form operations?
[16:15] <danilos> gary_poster, it's just that it kind of seems wrong to me to process data that we have produced based on data we still have (if we still have it)
[16:15] <danilos> gary_poster, also, get_key would definitely benefit from having a docstring about what is it really doing :)
[16:16] <leonardr> benji: yes, it uses the PATCHPlugin
[16:16] <vila> jam: oh
[16:17] <gary_poster> danilos, not sure I follow "process data that we have produced based on data we still have" in context.  If I do understand you, which I might not, then we do not have that data anywhere other than in these activity objects.
[16:17] <leonardr> it will also let you set up a hook function to be run when a certain field of the context changes
[16:17] <gary_poster> danilos: get_key docstring, yeah, I saw that when I was writing the MP, but I was suffering from fatigue ;-)
[16:17] <gary_poster> I'll add one
[16:17] <benji> leonardr: is your work purely for in-place editing or it it also for forms with ok/cancel buttons
[16:17] <danilos> gary_poster, right, my question is basically, do we have it in a form that's more suitable for processing (i.e. as target/attribute)? if not, whatchanged is what we'll have to live with
[16:18] <danilos> gary_poster, and fwiw, I wouldn't mind a unit test or two for get_key either
[16:18] <gary_poster> danilos, target/attribute is the closest we can get (as far as I've been told and as far as I've seen myself), and those are computed attributes based off of whatchanged
[16:19] <gary_poster> so I think asking me to use target/attribute is reasonable, a good idea, and yet also kind of minor
[16:19] <danilos> gary_poster, right, then I guess it's ok as-is
[16:19] <gary_poster> ok
[16:19] <danilos> gary_poster, heh, if it is minor, please do, if not, no worries
[16:19] <gary_poster> unit test for get_key, ok :-)
[16:20] <gary_poster> danilos, I meant minor as in not that important, but it probably won't be too bad.  I can give it a whirl.
[16:21] <gary_poster> rephrase, I meant minor as in not that important, but it probably will be relatively easy.
[16:21] <danilos> gary_poster, oh, my only worry is that "whatchanged" will be changed in the future, and our code might be silently broken
[16:22] <danilos> gary_poster, so, if we make sure we have parsing in only one place, that reduces the chances of that happening
[16:22] <gary_poster> danilos, I worried about that a bit, which is why I went a bit overboard in the tests for this.  I could go even farther "overboard" and considered it
[16:22] <jam> vila: https://bugs.launchpad.net/launchpad/+bug/717345/comments/14
[16:22] <_mup_> Bug #717345: Updates to SFTP server leak file handles in use_forking_server mode <Launchpad itself:In Progress by jameinel> < https://launchpad.net/bugs/717345 >
[16:22] <jam> see the last paragraph
[16:22] <gary_poster> and would be willing to, as I mentioned in the cover letter
[16:23] <gary_poster> danilos, ok so summarizing so we're clear, here's what I'll do
[16:23] <gary_poster> 1) add docstring and unittest for get_key
[16:23] <leonardr> benji: for ok/cancel buttons you'll add a custom widget and hook it into this system
[16:24] <benji> interesting
[16:24] <jcsackett> deryck: do you have any idea why diff overlays on lp.dev don't size remotely the same as diff overlays on lp.net? display appears to be YUI related, which is why i'm coming to you.
[16:24] <gary_poster> 2) move duplicateof code to target computed attribute code, and add test
[16:24] <gary_poster> 3) change get_key to use target/attribute
[16:24] <gary_poster> danilos, yeah?
[16:24] <danilos> gary_poster, yep, sounds good
[16:24] <gary_poster> cool, on it
[16:25] <danilos> gary_poster, great, thanks
[16:25] <gary_poster> thank you
[16:27] <jtv> henninge: can you think of any problems with my approach?  po/messages.pot for project Foo will have domain Foo, name foo.
[16:29] <deryck> jcsackett, no idea off the top of my head
[16:29] <jcsackett> well darn. :-P
[16:29] <benji> leonardr: do you know when your work will be usable by others?
[16:29] <deryck> jcsackett, I'm grabbing something to eat before the tl call next hour, but I can help you look it over after all that
[16:29] <deryck> different CSS linked in devmode maybe?
[16:29]  * deryck goes to eat now
[16:29] <leonardr> benji: the event-based stuff is still in the theoretical stage
[16:30] <benji> -
[16:30] <jcsackett> deryck: enjoy, and thanks. :-P
[16:30] <leonardr> for the widget stuff, there's no reason why you can't do it now--you just have to decide to buckle down and consolidate your javascript code into a widget
[16:35] <henninge> jtv: You will need some name mangling
[16:36] <henninge> jtv: project "Foo Bar", domain "Foo_Bar", name "foo-bar"
[16:36] <jtv> henninge: selbstverständlich :)_
[16:36] <henninge> jtv: oh, that was the project name, like in the URL, right?
[16:36] <henninge> so that's quite useful already
[16:36] <jtv> Yes, but even so, I take it the mangling is already there.
[16:37] <henninge> hm
[16:37] <jtv> Because a filename can contain all the weird stuff that project names can.
[16:37] <henninge> right
[16:37] <jtv> If not, well, then I'll add it and we'll have fixed another subtle bug.  :-)
[16:41] <jcsackett> sinzui: i have just discovered there will be maintenance folks in my apartment all afternoon, which makes mumbling hard. move to sometime soonish or to tomorrow morning?
[16:49] <sinzui> jcsackett: can talk in 1.5 hours or after. Any time really. I wanted to talk to you anyway about the UI for seeing feature flag changes
[16:49] <jcsackett> sinzui: so like 1:30? should work for me.
[16:50] <lifeless> moin
[16:50] <sinzui> jcsackett: okay
[16:51] <danilos> gary_poster, I've approved your branch, but if you want, I'd be happy to take a look at incremental diff (as I said in a comment)
[16:52] <danilos> abentley, thanks for the review, btw :)
[16:52] <gary_poster> danilos, awesome, thanks.  how much longer are you around today?
[16:52] <abentley> danilos, np.
[16:52] <danilos> gary_poster, probably another 30 mins or so
[16:53] <gary_poster> danilos, ok, I won't make it by then.  I'll decide whether to wait for you once I'm done with the revision.  I think you'll be happy with the changes.
[16:54] <danilos> gary_poster, yeah, I am confident I will be, but I might stick around for a full hour, so try me :)
[16:54] <gary_poster> danilos :-) ok cool
[16:58] <danilos> gary_poster, oh, one more thing, can you please check if the test runner really picks up a unittest.TestCase tests (eg. a TestGetEmailNotifications) from a file with no explicit loadTestsFromName() call (I vaguely remember that not happening in the past, but I am not too sure about it)
[16:59] <gary_poster> sure danilos
[16:59] <jtv> good night folks!
[16:59] <danilos> gary_poster, actually, I've tried it out myself, and it does :)
[17:00] <gary_poster> ok cool :-)
[17:00] <danilos> jtv, good night
[17:00] <gary_poster> thank you
[17:00] <jtv> zzz
[17:00] <leonardr> benji: the only feature i know that collection objects have is 1) the 'entries' attribute which has the default page
[17:00] <leonardr> and 2)  the 'lp_slice' method, which lets you get stuff off of the default page
[17:01] <benji> leonardr: thanks, I'll add that
[17:02] <leonardr> but i suspect nobody uses collections, judging from what i've seen
[17:02] <gary_poster> leonardr that doesn't mean we shouldn't
[17:02] <benji> yeah, I share your suspicion, that's probably why I couldn't find any examples to learn from
[17:09] <jml> although using lp.testing.TestCase is better than unittest.TestCase for a whole heap of reasons.
[17:13] <leonardr> benji: look at lib/lp/code/browser/sourcepackagerecipe.py for an example that uses the InlineEditorPicketWidget
[17:13] <leonardr> the widget itself is tested in lib/lp/app/doc/lazr-js-widgets.txt
[17:14] <leonardr> that's the direction we'd like to move in. it would make the javascript much more comprehensible
[17:26] <jml> lifeless: is edge getting less traffic now?
[17:41] <henninge> danilos, jtv-afk: Did I hear you complain about queue approval timing out a lot ?
[17:43] <danilos> henninge, it was mostly jtv, the last approvals I did a week or so ago did not time out for me
[17:44] <henninge> danilos: I cannot approve a template import on qastaging, it times out in ... POFile.updateStatistics!
[17:44] <henninge> which is in _copyPOFilesFromSharingTemplates
[17:44] <danilos> henninge, that's very interesting, if that's timing out, I would expect different filters on +translate page to time out
[17:44] <danilos> henninge, oh
[17:47] <henninge> danilos: do we have a way to exempt a page from the timeout?
[17:47] <danilos> henninge, you can up a timeout per page, I think POFile:+translate already has an exception
[17:48] <henninge> how?
[17:48] <danilos> henninge, look at https://launchpad.net/+feature-rules
[17:48] <henninge> cheers
[17:48] <danilos> henninge, you might need an admin to modify the value though
[17:51] <lifeless> jml: per appserver yes
[17:52] <lifeless> jml: less than it was before? not entirely sure.
[17:52] <lifeless> flacoste: got a minute? I want to talk capacity ...
[17:52] <jml> lifeless: ok.
[17:52] <flacoste> lifeless: i've got 10 minutes
[17:52] <jml> lifeless: was curious since we are still getting edge crashes.
[17:57] <lifeless> jml: thats because we're still using edge
[17:57] <lifeless> jml: we can't get rid of it transparently because of some bugs in launchpadlib/wadl
[17:57] <bigjools> good night all
[17:58] <jml> lifeless: well, yes. Was asking to test a theory. If the crashes are induced by high load and we've got less traffic then I would expect fewer crashes.
[17:58] <jml> lifeless: although I didn't know that we can't get rid of edge transparently
[17:58] <jml> that is a pain.
[17:58] <lifeless> jml: indeed
[17:58] <lifeless> jml: you can run stats and normalise by appserver
[17:59] <jml> lifeless: my curiosity is far more idle than that :)
[17:59] <lifeless> some appservers have crazy configs though; two in particular are configured for 32 threads (they were test instances from the scaling tests, not meant for prod deployment as-is)
[17:59] <jml> huh
[17:59] <lifeless> I have a branch that fixes this as part of the single threaded appserver RT
[18:05]  * deryck goes to finish lunch
[18:09]  * jml goes to get food
[18:09] <lifeless> allenap: btw thats a dupe
[18:09] <lifeless> allenap: I think if you search for person picker you'll find the original
[18:31] <jcsackett> sinzui: mumble? i have had to relocate but think i have found a quietish spot.
[18:31] <jkakar> Out of curiosity, is it possible to change the name of project or project group?  I mean the name used in URLs for bugs, branches, etc.
[18:31] <jcsackett> or given i have already had to move, we can do the usual time if you would prefer.
[18:31] <sinzui> jcsackett: get comfortable, then ping me
[18:32] <abentley> jcsackett, why does your bugs-in-deactivated-pillars branch request reviews from both Robert and Launchpad code reviewers?
[18:32] <dobey> jkakar: i think you have to ping a l-osa to change it
[18:32] <sinzui> jkakar: a ~registry member can change the launchpad-id in the url We want to let the owners do it bug we have not solved the case about know when the URL is not permanent
[18:32] <sinzui> almost everyone in this channel can change a project name
[18:33] <jcsackett> abentley: lifeless was helping me out with some performance issue, i thought i would solicit comment from him directly, but leave it open to usual review.
[18:33] <jkakar> Cool, thanks.  Was mostly curious if it was possible/something we did for folks.
[18:33] <sinzui> jkakar: we can also provide an alias so that old urls do work eg gaim->pidgin
[18:33] <jkakar> sinzui: Ooh, very nice. :)
[18:34] <abentley> jcsackett, ah, cool.  I thought maybe you only wanted a review from Robert, but had requested a second review instead of changing the existing one.
[18:34] <jcsackett> abentley: a very reasonable guess.
[18:35] <jcsackett> sinzui: ready whenever, assuming mumble is cooperating.
[18:37] <abentley> jcsackett, you're changing model code, but you're testing browser code.  That makes this an integration test, so you still need a unit test IMO.
[18:40] <abentley> jcsackett, I recommend using person_logged_in instead of login/logout, which is already importd.
[18:40] <abentley> s/importd/imported.
[18:40] <abentley> jcsackett, I don't understand why you're using both.
[18:42] <jcsackett> abentley: i can agree on the test, and i'll restructure the login/logout bit.
[18:43] <jcsackett> laziness, is the answer, regarding using both. :-P
[18:43] <abentley> jcsackett, you can just change it to a unit test.  I don't think you need an integration test
[18:45] <lifeless> jcsackett: looking now
[18:49] <lifeless> jcsackett: you've done something different to https://bugs.launchpad.net/launchpad/+bug/421901/comments/14
[18:49] <_mup_> Bug #421901: Person:+bugs timeouts <lp-bugs> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/421901 >
[18:56] <henninge> abentley: Your diverged fix looks good, I just QA'd it.
[18:56] <abentley> henninge: cool, thanks.
[19:00] <henninge> lifeless: wasn't there some easy way to generate the list of bugs for the Deployments table on LPS?
[19:01] <lifeless> henninge: there is a bug asking for that
[19:02] <henninge> oh, ok.
[19:02] <henninge> I seem to live in the future, then. ;)
[19:05] <jcsackett> lifeless, abentley: i'll respond shortly. otp.
[19:16] <henninge> deryck: QA done and I requested the deployment.
[19:16] <henninge> I will go home now
[19:16] <deryck> henninge, awesome.  many thanks!
[19:16] <deryck> henninge, all the revs before you are qa-ok?
[19:17] <henninge> deryck: yes, they were Abel's and Aaron's, I QA'ed them, too.
[19:17] <deryck> excellent.  thanks!
[19:17] <deryck> henninge, enjoy your night.  Sorry you had such a long day.
[19:18] <henninge> it dragged on a bit ...
[19:24] <jml> is there a way to specify a build-dep w/ buildout?
[19:24] <jml> i.e. not install_requires
[19:26] <lifeless> jml: I don't think it discriminates between build and run, does it ?
[19:26] <jml> lifeless: that's my question.
[19:26] <lifeless> heh
[19:28] <jcsackett> lifeless: read your comment. the reason for the different join is nothing better than distraction. i'm pushing up changes now--we def want the active flag in the join.
[19:28] <jcsackett> abentley: i'm also creating the unit test. i will push that up shortly.
[19:34] <jml> Error: Picked: Sphinx = 1.0.7 :(
[20:09] <benji> jml: it looks like you need to nail the version by adding "Sphinx = 1.0.7" to versions.cfg
[20:10] <jml> benji: thanks.
[20:11] <jml> benji: I'm thinking now that maybe I should just make the test skip if sphinx isn't available.
[20:11] <allenap> lifeless: Yeah, someone else has marked it as a dupe now. It struck me that it was probably a dupe, but the dupe finder had no luck, and, as it turns out, the master bug's title doesn't really give enough away to help.
[20:12] <lifeless> allenap: well it should be easier to find now
[20:12] <benji> Sphinx isn't an onerous dependency, I wouldn't worry about making in required
[20:13] <benji> and it would be good if there is no barrier to an existing LP developer contributing to the docs
[20:14] <jml> benji: good point.
[20:20] <LPCIBot> Project devel build (447): STILL FAILING in 6 hr 19 min: https://hudson.wedontsleep.org/job/devel/447/
[20:23] <flacoste> jml, lifeless: http://people.canonical.com/~flacoste/lp-bugs-chart/
[20:23] <flacoste> deryck: an example of YUI charts ^^^
[20:25] <deryck> hurrah!
[20:25] <deryck> you lucky link-of-to-yahoo-cdn hacker you!
[20:25] <lifeless> http://webnumbr.com/launchpad-timeout-bugs#
[20:26] <lifeless> http://webnumbr.com/launchpad-oops-bugs.all
[20:26] <lifeless> http://webnumbr.com/launchpad-critical-bugs
[20:36] <flacoste> i prefer my stacked graphs
[20:36] <flacoste> :-)
[20:36] <jam> bzr st
[20:36] <jam> mt
[20:45] <benji> flacoste: are the fractional bugs in the first chart the result of bugs that take longer than a week to fix?
[20:46] <flacoste> benji: no, they are a workaround for http://yuilibrary.com/projects/yui3/ticket/2529972
[20:46] <benji> ah
[20:46] <flacoste> i replace 0 with 0.1 to prevent the graph from being screwed up
[20:48] <benji> too bad non-zero infinitesimals don't exist
[20:57] <leonardr> thumper, i need to leave in a few minutes--can we do a quick mumble?
[20:58] <thumper> leonardr: sure
[21:02] <thumper> StevenK: we can't hear you
[21:02] <StevenK> thumper: Not trying to talk yet
[21:07] <deryck> Later on, everyone.
[21:15] <wallyworld___> thumper: https://code.launchpad.net/~wallyworld/launchpad/recipe-build-now/+merge/49968
[21:16] <wallyworld___> go /nick wallyworld
[21:27] <allenap> Does anyone know a neat way to capture log output in a test? Like a context manager or a fixture?
[21:28] <jcsackett> self._
[21:28] <jml> allenap: addDetail(), there's an example in lp.testing.TestCase, iirc.
[21:28] <jcsackett> ...damn clipboard...
[21:29] <allenap> jml: Sorry, I meant how to capture log output by, for example, calls to log.debug()?
[21:31] <jml> allenap: oh, you add one of the mock handlers
[21:31] <allenap> jml: Ah, yes, like FakeLogger.
[21:33] <jml> allenap: yeah.
[21:33] <allenap> Thank you :)
[21:40] <poolie> hi jml?
[21:44] <jml> poolie: hello
[21:46] <poolie> hey there
[21:46] <poolie> sorry it's so late, i had to do some chores here first
[21:48] <jml> that's ok
[21:53] <wgrant> jam: That's what I found, yes.
[21:53] <wgrant> jam: So once we hit the FD limit, analysis is useless.
[21:53] <wgrant> jam: We need to watch it before it hits :/
[21:53] <jam> wgrant: well, I can reproduce here, and I think I have a handle on how to clean up
[21:54] <jam> so that it isn't useless
[21:54] <jam> I've got 3 patches so far, finishing up the 4th
[21:54] <wgrant> I saw it mostly leaking sockets to the forking master.
[21:54] <wgrant> With only a few fifo handles staying around.
[21:54] <poolie> jml, shall we talk on the phone?
[21:55] <poolie> hi jam, wgrant
[21:55] <jml> poolie: sure, although skype or mumble are to be preferred
[21:55] <poolie> let's try mumble
[21:55] <jml> ok
[21:58] <wgrant> jam: I was able to stably run hammer_ssh against dev with 120 concurrent connections. But FDs occasionally spiked to over 900, because there were more than 200 ssh processes. Any idea what was going on there?
[21:59] <wgrant> 150 was too much, but possibly only because hammer_ssh doesn't actually limit properly.
[22:00] <wgrant> jam: Do you think we need to retain the master socket and stderr?
[22:01] <jam> wgrant: you mean in hammer? or in the Conch service?
[22:01] <jam> we definitely do in the Conch
[22:01] <wgrant> jam: In the Conch service.
[22:01] <jam> because it is used
[22:01] <wgrant> Oh :(
[22:02] <wgrant> We can't just wait for our sockets to close to detect exiting?
[22:02] <jam> as for hammer not rate limiting... it spawns another connection once it closes the handles to the spawned ssh
[22:02] <jam> we could have it wait to spawn until the ssh actually exits
[22:02] <jam> just change the line that sasy "if len(pool) < 200" to "if len(pool) + len(stopping) < ..."
[22:02] <wgrant> Aha.
[22:02] <jam> wgrant: fifo's don't exit like that
[22:02] <jam> unfortunately
[22:02] <wgrant> Bah.
[22:02] <jam> which is why we hold open the socket
[22:02] <jam> because it *does*
[22:03] <jam> roughly
[22:03] <jam> that socket is actually connected to the master, which will inform when the child is finally closed
[22:03] <wgrant> Right.
[22:04] <wgrant> jam: Did you obtain the process listings that I discovered the existence of yesterday?
[22:04] <jam> wgrant: yeah, that is patch 1,2 and I think 3
[22:04] <wgrant> Ah, I see you followed the logs.
[22:04] <jam> wgrant: Conch asks for a new child, starts connecting but can't finish
[22:04] <jam> then the child sits around waiting forever
[22:05] <jam> https://code.launchpad.net/~jameinel/launchpad/lp-serve-child-hangup/+merge/50055
[22:05] <jam> tells the child to hang up after 2 minutes
[22:05] <wgrant> jam: Oh yeah, I worked that out quickly enough.
[22:05] <wgrant> jam: I also looked into the log rotation issue late last night.
[22:05] <wgrant> It strongly suggested that we reached exhaustion at 10:29, not 11:01.
[22:05] <wgrant> Yet the first bad process is from 11:01.
[22:06] <jam> wgrant: certainly, at least the first one
[22:10] <wgrant> jam: But 117*5 is only 600ish. The base is ~10. So we have 400 handles unaccounted for.
[22:10] <wgrant> Unless there were connections staying around with fifos open after the forking service had died?
[22:13] <jam> wgrant: we are missing the log that might tell us about other bad children.
[22:13] <jam> If the server cannot process a request but the child doesn't hang around.
[22:14] <wgrant> Right.
[22:14] <wgrant> I wonder.
[22:15] <wgrant> Once we have it cleaning up, we may also want to bump the FD limit.
[22:15] <wgrant> Argh.
[22:15] <wgrant> Except that I tried that, and then select crashed instead.
[22:17] <jam> wgrant: interesting. I've certainly been reproducing it by *lowering* the FD limit
[22:17] <jam> at 100, I can hammer with 15, but not with 20
[22:17] <jam> ulimit -n 100, hammer --load=20 starts failing, hammer --load=10 passes just fine
[22:18] <wgrant> jam: Well, I was hoping we could get it to stop leaking on failure, then quadruple the failure point so it's safe to run on prod.
[22:19] <wgrant> So we can watch and see if there are any other leaks.
[22:19] <mwhudson> wgrant: probably need to use the poll reactor in that case
[22:20] <wgrant> Probably.
[22:20] <mwhudson> probably should anyway actually
[22:20] <jam> mwhudson: you mean select.poll vs select.select?
[22:20] <jam> or however that translates into Twisted objects
[22:21] <mwhudson> jam: yes, twisted has a few reactors
[22:21] <mwhudson> the default is select
[22:21] <mwhudson> but we'd probably want to use the poll or epoll reactors
[22:21] <mwhudson> and have to, if we want to support > 1024 (?) fds
[22:22] <mwhudson> or you can recompile python with MAX_FD lifted or whatever it is :)
[22:22] <poolie>    robert tries to correct deryck on his understanding of
[22:22] <poolie>    iterations, but fails miserably because deryck is right (or at
[22:22] <poolie>    least taking notes and has the last word, muuuuhahhhh!) :-)
[22:22] <poolie> :)
[22:24] <mwhudson> yeah, that made me laugh too :)
[22:31] <sinzui> wgrant: mumble?
[22:42] <wgrant> jam: Which leaks haven't yet been eliminated?
[22:43] <poolie> jam, couldn't we pass the fd across the unix socket?
[22:43] <jam> poolie: still takes up a fd
[22:43] <poolie> this seems to be getting complicated
[22:44] <wgrant> I think we need to bust the 1024 FD limit.
[22:44] <wgrant> Which means increasing the ulimit and moving to the new reactor.
[22:44] <jam> wgrant: or just getting the haproxy stuff working and using 2 services
[22:44] <wgrant> True.
[22:44] <poolie> well, using poll or similar is probably a good idea anyhow
[22:45] <poolie> jam, so it seems like allowing there to be a state where the child bzr process is started, but it's not connected to conch is just giving an opportunity for trouble
[22:45] <poolie> so i'm suggesting using fd passing as a way to eliminate that, rather than to reduce the number of fds used
[22:46] <jam> poolie: you can still run out of fds while transferring them over the socket.
[22:46] <jam> I also don't know how to do the socket transfer stuff, though I can learn
[22:46] <huwshimi> sinzui: Let me know when you're available to talk about that stuff
[22:46] <jam> so you still have the possibility of the child being open because it couldn't transfer the handles
[22:46] <poolie> gary_poster, is there any reason your apidoc couldn't move to people.c.c and therefore be public?
[22:46] <mwhudson> poolie: i think it documents shipit
[22:47] <mwhudson> or something lame like that
[22:47] <wgrant> But the shipit code is basically public anyway :(
[22:47] <sinzui> huwshimi: I expect 2.5 hours. My daughter are providing an itinerary for the next few hours
[22:47] <gary_poster> hi poolie.  yeah, it probably does, though that coud be adjusted, if it still worked. :-/
[22:47] <huwshimi> sinzui: Sure, no problems :)
[22:47] <poolie> jam, i would expect you would set up the fds before forking
[22:47] <poolie> therefore not start the child at all if something goes wrong
[22:48] <poolie> that's why i say we could avoid the issue of things being half-
[22:48] <poolie> started
[22:48] <jam> poolie: interesting idea, but quite a bit more complex to change the current code. I'm sure it can be done, but it changes a lot of the ordering
[22:49] <poolie> gary_poster, maybe we could even just have two copies, one with shipit and one without
[22:50] <poolie> but as you say people can run it up themselves
[22:50] <poolie> jam, i wonder if it would be worth it if it's safer
[22:50] <poolie> i don't think of using one thread in python to stop another as being a very safe technique
[22:51] <jam> poolie: works quite well in my testing, especially since the one is only blocked on an os.open
[22:51] <poolie> the first iteration worked well in your testing too ;-)
[22:54] <jam> poolie: true, though I'm also testing under these conditions
[22:55] <jam> with running out of file handles, and seeing the cleanup
[22:55] <jam> I'm willing to iterate on this a bit
[22:55] <jam> but it is my EOD right now
[22:55] <poolie> sure, i'm just saying i think it's inherently safer to avoid this stage, all else being equal
[22:55] <poolie> i've used fd passing before
[22:55] <lifeless> jam: poolie: we've 3 weeks to get the next iteration prepped, by default
[22:55] <jam> poolie: then perhaps you'd like to write a patch?
[22:55] <poolie> if i get a chance i will see if it's available in python and how it would fit in
[22:56] <jam> poolie: the 3-4 patches I've put up today, I can see that I can force the service to run out of handles, it complains for a while but still serves what it can
[22:56] <jam> at the end, everything gets cleaned up
[22:56] <jam> and lsof shows it back at pristine state
[22:59] <jam> poolie: I don't see 'sendmsg' in the socket documentation: http://docs.python.org/library/socket.html#module-socket
[22:59] <jam> And "google python sendmsg recvmsg" is a bit lacking
[22:59] <jam> http://bugs.python.org/issue1194378 seems to be an implementation
[22:59] <jam> but looks to only be py 2.7/3.1
[23:00] <jam> which turns out to be a dupe of: http://bugs.python.org/issue6560
[23:00] <jam> which doesn't seem to have a resolution
[23:00] <jam> just a patch
[23:00] <jam> anyway, maybe I'll see you guys later tonight.
[23:04] <poolie> jam, hm, we might need our own C glue, and perhaps at that point it's not worth it
[23:05] <spiv> ctypes might do.
[23:05] <spiv> I'm pretty sure I've heard of people doing this in Python before though.
[23:06] <spiv> (but perhaps with C glue)
[23:09] <spiv> There's http://pypi.python.org/pypi/sendmsg/
[23:11] <poolie> as a c extension
[23:11]  * poolie is looking into bug 720403
[23:11] <_mup_> Bug #720403: bzr server error: "file exists" while taking lock <code-hosting> <Launchpad itself:Confirmed> < https://launchpad.net/bugs/720403 >
[23:11] <poolie> hi spiv
[23:13] <spiv> Right, but at least it's a C extension you don't have to write from scratch yourself :)
[23:20] <wgrant> sinzui: Do you have any suggestions for reducing the DMP spam?
[23:20] <lifeless> wgrant: dmp ?
[23:20] <wgrant> I think I will stop logging errors as errors, and perhaps increase the check interval.
[23:20] <wgrant> lifeless: distribution mirror prober
[23:20] <sinzui> mirror prober
[23:20] <lifeless> ah
[23:21] <sinzui> wgrant: I do not.
[23:21] <lifeless> are you talking about oopses from it, or jus tlogging ?
[23:21] <wgrant> Just logging.
[23:21] <wgrant> It logs some normal probe errors at warning/error
[23:21] <wgrant> And sometimes overruns its window.
[23:22] <lifeless> it should parallelise
[23:23] <lifeless> its heavily driven by mirror speeds
[23:24] <wgrant> It is parallised.
[23:24] <wgrant> Although not completely.
[23:27] <wallyworld> thumper: is there a bug for the "build now" work?