Re: emboss: FTBFS with OpenJDK 17 due to com.sun.net.ssl removal
Hi Andreas, I can take a look. What's the problem? Still working through getting EMBOSS moved to github with all the past releases. Nearly there. Then I play a lot of testing and updates for anything that has run into problems. regards, Peter Rice On 13/12/2021 17:55, Andreas Tille wrote: Hi, I've just asked for help on bug #982036 but no response so far. I think it is time to care if we want to keep emboss for the next stable release. Kind regards Andreas. -- This email has been checked for viruses by AVG. https://www.avg.com
Re: ELIXIR & Debian(-Med)
Hi Michael, Happy to help if I can. The article refers to data resources, but I would expect a software resource to qualify. The ELIXIR tools specialists are ELIXIR Denmark https://www.elixir-denmark.org/ They should also be able to help. regards, Peter Rice On 04/09/2020 15:27, Michael R. Crusoe wrote: I'd like to see Debian/Debian-Med become an official ELIXIR Core Data Resource during the next cycle. https://f1000research.com/articles/5-2422/v2 has the details about the last review round. Would anyone like to help me with the application process? Thanks,
Re: Embassy phylipnew - please use freely licensed source of phylip
Hi Andreas, Yes, that is high on my list of things to do ... but top of the list is restoring EMBOSS websites that are currently being moved around within open-bio. Once that is done all the EMBASSY packages need a review and several need updating. Phylipnew can be first as it is usually the simplest to do. regards, Peter Rice EMBOSS Team On 27/07/2016 07:05, Andreas Tille wrote: Hi Peter, On Tue, Jul 26, 2016 at 10:34:21PM +0100, Peter Rice wrote: This was a restoration of the 6.6.0 release files which had been lost when the FTP server was reset, and a correction of the file names which should have been .660 on the original FTP server. Thanks for the clarification. However, do you see any chance to fetch the new phylip sources which are not really different from the old ones except they now have a free license. I'd even volunteer to assemble a new tarball containing the new sources and do the needed patching if somebody would check this and do an official release. The same applies to the other EMBASSY packages. Kind regards Andreas. regards, Peter Rice EMBOSS Team On 25/07/2016 10:55, Andreas Tille wrote: Hi, I realised that at the EMBASSY download ftpserver[1] files with new version numbers appeared. I was specifically keen to check PHYLIPNEW since I wanted to release a Debian package with the freely licensed phylip. Unfortunately I realised that PHYLIPNEW-3.69.660.tar.gz is byte identical to PHYLIPNEW-3.69.650.tar.gz - so no change in the source code has happened at all. I wonder whether this is by mistake or what the version rename might mean here. It would be really great if you could base the code on version 3.696 of phylip since this version has a free license and could be distributed in Debian main. Kind regards Andreas. [1] ftp://emboss.open-bio.org/pub/EMBOSS/
Re: Embassy phylipnew - please use freely licensed source of phylip
Hi Andreas, This was a restoration of the 6.6.0 release files which had been lost when the FTP server was reset, and a correction of the file names which should have been .660 on the original FTP server. The same applies to the other EMBASSY packages. regards, Peter Rice EMBOSS Team On 25/07/2016 10:55, Andreas Tille wrote: Hi, I realised that at the EMBASSY download ftpserver[1] files with new version numbers appeared. I was specifically keen to check PHYLIPNEW since I wanted to release a Debian package with the freely licensed phylip. Unfortunately I realised that PHYLIPNEW-3.69.660.tar.gz is byte identical to PHYLIPNEW-3.69.650.tar.gz - so no change in the source code has happened at all. I wonder whether this is by mistake or what the version rename might mean here. It would be really great if you could base the code on version 3.696 of phylip since this version has a free license and could be distributed in Debian main. Kind regards Andreas. [1] ftp://emboss.open-bio.org/pub/EMBOSS/
Re: Can "PDB" license be considered free ?
Hi Riley, On 07/03/2016 19:20, Riley Baird wrote: The distribution of modified PDB data including the records HEADER, CAVEAT, REVDAT, SPRSDE, DBREF, SEQADV, and MODRES in PDB format and their mmCIF and XML equivalents is not allowed. I'm not sure what the PDB format is, so I might be wrong, but my intuition is that trying to stop people from distributing data in a certain file format would be non-free. We had this discussion some years back about SwissProt protein sequence entries included as test data in EMBOSS. We also have PDB files in the EMBOSS test data. The conclusion was that scientific data (SwissProt, PDB, etc.) are scientific facts and it is not reasonable to require permission to change them. The license says you may not alter the entries in the PDB database (text file) and redistribute it in any of its original formats - because PDB releases must only come from the curators of the database. It may help to consider an equivalent in another field. Imagine an open source package that included a copy of the Declaration of Independence. It would not be reasonable to insist on permission to change the text, for example to add a phrase from Animal Farm ... "but some are more equal than others" Hope that helps, Peter Rice
Re: description of debian-med packages using EDAM
Hi Hervé On 13/07/2015 15:16, Hervé Ménager wrote: Dear all, I and Steffen are currently meeting at ISMB2015 to discuss and hack the description of debian-med packages using EDAM. We will try to come up with a workable solution. Please get in touch if you'd like to make comments or suggestions regarding this. Happy to help with any suggestions, very keen to increase the usefulness and use of EDAM. regards, Peter Rice -- 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/55a3c9cf.8070...@yahoo.co.uk
Re: PHYLIP is now free software
Hi Andreas On 12/05/2015 10:21, Andreas Tille wrote: Hi EMBOSS team, I would like to inform you that the authors of PHYLIP have put their code under a BSD-2-clause license last autumn. So the phylip package in Debian went from non-free into the main Debian distribution. Since there is another instance of this code integrated into Debian which is provided by EMBOSS[1] I wonder whether you might want to consider switching to the new upstream version 3.696 which is basically the relicensed code of 3.695. This would enable the distribution inside the main Debian distribution. Excellent news. Many thanks. I will take a look at any other changes between versions to see what we can do. Peter -- 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/5551ccf0.4040...@yahoo.co.uk
RE: Status of EMBOSS [Was: Bug#762673: emboss: FTBFS on hurd-i386]
Out of office for next two weeks but will take a look when I get back.
Too few changes for a new EMBOSS release this summer
regards,
Peter Rice
EMBOSS Team
-Original Message-
From: "Andreas Tille"
Sent: 24/09/2014 13:23
To: "Debian Med Project List"
Subject: Status of EMBOSS [Was: Bug#762673: emboss: FTBFS on hurd-i386]
Hi,
in the bug report below it is claimed that upstream is not very active
lately. I also somehow assumed a new version in summer. Any news about
this? If a new version is at horizont in the next two weeks we might
have a chance to upload it to Jessie. Otherwise I would simply fix the
bug below and update the packaging a bit to have it properly clean in
Jessie with the current version.
Kind regards
Andreas.
- Forwarded message from Svante Signell -
Date: Wed, 24 Sep 2014 12:28:47 +0200
From: Svante Signell
To: Debian Bug Tracking System
Subject: Bug#762673: emboss: FTBFS on hurd-i386
X-Debian-PR-Message: report 762673
X-Debian-PR-Package: src:emboss
X-Debian-PR-Keywords: patch
X-Debian-PR-Source: emboss
Source: emboss
Version: 6.6.0+dfsg-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Hi,
Currently emboss fails to build from source due to usage of
PATH_MAX, which is not defined on GNU/Hurd. Only one file needs a
modification, see the attached path. This patch assumes getcwd(NULL,0)
works. Depending on for which systems this software is aimed at, a
configure.ac (.in here) check can be added. However, it seems that
upstream is not very active lately. This patch should work at least for
Debian supported OSes (libc4, libc5, glibc).
Thanks!
--- a/ajax/core/ajfile.c.orig 2013-07-15 23:25:29.0 +0200
+++ b/ajax/core/ajfile.c2014-09-24 11:01:42.0 +0200
@@ -8574,9 +8574,9 @@
const AjPStr ajFileValueCwd(void)
{
-char cwd[PATH_MAX+1];
+char *cwd = getcwd(NULL,0);
-if(!getcwd(cwd,PATH_MAX))
+if(!cwd)
{
ajStrAssignClear(&fileCwd);
@@ -8589,6 +8589,7 @@
if(!ajStrSuffixC(fileCwd, SLASH_STRING))
ajStrAppendC(&fileCwd, SLASH_STRING);
+free(cwd);
return fileCwd;
}
___
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
--
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/20140924122253.gb20...@an3as.eu
Re: Biological data being used by an unpublished research paper is considered proprietary
On 16/09/2013 11:31, Faheem Mitha wrote: Hi, This is really not Debian-related, except insofar as the software in question is something that might have been in Debian one day. I talked about that with people on debian-med recently. So, it is technically off-topic. I posted a reply on stackexchange with instructions to get the data from the EBI SRS server. However, I have run into this issue before in the context of biological database entries and Debian so it may be worth discussing here. There were objections to including SwissProt entries in the example data for the EMBOSS package because the licensing of SwissProt does not allow them to be edited. That was resolved by agreeing that scientific facts should not be edited so that the files could be accepted as part of a Debian package even though they could not be changed. A fine compromise I feel. regards, Peter Rice EMBOSS team -- 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/5236f28f.2020...@yahoo.co.uk
Re: Please test emboss packaging in Git
On 09/09/2013 15:54, Andreas Tille wrote: Hi, I wonder if there are volunteers to test EMBOSS packaging in Git. IMHO we should upload soonish to finally close #694908. I'll check the other bugs whether these are fixed in new upstream soon but some testing of somebody else before I'll upload might not harm. Happy to help! Peter Rice EMBOSS Team -- 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/522ded42.90...@yahoo.co.uk
Re: [emboss-bug] LEG: Optimisation and porting - assembly
Hi Andreas, > BTW, after > a second look EMBOSS was a false positive I forgot to remove (sorry for > the noise to EMBOSS developers). No problem! Your message made me realise I was no longer subscribed to debian-med ... now I need to read through the archive to see what I missed since my old email address expired! regards, Peter Rice EMBOSS team -- 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/1364978098.97619.yahoomail...@web171903.mail.ir2.yahoo.com
Re: Debian Med sprint II in Southport, UK - any objections to the last weekend in January?
On 08/10/2011 05:33 PM, Tim Booth wrote: > For now I just want to set a date, so I'll propose the last weekend in > January - the 27th,28th,29th - as per last time. Please let me know if: > > a) You want to come but can't make that date > b) You want to come but can't do a weekend I will be moving jobs after December. Don't know where yet, but it makes a weekend much the best option for me. Peter -- 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/4e42b41a.1060...@ebi.ac.uk
Re: [EMBOSS] Files included in EMBOSS but licensed ...
Quoted in full for the benefit of the debian-med list who missed the original posting On 29/07/2011 21:35, Adam Sjøgren wrote: On Fri, 29 Jul 2011 09:39:46 +0100, Peter wrote: It might make things clearer if someone from Debian could explain: (I am not from Debian, but here is my take on it anyway:) (a) why a Creative Commons licence is an issue for you One of the fundamental software freedoms is the freedom to change the software¹. The Debian Free Software Guidelines' definition of free software includes this freedom². So the "No Derivatives" variants of the Creative Commons licenses aren't free by the DFSG definition. (The GNU Free Documentation License on documents with invariant sections is considered non-free by DFSG-standards as well, even if the invariant sections are things that nobody would want to change.) When a project of volunteers packages 29000+ thousand packages, I think making a judgement call on whether it is okay that the license of a couple of files does not live up to the guidelines is neigh impossible. The answer to "Why would you want to?" is, because you might need to. It is more obvious with programs and code than it is with database entries, granted - but I guess the equivalent problem would be that the licensor didn't want to fix a problem in such a database, and that problem made the programs using it malfunction. It would be a pain if you weren't allowed to fix the problem and distribute the fixed data yourself, say, if "upstream" didn't want to include the fix for some reason or another; maybe they happened to turn sour on the world/you - stranger things have happened. So, nobody is probably ever going to exercise that freedom in this specific case, I think, but ignoring some of the freedoms in special cases is infeasible for a project such as Debian. This is just me trying to explain how I understand it, so take it with a grain of salt, and swing by debian-legal³ for the experts. A specific example might help. About 5 years ago a release of the UniProt database (as plain text files) broke the Wisconsin (GCG) sequence analysis package. They introduced extremely long lines in a data file that everyone assumed was only maximum 80 characters. As GCG was closed source, the fix required a change to the UniProt files to either wrap or truncate the 'offending' records. The fix was not to distribute a change to the data of course, but to write and distribute a simple perl script that wrapped the long records. That was not a licensing issue - the content stays the same, the format is changed, no changed data is distributed. But it does illustrate that the database licensing does not prevent 'fixing' a database. (b) why you appear to consider a copy of a whole or part of a public biological database as part of an "operating system" They are part of a package which is included in the Debian GNU/Linux free operating system. I expect there are many problems that arise if data ... and documentation ... are considered to be software. For EMBOSS we didn't officially specify a license for the documentation but other packages probably do. It still worries me that some of our documentation files officially include GPL licensed (EMBOSS) source code but I did not like any of the alternative documentation licenses. (I personally think it would make sense to change to a Creative Commons license that allows derivative works - Uniprot and others are going to be the canonical source for the data anyway, so nothing will be lost by them by doing that, as far as I can see.) Unlikely. The no-derivatives version is specifically there to prevent derivatives - for example Debian distributing a modified UniProt without permission. The ontologies are similar, but do allow for the use case of importing terms from one ontology into another if the ontology name is changed (and preferably if cross-references to the original are provided). Again, the need is to protect the integrity of the original ontology content so references to a GO term or a UniProt entry are clearly defined. This is essential for many of the public bioinformatics databases. Data and software are not the same in this context. I am curious whether documentation licensing raises any issues. Just my 2c worth Peter Rice EMBOSS Team -- 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/4e33c79f.8080...@ebi.ac.uk
Re: [EMBOSS] Files included in EMBOSS but licensed ...
On 07/29/2011 08:46 AM, Peter Rice wrote: > On 28/07/2011 15:38, Charles Plessy wrote: >> Dear EMBOSS developers, >> (CC Debian Med mailing list) >> >> while working on upgrading Debian's emboss package to version 6.4.0 >> (congratulations, by the way), I found some files in EMBOSS that are >> not considered ‘Free software’ by Debian. While we're on the topic of licensing, some other data files in EMBOSS 6.4.0 have licences. emboss/data/OBO contains copies of several Open Bio-Ontologies for which EMBOSS includes index files - so you need the data file version that matches the index files. For example, the Gene Ontology terms http://www.geneontology.org/GO.cite.shtml are: GO Usage Policy The GO Consortium gives permission for any of its products to be used without license for any purpose under three conditions: That the Gene Ontology Consortium is clearly acknowledged as the source of the product; That any GO Consortium file(s) displayed publicly include the date(s) and/or version number(s) of the relevant GO file(s) (the GO is evolving and changes will occur with time); That neither the content of the GO file(s) nor the logical relationships embedded within the GO file(s) be altered in any way. which looks rather like the problem you had with Creative Commons. Licenses that protect the official database release from derives versions are entirely reasonable and standard in bioinformatics. Basically, making sure that when you refer to a UniProt entry, or a, OBO ontology term, everyone agrees you are referring to one agreed entry or term. EMBOSS does depend on these files. The database names are hard-coded into some of the new (and more to come) applications. You could download the databases and indexes from our rsync copies we use to keep developers in sync. These are at rsync://emboss.open-bio.org/EMBOSS/ It might make things clearer if someone from Debian could explain: (a) why a Creative Commons licence is an issue for you (b) why you appear to consider a copy of a whole or part of a public biological database as part of an "operating system" regards, Peter Rice EMBOSS Team -- 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/4e3271d2.2070...@ebi.ac.uk
Re: [EMBOSS] Files included in EMBOSS but licensed under Creative Commons Attribution-NoDerivs
On 28/07/2011 15:38, Charles Plessy wrote: Dear EMBOSS developers, (CC Debian Med mailing list) while working on upgrading Debian's emboss package to version 6.4.0 (congratulations, by the way), I found some files in EMBOSS that are not considered ‘Free software’ by Debian. They were actually present in past releases as well. Their license is Creative Commons Attribution-NoDerivs 3.0 Unported (CC BY-ND 3.0), and it disallows modification of the files. The presence of these files in EMBOSS makes it impossible for Debian to redistribute it in our operating system. I have confirmed with the UniProt consortium's helpdesk that, even in isolation, these files are covered by the CC BY-ND license. I see three possible solutions. Ummm in what sense would *you* be modifying the files? UniProt's license http://www.uniprot.org/help/license says License & disclaimer License We have chosen to apply the Creative Commons Attribution-NoDerivs License to all copyrightable parts of our databases. This means that you are free to copy, distribute, display and make commercial use of these databases in all legislations, provided you give us credit. However, if you intend to distribute a modified version of one of our databases, you must ask us for permission first. So I see no problem for EMBOSS in including the files. The only problem is for someone "modifying the files and redistributing them" without permission ... but strictly that would not apply to most uses of a UniProt entry (otherwise you could not use one entry as input and distribute the results). The licensing is there to prevent redistribution of UniProt without permission. Anyway, you can just delete them from the Debian duistribution of EMBOSS - and find your own way to run the QA tests. I don't think we have a problem. regards, Peter Rice EMBOSS Team regards, Peter Rice -- 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/4e326562.1020...@ebi.ac.uk
Re: [EMBOSS] Files included in EMBOSS but licensed under Creative Commons Attribution-NoDerivs
On 28/07/2011 15:38, Charles Plessy wrote: Dear EMBOSS developers, (CC Debian Med mailing list) while working on upgrading Debian's emboss package to version 6.4.0 (congratulations, by the way), I found some files in EMBOSS that are not considered ‘Free software’ by Debian. They were actually present in past releases as well. Here is their list: test/data/amir.swiss test/data/uniprotft.sw test/swiss/seq.dat test/swnew/trembl.dat Huh? Example entries from UniProt? We can of course remove them from the distribution but then the QA tests will not work if anyone tries them. I suspect amir.swiss predates this UniProt licensing, but the others are more recently updated. Anyway, EMBOSS will work perfectly well without them. You can just delete them. and emboss/data/dbxref.txt That one can go. It was a source for the DRCAT.dat data resource catalogue and yes we do have permission from UniProt to use it. Their license is Creative Commons Attribution-NoDerivs 3.0 Unported (CC BY-ND 3.0), and it disallows modification of the files. The presence of these files in EMBOSS makes it impossible for Debian to redistribute it in our operating system. I have confirmed with the UniProt consortium's helpdesk that, even in isolation, these files are covered by the CC BY-ND license. I see three possible solutions. a) Remove the files in Debian's EMBOSS package. b) Distribute EMBOSS with the files, but in the non-free section of the Debian archive. c) Replace the files by Free equivalents, for instance by re-creating records from scratch. I am not very comfortable with any of the solutions, and was wondering if you would have suggestions ? I will also have words with the UniProt folk at EBI and if it really is not possible to include a few example entries with EMBOSS then I'll check with the other Open Bio projects. This is really silly. regards, Peter Rice EMBOSS Team -- 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/4e326130.7030...@ebi.ac.uk
