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 · 40 comments

Comments

Projects
None yet
@tkashkin
Copy link
Owner

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

This comment has been minimized.

Copy link
Owner Author

commented Dec 22, 2018

@neuromancer, @hogarthj any updates on GameHub packages?

@FabioLolix

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Owner Author

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Owner Author

commented Jan 29, 2019

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

@neuromancer

This comment has been minimized.

Copy link
Contributor

commented Jan 29, 2019

Great, I just received the notification for that.

@FabioLolix

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Owner Author

commented Mar 29, 2019

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

@lewellyn

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Owner Author

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Owner Author

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Owner Author

commented Apr 11, 2019

@lewellyn it seems that OBS removes dashes from tag, but tags in repo have dashes: tags, .obsinfo.

@lewellyn

This comment has been minimized.

Copy link
Contributor

commented Apr 11, 2019

Aha. Indeed. I forgot about that. (Dashes are special in versioning.) However, the output I gave from --version looks as you would expect, correct?

@tkashkin

This comment has been minimized.

Copy link
Owner Author

commented Apr 11, 2019

Yes

@lewellyn

This comment has been minimized.

Copy link
Contributor

commented Apr 11, 2019

@tkashkin

Ok then, I'll not worry too much about replacing the - with _ in the tag while building the tarball, I guess. Having no delimiter there is more in-line with standard packaging practice. I'd actually like to figure out how to pass the branch information to the build, so that I can make that purely the version number. I may have to try to get a pull request together for the obs_scm project to make that happen.

I'm still poking at the other distros to see what else I can make build aside from the latest and greatest rolling release bits. Would you be interested in me DMing or emailing you a webhook URL to add to AppVeyor so it'll automatically kick off a build each time there's a change to dev, and a one-click install file to make it easy for users to install?

I'm sure I still have a few bugs introduced by packaging, but the only way to find those will be to have more people using the package. 😹

@hogarthj @AngryPenguinPL

Mind taking a look at my .spec and providing feedback on the packaging therein? I'm pulling direct from git and tarring up the tag, rather than retrieving from the URL, as that lets me be very lazy and always get whatever's latest without any manual work. (Also dev/master packages can be a one-line change external to the .spec which is a nice bonus.) But otherwise, most of the rest should be familiar to other distros' methods.

@tkashkin

This comment has been minimized.

Copy link
Owner Author

commented Apr 11, 2019

Would you be interested in me DMing or emailing you a webhook URL to add to AppVeyor so it'll automatically kick off a build each time there's a change to dev, and a one-click install file to make it easy for users to install?

Sure, check my email in GitHub profile or DM me somewhere: https://tkashkin.tk/#/contacts.

@tim77

This comment has been minimized.

Copy link

commented Apr 13, 2019

In reply to @lewellyn #234 (comment)

Additionally, I'd suggest building against libmanette.

Added for Fedora 30+ builds. Thank you.


As for #162 i cant even test this myself. Cant download Bio Menace: [WARN] Forbidden

@vhda

This comment has been minimized.

Copy link

commented Apr 14, 2019

@tkashkin libunity9 is shown as Depends, so it is not optional. This is a no-go for Debian, since Unity is Ubuntu only.
Thanks!

@tim77

This comment has been minimized.

Copy link

commented Apr 15, 2019

Just FYI, no #162 for me perhaps because optimization already turned off.

But i randomly struggle with this [WARN] Forbidden when downloading games from GOG. Need more time to test this...

@Charadon

This comment has been minimized.

Copy link

commented Jun 6, 2019

Deb package doesn't work on Debian (I'm using Buster) since it still depends on libunity.

@tkashkin

This comment has been minimized.

Copy link
Owner Author

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

This comment has been minimized.

Copy link

commented Jun 6, 2019

Isn't using Recommends an option?

@tkashkin

This comment has been minimized.

Copy link
Owner Author

commented Jun 6, 2019

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

@tkashkin

This comment has been minimized.

Copy link
Owner Author

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

This comment has been minimized.

Copy link
Owner Author

commented Jun 7, 2019

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

@hlechner

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

commented Jun 16, 2019

@neuromancer

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

commented Jun 16, 2019

I think it should be solved now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.