[00:07] cjwatson: is it possible that the redirect for when a http/https repo doesn't exist requires auth? [00:07] cjwatson: i think that's what i'm seeing right now, but am curious [00:08] i'll debug it more tmrw [00:08] nacc: On cgit that's correct. [00:09] nacc: We can't expose the difference between a private repo that you can't see and a non-existent repo. [00:10] nacc: Does this mean you're using cgit programmatically? [00:13] wgrant: sorry for bothering you, but is it possible to build from git repository with submodules on Launchpad? [00:14] I can't find any information how to make Launchpad clone local git (pre-imported to git on Launchpad) repository recursively. [00:14] SXX: Using a source package recipe? [00:16] wgrant: isn't git-build-recipe it? [00:16] SXX: Yep, just checking which particular technology you were using [00:18] SXX: Recipes don't support submodules, but you can use the "nest" and "nest-part" commands to achieve equivalent behaviour. [00:18] wgrant: so only way to use submodule is to nest some another repository? Thank you! [00:21] wgrant: one more little question. Should I post about PPA space increase on Launchpad or could I ask it here? [00:21] https://launchpad.net/~vcmi/+archive/ubuntu/ppa/+packages [00:21] SXX: Usually on answers.launchpad.net/launchpad, but I've increased that one for you here [00:23] wgrant: thank you very much! I'll see how I could use nesting here and might be extract our dependency into separate package, after all it is extracted by our Debian maintainer. [00:23] SXX: A separate package for a dependency often makes sense, yep. [00:26] wgrant: yeah I know, but it's would also increase needed maintenance of PPA and submodule require none. Anyway thanks for your time. That's much of help! [00:26] Only wish there were warning about lack of submodule support so there no real point to convert from bzr to git :-) [00:28] Since I seen our build broke due to submodule usage, then seen Launchpad now support Git and supposed I'll bypass the problem this way. [00:28] wgrant: this was `git fetch` reporiting that for a url with https in it [00:28] wgrant: need to think about how to do this in the importer [00:28] wgrant: git:// correctly just returns no objects [00:30] nacc: Yeah, unfortunately due to HTTP there's no other option. [00:30] You'll find the same behaviour on all other HTTPS git servers that implement proper privacy [00:30] The client won't even try to send auth unless we send a 401 [00:32] wgrant: interesting, i may have to undo our defaults (i switched to https at cjwatson's advice) :) [00:33] cjwatson: --^ so the above is a reason to use git:// [00:34] nacc: You should definitely use HTTPS because git:// is an awful protocol that has no reason to exist and is insecure as anything. [00:34] nacc: I wonder if you can configure git to not even ask for auth for a given location [00:34] wgrant: yeah that was why we switched (recently) :) [00:35] wgrant: i'm looking in the git code to see if i can ask it not to auth [00:35] wgrant: as in general, this is for fetch, and readonly anyways [00:35] (as a first pass) [00:35] nacc: Readonly is just as bad. [00:35] wgrant: i meant still use https [00:35] Because someone clones a compromised version and then dputs it to the primary archive [00:35] wgrant: but have it just fail on 401 [00:35] Ah right [00:35] Yep [00:35] That would be ideal. [00:35] rather than retry [00:35] i'll look and maybe i can push something upstream [00:36] heh [00:37] $ GIT_TERMINAL_PROMPT=0 git fetch nacc [00:37] fatal: could not read Username for 'https://git.launchpad.net': terminal prompts disabled [00:37] now that's hacky :) [00:38] wgrant: but i could wrap the above in our methods and that'd get us further, at least [00:39] nacc: Sounds plausible. Let us know if that doesn't work out. [00:41] wgrant: thanks === chihchun_afk is now known as chihchun === StevenK_ is now known as StevenK === caribou_ is now known as caribou === chihchun is now known as chihchun_afk [13:41] Hello. Would somebody be able to help me please? Every time I try to log in to Launchpad from SSO it shows an error message === JanC_ is now known as JanC [13:55] dwrdj: What error message exactly? [13:56] Oops!Sorry, something just went wrong in Launchpad.We’ve recorded what happened, and we’ll fix it as soon as possible. Apologies for the inconvenience. [13:56] dwrdj: Does it give you an OOPS ID? [13:57] (Error ID: OOPS-d05c32cd68f14335080020848e3ef87d) [13:57] https://oops.canonical.com/?oopsid=OOPS-d05c32cd68f14335080020848e3ef87d [13:58] Just a moment. [14:04] dwrdj: Should work now. (There was an automatically-created stub user record for you because your email address was mentioned in a source package upload, and we had to merge that into your real account.) [14:05] Ah OK. Thank you very much [23:35] cjwatson: wgrant: thanks for the help yesterday re: git/https, we have something working for now. I had a new question. We realized recently that ubuntutools.archive.{Debian,Ubuntu}SourcePackage only "fallback" to Launchpad when it can't find the files it needs on deb.debian.org/archive.ubuntu.com. Given that we really only want to trust LP in the importer, would it make the most sense for us to subclass [23:35] and override the use of mirrors/masters in those classes? [23:36] I think that will cause us to fall back to _lp_url internally in _source_urls in SourcePackage === benjaomi- is now known as benjaoming [23:59] nacc: I think that probably makes sense.