review for gtg/0.6-1
hi Francois, I took a look at the gtg package put up for sponsorship in the Python team: * changelog: + multiple entries for revisions that did enter the archive (0.3.1-2 through 4) appear to have gone missing? + there's about a dozen open bugs against the old package, yet only a single one gets closed. Did you review the outstanding bugs and check if any of them are fixed by the new upstream release and/or the revamped packaging? + it's team policy to keep the target distribution at UNRELEASED while a package is under review. + ITP bug not closed upon package reintroduction? * clean: consider converting the entries for deleting pycache stuff at depths other than 3 to also use globbing. * control: + long description should be extended. Assume the reader knows little or nothing about the application at all; what can it do, what makes it special, what services does it integrate with, and so on. Take a look at the upstream homepage if you need inspiration. + why list the old maintainer as uploader? + multiple missing dependencies for utilities called by script_pocketmod. + missing dep gir1.2-secret-1 (for the optional import of gi.repository.Secret in GTG/core/keyring.py) + missing dep for optional import of gi.repository.GnomeKeyring in GTG/core/keyring.py (though it seems that's not yet packaged in Debian so we might have to forego it for now). + missing dep gir1.2-pango-1.0 (for the unconditional import of Pango in GTG/gtk/browser/treeview_factory.py and other files; as well as PangoCairo in GTG/gtk/browser/cell_renderer_tags.py) + unused build-dep on itstool? + lots of build-deps only appear useful for testing; please mark those . * copyright: + public domain without explanation detailing exactly what exemption the files in question have from default copyright restrictions. + GTG/plugins/dev_console/* headers say LGPL, not GPL. + one Jean-François Fortin Tam is listed in the 'Files: *' paragraph, but only appears as a copyright holder in two files (GTG/core/info.py.in and a single translation). * docs: what purpose does a list of upstream authors serve as end user documentation? * patches: two out of three patches at first glance appear useful for inclusion upstream, yet all are marked 'Forwarded: not-needed'? * rules: + override_dh_auto_install starts by calling dh_auto_install; consider using execute_after_ instead of an override in such cases. + upstream testsuite (based on pytest) not run on build, why? * lintian: + X: gtg: executable-in-usr-lib usr/lib/python3/dist-packages/GTG/plugins/export/export_templates/script_pocketmod (wrong install location per FHS?) + X: gtg: executable-in-usr-lib usr/lib/python3/dist-packages/GTG/core/networkmanager.py (imported as a python module, file probably shouldn't be executable at all?) * autopkgtests: + please change directory to $AUTOPKGTEST_TMP before running test commands to ensure the test doesn't depend on anything from the extracted source pkg, see best practices at [1]. + consider adding an autopkgtest based on the upstream testsuite. * source: variables not properly quoted in 'script_pocketmod', cannot handle spaces (etc.) in the path of the source file; please patch. Once the above comments have been addressed, simply re-add the package to the IRC channel topic. Note: I didn't do any functional testing yet, in light of the need for significant changes to the current packaging. [1]https://wiki.debian.org/ContinuousIntegration/AutopkgtestBestPractices pgpmbgnj_P0OF.pgp Description: OpenPGP digital signature
Re: build package xrayutilities - wheel and pip with setuptools
thanks for your help.
I have one more question
I have this command from the previous build
{interpreter} setup.py build_man
how can I translate this with the new build systeme ?
Re: build package xrayutilities - wheel and pip with setuptools
On Tuesday, November 1, 2022 11:15:59 AM EDT PICCA Frederic-Emmanuel wrote:
> thanks for your help.
>
> I have one more question
>
> I have this command from the previous build
>
> {interpreter} setup.py build_man
>
> how can I translate this with the new build systeme ?
As far as I can see, the package doesn't ship any files in /usr/bin. Why do
you need to build man pages (I'm assuming that's what that's for? More
generically, what problem did that step in the process solve that's not solved
now?
Scott K
signature.asc
Description: This is a digitally signed message part.
Re: build package xrayutilities - wheel and pip with setuptools
On Tuesday, November 1, 2022 2:42:22 PM EDT PICCA Frederic-Emmanuel wrote: > > As far as I can see, the package doesn't ship any files in /usr/bin. > > Why do you need to build man pages (I'm assuming that's what > > that's for? More generically, what problem did that step in the > > process solve that's not solved now? > > this is for the pyfai package which I need to update > > https://salsa.debian.org/science-team/pyfai I see. I was confused by the subject saying this was about xrayutilities still. I'll have a look. Scott K signature.asc Description: This is a digitally signed message part.
Re: build package xrayutilities - wheel and pip with setuptools
On Tuesday, November 1, 2022 2:48:12 PM EDT Scott Kitterman wrote: > On Tuesday, November 1, 2022 2:42:22 PM EDT PICCA Frederic-Emmanuel wrote: > > > As far as I can see, the package doesn't ship any files in > > > /usr/bin. > > > Why do you need to build man pages (I'm assuming that's what > > > that's for? More generically, what problem did that step in the > > > process solve that's not solved now? > > > > this is for the pyfai package which I need to update > > > > https://salsa.debian.org/science-team/pyfai > > I see. I was confused by the subject saying this was about xrayutilities > still. I'll have a look. > > Scott K It looks to me like the current pyproject.toml file for pyfai is not sufficient to build the package, so I would tempted to keep what you have now. For another package (weasyprint) where I have to build the man page from Sphinx documentation myself, I use this to build it: override_dh_installman: PYTHONPATH=.:$PYTHONPATH sphinx-build -b man docs debian dh_installman Then weasyprint.manpages has: debian/weasyprint.1 Their build_man command has a lot of moving parts, so pyfai may br more complicated. AScott K signature.asc Description: This is a digitally signed message part.
Re: Help needed: numpy FTBFS with newer setuptools
> export SETUPTOOLS_USE_DISTUTILS=stdlib > > in debian/rules does make it build for me. Do you consider that a fix? thanks! that worked indeed -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: build package xrayutilities - wheel and pip with setuptools
> As far as I can see, the package doesn't ship any files in /usr/bin. > Why do > you need to build man pages (I'm assuming that's what that's > for? More > generically, what problem did that step in the process solve that's not > solved > now? this is for the pyfai package which I need to update https://salsa.debian.org/science-team/pyfai
Re: build package xrayutilities - wheel and pip with setuptools
On Tuesday, November 1, 2022 3:02:00 PM EDT PICCA Frederic-Emmanuel wrote: > >It looks to me like the current pyproject.toml file for pyfai is not > >sufficient> > > to build the package, so I would tempted to keep what you have now. > > Due to the presence of this file, pybuild try to build using the "new way" > instead of building with setup.py. > > I do not know if other package are in this state, but if produce an FTBFS. > > Cheers I don't think it should do that, so we need to investigate. Where can I find the updated packaging? Scott K signature.asc Description: This is a digitally signed message part.
Re: build package xrayutilities - wheel and pip with setuptools
>It looks to me like the current pyproject.toml file for pyfai is not >sufficient > to build the package, so I would tempted to keep what you have now. Due to the presence of this file, pybuild try to build using the "new way" instead of building with setup.py. I do not know if other package are in this state, but if produce an FTBFS. Cheers
Re: build package xrayutilities - wheel and pip with setuptools
On Tuesday, November 1, 2022 3:31:47 PM EDT PICCA Frederic-Emmanuel wrote: > > I don't think it should do that, so we need to investigate. Where > > can I find the updated packaging? > > I did not push the change right now, I will push once I solve this issue :). > > my opinion is that I should force via PYBUILD_SYSTEM=distutils > > Fred If that works, I think it's fine, but I don't think it should be necessary. Let me know once you push the package and I'll see if there's a pybuild issue. Scott K signature.asc Description: This is a digitally signed message part.
Re: build package xrayutilities - wheel and pip with setuptools
> I don't think it should do that, so we need to investigate. Where can I > find > the updated packaging? I did not push the change right now, I will push once I solve this issue :). my opinion is that I should force via PYBUILD_SYSTEM=distutils Fred
Bug#1023299: ganeti-testsuite: yaml.load in testsuite needs to specify loader
Source: ganeti-testsuite Version: 3.0.2-1 Severity: serious Tags: upstream ftbfs Justification: fails to build from source X-Debbugs-Cc: debian-python@lists.debian.org Previously yaml.load did not require a loader to be specified: load(stream, Loader=None) Now it does (starting in pyyaml 6.0): load(stream, Loader) Ganeti-testsuit uses yaml.load without specifying a loader, which now causes a test failure in unstable. Due to ganeti not being buildable currently, it's not possible to fix this at the moment. Note: Using FTBFS as a tag since that's the closest thing we have to a test failure that would prevent migration. Scott K
New upstream version of sphinxext-opengraph 0.7.0
Dear list, I have committed to salsa the new version of sphinxext-opengraph [1]. If someone could have a look, that would be great. Thanks! Best, Chiara [1] https://salsa.debian.org/python-team/packages/sphinxext-opengraph
Joining the Debian Python Team
Hi, I'm packaging "depthcharge-tools", a Python project of mine that manages the ChromeOS bootloader to make Debian natively bootable on Chromebooks. My sponsor already cloned it to the python-team/packages Salsa namespace and uploaded it to NEW with the Python Team as Maintainer. I want to join the team to keep maintaining it as part of the team. My salsa account name is "alpernebbi". I have read and accept the Debian Python Team Policy: https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst Also, I have requested access to the cloned repo, please accept it: https://salsa.debian.org/python-team/packages/depthcharge-tools Thanks!
