Bug 115446 - sci-biology/cutg-149 should be stabilised
Bug#: 115446 Product:  Gentoo Linux Version: unspecified Platform: All
OS/Version: Linux Status: RESOLVED Severity: normal Priority: P2
Resolution: WONTFIX Assigned To: ribosome@gentoo.org Reported By: ribosome@gentoo.org
Component: Applications
URL: 
Summary: sci-biology/cutg-149 should be stabilised
Keywords:  
Status Whiteboard: 
Opened: 2005-12-13 12:00 0000
Description:   Opened: 2005-12-13 12:00 0000
I would like all supporting arches to please stabilise   
sci-biology/cutg-149. Here is a (small) test case using EMBOSS:  
 
$ wget pelican.rsvs.ulaval.ca/distfiles/seq/Zostera-Zymobacter-ref.codcmp 
$ codcmp EZostera_marina.cut EZymobacter_palmae.cut Zostera-Zymobacter.codcmp 
$ diff -u Zostera-Zymobacter-ref.codcmp Zostera-Zymobacter.codcmp 
 
There should be no difference between the two files. 
 
Thanks in advance,

------- Comment #1 From Markus Rothe 2005-12-13 12:50:37 0000 -------
stable on ppc64 

------- Comment #2 From nixnut 2005-12-17 22:15:23 0000 -------
tested on ppc
works for me

------- Comment #3 From Tobias Scherbaum 2005-12-23 11:41:54 0000 -------
ppc stable, thanks for testing nixnut :)

------- Comment #4 From Simon Stelling (RETIRED) 2005-12-23 16:06:58 0000 -------
amd64 stable

------- Comment #5 From Olivier Fisette 2006-01-12 18:54:33 0000 -------
ppc-macos, could you have a look at this, please? TIA,

------- Comment #6 From Fabian Groffen 2006-01-13 12:08:38 0000 -------
22000 files checked ...
23000 files checked ...
24000 files checked ...
25000 files checked ...
26000 files checked ...
27000 files checked ...
existing file /usr/share/EMBOSS/data/CODONS/EXenopus.cut is not owned by this
package
* spent 2.82439494133 seconds checking for file collisions
* This package is blocked because it wants to overwrite
* files belonging to other packages (see messages above).
* If you have no clue what this is all about report it
* as a bug for this package on http://bugs.gentoo.org

package sci-biology/cutg-149 NOT merged


after a long long long long long long while, so I'd like to have this sorted
out before I try again...  It's last package in the whole list of packages you
want me to mark stable:
sci-biology/clustalw-1.83-r1  
sci-biology/primer3-1.0.0  
sci-biology/emboss-3.0.0  
sci-biology/prosite-19.16  
sci-biology/transfac-3.2  
sci-biology/rebase-512  
sci-biology/aaindex-7.0  
sci-biology/prints-38.0  
sci-biology/cutg-149  

The file is on my system:
-rw-r--r--   1 root  wheel  2027 Jan 13 20:01
/usr/share/EMBOSS/data/CODONS/EXenopus.cut

It's now 21:02 here, so the file was installed today as part of another
package.

% equery files emboss | grep -i EXenopus.cut
/usr/share/EMBOSS/data/CODONS/Exenopus.cut

Mind the case of the x!  Mac OS X root filesystem is case INsensitive.  I
diffed both files, and they are completely different.  Unless you know better,
I guess we have a big problem here.

------- Comment #7 From Olivier Fisette 2006-01-13 13:03:09 0000 -------
(In reply to comment #6)
> Mind the case of the x!  Mac OS X root filesystem is case INsensitive.  I
> diffed both files, and they are completely different.  Unless you know
> better, I guess we have a big problem here.

Yes we do. The genus is always capitalised in CUTG files. The database coexists
pacifically with the codon files provided by EMBOSS since those are lowercase
(except for the initial E). A possible solution would be to install the
EMBOSS-provided files in a different directory. I will look into this shortly,
test it in 150-r1, and ask for stabilisation in about a month.

Thanks for your time,

------- Comment #8 From Fabian Groffen 2006-01-13 14:01:31 0000 -------
ehm, to misuse this bug for the others:  Does it make sense if I stable all the
others, or do they have an intrinsic interdependency upon each other?  I'd like
to help you out on the others (as I got them compiled anyway) but I don't have
the foggiest idea on what kind of programs I'm dealing with :)

------- Comment #9 From Olivier Fisette 2006-01-13 15:26:15 0000 -------
(In reply to comment #8)
> ehm, to misuse this bug for the others:  Does it make sense if I stable all the
> others, or do they have an intrinsic interdependency upon each other?  I'd like
> to help you out on the others (as I got them compiled anyway) but I don't have
> the foggiest idea on what kind of programs I'm dealing with :)
> 

There is no problem. ;-) All these packages are independent.

Thanks for your work,