[Bug 472150] Review Request: coot - crystallographic macromolecular building toolkit

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=472150





--- Comment #54 from Tim Fenn <fenn at stanford.edu>  2009-11-09 19:54:04 EDT ---
(In reply to comment #53)
> I've had no time for reviews recently, but I have a little now.
> 

Thanks again for helping with this.

> This builds find on rawhide, but not F11 because of the clipper-devel
> dependency.  A version build for F12 will install on F11 but won't run.  My
> "not-quite-F12" boxes are all at work, which makes testing difficult; I can run
> it remotely, but it fails with "*** Cannot find the double-buffered visual." 
> Looks like you just can't go GLX over SSH, which I swear used to work OK. 
> Unfortunately I can't really do a proper review if I can't do any testing.
> 

You can grab the clipper .src.rpm from F12 and build it under F11, it should
build OK, if that helps...

> 
> When I installed this I tried to find the icon, only to find that it shows up
> in the Graphics category.  Unfortunately the desktop file spec doesn't really
> have a top-level category that fits this package, but I'd at least expect to
> see "Graphics;Science;", maybe with Engineering or DataVisualization if they're
> appropriate.
> 

Yeah, I just followed what I did with pymol
(https://bugzilla.redhat.com/show_bug.cgi?id=462251), I really wasn't sure what
to put there.  I'll make the change to Graphics;Science (and in pymol as well,
for that matter).

> Honestly the only real issue I see at this point is the wholesale inclusion of
> unrelated upstream projects in the coot/scheme directory.  Generally we don't
> do that kind of thing; it's basically the situation from
> http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
> I didn't really notice before that those were separate projects; I originally
> thought they were part of coot but carried different licenses.  Now I see that
> they are merely prerequisites that shouldn't be part of this package.
> 

I brought this up with upstream.  My concern was that guile net-http and
guile-gui are unsupported, and goosh is part of the guile os process, and thus
isn't maintained as its own package anymore.  Therefore, I figured it wasn't
worth separating them out into their own packages.  Paul (upstream) has
suggested he'll just include the code as part of the coot distribution and
maintain it himself, but this was a few months ago - I'll ask him again about
this and post an update soon.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.