Re: Requests to join DPT haven't been processed for months

[Christian Kastner]

On 2024-04-03 16:50, Stefano Rivera wrote:
> We've added a new owner to help out. Thanks peb!
> 
> Stefano

Excellent, thanks Stefano and of course Pierre-Elliott for taking care
of this!

Best,
Christian

Requests to join DPT haven't been processed for months

[Christian Kastner]

Hi,

one of the GSoC candidates I'm mentoring hasn't had his request to join
the team processed for a month. I then checked and unless I'm mistaken,
*no*( requests filed in 2024 have been processed. At least, all threads
I could find are as of yet unanswered.

Some of the requests were already accompanied by contributions, so it
would be a extra shame to have these contributors move on.

Is there any way I (or anyone else) can help with this?

Best,
Christian

Re: Request to join Debian Python team

[Christian Kastner]

Hi admins,

On 2024-03-09 16:49, Xuanteng Huang wrote:
> Sorry for bothering. I’m writing this to kindly remind this request.
> And please let me know if there is anything to fix.

I fully support this request, if it's any help. Xuanteng is working with
the Debian ROCm Team but I asked him to publish the general Python stuff
under the DPT.

Best,
Christian

Re: Suggesting change in DPT policy

[Christian Kastner]

On 2024-03-03 17:32, Thomas Goirand wrote:
> On 3/3/24 00:37, Christian Kastner wrote:
>> For
>> example, I also often skip tests -- it's just that I do it under
>> conditions that I'm happy to defend (cause isolated, reported upstream,
>> etc.), but others may not be aware of that.
> 
> There are many cases where skipping tests is ok. As you wrote, when
> reported upstream, and when the thing that's broken is the test itself
> (but the functionality is not broken).
> 
> The best practice is to document somewhere in the package (in d/rules?)
> why it's been disabled. I have to admit I often don't do that extra
> documentation work myself though (though mostly on packages I maintain
> alone, for OpenStack for example).

I agree and have no issue with this. On the contrary, I consider this
proper. I do it myself all the time. I've also temporarily disabled doc
builds (for some transition). But I make note of these things in d/rules
(or wherever it makes sense), and/or file bugs, etc.

In the case I'm talking about, this was more of just disabling large
parts (or maybe it was all, I don't remember) of tests with no attempt
at even looking what the problem was.

I should have framed my complaints better. I don't have any issue at all
with workarounds or pragmatism when they're implemented somewhat
carefully and/or reasonably, like the test-skip-handling you describe above.

Best,
Christian

Re: Suggesting change in DPT policy

[Christian Kastner]

On 2024-03-02 23:09, Christian Kastner wrote:
> I think moving DPT to Maintainers is a good idea.

Additionally, I agree that having DPT in Uploaders is pointless, and
welcome the prposed policy change.

> I think removing Uploaders is a terrible one.

Apologies, I retract this part as it was not suggested. I misunderstood
the diff.

Best,
Christian

Re: Suggesting change in DPT policy

[Christian Kastner]

Hi Stefano,

I need to retract my previous mail. Ironically, it was based on a
careless misread of the proposed policy change diff.

On 2024-03-03 00:07, Stefano Rivera wrote:
> Now that we have Salsa with Merge Requests, it's hard for me to see much
> benefit from having packages in the team with the weak team membership
> (uploader).

I fully support removing weak team membership. I have always considered
having DPT in Uploaders to be pointless.

What I misunderstood in the diff was that the proposed policy change of
"anyone can commit" to effectively mean that Uploaders is not relevant
anymore, but that was not what was proposed.

> I don't think any of the things you describe there are acceptable for
> team maintenance.
> 
> Disabling tests or docs may be necessary in the short term. Or if they
> will never be able to work again. But I don't think those are OK to do,
> upload and walk away.
> 
> If the tests are broken and you can't figure it out, you talk to the
> people who know the package better.
> 
> We could spell these things out more clearly in the team rules.
> We can also push back on team members who behave like this. Repeatedly
> doing the things you describe, when asked not to, should lead to being
> kicked out of the team.

I like that suggestion a lot!

And, to be more constructive this time, I want to make it clear that
contributions are always truly welcome, that's why it's under DPT.

And while diligence (or lack thereof) can be criticized, I'm aware that
often, contributors are unaware that what they are doing is wrong. For
example, I also often skip tests -- it's just that I do it under
conditions that I'm happy to defend (cause isolated, reported upstream,
etc.), but others may not be aware of that.

Spelling this out more clearly would improve this.

> Picking up a bug and realising you are in over year head is something
> that will happen to new contributors to Debian. Having a team there to
> help out when someone does make a mess like that is useful.
> 
> A few lines in a README.source about what makes a package complex is
> probably also useful to your collaborators (although, yes, of course
> writing this is work).

I'd like that. But to be effective, it must really be in-grained that
for anything DPT, one should check README.source first.

This may come naturally to many of us, but it's certainly not universal.

>> I see Uploaders as a signal of "these are the regular maintainers, I
>> should check with these people before doing any *major* changes". And I
>> argue that this is reasonable.
> 
> I'd say it's best practice to do that whenever a package has people who
> seem to be caring about it.

Agreed.

> That's not the case for many packages in the team. Even ones listed with
> the team in Uploaders and a human as Maintainer.

Also agreed. But in that case, this inter-personal conflict usually does
not arise, for lack persons.

Best,
Christian

Re: Suggesting change in DPT policy

[Christian Kastner]

Hi again,

On 2024-03-02 23:11, Andreas Tille wrote:
> I'm curious why you believe I didn't care. I likely would have reverted
> my change if I didn't have more urgent matters to attend to.
> Re-uploading a package just to revert the Maintainer and Uploader is
> lower on my priority list than fixing other RC bugs.

To add another perspective: what if reverting is not about "fixing" the
package again, but a courtesy or sign of respect towards the person that
was upset by this action. Wouldn't that change the priority entirely?

> What exactly is the "mess" in this story.  Probably not swapping
> Maintainer+Uploader since I several times confirmed that it is my fault
> and immediately said I'm sorry about this.
>From past interactions, I honestly believe you are. But let me point out
that interaction-wise, saying you're sorry and showing you're sorry are
two different things. And having upset someone, not performing that one
requested gesture that would heal the situation is going to cause friction.

