Hello together,
when will come the current version 3.0 from audacity in the repos?
pamac shows me only the version
Thanks and regards
audacity package is inherited from arch linux … Dave will, probably, take care of it soon.
3 Likes
Thank you very much for this info @bogdancovaciu
regards
philm
22 May 2021 08:24
4
Well, it depends. It was flagged out-of-date on 2020-06-27 …
AUR (en) - audacity-git Arch Linux - audacity 1:2.4.1-4 (x86_64)
EDIT: Corrected link
But we are talking about an official package here, isn’t it? Also usually AUR’s git packages can’t be out-of-date by definition…
1 Like
moson
22 May 2021 09:09
6
Actually it is the official package that is flagged out of date since 2020.
I guess with the link Phil meant to say that there is a git package in the AUR in case you’d want to install the latest version…
1 Like
Yes, I would prefer audacity as an official package. I try to install V3.02 from AUR.
Thanks for your support
regards
Ok. That’s make more sense
I tried to install audacity-wxgtk2 3.0.2-1 from AUR with pamac, but the installation dosent work.
Now I installed " audacity-alien 3.0.2-1 " from AUR with pamac and it works fine:
regards
Lolix
22 May 2021 09:35
10
There are several problems with packaging Audacity
opened 04:44PM - 21 Jul 20 UTC
Arch Linux
bug-distros
**Describe the bug**
To quote the [2.4.2 release notes](https://www.audacitytea… m.org/audacity-2-4-2-released/):
> If you’re using Audacity 2.4.2 on Linux, do use the right wxWidgets library. We’ve in the past had a lot of reports of problems on Linux that turned out in the end to be because some distributions were using system wxWidgets (3.0.0) with Audacity.
When considering the aforementioned quote in the context of the [build instructions for Linux in regards to wxwidgets in `linux/build.txt`](https://github.com/audacity/audacity/blob/16d52f63a4183bba77ef7305d14622958dc0d1d5/linux/build.txt#L37-L65) or [in the wiki](https://wiki.audacityteam.org/wiki/Building_On_Linux#Instructions) it becomes clear, that these requirements can never be met on Linux distributions due to the way that source tarballs of audacity are offered to its consumers, how the build system for audacity works and foremost due to the custom wxwidgets version in use.
In the reproducer section I have highlighted the reasons why Linux distributions will not build against your custom version of wxwidgets (rendering Audacity broken or at best unstable across the board).
Even if a distribution such as Suse Tumbleweed [has the resources to spend on building the development version of wxwidgets](https://build.opensuse.org/package/show/openSUSE:Factory/wxWidgets-3_2-nostl) (i.e. currently 3.1.3) they will *not* build Audacity against your custom patched version as this causes loads of pain:
This is either to patch your custom version of wxwidgets to be built and linked statically every time - and given the recent unannounced changes with the build system (#595) I deem such an endeavor rather time consuming - or to provide a custom package of your custom development version of wxwidgets to be linked dynamically - which will introduce conflicts with (future) existing packages of wxwidgets in that specific version. Both are very unlikely to happen as this requires a lot of time to be spend on just one package (Audacity is the only consumer of its custom wxwidgets version).
Without working on this angle, I don't see how problems such as #538 (I guess there are many more judging from the release notes) can be prevented in the future and personally, as a distribution packager I don't see myself in a position where I am obligated (or able) to a) fix any issues resulting from this and b) provide Audacity as a package if the workload due to distribution tickets related to the aforementioned issues increase unreasonably.
I would be interested to hear the developer's ideas in regards to reproducibility of the current approach in a packaging context, the possibility around linking statically (although that will not satisfy many distributions) by providing encompassing source tarballs and what drove the decision making process in regards to patching the development version of wxwidgets.
**To Reproduce**
Steps to reproduce the behavior:
1. Download tarball for Audacity 2.4.2
2. Build against stable wxwidgets (i.e. currently 3.0.5)
3. Have unstable package
Alternatively:
1. Download tarball for Audacity 2.4.2
2. Clone https://github.com/audacity/wxWidgets
3. Build an unreproducible version of a custom wxwidgets from [HEAD of whatever is the current default branch](https://github.com/audacity/wxWidgets/commits/audacity-fixes-3.1.3) (ouch!)
4. Install an unreproducible version of a custom wxwidgets into the build environment and build audacity against it (???)
5. Package Audacity with a custom (dynamically linked) wxwidgets version (???)
Alter-alternatively:
1. Clone https://github.com/audacity/wxWidgets
2. Build an unreproducible version of a custom wxwidgets from [HEAD of whatever is the current default branch](https://github.com/audacity/wxWidgets/commits/audacity-fixes-3.1.3) (ouch!)
3. Package an unreproducible version of a custom wxwidgets development release, that will only be used for Audacity (ouch!)
4. Install unreproducible package of a custom wxwidgets development release (which will then conflict with a future wxwidgets 3.1.x package in the case that distributions switch - [currently there are not many distributions even going for 3.1.x](https://repology.org/project/wxwidgets/versions) though)
5. Download tarball for Audacity 2.4.2
6. Build Audacity against the custom unreproducible wxwidgets development package
7. Have stable package (???)
**Expected behavior**
* Audacity can be built against a stable version of wxwidgets without side-effects
Alternatively:
* Audacity can be built against a development version of wxwidgets without side-effects (downside: distributions need to package a development version, of which Audacity might be the only consumer)
Alter-Alternatively:
* Audacity source tarballs with **all** relevant custom sources (this includes the latest stable release of the [custom and patched wxwidets](https://github.com/audacity/wxWidgets)) are offered to consumers that need to build from source
* Audacity may be built against its custom wxWidgets version (statically linked) from one source tarball (note: this will still be a big no-no for most Linux distributions, [see Fedora's take on this topic](https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libraries))
**Screenshots**
n/a
**Additional information (please complete the following information):**
- OS: Arch Linux
- Version: 2.4.2
**Additional context**
Upstream wxWidgets clearly marks [3.0.5 as the *stable* release](https://wxwidgets.org/news/2020/04/wxwidgets-3.0.5-released/) and [3.1.3 as a *development* release](https://wxwidgets.org/news/2019/10/wxwidgets-3.1.3-released/).
This means Audacity makes use of a *patched* development release (so not even a vanilla development release).
opened 12:46PM - 29 Jun 20 UTC
Arch Linux
Meta
Request
bug-distros
**Describe the bug**
In c42d188e7 the autotools setup has been removed, althoug… h the new cmake setup still has fundamental issues in reaching feature parity (#519, #521, #522). This change was neither mentioned in the ChangeLog (see #593) nor in the [release notes in the wiki](https://wiki.audacityteam.org/wiki/Category:Release_Notes).
**To Reproduce**
Steps to reproduce the behavior:
1. Download 2.4.2
2. Extract and try to use autotools to build
3. Try to find information about autotools setup deprecation anywhere
**Expected behavior**
A fundamental change with _how_ a project is being built is announced in a ChangeLog. If a deprecation is planned it would be very helpful to pro-actively announce this (for a large scale project such as Audacity) and make sure that at least feature parity with the previous build system is reached before making it the default.
**Screenshots**
n/a
**Additional information (please complete the following information):**
- OS: Arch Linux
- Version Audacity 2.4.2
**Additional context**
A possible approach to pro-actively announcing these types of changes instead of pushing this downstream (without announcement) has been made in https://github.com/audacity/audacity/issues/538#issuecomment-633678357 and I have opened #593 for a more straight forward and helpful use of the ChangeLog.
I don't quite understand what kept the project from simply announcing when and how their build system will change fundamentally. For me this is considered common courtesy (especially after bringing this up before).
opened 12:47PM - 17 May 20 UTC
Arch Linux
bug-distros
**Describe the bug**
The CMake setup hardcodes the required version for [portsm… f](https://repology.org/project/portsmf/versions) to something Debian/Ubuntu specific.
The [portsmf upstream does not seem to have proper releases](https://sourceforge.net/p/portmedia/wiki/Installing_portsmf_on_Linux/) (which is why on Arch Linux we chose to check it out of svn directly using a specific revision (currently the latest), following the style of portmidi on sourceforge (which provides releases based on revision numbers, e.g. `217`). This currently translates to version `234`.
When using the cmake setup on anything but Debian or Ubuntu this means, that portsmf is not detected and the internal version is always used.
**To Reproduce**
```
cmake -L -B build -S .
```
[audacity-2.4.0-cmake.log](https://github.com/audacity/audacity/files/4640246/audacity-2.4.0-cmake.log)
**Expected behavior**
The system installation of portsmf is detected (which was the case with the autotools based setup).
**Screenshots**
-
**Additional information (please complete the following information):**
- OS: Arch Linux
- Version Audacity 2.4.0
**Additional context**
I'm aware, that portsmf doesn't provide a pkgconf integration out-of-the-box and is generally undead, but hardcoding this to always default to the local version and not detecting a system version is not a good choice either IMHO.
opened 01:44PM - 17 May 20 UTC
Arch Linux
bug-distros
**Describe the bug**
The cmake setup for 2.4.0 does not detect a system version… of lame.
On Arch Linux we currently offer 3.100, but it is not detected.
**To Reproduce**
```
cmake -L -B build -S .
```
[audacity-2.4.0-cmake.log](https://github.com/audacity/audacity/files/4640339/audacity-2.4.0-cmake.log)
**Expected behavior**
A system version of lame is detected and used.
**Screenshots**
-
**Additional information (please complete the following information):**
- OS: Arch Linux
- Version Audacity 2.4.0
**Additional context**
The detection of the lame library works in the autotools setup (based on the header file).
opened 01:55PM - 17 May 20 UTC
Arch Linux
bug-distros
**Describe the bug**
When building with autotools or CMake neither portaudio no… r portmidi is detected properly.
While for portmidi a wrong version is hardcoded into the CMake setup (similar to what is done for portsmf, see #519), for portaudio the detection doesn't seem to work at all.
**To Reproduce**
```
cmake -L -B build -S .
```
[audacity-2.4.0-cmake.log](https://github.com/audacity/audacity/files/4640345/audacity-2.4.0-cmake.log)
**Expected behavior**
Both portaudio and portmidi system installations are detected and used if they are available.
If they should not be available, the option to use system installations of either library should be removed or set to **experimental**.
**Screenshots**
-
**Additional information (please complete the following information):**
- OS: Arch Linux
- Version Audacity 2.4.0
**Additional context**
While portaudio is still "more or less" active upstream, it hasn't seen a release in many years and the inability of the project to move away from the lock-in pay-to-use assembla to a less restrictive source distribution platform is not a good sign.
If many (custom) patches on top of the latest releases of portaudio or portmidi exist, then these should be upstreamed and if possible upstream should be conveyed to a new release (I tried to get a response from the portaudio maintainers on this topic a while back, but never got a reply).
I'm aware if any of the audacity maintainers are in contact with these upstreams or not, but I'm certain that their voice would be heard as a fairly large user of both libraries.
1 Like
caho
22 May 2021 09:39
11
I tested it with some of my audacity - projects and all works fine
For example:
regards
philm
22 May 2021 10:01
12
Maybe we should try the PKGBUILD from KaOS …
1 Like
Lolix
22 May 2021 18:19
13
Unless they fail to build, which was the case until minutes ago
I have copied the flag that I was missing from KaOS pkgbuild, while also enabling to build against Gtk3 instead of Gtk2 Update audacity-git · FabioLolix/PKGBUILD-AUR_fix@56c2ddd · GitHub
Arch repo not getting updated due to upstream build issues apparently…
audacity is stuck on 2.4.1 for months now, due to upstream build issues
1 Like
i’m not sure i WANT the new version:
https://news.ycombinator.com/item?id=27724389
edit: it looks like the telemetry has to be enabled at compile time and defaults off, so whoever builds it for arch will ?probably? not do that?
6 Likes
To expand on what @steanne said.
Audacity has been bought Muse Group, and they want to make Audacity phone home: system details and errors (opt-in), IP on use (opt-out).
There is a fork here:
2 Likes
That’s an overreaction. Audacity can be built without the “telemetry”: [Fedora-legal-list] Re: Audacity is no longer free - legal - Fedora Mailing-Lists
There’s no need for a fork to be used, and this “telemetry” is completely reasonable, it’s simply being taken out of proportion: Clarification of Privacy Policy · Discussion #1225 · audacity/audacity · GitHub
omano
8 July 2021 02:02
19
In their latest policy update, they forbid people under the age of 13 to use Audacity, and the telemetry seems to be there for good.
I don’t think there is an over reaction, it’s been multiple months now that they are going against FOSS mentality.
4 Likes
This is purely there because of the GDPR restriction that collecting IP addresses is personal data. The only reason they collect IP addresses is because of the very nature the internet works, please tell me how you’re supposed to check for updates without revealing your IP address.
If you’re going against Audacity because of the 13 year limit, might wanna go against Signal , Steam , Openshot , Firefox , Bitwarden , Element/Riot , LineageOS and basically every piece of software that connects to the internet in some way and has a legal team that has done their homework.
Please do not form a double standard, and understand that these are all due to legal restrictions by GDPR, not because the company behind Audacity has a vendetta against 12 year olds.
