Having slept on it, this actually moves rpm in the wrong direction. To solve
the issue, (build)host and target optflags need to be separate macros, and for
compatibility with the vast majority of packages, plain %optflags needs to
always mean *target* optflags, not host.
--
Reply to this email
Ran into a related issue in https://bugzilla.redhat.com/show_bug.cgi?id=2231727
/ #2622.
Chased %_build_arch to its origin:
https://bugzilla.redhat.com/show_bug.cgi?id=36663. For the click-allergic, the
point is to detect cross-building for which %_target_cpu and %_build_cpu
doesn't work beca
@pmatilai pushed 1 commit.
4c8b6996263966912b184576e58d8056099cd88c Behave more consistently when target
arch %optflags are not defined
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2622/files/b1c99cc21dd8dc984734cd2a66e48a5676280dee..4c8b6996263966912b184576e58d805
Anytime --target is used, there's an unresolvable ambiguity as to what a
particular macro might mean, it could be either the host or the target,
depending whether the platform file for the target happened to override it. If
it did, then we can no longer locate paths on the build host based on ma
Apparently this breaks scl-utils:
https://bugzilla.redhat.com/show_bug.cgi?id=2233454
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2575#issuecomment-1687907845
You are receiving this because you are subscribed to this thread.
Message
It's another case where macro ambiguity causes problems: are the macros
supposed to reflect the buildhost or the target? Sometimes they're one,
sometimes the other, and no way to tell which.
%_root_prefix is a strange name for this, in the rpm context at least where
root often means an chroot s
Commit cececfb6851234aca3e8d102de1c192c6bdf3e67 introduced %_root_prefix macro
but this unnecessarily breaks widespread use in scl-utils:
https://bugzilla.redhat.com/show_bug.cgi?id=2233454
Just query the value from pkg-config if available and otherwise use hardcoded
value pointing to /usr inst
@pmatilai pushed 1 commit.
017e28b0da96f5b0f189f8e4f334c80960d36f06 Move the %_sysusersdir definition to
a more logical spot
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2625/files/20b989f36d1c9665157708b1bf36a8e97ef3ce1d..017e28b0da96f5b0f189f8e4f334c80960d36f06
Y
Note that even if scl-utils was changed to test for something else, this clash
has a potential of breaking rpm instead. scl-utils was there first by a long
shot, we better let them have the macro.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/r
Merged #2625 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2625#event-10157203282
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
We should probably put those build macros into separate macro files - one per
build type. That makes it easier for people to add their own and to hand them
over to other communities, if we want to get rid of them upstream.
Also the macros file is too big already.
--
Reply to this email directl
Sure, I just stuffed them there because... we don't have anything else at the
moment.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2620#issuecomment-1688337433
You are receiving this because you are subscribed to this thread.
Message
and make the project REUSE compatible.
See https://reuse.software/
This will more explicit what license each file is under and will allow to
quickly review the overall license of the whole project.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management
found another breakage:
`sed -i -e 's/-j2/%{?_smp_mflags}/' setup.py`
in
https://github.com/bmwiedemann/openSUSE/blob/master/packages/p/python-python-poppler/python-python-poppler.spec#L61
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues
Yes, there will be any number of ways the parsed spec inclusion can trip up
bit-for-bit differences. "Breakage" is a strange and strong word for it,
another angle to look at it is to use it as a tool to help reproducability: if
the parsed spec (which is what the build will actually use, after al
15 matches
Mail list logo
