Packages

[tkashkin]

Debian/Ubuntu-based distros

• Prebuilt deb packages from releases
• PPA: https://launchpad.net/~tkashkin/+archive/ubuntu/gamehub

---

Other distros

Distro	Package(s)	Maintainer(s)
Arch Linux	gamehub-git	@FabioLolix, @neuromancer
	gamehub	@FabioLolix
fedora	gamehub	@tim77
openSUSE	gamehub	@lewellyn
OpenMandriva	gamehub	@AngryPenguinPL

[tkashkin]

@neuromancer, @hogarthj any updates on GameHub packages?

[FabioLolix]

I'm interested in AUR packages maintainership/co-maintainership, had made updated pkgbuilds for Gamehub (not online ATM), can get in touch with current AUR maintainers in the next days

[neuromancer]

@FabioLolix Let's co-maintain the gamehub(-git) packages. My AUR username is neuromancer. Do you know the exact procedure to change the current ones?

Also, can we ask ArchLinux to include a stable version of GameHub as a precompiled package? That could be great!

[friday]

My Arch build now is basically the gamehub-git package modified to use the dev branch, adding this very much needed change and overriding strip (debug symbols).

The first two changes solves very critical issues for me, and I think gamehub-git would benefit hugely from both. gamehub should by convention not use the dev branch, but *-git packages means the working branch, which is dev.

The dependencies may still be outdated though, though not what I've seen.

[friday]

Update: @btd1337 updated the gamehub-git aur with my suggestions. It works well now imo.

If you have AUR accounts you can help out by upvoting it, so it's more likely other users will use gamehub-git rather than the one just named gamehub

[tkashkin]

gamehub-git was disowned by @btd1337.

Now I am a primary maintainer of this package, however I don't have experience with Arch and AUR.

Does anyone want to co-maintain this package?

[neuromancer]

I don't have experience with AUR (just in Arch in general), but I should be able to help you, since I re-install that package frequently 😄

[tkashkin]

@neuromancer I have added you as a co-maintainer.

[neuromancer]

Great, I just received the notification for that.

[FabioLolix]

You can add me too, I didn't have much time lately but I have some experience with the AUR

[friday]

I'm not sure there'd be a benefit to me also having that role, but don't mind helping out here.

This fixes the issues I know of in PKGBUILD.

You may want to change _branch to master now too, depending on which branch has the latest version?

Someone also suggested changing to arch=('any') but I can't verify this works and/or is a good idea. The dependencies would have to work too I think.

[FabioLolix]

Updates coming, an orphan request for gamehub on AUR has been asked some days ago and accepted today.

There will be some things to specify:

• complete maintainers contact info
• add/re-add optdepends (with description)
• decide if keep debug options

I have adopted @friday's CFLAGS="$CFLAGS -O0" meson to launch Factorio

Improved/fixed/unified the packages and things like license,arch=(), fixed link creation. Removed unnecessary custom variables

While not all dependencies are listed the packages compile in a clean chroot

FabioLolix/PKGBUILD@54358dc

---

overriding strip (debug symbols).

exists the !strip option, but what did the trick was $CFLAGS -O0

but *-git packages means the working branch, which is dev.

IMO, $name-git package should track master branch, while different packages should track other banches ($name-$branch-git) usually

Someone also suggested changing to arch=('any') but I can't verify this works and/or is a good idea.

Bad idea, because the package is compiled, any is used for Perl, PHP, icon themes, etc..

[friday]

Nice!
com.github.tkashkin.gamehub --version shows the right branch now, even without -Dgit_branch. Not sure why, but good. 👍

IMO, $name-git package should track master branch, while different packages should track other banches ($name-$branch-git) usually

Perhaps. I've never seen $name-$branch-git, but I've seen $name-dev instead of / in addition to $name-git. I haven't found any documented conventions about this particular case. For GameHub dev was the clear choice imo, but now it depends on how @tkashkin intends to do further development.

[hogarthj]

@tkashkin apologies but life got in the way a bit (vacations, work and sickness ... been a busy few months) .... I'm back again now ... just did a test build and looking good with the polkit and overlay changes :)

I'll update with the COPR soon and a PR that will allow RPM builds with the spec I have soon.

[AngryPenguinPL]

RPM packages ready for OpenMandriva Cooker (upcoming Lx4) for all supported arch x86, znver1, x86_64, ARMv7hnl and aarch64.

OpenMandriva users can install it via:

dnf install gamehub

https://abf.openmandriva.org/openmandriva/gamehub/build_lists

[tkashkin]

GameHub now depends on libunity since 3084beb. More info: #225.

[lewellyn]

FWIW, I've put together a pretty solid package for openSUSE on OBS: https://build.opensuse.org/package/show/home:lewellyn:gamehub/gamehub

I'm using it myself, so this isn't just a "it builds!" sort of thing... I have a pretty sizable library (a couple thousand games) and I've put the app I've packaged through its paces a bit, including controller support. :)

At this moment, only Tumbleweed builds properly. I've been working on the build dependencies for Leap (42.3, 15.0, and 15.1) and SLE. I'm also going to try to get it building for at least one other RPM-based distro, mostly as a build canary. (If something fails for another distro, it will let me know to be wary for changes in openSUSE so I can avoid build failures.)

It's set up so that I can give @tkashkin a URL to use as a GitHub webhook and it'll automatically force a new build each time there's a commit to git. 👍 Until such time as it's requested of me, I'll kick off fresh builds manually pretty often.

Note that my intent with this package is to have a good, solid current-dev-git GameHub in openSUSE. I'm not unwilling to build one for current release, as well. But I see more value at the moment in testing the sharpest edges in hopes of exposing bugs, to make sure that once it ends up in actual distro packages it's as stable as can be.

I'm aware of at least two other GameHub packages in OBS. I feel that mine is closer to a release-grade package at this time. I'm not here to disparage the hard work of others, so I'll not detail for posterity the issues I had with their packages. I'm quite willing to work with anyone who wants to help with making a better package and experience. Even people who use other RPM-based distros. gasp :)

With enough users and feedback of this package, I'd be willing to submit my changes to the X11:Pantheon:Apps repo, in hopes of getting a distro package of GameHub (for tagged releases) once libunity is in Factory rather than only in an OBS repository.

@tkashkin I can provide you a one-click install file for users to click on your project page, if you wish. Send me a message and we can work that out. :)

(For those curious about the version format I chose, it's "TAG+commits after tag_commit hash". I wanted a - instead of a _, but there are some battles worth fighting and I decided to let the source service win that one... I can't get it to keep the dashes in the tag either...)

[tkashkin]

@lewellyn

once libunity is in Factory rather than only in an OBS repository

libunity dependency is now optional since it's not essential.

For those curious about the version format I chose, it's "TAG+commits after tag_commit hash"

Tags are created automatically by AppVeyor after each commit if build was successful. It means that commits after tag should almost always be 0.

#236 suggests that com.github.tkashkin.gamehub -v doesn't list full version and commit.
You can pass -Dgit_branch=, -Dgit_commit= and -Dgit_commit_short= options to meson. See #172 (comment).

It also might be worth to use --buildtype=debug option to keep debug symbols to get more useful gdb stacktraces. And compiler optimizations should be disabled because #162.

[lewellyn]

@lewellyn

once libunity is in Factory rather than only in an OBS repository

libunity dependency is now optional since it's not essential.

What gets lost by not including it? Considering it's in a repo that's likely to end up in Factory/Tumbleweed (similar to Debian Unstable or Fedora Rawhide), I have a preference to keep the dependency for the moment (where it's resolvable) if it creates a higher-quality app or experience.

For those curious about the version format I chose, it's "TAG+commits after tag_commit hash"

Tags are created automatically by AppVeyor after each commit if build was successful. It means that commits after tag should almost always be 0.

OK. So there's a chance that if the sources are pulled in that minute or so between commit and AppVeyor's build, the tag won't reflect reality? I've stripped everything but the tag from the version now.

#236 suggests that com.github.tkashkin.gamehub -v doesn't list full version and commit.
You can pass -Dgit_branch=, -Dgit_commit= and -Dgit_commit_short= options to meson. See #172 (comment).

It also might be worth to use --buildtype=debug option to keep debug symbols to get more useful gdb stacktraces. And compiler optimizations should be disabled because #162.

Sorry, I had misread the comment in the New Issue template as "compiled with optimization turned on", as I always peek in those when building something to try to make them useful if they die. :)

I have resolved the build information, as well:

Version: 0.13.1-cac6092-dev
Branch:  dev
Commit:  cac6092 (cac6092ffec62b416e1daa23beae8323d0b902a0)
Distro:  openSUSE Tumbleweed
DE:      XFCE

Unfortunately, as I lose the short hash by the time the build process starts, I am just taking the first 7 characters of the full commit hash. This is, effectively, all git is doing. :)

I've run and tested the bits locally and have recently pushed them to my repo so that they will automatically build.

If you have any additional feedback or requests, I'm willing to oblige to the best of my ability. 👍 I'd also be interested in feedback from those packaging for other RPM distros. I haven't taken the time to really look at the other specs yet; just enough to sanity check that I was doing approximately the correct thing.

[tkashkin]

@lewellyn

libunity dependency is now optional since it's not essential.

What gets lost by not including it?

Nothing too important. Now it's used to implement a list of favorite games, download progress and current downloads counter on launchers/docks/etc. It's nice to have it if available but it's not required:

OK. So there's a chance that if the sources are pulled in that minute or so between commit and AppVeyor's build, the tag won't reflect reality? I've stripped everything but the tag from the version now.

Yes, tag won't be updated before build finishes successfully.

Tag format now is <version>-<build>-<branch> where <build> is AppVeyor build number.
You can ignore build number because specific version can be identified by commit hash. The main reason why it's in tag is that AppVeyor builds and tags must be unique.

[lewellyn]

Tag format now is <version>-<build>-<branch> where <build> is AppVeyor build number.
You can ignore build number because specific version can be identified by commit hash. The main reason why it's in tag is that AppVeyor builds and tags must be unique.

Hm. The tags I'm seeing in the repo are <version><branch>. I'm pretty OK with that, as I don't have git tree information by the time the build starts (basically just tag and full hash). The only reasonable way I have to pass the branch is the tag, right now. If the repo tags do change to <version>-<build>-<branch>, I'll have to be cleverer.

[vhda]

Isn't using Recommends an option?

[tkashkin]

@vhda no, all dependencies need to be listed in Build-Depends for launchpad to install them.

[tkashkin]

@Charadon, @vhda

I have decided to remove libunity-dev from Build-Depends since it's not that useful and it started to cause failed builds on Launchpad due to old dependencies.

Built package should still use libunity if libunity-dev was installed on build system but it's not required to build and will not be installed automatically.

In future I plan to remove it entirely or use/backport granite implementation.

[tkashkin]

libunity is now disabled by default. Pass -Duse_libunity=true to meson to use it.

[hlechner]

@tkashkin ( @FabioLolix, @neuromancer ) is it possible to remove the libunity from the dependences from the AUR gamehub-git? or just make it as optional dependence.

Right now, it's not possible to compile the libunity due to an incompatibility with the latest version of vala (I had to downgrade the vala to compile it)

[FabioLolix]

I'll be on it soon today Il dom 16 giu 2019, 13:39 Henrique Lechner <notifications@github.com> ha scritto:

…

