Re: Fixes for python-pyopencl and new upsteam release

["Adam D. Barratt" <adam@adam-barratt.org.uk>]

[Apparently your previous mail triggered quite a few rules in a custom
SA ruleset, so I hadn't seen it until I found it in my spam folder this
afternoon]

On Sat, 2010-10-23 at 20:47 +0200, Tomasz Rybak wrote:
> Dnia 2010-10-23, sob o godzinie 16:37 +0100, Adam D. Barratt pisze:
> > On Thu, 2010-10-21 at 21:47 +0200, Tomasz Rybak wrote:
> > +  * Fixed FTBFS on i386 (Closes: #599782)
> > 
> > This isn't actually RC, as the package has never built on i386; still
> > worth fixing though.
> 
> After applying fix suggested by Jakub Wilk now it builds on i386
> (I checked using pbuilder, and Evgeni Golov was able to build on
> his system).

I wasn't suggesting that the fix didn't work, just pointing out that the
bug in question isn't RC.

[ print -> print() ]
> > That won't work with python 2.6 or earlier; well, it'll work with 2.6 if
> > you import it from future, but the package claims to support python 2.5
> > and above.  There's a bunch of other occurrences of this in the diff,
> > but the rest all appear to be patched out.
> 
> Removed all 9 lines containing print.

Hmmm, might the messages in them be useful?  I'm not sure if there's a
nice way of handling both the print keyword and function without a try
except.  Having said that, as the package doesn't ship a python3 binary
package anyway, you only actually need to be compatible with 2.6 and
earlier...

> > +  * Forced build scripts not to use boost libraries included in the source
> > 
> > Could you point out where that fix is in the diff?  I couldn't
> > immediately spot it, but might be missing something obvious.
> 
> Upstream package (available from pypi) includes Boost.
> I am using source downloaded using git (debian/rules get-orig-source),
> so it does not contain Boost (I do not want waste space), but I also
> disabled ability to use shipped boost in case someone wants to build
> using pypi source.
[...]
>      if conf["USE_SHIPPED_BOOST"]:
>          if not exists("bpl-subset/bpl_subset/boost/version.hpp"):
[...]
>              conf["USE_SHIPPED_BOOST"] = False
[...]
>      if conf["USE_SHIPPED_BOOST"]:
>          conf["BOOST_INC_DIR"] = ["bpl-subset/bpl_subset"]
>          conf["BOOST_LIB_DIR"] = []

That doesn't actually appear to disable anything, afaics.
USE_SHIPPED_BOOST will be set to False when building the Debian package,
but only because bpl-subset/bpl_subset/boost/version.hpp won't exist.

> > +  * Switch to debhelper compat level 8; no changes necessary.
> > 
> > That's not an appropriate change to be making at this stage.
> 
> Should I revert to 7 then?

Yes, please.

> In case of pyopencl it was only change of value in debian/compat.

(and a build-dependency bump in debian/control)

It's (almost) always a trivial change to the source package.  The reason
it's frowned upon is that it has the potential to lead to unanticipated
changes in the binary packages.

> > +    * Depend on libnvidia-compiler instead of transitional libnvidia-compiler1
> > +    * Build-depend on nvidia-libopencl1 and khronos-opencl-headers
> > +      instead of nvidia-libopencl1-dev
> > 
> > These don't correspond to the changes actually made.  Both
> > libnvidia-compiler and khronos-opencl-headers are added as non-default
> > alternatives, rather than replacing the previous packages (which is just
> > as well, given that libnvidia-compiler isn't in testing and
> > khronos-opencl-headers isn't in the archive at all).
> 
> Changed to:
>     * Added alternative dependency to help with post-Squeeze changes
>       in NVIDIA driver packages
>     * Added alternative build-dependency on nvidia-libopencl1
>       and khronos-opencl-headers instead of nvidia-libopencl1-dev
>       which will be removed from NVIDIA driver packages after Squeeze

That's better, although for Squeeze the changes are no-ops.

> > To be entirely honest, given that the package has only ever had one
> > upload (in July) and has no reverse-dependencies I'm not sure right now
> > whether fixing it or removing it from testing would be the best
> > solution.
> 
> I would like to fix it.
> Ubuntu 10.10 contains python-pyopencl.
> In scientific community GPGPU is gaining momentum (I do not have
> statistical proof, but it seems when looking at articles).
> IMO having at least one OpenCL implementation and supporting
> libraries would make Debian more attractive.

Having an implementation that's not widely tested (popcon reports a
total of six installations, fwiw) also has the potential to have
precisely the opposite effect, I suspect.

If people are particularly interested in things that are "gaining
momentum" whilst a new release of any distribution is in progress then
isn't the likelihood that they'll either use newer versions of the
distribution or at least supplement the base with much more up-to-date
backports?

Regards,

Adam