Publish in Linux distributions' repositories.

[RokeJulianLockhart]

The current https://github.com/chidiwilliams/buzz/releases/download/v0.8.1/Buzz-0.8.1-linux.zip is inadequate.

Complete	Type	Name	Rationale
[ ]	.apk	Android	Immediately provides about 3.6 billion more users access to this, and shouldn't be infeasible due to the simplistic and inherently vertical interface, per https://camo.githubusercontent.com/85870ac08ce375dbb26f2b6535793cf43ef21794e3c6c2d68c737816341c269d/68747470733a2f2f63646e2e6c6f6f6d2e636f6d2f73657373696f6e732f7468756d626e61696c732f63663236336230393961633334383130383262623536643139623763383766652d776974682d706c61792e676966. This would involve publishing in two repositories – first https://f-droid.org/en/docs/Inclusion_How-To/, then Google Play. Only the latter should involve any work.
[ ]	.rpm	(Open)SUSE	Popular due to it supporting every processor and EFI type under the sun.
[ ]	.rpm	Fedora	Immensely popular for users of modern hardware.
[ ]	.deb	Debian	Popular due to it supporting every processor under the sun.
[ ]	.deb	Ubuntu	Immensely popular for new Linux users.
[ ]		Arch	https://github.com/chidiwilliams/buzz/issues/384 – “It's strange that I don't find this project on AUR.” Added to consolidate issues, although the AUR is worth contributing to due to its immense package selection.

[chidiwilliams]

Yes, this would be great to have, although I haven't found time to fix the Linux packaging. Thanks for making the issue. Will track progress here.

[xalt7x]

Please consider Flatpak (universal packaging format for most Linux distributions).

[RokeJulianLockhart]

Although know that @Flatpak does not replace in any way native packages. It augments them until native versions are available. @xalt7x, you should open a separate issue for that.

[xalt7x]

@rokejulianlockhart

Although know that https://github.com/flatpak does not replace in any way native packages. It augments them until native versions are available.

Well, I don't want to argue much but that's a very questionable statement.
Most native packages are provided by either distro maintainers (Debian, Ubuntu, Fedora, openSUSE, Arch) or volunteers (Ubuntu PPA, openSUSE Build Service, Arch AUR). Original vendors provide their software in a format which they see as valuable and which they can properly maintain. Some software might never be packaged in distro native versions. Why? Because it requires additional interest, time, effort, skills and further even maintenance to preserve compatibility with newer distros (which might update or even drop critical dependencies).
So no, Flatpak is not a stop-gap "until native versions are available".
Universal packages (Flatpak, Snap and Appimage) exist to simplify distribution and maintenance burden.

you should open a separate issue for that.

I agree, this thread really should focus on native packages hence my rant is over and new issue created :) . Thanks for the suggestion!

[RokeJulianLockhart]

Well, I don't want to argue much, but that's a very questionable statement. Most native packages are provided by either distro maintainers (Debian, Ubuntu, Fedora, openSUSE, Arch) or volunteers (Ubuntu PPA, openSUSE Build Service, Arch AUR). Original vendors provide their software in a format which they see as valuable and which they can properly maintain. Some software might never be packaged in distro native versions. Why? Because it requires additional interest, time, effort, skills and further even maintenance to preserve compatibility with newer distros (which might update or even drop critical dependencies). So no, Flatpak is not a stop-gap “until native versions are available”. Universal packages (@Flatpak, Snap and AppImage) exist to simplify distribution and maintenance burden.

I know this, @xalt7x. I'm uncertain why you state it – it does not contradict

know that @flatpak does not replace in any way native packages. It augments them until native versions are available.

---

I suggest that you mark https://github.com/chidiwilliams/buzz/issues/466#issuecomment-1577192907 and https://github.com/chidiwilliams/buzz/issues/466#issuecomment-1585557350 as off-topic.

[lv2eof]

Hi, I would like to install Buzz in Fedora 38 running KDE. I search for "libportaudio2" and I coudn't find it. How can I install Buzz on Fedora? In "Discover" (the apps repository for KDE) there is an entry for Buzz but it stops in the middle of the installation process. Thanks in advance.

[RokeJulianLockhart]

In "Discover" (the apps repository for KDE) there is an entry for Buzz but it stops in the middle of the installation process.

Does Discover state why, @lv2eof?

[lv2eof]

Hi, I have to admit that it was my fault. I haven't wait enough time. Nevertheless, it takes so much time to install that I though it was frozen. Any way, it is installed and it working. I tried with a podcast of more than one hour long and the result was better than expected. Best regards.

[spoelstraethan]

@chidiwilliams perhaps this could help boost the process.

https://github.com/goreleaser/nfpm

[RokeJulianLockhart]

https://github.com/chidiwilliams/buzz/issues/466#issuecomment-1773080637

@spoelstraethan, I believe that https://openbuildservice.org/ is probably the easiest, since they take care of bug management (should that be desirable) hosting and CI.

[raivisdejus]

Old thread, but a question - As we have SNAP version that runs on multiple Linux distributions des anybody feel that some Linux platform is still missing support?

[RokeJulianLockhart]

https://github.com/chidiwilliams/buzz/issues/466#issuecomment-2150337308

@raivisdejus, Snap is not well regarded by most. Were you to provide a Flatpak, many would consider that adequate, but .deb and .RPM would be a significant improvement too.

[xalt7x]

I search for "libportaudio2" and I coudn't find it. How can I install Buzz on Fedora?

In case anyone else wondering, here's a command to install missing dependencies for PyPI package: sudo dnf install portaudio python3-pip

Then same commands as in the Buzz Readme:

pip install buzz-captions
python -m buzz

For immutable distros likle Fedora Atomic (Silverblue, Kinoite), Universal Blue or OpenSUSE Aeon/Kalpa, I'd recommend installing in a distrobox container (surely, distrobox package needs to be installed/layered on the host OS).

Tested on Fedora 40 Kinoite with distrobox v1.7.2.1 and Buzz v1.01

[xalt7x]

@raivisdejus

Old thread, but a question - As we have SNAP version that runs on multiple Linux distributions des anybody feel that some Linux platform is still missing support?

IMO, the biggest problem with universal Snap support is that it relies on AppArmor + out-of-tree patches for confinement. So Snaps are suitable for distros with good AppArmor support (Ubuntu, Debian, Manjaro, openSUSE Leap) and not so much for distros that prefer SELinux (Fedora, OpenSUSE Aeon/Kalpa) or prefer not to apply AppArmor patches (Solus).

Additional information:

• https://getsol.us/2024/07/15/dropping-apparmor-kernel-patches/
• https://github.com/nextcloud-snap/nextcloud-snap/wiki/Why-Ubuntu-is-the-only-supported-distro/
• https://forum.snapcraft.io/t/snapd-still-requires-out-of-tree-apparmor-patches-for-strict-confinement/19632
• https://www.reddit.com/r/Fedora/comments/14ls05p/current_state_of_snaps_security_particularly/