Re: python-cryptography, Rust, and OpenSSL 3.0

[Tristan Seligmann]

> python-cryptography_3.4.8-1_source.changes uploaded successfully to
localhost

On Wed, 1 Dec 2021 at 21:38, Tristan Seligmann 
wrote:

> On Wed, 1 Dec 2021 at 21:34, Stefano Rivera  wrote:
>
>> Hi Simon (2021.12.01_12:31:20_+)
>> > 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?
>>
>> I'd assume, yes.
>>
>> We were waiting on PyO3, primarily, I think. I see it's in unstable, but
>> hasn't made it to testing, yet. I'll do a source-only upload.
>>
>
> Thanks for the patches, Simon; I am working on testing and uploading this
> version as an intermediate step while we resolve the Rust issue. As far as
> Rust goes, it should be straightforward packaging the missing dependencies
> here, but unfortunately I have not been able to do much Debian-related work
> recently.
>

Re: python-cryptography, Rust, and OpenSSL 3.0

[Tristan Seligmann]

On Wed, 1 Dec 2021 at 21:34, Stefano Rivera  wrote:

> Hi Simon (2021.12.01_12:31:20_+)
> > 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?
>
> I'd assume, yes.
>
> We were waiting on PyO3, primarily, I think. I see it's in unstable, but
> hasn't made it to testing, yet. I'll do a source-only upload.
>

Thanks for the patches, Simon; I am working on testing and uploading this
version as an intermediate step while we resolve the Rust issue. As far as
Rust goes, it should be straightforward packaging the missing dependencies
here, but unfortunately I have not been able to do much Debian-related work
recently.

Re: upstream python concerns, python3-full package for bullseye

[Tristan Seligmann]

On Fri, 12 Feb 2021 at 02:43,  wrote:

> From your arguments above, it doesn't sound like the python3-full solves
> a problem you experience. So, I'm not sure why you'd be using it.
>
> If it doesn't include distutils, venv, lib2to3, etc. then it doesn't
> solve any problem we currently have, and we don't need it. The purpose
> is to provide a package that gives you the entire stdlib.
>

I wanted to point out that this follows the pattern set by the many other
*-full packages in Debian, such as ruby-full.

mercurial-git

[Tristan Seligmann]

Hi all,

Regarding #961245:

> Ideally this should be fixed by renaming the hg-git's module back to what 
> upstream uses. But of course this is going to break all hg-git users' 
> configurations. :-/

I've gone ahead with this change in hg-git 0.9.0-1, with a NEWS.Debian
entry alerting users. Breaking existing configurations is unfortunate,
but:

1) The breakage is a relatively harmless error message, rather than
data loss or something like that;
2) The disparity with upstream causes ongoing confusion for new users
(searching the web turns up a small but continuing stream of bug
reports in all sorts of places);
3) hg-git has unfortunately been broken in unstable recently for long
stretches of time due to incompatible upstream changes, so I'm not
sure how many users of the package are even left.

Restoring the upstream hgext.git extension will take a bit more
planning to avoid problems with upgrades from buster, so I have not
done this (yet).

Finally, it occurs to me that I should have sent this mail _before_
making this change, rather than _after_; sorry about that.

Re: Bug#916682: python-cryptography: build from source fails with libssl-dev_1.1.0j-1~deb9u1 amd64

[Tristan Seligmann]

I suspect this is fixed upstream but I am unable to take care of uploading
a new version for the next few weeks. An NMU / team upload would be
appreciated!

Re: Bug#902592: [Help] Potential Cython issue with new version of h5py (Was: Bug#902592: New version does not build)

[Tristan Seligmann]

On Fri, 29 Jun 2018 at 14:40 Andreas Tille  wrote:

> Would you mind filing an according bug report we could refer to?
>

I've filed this as #902784 although I haven't had the chance to investigate
the cause further. (Probably some minor packaging error)

