=== flacoste is now known as flacoste_afk === flacoste_afk is now known as flacoste [00:09] rinze: new nick jelmer? [00:10] thumper: Two nicks :-) One I use for work channels and one for non-work channels in an attempt to keep the two more separate [00:10] obviously I'm failing since it's midnight here [00:10] rinze: :) [00:11] rinze: and you are in a work channel [00:12] rockstar: What are the security concerns with 'run' in recipes? [00:12] We already run it in a secure environment. [00:39] thumper: are code imports for packaging branches on the roadmap for the near future? [00:39] rinze: not the immediate future [00:41] Lots of the work was done earlier in the year, though. === mordred_ is now known as mtaylor [00:45] wgrant: not related to code imports for packaging branches.. [00:46] (I'm not complaining, regular code imports work quite well too) [00:48] rinze: IIRC james_w removed lots of roadblocks relating to that. [00:48] newImport is on IBranchTarget now isn't it? [00:49] I'm not sure if it got finished, but it was mostly done. [00:49] ah, I didn't realize that [00:49] James is everywhere :-) [00:49] He is. [00:53] you might be able to create code imports for package branches over the api already [00:54] I wonder how happy the UI will be about that. [00:55] https://edge.launchpad.net/+apidoc/devel.html#source_package-newCodeImport [00:55] possibly not very [00:56] It's possible it will be fine. [00:56] But if it was working, I would have thought we'd see some of these imports around. [00:56] mm, might be ok [00:57] someone should try it on staging :-) [00:57] * rinze is about to [01:02] mwhudson: w00t, that works [01:02] https://code.staging.launchpad.net/debian/experimental/+source/tdb [01:02] * rinze hugs james_w [01:03] cool [01:03] Excellent. [01:04] mwhudson: thanks! [01:04] * rinze gets some sleep [01:04] even https://code.staging.launchpad.net/+code-imports?field.review_status=NEW&field.review_status-empty-marker=1&field.rcs_type=&field.rcs_type-empty-marker=1&submit=Submit+Query works [01:05] * mwhudson approves the branch, lets see if the staging code import infrastructure has rotted and died again === Ursinha-dinner is now known as Ursinha [01:23] seems not [01:23] Yep. [01:23] Although codebrowse is unhappy with it. [01:23] oh? [01:23] boo [01:23] Try to browse into debian/ [01:24] Hmm. [01:24] yeah, strange [01:25] http://bazaar.staging.launchpad.net/~jelmer/debian/experimental/tdb/experimental/files/head:/debian/patches is ok though [01:26] Odd. [01:35] looks like a loggerhead bug [01:38] spm: Hi. There's an upload failure caused by a buildd-manager bug that requires some time-sensitive debugging. Do you have a few minutes? [01:39] wgrant: sure [01:39] spm: Firstly, when does librarian-gc run? [01:39] it destroys the evidence (which was why the debugging failed last time) [01:39] "regularly", let me verify [01:41] once a day, 6pm server [01:41] That was 7ish hours ago? [01:42] ath too hard; kcalc; yes. [01:42] *math [01:42] If so, it may not have erased everything yet. Yay. [01:42] heh [01:43] So, https://edge.launchpad.net/ubuntu/+source/qt4-x11/4:4.7.0~beta2-0ubuntu2/+build/1879966 somehow succeeded once, then succeeded again. [01:43] It shouldn't have run again after it succeeded the first time, of course. [01:44] Can you check how many LFAs there are with the filename 'buildlog_ubuntu-maverick-powerpc.qt4-x11_4:4.7.0~beta2-0ubuntu2_BUILDING.txt.gz', and how many with the filename 'buildlog_ubuntu-maverick-powerpc.qt4-x11_4:4.7.0~beta2-0ubuntu2_FULLYBUILT.txt.gz'? [01:44] (the buggy retry unlinks the log LFAs, so we can't tell what's gone on through the UI, and they get destroyed by librarian-gc as soon as it runs) [01:45] But they should still be around at the moment. [01:45] Since the event was roughly 6 hours ago. [01:46] so it succeeeded twice? that's a nice trick. [01:46] Yes. [01:47] And the second time failed to upload, since the files were already uploaded. [01:47] well [01:47] And because the Soyuz data model is awesome, there's no record in the DB of the first attempt, except for the orphaned LFAs. [01:47] if it succeeded the first time it should succeed the second time too :-) [01:47] it's the retry that's mysterious [01:48] It's a Miracle, perhaps? [01:51] Do you want queries for my above request? [01:53] SELECT * FROM libraryfilealias WHERE filename IN ('buildlog_ubuntu-maverick-powerpc.qt4-x11_4:4.7.0~beta2-0ubuntu2_FULLYBUILT.txt.gz', 'buildlog_ubuntu-maverick-powerpc.qt4-x11_4:4.7.0~beta2-0ubuntu2_BUILDING.txt.gz'); [01:53] if you can that'd be wonderful - just got pulled into a U1 deploy/update thingy... [01:54] Ah, you can do that. This isn't so critical now I know there's a while until librarian-gc runs. [01:55] so generous of you! ;-) [01:56] Heh, sorry. Just the last couple of times we've tried to catch this, we've been too late. [01:56] nod [01:56] http://paste.ubuntu.com/467277/ fwiw [01:57] Thanks. [01:59] yarp; and they're both still live too [02:00] Yeah. Unfortunately the it looks like the first occurence of the issue with this build was a couple of days ago, and it was just retried again this morning. [02:00] curious: The following NEW packages will be installed: libdconf0 libmpfr4 <== the latter is new [02:00] So we are again too late. [02:01] spm: Um, you're running maverick? [02:01] I'm not, no. [02:01] Those two are only in maverick... [02:01] * spm raises eyebrows [02:57] +class ILaunchpadPublicationDirective(IRequestPublicationDirective): [02:57] + [02:57] + priorty = Int(required=False) [02:57] I don't think that's how one spells 'priority'. Does this mean that interface doesn't actually do anything? [02:58] wgrant: oops [02:59] Heh. [03:00] yes, the interface is in fact not required [03:10] wgrant: want to review a branch in a sec? :-) [03:11] * wgrant isn't a reviewer yet... [04:27] wgrant: we should fix that [04:29] Ursinha: still up ? [04:29] haha yes sir [04:29] I wanted to talk to you [04:30] when should we use the oops tag? (bug 607879) [04:30] <_mup_> Bug #607879: https://bugs.edge.launchpad.net/~person/+participation timeouts [04:30] about a timeout bug [04:30] oh oh, I'm in trouble ;) [04:30] lifeless, timeout implies oops [04:30] so it's redundant to tag timeout and oops [04:30] Ursinha: So, I was following https://dev.launchpad.net/PolicyAndProcess/ZeroOOPSPolicy [04:30] lifeless, and I love you for that, but let me read the page [04:31] lifeless, "It should be tagged with either 'oops' or 'timeout' on it." [04:31] Ursinha: I'll stop using both on the same tag [04:31] that? [04:32] yeah, i think its a little subtle [04:32] I mean, to me the value in a oops tag is that one can look at the tag and get all oops related bugs [04:32] but if it causes some script/reporting issue its obviously better to have only one, which is what I'm guessing is the issue? [04:33] lifeless, is it hard to get bugs tagged oops and timeout at once? [04:33] I mean, the two sets [04:34] lifeless, I was pondering about having only one tag to fetch all oops bugs, but I guess lp lets you query bugs with one or another tag very easily [04:35] Ursinha: well, theres quite a few tagged both before my filing efforts yesterday [04:35] it would be easy to clean the data up [04:35] really? why? [04:35] I don't know, it was just like that [04:36] (I think) [04:36] <- 0536, not 100% awake yet [04:36] :) [04:36] anyhow - I'll check and fix today, thats easy. [04:37] lifeless, that's ok, not that critical, just trying to be consistent as I know that some scripts that fetch stats consider them separately [04:37] yup [04:37] lifeless, about the timeout bug [04:37] I'm not panicking on it, I'm just rectifying something I've made a little worse. [04:37] easy [04:38] ok, about the bug - which one ? [04:38] finding the number, just a min [04:40] lifeless, bug 607879, that you filed for +participation timeouts [04:40] <_mup_> Bug #607879: https://bugs.edge.launchpad.net/~person/+participation timeouts [04:40] ok [04:40] I see that now this bug is linked to another oops, the most offender in timeouts list, like https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1662A100 [04:41] I think thats the oopstools confusion [04:41] I put the link in on a more suitable oops, I'm sure [04:42] yeah, I did - the ones in the bug at the top [04:42] I wanted to know if they're related somehow, of if the correct bug for this oops is bug 424671 [04:42] <_mup_> Bug #424671: attachments: accessing attachment's message is very slow [04:42] they are only related by being 'timeout' errors with 'select' in the exception value [04:42] e.g. not related at all [04:42] right [04:43] that bug in oops-tools is really annoying [04:43] yes [04:43] the timeouts count is ultrahigh, I guess that bug needs some more attention [04:44] gmb had a fix in the pipeline [04:44] but went on leave [04:44] and now deryck is too [04:44] is bryceh at the rally? or brian? I can ping them [04:45] lifeless, nope we're both in PDX [04:45] ok, I might see about moving it forward today [04:45] cool lifeless [04:46] perhaps you can pick it up my afternoon and drive it? its kindof killing leanne :) [04:46] thanks [04:46] lifeless, 'you' me or bryceh? [04:46] bryceh [04:46] or brian [04:47] now where did the branch go [04:47] * bryceh needs to learn to keep his fat mouth shut [04:47] haha [04:47] lifeless, the bug that should be fixed in oops tools is bug 461269 [04:48] <_mup_> Bug #461269: oops reports should be grouped by oops signature not exception type and exception value [04:48] but I guess I already told you that [04:49] this bug is kinda critical to our ZeroOopsPolicy to happen :/ [04:54] is matsubara's branch insufficient? [04:55] lifeless, no idea. he'll be back today and I'll ask him. [04:56] Ursinha: revno 11156 in devel [04:56] Ursinha: should fix that attachments thing [04:56] lifeless, cool [04:56] so I'll test it on edge and if its better there, organise a CP [04:58] meep: http://www.zdnet.com/blog/security/dell-ships-motherboard-with-malicious-code/6901?tag=nl.e589 [05:00] Awesome... [05:04] bryceh: http://pastebin.com/GTc6Y1LY [05:04] bryceh: I have /no/ idea how I seem to have triggered these failures in bugs [05:04] I haven't changed templates [05:05] I'm going to sleep a bit [05:05] gnight [05:05] bye lifeless [05:06] wgrant: or perhaps you have some idea? [05:07] wgrant: oh oh, excellent you're up - you wouldn't happen to be willing to qa something for me ? [05:07] lifeless: Sure. [05:07] Also, looking at that traceback now... [05:08] wgrant: make an api call to https://api.launchpad.net/1.0/bugs/414746/attachments - it should boom; make the same to edge - if it works, we have a CP we need to do. [05:08] <_mup_> Bug #414746: speakers cannot be muted when using headphones regression (karmic)

[05:09] Most of the diff is crap -- the problem with the first and last is that the mailto: stuff is missing. [05:09] ok [05:09] well thats due to having ubuntu as a stopword now, I think [05:09] so I'll just nuke that [05:09] Ah. [05:10] lifeless: Timed out on edge for me. [05:10] darn [05:10] OOPS-1664ED389 [05:10] Worked the second time, though. [05:10] ok, give that a few minutes and I'll get another bug up [05:10] well, thats an improvement [05:10] != fixed though [05:10] Still fails on production. [05:10] gawd yes [05:11] lib/lp/bugs/tests/../stories/guided-filebug/xx-sorting-by-relevance.txt is still naffed, hmm [05:12] Right, I'm not sure about that one. [07:10] turns out it was one extra row missing or so [07:10] I'm going to do a follow up patch to remove all filtering of terms === almaisan-away is now known as al-maisan [08:30] losa ping [08:30] lifeless: can you give us a few - in a review meeting atm [08:30] of course [08:31] take as long as needed [08:31] thx [08:33] * wgrant is also interested on when Lucid's happening. [08:34] Since there's a dpkg issue that's fixed there. [08:43] \o/ rockstar your bugs all came through qa bot just now ;) [08:44] flacoste: are you still around ? [08:45] flacoste: if so, could you, if you agree, move rt 40477 and 40480 both to pri 88, and drop rt 40403 to pri 87, and nuke rt 31058 [09:00] Hey [09:09] hi mrevell [09:10] Hey there lifeless [09:17] lifeless: what did you need? [09:18] I wanted to see if I could help with the slony packages thing [09:18] either by doing, or perhaps talking with the server team folk here who are keen to offer assistance for backports and things like that that we need [09:19] did my backports not work? [09:19] lifeless: ah, spm (who's just EODed) is working on that one, and I believe have made some better progress on it today [09:20] maxb: I think they did, but its a ppa and versioning + availability of old builds trickiness [09:20] maxb: or something like that [09:21] mthaddon: ok. [09:22] lifeless: although the lucid buildbot instance has been failing consistently for a few days now (had meant to chase someone about that) which would be a problem for lucid upgrades [09:22] mthaddon: well if you need help of any sort; please let me know :- on the packages side Jos has made it clear that he considers his team are here to support us; on other sides - well, I have the odd trick up my sleeve [09:22] mthaddon: I believe mars looked at that overnight; will see if there is a bug and if not make one. [09:22] cool, thx [09:23] lifeless: before I go eat, and despite my EOD'd nature; yeah. it's just been a tad fiddly, and a bit of a learning experience for me. I am *hopeful* that the next submissions (early tomorrow I hope) will succeed, and then progress will occour. [09:23] spm: thanks! [09:24] the most recent build was a fail, becuase it built the pg 8.3, with a dependancy on pg 8.4. which is um... bad. [09:25] spm: the packages, or bb ? [09:35] stub: around ? [09:35] physically, yes. [09:35] whats he wiki page that the lp dependency deb updates is documented on ? [09:36] seems i doesn't mention doing hardy as well as lucid atm [09:36] brb [09:36] LaunchpadPPA [09:41] gmb: Hi [09:41] rinze, Morning. [09:41] hurrah for /whois [09:43] gmb: There's a buildbot failure for db_lp in bugtask-search.txt. It looks spurious but caused by the fact there is no sorting done before printing. [09:43] gmb: I was wondering if you could confirm that - https://lpbuildbot.canonical.com/builders/db_lp/builds/971/steps/shell_7/logs/summary [09:44] rinze, Yeah, that looks to be the case. [09:44] Thought we'd fixed all of those. [09:45] rinze, Want me to take care of it or are you already in the process. [09:46] gmb: I was already in the process of getting a branch up. [09:46] rinze, Okay, cool. [10:02] gmb: Reading the doctest in more detail I'm wondering if simply sorting wouldn't defeat the test - it asserts that bug #9 is on top of the list. [10:02] <_mup_> Bug #9: Rosetta's po parser is too strict [10:02] Gaaargh. [10:03] gmb: Does the order not matter for the other bugs ? [10:06] rinze, From reading the test I think not. But it's spectacularly unclear. [10:06] *why* is it printing out bugtask ids? Hell's teeth. [10:07] rinze, So, yes, sorting would defeat the object of the test [10:07] Because the test is that things are sorted properly. [10:07] So there's some bigger underlying cause here. [10:09] gmb: Any chance you could take over? I can handle adding a trivial sorted() call somewhere, but this looks more complex. [10:09] rinze, Sure. === persia` is now known as persia [10:38] gmb: oh hai [10:38] gmb: aren't you on leave? [10:39] lifeless, Yesterday I was. Working today and tomorrow then I'm on leave for two weeks. [10:39] qargh [10:39] testfix ? [10:40] lifeless: https://lpbuildbot.canonical.com/builders/db_lp/builds/971/steps/shell_7/logs/summary [10:41] hmm [10:41] gmb: tell me about that ^ [10:41] I have a branch changing bug stuff, so I can put a fix in too [10:42] lifeless, I'm trying to look at it now but it's taking an age to update my local copy of db-devel. [10:42] lifeless, It looks like something broke with the ordering of search results. Will know more shortly, hopefully. [10:43] they are ordered by fti [10:43] aren't they ? [10:43] gmb: I'm about to land my malone branch - it passed ec2land [10:44] oh, so heat is intended too [10:44] why does db-devel builds break devel ? [10:45] lifeless, The test that's failing tests that ordering by '-number_of_duplicates' works properly. Which it apparently doesn't any more. Can't say why, yet. [10:45] lifeless, I think it's a stop-the-line measure. One builder breaks, everything stops. [10:45] (Which is why trying to get my CP for initial_message landed was such a ballache) [10:47] gmb: which, btw, isn't enough. [10:47] lifeless, Yeah, we figured as much on Tuesday IIRC. [10:50] also [10:50] holy fuck searchTasks [10:52] rev 11188 is a candidate [10:52] * gmb looks while make schema runs [10:53] its changing duplicate bug logic [10:53] AAAAA. [10:53] Yep. [10:54] cause I'm keen to get this landed, I'd love to put a one-liner in my branch and shove it through ;) [10:55] shame deryck made duplicateof readonly :) [10:56] I wonder whether this is as simple as a db flush that needs to happen. [10:56] Mind you, there's already a flush_database_updates() call in there. Hmm. [10:57] * gmb adds a transaction.commit() for good measure [10:57] how dnah [10:57] urgh, death to commit in tests [10:57] lifeless, yeah, didn't work anyway :) [10:57] doubt that thats it - you're calling into model code directly. [10:58] True. [10:59] bigjools: The master/slave split means we have to, though... [11:00] bigjools: I wish there was a way around that. [11:00] there isn't [11:00] Damn. [11:00] we still have a lot of tests doing commit() unnecessarily though [11:00] Well. [11:00] Agreed. [11:01] I'm considering the idea of having another master store for derived distros actually [11:01] There are two reasons I know of: 1) librarian 2) slave store [11:01] Are there any other reasons left? [11:01] not that I know about [11:01] we can fix (1) in tests [11:01] How? [11:02] make the file available in the librarian right away [11:02] you may be misunderstanding the issue there [11:02] I guess. [11:03] although, read committed may workaround it [11:03] the issue is that when we use slave stores to read data, we have to commit to get them to sync [11:03] and I think that's a good thing to still have to do in tests [11:04] Apart from the fact it's slow. [11:04] indeed [11:05] lifeless, Ah, interesting. Bug 10 is marked as a dupe of bug 9, but bug 9's number_of_duplicates is still zero. It should be 1; that's why the sorting's off. [11:05] <_mup_> Bug #10: It says "displaying matching bugs 1 to 8 of 8", but there is 9 [11:05] <_mup_> Bug #9: Rosetta's po parser is too strict [11:05] <_mup_> Bug #9: Rosetta's po parser is too strict [11:05] Shut up you stupid bot [11:05] gmb: so the aggregation is failing [11:06] is number_of_dupes a cached value - either db or model ? [11:06] lifeless, Well, I think that it's a trigger that's failing to be run for some reason. [11:06] gmb: or a bug in the trigger :P [11:06] I'm checking now. [11:06] Yeah. [11:08] yeah ? [11:08] lifeless, The triggered function *looks* fine (database/schema/trusted.sql:917) [11:08] lifeless, That was a sort of "yes, that's possible" noise. [11:08] I can't express "ugnh" properly in textual form [11:09] no, its wrong [11:09] stub: what do you think to the idea of having a new master store for derived distributions? I am concerned about the load they'll put on the DB when doing everything a distro needs to do. [11:09] lifeless, Really? [11:09] gmb: totally [11:09] lifeless, Maybe I'm just not caffeined-up enough yet. Why? [11:10] bigjools: I'm keen on sharding/partitioning; I think you'll find that that isn't going to split out terribly well with our current setup; also I think the load isn't a huge concern in the short term - we are write limited yes, but we can reduce IO massively by fixing a few bugs. [11:10] gmb: because [11:10] gmb: voice? [11:11] I really want a whiteboard for this [11:11] lifeless: why do you think it won't split? [11:11] the write load that Soyuz generates is huge, BTW. [11:11] because you have links throughout the system that are doing FK's [11:11] and slony isn't a multi-master system [11:11] lifeless, Sure. Though be warned, I'm in a coffee shop, so there may be bean-grinding and child noises. [11:11] Why is the write load so huge? [11:12] The read load is certainly massive. [11:12] lifeless, Skype, mumble? [11:12] gmb: skype; id ? [11:12] publisher for starters [11:12] lifeless, binnsgm. Starting it now. [11:12] bigjools: It might actually make things better. At the moment, we have 31 distributions but almost the entire database is linked to just 1 (Ubuntu). This can give us some wonky query plans. [11:12] bigjools: How's that write-heavy? [11:12] It just touches a couple of fields on a few publications. [11:12] a lot of publications [11:12] It's going to be doing less than the thing that sends bug notifications. [11:13] the scripts also mostly use the master DB out of necessity [11:13] True. [11:13] which is part of what I meant by write load I guess [11:14] The publisher doesn't need to be as bad as it is. [11:14] undoubtedly! [11:14] I'd like to pipeline it [11:15] We need to work out what to do about index generation. [11:15] Everything else is pretty quick. [11:16] (apart from source domination, but that's a trivial fix) [11:17] for indexes we can just append to Packages/Sources [11:17] But what exactly do you mean by pipelining? [11:17] the opposite of batching like we do now [11:17] I considered that... but we have to regenerate them some time. [11:17] bigjools: gah, that's such a bad bad bad tradeoff [11:18] yes, we can do it occasionally [11:18] elmo: why? [11:18] you're trading CPU time on one server (ours) for increased download time for millions and millions of users [11:19] so then we also need incremental updates - isn't there something that does that already? [11:19] yes, but it's crack and also pessmizes things for users [11:19] pdiffs aren't really awesome. [11:19] but I also don't buy the argument that the answer to 'append sucks' is incremental updates [11:19] the answer is 'don't do append' [11:20] why? [11:20] because it's not expensive to actually write a packages file in a non-append fashion [11:20] apt-ftparchive is slow, yes, that doesn't mean doing non-append packages file generation will always be slow [11:20] At the moment it is. But I should work out how to effectively benchmark my caching experiments from earlier in the year. [11:21] someone told me that a-f is actually quick, it's generating its input files that's slow [11:21] bigjools: they're lieing [11:21] Both parts are slow. [11:21] and/or confused and/or stupid [11:21] The publisher logs make that clear. [11:21] or some combination thereof [11:21]