The update this morning brought some changes at least in the pulse configuration. I got aware of this because the update asked me if I want to overwrite with the pkg file /etc/pulse/librem5,pa.pkg-dist my existing file (which was working fine) /etc/pulse/librem5.pa. I denied the overwriting with the result that afterwards no audio was working in calls anymore. I had to rename mine one to librem5.pa.wasworking and to move librem5,pa.pkg-distin place aslibrem5.pa`, and after a reboot everything was fine again in calls.
It’s quite dangerous that an update let you without phone calls, IMHO.
I have here the diff between the two files, maybe some pulseaudio guru understands what was happening:
If I recall correctly, when apt asks you if you want to keep your own version of a config or let the system overwrite it, that dialog pretty clearly states that if you don’t know what you are doing you should let it overwrite it.
Hmmm. The old configuration had cost me in February a lot of work beeing able to do voice calls at all. That’s why I decided in that moment to not overvrite it, I went to a shell and made a copy of what came down as distribution, because what came down in February did not worked either.
I am on an Evergreen L5, with gnome-Calls 43.0, pulseaudio 14.2, with recent new L5 base packages installed.
Calls are working for me with VOLTE on and on 4G AT&T.
What i did notice is that if the Camera/Microphone HKS switch are set to off, then receiving or making calls on selecting answer it goes straight to voicemail. This could be by design.
I think what it should be doing is allow calls to go through, then with microphone off send banner notification to user alerting them that they need to turn the microphone on to be heard, maybe even have the action in the notification if the microphone is turned off in software instead of the HKS which would take the user to the Sound Gnome settings menue.
Not saying that would be a fix but maybe make the software more robust.
I think that’s a bit harsh. Many times I have faced that prompt during an upgrade (not on the Librem 5, this is on Linux generally). The reality is that in practice it may be that both options (keep the existing file, take the package maintainer’s file) will break the system. Usually the only way forward is to save all the versions and, after the upgrade, carefully study all the changes, and the documentation, to work out what is needed.
Given the pace of development on the Librem 5 (i.e. lots of things happening), a user should probably have a bias towards “take the package maintainer’s file” and sort things out afterwards - and a bias against getting too creative with local configuration at all. Just my opinion of course.
As I said, I’ve had a lot of work in February to get audio in calls working at all in the sense that the called person could understand me. If you will search the forum for sure you will find them. That’s why I wanted to keep the file. After the update I did call to the voice message system of my company (because this allows to record and play back the recorded in one call) and I realized, already because of the missing dial tone, that my old config now was not working anymore. So I installed the distributed file, rebooted and all was fine again. Maybe even better the quality. I’d not call that procedure “willingly broke” my system myself.
When I have some time, I will do a closer look into the changes, maybe I understand them (or some kind soul can explain them).
The result of that work should mean that that the new default pulseaudio config should be sufficient to provide improved voice call audio without the need for any custom configuration.
Typically what I do on Debian based systems is…
sudo apt update && apt list --upgradeable
I then look through the list of upgrades available, if there is anything in the list I know has been customised I then run apt changelog on the package prior to upgrading to try to determine what impact the upgrade may have.
Unlike Debian which will display the changelog of the package version to be installed, with the Librem 5 (and perhaps PureOS in general?), apt changelog will only return the relevant changelog after the package has been upgraded (or at least that was the case when I have tried it previously) which limits it’s usefulness.
If the package maintainers version breaks the system, then that should be a pretty serious bug that should be reported. Even if that might have happened to you some time, it should not be a normal case.
In my opinion, if you modify system configurations you are responsible for keeping them up to date. There are probably almost an infinite amount of possible configuration combinations the user can set, it’s simply not realistic to expect maintainers to be able to handle all of them. Even if they tried, different people would probably want it handled in different ways.
If you make a custom fix yourself, you are responsible for making sure that it does not break anything else in a future update.
The freedom that desktop Linux distributions give also means a lot of responsibility for the users. I think that the new SteamOS 3.0 did the right thing of making large parts of the system read-only so users don’t break things. Makes a lot of sense when your primary target audience is someone who just want things to work, while they still give the possibility to completely replace the whole distro if you so desire for those who want to tinker.
Depends what we mean by “break the system”. If the system fails to boot or a key component fails to start then you are right. But for what I meant - something worked correctly prior to the upgrade and no longer works correctly after the upgrade (because configuration has been lost) - then I wouldn’t bother to report it.
This is a well-known problem with ad hoc growth in nature of parameters and number of parameters. It is infeasible to test all possible combinations (exponential growth) but, worse still, there are subtle interactions between parameters where some combinations can’t make sense (i.e. not orthogonal).
If reporting anything to the package maintainer, it might be: improve the configuration file architecture so that the package maintainer’s version can be replaced on every upgrade and the user never modifies the package maintainer’s version but the user can apply parameter overrides via a separate config file.
It is still possible for an upgrade to break but it is more robust in the face of config-related software changes.
As I said: Usually the only way forward is to save all the versions and, after the upgrade, carefully study all the changes, and the documentation, to work out what is needed.
There already is an option to show the differences when upgrading and selecting whichever version you want (or a mix of them, by manually editing the files in a shell).
On my desktop I use arch which handles it in a different way. It keeps the users configuration and saves the maintainers new version at the same place but with the suffix “.pacnew”. Instead of prompting the user, it just prints a single line of text saying that there’s a new version which is really hard to see when there’s often a hundred of uninteresting lines printed during upgrade. Has messed up things 2-3 times for me the past 8 years of using arch on two computers. In general I prefer arch, but debian handles this much better.
Yes - however I prefer not to use that as the upgrades already take an eternity as it is - and, without carefully reading the documentation, making changes during the upgrade is a recipe for a stuff up. I prefer just to study the changes in the cool light of day.
Postponing fixing the configurations will result in a system that is upgraded, but possibly has broken configurations so it does not solve anything. At that point it’s better to upgrade every package in the system except for that package until you have the time to fix it, otherwise you will have a running system with a possibly broken state (and depending on what package it was, it can be a critical issue).
Regardless, you still have the option to open the shell during upgrade and copy both versions. I don’t see the problem here to be honest.
