Bug 2108875

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. ***