Re: [gentoo-dev] Package up for grabs: sys-firmware/iwl1000-ucode

2019-11-15 Thread Matt Turner
On Fri, Nov 15, 2019 at 2:20 AM Ulrich Mueller  wrote:
> The package is somewhat redundant, because sys-kernel/linux-firmware
> installs the same files. (Same for all other sys-firmware/iwl*-ucode
> packages.)

Should last-rite all of them, IMO.



[gentoo-dev] [PATCH 3/3] distutils-r1.eclass: Add tests for distutils_enable_tests

2019-11-15 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/tests/distutils-r1.sh | 67 +++-
 1 file changed, 66 insertions(+), 1 deletion(-)

diff --git a/eclass/tests/distutils-r1.sh b/eclass/tests/distutils-r1.sh
index d557f6cad534..d5f3e2812ca4 100755
--- a/eclass/tests/distutils-r1.sh
+++ b/eclass/tests/distutils-r1.sh
@@ -17,6 +17,36 @@ test-phase_name_free() {
fi
 }
 
+test-distutils_enable_tests() {
+   local runner=${1}
+   local exp_IUSE=${2}
+   local exp_RESTRICT=${3}
+   local exp_DEPEND=${4}
+
+   local IUSE=${IUSE}
+   local RESTRICT=${RESTRICT}
+   local DEPEND=${DEPEND}
+
+   tbegin "${runner}"
+
+   distutils_enable_tests "${runner}"
+
+   local ret var
+   for var in IUSE RESTRICT DEPEND; do
+   local exp_var=exp_${var}
+   if [[ ${!var} != "${!exp_var}" ]]; then
+   eindent
+   eerror "${var} expected: ${!exp_var}"
+   eerror "${var}   actual: ${!var}"
+   eoutdent
+   ret=1
+   tret=1
+   fi
+   done
+
+   tend ${ret}
+}
+
 inherit distutils-r1
 
 tbegin "sane function names"
@@ -27,6 +57,41 @@ test-phase_name_free python_compile
 test-phase_name_free python_test
 test-phase_name_free python_install
 
-tend ${failed}
+tend
+
+einfo distutils_enable_tests
+eindent
+BASE_IUSE="python_targets_python2_7"
+BASE_DEPS="python_targets_python2_7? ( >=dev-lang/python-2.7.5-r2:2.7 ) 
>=dev-lang/python-exec-2:=[python_targets_python2_7(-)?,-python_single_target_python2_7(-)]"
+TEST_RESTRICT=" !test? ( test )"
+
+einfo "empty RDEPEND"
+eindent
+RDEPEND=""
+test-distutils_enable_tests pytest \
+   "${BASE_IUSE} test" "${TEST_RESTRICT}" "${BASE_DEPS} test? ( 
dev-python/pytest[${PYTHON_USEDEP}]  )"
+test-distutils_enable_tests nose \
+   "${BASE_IUSE} test" "${TEST_RESTRICT}" "${BASE_DEPS} test? ( 
dev-python/nose[${PYTHON_USEDEP}]  )"
+test-distutils_enable_tests unittest \
+   "${BASE_IUSE}" "" "${BASE_DEPS}"
+test-distutils_enable_tests setup.py \
+   "${BASE_IUSE}" "" "${BASE_DEPS}"
+eoutdent
+
+einfo "non-empty RDEPEND"
+eindent
+BASE_RDEPEND="dev-python/foo[${PYTHON_USEDEP}]"
+RDEPEND=${BASE_RDEPEND}
+test-distutils_enable_tests pytest \
+   "${BASE_IUSE} test" "${TEST_RESTRICT}" "${BASE_DEPS} test? ( 
dev-python/pytest[${PYTHON_USEDEP}] ${BASE_RDEPEND} )"
+test-distutils_enable_tests nose \
+   "${BASE_IUSE} test" "${TEST_RESTRICT}" "${BASE_DEPS} test? ( 
dev-python/nose[${PYTHON_USEDEP}] ${BASE_RDEPEND} )"
+test-distutils_enable_tests unittest \
+   "${BASE_IUSE} test" "${TEST_RESTRICT}" "${BASE_DEPS} test? (  
${BASE_RDEPEND} )"
+test-distutils_enable_tests setup.py \
+   "${BASE_IUSE} test" "${TEST_RESTRICT}" "${BASE_DEPS} test? (  
${BASE_RDEPEND} )"
+eoutdent
+
+eoutdent
 
 texit
