I've tested the image and seen that it works. Uploading to the download page is a separate discussion and should probably wait until we've tested the OEM image. We can close this bug however by stating that there are two locations for new images, one is a directory that just holds the output of the build system, the other is the official, tested download image.

Thanks for mentioning, @guido - I had missed T594 now linked here.

Tracking fast-changing packages in particular need strong monitoring e.g. by somthing like security-tracker.debian.org.

This is also related to https://tracker.pureos.net/T594

in a binary .deb package you don't want your source control tool cruft left inside

That was a bit cryptic, sorry. I mean that in a binary .deb package you don't want your source control tool cruft left inside since it is extraneous and doesn't keep the original upstream source pristine. But, at the same time, you do want a branch that contains the debian directory since that is where the control file and other debian files live which give instructions to the final binary. The consequences are that one has to jungle many branches and to make sure you're on the right branch when you call gpb. Or perhaps I haven't got the hang of it yet.

I can confirm that the suspend/resume fix works

@jonas.smedegaard sure, the new title makes sense to me.

I find that expressing tickets as what is wrong helps.

@jeremiah.foster: No, this ticket is explicitly about the functionality, not branding of it!

package without .git and with debian/

Indeed. I used gbp to package flashrom for PureOS and will use it to package some other firmware. I still find the combination of git branching and Debian packaging confusing especially when one wants to package without .git and with debian/ :-|

ps. Worth learning git-gbp as, well, "most" of Debian uses it these days so you'll bump into it whether you like it not. :)

Nice work!

New Debian maintainer: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919434

Well, as we discussed in https://tracker.pureos.net/T688, we want to get rid of the PureBrowser branding anyway.

flashrom 1.0 is in our repos but is not available yet. Will check on what the hold up is.

For clarity, you mean adding a stable Firefox with its own branding and without any changes to defaults, right? This shouldn't be an issue since PureBrowser would be the default and Firefox would require installation by the user.

I received an update from the coreboot team regarding this problem. It apparently is not a PureOS issue only, it affects other OSes too. The quick fix is to suspend and resume again (obviously not a permanent fix). The coreboot team suspects it could be related to some ACPI setting in coreboot, but they haven't been able to find anything conclusive.

It would be great to get some more information on the state of the laptop when it is hibernating. I'm setting up something called "tellerstats" with lm-sensors (which are both in PureOS) to gather more info so I can see if I can reproduce the problem.

Is there anything I can do to help find the cause (collect logs, etc.)?

Seems you are on the right track in that the error message indicates FileZilla is requesting a feature unavailable in GnuTLS. The exact cause for you may not be same as the one addressed in the bugreorts you found - they might just be for similar kinds of issues.

The build is still failing :(

So, the problem is a simple test failure on arm64: https://software.pureos.net/builds/job/2ea4dd9c-5685-46cb-bd0c-f0d747053990

Assertion 'r < 0' failed at ../src/journal/test-compress.c:235, function test_lz4_decompress_partial(). Aborting.

@chris.lamb I'll have a look

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.