[00:07] <nacc> cjwatson: is it possible that the redirect for when a http/https repo doesn't exist requires auth?
[00:07] <nacc> cjwatson: i think that's what i'm seeing right now, but am curious
[00:08] <nacc> i'll debug it more tmrw
[00:08] <wgrant> nacc: On cgit that's correct.
[00:09] <wgrant> nacc: We can't expose the difference between a private repo that you can't see and a non-existent repo.
[00:10] <wgrant> nacc: Does this mean you're using cgit programmatically?
[00:13] <SXX> wgrant: sorry for bothering you, but is it possible to build from git repository with submodules on Launchpad?
[00:14] <SXX> I can't find any information how to make Launchpad clone local git (pre-imported to git on Launchpad) repository recursively.
[00:14] <wgrant> SXX: Using a source package recipe?
[00:16] <SXX> wgrant: isn't git-build-recipe it?
[00:16] <wgrant> SXX: Yep, just checking which particular technology you were using
[00:18] <wgrant> SXX: Recipes don't support submodules, but you can use the "nest" and "nest-part" commands to achieve equivalent behaviour.
[00:18] <SXX> wgrant: so only way to use submodule is to nest some another repository? Thank you!
[00:21] <SXX> wgrant: one more little question. Should I post about PPA space increase on Launchpad or could I ask it here?
[00:21] <SXX> https://launchpad.net/~vcmi/+archive/ubuntu/ppa/+packages
[00:21] <wgrant> SXX: Usually on answers.launchpad.net/launchpad, but I've increased that one for you here
[00:23] <SXX> 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] <wgrant> SXX: A separate package for a dependency often makes sense, yep.
[00:26] <SXX> 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] <SXX> Only wish there were warning about lack of submodule support so there no real point to convert from bzr to git :-)
[00:28] <SXX> 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] <nacc> wgrant: this was `git fetch` reporiting that for a url with https in it
[00:28] <nacc> wgrant: need to think about how to do this in the importer
[00:28] <nacc> wgrant: git:// correctly just returns no objects
[00:30] <wgrant> nacc: Yeah, unfortunately due to HTTP there's no other option.
[00:30] <wgrant> You'll find the same behaviour on all other HTTPS git servers that implement proper privacy
[00:30] <wgrant> The client won't even try to send auth unless we send a 401
[00:32] <nacc> wgrant: interesting, i may have to undo our defaults (i switched to https at cjwatson's advice) :)
[00:33] <nacc> cjwatson: --^ so the above is a reason to use git://
[00:34] <wgrant> 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] <wgrant> nacc: I wonder if you can configure git to not even ask for auth for a given location
[00:34] <nacc> wgrant: yeah that was why we switched (recently) :)
[00:35] <nacc> wgrant: i'm looking in the git code to see if i can ask it not to auth
[00:35] <nacc> wgrant: as in general, this is for fetch, and readonly anyways
[00:35] <nacc> (as a first pass)
[00:35] <wgrant> nacc: Readonly is just as bad.
[00:35] <nacc> wgrant: i meant still use https
[00:35] <wgrant> Because someone clones a compromised version and then dputs it to the primary archive
[00:35] <nacc> wgrant: but have it just fail on 401
[00:35] <wgrant> Ah right
[00:35] <wgrant> Yep
[00:35] <wgrant> That would be ideal.
[00:35] <nacc> rather than retry
[00:35] <nacc> i'll look and maybe i can push something upstream
[00:36] <nacc> heh
[00:37] <nacc> $ GIT_TERMINAL_PROMPT=0 git fetch nacc
[00:37] <nacc> fatal: could not read Username for 'https://git.launchpad.net': terminal prompts disabled
[00:37] <nacc> now that's hacky :)
[00:38] <nacc> wgrant: but i could wrap the above in our methods and that'd get us further, at least
[00:39] <wgrant> nacc: Sounds plausible. Let us know if that doesn't work out.
[00:41] <nacc> wgrant: thanks
[13:41] <dwrdj> 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
[13:55] <cjwatson> dwrdj: What error message exactly?
[13:56] <dwrdj> 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] <cjwatson> dwrdj: Does it give you an OOPS ID?
[13:57] <dwrdj> (Error ID: OOPS-d05c32cd68f14335080020848e3ef87d)
[13:58] <cjwatson> Just a moment.
[14:04] <cjwatson> 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] <dwrdj> Ah OK. Thank you very much
[23:35] <nacc> 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] <nacc> and override the use of mirrors/masters in those classes?
[23:36] <nacc> I think that will cause us to fall back to _lp_url internally in _source_urls in SourcePackage
[23:59] <wgrant> nacc: I think that probably makes sense.