[01:09] * thumper twiddles his thumbs while the tests run [01:09] thumper: do you twiddle clockwise or anti? or switch from one t'other? enquiring minds wish to know. [01:09] spm: I alternate [01:10] like current, but not as fast [01:10] * spm looks for a report on the intrawebsfont-of-all-knowledge as to what that says about thumpers mental state of being [01:10] sadly, reckon I could google for that and get a semi-credible answer.... :-) [01:15] spm: an answer yes, a semi-credible one? now that is a question all in itself [01:15] ha [01:25] * mwhudson lunches [01:56] * thumper is having test failures with GpgmeError: (32, 176, 'Unknown error code') [02:07] thumper: There is a patch needed for Lucid. [02:08] :( [02:08] I think it's in trunk now. [02:08] pygpgme trunk, that is. [02:08] is it in LP code somewhere? [02:08] I'm running the tests through ec2 now anyway [02:09] mwhudson actually approved the sourcedeps.conf change a few days ago. [02:09] It just hasn't been landed yet. [02:10] ok [02:10] I thought I had seen something about pygpgme fly past [02:11] bad jelmer [03:06] wgrant: re bug 549323, i did try to tell them so [03:06] Bug #549323: Discourages bug fixes [03:23] * thumper has finally started writing the tests for iterReady [03:30] wgrant: ugh, is this deliberate or a bug ? [04:02] mwhudson: happy with bug 532210? [04:03] thumper: yes [04:03] didn't i change the tag already? [04:03] no [04:03] not yet [04:04] ok [04:04] now i have :) [04:04] ta [04:15] mwhudson: do we have a reasonable branch to test https://bugs.edge.launchpad.net/launchpad-code/+bug/532402 on? [04:15] Bug #532402: record last_revision used to determine partial success before doing import

