Re: PyViennaCL next upload

2014-05-06 Thread Toby St Clere Smithe
Hi Anton, Andreas,

Anton Gladky gl...@debian.org writes:
 as far as I know Andreas Tille proposed a nice and really necessary tool
 to exclude and repack source tarballs [1], [2] (CC-ing him). But, it seems,
 it is not yet in uscan (sorry, I may be wrong).

I have updated the source package as Thorsten suggested, having also
made a new bug-fix release upstream. Thanks to Andreas' work, it was
much easier than I had anticipated, needing only minor changes to
debian/copyright, debian/watch and debian/rules (the latter just to turn
off a warning produced by a build system check for the excluded files).

I apologise for the time wasted by my not realising this sooner!

Could you sponsor the new package? It is available on mentors [1], and
in git[2].

[1] 
http://mentors.debian.net/debian/pool/main/p/pyviennacl/pyviennacl_1.0.2+dfsg-1.dsc
[2] 
http://anonscm.debian.org/gitweb/?p=debian-science/packages/pyviennacl.git;a=shortlog;h=refs/tags/debian/1.0.2%2Bdfsg-1

 I would also strongly recommend you to implement autotests using DEP-8 [3].
 An example for python packages you can find here [4], [5]. Then your package
 will regularly be tested.

I agree that this would be nice. But, as things stand today, I don't
think it can work: PyViennaCL currently depends on OpenCL, and so any
tests would not run unless an OpenCL implementation was available, which
is (I think) not the case on the buildds. The only plausible free
implementations right now are Mesa, which is new and unstable (as well
as only really supported on r600g hardware), and beignet, which has
similar problems, and only supports Intel HD4000+ hardware (I believe).

Either when the OpenCL situation settles down or when I modify
PyViennaCL to support CPU-only computation, I will definitely implement
autopkgtests. Of course, in the CPU-only case, then the OpenCL code
paths (the raison-d'ĂȘtre of PyViennaCL!) will not be tested. In any
case, many thanks for the useful links.


Best regards,

-- 
Toby St Clere Smithe
http://tsmithe.net


-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: PyViennaCL package bug

2014-05-06 Thread Toby St Clere Smithe
Hi again,

sorry for the relentless e-mailing. This will be the last one for now
from me!

Toby St Clere Smithe m...@tsmithe.net writes:
 if you were planning on uploading pyviennacl 1.0.2 soon, please don't --
 there's a bug I want to fix first! I'll e-mail again when the package is
 ready.

I've fixed the bug (a minor issue with the build system) and have
uploaded the fixed packages to git and mentors -- the links are as
before, I believe.

Cheers,

-- 
Toby St Clere Smithe
http://tsmithe.net

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Re: Comments regarding pyviennacl_1.0.1-1_amd64.changes

2014-05-05 Thread Toby St Clere Smithe
Hi Thorsten,

(I lost power on my laptop, so lost your e-mail and have to reply like
this..)

If you have a look at debian/rules, you'll see that in fact I do use the
Debian-provided Boost. And there is a good reason why the source package
contains a subset of Boost: PyViennaCL is written for a general
scientific / academic audience, which may be using out of date
institutional systems, or systems that run Windows, or Mac OS X. In
these cases, it's very hard to be sure of having a functioning Boost
installation, and so the upstream sources contains the minimal subset of
Boost used by PyViennaCL.

Since the source package is built directly from these upstream sources
(no need to repackage, because the copyright situation is OK), it
includes these boost sources. But, as I say, they are not used in
building the Debian binaries, and are not installed on any Debian user's
computer.

Cheers,

-- 
Toby St Clere Smithe
http://tsmithe.net

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Re: Comments regarding pyviennacl_1.0.1-1_amd64.changes

2014-05-05 Thread Toby St Clere Smithe
Hi Thorsten,

Thorsten Alteholz alteh...@debian.org writes:
 On Mon, 5 May 2014, Toby St Clere Smithe wrote:
 Since the source package is built directly from these upstream sources
 (no need to repackage, because the copyright situation is OK),

 but in [1] there are other reasons mentioned to repackage.
 Removing 4200 files out of 4300 seems to be a good point for repacking, 
 doesn't it?
 And with this newly introduced handling via debian/copyright, it
 should not be that complex.

I know you have the final say here, but the same document[1], under
seciont 6.7.8.2 point 3 makes the converse point that the orig tarball
should, except where impossible for legal reasons, preserve the entire
building and portablility infrastructure provided by the upstream
author. For example, it is not a sufficient reason for omitting a file
that it is used only when building on MS-DOS.

The rationale given is that it is common for Debian users who need to
build software for non-Debian platforms to fetch the source from a
Debian mirror rather than trying to locate a canonical upstream
distribution point, which I agree with!

I'm not sure if the large number of files over-rides this point, but I'm
not sure the effort is worth it in any case: the boost files are small
(totalling only 38MB uncompressed, with a big compression ratio so that
any bandwidth used by the tarball is a fraction of that) and kept in a
self-contained subdirectory. Removing them would also complicate the
git-buildpackage workflow that I (and any co-maintainers) use, and of
course would mean maintaining a special get-orig-source rule, none of
which is strictly necessary.

But, of course, if you think it is imperative that they are removed,
then I shall do so!

[1] 
https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#repackagedorigtargz


Best regards,

-- 
Toby St Clere Smithe
http://tsmithe.net


-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


PyViennaCL next upload

2014-05-05 Thread Toby St Clere Smithe
Hi Anton,

further to the discussion earlier, over the next days I'm going to
collect together a couple of bug fixes, make a new upstream release, and
also do the repackaging. Then would you be happy to sponsor a new
upload?

Also, I would still like to learn more about this new tool that you and
Thorsten mentioned, if you have a link to some reading :-)

