Adrian Schollmeyer

Any updates on this?

Well, from what the name suggests, `m_deviceListMutex` is responsible for handling access to `m_devices`, so passing the mutex on to the AlsaPCMDevice is not a good idea in the first...

Is it really a good idea to having to maintain two APIs? Also, most languages probably have a client library for MPD by now, so I don't see much benefit...

How about just using the [compatiblilty namespace](https://docs.pydantic.dev/latest/migration/#continue-using-pydantic-v1-features) for now? This should allow running bugwarrior with pydantic v2 while avoiding the need to upgrade to v2 features immediately.

Just got the same problem under Arch Linux when working with a C/C++ source tree: ``` Error: Connection is closed. at new ConnectionError (/home/adrian/.atom/packages/ide-clangd/node_modules/vscode-jsonrpc/lib/main.js:138:28) at throwIfClosedOrDisposed (/home/adrian/.atom/packages/ide-clangd/node_modules/vscode-jsonrpc/lib/main.js:613:19) at Object.sendNotification (/home/adrian/.atom/packages/ide-clangd/node_modules/vscode-jsonrpc/lib/main.js:667:13)...

Thank you for your contribution. I've used this to restructure the current ebuilds. Please have a look at PR #561 and see if it works on your machine. Thanks!

Seems like the CI pipeline is unable to build the package due to missing dependencies (fftw3f): https://app.circleci.com/pipelines/github/gentoo-audio/audio-overlay/2005/workflows/2eb55cf6-0305-46e0-bde4-ba46f1d70e1b/jobs/5914 Could you please have a look at the dependencies?

I'm not really a fan of symlinked ebuilds and putting if blocks in the live ebuild for every extra detail just makes the ebuild overly complicated. Hence, I'd prefer if...

Nice job! Unfortunately, the CI pipeline fails: > Did not find CMake 'cmake' > Found CMake: NO > Run-time dependency x11 found: NO (tried pkgconfig) > > meson.build:91:8: ERROR: Dependency...

Sorry, but I'm currently a very busy. I can't promise that I'll have a look at this until october. I hope that's okay!