Package Details: openmw-git 0.48.0.r4764.g012d10703f-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 (Lone_Wolf)
Last Packager: bwrsandman
Votes: 30
Popularity: 0.048973
First Submitted: 2011-01-05 16:17 (UTC)
Last Updated: 2024-03-25 21:25 (UTC)

Pinned Comments

Lone_Wolf commented on 2022-06-17 10:07 (UTC)

openmw-git has been found to require a sizable amount of temporary space during building.

The available amount depends on system specifics so is different for all systems. In case build fails with "no space left on device" you may be bitten by this.

See https://bbs.archlinux.org/viewtopic.php?id=277304 for details and possible solutions.

bwrsandman commented on 2016-09-24 14:59 (UTC) (edited on 2018-11-22 17:28 (UTC) by bwrsandman)

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

« First ‹ Previous 1 2 3 4 5 6 7 8 .. 13 Next › Last »

Le_Limule commented on 2023-04-23 16:36 (UTC)

Argh! As i feared, there is a regression: now the Protective Guard mod doesn't work any more. Same thing on my Debian computer. The issue is described here:

https://gitlab.com/OpenMW/openmw/-/issues/7339#note_1363501476

Le_Limule commented on 2023-04-23 13:50 (UTC)

Thanks. I rebuild with a fresh $scrdir. It works. I imagine i have now a new version of the sources. I wanted to keep working with the "old" sources i had. It doesn't matter. I hope there is no regression. Thanks again.

Lone_Wolf commented on 2023-04-22 21:22 (UTC) (edited on 2023-04-22 21:23 (UTC) by Lone_Wolf)

Le_Limule, archlinux has had icu 72.2-2 in repos since nov 2022 and I have been running openmw-git against that icu version since then .

  • downgrade : no
  • symlink icu 71 libs to icu 72 : NO, very bad idea which will cause hard-to-troubleshoot breakage.

run a full pacman -Syu, then try again.

make sure to add --cleanbuild to the makepkg command so you'll start with a fresh $srcdir .

Jackleson commented on 2023-04-22 21:20 (UTC) (edited on 2023-04-22 21:56 (UTC) by Jackleson)

Le_Limule, I updated my system today (Manjaro so maybe its two week delayed) my icu is 72.1-2. linicuuc.so part of li32-icu is 72.1-2 as well. my current openmw-git install runs fine I will try updating it now too.

update: update went well and game runs fine.

Le_Limule commented on 2023-04-22 20:32 (UTC) (edited on 2023-04-22 20:33 (UTC) by Le_Limule)

I upgrade my system. Now i get "openmw: error while loading shared libraries: libicuuc.so.71: cannot open shared object file: No such file or directory" when openmw is launched. libicuuc, part of icu, is version 72 since my system update.

I rebuild openmw-git: same error. Then i rebuild openscenegraph-openmw-git, recastnavigation-openmw, and openmw-git: now the openmw-git rebuild fail at this stage: [ 66%] Linking CXX executable ../../openmw (undefined references with icu_72 and icu_71...)

Must i

  • downgrade icu 72 -> 71 ?

  • do some "icu 71" links to "icu 72" ?

  • other?...

Jackleson commented on 2023-04-20 20:33 (UTC) (edited on 2023-04-20 20:34 (UTC) by Jackleson)

Can .47 be removed or changed to .49? I know its just the name, but it is wrong.

txtsd commented on 2023-04-08 06:37 (UTC)

Just the number of commits is a good idea since upstream does not seem to care about consistent tag names. So just openmw-git r4538.ga41cbfb349-1 for example, with an epoch if there might be problems with vercmp.

Lone_Wolf commented on 2023-03-27 12:21 (UTC)

openmw devs only use tags in release branches and never in the development branch. llvm and mesa also work like this.

I am aware of 3 methods that are in use :

  • manually add the version as a static value in pkgver() , like my openscenegraph-openmw-git package.

  • get the version info from a file provided in the upstream sources. my llvm-minimal-git and mesa-minimal-git packages do this.

  • don't bother with versions, just use the number of commits since start of project

(add the commit hash in all cases)

Using tags meant for release branches is in my opinion wrong for packages building development trees, but this is bwrsandmans package and I'll follow whatever they decide.

bwrsandman commented on 2023-03-27 01:19 (UTC)

Not going to be basing the version here based on the CMake config. That's hyper specific and much more likely to fail than basing off of the tags.

I've said this before, the ideal thing to do is for upstream to be consistent with their tagging but even with that, it's making a mountain out of a mole hill.

Le_Limule commented on 2023-03-22 12:10 (UTC)

@Lone_Wolf: thanks, i go the right way now: it works.

« First ‹ Previous 1 2 3 4 5 6 7 8 .. 13 Next › Last »