Hello Andreas, > I was running routine-update and have build the package. When calling > a random binary I experienced: > > > $ plot_features > 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 I experienced the same thing, but I assumed my direct execution was wrong and maybe lefse was meant to be used / integrated within something in the python ecosystem. If I recall correctly, I got an error (I think it was different to this) when executing lefse pre the python3 conversion. > 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 > droped and > > from lefse import * > > should remain. I assume so. I don't think this was result in a complete breakage. I'm fairly misinformed with python but I am not too sure of the idea behind "from lefse import *" getting converted to "from .lefse import *". I will take another look at this. Annoyingly, this test script is broken even before the python3 conversion. > 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. From my experience with debian mentors mailing list, people are understandably busy and I haven't received any replies with previous emails. I agree, the package is not totally broken because the direct source clone acts up the same way as this package, so functionality-wise, I assume there is very little to no deviation. Maybe as you suggest, it is best to upload and wait for user bug reports - that will be an experience too and should rule out any packaging faults. FAST has a low traffic anyways. >> 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 :). These packages have been quite an experience and something I'd continue doing for debian med. Simka should be an easy program to package once I figure out why the object linkage fails. Kinds regards, Shayan Doust On 09/09/2019 20:19, Andreas Tille wrote: > Hi Shayan, > > 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: > > > $ plot_features > 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 > droped and > > from lefse import * > > should remain. > >> 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 > > Andreas. >
Attachment:
signature.asc
Description: OpenPGP digital signature