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.

emacs26 is not available in PureOS yet or in Debian. You can download it from here: https://ftp.gnu.org/gnu/emacs/

Here is documentation on how to build a PureOS image: https://tracker.pureos.net/w/howto_build/

I dont wanna to install emacs25... I Wanna emacs26.

Moving from private email to
[Moving from private email]

Please fix this!

Whoops, didn't mean to close this (just wanted to look for the exact terms used in there...)

This issue has a question as its title. Is the issue then "Resolved" when the question is answered? And should we tag it "Invalid" if multiple conflicting answers emerge?

From the file you posted I can see that USB appears to be working;

The parts in red are:

Well, before you do, issuing the command to show the kernel ring buffer might help us. Can you test with a USB device?

I will have to do a reinstall on my work system which I can do. I will try it on the L13 I have first to see if duplicate-able. I can't remember if I did dist-upgrade because apt-get upgrade didn't work.

touche’

If foobar v5.0.1 is stable and foobar v6.0beta2 is unstable, then what is foobar v4.2? And what is foobar v6.0+git20190304?

Omar, can you do a

sudo dmesg -w

then plug in a USB cable connected to a device known to work and put any error messages here?

How can something be "too stable" or "too unstable"? Isn't it kind of like saying you're too pregnant? Either your pregnant, or you're not.

updated, rebooted, and still no GUI. Confirmed that the changes are still in the file.

Below is text from my /etc/default/grub -- both lines are commented out. I will try uncommenting, updating grub and rebooting, then report.

Also, this will need to be uncommented;

Can you paste a copy of /etc/default/grub here?

Great that it works now.

I ran sudo aptitude install openttd and it installed and I was able to run the game. Just to be sure, I removed both openttd and aptitude and reinstalled just openttd using apt and that worked too. I can't pinpoint what has changed but it's working now.

Please try install using aptitude - in case that reveal more/different details: sudo apt install aptitude and then sudo aptitude install openttd

When I run apt-mark showhold, nothing is returned from that command.

I think that you can clear this up by doing;

The error message hints that held packages may be the cause.

I had no problem a month ago.

Seems this was reported upstream more than a year ago: https://bugs.debian.org/884372

This has been a problem since late last year. You may want to follow this tracking item.

This is very helpful @mak, thanks. I'll read up.

The problem is solved. It was a conflict with my virtual machines that was using the wifi network.

Looks like I somehow always ignored those issues when processing bugs, sorry for that!

I can do it, unless you are faster with it - it's a really trivial upload anyway :-)

In other words: Feel free to reassign to me for now if you prefer

Ah, sorry - I was wondering why I had "missed" to file this issue sooner, and your remark now hints that there was a good reason.

Can you check if this is still an issue? There have been lots of changes on the locale handling in the PureOS initial setup and installer.

No problem with processing delay: Had it been urgent then I would have shouted louder :-)

FTR, this goes together with https://github.com/systemd/systemd/pull/9864 where I am still waiting on feedback.
The current situation with localed on Debian is really suboptimal.

FTR, the reason for blocking nvidia-settings was "References non-free NVIDIA driver".
Package is removed from blacklist now.

Yikes, looks like this issue fell through the cracks completely, sorry for that.

2019-03-24 07:27:13 - INFO: Imported 'mate-sensors-applet_1.20.3-1.dsc' to 'landing/main'.
2019-03-24 07:28:21 - INFO: Imported 'mate-sensors-applet-common_1.20.3-1_all.deb' to 'landing/main'.
2019-03-24 07:28:22 - INFO: Imported 'mate-sensors-applet_1.20.3-1_amd64.deb libmate-sensors-applet-plugin-dev_1.20.3-1_amd64.deb mate-sensors-applet-common_1.20.3-1_all.deb mate-sensors-applet-nvidia_1.20.3-1_amd64.deb libmate-sensors-applet-plugin0_1.20.3-1_amd64.deb' to 'landing/main'.
2019-03-24 07:28:24 - INFO: Imported 'libmate-sensors-applet-plugin-dev_1.20.3-1_arm64.deb mate-sensors-applet-common_1.20.3-1_all.deb libmate-sensors-applet-plugin0_1.20.3-1_arm64.deb mate-sensors-applet_1.20.3-1_arm64.deb' to 'landing/main'.