Official Debian package #120
Comments
|
Hello @alexmyczko. So, it looks like you are using CMake to build the project. Is that the case? |
|
waiting for https://bugs.debian.org/1064953 |
|
Interesting news.
What is the timescale for this? Hours or months? Yes, RDKit is now a hard dependency. With the move to GTK4 (in Coot 1.1) the dependency on a canvas has been removed. Is there a way to check for lack of copyright assignment? |
|
It was like sub-hour, package already fixed in sid, webpage outdated, i got it from incoming.debian.org and building to test... thanks for clarifying it is a hard dependency. I usually postpone the really hard things like debian/copyright. first it builds, then it works, and so on... BUT let me assure you, there's interest from many sides, and I am now equipped with a new vortex m0110 keyboard which encourages me to type alot ;) |
|
OK, sounds good. What's next/what can I help with? |
|
At the moment nothing, I had problems building rdkit src deb pkg, but now it's built installing it from the archive (sid, amd64) and continuing trying, this is very appreciated your help. No worries, I sure will have questions... |
|
99% of the problems of installing Coot is installing the dependencies. Which version of GTK4 are you going to use? |
|
here's the GTK4 looks like: |
|
I have lead you astray, it seems. The CMake build system builds (only) libcootapi and chapi - which are fine things to have but they are not coot. Use |
|
so i'll need configure AND cmake, or configure also builds libcootapi/chapi? |
Ask me that now and I will say "Yes, both." They should build different libraries and not step on each other's toes. This answer may change in the future as I get to like and understand CMake more. You will also build Layla - which is a useful stand-alone chemisry application. |
|
that's fine, i've seen projects that have much worse build systems or well lacking them completey :) |
|
FWIW, libcootapi is the core library behind Moorhen (https://moorhen.org) |
|
ok the cmake part looks good so on to configure, aha no configure, let me guess which parts of this i need (witout reading the manual) i have a note about |
|
|
You can take a look at If you prefer, you can build from a tarball release: https://www2.mrc-lmb.cam.ac.uk/personal/pemsley/coot/source/releases/coot-1.1.07.tar.gz |
|
i do have the tarball release (ah but selfmade git checkout without configure, now i get it), i guess i'll help it find rdkit: configure was successfull with just |
|
|
hm they don't come with Looking into https://salsa.debian.org/debichem-team/rdkit/-/blob/master/debian/rules?ref_type=heads |
|
Coordgen is a Schrödinger library. |
|
this would not do it? |
|
I imagine so. |
|
ended with: need |
|
This looks like a source-code bug. Layla uses rdkit. Check the use of the I have to go to work now - hiatus. |
|
@hgonomeg do you have thoughts about this? I thought that the libraries with which a target is linked should be specified on the command line after the target. This seems to specify |
|
What does this say?
|
|
Very happy to see this development! I have attempted to build a Debian package for coot some years ago, with varying level of success, but did not follow through the whole process. I am puzzled to see I recall I had to patch --- a/lbg/Makefile.am
+++ b/lbg/Makefile.am
@@ -80,7 +80,7 @@
# (if that is annoying, then remove it and expand it by hand)
#
lidia_LDADD = \
- ./libcoot-lidia.la $(GLOB_LIBS) $(RDKIT_LIBS) $(L_BOOST_PYTHON)
+ ./libcoot-lidia.la ../lidia-core/.libs/libcoot-lidia-core.la $(GLOB_LIBS) $(RDKIT_LIBS) $(MMDB_LIBS) $(GTK_LIBS) $(PYTHON_LIBS) $(L_BOOST_PYTHON)
# not needed: linked by dependency libs
# $(CLIPPER_LIBS) $(MMDB_LIBS) $(GSL_LIBS) |
|
@alexmyczko have you pushed your packaging attempt somewhere? I would like to give it a shot. |
|
@merkys the current stuff is at http://sid.ethz.ch/debian/coot/2024/ and without debian/ it's just building manually from source, once this is successfull, i can start/continue what's on salsa and put it on salsa... If IRC is easier for you, i'm there as tarzeau (or tarzeau_) |
Thanks. On my end, I have tested |
very important test :-) This is a side-question: Is is possible to download the structure factors from COD structures (so that Coot can make a map?) |
Indeed :) By the way, currently coot makes requests to the COD using
The COD has structure factors in CIF HKL format, for example, 1100908.hkl. Some CIF files have embedded SHELX HKL structure factors, but we have not implemented parsing them yet. There seems to be a Python package ShelXFile which can read them. |
|
I am pretty sure I wrote a SHELX data parser - in 2006-2007 or so. Who knows where it is now though⸮ I don't recall anything about |
|
OK, where are we now? Are you waiting for me? |
We at the COD have plans to parse SHELX data embedded in CIF files, but so far we did not to anything about it. At some point we will have to investigate the existing SHELX parsers, it would be interesting to look into yours.
Here it is: coot/src/c-interface-network.cc Line 678 in a494e2b I would suggest switching to https:// and removing ?CODSESSION=fromCoot as it is not necessary.
I have submitted the package for copyright review It would be nice if at some point you could make a release with all the recent changes to the codebase. For now I have packaged a development version (from some git commit), but it would be nicer to have a stable release packaged for Debian. |
|
OK, I'll get a new release done on Monday. |
Done d599bb9 |
|
Coot has passed the copyright checks on Saturday and has been accepted to Debian! Thanks a lot for making this happen! The build matrix looks quite good. Some of the Debian's officially supported 64bit architectures are failing, but I have a feeling this might be due to incomplete time_64 transition. Anyway these are not a big deal. My next step is to update the package to v1.1.08. |
|
When running
It is not available? That doesn't seem right? Is the path wrong or something? |
Woohoo - fantastic news. |
git is not installed on any of the Debian build machines by default. Usual practice is to build from source tarballs, and these do not normally ship As for hurd-i386, I think the problem might be with float comparison in gemmi: |
That issue has (now) been brought up on our local discussion forum. Maybe I should have used GitHub. |
I think |
|
(I missed the []) |
|
I have opened project-gemmi/gemmi#316 to ask about the possible float comparison issue. |
|
Should I add a workaround for when git is not available when |
This would be really nice to have. |
OK, done (it seems to me). I am thinking to release 1.1.09 in a week or so, for the record. |
|
I noticed |
Commit a0fbdb6 fixes this issue. |
Hmm. Yes. What do you need me to do? For the record (1.1.09+) I have changed the coot shell script again. Now it is a minimal wrapper. |
Noting, actually. I just described the failure as I thought you were not aware of it. I have not tried the master branch before bothering you. Then I did some bisecting and noticed there was a fix in post-1.1.08.
OK. I think |
|
Would it be OK to build Coot for the Hurd without |
|
@pemsley debian/rules file is a makefile. technically that is no problem to do. |
|
I am working on XDG base today and will hopefully get that done and release 1.1.09 tomorrow. |
To add to @alexmyczko reply, architecture-specific build options are an usual practice in Debian. I will try to do so for the next upload. |
There's the intent to package at https://bugs.debian.org/897673
and the current public state: https://salsa.debian.org/science-team/coot
and then there's some success on a local machine that builds 1.1.07
and if software builds successfully, it's likely to also work and be packagable...
(Using this place to keep track of the history of building the package)
correction: almost success
Just to see where we are: https://repology.org/project/coot/versions
(comparisons are bad, Paul Watzlawik, Situation is Hopeless, But Not Serious, The Pursuit of Unhappiness)
The text was updated successfully, but these errors were encountered: