webrtc progress: https://blogs.gnome.org/tsaunier/2018/07/31/webkitgtk-and-wpe-gains-webrtc-support-back/

That's because of the 'su $user' command that's in there. Root doesn't have to type the user's password but a regular user (even the same user) does.

Hi @jeremiah.foster and @mak , I downloaded iso 04-22 (pureos-8.0-gnome-live_20190422-amd64.hybrid.iso) from link and not working.

At least I haven't partitioned the USB drive. :}

Yes, ENV{ID_VENDOR} is what we'd want, as ID_VENDOR is being set in an environment variable that gets passed along to these udev rules. I was just flagging that in your udevadm output it had set ID_VENDOR (via ATTRS{ID_VENDOR}) to Nitrokey.

The script does work when it runs by itself (always worth asking :-)

Based on this:

The format of the udev rule in the file itself may be the issue, I'm still trying to determine. Nitrokey offers packages: https://www.nitrokey.com/download/debian I'm going to see if they provide any inspiration.

The udev rule doesn't work in either machine; neither the L13v3 or L15v3. With regard to identifying the device, I'm included dmesg output (which I've not found super helpful) and udevadm output (which is better.)

So to get this straight, the udev rule works with your particular Librem Key on one laptop but not another? I wonder if for some reason the ID_VENDOR value changed from "Nitrokey" to something else in newer revisions of the Librem Key.

The rules file is in the right location (/etc/udev/rules.d) and it gets read according to systemd-udev:

Apr 23 10:02:36 slate systemd-udevd[386]: Reading rules file: /etc/udev/rules.d/85-libremkey.rules

The gnome-screensaver-lock works well. I cannot get the udev rule to be discovered on my L15v3 however. There is some information on this available on the Nitrokey from upstream where they publish their own udev rules but that fails to work for me as well.

@jeremiah.foster Please (not only update description but also) make a comment elaborating why you consider DuckDuckGo is really tracking users.

Eww, I don't think I have addressed this yet. Thanks for the issue report!

There is a new version of Calamares out and I wonder if this is still an issue? @hayder could you let us know if this bug is still open?

Thanks for reporting this issue. There is another new build, can you try that one: https://downloads.puri.sm/oem/gnome/2019-04-22/

Wow, what a marvel. now it worked 100% in ISO 2019-04-19. thank you.

emacs25 seems to only exist as a transitional binary package to emacs-gtk in PureOS:

emacs25    | 25.2+1-6+b2   | landing    | arm64
emacs25    | 25.2+1-6+b3   | landing    | amd64
emacs25    | 1:26.1+1-3.2  | green      | all
emacs25    | 1:26.1+1-3.2  | landing    | all
emacs25    | 1:26.1+1-3.2  | purple     | all

There appears to be some cruft in landing, but that has a lower version number so shouldn't be easily installable.
Are you sure this is still an issue?

Raising priority, since a package without security tracking from Debian for a year is bad!

Seems emacs25 was dropped a year ago from Debian but is still lingering in PureOS, and I guess then also blocking the more recently introduced emacs (without version in package name, currently containing version 26) to enter PureOS at all.

Working on adding an entry into the PureOS wiki about this. Thanks for your work EchedeyLR.

I'm not sure what vboot is, but if we're talking about Intel Boot Guard, it's my understanding that requires physically blowing fuses within the CPU, that then only allows signed UEFI to actually boot/run.

I can reproduce this here. The timezone shouldn't actually cause any problems here, yet the Release file was apparently signed and piblished with a timestamp in the future to your system. Very strange. There is no unusual behavior going on in the archive as far as I can see.

This issue resurfaced. Noticed it by running an update at around 00h10 Central European Time

The database connection got a bit messed up due to parts of the infrastructure rebooting.
Should all work again now (and soon even recover better from issues like this when the new software is in place).

librem5-devkit-tools_0.0.2_source.changes: misses mandatory field Binary
How was this source package built exactly? The Binary field needs to be present in .changes file in order to be processed.

This is not a bug in the archive. Source-only uploads are allowed, but the .changes file of this package apparently misses the mandatory Binary field and is therefore rejected. Not sure what caused this though, there might be an issue in the packages' build process somewhere.
See https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-binary for more info on the missing field.

I've reuploaded the same package I uploaded on jan 3rd. source package is librem5-devkit-tools.

I changed the line to GRUB_CMDLINE_LINUX_DEFAULT="quiet" and then ran "sudo update-grub" This seems to have sped things up, boot does not seem to be hanging, but I unfortunately can't quantify this. I still don't see the splash screen for disk encryption, and decided to go back and double check my grub.cfg file. Strangely, the "splash" parameter has disappeared from the "vmlinuz" lines of the file, so that may be why. I have three "vmlinuz" lines in my grub.cfg file, under separate/nested "menuentry" commands. It looks like this:

Rebuilding sure avoids some (possibly gazillions) edge cases. This issue is about something else, though:

Attempting a sync, seeing it fail and then needing to do a manual rebuild is not efficient and can not be reliably automated. Attempting a sync which works but has a decent chance of introducing breakage which can be avoided by a rebuild is not wise.
By always rebuilding packages synced from foreign suites we get a 100% automatable process that saves human work and avoids the introduction of errors due to binaries being built in the wrong environment, even if they are rare.

Sorry, I don't follow what is so definite. Why do we not - by the exact same logic - "definitely" need to rebuild all the packages that we grab from testing?

@guido The package doesn't exist in our repositories anywhere, and I could fine no trace of it ever being uploaded. What's its source package name? Can you maybe just upload the package again?

Can you elaborate on what kind of "subtle incompatibilities" you consider rendering it "definitively not a smart idea" to let Debian unstable packages into PureOS?

Its is NOT RESOLVED.

Hello, you is wrong! The emacs 26 works in Debian Testing (PureOS's base). See the picture.

Other possibly interesting stuff:

uploaded mfgtools_1.2.91+0git6b465-0pureos+librem5.1_amd64.changes

The corresponding source package (librem5-devkit-tools) was uploaded but the librem5-devkit-host package did not make it into the archive. @mak did some investigations on why that happened but I don't think there was a clear outcome.

It is complex, I agree. The screenshots help alot. I don't think that your swap partition is in fact encrypted. One way to find out for sure is to issue this command;

I experience that behavior on occasion as well. I'll try and do some debugging since I'm interested in understanding if there's a fix.

I also see the issue described by @soapergem. Today I updated to a new kernel:

can I just change the current line to
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
What is the implication of having two "resume=" targets?
The device after "cryptdevice=" is not a UUID listed in fstab or any of the partitions/filesystem shown in the disks app, but may be an alias for the main filesystem? The first "resume=" and the "root=" are followed by what is in the "Device" field of the main filesystem in disks, while the second "resume=" (after "splash") is followed by the UUID of the swap partition.
I find this all a bit hard to follow, sorry. Here are screenshots of the partitions...

cvt 3840 2160 26 also works for me:

Related Librem 5 feature: https://source.puri.sm/Librem5/use-cases/issues/25

1. You have two "resume=" targets. The UUIDs differ too. You may want to compare the two resume target disk UUIDs with what you have in /etc/fstab to make sure that the last resume= is even needed. You can use the 'disks' tool to do this.

Here's the actual file{F254246}

That last may be the problem. I hadn't noticed before, but that line is truncated because it is so long, and didn't copy correctly when I looked at grub before.

I forgot to mention that the broken version of uuu is:
Version: 1.2.31-0+pureoslibrem5.2

Can you re-paste your

/etc/default/grub

file? I don't see any mention of your encrypted disks for example. I worry your grub configuration may have become corrupted somehow.