Re: Streamlining the use of Salsa CI on team packages

2019-09-13 Thread Louis-Philippe Véronneau
On 19-09-13 05 h 57, Thomas Goirand wrote:
> On 9/5/19 7:40 AM, Louis-Philippe Véronneau wrote:
>> Hello folks!
>>
>> I'd like to propose we start using Salsa CI for all the team packages. I
>> think using a good CI for all our packages will help us find packaging
>> bugs and fix errors before uploads :)
> 
> I would agree *IF* and only *IF* we find better runners than the one
> currently default in Salsa. The GCE runners are horribly slow (they are
> the smallest to avoid cost). As a result, some tests may just fail
> because of that, and it becomes just frustrating / annoying noise.

I never experienced such timeouts, but I guess I don't work on very
large packages or things that take more than a few minutes to build.

If what you describe really is caused by the default runners not being
fast enough, why couldn't we ask the Salsa team for more powerful ones?
Have you talked to them about this?

It seems to me that spending money in QA like CI runners is very
profitable for the project, as it saves everyone a lot of time dealing
with unnecessary failure caused by lack of tests. It's not like Debian
is a very poor organisation...

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: Python3 issue with Tkinter (Was: Bug#938447: scoary: Python2 removal in sid/bullseye)

2019-09-13 Thread Andrey Rahmatullin
On Fri, Sep 13, 2019 at 10:04:12PM +0200, Andreas Tille wrote:
> try:
> ttk
> Tkinter
> except NameError:
> sys.exit("Need the following installed: Tkinter, tkFileDialog, ttk")
> 
> 
> I have no idea what the call to tkk is supposed to do 
Checking that the name exists.

> and why it ends up in a NameError.
The name doesn't exist, most likely because one of the ImportErrors
didn't happen. And it didn't happen because you ran 2to3 on code that
already supports both 2 and 3, thus turning the py2 parts into the py3
ones...

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Python3 issue with Tkinter (Was: Bug#938447: scoary: Python2 removal in sid/bullseye)

2019-09-13 Thread Andreas Tille
Hi,

I think I ported scoary successfully to Python3 in Git[1].  The
command line applications seem to work but the GUI is just ending
with

   Need the following installed: Tkinter, tkFileDialog, ttk

For the more simple inspection I copy here the beginning which leads to
this:


import sys, os
import threading

try:
import tkinter
except ImportError:
#Python 3 issues
try:
import tkinter as Tkinter
except:
sys.exit("Need to have Tkinter / tkinter installed")

try:
import tkinter.filedialog
except ImportError:
# Python 3 issues
try:
from tkinter import filedialog
tkFileDialog = filedialog
except:
sys.exit("Could not find tkFileDialog / filedialog")

try:
import tkinter.ttk
except ImportError:
# Python 3 issues
try:
from tkinter import ttk as ttk
except:
sys.exit("Could not find ttk / tkinter.ttk")

try:
ttk
Tkinter
except NameError:
sys.exit("Need the following installed: Tkinter, tkFileDialog, ttk")


I have no idea what the call to tkk is supposed to do and why it ends up
in a NameError.  Any hints?

Kind regards

 Andreas.

[1] https://salsa.debian.org/med-team/scoary

-- 
http://fam-tille.de



Bug#940184: RM: python-enthoughtbase -- RoM; dead upstream; ancient; no Python 3 support and no reverse deps

2019-09-13 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal

https://pypi.org/project/EnthoughtBase/ is dead and I cannot find the new
source. The current upstream source was uploaded to Debian in 2011.

Popcon is 203, not sure why. It has only a reverse build-dep in stable and
oldstable, not reverse deps there.

Reverse deps checked with dak rm -Rnb python-enthoughtbase

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: skimage (build-)depends on python-cloudpickle which has already been dropped

2019-09-13 Thread Andrey Rahmatullin
On Fri, Sep 13, 2019 at 05:16:30PM +0800, Drew Parsons wrote:
> Python maintainers, remember, check your reverse dependencies before
> dropping your python2 packages.
> Check each of
> 
>   build-rdeps python-yourmodule
>   apt-rdepends -r python-yourmodule
> 
> and confirm the package has rdeps=0 on Sandro's list at
> http://sandrotosi.me/debian/py2removal/index.html
And grep-dctrl -FTestsuite-triggers $pkg -sPackage 
/var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources 

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye

2019-09-13 Thread Andreas Tille
Hi,

On Thu, Sep 12, 2019 at 09:08:04PM +0200, Michael Kesper wrote:
> > Since I do not have much experience with hashlib I'd be happy if 
> > someone might be able to proof-read `def Save_Cycle` in 
> > save_load.py.
> 
> This does not have anything to do with hashlib per se.
> It's just the usual mess of mixing bytestrings with strings.
> You often don't notice in Python2, it just introduces subtle bugs.
> Python3 is more strict here and doesn't allow it.
> 
> Try this:
> 
> tmp = rt.encrypt('Cycle{}'.format(pickle.dumps(objSave)))

Thanks to this hint and the other hints by Peter Green, I'm now a
bit further.
 
> As an explanation:
> 
> Python 3.7.3 (default, Apr  3 2019, 05:39:12)
> ...

Thanks as well.

> P.S.: The code is in a bad state regarding whitespace / indentation.
> This is critical to get right in Python (e.g. after a for there _has to_
> be an indentation added, Python normally uses four spaces, no tabs).

I'm aware that the code is not good - there are other issues than spaces
and tabs for instance I removed an instance of os.tempnam where upstream
simply had overridden the automatic warning.  Its unmaintained upstream
as well.

I've seen other code in Debian which is not good as well.  Its rather a
philosophical question whether it is better to drop it from Debian (and
leave its users alone may be fiddling around with the upstream code
themselves) or whether we try our best to make the code at least
acceptable.  I usually subscribe to the latter and think there is no
right or wrong here.

I'm not really sure whether we might manage in this case.  After
implementing all hints I'm now stumbling upon:


Traceback (most recent call last):
  File "/usr/bin/cycle", line 83, in OnCloseWindow
Save_Cycle(cycle.name, cycle.passwd, cycle.file)
  File "/usr/share/cycle/save_load.py", line 46, in Save_Cycle
tmp = rt.encrypt('Cycle{}'.format(pickle.dumps(objSave)))
  File "/usr/share/cycle/p_rotor.py", line 63, in encrypt
return self.cryptmore(buf, 0)
  File "/usr/share/cycle/p_rotor.py", line 88, in cryptmore
c = rotors[i][c ^ pos[i]]
TypeError: unsupported operand type(s) for ^: 'str' and 'int'


I think an  "int(c) ^ pos[i]"  could do here - but I'd like
to get some confirmation first.

Kind regards

 Andreas.

-- 
http://fam-tille.de



Re: Streamlining the use of Salsa CI on team packages

2019-09-13 Thread Thomas Goirand
On 9/5/19 7:40 AM, Louis-Philippe Véronneau wrote:
> Hello folks!
> 
> I'd like to propose we start using Salsa CI for all the team packages. I
> think using a good CI for all our packages will help us find packaging
> bugs and fix errors before uploads :)

I would agree *IF* and only *IF* we find better runners than the one
currently default in Salsa. The GCE runners are horribly slow (they are
the smallest to avoid cost). As a result, some tests may just fail
because of that, and it becomes just frustrating / annoying noise.

Would anyone but me (ie: my company) be able to provide decent runners?

Cheers,

Thomas Goirand (zigo)



Re: 2to3 adds '.' in front dir of "from dir import ..." statements (Was: [MoM] lefse migration to python 3])

