Package Details: tmsu 0.6.1-1

Git Clone URL: https://aur.archlinux.org/tmsu.git (read-only)
Package Base: tmsu
Description: A tool for tagging your files and accessing them through a virtual filesystem.
Upstream URL: http://tmsu.org/
Licenses: GPL3
Provides: tmsu
Submitter: tmladek
Maintainer: MarcinWieczorek
Last Packager: MarcinWieczorek
Votes: 13
Popularity: 0.239562
First Submitted: 2015-08-29 19:21
Last Updated: 2017-01-24 16:08

Required by (0)

Sources (1)

Latest Comments

flarkis commented on 2017-07-09 20:57

Modifying the PATH variable is not the correct solution here. The issue is a poorly written Makefile. Neither of the tests have dependencies on the final compiled output, so running with jobs > 1 causes the tests to run in parallel with the compilation.

Additionally tests shouldn't be in the build command in the first place. That's what check is for. The user should have the option to skip failing tests if the outputs are generated properly.

So with all that being said I think the correct solution is to modify the PKGBUILD like

```
28c28,33
< make
---
> make dist
> }
>
> check() {
> cd "$srcdir/TMSU-$pkgver"
> make test
```

peperunas commented on 2017-06-15 08:55

Yep. CheezenOne is right. Just run make with the modified PATH env variable. Can the maintainer edit the PKGBUILD please?

CheezenOne commented on 2017-05-03 16:02

I could get the PKGBUILG compile the package after changing the make command to:
```
cd "$srcdir/TMSU-$pkgver"
PATH="$PATH:$(pwd)/bin" make -j1
```

My build was failing because the path to the `tmsu` executable was not known when the tests were executed.

oniony commented on 2017-03-29 22:55

Well, to investigate this further I just:

1. Uninstalled TMSU
2. Downloaded the PKGBUILD from here
3. Commented out the Go dependency from the PKGBUILD (as I have a version installed outside of Pacman)
4. Ran `makepkg` on the PKGBUILD.

This worked fine: the tests all ran successfully. I then ran `sudo pacman -U tmsu-0.6.1-1-i686.pkg.tar.gz` and installed it without any problem.

So I don't think there is, after all, any problem with either the PKGBUILD or the TMSU binary.

My earlier fears about the `run` script are unfounded: the build directory is not affected (it still builds to `bin` beneath the directory `makepkg` creates, so the relative path to the just-built TMSU is good).

So not sure why this is not working for some people.

oniony commented on 2017-03-29 13:03

@vok5, sure, I could look to introduce a `BUILD_DIR` variable. I would need to think about how the `run` script will be able to pick this up, especially as it's possible to run this script directly (without `make`).

vok5 commented on 2017-03-29 12:22

@oniony, thank you for having a look. I believe the `run` script shouldn't assume the build directory to be `bin`. It would fix the issue with this package and also make tmsu's tests more robusts. Perhaps, using an environment variable like BUILD_DIR, which could be overwritten would be a solution.

As for the PKGBUILD file, the build directory is changed by `makepkg` (https://wiki.archlinux.org/index.php/Creating_packages#build.28.29). Then, right before executing `make`, `cd "$srcdir/TMSU-$pkgver"` is executed to get inside the build directory of this package.

MarcinWieczorek commented on 2017-03-28 22:52

I'm not having any trouble building the package with current PKGBUILD. If you could please provide more logs that would be great. Somebody also try to add "${pkgdir}/usr/bin/" to PATH in order to conduct tests and try if it changes anything.

oniony commented on 2017-03-24 20:07

I've reviewed the code. The path is set in the `tests/run` script, which should mean the built version should take precedence over any pre-existing version you happen to have installed.

However the `run` script does assume a build directory of `bin`, so if the Arch package is building it elsewhere that could explain how it's not being picked up (and any pre-existing installation is used in its stead).

I've had a look at the PKGBUILD file but I cannot see anywhere the build directory is overriden, however.

MarcinWieczorek commented on 2017-03-24 11:21

Thank you for reaching out. That's nice to be visited by the upstream :p
I don't have a possibility of taking care of this, but I should have push access if you manage to fix this issue.

Marcin Wieczorek

oniony commented on 2017-03-24 11:16

TMSU author here. I'll take a look this evening. You might be right: it could be using the binary on the path rather than the one just built, which would not be ideal :)

All comments