Unexpected issue fetching a local git repo from an ebuild

John R. Graham

I have a workflow I've been using for years where I create a bespoke ebuild that fetches source code from a "feature branch" (that I create) of a local git repository that is itself a clone of an upstream repository. Currently I'm working on upstream samba so I've cloned the upstream samba repo into /home/jgraham/Projects/Gentoo/samba, checked out the tag I'm interested in and created the feature branch, in this case named nss_winbind_experiments, and switched to that branch. This structure allows me to make changes in the local repo and, as soon as I commit those changes, they can be built and installed with Portage. I use versions like 9998, 9997 for my local experimental branches.

This has been working for years but in my latest attempt git is no longer happy:

CaptainBlood · Advocate Joined: 24 Jan 2010 Posts: 3952

Unexperienced here...

Did you had previous success with EAPI 8?

Thks 4 ur attention, interest & support.
_________________
USE="-* ..." in /etc/portage/make.conf here, i.e. a countermeasure to portage implicit braces, belt & diaper paradigm
LT: "I've been doing a passable imitation of the Fontana di Trevi, except my medium is mucus. Sooo much mucus. "

logrusx · Advocate Joined: 22 Feb 2018 Posts: 2475

At first I thought portage sandbox must have been strengthened, but then I found this:

https://confluence.atlassian.com/bbkb/git-command-returns-fatal-error-about-the-repository-being-owned-by-someone-else-1167744132.html

The safe.directory solution should work but I'm not sure where you should put it. Is it in portage tree or your repository, it's unclear to me.

EDIT: I think it's better explained here: https://blog.echomy.com/index.php/2024/08/05/resolving-the-detected-dubious-ownership-error-in-git-an-in-depth-guide/

Best Regards,
Georgi

John R. Graham · Posted: Mon Dec 02, 2024 10:32 pm Post subject:

CaptainBlood · Advocate Joined: 24 Jan 2010 Posts: 3952

Glad you made it with support from others.
Nice sharing of kinda uncommon ebuild architecture,
Bookmarked.

Thks 4 ur attention, interest & support.
_________________
USE="-* ..." in /etc/portage/make.conf here, i.e. a countermeasure to portage implicit braces, belt & diaper paradigm
LT: "I've been doing a passable imitation of the Fontana di Trevi, except my medium is mucus. Sooo much mucus. "

Hu · Administrator Joined: 06 Mar 2007 Posts: 22768

Yes, using --system is unusual here, since that writes it to the system-wide configuration, but you only needed it for the Portage user. I think I recall that Portage sets $HOME to a value other than the one in /etc/passwd, so your sudo'd command probably wrote the file in a directory that would work if you ran su - portage and ran git commands, but does not work when emerge runs git as part of an ebuild. I do not recall how Portage sets $HOME, or why I think that it is special. Perhaps the environment file from a failed run would help.

John R. Graham · Posted: Tue Dec 03, 2024 4:23 am Post subject:

I had gone so far as to look at portage's home directory as recorded in /etc/passwd and confirmed that the initially recommended command (--global; not --system) indeed wrote a .gitconfig file in that directory, but you make a good point. Checking the environment file produced by

John R. Graham · Posted: Tue Dec 03, 2024 4:26 am Post subject:

logrusx · Advocate Joined: 22 Feb 2018 Posts: 2475

Hu · Administrator Joined: 06 Mar 2007 Posts: 22768

Although sudo is misused with shocking frequency, it is innocent in this case. John was misled by the assumption that the command printed by git (not sudo) would work as written. If Portage ran all ebuilds with $HOME set to the value from /etc/passwd, the command probably would have worked. Since it does not, neither sudo -u portage git ... nor su - -c 'git ...' will do the right thing.