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.

E: Release file for http://repo.pureos.net/pureos/dists/green/InRelease is expired (invalid since 16h 0min 45s). Updates for this repository will not be applied.

Resolved in the 2018-05-30 image, currently building: http://master.pureos.net/jobs/c1202f83-6ecc-47d7-831a-77f72baa8d0b

This will have to live in contrib, thus de-prioritising.

At the moment, apt-file is pretty useless on PureOS, due to the archive not generating a Contents file (or rather, an empty one).
I am not sure though whether it's worth fixing at the current point in time, because the dinstall runs are already really slow, extracting file contents will slow the process down even further.
So this will likely only get fixed when my patches to speed up the process and break it into smaller bits have landed.
Generating Contents is easily one of the most expensive tasks to do (I was under the impression that we were building valid Contents files though and even thought about disabling it - but apparently, it's slow already, even without building them (the archive never created Contents files))

Thanks. Split this into T456 as it's still open/unresolved :)

BTW, the bug is still present in the installer, but not after the user installs the updates. This can cause some users to think that their password isn't working anymore (enter a pipe in your password in the installer, do not click "show password" so you're unaware that you entered a > or a < instead, install the updates, reboot, password suddenly stops working).

Ok, I'll try revert my configuration to something default looking and see if I can isolate the issue. Please consider this low priority in the meantime.

Can't reproduce this, and have been locking/unlocking quite a bit.

just for the record, I guess you mean it was uploadd to landing, @chris.lamb

FYI qemu 1:2.12+dfsg-1+b1+pureos1 was just uploaded to green.

I have added my user to the kvm group but when restarting libvirtd, I got the following error :

Simple reason for that being that the utils are part of the main coreboot sources, and we only really want the utilities right now (packaging the rest didn't make sense to me, but it might at some point, at which we can easily add the other pieces to the existing packaging)

Whilst the binary package is coreboot-utils, the source package (ie. the thing we would update) is coreboot.

Note: package is coreboot-utils

Appears to be 4.16.0-1-amd64 related (see forum). Retitling bug to match.

I'll take it in that case. Thanks!

I wouldn't mind if someone else updated the package, but I also could take the task of course.

@mak Any new (non-system) users. (is that passwd/user-default-groups?)

Should we add any new users created on the system to the kvm group, or just the ones that were created by the installers?

@jonas.smedegaard That is because the package has binNMUs, and there is nothing we can do about this issue unless we rebuild all the packages for PureOS again and stop binary-syncing.
You can work around this by making a 1:2.12+dfsg-1+pureos1 upload.

We are currently up-to-date wrt Debian for flashrom. A request for a new upstream version has been filed here: https://bugs.debian.org/892065

Related to https://tracker.pureos.net/T450 ? :)

Can be found at https://source.puri.sm/pureos/packages/pureos-gnome-settings now

Anytime! Let me know the next time you need an adrenaline fix ;)

Thank you for looking into that so quickly!
I had some mild panic that something seriously broke and the automatic migration let broken packages into green.

Ah, my bad... something snuck in when I was adding a utility from sid!

I can't reproduce this here... The pureos-desktop package is a transitional package to pureos-gnome, is the latter installable? Can you get a better error message from APT? Are there packages from 3rd-party repositories installed?

This has caused the removal of gnome-control-center :/

In T448#7988, @mladen.pejakovic wrote:

It appears that this is already described in forums: https://forums.puri.sm/t/kernel-panic-after-recent-update/3171/

It appears that this is already described in forums: https://forums.puri.sm/t/kernel-panic-after-recent-update/3171/

https://lists.puri.sm/pipermail/pureos-changes/2018-May/000299.html might be the culprit, but I can't see how.

(Do we have any more info? For example, which packages were upgraded?)

Fixed in 3.27.92-1pureos2 and filed the default group request in T447.