- Spec URL: https://copr-be.cloud.fedoraproject.org/results/akien/godot/fedora-rawhide-x86_64/00725225-godot/godot.spec - SRPM URL: https://copr-be.cloud.fedoraproject.org/results/akien/godot/fedora-rawhide-x86_64/00725225-godot/godot-3.0.2-1.fc29.src.rpm - COPR build: https://copr.fedorainfracloud.org/coprs/akien/godot/build/725225/ (ignore failed Mageia builds, they're due to a mirror issue - Godot is already packaged officially in Mageia) Godot is an advanced, feature-packed, multi-platform 2D and 3D game engine. It provides a huge set of common tools, so you can just focus on making your game without reinventing the wheel. Godot is completely free and open source under the very permissive MIT license. No strings attached, no royalties, nothing. Your game is yours, down to the last line of engine code. ------- I'm an upstream developer of Godot Engine, and already package it officially in Mageia. I'd like to get it in Fedora too, and did a lot of work to properly unbundle thirdparty libraries and document thirdparty licenses upstream for this. I am already a Fedora packager (maintaining "jumpnbump") and would gladly maintain godot too once accepted. Fedora Account System Username: akien
Taking this review.
Small documentation diff for bundled libvpx on RHEL 7: https://hastebin.com/xotihoseji.diff An alternative to bundling there would be to disable WebM support for Godot on RHEL 7.
Spec review notes: > %if 0%{?mageia} > BuildRequires: appstream-util > %else > BuildRequires: libappstream-glib > %endif This could be simplified to "BuildRequires: %{_bindir}/appstream-util" "dnf install /usr/bin/appstream-util" works on both Fedora and Mageia, so I would think this should work in your spec. > # Git commit slightly newer than 2.87 > # Can be unbundled if bullet 2.88+ is available > Provides: bundled(bullet) = 2.87 If you know the Git commit, could you put that in the Provides versioning? Something like the following: Provides: bundled(bullet) = 2.87+git<commitdate>.<shorthash> > # Has some modifications for IPv6 support, upstream enet is unresponsive > # Should not be unbundled. > Provides: bundled(enet) = 1.3.13 I checked into this, it seems like upstream seems to want a mailing list discussion first[1]? I'm not entirely sure what this means, but it'd be nice if IPv6 support was in upstream enet (there are three pull requests for it...) [1]: https://github.com/lsalzman/enet/issues/78 > # Upstream commit from 2016, newer than 1.0.0.27 which is last tag > # Could be unbundled if packaged. > # Godot upstream will soon deprecate this "libsimplewebm" module. > Provides: bundled(libwebm) As you're an upstream developer, I would suggest that libmatroska would be a better alternative to libwebm (libmatroska can parse webm containers too, since they are a subset of mkv). But if you're deprecating it... > # Has custom changes to support seeking in zip archives > # Should not be unbundled. > Provides: bundled(minizip) = 1.2.4 OK. > # Could be unbundled if packaged. > Provides: bundled(nanosvg) If this[2] is the nanosvg in question, I can see why it's bundled instead of packaged. Could you indicate what commit is packaged in nanosvg? You can do something like the following: Provides: bundled(nanosvg) = 0-0.git<commitdate>.<shorthash> [2]: https://github.com/memononen/nanosvg > # Could be unbundled if packaged. > Provides: bundled(squish) = 1.15 Is there any reason it couldn't be packaged? It looks like libsquish is fairly active and releases often enough. > # Can't be unbundled out-of-the-box as it uses experimental APIs available > # only to static linking. They're not critical features though and could > # maybe be patched away to link against a shared zstd. Provides: bundled(zstd) = 1.3.3 Have you talked to upstream[3] about stabilizing the APIs used by Godot so that it can use a dynamically linked libzstd? [3]: https://github.com/facebook/zstd
(In reply to Neal Gompa from comment #3) > Spec review notes: > > > %if 0%{?mageia} > > BuildRequires: appstream-util > > %else > > BuildRequires: libappstream-glib > > %endif > > This could be simplified to "BuildRequires: %{_bindir}/appstream-util" > > "dnf install /usr/bin/appstream-util" works on both Fedora and Mageia, so I > would think this should work in your spec. Sure, will do. > > # Git commit slightly newer than 2.87 > > # Can be unbundled if bullet 2.88+ is available > > Provides: bundled(bullet) = 2.87 > > If you know the Git commit, could you put that in the Provides versioning? > > Something like the following: > > Provides: bundled(bullet) = 2.87+git<commitdate>.<shorthash> Is the `+git<commitdate>.<shorthash>` standard enough? I wouldn't want scripts relying on parsing `bundled()` provides to break due to invalid NEVR expressions. How about simply specifying the commit (d05ad4b821ba867dfd01f1e5f22c4d9d1bda6869) in a comment instead? > > # Has some modifications for IPv6 support, upstream enet is unresponsive > > # Should not be unbundled. > > Provides: bundled(enet) = 1.3.13 > > I checked into this, it seems like upstream seems to want a mailing list > discussion first[1]? I'm not entirely sure what this means, but it'd be nice > if IPv6 support was in upstream enet (there are three pull requests for > it...) > > [1]: https://github.com/lsalzman/enet/issues/78 We had very lengthy discussions before deciding to vendor and modify enet [0]. The upstream maintainer is very uncooperative (and now, completely inactive), so all projects using enet have ended up forking it for their own usage. There is as of yet no "main" fork to use as upstream, and we eventually wrote our own Godot socket interface to enet, which allows for a much better integration than if we were using the pristine code. So currently unbundling enet is not possible, and not desired. [0]: https://github.com/godotengine/godot/issues/6992 > > # Upstream commit from 2016, newer than 1.0.0.27 which is last tag > > # Could be unbundled if packaged. > > # Godot upstream will soon deprecate this "libsimplewebm" module. > > Provides: bundled(libwebm) > > As you're an upstream developer, I would suggest that libmatroska would be a > better alternative to libwebm (libmatroska can parse webm containers too, > since they are a subset of mkv). But if you're deprecating it... We're going to replace most audio and video plugins (apart from vorbis) by pluggable libraries using the GDNative interface, so that all users can simply pick the plugins they need without having to bundle all the world. > > # Could be unbundled if packaged. > > Provides: bundled(nanosvg) > > If this[2] is the nanosvg in question, I can see why it's bundled instead of > packaged. > > Could you indicate what commit is packaged in nanosvg? You can do something > like the following: > > Provides: bundled(nanosvg) = 0-0.git<commitdate>.<shorthash> > > [2]: https://github.com/memononen/nanosvg That's this nanosvg yeah, so far it's not package in distros that I know of. I haven't actually looked into packaging it yet, but it's a header-only library meant to be vendored by design. The bundled commit is 9a74da4db5ac74083e444010d75114658581b9c7. Same question as above regarding putting it as the bundled() version, can we consider that format standard? The Bundled Software policy [1] is not really explicit. [1]: https://fedoraproject.org/wiki/Bundled_Software_policy > > # Could be unbundled if packaged. > > Provides: bundled(squish) = 1.15 > > Is there any reason it couldn't be packaged? It looks like libsquish is > fairly active and releases often enough. Not that I know of, just needs someone to package it :) As long as Godot is the only user of this dependency, and we already provided bundled sources, I have little incentive to package it myself. But if it were, it's already easy to unbundle with the `builtin_squish=no` argument. The Bundled Software policy [1] doesn't explicitly require packaging thirdparty libraries to unbundle them, but only to use those libraries which are already available. Still, I'm a packager and like clean things, so I might end up packaging libsquish and thus unbundling it somewhere down the road. > > # Can't be unbundled out-of-the-box as it uses experimental APIs available > > # only to static linking. They're not critical features though and could > > # maybe be patched away to link against a shared zstd. > Provides: bundled(zstd) = 1.3.3 > > Have you talked to upstream[3] about stabilizing the APIs used by Godot so > that it can use a dynamically linked libzstd? > > [3]: https://github.com/facebook/zstd No, it's actually a Godot bug to be using experimental APIs in the first place (just opened [2] about it). The contributor who integrated zstd likely did not pay attention to this (those APIs are available when linking statically), I found out that it doesn't build against system shared libraries quite recently. AFAIK there's no reason that the stable APIs wouldn't suffice. [2]: https://github.com/godotengine/godot/issues/17374
(In reply to Rémi Verschelde from comment #4) > (In reply to Neal Gompa from comment #3) > > Spec review notes: > > > > > %if 0%{?mageia} > > > BuildRequires: appstream-util > > > %else > > > BuildRequires: libappstream-glib > > > %endif > > > > This could be simplified to "BuildRequires: %{_bindir}/appstream-util" > > > > "dnf install /usr/bin/appstream-util" works on both Fedora and Mageia, so I > > would think this should work in your spec. > > Sure, will do. > > > > # Git commit slightly newer than 2.87 > > > # Can be unbundled if bullet 2.88+ is available > > > Provides: bundled(bullet) = 2.87 > > > > If you know the Git commit, could you put that in the Provides versioning? > > > > Something like the following: > > > > Provides: bundled(bullet) = 2.87+git<commitdate>.<shorthash> > > Is the `+git<commitdate>.<shorthash>` standard enough? I wouldn't want > scripts relying on parsing `bundled()` provides to break due to invalid NEVR > expressions. > > How about simply specifying the commit > (d05ad4b821ba867dfd01f1e5f22c4d9d1bda6869) in a comment instead? > You can do that too, if you'd prefer. We don't actually have any tooling for processing bundled() Provides. It's mainly observed by humans when checking for security issues. > > > # Has some modifications for IPv6 support, upstream enet is unresponsive > > > # Should not be unbundled. > > > Provides: bundled(enet) = 1.3.13 > > > > I checked into this, it seems like upstream seems to want a mailing list > > discussion first[1]? I'm not entirely sure what this means, but it'd be nice > > if IPv6 support was in upstream enet (there are three pull requests for > > it...) > > > > [1]: https://github.com/lsalzman/enet/issues/78 > > We had very lengthy discussions before deciding to vendor and modify enet > [0]. > > The upstream maintainer is very uncooperative (and now, completely > inactive), so all projects using enet have ended up forking it for their own > usage. There is as of yet no "main" fork to use as upstream, and we > eventually wrote our own Godot socket interface to enet, which allows for a > much better integration than if we were using the pristine code. > > So currently unbundling enet is not possible, and not desired. > > [0]: https://github.com/godotengine/godot/issues/6992 > This is reasonable, though someone really should try to revive it properly so forking ad infinitum goes away... > > > # Upstream commit from 2016, newer than 1.0.0.27 which is last tag > > > # Could be unbundled if packaged. > > > # Godot upstream will soon deprecate this "libsimplewebm" module. > > > Provides: bundled(libwebm) > > > > As you're an upstream developer, I would suggest that libmatroska would be a > > better alternative to libwebm (libmatroska can parse webm containers too, > > since they are a subset of mkv). But if you're deprecating it... > > We're going to replace most audio and video plugins (apart from vorbis) by > pluggable libraries using the GDNative interface, so that all users can > simply pick the plugins they need without having to bundle all the world. > OK. > > > # Could be unbundled if packaged. > > > Provides: bundled(nanosvg) > > > > If this[2] is the nanosvg in question, I can see why it's bundled instead of > > packaged. > > > > Could you indicate what commit is packaged in nanosvg? You can do something > > like the following: > > > > Provides: bundled(nanosvg) = 0-0.git<commitdate>.<shorthash> > > > > [2]: https://github.com/memononen/nanosvg > > That's this nanosvg yeah, so far it's not package in distros that I know of. > I haven't actually looked into packaging it yet, but it's a header-only > library meant to be vendored by design. > > The bundled commit is 9a74da4db5ac74083e444010d75114658581b9c7. Same > question as above regarding putting it as the bundled() version, can we > consider that format standard? The Bundled Software policy [1] is not really > explicit. > > [1]: https://fedoraproject.org/wiki/Bundled_Software_policy > As I said earlier, it's mainly for humans to analyze, so there's no "standard" aside from using a valid RPM version-release. Since nothing is supposed to require bundled() Provides, it should be fine to use that too.. > > > # Could be unbundled if packaged. > > > Provides: bundled(squish) = 1.15 > > > > Is there any reason it couldn't be packaged? It looks like libsquish is > > fairly active and releases often enough. > > Not that I know of, just needs someone to package it :) > > As long as Godot is the only user of this dependency, and we already > provided bundled sources, I have little incentive to package it myself. But > if it were, it's already easy to unbundle with the `builtin_squish=no` > argument. > > The Bundled Software policy [1] doesn't explicitly require packaging > thirdparty libraries to unbundle them, but only to use those libraries which > are already available. Still, I'm a packager and like clean things, so I > might end up packaging libsquish and thus unbundling it somewhere down the > road. > > > > # Can't be unbundled out-of-the-box as it uses experimental APIs available > > > # only to static linking. They're not critical features though and could > > > # maybe be patched away to link against a shared zstd. > > Provides: bundled(zstd) = 1.3.3 > > > > Have you talked to upstream[3] about stabilizing the APIs used by Godot so > > that it can use a dynamically linked libzstd? > > > > [3]: https://github.com/facebook/zstd > > No, it's actually a Godot bug to be using experimental APIs in the first > place (just opened [2] about it). The contributor who integrated zstd likely > did not pay attention to this (those APIs are available when linking > statically), I found out that it doesn't build against system shared > libraries quite recently. AFAIK there's no reason that the stable APIs > wouldn't suffice. > > [2]: https://github.com/godotengine/godot/issues/17374 Good to know.
Updated spec file and SRPM based on review so far (+ fixing a wrong argument in the .desktop file that I noticed today). Supersedes the ones in comment 0 (diff: https://hastebin.com/ogozajisor.diff ) - Spec URL: https://copr-be.cloud.fedoraproject.org/results/akien/godot/fedora-rawhide-x86_64/00727777-godot/godot.spec - SRPM URL: https://copr-be.cloud.fedoraproject.org/results/akien/godot/fedora-rawhide-x86_64/00727777-godot/godot-3.0.2-1.fc29.src.rpm - COPR build: https://copr.fedorainfracloud.org/coprs/akien/godot/build/727777/
> %if 0%{?fedora} || 0%{?rhel} > %post > /bin/touch --no-create %{_datadir}/icons/hicolor &>/dev/null || : > > %postun > if [ $1 -eq 0 ] ; then > /bin/touch --no-create %{_datadir}/icons/hicolor &>/dev/null > /usr/bin/gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || : > fi > > %posttrans > /usr/bin/gtk-update-icon-cache %{_datadir}/icons &>/dev/null || : > %endif This would be RHEL-only. All currently supported Fedora releases use file triggers for this, provided hicolor-icon-theme is a requirement of the package (which it is, in this case). Also, can you move this section up to be along with the rest of the main package sections (like the file list and whatnot).
(In reply to Neal Gompa from comment #7) > > %if 0%{?fedora} || 0%{?rhel} > > %post > > /bin/touch --no-create %{_datadir}/icons/hicolor &>/dev/null || : [snip] > > This would be RHEL-only. All currently supported Fedora releases use file > triggers for this, provided hicolor-icon-theme is a requirement of the > package (which it is, in this case). > > Also, can you move this section up to be along with the rest of the main > package sections (like the file list and whatnot). Done locally: https://hastebin.com/omodelofir.diff
Could you please provide links to a spec and srpm with these fixes applied? I can't run fedora-review on diffs. :)
Here you go: - Spec URL: http://remi.verschelde.fr/files/godot/fedora/godot.spec - SRPM URL: http://remi.verschelde.fr/files/godot/fedora/godot-3.0.2-1.mga6.src.rpm
Review notes: [x] Package is named appropriately [x] Package installs and runs correctly [x] Package uses macros consistently [x] Package uses the correct scriptlets [x] Bundled libraries are noted with useful rationale [!] BUILD_REVISION isn't honored. * It looks like _you_ ripped this out: https://github.com/godotengine/godot/commit/3fd23da5ee2e69e1aca663b52ecf1f3d61188a64 [!] Changelog entry missing * Fedora packages need changelog entries: https://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs
(In reply to Neal Gompa from comment #11) > [!] BUILD_REVISION isn't honored. > * It looks like _you_ ripped this out: > https://github.com/godotengine/godot/commit/ > 3fd23da5ee2e69e1aca663b52ecf1f3d61188a64 Indeed, it must be BUILD_NAME now. > [!] Changelog entry missing > * Fedora packages need changelog entries: > https://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs Added. ----- Updated spec and SRPM at same URLs: - Spec URL: http://remi.verschelde.fr/files/godot/fedora/godot.spec - SRPM URL: http://remi.verschelde.fr/files/godot/fedora/godot-3.0.2-1.mga6.src.rpm
Looks good. PACKAGE APPROVED.
(fedrepo-req-admin): The Pagure repository was created at https://src.fedoraproject.org/rpms/godot
godot-3.0.2-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-de2aa691a1
godot-3.0.2-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-cca3843e51
godot-3.0.2-2.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-02f57f019e
godot-3.0.2-2.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-1b5f2cfdef
godot-3.0.2-2.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
godot-3.0.2-2.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.
godot-3.0.2-2.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
godot-3.0.2-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.
I'm new to Fedora; sorry if this is bad etiquette. I wanted to ask if I could request the official Godot-mono specifically to be added as well, since base Godot doesn't include C# support out of the box.
No I don't plan to package the Mono version. It has strict requirements on the way Mono is built (including patches), and distribution requirements which do not fit well with a system-wide installation. It also depends on some of the .NET stack which is not available in Fedora, such as msbuild or dotnet CLI. Use the version for godotengine.org if you want to use C#.