starred/s3fs-fuse
1
0
Fork 0
mirror of https://github.com/s3fs-fuse/s3fs-fuse.git synced 2026-04-25 13:26:00 +03:00
Code Issues 305 Projects Releases 5 Packages Wiki Activity

[GH-ISSUE #2496] 1.95 release #1219

New issue
Closed
opened 2026-03-04 01:52:19 +03:00 by kerem · 24 comments
kerem commented 2026-03-04 01:52:19 +03:00
Owner
Copy link

Originally created by @gaul on GitHub (Jul 12, 2024).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2496

Let's run one more release that is compatible with CentOS 7 since we will drop support for it in #2469. I would like to finish off work on the static lock checking since this seems to reveal a bunch of concurrency bugs but otherwise I don't think we have any other outstanding PRs.

Originally created by @gaul on GitHub (Jul 12, 2024). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2496 Let's run one more release that is compatible with CentOS 7 since we will drop support for it in #2469. I would like to finish off work on the static lock checking since this seems to reveal a bunch of concurrency bugs but otherwise I don't think we have any other outstanding PRs.
kerem closed this issue 2026-03-04 01:52:19 +03:00
kerem commented 2026-03-04 01:52:20 +03:00
Author
Owner
Copy link

@ggtakec commented on GitHub (Jul 12, 2024):

I agree to the 1.95 release.
Let's make this the last version for CentOS 7.

@juliogonzalez
Is it possible to release for CentOS 7?
My test code that I created for CentOS 7 is no longer buildable on Github Actions, so I can't test it with CI.

<!-- gh-comment-id:2225502976 --> @ggtakec commented on GitHub (Jul 12, 2024): I agree to the 1.95 release. Let's make this the last version for CentOS 7. @juliogonzalez Is it possible to release for CentOS 7? _[My test code](https://github.com/ggtakec/s3fs-fuse/tree/centos7) that I created for CentOS 7 is no longer buildable on Github Actions, so I can't test it with CI._
kerem commented 2026-03-04 01:52:20 +03:00
Author
Owner
Copy link

@juliogonzalez commented on GitHub (Jul 12, 2024):

I agree to the 1.95 release. Let's make this the last version for CentOS 7.

@juliogonzalez Is it possible to release for CentOS 7? My test code that I created for CentOS 7 is no longer buildable on Github Actions, so I can't test it with CI.

Possible: Yes

Desiderable: Not so much without tests, IMHO.

I wil try to have a look in the next days to see if I can find why this is failing, as it should not. My suspect is something around uses: actions/checkout@v3, but not sure right now of what's going on. Maybe it won't be hard to figure it out.

<!-- gh-comment-id:2225605081 --> @juliogonzalez commented on GitHub (Jul 12, 2024): > I agree to the 1.95 release. Let's make this the last version for CentOS 7. > > @juliogonzalez Is it possible to release for CentOS 7? _[My test code](https://github.com/ggtakec/s3fs-fuse/tree/centos7) that I created for CentOS 7 is no longer buildable on Github Actions, so I can't test it with CI._ Possible: Yes Desiderable: Not so much without tests, IMHO. I wil try to have a look in the next days to see if I can find why this is failing, as it should not. My suspect is something around `uses: actions/checkout@v3`, but not sure right now of what's going on. Maybe it won't be hard to figure it out.
kerem commented 2026-03-04 01:52:20 +03:00
Author
Owner
Copy link

@ggtakec commented on GitHub (Jul 12, 2024):

@juliogonzalez
Sorry for my poor explanation.

The reason it's failing is because Github Actions' actions/checkout@v3 can't checkout the source code, and this is a problem specific to GHA.
(It worked right after EOL, but started failing after that)
There should be no problem building the source code.

<!-- gh-comment-id:2225634592 --> @ggtakec commented on GitHub (Jul 12, 2024): @juliogonzalez Sorry for my poor explanation. The reason it's failing is because Github Actions' actions/checkout@v3 can't checkout the source code, and this is a problem specific to GHA. (It worked right after EOL, but started failing after that) There should be no problem building the source code.
kerem commented 2026-03-04 01:52:20 +03:00
Author
Owner
Copy link

@juliogonzalez commented on GitHub (Jul 12, 2024):

@juliogonzalez Sorry for my poor explanation.

The reason it's failing is because Github Actions' actions/checkout@v3 can't checkout the source code, and this is a problem specific to GHA. (It worked right after EOL, but started failing after that) There should be no problem building the source code.

I see.

But if you create 1.95 from master (and not from the point where you branched to try fix the tests for CentOS7), that would mean releasing with commits that were not really tested for CentOS7. And in this case it would be better to avoid the release.

Let me play a little bit with your branch to see if I can get a fix, before we take a decision. I will come back to you in a few days, probably during the weekend, or shortly after.

<!-- gh-comment-id:2225641336 --> @juliogonzalez commented on GitHub (Jul 12, 2024): > @juliogonzalez Sorry for my poor explanation. > > The reason it's failing is because Github Actions' actions/checkout@v3 can't checkout the source code, and this is a problem specific to GHA. (It worked right after EOL, but started failing after that) There should be no problem building the source code. I see. But if you create 1.95 from master (and not from the point where you branched to try fix the tests for CentOS7), that would mean releasing with commits that were not really tested for CentOS7. And in this case it would be better to avoid the release. Let me play a little bit with your branch to see if I can get a fix, before we take a decision. I will come back to you in a few days, probably during the weekend, or shortly after.
kerem commented 2026-03-04 01:52:20 +03:00
Author
Owner
Copy link

@ggtakec commented on GitHub (Jul 12, 2024):

I posted PR #2497 to restore CentOS 7 to CI(Github Actions).

@juliogonzalez
The reason why actions/checkout execution was failing was because it was changed to use nodejs 20(CentOS 7 needs nodejs 16).
To avoid this, the ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION(=true) environment variable is set.
Reference: https://github.com/actions/checkout/issues/1809

@gaul
Could you review this PR #2497 ?
The code added in this PR (only CI-related) can be deleted after the release.
I would like to merge this PR and prepare it for release 1.95.

<!-- gh-comment-id:2225848930 --> @ggtakec commented on GitHub (Jul 12, 2024): I posted PR #2497 to restore CentOS 7 to CI(Github Actions). @juliogonzalez The reason why `actions/checkout` execution was failing was because it was changed to use `nodejs 20`(CentOS 7 needs `nodejs 16`). To avoid this, the `ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION(=true)` environment variable is set. _Reference: https://github.com/actions/checkout/issues/1809_ @gaul Could you review this PR #2497 ? The code added in this PR (only CI-related) can be deleted after the release. I would like to merge this PR and prepare it for release 1.95.
kerem commented 2026-03-04 01:52:20 +03:00
Author
Owner
Copy link

@gaul commented on GitHub (Oct 16, 2024):

We have a few outstanding locking fixes and the shared_ptr PR but does anything else block 1.95?

<!-- gh-comment-id:2417953325 --> @gaul commented on GitHub (Oct 16, 2024): We have a few outstanding locking fixes and the shared_ptr PR but does anything else block 1.95?
kerem commented 2026-03-04 01:52:20 +03:00
Author
Owner
Copy link

@juliogonzalez commented on GitHub (Oct 16, 2024):

Is the plan about this being the last CentOS7 release still valid?

If that's the case, I am not sure EPEL7 is going to accept it. But in any case I will make sure the package still builds for CentOS7 and clones so anyone can easily build 1.95.

<!-- gh-comment-id:2418033806 --> @juliogonzalez commented on GitHub (Oct 16, 2024): Is the plan about this being the last CentOS7 release still valid? If that's the case, I am not sure EPEL7 is going to accept it. But in any case I will make sure the package still builds for CentOS7 and clones so anyone can easily build 1.95.
kerem commented 2026-03-04 01:52:20 +03:00
Author
Owner
Copy link

@gaul commented on GitHub (Oct 16, 2024):

We haven't merged anything that will break CentOS 7 so 1.95 should be compatible. But I would like to explore FUSE3 and C++17 for 1.96 which will break CentOS 7.

<!-- gh-comment-id:2418056160 --> @gaul commented on GitHub (Oct 16, 2024): We haven't merged anything that will break CentOS 7 so 1.95 should be compatible. But I would like to explore FUSE3 and C++17 for 1.96 which will break CentOS 7.
kerem commented 2026-03-04 01:52:20 +03:00
Author
Owner
Copy link

@gaul commented on GitHub (Oct 25, 2024):

Does anything block the release? I suggest these release notes:

  • Add ipresolve option to select IPv4- or IPv6-only
  • Changed s3fs logo
  • Enable static lock checking and fix locking errors
  • Fix deadLock in FdManager::ChangeEntityToTempPath
  • Fix FreeBSD support
  • Fix use-after-free in FdManager::ChangeEntityToTempPath
  • Fix Windows compilation
  • Improve memory ownership and fix leaks
  • Retry request on HTTP 429 error
<!-- gh-comment-id:2436558808 --> @gaul commented on GitHub (Oct 25, 2024): Does anything block the release? I suggest these release notes: * Add `ipresolve` option to select IPv4- or IPv6-only * Changed s3fs logo * Enable static lock checking and fix locking errors * Fix deadLock in FdManager::ChangeEntityToTempPath * Fix FreeBSD support * Fix use-after-free in FdManager::ChangeEntityToTempPath * Fix Windows compilation * Improve memory ownership and fix leaks * Retry request on HTTP 429 error
kerem commented 2026-03-04 01:52:20 +03:00
Author
Owner
Copy link

@ggtakec commented on GitHub (Oct 25, 2024):

I would like to fix the part I commented on in https://github.com/s3fs-fuse/s3fs-fuse/pull/2569#discussion_r1815840691 .
If I need to make the fix quickly and separate it from #2569, I will immediately submit a PR to fix just that part.

<!-- gh-comment-id:2436575686 --> @ggtakec commented on GitHub (Oct 25, 2024): I would like to fix the part I commented on in https://github.com/s3fs-fuse/s3fs-fuse/pull/2569#discussion_r1815840691 . If I need to make the fix quickly and separate it from #2569, I will immediately submit a PR to fix just that part.
kerem commented 2026-03-04 01:52:20 +03:00
Author
Owner
Copy link

@ggtakec commented on GitHub (Oct 26, 2024):

Congratulations on the v1.95 release

<!-- gh-comment-id:2439092282 --> @ggtakec commented on GitHub (Oct 26, 2024): Congratulations on the v1.95 release
kerem commented 2026-03-04 01:52:21 +03:00
Author
Owner
Copy link

@juliogonzalez commented on GitHub (Oct 27, 2024):

Tracking for RPM submissions

Git main repository

openSUSE

As usual, one accepted this will be submitted to openSUSE Tumbleweed and derivates (such as openSUSE MicroOS), and to new openSUSE Leap and SUSE Linux Enterprise versions.

Existing openSUSE Leap and SUSE Linux Enterprise version will not get unless someone makes a formal request.

Fedora/EPEL

<!-- gh-comment-id:2440117118 --> @juliogonzalez commented on GitHub (Oct 27, 2024): # Tracking for RPM submissions ## Git main repository - **PR:** https://github.com/juliogonzalez/s3fs-fuse-rpm/pull/32 (merged) - **Release:** https://github.com/juliogonzalez/s3fs-fuse-rpm/releases/tag/1.95-1 ## openSUSE - **SR**: https://build.opensuse.org/requests/1218679 As usual, one accepted this will be submitted to openSUSE Tumbleweed and derivates (such as openSUSE MicroOS), and to new openSUSE Leap and SUSE Linux Enterprise versions. Existing openSUSE Leap and SUSE Linux Enterprise version will not get unless someone makes a formal request. ## Fedora/EPEL - **EPEL7:** Not possible, as I can't push to pagure anymore: ``` remote: Branch refs/heads/epel7 is unsupported. Cannot push to a disabled branch (maybe eol?). remote: Denied push for ref 'refs/heads/epel7' for user 'juliogonzalez' remote: All changes have been rejected To ssh://pkgs.fedoraproject.org/rpms/s3fs-fuse ! [remote rejected] epel7 -> epel7 (pre-receive hook declined) error: failed to push some refs to 'ssh://pkgs.fedoraproject.org/rpms/s3fs-fuse' ``` Still, anyone can still build the package using https://github.com/juliogonzalez/s3fs-fuse-rpm/ using an existing CentOS7 system (or any clone) Or, as an alternative, anyone can download it from my CI: https://jenkins.juliogonzalez.es/job/s3fs-fuse-rpm-build/DISTRO=centos7,label=docker/56/ - **EPEL8:** https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-b619a3d6a0 - **EPEL9:** https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-5821d3258a - **Fedora39:** https://bodhi.fedoraproject.org/updates/FEDORA-2024-e6c8cdab6b - **Fedora40:** https://bodhi.fedoraproject.org/updates/FEDORA-2024-ecc8cbb47f - **Fedora41:** https://bodhi.fedoraproject.org/updates/FEDORA-2024-23df4e7758 - **Fedora Rawhide:** https://bodhi.fedoraproject.org/updates/FEDORA-2024-8744c124ff
kerem commented 2026-03-04 01:52:21 +03:00
Author
Owner
Copy link

@gaul commented on GitHub (Oct 27, 2024):

Thanks as always @juliogonzalez! I will try the Fedora 41 package when it reaches testing.

<!-- gh-comment-id:2440118213 --> @gaul commented on GitHub (Oct 27, 2024): Thanks as always @juliogonzalez! I will try the Fedora 41 package when it reaches testing.
kerem commented 2026-03-04 01:52:21 +03:00
Author
Owner
Copy link

@juliogonzalez commented on GitHub (Oct 27, 2024):

Thanks as always @juliogonzalez! I will try the Fedora 41 package when it reaches testing.

Done, see above.

Regarding CentOS7 and clones: The submission for EPEL7 could not be prepared (details above), but still anyone can freely and easily build for CentOS7 and clones using my repository.

<!-- gh-comment-id:2440132571 --> @juliogonzalez commented on GitHub (Oct 27, 2024): > Thanks as always @juliogonzalez! I will try the Fedora 41 package when it reaches testing. Done, see above. Regarding CentOS7 and clones: The submission for EPEL7 could not be prepared (details above), but still anyone can freely and easily build for CentOS7 and clones using my repository.
kerem commented 2026-03-04 01:52:21 +03:00
Author
Owner
Copy link

@juliogonzalez commented on GitHub (Nov 6, 2024):

1.95 now available at:

I still could not push 1.95 (and neither 1.94) to https://build.opensuse.org/project/show/home:juliogonzalez:s3fs-fuse (for Debian/Ubuntu, as non-official package) as https://packages.debian.org/search?keywords=s3fs is still at 1.93 for Debian sid.

<!-- gh-comment-id:2460317874 --> @juliogonzalez commented on GitHub (Nov 6, 2024): 1.95 now available at: - https://build.opensuse.org/package/show/filesystems/s3fs as experimental for all supported SUSE/openSUSE OS - openSUSE Tumbleweed - EPEL8 - EPEL9 - Fedora 39 - Fedora 40 - Fedora 41 - Fedora RawHide I still could not push 1.95 (and neither 1.94) to https://build.opensuse.org/project/show/home:juliogonzalez:s3fs-fuse (for Debian/Ubuntu, as non-official package) as https://packages.debian.org/search?keywords=s3fs is still at 1.93 for Debian sid.
kerem commented 2026-03-04 01:52:21 +03:00
Author
Owner
Copy link

@juliogonzalez commented on GitHub (Nov 6, 2024):

@gaul I see you contributed to the Debian package https://salsa.debian.org/debian/s3fs-fuse/-/commits/debian/?ref_type=HEADS, so apparently one doesn't need to be maintainer to send MRs to that repo. I will see what I can do this weekend (sadly I don't have enough time to become a Debian maintainer for s3fs as well, but maybe I can easy things for Mattia Rizzolo)

<!-- gh-comment-id:2460330000 --> @juliogonzalez commented on GitHub (Nov 6, 2024): @gaul I see you contributed to the Debian package https://salsa.debian.org/debian/s3fs-fuse/-/commits/debian/?ref_type=HEADS, so apparently one doesn't need to be maintainer to send MRs to that repo. I will see what I can do this weekend (sadly I don't have enough time to become a Debian maintainer for s3fs as well, but maybe I can easy things for Mattia Rizzolo)
kerem commented 2026-03-04 01:52:21 +03:00
Author
Owner
Copy link

@gaul commented on GitHub (Nov 6, 2024):

I don't exactly understand how Debian manages releases but this seems to have the entire git history which is why Takeshi and my names show up. I file issues with them sometimes to upgrade to reduce stale bugs filed but haven't done so recently.

<!-- gh-comment-id:2460354913 --> @gaul commented on GitHub (Nov 6, 2024): I don't exactly understand how Debian manages releases but this seems to have the entire git history which is why Takeshi and my names show up. I file issues with them sometimes to upgrade to reduce stale bugs filed but haven't done so recently.
kerem commented 2026-03-04 01:52:21 +03:00
Author
Owner
Copy link

@juliogonzalez commented on GitHub (Nov 6, 2024):

I don't exactly understand how Debian manages releases but this seems to have the entire git history which is why Takeshi and my names show up. I file issues with them sometimes to upgrade to reduce stale bugs filed but haven't done so recently.

You're right. Seems Debian gets the whole git history. I guess they're rebasing changes from https://github.com/s3fs-fuse/s3fs-fuse then adding what Debian needs on top.

As of this moment seems they don't have any bug report, maybe you can send them the request to upgrade to 1.95 on Debian sid?

That way it will at least go to the next Debian and Ubuntu versions, and as soon as they have it in Debian sid, I can provide the (unofficial) packages via https://build.opensuse.org/project/show/home:juliogonzalez:s3fs-fuse

<!-- gh-comment-id:2460381692 --> @juliogonzalez commented on GitHub (Nov 6, 2024): > I don't exactly understand how Debian manages releases but this seems to have the entire git history which is why Takeshi and my names show up. I file issues with them sometimes to upgrade to reduce stale bugs filed but haven't done so recently. You're right. Seems Debian gets the whole git history. I guess they're rebasing changes from https://github.com/s3fs-fuse/s3fs-fuse then adding what Debian needs on top. As of this moment seems they don't have any bug report, maybe you can send them the request to upgrade to 1.95 on Debian sid? That way it will at least go to the next Debian and Ubuntu versions, and as soon as they have it in Debian sid, I can provide the (unofficial) packages via https://build.opensuse.org/project/show/home:juliogonzalez:s3fs-fuse
kerem commented 2026-03-04 01:52:21 +03:00
Author
Owner
Copy link

@gaul commented on GitHub (Nov 6, 2024):

I opened this issue to upgrade Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1086865

<!-- gh-comment-id:2460474706 --> @gaul commented on GitHub (Nov 6, 2024): I opened this issue to upgrade Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1086865
kerem commented 2026-03-04 01:52:21 +03:00
Author
Owner
Copy link

@juliogonzalez commented on GitHub (Apr 15, 2025):

I bring some news to this issue about CentOS7 and family.

As explained at https://github.com/s3fs-fuse/s3fs-fuse/issues/2496#issuecomment-2440117118, I could not provide packages for EPEL7 back then, as it was already End of Life.

However, since I got contacted by someone to see if I could provide EPEL7 packages (which is, again, not possible), I decided to build it at the same place where I was already building unofficial packages for Debian and Ubuntu:

https://build.opensuse.org/project/show/home:juliogonzalez:s3fs-fuse
And downloads available at:
https://download.opensuse.org/repositories/home:/juliogonzalez:/s3fs-fuse/EL7/

Thing to keep in mind

  • 1.95 is the lat version that will support CentOS7 and family
  • Build for architectures other than x86_64, ppc64le and aarch64 was failing. So only those architectures are available.
  • The build uses the latest available CentOS7 and EPEL7 packages and not anything provided by the Extended Life Cycle Support from Red Hat, so the build is using dependencies that could contain vulnerabilities. So if you have access to the Extended Life Cycle Support from Red Hat, build should happen using https://github.com/juliogonzalez/s3fs-fuse-rpm/tree/1.95-1
  • As usual, that unofficial build is not endorsed by Fedora, EPEL, Red Hat or any other organization, and users are using it at their own risk. People can contact me, but keep in mind I am providing those builds in best-effort mode and with no warranty!
<!-- gh-comment-id:2807286762 --> @juliogonzalez commented on GitHub (Apr 15, 2025): I bring some news to this issue about CentOS7 and family. As explained at https://github.com/s3fs-fuse/s3fs-fuse/issues/2496#issuecomment-2440117118, I could not provide packages for EPEL7 back then, as it was already End of Life. However, since I got contacted by someone to see if I could provide EPEL7 packages (which is, again, not possible), I decided to build it at the same place where I was already building unofficial packages for Debian and Ubuntu: https://build.opensuse.org/project/show/home:juliogonzalez:s3fs-fuse And downloads available at: https://download.opensuse.org/repositories/home:/juliogonzalez:/s3fs-fuse/EL7/ Thing to keep in mind - 1.95 is the lat version that will support CentOS7 and family - Build for architectures other than `x86_64`, `ppc64le` and `aarch64` was failing. So only those architectures are available. - The build uses the latest available CentOS7 and EPEL7 packages and not anything provided by the Extended Life Cycle Support from Red Hat, so the build is using dependencies that could contain vulnerabilities. So if you have access to the Extended Life Cycle Support from Red Hat, build should happen using https://github.com/juliogonzalez/s3fs-fuse-rpm/tree/1.95-1 - As usual, that unofficial build is not endorsed by Fedora, EPEL, Red Hat or any other organization, and users are using it at their own risk. People can contact me, but keep in mind I am providing those builds in best-effort mode and with no warranty!
kerem commented 2026-03-04 01:52:21 +03:00
Author
Owner
Copy link

@gaul commented on GitHub (Apr 15, 2025):

Build for architectures other than x86_64, ppc64le and aarch64 was failing. So only those architectures are available.

What kind of build failures? Occasionally 32-bit compatibility issues creep in but those are easy to fix. Raspberry Pi/armv7 is the only real reason to fix these.

<!-- gh-comment-id:2807393182 --> @gaul commented on GitHub (Apr 15, 2025): > Build for architectures other than `x86_64`, `ppc64le` and `aarch64` was failing. So only those architectures are available. What kind of build failures? Occasionally 32-bit compatibility issues creep in but those are easy to fix. Raspberry Pi/armv7 is the only real reason to fix these.
kerem commented 2026-03-04 01:52:21 +03:00
Author
Owner
Copy link

@juliogonzalez commented on GitHub (Apr 15, 2025):

What kind of build failures? Occasionally 32-bit compatibility issues creep in but those are easy to fix. Raspberry Pi/armv7 is
the only real reason to fix these.

Strictly speaking I just noticed inspecting https://build.opensuse.org/projects/Fedora:EPEL:7/meta that is not there arm7vl

For arm7vl, I was getting:

nothing provides automake, nothing provides gcc-c++, nothing provides make, nothing provides pkgconfig, nothing provides pkgconfig(fuse) >= 2.8.4, nothing provides pkgconfig(libcurl), nothing provides pkgconfig(libxml-2.0), nothing provides pkgconfig(openssl), nothing provides autoconf, nothing provides binutils, nothing provides bzip2, nothing provides gcc, nothing provides gdbm, nothing provides gettext, nothing provides glibc, nothing provides perl, nothing provides perl-constant, nothing provides perl-Carp, nothing provides perl-Data-Dumper, nothing provides perl-Exporter, nothing provides perl-Getopt-Long, nothing provides perl-Digest-MD5, nothing provides libtool, nothing provides ncurses, nothing provides zlib, nothing provides rpm-build, nothing provides centos-release, nothing provides redhat-rpm-config

For s390x the same:

nothing provides automake, nothing provides gcc-c++, nothing provides make, nothing provides pkgconfig, nothing provides pkgconfig(fuse) >= 2.8.4, nothing provides pkgconfig(libcurl), nothing provides pkgconfig(libxml-2.0), nothing provides pkgconfig(openssl), nothing provides autoconf, nothing provides binutils, nothing provides bzip2, nothing provides gcc, nothing provides gdbm, nothing provides gettext, nothing provides glibc, nothing provides perl, nothing provides perl-constant, nothing provides perl-Carp, nothing provides perl-Data-Dumper, nothing provides perl-Exporter, nothing provides perl-Getopt-Long, nothing provides perl-Digest-MD5, nothing provides libtool, nothing provides ncurses, nothing provides zlib, nothing provides rpm-build, nothing provides centos-release, nothing provides redhat-rpm-config

But this is normal, as those architectures were not imported to the Open Build Service.

Seems s390x was never supported on CentOS7. And as for ARM 32 bits (àrm7vl`) I see https://blog.centos.org/2016/01/alternative-architectures-abound-in-centos-7-1511/, so technically speaking it could be added to the Open Build Service. But TBH I don't fill like disturbing the Open Build Service for an EoL OS :-)

Of course if someone wants to use an old raspberry in 32 bits mode with CentOS7 (new raspberries support 64 bits), they can still build the RPM manually from https://github.com/juliogonzalez/s3fs-fuse-rpm/tree/1.95-1, so I think this solution is acceptable.

<!-- gh-comment-id:2807432281 --> @juliogonzalez commented on GitHub (Apr 15, 2025): > What kind of build failures? Occasionally 32-bit compatibility issues creep in but those are easy to fix. Raspberry Pi/armv7 is the only real reason to fix these. Strictly speaking I just noticed inspecting https://build.opensuse.org/projects/Fedora:EPEL:7/meta that is not there `arm7vl` For `arm7vl`, I was getting: ``` nothing provides automake, nothing provides gcc-c++, nothing provides make, nothing provides pkgconfig, nothing provides pkgconfig(fuse) >= 2.8.4, nothing provides pkgconfig(libcurl), nothing provides pkgconfig(libxml-2.0), nothing provides pkgconfig(openssl), nothing provides autoconf, nothing provides binutils, nothing provides bzip2, nothing provides gcc, nothing provides gdbm, nothing provides gettext, nothing provides glibc, nothing provides perl, nothing provides perl-constant, nothing provides perl-Carp, nothing provides perl-Data-Dumper, nothing provides perl-Exporter, nothing provides perl-Getopt-Long, nothing provides perl-Digest-MD5, nothing provides libtool, nothing provides ncurses, nothing provides zlib, nothing provides rpm-build, nothing provides centos-release, nothing provides redhat-rpm-config ``` For `s390x` the same: ``` nothing provides automake, nothing provides gcc-c++, nothing provides make, nothing provides pkgconfig, nothing provides pkgconfig(fuse) >= 2.8.4, nothing provides pkgconfig(libcurl), nothing provides pkgconfig(libxml-2.0), nothing provides pkgconfig(openssl), nothing provides autoconf, nothing provides binutils, nothing provides bzip2, nothing provides gcc, nothing provides gdbm, nothing provides gettext, nothing provides glibc, nothing provides perl, nothing provides perl-constant, nothing provides perl-Carp, nothing provides perl-Data-Dumper, nothing provides perl-Exporter, nothing provides perl-Getopt-Long, nothing provides perl-Digest-MD5, nothing provides libtool, nothing provides ncurses, nothing provides zlib, nothing provides rpm-build, nothing provides centos-release, nothing provides redhat-rpm-config ``` But this is normal, as those architectures were not imported to the Open Build Service. Seems `s390x` was never supported on CentOS7. And as for ARM 32 bits (àrm7vl`) I see https://blog.centos.org/2016/01/alternative-architectures-abound-in-centos-7-1511/, so technically speaking it could be added to the Open Build Service. But TBH I don't fill like disturbing the Open Build Service for an EoL OS :-) Of course if someone wants to use an old raspberry in 32 bits mode with CentOS7 (new raspberries support 64 bits), they can still build the RPM manually from https://github.com/juliogonzalez/s3fs-fuse-rpm/tree/1.95-1, so I think this solution is acceptable.
kerem commented 2026-03-04 01:52:21 +03:00
Author
Owner
Copy link

@gaul commented on GitHub (Apr 15, 2025):

OK it's not a s3fs source issue then. I don't have the entire Raspberry Pi situation in my head but even my RPi4 running bookworm defaults to a 64-bit kernel but 32-bit userland due to perceived memory savings.

<!-- gh-comment-id:2807496399 --> @gaul commented on GitHub (Apr 15, 2025): OK it's not a s3fs source issue then. I don't have the entire Raspberry Pi situation in my head but even my RPi4 running bookworm defaults to a 64-bit kernel but 32-bit userland due to perceived memory savings.
kerem commented 2026-03-04 01:52:21 +03:00
Author
Owner
Copy link

@juliogonzalez commented on GitHub (Apr 15, 2025):

OK it's not a s3fs source issue then. I don't have the entire Raspberry Pi situation in my head but even my RPi4 running bookworm defaults to a 64-bit kernel but 32-bit userland due to perceived memory savings.

Right, not a s3fs issue. If someone wants to build locally using the SPEC, they can still do it and should work hopefully just fine (I'd try, but all my Raspberries are running Rasperry Pi OS 32 bits for now :-))

<!-- gh-comment-id:2807588884 --> @juliogonzalez commented on GitHub (Apr 15, 2025): > OK it's not a s3fs source issue then. I don't have the entire Raspberry Pi situation in my head but even my RPi4 running bookworm defaults to a 64-bit kernel but 32-bit userland due to perceived memory savings. Right, not a s3fs issue. If someone wants to build locally using the SPEC, they can still do it and should work hopefully just fine (I'd try, but all my Raspberries are running Rasperry Pi OS 32 bits for now :-))
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
v1.97
v1.96
v1.95
v1.94
v1.93
v1.92
v1.91
v1.90
v1.89
v1.88
v1.87
v1.86
v1.85
v1.84
v1.83
v1.82
v1.81
v1.80
v1.79
v1.78
Pre-v1.78
v1.77
v1.76
v1.75
v1.74
Labels
Clear labels   
bug

   
bug

   
dataloss

   
duplicate

   
enhancement

   
feature request

   
help wanted

   
invalid

   
need info

   
performance

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
question

   
testing
No labels
bug
bug
dataloss
duplicate
enhancement
feature request
help wanted
invalid
need info
performance
pull-request
question
question
testing
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/s3fs-fuse#1219
No description provided.