I'm running Pop_OS 22.04 (which has pipewire audio) and audacity is hanging on launch (unless it is launch with sudo, which seems quite odd).
To try and debug the system, I'm trying to build audacity from github sources.
In the initial configuration phase of the build, I get the following messages
-- Fixing up ZLib mess...
-- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.11")
-- Looking for pa_jack.h
-- Looking for pa_jack.h - not found
-- Looking for pa_linux_alsa.h
-- Looking for pa_linux_alsa.h - not found
So, here is the thing I am confused about. I thought that pipewire was API compatible with pulse-audio. So shouldn't there be a version of the pa_*.h files to use with pipewire? If so, which Debian package do I need to install to get them?
The pa_ stands for PortAudio, not pulse-audio. The portaudio19-dev package had the required header files.
Related
I'm not using NixOS but I wrote a flake that I'm using to generate a dev shell to build a Rust project (this is essentially just the audio example from the Bevy repository). My issue is that I encounter the following error when attempting to run the project in the dev shell:
$ nix --extra-experimental-features nix-command --extra-experimental-features flakes develop
bash-4.4$ cargo run
Finished dev [unoptimized + debuginfo] target(s) in 6.62s
Running `target/debug/audio`
ALSA lib pcm_dmix.c:1075:(snd_pcm_dmix_open) unable to open slave
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: NoDevice', /home/a/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_audio
-0.5.0/src/audio_output.rs:22:67
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
bash-4.4
One of the dependencies of the project is the Bevy crate which requires ALSA, so I'm assuming the issue is because the ALSA package exposed by the dev shell is probably misconfigured. I use PipeWire on my actual system (I think it also uses ALSA as a backend) and I tried adding ALSA and PipeWire as one of the buildInputs for the flake, but I'm not sure how I'm supposed to configure these within the dev shell. According to this issue on the Bevy repository, the usual fix for this issue, at least for Arch-based distros, is to install the pipewire-alsa package. I'm not sure what the equivalent of doing that is in the context of a Nix dev shell is though, since there is no pipewire-alsa package in nixpkgs that I can add to my flake. So with that said, how should I go about configuring ALSA or PipeWire in the dev shell?
The following command used to work flawlessly:
C:\tools\apache-cxf-3.3.1\bin\wsdl2java -client -d generated foo.wsdl
It no longer works with the latest version of JDK - 12. I have downloaded the latest version of Apache CXF, and still get the same error:
-Djava.endorsed.dirs=C:\tools\apache-cxf-3.3.1\bin\..\lib\endorsed is not supported. Endorsed standards and standalone APIs
in modular form will be supported via the concept of upgradeable modules.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Could anyone offer a tip on how to remedy this?
I got the Apache CXF 3.3.1 wsdl2java utility to work with the latest OpenJDK 11 by doing 4 things:
Pull down this jar and place it into the {CXF_HOME}/lib directory: https://mvnrepository.com/artifact/javax.jws/jsr181-api/1.0-MR1
Pull down this jar and also place it in the {CXF_HOME}/lib directory: https://mvnrepository.com/artifact/javax.xml.ws/jaxws-api/2.3.1
In my case, since I'm running on a Mac, I vi'd the wsdl2java script and made sure these two jars are explicitly being set on the CXF classpath, by doing the following declaration within the script right before the execution of the java command:cxf_classpath=${cxf_classpath}:../lib/jaxws-api-2.3.1.jar:../lib/jsr181-api-1.0-MR1.jar
Lastly, I removed the '-Djava.endorsed.dirs="${cxf_home}/lib/endorsed"' parameter from the java command at the end of the script, since newer JDKs no longer support this argument, so my command now looks like this:$JAVA_HOME/bin/java -Xmx${JAVA_MAX_MEM} -cp "${cxf_classpath}" -Djava.util.logging.config.file=$log_config org.apache.cxf.tools.wsdlto.WSDLToJava "$#"
Now, using OpenJDK11, I'm able to point to an external WSDL file and successfully generate the client code I need to consume this SOAP service with the following command:
./wsdl2java -client -d src https://somewhere.com/service\?wsdl
Whether or not this all works yet is TBD in terms of being able to call and consume the SOAP service I'm coding against, but I've at least now overcome the Java9+ support issue with this tool specific to generating client code from a WSDL.
If your needs are different, I would at least remove the '-Djava.endorsed.dirs="${cxf_home}/lib/endorsed"' JVM parameter and start calling the wsd2java command with the parameters you need set and just start iteratively adding back in the missing libs it starts throwing java.lang.NoClassDefFoundError errors for.
Their FAQ specifically says starting in 3.3.x, Java 9+ will be supported but something clearly dropped the ball between the no-longer-supported hardcoded JVM arguments still being passed in the utility and the missing libraries to support the newer JDKs where these legacy libs have been removed.
Hope this helps someone out there unfortunate enough to ALSO still be programming against SOAP endpoints but trying to at least keep the client-side code you're writing up to date and taking advantage of the newer features of the modern JDK.
I’m getting strange error while building project in Xcode 9.4
Build system information - unexpected service error: The Xcode build system has crashed. Please close and reopen your workspace.
I tried Xcode quit and reopen but that didn’t worked. Any solution?
Please clear derived data folder (located at ~/Library/Developer/Xcode/DerivedData) and restart the Xcode project.
This error usually happens between Xcode major versions. Apple usually claim their new build system is ** times faster than their previous version. If you see this error(I see this on changing Xcode9 to Xcode10 beta), you can always change it to the legacy build system. Here is how you can do this:
Open 'workspace settings'( it is now changed to 'Project Settings' if you are using Xcode10 or later) in the File Menu
Change build system to 'legacy'
Update for Xcode 13.4.1:
I had this infamous bug today as well. I tried a lot including clean project, delete derived, restart max etc.
What did the fix finally is similar to the answer of kakaiikaka: I set the workspace settings to "Legacy Build System (Deprecated)" for both, the shared and per user workspace. I tried to build with this, but got an error because I had packages wich are not supported.
Restarted Xcode, then changed back the build system. Restarted Xcode again.
Now the crash doesn't happen any more.
Looks like something internal was spoilt and cycling the build system fixed it.
I moved a lot of files all at once between folders, including nested folders. This error started happening. Nothing I did in regards to cleaning, purging derived data, or undoing the move operation would help.
What I did to help was: restore the previous version of the project file from source control and then re-add all the applicable new files to it. It was project file related. Deleting user data inside the project container did not help in my case. So as long as you use source control and can rollback the .xcodeproj, this may be an option.
it happened to me when i changed build configuration names. After deleting Pods folder and Podfile.lock, and then runnnig "pod install" fixed the issue.
For Xcode 10.2 delete podfile, podfile.lock, xcworkspace, open terminal, cd directory of project, pod init, add pods you want to pod file, pod install, open xcworkspac. Everything will be indexing now and then you can build.
The simple directions found all over the internet for installing Core using OPAM no longer work. What is the new way to install and use Core?
I think I tracked the problem down to a message on the ocaml-core mailing list about renaming several dependencies https://groups.google.com/forum/#!topic/ocaml-core/Te6LTiNBO08.
Paired down, the widely published installation instructions amount to two steps after installing opam itself:
$ opam install core
$ cat >> ~/.ocamlinit <<EOF
#use "topfind";;
#thread;;
#camlp4o;;
#require "core.top";;
#require "core.syntax";;
EOF
Following these directions result in an error about the "sexprlib.syntax" package missing when using ocaml (or corebuild, utop, etc).
Failing directions can be found in this widely referenced ebook
https://github.com/realworldocaml/book/wiki/Installation-Instructions#setting-up-and-using-utop
and are reflected in directions here on Stackoverflow in questions such as:
Ocaml utop library paths, Core module
What is the new way to set up Core?
opam install core no longer seems to be sufficient since it does not pull in the new syntax packages. I am not sure if this is a dependency bug or not.
The recommended ocamlinit settings also seem wrong.
I found that the core 113.24.00 is defective and all the installation instructions on the net as of this writing are out of date.
Users must make the following corrective steps:
Remove all #require references to packages ending in .syntax from ~/.ocamlinit.
Make your own corebuild script without any references to syntax packages
as found at https://github.com/janestreet/core/blob/master/corebuild.
You may also remove the #camlp4o;; line from your .ocamlinit as this library is no longer required by Core.
I am attempting to run foswiki on OpenBSD. Things are installed and i am able to open "/bin/Configure" page of foswiki configuration screen. but the page reports few errors, complaining that following files are either not found or outdated and new versions are required.
The Files are : grep, rcs, ci, co,rlog, rcsdiff
I tried commands like "pkg_add -Uu" to upgrade packages installed, but it reports all packages are uptodate.
I also tried "pkg_add rcs" "pkg_add grep" etc but non works.
So my basic question is how to I update above files to their latest version required by foswiki.
Regards
While I’m not familiar with Foswiki, my first thought is your web server is chrooted, as this is the default on OpenBSD, and, as a result, Foswiki cannot find the files it needs. You can copy the files Foswiki needs into the chroot or run the web server without chroot, which is bad from a security perspective.
all programs mentioned are part of a base openbsd install and the above answer is correct. the openbsd documentation on chrooted apache has more info.
if you don't have to stick with foswiki you can try dokuwiki instead which has package support on openbsd and installs easily in very much the same way you tried already:
sudo pkg_add -U dokuwiki
hope the process is pretty much self-descriptive. in addition, the manpage for pkg_add is a good thing to read. good luck!