This package still uses the legacy eclass code paths. These paths are deprecated and pose a significant maintenance cost. Please update the package to use PEP517 build mode. For more information, please see the Python Guide, particularly; https://projects.gentoo.org/python/guide/migration.html#migrating-to-pep-517-builds
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=331a06d2a333b02996e9cc49ab55441c9bd749bd commit 331a06d2a333b02996e9cc49ab55441c9bd749bd Author: Sebastian Pipping <sping@gentoo.org> AuthorDate: 2023-07-08 13:50:13 +0000 Commit: Sebastian Pipping <sping@gentoo.org> CommitDate: 2023-07-08 13:54:07 +0000 dev-vcs/git-big-picture: Start using DISTUTILS_USE_PEP517 Closes: https://bugs.gentoo.org/909981 Signed-off-by: Sebastian Pipping <sping@gentoo.org> .../git-big-picture-1.2.2-r2.ebuild | 41 ++++++++++++++++++++++ 1 file changed, 41 insertions(+)
[Adding this comment en-masse, sorry for the noise, but it's important.) 1. Please take particular care to check file diffs before/after, possibly using `iwdevtools`. Keep a particular eye out for e.g. config files now missing from /etc and instead being in /usr/lib/python*/site-packages, etc. 2. Please make sure to do the migration in a new revision in ~arch, partly because of 1.
Hi Sam, adding you to CC for the moment so you have a chance to see this reply: (In reply to Sam James from comment #2) > [Adding this comment en-masse, sorry for the noise, but it's important.) No worries, good disclaimer though. > 2. Please make sure to do the migration in a new revision in ~arch, partly > because of 1. My apologies for going right to stable amd64 here by accident — do you want me to degrade to ~amd64?. repoman would have prevented it but pkg-dev doesn't (and that sucks big time, if I may be frank) and it's hard to adapt to that sudden lack in safety net, in the other two cases I did additional checks manually. > 1. Please take particular care to check file diffs before/after, possibly > using `iwdevtools`. Keep a particular eye out for e.g. config files now > missing from /etc and instead being in /usr/lib/python*/site-packages, etc. I have checked my related fixes to… - app-containers/docker-compose:0 - app-portage/elogv - dev-vcs/git-big-picture …from earlier today once more and I believe they are sane and without problems like these. No commits fixing up on mine in Git either. If something is off that I am not aware of, please help me see it. Thanks!
(In reply to Sebastian Pipping from comment #3) > Hi Sam, > > adding you to CC for the moment so you have a chance to see this reply: > > > (In reply to Sam James from comment #2) > > > 2. Please make sure to do the migration in a new revision in ~arch, partly > > because of 1. > > My apologies for going right to stable amd64 here by accident — do you want > me to degrade to ~amd64?. repoman would have prevented it but pkg-dev > doesn't (and that sucks big time, if I may be frank) and it's hard to adapt > to that sudden lack in safety net, in the other two cases I did additional > checks manually. `pkgcheck scan --commits` and `pkgdev push` should notice this. Would you mind doing that? I can handle it if you're not at a computer though. > > > > 1. Please take particular care to check file diffs before/after, possibly > > using `iwdevtools`. Keep a particular eye out for e.g. config files now > > missing from /etc and instead being in /usr/lib/python*/site-packages, etc. > > I have checked my related fixes to… > > - app-containers/docker-compose:0 > - app-portage/elogv > - dev-vcs/git-big-picture > > …from earlier today once more and I believe they are sane and without > problems like these. No commits fixing up on mine in Git either. If > something is off that I am not aware of, please help me see it. Thanks! Thank you for checking!
(In reply to Sam James from comment #4) > `pkgcheck scan --commits` and `pkgdev push` should notice this. Letting pkgdev push Git is too scary for me (..); "pkgcheck scan --commits" is a nice idea, but I cannot get it to work in practice: # pkgcheck scan --commits 331a06d2a333b02996e9cc49ab55441c9bd749bd^..HEAD ; echo $? # two dots pkgcheck scan: error: failed retrieving commit hash for git repo: '[..]/gentoo-GIT' 2 # pkgcheck scan --commits 331a06d2a333b02996e9cc49ab55441c9bd749bd^...HEAD ; echo $? # three dots <no output> 0 Any ideas? The SHA1 331a06d2a333b02996e9cc49ab55441c9bd749bd is the git-big-picture commit where I was hoping for a complaint about going straight to stable.
(In reply to Sebastian Pipping from comment #5) > "pkgcheck scan --commits" is a nice idea, but I cannot get it to work in > practice: > > # pkgcheck scan --commits 331a06d2a333b02996e9cc49ab55441c9bd749bd^..HEAD > ; echo $? # two dots > pkgcheck scan: error: failed retrieving commit hash for git repo: > '[..]/gentoo-GIT' > 2 > [...] See https://wiki.gentoo.org/wiki/Pkgcheck#failed_retrieving_origin.2FHEAD_commit_hash_for_git_repo. If it continues to fail, try pkgcheck cache -fR.
(There's also some sort of annoying issue with certain origin types but I can't remember it right now. We should at least document what the workaround for that is if someone can tell me what it is. ajak/arthur?)
I recall pkgcheck getting confused if the `origin` remote isn't the authoritative Gentoo repository, can we see `git remote -v`?
I avoid remote name "origin" consistently for safety reasons, my remote name here is "git-gentoo-org" and refs/remotes/git-gentoo-org/HEAD seems set properly. Is the remote not being named "origin" the problem?
Yeah, I think that is likely the issue. See also: - https://github.com/pkgcore/pkgcheck/blob/4e9dbc12ea3b269c021bca30599b043a448acf26/src/pkgcheck/addons/git.py#L657 - https://github.com/pkgcore/pkgcheck/issues/321 - https://github.com/pkgcore/pkgdev/issues/107
Oh my, hardcoding "origin" is not nice. Thanks for the links! I fooled pkgcheck into having a remote "origin" around now like this: # git remote add origin https://anongit.gentoo.org/git/repo/gentoo.git # git remote update origin # git remote set-head origin master (Not a good long-term solution because it won't advance when pushing to git-gentoo-org.) Now the output of "pkgcheck scan" shows this: # pkgcheck scan --commits 331a06d2a333b02996e9cc49ab55441c9bd749bd^..331a06d2a333b02996e9cc49ab55441c9bd749bd dev-vcs/git-big-picture UnstableOnly: for arch: [ x86 ], all versions are unstable: [ 1.2.2-r1, 1.2.2-r2 ] DistutilsNonPEP517Build: version 1.2.2-r1: uses deprecated non-PEP517 build mode, please switch to DISTUTILS_USE_PEP517=... RedundantVersion: version 1.2.2-r1: slot(0) keywords are overshadowed by version: 1.2.2-r2 PotentialStable: version 1.2.2-r2: slot(0), stabled arch: [ amd64 ], potential: [ ~x86 ] PythonCompatUpdate: version 1.2.2-r2: PYTHON_COMPAT update available: python3_12 The only warning (based on color) seems to be the DistutilsNonPEP517Build about version 1.2.2-r1. No warning about going straight to stable, or I'm just not seeing it — do you? What kind of warning output would you expect for this case? Thanks!
