PipeWire 0.3.31 Released With Better JACK Support, More Crash Fixes

[ssokolow]

Did you ever have a close look at the flatpak run and install command.

I'm well aware of the complexity involved in doing it properly. That's why I called what I did a hack.

That doesn't change the fact that, as an end user, it's an uphill battle to make Flatpak-installed applications suitable for some uses and I only have so much time to spare.

[oiaohm]

For example:[LIST=1][*]I had to build my own hack to generate CLI launcher aliases that don't begin with com.WeDontLikeTabCompletion.* and the Flatpak devs have punted on this. (I use gmrun or Yakuake for launching applications, so I'm not going to put up with flatpak run ... as the simplest command.)

Did you ever have a close look at the flatpak run and install command.

https://www.systutorials.com/docs/linux/man/1-flatpak-run/

--user
Look for the application and runtime in per-user installations.

--system
Look for the application and runtime in the default system-wide installations.

--installation=NAME
Look for the application and runtime in the system-wide installation specified by NAME among those defined in /etc/flatpak/installations.d/. Using --installation=default is equivalent to using --system.

Next question what is that installations thing.

https://docs.flatpak.org/en/latest/flatpak-command-reference.html#flatpak-installation

flatpak can operate in system-wide or per-user mode. The system-wide data is located in $prefix/var/lib/flatpak/, and the per-user data is in $HOME/.local/share/flatpak/.

In addition to the default installation locations, more system-wide installations can be defined via configuration files /etc/flatpak/installations.d/, which must have the .conf extension and follow the format described below.

Welcome to fun how many times does flatpak allow you to install the same flatpak application on a system. The answer is as many installation directories as you are willing create. You start with 2 but the answer is in fact infinity. I have used this at times when I have need there different versions of the same flatpak application.

I have multi versions of chromuim installed include the degoogled chromuim.

ssokolow the problem here is the reality that flatpak different. The URI for application was chosen because that a unique value to a flatpak installation directory please note only unique to the installation you can have many different versions installed. Now take the "ebook-convert" command from calibre. It quite possible for me to have multi applications installed in flatpak that provide the ebook-convert command. This could be like degoogled chromuim that is a fork so I have chromeuim and degoogle chromuim in the same installation directory of course they both contain the binary chromuim.

The bug of CLI ease of use with flatpak is not easy. No one in the complete bug report was really putting up a workable solution and was not looking at what was the constraints of flatpak itself. Instead presuming presuming this was simple.

Please also note the last bit of the of the URI does not have to be the command that being executed by "flatpak run com.github.Eloston.UngoogledChromium" the binary in that is "/app/bin/chromium" that is run when you click on the .desktop file. Yes a person suggest used the last bit of the URI as the program this does not work. flatpak --command because each flatpak package can in fact provide multi applications yes this include multi .desktop files. Yes this could include multi command line applications.

Ubuntu snap is not design to allow multi versions of the same application where flatpak is. Yes this is why you install a Ubuntu snap it adds a symlink because it can if you had a package and it was going to conflit there are cases where the result with Ubuntu snap the snap will not install until you remove that package so the way the snap package solved the command line problem does not apply to massively more flexible flatpak .

I do think we need some application like https://wiki.debian.org/DebianAlternatives that is designed for flatpak. Yes debian and other distributions have run into the problem of multi packages providing the same binary. Please note that complete bug report asking for better commandline no one person in fact brought up that the solution need to be like a debian alternative system due to what flatpak is. Yes designed for the nightmare that you can have applications installed multi times and that binary names are not unique. Of course application could include important things like setting up allowed directories.

There is a question if this should be automatic at all. Correct might be if you need command line tools you run this application/command to enable X internal flatpak application to be exposed to user with correct sandbox set every time user runs command.

ssokolow I really don't any clue how good solution to make flatpak command line usage nice that does not require user work to enable(so not able to be automatic). I do know enough to look at items people are suggesting and see this is not workable due to flatpak been such a pain with allowing due to the fact it allows you to install the same application a unlimited number of times so since you are allowed unlimited number of versions of any application by the flatpak design. This is a different level of problem to what distributions have faced in the past. My point of view this requires more powerful version of Debian Alternatives yes the more powerful version would have to include sandbox rule setting. I cannot see anything existing that is just ready to go that will fix the problem up and with the different levels of security people want I cannot see how generic works out box on the command line can be done with flatpak that simpler than the current flatpak run. Generic I have to run command to enable application command on command line in a short simple is something that may be able to be made work.

