RE: Request to join the DPT
On jeu. 30 mai 2024 13:57:58, Simon Chopin wrote: > Hi folks, > > Could I please join the DPT Salsa team? My Salsa login is `schopin`. > > My rationale for joining isn't because of specific packages, but rather > that as part of my work in Ubuntu I tend to touch a lot of Python > packages, and being a member of the DPT would reduce the friction in > submitting those changes back to Debian (my eventual goal being becoming > a DD so that friction gets reduced even further). Forgot to add: I have read the policy at https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst and I accept it. > > Cheers, > > Simon
Request to join the DPT
Hi folks, Could I please join the DPT Salsa team? My Salsa login is `schopin`. My rationale for joining isn't because of specific packages, but rather that as part of my work in Ubuntu I tend to touch a lot of Python packages, and being a member of the DPT would reduce the friction in submitting those changes back to Debian (my eventual goal being becoming a DD so that friction gets reduced even further). Cheers, Simon
python-cryptography, Rust, and OpenSSL 3.0
Hi, TL;DR: Does it make sense to upload the intermediary upstream version 3.4.8 or rather wait for someone to work on the Rust-based later versions? I'm currently working on the OpenSSL 3.0 transition in Ubuntu, and python-cryptography in its current version in Debian and Ubuntu does not support it[0]. The current version of the package is 3.3.2-1, whereas upstream is at 36.0. Versioning scheme notwithstanding, upstream moves with a rapid pace, since 3.3.2 came out in February 2021. This package has recently gained some notoriety[1] for wanting to use Rust to replace parts of its C core. 3.4 introduces an optional dependency on the Rust toolchain, which became mandatory in 35.0 (think 3.5). Said 35.0 release also brought OpenSSL 3.0 support, which is why I first tried to update the package directly to 35.0 (36.0 wasn't out at the time), but it needs a good few packages that aren't, or weren't at the time, in the Debian archive, with transitive dependencies on crates that aren't necessarily version-compatible with what's currently in Debian. Furthermore, dh-python and pybuild aren't necessarily ready for the setuptools Rust extension. So, instead I opted for packaging the last Rust-optional version, 3.4.8, and backported the necessary OpenSSL 3.0 patches. I posted the result of this work on Salsa[2]. Now that the OpenSSL 3 transition has started in Ubuntu, I plan on uploading this package to our archive as I lack the time to do the necessary work for the Rust enablement, but I'm wondering if it makes sense to do the same in Debian? Cheers, Simon PS: please keep me in CC, as I'm not subscribed to the ML. [0]: https://bugs.launchpad.net/ubuntu/+source/python-cryptography/+bug/1946189 [1]: https://lwn.net/Articles/845535/ [2]: https://salsa.debian.org/python-team/packages/python-cryptography/-/merge_requests/6 -- Simon Chopin Foundations Team Ubuntu MOTU simon.cho...@canonical.comscho...@ubuntu.com
Re: Inconsistency in source package naming for python modules
Quoting Thomas Goirand (2013-07-08 15:59:02) Hi, Over the last months, I've seen lots of inconsistency in the source package naming scheme in the python module maintained in the team. Sometimes, module X will have its source package called python-X or just X. If we have a python module named X, then IMO, we should stick to call the source package python-X, and not just X. Why? Because AFAICT it seems that there's a consensus in Debian that, if a package is producing a single binary, then its source package should have the same name. I can find at least one source that prones something different: [1] http://www.debian.org/doc/manuals/maint-guide/first.en.html#namever Cheers, Simon signature.asc Description: signature
Re: RFS: bunch, kitchen, grapefruit, fabulous, stomper, txws, txzmq, moksha.common, moksha.hub
Quoting Jakub Wilk (2013-05-08 12:29:58)
* Simon Chopin chopin.si...@gmail.com, 2013-05-07, 20:04:
(or RFR, for Jakub :P)
Oh hi!
fabulous: Makes your terminal output totally fabulous
fabulous/fonts/cmr10.ttf license doesn't look free to me.
I've removed all the fonts from the tarball since their license wasn't
specified anyway — I had to go look in other packages to find them.
I guess the FTP masters disagree with you on the license though, as one
can find this font at least in fonts-lyx.
I see this in debian/patches/build_xterm256_ext:
-library = expanduser('~/.xterm256.so')
+library = '/usr/share/lib/xtermspeedup.so'
Errr, /usr/share/lib/?
Ooops. Fixed
I don't see a point of making fabulous-xtermspeedup a separate package.
It's tiny, and doesn't bring any extra dependencies.
Yes, but it's arch:any whereas the rest is arch:all.
The package FTBFS when I build only arch-dependent packages:
|dh_sphinxdoc -a
| dh_sphinxdoc: Sphinx documentation not found
| make: *** [binary-arch] Error 2
Shouldn't dh_sphinxdoc -a be a NOP?
If I were the maintainer, I would remove (with a Debian-specific patch)
this junk from setup.py:
| from ez_setup import use_setuptools
| use_setuptools(version='0.6c11')
I always thought this was only a convoluted way to check for the version
and never bothered to actually look at ez_setup. Now I understand why
you'd remove it, and will do the same from now on.
lintian4python emits (among others):
x: python-fabulous: except-without-exception-type
usr/share/pyshared/fabulous/logs.py:86
x: python-fabulous: except-without-exception-type
usr/share/pyshared/fabulous/utils.py:95
x: python-fabulous: except-without-exception-type
usr/share/pyshared/fabulous/xterm256.py:104
Patched and reported upstream.
Cheers,
Simon
signature.asc
Description: signature
Re: python3.3 status
Quoting Scott Kitterman (2013-05-24 00:19:06) On Tuesday, May 07, 2013 02:01:26 PM Jakub Wilk wrote: [...] pytest FTBFS TODO Fixed signature.asc Description: signature
Re: RFS: bunch, kitchen, grapefruit, fabulous, stomper, txws, txzmq, moksha.common, moksha.hub
Quoting Thomas Goirand (2013-05-08 17:45:12) On 05/08/2013 02:04 AM, Simon Chopin wrote: bunch: Dot-accessible Python dictionary (a la JavaScript objects) kitchen: Cornucopia of useful Python code grapefruit: Python module to manipulate color information easily fabulous: Makes your terminal output totally fabulous I thought these were jokes, not package names! :) Hey, I didn't choose the names :-). /me points to the Fedora folks. Cheers, Thomas P.S: Lucky the short desc are good enough, though even after reading the one of kitchen, I still don't know what it does. Would it be possible to review that one? Or it's really just a bunch of functions impossible to describe better without itemizing them? Well, yes, it is a bunch of functions not especially related to one another that the Fedora devs found useful in various bits of their infrastructure. signature.asc Description: signature
RFS: bunch, kitchen, grapefruit, fabulous, stomper, txws, txzmq, moksha.common, moksha.hub
(or RFR, for Jakub :P) Hello, I'm looking for sponsors for all the packages above, all dependencies of fedmsg in a way or another. bunch, kitchen and grapefruit (I think) have all been already reviewed by Jakub Wilk, all the remarks being adressed TTBMK. From the ITPs: bunch: Dot-accessible Python dictionary (a la JavaScript objects) kitchen: Cornucopia of useful Python code grapefruit: Python module to manipulate color information easily fabulous: Makes your terminal output totally fabulous stomper: Python client implementation of the STOMP protocol txws: Twisted WebSockets wrapper txzmq: ZeroMQ bindings for Twisted moksha.common: Common components for Moksha moksha.hub: Hub components for Moksha Moksha is a combination of Web framework and messaging hub that is written on top of widely-used and tested components such as Twisted, 0mq or TurboGears. All packages are available in the DPMT repository. For those wondering, I'm left with m2ext, python-fedora and fedmsg itself to package, and I might actually drop python-fedora from the list :-) Cheers, Simon signature.asc Description: signature
Upload of python-mock 1.0.1 to Debian unstable
Hi, I'd like to know if/when you plan to upload python-mock 1.0.1 in unstable (it sits at the moment in experimental). One of my packages, pytest, currently FTBFS in unstable due to the recent Python 3.3 changes and the new upstream version build-depends on python-mock = 1.0.1, so I guess you'd understand my desire to get this fixed quickly. Cc-ed Sebastian as he was my last sponsor for pytest Cheers, Simon signature.asc Description: signature
Re: RFS: kitchen, bunch, grapefruit
Hi Jakub,
First off, as usual, thanks for your thorough reviews, as usual.
Quoting Jakub Wilk (2013-04-27 21:06:24)
* Simon Chopin chopin.si...@gmail.com, 2013-04-26, 10:43:
I'm looking for a sponsor for my three Python modules, kitchen, bunch
and grapefruit,
I took a bite of grapefruit:
Policy v3.9.4 made build-{arch,indep} targets mandatory. These targets
were not implemented in dh until 8.1.0. So if you want to claim
compliance with standards version 3.9.4, you should build-depend on at
least this version.
Thanks for the hint, I didn't know that.
setup.py uses setuptools when it's available. To make build
deterministic, you must either build-depend on python-setuptools, or
disable the setuptools import (in a Debain-specific patch).
python-setuptools it is.
Something is very wrong with the package short description. :)
Copy-pasta gone wrong. I blame Vim ;-)
s/let/lets/, s/Primary/primary/ in the long description.
Typos in upstream code:
amout - amount
appart - apart
froming - forming
functionnalities - functionalities
instanciation - instantiation
specifed - specified
substract - subtract
widers - wider
All corrected/patched.
all dependencies (of dependencies) of fedmsg[1]
Out of interest, why does fedmsg need a color conversion library?
fedmsg provides a few command-line utilities, which use python-fabulous
to color the output, which in turn needs this library.
I don't intend to sponsor any of these, but I explored kitchen a bit:
Short description doesn't need to start with a capital letter.
Fixed.
The list in the long description has inconsistent capitalization and
punctuation:
- the first item starts with a lowercase letters, but others with a
capital
letter;
- the second item ends with full stop, but others don't.
Fixed (and removed the second item, see below)
License field formatting in d/copyright works like Description in
d/control. So in the License: Python paragraph, you should either
indent first lines of every item, or un-indent the remaining lines.
License/copyright status of these files are not documented in the
copyright file:
kitchen/pycompat27/subprocess/_subprocess.py is not
kitchen/pycompat24/base64/_base64.py
Fixed.
Typos:
afterall - after all
causethe - cause the
defnining - defining
documenation - documentation
everytime - every time
inpput - input
interchangably - interchangeably
represntable - representable
Supackages - Subpackages
Marcus Kuhn - Markus Kuhn
Fixed and reported upstream.
You should probably quote the original Kuhn's license in d/copyright,
too.
Good idea :-)
You might want ask upstream to update their copy of GPL; it has still
the old FSF address.
Done
We don't want embedded copies of stdlib modules in the binary package.
I've simply removed the pycompat* modules as they're not relevant in
Debian anyway, and added a note in README.Debian about it.
The bunch clean error and the debhelper version being too low are fixed
as well, I'm just too lazy to fetch the quotes :-)
Cheers,
Simon
signature.asc
Description: signature
RFS: kitchen, bunch, grapefruit
Hi, I'm looking for a sponsor for my three Python modules, kitchen, bunch and grapefruit, all dependencies (of dependencies) of fedmsg[1], and available in the DPMT SVN repo. The packages are Lintian-clean, and the lintian4py various pyflakes errors and warnings have been reported upstream, or will be in a close future. Note that once those have cleared NEW, there will be another bunch of packages waiting for nice DDs to upload them ;-). Cheers, Simon signature.asc Description: signature
Re: [Python-modules-team] python-modules-team moderation bankruptcy
Quoting Jakub Wilk (2013-04-11 13:15:32) Due to unfortunate circumstances, python-modules-team@lists.a.d.o hasn't been moderated for years. We have currently about 4500 messages in the moderation queue; vast majority of them is spam. I don't believe that it's worth anyone's time to go through them all, especially since value of most (all?) non-spam messages is very little after all these months/years. Therefore, unless someone objects, I'm going to declare moderation bankruptcy: I'll discard all the messages older that a month, and start moderation anew. If your message is currently held in python-modules-team moderation queue, and you want it to reach the list, please tell us NOW. How can we contribute to the spam filtering effort ? signature.asc Description: signature
Re: py.test is not in debian anymore
debian-python@lists.debian.org Cc-ed. On Wed, 28 Mar 2012 20:55:54 +0200, Tiziano Zito tiziano.z...@bccn-berlin.de wrote: hi simon, Hi ! I am a user of py.test and maintainer of the python-mdp package, which used to suggest python-py and used py.test. now that py.test is not contained in python-py anymore, I was thinking about filing an RFP for pytest. you already filed an ITP for that, which is owesome :) yarik, a seasoned DD in Cc, would be willing to sponsor, but being really busy, asked me to help him review your package. if you agree I could send you my comments about your package, so that with the help of yarik you can make it fit for a speedy upload to debian. what do you think? Only good things :-). The more review the package gets, the better it should become. Unfortunately, I have virtually no free time until next week, which means I will not be able to address any comment you could have ATM. As I intend to package pytest under the umbrella of the DPMT, the packaging is in its SVN, and I added an RFS for it on the TODO wiki page. Cheers, Simon -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120329012827.57487A0204@beltira
PMPT: Request to join
Hi ! My name is Simon, and I hereby request to join the Python Modules Packaging Team :-). As stated in my Alioth request, I have indeed interest in maintaining various modules as dependencies of some beets plugins[1]. A little bit about myself: I am a French CS student currently living in Berlin and looking for a university, hence a lot of free time in my hands. I do not have extensive packaging knowledge nor am I a Python guru, but I am willing to learn, and wish to contribute back to Debian. Cheers, Simon [1] http://beets.radbox.org/ signature.asc Description: Digital signature
