Please branch and build duf in epel9. If you do not wish to maintain duf in epel9, or do not think you will be able to do this in a timely manner, I would be happy to be a co-maintainer of the package (FAS jonathanspw); please add me through https://src.fedoraproject.org/rpms/duf/adduser
Mikel, what is the nature of the dependency tree here? Unless we're using bundled dependencies, I doubt branching this for EPEL will be an easy effort.
Looking at the last f36 koji build, it doesn't seem that bad: DEBUG util.py:445: ============================================================================================== DEBUG util.py:445: Package Arch Version Repo Size DEBUG util.py:445: ============================================================================================== DEBUG util.py:445: Installing: DEBUG util.py:445: golang-github-iglou-eu-wildcard-devel noarch 1.0.3-1.fc36 build 16 k DEBUG util.py:445: golang-github-jedib0t-pretty-devel noarch 6.2.7-1.fc36 build 96 k DEBUG util.py:445: golang-github-mattn-runewidth-devel noarch 0.0.13-1.fc36 build 23 k DEBUG util.py:445: golang-github-muesli-termenv-devel noarch 0.12.0-1.fc36 build 408 k DEBUG util.py:445: golang-x-sys-devel noarch 0-23.20220604gitbc2c85a.fc36 build 429 k DEBUG util.py:445: golang-x-term-devel noarch 0-0.7.20220129git03fcf44.fc36 build 25 k DEBUG util.py:445: Installing dependencies: DEBUG util.py:445: golang-github-lucasb-eyer-colorful-devel noarch 1.2.0-3.fc36 build 427 k DEBUG util.py:445: golang-github-mattn-isatty-devel noarch 0.0.14-1.fc36 build 14 k DEBUG util.py:445: golang-github-pkg-profile-devel noarch 1.5.0-4.fc36 build 15 k DEBUG util.py:445: golang-github-rivo-uniseg-devel noarch 0.2.0-4.fc36 build 44 k DEBUG util.py:445: ============================================================================================== DEBUG util.py:445: Install 10 Packages
Even so, as I said in the last Go SIG meeting, I'm a bit hesitant about continuing to add more applications and more branches when we already have such a high number of FTBFS packages in Fedora. However, this is an open source project, and I don't get to dictate how and where folks direct their time. I'm just raising my concerns.
@Jonathan I added you as a collab for epel, not sure if I did it correctly, let me know if I need to add something else. As @gotmax++ reports you'll need to make sure the rest of deps are ready for EPEL before pushing duf. I don't plan to work on golang packages for EPEL at the moment, I rather focus fixing FTBFS, keeping my plate empty or working in other software I want to add to Fedora.
> I'm a bit hesitant about continuing to add more applications and more branches when we already have such a high number of FTBFS packages in Fedora To be clear, I'm talking about the go ecosystem in Fedora. I generally support branching packages for EPEL. I am part of the EPEL SIG and maintain packages in EPEL. I just don't want to add a bunch of go packages to EPEL if they're going to be unmaintainable. > @Jonathan I added you as a collab for epel, not sure if I did it correctly, let me know if I need to add something else. It appears you've done it correctly :). Jonathan, I am happy to help out if you have any questions. Feel free to join us in #fedora-golang (Libera.chat) / #golang:fedoraproject.org (Matrix).
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle. Changing version to 37.
*** Bug 2227412 has been marked as a duplicate of this bug. ***