Re: Status of sqlalchemy

[Martin]

Hi Piotr,

On 2024-04-15 15:07, Piotr Ożarowski wrote:
> sqlalchemy 2.X currently FTBFS due to a segmentation fault (3.11 and
> 3.12) somewhere in pysqlite:
...
> I will upload to unstable once I figure that one out

Any news on that? Thank you!
(I'm not sure, if I can help with that, unfortunately.)

Cheers

Re: Status of pymodbus (was: Status of sqlalchemy)

[Martin]

Hi Alexandre,

I pushed my changes to debian/master. If you have time to work on
pymodbus (e.g. update disable-failing-unittests.patch), please go on.
I probably can't work on that this week.

Cheers

Re: Status of pymodbus (was: Status of sqlalchemy)

[Martin]

Quoting Alexandre Detiste :

I ll check back home, but it's most likely I was waiting for SQLAlchemy
2.xx.


Good!


I know for share that one package does wait for SA 2.xx but can t remember
which one.


It looksk

like all but one of the debian/patches are obsolete now?


It seems, that *two* patches need to stay, but need work:

1. privacy-breach-fixes.patch (I updated this, can push later)

2. disable-failing-unittests.patch (needs more work, don't hold your breath)

There are also two (?) new build-depends. Again, I can push later.

debian/rules needs a minor PYTHONPATH fix. Will push when back home ;-)

Cheers

Status of pymodbus (was: Status of sqlalchemy)

[Martin]

On 2024-04-15 11:38, Alexandre Detiste wrote:
> Le lun. 15 avr. 2024 à 11:20, Thomas Goirand  a écrit :
>> The rest of:
>> - pymodbus
>>
>> I don't even know what they do.
>
> Life is better when one does not have to deal with modbus :-)

Yes!

> This package is outdated and need a refresh.

As I see, you already pushed a new upstream to git in January/February,
but did not yet upload the package. Are there any blockers? It looks
like all but one of the debian/patches are obsolete now?

Re: Status of sqlalchemy

[Martin]

Quoting Piotr Ożarowski :

sqlalchemy 2.X currently FTBFS due to a segmentation fault (3.11 and
3.12) somewhere in pysqlite:

...

I will upload to unstable once I figure that one out


Perfect! I prefer not to mess with the package, if I don't have to ;-)
Thanks, Piotr!

Re: Status of sqlalchemy

[Martin]

Quoting Thomas Goirand :

The rest of:
- pymodbus
- sqlalchemy-utc
- wtforms-alchemy

I don't even know what they do.

All that to say: I'm ok at this point if SQLA 2.x is uploaded to Sid  
and we move on...


I'll check, if I can update pymodbus, which is some versions behind
upstream. Maybe that already fixes things.

I don't know about the other two: I feel uneasy to break them, but we
need SQLAlchemy 2.x anyway, looks like 1.x is not supported anymore.

If nobody objects (or is faster than me), I'll upload SQLAlchemy 2.x
to unstable in a couple of days or weeks. No hurry from my side.

Cheers

Re: Status of sqlalchemy

[Martin]

Hi,

are there any news regarding the status of sqlalchemy?
I'm curious, because the next version of gajim will depend on
sqlalchemy >= 2, which is only in experimental right now.

Cheers

Re: morph's abandoned packages (list)

[Martin]

On 2024-03-15 14:21, Alexandre Detiste wrote:
> I would pick-up matplotlib I guess, I have some special connection to it,
...
> Help is appreciated, I already cherry picked some commits from Ciel's PR.

I *might* help on this, because we use matplotlib at $DAYJOB, but can't
promise much, as my workload is already pretty high.

Cheers

Re: Suggesting change in DPT policy

[Martin]

On 2024-02-27 15:15, Thomas Goirand wrote:
> Though indeed, I don't
> think it's reasonable to have a package in the team, but with strong
> ownership. I believe that we should either have a package in the team,
> or not. Period.

I'm in favour of that change, too, but I can live with the current state
as well. All my packages are team owned, and I'm mere uploader, anyway.

Cheers

Bug#1063940: ITP: python-term-image -- Display images in the terminal with Python

[Martin]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-python@lists.debian.org

Package Name: python-term-image
Version: v0.7.1
Upstream Author: Toluwaleke Ogundipe 
License: MIT
Programming Lang: Python 3
Homepage: https://github.com/AnonymouX47/term-image

