Official Debian package
Closed this issue · 164 comments
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
[100%] Linking CXX executable test-molecules-container
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libssm.so: undefined reference to `mmdb::Atom::Transform(double (&) [4][4])'
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libssm.so: undefined reference to `mmdb::Mat4Copy(double (&) [4][4], double (&) [4][4])'
collect2: error: ld returned 1 exit status
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)
Hello @alexmyczko.
I was unware of this effort - or had forgotten about it.
I would like this to be a thing and am happy to put some hours in to help make it happen.
I have seen the linking error you mention above some years ago. I don't recall at the moment how to fix it.
I will have a look and a think.
So, it looks like you are using CMake to build the project. Is that the case?
The CMake system (at the moment only) builds up to libcootapi and chapi (the nanobind-based python coot_headless_api). To build the Coot binary and Layla you will need to use configure (at the moment).
You may find build-it-3-3 useful.
Which version of mmdb (and clipper) are you using/linking against?
What does CMakeCache.txt say about MMDB?
Can you compile with VERBOSE=1 ?
waiting for https://bugs.debian.org/1064953
Interesting news.
which is due to be installed in the Debian FTP archive
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 cmake . output
cmake .
CMake Warning (dev) at CMakeLists.txt:2 (project):
cmake_minimum_required() should be called prior to this top-level project()
call. Please see the cmake-commands(7) manual for usage documentation of
both commands.
This warning is for project developers. Use -Wno-dev to suppress it.
-- Looking for mmdb2/mmdb_defs.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libmmdb2.so
-- Looking for ssm/ssm_vxedge.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libssm.so
-- Looking for clipper/clipper.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-core.so
-- FFTW2 libraries - /usr/lib/libsfftw.so
-- - /usr/lib/libsrfftw.so
-- FFTW2 header directory - /usr/include
-- Looking for clipper/clipper-mmdb.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-mmdb.so
-- Looking for clipper/clipper-ccp4.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-ccp4.so
-- Looking for clipper/clipper-contrib.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-contrib.so
-- Looking for clipper/clipper-minimol.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-minimol.so
-- Looking for clipper/clipper-cif.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-cif.so
-- CCP4 include directory: /usr/include
-- Found gemmi version 0.6.4
-- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.83.0/BoostConfig.cmake (found suitable version "1.83.0", minimum required is "1.83.0")
-- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.83.0/BoostConfig.cmake (found version "1.83.0") found components: iostreams system python regex thread serialization
-- Configuring done (0.6s)
-- Generating done (0.5s)
-- Build files have been written to: /var/www/debian/coot/2024/coot-Release-1.1.07
GTK4 looks like:
root@phd-sid:/var/www/debian/coot/2024/coot-Release-1.1.07# dpkg -l |grep gtk4
ii gir1.2-xdpgtk4-1.0:amd64 0.7.1-5 amd64 Flatpak portal library - introspection data for GTK 4
ii libportal-gtk4-1:amd64 0.7.1-5 amd64 Flatpak portal library for GTK 4 GUIs
ii libportal-gtk4-dev:amd64 0.7.1-5 amd64 Flatpak portal library (development files for GTK 4)
ii libvte-2.91-gtk4-0:amd64 0.75.91-2 amd64 Terminal emulator widget for GTK 4 - runtime files
ii libvte-2.91-gtk4-dev:amd64 0.75.91-2 amd64 Terminal emulator widget for GTK 4 - development files
ii python3-wxgtk4.0 4.2.1+dfsg-3 amd64 Python 3 interface to the wxWidgets Cross-platform C++ GUI toolkit
root@phd-sid:/var/www/debian/coot/2024/coot-Release-1.1.07# dpkg -l |grep gtk-4
ii gir1.2-gtk-4.0:amd64 4.12.5+ds-3 amd64 GTK graphical user interface library -- gir bindings
ii gir1.2-javascriptcoregtk-4.0:amd64 2.42.5-1 amd64 JavaScript engine library from WebKitGTK - GObject introspection data
ii gir1.2-javascriptcoregtk-4.1:amd64 2.42.5-1 amd64 JavaScript engine library from WebKitGTK - GObject introspection data
ii libgtk-4-1:amd64 4.12.5+ds-3 amd64 GTK graphical user interface library
ii libgtk-4-bin 4.12.5+ds-3 amd64 programs for the GTK graphical user interface library
ii libgtk-4-common 4.12.5+ds-3 all common files for the GTK graphical user interface library
ii libgtk-4-dev:amd64 4.12.5+ds-3 amd64 development files for the GTK library
ii libgtk-4-media-gstreamer 4.12.5+ds-3 amd64 GStreamer media backend for the GTK graphical user interface library
ii libjavascriptcoregtk-4.0-18:amd64 2.42.5-1 amd64 JavaScript engine library from WebKitGTK
ii libjavascriptcoregtk-4.0-dev:amd64 2.42.5-1 amd64 JavaScript engine library from WebKitGTK - development files
ii libjavascriptcoregtk-4.1-0:amd64 2.42.5-1 amd64 JavaScript engine library from WebKitGTK
ii libjavascriptcoregtk-4.1-dev:amd64 2.42.5-1 amd64 JavaScript engine library from WebKitGTK - development files
ii libswt-gtk-4-java 4.26.0-2 amd64 Standard Widget Toolkit for GTK+ Java library
ii libswt-gtk-4-jni 4.26.0-2 amd64 Standard Widget Toolkit for GTK+ JNI library
ii libwebkit2gtk-4.0-37:amd64 2.42.5-1 amd64 Web content engine library for GTK
ii libwebkit2gtk-4.0-dev:amd64 2.42.5-1 amd64 Web content engine library for GTK - development files
ii libwebkit2gtk-4.1-0:amd64 2.42.5-1 amd64 Web content engine library for GTK
ii libwebkit2gtk-4.1-dev:amd64 2.42.5-1 amd64 Web content engine library for GTK - development files
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 configure to build coot. Read build-it-3-3 to see how I use coot's
configure
so i'll need configure AND cmake, or configure also builds libcootapi/chapi?
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
[100%] Linking CXX executable test-molecules-container
/usr/bin/cmake -E cmake_link_script CMakeFiles/test-molecules-container.dir/link.txt --verbose=1
/usr/bin/c++ -O3 -DNDEBUG "CMakeFiles/test-molecules-container.dir/api/test_molecules_container.cc.o" "CMakeFiles/test-molecules-container.dir/api/filo-tests.cc.o" -o test-molecules-container -Wl,-rpath,/var/www/debian/coot/2024/coot-Release-1.1.07 libcootapi.so /usr/lib/x86_64-linux-gnu/libssm.so /usr/lib/x86_64-linux-gnu/libclipper-minimol.so /usr/lib/x86_64-linux-gnu/libclipper-mmdb.so /usr/lib/x86_64-linux-gnu/libclipper-cif.so /usr/lib/x86_64-linux-gnu/libclipper-core.so /usr/lib/x86_64-linux-gnu/libclipper-ccp4.so /usr/lib/x86_64-linux-gnu/libclipper-contrib.so /usr/lib/libsfftw.so /usr/lib/libsrfftw.so /usr/lib/x86_64-linux-gnu/libmmdb2.so /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/x86_64-linux-gnu/libgsl.so /usr/lib/x86_64-linux-gnu/libgslcblas.so /usr/lib/x86_64-linux-gnu/libpng.so /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.83.0 /usr/lib/x86_64-linux-gnu/libboost_system.so.1.83.0
make[2]: Leaving directory '/var/www/debian/coot/2024/coot-Release-1.1.07'
[100%] Built target test-molecules-container
make[1]: Leaving directory '/var/www/debian/coot/2024/coot-Release-1.1.07'
/usr/bin/cmake -E cmake_progress_start /var/www/debian/coot/2024/coot-Release-1.1.07/CMakeFiles 0
so on to configure, aha no configure, let me guess which parts of this i need (witout reading the manual)
libtoolize --force
aclocal
autoheader
automake --force-missing --add-missing
autoconf
./configure
i have a note about autoreconf -vif but i don't remember why...
root@phd-sid:/var/www/debian/coot/2024/coot-Release-1.1.07# libtoolize --force
libtoolize: putting auxiliary files in '.'.
libtoolize: linking file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'macros'.
libtoolize: linking file 'macros/libtool.m4'
libtoolize: linking file 'macros/ltoptions.m4'
libtoolize: linking file 'macros/ltsugar.m4'
libtoolize: linking file 'macros/ltversion.m4'
libtoolize: linking file 'macros/lt~obsolete.m4'
root@phd-sid:/var/www/debian/coot/2024/coot-Release-1.1.07# aclocal
configure.ac:35: warning: macro 'AM_ACLOCAL_INCLUDE' not found in library
configure.ac:112: warning: macro 'AM_MINGW_WINDOWS' not found in library
configure.ac:115: warning: macro 'AM_PATH_GLOB' not found in library
configure.ac:133: warning: macro 'AM_PATH_SQLITE3' not found in library
configure.ac:184: warning: macro 'AM_PATH_MMDB2' not found in library
configure.ac:186: warning: macro 'AM_WITH_SSM' not found in library
configure.ac:191: warning: macro 'AM_SINGLE_FFTW2' not found in library
configure.ac:195: warning: macro 'AM_PATH_CLIPPER' not found in library
configure.ac:411: warning: macro 'AM_COOT_SYS_BUILD_TYPE' not found in library
configure.ac:433: warning: macro 'AM_WITH_MYSQL_DATABASE' not found in library
fatal: not a git repository (or any parent up to mount point /var/www)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or any parent up to mount point /var/www)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or any parent up to mount point /var/www)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or any parent up to mount point /var/www)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
root@phd-sid:/var/www/debian/coot/2024/coot-Release-1.1.07# autoheader
autoheader: warning: WARNING: Using auxiliary files such as 'acconfig.h', 'config.h.bot'
autoheader: WARNING: and 'config.h.top', to define templates for 'config.h.in'
autoheader: WARNING: is deprecated and discouraged.
autoheader:
autoheader: WARNING: Using the third argument of 'AC_DEFINE_UNQUOTED' and
autoheader: WARNING: 'AC_DEFINE' allows one to define a template without
autoheader: WARNING: 'acconfig.h':
autoheader:
autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1,
autoheader: [Define if a function 'main' is needed.])
autoheader:
autoheader: WARNING: More sophisticated templates can also be produced, see the
autoheader: WARNING: documentation.
fatal: not a git repository (or any parent up to mount point /var/www)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or any parent up to mount point /var/www)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
autoheader: error: error: AC_CONFIG_HEADERS not found in configure.ac
root@phd-sid:/var/www/debian/coot/2024/coot-Release-1.1.07# automake --force-missing --add-missing
configure.ac:42: installing './compile'
configure.ac:32: installing './missing'
MoleculesToTriangles/CXXClasses/Makefile.am: installing './depcomp'
api/Makefile.am:89: installing './py-compile'
root@phd-sid:/var/www/debian/coot/2024/coot-Release-1.1.07# autoconf
fatal: not a git repository (or any parent up to mount point /var/www)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or any parent up to mount point /var/www)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
root@phd-sid:/var/www/debian/coot/2024/coot-Release-1.1.07# ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C++... yes
checking whether g++ accepts -g... yes
checking for g++ option to enable C++11 features... none needed
checking whether make supports the include directive... yes (GNU style)
checking dependency style of g++... gcc3
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking how to print strings... printf
checking for gcc... gcc
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-pc-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for file... file
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /usr/bin/dd
checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1
checking for mt... mt
checking if mt is a manifest tool... no
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /usr/bin/ld -m elf_x86_64
checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking which libtool initialization strategy to adopt... AC-PROG-LIBTOOL
checking what warning flags to pass to the C compiler... -Wall -Wunused
checking what language compliance flags to pass to the C compiler...
checking what warning flags to pass to the C++ compiler... -Wall -Wno-unused
checking what language compliance flags to pass to the C++ compiler...
checking for sys/stdtypes.h... no
checking for OpenMP flag of C compiler... -fopenmp
checking whether g++ supports C++11 features by default... yes
checking for std::thread in thread... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for glib-2.0... yes
checking if this is MINGW on Windows... no
checking if this is msys2 windows 64... no
checking for libpng >= 1.2... yes
checking for cairo >= 1.14... yes
checking for SQLite3... yes
checking for mmdb2... yes
checking for ssm... yes
checking for non-prefixed single-precision FFTW2 (fftw.h)... no
yes
checking for Clipper... yes
checking for gsl-config... /usr/bin/gsl-config
checking for GSL - version >= 1.3... yes
checking for glm >= 0.9.9... yes
checking for gtk4 >= 4.4... yes
checking for epoxy >= 1.5... yes
checking for a Python interpreter with version >= 3.7... python3
checking for python3... /usr/bin/python3
checking for python3 version... 3.11
checking for python3 platform... linux
checking for python3 script directory... ${prefix}/lib/python3/dist-packages
checking for python3 extension module directory... ${exec_prefix}/lib/python3/dist-packages
checking for python3.11... (cached) /usr/bin/python3
checking for a version of Python >= '2.1.0'... yes
checking for the distutils Python package... yes
checking for Python include path... -I/usr/include/python3.11
checking for Python library path... -L/usr/lib/x86_64-linux-gnu -lpython3.11
checking for Python site-packages path... /usr/lib/python3/dist-packages
checking python extra libraries... -ldl -lm
checking python extra linking flags... -Xlinker -export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions
checking consistency of all components of python development environment... yes
checking python3 module: requests... yes
checking for pygobject-3.0 >= 3.36... yes
checking for boostlib >= (102000)... yes
checking whether the Boost::Thread library is available... yes
checking for exit in -lboost_thread... yes
checking whether the Boost::Python library is available... yes
checking whether boost_python is the correct library... no
checking whether boost_python311 is the correct library... yes
checking for RDKit in NONE
Configuration error. No, bad... we do not have necessary RDKIT
aclocal -I macros
You can take a look at autogen.sh - that was written presuming that the dependencies are installed in the user's directories (by the build script). You are at about line 4544 of the build-it-3-3
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:
# grep -i rdkit configure
RDKIT_LIBS
RDKIT_CXXFLAGS
with_rdkit_prefix
--with-rdkit-prefix location of the RDKit package
# Boost-Python is needed for RDKit interface.
# Check whether --with-rdkit-prefix was given.
if test ${with_rdkit_prefix+y}
withval=$with_rdkit_prefix; rdkit_prefix="$withval"
rdkit_prefix=false
if test x$rdkit_prefix = xfalse ; then
echo checking for RDKit in $prefix
if test -x $prefix/include/rdkit ; then
echo OK, good we found RDKit in $prefix
rdkit_install_dir=$prefix
RDKIT_CXXFLAGS="-I$rdkit_install_dir/include/rdkit -DRDKIT_HAS_CAIRO_SUPPORT"
RDKIT_LIBS="-L$rdkit_install_dir/lib -lRDKitMolDraw2D -lRDKitForceFieldHelpers -lRDKitDescriptors -lRDKitForceField -lRDKitSubstructMatch -lRDKitOptimizer -lRDKitDistGeomHelpers -lRDKitDistGeometry -lRDKitChemReactions -lRDKitAlignment -lRDKitEigenSolvers -lRDKitDepictor -lRDKitcoordgen -lRDKitMolChemicalFeatures -lRDKitPartialCharges -lRDKitFileParsers -lRDKitRDGeometryLib -lRDKitGraphMol -lRDKitShapeHelpers -lRDKitFingerprints -lRDKitMolAlign -lRDKitMolTransforms -lRDKitChemTransforms -lRDKitSmilesParse -lRDKitGenericGroups -lRDKitRingDecomposerLib -lRDKitFilterCatalog -lRDKitCatalogs -lRDKitSubgraphs -lRDKitPartialCharges -lRDKitRDGeneral -lRDKitDataStructs -lboost_serialization -lboost_iostreams -l$BOOST_PYTHON_LIB $pl"
echo Configuration error. No, bad... we do not have necessary RDKIT
rdkit_install_dir="$withval"
# better RDKit linking I hope
RDKIT_CXXFLAGS="-I$rdkit_install_dir/include/rdkit -DRDKIT_HAS_CAIRO_SUPPORT"
RDKIT_LIBS="-L$rdkit_install_dir/lib -lRDKitMolDraw2D -lRDKitForceFieldHelpers -lRDKitDescriptors -lRDKitForceField -lRDKitSubstructMatch -lRDKitOptimizer -lRDKitDistGeomHelpers -lRDKitDistGeometry -lRDKitChemReactions -lRDKitAlignment -lRDKitEigenSolvers -lRDKitDepictor -lRDKitcoordgen -lRDKitMolChemicalFeatures -lRDKitPartialCharges -lRDKitFileParsers -lRDKitRDGeometryLib -lRDKitGraphMol -lRDKitShapeHelpers -lRDKitFingerprints -lRDKitMolAlign -lRDKitMolTransforms -lRDKitChemTransforms -lRDKitSmilesParse -lRDKitGenericGroups -lRDKitRingDecomposerLib -lRDKitFilterCatalog -lRDKitCatalogs -lRDKitSubgraphs -lRDKitPartialCharges -lRDKitRDGeneral -lRDKitDataStructs -lboost_serialization -lboost_iostreams -l$BOOST_PYTHON_LIB $pl"
configure was successfull with just --with-rdkit-prefix= so waiting for make
--with-rdkit-prefix=$install_top_dir where $install_top_dir is /usr I guess
/usr/bin/ld: cannot find -lRDKitcoordgen: No such file or directory
/usr/bin/ld: cannot find -lRDKitRingDecomposerLib: No such file or directory
hm they don't come with
$ dpkg -L librdkit1
<alot>
$ dpkg -L librdkit1|grep RDKitcoordgen
$ dpkg -L librdkit1|grep RDKitRingDec
<allempty>
Looking into https://salsa.debian.org/debichem-team/rdkit/-/blob/master/debian/rules?ref_type=heads
Coordgen is a Schrödinger library.
https://github.com/schrodinger/coordgenlibs
I guess if it is not installed then the RDKit can't make a wrapper library.
You could try removing RDKitcoordgen and RDKitRingDecomposerLib from configure.ac
Coot doesn't directly use functions from either library.
this would not do it?
sed -i s,-lRDKitcoordgen,,g configure
sed -i s,-lRDKitRingDecomposerLib,,g configure
I imagine so.
ended with:
libtool: link: g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/13/crtbeginS.o .libs/layla_embedded.o .libs/generators.o .libs/notifier.o .libs/signals.o .libs/state.o .libs/ui.o .libs/utils.o ligand_editor_canvas/.libs/core.o .libs/ligand_editor_canvas.o ligand_editor_canvas/.libs/model.o ligand_editor_canvas/.libs/tools.o ligand_editor_canvas/.libs/render.o .libs/python_utils.o -Wl,-rpath -Wl,/var/www/debian/coot/2024/coot-Release-1.1.07/geometry/.libs -Wl,-rpath -Wl,/var/www/debian/coot/2024/coot-Release-1.1.07/lidia-core/.libs -Wl,-rpath -Wl,/var/www/debian/coot/2024/coot-Release-1.1.07/utils/.libs ../geometry/.libs/libcoot-geometry.so ../lidia-core/.libs/libcoot-lidia-core.so ../utils/.libs/libcoot-utils.so -lgtk-4 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -lgdk_pixbuf-2.0 -lcairo-gobject -lcairo -lgraphene-1.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -L/usr/lib -lRDKitMolDraw2D -lRDKitForceFieldHelpers -lRDKitDescriptors -lRDKitForceField -lRDKitSubstructMatch -lRDKitOptimizer -lRDKitDistGeomHelpers -lRDKitDistGeometry -lRDKitChemReactions -lRDKitAlignment -lRDKitEigenSolvers -lRDKitDepictor -lRDKitMolChemicalFeatures -lRDKitFileParsers -lRDKitRDGeometryLib -lRDKitGraphMol -lRDKitShapeHelpers -lRDKitFingerprints -lRDKitMolAlign -lRDKitMolTransforms -lRDKitChemTransforms -lRDKitSmilesParse -lRDKitGenericGroups -lRDKitFilterCatalog -lRDKitCatalogs -lRDKitSubgraphs -lRDKitPartialCharges -lRDKitRDGeneral -lRDKitDataStructs -lboost_serialization -lboost_iostreams -lboost_python311 -L/usr/lib/x86_64-linux-gnu -lpython3.11 -lcurl -lpthread -L/usr/lib/gcc/x86_64-linux-gnu/13 -L/usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/13/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/13/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/13/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/crtn.o -g -O2 -Wl,-soname -Wl,libcoot-layla.so.0 -o .libs/libcoot-layla.so.0.0.0
libtool: link: (cd ".libs" && rm -f "libcoot-layla.so.0" && ln -s "libcoot-layla.so.0.0.0" "libcoot-layla.so.0")
libtool: link: (cd ".libs" && rm -f "libcoot-layla.so" && ln -s "libcoot-layla.so.0.0.0" "libcoot-layla.so")
libtool: link: ar cr .libs/libcoot-layla.a layla_embedded.o generators.o notifier.o signals.o state.o ui.o utils.o ligand_editor_canvas/core.o ligand_editor_canvas.o ligand_editor_canvas/model.o ligand_editor_canvas/tools.o ligand_editor_canvas/render.o python_utils.o
libtool: link: ranlib .libs/libcoot-layla.a
libtool: link: ( cd ".libs" && rm -f "libcoot-layla.la" && ln -s "../libcoot-layla.la" "libcoot-layla.la" )
/bin/bash ../libtool --tag=CXX --mode=link g++ -DPKGDATADIR='"/usr/local/share/coot"' -DUSE_SQLITE3 -lcurl -DUSE_LIBPNG=1 -I/usr/include/libpng16 -g -O2 -Wall -Wno-unused -std=c++17 -o layla main.o libcoot-layla.la ../utils/libcoot-utils.la -lgtk-4 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -lgdk_pixbuf-2.0 -lcairo-gobject -lcairo -lgraphene-1.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lglib-2.0
libtool: link: g++ -DPKGDATADIR=\"/usr/local/share/coot\" -DUSE_SQLITE3 -DUSE_LIBPNG=1 -I/usr/include/libpng16 -g -O2 -Wall -Wno-unused -std=c++17 -o .libs/layla main.o -lcurl ./.libs/libcoot-layla.so ../utils/.libs/libcoot-utils.so -lgtk-4 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -lgdk_pixbuf-2.0 -lcairo-gobject -lcairo -lgraphene-1.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0
/usr/bin/ld: ./.libs/libcoot-layla.so: undefined reference to `coot::rdkit_mol(coot::dictionary_residue_restraints_t const&)'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:684: layla] Error 1
make[1]: Leaving directory '/var/www/debian/coot/2024/coot-Release-1.1.07/layla'
make: *** [Makefile:745: all-recursive] Error 1
need make VERBOSE=1?
This looks like a source-code bug.
Layla uses rdkit. Check the use of the #define USE_RDKIT - coot::rdkit_mol() should have been added to libcoot-lidia-core and libcoot-lidia-core should have been linked into libcoot-layla.
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 libcoot-lidia-core.so before -o libcoot-layla.so
What does this say?
nm --demangle lidia-core/.libs/libcoot-lidia-core.so | grep rdkit_mol
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 RDKitcoordgen and RDKitRingDecomposerLib, RDKit does not seem to have them in Debian. Most likely this is due to version difference, Debian has RDKit 202309.3.
I recall I had to patch lbg/Makefile.am to get rid of undefined reference messages:
--- 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_)
The lbg directory is just hanging around for historical reasons. It is not compiled. It cannot be compiled with GTK4.
lbg has been replaced by layla.
@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. It would be nice to have debian/ directory as soon as possible, as dependency collection alone took quite some time for me. Nevertheless, I managed to call cmake successfully, but configure still complains about:
checking for RDKit in NONE
Configuration error. No, bad... we do not have necessary RDKIT
I have removed RDKitcoordgen and RDKitRingDecomposerLib, but possibly some other modules could not be found as well.
I will continue my attempts next week. We may coordinate on IRC, that is an option.
@merkys How about doing acedrg after coot? 😃
Definitely! 😃
Re: Configuration error. No, bad... we do not have necessary RDKIT
If you specify --with-rdkit-prefix=<something> then you will not get this error message.
If you specify
--with-rdkit-prefix=<something>then you will not get this error message.
Indeed, this worked for me as --with-rdkit-prefix=/usr as RDKit libraries are under /usr/lib/ and headers at /usr/include/rdkit/. Nevertheless I ran into the same problem as @alexmyczko:
/usr/bin/ld: ./.libs/libcoot-layla.so: undefined reference to `coot::rdkit_mol(coot::dictionary_residue_restraints_t const&)'
libcoot-lidia-core.so does not seem to mention rdkit_mol (nm --demangle lidia-core/.libs/libcoot-lidia-core.so | grep rdkit_mol returns no output)
Hmm... See the build-it-3-3 script.
Are you passing --with-enhanced-ligand-tools to configure?
Are you passing
--with-enhanced-ligand-toolstoconfigure?
Success! I apparently missed this thinking that it may not affect the overall linking that much.
@alexmyczko I will start preparing debian/ directory ASAP.
The next major task will be the copyright review. I am aware coot is dedicated to free software which I greatly admire. However, we have to show that all files bearing "All rights reserved" or "Copyright" have explicit license pointer. We need to make sure there are no files with dubious licenses.
are you using sbuild and decopy?
are you using sbuild and decopy?
I am using sbuild. I was not aware of decopy, but I have been using licensecheck - I will give decopy a look.
I apparently missed this thinking that it may not affect the overall linking that much.
ENHANCED_LIGAND_TOOLS should go hand-in-hand with RDKit usage, but I don't test configure without --enhanced-ligand-tools so I missed that case.
I ran decopy and I didn't know what to make of the results.
I thought the fact that it picked up a scheme lambda function a copyright was funny:
(lambda (c) (is-solvent-chain? imol c))
i guess that is a false result, skip/ignore, i have found it very useful to skim through its result to make sure to not forget something obvious...
This is what I got. What do I do now?
https://salsa.debian.org/science-team/coot put your packaging here, and I'll try to process it with a result, explaining to you what I did and how I did... ?
I ran
decopyand I didn't know what to make of the results.I thought the fact that it picked up a scheme lambda function a copyright was funny:
(lambda (c) (is-solvent-chain? imol c))
None of the tools for copyright review is ideal, alas. What you got from decopy is a scaffold for debian/copyright file. It looks rather raw now, but it is a good starting point. I would look at files identified by decopy as lacking explicit license statement, also ones which may caused unusual output by decopy.
What might not get past Debian copyright audit immediately are files under MoleculesToTriangles/, buccaneer_ml_growing/, cootilus/, cootaneer/ and surface/ as they bear "all rights reserved" notice without explicitly mentioning the license. Kevin Cowtan told me personally that Nautilus subset used by coot is licensed under LGPL, but this may not get past the copyright audit as this knowledge both not included in coot's source and was communicated in personal correspondence.
https://salsa.debian.org/science-team/coot put your packaging here, and I'll try to process it with a result, explaining to you what I did and how I did... ?
Good idea, this is exactly what I am going to do.
MoleculesToTriangles/,buccaneer_ml_growing/,cootilus/,cootaneer/andsurface
Ha. All code not written by me.
I am going to delete surface right now.
I have not found cootlius or cootaneer to be useful and I don't teach them. I am not sure that they are even available in the new GTK4 interface. They can be removed if they prove to be problematic.
I now notice that I need to replace some code in MoleculesToTriangles - that might take a few days.
@alexmyczko I have pushed my packaging attempts to https://salsa.debian.org/science-team/coot. I re-used debian/ directory from earlier attempts (5 years ago?), but updating the dependency list and building routines (configure part). Feel free to modify.
I am having troubles with setting sbuild on a more effective build machine due to ongoing t64 and usrmerge transitions. On the other hand, this will divert my attention to debian/copyright 😄
@pemsley thanks a lot for clarifying cootlius, cootaneer and surface. Just FYI, you do not have to remove them from coot - we can exclude files/directories on Debian side, the only thing that matters is that the package builds without them.
@merkys same, dpkg-checkbuilddeps: error: Unmet build dependencies: libgtkmm-4.0-dev.. maybe tomorrow...
https://salsa.debian.org/science-team/coot/-/blob/master/debian/patches/compare-dictionaries.patch
https://salsa.debian.org/science-team/coot/-/blob/master/debian/patches/coot-make-shelx-restraints.patch
are not needed I think.
Also lidia and dynarama are no longer built.
https://salsa.debian.org/science-team/coot/-/blob/master/debian/patches/compare-dictionaries.patch https://salsa.debian.org/science-team/coot/-/blob/master/debian/patches/coot-make-shelx-restraints.patch are not needed I think.
Thanks for reviewing. Most of the patches are no longer applied (only those which are not commented out in https://salsa.debian.org/science-team/coot/-/blob/master/debian/patches/series).
OK.
I have remove CPPFLAGS from swig usage.
OK. I have remove CPPFLAGS from swig usage.
Right, I was about to write concerning that. Apparently swig does not understand everything what goes to CPPFLAGS. Maybe GUILE_CPPFLAGS or SWIG_CPPFLAGS are more appropriate here? I think I have seen these variables used in other Makefiles of coot.
I have spent some time investigating how to compile the debian/copyright file and I came to a conclusion that the easiest approach would be the following: add an all-encompassing entry on top of debian/copyright:
Files: *
Copyright: 2001-2007, The University of York
2007-2009, The University of Oxford
2010-2016, Medical Research Council
2001-2024, Paul Emsley
License: GPL-3+
and then list all the files which have different licenses and/or copyright holders below. The number of such files seems doable. @pemsley is this OK with you? By the way, one more directory, protein_db/, contains files with "all rights reserved" notices.
Current debian/copyright is far from ideal at the moment, but I am slowly getting to what I would like to have.
The cross-over between Oxford and Medical Research Council was 2012 (not 2010).
Why do you prefer this new proposal over what already exists?
I don't understand what "all rights reserved" means and what makes it an issue. Is it because there is no license? If/when I get the go-ahead, I will change the notice for files in cootilus, cootaneer and protein_db.
paul.emsley@bioch.ox.ac.uk is a dead email address
Source: http://coot.googlecode.com/svn/trunk/ is dead.
The cross-over between Oxford and Medical Research Council was 2012 (not 2010).
Thanks, fixed.
Why do you prefer this new proposal over what already exists?
Current debian/copyright was auto-generated a bunch of years ago. It badly needs updating and decrufting in order to be maintainable. Having a concise debian/copyright would be easier to update with subsequent coot releases, as newly added files will fall under top-level Files: * rule and only the ones with different copyright owners/licenses will have to be added separately. Please let me know should you have any objections to this.
I don't understand what "all rights reserved" means and what makes it an issue. Is it because there is no license? If/when I get the go-ahead, I will change the notice for files in
cootilus,cootaneerandprotein_db.
Some of my packages were rejected by Debian due to unclear licensing of individual files, but now I cannot trace back any case when it happened due to "all rights reserved" notice. So maybe there is nothing wrong with it, just me being overly cautious. Let us keep the current license statements for now and see how the Debian's copyright review goes. I am not a lawyer, though.
paul.emsley@bioch.ox.ac.ukis a dead email address
Source: http://coot.googlecode.com/svn/trunk/is dead.
I have replaced these with links to GitHub. This seems to be the usual practice in Debian for GitHub-based projects, but let me know if you prefer other addresses.
There will be action on the files in the various directories mentioned above in the next few days.
once it works on debian, I will try a homebrew recipe for macOS :)
once it works on debian, I will try a homebrew recipe for macOS :)
Thas has been under discussion for some time:
#33
I also have a GitHub Action that tries to build using it.
I managed to successfully build the package on Debian. The remaining tasks for Debian package:
- actually try it (current Debian unstable transitions for t64 and usrmerge caused installability problems on my machine, thus this is a question of time - I believe next week to bring more stability)
- CMake part
-
debian/copyright - fonts (Debian already has Vera and BitStream fonts packaged; introducing copies is discouraged, thus these fonts should either be symlinked or have their paths patched in coot)
- shared libraries (see below)
- tests (
python-tests/houses a test suite which could be used to automatically check against integrity regressions) - integrate with gemmi (nice to have)
Now about shared libraries. Coot is dynamically linked against a bunch of its own shared libraries (libcoot* and some other names). In Debian these will have to be packaged either as public or private shared libraries:
- Public ones would live under
/usr/lib/<multiarch-triplet>/which is in defaultLD_LIBRARY_PATHthus other programs linking against-lcoot*would find them without additional effort. Public shared libraries are expected to maintain ABI stability. - Private ones would live under
/usr/lib/<multiarch-triplet>/coot/which is not under the defaultLD_LIBRARY_PATH. This option does not impose any requirements on the ABI, but might need adjusting coot's launcher to look for them there.
Running the tests in python-tests requires additional data files. One can run less extensive internal tests that do not require additional data. Or that used to be the case - it seem that I need to reactivate that option.
What needs to be done for the CMake part?
Fonts are something that you will patch, I take it.
Let's make the libraries private (except the CMake target libcootapi, I suppose). Coot's launcher (bin/coot) in your case can be replaced by a one-liner
exec $prefix/libexec/coot-bin $* or some such. The other stuff is only needed for the binary tar ball if the prefix directory is relocated.
Running the tests in
python-testsrequires additional data files. One can run less extensive internal tests that do not require additional data. Or that used to be the case - it seem that I need to reactivate that option.
Right, additional data files might be an issue. So less extensive internal tests would be very nice to have.
What needs to be done for the CMake part?
Not much - I just have to add it to Debian package building rules. I succeeded running CMake build manually, thus it should be trivial to add it to the rules.
Fonts are something that you will patch, I take it.
Yes.
Let's make the libraries private (except the CMake target
libcootapi, I suppose). Coot's launcher (bin/coot) in your case can be replaced by a one-linerexec $prefix/libexec/coot-bin $*or some such. The other stuff is only needed for the binary tar ball if the prefix directory is relocated.
OK, thanks, this is what I will do.
Let's make the libraries private (except the CMake target
libcootapi, I suppose). Coot's launcher (bin/coot) in your case can be replaced by a one-linerexec $prefix/libexec/coot-bin $*or some such. The other stuff is only needed for the binary tar ball if the prefix directory is relocated.
Am I right that libcootapi should be a public library? If so, it does not seem to be installed under CMAKE_INSTALL_PREFIX by CMake (CMakeLists.txt probably misses install()) and it does not have a soversion (version appended to soname), viz:
coot$ objdump -x debian/tmp/usr/lib/x86_64-linux-gnu/libcoot-cabuild.so | grep SONAME
SONAME libcoot-cabuild.so.0
coot$ objdump -x obj-x86_64-linux-gnu/libcootapi.so | grep SONAME
SONAME libcootapi.soAm I right that libcootapi should be a public library
That question might mean more to you than to me - but it does seem possible that there will be C++ application developers who want to use the C++ api of Coot. Most developers will use the Python module - like RDKit, I suppose.
install(TARGETS cootapi DESTINATION lib)
Doesn't that do the trick? I don't understand much about CMake.
It seems to me that the soname should be "1.1" - I may change the API in future - I have done so in the recent past.
Am I right that libcootapi should be a public library
That question might mean more to you than to me - but it does seem possible that there will be C++ application developers who want to use the C++ api of Coot. Most developers will use the Python module - like RDKit, I suppose.
OK, libcootapi should be a public library then.
install(TARGETS cootapi DESTINATION lib)Doesn't that do the trick? I don't understand much about CMake.
Maybe the following is more appropriate:
install(TARGETS cootapi DESTINATION ${CMAKE_INSTALL_PREFIX}/lib)I do not know much about CMake either, but other install commands start with ${CMAKE_INSTALL_PREFIX} prefix. I am not sure where paths without it lead.
It seems to me that the soname should be "1.1" - I may change the API in future - I have done so in the recent past.
Sure, this is usually the case. Then the following instruction needs to be added for CMake:
set_target_properties(cootapi PROPERTIES SOVERSION 1.1)Maybe the following is more appropriate:
install(TARGETS cootapi DESTINATION ${CMAKE_INSTALL_PREFIX}/lib)
This seems to do the same as already existing code:
install(TARGETS cootapi DESTINATION lib)--self-test to run a few self tests (no external data needed). Returns with 0 exit status on success.
I have tweaked CMakeLists.txt in the light of the above discussion.
--self-testto run a few self tests (no external data needed). Returns with 0 exit status on success.
Thanks. I tried running this test on source of git commit 28325c4 (latest) and got the following output:
INFO:: Running internal self tests
INFO:: Test Clipper core : OK
INFO:: Test Clipper contrib: OK
run_internal_tests() --------- we have 8 internal test functionns
Entering test: kevin's torsion test
PASS: kevin's torsion test
Entering test: test_alt_conf_rotamers
INFO:: Reading coordinate file: /home/andrius/data/greg-data/tutorial-modern.pdb
INFO:: file /home/andrius/data/greg-data/tutorial-modern.pdb has been read.
FAIL: test_alt_conf_rotamers found only 0 rotamers
Tests seem to reach for /home/andrius/data/greg-data/tutorial-modern.pdb which is outside the source tree (moreover, I cannot find greg-data in the source). Thus I symlinked coot's data/ directory to ~/data/greg-data and now the required test files are found. Interestingly, despite FAIL on the last line, the exit status is 0. Maybe this is OK then?
I have tweaked
CMakeLists.txtin the light of the above discussion.
Thanks, I confirm that the soversion is visible now.
Oh, my bad. I should have checked the directory. --self-test (i.e. pure Coot install) shouldn't know about greg-data.
I don't like FAIL and zero exit status. I will investigate that too.
By the way, there is still one occurrence of swig call with CPPFLAGS which fails if CPPFLAGS contains anything unknown to swig:
Line 181 in de224b2
OK, both the --self-test problems has been cleaned up 88d8739
So I think that you can tick the "tests" box.
By the way, there is still one occurrence of swig call with CPPFLAGS which fails if CPPFLAGS contains anything unknown to swig:
Ah yes. Python too. Fixed in 12401d5
Do you need anything more from me re debian/copyright?
Thanks, tests are now working (and passing successfully). I confirm that the swig issue is as well fixed now.
As for debian/copyright, I think copyright details are clear for all files now. For files with "all rights reserved" without explicit license I am just going to assume they fall under the GPL-3+ as the rest of the project.
Nevertheless, collecting all the copyright holders for all the files will take time. I have already greatly simplified the debian/copyright by stating that these are the copyright holders for all the files:
Files: *
Copyright: 2001-2007, The University of York
2007-2012, The University of Oxford
2012-2016, Medical Research Council
1999-2024, Paul Emsley
2004-2011, Bernhard Lohkamp
License: GPL-3+
It would further simplify debian/copyright a lot if I could put Kevin Cowtan and Kevin Keating here as well instead of cherry-picking their files separately. Please let me know if you agree or disagree with such treatment. Alternatively I would probably need to devise a script to look at all GPL-3+-licensed files and collate their holders and years. Current tools like decopy and licensecheck somewhy fail extracting copyright info from many files.
It seems that I unintentionally missed some. I will fix buccaneer_ml_growing and a few other files from Kevin tonight.
Can you have a look at the ligand/dMSFT* files and see if they are OK?
Kevin Cowtan and Kevin Keating should have cherry-picked files. I can make you a list for both.
It seems that I unintentionally missed some. I will fix
buccaneer_ml_growingand a few other files from Kevin tonight.
Thanks.
Can you have a look at the
ligand/dMSFT*files and see if they are OK?
Yes, they are licensed under BSD-3-Clause which is perfectly fine.
Kevin Cowtan and Kevin Keating should have cherry-picked files. I can make you a list for both.
Thanks. It would be nice to have an automated procedure for such cherry-picking in order to be able to update with every new coot release. Perhaps it would suffice to look for their surnames with something like grep -P 'Copyright.*Surname' and pass to awk/perl script to collate years? I think I could write something usable in a couple of minutes.
By the way, what about Bernhard Lohkamp? I have taken the liberty to add him under Files: * as well, but maybe his files should be cherry-picked as well?
For example, the following extracts all explicitly GPL-3+ versioned files:
find . -type f -print0 | xargs -0 grep -l 'GNU General Public License' | xargs grep -l 'either version 3 of the License' | xargs grep Cowtan | grep -i copyrightThis extracts files without explicit GPL license:
find . -name debian -prune -o -type f -print0 | xargs -0 grep -l Cowtan | xargs grep -L 'GNU General Public License' | xargs grep Cowtan | grep -i copyrightAfter that, extracting year range and outputting in debian/copyright format should be easy.
I think the current debian/copyright is more accurate and I prefer it.
Now that I understand a bit more about what it is, I would rather modify that than prune it back as you suggest.
I will spend some time in the next few days on fixing the notices and debian/copyright - maybe tomorrow, but maybe not.
By the way, what about Bernhard Lohkamp? maybe his files should be cherry-picked as well?
Yes, I think so.
Thank you for your support in this. Writing a debian/copyright is quite often the most tedious part of creating a Debian package. I strive to make them both accurate and maintainable.
Accuracy matters a lot, as package may not get into Debian because of missing license statements. In Debian, copyright review is done by a dedicated team. Sometimes a package has to wait months for its review. Then if its debian/copyright is inaccurate, it is "returned for repairs" and the process is repeated (including the waiting). I strive to get the debian/copyright right for its first review, but my success rate is around 2:3.
By maintainability I mean keeping the debian/copyright accurate for subsequent package updates. Subsequent package updates in Debian do not undergo copyright reviews (unless new binary packages are introduced, renamed, or soversions get bumped), but having outdated debian/copyright kind of defeats its purpose (and is a serious bug if noticed). I maintain a couple of Debian packages which I cannot keep up-to-date due to the complexity of their debian/copyright files.
Thus it would be nice if we could devise an algorithm to collate the files and their copyright holders for coot. As said, current tools produce both false-positives and false-negatives. It is nice that in coot source files are properly annotated. Too bad that current automated tools miss some of them - perhaps their regular expressions fail.
I think I am going to give licensecheck another shot. I will exclude all non-text files (images and sounds), fixup scheme files with sed (licensecheck does not understand scheme's ;;;; as comment line) and run licensecheck. The output will still need some manual work (like removing all UNKNOWN files which fall under top-level copyright and putting BSD-3-Clause for ligand/dSFMT* files), but I expect that that will require less work (and be more accurate) than my current approach of minimising the length of debian/copyright. Then I will add raw licensecheck output in order to diff it against licensecheck output for the subsequent coot releases. What do you think?
What are UNKNOWN files?
Which files do not need an embedded license?
autogen.sh
burn-up/make-new-graph.sh
burn-up/new-burn-point.sh
burn-up/process-rel-todo.awk
blog/_config.yml
.clang-format
ChangeLog
aux-scripts/mtrix-to-ncs-matrix.awk
What are
UNKNOWNfiles?
By UNKNOWN files I mean the ones from which licensecheck cannot extract any licensing info (no copyright holder and license indicators). Normally files without any indications are treated as falling under the top-level license appearing in COPYING (or similarly named) file.
Which files do not need an embedded license?
I think none of them needs an embedded license iff COPYING is applicable to them.
I think I am very close to getting to debian/copyright right. As said, I used licensecheck to prepare a draft for debian/copyright and filled in the missing licenses without merging any of the paragraphs. You may find my attempt here (please mind that it is on a branch). The file is quite long now, but I think it has a great chance to pass the copyright review, as all licenses and copyright holders are explicitly listed for every file.
I still need some time to finalise this debian/copyright, but I expect the remaining work to take less than an hour. After finishing debian/copyright I am going to upload the package for the copyright review. As the review may take a few weeks, this will give us time to polish the package itself.
I recently read the copyright notices of several files. I was surprised that they were GPLed. I had intended for them to be LGPL3+. I thought I had converted the licenses years ago. I wll have to go back and convert MoleleculesToTriangles cootilus, cootaneer and protein_db also. Baah.
I will write you here when those files have been changed.
The *-kk.cc files will remain GPL, they are not mine to change.
I have removed a few unused files, you may have noticed.
I notice that other software package copyright notices have something like
This file is part of GnuTLS
or
This file is part of the GNU MP Library.
or
This file is part of GNU Nettle.
after the copyright line.
Is this line needed?
I notice that other software package copyright notices have something like
This file is part of GnuTLSorThis file is part of the GNU MP Library.orThis file is part of GNU Nettle.after the copyright line. Is this line needed?
This does not affect the treatment of copyright notices (i.e., it is not needed by Debian). However, developers of code sometimes choose to indicate the name of the project in each/some code files. I guess this is done mostly to retain a pointer to the original codebase in case their files get copied to other people's projects.
@merkys if there is anything i can help with?
@alexmyczko at the moment I am waiting for @pemsley to finish checking the copyright notices. After that the package should be ready for its initial upload, and while we wait for the copyright review we can finish polishing it.
I plan to work on these tasks myself as I have already started them:
- Review and possibly simplify the packaging. There are still some leftover code/instructions from earlier packaging attempts which are not used anymore.
- Review the wrappers.
Here are some tasks that you may help with:
- Testing the package. For instance, I have a feeling that loading of remote PDB files does not work due to missing dependencies or changes to paths to Python files.
- Manpages. It would be best to reuse something from coot's documentation or to generate them with
help2man. Maintainer-written manpages are difficult to keep up-to-date. -
coots-nest. Morten Kjeldgaard has contributed some sort of coot's wrapper some 10 years ago. I am not quite sure what it does and if it still works. I think it would be best to omit it from Debian package until we sort it out. - Test building on non-amd64 architectures. I worked on amd64, thus it would be interesting to see how well it ports. But this can wait until the package is accepted to Debian, as in Debian builds will be attempted on all Debian-supported architectures.
Yes. Sorry for the delay. The days are just packed. I've been working on Moorhen too and I just haven't had the hours to sit down and fix this. I will give it a bash in the next few days (if I can get work done on my laptop).
I bungled the previous change - I meant to use the LGPL.
i can take 1, 2, and 4.
Morten Kjeldgaard is no longer a friend of the project - see his twitter comment for an example. So, I agree.
Re: non-amd64 bit: I have an as-yet-unboxed Raspberry Pi somewhere - I could try that. I expect the problem to be with the dependencies, e.g. RDKit, GTK4, PyGObject, clipper, gc - I don't see why the actually Coot part shouldn't just work.
oh that is slow, i have http://bananas.debian.net
OK, you can try the generic build script and see what happens...
get https://raw.githubusercontent.com/pemsley/coot/main/build-it-3-3
$ bash build-it-3-3
Thanks @alexmyczko for taking the tasks! Please mind that I worked in package-latest-dev-version branch as I would like to reserve master for coot releases at the moment.
Re coots-nest. I will take care of this and will exclude it from Debian package.
Re non-amd64. Debian supports a variety of architectures and machines with these architectures are made available for Debian developers to help with porting. But as said, this can wait until after coot gets accepted into Debian, as builds on all Debian architectures will be attempted automatically after that. Of course it does not hurt to try earlier.
cootilus/nautilus_lib.pdb is a PDB file, not source code. How does the license work for that (there are other such files, for example cootaneer/cootaneer-llk-2.40.dat, protein_db/protein.db).
Also cootaneer/Makefile-coot - that also doesn't have a copyright notice. It is not used, I think. Should I remove it?
I have added or made updates to many source code copyright notices.
My plan is to continue to do so add or change the others to LGPL 3.
This is slow-going, painstaking and dull.