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.

I learned that Option 2 can be enabled by the user in a safe way by setting the "general.useragent.compatMode.firefox" parameter in about:config to true -- that is the purpose of that option which is only available in Firefox derivatives.

@d3vid, my connection is stable. I have no problems when not connected to the VPN; the connection never just suddenly drops, like it does when I am using it. Also, my packages are all up-to-date, and the problem still persists into this morning.

I am planning plenty more cleanup of that kind, but wait until _after_ we get endorsement from FSF to not confuse things.

@jonas.smedegaard Those are the issues I resolve with pleasure.
The last thing we need is bullshit divergences.

Status "invalid" more accurate than "closed".

Changing status to "invalid", more appropriate for the task as a whole (arguably I should've created a subtask for the package removal which is indeed "done" by now).

This is not a Freedom issue: It does not fallback-depend on any nonfree implementation but on the virtual package representing any implementation, so does not promote nonfree stuff (even at the stretched levels of suggesting or even mention).

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

User Agent sniffing is an anti-pattern - use feature detection instead!

From cross-report (link above):

Done

Please drop derived cron package: There is no need for deriving from Debian (issue is bogus).

This issue is bogus: It is correct for metadata to describe license as Artistic, but code itself is licensed "same as Perl" which means dual-licensing as _either_ Artistic or GPL-1+.

Possibly libunrar0 is nonfree in some other universe (or in ancient times?), but it is non-existent in PureOS as well as (contemporary at least) Debian.

https://appstream.debian.org/sid/main/issues/linphone.html (same issue on PureOS for sure).

I can use jitsi on my IceWeasel if I put comment the following in its vendor.js:

Cross-reported to Jitsi Meet: https://github.com/jitsi/jitsi-meet/issues/2147

I'd suggest just importing OVPN files with GNOME Network Manager.

I've been using the GNOME desktop for VPN access for a few weeks now. Running up-to-date PureOS-green on a Librem 15v3. Currently using openvpn 2.4.4, network-manager-openvpn-gnome 1.2.8, network-manager-gnome 1.8.4.

Package systemd resynchronized with Debian.

INFO: Imported 'systemd_235-2.dsc' to 'landing/main'.
INFO: Imported 'libudev-dev_235-2_amd64.deb libnss-myhostname_235-2_amd64.deb libpam-systemd_235-2_amd64.deb libnss-resolve_235-2_amd64.deb libnss-mymachines_235-2_amd64.deb libsystemd-dev_235-2_amd64.deb libsystemd0_235-2_amd64.deb libnss-systemd_235-2_amd64.deb libudev1_235-2_amd64.deb libudev1-udeb_235-2_amd64.udeb systemd-sysv_235-2_amd64.deb systemd-coredump_235-2_amd64.deb systemd_235-2_amd64.deb udev_235-2_amd64.deb systemd-container_235-2_amd64.deb systemd-journal-remote_235-2_amd64.deb udev-udeb_235-2_amd64.udeb systemd-tests_235-2_amd64.deb' to 'landing/main'.

Fixed with release 1:0.5.4.12-1pureos1 today (expected to enter gren within 24 hours).