9383e41382
**Summary** The previous change to pyproject.toml happened to only work for sources also using other, higher-priority build systems. The logic for adding the dependencies to PYTHON_MODULE recipes was still based on strings. Additionaly the dependencies were added multiple times for each `pyproject.toml` or `setup.cfg file` found. Don't add additional dependencies if PEP 517 is already among known_types Make sure the PEP517 dependencies are correctly added if the source also uses other build systems instead of wrapping them in pkgconfig() Signed-off-by: Thomas Staudinger <Staudi.Kaos@gmail.com> |
||
|---|---|---|
| .. | ||
| CI | ||
| Go | ||
| Hooks | ||
| Legacy/Scripts | ||
| perl | ||
| Scripts | ||
| Tasks | ||
| .gitignore | ||
| autobuild-ignore-doxygen.yml | ||
| autobuild-ignore-python-pytest.yml | ||
| iso_packages.txt | ||
| Makefile | ||
| Makefile.iso | ||
| Makefile.toplevel | ||
| mapping | ||
| README.md | ||
| STATELESSNESS | ||
common
See this page for setup documentation.
Repositories
Cloning
To clone all repositories indicated in our packages file, run the below mentioned command. Please note that this list is not comprehensive and members of the Solus Team are required to run separate tooling to ensure this packages file is up-to-date (to include new files or remove deprecated ones):
make clone
Updating
To update all cloned repositories, run the following:
make pull
Building
To build a package, first ensure solbuild is set up and the adequate symlinks are set up. This can be done by following our Building a Package documentation on the Help Center, linked at the top of this document.
Go into the directory of the package you wish to build and type:
make
Publish
Submission is only possible for maintainers. As a maintainer you may freely push to your package(s) and initiate builds for them, which will be pushed to the unstable repository. You can watch builds at the Solus Package Build Status Page
If you're submitting a package.yml build, ensure you also commit the pspec_$ARCH.xml
file, as builds are created from git tags.
cd $somepkg
make publish
solbuild
Install solbuild from the main repository. All builds are performed in the unstable repository, so unstable-x86_64 is the default build profile.
Install solbuild-config-unstable to lock builds to the unstable repository.
See man solbuild for further details.
Notes on yabi
This tool is not used directly anymore. It is kept as a useful example of how to use abi-wizard and explode eopkgs from go.
Historical information from DataDrake, note that ypkg3 is deprecated.
yabican and will mark libraries as missing if it cannot find them on your system.yabican and will mark libraries as missing if it cannot find matches for symbols inside the library. I haven't had a chance to make the errors more verbose, so you'll have to use your judgment.- It's OK to submit patches with UNKNOWN in abi_used_libs or abi_used_symbols. If you are updating a package and it's not part of a local stack upgrade, you probably have everything installed on your machine and it will work fine.
yabidoes not run inside the chroot so it won't see files from packages getting installed from your local repo. This won't be getting fixed untilypkg3handles ABI stuff inside the chroot. And that's perfectly fine as the point of yabi is to make sure we have the new abi_used_symbols files. If a symbol has an unknown library, it's still at least recorded and agrepwill find it and any additional information over whatabireportcan tell us, which is still an improvement.- I intentionally made it so that
yabiwould update the ABI reports even if libraries are marked as missing. This is to work around (4). If you think it's a bug, please check against (1) and (2).