(reposting message first sent to games(a)lists.fedoraproject.org) Hi, My redhat/fedora skills were a bit rusty (1998-rusty), so as an exercice I dediced to port to fedora the game-data-packager Debian native project I'm working on. So far, so good, it's already mostly done. https://github.com/a-detiste/game-data-packager/commits/fedora That will provide Fedora recipes to automaticaly build noarch .rpm for currently about 200 games; one of my goal is to cover all versions of all scummvm games. It can also download shareware data for doom, quake, descent... games. http://pkg-games.alioth.debian.org/game-data/

Of course it would be better to have real Fedora users that test this; not only someone that run a minimal install on a container. (chocolate-doom works over "ssh -X" !) For example I already spotted that fedora "dynamite" package is lacking id-shr-extract program needed to unpack wolf3d shareware; but rpmfusion provides "wolf3d-shareware.noarch" sot this is not a problem.

Two interresting dependencies of G-D-P I didn't found in rpmfusion are innoextract & lgogdownloader; when installed a setup....exe sold by GOG.com can be automaticaly downloaded & repacked as a .rpm

The fedora support branch has now been completely merged in master :-) Running it from the git tree is explained here: http://anonscm.debian.org/cgit/pkg-games/game-data-packager.git/tree/doc/... $ git clone https://anonscm.debian.org/git/pkg-games/game-data-packager.git $ make "Then the `./run` command can be used instead of the system-installed `game-data-packager` command." Le mardi 3 novembre 2015, 09:54:35 Hans de Goede a écrit : > > Cool! Do you plan to maintain this for Fedora/rpmfusion in the long > run or is this just a way to exercise your Fedora skills and if we want > to make use of this do we need to find someone to step up from the > rpmfusion community to maintain this ? I'm now running it thourgh virtualbox, maintenance will be more bearable when I manage to run it in a thin container with full X/OpenGl support. (systemd-nspawn ?)

The LXC recipe I have at hand doesn't work anymore: https://github.com/lxc/lxc/issues/626

--- I managed to build the "dumb" noarch rpm's produced by G-D-P by using a simple "%files" stanza and shoving the generated specfiles to "rpmbuild -bb"; but I have more difficulties in writing G-D-P's own .spec file, It should be really easy to package by someone who is used to; one just needs to do 'make ; make check' and fill version.py with constants: http://anonscm.debian.org/cgit/pkg-games/game-data-packager.git/tree/debi... --- The generated .rpm always go to ~/rpmbuild/RPMS/noarch/ where the default is $(pwd) on Debian; I didn't found a simple way to overide this, but maybe that's not desired and it's better to remove the "--destination" option.

Having a option not to compressing 2GB rpm's that'll be used locally or rpm's that are zipfile + little else (like Quake .pk? archives) would be nice too.

--- All scummvm & z_code games (Zork, H2G2) should already work as-is. For the other games, the assets are located where the Debian-packaged engines except those, thus mostly in /usr/share/games/<something> See "grep usr/share/games data/*.yaml". So each engine needs to be reviewed.

--- Bonus: the git tree also include a launcher for the "Master Levels for Doom II"; you may want to generate a seperate .rpm with this: https://wiki.debian.org/Games/MasterLevelsForDoomII Thnigs like "['update-alternatives', '--list', 'doom']" needs porting; I'll handle that.

>> Two interresting dependencies of G-D-P I didn't found in rpmfusion >> are innoextract & lgogdownloader; when installed a setup....exe >> sold by GOG.com can be automaticaly downloaded & repacked as a .rpm > > That is cool, what are the licenses of these 2 utilities ? Both are in Debian/main, - innoextract is MIT licensed & also has it's own rpm repository - lgogdowloader is 'What The F**k' licensed (=~MIT) innoextract is now pretty much done, but lgogdownloader can break anyday when GOG.com changes it's API; so this needs more frequent updates like youtube-dl .

Le mardi 3 novembre 2015, 14:49:47 Hans de Goede a écrit : > >> I'm now running it thourgh virtualbox, maintenance will be more bearable >> when I manage to run it in a thin container with full X/OpenGl support. >> (systemd-nspawn ?) > > Ok, so you do plan to maintain it, that would be great as we > are currently having a shortage of active packagers for rpmfusion. Yes I can maintain this one package. I don't like the "summer of code" mindset of releasing something half done & then disapear. I'm also interrested into Fedora users contributing details of games(/versions) missing.

