Re: proposed patch libbam-dev due to cufflinks configure script not picking up bam.h
On 12/05/2011 11:50 PM, Charles Plessy wrote: > Le Mon, Dec 05, 2011 at 03:52:12PM +0100, Alex Mestiashvili a écrit : > >> >> I stuck trying to find a contact of locfit's author , (locfit is the >> part of cufflinks). >> The license of locfit forbids benchmarking so it is not free . >> Should we go for non-free section in such case ? >> > Hi all, > > I found a paper from 2009 that indicates that the author was working in New > Zealand at that time. Have you tried that address ? > > http://www.biomedcentral.com/1471-2202/10/S1/S3 > http://www.stat.auckland.ac.nz/showperson?firstname=Catherine&surname=Loader > > Another solution is to contact the cufflinks authors and as them if they can > help or replace locfit. > > We can definitely upload to non-free in the meantime. > > Have a nice day, > > Yes , I tried this email , it is not valid any more ... 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/4edde2f0.3080...@biotec.tu-dresden.de
Working on Ensembl package
Hi, I tried to handle all our RC bugs in the "Advent Bug Squashing" time and I admit Ensemble is the hardest one. While hanging around in experimental/non-free I do consider it not as "second class" package. However, when looking at the package and its changelog I realised that it is not maintained according our usual quality requirements. Not only beeing behind upstream two versions it has more lintian issues than my xterm scrolls backwards (when using -i -I). That's inacceptable. I would also like to see the package in main rather than non-free. One important brick is to close #645487 - which is in principle fixed in SVN (but needs testing). However fighting all other issues is quite a lot of work I have several other changes on my local disk I need to check before commiting. I'd also consider it a good idea to teach upstream about consistently setting file permissions and fixing shebang in scripts. Fixing these causes a lot of complexity in the packaging. My primary goal is to bring the package into a shape without lintian errors and warnings (if needed with reasonable overrides) while keeping packaging directory layout unchanged. Once this is done I will issue a call for testing. Steffen keeps on mentioning to work on this on the Debian Med sprint in Southport but I personally do not like to leave tasks for a later date if it can be done now. There is no point in waiting to fix problems. I try to add comments in code and SVN commits to make sure the other ensembl packagers can learn about Debian standards. I do not intend to upload the package before I get a confirmation from an ensembl user that my work is OK. So Steffen, there is no need to be afraid of breaking something and pointing people to snapshots. BTW, I wonder whether people *really* are *relaying* on packages in experimental and do expect that these will not be broken. These people should probably read a bit more about the role of experimental. However, I have realised that this is no excuse to break something in an uncareful way. I would love if some ensembl users (perhaps using a private mail address) might engage themselves in a discussion here. Finally we are discussing about Open Source code which is free for anybody and those technical issues should be discussed open. I keep on asking for this all the time for one simple reason: Private discussion simply kills the chance that other competent people who might spend some time on a problem can join. 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/20111206204245.gb2...@an3as.eu
