Some required tools for compiling and testing libstorage-ng are:
gcc-c++ boost-devel libjson-c-devel libxml2-devel libtool doxygen graphviz python3-devel python3-networkx ruby ruby-devel rubygem-test-unit swig >= 3.0.3 and != 3.0.8 (from YaST:storage-ng)
In addition to the previous packages, add these distribution-specific packages as well.
For some openSUSE/SUSE distributions the naming of
rubygem-test-unit might be the following:
make -f Makefile.repo make -j$(nproc)
Some files used to generate the bindings must be updated using tools in the utils directory.
When changing any exception specification (those in comments for
doxygen) you have to run
./generate-catches.py > ../bindings/storage-catches.i.
When changing the class hierarchy of classes derived from Device or
Holder you have to run
./generate-downcast.py > ../bindings/storage-downcast.i.
Make sure the documentation generated by doxygen is up-to-date before running the utils above.
Running Unit Tests
make -j$(nproc) install DESTDIR=/tmp/scratch make -j$(nproc) check LOCALEDIR=/tmp/scratch/usr/share/locale
Making an RPM
make -f Makefile.repo make package cd package osc build --local-package --alternative-project=openSUSE:Factory
Creating Changes And Package And Submitting To OBS
Creating the changes file and tar archive are handled by jenkins using linuxrc-devtools.
You can generate a preview of the changes file by running
and create the tar.xz source archive by running
Package versions are tracked by setting version tags in git. The last version digit is auto-increased with every OBS commit.
The version can always be set manually by setting an appropriate tag in git.
VERSIONfile is auto-generated from the latest git tag.
The spec file template
libstorage-ng.spec.inis not used. Instead, the spec file from the OBS is used.
For a more detailed description about the handling of version numbers and changelog entries look here.
Versioning follows YaST's versioning scheme.
Currently this means
- 4.1.X for the
masterbranch submitted to
- 3.3.X for the
SLE-15-GAbranch submitted to
See especially the class hierarchy:
For continuous integration at GiHub the Travis CI service is used. To have the required build environment we use the yastdevel/libstorage-ng docker image. See the Travis documentation for more details.
Travis Cache Cleanup
The cache is maintained automatically and does not need any intervention. However, in a very rare case you might need to clear the cache and start from scratch.
- You can directly remove the cache archive at Travis, but this requires the appropriate access permissions.
- If you are not allowed to remove the cache at Travis then temporarily uncomment the cache cleanup code in the .travis.sh file. After the cache is cleared you can remove this temporary commit, Travis will use empty cache for the next build.