Spec URL: https://raphgro.fedorapeople.org/review/openra/openra.spec SRPM URL: https://raphgro.fedorapeople.org/review/openra/openra-20141029-1.fc20.src.rpm Description: Libre/Free Real Time Strategy project that recreates the famous Command & Conquer titles Fedora Account System Username: raphgro copr: http://copr-be.cloud.fedoraproject.org/results/raphgro/OpenRA/ koji f21: http://koji.fedoraproject.org/koji/taskinfo?taskID=7986601 rpmlint does not show any true issues besides many false positives. TODO unbundle 3rdparty stuff like embedded libraries Note also Mono guidelines: https://fedoraproject.org/wiki/Packaging:Mono?rd=Packaging/Mono#Distributing_Prebuilt_Assemblies
(In reply to Raphael Groner from comment #0) … > TODO unbundle 3rdparty stuff like embedded libraries https://github.com/OpenRA/OpenRA/issues/6863
FYI: Open.NAT¹ is a fork of the somehow dead project Mono.NAT (review request: bug #1166897), and so seems to be the new hope instaed. Asking upstream² what the plan is or should be. ¹ https://github.com/lontivero/Open.NAT ² https://github.com/OpenRA/OpenRA/issues/7140
I am waiting for upstream. They promised a patch to remove the b0rken feature to use mono-nat (bundled 3rdparty).
Upstream gave up with a port to use Open.NAT instead of upstreamly dead Mono.NAT.
(In reply to Raphael Groner from comment #4) > Upstream gave up with a port to use Open.NAT instead of upstreamly dead > Mono.NAT. This decision could be overthought and reverted at upstream cause of a PR to backport of Open.NAT to .NET 3.5 https://github.com/lontivero/Open.NAT/pull/31
I already built Mono.NAT for Fedora 22 10 months ago at: https://build.opensuse.org/package/show/games:openra/mono-nat
Upstream moved from Mono.NAT to Open.NAT, see https://github.com/OpenRA/OpenRA/pull/10281 I'll start a new review request for Open.NAT .
After a long hiatus we decided to do that not yet, because it is not possible to get Mono or .NET >= 4.5 to run on Windows XP which parts of the community still use. https://github.com/OpenRA/OpenRA/pull/10279
After a long hiatus I decided to fully stop my work with OpenRA packaging. Unfortunately, there are too many unresolvable issues with the bundled libraries and upstream is unwilling to accept proposed solutions and denies patches.
Which patches from your side were denied? Maybe I can take a look and talk to Paul.
Note, that we ditched Windows XP support in favor of modern Linux variants https://github.com/OpenRA/OpenRA/pull/11284 even though that caused a minor shit storm. http://www.ppmforums.com/viewtopic.php?t=42725
(In reply to Matthias Mailänder from comment #10) > Which patches from your side were denied? Maybe I can take a look and talk > to Paul. Let's assume you read my reports on GitHub and I don't want to invest my costly time to explain the same things again and again to repeat my feeling about noone understood.
I haven't subscribed to the whole OpenRA bug tracker anymore as the sheer amount would blow up my inbox and I decided to step down from development a bit. Can you maybe list your key blockers? I can try to work on them during the holidays and put them back on the agenda. I know that it is way easier to bundle everything and that clean cross-platform C# dependencies is still a long way to go. Sometimes you have to make compromises especially when dealing with a large group of non-technical consumers and you only have very limited free time to support them. See also my experiments at https://build.opensuse.org/project/show/games:openra where I even went through the madness of doing so in a cross-distribution way.
Unbundling third party libraries shouldn't be a hard blocker anymore due to changes in Fedora's policies. Is there licensing issues? If not, this should still be good to package, providing any bundled software (that can't be removed) is built from source and the necessary "Provides: bundled(*)" are added.
If getting software into Fedora is such an bureaucratic, time-consuming and laborious we could also collaborate together on a FlatPak/AppImage bundle that works across distributions. https://github.com/OpenRA/OpenRA/issues/12257 I guess this task will fail anyway in the IP review as OpenRA relies a lot on foreign intellectual property. Even though trademarks are avoided, the code is a clean room implementation and most of the assets are hosted separately on a community mirror server with silent approval from Electronic Arts, I assume licensing and redistribution of files as in https://github.com/OpenRA/OpenRA/tree/bleed/mods/ra/bits are a real problem, that has to be addressed first.
If getting software into Fedora is such an bureaucratic, time-consuming and laborious act, we could also collaborate together on a FlatPak/AppImage bundle that works across distributions. https://github.com/OpenRA/OpenRA/issues/12257 I guess this task will fail anyway in the IP review as OpenRA relies a lot on foreign intellectual property. Even though trademarks are avoided, the code is a clean room implementation and most of the assets are hosted separately on a community mirror server with silent approval from Electronic Arts, I assume licensing and redistribution of files as in https://github.com/OpenRA/OpenRA/tree/bleed/mods/ra/bits are a real problem, that has to be addressed first.
(In reply to Matthias Mailänder from comment #16) > If getting software into Fedora is such an bureaucratic, time-consuming and > laborious act, we could also collaborate together on a FlatPak/AppImage > bundle that works across distributions. > https://github.com/OpenRA/OpenRA/issues/12257 > > I guess this task will fail anyway in the IP review as OpenRA relies a lot > on foreign intellectual property. Even though trademarks are avoided, the > code is a clean room implementation and most of the assets are hosted > separately on a community mirror server with silent approval from Electronic > Arts, I assume licensing and redistribution of files as in > https://github.com/OpenRA/OpenRA/tree/bleed/mods/ra/bits are a real problem, > that has to be addressed first. IMHO, most of the bureaucratic issues came down to the strict no-bundling policy and a few other issues that have since been reworked and "loosened". Although in regard to the "foreign intellectual property", I can imagine you are correct, but I can't speak for the legal team. RPMFusion could be used to package this if legal rejects this, but with that said, I would still think that a FlatPak would be the easiest option.
I managed to drop 2 dependencies with https://github.com/OpenRA/OpenRA/pull/12702 with the help of the Maxmind C# developers.
Any progress on this bug? I rather like this game too and it'd be nice to see Fedora becoming one of only two distributions I'm aware of with it in an official repository with the other being Arch Linux.
No, not really. I also lost interest. As the Mono/.NET distribution packaging isn't really working well and it's not looking like it's getting better in the future after the acquisition of Xamarin from Microsoft, the OpenRA team will probably look into containerized apps, but hasn't really decided on what format to choose: * https://github.com/OpenRA/OpenRA/issues/12663 FlatPak * https://github.com/OpenRA/OpenRA/issues/12257 AppImage * https://github.com/OpenRA/OpenRA/issues/11133 Snap
I actually filed the AppImage request, but my guess is a decision is months, if not years away, hence why I'm interested in distro-specific packages. But I suppose such is life, at least there's unofficial OpenRA packages available for Fedora.