Re: Help needed to update to latest fastqc

[olivier.sal...@codeless.fr]

On 08/12/2015 12:44 PM, Tim Booth wrote:
> Hi Andreas and Olivier,
>
> I'm going to have a crack at the FastQC update.  I've been poking at the
> HDF5 packages and here are my conclusions so far:
I already had a look and started some work. In fact I expected to
progress on it during Debconf, but if you started it...
> ---
>
> We have 2 Free Java libraries for HDF5:
>
> 1) The "NCSA" lib distributed by hdfgroup.org with classes in namespace
> ncsa.hdf.hdf5lib, packaged on Debian as libjhdf5-java.
>
> 2) The "CISD" aka. "SIS" lib distributed by ethz.ch with classes in the
> namespace ch.systemsx, not currently packaged on Debian.
>
> The SIS library forks some Java code from the ncsa.hdf namespace, and
> also needs to link against the NCSA native library (via JNI) at runtime.
>
> So, trying to package sis-jhdf5:
>
> wget
> 'https://wiki-bsse.ethz.ch/download/attachments/26609237/sis-jhdf5-14.12.1-r33502.zip?version=1&modificationDate=1424599261225&api=v2'
> # The source is in a zip within the zip...
> unzip sis-*
> mkdir sis-jhdf5-14.12.1
> cd !$
> unzip ../sis-jhdf5/src/sis-jhdf5-src.zip
>
> For compilation to succeed, we also need sis-base, not to be confused
> with the entirely separate project at sis.apache.org!
Is it all ? In my previous check, it seemed (but not sure, it was quite
some time ago) that there were multiple dependencies (or sis-base itself
depending on other libs to package in sis repo)
>
> wget
> http://bs-svn01.ethz.ch/repos/cisd/libraries/trunk/sis-base/sis-base-src.zip
>
> The code also depends on their own args4j library, but only for the CLI
> under ch/systemsx/cisd/hdf5/h5ar/HDF5ArchiverMain.java which we can
> simply leave out just now.
>
> So - can we exclude the ncsa.hdf.hdf5lib.* classes from sis-jhdf5 and
> compile it against the existing classes in /usr/share/java/jhdf5.jar?
> My conclusion is not, because...
>
> The version of ncsa/hdf/hdf5lib/exceptions/HDF5Exception.java supplied
> with the sis-jhdf5 code subclasses RuntimeException but the version in
> libhdf5-java does not.  The result is that the code here does not need
> to declare the exceptions being thrown, and thus simply ignores them
> all.  One can go through and add all "throws" declarations (there are a
> _lot_ of them!!), but then any client code using the library will also
> break unless it is likewise patched or the code is modified to handle
> the exceptions internally. I think we'd best just admit defeat here and
> use the code supplied with sis-jhdf5.
I think that we should indeed keep the "copied" code from original, as I
think they adapted it for their needs. Makihng modifications to use
completly nca would make it unmaintainable in later updates I think.
>
> So, I'm going to try rolling two new packages, and see if that allows me
> to compile the latest FastQC:
>
> libsis-base-java (should be simple)
> libsis-jhdf5-java (depends on libsis-base-java + existing libjhdf5-jni)
>
> I'll report back on progress and commit to SVN as usual.  Let me know if
> you think I'm missing something.
>
> Cheers,
>
> TIM
>
>
> On Thu, 2015-06-25 at 09:37 +0200, Andreas Tille wrote:
>> Hi Olivier,
>>
>> any news about this hdf5lib packaging?
>>
>> Kind regards
>>
>>  Andreas.
>>
>> On Tue, May 05, 2015 at 09:25:23AM +0200, Olivier Sallou wrote:
>>>
>>> On 05/04/2015 10:52 PM, Andreas Tille wrote:
 Hi Olivier,

 On Mon, May 04, 2015 at 06:41:10PM +0200, Olivier Sallou wrote:
