[gentoo-dev] [RFC] News Item: sys-fs/cryfs-0.10.2 update

[gentoo-dev] [RFC] News Item: sys-fs/cryfs-0.10.2 update

[Andreas Sturmlechner]

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

Title: sys-fs/cryfs-0.10.2 update 
Author: Andreas Sturmlechner <asturm@gentoo.org>
Content-Type: text/plain
Posted: 2019-10-26
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: <sys-fs/cryfs-0.10

Internal changes in sys-fs/cryfs-0.10 [1] made it incompatible with encrypted
containers created with 0.9.x. No automatic migration of old containers is
provided. This requires manual upgrade planning.

Before updating, copy all data from cryfs containers to a temporary and secure
location. After 0.10.x update, move it back into a newly created container.

This is being made more complicated by conflicting boost dependencies:
- sys-fs/cryfs-0.9.x depends on sys-fs/cryfs-1.65.0
- sys-fs/cryfs-0.10.x depends on >=dev-libs/boost-1.65.1

Which means this update is going to be part of a bigger system update as
typically many boost consumers need to be rebuilt.

[1] https://github.com/cryfs/cryfs/releases/tag/0.10.1

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

[gentoo-dev] Re: [RFC] News Item v2: sys-fs/cryfs-0.10.2 update

[Andreas Sturmlechner]

[-- Attachment #1: Type: text/plain, Size: 913 bytes --]

Title: sys-fs/cryfs-0.10.2 update 
Author: Andreas Sturmlechner <asturm@gentoo.org>
Content-Type: text/plain
Posted: 2019-10-26
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: <sys-fs/cryfs-0.10

Filesystems created with CryFS 0.9.x are incompatible with the new storage 
format. [1] Migration is necessary before mounting with CryFS 0.10 and 
possible for old containers going back as far as CryFS 0.9.4. [2]

However, upstream recommend to create new containers with 0.10 to avoid 
potential data loss from a failed migration, and in order to benefit from all 
performance advantages of the new format.

Before updating, copy all data from cryfs containers to a temporary and secure
location. After the update, move it back into a newly created container. Don't 
forget to remove the temporary files afterwards.

[1] https://bugs.gentoo.org/690324
[2] https://github.com/cryfs/cryfs/releases/tag/0.10.1

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

[gentoo-dev] Re: [RFC] News Item v3: sys-fs/cryfs-0.10.2 update

[Andreas Sturmlechner]

[-- Attachment #1: Type: text/plain, Size: 1140 bytes --]

(v3: amended with KDE Plasma Vaults)

Title: sys-fs/cryfs-0.10.2 update 
Author: Andreas Sturmlechner <asturm@gentoo.org>
Content-Type: text/plain
Posted: 2019-10-28
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: <sys-fs/cryfs-0.10

Filesystems created with CryFS 0.9.x are incompatible with the new storage 
format. [1] Migration is necessary before mounting with CryFS 0.10 and 
possible for old containers going back as far as CryFS 0.9.4. [2]

However, upstream recommend to create new containers with 0.10 to avoid 
potential data loss from a failed migration, and in order to benefit from all 
performance advantages of the new format.

Before updating, copy all data from cryfs containers to a temporary and secure
location. After the update, move it back into a newly created container. Don't 
forget to remove the temporary files afterwards.

Users of KDE Plasma Vaults should follow the same procedure. To check the type 
of existing containers, open them using the Vaults widget. It is part of the 
path as displayed in dolphin.

[1] https://bugs.gentoo.org/690324
[2] https://github.com/cryfs/cryfs/releases/tag/0.10.1

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] Re: [RFC] News Item v3: sys-fs/cryfs-0.10.2 update

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 268 bytes --]

>>>>> On Mon, 28 Oct 2019, Andreas Sturmlechner wrote:

> News-Item-Format: 1.0

I'm aware that it's not required by policy to use the newest format,
but is there any particular reason for not using 2.0?

More generally, can we deprecate News-Item-Format 1.0?

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Re: [gentoo-dev] Re: [RFC] News Item v3: sys-fs/cryfs-0.10.2 update

[Andreas Sturmlechner]

On Monday, 28 October 2019 at 11:54, Ulrich Mueller wrote:
> >>>>> On Mon, 28 Oct 2019, Andreas Sturmlechner wrote:
> 
> > News-Item-Format: 1.0
> 
> I'm aware that it's not required by policy to use the newest format,
> but is there any particular reason for not using 2.0?

None, I guess. Simple change then:

Title: sys-fs/cryfs-0.10.2 update
Author: Andreas Sturmlechner <asturm@gentoo.org>
Posted: 2019-10-29
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: <sys-fs/cryfs-0.10

[gentoo-dev] [RFC] News Item v2: Desktop profile switching USE default to elogind

[Andreas Sturmlechner]

