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.

My apologies. The username is pureos and there is no password. :)

Fixed in 1.7.9-1 which is now in PureOS green. Enjoy :)

I tested it too, it fails again.

@chris.lamb Tested it. It's wrong login.

The issue was caused by allowing an openvpn-based vpn to start automatically on boot. The vpn config file ran /etc/openvpn/update-resolv-conf which ran /sbin/resolvconf (or exits if the resolvconf package is not installed). So in the case where the resolvconf package is not installed, there is no problem if you boot the system and stop the vpn. However, the resolvconf package was causing the default nameservers to be 192.168.237.*

Thanks!

This is the output from GNOME Boxes:

I use Debian unstable on my laptop.

Yes, it works, it's now building properly. thank you very much for the soooper prompt fix!

@Uhino Could you try "user" with no password?

Fixed for a while already, I forgot to close the bug report.
Thank you for reporting the issue!

This should be fixed now (and ideally won't ever break again).

This has been resolved for ages now, thank you for reporting the issue!

It's fixed, and tested. Make sure you delete the flashrom directory so it gets checked out cleanly (rm -rf coreboot/flashrom/) then retry, it should work now.

I get the same problem when i tested in virtualbox. Try'd multiple username and password combination but no luck. What is the default login?

Yes, it's a library dependency (libusb) while flashrom is being compiled by the script. It's unrelated to the kernel (though the kernel also uses libusb and is affected by the same issue).
It looks like this was fixed in flashrom 11 days ago and the commit is here : https://review.coreboot.org/cgit/flashrom.git/commit/?id=291764a70e6d8b212680e311bfb0825abf2b9a2f
I'm now testing it and I should have it fixed and the script updated within the hour.

thanks for looking into this @kakaroto, the error is popping up while building the coreboot from your script, so would it not be an issue with library dependencies installed ?

I don't think the patch to the kernel is relevant here since coreboot has nothing to do with the linux kernel. I think the patch needed has to be on the flashrom project itself. I'll have a look and see if that was recently fixed upstream, then I'll update the flashrom we use in the build_coreboot script, and test it.

Heh, you must have missed see the oodles of scrollback on Riot me begging folks to open a suitable number of issues, whichever they are? :p

(just for the record: @chris.lamb in a chat discussion I was unaware of the existence of T439 and possibly Kyle was too, since our discussions was on whether it would be sensible or not to _open_ an issue regarding UK keyboards or maybe better to instead use a wiki for that.)

@heather.ellsworth wrote:

the problem is that PureOS induces the use of private extensions because it uses the Mozilla store. and this is pretty bad (see the pictures below).

@heather.ellsworth Thanks for providing input on chris' keyboard issue - but since that is *not* a US keyboard it confuses matters to share that info here. Perhaps discuss with @kyle.rankin where to put your info as he has some ideas on where to most appropriately put it.

Hmm.. so I have been running a script just after reboot that does some post startup things, including setting the keycodes. If I disable the running of that and reboot, then it appears that my keycodes are magically working again and I have no idea when this started working.

Hmpf, looks like we are detecting it fine and applying the correct keyboard_key setting (note KEYBOARD_KEY_56=backslash). Any other developers with a US keyboard lurking here?I have a UK keyboard so am now a little stuck :)

My systemd version is 238-4

My systemd version is 238-4

@heather.ellsworth Thanks for that. So, you shouldn't have to do that .. can you clarify which version of systemd you are running? Please run apt list systemd

Sorry for the late reply. I have a L13v2 with a US keyboard. After I reboot my Librem, I always do sudo setkeycodes 56 43 and that fixes the issue.

I spoke with the cryptroot maintainers in Debian and they are planning a bit of rewrite within the next week, so I won't immediately work on this as the patches won't apply.

@chris.lamb Ah, okay, makes sense. :) Sorry, retitled now.

@mladen.pejakovic Was asking you to retitle as you are the one who knew/knows the status of this. :) There's been enough confusion and/or missing info already, I don't want to add to that by an inaccurate naming.