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

2024-03-30 Thread Diane Trout
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 else to have to redo your work.
> 
> What more is needed for it to be ready for unstable?


The things I think are kind of broken are:

We've got 7.0.0 and upstreams current version is 15.0.2.

the pyarrow 7.0.0 tests fail because it depends on a python test
library that breaks with pytest 8.0. Either I need to disable the
python tests or upgrade to a newer version.

My upgrade didn't go smoothly because uscan found also upstreams debian
watch file which is too loose and matches some other tar balls on their
distribution site.

(Though I don't know why uscan keeps looking for watch files after
finding one in debian/watch)

And you were probably right in that arrow needs to be a team, because I
have no idea how to get other the other languages interfaces packaged.

Oh and I probably need to get the pyarrow installed somewhere, since it
was stopping at the tests I hadn't run into dh_missing errors yet.

Diane



Re: New upstream version for python-pint

2024-03-30 Thread Thomas Goirand

On 3/29/24 15:13, Antonio Valentino wrote:

Dear Thomas and Ondřej,
a couple of packages that I maintain are impacted by an RC bug in 
python-pint (#1067318).
I think that an update to the to the latest pint version 0.23 should be 
sufficient to fix the issue.


If you agree, I would like prepare the package for the new upstream 
version in the salsa.

Of course I will let to you the review and upload.

Please let me know,


kind regards


Please go ahead and feel free to add yourself as uploader.

Thomas



Re: morph's abandoned packages (list)

2024-03-30 Thread Thomas Goirand

On 3/30/24 02:08, Bo YU wrote:

hi!

On Sat, Mar 30, 2024 at 8:20 AM Thomas Goirand  wrote:


On 3/29/24 21:18, Timo Röhling wrote:

Hi Thomas,

* Thomas Goirand  [2024-03-17 23:09]:

Anyone is welcome to join, it's just that I'm using git tag workflow,
so it doesn't fit in the DPT, but that's the only thing.

I am not familiar with that workflow and could not find any
documentation. Can you give me a quick overview what I should do
differently from the "regular" DPT workflow?

Cheers
Timo


I'm not using pristine-tar, or gbp import-orig, and don't use upstream
tarballs, but git only. Everything is done in a single (debian) branch.

Just share the workflow of DPT I always follow[0]:
```
$ uscan   # Download your package's upstream original tarball
$ tar -xvf srcpkgname_1.0.orig.tar.gz
$ cd srcpkgname_1.0
$ git init
$ git checkout -b upstream
$ git add .
$ git commit -m "import srcpkgname_1.0.orig.tar.gz"
$ git tag -s upstream/1.0
$ pristine-tar commit ../srcpkgname_1.0.orig.tar.gz upstream
$ git checkout -b debian/master
```
And upgrade upstream release[1]. These should be enough.
If given team maintenance, I would like to suggest to follow this.

[0]: https://wiki.debian.org/Python/GitPackaging#Creating_a_new_package
[1]: https://wiki.debian.org/Python/GitPackaging#New_upstream_release
I would not do this way, but use gbp import-orig instead. I'm not sure 
why the wiki recommends, IMO wrongly, to do things by hand. Indeed, all 
of this:


$ git checkout -b upstream
$ git add .
$ git commit -m "import srcpkgname_1.0.orig.tar.gz"
$ git tag -s upstream/1.0

can be replaced by by this simple command:
$ gbp import-orig ../srcpkgname_1.0.orig.tar.gz

Cheers,

Thomas Goirand (zigo)



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

2024-03-30 Thread Julian Gilbey
Hi Diane,

On Fri, Mar 29, 2024 at 11:49:07AM -0700, Diane Trout wrote:
> 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: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021),
> > but that is fairly old now.  As Apache Arrow supports numerous
> > languages, it may well benefit from having a group of developers with
> > different areas of expertise to build it.  (Or perhaps it would make
> > more sense to split the upstream source into a collection of
> > different
> > Debian source packages for the different supported languages.  I
> > don't
> > know.)  Unfortunately I don't have the capacity to devote any time to
> > it myself.
> > 
> > Thanks in advance for anyone who can step forward for this!
> 
> I've been maintain dask and anndata and saw that apache arrow was
> getting increasingly popular.
> 
> I took the current science-team preliminary packaging 7.0.0 packaging
> and managed to get it to build through a combination of patches and
> turning off features.
> 
> I even mostly managed to get pyarrow to build. (Though some tests fail
> due to pytest lazy-fixture being abandoned).
> 
> I pushed my current work in progress to.
> 
> https://salsa.debian.org/diane/arrow.git
> 
> Was anyone else planning on working on it or should I push my updates
> to the science-team package?

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 else to have to redo your work.

What more is needed for it to be ready for unstable?

Best wishes,

   Julian



Re: Packaging multivolumefile?

2024-03-30 Thread Andreas Metzler
On 2024-03-30 Andreas Metzler  wrote:
> Hello,

> I originally intended to file an ITP, but it probably makes more sense
> to ask here:

> py7zr >= 0.16.0 requires multivolumefile by the same author. How about
> packaging it under the debian-python umbrella?

Nevermind, YOKOTA Hiroshi already has done this and more and is looking
for sponsors.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065221#17

cu Andreas



Packaging multivolumefile?

2024-03-30 Thread Andreas Metzler
Hello,

I originally intended to file an ITP, but it probably makes more sense
to ask here:

py7zr >= 0.16.0 requires multivolumefile by the same author. How about
packaging it under the debian-python umbrella?


* Source package name: python-multivolumefile
* Binary Package name: python3-multivolumefile
  Version : 0.2.3
  Upstream Contact: Hiroshi Miura 
* URL : https://codeberg.org/miurahr/multivolume
* License : LGPL-2.1+
  Programming Lang: Python
  Description : multiple files-wrapping library for Python

MultiVolumefile is a Python library to provide file-object wrapping
multiple files as virtually like as a single file. It inherits
io.RawIOBase class and supports some of its standard methods.

The upstream projectname is "multivolume", I would go for
python-multivolumefile to better match the module name and add a python
prefix since I am not using the upstream name anyway.)

multivolume has not seen any activity in GIT for about two years,
however py7zr seems to be alive.

I would be willing to do the grunt work but have basically zero
experience in packaging python modules, so I would appreciate some
handholding/feedback.

TIA, cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'