Re: Bug#936613: ginac: Python2 removal in sid/bullseye
On 10.09.19 20:31, Richard B. Kreckel wrote: On 10.09.19 11:29, Matthias Klose wrote: Please read the instructions, they mention to check dependencies, build dependencies, and test dependencies ... I have read https://wiki.debian.org/Python/2Removal and the linked pages. Are there any other instructions? $ apt-cache showsrc ginac|grep Depends Build-Depends: cdbs (>= 0.4.28), debhelper (>= 9), libcln-dev, libgmp-dev, libreadline-dev, pkg-config (>= 0.18) | pkgconf, dh-autoreconf, python, texinfo That 'python' package it depends on is a dependency package. Isn't it going to depend on Debian's Python3, so /usr/bin/python will mean Python 3, as e.g. in Fedora 31? No. bullseye will not have a python package, and no python command. If the python command is going to be python3, then I suppose we can close this bug. (I've checked that the package can be built on a box where python3 has been made the default.) If the python command isn't going to be python3, then I'll update the build-dependencies ASAP. And then this fact ought to be prominently documented and explained in the instructions so to support this transition. please do. and feel free to clarify the wiki page. Thanks, Matthias
Re: Streamlining the use of Salsa CI on team packages
Gregor Riepl: > >> I am not a fan of pointing to a moving target with the "include" statement: >> >> include: >> - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml >> - >> https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml >> >> "master" will change, and that can break CI jobs where nothing in the >> local repo has changed. > > It does have pros and cons. > > The good: Additional build/verification steps or even automatic deployment can > be added by the Salsa team at some point without requiring changes to each > repository. > > The bad: As you mentioned, a moving target can be bad and cause inadvertent > build failures and other issues that are out of the hands of maintainers. > > The ugly: Pulling in external scripts always bears a certain risk. They may go > away at some point or cause potentially dangerous side effects. > > However, I do think that a standardised CI pipeline is very useful. Consider > that the buildd infrastructure also uses a standardised build process that > packages cannot simply get away from. If this process is replicated on Salsa, > with an external script or not, people will quickly get a "glimpse" of what > would happen on buildd. The need to manually adapt the CI script every time > something changes in the buildd process is a heavy burden to bear and will > easily lead to people "forgetting" to update their scripts. That kind of > defeats the purpose. > > Also, consider that the Salsa CI pipeline is not an absolute source of truth, > but a tool for developers and maintainers to quickly spot issues with their > packages. If an autobuild fails, it's not the end of the world. It just means > you have to go check what's going on. > I totally agree about having a standardized build process and CI pipeline. And I agree that the CI builds are a tool, not the final release build process. As for updating that config, in Debian we already have a well known update mechanism: `apt-get upgrade`. The CI builds can use that same process, we don't need to introduce a new one just for CI builds (e.g. dynamic links to files in gitlab). These CI environment configs can be included in a Debian package. This has been my goal with ci-image-git-buildpackage. The bits are all shell scripts which can easily be included in a Debian package. The mechanism used in salsa-ci-team/pipeline is a mystery, even to me, and I've been using GitLab-CI since the beginning (2015), and setting up CI systems since 2006 (bash scripts!). There is obviously a lot of great work in salsa-ci-team/pipeline, I just question the interface between it and the Debian Developer: how its specified in the .gitlab-ci.yml file. .hc
RFS: fortran-language-server 1.10.2-1
Hi team, I've created fortran-language-server in PAPT https://salsa.debian.org/python-team/applications/fortran-language-server to address ITP Bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936075 Could spend some time to review and upload the package? Thanks, Denis
Re: pybuild mysteriously does not copy all testfiles
Hi IOhannes,
I have basically the same problem, funnily with almost the same subject:
https://lists.debian.org/debian-python/2019/09/msg00040.html
The difference is, that the "external" subdirectory is not copied. So,
it seems to be a bug in dh-python.
Cheers
Ole
"IOhannes m zmölnig (Debian/GNU)" writes:
> updating one of my packages (python-can), the test-suite started to
> fail, with an error-code 5, indicating that "no tests have been run".
>
> since there *are* tests to be run, i investigated and - after scratching
> my head - found that 'pybuild' did not fully copy the test-directory
> from the source-directory to the build directory.
>
> The sources "test/" directory contains:
> ```
> test/serial_test.py
> test/test_slcan.py
> test/test_cyclic_socketcan.py
> test/data/logfile.blf
> test/data/__init__.py
> test/data/example_data.py
> test/data/logfile.asc
> test/test_bit_timing.py
> test/zero_dlc_test.py
> test/test_systec.py
> test/open_vcan.sh
> test/message_helper.py
> test/contextmanager_test.py
> test/test_detect_available_configs.py
> test/test_message_sync.py
> test/notifier_test.py
> test/config.py
> test/simplecyclic_test.py
> test/test_scripts.py
> test/logformats_test.py
> test/listener_test.py
> test/back2back_test.py
> test/test_message_class.py
> test/__init__.py
> test/test_message_filtering.py
> test/test_socketcan.py
> test/test_kvaser.py
> test/test_viewer.py
> test/network_test.py
> test/test_vector.py
> test/test_socketcan_helpers.py
> test/test_load_file_config.py
> ```
>
> However, ".pybuild/cpython3_3.7_can/build/test/" contains only: (after
> dh_auto_test failed):
> ```
> test/data/__init__.py
> test/data/example_data.py
> ```
>
> d/rules is pretty standard:
> ```
> #! /usr/bin/make -f
> export PYBUILD_NAME=can
> include /usr/share/dpkg/default.mk
> export DEB_VERSION_UPSTREAM
> %:
> dh $@ --with python3,sphinxdoc --buildsystem=pybuild
> override_dh_clean:
> dh_clean
> rm -f test.asc test.csv
> rm -rf .pytest_cache/
> override_dh_auto_build:
> dh_auto_build
> python3 -m sphinx -E -T -b html doc .pybuild/docs/html/
> override_dh_auto_install:
> dh_auto_install
> -for f in debian/*/usr/bin/*.py; do mv $$f $${f%.py}; done
> -rm -f debian/*/usr/lib/python*/dist-packages/test.???
> ```
>
> and the package does not contain d/pybuild.testfiles or similar.
>
> Now if I add a file from tests (say "test/network_test.py") to
> d/pybuild.testfiles, that file is copied (although into
> .pybuild/cpython3_3.7_can/build/ rather than into
> .pybuild/cpython3_3.7_can/build/test/) and runs correctly.
> adding "test/" to d/pybuild.testfiles (with or without the trailing
> slash) did not do anything (apart from the original behaviour of only
> copying 2 files).
> doing something like "find test -type f > d/pybuild.testfiles" copied
> all files, however the directory structure was lost (all files ended up
> in .pybuild/cpython3_3.7_can/build/), and the tests started to fail as
> they didn't find files in the subdirectories as expected.
>
> i'm totally stumified.
>
> an intermediate hack i found to work is to manually copy the "test/"
> directoy into the build-dir, using:
> export PYBUILD_BEFORE_TEST=cp -r {dir}/test {build_dir}
>
> but that seems extraordinarily clumsy. esp. since pybuild(1) says:
>> By default only test and tests directories are copied to build
>> directory.
>
> any ideas what does wrong?
> mgfdsar
> IOhannes
pybuild mysteriously does not copy all testfiles
updating one of my packages (python-can), the test-suite started to
fail, with an error-code 5, indicating that "no tests have been run".
since there *are* tests to be run, i investigated and - after scratching
my head - found that 'pybuild' did not fully copy the test-directory
from the source-directory to the build directory.
The sources "test/" directory contains:
```
test/serial_test.py
test/test_slcan.py
test/test_cyclic_socketcan.py
test/data/logfile.blf
test/data/__init__.py
test/data/example_data.py
test/data/logfile.asc
test/test_bit_timing.py
test/zero_dlc_test.py
test/test_systec.py
test/open_vcan.sh
test/message_helper.py
test/contextmanager_test.py
test/test_detect_available_configs.py
test/test_message_sync.py
test/notifier_test.py
test/config.py
test/simplecyclic_test.py
test/test_scripts.py
test/logformats_test.py
test/listener_test.py
test/back2back_test.py
test/test_message_class.py
test/__init__.py
test/test_message_filtering.py
test/test_socketcan.py
test/test_kvaser.py
test/test_viewer.py
test/network_test.py
test/test_vector.py
test/test_socketcan_helpers.py
test/test_load_file_config.py
```
However, ".pybuild/cpython3_3.7_can/build/test/" contains only: (after
dh_auto_test failed):
```
test/data/__init__.py
test/data/example_data.py
```
d/rules is pretty standard:
```
#! /usr/bin/make -f
export PYBUILD_NAME=can
include /usr/share/dpkg/default.mk
export DEB_VERSION_UPSTREAM
%:
dh $@ --with python3,sphinxdoc --buildsystem=pybuild
override_dh_clean:
dh_clean
rm -f test.asc test.csv
rm -rf .pytest_cache/
override_dh_auto_build:
dh_auto_build
python3 -m sphinx -E -T -b html doc .pybuild/docs/html/
override_dh_auto_install:
dh_auto_install
-for f in debian/*/usr/bin/*.py; do mv $$f $${f%.py}; done
-rm -f debian/*/usr/lib/python*/dist-packages/test.???
```
and the package does not contain d/pybuild.testfiles or similar.
Now if I add a file from tests (say "test/network_test.py") to
d/pybuild.testfiles, that file is copied (although into
.pybuild/cpython3_3.7_can/build/ rather than into
.pybuild/cpython3_3.7_can/build/test/) and runs correctly.
adding "test/" to d/pybuild.testfiles (with or without the trailing
slash) did not do anything (apart from the original behaviour of only
copying 2 files).
doing something like "find test -type f > d/pybuild.testfiles" copied
all files, however the directory structure was lost (all files ended up
in .pybuild/cpython3_3.7_can/build/), and the tests started to fail as
they didn't find files in the subdirectories as expected.
i'm totally stumified.
an intermediate hack i found to work is to manually copy the "test/"
directoy into the build-dir, using:
export PYBUILD_BEFORE_TEST=cp -r {dir}/test {build_dir}
but that seems extraordinarily clumsy. esp. since pybuild(1) says:
> By default only test and tests directories are copied to build
> directory.
any ideas what does wrong?
mgfdsar
IOhannes
signature.asc
Description: OpenPGP digital signature
Re: 2to3 adds '.' in front dir of "from dir import ..." statements (Was: [MoM] lefse migration to python 3])
It results from the ambiguity between absolute and relative imports in Python 2. Here 2to3 considers your imports being relative, hence the added dot. I believe no dots would be added should a `from __future__ import absolute_import` be found in the preamble of the module. Hope this helps. Ghis Le mar. 10 sept. 2019 à 07:51, Andreas Tille a écrit : > Hi, > > in the process of the Python3 migration the package lefse was converted > using 2to3. The changes can be found in git[1]. I'm wondering about > the following diff created by 2to3: > > - from lefse import * > + from .lefse import * > > When calling a random binary of the resulting binary package lefse I > experienced: > > $ plot_features > Traceback (most recent call last): > File "/usr/bin/plot_features", line 6, in > from .lefse import * > ModuleNotFoundError: No module named '__main__.lefse'; '__main__' is not a > package > > > I think the line > >from lefse import * > > should remain to keep that script functional. I now checked another > package (cain - nothing pushed yet) and here also 2to3 is changing > >from something import * > > to > >from .something import * > > Could somebody please enlighten me about this added '.' which does not > seem to work? > > Kind regards > > Andreas. > > [1] https://salsa.debian.org/med-team/lefse > > -- > http://fam-tille.de > >
