Possibly a straight up revert is the right thing to do. I was trying to keep
the intention of the previous patch as much as possible.
In terms of VFP/VFPv3 it is a requirement of ARMv8, but in theory (although I'm
not sure why you'd want to) you could have softfp builds on armv8 so to keep
comp
aths.
The 8c3a7b8fa commit where this functionality also has other issues
it didn't include the VFP HWCAP for armv6 which rpm included
previously, but just the VFP3, and NEON is a requirement, and hence
always present in armv8 so it's assumed that it's part of armv8.
Signed-off-by
> Oh, ugh. Now that I started rebasing rawhide to 4.15.1 I notice Fedora also
> reverted
> [8c3a7b8](https://github.com/rpm-software-management/rpm/commit/8c3a7b8fa92b49a811fe36b60857b12f5d7db8a8)
> and upstream should've probably done the same because now the detection code
> can come up with
> @pmatilai I don't know of any publicly distributed RPMs in this manner yet.
>
> That said, is it possible to make it so that `arm64` causes `aarch64` RPMs to
> be created? When I wrote
> [236d6f5](https://github.com/rpm-software-management/rpm/commit/236d6f5a2b924266b1249a82875b595e8758c52b),
> Nobody has answered my earlier question, so lets repeat that:
>
> **Are the actual .arm64 rpm packages in the wild?**
>
> If not, then there's zero reason for rpm (and others) to carry the compat
> crap around, and all the more reason to revert that stuff before it spreads.
None that I'm awar
> As for arm64, the cat is out of the bag though as it has been shipped in a
> stable rpm release now.
It hasn't shipping in a stable Fedora release though, and while I understand
the concerns of upstream maintainers, my concern is primarily for the
Fedora/RHEL/CentOS ecosystem.
--
You are re
> @nullr0ute , let me get this straight: it's the armv8* maps that are actually
> breaking Fedora, the arm64 is just something you disagree with but isn't
> breaking anything (at the moment anyway), right?
Correct, but we do not want to ship the arm64 mapping in a stable release
because it is n
> I don't agree at all. There is no conceivable reason that this would cause a
> "support nightmare", given the common acceptance of `arm64` == `aarch64`
> across tools and operating systems. In doing this, tools like `alien` work
> out of the box properly for going back and forth between rpm an
> I think upstream rpm should never ever _generate_ packages with "arm64" as
> architecture, but having a courtesy compat mapping to it seems mostly
> harmless. So maybe drop the build side mapping, but leave the other compat
> mappings in place? That'd be similar to how em64t alias is handled.
> As for the `arm64`/`aarch64` thing, I wrote it after encountering a number of
> issues at work trying to deal with converting debs to rpms for AArch64 (for
> reasons I can't go into, unfortunately) as well as having people wanting to
> use the Debian arch names in spec files (because things l
I've dropped the patches for armv5tl
--
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/901#issuecomment-543190334___
Rpm-maint mail
@nullr0ute pushed 1 commit.
d32c1e604219fbfe8923324fb12c870bf3139e32 Remove problematic sub variants of
armv8 and related
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/901/files/790b0ec08027ba1676acc
> @nullr0ute `armv5tl` was used in Mageia, and I upstreamed those changes from
> Mageia as the rpm comaintainer to reduce the patch load and make our rpms
> workable on other distros (having "special" architectures is not great...).
> We used it as the baseline "synthetic" architecture to suppor
> I don't know if GitHub has anything to offer for such an "special interest
> group" functionality, but one possible old-school solution could be something
> like a kernel style MAINTAINERS file where subsystem maintainers (be them
> individuals or special interest groups) can announce themselv
> Said patches sat in our public pull-requests for significant time, some
> literally for months. Nobody objected.
As the Arm maintainer in Fedora, mostly in my spare time, I unfortunately don't
have the time to follow every list of every bit of software available in Fedora
to see how it might
> This whole PR is awful.
Please keep the discussion technical. Comments like these are a matter of
opinion and are useful in productive technical discussion.
> And the commit about `aarch64` and `arm64` "not being equivalent": tough. In
> virtually _every_ single non-rpm/non-gcc platform, the
> Note that even that fix as it stands will break OpenMandriva, who wrote that
> to support their distribution. If you want to alter it, work with @berolinux
> to fix it properly.
I don't see where you support armv5tl, and you provided no details in the
commit as to why it was being added, but
> As noted above, this needs to be worked out between various Arm maintainers
> to come up with solutions that work for everybody. We're not on a seesaw.
Maybe if there was engagement from the Arm maintainers in other distros to
confirm they were OK with the patches before they were merged we wo
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1562084
Signed-off-by: Peter Robinson <pbrobin...@gmail.com>
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/901
-- Commit Summary --
* Revert "rpmrc: Add architecture compatib
19 matches
Mail list logo
