Debuginfo/debugsource: mingw package with mixed host and target debuginfos
Hi
mingw-qt5-qtbase and mingw-qt5-qttools are currently FTBFS [1] due to
errors like
error: Could not open %files file
/builddir/build/BUILD/qtbase-opensource-src-5.9.1/debugsourcefiles.list: No
such file or directory
Duplicate build-ids
/builddir/build/BUILDROOT/mingw-qt5-qtbase-5.9.1-4.fc27.x86_64/usr/i686-w64-mingw32/lib/libQt5Bootstrap.so.5.9.1
and
/builddir/build/BUILDROOT/mingw-qt5-qtbase-5.9.1-4.fc27.x86_64/usr/x86_64-w64-mingw32/lib/libQt5Bootstrap.so.5.9.1
Duplicate build-ids
/builddir/build/BUILDROOT/mingw-qt5-qtbase-5.9.1-4.fc27.x86_64/usr/i686-w64-mingw32/lib/libQt5BootstrapDBus.so.5.9.1
and
/builddir/build/BUILDROOT/mingw-qt5-qtbase-5.9.1-4.fc27.x86_64/usr/x86_64-w64-mingw32/lib/libQt5BootstrapDBus.so.5.9.1
Could not open %files file
/builddir/build/BUILD/qtbase-opensource-src-5.9.1/debugsourcefiles.list: No
such file or directory
Indeed, these packages need special logic to deal with debuginfo files because
both host as well as target binaries are produced by the package, the result up
to now being
mingw-qt5-qtbase-debuginfo -> host
mingw32-qt5-qtbase-debuginfo -> target
mingw64-qt5-qtbase-debuginfo -> target
This was handled in the spec file [2] as
# Override the __debug_install_post argument as this package
# contains both native as well as cross compiled binaries
%global __debug_install_post %%{mingw_debug_install_post};
%{_rpmconfigdir}/find-debuginfo.sh
%{?_missing_build_ids_terminate_build:--strict-build-id} %{?_find_debuginfo_opts}
"%{_builddir}/%%{?buildsubdir}" %{nil}
Long text short question: can someone help me adapt this logic for the new
debuginfo/debugsource mechanism?
Thanks
Sandro
[1]
https://koji.fedoraproject.org/koji/getfile?taskID=21030286&volume=DEFAULT&name=build.log&offset=-4
[2]
https://src.fedoraproject.org/rpms/mingw-qt5-qtbase/blob/master/f/mingw-qt5-qtbase.spec
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Debuginfo/debugsource: mingw package with mixed host and target debuginfos
Hi Sandro, On Wed, Aug 09, 2017 at 03:30:24PM +0200, Sandro Mani wrote: > Long text short question: can someone help me adapt this logic for the > new debuginfo/debugsource mechanism? rpm was changed to make exactly these kind of scenarious easier to handle. And at the same time it enabled some settings to make such splits automatic for all packages. Unfortunately that bites in your case. For the next couple of weeks I only have limited internet access, so I cannot directly help you. But I wrote an overview of changes and settings that packages can use in the following two posts: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ITJHJTUO2WFEAYIHANSM6AMAB5SIFASI/ https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RIAOOP7FDT2CS7QPJNARURFUBBLZO6A4/ A workaround that probably gets you past the build failure for now is to just revert rpm to its old logic by adding the following to your spec file: %undefine _debugsource_packages %undefine _debuginfo_subpackages > [2] > https://src.fedoraproject.org/rpms/mingw-qt5-qtbase/blob/master/f/mingw-qt5-qtbase.spec One thing I do notice is that after setup you seem to go outside (up) the rpm setup source builddir. This will confuse rpm when it tries to find source files that the binaries were build from. See also this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1479198 Hope the helps for now, Mark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Debuginfo/debugsource: mingw package with mixed host and target debuginfos
A workaround that probably gets you past the build failure for now is to just revert rpm to its old logic by adding the following to your spec file: %undefine _debugsource_packages %undefine _debuginfo_subpackages Thanks, that worked for now. [2] https://src.fedoraproject.org/rpms/mingw-qt5-qtbase/blob/master/f/mingw-qt5-qtbase.spec One thing I do notice is that after setup you seem to go outside (up) the rpm setup source builddir. This will confuse rpm when it tries to find source files that the binaries were build from. See also this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1479198 I'll need to check why the build folder was placed outside the source tree - perhaps it's because qmake (used to?) warn that build trees below the source trees are unsupported. Thanks Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
