=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
[08:23] <alkisg> Hi, I'm trying to create a recipe for 2 git branches but it fails, could I have some help please? https://code.launchpad.net/~alkisg/+recipe/ltsp+debian-packaging
[08:24] <alkisg> nest-part packaging lp:~alkisg/+git/ltsp-debian debian debian disable-upstreamed-patches => this pulls the folder "debian" from branch "disable-upstreamed-patches" and puts it into a folder named "debian", right?
[08:30]  * alkisg tries removing the branch name completely, while setting it as the default in the branch options...
[08:31] <cjwatson> Looks like it *should* work.  Maybe worth trying to run git-build-recipe locally.
[08:31] <alkisg> Thank you cjwatson, will try that locally
[08:34] <alkisg> cjwatson: it worked on launchpad when I removed the branch name. The correct syntax is to put the branch name in the end, and NOT like this, right? "nest-part packaging lp:~alkisg/+git/ltsp-debian disable-upstreamed-patches debian debian"
[08:36] <alkisg> Ah, in the repository options, I also changed "Default branch", from "refs/heads/master", which was the default there but didn't exist at all, to "refs/heads/disable-upstreamed-patches"
[08:36] <alkisg> One of those 2 changes made it work...
[08:39] <cjwatson> oh yeah, "nest-part packaging lp:~alkisg/+git/ltsp-debian disable-upstreamed-patches debian debian" looks more correct
[08:39] <alkisg> cjwatson: let me find the docs link that had it wrong there...
[08:39] <cjwatson> wait, no, I do see the contradictory docs
[08:39] <cjwatson> sorry, it's been a while
[08:40] <cjwatson> yeah, branch comes last, I'm fairly sure the docs are correct
[08:40] <alkisg> https://help.launchpad.net/Packaging/SourceBuilds/Recipes#nest-part => nest-part packaging lp:~some-person/some-project debian debian master-with-packaging
[08:40] <alkisg> Ah ok
[08:40] <cjwatson> a non-existing default branch would indeed break things, as the code is at the moment
[08:41] <cjwatson> so I think your change to the default branch was what fixed it
[08:41] <alkisg> OK, I'll try to put the branch name back to the recipe, and rebuild, while having the default branch correct in the options
[08:41] <alkisg> This should verify what we assume
[08:41] <cjwatson> it doesn't have to be refs/heads/disable-upstream-patches necessarily, but it does have to exist
[08:49] <alkisg> I pushed that repository with git push, and it auto-selected a default which didn't exist...
[08:51] <cjwatson> Odd
[08:51] <alkisg> cjwatson: no, it failed to build again
[08:52] <alkisg> I only put back the "disable-upstream-patches" back in the recipe now, no other change
[08:52] <alkisg> To sum up, "nest-part packaging lp:~alkisg/+git/ltsp-debian debian debian" builds properly, and "nest-part packaging lp:~alkisg/+git/ltsp-debian debian debian disable-upstream-patches" fails
[08:53] <cjwatson> that's because you've misspelled your branch
[08:53] <alkisg> omg
[08:54] <cjwatson> disable-upstreamed-patches
[08:54] <alkisg> Very sorry, I don't know where that bad copy/paste came from
[08:58] <alkisg> Build succeeded
[08:59] <alkisg> So the only problem was, when I ran `git push` to initially create the repository, it defaulted to 'refs/heads/master', while my repository had no branch called 'master'. And going to the web interface and setting an existing one there, fixed the issue.
[08:59] <alkisg> Thank you very much
[09:07] <cjwatson> This is https://bugs.launchpad.net/git-build-recipe/+bug/1683913 BTW
[09:07] <ubot5> Ubuntu bug 1683913 in git-build-recipe "git-build-recipe assumes that HEAD exists in the source repositories" [Undecided,New]
[15:59] <nacc> cjwatson: if a user has used any tooling to specify their launchpad user name, is that stored anywhere currently in ~/ ? Just trying to determine if there's anything I can try to depend on to derive the LP user of the current user other than asking (or them setting it separately in their git-config)
[16:00] <cjwatson> if they've used launchpadlib then there's lp.me
[16:01] <nacc> cjwatson: which file does that get stored in? I only see cache directories under .launchpadlib
[16:01] <cjwatson> and I suppose you could try 'bzr lp-login' if it's only on a setup path
[16:01] <nacc> cjwatson: oh true, there is that
[16:01] <nacc> cjwatson: although i'd rather the git tooling didn't need to rely on bzr :)
[16:02] <nacc> on some level, i guess we're doing what `bzr lp-loging` does for the git side
[16:02] <nacc> rbasak: --^
[16:02] <nacc> *login not loging
[16:02] <cjwatson> nacc: in the launchpadlib cache it's not stored locally directly; python-keyring has credentials, and those correspond to LP database rows which identify what user they're for
[16:03] <nacc> cjwatson: ah
[16:03] <cjwatson> sure, I understand you don't want to rely on bzr, I was just thinking of it as one of a collection of heuristics you could run to try to guess
[16:03] <nacc> cjwatson: yep, absolutely
[16:03] <cjwatson> s/cache/case/ above
[16:03] <nacc> cjwatson: and in the snap it doesn't matter too much :)
=== chihchun is now known as chihchun_afk
=== santa is now known as Guest19199
[18:38] <alkisg> What's the suggested method to maintain translations from launchpad git branches? Rosetta can't yet import nor export to git, right?
[18:39] <alkisg> Should we set up a .git=>.bzr code import, and then tell rosetta to use the .bzr mirror for importing the translations, and a third bzr branch to export them?
=== JanC is now known as Guest79336