tkashkin
Packages
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 |
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
@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!
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.
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
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?
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 :smile:
You can add me too, I didn't have much time lately but I have some experience with the AUR
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.
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
https://github.com/FabioLolix/PKGBUILD/commit/54358dcbaf952031de3091d8cad1a1f8ecbd2faf
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..
Nice!
com.github.tkashkin.gamehub --version shows the right branch now, even without -Dgit_branch. Not sure why, but good. :+1:
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.
@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.
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
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. :+1: 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...)
@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 https://github.com/tkashkin/GameHub/pull/172#issuecomment-453858894.
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
once libunity is in Factory rather than only in an OBS repository
libunitydependency 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 tagshould almost always be0.
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 -vdoesn't list full version and commit. You can pass-Dgit_branch=,-Dgit_commit=and-Dgit_commit_short=options tomeson. See #172 (comment).It also might be worth to use
--buildtype=debugoption 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. :+1: 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.
@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.
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.
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
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. :joy_cat:
@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.
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.
In reply to @lewellyn https://github.com/tkashkin/GameHub/issues/234#issuecomment-482815071
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
@tkashkin libunity9 is shown as Depends, so it is not optional. This is a no-go for Debian, since Unity is Ubuntu only. Thanks!
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...
Deb package doesn't work on Debian (I'm using Buster) since it still depends on libunity.
