Please port to py3.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7d45f1c02b7588cfc8882c44ac0663c040a511dc commit 7d45f1c02b7588cfc8882c44ac0663c040a511dc Author: Aaron Bauman <bman@gentoo.org> AuthorDate: 2020-08-02 22:49:23 +0000 Commit: Aaron Bauman <bman@gentoo.org> CommitDate: 2020-08-02 22:51:26 +0000 package.mask: last-rite sys-fs/ecryptfs-utils Bug: https://bugs.gentoo.org/735486 Bug: https://bugs.gentoo.org/564894 Bug: https://bugs.gentoo.org/704356 Bug: https://bugs.gentoo.org/715938 Bug: https://bugs.gentoo.org/697778 Bug: https://bugs.gentoo.org/715508 Signed-off-by: Aaron Bauman <bman@gentoo.org> profiles/package.mask | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
The basic functionality (that is, mounting ecryptfs pseudofilesystems) works fine sans python (emerge with -python). Looks like python is only necessary if you want Python bindings. As far as I see no package depends on ecryptfs-utils, let alone on its python bindings, so if we simply remove the option of building those python bindings and drop the `python` useflag, we need never speak of python in the context of ecryptfs-utils again.
Created attachment 652692 [details] Build ecryptfs-utils without Python Following Wicher Minnaard's insight I hacked an ebuild with Python bindings forcibly disabled (--disable-pywrap) and all Python references removed. So, Please don't remove ecryptfs-utils.
(In reply to Tiago Sousa from comment #3) > Created attachment 652692 [details] > Build ecryptfs-utils without Python > > Following Wicher Minnaard's insight I hacked an ebuild with Python bindings > forcibly disabled (--disable-pywrap) and all Python references removed. So, > > Please don't remove ecryptfs-utils. Thanks for this, but it doesn't address the fundamental "No maintainer" issue. I am a long-time user of eCryptfs, but this removal may be the kick I needed to migrate to native and more memory efficient ext4 FS Encryption (https://wiki.gentoo.org/wiki/Ext4_encryption, https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html).
(In reply to Geoffrey Goodrum from comment #4) > Thanks for this, but it doesn't address the fundamental "No maintainer" > issue. I see, unfortunately I'm not interested in proxy maintaining packages, so can't help there. At this point Gentoo seems to be falling apart and I just keep the pieces that I need in my own tree. For example it's ridiculous that Cinnamon was days away from being removed, which was almost my quitting point. Even today I had to hack virtual/cron to recognize vixie-cron, which was removed also for lacking maintainer, despite working well. So many packages were removed that could be kept longer, at least until they actually broke. I'll just try to salvage ecryptfs-utils while I can and jump ship when that becomes impossible, which is bound to happen sooner or later. For years now I don't understand the direction of the Gentoo project, but it doesn't seem to be targeted at end users. Well, enough /rant :) > I am a long-time user of eCryptfs, but this removal may be the kick I needed > to migrate to native and more memory efficient ext4 FS Encryption > (https://wiki.gentoo.org/wiki/Ext4_encryption, > https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html). Thanks for the link, but that doesn't seem a viable solution for now. From the wiki: "This scenario will work only with single user computer (specified in systemd service file)." Well I don't even use systemd, plus I want any user's home to be encrypted and decrypted dynamically on any login, whether console, X or ssh. For the life of me I can't understand why perfectly working and well engineered software is sometimes cast aside. I'll try to hold on to ecryptfs for as long as possible...
(In reply to Tiago Sousa from comment #5) > (In reply to Geoffrey Goodrum from comment #4) > > I am a long-time user of eCryptfs, but this removal may be the kick I needed > > to migrate to native and more memory efficient ext4 FS Encryption > > (https://wiki.gentoo.org/wiki/Ext4_encryption, > > https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html). > Thanks for the link, but that doesn't seem a viable solution for now. From > the wiki: "This scenario will work only with single user computer (specified > in systemd service file)." Well I don't even use systemd, plus I want any > user's home to be encrypted and decrypted dynamically on any login, whether > console, X or ssh. For the life of me I can't understand why perfectly > working and well engineered software is sometimes cast aside. I'll try to > hold on to ecryptfs for as long as possible... I use OpenRC myself. I believe I can use the Wiki's systemd config to figure it out for OpenRC (and update the Wiki accordingly), but I'd love to see an official Gentoo fscrypt package (as in Arch), which would be much easier and address your multi-user concern. I might just install fscrypt locally, or if ambitious create an Overlay for it.
(In reply to Tiago Sousa from comment #5) > (In reply to Geoffrey Goodrum from comment #4) > > Thanks for this, but it doesn't address the fundamental "No maintainer" > > issue. > I see, unfortunately I'm not interested in proxy maintaining packages, so > can't help there. At this point Gentoo seems to be falling apart and I just > keep the pieces that I need in my own tree. For example it's ridiculous that > Cinnamon was days away from being removed, which was almost my quitting > point. Even today I had to hack virtual/cron to recognize vixie-cron, which > was removed also for lacking maintainer, despite working well. So many > packages were removed that could be kept longer, at least until they > actually broke. I'll just try to salvage ecryptfs-utils while I can and jump > ship when that becomes impossible, which is bound to happen sooner or later. > For years now I don't understand the direction of the Gentoo project, but it > doesn't seem to be targeted at end users. Well, enough /rant :) Sorry to hear this. Things like this get cleaned when not maintained and we have big movements like Py2 removal. If you would like to remove the Py bindings and keep it around then please feel free to maintain it. I will happily merge any PR's to do so. > > > I am a long-time user of eCryptfs, but this removal may be the kick I needed > > to migrate to native and more memory efficient ext4 FS Encryption > > (https://wiki.gentoo.org/wiki/Ext4_encryption, > > https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html). > Thanks for the link, but that doesn't seem a viable solution for now. From > the wiki: "This scenario will work only with single user computer (specified > in systemd service file)." Well I don't even use systemd, plus I want any > user's home to be encrypted and decrypted dynamically on any login, whether > console, X or ssh. For the life of me I can't understand why perfectly > working and well engineered software is sometimes cast aside. I'll try to > hold on to ecryptfs for as long as possible...
(In reply to Aaron Bauman from comment #7) > Sorry to hear this. Things like this get cleaned when not maintained and we > have big movements like Py2 removal. If you would like to remove the Py > bindings and keep it around then please feel free to maintain it. I will > happily merge any PR's to do so. Thanks for reaching out, Aaron, the PR is out. PS: Quite a lot of steps in that PR wiki page... Shame the effort would go to waste... I think I see what you did there... :P :)
There is nothing comparable to ecryptfs-utils. Other solutions will use a whole disk or filenames leak when encrypted or usage is humble lacking utils. I found a patch in a mailing list from 2018: https://www.spinics.net/lists/ecryptfs/msg01026.html. I never used Swig and didn't look into ecryptfs-utils yet. In addition I'm willing to volunteer as a proxy maintainer for ecryptfs-utils. Will setup a machine according to the wiki page and start with an overlay for the PR to gain traction.
(In reply to Tiago Sousa from comment #3) > > Following Wicher Minnaard's insight I hacked an ebuild with Python bindings > forcibly disabled (--disable-pywrap) and all Python references removed. So, > > Please don't remove ecryptfs-utils. Seems like Debian (Sid) took the same approach. Are your changes related/ similar/ the same? https://launchpad.net/debian/+source/ecryptfs-utils/111-5
(In reply to onkobu from comment #10) > (In reply to Tiago Sousa from comment #3) > > > > Following Wicher Minnaard's insight I hacked an ebuild with Python bindings > > forcibly disabled (--disable-pywrap) and all Python references removed. So, > > > > Please don't remove ecryptfs-utils. > > Seems like Debian (Sid) took the same approach. Are your changes related/ > similar/ the same? > > https://launchpad.net/debian/+source/ecryptfs-utils/111-5 I didn't look at their changes, since the original ebuild already knew how to disable the bindings (with -python), I simply hardcoded that. Credit to Wicher Minnaard for pointing in the right direction. Thank you so much for stepping up to proxy maintain this, onkobu! A side rant about Gentoo: It is nice to see Debian giving WAY more than this *30 days* nonsense (their Sid development branch is rolling, like us). Their bug was opened in August last year (!), a fix was suggested in May 14th, a patch was posted in June 15th, and it was accepted in August 2nd: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936465 That's how volunteer-based, user-oriented distros should work.
I'd also opt for simply skipping python instead of dropping the entire package. It is hard to get in contact with Gentoo guys. Debian has more surface.
Arch Linux has a rolling approach, too. And they're not that picky about Python 2. But their dependency system works the other way around and enables Python bindings if Python (2) is already installed. They're still using 111-4. https://www.archlinux.org/packages/?name=ecryptfs-utils
I'm happy to merge the PR but I need a GCO sign off from the person who made it.
(In reply to Sam James from comment #14) > I'm happy to merge the PR but I need a GCO sign off from the person who made > it. Done, sorry, I'm a noob. Consider adding this strict requirement to the paragraph before "repoman ci" at: https://wiki.gentoo.org/wiki/GitHub_Pull_Requests#Step_5:_User_changes_a_package
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=924bca481d9127d2c3ac92f9cab4a5688384ee66 commit 924bca481d9127d2c3ac92f9cab4a5688384ee66 Author: Sam James <sam@gentoo.org> AuthorDate: 2020-08-17 00:45:03 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2020-08-17 00:50:59 +0000 sys-fs/ecryptfs-utils: unmask Bug: https://bugs.gentoo.org/735486 Signed-off-by: Sam James <sam@gentoo.org> profiles/package.mask | 5 ----- 1 file changed, 5 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4542f5205ad1bc953e54ccbc487f5e6ebe3a5f8c commit 4542f5205ad1bc953e54ccbc487f5e6ebe3a5f8c Author: Sam James <sam@gentoo.org> AuthorDate: 2020-08-17 00:50:54 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2020-08-17 00:50:54 +0000 sys-fs/ecryptfs-utils: forcibly disable Python bindings From Tiago's original PR: "This package only supports Python 2, so disable the bindings with --disable-pywrap and remove the USE flag. The tools themselves don't require Python, they're either binaries or shell scripts." Committing separately because I want to do this in a revbump due to other cleanups and in case someone wants to shout about the Python bindings being somehow useful. Thanks-to: Tiago Sousa <tiagosousa@gmail.com> Bug: https://bugs.gentoo.org/735486 Package-Manager: Portage-3.0.2, Repoman-2.3.23 Signed-off-by: Sam James <sam@gentoo.org> .../ecryptfs-utils-111_p20170609-r1.ebuild | 82 ++++++++++++++++++++++ 1 file changed, 82 insertions(+)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0e2cee62bac2765e792060042b835ab94b99d2a9 commit 0e2cee62bac2765e792060042b835ab94b99d2a9 Author: Sam James <sam@gentoo.org> AuthorDate: 2020-08-17 01:08:06 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2020-08-17 01:08:06 +0000 sys-fs/ecryptfs-utils: cleanup old Python 2.7 version Closes: https://bugs.gentoo.org/735486 Package-Manager: Portage-3.0.2, Repoman-2.3.23 Signed-off-by: Sam James <sam@gentoo.org> .../ecryptfs-utils-111_p20170609.ebuild | 94 ---------------------- 1 file changed, 94 deletions(-)
