re-closing this issue for now

Not related to T429a after all I think. I think I have a fix, just need to get back to my Librem machine to test.

Ah, wait, it *is* an unrelated issue: https://bugs.debian.org/897572

Or is this an entirely unrelated issue? Could do with some guidance here :)

Unfortunately, neither the udev rule nor the "setkeycodes 56 43" works for me. Any ideas?

I think it doesn't matter what keys you hit (as long as you press something) it will eventually timeout to some degree.

Re-opening. I just installed plymouth from green and it still has this behaviour.

https://github.com/systemd/systemd/pull/7826 is in our systemd

So, I can reproduce this. ctrl-alt-f2 actually seems to work for me (in the sense that it restores the gui prompt)

@d3vid Can you try Alt-F2?

This was not fixed in the above due to https://bugs.debian.org/898511 ("git repository missing latest 0.9.3-2 upload")

Fixed in https://code.puri.sm/pureos/plymouth/commit/c6c31458c6e485c559c1757efbd6187a132f4a60 (uploaded as plymouth_0.9.3-1pureos1_amd64.changes)

Thanks, although I mildly disagree that it's just cosmetic change given that it requires separate access with yet another set of credentials and ACL to maintain etc. etc etc.

Ah, it's on code.puri.sm. Getcha. Wfm now!

In T375#6988, @theodotos.andreou wrote:

https://code.puri.sm/Purism/Systems-Tasks/issues/58

https://lists.puri.sm/pipermail/pureos-project/2018-April/000000.html

• Vcs-Git,
• Vcs-Browser
• Maintainer
• Uploaders
• +pureos\d in version string

Is there tracking bug for gitlab migration? :)

(Apologies. I misspoke when I said *un*-encrypted; what I meant was "whatever less-secure method which would re-enable S2D)

Just out of curiousity, would it be possible to disable this feature post-installation? ie switch from encrypted to unencrypted?

@I_have_issues wrote:

:p

I think this is https://tracker.pureos.net/T292 ?

I think we could do two things here:

Split from https://tracker.pureos.net/T257

Renamed back and filed the 'default' issue as https://tracker.pureos.net/T364. These are two seperate issues AIUI.

Should be resolved in network-manager-openvpn_1.8.0-2pureos2 uploaded with urgency=high.

@d3vid Thank you for the update. I'm a little hesitant to package the latest upstream as Debian have not done it yet and we might be introducing *other* problems to our users. I will go ahead and add and push though. Stay tuned.

Fixed in initramfs-tools_0.130pureos1

*grin*

echo 1 > /proc/sys/i/care/about/freedom, huh? :)

@todd I worry this would be difficult to push back into Debian simply by hiding them as that would be somewhat of a poor experience for anyone who actually wanted to go ahead and install them. So, I wonder if we should add (or link to) a warning lecture about free software here , somewhat what like I propose in https://bugs.debian.org/888405. Thoughts?

• Matthias bumps urgency of the package

David Seaward wrote:

Previous upload rejected, re-uploaded which was accepted.

This should be fixed in network-manager-openvpn version 1.8.0-2pureos1.

Can we rebuild this package with this patch applied:

So, from PureOS's point of view, I wonder whether we should do any of:

Sure, but not with gdebi!

(w/no patches.)

Will do! Thanks!

/etc/resolv.conf is not created correctly on a clean install of PureOS

Okay but doesn't the resolv.conf have a big warning in it saying "do not edit this file"? :p

Ah, I was a little behind on updates. When I upgrade to the latest versions of packages (on my Librem 13v2) it fails to start. :)

I can't reproduce this:

Hm, I can't reproduce this: https://i.imgur.com/as3SNtc.jpg

Hm, I can't reproduce this: https://i.imgur.com/as3SNtc.jpg

Is this related to T292 ?

@tharvill Underlining this is not a (recent!) regression is helpful, thank you. I am fairly certain it's a somewhat structural problem with the Debian Installer generally which will require some work in Debian itself.

More work on this today. Got compiling going etc, and the "system-info" call works, etc. etc. \o/

Thanks. Have synced with debian-boot team on this..

This might be an evdev/libinput thing, but d-i does not ship (has has not shipped) with libinput, so there is possibly some hardware regression/change involved here.

This is stumping me at the moment, alas. Whilst the trackpad is being detected, it does not appear to be registering as a mouse device. Well, /dev/input/event5 is being detected as the touchpad, rather than /dev/input/mouse0 ("no input driver specified"). Not sure if that is even meaningful. X has -- unfortunately -- always worked for me in the past. Device exists in /proc/bus/input/devices as expected

I can reproduce this:

@blendergeek I need to package it but I needed to package (at least) two dependencies first, hence my updates and references to "NEW", etc.

@francois "OEM install" - you are using the downloaded ISO? If so, please give me the SHA1 of said image so we are working from the same version as there were some changes recently.

Both deps now in Debian unstable

dbus-cpp now in NEW

process-cpp out of NEW

process-cpp now in NEW

ITPs in Debian:

WIP on that is here: https://github.com/lamby/pkg-process-cpp

Packaging for dbus-cpp is here: https://github.com/lamby/pkg-dbus-cpp

@james.rufer Thanks for your response - as you can see from the recent history this specific issue is being resolved.

Yep!

Needs packaging. Am on it :)

Pretty certain this is the same as T293, so merging there!