Hi,
On 2024-09-27 23:00, Aditi Mishra wrote:
> Version: 2.1.2+dfsg-4
>
> pytorch FTBFS on ppc64el: Open bug
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071655
>
> This regression is still seeing more than a month. Can you provide any detail
> about this?
2.4.1 was just recently uplo
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 acco
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 publi
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
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 w
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
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 fixin
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 t
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
> Sever
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 li
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 an
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
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 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 pybui
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
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 li
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-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 (w
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
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: python-xmlschema
Version : 1.2.2
Upstream Author : SISSA (Scuola Internazionale Superiore di Studi Avanzati)
* URL : https://github.com/sissaschool/xmlschema/
* License : MIT
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
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.
A
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
> appeare
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 se
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/
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', bu
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 corr
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
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,
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", rig
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
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
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 ef
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 the
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
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,
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 env
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 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 ea
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 wa
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
> co
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-wr
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/
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 ‘Depend
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 appr
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)
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 a
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
50 matches
Mail list logo