-- 
2.24.0




[gentoo-dev] [PATCH 2/3] distutils-r1.eclass: distutils_enable_tests, handle no deps better

2019-11-15 Thread Michał Górny
Do not set IUSE or other variables if the test runner does not have
any deps, and RDEPEND is empty.

Signed-off-by: Michał Górny 
---
 eclass/distutils-r1.eclass | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 99da6f5111cd..f316f85c3fc8 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -255,21 +255,16 @@ distutils_enable_tests() {
debug-print-function ${FUNCNAME} "${@}"
[[ ${#} -eq 1 ]] || die "${FUNCNAME} takes exactly one argument: 
test-runner"
 
-   [[ ${EAPI} == [56] ]] && local BDEPEND
-
-   IUSE+=" test"
-   RESTRICT+=" !test? ( test )"
-   BDEPEND+=" test? ("
-
+   local test_deps
case ${1} in
nose)
-   BDEPEND+=" dev-python/nose[${PYTHON_USEDEP}]"
+   test_deps="dev-python/nose[${PYTHON_USEDEP}]"
python_test() {
nosetests -v || die "Tests fail with ${EPYTHON}"
}
;;
pytest)
-   BDEPEND+=" dev-python/pytest[${PYTHON_USEDEP}]"
+   test_deps="dev-python/pytest[${PYTHON_USEDEP}]"
python_test() {
pytest -vv || die "Tests fail with ${EPYTHON}"
}
@@ -289,9 +284,15 @@ distutils_enable_tests() {
die "${FUNCNAME}: unsupported argument: ${1}"
esac
 
-   BDEPEND+=" ${RDEPEND} )"
-
-   [[ ${EAPI} == [56] ]] && DEPEND+=" ${BDEPEND}"
+   if [[ -n ${test_deps} || -n ${RDEPEND} ]]; then
+   IUSE+=" test"
+   RESTRICT+=" !test? ( test )"
+   if [[ ${EAPI} == [56] ]]; then
+   DEPEND+=" test? ( ${test_deps} ${RDEPEND} )"
+   else
+   BDEPEND+=" test? ( ${test_deps} ${RDEPEND} )"
+   fi
+   fi
 
# we need to ensure successful return in case we're called last,
# otherwise Portage may wrongly assume sourcing failed
-- 
2.24.0




[gentoo-dev] [PATCH 1/3] distutils-r1: distutils_enable_tests, add 'setup.py' option

2019-11-15 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/distutils-r1.eclass | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 2edffdb2d7c5..99da6f5111cd 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -241,6 +241,7 @@ fi
 #
 # - nose: nosetests (dev-python/nose)
 # - pytest: dev-python/pytest
+# - setup.py: setup.py test (no deps included)
 # - unittest: for built-in Python unittest module
 #
 # This function is meant as a helper for common use cases, and it only
@@ -273,6 +274,11 @@ distutils_enable_tests() {
pytest -vv || die "Tests fail with ${EPYTHON}"
}
;;
+   setup.py)
+   python_test() {
+   esetup.py test
+   }
+   ;;
unittest)
python_test() {
"${EPYTHON}" -m unittest discover -v ||
-- 
2.24.0




Re: [gentoo-dev] Why adding python3_8 to Gentoo sucks?

2019-11-15 Thread Ian Stakenvicius

On 2019-11-13 4:16 p.m., Michał Górny wrote:

[ Snip! ]


Can automation help with this at all, or is automation being used 
already?


Also to clarify, is the issue here the way that we specify python 
versions syntactically in all of the ebuilds in the repo, or is it 
just the way the dependency graph and compatibility of packages 
against a new python variant pan out?





Re: [gentoo-dev] Why adding python3_8 to Gentoo sucks?

2019-11-15 Thread Rich Freeman
On Fri, Nov 15, 2019 at 3:05 AM Michał Górny  wrote:
>
> On Wed, 2019-11-13 at 22:16 +0100, Michał Górny wrote:
> > I'd like to share my frustration at the state of Python in general,
> > and Python packages in Gentoo.  So I'd like to 'bootstrap' python3_8 --
> > that is, add it to the most common dependency, dev-python/setuptools.
> > Simple thing, right?
> >
>
> So I went with plan B instead: I'll do as much testing locally
> as possible, and add py3.8 when I manage to get the tests on the package
> in question working, independently of the testing of all deep test deps.
> This will mean that some packages will have tests disabled temporarily
> for end users.
>

Perhaps an overlay would be simpler just so that you can generally
avoid worrying about QA until you're tidying up, but otherwise this
seems like it could be done in-tree by just masking the use flag so
that only those willing to test/contribute run into issues.

You've described a number of issues and my sense is that many are just
inherent to python itself (the complex dep graph/etc - unless we want
a monolithic package).  Some of course go to Gentoo practices, some of
which cause pain outside of python.

In particular it seems like many still don't understand when
revbumping is necessary.  I'd have to dig up the wording of the actual
decision but as I recall when the Council made the decision they
wanted to leave a bit of room for maintainer discretion, trusting that
maintainers would use it properly.  An alternative proposal was to
just make a strict rule that would have erred on the side of QA, at
the cost of extra rebuilds for users (but at least consistent ones
that didn't break package managers).  Obviously developers can't
exercise proper discretion if they don't fully understand the impacts.
If in doubt a revbump should always be safe, just at the cost of some
rebuilds (which are probably cheap for python packages).

-- 
Rich



Re: [gentoo-dev] Why adding python3_8 to Gentoo sucks?

2019-11-15 Thread Alexey 'Alexxy' Shvetsov
В письме от пятница, 15 ноября 2019 г. 15:19:31 MSK пользователь Michael 
Orlitzky написал:
> On 11/15/19 7:04 AM, Alexey 'Alexxy' Shvetsov wrote:
> > As i remember some decades ago policy was: revbump needed if you change
> > chnages stuff installed on filesystem. So in case of py addition it is. So
> > what changed?
> > 
> > Are there some new written rules that says in what case you need revbump
> > and in what it needed?
> 
> To avoid breaking dependency resolution on users' systems, you have to
> make a new revision whenever you change a metadata variable that the
> package manager uses: DEPEND, RDEPEND, BDEPEND, IUSE, LICENSE,
> PYTHON_COMPAT, etc.
> 
> Basically, unless your change is completely trivial (updated comment,
> typo fix...), you should be making a new revision by default.

Yep. That that i remember. 

-- 
Best regards,
Alexey 'Alexxy' Shvetsov

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Why adding python3_8 to Gentoo sucks?

2019-11-15 Thread Michael Orlitzky
On 11/15/19 7:22 AM, Michał Górny wrote:
> 
> https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html
> 

Two things on that page are outright wrong:

  1. If the package has stable keywords, they should be moved to the new
 revision without dropping. To commit the ebuild, repoman commit
 --straight-to-stable option should be used.

That violates our other stabilization policies and common sense.

  2. Examples of changes that can be done without a revision bump are...

 adding a new USE flag or removing an existing one (since change in
 USE flags is going to trigger --changed-use rebuild),

The --changed-use flag is not default, not part of the PMS, and slows
portage down even more than it already is. The council ratified the PMS
and the associated GLEP, and following this advice breaks PMS-compliant
package managers.



Re: [gentoo-dev] Why adding python3_8 to Gentoo sucks?

2019-11-15 Thread Michał Górny
On Fri, 2019-11-15 at 15:04 +0300, Alexey 'Alexxy' Shvetsov wrote:
> В письме от пятница, 15 ноября 2019 г. 13:47:12 MSK пользователь Mart 
> Raudsepp 
> написал:
> > Ühel kenal päeval, R, 15.11.2019 kell 13:20, kirjutas Alexey 'Alexxy'
> > 
> > Shvetsov:
> > > В письме от пятница, 15 ноября 2019 г. 11:45:32 MSK пользователь
> > > Michał Górny
> > > 
> > > написал:
> > > > On Fri, 2019-11-15 at 11:41 +0300, Alexey 'Alexxy' Shvetsov wrote:
> > > > > I think problem is more global:
> > > > > * many python3_6 packages dont have python3_7 keywords, because
> > > > > its
> > > > > maintainers dont bother about it. So if you want to switch to
> > > > > python3_7
> > > > > you
> > > > > still need manualy add python3_7 use for  many packages (that
> > > > > actualy work
> > > > > without problems
> > > > > * we need policy for python packages that force enablement of new
> > > > > python
> > > > > version on existing packages.
> > > > 
> > > > Policy makes little sense if there's no way to enforce it.
> > > > 
> > > > If you tested some package on py3.7 and depgraph, just add it
> > > > there.
> > > 
> > > Some people dont like it =D And some arches (doesnt matter if i have
> > > such hw
> > > and tested on it)
> > 
> > People mostly don't like it when you throw unrelated changes on top of
> > that, under the guise of just python target addition, especially when
> > they are also broken changes and involve a revbump without maintainers
> > involvement (just PYTHON_TARGETS addition doesn't). Or if it actually
> > doesn't work with the added python targets.
> 
> As i remember some decades ago policy was: revbump needed if you change 
> chnages stuff installed on filesystem. So in case of py addition it is. So 
> what 
> changed? 
> 
> Are there some new written rules that says in what case you need revbump and 
> in what it needed? 

https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Why adding python3_8 to Gentoo sucks?

2019-11-15 Thread Michael Orlitzky
On 11/15/19 7:04 AM, Alexey 'Alexxy' Shvetsov wrote:
> 
> As i remember some decades ago policy was: revbump needed if you change 
> chnages stuff installed on filesystem. So in case of py addition it is. So 
> what 
> changed? 
> 
> Are there some new written rules that says in what case you need revbump and 
> in what it needed? 
> 

To avoid breaking dependency resolution on users' systems, you have to
make a new revision whenever you change a metadata variable that the
package manager uses: DEPEND, RDEPEND, BDEPEND, IUSE, LICENSE,
PYTHON_COMPAT, etc.

Basically, unless your change is completely trivial (updated comment,
typo fix...), you should be making a new revision by default.



Re: [gentoo-dev] Why adding python3_8 to Gentoo sucks?

2019-11-15 Thread Alexey 'Alexxy' Shvetsov
В письме от пятница, 15 ноября 2019 г. 13:47:12 MSK пользователь Mart Raudsepp 
написал:
> Ühel kenal päeval, R, 15.11.2019 kell 13:20, kirjutas Alexey 'Alexxy'
> 
> Shvetsov:
> > В письме от пятница, 15 ноября 2019 г. 11:45:32 MSK пользователь
> > Michał Górny
> > 
> > написал:
> > > On Fri, 2019-11-15 at 11:41 +0300, Alexey 'Alexxy' Shvetsov wrote:
> > > > I think problem is more global:
> > > > * many python3_6 packages dont have python3_7 keywords, because
> > > > its
> > > > maintainers dont bother about it. So if you want to switch to
> > > > python3_7
> > > > you
> > > > still need manualy add python3_7 use for  many packages (that
> > > > actualy work
> > > > without problems
> > > > * we need policy for python packages that force enablement of new
> > > > python
> > > > version on existing packages.
> > > 
> > > Policy makes little sense if there's no way to enforce it.
> > > 
> > > If you tested some package on py3.7 and depgraph, just add it
> > > there.
> > 
> > Some people dont like it =D And some arches (doesnt matter if i have
> > such hw
> > and tested on it)
> 
> People mostly don't like it when you throw unrelated changes on top of
> that, under the guise of just python target addition, especially when
> they are also broken changes and involve a revbump without maintainers
> involvement (just PYTHON_TARGETS addition doesn't). Or if it actually
> doesn't work with the added python targets.

As i remember some decades ago policy was: revbump needed if you change 
chnages stuff installed on filesystem. So in case of py addition it is. So what 
changed? 

Are there some new written rules that says in what case you need revbump and 
in what it needed? 


-- 
Best regards,
Alexey 'Alexxy' Shvetsov

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Why adding python3_8 to Gentoo sucks?

2019-11-15 Thread Mart Raudsepp
Ühel kenal päeval, R, 15.11.2019 kell 13:20, kirjutas Alexey 'Alexxy'
Shvetsov:
> В письме от пятница, 15 ноября 2019 г. 11:45:32 MSK пользователь
> Michał Górny 
> написал:
> > On Fri, 2019-11-15 at 11:41 +0300, Alexey 'Alexxy' Shvetsov wrote:
> > > I think problem is more global:
> > > * many python3_6 packages dont have python3_7 keywords, because
> > > its
> > > maintainers dont bother about it. So if you want to switch to
> > > python3_7
> > > you
> > > still need manualy add python3_7 use for  many packages (that
> > > actualy work
> > > without problems
> > > * we need policy for python packages that force enablement of new
> > > python
> > > version on existing packages.
> > 
> > Policy makes little sense if there's no way to enforce it.
> > 
> > If you tested some package on py3.7 and depgraph, just add it
> > there.
> 
> Some people dont like it =D And some arches (doesnt matter if i have
> such hw 
> and tested on it)

People mostly don't like it when you throw unrelated changes on top of
that, under the guise of just python target addition, especially when
they are also broken changes and involve a revbump without maintainers
involvement (just PYTHON_TARGETS addition doesn't). Or if it actually
doesn't work with the added python targets.


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Why adding python3_8 to Gentoo sucks?

2019-11-15 Thread Alexey 'Alexxy' Shvetsov
В письме от пятница, 15 ноября 2019 г. 11:45:32 MSK пользователь Michał Górny 
написал:
> On Fri, 2019-11-15 at 11:41 +0300, Alexey 'Alexxy' Shvetsov wrote:
> > I think problem is more global:
> > * many python3_6 packages dont have python3_7 keywords, because its
> > maintainers dont bother about it. So if you want to switch to python3_7
> > you
> > still need manualy add python3_7 use for  many packages (that actualy work
> > without problems
> > * we need policy for python packages that force enablement of new python
> > version on existing packages.
> 
> Policy makes little sense if there's no way to enforce it.
> 
> If you tested some package on py3.7 and depgraph, just add it there.

Some people dont like it =D And some arches (doesnt matter if i have such hw 
and tested on it)


-- 
Best regards,
Alexey 'Alexxy' Shvetsov

signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Package up for grabs: sys-firmware/iwl1000-ucode

2019-11-15 Thread Ulrich Mueller
This installs firmware for the Intel® Centrino® Wireless-N 1000 device.
I no longer have any hardware to test it.

The package is somewhat redundant, because sys-kernel/linux-firmware
installs the same files. (Same for all other sys-firmware/iwl*-ucode
packages.)

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] Why adding python3_8 to Gentoo sucks?

2019-11-15 Thread Michał Górny
On Fri, 2019-11-15 at 11:41 +0300, Alexey 'Alexxy' Shvetsov wrote:
> I think problem is more global: 
> * many python3_6 packages dont have python3_7 keywords, because its 
> maintainers dont bother about it. So if you want to switch to python3_7 you 
> still need manualy add python3_7 use for  many packages (that actualy work 
> without problems
> * we need policy for python packages that force enablement of new python 
> version on existing packages.

Policy makes little sense if there's no way to enforce it.

If you tested some package on py3.7 and depgraph, just add it there.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Why adding python3_8 to Gentoo sucks?

2019-11-15 Thread Alexey 'Alexxy' Shvetsov
I think problem is more global: 
* many python3_6 packages dont have python3_7 keywords, because its 
maintainers dont bother about it. So if you want to switch to python3_7 you 
still need manualy add python3_7 use for  many packages (that actualy work 
without problems
* we need policy for python packages that force enablement of new python 
version on existing packages.

В письме от четверг, 14 ноября 2019 г. 00:16:10 MSK пользователь Michał Górny 
написал:
> Hi,
> 
> I'd like to share my frustration at the state of Python in general,
> and Python packages in Gentoo.  So I'd like to 'bootstrap' python3_8 --
> that is, add it to the most common dependency, dev-python/setuptools.
> Simple thing, right?
> 
> 
> 1. There's no such thing as trivial dependency graph in Python.  If you
> think that setuptools has a few deps, you're entirely wrong.  I actually
> had to write a tool to even assemble list of deps to start with,
> and the number is: 174.  I mean, in order to enable py3.8 on setuptools,
> you have to enable it on at least 173 other packages.
> 
> Sure, some of those packages are just doc-deps or test-deps, and some
> could be avoided one way or another.  However, avoiding them is only
> temporary and involves more effort than it saves.
> 
> 
> 2. There are some packages that dropped Python 2.7 but still have 2.7
> deps.  So we need to also add py3.8 to older versions that still has
> 2.7.  Plus, some packages have explicit <-deps.  So we need to add 3.8
> to them, and hope that the old version will actually work with 3.8,
> and then to their extra dependencies.
> 
> This is all handiwork.  The number is now 178 packages, or 187 ebuilds.
> 
> 
> 3. Of course there are packages with new deps dropping keywords whose
> maintainers (or bumpers) never bothered filing a keywordreq.  Because
> why bother, somebody else will do that when it blocks everything,
> right?!
> 
> Well, guess what.  python3_8 flag is going to be masked on non-amd64
> because people didn't bother keywording new versions of their packages
> on other arches.
> 
> If you choose to realize your mistake now, and are willing to fix it,
> start keywording new versions.
> 
> 
> Here's the initial CI run:
> 
> https://github.com/gentoo/gentoo/pull/13638
> 
> The packages haven't been tested yet.  If you want to help, feel free to
> apply it locally, and run tests in all those packages, and try to
> assemble a reasonably readable report of what fails.  Then probably diff
> the failures against py3.7 because some packages probably fail there
> as well.
> 
> Of course many of those packages don't have tests at all.  Because it
> was too much effort, and the four-letter company didn't pay for them.
> Because it was too hard to use GitHub snapshot over pypi tarball that
> doesn't bundle tests because obviously nobody wants them.  Help with
> that welcome too.
> 
> Help with getting rid of py2 revdeps of py3-only packages would be very
> welcome too.
> 
> In other words, there's a lot of work to get Python near-sane in Gentoo,
> and we'd welcome all the help we can get.  TIA.


-- 
Best regards,
Alexey 'Alexxy' Shvetsov

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Why adding python3_8 to Gentoo sucks?

2019-11-15 Thread Michał Górny
On Wed, 2019-11-13 at 22:16 +0100, Michał Górny wrote:
> I'd like to share my frustration at the state of Python in general,
> and Python packages in Gentoo.  So I'd like to 'bootstrap' python3_8 --
> that is, add it to the most common dependency, dev-python/setuptools. 
> Simple thing, right?
> 

Well, it turned out that things are worse than I anticipated.
I expected *some* minor test breakage.  What we have instead is packages
being so broken that they break a lot of other packages.

So I went with plan B instead: I'll do as much testing locally
as possible, and add py3.8 when I manage to get the tests on the package
in question working, independently of the testing of all deep test deps.
This will mean that some packages will have tests disabled temporarily
for end users.

This means we've got dev-python/setuptools with py3.8 now, and we can
start slowly testing everything.  As the depgraph grows, we'll be able
to reenable tests everywhere.

I will also probably start removing either complete py2 support, or some
of its features (e.g. docs) whenever it causes trouble.  Given that both
dev-python/sphinx (primary doc building tool) and dev-python/pytest (one
of the most common test runners) no longer support py2, we're in a big
mess.


-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part