@tkashkin <https://github.com/tkashkin> ( @FabioLolix <https://github.com/FabioLolix>, @neuromancer <https://github.com/neuromancer> ) is it possible to remove the libunity from the dependences from the AUR gamehub-git? or just make it as optional dependence. Right now, it's not possible to compile the libunity due to an incompatibility with the latest version of vala (I had to downgrade the vala to compile it) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#156?email_source=notifications&email_token=AEV2OT7ZVRAW4B7OKO3GRE3P2YRAZA5CNFSM4GL57MD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXZLDCQ#issuecomment-502444426>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEV2OTZ63LCOVQHYC7ETA7LP2YRAZANCNFSM4GL57MDQ> .

[neuromancer]

@tkashkin ( @FabioLolix, @neuromancer ) is it possible to remove the libunity from the dependences from the AUR gamehub-git? or just make it as optional dependence.

Let me reinstall it here to confirm this..

[neuromancer]

You are right, libunity cannot be (re)installed:

protocol-scope-interface.vala:117.3-117.51: warning: DBus methods are recommended to throw at least `GLib.Error' or `GLib.DBusError, GLib.IOError'
  public abstract async ActivationReplyRaw activate (
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
protocol-scope-interface.vala:124.3-124.57: warning: DBus methods are recommended to throw at least `GLib.Error' or `GLib.DBusError, GLib.IOError'
  public abstract async HashTable<string, Variant> search (
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
protocol-scope-interface.vala:130.3-130.43: warning: DBus methods are recommended to throw at least `GLib.Error' or `GLib.DBusError, GLib.IOError'
  public abstract async string open_channel (
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
protocol-scope-interface.vala:137.3-137.42: warning: DBus methods are recommended to throw at least `GLib.Error' or `GLib.DBusError, GLib.IOError'
  public abstract async void close_channel (
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
protocol-scope-interface.vala:142.3-142.63: warning: DBus methods are recommended to throw at least `GLib.Error' or `GLib.DBusError, GLib.IOError'
  public abstract async HashTable<string, Variant> push_results (
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
protocol-scope-interface.vala:151.3-151.42: warning: DBus methods are recommended to throw at least `GLib.Error' or `GLib.DBusError, GLib.IOError'
  public abstract async void set_view_type (uint view_type) throws IOError;
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Compilation failed: 2 error(s), 12 warning(s)
make[2]: *** [Makefile:957: libunity_protocol_private_la_vala.stamp] Error 1
make[2]: se sale del directorio '/tmp/yaourt-tmp-g/aur-libunity/src/protocol'
make[1]: *** [Makefile:571: all-recursive] Error 1
make[1]: se sale del directorio '/tmp/yaourt-tmp-g/aur-libunity/src'
make: *** [Makefile:475: all] Error 2

[neuromancer]

I think it should be solved now.

[tkashkin]

granite has been removed from dependencies since e7bffdf.
I'll push a new release to master after some testing.

[Ergo0]

not sure if this is the place to go with this, But ive been trying to build a package for my distro named crux. which can be found at https://crux.nu . While compiling the package it seems to get stuck forever with the following message :
Secret-1.gir:9452.1-9452.0: error: unexpected end of file
Secret-1.gir:9452.1-9452.0: warning: expected end element of `type'

[tkashkin]

@Ergo0 that's not helpful. Can you provide full build log?

[Ergo0]

@tkashkin So i tried to pipe the buildlog into a textfile and also tried to upload the output through wgetpaste. the problem seems to be that the build gets stuck on a loop. this is the buildlog before the error message i just posted : https://bpaste.net/show/259fd7e8f893
the last message there gets followed by :
Secret-1.gir:9452.1-9452.0: error: unexpected end of file
Secret-1.gir:9452.1-9452.0: warning: expected end element of type' Secret-1.gir:9452.1-9452.0: error: unexpected end of file Secret-1.gir:9452.1-9452.0: warning: expected end element of type'
Secret-1.gir:9452.1-9452.0: error: unexpected end of file
Secret-1.gir:9452.1-9452.0: warning: expected end element of type' Secret-1.gir:9452.1-9452.0: error: unexpected end of file Secret-1.gir:9452.1-9452.0: warning: expected end element of type'

which basically keeps repeating itself as if its stuck in a loop.

[tkashkin]

@Ergo0 this is not related to GameHub. Something goes wrong while compiling gir bindings for libsecret which is not even a direct dependency of GameHub (probably something like webkit2gtk depends on it).

[TimB87]

@Ergo0 @tkashkin I went ahead and created some missing ports, this works for me
https://nullvoid.de/crux/ports/gamehub/

[TheRealDannyBoy]

It would be nice if innoextract and the WineWrap dependencies were added as optdepends to the AUR packages. I'd be willing to do submit a patch myself if the AUR has a mechanism for that.

[stephanlachnit]

I'm interested to package this for Debian. However, do you really need the debian/ dir in the master branch? Frankly, it's not really in a good state: it uses a native format (which it really shouldn't), the debhelper version is way out of date, as is the Policy Standard, the rules file is unnecessarily complicated, Rules-Requires-Root is missing, the section isn't correct, the description too short - or more precisely - the long description doesn't exist at all, the package name breaks Debian conventions, the changelog isn't updated since 0.14, it lacks a watch file, the copyright year is out of date, it recommends a DE specific tool, it lacks metadata and autopkgtest, and it suggests Steam which isn't DFSG compliant afaik.
Of course, I can just overwrite all of this, but I prefer not to do so. Putting the files in a separate branch is a good idea, I will gladly provide a PR with all the improvements I do to the Debian package.

[tkashkin]

@stephanlachnit Thanks for help.

I've packaged it a long time ago and I didn't research Debian packaging guidelines deep enough, so it's definitely not a good package. Some of the issues you've listed come from elementary packaging guidelines because initially GameHub targeted primarily elementary OS.

it recommends a DE specific tool

file-roller can be called at runtime to extract archives. I should probably implement
it inside GameHub, but now it depends on file-roller for some actions (not required in most cases).

Putting the files in a separate branch is a good idea

Yes, I agree. It will slightly complicate CI scripts, but I planned to rewrite them anyway.

[stephanlachnit]

Another things I noticed: it looks like you bundle libs for flatpak. Can you avoid this and download them when building instead? (iirc this is easily possible)
Debian packaging guidelines require to specify the correct license for every single file in the source package, this is something which is impossible when bundling sources as tars, making it impossible to get GameHub into Debian.

[tkashkin]

@stephanlachnit Does it matter even if these libs are not used by debian package? Would moving them to a separate branch or repo be enough if it matters?

I plan to rewrite flatpak in future anyway and flatpak-specific files will likely be in a separate branch as well as debian/. snap/ should be removed since it's broken.

[Saroufim]

Is there a possibility of adding GameHub once again to Flathub? Lutris is already there on the beta channel.

[stephanlachnit]

It depends. It does matter if it's inside the source package. Usually we just use the autogenerated one from github when a version is tagged. These tarball include the entire repo, so yes that would be a problem.
Moving them in a separate branch solves this, or alternatively by creating a source tarball for every release.

[tkashkin]

@Saroufim I will try if I can fix existing issues.

[tkashkin]

@stephanlachnit I'll move them to a separate branch.

[emorrp1]

When installing the flatpak bundle from the releases page, I had to run with --user otherwise it fails to find the runtime:

:~ $ flatpak install ~/Downloads/GameHub-bionic-0.16.0-1-master-b0f5e25.flatpak 
error: The application com.github.tkashkin.gamehub/x86_64/master requires the runtime org.gnome.Platform/x86_64/3.28 which was not found
:~ $ flatpak install --user ~/Downloads/GameHub-bionic-0.16.0-1-master-b0f5e25.flatpak 
Info: (pinned) org.gnome.Platform//3.28 is end-of-life, with reason:
...

This is with flatpak 1.10 on Debian buster-backports

[yangfl]

FYI: https://repology.org/project/gamehub/versions