Re: [MoM] lefse migration to python 3
On Mon, Sep 09, 2019 at 07:19:05PM +0100, Shayan Doust wrote:
> Just an update. Apologies for the somewhat degraded and slower performance.
Really no need to apologize - I simply had a real life weekend as well.
> Please check the patch as mentioned for just an instance to make sure I
> am on a satisfactory path before I push for a changelog. As stated, one
> file needed to have a consistent tab / space correction due to failing
> apt install which resulted in a slightly bigger patch than preferred.
> I'd hate to finalise on something that isn't good :).
I was running routine-update and have build the package. When calling
a random binary I experienced:
Traceback (most recent call last):
File "/usr/bin/plot_features", line 6, in <module>
from .lefse import *
ModuleNotFoundError: No module named '__main__.lefse'; '__main__' is not a package
As far as I can see this is actually a Python3 conversion issue
I really wonder whether this chunk of the patch should be rather
from lefse import *
> On top of this, regarding FAST, upstream has been really silent (not
> usually like this). I could give them a week or so, but what is the
> worst case with regards to this package? It seems like the test suite is
> troublesome (more than probably a machine trouble / misconfiguration or
> FAST nitpicking a specific opencl platform) and if there is no response
> from upstream, I won't be able look into the test suite. Does that mean
> theoretically abandoning this package for some amount of time either
> until the test suite can be checked by another peer with the correct
> hardware & opencl knowledge?
Asking on Debian Mentors list is an option to clarify the test suite
issue. We could even upload the package to new queue. It will last
some time anyway to pass the queue. The package is also not totally
broken (binaries are starting, some tests are passing). Its hard to
tell whether those failures are practically important or not. We could
hope for user bug reports.
> On the side, I have decided to work on another package. It seems like
> even this is getting to be a slight pain (depends on gatb-core and
> modifying cmake to use debian packaged gatb-core seems to bring a whole
> lot of issues during linkage). I am currently waiting until upstream
> replies or someone via the mentors mailing list to give a suggestion.
I've seen and appreciated your commits. :-)
> Thanks for the support once again & kind regards,
Thanks a lot for your work