Bug#1023211: RM: dirtbike -- ROM; Obsolete, no longer used for any Debian Python packages
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: debian-python@lists.debian.org We used to use this back when we debundled pip's embedded dependencies. We don't do that anymore (no longer supported upstream), so dirtbike is not needed. It is unmaintained upstream and likely to be a problem over time since its design is inherently fragile. Scott K
Re: Help needed: numpy FTBFS with newer setuptools
Hi Sandro, with the recent upload of setuptools/65.3.0 (and following) in unstable, numpy FTBFS[1]. The reason is that numpy build system (both used internally and by other packages) customizes setuptools/distutils. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020135 Upstream is unwilling[2] to continue patching their build system in response to setuptools changes. While there may be merit in their position, this leaves Debian in a state where numpy is unbuildable, and the freeze is approaching. [2] https://github.com/numpy/numpy/issues/21114 I tried to look at addressing this problem myself, but i had no luck, so i'm here to ask for the help of the wider python team to address this issue. A build log from my machine is available here[3] (error is at the end of the page, as usual). [3] https://paste.debian.net/1259001/ My plan would be, once this is addressed, to package the latest 1.23.4 in experimental, ask for an archive rebuild and later upload 1.23.x to unstable in time for the freeze. This plan is currently on hold due to [1]. Thanks in advance for your help! export SETUPTOOLS_USE_DISTUTILS=stdlib in debian/rules does make it build for me. Do you consider that a fix? Cheers Jochen signature.asc Description: PGP signature
Re: build package xrayutilities - wheel and pip with setuptools
On Monday, October 31, 2022 1:26:03 PM EDT Carsten Schoenert wrote: > Hello Frederic, > > Am 31.10.22 um 08:57 schrieb PICCA Frederic-Emmanuel: > >> I can build the package basically doing these modifications and by > >> adding the additional B-D package Scott did mention. Simply let > >> dh_sphinxdoc build the documentation and adding the additional needed > >> package dependencies. > > > > [your patch] > > > > In your proposition you removed the arch/indep split, is it on purpose ? > > yes, building the Sphinx based documentation doesn't need to be done > that (to me fragile) way. debhelper is smart enough to do the right > things in the correct order if you tell it to use the sphinxdoc module. Agreed. More generally, use of setup.py is being deprecated in favor of the pyproject.toml based interface with the various Python build systems (including setuptools). The approach Carsten is recommending is recommending is not only more robust, it is more future proof. At some point your upstream will probably stop including the setup.py and you don't want to depend on it if you don't need to (and you don't). Scott K signature.asc Description: This is a digitally signed message part.
Re: build package xrayutilities - wheel and pip with setuptools
Hello Frederic, Am 31.10.22 um 08:57 schrieb PICCA Frederic-Emmanuel: I can build the package basically doing these modifications and by adding the additional B-D package Scott did mention. Simply let dh_sphinxdoc build the documentation and adding the additional needed package dependencies. [your patch] In your proposition you removed the arch/indep split, is it on purpose ? yes, building the Sphinx based documentation doesn't need to be done that (to me fragile) way. debhelper is smart enough to do the right things in the correct order if you tell it to use the sphinxdoc module. -- Regards Carsten
Re: review for pipenv/2022.10.12-1
> You can avoid resetting or forcing anything by increasing the > repacksuffix. As far as both git and the tooling are concerned, that > makes it an all new upstream version without conflicts with the > repo's current content, so pushing to git works just fine. > First update the excluded files in d/copyright and commit that > change, then run with the usual 'gbp import-orig --pristine-tar > --uscan'. When gbp asks you for the upstream version, modify the +ds > part to +ds2 and proceed with that. Thanks! uscan was not quite letting me use gbp import-orig but I was able to update the excluded files and have uscan re-download the new tarball correctly. Then I just had to rename the tarball with the +ds2 version and use gbp import-orig . Anyway that produced the intended result, so I pushed that along with the lintian-overrides, and the pipeline passes. >> I totally lost interest in maintaining that package and kind of neglected >> it because of the vendoring and the package itself or rather its upstream. >> Anyways, I thought I've orphaned it long time ago (maybe I forgot to do >> that). So thank you for taking over, I'm sure a lot of users will be happy! No problem! I am happy to help. I added myself as an uploader also, and I do not think there is a need to formally orphan if the team still maintains it (and I will continue to upload). Ileana
Re: build package xrayutilities - wheel and pip with setuptools
> Hello Frederic, Hello Carsten > please could you provide next time direct links to the VCS/Tracker of > your package, that prevents time to search for the correct package on my > or others people side. Also a speaking subject content is helping me to > decide if I want to spend time on taking a look, youve choose a very > generic line. :-) ack > https://tracker.debian.org/pkg/xrayutilities > https://salsa.debian.org/science-team/python-xrayutilities > No as you have overwritten the default target by a call that is quite > similar to the original pybuild call. > Yes, the environment isnt the same for the second call, youd need > to > ensure that the build directory is clean before starting the second run. > But I dont see why this construct youve build in d/rules is > needed > that way. ok > I can build the package basically doing these modifications and by > adding the additional B-D package Scott did mention. Simply let > dh_sphinxdoc build the documentation and adding the additional needed > package dependencies. [your patch] In your proposition you removed the arch/indep split, is it on purpose ? > lintian has some additional remarks any way, I havent looked further at > these. ok Cheers Fred
