Re: insighttoolkit vs tiff5

2012-05-10 Thread Mathieu Malaterre
Okay let's do this.

On Wed, May 9, 2012 at 6:02 PM, Dominique Belhachemi domi...@debian.org wrote:
 I think we should use libtiff-dev only and file bugs against the
 consuming package if build errors appear.
 -Dominique

 On Wed, May 9, 2012 at 10:58 AM, Mathieu Malaterre ma...@debian.org wrote:
 Hi there,

  With ref to #672242, does anyone see any reason to not go back and
 use libtiff4-dev in insighttoolkit. Upstream does not clearly support
 tiff 4.0.0 anyway.

  My only fear is that libtiff5-dev and libtiff4-dev will conflicts at
 some point in a package trying to use them both.

 Comments welcome
 -M


 --
 To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: 
 http://lists.debian.org/ca+7wusyzx7qb4prnj2b2jprpxi4c8ulbfmq7-mzurnkwrw6...@mail.gmail.com




-- 
Mathieu


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+7wusy7yls41zsl5n9toubs5rsx+dr0nhgrjzuydlgjkzt...@mail.gmail.com



Build issue when building with gcc-4.7

2012-05-10 Thread Andreas Tille
Hi,

when building libhmsbeagle using gcc version 4.7 you get a build error
which can be easily fixed (see patch in Debian Med SVN[1])

Before I upload a package featuring this patch I would like to clarify
something which remains not clear to me.  The first thing is that I'm a
bit unsure what version you might consider as stable for Debian
release.  The homepage[2] is featuring version 1.0.  However, our watch
file (containing the metainformation from where to download the source
which needs to point to tagged SVN releases because you are not
providing a downloadable source tarball) points to SVN tags[3] and finds
version 1.1.  So which one is the one you want Debian to distribute?
BTW, questions like this will not occure if you would provide versioned
a source tarball at the homepage directly.

The second issue is about the problem which was discussed in the
beginning of this year[4] about SSE support.  I have noticed that you
seem to have dealt with this but at least if I build not really
successfully.  I can not build on my amd64 machine if I do not at least
add this patch:


--- libhmsbeagle-1.1.orig/configure.ac
+++ libhmsbeagle-1.1/configure.ac
@@ -211,6 +211,9 @@
 if test  $enable_sse = yes; then
SSE_CFLAGS+=-DENABLE_SSE
 AM_CXXFLAGS=$AM_CXXFLAGS -msse2
+AM_CONDITIONAL(HAVE_SSE2,true)
+else
+AM_CONDITIONAL(HAVE_SSE2,false)
 fi

 # 
--


Otherwise automake is claimin missing AM_CONDITIONAL statement for
HAVE_SSE2.  Moreover I think the way you changed
libhmsbeagle/CPU/Makefile.am is not sufficiently preventing that the
build system tries to build libhmsbeagle-cpu-sse.la on non-Intel
architectures.  The first line says:

lib_LTLIBRARIES=libhmsbeagle-cpu.la libhmsbeagle-cpu-sse.la

and thus libhmsbeagle-cpu-sse.la is an unconditional target which is not
handled by the HAVE_SSE2 conditional.  It might be that the HAVE_SSE2
condition has a completely different purpose than the patch from
Debian[5] which was using HAVE_SSE and thus I would like to make sure
I have understood things properly first before I upload.

Kind regards and thanks for providing libhmsbeagle as Free Software

  Andreas.

[1] 
http://anonscm.debian.org/viewvc/debian-med/trunk/packages/libhmsbeagle/trunk/debian/patches/gcc-4.7.patch?view=markup
[2] http://code.google.com/p/beagle-lib/
[3] http://beagle-lib.googlecode.com/svn/tags/
[4] http://bugs.debian.org/656755
[5] 
http://anonscm.debian.org/viewvc/debian-med/trunk/packages/libhmsbeagle/trunk/debian/patches/disable_cpu_sse_plugin.patch?revision=9433view=markup

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120510095938.gg3...@an3as.eu



Re: Fix for Bug#672090: bowtie2: ftbfs with GCC-4.7

2012-05-10 Thread Alex Mestiashvili
On 05/09/2012 03:57 PM, Andreas Tille wrote:
 Hi Alex,

 On Wed, May 09, 2012 at 03:15:04PM +0200, Alex Mestiashvili wrote:
   
 I've prepared patch to fix #672090.

 Could you please check  upload it.
 
 Uploaded.  As I said in BTS IMHO also #668123 is fixed.  We will see how
 the just uploaded version builds on other architectures and might close
 the bug manually afterwards.

 Thanks for working on this

Andreas.

   
Thank you,

As I see now, it fails to build on i386. I think problem comes from
Makefile.
I will get a real i386 box and try to fix it. In 32bit chroot on amd64 I
could built it successfully.
And it still fails on other architectures than amd64.

Best regards,
Alex



-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4faba2fd.4050...@biotec.tu-dresden.de



Re: Do we track releases or development versions [Was: r-bioc-cummerbund ... upstream/1.1.3-17-gae72ebb]

