Looks like this is a wipefs error. Needs more investigation.

it's worth questioning our assumptions in cases like this, and luckily I had just been in a discussion about this very thing with a PureOS user, looked up the policy, and can't find anything restricting us from doing that. I will contact Mozilla on Friday trademark-permissions@mozilla.com if there are no objections, but it's best to let this sit for a while.

+1 for rebranding to Firefox, I didn't know that was an option :)

copypasta from my comments in a Matrix room, but TL;DR let's just rebrand it back to Firefox, I'm pretty sure Mozilla will give us its blessing to do so.

@mak Can you have a look?

Did an upgrade and rebooted, it still reports 239-7pureos1.
Is the new version already in green?

Thanks. What you need to do next is:

Here's the output: 239-7pureos1

Hey @hasolo, sorry for the delay in replying. Can you let me know exactly which version of systemd you are using? You can do this with:

I will try to reproduce this.

Okay, if your hosting plan does not offer SSH, then as you say SFTP (and also SCP which is secure copy and uses SSH for data transfer) won't work. SSH is likely more secure however if configured correctly but perhaps you have no control over the plan your ISP offers you.

This is not (by our definition) a freedom issue: It does not involve installing non-free software locally.

This is not a freedom issue (by our definition), since it does not involve installing non-free software locally.

This is not a freedom issue, since it does not involve installing non-free software locally.

This is not a freedom issue, since it does not involve installing non-free software locally.

@mak ping!

@mak ping!

@mak ping!

Please drop forked package now, @mak

@mak ping!

@mak Ping!

thanks @sriram.ramkrishna! slight tweaks that make these more OS-agnostic and (hopefully) future-proof:

Here are two screenshots of etcher.

Thank you for your reply.
I don't know for SFTP (SSH File Transfer Protocol) because my hosting plan doesn't include this option so I can't test it or use it. FTPS is different: this is FTP over TLS/SSL (so basically a secured regular FTP). I don't know SCP.
Yes I didn't catch all the implication of these GnuTLS/FileZilla issues and as you said I think this should be dealt with on the FileZilla side.
Should we raise this to FileZilla dev?

Thank you for your reply. How can we upstream this issue?

See https://lists.puri.sm/pipermail/pureos-project/2019-January/000015.html for an explanation. The new image just needs to be tested and the download webpage updated in that case.

Just for clarity, you're pointing to the fact that the PureOS download page (https://pureos.net/download/) has an older ISO image which the downloads page you pointed to (https://downloads.puri.sm/live/gnome/2018-12-10/) has a more recent ISO release?

I will check and get confirmation.

Thank you for this report. I believe that this should go upstream into the Klavaro software itself

I don't think this is related to PureOS packaging because we tend not to change upstream Debian packages except where necessary. I'll take a closer look, but I don't really understand the key issue. I see that libgnutls is going to change, but will that fix the problem? It appears they're only going to turn it into a no-op, so won't we need a new FileZilla that brings back in the functionality somehow? What about other protocols like SFTP (or is that the same as FTPS?) or SCP?

Merged upstream and fixed locally in:

Thank you @hethi , I opted to remove command-not-found until there's an update to fix its behavior. For anyone who may come across this issue and would like to remove it:

If you add e.g. Debian to the apt sources, e.g. cause you need some Debian non-free package which of course is a bad bad bad thing on PureOS, you get some Contents files which were mentioned above - then a commands.db will be created, but for these Contents files only. I.E. the command-not-found will tell you Debian packages only which contain the searched command, but not PureOS packages. Not really what you want.

My apologies, I have no idea where I got that number. I reviewed my own hand-edited file and it says "backslash"

it's the value that we used for the other entries that were already in the file

Is there a workaround or manual way to fix this issue in the meantime?

This is the value I used and tested, and it's the value that we used for the other entries that were already in the file. If we were to change it for this case, we should also change it for the other, previous Librem 13 entries.

the value on the right side is supposed to be a key name. Shouldn't this be something like KEYBOARD_KEY_56=backslash instead

See also https://dev.getsol.us/T6371

Upstream PR filed here:

Yes, this should go upstream like with the parent issue. I have tested this fix against my Librem 13 v4.

@kyle.rankin Thanks for filing this. Should this also go upstream?

Is it possible, that it's fixed on US and UK layouts, but on DE not?
Still have this issue...

Very happy to take this. Indeed good call -- can you create a new, Librem 13v4-specific ticket for this and assign it to yours truly?

If it's better to open a new ticket than comment on this one that's fine, but having all the context of this ticket is useful. We now have a Librem 13v4 and so need to modify the same systemd files to add:

Impossible to continue with owncloud-client.
I have a message : incompatibility wtih Nextcloud server 14.0.4

Will do! I've used both in the past, but found GBP's branching model confusing. Jonas and Matthias have recommendations so I hope to find something that works. :-)

Ah, getcha. In that case, I suggest you checkout pristine-tar and the whole gbp-buildpackage flow in general. That will mean you have both worlds with no compromise. :)

Sorry, I haven't included my debian/ directory yet. I wanted to include a 'pristine' source. Of course I have added a patch, so it isn't pristine, but I wanted to get the source into salsa since there seems to be some movement with the ITA bug in Debian's bug tracker and hopefully we can all work with the same source.

Hey @jeremiah.foster I don't see your other branches, or I don't understand where your debian/ directory is..? :)

Since I haven’t received a response yet:
I went ahead and installed PureOS inside a VM. Can someone on the dev team point me to the necessary repos to build a new live disc? I’d like to try to modify the ISO disc with the changes I need.
I think I need these, but not 100% sure:
https://source.puri.sm/pureos/infra/make-live
https://source.puri.sm/pureos/core/live-build

Looks like you're booting the Purism Librem 13 v2 with a 4.17.0-3 Linux kernel. I'll see if I can find a machine to reproduce that error. In the mean time, would you try and boot from the latest live disk? https://pureos.net/download/ Instructions are here: https://tracker.pureos.net/w/installation_guide/live_system_installation

I've uploaded lastest flashrom code to salsa on debian.org; https://salsa.debian.org/jeremiah-guest/flashrom
Next step (happening now) is to build the package for PureOS and then share any useful artifacts with Debian maintainer.

It's FOSS. There is a problem with that tag.

Thank you everyone. Please re-open if you see any issue related to this at all. I appreciate all the work done on this issue and the high quality communication from everyone! It is quite satisfying to close this bug and I hope we can continue to resolve issues. Okay, enough of my blather.

Fixed on my side as well. Thank you.

Please read my post prior to Jonas's. If @user22492 does not comment by Friday, I'll close this. I was giving him a little time.

It's still on my todo list, but with a low priority, so it pretty much is at the bottom of the queue every time something else of higher importance is added.
Since we have AppStream and this feature isn't one of the most popular ones, its priority is low.
However, it is fixable and I intend to do so when the infrastructure redesign is applied.

I think we can close this, but I'd like more input from the original poster.

This is an ancient bug. I think we should move it to "won't fix" or try and fix it.

This is a known issue unfortunately; T155 I'll see if we can't update the status of that bug to solve this issue.