You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Numerous projects, including components under zeromq that served as role models for NUT CI with cross-pollination over time, benefit from integration with https://build.opensuse.org/ and both having recent iterations available in package repositories made for multiple (Linux) distributions, and checking (github statuses and all) that the packages are buildable for those distributions.
I suppose this would need bringing NUT-provided "reference" packaging into shape (like make package already implemented for some OSes), possibly drawing inspiration from DEB and SPEC files for those target distributions as shipped by them already, or from 42ITy fork which developed a means to build on a private OBS instance: https://github.com/42ity/nut/tree/FTY/obs
Note that special recipe file naming may be involved to ship numerous SPEC files that would be used by OBS for this or that distribution.
I am not sure that NUT as a project should "insist" on replacing distro-specific packages: after all, tight and "correct" integration with the OS lifecycle is better done by domain experts, but providing a way for users and testers to easily install a standardly-built replacement without guessing configure parameters every time would be cool. And it might help co-ordinate the sprawl of NUT packages (names, content) across the board - letting each distro shine where it is best, and letting NUT seem the same everywhere :)
In a way this follows up from #869 as addition of CI platform and practical use/test-case - yet another environment to weed out failures. Notably, OBS can be used to further trigger dependency builds, to check that NUT public API is not broken (as found in #1638 for example).
The text was updated successfully, but these errors were encountered:
jimklimov
added
the
CI
Entries related to continuous integration infrastructure (historically also recipes like Makefiles)
label
Nov 28, 2021
jimklimov
changed the title
CI/Packaging: Want integration with OpenSUSE Build Service for master branch
CI/Packaging: Want packaging recipes and integration with OpenSUSE Build Service for master branch
Nov 28, 2021
jimklimov
changed the title
CI/Packaging: Want packaging recipes and integration with OpenSUSE Build Service for master branch
CI/Packaging: Want packaging recipes and integration with OpenSUSE Build Service (OBS) for master branch
Sep 28, 2022
Numerous projects, including components under zeromq that served as role models for NUT CI with cross-pollination over time, benefit from integration with https://build.opensuse.org/ and both having recent iterations available in package repositories made for multiple (Linux) distributions, and checking (github statuses and all) that the packages are buildable for those distributions.
I suppose this would need bringing NUT-provided "reference" packaging into shape (like
make package
already implemented for some OSes), possibly drawing inspiration from DEB and SPEC files for those target distributions as shipped by them already, or from 42ITy fork which developed a means to build on a private OBS instance: https://github.com/42ity/nut/tree/FTY/obsNote that special recipe file naming may be involved to ship numerous SPEC files that would be used by OBS for this or that distribution.
I am not sure that NUT as a project should "insist" on replacing distro-specific packages: after all, tight and "correct" integration with the OS lifecycle is better done by domain experts, but providing a way for users and testers to easily install a standardly-built replacement without guessing configure parameters every time would be cool. And it might help co-ordinate the sprawl of NUT packages (names, content) across the board - letting each distro shine where it is best, and letting NUT seem the same everywhere :)
In a way this follows up from #869 as addition of CI platform and practical use/test-case - yet another environment to weed out failures. Notably, OBS can be used to further trigger dependency builds, to check that NUT public API is not broken (as found in #1638 for example).
The text was updated successfully, but these errors were encountered: