that issue is not actual if I don't encrypt the directories.

Would it be possible to see a picture of this "@@@@" ?

The os-release thing already results in a neat "PureOS" string

@chris.lamb The os-release thing already results in a neat "PureOS" string, and the logo is being worked on: https://salsa.debian.org/gnome-team/gnome-control-center/merge_requests/1/diffs

FYI I got curious so glancing at the source code the image is "just" (har har) replacing panels/info/GnomeLogoVerticalMedium.svg and the text itself is currently populated by parsing /etc/os-release in get_os_info (panels/info/cc-info-overview-panel.c).

Ahhh, those silly tiny gnome scrollbars ...

@chris.lamb Scroll to the very bottom in g-c-c, click "Details" -> "About"

@wellton To me it looks like you are installing PureOS on an UEFI payload. This has not been tested at all and is not really supported. Are you using an EFI Payload for Libreboot?
What you can try is to run the Live session, and install the system from there with the Live installer - that might work (but has not been tested by anybody yet).

Has the control center "details" pane moved? Can't find it in the current version...

Thanks! FTR was very happy to do this if you didn't want to :)

@chris.lamb

Your remarks around upstream tarballs being ipso facto pristine is

also a little misleading in the general case, due to (at least)
Github's non- deterministic generatation of tarballs...

hello @heather.ellsworth , I`m using https://downloads.puri.sm/live/gnome/2018-05-30/pureos-8.0-gnome-live_20180530-amd64.hybrid.iso ,.. the same checksum. (I reported earlier.)

@wellton Yes, your issue appears to be due to using libreboot instead of using the image as is. I'm not sure what @mak 's plan for support of libreboot is going forward but for now to fix your issue, I'd recommend you use the https://downloads.puri.sm/live/gnome/2018-05-30/pureos-8.0-gnome-live_20180530-amd64.hybrid.iso as it is with no changes.

@heather.ellsworth What is wrong? Is it because of the libreboot? Can you fix that? 2018-01-20 works with libreboot.

This is completely valid packaging, and gbp will happily use it.
It's used inside Debian by a bunch of projects, most notably the
KDE/Qt packaging team.

@chris.lamb I don't really recall why I did that back then, but this is debian/ directory only style packaging with Git. This is completely valid packaging, and gbp will happily use it. It's used inside Debian by a bunch of projects, most notably the KDE/Qt packaging team.

Requested upstream make a new release here:

ah, my bad... we also got wifi chip from thinkpenguin that is suppose to work with bt but it actually doesn't (and @mak actually confirmed it is basically the same chip we use for our librems)

Sure. I can actually confirm:

Nope, it's not free: https://packages.debian.org/buster/firmware-atheros

In T23#8320, @mladen.pejakovic wrote:

How did we miss to load this firmware :-/

Because it is a proprietary firmware.

How did we miss to load this firmware :-/

@chris.lamb can you check this, as this is also the issue in upstream (Debian). How did we miss to load this firmware :-/

Actually it is not the driver that is missing but a free firmware for the AR3k Bluetooth chip used.
You can see the failed firmware load attempt in the kenel messages:

Thanks :)

@chris.lamb I thought this was related to T433, but it obviously isn't. But I know I have seen this somewhere before, most likely in community forums, I'll try to find the topic.

Cool. just checking we're all in total alignment and easier to frame as raw/bald questions :)

Does the *current* coreboot source package build a coreboot image?

@mladen.pejakovic Would be very interested to know the problem. Could you spend a brief moment trying to locate it, otherwise this information will be lost in time..

Does the *current* coreboot source package build a coreboot image? If so, it's going to be difficult to just update the utils and not the image itself..

how to do?

Yes, I know that, but I meant you don't need to build an actual coreboot image, just the utils that come with it.

Hi @chris.lamb . of course !! =)

The Tilix Git history, of course, But also the Debian package has no explicit patch (if it had, I should have noticed that as co-maintainer of the package ^^)
When I thought about this at first my intent was to only show the message if a feature requiring the VTE change was activated, but not immediately on startup.
As initial workaround, I added a gsettings change to PureOS default settings, but that only works if Tilix was installed first, which it isn't (so the gsettings override didn't really work, and I did not want to introduce a divergence of Tilix for PureOS).

(some changed to core)

the Git history

Can you please point to the commit that fixed this? I fail to find it in the Git history. Thanks!

Ah, I see:

Hello @chris.lamb , for now, it's only in the last version of screenfetch github, but it will not take long to update in debian and soon after in PureOS =)

@chris.lamb This turns out to be the same issue that was already fixed (but I cannot find it now).

@mladen.pejakovic Duplicate of what, sorry?

Customer reported that they cannot reproduce this after update. Closing as a duplicate.

I cannot reproduce this - am running 4.16.0-1-amd64 with no issues.

T450? I think I meant T292.

Hi @wellton! That is great news indeed. Is this in the version in PureOS now? Not 100% entirely sure of the purpose of this report/task at the moment :)

good news: Screenfetch supoorts PureOS =)

That was fixed three days ago already.
Thanks for reporting the issue.

Thanks for the clarifications - makes good sense to me now.

@jonas.smedegaard Yes. I will remove „fix“ from the title as it is confusing indeed. It supposed to mean that this out-of-tree driver needs to be rebased (is this the right term?) to the latest kernel, as it haven't been updated for a while.

@mladen.pejakovic Do I understand you correctly that packaging this driver is an improvement (for some of our users) over the byd driver provided with mainline Linux - but that mainline linux driver for BYD is not broken?

It seems the proposed out-of-tree driver has bells-and-whistles - i.e. enables multi-touch support and more.

Please elaborate on the reason this driver is needed.

Background info (thanks to Allison Randal): https://patchwork.kernel.org/patch/9424421/

This seems a duplicate of T52 - and related to T150.

Please elaborate on the reason this driver is needed.

@kakaroto Understand that but I think the confusion here is that the binary package you wish to use (ie. coreboot-utils here) is generated from a "source" package and crucially one doesn't — and cannot! — update binary packages directly. Or, putting it another way the version number is a property of the source package.

systemd 238-5 (Debian unstable)

Yes, it still is required (and it's not handled by the coreboot team). The source package might be 'coreboot' as stated above, but the binary package that I need updated is 'coreboot-utils'.
Thanks

@kakaroto Just to 100% check after private Riot chat; this ticket/update is still required?

This issue has been resolved.

I confirm I haven't been able to reproduce the bug after weeks of usage.

I think the issue was found and resolved and tests by Francois haven't been able to reproduce the problem, so i'll consider this done.

(Re-opening as, well, it's not really "fixed" in a meaningful sense to our users although it might be from a technical PoV..)

What version of systemd are you using, if any?

Hi @heather.ellsworth , Same 0426`s problem see the pictures below. I re-downloaded the iso 0530.

The md5sum of the 0426 and 0530 isos are definitely different:
452765b43d9223c7cb7fee6fbdf2357f pureos-8.0-gnome-live_20180426-amd64.hybrid.iso
7ffc352ba28b954922fe9d3739f8460b pureos-8.0-gnome-live_20180530-amd64.hybrid.iso

unfortunately, this problem still persists in iso 20180530.
I use Thinkpad T400 with Libreboot. The checksum is the same.