On Tuesday, August 13, 2019 12:22:17 PM CEST Panu Matilainen wrote: > On 8/13/19 1:19 PM, Kamil Dudka wrote: > > > On Tuesday, August 13, 2019 11:26:12 AM CEST Panu Matilainen wrote: > > > >> On 8/13/19 11:17 AM, Igor Gnatenko wrote: > >> > >> > >> > >>> https://bugzilla.redhat.com/show_bug.cgi?id=1738293 > >>> > >>> > >>> > >>> How did it pass review? > >>> > >>> > >>> > >>> > >>>> Obsoletes: compton > >>> > >>> > >>> > >>> > >>> Silently doing Obsoletes of an active package and doing so even > >>> without version which is prohibited by the Packaging Guidelines. > >>> Really? > >>> > >>> > >>> > >>> > >>>> cp -a yshui-%{appname}-%{test_shortcommit}/subprojects/test.h > >>>> /builddir/build/BUILD/%{appname}-%{version}/subprojects/ > >> > >> > >> > >>> > >>> > >>> I am not sure if it is written anywhere, but hardcoding > >>> /builddir/whatsoever is so bad… > >>> > >>> > >>> > >>> > >>>> %meson --buildtype=release > >>> > >>> > >>> > >>> > >>> There is specific reason why we have --buildtype=plain in %meson > >>> macro, because with release buildtype, debuginfo is unusable… > >>> > >>> > >>> > >>> > >>>> # Enable LTO > >>>> %global optflags %{optflags} -flto=$(nproc) > >>>> %global build_ldflags %{build_ldflags} -flto > >>> > >>> > >>> > >>> > >>> Have anybody ever talked to the RPM folks about proper way of enabling > >>> LTO for builds? This specific way of setting it makes build > >>> non-reproducible. > >> > >> > >> > >> > >> Rpm can't help it if gcc/linker argument makes builds non-reproducable. > >> That said, see https://github.com/rpm-software-management/rpm/pull/809, > >> gcc upstream is aware of the issue and supports -flto=auto now, which is > >> what builds should be using for reproducability. > >> > >> > >> > >> - Panu - > > > > > > By reproducibility you mean that the number of jobs can be (in some > > cases) > > controlled by RPM macros? > > > > Does the number of jobs have any impact on the resulting binary? > > > > > See the above URL. > > It doesn't affect the actual link stage, but it affects the stored > optflags in the package (and the actual binaries if that was enabled) > > - Panu - OK, got it. The issue is that -flto=N can be stored in the resulting binary RPMs and the N can differ across builds. So you want to use -flto=auto to always store the same flag, even though the flag may have different semantics in different builds of the same package. Sorry for not understanding it originally. It is good idea to provide some context when you post to such generic list as fedora-devel. Not all readers are experts in all topics and/or have capacity to read in depth all referred documents. Thank you for clarifying it! Kamil _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
