Re: armv7l status?
W dniu 14.05.2020 o 14:34, Florian Weimer pisze: > Just to be clear here, armhfp is *not* the common denominator of all > 32-bit Arm architectures. It does not cover the overall architecture in > the sense that is compatible to with everything out there. (I'm not > sure if that is even possible.) Fedora's 32-bit Arm requirements have > always been fairly advanced, resulting in fewer compatible devices than > other Linux distributions. armhfp (Fedora, CentOS) is same as armhf (Debian, Ubuntu) as this was discussed years ago in a group of ARM distro developers when there was a need for v7 target. armhf(p) == armv7 vfp3-d16, no neon There are armv7 cpus with vfp4, armv7 with vfp3-d32, almost all armv7 chips nowadays have neon. And all them are compatible with armhf distros. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: armv7l status?
On Thu, May 14, 2020 at 8:13 am, Stephen John Smoogen wrote: You keep thinking that ARM is a secondary architecture and it would be on alt.fedoraproject.org. ARM is a primary architecture and so would NOT show up on alt. ARM has been a primary architecture for many releases so this isn't new. Honestly, all architectures should be displayed on alt. Or at least there should be a prominent pointer to where the other architectures may be found, if we want to maintain this distinction between "primary" and "alternate." Otherwise people are going to assume they are not supported. I mean, if I can't figure this out without asking devel@, what chance do our users have...? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: armv7l status?
On Wed, May 13, 2020 at 12:49:35PM -0500, Michael Catanzaro wrote: > On Wed, May 13, 2020 at 9:51 am, Stephen John Smoogen > wrote: > >Those pages are needing some love and care as aarch64 should not > >be on it anymore. Currently the primary architectures that Fedora > >builds against are > > > > [smooge@batcave01 32]$ ls -l Workstation/ > >total 12 > >drwxr-xr-x. 3 263 263 4096 2020-04-23 00:09 aarch64/ > >drwxr-xr-x. 3 263 263 4096 2020-04-22 22:27 armhfp/ > >drwxr-xr-x. 3 263 263 4096 2020-04-22 23:08 x86_64/ > > So we used to distinguish between primary and secondary > architectures in that package maintainers were responsible for > primary architectures and architecture teams were responsible for > secondary architectures. > > Now, all architectures are built on koji and all builds have to > succeed. So we're forced to care about ppc64le and s390x whether you > call them "primary" or not. Is it still a useful distinction to > have? There are unofficial architectures still which are not being built in Koji. RISC-V (riscv64) being probably the most notable. David rebuilds all of Fedora (@ http://fedora.riscv.rocks/koji/) and deals with broken packages. You may occasionally see him submitting fixes upstream and/or into Fedora. Rich. > >The workstation image for armhfp is stored in > > > >[smooge@batcave01 releases]$ ls -1 > >32/Workstation/armhfp/images/Fedora-Workstation-* > >32/Workstation/armhfp/images/Fedora-Workstation-32-1.6-armhfp-CHECKSUM > >32/Workstation/armhfp/images/Fedora-Workstation-armhfp-32-1.6-sda.raw.xz > > OK, that's extremely confusing. I assumed ARM was no longer > supported because it's not found on alt.fedoraproject.org. I'm not > sure if removing architectures from there is a good idea. Anyway, OK > then, I guess I still have to care about it. :) > > Why do we call it armv7hl on koji but armhfp for the download > images? Consistent terminology would be nice. > > Michael > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: armv7l status?
On Thu, May 14, 2020 at 7:34 AM Florian Weimer wrote: > * Peter Robinson: > > > armhfp is "Arm hard floating point" which covers the overall ARM 32 > > bit architecture, there can be different variants in there, armv6, > > armv7, armv7+NEON, armv8 (the 32 bit variant as opposed to aarch64) > > and so on... > > Just to be clear here, armhfp is *not* the common denominator of all > 32-bit Arm architectures. It does not cover the overall architecture in > the sense that is compatible to with everything out there. (I'm not > sure if that is even possible.) Fedora's 32-bit Arm requirements have > always been fairly advanced, resulting in fewer compatible devices than > other Linux distributions. > But AFAIK, not raspberry Pi 4 yet :) Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: armv7l status?
> > armhfp is "Arm hard floating point" which covers the overall ARM 32 > > bit architecture, there can be different variants in there, armv6, > > armv7, armv7+NEON, armv8 (the 32 bit variant as opposed to aarch64) > > and so on... > > Just to be clear here, armhfp is *not* the common denominator of all > 32-bit Arm architectures. It does not cover the overall architecture in > the sense that is compatible to with everything out there. (I'm not > sure if that is even possible.) Fedora's 32-bit Arm requirements have > always been fairly advanced, resulting in fewer compatible devices than > other Linux distributions. That is correct, the armhfp was a general designator we chose in Fedora. The wider arm 32 bit ecosystem is wild so we decided to choose a subset that was achievable and covered most of the use cases. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: armv7l status?
* Peter Robinson: > armhfp is "Arm hard floating point" which covers the overall ARM 32 > bit architecture, there can be different variants in there, armv6, > armv7, armv7+NEON, armv8 (the 32 bit variant as opposed to aarch64) > and so on... Just to be clear here, armhfp is *not* the common denominator of all 32-bit Arm architectures. It does not cover the overall architecture in the sense that is compatible to with everything out there. (I'm not sure if that is even possible.) Fedora's 32-bit Arm requirements have always been fairly advanced, resulting in fewer compatible devices than other Linux distributions. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: armv7l status?
* Stephen John Smoogen: > When x86_64 splits into 48 bit memory path to some larger memory (60 > bit I think is discussed) sometime in the future, we will probably > still call it x86_64 but build x86_64b packages. This has already happened. You did not notice it because it did not require x86_64b packages. It's possible to hide most of the effect of the change by not handing higher memory regions to userspace unless it requested it explicitly. This is similar to how things are handled on ppc64le. aarch64 had a similar transition, but opted for a hard break, if I recall correctly. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: armv7l status?
> > Those pages are needing some love and care as aarch64 should not be > > on it anymore. Currently the primary architectures that Fedora builds > > against are > > > > [smooge@batcave01 32]$ ls -l Workstation/ > > total 12 > > drwxr-xr-x. 3 263 263 4096 2020-04-23 00:09 aarch64/ > > drwxr-xr-x. 3 263 263 4096 2020-04-22 22:27 armhfp/ > > drwxr-xr-x. 3 263 263 4096 2020-04-22 23:08 x86_64/ > > So we used to distinguish between primary and secondary architectures > in that package maintainers were responsible for primary architectures > and architecture teams were responsible for secondary architectures. That's not exactly true, and secondary architectures has been dead since Fedora 26. We have Primary, Alternate and Experimental architectures and Blocking and non blocking artefacts. Primary are x86 and Arm architectures, Alternate are Power and s390x and Experimental are things like RISC-V. > Now, all architectures are built on koji and all builds have to > succeed. So we're forced to care about ppc64le and s390x whether you > call them "primary" or not. Is it still a useful distinction to have? That's one of the reasons we killed off secondary. > > The workstation image for armhfp is stored in > > > > [smooge@batcave01 releases]$ ls -1 > > 32/Workstation/armhfp/images/Fedora-Workstation-* > > 32/Workstation/armhfp/images/Fedora-Workstation-32-1.6-armhfp-CHECKSUM > > 32/Workstation/armhfp/images/Fedora-Workstation-armhfp-32-1.6-sda.raw.xz > > OK, that's extremely confusing. I assumed ARM was no longer supported > because it's not found on alt.fedoraproject.org. I'm not sure if > removing architectures from there is a good idea. Anyway, OK then, I > guess I still have to care about it. :) > > Why do we call it armv7hl on koji but armhfp for the download images? > Consistent terminology would be nice. armhfp is "Arm hard floating point" which covers the overall ARM 32 bit architecture, there can be different variants in there, armv6, armv7, armv7+NEON, armv8 (the 32 bit variant as opposed to aarch64) and so on... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: armv7l status?
On Wed, 13 May 2020 at 13:50, Michael Catanzaro wrote: > On Wed, May 13, 2020 at 9:51 am, Stephen John Smoogen > wrote: > > Those pages are needing some love and care as aarch64 should not be > > on it anymore. Currently the primary architectures that Fedora builds > > against are > > > > [smooge@batcave01 32]$ ls -l Workstation/ > > total 12 > > drwxr-xr-x. 3 263 263 4096 2020-04-23 00:09 aarch64/ > > drwxr-xr-x. 3 263 263 4096 2020-04-22 22:27 armhfp/ > > drwxr-xr-x. 3 263 263 4096 2020-04-22 23:08 x86_64/ > > So we used to distinguish between primary and secondary architectures > in that package maintainers were responsible for primary architectures > and architecture teams were responsible for secondary architectures. > > Now, all architectures are built on koji and all builds have to > succeed. So we're forced to care about ppc64le and s390x whether you > call them "primary" or not. Is it still a useful distinction to have? > > > The workstation image for armhfp is stored in > > > > [smooge@batcave01 releases]$ ls -1 > > 32/Workstation/armhfp/images/Fedora-Workstation-* > > 32/Workstation/armhfp/images/Fedora-Workstation-32-1.6-armhfp-CHECKSUM > > 32/Workstation/armhfp/images/Fedora-Workstation-armhfp-32-1.6-sda.raw.xz > > OK, that's extremely confusing. I assumed ARM was no longer supported > because it's not found on alt.fedoraproject.org. I'm not sure if > removing architectures from there is a good idea. Anyway, OK then, I > guess I still have to care about it. :) > > You keep thinking that ARM is a secondary architecture and it would be on alt.fedoraproject.org. ARM is a primary architecture and so would NOT show up on alt. ARM has been a primary architecture for many releases so this isn't new. > Why do we call it armv7hl on koji but armhfp for the download images? > Consistent terminology would be nice. > > The arm architecture has its own weirdness in the same way that we call x86_32 i386 but we build i686 packages. When x86_64 splits into 48 bit memory path to some larger memory (60 bit I think is discussed) sometime in the future, we will probably still call it x86_64 but build x86_64b packages. The world of building for hardware is messy.. > Michael > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: armv7l status?
James, so you guys still rely on koji for builds? That's relevant for this thread m On Wed, May 13, 2020, 5:31 PM James Cameron wrote: > Thanks Martin. > > That release was a respin of Fedora 18. Regressions in Fedora 20, and > our downsize at OLPC, stopped us tracking Fedora. > > Lubomir Rintel has been working on OLPC XO-1.75 and XO-4 support for > Fedora rawhide. > > Alex Perez has mentioned that OLPC XO-1.75 can boot Fedora latest with > some care. > > On Wed, May 13, 2020 at 09:25:54AM -0400, Martin Langhoff wrote: > > Looping in James Cameron - as recently as Jan 2020 he's made a release > for > > armv7l > > > > [1]http://lists.laptop.org/pipermail/devel/2020-January/039079.html > > > > hth ~ martin > > > > On Wed, May 13, 2020 at 9:21 AM Martin Langhoff <[2] > martin.langh...@gmail.com> > > wrote: > > > > On Wed, May 13, 2020 at 9:14 AM Michael Catanzaro <[3] > mcatanz...@gnome.org> > > wrote: > > > > Why are we still doing builds for armv7l in koji? > > > > Presumably for OLPC packages. That ARM build target is/was the right > one > > for the ARM CPUs on those. > > > > I haven't been in the loop for a while, but until recently there was > a > > group of volunteers still cranking packages for ARM-based XO laptops. > > > > cheers, > > > > m > > -- > > [4]martin.langh...@gmail.com > > - ask interesting questions ~ [5] > http://linkedin.com/in/martinlanghoff > > - don't be distracted~ [6] > http://github.com/martin-langhoff > >by shiny stuff > > > > -- > > [7]martin.langh...@gmail.com > > - ask interesting questions ~ [8] > http://linkedin.com/in/martinlanghoff > > - don't be distracted~ [9]http://github.com/martin-langhoff > >by shiny stuff > > > > References: > > > > [1] http://lists.laptop.org/pipermail/devel/2020-January/039079.html > > [2] mailto:martin.langh...@gmail.com > > [3] mailto:mcatanz...@gnome.org > > [4] mailto:martin.langh...@gmail.com > > [5] http://linkedin.com/in/martinlanghoff > > [6] http://github.com/martin-langhoff > > [7] mailto:martin.langh...@gmail.com > > [8] http://linkedin.com/in/martinlanghoff > > [9] http://github.com/martin-langhoff > > -- > James Cameron > http://quozl.netrek.org/ > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: armv7l status?
On Wed, May 13, 2020 at 9:51 am, Stephen John Smoogen wrote: Those pages are needing some love and care as aarch64 should not be on it anymore. Currently the primary architectures that Fedora builds against are [smooge@batcave01 32]$ ls -l Workstation/ total 12 drwxr-xr-x. 3 263 263 4096 2020-04-23 00:09 aarch64/ drwxr-xr-x. 3 263 263 4096 2020-04-22 22:27 armhfp/ drwxr-xr-x. 3 263 263 4096 2020-04-22 23:08 x86_64/ So we used to distinguish between primary and secondary architectures in that package maintainers were responsible for primary architectures and architecture teams were responsible for secondary architectures. Now, all architectures are built on koji and all builds have to succeed. So we're forced to care about ppc64le and s390x whether you call them "primary" or not. Is it still a useful distinction to have? The workstation image for armhfp is stored in [smooge@batcave01 releases]$ ls -1 32/Workstation/armhfp/images/Fedora-Workstation-* 32/Workstation/armhfp/images/Fedora-Workstation-32-1.6-armhfp-CHECKSUM 32/Workstation/armhfp/images/Fedora-Workstation-armhfp-32-1.6-sda.raw.xz OK, that's extremely confusing. I assumed ARM was no longer supported because it's not found on alt.fedoraproject.org. I'm not sure if removing architectures from there is a good idea. Anyway, OK then, I guess I still have to care about it. :) Why do we call it armv7hl on koji but armhfp for the download images? Consistent terminology would be nice. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: armv7l status?
On Wed, 13 May 2020 at 09:15, Michael Catanzaro wrote: > Hi, > > Why are we still doing builds for armv7l in koji? > > I see that it is not represented on https://alt.fedoraproject.org/alt/ > so I presume we no longer support installing this architecture. Is it > really only used for multilib, like the i686 packages? If so, is it > really necessary? If we're not producing install media, we should > probably just turn it off? > > Those pages are needing some love and care as aarch64 should not be on it anymore. Currently the primary architectures that Fedora builds against are [smooge@batcave01 32]$ ls -l Workstation/ total 12 drwxr-xr-x. 3 263 263 4096 2020-04-23 00:09 aarch64/ drwxr-xr-x. 3 263 263 4096 2020-04-22 22:27 armhfp/ drwxr-xr-x. 3 263 263 4096 2020-04-22 23:08 x86_64/ The workstation image for armhfp is stored in [smooge@batcave01 releases]$ ls -1 32/Workstation/armhfp/images/Fedora-Workstation-* 32/Workstation/armhfp/images/Fedora-Workstation-32-1.6-armhfp-CHECKSUM 32/Workstation/armhfp/images/Fedora-Workstation-armhfp-32-1.6-sda.raw.xz -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: armv7l status?
> > Also, multilib for aarch64 + armv7hl is not "A Thing" (TM), IIRC > > because no aarch64 hardware really supports that. > > > > There is hardware that does support it, but we pretend they don't > exist in Fedora. After all, the Raspberry Pi is an example of this. No, there's HW that will run in ARMv7 mode or aarch64 mode but not always at the same time, for example you use you have to set a flag in the config.txt so it will run in aarch64 mode when it boots. The architectures are also not compatible, in the case of x86_64 it's a super set of x86 adding 64bit instructions as an extension to the 32 bit architecture so 32bit is guaranteed to be there when you have an x86_64 chip where on Arm they are two bits of silicon on the same chip, the ISA is different and the 64 bit architecture isn't a superset of the 32 bit architecture. On a ARMv8 chip the 32 bit silicon is optional, some silicon vendors, such as the SoCs in the Raspberry Pi 3 and 4 have it but there's a lot that don't, and newer gens of chips will even reduce this more. So while there are some that can run both 32 bit and 64 bit code side by side it's not multilib in the traditional x86 sense where they run side by side because the instructions are the same and can be queued to run on the same silicon. There is no way to tell until the code tries to run whether the chip is capable of this so you could use a aarch64 bit dnf/rpm stack to install ARMv7 binaries only to have them fail when you try to run them (or in rpm post install scripts) which gives a terrible experience. Or if you have a VM that migrates from one platform to another which doesn't support it and things start to break. The multilib support, even in x86, is pretty glued together with exceptions all over the place, so the cost vs benefit of actually supporting this in any level of sane manner was considered not worth it. Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: armv7l status?
On Wed, May 13, 2020 at 9:20 AM Fabio Valentini wrote: > > Also, multilib for aarch64 + armv7hl is not "A Thing" (TM), IIRC > because no aarch64 hardware really supports that. > There is hardware that does support it, but we pretend they don't exist in Fedora. After all, the Raspberry Pi is an example of this. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: armv7l status?
> Why are we still doing builds for armv7l in koji? Because it's still a primary architecture and actively used and supported. > I see that it is not represented on https://alt.fedoraproject.org/alt/ > so I presume we no longer support installing this architecture. Is it > really only used for multilib, like the i686 packages? If so, is it > really necessary? If we're not producing install media, we should > probably just turn it off? We're producing an installer plus a number of images for a number of the desktops, plus a server, minimal as well as IoT related stuff. Actually it's never been supported by multilib so that would never be the reason. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: armv7l status?
Looping in James Cameron - as recently as Jan 2020 he's made a release for armv7l http://lists.laptop.org/pipermail/devel/2020-January/039079.html hth ~ martin On Wed, May 13, 2020 at 9:21 AM Martin Langhoff wrote: > On Wed, May 13, 2020 at 9:14 AM Michael Catanzaro > wrote: > >> Why are we still doing builds for armv7l in koji? >> > > Presumably for OLPC packages. That ARM build target is/was the right one > for the ARM CPUs on those. > > I haven't been in the loop for a while, but until recently there was a > group of volunteers still cranking packages for ARM-based XO laptops. > > cheers, > > > m > -- > martin.langh...@gmail.com > - ask interesting questions ~ http://linkedin.com/in/martinlanghoff > - don't be distracted~ http://github.com/martin-langhoff >by shiny stuff > -- martin.langh...@gmail.com - ask interesting questions ~ http://linkedin.com/in/martinlanghoff - don't be distracted~ http://github.com/martin-langhoff by shiny stuff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: armv7l status?
On Wed, May 13, 2020 at 9:14 AM Michael Catanzaro wrote: > Why are we still doing builds for armv7l in koji? > Presumably for OLPC packages. That ARM build target is/was the right one for the ARM CPUs on those. I haven't been in the loop for a while, but until recently there was a group of volunteers still cranking packages for ARM-based XO laptops. cheers, m -- martin.langh...@gmail.com - ask interesting questions ~ http://linkedin.com/in/martinlanghoff - don't be distracted~ http://github.com/martin-langhoff by shiny stuff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: armv7l status?
On Wed, May 13, 2020 at 3:14 PM Michael Catanzaro wrote: > > Hi, > > Why are we still doing builds for armv7l in koji? > > I see that it is not represented on https://alt.fedoraproject.org/alt/ > so I presume we no longer support installing this architecture. Is it > really only used for multilib, like the i686 packages? If so, is it > really necessary? If we're not producing install media, we should > probably just turn it off? There definitely are images produced for 32-bit arm: https://arm.fedoraproject.org/ I don't know why they are on a separate "arm" page instead of on the "alt" page with aarch64 and other alternative architectures ... Also, multilib for aarch64 + armv7hl is not "A Thing" (TM), IIRC because no aarch64 hardware really supports that. Fabio > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
armv7l status?
Hi, Why are we still doing builds for armv7l in koji? I see that it is not represented on https://alt.fedoraproject.org/alt/ so I presume we no longer support installing this architecture. Is it really only used for multilib, like the i686 packages? If so, is it really necessary? If we're not producing install media, we should probably just turn it off? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
