[00:03] <StevenK> wallyworld: http://penny-arcade.com/comic/2011/09/12
[00:04] <nigelb> ohai StevenK
[00:04] <nigelb> Could you point me to something that will help with javascript unit tests?
[00:05] <StevenK> No
[00:05] <StevenK> Since I have no idea myself
[00:05] <nigelb> excellent!
[00:05] <nigelb> I'll wait for wallyworld then.
[00:06] <nigelb> I made a whole lot of changes to untested code. Can't get away without writing tests anymore.
[00:09] <wallyworld> hi nigelb
[00:10] <nigelb> wallyworld: Hi! I did some major changes to +check-links and lp-links.js
[00:10] <wallyworld> nigelb: excellent. what changes?
[00:11] <nigelb> it pulls in the title and updates the dom with bug title
[00:11] <nigelb> so I had to change how the API is used to make my changes generic.
[00:11] <nigelb> https://code.launchpad.net/~nigelbabu/launchpad/bug-title-849121/+merge/75267
[00:11]  * wallyworld looks
[00:12] <nigelb> Actually, the example in the MP is slightly wrong. /me corrects.
[00:24] <nigelb> wallyworld: How does it look? I hope it doesn't make your eyes bleed :)
[00:25]  * wallyworld looks again
[00:26] <wallyworld> nigelb: the branch links value should be "invalid"
[00:26] <wallyworld> but it looks fine i think
[00:26] <wallyworld> it's a nice addition
[00:27] <nigelb> \o/
[00:28] <wallyworld> did you have a question you wanted to ask?
[00:28] <nigelb> err, is there documentation about javascript unit tests?
[00:28] <wallyworld> i didn't look at the code in detail, just the new output
[00:28] <wallyworld> https://dev.launchpad.net/JavascriptUnitTesting
[00:28] <wallyworld> that plus looking at what others have already done
[00:29] <nigelb> oooh. Awesomeness \o/
[00:29] <wallyworld> plus asking on here if you are stuck :-)
[00:29] <nigelb> :)
[00:30] <wallyworld> 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] <nigelb> wallyworld: sure! :-)
[00:31] <wallyworld> good luck with the tests :-) yui tests aren't too bad when you get used to them
[00:32] <nigelb> Hah. The last time I tried I was fairly homicidal :P
[01:08] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/missing-all-still/+merge/75286
[01:09] <wgrant> StevenK: jtv may have a branch to remove that import.
[01:09] <wgrant> StevenK: It was a temporary import of a private class, I believe.
[01:10] <StevenK> "temporary" -- it's been bugging me for two days
[01:36] <wgrant> lifeless: You have a 5 month old LP branch, changing the way INCOMPLETE is stored.
[01:36] <wgrant> lifeless: 'tis the oldest active review.
[02:08] <lifeless> wgrant: feel free to fix it and land it
[02:28] <rsalveti> 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] <wgrant> rsalveti: What sort of thing do you want to test? Much of it still requires sysadmin handholding at this stage.
[02:29] <rsalveti> wgrant: basically the idea is to start using this feature to guide the linaro-ubuntu development
[02:30] <rsalveti> I'm kind of the main user for this feature from the linaro side
[02:30] <rsalveti> 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] <wgrant> Right, bigjools is the one to talk to, but he's in the UK.
[02:31] <wgrant> I don't think (qa)staging have all the cron jobs set up.
[02:31] <wgrant> And we don't know if derived distros actually works yet.
[02:31] <wgrant> Ubuntu is using the native syncing features, but that's all that's actually known to work properly.
[02:31] <rsalveti> 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] <rsalveti> yeah, that's the main feature even for us
[02:31] <Ursinha> when I was doing exploratory testing, afair bigjools was running the cronjobs manually
[02:31] <rsalveti> and the idea is to start using it to see what is still missing
[02:32] <wgrant> rsalveti: Well, critically we don't even know if you can create a new usable distribution.
[02:32] <wgrant> I have my doubts over whether initialising it with packages actually yields a usable set of packages.
[02:32] <rsalveti> 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] <Ursinha> rsalveti, I think that you'd need superpowers to create a distro
[02:32] <wgrant> Right. We can try creating a test linaro distro on staging once spm is back, if we want.
[02:32] <Ursinha> wgrant, is the feature that alpha still?
[02:33] <rsalveti> cool, will move this conversation over email then
[02:33] <rsalveti> wgrant: thanks for your help anyway
[02:33] <Ursinha> rsalveti, spm should be back soon, I guess
[02:33] <wgrant> 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] <rsalveti> Ursinha: but I'll be gone soon :-)
[02:33] <wgrant> Ursinha: The syncing is tested.
[02:33] <wgrant> Ursinha: Everything else is not.
[02:33] <Ursinha> wgrant, hm, right
[02:34] <rsalveti> wgrant: cool, he's my main poc, so good to know he's the right guy for it :-)
[02:34] <Ursinha> so I believe rsalveti would do the testing :)
[02:34] <rsalveti> that's the idea
[02:34] <wgrant> The extent of the initialisation testing so far seems to have basically been "it doesn't crash, therefore it must be good"
[02:34] <Ursinha> haha
[02:34] <rsalveti> we can only test when there's someone really using it :-)
[02:35] <wgrant> We created the first production test last night.
[02:35] <wgrant> https://launchpad.net/bilimbitest/angry
[02:35] <Ursinha> hahaha
[02:35] <Ursinha> lol
[02:35] <rsalveti> cool
[02:38] <wgrant> We may be able to push the first builds through production tonight, if things go well.
[02:40] <wgrant> rsalveti: Does Linaro rebase on the latest Ubuntu release each time we release?
[02:40] <wgrant> rsalveti: Or does it merge like Ubuntu does from Debian?
[02:40] <rsalveti> wgrant: both
[02:40] <rsalveti> wgrant: we use the stable ubuntu release to do our main releases
[02:41] <rsalveti> but at the same time we're also working against the dev release, testing our packages and then pushing directly to ubuntu
[02:41] <rsalveti> but the main priority is to be on top of the latest stable release
[02:41] <rsalveti> like, we expect 11.09 to be our last natty based release
[02:41] <rsalveti> and do the first oneiric based one next month, together with the ubuntu release
[02:42] <wgrant> 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] <rsalveti> wgrant: currently we're just using a PPA
[02:42] <rsalveti> and that's why we wanted the derived distro so much, working with a PPA is quite annoying
[02:42] <wgrant> Right.
[02:42] <rsalveti> as we can't track upstream updates
[02:43] <rsalveti> and we can have bugs against packages
[02:43] <rsalveti> and so on
[02:43] <rsalveti> *can't
[02:43] <wgrant> Yep.
[02:44] <rsalveti> it's specially annoying when working against the dev release
[02:44] <wgrant> So, hopefully you can talk to Julian in your morning some time.
[02:44] <wgrant> 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] <rsalveti> yup, will try to ping him directly tomorrow morning
[02:51] <StevenK> wgrant: Can haz review? https://code.launchpad.net/~stevenk/launchpad/denorm-bspph-garbo/+merge/75118
[03:18] <jtv> StevenK: I guess I'll go to work on your branches then.  Sorry, old boy.
[03:24] <StevenK> jtv: I have a missing import branch -- which you can ignore if you're going to fix it.
[03:28] <jtv> StevenK: too late.
[04:30] <jtv> 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] <StevenK> 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] <jtv> 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] <jtv> 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] <StevenK> Oh, wgrant and sinzui are well aware of what I'm doing.
[04:51] <wgrant> A bug would be nice.
[04:51] <wgrant> Given this should be quick.
[04:51] <wgrant> It can sit around assigned to you for a few days.
[04:52] <jtv> It's easy to forget these things, and that's how you get… Soyuz.  :)
[04:52] <wgrant> jtv: NOW you're learning.
[04:52] <StevenK> Meh :-P
[04:52] <jtv> wgrant: technically, I've been drinking to forget Soyuz for months now.
[04:59] <kb9vqf> Quick question: the builddmaster/accepted and builddmaster/incoming directories seems to be full of files; can these be safely deleted?
[04:59] <kb9vqf> also wondering about the fatsam directory--what does it do and can it be cleaned up?
[05:01] <wgrant> kb9vqf: fatsam is the librarian's old name.
[05:01] <wgrant> kb9vqf: That's all the librarian data.
[05:01] <kb9vqf> ok
[05:01] <wgrant> kb9vqf: And I thought I answered your accepted/incoming question a month or so back :)
[05:01] <wgrant> kb9vqf: Incoming is the queue... stuff shouldn't be in there once process-upload.py runs.
[05:01] <wgrant> If there is, you're probably not running it properly.
[05:01] <wgrant> accepted you can dispose of.
[05:02] <kb9vqf> wgrant: You answered my question about poppy/incoming :)
[05:02] <kb9vqf> I was wondering about builddmaster/incoming
[05:02] <wgrant> kb9vqf: Ah.
[05:02] <wgrant> kb9vqf: Are you running process-upload.py over that dir?
[05:02] <wgrant> A year ago it was run automatically by buildd-manager, but that's no longer the case.
[05:02] <kb9vqf> the builddmaster directory?
[05:02] <wgrant> Yes.
[05:03] <kb9vqf> I don't think so
[05:03]  * kb9vqf goes to check
[05:04] <wgrant> Something like 'scripts/process-upload.py -C buildd --builds /srv/launchpad.net/builddmaster'
[05:04] <wgrant> The '-C buildd --builds' bit is important.
[05:04] <kb9vqf> As far as I can tell I am only running it over the poppy directory
[05:04] <kb9vqf> unless it is in a cron script somewhere
[05:05] <wgrant> It's a separate cron job now.
[05:05] <kb9vqf> and it is supposed to clean up the builddmaster directory?
[05:05] <wgrant> It will do that once it has processed the uploads.
[05:05] <wgrant> If it's not running, your builds aren't going to do much.
[05:05] <wgrant> They will just sit in the upload queue forever.
[05:05] <kb9vqf> everything is working OK so I think it is running
[05:05] <wgrant> What rev are you running?
[05:05]  * wgrant checks.
[05:05] <kb9vqf> an older rev
[05:05] <kb9vqf> probably a year or so earlier
[05:06] <wgrant> r10983
[05:06] <kb9vqf> ok
[05:06] <wgrant> June last year.
[05:06] <wgrant> So.
[05:06] <wgrant> That's before this change.
[05:06] <kb9vqf> ok
[05:07] <wgrant> That may explain why there's stuff left in incoming/. Is it mostly old?
[05:07] <kb9vqf> so it is safe to delete the builddmaster/incoming directory contents then?
[05:07]  * kb9vqf goes to check
[05:07] <kb9vqf> yes
[05:08] <wgrant> Kill them all.
[05:08] <kb9vqf> delete all the files?
[05:08] <kb9vqf> there are some new ones in there as well
[05:08] <kb9vqf> well, newer
[05:08]  * kb9vqf just wants to double check before hosing his system :)
[05:08] <wgrant> 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] <wgrant> buildd-manager ran process-upload automatically once each build completing, telling it to look only at that build.
[05:09] <kb9vqf> so everything in this directory already has a copy in librarian for the PPA?
[05:09] <wgrant> So it won't ever look at stuff from old builds.
[05:09] <wgrant> 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] <kb9vqf> I think I understand
[05:10] <kb9vqf> and deleting these files would not delete any published binaries or sources
[05:10] <wgrant> Right.
[05:10] <wgrant> That's just the intermediate queue between the buildds and the DB/librarian.
[05:10] <kb9vqf> I'm tempted to go on the safe side and only delete stuff that is a few days old or more
[05:10] <kb9vqf> ok, now I understand :)
[05:10] <wgrant> What sort of stuff is left that is new?
[05:11] <kb9vqf> .deb files
[05:11] <kb9vqf> .dsc files
[05:11] <wgrant> Hmm. Odd.
[05:11] <wgrant> https://dev.launchpad.net/Soyuz/TechnicalDetails is mostly brand new, and might be a helpful reference at times.
[05:11] <wgrant> It's still being written.
[05:11] <kb9vqf> basically the output of a builder
[05:11] <kb9vqf> ok
[05:12] <wgrant> lots of it from a developer's perspective, but may still be handy for your purposes.
[05:12] <kb9vqf> 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] <wgrant> Right.
[05:12] <wgrant> They're both handled by process-upload.
[05:12] <kb9vqf> and each queue's contents are eventually loaded into librarian?
[05:12] <kb9vqf> ok
[05:12] <kb9vqf> I feel much better about deleting those files :)
[05:12] <wgrant> But for buildd uploads, buildd-manager runs it automatically (well, not any more, but in your code)
[05:12] <wgrant> Once process-upload runs, those files are useless.
[05:13] <kb9vqf> right
[05:13] <kb9vqf> and since I've had the buildd manager die on me...
[05:13] <kb9vqf> it might explain the leftovers
[05:13] <wgrant> Yep.
[05:13] <kb9vqf> ok
[05:13] <kb9vqf> thanks for the help :)
[05:13] <wgrant> np
[05:36] <wgrant> StevenK: Are devel/db-devel jenkins builds meant to be disabled?
[06:15] <nigelb> Morning.
[06:16] <wgrant> Hi nigelb.
[06:16] <nigelb> Now I've fallen ill. Sigh.
[06:16] <wgrant> More LP time :P
[06:16] <nigelb> heh
[06:18] <nigelb> Hrm, devel has not yet been merged into db-devel.
[06:18] <nigelb> buildbot breakage still on-going?
[06:26] <StevenK> wgrant: Yes
[06:26] <StevenK> wgrant: Let me fix that
[06:27] <nigelb> wgrant: How did I end up asking the exact same question about a few minutes after you.
[06:27] <nigelb> Should. Get. Away. From Computer.
[06:27] <StevenK> wgrant: Fix0rated
[06:28] <wgrant> StevenK: Thanks.
[06:28] <wgrant> nigelb: buildbot should pass in <10min.
[06:28] <nigelb> \o/
[06:28] <StevenK> wgrant: It was disabled in case I was dealing with config
[06:29] <wgrant> Ahh.
[06:45] <wgrant> buildbot passed!
[06:45] <StevenK> OMG
[06:45] <wgrant> Both of them.
[06:45] <wgrant> Too late for fastdowntime tonight, though :(
[06:51] <StevenK> wgrant: Really?
[06:52] <nigelb> This is what happens when you conspire to steal FDT time :P
[06:52] <wgrant> StevenK: We need staging to update.
[06:52] <wgrant> nigelb: wallyworld stole my window :(
[06:52] <nigelb> bwahaha.
[06:52] <wgrant> An hour before he was meant to start for the day, too!
[06:52] <nigelb> haha
[06:52] <wgrant> So I start at 9am, thinking I'm going to get my patch in first.
[06:52] <wgrant> But find that his is already landed.
[06:52] <wgrant> Baaaah.
[06:53] <nigelb> :D
[06:53] <nigelb> I love it.
[06:54] <nigelb> Hrm. db-devel branch page timing out. Known?
[06:56] <wgrant> It will have just pushed.
[06:56] <wgrant> And will be scanning.
[06:56] <wgrant> Might time out for 30s or so.
[06:56] <nigelb> AH
[06:56] <wgrant> Yes, that sucks.
[06:56] <nigelb> haha
[06:56] <wgrant> But branchrevision is terrible.
[06:57] <nigelb> "udd importer should make tea while launchpad is down"
[06:57] <wgrant> Heh
[06:57] <nigelb> wgrant: I wish that and loggerhead started working better.
[06:57] <wgrant> Yeah.
[06:58] <StevenK> s/started \(work\)ing better/\1\ed/
[06:58] <StevenK> Doh, one extra \
[06:59] <nigelb> "I forgot to escape something. Wheeee[taptaptap]eeeeee"
[06:59] <wgrant> StevenK: You were dealing with rvba's confirmationoverlay?
[07:00] <wgrant> Also, your DB patch has somehow conflicted with db-devel.
[07:00] <StevenK> It has?
[07:00] <wgrant> This is a bit screwed.
[07:00] <StevenK> stub landed that
[07:00] <wgrant> Contents conflict in database/schema/patch-2208-87-2.sql
[07:00] <wgrant> Hmm.
[07:00] <StevenK> My patch should win, it's *applied*
[07:01] <wgrant> Yes.
[07:01] <wgrant> And there's no 87-2 in stable to conflict with it.
[07:01] <wgrant> But it still conflicted.
[07:01] <StevenK> And it wouldn't have landed with a conflict.
[07:01] <StevenK> So, WTF.
[07:01] <nigelb> How can you conflict with no file?
[07:02] <StevenK> Oh, database/schema/patch-2208-87-2.sql exists in db-devel
[07:02] <wgrant> Contents conflict often happens when the same file is added in two different branches.
[07:02] <wgrant> StevenK: Yes.
[07:02] <wgrant> But it's not in stable.
[07:02] <wgrant> AFAICT
[07:02] <lifeless> added twice rather than added + merged ?
[07:02] <StevenK> lifeless: Shoo
[07:02] <wgrant> If he's here, he could lend his bzr expertise to work out WTF is going on here :P
[07:03] <wgrant> 87-2 has never been in stable.
[07:03] <wgrant> So how on earth is it conflicting when being merged into db-devel.
[07:03] <lifeless> let me just suck down both branch tips
[07:03] <poolie> hi
[07:03] <poolie> i'l leave that with him
[07:04] <nigelb> heh
[07:05] <nigelb> WIN. Yes. 87 is not in stable.
[07:05] <wgrant> Hmm.
[07:05] <wgrant> I wonder if my three merges that were based on devel are problematic.
[07:05] <wgrant> except that devel has been merged since then.
[07:05] <wgrant> And those three are a week old anyway.
[07:06] <StevenK> jtv: Can you have another look at https://code.launchpad.net/~stevenk/launchpad/denorm-bspph-garbo/+merge/75118 ?
[07:07] <wgrant> It's probably a criss-cross, but there's no warning about it, and shouldn't have been conflicts.
[07:07] <wgrant> Oh.
[07:07] <wgrant> There is a warning.
[07:07] <wgrant> It's just drowned out by tonnes of other crap.
[07:07] <wgrant> lifeless: Sorry, missed that. Fixing now.
[07:07] <stub> I didn't think we could land db patches directly on devel atm?
[07:07] <wgrant> stub: PQM only checks for -0 :)
[07:07] <nigelb> What went wrong?
[07:08] <wgrant> nigelb: A criss-cross merge.
[07:08] <wgrant> We're going to be having a bit of that if buildbot keeps playing up.
[07:09] <poolie> if a criss cross of addition of one file is conflicting that seems like a bzr bug
[07:09] <poolie> possibly already filed
[07:10] <wgrant> 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] <adeuring> good morning
[07:41] <jtv> hi adeuring
[07:41] <adeuring> hi jtv!
[07:42] <jtv> 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] <jtv> I'm talking about the class; we can deal with the person later.
[07:42] <jtv> Or now—I don't particularly care either way, as long as we clean things up.
[07:43] <wgrant> jtv: Indeed, gina's katie import support hasn't been used since 2006, and probably won't be again.
[07:43] <wgrant> dak's schema has changed hugely anyway.
[07:43] <wgrant> Delete.
[07:43] <jtv> It can't be again.  We have no proof that it will even run, let alone work.
[07:44] <jtv> If we want her back, we'll have to rewrite her either way.
[07:44] <wgrant> You still don't understand how Soyuz works.
[07:44] <wgrant> We don't care about this proof or workingness business.
[07:44] <wgrant> Run and see what blows up.
[07:44] <wgrant> That's the Soyuz Way™
[07:45] <jtv> I thought I was doing rather well on that with transitional domination, actually.
[07:46] <wgrant> Heh
[07:58] <mrevell> Hi
[08:00] <jtv> hi mrevell
[08:09]  * StevenK prods jtv more.
[08:10] <jtv> StevenK: what?
[08:10] <StevenK> [17:06] < StevenK> jtv: Can you have another look at https://code.launchpad.net/~stevenk/launchpad/denorm-bspph-garbo/+merge/75118 ?
[08:10] <jtv> OK
[08:11] <jtv> 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] <mwhudson> (in my spare time)
[08:15] <mwhudson> anyone want to argue me out of it?
[08:16] <jtv> wgrant: ye commit hath landed.  Blocked by qa-needstesting for stub & nigelb, but I guess it's too late for today anyway..?
[08:16] <jtv> mwhudson: this is an auth thing?
[08:16] <wgrant> mwhudson: That would be handy.
[08:16] <mwhudson> jtv: yes
[08:16] <wgrant> mwhudson: Do you know about the librarian's TimeLimitedTokens?
[08:17] <mwhudson> wgrant: i am aware of them, i guess would be the best thing to say
[08:17] <wgrant> jtv: We can do a nodowntime today if you desire.
[08:17] <wgrant> mwhudson: They provide a day of access to a specific restricted library file. Sort of similar to what you're suggesting.
[08:18] <wgrant> mwhudson: Complications for branches are many, however.
[08:18] <wgrant> mwhudson: We can't safely serve branches over HTTPS under their current domain, for one.
[08:18] <jtv> stub: busily q/a'ing garbo-frequently?
[08:18] <mwhudson> 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] <mwhudson> wgrant: i was thinking of going over ssh
[08:18] <wgrant> mwhudson: Ah, that works too.
[08:18] <stub> jtv: spm is setting it up everywhere now
[08:19] <mwhudson> i guess i should write a spec, really
[08:19] <wgrant> mwhudson: That is the approach I have always assumed we would take for private recipe builds.
[08:19] <wgrant> mwhudson: And getting rid of the puller would also benefit from it.
[08:19] <spm> stub: well. ish. I've started it; but can't complete today. have put it high in the XS queue
[08:19] <wgrant> So, yes, good plan.
[08:19] <wgrant> LEP it up!
[08:19] <jtv> stub: is that still Q/A we're talking about?
[08:20] <stub> spm: Production could fall over, or at least the lpapis due to oauth nonces grinding to a halt.
[08:20] <stub> spm: What is the blockage?
[08:20] <spm> I EOD'd about 20 mins ago? :-)
[08:20] <spm> and am busy writing an incident report
[08:20] <stub> spm: Right, so need to hand it over then.
[08:20] <jml> jtv: can you please review https://code.launchpad.net/~jml/launchpadlib/fake-launchpad/+merge/75211
[08:21] <bigjools> StevenK: http://tinyurl.com/6b2d6v6 - I'll try not to troll you any more :)
[08:21] <StevenK> jtv: I will look at the offset thing tomorrow morning, then.
[08:21] <jtv> jml: OK—will go into standup soon, so may take a bit.
[08:21] <mwhudson> wgrant: in general, i'm thinking explicit revocation rather than time limiting
[08:21] <jtv> StevenK: any idea how it might affect performance?
[08:21] <jml> jtv: no worries.
[08:22] <StevenK> 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] <jtv> StevenK: then you might as well just drop the offset.  Nice & simple.
[08:23] <stub> spm: I can also cobble something together for production if you push a fresh tree to wildcherry
[08:24] <StevenK> jtv: Right, I'll switch to a boolean -- it will declare itself done when the find functions resultset .is_empty()
[08:25] <jtv> StevenK: great.  Simpler means less to go wrong.
[08:27] <StevenK> jtv: So I lied. The branch has pushed, and I'll ping you when the MP diff is updated.
[08:27] <jtv> StevenK: OK, but call first.
[08:27] <StevenK> jtv: Sure, then have the stand-up and then another look at the MP -- it should be done by then
[08:56] <jtv> StevenK: you're done.
[08:58] <StevenK> jtv: Thanks!
[09:02] <nigelb> QA?
[09:03] <nigelb> How do I QA that.
[09:06] <jtv> nigelb: the main thing is to make sure that it's safe to roll out.
[09:07] <nigelb> I don't think it will topple over. But I have no idea how to verify that.
[09:10] <nigelb> bigjools: Woah. That's a fun article.
[09:15] <mwhudson> wgrant: do you think https://dev.launchpad.net/LEP/BranchAccessToken misses anything vital?
[09:18] <nigelb> mwhudson: What's Offspring?
[09:18] <mwhudson> nigelb: image building software
[09:18] <wgrant> mwhudson: I like the stakeholders section.
[09:19] <mwhudson> nigelb: ah, my attempt at wiki syntax failed there
[09:19] <nigelb> heh
[09:19] <wgrant> mwhudson: The third story title seems wrong.
[09:19] <nigelb> I did wonder if it was some sort of Launchpad codename :P
[09:20] <wgrant> mwhudson: Looks pretty good, though!
[09:20] <mwhudson> wgrant, nigelb: both fixed i hope
[09:20] <wgrant> mwhudson: Would be nice to have similar things for OAuth tokens, though.
[09:20] <poolie> Riddell, thanks for posting those build service comparisons
[09:20] <mwhudson> wgrant: i thought about oauth once
[09:20] <wgrant> We probably want to think about other places we may want this before we go ahead and do stuff.
[09:21] <mwhudson> wgrant: i think i've recovered now
[09:21] <poolie> i know jml had looked at it before but actually using it in anger (or not) obviously gives much more depth
[09:21] <wgrant> ie. I don't want all my API scripts to be able to upload to Ubuntu.
[09:21] <wgrant> Heh.
[09:21] <jelmer_> mwhudson, being able to delete the puller, that'd be nice
[09:21] <nigelb> mwhudson: Yep :)
[09:21] <mwhudson> wgrant: well OAuthToken does have a "context" concept, right?
[09:21] <wgrant> mwhudson: Hee hee.
[09:21] <wgrant> mwhudson: It's there.
[09:21] <wgrant> mwhudson: And partially implemented.
[09:22] <mwhudson> i don't think anything sets or reads it though
[09:22] <wgrant> But not working or enabled.
[09:22] <nigelb> OAuth is PITA, but I'm not sure if there's something else that does its job.
[09:23] <nigelb> Woah. There's a LEP for a Dashboard? Activity Walls?
[09:23] <mwhudson> wgrant: what things do you have in mind for oauth-y stuff?  oauth is pretty http specific isn't it?
[09:23] <Riddell> poolie: not to be taken as critisism of course :)
[09:23] <mwhudson> and I guess we _could_ enable branch access over http
[09:23] <mwhudson> but well
[09:23] <wgrant> mwhudson: I don't meant doing this with OAuth.
[09:24] <wgrant> mwhudson: I'd like restricted tokens for more than just branches.
[09:24] <mwhudson> ah right
[09:24] <wgrant> Not as part of this, but we should probably at least think about it a bit.
[09:24] <wgrant> So we don't go the wrong way.
[09:25] <mwhudson> i guess the another similar thing is p3as?
[09:25] <wgrant> Indeed, that is not dissimilar.
[09:25] <wgrant> Each token has access to exactly one archive.
[09:27] <mwhudson> what else?  i think anything involving the browser is a bit different somehow
[09:27] <mwhudson> (e.g. allowing someone to see a particular bug, or branch)
[09:35] <wgrant> Not much at the moment.
[09:35] <wgrant> But I want to be able to write an Ubuntu bug robot and give it a token that allows it to write to bugs, but not root everyone's systems.
[09:35] <wgrant> For example.
[09:36] <mwhudson> yeah
[09:36] <mwhudson> however
[09:36] <mwhudson> i don't want to invent a schema that can describe both "all bugs on a particular distribution" and "a finite set of branches"
[09:37] <wgrant> Certainly.
[09:37] <mwhudson> that's not so much a rabbit hole as an open cast mine
[09:38]  * mwhudson looks at translatePath, dies a little inside
[09:40] <wgrant> Yeah, I thought you'd know not go to look at it without protection.
[09:41] <mwhudson> one forgets things
[09:42] <mwhudson> trying to do this by creating a new kind of principal is insane, right?
[09:42] <wgrant> I expect that would be somewhat insane.
[09:47] <mwhudson> yeah
[09:49] <mwhudson> jelmer_: yes indeed
[09:49] <mwhudson> jelmer_: it's tests too :)
[09:55] <mwhudson> wow 'make' seems to be taking a preposterously long time
[09:56] <nigelb> "seems"?
[09:56] <mwhudson> ok, is
[09:56] <nigelb> make run?
[09:56] <mwhudson> just 'make'
[09:56] <mwhudson> it's creating wadl now
[09:57] <nigelb> Everytime I touch javascript, I cringe about the amount of time make is going to take.
[09:58] <nigelb> wgrant had a nice hack for the that, which I keep forgetting :(
[09:59] <wgrant> make jsbuild
[10:03] <lifeless> mwhudson: how is a branch access token different to an ssh key?
[10:14] <nigelb> Hrm. My YUI test HTML doens't have styling.
[10:16] <mwhudson> lifeless: it doesn't correspond to a Perosn
[10:27] <jml> jtv: I guess you didn't get around to that review?
[10:28] <jtv> jml: you just tore me away from it.  :)
[10:28] <jml> jtv: oh, ok, thanks.
[10:28] <nigelb> The css for javascript test is not getting loaded. Debugged for 20 minutes and still no clue. Anyone has suggestions?
[10:29] <nigelb> Well, it is loaded. But some of it is not getting used.
[10:33] <nigelb> aaaaaah.
[10:33] <nigelb> the wiki is wrong.
[10:33] <nigelb> <-- *headdesk*
[11:08] <lifeless> mwhudson: I think we should talk about what problem you are addressing - as it stands, it has me a little worried about complexity, protocols, compatibility, auditing and security.
[11:51] <jtv> jml: it was too much for one go, I'm afraid.  Posted notes for all but the tests; more tomorrow.
[11:55] <jml> :(
[11:55] <jml> jtv-afk: thanks.
[12:09] <jml> jkakar: jtv has asked some questions in his review that maybe you'd be better placed to answer: https://code.launchpad.net/~jml/launchpadlib/fake-launchpad/+merge/75211
[12:16] <nigelb> jml: Wow. 5000 line diff.  o_O
[12:16] <jml> nigelb: not really.
[12:17] <nigelb> 40,425.
[12:17] <nigelb> Oh.
[12:17]  * nigelb bows.
[13:03] <jml> nigelb: it's mostly changing data files
[13:05] <nigelb> jml: Ahh.
[13:30] <deryck> henninge, ping for standup
[13:38] <henninge> deryck: oh, sorry
[13:38] <deryck> henninge, we're just finishing up, if you don't want to join
[14:22] <jml> gmb: can I convince you to take a look at that branch again? jtv has reviewed all but the tests.
[14:25] <gmb> jml: I've already scheduled some time for it this afternoon.
[14:29] <jml> gmb: thanks.
[14:48] <jkakar> jml: I think you did a great job answering jtv-afk's awesome review comments.  Thanks! :)
[14:50] <jml> jkakar: thanks.
[14:51] <jml> jkakar: I've been learning about wadl on the way.
[15:54] <adeuring> abentley: could you please review this MP: https://code.launchpad.net/~adeuring/launchpad/bug-739052-8/+merge/75372 ?
[15:54] <abentley> adeuring: sure.
[15:54] <adeuring> thanks!
[16:01] <abentley> adeuring: I'd be inclined to move most of the body of rough_length into a generic function, but perhaps you feel it's too early for that?
[16:02] <adeuring> abentley: I thought about that too. But to be honest: I simply want to fix the main bug. Working on it took already too long ;)
[16:02] <abentley> adeuring: Fine with me.  r=me.
[16:02] <adeuring> abentley: great, thanks!
[16:03] <gmb> jml: r=me on the tests; I'll leave jtv-afk to reply to your response to his comments. A couple more copyright notices that need updating, too (is there a template that needs changing somewhere?)
[16:05] <jml> gmb: I don't know re template. As I might not have said, I'm just updating an old branch. :)
[16:05] <gmb> jml: You may have, and I've probably missed it. Fair dos.
[17:10] <nigelb> abentley: Hi! Could you land a branch for me into db-devel?
[17:11] <abentley> nigelb: sorry, give me a couple minutes.
[17:11] <nigelb> Cool :)
[17:12] <abentley> nigelb: which branch?
[17:12] <nigelb> abentley: https://code.launchpad.net/~nigelbabu/launchpad/kill-statusexplanation/+merge/74934
[17:13] <nigelb> The last time I missed a few places the field was being used.  Fixed it in devel and merged it down.
[17:18] <abentley> nigelb: Okay, let me just snag a copy here...
[17:24] <abentley> nigelb: landed.
[17:24] <nigelb> abentley: Thanks!
[17:28] <dobey> hrmm
[17:29] <dobey> https://lp-oops.canonical.com/?oopsid=OOPS-2083J68
[17:29] <dobey> that does not look fun :(
[17:44] <dobey> can someone tell me what that means ^^?
[17:46] <dobey> ShortListTooBigError: Hard limit of 1000 exceeded.
[18:09] <salgado> dobey, I think it means someone expected a DB query wouldn't return more than 1000 items, but it did
[18:11] <dobey> hmm. how can i work around this and let my bot request builds of that recipe?
[18:12] <cjwatson> wgrant: fixed apt is on mawson now, if you'd care to try it ouot?
[18:12] <cjwatson> *out
[18:15] <sinzui> jcsackett, do you have time to mumble?
[18:15] <jcsackett> sinzui: sure.
[18:19] <jcsackett> sinzui: http://people.canonical.com/~curtis/target-picker/target-picker-3.html
[18:39] <nigelb> Hi, could someone help me with mockio?
[18:39] <nigelb> var mock_io = Y.lp.testing.mockio.MockIo();
[18:39] <nigelb> The mock_io variable is undefined for me.
[18:39] <nigelb> Included the mockio.js, declared it in YUI.use as well.
[18:46] <nigelb> Ah. Again, wrong example. *fixes*
[18:55] <nigelb> I made changes to mockio page and javascript unit testing page.
[18:55] <nigelb> https://dev.launchpad.net/JavascriptUnitTesting/MockIo?action=diff&rev2=7&rev1=6 https://dev.launchpad.net/JavascriptUnitTesting?action=diff
[18:55] <nigelb> If anyone wants to check
[19:53] <abentley> nigelb: thanks for the fix.  Darn JS.
[22:17] <mwhudson> well this was unexpected
[22:17]  * mwhudson has implemented anonymous access to public branches over ssh
[22:22] <james_w> the question is...what were you aiming to do? :-)
[22:22] <mwhudson> james_w: well, i was thinking about https://dev.launchpad.net/LEP/BranchAccessToken
[22:23] <cody-somerville> mwhudson, how do you do anonymous access to public branches over ssh?
[22:23] <mwhudson> cody-somerville: fiddling with how the ssh server does authentication
[22:24] <cody-somerville> is the benefit the ability to use the smart server to make things faster vs. over http(s)?
[22:24] <mwhudson> yeah
[22:31] <maxb> Anonymous ssh sounds weird, but there's a fairly large precedent for it in the BSD world as an anoncvs transport, IIUC
[23:03] <mwhudson> yeahhttps://code.launchpad.net/~mwhudson/launchpad/anon-ssh-hack/+merge/75442
[23:03] <mwhudson> oops
[23:03] <mwhudson> https://code.launchpad.net/~mwhudson/launchpad/anon-ssh-hack/+merge/75442
[23:12] <StevenK> G: You have QA, r13938, bug 763820
[23:12] <_mup_> Bug #763820: double "with" on +editpgpkeys <qa-needstesting> <trivial> <ui> <Launchpad itself:Fix Committed by dev-nigelj> < https://launchpad.net/bugs/763820 >
[23:19] <StevenK> nigelb: You have QA as well! r13932, bug 88545
[23:19] <_mup_> Bug #88545: Abolish the "statusexplanation" database field <lp-bugs> <qa-needstesting> <tech-debt> <Launchpad itself:In Progress by nigelbabu> < https://launchpad.net/bugs/88545 >
[23:27] <G> StevenK: thanks for the reminder :)
[23:30] <G> mwhudson: if you ask me, I think it's genius :)
[23:30] <mwhudson> G: heh, thanks
[23:30] <G> I see another use for it too...
[23:31] <mwhudson> G: whereabouts in nz are you btw?
[23:31] <G> If at first you don't succeed, try, try again (as anonymous)   i.e. if a "bzr branch" or pull fails because of missing public key, give it a go as anonymous because there is a good chance there may be read-only access
[23:32] <G> errr missing private key that should be
[23:32] <G> mwhudson: West Auckland (I'm a JAFA)
[23:32] <mwhudson> ah right
[23:32]  * mwhudson is in wellington
[23:32] <mwhudson> (but a brit)
[23:33] <G> StevenK: done
[23:33] <StevenK> G: Thanks!
[23:34] <G> my logic is... if I say login to my VM, and do a rocketfuel-get or something and forget to invoke the SSH Agent, because the launchpad repo is world-readable, it'd fall back on the anonymous user, and still work
[23:34] <wgrant> nigelb: That shouldn't have been landed yet :(
[23:35] <wgrant> nigelb: The prereq is not deployed to anywhere yet, and because it affects oops-prune it needs to be deployed absolutely everywhere.
[23:35] <G> to me, something like would be a great idea as far as usability
[23:36] <G> (I'll let others come up w/ reasons why I'm insane for thinking that ;))