Best,
Christian

Re: Suggesting change in DPT policy

[Christian Kastner]

Hi Andreas,

On 2024-02-27 09:05, Andreas Tille wrote:
> Since I consider the current situation as demotivating for newcomers
> as well as long standing contributors I would like to suggest to drop
> this "weak statement of collaboration" option from policy.  I've attached
> an according patch to the team policy[5].  I'm fine with creating a MR
> to be discussed rather in Salsa than this mailing list - whatever seems
> worthwhile to you.

I think moving DPT to Maintainers is a good idea.

I think removing Uploaders is a terrible one.

Some packages are complex, some packages have lots of reverse
dependencies. Where these two circles overlap, a careless "drive-by"
maintainer can do a lot of harm.

Not going to name names, but I've seen this with packages I've worked
on: I put a lot of effort into cleaning things up, making things robust,
getting docs to build, tests to pass, collaborating with upstream,
fixing reverse dependencies, and then someone spends a few minutes to
upload a new version with total disregard for what the other
maintainer(s) were doing.

Things like "oh, documentation doesn't build anymore, I'll just disable
it", rather than fixing it. Or "oh, these tests don't pass anymore, I'll
just disable them", rather than looking into the regression. "Oh, my
upload triggered a transition, I'm no longer interested in this".

(This are all things that have happened to me.)

All that stuff is then left for others to clean up. And if one is
unlucky enough, this doesn't just cause work for the package, but for
all reverse dependencies.

So while I absolutely condemn the conduct that you describe, I do also
have to condemn this careless drive-by work, because it is also
extremely demotivating.

I see Uploaders as a signal of "these are the regular maintainers, I
should check with these people before doing any *major* changes". And I
argue that this is reasonable.

Best,
Christian

Re: Bug#1064070: RFP: cxxheaderparser -- python library for parsing C++ headers

[Christian Kastner]

Control: tag -1 pending

I've uploaded this to experimental, though with the Debian Python Team
as maintainer. Because although it is a dependency of the ROCm stack, it
seems to be a generally useful Python library.

Best,
Christian

On 2024-02-16 18:57, Cordell Bloor wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-Cc: c...@slerp.xyz, debian...@lists.debian.org
> 
> * Package name: cxxheaderparser
>   Version : 1.3.1
>   Upstream Contact: RobotPy Development Team 
> * URL : https://github.com/robotpy/cxxheaderparser
> * License : BSD-3-Clause
>   Programming Lang: Python
>   Description : Python library for parsing C++ headers
> 
> The cxxheaderparser library is used to parse syntactically valid C++
> code and operate on the results. It provides both a visitor-style
> interface to process the results as they are being parsed or the option
> of a single data structure containing all parsed information.
> 
> This library is a successor to CppHeaderParser, which is a build
> dependency of the AMD ROCm GPU profiling libraries used by PyTorch.
> Specifically, CppHeaderParser is required for roctracer and parts of
> rocm-hipamd. As CppHeaderParser has been deprecated by its authors,
> those libraries will need to be migrated to cxxheaderparser.
> 

Re: New upstream version numpydoc 1.2.1 on salsa?

[Christian Kastner]

Hi Chiara,

On 2022-03-31 00:04, Chiara Marmo wrote:
> Version 1.2.0 is affected by a bug [1] which generates a scikit-learn
> bug in debian [2].
> 
> Version 1.2.1 will fix the debian bug and hopefully moves towards the
> migration of scikit-learn new version in testing.
> 
> Is someone in this list available to merge my MRs, or to update the
> package if my MRs are not acceptable?

As I did the 1.2.0 upload, I went ahead and merged your changes, and
then uploaded.

Thanks for taking care of this!

Best,
Christian

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

[Christian Kastner]

On 12.02.21 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

I think you are reading waaay too much into just this name. The package
will also have a synopsis and a description. There's no reason for our
users to assume or believe anything at all; the facts will be right
there in front of them.

And there's no way past the synopsis with some generic name like
python3-full, or python3-minimal, or python3-dev, etc.

> Also, it's a disservice to push our users into the direction of using
> venv which is very ugly way to use Python in a Debian system, outside of
> just testing something.

How would merely having these packages installed push a user to do
anything with them?

Furthermore, I think "just testing something" is a major use case we
absolutely should support. Personally, it's the first step in my process
for packaging something for Debian, because some things are better kept
out, as I'm sure we've all made the experience.

And finally, let's face it: for the vast amount of users and even
upstreams(!), we wouldn't be pushing them towards venv, they are already
there. pip (and conda) are already the standard tools for getting Python
packages. I don't see how standing in the way of this will win us any
favors. On the contrary, I do see how this casts a unfavorable light on us.

Best,
Christian

PS: To be clear, personally, I vastly prefer Debian-packaged Python
software, and will package anything I use if it is not yet in the
archive, provided its quality is sufficiently high and there is
continued upstream support.

Re: Generic Python packages which don’t work on all architectures

[Christian Kastner]

On 21.01.21 02:44, Paul Wise wrote:
> I am now thinking that a more generic solution than Architecture:
> linux-all is needed, in order to cover your case as well. Perhaps
> something like Available-Architecures or Runtime-Architectures or
> Architecture-all-Architectures: or similar.

To be honest, that sounds like a lot of complicated extra infrastructure
work compared to just making the package architecture-dependent.

Yes, it will save a few builds, but it's not like these particular
builds consume a lot of resources.

Best,
Christian

Bug#977651: ITP: sphinx-prompt -- Sphinx directive to add unselectable prompt

[Christian Kastner]

Package: wnpp
Severity: wishlist
Owner: Christian Kastner 

* Package name: sphinx-prompt
  Version : 1.3.0
  Upstream Author : Stéphane Brunner
* URL : https://github.com/sbrunner/sphinx-prompt
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Sphinx directive to add unselectable prompt

Sphinx prompt adds a new directive for documentating steps in
interactive prompts. Currently, Bash, Python, and Scala syntax are
supported.

This is a dependency of scikit-learn 0.24. It will be maintained under the
umbrella of the Debian Python Team.

Re: Packaging a python module when already using cmake buildsystem

[Christian Kastner]