Re: [Help] Potential Cython issue with new version of h5py (Was: Bug#902592: New version does not build)

[Tristan Seligmann]

On Fri, 29 Jun 2018 at 14:20 Andreas Tille  wrote:

> Hi Tristan,
>
> On Fri, Jun 29, 2018 at 01:31:31PM +0200, Tristan Seligmann wrote:
> > This is a cython bug; cython-dbg fails to ship the StringIOTree extension
> > module, so the regular non-debug module is found when doing a debug build
> > but fails to load.
>
> Are you refering to #902551?
>

No, that bug looks unrelated.

Re: [Help] Potential Cython issue with new version of h5py (Was: Bug#902592: New version does not build)

[Tristan Seligmann]

This is a cython bug; cython-dbg fails to ship the StringIOTree extension
module, so the regular non-debug module is found when doing a debug build
but fails to load.

On Fri, 29 Jun 2018 at 13:18 Andreas Tille  wrote:

> Control: tags -1 help
>
> I agree with Ghislain that the issue below might be caused by Cython.
> Any idea how to fix this?
>
> Kind regards
>
>   Andreas.
>
> On Fri, Jun 29, 2018 at 12:23:52PM +0200, Ghislain Vaillant wrote:
> > I am away right now and can't investigate before two weeks.
> >
> > Looks Cython related from a first look.
> >
> > Ghis
> >
> > Le ven. 29 juin 2018 à 11:17, Andreas Tille  a
> écrit :
> >
> > > Hi Ghislain,
> > >
> > > since one of the Debian Med packages seems to be affected I tried to
> > > upgrade h5py (see Git repository).  Unfortunately it does not build:
> > >
> > > ...
> > > running build_ext
> > > Traceback (most recent call last):
> > >   File "setup.py", line 168, in 
> > > cmdclass = CMDCLASS,
> > >   File "/usr/lib/python2.7/dist-packages/setuptools/__init__.py", line
> > > 129, in setup
> > > return distutils.core.setup(**attrs)
> > >   File "/usr/lib/python2.7/distutils/core.py", line 151, in setup
> > > dist.run_commands()
> > >   File "/usr/lib/python2.7/distutils/dist.py", line 953, in
> run_commands
> > > self.run_command(cmd)
> > >   File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
> > > cmd_obj.run()
> > >   File "/usr/lib/python2.7/distutils/command/build.py", line 128, in
> run
> > > self.run_command(cmd_name)
> > >   File "/usr/lib/python2.7/distutils/cmd.py", line 326, in run_command
> > > self.distribution.run_command(command)
> > >   File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
> > > cmd_obj.run()
> > >   File "/build/h5py-2.8.0/setup_build.py", line 156, in run
> > > from Cython.Build import cythonize
> > >   File "/usr/lib/python2.7/dist-packages/Cython/Build/__init__.py",
> line
> > > 1, in 
> > > from .Dependencies import cythonize
> > >   File "/usr/lib/python2.7/dist-packages/Cython/Build/Dependencies.py",
> > > line 36, in 
> > > from ..Compiler.Main import Context, CompilationOptions,
> > > default_options
> > >   File "/usr/lib/python2.7/dist-packages/Cython/Compiler/Main.py", line
> > > 30, in 
> > > from .Symtab import ModuleScope
> > >   File "/usr/lib/python2.7/dist-packages/Cython/Compiler/Symtab.py",
> line
> > > 19, in 
> > > from . import PyrexTypes
> > >   File
> "/usr/lib/python2.7/dist-packages/Cython/Compiler/PyrexTypes.py",
> > > line 17, in 
> > > from .Code import UtilityCode, LazyUtilityCode, TempitaUtilityCode
> > >   File "Cython/Compiler/Code.py", line 38, in init Cython.Compiler.Code
> > > ImportError: /usr/lib/python2.7/dist-packages/Cython/
> > > StringIOTree.x86_64-linux-gnu.so: undefined symbol: Py_InitModule4_64
> > > E: pybuild pybuild:336: build: plugin distutils failed with: exit
> code=1:
> > > /usr/bin/python-dbg setup.py build
> > > dh_auto_build: pybuild --build -i python{version}-dbg -p 2.7 returned
> exit
> > > code 13
> > > make[1]: *** [debian/rules:22: override_dh_auto_build] Error 25
> > > make[1]: Leaving directory '/build/h5py-2.8.0'
> > > make: *** [debian/rules:10: build] Error 2
> > > dpkg-buildpackage: error: debian/rules build gave error exit status 2
> > >
> > >
> > > Can you please have a look?
> > >
> > > Kind regards
> > >
> > > Andreas.
> > >
> > > --
> > > http://fam-tille.de
> > >
>
> > ___
> > Debian-med-packaging mailing list
> > debian-med-packag...@alioth-lists.debian.net
> >
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
>
>
> --
> http://fam-tille.de
>
>

Re: Next python-mote pre-condition test issue: python-jsondiff trows ModuleNotFoundError: No module named 'nose_random'

[Tristan Seligmann]

On Tue, 16 Jan 2018 at 22:45 Andreas Tille  wrote:

> My web search for a module named 'nose_random' remained empty.
>

I found this package, which seems to match, from the same organization:
https://github.com/ZoomerAnalytics/nose-random

Unfortunately it seems to be unreleased, so I think you would need to
package a GitHub snapshot or something (or alternatively disable the tests).

Re: Please help with test suite error and installation problem of python-aws-xray-sdk (Was: If there is no response in debian-python then debian-science might be the right team)

[Tristan Seligmann]

On Mon, 15 Jan 2018 at 13:59 Andreas Tille  wrote:

>SyntaxError: invalid syntax
> !!! Interrupted: 4 errors during collection
> 
>

All of these syntax errors relate to syntax that only exist on Python 3,
thus I would conclude that this package does not support Python 2.

Re: /usr/bin/python2 in shebangs?

[Tristan Seligmann]

On Thu, 14 Dec 2017 at 15:39 Piotr Ożarowski  wrote:

> I plan to prepare new dh-python upload soon and hence a question about
> a bit controversial change: should dh_python2 (as we discussed during
> last DebConf's Python BoF) replace /usr/bin/python shebangs with
> /usr/bin/python2?
>

Since on a Debian system we know we have /usr/bin/python2 (as opposed to
some theoretical portable script that might need to run on other systems),
this sounds perfectly fine to me.

Re: Question about binary sphinx inventory files

[Tristan Seligmann]

On Sat, 26 Aug 2017 at 00:20 W. Martin Borgert  wrote:

> I believe that a small number of Python module doc packages use
> binary Sphinx inventory (.inv) files during build, that are just
> downloaded from python.org by the package maintainer. I don't
> know anything about Sphinx nor how to encode/decode .inv files.
> https://pypi.python.org/pypi/sphobjinv is not in Debian, is it?
> How would I create e.g. https://docs.python.org/objects.inv
> from which sources?
>

In the case of Python's documentation inventory specifically, this is built
and distributed in the python*-doc packages, and there should be no need to
download it from python.org.

Re: removing python3-trollius

[Tristan Seligmann]

On Mon, 10 Jul 2017 at 11:45 Michael Hudson-Doyle <
michael.hud...@canonical.com> wrote:

>
> python3-trollius fails tests with Python 3.6 and rather than think about
> why, I think it makes more sense to stop building trollius for Python 3.
>

Sounds reasonable to me!

Re: Bug#866668: src:python-cryptography: Misbuild with more than one supported python3 version

[Tristan Seligmann]

Control: severity -1 important

On Fri, 30 Jun 2017 at 19:33 Scott Kitterman  wrote:

> Technically, it builds, but in a way that's not useful.  It would actually
> be
> better if it had failed (I noticed this from reviewing build logs after the
> python3 interpreter depends weren't generated correctly).
>

In fact, the package works fine on python3.5 as well as python3.6 (the
module imports, and the full test suite passes against the installed
modules), thus I'm downgrading the severity of this bug.

During the build, the extension modules are first built on python3.5, and
it is these modules that land in /usr/lib/python3, with the "abi3" ABI tag.
The extension modules are then built again on python3.6, but these don't
get moved into /usr/lib/python3 due to the files from the python3.5 build
having the same name, thus landing in an incorrect directory in the  final
package and serving no useful purpose.

The reason the package still works is the "abi3" ABI tag; these modules
(like all CFFI-built modules, by default) are using the Python 3 "stable
ABI"[1] so the modules built on python3.5 work fine when imported on
python3.6, and vice-versa. I think what this means is that we only need to
run the Python 3 build once (using the default version?); also, I think the
interpreter depends are in fact correct in light of this. I tested
downgrading to 1.7.1-3 and the module still imports and works on python3.6,
even though 1.7.1-3 was only ever built against python3.5.

However, testing against all supported versions at build time is probably
still appropriate.

I'm looping in debian-python here as others may be surprised by this
combination of effects as well, and we should probably be handling the
issue of modules using the stable ABI consistently. Also, I'm not 100%
certain what the best way forward is here; teach pybuild/dh_python3 about
the stable ABI?

[1] https://docs.python.org/3/c-api/stable.html

Re: No longer uploading mercurial

[Tristan Seligmann]

On Sat, 20 May 2017 at 12:39 Javi Merino  wrote:

> I have been uploading mercurial for some years, but since November I'm
> struggling to find time to work on the package.  I don't think I will
> have time to keep up with mercurial's release schedule when stretch is
> released.
>

I'm listed in Uploaders and although I haven't touched the package
recently, I can probably still find my way around, so I think I should be
able to take over as primary uploader.

Re: python-modules-commits ml not receiving all commits?

[Tristan Seligmann]

On Wed, 5 Apr 2017 at 15:08 Sandro Tosi  wrote:

> Hello there,
> it looks like
> http://lists.alioth.debian.org/pipermail/python-modules-commits/2017-April/thread.html
> is not receiving all the commits to our repo, f.e. i know numpy has
> been updated yday and today, but none of the commits area in the
> archive (nor in my mailbox, that's how i noticed this)
>

I sometimes get bounce messages for email notifications generated by
commits I push, due to the message size being too large; perhaps this is
the cause?

Re: Problems upgrading r-cran-fastcluster due to failed test in Python module

[Tristan Seligmann]

On Thu, 17 Nov 2016 at 12:25 Gard Spreemann  wrote:

> The weird thing is that this error does not occur when building on my
> ordinary system (outside of the pbuilder chroot). Does pbuilder not
> allow non-ASCII output or something?
>

Pbuilder is probably defaulting the locale to C, whereas your system/user
locale is probably a UTF-8 locale (eg. en_US.UTF-8). You can probably
resolve this issue with an `export LC_ALL=C.UTF-8` in debian/rules.

Re: Joining

[Tristan Seligmann]

Hi all,

I think this email slipped through the cracks; could one of the alioth
admins look at this?

(I have been working with / sponsoring Richard on such packages as
python-trezor)

On Tue, 2 Feb 2016 at 22:30 Richard Ulrich  wrote:

> Hi,
>
> I would like to join the team, in order to maintain my current packages
> within the team.
>
> My alioth login is : ulrichard-guest
>
> I have read the policy and accept it.
>
>
> Rgds
> Richard
>
> --
> Meine Kontaktdetails sind immer aktuell in der NameCoin blockchain mit
> der Kennung: id/ulrichard
> Teile davon sieht man mit folgendem Link:
> https://nameid.org/?name=ulrichard
> Bitte schicken Sie mir wenn möglich PGP/GPG verschlüsselte Nachrichten.
>
>

Re: pypy pakages

[Tristan Seligmann]

On Tue, 10 May 2016 at 23:29 Stefano Rivera  wrote:

> Hi Michael (2016.05.10_19:23:33_+0200)
> > is there a specific reason why there are so few pypy-* packages in the
> > archive? Is it just a lack of interest or are any practical reasons not
> > to have them?
>
> I think we're all kind of waiting for PyPy 3, so that we don't have to
> bring up an entire stack of packages (that few people are going to use).
>
> Personally, I've crated a couple, just to be sure that it all works
> correctly.
>

I've added pypy-* packages to all of my packages that I can, the rest are
missing dependencies. I think it would be great if we could get
performance-sensitive applications running on PyPy instead of CPython, but
of course this requires the whole dependency graph to have pypy-* packages
built.

Re: Test suite in github but missing from pypi tarballs

[Tristan Seligmann]

Resending to the list since I accidentally replied off-list!

On Thu, 21 Apr 2016, 20:14 Tristan Seligmann, <mithra...@mithrandi.net>
wrote:

> On Thu, 21 Apr 2016 at 19:34 Barry Warsaw <ba...@debian.org> wrote:
>
>> I also don't particularly like relying on GitHub generated tarballs.
>> Despite
>> popular believe, not every upstream uses GH or even git, signs their tags
>> or
>> even tags their releases.  But almost *every* Python package releases
>> tarballs
>> to PyPI.
>
>
> There's no particular reason why every Python package has to distribute
> the Debian orig tarball via PyPI, though. *My* projects are almost all on
> GitHub these days, so I offer the git tags and github archives as an option
> to get the "full source"; in the past, I have hosted projects elsewhere,
> and released tarballs elsewhere, and there is of course nothing wrong with
> this.
>
> If you want to make your PyPI sdists do double-duty, there's usually
> nothing terribly wrong with this, but given that they must include
> generated artifacts (like .c source generated by Cython) in order to work
> well for pip, and pip is typically how people consume PyPI, I don't view
> these as the ideal "upstream source" for Debian.
>
> And of course, there are extreme examples like *cryptography*: The
> python-cryptography source package is 384K, the python-cryptography-vectors
> source package (necessary for running the cryptography tests) is 26MB!
>
> FWIW: I should note that I'm a fan of having my tests as a subpackage of
> the main package (ie. mything.tests) so they can be run by an end-user to
> verify that an installed copy of the package is actually working. I do this
> in most of the projects I'm upstream for; so the tests *are* included in
> my sdist, but other files are not (like documentation).
>

Re: Test suite in github but missing from pypi tarballs

[Tristan Seligmann]

On Thu, 21 Apr 2016 at 16:47 Edward Betts  wrote:

> Debian binary packages don't normally include the test suite. Some Python
>
library developers are treating the pypi releases in a similar way, as if
> they're just for deployment. They think anybody who needs the test suite is
> doing development and will clone from the github repo.
>

With my upstream developer hat on: source packages on PyPI are meant for
end users to install via pip. They often include generated artifacts, and
don't include things that aren't intended for installation via pip (tests
being just one of these).

For distribution packaging purposes, the GitHub tags are generally
preferrable. GitHub makes archives of tagged releases available as
tarballs, so this is generally a simple tweak to debian/watch.

Bug#815387: ITP: python-attrs -- Python attributes without boilerplate

[Tristan Seligmann]

Package: wnpp
Severity: wishlist
Owner: Tristan Seligmann <mithra...@mithrandi.net>

* Package name: python-attrs
  Version : 15.2.0
  Upstream Author : Hynek Schlawack <h...@ox.cx>
* URL : https://github.com/hynek/attrs
* License : MIT
  Programming Lang: Python
  Description : Python attributes without boilerplate

attrs is an MIT-licensed Python package with class decorators that ease the
chores of implementing the most common attribute-related object protocol.

attrs is the successor to Characteristic, and is a dependency of
python-servicy-identity from 16.0.0.

Bug#811386: ITP: python-genty -- Python library for test generation

[Tristan Seligmann]

Package: wnpp
Severity: wishlist
Owner: Tristan Seligmann <mithra...@mithrandi.net>

* Package name: python-genty
  Version : 1.3.0
  Upstream Author : Box <o...@box.com>
* URL : https://github.com/box/genty
* License : Apache 2.0
  Programming Lang: Python
  Description : Python library for test generation

Needed as a test dependency for python-flaky. I will maintain this under DPMT.

Bug#808605: ITP: python-flaky -- Plugin for nose or py.test that automatically reruns flaky tests

[Tristan Seligmann]

Package: wnpp
Severity: wishlist
Owner: Tristan Seligmann <mithra...@mithrandi.net>

* Package name: python-flaky
  Version : 3.0.1
  Upstream Author : Box <o...@box.com>
* URL : https://github.com/box/flaky
* License : Apache License
  Programming Lang: Python
  Description : Plugin for nose or py.test that automatically reruns flaky 
tests

Binary package names: python3-flaky python-flaky pypy-flaky

Flaky is a plugin for nose or py.test that automatically reruns flaky tests.

Re: Help with pytest 2.8.5

[Tristan Seligmann]

On Thu, 17 Dec 2015, 14:16 Piotr Ożarowski  wrote:

>
> I didn't test it but... why is override_dh_auto_test needed at all?
> Did you try with:
>

Ah sorry, my diff was against the old debian/rules which didn't use
pybuild.

However the same problem may happen if pybuild chdir()s to the build
directory (I don't remember offhand what it does, and I'm not at my
computer).

Re: Help with pytest 2.8.5

[Tristan Seligmann]

On Thu, 17 Dec 2015 at 02:17 Barry Warsaw  wrote:

I've made some significant changes to the packaging by switching it to
> pybuild.  That's not the problem though. ;)  The problem is that I can't
> get
> the test suite to run cleanly during package build.  I'm seeing two
> failures
> in testing/test_genscript.py which causes the build to fail (or, if I
> ignore
> that, prevents pybuild from running the test for Python 3.4 and 3.5).
>

The failures in test_genscript are due to running the tests from the source
directory; this causes the sources (in particular,
_pytest.standalonetemplate) to be imported with relative paths, which are
then no longer correct once pytest chdir()s to a temporary directory during
the test run.

I attached a patch which illustrates how to fix the problem.

There is one other test failure, a failing doctest in
testing/cx_freeze/tests/test_doctest.txt; this is a result of the 2.8.5
sdist being prepared on Windows, causing all of the source files to have
"dos" (CRLF) line endings instead of "unix" (LF) line endings. I'm not sure
exactly what the best way to fix this is, but I guess a patch to change the
line-endings in the file should do the trick.
diff --git a/debian/rules b/debian/rules
index f473395..3c2f918 100755
--- a/debian/rules
+++ b/debian/rules
@@ -59,8 +59,9 @@ override_dh_clean:
 override_dh_auto_test:
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
set -ex; \
+   cd /tmp; \
for py in $(PYVERS) $(PY3VERS); do \
-   PYTHONPATH=$(CURDIR) python$$py -m pytest testing ; \
+   PYTHONPATH=$(CURDIR) python$$py -m pytest $(CURDIR)/testing ; \
done
 endif

Re: Pushing a bunch of packages to jessie-backports

[Tristan Seligmann]

On Thu, 26 Nov 2015 at 10:32 Piotr Ożarowski  wrote:

> > This is not the policy for backports. Amend the policy if you
> > disagree. It's not fair to kick Zigo because he didn't follow the rules
> > and consider oneself above them when he respects them.
>
> fix it yourself, I'm getting all the bugs and emails so there's nothing
> that suggest I should use backport's policy rather then Debian's.
>

Note that regarding bug reports, the backports website states:

"Please report bugs that you found in the packages to the backports
mailinglist  and *NOT* to the
Debian BTS!"

Re: RFS updating the setuptools-scm and mistune packages

[Tristan Seligmann]

On Wed, 30 Sep 2015 at 13:55 Julien Puydt  wrote:

> ssh://git.debian.org/git/python-modules/packages/mistune.git
> ssh://git.debian.org/git/python-modules/packages/setuptools-scm.git
>

Uploaded.

Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental

[Tristan Seligmann]

On Wed, 30 Sep 2015 at 10:45 Thomas Goirand <z...@debian.org> wrote:

> On 09/29/2015 04:02 PM, Tristan Seligmann wrote:
> > but I'm not sure that having someone
> > blindly upload my packages if they haven't worked on them before is a
> > good idea.
>
> If this is what you think of my upload, I don't agree with the above
> wording at least.
>

I don't specifically know anything about networkx, and I didn't take the
time to look at it, so I wasn't directing this at you personally except
insofar as the events that spawned this thread made me think about
situations like this. I think I do owe you an apology as my original mail
was worded carelessly.

On 09/29/2015 04:02 PM, Tristan Seligmann wrote:
> > I feel like I should go through all of my packages and remove the team
> > from Maintainer for all of them
>
> If you don't want anyone from the team to upload "your" packages (btw,
> they are not yours, you are sharing them with other DDs and all of our
> user bases), then by all means, remove the team from any fields.
>

They're mine in the sense that I am taking responsibility for them, while
others are not. I'm the one reading the bug repoorts, looking at the
package on my qa.debian.org dashboard, etc. I'm certainly not opposed (in
general) to anyone wants to share that responsibility, but then surely the
way to do this is to add themselves to Uploaders? If they're not interested
in doing that, then I think it's probably best if I (or another
co-maintainer, if there is one!) am at least glancing over their changes
before they're uploaded.

In other words, I'm not trying to say "MINE! ALL MINE! HANDS OFF!", and in
fact I don't mind anyone *committing* things to any of my packages: the
worst case scenario there is that I see the changes, find some horrible
problem, revert them, and let you know why. I don't think that's a terrible
state of affairs at all for a worst case, and most of the time the scenario
will be that I see the changes, don't find any horrible problems, and am
very happy that someone else did some work so that I didn't have to do it!
But I am uncomfortable taking responsibility for a package version that I
didn't even have a chance to look at before it was uploaded.

On the other hand, I don't want a lack of time/effort to hold up others who
can put in the time/effort, that is why I try to make a point out of
responding quickly in cases like this; I know how frustrating it can be to
have a simple patch blocked for weeks by an unresponsive maintainer, and I
definitely don't want my "please don't upload without pinging me" ideas to
lead to situations like that. In other words, if I don't have the time to
respond quickly, then I'm probably disqualifying myself as a maintainer
anyway, so it only makes sense to allow others to take over in my
"absence", even if only temporarily.

Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental

[Tristan Seligmann]

On Tue, 29 Sep 2015 at 15:48 Barry Warsaw  wrote:

> The wiki says that the general rule of thumb is to set the team as
> Maintainer,
> to which I agree.  I may not have been as deliberate about my own
> packages, so
> I plan on reviewing them, and will fix any that aren't "special".
>

After reading this thread, I feel like I should go through all of my
packages and remove the team from Maintainer for all of them. I try very
hard to respond promptly to pings (bugs, email, IRC, ...) about my
packages, even if it's just to say "sorry, I can't take care of that right
now, feel free to upload"; but I'm not sure that having someone blindly
upload my packages if they haven't worked on them before is a good idea.

(And I say this having done a few team uploads in DPMT / collab-maint
recently; while I didn't think too much about these at the time, in
retrospect I feel like I made a mistake uploading those packages)

Re: RFS: path.py -- module wrapper for os.path

[Tristan Seligmann]

On Thu, 17 Sep 2015 at 16:11 Julien Puydt  wrote:

> Hi,
>
> I'm looking for a sponsor for:
>
> * Package name: path.py
>

Uploaded and tagged.

Re: RFS: ipython-genutils -- IPython vestigial utilities

[Tristan Seligmann]

On Sat, 12 Sep 2015 at 18:46 Julien Puydt  wrote:

> The package is now available here:
> Vcs-Git:
> git://anonscm.debian.org/python-modules/packages/ipython-genutils.git
> Vcs-Browser
> 
> :
> http://anonscm.debian.org/cgit/python-modules/packages/ipython-genutils.git
>

Uploaded and tagged.

Re: Bug#785275: ITP: python-ipaddress -- Backport of the ipaddress module from Python 3.3

[Tristan Seligmann]

On Mon, 8 Jun 2015 at 15:27 Tristan Seligmann mithra...@mithrandi.net
wrote:

  import ipaddr, ipaddress
  ipaddress.ip_address(b'\x7f\x00\x00\x01')
 IPv4Address(u'127.0.0.1')
  ipaddr.IPAddress(b'\x7f\x00\x00\x01')
 Traceback (most recent call last):
   File stdin, line 1, in module
   File
 /home/mithrandi/deployment/virtualenvs/tempenv-56cd218832e2d/local/lib/python2.7/site-packages/ipaddr.py,
 line 78, in IPAddress
 address)
 ValueError: '\x7f\x00\x00\x01' does not appear to be an IPv4 or IPv6
 address


For a more obnoxious example:

 import ipaddress, ipaddr
 ipaddress.ip_address(b'0::1')
IPv4Address(u'48.58.58.49')
 ipaddr.IPAddress(b'0::1')
IPv6Address('::1')

Re: Bug#785275: ITP: python-ipaddress -- Backport of the ipaddress module from Python 3.3

[Tristan Seligmann]

Control: tag -1 - wontfix

On Fri, 22 May 2015 at 17:06 Scott Kitterman deb...@kitterman.com wrote:

 There are far more users of ipaddr than ipaddress.  There's exactly two
 API differences.  I'm willing to look at pip and propose a patch to work
 with either.


I've discovered yet another API incompatibility which affects
python-cryptography:

 import ipaddr, ipaddress
 ipaddress.ip_address(b'\x7f\x00\x00\x01')
IPv4Address(u'127.0.0.1')
 ipaddr.IPAddress(b'\x7f\x00\x00\x01')
Traceback (most recent call last):
  File stdin, line 1, in module
  File
/home/mithrandi/deployment/virtualenvs/tempenv-56cd218832e2d/local/lib/python2.7/site-packages/ipaddr.py,
line 78, in IPAddress
address)
ValueError: '\x7f\x00\x00\x01' does not appear to be an IPv4 or IPv6 address

The reason is that ipaddr requires you to use the ipaddr.Bytes wrapper
type, rather than a normal bytes object, for packed addresses. Closer
examination reveals that the entire module appears to be API-incompatible
with ipaddress with regard to string types; ipaddress expects to receive
unpacked addresses as unicode objects, but ipaddr expects them as bytes
(not Bytes) objects. This break in compatibility probably goes unnoticed in
most situations due to implicit encoding/decoding, but at this point I am
seriously uncomfortable trying to work around these API differences in a
patch to cryptography (or any other future package I work on that depends
on ipaddress, for that matter). Thus I am renewing my intention to package
python-ipaddress for use as a dependency of python-cryptography.

Re: Bug#785275: ITP: python-ipaddress -- Backport of the ipaddress module from Python 3.3

[Tristan Seligmann]

On 22 May 2015 at 15:43, Donald Stufft don...@stufft.io wrote:
 I'm not sure if I was looking at the wrong ipaddr or something but the
 documentation I found was pretty crappy and looking at it I didn't see how to
 actually use ipaddr the same way I was using ipaddress in pip. In addition to
 that, the API doesn't really look the same as the ipaddress to me so it's 
 going
 to require some sort of compatability shim maintained in pip in order to be
 able to run one module on Python 2 and another module on Python 3.

If you're talking about the documentation linked to from PyPI (at
http://pythonhosted.org//ipaddr/), the problem is just that the
documentation is for an ancient version of ipaddr. I was also thrown
off by this originally, but if you look at an actually-recent version
of ipaddr, the API seems to be the same (or at least very similar, I
didn't look into it in detail so there may be differences in
unicode/bytes handling, although I hope not).

On the other hand, if upstream software is going to use ipaddress, it
really doesn't seem like Debian's place to patch everything to use
ipaddr.

