Re: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye
Hi Andrey, On Wed, Sep 11, 2019 at 07:32:33PM +0500, Andrey Rahmatullin wrote: > > $ cycle > > Traceback (most recent call last): > > File "/usr/bin/cycle", line 12, in > > from dialogs import * > > File "/usr/share/cycle/dialogs.py", line 8, in > > from cal_year import cycle, Val > > File "/usr/share/cycle/cal_year.py", line 9, in > > from dialogs import Note_Dlg > > ImportError: cannot import name 'Note_Dlg' from 'dialogs' > > (/usr/share/cycle/dialogs.py) > There are circular imports in the code so you most likely broke that by > reordering imports in various files. s/you most likely broke/2to3 most likely broke/ I admit I did not really checked what 2to3 created but I can assure you I did not simply fired up an editor and had fun reverting some import sequences. > "from cal_year import *; from dialogs import *" works, the reverse > doesn't, so the /usr/bin/cycle code is definitely problematic, not sure > about other changes. I can not confirm that from cal_year import * works at all. It works in the unpatched Python2 version. git clone https://salsa.debian.org/med-team/cycle cd cycle echo "from cal_year import *" | python quilt push -a echo "from cal_year import *" | python3 Traceback (most recent call last): File "", line 1, in File "/home/andreas/debian-maintain/salsa/med-team/cycle/cal_year.py", line 9, in from dialogs import Note_Dlg File "/home/andreas/debian-maintain/salsa/med-team/cycle/dialogs.py", line 12, in from cal_year import cycle, Val ImportError: cannot import name 'cycle' from 'cal_year' (/home/andreas/debian-maintain/salsa/med-team/cycle/cal_year.py) So may be I misinterpreted your hint but even reverting the reordering of 2to3 in my latest commit does not help. Kind regards Andreas. -- http://fam-tille.de
Re: Request to join PAPT
Hello, Is someone able to make me a member of PAPT on Salsa, please? Thanks. Christopher On Wed, 4 Sep 2019 at 20:51, Christopher Hoskin wrote: > > Hello, > > Please could I join PAPT in order to maintain a pympress package [1]. > I am a Debian Developer and already a member of DPMT. I have read and > agreed to [2]. > > Thanks, > > Christopher > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935151 > [2] > https://salsa.debian.org/python-team/tools/python-apps/blob/master/policy.rst
Re: 2to3 adds '.' in front dir of "from dir import ..." statements (Was: [MoM] lefse migration to python 3])
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. Best regards Michael [0] https://github.com/python/devguide/pull/344 https://pythonclock.org/ signature.asc Description: OpenPGP digital signature
Re: 2to3 adds '.' in front dir of "from dir import ..." statements (Was: [MoM] lefse migration to python 3])
Hi Michael, On Thu, Sep 12, 2019 at 09:22:06AM +0200, Michael Kesper wrote: > 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. I agree here. @Thomas: We talked about sixer at DebConf (thanks for the hint in any case). But I consider the additional dependency it introduces something I'd like to avoid if possible. So I first try my luck with 2to3 (and I admit I observed some surprises which did not made me that lucky at all) before I'd use sixer as fallback. Kind regards Andreas. -- http://fam-tille.de
Re: pybuild mysteriously does not copy all testfiles
On 10.09.19 16:14, Ole Streicher wrote: > Hi IOhannes, > > I have basically the same problem, funnily with almost the same subject: which was entirely intentional :-) i decided to start a new thread because i'm not sure whether the problem is really the same. but i guess, i'll just file a bug against dh-python... dfasdr IOhannes
Re: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye
On Thu, Sep 12, 2019 at 09:17:08AM +0200, Andreas Tille wrote: > > > $ cycle > > > Traceback (most recent call last): > > > File "/usr/bin/cycle", line 12, in > > > from dialogs import * > > > File "/usr/share/cycle/dialogs.py", line 8, in > > > from cal_year import cycle, Val > > > File "/usr/share/cycle/cal_year.py", line 9, in > > > from dialogs import Note_Dlg > > > ImportError: cannot import name 'Note_Dlg' from 'dialogs' > > > (/usr/share/cycle/dialogs.py) > > There are circular imports in the code so you most likely broke that by > > reordering imports in various files. > > s/you most likely broke/2to3 most likely broke/ 2to3 doesn't do that. You mentioned autopep8, it could do that. > > "from cal_year import *; from dialogs import *" works, the reverse > > doesn't, so the /usr/bin/cycle code is definitely problematic, not sure > > about other changes. > > I can not confirm that > >from cal_year import * > > works at all. It works in the unpatched Python2 version. I was just saying that (in the unpatched Python2 version) "from cal_year import *; from dialogs import *" works, the reverse doesn't, and the patched version contains the reverse. >git clone https://salsa.debian.org/med-team/cycle >cd cycle >echo "from cal_year import *" | python >quilt push -a >echo "from cal_year import *" | python3 > Traceback (most recent call last): > File "", line 1, in > File "/home/andreas/debian-maintain/salsa/med-team/cycle/cal_year.py", line > 9, in > from dialogs import Note_Dlg > File "/home/andreas/debian-maintain/salsa/med-team/cycle/dialogs.py", line > 12, in > from cal_year import cycle, Val > ImportError: cannot import name 'cycle' from 'cal_year' > (/home/andreas/debian-maintain/salsa/med-team/cycle/cal_year.py) > > > So may be I misinterpreted your hint but even reverting the reordering > of 2to3 in my latest commit does not help. I also said that other changes may be problematic too. I didn't check them. -- WBR, wRAR signature.asc Description: PGP signature
Re: 2to3 adds '.' in front dir of "from dir import ..." statements (Was: [MoM] lefse migration to python 3])
On Thu, Sep 12, 2019 at 08:30:20AM +0200, 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. For > example, you can use sixer, which I maintain in Debian, and often used > (and abused) to do Python 3 conversions. There's also 2to6, which I > don't know much about, but I've read it works about the same way as > sixer (which was specifically written for OpenStack). > > 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. I can add to this that it's non-trivial to convert from six to normal Py3 code, unless there are some tools that I didn't find. And it's really time to do that, not to convert TO six. -- WBR, wRAR signature.asc Description: PGP signature
Bug#940102: RFS: flask-jwt-simple/0.0.3-1 [ITP] -- Protecting flask endpoints with JSON Web Tokens (Python 3)
Package: sponsorship-requests Severity: wishlist Owner: Emmanuel Arias X-Debbugs-CC: debian-python@lists.debian.org Dear mentors, I am looking for a sponsor for my package "flask-jwt-simple" * Package name: flask-jwt-simple Version : 0.0.3-1 Upstream Author : Landon Gilbert-Bland * URL : https://github.com/vimalloc/flask-jwt-simple * License : MIT * Vcs : https://salsa.debian.org/python-team/modules/python-flask-jwt-simple Section : python It builds those binary packages: python3-flask-jwt-simple - Protecting flask endpoints with JSON Web Tokens (Python 3) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/flask-jwt-simple Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/f/flask-jwt-simple/flask-jwt-simple_0.0.3-1.dsc Changes since the last upload: * Initial release (Closes: #934101) Regards, -- Emmanuel Arias
Re: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye
On Thu, Sep 12, 2019 at 01:57:32PM +0500, Andrey Rahmatullin wrote: > > > There are circular imports in the code so you most likely broke that by > > > reordering imports in various files. > > > > s/you most likely broke/2to3 most likely broke/ > 2to3 doesn't do that. You mentioned autopep8, it could do that. Ahhh, well, that might be another way to mess up the sequence. Put a mental note to warn me about autodep8. > > So may be I misinterpreted your hint but even reverting the reordering > > of 2to3 in my latest commit does not help. > I also said that other changes may be problematic too. I didn't check > them. OK, I redid the patching in git[1] now. Some more wxPython 4 porting was needed as well but I somehow got the user interface working. May be some final helping hint could be how to fix leaving the program that leads to: 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 27, in Save_Cycle m.update(passwd) TypeError: Unicode-objects must be encoded before hashing I tried m.update(passwd.encode()) but this leads later to Traceback (most recent call last): File "cycle.py", line 83, in OnCloseWindow Save_Cycle(cycle.name, cycle.passwd, cycle.file) File "/home/andreas/debian-maintain/salsa/med-team/cycle/save_load.py", line 46, in Save_Cycle tmp=rt.encrypt( 'Cycle'+pickle.dumps(objSave) ) TypeError: can only concatenate str (not "bytes") to str 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. Kind regards Andreas. [1] https://salsa.debian.org/med-team/cycle -- http://fam-tille.de
should Debian add itself to https://python3statement.org ?
https://python3statement.org/ is a site documenting the projects which are supporting the policy of dropping Python2 to keep Python3 only. The site is designed for python packages specifically, to have only Python3 supported by end of 2020. But it seems to me it would be in the spirit of the site to add Debian's pledge to remove Python2 (we are currently in the middle of doing just that). Is this a thing that we want to do as a project, to add Debian to https://python3statement.org/ ? Drew
Re: Streamlining the use of Salsa CI on team packages
On 19-09-10 14 h 09, Hans-Christoph Steiner wrote: > > > 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. I think we all agree on that :) I'd like to start working on a draft modification to the DPMT and PAPT to add a part about using Gitlab CI, but I'm not sure what the process to change those files is... How were previous modifications dealt with? -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ signature.asc Description: OpenPGP digital signature
Getting rid of debian-python.readthedocs.io ?
Hi! Often I stumble on this readthedocs.io [1] website and it's badly outdated. Since we already have the Debian Wiki, I'm not sure it's worth keeping up to date, or at least no one has cared to do so in the last 4 years. If we really want a sphinx website, we should just build one on Salsa [2]. Is there anyone here with access to that page? I think we should remove it, but if people want to keep it, at least we should update it :) [1]: https://debian-python.readthedocs.io/en/latest/debian-policy.html [2]: https://wiki.debian.org/Salsa/Doc#Web_page_hosting -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ signature.asc Description: OpenPGP digital signature
Re: should Debian add itself to https://python3statement.org ?
Drew Parsons writes ("should Debian add itself to https://python3statement.org
?"):
> https://python3statement.org/ is a site documenting the projects which
> are supporting the policy of dropping Python2 to keep Python3 only.
That statement is a *pledge* to drop support for python2 by the end of
2020. Have we in fact made such a pledge ? I think I may have missed
the memo that python2 would be removed from bullseye.
I did some searching and found this
https://lists.debian.org/debian-python/2019/07/msg00080.html
which is a sane-looking transition plan but doesn't seem to have a
timeframe and doesn't seem to contemplate removal of the actual
python2 interpreter.
FTAOD I don't have an opinion about whether bullseye *should* ship
without python2. Obviously dropping it would not be desirable from
users' pov, but maintaining an ancient thing by ourselves would not be
desirable either. I think I trust the Debian Python team to make that
tradeoff.
But we need to be clear what's going on and communicate early. If
python2 is going out of bullseye then there are a lot of bugs that
should probably be marked rc fairly soon...
thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: should Debian add itself to https://python3statement.org ?
On 12.09.19 17:01, Ian Jackson wrote:
Drew Parsons writes ("should Debian add itself to https://python3statement.org
?"):
https://python3statement.org/ is a site documenting the projects which
are supporting the policy of dropping Python2 to keep Python3 only.
That statement is a *pledge* to drop support for python2 by the end of
2020. Have we in fact made such a pledge ? I think I may have missed
the memo that python2 would be removed from bullseye.
I did some searching and found this
https://lists.debian.org/debian-python/2019/07/msg00080.html
which is a sane-looking transition plan but doesn't seem to have a
timeframe and doesn't seem to contemplate removal of the actual
python2 interpreter.
FTAOD I don't have an opinion about whether bullseye *should* ship
without python2. Obviously dropping it would not be desirable from
users' pov, but maintaining an ancient thing by ourselves would not be
desirable either. I think I trust the Debian Python team to make that
tradeoff.
But we need to be clear what's going on and communicate early. If
python2 is going out of bullseye then there are a lot of bugs that
should probably be marked rc fairly soon...
it's communicated here:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=py2removal;users=debian-python@lists.debian.org
derived from
https://release.debian.org/transitions/html/python2-rm.html (not perfect, we are
still missing bug reports).
it's way too early to mark all of these as RC.
No, it's not yet decided if Python2 will be part of bullseye. But the python
command and the unversioned python packages won't be part of bullseye.
thanks,
Ian.
Re: should Debian add itself to https://python3statement.org ?
Hi, On 12-09-2019 17:01, Ian Jackson wrote: > But we need to be clear what's going on and communicate early. Yes, not on the front page, but there is (first bullet): https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#deprecated-components Paul signature.asc Description: OpenPGP digital signature
Re: should Debian add itself to https://python3statement.org ?
Hi Drew, https://release.debian.org/transitions/html/python2-rm.html Given the current progress it looks not easy to make a promise. If some upstream happen to lag behind the schedule of python3 migration, we'll just stuck there for a while. On 2019-09-12 14:46, Drew Parsons wrote: > https://python3statement.org/ is a site documenting the projects which > are supporting the policy of dropping Python2 to keep Python3 only. > > The site is designed for python packages specifically, to have only > Python3 supported by end of 2020. > > But it seems to me it would be in the spirit of the site to add > Debian's pledge to remove Python2 (we are currently in the middle of > doing just that). > > Is this a thing that we want to do as a project, to add Debian to > https://python3statement.org/ ? > > Drew
Re: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye
Hi,
On 12.09.19 16:09, Andreas Tille wrote:
> May be some final helping hint could be how to fix leaving the
> program that leads to:
>
>
> 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 27, in Save_Cycle
> m.update(passwd) TypeError: Unicode-objects must be encoded before
> hashing
>
>
> I tried
>
> m.update(passwd.encode())
>
> but this leads later to
>
> Traceback (most recent call last): File "cycle.py", line 83, in
> OnCloseWindow Save_Cycle(cycle.name, cycle.passwd, cycle.file) File
> "/home/andreas/debian-maintain/salsa/med-team/cycle/save_load.py",
> line 46, in Save_Cycle tmp=rt.encrypt( 'Cycle'+pickle.dumps(objSave)
> ) TypeError: can only concatenate str (not "bytes") to str
>
>
> 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)))
As an explanation:
Python 3.7.3 (default, Apr 3 2019, 05:39:12)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle
>>> s = 'abc123üöß'
>>> objSave = pickle.dumps(s)
>>> objSave
b'\x80\x03X\x0c\x00\x00\x00abc123\xc3\xbc\xc3\xb6\xc3\x9fq\x00.'
>>> type(objSave)
>>> print('Cycle'+pickle.dumps(objSave))
Traceback (most recent call last):
File "", line 1, in
TypeError: can only concatenate str (not "bytes") to str
>>> print('Cycle{}'.format(pickle.dumps(objSave)))
Cycleb'\x80\x03C\x16\x80\x03X\x0c\x00\x00\x00abc123\xc3\xbc\xc3\xb6\xc3\x9fq\x00.q\x00.'
Best wishes
Michael
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).
signature.asc
Description: OpenPGP digital signature
Re: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye
but this leads later to Traceback (most recent call last): File "cycle.py", line 83, in OnCloseWindow Save_Cycle(cycle.name, cycle.passwd, cycle.file) File "/home/andreas/debian-maintain/salsa/med-team/cycle/save_load.py", line 46, in Save_Cycle tmp=rt.encrypt( 'Cycle'+pickle.dumps(objSave) ) TypeError: can only concatenate str (not "bytes") to str String handling changed significantly between python2 and python3. Python 2 is "byte strings by default", type "str" was used for byte strings and type "unicode" was used for unicode strings. Implicit conversions between the two were allowed. Python 3 is "unicode by default", type "bytes" is used for byte strings and type "str" is used for unicode strings. There is no implict conversion between unicode strings and byte strings. "pickle.dumps" returned a bytes object, and you tried to concatenate it to a str object. You need to change 'Cycle' to b'Cycle'. Also python 3 bytes objects behave a bit differently from python 2 str objects. To accommodate this I believe you need the following changes in p_rotor.py "|for c in map(ord, buf):|" -> "|for c in buf:|" "|return ''.join(map(chr, outbuf))|" -> "|return bytes(outbuf)|" "|for c in map(ord, key):|" -> "for c in key:"
