Closed #3115 as completed via #3130.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3115#event-12958559772
You are receiving this because you are subscribed to this thread.
Message ID:
___
R
It happens here if I `mock --rebuild any.src.rpm`, nothing special required.
Probably koji detects noarch packages and then puts forcearch into the config
or something.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3115#issuecomment-
Oh, thanks but I actually meant a reproducer use-case or such but okay I can
reproduce now.
It's pretty weird because under koji, the --target is noarch in mock as it
should (eg
https://kojipkgs.fedoraproject.org//packages/python-pluggy/1.3.0/3.fc40/data/logs/noarch/build.log)
but locally it se
https://github.com/rpm-software-management/mock/blob/3560d386d32e0d96e50f1495a0ee66c0e9d3fe55/mock/py/mockbuild/backend.py#L744
https://github.com/rpm-software-management/mock/blob/3560d386d32e0d96e50f1495a0ee66c0e9d3fe55/mock/py/mockbuild/backend.py#L43
https://github.com/rpm-software-management
Can you point me to a case where it does that?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3115#issuecomment-2133382647
You are receiving this because you are subscribed to this thread.
Message ID: __
I agree that `rpmbuild -bb --target x86_64 noarch.spec` is nonsense, but (at
least here, and I don't see anything too unusual in the config) mock does that.
Probably best to just not make mock pass --target unless it's crosscompiling.
--
Reply to this email directly or view it on GitHub:
https:/
I mean, I know mock always passes --target, and that's been the right thing to
do (and still isn't wrong, it's just no longer strictly needed). But it passes
--target noarch when building noarch packages, and --target normally.
--
Reply to this email directly or view it on GitHub:
https://gith
The ticket is still open for a reason, the linked PR was just band-aid as it
states.
You mean 'rpmbuild -bb --target x86_64 noarch.spec' ? Why would you do *that*?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3115#issuecomment-21326
Even with this patch, it can still be triggered by using passing `--target
x86_64` while building a package that switches to noarch with `BuildArch:
noarch`. (`mock` does this, for example)
Probably the relevant bits of the macros are now parsed before `BuildArch` but
after `--target`.
--
Repl
Commit 8535694599ee7f35747d44e2ea0a62dc5e8880e5 hinged the entire debuginfo
generation logic around %_enable_debug_packages, including getting it right
(disabled) for noarch packages from the platform configuration macros. The
problem with that, %_enable_debug_packages is *intended* to be a dist
10 matches
Mail list logo
