Re: Streamlining the use of Salsa CI on team packages
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)
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)
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
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
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
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
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])
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
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
