On Wednesday, July 26, 2017 14:55:34 Igor Gnatenko wrote: > On Wed, 2017-07-26 at 14:38 +0200, Kamil Dudka wrote: > > > On Monday, June 26, 2017 16:13:02 Mark Wielaard wrote: > > > > > Hi packagers, > > > > > > > > > > > > rawhide rpmbuild contains various debuginfo improvements that > > > hopefully > > > will make various hacks in spec files redundant. > > > > > > > > These improvements break build of packages that use the > > RemovePathPostfixes > > feature of RPM, such as coreutils or curl: > > > > > > > > https://koji.fedoraproject.org/koji/getfile?taskID=20745024&volume=DE > > FAULT&name=build.log&offset=-4000 > > https://koji.fedoraproject.org/koji/getfile?taskID=20745984&volume=DE > > FAULT&name=build.log&offset=-4000 > > > > > > > > Is this expected? > > Definitely not, but thanks a lot for reporting! > > I've created issue for rpm[0] to track this problem. For now, feel free > to add %undefine _debuginfo_subpackages on top of your spec files. Thanks for the quick reply on this! Using the above trick helped me to make both coreutils and curl build successfully again. Kamil > Sorry for breakage. > > [0]https://github.com/rpm-software-management/rpm/issues/280 > > > > > > > Kamil > > > > > > > > > If you have your own way of handling debuginfo packages, calling > > > find-debuginfo.sh directly, need hacks for working around debugedit > > > limitations or split your debuginfo package by hand then please try > > > out > > > rpmbuild in rawhide and read below for some macros you can set to > > > tweak > > > debuginfo package generation. > > > > > > > > > > > > If you still need hacks in your spec file because setting macros > > > isn't > > > enough to get the debuginfo packages you want then please let us > > > know. > > > Also please let us know about packages that need to set debuginfo > > > rpm > > > macros to non-default values because they would crash and burn with > > > the > > > default settings (best to file a bug against rpmbuild). > > > > > > > > > > > > The improvements have been mainly driven by the following two > > > change > > > proposals for f27 (some inspired by what other distros do): > > > > > > > > > > > > https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo > > > https://fedoraproject.org/wiki/Changes/SubpackageAndSourceDebuginfo > > > > > > > > > > > > The first is completely done and has been enabled by default for > > > some > > > months now in rawhide. The second introduces two new macros to > > > enable > > > separate debugsource and sub-debuginfo packages, but has not been > > > enabled by default yet. If people like the change and no bugs are > > > found > > > (and fesco and releng agree) we can enable them for the f27 mass > > > rebuild. > > > > > > > > > > > > If your package already splits debuginfo packages in a (common) > > > source > > > package and/or sub-debuginfo packages, please try out the new > > > macros > > > introduced by the second change. You can enable the standard > > > splitting > > > by adding the following to your spec file: > > > > > > > > > > > > %global _debugsource_packages 1 > > > %global _debuginfo_subpackages 1 > > > > > > > > > > > > Besides the above two changes debuginfo packages can now (and are > > > by > > > default in rawhide) build by running debug extraction in parallel. > > > This > > > should speed up building with lots of binaries/libraries. If you do > > > invoke find-debuginfo.sh by hand you most likely will want to add > > > %{?_smp_mflags} as argument to get the parallel processing speedup. > > > > > > > > > > > > If your package is invoking find-debuginfo.sh by hand also please > > > take a > > > look at all the new options that have been added. Also note that > > > almost > > > all options can be changed by setting (or undefining) rpm macros > > > now. > > > Using the rpm macros is preferred over invoking find-debuginfo.sh > > > directly since it means you get any defaults and improvements that > > > might > > > need new find-debuginfo.sh arguments automatically. > > > > > > > > > > > > Here is an overview of various debuginfo rpm macros that you can > > > define > > > undefine in your spec file with the latest rpmbuild: > > > > > > > > > > > > # > > > # Should an ELF file processed by find-debuginfo.sh having no build > > > ID > > > # terminate a build? This is left undefined to disable it and > > > defined to > > > # enable. > > > # > > > %_missing_build_ids_terminate_build 1 > > > > > > > > > > > > # > > > # Include minimal debug information in build binaries. > > > # Requires _enable_debug_packages. > > > # > > > %_include_minidebuginfo 1 > > > > > > > > > > > > # > > > # Include a .gdb_index section in the .debug files. > > > # Requires _enable_debug_packages and gdb-add-index installed. > > > # > > > %_include_gdb_index 1 > > > > > > > > > > > > # > > > # Defines how and if build_id links are generated for ELF files. > > > # The following settings are supported: > > > # > > > # - none > > > # No build_id links are generated. > > > # > > > # - alldebug > > > # build_id links are generated only when the __debug_package > > > global is > > > # defined. This will generate build_id links in the -debuginfo > > > package > > > # for both the main file as /usr/lib/debug/.build-id/xx/yyy and > > > for > > > # the .debug file as /usr/lib/debug/.build-id/xx/yyy.debug. > > > # This is the old style build_id links as generated by the > > > original > > > # find-debuginfo.sh script. > > > # > > > # - separate > > > # build_id links are generate for all binary packages. If this is > > > a > > > # main package (the __debug_package global isn't set) then the > > > # build_id link is generated as /usr/lib/.build-id/xx/yyy. If > > > this is > > > # a -debuginfo package (the __debug_package global is set) then > > > the > > > # build_id link is generated as /usr/lib/debug/.build-id/xx/yyy. > > > # > > > # - compat > > > # Same as for "separate" but if the __debug_package global is set > > > then > > > # the -debuginfo package will have a compatibility link for the > > > main > > > # ELF /usr/lib/debug/.build-id/xx/yyy -> /usr/lib/.build- > > > id/xx/yyy > > > %_build_id_links compat > > > > > > > > > > > > # Whether build-ids should be made unique between package > > > version/releases > > > # when generating debuginfo packages. If set to 1 this will pass > > > # --build-id-seed "%{VERSION}-%{RELEASE}" to find-debuginfo.sh > > > which will > > > # pass it onto debugedit --build-id-seed to be used to prime the > > > build-id > > > # note hash. > > > %_unique_build_ids 1 > > > > > > > > > > > > # Do not recompute build-ids but keep whatever is in the ELF file > > > already. > > > # Cannot be used together with _unique_build_ids (which forces > > > recomputation). > > > # Defaults to undefined (unset). > > > #%_no_recompute_build_ids 1 > > > > > > > > > > > > # Whether .debug files should be made unique between package > > > version, > > > # release and architecture. If set to 1 this will pass > > > # --unique-debug-suffix "-%{VERSION}-%{RELEASE}.%{_arch} find- > > > debuginfo.sh > > > # to create debuginfo files which end in -<ver>-<rel>.<arch>.debug > > > # Requires _unique_build_ids. > > > %_unique_debug_names 1 > > > > > > > > > > > > # Whether the /usr/debug/src/<package> directories should be unique > > > between > > > # package version, release and architecture. If set to 1 this will > > > pass # > > > --unique-debug-src-base "%{name}-%{VERSION}-%{RELEASE}.%{_arch}" to > > > # > > > find-debuginfo.sh to name the directory under /usr/debug/src as # > > > <name>-<ver>-<rel>.<arch>. > > > %_unique_debug_srcs 1 > > > > > > > > > > > > # Whether rpm should put debug source files into its own subpackage > > > #%_debugsource_packages 1 > > > > > > > > > > > > # Whether rpm should create extra debuginfo packages for each > > > subpackage > > > #%_debuginfo_subpackages 1 > > > > > > > > > > > > # Number of debugging information entries (DIEs) above which > > > # dwz will stop considering file for multifile optimizations > > > # and enter a low memory mode, in which it will optimize > > > # in about half the memory needed otherwise. > > > %_dwz_low_mem_die_limit 10000000 > > > # Number of DIEs above which dwz will stop processing > > > # a file altogether. > > > %_dwz_max_die_limit 50000000 > > > > > > > > > > > > %_find_debuginfo_dwz_opts --run-dwz\\\ > > > > > > --dwz-low-mem-die-limit %{_dwz_low_mem_die_limit}\\\ > > > --dwz-max-die-limit %{_dwz_max_die_limit} > > > > > > > > > > > > If there are settings missing that would be useful, bugs with the > > > default settings or defaults that should be changed please do file > > > a bug > > > report. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Mark > > > > > > > > _______________________________________________ > > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > > -- > -Igor Gnatenko _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