On 22 May 2015 at 03:50, Scott Kitterman deb...@kitterman.com wrote:
 I'm also concerned that because of type processing differences (strings versus
 bytes and UTF-8 by default versus not) there is potential for subtle
 incompatibilities in the backported ipaddress.  I had complaints on an
 upstream project that uses ipaddress with python3 when it was available
 failing with ipaddress in python2.

I don't quite follow this. If ipaddr isn't compatible with ipaddress,
then the claim that you can simply import ipaddr instead of ipaddress
is obviously not true for software that is currently using ipaddress.
On the other hand, if they are compatible, then having ipaddress
installed shouldn't break anything regardless of whether it imports
ipaddress or ipaddr.

Or are you saying that the ipaddress backport is not compatible with
python3 stdlib's ipaddress? (This would be a very unfortunate state of
affairs, but impossible to imagine)
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


-- 
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/CAMcKhMT5mci=eH==fcUOX8zLfq53REoAJxPdt3V+AeC+7_=t...@mail.gmail.com

Re: Bug#785275: ITP: python-ipaddress -- Backport of the ipaddress module from Python 3.3

[Tristan Seligmann]

On 22 May 2015 at 16:06, Tristan Seligmann mithra...@mithrandi.net wrote:
 Or are you saying that the ipaddress backport is not compatible with
 python3 stdlib's ipaddress? (This would be a very unfortunate state of
 affairs, but impossible to imagine)

This should have been *not* impossible, of course.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


-- 
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/CAMcKhMT=dhk-uds2mniuf-ut-cxwlg1+ckih3zyetqdeeic...@mail.gmail.com

Re: Bug#785275: ITP: python-ipaddress -- Backport of the ipaddress module from Python 3.3

[Tristan Seligmann]

Control: tag -1 + wontfix

On 14 May 2015 at 13:45, Scott Kitterman deb...@kitterman.com wrote:
 Is this 100% compatible with ipaddress from upstream now?  The problem I ran
 into before is that when importing ipaddress and it turned out to be this one
 and not the upstream one, the API was different, so it didn't work.

I assumed so, otherwise there would be no point in a backport, but I
haven't yet done the work to verify this.

 It's completely trivial to use ipaddr with
 python2 and ipaddress with python3 [1], so this backport seems pretty
 pointless to me.

Well, it's only completely trivial if they have the same API and you
count putting a try/except wrapper around every single import of the
package as trivial...

However, given that my initial experiments with using ipaddr seem to
show that it's feasible, I'll probably stick with that for now.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


-- 
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/camckhmsqcyhfcn4e41aq1ovpprekrry23jxld_phb+qreke...@mail.gmail.com

Bug#785275: ITP: python-ipaddress -- Backport of the ipaddress module from Python 3.3

[Tristan Seligmann]

Package: wnpp
Severity: wishlist
Owner: Tristan Seligmann mithra...@mithrandi.net

* Package name: python-ipaddress
  Version : 1.0.7
  Upstream Author : Philipp Hagemeister
* URL : https://github.com/phihag/ipaddress
* License : PSF
  Programming Lang: Python
  Description : Backport of the ipaddress module from Python 3.3

This is a new dependency of python-cryptography. I intend to maintain the
package in DPMT.


-- 
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/20150514034256.3431.92795.report...@lorien.mithrandi.net

Re: Bug#785275: ITP: python-ipaddress -- Backport of the ipaddress module from Python 3.3

[Tristan Seligmann]

On 14 May 2015 at 06:04, Scott Kitterman deb...@kitterman.com wrote:
 Why can't python-cryptography use python-ipaddr that's already in the archive?

cryptography is python2/3 dual-source. Carrying a Debian-specific
patch[1] that introduces a slew of fallback imports to ipaddr, solely
to avoid uploading a new package, seems like a poor choice to me.

Having said that, I just whipped up a proof-of-concept patch that adds
import ipaddr as ipaddress fallbacks everywhere, and the related
tests seem to pass (I still have some failures due to missing
python-idna[3], so I don't have a clean test run yet), so it appears
that this would be feasible without major changes.

 There are only two very small API differences and when you introduce ipaddress
 in python2, it can break code that's designed to use ipaddr in python2 and
 ipaddress in python3 (I've run into this in projects where I'm upstream).

That is unfortunate, but unless the ipaddress backport is
API-incompatible in some way with the Python 3 stdlib version, surely
this just a bug in that code?

(Incidentally, I was initially under the impression that the APIs were
completely incompatible, as the API docs are severely out of date[2],
but the current version is much closer, as you describe)

 It seems somewhat odd to me to take ipaddr that was developed for python2 and
 integrated upstream as ipaddress in python3 and then backport it to python2 as
 ipaddress.

Well, blame the CPython maintainers for their fondness of arbitrarily
changing the API of modules they import into stdlib...

 Also, the listed copyright holder in the code is Google, not Philipp 
 Hagemeister.

Yes, the copyright holder is Google, the code was contributed to
Python under the PSF license. (I didn't mean to imply otherwise, I
just copy/pasted the info from PyPI into the wnpp template, apparently
without paying enough attention to what I was doing)

[1] I don't see why upstream should be interested in such a patch.

[2] http://pythonhosted.org//ipaddr/ as linked to from
https://pypi.python.org/pypi/ipaddr/

[3] https://bugs.debian.org/756388
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


-- 
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/camckhmrxxva891sr-8n4bwpyenyzh5r2y+yat2ejtpfesvf...@mail.gmail.com

Re: Sample DPMT SVN-GIT migration

[Tristan Seligmann]

On 1 May 2015 at 16:46, Barry Warsaw ba...@debian.org wrote:
 Also, I just saw that git-buildpackage(1) has gone away.  It seem like all we
 have now is gbp(1) but that has a different cli, and I think it has pq
 built-in.

`gbp buildpackage` and `git-buildpackage` have identical options and
behaviour. The latter has just been calling the former for a long
time, as far as I know.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


-- 
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/CAMcKhMS8DOimH+joFcrjR8ZUrx-xk=e0dqb-ek9ubmtcjtx...@mail.gmail.com

Re: Debian uscan redirector for PyPI (was: PyPI and debian/watch)

[Tristan Seligmann]

On 5 February 2015 at 22:59, Piotr Ożarowski pi...@debian.org wrote:
 [Tristan Seligmann, 2015-02-05]
 Now add an option to make it do pgpsigurlmangle ;P

 done (only if last release has a signature, though)

Awesome, thanks!
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


--
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/camckhmtf7dt9kskdbulb34naqgpk-nz9ynhgfax+dnjpz0a...@mail.gmail.com

Re: PyPI and debian/watch

[Tristan Seligmann]

On 4 February 2015 at 10:05, Ben Finney ben+deb...@benfinney.id.au wrote:
 Tristan Seligmann mithra...@mithrandi.net writes:

 The debian/watch file I wrote for python-nacl (which also verifies the
 PGP signature) seems to work.

 I can't get PGP signature retrieval to rowk (“uscan warning:
 pgpsigurlmangle option exists, but the upstream keyring does not exist”)
 even with your suggested pattern.

You need a debian/upstream/signing-key.asc with the ASCII-armored PGP
keys which will be accepted for signing the release.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


--
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/CAMcKhMRseQ1C-kz=ofe9s+9rdfxokrwcfp1pb0qgpsjkagm...@mail.gmail.com

Re: Status of pythondialog in Debian

[Tristan Seligmann]

On 22 October 2014 09:47, Florent Rougon f.rou...@free.fr wrote:
 It is in unstable, thank you! I wonder if the new package
 (python3-dialog) should not have Conflicts and Replaces with
 python-dialog. Although I suppose both packages can be installed at the
 same time, the current situation may leave the old, unmaintained
 python-dialog forever installed on users' systems (until manual removal
 or removal of Python 2...).

 What do you think?

Replaces: would not be appropriate or necessary since none of the
files are overlapping; this is only necessary when two packages
install files to the same location, and the one package must be
installed over the other.

Conflicts: would not be appropriate either, because both packages will
work just fine when coinstalled, as you mention.

It is indeed possible for a removed package (obsolete package, as
aptitude etc. call it) to stay on user systems forever, unless the
user takes some action, but I think the packaging tools and
documentation provide the necessary tools for users to address this.
For example, the release notes have a section on this topic:

https://www.debian.org/releases/wheezy/i386/release-notes/ch-upgrading.en.html#obsolete

aptitude will list the package under Obsolete and Locally Created
Packages), I believe the other package management frontends will do
something similar. If the old python-dialog package is working for
some user (there is no package in Debian using python-dialog, but
perhaps they have some locally installed software using it), then I
expect they can just continue to use it, whereas if it is not being
used then it doesn't really cause any harm by being installed on their
system.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


-- 
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/CAMcKhMTEMBpkrtqXD=+iwpyftchwnrbhlrxktfiipaxygw+...@mail.gmail.com

Re: How to solve #751375, file clash

[Tristan Seligmann]

On 16 October 2014 23:55, Brian May br...@microcomaustralia.com.au wrote:
 Is the configparser.py supplied by  python-pies2overrides different from the
 file supplied by python-configparser?

 If it is the same file, you could delete it from python-pies2overrides and
 depend on python-configparser.

The pies2overrides configparser.py contains only this:

==
from __future__ import absolute_import

from ConfigParser import *
==

(The purpose of the pies2overrides library is to provide compatibility
with Python 3 stdlib names)

I would guess that using python-configparser in place of this module
would still work, at least for the software that uses pies2overrides.

On 16 October 2014 23:49, Per Andersson avtob...@gmail.com wrote:
 or to move
 pies2overrides into it's own namespace (and patch frosted
 accordingly)?

If you're planning to patch frosted (or any other software that uses
pies2overrides; I packaged and uploaded isort recently, for example),
then there's not much point in *moving* pies2overrides, just patch the
software not to use it at all. That is, there is no point writing
this:

try:
from configparser import blah
except ImportError:
from pies2overrides.configparser import blah

Instead of just writing this:

try:
from configparser import blah
except ImportError:
from ConfigParser import blah
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


-- 
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/camckhmsc6+hzdz2swkagq0c7j5iy00byyo5ouf_hsnt69cp...@mail.gmail.com

Re: Keeping upstream commits separate from Debian packaging commits

[Tristan Seligmann]