2012-05-10 Thread Carlos Borroto
On Tue, May 8, 2012 at 3:22 PM, Andreas Tille andr...@an3as.eu wrote:
 On Tue, May 08, 2012 at 11:32:11AM -0400, Carlos Borroto wrote:

 I agree on following stable releases as a general rule. The reason I
 chose to use development version of cummeRbund was because at the time
 upstream was recommending it. The package was on heavy development and
 stable releases tied to Bioconductor were getting behind quite fast. I
 just checked the upstream website and now the recommendation is to use
 the stable version tied to Bioconductor.

 I just finish my semester yesterday and I plan to get up to speed with
 several TODOs I have with the packages I'm contributing to.

 Thanks for the clarification.

 I'll do this update right away.

 Just let us know if you need any help / sponsoring.


Hi Andreas,

I'm taking a look at this package and everything seems ready. I see
you already fixed the watch file. Regarding citation, I haven't read
yet how we are doing this, but I will soon. Do you wan't me to get the
changelog ready and ask for sponsoring? Or do you have something else
in mind that should be tackle before submission?

Thanks,
Carlos


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CABgGhBLoz2DPcaM=g4RAjhzZ6uxf4uiP0_-PxG6VPK3tb=c...@mail.gmail.com



Re: Do we track releases or development versions [Was: r-bioc-cummerbund ... upstream/1.1.3-17-gae72ebb]

2012-05-10 Thread Andreas Tille
On Thu, May 10, 2012 at 10:25:45AM -0400, Carlos Borroto wrote:
 
 I'm taking a look at this package and everything seems ready. I see
 you already fixed the watch file.

Yep.  I fixed it and afterwards I have read the comment. :-) This made
me a bit unsure ...

 Regarding citation, I haven't read
 yet how we are doing this, but I will soon.

See

http://wiki.debian.org/UpstreamMetadata

At very bottom you'll find a template.  There are  100 examples in our
Vcs (SVN+Git).

 Do you wan't me to get the
 changelog ready and ask for sponsoring? Or do you have something else
 in mind that should be tackle before submission?

It would be reasonable if you ping me once you are finished.  I do not
have additional plans for changes.

Kind regards

Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120510202033.gj3...@an3as.eu



Re: Fix for Bug#672090: bowtie2: ftbfs with GCC-4.7

2012-05-10 Thread Andreas Tille
On Thu, May 10, 2012 at 01:14:05PM +0200, Alex Mestiashvili wrote:
 As I see now, it fails to build on i386. I think problem comes from
 Makefile.

:-(

 I will get a real i386 box and try to fix it.

If you will not succeede getting such a box, you might like to use
debian-med.debian.net.  There is pbuilder and sbuild installed on this
machine.

 In 32bit chroot on amd64 I
 could built it successfully.
 And it still fails on other architectures than amd64.

:-(
Is this a problem in the code or just a broken Makefile?

Kind regards

Andreas. 

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120510202249.gk3...@an3as.eu



Re: MOM: Expression of Interest

2012-05-10 Thread Andreas Tille
Hi Ismail,

thanks for your interest in MoM.  At first it would be cool if you would
confirm that you are reading the list debian-med@lists.debian.org which
would enable me to leave out CC to you personally which is unusual on
this list.

On Thu, May 10, 2012 at 06:34:35PM +0100, ismail adegbenga wrote:
 Hi Andreas,
 I am a follower of the gnumed-devel mailig list.
 I just read your mail showing your intent to mentor a student on the above
 list.

I really liked that Sebastian forewarded my mail and I'm happy to teach
you about the things you need to work on the packages.

 I am not a programmer, although I am willing to learn and contribute
 something to the growth of FOSS.

It does not harm if you have some coding skills but it is not required
specifically not if the package in question you are targeting is
basically packaged and just needs updates.

 I am a Debian-Sid user.
 I have noticed the relatively slow pace at which updates appear in
 Debian.

Is this concerning the gnumed packages?  Just to make sure we are
talking about the same thing:  I think we are quite good behind upstream
GNUmed to package for Debian *unstable*.  If you are concerned about
getting these packages into Debian *stable* that's something else and
would be only possible via backports.  Could you go a bit more into
detail what would you consider a faster pace (just to understand what
you are gaining for - I'm by all means for an enhancement, just to
make sure we adjust our time scale properly. :-)).

 I am assuming this is due to the few number of people involved
 in packaging upstream updates
 I am willing to learn and contribute if this will improve the general
 state of things. 

I'd be very happy if somebody else would update the GNUmed packages in
SVN and I would just need to pull the status and upload.

To start with the MoM poject I'd suggest you put your name on the Wiki
page[1] and read the Debian Med policy which is linked under Helpful
Links.  This gives basic advise what to do to get commit permissions to
the SVN repository.

If you have any question about this - even if you think it might sound
stupid just ask here in public.  There are no such things like stupid
questions - only not asking is stupid.  We need this communication to
adjust the mentoring topics.

Kind regards and thanks again for your interest to help Debian Med

Andreas.

[1] http://wiki.debian.org/DebianMed/MoM

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120510205205.gn3...@an3as.eu



Re: MOM: Expression of Interest

2012-05-10 Thread Karsten Hilbert
On Thu, May 10, 2012 at 10:52:05PM +0200, Andreas (Debian) wrote:

  I am a follower of the gnumed-devel mailig list.
  I just read your mail showing your intent to mentor a student on the above
  list.
 
 I really liked that Sebastian forewarded my mail and I'm happy to teach
 you about the things you need to work on the packages.

I would agree to serve as technical upstream contact.

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120510210752.gg3...@hermes.hilbert.loc