Re: About backports.
Hi, Andreas, On السبت 15 آب 2015 23:24, Andreas Tille wrote: Hi Afif, Even with the current system in Debian, this can be somewhat automated--for example, setting up a machine to respond to the testing migration emails by triggering a rebuild of a package on a Stable chroot and, if it succeeds and passes tests, to automatically prepare the package and upload to backports. That's a brilliant idea! I've just thrown this idea on the breakfast table here at DebConf and everybody likes it a lot! :) I could look into doing part of this, but I obviously can't do any uploads, automated or otherwise. If I ever get to become a DD, I could then look into taking care of this whole process. Please get a DD soon! ;-) I'd love to; should I go ahead and start NM while my DM application is waiting? I'd be really happy if you would work on this I can start looking into implementing of this system. Thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Re: RFS - python-cobra 0.4.0b2 backport
Hi Afif, On Sun, Aug 16, 2015 at 12:01:22AM -0700, Afif Elghraoui wrote: The new upstream release of python-cobra has just entered testing. I have backported the package to jessie--could someone please upload? Done. BTW, what I remember regarding to your backports plan: Please keep in mind that there might be other teams with the same intention. So please whenever it comes to specify Debian Med somewhere use a variable $BLEND to enable other Blends profiting easily from your work. Kind regards Andreas. -- http://fam-tille.de
Re: About backports.
Hi Afif, On Sat, Aug 15, 2015 at 07:46:05PM -0700, Afif Elghraoui wrote: From a strategic point of view I'm not sure that some extra infrastucture will support the idea of convergence to collect people behind a common idea. Even with the current system in Debian, this can be somewhat automated--for example, setting up a machine to respond to the testing migration emails by triggering a rebuild of a package on a Stable chroot and, if it succeeds and passes tests, to automatically prepare the package and upload to backports. That's a brilliant idea! I've just thrown this idea on the breakfast table here at DebConf and everybody likes it a lot! I could look into doing part of this, but I obviously can't do any uploads, automated or otherwise. If I ever get to become a DD, I could then look into taking care of this whole process. Please get a DD soon! ;-) We would then just need to keep track of a list of packages that should be backported. Fully understood the idea. I'd be really happy if you would work on this Andreas. -- http://fam-tille.de
RFS - python-cobra 0.4.0b2 backport
Hi, all, The new upstream release of python-cobra has just entered testing. I have backported the package to jessie--could someone please upload? Many thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Re: packages not queued on Debian CI
Hi Afif, On Sat, Aug 15, 2015 at 07:22:09PM -0700, Afif Elghraoui wrote: On الإثنين 10 آب 2015 20:39, Charles Plessy wrote: By the way, I do not understand why python-cobra does not show up on ci.debian.net, despite it seems to have every control field needed. I thought this just needed a couple days, but it's been more than that and python-cobra is still not listed there. This is also the case for python-pbcore. I'm not sure what's going on. I suspect some delay for new packages but if you want to be sure you need to ask the ci maintainers. Kind regards Andreas. -- http://fam-tille.de
Re: gcc-5 transition of GDCM
Hi, I orphaned it today, so whoever would like to take care it can step up directly. The package is simple and straghtforwrad, shouldn't be a lot of trouble. Regards, Aron On Fri, Aug 14, 2015 at 5:13 AM, michkapop...@gmail.com wrote: 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 happyaron...@gmail.com 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 ti...@debian.org 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 signature.asc Hi I was told someone mentioned pygccxml here :) I am the current maintainer of the project (https://github.com/gccxml/pygccxml 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 -- Regards, Aron Xu
Re: RFS - python-cobra 0.4.0b2 backport
Hi, Andreas, On الأحد 16 آب 2015 02:19, Andreas Tille wrote: Hi Afif, On Sun, Aug 16, 2015 at 12:01:22AM -0700, Afif Elghraoui wrote: The new upstream release of python-cobra has just entered testing. I have backported the package to jessie--could someone please upload? Done. Thanks; I wrote a separate email about this, but it looks like the version uploaded was incorrect. The version in Git was correct, though. BTW, what I remember regarding to your backports plan: Please keep in mind that there might be other teams with the same intention. So please whenever it comes to specify Debian Med somewhere use a variable $BLEND to enable other Blends profiting easily from your work. Of course; I always try to avoid hard-coding values. :) Thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Re: Help needed to update to latest fastqc
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
--
gpg key id: 4096R/326D8438 (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Re: RFS - python-cobra 0.4.0b2 backport
On Sun, Aug 16, 2015 at 11:23:22AM -0700, Afif Elghraoui wrote: Thanks; I wrote a separate email about this, but it looks like the version uploaded was incorrect. The version in Git was correct, though. I noticed that the version in the debian/jessie branch: python-cobra (0.4.0b1-2~bpo8+1) jessie-backports; urgency=medium * Rebuild for jessie-backports. -- Afif Elghraoui a...@ghraoui.name Fri, 17 Jul 2015 00:10:40 -0700 $ git log | head -n1 commit fe42d7ce8819d9b6511cd944663c41f4cbb7b585 was refused. No idea why and I do not remember the mentioned separate mail. :-( BTW, what I remember regarding to your backports plan: Please keep in mind that there might be other teams with the same intention. So please whenever it comes to specify Debian Med somewhere use a variable $BLEND to enable other Blends profiting easily from your work. Of course; I always try to avoid hard-coding values. :) Kind regards Andreas. -- http://fam-tille.de
Re: RFS - python-cobra 0.4.0b2 backport
On الأحد 16 آب 2015 12:33, Andreas Tille wrote: On Sun, Aug 16, 2015 at 11:23:22AM -0700, Afif Elghraoui wrote: Thanks; I wrote a separate email about this, but it looks like the version uploaded was incorrect. The version in Git was correct, though. I noticed that the version in the debian/jessie branch: python-cobra (0.4.0b1-2~bpo8+1) jessie-backports; urgency=medium * Rebuild for jessie-backports. -- Afif Elghraoui a...@ghraoui.name Fri, 17 Jul 2015 00:10:40 -0700 $ git log | head -n1 commit fe42d7ce8819d9b6511cd944663c41f4cbb7b585 was refused. No idea why and I do not remember the mentioned separate mail. :-( Maybe your debian/jessie branch isn't tracking the remote, so that it's not updating when you execute git pull. Can you try (from your local debian/jessie branch) git pull origin debian/jessie I am looking at cgit and I see the latest version online there: https://anonscm.debian.org/cgit/debian-med/python-cobra.git?h=debian%2Fjessie Thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