[ssokolow]

Can you elaborate why command-line and flatpak don't work well. I mean it is a little less convenient but once one gets used to executing
'flatpak run org.inkscape.Inkscape' instead of 'inkscape', it works just as well.
Of course, 'inkscape' itself is just a link to the installed executable and can also be configured to execute the flatpak command.

Totally agree to the file access from browser. Currently, the only options are to either copy your files in a folder accessible by the browser (usually just ~/Downloads) or to blow the sandbox wide open.
However, I think this is being considered..

Ahh, what the heck. I'll do an initial response now.

It's sort of a death of a thousand cuts, exacerbated by developers who explicitly say they have no intent to support CLI uses.

For example:

1. I had to build my own hack to generate CLI launcher aliases that don't begin with com.WeDontLikeTabCompletion.* and the Flatpak devs have punted on this. (I use gmrun or Yakuake for launching applications, so I'm not going to put up with flatpak run ... as the simplest command.)
2. Because of the lack of official support, my hack to generate CLI aliases sometimes generates things like scummvm_wrapper or com.github.tchx84.Flatseal because that's the actual command name inside the Flatpak. (When I graduate beyond a minimal shell script hack, I'll have to maintain a fixups table.)
3. I still have to build my own solution for generating wrappers which construct the right --filesystem= arguments from the CLI arguments, and I don't know how to do a File Chooser Portal-esque "update an existing sandbox" thing for programs which operate on a single-instance "reuse existing running process if present" model. (Currently, I just have to remember to copy SVG files into the folders I've tightened its manifest sandbox to before opening them, since I use Flatpak to get the newest Inkscape. To do it right, I basically have to reinvent the application's CLI argument parser so I can tell what is and isn't potentially an output path that doesn't exist yet but needs to be granted anyway.)
4. This all assumes the program isn't something I'd also like to run in a context where my PATH override to the folder full of launcher wrappers are, such as a cronjob using Xvfb or the tool's headless mode. (I'm mildly surprised this hasn't come up for scripting Inkscape to render SVGs yet.)

Oh, and do check out that "punted" link, because the devs basically decided that "The current solution doesn't meet my needs and here's why" was "abusive" and locked the issue.

[ssokolow]

https://github.com/flathub/com.calib...ibre/issues/30
People have got the ebook-convert working with the "flatpak run --command=ebook-convert com.calibre_ebook.calibre" the problem was a runtime issue why it would fail covered in the bug report above. Please note this was also resulting in convert failures with the complete calibre graphical open as well.

Huh. When I was looking through the issues to see if there were any deal-breakers, I came away with a memory of an uncontested use of the phrase "will never work" somewhere.

As for the rest, I'll reply to that after I get some more sleep as part of replying to mppix.

[oiaohm]

i use teams with pipewire without issues

https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/838#note_975561

Read the bug report pal666. There are people having problems with Teams. The issue is that MS Teams wants 16 bit audio. If it see no 16 bit audio it pretends no audio at all exists.

Yes its possible to make MS Teams fail with pulseaudio and raw ALSA. Yes if your sound card is 16 bit only pipewire would provide 16 bit to everything out the box so then MS Teams would work perfectly. You have a system that supports like 24 bit audio then pipewire based on it configuration decides if it exposes 16 bit audio to ALSA or not the common default has been no 16 bit audio in that case.

This is why we people like you pal666 saying works for me. Then people like jacab saying it does not work for them. This is minor teething problems. There is also 16 bit audio speed particular speeds of 16 bit audio MS Teams will not have a bar of either.

The reality is MS Teams could have had a lot better error handling as in detected audio and then found not the format it required could have displayed a nice little error need 16 bit audio system. The problem would have been more user solvable then just displaying no audio because it did not like what it found.

Yes pulseaudio with ALSA support disable MS Teams is also dead. The version of Teams electron runtime does not have pulseaudio support instead is depending on ALSA emulation by pulseaudio/pipewire. Yes current editions of electron runtime do have pulseaudio support and that path would have resulted in automatic 16 bit to 24 conversion being done.

[pal666]

