I have some personal ebuild to test live kernels like for example drm-next. i use 9999 as version for this ebuild of course. when i run repoman manifest i got an infinite loop of ebuild.sh (htop shows bash executing ebuild.sh with argument depend. I will attach the portage debug log soon and the ebuild too. I found a workaround in the zen-source-9999 ebuild which is in the main portage tree, you can read the comment here http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-kernel/zen-sources/zen-sources-9999.ebuild?view=markup The solution is to set CKV manually. Reproducible: Always
Created attachment 229227 [details] the portage debug log the portage debug log when running repoman manifest
Created attachment 229229 [details] the ebuild that caused the issue of course if the CKV line is uncommented the issue is gone
Did you use external kernel overlays?
(In reply to comment #3) > Did you use external kernel overlays? No i use these overlay: gechi and x11 (gechi is an italian overlay you can browse here https://gechi-overlay.svn.sourceforge.net/svnroot/gechi-overlay/overlay/ no kernels anyway)
Caused by http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/kernel-2.eclass?r1=1.225&r2=1.226 For 9999 kernels, detect_version sets KV_MINOR and KV_PATCH to empty, then calls kernel_is ge 2 6 && RELEASE=${RELEASE/-pre/-git} which loops back to detect_version because of the linked change. Suggestions that come to mind: 1) Make kernel_is only check for KV_MAJOR being non-empty 2) Check for being set, as opposed to being set to a non-empty string (something along the lines of [[ ${FOO-unset} != ${FOO} ]] && echo "FOO is unset") 3) Make detect_version die if any of the main three variables ends up being empty 3) strikes me as best - it will break existing ebuilds in overlays, but arguably they're already broken if they don't allow the eclass to check their versions in a sensible manner.
(In reply to comment #5) > 3) strikes me as best - it will break existing ebuilds in overlays, but > arguably they're already broken if they don't allow the eclass to check their > versions in a sensible manner. (And of course they're also already broken by this bug, but they would arguably still be broken if this was fixed in some other way.)
Yeah, solution #3 is best, because just checking for unset still leaves the values unset, and there are actually cases that we need those values. The commit I just put into the tree now dies if it cannot work them out. If you have a kernel-sources package affected by this, you MUST add the variable CKV to it. CKV=2.6.99 is a good example value.