[01:01] wgrant: StevenK: one of you may wish to tag or tag n dup bug 982539 [01:01] <_mup_> Bug #982539: Losing access to private bugs recently < https://launchpad.net/bugs/982539 > [04:08] wgrant: I believe 163 TypeError: is not JSON serializable is yours ? [04:11] lifeless: StevenK's and harmless. [04:12] wgrant: its in the report, if its expected it shouldn't, otherwise it should be fixed. [04:12] s2n fail otherwise [04:12] StevenK: ^ [04:12] Of course. [04:13] But it's harmless so it's not being fixed as utmost priority. [04:53] lifeless: Not working today. [04:53] kk [04:54] lifeless: The bug has been marked as disclosure, so it's on our roadmap. I expect Curtis will get me to fix it after I finish the bug transistion to information type. [07:20] Something is broken with mp comments [07:21] The first time I submitted some comments it updated the page with my comments, but lost them on page refresh [07:22] When I returned and rewrote my comments and submitted it updated the page correctly again, but this time on refresh it had double submitted my comments (I only pressed Save Comment once) [07:23] oh and the text was different between the two submissions so the double paste wasn't just my old text appearing [07:23] oh wait, I'm lying [07:23] ignore me :) [07:24] something weird is going on with caching or something [07:24] I'll get me coat [08:14] aloha [09:03] good morning === almaisan-away is now known as al-maisan [10:41] morning === al-maisan is now known as almaisan-away [12:18] lifeless, hey, remember I told you last week that there was a really obscure difference in behavior between Invalid and Won't Fix, but I couldn't remember what it was? I just found it -- it's described in bug 196500. [12:18] <_mup_> Bug #196500: Unexplained that only "Won't Fix" series status makes main bug status changeable

