[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: networkx 2.5 Re: Falcon -> misc updates



Hi Andreas,

The whole falcon heavily depended on Python2. And the nim code did no
compile. This was addressed. No idea if the error we now see results
from the Python migration or if this is something else. Did the 2.1.x
version ever before get to the point that tests were run?

I admit that I did not see an easy fix this error either. There is some
confusion with StringIO vs ByteIO which was not distinguished in Python2
and the tests feed some weird unicode as a byte sequence. Did not yet
look very deep into this DuplicateOptionError.

I need some fresh look and fresh energy to investigate this further.

Steffen

On 01.09.20 15:31, Andreas Tille wrote:
> Hi Steffen,
>
> I finally found the time to check falcon and was running routine-update
> first.  I also tried to simplify dh_auto_test.  However, I think the
> code that is executed should be perfectly the same as before.
> Unfortunately I get:
>
> ...
>                         if (self._strict and
>                             (sectname, optname) in elements_added):
>>                           raise DuplicateOptionError(sectname, optname,
>                                                        fpname, lineno)
> E                           configparser.DuplicateOptionError: While reading from '<???>' [line 13]: option 'job_queue' in section 'General' already exists
>
> /usr/lib/python3.8/configparser.py:1093: DuplicateOptionError
> =============================== warnings summary ===============================
> falcon_kit/mains/consensus_task.py:15
>   /build/falcon-2.1.4/FALCON/falcon_kit/mains/consensus_task.py:15: DeprecationWarning: invalid escape sequence \d
>     """Return opts sans the regexp match, and proper nproc.
>
> falcon_kit/FastaReader.py:29
>   /build/falcon-2.1.4/FALCON/falcon_kit/FastaReader.py:29: DeprecationWarning: invalid escape sequence \s
>     nameParts = re.split('\s', name, maxsplit=1)
>
> -- Docs: https://docs.pytest.org/en/latest/warnings.html
> ----------- generated xml file: /build/falcon-2.1.4/FALCON/test.xml ------------
> ============================ slowest test durations ============================
> 0.02s call     test/test_util_io.py::test_io_se1331
> 0.01s call     test/test_functional.py::test_Readers
> 0.01s call     test/test_util_io.py::test_str_type[CapturedProcessReaderContext]
>
> (0.00 durations hidden.  Use -vv to show these durations.)
> =============== 17 failed, 79 passed, 2 warnings in 1.68 seconds ===============
> {('.1', '.1'): 'daligner -v -w1 -h1 -t50 -H2000 -e0.99 -l1 -s1000 -P=. -mdust '
>                'raw_reads.1 raw_reads.1\n'
>                'LAcheck -v raw_reads *.las\n',
>  ('.2', '.1', '.2'): 'daligner -v -w1 -h1 -t50 -H2000 -e0.99 -l1 -s1000 -P=. '
>                      '-mdust raw_reads.2 raw_reads.1 raw_reads.2\n'
>                      'LAcheck -v raw_reads *.las\n'}[3735998]'echo "hi\nthere"'
> [3735998]'echo "hi\nthere"'
> [3735998]'seq 20000'
> [3735998]'seq 2'
> [3735998]'seq 2'
> make[2]: *** [makefile:25: test] Error 1
>
>
> I admit I have no idea how to fix this.
>
> Kind regards
>
>        Andreas.
>
>
> On Thu, Aug 27, 2020 at 07:28:48PM +0200, Steffen Möller wrote:
>> Networkx 2.5 I just also uploaded. What is kind of unexpected is
>> that in debian/tmp the file are installed to the subdirectory
>> /usr..python3.8
>> while the package receives the same in the python3 subdirectory.
>>
>> What should be done to address this? Manually rename the folder in
>> debian/tmp?
>>
>> Many thanks!
>>
>> Steffen
>>
>> On 27.08.20 19:16, Steffen Möller wrote:
>>> Hello,
>>>
>>> with python3-networkx 2.5 the previously reported FTBFS is done. I am
>>> just cowbuilding that monster again and will then team-upload.
>>>
>>> Concerning falcon I transitioned everything (except for the module
>>> declaration) to Python3. The nim code is now compatible with version 1.2
>>> of nim. Especially that strings are no longer allowed to be nil rather
>>> bit the code hard. I just pushed this all, so I don't lose these
>>> changes, and also happily pass the finalisation of the package in other
>>> hands. Should be these Python modules only ...
>>>
>>> What we should really do so is to feed these changes back to upstream.
>>>
>>> Steffen
>>>
>>


Reply to: