I want to have a rpm package build with Copr1. My current build target list is Fedora 35, 36, rawhide and Centos 7 and Stream 8. I have not yet created the copr project.
Compiling on one of my machines, the package builds successfully on the Fedora variants with mock. The problem is that on Centos variants one of the build dependencies and some of its dependencies are not available. I have found appropriate srpm files and compiled them on one of my machines with the Centos Stream 8 (one of them required two custom patches). With those custom dependencies I am able to successfully compile the original package.
So just to be clear, the problem is that the spec file contains for example
BuildRequires: libsomething
where libsomething is available as a plain upstream package in some of the build targets while needs an additional custom repo for some other build targets.
The FAQ says the following about dependencies:
Can I depend on other packages, which are not in Fedora/EPEL?
Yes, they just need to be available in some yum repository. It can either be another Copr repo or a third-party yum repo (e.g jpackage). Click on “Edit” in your project and add the appropriate repositories into the “Repos” field. Packages from your project are available to be used at build time as well, but only for the project you are currently building and not from your other projects.
But this sounds like an all or nothing approach, and I absolutely do not want to override the already existing upstream packages, only provide them when they are missing.
So what strategy do people use to handle this?
Update: I have now created copr projects and made some attempts at building (after resolving dependencies of dependencies in several levels), but the problem is as I describe above. If I add copr://hlovdal/projectname as a build dependency then epel-8-x86_64 compiles fine because it is provided with the missing dependencies while fedora-35-x86_64 fails because the repository does not have any fedora packages. If I remove the repo epel fails while fedora succeeds.
I also attempted to add the base url from the corresponding /etc/yum.d.repo file, and only hardcode epel instead of $distname hoping that the fedora builds would just ignore non-existing/wrong repo setting, but the build does not like that and still fails.
1 Copr is Fedora's freely available build system.
Related
I checked out a gtk project inside a docker and during meson build found many dependencies are missing eg. libwayland-dev, libxrandr-dev...
Because meson fails at the first missing dependency, I had to redo this over and over to get install the entire list of dependencies that will be looked for using pkg-config. And, in projects with multiple git submodules, this becomes a lengthy process.
Wondering if I'm doing this whole thing wrong or if there is a way to get to the complete list of dependencies.
To get dependencies for your project, from build directory run:
meson introspect --dependencies
I have a repository that contains three python packages: a main package, and two addon packages, with shared documentation. Each project is in its own directory, with its own setup.py, as so:
Repository
Main Project
setup.py
Addon One
setup.py
Addon Two
setup.py
Documentation
RST files, RTD conf, etc.
Previously, I was using setuptools.find_packages() to build my packages, but was having issues with the contents of the packages bleeding together, as they shared namespaces. So I switched to specifying the packages I wanted to build, such as
packages=["Main Package"]
However, this broke my ReadTheDocs auto-build, where I had specified
- method: setuptools
path: Main Project
in .readthedocs.yml, with RTD now complaining my package (inside the Main Project directory) doesn't exist, as it attempts to build it.
In my project, I use a script to build the packages, where I move into each directory, run its setup, then move out. Works fine, my packages and documentation all build locally. However, it looks like RTD is only using the defined path to prepend my setup.py script, and therefore not finding the source package as the working directory is the parent directory (but I could be wrong!).
I've read through the documentation, including https://github.com/readthedocs/readthedocs.org/issues/4354 where the feature was originally added, but I have not been able to find a solution myself yet.
How can I tell RTD to change directory before building the packages, or is there an alternative approach that will support my repo structure?
Repository in question is here.
I found a solution:
I changed my local build script to use the root project directory, as per-RTD. I then added the directive package_dir={"": "[directory]"} to the setuptools.setup() calls in each project's setup.py.
I have an existing codebase where a number of third-party dependencies were added as Git submodules, and their directories are directly referenced inside CMakeLists.txt, as in include_directories(../external/foo).
Some of the dependencies are large projects, like FFmpeg, and I'd rather just use the version I installed to my system with a package manager. But the maintainer of the codebase wants to be able to continue using the in-tree dependencies.
I thought a compromise would be to configure CMake to permit both, either using an installed package, or using the in-tree submodules. I think find_package can be used to find the installed package, but is there a good way to implement this behavior that isn't too hacky?
You can add an option to your cmake file that allows the user to switch between the internal FFMpeg or the system one. option(INTREE_FFMPEG "Use the intree ffmpeg" ON). The option can be set either via the cmake-gui or as a command line switch.
I run: conan install Boost/1.64.0#conan/stable, and it fails.
Output:
C:\temp>conan install Boost/1.64.0#conan/stable
Boost/1.64.0#conan/stable: Not found in local cache, looking in remotes...
Boost/1.64.0#conan/stable: Trying with 'bintray'...
Boost/1.64.0#conan/stable: Trying with 'conan.io'...
ERROR: Unable to find 'Boost/1.64.0#conan/stable' in remotes
Trying other package, works:
C:\temp>conan install fmt/4.0.0#bincrafters/stable
fmt/4.0.0#bincrafters/stable: Not found in local cache, looking in remotes...
fmt/4.0.0#bincrafters/stable: Trying with 'bintray'...
fmt/4.0.0#bincrafters/stable: Trying with 'conan.io'...
Downloading conanmanifest.txt
[==================================================] 121B/121B
Downloading conanfile.py
[==================================================] 1.8KB/1.8KB
fmt/4.0.0#bincrafters/stable: Installing package
Requirements
fmt/4.0.0#bincrafters/stable from conan.io
Packages
fmt/4.0.0#bincrafters/stable:63da998e3642b50bee33f4449826b2d623661505
fmt/4.0.0#bincrafters/stable: Retrieving package 63da998e3642b50bee33f4449826b2d623661505
fmt/4.0.0#bincrafters/stable: Looking for package 63da998e3642b50bee33f4449826b2d623661505 in remote 'conan.io'
Downloading conanmanifest.txt
[==================================================] 938B/938B
Downloading conaninfo.txt
[==================================================] 491B/491B
Downloading conan_package.tgz
[==================================================] 159.8KB/159.8KB
fmt/4.0.0#bincrafters/stable: Package installed 63da998e3642b50bee33f4449826b2d623661505
Any idea why the package isn't found?
How to debug it?
Conan is a decentralized package manager (kind of git-like style), so it can have many remotes. By default it comes configured with 2 remotes:
conan-transit: Is a read-only copy of the old conan.io repository, which contains many different Boost packages, from different authors. Quality is variable, so some packages might work only for certain OS, or might fail for some configurations.
conan-center: It is a moderated/reviewed repository, package creators can submit inclusion requests to share their packages with the community.
So far conan-transit contains several Boost/1.64 packages, so can check it with:
$ conan search Boost* -r=conan-transit
$ conan search Boost* -r=conan-center
As you can see the package you are trying to install doesn't exist in these repositories.
As I said above, conan is decentralized, so you can use different remotes. For example, the "bincrafters" community has a bintray repo that can be added with:
$ conan remote add bincrafters https://api.bintray.com/conan/bincrafters/public-conan
$ conan search Boost* -r=bincrafters
You will see they have a large number of Boost/1.64 packages, because they have created a modularized version of boost, in which every library lives in a different package, so you only get installed what you need.
UPDATE: Packages in the central repository are being renamed by the community to lowercase. Try with boost lowercase in the above if necessary.
I have a CMake project to build multiple shared libraries and tools, most of these under subdirectories:
add_directory(libFirst)
add_directory(libSecond)
add_directory(myTool)
# etc...
The install(TARGET "someTarget" COMPONENT "someTarget" ...) rules are in the respective subdirectory/CMakeLists.txt files.
I would like to generate Debian packages for all of these using a make package command from the build directory. I have CPACK_DEB_COMPONENT_INSTALL set to ON.
The problem I'm facing, is that not all of the targets have the same VERSION and/or SOVERSION. For example, libFirst is at version 1.0.0.0 and libSecond is version 4.3.0.0. This means that the generated packages should also have different version, but the only way I've found to specify the version is to specify the CPACK_PACKAGE_VERSION_MAJOR, CPACK_PACKAGE_VERSION_MINOR and CPACK_PACKAGE_VERSION_PATCH variables (and perhaps the internal CPACK_PACKAGE_VERSION variable), which set the version for all generated packages.
Is there a way to set package versions per-component, for example by setting some variables similarly to the other CPACK_COMPONENT_<COMPONENT>_* or CPACK_DEBIAN_<COMPONENT>_* variables?
I don't think this is possible at the moment but I have created a merge-request (https://gitlab.kitware.com/cmake/cmake/merge_requests/2305) which provides this functionality.
I hope it will get approved but in the meantime you can locally change your CPackDeb.cmake as shown in this diff: https://gitlab.kitware.com/cmake/cmake/merge_requests/2305/diffs. The default location of that file is in /usr/share/cmake/Modules/CPackDeb.cmake.