On 2020-09-24 13:22, Francis Murtagh wrote:
> I'm trying to package a newly added python component of our
> tool https://tracker.debian.org/pkg/armnn.
> 
> It has a setup.py and uses SetupTools and DistUtils so I was hoping to
> add --with Python3 and hope that a lot of magic would be done by pybuild.
> However as I'm already using cmake as the build system I can't stick
> pybuild in there.

You can pass --buildsystem to individual targets, so something like this
might work (haven't tried it though):

override_dh_auto_build:
dh_auto_build --buildsystem=cmake
dh_auto_build --buildsystem=pybuild

If that particular example doesn't work, I'm sure that a closely related
one should (I've seen it before, but unfortunately don't recall where).

I did a quick search on codesearch.debian.net and here's one example of
a d/rules using two separate build systems:


https://sources.debian.org/src/python-tenacity/6.2.0-4/debian/rules/?hl=16#L16

Best,
Christian

Re: Merging the PAPT and the DMPT

[Christian Kastner]

On 2020-09-21 10:45, Ondrej Novy wrote:
> út 15. 9. 2020 v 0:12 odesílatel Christian Kastner  Has getting rid of the subgroups entirely been considered, IOW: moving
> the packages directory to python-team/?
> 
> reason is ACL. We need different access for "tools" and for "packages".  

That makes sense, thank you for the clarification!

Second draft of the announcement looks good to me.

Re: Merging the PAPT and the DMPT

[Christian Kastner]

On 2020-09-14 09:59, Ondrej Novy wrote:
>   * transferring all project from modules+applications to packages subgroup

Has getting rid of the subgroups entirely been considered, IOW: moving
the packages directory to python-team/?

The only remaining subgroup seems to be "tooling", and that could live
on as a subgroup unless I'm misunderstanding GitLab.

Re: [DRAFT] DPMT and PAPT is DPT now

[Christian Kastner]

Hi Ondřej,

On 2020-09-14 10:39, Ondrej Novy wrote:
> for simplification we merged two subteams - Debian Python Modules Team
> and Python Applications Packaging Team into just one: Debian Python
> Team, DPT.
> 
> All Salsa repositories are in "packages" subgroup [1] now.
> 
> We have only one team policy [2] now.
> 
> And as always, new contributors are welcomed :)
> 
> [1] https://salsa.debian.org/python-team/packages
> [2] 
> https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst

I'm prone to be much too verbose, but seeing as -devel-announce has an
audience that might lack context and details that are well-known to
-python, I'd like to suggest the following amended version just in case:


PAPT and DPMT become DPT


Historically, the Debian Python ecosystem was maintained by two separate
teams: the Debian Python Applications Packaging Team (PAPT) for
applications, and the Debian Python Modules Team (DPMT) for modules used
by applications.

As there was substantial overlap between the members of these teams, their
work,  and their tooling, these teams have been merged into one: the
Debian Python Team (DPT).

[Or whatever the actual history and motivations were; as I said in an
earlier mail, it was never quite clear to me why two teams were needed
in the first place]


Changes
---

This merge mainly affects package maintainers. End users should not see
a change beyond the Maintainer field of packages.

For maintainers, the following has changed:
  * The respective PAPT and DPMT policies are superseded by the new,
more compact DPT policy [1]. Please take a few minutes to familiarize
yourself with this new policy.
  * All Salsa repositories are in "packages" subgroup [2] now. Please
set Vcs-* fields of new packages accordingly.
  * The Maintainer field of new packages should now be set to
"Debian Python Team ".


Migration
-

On Salsa, redirects have been implemented from the old "applications"
and "modules" subgroups to the new "packages" subgroup. Vcs-* URLs
should continue working for now.

[... and the other migration steps are still being planned, right?]


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

Re: Merging the PAPT and the DMPT

[Christian Kastner]

On 2020-09-07 13:38, Ondrej Novy wrote:
> ~10 days without reply, merged.

I'm really happy about this :-) I've always found the split odd.

By the way, this might be something worth sending to
debian-devel-announce, possibly including a short summary/description of
how this affects contributors (what changes need to be made, etc.)

Bug#969766: ITP: python-multipledispatch -- multiple dispatch in Python

[Christian Kastner]

Package: wnpp
Severity: wishlist
Owner: Christian Kastner 

* Package name: python-multipledispatch
  Version : 0.6.0
  Upstream Author : Matthew Rocklin
* URL : https://github.com/mrocklin/multipledispatch/
* License : BSD-3-clause
  Programming Lang: Python
  Description : multiple dispatch in Python

This implementation of multiple dispatch is efficient, mostly complete,
performs static analysis to avoid conflicts, and provides optional namespace
support. It looks good too.

What this does:
 * Dispatches on all non-keyword arguments
 * Supports inheritance
 * Supports instance methods
 * Supports union types, e.g. (int, float)
 * Supports builtin abstract classes, e.g. Iterator, Number, ...
 * Caches for fast repeated lookup
 * Identifies possible ambiguities at function definition time
 * Provides hints to resolve ambiguities when they occur
 * Supports namespaces with optional keyword arguments
 * Supports variadic dispatch

What this doesn't do:
 * Diagonal dispatch
 * Efficient update: The addition of a new signature requires a full resolve
   of the whole function. This becomes troublesome after you get to a few
   hundred type signatures.

This will be maintained within the Debian Python Team.

Bug#968152: ITP: python-iniconfig -- brain-dead simple parsing of ini files

[Christian Kastner]

Package: wnpp
Severity: wishlist
Owner: Christian Kastner 

* Package name: python-iniconfig
  Version : 1.0.1
  Upstream Author : Ronny Pfannschmidt
* URL : https://github.com/RonnyPfannschmidt/iniconfig
* License : MIT
  Programming Lang: Python
  Description : brain-dead simple parsing of ini files

iniconfig is a small and simple INI-file parser module having a unique set of
features:

  * tested against Python2.4 across to Python3.2, Jython, PyPy
  * maintains order of sections and entries
  * supports multi-line values with or without line-continuations
  * supports "#" comments everywhere
  * raises errors with proper line-numbers
  * no bells and whistles like automatic substitutions
  * iniconfig raises an Error if two sections have the same name.

This is a dependency of a newer pytest version and will be maintained under the
umbrella of the Debian Python Modules Team.

Bug#968151: ITP: python-xmlschema -- implementation of XML Schema for Python

[Christian Kastner]

Package: wnpp
Severity: wishlist
Owner: Christian Kastner 

* Package name: python-xmlschema
  Version : 1.2.2
  Upstream Author : SISSA (Scuola Internazionale Superiore di Studi Avanzati)
* URL : https://github.com/sissaschool/xmlschema/
* License : MIT
  Programming Lang: Python
  Description : implementation of XML Schema for Python

This library includes the following features:

  * Full XSD 1.0 and XSD 1.1 support
  * Building of XML schema objects from XSD files
  * Validation of XML instances against XSD schemas
  * Decoding of XML data into Python data and to JSON
  * Encoding of Python data and JSON to XML
  * Data decoding and encoding ruled by converter classes
  * An XPath based API for finding schema's elements and attributes
  * Support of XSD validation modes strict/lax/skip
  * Remote attacks protection by default using an XMLParser that forbids
entities

This is a dependency of a newer pytest version and will be maintained under the
umbrella of the Debian Python Modules Team.

Re: Issues running pytest from within .pybuild

[Christian Kastner]

On 2020-05-18 01:30, Scott Kitterman wrote:
> On Sunday, May 17, 2020 6:26:11 PM EDT Christian Kastner wrote:
>> From the GitHub issue, it seems as if the current practice of testing
>> from within .pybuild is not supported by pytest, but I'm inclined to
>> believe that it is my approach that is flawed.
>>
>> [1] https://github.com/pytest-dev/pytest/issues/7223
> 
> I think this would only happen if sys.path had been extended to include the 
> main source directory.  You may need to cd to $SRCDIR/.pybuild/.../sklearn 
> before calling pytest or something may be inserting the source directory into 
> sys.path.

All of this is being delegated to pybuild, by calling it with the
--test-pytest option. It takes care of cd'ing to the build dir before
calling pytest. The only customization is using --pytest-args to pass
some additional options to exclude some tests.

Hence why I'm puzzled to see this.

Manually cd'ing into the directory and running pytest (to test whether
pybuild is doing something funny) doesn't help.

It really looks as if this is a pytest issue, but on the GitHub issue
linked above, the assessment was "It's a little weird to discover tests
from an ephemeral build dir". Seeing as doing this is the standard
practice for pybuild, I thought it best to check back here.

Christian

Issues running pytest from within .pybuild

[Christian Kastner]

In a recent version of src:scikit-learn, a workaround was added to
resolve an ImportMismatchError regarding one of the conftest.py files
used by pytest.

I hit a new instance of this while preparing a new upstream release, so
I inquired [1] with pytest upstream as to why this could be happening.

Apparently, the error is caused by the .pybuild directory being located
as a subfolder of the source directory. This leads to pytest finding two
separate sklearn/conftest.py files
  * $SRCDIR/sklearn/conftest.py
  * $SRCDIR/.pybuild/.../sklearn/conftest.py)
which triggers the ImportMisMatchError.

Now, I've only seen this happen with src:scikit-learn, and (oddly
enough) only with 2 of 4 conftest.py files. The other two do not trigger
the error, nor do other packages of mine which use pytest.

Has anyone seen something similar with their packages, or is anyone
aware of any recipes that can be used to resolve the issue properly?

>From the GitHub issue, it seems as if the current practice of testing
from within .pybuild is not supported by pytest, but I'm inclined to
believe that it is my approach that is flawed.

[1] https://github.com/pytest-dev/pytest/issues/7223

Christian

Re: Python3.8 Transition Lessons Learned

[Christian Kastner]

Hi Scott,

On 2020-04-14 16:22, Scott Kitterman wrote:
> These binNMUs migrated to Testing immediately.  This resulted in a case where 
> in Testing, python3.7 and python3.8 were supported versions, but packages had 
> lost their python3.7 support.  This caused autopkgtest failures which 
> appeared 
> as regressions.

thank you for the update, and this fragment in general. I saw these
failures, and was somewhat puzzled. This clarifies the issue.

Re: New packages: -doc package with python or python3 prefix?

[Christian Kastner]

On 28.03.20 12:22, Simon McVittie wrote:
> On Sat, 28 Mar 2020 at 11:44:35 +0100, ghisv...@gmail.com wrote:
>> I believe it should remain python- (as the programming language),
>> instead of python3- (the major version targeted).
> 
> In cases where the documentation is large enough to justify a separate
> binary package, this matches my understanding of the policy. If/when there
> is eventually a Python 4, I think we would want the module that is used
> via "import tpot" to ship python3-tpot, python4-tpot and python-tpot-doc
> binary packages; it would seem odd for the documentation for python4-tpot
> to be in python3-tpot-doc.
Indeed, I can see that now.

> Unfortunately https://www.debian.org/doc/packaging-manuals/python-policy/
> doesn't say anything either way on this. I think it should, and I'll open
> a bug with a reference to the proposed patch in
> .

Thanks!

New packages: -doc package with python or python3 prefix?

[Christian Kastner]

The Python 2 removal page [1] states that existing python-$foo-doc
packages should not be renamed to python3-$foo-doc.

But what about new packages? I have a package in NEW that provides
python3-tpot, but should the doc package have a python- or python-3 prefix?

[1] https://wiki.debian.org/Python/2Removal

Re: dh_python3 sets shebang to Python 2 -- is this a bug?

[Christian Kastner]

Hi Andreas!

On 20.01.20 17:40, Andreas Henriksson wrote:
> On Mon, Jan 20, 2020 at 08:51:56AM +0100, Christian Kastner wrote:
> I've personally seen some upstream use 'python' in shebang with the
> intention of meaning 'works with either python2 or python3', but in
> debian it seems people have always assumed unversioned
> (/usr/bin/)python always means python *2*.
> I guess the tools are written in the latter sense here, rewriting the
> shebang from python -> python2 explicitly unless you override it

That's the plausible explanation... it just felt odd to see this is an
pure Python 3 package.

> You should note that if you know the code is actually python-version
> agnostic you should be able to fix this by setting the shebang
> explicitly by using:
> https://sources.debian.org/src/dh-python/4.20191017/dh_python3/#L122
> 
> eg. in debian/rules use: export DH_OPTIONS=--shebang=/usr/bin/python3 

That worked, thanks!

>> Furthermore, the package does not list any Python 2 build dependencies,
>> and all binary package dependencies are generated by the
>> ${python3:Depends} substvar. Could this perhaps be worth an "if the
>> package does not have Python 2 dependencies, a Python 2 shebang is a
>> bug" lintian check?
> 
> Having some safety-net in place here would likely be a good idea because
> I understand how this could easily be missed otherwise.

Let's see if anyone else has something contradictory to add... else,
I'll file the wishlist bug.

Christian

dh_python3 sets shebang to Python 2 -- is this a bug?

[Christian Kastner]

I have an issue with a package build, and I'm not sure whether this is a
bug in dh-python, or whether I'm just misunderstanding something.


A package that had recently been converted from Python 2 to Python3 was
still generating dependencies for Python 2, see #936924.

Frederic-Emmanuel Picca correctly pointed me to the source of this
issue, it was an unversioned shebang in some scripts installed into
/usr/bin.

Here's the thing that puzzles me: dh_python3 identifies the unversioned
shebang,

  | I: dh_python3 tools:114: replacing shebang in 
debian/libsvm-tools/usr/bin/svm-grid
  | I: dh_python3 tools:114: replacing shebang in 
debian/libsvm-tools/usr/bin/svm-subset
  | I: dh_python3 tools:114: replacing shebang in 
debian/libsvm-tools/usr/bin/svm-checkdata
  | I: dh_python3 tools:114: replacing shebang in 
debian/libsvm-tools/usr/bin/svm-easy

but it replaces the shebang with the Python *2* versioned one.

A Python 3 helper setting /usr/bin/python2 looks odd to me, but I have
no in-depth knowledge of dh-python's design, or the corner cases it
might need to address.

Is there a use case where dh_python3 (not dh_python2) doing this can
make sense? Or can this be considered a bug?

Furthermore, the package does not list any Python 2 build dependencies,
and all binary package dependencies are generated by the
${python3:Depends} substvar. Could this perhaps be worth an "if the
package does not have Python 2 dependencies, a Python 2 shebang is a
bug" lintian check?


Christian

Bug#944261: ITB: python-seaborn -- Python data visualization library

[Christian Kastner]

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

* Package name: python-seaborn
  Version : 0.9.0
  Upstream Author : Michael Waskom 
* URL : https://seaborn.pydata.org
* License : BSD-3-clause
  Programming Lang: Python3
  Description : Python data visualization library

Seaborn is a Python data visualization library based on matplotlib. It
provides a high-level interface for drawing attractive and informative
statistical graphics.

This will be maintained within the Debian Science Team.

Re: Python2 removal: package with low-popcon reverse dependencies

[Christian Kastner]

On 11.10.19 19:47, Matthias Klose wrote:
> On 11.10.19 18:27, Christian Kastner wrote:
>> This would nevertheless be a case for the "py2keep", right?
> 
> No.
> 
> #933348 is another bug for removed packages (mopidy-scrobler). Do you
> really want to keep that? 

Not at all, I'd actually prefer just dropping the Python2 version of
python-cachetools. However, this breaks things, and it wasn't entirely
clear to me much breakage is acceptable.

> Is the mopidy popcon really enough to keep it?  Don't look at the
> popcon of any python module. The relevant popocon is the one for the
> application.

OK.

> No, this is not yet done. Pending a dh-python upload.

So assuming I had a Python2 module that needed updating (instead of
outright removing it), I'd await this upload.

Thanks,
Christian

Python2 removal: package with low-popcon reverse dependencies

[Christian Kastner]

Hi,

python-cachetools provides modules for Python2 and Python3.

The Python2 module as two reverse dependencies, both with low installed
popcon:
python-cachetools:  302
mopidy-podcast: 109
mopidy-internetarchive:  95

This would nevertheless be a case for the "py2keep", right?

Would this also be the case if python-cachetools itself had a lower
popcon, say 50? Or is any form of dependency a case for "py2keep"?

Furthermore, the instructions in the Python2 removal request #937627 say:
> Also any dependencies on an unversioned python package (python,
> python-dev) must not be used, same with the python shebang.  These
> have to be replaced by python2/python2.7 dependencies and shebang.

The binary package has versioned dependencies generating during the
build process, so there is nothing else to do, right?

Christian

Please remove pyrit from PAPT Salsa

[Christian Kastner]

Hi,

pyrit has been handed over to pkg-security, where it will be better
taken care of, and the main repository is now pkg-security-team/pyrit.

Could one of the owners of PAPT on Salsa please remove the repository
python-team/applications/pyrit?

Regards,
Christian

Re: Graph-tool in Debian

[Christian Kastner]

Hi Tiago,

On 2015-01-20 11:49, Tiago de Paula Peixoto wrote:
> I already provide Debian packages:
> 
> https://graph-tool.skewed.de/download#debian
> 
> But I would like to probe your interest into getting this into Debian
> proper.
> 
> I would be willing to maintain the package, but I would need some
> sponsorship, as well as some initial pointers on best practices and so
> on.

As you already have some experience with Debian packaging, you'll
probably want to start here:

http://mentors.debian.net/

There are two Python teams within Debian: one for applications (PAPT),
and one for modules (PMPT). Here is the wiki page for the PAPT:

https://wiki.debian.org/Teams/PythonAppsPackagingTeam

Among the links listed there, the policy is an important read:

http://python-apps.alioth.debian.org/policy.html

Finally, it's best to join the #debian-python and #debian-mentors IRC
channels on OFTC, where people are usually quite helpful.

Regards,
Christian


-- 
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/54be4f47.2040...@kvr.at

Re: Proposed git migration plan

[Christian Kastner]

On 2014-08-27 01:41, Antoine Musso wrote:
> Le 27/08/2014 10:13, Sandro Tosi a écrit :
> 
>> Offline commits? how many time (for real..) you badly needed it? i
>> guess so  few that if you (for one time) just do a big commit instead
>> of a storm of micro commit the world wont stop
>
> As a side effect, that also mean you don't have to use a potentially
> lagged network connection when doing simple operations.  There is
> nothing I hate more than waiting for network when using the commands
> log, commit or blame.

This annoys me to no end as well.

