The "Application menu" extension it works now. I have read that it does not work if you disable "hot corners" on "tweak". Now i am going to disable the extension and reboot to test if "Applications" name it appears again. (They appears after disable but i have not idea if they would appears after reboot)

I read this in a review:

The "Application menu" extension error was reported by some users days ago here: https://extensions.gnome.org/extension/6/applications-menu/ but i did not read about did not appear the name after this.

This issue seems to be triggered when I switch from one application or desktop to another, after I've woken up from a sleep/hibernate.

Thanks a lot for testing and reporting this, @francois!

The problem has now been fixed on my side with the new version of qemu (now on green). I can run a virtual machine without any problem.

Updated!

FYI for all subscribers - the Tor Browser downloaded from PureOS repos hasn't worked for anyone over the past 6-7 months. To use the Tor Browser, we all have to download the package directly from their website. It would be great if this could be fixed in the PureOS repos so everyone could easily download and install the Tor Browser Bundle using "Software" in PureOS. See the following threads for more on this:

People from thinkpenguin insist on that their card works with Trisquel 7 – and that if it doesn't work for me it has something to do with my system ("USB controller related problems/USB hub issues/or whatnot").

This is now "fixed" in PureOS, or worked-around rather.
I hope to maybe be able to address the actual issue at Debconf.

I've uploaded a new revision of Tilix with my patch to Debian: https://tracker.debian.org/news/973587/accepted-tilix-181-1-source-all-amd64-into-unstable/
Let's see if this sticks. Regardless of the workaround, we should still work towards fixing the actual issue, because that will not only benefit Tilix, but also GNOME Terminal and any other VTE-using app.

I fixed it by using the old commit hash for the previous microcode. I didn't want to update the microcode since that would mean changing the version (so, changing the config, adding a new tag, rebuilding all, changing coreboot final hashes, changelog, etc..) and I'd like to do it later when I update the FSP for the skylake ones as well, but that one needs testing first and I wanted this fix to be out asap.

Humm.. I thought that repo was meant to contain an archive of all microcodes, I didn't realize he deleted old ones when new ones are out.
I'll update the link and use the commit hash, I prefer that than having the script break constantly.

Given that this is a) the default terminal and b) is *horrifically* ugly, this is giving new users a truly terrible first impression. :(

I was able to reproduce the same behaviour I see in Trisquel 7.0 with the card I got from thinkpenguin (with bluetooth module 0489:e076) – device is initialized but not usable, see above – with a recent kernel (Linux version 4.18.0-rc4) by reverting this commit. I'm quite sure I get the same result with the combo card I got with my Librem 13, but I don't want to change the cards too often… I'm afraid to fret the antenna connectors…

@chris.lamb The only thing we would need to do is get https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675008 fixed in some capacity, no policy change is required - unless we do end up sourcing /etc/profile.d/* for non-login shells like Fedora, in that case we need to change policy I guess.
If we want to establish a new directory for that purpose, we can also do so and add it to policy later. It ultimately all depends on that bug report.

the time we can expect to wait until fix is applied upstream

Considering that we target everyday users, and this affects the first-time experience of our default terminal, is it feasible to maintain a patch/fork of Tilix until the proper fix is applied upstream?

So, the official bug report to watch is now this one: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675008

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