Re: [Debian-med-packaging] Bug#798167: camitk: depends on vtk 5

2016-04-18 Thread Emmanuel Promayon

Hi again,

Thank you both for your inputs.

Mattia is right, I think it is the same problem that occurred in 
#821091. The bug was "solved" by reverting back to Qt4.


Thank you very much Gert for this tip about the vtk macro! We were 
wondering what the magic made gdcm-vtk package compile on sid with no 
error while we had a lot of problem with the macros (I checked d/patches 
and the vtk d/r files, but missed this). Now the mistery is explained, 
thank you!


I also tried VTK 6.3 and QVTKWidget3 [1] as you suggested as well, but 
to no avail.


I tried the upstream QVTKWidget2 version, and it works very well for 
the integrated card... but it does not working with the nvidia GPU!


So I might be able to produce a mix between the 6.3 QVTKWidget version 
and the upstream QVTKWidget2 version that can work for both integrated 
and nvidia GPU.


As I said to Gianfranco, on the #817163 thread, unfortunately, I will 
not be able to work on the packaging before the beginning of May.


I don't want camitk to block any transition, so if it is ok with 
everyone, I agreed to his suggestion of temporarily removing camitk from 
sid. I pushed my last files on the git (not ready yet), for information. 
A working camitk 4 package should not be too long to be back.


Thank you again for all your support and ideas!

Emmanuel

[1] 
http://stackoverflow.com/questions/26944831/using-qvtkwidget-and-qopenglwidget-in-the-same-ui


On 17/04/16 12:57, Gert Wollny wrote:

Hello,

while moving to VTK 6 please take into account that we are preparing a
transition to VTK 6.3.

Compared to VTK 6.2 version 6.3 removes some deprecated macros
and removes the module "vtkRenderingFreeTypeOpenGL".

You should be able to catch most of the problems related to macros by
compiling with VTK_LEGACY_REMOVE defined.

VTK 6.3 is available from experimental.

Best,
Gert







--
Emmanuel Promayon, Maitre de conférences
Univ. Grenoble Alpes / Polytech Grenoble
Laboratoire TIMC-IMAG / équipe GMCAO
Tel. +33/0 456 52 00 03



smime.p7s
Description: S/MIME Cryptographic Signature


Re: [MoM] Fwd: Outreachy project (CI for all biological applications inside Debian)

2016-04-18 Thread Andreas Tille
Hi Tatiana,

