PipeWire 0.3.31 Released With Better JACK Support, More Crash Fixes

[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.

[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.

[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.

[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]

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]

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.

Take a closer look at that bug report and the other bug reports opened over the CLI issue. There is a repeating fault that nothing being suggested is allowing of the complexity that flatpak is.

I hope one day someone opens a CLI bug fix issue with flatpak that is properly considered.

[ssokolow]

Take a closer look at that bug report and the other bug reports opened over the CLI issue. There is a repeating fault that nothing being suggested is allowing of the complexity that flatpak is.

I hope one day someone opens a CLI bug fix issue with flatpak that is properly considered.

I know it's a hard problem... which is why the people who know Flatpak the best (the people who develop it) should be trying to solve it, rather than WONTFIXing it and calling "Flatpak still doesn't meet my needs with what you've done " abusive.

There's a reason there's a difference between a feature request and a pull request. Something that's claiming its intent is to support end-users who aren't hardcore programmers can't then turn around and demand that real end-users of competing solutions must deliver a perfect pitch and proof of concept to have their use case accepted as valid.

[oiaohm]

I know it's a hard problem... which is why the people who know Flatpak the best (the people who develop it) should be trying to solve it, rather than WONTFIXing it and calling "Flatpak still doesn't meet my needs with what you've done " abusive.

There's a reason there's a difference between a feature request and a pull request. Something that's claiming its intent is to support end-users who aren't hardcore programmers can't then turn around and demand that real end-users of competing solutions must deliver a perfect pitch and proof of concept to have their use case accepted as valid.

But you also have problem there that the bug report has tons of people pushing paths that can never work.

Problem here the people who know Flatpak best being the developers don't have a good solution. The developer of flatpak solution is create a alias on need. Debian alternative system did not come from core debian developers at first. Debian alternative system came from a person building a stack of hacks that worked for most of the problem cases. This include what GUI the users would need.

Just look over that bug report what was closed and the following abusive. Start of that bug report there is nothing mentioned about how to pass files into the sandbox safely for the command line. You might want some form of specialist command wrapper so user can pass any file into the flatpak without needing the file to be on a accessible path.

The reality here not all bugs on open source applications are closed for fair reason. This case the bug has no sign that it will make any progress. The users wanting this feature are not providing any clear clarifications of what they are attempt to-do.

https://github.com/flatpak/flatpak/issues/1188 if you go submit by submit on this bug carefully people are asking for 5 totally different things. One ask for that flatpak run lastbitafterdot works.

The reality there the developers are not mind readers. Some of bugs you need to close why because they have become what called abusive/abused. Lot of people thing this abusive/abused means bad language it also means the ideal is muddled to the point that could not be sure of they have solved the issue of the bug or not. In case that it has muddled the correct thing is close the bug and hope another user opens a new bug with a lot clearer define of what they want.

ssokolow something to be also be aware of they have the wontfix flag. This bug they closed and did not apply the wontfix flag. The reason closed being abusive is common miss read. Wine project changed to muddled a long time ago or closed requires splitting.

ssokolow do read over 1188 and try to clear list of what everyone in fact wants that does not end up conflicting. There are just cases where a bug need to be closed because its no longer a useful for development. No longer useful for development does not mean the problems in the bug report are solved.

Key point a bug report is meant to be a single definable problem 1188 is not that like it or not. If a bug is not a single definable problem its normally a bug being used to report multi issues in a single issue that is really attempting to abuse the bug system.

[mppix]

@oiaohm
@ssokolow
The bug report mentions a 'flatpak alias' function. AFAIK, this is not done yet but it would get us at least halfway there.
Now if the aliases would have an option to use both, the flatpak default reverse DNS or 'regular' DNS (to simplify auto-completion), this would be essentially done..
After that, it would just be a ton of bug reports to solve the command line bugs as people would start using it..
Just my 2c.

PS. yes, the behavior of some in the bug tracker is not acceptable. However, I can certainly understand the increasing frustration if this remains a wontfix.

[oiaohm]

@oiaohm
@ssokolow
The bug report mentions a 'flatpak alias' function. AFAIK, this is not done yet but it would get us at least halfway there.
Now if the aliases would have an option to use both, the flatpak default reverse DNS or 'regular' DNS (to simplify auto-completion), this would be essentially done..
After that, it would just be a ton of bug reports to solve the command line bugs as people would start using it..
Just my 2c.

That flatpak alias is not in fact what bug #1188 starting objective was.

https://github.com/flatpak/flatpak/issues/1565

It is 1565 but that is flatpak alias thing that is not implemented yet.

The reality here is the refi64 commented on Oct 8, 2019 should have been a different bug report. The flatpak alias as not in fact addressing the problem listed at the start of bug. Please note 1565 was opened in Apr 10, 2018 so reli64 comment in 1188 is in fact duplication of existing feature not implemented. Yes if feli64 had created a new bug in 2019 it would have most likely been closed as a duplicate of 1565.

Sorry this miss use of a bug system is abuse of the bug system. It also the bug system does not guide people hands well to show them they can open a new bug and link it to existing. So in case that you have a different idea that may solve the problem the smart and correct thing is in fact open new bug with the different solution and ask if this solution would fix problem.

mppix sorry to say as you look at 1188 I understand why the person managing the bug system would just say its abused and close the bug due to it becoming a managed mess. The item you pulled is one of the abused cases where its not what the bug was about and there was existing bug open for that feature. The deep you dig into 1188 bug the more of these rabbit holes you find of existing open bug solutions being duplicated in 1188. This is not like please look at X bug to see if this solution will solve this problem but instead reduplication with no link to existing.

I know its horrible the problem with bug triage at times you do have to be a total ass because like this 1188 the bug has gone off the rails best solution close the bug. Hopefully users will search the existing open and join the existing that match what they want or open a new bug that objective is clear not a muddled mess of different objectives.