Arch Linux User Repository

I've updated the dependency and removed the Linux c-host for now. Unless it gets dropped completely, I will re-add it once it gets a fix.

@evelyn: I don't think there is much I can do about that. Based on my automated build reports the c-host has been broken for about 3 weeks now. From what I can tell there is no Linux platform implementation (time.c) for said lgCreateTimer/lgTimerDestroy functions upstream, only for the Windows platform. Hence the undefined reference error; only a header exists but no implementation. I've not had the time to dive deeper into this yet sadly.

@Netboy3: You are right. I did add it for the build (makedepends) but it seems I'd forgotten/neglected to also put it into the depends. I suspect you are the first to notice this since the change was made and it's been like this for quite a while now xD

I'm hoping to pick this up upcoming weekend, worst case the one after.

libxi should be a "depends" for the client. It provides a library that is linked against the looking-glass-client executable. Without this, if a user system doesn't have any other package using libxi and they decide to remove orphans, the client will break.

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