=== mwhudson_ is now known as mwhudson [00:14] wgrant: is one supposed to review a mp with a conflict or wait/ask for the conflict to be resolved? [00:16] wallyworld: That's one of the great unanswered questions of the modern age. [00:16] hah [00:17] Are there more conflicts than just sourcecode.cache [00:17] ? [00:17] the other issue is the mp was resubmitted (after the susperceded one was approved) so perhaps the original approver should be the one to look at the new one [00:17] That seems to be it. [00:17] no, no other conflicts [00:18] i could easily remove them when running locally [00:18] just wondering as a matter of policy [00:18] It was last reviewed two months ago; I'm not sure that bac would have significantly more context than you at this point. [00:19] sure. i'll jump in then [00:34] wallyworld: what happens now with https://code.launchpad.net/~mwhudson/launchpad/ChoiceSource-flexibility/+merge/73611, does it need to be mentored? [00:34] mwhudson: i'm thinking for such a small change it's ok [00:34] wallyworld: can you land it then please? I don't think i have all the relevant bits set up [00:35] i guess it needs a commit message [00:35] mwhudson: sure, i was just about to ask you if you wanted me tyo do that [00:35] and uh, a bug report? [00:35] mwhudson: yes, a bug report if you want to be able to qa it before it gets released [00:35] i think that would be a good idea :) [00:35] just to be sure nothing breaks [00:36] there are semi related problems to do with the zIndex of the blocking div that prettyoverlay creates [00:36] but they can wait for another day :) [00:38] i'm getting persistent oopses on https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/835153 [00:38] <_mup_> Bug #835153: oosplash.bin crashed with SIGSEGV in XSetForeground()

