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? Kamil _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