> File fastqc/uk/ac/babraham/FastQC/Sequence/Fast5File.java imports
> HDFS5Factory from ch.systemsx.cisd.hdf5
>
> but jhdf5.jar only contains files like:  ncsa/hdf/hdf5lib/... and no
> HDF5Factory
>
> this jhdf5 is not the correctl lib (or an other one is needed).
 I guess its this one:

 
 https://svncisd.ethz.ch/doc/hdf5/hdf5-8.10/ch/systemsx/cisd/hdf5/package-summary.html
>>> seems that original code source is the same
>>> (https://svncisd.ethz.ch/repos/cisd/jhdf5/trunk/source/java/)
>>> (/ncsa/...) but that /ch/...  has not been included for a reason
  
> In addition, in debian/patches/build.xml is missing commons-math3.jar to
> be added in pathelement for classpath.
>
> for duplicate classes, I don't yet, but hdf5 first need to be resolved.
 If I do not hear from you I'll try the URL above tomorrow (if nobody
 else might beat me which would for sure welcome as always).

 Kind regards

   Andreas.

>>> -- 
>>> Olivier Sallou
>>> IRISA / University of Rennes 1
>>> Campus de Beaulieu, 35000 RENNES - FRANCE
>>> Tel: 02.99.84.71.95
>>>
>>> gpg key id: 4096R/326D8438  (keyring.debian.org)
>>> Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438
>>>
>>>
>>> -- 
>>> 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/55487063.1090...@irisa.fr
>>>
>>>
>> -- 
>> http://fam-tille.de
>>
>>
>
> -- 

Re: Help needed to update to latest fastqc

[olivier.sal...@codeless.fr]

On 08/12/2015 08:43 PM, Tim Booth wrote:
> Hi,
>
> After a fair amount of struggling I conclude that I do not have all the
> code required to build this thing from source.
>
> The distribution of JHDF5 from
> https://wiki-bsse.ethz.ch/pages/viewpage.action?pageId=26609113
> contains some Java source code and a bunch of pre-compiled JNI shared
> libs, eg.:
>
> sis-jhdf5/lib/native/jhdf5/amd64-Linux/libjhdf5.so
>
> The source for this file is not to be found anywhere that I can see it.
> One might assume (and the FAQ implies) that the file is equivalent
> to /usr/lib/jni/libjhdf5.so provided by the exiting package libjhdf5-jni
> but it isn't!  Inspecting it with readelf shows it is full of symbols in
> the ETH SIS namespace:
>
> tbooth@balisaur[sis-jhdf5] readelf -sW 
> ./sis-jhdf5/lib/native/jhdf5/amd64-Linux/libjhdf5.so | grep ch_systemsx | head
> 19: 00039a4058 FUNCGLOBAL DEFAULT   10 
> Java_ch_systemsx_cisd_hdf5_hdf5lib_H5_H5Scopy
> 31: 0002e930   181 FUNCGLOBAL DEFAULT   10 
> Java_ch_systemsx_cisd_hdf5_hdf5lib_H5_H5Dchdir_1ext
> 35: 0003b590   918 FUNCGLOBAL DEFAULT   10 
> Java_ch_systemsx_cisd_hdf5_hdf5lib_H5_H5Sget_1select_1bounds
> 40: 000387f045 FUNCGLOBAL DEFAULT   10 
> Java_ch_systemsx_cisd_hdf5_hdf5lib_H5_H5Pcreate_1xfer_1abort
> 41: 0003882066 FUNCGLOBAL DEFAULT   10 
> Java_ch_systemsx_cisd_hdf5_hdf5lib_H5_H5Pget_1char_1encoding
> 46: 00034500   203 FUNCGLOBAL DEFAULT   10 
> Java_ch_systemsx_cisd_hdf5_hdf5lib_H5_H5Oopen
> 47: 00034ae0   363 FUNCGLOBAL DEFAULT   10 
> Java_ch_systemsx_cisd_hdf5_hdf5lib_H5_H5Pget_1version
> 52: 0003521066 FUNCGLOBAL DEFAULT   10 
> Java_ch_systemsx_cisd_hdf5_hdf5lib_H5_H5Pset_1layout
> 65: 0003c560   126 FUNCGLOBAL DEFAULT   10 
> Java_ch_systemsx_cisd_hdf5_hdf5lib_H5_H5Tget_1member_1name
> 68: 00032da058 FUNCGLOBAL DEFAULT   10 
> Java_ch_systemsx_cisd_hdf5_hdf5lib_H5_H5Idec_1ref
> ...and many more...
>
> So, this .so file is definitely specific to this library.  It seems to
> be a superset of a fork of the upstream NCSA code.  The only contact
> details I can find for the library are for Dr. Bernd Rinn who is the
> head of the whole division, but I shall contact him personally and see
> if he can pass the query on.
I will have a look on my side. I think that I found some code some times
ago, but this packaging is definitly quite hard.
could you make what you made available (sis-hdf5, sis-base etc.) so that
I avoid losing time doing the same thing to test compilation.

