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-med@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.

Re: dcm2niix -- I have an intent to take over (still under Debian Med team), objections?

[Ghislain Vaillant]

Le lun. 3 déc. 2018 à 22:39, Yaroslav Halchenko  a
écrit :

>
> On Mon, 03 Dec 2018, Andreas Tille wrote:
>
> > Hi Yaroslav,
>
> > On Mon, Dec 03, 2018 at 03:36:19PM -0500, Yaroslav Halchenko wrote:
>
> > > Chris asked me to take over maintenance in Debian as well, and Ghislain
> > > blessed me as well.
>
> > Fine for me.
>
> > > To minimize amount of work for myself, I would like
> > > to continue with NeuroDebian packaging, just polishing it up (copyright
> > > file and may be some cleanup).  How NeuroDebian packaging is
> > > different (dropping historical perspective) ATM it is at
> > > http://github.com/neurodebian/dcm2niix
>
> > Please do not do this.  The development platform for Debian packages is
> > salsa.debian.org and *lots* of QA tools are relying to find the
> packaging
> > code here.  I do not mind about the team but I mind a lot about the host
> > any Blends package can be found.
>
> I would be happy to move it to salsa.  I just pointed to it as the one
> we currently use
>
> I guess I would then move it to dcm2niix-epoch1 smth like that (on salsa
> i.e.) so previous versions could be found from the original
> dcm2niix repo (to which I would also add a commit obliterating
> everything and stating to look into that -epoch1 repo)
>

Please use the original packaging work on salsa and keep the history intact.

I don't see what would prevent you from rebasing the work done on
Neurodebian on top of mine. Epoch bumps don't justify history rewrites or
new repositories, imo.

Unless I misunderstood your intent. It's not 100% clear to me.

>
> > > - main difference is our git repo sitting on top of the upstream so we
> > >   also can produce an .orig. tarball with dcm_qa submodule which
> > >   provides data for testing of correct operation.  That increases the
> > >   tarball size but IMHO it is worth it!
>
> > I do not mind about the tarball size.
>
> I also didn't but current one (280MB) made me think... not sure yet what
> thoughts it would give ;)
>
> > > ... removed all agreeed upon ...
>
> > > Please let me know what you think
>
> > All those packaging details sound sensible but please, pretty
> > please stick to salsa.d.o.
>
> sure
>
> > Thank you for your work on this package
>
> Cheers!
> --
> Yaroslav O. Halchenko
> Center for Open Neuroscience http://centerforopenneuroscience.org
> Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
> Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
> WWW:   http://www.linkedin.com/in/yarik
>
>

Re: RFS: simpleitk/1.0.1-2

[Ghislain Vaillant]

Le dimanche 11 mars 2018 à 19:04 -0400, Afif Elghraoui a écrit :
> 
> على الأحد 11 آذار 2018 ‫16:04، كتب Afif Elghraoui:
> > 
> > 
> > على الأحد 11 آذار 2018 ‫14:04، كتب Ghislain Vaillant:
> > > Could someone upload simpleitk/1.0.1-2 [1], please?
> > 
> > I'll get it.
> > 
> 
> I'm getting this lintian error:
> 
> E: simpleitk source: missing-notice-file-for-apache-license NOTICE
> N:
> N:The package appears to be licensed under the Apache 2.0 license
> and a
> N:NOTICE file (or similar) exists in the source tree. However, no
> files
> N:called NOTICE or NOTICE.txt are installed in any of the binary
> packages.
> N:
> N:The Apache 2.0 license requires distributing of such files:
> N:
> N: (d) If the Work includes a "NOTICE" text file as part of its
> N: distribution, then any Derivative Works that You
> distribute must
> N: include a readable copy of the attribution notices
> contained
> N: within such NOTICE file [..]
> N:
> N:Please include the file in your package, for example by adding
> N:path/to/NOTICE to a debian/package.docs file.
> N:
> N:Refer to /usr/share/common-licenses/Apache-2.0 for details.
> N:
> N:Severity: serious, Certainty: possible
> N:
> N:Check: source-copyright, Type: source
> N:
> 
> Since the source hasn't changed, this must have been detected by new
> lintian rules. Can you please take a look?

Indeed, this Lintian error is brand new. *sigh*

I have updated the packaging to fix this and retagged.

Cheers,
Ghis

RFS: simpleitk/1.0.1-2

[Ghislain Vaillant]

Dear all,

Could someone upload simpleitk/1.0.1-2 [1], please?

Changes since last upload:

  * Cherry-pick upstream fix for FTBFS on i386.