2019-09-13 Thread Thomas Goirand
On 9/12/19 9:22 AM, Michael Kesper wrote:
> Hi all,
> 
> On 12.09.19 08:30, Thomas Goirand wrote:
>> I wont comment on the relative import ambiguity problem, as Ghislain
>> replied correctly. However, I do want to comment on 2to3.
>>
>> I generally recommend against using it, in the favor of other tools. 
> ...
>>
>> The advantage is that you'll get a source code that will work on both
>> Python 2 and 3. It's generally a way more easy to submit upstream, which
>> may not want to loose Python 2 compatibility.
> 
> We should stop caring about that.
> Python2 will be EOL'ed at January 1, 2020 [0].
> Python2 will vanish from next Debian release.
> Please convert into idiomatic Python3 code, that's the sane way going forward.

As much as WE are concerned, probably. However, there's still multiple
cases where you still care having compat with both versions of Python.
First, the case where upstream does care about Py2. You probably wont
succeed convincing them it is too late and they should stop caring.
There's also the case where, as a package maintainer, you see a Python
package that currently has only Py2 support. In some case, you need to
first introduce Python 3 compat without breaking Python 2 support, so
you that way get enough time to fix the reverse dependencies.

I am not buying into the argument that adding a dependency on six.py is
a problem. It generally isn't. If upstream cares about dependency-less
stuff, then probably you should ignore upstream and do the work in
Debian alone, until upstream fixes his code to do Python 3 only.

Cheers,

Thomas Goirand (zigo)



Re: skimage (build-)depends on python-cloudpickle which has already been dropped

2019-09-13 Thread Drew Parsons

On 2019-09-13 15:42, Andreas Tille wrote:

Hi,

as Peter Green found out the cloudpickle source package droped Python2
support which makes bug #938494 serious.  I guess it would be even
harder to drop python-skimage right now since this would affect
python-numpy and according to

   $ apt-cache rdepends python-numpy | sort | uniq | wc -l

339 reverse dependencies.  I have no better solution than just pinging
bug #938494 from time to time - and to ping this list to work harder on
Python3 migration.



It is something of a problem, so I'm cc:ing debian-python.

There have been a number of packages dropping python2 support 
out-of-sequence, causing this problem.  Not just cloudpickle, also 
pyqtgraph, which still had pymca as a dependent.  Fortunately pymca was 
already ready to drop the dependency, but still, how many other examples 
are there?


Python maintainers, remember, check your reverse dependencies before 
dropping your python2 packages.

Check each of

  build-rdeps python-yourmodule
  apt-rdepends -r python-yourmodule

and confirm the package has rdeps=0 on Sandro's list at 
http://sandrotosi.me/debian/py2removal/index.html


Drew