[00:20] I'm trying to pull the summary from a spec, but it doesn't seem to be working. I am using elem.get just like I did for all the other info I am getting, but this one isn't working. [00:20] Any ideas? [00:20] cjohnston: Isn't working? [00:20] And which library are you using? That doesn't look like launchpadlib. [00:21] http://blog.bitbucket.org/2011/07/07/redesigned-commits-screen/ [00:21] simplejson [00:22] It's there. [00:23] wgrant: http://pad.ubuntu.com/dYgqgL4JaA [00:24] cjohnston: It's in the JSON that LP sends, but I don't know how you are getting the JSON. [00:24] wgrant: http://bazaar.launchpad.net/~summit-hackers/summit/1.x/view/head:/summit/schedule/models/meetingmodel.py#L188 [00:29] Does that give you any more info wgrant ? [00:29] cjohnston: Not really. Launchpad is sending the correct JSON, so you'll need to check the JSON you have. [00:29] wgrant: hi [00:30] jelmer: Hi. [00:30] wgrant: You tried to land lp:~jelmer/launchpad/publisher-use-debian-2 earlier but it failed for some reason, do you know what it was? [00:31] Hmm, I recall I ran it through ec2, but cannot find an email about it.. [00:31] wgrant: no worries, I'll have another look at it [00:31] wgrant: thanks [00:32] Sorry. [00:33] wgrant: Don't be :) I appreciate you trying to land it, when I didn't have time to. [00:34] * jelmer gets some sleep [00:35] Night. [02:06] does anything still use BranchSparkView ? [02:08] Heh [02:08] lifeless: A bunch of tests? [02:09] nuke from orbit time [02:09] It was disabled during 3.0, to be fixed and revived within a month. [02:09] And IBranch:+spark [02:09] lifeless: Are you nuking it? [02:10] StevenK: not right now, I have managerial thingies to do [02:10] then some folk from .au are dropping by before they head home [02:10] if you are interested in nuking it, please do. [02:10] [red button] [02:10] * lifeless pushes the red button === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 241 - 0:[######=_]:256 [02:38] wgrant: Can haz review? https://code.launchpad.net/~stevenk/launchpad/destroy-branchsparkview/+merge/68627 [02:38] StevenK: What about the JS? [02:38] There's JS? [02:38] That view provides JSON to the JS. [02:40] * StevenK looks for the JS [02:42] wgrant: Three more methods found and destroyed, but the JS is proving harder to locate. [02:43] Already removed in r9680 [02:45] Ah, so the JS is long-dead [02:50] wgrant: No review, then? :-) [02:51] It is reviewed. [02:51] Was just checking you'd got all of it. [02:51] Ahhh [02:51] I got all of it after I killed the other 3 methods? [02:51] Yes [02:51] Excellent, thanks [04:35] righto, time to write up docs [04:35] StevenK_: thanks for fixing that timeout! [04:35] (+spark) [04:35] Haha [04:35] lifeless: Is there a bug about it? [04:37] none filed yet [04:37] it was 1/0 in todays timeout report [04:38] lifeless: Fair enough. My branch is currently ec2ing [04:38] no-qa is fine IMO [04:38] I'm just happy :) === StevenK_ is now known as StevenK [04:40] Aha! [04:40] An excuse to kill IUpstreamBugTask and co. [04:40] Oh? [04:40] Do you know of it? [04:41] IUpstreamBugTask, IProductSeriesBugTask, IDistroSeriesBugTask, IDistroBugTask are marker interfaces. [04:41] Nope [04:41] Which need to change when the target of a task changes. [04:41] Which means that retargetting bugs between target types needs to change them. [04:41] But that makes lazr.lifecycle sad. [04:42] So, I may finally kill them. [04:42] More code deletion? :-) [04:42] Since there's just about no good reason to have them. [04:42] There are only a couple of places that care, and they can just check the interfaces of the target directly. [04:48] Yippie, build fixed! [04:48] Project db-devel build #739: FIXED in 5 hr 38 min: https://lpci.wedontsleep.org/job/db-devel/739/ [05:13] wgrant: Do you know if dogfood has query logging on? === almaisan-away is now known as al-maisan [05:13] StevenK: It doesn't seem to. [05:14] I am disappoint. [05:14] Ja. [05:14] OTOH the disk space would probably be sort of bad. [05:14] Meh, mawson has 150GiB free :-P [05:14] Now :) [05:19] * StevenK peers at database/schema/launchpad.html [05:31] Hmmm. 450 results for '%ubuntu%' in PillarName [05:32] At least one of them is the distribution itself. [06:02] * wgrant headdesks. [06:02] wgrant? [06:02] - else: [06:02] - assert ( [06:02] - "Expected IDistroSeriesBugTask or IProductSeriesBugTask. " [06:02] - "Got: %r" % bugtask) [06:03] There should really be a warning for that. [07:25] good morning [07:38] hi adeuring [07:38] oh, and hi rvba! [07:39] hi jtv [07:39] wgrant: I take it the cocoplum rollout succeeded then? [07:39] jtv: Soyuz only had unrelated OOPSes this morning, so yup, seems like it all went OK. [07:40] hi jtv! [07:40] Great. [07:40] Good morning all. [07:40] wgrant: for my next trick, I sort of re-did the distro-publisher code. [07:40] So I saw! [07:40] Well. [07:41] I saw the "diff too big" warning in the email. [07:41] I've not seen the change itself. [07:41] Similar to what you did to process-accepted? [07:41] "Diff too big"? I hadn't seen that. [07:41] Should be "only" 1200 lines or so. [07:41] I suppose. [07:42] I didn't feel I could just go on adding to the problem. [07:42] Indeed. [07:42] So much evil to destroy :( [07:43] The question right now is: how do I Q/A publish-distro? [07:43] (Have a look at it — it wasn't nearly as hairy as it seemed) [07:44] That is a lot of tests. [07:44] Yes, it really helps to know that the components work. [07:45] Found one or two cases of "this couldn't have worked." [07:52] hi bigjools [07:52] morning [08:10] Anyone want to review https://code.launchpad.net/~stub/launchpad/staging/+merge/68529 for me? Boring meat and potatoes staging/production rollout code. [08:12] Morning === allenap` is now known as allenap [08:27] wgrant: You remove a XXX from 2006 that references bug 55089 [08:27] <_mup_> Bug #55089: IUpstreamBugTask should be renamed to IProjectBugTask

