Merging custom CentOS packages to Master
Hello all, Next big activity is pushing the required CentOS 8 packages to the Uyuni Master branches. The distribution of packages to repositories on the Uyuni Server are: - Uyuni Master: 98 + Uyuni Master Other: 58 - New custom packages: 46 - EPEL: 34 - PowerTools: 50 - CentOS 8 BaseOS: 477 + CentOS 8 AppStream: 196 1) I would push my newly created custom packages including kits to "Uyuni Master Other". Are there any guidelines? Otherwise I would just split out the change log of the spec file and submit. 2) What do we do about the EPEL and PowerTools packages? I feel a bit uneasy of pushing 84 packages (+ probable build dependencies) to OPS. Especially when you consider that these packages need to be maintained and monitored for security fixes. 3) One more (not so pleasant) thought is the module system. Installation requires activation of 10 modules and deactivation of 2 more modules. If we go for loading all packages of point 2) into OBS, we might as well add the ones from the modules and create an Uyuni Server module (one per major release?). That would simplify the user experience and probably use the module system as intended (but kill maintainability...). Let me know your thoughts and ways to continue. Best wishes, Stefan
Hi Stefan We need a bit of time to review this an give a proper answer. We hope that we can enable CentOS building on Master by end of the week and then we can try some tricks to include a selection of EPEL and PowerTools packages into a resulting repo for Uyuni server. These packages would be refreshed with every "release" of Uyuni. So we would get also fixes of these packages when they appear in EPEL/PowerTools. What would help is, if you could provide a list of packages which are required and the source where it come from. Also packages you want to submit newly . And the list of Steams which needs to be enabled would help too. Thanks Am Dienstag, 2. Februar 2021, 12:37:29 CET schrieb Stefan Bluhm:
Hello all,
Next big activity is pushing the required CentOS 8 packages to the Uyuni Master branches.
The distribution of packages to repositories on the Uyuni Server are: - Uyuni Master: 98 + Uyuni Master Other: 58
- New custom packages: 46 - EPEL: 34 - PowerTools: 50
- CentOS 8 BaseOS: 477 + CentOS 8 AppStream: 196
1) I would push my newly created custom packages including kits to "Uyuni Master Other". Are there any guidelines? Otherwise I would just split out the change log of the spec file and submit.
2) What do we do about the EPEL and PowerTools packages? I feel a bit uneasy of pushing 84 packages (+ probable build dependencies) to OPS. Especially when you consider that these packages need to be maintained and monitored for security fixes.
3) One more (not so pleasant) thought is the module system. Installation requires activation of 10 modules and deactivation of 2 more modules. If we go for loading all packages of point 2) into OBS, we might as well add the ones from the modules and create an Uyuni Server module (one per major release?). That would simplify the user experience and probably use the module system as intended (but kill maintainability...).
Let me know your thoughts and ways to continue.
Best wishes,
Stefan
-- Regards Michael Calmer -------------------------------------------------------------------------- Michael Calmer SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg T: +49 (0) 911 74053 0 F: +49 (0) 911 74053575 - e-mail: Michael.Calmer@suse.com -------------------------------------------------------------------------- SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer (HRB 36809, AG Nürnberg)
Hello
Tricks = OBS download service to bring EPEL and PowerTools packages to the Uyuni repos? That sounds like a real possibility, and it should save a ton of manual work.
Thank you
Pau Garcia Quiles
SUSE Manager Product Owner & Technical Project Manager
Phone: +34 91 048 7632
SUSE Software Solutions Spain
________________________________
From: Michael Calmer
Hello all,
Next big activity is pushing the required CentOS 8 packages to the Uyuni Master branches.
The distribution of packages to repositories on the Uyuni Server are: - Uyuni Master: 98 + Uyuni Master Other: 58
- New custom packages: 46 - EPEL: 34 - PowerTools: 50
- CentOS 8 BaseOS: 477 + CentOS 8 AppStream: 196
1) I would push my newly created custom packages including kits to "Uyuni Master Other". Are there any guidelines? Otherwise I would just split out the change log of the spec file and submit.
2) What do we do about the EPEL and PowerTools packages? I feel a bit uneasy of pushing 84 packages (+ probable build dependencies) to OPS. Especially when you consider that these packages need to be maintained and monitored for security fixes.
3) One more (not so pleasant) thought is the module system. Installation requires activation of 10 modules and deactivation of 2 more modules. If we go for loading all packages of point 2) into OBS, we might as well add the ones from the modules and create an Uyuni Server module (one per major release?). That would simplify the user experience and probably use the module system as intended (but kill maintainability...).
Let me know your thoughts and ways to continue.
Best wishes,
Stefan
-- Regards Michael Calmer -------------------------------------------------------------------------- Michael Calmer SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg T: +49 (0) 911 74053 0 F: +49 (0) 911 74053575 - e-mail: Michael.Calmer@suse.com -------------------------------------------------------------------------- SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer (HRB 36809, AG Nürnberg)
Hello,
coming back to earlier discussions, also during the monthly call, I have my repos back up to speed to make Uyuni deployable again. This time AlmaLinux.
[ https://build.opensuse.org/project/show/home:sbluhm:systemsmanagement:Uyuni:... | https://build.opensuse.org/project/show/home:sbluhm:systemsmanagement:Uyuni:... ]
If you link to this repo, all packages of Uyuni:Master and Uyuni Master:Other should build (excluding any Go packages, cobbler and ones I missed).
Packages required for server installation (publish):
apache-commons-daemon
apache-commons-digester
apache-commons-discovery
apache-commons-fileupload
apache-commons-validator
btrfs-progs
dom4j
ecj
geronimo-jta
icu4j
javapackages-tools
joda-time
nekohtml
openslp
protobuf
python-certifi
python-debian
python-futures
python-m2crypto
python-pycurl
python-singledispatch
python-tornado
python-ws4py
python-zmq
python2-msgpack
python2-typing
python3-psycopg2
python3-pycryptodomex
python3-pyyaml
servletapi5
snapper
spacewalk-selinux
tomcat
unix2_chkpwd
xpp3
Packages required for build only:
apache-commons-el
apache-commons-fileupload-kit
docbook-utils
dom4j-kit
geronimo-jaxrpc
geronimo-jaxrpc-kit
geronimo-saaj
geronimo-saaj-kit
jaxen
jaxen-kit
joda-convert
maven-javadoc-plugin 3.2.0
maven-javadoc-plugin-kit 3.2.0
maven-javadoc-plugin-kit 3.0.0
maven-javadoc-plugin 3.0.0
meson
mod_wsgi
msv-kit
msv-xsdlib
openSUSE-build-key
perl-Try-Tiny
protobuf-kit
python2-simplejson
servletapi4
snakeyaml
wsdl4j
xml-commons-apis-bootstrap
xstream
So still waiting for instructions how to best proceed with this.
Thank you,
Stefan
From: Michael Calmer
Hello all,
Next big activity is pushing the required CentOS 8 packages to the Uyuni Master branches.
The distribution of packages to repositories on the Uyuni Server are: - Uyuni Master: 98 + Uyuni Master Other: 58
- New custom packages: 46 - EPEL: 34 - PowerTools: 50
- CentOS 8 BaseOS: 477 + CentOS 8 AppStream: 196
1) I would push my newly created custom packages including kits to "Uyuni Master Other". Are there any guidelines? Otherwise I would just split out the change log of the spec file and submit.
2) What do we do about the EPEL and PowerTools packages? I feel a bit uneasy of pushing 84 packages (+ probable build dependencies) to OPS. Especially when you consider that these packages need to be maintained and monitored for security fixes.
3) One more (not so pleasant) thought is the module system. Installation requires activation of 10 modules and deactivation of 2 more modules. If we go for loading all packages of point 2) into OBS, we might as well add the ones from the modules and create an Uyuni Server module (one per major release?). That would simplify the user experience and probably use the module system as intended (but kill maintainability...).
Let me know your thoughts and ways to continue.
Best wishes,
Stefan
--
Regards
Michael Calmer
--------------------------------------------------------------------------
Michael Calmer
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg
T: +49 (0) 911 74053 0
F: +49 (0) 911 74053575 - e-mail: Michael.Calmer@suse.com
--------------------------------------------------------------------------
SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer (HRB 36809, AG Nürnberg)
Von: "Pau Garcia Quiles"
Hello all,
Next big activity is pushing the required CentOS 8 packages to the Uyuni Master branches.
The distribution of packages to repositories on the Uyuni Server are: - Uyuni Master: 98 + Uyuni Master Other: 58
- New custom packages: 46 - EPEL: 34 - PowerTools: 50
- CentOS 8 BaseOS: 477 + CentOS 8 AppStream: 196
1) I would push my newly created custom packages including kits to "Uyuni Master Other". Are there any guidelines? Otherwise I would just split out the change log of the spec file and submit.
2) What do we do about the EPEL and PowerTools packages? I feel a bit uneasy of pushing 84 packages (+ probable build dependencies) to OPS. Especially when you consider that these packages need to be maintained and monitored for security fixes.
3) One more (not so pleasant) thought is the module system. Installation requires activation of 10 modules and deactivation of 2 more modules. If we go for loading all packages of point 2) into OBS, we might as well add the ones from the modules and create an Uyuni Server module (one per major release?). That would simplify the user experience and probably use the module system as intended (but kill maintainability...).
Let me know your thoughts and ways to continue.
Best wishes,
Stefan
-- Regards Michael Calmer -------------------------------------------------------------------------- Michael Calmer SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg T: +49 (0) 911 74053 0 F: +49 (0) 911 74053575 - e-mail: Michael.Calmer@suse.com -------------------------------------------------------------------------- SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer (HRB 36809, AG Nürnberg)
participants (3)
-
Michael Calmer -
Pau Garcia -
Stefan Bluhm