There is a proposal[1] in upstream GlusterFS to drop 32-bit arches.
The original proposal was to drop 32-bit with GlusterFS-7. GlusterFS-7 will land in Fedora 31/rawhide soon. More than likely though it will not be official until GlusterFS-8, which will probably land, accordingly, after Fedora 31 GA in Fedora 32/rawhide.
[1] https://github.com/gluster/glusterfs/issues/702
--
Kaleb
There is a proposal[1] in upstream GlusterFS to drop 32-bit arches.
The original proposal was to drop 32-bit with GlusterFS-7. GlusterFS-7 will land in Fedora 31/rawhide soon. More than likely though it will not be official until GlusterFS-8, which will probably land, accordingly, after Fedora 31 GA in Fedora 32/rawhide.
[1] https://github.com/gluster/glusterfs/issues/702
--
Kaleb
_______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@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-announce@lists.fedorapro...
On Mon, Aug 5, 2019 at 9:51 AM Kaleb Keithley kkeithle@redhat.com wrote:
There is a proposal[1] in upstream GlusterFS to drop 32-bit arches.
The original proposal was to drop 32-bit with GlusterFS-7. GlusterFS-7 will land in Fedora 31/rawhide soon. More than likely though it will not be official until GlusterFS-8, which will probably land, accordingly, after Fedora 31 GA in Fedora 32/rawhide.
Kaleb, when this is determined upstream, can you please file this as a Fedora 32 (or whatever version) change proposal? Note that the Fedora 31 Change proposal deadline has already passed and that F31 branches from rawhide on 13 August.
On 05. 08. 19 15:36, Kaleb Keithley wrote:
There is a proposal[1] in upstream GlusterFS to drop 32-bit arches.
The original proposal was to drop 32-bit with GlusterFS-7. GlusterFS-7 will land in Fedora 31/rawhide soon. More than likely though it will not be official until GlusterFS-8, which will probably land, accordingly, after Fedora 31 GA in Fedora 32/rawhide.
What about the dependent packages?
$ repoquery --repo=rawhide{,-source} --whatrequires glusterfs-devel glusterfs-api-devel-0:6.4-3.fc31.i686 glusterfs-api-devel-0:6.4-3.fc31.x86_64 libvirt-0:5.5.0-2.fc31.src qemu-2:4.1.0-0.1.rc2.fc31.src samba-2:4.10.6-0.fc31.2.src uwsgi-0:2.0.18-2.fc31.src
$ repoquery --repo=rawhide{,-source} --whatrequires glusterfs-api-devel gluster-block-0:0.4-4.fc31.src glusterfs-coreutils-0:0.3.1-2.fc31.src libvirt-0:5.5.0-2.fc31.src nfs-ganesha-0:2.8.2-3.fc31.src qemu-2:4.1.0-0.1.rc2.fc31.src samba-2:4.10.6-0.fc31.2.src scsi-target-utils-0:1.0.70-9.fc31.src tcmu-runner-0:1.1.3-2.fc26.src uwsgi-0:2.0.18-2.fc31.src
On Mon, Aug 5, 2019 at 3:44 PM Kaleb Keithley kkeithle@redhat.com wrote:
There is a proposal[1] in upstream GlusterFS to drop 32-bit arches.
The original proposal was to drop 32-bit with GlusterFS-7. GlusterFS-7 will land in Fedora 31/rawhide soon. More than likely though it will not be official until GlusterFS-8, which will probably land, accordingly, after Fedora 31 GA in Fedora 32/rawhide.
Will clients still work, is this server only?
On Mon, Aug 5, 2019 at 11:29 AM Peter Robinson pbrobinson@gmail.com wrote:
On Mon, Aug 5, 2019 at 3:44 PM Kaleb Keithley kkeithle@redhat.com wrote:
There is a proposal[1] in upstream GlusterFS to drop 32-bit arches.
The original proposal was to drop 32-bit with GlusterFS-7. GlusterFS-7
will land in Fedora 31/rawhide soon. More than likely though it will not be official until GlusterFS-8, which will probably land, accordingly, after Fedora 31 GA in Fedora 32/rawhide.
Will clients still work, is this server only?
Existing 32-bit GlusterFS clients (glusterfs-7 and earlier) should continue to work just fine — AFAIK — connecting to 64-bit glusterfs servers.
The proposal[1] as it stands is to drop all aspects of 32-bit support, i.e. client, server, gfapi, etc., going forward from glusterfs-8. This should be considered advanced notice that consumers that have dependencies need to plan accordingly.
Please feel free though to add your thoughts to the issue.
On Mon, Aug 5, 2019 at 9:57 AM Miro Hrončok mhroncok@redhat.com wrote:
On 05. 08. 19 15:36, Kaleb Keithley wrote:
There is a proposal[1] in upstream GlusterFS to drop 32-bit arches.
The original proposal was to drop 32-bit with GlusterFS-7. GlusterFS-7
will land
in Fedora 31/rawhide soon. More than likely though it will not be
official until
GlusterFS-8, which will probably land, accordingly, after Fedora 31 GA
in Fedora
32/rawhide.
What about the dependent packages?
$ repoquery --repo=rawhide{,-source} --whatrequires glusterfs-devel glusterfs-api-devel-0:6.4-3.fc31.i686 glusterfs-api-devel-0:6.4-3.fc31.x86_64 libvirt-0:5.5.0-2.fc31.src qemu-2:4.1.0-0.1.rc2.fc31.src samba-2:4.10.6-0.fc31.2.src uwsgi-0:2.0.18-2.fc31.src
Er, what about them? AIUI, there isn't going to be a i686 Fedora in F31 and beyond. That just leaves armv7hl. Is anyone really running libvirt, qemu, or storage on such platforms? If they are, the number must be vanishingly small. (My own experience with virt on ARM makes me believe that the that the number must be truly microscopic.) Of those that are, is there a reason they can't keep running glusterfs-7 on F30 or F31 indefinitely if they really need 32-bit gluster?
$ repoquery --repo=rawhide{,-source} --whatrequires glusterfs-api-devel
gluster-block-0:0.4-4.fc31.src glusterfs-coreutils-0:0.3.1-2.fc31.src libvirt-0:5.5.0-2.fc31.src nfs-ganesha-0:2.8.2-3.fc31.src qemu-2:4.1.0-0.1.rc2.fc31.src samba-2:4.10.6-0.fc31.2.src scsi-target-utils-0:1.0.70-9.fc31.src tcmu-runner-0:1.1.3-2.fc26.src uwsgi-0:2.0.18-2.fc31.src
tcmu-runner and scsi-target-utils is only for gluster-block, which, by extension should also drop 32-bit at the same time. Likewise, glusterfs-coreutils should also drop 32-bit support.
That only leaves ganesha and samba, which can drop their FSAL_GLUSTER and VFS_GLUSTER plug-ins on 32-bit. Something they have already had to do for Ceph-14 in Fedora 30.
--
Kaleb
On Mon, Aug 05, 2019 at 03:56:19PM +0200, Miro Hrončok wrote:
On 05. 08. 19 15:36, Kaleb Keithley wrote:
There is a proposal[1] in upstream GlusterFS to drop 32-bit arches.
The original proposal was to drop 32-bit with GlusterFS-7. GlusterFS-7 will land in Fedora 31/rawhide soon. More than likely though it will not be official until GlusterFS-8, which will probably land, accordingly, after Fedora 31 GA in Fedora 32/rawhide.
What about the dependent packages?
$ repoquery --repo=rawhide{,-source} --whatrequires glusterfs-devel glusterfs-api-devel-0:6.4-3.fc31.i686 glusterfs-api-devel-0:6.4-3.fc31.x86_64 libvirt-0:5.5.0-2.fc31.src qemu-2:4.1.0-0.1.rc2.fc31.src samba-2:4.10.6-0.fc31.2.src uwsgi-0:2.0.18-2.fc31.src
$ repoquery --repo=rawhide{,-source} --whatrequires glusterfs-api-devel gluster-block-0:0.4-4.fc31.src glusterfs-coreutils-0:0.3.1-2.fc31.src libvirt-0:5.5.0-2.fc31.src nfs-ganesha-0:2.8.2-3.fc31.src qemu-2:4.1.0-0.1.rc2.fc31.src samba-2:4.10.6-0.fc31.2.src scsi-target-utils-0:1.0.70-9.fc31.src tcmu-runner-0:1.1.3-2.fc26.src uwsgi-0:2.0.18-2.fc31.src
This is no big deal from libvirt/qemu POV. We've already trivially adapted to ceph being purged from 32-bit archs by adding conditionals. The same is trivial for glusterfs too.
Regards, Daniel
On 05. 08. 19 19:08, Kaleb Keithley wrote:
Er, what about them? AIUI, there isn't going to be a i686 Fedora in F31 and beyond.
So we keep adding ExcludeArch to more and more packages? Transitively, this will be harder and harder. Shouldn't we instead only explicitly build and select what needs to be built on i686 for multilib?
Kaleb Keithley wrote:
The proposal[1] as it stands is to drop all aspects of 32-bit support, i.e. client, server, gfapi, etc., going forward from glusterfs-8. This should be considered advanced notice that consumers that have dependencies need to plan accordingly.
Please feel free though to add your thoughts to the issue.
The upstream issue actually says they want to keep building 32-bit in their CI, so it should compile just fine, they just won't test it. So an ExcludeArch should not be necessary.
It is quite likely that many upstream projects are never tested on armv7hl by upstream. That doesn't mean we need to ExcludeArch: armv7hl all of them.
Kevin Kofler
On Mon, Aug 5, 2019 at 6:17 PM Kevin Kofler kevin.kofler@chello.at wrote:
Please feel free though to add your thoughts to the issue.
The upstream issue actually says they want to keep building 32-bit in their CI, so it should compile just fine, they just won't test it.
It's already the case that it's not tested. It hasn't been tested in all the years that I've been packaging it.
The upstream issue is about finally making it official that 32-bit is not supported.
Building it on 32-bit in the CI is only to ensure correctness of sprintf format strings. It's a compile-only test.
--
Kaleb
And that is sufficient. As long as it compiles, you can package it. Whether upstream "supports" it or not is irrelevant.
It depends on package maintainer. If upstream dropped 32-bit support, I'd stop building it for that arch in Fedora.
Why would package maintainer have to bear the burden of potential breakage if upstream doesn't test it?
On Tue, 13 Aug 2019, 23:33 Kevin Kofler, kevin.kofler@chello.at wrote:
Kaleb Keithley wrote:
Building it on 32-bit in the CI is only to ensure correctness of sprintf format strings. It's a compile-only test.
And that is sufficient. As long as it compiles, you can package it. Whether upstream "supports" it or not is irrelevant.
Kevin Kofler
If it compiles, ship it!
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On 14. 08. 19 8:55, Frantisek Zatloukal wrote:
It depends on package maintainer. If upstream dropped 32-bit support, I'd stop building it for that arch in Fedora.
Why would package maintainer have to bear the burden of potential breakage if upstream doesn't test it?
If neither of my upstreams officially supports s390x, should I just drop it everywhere?
On Wed, Aug 14, 2019 at 11:29 AM Miro Hrončok mhroncok@redhat.com wrote:
On 14. 08. 19 8:55, Frantisek Zatloukal wrote:
It depends on package maintainer. If upstream dropped 32-bit support,
I'd stop
building it for that arch in Fedora.
Why would package maintainer have to bear the burden of potential
breakage if
upstream doesn't test it?
If neither of my upstreams officially supports s390x, should I just drop it everywhere?
The real question which every packager should ask himself is: Do I have the capacity (time, knowledge, hardware, etc.) to solve problems on non-supported architecture by upstream? And if the answer is no - it is probably better to drop the arch instead of shipping smth that not even the maintainer knows whether it is usable at all (like I used to ship eclipse on 32 bit arm although I'm quite sure it was not usable at all).
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On 8/14/19 10:59 AM, Andreas Tunek wrote:
On Tue, 13 Aug 2019, 23:33 Kevin Kofler, <kevin.kofler@chello.at mailto:kevin.kofler@chello.at> wrote:
Kaleb Keithley wrote: > Building it on 32-bit in the CI is only to ensure correctness of sprintf > format strings. It's a compile-only test. And that is sufficient. As long as it compiles, you can package it. Whether upstream "supports" it or not is irrelevant. Kevin KoflerIf it compiles, ship it!
That's not fun at all.
Attitudes like that is why there's rottenware in the distro that last actually worked sometime around 2011, dutifully rebuilt on each mass-rebuild and even spec cleanups taking place but the software itself crashes on startup (or is otherwise entirely dysfunctional) ever since.
- Panu -
* Panu Matilainen:
Attitudes like that is why there's rottenware in the distro that last actually worked sometime around 2011, dutifully rebuilt on each mass-rebuild and even spec cleanups taking place but the software itself crashes on startup (or is otherwise entirely dysfunctional) ever since.
I think that's only a problem if reported bugs don't get fixed. If such bugs are fixed, shipping everything that builds aligns well with building a community-tested distribution.
Exceptions could be software that leads to purchases of some kind, based on an incorrect assumption of Fedora support due to the existence of the non-working package.
Thanks, Florian
On 8/14/19 12:28 PM, Florian Weimer wrote:
- Panu Matilainen:
Attitudes like that is why there's rottenware in the distro that last actually worked sometime around 2011, dutifully rebuilt on each mass-rebuild and even spec cleanups taking place but the software itself crashes on startup (or is otherwise entirely dysfunctional) ever since.
I think that's only a problem if reported bugs don't get fixed. If such bugs are fixed, shipping everything that builds aligns well with building a community-tested distribution.
Part of the problem is the auto-close of bugs. When bugs get auto-closed for the umpteenth time without anybody attending them, people tend to give up, and the component ends up looking like there are no bugs at all. Which actually is quite a good indicator of a broken, dead package...
- Panu -
Aleksandar Kurtakov wrote:
The real question which every packager should ask himself is: Do I have the capacity (time, knowledge, hardware, etc.) to solve problems on non-supported architecture by upstream? And if the answer is no - it is probably better to drop the arch instead of shipping smth that not even the maintainer knows whether it is usable at all (like I used to ship eclipse on 32 bit arm although I'm quite sure it was not usable at all).
By that definition, all my packages would really be ExclusiveArch: x86_64. Is that really what you want?
Kevin Kofler
Florian Weimer wrote:
I think that's only a problem if reported bugs don't get fixed. If such bugs are fixed, shipping everything that builds aligns well with building a community-tested distribution.
Exceptions could be software that leads to purchases of some kind, based on an incorrect assumption of Fedora support due to the existence of the non-working package.
Well, that would exclude a lot of hardware drivers, and make Fedora pretty useless. (You cannot realistically test Fedora on all hardware on which users want to use it.)
In the end, if I need, e.g., a printer, I just have to buy some model, check the model lists upstream (in my example: Gutenprint, HPLIP, etc.) claims to support (for printers, openprinting.org can also be of help) and then hope it works. Short hardware compatibility lists with regularly tested models are not always helpful because the listed models are often no longer available and/or not in the desired price and/or feature range.
Kevin Kofler
* Kevin Kofler:
Florian Weimer wrote:
I think that's only a problem if reported bugs don't get fixed. If such bugs are fixed, shipping everything that builds aligns well with building a community-tested distribution.
Exceptions could be software that leads to purchases of some kind, based on an incorrect assumption of Fedora support due to the existence of the non-working package.
Well, that would exclude a lot of hardware drivers, and make Fedora pretty useless. (You cannot realistically test Fedora on all hardware on which users want to use it.)
You dropped too much context here. Drivers which are rottenware (Panu's term) are exactly in this category. We can only hope that upstreams remove them, based on feedback from the larger community.
Thanks, Florian
On Wed, Aug 14, 2019 at 3:31 PM Kevin Kofler kevin.kofler@chello.at wrote:
Aleksandar Kurtakov wrote:
The real question which every packager should ask himself is: Do I have the capacity (time, knowledge, hardware, etc.) to solve problems on non-supported architecture by upstream? And if the answer is no - it is probably better to drop the arch instead of shipping smth that not even the maintainer knows whether it is usable at all (like I used to ship eclipse on 32 bit arm although I'm quite sure it was not usable at all).
By that definition, all my packages would really be ExclusiveArch: x86_64. Is that really what you want?
There is big difference between what I want and what I can do :) . Setting clear expectations is crucial for any system to work properly and issues(e.g. understaffed) being noticed before it's late.
Kevin Kofler
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
Florian Weimer wrote:
You dropped too much context here. Drivers which are rottenware (Panu's term) are exactly in this category. We can only hope that upstreams remove them, based on feedback from the larger community.
The question is, how do you know whether the unmaintained driver last tested years ago still works (making potentially hundreds of silent users happy, and removing it will force them to spend money on replacing their hardware) or is actually completely broken? You have just no way to know.
Kevin Kofler
On Mon, Aug 5, 2019 at 9:55 AM Ben Cotton bcotton@redhat.com wrote:
On Mon, Aug 5, 2019 at 9:51 AM Kaleb Keithley kkeithle@redhat.com wrote:
There is a proposal[1] in upstream GlusterFS to drop 32-bit arches. ...
Kaleb, when this is determined upstream, can you please file this as a Fedora 32 (or whatever version) change proposal? Note that the Fedora 31 Change proposal deadline has already passed and that F31 branches from rawhide on 13 August.
Revisiting this topic 2+ years later. But with a new twist.
glusterfs-10 (glusterfs-10.0 RC0) has introduced changes that now result in build (link edit) errors on armv7hl[1].
I have not investigated whether this is fixable. I kinda suspect it isn't, but that remains to be seen.
Regardless, I am proposing to drop armv7hl from glusterfs-10 in Fedora-36/rawhide. (Yes, I know how much everyone wants to run glusterfs on their old 32-bit RaspPis.) If it turns out it is fixable then I will withdraw the proposal.
Where to I file a change proposal? Is that what's documented at [2]? It looks to me like it is well before any deadline according to [3].
Thanks
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=77518308 [2] https://docs.fedoraproject.org/en-US/program_management/pgm_guide/changes/ [3] https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html
On Tue, Oct 19, 2021 at 12:14 PM Kaleb Keithley kkeithle@redhat.com wrote:
Where to I file a change proposal? Is that what's documented at [2]? It looks to me like it is well before any deadline according to [3].
[2] https://docs.fedoraproject.org/en-US/program_management/pgm_guide/changes/
Not quite. That's for me (and future versions of me) to remember how to process them. What you're looking for is
https://docs.fedoraproject.org/en-US/program_management/changes_policy/ and https://docs.fedoraproject.org/en-US/program_management/changes_guide/
Please feel free to reach out to me directly if anything is unclear.
[3] https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html
Correct. Without seeing it, I'd guess this is probably a self-contained Change, which would be due 18 January. If the impact is broad enough to make it a System-Wide Change, that would be due 28 December (those dates are just for proposal submission, not completion)
Thanks, BC
-
Aleksandar Kurtakov -
Andreas Tunek -
Ben Cotton -
Daniel P. Berrangé -
Florian Weimer -
Frantisek Zatloukal -
Kaleb Keithley -
Kevin Kofler -
Miro Hrončok -
Panu Matilainen -
Peter Robinson