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...
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
<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.
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
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