python-cobra seems to resist backporting :-( [python-cobra_0.4.0b2-1~bpo8+1_amd64.changes REJECTED]
I've never seen this. :-( Any idea Andreas. - Forwarded message from Debian FTP Masters ftpmas...@ftp-master.debian.org - Date: Mon, 17 Aug 2015 09:22:57 + From: Debian FTP Masters ftpmas...@ftp-master.debian.org To: Debian Med Packaging Team debian-med-packag...@lists.alioth.debian.org, Afif Elghraoui a...@ghraoui.name, ti...@debian.org Subject: python-cobra_0.4.0b2-1~bpo8+1_amd64.changes REJECTED python-cobra_0.4.0b2-1~bpo8+1.dsc: Invalid size hash for python-cobra_0.4.0b2.orig.tar.gz: According to the control file the size hash should be 2264579, but python-cobra_0.4.0b2.orig.tar.gz has 2231532. If you did not include python-cobra_0.4.0b2.orig.tar.gz in your upload, a different version might already be known to the archive software. === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. ___ 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 - -- http://fam-tille.de
Re: python-cobra seems to resist backporting :-( [python-cobra_0.4.0b2-1~bpo8+1_amd64.changes REJECTED]
On الإثنين 17 آب 2015 04:39, Andreas Tille wrote: I've never seen this. :-( Any idea Andreas. Like Olivier said, it looks like the orig.tar.gz is not the same for some reason. I don't understand why--all I did was merge the master branch into the backports branch. Git correctly shows that the only difference between the version in unstable and the backports version is the changelog. The size hash of the .orig.tar.gz on my machine matches what this says it should be: $ ls -l python-cobra_0.4.0b2.orig.tar.gz -rw-rw-r-- 1 afif afif 2264579 Aug 10 02:19 python-cobra_0.4.0b2.orig.tar.gz Did it get corrupted somehow? Thanks and regards Afif - Forwarded message from Debian FTP Masters ftpmas...@ftp-master.debian.org - Date: Mon, 17 Aug 2015 09:22:57 + From: Debian FTP Masters ftpmas...@ftp-master.debian.org To: Debian Med Packaging Team debian-med-packag...@lists.alioth.debian.org, Afif Elghraoui a...@ghraoui.name, ti...@debian.org Subject: python-cobra_0.4.0b2-1~bpo8+1_amd64.changes REJECTED python-cobra_0.4.0b2-1~bpo8+1.dsc: Invalid size hash for python-cobra_0.4.0b2.orig.tar.gz: According to the control file the size hash should be 2264579, but python-cobra_0.4.0b2.orig.tar.gz has 2231532. If you did not include python-cobra_0.4.0b2.orig.tar.gz in your upload, a different version might already be known to the archive software. -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Re: python-cobra seems to resist backporting :-( [python-cobra_0.4.0b2-1~bpo8+1_amd64.changes REJECTED]
On 08/17/2015 01:39 PM, Andreas Tille wrote: I've never seen this. :-( Any idea Andreas. - Forwarded message from Debian FTP Masters ftpmas...@ftp-master.debian.org - Date: Mon, 17 Aug 2015 09:22:57 + From: Debian FTP Masters ftpmas...@ftp-master.debian.org To: Debian Med Packaging Team debian-med-packag...@lists.alioth.debian.org, Afif Elghraoui a...@ghraoui.name, ti...@debian.org Subject: python-cobra_0.4.0b2-1~bpo8+1_amd64.changes REJECTED python-cobra_0.4.0b2-1~bpo8+1.dsc: Invalid size hash for python-cobra_0.4.0b2.orig.tar.gz: According to the control file the size hash should be 2264579, but python-cobra_0.4.0b2.orig.tar.gz has 2231532. maybe try to get orig.tar.gz from Debian web site and use it for your build. Maybe your local orig.tar.gz is not the same (compression timestamp...) If you did not include python-cobra_0.4.0b2.orig.tar.gz in your upload, a different version might already be known to the archive software. === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. ___ 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 - -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Re: Help needed to update to latest fastqc
Hi Olivier,
I'm working with your updated libsis-base package. It compiles OK but I
had to tinker with the library loading to get the self tests to pass
(sse below).
I've modified the package to build according to
https://www.debian.org/doc/packaging-manuals/java-policy/x104.html. Both
native .so libraries are JNI so they are tightly bound to the Java
wrapper and no other code should ever link to them. My impression is
that therefore they should go into /usr/lib/jni and either be
un-versioned or else named like:
libcisd-nativedata-14.12.0.so
Because the .so file has to precisely match the version of the .jar file
and they can and should be updated in lock step. The usual
considerations about major.minor.bugfix versioning don't apply.
On that topic, the Java code in libsis-base loads both these libraries
on a best-effort basis and tries to fall back to native routines the
code is unavailable. I'd advocate bypassing all this with a direct call
to eg. System.loadLibrary(cisd_unix);, on the assumption that all
Debian users expect to have the native libraries loaded. The result is
that you then get an informative no such native library error right
away rather than a cryptic failure later on.
What do you think? I've committed my simplified build so you can see
what I've done. If you think I've messed it up then just revert to
r19959 which was your last version.
Cheers,
TIM
On Sun, 2015-08-16 at 17:20 +0200, olivier.sal...@codeless.fr wrote:
On 08/14/2015 10:48 AM, Tim Booth wrote:
Hi Olivier,
http://anonscm.debian.org/viewvc/debian-med/trunk/packages/libsis-base-java/
http://anonscm.debian.org/viewvc/debian-med/trunk/packages/libsis-jhdf5-java/
I've not modified FastQC at all. Or rather, I tried patching out the
FAST5 support but I just did that within the vanilla source; I'm not
playing with the package from GIT at this point.
Ok, libsis-base-java sounds good (except a few remaining polishing).
However, you can take code from svn and build package. autotests are fine.
I have updated libsis-jhdf5-java in svn too to generate native libs,
java lib (what you already did) and launch tests.
Libraries compilation is ok (.so and .jar), but tests fail when using
native libs (load is ok). I don't know why and am struggling with it, as
error message does not help (failed to instanciate). If you want to have
a look I gonna continue ot investiguate.
Olivier
Cheers,
TIM
On Fri, 2015-08-14 at 08:16 +0200, olivier.sal...@codeless.fr wrote:
On 08/13/2015 05:20 PM, Tim Booth wrote:
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.
what do you mean by commit to SVN ?
I looked at SVN repo for fastqc but it is empty, referring to git repo
[0]
Where is you code ?
[0] http://anonscm.debian.org/viewvc/debian-med/trunk/packages/fastqc/
Olivier
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);
PATCH
I'm done with this for now. Off to debug some Python code.
Best,
TIM
--
gpg key id: 4096R/326D8438 (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
--
Nothing is inherently mysterious - nothing that actually exists, that
is. If I am ignorant about a phenomenon,
Re: python-cobra seems to resist backporting :-( [python-cobra_0.4.0b2-1~bpo8+1_amd64.changes REJECTED]
Hi, On Mon, Aug 17, 2015 at 06:53:39AM -0700, Afif Elghraoui wrote: On الإثنين 17 آب 2015 04:39, Andreas Tille wrote: I've never seen this. :-( Any idea Andreas. Like Olivier said, it looks like the orig.tar.gz is not the same for some reason. I don't understand why--all I did was merge the master branch into the backports branch. Git correctly shows that the only difference between the version in unstable and the backports version is the changelog. I did as advised and can confirm that a simple gbp buildpackage created a different orig.tar.gz with different file size and hash. The size hash of the .orig.tar.gz on my machine matches what this says it should be: $ ls -l python-cobra_0.4.0b2.orig.tar.gz -rw-rw-r-- 1 afif afif 2264579 Aug 10 02:19 python-cobra_0.4.0b2.orig.tar.gz Did it get corrupted somehow? Seems so. No idea how. :-( Hope now everything will be fine. Kind regards Andreas. -- http://fam-tille.de
reportbug wnpp
Hi, does anymore experienced issues with reportbug ? I tried to create an ITP but reportbug crashes when trying to contact Debian BTS on wnpp. Could someone make a try for me so that I can progress if issue is only on my side ITP for package: python-cutadapt description: Cleaner for biological high sequencing data reads language: Python (2 and 3) license: MIT homepage: https://pypi.python.org/pypi/cutadapt/ Thanks Olivier
Re: reportbug wnpp
Try reportbug --no-query-bts wnpp There is an open bug about this somewhere but this should help Andreas. On Mon, Aug 17, 2015 at 08:20:34AM +, olivier sallou wrote: Hi, does anymore experienced issues with reportbug ? I tried to create an ITP but reportbug crashes when trying to contact Debian BTS on wnpp. Could someone make a try for me so that I can progress if issue is only on my side ITP for package: python-cutadapt description: Cleaner for biological high sequencing data reads language: Python (2 and 3) license: MIT homepage: https://pypi.python.org/pypi/cutadapt/ Thanks Olivier -- http://fam-tille.de
Bug#795822: ITP: python-cutadapt -- cleaner for biological high sequencing data reads
Package: wnpp Severity: wishlist Owner: Olivier Sallou olivier.sal...@irisa.fr X-Debbugs-Cc: debian-med@lists.debian.org * Package name: python-cutadapt Version : 1.8.3 Upstream Author : Marcel Martin marcel.mar...@scilifelab.se * URL : http://pypi.python.org/pypi/cutadapt * License : MIT Programming Lang: Python Description : cleaner for biological high sequencing data reads Cutadapt finds and removes adapter sequences, primers, poly-A tails and other types of unwanted sequence from your high-throughput sequencing reads. Cleaning your data in this way is often required: Reads from small-RNA sequencing contain the 3’ sequencing adapter because the read is longer than the molecule that is sequenced. Amplicon reads start with a primer sequence. Poly-A tails are useful for pulling out RNA from your sample, but often you don’t want them to be in your reads. Cutadapt helps with these trimming tasks by finding the adapter or primer sequences in an error-tolerant way. It can also modify and filter reads in various ways. Adapter sequences can contain IUPAC wildcard characters. Also, paired-end reads and even colorspace data is supported. If you want, you can also just demultiplex your input data, without removing adapter sequences at all. Cutadapt comes with an extensive suite of automated tests and is available under the terms of the MIT license. Package will be managed under DebianMed team