>> is there anything else so "attractive" about git?
> 
> Cheap local branches which let you pill up work in progress patches /
> rewrite without having to keep several copy of the same svn repo.  The
> branches in git are just a name pointing to a commit in the tree.

I would really like to emphasize this one. The ability to work locally,
then rewrite that work, and only *then* publish it is invaluable to me.

When implementing a feature, I don't need to share the history of all
mistakes I made with the world, because to everyone else but me, those
are just noise polluting the history and unnecessarily complicating it.

Instead, I implement the feature locally, and when it works as intended,
I rewrite the entire history so that it is clean and comprehended, and
only *then* do I push.

> The stash, which let you save your uncommited changes and come back to
> them later (think of it as lightweight branches).  That is really nice
> when you have to interrupt your workflow, stash it, handle the
> interrupt, reapply your stash and resume work.
> 
> Tags can be signed with gpg. They are a pointer to a commit just like
> branches, and hence don't force you to do a full copy to create a tag.
> 
> Switching between branches is a breeze and does not need network access
> either.
> 
>> If we don't define *upfront* what are the problems we currently have
>> and that we want to solve, then we're just proposing a technical
>> exercise without a real gain. and I cant stress this point never
>> enough.
> 
> I agree there, would be nice to list the problems with svn.  But I guess
> most of them are related to svn being a bad (and slow) CSV system.


-- 
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/53fdfb50.3000...@kvr.at

Re: Proposed git migration plan

[Christian Kastner]

On 2014-08-26 20:04, Stuart Prescott wrote:
>>> I eventually gave up and used git-import-dscs -- debsnap.
>>>
>>> That said -- all the above experience was with full-source svn repos. I
>>> would anticipate that the debian/-only repos would be easier to migrate as
>>> they are much simpler, but then the new git repo would also be
>>> debian/-only.
>>
>> I just tried this one of of my simple packages (cov-core, a fairly new
>> package
>> with only two upstream releases in Debian).  In svn it's a debian/-only
>> package but after the g-i-d the git repo ended up full source (yay!). 
>> Then I
>> did a `git-import-orig --uscan` and it seemed to work just fine.  
> 
> sure -- git-import-dscs will make full source repos for you, but it is not 
> converting svn repos to git repos which is what I was really talking about 
> there... it's throwing away the svn repo and making a new git repo with some 
> sparse, condensed history in it. If the real history needs to be preserved, 
> then a helper like svn-all-fast-export, git-svn or similar is needed and 
> that won't on its own make full source repos.

If the goal is source-ful branches (which I'm hoping), there's a
tradeoff to consider here:

(a) either have that sparse, condensed history, but that would also be a
history from which past packages can be recreated, as for each tag,
there would be the debian source and the upstream source, or

(b) have the full history as produced eg by git-svn, but without the
connection to the upstream source. After all, the svn repos were kept
sourceless.


-- 
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/53fd5c65.4080...@kvr.at

Re: dh_auto_* and Makefile

[Christian Kastner]

On 2014-05-02 02:48, Brian May wrote:
> In a particular project (django-model-utils 2.0.3 to be precise), if I
> have a debian/rules file containing:
> 
> 
> %:
> dh $@ --with python2
> 
> Then dh_auto_* tools determine that the project comes with a Makefile
> (upstream file), and uses that instead of setup.py
> 
> How can I force it to use setup.py?

%:
 dh $@ --with python2 --buildsystem=python_distutils

See also section BUILD SYSTEM OPTIONS of debhelper(7).

> I have tried providing override_dh_auto_*, but then I hard coded the
> python version to use.
> 
> Or should I create a patch in debian/patches that removes the Makefile?
> This seems to be the simplest solution, but want to make sure it sounds
> reasonable.
> 
> Thanks
> -- 
> Brian May  >


-- 
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/5362f173.6080...@kvr.at

Re: Package for multiple Python versions

[Christian Kastner]

On 09/10/2011 11:18 PM, Mitar wrote:
> Hi!
> 
> On Sat, Sep 10, 2011 at 10:59 PM, Christian Kastner  wrote:
>> The reason for this is that your build environment affects the resulting
>> binary package in various ways, one of them being the generated
>> dependencies, which is why you are seeing strange things below.
> 
> Sure. But then I cannot have one package to cover them all? Like one
> .deb file people could install everywhere and things would work? So
> with dependencies on major versions.

It depends. With simple packages with only minimal dependencies this
should not be a problem. The more complex your package gets, however,
the harder it becomes. For example, it may depend on the presence of
specific versions of helpers.

> I made some tests and it seems it should be enough to have Python 2.6
> as lower bound, not necessary so precise as dh_python2 helper makes
> it.

I'd expect this to be an example for the above. If dh_python2 generated
a dependency, I'd assume it is minimal and would consider mucking about
with it a Bad Move.

(Someone else, please correct me if I'm wrong.)

> I now made an ugly hack to fix this. ;-) Before dh_gencontrol I run:
> 
> # We make dependencies less strict
> perl -i -p -e 's/(, )?python \(>= ([^.\)]+\.[^.)]+)\.[^)]+\)/$1python
> (>= $2)/g' $(CURDIR)/debian/$@.substvars
> 
> # Require at least one version of libpython, not all of them; we move
> all of them to Recommends
> perl -n -e 'if (/^shlibs:Depends=.*?(libpython[^,]+(?:,
> libpython[^,]+)*)/) { print "shlibs:Recommends=$1\n" }'
> $(CURDIR)/debian/$@.substvars >> $(CURDIR)/debian/$@.substvars
> perl -i -p -e '1 while s/^(shlibs:Depends=.*?)(libpython[^,]+),
> (libpython[^,]+)/$1$2 | $3/g' $(CURDIR)/debian/$@.substvars


-- 
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/4e6ca3fd.2000...@kvr.at

Re: Package for multiple Python versions

[Christian Kastner]

On 09/10/2011 05:04 PM, Mitar wrote:
> What I have done is installed Python 2.7 from wheezy so that package
> would be build for Python in stable (2.6) and for 2.7 (unstable,
> Ubuntu).

Unfortunately, that is not how building for multiple distributions works.

You need to have a separate build environment for each distribution. You
then build binary packages for each distribution from your one source
package, which you normally develop using the "unstable" distribution.
The reason for this is that your build environment affects the resulting
binary package in various ways, one of them being the generated
dependencies, which is why you are seeing strange things below.

I wanted to give the build a brief look but your package FTBFS in
unstable due to a missing OpenGL-related build dependency, could you check?

Regards,
Christian


> But now I get strange dependencies which prevent installation on stable:
> 
> The following packages have unmet dependencies:
>  python-orange : Depends: libpython2.7 (>= 2.7) but it is not installable
>  Depends: python (>= 2.6.6-7~) but 2.6.6-3+squeeze6 is
> to be installed
> 
> Where did it got  2.6.6-7~ version for Python? Is there a way to force
> it to 2.6 (so not precise dependency)?
> 
> And why it depends on both libpython2.6 and libpython2.7. It should
> depend on the one for which you have Python installed.
> 
> Packages are here:
> 
> http://orange.biolab.si/debian/
> 
> (I have not yet fixed all other suggestions you have send me.)
> 
> Thanks for all the help.
> 
> 
> Mitar
> 
> 


-- 
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/4e6bcfcf.6050...@kvr.at

Re: Package for multiple Python versions

[Christian Kastner]

On 07/22/2011 09:57 AM, Mitar wrote:
> I now saw that my Orange package is build just for Python 2.6.
> 
> http://orange.biolab.si/debian/dists/squeeze/main/source/
> 
> How can I make it be build also for 2.7?

  1. Get a list of requested Python versions with pyversions(1)
  2. Perform build with each of the requested Python versions

Ad 1: You're using pyversions already, but only to get the default
Python version. Use -vr instead of -vd to get a list of requested Python
versions.

Ad 2: I'm not entirely clear on the structure of your program or how the
build process works -- there's a setup.py, but in debian/rules you
build/install manually -- but something like this should work:

debian/rules

build:
# Get the supported Python versions
PYVERS = $(shell pyversions -r -v)

set -e -x;\
for py in $(PYVERS); do \
PYTHON=python$$py make -C source;
done

