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 <mc@suse.de> Sent: Wednesday, February 3, 2021 10:34 AM To: devel@lists.uyuni-project.org <devel@lists.uyuni-project.org> Subject: Re: Merging custom CentOS packages to Master 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) Von: "Pau Garcia Quiles" <pau.garcia@suse.com> An: "Michael Calmer" <mc@suse.de>, "devel" <devel@lists.uyuni-project.org> Gesendet: Mittwoch, 3. Februar 2021 11:41:04 Betreff: Re: Merging custom CentOS packages to Master From: Michael Calmer <mc@suse.de> Sent: Wednesday, February 3, 2021 10:34 AM To: devel@lists.uyuni-project.org <devel@lists.uyuni-project.org> Subject: Re: Merging custom CentOS packages to Master 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)