Package Details: openmw-git 0.46.0.r1477.gdc82cb61f-1

Git Clone URL: https://aur.archlinux.org/openmw-git.git (read-only, click to copy)
Package Base: openmw-git
Description: An open-source engine reimplementation for the role-playing game Morrowind.
Upstream URL: http://www.openmw.org
Licenses: custom, GPL3, MIT
Conflicts: openmw
Provides: openmw
Submitter: None
Maintainer: bwrsandman
Last Packager: bwrsandman
Votes: 28
Popularity: 0.013445
First Submitted: 2011-01-05 16:17
Last Updated: 2021-01-06 15:16

Pinned Comments

bwrsandman commented on 2016-09-24 14:59

Please refrain from flagging the git version as out date when a new release comes out. The git aur packages update their version on install time based on the tags of the git repo.

Keep in mind that this is a VCS package and it is meant to be in line with the latest master which might not always work. It is not meant to follow the release pattern in any particularly smart way and assumes that upstream maintains their tags consistently.

For the newest release, the correct page is https://www.archlinux.org/packages/?q=openmw

Latest Comments

1 2 3 4 5 6 Next › Last »

txtsd commented on 2021-01-06 09:29

Also, they've recommended we switch to gitlab as the source since github is just a read-only mirror.

EDIT: from psi29a on discord:

gitlab is the 'truth', github is the mirror.
We've trying to deprecate/remove github for awhile now.
So all package maintainers should be using gitlab.
Anyway, git describe only shows annotated tags
it seems that we only had one annotated tag, and that was 0.43
debian doesn't use git describe
it just grabs tags and sorts
I believe that archlinux shouldn't rely on git describe for ground truth of latest release.
btw, how we develop... before we release, we branch from master... so for example, for 0.46 we branched... and continued polishing that branch.
That way we can continue developing on master towards 0.47 while 0.46 matures.
Since git describe only shows tags that can be reached via master...
it shouldn't be showing anything
0.43 is a fluke

txtsd commented on 2021-01-06 08:35

@bwrsandman Use this as the pkgver() so we can finally have the correct git tag.

pkgver() {
  cd "${srcdir}/${pkgname%-git}"
  _tag="$(git describe --tags $(git rev-list --tags --max-count=1) | sed 's/openmw-//')"
  _numcommits="$(git rev-list  `git rev-list --tags --no-walk --max-count=1`..HEAD --count)"
  _hash="$(git rev-parse --short HEAD)"
  printf "%s.%s.g%s" "$_tag" "$_numcommits" "$_hash"
}

EDIT: You may stick an r before the number of commits to maintain monotonicity per the wiki

Lone_Wolf commented on 2020-12-28 22:41

Since https://gitlab.com/OpenMW/openmw/-/commit/18ef32ca82bd9c3cfcdc9f420131e4697ee054c9 openmw trunk requires bullet built with double precision.

Atm my bullet-multithreaded package is the only one that provides that. I have uploaded a copy of my personal openmw trunk package to https://aur.archlinux.org/packages/openmw-mt-git .

bwrsandman, please check openmw-mt-git and adjust your pkgbuild . Once that has been done I'll submit a deletion request for openmw-mt-git .

Lone_Wolf commented on 2020-10-20 12:07

Recently openmw master gained support for async physiscs, see https://forum.openmw.org/viewtopic.php?f=8&t=7148 for some background info.

To use this you need bullet with multihreaded support. Repo package doesn't provide that.

Use my new aur package https://aur.archlinux.org/pkgbase/bullet-multithreaded/ and rebuild openmw-git against it.

Lone_Wolf commented on 2020-10-14 21:52

I've sent you my PKGBUILD through email.

bwrsandman commented on 2020-10-13 16:26

@Lone_Wolf I am still maintaining the package. If you have improvements to the PKGBUILD that I should be integrating, let me know.

In general this is a very simple package to maintain and requires little logic since most of the packaging logic is done by cmake. The biggest issue I have is that the devs have stopped branching off of release tags since 0.43 which makes it impossible to deduce the correct version automatically.

Lone_Wolf commented on 2020-10-13 10:11

bwrsandman, are you still maintaining / using this ?

I have been using my own PKGBUILD for master a few months now and do play openmw using it.

weedfreak commented on 2019-11-19 14:48

Fails to build after recent boost update.

Errors like Boost_INCLUDE_DIR used as include directory in directory /tmp/yaourt-tmp-****/aur-openmw-git/src/openmw repeated several dozen times, apparently for every file in the build, and then

-- Configuring incomplete, errors occurred!

I tried adding -DBoost_NO_BOOST_CMAKE=ON to the build instructions, this works for some other projects but not openmw.

Rulatir commented on 2018-11-22 17:31

OK, I just rebuilt after hardcoding #branch=openmw-45 (which is what I really wanted, I didn't want the master branch) and the package built as openmw-git-0.43.0.1680.g03437b712-1-x86_64.pkg.tar.xz. However the 03437b712... commit is indeed the one at the top of the openmw-45 branch as of right now, so I am satisfied with your explanation.

bwrsandman commented on 2018-11-22 17:17

TLDR: The package still rebuilds latest master as it is intended to, which is much more up to date than release 0.44. Error is due to the fact that the 0.44 tag was never merged into master and the standard way of determining versions is broken for this version only.

@Rulatir if you're looking for the 0.44 release please refer to the community version [1]

This package (openmw-git) does not guarentee to be inline with the latest release (last updated on June 20th).

It does, however guarantee to be inline with the latest master of the git repo, which as of writing this is the case (4098a7be1dac0f674171864e78ee1ab10a8d24ce Wed Nov 21 20:24:11 2018 +0100).

The reason why building it gives a misleading version number is the command in pkgver(): git describe --always

The way git describe works is by looking for the latest tag on the branch (master), taking that and giving the number of commits since that tag and a shortref.

The reason why this release is showing up as 0.43 right now is that the folks at openmw never merged the 0.44 tag into master.

Now, I could go against the AUR packaging standards[2] and hard code 0.44 in pkgver(), but I think we can agree that this would cause more issues down the line such as when 0.45 is released. Not to mention this sort of package update forces a half hour to multi hour rebuild for all users using aur helpers.

VCS packages, unfortunately, are not an exact science and they require upstream to do things consistently.

[1] https://www.archlinux.org/packages/community/x86_64/openmw/

[2] https://wiki.archlinux.org/index.php/VCS_package_guidelines#The_pkgver()_function