@chris.lamb Gives me an error 404...

This is now here: https://source.puri.sm/Purism/Systems-Tasks/issues/58

not solved yet, I'm newbie with Linux/Debian so I try to figure it out how it works these 'partitioning thing'...

I too can no longer reproduce this. The "grayed out" section is no longer there and changes can be made. This can be closed.

A quick update:

… and after some testing.

Done. Sorry for taking a bit longer with this, I was traveling yesterday.

I removed the repo, but you do have "Master" permission on the whole PureOS project - not sure why you couldn't remove the repo...

Reviewed packages from Zhu on mentors.debian.net

Fixed in https://salsa.debian.org/lintian/lintian/commit/fa0de8203b53981c514f64ff0dd212386b31543a

I have now tried using both Arch Linux and the latest Ubuntu installer in addition to Qubes OS, but I still have not been able to get a 4K resolution on a Librem13 laptop (ordered in January 2018).

Hi QiZhi, I'm also seeing this problem. Have you been able to find a solution yet?

https://bugs.debian.org/901130 modules

Reverted in https://salsa.debian.org/lintian/lintian/commit/05d705ff4e2175295d998cf304e5992709fbf7bd

https://bugs.debian.org/884797#34 Shengjing Zhu will take over this in Debian. Have offered to sponsor.

Fixed in Lintian: https://salsa.debian.org/lintian/lintian/commit/a1564876037e3e9e6d3fdf8fdceccec40fc85ffa

I cannot reproduce this - I can edit my computer's name here (it is not greyed out)

heh, beaten by @chris.lamb :-P

Reported in Debian: https://bugs.debian.org/901035

This is being tracked in Debian at: https://bugs.debian.org/901035

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.