Description: Display images in the terminal with Python term-image is a
 library and program to display images on compatible terminals.
 .
 Features:
  - Multiple image formats (basically all formats supported by PIL.Image.open()
  - Multiple image source types: PIL image instance, local file, URL
  - Multiple image render styles (with automatic support detection)
  - Support for multiple terminal graphics protocols: Kitty, iTerm2
- Exposes various features of the protocols
  - Transparency support (with multiple options)
  - Animated image support (including transparent ones)
- Multiple formats: GIF, WEBP, APNG (and possibly more)
- Fully controllable iteration over rendered frames of animated images
- Image animation with multiple parameters
  - Integration into various TUI / terminal-based output libraries.
  - Terminal size awareness
  - Automatic and manual image sizing
  - Horizontal and vertical alignment
  - Automatic and manual font ratio adjustment (to preserve image aspect ratio)

This is a new, optional dependency (Recommends) of libervia-backend.

Bug#1063815: ITP: vapid -- Simple VAPID header generation library

[Martin]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-python@lists.debian.org

Package Name: vapid / python3-py-vapid
Version: 1.8.2
Upstream Author: JR Conlin 
License: MPL2
Programming Lang: Python 3
Homepage: https://github.com/web-push-libs/vapid

Description: Simple VAPID header generation library
 This minimal library contains the minimal set of functions you need to
 generate a VAPID key set and get the headers you'll need to sign a
 WebPush subscription update.

Bug#1063814: ITP: encrypted-content-encoding -- Encrypted Content-Encoding for HTTP

[Martin]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-python@lists.debian.org

Package Name: encrypted-content-encoding / python3-http-ece
Version: v1.2.0
Upstream Author: Martin Thomson 
License: MIT
Programming Lang: Python 3
Homepage: https://github.com/web-push-libs/encrypted-content-encoding

Description: Encrypted Content-Encoding for HTTP
 This library implements HTTP ECE in accordance with RFC 8188.
 It is needed e.g. for WebPush.

Bug#1057361: ITP: pickle-secure -- wrapper around pickle that creates encrypted pickles

[Martin]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-python@lists.debian.org
Control: blocks 1019277 by -1

Package Name: pickle-secure
Version: 0.99.9
Upstream Author: Stephanos Kuma 
License: LGPL-3
Programming Lang: Python 3

Description: wrapper around pickle that creates encrypted pickles
 pickle-secure offers a similar API as the built-in pickle.

This is a (build) dependency for Slidge.

Re: Updating python3-xlrd for pandas 1.5 compatibility

[Martin]

On 2023-02-22 23:12, Diane Trout wrote:
> | visidata | none | Build-Depends |

There seems to be no versioned depends or similar in the code.
Should be safe, but in doubt ask Anja (upstream).

Cheers

Bug#1021759: ITP: py-rnp -- Python bindings for librnp

[Martin]

Package: wnpp
Owner: deba...@debian.org
Severity: wishlist

* Package name: py-rnp
  Version : 0.1.0
  Upstream Author : Daniel Wyatt 
* URL or Web page : https://github.com/rnpgp/py-rnp
* License : (under investigation)
  Description : Intent to Package [ITP]

Python bindings for librnp.

RNP is a set of cross-platform tools implementing OpenPGP (RFC 4880) and
related standards.

Bug#1021569: RFP: ttconv -- library and tool for converting timed text or subtitle formats

[Martin]

Package: wnpp
Severity: wishlist

* Package name: ttconv
  Version : 1.0.5
  Upstream Author : Pierre-Anthony Lemieux 
* URL or Web page : https://github.com/sandflow/ttconv
* License : BSD 2-Clause
  Description : library and tool for converting timed text or subtitle 
formats

ttconv is a library and command line application written in pure Python
for converting between timed text formats used in the presentations of
captions, subtitles, karaoke, etc.

Input formats: TTML / IMSC, SCC / CEA 608, EBU STL, SRT

Output formats: IMSC / TTML, WebVTT, SRT

Bug#1019492: RFP: python-aiosignald -- Python bindings for signald

[Martin]

Package: wnpp
Severity: wishlist

* Package name: python-aiosignald
  Version : v0.3.1
  Upstream Author : Nicolas Cedilnik 
* URL or Web page : https://git.sr.ht/~nicoco/aiosignald
* License : AGPL-3+
  Description : Python bindings for signald
  
> Interact with the signal messaging network in python with sweet, sweet
> autocompletion. Most of the code is generated by the generate.py
> script that uses the schema available at
> https://signald.org/protocol.json. No 3rd party dep, just the python
> standard lib.

Re: Desire to join

[Martin]

On 2022-08-03 19:57, Felix Delattre wrote:
> So far I have contributed to Debian:

And Felix is also my co-upstream of https://tracker.debian.org/sms4you :-)

Bug#1008738: ITP: python-cobs -- Consistent Overhead Byte Stuffing for Python

[Martin]

Package: wnpp
Severity: wishlist
Owner: Martin 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org

* Package name: python-cobs
  Version : v1.2.0
  Upstream Author : Craig McQueen
* URL : https://github.com/cmcqueen/cobs-python/
* License : MIT
  Programming Lang: Python
  Description : Consistent Overhead Byte Stuffing for Python

The cobs package is provided, which contains modules containing functions for
encoding and decoding according to COBS methods.

I intent to maintain this package under the umbrella of the Debian  
Python Team.

Request to join the Debian Python Team

[Martin Günther]

Hi all,

I would like to join the Debian Python Team. My salsa handle is 
"mguenther" (the account is still pending approval).


The reason why I would like to join the team is to maintain the
"pass-git-helper" package, which is currently up for adoption [1]. 
Jochen Sprickerhof (jspri...@debian.org) will transfer the package to 
the DPT and sponsor me.


I have read the policy [2] and accept it.

Best wishes,
Martin


[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007004

[2]: 
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst




OpenPGP_signature
Description: OpenPGP digital signature

Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided upstream source tarballs

[Martin]

On 2021-06-26 02:04, Paul Wise wrote:
> I would like to see #2 split into two separate tarballs, one for the
> exact copy of the git tree and one containing the data about the other
> tarball. Then use dpkg-source v3 secondary tarballs to add the data
> about the git repo to the Debian source package.

IIRC, last time I tried multiple tarballs, I got stuck with
pristine-tar. Not sure, if I didn't find out how to commit or
if the problem was with checkout, though.

Do you happen to know, if this is an issue?

PS: Just for the record: I'm always(?) using upstream sources
from git, not PyPi, because the latter typically are missing
unit tests, which we want to run in Debian.

Re: Remove trac from Debian 11?

[Martin]

On 2021-05-10 14:00, Andrius Merkys wrote:
> I do not think that slowing down of development is reason serious enough
> to remove a package which is otherwise fine. Or are there other reasons
> that I am not aware of?

I don't have a problem with slow development, but the current
version is probably not good enough to maintain it for some
years. I'm optimistic, that in some months or so 1.6.x will
be released, which should be fine. I'm planning to backport it
to Debian 11, so that users still can install trac easily.

Remove trac from Debian 11?

[Martin]

Dears,

trac is a long-time Debian package, uploaded first by Jesus
Climent in 2004. I like the traditional look of Trac and its
climate-friendly resource usage :-)

Now, while Trac is still maintained upstream and has been ported
to Python 3 recently, development slowed down since long and the
current 1.5.x release series is not yet "there".

I wonder, whether the package should be part of Debian 11, or
better miss one stable release and have it in better shape for
Debian 12.

If nobody objects, I'll file a bug to keep it out of Debian 11.

Comments welcome!

Cheers

Re: Python package situation

[Martin]

On 2021-02-17 02:13, Andrey Rahmatullin wrote:
> Are you asking about testing or stable? Because for stable the "packages
> are either outdated or do not exist" situation is somewhat expected and
> testing is not that interesting case, though even in testing we may have a
> lot of outdated packages.

At work, we are using stable with backports. Once in a while we
make a local package or local backport, too, and put it in our
local (reprepro driven) repo. Very often, we can just accept the
version in Debian, even if it is not the latest one.

> Surely you use only a subset of modules while other people may need a
> different subset, and ability to make and upload new or updated packages,
> unavailable for most Debian Python users, is definitely helpful.

Yes, having upload rights to Debian, incl. backports, is very
helpful and I was not implying that it were the same situation
for those without that priviledge :-)

But at least people on this ML either have that possibility or
know how to file RFPs/ITPs or just ask the right people.

But that option is less attractive, if the work is far too much,
i.e. either too many packages involved or very tricky packages -
for technical or other reasons.

That's why I'm curious: Maybe the missing packages are the same
for multiple people and we can solve the problem?

Python package situation

[Martin]

On 2021-02-16 10:17, Bastian Venthur wrote:
> I *wish* I could
> just install everything via the Debian Packaging System, but the reality for
> most relevant Python packages is very different: packages are either
> outdated or do not exist in Debian

Are you talking about many packages? Or only some, that are
difficult to package? Can you give an example?

At my job, we were always able to stay with Debian packages, or
I just packaged the missing pieces, but maybe our use case is
not that advanced.

I believe, that we don't have much of the Django ecosystem
packaged and many aio* packages seem to be missing...

Cheers

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

[Martin]

On 2021-02-12 10:16, Thomas Goirand wrote:
> I mostly agree to add a metapackage. I just don't agree with the choice
> of package name. It makes our user believe that Python isn't "full"
> without it, and they then may install it when they don't need it to
> consume whatever is packaged in Debian. Reality is different.

I agree with your technical point of view. Friends don't let
friends use pip and I banned its use at work.

I don't care about having the package or not and how it were
named, as long as it remains easy to not have it.

Cheers

Re: python3-(py)crypto(dome)?

[Martin]

On 2020-12-05 19:51, Andrey Rahmatullin wrote:
> On Sat, Dec 05, 2020 at 02:43:44PM +0100, Martin wrote:
> > Package wokkel has changed the dependency from python3-crypto to
> > python3-cryptodome, leading to #975748 and #975770.
> The changelog entry says "Switch to python3-pycryptodome" but the control
> field says "python3-cryptodome". This is a bug in python3-wokkel,
> unrelated to the initial question here.

Related in the sense: If python3-pycryptodome would provide
python3-crypto, the old dependency were correct. If
python3-pycryptodome would be renamed to python3-cryptodome, the
current dependency were correct. The fix in wokkel should not
lead to a problem after the next upload of python3-pycryptodome.
Anyway, if nobody objects, I just upload the fixed wokkel.

Cheers

python3-(py)crypto(dome)?

[Martin]

Dears,

I'm a little confused about what the correct name for the
binary package python3-pycryptodome should or will be.

