[00:08] <jml> sinzui is probably offline now
[00:08] <jml> btw
[00:08] <jml> we're getting a whole bunch of script failed to run errors
[00:20] <pcjc2> lifeless: Please hold that MP, it is broken
[00:23] <lifeless> pcjc2: ec2 should bounce it
[00:23] <lifeless> how is it bust?
[00:24] <pcjc2> I moved the EXISTS() into the clause generator, but stupidly put it _inside_ the clasuse which is UNION'd when you have more than one tag queried
[00:24] <lifeless> whee
[00:24] <pcjc2> So I moved the EXISTS outside the join, but now have to return "None" for the no-tags passed case
[00:24] <pcjc2> seems like a plan
[00:24] <pcjc2> that's why I shouldn't code when tired
[00:25]  * pcjc2 aims clue-bat at own head
[00:25] <pcjc2> I _thought_ I had run the tests
[00:45] <lifeless> pcjc2: have you pushed?
[00:45] <pcjc2> yes
[00:45]  * pcjc2 hopes this time it is not completely broken
[00:45] <pcjc2> will be worth giving it another quick review though.. as it has changed a little
[00:47] <pcjc2> Only bugtask.py has changed since the last push
[00:47] <pcjc2> I guess real LP developers have lots of irons in the fire at once.. for all the pause-time running tests etc..
[00:48] <pcjc2> high throughput, high latency
[00:51] <lifeless> a bit yeah
[00:52] <lifeless> pcjc2: kicked it off
[00:52] <pcjc2> Thanks
[00:52] <pcjc2> EC2 is a cloud server instance?
[00:53] <lifeless> amazon ec2
[00:54] <pcjc2> ok - had no idea you used Amazon servers
[00:54] <pcjc2> is that just for testing?
[00:54] <lifeless> =yes
[00:57] <lifeless> ok, its away
[01:15] <LPCIBot> Project db-devel build (266): STILL FAILING in 4 hr 23 min: https://hudson.wedontsleep.org/job/db-devel/266/
[01:15] <LPCIBot> * Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12191
[01:15] <LPCIBot> included.
[01:15] <LPCIBot> * Launchpad Patch Queue Manager: [r=abel,
[01:15] <LPCIBot> stub][ui=none][bug=276488] Add a nameblacklist admin field that
[01:15] <LPCIBot> exempty the assigned team from the restriction.
[01:18] <LPCIBot> Project devel build (358): STILL FAILING in 4 hr 28 min: https://hudson.wedontsleep.org/job/devel/358/
[01:18] <LPCIBot> * Launchpad Patch Queue Manager: [r=benji,
[01:18] <LPCIBot> edwin-grubbs][ui=none][bug=696913] Adds doNotSnapshot to fields
[01:18] <LPCIBot> involved in OOPSes with ShortlistTooBigErrors.
[01:18] <LPCIBot> * Launchpad Patch Queue Manager: [r=jml][ui=none][no-qa] Upgrade the version of Twisted that Launchpad
[01:18] <LPCIBot> uses from 10.1 to 10.2, preserving the patch for Twisted bug 4395.
[01:18] <_mup_> Bug #4395: wings3d: merge new debian version <wings3d (Ubuntu):Fix Released> < https://launchpad.net/bugs/4395 >
[01:20] <wgrant> Hmm, those two errors look gmpy-related.
[01:20] <jelmer> wgrant: which ones?
[01:26] <wgrant> jelmer: Hudson's. entitlement.txt and looptuner.txt
[01:26] <wgrant> I don't know why gmpy would be installed there, though.
[01:27] <lifeless> for codehosting ssh exchange performance
[01:27] <wgrant> Uhoh.
[01:27] <lifeless> wgrant: https://lpstats.canonical.com/graphs/CodehostingPerformanceStaging/
[01:29] <wgrant> lifeless: OK, I see your point, but test failures.
[01:30] <lifeless> wgrant: agreed
[01:30] <lifeless> wgrant: not sure whats up there
[01:30] <lifeless> wgrant: given it had to go through bb etc
[01:30] <wgrant> lifeless: I bet buildbot doesn't have python-gmpy installed.
[01:30] <wgrant> I can reproduce locally once I install it.
[01:31] <lifeless> perhaps it wasn't added to the deps?
[01:31] <lifeless> or $something
[01:31] <wgrant> It wasn't, AFAICT.
[01:31] <wgrant> Hmm.
[01:31] <wgrant> Why does codehosting send me the URL to the MP twice?
[01:32] <wgrant> In MP emails, that is.
[01:32] <wgrant> For more details, see:
[01:32] <wgrant> https://code.launchpad.net/~wgrant/launchpad/rebuilds-without-nai/+merge/46070
[01:32] <wgrant> -- https://code.launchpad.net/~wgrant/launchpad/rebuilds-without-nai/+merge/46070 You are the owner of lp:~wgrant/launchpad/rebuilds-without-nai.
[01:37] <thumper> lifeless: that drop is pretty awesome
[01:39] <wgrant> I'd go a bit further than that.
[01:39] <wgrant> Although that could be because qastaging's bzr is broken.
[01:40] <lifeless> is it?
[01:40] <wgrant> bzr: ERROR: Server sent an unexpected error: ('error', 'No module named bzrdir')
[01:40] <poolie> oops
[01:40] <lifeless> heh!
[01:40] <lifeless> jam: ^
[01:40]  * thumper chuckles
[01:41] <wgrant> Is qastaging running the forking lp-serve thing?
[01:41] <lifeless> yes
[01:43] <jam> wgrant: well, the graph is doing "hello" which does work on qastaging
[01:43] <jam> "echo hello | ssh bazaar.qastaging.launchpad.net bzr serve --inet --directory=/ --allow-writes"
[01:43] <jam> however, there is, indeed, something broken
[01:44] <jam> lifeless: is there a place where qastaging log files will be copied, such that I can get a look at them?
[01:45] <jam> knowing who is asking for bzrdir and not finding it would be helpful
[01:49] <wgrant> tellurium's codehosting-access.log is a couple of months out of date on carob :(
[01:49] <wgrant> I wonder if the qastaging stuff doesn't sync yet.
[01:50] <jam> the log file is at /srv/bazaar.qastaging.launchpad.net/qastaging-logs/codehosting/bzr-lp-forking-service.log
[01:50] <jam> or possibly another one
[01:51] <wgrant> Nothing like that on carob.
[01:51] <wgrant> spm: ^^ are qastaging codehosting logs not syncing?
[01:52] <pcjc2> goodnight
[02:05] <lifeless> jam: devpad
[02:05] <jam> wgrant: well, I did check again that running the service locally works, and I can push through local codehosting
[02:06] <jam> lifeless: looking at /srv/launchpad.net-logs/qastaging doesn't have much
[02:06] <wgrant> Hmm, odd.
[02:06] <jam> wgrant: yeah
[02:06] <lifeless> check with losas in -ops
[02:06] <wgrant> jam: There is some stuff under /srv/launchpad.net-logs/staging/tellurium/codehosting.
[02:06] <lifeless> ah, you are
[02:06] <jam> lifeless: no response yet
[02:06] <wgrant> But nothing from qastaging, and nothing since November.
[02:06] <wgrant> So it may have all broken when qastaging was introduced.
[02:07] <wgrant>    811.51s  OOPS-1839REPORTIFSEEN1172  None
[02:07] <wgrant> Yay
[02:13] <lifeless> wgrant: that means something running as 'production'
[02:33] <wgrant> lifeless: I know. I was just surprised to see it being used for something that takes >10 minutes.
[02:34] <wgrant> I thought it would be mostly tiny things that nobody has looked at for 5 years.
[02:36] <lifeless> wgrant: right, so the question is do we want to bless doing this, or move them to another config
[02:39] <wgrant> lifeless: Kill them.
[02:44] <wgrant> I need to do a similar thing to cesium.
[02:44] <wgrant> It uses the ftpmaster config :(
[02:48] <lifeless> wgrant: if you're looking at this stuff, I'd love it if you file some bugs
[02:48] <lifeless> (Or JFDI)
[02:57] <wgrant> lifeless: Or we could adopt your OOPS naming strategy.
[02:57] <wgrant> And then we can delete most of the configs.
 spm: ^^ are qastaging codehosting logs not syncing? <== no. never been setup to
[02:58] <wgrant> spm: :(
[02:58] <lifeless> wgrant: I want to do that
[02:58] <lifeless> spm: please do?!
[02:59] <spm> yeah, am atm. needs rotatin' as well
[02:59] <spm> fwiw, have I ever mention just how much I despise the default twistd logging?
[02:59] <spm> log rotation*
[03:01] <wgrant> Why does Australia fail at summer?
[03:01] <wgrant> Now we are flooding too :(
[03:02]  * spm tries not too feel smug at 650m above sea level
[03:06] <lifeless> spm: thanks
[03:06]  * wgrant throws a few buckets of water at spm.
[03:06] <spm> ta, but we've had enough rain lately. thanks tho! ;-)
[03:08] <wgrant> :(
[03:09] <spm> still overcast today. yeck.
[03:10] <wgrant> The weather today is pretty nice.
[03:10] <wgrant> Except that the ground is so saturated that parts of my floor appear to be exuding water.
[03:10] <wgrant> The humidity is <90%, though, which is a pleasant change.
[03:17] <spm> heh, we all start dying from excessive humidity when it gets above 25%
[03:35] <spm> the yak shaving on tellurium continues. just about in tears of laughter here.....
[03:36] <wgrant> I see we have a directory, but no content. It does sound fun.
[03:48] <spm> I was being excessively optimistic creating the directory, I feel
[03:57] <spm> the yak, be shavéd.
[03:59] <wgrant> Indeed, thanks.
[04:01] <wgrant> jam: There are logs now.
[04:02] <wgrant> /srv/launchpad.net-logs/staging/tellurium/qastaging-codehosting/codehosting/bzr-lp-forking-service.log
[04:05] <spiv> Hmm, did devpad's ssh host key change relatively recently?
[04:06] <elmo> spiv: if by relatively recently you mean months ago, yes
[04:06] <wgrant> It changed from sodium to carob at some point over a month ago.
[04:07] <spiv> elmo: months ago is entirely possible.
[04:07] <spiv> Thanks.
[05:39] <LPCIBot> Project db-devel build (267): STILL FAILING in 4 hr 23 min: https://hudson.wedontsleep.org/job/db-devel/267/
[05:39] <LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12192
[05:39] <LPCIBot> included.
[05:45] <LPCIBot> Project devel build (359): STILL FAILING in 4 hr 27 min: https://hudson.wedontsleep.org/job/devel/359/
[05:45] <LPCIBot> * Launchpad Patch Queue Manager: [r=jml][ui=none][no-qa] Always use Python 2.6.
[05:45] <LPCIBot> * Launchpad Patch Queue Manager: [r=julian-edwards][ui=none][no-qa] Use the uploader db user for
[05:45] <LPCIBot> ppa-add-missing-builds.
[05:45] <LPCIBot> * Launchpad Patch Queue Manager: [r=adeuring][ui=none][bug=697685] Adds validation to
[05:45] <LPCIBot> RequestPeopleMergeView so that persons with PPAs cannot be merged.
[06:05]  * huwshimi is off
[06:08] <wgrant> huwshimi: See you in Dallas.
[06:08] <huwshimi> wgrant: Yeah will do :)
[06:09] <spm> have safe flights guys!
[06:29] <lifeless> wgrant: when are you coming?
[06:38] <maxb> hmm
[06:38] <maxb> We need a way for the code import scheduler to not dispatch multiple jobs for the same svn repository to the same machine simultaneousl
[06:38] <maxb> y
[06:39] <spm> not sure if there's a bug for that; but that's been an operational issue for us before. so +1.
[06:40] <maxb> Because for noteable one-repo-many-projects repositories (like Apache), we now can't start any new code imports, because they take so long to initialize the first time, another job comes along, and kills the long running one with a sqlite error
[06:40] <wgrant> lifeless: I depart at midday on Sunday.
[06:40] <maxb> Of course, this requires figuring out what it means to "be from the same repository"
[06:41] <spm> yes :-)
[06:41] <wgrant> lifeless: Arriving DFW at 15:10
[06:41] <maxb> for which svn has a perfectly good UUID, but I can't think how to get it available in the DB/appservers
[06:42] <wgrant> maxb: Particularly when it is the initial imports that often fail :(
[06:42] <maxb> I suppose one possibility would be to cheat... add external whole-job locking by uuid to bzr-svn, such that it's any new jobs which fail, rather than new jobs killing jobs which have been running for hours
[06:43] <wgrant> I can't think of much beyond making the import take a UUID-based lock.
[06:43] <wgrant> Right.
[06:43] <wgrant> Preferably making the subsequent jobs not really fail at all.
[06:43] <maxb> Possibly adding a new "Skipped" job status, such.... snap :-)
[06:43] <wgrant> But just rejecting them softly, not contributing to failure counts.
[06:43] <jelmer> maxb: I think it'd be more worthwhile to spend time on the new cache format /or/ switch to tdb.
[06:43] <maxb> We are of one mind :-)
[06:44] <maxb> jelmer: My personal experiences with tdb are that it sucks badly once the cache gets into the gigabyte range
[06:44] <maxb> Also the operational pain of needing to rebuild the cache for all code imports makes me weep
[06:46] <jelmer> maxb: It's supposed to scale pretty well even in that regard
[06:46] <jelmer> maxb: It's worked fine for larger branches for me in the past
[06:46] <jelmer> maxb: are you on NFS?
[06:46] <maxb> jelmer: it, uh, doesn't :-)
[06:46] <maxb> I've gone back from tdb to sqlite for performance
[06:46] <jelmer> maxb: Have you reproduced that recently?
[06:47] <maxb> even though it triples the size of the file
[06:47] <maxb> No NFS, just plain local disk
[06:47] <maxb> I wouldn't say *recently*. On the other hand, I've not noticed any tdb updates in Ubuntu in a while
[06:48] <jelmer> maxb: e.g. the bucket sizes are different these days
[06:48] <spm> isn't tdb a tridge/samba thing? ergo perfect already?
[06:48] <jelmer> spm: it's a tridge/rusty thing :-)
[06:48] <spm> near enough... ;-)
[06:49] <jelmer> there's a new format on the way with some improvements, but I'd be really surprised if the current performance is worse than sqlite
[06:49] <maxb> jelmer: hmm. So, you think that might solve the problem of performance sucking unless the entire file was in kernel cache?
[06:51] <jelmer> maxb: that depends entirely on the access patterns of the user
[06:52] <maxb> access pattern: fetching svn rev info for ~1000 new revs
[06:59] <jelmer> that shouldn't require having the entire db in the kernel cache in the current format either
[07:01]  * jelmer gets some sleep
[07:01] <al-maisan> good idea :)
[07:01]  * maxb curses at private code imports causing the code import list pages to oops
[09:02] <adeuring> good morning
[09:38] <wgrant> mrevell: I'd like some advice on the PPA creation and edit UI, if you're free.
[09:45] <mrevell> wgrant, I can be, although my day's pretty full. Is it something we could talk about next week? Perhaps with huwshimi.
[09:45] <wgrant> mrevell: Sure.
[09:45] <mrevell> Thanks. I'll make a note to ask you about it.
[09:49] <wgrant> Thanks.
[10:04] <LPCIBot> Project db-devel build (268): STILL FAILING in 4 hr 25 min: https://hudson.wedontsleep.org/job/db-devel/268/
[10:04] <LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12193,
[10:04] <LPCIBot> 12194, 12195, 12196 included.
[10:12] <LPCIBot> Project devel build (360): STILL FAILING in 4 hr 27 min: https://hudson.wedontsleep.org/job/devel/360/
[10:12] <LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][ui=none][bug=501945] Improve SQL efficiency when
[10:12] <LPCIBot> searching for bugs by tag (Pre-filter by Bug.id)
[10:12] <LPCIBot> * Launchpad Patch Queue Manager: [r=jcsackett,
[10:12] <LPCIBot> Edwin][ui=none][bug=183372] Add a heartbeat to Mailman's xmlrpc log.
[10:12] <LPCIBot> * Launchpad Patch Queue Manager: [r=thumper][ui=none][no-qa] Update loggerhead to get important bug
[10:12] <LPCIBot> fixes and performance improvements.
[11:57] <gmb> Is anyone else finding pushing branches to LP to be really slow or is it just my connection?
[12:05] <deryck> Morning, all.
[13:15] <pcjc2> hi
[13:48] <allenap> mrevell: For the blueprints stats, did you want numbers per project (in the top 50), or just a total?
[13:48] <mrevell> allenap, Per project, if that's okay, purlease
[13:49] <allenap> mrevell: It is totally okay.
[13:49] <mrevell> I have to state that I wasn't on lunch that long ... I just dived back into work without checking my IRC nick.
[13:49] <pcjc2> Is the code for the Launchpad QA Bot available somewhere?
[13:50] <mkanat> Looks like bazaar.qastaging.launchpad.net redirects infinitely, so I can't test loggerhead on qastaging.
[13:51] <lifeless> pcjc2: Its not open sourced yet; it is planned to be
[13:51] <pcjc2> ok - just I was writing something similar for git commits, and wondered if I could steal some ideas, that was all
[13:52] <pcjc2> Design is going to be Git HOOK -> sqlite database with a "work queue" -> gpleda.org robot -> LP
[13:52] <pcjc2> The database in the middle is to absorb any grief which might happen if LP is down when commits come in
[13:52] <pcjc2> Possibly not an issue for the QA bot
[13:52] <mkanat> pcjc2: I'd be surprised if there isn't already such a system for git.
[13:52] <pcjc2> I wouldn't know where to look for it..
[13:53] <mkanat> pcjc2: #git would know.
[13:53] <pcjc2> I'm also writing (going to write) a small patch to our gitweb instance to look for the same "Closes-bug: lp-12345" syntax we intend to use, and link to LP
[13:54] <pcjc2> lifeless: When will that merged bug tag code hit staging?
[13:54] <pcjc2> (Or has it done so already - bug is tagged qa-needstesting)
[13:55] <lifeless> qastaging.launchpad.net has it already
[13:55] <lifeless> I was just going to do a few searches and see how it looks
[13:55] <pcjc2> ok- I was testing on staging
[13:55] <pcjc2> inkscape fails on staging
[13:55] <lifeless> staging is where things with db schema patches, and some specific services are qa'd
[13:56] <pcjc2> damn - also fails on qastaging
[13:56] <lifeless> qastaging is where things that can be continuously deployed are tested
[13:56] <lifeless> works for me
[13:57] <lifeless> I did a search on launchpad for tag -*
[13:57] <lifeless> ok
[13:57] <lifeless> copied the search to production
[13:57] <pcjc2> works now
[13:57] <lifeless> fail
[13:57] <lifeless> you can hit cold cache effects
[13:57] <pcjc2> I had a search URL from staging, changed to "qastaging"
[13:57] <lifeless> staging has 64GB or ram or something small like that
[13:57] <pcjc2> so cold cache -> timeout?
[13:57] <lifeless> db size is 250GB
[13:58] <pcjc2> ok, but there is some improvement on qastaging
[13:58] <pcjc2> one can at least perform the query
[13:58] <lifeless> at this stage in our performance overhaul we generally are happy if it works a second time
[13:58] <pcjc2> I'm amazed that on inkscape, out of 2805 open bugs, there are only 288 without tags
[13:59] <pcjc2> This was the kind of query I originally wanted to do on our bugs (but I realised afterwards that we imported everything with _some_ tag, so it doesn't help so much)
[14:14] <pcjc2> Is there a better place than a bug report to file feature requests / design ideas?
[14:14] <pcjc2> Two ideas in my head right now...
[14:15] <pcjc2> Advanced search link (from inside an existing advanced search) should keep the current search terms selected
[14:15] <lifeless> facet based search
[14:15] <lifeless> strongly desired, very sure its already a bug
[14:15] <pcjc2> It would be nice to do a search, then work through all those bugs - with an added "Next" "Previous" (whatever) nagivation overlayered on the bug page
[14:16] <pcjc2> So one could find all bugs with no tags (for example), then click through them one by one tagging them
[14:16] <pcjc2> without having to go back to the original search
[14:16] <lifeless> a bit like gmail? :) I don't recall seeing a bug for that, but that could be nice
[14:16] <pcjc2> I've not used gmail in ages, so couldn't comment
[14:16] <pcjc2> I was just thinking ... "what am I trying to do.." and "how could it be easier?"
[14:17] <pcjc2> Rather than features for the sake of features
[14:17] <gmb> pcjc2: Are you thinking about multiple bug editing here?
[14:17] <gmb> That's something we've wanted for donkey's ages.
[14:17] <pcjc2> yes and no.. edit one at once, but page through them
[14:17] <gmb> Ah, I see.
[14:17] <pcjc2> bonus points for letting a project save particular search queries they work with often
[14:18] <pcjc2> find all bugs tagged "fruit"
[14:18] <gmb> That would be nice. I can definitely see myself using that.
[14:18] <pcjc2> I don't know how it would be done technically
[14:19] <pcjc2> Perhaps one could add "next bug" and "previous bug" links to every bug page
[14:19] <pcjc2> and then allow a concept of an active filter / search which reduces your view of bugs
[14:20] <pcjc2> would need to think of a UI to specify / show the collection context
[14:20] <pcjc2> IE.. am I looking at the "next bug" assigned to me?
[14:20] <pcjc2> in the project?
[14:20] <pcjc2> In the search results?
[14:25] <allenap> mrevell: How do you want the results ordered? By the number of specifications for each project, or the project name?
[14:25] <gmb> pcjc2: If you could look at a bug in the context of a specific group of bugs it could make sense. e.g.:
[14:26] <gmb> bugs.lp.n/~gmb/launchpad/+assignedbugs/12345
[14:26] <gmb> Though the URL construction logic could be a bit torturous.
[14:27] <gmb> (I think that's how Gmail does it, but I'm not sure).
[14:27] <pcjc2> lots of possibilities once you start wanting to do it for arbitrary searches
[14:27] <pcjc2> I think we should support saving searches as a resource
[14:27] <pcjc2> either against a project, or person / team
[14:27] <gmb> pcjc2: It's on our to-do list.
[14:27] <gmb> Or at least our want-to-do list
[14:28] <gmb> kiko called it "Bug Bags" in 2008, I remember that much.
[14:28] <gmb> Mainly because he told me roughly what that meant and I had to explain it to a lot of people.
[14:29] <gmb> Actually, I think Bug Bags were arbitrary groupings of bugs to which you could add new ones if you wished. A bit like tags but personal to the user.
[14:29] <wgrant> I think they were ordered, too.
[14:29] <wgrant> But I don't think we heard anything about them after UDS Jaunty...
[14:30] <pcjc2> Also - is it me, or is LP missing a "related bugs" feature
[14:30] <pcjc2> where something is not quite a duplicate.. but may be relevant
[14:30] <gmb> wgrant: They're a kiko feature: Kind of ephemeral until lifeless decides to do it.
[14:30] <wgrant> Heh.
[14:30] <gmb> pcjc2: YES.
[14:30] <LPCIBot> Project db-devel build (269): STILL FAILING in 4 hr 26 min: https://hudson.wedontsleep.org/job/db-devel/269/
[14:30] <gmb> A thousand times yes.
[14:30] <LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12197
[14:30] <LPCIBot> included.
[14:30] <StevenK> Rargh
[14:31] <pcjc2> And possibly "blocks bug" / "blocked by bug" relationship between 2x or more bugs
[14:31] <mrevell> allenap, I don't think I mind.
[14:31] <mrevell> allenap, number of specs I s'ppose
[14:32] <pcjc2> quote 'the "bug bag" functionality that will come with LP 3.0'
[14:32] <pcjc2> From https://wiki.edubuntu.org/UDSJaunty/Report/QA
[14:33] <gmb> pcjc2: Bug relationships are my number one thing-to-do.
[14:33] <pcjc2> awesome - then I won't feel the need to file a feature request about that
[14:34] <pcjc2> I'm considering the "bug bag" / bug collection idea though.. (currently looking for docs on the old bug bag idea)
[14:34] <gmb> I really hope that that feature will get assigned to my new squad when its time comes.
[14:34] <pcjc2> what is your squad?
[14:34] <wgrant> mrevell, allenap: https://pastebin.canonical.com/41512/ is the top 50 project blueprint totals, if that's what you're after. mpt asked for it a couple of weeks back.
[14:34] <gmb> (Flacoste, lifeless: Take note, I will cry like a man-baby if we don't get that one).
[14:35] <gmb> pcjc2: The yellow squad. I'm told that we're not going to be the yellow squad for very long, though :)
[14:35] <pcjc2> (Or is it just - when the dev cycle rolls around to your turn for feature development in that area again?)
[14:35] <gmb> pcjc2: Well, we're reorganising, so that's the general plan.
[14:36] <gmb> Basically, you have N squads, N-2 of which are assigned to feature work. The other 2 deal with bugs on a day-to-day basis.
[14:36] <pcjc2> I read the posts about it, sounds like a good plan
[14:36] <gmb> Once a feature's complete, the feature squad becomes a Triage / bugfix squad and one of the existing squads becomes a feature squad.
[14:36] <gmb> pcjc2: The new structure takes effect next week when we sprint in Dallas.
[14:36] <allenap> wgrant: I'm getting some more fiddly stats than that, but thanks anyway :)
[14:37] <wgrant> Ah, OK.
[14:37] <bigjools> wgrant: go. to. sleep.
[14:37] <pcjc2> Not to be ungrateful, but search ought to be more AJAXy
[14:37] <LPCIBot> Project devel build (361): STILL FAILING in 4 hr 25 min: https://hudson.wedontsleep.org/job/devel/361/
[14:37] <LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][ui=none][bug=701947][no-qa] Cull a load of unnecessary
[14:37] <LPCIBot> .count()s in favour of less-expensive SQL.
[14:37] <LPCIBot> * Launchpad Patch Queue Manager: [r=thumper][ui=sinzui][bug=702694] Tweak the text on the
[14:37] <LPCIBot> +daily-builds page.
[14:37] <LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][ui=none][bug=680733] Fix the recipe view's builds so
[14:37] <LPCIBot> broken builds don't get stuck at the top of the list.
[14:37] <gmb> pcjc2: Again, a thousand times yes.
[14:37] <lifeless> hmm, I need to people with PPAs to qa bug 697685
[14:37] <_mup_> Bug #697685: People with PPAs should not be allowed to merge accounts <merge-deactivate> <ppas> <qa-needstesting> <Launchpad itself:Fix Committed by jcsackett> < https://launchpad.net/bugs/697685 >
[14:38] <wgrant> bigjools: I was just resending an ec2 instance that failed because of a conflict
[14:38] <wgrant> !
[14:38] <bigjools> is that the conflict I warned you about? :)
[14:38] <wgrant> Yes.
[14:38] <wgrant> Shh.
[14:38] <pcjc2> gmb: Does this get you something: http://onecall.farnell.com/jsp/search/browse.jsp?N=411+500003+1000224&Ntk=gensearch_001&Ntt=100uF+25V&Ntx=mode+matchallpartial
[14:38] <flacoste> gmb: noted
[14:38] <pcjc2> Might be tied to my session though
[14:38] <flacoste> gmb: why won't you the yellow ones for long?
[14:38] <gmb> flacoste: I think there's a general sense that we want to be the Gold Squad ;)
[14:39] <gmb> (Or something)
[14:39] <gmb> I jest.
[14:39] <flacoste> lol
[14:39] <flacoste> yellow gold
[14:39] <flacoste> not to be confused with yyykon gold
[14:39] <flacoste> yukon gold
[14:39] <bigjools> I need something better than Red, I shall be asking my team next week
[14:39] <flacoste> bigjools: as you as you are not the Reds
[14:40] <bigjools> I cannot possibly be associated with red :)
[14:40] <bigjools> flacoste: the google spreadsheet says Red
[14:40] <pcjc2> gmb: That is a nice example of ajax search (even if the results are manually updated). The only missing feature is the ability to exclude based upon a given field
[14:40] <pcjc2> IE. "Not 25V DC"
[14:42] <pcjc2> Combine that search functionality, the ability to negate the filters.. and a means to save a given query.. we would have awesome
[14:42] <allenap> bigjools: Come on, red is good :)
[14:42] <gmb> pcjc2: That's a reasonable example. I think we'd want to aim for a slightly slicker UI, but it would be a good first step.
[14:42] <bigjools> allenap: I don't want to be Red Ed
[14:42] <StevenK> Hahaha
[14:42] <pcjc2> It is usable - I agree you want slicker
[14:42]  * StevenK keep that in mind for next week
[14:43] <allenap> bigjools: Glitter then.
[14:43] <bigjools> allenap: lol
[14:43] <bigjools> that would be gary's team....
[14:43] <gmb> OI.
[14:43] <allenap> Of course!
[14:43] <gary_poster> :-)
[14:43] <pcjc2> Silly ideas in abundance here.. what about reverse AJAX for pushing updates to bugs whilst one has the page open?
[14:44] <pcjc2> Often I find I'm working on bugs with other developers, and we have to keep hitting refresh
[14:44] <lifeless> bigjools: any idea how to qa http://launchpad.net/bugs/680733 ?
[14:44] <_mup_> Bug #680733: broken recipe build gets stuck at top of "5 latest builds" list on recipe page, forever <lp-code> <qa-needstesting> <recipe> <Launchpad itself:Fix Committed by thumper> < https://launchpad.net/bugs/680733 >
[14:44] <StevenK> If the Launchpad squards are going to named like that, there will be a beating next week
[14:44] <gary_poster> I was thinking Gold Lame, per gmb.  Or maybe Yellow Bellies (Americanism for cowards).
[14:44] <bigjools> lifeless: checking
[14:45] <bigjools> StevenK: maybe something that alliterates with the squad leader's name then
[14:45] <bigjools> Gary's Gang, for example
[14:45] <gary_poster> heh
[14:46]  * gary_poster tries to recall the names of the two gangs in West Side Story...
[14:46] <gary_poster> Jets and...
[14:46] <gary_poster> ah, yes, Sharks
[14:47] <jcsackett> lifeless: don't worry about bug 697685. i just qa'ed. thanks for getting my other bug, btw. :-)
[14:47] <_mup_> Bug #697685: People with PPAs should not be allowed to merge accounts <merge-deactivate> <ppas> <qa-ok> <Launchpad itself:Fix Committed by jcsackett> < https://launchpad.net/bugs/697685 >
[14:47] <lifeless> jcsackett: sweet, thanks
[14:47] <bigjools> lifeless: no... :/
[14:49] <bigjools> lifeless: the URL is invalid on qastaging... ummm
[14:49] <lifeless> anyone know of a team with recipes on qastaging ?
[14:50] <bigjools> https://code.qastaging.launchpad.net/~bzr/ is repeatedly timing out
[14:51] <lifeless> yeah, its high on the ppr but not a timeout on prod atm
[14:52] <lifeless> well we're clear to 12201
[14:52] <lifeless> be nice to get 12201 and 12202 in the deploy
[15:17] <flacoste> bac: did you start the wiki page for the review discussion of next week?
[15:27] <lifeless> pcjc2: your fix should be live in ~ 20 minutes
[15:34] <pcjc2> exciting stuff
[15:54] <spiv> StevenK: I hear you're looking at a pow/gmpy doctest failure?
[15:57] <StevenK> Yes
[15:57] <StevenK> I think we have it
[15:57] <spiv> StevenK: different repr() for values returned from pow(...) ?
[15:59] <lifeless> spiv: loop tuner showing different perturbations
[16:02] <spiv> lifeless: ah, pow(float(some_int), ...) returning an integer rather than a float?
[16:02] <lifeless> returns an mpz
[16:02] <spiv> Right
[16:02] <lifeless> that in one case we have
[16:03] <lifeless> class.int_colum = pow(9,10)
[16:03] <lifeless> so that generates a TypeError
[16:04] <spiv> *nod*
[16:04] <spiv> I'd be happy to add eyeballs to reviewing a fix, if anyone wants.
[16:05] <lifeless> we're just using math.pow in the lp suite
[16:06] <spiv> Sounds reasonable.
[16:06] <lifeless> spiv: possibly the conch pow hack should not cast floats
[16:06] <lifeless> e.g. only int -> mpz
[16:06] <lifeless> and float -> mpq
[16:07] <spiv> lifeless: yeah, possibly.  Or PyCrypto should be changed to automatically use gmpy when it is availabe
[16:07] <spiv> Then Conch wouldn't need to override the builtin pow.
[16:07] <lifeless> spiv: actually, does it cast float -> mpz? cause that would be -wrong-
[16:07] <spiv> lifeless: that's ok, because floats are wrong by definition ;)
[16:07] <lifeless> float -> mpf is better
[16:07]  * spiv looks
[16:08] <spiv> lifeless: it unconditionally casts to mpz :(
[16:08] <lifeless> spiv: now this, if you care to fix, would be good
[16:08] <lifeless> I guess it means looking at pycrypto to see if it actually uses longs or floats
[16:09] <spiv> crypto?  With floats?
[16:09] <lifeless> python coders
[16:09] <spiv> heh.
[16:09] <spiv> Point taken.
[16:10] <StevenK> lifeless: https://code.launchpad.net/~stevenk/launchpad/gmpy-fix/+merge/46278
[16:18] <lifeless> pcjc2: its live
[16:28] <lifeless> Ursinha-nom: hi; I wonder if you could include a little more context in bugs like https://bugs.launchpad.net/bzr/+bug/702914 - I've updated it
[16:28] <_mup_> Bug #702914: AttributeError OOPS in codebrowse <codebrowse> <oops> <Bazaar:New> <Launchpad itself:Triaged> < https://launchpad.net/bugs/702914 >
[16:29] <spiv> lifeless, StevenK: I've filed http://twistedmatrix.com/trac/ticket/4803
[16:29] <lifeless> Ursinha-nom: also oops are critical + triaged status
[16:29] <lifeless> spiv: thanks
[16:29] <spiv> And will make a patch
[16:29] <lifeless> spiv: awesome
[16:30] <lifeless> Ursinha-nom: the goal being that folk without access to the oops db should be able to make some sense of the bug ( unless its got prvate data of course)
[16:32] <lifeless> StevenK: I filed bug 702933
[16:32] <_mup_> Bug #702933: IntColumn raises TypeError on assignment of an mpz <Storm:New> < https://launchpad.net/bugs/702933 >
[16:32] <lifeless> StevenK: as we have no cases in core code I'm not going to do a patch just yet
[16:45] <lifeless> sinzui: rt 43392 may interest you -
[16:45] <lifeless> I think I captured enough data, but perhaps more needs to be said (on it?)
[16:46] <sinzui> I cannot access the rt system
[16:46] <lifeless> ah
[16:47] <lifeless> natty?
[16:47] <sinzui> Is this about nagio + mailman
[16:47] <lifeless> yes
[16:47] <sinzui> lifeless, no. I do not have working credentials for rt
[16:48] <Ursinha-nom> lifeless, I would include more context if I have it :)
[16:49] <lifeless> Ursinha-nom: just copy more of the backtrace :)
[16:49] <lifeless> Ursinha-nom: the url from the oops report
[16:49] <Ursinha-nom> lifeless, the oops becomes a link
[16:49] <Ursinha-nom> ah, ok
[16:49] <Ursinha-nom> got it
[16:50] <lifeless> Ursinha-nom: yes, but e.g. mkanat (who does loggerhead things) cannot see the raw oops, so we need to decide whats safe and expose it
[16:50] <lifeless> ditto adi roban for translations patches
[16:50] <lifeless> wgrant until we hired him
[16:50] <Ursinha-nom> lifeless, sure, I can do that :)
[16:50] <lifeless> thank you!
[16:53] <lifeless> pcjc2: were you going to look at a CVE issue too?
[16:54] <lifeless> sinzui: bug 162510 - IIRC some job has been created for that?
[16:54] <_mup_> Bug #162510: Person:+delete timeouts : Person merging needs to be done asynchronously <canonical-losa-lp> <chr> <feature> <lp-registry> <merge-deactivate> <tech-debt> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/162510 >
[16:55] <sinzui> lifeless no. We have a table and a generic job that could be adapted to do the work
[16:55] <sinzui> lifeless, http://launchpad.leankitkanban.com/Boards/Show/12749744
[16:55] <sinzui> ^ it is in the back log to do, maybe in two weeks
[16:59] <sinzui> lifeless is the mailman log change really fix released? The code is in production?
[17:02] <lifeless> pretty sure
[17:02] <lifeless> we did a nodowntime deploy
[17:10] <pcjc2> @lifeless: RE: CVE issue, didn't find a time-out which matched, but can file a bug for updating the code to be more efficient, like the tags one is
[17:13] <lifeless> jml: how important in the scheme of things is the rosetta translation statistics being up to date?
[17:13] <jml> lifeless: I don't know.
[17:14] <lifeless> jml: we don't run the daily stats effectively at the moment because its too sensitive to cluster replication lag
[17:15] <lifeless> danilo feels that having stats up to date is a critical thing
[17:15] <lifeless> I think that I don't know and its a product owner question :)
[17:15] <lifeless> the technical work is fairly shallow, FWIW
[17:16] <jml> lifeless: I'll talk w/ danilos
[17:16] <danilos> jml, ok
[17:16] <jml> now's not a great time
[17:18] <danilos> jml, ok
[17:27] <pcjc2> Anyone else seeing this bug..
[17:27] <pcjc2> Go to a bug, edit its tags. (Have a pop-up auto-complete box appear)
[17:27] <pcjc2> After completing tag editing, the auto-complete layer stays visible
[17:28] <pcjc2> Does not happen if you cancel editing, only if you confirm it
[17:29] <lifeless> bug in chromium support
[17:29] <lifeless> its filed
[17:30] <pcjc2> Its not chrome i'm using.. epiphany, which is webkit
[17:30] <lifeless> so is chrome
[17:30] <lifeless> so its a webkit thing
[17:30] <pcjc2> ok, didn't know that.
[17:30] <lifeless> hmm, I was sure it was filed
[17:32] <bigjools> I've seen that happen in FF as well
[17:32] <pcjc2> Just wondered if it was a new bug, as I'd not seen it before now
[17:35] <lifeless> gary-lunch: is bug 381617 fix released in lazr-js ?
[17:35] <_mup_> Bug #381617: Inline tags autocomplete displays in the wrong location <javascript> <lp-bugs> <ui> <Launchpad itself:Fix Released by mars> <LAZR Javascript Library:Fix Committed by mars> < https://launchpad.net/bugs/381617 >
[17:35] <bigjools> I forgot how to re-create it
[17:43] <pcjc2> I'm tempted to feature-request a tag search which can "?sf-bugs -*"
[17:44] <lifeless> in english ?
[17:44] <pcjc2> as in I want to find bugs which have no tags - other than not caring whether they have the sf-bugs tag or not
[17:44] <pcjc2> I don't think that is achievable with the current queries, although I might be wrong there
[17:45] <pcjc2> or -!sf-bugs
[17:45] <lifeless> no tags other than sf-bugs
[17:45] <pcjc2> indeed
[17:45] <pcjc2> although our query might be "find bugs which have no tags aside from sf-bugs, sf-patches, sf-feature-requesets..."
[17:46] <lifeless> sure
[17:46] <lifeless> uhm
[17:46] <pcjc2> Still - there is the API which can help with that
[17:46] <lifeless> feel free to file it
[17:46] <lifeless> search isn't currently in the main bits being overhauled, but a patch to do it would be gladly reviewed
[17:46] <pcjc2> I suspect it could well be rolled up if / when search is overhauled
[17:46] <pcjc2> gmb sounded keen to make it nicer
[17:48] <pcjc2> Its a difficult problem - we are effectively trying to present the user with an efficient way to convey what might be quite a complex SQL query
[17:49] <pcjc2> And harder if we wanted to go further, and allow regexp matches against tag names
[17:49] <jml> pcjc2: there are examples of similar interfaces in trac, rememberthemilk and gmail
[17:50] <pcjc2> Can the DB do a regexp match, or do you have to pull a list of all tags for the given search scope and then filter down to get a list of bugs?
[17:50] <jml> pcjc2: lots of us are very keen to make search nicer. I suspect a motivated volunteer would find help easily :)
[17:50] <pcjc2> I don't think I've got the time to dedicate to it at the moment - other priorities
[17:51] <pcjc2> I would love to do it, but there would be a learning steep curve involved
[17:51] <pcjc2> I can't take on any more unpaid mega-tasks at the moment though
[17:52]  * jml understands
[17:52] <jml> but I still don't regret fishing :)
[17:54] <pcjc2> No - I'd be very tempted if circumstances were different
[17:56] <pcjc2> If you edit tags and specify something wrong (lets say, use an illegal character, such as "," between tags, the page basically gets stuck
[17:56] <pcjc2> with no way to cancel or re-edit the tags
[17:56] <pcjc2> Is that related to the existing filed tags bug?
[17:58] <lifeless> I think you should file that
[17:59] <pcjc2> will do
[18:26] <gary_poster> lifeless: I have no idea.  I was on the periphery of lazr-js.  mars, when you return, please update bug 381617 as fix-released, assuming it was.
[18:26] <_mup_> Bug #381617: Inline tags autocomplete displays in the wrong location <javascript> <lp-bugs> <ui> <Launchpad itself:Fix Released by mars> <LAZR Javascript Library:Fix Committed by mars> < https://launchpad.net/bugs/381617 >
[18:29] <lifeless> gary_poster: thanks
[18:30] <gary_poster> np
[18:42] <lifeless> mars: 07:26 < gary_poster> lifeless: I have no idea.  I was on the periphery of lazr-js.  mars, when you return, please update bug 381617 as fix-released, assuming it was.
[18:42] <_mup_> Bug #381617: Inline tags autocomplete displays in the wrong location <javascript> <lp-bugs> <ui> <Launchpad itself:Fix Released by mars> <LAZR Javascript Library:Fix Committed by mars> < https://launchpad.net/bugs/381617 >
[18:43] <gary_poster> :-)
[18:43] <mars> gary_poster, lifeless, will do
[18:43] <gary_poster> thank you
[18:45] <mars> done
[18:46] <mars> gary_poster, did I miss anything else?  Was fighting an Intel GPU crash
[18:46] <gary_poster> thanks mars.  not that I know of
[18:46] <mars> thanks
[18:46] <gary_poster> I hope you won :-)
[18:47] <mars> nope!  Had to do a hard reboot.
[18:47] <gary_poster> :-/
[18:48] <mars> The X201 does not like you using the 'Display Switch' button after docked, and then you undocking.  Crashes the GPU, cascades to crashing the shutdown syslog daemon (preventing shutdown)
[18:50] <mars> Still an awesome laptop though
[18:52] <StevenK> mars: I got an X201 as well :-)
[18:52] <mars> StevenK, excellent choice! :)
[18:54] <mars> I have it as my primary system now, using a dock and my 24" monitor and speakers
[18:54] <mars> Best of both worlds: more powerful than my previous desktop, same screen size, and ultra-portable in a flash
[18:54] <mars> (except for that GPU bug)
[18:58] <LPCIBot> Project db-devel build (270): STILL FAILING in 4 hr 27 min: https://hudson.wedontsleep.org/job/db-devel/270/
[18:58] <LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12198,
[18:58] <LPCIBot> 12199, 12200, 12201, 12202 included.
[19:03] <LPCIBot> Project devel build (362): STILL FAILING in 4 hr 26 min: https://hudson.wedontsleep.org/job/devel/362/
[19:03] <LPCIBot> * Launchpad Patch Queue Manager: [r=allenap][ui=none][bug=656823] Correct the description of a bug
[19:03] <LPCIBot> subscription filter that has no conditions. A filter without
[19:03] <LPCIBot> conditions actually allows all mail through,
[19:03] <LPCIBot> not no mail through as previously claimed.
[19:04] <LPCIBot> * Launchpad Patch Queue Manager: [r=adeuring][ui=none][bug=656823] UI to delete bug subscription
[19:04] <LPCIBot> filters.
[19:04] <LPCIBot> * Launchpad Patch Queue Manager: [r=adeuring][ui=none][bug=656823] UI for creating new bug
[19:04] <LPCIBot> subscription filters.
[19:04] <LPCIBot> * Launchpad Patch Queue Manager: [r=mwhudson,
[19:04] <LPCIBot> stevenk][ui=none][bug=697255] Fix the source package recipe build
[19:04] <LPCIBot> title for deleted recipes.
[19:04] <LPCIBot> * Launchpad Patch Queue Manager: [r=julian-edwards, mwhudson,
[19:04] <LPCIBot> stevenk][ui=none][bug=692814] Make recipe builds live under the
[19:04] <LPCIBot> archive, not the recipe.
[19:18] <lifeless> flacoste: two ideas for graphs
[19:18] <lifeless> the 99% time, weekly report rather than daily, for a smoother trend line
[19:18] <lifeless> and a non-api 99% time (Which I'm filing a bug on now)
[19:18] <flacoste> lifeless: a moving weekly average?
[19:19] <lifeless> flacoste: that would be interesting too
[19:19] <flacoste> yeah, i thought of that one
[19:19] <flacoste> because otherwise, we'd have only one point per week
[19:19] <lifeless> lastly I'd love to have a | marker when we deploy and a || for db deploys
[19:20] <lifeless> gmb: we need to talk features & API
[19:20] <lifeless> gmb: I'm not sure it makes a great deal of sense to expose arbitrary flag queries on the api
[19:20] <lifeless> gmb: for performance and sanity reasons
[19:26] <Ursinha> I'm constantly getting connection timed out when trying to push a branch to launchpad... is that just me?
[19:27] <lifeless> I sure hope su
[19:27] <lifeless> what does it say?
[19:29] <lifeless> https://lpstats.canonical.com/graphs/CodehostingPerformance/ is interesting
[19:33] <lifeless> https://lpstats.canonical.com/graphs/CodehostingCrowberryConnections/ seems ok
[19:33] <lifeless> Ursinha: what does bzr say ?
[19:34] <Ursinha> ssh: connect to host bazaar.launchpad.net port 22: Connection timed out
[19:34] <Ursinha> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[19:34] <Ursinha> that happened yesterday as well, and worked without me doing nothing but trying
[19:34] <Ursinha> lifeless, ^
[19:52] <StevenK> sinzui: I can get Neil's attention here to help you with Unity over IRC if you wish.
[19:53] <sinzui> I think I just need to wait for all the parts to build and mirrors updated. I just got a few items built in the last 3 hours
[19:53] <sinzui> I think I am waiting on unity or compiz parts to arrive
[19:55] <lifeless> mbarnett: ^
[20:14] <lifeless> Ursinha: whats your ip address?
[20:14] <lifeless> so we can look that up in the access log
[20:15] <lifeless> mbarnett: can you look in the twistd.log and access.log for codehosting
[20:18] <mbarnett> sorry, was answering on the other channel
[20:19] <mbarnett> codehosting-access.log.1:2011-01-13 18:44:48,676 INFO [83012064] IPv4Address(TCP, '201.82.195.142', 57421) connected.
[20:19] <mbarnett> codehosting-access.log.1-2011-01-13 18:44:50,345 INFO [83012064] ursinha logged in.
[20:19] <mbarnett> codehosting-access.log.1-2011-01-13 18:44:50,434 INFO [87931288] failed to authenticate.
[20:19] <mbarnett> left out:
[20:19] <mbarnett> codehosting-access.log.1-2011-01-13 18:44:50,434 INFO [87931288] disconnected.
[20:32]  * StevenK attempts to subvert bzr sufficently
[20:32]  * jelmer hands StevenK subvertpy
[20:33] <StevenK> Good, because using sftp manually isn't working
[20:33] <jelmer> :-(
[20:44] <pcjc2> lifeless: That bug you wanted me to file is Bug #703061
[20:44] <_mup_> Bug #703061: Tags edit with syntax error makes further tag editing impossible <lp-bugs> <ui> <Launchpad itself:New> < https://launchpad.net/bugs/703061 >
[20:45] <StevenK> Right, still no diff :-(
[21:06] <gary_poster> lifeless, I want to move an old card off of the Foundations board as one of the last acts there: finishing ++profile++ so you can use it on staging.
[21:06] <gary_poster> You wanted that done with a feature flag, I believe.  I have one guess as to why, but I'd rather be sure.  Why?
[21:06] <gary_poster> If I were doing it without further input, I'd make a flag named something like "can-profile-on-staging" (meaning staging and qastaging) and then team:launchpad would have it set to True, with the possibility of opening it to others if desired.  Does that satisfy your needs, or do you have another requirement?
[21:10] <deryck> Until Dallas then!  Have a nice weekend everyone.
[21:10] <jml> gary_poster: lifeless is on a call right now. will be off soon.
[21:10] <gary_poster> jml ack, thanks
[21:33] <lifeless> gary_poster: I think just a flag control for the 'enabled' status
[21:33] <lifeless> gary_poster: no need to tie it to staging specifically
[21:34] <gary_poster> lifeless: that seems like an unnecessary risk to me
[21:34] <gary_poster> lifeless: unless there's a compelling use case that supercedes the risk, of course
[21:50] <lifeless> gary: hi
[21:50] <gary_poster> hey
[21:51] <lifeless> gary_poster: uhm, so I think code simplicity and clarity is important here
[21:51] <lifeless> gary_poster: we don't label the config section 'profiling for developers'
[21:51] <gary_poster> don't get the connection yet
[21:52] <lifeless> gary_poster: if I was doing it, I would have the flag be (IIRC) profiling.enabled
[21:53] <lifeless> the rule using team:launchpad, and only put it on on staging
[21:53] <lifeless> gary_poster: there isn't a specific use case saying we must have it available on e.g. production
[21:53] <lifeless> gary_poster: otoh if you're doing, you should do something that feels right to you.
[21:53] <lifeless> gary_poster: one thing I will suggest is that the flag should -replace- one of the config settings
[21:54] <gary_poster> lifeless, how do we put it only on staging?  can we do that only in one-offs?
[21:54] <lifeless> the overall enabled one, I think.
[21:54] <gary_poster> or can we do it once and have it stick?
[21:54] <gary_poster> (which I would think is the desirable behavior)
[21:54] <lifeless> gary_poster: I'd put it in a tiny post-restore hook
[21:54] <lifeless> gary_poster: in the staging and qastaging restore scripts
[21:55] <gary_poster> that spreads the configuration and behavior out more than I like.  This does feel like it is a matter of taste.  This isn't the way I'd do it, but I can do as you describe.
[21:56] <lifeless> gary_poster: I have an alternative
[21:56] <lifeless> but its more code
[21:56] <lifeless> if feature flags scopes had an and operator
[21:56] <lifeless> we could do
[21:56] <gary_poster> I get you
[21:56] <lifeless> server:staging and in_team:launchpad
[21:56] <gary_poster> That's a lot of work for something that is not a requirement
[21:56] <lifeless> if we put that on production, it would propogate to qastaging and staging
[21:57] <gary_poster> Well, "a lot" may or may not be true
[21:57] <gary_poster> but certainly more than is needed
[21:57] <lifeless> gary_poster: the main thing for me is that the rule shouldn't refer to the server instance *in code* - thats config which should be in the rules.
[21:57] <lifeless> otherwise we can't use it on e.g. dogfood, or developer machines, quite as easily
[21:58] <lifeless> gary_poster: does that make sense?
[21:59] <lifeless> brb fooding
[22:00] <gary_poster> We disagree there--we have configuration abstractions for stuff like this--but I'm just going to follow your plan...essentially because you are TA, and I don't feel strongly enough about this to go further.  :-)
[22:00] <gary_poster> I was intending developer machines to always have this behavior, irresepctive of the flag.
[22:01] <gary_poster> But I'll proceed as described.
[22:03] <lifeless> gary_poster: ah, interesting. But - thanks.
[22:09] <lifeless> jam: https://launchpadlibrarian.net/1573330/emblem8.png
[22:17] <jelmer> StevenK: I've fixed the bzr bug that was affecting you
[22:18] <StevenK> \o/
[22:18] <jelmer> StevenK: did the diff appear yet ?
[22:18]  * StevenK worked around it
[22:32] <lifeless> poolie: https://bugs.launchpad.net/launchpad/+bug/297398/comments/4
[22:32] <_mup_> Bug #297398: support password/passphrase authentication for bazaar <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/297398 >
[22:37] <lifeless> jml: https://bugs.launchpad.net/launchpad/+bug/297398
[22:37] <_mup_> Bug #297398: support password/passphrase authentication for bazaar <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/297398 >
[22:45] <lifeless> wgrant: does 363916 need to be private?
[22:46] <StevenK> lifeless: You know, it's Saturday in .au, right?
[22:47] <lifeless> StevenK: and?
[22:47] <StevenK> lifeless: And no fair asking about work stuff on the weekend?
[22:48] <lifeless> StevenK: he doesn't have to answer
[22:49] <lifeless> StevenK: its not like I'm stalking in an unrelated channel; if he wants to sign off, he can.
[22:49] <lifeless> I suspect, like I, his interest in Launchpad extends beyond a simple definition of work hours
[22:50]  * StevenK decides that arguing is less fun when he is tired
[22:51] <lifeless> StevenK: I don't think arguing is ever fun, FWIW.
[22:52] <StevenK> No, trolling is much better, right?
[23:16] <wgrant> lifeless: Probably not.
[23:24] <lifeless> mars: do you know of an upstream bug for 664105
[23:24] <lifeless> bug 644105
[23:24] <_mup_> Bug #644105: remove basic auth (and passwords) - neither are used outside of the test suite <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/644105 >
[23:24] <lifeless> that is, the windmill hostname crossing limitation
[23:31] <LPCIBot> Project db-devel build (271): STILL FAILING in 4 hr 33 min: https://hudson.wedontsleep.org/job/db-devel/271/
[23:31] <LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12203,
[23:31] <LPCIBot> 12204 included.
[23:35] <LPCIBot> Project devel build (363): STILL FAILING in 4 hr 31 min: https://hudson.wedontsleep.org/job/devel/363/
[23:35] <LPCIBot> * Launchpad Patch Queue Manager: [r=deryck][ui=none][bug=699719][incr] The code that sets up event
[23:35] <LPCIBot> handlers for the bugtask:+index portlets has been moved into a
[23:35] <LPCIBot> function so that we can better manage its behaviour using
[23:35] <LPCIBot> feature flags.
[23:35] <LPCIBot> * Launchpad Patch Queue Manager: [r=julian-edwards][ui=none][bug=701387] Drop unused
[23:35] <LPCIBot> Archive.arm_builds_allowed.
[23:35] <LPCIBot> * Launchpad Patch Queue Manager: [r=gmb, leonardr][ui=none][bug=620458,
[23:35] <LPCIBot> 629804] use LaunchpadWebServiceCaller to check the HTTP response in
[23:35] <LPCIBot> test_user_access_to_private_bug_attachment()
[23:35] <LPCIBot> * Launchpad Patch Queue Manager: [r=bac][ui=matthew.revell][bug=676495] No oopses when rescoring
[23:35] <LPCIBot> non-queued recipe builds.
[23:35] <LPCIBot> * Launchpad Patch Queue Manager: [r=henninge][ui=none][bug=607958] do not join unneeded target tables
[23:35] <LPCIBot> in BugTaskSet.findExpirableBugTasks()
[23:35] <LPCIBot> * Launchpad Patch Queue Manager: [r=adeuring][ui=none][bug=702260] Directly deleted library files no
[23:35] <LPCIBot> longer cause the PackageDiff processor to crash.
[23:38] <wgrant> sinzui: FWIW, I have similar natty issues.
[23:38] <sinzui> \o/
[23:38] <wgrant> sinzui: I can fix it by manually running metacity and then killing gnome-panel from a TTY.
[23:38] <sinzui> ah
[23:39] <StevenK> LPCIBot: Shush. I better have fixed you this devel build.
[23:39] <wgrant> sinzui: Which video driver?
[23:39] <sinzui> I reinstalled docky to give me a sense of status and what is running
[23:40] <sinzui> I am using nvidia 173...
[23:40] <lifeless> sinzui: hey
[23:40] <lifeless> bug 697492 - I've made a few tweaks to it; I'm wondering if the fix is shallow or not
[23:40] <_mup_> Bug #697492: user account suspension wants 'user password' reset too <canonical-losa-lp> <merge-deactivate> <tech-debt> <users> <Launchpad itself:Triaged> < https://launchpad.net/bugs/697492 >
[23:40] <lifeless> specifically to just not /ask/ for a new password if an lp admin is suspending a user.
[23:41] <sinzui> Well I am not sure an admin should be suspending users since the admin cannot undo the damage
[23:41] <wgrant> sinzui: Can't they?
[23:41] <sinzui> no
[23:41] <wgrant> Even ~registry can suspend users...
[23:42] <wgrant> Does suspending unset the preferredemail?
[23:43] <sinzui> our code to restore an the email address and and password is never in the execution path since we switched to SSO
[23:43] <wgrant> :(
[23:44] <sinzui> Our code is happy to set the accept SSO authentication, set them as a principle with a know profile, then abandoning the poor user
[23:44] <wgrant> lifeless: Could we hack around that Windmill issue by leaving a test-only basic auth path with a hardcoded password?
[23:44] <sinzui> I cannot remember the bug that is tracking that. Gary may remember
[23:45] <sinzui> I keep talking about the madness that no user should ever be set as the principle for a profile without an email address, but getting that fixed is very difficult
[23:46] <wgrant> sinzui: Do we have a list of things that need to be fixed to make the authentication experience not suck?
[23:46] <wgrant> StevenK: You've fixed the pow() issues?
[23:46] <sinzui> gary has a very long wiki page describing the work that needs to be done
[23:46] <StevenK> Yes
[23:46]  * sinzui looks
[23:47] <wgrant> sinzui: Does the cover the suspension issues?
[23:47] <wgrant> StevenK: Yay.
[23:47] <StevenK> wgrant: s/pow/math.pow/ since gmpy sucks
[23:48] <wgrant> Hah.
[23:48] <sinzui> wgrant, Yes. I wont let him forget
[23:48] <sinzui> it
[23:49] <sinzui> wgrant, https://dev.launchpad.net/LEP/OpenIdRoadmap
[23:52] <wgrant> sinzui: Does the first step require any code?
[23:53] <sinzui> lifeless, the immediate fix for the losa is to remove the password field from all forms. That is trivial and prevent admins from thinking they are changing passwords
[23:53] <sinzui> wgrant, the first step of what
[23:54] <wgrant> The first step of that roadmap: divorcing ShipIt. I mean, ideally ISD would spend two days rewriting it in Django. But since it appears they won't, it should probably just have a fork of LP and its database.
[23:54] <sinzui> wgrant, I am not sure how fast ISD is progressing on that issue
[23:55] <wgrant> It's such a trivial app :(
[23:55] <sinzui> wgrant, an I perplexed about the rules for provisioning a lp profile. I do not know what is hard about checking if it is in a usable state
[23:56] <wgrant> sinzui: Which rules?
[23:56] <wgrant> In "thoughts?"?
[23:56] <sinzui> Those in webapp authentication somewhere
[23:57] <sinzui> wgrant I was thinking of servicing part of the issue for myself by giving ~registry the power to see suspended users, and updating that form to restore the user email address when the status is set active
[23:58] <wgrant> sinzui: It seems to me that using the presence of preferredemail as an indicator of account status is unreasonably crackful.
[23:59] <sinzui> possibly. Updating all Lp will take some work I think
[23:59] <wgrant> Sure.
[23:59] <sinzui> An I believe account is going away, so I do not know where status will live if it does
[23:59] <wgrant> It'll need to live on person, but DEATH TO ACCOUNT.