Using sys-app/portage-2.3.1 and Python 3.5 makes eix-sync to fail under git procedure with the following issue: >>> Syncing repository 'gentoo' into '/usr/portage'... fatal: no upstream configured for branch 'master' Traceback (most recent call last): File "/usr/lib64/python3.5/site-packages/portage/util/_async/AsyncFunction.py", line 39, in _run result = self.target(*(self.args or []), **(self.kwargs or {})) File "/usr/lib64/python3.5/site-packages/portage/sync/controller.py", line 159, in sync taskmaster.run_tasks(tasks, func, status, options=task_opts) File "/usr/lib64/python3.5/site-packages/portage/sync/controller.py", line 66, in run_tasks result = getattr(inst, func)(**kwargs) File "/usr/lib64/python3.5/site-packages/portage/sync/syncbase.py", line 125, in sync return self.update() File "/usr/lib64/python3.5/site-packages/portage/sync/modules/git/git.py", line 96, in update cwd=portage._unicode_encode(self.repo.location))).rstrip('\n') File "/usr/lib64/python3.5/subprocess.py", line 626, in check_output **kwargs).stdout File "/usr/lib64/python3.5/subprocess.py", line 708, in run output=stdout, stderr=stderr) subprocess.CalledProcessError: Command '['/usr/bin/git', 'rev-parse', '--abbrev-ref', '--symbolic-full-name', '@{upstream}']' returned non-zero exit status 128 That error doesn't happen under portage 2.3.0, seems like the new version break something related with git sync, and make eix-sync to fail syncing that repository. Reproducible: Always Steps to Reproduce: 1. emerge =sys-apps/portage-2.3.1 2. eix-sync 3. sync failed Actual Results: subprocess.CalledProcessError: Command '['/usr/bin/git', 'rev-parse', '--abbrev-ref', '--symbolic-full-name', '@{upstream}']' returned non-zero exit status 128 Expected Results: Working. I didn't tested using Python2.7 or other python version.
Created attachment 447446 [details] gentoo.conf file for Gentoo repo.
Assuming that your upstream gentoo remote is named origin, you should run this command: git branch --set-upstream-to origin/master This is required since the following change from bug 552814: https://gitweb.gentoo.org/proj/portage.git/commit/?id=84413bb1dd9df322568ce25efc5b7854a43d03c7
I'm not sure how it ever worked for you without having an upstream branch set, since from my experience git pull will fail in that case as follows: $ git pull fatal: No remote repository specified. Please, specify either a URL or a remote name from which new revisions should be fetched.
Created attachment 447456 [details] Attaching my .git/config for portage I have already set as origin configured to fetch on origin/master.
(In reply to Pablo Cholaky from comment #4) > Created attachment 447456 [details] > Attaching my .git/config for portage > > I have already set as origin configured to fetch on origin/master. The relevant setting in my .git/config is as follows: [branch "master"] remote = origin merge = refs/heads/master
Yes, that works, adding the branch merge configuration process made it work. Is strange because with 2.3.0 was working without specifying the master configuration, but now requires the specific branch setting. Using git pull or fetch/merge never gave me problems before. Just a small question, why are you creating a shadow clone? To avoid giving the whole history to users? Well, anyways, good to detect this would broke some people configuration, and how to fix it. I think this will only affects to guys with very specific git configurations (like mine) I would say, this issue is resolved as wontfix, unless you think you could add some validation against portage, but I wouldn't think that's necessary. Many thanks.
(In reply to Pablo Cholaky from comment #6) > Just a small question, why are you creating a shadow clone? To avoid giving > the whole history to users? Yeah, it's shallow by default, in order to minimize bandwidth. You can set sync-depth = 0 in repos.conf if you want the full history.
I'd like to improve behavior here, so that the GitSync.update method handles there error and returns and returns an error code.
By the way, I saw the cache generation is now under root only permission (600), is that an expected behavior? Should I report that to eix project? Now under cache: metadata-md5-or-flat for Gentoo, it gaves me a whole of "cannot read cache file <cache file>: Permission denied, is that some new feature added into egencache?
(In reply to Pablo Cholaky from comment #9) > By the way, I saw the cache generation is now under root only permission > (600), is that an expected behavior? Should I report that to eix project? > > Now under cache: metadata-md5-or-flat for Gentoo, it gaves me a whole of > "cannot read cache file <cache file>: Permission denied, is that some new > feature added into egencache? That's bug 594358.
Fixed in master branch: https://gitweb.gentoo.org/proj/portage.git/commit/?id=f5d258656de3db54af06fbca9b8da5217d3802f4
Fixed in portage-2.3.3.
