emerge fails * checking ebuild checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] >>> Preparing to unpack ... >>> Unpacking source... * EGIT_PROJECT has been removed. Instead, the eclass determines * the local clone path using path in canonical EGIT_REPO_URI. * If the current algorithm causes issues for you, please report a bug. * ERROR: sys-kernel/raspberrypi-sources-4.9.9999::gentoo failed (unpack phase): * EGIT_PROJECT is no longer necessary. * * Call stack: * ebuild.sh, line 115: Called src_unpack * environment, line 4243: Called git-r3_src_unpack * environment, line 2368: Called _git-r3_env_setup * environment, line 341: Called die * The specific snippet of code: * die "EGIT_PROJECT is no longer necessary."; * This likely can be fixed by removing the line defining EGIT_PROJECT, but please try to make it possible for users to reuse the already downloaded git content. Don't want to be forced to download the whole git tree again for a minor update in it.
I can duplicate this bug. Please, remove the EGIT_PROJECT from the ebuilds. Thank you!
It is possible to delete that line, but there are further issues with checking out the source code as I noted a few days ago. As a workaround, github has a cool patch feature which automatically hands over soure code tree patches, if you simply add a .patch suffix at the end of a commit you are navigating to. So by downloading the faulty commit, saving it to /usr/portage/ and applying it with -R for reverse, you can easily revert the whole change locally. It is not permanently though, so keep the patch somewhere out of portage's reach! patch url is https://github.com/gentoo/gentoo/commit/52b506bae2f657f6d912fa7f909c6fa05113a55f.patch
Created attachment 499542 [details] (prepare phase) The source directory '${S}' doesn't exist
Comment on attachment 499542 [details] (prepare phase) The source directory '${S}' doesn't exist ls -l /var/tmp/portage/sys-kernel/raspberrypi-sources-4.14.9999/work/ total 4 drwxr-xr-x 25 portage portage 4096 Oct 21 13:15 raspberrypi-sources-4.14.9999
It seems that the S variable is incorrectly defined in the kernel-2.eclass. larry $ grep -wn "S=" /var/tmp/portage/sys-kernel/raspberrypi-sources-4.14.9999/temp/environment 131:declare -x S="/var/tmp/portage/sys-kernel/raspberrypi-sources-4.14.9999/work/linux-4.14.9999-raspberrypi" 1036: S="${WORKDIR}"/linux-${KV_FULL}; larry $ grep -B 2 -A 2 -n 'S="${WORKDIR}"/linux-${KV_FULL}' /usr/portage/eclass/kernel-2.eclass 468- 469- # we will set this for backwards compatibility. 470: S="${WORKDIR}"/linux-${KV_FULL} 471- KV=${KV_FULL} 472-
Created attachment 499666 [details] The environment file (log).
(In reply to Kevin Vigouroux from comment #5) > It seems that the S variable is incorrectly defined in the kernel-2.eclass. > > larry $ grep -wn "S=" > /var/tmp/portage/sys-kernel/raspberrypi-sources-4.14.9999/temp/environment > 131:declare -x > S="/var/tmp/portage/sys-kernel/raspberrypi-sources-4.14.9999/work/linux-4.14. > 9999-raspberrypi" > 1036: S="${WORKDIR}"/linux-${KV_FULL}; > > larry $ grep -B 2 -A 2 -n 'S="${WORKDIR}"/linux-${KV_FULL}' > /usr/portage/eclass/kernel-2.eclass > 468- > 469- # we will set this for backwards compatibility. > 470: S="${WORKDIR}"/linux-${KV_FULL} > 471- KV=${KV_FULL} > 472- See attachment 499542 [details] (a sample of the file build.log) File: kernel-2.eclass 808 unpack_set_extraversion() { 809 cd "${S}" 810 sed -i -e "s:^\(EXTRAVERSION =\).*:\1 ${EXTRAVERSION}:" Makefile 811 cd "${OLDPWD}" 812 }
After removing EGIT_PROJECT, setting EGIT_CHECKOUT_DIR="${WORKDIR}/linux-${PV}-raspberrypi" does the job for me.
(In reply to Conrad Kostecki from comment #8) > After removing EGIT_PROJECT, setting > EGIT_CHECKOUT_DIR="${WORKDIR}/linux-${PV}-raspberrypi" does the job for me. How did you proceed? Could you provide a patch? I suppose you have added EGIT_CHECKOUT_DIR in the raspberrypi-source-x.xx.xxxx ebuild because setting EGIT_CHECKOUT_DIR in git-r3.eclass with ".../linux-${PV}-raspberrypi" is wrong. Indeed, git-r3.eclass applies to several Git repositories. In my case, I added EGIT_CHECKOUT_DIR in the raspberrypi-source-4.14.9999 ebuild *but I got the same emerge failure*: `die "The source directory '${S}' doesn't exist"`. It seems that git-2.eclass copy the repository's files in the EGIT_SOURCEDIR directory. EGIT_SOURCEDIR is defined with the value of S. File git-2.eclass: line 142: : ${EGIT_SOURCEDIR="${S}"} line 303: # @FUNCTION: git-2_move_source # @INTERNAL # @DESCRIPTION: # Internal function moving sources from the EGIT_DIR to EGIT_SOURCEDIR dir. 307: git-2_move_source() { ... 314: ${MOVE_COMMAND} "${EGIT_SOURCEDIR}" \ || die "${FUNCNAME}: sync to \"${EGIT_SOURCEDIR}\" failed" ... } N.B: I would add precision to comment #5: S is well defined in kernel-2.eclass but does not associate (integrate) inside the build environment defined by git-r3.eclass.
(In reply to Kevin Vigouroux from comment #9) > (In reply to Conrad Kostecki from comment #8) > > After removing EGIT_PROJECT, setting > > EGIT_CHECKOUT_DIR="${WORKDIR}/linux-${PV}-raspberrypi" does the job for me. > > How did you proceed? Could you provide a patch? > > I suppose you have added EGIT_CHECKOUT_DIR in the > raspberrypi-source-x.xx.xxxx ebuild because setting EGIT_CHECKOUT_DIR in > git-r3.eclass with ".../linux-${PV}-raspberrypi" is wrong. Indeed, > git-r3.eclass applies to several Git repositories. > > In my case, I added EGIT_CHECKOUT_DIR in the raspberrypi-source-4.14.9999 > ebuild *but I got the same emerge failure*: `die "The source directory > '${S}' doesn't exist"`. I did a mistake: during a test, I modified the variable S on line 470 of the kernel-2.eclass file and forgot to reset it. Setting EGIT_CHECKOUT_DIR="${WORKDIR}/linux-${PV}-raspberrypi" in the raspberrypi-sources ebuild also works for me. Thank Conrad!
Created attachment 500184 [details, diff] Fixed EGIT_* variables due to git-r3 migration - Put the modified ebuild (edited manually or created with the patch command) in a local ebuild repository. * https://wiki.gentoo.org/wiki/Handbook:AMD64/Portage/CustomTree#Adding_unofficial_ebuilds * https://wiki.gentoo.org/wiki/Repoman * https://devmanual.gentoo.org
I was unaware of this bug, before I filed a PR on Github, which fixes the issue for sys-kernel/raspberrypi-sources-4.19.9999.
Looks like other versions were fixed in https://github.com/gentoo/gentoo/commit/b79eed3e2440dfda67fde2c041ce03928bed0f26
Can someone confirm that the ebuild now works as expected? checking out the git sources from git, unpacking them, installing them to image and merging them to the file system? I can't test at the moment due to bandwith limitations.
After I saw those changes, I tested them, and they don't work. https://github.com/gentoo/gentoo/pull/6524 at least fixes it for me.
The last commit removed the patch: https://github.com/gentoo/gentoo/commit/524925d and the patch was not applied to all affected ebuilds: https://github.com/gentoo/gentoo/commits/master/sys-kernel/raspberrypi-sources
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=524ea20de7db8f514164cd7d697564678a0a46b4 commit 524ea20de7db8f514164cd7d697564678a0a46b4 Author: Alexey Sokolov <sokolov@google.com> AuthorDate: 2017-12-11 21:49:35 +0000 Commit: Patrice Clement <monsieurp@gentoo.org> CommitDate: 2018-01-04 17:43:30 +0000 sys-kernel/raspberrypi-sources: inherit git-r3 eclass across the remaining ebuilds. Also partially revert 524925d4b833502b81a5c653b57cfe5437820d81. Closes: https://bugs.gentoo.org/633542 Closes: https://github.com/gentoo/gentoo/pull/6524 sys-kernel/raspberrypi-sources/raspberrypi-sources-4.10.9999.ebuild | 3 ++- sys-kernel/raspberrypi-sources/raspberrypi-sources-4.11.9999.ebuild | 3 ++- sys-kernel/raspberrypi-sources/raspberrypi-sources-4.12.9999.ebuild | 3 ++- sys-kernel/raspberrypi-sources/raspberrypi-sources-4.13.9999.ebuild | 3 ++- sys-kernel/raspberrypi-sources/raspberrypi-sources-4.14.9999.ebuild | 1 + sys-kernel/raspberrypi-sources/raspberrypi-sources-4.4.9999.ebuild | 3 ++- sys-kernel/raspberrypi-sources/raspberrypi-sources-4.9.9999.ebuild | 3 ++- 7 files changed, 13 insertions(+), 6 deletions(-)
Solved. Thanks! :)
