Closed samtrek closed 1 year ago
I am now using submodules so I can share code across projects more easily. Please execute git submodule update --init
.
Thank you for your feedback, the copy of the plugin I am using is from the AUR (Arch User Repository) seems the maintainer has not been been seeing to the plugin for awhile, I had to do manual installation to update it.
I am the maintainer. Indeed, I did forgot adjust the PKGBUILD yesterday.
Oh, then it will be updated when you have the time to spare, thank you for the good work.
Should be working now. Feel free to leave a message if it does. If it does not, please leave a message anyway. ;)
Sorry to bother you once again, it can now be installed through the aur, however the issues encountered are as follows
rm: cannot remove '/home/$USER/.cache/paru/clone/purple-gowhatsapp-git/src/purple-gowhatsapp/build/src/go/go/pkg/mod/google.golang.org/protobuf@v1.30.0/LICENSE': Permission denied rm: cannot remove '/home/$USER/.cache/paru/clone/purple-gowhatsapp-git/src/purple-gowhatsapp/build/src/go/go/pkg/mod/google.golang.org/protobuf@v1.30.0/regenerate.bash': Permission denied
I can live with these errors, I have been using it like this for a while, but it will be nice if it can be looked into, once again thank you for your efforts.
Thank you for the information. On my test machine it works flawlessly with makepkg
. I do not know Arch (or paru for that matter) well enough to resolve this quickly. In case an Arch user could look into this, that would be nice.
This looks like the build issues I was seeing with DEB. Basically, anything in the golang build and cache directory is read-only. I don't know why it's like that, but it's like that every time.
it must be a golang setting at build time , maybe in cmake, but almsot certainly inside go.
Indeed, this is inside go and by design, says https://github.com/golang/go/issues/27161#issuecomment-433102849. Allegedly, one shall use go clean -modcache
for clean-up. I added an appropriate target clean-modcache
to CMakeLists.txt. However, there is no support for clean-up procedures in PKGBUILD. Feel free to re-open this issue in case that is changing. Until then, this is a "wontfix". I am not aware of cpack having clean-up procedure.
Late to the party, but I maintain the versioned PKGBUILD, the git submodule --init does not work, I am trying to build release versions, not git.
https://aur.archlinux.org/packages/purple-gowhatsapp-git should be identical with https://github.com/hoehermann/purple-gowhatsapp/blob/whatsmeow/PKGBUILD. Both check out the latest tagged version. I do not actually make use of the github releases page. At least not yet. There is some movement happening at #172. :)
From what I see at https://aur.archlinux.org/packages/purple-gowhatsapp, it is downloading the source archive. That will not support git submodules. Maybe you can download the file explicitly?
wget https://raw.githubusercontent.com/hoehermann/purple-cmake-template/master/purple-config.cmake -O submodules/purple-cmake/purple-config.cmake
Since I am using Ubuntu most of the time, I do not know the benefits of having two variants in the AUR. I never understood how the version information in the project, the PKGBULD and SRCINFO interact. Please note: Due to the static nature of go builds, it is necessary to re-build the plug-in to keep up with the WhatsApp version numbers. Users can get away with using old versions for quite some time, but there is a new one every other week! :o
Since you are familiar with AUR, can you tell me how to delete the outdated comments found at https://aur.archlinux.org/packages/purple-gowhatsapp-git?
nvm. I just used a static version of purple-config.cmake, that I just downloaded, and bundled with the PKGBUILD instead of linking. I think this is best, as this is a known good version, instead of linking to a dynamic github object. I will test this file every release, and if needed, import a new one.
Static version that compiles today, should compile tommorrow, with known good cmake file.
Disregard.
edit: benefits of two packages: One package is -git version. This pulls whatever is latest two is based on static releases. This is superior for downstream package management. You have known code, stable releases, and ability to reproduce bugs.
I have my own Arch repo, so I make a lot of static release versions. When possible, I use static releases. Better for quality and management reasons.
The error thrown is in this form, will like to know what to do going forward, I am on Archlinux 6.1.38-1-lts
CMake Error at CMakeLists.txt:6 (find_package): By not providing "FindPurple.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "Purple", but CMake did not find one.
Could not find a package configuration file provided by "Purple" with any of the following names:
Add the installation prefix of "Purple" to CMAKE_PREFIX_PATH or set "Purple_DIR" to a directory containing one of the above files. If "Purple" provides a separate development package or SDK, be sure it has been installed.