You are not logged in.

#51 2013-06-13 15:52:32

kokoko3k
Member
Registered: 2008-11-14
Posts: 2,390

Re: Humble Bundle 8


Help me to improve ssh-rdp !
Retroarch User? Try my koko-aio shader !

Offline

#52 2013-06-13 16:04:32

HalosGhost
Forum Moderator
From: Twin Cities, MN
Registered: 2012-06-22
Posts: 2,089
Website

Re: Humble Bundle 8

ford prefect wrote:

versionformat ddmmyyyy is not good for updates. yyyymmdd works much better.
to implement this in your logic you could add a variable like _srcver and set it the other way around.
normal humble bundle games do not get updates, but this, i think, might get some fixes, so the version is likely to change.
thanks for considering.

I completely agree about the versioning standard, YYYYMMDD is certainly superior, but I really feel like adding a completely new variable just to switch around the date seems really odd. I can do it if that's what people would prefer, but I like to try and keep PKGBUILDs as small as possible.

All the best,

-HG

Edit: Adding lib32-{sdl,virtualgl} (I already had lib32-libpulse), still fails with the same error codes as before. But, if it works for a few people, I may just call it good for now; we'll see…

Last edited by HalosGhost (2013-06-13 16:06:45)

Offline

#53 2013-06-13 17:40:29

sas
Member
Registered: 2009-11-24
Posts: 155

Re: Humble Bundle 8

ford prefect wrote:

for me, playing was not possible w/o lib32-virtualgl ([...] maybe because of my optimus graphics?)