source/*/Makefile:
=
Substitute python with $(PYTHON) where appropriate


Again, I didn't look into your build process in detail, so adjust the
above to your needs. For example, the above really performs the entire
build process twice. If Python is involved in only a subset of the
steps, it would be better to iterate there instead.


Christian


-- 
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/4e29ef0a.7020...@kvr.at

Re: Help with my Debian package for Orange

[Christian Kastner]

On 07/01/2011 05:21 AM, Barry Warsaw wrote:
> On Jul 01, 2011, at 01:00 AM, Mitar wrote:
> 
>> I will not yet use "dh" as it looks too magical for me for now. I
>> would like to understand what is happening. And first have a working
>> package. Then I can play with cleaning it up. Or would it be easier to
>> just let dh do everything? I doubt it can be magical enough.
> 
> Personally, I find dh preferable, even with the magical aspects.  You can
> always set DH_VERBOSE=1 to get decent output about exactly what it's doing.  I
> think dh and dh_python2 make a great way to very easily package up most Python
> libraries.  I have some recommendations to add for extnsion modules coming
> soon to the dh_python2 transition wiki page.

It's definitely preferable for an experienced packager, it can be
confusing as hell though to the commencing packager because in order to
understand dh syntax, you must first understand what debian/rules does,
ie the actual process of building a package from source.

Additionally, stuff like "dh_installmanpages" (regular or dh syntax) is
completely obvious to us, but the commencing packager
  * must first understand what that command tries to accomplish
  * must understand how it accomplishes it
  * must understand when it accomplishes it (at what stage)
  * must realize that even though it is a quasi-standard, it it "just"
a helper, and there are other ways to accomplish the same thing
  * etc

At least, that's the way I saw it when I started packaging about a year
ago, and getting familiar was a time-consuming process.

I'd recommend getting started with either the New Maintainainer's
Guide[0] or the Packaging Tutorial Yarik posted, and probably with a
simpler package. Once the basics are solid, stuff like dh (and other
helpers) become natural.

Christian

[0] http://www.debian.org/doc/manuals/maint-guide/


-- 
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/4e0dca4c.1000...@kvr.at

Re: Help with my Debian package for Orange

[Christian Kastner]

On 06/29/2011 06:58 PM, Mitar wrote:
> I have made a Debian package for Orange:
> 
> http://orange.biolab.si/
> 
> The idea is that we have a daily snapshot packaged as Debian package.
> 
> You can get it here (also source package):
> 
> http://orange.biolab.si/debian/

FYI, a separate packaging was already attempted sometime in the past.
You can find the SVN repository for the packaging here:

http://anonscm.debian.org/viewvc/collab-maint/deb-maint/orange-data-mining/

I don't know how current this is, but there might be some helpful stuff
in there. Either way, if you indeed will start to provide packaging
upstream, then the above repo should probably be removed to avoide
confusion.



-- 
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/4e0dcb3d.1000...@kvr.at

Re: Where to put debugging extension

[Christian Kastner]

On 06/15/2011 09:47 PM, Nikolaus Rath wrote:
> Should I put the extension build for the debug interpreter into the
> normal python-xx package, or into the python-xx-dbg package that also
> contains the debugging symbols?
> 
> The first variant seems to be more common, but I'm having trouble to
> come up with a good pattern for debian/xx.install to exclude the
> extension build for the debugging intepreter (and, vice versa, for
> including it in debian/xx-dbg.install).

This may be helpful:

http://wiki.debian.org/Python/DbgBuilds#Install


Christian



signature.asc
Description: OpenPGP digital signature

Re: dh_strip and Python Extensions

[Christian Kastner]

Hi,

On 05/26/2011 02:32 AM, Nikolaus Rath wrote:
> I'm not quite sure when this started, but dh_strip is placing my Python
> .so extensions into /usr/lib/debug/..., which makes Lintian complain:
> [...]
> 
> $ lintian ../python-llfuse-dbg_0.31-1_amd64.deb
> W: python-llfuse-dbg: python-debug-in-wrong-location 
> usr/lib/debug/usr/lib/pyshared/python2.6/llfuse.so 
> /usr/lib/debug/usr/lib/pymodules/python2.6/llfuse.so
> W: python-llfuse-dbg: python-debug-in-wrong-location 
> usr/lib/debug/usr/lib/pyshared/python2.6/llfuse_d.so 
> /usr/lib/debug/usr/lib/pymodules/python2.6/llfuse_d.so

The first path is where dh_strip has installed the files. The second
path, however, is where they are expected. See [0] for a fix, and [1]
for a rationale.

HTH,
Christian

[0] http://wiki.debian.org/Python/DbgBuilds#line-165
[1] http://bugs.debian.org/576014



signature.asc
Description: OpenPGP digital signature

Re: python sample packages?

[Christian Kastner]

On 11/08/2010 09:53 PM, Paul Elliott wrote:
> Sorry if this is a faq, but are there any hellow world
> debian sample packages that could be used as a starting point?

I'm not aware of any. [0], however, appears to provide the relevant code
sections for packaging modules

[0]https://wiki.ubuntu.com/PackagingGuide/Python#The%20debhelper%20way

Having recently looked at packaging a Java library for the first time, I
found the sample packages[1] provided by the Java team immensely helpful
in getting started:

[1] http://pkg-java.alioth.debian.org/examples/

It would be nice if we could provide a similar service for Python, too.
I added it to my own TODO list, but I fear that I won't get around to it
anytime soon...

Christian



signature.asc
Description: OpenPGP digital signature

Re: Package relationships for python debug packages

[Christian Kastner]

On Tue, 19 Oct 2010 13:23:35 +1100, Ben Finney

wrote:
> Howdy all,
> 
> What relationship should be declared between a binary ‘python-foo-dbg’
> package and the ‘python-dbg’ package?
> 
> I can't remember the rationale, but the consensus was not what I
> expected. Should the binary package ‘Depends: python-dbg’, or should it
> instead ‘Recommends: python-dbg’? What's the rationale?

In http://wiki.debian.org/Python/DbgBuilds, we argued for ‘Recommends:
python-dbg’ if the package can be used without the debug interpreter (eg:
it contains the stripped debugging symbols for use with gdb); otherwise,
‘Depends: python-dbg’.


Christian


-- 
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/a307b6fa2010da4b1ee8befdef834...@kvr.at

Building Python debug extensions with dh

[Christian Kastner]

A mentor recently proposed that I ship -dbg versions of a Python
extension. Researching on how to properly do so, it appeared that there
was no standard approach to this. On the contrary, I found numerous
differing implementations, with quite a few exhibiting some flaws.

I chose to follow the approach taken in python-djvu. With extensive help
by Jakub Wilk, I polished my internal documentation and posted it to:
http://wiki.debian.org/Python/DbgBuilds


Some noteworthy issues we encountered:

* Relationships between regular extension, debug extension and debug
interpreter should be reevaluated. Currently, -dbg uses Recommends: for
the debug interpreter and any required extensions (rationale in wiki)

* It would be great if #589759 would see some additional feedback so the
issue can properly be resolved

* It appears that more packages have gotten the issue in #576014 wrong
that right.

Feedback welcome!

Christian


-- 
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/4c61684b.9020...@kvr.at

RFS: pyevolve

[Christian Kastner]

Hello,

I am looking for a sponsor for my package "pyevolve".

* Package name: pyevolve
  Version : 0.6~rc1~svn397+dfsg-1
  Upstream Author : Christian S. Perone 
* URL : http://pyevolve.sourceforge.net
* License : Python License (with upstream subsituted for PSF)
  Section : python

It builds these binary packages:
python-pyevolve - Complete genetic algorithm framework written in pure
python
python-pyevolve-doc - Documentation for the Pyevolve genetic algorithm
framework

The package appears to be lintian clean.

The upload would fix these bugs: 580924


Pyevolve is one of the most complete genetic algorithm frameworks
currently available. It is trivially easy to use out-of-the-box and yet
easily extendable. It also provides extensive documentation.

For a good overview of Pyevolve's feautres and capabilities, see ACM
SIGEVOlution Volume 4 Issue 1, available at http://www.sigevolution.org.

Upstream is very responsive.


The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/p/pyevolve
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/p/pyevolve/pyevolve_0.6~rc1~svn397+dfsg-1.dsc

I would be glad if someone uploaded this package for me.


Thanks,
Christian



signature.asc
Description: OpenPGP digital signature

Re: RFS: pyrit

[Christian Kastner]

On 05/20/2010 03:58 PM, Paul Wise wrote:
> On Thu, May 20, 2010 at 9:24 PM, Christian Kastner  wrote:
> 
>> Pyrit is an excellent example of a GPGPU-driven application. It consists
>> of a main program and optional extensions for various GPGPU
>> technologies, such as NVIDIA CUDA and OpenCL.
> 
> Do we have OpenCL support in Debian main?

Not yet, but it's being worked on. I've been in contact with the NVIDIA
Team, they expect the NVIDIA toolkit (with CUDA and OpenCL support) to
be available RSN, see #581184.

I don't anticipate an OpenCL extension for pyrit, though. That would
require binary packages for each specific vendor implementation (eg
pyrit-opencl-nvidia). You might as well just use pyrit-cuda.


-- 
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/4bf547e6.8000...@kvr.at

RFS: pyrit

[Christian Kastner]

Dear mentors,

I am looking for a sponsor for my package "pyrit".

* Package name: pyrit
  Version : 0.3.0-1
  Upstream Author : Lukas Lueg 
* URL : http://code.google.com/p/pyrit/
* License : GPLv3 + OpenSSL linking exception
  Section : net

It builds these binary packages:
pyrit  - A GPGPU-driven WPA/WPA2-PSK key cracker

The package appears to be lintian clean.

The upload would fix these bugs: 570918


Pyrit is an excellent example of a GPGPU-driven application. It consists
of a main program and optional extensions for various GPGPU
technologies, such as NVIDIA CUDA and OpenCL.

This package provides the main program. It is fully functional version
of Pyrit, but lacks support for non-free technologies such as CUDA.
These technologies will be supported via separately distributed python
extensions (see ITP #582315) in contrib.

Upstream is very responsive.


The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/p/pyrit
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/p/pyrit/pyrit_0.3.0-1.dsc

I would be glad if someone uploaded this package for me.


Regards,
Christian



signature.asc
Description: OpenPGP digital signature