Olivier
>
> If Bernd can't help, then unless I've missed a trick we will have to
> consider that this library and anything that depends on it (eg FastQC)
> are not fully open source :-(
>
> Cheers,
>
> TIM
>
> On Wed, 2015-08-12 at 15:00 +0200, Andreas Tille wrote:
>> Hi Tim,
>>
>> from my *very* naive point of view your considerations make sense.
>> Olivier might have some more educated opinion (and perhaps some code?).
>>
>> I'll be available vor sponsering as usual.
>>
>> Thanks for your work on this
>>
>>  Andreas.
>>
>> On Wed, Aug 12, 2015 at 11:44:19AM +0100, Tim Booth wrote:
>>> Hi Andreas and Olivier,
>>>
>>> I'm going to have a crack at the FastQC update.  I've been poking at the
>>> HDF5 packages and here are my conclusions so far:
>>>
>>> ---
>>>
>>> We have 2 Free Java libraries for HDF5:
>>>
>>> 1) The "NCSA" lib distributed by hdfgroup.org with classes in namespace
>>> ncsa.hdf.hdf5lib, packaged on Debian as libjhdf5-java.
>>>
>>> 2) The "CISD" aka. "SIS" lib distributed by ethz.ch with classes in the
>>> namespace ch.systemsx, not currently packaged on Debian.
>>>
>>> The SIS library forks some Java code from the ncsa.hdf namespace, and
>>> also needs to link against the NCSA native library (via JNI) at runtime.
>>>
>>> So, trying to package sis-jhdf5:
>>>
>>> wget
>>> 'https://wiki-bsse.ethz.ch/download/attachments/26609237/sis-jhdf5-14.12.1-r33502.zip?version=1&modificationDate=1424599261225&api=v2'
>>> # The source is in a zip within the zip...
>>> unzip sis-*
>>> mkdir sis-jhdf5-14.12.1
>>> cd !$
>>> unzip ../sis-jhdf5/src/sis-jhdf5-src.zip
>>>
>>> For compilation to succeed, we also need sis-base, not to be confused
>>> with the entirely separate project at sis.apache.org!
>>>
>>> wget
>>> http://bs-svn01.ethz.ch/repos/cisd/libraries/trunk/sis-base/sis-base-src.zip
>>>
>>> The code also depends on their own args4j library, but only for the CLI
>>> under ch/systemsx/cisd/hdf5/h5ar/HDF5ArchiverMain.java which we can
>>> simply leave out just now.
>>>
>>> So - can we exclude the ncsa.hdf.hdf5lib.* classes from sis-jhdf5 and
>>> compile it against the existing classes in /usr/share/java/jhdf5.jar?
>>> My conclusion is not, because...
>>>
>>> The version of ncsa/hdf/hdf5lib/exceptions/HDF5Exception.java supplied
>>> with the sis-jhdf5 code subclasses RuntimeException but the version in
>>> libh

Re: gcc-5 transition of GDCM

[Andreas Tille]

Hi Michka,

I keep the Debian maintainer Aron Xu in CC.  Gccxml was maintained as a
predependency of some Debian Med package by the according team.  I'm not
aware that python-pygccxml has any reverse dependencies in Debian Med
but surely ITK is of interest.  Could the ITK people please raise their
opinion whether it would be good to team maintain this package here as
well.  Aron, would you consider using some common Git repository either
in Debian Med or collab-maint?

Kind regards

 Andreas.

