@francois

actually, you'd want to change the link to use the latest commit hash, not master, otherwise the script will break again next time the microcode is updated. So instead use:
https://github.com/platomav/CPUMicrocodes/tree/956244154c87316e4e6162f02b17cf3547597b1a/Intel/cpu306D4_platC0_ver0000002**B_2018-03-22_PRD_0B0DD00D**.bin//

Merge request here: https://gitlab.com/lamby/osinfo-db/merge_requests/1

This issue affects everything using VTE, gnome-terminal is only exempt due to reverting an upstream change permanently via https://salsa.debian.org/gnome-team/gnome-terminal/blob/debian/master/debian/patches/Provide-fallback-for-reading-current-directory-if-OS.patch

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706065 for the Debian discussion about this on gnome-terminal and https://bugzilla.gnome.org/show_bug.cgi?id=697475#c43 for the upstream change that broke this in the first place, which VTE upstream won't change.
Also, the PR discussion has some more information: https://github.com/gnunn1/tilix/pull/1456#issuecomment-403175621

It's fixed now.

everything using VTE in Debian actually has to implement a workaround for this to work, gnome-terminal is carrying a patch for this for ages.

Checksum validation of 'main/source/Sources.xz' failed (5eb9cc2ccdf1bf16351400d06ae35d16089874d996c1afeab5b94179974051c2 != 56c51a31d6cc797891e0fa0b3112b7ffc7461819903664beddefcf565c742c0f). - the issue still persists.

@chris.lamb The proper fix would be to establish a new location for scripts to be sourced by shells even for non-login shells. At the moment, everything using VTE in Debian actually has to implement a workaround for this to work, gnome-terminal is carrying a patch for this for ages.

Currently blocked in Debian: gnucash unsatisfiable Build-Depends(-Arch) on armel: guile-2.2-dev

Assigning over for triage/priority :)

We can surely fix this annoying error without changing the Debian Policy (!).

The past sync run was interrupted, apparently because of connectivity issues (hashsum mismatch). This issue should resolve itself within the next few hours automatically - I'll keep this issue open until it does though.

Since upstream doesn't want this patch, we have no good way to resolve this.
I will discuss whether and how to change the Debian policy for sourcing files on first load of shells at Debconf, and if everything failes apply this patch downstream at Debian.

After playing around a bit I suspect the only reason why in Trisquel 7.0 both devices are initialized is that it uses an old kernel version (linux-libre 3.13), so the driver btusb is used instead of ath3k… Have a look at this commit: our bluetooth module (04ca:300d) is blacklistet in btusb and included in ath3k. I'm not sure but this could be a simple answer to the question why in Trisquel 7.0 the device is initialized but not in recent Debian versions / PureOS / …

Fixed.

This should be fixed - can you please verify that the issue is indeed resolved for you?

I received the module from thinkpenguin – and it's really a different QCNFA222… But yesterday I wasn't able to get it to work with Trisquel 7, it behaved the same way as our module (which is built in the Librem 13): the bluetooth device is initialized without the firmware but I can't find my other bluetooth devices to connect and when I set the device to visible I can't find it with my other devices.

The issue is known to the system: https://master.pureos.net/depcheck/green/binary/amd64/details/libkf5filemetadata-bin/5.45.0-1

Sure, I have no idea how you guys do things, so I'll just assign it to zlatan as suggested. Thanks.

@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.