>> The generated .rpm always go to ~/rpmbuild/RPMS/noarch/ >> where the default is $(pwd) on Debian; I didn't found a simple >> way to overide this, but maybe that's not desired and >> it's better to remove the "--destination" option. > > You can pass: > > --define "_rpmdir $(pwd)" > > to rpmbuild to use the cwd as output dir, the rpms will then be written > to $(pwd/noarch I do not believe there is a way to get rid of the "noarch" > part of the path. It's a bit ugly, but --define "_rpmdir /tmp" might be of use if user want to install package right away without keeping the rpm. >> Having a option not to compressing 2GB rpm's that'll be used locally >> or rpm's that are zipfile + little else (like Quake .pk? archives) would >> be nice too. > > Erm, I'm pretty sure you can do that too, but I do not know how. I found what I needed : "%define _binary_payload w0.gzdio" & "%define _binary_payload w1.gzdio" . >> All scummvm & z_code games (Zork, H2G2) should already work as-is. >> >> For the other games, the assets are located where the Debian-packaged >> engines except those, thus mostly in /usr/share/games/<something> >> >> See "grep usr/share/games data/*.yaml". >> >> So each engine needs to be reviewed. > > Yeah, we typically put game-data under /usr/share/foo rather then > /usr/share/games/foo. But for things like scummvm you likely also > provide a .desktop for the game, passing in the right options to > start the game ? Then using /usr/share/games should be fine. Yes, indeed when a .desktop file is also generated, the assets can go anywhere; residualvm is also already ok. >>>> Two interresting dependencies of G-D-P I didn't found in rpmfusion >>>> are innoextract & lgogdownloader; when installed a setup....exe >>>> sold by GOG.com can be automaticaly downloaded & repacked as a .rpm >>> >>> That is cool, what are the licenses of these 2 utilities ? >> >> Both are in Debian/main, >> - innoextract is MIT licensed & also has it's own rpm repository >> - lgogdowloader is 'What The F**k' licensed (=~MIT) >> >> innoextract is now pretty much done, >> but lgogdownloader can break anyday when GOG.com changes it's API; >> so this needs more frequent updates like youtube-dl . > > Ok, so license wise both can go to Fedora proper rather then rpmfusion. > > innoextract definitely should go to Fedora proper. > lgogdownloader is more interesting. Which also makes me wonder about > game-data-packager itself. I really do not see any reason for them not to > be in Fedora proper, but I must admit it sort of a gray area. Both of these utilities are just a single C++ binary built with cmake + boost; so it should have been easy to build those by hand, but Fedora is lacking two dependecies: rhash & htmlcxx . So this is now 4 packages that are needed :-( I found a recipe here: http://webcache.googleusercontent.com/search?q=cache:i-GMQKVEu58J:xmodulo... I think I can handle a noarch python package, but when it comes to C++ packages that needs extra versioned libraries that gets a bit more difficult to handle. So for now I'll just use/suggest the innoextract package provided by upstream.

> I think you may want to mail Tom Callaway <tcallawa(a)redhat.com&gt; > about how acceptable both of them are for Fedora. He is the go to > persons for questions like these, and any answer he gives is the > definitive answer. lgogdownloader can also be used to download pay-per-view indie movies about My Little Pony fans and other things... http://www.gog.com/movie/bronies_the_extremely_unexpected_adult_fans_of_m... I wouldn't fight over inclusion of this or G-D-P in Debian main, so here also I won't either. I already got 2 relevant answers here before posting to rpmfusion ML: https://lists.fedoraproject.org/pipermail/games/2015-November/thread.html

Le mercredi 4 novembre 2015, 13:01:51 Hans de Goede a écrit : >> So for now I'll just use/suggest the innoextract package provided by upstream. > > I do not think this is a good idea, we really want to do this properly. Ok I'll start with this one, because: - it's the most usefull utility of the two - the most stable too - I can just re-use existing specfile (I have already pinged upstream about this) https://github.com/arx/ArxPackages/blob/master/innoextract/rpm/innoextrac...

