Re: Packaging Open Porous Media (OPM) software suite
Hi Markus, Welcome on board! I have added you to the salsa group of the Debian Science Team. Feel free to push your projects there. I did not have a deep look into the packaging, but have some notes: - Try to use the newer compat-version. 11 is a little bit outdated. - Please add autopkgtests for packages. - Try to add Gitlab-CI for every package. It definitely improves the package quality and makes the package maintenance easier. - Please consider reducing the number of source packages. Uploading/sponsoring 7 source packages, especially if some of them should go through NEW queue. It is pain. > - In the future we imight want to be able to install several versions I would recommend not to do it. At least in the official version of the Debian package. That just means that every new upload should have another binary name, NEW queue, sponsoring from DD etc. It can only have sense for very big and very popular packages like boost for example. But for small scientific packages it is just overhead. > Does the top-level directory in the tarballs need to have a special No. If you do "dpkg-source -x AAA.dsc" the top level directory will be overwritten. Just a general note. Make the simple things not too complicated. Otherwise the package will not work and is very difficult in maintenance. Best regards Anton Am Mi., 28. Apr. 2021 um 15:40 Uhr schrieb Markus Blatt : > Hi, > > I have recently posted an ITP (bug )for this software > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987381 > > > > * Package name: opm-common, opm-material, opm-grid, opm-models, opm- > simulators, opm-upscaling > Version : 2021.04 > Upstream Author : OPM > * URL : https://www.opm-project.org/ > * License : GPL2+/GPL3+ > Programming Lang: C++, Python > Description : Open Porous Media (OPM) software suite > . > The Open Porous Media (OPM) software suite provides libraries and > tools for modeling and simulation of porous media processes, especially > for simulating CO2 sequestration and improved and enhanced oil > recovery. > > > > I am part of the OPM development team. We are prepared to maintain the > packages, but as nobody of us is a Debian developer, we would of course > need help for uploading. We have not done so, but intend to ask Ansgar > Burchardt whether he has time for this. > > I have an account on salsa and the current version of the packaging > effort can be found there. https://salsa.debian.org/blattms/opm-common > https://salsa.debian.org/blattms/opm-material > https://salsa.debian.org/blattms/opm-models > https://salsa.debian.org/blattms/opm-grid > https://salsa.debian.org/blattms/opm-simulators > https://salsa.debian.org/blattms/opm-upscaling To us as recreational > packagers this looks good now, but chances are that we have missed > stuff. > > I also requested being added to the Debian Science team on Salsa, but > that does not seem to have happened yet (or I missed it). Once that > happens I will gladly push to https://salsa.debian.org/science-team. > > Some notes on the packaging: > > - Packaging is based on the branch point (git commit) for the upcoming > 2021.04 release. Once that is released we will add the new version. > - We use git-buildpackage with the default layout and pristine-tar > (there is a debian/dbp.conf file that activate pristine-tar, and tells > it which files to strip from upstream) > - We have stripped some sources for the Debian packaging (jenkins, > travis, embedded source code, upstream packaging for Redhat, Debian, > OpenSuse) to satisfy the Debian Policy and prevent unnecessary changes > from appearing in the Repositories of the Debian packaging. Note that > these are also stripped from the tarballs and listed in > debian/copyright (Excluded-Files) and debian/gbp.conf for ease of > maintenance. > - Apart from opm-material and opm-models, which are header-only > libraries and missing lib.deb because of this, most > repositories create Packages lib-dev.deb, lib.deb, > lib-doc.deb and (for opm-common, opm-grid, opm-simulators) > lib-bin.deb. There are also packages with python bindings: > python3-opm-common.deb, python3-opm-simulators.deb > - For the library packages the SONAME will change with each release, as > the ABI is quite unstable. The version is not part of the library > package name, which lintian would warn about. But we are overwriting > the warning currently. > - opm-upscaling is missing manpages for the binaries. This will be fixed > upstream and backported soon. > > Some questions: > > - In the future we imight want to be able to install several versions > of libopm-simulators-bin.deb concurrently (which would need to depend > on different versions of the library packages lib.deb, and > probably install binaries into different versioned directories and use > update-alternatives. Is there a proposed policy/approach to do this? I > would assume that this
Re: Bug#949767: arrayfire update fails in configure step
Gard Spreemann writes: > Gard Spreemann writes: > >> Andreas Tille writes: >> >>> Hi Aaron, >>> >>> On Tue, Apr 27, 2021 at 08:14:10PM -0400, Aaron M. Ucko wrote: Please try adding a build dependency on libclfft-dev and replacing src/backend/opencl/CMakeLists.txt's inclusion of build_clFFT with a call to find_package(clFFT) > Thanks a lot for your initial hint >>> >>> Thanks again. I now tried to learn from this and added a similar patch >>> for CLBLast[1] but as you can see in the new log[2] it is not that >>> simple. I tried to compare the content of >>> libclfft-dev_2.12.2-3.1_amd64.deb and libclblast-dev_1.5.2-1_amd64.deb >>> how the cmake files under /usr/lib/x86_64-linux-gnu/cmake/ are looking >>> like and I need to admit I have no idea why this fails. >> >> This seems to be just a typo on my part. The logs have >> >> *** >> CMake Warning at CMakeModules/build_CLBlast.cmake:8 (find_package): >> By not providing "FindCLBLast.cmake" in CMAKE_MODULE_PATH this project has >> asked CMake to find a package configuration file provided by "CLBLast", but >> CMake did not find one. >> Could not find a package configuration file provided by "CLBLast" with any >> of the following names: >> CLBLastConfig.cmake >> clblast-config.cmake >> Add the installation prefix of "CLBLast" to CMAKE_PREFIX_PATH or set >> "CLBLast_DIR" to a directory containing one of the above files. If >> "CLBLast" provides a separate development package or SDK, be sure it has >> been installed. >> *** >> >> libclblast-dev ships >> >> /usr/lib/x86_64-linux-gnu/cmake/CLBLast/CLBlastConfig.cmake >> >> Notice that there's both "CLBLast" and "CLBlast" in there! I'll >> investigate. > > Looks like an upstream bug; consider the inconsistent capitalization of > the second l in "clblast" online 363 in > > > https://salsa.debian.org/gspr/clblast/-/blob/54e86eec37593623a5f692a39d78355043a402ad/CMakeLists.txt#L363 > > I'll report it upstream and patch src:clblast. Could you try with the patch from the debian/gspr/typo branch of [1]? Alternatively, I put a built version of the patched clblast up at [2]. [1] https://salsa.debian.org/gspr/clblast.git [2] https://nonempty.org/~gspr/clblast-typo/ Best, Gard signature.asc Description: PGP signature
Re: Bug#949767: arrayfire update fails in configure step
Gard Spreemann writes: > Andreas Tille writes: > >> Hi Aaron, >> >> On Tue, Apr 27, 2021 at 08:14:10PM -0400, Aaron M. Ucko wrote: >>> Please try adding a build dependency on libclfft-dev and replacing >>> src/backend/opencl/CMakeLists.txt's inclusion of build_clFFT with a call >>> to >>> >>> find_package(clFFT) >>> >>> > Thanks a lot for your initial hint >> >> Thanks again. I now tried to learn from this and added a similar patch >> for CLBLast[1] but as you can see in the new log[2] it is not that >> simple. I tried to compare the content of >> libclfft-dev_2.12.2-3.1_amd64.deb and libclblast-dev_1.5.2-1_amd64.deb >> how the cmake files under /usr/lib/x86_64-linux-gnu/cmake/ are looking >> like and I need to admit I have no idea why this fails. > > This seems to be just a typo on my part. The logs have > > *** > CMake Warning at CMakeModules/build_CLBlast.cmake:8 (find_package): > By not providing "FindCLBLast.cmake" in CMAKE_MODULE_PATH this project has > asked CMake to find a package configuration file provided by "CLBLast", but > CMake did not find one. > Could not find a package configuration file provided by "CLBLast" with any > of the following names: > CLBLastConfig.cmake > clblast-config.cmake > Add the installation prefix of "CLBLast" to CMAKE_PREFIX_PATH or set > "CLBLast_DIR" to a directory containing one of the above files. If > "CLBLast" provides a separate development package or SDK, be sure it has > been installed. > *** > > libclblast-dev ships > > /usr/lib/x86_64-linux-gnu/cmake/CLBLast/CLBlastConfig.cmake > > Notice that there's both "CLBLast" and "CLBlast" in there! I'll > investigate. Looks like an upstream bug; consider the inconsistent capitalization of the second l in "clblast" online 363 in https://salsa.debian.org/gspr/clblast/-/blob/54e86eec37593623a5f692a39d78355043a402ad/CMakeLists.txt#L363 I'll report it upstream and patch src:clblast. Best, Gard
Re: Bug#949767: arrayfire update fails in configure step
Andreas Tille writes: > Hi Aaron, > > On Tue, Apr 27, 2021 at 08:14:10PM -0400, Aaron M. Ucko wrote: >> Please try adding a build dependency on libclfft-dev and replacing >> src/backend/opencl/CMakeLists.txt's inclusion of build_clFFT with a call >> to >> >> find_package(clFFT) >> >> > Thanks a lot for your initial hint > > Thanks again. I now tried to learn from this and added a similar patch > for CLBLast[1] but as you can see in the new log[2] it is not that > simple. I tried to compare the content of > libclfft-dev_2.12.2-3.1_amd64.deb and libclblast-dev_1.5.2-1_amd64.deb > how the cmake files under /usr/lib/x86_64-linux-gnu/cmake/ are looking > like and I need to admit I have no idea why this fails. This seems to be just a typo on my part. The logs have *** CMake Warning at CMakeModules/build_CLBlast.cmake:8 (find_package): By not providing "FindCLBLast.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "CLBLast", but CMake did not find one. Could not find a package configuration file provided by "CLBLast" with any of the following names: CLBLastConfig.cmake clblast-config.cmake Add the installation prefix of "CLBLast" to CMAKE_PREFIX_PATH or set "CLBLast_DIR" to a directory containing one of the above files. If "CLBLast" provides a separate development package or SDK, be sure it has been installed. *** libclblast-dev ships /usr/lib/x86_64-linux-gnu/cmake/CLBLast/CLBlastConfig.cmake Notice that there's both "CLBLast" and "CLBlast" in there! I'll investigate. Best, Gard
Re: arrayfire update fails in configure step
Hi Aaron, On Tue, Apr 27, 2021 at 08:14:10PM -0400, Aaron M. Ucko wrote: > Please try adding a build dependency on libclfft-dev and replacing > src/backend/opencl/CMakeLists.txt's inclusion of build_clFFT with a call > to > > find_package(clFFT) > > > Thanks a lot for your initial hint Thanks again. I now tried to learn from this and added a similar patch for CLBLast[1] but as you can see in the new log[2] it is not that simple. I tried to compare the content of libclfft-dev_2.12.2-3.1_amd64.deb and libclblast-dev_1.5.2-1_amd64.deb how the cmake files under /usr/lib/x86_64-linux-gnu/cmake/ are looking like and I need to admit I have no idea why this fails. Kind regards Andreas. [1] https://salsa.debian.org/science-team/arrayfire/-/blob/master/debian/patches/use_debian_packaged_libs.patch#L64 [2] https://salsa.debian.org/science-team/arrayfire/-/jobs/1611074#L1602 -- http://fam-tille.de
Packaging Open Porous Media (OPM) software suite
Hi, I have recently posted an ITP (bug )for this software https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987381 * Package name: opm-common, opm-material, opm-grid, opm-models, opm- simulators, opm-upscaling Version : 2021.04 Upstream Author : OPM * URL : https://www.opm-project.org/ * License : GPL2+/GPL3+ Programming Lang: C++, Python Description : Open Porous Media (OPM) software suite . The Open Porous Media (OPM) software suite provides libraries and tools for modeling and simulation of porous media processes, especially for simulating CO2 sequestration and improved and enhanced oil recovery. I am part of the OPM development team. We are prepared to maintain the packages, but as nobody of us is a Debian developer, we would of course need help for uploading. We have not done so, but intend to ask Ansgar Burchardt whether he has time for this. I have an account on salsa and the current version of the packaging effort can be found there. https://salsa.debian.org/blattms/opm-common https://salsa.debian.org/blattms/opm-material https://salsa.debian.org/blattms/opm-models https://salsa.debian.org/blattms/opm-grid https://salsa.debian.org/blattms/opm-simulators https://salsa.debian.org/blattms/opm-upscaling To us as recreational packagers this looks good now, but chances are that we have missed stuff. I also requested being added to the Debian Science team on Salsa, but that does not seem to have happened yet (or I missed it). Once that happens I will gladly push to https://salsa.debian.org/science-team. Some notes on the packaging: - Packaging is based on the branch point (git commit) for the upcoming 2021.04 release. Once that is released we will add the new version. - We use git-buildpackage with the default layout and pristine-tar (there is a debian/dbp.conf file that activate pristine-tar, and tells it which files to strip from upstream) - We have stripped some sources for the Debian packaging (jenkins, travis, embedded source code, upstream packaging for Redhat, Debian, OpenSuse) to satisfy the Debian Policy and prevent unnecessary changes from appearing in the Repositories of the Debian packaging. Note that these are also stripped from the tarballs and listed in debian/copyright (Excluded-Files) and debian/gbp.conf for ease of maintenance. - Apart from opm-material and opm-models, which are header-only libraries and missing lib.deb because of this, most repositories create Packages lib-dev.deb, lib.deb, lib-doc.deb and (for opm-common, opm-grid, opm-simulators) lib-bin.deb. There are also packages with python bindings: python3-opm-common.deb, python3-opm-simulators.deb - For the library packages the SONAME will change with each release, as the ABI is quite unstable. The version is not part of the library package name, which lintian would warn about. But we are overwriting the warning currently. - opm-upscaling is missing manpages for the binaries. This will be fixed upstream and backported soon. Some questions: - In the future we imight want to be able to install several versions of libopm-simulators-bin.deb concurrently (which would need to depend on different versions of the library packages lib.deb, and probably install binaries into different versioned directories and use update-alternatives. Is there a proposed policy/approach to do this? I would assume that this needs to be prepared now by putting some kind of versioning into the Debian packages for the libraries (e.g. like Petsc). - Does the top-level directory in the tarballs need to have a special name (like opm-common-2021.04 for version 2021.04 of opm-common)? The reason for asking is that upstream tags final versions as release//final, which will make uuscan us funny looking opm-common-release-2021.04-final. If it does upstream needs to use the more common tagging scheme v, or we need to create the tarballs ourselves and use gbp import-orig . Thanks a lot for your kind help. Cheers, Markus -- Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de Pedettistr. 38, 85072 Eichstätt, Germany, USt-Id: DE279960836 Tel.: +49 (0) 160 97590858
