Arch Linux User Repository

If you encounter any issues building a package from this PKGBUILD and/or running the resulting binaries:

DO NOT CONTACT UPSTREAM!!!

This PKGBUILD is not supported nor provided by upstream!

Only leave messages here on the AUR!

Seem to be getting an error right at the end of the build process and not really sure how to troubleshoot this :/

[100%] Linking C executable looking-glass-host

/usr/bin/ld: CMakeFiles/looking-glass-host.dir/src/app.c.o: in function `startThreads':

app.c:(.text.startThreads+0x34): undefined reference to `lgCreateTimer'

/usr/bin/ld: CMakeFiles/looking-glass-host.dir/src/app.c.o: in function `stopThreads':

app.c:(.text.stopThreads+0x61): undefined reference to `lgTimerDestroy' collect2: error: ld returned 1 exit status

make[2]: *** [CMakeFiles/looking-glass-host.dir/build.make:113: looking-glass-host] Error 1

make[1]: *** [CMakeFiles/Makefile2:258: CMakeFiles/looking-glass-host.dir/all] Error 2

make: *** [Makefile:150: all] Error 2

==> ERROR: A failure occurred in build(). Aborting...

As of https://github.com/gnif/PureSpice/commit/f78cdeb10f9da0e5d1e18594691bd0e38cfa80fd -O0 is not necessary anymore.

I have not used your patch (aside from the one in PR246). I've updated it according to the changes needed using the standard way that's written down for sub-module use within PKGBUILDs.

This way I'm not suddenly managing source downloads in the prepare function but keeping that where it should be in the makepkg build process.

Hey Omar007,

Looks like you've taken the originally posted patch, but I have since edited the commit to initialize submodules separately from the PKGBUILD, just to reduce noise and it's clunkiness: https://github.com/zer0def/PKGBUILDs/commit/11429d41d0c3e458af073f9a85bdd0ebc44377cc.patch

Patch that makes current PKGBUILD compilable: https://github.com/zer0def/PKGBUILDs/commit/e893481a7c4c19f310985d0a17d6d702b0287819.patch

0001-linux-host.patch is just a function definition and library linking fix for looking-glass-host-git, my guess is that gnif may have an alternate plan to approaching this

1) Stable was the wrong word. I meant versioned release. The versioned one is available at https://aur.archlinux.org/pkgbase/looking-glass/ (notice the lack of '-git'. For reference if you're interested; https://wiki.archlinux.org/index.php/VCS_package_guidelines)

2) I think I found the instructions you are referring to but they mention both the versioned and the -git variant, not just the -git variant. It's not explicit about it breaking though so I submitted an update that explicitly warns about the -git version and encourages users to switch to the versioned one instead; https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF#Getting_a_client

3) This is a combination of things; I can see this might happen with the previous instructions that aren't clear about the support status and how it may break but it'd also help to just not even investigate issues in the first place unless the user provides output that explicitly states a supported version. But obviously setting the minimum requirements for looking at/investigating a bug report is up to you.

Nice that there are continuous builds of the host application now! I'll add a post-install/post-upgrade script to notify the user about this. That's certainly an improvement I can make.

For the wiki I think it's better to just keep encouraging the users to just use the versioned one. Honestly, they are using the wiki for a reason so I think we should just keep that as simple as possible. Do you agree or should it be updated to tell them to grab the latest AppVeyor build if they use the -git variant as opposed to the versioned variant?

EDIT: I've pushed an update with an install script that reminds users every time they install/upgrade their locally build package. I'll leave the decision on what you want to do with the wiki instructions to you. For now I've left that at encouraging the versioned release instead.

1) There is no stable version of Looking Glass, period. The Alpha releases are just tagged points where a windows host executable has been released that is compatible with the client.

2) Fair enough, but it seems the arch community guide tells everyone to use this build package, and then they can't make it work as there is no windows host executable build for the bleeding edge version.

3) The issue caused by this package looks like a valid bug to be reported, as such the support forums are getting several reports a week that I end up wasting my time on diagnosing when it is caused by a failure to use the right version.

I am the gnif that owns the repo. I am not asking you to remove this package, I am asking that it be altered to pull the tagged version instead. At this time, A11 is the latest tag, A12 will be coming soon. This is the entire point of git tagging.

Edit: I have setup AppVeyor to do continuous builds of the windows host application, this should resolve this problem. I don't know much about arch but if you can somehow make that known when the package is built it would be much appreciated. See: https://ci.appveyor.com/project/gnif/lookingglass/build/artifacts

1) Using master/trunk/etc is the whole point of -vcs recipes (-git, -svn, ...). For stable/released versions, use the appropriate recipe; https://aur.archlinux.org/pkgbase/looking-glass/

2) The user needs to make the package himself and is completely aware of which version he/she is building (or should be anyway.. If they are not, I don't want to get anywhere near their system ever..). Furthermore, -vcs versions need explicit rebuilding by the user as well so this process is something that he/she has to repeat continuously.

3) Any problems with the PKGBUILD should be directed here, not at the devs. Problems with the software should be send to the devs according to their policies. So if they say they need certain info, provide said info. If they say they do not support or process bug reports for master builds, don't submit bugs for the master build!! (be it build manually or with this recipe)

All that said, assuming you are the gnif that owns the github repo, how many bogus reports are we talking about? Aside from that, removing this does not stop people from building master though, nor does it remove the recipe from user's systems if they already grabbed it, nor does it stop anyone from re-providing/uploading a recipe to build master. Hell, the chances that a -vcs version does not appear for any given non-vcs (where possible) is quite small. People are even providing -vcs versions for actual packages you can find in the Arch repositories.

Please stop this package from pulling the master build from git. The master build is NOT supported and often becomes incompatible with the host application. This is continuing to cause many bogus bug reports because this package has not followed the clear instructions to only use tagged releases.

At this time, the current alpha version with a working windows host executable is A11.

please add libconfig as a dependency.