On Thu, Aug 13, 2015 at 08:37:13AM +0200, michkapop...@gmail.com wrote:
> > On August 5, 2015 03:29:30 PM Sébastien Jodogne wrote:
> > 
> >>> I will try hard to get the script into VCS tonight and then I will welcome
> >>> help in testing the builds on dependent packages.
> >> 
> >> Great! Let me know when things are ready.
> > 
> > OK.  The gccxml package is updated with a wrapper around castxml (the real
> > binary is renamed to gccxml.real).
> > 
> > Still working on testing build-deps with it.  Sadly, pygccxml fails :-(
> > 
> > -Steve
> > 
> 
> Hi
> 
> I was told someone mentioned pygccxml here :)
> 
> I am the current maintainer of the project 
> (https://github.com/gccxml/pygccxml ).
> During the last months I worked on the integration of CastXML in pygccxml and 
> I am
> almost done. Basically, there were around 80 unit tests failing, and I am down
> to 10 failing tests. The core unit tests are running, and ITK already uses 
> pygccxml
> internally. So as long as one does not do fancy stuff, it should be ok.
> 
> I delayed the new release in the hope to be able to fix the remaining tests; 
> but this
> takes a lot of time (as I did not write pygccxml in the first place, I am 
> discovering
> the code). But I think there is some pressure to release a new version with 
> basic
> support so people can start using it. I even heard from 1 or 2 people which 
> are using
> the current unstable version in combination with pyplusplus to build their 
> project
> using CastXML instead of GccXML.
> 
> I will publish a new pygccxml version (1.7.0) in the next weeks. The package 
> name
> will not change, and is backwards compatible with gccxml. I will temporarily 
> disable
> the failing tests when running with CastXML.
> 
> Please tell me if I need to notify someone when the new version is out or if 
> there
> is something I can to to help the packaging. pygccxml will also be available
> through pip.
> 
> Regards
> 
> Michka
> 
> 
> 
> 

-- 
http://fam-tille.de

Re: gcc-5 transition of GDCM

[Aron Xu]

Actually I'm seeking to orphan the package as I don't use it myself
anymore, but it's not a burden so far so that I haven't done it yet.
If there are people interested in adopting or co-maintaining it'll be
appreciated. There's no any form of repository at the moment and I can
create one if no one else is more interested, :)

Thanks,
Aron

