ekiga failed to build from source in Fedora rawhide/f30 https://koji.fedoraproject.org/koji/taskinfo?taskID=32379920 For details on the mass rebuild see: https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild Please fix ekiga at your earliest convenience and set the bug's status to ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks, ekiga will be orphaned. Before branching of Fedora 31, ekiga will be retired, if it still fails to build. For more details on the FTBFS policy, please visit: https://fedoraproject.org/wiki/Fails_to_build_from_source
Created attachment 1529810 [details] build.log file build.log too big, will only attach last 1024 bytes
Created attachment 1529811 [details] root.log file root.log too big, will only attach last 1024 bytes
Created attachment 1529812 [details] state.log
checking for boostlib >= 1.34... yes checking whether the Boost::Signals library is available... no BUILDSTDERR: configure: error: You need the boost signals library to compile Ekiga Boost.Signals library has been removed from the version of Boost in rawhide. The code should be ported to use Boost.Signals2 (or if the check is unnecessary, just stop checking for Boost.Signals).
I only briefly looked on this and the check is unfortunately valid. There is no release of the upstream code with the Boost.Signals2 usage, but it exists. The problem I faced with my (semi-)quick tests was with not new enough version of ptlib in rawhide. The upstream checkout of the master branch at commit 8c954b8a requires ptlib 2.16.3 and opal 3.16.3. I do not know whether it's possible to update those together with ekiga in Fedora.
They tend to be quite closely tied. I'm considering just retiring ekiga/opal/ptlib because while upstream isn't officially dead it's pretty damn close
(In reply to Peter Robinson from comment #6) > They tend to be quite closely tied. Ah, I see. I noticed the version check to be 'equal', instead of 'equal or greater than', in the .spec file. > I'm considering just retiring ekiga/opal/ptlib because while upstream > isn't officially dead it's pretty damn close I agree with mostly inactive upstream "these days", but I think it would not be fair to retire it for Fedora 30 at this moment, because anyone interested to take ownership won't have much time to fix it for Fedora 30. What about getting the master snapshot and update all three packages (does anything else use opal/ptlib in Fedora? I'd guess no) and retire it for Fedora 31? I do not have any personal preference here, I do not use ekiga, I'm just thinking of "being fair". Anyway, it's only my opinion. The decision is up to you.
> > I'm considering just retiring ekiga/opal/ptlib because while upstream > > isn't officially dead it's pretty damn close > > I agree with mostly inactive upstream "these days", but I think it would not > be fair to retire it for Fedora 30 at this moment, because anyone interested > to take ownership won't have much time to fix it for Fedora 30. What about Well F-30 hasn't branched as yet so I don't agree. I could ask if anyone is interested in taking it over. > getting the master snapshot and update all three packages (does anything > else use opal/ptlib in Fedora? I'd guess no) and retire it for Fedora 31? I > do not have any personal preference here, I do not use ekiga, I'm just > thinking of "being fair". Anyway, it's only my opinion. The decision is up > to you. I don't have time to rebase to git trees, nor the time to test that something like that even worked, nor do I have the interest and I have no idea what the state of git master is. I think we'd be better off just retiring it.
No problem. I'd like to help, but I also do not use ekiga, thus I've no idea how to test it properly.
Has this been retired yet? It is currently preventing upgrades to F30: Problem 4: problem with installed package ekiga-4.0.1-42.fc29.x86_64 - package ekiga-4.0.1-42.fc29.x86_64 requires libedataserver-1.2.so.23()(64bit), but none of the providers can be installed - evolution-data-server-3.30.5-2.fc29.x86_64 does not belong to a distupgrade repository Maybe mail the ML asking if anyone wants to take it up and fix it?
Dear Maintainer, your package has not been built successfully in f30. Action is required from you. If you can fix your package to build, perform a build in koji, and either create an update in bodhi, or close this bug without creating an update, if updating is not appropriate [1]. If you are working on a fix, set the status to ASSIGNED to acknowledge this. Following the latest policy for such packages [2], your package can be orphaned if this bug remains in NEW state more than 8 weeks. [1] https://fedoraproject.org/wiki/Updates_Policy [2] https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
(In reply to Ankur Sinha (FranciscoD) from comment #10) > Has this been retired yet? It is currently preventing upgrades to F30: > > Problem 4: problem with installed package ekiga-4.0.1-42.fc29.x86_64 > - package ekiga-4.0.1-42.fc29.x86_64 requires > libedataserver-1.2.so.23()(64bit), but none of the providers can be > installed > - evolution-data-server-3.30.5-2.fc29.x86_64 does not belong to a > distupgrade repository > > > Maybe mail the ML asking if anyone wants to take it up and fix it? Same problem on my system today. Cheers. Denis
Problem is ekiga upstream is dead so it's a matter of constantly gluing it back together with any changes to upstream packages. I'm happy if someone is interested in taking over the stack (ptlib/opal/ekiga) but I do wonder if it's worth it.
Yeh, probably best to orphan it if it's dead---I doubt it's commonly used nowadays with the plethora of apps that include its functionality. If no one picks it up, it'll be retired (and added to fedora-obsolete-whatever) to ensure that the upgrade path doesnt break?
Could somebody review https://src.fedoraproject.org/rpms/ptlib/pull-request/1 and merge, please?
*** Bug 1710756 has been marked as a duplicate of this bug. ***
*** Bug 1707697 has been marked as a duplicate of this bug. ***
(In reply to Ankur Sinha (FranciscoD) from comment #14) > Yeh, probably best to orphan it if it's dead---I doubt it's commonly used > nowadays with the plethora of apps that include its functionality. Surprisingly but it's hard to find a SIP client which works in Fedora. Empathy (telepaty) is dead as well, Twinkle isn't very functional (lacks G.729, standalone). I'm going to try Pidgin - let's see if it works with SIP-servers.
(In reply to Peter Lemenkov from comment #18) > (In reply to Ankur Sinha (FranciscoD) from comment #14) > > Yeh, probably best to orphan it if it's dead---I doubt it's commonly used > > nowadays with the plethora of apps that include its functionality. > > Surprisingly but it's hard to find a SIP client which works in Fedora. > Empathy (telepaty) is dead as well, Twinkle isn't very functional (lacks > G.729, standalone). I'm going to try Pidgin - let's see if it works with > SIP-servers. And here it is - SIP is not working in Pidgin. https://developer.pidgin.im/ticket/9754 So the only VoIP option left is to use Android. Might not be a problem for a regular user but SIP-development on Fedora becomes troublesome.
I would like to see some feedback for https://copr.fedorainfracloud.org/coprs/robert/ekiga/ in order to get Ekiga back again.
(In reply to Robert Scheck from comment #20) > I would like to see some feedback for > https://copr.fedorainfracloud.org/coprs/robert/ekiga/ in order to get Ekiga > back again. I've just tried it - it works for me. Please push the changes back to Fedora - let's make it available.
Feel free to do a PR, if anyone wishes to assist and co-maintain also reach out
(In reply to Peter Lemenkov from comment #21) > I've just tried it - it works for me. Please push the changes back to Fedora - let's make it available. Do calls really work for you (inbound, outbound) or does Ekiga just start and connect properly? Because...I've gotten a negative testing result for calls, but I wasn't able to track the cause down (likely in ptlib or opal due to latest gcc).
(In reply to Peter Robinson from comment #22) > Feel free to do a PR, if anyone wishes to assist and co-maintain also reach out I'll create a pull request once I've some positive feedback (see comment #23) and I'll then apply for co-maintainer for these three packages.
*** Bug 1711937 has been marked as a duplicate of this bug. ***
(In reply to Robert Scheck from comment #23) > (In reply to Peter Lemenkov from comment #21) > > I've just tried it - it works for me. Please push the changes back to Fedora - let's make it available. > > Do calls really work for you (inbound, outbound) or does Ekiga just start > and connect properly? Because...I've gotten a negative testing result for > calls, but I wasn't able to track the cause down (likely in ptlib or opal > due to latest gcc). I've just tested it with SEMS announcement module - I was able to dial in and hear some audio. So calls looks ok (SIP flow is normal). I cannot test 2-way audio - I suspect there is something with my mic settings in Ekiga or something. Let's push it and give it a try. I believe a somewhat troublesome app is better than app which is completely broken.
So, here we go: - https://src.fedoraproject.org/rpms/ptlib/pull-request/2 - https://src.fedoraproject.org/rpms/ekiga/pull-request/1 Peter, my FAS name is robert (-> ekiga, ptlib and opal).
ekiga-4.0.1-44.fc30 ptlib-2.10.11-3.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-c5e3dc44ba
ekiga-4.0.1-44.fc30, ptlib-2.10.11-3.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-c5e3dc44ba
ekiga-4.0.1-44.fc30, ptlib-2.10.11-3.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.