FreeOrion

Forums for the FreeOrion project
It is currently Wed Dec 13, 2017 2:52 pm

All times are UTC




Post new topic Reply to topic  [ 14 posts ] 
Author Message
PostPosted: Fri Nov 11, 2016 5:10 pm 
Offline
Space Krill

Joined: Fri Nov 04, 2016 12:27 am
Posts: 6
Hi everyone,

I just thought I'd share my efforts to package your amazing game into an installable RPM for those who want to skip past the compilation phase and just play the game:

The link to my efforts is here.

These RPMs were only built for Fedora 23 and 24. I'll package Fedora 25 when it gets out of Beta next week.

Due to library issues, this can't be installed onto CentOS 7 at this time.

I hope this helps!


Last edited by l2g on Fri Nov 11, 2016 5:27 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Fri Nov 11, 2016 5:13 pm 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12041
Location: Munich
"FreeOrion" should be one word.

Your page's link to the Fedora Magazine article doesn't work... flipped text and link, I think.


Top
 Profile  
 
PostPosted: Fri Nov 11, 2016 5:26 pm 
Offline
Space Krill

Joined: Fri Nov 04, 2016 12:27 am
Posts: 6
Thank you for such a fast response!

Duly noted and fixed!


Top
 Profile  
 
PostPosted: Fri Nov 11, 2016 5:43 pm 
Offline
Programmer
User avatar

Joined: Fri Mar 01, 2013 9:52 am
Posts: 1040
Location: Germany
Thanks for your effort but there are some more wrong parts in the article:

Quote:
There are 2 directories you’ll want to know about:

DIRECTORY DESCRIPTION
~/.freeorion The directory all of your local configuration gets written to when the game is running.
~/.local/share/freeorion The directory that the system will write some variable data to (such as your saved games).


We try to follow the XDGBaseDir specification on non-Apple UNIX since v0.4.6. Unless there is a bug ~/.freeorion should not exist. Also there is '~/.config/freeorion/' with it's associated XDGBaseDir meaning.

Quote:
/usr/bin/freeoriond: A server platform you can optionally run which can host games for you and allow you to share your game with others.
/usr/bin/freeorionca: Artificial Intelligence (AI) client server. This can connect to a freeoriond server and simulate additional AI.


Both are more some kind of libexec-ish tools and are not considered user visible executable (freeoriond most of the time, freeorionca all the time). Also freeorionca is not a server, it doesn't open a port and listens for incoming network connections but a client.


I'm curious about the spec file. Do you have a direct link to it that doesn't involve downloading the srpm?

_________________
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz


Top
 Profile  
 
PostPosted: Fri Nov 11, 2016 5:44 pm 
Offline
Programmer
User avatar

Joined: Fri Mar 01, 2013 9:52 am
Posts: 1040
Location: Germany
Also do you plan to make this a fedora hosted package?

_________________
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz


Top
 Profile  
 
PostPosted: Fri Nov 11, 2016 5:55 pm 
Offline
Space Krill

Joined: Fri Nov 04, 2016 12:27 am
Posts: 6
I couldn't have asked for a better person to provide feedback.

Here is the link to the patch i had to make and here is the link to the spec file.

The patch is only good for this release and merely pre-acomplishes the prep configuration by the make file which reads uses the git libraries and .git directory to determine the version. Once 0.4.6 is figured out, it generates a header file that 'everything' needs. Precreating this (and one other file with similar characteristics) is all the patch accomplishes.

It took me several tries and tweaks to get everything to build properly and create a spec from scratch. But when i saw that 3 binaries were compiled (on top of freeorion itself), i got a bit confused and just included them in the packaging (to be safe).

The documentation surrounding them are based on executing them with a --help switch. I figured i'd include them and that they were probably automatically spawned anyway from the freeorion binary. Anyway, i took them out of the blog based on your description (but not from the installation - should i?)

As per the .config/freeorion; another great find on your part. It is totally documented that way (and appears on my system as such). That was just another typo found by you; you're really good at this editing stuff!

Please continue to fire away comments and educate me! I'm only making the blog entry better with all your help :) Thank you!


Top
 Profile  
 
PostPosted: Fri Nov 11, 2016 6:46 pm 
Offline
Programmer
User avatar

