Hi,
On 03-11-15 17:07, Alexandre Detiste wrote:
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.
That is great!
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.com/download-gog-games-command-line-linux.html+&cd=3&hl=fr&ct=clnk&gl=us
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 do not think this is a good idea, we really want to do this properly.
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:
https://github.com/dhoerl/htmlcxx
States:
"The code here is designed to be incorporated directly in your Mac or iOS project
and not as a library."
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 you can simply put a snapshot of this in the
same src.rpm as innoextract / lgogdownloader, and use that
directly.
I think you may want to mail Tom Callaway <tcall...@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.
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_my_little_pony
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:
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
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).
Regards,
Hans
