meator
meator
Here is an example of this behavior: https://github.com/enkore/j4-dmenu-desktop/assets/67633081/d0bf86a3-9da9-428d-a1ac-cfb8ad20b20b User input is using arrays, a non-POSIX feature which isn't supported by `dash`. This is partly the reason the user specified shell...
This should be fixed in `develop` now. I am planning to make a r3.0 release in the foreseeable future which would include the fix.
To summarize, using system installed Catch2, `_GLIBCXX_DEBUG=1` and the sample code crashes.
Oh, thanks for the explanation. I'm dumb. Now that you've pointed it out, it makes a lot of sense that mixing `_GLIBCXX_DEBUG` and non-`_GLIBCXX_DEBUG` code will break havoc.
Services shouldn't be responsible for this; see https://github.com/AdnanHodzic/auto-cpufreq/pull/500#pullrequestreview-1891195465
It looks like this is related to https://github.com/valentjn/ltex-ls/issues/186#issuecomment-1427107389
When there is no [mention of "or later", it is GPL-3.0-only](https://www.gnu.org/licenses/identify-licenses-clearly.html) AFAIK. So the previous notice was valid and it was GPL-3.0-only. But the author changed his license making this...
Thank you for the explanation!
It looks like a tag for `v0.9.7` was made, but a GitHub release wasn't. Related to https://github.com/nicfit/eyeD3/issues/605 I will probably switch to the tagged release to fix this problem.
If `TryExec=zed` is failing because it tries to access `zed` instead of `Zed`, I don't think that removing `TryExec` altogether is a good solution. It should be changed to `Zed`...