Hello,
I am building a package locally and run across a failure that seems to be unexplained. It gets to the install phase and then abruptly fails with the following build log:
-- Installing: /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/rpostback -- Installing: /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/rpostback- askpass -- Installing: /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/rpostback- editfile -- Installing: /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/rpostback- gitssh -- Installing: /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/rpostback- pdfviewer -- Installing: /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/askpass- passthrough + rm -rf /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64//usr/lib64 + /usr/lib/rpm/find-debuginfo.sh -j8 --strict-build-id -m -i --build-id-seed 1.1.422-1.fc27 --unique-debug-suffix -1.1.422-1.fc27.x86_64 --unique-debug- src-base R-studio-desktop-1.1.422-1.fc27.x86_64 --run-dwz --dwz-low-mem-die- limit 10000000 --dwz-max-die-limit 110000000 -S debugsourcefiles.list /home/ sgrubb/working/BUILD/rstudio-1.1.422 extracting debug info from /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/rstudio extracting debug info from /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/rsession extracting debug info from /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/diagnostics extracting debug info from /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/rpostback /usr/lib/rpm/sepdebugcrcfix: Updated 4 CRC32s, 0 CRC32s did match. 15342 blocks + /usr/lib/rpm/check-buildroot + /usr/lib/rpm/brp-compress + /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip + /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1 error: Bad exit status from /home/sgrubb/working/tmp/rpm-tmp.tz0qAN (%install)
RPM build errors: Bad exit status from /home/sgrubb/working/tmp/rpm-tmp.tz0qAN (%install)
Is the output from sepdebugcrcfix indicating a failure? If so, how do you fix this? If its not this, its really weird because there is plenty of disk space and no other indication that something is wrong.
Thanks, -Steve
On 04/02/2018 18:13, Steve Grubb wrote:
Hello,
I am building a package locally and run across a failure that seems to be unexplained. It gets to the install phase and then abruptly fails with the following build log:
-- Installing: /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/rpostback -- Installing: /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/rpostback- askpass -- Installing: /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/rpostback- editfile -- Installing: /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/rpostback- gitssh -- Installing: /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/rpostback- pdfviewer -- Installing: /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/askpass- passthrough
- rm -rf /home/sgrubb/working/BUILDROOT/R-studio-
desktop-1.1.422-1.fc27.x86_64//usr/lib64
- /usr/lib/rpm/find-debuginfo.sh -j8 --strict-build-id -m -i --build-id-seed
1.1.422-1.fc27 --unique-debug-suffix -1.1.422-1.fc27.x86_64 --unique-debug- src-base R-studio-desktop-1.1.422-1.fc27.x86_64 --run-dwz --dwz-low-mem-die- limit 10000000 --dwz-max-die-limit 110000000 -S debugsourcefiles.list /home/ sgrubb/working/BUILD/rstudio-1.1.422 extracting debug info from /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/rstudio extracting debug info from /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/rsession extracting debug info from /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/diagnostics extracting debug info from /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/rpostback /usr/lib/rpm/sepdebugcrcfix: Updated 4 CRC32s, 0 CRC32s did match. 15342 blocks
- /usr/lib/rpm/check-buildroot
- /usr/lib/rpm/brp-compress
- /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip
- /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1
error: Bad exit status from /home/sgrubb/working/tmp/rpm-tmp.tz0qAN (%install)
RPM build errors: Bad exit status from /home/sgrubb/working/tmp/rpm-tmp.tz0qAN (%install)
Is the output from sepdebugcrcfix indicating a failure? If so, how do you fix this? If its not this, its really weird because there is plenty of disk space and no other indication that something is wrong.
Thanks, -Steve
Full build log, please.
On Sunday, February 4, 2018 12:42:56 PM EST Antonio Trande wrote:
Not enough information to check signature validity. Show Details
On 04/02/2018 18:13, Steve Grubb wrote:
Hello,
I am building a package locally and run across a failure that seems to be unexplained. It gets to the install phase and then abruptly fails with the following build log:
-- Installing: /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/rpostback -- Installing: /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/rpostbac k- askpass -- Installing: /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/rpostbac k- editfile -- Installing: /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/rpostbac k- gitssh -- Installing: /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/rpostbac k- pdfviewer -- Installing: /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/askpass- passthrough
- rm -rf /home/sgrubb/working/BUILDROOT/R-studio-
desktop-1.1.422-1.fc27.x86_64//usr/lib64
- /usr/lib/rpm/find-debuginfo.sh -j8 --strict-build-id -m -i
--build-id-seed 1.1.422-1.fc27 --unique-debug-suffix -1.1.422-1.fc27.x86_64 --unique-debug- src-base R-studio-desktop-1.1.422-1.fc27.x86_64 --run-dwz --dwz-low-mem-die- limit 10000000 --dwz-max-die-limit 110000000 -S debugsourcefiles.list /home/ sgrubb/working/BUILD/rstudio-1.1.422 extracting debug info from /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/rstudio extracting debug info from /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/rsession extracting debug info from /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/diagnostics extracting debug info from /home/sgrubb/working/BUILDROOT/R-studio- desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/rpostback /usr/lib/rpm/sepdebugcrcfix: Updated 4 CRC32s, 0 CRC32s did match. 15342 blocks
- /usr/lib/rpm/check-buildroot
- /usr/lib/rpm/brp-compress
- /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip
- /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1
error: Bad exit status from /home/sgrubb/working/tmp/rpm-tmp.tz0qAN (%install)
RPM build errors: Bad exit status from /home/sgrubb/working/tmp/rpm-tmp.tz0qAN (%install)
Is the output from sepdebugcrcfix indicating a failure? If so, how do you fix this? If its not this, its really weird because there is plenty of disk space and no other indication that something is wrong.
Thanks, -Steve
Full build log, please.
It's too big for the mail list. I put it here:
http://people.redhat.com/sgrubb/files/build.log
-Steve
On 04/02/18 19:30, Steve Grubb wrote:
On Sunday, February 4, 2018 12:42:56 PM EST Antonio Trande wrote:
Not enough information to check signature validity. Show Details
On 04/02/2018 18:13, Steve Grubb wrote:
Hello,
- /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1
error: Bad exit status from /home/sgrubb/working/tmp/rpm-tmp.tz0qAN
Full build log, please.
It's too big for the mail list. I put it here:
Many questions here, and a large package. Still, searching the logs I cannot see any python files - are there any such at all?
If not, perhaps you could disable the byte compulation as described in [1]?
Another question: brp-python-bytecompile tries to use /usr/bin/python which still is python2.7 (I think). So, have you a BR: python2-devel, or is the python command just missing in the build environment?
Cheers! --alec [1] https://fedoraproject.org/wiki/Packaging:Python_Appendix#Manual_byte_compila...
On Sunday, February 4, 2018 2:29:26 PM EST Alec Leamas wrote:
On 04/02/18 19:30, Steve Grubb wrote:
On Sunday, February 4, 2018 12:42:56 PM EST Antonio Trande wrote:
Not enough information to check signature validity. Show Details
On 04/02/2018 18:13, Steve Grubb wrote:
Hello,
- /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1
error: Bad exit status from /home/sgrubb/working/tmp/rpm-tmp.tz0qAN
Full build log, please.
It's too big for the mail list. I put it here:
Many questions here, and a large package. Still, searching the logs I cannot see any python files - are there any such at all?
None at all. Its all java, javascript, R, and ELF files.
If not, perhaps you could disable the byte compulation as described in [1]?
Bingo! That fixed the build...which leads to the question of why is that failing?
Another question: brp-python-bytecompile tries to use /usr/bin/python which still is python2.7 (I think). So, have you a BR: python2-devel, or is the python command just missing in the build environment?
This is being built on my local system. Its has both available:
# rpm -qa | grep python | grep devel python2-devel-2.7.14-7.fc27.x86_64 python3-devel-3.6.4-7.fc27.x86_64
But this package uses no python anywhere. So, its strange that the build is getting tripped up on python.
Thanks for the help. This should let me release an Rstudio 1.1 srpm shortly.
Thanks, -Steve
On 04/02/18 21:36, Steve Grubb wrote:
On Sunday, February 4, 2018 2:29:26 PM EST Alec Leamas wrote:
Many questions here, and a large package. Still, searching the logs I cannot see any python files - are there any such at all?
None at all. Its all java, javascript, R, and ELF files.
If not, perhaps you could disable the byte compulation as described in [1]?
Bingo! That fixed the build...which leads to the question of why is that failing?
I think the basic answer is that the byte comoilation script is using all sorts of strange heuristics. It seems that it determined a that a non-python file was python.
Efforts are under way to redefine things and make the byte compilation more explicit. Until this is done, this is probably not the last error of this sort.
In other words, it's sort of a known bug with fixes under way, slowly...
Cheers! --alec
On 02/04/2018 10:08 PM, Alec Leamas wrote:
On 04/02/18 21:36, Steve Grubb wrote:
On Sunday, February 4, 2018 2:29:26 PM EST Alec Leamas wrote:
Many questions here, and a large package. Still, searching the logs I cannot see any python files - are there any such at all?
None at all. Its all java, javascript, R, and ELF files.
If not, perhaps you could disable the byte compulation as described in [1]?
Bingo! That fixed the build...which leads to the question of why is that failing?
I think the basic answer is that the byte comoilation script is using all sorts of strange heuristics. It seems that it determined a that a non-python file was python.
Efforts are under way to redefine things and make the byte compilation more explicit. Until this is done, this is probably not the last error of this sort.
In other words, it's sort of a known bug with fixes under way, slowly...
I'd like to make sure any Python-related automation is limited to Python context (/usr/lib*/python*, files with python shebangs, etc.). I'm not sure why it's not this way now.
We're preparing a Change to fix this exact issue in Fedora 29. Started just last week, actually: https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompilat...
Up to this point I thought this was just a theoretical issue. Thank you for finding a concrete example -- and sorry it had to be you!
On 05/02/18 16:06, Petr Viktorin wrote:
On 02/04/2018 10:08 PM, Alec Leamas wrote:
In other words, it's sort of a known bug with fixes under way, slowly...
We're preparing a Change to fix this exact issue in Fedora 29. Started just last week, actually: https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompilat...
Right, this is what I had in mind when I wrote my reply. At that point, lazy me couldn't find that Change page even though I was aware it existed somewhere in space.
Cheers!
--alec
On Monday, February 5, 2018 10:06:43 AM EST Petr Viktorin wrote:
I think the basic answer is that the byte comoilation script is using all sorts of strange heuristics. It seems that it determined a that a non-python file was python.
Efforts are under way to redefine things and make the byte compilation more explicit. Until this is done, this is probably not the last error of this sort.
In other words, it's sort of a known bug with fixes under way, slowly...
I'd like to make sure any Python-related automation is limited to Python context (/usr/lib*/python*, files with python shebangs, etc.). I'm not sure why it's not this way now.
We're preparing a Change to fix this exact issue in Fedora 29. Started just last week, actually: https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompila tion
Up to this point I thought this was just a theoretical issue. Thank you for finding a concrete example -- and sorry it had to be you!
OK. RStudio failing to build was an irritation. Now I have a serious problem. The python byte compiler is preventing akmods from building kernel modules leaving me with a near unusable system.
2018/02/06 07:09:32 akmodsbuild: + cd nvidia-kmod-390.25 2018/02/06 07:09:32 akmodsbuild: + for kernel_version in 4.14.16-300.fc27.x86_64___/usr/src/kernels/4.14.16-300.fc27.x86_64 2018/02/06 07:09:32 akmodsbuild: + mkdir -p /tmp/akmodsbuild.9LmgJsG6/BUILDROOT/nvidia-kmod-390.25-1.fc27.x86_64//usr/lib/modules//4.14.16-300.fc27.x86_64//extra/nvidia// 2018/02/06 07:09:32 akmodsbuild: + install -D -m 0755 _kmod_build_4.14.16-300.fc27.x86_64/nvidia-drm.ko _kmod_build_4.14.16-300.fc27.x86_64/nvidia-modeset.ko _kmod_build_4.14.16-300.fc27.x86_64/nvidia-uvm.ko _kmod_build_4.14.16-300.fc27.x86_64/nvidia.ko /tmp/akmodsbuild.9LmgJsG6/BUILDROOT/nvidia-kmod-390.25-1.fc27.x86_64//usr/lib/modules//4.14.16-300.fc27.x86_64//extra/nvidia// 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/check-buildroot 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-compress 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-strip /usr/bin/strip 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1 2018/02/06 07:09:32 akmodsbuild: error: Bad exit status from /var/tmp/rpm-tmp.5l5Sxs (%install)
The issue is this, today a new nvidia driver was release via rpmfusion. Now my user space does not match kernel modules. Kernel modules are failing to build as noted above. When it boots. it detects this mismatch and refuses to work.
Is there a way to suppress this to get kernel modules to build?
-Steve
On Tue, 2018-02-06 at 08:41 -0500, Steve Grubb wrote:
On Monday, February 5, 2018 10:06:43 AM EST Petr Viktorin wrote:
I think the basic answer is that the byte comoilation script is using all sorts of strange heuristics. It seems that it determined a that a non-python file was python.
Efforts are under way to redefine things and make the byte compilation more explicit. Until this is done, this is probably not the last error of this sort.
In other words, it's sort of a known bug with fixes under way, slowly...
I'd like to make sure any Python-related automation is limited to Python context (/usr/lib*/python*, files with python shebangs, etc.). I'm not sure why it's not this way now.
We're preparing a Change to fix this exact issue in Fedora 29. Started just last week, actually: https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_byt ecompila tion
Up to this point I thought this was just a theoretical issue. Thank you for finding a concrete example -- and sorry it had to be you!
OK. RStudio failing to build was an irritation. Now I have a serious problem. The python byte compiler is preventing akmods from building kernel modules leaving me with a near unusable system.
2018/02/06 07:09:32 akmodsbuild: + cd nvidia-kmod-390.25 2018/02/06 07:09:32 akmodsbuild: + for kernel_version in 4.14.16- 300.fc27.x86_64___/usr/src/kernels/4.14.16-300.fc27.x86_64 2018/02/06 07:09:32 akmodsbuild: + mkdir -p /tmp/akmodsbuild.9LmgJsG6/BUILDROOT/nvidia-kmod-390.25- 1.fc27.x86_64//usr/lib/modules//4.14.16- 300.fc27.x86_64//extra/nvidia// 2018/02/06 07:09:32 akmodsbuild: + install -D -m 0755 _kmod_build_4.14.16-300.fc27.x86_64/nvidia-drm.ko _kmod_build_4.14.16-300.fc27.x86_64/nvidia-modeset.ko _kmod_build_4.14.16-300.fc27.x86_64/nvidia-uvm.ko _kmod_build_4.14.16-300.fc27.x86_64/nvidia.ko /tmp/akmodsbuild.9LmgJsG6/BUILDROOT/nvidia-kmod-390.25- 1.fc27.x86_64//usr/lib/modules//4.14.16- 300.fc27.x86_64//extra/nvidia// 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/check-buildroot 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-compress 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-strip /usr/bin/strip 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-strip-comment- note /usr/bin/strip /usr/bin/objdump 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-strip-static- archive /usr/bin/strip 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-python- bytecompile /usr/bin/python 1 2018/02/06 07:09:32 akmodsbuild: error: Bad exit status from /var/tmp/rpm-tmp.5l5Sxs (%install)
The issue is this, today a new nvidia driver was release via rpmfusion. Now my user space does not match kernel modules. Kernel modules are failing to build as noted above. When it boots. it detects this mismatch and refuses to work.
Is there a way to suppress this to get kernel modules to build?
hum haven't you a modified version of rpm-build [1] in your computer ?
[1]
rpm -qf /usr/lib/rpm/brp-python-bytecompile -V
-Steve
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Tuesday, February 6, 2018 8:50:17 AM EST Sérgio Basto wrote:
On Tue, 2018-02-06 at 08:41 -0500, Steve Grubb wrote:
On Monday, February 5, 2018 10:06:43 AM EST Petr Viktorin wrote:
I think the basic answer is that the byte comoilation script is using all sorts of strange heuristics. It seems that it determined a that a non-python file was python.
Efforts are under way to redefine things and make the byte compilation more explicit. Until this is done, this is probably not the last error of this sort.
In other words, it's sort of a known bug with fixes under way, slowly...
I'd like to make sure any Python-related automation is limited to Python context (/usr/lib*/python*, files with python shebangs, etc.). I'm not sure why it's not this way now.
We're preparing a Change to fix this exact issue in Fedora 29. Started just last week, actually: https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_byt ecompilation
Up to this point I thought this was just a theoretical issue. Thank you for finding a concrete example -- and sorry it had to be you!
OK. RStudio failing to build was an irritation. Now I have a serious problem. The python byte compiler is preventing akmods from building kernel modules leaving me with a near unusable system.
2018/02/06 07:09:32 akmodsbuild: + cd nvidia-kmod-390.25 2018/02/06 07:09:32 akmodsbuild: + for kernel_version in 4.14.16- 300.fc27.x86_64___/usr/src/kernels/4.14.16-300.fc27.x86_64 2018/02/06 07:09:32 akmodsbuild: + mkdir -p /tmp/akmodsbuild.9LmgJsG6/BUILDROOT/nvidia-kmod-390.25- 1.fc27.x86_64//usr/lib/modules//4.14.16- 300.fc27.x86_64//extra/nvidia// 2018/02/06 07:09:32 akmodsbuild: + install -D -m 0755 _kmod_build_4.14.16-300.fc27.x86_64/nvidia-drm.ko _kmod_build_4.14.16-300.fc27.x86_64/nvidia-modeset.ko _kmod_build_4.14.16-300.fc27.x86_64/nvidia-uvm.ko _kmod_build_4.14.16-300.fc27.x86_64/nvidia.ko /tmp/akmodsbuild.9LmgJsG6/BUILDROOT/nvidia-kmod-390.25- 1.fc27.x86_64//usr/lib/modules//4.14.16- 300.fc27.x86_64//extra/nvidia// 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/check-buildroot 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-compress 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-strip /usr/bin/strip 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-strip-comment- note /usr/bin/strip /usr/bin/objdump 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-strip-static- archive /usr/bin/strip 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-python- bytecompile /usr/bin/python 1 2018/02/06 07:09:32 akmodsbuild: error: Bad exit status from /var/tmp/rpm-tmp.5l5Sxs (%install)
The issue is this, today a new nvidia driver was release via rpmfusion. Now my user space does not match kernel modules. Kernel modules are failing to build as noted above. When it boots. it detects this mismatch and refuses to work.
Is there a way to suppress this to get kernel modules to build?
hum haven't you a modified version of rpm-build [1] in your computer ?
[1] rpm -qf /usr/lib/rpm/brp-python-bytecompile -V
Nope. The whole package passes verification.
[root@x2 ~]# rpm -qV rpm-build-4.14.0-2.fc27.x86_64 [root@x2 ~]#
Any way to generate troubleshooting info to help figure out what's wrong? Any good way to suppress this so akmods works?
-Steve
On Tue, 2018-02-06 at 09:07 -0500, Steve Grubb wrote:
On Tuesday, February 6, 2018 8:50:17 AM EST Sérgio Basto wrote:
On Tue, 2018-02-06 at 08:41 -0500, Steve Grubb wrote:
On Monday, February 5, 2018 10:06:43 AM EST Petr Viktorin wrote:
I think the basic answer is that the byte comoilation script is using all sorts of strange heuristics. It seems that it determined a that a non-python file was python.
Efforts are under way to redefine things and make the byte compilation more explicit. Until this is done, this is probably not the last error of this sort.
In other words, it's sort of a known bug with fixes under way, slowly...
I'd like to make sure any Python-related automation is limited to Python context (/usr/lib*/python*, files with python shebangs, etc.). I'm not sure why it's not this way now.
We're preparing a Change to fix this exact issue in Fedora 29. Started just last week, actually: https://fedoraproject.org/wiki/Changes/No_more_automagic_Python _byt ecompilation
Up to this point I thought this was just a theoretical issue. Thank you for finding a concrete example -- and sorry it had to be you!
OK. RStudio failing to build was an irritation. Now I have a serious problem. The python byte compiler is preventing akmods from building kernel modules leaving me with a near unusable system.
2018/02/06 07:09:32 akmodsbuild: + cd nvidia-kmod-390.25 2018/02/06 07:09:32 akmodsbuild: + for kernel_version in 4.14.16- 300.fc27.x86_64___/usr/src/kernels/4.14.16-300.fc27.x86_64 2018/02/06 07:09:32 akmodsbuild: + mkdir -p /tmp/akmodsbuild.9LmgJsG6/BUILDROOT/nvidia-kmod-390.25- 1.fc27.x86_64//usr/lib/modules//4.14.16- 300.fc27.x86_64//extra/nvidia// 2018/02/06 07:09:32 akmodsbuild: + install -D -m 0755 _kmod_build_4.14.16-300.fc27.x86_64/nvidia-drm.ko _kmod_build_4.14.16-300.fc27.x86_64/nvidia-modeset.ko _kmod_build_4.14.16-300.fc27.x86_64/nvidia-uvm.ko _kmod_build_4.14.16-300.fc27.x86_64/nvidia.ko /tmp/akmodsbuild.9LmgJsG6/BUILDROOT/nvidia-kmod-390.25- 1.fc27.x86_64//usr/lib/modules//4.14.16- 300.fc27.x86_64//extra/nvidia// 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/check-buildroot 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-compress 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-strip /usr/bin/strip 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-strip- comment- note /usr/bin/strip /usr/bin/objdump 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-strip-static- archive /usr/bin/strip 2018/02/06 07:09:32 akmodsbuild: + /usr/lib/rpm/brp-python- bytecompile /usr/bin/python 1 2018/02/06 07:09:32 akmodsbuild: error: Bad exit status from /var/tmp/rpm-tmp.5l5Sxs (%install)
The issue is this, today a new nvidia driver was release via rpmfusion. Now my user space does not match kernel modules. Kernel modules are failing to build as noted above. When it boots. it detects this mismatch and refuses to work.
Is there a way to suppress this to get kernel modules to build?
hum haven't you a modified version of rpm-build [1] in your computer ?
[1] rpm -qf /usr/lib/rpm/brp-python-bytecompile -V
Nope. The whole package passes verification.
[root@x2 ~]# rpm -qV rpm-build-4.14.0-2.fc27.x86_64 [root@x2 ~]#
Any way to generate troubleshooting info to help figure out what's wrong? Any good way to suppress this so akmods works?
I tested yesterday akmods of VirtualBox on rawhide without any problem, So I may deduce that should work also with nvidia and therefore also may I deduce that is a local issue ... .
-Steve
-
Alec Leamas -
Antonio Trande -
Petr Viktorin -
Steve Grubb -
Sérgio Basto