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
Re: RFS: python-gnatpython [second try]
And of course I forgot to actually CC debian-python@l.d.o. Sorry for the spam. On Wed, Jan 18, 2012 at 05:01:54PM +0100, Simon Chopin wrote: > Hi! > > CCing the debian-python mailing list. > On Wed, Jan 18, 2012 at 03:55:57PM +0100, Xavier Grave wrote: > > Dear mentors, > > > > I am looking for a sponsor for my package "python-gnatpython". > > > > * Package name: python-gnatpython > >Version : 54-1 > >Upstream Author : AdaCore > > * URL : http://forge.open-do.org/projects/gnatpython > > * License : GPL-2+ and GPL-3+ > >Section : python > > > > It builds those binary packages: > > > > python-gnatpython - python framework to ease development of test suites > > python-gnatpython-doc - python framework to ease development of test > > suites (examples) > > > > To access further information about this package, please visit the > > following URL: > > > > http://mentors.debian.net/package/python-gnatpython > > > > Alternatively, one can download the package with dget using this command: > > > > dget -x > > http://mentors.debian.net/debian/pool/main/p/python-gnatpython/python-gnatpython_54-1.dsc > > > > This new package is a build dependency for the polyorb package. > > > > I would be glad if someone uploaded this package for me. > > It is my first python package and I have followed most advices from > > Jakub Wilk [1], thanks to him again. > > > > Kind regards, > > > > Grave Xavier > > [1] http://lists.debian.org/debian-python/2011/09/msg00078.html > > Please note that I am not a DD, and not even a very experienced > packager. > > It might be worth asking the Debian Python Module Team for > sponsoring, hence the CCing to them. Other than that, I did not really > have a look at the package itself, but I ran a pedantic Lintian check on > it and there are some nitpicks: > > $ lintian --pedantic -EI ../python-gnatpython_54-1_amd64.changes > P: python-gnatpython source: debian-control-has-unusual-field-spacing > line 19 > I: python-gnatpython source: debian-watch-file-is-missing > P: python-gnatpython: no-upstream-changelog > I: python-gnatpython: spelling-error-in-copyright GNU Public License > GNU General Public License > I: python-gnatpython: extended-description-is-probably-too-short > I: python-gnatpython: capitalization-error-in-description python Python > I: python-gnatpython: spelling-error-in-manpage > usr/share/man/man1/mainloop.1.gz adress address > P: python-gnatpython-doc: no-upstream-changelog > I: python-gnatpython-doc: spelling-error-in-copyright GNU Public > License GNU General Public License > I: python-gnatpython-doc: capitalization-error-in-description python > Python > P: python-gnatpython-doc: example-unusual-interpreter > usr/share/doc/python-gnatpython-doc/examples/echo_testsuit > > It would be nice to fix at least the spelling errors. Also, the watch > file is always a nice thing to have where possible. It allows other > developers to easily download the .orig.tar, and of course is used to > warn the maintainer of new versions. > > Cheers, > > Simon signature.asc Description: Digital 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 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
Re: py.test is not in debian anymore
Hi Tiziano, On Mon, Apr 02, 2012 at 03:39:31PM +0200, Tiziano Zito wrote: > here a couple of short comments: > > - why do you build for all python versions and then only install > for the default versions? > > - in override_dh_auto_test, it would probably be better not to > introduce your own ENABLE_TESTS flag. you should rely on the > DEB_BUILD_OPTIONS variable. something like this should do: > ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) Well, actually it was to disable the tests by default for the first upload, since py.test isn't in the archive. Nonetheless, it is a good idea to add support for DEB_BUILD_OPTIONS, I suppose I can just comment out the whole section as well. > - why did you choose to rename the py.test script for python3 to > py3.test? I think the upstream convention of having > py.test-2.6, py.test-2.7, py.test-3.2, etc., seems > more sensible and also consistent with other packages (see for > example ipython: ipython2.6 ipython2.7 ...) > at the end one could have a py.test link to point to the > py.test-2.x where x is the default (probably 7 for wheezy), and > same thing for the python3 version, where py.test-3 may point to > py.test-3.2 on wheezy. I began to do so in my first attempts, but I didn't want the package to depend on non-default Python versions, which it would have if I provided every script because of the strict shebangs. Incidentally, the build for all version comes from this attempt, I've forgotten to clean it up. In any case, it doesn't cost much to build for every available version and prevents any syntax error. For the py3.test, I cannot remember why I used that name. The reason must not have been a good one if I've forgotten it, though ;-). py.test-3 is fine as well. IMHO there is three alternatives: * Provide the scripts for all Python versions available, py.test[-3] pointing to the default Python version. It would mean that the package would depend on python-all and python3-all because of the shebang. I strongly dislike this one. * Only provide the default Python version scripts. This is what I do now. If the users want to use different Python versions, they can always use "python$VERSION -m pytest" (since 2.0). * Do it the ipython way: use the python scripts for py.test and py.test-3, and use a shell script that detects the Python version to use based on the script name, and fails graciously if it isn't available. I hadn't thought about the third alternative until you mentioned ipython, but it seems a rather good approach. I'll take a shot at it shortly. Cheers, Simon signature.asc Description: Digital 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
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: 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 , 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: 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: 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
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 Jakub Wilk (2013-05-08 12:29:58)
> * Simon Chopin , 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: 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
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
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
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
