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.

John R. Graham · Posted: Tue Dec 03, 2024 10:23 pm Post subject:

You know, when I first crafted this workflow back in 2017, the running ebuild environment contained ${HOME} defined to what was specified in the /etc/passwd file for the portage user (call that the "normal home directory" for the sake of discussion). That directory was, of course, writable to the portage user. That means that ebuilds could alter the state of the system in a way that would affect future ebuilds. If I may speculate (as I have know first-hand knowledge for the reason for the change), it appears that what may have happened is, in a laudable attempt to create a completely consistent and normalized environment for all ebuilds, the new home directory location was ephemerally created in /var/tmp/portage/${CATEGORY}/${P}/homedir as part of the setup for each run of an ebuild, created empty. The ebuild is free (PMS confirms) to populate that directory if some program involved in the build needs something to be there.

But what just occurred to me is that it could be useful if, instead of creating an empty homedir there, portage were to populate it with the contents of the normal portage user home directory. This would still allow each new ebuild to have a consistent environment—because the contents of the homedir would be guaranteed to be consistent from run to run. The system owner could intentionally populate the normal portage home directory but the ebuild would be forbidden (at least by best practice) from writing there. It'd also make the git command that failed for me work in an unsurprising way—a better way than being forced to change the system-wide safe directory list.

Can anyone think of a downside to this approach? I might create a bug report / feature request—and work on an implementation.

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.