< https://launchpad.net/bugs/835153 > [00:38] wallyworld: ok, should be good to land now [00:38] mwhudson: cool. onto it [00:38] thanks [01:04] allenap: thanks for those two suggestions for the 61428 merge [01:04] wgrant: looks like a buildbot test has hung. i assume we just force a new build in this case? i think this happens occasionally? [01:19] wallyworld: It's a regression in the last couple of weeks, but yes. [01:22] allenap: I just made the change that you suggested on my MP (https://code.launchpad.net/~dev-nigelj/launchpad/bug61428/+merge/73632) so it should be good to land now [01:30] Project devel build #1,022: STILL FAILING in 4 hr 55 min: https://lpci.wedontsleep.org/job/devel/1022/ [02:11] hi wallyworld! [02:27] Morning! [02:53] oh oh. [02:53] 503 error from loggerhead. [02:56] hi nigelb… sorry, never got around to looking at your MP yesterday. [03:00] jtv: hehe, np, I asked the OCR. I'm fixing test failings in it now :) [03:00] OK great [03:18] What is the solution if the result of the doctest is > 78 characters? [03:24] wgrant: about? [03:32] nigelb: Unless you're using -NORMALIZE_WHITESPACE, you can just add newlines wherever you want. [03:33] Does this look fine? [03:33] >>> browser.getControl('Title').value = 'Extension Manager ' [03:33] ... 'System Upgrades' [03:33] because lint complains for that. [03:35] jtv: hi. sorry missed your ping. my stupid irc client doesn't pop up notifications for very long and then I miss them if i am afk eating or something :-( [03:35] nigelb: Oh, that's not the result... I'd do this: [03:35] >>> browser.getControl('Title').value = ( [03:36] ... 'Extension Manager System Upgrades') [03:36] Ah. [03:37] wallyworld: I was just saying good morning. As you know I don't think you need any further mentoring, and since I can't find any further procedural notes, I hereby formalize your graduation. [03:37] Note to mailing list to follow. [03:37] congrats wallyworld! [03:37] jtv: cool :-) i did a largish review this morning but it needs fixing so i didn't ping you yet. but i guess now i don't need to [03:38] nigelb: thanks [03:38] That's right. [03:39] * wallyworld goes back to fixing some failing tests !@%@!%@$! [03:39] haha [03:41] If my code passes tests, does it automatically get merged? [03:41] passes tests from ec2land. [03:41] nigelb: yes, unless pqm is in testfix mode [03:42] due to a buildbot breakage [03:42] hrm, I don't think my branch last night merged, despite tests passing. [03:42] buildbot was broken for a while. [03:42] nigelb: check your email - there should be one saying it merged or else something like 0 tests blah blah [03:42] nigelb: whoever ran ec2 land should have an email in that case [03:43] heh, simultaneous contradiction! [03:43] The signer gets the PQM email. [03:43] oops. i forgot that someone else would have landed it [03:43] Both parties get the EC2 email. [03:44] ok, I'll poke danilos later when he gets on. [03:44] mwhudson: Did you find configobj helpful? :) [03:57] nigelb: i haven't gotten around to looking at it yet [03:58] nigelb: i'd blanked on the fact that bzr used an external library for this sort of thing though [03:58] well sort of external [03:58] :) [03:58] There are lots of things in ConfigParser which really irritate me [03:59] argh, doctests. [03:59] How do I reduce this one to less than 78 [03:59] 'http://blueprints.launchpad.dev/firefox/+spec/extension-manager-upgrades/+edit' [04:00] http://blueprints...dev/firefox/+spec/exten.../+edit [04:00] nigelb: do you have to silence the lint complaint? [04:00] i don't know if doing so would be a good use of time [04:00] hi, btw [04:00] poolie: Well, I can always ignore it :D [04:01] I didn't think we cared about 78 char limit in doctests ... [04:01] poolie: Morning! :) [04:01] StevenK: \o/ [04:01] hi there [04:16] Can someone kick this back into ec2? https://code.launchpad.net/~nigelbabu/launchpad/specification-validation-59301/+merge/73631 [04:18] * nigelb also notes the /topic needs updation [04:23] jtv: "to a vicious shark who will go as deep as it takes to find out what's wrong with your branch" -- you've trained him well :P === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: supreme ruler wallyworld | Critical bugs: 251!! - 0:[#######=]:256 [04:23] Does anybody know of a Unicode explosion character?' [04:23] Or something similar? [04:24] wgrant: an invalid UTF-8 sequence will usually do the trick :-P [04:24] nigelb: thanks ☺ [04:24] jtv: The graph in the topic will need it soon :( [04:25] ☢ ? [04:25] Ha, that's why. [04:25] jtv: That works. [04:25] There are 257 tasks :( [04:25] I take it the counter's been running the wrong way then? Otherwise you'd be looking for ☮ [04:25] But 6 of them are private. [04:26] So webnumbr says we are safe and the world has not ended. [04:26] ☠ [04:26] Who is webnumbr? [04:26] http://webnumbr.com/launchpad-critical-bugs [04:26] wgrant: http://www.fileformat.info/info/unicode/char/1f4a3/index.htm [04:27] That is worryingly far outside the BMP. I wonder how widely supported it is. [04:27] But that looks helpful, thanks. [04:27] Hah. [04:27] Introduced in Unicode 6. [04:27] ie. 10 months ago. [04:27] Only 2 fonts support it. === wallyworld changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld | Critical bugs: 251!! - 0:[#######=]:256 [04:34] wallyworld: Hi, I had a few test failures yesterday from this MP. Would you mind re-reviewing and kicking it back into ec2? https://code.launchpad.net/~nigelbabu/launchpad/specification-validation-59301/+merge/73631 [04:34] nigelb: sure [04:35] * wallyworld looks [04:35] I should have commited test fixes and then fixed lint. [04:35] gah. [04:38] wallyworld: Nice work! [04:39] StevenK: thanks. how's the battle scenario modelling going? [04:39] More painting :-P [04:41] remember, i want to see a photo when it's done :-) [04:41] I've been linking you photos in privmsgs, you didn't comment :-P [04:42] StevenK: ah bollocks. didn't notice :-( Under Unity, quassell notifications aren't very obvious to me anymore for some reason so i miss them [04:43] StevenK: so they start out blue? so you still have some work to do on those ones? [04:44] wallyworld: They start out grey and on a sprue [04:44] nigelb: ec2 is off and running the tests [04:44] So I need to cut them out, assemble them and then paint them fully [04:44] wallyworld: thanks [04:44] StevenK: battle scenario modelling? [04:45] * wallyworld types into google "define: sprue" [04:45] nigelb: that was my made up term [04:45] not sure what the official name for it is [04:45] What is he making? :) [04:47] nigelb: painting little figurines of warriors and the like for display in a battle field scenario [04:48] StevenK: not sure if that's the correct description? ^^^^ [04:48] Oooooh. [04:48] Close enough [04:49] StevenK: You made those? O_O [04:49] like, from scratch? [04:49] wallyworld, nigelb: http://wedontsleep.org/~steven/IMG_2807.JPG is what they start out like. [04:50] ah, not entirely from scratch. [04:50] That is for a different army, but you get the idea. [04:50] But still, excellent work. [04:50] StevenK: oh, i didn;t realise you had to glue them together before painting [04:50] You manage to do stuff that does not involve computers during paid vacation. [04:50] wallyworld: That's the colour they start out as well. [04:50] * wallyworld nods [04:51] That blue colour on them is 4 different blues [04:51] how do you attach them? [04:51] melt? [04:51] or glue? [04:51] nigelb: Plastic glue [04:51] * wallyworld wonders how StevenK is typing with all his fingers stuck together [04:52] Plastic glue doesn't affect skin, it washes off easily [04:52] If his fingers do get stuck, I know which key it will be on. [04:52] ('Del') [04:52] * G fears StevenK's army [04:53] Pft, I use vim, so it would be d [04:53] heh [04:59] ohhh I may have spied on a another bugfix :) [04:59] G: You're +1200? [04:59] nigelb: yep [05:00] Two people with first names Nigel and we're both not British? Talk about breaking stereotypes :P [05:00] in way of ancestry I'm mainly British [05:01] Ah. [05:01] but I'm also partly Swede etc as well [05:22] hooray for wallyworld! [05:22] congratulations on your asterectomy [05:22] asterectomy sounds painful :P [05:23] "define asterectomy" got spell corrected to "define hysterectomy" making me LOL :) [05:32] poolie: thanks [05:32] the removal of his "i'm not a real reviewer" star [05:32] Ah. [05:33] aww wallyworld changed it, wgrant put a better /topic ;) === Topic unset by poolie on #launchpad-dev === poolie changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld | Critical bugs: 251!! - 0:[#######=]:256 [05:37] Project devel build #1,023: STILL FAILING in 4 hr 7 min: https://lpci.wedontsleep.org/job/devel/1023/ [05:58] wallyworld: gratifying that your graduation did not go unnoticed, no? ☺ [05:58] jtv: i was hoping to sneak under the radar and keep it quiet. but you put an end to that ambition :-P [05:59] Why would you want to do that? [05:59] jtv: i don't like attention :-) [05:59] i'm shy [05:59] Tip #1 for a reviewer: be feared. Otherwise people start bothering you for reviews even when they have other options. [05:59] hah. good advice :-) [05:59] The attention comes in the one form or the other. Trust me, you got the better deal. [06:00] lol [06:00] jtv: i notice you have a repuation as a feared reviewer [06:00] now i know why [06:00] "fascist" is the more common term, but alright [06:01] jtv: well, if hard questions are asked and you get good answers, then that's good [06:01] I rejected a sentence added to an HTML page the other day. [06:01] all this discussion about fearing reviewers when I want to run something by... :) [06:01] wallyworld: see? ^^ [06:01] G: i don't bite, but jtv does [06:01] i think i need more mentoring therefore :-) [06:01] I'm doing my best for you, wallyworld. Don't throw it all away. [06:02] wallyworld: well it's lucky I also don't fear people generally :) [06:02] Repeat afer me: I bite. I'm a shark. I'll go as deep as it takes to find what is wrong with your branch. [06:02] * wallyworld repeats I bite. I'm a shark. I'll go as deep as it takes to find what is wrong with your branch. [06:02] jtv: why the rejected sentence? [06:03] Sorry, is this _still_ not clear to you? [06:03] Fear. [06:03] ah, right. [06:03] * wallyworld needs to grow a pair [06:04] You don't have to be online who you are in real life though. Ever seen BjornT and bigjools face off in the two arenas? The outcomes are very different, I tell you. [06:04] wallyworld: putting your self proclaimed fearsome-ness to the test... I'm looking at https://bugs.launchpad.net/launchpad/+bug/793670 and found the issue ln 1819 of lib/lp/registry/browser/person.py runs setPreferredEmail(None), but a reactivation doesn't know which e-mail to set preferred again [06:04] <_mup_> Bug #793670: User account missing preferred email after suspension/reactivation < https://launchpad.net/bugs/793670 > [06:04] wallyworld: What we have online is you with a huge automatic weapon. [06:04] No go get 'em. :) [06:04] wallyworld: would the right way be to create a new EmailAddressStatus such as "OLDPREFERRED" to save that detail? [06:05] G: i'll look, give me a second [06:05] jtv: will do [06:05] :) [06:07] wallyworld: so maybe something like setSuspendedPreferredEmail() which changes the status of the current preferred e-mail to OLDPREFERRED and then does _setPreferredEmail(None) [06:07] G: jtv doesn't bite. Be makes you bite yourself after seeing his reviews. [06:07] *But he [06:07] Well _if possible_ obviously I like to avoid even that bit of the work. :) [06:09] wallyworld: rationale for a new Status, is that otherwise the question is "which VALIDATED e-mail should become the new PREFERRED e-mail" [06:09] StevenK, wgrant: we don't import binaries from debian, do we? I suddenly wonder if there's still any need for gina to import binaries at all. [06:11] jtv: We don't use gina's binary importer at the moment, no. [06:11] jtv: But removing it right before we start migrating derivative distros onto LP would be somewhat foolish, I think. [06:12] G: another option is to modify the preferredemail property on person to check the account status before returning the email object [06:12] G: that seems cleaner to me [06:12] wallyworld: ahhh now that is a good idea [06:13] G: it's a smaller, more localised change with a smaller footprint [06:13] wallyworld: but I think the logic to removing the preferred e-mail address is to avoid cases where it may not go through the preferredemail property? [06:14] G, wallyworld: This is a pretty difficult and all-encompassing issue. [06:14] we need to make person status explicit, and fix a lot of code that checks for preferredemail instead. [06:14] wgrant: so when are we going to start using gina's binary importer? What tells us that it will still work properly when we do? What work have we done to verify that there are no harmful interactions between the binary importer and derived distributions? [06:14] DB queries and stuff that doesn't use the property. [06:14] jtv: None, but it will probably need to be done this year and deleting it is not a good idea. [06:14] G: So, in summary, "run away". [06:15] G: This is a deep rabbit hole. [06:15] wgrant: you would hope there's a single piece of logic to do "get the email address to send stuff to for this person" [06:15] wallyworld: Hee hee hee. [06:16] wgrant: so we have something that we don't use, and won't use, and may do some kind of unknown damage. Therefore we can't delete it shortly before the point where it may start doing that damage. Does that sum it up? [06:16] wallyworld: So, no, there isn't. And the preferred address is used not just for finding the preferred address, but also for checking whether the account is active. [06:16] wgrant: so essentially noone understands the logic so run away? [06:16] wgrant: that's dumb. account status should be via an "status" property of some sort [06:17] wgrant: thats what I'm saying... introduce a new ENUM option "OLDPREFERRED" and set the PREFERRED to that instead of VALIDATED on suspension [06:17] jtv: gina is known to not be in a good state. I hope nobody is crazy enough to run it in anything except source-only Debian mode without first extensively checking the code. [06:17] not piggybacked onto another property [06:17] G: But the account status is unrelated to email addresses. [06:17] G: It should be a property of the person. [06:17] wgrant: so what else would we use it for? [06:17] jtv: Migrating Linaro and OEM and $OTHER_DERIVATIVES to LP. [06:17] wallyworld: You. Would. Think. [06:18] wallyworld: There is Account.status, but very little uses it, and Account needs to burn anyway. [06:18] yeah, clearly i'm still too idealistic wrt lp code cleanliness [06:18] wgrant: but isn't: make it so LOSA's don't have as much work to do, and "re-implement everything sanely" two different issues? [06:18] * jtv gives up on wgrant [06:18] jtv: Hm? We've just enabled LP to handle derivative distributions. [06:18] jtv: We have several derivative distributions that need to be moved into LP. [06:19] The way to migrate a distribution to LP is to use gina on it, importing binaries too. [06:19] G: you should talk to someone like cutis (who is on leave till next week). he know a lot about our email infrastructure i think [06:19] gina needs significant repairs to be able to do that properly nowadays, but deleting the code is hardly going to make it better. [06:20] G: Not really. Adding a new email address status is just perpetuating the insanity. [06:20] G: We should fix this properly. [06:20] G: fwiw. "so LOSA's don't have as much work to do" is a ... funky way of phrasing it. better would be "so losas can spend THAT time on other tasks equally valuable" [06:21] it's not like we're sitting around on our hands waiting to be pinged :-) [06:21] spm: actually that is a better way of putting it :) [06:21] :-) [06:21] spm: I should have said "So they don't have to worry about that issue anymore" :) [06:22] or something like that :) [06:22] wgrant: but yes, I see your point [06:23] wgrant: and obviously the solution would be to find everything that generates and e-mail and make sure that it someway or another goes through a proper method to get the e-mail address, that also checks if the account is active [06:23] G: Roughly. [06:24] jtv: So, am I still given up on? I'm not quite sure what's so controversial about not deleting code that we will probably have to revive to bring this feature into use. [06:25] and I'd imagine doing that, and all the subsequent tests to make sure it's working properly would be quite a lot :) [06:26] wgrant: sorry, I get frustrated sometimes. I now realize that you meant to give the right answer, but because you never answered the direct question, I completely misinterpreted the rest of what you said. So for confirmation I posed that "so we're not going to use this code," but you didn't deny it. After all that, it was a very disorienting realization that you meant the exact opposite of what I was getting all along. [06:27] I asked a composite question, which in retrospect maybe I shouldn't have done, and so when you talked about "None" and "it," that left a lot of room for interpretation. [06:27] jtv: We are going to use the code, but not in its current state. [06:27] It was last used in mid-2007. People know not to use it now, so it is not harmful. [06:28] You really know how to scare me! [06:28] But when we want to move distros onto LP, we will have to revive it and verify its correctness. [06:28] That's the part I was curious about: I got the impression that this was basically no more than a leftover from the original Ubuntu import. [06:28] It *is* basically no more than a leftover from the original Ubuntu import. [06:29] But it was used 18 months later to import partner too, because it still mostly worked, and didn't break too much. [06:29] Well one thing more, apparently: the start of derived-distros import. [06:29] And I imagine it will be used against soon. [06:29] again [06:29] Right. [06:29] But it's still just a leftoer. [06:29] Just one that will be reincarnated. [06:29] gina itself was just a leftover from the Ubuntu import. [06:29] It got reincarnated and fixed up to import Debian. [06:29] Some years later. [06:30] I don't know how many changes it went through; usually I advocate ditching poorly-understood custom code over reviving it after a long period of falling out of touch with the working application. It'd do this code a world of good, but I can see the point for not rewriting this kind of stuff on a whim. [06:31] But oh, the stuff I keep prying out. [06:32] gina's not huge, and it's pretty awful, but given the way LP goes it's tempting not to throw away roughly working code. [06:32] Because it would naturally take at least 18 months to get a replacement working :/ [06:32] I finally figured out that some very hard-to-read code with practically untyped data was really iterating over a dict's elements in alphabetical key order. [06:33] Yeah, there is a bit of that sort of stuff. [06:33] A bit, he says. [06:33] But it's normally possible to untangle. [06:33] Eventually. [06:33] ... occasionally by rewriting it and seeing what differs when you import an archive. [06:33] That's what I did with the dominator: a huge sql-laden mega-method turned out to be a few completely independent, easily-described methods. [06:34] Which reminds me: ran a full test domination of Debian on dogfood. Seems to have gone pretty well, apart from the known problem with pre-existing publication records. [06:34] I wonder why we have all this support for deleting a source package without its binary packages though. [06:34] (Well, requesting deletion of a publication of a source package without doing the same for the publications of its binary packages) [06:35] Things could be a whole lot simpler and faster without that ability. [06:35] SPPH<->BPPH links are special. [06:35] ie. implied and varying. [06:36] Oh. [06:36] Oh God no. [06:36] Please no. [06:36] Remember that complicated code that iterated over a dict's keys? [06:36] That was for source packages. [06:36] And? [06:37] It has a near-exact counterpart for binary packages. [06:37] Ah yes. [06:37] That also happens a bit. [06:37] for binary in sorted(packages_map.bin_map[archtag].values(), [06:37] key=lambda x: x.get("Package")): [06:38] —where packages_map.bin_map[archtag] is, of course, keyed by x["Package"]. [06:38] Heh. [06:38] I'm glad to see you cleaned up the dominator more. [06:38] I did a bit a yearish ago. [06:38] But it was still pretty awful. [06:39] I didn't get all the way up to judgeSuperseded and judgeAndDominate... just the lower-level stuff. [06:39] You seem to have fixed the rest up nicely, however. [06:40] Thanks. Didn't even change much in terms of complexity, just moved large blocks of code. [06:40] And simplified the setdefault/sort/reverse mess. [06:40] Oh, that :) [06:40] With the creative variable name 'L'. [06:41] package_name = binary.get("Package", "unknown") [06:41] Erm. [06:41] ^^ after all that trouble reconstructing the dict key, which is binary['Package'] [06:42] s/.*/raise DebianIsInsaneError/ [06:42] I'll catch your DebianInsaneError and raise you a personal sanity failure. [06:46] danilos: Hi, around? [06:46] Oops. [06:46] I made the mistake of using qannotate to check the dominator's history. [06:46] Forgetting the qt apps now hang X. [06:47] Thanks unity :) [06:47] Excellent. [06:47] Aren't you going to go the extra mile and blaim thumper for it? [06:47] Nah, I've already done that once this week. [06:48] *blame [06:55] jtv: Launchpad is really good at consistency, isn't it? [06:56] We're getting better. I think squads are a step forward. [06:56] Even within a squad. [06:56] Consider the ?PPH state transitions from PUBLISHED. [06:56] supersede(), setDeleted() and requestObsolescence(). [06:56] Well, setDeleted is purely an internal support method. [06:57] Three different tenses, three different prefixes. [06:57] True. [06:57] That part makes sense. The real comparison I think is {requestDeletion, requestObsolescence} and those look consistent to me. [06:57] Indeed, I'd forgotten that setDeleted had not entirely replaced requestDeletion. [06:58] It was never meant to. [07:03] wgrant: here's a thought about debian domination. I can make retireDeadSourcePublications find the latest source publication for each package; request deletion for that one and supersede the rest. [07:04] jtv: That would work. [07:04] Oh, gotta help out with something else now. [07:04] * wallyworld is off to see Australia vs Thailand in a soccer World Cup qualifier :-) [07:07] good morning [07:31] StevenK: So tell me about our Storm branch. Is there stuff in there that hasn't or cannot land upstream? [07:32] stub: Has with_ landed upstream? [07:32] The main issue apart from that is that storm now converts Date to a Python date, rather than a datetime. [07:33] I dunno. I think this happened while I was on leave. [07:33] which breaks tests and some code. [07:33] Do we have bugs open on Launchpad or Storm? [07:34] I don't recall. lifeless did the Date -> date revert initially. [07:34] StevenK and I just updated the branch later with fixes we'd landed on trunk. [07:34] ok. I'll trawl some bugs. === danilo_ is now known as danilos [07:46] wallyworld, hey, congrats on becoming a reviewer and thanks for using your newly found powers to review my code-imports-ui branch ! [07:47] is someone fixing the merge conflict? [07:48] I can get there in a minute [07:49] \o/ [08:12] danilos: Aha, thanks for merging! I was about to poke you. :) [08:17] Hello [08:18] nigelb, you are welcome (it failed to merge yesterday because we hit "testfix" mode: a mode which stops further landings from happening when someone merges a branch that fails the test suite) [08:21] hey mrevell :) [08:21] danilos: ah! that makes sense :) === almaisan-away is now known as al-maisan [08:28] hum, how does one update sourcedeps.cache without doing it manually? [08:28] danilos, ./utilities/update-sourcecode ? [08:29] jelmer: oh, thanks :) [08:41] hmmm I was looking at the list of trivial Launchpad bugs, and found: https://bugs.launchpad.net/launchpad/+bug/137373 the funny thing is, now it seems the blacklist deosn't exist, and you can 'register' a project named 'codeofconduct' without error, but be generated to the code of conduct page [08:46] G: that sounds odd. Let me try that. [08:47] mrevell: I just did a grep around, and can only see the error message in relation to person/team names [08:47] G: on staging,I get the message "The name 'codeofconduct' has been blocked by the Launchpad administrators." [08:47] it's as if the concept of blacklisting project names went into a void/black hole [08:48] mrevell: on my rocketfuel setup LP, it just proceeds like nothing happened [08:49] G: Weird. On product it's blocked. I did notice that initially it tried to give me a project name of "codeof", though. [08:49] haha and now it says "codeofconduct is already used by another project" so the registration obviously worked [08:49] G: did you check if the blacklisting is in the db? [08:50] I'm just guessing. It is possible that its a table of some sort. [08:50] I'm not sure how the blacklisting works. Any ideas wgrant? [08:51] for people/teams it's done in python in: ./lib/lp/registry/interfaces/person.py (class PersonNameField(BlacklistableContentNameField) [08:51] That's a person, not a project [08:51] StevenK: I said that :) [08:52] my point is, greping around in my checkout, I can't find anything similar for projects [08:53] ohhh except I know what I mayhave done wrong [08:54] case? === adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld, adeuring | Critical bugs: 251!! - 0:[#######=]:256 [08:59] mrevell, I am pretty sure blacklisting is a table in the DB [08:59] G: ^ [08:59] hmmm okay, theory didn't work out [09:00] I created a user that didn't belong to any teams in the DB and it still worked w/o error [09:00] mrevell, "psql launchpad_dev" and then "\d nameblacklist" :) [09:01] danilos: ahhh ha [09:01] and select * from nameblacklist; doesn't include a regex that matches codeofconduct [09:02] Which is why it worked for you. [09:02] It's in the production database [09:03] yep, okay that makes sense now [09:03]