Thanks to Adrian Bunk for reporting (Closes: #892459)
  * Point the VCS URIs to salsa.debian.org
  * Bump the debhelper version to 11
  * Bump the standards version to 4.1.3

[1] https://salsa.debian.org/med-team/simpleitk/tree/debian/1.0.1-2

Cheers,
Ghis

Access to salsa

[Ghislain Vaillant]

Dear all,

Could someone grant me (vaillant-guest) access to the team on salsa? I
am already a member.

Thanks,
Ghis

RFS: dcm2niix/1.0.20171215-1

[Ghislain Vaillant]

Hi team,

Could someone sponsor this update for dcm2niix [1]? Nothing much to
report besides an update to the latest upstream release and version
bumping for debhelper and standards.

It's already pushed and tagged to the packaging repository and has been
validated on debomatic.

[1] https://anonscm.debian.org/cgit/debian-med/dcm2niix.git

Thanks,
Ghis

Migration to salsa

[Ghislain Vaillant]

Hi team,

Are there any plans to migrate the team to salsa? What are the
blockers, if any?

Cheers,
Ghis

Re: ismrmrd FTBFS on armhf

[Ghislain Vaillant]

Le 17/12/17 à 15:40, Adrian Bunk a écrit :

On Sun, Dec 17, 2017 at 02:33:03PM +, Ghislain Vaillant wrote:

ISMRMRD uses a non-portable instruction (#pragma pack) which modifies the
memory alignment of its data structures. It seems neither armhf nor sparc64
supports it, hence the failure of the test suite for both architectures.


#pragma pack is supported everywhere,
and this pragma is the cause of the FTBFS.


Ack.


I am not sure what the best course of action is. Either leaving things as is
assuming a future rebuild with a newer compiler could improve it, disabling
the tests or even dropping the packages for the failing architectures.

Opinions welcome.


With #pragma pack you are forcing the compiler to do the wrong thing,
the only thing a newer compiler could possibly improve would be to
error on such code.


Ack.


Unaligned floating point access on armhf is expected to fail,
and that's exactly what happens here:
unknown location(0): fatal error: in 
"AcquisitionsTest/test_acquisition_header": memory access violation at address: 
0xbecd3b6a: invalid address alignment

Running the test in gdb confirms that this is floating point code.

sparc is generally unhappy with unaligned access:
unknown location(0): fatal error: in 
"AcquisitionsTest/test_acquisition_header": memory access violation at address: 
0x7feffb7c936: invalid address alignment

Note that even on architectures where unaligned access is permitted
it can be slower than aligned access.


So, what would be the right course of action moving forward? Removing 
the package for both armhf and sparc64?


Ghis

Re: ismrmrd FTBFS on armhf

[Ghislain Vaillant]

ISMRMRD uses a non-portable instruction (#pragma pack) which modifies 
the memory alignment of its data structures. It seems neither armhf nor 
sparc64 supports it, hence the failure of the test suite for both 
architectures.


I am not sure what the best course of action is. Either leaving things 
as is assuming a future rebuild with a newer compiler could improve it, 
disabling the tests or even dropping the packages for the failing 
architectures.


Opinions welcome.

Ghis

Re: src:mypy: Split public modules from mypy package

[Ghislain Vaillant]

Hi Michel,

Mypy cannot be updated to 0.550 in Debian atm, because our version of 
psutil is too low (bug filed).


Meanwhile, I have pushed an update (0.540-2) implementing the split of 
modules and command-line packages. I have also added a -doc package, 
since a trip to NEW was required anyway.


I have not focused on the tests too much yet. Upstream is using a weird 
format which pytest does not recognize. The runtests.py script they are 
using also yielded some obscure errors.


Could you push this update please?

https://anonscm.debian.org/cgit/debian-med/mypy.git

Thanks,
Ghis


On 30/10/17 16:42, Michael Crusoe wrote:
Perfect. With the faster releases schedule feel free to push a new 
release whenever!


I should add a README.source about wanting to get more of their tests 
under autopkgtest


(You can find a couples issues on their GitHub repository about this. My 
username here is mr-c)


Pe 30 oct. 2017 17:38, "Ghislain Vaillant" <ghisv...@gmail.com 
<mailto:ghisv...@gmail.com>> a scris:


No problem. Version 0.550 is just around the corner, so I'll take
the opportunity of a new release to implement the necessary changes.

Ghis


On 30/10/17 16:07, Michael Crusoe wrote:

Hey  Ghislain,

Thank you for bringing this issue to my attention. A great plan,
go for it!

Sorry for the delay, your email just now is the first I've seen
of this proposal.

Pe 30 oct. 2017 17:00, "Ghislain Vaillant" <ghisv...@gmail.com
<mailto:ghisv...@gmail.com> <mailto:ghisv...@gmail.com
<mailto:ghisv...@gmail.com>>> a scris:

     Hi Michael,

     Could you please acknowledge the following bug report I
recently
     raised for src:mypy, and whether you are happy with myself
     implementing the necessary change?

     I am a d-med member myself, but would rather ask first due
to the
     nature of the change. Plus, it will involve a trip to the
NEW queue.
     FYI, I am also implementing the same split for src:yapf,
which the
     Python language server is also depending on.

     Cheers,
     Ghis


     On Fri, 20 Oct 2017 10:59:35 +0100 Ghislain Antony Vaillant
     <ghisv...@gmail.com <mailto:ghisv...@gmail.com>
<mailto:ghisv...@gmail.com <mailto:ghisv...@gmail.com>>> wrote:

         Package: src:mypy
         Severity: wishlist

         Dear Michael,

         src:mypy currently produces a single binary package
providing
         both the
         main command line interface and the public modules.
However, the
         latter
         is a dependency of integration plugins for flake8
(flake8-mypy)
         and the
         Python language server (pyls-mypy), both of which are
in the
         process of
         being packaged.

         The Debian Python policy stipulates that public modules be
         provided in a
         separate binary package, or install standalone Python
         applications under
         /usr/share/${app} [1].

         Please consider packaging the public modules into a
separate
         python3-mypy binary package and have mypy depend on it.
If you can't
         find the time, I'd be happy to do it as I am also a
member of d-med.

         [1]

https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html

<https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html>

<https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html


<https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html>>

         Cheers,
         Ghis

         -- System Information:
         Debian Release: stretch/sid
            APT prefers artful
            APT policy: (500, 'artful')
         Architecture: amd64 (x86_64)
         Foreign Architectures: i386

         Kernel: Linux 4.13.0-16-generic (SMP w/8 CPU cores)
         Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8
(charmap=UTF-8),
         LANGUAGE=en_GB:en (charmap=UTF-8)
         Shell: /bin/sh linked to /bin/dash
         Init: systemd (via /run/systemd/system)

Re: RFS: simpleitk/1.0.1-1 [ITP]

[Ghislain Vaillant]

Hi Afif, thanks for taking care of the review (and uploading dcm2niix).

On 02/11/17 02:05, Afif Elghraoui wrote:

Based on the Python policy, the python3-dev build-dependency should be
either python3-all-dev, or specific to a minor version of python3 (like
python3.5-dev) [2].


Since the build system does not let me easily build against all 
supported Python 3 versions, a dependency on python3-dev makes more 
sense than python3-all-dev. I have seen this done many times in other 
CMake-based build of packages.



My reading of the BuildProfileSpec wiki page suggests to me that the
`googletest` build dependency should be qualified as `googletest
`. And I'm not sure that there is need to wrap the
override_dh_auto_test rule to look for `nocheck` in `DEB_BUILD_OPTIONS`,
but I've posted a question about this to -devel [3] since I've seen
similar code get added to python-pysam as well [4].


You are absolutely correct. I have updated the repository accordingly.

Although guarding the override is not always superfluous, depending on 
your build system. For pybuild or CMake though, it should not be needed.



Thanks and regards
Afif


[1] https://anonscm.debian.org/cgit/debian-med/simpleitk.git



2.
https://www.debian.org/doc/packaging-manuals/python-policy/build_dependencies.html
3. https://lists.debian.org/debian-devel/2017/11/msg3.html
4.
https://anonscm.debian.org/cgit/debian-med/python-pysam.git/tree/debian/rules?id=5897693255ab6a36fb69cfc5bc096c65973f5f47#n25


Cheers,
Ghis

RFS: simpleitk/1.0.1-1 [ITP]

[Ghislain Vaillant]

Hi all,

Could someone from the team sponsor the initial upload for simpleitk 
[1]. Perhaps Gert (cc'd), since he is also involved with packaging ITK?


[1] https://anonscm.debian.org/cgit/debian-med/simpleitk.git

Cheers,
Ghis

RFS: dcm2niix/1.0.20171017-1

[Ghislain Vaillant]

Hi everyone,

Could someone from the team sponsor the latest update to dcm2niix [1].

[1] https://anonscm.debian.org/cgit/debian-med/dcm2niix.git

Cheers,
Ghis

Re: [Ann] Changed Debian Med policy: SVN is now deprecated

[Ghislain Vaillant]

On 22/09/17 11:09, Mattia Rizzolo wrote:

On Fri, Sep 22, 2017 at 12:06:03PM +0200, Gert Wollny wrote:

As for insighttoolkit ... Has anyone experience on how to manage a
multi-source project in git?


git-buildpackage (gbp) since not so many months has support for
multi-tarball packages.  It's pretty much only just about using
--component= when running `gbp import-orig`, check out the manpage.

I tried it with opencv during the summer, and I must say I'm quite happy
with it.


Same with simpleitk (one tarball for the sources, another for the data). 
gbp --component made that painless.


Ghis

Re: InVesalius new upstream version

[Ghislain Vaillant]

On 14/08/17 15:17, Mattia Rizzolo wrote:

2. I created a debian/source/options file with extend-diff-ignore
option. During the package generation I'm moving the cython source
files to another folder to compile them. This is causing errors with
generation of diff file relative to the orig file.
So I'm using the extend-diff-ignore to ignore these files. Am I doing
it correctly?


That feels like something that is not as clean as it could be.  Also,
reading your description of what you are doing I believe your package
wouldn't build twice in a row (i.e. `dpkg-buildpackage &&
dpkg-buildpackage`), which is another bug.  I think what you want to do
instead is to *copy* those sources into a temporary directory that you
then remove with dh_clean.  That said, this feels like an upstream
thing, why do you need to copy/move files around before building them?
The clean target doesn't clean enough? etc etc.


Since Cythonized files can be regenerated, you can just filter them out 
of the source tarball and run the build as usual. Their absence will not 
trigger a diff error and the clean target should get rid of the 
generated ones. That's in theory.


In practice, some upstream do ship the Cythonized files to avoid a 
dependency on Cython at build time (fair enough) but do not provide an 
appropriate clean command to get rid of them (not nice).


If that's your case, in addition to excluding the Cythonized files from 
the tarball, you need to clean them manually either using an override 
for the dh_auto_clean target or by listing their corresponding paths in 
a debian/clean file (usually preferred).


You may also patch the build system and forward the clean command 
upstream too (even better).


Ghis

Re: Fwd: [WSSSPE] WSSSPE5.1 & WSSSPE5.2

[Ghislain Vaillant]

I second that. Do you have a particular format in mind?

I saw you had something lined up about CWL. Is that for the UKRSE
conference, or the workshop before?

I should apologize for my lack of knowledge about the format of the
conference. FYI, it would be my first attendance to it, assuming I can
convince my PI and secure some funding.

Ghis


On Sat, 2017-06-03 at 16:00 +0300, Michael Crusoe wrote:
> The WSSSPE 5.1 conference on Sept 6th in Manchester, UK would be a good 
> opportunity to present our thoughts on a role for Debian in the pursuit of 
> sustainable research software.
> 
> -- Forwarded message --
> From: Daniel S. Katz 
> Date: 2017-05-31 18:11 GMT+03:00
> Subject: [WSSSPE] WSSSPE5.1 & WSSSPE5.2
> To: wss...@lists.researchcomputing.org.uk
> 
> 
> Hi,
> 
> We will be holding two one-day WSSSPE (Workshop on Sustainable Software for 
> Science: Practice and Experiences) workshops this fall:
> 
> WSSSPE5.1 (http://wssspe.researchcomputing.org.uk/wssspe5-1/) the day before 
> the RSE Conference in Manchester, UK (Sept 6)
> WSSSPE5.2 (http://wssspe.researchcomputing.org.uk/wssspe5/) the day before 
> the IEEE eScience Conference in Auckland, NZ (Oct 24)
> 
> WSSSPE5.1 will soon have a CFP out, and there is already one for WSSSPE5.2 
> (http://wssspe.researchcomputing.org.uk/wssspe5/call-for-submissions/_
> 
> Please consider attending one or both.
> 
> Thanks,
> Dan
> 
> -- 
> Daniel S. Katz
> Assistant Director for Scientific Software and Applications, NCSA
> Research Associate Professor, CS
> Research Associate Professor, ECE
> Research Associate Professor, iSchool
> University of Illinois
> (217) 244-8000
> d.k...@ieee.org or dsk...@illinois.edu
> http://danielskatz.org
> 
> 
> 
> 
> 
> ___
> WSSSPE mailing list
> wss...@lists.researchcomputing.org.uk
> http://lists.researchcomputing.org.uk/listinfo.cgi/wssspe-researchcomputing.org.uk
> 
> 
> 
> 
> -- 
> Michael R. Crusoe
> Community Engineer & Co-founder
> Common Workflow Language project
> https://impactstory.org/u/-0002-2961-9670
> michael.cru...@gmail.com
> +1 480 627 9108
> +32 2 808 25 58

RFS: dcm2niix/1.0.20170429-1 [experimental]

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the following package:

* Package name: dcm2niix
  Version : 1.0.20170429-1
  Upstream Author : Chris Rorden
* URL : https://github.com/rordenlab/dcm2niix
* License : BSD
  Section: science

One can check out the package by visiting the following URL
(debian/experimental branch):

  https://anonscm.debian.org/git/debian-med/dcm2niix.git

Changes since the last upload:

  * New upstream version 1.0.20170429
  * Update copyright information
  * Drop the patch queue, no longer required
  * Specify the source directory and build system
  * Use the system zlib and openjpeg2 libraries
  * Build and install the manpages with Sphinx

Best regards,
Ghis

Re: bits about the future with VTK in Buster

[Ghislain Vaillant]

On Thu, 2017-04-06 at 10:27 +0200, Gert Wollny wrote:
> Hello all, 
> 
> I just drop this here for future reference. 

Thanks for looking into it and summarizing your findings.

> I've experimented a bit with VTK-7.1 and among other, minor issues I
> came across the problem that VTK now defaults to,  and, hence, 
> encourages the use of, a new renderer backend, called OpenGL2 that
> requires an OpenGL 3.2 context. The old OpenGL renderer is still
> available in the code, but when compiling VTK one can only enable one
> or the other.

Ack.

> Now, OpenGL specifies a compatibility profile that would provide the
> legacy fixed function interface also with the new >=3.2 context, but
> Mesa doesn't implement it, which means, code written against the old
> style OpenGL API will not run properly when a 3.2 OpenGL context is
> used (as required by the VTK OpenGL2 backend), even if the
> incompatibilities between the VTK renderer class interfaces could be
> patched.
> 
> Also, code using the new renderer will not run on older graphics
> hardware, since VTK then simply rejects pre-OpenGL 3.0 contexts.  

Well, I guess we will have to draw a line in the sand at some point
about old hardware compatibility. Are there that many people running
something as intensive as paraview on a very old laptop, I wonder? 

> One example that uses VTK, but it also has lots of old-style OpenGL
> code in it is ginkgocadx, which means it can not run properly with VTK
> with the new renderer is enabled. ginkgocadx has been abandoned by
> upstream, and I started to maintain it and try to keep the code up to 
> date. The last few days I tried to port it to OpenGL >= 3.2, but it is 
> a big task, since toe code is littered with old-style openGL, so I
> don't really see it being done, and I guess it is similar for other
> projects that use VTK. I could imagine that even for software that is
> actively maintained the developers may be reluctant to switch to the
> new renderer if it contains too much non-VTK OpenGL code (I checked,
> and at least with version 3.4 itksnap also uses some direct calls to
> old-style OpenGL). 
> 
> On the other hand we can expect that some software will start to rely
> on the new OpenGL2 renderer at which point we have a problem if we
> don't want to keep two versions of VTK in the archives.

I wonder whether we could keep VTK-6 for projects using the old API and
force VTK-7-only projects to use the new one? VTK-6 and VTK-7 should be
co-installable, right?

Ghis

Re: Help needed for pandas bug: Could anybody verify the suspicion that tzdata might have some influence?

[Ghislain Vaillant]

On 28/03/17 10:37, Andreas Tille wrote:

PS: Yaroslav, you know my opinion about using Vcs outside of debian.org and
deriving from policies that are widely established.  Currently
  git://github.com/neurodebian/pandas.git
is not even featuring the latest uploads - last changelog entry is

pandas (0.19.2-2) unstable; urgency=medium

  * Exclude a number of tests while running on non-amd64 platforms
due to bugs in numpy/pandas

 -- Yaroslav Halchenko   Wed, 11 Jan 2017 12:13:05 -0500


I'm sorry to repeat myself but you are not creating a welcoming
environment for people who intend to help.


This sentiment is shared on my side too.

It was very disappointing to discover that nipype will not be part of 
Stretch due to an RC, which looks like many of those the team fixed 
during the Numpy 1.12 migration [1]. Besides, the packaging repository 
is quite frankly a mess [2] and is outdated.


Looking at the other packages maintained by NeuroDebian and affected by 
RCs [3] (which include nipy, dipy and pandas), the repository layout is 
inconsistent from one package to the next [4, 5, 6]. IMO, as an 
experienced packager who has contributed to many different teams, this 
completely cancels out the benefits of having packages team-maintained 
in the first place.


I am wondering whether NeuroDebian should instead be focusing on 
maintaining high-quality backports of neuroimaging software for 
supported Debian and Ubuntu releases (a goal it currently fulfills very 
well), and leave the main packaging effort to other Debian packaging 
teams (Science, Med, Python...).


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848777
[2] https://anonscm.debian.org/git/pkg-exppsy/nipype.git
[3] 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint=team%40neuro.debian.net=no=done=critical=grave=serious

[4] https://anonscm.debian.org/cgit/pkg-exppsy/dipy.git
[5] https://anonscm.debian.org/cgit/pkg-exppsy/nipy.git
[6] https://anonscm.debian.org/cgit/pkg-exppsy/pandas.git

Best regards,
Ghis

Re: Request to Join Project Debian Med from Vojtech Kulvait (kulvait-guest)

[Ghislain Vaillant]

On 13/03/17 07:29, Andreas Tille wrote:

[Please note that I sent a copy to the list since there is no
 private information in your mail and *all* technical discussion
 should be archived on the list.]

Hi Vojtech,

On Mon, Mar 13, 2017 at 12:01:01AM +0100, Vojtech Kulvait wrote:

thank you for adding me. I was able to obtain sources running

gbp clone git://git.debian.org/debian-med/dicompyler.git


this is the anonymous checkout.  It is better to use ssh://...
You can easily change this afterwards by editing the file

   .git/config

in the [remote "origin"]  url  property (or more cleanly you know the
proper Git command to do so which I resist to learn due to this
shortcut.


However gbp buildpackage did not work due to missing public keys.


Most probably you get an error due to missing *private* key.  That's
actually not a "did not work" issue since the packages are created but
not signed.  Just add your own ID (name + e-mal) in debian/control as
Uploader and use the same ID inside the changelog where gbp is seeking
for the ID that should sign the upload ... if not overriden at command
line using  --debsign-k "your ID"  which you could do alternatively.


I was working on fixing wxPython 3.0 stuff. I noticed that someone did some
work on this as well since there is ./debian/patches/fix-xrc-errors.patch
that seems not to be applied on sources.


You neet do call

quilt push -a

to get all patches applied!


Or you can use `gbp-pq` [1] if you are more comfortable with git.

[1] 
http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.patches.html



Anyway I have been able to fix the problems and get the program running
under https://packages.debian.org/jessie/libwxgtk3.0-0 package, the main
functionality is fixed.

I don't know what to do next if I want to get it back to Debian.


Please make sure you apply all quilt patches first.  Then you do

quilt new my_new_patch.patch
quilt edit file_to_edit
quilt refresh
vi debian/patches/my_new_patch.patch
  add
Author: your_ID
Last-Update: ...
Bug-Debian: https://bugs.debian.org/854837
Description
  fields to document the patch
git add debian/patches/my_new_patch.patch
quilt pop -a
  ## This is *important* to make sure you do not commit all
  ## changes done by quilt as git changes
dch
  ## document your change in debian/changelog
git commit -a
  ## make sure only your patch, debian/patches/series and
  ## debian/changelog are changed here
git push


It seem
that I don't have write access to git


See above.  You have an anonnymous clone - just use ssh.


That's assuming Vojtech is already a member of the team and provided his 
SSH key to Alioth, right?



and I also don't know if the official
packages are somehow automatically built from git repositories. I would
like to at least check the dependencies.


There is no such thing like automatic build.  You need a sponsor (for
instance me) who builds the package, checks it and signs with a key that
has a @debian.org address (=official Debian Developer).


You may request access to the debomatic service, which would allow you 
to test your builds in a similar setup as the official builders. To push 
the package to the latter, you would need to be sponsored as Andreas 
described.


[2] http://debomatic-amd64.debian.net/

Cheers,
Ghis

Re: Important News for DebMed graphics package maintainers

[Ghislain Vaillant]

Good one

Le 6 févr. 2017 6:07 PM, "Roland Fehrenbacher"  a écrit :

>
> Please take this important new order into account or else ...
>
> https://twitter.com/genetics_blog/status/827267187077373952
>
> Sorry, couldn't help posting this to you guys :)
>
> Cheers,
>
> Roland
>
> ---
> http://www.q-leap.com / http://qlustar.com
>   --- HPC / Storage / Cloud Linux Cluster OS ---
>
>

Re: Help needed for course lecture about Debian packaging

[Ghislain Vaillant]

By getting to know the software you are willing to package?

Ghis


On Wed, 2017-02-01 at 20:43 +0300, Canberk Koç wrote:
> Hello Again ,
> 
> We are wondering that specially how can we find the building dependencies of 
> a source code at first. Did we have a tool for that? ( Source code is only 
> source files not debian dir included )
> 
> 1 Şub 2017 20:20 tarihinde "Andreas Tille"  yazdı:
> > Hi,
> > 
> > On Wed, Feb 01, 2017 at 08:15:12PM +0300, Canberk Koç wrote:
> > > Me and my 3 friends ( Ali, Kerim and Çağrı ) will give a course about
> > > debian packaging from scratch in a conference (ab2017.aksaray.edu.tr).
> > >
> > > So we are working on it and thought to ask you what subjects we should
> > > touch any ideas can help us to learn and teach .
> > 
> > may be this is helpful
> > 
> >    https://www.lucas-nussbaum.net/blog/?p=640
> >    https://packages.debian.org/search?keywords=packaging-tutorial
> > 
> > Kind regards
> > 
> >       Andreas.
> > 
> > --
> > http://fam-tille.de
> > 
> > 

Re: Help needed for compiling libsbml-odesolver

[Ghislain Vaillant]

On Fri, 2017-01-27 at 17:13 +0100, Andreas Tille wrote:
> Hi,
> 
> I tried to package libsbml-odesolver[1] but I was running into the same
> error as it was reportet on the sundials list[2]:
> 
> ...
>   In file included from sbmlsolver/processAST.h:44:0,
>from arithmeticCompiler.c:46:
>   ./sbmlsolver/odeModel.h:171:3: error: unknown type name ‘CVDenseJacFn’
>  CVDenseJacFn compiledCVODEJacobianFunction;
>  ^~~~
>   In file included from sbmlsolver/processAST.h:44:0,
>from compiler.c:44:
>   ./sbmlsolver/odeModel.h:171:3: error: unknown type name ‘CVDenseJacFn’
>  CVDenseJacFn compiledCVODEJacobianFunction;
>  ^~~~
>   ./sbmlsolver/odeModel.h:185:3: error: unknown type name ‘CVDenseJacFnB’
>  CVDenseJacFnB compiledCVODEAdjointJacobianFunction;
>  ^
>   ./sbmlsolver/odeModel.h:187:3: error: unknown type name ‘CVDenseJacFnB’
>  CVDenseJacFnB current_AdjJAC;
>  ^
> ...

`CVDenseJacFn` is declared in cvdense.h from Win32/WinCVODE/sundials/...

This file does not look included in ./sbmlsolver/odeModel.h, or perhaps
transitively?

Do we have a packaged version of sundials that is compatible?


> Since there was no response to [2] I opened an issue at SBML_odeSolver
> upstream[3] but may be somebody more experienced than me might have a
> good idea for a patch.
> 
> Kind regards
> 
>Andreas.
> 
> 
> [1] https://anonscm.debian.org/git/debian-med/libsbml-odesolver.git
> [2] 
> http://sundials.2283335.n4.nabble.com/Building-SBML-odeSOLVER-td4653445.html
> [3] https://github.com/raim/SBML_odeSolver/issues/3
> 

Re: Help for next version of freebayes needed: libseqlib build error

[Ghislain Vaillant]

On Fri, 2017-01-27 at 15:28 +0100, Andreas Tille wrote:
> Hi,
> 
> Version 1.1.x of freebayes needs libseqlib and I commited some
> preliminary packaging to Git[1].  My obviously poor attempt to use
> Debian packaged libraries instead of code copies endet up in
> 
> ...
> g++ -DHAVE_CONFIG_H -I. -I..  -I../ -I../htslib -Wno-sign-compare -Wdate-time 
> -D_FORTIFY_SOURCE=2 -g  -Wno-unknown-pragmas -g -O2 
> -fdebug-prefix-map=/build/libseqlib-1.1.1=. -fstack-protector-strong -Wformat 
> -Werror=format-security -c -o libseqlib_a-SeqPlot.o `test -f 'SeqPlot.cpp' || 
> echo './'`SeqPlot.cpp
> In file included from ../SeqLib/UnalignedSequence.h:5:0,
>  from ../SeqLib/BamRecord.h:23,
>  from ../SeqLib/BFC.h:8,
>  from BFC.cpp:33:
> /usr/include/bwa/bwa.h:33:3: error: conflicting declaration ‘typedef struct 
> bseq1_t bseq1_t’
>  } bseq1_t;
>^~~
> In file included from ../SeqLib/BFC.h:5:0,
>  from BFC.cpp:33:
> /usr/include/fml.h:11:3: note: previous declaration as ‘typedef struct 
> bseq1_t bseq1_t’
>  } bseq1_t;
>^~~
> In file included from ../SeqLib/UnalignedSequence.h:5:0,
>  from ../SeqLib/BamRecord.h:23,
>  from ../SeqLib/BFC.h:8,
>  from BFC.cpp:33:
> /usr/include/bwa/bwa.h:42:11: error: conflicting declaration of C function 
> ‘bseq1_t* bseq_read(int, int*, void*, void*)’
>   bseq1_t *bseq_read(int chunk_size, int *n_, void *ks1_, void *ks2_);
>^
> ...

Looks like the system BWA and FML have conflicting bseq1_t
declaration. 

I noticed that upstream is using personal forks of BWA and FML, not the
upstream ones. If you look for bseq1_t in the SeqLib clones of BWA and
FML, no definition appears. However, they do appear in the respective
upstream repositories.

Looks like upstream had to patch the BWA and FML code bases to be able
to mix them without a multiple-definition error. I am not sure you can
get away from it.


> If you want to make this your riddle for the weekend and you
> can come up with a solution this would simplify upgrading
> freebayes.
> 
> Kind regards
> 
>Andreas.
> 
> 
> [1] https://anonscm.debian.org/git/debian-med/libseqlib.git
> 

Re: dcm2niix

[Ghislain Vaillant]

On Wed, 2017-01-11 at 13:19 -0500, Yaroslav Halchenko wrote:
> On Wed, 11 Jan 2017, Ghislain Vaillant wrote:
> 
> > On Wed, 2017-01-11 at 11:22 -0500, Yaroslav Halchenko wrote:
> > > Hi Ghislain,
> > > Thanks for packaging and uploading to dcm2niix!
> > You're welcome.
> > > It is a pity though that we duplicated the effort somewhat since
> > > we maintained dcm2niix within NeuroDebian for a while and didn't upload
> > > primarily due to some licensing issues we brought up with upstream and
> > > which were later resolved (e.g. of console/ujpeg.*)
> > Before packaging a piece of software for Debian, I systematically check
> > whether an ITP has already been filed for it on the Debian BTS. There
> > was none, so I went for it. The duplication is a pity, but I can't be
> > blamed for following the standard procedure for contributing a new
> > package to the archive.
> 
> ;) oh -- it wasn't my intend to blame anyone.  Indeed, if to blame we
> could blame us (NeuroDebian) since indeed I don't think we ever filed an
> ITP for this one
> 
> > > It would be nice to converge and co-maintain a single package, may be
> > > under some team, e.g our pkg-exppsy (neurodebian) team or  debian-med --
> > > whatever you would prefer
> > I believe the package should be maintained by the Debian Med Team, and
> > subsequently backported to Debian Stable and Ubuntu LTS by NeuroDebian,
> > if desirable. The primary source for derivative projects should remain
> > Debian.
> 
> sure
> 
> > > our packaging is present on alioth and github:
> > > git://git.debian.org/git/pkg-exppsy/dcm2niix.git
> > > https://github.com/neurodebian/dcm2niix
> > 
> > Ack.
> > > unfortunately there is a stumbling stone on our end also -- versioning
> > > since upstream was inconsistent and I was naive to switch from our
> > > custom 0.0.date to their 'date' scheme they took for earlier
> > > releases, and now they have switched to 1.0.date ... heh
> > Ack.
> > You are referring to the following issue [1], right?
> > [1] https://github.com/rordenlab/dcm2niix/issues/28
> 
> I guess ;)
> 
> 
> > > correct resolution, to account for poor us NeuroDebianoids would be to
> > > introduce an epoch making it 1:1.0.20161101  so currently present
> > > version in neurodebian (20160921+git16-g0339407-1~nd+1) would upgrade to
> > > it.
> 
> 
> > > What do you think? ;)
> > Well, do I really have a choice?
> 
> ;) now that you are the authority over the Debian's dcm2niix package --
> more than ever ;)
> 
> > An alternative solution could be to convince Chris to revert to the old
> > MMDD versioning scheme. This way both the Debian and NeuroDebian
> > packages can be upgraded without such hack. He is about to make a new
> > release so we should act fast.
> 
> indeed!  I will gently follow up on the
> https://github.com/rordenlab/dcm2niix/issues/28
> now

See my follow-up on https://github.com/rordenlab/dcm2niix/issues/66

Hopefully, we can sort this out.

Cheers,
Ghis

Re: dcm2niix

[Ghislain Vaillant]

On Wed, 2017-01-11 at 11:22 -0500, Yaroslav Halchenko wrote:
> Hi Ghislain,
> 
> Thanks for packaging and uploading to dcm2niix!

You're welcome.

> It is a pity though that we duplicated the effort somewhat since
> we maintained dcm2niix within NeuroDebian for a while and didn't upload
> primarily due to some licensing issues we brought up with upstream and
> which were later resolved (e.g. of console/ujpeg.*)

Before packaging a piece of software for Debian, I systematically check
whether an ITP has already been filed for it on the Debian BTS. There
was none, so I went for it. The duplication is a pity, but I can't be
blamed for following the standard procedure for contributing a new
package to the archive.

> It would be nice to converge and co-maintain a single package, may be
> under some team, e.g our pkg-exppsy (neurodebian) team or  debian-med --
> whatever you would prefer

I believe the package should be maintained by the Debian Med Team, and
subsequently backported to Debian Stable and Ubuntu LTS by NeuroDebian,
if desirable. The primary source for derivative projects should remain
Debian.

> our packaging is present on alioth and github:
> git://git.debian.org/git/pkg-exppsy/dcm2niix.git
> https://github.com/neurodebian/dcm2niix

Ack.

> unfortunately there is a stumbling stone on our end also -- versioning
> since upstream was inconsistent and I was naive to switch from our
> custom 0.0.date to their 'date' scheme they took for earlier
> releases, and now they have switched to 1.0.date ... heh

Ack.

You are referring to the following issue [1], right?

[1] https://github.com/rordenlab/dcm2niix/issues/28

> correct resolution, to account for poor us NeuroDebianoids would be to
> introduce an epoch making it 1:1.0.20161101  so currently present
> version in neurodebian (20160921+git16-g0339407-1~nd+1) would upgrade to
> it.
> 
> 
> What do you think? ;)

Well, do I really have a choice?

An alternative solution could be to convince Chris to revert to the old
MMDD versioning scheme. This way both the Debian and NeuroDebian
packages can be upgraded without such hack. He is about to make a new
release so we should act fast.

Ghis

Re: cme and stylistic changes in team uploads

[Ghislain Vaillant]

On 25/12/16 23:51, Afif Elghraoui wrote:

I think it's enough consistency that people are either using dh_make,
debmake, or the debian-med packaging template and just adding to that.
If people were writing these packaging files from scratch, there would
be real consistency issues.


Come on, I am sure most people just copy an existing debianization that 
is close enough to the package they intend to work on, despite our best 
efforts to advise against doing so.



I don't impose this on anyone--I would not
force people requesting sponsorship to use it, nor would I change it
while making a team upload.


I'd definitely not request the cme style while I'm recommending it to
newcommers for the said reasons.  I'm usually doing it in team uploads
since up to now nobody expressed that its not wanted.  I'd not use it
for instance on packages where you are Uploader and I know that you do
not like it.


Place yourself as a newcomer for a minute. You were advised to use cme 
because whatever changes you make, you are guaranteed a well-formed 
d/control or d/copyright, or else the software will scream at you.


You are now happy with your contribution and get it uploaded, only to be 
publicly shamed on the team's mailing list for not respecting the main 
uploader's custom style.


Now let me ask you this, does this sound like a great packaging 
experience to you?



cme introduces some consistency in the formatting that is definitely
welcome.


Its not *only* the formatting its also a defined sequence of fields
which I consider a helpful standard.


It also helps you flag things like non-secure VCS URIs and
out-of-date standards fairly easily.


Its not just flagging it - its fixing it and by doing so it saves
time.


That is what I meant, I should have been more explicit.

It saves valuable time **not** spent on ensuring the consistency of the 
Debian files being worked on. Now, if I have to second-check everything 
cme does, then the original purpose of the software is defeated.



Flagging is what lintian does.


Yes, lintian is *only* flagging and I need to rebuild the package
after manual work.  Cme does things in advance and saves me another
build which is very convenient.



I agree that can be helpful, but to me it's outweighed by the problems I
have with it.


The problem here is you putting comments in d/control to categorize 
dependencies. This is highly non-standard. If you really want to do such 
thing, then you should be using build profiles [1] which would bring 
additional benefits.


[1] https://wiki.debian.org/BuildProfileSpec

Otherwise, your comments in d/control are just plain noise, I am afraid.


While cme also makes those changes for
you, it removes trailing commas from listings (making for noisier diffs)


I admit I was considering a bug report against cme about this but
somehow never took the time.  In the past I learned that cme authors are
quite sensible and if you have good reasons are responsive about this.


I understand why they would want to classify this as WONTFIX. Supporting 
many exotic formating practices is a pain.



So if this really concerns you I'd try a bug report if I would be in
your shoes.


and misaligns all itemized lists.


I never observed this.  Could you please give an example?  That could
also be a topic for a bug report.


This is really not a big deal, but I was referring to something like:

Build-Depends: A,
   B,
   C
...
Depends: D,
 E,

versus

Build-Depends:
A,
B,
C
...
Depends:
D,
E

where in the latter case, both lists are aligned. Again, not a very big
deal.


Not a very big deal indeed!


I'm not trying to convince anyone because I'm not really interested in
disputing style; all I'm saying is that if someone wants to make a team
upload, I don't think that making stylistic changes should be part of it.



It depends.  If I know that the team member does not like it I agree.


He made himself clear, that is for sure.


However, in the past I touched so many packages of team members who in
the beginning were not aware about cme and its features and who were
happy about the change or team members who somehow stopped caring for
the package in question or left the team at all that the overall style
consistence became a feature of the Debian Med packages which I do not
want to miss today.  That's the reason we have even put

   ... simply call

   cme fix dpkg-control

   to get a properly formated, sanity checked debian/control file.

in our team policy[1].



I had the same experience, even for contributions outside d-science and 
d-med.



Although in the case of someone leaving the team or stopping work on a
package, presumably someone else has joined the uploaders list, in which
case subsequent changes are no longer Team uploads. My suggestion was
only to not change style as part of Team uploads.



That being said, like any other tools, it should not be used blindly and
whoever messed with your 

Re: plastimatch/1.6.5+dfsg1-1 prep

[Ghislain Vaillant]

On Tue, 2016-12-06 at 14:38 +0100, Andreas Tille wrote:
> Hi again,
> 
> On Tue, Dec 06, 2016 at 11:05:02AM +, Ghislain Vaillant wrote:
> > > Hmmm, this message droped in my inbox after uploading.  I'm not sure how
> > > important this might be - in any case the package has built nicely.
> > 
> > Both libblas-dev and libblas-dev | libblas.so would lead to successful
> > builds on autobuilders. The latter always pick libblas-dev in case an
> > alternative implementation is not already installed.
> 
> OK, so there is no real point to change anything since I only use clean
> chroots for building (and expect others to do so as well at least before
> uploading, right?

I'd say this change is probably not a reason for releasing a new iteration of
the package. However, not all users build from chroots and those would enjoy
being able to use their preferred BLAS implementation.

> > It is only a big deal for local builds, where you might have a BLAS
> > compatible package already installed (which provides libblas.so).

For instance, there is a significant difference in build time for src:shark
whether you build it with libblas-dev or libopenblas-dev. The testsuite runs
much faster with the latter, but it is not available on all architectures.

libblas-dev | libblas.so ensures that I can use OpenBLAS in local builds and
NetLib's BLAS in chroots / autobuilders.

Ghis

Re: consensuscore2: Any news?

[Ghislain Vaillant]

On Fri, 11 Nov 2016 14:17:13 -0800 Afif Elghraoui  wrote:
> Hi, Andreas,
> 
> على الأربعاء  9 تشرين الثاني 2016 ‫03:11، كتب 
> Andreas Tille:
> > 
> > do you have any news with this issue?
> > 
> 
> I should have posted an update. Upstream has moved consensuscore2 into a
> new source package, unanimity [1]. The packaging issues I was having are
> due to building the mixed-language code base. I have not found a good
> solution for this with debhelper, and the upstream build system was also
> very unconventional in order to handle it (which did not help
> debhelper's latching onto it). I think what needs to be done is to just
> package unanimity and have consensuscore2 be one of its binary packages.
> I'll have to see whether this problem will come up again after that.

I confirm Afif's reporting. This project is deprecated in favour of a larger
one.

We should just request an RM for this package, since we won't be getting any
support for it from upstream in the future, and focus on the new project. This
should also clear the current RC bug affecting it.

Ghis

Re: plastimatch/1.6.5+dfsg1-1 prep

[Ghislain Vaillant]

On Tue, 2016-12-06 at 11:01 +0100, Andreas Tille wrote:
> Hi Ghislain,
> > Other comments:
> > 
> > - "Add libblas-dev dependency (sub-dependency of libdlib-dev) to
> > plastimatch"
> > 
> > If libdlib-dev is missing a dependency (BLAS), it should be fixed
> > there. Transitive dependencies should not happen unless the dependency
> > in question is optional (like a specific backend, or extra feature).
> > 
> > If plastimatch directly depends on BLAS, then the right dependency
> > should be libblas-dev | libblas.so, to allow any implementation of BLAS
> > (netlib, atlas or openblas) to fulfill it. 
> 
> Hmmm, this message droped in my inbox after uploading.  I'm not sure how
> important this might be - in any case the package has built nicely.

Both libblas-dev and libblas-dev | libblas.so would lead to successful
builds on autobuilders. The latter always pick libblas-dev in case an
alternative implementation is not already installed.

> Could you please be more verbose what effect the additional dependency
> might have?

It is only a big deal for local builds, where you might have a BLAS
compatible package already installed (which provides libblas.so).

Ghis

plastimatch/1.6.5+dfsg1-1 prep

[Ghislain Vaillant]

On Tue, 2016-12-06 at 08:11 +0100, Andreas Tille wrote:
> Hi Gregory,
> 
> On Mon, Dec 05, 2016 at 06:52:07PM -0500, Gregory Sharp wrote:
> > 
> > > I admit if there was an explicit reason I simply forgot it (but its also
> > > for amd64, right).
> > 
> > The architectures are amd64 and i386 because libinsighttoolkit4-dev
> > is only available on those platforms.  If there is a more elegant 
> > way to represent this constraint I would be happy to remove.
> 
> The more elegant way is to simply specify "any".  Autobuilders will
> notice themselves whether a Build-Dependency exists or not and simply do
> nothing if a Build-Dependency is missing.

I second this.

I have a similar source package (asl) depending on VTK, which is also
not available on all architectures. It is marked any nonetheless and
has been built by the builders wherever all dependencies were
satisfiable.

Other comments:

- "Add libblas-dev dependency (sub-dependency of libdlib-dev) to
plastimatch"

If libdlib-dev is missing a dependency (BLAS), it should be fixed
there. Transitive dependencies should not happen unless the dependency
in question is optional (like a specific backend, or extra feature).

If plastimatch directly depends on BLAS, then the right dependency
should be libblas-dev | libblas.so, to allow any implementation of BLAS
(netlib, atlas or openblas) to fulfill it. 

Cheers,
Ghis

Re: pyBigWig

[Ghislain Vaillant]

On 02/12/16 19:14, Diane Trout wrote:



I don't think this is a problem. Policy 4.13 [1] says

~~~
Debian packages should not make use of these convenience copies
unless
the included package is explicitly intended to be used in this way.
~~~

which I think matches the situation here.


Thank you for point that clause out.

As its a python module I followed python team conventions for
organizing the source tree. But it seems like the package really should
be under debian-med? Is that OK?

Diane


There is a large range of Python packages being maintained in other 
teams than the DPMT, and the latter usually recommends to follow the 
Python packaging recommendations.


In the end, where the package (pyBigWig) is hosted becomes a matter of 
choice for the maintainer (yourself) and the decision is often based on 
which team is likely to be more able to assist with looking after the 
package long-term. For instance, if pyBigWig is mostly used by other 
d-med packages, then it is sensible to host it alongside them.


I am not quite sure what you mean by "organizing the source tree", since 
you are supposed to have the unpacked sources from the upstream tarball, 
plus an additional debian/ folder containing the Debian specific files 
(control, copyright, rules...). This is common to all packaging policies.


Ghis

Re: Versioning of snap-aligner

[Ghislain Vaillant]

On 02/12/16 10:38, Andreas Tille wrote:

Hi Michael,

when browsing throught the list of packages with no sensible uscan
result in DMD[1] I stumbled upon snap-aligner.  I commited a watch file
that is able to detect and download the releases tagged by upstream.
IMHO the latest version should be 1.0~beta.18 and not 0.18~1.0~beta.18.

What do you think about this?

Kind regards

  Andreas.

[1] 
https://udd.debian.org/dmd/?email1=debian-med-packag...@lists.alioth.debian.org=html#todo



I agree. The latest tag (v1.0beta.18) should be mangled to either 
1.0~beta.18 or 1.0~beta18.


Ghis

Re: Considerations for pird (Was: pirs/2.0.2+dfsg-2 follow-up)

[Ghislain Vaillant]

On 01/12/16 12:33, Andreas Tille wrote:

Hi Ghislain,

thanks for your bug fixes and the tracking whether everything went fine
afterwards.

On Thu, Dec 01, 2016 at 10:31:30AM +, Ghislain Vaillant wrote:


Looks like there are more non-portable options being used in pirs according
to the build logs, -mtune=generic in particular.

I will prepare an upload with a patch dropping this option. Depending on
performance needs, we may inject this option in d/rules with a conditional
on the host architecture, in a later update.


I admit that loosing performance on amd64 where people will use the
software in reality is not acceptable just for beeing able to compile it
on random architecture that are not relevant for practical work.  So if
the -mtune option can increase the performance it should be used on
amd64.

What do others here on the list think about this?

Kind regards and thanks again

  Andreas.



As a recap, what I propose is to patch the upstream Makefiles to drop 
the non-portable optimization and inject -mtune=generic via the 
confflags for amd64.


Ghis

Re: December

[Ghislain Vaillant]

On 29/11/16 18:40, Andreas Tille wrote:

Hi Thorsten,

On Tue, Nov 29, 2016 at 07:18:27PM +0100, Thorsten Alteholz wrote:

how time flies! This time of the year has come again and in order to carry
on a tradition, I want to remind everybody of our combined efforts to take
care of some poor souls.


Thanks a lot again for this great motivation to fix bugs!


The days are closing in, the year is drawing to an end and we should think
of all those, that are not around with their own kind. Again, during the
last few months, lots of volunteers all around the world tracked down those
poor souls and put their cases in the database. We should take care of those
needy. This year, there are only about 150 cases which are relevant to
Debian Med[1] (only 9 being serious[2]). So please feel pity for them and
allow the transition of as many as possible poor souls to their final
destination, the retirement community in the Archive. Maybe some of the
"won't fix" can be resolved as well.


I admit this year went quite well to keep the bug count low - thanks to
all who contributed to this.


Furthermore I would like to mention another page[3] with lots of information
about Debian Med packages. Besides the list of RC bugs you can also see
packages that can not be built on a Debian architecture, packages that are
not allowed to migrate from unstable to testing (and thus won't be included
in the next release) and packages with a new upstream version. I think those
packages need some care as well.


I'd like to stress this a lot.  Please check that all our work on
packaging gets rewarded by packages inside the next stable release.
Some packages are just hanging in unstable without migration and this
might mean fixing bugs on non-Debian Med packages.  I'm sure Thorsten
will put these on his record as well - so please do not afraid to work
on other packages than you did before.  The learning effect for you is
an additional plus.


As soon as I get the notice of a closed case I will record that in our
Advent calendar[4].

In contrast to normal calendars, let us fill this special one with lots of
good deeds. Maybe we can hide at least one number of a closed case behind
every door.


That's definitely the goal - please lets share the effort to reach it.


Have fun,


Your advent calendar was always fun - I'm pretty sure it will be again

 Andreas.


[1]http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint=debian-med-packaging%40lists.alioth.debian.org=no=yes=yes=fixed=done
[2]http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint=debian-med-packaging%40lists.alioth.debian.org=no=done=critical=grave=serious
[3]http://udd.debian.org/dmd.cgi?email=debian-med-packag...@lists.alioth.debian.org
[4]http://debian-med.alteholz.de/advent




If I have fixes pending for these packages, should I push one a day to 
avoid holes in your advent calendar ;-)


Looks cool by the way !

Ghis

Re: [Debian-med-packaging] Bug#841560: Could anybody please check the issue in python-skbio

[Ghislain Vaillant]

On 15/11/16 11:58, Kevin Murray wrote:

Hi Andreas,

On 12:13 15/11, Andreas Tille wrote:

On Tue, Nov 15, 2016 at 07:15:03PM +1100, Kevin Murray wrote:

There are also old binary packages preventing a testing transition,
which I'm not sure how to deal with.


If you want to get old package versions removed for certain architectures
you file a bug:


Thanks for the tip! Sorry for being a bit thick, but I'm not 100% sure which
package needs removing. From the "testing excuses" page for skbio, "missing
build on i386: python-skbio, python-skbio-doc, python3-skbio (from 0.4.1-1)".
Does this mean that the i386 packages from testing (or sid?) should be removed
(via the method you suggest)?

Or should the python-skbio (binary, python2) package be removed for all
architectures, as it is no longer provided? (this would be done with a bug
against release.debian.org, right?)


Just file a removal bug [1] for python-skbio asking for a removal from 
i386 only. Use reportbug for this, it will ask you the right questions 
to fill the initial template of the email.


[1] https://wiki.debian.org/ftpmaster_Removals

Ghis

Re: [Mom] Varmatch package situation

[Ghislain Vaillant]

On 02/11/16 07:18, Afif Elghraoui wrote:

Varmatch is a pretty new software package and they haven't yet made
their first official release. I saw the preprint article, thought it was
interesting, and made this start in packaging it as a result.

Being unreleased yet, the major concern is for it to produce accurate
results, so you should make sure that it can reproduce the results they
claim that it can with their test data.


Not to mention upstream might not be happy to have unreleased software 
officially packaged.


Ghis

Re: Remaining gcc-6 errors

[Ghislain Vaillant]

On 09/09/16 16:48, Andreas Tille wrote:

Hi Gert,

On Fri, Sep 09, 2016 at 05:13:01PM +0200, Gert Wollny wrote:

On 09.09.2016 15:54, Andreas Tille wrote:

   #831126 vxl: FTBFS with GCC 6: vcl_compiler.h:127:4: error: #error "Dunno about 
this gcc"

In the ITK embedded copy this is patched, but when I tried to apply the
patch to the stand-alone version I found out the last released stand-alon
version is way behind. I also don't see any reverse dependencies on
libvxl1.17v5 (apart from the -dev and -dbgsym packages).

Which makes me wonder whether it is useful to maintain the stand-alone
version.


I'm fine with droping vxl.

Any other opinions

  Andreas.



After a quick look at vxl upstream, it sounds like features are 
transitioned from ITK to vxl rather than the opposite. Since vxl is

playing catch-up, I don't see a compelling reason to use it as a
dependency downstream.

Besides, vxl has no rdepends in the archive currently, so better drop it
than spend valuable maintainer's time working on it.

Ghis

Re: otb is marked for autoremoval from testing

[Ghislain Vaillant]

On 02/09/16 07:01, Sebastiaan Couwenberg wrote:

On 09/02/2016 06:39 AM, Debian testing autoremoval watch wrote:

otb 5.6.1+dfsg-1 is marked for autoremoval from testing on 2016-10-08

It (build-)depends on packages with these RC bugs:
835400: libminc: FTBFS: convert.c:13:18: fatal error: hdf5.h: No such file or 
directory


This makes no sense.

otb doesn't have libminc in it's dependency chain, it does have
insighttoolkit4 in its dependency chain which has its own RC bug: #835761

Debian Med, can someone fix the libminc RC bug regardless,


I sent one to Andreas (via email, cc'd) on the 25th when the bug was
originally submitted.

It appears he has yet to submit a new release of the package. I can
prepare it if time is an issue on his end.

Cheers,
Ghis

Re: Packaging wishlist for this week's H3Africa workshop

[Ghislain Vaillant]

On 22/08/16 16:42, Michael Crusoe wrote:

One more: snpeff http://snpeff.sourceforge.net/download.html

On Mon, Aug 22, 2016 at 5:36 PM, Michael Crusoe 
> wrote:


Hello everyone,

I'm at the H3Abionet Cloud computing hackathon this week in
Pretoria, South Africa.


http://www.h3abionet.org/training-and-education/h3abionet-courses/17-h3abionet-courses/h3abionet-courses-upcoming/266-h3abionet-cloud-computing-hackathon



The resulting CWL tools and workflow descriptions will be
contributed in real time to the community repository:
https://github.com/common-workflow-language/workflows


It would be super nice if I could get assistance making Debian
packages of the following so we don't abuse Docker as a package
manager :-)

metagenomeSeq
https://bioconductor.org/packages/release/bioc/html/metagenomeSeq.html



phloseq https://github.com/joey711/phyloseq


bamstats http://bamstats.sourceforge.net/


Cheers,

-- 
Michael R. Crusoe

Community Engineer & Co-founder
Common Workflow Language project
https://impactstory.org/u/-0002-2961-9670

michael.cru...@gmail.com 
+40 720 781 765 
+1 480 627 9108 




--
Michael R. Crusoe
Community Engineer & Co-founder
Common Workflow Language project
https://impactstory.org/u/-0002-2961-9670
michael.cru...@gmail.com 
+40 720 781 765
+1 480 627 9108


Are there ITP / RFP bugs filed for these already?

If you don't know for sure, please check.

Ghis

Re: Bug#822110: odil: FTBFS when built with dpkg-buildpackage -A (chrpath fails)

[Ghislain Vaillant]

On 22/04/16 07:03, Julien Lamy wrote:

It seems that my fix actually made things worse since the builds have
failed for almost all architectures [1]. I think the cause is me not
reading correctly pbuilder's man page and build testing my previous
version with "--debbuildopts -B" instead of "--binary-arch". I've
committed a new version, with a better separation of arch and indep in
d/rules [2]. I've checked that "pbuilder --debbuildopts -A" builds only
indep packages, that "pbuilder --binary-arch" build only arch packages
and that packages are usable.

Does this new version seem correct ? Are there other tests to run than
my pbuilder ones ?

Sorry for the noise !

[1] https://buildd.debian.org/status/package.php?p=odil
[2] https://anonscm.debian.org/cgit/debian-med/odil.git/commit/

Cheers,


Hey Julien,

Indeed if you want to achieve true separation between -arch and -indep
only builds, then the additional overrides you listed with a no-op in it
are required.

This however:
+override_dh_auto_build-arch:
dh_auto_build

...should not be needed I believe.

That being said what *really* matters is having -arch only builds
working. If asking -indep builds results in a full build, then this is
not exactly a deal breaker, since not all upstream designed their build
system with such separation between -arch and -indep targets in mind.

Still nice you figured your case out. Plus, your d/rules does not look
too bad apart from the no-op targets.

Best regards,
Ghislain

Re: Packaging Python extensions and applications

[Ghislain Vaillant]

On 13/04/16 17:37, Julien Lamy wrote:

Dear all,
While preparing the package of the new upstream release of Odil, I had a
couple of questions regarding the packaging of Python extensions and
applications. I've read the Debian Python Policy and the Python Style
Guides on wiki.debian.org, but I'm not sure my current solution (cf.
https://anonscm.debian.org/cgit/debian-med/odil.git/tree/debian) is
correct, although Lintian does not complain.

To recap, Odil is a C++ 11 library, now with Python wrappers using
Boost.Python; no pure Python code appear in the wrappers, only the C++
extension. A CLI tool has also been added, in pure Python, using the
wrappers. I've created two new packages: python-odil for the wrappers,
and odil for the application. I'm wondering about the following points:

1. The current package is Python 2 only. Should I work on Python 3
compatibility, or could the package stay as Python 2 only (for now)?


Python 3 compatibility would be nice to have at some point, since
Python 2 has an expiration date.


2. I'm getting a warning regarding ${python:Depends}: since everything
works and I'm build-depending on libboost-python-dev, I've ignored it.
Are my dependencies correct?


You can have a look at opengm, which provides similar bindings via
Boost.Python.


3. The CLI application is split in multiple files: I've copied what dput
(https://sources.debian.net/src/dput/0.9.6.4/) is doing (main script in
usr/bin and other files in usr/share/odil, postinst and prerm to handle
bytecode). Is this OK, or is there a better way to do it?


Sounds ok to me. Can you run the application successfully with this
setup?

Ghis

Re: Lets maintain libbpp-phyl-omics in Debian Med team

[Ghislain Vaillant]

On 06/04/16 15:46, Andreas Tille wrote:

As for the git repository, may I ask why you need to create one? Would that
be a local debian copy of the one on github?
Makes me think that it would be time to synchronize our local repos and the
github one...


The Debian *packaging* repository is different from your development
repository - at least in the most frequently used workflow for Debian
packaging.  This repository stores only *release tarballs* (thus my
request for tagging releases) and the debian packaging is what is kept
track of (which you do not want inside your upstream code).


+1 for tagging your releases. It defines from which commit the official 
release tarball originated, which helps for sending our patches for

inclusion upstream.


There are other workflows where the Debian repository is using a clone
from Github (or whereever the repository can be found) but as I said
this is an unusual case which is used very less in our team.


One such example is this one:


https://anonscm.debian.org/cgit/debian-science/packages/python-arrayfire.git

Regardless of the choice of packaging repository layout, the important
thing is that the upstream branch (containing the upstream source) and
the packaging branch (containing the debianized source) are clearly
separated.

Hope this helps,
Ghis

Re: Strengthening team by fixing other members bugs

[Ghislain Vaillant]

On 04/04/16 09:14, Andreas Tille wrote:

Hi,

last week I had the idea to declare April as a month of fixing bugs in
Debian Med packages.  While about eight monthes are left until we the
freeze for Jessie will start we should constatly make sure that our
packages are free of bugs and are distributable all the time.  I think
it makes perfectly sense if everybody would look into bugs of packages
he has not yet touched.  This would increase the number of people
looking for packages and in most cases you can learn something new.


I would add that, alongside fixing bugs, we should ensure all our
packages have some sort of CI testing going on, when applicable.


It would be great if everybody who considers a member of the Debian Med
team (even if not very active until now) would try to fix one bug per
week.

If you have problems finding target bugs simply seek our teams bug
page[1].

Kind regards and have fun fixing bugs

  Andreas.

[1] https://bugs.debian.org/debian-med-packag...@lists.alioth.debian.org


Assuming someone has got a fix for a bug concerning a package he or she
does not personally maintain, how do you think this someone should
proceed? Push directly to the debian-branch? To a temporary branch, and 
give the official DM an opportunity to review?


I know yourself and myself have done this directly for each other's
packages in the past (which I am fine with), but it may be not to
everyone's taste.

Ghis

Re: [MoM] Re: bart - tools for computational magnetic resonance imaging

[Ghislain Vaillant]

On 09/01/16 08:35, Martin Uecker wrote:

  Ghislain Vaillant <ghisv...@gmail.com>:



FYI, the same trick is used for other dependencies with multiple
backends such as OpenCL.


What is the state of OpenCL on Debian?


The OpenCL headers are regularly updated, so are the main open-source 
drivers like ocl-icd (reference) and beignet (Intel). There is also pocl 
(CPU) but the packaging is lagging and its maintainer does not look very 
active. I am personally using the Nvidia one on my laptop and it works 
fine too.



We only support CUDA in BART, but I always wanted to add OpenCL
support and it should be fairly easy...


I personally maintain a few packages which requires OpenCL. You only 
need to build-depend on ocl-icd-opencl-dev | opencl-dev (which would 
also pull opencl-headers) and you are good to go.


Best regards,
Ghis

Re: [MoM] Re: bart - tools for computational magnetic resonance imaging

[Ghislain Vaillant]

On 09/01/16 08:35, Martin Uecker wrote:

  Ghislain Vaillant <ghisv...@gmail.com>:



FYI, the same trick is used for other dependencies with multiple
backends such as OpenCL.


What is the state of OpenCL on Debian?


The OpenCL headers are regularly updated, so are the main open-source 
drivers like ocl-icd (reference) and beignet (Intel). There is also pocl 
(CPU) but the packaging is lagging and its maintainer does not look very 
active. I am personally using the Nvidia one on my laptop and it works 
fine too.



We only support CUDA in BART, but I always wanted to add OpenCL
support and it should be fairly easy...


I personally maintain a few packages which requires OpenCL. You only 
need to build-depend on ocl-icd-opencl-dev | opencl-dev (which would 
also pull opencl-headers) and you are good to go.


Best regards,
Ghis

Re: [MoM] Re: bart - tools for computational magnetic resonance imaging

[Ghislain Vaillant]

On 09/01/16 08:03, Martin Uecker wrote:

What are the next steps?


Submit an RFS bug [1] and upload the package to mentors [2].

That's the usual route. Maybe the MoM process is different though. To be 
checked with Andreas.


[1] http://mentors.debian.net/sponsor/rfs-howto
[2] http://mentors.debian.net/
[3] https://wiki.debian.org/DebianMed/MoM

Best,
Ghis

Re: [MoM] Re: bart - tools for computational magnetic resonance imaging

[Ghislain Vaillant]

On 08/01/16 19:29, Martin Uecker wrote:



Hi Ghisvail!


- Binary packages split-up.

I am not quite sure about the usefulness of the bart-dev package. The final 
compilation line shows:

...

i.e. the final output is one executable (bart) with private libraries (libbox, 
libgrecon...) linked statically. So it looks to me that these libraries are not 
intended to be used publicly?


There are meant to be used and there are people who are using
them for internal projects. Ofcourse, they currently use the
source distribution of BART, but I think a -dev package would
be useful in the long run. I also have  a small image viewer
build on top of the libraries, which I would like to package
eventually:

https://github.com/mrirecon/view


Good. Then, you might want to use libbart-dev as the package name, which 
is usually the naming convention for packages containing any libraries 
(in shared or static form).



- lapack-dev -> lapack-dev | lapack.so in your list of Build-Depends in 
d/control.


That way your package can be built with optimized libraries like atlas or 
openblas.


Sounds like a good idea, but I do not understand it. What
does it mean to depend on "lapack.so"?


Using Build-Depends on liblapack-dev alone forces local source package 
build to have liblapack-dev installed.


Using Build-Depends on liblapack-dev | liblapack.so, a local source 
package build can be done with other BLAS providers than Netlib, such as 
libopenblas-dev or libatlas-dev.



Also one can replace liblapack.so using update-alternatives.
Why would it matter what I compile against as all alternatives
should be ABI compatible?


Absolutely. It is just that if I use OpenBLAS locally, I don't want to 
have to install lapack-dev to build bart, which would also mess up with 
my alternatives in the process. Using liblapack-dev | liblapack.so is 
just a bit friendlier.


FYI, the same trick is used for other dependencies with multiple 
backends such as OpenCL.


Hope this helped,
Ghis

Re: [MoM] Re: bart - tools for computational magnetic resonance imaging

[Ghislain Vaillant]

Hi Martin,

Great to see that your packaging work is progressing. Here are a few 
remarks on my side:


- Binary packages split-up.

I am not quite sure about the usefulness of the bart-dev package. The 
final compilation line shows:


gcc  -O3 -ffast-math -std=c99 -Wmissing-prototypes 
-I/home/ghislain/debian/packages/bart/src/ -fopenmp 
-Dmain_real=main_bart -o bart src/main.c 
/home/ghislain/debian/packages/bart/src/bart.o lib/libbox.a 
lib/libbox2.a lib/libgrecon.a lib/libsense.a lib/libnoir.a 
lib/libwavelet2.a lib/libiter.a lib/liblinops.a lib/libwavelet3.a 
lib/liblowrank.a lib/libnoncart.a lib/libcalib.a lib/libsimu.a 
lib/libsake.a lib/libdfwavelet.a lib/libnum.a lib/libmisc.a lib/libnum.a 
lib/libmisc.a -L/usr//lib -lfftw3f_threads -lfftw3f  -llapack -lblas 
-lgsl -lgslcblas -lpng -lz -lm


i.e. the final output is one executable (bart) with private libraries 
(libbox, libgrecon...) linked statically. So it looks to me that these 
libraries are not intended to be used publicly?


- Licensing of the bart Debian packages.

Since the software is compiled with GSL and FFTW support, the resulting 
binary should be distributed under a compatible GPL-like license. This 
may need to acknowledged somewhere, maybe in debian/README.Debian. For 
an example of such acknowledgement, have a look at how this is done with 
ITK [1].


[1] 
http://anonscm.debian.org/viewvc/debian-med/trunk/packages/insighttoolkit/trunk/debian/copyright?view=markup


- Copyright listing.

The output of licensecheck shows that some files have different 
copyright attributions than yours. For instance:


./matlab/imshow3.m: UNKNOWN
  [Copyright: Michael Lustig 2012 [sx,sy,nc] = size(img);]

Please be super thorough on these, since a non-exhaustive copyright 
listing is a strong motive for package rejection.


- lapack-dev -> lapack-dev | lapack.so in your list of Build-Depends in 
d/control.


That way your package can be built with optimized libraries like atlas 
or openblas.


- Potential overlinkage.

You might want to check these warnings out:

dpkg-shlibdeps: warning: package could avoid a useless dependency if 
debian/bart/usr/bin/bart was not linked against libgslcblas.so.0 (it 
uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if 
debian/bart/usr/bin/bart was not linked against libz.so.1 (it uses none 
of the library's symbols)


Which could be solved with some hardening flags, if you don't want to 
touch your Makefiles too much:


https://wiki.debian.org/HardeningWalkthrough


Apart from these comments. Looks good on my side.
Ghislain

Re: 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

Re: 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

Re: [MoM] Re: bart - tools for computational magnetic resonance imaging

[Ghislain Vaillant]

Hi Martin, some pieces of advice below:

On 07/12/15 11:26, Martin Uecker wrote:

The only issue is that I have to specify the tag with 'gdb'
because it looks for 'upstream/v0.2.09' which does not
currently exist. Instead of adding these tags, I would prefer
to reconfigure 'gdb' to use the existing upstream tags without
the prefix 'upstream/'. Then I could just push the regular
upstream tags. Would this be ok?


Just add a debian/gbp.conf [1] file with the following content:

[DEFAULT]
upstream-branch = upstream
debian-branch = master
upstream-tag = v%(version)s
debian-tag = debian/%(version)s
pristine-tar = True

That way you are documenting how your packaging repository is layed out 
explicitly (always a good thing), plus gbp will pick up these options 
over the default ones under $HOME/.gbp.conf. That way, you won't need to 
explicitly specify the tag via --git-upstream-tag anymore.


[1] 
http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/man.gbp.conf.html



I also created a newer upstream tag v0.2.09d specifically
for the initial packaging work because I made some upstream
changes to make packaging easier.  The bart_0.2.09.orig.tar.gz
which is now in the pristine-tar branch actually corresonds
to v0.2.09d.  I hope that is not too messed up, but with the
next upstream version (to be released soon) this hack would
gone.
Since you have yet to submit a first Debian package publicly, you are 
kind of free to do whatever you like with the packaging specific 
branches (pristine-tar, master) of your repository (force push, 
rebase...). Just make sure everything is in order once your package is 
ready for its first submission.


Ghis

Re: [MoM] Re: bart - tools for computational magnetic resonance imaging

[Ghislain Vaillant]

On 07/12/15 08:18, Uecker, Martin wrote:


Hi Andreas,


On Sun, Dec 06, 2015 at 11:59:02PM +, Uecker, Martin wrote:

Put simply, pristine-tar is our way to encapsulate access to the source
tarball used for packaging. Someone who checks out a d-science
repository does not need to know where the tarball comes from (github,
bitbucket, PyPI...), he or she can just check it out using pristine-tar
on the packaging repository.


Ok, I created a tar ball using a git archive (which matches what
github does) and then used pristine-tar to check it in.


I think this is a misunderstanding.  You should write a debian/watch file
(line 22 of this template
   
https://anonscm.debian.org/viewvc/debian-med/trunk/package_template/watch?revision=20511=markup
is your friend) and use the downloaded tarball when importing pristine-tar.


Ok, done.

Please note that there is no difference between downloading
tar balls from github which uses 'git archive' to create them
or creating them locally using 'git archive' (with the
right arguments). This already produces bit-identical results
(with the same hash)! So there is really no point in downloading
upstream tarballs from Github when one has a local copy of the git
repository.


Actually, you can do it with `gbp buildpackage` by passing the 
--git-no-pristine-tar and --git-pristine-tar-commit, which effectively 
will produce the pristine tarball from the tag you based your packaging off.


Andreas gave you the general guideline which works for any source. The 
--git*pristine-tar* options only work if you are using the upstream git 
repository.


FYI, make sure you have a valid watch file (although you are not using 
uscan), because that is also what is used by the Debian Package Tracking 
System to signal when new upstream releases are available.



You could add these in additional python-bart octave-bart binary
packages (sorry, matlab can not be provided as official Debian package).
You should read the according pages at wiki.debian.org where to put
Python modules (or you just check your local system where these are
stored) and Octave files (I never dealt with these but I guess there is
a wiki paga as well).  Feel free to ask me if you are struck in the
jungle of documentation and I'll provide more specific pointers.


Ok, I have to look at it. There are only very few small scripts,
so I would rather put it in the same package.


Another remark to the packaging:  Currently there is a libgsl migration
ongoing and you should use libgsl-dev instead of libgsl0-dev.


Done. Although now it doesn't build locally on my Ubuntu machine
anymore (only using pbuilder in a sid change root).


You could use something like libgsl0-dev | libgsl-dev to stay compatible 
with earlier versions?


Ghis

Re: [MoM] Re: bart - tools for computational magnetic resonance imaging

[Ghislain Vaillant]

On 06/12/15 12:32, Uecker, Martin wrote:

Hi Andreas,


Ok, I put it in /git/debian-med/bart.git as described in the
debian-med policy.

I checked this out and added Vcs fields and Homepage to Debian control
(please pull).  I noticed that the pristine-tar branch is missing in the
git repository.  You can get this easily by redoing

 gbp import-orig --pristine-tar your_orig_tar_gz

(just make sure you use the --pristine-tar option) and push the
pristine-tar branch.  The rationale is that we can both easily work
on a byte identical tarball right from the Git archive.

Ok, what is the deal with pristine-tar? Our upstream tar balls are
generated by github using git-archive. So there does not seem to
be any point to create tar balls just to re-import them using
pristine-tar, or is there?


Put simply, pristine-tar is our way to encapsulate access to the source 
tarball used for packaging. Someone who checks out a d-science 
repository does not need to know where the tarball comes from (github, 
bitbucket, PyPI...), he or she can just check it out using pristine-tar 
on the packaging repository.



I assume that the debian/control file is missing other Build-Depends
than just debhelper.

Yep. I added some. It builds using git-pbuilder.


FYI, it should also be possible to build your source package without 
gbp, by checking out the source tarball with pristine-tar and calling 
dpkg-buildpackage on master.


It is also a good way to test whether your clean target works as 
intended, by running dpkg-buildpackage twice and see whether it 
succeeds. If the clean target is insufficient, dpkg-buildpackage will 
complain of a mismatch between the source tarball and the content of the 
packaging tree.



I'd also recommend to use

 cme fix dpkg-control

which would bump your Standards-Version to 3.9.6 (which you can also do
manually but cme is a nifty tool I'd like to introduce to newcomers).

My experience so far: It pulls in a million of perl packages, then I had to
figure out that I still have to install an extra package for dpkg-control
to work, then it complains that it doesn't know libpng-dev, but if I replace
it with libpng12-dev fixes it to be libpng-dev again. It also spits out a
lot of incomprehensible warnings about the VCS-* lines. It didn't bump
the standards version, but decides to do some arbitrary reformatting ;-)


Yes cme can be a bit picky sometimes.

Anyway, Standards-Version should be set to 3.9.6 indeed, which Lintian 
would complain about later when you build the package.


Running licensecheck on the source tree revealed a few files which have 
missing copyright headers:


 licensecheck -r --copyright . | grep "No copyright"
./vars.m: *No copyright* UNKNOWN
./update-version.sh: *No copyright* UNKNOWN
./makedoc.sh: *No copyright* UNKNOWN
./src/simu/phantom.h: *No copyright* UNKNOWN
./src/simu/sens.h: *No copyright* UNKNOWN
./src/mat2cfl.c: *No copyright* UNKNOWN
./src/wavelet3/wl3-cuda.h: *No copyright* UNKNOWN
./src/wavelet3/wavthresh.h: *No copyright* UNKNOWN
./src/linops/sum.h: *No copyright* UNKNOWN
./src/linops/ufft.h: *No copyright* UNKNOWN
./src/linops/sampling.h: *No copyright* UNKNOWN
./src/linops/rvc.h: *No copyright* UNKNOWN
./src/dfwavelet/prox_dfwavelet.h: *No copyright* UNKNOWN
./src/sake/sake.h: *No copyright* UNKNOWN
./src/calib/calmat.h: *No copyright* UNKNOWN
./src/calib/cc.h: *No copyright* UNKNOWN
./src/num/simplex.h: *No copyright* UNKNOWN
./src/num/convoaa.h: *No copyright* UNKNOWN
./src/num/shuffle.h: *No copyright* UNKNOWN
./src/num/shuffle.c: *No copyright* UNKNOWN
./src/num/filter.h: *No copyright* UNKNOWN
./src/iter/vec.h: *No copyright* UNKNOWN
./src/iter/vec.c: *No copyright* UNKNOWN
./src/ismrm/read.h: *No copyright* UNKNOWN
./src/misc/version.h: *No copyright* UNKNOWN
./src/misc/cppwrap.h: *No copyright* UNKNOWN
./src/misc/pcaa.h: *No copyright* UNKNOWN
./src/misc/version.c: *No copyright* UNKNOWN
./src/misc/utils.h: *No copyright* UNKNOWN
./src/misc/cppmap.h: *No copyright* UNKNOWN
./src/misc/png.h: *No copyright* UNKNOWN
./src/misc/dicom.h: *No copyright* UNKNOWN
./src/bbox.c: *No copyright* UNKNOWN
./ar_lock.sh: *No copyright* UNKNOWN
./update-if-changed.sh: *No copyright* UNKNOWN
./git-version.sh: *No copyright* UNKNOWN
./matlab/bart.m: *No copyright* UNKNOWN
./matlab/writecfl.m: *No copyright* UNKNOWN
./matlab/readcfl.m: *No copyright* UNKNOWN
./scripts/rtnlinv.m: *No copyright* UNKNOWN
./vars.sh: *No copyright* UNKNOWN
./octview.m: *No copyright* UNKNOWN

Which you may or may not want to act upon. Since the other source files 
have one it might be picked up during the review process anyway.


Otherwise, looks good.

Quick question, is the package supposed to install just the bart 
executable and its accompanying documentation or something else in 
addition ?


Cheers,
Ghis

Re: 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

Re: bart - tools for computational magnetic resonance imaging

[Ghislain Vaillant]

On 01/12/15 00:15, Uecker, Martin wrote:


Hi all,

I would love to see our image reconstruction software
for magnetic resonance imaging included in Debian.

I filed an ITP with more information here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806762

The source code is on Github:

https://github.com/mrirecon/bart

I already added a debian branch with the debian control
files. Using gbp I can build a package with:

gbp buildpackage  --git-debian-branch=debian --git-upstream-tree=master

but it probably needs more work... and a sponsor.


Martin


Hi Martin,

Let me know if you need assistance on the packaging side.

Glad to see more MRI reconstruction software being packaged for Debian.

Cheers,

Ghis

Re: bart - tools for computational magnetic resonance imaging

[Ghislain Vaillant]

On 01/12/15 15:04, Uecker, Martin wrote:

Ghislain Vaillant:



Hi Martin,

Let me know if you need assistance on the packaging side.

Glad to see more MRI reconstruction software being packaged for Debian.

Cheers,

Ghis



Thank you, Ghis!

I am sure that I will need some help. I see that you have already
packaged the ismrmrd library (which we aim to properly support at
some point in BART).


Indeed. Still need to find time for Gadgetron as well, but it is a much 
bigger piece of work ^^.


Nice to hear you are planning to support ISMRMRD. FYI, Michael's team is 
currently working on the next major release (2.x), so I would suggest to 
wait a bit. Your call.


I can set the packaging repository up on d-med and push your initial 
work to it if you like. That would make collaborative work with members 
of d-med much easier, myself included.


Ghis

Re: 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

Re: bart - tools for computational magnetic resonance imaging

[Ghislain Vaillant]

On 01/12/15 16:37, Uecker, Martin wrote:

I can set the packaging repository up on d-med and push your initial
work to it if you like. That would make collaborative work with members
of d-med much easier, myself included.


So I tried to do it myself. See my mail to Andreas.


Perfect. Don't hesitate to ping me once you are happy with the current 
state of your packaging work. I am happy to help you on the final touch 
before review.


Good luck and thanks for your contribution to Debian.

Ghis

Shark / libshark packaging status

[Ghislain Vaillant]

Dear all,

I recently pushed a candidate source package for Shark [1] to the 
d-science package repositories [2]. After more careful reading of the 
different ITP / RFP bugs filed for Shark [3][4], I just realized that 
someone had already started working on it a while back (Goswin).


Please correct if I am wrong but it seems that no upload to the main 
archive has been done so far for Shark. And rightfully so, since there 
are some licensing issues in the distributed files (bug filed upstream) 
and quite a bit of patching had to be done to fix the build system (PR 
sent upstream). So as of today, I would advise against sponsoring an 
upload for it just yet, although the packaging is ready (lintian-free, 
upstream metdata, autopkgtest...).


I don't know how you guys want to handle the duplication, but I wanted 
to confirm that I am happy to join force with Goswin should he want to 
co-maintain this package with me.


[1] https://github.com/Shark-ML/Shark
[2] https://anonscm.debian.org/cgit/debian-science/packages/shark.git
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595485
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777043

Best regards,
Ghislain

Re: [po...@debian.org: Bug#802172: ismrmrd: FTBFS on several arches]

[Ghislain Vaillant]

I will, sorry for forgetting to push.

I will forward the bug upstream to get the test suite fixed, assuming 
upstream cares for these architectures.


Ghis


On 18/10/15 07:38, Andreas Tille wrote:

Hi Ghislain,

I guess you will care about this bug.  I noticed that the repository in
Debian Med is not containing 1.3.1-1.  Could you please push the latest
state?

Thanks

  Andreas.

- Forwarded message from Emilio Pozuelo Monfort  -

Date: Sun, 18 Oct 2015 02:45:53 +0200
From: Emilio Pozuelo Monfort 
To: sub...@bugs.debian.org
Subject: Bug#802172: ismrmrd: FTBFS on several arches
X-Debian-PR-Message: report 802172
X-Debian-PR-Package: src:ismrmrd
X-Debian-PR-Keywords:
X-Debian-PR-Source: ismrmrd

Source: ismrmrd
Version: 1.3.1-1
Severity: serious

Your package failed to build on several architectures. Here's an excerpt from
the armel build:

*** 546 failures detected in test suite "ISMRMRD Unit Tests"
make[4]: *** [tests/CMakeFiles/check] Error 201

All logs available at:

https://buildd.debian.org/status/logs.php?pkg=ismrmrd=1.3.1-1

Emilio

___
Debian-med-packaging mailing list
debian-med-packag...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging


- End forwarded message -

Re: Maintenance of freeimage over to d-science

[Ghislain Vaillant]

Hi Anton,

I'll be on leave for the next week and can't commit to get this patch 
out soon. Feel free to do it or let the QA team handle it. I will make 
sure to re-sync the packaging repository with theirs when I get back.


Cheers,
Ghislain


On 27/09/15 20:37, Anton Gladky wrote:

Hi Ghislain,

thanks for your work! Please ping me if you need uploading of
this package. Also it would be good to port this security patch
for the Jessie to close that vulnerability.

Best regards

Anton


2015-09-27 16:21 GMT+02:00 Ghislain Vaillant <ghisv...@gmail.com>:

Dear all,

Following the discussion in Bug#797165, both Anton and I took the initiative
of moving the maintenance of freeimage over to Debian Science, since quite a
few of our dependencies depend on it.

I have pushed a pristine clone of the collab-maint repository in
git/debian-science/packages/freeimage.git. Now starts the work of updating
the packaging to the latest upstream version (3.17) and review the list of
our patches.

Many thanks to Anton and the Debian QA team for supporting this effort.

Ghislain

Re: Proper package relationships when a project depends on CBLAS

[Ghislain Vaillant]

On 29/09/15 18:09, Felix Salfelder wrote:

On Tue, Sep 29, 2015 at 05:49:50PM +0100, Ghislain Vaillant wrote:

what is wrong with a builddep on libopenblas-dev|someotherblas-dev?

do you want to discard the second option in case the first is available
(don't know how to do that)?


If I use say libopenblas-dev | libatlas-dev, then the generated
binary package will have a Depends field with either
libopenblas.so.X or libatlas.so.X.


i assume this dependency is generated by dh_shlibdeps and your control
file lists ${shlibs:Depends} in the list of binary package dependencies.
for sure you can exchange that for whatever you please, e.g.
libopenblas.so.X | libatlas.so.X


Instead, I should probably have
libblas.so.X which can be updated via update-alternatives to any of
these implementations.


if there is a virtual package that depends on one of the above, then
sure, depend on that one.


Now I understand. I have replaced this dependency with:
BuildDepends: libblas-dev | libblas.so

Whereby libblas.so can be provided by libopenblas-dev or libatlas-dev.

Then the binary package gets the following dependency:
Depends: libblas.so.3

Which may be provided by libopenblas, libatlas or libblas, via 
update-alternatives.



Or should I actually care?


this is up to you. (but yes, sounds fun).


One learns something everyday :-)

Many thanks Felix for your pointers.

Ghis

Re: Proper package relationships when a project depends on CBLAS

[Ghislain Vaillant]

On 29/09/15 12:08, Felix Salfelder wrote:

On Tue, Sep 29, 2015 at 12:01:26PM +0100, Ghislain Vaillant wrote:

At the moment, I am building against libopenblas-dev, but the latter
is not available on all architectures and therefore restricts the
build of the source package (ArrayFire) to the restricted set that
provides it.
[..]
I have looked on c.d.n, but nothing seemed like an obvious solution to me.


HI Ghislain.

what is wrong with a builddep on libopenblas-dev|someotherblas-dev?

do you want to discard the second option in case the first is available
(don't know how to do that)?

cheers
felix



If I use say libopenblas-dev | libatlas-dev, then the generated binary 
package will have a Depends field with either libopenblas.so.X or 
libatlas.so.X. Instead, I should probably have libblas.so.X which can be 
updated via update-alternatives to any of these implementations.


Or should I actually care?

Ghislain

Maintenance of freeimage over to d-science

[Ghislain Vaillant]

Dear all,

Following the discussion in Bug#797165, both Anton and I took the 
initiative of moving the maintenance of freeimage over to Debian 
Science, since quite a few of our dependencies depend on it.


I have pushed a pristine clone of the collab-maint repository in 
git/debian-science/packages/freeimage.git. Now starts the work of 
updating the packaging to the latest upstream version (3.17) and review 
the list of our patches.


Many thanks to Anton and the Debian QA team for supporting this effort.

Ghislain

Re: Lena licensing, how to patch?

[Ghislain Vaillant]

On 20/08/15 20:54, olivier sallou wrote:

Hi,
I have a colleague who have the lena image licensing issue in his package.
He tried to patch it but get fuzzing issue when building the package.
As it is a binary file and never patched a binary file, has anyone an
idea on how to correctly patch this file ?

As it is not a new upstream release, we cannot simply exclude it from
orig.tar

Thanks

Olivier


Hi Olivier,

You can submit a new stripped orig.tar with a +dfsg1 suffix and bump the 
dversion of the source package with that suffix too.


No ?

Ghis

Re: Policy and Best Practices

[Ghislain Vaillant]

On 29/07/15 16:12, Steve M. Robbins wrote:

On July 29, 2015 09:40:41 AM Ghislain Vaillant wrote:



FYI, I am intending to write a piece on the d-science / d-med policies
regarding DEP-14 and its relationship with import-orig and pure Git
workflows. Just need to find the time for it.


Just like to say: I would find that extremely helpful.  So I'm hoping you can
find the time.

And kudos to all who contributed to the Debian-Med and Debian-Science policy /
packaging-workflow documents.  I found them all useful.

I like git, but I'm not very comfortable with it so I really appreciate best
practices recommendations.

-Steve



Your encouragements are very much appreciated Steve. This is very 
motivating.


I will try to keep the lists posted with my progress.

Cheers,
Ghis


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

Re: Git repository of htslib is lacking pristine-tar

[Ghislain Vaillant]

On 29/07/15 08:54, Andreas Tille wrote:

Hi Charles,

On Wed, Jul 29, 2015 at 03:26:55PM +0900, Charles Plessy wrote:

...
instead, I used:

 pristine-tar commit /tmp/htslib-1.2.1.tar.gz 1.2.1

As a result, git-buildpackage did not manage to find the pristine-tar 
information.


This is what I realised afterwards. :-)


In any case, please note that uscan or apt-get source can also provide you with
an upstream tarball if you are connected to Internet.  Since it regularly
happens that people mess up with the pristine-tar branch (for example by
forgetting to push it), this is an important workaround to remember.


Sure.  I'm perfectly aware of this.  However, I always have the hope
that more people become involved in our packages and so it helps if
things are in the order they should be.  Getting a beginner frustrated
if gbp does not work out of the box is not helpful.


I do not want to be a blocker, but on packages like htslib, I do not want to
work with the pristine tarball workflow.  Given that I am obviouly unable to
follow your pace, I will understand if you remove my name from the Uploaders
field and go ahead without me.  But if you do that for all my packages,
maybe you will have too much work as well ... so we must compromise :)


As I said I'm willing to learn and may be I will like this workflow at
some point in time.  So I rather try to understand what you are doing
(and I also need to spend some time into DEP-14) and we might find an
alternative workflow that should be documented properly.

BTW, about my pace:  I'm more and more realising that it does not scale
if I do the large amount of bug fixing in the Debian Med team[1].  Since
I'm currenly at home (this time will end next week) I fixed more than
one bug per day.  We have *lots* of easy to fix targets.  If a newcomer
would try to fix two bugs per month he would make it into the bugs
statistics[1] after one years.  I bet there are more than 24 easy
targets at belonging to the Debian Med team[2].


I think that the main problem is that I did not manage to document the workflow
on time before reducing my activity.  Otherwise, I think that it works fine.
Nevertheless, there may be changes in the future, for instance to harmonise
with DEP 14.


I think the latter should be approached since it is documented by
nature.

In short:  Just relax and care about your family.  I hope for more bug
fixers and will think about methods to strengthen the awareness that we
need some more action here.

Kind regards

 Andreas.

[1] http://blends.debian.net/liststats/bugs_debian-med.png
[2] 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=debian-med-packag...@lists.alioth.debian.org



FYI, I am intending to write a piece on the d-science / d-med policies 
regarding DEP-14 and its relationship with import-orig and pure Git 
workflows. Just need to find the time for it.


Meanwhile, should you have any questions wrt the layout of your 
packaging Charles, feel free to contact us. We have all been newcomers 
and are still learning as well.


Regarding your pace, this is something you need to find by yourself. 
Some people maintains a handful of packages, some more, some less, some 
focuses on bug fixing, documentation and so on. In the end, every 
little helps.


Best regards,
Ghis


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

Re: Git repository of htslib is lacking pristine-tar

[Ghislain Vaillant]

On 28/07/15 11:19, Andreas Tille wrote:

Hi Charles,

$ gbp clone ssh://git.debian.org/git/debian-med/htslib.git
$ cd htslib
$ gbp buildpackage
gbp:info: Orig tarball 'htslib_1.2.1.orig.tar.gz' not found at '../tarballs/'
gbp:error: Pristine-tar couldn't checkout htslib_1.2.1.orig.tar.gz: fatal: 
Path 'htslib_1.2.1.orig.tar.gz.delta' does not exist in 'refs/heads/pristine-tar'
pristine-tar: git show refs/heads/pristine-tar:htslib_1.2.1.orig.tar.gz.delta 
failed

I tried:

$ pristine-tar commit ../htslib_1.2.1.orig.tar.gz v1.2.1
pristine-tar: failed to find ref using: git show-ref v1.2.1

which I took from bedtools debian/README.source.  It seems that the 'v'
in front of the version number in the end needs to be left our here.  I
commited an according README.source.

I admit I'm not yet convinced that the chance to enable upstream pull
requests are worth the drawback that other team members have trouble
to follow an undocumented workflow.

Kind regards

Andreas.




You can normally do:

gbp buildpackage --git-upstream-tag=v1.2.1 \
--git-debian-branch=debian/unstable \
--git-no-pristine-tar \
--git-pristine-tar-commit

The last 2 options explicitly tell gbp that a pristine-tar commit does 
not exist yet for this tag and that is should generate a tarball and 
commit one.


In case the tarball for the current tag already exist in pristine-tar, 
these options are simply ignored.


This is a beginning of a documented workflow following DEP-14:
http://blog.mycre.ws/articles/git-packaging-workflow-for-py-lmdb/

Ghis


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

Re: [MoM] Re: Help with Debian packaging of DCMTK++

[Ghislain Vaillant]

On 17/07/15 17:33, Julien Lamy wrote:

Le 16/07/2015 20:39, Andreas Tille a écrit :

That's OK now.  I guess your next commits will be a debian/ dir.  Feel
free to commit your latest stuff you just did and improve from there.


I just pushed the first version of the debian dir, which raised a
question regarding unit tests: should I assume that the tests have been
run upstream or should I run them during the build? Right now, I've gone
the easy way and skipped them: they run relatively quickly but require a
specific environment (environment variables, running processes and
whatnot, a script is provided to set up all of this).

Next week, I'll try to integrate the code documentation and to fix the
shlib-related Lintian warnings.

Best,



The test suite should be run during the package build process. Since you 
said that a specific setup is required, you may want to use an override 
(override_dh_auto_test) to achieve the necessary setup / teardown for 
the test suite to run successfully. It should look like this in your 
d/rules:


override_dh_auto_test:
# set your envvars up here
ENVVAR1 = ...
ENVVAR2 = ...
# call the test suite
dh_auto_test
# optional teardown, if stuff needs to be cleared...
rm ...

Bon courage,
Ghislain


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

Re: python-pysam version lagging

[Ghislain Vaillant]

Hi guys, just a few additional comments

2015-06-09 9:14 GMT+01:00 Charles Plessy ple...@debian.org:

 Le Tue, Jun 09, 2015 at 12:38:31AM -0700, Afif Elghraoui a écrit :
 
  I was able to build it and clean it up a little more, but the package
 still
  has some lint:

 Hi Afif, thanks a lot for all this work.

  W: python-pysam source: dep5-copyright-license-name-not-unique
 (paragraph at
  line 40)
 
  I'm actually not sure what to do about this one.

 Try public-domain instead of PublicDomain.  public-domain is a special
 case
 in the machine-readable specification, so if the Lintian warning stays, I
 would
 consider it a false positive.

 https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/


This is one of these weird lintian warnings that popped up recently. Seems
that
you can no longer define a License twice in d/copyright. I believe bug
reports
have been sent about the rationales behind this.

 I: ...hardening-no-fortify-functions...
 
  I think these are false positives since the CPPFLAGS for fortification
 look
  like they're correctly set as I watch the package build.

 I have seen such apparent false positives in other packages.  If you have
 time,
 maybe it is worth asking for comments on the debian-mentors mailing list ?


+1


  I: ...spelling-error-in-binary...
 
  This is maybe not worth fixing.

 Maybe the easiest way to get rid of it is a pull request to upstream on
 GitHub ?


Happened to me a few times, each time I ended up sending a patch upstream.
It's up
to you to decide whether you want to carry on a patch downstream just to
fix such an
inoffensive bug. I personally did not care to do so.


Best regards,
Ghislain

Access to collab-maint

[Ghislain Vaillant]

Dear all,

Is there anyone in the team who can grant me access to collab-maint ? I
have sent a enquiry email via the Alioth page a while back and never got
any reply. I have got some non-science related packages that I'd like to
host on collab-maint instead of d-science / d-med.

Thank you very much in advance,

Cheers,
Ghislain

Re: Access to collab-maint

[Ghislain Vaillant]

Hi Andreas,

On Wed, 15 Apr, 2015 at 3:14 PM, Andreas Tille andr...@an3as.eu wrote:

Hi Ghislain,

On Wed, Apr 15, 2015 at 02:16:07PM +0100, Ghislain Vaillant wrote:

 Dear all,

 Is there anyone in the team who can grant me access to collab-maint 
? I
 have sent a enquiry email via the Alioth page a while back and 
never got
 any reply. I have got some non-science related packages that I'd 
like to

 host on collab-maint instead of d-science / d-med.


I vaguely remember that creating a repository on collab-maint need to 
be

done by a DD and requires manual intervention.


The description in [1] does not explicitly mentioned this is restricted 
to DD usage.


[1] https://wiki.debian.org/Teams/CollabMaint



Please give proper why
you prefer collab-maint which requires extra work with no visible 
profit

over debian-med/debian-science.


I thought only packages or deps related to scientific packages were 
welcome in
d-science. Since some packages I work on seemed to fit the description 
in [1], I

thought about using collab-maint instead.


We have previously packaged non-med /
non-science software as preconditions for our target packages and I 
see

no point to derive from this habit for cosmetic reasons.


The one package I had in mind at the moment was bitstring [2], which is 
more of a
general purpose module but may become an install-dep of future 
scientific packages.


[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781540
Bottom line is I should stick to d-science for this one ?


Thanks for your very much for your comments,

Ghis

Re: Broken irtk repository

[Ghislain Vaillant]

2015-03-19 13:10 GMT+00:00 Andreas Tille andr...@an3as.eu:

 Hi Ghislain,

 On Tue, Mar 17, 2015 at 11:51:28PM +, Ghislain Vaillant wrote:
  Hi Andreas,
 
  For this package, I have experimented on an alternative layout for the
 git
  repository, following
  the section entitled When upstream uses Git in the git-buildpackage
  manual [1].
 
  Since the repository only contains the debian/sid and pristine-tar
  branches (no upstream or
  master), it does not play very nice with the defaults of gbp-clone and
 co.
 
  I can definitely checkout the repository with the following command:
  gbp-clone git+ssh://git.debian.org/git/debian-med/irtk.git
  --upstream-branch=master --debian-branch=debian/sid

 While I can confirm that this worked now I have two problem with this
 approach which I have no sensible solution for but we should find some
 clue:

   1. How to know in advance that this scheme is used?
  Even if you can not know this in advance the method you are
  using should be documented in detail in the team policy (feel
  free to edit the policy document).


I don't know. gbp usually assumes you have an upstream and a debian branch.
How to
handle the particular case where only pristine-tar and the debian branch
are used is
beyond my knowledge.



   2. The method that is currently used to fetch machine readable data
  from packages in VCS fails.  Is based on:

 tille@moszumanska:/git/debian-med/irtk.git$ git ls-tree -r HEAD debian/
 fatal: Not a valid object name HEAD

  Here is a random example what is expected:

 tille@moszumanska:/git/debian-med/irtk.git$ cd ../ipig.git/
 tille@moszumanska:/git/debian-med/ipig.git$ git ls-tree -r HEAD debian/
 100644 blob cba7e1853702e26bee937c80153166337c4cbdaadebian/build.xml
 100644 blob bc9a75ff0e4704e5dee767b429b61b1ab11c9694debian/changelog
 100644 blob ec635144f60048986bc560c5576355344005e6e7debian/compat
 100644 blob 9280cf8b5b22ede16c8b8612286b898d4ab1d0e6debian/control
 100644 blob fcd466a5c2daeeeb5ed94cf62d0e9a13b01c5f76debian/copyright
 100755 blob fa6488b7d78b26bbf6bf040242c782d550ad5fc0
 debian/createmanpages
 100755 blob 1c33f8ab4b05a1e2f3dc0e8d47e1393516e45a75
 debian/get-orig-source
 100644 blob 8eead9d92f4ea99eb3a2937042503d129cd0c8c7debian/ipig.1
 100644 blob e77248175524d9f63749c2d6ca67159eeb4aa635debian/ipig.dirs
 100644 blob c76b352b696e5ab9deaabff1cad7ce3b8aac397ddebian/ipig.jlibs
 100755 blob 816d3cf34a295cea00d7cec768dcb6434572c93adebian/ipig.sh
 100644 blob 0f651869c921dec14bcfa53fe5e807692afbfb78debian/manpages
 100755 blob f44b6242f4a022b60055c6f5754f05014189f030debian/rules
 100644 blob 163aaf8d82b6c54f23c45f32895dbdfdcc27b047
 debian/source/format
 100644 blob d1d8ed7adac29cacfcf20739b05f80d945c55720
 debian/upstream/metadata
 100644 blob feb8aa3e1959e34bd2085d5ba2b65c62a8a161c1debian/watch


 Can you provide a safe way to get the metadata if even
   git ls-tree -r HEAD
 fails (not mentioning the restriction to debian/ dir).


I cannot. I should have used the method described in the policy in the
first place.



 I'm not against establishing new methods if they fit some needes better.
 However, we need to adapt the documentation and the tools we use to
 these methods.

  And build with:
  gbp buildpackage --git-upstream-tag='v%(version)s'
  --git-debian-branch=debian/sid

 Not tested - but it should also make its way into policy


Again, this is just an experiment and probably not something you would
document
in the policy yet.


  I quite like the workflow explained in the manual,

 We should at least link to the manual[1] and give some guidelines when
 it makes sense to use this method.

  where you just fetch the
  new upstream tag,
  merge in a debian/release branch and use the --git-upstream-tag option
 to
  specify the
  upstream source. I'll get back to the usual workflow with gbp
 import-orig
  if that is a
  problem, it was really just by curiosity that I tried this.

 As I said:  I do not want to suppress any progress in our tool set.  But
 as long as it is not documented in our policy and we have made sure all
 our tools are working on it whe should be a bit carefully.


I have barely tested this method and I can see no immediate advantage of
using it,
besides avoiding duplication between the pristine-tar and upstream
branches.

The last question about irtk:  Do you think it should be Recommended by
 med-imaging or just Suggested?


Too early to say. I also have some concerns on the licensing of some of the
components,
which I have to sort out first. That's why I did not even file an ITP for
it yet.

I personally can not obtain the
 relevance for medicine in the package description - or may be the
 description could be enhanced?


I am aware that the description is too succinct. I am working with upstream
on that.


 As I said the package will only show up
 once the metadata can be read from Git with the usual procedure or you
 suggest a patch

Re: Broken irtk repository

[Ghislain Vaillant]

Hi Andreas,

For this package, I have experimented on an alternative layout for the git
repository, following
the section entitled When upstream uses Git in the git-buildpackage
manual [1].

Since the repository only contains the debian/sid and pristine-tar
branches (no upstream or
master), it does not play very nice with the defaults of gbp-clone and co.

I can definitely checkout the repository with the following command:
gbp-clone git+ssh://git.debian.org/git/debian-med/irtk.git
--upstream-branch=master --debian-branch=debian/sid

And build with:
gbp buildpackage --git-upstream-tag='v%(version)s'
--git-debian-branch=debian/sid

I quite like the workflow explained in the manual, where you just fetch the
new upstream tag,
merge in a debian/release branch and use the --git-upstream-tag option to
specify the
upstream source. I'll get back to the usual workflow with gbp import-orig
if that is a
problem, it was really just by curiosity that I tried this.

Ghislain


[1]
http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html

2015-03-17 17:57 GMT+00:00 Andreas Tille andr...@an3as.eu:

 Hi Ghislain,

 I'm unable to clone

ssh://git.debian.org/git/debian-med/irtk.git

 Could you please try a fresh checkout if it works for you and if not
 please fix the repository?

 Kind regards

 Andreas.

 --
 http://fam-tille.de

best practice to move a package to team maintainership

[Ghislain Vaillant]

Hi everyone,

I'd like your opinion regarding the following matter. There is a package I
need an update for (h5py), which is now particularly outdated. It is
currently being maintained by a solo Debian maintainer, who I contacted
regarding this but has yet to reply. So I worked on my own, fixed the
packaging for the latest upstream version and tested locally on my work
machines.

My understanding is that, If the package were team-maintained (like hdf5
for instance), I could provide these changes and contribute to updating the
package in an easier way. I am not even sure how I can forward my changes
to the Debian maintainer, I am just so used to the comfort of working in
Debian-science / Debian-med I guess.

My question is the following: is there a good practice for suggesting a
move to team-maintainership to a solo Debian maintainer ? Via a bug report
? Mailing-list ? Direct email contact ?

Also, would that actually make sense, or am I just plain silly here ?

Cheers,
Ghis

Re: Bug#778852: RFS: ismrmrd/1.2.1-1 [ITP #732360] -- ISMRM Raw Data Format.

[Ghislain Vaillant]

Thanks Andreas,

Can I ask you to re-upload ismrmrd please ? I forgot to change the
maintainer field to d-med, but more importantly, did not license the
debian/ folder under a license compatible with upstream, which could cause
problems with patches in the future. Thanks !

For the D-M application, I am seriously considering it.

Cheers,

2015-02-20 17:36 GMT+00:00 Andreas Tille andr...@an3as.eu:

 Hi Ghislain,

 On Fri, Feb 20, 2015 at 05:05:50PM +, Ghislain Vaillant wrote:
  I have added an entry to the SoB tasks [1].
 
  However, I cannot access the blends svn repository to update the imaging
  task file.
  Since I am a member of d-med on Alioth, I am supposed to have access,
 right
  ?

 The following user groups have commit permissions:

   1. Debian Developers
   2. Members of Blends team

 This has advantages and disadvantages - you have hit the latter. :-)
 If you want to have commit permissions you can join group 1. (we talked
 about this recently ;-)) or 2. (which is simple).  Or you simply ask me
 to commit something like this:

 $ svn diff
 Index: imaging
 ===
 --- imaging (Revision 4142)
 +++ imaging (Arbeitskopie)
 @@ -542,6 +542,8 @@

  Depends: mia-tools, mialmpick, mia-viewit

 +Depends: ismrmrd-tools
 +
   ; Added by blends-inject 0.0.7. [Please note here if modified manually]
  Suggests: connectomeviewer
  Published-Authors: Gerhard S, Daducci A, Lemkaddem A, Meuli R, Thiran J-P
 and Hagmann P
 Index: imaging-dev
 ===
 --- imaging-dev (Revision 4136)
 +++ imaging-dev (Arbeitskopie)
 @@ -169,3 +169,5 @@
  Depends: libedf-dev

  Depends: python-imageio
 +
 +Depends: libismrmrd-dev


 ... which I did right now.


 Thanks for your work on this

Andreas.

 --
 http://fam-tille.de

RFS: ismrmrd/1.2.1-1 [ITP #732360] -- ISMRM Raw Data Format.

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for the following package:

* Package name: ismrmrd
  Version : 1.2.1-1
  Upstream Author : The ISMRMRD developers
* URL : http://ismrmrd.github.io/
* License : Expat
  Programming Lang: C++
  Description : ISMRM Raw Data Format

The ISMRM raw data format is a specification of a common format
to represent and share magnetic resonance imaging raw and image
data. The ISMRMRD library is a C++ implementation of such format,
plus a set of tools to generate and validate ISMRMRD datasets.

It builds the following binary packages:
 libismrmrd1.2  -- shared library
 libismrmrd-dev -- header and development files
 libismrmrd-doc -- html documentation
 ismrmrd-tools -- standalone executables
 ismrmrd-schema -- validation schema

These binary packages have been successfully tested over the past
few months using the following PPA:
 https://launchpad.net/~ghisvail/+archive/ubuntu/ismrmrd

The source package can be checked out at:
 http://anonscm.debian.org/gitweb/?p=debian-med/ismrmrd.git

This package will be maintained by the Debian-med Team and sponsored via
the Sponsorship of Blends.

Best regards,
Ghis


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54e762b6.5030...@gmail.com

Re: 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 

Re: Bug#772949: RFS: imageio/1.0-1 [ITP] -- Library for reading and writing a wide range of image formats

[Ghislain Vaillant]

I have added this package to the debian-science imageanalysis and
debian-med imaging-dev tasks.

Cheers,
- Ghis

Task for MRI (Magnetic Resonance Imaging) development

[Ghislain Vaillant]

Dear all,

I originally started to contribute to the Debian ecosystem to help make
available some of the development library, such as [1], necessary to work
with MRI data. In the field of MRI processing, we are currently witnessing
a growing interest towards the release of opensource tools / framework
specific to MRI [2, 3]. Since most reconstruction clusters I know run on
Linux, I can see Debian playing a great part in providing a centralized
repository for distributing and releasing MRI related software. Before
that, It would be nice to have a centralized place to discuss and
coordinate packaging jobs for MRI software, which I thought the creation of
dedicated task [4] would officially acknowledge.

First of, does it sound silly ?
Is that enough to justify the creation of a new task ?
Would there be any interest from other people besides me ?
How much work would it represent to organize such task ?

Just testing the waters.

Cheers,

Ghis

[1] https://packages.debian.org/fr/source/sid/nfft
[2] http://gadgetron.github.io/
[3] http://gpilab.com/
[4] http://blends.debian.org/med/tasks/

Re: Task for MRI (Magnetic Resonance Imaging) development

[Ghislain Vaillant]

Hi Yaroslav,

Thanks for your insights.

2014-12-08 17:36 GMT+00:00 Yaroslav Halchenko deb...@onerussian.com:


 On Mon, 08 Dec 2014, Ghislain Vaillant wrote:

 Dear all,

 I originally started to contribute to the Debian ecosystem to help
 make
 available some of the development library, such as [1], necessary to
 work
 with MRI data. In the field of MRI processing, we are currently
 witnessing
 a growing interest towards the release of opensource tools / framework
 specific to MRI [2, 3]. Since most reconstruction clusters I know run
 on
 Linux, I can see Debian playing a great part in providing a
 centralized
 repository for distributing and releasing MRI related software. Before
 that, It would be nice to have a centralized place to discuss and
 coordinate packaging jobs for MRI software, which I thought the
 creation
 of dedicated task [4] would officially acknowledge.

 Hi Ghislain,

 First of, does it sound silly ?

 not all

 Is that enough to justify the creation of a new task ?

 in addition to
 http://blends.debian.org/med/tasks/imaging
 and
 http://blends.debian.org/med/tasks/imaging-devel
 ?

 There is already a bulk of MRI related software packages
 contributed to listings in those two tasks

 What would you call the task?  what software would you like to list
 there?  If to make just MRI specific task -- not sure.


There is indeed already a large collection of MRI tools in both imaging and
imaging-devel. I should have checked first. Then, I guess a specific task
for MRI is not really needed.


Would there be any interest from other people besides me ?
 How much work would it represent to organize such task ?

 not much ;)

 Just testing the waters.

 FWIW you might like also to know about the NeuroDebian project:
 http://neuro.debian.net/ , which while concentrating on brains also is
 quite MRI-centric ;)  We do package/maintain some software under
 debian-med and debian-science blends umbrellas and list them in those
 tasks pages.


I should probably watch / join neurodebian as well then.



 As for the packaging discussion  place -- debian-med mailing list would
 indeed be a good venue ;)


Noted. I'll keep that in mind for my next contributions.

Cheers,
Ghislain

Re: Fwd: [iva] - Python 3 code depends on pysam

[Ghislain Vaillant]

At worst, can't you just disable the test suite for the Python 3 builds ?
Pybuild should allow to do that easily.

Ghis

2014-11-24 16:36 GMT+00:00 Jorge Sebastião Soares j.s.soa...@gmail.com:

 Hi guys,

 So essentially the package build halts when it tries to run the test suite:

 This is the error I'm getting when the pysam module is being imported:

 root@debian:~/iva-0.10.0# python3.4 setup.py test
 running test
 running egg_info
 writing top-level names to iva.egg-info/top_level.txt
 writing iva.egg-info/PKG-INFO
 writing dependency_links to iva.egg-info/dependency_links.txt
 reading manifest file 'iva.egg-info/SOURCES.txt'
 writing manifest file 'iva.egg-info/SOURCES.txt'
 running build_ext
 Failure: ImportError (No module named 'pysam') ... ERROR

 ==
 ERROR: Failure: ImportError (No module named 'pysam')
 --
 Traceback (most recent call last):
   File /usr/lib/python3/dist-packages/nose/failure.py, line 39, in
 runTest
 raise self.exc_val.with_traceback(self.tb)
   File /usr/lib/python3/dist-packages/nose/loader.py, line 414, in
 loadTestsFromName
 addr.filename, addr.module)
   File /usr/lib/python3/dist-packages/nose/importer.py, line 47, in
 importFromPath
 return self.importFromDir(dir_path, fqname)
   File /usr/lib/python3/dist-packages/nose/importer.py, line 94, in
 importFromDir
 mod = load_module(part_fqname, fh, filename, desc)
   File /usr/lib/python3.4/imp.py, line 245, in load_module
 return load_package(name, filename)
   File /usr/lib/python3.4/imp.py, line 217, in load_package
 return methods.load()
   File frozen importlib._bootstrap, line 1220, in load
   File frozen importlib._bootstrap, line 1200, in _load_unlocked
   File frozen importlib._bootstrap, line 1129, in _exec
   File frozen importlib._bootstrap, line 1471, in exec_module
   File frozen importlib._bootstrap, line 321, in
 _call_with_frames_removed
   File /tmp/buildd/iva-0.10.0/iva/__init__.py, line 20, in module
 from iva import *
   File /tmp/buildd/iva-0.10.0/iva/assembly.py, line 2, in module
 import pysam
 ImportError: No module named 'pysam'

 --
 Ran 1 test in 0.016s

 FAILED (errors=1)


 If pysam is python 3 compliant, I'm tempted to create the needed symlinks
 in python3.4 pointing to pysam in python2.7, eg.

 ln -s /usr/lib/python2.7/dist-packages/pysam
 /usr/lib/python3.4/dist-packages/pysam

 I'm sure that this is not the proper way of doing things, so is there any
 other way I can get pysam to be installed under python3.4 rather than
 python2.7?

 Regards,

 Jorge