Bug#995829: ITP: itk5 -- extensive suite of software tools for image analysis

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Vaillant 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-...@lists.debian.org

* Package name: itk5
  Version : 5.2.1
  Upstream Author : NumFOCUS
* URL : https://itk.org
* License : Apache-2.0
  Programming Lang: C++, Python
  Description : extensive suite of software tools for image analysis

This package is a core dependency for a large array of medical packages.

This package will be maintained by the Debian Med Packaging Team.

Bug#976622: ITP: python3-oscrypto -- cryptography library for Python

[Ghislain Vaillant]

Use python-oscrypto (as in Python the language) or just oscrypto for the
source package name.

Use python3-oscrypto for the name of the binary package installing the
module for Python 3.

Le dim. 6 déc. 2020 à 01:18, Joseph Nahmias  a écrit :

> Package: wnpp
> Severity: wishlist
>
> * Package name: python3-oscrypto
>   Version : 1.2.1
>   Upstream Author : Will Bond 
> * URL : https://github.com/wbond/oscrypto
> * License : MIT
>   Programming Lang: Python
>   Description : cryptography library for Python
>
> TLS (SSL) sockets, key generation, encryption, decryption, signing,
> verification and KDFs using the OS crypto libraries. Does not require a
> compiler, and relies on the OS for patching. Works on Windows, OS X and
> Linux/BSD.
>
> I plan to maintain this under the Debian Python Team.
>
> Used by a number of cross-platform projects including for verifying
> LineageOS
> builds.
>
>

Bug#887747: ITP: gnome-shell-extension-easyscreencast -- video recording extension for the GNOME shell

[Ghislain Vaillant]

Le lun. 1 oct. 2018 à 05:42, Samuel Henrique  a
écrit :

> Hello everyone,
>
> I see that the last email here is from January 21th, so I decided to
> myself package gnome-shell-extension-easyscreencast,
>

You did well.

>
> It is almost ready at salsa[0], it just need a final review of d/copyright
> to check if there were new copyright holders added on the new release. I
> did not committed under gnome's team organization, but I can do so if asked
> (I didn't because I don't know if this is what the team wants).
>

If you want the package to be under team maintenance, you should.

>
> Please let me know if you've made any progress on your package, if you
> want to do any changes on top of mine or if you want to co-maintain it.
>
> If there's no opinions against, I will do the upload soon.
>

Please go ahead. Thank you for taking care of it.

>
> Thanks,
>
> [0]https://salsa.debian.org/debian/gnome-shell-extension-easyscreencast
>
> --
> Samuel Henrique 
>

Bug#903136: RFP: spyder-kernels -- Jupyter kernels for the Spyder console

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist

* Package name: spyder-kernels
  Version : 1.0.1
  Upstream Author : Spyder Development Team
* URL : https://github.com/spyder-ide/spyder-kernels
* License : Expat
  Programming Lang: Python
  Description : Jupyter kernels for the Spyder console

Long-Description:
 Package that provides the kernels used by Spyder on its IPython
 console.
 .
 Spyder is the Scientific Python Development Environment.

Spyder-kernels is a required dependency for spyder>=3.3. I would suggest
to co-maintain this package wit the Debian Science Team wherein spyder
and its plugins are currently located.

Bug#892758: ITP: python-bsdf -- Python implementation of the Binary Structured Data Format

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Vaillant <ghisv...@gmail.com>

* Package name: python-bsdf
  Version : 2.1.1
  Upstream Author : Almar Klein
* URL : http://bsdf.io/
* License : BSD
  Programming Lang: Python
  Description : Python implementation of the Binary Structured Data Format

Long-Description:
 The Binary Structured Data Format (BSDF) is an open specification for
 serializing (scientific) data, for the purpose of storage and (inter
 process) communication.
 .
 It's designed to be a simple format, making it easy to implement in
 many programming languages. However, the format allows implementations
 to support powerful mechanics such as lazy loading of binary data, and
 streamed reading/writing.
 .
 BSDF is a binary format; by giving up on human readability, BSDF can be
 simple, compact and fast. See the full specification, or how it
 compares to other formats.

This library is a new dependency for src:python-imageio. It will be
maintained by the Debian Science Team.

Bug#888075: Switch to ITA

[Ghislain Vaillant]

Control: owner -1 !
Control: retitle -1 ITA: csvkit

I intend to adopt csvkit and transfer its maintenance to the Debian
Science Team together with the agate stack it depends on.

Cheers,
Ghis

Bug#887747: RFP: gnome-shell-extension-easyscreencast -- video recording extension for the GNOME shell

[Ghislain Vaillant]

Control: owner -1 !
Control: retitle -1 ITP: gnome-shell-extension-easyscreencast -- video 
recording extension for the GNOME shell 

I have successfully built a local version of the package using the
initial work done by the Kali team [1]. I intend to base the initial
packaging on that and improve it to the Debian packaging standards.