Cheers,

-- 
Toby St Clere Smithe
http://tsmithe.net


-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Re: Comments regarding pyviennacl_1.0.1-1_amd64.changes

2014-05-05 Thread Toby St Clere Smithe
Hi Thorsten,

Thorsten Alteholz alteh...@debian.org writes:
 On Mon, 5 May 2014, Toby St Clere Smithe wrote:
 I know you have the final say here, but the same document[1], under
 seciont 6.7.8.2 point 3 makes the converse point that the orig tarball
 should, except where impossible for legal reasons, preserve the entire
 building and portablility infrastructure provided by the upstream
 author. For example, it is not a sufficient reason for omitting a file
 that it is used only when building on MS-DOS.

 yes, this is true for stuff that is not already in the archive (like
 the MS-DOS build system). As you pointed out there is already an
 option to ignore the embedded copy of boost. So the building
 infrastructure is not harmed by removing boost.

Right.

 The rationale given is that it is common for Debian users who need to
 build software for non-Debian platforms to fetch the source from a
 Debian mirror rather than trying to locate a canonical upstream
 distribution point, which I agree with!

 But those users could also fetch the boost library from the Debian mirror.

This is also true.

 Anyway, the suggestion from Anton is fine and I marked the package for
 accept.

Thanks. I'll follow the advice for the next upload.


Cheers,

-- 
Toby St Clere Smithe
http://tsmithe.net

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Re: RFS: pyviennacl/1.0.1-1

2014-03-17 Thread Toby St Clere Smithe
Hi Anton,

Anton Gladky gl...@debian.org writes:
 why the repo is missing on alioth?
 http://anonscm.debian.org/gitweb/?p=debian-science/pyviennacl.git;a=summary

How silly of me! That's the wrong URL. It should be

  http://anonscm.debian.org/gitweb/?p=debian-science/packages/pyviennacl.git

I've fixed the control file, and uploaded a new version to mentors. It
might take a moment to appear.

Cheers,