Because https://bugs.debian.org/891619 talks about renaming it
and/or providing python3-crypto.

Package wokkel has changed the dependency from python3-crypto to
python3-cryptodome, leading to #975748 and #975770.

For now, I would upload wokkel with changed dependency, from
python3-cryptodome to python3-pycryptodome. Any objections?

Cheers

Re: Granting `Janitor` direct access to our teams repos

[Martin]

On 2020-07-27 20:18, Sandro Tosi wrote:
> So: let's just make that automatic? Thoughts?

Yes.

Re: packaging DiscoDOS - a cli tool for vinyl DJs

[Martin]

On 2020-05-15 17:43, jojo wrote:
> I'd like to join the list because I think my software is a valuable addition
> to the debian universe, my ultimate goal would be to bring it into Ubuntu
> Studio because it is music-related.

Cool! Sounds like a very interesting program, indeed!

Remove or update pyfeed and xmlelements

[Martin]

Hi Matteo, hi Thomas,

the new version of salutatoi does not need python-feed and
python-xe anymore. AFAIK, there are not other dependencies on
them. Maybe you would like to ask for removal?
If not, remember to update them to Python 3 (currently supported
only in experimental, but still with Python 2 versions).

Cheers

Re: Non-migration of cssutils

[Martin]

Quoting Mattia Rizzolo :

Given that the whole stack of packages is scheduled to get out on
2020-02-16, it's more likely that everything will be removed, and then
cssutils will migrate back (and with it everything that will be suitable
to migrate back into testing) at the next britney run.


That's fine for me! Thanks for the explanation!

Re: Non-migration of cssutils

[Martin]

Quoting Mattia Rizzolo :

I reckon the way forward is to fix those two FTBFS in calibre.


If calibre gets removed from testing on 2020-02-16, the reason
for non-migration of cssutils and removing depending packages
from testing, e.g. gajim, vanishes. Will this work out due to
britneys wisdom? Or should calibre better removed from testing
before 2020-02-16, if problems are not fixed until then?

Non-migration of cssutils

[Martin]

Hi,

at https://tracker.debian.org/pkg/cssutils I don't see,
why the package does not migrate. Some package depend on
cssutils and will be removed from testing soon...

Any idea what's wrong with cssutils?

TIA & Cheers

Re: Future of Trac in Debian

[Martin]

Quoting Sandro Tosi :

So Jan 1 arrived, what do you think we should do? i didnt see any
progress on the port to python3 upstream; should we start filing RM
for trac extensions/plugins and once they are gone, RM src:trac?


I don't expect a Python 3 version of Trac before a year from now.
Debian, the high speed train, overtakes Trac, the steam train!


an initial list of packages for the first pass of RM could be:

$ apt-cache search trac-
libnet-trac-perl - Perl client library for Trac
libtext-trac-perl - module for formatting text with Trac Wiki Style


AFAIK, those two are not Python and can use a remote Trac server,
so they can stay. All others need to be removed.


if i dont hear anything back withing a week, i'll most likely opening
those RM bugs, so that we can work on their transitive dependencies.


Just go ahead. I hope, we can reintroduce Trac in one or two
years, maybe in time for Debian 12 (bookworm), but probably not
for Debian 11 (bullseye).

Help with interpreting piuparts error

[Martin]

Hi,

I'm not sure how to interpret this 14799 lines piuparts log:
https://piuparts.debian.org/sid/fail/python-aiohttp-session-doc_2.9.0-2.log
It says "ERROR: FAIL: Installation and purging test."
Any idea what's wrong with the package? TIA!

Cheers

Re: Future of Trac in Debian

[Martin]

On 2019-11-29 18:13, Nicholas D Steeves wrote:
> IMHO one of the Debian Trac uploaders should post to the #12130 Trac
> ticket informing them of our plan.

I linked to the email of 2019-10-14:
https://trac.edgewall.org/ticket/12130#comment:63

Re: Future of Trac in Debian

[Martin]

On 2019-11-29 16:24, Sandro Tosi wrote:
> I know it may sound hard, but is it now time to remove trac from
> Debian, and ideally re-introduce it back when it's being ported to
> py3k?

See also:
https://groups.google.com/forum/#!topic/trac-users/5VMI83sbqFs
What would be the alternative?

It would be nice to have newer versions (based on Python 2) as
backports or sloppy backports for buster, but that will not be
possible anymore, as soon as Trac is removed from unstable,
right?

