Packaging multivolumefile?
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'
Re: Packaging multivolumefile?
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
Re: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)
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: morph's abandoned packages (list)
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: New upstream version for python-pint
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: 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 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
