Description of problem: Qt 5 versions of the OpenSceneGraph qt and qt-devel packages are needed to use OpenSceneGraph with Qt 5 applications. Currently (Fedora 24) OpenSceneGraph qt and qt-devel are only available for Qt 4. Version-Release number of selected component (if applicable): 3.4.0 Additional info: It is likely that Qt 4 and 5 versions of the OpenSceneGraph Qt packages will be needed for an extended transitional period. Some discussion on the OpenSceneGraph mailing list has begun about supporting both builds in their packaging system and possibly making separate Qt 4 and 5 osgQt packages but this won't happen until OpenSceneGraph 3.6.0 at the earliest. But it should be possible to build separate Qt 4 and 5 packages with the 3.4.0 code base as is and it would be very useful to have that in Fedora 24.
(In reply to Stuart Mentzer from comment #0) > But it should be possible to build separate Qt 4 and 5 packages > with the 3.4.0 code base as is and it would be very useful to have that in > Fedora 24. Having experimented a bit with Qt4/Qt5 builts, I found this won't be easily achievable. - OSG-3.4.0's qt-libs/plugins/binaries use non-qt-versioned file names/SONAMEs. I.e. qt4 and qt5-compiled binaries will conflict at runtime/installation time. - Qt5-built OSG is slightly incompatible with Qt4-build versions of OSG-3.4.0. (Building against QT5 causes OSG to drop the osgdb_qfont.so plugin) - OSG-3.4.0 monolytical build system treats QT4 and QT5 as mutually exclusive alternatives. All in all, I don't see an easy way to implement parallel installation of qt4-/qt5-build variants.
I will forward this info to the OSG team. It sounds like they would need to have isolated Qt 4 and 5 builds with distinct install paths and lib names. I'm not sure this can happen in time for the upcoming OSG 3.6.0 release. I'll post what I find out here. It looks like the latest OSG packaging on Debian and Arch use Qt 5 builds so if supporting Qt 4 and 5 in parallel is not practical maybe switching OSG on Fedora to Qt 5 for OSG 3.6.0 would make sense.
Hi Fedora osgearth maintainer here. I suppose the upstream discussion concerning this issue is here: http://forum.openscenegraph.org/viewtopic.php?t=16024 which seems to have stalled. I don't find any other relevant discussions, so I suppose the situation upstream has not changed. I'd like to propose we switched to Qt5 starting with F27 (or perhaps already F26?) $dnf repoquery --whatrequires libosgQt.so* lists only osgearth, which already supports Qt5 so should be an easy transition. The wider rationale behind this proposal is that QGIS-3.0, which also includes the port to Qt5, is scheduled for release in Q3 2017, and QGIS includes a 3D globe plugin (which I maintain) which uses ogearth.
(In reply to Sandro Mani from comment #3) > Hi > Fedora osgearth maintainer here. I suppose the upstream discussion > concerning this issue is here: > > http://forum.openscenegraph.org/viewtopic.php?t=16024 > > which seems to have stalled. It hasn't stalled nor been forgotten ... > I don't find any other relevant discussions, so > I suppose the situation upstream has not changed. ... it's simple that. Upstream hasn't provided a new stable release, yet and I do not jump the gun of shipping unstable versions. > I'd like to propose we switched to Qt5 starting with F27 (or perhaps already > F26?) I regret, this hardly won't be possible unless OSG releases a release which supports QT5. The current version doesn't. > $dnf repoquery --whatrequires libosgQt.so* > lists only osgearth, which already supports Qt5 so should be an easy > transition. OSG is being used by more than just osgearth. Amongst these are heavy-weighted packages such as FlightGear.
Ah somehow completely missed FlightGear... Can you point to relevant upstream infos regarding this issues? I'd be interested in following them.
(In reply to Ralf Corsepius from comment #4) > I regret, this hardly won't be possible unless OSG releases a release which > supports QT5. The current version doesn't. I understand that OSG 3.4.0 doesn't make parallel packaging for Qt4 and Qt5 practical but perhaps the obstacles to just packaging it only for Qt5 are surmountable, esp. since Ubuntu manages it. Is it just the osgdb_qfont.so issue or are there others? The OSG development code that will lead to the 3.6.0 stable release has separated out an osgQt package that should simplify packaging but if there are problems with Qt5 packaging on Fedora that may affect that also we should inform the OSG team. I build 3.4.0 with Qt5 on Windows without a problem (after a few CMake tweaks) but I realize that is a very different beast. If there is work we could help on to make the switch to Qt5 possible please let us know.
Replying to myself: qt stuff has now been split off to a new project upstream, osgQt.
I've created a COPR repo for OpenSceneGraph with Qt5 support at [1]. This includes an initial package for osgQt. I've also proposed to osgQt upstream the patch I used to support side-by-side installation of osgQt-qt4 and osgQt-qt5 at [2]. [1] https://copr.fedorainfracloud.org/coprs/smani/OpenSceneGraph-qt5 [2] https://github.com/openscenegraph/osgQt/pull/3
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. 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 '24'. 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 24 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 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 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.
OSG-3.6.0 is now released, I've built it (along with the now split-off osgQt) in copr [1]. Would be nice if the update could land in Fedora proper for F29+. [1] https://copr.fedorainfracloud.org/coprs/smani/OpenSceneGraph-qt5-git/builds/
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
Following the unsuccessful attempt via direct message (s. conversation below) to obtain a proper explanation as to what is holding back updating the OpenSceneGraph package and adding Qt5 support, I'm herewith initiating the non-responsive maintainer procedure, asking the maintainer to give a proper explanation or letting go of the package if he is unwilling to maintain it. -------------------- Hi I'm still interested in hearing the reasons for not updating osg, other distros have updated long ago. Again, since I need the packages for my dayjob and don't want to keep them in COPR forever, I'm willing and interested to work on updating them. Thanks Sandro On 17.04.19 13:17, Sandro Mani wrote: > Hi > > Thanks for your reply. > > On 17.04.19 12:45, Ralf Corsepius wrote: >>> I've been maintaining up-to-date OpenSceneGraph and matching mingw builds in COPR [1] with qt5 support for the past couple of years, needing them for my dayjob, but I'd really like to get them into Fedora proper to avoid the maintenance overhead in COPR. >> Correct. I repeatedly tried to update these packages, but so far, all tries have failed for various reason in the end got stuck. > May I ask what specific issues you encountered? Are there some related upstream issues? Can other packagers help in any way? >> >>> I'd be happy to also maintain them in Fedora proper if desired - I see there has been no real update to the packages in recent times. >> >> I am aware about your packages, but last time I looked into them, I wasn't excited (no punt nor offense intended!) > > Uhm, care to give some details here? I mean, the OpenSceneGraph.spec is basically your own spec, just updated to the latest version. And the osgQt package is pretty trivial which should hardly be controversial. > > Sandro
As per non-responsive maintainer policy: Ping?
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. 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 '31'. 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 31 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 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 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.