For some reason the bug report did not include the screenshot of the Calf Plugin GUI. Here it is now

Have you reported this upstream? It's likely related to wxwidgets as your pkgbuild has "-Daudacity_use_wxwidgets=local" where as latest Arch does not.

Nope, I have not reported it upstream.
Why would I? Audacity does not have the problem.

The PKGBUILD supplied builds an Audacity where the GUI of plugins work.
How is upstream going to fix something that is working already? Why would they even care?

This bug report is to let the maintainer of the community build of Audacity know that there is a problem.

If the maintainer feels that the way that the package is being built is correct, and that the GUI's not working on it is a bug in Audacity itself, then it is the maintainer's responsibility to report it upstream. With a full report of why it's a bug, of course.

The developers are much more likely to listen to the maintainer of the community package than some random guy on the internet. This is of course assuming that the maintainer knows what they are doing and can put together a coherent bug report, which is a fair assumption, IMHO.

> Why would I?

Because unless it's an Arch packaging problem, Arch cannot help.

> then it is the maintainer's responsibility to report it upstream

Erm, no. Please reread the bug reporting guidelines [1].

[1] https://wiki.archlinux.org/title/Bug_reporting_guidelines#Upstream_or_Arch%3F

My point here is that it _is_ a packaging problem.
If I am wrong on this point, please explain how it's not a packaging problem.

The guidelines you so kindly provided even state that the packager should check functionality of the software being packaged.
;)

@evorster: Thanks for the report.

For future reference I'd recommend to tone down the passive-aggressiveness in your interaction here. It does not help your point across and it does not help in solving this issue either.
I believe the section of the wiki article provided by Toolybird is fairly clear on what is someone's "responsibility". As a reminder: Arch Linux is volunteer and community driven, which does not mean that users are entitled to my time or any action from my side.

With this out of the way and looking at the issue you describe:
After running audacity from a terminal and observing its output, it becomes clear that it is unable to load the shared object files provided by suil.

```
suil error: Failed to open module /libsuil_x11_in_gtk3.so (/libsuil_x11_in_gtk3.so: cannot open shared object file: No such file or directory)
```

This and especially the leading `/` is odd, as it implies that audacity has issues opening the required and existing file (and likely looks for it in the wrong location).
As we build against system libraries and do not download the internet during build, my conclusion would be that the build system of audacity is buggy and therefore unable to properly resolve the required shared object files when building against system suil.
Ergo this is an upstream bug, which means that this needs to be reported upstream to be fixed. Potentially there even is a fix for it already and this needs to be investigated.
If you have time for that, that would be very much appreciated!

Communication is definitely not my strong point, there are a few things that I thought does not need to be said, but looking at your response maybe it does.
1. I am not the maintainer of the community package for audacity, and have no stake in it.
2. Audacity runs fine on my system, and the plugins display their GUI.
When you consider the two points above, why would I spend any more of my time on this?

The bug report was purely to inform you that the community package of Audacity is not running properly.
The screenshots and example PKGBUILD was provided in an effort to be _helpful_

With information, you now have choices:
1. Do nothing. Community audacity stays broken until someone else takes an interest. Maybe some poor hapless user that can't fix their own stuff might be coerced into annoying upstream audacity for a fix. When you consider that Linux is a very small subset of Audacity's users, and of that subset only a fraction uses Arch, and of that subset only a fraction uses the plugins, and of that subset only a fraction wants the GUI... I don't see the Audacity developers spending any time on this... especially since a way exists that works around the issue.

2. Change the PKGBUILD of community audacity. With this option you get to close a bug report with RESOLVED, and maybe the other user of this package with plugins suddenly gets fancy-looking GUI's, and the overall quality of Arch goes up by the tiniest amount. You get to go on and do all the other things that keep you busy, quietly assured that you did a good job. Everybody's happy.

3. Report the issue upstream yourself. You have the biggest stake in Audacity working properly on Arch, as you volunteered to be the package maintainer. You also have the proper skill set and authority that goes with package maintainership in the Arch community, and having a working relationship with the developers of the package that you maintain is generally considered a good thing. It may be a little bit of an uphill battle, though. Some people like that sort of thing... but not me, personally. I tend to hack together something that works and then carry on with the more enjoyable activities that our short time on this planet offers.

> The bug report was purely to inform you that the community package of Audacity is not running properly.

I understand. Yet, when met with clear instructions your answers were and still are coming across as condescending.

> I don't see the Audacity developers spending any time on this...

This is conjecture, legitimizing your own actions of not reporting this upstream. To turn this around: Why would *I* spend time on writing a bug report if they are going to do nothing about this? This and most of the argumentation in your offered "choices" are providing a false balance trying to sway the reader towards choice 2.
I am not interested in your opinion about "my intentions". I am interested in finding the root cause of a technical issue and how to solve this for users :)

> especially since a way exists that works around the issue

Which is the vendored version of audacity that you provided in the AUR and I have had deleted [1] for being in conflict with the AUR rules of submission.
We do not "work around" an issue by vendoring libraries if a proper solution would e.g. mean to apply a patch to the build system.
On a personal level you are of course always free to build audacity in any way you like. This however is nothing that works for a Linux distribution.

> Change the PKGBUILD of community audacity.

No. We do not use upstream vendored libs, just because our current way of building inconveniences a user. There are reasons why we build against system libraries (see this Fedora wiki article [2] for a good overview).

> You have the biggest stake in Audacity working properly on Arch, as you volunteered to be the package maintainer.

Anyone can build audacity from source against system libraries and it would (very likely) exhibit this behavior. An appeal to authority has no merit in a bug report that is based on reproducible facts.

> Some people like that sort of thing... but not me, personally. I tend to hack together something that works and then carry on with the more enjoyable activities that our short time on this planet offers.

I'd rather you'd stop this passive-aggressive show. I'm not interested in your personal opinion about my or anyone's intentions.

[1] https://lists.archlinux.org/pipermail/aur-requests/2022-July/074984.html
[2] https://fedoraproject.org/wiki/Bundled_Libraries

Fair enough. Have fun, and good luck.

Small update to this issue.

After some investigation, it looks like calf is gtk2 only at this point, and suil does not support displaying gtk2 in a gtk3 application.
The developer of suil said in https://github.com/lv2/lv2/wiki#avoid-gui-frameworks: ""gtk2 + gtk3 cannot exist in the same memory-space, likewise Qt4 + Qt5. This means a gtk2 host cannot load plugins with a gtk3 GUI, nor can you load a Qt4 plugin at the same time as plugin using a Qt5 GUI."

So, your audacity build IS running properly, and it's calf that is using an incompatible toolkit. My apologies.

It's possible to build Audacity on gtk2, but that is a step backwards for anyone that is not actually using the Calf plugins.

Would you have any objections if I put in an audacity-gtk2 package in AUR?

The purpose of this would be to have an Audacity built against gtk2 that is compatible with calf plugins. Once calf updates their plugins away from using gtk2, then we can delete the package.

As such, I propose to actually use the vendor supplied wxwidgets 3.1.3, as the latest branch of audacity does not build against the system wxwidgets-gtk2 3.2.0-4, and when built against wxgtk-common-dev-314-opt, you need to run it with:
LD_LIBRARY_PATH=/opt/wxgtk-dev-314/lib audacity, and then the package would gain a dependency on wxgtk-common-dev-314-opt, which is worse than just using the vendor-supplied libraries.

It's not unheard of for packages to install their own versions of system libraries, steam does it in abandon, and I am sure there are other examples. Audacity installs the wxwidgets gtk2 version that it uses in it's own directories, and does not conflict with the system libraries at all.