Fixed with an update, a few days later.

Fixed in https://code.puri.sm/pureos/gimp/commit/d08880cc1da453421dddb31643fedb40fdf8e4d0 / 2.8.20-1pureos1

@francois can you have a look at this?

Ok, I take over from here. Pick something fun to work on (or take a break, I am sure noone minds!).

concern for you: You have fought this issue for a long time and mentioned frustration about it on irc recently.

Thanks for reporting this!

Reason for my cautious wording of comment T147#4606 was concern for you: You have fought this issue for a long time and mentioned frustration about it on irc recently. I want to help but am genuinely uncertain what you consider helpful here.

I have the exact same issues. I am not able to run Puremail and I have problems with PGP key import and links with Thunderbird.

@jonas.smedegaard First, perhaps I am accidentally reading something in your messages that is not there but I truly hope there is no animosity or something other that purely technical discussion here? If there is, then let's fix that and move on. :)

Thanks for raising the issue here.

I see 3 options:

@chris.lamb Please do tell me if you would like me to finalize the packaging that I have succesfully test-built.

Previus comment updated to clarify the sloppy and confusing use of "fail".

No as in not-how-Debian-maintainer-intended-for-sid - e.g. causing rendering artifacts.

As in FTBFS? Wfm, but also do note that this package uses a control.in...

It seems *only* renaming package will fail (EDIT: or so I guess - it regenerates control file dropping build-dependency on gcc-6) due to our change of target suite, and (at least, haven't tried yet) this patch is needed:

This issue seems _not_ solved: Current povray package in PureOS green is 1:3.7.0.4-2pureos1 (the version which I explicitly requested to _drop_ as part of this issue).

The issue disappeared after a system update but it comes back few days ago now.

It's been merged, so yeay!
https://github.com/corna/me_cleaner/pull/70

Considered fixed.

Whoops, I forgot to close this...
The package has been force-synced with Debian and is now tracking Debian Testing again.

Tried to check if the same will happen with Puremail (Thunderbird fork) but after installation can't even run it:

marek@librem:~$ puremail
XPCOMGlueLoad error for file /usr/lib/puremail/libxul.so:
libhunspell-1.4.so.0: cannot open shared object file: No such file or directory
Couldn't load XPCOM.

Thanks @theodotos.andreou - please give it a try and let us know :)

Also, I only submitted the patch via that email. I haven't committed it to any repos yet. You're free to take my code and run with it to finish this -- thank you!

Hey @kakaroto -- this has been on my todo list, but if you can do it first (plus if you can do it for the L13, which I don't have information on) then please go ahead. My patch works with my L15 but I don't have more than one model to test it on.

I gave it a try. The setup wizard promotes these DNS services (in this order):

• Google
• OpenDNS
• Level3
• Norton
• Comodo
• DNS Watch
• Custom

Well, I can not say for all combinations but I have M.2 SATA + 2.5" SATA in my L13. In Seabios the M.2 SATA preceeds the 2.5" SATA drive, in Linux the 2.5" SSD becomes sda and the M.2 SATA ssd becomes sdb, this is what dmesg says:

Thanks a lot @habs for the contribution. I never did that because I also couldn't figure out proper docs on what those 4 PCI IDS should be., but it feels to me like it can be any PCI device on the machine, I just didn't think that they would uniquely identify the librems. I'm now realizing that uniquely identifying via PCI is not needed, but it rather needs to identify with PCI + dmi information, so it's fine as is.
I tested your patch but unfortunately it didn't work, because the ISA bridge doesn't have a subsystem id, so the pci id that worked for me is : {0x8086, 0x9d48, 0, 0, 0x8086, 0x1904, 0x8086, 0x2015}
Did you send the patch to them via gerrit or do you want me to finish it (add the info for librem 13, and for the previous revisions?) then send it in one commit ?

@nicole: SeaBIOS will boot from the M.2 and I think linux will assign 'sda' to the HDD it boots from, no ? If you have a linux installed on the 2.5" and you boot on it, the 2.5" would be seen as "sda" in that case, no ?

I'm still not sure how this think works. Do you rely on their DNS service or is it a local DNS service on the installed machine?

I've reviewed Pi-hole and made some notes here: https://plan.puri.st/upstream/pihole

PureOS ova for Virtualbox.

The order that Linux detects the devices is also the other way araound, i.e. the M.2 becomes, if present, sda and the 2.5" SATA becomes sdb if M.2 is present. This should, if possible, also be reflected in Coreoot/Seabios. It is confusing when the first detected Coreboot/Seabios disk becomes the second one in Linux.

I just built firefox-esr_52.4.0esr-2_amd64.deb from the Debian testing sources on an up-to-date PureOS install and it works fine for me, not experiencing that issue.

In T147#3213, @chris.lamb wrote:

Purebrowser is currently out of date as rebuilding the latest esr results in extremely strange rendering artifacts such as completely missing icons and lines, etc. until I mouseover:

https://i.imgur.com/LRaquLX.jpg

A regular firefox-esr does not suffer from this problem, so I am (temporarily!) stumped as to why this happens.

I am going to see what happens.

I've been seeing that issue. I made a sources.list with debian repo and making apt-get purge --remove thunderbird && apt-get install -y thunderbird.

wow, thanks a lot @habs ! I am really happy to see this!

I submitted a patch for the Librem 15 here: https://mail.coreboot.org/pipermail/flashrom/2017-November/015218.html

In T247#4470, @chris.lamb wrote:

In T247#4401, @jonas.smedegaard wrote:

User agent sniffing is an anti-pattern. Our browser getting identified as different from Firefox is a feature, not a bug.

Whilst I 100% agree in principle, after working for (gosh) 10 years in web development it is something that is really unavoidable :(

In T247#4401, @jonas.smedegaard wrote:

User agent sniffing is an anti-pattern. Our browser getting identified as different from Firefox is a feature, not a bug.