Open ThisNekoGuy opened 2 years ago
There's a flag for arch-nspawn
to not set arch. I guess that would fix it. I guess setting this is for cross compiling. So there should be not too much issue setting it by default.
@Morganamilo
I recently reported a bug about makechrootpkg about the devtools
package; supposedly how it's handled is that you can leave a file in /usr/share/devtools/setarch-aliases.d/<architecture-name-file>
with the contents left as "x86_64"
However, even though this will permit makechrootpkg
to accept that as valid, it'll continue to produce "x86_64" labeled packages (perhaps because it may not align with the arch
value set in PKGBUILDs?). Paru's implementation later expects to find the CARCH
named package in the repo update but then doesn't find it because of that.
Additionally, their solution causes a similar problem for makepkg
itself, because then makepkg
can automatically deny builds because the targeted PKGBUILD may not have the same arch
set. Which kind of makes this part of the issue on the Paru side probably related to https://github.com/Morganamilo/paru/issues/188 because it would involve overriding the PKGBUILD in some way, unless upstream decides to finally own the fact that just because it's intentionally a pain to change the CARCH
doesn't mean people don't compile for their own architectures anyway and that inhibiting that just because of what Arch officially supports on paper is stupid.
@Morganamilo I apologize for being heated that day; I was just tired of having dispute this upstream when it shouldn't be an issue to fight about in the first place. :/
Adding that alias to setarch
does let the packages build in the chroot
, but since some architecture options are of course not going to be added automatically as-is, I think it would be a good idea to parse CARCH and either append or replace the value(s) for PKGBUILDs to easily solve the latter part of this problem for when it tries to update local DBs but can't because it's looking for x
architecture but makechrootpkg
hands us an "x86-64" named package (which might be assumed to be that because the arch variable didn't take CARCH into account).
Another option would be to just rename the produced package to x
architecture so that the DB update doesn't get confused.
I'm actually trying to look into this myself but I'm new to rust.
wouldn't it be -v3 instead of _v3?
I think you shall only change -march=x86-64-v3 -mtune=native, not change CARCH.
CARCH is only for i686 and x86_64, there's no x86_64_v3 or x86_64-v3 for CARCH.
Affected Version
paru v1.9.0.r13.g48fe138 - libalpm v13.0.1
Description
Setting
CARCH
tox86_64_v3
inmakepkg.conf
causes building packages in chroots to fail with the message:setarch: x86_64_v3: Unrecognized architecture
However, I also run a Ryzen 3700X and I know my CPU supports it (and runningmakepkg
normally doesn't have this issue). For reference:And to be clear, it's not because of the underscores, doing it with hyphens produces the same result.
Output
Terminal output
paru.conf
makepkg.conf
pacman.conf