Releases retrieved: 2.77.0 Upstream release that is considered latest: 2.77.0 Current version/release in rawhide: 2.76.0-1.fc39 URL: http://www.gtkmm.org Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/7960/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/glibmm2.68
Please update to 2.77.0 in all stable Fedora branches as Telegram Desktop now require this version: https://github.com/telegramdesktop/tdesktop/pull/26419 https://github.com/desktop-app/cmake_helpers/pull/286
No, sorry, we don't update glib2 to new major releases in stable Fedora branches. glib follows GNOME release schedule and both glib and GNOME stick to the same major release that was at release time. glibmm packages are C++ bindings for glib and follow the same versioning and cannot (usually) be updated without updating glib first. I understand this is a major headache for you, but I am not sure I can help. MAYBE we could do an exception this cycle and update glib and its bindings in F38 to 2.78.x once the stable releases are out (2.77.x are development snapshots and definitely not suitable for stable Fedoras), but that could earliest happen in September when the stable GNOME 45 release is scheduled. Some ideas: Can you put the new telegram version in rawhide and keep using older version in stable branches? Alternatively, you could bundle both glib and glibmm in a private directory (/usr/lib64/telegram/ or something, together with adding RPATH that points to the private directory) so that telegram picks up the new version, but the system-wide glib2/glibmm2.68 packages stay at the stable versions. Another idea would be to talk to upstream telegram and ask if they could stick with using stable glib 2.76.x API for now until 2.78.x is actually released.