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

Packages #156

Open
tkashkin opened this issue Dec 22, 2018 · 56 comments
Open

Packages #156

tkashkin opened this issue Dec 22, 2018 · 56 comments

Comments

@tkashkin
Copy link
Owner

@tkashkin tkashkin commented Dec 22, 2018

Debian/Ubuntu-based distros


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
Copy link
Owner Author

@tkashkin tkashkin commented Dec 22, 2018

@neuromancer, @hogarthj any updates on GameHub packages?

@FabioLolix
Copy link

@FabioLolix FabioLolix commented Dec 22, 2018

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
Copy link
Contributor

@neuromancer neuromancer commented Dec 22, 2018

@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
Copy link
Contributor

@friday friday commented Jan 8, 2019

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
Copy link
Contributor

@friday friday commented Jan 12, 2019

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
Copy link
Owner Author

@tkashkin tkashkin commented Jan 29, 2019

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
Copy link
Contributor

@neuromancer neuromancer commented Jan 29, 2019

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
Copy link
Owner Author

@tkashkin tkashkin commented Jan 29, 2019

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

@neuromancer
Copy link
Contributor

@neuromancer neuromancer commented Jan 29, 2019

Great, I just received the notification for that.

@FabioLolix
Copy link

@FabioLolix FabioLolix commented Jan 29, 2019

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

@friday
Copy link
Contributor

@friday friday commented Jan 29, 2019

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
Copy link

@FabioLolix FabioLolix commented Jan 29, 2019

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
Copy link
Contributor

@friday friday commented Jan 30, 2019

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
Copy link

@hogarthj hogarthj commented Mar 1, 2019

@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
Copy link
Contributor

@AngryPenguinPL AngryPenguinPL commented Mar 27, 2019

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
Copy link
Owner Author

@tkashkin tkashkin commented Mar 29, 2019

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

@lewellyn
Copy link
Contributor

@lewellyn lewellyn commented Apr 10, 2019

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
Copy link
Owner Author

@tkashkin tkashkin commented Apr 10, 2019

@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
Copy link
Contributor

@lewellyn lewellyn commented Apr 11, 2019

@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
Copy link
Owner Author

@tkashkin tkashkin commented Apr 11, 2019

@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:

libunity_features

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
Copy link
Contributor

@lewellyn lewellyn commented Apr 11, 2019

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.

@tkashkin
Copy link
Owner Author

@tkashkin tkashkin commented Jun 6, 2019

@Charadon, @vhda

libunity is not required to build and related features will be disabled if it's not available. Built package will depend on libunity only if libunity-dev was installed in build environment.

However it's not possible to declare optional dependencies in debian/control. There is a workaround to depend on libunity-dev | dpkg but in this case Launchpad will not install libunity before building.

As a workaround you can remove libunity-dev from debian/control.in. Then rebuild package with scripts/build.sh gen_changelogs && scripts/build.sh build_deb. Resulting package should be in build/local/.

@vhda
Copy link

@vhda vhda commented Jun 6, 2019

Isn't using Recommends an option?

@tkashkin
Copy link
Owner Author

@tkashkin tkashkin commented Jun 6, 2019

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

@tkashkin
Copy link
Owner Author

@tkashkin tkashkin commented Jun 7, 2019

@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
Copy link
Owner Author

@tkashkin tkashkin commented Jun 7, 2019

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

@hlechner
Copy link

@hlechner hlechner commented Jun 16, 2019

@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
Copy link

@FabioLolix FabioLolix commented Jun 16, 2019

@neuromancer
Copy link
Contributor

@neuromancer neuromancer commented Jun 16, 2019

@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
Copy link
Contributor

@neuromancer neuromancer commented Jun 16, 2019

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
Copy link
Contributor

@neuromancer neuromancer commented Jun 16, 2019

I think it should be solved now.

@tkashkin
Copy link
Owner Author

@tkashkin tkashkin commented Jun 27, 2019

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

@Ergo0
Copy link

@Ergo0 Ergo0 commented Jun 28, 2019

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
Copy link
Owner Author

@tkashkin tkashkin commented Jun 28, 2019

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

@Ergo0
Copy link

@Ergo0 Ergo0 commented Jun 28, 2019

@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
Copy link
Owner Author

@tkashkin tkashkin commented Jun 28, 2019

@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
Copy link

@TimB87 TimB87 commented Jun 28, 2019

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

@TheRealDannyBoy
Copy link

@TheRealDannyBoy TheRealDannyBoy commented Oct 5, 2019

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
Copy link

@stephanlachnit stephanlachnit commented May 18, 2020

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
Copy link
Owner Author

@tkashkin tkashkin commented May 18, 2020

@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
Copy link

@stephanlachnit stephanlachnit commented May 18, 2020

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
Copy link
Owner Author

@tkashkin tkashkin commented May 18, 2020

@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
Copy link

@Saroufim Saroufim commented May 18, 2020

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

@stephanlachnit
Copy link

@stephanlachnit stephanlachnit commented May 18, 2020

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
Copy link
Owner Author

@tkashkin tkashkin commented May 18, 2020

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

@tkashkin
Copy link
Owner Author

@tkashkin tkashkin commented May 18, 2020

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

@emorrp1
Copy link

@emorrp1 emorrp1 commented Feb 8, 2021

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

@tkashkin tkashkin unpinned this issue Sep 2, 2021
@tkashkin tkashkin pinned this issue Sep 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet