[Pkg-electronics-devel] Processed: python3.6

Carsten Schoenert c.schoenert at t-online.de
Wed Jan 16 19:50:39 GMT 2019


Hello Felix,

Am 14.01.19 um 12:49 schrieb Felix Salfelder:
> On Mon, Jan 14, 2019 at 06:39:05AM +0000, Debian Bug Tracking System wrote:
>> Processing control commands:
>>
>>> block 916817 by -1
>> Bug #916817 [release.debian.org] transition: remove python3.6
>> 916817 was blocked by: 917369 917628 917626 916820 914147 917781
>> 916817 was not blocking any bugs.
>> Added blocking bug(s) of 916817: 919255
> 
> Dear All.
> 
> I fixed #918533 and #919255 in git/0.0.2-2. Please could you have a
> look and upload?

just a quick response after having a look.

Currently there are two commits in the git tree since version 0.0.2-1
for preparing -2.

The first (3d9a7d980a9902fdad3a1455c9b87c7bae77bf92) is basically not
needed, you would just have need to adjust the sequencer file
gnucap-python.docs.

The following patch archives the same behavior but increases the
readability of debian/rules a bit.

> $ git diff
> diff --git a/debian/gnucap-python.docs b/debian/gnucap-python.docs
> index e78a1c3..edc0071 100644
> --- a/debian/gnucap-python.docs
> +++ b/debian/gnucap-python.docs
> @@ -1 +1 @@
> -usr/share/doc/gnucap-python/NEWS
> +NEWS
> diff --git a/debian/rules b/debian/rules
> index 19f2763..d192805 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -52,8 +52,6 @@ override_dh_auto_install:
>         cd debian/tmp/usr/lib/*/gnucap[0-9]; ln -sf c_python${PYDEF}.so c_python.so
>         mv debian/tmp${PYDEF}/usr/share debian/tmp/usr
>  
> -       cp NEWS debian/tmp/usr/share/doc/gnucap-python/NEWS
> -
>  override_dh_auto_configure: $(PYVERS:%=ac-python%)
>  override_dh_auto_build: $(PYVERS:%=ab-python%)
>  override_dh_auto_test: $(PYVERS:%=at-python%)

The other (second) commit a03f2d72de38b5ab9a69104475be30eef03f7888 fixes
the actual problem but moves the same problem just into the future.

You will need to the quite the same again once Python3.8 will the
default Python3 version in Debian.
So it's better to use the virtual package python3-dev here instead of
python3.7-dev! Look at the dependencies of python3-dev.
The same is valid for the Python2 version here, just use python-dev
(even there will be no new major version of Python2 as we all know).

Some more suggestions.
Have a look at the output of the Lintian QS tool, it helps you find QA
issues you probably not see directly.

> $ lintian -IE
> W: gnucap-python source: ancient-python-version-field x-python-version 2.6
> I: gnucap-python source: out-of-date-standards-version 4.2.1 (released 2018-08-25) (current is 4.3.0)
> I: gnucap-python source: testsuite-autopkgtest-missing
> N: 1 tag overridden (1 warning)

Lintian warnings should really be investigated and fixed, the first
informative issue is also easy to fix, just check if you need to do
further QA work because of the current actual policy and increase the
S-V if ready. I assume you don't need to do anything to be able to do so.

https://www.debian.org/doc/debian-policy/upgrading-checklist.html#version-4-3-0

The package holds a git-buildpackage configuration file but it seem you
do most of the work manually. Do you know the option 'dch' for creating
or updating the changelog file?

The package is using debhelper 11, we are right in the beginning of the
freeze. The current version is 12, time to update?

https://nthykier.wordpress.com/2019/01/04/debhelper-compat-12-is-now-released/

Consider to order the Build-Depends entries alphabetical, it helps to
find packages in question more quickly (or not).

The tracker website is mentioning that gnucap-python could be marked
Multi-Arch: same.

dpkg-shlibdeps is printing really a lot of warnings! You will need to
tune the creation of the dependencies by modify this target in the rules
file. Just have a look at existing packages what this for similar
reasons and also have a look into the man page(s). The most of these
warnings are probably from used symbols found in private libs.

The comment in debian/rules seems more to explain the used hack than a
correct solution. I guess other package maintainer of python bindings
have the same or similar problems to solve. So looking into other
packages should give some inspiration or at show people that can be asked.

-- 
Regards
Carsten Schoenert



More information about the Pkg-electronics-devel mailing list