< https://launchpad.net/bugs/55089 > [08:28] Ah, which is already linked. Nice. [08:49] 1.1 billion branchrevision rows now... going up by about 50 million/month. [09:00] stub: is the disk space reduced at all by not having id as a primary key? [09:01] It is now that the nodes have all been rebuilt. [09:01] ah right [09:01] i guess it's a substantial fraction of the node rebuild time though... [09:06] stub: I'm still amazed by the lack of alarms and sirens for that change. [09:07] -back [09:08] -back [09:08] mwhudson: the id column plus various indexes came to a few 10s of GB [09:08] whoops, wrong keyboard layout and I insist on retyping it :) === _mup__ is now known as _mup_ === stub1 is now known as stub === al-maisan is now known as almaisan-away [10:09] really really starting to wish Launchpad has some kind of push notification [10:10] jml: Only once you lost your ability to direct? :) [10:10] wgrant: now I can afford to be selfish. [10:10] :( [10:10] Selfishness is what Launchpad has needed for a number of years now... [10:11] Stakeholder direction only gets us so far in the sensible directions. [10:11] We've been making it work, rather than making it not suck. [10:11] :) [10:13] wgrant: You tell me this only once I've lost my ability to direct? :P [10:13] Heh [10:13] heh, so hire someone who's as selfish as you :D === allenap changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: allenap | Critical bugs: 241 - 0:[######=_]:256 [10:41] danilos: Thanks for organising that deployment! [10:47] jml: communicating internally in the open is not a bad thing. I like reading the list even though I may not be able to do anything for a few items. [10:54] wgrant, hey, you are welcome :) [10:54] wgrant, and it should be more of a norm for the rest of us to do it === almaisan-away is now known as al-maisan [11:29] allenap: https://code.launchpad.net/~stub/launchpad/staging/+merge/68529 :-) [11:30] stub: I'm already looking at it :) [11:30] stub: Out of interest, why did you go for using /etc/init.d/pgbouncer instead of using PAUSE/SUSPEND/RESUME via the pgbouncer virtual database? === matsubara-afk is now known as matsubara [11:32] allenap: We need to shutdown pgbouncer because suspend/resume just blocks inbound connections, not reject them. [11:33] allenap: There is an option to tell it to reject connections that can't connect after x seconds, but it doesn't work in suspend mode (either bug or design, don't know) [11:34] allenap: in the lightning talk I gave, I sketched out a situation where connections block but after further discussions with lifeless we are just going to drop them and require the clients to cope and/or present nice errors to the users. [11:34] stub: Okay. The init script does cause a pause then shutdown, but with only 1 second delay. Is that okay. [11:34] ? [11:36] allenap: That is fine. [11:36] stub: r=me [11:36] And I could shut it down by other means (psql -d pgbouncer -c shutdown, or kill(1)) if it becomes a problem. [11:36] ta [11:39] jtv1, rvba: hi, there are a few revisions of your needing QA, it'd be nice if you can get to that today [11:39] danilos: I know, thanks [11:39] yours [11:39] danilos: will do. [11:45] danilos: done. [11:45] rvba, thanks [12:46] allenap: free for a review? https://code.launchpad.net/~jtv/launchpad/get_derived_distros/+merge/68675 === jtv1 is now known as jtv [13:02] Morning, all === jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: allenap, jcsackett | Critical bugs: 241 - 0:[######=_]:256 [13:27] allenap: can i request a review for https://code.launchpad.net/~jcsackett/launchpad/a-private-place-to-live/+merge/68687? [13:30] jcsackett: Sure. I think jtv's first then you. [13:30] allenap: I've been producing them faster than you can review them. :) [13:30] allenap: works for me. i can always do jtv's if you haven't already started. just can't review my own branch. :-P [13:31] jcsackett: I have a few more ready now. [13:31] So there's enough for both of you! [13:31] jtv: erm, eh, fantastic? :-p [13:31] hehheh [13:31] jcsackett: Okay, you start with jtv, I'll do yours, then move back onto jtv's new ones. [13:31] allenap: righto. === Ursinha` is now known as Ursinha === Ursinha is now known as Guest44940 === Guest44940 is now known as Ursinha_ [13:40] jtv: r=me on the first one. [13:40] * jcsackett likes short diffs. [13:40] thanks! [13:41] jtv: you have a preferred next branch for me to look at? i see three in the queue. [13:41] Yes: the bug-788078 one, thanks. [13:42] That's bigger, but I carved out pieces for a separate branch — which you just reviewed. :) [13:42] jtv: ok. looking at that one momentarily. [13:43] Thanks. === Ursinha_ is now known as Ursinha [14:19] allenap, jcsackett: are either of you looking at https://code.launchpad.net/~wallyworld/launchpad/picker-wiring-812255/+merge/68629 [14:19] sinzui: it's in the queue. :-) [14:20] sinzui: What Jon said :) [14:22] oh, 2 reviewers today! perfect day to get my branch out. [14:32] allenap: could you review https://code.launchpad.net/~bac/launchpad/bug-799901/+merge/68590 at your leisure? [14:33] bac: Sure :) [14:35] jtv: correct me if this is wrong, but it looks like this adding a fair bit of new iteration to the process; is this script not one we worry about time to complete on? [14:35] ugh, I need some help with a branch. Does anyone have a few minutes to help figure out why I'm getting http://dpaste.com/573320/ for https://code.launchpad.net/~nigelbabu/launchpad/spec-sub-sort/+merge/63315 [14:36] jcsackett: only for Ubuntu, in which case the list it iterates over is of length 1. [14:36] nigelb: I'll take a look. [14:36] allenap: Thanks a bunch! [14:36] jcsackett: the idea is we can do the work for all _other_ distros we do it for much more quickly. [14:36] jtv: so if we're doing all-derived we're well aware it could take a bit and that's just fine? [14:36] jtv: ok. [14:36] Yes. If it's not, we can easily extend this to more fine-grained load-balancing, such as "publish a thru f on this server." [14:37] jtv: ah, yes, you mentioned granularity in the cover letter. [14:37] Thought so. :) [14:37] ok, jtv, r=me. just wanted to make sure i wasn't approving a performance bomb. :-) [14:37] Good job. Thanks! [14:38] cody-somerville, timrc: do you have time to talk about OEM's ongoing requirements with regard to our derived distros feature? [14:38] bigjools, if I could keep natty from crashing, yes :) [14:38] bigjools, When? [14:39] can you do it in the next hour or so? [14:39] next week would probably be better as cody-somerville will be back in North America [14:39] or now? :) [14:39] oh.. [14:39] allenap: thanks for your comments, i'll address those changes. how much longer are you on review for? [14:39] next week is ok if that's better [14:39] bigjools, I'm at DebCamp this week. Next week would be much better for me. [14:40] jcsackett: Another couple of hours, then I'll be back later this evening. [14:40] allenap: ok. thanks. [14:40] cody-somerville, timrc: ok that's fine. I want to see how attached you are to using those crazy custom suites :) [14:40] jcsackett: I think you only *need* to address point 3. [14:40] bigjools, we're more crazy about deriving distros from multiple sources I think :) can we do that yet? [14:41] timrc: yes [14:41] allenap: right, but if i can i'll address the others. no reason to delay good fixes if it's not out of scope. [14:41] it's not quite released yet but we got it working finally, today [14:42] bigjools, neat! [14:43] what's the best way to submit a set of proposed changes for the Launchpad PPA? [14:43] I guess I need to do them for all of lucid, maverick, natty :-/ [14:43] cjwatson: if you have packages in a different PPA we can review and copy [14:44] I do (well, mvo does), but only for lucid at the moment [14:44] well it's your fault, you keep releasing new series every 6 months :) [14:44] gosh, I never knew I had a choice. :-) [14:45] ok, I'll see if I can put together a staging PPA with everything [14:45] great [14:53] hrm, is subscribing to a blueprint broken on trunk? [14:54] s/trunk/devel [14:54] I just realized I can't subscribe to a blueprint on my dev env. [14:57] nigelb: It should read user=subscribed_by not user=user. [14:57] Line 567 of specification.py. [14:58] ah [14:59] I think I didn't notice it when "fixed" the merge conflict when I merged from devel the last time === Ursinha is now known as Ursinha` === Ursinha` is now known as ursinha` === ursinha` is now known as Ursinha [15:08] nigelb: On the one hand sort_for_display() is generic - it can sort by any attribute - on the other it calls .lower() on the value it finds. I think you'd be better off without it; just fix the bug in specification.py and don't worry about the general case. As jtv notes in his review, it's a much bigger problem. What we really need is an agreed way to derive a collation key, but that's out of scope for this fix. [15:09] Isn't sort_for_display exactly what should hide that problem from us, so we can fix it once? [15:09] allenap: The inital bug was there was no lower() cuasing the sorting to be messed up. [15:09] what jtv just said. [15:10] I am so sorry for opening this whole can of worms... :) [15:10] hehe [15:10] jtv: Not really, because it conflates sorting with getting a collation key. [15:12] Unfortunately, yes. But at least it will mark places where we tried to work around this! [15:12] ugh, bigger traceback. http://dpaste.com/573346/ [15:12] If you could help me figure out how to start lookig at zope traceback, I'd be very grateful. [15:14] nigelb: line 156 is the clue [15:17] hm, so I look at that template? [15:20] nigelb: it's telling you where the traversal failed [15:20] in view/sorted_subscriptions [15:20] ah [15:21] so I look at browser/specificationsubscription.py where sorted_subscriptions is seems to be defined [15:21] jtv, nigelb: There is already an agreed upon collation key function for people: lp.registry.model.person.person_sort_key [15:28] allenap: Oh. [15:28] * nigelb headdesks and rewrites. [15:29] nigelb: Hehe, don't worry, it's well hidden :) [15:33] nigelb: Fwiw, here's a diff of the changes I would make: http://paste.ubuntu.com/649234/ [15:34] allenap: thanks! [15:35] jcsackett: By the way, would you have time to review a branch of mine? https://code.launchpad.net/~allenap/launchpad/localpackagediffs-filter-by-package-set-bug-809786-overlay/+merge/68647 [15:36] allenap: as it happens, i would. :-) === al-maisan is now known as almaisan-away [15:36] jcsackett: Thanks :) [15:47] allenap: I can't import person_sort_key. [15:47] "ImportError: cannot import name person_sort_key" [15:48] nigelb: Yeah, there appears to be a circular import problem. In my diff I import it near where it's used and that works. [15:48] allenap: ah, but I also need to use it in 225-ish [15:49] nigelb: Yeah. See my diff :) [15:49] ah, right. Sorry. [15:49] I should learn to read :P === deryck is now known as deryck[lunch] [15:59] * nigelb grrs. [15:59] No traceback. But no worky either. [15:59] nigelb: Push your branch and I'll take another look. [16:08] Project db-devel build #741: FAILURE in 5 hr 40 min: https://lpci.wedontsleep.org/job/db-devel/741/ [16:09] allenap: pushed :) [16:11] allenap: are you planning on filing bugs for all these xxx's with "bug=???" ? [16:12] jcsackett: I suppose so... the sneaky part of my mind had tried to forget about that :) [16:12] allenap: if you'll file those bugs and update the XXX, r=me. i can go ahead and approve it now with that understanding. :-) [16:13] jcsackett: Thanks, that's awesome. [16:13] allenap: that's a nice trick with the auto re-aligning of the overlay, btw. i wonder why that's not default behavior. [16:13] jcsackett: I'll do the same with your review. [16:14] oh, thanks. [16:27] nigelb: Right, so is it not ordering correctly in the UI? === matsubara is now known as matsubara-lunch [16:28] allenap: no. [16:31] nigelb: SpecificationPortletSubcribersContents.sorted_subscriptions returns the subscriptions that can be unsubscribed by the user before those that the user cannot. Could that explain what you're seeing? [16:35] nigelb: I have to go very soon, but I'll be back later (at ~1900 UTC). I've subscribed to your branch so just update the mp with your notes and I'll take a look. [16:35] allenap: I'll do that :) === allenap changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett | Critical bugs: 241 - 0:[######=_]:256 === salgado is now known as salgado-lunch === beuno is now known as beuno-lunch [17:15] allenap: You were right. That's what I was seeing. === matsubara-lunch is now known as matsubara [17:40] thanks for the review allenap -- nice suggestions === beuno-lunch is now known as beuno === salgado-lunch is now known as salgado [18:35] I have a user asking what the contents of /etc/pkgbinarymangler/striptranslations.conf looks like for one of our P3A's -- can anyone assist with that, here? [19:02] bac: Cool, np. [19:03] nigelb: That's cool. I reckon your branch is nearly ready to land. If you incorporate the minor changes to the test I put in the diff I reckon it will be ready. [19:20] Project devel build #908: FAILURE in 5 hr 39 min: https://lpci.wedontsleep.org/job/devel/908/ [19:22] allenap: yeah, doign that now. [19:30] allenap: pushed :) [19:41] morning [19:43] cjwatson: stuff for the lp ppa? we only realy care about about lucid, natty and oneiric atm [19:43] nigelb: I'll land it for you. [19:45] allenap: thanks! Also thanks for hand-holding through this :) [19:47] nigelb: No worries, thanks for taking the time to do this. It's making Launchpad better. [19:47] allenap: Yeah, talking to jml at UDS helped a huge deal in getting off my mental block about patching launchpad :) [19:49] nigelb: jml's UDS seems to have been a big success. It's hard getting started on Launchpad, but I think it's rewarding; we should be able to release your fix tomorrow or Monday. [19:50] yay :) [19:50] Now I need to find out a way to have wallyworld's working hours and my awake hours and my free hours all to fall into the same slot. [19:51] * cody-somerville recommends a time machine. [19:51] cody-somerville: OEM's working on one of those, right? [19:51] I'm not at liberty to say, sorry. [19:54] sure you, just remember to go back in time and stop him asking about it [19:57] haha [20:01] nigelb: Your branch should land in a few hours once the full test suite has run. I'll check on it in the morning. I'm off now, cheerio. [20:03] allenap: laters! thanks again! [20:54] lifeless: no maverick? ok, that simplifies things a bit [20:55] though actually a bit late since I already did those backports :-) [20:55] oh well, will post things from debconf [20:59] cjwatson: its nice to have, but no dev uses it and we don't deploy on it [21:01] ok [21:04] things that go on biuldds obviously need to support all the flavours buildds do [21:04] but IIRC this isn't one of those [21:04] indeed not === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === matsubara is now known as matsubara-afk [21:33] lifeless: Yeah, this is just getting rid of the interfaces, as it was big enough. [21:34] lifeless: I plan to extract most of the target-specific stuff from lp.bugs. [21:34] Because it is pretty revolting. [21:43] Yippie, build fixed! [21:43] Project db-devel build #742: FIXED in 5 hr 35 min: https://lpci.wedontsleep.org/job/db-devel/742/ [21:49] sinzui: But won't a productseries milestone vocab only show milestones within that series, which is what we want here? [22:06] wgrant, I think that is what I am trying to understand. a productseries should only target to a milestone that belongs to a series. a product bug could be targeted to any milestone for any series [22:07] wgrant, there is not thing wrong with what you did. I just want to know WTF Lp thinks it is doing [22:09] It will all be moot when we simplify bugtasks to series. This vocab will be forced to have similar rules [22:09] sinzui: Right. [22:10] I feel that we should probably preserve existing behaviour for now. [22:10] This pipeline will already extend into 5 or 6 branches. [22:10] absolutely keep it the way it is. I just wanted to know if we know about this bug. Maybe it needs to be reported [22:16] Yeah. [22:16] Ah, you've approved it now. Thanks! [22:26] wallyworld: Should bug #806785 be closed? [22:26] <_mup_> Bug #806785: Person picker displays duplicate info when selecting recipe owner < https://launchpad.net/bugs/806785 > [22:27] wgrant: yes,. i believe so. i'll check. perhaps i didn't link to to the branch [22:27] It's linked, but maybe wasn't until too late. [22:27] i would have linked it before i did the mp [22:27] jtv: https://lpbuildbot.canonical.com/builders/lucid_db_lp/builds/1171/steps/shell_6/logs/summary <- I think your ArchiveCruftChecker refactoring might have made it spew crufty to stderr? [23:22] Argh. [23:22] Series tasks. [23:23] they will all be at some point [23:23] Yeah, but the current implementation is a bit unfortunate. [23:23] In particular, you can presently change the sourcepackagename of a series sourcepackage task through the web UI. [23:24] Probably want to forbid that. [23:25] (I'm working on pushing all target changes through transitionToTarget, which doesn't let you change to/from a series target, because that's what nominations are for) [23:26] Hmm, retargetting them breaks the UI a bit. [23:26] If there's no corresponding DSP task, the name is not shown at all. [23:26] lifeless: Any opinions? [23:28] uhm [23:28] StevenK, lp:~sinzui/launchpad/dsp-picker-fields [23:28] so big picture [23:29] we want users that have sufficient privilege to just move stuff around willy nilly [23:29] e.g. same-series different-sourcepackagename is a no-brainer change to permit everyone [23:29] The current model makes that hard, but when everything is a series task it will be easier. [23:30] SP tasks are not meant to exist without a corresponding DSP task. [23:30] The UI breaks. [23:30] we want users that have insufficient privilege to have to go through a handshake - the nomination process - for changes they are not permitted [23:31] wgrant: SP being DSSP really ? [23:31] lifeless: Right. [23:31] this sound slike a conjoined masterish thing [23:31] anyhow [23:31] Similar. [23:32] I have no particular opinion; I'd like that we move towards the big picture [23:32] I'd prefer we don't let broken things happen [23:33] if we permit something that breaks the model today, I have no objection to restricting it [23:33] I'd question restricting something that isn't restricted today. [23:34] (and doesn't cause breakage) [23:34] I haven't seen any breakage around (except for really old bugs like bug #43150), so I presume it's not done much or at all. [23:34] <_mup_> Bug #43150: [SRU] maxima frontends fail to connect < https://launchpad.net/bugs/43150 > [23:35] wallyworld, http://www.jslint.com/lint.html [23:39] lifeless: It is tempting to forbid it, and if someone complains then chastise them and potentially hack transitionToTarget to permit changing to another SP in the same DS. [23:43] does it break things no matter what ? [23:43] or does it break things under some circumstances only ? [23:43] Unless you change all of them at once. [23:45] Meh, for now I will special-case permit it.