Toby





 Anton


 2014-03-16 18:39 GMT+01:00 Toby St Clere Smithe tsmi...@ubuntu.com:
 (Resending the below to the list, since GMane seems to have chewed it...)



 -- Weitergeleitete Nachricht --
 From: Toby St Clere Smithe tsmi...@ubuntu.com
 To:
 Cc: Anton Gladky gl...@debian.org
 Date: Sun, 16 Mar 2014 16:49:27 +
 Subject: RFS: pyviennacl/1.0.1-1
 Hi Anton, everybody,

 Could someone sponsor my new package `pyviennacl`[1]? It provides Python
 bindings to the `viennacl` package, which I recently updated. It builds:

  python-pyviennacl - Python bindings for ViennaCL linear algebra library 
 (for Python 2)
  python3-pyviennacl - Python bindings for ViennaCL linear algebra library 
 (for Python 3)
  pyviennacl-doc - HTML documentation for PyViennaCL

 The dsc is at [1], and the packaging is in git on alioth[2][3].


 [1] 
 http://mentors.debian.net/debian/pool/main/p/pyviennacl/pyviennacl_1.0.1-1.dsc
 [2] git://git.debian.org/debian-science/packages/pyviennacl.git
 [3] http://git.debian.org/?p=debian-science/pyviennacl.git;a=summary

 Thanks,

 Toby

 --
 debian-science-maintainers mailing list
 debian-science-maintainers@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


RFS: pyviennacl/1.0.1-1

2014-03-16 Thread Toby St Clere Smithe
(Resending the below to the list, since GMane seems to have chewed it...)

---BeginMessage---
Hi Anton, everybody,

Could someone sponsor my new package `pyviennacl`[1]? It provides Python
bindings to the `viennacl` package, which I recently updated. It builds:

 python-pyviennacl - Python bindings for ViennaCL linear algebra library (for 
Python 2)
 python3-pyviennacl - Python bindings for ViennaCL linear algebra library (for 
Python 3)
 pyviennacl-doc - HTML documentation for PyViennaCL

The dsc is at [1], and the packaging is in git on alioth[2][3].


[1] 
http://mentors.debian.net/debian/pool/main/p/pyviennacl/pyviennacl_1.0.1-1.dsc
[2] git://git.debian.org/debian-science/packages/pyviennacl.git
[3] http://git.debian.org/?p=debian-science/pyviennacl.git;a=summary

Thanks,

Toby
---End Message---
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: viennacl_1.5.1-1_amd64.changes REJECTED

2014-03-04 Thread Toby St Clere Smithe
Hi Anton, Thorsten,

Anton Gladky gl...@debian.org writes:
 thanks for pointing that out! I have just uploaded fixed version.

Thanks for both of your work!


Cheers,

Toby



 2014-03-03 19:24 GMT+01:00 Thorsten Alteholz alteh...@debian.org:

 Hi Anton,


 On Mon, 3 Mar 2014, Anton Gladky wrote:

 could you please explain, whether the package was rejected
 or accepted? Could it be the problem because of fact, that
 package moved from contrib to main?


 while we are at it, the package needs to be removed from contrib and can
 than be accepted into main.

 Meanwhile you might have another look at the package. The license of
 doc\manual\IEEEtran_v1.13.bst is missing in debian/copyright. It would be
 also nice to mention the contribution of UChicago Argonne, LLC. Maybe you
 want to upload a new version ...

   Thorsten




-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Re: viennacl package

2014-02-19 Thread Toby St Clere Smithe
Hi Anton,

Anton Gladky gl...@debian.org writes:
 2013/12/26 Toby St Clere Smithe m...@tsmithe.net:
 Yes, I have. But I am waiting until I have made a 1.0.0 release until I
 finish the job. At the moment, it builds against an in-tree copy of the
 ViennaCL sources, and I hope this will be acceptable until either I or
 someone else has a chance to update the viennacl package to 1.5.0.

 Feel free to update viennacl package to 1.5.0 in VCS [1], prepare
 team upload and ping me.

 [1] http://git.debian.org/?p=debian-science/packages/viennacl.git

I have updated the package in VCS, and also uploaded to
mentors[2]. Could you also sponsor PyViennaCL[3]?

[2] http://mentors.debian.net/debian/pool/main/v/viennacl/viennacl_1.5.1-1.dsc
[3] 
http://mentors.debian.net/debian/pool/main/p/pyviennacl/pyviennacl_1.0.0-1.dsc

Many thanks,

Toby


-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers