Re: Adopting factory-boy
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. Cheers, Thomas Goirand (zigo)
Re: entry-point script and private module install directory
FTR: [Piotr Ożarowski, 2016-05-11] > dh_auto_install -- --install-lib=/usr/share/pyfr/ this one ^ should be: dh_auto_install -- --install-args='--install-lib=/usr/share/pyfr/' or you can: export PYBUILD_INSTALL_ARGS=--install-lib=/usr/share/pyfr/ (thanks to Dmitry Shachnev for noticing) -- 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: entry-point script and private module install directory
[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
--
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
entry-point script and private module install directory
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 wrapper scripts, or is there a more clever way to tell the entry-point to look for a custom package location? Is there a good example you guys can point me to? There was a similar discussion for the grip [1] package on this list, but it did not lead to something I can use, or so I believe. [1] https://lists.debian.org/debian-python/2016/04/msg1.html Many thanks, Ghis
Re: pypy pakages
On May 10, 2016, at 09:56 PM, Tristan Seligmann wrote: >I think it would be great if we could get performance-sensitive applications >running on PyPy instead of CPython, but of course this requires the whole >dependency graph to have pypy-* packages built. That might be a good approach to building out the PyPy stack so we get more experience with it. Have you identified a leaf package or two that would benefit from being run under PyPy in Debian? That's the first step; then work backwards in the dep chain. Cheers, -Barry
Re: Adopting factory-boy
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. signature.asc Description: OpenPGP digital signature
Re: Adopting factory-boy
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. Cheers, Thomas Goirand (zigo)
Updating python-django-tagging (0.4.1 -> 0.4.3)
Hey, Is anyone available to review and upload a new version of python-django-tagging [1][2]? The changelog is: * New upstream release * Convert debian/copyright to the DEP-5 format * Add myself as an uploader * Remove the fix_calc_tag_weight patch, as this has been merged upstream * Remove the fix-testsuite patch, as this is unnecessary Thanks, Chris 1: https://anonscm.debian.org/cgit/python-modules/packages/python-django-tagging.git/ 2: https://tracker.debian.org/pkg/python-django-tagging signature.asc Description: OpenPGP digital signature
Re: Adopting factory-boy
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/ signature.asc Description: OpenPGP digital signature
