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.

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.