> I've taken a quick look, packaging rhash should be easy, it comes > with Makefile-s which properly generate versioned .so libs with a > proper soname at all, and honor DESTDIR, so packaging it really is > not a big deal. And this will actually be a good exercise for showing > that you know the basics of rpm packaging, which is requires to > become a Fedora / rpmfusion packager. > As for htmlcxx it does not come with a buildsys at all, and: Huh ? The one in Debian uses autoconf https://sources.debian.net/src/htmlcxx/0.85-3.4/configure.ac https://sources.debian.net/src/htmlcxx/0.85-3.4/debian/rules So that's just a 2-lines build there; the remainder is for the manpage. %: dh $@ --with autoreconf > https://github.com/dhoerl/htmlcxx That one seems to be something totally unrelated.

> So this is what in Fedora we call a copylib, and bundling those is ok, > esp. when upstream does not provide any sort of (API) versioning > what so ever. ... so this point doesn't apply. > So you can simply put a snapshot of this in the > same src.rpm as innoextract / lgogdownloader, > and use that directly. lgogdownloader is the current _single_ reverse dependency for this in Debian, still I'd prefer to do it properly. There, this one is not maitained by the Games team for example; it was packaged by someone else years before lgogdownloader even existed. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504222 So I'd prefer to keep it separate; this part will likely require less uploads; only when GCC decide to break all C++ packages.

>> I wouldn't fight over inclusion of this or G-D-P in Debian main, >> so here also I won't either. >> >> I already got 2 relevant answers here before posting to rpmfusion ML: >> >> https://lists.fedoraproject.org/pipermail/games/2015-November/thread.html > > Ok, forget my previous comment asking to put this in Fedora then, lets > just put these 2 in rpmfusion nonfree. I still believe that innoextract belongs > in Fedora proper, so a first step at getting g-d-p in rpmfusion would be > to get innoextract into Fedora, see: Extra hint: InnoSetup (the packager) is free software, albeit windows-only. https://github.com/jrsoftware/issrc/blob/master/license.txt I'll do that; I'll send the mail to fedora-devel > I can act as a sponsor for you in Fedora. I believe this is the best > way to process because of 2 reasons: > > 1) rpmfusion currently is overhauling its infra, so getting any new > pkgs in atm is kinda hard > 2) rpmfusion requires a sponsor process for non Fedora packages just > like the Fedora process, but once you're an official Fedora packager > you get the same rights in rpmfusion automatically > > Note the list at: > > https://fedoraproject.org/wiki/Join_the_package_collection_maintainers > > Looks much longer / more complicated then the process actually is a lot > of steps are very quick. The most work is finding a sponsor (done already :) > and getting a few initial packages reviewed by your sponsor (that would be me). I'm already at the "koji build --scratch f23 rpmbuild/SRPM/innoextract-1.5-1.fc23.src.rpm" step ;-)

Le jeudi 19 novembre 2015, 13:23:48 Hans de Goede a écrit : >>> [htmlcxx] > > Ok my bad, if it uses autoconf and a straight-forward build, then by > all means do package it for Fedora. Is it ok for Fedora that the current only reverse dependency is in RPMFusion ?

> I still believe that innoextract belongs in Fedora proper, > so a first step at getting g-d-p in rpmfusion would be > to get innoextract into Fedora, see: > > https://fedoraproject.org/wiki/Join_the_package_collection_maintainers > > I can act as a sponsor for you in Fedora. I believe this is the best > way to process because of 2 reasons: > > 1) rpmfusion currently is overhauling its infra, so getting any new > pkgs in atm is kinda hard > 2) rpmfusion requires a sponsor process for non Fedora packages just > like the Fedora process, but once you're an official Fedora packager > you get the same rights in rpmfusion automatically What was needed to make the "automatically" bit work ?

I've got the same userid, email, etc.. in both FAS systems and that doesn't seems to happen. I have now manually requested to join "RPM Fusion Packagers CVS commits Group (user)" & "RPM Fusion Bugs Group (user)".

> I've just sponsored you in rpmfusion fas now, so you have all > the same rights as in Fedora now. Ok thanks, will wait on CVSsync then