Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1458602 - ecryptfs-utils: Proper packaging of python part, e.g. rename and add subpackage(s) for python[2|3]
Summary: ecryptfs-utils: Proper packaging of python part, e.g. rename and add subpacka...
Status: CLOSED DUPLICATE of bug 1627433
Alias: None
Product: Fedora
Classification: Fedora
Component: ecryptfs-utils
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Lumír Balhar
QA Contact: Fedora Extras Quality Assurance
Whiteboard: PatchNeeded
Depends On: 533920
TreeView+ depends on / blocked
Reported: 2017-06-04 20:09 UTC by Raphael Groner
Modified: 2018-09-11 20:50 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-09-11 20:50:47 UTC
Type: Bug

Attachments (Terms of Use)
source code patch (deleted)
2018-06-18 11:48 UTC, Lumír Balhar
no flags Details | Diff
specfile patch (deleted)
2018-06-18 11:49 UTC, Lumír Balhar
no flags Details | Diff

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1577174 0 unspecified CLOSED ecryptfs-utils calls authconfig in postinstall and postuninstall, but authconfig is depredicated in Fedora 28 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1603860 0 unspecified CLOSED ecryptfs-utils: FTBFS in Fedora rawhide 2021-02-22 00:41:40 UTC

Internal Links: 1577174 1603860

Description Raphael Groner 2017-06-04 20:09:52 UTC
Description of problem:
The subpackage ecryptfs-utils-python uses a wrong name style, it's expected to be named as python2-ecryptfs-utils, it's supposed to be used with and requires python2. There's no python3 subpackage like python3-ecryptfs-utils.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. dnf install ecryptfs-utils-python

Actual results:
python2 is the fixed dependency.

Expected results:
It should be possible to use ecryptfs-utils with python3.

Additional info:
Especially for the case of python3, please take care about the guidelines that enforce compatibility with python3: In Fedora we have multiple Python runtimes, one for each supported major Python release. At this point that's one for python2.x and one for python3.x. If a piece of software supports python3, it must be packaged for python3.
However, packages in Fedora should not depend on where /usr/bin/python happens to point but instead should call the proper executable for the needed python major version directly, either /usr/bin/python2 or /usr/bin/python3 as appropriate. 

This package should generally follow the domain specific guidelines of python:

There's an example common spec file:

Comment 1 Jan Kurik 2017-08-15 07:00:52 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

Comment 2 Raphael Groner 2017-08-15 09:07:50 UTC
Ping? Any news here?

Comment 3 Michal Hlavinka 2017-08-15 11:28:31 UTC
not a high priority atm. If you (or anyone else) prepare the patch, I'll commit it.

Comment 4 Raphael Groner 2017-08-17 13:47:45 UTC
There's a bug in configure to let it fail with detection of right python3 environment. Have to investigate.

Comment 5 Raphael Groner 2018-03-03 16:26:01 UTC
Bug #533920 indicates a general issue with automake and python3.

Comment 6 Raphael Groner 2018-03-05 23:26:49 UTC
Work in progress:

Comment 7 Harald Reindl 2018-04-11 19:58:09 UTC
what about accept that python is crap when it takes that long to port code while PHP7 was released many years after python3 and in the meantime every serious project is wrking on 7.0/7.1/7.2 

do we have to expect the same b*****t with python3?

since GNOME3 did not learn anything from KDE4 i doubt that things become better - just port code relevant for distributions to a serious programming language which don't break anything left and right every few years

Comment 8 Petr Viktorin (pviktori) 2018-04-12 08:55:15 UTC
Lumír, could you look at ecryptfs when you get some time?

Comment 9 Petr Viktorin (pviktori) 2018-04-12 19:55:34 UTC
ecryptfs-utils is using some pregenerated code [0], which was apparently generated by SWIG 1.3.31. Current Fedora has SWIG 3.0.12.

Try removing these files (in %prep, after pushd %{name}-%{version}):

rm src/libecryptfs-swig/
rm src/libecryptfs-swig/libecryptfs_wrap.c

I'm afraid the rabbit hole goes further down from there, though.


Comment 10 Lumír Balhar 2018-05-29 19:24:56 UTC
I managed to port Python part of ecryptfs-utils with the code generated by Swig to Python 3 compatible form. Package with Python subpackages builds correctly.

Is there anybody who can give me a simple example of usage of python modules? I cannot find any documentation of usage so I am not able to test it.

Comment 11 Raphael Groner 2018-05-30 18:55:07 UTC
@lbalhar Thanks for your hard work.

As there are no usable python tests available, my suggestion would be:
Should we write some unit tests for the API of the legacy (python2) module and try run them also against python3? If it works, we could send all as a proposed patch to upstream.

Comment 12 Lumír Balhar 2018-05-31 07:27:24 UTC
(In reply to Raphael Groner from comment #11)
> @lbalhar Thanks for your hard work.
> As there are no usable python tests available, my suggestion would be:
> Should we write some unit tests for the API of the legacy (python2) module
> and try run them also against python3? If it works, we could send all as a
> proposed patch to upstream.

That's a great idea. The problem is that I have no idea how to use neither ecryptfs nor ecryptfs-utils and its Python module. So I am not the one who can write tests.

There are only three functions to test:
- binary_data ecryptfs_passphrase_blob(char *salt, char *passphrase);
- binary_data ecryptfs_passphrase_sig_from_blob(char *blob);
- int ecryptfs_add_blob_to_keyring(char *blob, char *sig);

Moreover, the usage is kinda hacky, because ecryptfs-utils contains dash in the name and it doesn't contain file. That means that you have to alter PYTHONPATH to be able to import libecryptfs. Python code in /usr/lib contains only import machinery to import mentioned functions from /usr/lib64 so you have to have both folders in PYTHONPATH.

Python 2:

# PYTHONPATH=/usr/lib/python2.7/site-packages/ecryptfs-utils/:/usr/lib64/python2.7/site-packages/ecryptfs-utils/ python2
>>> from libecryptfs import *
>>> ecryptfs_passphrase_blob('a', 'b')
>>> ecryptfs_passphrase_sig_from_blob('a')
>>> ecryptfs_add_blob_to_keyring('a', 'b')

Python 3:

# PYTHONPATH=/usr/lib/python3.6/site-packages/ecryptfs-utils/:/usr/lib64/python3.6/site-packages/ecryptfs-utils/ python3
>>> from libecryptfs import *
>>> ecryptfs_passphrase_blob('a', 'b')
>>> ecryptfs_passphrase_sig_from_blob('a')
b'y the completer f'
>>> ecryptfs_add_blob_to_keyring('a', 'b')

It seems that it works but Python 3 produces different results. And that's it. I cannot verify the results or set an algorithm for testing because I don't know ecryptfs well enough.

Here is the scratch build with python3 subpackage:

Could you please help me?

Comment 13 Lumír Balhar 2018-06-18 11:48:44 UTC
Created attachment 1452610 [details]
source code patch

Comment 14 Lumír Balhar 2018-06-18 11:49:49 UTC
Created attachment 1452611 [details]
specfile patch

Comment 15 Lumír Balhar 2018-06-18 11:55:23 UTC
I've added patches for source code and specfile. I've also sent a help request to ecryptfs mailing list.

Will see if we find somebody who can help us with tests.

Comment 16 Raphael Groner 2018-06-18 18:35:11 UTC
Reviewed both provided suggested patches, they look good to me and do not seem to break any existing functionality. Unfortunately, I did not find any time to provide some (promised) tests as source code, let's continue to wait even longer for any help.

Comment 17 Lumír Balhar 2018-06-19 07:21:21 UTC
Link to my ML post:

Comment 18 Raphael Groner 2018-07-19 21:27:38 UTC
We have now FTBFS in rawhide, see bug #1603860.

Comment 19 Raphael Groner 2018-07-22 06:14:41 UTC
Lumir, could you enhance my PR with your patches?

Comment 20 Lumír Balhar 2018-07-31 12:00:44 UTC
I don't know how can I add some commits to your pull request. I think that we just need to apply my patches from here in %prep and test the resulting package.

Could you please do that or should I open a new pull request with mentioned changes?

Comment 21 Miro Hrončok 2018-08-14 14:24:09 UTC
Why don't we just drop the python subpackage entirely and call it a day?

Comment 22 Raphael Groner 2018-08-14 14:42:22 UTC

Well, as there's obviously nearly zero interest for the python part incl. upstream, I'm +1 for dropping the subpackage. We should still add a comment into the spec file why we dropped.

Comment 23 Raphael Groner 2018-08-14 14:52:00 UTC
This turns into a bug about to expect no good compatibility with further version of python, so I'll remove RFE and generally adjust the title of this bug.

Lumir, thanks anyways for your work. But I guess any downstream patch is the wrong way to go here. In the hope you can agree.

When upstream can provide any official compatibility with python3 in future, then we could readd a python subpackage.

Comment 24 Lumír Balhar 2018-08-15 05:06:07 UTC
I agree. Providing working, compatible and tested source code for packages is not our responsibility.

Feel free to create a new PR where you remove python subpackage. It might be better to use %bcond to disable them and add some comments so it would be easier to enable it back.

If you have some time, please prepare mentioned PR and I'll do a review. Otherwise, I'll do it when I'll have some free cycles.

Comment 25 Raphael Groner 2018-09-11 20:50:47 UTC
Removal of python2 subpackage is requested in bug #1627433.

*** This bug has been marked as a duplicate of bug 1627433 ***

Note You need to log in before you can comment on or make changes to this bug.