I'd like it to be maintained under the umbrella of the Debian GNOME
team (cc'd). Anyone from the team, could you please accept my request
to join the group on salsa, so I can push and start a formal review.

[1] 
http://git.kali.org/gitweb/?p=packages/gnome-shell-extension-easyscreencast.git;a=summary

Cheers,
Ghis

On Fri, 19 Jan 2018 16:10:47 + Ghislain Vaillant <ghisv...@gmail.co
m> wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: gnome-shell-extension-easyscreencast
>   Version : 0.10
>   Upstream Author : Tobias Schönberg
> * URL : https://github.com/EasyScreenCast/EasyScreenCast
> * License : GPL-3
>   Programming Lang: JavaScript
>   Description : video recording extension for the GNOME shell
> 
> Long-Description:
>  This extension simplifies the use of the video recording function
>  integrated in gnome shell, allows quickly to change the various
>  settings of the desktop recording.

Bug#887747: RFP: gnome-shell-extension-easyscreencast -- video recording extension for the GNOME shell

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist

* Package name: gnome-shell-extension-easyscreencast
  Version : 0.10
  Upstream Author : Tobias Schönberg
* URL : https://github.com/EasyScreenCast/EasyScreenCast
* License : GPL-3
  Programming Lang: JavaScript
  Description : video recording extension for the GNOME shell

Long-Description:
 This extension simplifies the use of the video recording function
 integrated in gnome shell, allows quickly to change the various
 settings of the desktop recording.

Bug#860768: Switch from ITP to RFP

[Ghislain Vaillant]

Control: retitle -1 RFP: python-ordered-set
Control: noowner -1

On Wed, 19 Apr 2017 21:47:25 +0100 Ghislain Antony Vaillant 
 wrote:

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 

* Package name: python-ordered-set
  Version : 2.0.2
  Upstream Author : Luminoso Technologies, Inc.
* URL : https://github.com/LuminosoInsight/ordered-set/
* License : Expat
  Programming Lang: Python
  Description : ordered set implementation for Python

This package is a dependency for sphinxcontrib-bibtex. It will be
co-maintained by the DPMT.


sphinxcontrib-bibtex no longer needs this ITP to be fulfilled, as the 
dependency on ordered-set can be substituted with sortedcollections, 
which is already packaged.


Ghis

Bug#879050: Reopened

[Ghislain Vaillant]

Control: reopen -1 !

Please have a closer look at #700960. This is not the same piece of 
software as this ITP.


If anything, #700960 should have been merged with #542166 and closed as 
a result.


Ghis

Bug#852138: theano 0.9 ready for upload

[Ghislain Vaillant]

H Rebecca,

On 30/09/17 15:38, Rebecca N. Palmer wrote:
In Alioth (e49f225, not tagged as my other package's sponsor prefers not 
doing that until upload).


Note that my hardware can't run the GPU tests due to #877316, so it 
might be a good idea for someone else to do so before upload.


Thanks for the heads-up,

I thought Theano v0.9.x would require libgpuarray 0.7.x? Or is that for 
the future (and probably last) 1.0 version? Please let me know if you 
have further pieces of information.


Ghis

Bug#875432: s/python3-sphinx-intl/sphinx-intl

[Ghislain Vaillant]

On 12/09/17 14:07, Hideki Yamane wrote:

On Mon, 11 Sep 2017 16:48:17 +0100
Ghislain Vaillant <ghisv...@gmail.com> wrote:

Please consider changing the source package name to sphinx-intl. Based
on the description of the source package, it will produce a stand-alone
utility not a Python library.


  Thanks for your comment, I've chosen it since sphinx as python3-sphinx
  package. Is sphinx-intl better?


The python3- prefix is for binary packages only (alongside python- and 
pypy-).


Should you decide to use a prefix for the source package name, it should 
be python-, not python3-. Since sphinx-intl is intended to be used as a 
utility, not a library, I suggested you to just name the source package 
sphinx-intl and the corresponding binary packages sphinx-intl / 
sphinx-intl-doc.


Ghis

Bug#875432: s/python3-sphinx-intl/sphinx-intl

[Ghislain Vaillant]

Please consider changing the source package name to sphinx-intl. Based 
on the description of the source package, it will produce a stand-alone 
utility not a Python library.


Cheers,
Ghis

Bug#810788: Preparing a package of openshot-qt

[Ghislain Vaillant]

On 27/08/17 09:31, Dr. Tobias Quathamer wrote:

control: owner -1 !
control: retitle -1 ITP: openshot-qt -- high quality video editing and 
animation solutions

Dear Ghislain,

I'd like to try to tackle the packaging of openshot-qt. Do you have any
repository with your work you've done so far? The repository on
 seems to
be empty.


Hi Tobias,

I'll push my initial work rebased onto the latest version some time this 
week. Thanks for taking over.


Ghis

Bug#810788: OpenShot up for adoption

[Ghislain Vaillant]

Dear all,

I have just filed #872902 and #872904 to give up the Openshot stack for 
adoption. I need to prioritize my existing work on the Debian Science 
and Python teams and did not find the time necessary for completing the 
packaging for openshot-qt (now under RFP).


To whom who would be willing to take this over, I would say the most 
difficult part has been done (the packaging of the backend libraries 
libopenshot-audio and libopenshot). The frontend part is a Python 
application (openshot-qt) with some embedded Javascript libraries.


A word of caution however. First, I'd recommend to keep the whole stack 
in experimental until the application is thoroughly tested. There was a 
point where I had everything working, but the application looked pretty 
bad for some reason. Another warning concerns the tendency of upstream 
to break the API / ABI on every release, so consider doing updates in 
batches staged in experimental first.


I'll be happy to assist anyone who'd be willing to step up.

Best regards,
Ghis

Bug#655420: ITP: jtransforms -- A multithreaded FFT library written in pure Java

[Ghislain Vaillant]

On 20/08/17 15:25, Andreas Tille wrote:>

please consider packaging this in either Debian Science or pkg-java
team.


I'd recommend the Java Team for this one and read Markus' tutorial for 
maven [1] before debianizing. The source package should be named 
libjtransforms-java.


[1] 
http://collab.debian.net/portal/planet-debian/markus-koschany-pdfsam-how-to-upgrade-a-maven-application-for-debian


Ghis

Bug#852138: RFA: theano -- CPU/GPU math expression compiler for Python

[Ghislain Vaillant]

Hi Rebecca,

On Mon, 20 Mar 2017 22:47:49 + "Rebecca N. Palmer"  wrote:
> Control: retitle -1 ITA: theano -- CPU/GPU math expression compiler
for 
> Python
> 
> As previously suggested[0], I intend to adopt this (and probably 
> libgpuarray as well, though that's not a promise at this point).

I took care of libgpuarray: it is updated to the latest upstream
release and there is now an autopkgtest suite running.

> I am a debian-science team member, but not a DD.

Me neither. Daniel has been really helpful in reviewing and sponsoring
updates of his former packages so far.

> Upstream just released 0.9; should I start packaging that on Alioth? 
> (though no hurry to actually upload it, since both Debian and Ubuntu
are 
> currently frozen...)
> 
> [0] https://lists.debian.org/debian-science/2017/02/msg00030.html

Do you mind if I kickstart this effort then? I'd be happy to co-
maintain the Theano stack with you under the Debian Science Team
umbrella, unless you object to it.

Please let me know.

Cheers,
Ghis

Bug#860969: ITA: pybtex -- BibTeX-compatible bibliography processor

[Ghislain Vaillant]

On Sat, 2017-07-22 at 16:00 +0200, Daniel Stender wrote:
> Note: the package is going to move over to Debian-Science, a new Git
> repo has been
> installed already: https://anonscm.debian.org/git/debian-science/pack
> ages/pybtex.git
> 
> DS

Thanks Daniel for moving the package. An update for it is coming super
soon ;-)

Cheers,
Ghis

Bug#852137: Switch from RFA to ITA

[Ghislain Vaillant]

control: owner -1 !
control: retitle -1 ITA: libgpuarray -- library to manipulate tensors on the GPU

Bug#859879: (no subject)

[Ghislain Vaillant]

Hi Gordon, thanks for your interest for this package,

On 05/06/17 22:19, Gordon Ball wrote:

This is also a blocker for updating jupyter-notebook -> 5.0.


Has an appropriate blocking relationship [1] been added?

https://www.debian.org/Bugs/server-control#block


I have prepared a rough package:

https://git.chronitis.net/xterm.js/

The package could use some more tidying and testing, but should build
both the typescript part and a python script (crudely) emulates the
browserify part.


I already worked with a fellow Debian contributor (cc'd) on a packaging
back in version 2.5.0, we just did not find the time to finalize it. I
have updated our work for version 2.7.0 and requested him to upload it.

The packaging repository can be found here:

https://anonscm.debian.org/git/pkg-javascript/node-xterm.git/

Best regards,
Ghis

Bug#740296: Switch from RFP to ITP

[Ghislain Vaillant]

control: retitle -1 ITP: simpleitk -- cross-platform image analysis

Bug#740296: Switch from RFP to ITP

[Ghislain Vaillant]

control: owner -1 !
control: retitle ITP: simpleitk -- cross-platform image analysis toolkit

I have been iterating with upstream to get SimpleITK in a easier
packaging state. I believe it is now in a state where we can start
producing something.

The packaging of each wrapper will happen on a per-request basis, as I
don't have enough knowledge about all the languages covered by
SimpleITK to make them happen at once. For now, I intend to focus on
the common C++ core and the Python wrapper.


On Sun, 29 Jan 2017 07:48:24 +0100 Gert Wollny <gw.foss...@gmail.com>
wrote:
> Am Samstag, den 28.01.2017, 15:48 + schrieb Ghislain Vaillant:
> > What is the status of your packaging effort for simpleitk?
> I never got past early tests to compile it. At that time I had a
> certain interest in the package but that veined. 
> 
> > 
> > This bug was switched back to RFP in 2014. 
> Actually, it was not really "switched back", but only the title was
> corrected because the original submitter didn't set the proper name. 
> 
> > Please confirm whether you are still working on it.
> I'm not working on it. 
> 
> Best, 
> Gert  

Bug#863605: ITP: python-pyserial -- serial port access library in Python

[Ghislain Vaillant]

On Mon, 2017-05-29 at 10:32 +0200, Julien Cristau wrote:
> On 05/29/2017 10:22 AM, Ghislain Antony Vaillant wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Ghislain Antony Vaillant 
> > 
> > * Package name: python-pyserial
> >   Version : 3.3
> >   Upstream Author : Chris Liechti 
> > * URL : https://github.com/pyserial/pyserial
> > * License : BSD
> >   Programming Lang: Python
> >   Description : serial port access library in Python
> > 
> > Long-Description:
> >  This module encapsulates the access for the serial port. It provides
> >  backends for Python running on Windows, OSX, Linux, BSD (possibly any
> >  POSIX compliant system) and IronPython. The module named "serial"
> >  automatically selects the appropriate backend.
> > 
> > This package is a dependency to src:python-pymeasure. It will be
> > co-maintained by the Debian Science Team.
> > 
> 
> Sounds like this duplicates the existing python-serial package.
> 
> Cheers,
> Julien

Correct, thanks for spotting it.

Ghis

Bug#840034: RFA -> ITA

[Ghislain Vaillant]

control: owner -1 !
control: retitle -1 ITA: python-latexcodec -- LaTeX lexer and codec library for 
Python

I intend to help maintaining this package as part of my effort to
package sphinxcontrib-bibtex.

Ghis

Bug#861646: ITP: reprounzip -- Linux tools for reproducible experiments

[Ghislain Vaillant]

On Tue, 2017-05-02 at 15:14 -0400, Rémi Rampin wrote:
> 2017-05-02 15:05 EDT, Ghislain Vaillant <ghisv...@gmail.com>:
> > Thanks for clarifying. Just out-of-curiosity, why is the tracer
> > restricted to x86?
> 
> There is no technical limitation here, I would just have to write the
> system call map [1] for other platforms (and find a CI service I can
> test it on). It might be implemented in a future version, it is just
> not there yet.

I can offer to build and test the package for linux-any achitectures
instead of just (amd64, i386). This way you'll have access to our logs
if you want to do some testing.

> > Would you prefer "on Linux platforms" instead?
> 
> What about "Tool for reproducing Linux experiments"?
> 
> 
> [1]: 
> https://github.com/ViDA-NYU/reprozip/blob/b759459f60290756859af0b2f87c634353294e53/reprozip/native/syscalls.c#L901

Since we are struggling with where to put Linux (I don't think this
iteration is good either), why not just dropping it altogether:

"Tool for reproducing scientific experiments"

And leave the details to the long description.

Bug#861646: ITP: reprounzip -- Linux tools for reproducible experiments

[Ghislain Vaillant]

On Tue, 2017-05-02 at 12:55 -0400, Rémi Rampin wrote:
> 2017-05-02 12:11 EDT, Ghislain Vaillant:
> > Do you mean Linux the kernel or the platform? The tracer would not work
> > on a non-Linux kernel such as FreeBSD or the Hurd, am I right?
> 
> The tracer requires a Linux kernel, and currently only supports x86 and 
> x86_64.

Thanks for clarifying. Just out-of-curiosity, why is the tracer
restricted to x86? 

> > Since the tool itself targets reproducible experiments *on* Linux, but
> > is not specific *to* Linux, what about "Tool for reproducing
> > experiments on Linux"?
> 
> This makes it sound like you can only re-run the experiments if you're
> using Linux.

Well first, reprozip usage is restricted to Linux, and reprounzip
requires some form of Linux runtime to execute the experiment. So, I
believe the short description is quite accurate.

Besides, keep in mind that there is also a long description associated
with it, which I took verbatim from PyPI.

Would you prefer "on Linux platforms" instead?

Bug#861646: ITP: reprounzip -- Linux tools for reproducible experiments

[Ghislain Vaillant]

On Tue, 2017-05-02 at 09:54 -0400, Rémi Rampin wrote:
> 2017-05-02 05:44 -0400, Ghislain Vaillant:
> > Each tool is registered as a separate download on pip and are versioned
> > separately. Based on that alone, I guess it makes more sense to provide
> > separate source packages too.
> 
> Hi, ReproZip author here.
> 
> To give some context, the tools are packaged independently because
> they have different requirements (in particular, reprozip only works
> on Linux, but reprounzip works on other platforms where Docker and
> Vagrant are available).

Do you mean Linux the kernel or the platform? The tracer would not work
on a non-Linux kernel such as FreeBSD or the Hurd, am I right? 

> 2017-05-02 07:51 -0400, Holger Levsen:
> > And you should very probably remove the word "Linux" from the short 
> > description,
> > and maybe also s#reproducible#reproducing#…
> 
> We don't actually use this description anywhere I could find. The
> packages are collectively labelled as "Linux tool enabling
> reproducible experiments". Let me know if I missed something.

I guess Holger was trying to come up with a more accurate short
description of the package. 

Since the tool itself targets reproducible experiments *on* Linux, but
is not specific *to* Linux, what about "Tool for reproducing
experiments on Linux"?

Ghis

Bug#861646: ITP: reprounzip -- Linux tools for reproducible experiments

[Ghislain Vaillant]

On Tue, 2017-05-02 at 11:51 +, Holger Levsen wrote:
> On Tue, May 02, 2017 at 11:18:35AM +0100, Ghislain Vaillant wrote:
> > > and how is it different from zip? (or tar|gzip)
> > > those can also be used to (un)pack reproducible archives…
> > 
> > The unpacking step includes fetching the necessary dependencies, and
> > spawning a run of the experiment (locally, or on Vagrant / Docker)
> > automatically.
> 
>  
> ah! I think something along the lines should be added to the description.
> 
> And you should very probably remove the word "Linux" from the short 
> description,
> and maybe also s#reproducible#reproducing#…

Good point. I'll forward your suggestion upstream. 

Ghis

Bug#861646: ITP: reprounzip -- Linux tools for reproducible experiments

[Ghislain Vaillant]

On Tue, 2017-05-02 at 10:07 +, Holger Levsen wrote:
> On Tue, May 02, 2017 at 11:04:48AM +0100, Ghislain Vaillant wrote:
> > In a nutshell, take a scientific experiment (data + processing
> > pipeline), create a single archive out of it (packing step), and enable
> > a different machine to reproduce the experiment (unpacking step).
> 
> and how is it different from zip? (or tar|gzip)
> 
> those can also be used to (un)pack reproducible archives…

The unpacking step includes fetching the necessary dependencies, and
spawning a run of the experiment (locally, or on Vagrant / Docker)
automatically.

It's a step forward compared to providing a tar with code and data +
custom deployment script, which researchers are usually quite terrible
at writing.

Ghis

Bug#861646: ITP: reprounzip -- Linux tools for reproducible experiments

[Ghislain Vaillant]

On Tue, 2017-05-02 at 09:53 +, Holger Levsen wrote:
> On Tue, May 02, 2017 at 10:44:49AM +0100, Ghislain Vaillant wrote:
> I still wonder what these tools exactly do, though ;-)

In a nutshell, take a scientific experiment (data + processing
pipeline), create a single archive out of it (packing step), and enable
a different machine to reproduce the experiment (unpacking step).

Ghis

Bug#861646: ITP: reprounzip -- Linux tools for reproducible experiments

[Ghislain Vaillant]

On Tue, 2017-05-02 at 09:31 +, Holger Levsen wrote:
> unmerge 860531
> 
> On Tue, May 02, 2017 at 10:18:00AM +0100, Ghislain Vaillant wrote:
> > > a few days ago you already filed an ITP bug for this package?!!
> > 
> > No, reprozip != reprounzip (one is the packer, the other is the
> > unpacker).
> 
> aha! 
> 
> I didnt notice because those two bugs have
> - an identical upstream URL
> - an identical description
> - actually everything identical except for the package name

TBH, I have been a bit lazy on that one. I could have made the
distinction much more explicit.

> Does this really need to packages?

The whole ReproZip project is a collection of utilities, including
reprozip, reprounzip and reprounzip plugins for Vagrant and Docker.

Each tool is registered as a separate download on pip and are versioned
separately. Based on that alone, I guess it makes more sense to provide
separate source packages too.

> > Please undo the merge. Thanks.
> 
> done.

Cheers, sorry again for the confusion.

Ghis

Bug#860969: Switching to ITA

[Ghislain Vaillant]

control: owner -1 !
control: retitle -1 ITA: pybtex -- BibTeX-compatible bibliography processor

On Sat, 22 Apr 2017 22:42:13 +0200 Daniel Stender  
wrote:
> I request an adopter for the pybtex package.

I intend to help maintaining this package as part of my effort to
package sphinxcontrib-bibtex, which pybtex is a dependency of.

Ghis

Bug#800358: Switching to ITP

[Ghislain Vaillant]

control: owner -1 !
control: retitle -1 ITP: sphinxcontrib.bibtex -- Sphinx extension for BibTeX 
style citations

Bug#801307: Switching to ITP

[Ghislain Vaillant]

control: owner -1 !
control: retitle -1 IFP: pybtex-docutils -- docutils backend for pybtex

As part of the packaging effort for sphinxcontrib-bibtex.

Bug#859879: Switching to ITP

[Ghislain Vaillant]

control: retitle -1 ITP: node-xterm -- terminal front-end component for the 
browser
control: owner -1 !

Bug#859880: Add blocking bugs

[Ghislain Vaillant]

control: block -1 by 780187
control: block -1 by 859879

Bug#850448: Sponsering python-agate

[Ghislain Vaillant]

On 22/03/17 11:48, Andreas Tille wrote:

Hi Ghislain,

is there any reason why you have set target distribution to
experimental?  If it is just because of the freeze that does not make
sense since new packages are not in Squeeze anyway so there is no need
to let bugfixes pass by via unstable while new development is in
experimental.


One of the dependencies (python3-parsedatetime) in only available in 
experimental (I contributed the Python 3 packaging after the freeze 
unfortunately).


[1] https://packages.debian.org/experimental/python3-parsedatetime

The whole python-agate* ecosystem is here to serve the next update of 
csvkit, which will also happen in experimental anyway. After the freeze, 
both csvkit and python-agate* should migrate to unstable together, I 
suppose.


Ghis

Bug#850448: Switching from RFP to ITP

[Ghislain Vaillant]

control: owner -1 !
control: retitle -1 ITP: python-agate -- data analysis library that is 
optimized for humans instead of machines

Hi Sandro,

I'll have a look at it and check the other deps for csvkit.

Cheers,
Ghis

Bug#800358: Add blocking RFPs

[Ghislain Vaillant]

control: block -1 by 801306
control: block -1 by 801307

Bug#777069: Switching from RFP to ITP

[Ghislain Vaillant]

control: owner -1 !
control: retitle -1 ITP: python-line-profiler -- line-by-line profiling for 
Python

I would like to take over the following RFP.

This library is a dependency to the upcoming spyder-line-profiler
plugin for the spyder IDE. This package will be co-maintained by the
Debian Python Modules Team.

On Wed, 04 Feb 2015 18:04:40 +0100 Pietro Battiston  
wrote:
> * Package name: line-profiler
>   Version : 1.0
>   Upstream Author : Robert Kern
> * URL : https://pypi.python.org/pypi/line_profiler/
> * License : Python
>   Programming Lang: Python
>   Description : Line-by-line profiling for Python

Cheers,
Ghis

Bug#740296: SimpleITK

[Ghislain Vaillant]

What is the status of your packaging effort for simpleitk?

This bug was switched back to RFP in 2014. Please confirm whether you
are still working on it.

Thanks,
Ghis

Bug#798331: Back to RFA

[Ghislain Vaillant]

control: retitle -1 RFA: sundials -- SUit of Nonlinear and 
DIfferential/ALgebraic equation Solvers
control: noowner -1

Someone was already on it, but did not follow the package adoption
guidelines. Switching back to RFA, so that whoever is currently in
charge can communicate his work.

Ghis

Bug#798331: Switching to ITA

[Ghislain Vaillant]

control: owner -1 !
control: retitle ITA: sundials -- SUit of Nonlinear and DIfferential/ALgebraic 
equation Solvers

I'll look into it. Looks like we could use this opportunity to migrate
the packaging from svn to git, in accordance with the Debian Science
packaging policy.

Ghis

Bug#851444: ITP: python-xarray -- N-D labeled arrays and datasets in Python

[Ghislain Vaillant]

control: block -1 by 851520

Bug#851444: ITP: python-xarray -- N-D labeled arrays and datasets in Python

[Ghislain Vaillant]

control: block -1 by 851444

Bug#851806: ITP: libmseed2 -- seed (Standard for the Exchange of Earthquake Data) data records manipulation library

[Ghislain Vaillant]

On Thu, 2017-01-19 at 13:56 +0100, Andreas Tille wrote:
> On Thu, Jan 19, 2017 at 09:53:29AM +0000, Ghislain Vaillant wrote:
> > You may seek sponsorship by either uploading the source package to mentors
> > and filing an RFS bug, or posting your RFS request on the d-science
> > mailing-list with a link to the corresponding git repository.
> 
> I'd be up for sponsoring if the package is in Debian Science Git following
> Debian Science policy:
> 
>https://debian-science.alioth.debian.org/debian-science-policy.html
>  
> > If these attempts are not fruitful (remember we are mostly focusing on
> > finalizing Stretch, so new packages are low-priority these days), then you
> > can add an entry to the SoB page [1].
> 
> I admit I'm wondering into what task this package might belong -
> suggestions?

A geology-dev task perhaps? ObsPy, which I mentioned earlier, would
fall into that category too.


> > Unless Andreas is already on it? I would also be happy to review the
> > packaging but cannot upload.
> 
> Ghislain, I'd welcome your review before it gets on my table for
> sponsering.

Super. Then I'll wait for Pierre to send me a link to the repo.


> Kind regards
> 
>   Andreas.
>  
> > [1] https://wiki.debian.org/DebianPureBlends/SoB
> > 
> > Cheers,
> > Ghis
> > 
> > 
> > On 19/01/17 09:46, Pierre Duperray wrote:
> > > well the package is in shape, I think I'm not allowed to upload it.
> > > Where should I send it for review? I though I had
> > > 
> > > to wait a mentor declare himself for that?
> > > 
> > > 
> > > Cheers
> > > 
> > > Pierre
> > > 
> > > 
> > > On 01/19/2017 10:42 AM, Ghislain Vaillant wrote:
> > > > Let me also add that this library is necessary for python-obspy, which
> > > > I might get back to packaging at some point later.
> > > > 
> > > > So, thanks Pierre for taking care of this. Let the team know if you
> > > > need any assistance.
> > > > 
> > > > Ghis
> > > > 
> > > > 
> > > > On 19/01/17 08:00, Andreas Tille wrote:
> > > > > Hi Pierre,
> > > > > 
> > > > > thanks for the ITP.  I think this package should be done in the Debian
> > > > > Science team.
> > > > > 
> > > > > Kind regards
> > > > > 
> > > > >  Andreas.
> > > > > 
> > > > > On Wed, Jan 18, 2017 at 11:21:32PM +0100, Pierre Duperray wrote:
> > > > > > Package: wnpp
> > > > > > Severity: wishlist
> > > > > > Owner: Pierre Duperray <pierreduper...@free.fr>
> > > > > > 
> > > > > > * Package name: libmseed2
> > > > > >  Version : 2.18
> > > > > >  Upstream Author : Chad Trabant <c...@iris.washington.edu>
> > > > > > * URL :
> > > > > > http://ds.iris.edu/ds/nodes/dmc/software/downloads/libmseed/
> > > > > > * License : LGPL3
> > > > > >  Programming Lang: C
> > > > > >  Description : seed data records manipulation library
> > > > > > 
> > > > > > Provides a framework for manipulation of SEED (Standard for the
> > > > > > Exchange
> > > > > > of Earthquake Data) data records.
> > > > > > 
> > > > > > I think this package is relevant because it is a reference
> > > > > > implementation of
> > > > > > the SEED format manipulation. It will be a dependency on other
> > > > > > packages allowing,
> > > > > > for instance, realtime exchange of seismic data around the world.
> > > > > > I use these tools on a daily basis, no other package provide this
> > > > > > functionality
> > > > > > (as far as I know).
> > > > > > I plan to maintain this package and create other sismological
> > > > > > related package,
> > > > > > as a maintainer beginner, I definitively need a sponsor.
> > > > > > My work on this package basically consisted in learning packaging,
> > > > > > autotoolizing
> > > > > > the upstream source distribution. I plan to submit autotoolizing
> > > > > > patch and man page
> > > > > > typos patch upstream. I will also ask the upstream author if he his
> > > > > > interested
> > > > > > in co-maintaining this package.
> > > > > > 
> > > > > > 
> > 
> > 
> 
> 

Bug#851806: ITP: libmseed2 -- seed (Standard for the Exchange of Earthquake Data) data records manipulation library

[Ghislain Vaillant]

You may seek sponsorship by either uploading the source package to 
mentors and filing an RFS bug, or posting your RFS request on the 
d-science mailing-list with a link to the corresponding git repository.


If these attempts are not fruitful (remember we are mostly focusing on 
finalizing Stretch, so new packages are low-priority these days), then 
you can add an entry to the SoB page [1].


Unless Andreas is already on it? I would also be happy to review the 
packaging but cannot upload.


[1] https://wiki.debian.org/DebianPureBlends/SoB

Cheers,
Ghis


On 19/01/17 09:46, Pierre Duperray wrote:

well the package is in shape, I think I'm not allowed to upload it.
Where should I send it for review? I though I had

to wait a mentor declare himself for that?


Cheers

Pierre


On 01/19/2017 10:42 AM, Ghislain Vaillant wrote:

Let me also add that this library is necessary for python-obspy, which
I might get back to packaging at some point later.

So, thanks Pierre for taking care of this. Let the team know if you
need any assistance.

Ghis


On 19/01/17 08:00, Andreas Tille wrote:

Hi Pierre,

thanks for the ITP.  I think this package should be done in the Debian
Science team.

Kind regards

  Andreas.

On Wed, Jan 18, 2017 at 11:21:32PM +0100, Pierre Duperray wrote:

Package: wnpp
Severity: wishlist
Owner: Pierre Duperray <pierreduper...@free.fr>

* Package name: libmseed2
  Version : 2.18
  Upstream Author : Chad Trabant <c...@iris.washington.edu>
* URL :
http://ds.iris.edu/ds/nodes/dmc/software/downloads/libmseed/
* License : LGPL3
  Programming Lang: C
  Description : seed data records manipulation library

Provides a framework for manipulation of SEED (Standard for the
Exchange
 of Earthquake Data) data records.

I think this package is relevant because it is a reference
implementation of
the SEED format manipulation. It will be a dependency on other
packages allowing,
for instance, realtime exchange of seismic data around the world.
I use these tools on a daily basis, no other package provide this
functionality
(as far as I know).
I plan to maintain this package and create other sismological
related package,
as a maintainer beginner, I definitively need a sponsor.
My work on this package basically consisted in learning packaging,
autotoolizing
the upstream source distribution. I plan to submit autotoolizing
patch and man page
typos patch upstream. I will also ask the upstream author if he his
interested
in co-maintaining this package.

Bug#851806: ITP: libmseed2 -- seed (Standard for the Exchange of Earthquake Data) data records manipulation library

[Ghislain Vaillant]

Let me also add that this library is necessary for python-obspy, which I 
might get back to packaging at some point later.


So, thanks Pierre for taking care of this. Let the team know if you need 
any assistance.


Ghis


On 19/01/17 08:00, Andreas Tille wrote:

Hi Pierre,

thanks for the ITP.  I think this package should be done in the Debian
Science team.

Kind regards

  Andreas.

On Wed, Jan 18, 2017 at 11:21:32PM +0100, Pierre Duperray wrote:

Package: wnpp
Severity: wishlist
Owner: Pierre Duperray 

* Package name: libmseed2
  Version : 2.18
  Upstream Author : Chad Trabant 
* URL : http://ds.iris.edu/ds/nodes/dmc/software/downloads/libmseed/
* License : LGPL3
  Programming Lang: C
  Description : seed data records manipulation library

Provides a framework for manipulation of SEED (Standard for the Exchange
 of Earthquake Data) data records.

I think this package is relevant because it is a reference implementation of
the SEED format manipulation. It will be a dependency on other packages 
allowing,
for instance, realtime exchange of seismic data around the world.
I use these tools on a daily basis, no other package provide this functionality
(as far as I know).
I plan to maintain this package and create other sismological related package,
as a maintainer beginner, I definitively need a sponsor.
My work on this package basically consisted in learning packaging, autotoolizing
the upstream source distribution. I plan to submit autotoolizing patch and man 
page
typos patch upstream. I will also ask the upstream author if he his interested
in co-maintaining this package.

Bug#849477: ITP: python-pydap -- a Python library implementing the Data Access Protocol

[Ghislain Vaillant]

On Tue, 2016-12-27 at 11:12 -0500, Sandro Tosi wrote:
> On Tue, Dec 27, 2016 at 10:57 AM, Ghislain Antony Vaillant
>  wrote:
> > 
> > * Package name: python-pydap
> >   Version : 3.2.0
> >   Upstream Author : Roberto De Almeida 
> > * URL : http://www.pydap.org/
> 
> 
> how does it compare to https://packages.qa.debian.org/p/pydap.html?

We had a discussion a while back on the DPMT mailing-list [1].
Basically, pydap 3.x is a non-backward compatible rewrite of pydap 2.x.

Both can be installed side by side since they use different namespaces
(dap for pydap 2.x, pydap for pydap 3.x). Hence the introduction of a
new source package to avoid difficult upgrades for pydap 2.x rdepends.

[1] https://lists.debian.org/debian-python/2016/01/msg00139.html

Ghis

Bug#835367: ITP: voro++, progress on this ITP

[Ghislain Vaillant]

Hi Roger and the debian-astro team,

Could you please let me know what is your status on this ITP? I have a
package using an embedded copy of voro++ which would benefit from your
work.

Best regards,
Ghis

Bug#849050: ITP: python-graphviz -- Simple Python 3 interface for Graphviz

[Ghislain Vaillant]

>> Package: wnpp
>> Severity: wishlist
>> Owner: Diane Trout 
>> 
>> * Package name: python-graphviz
>>   Version : 0.5.2
>>   Upstream Author : Sebastian Bank
>> * URL : https://github.com/xflr6/graphviz
>> * License : Expat
>>   Programming Lang: Python
>>   Description : Simple Python 3 interface for Graphviz
>
> This naming would be unacceptable. Python 3 package should be named
> as "python3-foobar", not "python-foobar".

I completely disagree, "python-graphviz" is the appropriate name for
the source package.

It would produce a python3-graphviz binary package for the Python 3
build and a python-graphivz-doc for the documentation package.  

> There are already packages called "python{,3}-pygraphviz" and you may
> want to take a look.

There are different Python packages for graphviz [1]. Diane already had
a look at it I believe.

[1] https://pypi.python.org/pypi?%3Aaction=search=graphviz=
search

Ghis

Bug#817777: dask package for Debian.

[Ghislain Vaillant]

Hi Diane,

On Tue, 13 Dec 2016 20:44:58 -0800 Diane Trout  wrote:

Hello,

I've built a packaging for dask (#847497), dask.distributed (#847524)
and all of their required currently unpackaged dependencies. I'm
currently working on creating the git repositories and uploading them
to NEW.


What is the current status?


I don't have packages for s3fs, flexx, or jupyter notebook.


What would these be required for? Would you need assistance packaging those?


I have a non Debian policy compliant package for bokeh, but that's
probably going to stay stuck as I don't know how to deal with building
the javascript library.


Do you have a link to the current packaging nonetheless? That may still 
be a better starting point than from scratch.


Cheers,
Ghis

Bug#769767: changed to ITP

[Ghislain Vaillant]

control: retitle -1 ITP: python-imageio -- library for reading and writing 
image data
control: owner -1 !

On Sat, 12 Nov 2016 13:42:55 -0500 Yaroslav Halchenko  
wrote:
> imageio is used by 0.7 release (yet to see if optional) of  pysurfer, so
> would be cool to get it into debian.

I am currently working with Almar Klein to get imageio into a suitable 
packaging state.

So Hopefully, we could get something soon.

Bug#808264: blocked by new upstream release

[Ghislain Vaillant]

Control: block -1 by 838908

The aim is to have ArrayFire 3.4.x in the archive first before working
on this.

Ghis

Bug#794552: blocked by khronos-opencl-clhpp

[Ghislain Vaillant]

Control: block -1 by 837112

Bug#730670: switching from RFP to ITP

[Ghislain Vaillant]

control: owner -1 !
control: retitle -1 ITP: python-cartopy - cartographic Python library

Cartopy is a soft dependency to hdf-compass. I'll have a go at it.

I intend to maintain it under the Debian Science Team umbrella, unless
the Debian GIS Team is interested in it.

Ghis

Bug#825954: (no subject)

[Ghislain Vaillant]

control: retitle -1 RFP: obspy -- Python framework for seismology

Bug#825954: switching from ITP to RFP

[Ghislain Vaillant]

control: noowner -1
control: retitle RFP: obspy -- Python framework for seismology

obspy is currently affected by a licensing incompatibility.

Switching this ITP to RFP until this issue is fixed.

Ghis

Bug#794553: switching from ITP to RFP

[Ghislain Vaillant]

control: noowner -1
control: retitle -1 RFP: clrng

Bug#810254: vtk7: switched from ITP to RFP

[Ghislain Vaillant]

control: noowner -1
control: retitle -1 RFP: vtk7 -- Visualization Toolkit (VTK) version 7

I am hereby withdrawing my intent to package VTK 7.

Anyone interested to work on VTK 7 for Stretch, feel free to step up
and assign yourself to this bug.

Cheers,
Ghis

Bug#825954: ITP on hold due to licensing issue

[Ghislain Vaillant]

This ITP is now on hold due to a licensing problem discovered during
the copyright audit.

The issue is currently being discussed with upstream at:

  https://github.com/obspy/obspy/issues/1492

Best regards,
Ghis

Bug#736681: Adobe ADFKO is now free software!

[Ghislain Vaillant]

> Anyone want to package it?

I have had a look at it, and man this is a messy piece of software.

I'll see what I can come up with, and report my findings.

Ghis

Bug#832976: ITP: python-schema -- schema validation in Python

[Ghislain Vaillant]

Le 30 juil. 2016 2:26 PM, "Neil Williams"  a écrit :
>
> On Sat, 30 Jul 2016 13:54:11 +0100
> Ghislain Antony Vaillant  wrote:
>
> > Package: wnpp
> > Severity: wishlist
> > Owner: Ghislain Antony Vaillant 
> >
> > * Package name: python-schema
> >   Version : 0.6.2
> >   Upstream Author : Vladimir Keleshev 
> > * URL : https://github.com/keleshev/schema
> > * License : Expat
> >   Programming Lang: Python
> >   Description : schema validation in Python
> >
> > Long-Description:
> >  Schema is a library for validating Python data structures, such as
> > those obtained from config-files, forms, external services or
> > command-line parsing, converted from JSON/YAML (or something else) to
> > Python data-types.
> >
> > This package will be co-maintained by the Debian Python Modules Team.
>
> Isn't this much the same as the existing python-voluptuous package? A
> quick look at the README doesn't show anything that voluptuous can't do.
>
> --
>
>
> Neil Williams
> =
> http://www.linux.codehelp.co.uk/
>

Could be. Although, this is the package advertised and used by
python-docopt.

Not sure if voluptuous is mentioned.

Ghis

Bug#823436: switch from RFP to ITP

[Ghislain Vaillant]

control: owner -1 !
control: retitle -1 "ITP: python-prov -- W3C Provenance Data Model 
supporting PROV-JSON and PROV-XML"


I am on it.

Ghis

Bug#649623: status of python-freetype packaging

[Ghislain Vaillant]

Hi Daniel,

Any news on this? Do you need any help?

Ghis

Bug#821008: ITP: pyfr -- flux reconstruction in Python

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: pyfr
  Version : 1.3.0
  Upstream Author : Imperial College London
* URL : http://www.pyfr.org/
* License : BSD
  Programming Lang: Python
  Description : flux reconstruction in Python

Long-Description
 PyFR is an open-source Python based framework for solving 
advection-diffusion

 type problems on streaming architectures using the Flux Reconstruction
 approach of Huynh. The framework is designed to solve a range of governing
 systems on mixed unstructured grids containing various element types. 
It is
 also designed to target a range of hardware platforms via use of an 
in-built

 domain specific language derived from the Mako templating engine.

This package will be co-maintained by the Debian Science Team.

Bug#819157: r/bitstruct/python-bitstruct?

[Ghislain Vaillant]

Hi Brian, thanks for working on this package.

May I suggest to rename the source package to python-bitstruct as it
seems to be the (unofficial) convention for Python-only library.

FYI, we already have python-bitarray and python-bitstring available in
the archive. Perhaps, it would be nice to emphasize what makes this
library different for the other two, although I understand that the
motivation behind this packaging effort is to satisfy a Build-Depends.

Cheers,
Ghis

Bug#812761: Comments regarding your packaging plans for flif

[Ghislain Vaillant]

Hi Jon, how's the packaging going?

My remarks below:

> The source package would have multiple binary packages:
> - flif (command line tool)
> - libflif (shared library)
> - viewflif (simple image/animation viewer)
> - gif2flif (shell script)
> - apng2flif (shell script)

I would recommend the following layout, based on my experience:
- libflif0 (shared library)
- libflif-dev (development files)
- flif-doc (documentation)
- flif-tools or flif-bin or flif (tools and scripts)

No-need to split the tools package further, I believe. Otherwise, your
package would introduce a new binary package everytime a new script is
introduced, which would unnecessarily delay the upload to the archive.

> I am trying to put all necessary Debian packaging config files
> directly in the upstream git repository, at:
> https://github.com/FLIF-hub/FLIF

This practice is discouraged. Please don't embed the Debian packaging
files in the upstream repository. You might want to maintain them in a
separate branch instead for the time being. Have a look at what I have
done with field3d:

  https://anonscm.debian.org/cgit/pkg-phototools/field3d.git

> I hope to have flif included in the Debian archive when this release
> will be announced.

Well, this is up-to you and the quality of your packaging work.

> it would help to have a more experienced co-maintainer who can check
> and improve my effort at packaging.

Consider joining the phototools team and host your packaging repository
there, so that experienced maintainers like me can interact directly.

Good luck,
Ghislain

Bug#818983: ITP: ciftilib -- library for reading and writing CIFTI files

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Ghislain Antony Vaillant 

* Package name: ciftilib
  Version : 1.3
  Upstream Author : Washington University School of Medicine
* URL : https://github.com/Washington-University/CiftiLib
* License : BSD
  Programming Lang: C++
  Description : library for reading and writing CIFTI files

Long-Description:
 CIFTI (Connectivity Informatics Technology Initiative) standardizes
 file formats for the storage of connectivity data. These formats are
 developed by the Human Connectome Project and other interested parties.
 .
 CiftiLib is a C++ library for reading and writing CIFTI-2 files. It
 additionally supports CIFTI-1 files, for both on-disk and in-memory
 access. It also provides C++ code for reading and writing generic
 NIfTI-1 and NIfTI-2 files.

This package will be maintained by the Debian Med Team.

Bug#816290: RFP: elusive-icons -- the iconic font and CSS framework

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist

* Package name: elusive-icons
  Version : 2.0.0
  Upstream Author : The Redux Team
* URL : http://elusiveicons.com/
* License : SIL OFL 1.1, Expat
  Programming Lang: Text + CSS
  Description : the iconic font and CSS framework

Long-Description:
 Elusive Icons is a full suite of 304 pictographic icons for easy scalable
 vector graphics on websites, created and maintained by Team Redux.

Rationales:
 The fonts provided by this source package are required for the
 python-qtawesome source package, which currently uses an embedded copy.

Bug#814908: ITP: python-hdf5storage -- high-level utilities to read from and write to HDF5

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 

* Package name: python-hdf5storage
  Version : 0.1.12
  Upstream Author : Freja Nordsiek
* URL : https://github.com/frejanordsiek/hdf5storage
* License : BSD
  Programming Lang: Python
  Description : high-level utilities to read from and write to HDF5

This package uses h5py as a driver to provide a higher-level API to
interact with files saved in HDF5 format, including MATLAB v7.3. The
package will be co-maintained by the Debian Science Team, where h5py
currently resides.

Bug#814718: ITP: python-qtawesome -- iconic fonts in PyQt and PySide applications

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 

* Package name: python-qtawesome
  Version : 0.2.0
  Upstream Author : The Spyder development team
* URL : https://github.com/spyder-ide/qtawesome
* License : Expat
  Programming Lang: Python
  Description : iconic fonts in PyQt and PySide applications

This package is a build dependency for future releases of the Spyder
IDE.

Bug#814721: ITP: python-qtpy -- abtraction layer for PySide/PyQt4/PyQt5

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 

* Package name: python-qtpy
  Version : 1.0b1
  Upstream Author : Gonzalo Peña-Castellanos
* URL : https://github.com/spyder-ide/qtpy
* License : Expat
  Programming Lang: Python
  Description : abtraction layer for PySide/PyQt4/PyQt5

This package will become a build dependency for future releases of the 
Spyder IDE.

Bug#768772: What is the status of the packaging ?

[Ghislain Vaillant]

Any news from this submission ?

Ghis

Bug#808611: Build of JUCE without vendored dependencies.

[Ghislain Vaillant]

Hi Iohannes,

I tried to build libopenshot-audio with the vendored JUCE version but 
disabling its respective vendored dependencies, which you list in the 
TODO.Debian in the JUCE packaging repository.


This is how far I went, and hope it will be useful. FYI, I believe the 
version of JUCE embedded in OpenShot is partial, so I did not have to 
deal with all the dependencies you listed.


These are the dependencies that were successfully substituted with the 
system ones, with their corresponding CFLAGS and LDFLAGS:


flac:
FLAC_CFLAGS = -DJUCE_INCLUDE_FLAC_CODE=0 $(shell pkg-config --cflags flac)
FLAC_LDFLAGS = $(shell pkg-config --libs flac)

libjpeg:
JPEG_CFLAGS = -DJUCE_INCLUDE_JPEGLIB_CODE=0 $(shell pkg-config --cflags 
libjpeg)

JPEG_LDFLAGS = $(shell pkg-config --libs libjpeg)

libpng:
PNG_CFLAGS = -DJUCE_INCLUDE_PNGLIB_CODE=0 -DPNG_SKIP_SETJMP_CHECK 
$(shell pkg-config --cflags libpng)

PNG_LDFLAGS = $(shell pkg-config --libs libpng)

vorbis:
VORBIS_CFLAGS = -DJUCE_INCLUDE_OGGVORBIS_CODE=0 $(shell pkg-config 
--cflags vorbis)

VORBIS_LDFLAGS = $(shell pkg-config --libs vorbis)

zlib:
ZLIB_CFLAGS = -DJUCE_INCLUDE_ZLIB_CODE=0 $(shell pkg-config --cflags zlib)
ZLIB_LDFLAGS = $(shell pkg-config --libs zlib)

+ patch (provided) to replace the z-prefixed zlib types with non 
z-prefixed ones, because the symbols aren't defined apparently in the 
system zlib which Debian provides. The patch might be to be adapted for 
your source layout.


Good luck.

Cheers,
Ghis
From: Ghislain Antony Vaillant 
Date: Tue, 19 Jan 2016 16:31:57 +
Subject: Use non z-prefixed zlib types.

---
 .../modules/juce_core/zip/juce_GZIPCompressorOutputStream.cpp   | 4 ++--
 .../modules/juce_core/zip/juce_GZIPDecompressorInputStream.cpp  | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/JuceLibraryCode/modules/juce_core/zip/juce_GZIPCompressorOutputStream.cpp b/JuceLibraryCode/modules/juce_core/zip/juce_GZIPCompressorOutputStream.cpp
index f1db2b4..ee4afcf 100644
--- a/JuceLibraryCode/modules/juce_core/zip/juce_GZIPCompressorOutputStream.cpp
+++ b/JuceLibraryCode/modules/juce_core/zip/juce_GZIPCompressorOutputStream.cpp
@@ -87,8 +87,8 @@ private:
 {
 stream.next_in   = const_cast  (data);
 stream.next_out  = buffer;
-stream.avail_in  = (z_uInt) dataSize;
-stream.avail_out = (z_uInt) sizeof (buffer);
+stream.avail_in  = (uInt) dataSize;
+stream.avail_out = (uInt) sizeof (buffer);
 
 const int result = isFirstDeflate ? deflateParams (, compLevel, strategy)
   : deflate (, flushMode);
diff --git a/JuceLibraryCode/modules/juce_core/zip/juce_GZIPDecompressorInputStream.cpp b/JuceLibraryCode/modules/juce_core/zip/juce_GZIPDecompressorInputStream.cpp
index 88d49a3..b929580 100644
--- a/JuceLibraryCode/modules/juce_core/zip/juce_GZIPDecompressorInputStream.cpp
+++ b/JuceLibraryCode/modules/juce_core/zip/juce_GZIPDecompressorInputStream.cpp
@@ -126,8 +126,8 @@ public:
 {
 stream.next_in  = data;
 stream.next_out = dest;
-stream.avail_in  = (z_uInt) dataSize;
-stream.avail_out = (z_uInt) destSize;
+stream.avail_in  = (uInt) dataSize;
+stream.avail_out = (uInt) destSize;
 
 switch (inflate (, Z_PARTIAL_FLUSH))
 {
@@ -136,7 +136,7 @@ public:
 // deliberate fall-through
 case Z_OK:
 data += dataSize - stream.avail_in;
-dataSize = (z_uInt) stream.avail_in;
+dataSize = (uInt) stream.avail_in;
 return (int) (destSize - stream.avail_out);
 
 case Z_NEED_DICT:

Bug#810788: ITP: openshot-qt -- high quality video editing and animation solutions

[Ghislain Vaillant]

Dear Gregor and Jonas,

> Is this about packaging the new 2.x series separately?

Yes indeed. The rationales for it is that Jonathan (the upstream developer),
already provides different source packages in respective PPAs for 1.x [1]
and 2.x [2].

[1] https://launchpad.net/~openshot.developers/+archive/ubuntu/daily
[2]
https://launchpad.net/~openshot.developers/+archive/ubuntu/libopenshot-daily

So it would make things easier for him, assuming he wants to rebase his PPAs
on top of the Debian packages, if the packages available in Debian were to
keep
the same naming convention.

> Please strongly consider coordinate with openshot maintainer, e.g. to
> maybe ship an openshot-common package with reusable parts.

Already done. Jonathan also happens to be the Debian maintainer of the
current
openshot package. He is happy to have someone managing this over on the
Debian
side.

> You might also - both of you - consider joining the Debian Multimedia
> team :-)

Great suggestion. I will send a request to join in and ask Jonathan.

Best regards,
Ghis

Bug#808611: JUCE is also a build dependency for OpenShot 2.x

[Ghislain Vaillant]

Hi Iohannes,

Just to add that the recently released version of OpenShot 2.x requires
JUCE as a build dependency (libopenshot-audio). Right now, it is using
an embedded copy, which is not desirable from a packaging perspective.

Have you had any success in packaging JUCE so far? Please let me know of
your progress.

Cheers,
Ghis

Bug#808264: ITP: arrayfire-cuda -- CUDA backend for ArrayFire

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 

* Package name: arrayfire-cuda
  Version : 3.2.1
  Upstream Author : ArrayFire Development Group 
* URL : http://arrayfire.com/
* License : BSD
  Programming Lang: C++
  Description : CUDA backend for ArrayFire

Long Description:
 ArrayFire is a high performance software library for parallel computing
 with an easy-to-use API. Its array based function set makes parallel
 programming simple.
 .
 ArrayFire's multiple backends (CUDA, OpenCL and native CPU) make it
 platform independent and highly portable.
 .
 A few lines of code in ArrayFire can replace dozens of lines of
 parallel computing code, saving you valuable time and lowering
 development costs.

This package will be maintained by the Debian Science Team.

Bug#777043: Shark / libshark packaging status

[Ghislain Vaillant]

I have pushed the repository to d-science and filed an RFS for the 
initial upload of Shark.


If someone could have a look at it and sponsor it, that would be awesome.

Thanks,
Ghis

Bug#777043: Shark / libshark packaging status

[Ghislain Vaillant]

I think I know. I must have involuntarily pushed to ftp-master instead 
of ftp-mentors yesterday when I tried to fix an incomplete upload to 
mentors.


It happened before with Gianfranco and I believe he had to manually dcut 
the package from ftp-master before uploading.


Ghis

On 11/12/15 07:22, Andreas Tille wrote:

Hi Ghislain,

I've tried an upload this morning but it was rejected for reasons I do
not understand.  Need to check this when I might sit behind a faster
connection again.  I'm perfectly fine if somebody else might beat me in
this (as always).

Kind regards

Andreas.

On Thu, Dec 10, 2015 at 08:00:18PM +, Ghislain Vaillant wrote:

I have pushed the repository to d-science and filed an RFS for the initial
upload of Shark.

If someone could have a look at it and sponsor it, that would be awesome.

Thanks,
Ghis

Bug#777043: Shark / libshark packaging status

[Ghislain Vaillant]

On 30/11/15 12:42, Goswin von Brederlow wrote:

Go ahead and work on. I packaged this as it was a dependency for
something one of our customers wanted but interest seems to have been
reduced since then. So I'm happy passing this on to someone else.

MfG
Goswin



Thanks for passing this on to me. Is there any further action to take on 
this ITP as a result ?


Ghis

Bug#777043: Shark / libshark packaging status

[Ghislain Vaillant]

On 01/12/15 10:33, Andreas Tille wrote:

On Tue, Dec 01, 2015 at 09:24:12AM +, Ghislain Vaillant wrote:


Thanks for passing this on to me. Is there any further action to take on
this ITP as a result ?


Uploading? :-P


Which might be happening soon, upstream has been very responsive to my 
initial packaging feedback.


Once again, I will require some of your sponsorship magic when the time 
comes ;-)


Ghis

Bug#804612: Requires upload of bazel first

[Ghislain Vaillant]

According to the installation instructions [1], bazel is required to 
build TensorFlow. There is an ITP currently filed for bazel [2].


[1] 
https://github.com/tensorflow/tensorflow/blob/master/tensorflow/g3doc/get_started/os_setup.md

[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782654

On a separate note, this package would be a great candidate for 
maintenance by the Debian Science Team. I might give it a go if bazel 
gets uploaded eventually.


Ghis

Bug#777043: Anyone still working on this ITP?

[Ghislain Vaillant]

Is anyone still working on this ITP?

Otherwise, I am happy to start working on it and have shark maintained 
under Debian Science.


Thanks for letting me know.

Ghis

Bug#801971: ITP: opengm -- C++ template library for discrete factor graph models

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 

* Package name: opengm
  Version : 2.0.2
  Upstream Author : The OpenGM Developers 


* URL : http://hci.iwr.uni-heidelberg.de/opengm2/
* License : MIT
  Programming Lang: C++, Python
  Description : C++ template library for discrete factor graph models

OpenGM is a C++ template library for discrete factor graph models and
distributive operations on these models. It includes state-of-the-art
optimization and inference algorithms beyond message passing. OpenGM 
handles large models efficiently, is modular and extendible. The 
graphical model data structure, inference algorithms and different 
encodings of functions inter-operate through well-defined interfaces. 
The binary OpenGM file format is based on the HDF5 standard and 
incorporates user extensions automatically.


This package will be maintained by the Debian Science Team.

Best regards,
Ghis

Bug#768936: Fwd: Bug#768936: nufft: switch from ITP to RFP

[Ghislain Vaillant]

retitle 768936 RFP: nufft -- Library implementing the Non-Uniform Fast
Fourier Transform
noowner 768936
thanks

Bug#761202: pnfft: switch from ITP to RFP

[Ghislain Vaillant]

retitle 761202 RFP: pnfft -- Parallel NFFT software library based on MPI
noowner 761202
thanks

Bug#768936: nufft: switch from ITP to RFP

[Ghislain Vaillant]

retitle 768936 RFP: nufft -- Library implementing the Non-Uniform Fast 
Fourier Transform

noowner 768936
thanks

Bug#761201: Fwd: Bug#761201: pfft: switch from ITP to RFP

[Ghislain Vaillant]

retitle 761201 RFP: pfft -- Parallel FFT software library based on MPI
noowner 761201
thanks

Bug#761201: pfft: switch from ITP to RFP

[Ghislain Vaillant]

retitle 761201 RFS: pfft -- Parallel FFT software library based on MPI
noowner 761201
thanks

Bug#799001: ITP: python-arrayfire -- Python bindings for ArrayFire

[Ghislain Vaillant]

On 15 Sep 2015 09:53, "Geert Stappers"  wrote:
>
> On Mon, Sep 14, 2015 at 09:35:42PM +0100, Ghislain Antony Vaillant wrote:
> > ArrayFire is a high performance library for parallel computing wih an
> > easy-to-use API.
>
> s/computing wih an easy-to-use/computing with an easy-to-use/
>
> Write with with a t

Thanks for spotting this. Blind copy of upstream description.

Ghis

Bug#794553: ITP: clrng -- OpenCL random number generation library

[Ghislain Vaillant]

On 05/08/15 10:12, Bastien ROUCARIES wrote:

On Wed, Aug 5, 2015 at 11:06 AM, Ghislain Vaillant ghisv...@gmail.com wrote:

On 05/08/15 10:02, Bastien ROUCARIES wrote:

No idea. Taken from the upstream project description:

A library for uniform random number generation in OpenCL.

according to documentation: Currently, the library implements the
following three generators: MRG31k3p [4], MRG32k3a [7], LFSR113 [8]
and Philox-4×32-10 [11] .

So I think pseudo random according to title of publication...



Should I update the short description to:
OpenCL pseudo-random number generation library


Yes you should



Thanks for the recommendation, Bastien.

Will make sure this is done when I start working on the packaging.

Best regards,
Ghislain


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55c1d3e8.8030...@gmail.com

Bug#794553: ITP: clrng -- OpenCL random number generation library

[Ghislain Vaillant]

On 05/08/15 10:02, Bastien ROUCARIES wrote:

On Tue, Aug 4, 2015 at 12:49 PM, Ghislain Antony Vaillant
ghisv...@gmail.com wrote:

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant ghisv...@gmail.com

* Package name: clrng
   Version : 1.0.0
   Upstream Author : Advanced Micro Devices, Inc.
* URL : https://github.com/clMathLibraries/clRNG
* License : Apache version 2
   Programming Lang: C++
   Description : OpenCL random number generation library


Pseudo-random ? Please use only random for true random (cryptographic
quality) number



No idea. Taken from the upstream project description:

A library for uniform random number generation in OpenCL.

Should I update the short description to:

OpenCL pseudo-random number generation library

then ?

Cheers,
Ghis


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55c1d200.4040...@gmail.com

Bug#794649: ITP: compute -- cross-platform C++ library for GPU computing

[Ghislain Vaillant]

Package: wnpp
Owner: Ghislain Antony Vaillant ghisv...@gmail.com
Severity: wishlist

* Package name: compute
  Version : 0.4
  Upstream Author : Kyle Lutz kyle.r.l...@gmail.com
* URL : http://kylelutz.github.io/compute/
* License : Boost software license 1.0
  Programming Lang: C++
  Description : cross-platform C++ library for GPU computing

Long-Description:
 Boost.Compute is a GPU/parallel-computing library for C++ based on OpenCL.
 .
 The core library is a thin C++ wrapper over the OpenCL API and 
provides access

 to compute devices, contexts, command queues and memory buffers.
 .
 On top of the core library is a generic, STL-like interface providing 
common

 algorithms (e.g. transform(), accumulate(), sort()) along with common
 containers (e.g. vectorT, flat_setT). It also features a number of
 extensions including parallel-computing algorithms (e.g. exclusive_scan(),
 scatter(), reduce()) and a number of fancy iterators (e.g.
 transform_iterator, permutation_iterator, zip_iterator).

This package is required as a build-dependency to the OpenCL backend of 
ArrayFire, which CPU backend is already available in the main archive.


Boost.compute is expected to be part of release 1.59 of Boost. Having a 
separate package however is desirable from a backport perspective, since 
the library is header-only and compatible with Boost = 1.48. This has 
been discussed in length with the Debian Boost team, who eventually gave 
the green light to package it [1].


[1] 
http://lists.alioth.debian.org/pipermail/pkg-boost-devel/2015-July/003714.html


This package will be co-maintained by the Debian science team, alongside 
ArrayFire and its dependencies.


Best regards,
Ghislain


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55c1fa26.3050...@gmail.com

Bug#793139: ITP: python-dtcwt -- Dual-Tree Complex Wavelet Transform library for Python

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant ghisv...@gmail.com

* Package name : python-dtcwt
  Version : 0.10.1
  Upstream Author : Rich Wareham rich.git...@richwareham.com
* URL : https://github.com/rjw57/dtcwt
* License : BSD
  Programming Lang: Python
  Description : Dual-Tree Complex Wavelet Transform library for Python

This library provides support for computing 1D, 2D and 3D dual-tree 
complex wavelet transforms and their inverse in Python, along with a 
collection of DT-CWT algorithms and GPU acceleration.


In my opinion, this package is suitable for team-maintenance under 
Debian science.


Best regards,
Ghislain


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55ae75f5.8070...@gmail.com

Bug#785569: Work in progress in personal GitHub fork

[Ghislain Vaillant]

2015-05-18 20:46 GMT+01:00 Mathieu Malaterre ma...@debian.org:

 Hi Ghislain,

 On Mon, May 18, 2015 at 9:39 PM, Ghislain Vaillant ghisv...@gmail.com
 wrote:
  The CUDA backend should be more straightforward. Also, I am not sure
  whether it is more desirable to build the CUDA backend and have
  ArrayFire in contrib or stick with just CPU and OpenCL and have it in
  main.

 Please keep this package in main. Same thing happen in the past to
 libthrust. Having a package in contrib or non-free make it
 non-existant to lots of people.


I understand the reasoning, although a significant portion of the
scientific crowd still favours
CUDA over OpenCL. The case of libthrust is a bit of a non-issue now, since
it is a header-only
library so no build-deps on non-free components like the CUDA stack. On the
other hand,
ArrayFire would require the CUDA stack at build time.

Just add a quick documentation to README.Debian to build the CUDA backend.

 2cts


I am only interested in the CPU and OpenCL backend so far. This is a good
suggestion to provide
the steps to build the CUDA backend from the source package in a README.

Since some of the dependencies required to build the OpenCL backend are
missing, wouldn't it be
worth to submit the CPU backend first and later update the package with the
OpenCL binaries ?

I am intending to help with packaging clBLAS and clFFT (which Jerome
recently started working on I
believe), but these new packages will take quite some time to be reviewed
and uploaded to the main
archive, which would postpone the subsequent availability of ArrayFire in
Debian.

Additional comments / suggestions welcome :)

Ghis

Bug#785569: Work in progress in personal GitHub fork

[Ghislain Vaillant]

Progress of the packaging can be checked out at:
https://github.com/ghisvail/arrayfire/tree/debian

So far, the CPU backend builds fine and the packaging is lintian-free.
Testing required. I will then transfer the work to its Debian Science
repository.

The OpenCL backend requires additional dependencies (clBLAS, clFFT)
which are missing in Debian.

The CUDA backend should be more straightforward. Also, I am not sure
whether it is more desirable to build the CUDA backend and have
ArrayFire in contrib or stick with just CPU and OpenCL and have it in
main.

Cheers,
Ghislain


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1431977952.26995.6.ca...@gmail.com

Bug#781540: Please set Debian Science team as maintainer and yourself as uploader

[Ghislain Vaillant]

Completely forgot that, my bad.

Done.


Best regards,
Ghis

Bug#781540: ITP: bitstring -- Python module for manipulation of binary data

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant ghisv...@gmail.com

* Package name: bitstring
  Version : 3.1.3
  Upstream Author : Scott Griffiths sc...@griffiths.name
* URL : https://code.google.com/p/python-bitstring/
* License : MIT
  Programming Lang: Python
  Description : Python module for manipulation of binary data


Long Description


Bitstring is a pure Python module designed to help make the creation and
analysis of binary data as simple and natural as possible.

Bitstrings can be constructed from integers (big and little endian), hex,
octal, binary, strings or files. They can be sliced, joined, reversed,
inserted into, overwritten, etc. with simple functions or slice notation.
They can also be read from, searched and replaced, and navigated in,
similar
to a file or stream.


Reasons for packaging
-

This package brings simple support for arrays of bits, is well documented,
and works very well. It provides similar functionalities to bitarray
(already packaged) but does not require any compiled c-extension.


Due to the nature of this package, it should probably be team-maintained by
the Debian Python Modules Team (DPMT).


Best regards,
Ghislain

Bug#777000: ITP: limereg -- Lightweight Image Registration. Commandline application for image registration (automatically aligning two images with similar content).

[Ghislain Vaillant]

Added cc to debian-med.

I personally disagree with your statement on medical image registration. I
believe both fast and sophisticated registration tools can live together.
Your package would fit perfectly in d-science or d-med, if not both.

Regarding your naming scheme, I have nothing against it. However, if your
project becomes a large library associated with an executable, you might
want to consider using limereg (source package name), liblimereg (shared
object), liblimereg-dev (symlinks + headers), liblimereg-dbg (debug
symbols) and liblimereg-tools or liblimereg-bin (executables). Your call.

I would also suggest to finalize the separation between executable and
library first before doing the packaging.

Before actually finding a sponsor, you'd need to prepare the packaging
somewhere, in your personal or chosen debian team git repository for
instance, and make sure it is of sufficient quality for an upload (using
tools like Lintian). Then, you will file an RFS bug, which will point
prospective sponsors to the location of your packaging and give them
instructions on how to build and test the resulting binary packages.

Hope that helps.

Ghis


2015-02-10 15:35 GMT+00:00 Roelof Berg rb...@berg-solutions.de:

 Great, I really appreciate this. Thank you.

 I plan to contribute three packages. I hope, the naming scheme is correct:
 limereg: Commandline application for image registration (available)
 liblimereg: Shared object library for image registration (in development)
 liblimereg-dev: Headers etc. for development (in development)

 Then I plan to integrate liblimereg to more common software like
 Imagemagick, maye OpenCV (if I'll be allowed to - by the package owners and
 by my family - well, in fact my wife, who doesn't like me sitting at the
 laptop all the time  ;).

 I'm not sure which maintainer team would be better suited. It is meant for
 practical (!) application in all areas, from science over industrial
 automation up to end users. For medical image registration, however, it
 might be less suitable in many cases, because it is based on a very fast
 approach (ssd distance measure and linear interpolation), and in a medical
 setup usually more sophisticated (and probably more time consuming)
 approaches with a higher accuracy are used. I'm not sure if I will add
 these other algorithms (like ngf, spline ...) later. Well, maybe I will
 sometimes, because I'm working for a big medical device vendor in my
 daylight-life and just love this working field :)

 Anyway, I need a sponsor, if this shall become part of Debian.

 Regards,
 Roelof

 Von meinem Mobiltelefon gesendet.

  Am 10.02.2015 um 13:59 schrieb Andreas Tille andr...@an3as.eu:
 
  Hi Roelof,
 
  this sounds pretty interesting.  Since I see some scientific application
  I added limereg-dev (assuming that the development library will be named
  that way) to Debian Science imaging and Debian Med imaging-dev tasks.
 
  I wonder whether it might make sense to maintain the package inside the
  Debian Science team or alternatively the Debian Phototools team (both
  teams in CC)
 
  Kind regards and thanks for this interesting ITP
 
   Andreas.
 
  On Tue, Feb 03, 2015 at 11:42:22PM +0100, Roelof Berg wrote:
  Package: wnpp
  Severity: wishlist
  Owner: Roelof Berg rb...@berg-solutions.de
 
  * Package name: limereg
   Version : 1.1.0
   Upstream Author : Roelof Berg rb...@berg-solutions.de
  * URL : https://github.com/RoelofBerg/limereg
  * License : BSD
   Programming Lang: C++
   Description : Lightweight Image Registration. Commandline
 application for
  image registration (automatically aligning two images with similar
 content).
 
  I developed this application as part of a scientific project. It offers
 2D,
  grayscale, rigid image registration with a powerful
  derivative based approach and operates very fast and memory efficient
 (compared
  to traditional derivative-based aproaches).
 
  OpenCV is used to load and store the image data. The user can either
 output the
  registered image (image aligned/shifted/rotated upon another one)
  or it can output the numeric registration result (x-shift, y-shift and
  rotation).
 
  I want to develop this application further and want to maintain the .deb
  package. Furthermore
  I will publish the functionality as a library in an additional lib.deb
 and lib-
  dev.deb package.
  When the lib.deb package has been released I want to add it to
 imagemagik. This
  would enable people to register images just by using imagemagik :)
 
  I'm not aware of any other package offering image registration (if at
 all) in
  this speed and quality. Our mathematical aproach (regarding speed and
 memory
  usage) is very new and
  it is extremely unlikely that any other package can offer it. We just
 published
  it in a scientific magazine.
  Preprint: http://www.embedded-software-
  architecture.com/Berg2014Highly_Preprint.pdf
 
  Applications:
  HDR-Photograpy, Industrial