Re: Adopting factory-boy
On 12/05/16 07:57, Thomas Goirand wrote: > On 05/11/2016 02:31 PM, Christopher Baines wrote: >> On 11/05/16 13:19, Thomas Goirand wrote: >>> On 05/11/2016 11:31 AM, Christopher Baines wrote: On 23/12/15 15:30, Christopher Baines wrote: > On 23/12/15 11:31, Thomas Goirand wrote: >> I was the maintainer of this package, though I lost interest for it >> because there's no reverse dependency for it. > > Thanks for packaging it :) > >> If you want to continue maintaining it within the OpenStack PKG team, >> you can do it as well. Though we're not using git-dpm, and rather a git >> tag workflow, you're still free to use whatever workflow you want there, >> as long as the package is well maintained. >> >> If you need sponsoring for this package, I can review it and upload it >> for you. > > Great, thanks for the offer. I think I'll have to wait a couple of weeks > to see where things are for packaging this. There is at least one new > dependency for the latest release (python-fake-factory), I have packaged > that, but the tests currently don't pass. Once there is a release for > python-fake-factory, for which the tests pass, and that has been > uploaded to Debian, I'll get around to looking at factory-boy again. Its been quite a few weeks, but the above is now done. The missing dependency (python-fake-factory) is now in Debian, and I have updated factory-boy to the latest upstream version [1]. Are you still open to sponsoring this zigo? I have just filled in the alioth form to become a member of the OpenStack team. 1: http://git.cbaines.net/factory-boy/ >>> >>> Hi, >>> >>> I added you as a member of the team. Let me know when I should sponsor >>> the package. >> >> Great, I have pushed the changes to the repository and it is ready for >> you to review. > > Hi, > > Please join #debian-openstack-commits to see the build results. > Currently, the package FTBFS in Jessie's chroot: > > https://mitaka-jessie.pkgs.mirantis.com/job/factory-boy/5/console > > The type of error you're seeing is most of the time due to the fact you > didn't push the upstream tags to Git. Ok, the script in use there was not using the correct tag (it was missing a leading "v"), but this is now fixed by modifying GIT_TAG in the debian/rules makefile. However, the package still fails, as fake-factory is not available in Jessie. signature.asc Description: OpenPGP digital signature
Re: entry-point script and private module install directory
On 11/05/16 18:55, Piotr Ożarowski wrote:
[Ghislain Vaillant, 2016-05-11]
Dear all,
I have a package (pyfr), which is meant to be used as a command-line
application only.
The main script (pyfr) is installed via setuptools'
entry_points['console_scripts'], which generates the entry-point
automatically and places it under /usr/bin. However, when I install the
implementation module in a private location, such as /usr/share/pyfr,
the entry-point cannot find the module and load the application.
Right now, the module is installed in the dist-packages location,
although it is not intended to be public. It was just the easiest
solution to start with at the time.
What is the standard way to circumvent this? Do other packages use custom
you can create a wrapper or patch /usr/bin script to
sys.path.append('/usr/share/pyfr') but the easiest solution is to
install the script to /usr/share/pyfr/ (if the module is "pyfr" as well,
simply rename the script to "run" or any other name) and then symlink it
to /usr/bin/pyfr)
override_dh_auto_install:
dh_auto_install -- --install-lib=/usr/share/pyfr/
mv debian/pyfr/usr/bin/pyfr debian/pyfr/usr/share/pyfr/run
and add "/usr/share/pyfr/run /usr/bin/pyfr" to debian/pyfr.links
Thanks Piotr, that's the solution I have been looking for.
Ghis
Bug in pybuild's handling of --install-lib? [Was: Re: entry-point script and private module install directory]
On 12/05/16 09:22, Ghislain Vaillant wrote:
On 11/05/16 18:55, Piotr Ożarowski wrote:
you can create a wrapper or patch /usr/bin script to
sys.path.append('/usr/share/pyfr') but the easiest solution is to
install the script to /usr/share/pyfr/ (if the module is "pyfr" as well,
simply rename the script to "run" or any other name) and then symlink it
to /usr/bin/pyfr)
override_dh_auto_install:
dh_auto_install -- --install-lib=/usr/share/pyfr/
mv debian/pyfr/usr/bin/pyfr debian/pyfr/usr/share/pyfr/run
and add "/usr/share/pyfr/run /usr/bin/pyfr" to debian/pyfr.links
Thanks Piotr, that's the solution I have been looking for.
Ghis
Actually, on second look, Piotr's solution currently fails:
d/rules:
export PYBUILD_DESTDIR=$(CURDIR)/debian/tmp
[...]
override_dh_auto_install:
dh_auto_install -- --install-lib=/usr/share/pyfr
mv $(PYBUILD_DESTDIR)/usr/bin/pyfr $(PYBUILD_DESTDIR)/usr/share/pyfr/run
build log:
dh_auto_install -- --install-lib=/usr/share/pyfr
install -d debian/pyfr
install -d debian/pyfr-doc
pybuild --install -i python{version} -p 3.5
--install-lib=/usr/share/pyfr --dir . --dest-dir /<>/debian/tmp
usage: pybuild [ACTION] [BUILD SYSTEM ARGS] [DIRECTORIES] [OPTIONS]
pybuild: error: unrecognized arguments: --install-lib=/usr/share/pyfr
Whereas this succeeds:
d/rules:
export PYBUILD_DESTDIR=$(CURDIR)/debian/tmp
export PYBUILD_INSTALL_ARGS=--install-lib=/usr/share/pyfr
[...]
override_dh_auto_install:
dh_auto_install
mv $(PYBUILD_DESTDIR)/usr/bin/pyfr
$(PYBUILD_DESTDIR)/usr/share/pyfr/run
build log:
dh_auto_install
install -d debian/pyfr
install -d debian/pyfr-doc
pybuild --install -i python{version} -p 3.5 --dir . --dest-dir
/<>/debian/tmp
I: pybuild base:184: /usr/bin/python3 setup.py install --root
/<>/debian/tmp --install-lib=/usr/share/pyfr
running install
running build
running build_py
running install_lib
[...]
Is this a bug in pybuild or am I missing something?
Re: Bug in pybuild's handling of --install-lib? [Was: Re: entry-point script and private module install directory]
[Ghislain Vaillant, 2016-05-12] > Is this a bug in pybuild or am I missing something? you're missing my second reply¹ [¹] https://lists.debian.org/debian-python/2016/05/msg00043.html -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Bug in pybuild's handling of --install-lib? [Was: Re: entry-point script and private module install directory]
On 12/05/16 13:16, Piotr Ożarowski wrote: [Ghislain Vaillant, 2016-05-12] Is this a bug in pybuild or am I missing something? you're missing my second reply¹ [¹] https://lists.debian.org/debian-python/2016/05/msg00043.html Indeed, sorry for the noise. Thanks again for the support. Ghis
Re: Adopting factory-boy
On 05/12/2016 10:13 AM, Christopher Baines wrote: > On 12/05/16 07:57, Thomas Goirand wrote: >> On 05/11/2016 02:31 PM, Christopher Baines wrote: >>> On 11/05/16 13:19, Thomas Goirand wrote: On 05/11/2016 11:31 AM, Christopher Baines wrote: > On 23/12/15 15:30, Christopher Baines wrote: >> On 23/12/15 11:31, Thomas Goirand wrote: >>> I was the maintainer of this package, though I lost interest for it >>> because there's no reverse dependency for it. >> >> Thanks for packaging it :) >> >>> If you want to continue maintaining it within the OpenStack PKG team, >>> you can do it as well. Though we're not using git-dpm, and rather a git >>> tag workflow, you're still free to use whatever workflow you want there, >>> as long as the package is well maintained. >>> >>> If you need sponsoring for this package, I can review it and upload it >>> for you. >> >> Great, thanks for the offer. I think I'll have to wait a couple of weeks >> to see where things are for packaging this. There is at least one new >> dependency for the latest release (python-fake-factory), I have packaged >> that, but the tests currently don't pass. Once there is a release for >> python-fake-factory, for which the tests pass, and that has been >> uploaded to Debian, I'll get around to looking at factory-boy again. > > Its been quite a few weeks, but the above is now done. The missing > dependency (python-fake-factory) is now in Debian, and I have updated > factory-boy to the latest upstream version [1]. > > Are you still open to sponsoring this zigo? I have just filled in the > alioth form to become a member of the OpenStack team. > > 1: http://git.cbaines.net/factory-boy/ Hi, I added you as a member of the team. Let me know when I should sponsor the package. >>> >>> Great, I have pushed the changes to the repository and it is ready for >>> you to review. >> >> Hi, >> >> Please join #debian-openstack-commits to see the build results. >> Currently, the package FTBFS in Jessie's chroot: >> >> https://mitaka-jessie.pkgs.mirantis.com/job/factory-boy/5/console >> >> The type of error you're seeing is most of the time due to the fact you >> didn't push the upstream tags to Git. > > Ok, the script in use there was not using the correct tag (it was > missing a leading "v"), but this is now fixed by modifying GIT_TAG in > the debian/rules makefile. > > However, the package still fails, as fake-factory is not available in > Jessie. Hi, I added fake-factory as backport in that Jenkins server, and now it builds fine. In your Git log, I can read: * Add myself to Uploaders * Add build dependencies on fake-factory and python-ipaddress * Bump Standards-Version to 3.9.8 (no changes required) * Change the gbp.conf upstream-tag to include the v prefix, as this makes git-buildpackage able to find the tags None of this appeared in the debian/changelog. I added them, pushed them to the git, built and upload. Next time, please document all of your packaging changes in debian/changelog. Thanks for your contribution to Debian, Cheers, Thomas Goirand (zigo)
Re: Adopting factory-boy
On 12/05/16 15:14, Thomas Goirand wrote: On 05/12/2016 10:13 AM, Christopher Baines wrote: On 12/05/16 07:57, Thomas Goirand wrote: On 05/11/2016 02:31 PM, Christopher Baines wrote: On 11/05/16 13:19, Thomas Goirand wrote: On 05/11/2016 11:31 AM, Christopher Baines wrote: On 23/12/15 15:30, Christopher Baines wrote: On 23/12/15 11:31, Thomas Goirand wrote: I was the maintainer of this package, though I lost interest for it because there's no reverse dependency for it. Thanks for packaging it :) If you want to continue maintaining it within the OpenStack PKG team, you can do it as well. Though we're not using git-dpm, and rather a git tag workflow, you're still free to use whatever workflow you want there, as long as the package is well maintained. If you need sponsoring for this package, I can review it and upload it for you. Great, thanks for the offer. I think I'll have to wait a couple of weeks to see where things are for packaging this. There is at least one new dependency for the latest release (python-fake-factory), I have packaged that, but the tests currently don't pass. Once there is a release for python-fake-factory, for which the tests pass, and that has been uploaded to Debian, I'll get around to looking at factory-boy again. Its been quite a few weeks, but the above is now done. The missing dependency (python-fake-factory) is now in Debian, and I have updated factory-boy to the latest upstream version [1]. Are you still open to sponsoring this zigo? I have just filled in the alioth form to become a member of the OpenStack team. 1: http://git.cbaines.net/factory-boy/ Hi, I added you as a member of the team. Let me know when I should sponsor the package. Great, I have pushed the changes to the repository and it is ready for you to review. Hi, Please join #debian-openstack-commits to see the build results. Currently, the package FTBFS in Jessie's chroot: https://mitaka-jessie.pkgs.mirantis.com/job/factory-boy/5/console The type of error you're seeing is most of the time due to the fact you didn't push the upstream tags to Git. Ok, the script in use there was not using the correct tag (it was missing a leading "v"), but this is now fixed by modifying GIT_TAG in the debian/rules makefile. However, the package still fails, as fake-factory is not available in Jessie. Hi, I added fake-factory as backport in that Jenkins server, and now it builds fine. In your Git log, I can read: * Add myself to Uploaders * Add build dependencies on fake-factory and python-ipaddress * Bump Standards-Version to 3.9.8 (no changes required) * Change the gbp.conf upstream-tag to include the v prefix, as this makes git-buildpackage able to find the tags None of this appeared in the debian/changelog. I added them, pushed them to the git, built and upload. Next time, please document all of your packaging changes in debian/changelog. Ah yeah, sorry about the changelog, and thanks for uploading it :)
Re: pypy pakages
Stefano Rivera writes: > I think we're all kind of waiting for PyPy 3, so that we don't have to > bring up an entire stack of packages (that few people are going to > use). That's one thing I'm waiting for. Another thing is that many upstream packages don't bother declaring support for PyPy (heck, too many packages don't bother declaring what Python they support at all). I'm reluctant to assert that upstream's code supports PyPy if upstream doesn't assert that. > Otherwise, I'm not convinced that a large pypy stack in Debian is > really useful right now. Practically, I expect most pypy users to be > virtualenv-heavy. That is something Debian can play an important role in counteracting, I believe. (Provided we can actually support the packages, of course.) -- \ “The great thing about science is we can test our ideas.… But | `\ until we do, until we have data, it is just one more proposal.” | _o__) —Darren Saunders, 2015-12-02 | Ben Finney
RFS: python-easygui-0.98.0-1
Dear Debian Developers, Requesting review and sponsorship of python-easygui-0.98.0-1, available in the DPMT git repo. After quite some time with no updates and the upstream author announcing the project dead, development was picked up by a new upstream developer (endorsed by the original maintainer). Upstream now moved documentation to sphynx, and the documentation included in the package was thus moved from html to man. Is it ok to name the man page easygui when the Debian package name is python-easygui? Other changes to the package are made only to reflect new hosting of upstream code and web site. The package has a few lintian warnings: image-file-in-usr-lib These are images used in the easygui.egdemo() function. Having those in /usr/lib should, according to change in version 3.9.6.0 of Debian policy, be ok. Any comments and improvements are highly appreciated. I am a Debian maintainer, in case anybody feels like granting me upload permissions to the package. Sincerely Andreas Noteng signature.asc Description: OpenPGP digital signature
