Dear mentors,
I am looking for a sponsor for my package pyrit.
* Package name: pyrit
Version : 0.3.0-1
Upstream Author : Lukas Lueg lukas.l...@gmail.com
* URL : http://code.google.com/p/pyrit/
* License : GPLv3 + OpenSSL linking exception
Section :
On 05/20/2010 03:58 PM, Paul Wise wrote:
On Thu, May 20, 2010 at 9:24 PM, Christian Kastner deb...@kvr.at 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
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
On Tue, 19 Oct 2010 13:23:35 +1100, Ben Finney
ben+deb...@benfinney.id.au
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
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
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:
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
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
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
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
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
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
On 2014-08-27 01:41, Antoine Musso wrote:
Le 27/08/2014 10:13, Sandro Tosi a écrit :
snip
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,
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
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
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
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",
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?
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
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
>
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]
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
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.
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 t
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
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
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
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
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
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&q
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
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
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
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
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
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
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
>
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
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
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 thi
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
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.),
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
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
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
45 matches
Mail list logo