< https://launchpad.net/bugs/196500 > [12:37] mpt: Interesting that even you forget that one! [12:53] wgrant, you mock me [12:59] jml, do you have any predictions for when your recent testtools MPs will land? We are working from them for our own changes and relying on them. Having them merged would be ideal; failing that, having you maintain a fully merged and up-to-date version of those three branches would be nice; failing that we will plan to do it. https://code.launchpad.net/~jml/testtools/tagger/+merge/101904 , https://code.launchpad.ne [12:59] t/~jml/testtools/wrap-result-in-concurrent-suite/+merge/101902 , https://code.launchpad.net/~jml/testtools/tsfr-fixup/+merge/101898 [13:23] abentley: is there a way to get a nice list of files changed with bzr diff? [13:23] rick_h: bzr st [13:25] StevenK: ah cool, bzr diff --help only shows --stat-dir [13:25] rick_h: as StevenK says, you want "bzr stat" for that. I prefer the --short output, which is also more scriptable. [13:25] rick_h: Actually, it says "see also: status" [13:26] abentley: ah true. but bzr diff --stat --old=... works but isn't in the list [13:26] but yea, gotcha [13:26] rick_h: which list? the see also list? [13:27] rick_h: bzr diff --stat does not work for me. [13:27] abentley: the Option: in --help [13:27] bzr diff --stat --old=../devel just got me some info [13:28] looks like a lot more than I changed though so looking at what it's grabbing [13:28] rick_h: which version of bzr are you using? [13:28] abentley: 2.5.0 it looks like [13:29] abentley: 2.5.0 it looks like [13:32] rick_h: bzr status -r ancestor:../launchpad-trunk [13:42] bzr st -rsubmit: :) [13:48] nice, thanks guys, exactly what I was looking for [13:48] time to add an alias [14:38] sinzui: hello :D [14:38] I swear one of these days I won't come looking for you over privacy bugs [14:38] hey, IRC really works. I think my ISP is disabling DNS when U1 sync on enabled [14:39] sinzui: at the packet level? [14:39] not sure [14:39] sinzui: or just your isp dns servers don't like to respond to you? [14:39] as in just set your own dns to 8.8.8.8 or whatever to get around? [14:39] The who house was affected. I yesterday and today was fixed by me disabling u1 on all the computers [14:40] strange [14:40] gary_poster: they are blocked on lifeless [14:40] ish [14:40] sinzui: know the feeling when in ireland i disbale U1 sync as it kills my connect :/ [14:40] gary_poster: but I can land them tomorrow, I guess. [14:41] roll on when I go back to uk it'll all be up to date again [14:41] czajkowski, did you try limiting the upload to 50kb/s [14:42] yup doesnt really help not a great connection but does the job just not for U1 syning without killings things badly [14:42] sinzui: one for you https://bugs.launchpad.net/launchpad/+bug/982539 [14:42] <_mup_> Bug #982539: Losing access to private bugs recently < https://launchpad.net/bugs/982539 > [14:45] czajkowski, this must be related to the regression where th proper people are not subscribed [14:46] czajkowski, you will need to follow up with the reporter to as an admin to subscribe the bug supervisor to the bugs. I will add this issue to the purple squad's queue [14:46] okie dokie thanks sinzui [14:47] sinzui: next monday I promise no privacy bug issues :) [14:47] czajkowski, I am updating the bug to ask if this has happened in the last 8 hours...we released a change to address the previous regression [14:47] maybe this bug is aa dupe [14:48] k [14:48] czajkowski, oh, I see jcsackett has not landed the fix [14:49] jcsackett, what is blocking Bug #967115 [14:49] <_mup_> Bug #967115: Cannot set a bug private is the bug supervisor is not set < https://launchpad.net/bugs/967115 > [14:49] sinzui: a host of tests that i missed that i need to read through to update/delete. [14:49] in the process of that now. [14:50] thank you. [14:50] sinzui: jcsackett thanks folks [15:02] jml, tomorrow would be great, thanks [15:13] gary_poster: if lifeless reviews the branches during his working day, that would be the ideal for me. [15:13] gary_poster: but I'll land either way [15:13] jml, cool thanks [15:38] jtv: if you have a minute, review of my fix for my screw-up in https://code.launchpad.net/~cjwatson/launchpad/remove-query-distro-pending-suites/+merge/102129 would be great [15:39] cjwatson: you realize it's close to 23:00 on a public holiday? :) [15:39] No :-) [15:39] Feel free to say no then ;-) [15:40] I find timezones are a disease I frequently develop immunity to, and so often forget the exact ways in which other people are afflicted. Doubly so for holidays. [15:41] Are inoculations available? [15:41] Anyway, the new code looks to my eye suspiciously like what I suggested, but the old code looks suspiciously like what it said _before_ the branch I reviewed. What gives? [15:41] http://www.whittard.co.uk/coffee [15:42] Ah, the distroarchseriesID column on the model class. [15:43] 'distroarchseries_id' => 'distroarchseriesID' was more or less the change from your review to my first merge; then in the second merge, add the missing [] and add the ID to the interface [15:43] http://bazaar.launchpad.net/~cjwatson/launchpad/remove-query-distro-pending-suites/revision/15104 is the difference [15:44] ahh [15:45] (I couldn't find any documentation of these magic ID attributes, and had to zen it from the surroundings.) [15:47] Yeah, it's pure cargo cult I'm afraid. [15:47] Anyway, I've filed my review. [15:49] mkay, thanks [15:49] * cjwatson fixes and goes to land [15:49] (Can I set it to Approved myself once it has an Approve review and I'm ready to land it?) [16:01] Oh, there we go, my logs say I asked about that a few months back [16:01] 2011-12-20.log:14:02 cjwatson: generally the MP initiator sets it to approved, sometimes they might be getting a DB review too or a UI approval [16:02] 14:07 benji: ah, and I can't set the MP to Approved because I'm not in ~launchpad [16:02] So could somebody set https://code.launchpad.net/~cjwatson/launchpad/remove-query-distro-pending-suites/+merge/102129 to Approved for me so that I can land it, please? [16:02] cjwatson: OK, I'll do it [16:02] Thanks - I do have landing access now, but not ~launchpad === salgado is now known as salgado-lunch === deryck is now known as deryck[lunch] [17:30] webops ping Hi I want to make launchpad.net/charms series 'precise' the dev focus now, I need a LOSA to do that. Thanks! [17:36] SpamapS: so you want /charms/precise set to "Active development" correct? [17:37] thedac: right, I was told this is the process for that: https://wiki.canonical.com/InformationInfrastructure/OSA/LPHowTo/BranchUbuntu [17:37] SpamapS: ah, ok [17:38] thedac: one thing I'm a little nervous about... [17:38] thedac: it won't overwrite branches that already exist for the target series, will it? [17:39] SpamapS: I would not think so but that may be a question for another LP dev [17:39] thedac: I'll read the script.. please standby [17:39] sounds good [17:41] except BranchExists: [17:41] pass [17:41] on the surface, looks good === salgado-lunch is now known as salgado [17:48] hiho [17:48] is it possible to have a private distribution in LP [18:06] thedac: ok, looks good [18:06] thedac: so I think it would be smoething like './branch-distro.py -v charms oneiric precise [18:06] SpamapS: ok, one moment === deryck[lunch] is now known as deryck [18:10] olli: not at the moment [18:10] olli: you can have private PPAs which may be enough [18:12] SpamapS: I am getting a connection error: https://pastebin.canonical.com/64350/ [18:12] checking now [18:16] thedac: reading [18:18] SpamapS: connectivity to the dbs looks good. I am not sure why that is failing [18:22] thedac: haven't seen the error yet, had to go get my phone for 2factor auth ;) [18:23] ok [18:24] thedac: whoa, does that have to be run on the db master directly? [18:24] oh wait thats pgpool right? [18:25] port 5432 is postgres 5433 would be pgbouncer [18:25] connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"? [18:25] wouldn't that be.. a local server? [18:25] so it must not be picking up the correct config [18:26] we probably need an LPCONFIG=... before the command [18:29] SpamapS: that was it is running now [18:29] thedac: sweeeet [18:31] SpamapS: completed: https://pastebin.canonical.com/64352/ [18:33] thedac: thanks. There must be some other process to make precise the active (not Experimental) series [18:34] Yes, I can set that in the UI. That was my first question [18:36] is it just that a LP admin needs to change it? [18:36] SpamapS: ok, the precise series is now active [18:36] perfect [18:40] thedac: so.. some last step is missing. lp:charms/* is still oneiric [18:40] anybody know? [18:41] hm maybe not [18:42] SpamapS: yeah, I am not sure what needs doing at this point [18:42] thedac: never mind that seems to be good, lp:charms/* is in fact precise now [18:42] ah, cool [18:42] The only weird thing now is that under "Active series and mielstones" only 11.10 shows [18:43] SpamapS: I suspect this is a timing problem. Let's give it 15 minutes and check back [18:43] thedac: sounds good :) [18:45] deryck: ping [18:45] rick_h, hey hey [18:46] deryck: ok, stuck again, but this should be the last one [18:46] deryck: http://paste.mitechie.com/show/620/ chasing down the oauth bits and how they work [18:46] rick_h, don't worry about it. looking.... [18:46] deryck: let me know if it would be easier to hop on a call [18:46] basically trying to find when new oauth tokens take flight, and having issues tracing where the person bit comes into play [18:47] it *appears* that not until it's been reviewed/ok'd by the user, but that doesn't make sense else how does the user see their list of unapproved tokens [18:47] rick_h, ok, let me look at this paste and code.... [18:48] deryck: rgr [18:55] rick_h, have you seen lib/lp/services/oauth/stories/authorize-token.txt ? [18:57] deryck: no was working my way from code -> test [18:57] deryck: but this seems nice and step by step'd so will go through it [18:57] thanks [18:57] rick_h, np. you can also grep zcml for +authorize-token to find the view. [18:58] yea, I went from teh view into the model bits [20:53] salgado: ping [20:53] hi czajkowski [20:54] salgado: are you still working on bllueprints? [20:54] salgado: not sure if you are https://bugs.launchpad.net/launchpad/+bug/983309 [20:54] <_mup_> Bug #983309: Cannot read blueprints' titles when the dependecy tree is large < https://launchpad.net/bugs/983309 > [20:55] czajkowski, u1 has captured salgado and has no plans of releasing him again [20:55] beuno: ello and good evening to you [20:55] czajkowski, not anymore, no [20:55] salgado: grand job [20:56] czajkowski, the Linaro infrastructure team is still on the hook for any issues related to work-items in LP, but I don't think this would qualify [20:57] nods [20:57] czajkowski, however, that bug was filed by someone from Linaro so they might end up fixing it too [20:58] czajkowski, jamestunnicliffe has taken over the work-items stuff, btw [20:59] salgado: good to know [21:00] i'm pretty sure that bug is a duplicate fwiw [21:01] https://bugs.launchpad.net/launchpad/+bug/576807 [21:02] <_mup_> Bug #576807: blueprint dependency graph is too small and unreadable < https://launchpad.net/bugs/576807 > === salgado is now known as salgado-afk [21:55] thedac: hi, I'm working with SpamapS to promote our charms up to precise [21:55] thedac: we've still got some problems with the branch names after what you/clint did a couple of hours ago [21:55] thedac: do you have a sec to help with that? [21:55] m_3: sure [21:56] so the lp aliases are lp:charms/ which now points to lp:~charmers/charms/precise//precise [21:57] they should be pointing instead to lp:~charmers/charms/precise//trunk [21:57] I can push them to .../trunk and then promulgate which updates the alias to point to the correct branch [21:58] ok, let me see if I can do anything in the UI [21:58] however, that results in the alias pointing to .../trunk which is stacked on top of .../precise [21:58] then it won't let me remove the .../precise branches [21:59] thedac: I'm not sure what to do with it... I would guess that we could fix the aliases if we just had a mass rename of the aliased branches to .../trunk [22:01] lp:charms/sbuild is an example of one I tried to fix manually [22:01] m_3: I am not seeing a way for me to change that. I would guess the update script did this. [22:01] Anyone else have an idea what we can do? ^^^^ [22:01] * m_3 really clueless about that... lp newb [22:01] It sounds likely that branch-distro would have set things up this way [22:02] Give me a charm name that hasn't had manual fixing attempts to look at? [22:02] lp:charms/mongodb [22:03] it used to point to lp:~charmers/charms/oneiric/mongodb/trunk for the oneiric versions [22:03] clint ran some branch-distro script and now it points to lp:~charmers/charms/precise/mongodb/precise [22:03] Right, that'd be branch-distro at work [22:04] gotcha [22:04] Does it matter that the branch name is rather than "trunk" ? [22:04] gustavo's charm store looks exclusively for .../trunk branches though [22:04] ah [22:04] Well, fixing it all up ought to be fairly easy with a launchpadlib script [22:05] And you'd need to get a fix into branch-distro for the q-series opening [22:06] oh, ok... I'll go read up on launchpadlib. The manual changes created .../trunk stacked on .../precise which left dangling branches around that I couldn't clean up. I assumed that launchpadlib would just do the same basic thing [22:07] m_3: Presumably after you pushed the sbuild/trunk you did something to make it the official branch for precise? [22:08] Well, you don't want to use launchpadlib to create new branches, you want to use it to rename the existing ones [22:09] maxb: yes... our promulgate script (have to look to see what it does)... essentially creates the lp:charms/sbuild alias for the branch [22:10] maxb: ok, looking for rename [22:10] * m_3 and hoping clint returns from lunch soon :) [22:10] maxb thedac: thanks! [22:10] m_3: no problem [22:12] m_3: can you "re-promulgate" the ~charmers/charms/precise/sbuild/precise branch and delete the current .../trunk one? [22:13] maxb: sure... one sec [22:15] maxb: done [22:16] lp:charms/sbuild points to lp:~charmers/charms/precise/sbuild/precise again [22:16] If you have a "Change branch details" link in the right-hand portlet of https://code.launchpad.net/~charmers/charms/precise/sbuild/precise you can use that to change the name to trunk [22:17] Oh [22:17] there's a rename?! [22:17] yes :-) [22:17] maxb: ok, did that... poking around now [22:17] fantastic [22:18] can we map that to launchpadlib calls? [22:18] Give me 5 minutes, I'll whip up a launchpadlib script to do the rest in bulk [22:18] * SpamapS has just noted that maxb is his hero [22:18] SpamapS: can you try out sbuild from the store for precise now? [22:18] * m_3 no free envs atm [22:19] SpamapS: actually, nevermind... that worked! [22:20] m_3: woot [22:22] Give http://paste.ubuntu.com/933212/ a try .... a little difficult for me to test without a fake Launchpad, but I think it should work [22:25] it successfully complains about me not having access to edit the charms branches, anyway :-) [22:27] SpamapS, m_3: Why do you have the custom naming scheme? [22:27] branch-distro is not designed to do that. [22:27] Why doesn't juju use the alias? [22:27] maxb: Yikes... it did a couple, then I got an IntegrityError [22:28] m_3: There's probably already one with that name. [22:28] wgrant: right... excepting that case [22:28] wgrant: I don't know why the custom name is needed [22:29] wgrant: no idea on the name [22:29] m_3: probably statusnet [22:29] wgrant: Something about using get_branch_tips, which I don't believe shows the aliases [22:31] m_3: ok, my script is only acting on branches matching ~charmers/charms/precise/*/precise, so just manually resolve the duplication issue for that particular charm, then re-run; it won't go back over ones it has already renamed [22:31] wgrant: also we do actually use the name to specify charms to deploy via the store or not for non-official charms. [22:31] I agree with wgrant that using the aliases would make far more sense, but this way we can work with the existing hardcoded assumptions for now [22:31] wgrant: so lp:~clint-fewbar/charms/precise/puppet/trunk is a signal to the charm store to pick that charm up, but lp:~clint-fewbar/charms/precise/puppet/in-progress would not be published [22:31] wtf [22:32] That is, um, intriguing. [22:32] SpamapS: That seems a bit.... wrong. LP already has a concept of official-ness, which is what drives the aliases. Why not use that, rather than some odd naming convention? [22:32] I would prefer that we use the branch metadata, and only ship 'Mature' branches [22:32] maxb: we want users to be able to say something is official without access to the whole distro [22:33] maxb: its only official in their personal namespace. [22:33] so it becomse cs:~clint-fewbar/precise/puppet [22:33] (cs is the charmstore) [22:33] * maxb has trouble grappling with the idea of "official in a personal namespace" [22:33] maxb: think PPA [22:33] I suspect it means "stable" [22:33] Which is what Mature means [22:33] its as official as a package pushed to a PPA [22:33] which means, not very :) [22:34] I think we should move it to using the Mature status instead [22:34] ok, script ran... only a couple of pre-existing branches [22:34] Surely "trunk" is exactly the wrong name to use to mean "Mature" ? :-) [22:34] and drop the trunk thing altogether [22:34] maxb: depends on whether you are dev or ops ;) [22:34] I'm devops :-) [22:34] then you ship trunk, after it passes tests [22:35] s/trunk/ripe/ perhaps [22:35] thedac maxb wgrant: thanks! [22:37] m_3 / SpamapS: Well, I guess you'll figure something out... just remember that branch-distro is going to copy whatever is marked as official to a branch named next cycle [22:37] sinzui: http://pastebin.ubuntu.com/933230/ [22:39] maxb: I'm opening a bug that we should ship all "Mature" branches, not just those named 'trunk' [22:40] bug #983530 to be exact [22:40] <_mup_> Bug #983530: charm store should publish all 'Mature' branches. < https://launchpad.net/bugs/983530 > [22:42] There appear to still be 5 branches named ~charmers/charms/precise/*/precise, btw [22:43] Also, branch-distro has its own ideas of how it should manipulate branch lifecycle status, so you'll want to watch out for that [22:45] <[reed]> who is an appropriate contact for launchpad's bugzilla integration nowadays? [22:53] StevenK, wgrant, wallyworld, jcsackett: http://blog.launchpad.net/general/a-tale-of-two-travesties [23:03] maxb: Right, I noticed they all are set to 'Development', which makes sense.. we really want them to be Mature if the one they copied from was Mature. [23:04] maxb: we might need some alternative behavior flags for our use case... but I bet it takes us a year before we have a patch for LP ;) [23:13] SpamapS: Fortunately all the code you care about here is localized in one file, eliminating much of the usual scaryness of chasing around the LP codebase [23:13] lib/lp/codehosting/branchdistro.py ftr [23:13] maxb: its more about the scariness of chasing down our time to get 'er done [23:14] Aww. It's really just a fairly simple Python script once you learn to look past the "Eek! Launchpad!" factor :-) [23:14] so I think this is a bug in branch-distro [23:15] if I push to lp:charms/somethingnew [23:15] I get lp:~myuser/charms/precise/somethingnew/trunk [23:15] I should reasonably expect that branch-distro would duplicate that behavior, and not call a copy of that by the series name, but 'trunk' again. [23:15] hm [23:16] You do rather have a point there, that the two components of Launchpad ought to at least be consistent [23:16] this is causing enormous pain now because the official branches for things like rabbitmq-server were forked, and already existing as lp:~something/charms/precise/foo/trunk [23:16] which were not seen as BranchExisting errors. :-P [23:17] why is this causing enormous pain? A mild discomfort akin to a stone in your shoe, I would have thought :-) [23:17] SpamapS: Ubuntu doesn't use the push-to-alias code, so it doesn't work well for distros. [23:17] SpamapS: That's designed for projects. [23:18] s/push-to-alias/push-to-new-alias/ [23:18] indeed, I think we are breaking new ground.. and have happily found an inconsistency :) === matsubara is now known as matsubara-afk [23:19] wgrant: I assume the package importer does the new branch creation manually then. [23:20] SpamapS: Right. [23:21] so either push to new alias code should use series name in distros, and we should fix the charm store (seems the low impact way) or branch-distro should have a new option --branch-name to override the default of $series [23:22] I do *not* like the idea of hacking branch-distro. It is utterly the wrong place. [23:22] Even better would be that a new flag would be added to the distro object to note that it has charms in it, and change the behavior. [23:22] Because there are other things that look weird in launchpad.net/charms because we're not storing packages there [23:22] like, it would be cool to be able to say +charm instead of +source .. [23:23] and to drop the warnings about a package that has never been published [23:23] wgrant: https://code.launchpad.net/~stevenk/launchpad/forbid-proprietary-api/+merge/102201 since we're off the call. [23:25] SpamapS: I objected pretty strongly to using distros in the first place :) [23:25] StevenK: Won't that break like a million tests? [23:25] Hm. Maybe a few. [23:26] wgrant: you'd prefer we have each charm as a project? Or a giant single bzr branch of all the charms? [23:26] When I've done QA for r15103 (which will be tomorrow) and everything up to there is deployable, should I remove that deployment exception entry from LaunchpadProductionStatus on the grounds that any future deployment will be >=15103, or is there some other protocol for letting people know that that deployment exception can go away? [23:26] wgrant: we've already used the cross-charm capability to track bugs that affect multiple charms. And each charm in a branch gives us the ability to delegate permissions very effectively. [23:27] cjwatson: Leave it there, just in case. [23:27] Other than the fact we have vast precedent, why does it make sense to use the series name as the branch name for default distro branches? [23:27] cjwatson: Although I'll likely be deploying 15103 before you wake up. [23:27] Oh, there's a Comments column [23:27] wgrant: ah, well, if you want to do the obvious QA on it then fine by me [23:28] maxb: I like to think that one day we will make project and distribution branch models not gratuitously divergent. [23:28] maxb: Probably by removing the distroseries from the URL [23:28] um? [23:28] This would make that easier, although it's probably not the reason. [23:29] maxb: The distro branch namespace is divided up by series. Project branch namespaces aren't. [23:30] If we ever want to make these consistent, it's possibly handy to keep the branch names fairly unique like that. [23:30] Oh, I see what you mean now [23:30] wgrant: +1 [23:30] (of course I basically completely disagree with how distro branches work, but it's probably a bit late to make big changes) [23:31] But this change is reasonably inoffensive and sensible, so might happen in a few years. [23:31] It would be the incompatible change from hell, but it has a certain sense to it [23:31] wgrant: what's your fundamental problem with them, just that they're so different from project branches? [23:32] for the record, as an ubuntu developer and charm developer, I really like the way distro branches work :) [23:32] though I would prefer to have automatic population of -updates and -proposed for ubuntu so merge proposals for SRU's works properly [23:34] I'm not sure I'd want -updates and -proposed to pop into existence for every package with identical content to the release pocket, for *every package* [23:35] we sort of want them to autovivify when pushed to. which is not exactly trivial. [23:35] On the other hand, if you don't do that, you kind of need the ability to file a merge proposal onto a target branch which doesn't exist yet [23:35] I'd be happy if they were just seen as aliases to the main package, until they were actually published/pushed to [23:35] pushed to> or otherwise referenced as an lvalue [23:35] if I may shamelessly borrow terms [23:35] It's a good term :-) [23:38] jelmer: They make collaboration between distros hard -- in reality they will eventually just be minor branches of the upstream code, but they're all completely segregated and invisible to the upstream project. [23:38] jelmer: Most packages would do fine without a separate namespace in the distro. [23:38] They could just be specially linked branches in the project. [23:39] wgrant: that doesn't seem like a fundamental problem though, mostly a presentation issue [23:39] The hard split between debian and ubuntu isn't great [23:40] On the other hand, yes, it's really just a presentation problem [23:41] Perhaps. [23:41] .. and an issue with the importer, which doesn't take upstream links into account when it generates file ids or ancestry [23:41] * SpamapS wonders if we'll ever get all these worms back in the can [23:43] with sensible heuristics, and perhaps some support for handling parallel imports there is a lot we can do [23:43] that's a nontrivial amount of work though [23:44] wgrant: I think you're right that it will break a few tests. But I'd like it to break for users. :-( [23:44] StevenK: Also, that error message is entirely useless. [23:44] I can't transition to proprietary because I can't transition to proprietary :( [23:49] * StevenK isn't sure how to check if it's from the API. [23:49] In fact, I'm not certain if you can. [23:49] You can't directly. [23:50] Hm, can't think of a way to solve this then. That's disappointing. [23:50] You could add a from_api argument or something [23:52] lol @ But this change is reasonably inoffensive and sensible, so might happen in a few years. [23:52] wgrant: Or I could fix it differently and allow it only if the pillar has private_bugs. [23:52] timrc: you've not met wgrant before? [23:52] StevenK: But that's wrong. [23:52] timrc: :P [23:53] wgrant: I thought that was the plan? [23:53] jelmer, No, I hope he takes his comedy act on the road though :) jk [23:53] StevenK: "plan" being the important word here [23:53] StevenK: Future. [23:53] Keeping in the mind the plan is somewhat elastic. :-) [23:53] The plan is fairly well defined in only slightly conflicting ways in the minds of sinzui and myself.;