roc-toolkit
roc-toolkit copied to clipboard
roc-streaming
Provide PKGBUILD for Arch Linux
Since I encountered the same issues on Arch like described in this issue (add pthread flag) and furthermore needed to reinstall python on a second machine running Arch too (missing scons module [add dependency?]), I wanted to ask if it would be possible to create a PKGBUILD which handles the compilation for us? Obviously lots of users would profit by just running yay or whatever package manager they're using and this project would be noticed by a wider audience.
I'm unexperienced when it comes to compilation and not sure if I could maintain such PKGBUILD. I already looked into it and at how to create such file, but I probably couldn't fix compilation errors other users could encounter.
Just for reference your Arch build instructions.
Hi, sorry for late reply!
Creating PKGBUILD (as well as packaging for other distros) would be appreciated. For that we'd need someone who uses Roc on Arch and wishes to maintain the PKGBUILD.
Personally I don't use Arch, but if you or someone else would like to become a package maintainer, I'd be happy to help in any way.
I encountered the same issues on Arch like described in this issue (add pthread flag)
Hm, last time I wasn't able to reproduce it. I'll try once more in archlinux docker container.
and furthermore needed to reinstall python on a second machine running Arch too (missing scons module [add dependency?])
Could you elaborate? What error did you encounter and what dependency are you talking about?
Hm, last time I wasn't able to reproduce it. I'll try once more in archlinux docker container.
No, I can't reproduce the issue. Could you post your build commands and logs when the error ocurres?
Hi @gavv,
I would like to use Roc for longer, if I find a way to optimize the latency and don't have to restart pulseaudio on my client all the time. (need to debug what is the cause and maybe open a new issue) That said, I already read into PKGBUILD guidelines. I'm looking into it later and trying to create a working file and report back.
Depending the build errors with missing pthread flags I got this cmd error log and this build.log. Like described in the linked issue this error can be fixed by adding the pthread flags. This error occured on 2 installs of Manjaro Architect (one in headless mode) and was reproducable now with a freshly downloaded git-clone.
Edit: I used the linked build instructions from your doc page.
Edit2: The altered file is roc/scripts/3rdparty.py at line 490
Edit3: Wrong line number
Depending other dependencies, I can't reproduce anymore errors.
need to debug what is the cause and maybe open a new issue
Would be great!
Depending the build errors with missing pthread flags I got this cmd error log and this build.log.
Thanks, I'll take a look into it.
@gavv I already created a PKGBUILD with a patch for pthread flag, but I still need to rewrite it so it just downloads the latest release.
Maybe you can help me: Your build instructions download pulseaudio, but with PKGBUILD's I'm just putting pulseaudio as dependency and for most users pulseaudio shouldn't get downloaded (again) this way. So my problem now is that in your docs you provide a parameter --with-pulseaudio=<path>, but I don't know how to reference the path (/lib/pulseaudio) correctly, since the building environment is part of a fakeroot. I already asked some people on Arch IRC Channels, but they couldn't provide me a solution either.
Edit: Somewhere the path seems to be overwritten and I'm not sure if I need all the source files of pulseaudio, to build modules for it. So, if I use the mentioned path it gets extended to /lib/pulseaudio/src/.libs/libpulsecore-*.so and this way points to a non-existing directory. (I'm still not sure how this all works together with chroot, but I could maybe create hardlinks)
Edit2: Found the file (SConstruct) and could modify it, but I'm missing the config.h file (log) for pulseaudio I think. So it seems to me I can only build from existing pulseaudio if there are complete source files and I can't find the needed source files on my system. (if they're not downloaded by scons)
Regarding -pthread error. Thanks for detailed clarifications.
It seems that -pthread option is handled by libtool and it decides whether it is needed / supported on the current platform. It seems that on some platforms, it fails to add it. Other people report similar problems too: https://github.com/kevinkreiser/prime_server/issues/41
I've pushed a patch to develop (fd31def45268b18b6d24fe68bc84357c36d816a4) that adds -pthread when we're using a GNU-compatible toolchain. Could you please check whether it fixes the problem for you?
Regarding PulseAudio.
Unfortunately, PulseAudio doesn't provide an official API and infrastructure for external (out-of-tree) modules. So nominally it is extensible by modules, but all modules have to be part of the PulseAudio repository.
People tend to create out-of-tree modules from time to time (for their own risk), but building such modules would require fully built PulseAudio source tree. The config.h and other paths you mentioned are part of the PulseAudio source tree, but they're not installed on the system after building the sources.
When you're using --build-3rdparty=pulseaudio, Roc builds and uses the full PulseAudio source tree. When you're using --with-pulseaudio=DIR, you should download and build it by yourself.
Does it sucks? Yes. The proper solution would be to move our PulseAudio modules to upstream. I've plans to do it and even discussed it with upstream already, but there is still quite a lot of work to be done. As usual, any help is appreciated. If no one helps earlier, I think I'll look into it after next 4-5 minor releases of Roc, after finishing more important features.
Small note: if you're OK with building PulseAudio by Roc, but just want to prevent Roc from downloading anything, you can put the PulseAudio tarball into the vendor directory and --build-3rdparty will automatically use it. That directory is a sub-module and it already contains some tarballs.
@gavv Thanks a lot, that clarified a lot of my questions. I still didn't uploaded a PKGBUILD since I was busy myself and unsure if I should create a dev-version or a release-based version. For now I think it would be more appropriate to go for releases only and patch the pthread part for the latest release until your implementation is part of a new release. I will report back when I finished and tested the PKGBUILD.
I'm planning to release 0.1.5 in a few days, which will include the pthread fix.
Meanwhile, could you please check that the fresh develop fixes the pthread issue for you? (without patching 3rdparty.py)
UPD: The fix was not complete, I've just force-pushed a new one to develop.
UPD2: force-pushed once more.
@gavv I'm still getting errors: https://gist.github.com/Pandiora/70b2e52385b5112bd5edd816318fbe95
Strange, the current code should add either -pthread or -lpthread, depending on whether we're using a GNU toolchain. And in your log there is neither of them.
What commit are you using? Did you run something like:
git fetch origin
git checkout develop
git reset --hard origin/develop
or did a fresh clone?
@gavv Okay, sorry, my mistake. It were a fresh clone, but I tried to use the cpputest from AUR, which didn't worked like I expected. It now seems to add the flags correctly, when I use the cpputest build by scons.
Edit: just followed the building instructions from here.
I've tagged the 0.1.5 release: https://github.com/roc-project/roc/releases/tag/v0.1.5
Alright, thank you, I will alter and add the PKGBUILD when I've some free time.
Well, sorry for the late reply, didn't looked at Github for quite some time. I almost finished a script for the package and did a lot of testing, but gave up in between, since Arch-Chat is helpful in a way, I can't do or do not understand what they're asking for. No promise, but I try to look into it again, I still got the install-script lying around on my ssd.
Edit: Holy moly, this project exploded in just a few months! Seems like this tool could get a standard in the future if it gets well polished and easy to set up. ;)
In case this project is still active, I'd be interested to package it for the official repositories on Arch Linux, given that we could extend pipewire's functionality with it.