Btw. Trac development is still active (1.4 released three months
ago, but slow, maybe because of lack of developers:
"Trac 1.4 is the first major release of Trac in almost 3 years."
Trac 1.6 will probably use Python 3. But when? Nobody knows.

Cheers

Re: Python 3 transition question

[Martin Kelly]

On 9/2/19 1:18 PM, Martin Kelly wrote:

On 9/1/19 10:07 PM, Scott Kitterman wrote:



On September 2, 2019 4:00:53 AM UTC, Sandro Tosi  
wrote:

I would just stop building these.  And if the reverse dependencies

have a

py2removal bug itself, then comment in these issues that the
suggested/recommended package gets removed.  If they don't have a

py2removal

bug, please file the bugs for these packages.


i dont believe this is a sensible approach; for example i maintain
python-mpmath, that would be rendered uninstallable the moment
python-gmp2 is removed. Now, python-mpmath has 3 external
reverse-dependencies (just to name a couple, sagemath and simpy) that
would be then uninstallable, and so on and so forth for all their
rdeps.

Martin, i think for now the only option is to keep the py2 packages
around until we're ready to drop them (ie they have 0 rdeps).


I just checked on packages.d.o and according to it, python-gmp2 is a 
Suggests.  Suggests aren't installed with packages.  Unless I'm 
missing something, python-mpmath wouldn't become uninstallable.


IIRC, policy doesn't even require Suggests packages to exist.

I agree about keeping packages as long as they have reverse 
Recommends, but I think Suggests is going too far (although AIUI, 
missing Recommends don't make the package uninstallable either).


Scott K



If I'm summarizing correctly, it sounds like there is no policy on 
exactly what to do here. I think removing the package would be pretty 
bad, because gmpy is designed to speed up numerical libraries, and the 
performance hit without it would make many libraries really painful to 
use. Given this, perhaps the dependencies should be Recommends instead 
of Suggests.


The guidelines I saw in the bugs filed on my packages (e.g. bug #937791) 
say to "document" the reverse dependency. Where do I document this?


(ping). I'd like to resolve the bugs I have on my packages and am not 
sure yet how best to proceed.

Re: Python 3 transition question

[Martin Kelly]

On 9/1/19 10:07 PM, Scott Kitterman wrote:



On September 2, 2019 4:00:53 AM UTC, Sandro Tosi  wrote:

I would just stop building these.  And if the reverse dependencies

have a

py2removal bug itself, then comment in these issues that the
suggested/recommended package gets removed.  If they don't have a

py2removal

bug, please file the bugs for these packages.


i dont believe this is a sensible approach; for example i maintain
python-mpmath, that would be rendered uninstallable the moment
python-gmp2 is removed. Now, python-mpmath has 3 external
reverse-dependencies (just to name a couple, sagemath and simpy) that
would be then uninstallable, and so on and so forth for all their
rdeps.

Martin, i think for now the only option is to keep the py2 packages
around until we're ready to drop them (ie they have 0 rdeps).


I just checked on packages.d.o and according to it, python-gmp2 is a Suggests.  
Suggests aren't installed with packages.  Unless I'm missing something, 
python-mpmath wouldn't become uninstallable.

IIRC, policy doesn't even require Suggests packages to exist.

I agree about keeping packages as long as they have reverse Recommends, but I 
think Suggests is going too far (although AIUI, missing Recommends don't make 
the package uninstallable either).

Scott K



If I'm summarizing correctly, it sounds like there is no policy on 
exactly what to do here. I think removing the package would be pretty 
bad, because gmpy is designed to speed up numerical libraries, and the 
performance hit without it would make many libraries really painful to 
use. Given this, perhaps the dependencies should be Recommends instead 
of Suggests.


The guidelines I saw in the bugs filed on my packages (e.g. bug #937791) 
say to "document" the reverse dependency. Where do I document this?

Re: dropping python2 [was Re: scientific python stack transitions]

[W. Martin Borgert]

On 2019-07-08 10:00, Elena ``of Valhalla'' wrote:
> I don't think it would be accepted by backports, since it goes against
> the requirement that stuff in backports is in testing (and meant to
> remain there when it becomes stable).

I'm not sure, but building an additional binary package from the
same source package might be OK for bpo. Of course, d/control
etc. would differ, but that's common.

Re: Please enable me pushing to python-team/applications

[W. Martin Borgert]

On 2019-03-21 00:47, Thomas Goirand wrote:
> Can't you guys just simply give write access to Andreas? What's the
> issue? Why is it taking so long? This really give the feeling the "team"
> is still very much dysfunctional,

Maybe two, three people more can get "owner" permissions?

Remove python-social-auth?

[W. Martin Borgert]

Hi,

I like to make python-social-auth a transitional package which
installs social-auth-core and social-auth-app-django. Which is
practically the new project by upstream. Or just remove it?
We don't want python-social-auth in buster, do we?

TIA & Cheers

Re: Dropping Python 2 support for web.py before buster

[W. Martin Borgert]

On 2019-02-04 12:14, Raphael Hertzog wrote:
> Anyway, the fact that we have one known user should not forbid you
> to go forward with all this. I will change the Kali infrastructure
> to use something else, most likely buildd and wannabuild.

Or maybe port rebuildd to Python 3?

Re: Help with setuptools-related build break

[Martin Kelly]

On 1/26/19 4:56 PM, Scott Kitterman wrote:

On Saturday, January 26, 2019 04:05:50 PM Martin Kelly wrote:

Hi,

I'm attempting to release a new version of my package python-gmpy2 [1]
and am hitting a bug that I can't figure out how to resolve.
Specifically, in the latest version under pbuilder, python-setuptools is
missing. When I add python-setuptools and python3-setuptools it to the
build dependencies, I get the following error:

Err http://cdn-fastly.deb.debian.org/debian sid/main amd64
python-pkg-resources all 39.2.0-1
404  Not Found [IP: 151.101.52.204 80]
Err http://cdn-fastly.deb.debian.org/debian sid/main amd64
python-setuptools all 39.2.0-1
404  Not Found [IP: 151.101.52.204 80]
Err http://cdn-fastly.deb.debian.org/debian sid/main amd64
python3-setuptools all 39.2.0-1
404  Not Found [IP: 151.101.52.204 80]
E: Failed to fetch
http://cdn-fastly.deb.debian.org/debian/pool/main/p/python-setuptools/python
-pkg-resources_39.2.0-1_all.deb: 404  Not Found [IP: 151.101.52.204 80]
E: Unable to fetch some packages; try '-o APT::Get::Fix-Missing=true' to
continue with missing packages

[snip]

E: pbuilder-satisfydepends failed.

Indeed, this package version does not exist in the repo, so I'm not sure
why apt is attempting to install it.

Does anyone have some guidance and/or debugging suggestions?

Thanks,
Martin

[1] https://salsa.debian.org/python-team/modules/python-gmpy2


Those are obsolete versions.  You need to run pbuilder update.

Scott K



Thanks, this is what I thought as well, and so I kept running pbuilder 
update to no avail. I realized that I was using cowbuilder, so the 
update was happening on a different chroot. After starting from a clean 
cowbuilder, the problem is gone.

Help with setuptools-related build break

[Martin Kelly]

Hi,

I'm attempting to release a new version of my package python-gmpy2 [1] 
and am hitting a bug that I can't figure out how to resolve. 
Specifically, in the latest version under pbuilder, python-setuptools is 
missing. When I add python-setuptools and python3-setuptools it to the 
build dependencies, I get the following error:


Err http://cdn-fastly.deb.debian.org/debian sid/main amd64 
python-pkg-resources all 39.2.0-1

  404  Not Found [IP: 151.101.52.204 80]
Err http://cdn-fastly.deb.debian.org/debian sid/main amd64 
python-setuptools all 39.2.0-1

  404  Not Found [IP: 151.101.52.204 80]
Err http://cdn-fastly.deb.debian.org/debian sid/main amd64 
python3-setuptools all 39.2.0-1

  404  Not Found [IP: 151.101.52.204 80]
E: Failed to fetch 
http://cdn-fastly.deb.debian.org/debian/pool/main/p/python-setuptools/python-pkg-resources_39.2.0-1_all.deb: 
404  Not Found [IP: 151.101.52.204 80]
E: Unable to fetch some packages; try '-o APT::Get::Fix-Missing=true' to 
continue with missing packages


[snip]

E: pbuilder-satisfydepends failed.

Indeed, this package version does not exist in the repo, so I'm not sure 
why apt is attempting to install it.


Does anyone have some guidance and/or debugging suggestions?

Thanks,
Martin

[1] https://salsa.debian.org/python-team/modules/python-gmpy2

Re: Dropping Python 2 support for web.py before buster

[W. Martin Borgert]

On 2019-01-22 15:02, Julien Danjou wrote:
> I'm not actively maintaining rebuildd for years now. I'm not even sure
> it has still any user. I wouldn't spend time on porting rebuildd nor I
> would let it block it updating web.py.
> Not sure what's the other solution would be (removal?) but if you have
> any idea, go ahead.

OK, I'll upload web.py without Python 2 support then.
If someone has strong interest in rebuildd, they has to make a
Python 3 version anyway. If the package is not in buster, there
can still be a backport.

Thanks for your input, Julien, Julien, and Mattia!

Re: Dropping Python 2 support for web.py before buster

[W. Martin Borgert]

Quoting Mattia Rizzolo :

On Tue, Jan 22, 2019 at 12:18:09PM +0100, W. Martin Borgert wrote:

I'm going to package the latest git master of web.py¹, because of
Python 3.7 compatibility. It has a new dependency on cheroot², which
has only a Python 3 version in Debian. I could ask Julien to provide a
Python 2 package of cheroot for buster, but I prefer to drop Python 2
support of web.py instead. Any opinions?


I would say "go for the drop!!!" if not for the presence of a reverse
dependency of the python2 package (rebuildd).  So IMHO the best would
be:
 * port rebuildd to py3
 * drop the py2 package


Julien & Julien, how realistic is moving rebuildd³ to Python 3 for
buster? Or better upload cheroot with Python 2 support for now?
The update of web.py is, unfortunately, necessary for Python 3.7.

Cheers

¹https://tracker.debian.org/webpy
²https://tracker.debian.org/python-cheroot
³https://tracker.debian.org/rebuildd

Dropping Python 2 support for web.py before buster

[W. Martin Borgert]

Hi,

I'm going to package the latest git master of web.py¹, because of
Python 3.7 compatibility. It has a new dependency on cheroot², which
has only a Python 3 version in Debian. I could ask Julien to provide a
Python 2 package of cheroot for buster, but I prefer to drop Python 2
support of web.py instead. Any opinions?

Cheers

¹https://tracker.debian.org/webpy
²https://tracker.debian.org/python-cheroot

cssutils salsa PR review or permission update

[Martin Pitt]

Hello Pythoneers,

The other day I worked a bit on the cssutils package (I'm a co-maintainer). But
then I noticed that since the salsa migration I can't commit to the official
packaging git any more, so I sent a PR instead:

  https://salsa.debian.org/python-team/modules/cssutils/merge_requests/1/commits

Does the Python modules team receive notifications about these? I don't mind
much working through PRs, or perhaps it's possible to add me as a committer for
cssutils on the salsa repo? I just wouldn't like to upload a new version
and leave the VCS out of date.

Thanks for any suggestions,

Martin

Re: Matplotlib 3.0 - update ok?

[W. Martin Borgert]

Quoting Steffen Möller :
Now, I am tempted to create a package matplotlib3 instead of forcing  
everyone to update from this long term release (see  
https://matplotlib.org/).


Any opinions from your sides?


I wonder, whether it's easier to wait for buster and then create an
orange backport? I'm sure, immediately after release, we (= Python
teams) will start to drop Python 2 support anyway. In the mean time
new versions of matplotlib and friends, as well as orange, might be
suitable for experimental, so that your packaging work doesn't need
to wait. Orange looks very interesting and is a welcome addition to
Debian, btw.!

Re: git-dpm -> gbp conversion (mass-change)

[W. Martin Borgert]

On 2018-08-03 10:08, W. Martin Borgert wrote:
> On 2018-08-03 08:04, Simon McVittie wrote:
> > There is no upstream/master, upstream/unstable, upstream/stretch or
> > similar in DEP-14, because:
> 
> I did not suggest mingling upstream branches with Debian
> versions, which seems to be your impression. I just (maybe
> wrongly) thought, that upstream/master whatever upstream does in
^ follows
> their master/tip/trunk (just as upstream/latest always follows
> the latest upstream release). I don't remember, where I got that
> idea from. Unreliable sources :~)

Re: git-dpm -> gbp conversion (mass-change)

[W. Martin Borgert]

On 2018-08-03 08:04, Simon McVittie wrote:
> There is no upstream/master, upstream/unstable, upstream/stretch or
> similar in DEP-14, because:

I did not suggest mingling upstream branches with Debian
versions, which seems to be your impression. I just (maybe
wrongly) thought, that upstream/master whatever upstream does in
their master/tip/trunk (just as upstream/latest always follows
the latest upstream release). I don't remember, where I got that
idea from. Unreliable sources :~)

Re: git-dpm -> gbp conversion (mass-change)

[W. Martin Borgert]

On 2018-08-03 04:33, Scott Kitterman wrote:
> On August 3, 2018 3:51:00 AM UTC, "W. Martin Borgert"  
> wrote:
> >How about changing "upstream" to "upstream/latest" (for upstream
> >releases, typically for unstable) and "upstream/master" (for
> >following upstream master, typically for experimental)?
>
> I think we should just follow DEP-14 branch naming conventions (which, having 
> re-read it, I discover I haven't been doing).

In fact, I thought that "upstream/master" were DEP-14-ish, but
only "upstream/latest" (for the newest release) is.

Re: git-dpm -> gbp conversion (mass-change)

[W. Martin Borgert]

On 2018-08-03 11:06, Ondrej Novy wrote:
> 2. change default branch to debian/master

How about changing "upstream" to "upstream/latest" (for upstream
releases, typically for unstable) and "upstream/master" (for
following upstream master, typically for experimental)?

Request to join the Python Modules team

[Martin Kelly]

Hi,

I would like to join the Salsa Python Modules team in order to continue 
maintaining my package python-gmpy2. I previously had Alioth access and 
have finally had time to migrate to Salsa.


My Salsa login is aomighty-guest.

I have attempted to read and accept the Python Modules policy 
(https://python-modules.alioth.debian.org/python-modules-policy.html), 
as stated in https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin, 
but the link is dead.


Thanks,
Martin

Re: Backport of Python 3.6 for Debian Stretch?

[W. Martin Borgert]

Quoting Nguyễn Hồng Quân :

Python 3.6 has much better performance than Python 3.5, especially on
embedded computer (I tried and compared).


This is interesting! Did you also compare Python 2.7 with 3.5/3.6?
I'm looking for more reasons to finally port my embedded software :~)

Re: Backport of Python 3.6 for Debian Stretch?

[W. Martin Borgert]

Quoting Nguyễn Hồng Quân :

We write an application which needs Python 3.6.


Could you elaborate, why you need Python 3.6 instead of 3.5?
Maybe there is a way to make your application work with 3.5?
E.g. by backporting specific modules?

Re: Where to put docs of a -doc package for python 2 + 3 modules?

[W. Martin Borgert]

Quoting Thomas Goirand :

Which is why I think we should have standardize on python-foo for the
source package (which is what I do).


Same here, even if foo is not yet taken.

Save the environment, do not pollute the global packages namespace! :~)

Re: Where to put docs of a -doc package for python 2 + 3 modules?

[W. Martin Borgert]

On 2018-03-12 23:15, Thomas Goirand wrote:
> But what now that python-foo is gone? Should I rename the doc package?

No, but that's just my gut feeling.

Re: Where to put docs of a -doc package for python 2 + 3 modules?

[W. Martin Borgert]

Quoting Simon McVittie :

In python-mpd-doc and python-dbus-doc, I installed the real documentation
files in /u/s/d/python-*-doc, but placed symlinks to them in both
/u/s/d/python-* and /u/s/d/python3-*. Perhaps that's a reasonable way
to achieve the spirit of the Policy §12.3 recommendation while not
privileging one of Python 2, Python 3, PyPy, etc. over the others?


Nice idea, I'll do the same. Thanks!

Where to put docs of a -doc package for python 2 + 3 modules?

[W. Martin Borgert]

Hi,

policy (12.3) says, that putting the contents of package-doc
into /usr/share/doc/package/ (main package) is preferred over
/usr/share/doc/package-doc/. debhelper detects the Python 2
package as main package. One can override this to the path for
the Python 3 package, but both feels wrong to me. Even if we
drop Python 2 at some point, maybe then there is Python 4 or
PyPy. I tend to stay with the traditional path, and ignore
the preference of our beloved policy. Not without first
consulting this very mailing list, of course. Opinions?

TIA & Cheers

Re: PAPT migrated to Git on Salsa

[W. Martin Borgert]

On 2018-02-24 23:49, Stefano Rivera wrote:
>  'trac-batchmodify',
>  'trac-git',

The functionality of those two is now part of trac itself.
We might want to keep them for LTS purposes until they are not
part of any LTS release anymore. But I don't care much...

Re: Help proposed for migration of PAPT repos to Salsa

[W. Martin Borgert]

Quoting Stefano Rivera :

I didn't get much review last time, but there did seem to be a general
+1


From me not only "+1", but also "thank you"!

PAPT repo at salsa.d.o open for new packages now?

[W. Martin Borgert]

Hi,

if I have a Python program, that currently is not yet maintained
by PAPT, but want to move it to the team: May I use
salsa.d.o/python-team/applications/ now? Any objections?

TIA & Cheers

Re: Move to salsa? Team structure preview ready

[W. Martin Borgert]

Quoting Ondrej Novy :

2018-02-08 10:14 GMT+01:00 Ondrej Novy :

I created team "python-team" in salsa with 3 subgroups:


interpreter
modules
applications


OK.


I can do DPMT GIT migration, but I need agreement on new structure.


OK! :~)


We can merge two subgroups later.


No need to merge the subgroups ever.
With this structure, it is one team already.

If there nobody objects, we have to:
 - migrate the git archives (you volunteered, thanks!)
 - ask for membership in the team (everybody)
 - change Python team documentation (who?)
 - make an MR for https://salsa.debian.org/salsa/AliothRewriter (who?)
 - ?

Re: Merge modules and apps team?

[W. Martin Borgert]

On 2018-02-07 09:58, Matthias Klose wrote:
> I don't think that is a good idea.  Both teams are not very active when it 
> comes
> to address RC issues and updating to new upstream versions.  From my point of
> view the apps team is worse than the modules team in this regard.

In fact, this is one of the reasons I like to merge them. I hope,
that the slightly better situation of the modules will rub off on
the apps.  My illusions might be in vain, but at least I do not
see any disadvantage in the merge.

Move to salsa? Merge modules and apps team?

[W. Martin Borgert]

Hi,

how about moving the Python team(s) to salsa?
And how about merging the modules and apps teams into one?

Moving git packages (modules team) is very easy using
import.sh from https://salsa.debian.org/mehdi/salsa-scripts.git

Moving svn packages (apps team) is probably more work.

Any opinions? Any doubts?

TIA & Cheers

Re: Update wokkel?

[W. Martin Borgert]

On 2017-10-27 17:26, Angel Abad wrote:
> Because there is no official release with these changes, I will
> write upstream developer and I will tell you.

Was there any outcome? TIA!

Help the orphans! (here: Python modules)

[W. Martin Borgert]

Hi,

unfortunately, I had to orphan some packages:

python-activipy -- implementation of ActivityStreams 2.0 (#882871)
python-mpld3 -- D3 viewer for matplotlib (#882858)
python-mplexporter -- general matplotlib exporter (#882857)
python-odoorpc -- pilot Odoo servers through RPC (#882870)
python-oerplib -- Python client library to Odoo server (#882868)

Maybe somebody likes to take over one or the other?

TIA & Cheers

Update wokkel?

[W. Martin Borgert]

Hi Angel and team,

would you mind, if I update wokkel and close #735304 (teams git
repo) and #879712 (Python 3 support)? I would add myself to
uploaders, too.

TIA & Cheers


signature.asc
Description: PGP signature

Re: pycharm package in debian

[W. Martin Borgert]

On 2017-10-02 10:37, Thomas Goirand wrote:
> On 10/01/2017 11:50 PM, Matthias Klose wrote:
> > Do you want point users to the five year lagging behind eclipse package in 
> > Debian?
>
> Why 5 years? We do release stable approx every 2.5 years...

5 years minus 12 days:
Eclipse 3.8.1 has been uploaded to Debian on 2012-10-14.

Cheers

Re: pycharm package in debian

[W. Martin Borgert]

On 2017-10-01 23:16, Andrey Rahmatullin wrote:
> On Sun, Oct 01, 2017 at 04:52:55PM +0200, W. Martin Borgert wrote:
> > I usually start to use software, when it arrives in Debian.
> > Or I package it. If there is some snap or other third party
> > package, I'm unsure how to work with it:
> >
> > How to install?
> I expand the tarball to ~
...

This is my point: I'm too lazy and too old to find out for every
random application how to install, uninstall, upgrade it, find
out which version, if any, is installed on my system, whether
the software complies with the DFSG, etc.

> Surely you don't expect the Debian maintainers to fix bugs you could
> encounter in PyCharm?

I expect Debian maintainers to forward bugs to upstream, if they
assume, that the bug is not introduced by them. (For some highly
complex software, like Gnome or KDE, this is not practical, but
for many packages this should work.)

Cheers

Re: pycharm package in debian

[W. Martin Borgert]

On 2017-10-01 17:16, Ghislain Vaillant wrote:
> Most likely a lot. We are talking about a large application with probably
> quite a few dependencies in Java / Kotlin.
>
> Why not? Because failure to commit to regular updates would feed the
> current narrative that Debian ships old and loosely maintained software.
> Especially when there are other means of installing the software which are
> officially documented upstream.
>
> I have been there with packages I personally maintain (spyder for
> instance), and I am raising these concerns out of my own experience and
> feedback from existing users. Feel free to disregard.

Those are absolutely valid concers. I'm aware of many outdated
packages, including some maintained by me. I leave the challenge
to those, who like to package it. Still, if PyCharm were in
Debian, I would at least try it out some day.

Cheers

PS: Is there maybe something broken with the quoting function of
your MUA? I cannot differentiate between text written by you and
quoted text. There is no '> ' or whatever...

Re: pycharm package in debian

[W. Martin Borgert]

On 2017-10-01 08:26, Ghislain Vaillant wrote:
> May I ask what would be the benefit for pycharm to be in Debian, when we
> already have the official Jetbrains Toolbox App or the snap package as means
> to install and update the application?

I usually start to use software, when it arrives in Debian.
Or I package it. If there is some snap or other third party
package, I'm unsure how to work with it:

How to install? How to uninstall? How to report bugs and to
whom? How to download the source code and rebuild it? Is it
DFSG-free anyway? (Does it already build reproducible?)

There is nothing wrong with having snap or other packages
available, but I'm not their target audience. But I'm an Emacs
- and vi! - user anyway :~)

Another question is, how much work it will be and whether it is
worth the effort, esp. permanent maintenance. But if somebody
wants to do it, why not?

Cheers

Re: Docs only packages?

[W. Martin Borgert]

On 2017-09-24 10:35, Diane Trout wrote:
> What do people think about having documentation only packages?

Good thing. Like manpages etc.


signature.asc
Description: PGP signature

Re: Question about binary sphinx inventory files

[W. Martin Borgert]

On 2017-08-26 11:42, Dmitry Shachnev wrote:
> https://codesearch.debian.net/search?q=html%2Fobjects%5C.inv+path%3Adebian%2Fpatches%2F.*

I should use codesearch more often :~)
And "searx" should have a backend for it!

Re: Question about binary sphinx inventory files

[W. Martin Borgert]

On 2017-08-25 22:36, Tristan Seligmann wrote:
> 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.

Thanks! I use the packaged file now in python-simpy3.
AFAIK, only python-numpy still uses a downloaded .inv.

Uploading Python modules which drop support for Python 2?

[W. Martin Borgert]

Hi team,

pysolar upstream version 0.7 dropped support for Python 2, so I
did not upload it for stretch. I'm considering upload for buster
now. What do you think?

Cheers


signature.asc
Description: PGP signature

Re: django-cms in Debian?

[W. Martin Borgert]

Quoting Dominik George :

at Teckids, we are about to start using Django CMS for our website.

We have a policy to only use Debian stable/main if at all possible.


This is a very useful policy!


So I wonder whether there is a reason django-cms is not in Debian?
(Apart from "noone started maintaining it" ;)


No, it's just "work", as far as I know.


In other words, before I start packaging django-cms and its missing
dependencies, is there anything I should know?


Just read https://bugs.debian.org/516183, I'm sure I'm not the only
one who very much appreciates having Django CMS in Debian!

Cheers

Re: PAPT git migration

[W. Martin Borgert]

Many thanks, Stefano, for your work on this!

On 2017-05-31 20:58, Stefano Rivera wrote:
> * trac-batchmodify: OK
> * trac-git: missing a tag [DONE]

Those two are only in oldstable.
Not sure whether it is worth to migrate them at all.

> * trac-privateticketsplugin: missing some tags [DONE]

This git repository should probably renamed to
trac-privatetickets.

Cheers

alioth python-apps access for moschlarb-guest

[Christoph Martin]

Der Python-Apps Alioth project maintainers,

please give moschlarb-guest access rights to the repositories in
python-apps. He wants to help maintain together with me nagstamon.

Regars
Christoph
-- 

Christoph Martin, Leiter Unix-Systeme
Zentrum für Datenverarbeitung, Uni-Mainz, Germany
 Anselm Franz von Bentzel-Weg 12, 55128 Mainz
 Telefon: +49(6131)3926337
 Instant-Messaging: Jabber: mar...@uni-mainz.de
  (Siehe http://www.zdv.uni-mainz.de/4010.php)
<>

signature.asc
Description: OpenPGP digital signature

Re: [Python-modules-commits] [python-social-auth] 55/89: Merge pull request #821 from open-craft/saml-no-idp

[W. Martin Borgert]

On 2016-12-24 10:48, Sandro Tosi wrote:
> what's all this? 89 commits? are you pulling commits from upstream
> git? this looks just spam to the mailing list

Sorry, this was not intended. I pulled upstream in fact, but I
was not aware that I was pushing it to our git, too. :~(

Re: DEP 8: Gathering Django usage analytics

[W. Martin Borgert]

Quoting Barry Warsaw :

I'd love to know if there's a Debian-wide policy on such things.  E.g. if
"opt-out with informed user consent" was an official policy that we could
clearly point to and reference, it would greatly help provide  
guidance to both

Debian maintainers and upstreams.


In the issue at github someone already points out that popcon is "opt-in"
and I'm sure, that the overwhelming majority in Debian is in favour of it
in contrast to "opt-out". I can understand, that upstream would prefer
the latter, but Debian has a reputation for taking privacy issues very
serious and likes to keep it. Not sure about any policy on this, though.
If Django implements usage analytics, I would strongly suggest to make it
"opt-in" in Debian, just as popcon, not "opt-out".

Cheers

Joining the team

[Martin Kratochvíl]

 Hi,

> Why you want to join the team: e.g. maintain your current packages within
the team, help maintain some specific packages, etc.

I want to maintain new package python3-geoip2 (and others). And I want to

help with other packages too.

> Your Alioth login.

krata-guest

> A statement that you have read
https://python-modules.alioth.debian.org/policy.html and that you accept it.

I read the policy and I'm accepting it.

Thanks
--
Ing. Martin Kratochvíl

Re: on keep providing python 2 packages

[W. Martin Borgert]

On 2016-08-19 08:19, Sandro Tosi wrote:
> does anyone else agrees with this view? should we clarify that, when
> available, python2 modules must be provided (along with their py3k)?

Yes.

Re: using git-dpm or plain git-buildpackage in PAPT and DPMT (was: PAPT Git)

[W. Martin Borgert]

On 2016-08-10 10:18, Thomas Goirand wrote:
> Instead of
> accepting the merge, and resolving conflicts later on, git-dpm goes into
> the rebase conflict mode of Git, and it's often not obvious what to do
> there. Messing-up everything, and restart from scratch (and then iterate
> until done properly) isn't uncommon.

Been there, lost hours :~(

> As I only heard complains about git-dpm, maybe someone would like to
> express his joy using it, and explain why they think it's a nice tool.
> But is there such person? It seems git-dpm only brings frustration.

Well, in most cases I did not have any problems with it.
Points I like and would prefer not to change:
 - no need to use quilt
 - no special build command, just plain dpkg-bp or whatever

The idea to try something else in PAPT is very welcome from my
side, no matter what tool.

PAPT Git (was: pypi2deb 1.20160809 and --profile dpmt)

[W. Martin Borgert]

On 2016-08-09 23:28, Daniel Stender wrote:
> On this occasion ... let it be me to start the discussion: let's get into Git
> also for Python Apps soon.

A common VCS for both DPMT and PAPT would be nice, indeed.

(I have been reminded rightfully by both Piotr and Sandro, that
PAPT still uses SVN. Changing that would increase my fun level!)

Re: removing $(PYBUILD_NAME).egg-info with clean target in debian/rules?

[Martin A. Brown]

Greetings Piotr and Ondrej,

>> Problem description:  when I run 'debclean' or 'debian/rules clean', 
>> I still have a directory called 'tldp.egg-info'.  I don't want it to 
>> remain after 'clean'.
>
>pybuild removed that in the past, but some tools complained so I 
>disabled this feature. You can get it back by adding 
>"foo.egg-info/*" to debian/clean file. It's OK to remove it in 
>clean target - these files will be regenerated.

Excellent!

>I'm using this:
>
># cat debian/source/options
>extend-diff-ignore = "^[^/]*[.]egg-info/"
>
>and keeping .egg-info here.
>
>But if you don't want it here, use dh_clean OR create file debian/clean
>(man dh_clean for complete doc).

I will do that.  Thank you both for your quick replies.

Best,

-Martin

-- 
Martin A. Brown
http://linux-ip.net/

removing $(PYBUILD_NAME).egg-info with clean target in debian/rules?

[Martin A. Brown]

Hello all,

I'm trying to prepare a package (tldp, python3-tldp) for acceptance.  
I have mentor support from sponsor Gianfranco Costamanga (under bug 
#822722).

My build works.  It was really easy using the pybuild system.  
Thank you to whomever wrote that.

Problem description:  when I run 'debclean' or 'debian/rules clean', 
I still have a directory called 'tldp.egg-info'.  I don't want it to 
remain after 'clean'.

Therefore, I added the following fragment to my rules (please ignore 
the removal of the Sphinx _build dir):

override_dh_clean:
(cd docs && \
rm -rf -- ./_build)
rm -rf -- ./$(PYBUILD_NAME).egg-info
dh_clean

Gianfranco's comment is that I should not need to remove this 
.egg-info thing myself.

Is there a better way to remove $(PYBUILD_NAME).egg-info?

Is the 'clean' target not the right one?  Is there a 'distclean' or 
something else I should be using?

Thank you in advance,

-Martin

 [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822722

-- 
Martin A. Brown
http://linux-ip.net/

Re: Autopkgtest smoke test for Python libraries

[Martin Pitt]

Hey Barry,

Barry Warsaw [2016-03-01 10:48 -0500]:
> I gather that it's supposed to be used by the maintainer in a source package
> ($vcs repo) to jumpstart a debian/tests directory?

You could use it for that purpose indeed, but that's not really what
it is intended for. The idea is that the generic tests apply to all
packages of a particular type, so you can change them centrally
instead of having to modify and upload hundreds of packages.

There is one more thing, though: The test machinery needs to be able
to discover that a package has an autodep8 test (without having the
source package already available, as getting and checking that is very
expensive). So ideally all source packages which want to use that will
get a "Testsuite: autopkgtest-pkg-python" header in debian/control,
like for example libnet-oauth-perl. However, until these get uploaded
we can add some custom code to debci to recognize those packages based
on the name and dependencies (that's what we did for bootstrapping the
perl and ruby autodep8 tests).

> I'm not sure how useful things like "setup.py test" are for DEP-8.  In general
> I think a package's test suite are best exercised during package build[*].

During package build is of course good, but one of the points of
autopkgtest is to run the tests when one of your dependencies change
(and thus potentially break you).

> For the majority of Python packages, I view DEP-8 as ensuring that the user
> experience is what they expect, and that means at a minimum that the packages
> import and Do Something Simple.  A generic proof of non-broken import can mean
> printing the package's version or the module path, and that's something that
> autopkg8 could templatize.  Anything more than that requires some more
> detailed knowledge about what the package does.

As I said, running upstream tests works surprisingly well for
Perl/Ruby, we had about 80% success rate. But they are a bit more
rigid in structure apparently.

But indeed, ensuring that your module still imports already says a
lot. New dependencies can still break your module in subtle ways, but
at least things like new/removed Python versions, linker errors, wrong
paths etc. are spotted.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: PGP signature

Re: Autopkgtest smoke test for Python libraries

[Martin Pitt]

Hello all,

Thanks to Matthias for pointing this out to me. I try to reply
in-thread. Please keep CC:ing me as I'm not subscribed.

> The goal is to perform a simple “smoke test” to verify the correct
> installation of the Python libraries from the Debian packages, for all
> relevant Python interpreters.
> 
> A secondary goal is to have the actual smoke test code be re-usable,
> possibly incorporated into a standard Debian Python packager toolkit.

Very nice! There's precedent for Perl, Ruby and DKMS packages which
have a fairly standard way to run the upstream test suite. For Python
there are some conventions, like "./setup.py test" or running
nosetests, maybe it's worth experimenting with those after getting the
initial "import works" smoketest in place.

This situation (testing many related packages in a similar way) is
what autodep8 is for. When run in a Debian source package tree, it
checks if it knows something about this type of package, and if so,
synthesizes a debian/tests/control. Have a look at

  http://anonscm.debian.org/cgit/collab-maint/autodep8.git/tree/

which has a README, and the "detect" and "generate" scripts in
support/.

> * debian/tests/control
> 
>   Specifies two tests to run, ‘smoke-python2’ and ‘smoke-python3’.
> 
>   The dependencies explicitly specify the Python 2 and Python 3 library
>   modules respectively. Can this be automated better?

The "generate" script could iterate over all binary packages of the
source and pick out the python-* or the python3-* ones, respectively.

> * debian/tests/smoke-python2, debian/tests/smoke-python3
> 
>   These are Bash programs that just run a Python module under every
>   available Python interpreter.
> 
>   Running ‘py{,3}versions -i’ gets all the installed Python
>   interpreters. Can this fail, e.g. can the set of interpreters be
>   different from what interpreters the package was built for?

Yes, it can, and that's IMHO a situation where you *want* the test to
fail, as your package is actually broken (or at least in need of a
binNMU).

>   These scripts are very simple, but not simple enough that I was
>   comfortable stuffing them directly into the ‘debian/tests/control’
>   file. Is that a shortcoming of the Autopkgtest specification?

Not sure what you mean with "shortcoming", you can put arbitrary shell
code into Test-Command:. However, the spirit is that these should be
very short, usually one line. I suggest that they should mostly just
call something like "/usr/share/python-something/run-autopkgtest $py $pkgname"
and you maintain the actual test code centrally in e. g.
python-defaults.

> * debian/tests/smoke_test.py
> 
>   A module that runs a simple suite of smoke tests: emit the interpreter
>   description, fetch the Python distribution of the installed library
>   and emit that, import the modules and emit those.
> 
>   Implemented as a command-line program so that the distribution name,
>   and the set of module names, are specified by the caller. This
>   hopefully makes ‘smoke_test.py’ reuseable for many Python library
>   packages.
> 
>   Does this module meet your idea of a simple “smoke test” for Python
>   library packages? Should it do more?

That seems like an excellent starting point indeed. Making sure that
all modules are importable will catch missing builds for particular
Python versions, regressions in newer Python versions, missing
dependencies, packaging errors, etc. As said above, maybe in the
future we want to try and run upstream test suites, but this will need
a lot more heuristics (starting with additional test deps).

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: PGP signature

Request to join DPMT

[Tim Martin]

Hi,

I'd like to join the DPMT. I'm interested in packaging some Python
libraries for Yang and Netconf (pyang and pyangbind).

My Alioth username is timmartin-guest.

I've read and agree to
https://python-modules.alioth.debian.org/python-modules-policy.html

Tim

Re: conflicting packages python-pysocks and python-socksipy

[W. Martin Borgert]

On 2016-01-08 01:54, Scott Kitterman wrote:
...
> This is done (#810306).
...
> Bug#810309: torchat 
> Bug#810308: python-sleekxmpp
> Bug#810307: offlineimap

Scott, many thanks for filing the bugs and fixing python-socksipy!

conflicting packages python-pysocks and python-socksipy

[W. Martin Borgert]

Hi,

TLDR: Both are the same, providing the "socks" module. We should
remove one of them. Maybe renaming the other to python-socks.

Longer story: Recently, I upgraded the outdated python-socksipy
package. This involved following a new upstream. Later I was
informed, that the new upstream was already packaged under the
name python-pysocks.

Questions:

 - shall we remove one of the package?
   (proposal: yes)
 - which of the two packages should be removed from Debian?
   (proposal: remove pysocks, just because socksipy is older)
 - shall the other package provide dummy transitional packages?
   (proposal: yes)
 - shall we rename the binary package to python-socks?
   (proposal: yes)

Any ideas or opinions?

TIA & Cheers

python-cherrypy (was: packages without any uploaders)

[W. Martin Borgert]

On 2015-12-12 21:41, Mattia Rizzolo wrote:
> https://tracker.debian.org/pkg/python-cherrypy
>
> This package, python-cherrpy, is Maintainer: DPMT, but has nobody listed
> in Uploaders.
...
> I'm CCing the former maintainer, since I don't know if he follows this
> list.

If neither Gustavo nor you were interested in CherryPy, I would
consider putting my name in the Uploaders field. I would
probably upgrade the package to version 3.8.1 and add a Python 3
package - we still ship seven year old 2.3.0 and only Python 2.

Cheers

Re: python-cherrypy (was: packages without any uploaders)

[W. Martin Borgert]

On 2015-12-13 00:22, W. Martin Borgert wrote:
> If neither Gustavo nor you were interested in CherryPy, I would
> consider putting my name in the Uploaders field. I would
> probably upgrade the package to version 3.8.1 and add a Python 3
> package - we still ship seven year old 2.3.0 and only Python 2.

I just checked again and realised that there is a cherrypy3
package which is not outdated at all and well-maintained by
Gustavo. But it also lacks the Uploaders name. Easy to fix :~)

Sorry for the noise!

pyftpdlib: Working on Python 3 etc.

[W. Martin Borgert]

Hi,

just a heads-up email:

I will try to work on some open bugs of python-pyftpdlib,
mainly because I need the Python 3 version urgently.

Janos, if you want me to stop, just say so! :~)

Cheers

pristine-tar (was: Git migration schedule)

[W. Martin Borgert]

Quoting Julien Puydt :

Do you know pristine-tar is orphaned ? (bug #737871)


This is known to readers of this mailing list, e.g.
https://lists.debian.org/debian-python/2014/10/msg00039.html
So far, it just seems to work for (most of?) us.

Cheers

team vs individual as maintainer (was: radical changes)

[W. Martin Borgert]

Quoting Piotr Ożarowski :

I assume you all like other ideas, like no team in Maintainer, right?


To me, "team maintenance" would mean, that the team appears in the
"Maintainer" field. In "Uploaders" it doesn't make sense, so where
would the team appear?

Personally, I prefer to have the team in "Maintainer" to encourage
others to intervent.

How about leaving it as is? I.e. people in the team decide what is
more appropriate for a package?

Cheers