[04:19] thumper: not really [04:20] mwhudson: I suppose we should just test the imports on staging and see that they work still [04:20] thumper: i can think of some slightly contrived ways to test it by getting a losa to SIGSTOP the import processs [04:20] thumper: yeah [04:20] thumper: doing that already in fact :) [04:20] if only there was a friendly losa around.... [04:20] cool [04:20] spm: yeah, know any? [04:20] thumper: https://code.staging.launchpad.net/~vcs-imports/gedit/head [04:21] thumper: not on the key criteria no. losa's around? yup. friendly? no. [04:21] it's also a fiddle, the only public svn repo i can think of is codespeak, and bzr-svn tends to break on that [04:21] (thanks to svn bugs) [04:29] mwhudson: that subversion import is via cscvs, you knew that right? [04:29] * thumper afk for a bit [04:36] thumper: ah balls [04:36] thumper: thanks [05:38] * mwhudson stops [06:56] lifeless: Is which deliberate? [06:56] poolie: I decided not to. I've almost given up trying to convince people nicely. [06:56] wgrant: bug 549323 [06:56] Bug #549323: confirmation dialog on bug status change discourages bug fixes [06:56] lifeless: It's quite deliberate. [06:56] If you're not a bug supervisor, you're not meant to change the status. [06:57] lifeless: read the other bug linked from it [06:57] wgrant :-( [06:57] wgrant: if we're doing that, we should delete 'in progress' [06:57] ? [06:58] poolie: so that there is no bug state that contributors who aren't bug supervisors need to set the bug to [06:58] oh i don't know [06:58] I think 'assignee' is sufficient to indicate in progress [06:58] confirmed|triaged + assigned [06:58] i see [06:58] this is a different issue [06:59] fwiw i think you can say "some work has been done on this but nobody owns it at the moment" [06:59] however [06:59] the point here is not that people cannot set the state [06:59] just an attempt to reduce erroneous settings [06:59] and a confirmation dialog is a very poor way to accomplish that [07:00] poolie: arguably though, it won't progress when noone owns it. [07:00] poolie: yes, I can see the dialog being a poor way issue [07:00] right, i don't think you should leave bugs in this state for long [07:00] but they can be there [07:00] it's like saying you shouldn't be allowed to have open critical unassigned bugs :) [07:01] true [07:01] I think it depends on what you take 'in progress' to mean. [07:01] if you mean 'started but not finished', then I agree that it can be in that state. [07:01] An alert() which users cannot bypass is a *particularly* poor way to accomplish it. [07:01] if you mean 'being worked on', then I don't agree. [07:02] And I think most users take 'in progress' to mean 'progressing' not 'started but not finished' [07:05] i don't think "actually being worked on now" is modelled very well by a single field on the task [07:05] it will be out of date [07:06] agreed [07:09] wgrant: is it really 'bug supervisor' not, as promised in bug 531963, 'bug contributor'? [07:09] Bug #531963: Add a confirmation step when setting the bug status if the user is not a bug contributor [07:10] poolie: 'bug contributor' doesn't exist, except by karma. [07:10] poolie: The review I snooped at checked for importance privileges. [07:10] * wgrant checks the source. [07:12] + 'status_requires_confirmation': not self.user_can_edit_importance, [07:12] poolie: ^^ [07:13] ok, thanks [07:13] so there is no escape [07:14] perhaps it would be better if it was more sophisticated than that [07:14] Apart from Greasemonkey. [07:14] \o/ [07:14] lifeless: Indeed. [07:49] good morning [07:53] noodles775: Morning. [07:57] Hi wgrant and adeuring :) [07:57] hi noodles775! [07:57] Hi adeuring. [07:57] hi wgrant! [07:58] noodles775: Since LP won't have emailed anybody, again, have a https://bugs.edge.launchpad.net/soyuz/+bug/550233. Also https://bugs.edge.launchpad.net/soyuz/+bug/550049, but I've already poked Julian about that. [07:58] * noodles775 looks [08:09] wgrant: urk, now i get that dialog about bzr in ubuntu [08:09] poolie: Ha ha ha. [08:09] Give them hell. [08:12] * wgrant heads trainward. [09:08] * thumper is having trouble stopping [09:10] thumper: Me too [09:10] thumper: switch to your other project [09:11] his wife? [09:11] lifeless: congrats BTW [09:11] bigjools: thanks :) [09:12] lifeless: is this a hacking honeymoon? :) [09:12] bigjools: honeymoon will be later this year [09:12] waaay to much on right now to do it atm [09:37] Morning [09:50] Hi all ! I'd like to install Launchpad on a Ubuntu box, but I wonder how hard it would be to make it scalable [09:54] fayce: launchpad itself - depends on what you mean by scalable [09:56] thank you lifeless, I meant by "scalable" the fact that I can load balance it trough different physical (or virtual) servers without too much work [09:57] I guess that launchpad is designed that way... kind of stateless ? [09:57] its not stateless [09:57] but the state lives in a db [09:57] bigjools: What in IBuildFarmJob says that it is a DB object? [09:59] (I don't know how it manages to not live in the DB; that is Code magic.) [10:00] ok, thanx. I'm about to get the source code and try to install it. [10:00] hello all [10:00] Morning jml. [10:08] wgrant: I don't understand your first comment, but the second one is exactly what bothers me [10:08] I don't want magic [10:08] bigjools: By calling Store.remove(some IBuildFarmJob), we are violating IBuildFarmJob. [10:08] how? [10:09] Nothing in the interface says that it can be removed from a store. [10:09] it's no different to destroySelf, except I don't want any more of the latter [10:09] IBuildFarmJob should have a concrete table behind it somewhere [10:09] IBFJ now defines destroySelf. verifyObject will correctly catch if something is missing it. [10:09] that's my point [10:09] It should. [10:10] And we should really work out a solution to that, true. [10:10] right - so I prefer that to hacking something in [10:11] create an IStorm interface and attach it to storm.base.Storm objects with ZCML. [10:12] stub: I thought we couldn't do that. [10:12] why not? [10:14] You could also adapt the object to IMasterObject, which would give you a Storm object or fail. [10:14] Didn't I see a comment suggesting that the I*Store adapters registered on Interface because you can't tell Zope that a class and all its derivatives implement an interface. [10:14] ? [10:15] maybe. I don't recall. [10:15] lib/canonical/launchpad/webapp/adapter.py, just before get_store. [10:16] Oh... that is classes. [10:16] We adapt classes to I*Store, which is the problem. This would be adapting instances which is fine. Just declare Storm implements IStorm and all Storm instances will provide that interface. [10:17] Oh, right. [10:17] That makes more sense ow. [10:17] But if a class provides an interface, subclasses don't automatically provide it too. [10:17] (Which I think is a bug? Not sure, but it isn't going to be fixed any time soon if it is) [10:21] sounds like a bug to me [10:21] wgrant: anyway as I said on the bug I'm of a mind to mark it invalid [10:21] bigjools: Well, when is the data model rework going to happen? [10:21] wgrant: noodles775 is working on it right now [10:21] Excellent. [10:21] we need it for builder history [10:22] and jtv needs to fix his stuff too :) [10:22] Yep. [10:22] But with that and my other Saturday fixes, translations jobs work perfectly. [10:22] wgrant, bigjools: *was* going to start working on it today, but other things came up ;) [10:22] :) [10:22] have you ever been to a blackhat wgrant? :) [10:23] bigjools: No. [10:23] anyway, UI should drive all other features, not the other way around. jml would agree with me. [10:23] +inf [10:23] heh [10:24] bigjools: I would say user experience, not ui [10:24] I think its closer to the spirit of the issue [10:24] amounts to the same thing for me, but yeah [11:00] Morning, all. === deryck changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 4 of 10.03 | PQM is in RC mode | Release manager: deryck | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in irc://irc.freenode.net/#launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | [11:09] deryck: Hi. Can I please have your blessing for https://code.edge.launchpad.net/~wgrant/launchpad/bug-540819-fix-builder-list-icons/+merge/22288? [11:09] Hi wgrant. Let me take a look.... [11:12] wgrant, can you get the normal reviews from someone else first please? Then I'll consider it for an RC. But my initial reaction is I have no qualms about this going in. [11:13] I think we will also have someone from bugs back out the confirmation dialog for status change, until it has been correctly done. [11:14] deryck: Ah, OK. [11:14] deryck: +1 from me on backing out the confirmation dialog, clearly... [12:22] Has meliae become a new dependency, but not been added to buildout or -dependencies? === fayce_ is now known as fayce [12:27] Ahh... forgot to rebuild my eggs. === Ursinha-afk is now known as Ursinha === matsubara-afk is now known as matsubara === flacoste_afk is now known as flacoste [14:29] gror backlight [15:34] hey salgado are you CHR today? [15:35] I should be but had completely forgotten about it [15:35] thanks for reminding me, bac [15:35] salgado: there are some questions in #launchpad [16:06] am I right that we now need a referer header for each POST request? [16:06] adeuring: right [16:07] leonardr: gah... I can't use firefox to edit any LP page... [16:07] mwhudson, if you're around i have a question about http://www.mail-archive.com/launchpad-dev@lists.launchpad.net/msg02999.html [16:07] but the important detail: [16:07] We don't get any longer new submissions to the HDWB [16:08] since when do we have this referer check? [16:10] adeuring: a couple weeks ago. it was a security measure [16:10] leonardr: sure, I understand that. Is it possible to switch this off for selected forms? === matsubara is now known as matsubara-lunch [16:11] adeuring: yes, i'm finding the information for you now [16:11] adeuring: the bug is https://bugs.edge.launchpad.net/launchpad-foundations/+bug/529348 [16:11] leonardr: thanks! [16:12] np [16:33] gary_poster: I just got a head-up from cr3 and jcastro that LP does not accept any longer ay HWDB submission. The reason is simple: The data is posted by checkbox, and the request does not contain a referer header. Can you give me a clue how to best fix this? [16:34] there is this exemption for "/+storeblob" and a few other URLs, should we extend that? [16:35] adeuring: yes, I suppose so, with associated tests, and quite possibly with an associated bug or two against the webservice saying that whatever the HWDB is doing now should be doable with the webservice, at which point we can remove the exceptions. [16:36] adeuring: what do you mean "The data is posted by checkbox"? [16:36] gary_poster: the program that collects the data on a user's machine is called checkbox. [16:37] ah, ok [16:37] and it seems to POST without a referer [16:37] I thought it was a form element :-) [16:37] gary_poster: ;) === salgado is now known as salgado-lunch [16:39] adeuring: so...actually, I also suggest that they change their script now to include a REFERER. That way eventually legacy clients will "just work," and sooner than if they wait to be able to do whatever it is they need to do through the webservice API [16:40] gary_poster: yes, checkbox should do that. But it is installed by default on every Ubuntu system, and getting rid of old version will ned quite some time... [16:41] adeuring: ack, so let's get started ;-) getting the change into lucid would be a *big* win in that regard [16:41] right === deryck is now known as deryck[lunch] === matsubara-lunch is now known as matsubara === Ursinha is now known as Ursinha-lunch === salgado-lunch is now known as salgado === beuno is now known as beuno-lunch === deryck[lunch] is now known as deryck [18:29] sinzui, ping [18:35] hi deryck [18:37] sinzui, hi. should Bug #550980 be a registry bug instead of malone? (I realize anyone can fix it, just curious who normally owns that script.) [18:37] Bug #550980: Ordering of Bug importance is wrong [18:37] * deryck fixes the title [18:38] It is a registry bug [18:38] It is also browser based. webkit shows things very wrong. firefox is kind of right [18:39] ah, ok. I'll retarget to you guys then. [18:40] already done [18:40] and there's our friend the NotImplementedError. :-) You did beat me [18:41] jml, james_w: I'd really rather leonardr and I not consider the adapter question until we've dealt with other things on our schedule, and I'd really rather decisions assuming a given solution (which is what I--perhaps mistakenly--understand the current resolution of your mail thread) to be postponed. I understand that you want changes, but pushing for too much at once will lead to flailing, I'm afraid. [18:43] ah, disappointments: the local paneras no longer allows ssh connections apparently :-/ [18:45] leonardr: my concern expressed about the adapter thread (and the original question about exposing newCodeImport), if you do have any quick wisdom or ideas to share with james_w and jml, please do. [18:52] deryck: That bug was a duplicate of a foundations bug. I also found the same bug reported in malone. I duped them so that it was clear that there is one universal webkit js problem in launchpad [18:52] sinzui, excellent, thanks! === beuno-lunch is now known as beuno [19:09] gary, looking === matsubara is now known as matsubara-afk [19:46] gary_poster: I don't think I'm rushing ahead, I'm just responding to the only replies I have had on the topic. If you want to defer exposing anything that uses adapters until there is a general solution in place then please tell me and I shall go work on something else. [19:54] james_w: fair enough. My concern is jml encouraging an approach when we don't have an agreement yet, and, as he said, we have (already too many) other things to focus on right now. I don't know the API you are trying to expose. [19:54] If your approach to exposing does not assume a particular general solution, and is something that would really be a big win for you, then I'll not feel comfortable discouraging you. If it is a minor win, or if it involves changes to launchpadlib itself, then I'll be skeptical that this should be pursued until Leonard and I have bandwidth to discuss it. [19:55] I can expose it anyway you like [19:55] I definitely do not intend to change launchpadlib [19:56] and the fact that I am working on LP rather than continue to wait for the change to bubble to the top of an LP developers stack should indicate that it is important for us === Ursinha-lunch is now known as Ursinha [19:59] james_w, gary: i've responded via email [19:59] thanks leonardr [20:03] james_w: "expose any way you like": if it is within the range of the current standard tools to expose APIs, please consider me out of your way. The code team (and probably Jono, with his experience there) are the ones to guide you. [20:03] "do not intend to change launchpadlib": OK sorry, that was a question I had when I read that a change would be on the "client side." A misunderstanding. [20:03] not waiting for LP developers: understood. [20:03] I don't want to be a hindrance. It doesn't sound like I need to be one. Sorry for the noise. [20:09] gary_poster: thanks, let's continue discussion on the mailing list to decide what the best way to proceed is, at least in the short-term. [20:10] james_w: cool. === dpm is now known as dpm-afk [20:33] is there an easy way to look up a member of an enum by token? [20:47] leonardr: what do you mean by 'token' ? [20:48] mwhudson: i'm looking at a dbenum value and it has a number of fields: .token, .sort_key, etc [20:48] that's the token i mean [20:52] um [20:52] i don't see token on this dbitem [20:53] morning [20:53] leonardr: yes [20:53] leonardr: I think [20:53] leonardr: it looks like the class has a getTermByToken method though [20:55] ok, let me get precise about what i'm seeing [20:56] [20:57] it has a .description and an __iter__ [20:57] [x for x in OAuthPermission] is a bunch of lazr.enum._enum.TokenizedITem objects [20:57] each has a .title, a .token, and a .value [20:58] * thumper nods [20:58] i don't see any lookup methods anywhere. i get the feeling this is on a different level of abstraction from DBItem [21:00] leonardr: the item lookup is abstracted [21:00] leonardr: for no good reason [21:00] i'm getting the feeling it's not worth figureing this out to save a couple lines of code [21:01] what are you wanting? [21:01] here's my code [21:01] for check_permission in OAuthPermission: [21:01] if check_permission.token == permission: [21:01] permission = check_permission.value [21:01] break [21:01] to get the enuerated value from the token name? [21:01] i'd like to write permission = OAuthPermission.getByToken(permission) [21:02] permission = OAuthPermission.items[permission] [21:02] assuming permission is the string [21:03] >>> i [21:03] [21:03] >>> i.token [21:03] 'WRITE_PRIVATE' [21:03] >>> t [21:03] [21:03] >>> t.items[i.token] [21:03] [21:05] leonardr: that work for you? [21:08] yes, that seems to work [21:08] coolio [21:14] thanks [21:44] moin === salgado is now known as salgado-afk [22:27] * mwhudson rebooting [22:37] ✁☹ [22:38] that is for whoever decided that preferredemail was better than preferred_email [22:38] and while we're at it [22:38] displayname instead of display_name [22:38] thumper: ancient history isn't it? [22:38] probably [22:38] for a while _ wasn't allowed in column names in the db [22:39] stupid [22:40] every time I need to access preferredemail I get it wrong [22:57] mwhudson: got a minute to talk through something twisted? [22:57] hmm.. that could be a no === matsubara-afk is now known as matsubara [23:07] well, that was err, fun