@kakaroto This ticket is currently unassigned so it's not on anyone's radar. May I suggest assigning to @zlatan.todoric so that he can pass it on to whoever is free, etc.?

In T460#9044, @wellton wrote:

see ...

@mak Hi Make, how are you?

Can someone follow up on this ? That request says "it doesn't have huge changes but it would be nice to have it" is actually wrong since this v1.0 release actually adds Skylake support which is definitely a must-have rather than a nice-to-have feature. (At least for us).

♥ thanks

@kyle.rankin Just email your comments to 903163@bugs.debian.org ? :)

The point about it just being a shell script is valid. I would be perfectly fine with including this script (or a similar forked script) directly into cryptsetup-initramfs, especially if that helps speed the process along.

pureos is probably aware of it as there exists still the corresponding section in the troubleshooting wiki

(The one who fixed my laptop says:)

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 :)