Description of problem: Please build hylafax+ for EPEL 8. Rebuilding hylafax+-7.0.0-2.fc31 package "as is" should be sufficient. Version-Release number of selected component (if applicable): hylafax+-7.0.0-2.fc31 Actual results: No hylafax+ in EPEL 8. Expected results: hylafax+-7.0.0-2.el8 - or better ;-) Additional info: Please let me know if you are not interested in maintaining the package on EPEL 8 branch.
I've got things ready to build. I think now just the missing dependencies is the problem: DEBUG util.py:593: No matching package to install: 'mgetty' DEBUG util.py:593: No matching package to install: 'uucp' DEBUG util.py:593: Not all dependencies satisfied DEBUG util.py:593: Error: Some packages could not be found. As soon as the dependencies are built then I can build hylafax+.
Lee, just for clarification: Are mgetty and uucp hard dependencies of hylafax+? Why exactly are these two packages needed?
(In reply to Robert Scheck from comment #2) > Lee, just for clarification: Are mgetty and uucp hard dependencies of > hylafax+? Why exactly are these two packages needed? HylaFAX's faxgetty and faxsend traditionally run as the uucp user. If uucp is not present then another user must be created (generally "fax") prior to installation. mgetty can be used in combination with faxgetty to do voice features - faxgetty could hand off the call to mgetty in the event that it was detected as a voice call. This feature is rarely used and could be disabled, if mgetty is not present. Traditionally both mgetty and uucp were present on RedHat/Fedora/CentOS systems, and so the SPEC is configured for that expectation. If these packages will not be present in EPEL8 then I will need to adjust the SPEC file to compensate.
Do I get it correct that the only reason for the uucp dependency is the uucp system user? I guess the solution mgetty provides is quite unique? Or is there a mgetty drop-in replacement?
(In reply to Robert Scheck from comment #4) > Do I get it correct that the only reason for the uucp dependency is the uucp > system user? Correct. I suspect that there was some reason for using uucp common among various gettys - i.e. mgetty and faxgetty would both use uucp, I think. > I guess the solution mgetty provides is quite unique? Or is there a mgetty > drop-in replacement? mgetty was/is part of "mgetty+sendfax" (a separate project entirely from HylaFAX), and last I heard Gert Doering was still maintaining it upstream. But, yes, the mgetty + faxgetty implementation was a rather unique one, and I'm sure a few people over the last 30 years used it, but not anyone I ever worked with directly. These days most people who want that voice + fax functionality are using a bigger hammer on the voice side of things, like Asterisk or FreeSWITCH.
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle. Changing version to 32.
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.