Fixed in pureos-security-hardening 0.0.1.

Fixed in pureos-security-hardening 0.0.1.

Fixed in pureos-security-hardening 0.0.1.

yes, that package name sounds perfect!

@kyle.rankin Can you provide any input (on the Debian bug preferably...) on the response from Guillem here: https://bugs.debian.org/903163#10 ? Thanks!

Another firewall alternative: https://www.opensnitch.io/

Also suid_dumpable

Alternatives to the subgraph firewall might include https://douaneapp.com/

ITP bug filed here: https://bugs.debian.org/903163
Initial, untested packaging here: https://salsa.debian.org/lamby/pkg-gpg-encrypted-root

This should reappear soon:

Patch created: https://github.com/gnunn1/tilix/pull/1456

Subject: anbox_0.0~git20180612-1_amd64.changes ACCEPTED into unstable

This is definitely not fixed yet, I'll look into this again.

I happened to see the last posts scroll by....

The useragent flag changes, well, the user-agent. And only that.

It appears the compatMode boolean no longer resolves this issue (tested with the uMatrix link above). I'm not sure what has changed, possibly AMO now requires a newer version of Firefox?

Yes, there was a typo. :)

(Diff of description appears to be:)

Thanks for the ping and this is good to know; can prioritise this over some other things on my radar :)

Just checking in on the status of this ticket. We are not yet at a place where this is blocking other activity but will be within another week or two.

Ok, I am convinced with doing option 2.

@zlatan.todoric I made pictures of the module in my Librem 13 v3 (see below). I didn't recieve the module from thinkpenguin yet, I'll send pictures as soon as I receive it.

@mak can you take pictures of our and the ordered module? Also mak can elaborate more as he has the one.
@stefannagy can you also attach images of module you ordered? Trisquel having something and Debian not is of interest to me (adding also @jonas.smedegaard to maybe try and track what is the difference).

That's pretty interesting!
It might even be that the "firmware" actually isn't real firmware but rather a set of config options. I have seen something like this for CSR based Bluetooth chips too. The settings would then also control the WiFi/Bluetooth coexistence which is probably the reason why it does not work w/o the blob in the Librems - the antenna switch does not switch it to the Bluetooth chip without it and thus the BT does not "see" any other devices around.
According to kernel sources our device is a
/* Atheros AR3012 with sflash firmware*/
The firmware it loads consists of two parts:
ramps_0x11020100_40.dfu
and
AthrBT_0x11020100.dfu
The "ramps" file is sysconfig the second is a RAM patch file for the in chip flash firmware.

People from thinkpenguin.com told me that in fact not all Qualcomm Atheros wireless combo cards require proprietary firmware for bluetooth to function. But with current distros you won't even notice that you have a card that doesn't need the firmware since the kernel wouldn't try anything without it… If you don't make the firmware available the driver (and not the firmware loading mechanism) will be disabled.

Interesting, I wonder what caused network-manager-openvpn-gnome to not be installed on my new system... Ah well!

Done, I moved everything away from Github a while ago.

@d3vid Yes - although technically, you would also need to check the recommends of the whole dependency tree that pureos-gnome (or any other package) depends on.
If the package is in the Depends line, you will have it regardless of whether the installation is new, if it is just recommended it might only be present on new installations.

Thanks for confirming that @mak , much appreciated!

I just generated new images, network-manager-openvpn-gnome is preinstalled on all of them ([installed,automatic]).
I therefore think it's safe to close this issue.

@chris.lamb That it's in recommends just means that a user can remove the package.

This is resolved in debootstrap >= 1.0.104pureos1 now.
You are now able to bootstrap purple and landing based on a revised green script.

@guido Ubuntu's scripts have a less-generic name though - that's why debootstrap in Debian has "green" and the Tanglu distribution names ("chromodoris", etc.) but not "staging" (Tanglu's equivalent to "landing") - I assume the same will be true for the generic landing name.

NB. this is an external, USB adaptor.

Assigning @mak (in the first instance) as it's installer-related...

Linking the .dev.0.fw to .4.0.fw apparently can work but there is an issue with NetworkManager using random MAC addresses that prevents associations:

I have the same trouble in the installed system. I've installed firmware-ath9k-htc; this has an htc_9271-1.dev.0.fw blob and also puts this in /etc/modprobe.d/ath9k_htc.conf:

options ath9k_htc use_dev_fw=1

however, the kernel is looking for htc_9271-1.4.0.fw and fails. I've tried linking the .dev.0.fw to .4.0.fw but it doesn't seem to work.

This problem seems to specifically point to the installer not changing its own active locale during the install process, but merely setting the default locale for the install on disk.

Check the Depends and Recommends of, for example, the pureos-gnome packages (and similar).

@mak I've been meaning to file this issue for a while, so it could be the update happened between my last install and me actually filing the issue. Since you've confirmed it I'm happy to close.

Works. Seems to have been fixed by a recent update, defaulting to java to jre10?

Hmm, this is a tough problem to solve. We can not really make a purism-specific seed for default packages. We could enable Purism branding on specific installs though, in which case the existing seed would always need to install Purism branding though (even if it is not shown).

I assume this is resolved.. as in, shorten your hostname? :)

(renaming to reflect underlying issue as I understand it.

Unless you are suggesting we upload the 'experimental' version directly to PureOS for now?

@mladen.pejakovic So, GNUcash was removed from the Debian "testing" repository and it is thus not in PureOS. There is, therefore, nothing to backport against!

https://bugs.debian.org/901134#47 further movement FYI

Ubuntu's scripts (/usr/share/debootstrap/scripts) are also in Debian. Would be great if the same were to be true for pureos since that would tickle to all downstreams and enable many more people to contribute without hazards.

@mak, go forward with this implementation so contributions and work of phone team becomes natural within pureos :)

In that case network-manager-openvpn-gnome was definitely not installed on my new system (installed 2018-04-26). :)

@chris.lamb I didn't misread the report, I just mistyped the package name (fixed). The statement in itself is still true.

@mak I fear you have misread this bug report. This is about network-manager-openvpn-gnome, not network-manager-gnome.

There's also tools like vmdeboostrap that invoke deboostrap / pbuilder directly. It would be much simpler if they could work out of the box.

No, with the new installation there can't be a kernel mismatch anymore. The problem here is that Libreboot is run with an UEFI payload which boots into an (unsupported) EFI mode of the live-cd, which still offers a debian-installer install option.
See https://tracker.pureos.net/T460 for reference.

@chris.lamb No, if network-manager-openvpn-gnome is in the list it *will* be installed, unless there is something else pulled in that is mandatory and conflicts with the package.
It will not be explicitly seeded if it is pulled in by another package that is also seeded.

This has nothing to do with Plan. You just happened to hit/see it whilst installing Plan.

IIRC, we had a couple different customer questions about Steam functioning under PureOS, and even though I knew it wouldn't, I thought I should test so as to not tell them wrong. In other words, don't test on your production machine ;)

@james.rufer (any reason why you added i386?)

oot@librem15v3-enterprise-pureos:/home/james# dpkg --print-architecture
amd64
root@librem15v3-enterprise-pureos:/home/james# dpkg --print-foreign-architectures
i386

Just went to do this but network-manager-gnome-openvpn is already in the list of Recommends since 31 May 2017 and crucially is actually on the same level as network-manager-gnome. Thus, whatever installed network-manager-gnome via the recommends system should have also installed network-manager-openvpn-gnome for you.

@kyle.rankin wrote:

And your smb.conf please! Sorry, not sure why I didn't ask before given that the error message clearly says it is "invalid"

Odd thing is when I went into the menu to open another application, "Plan" and "Plan Work package" are now installed

PureOS never had Chrome package in its archive and Chromium is now removed and blocked as well.

@zlatan.todoric This is my only source

Fair enough, but there are two mentions here, and chrome is a package which is installed through the package manager. Any thoughts on font issues there?