Re: Bug#971111: gubbins: FTBFS: pkg_resources.extern.packaging.requirements.InvalidRequirement: Parse error at "'/build/g'": Expected W:(abcd...)
Control: tags -1 help
Control: forwarded -1 Aidan Delaney
Hi,
I admit I have no idea what might have caused these pkg_resources
related errors and how to fix these.
Any help would be welcome
Andreas.
On Sun, Sep 27, 2020 at 08:45:17PM +0200, Lucas Nussbaum wrote:
> Source: gubbins
> Version: 2.4.1-2
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200926 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
> Relevant part (hopefully):
> > make[3]: Entering directory '/<>'
> > make[3]: Leaving directory '/<>'
> > make[2]: Leaving directory '/<>'
> > cd python && \
> > python3 setup.py test
> > running test
> > WARNING: Testing via this command is deprecated and will be removed in a
> > future version. Users looking for a generic test entry point independent of
> > test runner are encouraged to use tox.
> > running egg_info
> > creating gubbins.egg-info
> > writing gubbins.egg-info/PKG-INFO
> > writing dependency_links to gubbins.egg-info/dependency_links.txt
> > writing entry points to gubbins.egg-info/entry_points.txt
> > writing requirements to gubbins.egg-info/requires.txt
> > writing top-level names to gubbins.egg-info/top_level.txt
> > writing manifest file 'gubbins.egg-info/SOURCES.txt'
> > reading manifest file 'gubbins.egg-info/SOURCES.txt'
> > writing manifest file 'gubbins.egg-info/SOURCES.txt'
> > running build_ext
> > /<>/python/gubbins/common.py:538: DeprecationWarning: invalid
> > escape sequence \d
> > elif re.match('^\d', vcf_line) is not None:
> > /<>/python/gubbins/common.py:613: DeprecationWarning: invalid
> > escape sequence \d
> > search_obj = re.search('misc_feature([\d]+)..([\d]+)$', line)
> > /<>/python/gubbins/common.py:620: DeprecationWarning: invalid
> > escape sequence \=
> > search_taxa = re.search('taxa\=\"([^"]+)\"', line)
> > /usr/lib/python3/dist-packages/dendropy/utility/container.py:357:
> > DeprecationWarning: Using or importing the ABCs from 'collections' instead
> > of from 'collections.abc' is deprecated since Python 3.3, and in 3.9 it
> > will stop working
> > class CaseInsensitiveDict(collections.MutableMapping):
> > test_concatenate_fasta_files
> > (gubbins.tests.test_alignment_python_methods.TestAlignmentMethods) ... ok
> > test_get_sequence_names_from_alignment
> > (gubbins.tests.test_alignment_python_methods.TestAlignmentMethods) ... ok
> > test_number_of_sequences_in_alignment
> > (gubbins.tests.test_alignment_python_methods.TestAlignmentMethods) ... ok
> > test_reconvert_fasta_file
> > (gubbins.tests.test_alignment_python_methods.TestAlignmentMethods) ... ok
> > test_reinsert_gaps_into_fasta_file
> > (gubbins.tests.test_alignment_python_methods.TestAlignmentMethods) ... ok
> > test_get_recombination_files
> > (gubbins.tests.test_converging_recombinations.TestConvergingRecombinations)
> > ... ok
> > test_multiple_files_have_one_match
> > (gubbins.tests.test_converging_recombinations.TestConvergingRecombinations)
> > ... ok
> > test_reading_embl_file
> > (gubbins.tests.test_converging_recombinations.TestConvergingRecombinations)
> > ... ok
> > test_two_files_are_different
> > (gubbins.tests.test_converging_recombinations.TestConvergingRecombinations)
> > ... ok
> > test_two_files_are_same
> > (gubbins.tests.test_converging_recombinations.TestConvergingRecombinations)
> > ... ok
> > test_cleanup (gubbins.tests.test_dependencies.TestExternalDependencies) ...
> > ERROR
> > test_fasttree (gubbins.tests.test_dependencies.TestExternalDependencies)
> > ... ERROR
> > test_hybrid (gubbins.tests.test_dependencies.TestExternalDependencies) ...
> > ERROR
> > test_iqtree (gubbins.tests.test_dependencies.TestExternalDependencies) ...
> > ERROR
> > test_raxml (gubbins.tests.test_dependencies.TestExternalDependencies) ...
> > ERROR
> > test_rename_final_output
> > (gubbins.tests.test_dependencies.TestExternalDependencies) ... ERROR
> > test_dont_filter_input_file_with_multiple_duplicate_sequences
> > (gubbins.tests.test_pre_process_fasta.TestPreProcessFasta) ... ok
> > test_filter_out_alignments_with_too_much_missing_data
> > (gubbins.tests.test_pre_process_fasta.TestPreProcessFasta) ... ok
> > test_input_file_with_all_duplicate_sequences
> > (gubbins.tests.test_pre_process_fasta.TestPreProcessFasta) ... ok
> > test_input_file_with_multiple_duplicate_sequences
> > (gubbins.tests.test_pre_process_fasta.TestPreProcessFasta) ... ok
> > test_input_file_with_no_duplicate_sequences
> > (gubbins.tests.test_pre_process_fasta.TestPreProcessFasta) ... ok
> > test_input_file_with_one_duplicate_sequences
> > (gubbins.tests.test_pre_process_fasta.TestPreProcessFasta) ... ok
> > test_filter_out_removed_taxa_from_tree
> > (gubbins.tests.test_tree_methods.TestTreeMethods) ... ok
> > test_has_tree_been_seen_before
> > (gubbins.tests.test_tree_methods.TestTreeMethods) ... ok
> > test_internal_node_taxons_removed_when_used_as_s
Re: Bug#971111: gubbins: FTBFS: pkg_resources.extern.packaging.requirements.InvalidRequirement: Parse error at "'/build/g'": Expected W:(abcd...)
python/gubbins/common.py::parse_and_run() constructs an absolute path for the executable and then passes it to pkg_resources.get_distribution(). I have no idea what does this code want to achieve, as get_distribution() takes requirement specifications, not file paths. -- WBR, wRAR signature.asc Description: PGP signature
Re: Bug#971111: gubbins: FTBFS: pkg_resources.extern.packaging.requirements.InvalidRequirement: Parse error at "'/build/g'": Expected W:(abcd...)
Control: tags -1 upstream Control: forewarded -1 https://github.com/sanger-pathogens/gubbins/issues/286 On Fri, Oct 30, 2020 at 02:38:03PM +0500, Andrey Rahmatullin wrote: > python/gubbins/common.py::parse_and_run() constructs an absolute path for > the executable and then passes it to pkg_resources.get_distribution(). I > have no idea what does this code want to achieve, as get_distribution() > takes requirement specifications, not file paths. Thanks for checking - I've forwarded the issue upstream. Kind regards Andreas. -- http://fam-tille.de
Re: How to watch pypi.org
Thank you very much, Andrey. El dom., 4 oct. 2020 a las 17:42, Andrey Rahmatullin () escribió: > On Sun, Oct 04, 2020 at 05:28:57PM +0200, Fioddor Superconcentrado wrote: > > I've packaged a project provided via https://pipi.org and I wanted to > > create a debian/watch file but pipi.org publishes the tarball behind a > > strange url like > > > > > https://files.pythonhosted.org/packages/d6/72/9848a2d631dad70d7ea582540f0619e1a7ecf31b3a117de9d9f2b6b28029/django-settings-export-1.2.1.tar.gz > > > > I guess pypi.org is a common source of python code so perhaps there's > > already a solution for this. > The solution (that transparently uses pypi.debian.net) is described in > uscan(1). > > -- > WBR, wRAR >
Re: How to watch pypi.org
Thank you as well, Geert. And yes. It has taken me some time to come back to this issue but I've tested and seems to work fine. El dom., 4 oct. 2020 a las 17:44, Geert Stappers () escribió: > On Sun, Oct 04, 2020 at 05:28:57PM +0200, Fioddor Superconcentrado wrote: > > I've packaged a project provided via https://pipi.org and I wanted to > > create a debian/watch file but pipi.org publishes the tarball behind a > > strange url like > > > > > https://files.pythonhosted.org/packages/d6/72/9848a2d631dad70d7ea582540f0619e1a7ecf31b3a117de9d9f2b6b28029/django-settings-export-1.2.1.tar.gz > > > > I guess pypi.org is a common source of python code so perhaps there's > > already a solution for this. > > Quoting the manual page of uscan. > ( uscan is the utility reads debian/watch for watching. ) > > >PyPI >For PyPI based projects, pypi.debian.net runs a redirector >which allows a simpler form of URL. The format below will >automatically be rewritten to use the redirector with the watch >file: > > version=4 > https://pypi.python.org/packages/source/// \ > -(.+)\.tar\.gz debian uupdate > >For cfn-sphere, set the watch file as: > > version=4 > https://pypi.python.org/packages/source/c/cfn-sphere/ \ > cfn-sphere-([\d\.]+).tar.gz debian uupdate > >Please note, you can still use normal functionalities of uscan >to set up a watch file for this site without using the >redirector. > > version=4 > opts="pgpmode=none" \ > https://pypi.python.org/pypi/cfn-sphere/ \ > https://pypi.python.org/packages/.*/.*/.*/\ > cfn-sphere-([\d\.]+).tar.gz#.* debian uupdate > > > > > Thanks in advanced. > > Looking forward to something like "OK, that works" > > > Regards > Geert Stappers > -- > Silence is hard to parse > >
Re: How to watch pypi.org
As I said I'm very new to this and all (python) packages I'm using lately use the usual python tools (pipy, setup.py, etc) and my first approach has been to stick as close as possible to the upstream procedures. But I might very likely be taking a wrong decision. What are the reasons to go for git instead of pypi? I see that it is 'more upstream' but it seems that everyone else is pointing to pypi as a distro-agnostic solution. El lun., 5 oct. 2020 a las 4:24, Paul Wise () escribió: > On Sun, Oct 4, 2020 at 3:29 PM Fioddor Superconcentrado wrote: > > > I've packaged a project provided via https://pipi.org and I wanted to > create a debian/watch file but pipi.org publishes the tarball behind a > strange url like > > I would suggest using the upstream git repo instead of the PyPi tarballs. > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise > >
Re: How to watch pypi.org
On Fri, Oct 30, 2020 at 03:18:58PM +0100, Fioddor Superconcentrado wrote: > As I said I'm very new to this and all (python) packages I'm using lately > use the usual python tools (pipy, setup.py, etc) and my first approach has > been to stick as close as possible to the upstream procedures. But I might > very likely be taking a wrong decision. What are the reasons to go for git > instead of pypi? I see that it is 'more upstream' but it seems that > everyone else is pointing to pypi as a distro-agnostic solution. One reason is tarballs may be missing some files, including tests. > El lun., 5 oct. 2020 a las 4:24, Paul Wise () escribió: > > > On Sun, Oct 4, 2020 at 3:29 PM Fioddor Superconcentrado wrote: > > > > > I've packaged a project provided via https://pipi.org and I wanted to > > create a debian/watch file but pipi.org publishes the tarball behind a > > strange url like > > > > I would suggest using the upstream git repo instead of the PyPi tarballs. > > -- WBR, wRAR signature.asc Description: PGP signature
Re: How to watch pypi.org
On Fri, Oct 30, 2020 at 2:19 PM Fioddor Superconcentrado wrote: > As I said I'm very new to this and all (python) packages I'm using lately use > the usual python tools (pipy, setup.py, etc) and my first approach has been > to stick as close as possible to the upstream procedures. But I might very > likely be taking a wrong decision. What are the reasons to go for git instead > of pypi? I see that it is 'more upstream' but it seems that everyone else is > pointing to pypi as a distro-agnostic solution. As Andrey says, missing files is one issue, another is that tarballs often contain extra generated files that should be built from source, but if you use the tarball then they quite likely will not be built from source. -- bye, pabs https://wiki.debian.org/PaulWise
Re: How to watch pypi.org
On 2020-10-31 01:33:36 + (+), Paul Wise wrote: > On Fri, Oct 30, 2020 at 2:19 PM Fioddor Superconcentrado wrote: > > As I said I'm very new to this and all (python) packages I'm > > using lately use the usual python tools (pipy, setup.py, etc) > > and my first approach has been to stick as close as possible to > > the upstream procedures. But I might very likely be taking a > > wrong decision. What are the reasons to go for git instead of > > pypi? I see that it is 'more upstream' but it seems that > > everyone else is pointing to pypi as a distro-agnostic solution. > > As Andrey says, missing files is one issue, another is that tarballs > often contain extra generated files that should be built from source, > but if you use the tarball then they quite likely will not be built > from source. I have to agree, though in the upstream projects with which I'm involved, those generated files are basically a lossy re-encoding of metadata from the Git repositories themselves: AUTHORS file generated from committer headers, ChangeLog files from commit subjects, version information from tag names, and so on. Some of this information may be referenced from copyright licenses, so it's important in those cases for package maintainers to generate it when making their source packages if not using the sdist tarballs published by the project. -- Jeremy Stanley signature.asc Description: PGP signature
Re: How to watch pypi.org
On Sat, Oct 31, 2020 at 2:31 AM Jeremy Stanley wrote: > I have to agree, though in the upstream projects with which I'm > involved, those generated files are basically a lossy re-encoding of > metadata from the Git repositories themselves: AUTHORS file > generated from committer headers, ChangeLog files from commit > subjects, version information from tag names, and so on. Some of > this information may be referenced from copyright licenses, so it's > important in those cases for package maintainers to generate it when > making their source packages if not using the sdist tarballs > published by the project. As the maintainer of the autorevision package (which aims at dumping a cache of VCS version metadata, for when exporting a tarball from a VCS), I've been thinking about this for a while now. I've been thinking about modifying automake (and other build tools) to have a mode that basically does `git archive` instead of just calling tar and also creates separate tarballs for all the other generated or embedded files. One for the autorevision metadata, one for the autotools cruft, one for a cache of the data needed for AUTHORS/ChangeLog/NEWS etc and possibly other ones. Then Debian can use our multi-component quilt 3.0 format to take the git archive, the autorevision metadata, and the cache of the VCS data, but leave the autotools cruft behind. Then we can audit the git repo for generated files and embedded data/code copies and when there are none, we can confidently build the configure script from source knowing that everything required is available in the build-deps. The same could apply to projects uploading to NPM or PyPi, although I'm not sure if those support this sort of thing though. -- bye, pabs https://wiki.debian.org/PaulWise
