[00:03] wallyworld: http://penny-arcade.com/comic/2011/09/12 === StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK | Critical bugs: 263 - 0:[########*** stack smashing detected ***: ./lp terminated [00:04] ohai StevenK [00:04] Could you point me to something that will help with javascript unit tests? [00:05] No [00:05] Since I have no idea myself [00:05] excellent! [00:05] I'll wait for wallyworld then. [00:06] I made a whole lot of changes to untested code. Can't get away without writing tests anymore. [00:09] hi nigelb [00:10] wallyworld: Hi! I did some major changes to +check-links and lp-links.js [00:10] nigelb: excellent. what changes? [00:11] it pulls in the title and updates the dom with bug title [00:11] so I had to change how the API is used to make my changes generic. [00:11] https://code.launchpad.net/~nigelbabu/launchpad/bug-title-849121/+merge/75267 [00:11] * wallyworld looks [00:12] Actually, the example in the MP is slightly wrong. /me corrects. [00:24] wallyworld: How does it look? I hope it doesn't make your eyes bleed :) [00:25] * wallyworld looks again [00:26] nigelb: the branch links value should be "invalid" [00:26] but it looks fine i think [00:26] it's a nice addition [00:27] \o/ [00:28] did you have a question you wanted to ask? [00:28] err, is there documentation about javascript unit tests? [00:28] i didn't look at the code in detail, just the new output [00:28] https://dev.launchpad.net/JavascriptUnitTesting [00:28] that plus looking at what others have already done [00:29] oooh. Awesomeness \o/ [00:29] plus asking on here if you are stuck :-) [00:29] :) [00:30] nigelb: i have to go out for a bit to see a doctor. but ping me later if you have any questions etc [00:31] wallyworld: sure! :-) [00:31] good luck with the tests :-) yui tests aren't too bad when you get used to them [00:32] Hah. The last time I tried I was fairly homicidal :P [01:08] wgrant: https://code.launchpad.net/~stevenk/launchpad/missing-all-still/+merge/75286 [01:09] StevenK: jtv may have a branch to remove that import. [01:09] StevenK: It was a temporary import of a private class, I believe. [01:10] "temporary" -- it's been bugging me for two days === G_ is now known as G [01:36] lifeless: You have a 5 month old LP branch, changing the way INCOMPLETE is stored. [01:36] lifeless: 'tis the oldest active review. [02:08] wgrant: feel free to fix it and land it [02:28] hey, I'm from linaro and would like to test the derived distro feature, I wonder if I have any special permission even to play with it on dogfood/staging? [02:29] rsalveti: What sort of thing do you want to test? Much of it still requires sysadmin handholding at this stage. [02:29] wgrant: basically the idea is to start using this feature to guide the linaro-ubuntu development [02:30] I'm kind of the main user for this feature from the linaro side [02:30] was talking with flacoste about it, and he also pointed me bigjools to help, but don't think he's on-line now [02:30] Right, bigjools is the one to talk to, but he's in the UK. [02:31] I don't think (qa)staging have all the cron jobs set up. [02:31] And we don't know if derived distros actually works yet. [02:31] Ubuntu is using the native syncing features, but that's all that's actually known to work properly. [02:31] initially I'd like to see if I'd be able to test it against staging or dogfood, but don't know yet if I can get the permission to play with it just at staging [02:31] yeah, that's the main feature even for us [02:31] when I was doing exploratory testing, afair bigjools was running the cronjobs manually [02:31] and the idea is to start using it to see what is still missing [02:32] rsalveti: Well, critically we don't even know if you can create a new usable distribution. [02:32] I have my doubts over whether initialising it with packages actually yields a usable set of packages. [02:32] ideally we would like to be able to fully use it for linaro 11.10, that's the cycle we're planning to rebase on top of oneiric [02:32] rsalveti, I think that you'd need superpowers to create a distro [02:32] Right. We can try creating a test linaro distro on staging once spm is back, if we want. [02:32] wgrant, is the feature that alpha still? [02:33] cool, will move this conversation over email then [02:33] wgrant: thanks for your help anyway [02:33] rsalveti, spm should be back soon, I guess [02:33] rsalveti: That's probably best. We can get some stuff set up now by running cronjobs manually, but bigjools is the guy you want to coordinate with. [02:33] Ursinha: but I'll be gone soon :-) [02:33] Ursinha: The syncing is tested. [02:33] Ursinha: Everything else is not. [02:33] wgrant, hm, right [02:34] wgrant: cool, he's my main poc, so good to know he's the right guy for it :-) [02:34] so I believe rsalveti would do the testing :) [02:34] that's the idea [02:34] The extent of the initialisation testing so far seems to have basically been "it doesn't crash, therefore it must be good" [02:34] haha [02:34] we can only test when there's someone really using it :-) [02:35] We created the first production test last night. [02:35] https://launchpad.net/bilimbitest/angry [02:35] hahaha [02:35] lol === almaisan-away is now known as al-maisan [02:35] cool [02:38] We may be able to push the first builds through production tonight, if things go well. [02:40] rsalveti: Does Linaro rebase on the latest Ubuntu release each time we release? [02:40] rsalveti: Or does it merge like Ubuntu does from Debian? [02:40] wgrant: both [02:40] wgrant: we use the stable ubuntu release to do our main releases [02:41] but at the same time we're also working against the dev release, testing our packages and then pushing directly to ubuntu [02:41] but the main priority is to be on top of the latest stable release [02:41] like, we expect 11.09 to be our last natty based release [02:41] and do the first oneiric based one next month, together with the ubuntu release [02:42] I am disturbingly ignorant of how Linaro operates. Do you have a dak archive, or do you just use PPAs on top of Ubuntu? [02:42] wgrant: currently we're just using a PPA [02:42] and that's why we wanted the derived distro so much, working with a PPA is quite annoying [02:42] Right. [02:42] as we can't track upstream updates [02:43] and we can have bugs against packages [02:43] and so on [02:43] *can't [02:43] Yep. [02:44] it's specially annoying when working against the dev release [02:44] So, hopefully you can talk to Julian in your morning some time. [02:44] Otherwise I guess there will be a lot of email and talking to people like me, who are around sometimes when you are. [02:45] yup, will try to ping him directly tomorrow morning [02:51] wgrant: Can haz review? https://code.launchpad.net/~stevenk/launchpad/denorm-bspph-garbo/+merge/75118 === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === jtv changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK, jtv | Critical bugs: 263 - 0:[########*** stack smashing detected ***: ./lp terminated [03:18] StevenK: I guess I'll go to work on your branches then. Sorry, old boy. [03:24] jtv: I have a missing import branch -- which you can ignore if you're going to fix it. [03:28] StevenK: too late. === al-maisan is now known as almaisan-away [04:30] StevenK: I'm afraid I haven't been very kind to your branches. I was joking when I did the "sorry I'm going to review you" bit though! [04:49] jtv: I've done two of these migrations using garbo jobs before and have never been asked to file a bug to remember to remove them when they're done. [04:50] StevenK: it's just a recommendation—but I find it helps, e.g. if the code becomes a problem while you're on holiday. [04:51] It also means that the task is explicit, and not hidden among the pile of things you know you have to do that others aren't aware of. [04:51] Oh, wgrant and sinzui are well aware of what I'm doing. [04:51] A bug would be nice. [04:51] Given this should be quick. [04:51] It can sit around assigned to you for a few days. [04:52] It's easy to forget these things, and that's how you get… Soyuz. :) [04:52] jtv: NOW you're learning. [04:52] Meh :-P [04:52] wgrant: technically, I've been drinking to forget Soyuz for months now. [04:59] Quick question: the builddmaster/accepted and builddmaster/incoming directories seems to be full of files; can these be safely deleted? [04:59] also wondering about the fatsam directory--what does it do and can it be cleaned up? [05:01] kb9vqf: fatsam is the librarian's old name. [05:01] kb9vqf: That's all the librarian data. [05:01] ok [05:01] kb9vqf: And I thought I answered your accepted/incoming question a month or so back :) [05:01] kb9vqf: Incoming is the queue... stuff shouldn't be in there once process-upload.py runs. [05:01] If there is, you're probably not running it properly. [05:01] accepted you can dispose of. [05:02] wgrant: You answered my question about poppy/incoming :) [05:02] I was wondering about builddmaster/incoming [05:02] kb9vqf: Ah. [05:02] kb9vqf: Are you running process-upload.py over that dir? [05:02] A year ago it was run automatically by buildd-manager, but that's no longer the case. [05:02] the builddmaster directory? [05:02] Yes. [05:03] I don't think so [05:03] * kb9vqf goes to check [05:04] Something like 'scripts/process-upload.py -C buildd --builds /srv/launchpad.net/builddmaster' [05:04] The '-C buildd --builds' bit is important. [05:04] As far as I can tell I am only running it over the poppy directory [05:04] unless it is in a cron script somewhere [05:05] It's a separate cron job now. [05:05] and it is supposed to clean up the builddmaster directory? [05:05] It will do that once it has processed the uploads. [05:05] If it's not running, your builds aren't going to do much. [05:05] They will just sit in the upload queue forever. [05:05] everything is working OK so I think it is running [05:05] What rev are you running? [05:05] * wgrant checks. [05:05] an older rev [05:05] probably a year or so earlier [05:06] r10983 [05:06] ok [05:06] June last year. [05:06] So. [05:06] That's before this change. [05:06] ok [05:07] That may explain why there's stuff left in incoming/. Is it mostly old? [05:07] so it is safe to delete the builddmaster/incoming directory contents then? [05:07] * kb9vqf goes to check [05:07] yes [05:08] Kill them all. [05:08] delete all the files? [05:08] there are some new ones in there as well [05:08] well, newer [05:08] * kb9vqf just wants to double check before hosing his system :) [05:08] With the old code, if they're not from builds that have finished in the last few minutes then they're probably never going to be removed automatically. [05:08] buildd-manager ran process-upload automatically once each build completing, telling it to look only at that build. [05:09] so everything in this directory already has a copy in librarian for the PPA? [05:09] So it won't ever look at stuff from old builds. [05:09] Well, I wouldn't really expect stuff to be in there. But if it made it into the PPA's archive, then yes, it's in the librarian. [05:09] I think I understand [05:10] and deleting these files would not delete any published binaries or sources [05:10] Right. [05:10] That's just the intermediate queue between the buildds and the DB/librarian. [05:10] I'm tempted to go on the safe side and only delete stuff that is a few days old or more [05:10] ok, now I understand :) [05:10] What sort of stuff is left that is new? [05:11] .deb files [05:11] .dsc files [05:11] Hmm. Odd. [05:11] https://dev.launchpad.net/Soyuz/TechnicalDetails is mostly brand new, and might be a helpful reference at times. [05:11] It's still being written. [05:11] basically the output of a builder [05:11] ok [05:12] lots of it from a developer's perspective, but may still be handy for your purposes. [05:12] so just to make sure I have this straight...there are two queues, one that takes uploaded source packages and one that takes built binaries from the builders? [05:12] Right. [05:12] They're both handled by process-upload. [05:12] and each queue's contents are eventually loaded into librarian? [05:12] ok [05:12] I feel much better about deleting those files :) [05:12] But for buildd uploads, buildd-manager runs it automatically (well, not any more, but in your code) [05:12] Once process-upload runs, those files are useless. [05:13] right [05:13] and since I've had the buildd manager die on me... [05:13] it might explain the leftovers [05:13] Yep. [05:13] ok [05:13] thanks for the help :) [05:13] np === maxb_ is now known as maxb === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK, jtv | Critical bugs: 261 - 0:[########*** stack smashing detected ***: ./lp terminated [05:36] StevenK: Are devel/db-devel jenkins builds meant to be disabled? [06:15] Morning. [06:16] Hi nigelb. [06:16] Now I've fallen ill. Sigh. [06:16] More LP time :P [06:16] heh [06:18] Hrm, devel has not yet been merged into db-devel. [06:18] buildbot breakage still on-going? [06:26] wgrant: Yes [06:26] wgrant: Let me fix that [06:27] wgrant: How did I end up asking the exact same question about a few minutes after you. [06:27] Should. Get. Away. From Computer. [06:27] wgrant: Fix0rated [06:28] StevenK: Thanks. [06:28] nigelb: buildbot should pass in <10min. [06:28] \o/ [06:28] wgrant: It was disabled in case I was dealing with config [06:29] Ahh. [06:45] buildbot passed! [06:45] OMG [06:45] Both of them. [06:45] Too late for fastdowntime tonight, though :( [06:51] wgrant: Really? [06:52] This is what happens when you conspire to steal FDT time :P [06:52] StevenK: We need staging to update. [06:52] nigelb: wallyworld stole my window :( [06:52] bwahaha. [06:52] An hour before he was meant to start for the day, too! [06:52] haha [06:52] So I start at 9am, thinking I'm going to get my patch in first. [06:52] But find that his is already landed. [06:52] Baaaah. [06:53] :D [06:53] I love it. [06:54] Hrm. db-devel branch page timing out. Known? [06:56] It will have just pushed. [06:56] And will be scanning. [06:56] Might time out for 30s or so. [06:56] AH [06:56] Yes, that sucks. [06:56] haha [06:56] But branchrevision is terrible. [06:57] "udd importer should make tea while launchpad is down" [06:57] Heh [06:57] wgrant: I wish that and loggerhead started working better. [06:57] Yeah. [06:58] s/started \(work\)ing better/\1\ed/ [06:58] Doh, one extra \ [06:59] "I forgot to escape something. Wheeee[taptaptap]eeeeee" [06:59] StevenK: You were dealing with rvba's confirmationoverlay? [07:00] Also, your DB patch has somehow conflicted with db-devel. [07:00] It has? [07:00] This is a bit screwed. [07:00] stub landed that [07:00] Contents conflict in database/schema/patch-2208-87-2.sql [07:00] Hmm. [07:00] My patch should win, it's *applied* [07:01] Yes. [07:01] And there's no 87-2 in stable to conflict with it. [07:01] But it still conflicted. [07:01] And it wouldn't have landed with a conflict. [07:01] So, WTF. [07:01] How can you conflict with no file? [07:02] Oh, database/schema/patch-2208-87-2.sql exists in db-devel [07:02] Contents conflict often happens when the same file is added in two different branches. [07:02] StevenK: Yes. [07:02] But it's not in stable. [07:02] AFAICT [07:02] added twice rather than added + merged ? [07:02] lifeless: Shoo [07:02] If he's here, he could lend his bzr expertise to work out WTF is going on here :P [07:03] 87-2 has never been in stable. [07:03] So how on earth is it conflicting when being merged into db-devel. [07:03] let me just suck down both branch tips [07:03] hi [07:03] i'l leave that with him [07:04] heh [07:05] WIN. Yes. 87 is not in stable. [07:05] Hmm. [07:05] I wonder if my three merges that were based on devel are problematic. [07:05] except that devel has been merged since then. [07:05] And those three are a week old anyway. [07:06] jtv: Can you have another look at https://code.launchpad.net/~stevenk/launchpad/denorm-bspph-garbo/+merge/75118 ? [07:07] It's probably a criss-cross, but there's no warning about it, and shouldn't have been conflicts. [07:07] Oh. [07:07] There is a warning. [07:07] It's just drowned out by tonnes of other crap. [07:07] lifeless: Sorry, missed that. Fixing now. [07:07] I didn't think we could land db patches directly on devel atm? [07:07] stub: PQM only checks for -0 :) [07:07] What went wrong? [07:08] nigelb: A criss-cross merge. [07:08] We're going to be having a bit of that if buildbot keeps playing up. [07:09] if a criss cross of addition of one file is conflicting that seems like a bzr bug [07:09] possibly already filed [07:10] poolie: There was more than that, but the addition had me WTFing so I ignored the rest... and missed the criss-cross warning. [07:39] good morning [07:41] hi adeuring [07:41] hi jtv! [07:42] wgrant: mind if I throw Katie out of the house? She's a complete mess and she doesn't help us with _anything_. Plus, she's not tested that I can see. [07:42] I'm talking about the class; we can deal with the person later. [07:42] Or now—I don't particularly care either way, as long as we clean things up. [07:43] jtv: Indeed, gina's katie import support hasn't been used since 2006, and probably won't be again. [07:43] dak's schema has changed hugely anyway. [07:43] Delete. [07:43] It can't be again. We have no proof that it will even run, let alone work. [07:44] If we want her back, we'll have to rewrite her either way. [07:44] You still don't understand how Soyuz works. [07:44] We don't care about this proof or workingness business. [07:44] Run and see what blows up. [07:44] That's the Soyuz Way™ [07:45] I thought I was doing rather well on that with transitional domination, actually. [07:46] Heh [07:58] Hi [08:00] hi mrevell === StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jtv | Critical bugs: 261 - 0:[########*** stack smashing detected ***: ./lp terminated [08:09] * StevenK prods jtv more. [08:10] StevenK: what? [08:10] [17:06] < StevenK> jtv: Can you have another look at https://code.launchpad.net/~stevenk/launchpad/denorm-bspph-garbo/+merge/75118 ? [08:10] OK [08:11] StevenK: you kept the suspicious and apparently either unnecessary or incorrect handling of offset? [08:15] * mwhudson is tempted to implement a branchaccesstoken thing that allows access to a specific set of branches [08:15] (in my spare time) [08:15] anyone want to argue me out of it? [08:16] wgrant: ye commit hath landed. Blocked by qa-needstesting for stub & nigelb, but I guess it's too late for today anyway..? [08:16] mwhudson: this is an auth thing? [08:16] mwhudson: That would be handy. [08:16] jtv: yes [08:16] mwhudson: Do you know about the librarian's TimeLimitedTokens? [08:17] wgrant: i am aware of them, i guess would be the best thing to say [08:17] jtv: We can do a nodowntime today if you desire. [08:17] mwhudson: They provide a day of access to a specific restricted library file. Sort of similar to what you're suggesting. [08:18] mwhudson: Complications for branches are many, however. [08:18] mwhudson: We can't safely serve branches over HTTPS under their current domain, for one. [08:18] stub: busily q/a'ing garbo-frequently? [08:18] i have three use cases in mind (1) allowing the extermination of the branch puller (2) recipe builds for private branches (3) allowing other services (i.e. offspring) to access a particular private branch [08:18] wgrant: i was thinking of going over ssh [08:18] mwhudson: Ah, that works too. [08:18] jtv: spm is setting it up everywhere now [08:19] i guess i should write a spec, really [08:19] mwhudson: That is the approach I have always assumed we would take for private recipe builds. [08:19] mwhudson: And getting rid of the puller would also benefit from it. [08:19] stub: well. ish. I've started it; but can't complete today. have put it high in the XS queue [08:19] So, yes, good plan. [08:19] LEP it up! [08:19] stub: is that still Q/A we're talking about? [08:20] spm: Production could fall over, or at least the lpapis due to oauth nonces grinding to a halt. [08:20] spm: What is the blockage? [08:20] I EOD'd about 20 mins ago? :-) [08:20] and am busy writing an incident report [08:20] spm: Right, so need to hand it over then. [08:20] jtv: can you please review https://code.launchpad.net/~jml/launchpadlib/fake-launchpad/+merge/75211 [08:21] StevenK: http://tinyurl.com/6b2d6v6 - I'll try not to troll you any more :) [08:21] jtv: I will look at the offset thing tomorrow morning, then. [08:21] jml: OK—will go into standup soon, so may take a bit. [08:21] wgrant: in general, i'm thinking explicit revocation rather than time limiting [08:21] StevenK: any idea how it might affect performance? [08:21] jtv: no worries. [08:22] jtv: I'm not too concerned, to be honest. The query to find work to do is fairly lightweight, and the process is do the work is very lightweight as well. [08:23] StevenK: then you might as well just drop the offset. Nice & simple. [08:23] spm: I can also cobble something together for production if you push a fresh tree to wildcherry [08:24] jtv: Right, I'll switch to a boolean -- it will declare itself done when the find functions resultset .is_empty() [08:25] StevenK: great. Simpler means less to go wrong. [08:27] jtv: So I lied. The branch has pushed, and I'll ping you when the MP diff is updated. [08:27] StevenK: OK, but call first. [08:27] jtv: Sure, then have the stand-up and then another look at the MP -- it should be done by then [08:56] StevenK: you're done. [08:58] jtv: Thanks! [09:02] QA? [09:03] How do I QA that. [09:06] nigelb: the main thing is to make sure that it's safe to roll out. [09:07] I don't think it will topple over. But I have no idea how to verify that. [09:10] bigjools: Woah. That's a fun article. [09:15] wgrant: do you think https://dev.launchpad.net/LEP/BranchAccessToken misses anything vital? [09:18] mwhudson: What's Offspring? [09:18] nigelb: image building software [09:18] mwhudson: I like the stakeholders section. [09:19] nigelb: ah, my attempt at wiki syntax failed there [09:19] heh [09:19] mwhudson: The third story title seems wrong. [09:19] I did wonder if it was some sort of Launchpad codename :P [09:20] mwhudson: Looks pretty good, though! [09:20] wgrant, nigelb: both fixed i hope [09:20] mwhudson: Would be nice to have similar things for OAuth tokens, though. [09:20] Riddell, thanks for posting those build service comparisons [09:20] wgrant: i thought about oauth once [09:20] We probably want to think about other places we may want this before we go ahead and do stuff. [09:21] wgrant: i think i've recovered now [09:21] i know jml had looked at it before but actually using it in anger (or not) obviously gives much more depth [09:21] ie. I don't want all my API scripts to be able to upload to Ubuntu. [09:21] Heh. [09:21] mwhudson, being able to delete the puller, that'd be nice [09:21] mwhudson: Yep :) [09:21] wgrant: well OAuthToken does have a "context" concept, right? [09:21] mwhudson: Hee hee. [09:21] mwhudson: It's there. [09:21] mwhudson: And partially implemented. [09:22] i don't think anything sets or reads it though [09:22] But not working or enabled. [09:22] OAuth is PITA, but I'm not sure if there's something else that does its job. [09:23] Woah. There's a LEP for a Dashboard? Activity Walls? [09:23] wgrant: what things do you have in mind for oauth-y stuff? oauth is pretty http specific isn't it? [09:23] poolie: not to be taken as critisism of course :) [09:23] and I guess we _could_ enable branch access over http [09:23] but well [09:23] mwhudson: I don't meant doing this with OAuth. [09:24] mwhudson: I'd like restricted tokens for more than just branches. [09:24] ah right [09:24] Not as part of this, but we should probably at least think about it a bit. [09:24] So we don't go the wrong way. [09:25]