Another thing is that this syntax makes it impossible to have colons (':') in
the output (eg '%{!?foo::}'), which is a limitation the original syntax doesn't
have'. It obviously has it's own set of limitations and quirks...
--
You are receiving this because you are subscribed to this thread.
R
As mentioned in the ticket (#115), I want to see a plan for a syntax that
allows for generic condition instead of just existence test before proceeding.
Also mentioned in the ticket, the syntax has other issues too. Lets discuss
those in the ticket to keep it all in one place.
@pavlinamv , whil
Meh, wrong button... Closing as per above.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/798#issuecomment-520326737___
Rpm-ma
Fixed in commit c7e0b61c05878868300653d5892425c6c41fdba0
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/798#issuecomment-520326623
Closed #798.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/798#event-2549342624___
Rpm-maint mailing list
Rpm-maint@lists.rpm
Hope @pmatilai can help me with this pull request?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/809#issuecomment-520366815___
I can see -flto=auto being useful for the average upstream makefile defaults
but I'm not convinced this is the right thing to do in rpm context: we'd want
our parallel activities controlled via the same central tunables
($RPM_BUILD_NCPUS / %{_smp_ncpus_max}). If LTO falls back to detecting numbe
> I can see -flto=auto being useful for the average upstream makefile defaults
> but I'm not convinced this is the right thing to do in rpm context: we'd want
> our parallel activities controlled via the same central tunables
> ($RPM_BUILD_NCPUS / %{_smp_ncpus_max}).
Which is way you want to co
Maybe I'm missing something fundamental here, but I don't understand how is
-flto=auto supposed to help with making builds more reproducable. In rpm
context, the number of cpus make uses is typically set by rpm (whether
configuration or "all available"), and if you let it fall back to "as many
> Maybe I'm missing something fundamental here, but I don't understand how is
> -flto=auto supposed to help with making builds more reproducable.
Because if you are given a builder with 8 cores:
```
[ 40s] + export 'CFLAGS=-O2 -Wall -D_FORTIFY_SOURCE=2
-fstack-protector-strong -funwind-tables
> Then rpm -qp --qf "%{OPTFLAGS}" $rpm will show you the -flto=8 and that's the
> problem for reproducibility.
Ah... now I get it. I somehow got the impression that it was the linking that
produced different results with different number of cpus (as often happens with
parallel compression etc)
> Ah... now I get it. I somehow got the impression that it was the linking that
> produced different results with different number of cpus (as often happens
> with parallel compression etc)
That's good we understand each other.
No, our parallel linking in LTO is stable. Right now we divide the j
12 matches
Mail list logo