On Thu, Aug 13, 2015 at 3:29 PM, Andreas Tille  wrote:
> Hi Michka,
>
> I keep the Debian maintainer Aron Xu in CC.  Gccxml was maintained as a
> predependency of some Debian Med package by the according team.  I'm not
> aware that python-pygccxml has any reverse dependencies in Debian Med
> but surely ITK is of interest.  Could the ITK people please raise their
> opinion whether it would be good to team maintain this package here as
> well.  Aron, would you consider using some common Git repository either
> in Debian Med or collab-maint?
>
> Kind regards
>
>  Andreas.
>
> On Thu, Aug 13, 2015 at 08:37:13AM +0200, michkapop...@gmail.com wrote:
>> > On August 5, 2015 03:29:30 PM Sébastien Jodogne wrote:
>> >
>> >>> I will try hard to get the script into VCS tonight and then I will 
>> >>> welcome
>> >>> help in testing the builds on dependent packages.
>> >>
>> >> Great! Let me know when things are ready.
>> >
>> > OK.  The gccxml package is updated with a wrapper around castxml (the real
>> > binary is renamed to gccxml.real).
>> >
>> > Still working on testing build-deps with it.  Sadly, pygccxml fails :-(
>> >
>> > -Steve
>> > 
>>
>> Hi
>>
>> I was told someone mentioned pygccxml here :)
>>
>> I am the current maintainer of the project 
>> (https://github.com/gccxml/pygccxml ).
>> During the last months I worked on the integration of CastXML in pygccxml 
>> and I am
>> almost done. Basically, there were around 80 unit tests failing, and I am 
>> down
>> to 10 failing tests. The core unit tests are running, and ITK already uses 
>> pygccxml
>> internally. So as long as one does not do fancy stuff, it should be ok.
>>
>> I delayed the new release in the hope to be able to fix the remaining tests; 
>> but this
>> takes a lot of time (as I did not write pygccxml in the first place, I am 
>> discovering
>> the code). But I think there is some pressure to release a new version with 
>> basic
>> support so people can start using it. I even heard from 1 or 2 people which 
>> are using
>> the current unstable version in combination with pyplusplus to build their 
>> project
>> using CastXML instead of GccXML.
>>
>> I will publish a new pygccxml version (1.7.0) in the next weeks. The package 
>> name
>> will not change, and is backwards compatible with gccxml. I will temporarily 
>> disable
>> the failing tests when running with CastXML.
>>
>> Please tell me if I need to notify someone when the new version is out or if 
>> there
>> is something I can to to help the packaging. pygccxml will also be available
>> through pip.
>>
>> Regards
>>
>> Michka
>>
>>
>>
>>
>
> --
> http://fam-tille.de



-- 
Regards,
Aron Xu

Re: DWV (DICOM Web Viewer)

[Yves]

Hi Sébastien,

I did not progress on this topic but I will try to find some time to study
these examples. Thanks for the update!

Best,
Yves

On 8 August 2015 at 11:05, Sébastien Jodogne 
wrote:

> Hi Yves,
>
> > My name is Yves, I'm developing a pure javascript DICOM viewer called
> dwv.
> > It is released under GPL and available at
> https://github.com/ivmartel/dwv.
> > The viewer can be used on its own but also bundled in a PACS. In the case
> > of the Orthanc PACS, I created a plugin called DwvExplorer, also GPL and
> > available at https://github.com/ivmartel/DwvExplorer. It is very
> similar to
> > the orthanc-webviewer from Sebastien Jodogne except that the C++ code is
> > just there to redirect the http requests and extend the default web
> > explorer.
> >
> > Would a package of this plugin be of interest to you? If so, I would need
> > help since I'm totally new to debian...
>
> I was wondering whether there were news about the Debian packaging of your
> DWV plugin for Orthanc. I think this would be really cool to offer Debian
> users of Orthanc the freedom to choose between two independent Web-based
> viewers.
>
> There are now three examples of packaged Orthanc plugins [1,2,3] that
> might be useful for this work.
>
> Do not hesitate to get in touch with me if you need any help.
>
> Regards,
> Sébastien-
>
>
> [1]
> http://anonscm.debian.org/viewvc/debian-med/trunk/packages/orthanc-dicomweb/trunk/debian/
> [2]
> http://anonscm.debian.org/viewvc/debian-med/trunk/packages/orthanc-postgresql/trunk/debian/
> [3]
> http://anonscm.debian.org/viewvc/debian-med/trunk/packages/orthanc-webviewer/trunk/debian/
>

samtools 1.2 package layout change

[Tim Booth]

Hi Charles,

I was looking to see if it was worth pulling the samtools 1.2 package
into Bio-Linux (Ubuntu LTS Backports) and I can see that the package for
1.2 has all the utility scripts going into /usr/bin where before they
were in /usr/{lib,share}/samtools.  A slew of Lintian warnings results.

I wondered if this is a deliberate change or just an artefact of the new
build system?  I'd be happy to commit a fix that either restores the old
layout or else adds Lintian overrides.  What do you think?

Actually, I see from previous discussion on the list that I should wait
for the 1.3 release which builds on i386, but I think the above question
will still apply.

Cheers,

TIM

On Thu, 2015-08-13 at 08:02 +0900, Charles Plessy wrote:
> Hello everyone,
> 
> in conclusion, wgsim stays in samtools, where it will only get bug fixes, but
> no further developments. 
> 
> https://github.com/samtools/samtools/issues/429#issuecomment-129412846
> 
> Have a nice day,
> 

-- 
Nothing is inherently mysterious - nothing that actually exists, that
is.  If I am ignorant about a phenomenon, that is a fact about my state
of mind, not a fact about the phenomenon; to worship a phenomenon
because it seems so wonderfully mysterious, is to worship your own
ignorance.

  - Eliezer Yudkowsky

Re: Help needed to update to latest fastqc

[Tim Booth]

Hi Olivier,

Looks like Bernd Rinn is making positive noises regarding a DFSG version
of the library, so hopefully once he provides code you can take what I
have done and make use of it.  I committed to SVN because it's so much
easier than pushing to GIT and I'm lazy, sorry.

In my libsis-jhdf5-java package I created a small test
"ReadWriteTest.java" which I confirmed works correctly when used with
the binary libhdf5.so supplied by upstream.  Also my patches
fix_dodgy_cast.patch and remove_ch_rinn_imports.patch should be sound
but the others are junk caused by me trying to kick the code into
submission.

If for some reason we can't get this working then you could very easily
patch out FAST5 support in FastQC for now.  My impression is that it's
something of an alpha feature in any case.  I can't even find a .fast5
format file to test with!

>>>PATCH for FASTQC
This patch disables support for FAST5 format until we get the library built.
Most users won't need this anyway, and those that do can convert the file
to FASTQ using other tools.

Note you also need to completely remove the file
uk/ac/babraham/FastQC/Sequence/Fast5File.java, which I can't do in a quilt 
patch.

Tim Booth - 13th Aug 2015
--- a/uk/ac/babraham/FastQC/Sequence/SequenceFactory.java
+++ b/uk/ac/babraham/FastQC/Sequence/SequenceFactory.java
@@ -100,7 +100,8 @@
return new BAMFile(file,false);
}
else if (file.getName().toLowerCase().endsWith(".fast5")) {
-   return new Fast5File(file);
+   //return new Fast5File(file);
+   throw new SequenceFormatException("Support for FAST5 
files has not been enabled in this build of FastQC.");
}
else {
return new FastQFile(config,file);
<<

MOM: reportbug fails

[Malihe Asemani]

Hi Andreas,

The reportbug command fails, every time I tried to report a bug for
king-probe:

mali@buildEnv:/home/mali/med/probe$  LC_ALL=C reportbug wnpp
^[[A/usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py:57:
GtkWarning: could not open display
  warnings.warn(str(e), _gtk.Warning)
*** Welcome to reportbug.  Use ? for help at prompts. ***
Note: bug reports are publicly archived (including the email address of the
submitter).
Detected character set: us-ascii
Please change your locale if this is incorrect.

Using 'Malihe Asemani ' as your from address.
Will send report to Debian (per lsb_release).
What sort of request is this? (If none of these things mean anything to
you, or you are trying to report a bug in an existing package, please
press Enter to exit reportbug.)

1 ITP  This is an `Intent To Package'. Please submit a package description
along with copyright and URL in such a report.
2 OThe package has been `Orphaned'. It needs a new maintainer as soon
as possible.
3 RFA  This is a `Request for Adoption'. Due to lack of time, resources,
interest or something similar, the current maintainer is asking for
   someone else to maintain this package. They will maintain it in the
meantime, but perhaps not in the best possible way. In short: the
   package needs a new maintainer.
4 RFH  This is a `Request For Help'. The current maintainer wants to
continue to maintain this package, but they needs some help to do this,
   because their time is limited or the package is quite big and needs
several maintainers.
5 RFP  This is a `Request For Package'. You have found an interesting piece
of software and would like someone else to maintain it for Debian.
   Please submit a package description along with copyright and URL in
such a report.

Choose the request type: 1
Please enter the proposed package name: king-probe
Checking status database...
Please briefly describe this package; this should be an appropriate short
description for the eventual package:
>  Evaluate and visualize protein interatomic
packing
Your report will be carbon-copied to debian-devel, per Debian policy.
Querying Debian BTS for reports on wnpp (source)...
Traceback (most recent call last):
  File "/usr/bin/reportbug", line 2211, in 
main()
  File "/usr/bin/reportbug", line 1081, in main
return iface.user_interface()
  File "/usr/bin/reportbug", line 1703, in user_interface
latest_first=self.options.latest_first)
  File "/usr/lib/python2.7/dist-packages/reportbug/ui/text_ui.py", line
517, in handle_bts_query
source=source, http_proxy=http_proxy, archived=archived)
  File "/usr/lib/python2.7/dist-packages/reportbug/debbugs.py", line 1277,
in get_reports
stats = debianbts.get_status(bugs)
  File "/usr/lib/pymodules/python2.7/debianbts.py", line 179, in get_status
reply = server.get_status(*nr)
  File "/usr/lib/python2.7/dist-packages/SOAPpy/Client.py", line 545, in
__call__
return self.__r_call(*args, **kw)
  File "/usr/lib/python2.7/dist-packages/SOAPpy/Client.py", line 567, in
__r_call
self.__hd, self.__ma)
  File "/usr/lib/python2.7/dist-packages/SOAPpy/Client.py", line 430, in
__call
timeout = self.timeout)
  File "/usr/lib/python2.7/dist-packages/SOAPpy/Client.py", line 318, in
call
raise HTTPError(code, msg)
SOAPpy.Errors.HTTPError: 

Any Idea?

Re: MOM: reportbug fails

[Andreas Tille]

Hi,

On Thu, Aug 13, 2015 at 09:44:05PM +0430, Malihe Asemani wrote:
> Your report will be carbon-copied to debian-devel, per Debian policy.
> Querying Debian BTS for reports on wnpp (source)...
> Traceback (most recent call last):
>  ...
> SOAPpy.Errors.HTTPError: 
> 
> Any Idea?

A websearch uncovered that this is reported in bug #789047.

But there is a very simple workaround which you want for ITP bugs
anyway:

reportbug  --no-query-bts  wnpp

It does not make sense to query wnpp bugs anyway if you know in advance
that the bug in question is not reported. :-)

Hope this helps

 Andreas.

-- 
http://fam-tille.de

Re: gcc-5 transition of GDCM

[michkapopoff]

Hi

thanks for your insights. I guess python-pygccxml is not directly needed
here in Debian Med. On ITK’s side, pygccxml is present in ITK’s repo
as a subtree. So it is not needed as a dependency, and there is no plan
to change this.

I’ll leave the decision up to you. I personally recommend people to install
it through pip, which is the fastest way to get it. Having a debian package of
course better; maybe as there is already one it would only need an update
to the newest version.

I am not ready to maintain the package myself for the moment, as I have
other ongoing projects. But I can help if there are any questions.
Tell me if you want to update the package; I’ll send a mail to Aron
as soon as the new version is out.

Regards

Michka

> On 13 Aug 2015, at 13:30, Aron Xu  wrote:
> 
> Actually I'm seeking to orphan the package as I don't use it myself
> anymore, but it's not a burden so far so that I haven't done it yet.
> If there are people interested in adopting or co-maintaining it'll be
> appreciated. There's no any form of repository at the moment and I can
> create one if no one else is more interested, :)
> 
> Thanks,
> Aron
> 
> On Thu, Aug 13, 2015 at 3:29 PM, Andreas Tille  wrote:
>> Hi Michka,
>> 
>> I keep the Debian maintainer Aron Xu in CC.  Gccxml was maintained as a
>> predependency of some Debian Med package by the according team.  I'm not
>> aware that python-pygccxml has any reverse dependencies in Debian Med
>> but surely ITK is of interest.  Could the ITK people please raise their
>> opinion whether it would be good to team maintain this package here as
>> well.  Aron, would you consider using some common Git repository either
>> in Debian Med or collab-maint?
>> 
>> Kind regards
>> 
>> Andreas.
>> 
>> On Thu, Aug 13, 2015 at 08:37:13AM +0200, michkapop...@gmail.com wrote:
 On August 5, 2015 03:29:30 PM Sébastien Jodogne wrote:
 
>> I will try hard to get the script into VCS tonight and then I will 
>> welcome
>> help in testing the builds on dependent packages.
> 
> Great! Let me know when things are ready.
 
 OK.  The gccxml package is updated with a wrapper around castxml (the real
 binary is renamed to gccxml.real).
 
 Still working on testing build-deps with it.  Sadly, pygccxml fails :-(
 
 -Steve
 
>>> 
>>> Hi
>>> 
>>> I was told someone mentioned pygccxml here :)
>>> 
>>> I am the current maintainer of the project 
>>> (https://github.com/gccxml/pygccxml ).
>>> During the last months I worked on the integration of CastXML in pygccxml 
>>> and I am
>>> almost done. Basically, there were around 80 unit tests failing, and I am 
>>> down
>>> to 10 failing tests. The core unit tests are running, and ITK already uses 
>>> pygccxml
>>> internally. So as long as one does not do fancy stuff, it should be ok.
>>> 
>>> I delayed the new release in the hope to be able to fix the remaining 
>>> tests; but this
>>> takes a lot of time (as I did not write pygccxml in the first place, I am 
>>> discovering
>>> the code). But I think there is some pressure to release a new version with 
>>> basic
>>> support so people can start using it. I even heard from 1 or 2 people which 
>>> are using
>>> the current unstable version in combination with pyplusplus to build their 
>>> project
>>> using CastXML instead of GccXML.
>>> 
>>> I will publish a new pygccxml version (1.7.0) in the next weeks. The 
>>> package name
>>> will not change, and is backwards compatible with gccxml. I will 
>>> temporarily disable
>>> the failing tests when running with CastXML.
>>> 
>>> Please tell me if I need to notify someone when the new version is out or 
>>> if there
>>> is something I can to to help the packaging. pygccxml will also be available
>>> through pip.
>>> 
>>> Regards
>>> 
>>> Michka
>>> 
>>> 
>>> 
>>> 
>> 
>> --
>> http://fam-tille.de
> 
> 
> 
> -- 
> Regards,
> Aron Xu

Re: samtools 1.2 package layout change

[Charles Plessy]

Le Thu, Aug 13, 2015 at 03:03:34PM +0100, Tim Booth a écrit :
> 
> I was looking to see if it was worth pulling the samtools 1.2 package
> into Bio-Linux (Ubuntu LTS Backports) and I can see that the package for
> 1.2 has all the utility scripts going into /usr/bin where before they
> were in /usr/{lib,share}/samtools.  A slew of Lintian warnings results.
> 
> I wondered if this is a deliberate change or just an artefact of the new
> build system?  I'd be happy to commit a fix that either restores the old
> layout or else adds Lintian overrides.  What do you think?

Hi Tim,

in the current 1.2 package, the scripts are installed in /usr/bin by the
upstream build system, while before version 1.0 we installed them by hand in
/usr/share, since they were not installed by the upstream build system.

For the sake of compatibility with other distributions and platforms (that is,
the rest of the World), I think that we should not remove the file extensions.
Feel free to add a Lintian overrides.  On my side, I am not doing so because
overrides should be for false positives, while here it is the Policy that is
plain wrong.

Regarding missing manpages, before writing them I would recommend to contact
upstream to make sure they would adopt them and maintain them.  Otherwise, they
will bitrot and we will send wrong information to our users, again in a "only
Debian does it wrong" way.  For these Lintian warnings, I also do not write
overrides because they are true positives.  But feel free to override them if
they annoy you.

For "spelling-error-in-manpage" "allows to allows one to", once one upstream
developer who was native speaker disagreed; since then I ignore this "spelling
error".

I think that "spelling-error-in-binary usr/bin/samtools compres compress" is a
false positive; sorry for not overriding it earlier.  "compres" only appears
in the output of "strings /usr/bin/samtools" in a way that does not seem
to be related to user output, and not in the source code.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: Please update from ITK v3 to v4 [Re: RM: insighttoolkit -- ROM; Obsoleted by insighttoolkit4]

[Steve M. Robbins]

On August 13, 2015 01:47:37 PM Dmitry Smirnov wrote:
> On Wednesday 12 August 2015 22:01:36 Steve M. Robbins wrote:
> > Could those package maintainers update to v4, please?
> 
> First ITK-4 needs to be re-build for GCC-5 transition. 

Yes, true.  

There is work in progress on that front [1].  I'm at the point of testing 
whether ITK v4 builds in sid.  I was stalled last week because the libvtk6-dev 
dependency of ITK wasn't installable in sid.  It still is.


[1] https://lists.debian.org/debian-med/2015/08/msg00010.html

-Steve


signature.asc
Description: This is a digitally signed message part.