8:36 a.m.
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
8:38 a.m.
New subject: Fwd: Fedora 32 System-Wide Change: glusterfs dropping 32-bit arches
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)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.fedora...
8:54 a.m.
On Mon, Aug 5, 2019 at 9:51 AM Kaleb Keithley <kkeithle(a)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.
[1] https://github.com/gluster/glusterfs/issues/702
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.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
11:12 a.m.
On Mon, Aug 5, 2019 at 9:55 AM Ben Cotton <bcotton(a)redhat.com> wrote:
On Mon, Aug 5, 2019 at 9:51 AM Kaleb Keithley
<kkeithle(a)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
--
Kaleb
2:29 p.m.
On Tue, Oct 19, 2021 at 12:14 PM Kaleb Keithley <kkeithle(a)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.
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
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
10:28 a.m.
On Mon, Aug 5, 2019 at 3:44 PM Kaleb Keithley <kkeithle(a)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?
11:48 a.m.
On Mon, Aug 5, 2019 at 11:29 AM Peter Robinson <pbrobinson(a)gmail.com> wrote:
On Mon, Aug 5, 2019 at 3:44 PM Kaleb Keithley
<kkeithle(a)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.
[1] https://github.com/gluster/glusterfs/issues/702
5:16 p.m.
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.
[1] https://github.com/gluster/glusterfs/issues/702
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
2:59 p.m.
On Mon, Aug 5, 2019 at 6:17 PM Kevin Kofler <kevin.kofler(a)chello.at> wrote:
>
> Please feel free though to add your thoughts to the issue.
>
> [1] https://github.com/gluster/glusterfs/issues/702
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
1:55 a.m.
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?
3:28 a.m.
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?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3:36 a.m.
On Wed, Aug 14, 2019 at 11:29 AM Miro Hrončok <mhroncok(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
--
Alexander Kurtakov
Red Hat Eclipse Team
7:29 a.m.
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
7:53 a.m.
On Wed, Aug 14, 2019 at 3:31 PM Kevin Kofler <kevin.kofler(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
--
Alexander Kurtakov
Red Hat Eclipse Team
2:59 a.m.
On Tue, 13 Aug 2019, 23:33 Kevin Kofler, <kevin.kofler(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
4:09 a.m.
On 8/14/19 10:59 AM, Andreas Tunek wrote:
On Tue, 13 Aug 2019, 23:33 Kevin Kofler, <kevin.kofler(a)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 Kofler
If 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 -
4:28 a.m.
* 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
4:38 a.m.
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 -
7:39 a.m.
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
7:44 a.m.
* 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
8:09 a.m.
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
8:56 a.m.
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.
[1] https://github.com/gluster/glusterfs/issues/702
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
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
12:08 p.m.
On Mon, Aug 5, 2019 at 9:57 AM Miro Hrončok <mhroncok(a)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.
>
>
>
> [1] https://github.com/gluster/glusterfs/issues/702
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
4:45 p.m.
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?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
12:14 p.m.
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.
>
>
>
> [1] https://github.com/gluster/glusterfs/issues/702
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
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
920
days inactive
1726
days old
25 comments
11 participants
participants (11)
-
Aleksandar Kurtakov -
Andreas Tunek -
Ben Cotton -
Daniel P. Berrangé -
Florian Weimer -
Frantisek Zatloukal -
Kaleb Keithley -
Kevin Kofler -
Miro Hrončok -
Panu Matilainen -
Peter Robinson