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 Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
