In T1091#20414, @ctowne wrote:

Distribution upgrade worked for me.

sudo apt dist-upgrade

Distribution upgrade worked for me.

Another report from a user:

another report:

The patch has been merged and a new release made: https://source.puri.sm/librem5-apps/Stream/-/merge_requests/3

@joao.azevedo Sorry for the spurious ping. :-)

@jeremiah.foster you pinged the wrong João ;)

From what I can see the instructions for telegram-desktop 3.1.1+ds-1~bpo11+1 are the same as for other versions. That is to say, the build instructions appear to require you have API credentials;

Thanks for the clarification!

The patch adds no new features, it just makes the app work again

@jonas.smedegaard yes, this targets Byzantium.

@joao.azevedo did the outside World change, so that this is a regression, or is this a functionality which *never* worked on Stream and the patch is effectively a feature addition?

I assume this issue is targeted byzantium - tagging accordingly.

@jeremiah.foster pinging you here because you packaged Stream for PureOS.

thanks, this is working for now!

i now have 2.6.1+ds-1+deb11u1 and i cannot even log in.

I have updated 6/12 and again 17/12,
i now have 2.6.1+ds-1+deb11u1 and i cannot even log in.

Systemd v248 reverted the software workaround: https://github.com/systemd/systemd/commit/ba2b8f9

gnome-authenticatior already is packaged in Debian, but it is an old version; 3.32

Awesome, thanks for the feedback.
I used the GNOME Disks and reset the passphrase with no issues, worked pretty smoothly, no issues since.
My L15 is still hummin along just fine.

@Wildfire yes, this is fixed in Debian Bullseye

@mak
If time permits please have a look into updating base-files.

To add to this: if initramfs-tools is replaced by dracut the resulting initrd will not include functionality to decrypt a LUKS root filesystem using a LibremKey.

I guess this is done now...

@joao.azevedo please note that bundling multiple issues makes them all harder to track - e.g. I would be uncomfortable assigning the issue report to myself if knowledgable about only a subset of involved issues, would only flag it as done when all parts were done, and would have a hard time noticing when all parts were done.

Assigning to you, @jeremiah.foster as you seem to be involved already and know at least some bits of it...

Sorry for the late reponse.
Unfortunately, PureOS does not support non-free environments like VMware. You are of course welcome to try use it in such environments, but we cannot help with issues you may encounter related to that.

Closing due to lack of info.

I guess Adrian isn't active on this any longer, so reassigning back you to, @jeremiah.foster

@ChriChri Just for some extra context:

available since some time (entered Debian 2018-12-21)

available in Debian since 2018-12-21

I have not been able to use nuitka at all because the only version available in byzantium depends on a too-new version of base-files.

@guido Your assumption about the version we want is correct, I haven't looked at the current version within Debian yesterday. Due this I was also not wondering about the not visible new Debian version on the synchronization dashboard, seems there is a issue on not detecting the higher version in Debian, Matthias will be the only person I guess which can demystify this.

@carsten.schoenert I think we want base-files 11.1+debu11u1 + pureos changs, yes but @mak should confirm. What puzzles me is that it doesn't show up at https://master.pureos.net/sync/landing

Ah, I see it now: the older version mentioned by Carsten is the one currently in PureOS Byzantium.

which version of nuitka has such tight dependency on base-files, and why?

Seems your are right. That will require a update of base-files for byzantium.

This seems to have been resolved in the intervening period - due to updates I guess.

I am running a Librem14 (5.10.0-9-amd64) and was experiencing this same issue. Instead of purging gufw I needed to purge ufw. Before purging I noticed the ufw service was in a masked state after removing the package with apt. I also cleaned up /etc/ufw after the purge. I used the iptables rules in this bug report as a workaround and saved those to /etc/iptables/rule.v4 and .v6 so iptables-persistent would see them and rebooted. This fixed my issue, the networking was restored and the machine no longer would hang after decrypting the drive.

A user found out possible cause: