Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fedora RPM package #234

Closed
tim77 opened this issue Apr 9, 2019 · 6 comments
Closed

Fedora RPM package #234

tim77 opened this issue Apr 9, 2019 · 6 comments

Comments

@tim77
Copy link

tim77 commented Apr 9, 2019

Not issue, just info:

📦 GameHub RPM package in COPR

How to install:

sudo dnf copr enable atim/gamehub -y && sudo dnf install gamehub -y

Run:

com.github.tkashkin.gamehub
@lewellyn
Copy link
Contributor

Packages are being tracked in #156. There are a few of us working on various distros' packages. @hogarthj has been working on COPR packaging for a while. It might be worthwhile for you two to join forces. :)

@tim77
Copy link
Author

tim77 commented Apr 12, 2019

Wow nice indeed. I searched and didn't found any COPR repo. Now GameHub in official repos and ready for testing.

@lewellyn
Copy link
Contributor

lewellyn commented Apr 13, 2019

I'd suggest taking into account the suggestion made for my package to include debugging symbols as well as #162. It'd also be more useful in general if you discussed on #156 so that everyone working on packaging has one place to look for information on making their packages better.

Additionally, I'd suggest building against libmanette. I don't know if you tried to or not, as I only looked at the build log. Getting to the actual .spec from a bodhi/koji page always gets me lost. :(

@tim77 tim77 mentioned this issue Apr 13, 2019
@PanagiotisS
Copy link

I'd suggest taking into account the suggestion made for my package to include debugging symbols as well as #162. It'd also be more useful in general if you discussed on #156 so that everyone working on packaging has one place to look for information on making their packages better.

Additionally, I'd suggest building against libmanette. I don't know if you tried to or not, as I only looked at the build log. Getting to the actual .spec from a bodhi/koji page always gets me lost. :(

Following the above I changed the %meson macro in the .spec file as follows and I do not encounter the compatibility run issue anymore:

%build

CFLAGS="$CFLAGS -O0" meson \
    --buildtype=debug \
    --prefix=%{_prefix} \
    --libdir=%{_libdir} \
    --libexecdir=%{_libexecdir} \
    --bindir=%{_bindir} \
    --sbindir=%{_sbindir} \
    --includedir=%{_includedir} \
    --datadir=%{_datadir} \
    --mandir=%{_mandir} \
    --infodir=%{_infodir} \
    --localedir=%{_datadir}/locale \
    --sysconfdir=%{_sysconfdir} \
    --localstatedir=%{_localstatedir} \
    --sharedstatedir=%{_sharedstatedir} \
    --wrap-mode=%{__meson_wrap_mode} \
    --auto-features=%{__meson_auto_features} \
    %{_vpath_srcdir} %{_vpath_builddir} \
    %{nil}

%meson_build

Explanation:

Looking at the file /usr/lib/rpm/macros.d/macros.meson you can see how the %meson macro expands. Therefore I copied the macro and changed --buildtype=debug which was --buildtype=plain, and included the CFLAGS="$CFLAGS -O0".

My system:

$lsb_release 
Distributor ID: Fedora
Description:    Fedora release 29 (Twenty Nine)    
Release:        29
Codename:       TwentyNine
$ uname
5.0.7-200.fc29.x86_64

@PanagiotisS
Copy link

PanagiotisS commented Apr 18, 2019

Additionally, I'd suggest building against libmanette. I don't know if you tried to or not, as I only looked at the build log. Getting to the actual .spec from a bodhi/koji page always gets me lost. :(

Libmanette is not part of Fedora 29
The .spec includes the following

%if 0%{?fedora} >= 30
BuildRequires:  pkgconfig(manette-0.2)
%endif

EDIT:
The building directory can be found at the builds tab at the bottom. Select which fedora version you want. i.e. The .spec for fedora 29 for the newest (at the moment) build

@tkashkin
Copy link
Owner

tkashkin commented Jun 2, 2019

Closing this issue in favor of #156.

@tkashkin tkashkin closed this as completed Jun 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants