1:49 p.m.
Hi,
On 11/03/2015 11:57 AM, Alexandre Detiste wrote:
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 ?)
Ok, so you do plan to maintain it, that would be great as we
are currently having a shortage of active packagers for rpmfusion.
The LXC recipe I have at hand doesn't work anymore:
https://github.com/lxc/lxc/issues/626
I'm afraid I cannot help there.
---
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.
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.
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.
---
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.
---
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.
<snip>
>> 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.
I think you may want to mail Tom Callaway <tcallawa(a)redhat.com>
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.
Regards,
Hans