This is pretty simple. The get_version script shouldn't fail on a missing .config or it breaks any package which tries to do kernel checks prior to the kernel being built. The usual suspects are installer/release-building, so we'd like this to be fixed before we start 2007.1 early next month. I'm willing to help test this in any way.
This is still an issue which will block release-building. Has there been any progress here? This really is critical for Release Engineering.
This should fix it (obviously needs testing.) The main issue is that there's a config check wrapped in there for other functions in the eclass. I added a -c option to get_version so these functions can ask it to check the config file's existence. Checking the tree, I could only find the following ebuilds which call get_version and check_config (but didn't look for other stuff like check_zlibinflate -- the same principle should apply.) They all call get_version first, then check_config (which implies they need kernel configured.) In these cases what'll happen is the first call will check for the directory, and the second call to get_version (via check_config) will look for the config file. Please note: if linux-info_pkg_setup() is called with CONFIG_CHECK non-empty it will still bail if there is not a configured kernel (ll. 560-563) HTH; a release would do us all a lot of good.
Created attachment 140964 [details, diff] linux-info.eclass.patch
Doh sorry for spam (except the *spying-on-igli bods ofc) ebuilds i forgot to list: /usr/portage/net-dialup/ppp/ppp-2.4.4-r11.ebuild /usr/portage/net-dialup/ppp/ppp-2.4.4-r13.ebuild /usr/portage/net-dialup/ppp/ppp-2.4.4-r9.ebuild /usr/portage/net-firewall/tuxfrw/tuxfrw-2.61.ebuild /usr/portage/net-misc/br2684ctl/br2684ctl-20040226.ebuild /usr/portage/net-misc/quagga/quagga-0.99.7-r1.ebuild /usr/portage/net-misc/quagga/quagga-0.99.9.ebuild
(In reply to comment #2) > HTH; a release would do us all a lot of good. Was this really a necessary statement to even make? I'll check out the patch today. It sounds like it does exactly what we'll need. Thanks
Logically I think config checking should be it's own function. That would probably simplify your changes to get_version (which I have not yet reviewed).
(In reply to comment #6) > Logically I think config checking should be it's own function. That would > probably simplify your changes to get_version (which I have not yet reviewed). > Agreed; I started to do a base get_version which could be called by a config checking one but it started to get tricky trying to maintain the internal api and eliminate code duplication. So I just went for a quick patch using a flag, for this issue, rather than sort the whole eclass out. It's really crufty for one, so I'd end up cleaning it all first; it was late on this side of the Atlantic, and I wasn't sure if it would be received in the spirit it was meant. One minor issue is that for git sources, the extra bit at end won't be picked up til a -c call is done. Hope it helps, good luck. Feel free to email if you need any tweaks to bash stuff, Daniel. Removing cc to avoid unnecessary spam.
It doesn't need to be that complicated: one simple (one-line?) function gives a return code whether the .config exists. Then, the get_version function operates with a .config file if there is one there, and without if there is not one. Anything requiring a .config calls the first function, and dies if the return code indicates nothing is there.
Alright, implemented that. Also fixed the case where CONFIG_CHECK wasn't requiring anything to actually be set/unset but a .config was being required and checked all the same. Sorry for the delay.