The only problem I've had is that MS Teams doesn't work with PipeWire.

i use teams with pipewire without issues

[oiaohm]

Flatpak explicitly does not intend to provide first-class command-line support, so I'd never be able to use Calibre through Flatpak, since I only ever use it by scripting the ebook-convert CLI tool.

https://github.com/flathub/com.calibre_ebook.calibre/issues/30

People have got the ebook-convert working with the "flatpak run --command=ebook-convert com.calibre_ebook.calibre" the problem was a runtime issue why it would fail covered in the bug report above. Please note this was also resulting in convert failures with the complete calibre graphical open as well.

Flatpak does include support to use command line tools from flatpaks its not not the most friendly beast all the time due to the sandbox restrictions resulting in needing to pass the right allow flags so stuff works

Sandboxing I do agree is bringing it fair share of problems. That drag and drop is something else that needs to be solved.

[jo-erlend]

I use Pipewire as default audio server since 0.3.30 on Ubuntu 21.04 and all works fine. Finally I don't have to suspend PulseAudio for enable JACK for simple thing like a recording via Audacity. Even Audacity from Flatpak works fine (recording of multiple tracks never worked fine for me before use of Pipewire).

I have a Zoom H6 recorder, which has multiple inputs and I've tried to use it with Audacity, but only got one input. Do you think this might solve that? That would be so very cool! You really got my pulse going now.

[mppix]

I generally agree but there are hiccups here and there.

Some examples:

• Geeqie refuses to pick up the Flatpak-provided copy of the Breeze widget theme for whatever reason. (All my other GTK Flatpak apps Just Work™ on that front.)
• Flatpak explicitly does not intend to provide first-class command-line support, so I'd never be able to use Calibre through Flatpak, since I only ever use it by scripting the ebook-convert CLI tool.
• I keep the APT-distributed version of DOSBox for various test automation scripts that wouldn't know to pass the necessary --filesystem flags. (Hopefully, WASI won't take too long reach a point where a WASI build of DOSBox can be made and distributed via wax's CLI-friendly "share $PWD by default" paradigm.)
• There are various other apps that are on Flathub, which I currently use from the Kubuntu 20.04 LTS repositories while I'm waiting for various sandboxing-caused feature regressions to be tracked down and solved.
• I have yet to see how support will be added to web browsers for File Chooser Portal-like behaviour when double-clicking or dragging-and-dropping a file:// URL outside the Flatpak sandbox, so I have to keep one browser unconstrained for that.

Can you elaborate why command-line and flatpak don't work well. I mean it is a little less convenient but once one gets used to executing
'flatpak run org.inkscape.Inkscape' instead of 'inkscape', it works just as well.
Of course, 'inkscape' itself is just a link to the installed executable and can also be configured to execute the flatpak command.

Totally agree to the file access from browser. Currently, the only options are to either copy your files in a folder accessible by the browser (usually just ~/Downloads) or to blow the sandbox wide open.
However, I think this is being considered..

[ssokolow]

Other than that, I'm starting to make flatpak apps my default install process and I don't really see drawbacks: you tend to get the latest versions (big deal on Debian stable for example), more security, theming integration is often better, and it does not require much/any effort from the user.

I generally agree but there are hiccups here and there.

Some examples:

• Geeqie refuses to pick up the Flatpak-provided copy of the Breeze widget theme for whatever reason. (All my other GTK Flatpak apps Just Work™ on that front.)
• Flatpak explicitly does not intend to provide first-class command-line support, so I'd never be able to use Calibre through Flatpak, since I only ever use it by scripting the ebook-convert CLI tool.
• I keep the APT-distributed version of DOSBox for various test automation scripts that wouldn't know to pass the necessary --filesystem flags. (Hopefully, WASI won't take too long reach a point where a WASI build of DOSBox can be made and distributed via wax's CLI-friendly "share $PWD by default" paradigm.)
• There are various other apps that are on Flathub, which I currently use from the Kubuntu 20.04 LTS repositories while I'm waiting for various sandboxing-caused feature regressions to be tracked down and solved.
• I have yet to see how support will be added to web browsers for File Chooser Portal-like behaviour when double-clicking or dragging-and-dropping a file:// URL outside the Flatpak sandbox, so I have to keep one browser unconstrained for that.