On Thu, Mar 12, 2020 at 7:45 AM Stefan Bluhm <redhat....@bluhm-de.com> wrote:
> Thank you Neal and Michael,
> > Stefan: Unfortunately, spacewalk-setup fails due to a postgresql 
> > configuration error (unrecognized configuration parameter 
> > "checkpoint_segments"), otherwise this would have been an additional great 
> > achievement.
> Building and dnf install is successful but actually executing the spacewalk 
> installation "# spacewalk-setup" is doing some things and eventually failing 
> on the above message. Might have something to do with the expected 
> configuration file of postgresql or so. I haven't looked at it yet.
> > Michael: What are these packages? Fedora packages simply rebuilt for RHEL8? 
> > Or are there any tweaks in their spec? > Clean rebuilds can go to 
> > python-packages / java-packages, packages with changed specs we keep in git 
> > and build them into nightly.
> Different things. I mainly took Fedora 31 packages for dependencies of 
> dependencies of dependencies... and they mostly compiled OK. I had to change 
> quite some spec files to fix versioned Python issues or even add Python 2 
> back again. Other low number of sources were older Fedora versions, EPEL7 and 
> maybe one or two custom packages(rebuilds in newer versions). I was not able 
> to build some rpms so took the binary from F30 to continue. I will revisit 
> them to get them off my HDD.

Stuff that adds Python 2 back will likely be a problem. They've been
gutted in Fedora on purpose.

> So I think I will do this:
> 1. Add java packages to copr/java-packages. How would we go about that?
> 2. Add selected Python packages to copr/python.
> 3. Keep Python2 specific packages on my repository for time being. I guess 
> you could integrate mine to the spacewalk repo so that the server builds 
> successfully for time being.
> 4. Useful modified SPEC files will be pushed to git eventually (I have to 
> find them all back, probably a manual task...)
> 5. There are a few non-java/python packages. I would probably follow the git 
> approach
> > Michael: Server side can be moved to python3 without problem. For RHEL 6 
> > and 7 (and clones like CentOS, OL, etc.) clients we still need python2.
> I will not be touching the clients. I will leave that up to somebody else :) 
> My CentOS 7 and 8 servers all work for me.
> > Neal: It'd be good to get this back into Fedora. Get in touch on the Fedora 
> > development mailing list to help integrate this packages back in the 
> > distribution. They could also be built into EPEL 7/8 for reusability too.
> Most packages are from Fedora 31. So I guess they would somehow have to come 
> over to EPEL8. This would be a new area of work for me...
> The modified ones are me adding Python2 back again :)  I agree, all my work 
> (if useful) should be pushed upstream. I guess, this would have to be 
> evaluated on a case by case basis after we got Python 2 out of Spacewalk. 
> Maybe it even makes more sense to update Spacewalk to newer versions.
> Let's see what happens when I/we get round to it. Thank you for your support.

Obviously the Python 2 stuff can't go back in, and unlikely for EPEL 8
too. The other stuff seems fine.

> @Michael, once I get the server to actually install, is there any chance you 
> could then try it out and test the functions to estimate the effort? I 
> remember (Hopefully correctly) you mentioning that you have a test 
> environment (that is fully automated and tests all Spacewalk functions with a 
> click of a button). Otherwise this would be an interesting effort to do those 
> required code changes with new versions etc.

This would be cool for anyone to be able to do, actually... Any chance
that could be made public?

真実はいつも一つ!/ Always, there's only one truth!

Spacewalk-devel mailing list

Reply via email to