On Tue, Apr 05, 2016 at 07:42:04PM +0300, Tatiana Malygina wrote:
> I'm sorry for delay and not showing any response for some time, I was
> unexpectedly busy :(

Seem you found some time since I've seen your commit.  Thanks a lot for
your contribution.  I added some additional commits.  Please check these
out and read the log.  Please ask if something remains unclear.

Kind regards

  Andreas.

-- 
http://fam-tille.de



orthanc-imagej 1.1

2016-04-18 Thread Sebastien Jodogne

Hello,

I have just updated the "orthanc-imagej" package with the latest 
upstream version [1].


Andreas, as usual, would it be possible for you to sponsor it?

Regards,
Sébastien-


[1] 
http://anonscm.debian.org/viewvc/debian-med/trunk/packages/orthanc-imagej/trunk/debian/?sortby=date#dirlist




Re: orthanc-imagej 1.1

2016-04-18 Thread Andreas Tille
I'll take this.

On Mon, Apr 18, 2016 at 11:01:57AM +0200, Sebastien Jodogne wrote:
> Hello,
> 
> I have just updated the "orthanc-imagej" package with the latest upstream
> version [1].
> 
> Andreas, as usual, would it be possible for you to sponsor it?
> 
> Regards,
> Sébastien-
> 
> 
> [1] 
> http://anonscm.debian.org/viewvc/debian-med/trunk/packages/orthanc-imagej/trunk/debian/?sortby=date#dirlist
> 
> 

-- 
http://fam-tille.de



Re: orthanc-imagej 1.1

2016-04-18 Thread Andreas Tille
Uploaded and tagged.  Please tell me if the packaging should be moved to Git.
Thanks for your work
 Andreas.

On Mon, Apr 18, 2016 at 11:01:57AM +0200, Sebastien Jodogne wrote:
> Hello,
> 
> I have just updated the "orthanc-imagej" package with the latest upstream
> version [1].
> 
> Andreas, as usual, would it be possible for you to sponsor it?
> 
> Regards,
> Sébastien-
> 
> 
> [1] 
> http://anonscm.debian.org/viewvc/debian-med/trunk/packages/orthanc-imagej/trunk/debian/?sortby=date#dirlist
> 
> 

-- 
http://fam-tille.de



Re: orthanc-imagej 1.1

2016-04-18 Thread Sebastien Jodogne

On 04/18/2016 02:43 PM, Andreas Tille wrote:

Uploaded and tagged.  Please tell me if the packaging should be moved to Git.


Great, thanks again!

Regarding the move to Git, I personally do not have any preference. 
Maybe we could keep it in Subversion as long as possible to avoid any 
unnecessary work. However, if switching to Git is highly desirable, 
there is no problem for me as I have already an experience with the main 
"orthanc" package.


Regards,
Sébastien-



Re: orthanc-imagej 1.1

2016-04-18 Thread Andreas Tille
Hi Sebastien,

On Mon, Apr 18, 2016 at 03:14:05PM +0200, Sebastien Jodogne wrote:
> 
> Regarding the move to Git, I personally do not have any preference.

Me neither.  However, the thing is that if the orig tarball is recreated
(due to removal of files) we can not ensure that we are working on the
same tarball (means same md5sum, the content is identical) when using
the established SVN workflow.  In Git we inject the tarball pristine-tar
and thus we both are using the very same file.  Thus my personal rule
is: If tarball is not identical to download move to Git for packaging.

> Maybe we
> could keep it in Subversion as long as possible to avoid any unnecessary
> work. However, if switching to Git is highly desirable, there is no problem
> for me as I have already an experience with the main "orthanc" package.

For me the move is not urgent if the issue above is no real problem for
you. 

Kind regards

  Andreas.

-- 
http://fam-tille.de



Re: Last call for GSoC intern selection!

2016-04-18 Thread Andreas Tille
Hi Nicolas,

On Mon, Apr 18, 2016 at 05:01:31PM +0200, Nicolas Dandrimont wrote:
> > Our GSoC slots request has come and gone, and it's now time to make our 
> > final
> > intern selection for both GSoC and Outreachy.
> 
> Hey all,
> 
> We have one unassigned GSoC slot available for each of the following projects 
> :
> 
>  - Debian-Med CI

So far three students who seem to be equally qualified for this project
have raised interest on the mailing list where we are coordinating this
project[1] (list in CC):

  Name  Number of tests just provided
  Anna Lioznova   0
  Canberk Koç1
  Tatiana Malygina   1

>From reading their application all seem to be qualified for the project
and two of them have proven to be able to do the task on one example.
We are in the hard situation to pick the final candidate now.  Is there
anything from the GSoC formalism "paperwork" that might contribute facts
to the decision?

> Let me know ASAP which GSoC applicant, if any, you would like to accept in
> those projects.  The final deadline is 2016-04-20 at 23:59UTC (but please 
> don't
> wait, last minute acceptances are bound to fail).

Thanks for work in organising GSoC.  I hope we can find a decision until
tomorrow (2016-04-19).

Kind regards

  Andreas.

[1] http://lists.debian.org/debian-med

-- 
http://fam-tille.de



Re: Last call for GSoC intern selection!

2016-04-18 Thread Canberk Koç
Hi Andreas,

First of all i think you will pick the best candidate and due to my
mid-term exams i can't contribute more sorry for situation after exams i'll
try harder. I just want to say i learned a lot of things in the applying
stage already thanks for your help.

Best Regards,

Canberk.

2016-04-18 18:35 GMT+03:00 Andreas Tille :

> Hi Nicolas,
>
> On Mon, Apr 18, 2016 at 05:01:31PM +0200, Nicolas Dandrimont wrote:
> > > Our GSoC slots request has come and gone, and it's now time to make
> our final
> > > intern selection for both GSoC and Outreachy.
> >
> > Hey all,
> >
> > We have one unassigned GSoC slot available for each of the following
> projects :
> >
> >  - Debian-Med CI
>
> So far three students who seem to be equally qualified for this project
> have raised interest on the mailing list where we are coordinating this
> project[1] (list in CC):
>
>   Name  Number of tests just provided
>   Anna Lioznova   0
>   Canberk Koç1
>   Tatiana Malygina   1
>
> >From reading their application all seem to be qualified for the project
> and two of them have proven to be able to do the task on one example.
> We are in the hard situation to pick the final candidate now.  Is there
> anything from the GSoC formalism "paperwork" that might contribute facts
> to the decision?
>
> > Let me know ASAP which GSoC applicant, if any, you would like to accept
> in
> > those projects.  The final deadline is 2016-04-20 at 23:59UTC (but
> please don't
> > wait, last minute acceptances are bound to fail).
>
> Thanks for work in organising GSoC.  I hope we can find a decision until
> tomorrow (2016-04-19).
>
> Kind regards
>
>   Andreas.
>
> [1] http://lists.debian.org/debian-med
>
> --
> http://fam-tille.de
>
>


-- 


[image: --]

Canberk Koç
[image: https://]about.me/canberkkoc



Re: Request for sponsoring: beagle

2016-04-18 Thread Olivier Sallou


- Mail original -
> De: "Dylan" 
> À: "Debian Med Project" 
> Envoyé: Lundi 18 Avril 2016 08:11:05
> Objet: Re: Request for sponsoring: beagle
> 
> Hi,
> According to ftpmaster's comments, I removed the embedded copy of
> htsjdk and I patched some files to refer to the new htsjdk.
> But with this new patch, beagle FTBFS because jh_build searches .java
> files in .pc folder. So, I remove the .pc folder just before calling
> jh_build. I do not think it is the best solution but beagle builds
> now. Does someone have a better solution?

.pc is created with quilt when settings patches. With gbp, svn-buildpackage, 
this directory will not be present at build time, but I am surprised that 
jh_build searches for anything in .pc.
I don't think you should remove it (go against quilt and will fail unapplying 
patches). Maybe your build (build.xml, rules, ..?) makes a recursive search at 
root directory. IF this is the case, .pc should be exlcuded from search.

> 
> I also asked to upstream the source file of the pdf and he sent me a
> docx file. I do not find any information about how to integrate
> correctly a pdf from a docx file. So, I do not package the pdf
> anymore.
> 

You don't have (not mandatory) to regenerate pdf file, you can provide it as 
long as you provide the source document along with it.

Regeneration is a must to be sure everything is inline but it is accepted to 
provide pdf + source directly.

Olivier 

> Best regards,
> Dylan
> 
> 
> 
> 2016-03-26 21:45 GMT+01:00 Afif Elghraoui :
> > Hi, Dylan,
> >
> > This looks great to me. There may be an issue with the pdf manual not
> > being built from source (although the source is probably a docx file),
> > but we'll see what the archive masters say.
> >
> 
>