[00:37] Project parallel-test build #76: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/parallel-test/76/ [02:19] Project devel build #842: FAILURE in 5 hr 32 min: https://lpci.wedontsleep.org/job/devel/842/ [05:10] Project parallel-test build #77: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/parallel-test/77/ [06:36] Project db-devel build #673: FAILURE in 5 hr 38 min: https://lpci.wedontsleep.org/job/db-devel/673/ [07:36] Project devel build #843: STILL FAILING in 5 hr 16 min: https://lpci.wedontsleep.org/job/devel/843/ [09:09] A couple of UI changes to be reviewed if anyone wants to do them: [09:09] https://code.launchpad.net/~huwshimi/launchpad/what-next-712259/+merge/66030 [09:09] https://code.launchpad.net/~huwshimi/launchpad/table-headings-728187/+merge/66008 [09:10] bigjools: I ripped Storm out of lazr.amqp last night. [09:10] \o/ [09:10] And got it working with the rabbit fixture instead of system rabbit with hacked landscape setup script. [09:10] But it's slow. [09:10] \o/ and :( [09:11] So I need to port the test suite to testtools instead. [09:11] Rather than using zope.testrunner. [09:11] But lifeless and jml know about that. [09:11] jfdi [09:11] So it's doable this morning. [09:11] Rabbit changes aren't landed yet, but the suite passes locally with them. [09:11] * StevenK giggles at "\o/ and :(" [09:11] So you can happily turn off your system rabbit soon :) [09:11] WOOHOO! [09:12] wgrant: ok. I can work with you on that, since my talk is during this plenary session [09:13] matsubara: you should talk to flacoste & deryck about their acceptance test plans [09:13] matsubara: involves selenium & LEPs [09:14] jml: I think it should be pretty easy. [09:14] wgrant: yeah [09:14] jml: I started it yesterday but then abandoned it when I looked at docs. [09:15] I wonder how trivial a rabbit backport to lucid/maverick is. [09:15] Or possibly just skip the reject test on older rabbits. [09:15] wgrant: new deployment, w00t :) [09:15] jelmer: Yup, and the upgrades work fine. [09:16] jelmer: Not sure about the automatic Invalid stuff, though. [09:16] Thanks for fixing that up! [09:16] jml, will do. thanks for the heads up [09:49] Project parallel-test build #78: STILL FAILING in 1 hr 6 min: https://lpci.wedontsleep.org/job/parallel-test/78/ [09:55] There we go. [09:56] I tried persisting the rabbit process and just recreating the vhost between tests, but that seems to take 100-200ms... but it seems OK to just manually clear out the vhost over AMQP. [09:56] So I now have a fast test suite using the rabbit fixture. [09:56] yay. [10:03] wgrant: Could you please update DF when you get a chance? [10:05] Wait until I'm done with it. [10:05] Please. :-) [10:11] Could someone review this branch for me: https://code.launchpad.net/~matsubara/launchpad/724727-single-line-inline-editor/+merge/66089? It's a small css change [10:14] StevenK: (too late) [10:14] But I didn't restart the appserver, since I know you're using the librarian. [10:14] Right [10:14] Can you prod and see if memcached is running? [10:14] There is a memcached running. [10:15] (zomg, no latency!) [10:15] 2011-06-28 09:15:04 WARNING Memcache set failed for populate-bprc [10:15] :-( [10:15] Checking conifg.s [10:15] ah. [10:16] StevenK: The system memcached is running, but the Launchpad one is not. [10:16] Should I start it? (needs appsever/librarian restart) [10:16] Wait until garbo finishes [10:17] k [10:18] 2011-06-28 09:17:56 DEBUG2 [PopulateBinaryPackageReleaseContents] Iteration 1106 (size 1.0): 3.701 seconds [10:22] morning guys [10:22] Good day sir. [10:22] I have my webcam ready to roll [10:22] if someone can skype me that would be great [10:22] Excellent. [10:23] 2011-06-28 09:23:24 DEBUG2 [PopulateBinaryPackageReleaseContents] Done. 1192 items in 1192 iterations, 3267.929582 seconds, average size 1.000000 (0.364756941707/s) [10:23] wgrant: Please to be restarting. [10:25] spm: http://onefte.com/2011/06/27/youre-such-an-enabler/ is the bomb! [10:29] StevenK: Should be running now. === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [10:33] lifeless: technology ensues [10:34] \o. === al-maisan is now known as almaisan-away [10:34] lifeless: inappropriate branding! [10:35] jml: save-as branding [10:42] lifeless: Can we troll you instead? [10:42] lifeless: Seriously, please talk a little slower. [10:42] It's not that bad... [10:43] call dropped [10:43] or held ? [10:43] Francis killed it. [10:43] Somehow. [10:43] lifeless: flacoste pressed the wrong button [10:43] I bet he hit [10:43] PEBKAC === mrevell_ is now known as mrevell [10:47] lifeless: that means "99%ile is twice as fast"? [10:51] https://dev.launchpad.net/ArchitectureGuide/Services [10:54] lifeless: Does it suffer from the /tmp issue? [10:54] \o/ [10:55] lifeless: there's going to be more than 86 lines of work in getting it deployed, is my impression [10:55] poolie: hah! [10:55] for example the requirement for monitoring etc [10:55] lifeless: i like the way you've kept banging the drum of performance tuesday [10:56] lifeless: it might be easier to put questions on irc [10:56] jml: ? [10:57] lifeless: we've chosen web.py as our web infrastructure for our microservices, we've had other suggestions here that might be better (e.g. pyramid), why have we chosen web.py? [10:57] poolie: the "more than 85 lines of code" comment [10:57] poolie: it's true. [10:58] ah [10:58] i hoped for a moment you were laughing because i was wrong :) [10:58] poolie: Well, I think that initial cost is high, but it will become tiny once we have a few services set up similalr.y [10:58] wgrant: yeah, that's what I was thinking [10:59] poolie: maybe one day you will be :) [10:59] yeah, and as IS continue their projects for puppet, or as things become more containerized [10:59] Like haproxy is now. [10:59] Initial cost was high. [10:59] But now we have it set up, we can add new stuff to it trivially. [10:59] also as we figure out our monitoring needs & come up with stuff that is easy to use, for example [10:59] Right. [11:00] lifeless: this seems a bit inconsistent with saying that we can't use graphite because of (what was it) mental load [11:00] It's going to be a slow start. [11:00] although very much agree w/ what lifeless is saying right now about not converging on tech choices too soon. [11:00] me too [11:01] what are you banging? [11:01] I think pyramid is similarly inappropriate. [11:01] It seems to be an application framework. [11:01] Smaller, but still an application framework, sort of. [11:02] https://dev.launchpad.net/ArchitectureGuide/ServicesRequirements [11:02] for those who want to read them [11:02] i do agree with experimenting with new technologies, and that new ones are needed [11:02] Thanks jml [11:03] I was considering hacking up a version of Robert's work to use ZeroMQ so a direct comparison can be made. [11:04] lifeless: But don't the LOSAs already manage graphite instances, so it's not quite the same thing? [11:04] i guess i find it hard to believe having two graphing services will cause more mental load than having some code in node and same in python [11:04] nm [11:04] i don't want to side track [11:05] the general issue is: what's the amount of diversity that is acceptable? [11:05] any amount? [11:05] i'm not trying to debate the particular case here [11:05] so the problem is that it would violate the need for a canonical, trusted, operational data source [11:06] rather than that it would be new tech? [11:09] lifeless: we're hanging up on you [11:09] lifeless: you're still on screen, fwiw [11:10] lifeless: i don't mind changing this to tuolumne (much) but i don't understand the architectural position behind it [11:10] well... i can understand saying it's easier to do them in two steps [11:11] poolie: graphing is a core realtime troubleshooting service [11:12] poolie: development of a service is a nonrealtime isolated service [11:12] poolie: it isn't an architectural position to say that the troubleshooting stuff - logs, graphs, etc - need to be as consistent and reliable as we can [11:13] poolie: its a pure ops position [11:13] don't frameworks have big ops consequences? [11:14] well, perhaps microframeworks don't, but deploying say go or nodejs seems likely to substantially impact operational debugging [11:14] well [11:14] poolie: there will be an impact yes; its not free [11:15] poolie: but by their nature they are more isolated than graphing [11:16] bigjools: so, around [11:16] ? [11:22] it's a coffee break now [11:22] i' guess he'll be back later [11:24] poolie: another way to talk about the tuolumne/graphite thing [11:25] poolie: for a given microservice, we'll only have *one* implementation live [11:25] poolie: (unless we're deliberately migrating [as a funded driven project, not an itch-scratch that could stop at any time] betweeen implementations) [11:29] that's a reasonable point [11:30] sinzui, when is that bugfix likely to go out onto qas? [11:31] poolie: I can tell you are confused; you feel its inconsistent : I don't think it is, but IRC late at night isn't a brilliant way to tease it out. if you want voice, I can happily do that. [11:32] it's not a practical problem for me at the moment [11:32] i'm sorry it apparently took over your session, which wasn't my intention [11:33] no worries; it was only a slight segue [11:33] could someone send me the page performance report url? [11:33] poolie: https://devpad.canonical.com/~lpqateam/ppr/lpnet/latest-daily-partition.html [11:34] the stats stuff i've been reading reinforced to me that its treatment of times as normally distributed is very bogus [11:34] hugely [11:34] patches solicited! [11:34] i like the way it has highly optimized algorithms from Knuth implementing the wrong solution [11:34] complete with citations of learned papers [11:35] anyhow, go and sleep [11:35] poolie: well, for the purpose of giving us -a- baseline and running ok, its fit for purpose [11:35] right [11:36] as it speeds up the numbers will go down so it may be mostly academic [11:37] poolie: I would be worried if I thought the reported 99th percentile would be low. [11:37] poolie: I don't think it will be [11:38] benji, https://code.launchpad.net/~matsubara/launchpad/724727-single-line-inline-editor/+merge/66089 [11:39] bigjools: ping [11:39] lifeless: you punged? [11:39] I did [11:39] do you have a few minutes for a private skype call ? [11:40] lifeless: for you, of course, let me get set up, one min [11:40] lifeless: actually, 5 mins, I need to run to my room to get my headset [11:40] thats fine [11:40] I shall go talk to lynne for a minute ;) [11:41] lifeless: ok one minute again, allenap lent me his [11:43] Anyone want to do some ui reviews for me? [11:43] More specifically: https://code.launchpad.net/~huwshimi/launchpad/what-next-712259/+merge/66030 and https://code.launchpad.net/~huwshimi/launchpad/table-headings-728187/+merge/66008 [11:43] lifeless: hang on [11:43] headset fail [11:43] bigjools: hanging :> [11:44] as in skype doesn't want to use it [11:46] poolie: deployment overhead for microservices needs automation, but they should be (roughly) one init script [cookie cutter], one log feeder into tuolumne (standard apache format, so no coding), one nagios probe to hit a good url (also cookie cutter), and a stock haproxy config (also cookie cutter) [11:47] jml: I haven't written up the testing/importing aspects of services yet, today was more fragmented than I anticipated [11:48] stub: a 0mq service impl would be interesting indeed [11:49] stub: I am not convinced by my own analysis about ha needs yet ;) - having some experience and learning there would be most excellent [11:50] i wonder about the 99th percentile; it seems it ought to be possible to calculate it mathematically [11:51] i wonder if my R is up to it [11:51] gary_poster: when's a good time to get together with you and sinzui? [11:52] poolie: one thing to note is our dataset size - we're dealing with 12M rows per day, and for each row we have pageid, service time, sql time, sql query count [11:53] so any patch needs to not break the scaling behaviour [11:56] has anyone seen abentley? [11:57] bac: Just saw him walk out of the main LP room [11:57] thanks huwshimi...hopefully he's coming upstairs [11:59] benji: Do you feel like doing a couple of reviews for me? [11:59] https://code.launchpad.net/~jml/lazr.amqp/license-and-copyright/+merge/66113 [12:00] lifeless: where does the updated batching code live? Looking at Bug #739052 with abel. [12:00] <_mup_> Bug #739052: Distribution:+builds timeout < https://launchpad.net/bugs/739052 > [12:01] lifeless: Batching over nearly 800,000 results in a bad case [12:04] lifeless: nm. Found it. [12:04] hey barry! how about right after lunch, 2-ish? [12:06] gary_poster: sounds good [12:06] gary_poster: i'll meet you in the lp room [12:07] thanks barry! [12:10] lifeless: fyi mean+3*stddev does underestimate the 99th percentile time of an exponential distribution [12:11] by about 12% [12:11] lifeless: Are you around by any chance? [12:11] StevenK: yes [12:11] this is based just on the generic distributions, not launchpad's specific data [12:12] stub: you're going to finish it off \o/ [12:12] ? [12:12] it might actually more likely be an erlang distribution, not exponential [12:12] stub: there were only a few remaining glitches in my branch, I think. [12:13] stub: https://code.launchpad.net/~lifeless/launchpad/bug-752153/+merge/56505 [12:13] lifeless: Do you know how large the path table for the conflicts checker is? [12:13] stub: https://code.launchpad.net/~lifeless/launchpad/bug-759467/+merge/58262 is also -so-close-to-done- that will help with some timeouts [12:13] StevenK: not offhand [12:14] wallyworld: some code supposedly using the App Framework i have just found. https://github.com/ericf/photosnear.me/blob/master/public/photosnearme.js [12:14] so it's not collossally off, probably [12:14] er, wallyworld_ ^ [12:16] wgrant, gmb, jml, bigjools: The Rabbit fixture gives off working-like noises and is in lp:~allenap/+junk/lazr.fixtures [12:16] rvba: Oops, you too ^ [12:17] lifeless: Bah. Thought that stuff all landed. [12:18] allenap: cool! [12:19] StevenK: the schema: [12:20] CREATE TABLE binpackagefiles (package_id INTEGER, file_id INTEGER); [12:20] CREATE TABLE filepath (id INTEGER PRIMARY KEY, path VARCHAR); [12:20] CREATE TABLE packageversion (id INTEGER PRIMARY KEY, name_id INTEGER, version VARCHAR, arch_id INTEGER, controltext VARCHAR, analyzed_level INTEGER, preinst_hash VARCHAR); [12:20] select count(*) from binpackagefiles; [12:20] 49416355 [12:20] lifeless: Right, I'm curious how large the filepath table is [12:20] its counting now [12:20] it wasn't running, so its all cold IO [12:20] ight [12:20] *Right [12:21] but clearly < 49M :P [12:22] wallyworld_: https://github.com/yui/yui3/tree/master/src/app/js [12:23] StevenK: select count(*) from filepath; [12:23] 11018381 [12:23] StevenK: do you want the rows? [12:23] So 11 million or so [12:23] select * from filepath limit 1; [12:23] 1|usr/bin/2vcard [12:24] I'm trying to work out how large the BPP and BPRC tables are going to be. [12:25] BPP might only be a couple of GiB [12:26] average length 61.3 [12:26] select sum(length(path)) from filepath; [12:26] 675274107 [12:26] gmb, hi, I am about to remove your JS code for "collapsibles" which I can't find being used anywhere; you've got 0.04s to complain ;) [12:26] lifeless: With 350,000 paths on DF, the table is currently 75MiB. [12:26] (e.g. < 700MB) [12:26] danilos: No complaints. Kill it. [12:26] gmb, cool, thanks [12:26] after a branch lands to devel, how soon can i expect to see it on qas? [12:27] poolie: 7 hours [12:27] Riddell: http://docs.python.org/library/pdb.html#debugger-commands [12:27] poolie: up to 13 if it just missed a buildbot run [12:27] Project db-devel build #674: STILL FAILING in 5 hr 51 min: https://lpci.wedontsleep.org/job/db-devel/674/ [12:27] poolie: more if trunk is broken [12:27] stub: I wish they had landed :) [12:29] stub: Where are you hiding? [12:29] thanks [12:30] stevenk also told me to look at the estimate in builbdot and add 30m [12:30] lifeless: I question your 7. I thought qas took ~ 30 minutes to update [12:30] the step up in https://lpstats.canonical.com/graphs/CodebrowseHTTPResponses/ is a bit interesting [12:30] StevenK: 6 hours to go through BB [12:30] StevenK: Up with Julian for rabbity stuff [12:30] StevenK: 30 minute frequency of qas updates [12:31] StevenK: 15 minutes latency for the carob copy to update after BB [12:31] StevenK: and then the build-and-deploy time on asuka [12:31] adeuring: I'll send lp:~lifeless/launchpad/bug-752153 off to ec2 test to see how close it is to landing. I think we need this branch to land before we can tackle the batching bug. [12:32] Riddell: http://docs.zope.org/zope2/zope2book/AppendixC.html [12:32] stub: ok [12:33] so probably no less than 7 and possibly more? [12:34] lifeless: So StevenK has about 30GB of new data to store (every file path in every package). Microservice or main LP DB? [12:34] poolie: right [12:34] jcsackett_: did you figure anything out on bug 436247? [12:34] <_mup_> Bug #436247: links in side portlets are too close

< https://launchpad.net/bugs/436247 > [12:35] benji: i wasn't able to pursue it with my computer randomly dying. :-P [12:36] benji: as huwshimi pointed out, probably worth bugging sinzui === jcsackett_ is now known as jcsackett [12:36] stub: If a microservice makes sense for it, \o/. [12:37] stub: be sure to consider the whole use case in assessing that [12:37] bigjools, is there an easy way to create a private ppa in launchpad.dev with some dummy packages in it? [12:37] lifeless: I was poking him to talk to you about it if you are in your teddy bear suit. [12:37] sure, I can do that [12:50] jml: can you champion my service fake tests etc today, I promise to write it up tomorrow [12:53] StevenK: so did you want to talk about doing amicroservice? skype? [12:53] lifeless: ok [12:53] lifeless: I haz no skype [12:53] StevenK: voip? [12:54] lifeless: If it's 30GiB, I'm comfortable doing it in the main database since it will be running as part of the publisher. [12:54] jml: thanks! [12:54] lifeless: TBH, I came to Dublin not expecting to do anything like Skype. I can only do Mumble, except that I don't have a headset. [12:55] StevenK: the size of the data doesn't particular impact the service-nature of it for me [12:56] StevenK: things that make a difference are - is it potentially reusable for other goals? [12:56] lifeless: It is not. [12:56] StevenK: does it have different HA needs to the rest of the system (e.g. if its a cache we could rebuild it on failure rather than having N copies) [12:56] It's a list of contents of binary packages, I can't think of anything aside from contents generation that will find that useful. [12:57] StevenK: But, equally, there's no reason to have it in LP :) [12:57] But it's *easy* if it is in LP. [12:57] StevenK: does it have different IO needs than the rest of the system - e.g. will having it in the main DB sacrifice memory to it whereas on a different system it could be always-cold and we wouldn't care [12:57] And since this is a spare-time project, I'm loving the easy. [12:57] StevenK: But it's in LP if it is in LP. [12:58] does the rest of the system need to know about the implementation of this thing? [12:58] The publisher will [12:58] (if yes, it shouldn't be a service; if no it could be a service) [13:06] StevenK: FWIW I think that the contents.gz thing wouldn't make a good microservice on its own; it would need publishing data included in it. Such redundancy isn't necessarily bad (in fact having a service that handles archives, their internal consistency, etc, including contents.gz, would be awesome) [13:06] StevenK: so I'm totally fine with you including it in LP itself, given that we don't have that other service to put this in instead. [13:06] lifeless: Okay. [13:08] StevenK: it will often be easier (short term) to bundle stuff into the LP tree [13:09] StevenK: I'm glad stub suggested making it into a microservice; I think this particular case is probably too awkward right now, but we need to start doing it more [13:12] alrighty, its pumpkin time [13:12] ciao [14:05] matsubara: hey, sorry didn't answer you earlier === jr__ is now known as Riddell [14:49] wgrant, StevenK: do you have uncommitted changes in dogfood's source tree? [14:50] Yes. [14:50] boo [15:19] I'm writing a Perl script to try and interact with Launchpad using the API. I am able to get a request and access token, but making signed API requests fails. I get a 401 error with a 'Client-Warning: Missing Authenticate header' (despite having a request matching that of the documentation) and an 'Unknown consumer (nameOfMyApp)' message. Any ideas on what might be wrong? [15:23] wallyworld: https://code.launchpad.net/~launchpad-teal-squad/launchpad/lazr-js-kicking-and-screaming [15:28] wgrant: could you send me these cryptic python lines that you used to publish a message on rabbit? [15:29] rvba, bigjools: http://paste.ubuntu.com/634325/ [15:31] benji: https://code.launchpad.net/~huwshimi/launchpad/what-next-712259/+merge/66030 and https://code.launchpad.net/~huwshimi/launchpad/table-headings-728187/+merge/66008 [15:31] bigjools, rvba: http://paste.ubuntu.com/634326/ [15:31] * benji looks. [15:34] huwshimi: https://code.launchpad.net/~launchpad/launchpad/lazr-js-kicking-and-screaming [15:37] rockstar: ping! [15:48] huwshimi: both branches are approved, I had a thought on the second you might be interested in (or not;) [15:48] benji: Thanks a lot, I'll take a look [16:00] stub: http://paste.ubuntu.com/634326/ [16:04] wallyworld_, pong [16:04] rvba: http://pastebin.ubuntu.com/634349/ [16:06] hi rockstar. long story. we are packaging yui as a tarball to go in download-cache and i am porting the lazr-js build utils across to lp. someone said you had done something similar. i was wondering about any gotchas that i should be aware of [16:08] wallyworld_, https://launchpad.net/lazr.jstools [16:08] rockstar: thanks. i'll take a peek [16:08] wallyworld_, hm, there seems to be no branch there, but I'm sure I pushed it. [16:09] wallyworld_, lemme dig around, I'm sure I have a backup of it as well. [16:09] rockstar: ok. thanks. appreciate it [16:09] wallyworld_, I will say that the tools we were using in lazr-js tend to be less effective than, say YUI Compressor. [16:10] U1 is now using YUI compressor. It compresses YUI code a lot better than Chrome's js tools we were using in lazr-js. [16:10] rvba: http://pastebin.ubuntu.com/634351/ [16:10] rockstar: ok. we'll need to take a look at that too then. first step is a straight port and then we can tweak and optimise :-) [16:18] jtv, https://code.launchpad.net/~danilo/launchpad/branch-portlet-details-remove/+merge/66117 [16:25] poolie, I've added the link to jtv's branch to the project wiki page, fwiw [16:29] thanks! [16:41] rvba: http://paste.ubuntu.com/634369/ [16:41] wgrant: thanks. [16:45] Narwhals! Narwhals! [16:46] Swimming in the ocean. [16:46] Riddell: https://bugs.launchpad.net/bugs/801388 [16:46] <_mup_> Bug #801388: some person pickers show "assign me"/"remove assignee" when that makes no sense

< https://launchpad.net/bugs/801388 > [16:49] jcsackett: http://metaquotes.livejournal.com/6644038.html [16:56] jml: Do you perhaps have a moment to go over the BFBIA LEP this week? [16:56] jelmer: yes, I do. [16:57] jelmer: could do it pretty soon, actually [16:57] jelmer: otherwise, make an appointment on my calendar. [16:58] jml: Pretty soon works for me, too [16:58] jelmer: ok. [17:00] Project parallel-test build #79: STILL FAILING in 1 hr 1 min: https://lpci.wedontsleep.org/job/parallel-test/79/ [17:05] Yippie, build fixed! [17:05] Project devel build #844: FIXED in 5 hr 52 min: https://lpci.wedontsleep.org/job/devel/844/ === beuno is now known as bueno-lunch === salgado is now known as salgado-lunch [17:07] deryck, hey, since sinzui is not on IRC, how about you look at https://code.launchpad.net/~danilo/launchpad/speed-up-subscription-tests/+merge/66120 :) [17:08] danilos, sure. :-) Looking now.... [17:10] danilos, Y.lazr.anim was already available due to YUI().use for the test module? [17:10] deryck, yeah, and fwiw, the test works [17:10] deryck, I also increased the wait to 200ms from 20ms on sinzui's suggestion [17:11] danilos, I'm worried the 200ms is still too long. But there can be some difference between machines.... [17:11] danilos, but I would think 100ms should be enough even for slower machines. [17:12] unless the dom work is happening beyond the anim completing. [17:13] danilos, but sinzui tells me know 100-200ms is expected. So I say try 100. Lower is always better :) [17:23] deryck, 20ms works for me just fine, but let's try 100ms for buildbot (if it ever gets back there :) [17:23] danilos, I'm chatting more with sinzui about this now. his machine is what failed earlier, not buildbot. [17:23] deryck, oh === bueno-lunch is now known as beuno [18:20] Yippie, build fixed! [18:20] Project db-devel build #675: FIXED in 5 hr 53 min: https://lpci.wedontsleep.org/job/db-devel/675/ === salgado-lunch is now known as salgado [22:08] flacoste: hi [22:39] Project devel build #845: FAILURE in 5 hr 34 min: https://lpci.wedontsleep.org/job/devel/845/ [23:07] lifeless, Riddell, maybe we should just remove that option [23:07] does anyone ever want to see the least recently changed bugs? [23:08] i suppose maybe if you want to update the stalest inprogress or incomplete bugs [23:08] * jelmer doesn't think he's ever used it or would ever use it [23:09] perhaps 'changed long ago' [23:09] kind of gets into whether people ven know what 'changed' means, exactly [23:11] the bug in this area i would actuall ymost like closed is https://bugs.launchpad.net/launchpad/+bug/277352 [23:11] <_mup_> Bug #277352: should be easier to search for closed bugs < https://launchpad.net/bugs/277352 > [23:11] (which is not so trivial, but maybe not so hard) [23:11] i'm surprised it doesn't have more dupes [23:15] lifeless: when's the next lpnet rollout? [23:19] poolie, that one has annoyed me too in the past [23:21] poolie: when someone in dubling requests it [23:24] is it cheap? can i just request it? [23:27] if you follow the process, yes. [23:28] one bit of which is 'do not deploy right before everyone goes to sleep [23:28]