Re: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)

Hi Julian, On Sat, 2024-03-30 at 20:22 +, Julian Gilbey wrote: > Lovely to hear from you, and oh wow, that's amazing, thank you! > > I can't speak for anyone else, but I suggest that pushing your > updates > to the science-team package would be very sensible; it would be silly > for someone

Re: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)

On Mon, 2024-03-25 at 18:17 +, Julian Gilbey wrote: > > > So this is a plea for anyone looking for something really helpful to > do: it would be great to have a group of developers finally package > this!  There was some initial work done (see the RFP bug report for > details:

Re: dask.distributed RC bug #1042135

> > > > Thanks so much!  I see you've already started on dask :) > > I took at quick look at arrow - yikes!  There is potentially work > afoot on this though: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021 > Dask & dask.distributed 2023.8.0 was easier to update than some of the

Re: Updating python3-xlrd for pandas 1.5 compatibility

On Fri, 2023-02-24 at 19:33 +0100, Paul Gevers wrote: > Hi Diane, > > On 23-02-2023 08:12, Diane Trout wrote: > > the version of python3-xlrd 1.2.0-3 in unstable/testing is too old > > to > > be used with pandas 1.5.3. (See Bug #1031701). > > Do I understand c

Updating python3-xlrd for pandas 1.5 compatibility

Hi, the version of python3-xlrd 1.2.0-3 in unstable/testing is too old to be used with pandas 1.5.3. (See Bug #1031701). As it is a really common workflow to use pandas to read excel files, it'd be nice if the version of xlrd in bookworm was compatible. Because of the freeze I wanted to check if

Re: Bug#1030096: Any ideas Re: #1030096 dask.distributed intermittent autopkgtest fail ?

On Mon, 2023-02-06 at 21:39 +, Rebecca N. Palmer wrote: > I agree that xfailing the tests *may* be a reasonable solution.  I'm > only saying that it should be done by someone with more idea than me > of > whether these particular tests are important, because blindly > xfailing > everything

Re: Any ideas Re: #1030096 dask.distributed intermittent autopkgtest fail ?

On Mon, 2023-02-06 at 11:13 +0100, Andreas Tille wrote: > Hi Rebecca, > > Am Mon, Feb 06, 2023 at 07:59:17AM + schrieb Rebecca N. Palmer: > > (Background: the pandas + dask transition broke dask.distributed > > and it was > > hence removed from testing; I didn't notice at the time that if we

Bug#1013092: ITP: python3-sphinx-autosummary-accessors -- sphinx autosummary extension to pandas or xarray accessors

Package: wnpp Owner: Diane Trout Severity: wishlist * Package name: python3-sphinx-autosummary-accessors Version : 2022.4.0-1 Upstream Author : Justus Magin * URL or Web page : https://github.com/xarray-contrib/sphinx-autosummary-accessors * License : MIT Description

Re: Bug#982417: Python louvain packages naming confusion.

On Wed, 2021-02-10 at 18:35 -0500, Sandro Tosi wrote: > +Steffen explicitly, given the team is not in Maintainer nor > Uploaders > > > How about renaming the current python3-louvain package to > > python3-community-louvain using a normal transition package. > > that's incorrect:

Re: Python louvain packages naming confusion.

> > In the short term I recommend fixing this by adding a file to the > Debian python-louvain package named "debian/tests/autopkgtest-pkg- > python.conf" with the contents "import_name = community" > How about renaming the current python3-louvain package to  python3-community-louvain using a

Re: Bug#982417: Python louvain packages naming confusion.

On Wed, 2021-02-10 at 10:29 +0100, Michael R. Crusoe wrote: > > In the short term I recommend fixing this by adding a file to the > Debian python-louvain package named "debian/tests/autopkgtest-pkg- > python.conf" with the contents "import_name = community" > Thank you! I had a hunch there was

Re: Python louvain packages naming confusion.

On Wed, 2021-02-10 at 01:49 +, Paul Wise wrote: > On Tue, Feb 9, 2021 at 10:21 PM Diane Trout wrote: > > > The fairly popular (in the world of bioinformatics) ScanPy package > > uses > > a Python version of the louvain clustering algorithm implemented > > b

Python louvain packages naming confusion.

Hello, The fairly popular (in the world of bioinformatics) ScanPy package uses a Python version of the louvain clustering algorithm implemented by: https://github.com/vtraag/louvain-igraph https://pypi.org/project/louvain/ which installs into the "louvain" dist-packages directory. (from debc)

Re: gotchas when running tests via pybuild?

Hello, On Fri, 2021-01-22 at 14:06 -0300, Antonio Terceiro wrote: > Does anybody have an insight on cases like this? Are there any > details > that I'm missing? I occasionally have tests behave differently between the buildd and autopkgtest runner. Things that I have encountered. The pybuild

Python 3.9 & Numba

to make an experimental release of numba 0.52.0 with the compatibility patch and then see how pandas, astro team packages do with it. But it's a complicated package capable of strange side effects and I thought we should talk it over first. Thank you, Diane Trout [1] As an aside we also have an out of date

Re: Questions about including tests/ directory into package

On Thu, 2020-03-19 at 15:22 +0900, Sao I Kuan wrote: > Hi, > > I'm newcomer to Debian packaging, and trying to add the autopkgtest > test script into python-tinyalign[1]. > > [1] https://salsa.debian.org/med-team/python-tinyalign > > And now I'm facing a (maybe simple) problem. > > The

Re: Should python-cloudpickle get a py2keep tag?

On Thu, 2019-09-05 at 20:14 +0200, Matthias Klose wrote: > > you are asking about the least preferred option, without telling why > you can't > convert to python3, or why you can't remove the affected > packages. If you have > both spyder and spyder3 (Python3?), then why not drop spyder? I >

Should python-cloudpickle get a py2keep tag?

Hi, The py2removal bug says to discuss the py2keep tag first. src:cloudpickle is a dependency of src:spyder and src:skimage. python-skimage has a popcon inst score of 469 spyder has a popcon inst score of 1385 spyder3 has a popcon inst score of 1069 The removal bug says the popcon threshold

updating python-stdeb

Hi, Reading about all this talk about removing leaf python2 packages left me wondering. Could we change py2dsc's default python interpreter to python3? And that led me to check tracker there's 15 open bugs, and the last release was in 2015 Does anyone else use py2dsc? I was wondering if I

Re: Updating nbconvert : problems with privacy breaches

> But the other files... it's about changing the exporters and > templates > during document generation ; and the resulting files might then get > used > on non-Debian systems. In short : if I tamper with them to use > Debian > local packages, that basically means nbconvert in Debian will >

Re: NMU Advice: pybluez

> I think the general rule-of-thumb is to wait around 2 weeks for a > reply. > However, this package is team-maintained, so I would get in touch > with > the team first and ask them to sponsor the upload. This way, you > won't > need to wait that much and can do a team upload. > Ah good idea.

NMU Advice: pybluez

Hi, I was trying to do something with home-assistant and needed a Python 3 version of pybluez. Unfortunately I found this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839100 python-bluez: debian pybluez package version 0.22-1 uses upstream source code version 0.18 Which also blocks

Re: Dask sourceless javascript passed by me.

On Fri, 2018-06-08 at 10:05 +0800, Paul Wise wrote: > On Fri, Jun 8, 2018 at 5:59 AM, Diane Trout wrote: > > > How do I replace the .orig.tar.gz that I already uploaded? > > You will need a new upstream version, typically people use > 0.1.2+dfsg1 > (for DFSG issues)

Re: Dask sourceless javascript passed by me.

> > I would suggest talking to upstream about fixing this properly (no > > prebuilt files or embedded code copies in the VCS and tarballs). > > And in the meantime repacking the existing tarball to remove the > sourceless files. > I was suspecting that was going to be the answer... How do I

Dask sourceless javascript passed by me.

Hi, I discovered a mistake I made with packaging dask. There's two static html files which embed some bokeh generated javascript plot code that's in dask 0.17.5 and I uploaded that to the Debian. There doesn't appear to be source to build the files. Bokeh is free software (BSD-3-Clause), but

Bug#900535: Binary Independent build seems to have FTBFS

Package: src:python3-stdlib-extensions Version: 3.6.4-4 Severity: serious X-Debbugs-CC: debian-python@lists.debian.org Hello, python3-distutils is currently unavailable in unstable, it appears that python3-stdlib-extensions was intended to provided it, but the all architecture package is

What to do about packages that depend on distutils being not installable

Hi, I was trying to rebuild dask, and discovered that several dependencies aren't installable because python3-distutils appears to have been merged into python3-stdlib-extensions. For example in an unstable chroot python3-sphinx : Depends: python3-lib2to3 but it is not installable

Re: hangups

> > I wasn't sure this should go into Debian python modules, or Debian > > python applications? > > Since it has a public module, DPMT is a better bet. > Ok, thank you. Also that also has the advantage that I already have permissions to create repositories in DPMT Diane signature.asc

hangups

Hi, I'd packaged a hangouts client called hangups for myself a while ago, and I thought I'd upload it to Debian. https://hangups.readthedocs.io/en/latest/ I built the package so most of the python code is in a python3-hangups module but the executable is in its own package. (one could use the

Re: GitLab CI on salsa.debian.org

Can you trigger test on dependencies changing? Does CI run on architectures other than amd64? (I was thinking of complex packages with many dependencies like dask, or with fiddly bit manipulation like pandas) So this would get tests on each commit instead of the current autopkgtests which run

jupyter-notebook trickier copyright.

Hi, I was looking for copyrighted files and found jupyter-notebook/docs/sphinxext/ which lists an "All rights reserved" copyright. Adapted from bitbucket example here: https://bitbucket.org/birkenfeld/sphinx-contrib/src/tip/bitbucket/sphin xcontrib/bitbucket.py """ # # Original Copyright (c)

Re: RFS: jupyter components

Could you update the timestamp on jupyter-console as well? That one also has a time-warp-standards Thanks, Diane signature.asc Description: This is a digitally signed message part

Re: RFS: jupyter components

On Wed, 2017-10-25 at 22:15 +0200, Gordon Ball wrote: > > I would normally not update the timestamp while the suite is > UNRELEASED, > and expect whoever ultimately makes the upload to `dch -r` and tag > the > release, but maybe it would be less ambiguous to update it each time > d/changelog gets

Re: RFS: jupyter components

> I have just uploaded the current RFS packages (ipython, > jupyter-notebook, jupyter-console, nbconvert) to mentors.d.n I just reviewed nbconvert I got one lintian warning nbconvert source: timewarp-standards-version (2017-09-03 < 2017-09-27) The source package refers to a Standards-Version

Re: doc-central

On Fri, 2017-10-13 at 08:41 +0100, Simon McVittie wrote: > On Fri, 13 Oct 2017 at 08:13:08 +0800, Paul Wise wrote: > > On Fri, Oct 13, 2017 at 3:27 AM, Diane Trout wrote: > > > > > Being able to find all your documentation in one place would > > > really be &

doc-central

Hi, I wanted to be able to browse documentation locally, and the Python viewer doc-central is abandoned. What I have so far is a Python 3 version using CGI scripts. What I'd like is something uses wsgi and can run with Python's built-in wsgiref server instead of requiring a full web server.

pandas arm & mips FTBFS #877754

Hi, It's pretty difficult to run just one pandas unittest. I managed to extract a couple examples from the build logs and replicate the failures on a arm64 porterbox. Debian Bug is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877754 Forwarded to

Re: pycharm package in debian

> > who says that a "lagging behind" package doesn't have any security > > issues? If > > the package is lagging behind, how do you know that security > > updates aren't > > lagging behind either... > > As this is Debian, I do expect that at least, I can read the security > tracker to see the

Re: Python 3 Statsmodels & Pandas

On Sat, 2017-09-30 at 12:26 +0300, Dmitry Shachnev wrote: > > > > I wonder if it's better to filter sphinxdoc out of the dh line, > > install > > sphinx-common, or just always install python3-sphinx? > > Adding sphinx-common to B-D and keeping python3-sphinx in B-D-Indep > is > probably the

Re: Python 3 Statsmodels & Pandas

On Wed, 2017-09-27 at 08:34 +0200, Andreas Tille wrote: > > > > > https://ghic.org/~diane/debian/statsmodels.datasets.README.txt > > I think regarding formatting and context its perfectly fine. > > > Does it go in README.source? or in upstream/metadata? or something > > else? > > I think

Re: Python 3 Statsmodels & Pandas

> Since it is accepted for the R packages and the data are refering > to R data I do not see any reason why this should not be accepted. I traced back from Rdatasets to the original R packages. Every one of the packages are licensed as some combination of GPL-2 and GPL-3 However it's likely

Re: Python 3 Statsmodels & Pandas

> While I have not tried to build the current status I wonder what you > think about #873512. I'm perfectly fine with your solution to > exclude > some tests - I just wanted to give a hint that there is a potential > upstream patch. I think I looked at the upstream commits that fixed it,

Re: Python 3 Statsmodels & Pandas

On Mon, 2017-09-25 at 09:44 +0200, Andreas Tille wrote: > Hi Diane, > > On Sun, Sep 24, 2017 at 11:45:43PM -0700, Diane Trout wrote: > > The remaining issues are: > > > > * Some of the doc pages call get_rdataset, and there's no network > > access in the buil

Re: Python 3 Statsmodels & Pandas

On Mon, 2017-09-25 at 09:44 +0200, Andreas Tille wrote: > > > * Some of the doc pages call get_rdataset, and there's no network > > access in the builder so those calls fail. (ugliest error) > > Can you pre-fetch the data and provide it in debian/datasets? Looks like it'll take a bit of

Re: Python 3 Statsmodels & Pandas

On Sun, 2017-09-24 at 11:24 -0700, Diane Trout wrote: > Status with statsmodels almost done > > Trying to deal with jquery. > > leaving command > > -rm ./build/html/_static/jquery.js > > causes a build failure now. > leaving it in causes a lintain privacy

Re: Python 3 Statsmodels & Pandas

t;> On Sun, Sep 24, 2017 at 11:24:10AM -0700, Diane Trout wrote: >> > Status with statsmodels almost done > >> > Trying to deal with jquery. > >> > leaving command > >> >-rm ./build/html/_static/jquery.js > >> > causes a build fa

Re: Python 3 Statsmodels & Pandas

Status with statsmodels almost done Trying to deal with jquery. leaving command -rm ./build/html/_static/jquery.js causes a build failure now. leaving it in causes a lintain privacy error. there's also lintain warnings about a missing hardening flag, and no doc-base registration. At

Re: subliminal

On Thu, 2017-09-14 at 18:35 -0300, drebs wrote: > Hi, I am interested in updating the subliminal[2] package[1]. Is > there > someone else already working on that? If not, what would be the > process > for having it uploaded? (i am not a dm or dd) Should i send the > source > package to this list?

Re: Python 3 Statsmodels & Pandas

On Fri, 2017-09-22 at 10:57 +0200, Piotr Ożarowski wrote: > [Diane Trout, 2017-09-21] > > I made larger changes to statsmodels, by using pybuild instead of > > the > > previous multiple targets in debian/rules. > > you can simplify it even further by using pybuild's

Re: Python 3 Statsmodels & Pandas

I managed to merge the more important doc changes. I have a patch to switch doc building to using Python 3 components, as there's a goal of removing the Python 2 components at some point. The there's the patch for the nodoc/nocheck build profile, as well as adding a bunch of other dependencies

Re: Python 3 Statsmodels & Pandas

On Thu, 2017-09-21 at 17:56 -0400, Yaroslav Halchenko wrote: > If you could allow to review would be great. > Thanks for all the work. > I was btw also trying to build with the patch you shared yesterday Once I have all the changes for pandas would you like me to put them on a branch on alioth?

Re: Python 3 Statsmodels & Pandas

> If my poor opinion counts: For the moment we should run those tests > in > the build process than can be easily be run. Everything else should > probably be sorted out later (in autopkgtest or another later upload > if > somebody has a clue how we can solve the circular depenendecies). > >

Re: Python 3 Statsmodels & Pandas

> the biggest downside with this approach is that you *completely* skip > any > testing on other architectures than amd64. Is that what you really > want? Dear > porters, have fun where to search for bugs in packages without > testsuites! Ok you convinced me. dh_auto_tests stay. Is there

Re: Python 3 Statsmodels & Pandas

> On Saturday, 16 September 2017 14:18:10 AEST Diane Trout wrote: > > My solution was to use build-profiles to flag the test dependency > > with > > !nocheck > > this is, of course, a very elegant solution and exactly what build > profiles > are for... &

Re: Python 3 Statsmodels & Pandas

On Sat, 2017-09-16 at 22:59 +0200, Yuri D'Elia wrote: > On Sat, Sep 16 2017, Diane Trout wrote: > > python3-pandas: Pandas is not installable > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875723 > > I would have expected the rebuild of python packages affected by t

Python 3 Statsmodels & Pandas

Hi, Just wanted to give a progress report I was able to build a python 3 version of statsmodels, however I wasn't able to build it against the version of pandas in sid because pandas can't be installed. python3-pandas: Pandas is not installable

Re: Bug#729956: Forwarded upstream

Hi I pushed my work to alioth on the branch detrout-python3 I modified the statsmodels build recipe to at least partially use pybuild, and the documentation build uses python 3 components instead of python 2. I skipped the 4 tests that failed for me, that had an upstream bug report, when a new

Re: Bug#729956: Forwarded upstream

On Thu, 2017-09-07 at 06:20 +0200, Andreas Tille wrote: > Hi Diane, > > On Wed, Sep 06, 2017 at 02:45:14PM -0700, Diane Trout wrote: > > > > > but the build failed (for other reasons).  I'd willing to work on > > > this > > > but I definitely nee

Re: Bug#729956: Forwarded upstream

> but the build failed (for other reasons).  I'd willing to work on > this > but I definitely need help since I'm lacking the needed Python > knowledge. Hi, I saw your debian-python3 branch for statsmodels. The dependencies added in the package should probably be added as build-dependencies.

Re: Scaling back for now

I just wanted to say thank you for all you've done for Debian & Python. Diane signature.asc Description: This is a digitally signed message part

Re: Bug#872183: RFP: importmagic -- Python library for finding unresolved symbols and managing imports

On Mon, 2017-08-14 at 19:22 -0400, Nicholas D Steeves wrote: > Package: wnpp > Severity: wishlist > > * Package name: importmagic >   Version : 0.1.7 >   Upstream Author : Alec Thomas > * URL : https://github.com/alecthomas/importmagic > * License

Re: MBF for deprecating Python2 usage

On Tue, 2017-08-08 at 13:24 +1000, Ben Finney wrote: > > Those people, not party ot this conversation, have reasonable > expectation that such breakage will not happen without very good > reason. > Good reason would entail, as an example, that there is no better > alternative. > Why not ask? I

Re: MBF for deprecating Python2 usage

> What I am opposing is the suggestion to install, in the near to > medium > term, a command of exactly the same name that has subtly similar but > incompatible behaviour, when that behaviour *already* has a command – > ‘python3’ – that is widely used by those who need it. > my problem with

Re: MBF for deprecating Python2 usage

> What tearing need is there to change what the command ‘python’ does, > in > a backward-incompatible way? Personally, I'm ready for python to point to python3 now. I'm tired of writing python 2/3 compatible code because someone _might_ launch a script with "python my_python3_script.py instead

Re: MBF for deprecating Python2 usage

> I disagree, it's a bad idea to actively take steps to make the same > command invoke *incompatible* programs depending on the time and > host. My suggestion was "the startup banner should print what command to run to get Python 2." I was thinking of the case of the end-user trying to follow a

Re: a few quick questions on gbp pq workflow

> > Why would you need to repack a tarball just because it contains > prebuilt docs (non-DFSG-free licensed documentation aside)? I'm all I've occasionally repacked a tarball because upstream included minified jquery or mathjax. Diane signature.asc Description: This is a digitally signed

Re: MBF for deprecating Python2 usage

> * Plan for a date at which /usr/bin/python will point to Python 3.  I > know that’s the most controversial bit, but I do think that as time > goes on and we’re past 2020, it will be the choice that gives our > users the best experience. I agree the default should change. Perhaps when

Packaging Bokeh

Hi, I've made some limited progress trying to package Bokeh (BSD-3-Clause) upstream: http://bokeh.pydata.org/en/latest/ my packaging: https://github.com/detrout/python-bokeh I managed to get the version 0.9.1 from pypi installable. (Though since it was my own experiments I didn't remove the

Re: Packaging Bokeh

> > The most proper packaging would require grunt to be able to rebuild > > bokeh.js. I was wondering if releasing the pypi version would be good > > enough. (The package does at least contain a non-minimized version of > > bokeh.js) > I'm not sure about this, but it looks like the Bokeh source is

Re: Packaging Bokeh

On Saturday, September 05, 2015 09:28:48 Diane Trout wrote: > > > The most proper packaging would require grunt to be able to rebuild > > > bokeh.js. I was wondering if releasing the pypi version would be good > > > enough. (The package does at least cont

recommended numpy dependency ranges?

Hi, I have a small package the depends on numpy and it recently stopped working. Traceback (most recent call last): File /usr/local/lib/R/site- library/DEXSeq/python_scripts/dexseq_prepare_annotation.py, line 33, in module import HTSeq File

Re: recommended numpy dependency ranges?

I'm pretty sure a recompile will fix it, the question I have is how often does numpy break binary compatibility? Should set your numpy dependencies to something like: python-numpy (= 1.8, 1.9) do not hard code -- add calls to dh_numpy (dh_numpy3) to your rules and make sure you

Re: Python 3 as default

Instead, I mean, what would it take for the basic Debian system to install Python 3 only by default, and have any system scripts that depend on Python be Python 3. Nothing. I just did a default no-tasks selected debian wheezy system and no version of python was installed. Using a

Re: Packaging the new upstream release of ipython (i.e. 1.1.0)

So there is a list of things that need doing for ipython. I'd built my own not-redistributable version of 1.1.0, (progress at https://github.com/detrout/debian-ipython) I'll see if I can help with some of the work listed below. Diane On Thursday, October 03, 2013 22:29:41 Jean-Christophe