Title: Desktop profile switching USE default to elogind
Author: Andreas Sturmlechner <asturm@gentoo.org>
Posted: 2019-10-31
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: sys-auth/consolekit
Display-If-Profile: default/linux/alpha/17.0/desktop
Display-If-Profile: default/linux/amd64/17.0/desktop
Display-If-Profile: default/linux/amd64/17.0/desktop/plasma
Display-If-Profile: default/linux/amd64/17.1/desktop
Display-If-Profile: default/linux/amd64/17.1/desktop/plasma
Display-If-Profile: default/linux/arm/17.0/armv4/desktop
Display-If-Profile: default/linux/arm/17.0/armv4/desktop/plasma
Display-If-Profile: default/linux/arm/17.0/armv4t/desktop
Display-If-Profile: default/linux/arm/17.0/armv4t/desktop/plasma
Display-If-Profile: default/linux/arm/17.0/armv5te/desktop
Display-If-Profile: default/linux/arm/17.0/armv5te/desktop/plasma
Display-If-Profile: default/linux/arm/17.0/armv6j/desktop
Display-If-Profile: default/linux/arm/17.0/armv6j/desktop/plasma
Display-If-Profile: default/linux/arm/17.0/armv7a/desktop
Display-If-Profile: default/linux/arm/17.0/armv7a/desktop/plasma
Display-If-Profile: default/linux/arm/17.0/desktop
Display-If-Profile: default/linux/arm/17.0/desktop/plasma
Display-If-Profile: default/linux/arm64/17.0/desktop
Display-If-Profile: default/linux/arm64/17.0/desktop/plasma
Display-If-Profile: default/linux/hppa/17.0/desktop
Display-If-Profile: default/linux/ia64/17.0/desktop
Display-If-Profile: default/linux/m68k/17.0/desktop
Display-If-Profile: default/linux/powerpc/ppc32/17.0/desktop
Display-If-Profile: default/linux/powerpc/ppc64/17.0/32bit-userland/desktop
Display-If-Profile: default/linux/powerpc/ppc64/17.0/64bit-userland/desktop
Display-If-Profile: default/linux/sh/17.0/desktop
Display-If-Profile: default/linux/sparc/17.0/64ul/desktop
Display-If-Profile: default/linux/sparc/17.0/desktop
Display-If-Profile: default/linux/x86/17.0/desktop
Display-If-Profile: default/linux/x86/17.0/desktop/plasma

Modern desktop environments make use of PAM session tracking for users, login 
sessions and seats. [1] The most user-visible part of that is device and file 
permissions management and reboot/shutdown handling without superuser rights.

Users with systemd can stop reading here and continue with their daily routine.

ConsoleKit2 is unmaintained upstream for almost two years [2]. There are many 
longstanding bugs and papercuts with consumers that aren't being fixed, not 
least because these code paths receive very little testing.

Enter the elogind project [3], which is a standalone logind implementation 
based on systemd code, currently maintained by a fellow Gentoo user. We have 
had sys-auth/elogind available in Gentoo since the beginning of 2017, and 
meanwhile it has gained support [4] in KDE Plasma, Gnome [5], Cinnamon, MATE 
and Xfce, as well as most other former consolekit consumers.

Consequently, the desktop profile is switching away from consolekit to elogind. 
Users of sys-auth/consolekit who selected a different profile should consider 
doing the same. A guide is available [6]. Migration is easy, but if run from 
within a consolekit session that session may become broken.

Rely either on the profile, or set USE="elogind -consolekit" in make.conf 
yourself. Make sure there is no consolekit debris in /etc/portage/package.use:

# grep -R consolekit /etc/portage/package.use

Rebuild all affected consumers and remove sys-auth/consolekit:

# emerge --ask --changed-use --deep @world
# emerge --depclean consolekit

Optional, but recommended in case of trouble such as missing reboot/shutdown 
capabilities in the DM:

# rc-update add elogind boot

For users of startx instead of one of the supported DMs, do not forget to 
update ~/.xinitrc accordingly (ck-launch-session is gone without replacement).

PS: Subsequently, this will lead to the last-riting of sys-power/pm-utils [7]
which is dead even longer than the original ConsoleKit(1) project. KDE Plasma 
users sticking with sys-auth/consolekit are then going to lose suspend from 
GUI without superuser rights.

[1] https://wiki.gentoo.org/wiki/ConsoleKit
[2] https://github.com/ConsoleKit2/ConsoleKit2
[3] https://github.com/elogind/elogind/blob/master/README.md
[4] https://bugs.gentoo.org/show_bug.cgi?id=elogind-support
[5] https://blogs.gentoo.org/leio/2019/03/26/gnome-3-30/
[6] https://wiki.gentoo.org/wiki/Elogind
[7] https://bugs.gentoo.org/659616