Re: providing sphinx3-* binaries
On 03/10/17 22:46, Thomas Goirand wrote:
On 09/29/2017 01:08 PM, PICCA Frederic-Emmanuel wrote:
Hello guyes.
override_dh_sphinxdoc:
ifeq (,$(findstring nodocs, $(DEB_BUILD_OPTIONS)))
nodocs or nodoc
I alsa do something like this when there is extensions.
override_dh_sphinxdoc:
ifeq (,$(findstring nodoc, $(DEB_BUILD_OPTIONS)))
PYBUILD_SYSTEM=custom \
PYBUILD_BUILD_ARGS="cd docs && PYTHONPATH={build_dir}
http_proxy='127.0.0.1:9' {interpreter} -m sphinx -N -bhtml source build/html" dh_auto_build
# HTML generator
dh_installdocs "docs/build/html" -p python-gpyfft-doc
dh_sphinxdoc -O--buildsystem=pybuild
endif
In fact, I was thinking that probably, it'd be nicer to even do:
ifeq (,$(findstring nodoc, $(DEB_BUILD_PROFILES)))
and have Build-Profiles: for the python-foo-doc package. This
could even become a standard in the DPMT if everyone agrees.
Thoughts anyone?
s/DEB_BUILD_PROFILES/DEB_BUILD_OPTIONS
Quoting the relevant part of the documentation for the nodoc build
profile [1]:
"Builds that set this profile must also add nodoc to DEB_BUILD_OPTIONS"
[1] https://wiki.debian.org/BuildProfileSpec
Cheers,
Ghis
Re: providing sphinx3-* binaries
On 09/29/2017 01:08 PM, PICCA Frederic-Emmanuel wrote:
> Hello guyes.
>
>> override_dh_sphinxdoc:
>> ifeq (,$(findstring nodocs, $(DEB_BUILD_OPTIONS)))
>
> nodocs or nodoc
>
> I alsa do something like this when there is extensions.
>
> override_dh_sphinxdoc:
> ifeq (,$(findstring nodoc, $(DEB_BUILD_OPTIONS)))
> PYBUILD_SYSTEM=custom \
> PYBUILD_BUILD_ARGS="cd docs && PYTHONPATH={build_dir}
> http_proxy='127.0.0.1:9' {interpreter} -m sphinx -N -bhtml source build/html"
> dh_auto_build # HTML generator
> dh_installdocs "docs/build/html" -p python-gpyfft-doc
> dh_sphinxdoc -O--buildsystem=pybuild
> endif
In fact, I was thinking that probably, it'd be nicer to even do:
ifeq (,$(findstring nodoc, $(DEB_BUILD_PROFILES)))
and have Build-Profiles: for the python-foo-doc package. This
could even become a standard in the DPMT if everyone agrees.
Thoughts anyone?
Cheers,
Thomas Goirand (zigo)
Re: Namespace conflict for python-magic
Sorry about the slow response. This has been a pain for a while. I have a provisional diff to merge the two packages. Will give it some testing and pass a branch to you folks to take a look. Ideally the upstream file package would take it over. On Wed, Sep 6, 2017 at 1:23 AM, Mathias Behrle wrote: > * Christoph Biedl: " Re: Namespace conflict for python-magic" (Tue, 5 Sep 2017 > 18:24:25 +0200): > >> Mathias Behrle wrote... >> >> > * Christoph Biedl: " Re: Namespace conflict for python-magic" (Mon, 4 Sep >> > 2017 19:38:56 +0200): >> >> > > The cleanest solution indeed was to bring both upstreams together and >> > > ask them to reconcile the APIs and eventually make one of the both >> > > implementations obsolete. As things happen such an attempt was started >> > > two years ago but appearently never came to a result.[1] >> > >> > Agreed, that this would be the cleanest solution, but as you say there is >> > little probability, that the two upstreams will work together to merge >> > their >> > implementations. >> >> Still this should be tried first. Also, I'm not that pessimistic, see >> below. So let's bring the parties involved into the loop: > > [...] > > Thanks for your additional information and initiative to re-launch the merge > of > the two packages. This reads much better and more optimistic than what I could > find until now! Crossing fingers now in the hope for the best outcome for > everybody. > > Cheers, > Mathias > > -- > > Mathias Behrle > PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 > AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 -- Adam Hupp | http://hupp.org/adam/
