[opensuse-buildservice] CentOS 8 on obs: Different behavior concerning debug packages
Hi, I am trying to move packages from https://build.opensuse.org/project/show/home:behrisch to https://build.opensuse.org/project/show/science:dlr and get build failures on CentOS 8 although the configuration seems to be identical. The failing project is https://build.opensuse.org/package/show/science:dlr/fox16 which seems to have problems with debuginfos which I tried to disable using %global debug_package %{nil} (this works in my home project). My major question is where does this different behavior come from? Here is what I tried as workarounds: Moving around the define as mentioned here: https://superuser.com/questions/1091529/rpm-build-error-empty-files-file-deb... or adding futher defines such as %undefine _debuginfo_subpackages as mentioned here: https://bugzilla.redhat.com/show_bug.cgi?id=1481352 or %define _debugsource_template %{nil} as mentioned here: https://www.getpagespeed.com/server-setup/build-rpms-gotchas. Nothing worked so far. Thanks for your help, Michael
On sábado, 28 de noviembre de 2020 18:15:45 (CET) Michael Behrisch wrote:
Hi, I am trying to move packages from https://build.opensuse.org/project/show/home:behrisch to https://build.opensuse.org/project/show/science:dlr and get build failures on CentOS 8 although the configuration seems to be identical.
Not 100% identical - home:behrishc does not have debug flag enabled for all repositories: https://build.opensuse.org/repositories/science:dlr - science:dir has it enabled: https://build.opensuse.org/repositories/science:dlr
The failing project is https://build.opensuse.org/package/show/science:dlr/fox16 which seems to have problems with debuginfos which I tried to disable using %global debug_package %{nil} (this works in my home project).
My major question is where does this different behavior come from?
From the meta configuration for both projects.
Here is what I tried as workarounds: Moving around the define as mentioned here: https://superuser.com/questions/1091529/rpm-build-error-empty-files-file-deb ugfiles-list or adding futher defines such as %undefine _debuginfo_subpackages as mentioned here: https://bugzilla.redhat.com/show_bug.cgi?id=1481352 or %define _debugsource_template %{nil} as mentioned here: https://www.getpagespeed.com/server-setup/build-rpms-gotchas. Nothing worked so far.
First of all, I'd declare `debug_package` on top, right on top of `%define lname` But also I think you should not really use: %if 0%{?centos_version} >= 800 %global debug_package %{nil} %endif This doesn't look bad... as long as `centos_version` still works this way for CentOS8. So far I never used `centos_version` in any SPEC, as I never had anything really specific for CentOS. In most cases `rhel` should work, and will work not just for CentOS, but also for RHEL, Oracle, and whatever else is based on RHEL. Try: %if 0%{?rhel} >= 8 %global debug_package %{nil} %endif And remember to enable the debug flag for your home project, so you can check that it works before you submit to science:dlr Give it a try, and let us know.
Thanks for your help, Michael _______________________________________________ openSUSE Build Service mailing list -- buildservice@lists.opensuse.org To unsubscribe, email buildservice-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/buildservice@lists.opensuse.org
-- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com
Am 30.11.20 um 01:34 schrieb Julio González Gil:
On sábado, 28 de noviembre de 2020 18:15:45 (CET) Michael Behrisch wrote:
Hi, I am trying to move packages from https://build.opensuse.org/project/show/home:behrisch to https://build.opensuse.org/project/show/science:dlr and get build failures on CentOS 8 although the configuration seems to be identical.
Not 100% identical - home:behrishc does not have debug flag enabled for all repositories: https://build.opensuse.org/repositories/science:dlr - science:dir has it enabled: https://build.opensuse.org/repositories/science:dlr
Thanks for finding this one!
First of all, I'd declare `debug_package` on top, right on top of `%define lname`
But also I think you should not really use:
%if 0%{?centos_version} >= 800 %global debug_package %{nil} %endif
This doesn't look bad... as long as `centos_version` still works this way for CentOS8. So far I never used `centos_version` in any SPEC, as I never had anything really specific for CentOS.
In most cases `rhel` should work, and will work not just for CentOS, but also for RHEL, Oracle, and whatever else is based on RHEL.
Try:
%if 0%{?rhel} >= 8 %global debug_package %{nil} %endif
I used this documentation: https://en.opensuse.org/openSUSE:Build_Service_cross_distribution_howto#Dete... which does not mention anything for CentOS8 but also does not mention using %{?rhel} at all.
And remember to enable the debug flag for your home project, so you can check that it works before you submit to science:dlr
Give it a try, and let us know.
The good news, now I can reproduce the error also in my home, the bad news is, it is still there and I don't know what to do about it. Thanks for your help, I would be happy about more insights. Best, Michael
On martes, 1 de diciembre de 2020 18:38:32 (CET) Michael Behrisch wrote:
The good news, now I can reproduce the error also in my home, the bad news is, it is still there and I don't know what to do about it.
Thanks for your help, I would be happy about more insights.
Did you try using my suggestion? Even if it's not there... https://rpm-packaging-guide.github.io/#rpm-macros (look at "RPM Conditionals examples"). Maybe it should be documented at https://en.opensuse.org/ openSUSE:Build_Service_cross_distribution_howto#Detect_a_distribution_flavor_for_special_code but I am not sure how. {rhel} applies, AFAIK to RHEL, CentOS and Oracle. We use it a lot at Uyuni :-) For example see https://build.opensuse.org/package/view_file/ systemsmanagement:Uyuni:Master:CentOS8-Uyuni-Client-Tools/go1.15/go1.15.spec? expand=1 lines 27 and 131
Best, Michael _______________________________________________ openSUSE Build Service mailing list -- buildservice@lists.opensuse.org To unsubscribe, email buildservice-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/buildservice@lists.opensuse.org
-- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com
Am 01.12.20 um 18:53 schrieb Julio González Gil:
On martes, 1 de diciembre de 2020 18:38:32 (CET) Michael Behrisch wrote:
The good news, now I can reproduce the error also in my home, the bad news is, it is still there and I don't know what to do about it.
Thanks for your help, I would be happy about more insights.
Did you try using my suggestion?
Yes, but it did not work. I don't think the macro is the problem. I removed the %if completely https://build.opensuse.org/package/view_file/home:behrisch/fox16/fox16.spec?... and it still does not work. https://build.opensuse.org/package/live_build_log/home:behrisch/fox16/CentOS... Best, Michael
On martes, 1 de diciembre de 2020 20:31:10 (CET) Michael Behrisch wrote:
Yes, but it did not work. I don't think the macro is the problem. I removed the %if completely https://build.opensuse.org/package/view_file/home:behrisch/fox16/fox16.spec? expand=1 and it still does not work. https://build.opensuse.org/package/live_build_log/home:behrisch/fox16/CentOS _8/x86_64
Your problem is different now: [ 130s] Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/ abuild/rpmbuild/BUILDROOT/fox16-1.6.57-105.1.x86_64 [ 130s] error: Installed (but unpackaged) file(s) found: [ 130s] /usr/lib/debug/usr/lib64/libCHART-1.6.so. 0.0.57-1.6.57-105.1.x86_64.debug [ 130s] /usr/lib/debug/usr/lib64/libFOX-1.6.so. 0.0.57-1.6.57-105.1.x86_64.debug [ 130s] [ 130s] [ 130s] RPM build errors: [ 130s] Installed (but unpackaged) file(s) found: [ 130s] /usr/lib/debug/usr/lib64/libCHART-1.6.so. 0.0.57-1.6.57-105.1.x86_64.debug [ 130s] /usr/lib/debug/usr/lib64/libFOX-1.6.so. 0.0.57-1.6.57-105.1.x86_64.debug Since now you are not building the debug package anymore, you have two files that would normally go there... but they are not packaged. My best guess is that you need to change how `%configure`, `make` or `%make_install` are called, so you don't get the debug files create, or they don't get installed.
Best, Michael _______________________________________________ openSUSE Build Service mailing list -- buildservice@lists.opensuse.org To unsubscribe, email buildservice-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/buildservice@lists.opensuse.org
-- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com
Am 02.12.20 um 11:53 schrieb Julio González Gil:
On martes, 1 de diciembre de 2020 20:31:10 (CET) Michael Behrisch wrote: Your problem is different now:
[ 130s] RPM build errors: [ 130s] Installed (but unpackaged) file(s) found: [ 130s] /usr/lib/debug/usr/lib64/libCHART-1.6.so. 0.0.57-1.6.57-105.1.x86_64.debug [ 130s] /usr/lib/debug/usr/lib64/libFOX-1.6.so. 0.0.57-1.6.57-105.1.x86_64.debug
Since now you are not building the debug package anymore, you have two files that would normally go there... but they are not packaged.
My best guess is that you need to change how `%configure`, `make` or `%make_install` are called, so you don't get the debug files create, or they don't get installed.
OK, so I compared the log files and found two differences: 1. /usr/lib/rpm/find-debuginfo.sh is not called if debuginfo is disabled in the project but it is if I only use %global debug_package %{nil} 2. The opposite is true for /usr/lib/rpm/brp-strip I call neither of these scripts explicitly and I don't think they are triggered directly by the %make_install but I may be wrong. The internet says to disable find-debuginfo.sh you should set %global debug_package %{nil} https://stackoverflow.com/questions/4158692/what-does-find-debuginfo-sh-in-r... but obviously that does not do the trick. Is this a configuration bug or a change in behavior for more recent CentOS (and also Fedoras as I just noticed)? Is there more documentation what disabling debuginfo from the UI does in addition to %global debug_package %{nil} ? I would also adopt a solution which builds a proper debuginfo package instead of disabling, but I am little bit lost here as well (I found only this one: https://en.opensuse.org/openSUSE:Packaging_guidelines#Debuginfo) Thanks for your help, Michael
participants (2)
-
Julio González Gil -
Michael Behrisch