In T571#10542, @mak wrote:

Your PureOS is tainted.

Your PureOS is tainted. The only versions of gnome-software that we include in PureOS are:

gnome-software | 3.28.0-1pureos1 | green      | source, amd64, arm64
gnome-software | 3.28.0-1pureos1 | landing    | source, amd64, arm64
gnome-software | 3.28.0-1pureos1 | purple     | source, amd64, arm64

The PureOS specific change includes exactly a difference to recognized things from the pureos-main archive as free.
Please reinstall your system to ensure that you actually only have stuff we ship in PureOS, and make sure that no non-PureOS sources exist in your sources.list.
The output of apt list suggests a manual installation of a foreign gnome-software package (highly likely from Debian), but it could also be that it was updated once and the source it came from has been removed meanwhile (if you know that you manually updated gnome-software that is fine, in this case you would need to reset the package and can maybe avoid a reinstallation).

I can't reproduce this issue - the software is shown as "Free" for me.
Which version of gnome-software do you have installed? (apt list gnome-software)

Ah, the version in the screenshot indicates that it is the Debian package which gets installed.

Password Safe as shipped upstream contains code which has been removed from Debian redistribution due to its licensing.

What is displayed if you click on the red "Proprietary" field?

Also, i removed .gimp-2.8 directory from user and it does nothing.

Also, there is no output from terminal with no option and verbose, console messages and debug handlers enabled.

I agree, but it does show that it's a problem with your particular setup, what particularly is the problem and have you tried running from terminal

I have installed it from flathub and i have no problem, it works but i would want use official build, flatpak packages have a bad performance and flathub has propietary software on their repositories

I am using the official repository version.

Gimp works fine on my system latest version, do they offer it as a snap/flatpak

Dear all,

GIMP worked on my system four updates ago. ImageMagick it works but is very limited and i have no plans to change my default image editor.

https://forums.puri.sm/t/what-should-we-have-on-the-pure-browser-start-page/3792

gimp didn't come pre-installed on my system, but have you tried using a different image manipulator or an older of gimp?

Done :)

@mladen.pejakovic For what purpose? (What can he do here that I cannot?)

Done, GIMP is at 2.10.6-3 in landing now.

@chris.lamb Let's hand it over to Mak?

Hi tronkel,

Speficially Matthias has shared some info here: https://tracker.pureos.net/T99#10198

yes please.

Thanks @jonas.smedegaard. Want me to handle this? (I see I remain assigned..)

Seems Gimp 2.10 defaults to single window mode, and our fork can be dropped.

(NB. reply on that Debian bug report)

Tempted to close this issue as there is no clear "next action". Any objections?

@mladen.pejakovic Hey hey, what's the status of this? I'm just wondering what my next steps here — the ticket is currently assigned to me, but I have no obvious 'next action' as far as I can tell.

It's in debian testing now.

I have reported a problem
3-steps-needed-to-start-using-laptop-instead-of-2-steps-before
which Mladen linked to this tracker.

I have reinstalled GIMP without affect it.

Apparently, no problems on news user, only on the user created from the installer.

The website show now sign-in instead of Apache page.

The canaries use now science news from reuters.com, see at step 3:
https://github.com/purism/warrant-canary/tree/master/canaries

by filename information I mean the filename, such as: "pureos-8.0-gnome-live_20180826-amd64.hybrid.iso" which also contain useful information such as date (when iso was generated?)

I would describe the symptoms slightly different, but I'd say it has the same cause. (Assuming purism-power-optimisations)

This issue, as well as all reboot failures related to missing swap partitions are now addressed in the latest PureOS images.
In total, this issue and issues related to it consisted of 5 completely separate issues affecting various aspects:

See also: https://a13xp0p0v.github.io/2018/07/07/kconfig-hardened-check.html

I fixed this bug, which unfortunately brought us another (already known) bug of the swap partition not unlocking properly.

@mladen.pejakovic That's a different issue that was already fixed a while ago.
The one in this bug is actually even older and has been in PureOS forever (we just didn't see it because initramfs updates aren't triggered that often, and it is not that severe in its impact).

What should actually happen here is / being decrypted with a password, and swapfs being decrypted with a keyfile on /.
Or, as a second option, swapfs being reformatted at boot time.

Testing migration can be tracked here:

@kyle.rankin I have followed up to the bug (CC'd you)

Maybe it can help you:
https://lists.debian.org/debian-kde/2018/08/msg00030.html
https://lists.debian.org/debian-kde/2018/08/msg00032.html
Hope it will help

Hi @chris.lamb I just wanted to check in on the progress with this. Looking at the official bug it looks like things have stalled a bit but maybe there are other things happening behind the scenes with people working on packaging that I'm not aware of.

https://forums.puri.sm/t/on-boot-lvm-is-asking-the-same-password-twice/3547

You can fix this by changing the parameters of whetever is your swap partition to /dev/urandom swap,cipher=aes-xts-plain64,size=256,
e.g.:
luks-aaaaaaaa-a86a-469c-812f-92b36f70113e UUID=aaaaaaaa-a86a-469c-812f-92b36f70113e /dev/urandom swap,cipher=aes-xts-plain64,size=256

I selected the default partitioning option.

This /etc/crypttab is wrong, one line should have been set to auto-format swap.
Did you do manual partitioning, or did you select the default option?

• I contacted another FTP team member so this has been ACCEPTED in good time.

Thank you! :)

The non-comments in /etc/crypttab are:

Hmm, swap should not even be password-encrypted...
What's the content of your /etc/crypttab?

After the update-initramfs and reboot, I always get prompted to decrypt the / partition first and then prompted to decrypt the swap partition second (checked the uuid's against lsblk to determine this). This order is always preserved.

@vivia.nikolaidou Uploaded.

I have seen on the live installer that sometimes when I enter the passphrase a second time to confirm, the installer crashes and needs to be re-launched. This behavior happens sometimes and is not consistently reproducible but it happens frequently enough (when installing to a libvirt VM anyways) for it to be annoying, maybe ~25% of the time. Matthias thinks my issue is related to T547 so recording the behavior here.

I just got confused because mentors.debian.net complains that 4.2.1 is too new

Thanks, reuploaded! I just got confused because mentors.debian.net complains that 4.2.1 is too new and needs 4.1.4, but I am indeed getting 4.2.1 from lintian in sid.

Just had a look - thanks! So, if you're running Lintian from sid then I don't understand why you still have:

Thank you @mak I have added the slideshow to my to-do list and will discuss about it with Tobias. See you on the other issue!

Yes indeed, I am running lintian from Debian sid.

@vivia.nikolaidou Please go ahead and drop the "contrib" etc. and let me know where I can do the review/upload. (Note that the very latest lintian is for 4.2.1... but I assume you are running Lintian from Debian sid...)

I don't have a straightforward way of reproducing this. Let me see if I can find someone who can...

@chris.lamb Sorry - was on vacation last week. :)

I'll once again raise my point regarding "Freedom harm" tagged issues. According to https://www.gnu.org/distros/free-system-distribution-guidelines.en.html:

I was so sure that there already was a ticket, and I even wrote instructions there... But that either happened way back with our makeshift bugtracker, or I must have dreamed it.

Neat :-)
Since the error is triggered by archive metadata, there is no way to ensure people have upgraded their system prior to fetching new metadata. We just have to rely on people upgrading their system regularly.