Yes, VirtualGL is used internally by Bumblebee (which provides the optirun tool for NVIDIA Optimus rendering). The Bumblebee wiki page (which you really should read if you're using it) tells you that you need to install lib32-virtualgl to play 32bit games with optirun on 64bit Arch...

It isn't needed otherwise though, so it shouldn't be a dependency in any games PKGBUILDs.

Packages depending on lib32-libgl should simply assume that the user has properly configured 32bit OpenGL rendering for his system...

my friend needed lib32-sdl

I doubt that. The game uses SDL2, which it supplies itself in the /opt/dearesther/bin/ directory - so lib32-sdl (which provides SDL 1.2) shouldn't be specified as a dependency either...
(Probably something else going on there with your friend's installation...)

HalosGhost wrote:

YYYYMMDD is certainly superior, but I really feel like adding a completely new variable just to switch around the date seems really odd.

Trying to keep PKGBUILDs short is certainly a commendable goal, but I think you're carrying it too far... Temporary variables don't bite, you know smile Avoiding them should not go so far as to conflict with other important goals such as PKGBUILD readability and utility.

Offline

#54 2013-06-13 17:48:25

HalosGhost
Forum Moderator
From: Twin Cities, MN
Registered: 2012-06-22
Posts: 2,089
Website

Re: Humble Bundle 8

sas wrote:

Trying to keep PKGBUILDs short is certainly a commendable goal, but I think you're carrying it too far... Temporary variables don't bite, you know smile Avoiding them should not go so far as to conflict with other important goals such as PKGBUILD readability and utility.

Haha, alright, fair enough. When next it seems progress has been made and it makes sense to post an updated PKGBUILD, I'll add a _date variable and use it for the pkgver big_smile

All the best,

-HG

Offline

#55 2013-06-15 16:46:23

ejona86
Member
Registered: 2011-04-22
Posts: 5

Re: Humble Bundle 8

sas wrote:

Your PKGBUILD works fine for me (ATI Catalyst, 64bit system).

That likely means it is an issue with the open source drivers. I think it may be the OpenGL version supported that may be lacking.

sas wrote:

To try and solve your problem, first make sure that 32bit OpenGL rendering actually works on your system.

For the record, 32bit OpenGL works great for me. Running with LIBGL_DEBUG=verbose didn't present any clues.

sas wrote:
ejona86 wrote:

Dear_Esther is a shell script.

Indeed. And since the PKGBUILD is creating its own launch script anyways, I'd bypass Dear_Esther and just use this in the launch script:

#!/usr/bin/sh
cd /opt/dearesther
exec ./dearesther_linux -game dearesther "$@"

Even that is unnecessary. Simply make a symlink to Dear_Esther in the PKGBUILD:

ln -s "/opt/${pkgname}/Dear_Esther" "${pkgdir}/usr/bin/${pkgname}"
sas wrote:

Also, consider moving instead of copying the files from $srcdir to $pkgdir in case of a huge data size like this (1.4G unextracted!).
It will make the installation go faster for people who have the temporary build directory mounted on a hard disk, and prevent out-of-memory problems for people who have it mounted in RAM (e.g. inside /tmp).

Better than moving is to make hard links so that you can use makepkg -R. cp -l and ln can both function in that regard. "cp -rl" can be very helpful.

HalosGhost wrote:
depends=('glu' 'libxi' 'gcc-libs')
[ "$CARCH" == 'x86_64' ] && depends+=('lib32-glu' 'lib32-libxi' 'lib32-gcc-libs')

This will cause the package to depend directly on glu, libxi, and gcc-libs on 64-bit. It would be better to just have it depend on the 32-bit versions.

HalosGhost wrote:

YYYYMMDD is certainly superior, but I really feel like adding a completely new variable just to switch around the date seems really odd

The versions must increase over time. If the new version appears to be less than the old version you have to increase epoch, and don't go about doing that for something like this. The Humble Bundle packages frequently need another variable to manage the binary version. Take a look at psychonauts, supermeatboy, and beathazardultra for just some quick examples.

Offline

#56 2013-06-15 18:46:45

HalosGhost
Forum Moderator
From: Twin Cities, MN
Registered: 2012-06-22
Posts: 2,089
Website

Re: Humble Bundle 8

ejona86 wrote:

Even that is unnecessary. Simply make a symlink to Dear_Esther in the PKGBUILD:

ln -s "/opt/${pkgname}/Dear_Esther" "${pkgdir}/usr/bin/${pkgname}"

That is a great idea. Consider it done.

Better than moving is to make hard links so that you can use makepkg -R. cp -l and ln can both function in that regard. "cp -rl" can be very helpful.

This is another very good idea. I'm looking into using cp's link option.

This will cause the package to depend directly on glu, libxi, and gcc-libs on 64-bit. It would be better to just have it depend on the 32-bit versions.

I had figured it wasn't a big deal since the lib32 versions depend on the non-lib32 versions anyway, but you are right, it makes sense to only have them directly depend on the lib32 versions.

The versions must increase over time. If the new version appears to be less than the old version you have to increase epoch, and don't go about doing that for something like this. The Humble Bundle packages frequently need another variable to manage the binary version. Take a look at psychonauts, supermeatboy, and beathazardultra for just some quick examples.

Yes, I know, and epochs can be a major pain since it's difficult to move away from them once they've started. Below is the updated PKGBUILD as it stands now:

# Maintainer: Sam Stuewe <halosghost at archlinux dot info>
_name=dearesther
pkgname="${_name}-hib"
pkgver=2013.06.08
_date=06082013
pkgrel=1
pkgdesc='An immersive 3D narrative exploration game (Humble Bundle version)'
url='http://dear-esther.com'
arch=('i686' 'x86_64')
license=('custom:commercial')
[ "$CARCH" == 'i686' ] && depends=('glu' 'libxi' 'gcc-libs' 'openal' 'fontconfig')
[ "$CARCH" == 'x86_64' ] && depends=('lib32-glu' 'lib32-libxi' 'lib32-gcc-libs' 'lib32-openal' 'lib32-fontconfig')
options=('!strip' '!upx')
PKGEXT='.pkg.tar'
DLAGENTS+=('hib::/usr/bin/echo "Could not find %u. Manually download it to \"$(pwd)\", or set up a hib:// DLAGENT in /etc/makepkg.conf."; exit 1')

_installer="${pkgname//hib/linux}-${_date}-bin"
source=("hib://${_installer}")
sha256sums=('4b3368e9cd83f371b6ea63814ce1ec5db733d5ef3229e3f78bdc530c268076a4')

package() {
   install -d "${pkgdir}/usr/bin/"
   install -d "${pkgdir}/opt/${_name}"

   ln -s "/opt/${_name}/Dear_Esther" "${pkgdir}/usr/bin/${_name}"

   cd data
   cp -al --no-preserve=ownership * "${pkgdir}/opt/${_name}"
   chmod +x "${pkgdir}/opt/${_name}/Dear_Esther"
}

That should functionally copy everything with a much more minimalist launcher (thanks to ejona86), use a more sensible version format and post dependencies correctly.

All the best,

-HG

Last edited by HalosGhost (2013-06-15 18:48:46)

Offline

#57 2013-06-15 22:29:49

ejona86
Member
Registered: 2011-04-22
Posts: 5

Re: Humble Bundle 8

Concerning the native dearesther's package name: I am all for renaming the current (crossover) package to dearesther-crossover and naming the native linux one to dearesther.

Also, YYYYMMDD is the standard Arch format for date-based versions. Things like pacman-mirrorlist, pambase, linux-firmware, archlinux-keyring, and ca-certificates all use that format.

Offline

#58 2013-07-05 17:28:03

C5OK5Y
Member
Registered: 2010-07-04
Posts: 48

Re: Humble Bundle 8

As the CodeWeavers port of Dear Esther in the AUR didn't work for me I looked into the PKGBUILD of the native version. I did some minor edits and and added a .desktop file. I'm willing to maintain the native version in the AUR. I'm just posting here to see if anyone has any objections. The code of the PKGBUILD:

# Contributor: Claudio Kozicky <claudiokozicky@gmail.com>
# Contributor: Sam Stuewe <halosghost at archlinux dot info>

pkgname=dearesther
pkgver=20130608
_date=06082013
pkgrel=1
pkgdesc="An immersive 3D narrative exploration game."
arch=('i686' 'x86_64')
url="http://dear-esther.com"
license=('custom')
[ $CARCH = "i686" ] &&\
    depends=('fontconfig' 'gcc-libs' 'openal')
[ $CARCH = "x86_64" ] &&\
    depends=('lib32-fontconfig' 'lib32-gcc-libs' 'lib32-openal')
options=(!strip) # space benefit negligible
source=(hib://$pkgname-linux-$_date-bin $pkgname.desktop)
md5sums=('951127a283c3caf2c76031c7611d431d'\
    'e496da3386582874db8b28155893719d')

DLAGENTS+=('hib::/usr/bin/echo "Could not find %u. Manually download it to \"$(pwd)\", or set up a hib:// DLAGENT in /etc/makepkg.conf."; exit 1')
PKGEXT='.pkg.tar'

package() {
    # data
    cd $srcdir
    install -d $pkgdir/opt/$pkgname
    cp -al --no-preserve=ownership data/* $pkgdir/opt/$pkgname
    chmod +x $pkgdir/opt/$pkgname/Dear_Esther # 744 -> 755

    # launcher
    install -d $pkgdir/usr/bin
    ln -s /opt/dearesther/Dear_Esther $pkgdir/usr/bin/$pkgname

    # desktop integration
    install -d $pkgdir/usr/share/pixmaps
    ln -s /opt/$pkgname/$pkgname.png $pkgdir/usr/share/pixmaps
    install -Dm644 $pkgname.desktop $pkgdir/usr/share/applications/$pkgname.desktop
}

The .desktop file:

[Desktop Entry]
Value=1.0
Type=Application
Name=Dear Esther
Comment=An immersive 3D narrative exploration game.
Categories=Game
Path=/usr/bin
Exec=dearesther
Icon=dearesther

I'd also like to share some opinions. The first is regarding naming the (native) package dearesther instead of dearesther-hib or dearesther-hb. As the bundles are now called Humble Budles instead of Humble Indie Bundles, I wouldn't use the -hib suffix any more. Additionally I'd be for including the -hb suffix in the package name only when it is evident that the Humble Bundle version of the source files is incompatible with another version of the source files available elsewhere. In this case the possibility of using the package name without the suffix is of also dependent on whether ejona86 is willing to rename the CodeWeavers port to dearesther-codeweavers or something else. Then I'd like to comment on some of the other changes which I made to the PKGBUILD. In the package version I opted for using the YYYYMMDD format because it is (i my eyes) more widely used that the version with the dots. I removed :commercial from license=() because the part after the colon is meant to be the name of the license (according to the wiki). I edited the dependencies according to namcap. I removed '!upx' from options=() because it is enabled by default in /etc/makepkg.conf. The checksum is taken directly from the Humble Bundle web site. Other than that I edited only the syntax and rearranged some things in accordance to /usr/share/pacman/PKGBUILD.proto.

Offline

#59 2013-07-05 17:40:48

HalosGhost
Forum Moderator
From: Twin Cities, MN
Registered: 2012-06-22
Posts: 2,089
Website

Re: Humble Bundle 8

C5OK5Y, some of your edits are fine, but others I'm really not a fan of (I really prefer sha256 over md5/sha1; despite the fact that upstream provides md5s). I'm fine with the naming scheme being just "dearesther," but as you agreed, that is really up to ejona86 at this point. Having YYYYMMDD is fine instead of using dot delimiters. The license issue is largely personal preference given that there isn't an installable license so far as I can find. You must quote all your variables. The .desktop looks alright to me,

As for maintainership, I'm still planning on putting this on the AUR shortly, I've just been working through some issues on my rig to actually get the package to work (though I think it appears functional for most people).

All the best,

-HG

Offline

#60 2013-07-05 18:31:22

C5OK5Y
Member
Registered: 2010-07-04
Posts: 48

Re: Humble Bundle 8

HalosGhost: Ops, your right about the quoting, I didn't realise that Bash handles spaces in variables differently than ZSH. But doesn't it make more sense to only quote variables which can possibly contain spaces - $srcdir and $pkgdir? And regarding the checksums, are you sure that using MD5 and SHA1 is such a security issue? I mean has anyone actually managed to make a file which not only has an identical checksum to another file but also managed to make the file work maliciously?

Offline

#61 2013-07-05 21:35:17

HalosGhost
Forum Moderator
From: Twin Cities, MN
Registered: 2012-06-22
Posts: 2,089
Website

Re: Humble Bundle 8

The expansion of the variables is part of it, but it is general good practice to quote your variables. As for the checksums, it's not even really a security thing for me; it's a matter of principle. I'd like for MD5 and SHA1 to disappear from use; so I don't write PKGBUILDs that use them.

All the best,

-HG

Offline

#62 2013-07-05 22:41:27

ejona86
Member
Registered: 2011-04-22
Posts: 5

Re: Humble Bundle 8

C5OK5Y wrote:

I'm willing to maintain the native version in the AUR. I'm just posting here to see if anyone has any objections.

I'm fine with that. I would have done it myself a while back, but the native version doesn't work with the open source drivers yet from what I've seen (I assume you are using proprietary ATI or NVIDIA drivers).

C5OK5Y wrote:
md5sums=('951127a283c3caf2c76031c7611d431d'\
    'e496da3386582874db8b28155893719d')

No need for the trailing backslash. I think same for after the &&. Doesn't matter too much though.

C5OK5Y wrote:
    cp -al --no-preserve=ownership data/* $pkgdir/opt/$pkgname

I don't think the --no-preserve actually does anything because of the -l. Hard linked files share the same inode and permissions are stored in the inode, so the hard linked files are forced to have the same permissions (which is a downfall of using cp -l in a PKGBUILD, but it is soo much faster).

C5OK5Y wrote:

The first is regarding naming the (native) package dearesther instead of dearesther-hib or dearesther-hb. ... Additionally I'd be for including the -hb suffix in the package name only when it is evident that the Humble Bundle version of the source files is incompatible with another version of the source files available elsewhere.

I see no issue with that. Yes, I have only liked seeing -hib versions when 1) the download itself is different or 2) the version of the binary available is different. Those don't seem to be an issue here.

C5OK5Y wrote:

As the bundles are now called Humble Budles instead of Humble Indie Bundles, I wouldn't use the -hib suffix any more.

I continue to use hib because everyone thinks of them as the HIB, and because there are many packages already using hib; changing it at this point serves little purpose and only adds confusion. If you see hib, you know what it is talking about, but the same is not true for hb. That is why I chose hib:// for the scheme instead of hb://, because it wouldn't be obvious otherwise. -hib is short and unique and is already in use. Most people don't even think about the fact that it is HB and not HIB.

C5OK5Y wrote:

In this case the possibility of using the package name without the suffix is of also dependent on whether ejona86 is willing to rename the CodeWeavers port to dearesther-codeweavers or something else.

I'm game for that. Honestly, I wanted to replace the CodeWeavers version with the native version, but it seems we have to have both for the open source drivers. Nobody has gotten dearesther to work with open source drivers, right?

C5OK5Y wrote:

I edited the dependencies according to namcap.

Namcap is a great tool, but be wary that it is very wrong sometimes. I use namcap, ldd, and other more invasive measures to try to get dependencies right. If something namcap says doesn't make sense, it may just be namcap.

C5OK5Y wrote:

I removed '!upx' from options=() because it is enabled by default in /etc/makepkg.conf.

That isn't a great reason to do so. The question is: does the package work with upx enabled? If so, then leaving it out of options is good. If it doesn't work with upx, then you need the !upx. That said, I think it may work with upx, and strip for that matter. Since upx and strip modify the binaries, it could be understandable to disable them so that the installed binaries are identical as those provided in the download.

C5OK5Y wrote:

The checksum is taken directly from the Humble Bundle web site.

That's what I've been doing as well. As long as there is a checksum available from the "official" source I have been using that, whatever it happens to be. If there isn't one available, then I generate my own SHA256. If people don't like the security concerns and you feel like addressing them, then I would favor having both md5sums and sha256sums. Using the same checksum as available elsewhere can actually make it easier to find binaries if something happens to the download source in the future.

HalosGhost wrote:

You must quote all your variables

Bah. This is personal preference. I do quote almost all of my variables' assignment and usage, but that isn't something you have to do as well. Please quote things that may contains spaces (like $pkgdir), but for things you know don't contain spaces (like pkgname) it it up to you.

As another comment, has anyone tried using system libraries instead of the binary ones provided?

Offline

#63 2013-07-07 09:36:02

C5OK5Y
Member
Registered: 2010-07-04
Posts: 48

Re: Humble Bundle 8

ejona86 wrote:

I continue to use hib because everyone thinks of them as the HIB, and because there are many packages already using hib; changing it at this point serves little purpose and only adds confusion. If you see hib, you know what it is talking about, but the same is not true for hb. That is why I chose hib:// for the scheme instead of hb://, because it wouldn't be obvious otherwise. -hib is short and unique and is already in use. Most people don't even think about the fact that it is HB and not HIB.

Nice thinking.

ejona86 wrote:

I'm game for that. Honestly, I wanted to replace the CodeWeavers version with the native version, but it seems we have to have both for the open source drivers. Nobody has gotten dearesther to work with open source drivers, right?

I indeed am using the non-free drivers.

ejona86 wrote:

That isn't a great reason to do so. The question is: does the package work with upx enabled? If so, then leaving it out of options is good. If it doesn't work with upx, then you need the !upx. That said, I think it may work with upx, and strip for that matter. Since upx and strip modify the binaries, it could be understandable to disable them so that the installed binaries are identical as those provided in the download.

I haven't thought of that, thanks for explaining it.

ejona86 wrote:

As another comment, has anyone tried using system libraries instead of the binary ones provided?

The only library which looks replaceable is the SDL2 one. Unfortunately the game uses a slightly differently named version of the library than the one which is provided by the SDL2 packages in the AUR.

Offline

#64 2013-07-16 20:38:38

fettouhi
Member
Registered: 2007-05-07
Posts: 745

Re: Humble Bundle 8

Has anyone tried to pay Dear Esther 8native version) with a gamepad. For me the right stick is inverted, e.g. horizontal and vertical are switched meaning that if I turn right or left on the stick i look up and down.

Offline

#65 2013-07-30 13:54:03

sas
Member
Registered: 2009-11-24
Posts: 155

Re: Humble Bundle 8

ejona86 wrote:
C5OK5Y wrote:

As the bundles are now called Humble Budles instead of Humble Indie Bundles, I wouldn't use the -hib suffix any more.

I continue to use hib because everyone thinks of them as the HIB, and because there are many packages already using hib; changing it at this point serves little purpose and only adds confusion. If you see hib, you know what it is talking about, but the same is not true for hb. That is why I chose hib:// for the scheme instead of hb://, because it wouldn't be obvious otherwise. -hib is short and unique and is already in use. Most people don't even think about the fact that it is HB and not HIB.

+1 for continuing to use the "hib" label (for both package name suffix and protocol scheme).

The most semantically correct label would actually be "humble", because there's also the Humble Weekly Sales and the Humble Store in addition to the Humble Bundles - all of which share the same infrastructure (so if e.g. a game is available from both a Humble Bundle and through the Humble Store, it will be the exact same game archive and the same AUR package can be used).

However, "hib" has the benefit of being both short and memorable, and it is already in widespread use in the AUR - so lets stick with it.

ejona86 wrote:
C5OK5Y wrote:

I removed '!upx' from options=() because it is enabled by default in /etc/makepkg.conf.

That isn't a great reason to do so. The question is: does the package work with upx enabled?

My experience is that HIB packages (or at least some of them, in some cases) tend to break when upx is enabled, thus it should be explicitly disabled in the PKGBUILD (so that nothing will break for users who have turned in on in /etc/makepkg.conf).

I tend to disable strip too for HIB packages - leaving it turned on doesn't break anything, but it significantly slows down package installation for no real benefit (as the upstream binaries will already be optimized for release).

ejona86 wrote:

I would favor having both md5sums and sha256sums.

Then makepkg will check them both (I think), needlessly slowing down package installation.

Why not just use md5, if that is what upstream provides?
I really don't think theres a need for paranoid security measures here. We're not running an online bank, we're providing automated download+install scripts for convenience (absent which most users would manually download+install the software without any checksum'ing at all). The actual downloading of the Humble Bundle games will happen through HTTPS anyways, that's where your security comes from - the additional checksum in the PKGBUILD should just be considered as protection against download errors and user mistakes.

Offline

Board footer

Powered by FluxBB