On 16 October 2014 20:12, Hans-Christoph Steiner h...@at.or.at wrote:


 Tristan Seligmann wrote:
 If you are fetching the upstream revisions / tags into your packaging
 repository, you can use the upstream tag exactly as-is, no need to
 re-tag (and indeed re-tagging would generally be a bad idea).

 I think there is a lot of value to always including the Debian upstream/v1.0
 tag.  It provides a standard way to access the upstream version across all
 repos.  There is no such standard out there in the wild.  There are tags
 like v1.0, 1.0, release-1.0, the-real-1.0, etc. etc.

Renaming the tag does not require retagging, git tag objects (perhaps
unfortunately) do not include their name.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


-- 
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/CAMcKhMTEMf8MgvaQB476mvG_=kz7mhalfbxv1bd9_zuouaj...@mail.gmail.com

Re: Keeping upstream commits separate from Debian packaging commits

[Tristan Seligmann]

On 13 October 2014 00:19, Barry Warsaw ba...@debian.org wrote:
 Maybe not mutually exclusive, but what's the point?  I certainly would not
 base the Debian packaging on anything but the upstream tarball, and most git
 workflows provide those as an unpacked upstream source branch.  Does upstream
 vcs add value?

I would expect it to make merging / rebasing Debian patches on top of
a new upstream version easier, since you have the granular history of
changes to the source tree, not one massive single commit which may
not be accurate (eg. renames of change files may not be detected
etc.). On the flip side, if there are few or no patches to the
upstream source, then it probably doesn't matter much at all.

 In any case, if upstream vcs is included in the team git repo, then I think
 it's incumbent on maintainers of those packages to document that in
 README.source (both how it's done and *why*) and to ensure that notifications
 of upstream commits are suppressed to team mailing list and IRC.

I do think the benefits of team maintenance are diminshed quite a lot
when packages need to have such specialized instructions, so aiming
for a standardized workflow / configuration (*whatever* that might
be!) is valuable.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


-- 
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/camckhmtkd09xajtrnxtcxj6qdbpfmaqxjwoqdbycx1twdhb...@mail.gmail.com

Re: Keeping upstream commits separate from Debian packaging commits

[Tristan Seligmann]

On 16 October 2014 18:01, Thomas Goirand z...@debian.org wrote:
 Using pristine-tar and pulling from upstream VCS is silly. If you do
 like this, then why not just doing tag-based packaging? That's a lot
 safer than just re-tagging on top of what upstream does (ie: no risk to
 introduce any difference).

If you are fetching the upstream revisions / tags into your packaging
repository, you can use the upstream tag exactly as-is, no need to
re-tag (and indeed re-tagging would generally be a bad idea).

 Using upstream tags
 *without* using pristine-tar would seem to be inadvisable

 For what reason exactly? In what way pristine-tar helps when basing your
 packaging on upstream Git tags?

The purpose of pristine-tar is the same whether you base it on a
revision fetched from upstream, or a revision created by
git-import-orig or a similar tool: it allows you to produce the
original byte-for-byte tarball from the git repository, without having
to store the tarball itself in the repository in addition to the
contents of the tarball. (Although apparently it does not always
succeed at doing this...)

For most software, the primary distribution mechanism is a tarball
released by upstream on their website, their project hosting service,
or on a service like PyPI. If such a tarball exists, and is suitable
for use in Debian, then having the upstream source in Debian match the
tarball distributed by upstream byte-for-byte makes it much easier to
verify that the source in Debian is unmodified from the upstream
source. This is harder when the tarball is generated from a git tag:
the source package does not include the information necessary to match
it against the git tag, comparing the individual files is necessary
instead of comparing the archive, and producing the upstream source
(.orig.tar.gz) will produce a tarball with different bytes every time
(even if the file contents will not change).

Alternatively, if you will never generate the upstream source from the
git repository, then you avoid this problem, but then building a
particular package version may require manually fetching the correct
tarball from the archive / snapshot.debian.org if they are no longer
available from the original source.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


-- 
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/camckhmsh34wrxyyb-bg_qprsugrupadhwswqk4zol+ocids...@mail.gmail.com

Re: Keeping upstream commits separate from Debian packaging commits

[Tristan Seligmann]

On 12 October 2014 08:49, Thomas Goirand z...@debian.org wrote:
 Also, during the Debconf discussion, we decided we would use the
 pristine-tar workflow, *not* using upstream VCS merge. A
 git-import-orig normally goes into a single commit, which I don't
 think would bother anyone (not on the list, or on IRC).

I wasn't at Debconf, maybe this is why I'm a bit confused by what you
wrote here. pristine-tar and upstream VCS merge are in no way mutually
exclusive, but you seem to be implying that they are; did I misread
what you wrote? pristine-tar just needs a commit to base the tar delta
off of; this can be a tag created via git-import-orig, but it can just
as easily be a tag pulled from upstream. (Using upstream tags
*without* using pristine-tar would seem to be inadvisable, with the
possible exception of upstreams who don't release tarballs, and/or
sign all their release tags)

 the DPMT. Anyone who doesn't respect what we are collectively agree on
 should IMO take the blame for what happened on IRC and on the commit
 list, and pointing fingers at whoever configured it is IMO wrong.

I haven't seen anyone write importing upstream VCS into the Alioth
repo is forbidden anywhere; if this is the intent, then perhaps it
should be clearly spelled out somewhere. (Or perhaps it already is,
and I just missed it? In which case, whoops)
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


-- 
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/CAMcKhMQTGotYsddxC+ynb5oFn0QrP1ng+hkui9Lv6U=4yfs...@mail.gmail.com

Re: Using pristine-tar (was: Keeping upstream commits separate from Debian packaging commits)

[Tristan Seligmann]

On 12 October 2014 12:36, W. Martin Borgert deba...@debian.org wrote:
 Isn't pristine-tar deprecated by its author? I read
 https://bugs.debian.org/737871 and

That's interesting, I didn't know about that. I'm not really sure I
understand how dgit replaces pristine-tar, unless you assume that
every tarball you want to store is in the archive. (Perhaps that's a
reasonable assumption?) And since we are not planning to use dgit in
DPMT (as I understand it), I'm not sure what the obvious way for us to
replace pristine-tar is.

 http://www.preining.info/blog/2014/06/debian-pristine-tar-packaging/

This doesn't load for me at the moment (database error). Okay, found
it in Google's cache; unfortunately the post doesn't say much beyond
I'm going to stop using pristine-tar.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


-- 
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/camckhmsope0fbowpxjesp5nyg8rjhp9jbxmltmmqsafmomm...@mail.gmail.com

Bug#761167: ITP: isort -- utility / library for sorting Python imports

[Tristan Seligmann]

X-Debbugs-CC: debian-python@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Tristan Seligmann mithra...@mithrandi.net

* Package name: isort
  Version : 3.9.0
  Upstream Author : Timothy Crosley
* URL : https://github.com/timothycrosley/isort
* License : MIT (Expat-style)
  Programming Lang: Python
  Description : utility / library for sorting Python imports

isort is a Python utility / library to sort imports alphabetically, and
automatically separated into sections. It provides a command line
utility, Python library and plugins for various editors to quickly sort
all your imports.

I intend to maintain this package within the Python Applications
Packaging Team.


-- 
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/CAMcKhMSUjXuwZBPYfykKY9aRX0rOYq=Q1Wz=AwV=-kej99e...@mail.gmail.com

Re: When packaging a library, should I prevent its test suite from being packaged

[Tristan Seligmann]

On 9 September 2014 16:53, Konstantin Khomoutov
flatw...@users.sourceforge.net wrote:
 Having the test suite packaged along with the code looks like having
 not much sense to me, so should I try to exclude this subdirectory from
 packaging?  Is it considered a bad practice?  I don't have much
 familiarity with Python, let alone packaging its libraries, so I'm not
 sure if removing such files will break the library or not and what
 seasoned Python packagers do in cases like this.

As a Python /user/, I would very much like it for the tests to be
installed along with a package when possible; this allows me to run
the tests on a particular system in order to verify that the
installation of the package is fully functional.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


-- 
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/camckhmq_wprhdygjtn-bzfxm2b9l6zpmk+tmuoa_q1scyt1...@mail.gmail.com

Re: dh_python3 inocrrect dependancy

[Tristan Seligmann]

On 5 July 2014 02:44, Brian May br...@microcomaustralia.com.au wrote:
 I assumed it wasn't valid to have a line with only one value in that file.
 Then again, not sure where this file is documented. Would have thought maybe
 the dh_python2 man page, it isn't there.

From the dh_python2 man page:

   dependencies
   dh_python2 tries to translate Python dependencies from
requires.txt file to Debian dependencies. Use debian/pydist-overrides
or --no-guessing-deps option to override it if the guess is incorrect.
If you want dh_python2  to generate more strict dependencies (f.e. to
avoid ABI problems) create debian/python-foo.pydist file. See
/usr/share/doc/python-doc/README.PyDist (provided by python-doc
package) for more information. If the pydist file contains PEP386 flag
or set of (uscan like) rules, dh_python2 will make the depedency
versioned (version requirements are ignored by default).

From the dh_python3 man page:

   dependencies
   dh_python3  tries  to translate Python dependencies from
requires.txt file to Debian dependencies. Use debian/py3dist-overrides
or --no-guessing-deps option to override it if the guess is incorrect.
If you want dh_python3 to
   generate more strict dependencies (f.e. to avoid ABI problems)
create debian/python3-foo.pydist file. See
/usr/share/doc/dh-python/README.PyDist for more information. If the
pydist file contains PEP386 flag or set of  (uscan
   like) rules, dh_python3 will make the depedency versioned
(version requirements are ignored by default).

Both copies of README.PyDist (in python-doc and dh-python) seem to
exist and be almost identical (main difference is that the dh-python
version has a few extra words about Python 3 / dh_python3 related
things which the python-doc version doesn't have).
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


-- 
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/camckhmqnkm3n+b5hn5v9k2ttx5ifmrmh4nd5o+1ab_0pjis...@mail.gmail.com

Bug#737356: ITP: cryptography -- a Python library which exposes cryptographic recipes and primitives.

[Tristan Seligmann]

Package: wnpp
Severity: wishlist
Owner: Tristan Seligmann mithra...@mithrandi.net

* Package name: cryptography
  Version : 0.1
  Upstream Author : Alex Gaynor, Hynek Schlawack, Donald Stufft, Laurens
Van Houtven, Jean-Paul Calderone, Christian Heimes,
Paul Kehrer, and individual contributors.
* URL : https://cryptography.io/
* License : Apache License, Version 2.0
  Programming Lang: Python
  Description : a Python library which exposes cryptographic recipes and 
primitives.

The cryptography library is designed to be a one-stop-shop for
all your cryptographic needs in Python.

As an alternative to the libraries that came before it, cryptography
tries to address some of the issues with those libraries:
 - Lack of PyPy and Python 3 support.
 - Lack of maintenance.
 - Use of poor implementations of algorithms (i.e. ones with known
   side-channel attacks).
 - Lack of high level, Cryptography for humans, APIs.
 - Absence of algorithms such as AES-GCM.
 - Poor introspectability, and thus poor testability.
 - Extremely error prone APIs, and bad defaults.

I will probably be maintaining this in DPMT. The binary package name will be
python-cryptography as per the standard Python naming convention.


-- 
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/20140201234040.3234.29142.report...@elvandar.mithrandi.net

Re: Using update-alternatives for /usr/bin provided binaries

[Tristan Seligmann]

On Tue, Oct 15, 2013 at 1:47 PM, Thomas Goirand z...@debian.org wrote:
 On 10/15/2013 06:21 PM, Tristan Seligmann wrote:
 What sort of upstream source code would be using the /usr/bin
 wrapper at all? (I ask this question without prejudice; I can
 obviously imagine some ways this might happen, but I'm more interested
 in the actual existing use cases that you implied, not ones that only
 exist in my imagination)

 I'm not sure if you're talking about the *full path* bit or what.
 Upstream code (or at least, unit tests...) is calling coverage from
 the standard accessible $PATH.

 For example:

 zigo@ ~/os/heat/heat heat (debian/havana)# cat tox.ini | grep coverage
   python setup.py testr --coverage

Does this really invoke /usr/bin/coverage, as opposed to just
importing the coverage module (I'm not familiar with testrepository)?
I would have expected most Python tools to just import the module,
rather than spawning the wrapper as an external process, hence my
original question. (In fact, how would that invocation even work
correctly, if it's running with whatever interpreter the `coverage`
wrapper uses, rather than the interpreter you invoked setup.py with?)

 The thing is, we can bikeshed about what *may* happen *in the future*.
 Though right now, there's a problem which I would like to fix. And that
 is very easily fixed by providing /usr/bin/coverage, while ugly
 hacking (because that's what it is about) in all other upstream
 projects is a much, much harder task.

I agree with this; if a naming conflict develops in the future, I
don't think renaming things then will be any harder than renaming them
now is, and if a conflict never develops, there isn't an issue to
begin with.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


-- 
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/CAMcKhMR3oWC=XLR7e6KRfi_kg=rygfgocuxkgqmdwkcruvs...@mail.gmail.com

Re: Using update-alternatives for /usr/bin provided binaries

[Tristan Seligmann]

On Tue, Oct 15, 2013 at 11:19 AM, Thomas Goirand z...@debian.org wrote:
 You will *not* find any upstream source code that will be using
 /usr/bin/python2-coverage or /usr/bin/python3-coverage. Absolutely all
 of them will be using /usr/bin/coverage (if they need the command line
 tool). Thinking that you will be able to patch all of them is both an
 illusion and a waste of time IMO.

What sort of upstream source code would be using the /usr/bin
wrapper at all? (I ask this question without prejudice; I can
obviously imagine some ways this might happen, but I'm more interested
in the actual existing use cases that you implied, not ones that only
exist in my imagination)

 * The name ‘/usr/bin/coverage’ is, IMO, far too generic to claim in
   Debian for a Python-only development tool.

 While I agree in principles, there is, so far, no other package that
 claims this file. You can use apt-file search /usr/bin/coverage to
 check for this. The problem is that *upstream code* is using
 /usr/bin/coverage. So unless you explain this to upstream and have the
 issue fixed over there, and have it fixed in the pypi package, you
 cannot expect downstream code (users of python-coverage) to use anything
 else.

I think this is ultimately the problem of whichever package comes
second, not python-coverage. (cf. other examples of name collisions,
like ack/ack-grep)

 Also, if there was another package that were using /usr/bin/coverage, it
 could also use the update-alternatives thing (if it's implementing the
 same thing, of course... otherwise we have a problem).

Presumably it would /not/ be implementing the same thing.


--
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/CAMcKhMShx87_d8dR=ouos+cfct_qhetx7hz+d6egli9dmbe...@mail.gmail.com

Re: virtualenv --system-site-packages (was: PEP 453 affects Debian packaging of Python packages)

[Tristan Seligmann]

On Wed, Sep 25, 2013 at 6:21 PM, Barry Warsaw ba...@debian.org wrote:

 On Sep 25, 2013, at 06:15 PM, W. Martin Borgert wrote:

 Quoting Barry Warsaw ba...@python.org:
  Sounds a lot like `virtualenv --system-site-packages` right?
 
 IMHO, --system-site-packages should be the default.
 IIRC, it was the default in squeeze (1.4.9),
 but is not anymore in wheezy (1.7.1.2). Opinions?

 FWIW, I always use it, except when I don't and then I'm mad at myself for
 forgetting that option.


I'm the exact opposite; I never use it. I only want to use system-installed
packages for system-installed things (installed via .deb, of course).
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

Re: python-virtualenv 0.10.1-1

[Tristan Seligmann]

On Wed, Aug 14, 2013 at 8:14 PM, Barry Warsaw ba...@debian.org wrote:

 This one was on my list, so thanks for getting to it before I did. :)

 I did some minimal testing.  It built fine, and I could create Python 2.7 and
 3.3 virtualenvs, and pip install a few packages into both.  A cursory look at
 the diff also seems fine and lintian is happy.  I'd say go for it.

Thanks! I've uploaded it (with one more change suggested by lintian4py).
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


-- 
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/camckhmq5-g1fho2hyds8bfsodije_c_4bhufbokszwxmvpn...@mail.gmail.com

Bug#719458: ITP: python-contextlib2 -- Backported utilities for context management

[Tristan Seligmann]

Package: wnpp
Severity: wishlist
Owner: Tristan Seligmann mithra...@mithrandi.net

* Package name: python-contextlib2
  Version : 0.4.0
  Upstream Author : Nick Coghlan
* URL : http://contextlib2.readthedocs.org/
* License : PSF License
  Programming Lang: Python
  Description : Backports and enhancements for the contextlib module

contextlib2 is a backport of the standard library's contextlib module to
earlier Python versions.

It also serves as a real world proving ground for possible future
enhancements to the standard library version.


-- 
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/20130812034638.3327.8862.report...@lorien.mithrandi.net

Re: How does team maintenace of python module works?

[Tristan Seligmann]

On Sat, Feb 16, 2013 at 11:10 AM, Thomas Goirand z...@debian.org wrote:
 Oh! Are you *sure* this is what you think of me? It's quite shocking to
 read that. It's not that at all. It's:

It's what I think are the practical consequences of what you propose.

 team)! Well, if I'm not allowed to use Git within the team, that's
 exactly what is going to happen for these packages. And I think it's a
 shame.

But this is exactly the point; if team members are doing work in SVN,
then your packages in Git are not benefitting from this work.
Conversely, if you are doing work on the packages in Git, other
packages in SVN are not benefitting. Of course, there's nothing that
prevents you to ask for advice / commentary / whatever on the
debian-python mailing list regardless of whether you are discussing a
package maintained in DPMT/PAPT or not; you can also follow the team
guidelines in maintaining these packages if you so choose.

 If others see it that way, then they are missing the main point, which
 is I have absolutely no choice of the VCS, given how much my packaging
 work is intertwined with what upstream is using. Let me enumerate again:
 signed pgp git tags (remember: I live in China, and China played with
 man in the middle attacks with Github...), cherry-pick of patches, git
 merge -X theirs tag-name for new release tags, git ls-files to
 generate the MANIFEST.in, git archive to generate the orig.tar.xz, my
 auto-builder script which is fully git based, using the upstream
 repository for the master branch, etc. SVN or git-svn will not allow me
 to do this.

It certainly sounds like maintaining the packages in Git is a
reasonable choice here, and I don't have any reason to second-guess
your choices as maintainer; I just don't see how you hope to benefit
from maintaining the packages in the team when you aren't actually
making use of the team infrastructure that provides these benefits.
--
mithrandi, i Ainil en-Balandor, a faer Ambar


-- 
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/CAMcKhMSO=_oojdawlgsnwq+l1prmzke-riswxmpfbnd3mqs...@mail.gmail.com

Re: How does team maintenace of python module works?

[Tristan Seligmann]

On Thu, Feb 14, 2013 at 5:08 PM, Thomas Goirand z...@debian.org wrote:
 During these exchanges, I have already found that there's at least 4
 people (including myself) who would like to use Git. And that's without
 including all the members of the Openstack packaging team, who might
 also help. Do you think that we should form another Alioth project for
 that? Wouldn't that be silly? What are the alternatives that you see, if
 we are a lot of people willing to do python module team maintenance
 using Git?

I don't think forming a separate team would be silly at all. If you
have a group of people working on Python packages in Git, and a
separate group of people working on Python packages in SVN, what use
is there in pretending that they're the same group when they're
effectively separate anyway? Of course, there may be some people who
are interested in working on both teams, but there's nothing stopping
you being a member of both teams if you choose to do so.

When you say I want to maintain my packages in Git, in the team,
there are really only two possible implications that I can see: 1) I
want everyone in the team to comply with this way of doing things,
even though they don't want to do so, and 2) I want to do things my
own way separate from the rest of the team, but claim to be working as
part of the team. Now, written that way, perhaps you can see why this
produces a negative reaction from some existing team members, even if
you did not mean it in that way?

The purpose of the team is to share the maintenance and infrastructure
burden for the packages included under the team's umbrella; when you
split that infrastructure, you effectively fork the team even if you
do not give the fork a new name. Such a fork naturally causes a
division of effort, but if you feel that Git vs. SVN makes enough of a
difference, then I see no reason why you shouldn't collaborate with
other people who feel the same way; it doesn't have to be a hostile
fork.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


-- 
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/camckhmsu-_0+ovjqrgfomkp3d8swz8pjc3g4i5h6lb8tnxu...@mail.gmail.com

Re: Second round of advise on packaging python-csb

[Tristan Seligmann]

On Wed, Nov 14, 2012 at 5:42 PM, Tomás Di Domenico td...@tdido.com.ar wrote:
 Another blurry point. I'm having a hard time understanding the
 separation of tasks between the tarball packaging done by upstream I
 described before, and my Debian packaging. Similar to the docs, the
 tests are run by upstream when they build the tarball. Is it common to
 also include these tests in Debian packages?

In my opinion, packages should always include a test suite if
available; this allows an end-user to run the test suite on their
system once the package is installed, thus allowing them to verify
that the software as installed on their system is actually functional.
Of course, running the test suite at package build time (and during
for development, for that matter) should also be done in order to
catch problems as far upstream as possible, but I think extending the
ability to test the software downstream as far as possible is also
important.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


--
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/camckhmraj2wz5fktrxwhsoy3yeyz+kco9r3wwhwp0yfojrd...@mail.gmail.com

Re: Build-Depends-Indep dependencies

[Tristan Seligmann]

On Tue, Oct 26, 2010 at 6:16 PM, anatoly techtonik techto...@gmail.com wrote:
 On Tue, Oct 26, 2010 at 7:09 PM, Tristan Seligmann
 mithra...@mithrandi.net wrote:
 On Tue, Oct 26, 2010 at 5:35 PM, anatoly techtonik techto...@gmail.com 
 wrote:
 many places outdated (email-based bug-trackers, ML without search,

 FWIW: http://lists.debian.org/search.html

 Cool. Why Python Application Team list is not there?
 http://lists.alioth.debian.org/mailman/listinfo/python-apps-team

lists.alioth.debian.org is separate infrastructure to
lists.debian.org, unfortunately.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


-- 
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/aanlktikb4csmwl8vw8mzkdshba3yvm5r2+oy4c=by...@mail.gmail.com

Re: Packages whith “except” overwriting builtins

[Tristan Seligmann]

On Tue, Aug 3, 2010 at 11:47 PM, Paul Wise p...@debian.org wrote:
 2010/8/3 Jakub Wilk jw...@debian.org:
 You might be easily mislead into thinking that this code
 ...
 will catch both IOError and OSError exceptions. In fact, it will not, as it
 is more or less equivalent to:
 ...
 There are about 50 packages in the archive whose developers make this kind
 of mistake. I have attached log file and dd-list. I'm not willing to do MBF,
 but if someone else is, please feel free to use my data.

 What about adding a lintian warning about this? Could file a bug about that?

How would you implement the warning? There's no way to easily tell
whether a given name is an existing class name or not.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


-- 
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/aanlkti=yak15r9do2f4_jotcgswsyiydy4v8rvd-z...@mail.gmail.com

Re: Proposed Email to the release team about XS/B-P-V

[Tristan Seligmann]

On Thu, Jun 24, 2010 at 12:35 PM, Piotr Ożarowski pi...@debian.org wrote:
 * A module that works perfectly with every Python = 2.5, but its
 documentation generation system required Python 2.6. Build-dep on python
 (= 2.6) is needed, which doesn't mean that modules shouldn't be
 byte-compiled for 2.5.

 python (= 2.6-1~) | python (= 2.5)
 (note that buildds ignore everything after |)

I don't think that relying on the current behaviour of the buildds to
make semantically incorrect build-deps work is a great idea, even if
that behaviour never changes.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


--
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/aanlktimiojzbkoggkwuuqpqks0o4whuktqlfnka1r...@mail.gmail.com

Re: python-twisted-core not getting updated on i386, but is updated on amd64 [was Re: Increasing number of conflicts]

[Tristan Seligmann]

On Wed, Apr 21, 2010 at 7:41 AM, Rick Thomas rbtho...@pobox.com wrote:
 The reason seems to be that python-twisted-core version 10.0.0-3 is
 available on amd64 Sid, but on i386 Sid it's only available at version
 10.0.0-2 .

 Maybe it needs to be rebuilt for i386 ?

python-twisted-core is an Arch: all package, so the same package is
used on all arches. According to pdo[1], sid has 10.0.0-3 while
squeeze (testing) only has 10.0.0-2.

[1] http://packages.debian.org/search?keywords=python-twisted-core
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


-- 
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/r2yf5eea9171004210841jb755a333r73ee70c88a4a9...@mail.gmail.com

Re: Would like a sponsor to upload the new version of python-foolscap

[Tristan Seligmann]

On Fri, Jan 29, 2010 at 1:50 AM, Ben Finney ben+deb...@benfinney.id.au wrote:
 Elliot Murphy ell...@canonical.com writes:

 I've added foolscap to the /topic in #debian-python

 That strikes me as a rather obnoxious thing to do. Why change the topic
 for the whole channel, rather than just communicating as an individual
 asking for assistance?

02:17:36 -!- Topic for #debian-python: DPMT: pysilc, pyfiglet,
objgraph, python-django-rosetta, pyxdg, python-whisper, foolscap |
PAPT: ibid | RC bugs: http://tiny.pl/hhg32 | binNMUs for Py2.6:
http://tinyurl.com/ybshvqf | http://tinyurl.com/Py26Transition |
Byte-compile files: http://tinyurl.com/yzs8fpv |
http://tinyurl.com/Py24Removal

The topic of the channel seems like a perfectly reasonable place for
this kind of list, too, so I'm not sure why you object to it so
strongly. Are you even in the channel?
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: XS-Python-Version vs pyversions

[Tristan Seligmann]

On Tue, Sep 8, 2009 at 6:45 PM, anatoly techtonik techto...@gmail.com wrote:
 Mailing lists are not documentation. Wiki is some kind of docs, but it
 still bears a high degree of uncertainty.

This is missing the point. The original point of contention was
whether or not certain communication occurred; the mailing list
archives are a record of communication that occurred on the list, and
are thus documentation of what communication occurred. As far as
documentation of policy goes:

 They were documented.  The documentation has bitrotted because consensus was
 abandoned.

 It once lived at http://people.debian.org/~piman/python-policy/ - before
 the python policy process degenerated into such an absurd mess that the
 maintainer left Debian entirely.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: r7926 - in packages/python-axiom/trunk/debian (5 files)

[Tristan Seligmann]

On Wed, Mar 18, 2009 at 11:21 PM, Vincent Bernat ber...@debian.org wrote:
 The patch is not complete: upgrading from old databases still fail.

Please don't upload a package based on this patch; it's highly likely
that the patch that will be applied upstream will involve quoting all
column names, not just indexed, and so any database created with
this patch applied will be incompatible (in a subtle way).

 Unittests are  shipped with databases in  old format and  axiom tries to
 upgrade  them. There  is no  fix upstream  for this  and the  patch only
 covers database creation. Old databases still have a problem.

 Here is the error:
 [ERROR]: 
 axiom.test.historic.test_textlist.TextlistTransitionTest.test_transition
 We could skip those tests. Any thought?

I don't think there's much we can do about this, unless SQLite is
patched to fix this problem. The only real solution that can be
implemented in Axiom is a meta-upgrader that upgrades old stores;
we'll then need to add a NEWS.Debian note or something to notify users
that they /must/ upgrade their old stores before upgrading SQLite.
That still seems horribly inadequate, but I don't know what else we
can do to make the transition easier.

I plan to implement a proper patch that quotes the column names, and
hopefully get it merged upstream in the next day or two.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: r7926 - in packages/python-axiom/trunk/debian (5 files)

[Tristan Seligmann]

On Wed, Mar 18, 2009 at 11:37 PM, Vincent Bernat ber...@debian.org wrote:
 As a work-around, in commit 7928,  I have just skipped unittests for the
 whole test/historic directory. This  is just a suggestion, maybe someone
 has a better idea?

I think that's fine for now; we can probably leave it like that until
this is fixed properly upstream.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Major update of python-support

[Tristan Seligmann]

* Josselin Mouette j...@debian.org [2009-03-02 16:21:20 +0100]:

 Le lundi 02 mars 2009 à 15:48 +0100, Vincent Bernat a écrit :
  I ask  this because I  have many packages  that use unittests  after the
  build.  I add  /var/lib/python-support  to PYTHONPATH  and launch  those
  tests. Because the path has changed, this does not work any more.
  
  You suggest to run those tests against the sources instead. However, the
  main interests of those tests for me is to check that the binary package
  works as expected. For example, if setup.py (or debian/rules) forgets to
  ship one  file, this would  go unseen if  unittests are run  against the
  sources.
 
 In this case, you should run the unit tests from the directory where you
 install the modules, before running dh_pysupport.

Note that the only way to accurately test that installing the binary
package will yield a correctly-working installation is to actually
install the binary package and run the unit tests against the installed
package; build-time tests will not be able to detect things like
problems with postinst scripts and so on.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


signature.asc
Description: Digital signature

Re: Developer workflow and DVCS (was: Leaving DPMT?)

[Tristan Seligmann]

* Ondrej Certik ond...@certik.cz [2009-03-02 11:07:25 -0500]:

  If you don't want the project history, then you can use lightweight
  checkouts, which are essentially equivalent to SVN checkouts (you get a
  local working copy, but no local branch or repository).
 
 Ah, so you basically only get the local working copy, but *no* bzr
 repository, right? Well, with git, you can get this over the web
 interface, so we may write a simple (Python:) script to download this
 for you from the commandline. Maybe someone did this already.

Does fetching the tarball(?) from the git web interface give you
something that you can commit changes with? You can still commit /
update / etc. in a bzr lightweight checkout, like you can with an SVN
working copy.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


signature.asc
Description: Digital signature

Re: numpy 1.2.1, switching to git?

[Tristan Seligmann]

* Ondrej Certik ond...@certik.cz [2008-12-21 00:08:18 +0100]:

 As to mercurial  Tristan, I don't know if you actually ever used
 hg-buildpackage, but it is written in Haskell (!) and see my blog post
 here:

I've used it; being written in Haskell isn't something I consider a
problem. It works just fine for what I've used it for; but then again,
the task it performs is relatively simple, so I could probably get along
without it just fine. The main thing that matters to me is using the
VCS itself, since I'll be spending a lot more time interacting with the
VCS than with some vcs-buildpackage tool.

 Anyway, besides stating which vcs one likes, this is mostly a debate
 over a beer in Prague, but well, why not, I just had several of them.

Heh.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


signature.asc
Description: Digital signature

Re: numpy 1.2.1, switching to git?

[Tristan Seligmann]

 On Thu, Dec 18, 2008 at 9:07 PM, Monty Taylor mo...@inaugust.com wrote:
  /me whinges that switching to bzr for packaging in general would be a
  much nicer thing overall, since then ubuntu downstream is pretty well
  bzr...
 
  (note: I use bzr for all of my other projects, so I have a vested interest)
 
  However... _anything_ is an improvement over svn.
 
 Matthias also wrote me offlist, that he either prefers to stay in svn,
 or use bzr, but not git (if I understood well).
 
 The problem with bzr is that it seems to me it is mainly used in
 Ubuntu, but that's about it. Also compare for example the number of
 packages in the respective vcs:

My personal preference ordering would probably be:

hg, bzr, svn, git
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


signature.asc
Description: Digital signature

Re: Bug#477454: RFS: quodlibet (1.0.ds1-1)

[Tristan Seligmann]

* Joey Hess [EMAIL PROTECTED] [2008-06-03 22:51:16 -0400]:

 Tristan Seligmann wrote:
  Well, fair enough; I suppose the README.Debian note should not be quite
  as explicit as I made it. I'm just not very happy with the gratuitous
  (in my view) change to the upstream tarball, so I wanted to be as clear
  about it as I could for anyone else wondering why it didn't match the
  released tarball. If it were up to me, I wouldn't be making this change
  at all, but it seems the alternative is to release lenny without
  quodlibet, which is not very satisfactory either.
 
 There has never been a clear explaination in #477454 as to why the bug
 should be considered RC at all, or why, if it is RC, it would require
 modification of the upstream tarball to fix.

The explanation appears to be because an RM says so; as far as
modifying the upstream tarball goes, the only way anyone is going to
see the offending code is if they go looking for it. If the objective is
just to avoid casual users from being exposed to it, then nothing needs
to be changed in the first place, so I don't see the point in doing
anything at all in that case.

Am I missing some other rationale here? Unfortunately Andreas Barth has
not yet provided any further clarity on his statement that the fix is
pretty easy and forward; CC'ing him again to find out what he meant...

Once again, my personal opinion is that this really shouldn't be such a
big deal that it would prevent the package from releasing as-is with
lenny; the relevant code has already been changed upstream, can't this
bug be left as a non-RC severity and be closed with the next upload of
a new upstream release? I would have just done that anyway, but it seems
the next upstream release is likely to be long after lenny, so this
isn't an option unless the severity of the bug can be downgraded.

 There have been vague mutterings about the content being illegal in
 germany; I've already pointed out in the bug log several other instances
 of personal insults included in Debian packages. If the people who think
 this is illegal in germany, and that Debian should censor such speech
 think this bug is RC, they need to begin a comprensive audit and mass RC
 bug filing on all the other packages too. (They might also find certian
 such insults on the Debian mailing lists..)

I believe the illegal in Germany reasoning has already been shot down.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


signature.asc
Description: Digital signature

RFS: mutagen (1.14-1)

[Tristan Seligmann]

Source package is here:

http://mithrandi.net/debian/pool/main/m/mutagen/mutagen_1.14-1.dsc

I've just packaged a new upstream version, the delta in the debian diff
is trivial.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


signature.asc
Description: Digital signature

RFS: quodlibet (1.0.ds1-1)

[Tristan Seligmann]

Source package is here:

http://mithrandi.net/debian/pool/main/q/quodlibet/quodlibet_1.0.ds1-1.dsc

Fixes #477454 which is an RC bug; changelog as follows:

 quodlibet (1.0.ds1-1) unstable; urgency=low
 .
   * Ship modified upstream tarball, removing insulting source code, and put a
 note in README.Debian to explain why we're doing this (closes: #477454).
   * Add Vcs-Darcs field.
   * Add Homepage field.
   * Update my e-mail address.
   * Stop updating .po files during build.

-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


signature.asc
Description: Digital signature

Re: RFS: quodlibet (1.0.ds1-1)

[Tristan Seligmann]

* Joey Hess [EMAIL PROTECTED] [2008-06-03 17:53:23 -0400]:

 If the presense of this buried in an internal source file is so
 vile/illegal/unlike other profanity in software in Debian that you have to
 *repackage* the upstream tarball to hide it from the tender eyes of our users
 (with all the problems that entails), why do you then turn around and add it
 back in to the most important file that we expect our users to read?

Well, fair enough; I suppose the README.Debian note should not be quite
as explicit as I made it. I'm just not very happy with the gratuitous
(in my view) change to the upstream tarball, so I wanted to be as clear
about it as I could for anyone else wondering why it didn't match the
released tarball. If it were up to me, I wouldn't be making this change
at all, but it seems the alternative is to release lenny without
quodlibet, which is not very satisfactory either.

I've prepared a new version with this change here:

http://mithrandi.net/debian/pool/main/q/quodlibet/quodlibet_1.0.ds1-2.dsc

 PS: What does quodlibet sponsorship have to do with the debian-python mailing
 list?

It's a python package, and sponsorship requests for Python packages are
often sent to this list.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


signature.asc
Description: Digital signature

Re: Bugs that'll block python 2.5

[Tristan Seligmann]

* Raphael Hertzog [EMAIL PROTECTED] [2008-04-15 14:56:40 +0200]:

 On Tue, 15 Apr 2008, Adeodato Simó wrote:
  * Josselin Mouette [Tue, 15 Apr 2008 12:28:00 +0200]:
   The solution is really simple, just add them to python’s Provides: list.
  
  Plus, uhm, can't really be done for (c)elementtree, since python 2.5
  provides the modules under a different name/namespace.
 
 ?!
 
 In that case it might be a good idea to build python-celementtree for
 python 2.5 as well... I haven't heard of technical incompatibility but
 just that it was bundled with python 2.5 and thus unneeded/in conflict.

Since elementtree/celementtree is still released as a standalone module,
a program or library might be using newer features that aren't available
in the stdlib version; this would be more complex to fix than just a
simple try/except ImportError.

 But if the namespace is different, there's no file conflict and I don't
 understand why we cared about not generating the module for python 2.5.

I'm not really sure either; it seems over-eager to get rid of the
standalone module, even if most software can be fairly easily fixed to
import the module from either location.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


signature.asc
Description: Digital signature

Re: free profiler in python

[Tristan Seligmann]

* Ondrej Certik [EMAIL PROTECTED] [2008-02-09 00:01:52 +0100]:

 the python-profile is in non-free, so what free tool do you use for
 profiling your python programs? There is cProfile in python2.5, which
 seems to be free, but for showing
 the result I need pstat, which is again non-free. Is there a DFSG free
 way to profile python programs?

I use lsprofcalltree, which fires up KCacheGrind to visualize the
results of profiling from cProfile (aka lsprof).
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


signature.asc
Description: Digital signature

Re: [python-odtwriter] package name wrong?

[Tristan Seligmann]

* Michael Schutte [EMAIL PROTECTED] [2008-02-10 09:17:54 +0100]:

 On Sat, Feb 09, 2008 at 02:20:26PM +0100, Bernd Zeimetz wrote:
  So python-docutils-writers-odtwriter would be the right name in theory,
  but this doesn't make sense, indeed.
 
 Does anybody insist on that name?  If not, I’m going to update the long
 description to mention the relationship to python-docutils, which
 probably would have avoided that bug report in the first place.

Personally, I think that package name is ludicrous; python-odtwriter
seems fine, this kind of extend another package package is an
exceptional case, so I think it makes sense to bend the naming rules a
little.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


signature.asc
Description: Digital signature

Re: Proposed update to the python policy

[Tristan Seligmann]

* Pierre Habouzit [EMAIL PROTECTED] [2007-03-21 21:49:00 +0100]:

 On Wed, Mar 21, 2007 at 09:25:52PM +0100, Piotr Ożarowski wrote:
  it's useful for Python applications that need specific Python version.
  
  f.e. if current Python version is 2.4 and my app. will work only with
  python2.5 and above, I can Build-depend on python-dev (= 2.5) | 
  python2.5-dev
  and set XS-Python-Version: to current, =2.5
  
  example packages: emma, pypar2, gaupol, griffith
 
   could you explain me in which part 'current' is helping you here ? I
 missed to understand what asking for:
 
   XS-Python-Version: = 2.5

Doesn't this indicate that the package should be built for all versions
2.5 and up, rather than a single version?

   and please tell me what it changed in the package you built with that.
 I'm curious. Btw I don't think you answered the question properly, as
 you didn't explained the think current achieves for you. And honnestly,
 it's not a trick question, I mean it, what is its purpose for you. I
 don't see its usefulness, but I may miss a thing :)

As I understood it, current indicates that the package should only be
built for one version of python, the version that is currently the
default version in Debian.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


signature.asc
Description: Digital signature

PMPT / Alioth

[Tristan Seligmann]

Hi,

I'd like to be added to the PMPT project on Alioth; my account name is
mithrandi-guest. I'll probably be comaintaning various Divmod packages
with Stefano Zacchiroli.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


signature.asc
Description: Digital signature

Re: python-support 0.6

[Tristan Seligmann]

* Arnaud Fontaine [EMAIL PROTECTED] [2007-02-19 15:32:29 +0100]:

 In addition,  I wonder why python2.5-setuptools doesn't  exist? Is there
 something wrong with setuptools and python2.5?

Package: python-setuptools
Provides: python2.4-setuptools, python2.5-setuptools
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


signature.asc
Description: Digital signature

Re: debian/pycompat usage?

[Tristan Seligmann]

* Josselin Mouette [EMAIL PROTECTED] [2006-08-26 11:18:15 +0200]:

 Le vendredi 25 août 2006 à 17:09 -0700, Steve Langasek a écrit :
   This decision was not unilateral, sorry.
  
  It was a decision, made by you as python-support maintainer, in direct
  contradiction to what Matthias and I had discussed before DebConf and the
  conclusions of the DebConf python BoF, without any consideration given to
  the original goal of these fields.  That's unilateral.
 
 If unilateral means that some people were disagreeing, you could also
 say the decision to implement them at first was unilateral.

unilateral adj 1: involving only one part or side
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


signature.asc
Description: Digital signature

Re: Orphaning Python packages

[Tristan Seligmann]

* Joe Wreschnig [EMAIL PROTECTED] [2006-06-19 12:48:22 -0500]:

 I've orphaned feedparser and the GStreamer Python bindings (the 0.8 and

 I've also put python-mutagen up for adoption. I'm upstream for this

 to a regression in Pygame/SDL) or quodlibet please let me know.

I would be interested in adopting any or all of feedparser,
python-mutagen, quodlibet.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


signature.asc
Description: Digital signature