Closing due to lack of response from original reporter.

Closing as a non-issue: Phones are known to work with their memory constraints, which seems the only real concern here.

Hopefully this issue was fixed with newer releases of LibrOffice...

I have no idea what caused that issue, but blindly assume that it is fixed with newer releases of LibrOffice...

@tbernard do you still suffer from this (super frustrating, I imagine) issue now 3 years later?

@EchedeyLR Do I understand you correctly that this issue is solved by now?

Thanks for the detailed issue report, and sorry for the loooong silence.

Sorry for the looong silence.

Please note that it looks like adding /etc/firefox-esr/pureos.js is only masking the problem. The underlying implementation would still be built in the package and available in the source code. This has already been mentioned in the last paragraph of this comment: https://tracker.pureos.net/T902#16752

OK, if there's an interest from PureOS team to resolve these issues, I will do my best to file them separately.

I hope you have found a different distro more to your liking, then.

I'm sorry, but I abandoned PureOS. There were several things that didn't work to my liking and I didn't have time to study how to do it. For the record, I've been a GNU/Linux user for years, but I didn't quite understand how to make the system work. Maybe I'm getting older... :-/
I can't help to finish this task.

Interesting experiment by smvc. As noted above we can build from git *but* lack the laneakia integration so this currently foremost needs some input from @mak how we want to proceed there (i.e. what part of the laneakia system fetches from git, do we still build source packages, do we use shim .changes files or do away with all of this)? I'd go for initially mimiciing current build process as much as possible (have a art in laneakia that watches git repos, if a signed tag pops up verify that build a source package and submit it to the existing infrastructure and then work from there. But then again this depends if we want to work on something that works for Debian as well, etc.

Mabe this is useful: https://salsa.debian.org/smcv/deb-build-snapshot/

From my side this can be closed since i don't think amber matters much at this point. I'm not sure what the PureOS policy is here? Close once the release goes fully out of service? @jeremiah.foster ?

From my side we an close this since zanata isn't in use by any Purism project anymore afaik.

For the record I recently triggered this bug again, while building a rust app.

I assume - and sincerely hope - that this issue is solved by now.
No, we do not apply pressure on Debian developers - we collaborate with them.

This was a hardware issue specific to a single unit.

I would guess this issue to be tied to graphics drivers or the linux kernel. Both have seen many changes since this issue was reported - is it still reproducible with up-to-date amber or byzantium?

quite some time has gone by since this issue was reported - is it still a valid issue now? With amber and/or byzantium?

If update-initramfs really fails to rebuild initramfs then it is a serious issue - but the output shared in the issue description shows not a failure but just a warning.
What exactly fails here?

Yes, GDM3 is known to not handle locales correctly. See e.g. https://bugs.debian.org/633846 and other Debian bugs https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=gdm3

Probably this it (or was) an issue with the X11 graphics driver.
Quite some time has passed since this was reported - is the issue still reproducible with PureOS amber or byzantium today?

That looks like an issue not with PureOS but with a script executed from a direct download (something that is generally frowned upon due to its security implications, but that is another topic): Please report as an issue upstream instead.

Closing this as a non-bug.

The people in the Librem One team needing this tool no longer work for Purism, so there is noone who can provide feedback if the tool is working as intended, and I have therefore stopped caring.

based on the conversation, this issue is solved.

based on the conversation, this issue is solved.

seems from the conversation that this issue is solved.

Sorry, no: Thunderbird disabling plugins on upgrade is a design choice of the application, tied to how they manage plugins. The way to change that is essentially to switch to a different application.

This issue is more than a year old, and tied to byzantium which is (for a little while more) a moving target. I guess this is solved by now - if not then please reopen.