Re: Please upload the latest version of python-flask-cors ready in git
On Thu, Dec 17, 2020, at 04:28, Louis-Philippe Véronneau wrote: > Hello! > > Bastian Germann asked a month ago for the package python-flask-cors [1] > to be sponsored by someone from the Python Team. > > Since you put the Team in "Uploaders", I'm writing to you to know if it > would be possible to make an upload from the latest git commit in Salsa. > > Bastian fixed a CVE and a FTBFS bug (as well as updated the package) and > I did a few tweaks left and right. Hey, I think you're being overly conservative here; That package has had a RC bug open for almost a year. It's a security-sensitive package with open security issues; I think it's more than ripe for a team-upload. [rant about team in Uploaders deleted] > I believe the package should thus be ready to upload as is, as the only > thing missing is "dch -r" :) > > If you don't have the time to do so, I would be happy to make the upload > for you. Looks like Stewart doesn't have DM upload rights to this package so a DD would have to sponsor it anyway. HTH, -- Nicolas Dandrimont
Re: The python command in Debian
Hi Matthias, others, On Thu, Jul 9, 2020, at 15:26, Matthias Klose wrote: > As written in [1], bullseye will not see unversioned python packages and the > unversioned python command being built from the python-defaults package. > > It seems to be a little bit more controversial what should happen to the > python > command in the long term. Some people argue that python should never point to > python3, because it's incompatible, however Debian will have difficulties to > explain that decision to users who start with Python3 and are not aware of > the 2 > to 3 transition. So yes, in the long term, Debian should have a python > command > again. > > One solution could be not to ship the python command in bullseye, forcing > users > to adjust their local installations. This has the advantage that the error of > an unknown interpreter should be pretty clear. But leaves users without a > python command for the next two years until bullseye+1. > > Describing here a solution which is implemented for Ubuntu focal (20.04 LTS). > A > new source package what-is-python (-perl-dont-hurt-me) ships binary packages > python-is-python2, python-dev-is-python2, python-is-python3 and > python-dev-is-python3. The python-is-python2 package provides the python > package, such that packages that still depend on python are not removed on a > distro upgrade. On new installs, python-is-python3 is not installed by > default, > but the user gets a hint from command-not-found to install the package if he > tries to run python. Package dependencies on the new four binary packages > have > to be disallowed in the Python policy. Note that such a package including the > Provides should only be uploaded once all dependencies on the unversioned > python > packages are gone. So I see that the removal of `/usr/bin/python`-shipped-by-python-defaults has happened as planned. Thanks! I've just got a friend ask me about what to do to get /usr/bin/python to point at python3; Do you have any plan of uploading what-is-python for use in bullseye, at least without the python-is-python2 Provides for python as a first step (to keep the current "breakage")? In any case I think the python packaging policy at https://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html should get an update to match the current status quo related to /usr/bin/python; My friend looked at it and were confused not to find a /usr/bin/python anymore. Thanks, -- Nicolas Dandrimont
Re: Allow installation on buster of a package not supporting 3.7 (async/await syntax error when generating bytecode)
Hi! * Adam Cécile [2018-11-08 09:15:59 +0100]: > Hello list, > > > I have a package working perfectly fine on Pyrhon 3.6 but using async/await > methods so it cannot work on python 3.7 at the moment. > During package compilation, I popd 3.7 from supported version returned by > py3version and it allows me to build the package just fine: > > Problem: I cannot install it. Despite 3.7 was not "enabled" during build, > when installing debian helpers try to compile bytecode for both 3.6 and 3.7 > and fails. Is there any way to workaround that ? You can use the bcep (bytecompile exception pattern) mechanism. The documentation can be found in dh_python3(1)[1] and /usr/share/doc/dh-python/README.PyDist, and you can find some examples in codesearch. [1] https://manpages.debian.org/unstable/dh-python/dh_python3.1.en.html#bcep_files HTH, -- Nicolas Dandrimont BOFH excuse #227: Fatal error right in front of screen signature.asc Description: PGP signature
Updating the Python Modules *Team* policy
[
I'm *not* talking about the Python "packaging" Policy[0], which is under the
prerogative of the python{,3}-defaults maintainers.
[0] https://www.debian.org/doc/packaging-manuals/python-policy/
]
Dear all,
The DPMT policy[1] is still talking about Alioth and git-dpm, which is ever so
slightly outdated. valhalla submitted a MR[2] a while ago to fix some of these
references, but that ended up being a dead letter.
[1]
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
[2] https://salsa.debian.org/python-team/tools/python-modules/merge_requests/1
There was some confusion about who is the caretaker of this policy, I think
stemming from the fact that the "main" Python packaging policy also needs some
updates.
I feel the consensus is that that PR should just get merged and that the DPMT
policy can just be updated by team consensus on this list. Consider this a
heads up that I'll merge this in the next few days, unless there's any issue
people can come up with.
A MR describing the git-buildpackage workflow would also be appreciated.
Cheers,
--
Nicolas Dandrimont
BOFH excuse #378:
Operators killed by year 2000 bug bite.
signature.asc
Description: PGP signature
Report from the Python BoF @ DebConf18
Hey folks, Today, we've had a productive BoF session at DebConf18, with around 12 people in attendance (unfortunately, this was not held in a recorded room). Here are the raw notes: https://gobby.debian.org/export/debconf18/bof/python There are two team-wide items that would be of general interest: 1/ We agreed that we would like Python 3.7 as default Python3 in Buster. As this needs a lot of work still, we set ourselves an internal deadline of October 2018 to assess whether releasing with 3.7 as default is feasible, leaving us 2.5 months to do any followup transitions that would be needed before the start of the transition freeze. Matthias will talk to the Release Team with this plan to "pre-book" a transition slot and make sure this would fit within their freeze plans Of course, in the meantime, we need to keep pushingupstreams to fix the async and generator-related issues that arise in 3.7. This also means finding solutions for edge-cases such as astroid, whose 2.0 branch is the only to support Py3.7, but also drops 2.x support. We may have to consider removing some leaf packages as well. 2/ Ondrej Novy will do a mass-change from git-dpm to gbp on team packages. Related to this, Piotr will review and amend the team policy if necessary, as well as work on the pipeline to make sure the policy gets published from salsa. 3/ Finally, there was some conversation about looking into debhelper's automatic detection of documentation packages (dh_installdocs in compat 11, policy §12.3 / 3.9.7), to actualy move documentation to the python-$foo-doc package if it exists. Stuart has taken this action item. Cheers, -- Nicolas Dandrimont BOFH excuse #149: Dew on the telephone lines. signature.asc Description: PGP signature
Re: python-pkg-resources
Hi! * Vincent Bernat <ber...@debian.org> [2018-04-20 23:21:45 +0200]: > I've got a bunch of bugs like this one: > bugs.debian.org/cgi-bin/bugreport.cgi?archive=yes=896229 > > I didn't see any discussion about this MBF. https://lists.debian.org/debian-devel/2018/04/msg00258.html and (longish) thread. I guess a cross-post to this list would have been useful, but the deed is done now. HTH, -- Nicolas Dandrimont BOFH excuse #365: parallel processors running perpendicular today signature.asc Description: PGP signature
Bug#851290: ITP: flask-limiter -- Rate-limiting for Flask routes
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont <ol...@debian.org> * Package name: flask-limiter Version : 0.9.3 Upstream Author : Ali-Akber Saifee * URL : http://flask-limiter.readthedocs.org/ | https://github.com/alisaifee/flask-limiter * License : MIT Programming Lang: Python Description : Rate-limiting for Flask routes Flask is a micro web framework for Python based on Werkzeug, Jinja 2 and good intentions. . Flask-Limiter provides rate limiting features to flask routes. It has support for a configurable backend for storage with current implementations for in-memory, redis and memcache. This package will be maintained under the umbrella of the Debian Python Modules Team
Bug#851272: ITP: python-limits -- Rate limiting utilities for Python
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont <ol...@debian.org> * Package name: python-limits Version : 1.2.1 Upstream Author : Ali-Akber Saifee <a...@indydevs.org> * URL : https://limits.readthedocs.org * License : MIT Programming Lang: Python Description : Rate limiting utilities for Python limits is a Python module providing utilities to implement rate limiting using various strategies, such as fixed or moving windows, and various storage backends, such as in in-memory storage, Redis or memcached. limits is the back-end and base implementation of the rate-limiting algorithms provided by Flask-Limiter. The module will be maintained inside the Debian Python Modules Team
Bug#851255: ITP: python-rediscluster -- Python interface to a cluster of Redis key-value stores
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont <ol...@debian.org> * Package name: python-rediscluster Version : 0.5.3 Upstream Author : Salimane Adjao Moustapha <m...@salimane.com> * URL : https://github.com/salimane/rediscluster-py * License : MIT Programming Lang: Python Description : Python interface to a cluster of Redis key-value stores Redis is a key-value database in a similar vein to memcache but the dataset is non-volatile. Redis additionally provides native support for atomically manipulating and querying data structures such as lists and sets. . rediscluster is a Python library adapting the upstream Redis bindings to enable sharding among different Redis instances in a transparent, fast, and fault tolerant way. This package will be maintained under the umbrella of the Debian Python Modules Team. It is a dependency of python-limits, which in turn is a dependency of Flask-Limiter which I intend to package.
Bug#851153: ITP: hiro -- time manipulation utilities for Python
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont <ol...@debian.org> * Package name: hiro Version : 0.2 Upstream Author : Ali-Akber Saifee * URL : http://hiro.readthedocs.org/ / https://github.com/alisaifee/hiro * License : MIT Programming Lang: Python Description : time manipulation utilities for Python The hiro module provides a context-manager which hijacks a few commonly used time function to manipulate time in its context. It allows you to rewind, forward, freeze, unfreeze, and scale time according to given settings. . Most notably, the builtin functions time.sleep, time.time, time.gmtime, datetime.now, datetime.utcnow and datetime.today behave according the configuration of the context. hiro is a test dependency for python-limits, which itself is a dependency for flask-limiter which I intend to package. I will maintain those packages under the Debian Python Modules Team umbrella.
Bug#794637: ITP: celerymon -- real-time monitoring of Celery workers
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont ol...@debian.org * Package name: celerymon Version : 1.0.3 Upstream Author : Ask Solem a...@celeryproject.org * URL : https://github.com/celery/celerymon * License : BSD 2-clause Programming Lang: Python Description : real-time monitoring of Celery workers Celery is an open source asynchronous task queue/job queue based on distributed message passing. It is focused on real-time operation, but supports scheduling as well. . Celerymon provides an HTTP API and a web-interface to do real-time monitoring of the workers in a Celery cluster. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150805094609.25732.41750.report...@darboux.home.olasd.eu
Re: Bug#794637: ITP: celerymon -- real-time monitoring of Celery workers
* Nicolas Dandrimont ol...@debian.org [2015-08-05 11:46:09 +0200]: Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont ol...@debian.org * Package name: celerymon Version : 1.0.3 Upstream Author : Ask Solem a...@celeryproject.org * URL : https://github.com/celery/celerymon * License : BSD 2-clause Programming Lang: Python Description : real-time monitoring of Celery workers Celery is an open source asynchronous task queue/job queue based on distributed message passing. It is focused on real-time operation, but supports scheduling as well. . Celerymon provides an HTTP API and a web-interface to do real-time monitoring of the workers in a Celery cluster. Celerymon is dead upstream and has been superseded by python-flower, sorry for the noise. -- Nicolas Dandrimont BOFH excuse #377: Someone hooked the twisted pair wires into the answering machine. signature.asc Description: Digital signature
Re: DebConf14 svn-git migration BOF notes
* Stuart Prescott stu...@debian.org [2014-08-27 13:29:39 +1000]: Hi! svn history, do we keep it? with git-svn, or with the kde git-svn-import, each tag becomes a branch which is a pain. BTW svn-all-fast-export is the package that contains the kde git-svn-import tool -- it does rather have a naming crisis. svn-all-fast-export accepts a mapping that takes an svn tag and turns it into a git tag. It also takes svn branches and map them into git branches. Further details are at: https://wiki.debian.org/PackagingWithGit/Svn- buildpackageConversion#Importing_using_svn-all-fast-export and if you `debcheckout translate-toolkit` you will find a git repo that looks like a git repo for git-buildpackage should, even if some of the older commit messages are prefixed by '[svn-upgrade]'. The mapping rules on that wiki page are the ones I used for translate-toolkit and most packages would have the same rules with only s/mypackage/otherpackage/. Hey gang, I did a migration using svn-all-fast-export a (long) while back. The results are on http://anonscm.debian.org/cgit/users/olasd/dpmt/. I've been very annoyed with the svn tag - git branch mapping, and I haven't had time to script fixing those up. I also have no idea how to graft the upstream history there if we want sourceful repos (but I guess we can just not care about it). The stuff I used is in alioth:/home/users/olasd/dpmt_migration and should be world-readable. If you're so inclined, I could probably walk you through it, but considering that that was done 9 months ago, it is probably better to start from scratch anyway. Cheers, -- Nicolas Dandrimont BOFH excuse #122: because Bill Gates is a Jehovah's witness and so nothing can work on St. Swithin's day. signature.asc Description: Digital signature
Re: Proposed changes to python-virtualenv
* Barry Warsaw ba...@debian.org [2014-06-02 16:51:24 -0400]: On Jun 02, 2014, at 04:43 PM, Donald Stufft wrote: Sounds reasonable to me, the only “downside” is that virutalenv will default to Python 3, which is probably not what most people want (however they can do virtualenv -p python2). But it's what most people *should* want wink. Seriously though, I wonder if this is a problem or if some transition or wider announcement needs to be made. I think adding a note to NEWS.Debian would be nice to avoid surprises for people on upgrades. But it seems to be the sensible thing to do. Cheers, -- Nicolas Dandrimont BOFH excuse #384: it's an ID-10-T error signature.asc Description: Digital signature
Bug#747481: ITP: backports.ssl-match-hostname -- Backport of the Python 3.2 SSL hostname checking function
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont ol...@debian.org * Package name: backports.ssl-match-hostname Version : 3.4.0.2 Upstream Author : Brandon Craig Rhodes * URL : https://bitbucket.org/brandon/backports.ssl_match_hostname * License : Python Programming Lang: Python Description : Backport of the Python 3.2 SSL hostname checking function The Secure Sockets layer is only actually secure if you check the hostname in the certificate returned by the server to which you are connecting, and verify that it matches to hostname that you are trying to reach. . But the matching logic, defined in RFC2818, can be a bit tricky to implement on your own. So the ssl package in the Standard Library of Python 3.2 and greater now includes a match_hostname() function for performing this check instead of requiring every application to implement the check separately. . This package contains a backport of the ssl.match_hostname function for Python 2.4 and above. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140509083409.9292.16377.report...@darboux.home.olasd.eu
Re: Bug#747481: ITP: backports.ssl-match-hostname -- Backport of the Python 3.2 SSL hostname checking function
* Nicolas Dandrimont ol...@debian.org [2014-05-09 10:34:09 +0200]: Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont ol...@debian.org * Package name: backports.ssl-match-hostname Version : 3.4.0.2 Upstream Author : Brandon Craig Rhodes * URL : https://bitbucket.org/brandon/backports.ssl_match_hostname * License : Python Programming Lang: Python Description : Backport of the Python 3.2 SSL hostname checking function The Secure Sockets layer is only actually secure if you check the hostname in the certificate returned by the server to which you are connecting, and verify that it matches to hostname that you are trying to reach. . But the matching logic, defined in RFC2818, can be a bit tricky to implement on your own. So the ssl package in the Standard Library of Python 3.2 and greater now includes a match_hostname() function for performing this check instead of requiring every application to implement the check separately. . This package contains a backport of the ssl.match_hostname function for Python 2.4 and above. On IRC, Jakub kindly pointed me at #626539 and its resolution. As a recent update of a package I maintain (websocket-client) actually needs this backport, and I'll need to use it on wheezy (and therefore have to backport the backport), I'll go ahead and package that anyway. Thanks, -- Nicolas Dandrimont Microsoft is not the answer. Microsoft is the question. NO (or Linux) is the answer. (Taken from a .signature from someone from the UK, source unknown) signature.asc Description: Digital signature
Making packaging Python modules fun again (was: Re: Indeed, python-concurrent.futures is the same)
a $BEVERAGE or three.
Cheers,
Nicolas Dandrimont
[1] - http://python-modules.alioth.debian.org/cgi-bin/pet.cgi
[2] - git.debian.org:~olasd/public_git/dpmt/
[3] - git.debian.org:~olasd/dpmt_migration/ [see
tools/bin/{dpmt-rules-gen,dpmt-svn2git}]
--
BOFH excuse #431:
Borg implants are failing
signature.asc
Description: Digital signature
Re: QA Developer overview, compared with PET
* Ben Finney ben+deb...@benfinney.id.au [2014-01-27 10:37:06 +1100]: Nicolas Dandrimont ol...@debian.org writes: - Dust off the team's PET instance ([1], which looks rather outdated). [1] - http://python-modules.alioth.debian.org/cgi-bin/pet.cgi I've never seen PET before. It seems redundant with the official QA Packages Overview tool for each maintainer, which for DPMT is at URL:http://qa.debian.org/developer.php?login=python-modules-t...@lists.alioth.debian.org. Thanks for bringing PET to my attention. But I wonder whether it's unused for good reason? What does PET do which the Packages Overview tool does not? Why advocate PET rather than advocating for those features to be added to the QA PAckages Overview tool? PET is a VCS-centric view rather than an archive-centric view, which is what DDPO provides. See for instance the Perl team view: http://pet.debian.net/pkg-perl/pet.cgi This tool is meant to serve as a useful TODO-list of things that need to be done in (the VCS of) a team that maintains hundreds of packages. DDPO could probably be modified to take into account VCS information. But the data is not easy to gather, and I'm not sure that would align with the original intent of the tool. PET updates itself through VCS hooks, and has been specifically designed to use VCS data. Hope this clarifies, -- Nicolas Dandrimont BOFH excuse #90: Budget cuts signature.asc Description: Digital signature
Bug#734952: ITP: cloud-sptheme -- Cloud Sphinx theme and related extensions
Package: wnpp
Severity: wishlist
Owner: Nicolas Dandrimont ol...@debian.org
* Package name: cloud-sptheme
Version : 1.6
Upstream Author : Eli Collins
* URL : http://pythonhosted.org/cloud_sptheme/
* License : BSD
Programming Lang: Python
Description : Cloud Sphinx theme and related extensions
cloud_sptheme contains a Sphinx theme named Cloud, and some related
Sphinx extensions. Cloud and its extensions are primarily oriented
towards generating html documentation for Python libraries. It provides
numerous small enhancements to make the html documentation more
interactive, and improve the layout on mobile devices.
.
In addition to the Cloud theme, this package provides a few extra Sphinx
extensions which may be useful when documenting Python projects; and
should be theme-agnostic:
.
cloud_sptheme.ext.autodoc_sections
Patches the sphinx.ext.autodoc to handle RST section headers inside
docstrings.
cloud_sptheme.ext.issue_tracker
Adds a special :issue: role for quickly linking to your project's
issue tracker.
cloud_sptheme.ext.escaped_samp_literals
Patches Sphinx to permit escaped {} characters within a :samp: role.
cloud_sptheme.ext.table_styling
Enhances .. table directive to support per-column text alignment and
other layout features.
--
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/20140111032204.18007.83846.report...@darboux.home.olasd.eu
Bug#732837: ITP: vcversioner -- Use version control tags to discover version numbers
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont ol...@debian.org * Package name: vcversioner Version : 1.13.0.0 Upstream Author : Aaron Gallagher _...@habnabit.org * URL : https://github.com/habnabit/vcversioner * License : ISC Programming Lang: Python Description : Use version control tags to discover version numbers vcversioner autodiscovers a Python project's version number using version control system tags. This allows developers to avoid duplicating version information between their VCS and their setup.py metadata. . When the package is built, vcversioner generates a version.txt file that can be used for release tarballs. . Currently, vcversioner only supports the git VCS. -- 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/20131222100920.28777.73959.report...@hilbert.home.olasd.eu
Bug#727759: ITP: websocket-client -- WebSocket client library for python
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont ol...@debian.org * Package name: websocket-client Version : 0.12.0 Upstream Author : liris liris...@gmail.com * URL : https://github.com/liris/websocket-client * License : LGPL-2.1+ Programming Lang: Python Description : WebSocket client library for python websocket-client provides a low-level, synchronous API providing WebSocket client functionality to Python programs. It conforms to the WebSocket specification as standardized by the IETF in RFC 6455. . WebSocket is a protocol providing full-duplex communication channels over TCP, mostly used in Web browsers. This module is a test dependency for moksha.hub. It will be packaged under the DPMT umbrella, and the binary package will be called python-websocket as per the Debian Python Policy. -- 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/20131026094406.6017.11840.report...@darboux.home.olasd.eu
Re: Accepted python-defaults 2.7.3-5 (source all)
* Dmitrijs Ledkovs x...@debian.org [2013-05-06 03:13:47 -0700]: On 6 May 2013 00:29, Sandro Tosi matrixh...@gmail.com wrote: Hello, has this been discussed *and* agreed on? I can only see Luca's mail for python plans, but no ack from other members of the debian python board nor the ACK from RT. Python2.6 security support ends in October 2013 upstream. Which is well ahead of jessie freeze release. From security point of view alone, it would be unwise to ship python2.6 in jessie. Which imho is serious enough reason to remove python2.6 given its potential high exposure when used by web-frameworks. Hi, I don't think that's up for discussion. But Sandro's point was about http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573745#591 (look at point #6.) Cheers, -- Nicolas Dandrimont We are using Linux daily to UP our productivity - so UP yours! (Adapted from Pat Paulsen by Joe Sloan) signature.asc Description: Digital signature
Bug#702298: ITP: fabtools -- tools for writing awesome Fabric files
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont nicolas.dandrim...@crans.org Package name: fabtools Version : 0.12.0 Upstream Author : Ronan Amicel ronan.ami...@gmail.com URL : https://github.com/ronnix/fabtools http://fabtools.readthedocs.org/ License : BSD 2-clause Programming Lang: Python Description : common utilities for writing Fabric files fabtools includes useful functions to help people write Fabric files. For instance, through its API, it allows to manage system users, packages, databases, ... fabtools provides a number of low-level actions, as well as a higher level interface named fabtools.require. This higher-level interface, inspired by configuration management tools such as Chef or Puppet, is declarative and idempotent. (comments welcome on the long description, which looks like it needs some expanding) According to the Python policy, the binary package will be called python-fabtools. -- 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/87fw0aan71@hilbert.home.olasd.eu
RFS: python-simpy (Adoption, new upstream release, updated packaging)
Hi, I'm looking for a sponsor to upload my package python-simpy. I'm taking over the package from an inactive (since 2008) maintainer, and have I've tried my best to clean up and update the packaging (switching to dh short form, dh_python2, use of dh_sphinxdoc, DEP5, …). The updated source package is available from mentors.debian.net: dget -x http://mentors.debian.net/debian/pool/main/p/python-simpy/python-simpy_2.1.0-1.dsc The resulting packages are `linitian -Ei --pedantic`-clean (with the exception of the upstream changelog which isn't available), and I've run the test suite successfully on python 2.6 and 2.7 after installation. I injected the packaging into the DPMT svn at svn://svn.debian.org/python-modules/packages/python-simpy/trunk/ http://svn.debian.org/viewsvn/python-modules/packages/python-simpy/trunk/ The orig tarball can be fetched with uscan, and the documentation tarball can be built using the get-orig-docs-tarball target as documented in README.source. I would be glad for any review, comments, and of course if someone would upload the package. Cheers, -- Nicolas Dandrimont pgpuIv8LozI7K.pgp Description: PGP signature
Re: RFS: python-simpy (updated)
Le 20/08/2011 à 15:54, Nicolas Dandrimont nicolas.dandrim...@crans.org écrivit : Hi, I'm looking for a sponsor to upload my package python-simpy. I'm taking over the package from an inactive (since 2008) maintainer, and have I've tried my best to clean up and update the packaging (switching to dh short form, dh_python2, use of dh_sphinxdoc, DEP5, …). The updated source package is available from mentors.debian.net: dget -x http://mentors.debian.net/debian/pool/main/p/python-simpy/python-simpy_2.1.0-1.dsc The resulting packages are `linitian -Ei --pedantic`-clean (with the exception of the upstream changelog which isn't available), and I've run the test suite successfully on python 2.6 and 2.7 after installation. I injected the packaging into the DPMT svn at svn://svn.debian.org/python-modules/packages/python-simpy/trunk/ http://svn.debian.org/viewsvn/python-modules/packages/python-simpy/trunk/ The orig tarball can be fetched with uscan, and the documentation tarball can be built using the get-orig-docs-tarball target as documented in README.source. I would be glad for any review, comments, and of course if someone would upload the package. Just updated the package, addressing an IRC comment from Jakub: 16:29:35 jwilk olasd: Re python-simpy, see Debian Policy 4.6. Also, this whole find+head+grep+mv dance could be replaced by a single find|sed pipeline. Cheers, -- Nicolas Dandrimont -- 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/87ei0g3yjh@poincare.crans.org
Request to join DPMT
Hi, I'd like to join the DPMT, to be able to team-maintain (and be sponsored for) the python-simpy package, that I intend to take over and update[1]. My main focus right now would be the simpy package, but I use quite a few other python modules and am a django user, so I guess I could lend a hand for other things, if needed. My IRC nickname is olasd and I've been lurking on #debian-python for a while now. Cheers, -- Nicolas Dandrimont [1] http://bugs.debian.org/463044 pgpsppWvZ0nPe.pgp Description: PGP signature