Joined: Fri Mar 01, 2013 9:52 am
Posts: 1040
Location: Germany
I'm only focusing on the packaging part. Other may give better answers for end user resources.

  • There is no point in a lib package. The libraries are used by the game and developed as part of the game. They are not intendend for third party use.
  • There is no point in the development package for the same reason as for the lib package.
    There is no point for copying the header files. They are not needed by the program.
  • If you want to split up packages I suggest you follow the layout of the debian package, which split freeorion into freeorion (architecture specific binaries and libraries) and freeorion-data (game assets that don't rely on the host arch). Essentially everything inside 'usr/share/freeorion/' should be 'freeorion-data' and everything else 'freeorion'.
    https://anonscm.debian.org/cgit/pkg-gam ... an/control
    https://anonscm.debian.org/cgit/pkg-gam ... ta.install
    https://anonscm.debian.org/cgit/pkg-gam ... on.install
  • There is no need to have doxygen as build requirement unless you plan to build the (internal) API documentation.
  • Don't let you fool by the message for searching libtiff and libjpeg, CMake searches for those but we don't use or need them. If they are not installed CMake will configure the game to build without them.
  • Is there a particular reason why you build against zlib-static?
  • The ldconfig call is pointless, we build with RPATH enabled.
  • The `%{_prefix}/lib/freeorion/*.so` line will probably break on x86_64 arches.


Other than that it's probably better to ask fedora upstream what kind of inprovements they will prefer/require.

_________________
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz


Top
 Profile  
 
PostPosted: Fri Nov 11, 2016 7:11 pm 
Offline
Space Krill

Joined: Fri Nov 04, 2016 12:27 am
Posts: 6
I will quote my answers to your reply; it's easier to do:
adrian_broher wrote:
There is no point in a lib package. The libraries are used by the game and developed as part of the game. They are not intendend for third party use.

Well the lib package exists only because the -devel package was created. But in another comment you mention that there is no value in this approach. So I can merge it with the freeorion rpm and drop the devel; no problem.

adrian_broher wrote:
If you want to split up packages I suggest you follow the layout of the debian package, which split freeorion into freeorion (architecture specific binaries and libraries) and freeorion-data (game assets that don't rely on the host arch). Essentially everything inside 'usr/share/freeorion/' should be 'freeorion-data' and everything else 'freeorion'.
https://anonscm.debian.org/cgit/pkg-gam ... an/control
https://anonscm.debian.org/cgit/pkg-gam ... ta.install
https://anonscm.debian.org/cgit/pkg-gam ... on.install

Good idea; one of my concerns was just how much packaging of loose data there was. Splitting it into 2 semi-large packages is a better approach. I'll check out the debian release as pointed out.

adrian_broher wrote:
There is no need to have doxygen as build requirement unless you plan to build the (internal) API documentation.

I will create a new empty mock enviroment and try again. If i recall; i was having issues during the compilation because it wanted those packages available to it. When provided, the building went on as planned. But i'll test again and update accordingly.

adrian_broher wrote:
Don't let you fool by the message for searching libtiff and libjpeg, CMake searches for those but we don't use or need them. If they are not installed CMake will configure the game to build without them.

Noted; just curious though; why are the checks even there then? I saw the Checking... MISSING errors and just added the libraries to make em look clean.

adrian_broher wrote:
Is there a particular reason why you build against zlib-static?

Yes, my dependencies started from this article. I will drop the requirement and rebuild the mock environment to see if things work.

adrian_broher wrote:
- The ldconfig call is pointless, we build with RPATH enabled.
- The `%{_prefix}/lib/freeorion/*.so` line will probably break on x86_64 arches.

These 2 notes go together; Red Hat/Fedora frowns on the use of RPATH (ref), but my SPEC misses the entries to eliminate the reference to it. As a result, the cmake installs the libraries in /usr/lib (hardcoded) (even for x86_64) arch. While trying to get the RPM right; that was the first thing i had to change was %{_libdir} reference (which would have been /usr/lib64/) to %{_prefix}/lib to accommodate how it deployed on the system.

Quote:
Other than that it's probably better to ask fedora upstream what kind of improvements they will prefer/require.


I'm very familiar with packaging RPMs; it's people like you who make individual ones better because you know the product better than I do. I appreciate your feedback.


Top
 Profile  
 
PostPosted: Fri Nov 11, 2016 8:08 pm 
Offline
Programmer
User avatar

Joined: Fri Mar 01, 2013 9:52 am
Posts: 1040
Location: Germany
l2g wrote:
I will create a new empty mock enviroment and try again. If i recall; i was having issues during the compilation because it wanted those packages available to it. When provided, the building went on as planned. But i'll test again and update accordingly.


This shouldn't be the case. Like the libtiff and libjpeg, the 'doc' target is not created when doxygen is missing. Doxygen isn't a build requirement.

l2g wrote:
Noted; just curious though; why are the checks even there then? I saw the Checking... MISSING errors and just added the libraries to make em look clean.


Nobody was bothered enough by the message yet to remove the cause. :o)

l2g wrote:
Yes, my dependencies started from this article. I will drop the requirement and rebuild the mock environment to see if things work.


You will need zlib. But I wondered why you use the static variant. I'm developing and running FreeOrion on Fedora just fine with the shared variant.

l2g wrote:
These 2 notes go together; Red Hat/Fedora frowns on the use of RPATH (ref), but my SPEC misses the entries to eliminate the reference to it. As a result, the cmake installs the libraries in /usr/lib (hardcoded) (even for x86_64) arch. While trying to get the RPM right; that was the first thing i had to change was %{_libdir} reference (which would have been /usr/lib64/) to %{_prefix}/lib to accommodate how it deployed on the system.


Look at your ref, the following section right behind the one you linked: https://fedoraproject.org/wiki/Packagin ... _Libraries
RPath for internal libraries is allowed. I looked it up for Fedora and other distributions when I decided to implement it like this in the first place.

The GNUInstallDir should automatically select the correct install lib or lib64 location. If it doesn't that's a bug in the Fedora cmake package. I tested it and you're right. The installation isn't placed into the lib64 directory anymore on a 64 bit host. You can circumvent this by passing 'cmake -DCMAKE_INSTALL_LIBDIR=lib64 .' into the configuration step.

Another thing that I didn't see is the check step. We don't have any test suite so the call is pointless.

_________________
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz


Top
 Profile  
 
PostPosted: Fri Nov 11, 2016 10:49 pm 
Offline
Space Krill

Joined: Fri Nov 04, 2016 12:27 am
Posts: 6
All things considered here is the new spec file which factors everything we talked about; including the RPATH ordeal.

The libs and devel packages were both removed and new data package added to host the core /usr/share/* content.

Blog updated; and new packages available for the public.

Thanks again for all of your insight!


Top
 Profile  
 
PostPosted: Fri Nov 11, 2016 11:29 pm 
Offline
Programmer
User avatar

Joined: Fri Mar 01, 2013 9:52 am
Posts: 1040
Location: Germany
l2g wrote:
All things considered here is the new spec file which factors everything we talked about; including the RPATH ordeal.


Code:
# Eliminate RPATH entries
find %{buildroot}%{_bindir} -type f \
   -exec chrpath --delete {} \;
find %{buildroot}%{_libdir} -type f \
   -exec chrpath --delete {} \;


This will break things for sure.

_________________
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz


Top
 Profile  
 
PostPosted: Sat Nov 12, 2016 2:50 am 
Offline
Space Squid

Joined: Sat Jun 02, 2012 11:29 pm
Posts: 74
Hi,

In case it might help, here are Fedora packages based off of the openSUSE one that has been around for a while:

https://build.opensuse.org/package/show ... /freeorion


Top
 Profile  
 
PostPosted: Sat Nov 12, 2016 3:45 am 
Offline
Space Krill

Joined: Fri Nov 04, 2016 12:27 am
Posts: 6
adrian_broher wrote:
This will break things for sure.

Sort of, i did have to do this:
Code:
cat << _EOF > /etc/ld.so.conf.d/freeorion.conf
/usr/lib64/freeorion
_EOF
ldconfig

# in the spec i have to add this:
cat << _EOF > %{buildroot}%{_sysconfdir}/ld.so.conf.d/%{name}.conf
%{_libdir}/%{name}
_EOF

# All of the linking works great then
ldd /usr/bin/freeorion
sh-4.3# ldd /usr/bin/freeorion | egrep freeorio
# output ..
# ....
#   libfreeorioncommon.so => /usr/lib64/freeorion/libfreeorioncommon.so (0x00007f3ed0e14000)
#   libfreeorionparse.so => /usr/lib64/freeorion/libfreeorionparse.so (0x00007f3ed0882000)
#   libGiGiSDL.so => /usr/lib64/freeorion/libGiGiSDL.so (0x00007f3ed0655000)
#   libGiGi.so => /usr/lib64/freeorion/libGiGi.so (0x00007f3eccf84000)
# ....


raptor wrote:
In case it might help, here are Fedora packages based off of the openSUSE one that has been around for a while:

https://build.opensuse.org/package/show ... /freeorion


That's brilliant! I wonder why no one bothered to ever build the Fedora RPMs if this has been around for as long as you say it has! I will test this out against the spec i have which matches very close to this one. Thanks for sharing this!


Top
 Profile  
 
PostPosted: Sat Nov 12, 2016 6:04 pm 
Offline
Space Squid

Joined: Sat Jun 02, 2012 11:29 pm
Posts: 74
The RPMs are actually built, they're just a little hard to find:

https://software.opensuse.org/package/freeorion

Once upon a time I attempted to get freeorion into the http://koji.fedoraproject.org build system, but I didn't/don't have the time to work through another distro's bureaucracy.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 14 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group