>>> Running pre-merge checks for sys-libs/gpm-1.20.7-r6 * Unable to check for the following kernel config options due * to absence of any configured kernel sources or compiled * config: * - INPUT_MOUSEDEV - CONFIG_INPUT_MOUSEDEV: is not set (required to expose mice for GPM) * You're on your own to make sure they are set if needed. However, INPUT_MOUSEDEV is set to m. I built the linux kernel again, but sys-libs/gpm gives me the same warning. Reproducible: Always
Full build output / build.log for the binpkg? It'd be good to see what it's detecting or if any error messages like .config not found. If I were to "guess" it tried to use the same .config it found at build time but did not find it at runtime. Problem is that binpkgs load the environment they had at build time, and so all the variables are still set (including KV_FULL) and "get_version" will work without falling back to "get_running_version" even if the kernel it had at build time is gone.
(In reply to Ionen Wolkens from comment #1) > Full build output / build.log for the binpkg? It'd be good to see what it's > detecting or if any error messages like .config not found. well, emerge output.. I meant the output when emerging the binpkg, not creating it (thought build may sound confusing here).
(In reply to Ionen Wolkens from comment #1) > Problem is that binpkgs load the environment they had at build time, and so > all the variables are still set (including KV_FULL) and "get_version" will > work without falling back to "get_running_version" even if the kernel it had > at build time is gone. Should be noted that even if we do a fix for this (probably by always re-checking even if variables are set), it won't work for old binpkgs given they store the entire (old) eclass as well.
(In reply to Ionen Wolkens from comment #3) > (In reply to Ionen Wolkens from comment #1) > > Problem is that binpkgs load the environment they had at build time, and so > > all the variables are still set (including KV_FULL) and "get_version" will > > work without falling back to "get_running_version" even if the kernel it had > > at build time is gone. > Should be noted that even if we do a fix for this (probably by always > re-checking even if variables are set), it won't work for old binpkgs given > they store the entire (old) eclass as well. Well, unconditionally re-checking sound like it'd be messy actually (it'd print messages again within the same cycle given get_version is likely to get called multiple times). And then e.g. `unset KV_FULL` at the start of pkg_setup won't work when packages like gpm are calling check_extra_config directly. Maybe another way without refactoring everything would be to check if the .config still exists when attempt to use it, and then try to get version again if not (currently the "${mycat} <.config> | sed" has no error checking, which is why I suspect there's a file not found error message). Just guesswork though, I haven't tried/tested anything.
That's the best error message I have.
You can't give a build.log?
How can I get build.log for a binary package?
This is an issue I can confirm exists. To fix it, we would need to prevent Portage from env-saving some variables, or rework the eclass to not rely on global variables.
(In reply to Mike Gilbert from comment #8) > To fix it, we would need to prevent Portage from env-saving some variables, > or rework the eclass to not rely on global variables. On the Portage side, there's this section of PMS to contend with: 11.2 The State of Variables Between Functions https://dev.gentoo.org/~ulm/pms/head/pms.html#section-11.2
I wonder if we could get away with unsetting a few vars in linux-info_pkg_setup. I’ll look into it later.
(In reply to Mike Gilbert from comment #10) > I wonder if we could get away with unsetting a few vars in > linux-info_pkg_setup. I’ll look into it later. The example package from this bug report does not even run linux-info_pkg_setup (this is not a requirement to use the eclass unlike linux-mod-r1 which enforces it). And then get_version can be called a bit all over multiple times and that would end up repeating the check + messages if unset. In comment #4, pondered the idea of checking if the .config is still valid and if not repeat the check but haven't experimented. Thinking again, another route could be to check if merge type is binary, and reset once setting a new "do not repeat check" variable.
(In reply to Ionen Wolkens from comment #11) > (In reply to Mike Gilbert from comment #10) > > I wonder if we could get away with unsetting a few vars in > > linux-info_pkg_setup. I’ll look into it later. > The example package from this bug report does not even run > linux-info_pkg_setup (this is not a requirement to use the eclass unlike > linux-mod-r1 which enforces it). Oh wait it does, it's just adding pkg_pretend on top :) But well, that still means it's called before linux-info_pkg_setup anyway...
(In reply to Ionen Wolkens from comment #11) > Thinking again, another route could be to check if merge type is binary, and > reset once setting a new "do not repeat check" variable. This is the route I went with my PR.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f51cd5b64c14ddfb83488a12d538c66a4a309376 commit f51cd5b64c14ddfb83488a12d538c66a4a309376 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2024-03-09 19:16:26 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2024-03-12 00:38:27 +0000 linux-info.eclass: improve binpkg handling When installing a binpkg, Portage will restore the ebuild environment from when the binpkg was built. The stored values for KV_* may be different from the values that would be detected on the current system. To work around this, unset some key variables in linux-info_get_any_version when MERGE_TYPE == binary. Also, only look for the running kernel version: we can't possibly need a full kernel source tree when installing a package that has already been compiled. This gives a nice speedup as well. Closes: https://bugs.gentoo.org/926063 Signed-off-by: Mike Gilbert <floppym@gentoo.org> eclass/linux-info.eclass | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-)
I just installed sys-libs/gpm again and got the same warning. Should I wait for a new version of sys-libs/gpm?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7ca8ee3261f35705fbe94af7688e41815b42c0e6 commit 7ca8ee3261f35705fbe94af7688e41815b42c0e6 Author: Andrew Ammerlaan <andrewammerlaan@gentoo.org> AuthorDate: 2024-05-09 17:33:00 +0000 Commit: Andrew Ammerlaan <andrewammerlaan@gentoo.org> CommitDate: 2024-05-17 12:06:47 +0000 linux-mod-r1.eclass: do not reset kernel env vars in binpkgs Closes: https://bugs.gentoo.org/931213 Bug: https://bugs.gentoo.org/926063 Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org> Closes: https://github.com/gentoo/gentoo/pull/36597 Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org> eclass/linux-mod-r1.eclass | 5 +++++ 1 file changed, 5 insertions(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=05ad18f837f89cfa2b20e01264ef6332c240072c commit 05ad18f837f89cfa2b20e01264ef6332c240072c Author: Andrew Ammerlaan <andrewammerlaan@gentoo.org> AuthorDate: 2024-05-09 17:01:00 +0000 Commit: Andrew Ammerlaan <andrewammerlaan@gentoo.org> CommitDate: 2024-05-17 12:06:46 +0000 linux-info.eclass: respect eselect kernel setting in binpkgs Commit f51cd5b64c14ddfb83488a12d538c66a4a309376 resets kernel environment variables when binpkgs are merged, this makes sense since we care about the system that the binpkg will be installed on, not the system the binpkg was built on. This introduced Bug 931213 as a side-effect, which will be fixed in a separate commit to linux-mod-r1.eclass. In preparation of that, we document and rename the LINUX_INFO_BINARY_RESET to SKIP_KERNEL_BINPKG_ENV_RESET. However, commit f51cd5b64c14ddfb83488a12d538c66a4a309376 also makes binpkgs always use the running kernel version. This behaviour is surprising and confusing. In principle the 'eselect kernel' setting should still be respected when binpkgs are used. Bug: https://bugs.gentoo.org/926063 Bug: https://bugs.gentoo.org/931213 Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org> eclass/linux-info.eclass | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-)
