Re: [Spacewalk-devel] Spacewalk on RHEL8 - Step 1 (of many) completed
Dne 11. 03. 20 v 13:32 Neal Gompa napsal(a): > 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. I maintained some of those packages in Fedora. I orphaned them some time ago. I guess some of them will be still owned by orphan. Then you just grab it. But some of the are already retired, and you must go through: https://fedoraproject.org/wiki/Package_Review_Process -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk on RHEL8 - Step 1 (of many) completed
Stefan, they're part of the project. I'd say git will be locked/archived and website shutdown. No specific plan yet, but I wouldn't expect anything with name Spacewalk would stay available after May 2020. Tomas On Mon, Mar 16, 2020 at 5:11 PM Stefan Bluhm wrote: > > Thank you Tomas, > > can you already say what will happen to the git repository and the website? > Will they be shut down or just kept running idle? > > Best wishes, > > Stefan > > > - Ursprüngliche Mail - > Von: "Tomas Lestach" > An: "Stefan Bluhm" > CC: "spacewalk-devel" > Gesendet: Montag, 16. März 2020 17:06:55 > Betreff: Re: [Spacewalk-devel] Spacewalk on RHEL8 - Step 1 (of many) completed > > On Fri, Mar 13, 2020 at 12:57 PM Stefan Bluhm wrote: > > > > Hello Tomas, > > > > > Hey Stefan, Neal, Avi, > > > please keep in mind Spacewalk 2.10 is the last Spacewalk release planned > > > by Red Hat with a release date within a month. No further contributions > > > to Spacewalk are to be expected from Red Hat after May 2020. > > > > This is what I was already assuming (not even expecting 2.10). That is the > > reason for my own efforts to somehow keep the project alive. > > > > What will happen to the project (Github, COPR, spacewalkproject.org) after > > 2.10? Will it be closed or transferred fully to the community? I see it a > > bit difficult to further develop the project if the community is then > > locked out. Starting off a new fork from scratch for Spacewalk 3 (=RH drop > > out, RHEL8, Python 3) and therefore setting up a new community would > > certainly cost an unwanted toll. > > > > Can I volunteer to join the project board? > > > > Best wishes, > > > > Stefan > > > Hello Stefan, > > Spacewalk project will be discontinued. This won't change. > There are other Spacewalk forks of great quality out there. I > encourage to check them and pick the one that matches your needs at > most and start using it (eventually contributing) - if you want to > stay with Spacewalk codebase and technology. > As you mentioned there's still an option to make your own fork > (according to https://spacewalkproject.github.io/trademarkinfo.html). > I believe facts like having the source code in github (thanks to Suse > :-) ), having migrated the build system from an internal Koji instance > to public COPR (thanks to Michael :-) ) make it pretty > straightforward. However I'm not encouraging anyone directly to do so > as it may be much more work than expected. :-) > > Regards, > Tomas > ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk on RHEL8 - Step 1 (of many) completed
Thank you Tomas, can you already say what will happen to the git repository and the website? Will they be shut down or just kept running idle? Best wishes, Stefan - Ursprüngliche Mail - Von: "Tomas Lestach" An: "Stefan Bluhm" CC: "spacewalk-devel" Gesendet: Montag, 16. März 2020 17:06:55 Betreff: Re: [Spacewalk-devel] Spacewalk on RHEL8 - Step 1 (of many) completed On Fri, Mar 13, 2020 at 12:57 PM Stefan Bluhm wrote: > > Hello Tomas, > > > Hey Stefan, Neal, Avi, > > please keep in mind Spacewalk 2.10 is the last Spacewalk release planned by > > Red Hat with a release date within a month. No further contributions to > > Spacewalk are to be expected from Red Hat after May 2020. > > This is what I was already assuming (not even expecting 2.10). That is the > reason for my own efforts to somehow keep the project alive. > > What will happen to the project (Github, COPR, spacewalkproject.org) after > 2.10? Will it be closed or transferred fully to the community? I see it a bit > difficult to further develop the project if the community is then locked out. > Starting off a new fork from scratch for Spacewalk 3 (=RH drop out, RHEL8, > Python 3) and therefore setting up a new community would certainly cost an > unwanted toll. > > Can I volunteer to join the project board? > > Best wishes, > > Stefan Hello Stefan, Spacewalk project will be discontinued. This won't change. There are other Spacewalk forks of great quality out there. I encourage to check them and pick the one that matches your needs at most and start using it (eventually contributing) - if you want to stay with Spacewalk codebase and technology. As you mentioned there's still an option to make your own fork (according to https://spacewalkproject.github.io/trademarkinfo.html). I believe facts like having the source code in github (thanks to Suse :-) ), having migrated the build system from an internal Koji instance to public COPR (thanks to Michael :-) ) make it pretty straightforward. However I'm not encouraging anyone directly to do so as it may be much more work than expected. :-) Regards, Tomas ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk on RHEL8 - Step 1 (of many) completed
On Fri, Mar 13, 2020 at 12:57 PM Stefan Bluhm wrote: > > Hello Tomas, > > > Hey Stefan, Neal, Avi, > > please keep in mind Spacewalk 2.10 is the last Spacewalk release planned by > > Red Hat with a release date within a month. No further contributions to > > Spacewalk are to be expected from Red Hat after May 2020. > > This is what I was already assuming (not even expecting 2.10). That is the > reason for my own efforts to somehow keep the project alive. > > What will happen to the project (Github, COPR, spacewalkproject.org) after > 2.10? Will it be closed or transferred fully to the community? I see it a bit > difficult to further develop the project if the community is then locked out. > Starting off a new fork from scratch for Spacewalk 3 (=RH drop out, RHEL8, > Python 3) and therefore setting up a new community would certainly cost an > unwanted toll. > > Can I volunteer to join the project board? > > Best wishes, > > Stefan Hello Stefan, Spacewalk project will be discontinued. This won't change. There are other Spacewalk forks of great quality out there. I encourage to check them and pick the one that matches your needs at most and start using it (eventually contributing) - if you want to stay with Spacewalk codebase and technology. As you mentioned there's still an option to make your own fork (according to https://spacewalkproject.github.io/trademarkinfo.html). I believe facts like having the source code in github (thanks to Suse :-) ), having migrated the build system from an internal Koji instance to public COPR (thanks to Michael :-) ) make it pretty straightforward. However I'm not encouraging anyone directly to do so as it may be much more work than expected. :-) Regards, Tomas ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk on RHEL8 - Step 1 (of many) completed
On dv, 2020-03-13 at 12:04 +, francisco.card...@gmail.com wrote: > I think the main issue with all this is going to be the brutal > fragmentation that’s going to be going forward. > Oracle has his own twisted fork of spacewalk that isn’t even a fork > by itself. > SUSE has SUSE Manager and Uyuni which are both based on the vanilla > Spacewalk project but at least they are giving something back. Actually, we SUSE are giving it all: the Uyuni codebase (and even docs base) is identical to SUSE Manager. The only difference is support. As a contributor to Uyuni, SUSE will focus on openSUSE/SUSE Linux Enterprise on the server side, and on the most popular distributions on the client side (e. g. Uyuni includes crazy clients stuff such as Springdale Linux -Princeton's clone of RHEL-, Astra Linux -Russian Debian-derivative-, etc; SUSE Manager also includes that -because the codebase is the same as Uyuni, we don't add or remove- but there is no support from SUSE, it's only community-supported) I said this when I presented Uyuni at CentOS Dojo in Brussels 6 weeks ago and I will repeat it again: we are open to run Uyuni Server and Proxy on other platforms (e. g. CentOS or Debian) if anyone is willing to contribute and maintain it. https://wiki.centos.org/Events/Dojo/Brussels2020 Same for governance: I would love to open it. Thank you Pau Garcia Quiles Product Owner & Technical Project Manager, SUSE Manager SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk on RHEL8 - Step 1 (of many) completed
Hi, > On 13 Mar 2020, at 11:04 pm, francisco.card...@gmail.com wrote: > > Oracle has his own twisted fork of spacewalk that isn’t even a fork by itself. I'm not sure why you believe our build of Spacewalk is twisted, but with the exception of a few logo changes, it's pretty much the upstream code. We specifically didn't fork or change anything downstream to make it simple for customers to migrate to (and away) from our release of Spacewalk. Thanks, Avi -- Avi Miller Senior Manager Oracle Linux and Virtualization Product Management Phone: +61.3.8616.3496 Preferred pronouns: he/him/his signature.asc Description: Message signed with OpenPGP ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk on RHEL8 - Step 1 (of many) completed
On Fri, Mar 13, 2020 at 7:58 AM Stefan Bluhm wrote: > > Hello Tomas, > > > Hey Stefan, Neal, Avi, > > please keep in mind Spacewalk 2.10 is the last Spacewalk release planned by > > Red Hat with a release date within a month. No further contributions to > > Spacewalk are to be expected from Red Hat after May 2020. > > This is what I was already assuming (not even expecting 2.10). That is the > reason for my own efforts to somehow keep the project alive. > > What will happen to the project (Github, COPR, spacewalkproject.org) after > 2.10? Will it be closed or transferred fully to the community? I see it a bit > difficult to further develop the project if the community is then locked out. > Starting off a new fork from scratch for Spacewalk 3 (=RH drop out, RHEL8, > Python 3) and therefore setting up a new community would certainly cost an > unwanted toll. > > Can I volunteer to join the project board? > I would certainly like to see something along these lines and invite major contributors to Spacewalk to form community governance. Along with that, I'd also like to see the mailing lists transfer from redhat.com to lists.fedorahosted.org, as the mailing list experience is better there and demonstrates the clear community nature of the project. This is similar to what has happened for other community projects in the past where multiple stakeholders exist now, and even cobbler's mailing list is on lists.fedorahosted.org. Alternatively, it could spin out into its own domain like oVirt and RDO's mailing lists have. -- 真実はいつも一つ！/ Always, there's only one truth! ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk on RHEL8 - Step 1 (of many) completed
I think the main issue with all this is going to be the brutal fragmentation that’s going to be going forward. Oracle has his own twisted fork of spacewalk that isn’t even a fork by itself. SUSE has SUSE Manager and Uyuni which are both based on the vanilla Spacewalk project but at least they are giving something back. The issue going forward is that the main development branch is going to get severed and truth be told the only feasible options are either: Full Community Support. Vendor Based Support, with one of the other vendors (Which truth be told I'd not like and neither would most of us. Anyways the future goes I'd volunteer aswell. Regards, And these days guys be safe FC -Original Message- From: spacewalk-devel-boun...@redhat.com On Behalf Of Stefan Bluhm Sent: 13 March 2020 11:57 To: spacewalk-devel Subject: Re: [Spacewalk-devel] Spacewalk on RHEL8 - Step 1 (of many) completed Hello Tomas, > Hey Stefan, Neal, Avi, > please keep in mind Spacewalk 2.10 is the last Spacewalk release planned by > Red Hat with a release date within a month. No further contributions to > Spacewalk are to be expected from Red Hat after May 2020. This is what I was already assuming (not even expecting 2.10). That is the reason for my own efforts to somehow keep the project alive. What will happen to the project (Github, COPR, spacewalkproject.org) after 2.10? Will it be closed or transferred fully to the community? I see it a bit difficult to further develop the project if the community is then locked out. Starting off a new fork from scratch for Spacewalk 3 (=RH drop out, RHEL8, Python 3) and therefore setting up a new community would certainly cost an unwanted toll. Can I volunteer to join the project board? Best wishes, Stefan ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk on RHEL8 - Step 1 (of many) completed
Hello Tomas, > Hey Stefan, Neal, Avi, > please keep in mind Spacewalk 2.10 is the last Spacewalk release planned by > Red Hat with a release date within a month. No further contributions to > Spacewalk are to be expected from Red Hat after May 2020. This is what I was already assuming (not even expecting 2.10). That is the reason for my own efforts to somehow keep the project alive. What will happen to the project (Github, COPR, spacewalkproject.org) after 2.10? Will it be closed or transferred fully to the community? I see it a bit difficult to further develop the project if the community is then locked out. Starting off a new fork from scratch for Spacewalk 3 (=RH drop out, RHEL8, Python 3) and therefore setting up a new community would certainly cost an unwanted toll. Can I volunteer to join the project board? Best wishes, Stefan ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk on RHEL8 - Step 1 (of many) completed
Hey Tomas, > On 13 Mar 2020, at 12:34 am, Tomas Lestach wrote: > > > please keep in mind Spacewalk 2.10 is the last Spacewalk release planned > by Red Hat with a release date within a month. No further contributions > to Spacewalk are to be expected from Red Hat after May 2020. Thanks for the confirmation. Cheers, Avi -- Avi Miller Senior Manager Oracle Linux and Virtualization Product Management Phone: +61.3.8616.3496 Preferred pronouns: he/him/his signature.asc Description: Message signed with OpenPGP ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk on RHEL8 - Step 1 (of many) completed
On Thu, Mar 12, 2020 at 12:10 PM Neal Gompa wrote:
>
> On Thu, Mar 12, 2020 at 7:00 AM Michael Mraka
> wrote:
> >
> > Stefan Bluhm:
> > > Hello all,
> > >
> > > TLDR: Spacewalk packages build and can be installed on CentOS 8.
> > >
> > > as I am working on getting Spacewalk to run on CentOS8/RHEL8, I would
> > > like to share my progress here with you, in the hopes that you can
> > > contribute or share your experience/knowledge. I am not company
> > > sponsored, not a developer nor do I have much other knowledge of Linux.
> > >
> > > Around three weeks ago, I forked the GIT repo and the COPR repositories.
> > > So that is the basis of my current work:
> > > https://github.com/sbluhm/spacewalk
> > > https://copr.fedorainfracloud.org/coprs/sbluhm/nightly/ #
> > > Contains the packages from the original spacewalk nightly
> > > https://copr.fedorainfracloud.org/coprs/sbluhm/java-packages/ #
> > > Contains 421 Java related and other random packages
> > > https://copr.fedorainfracloud.org/coprs/sbluhm/python-packages/ #
> > > Contains 115 Python, Perl and other random packages
> > > http://dev2.bluhm-de.com/packages #
> > > Custom repo for locally compiled or added packages that I was not yet
> > > able to build.
> > >
> > > Primary objective was to hack everything together to get everything to
> > > build.
> > >
> > > I have added and built all required dependencies (mainly Python 2 and
> > > Java) and modified the RPM spec files so that it is possible to
> > > successfully build all Spacewalk packages. It is also possible to install
> > > all Spacewalk packages apart from spacewalk-proxy* and spacewalk-oracle*
> > > which I have no idea (or currently care) how to set up.
> >
> > Hello Stefan,
> >
> > That sounds like a huge amount of great work.
> >
> > > Unfortunately, spacewalk-setup fails due to a postgresql configuration
> > > error (unrecognized configuration parameter "checkpoint_segments"),
> > > otherwise this would have been an additional great achievement.
> >
> > See commit fe265a597de3f043c22bf7910d2119e9c9b967cd.
> > IMHO you just need to change condition in spec to
> > %if 0%{?fedora} || 0%{?rhel} >= 8
> >
> > > Next few steps I see (in no real particular order):
> > > - Clean up and verify the git changes and push them to the Spacewalk
> > > master. Michael, you will see quite a few SHORT pull requests coming from
> > > me in the future. It would be great, if you could sanity check them (as
> > > mentioned above, I am not a developer nor do I know what I am doing).
> >
> > I'll take a look.
> >
> > > - Fix the compile issues from my local repository and add them to the
> > > COPR repos.
> > > - Clean up the repos. I probably have more packages built than required.
> > > Including already existing RHEL8 packages and/or module conflicts.
> > > - Start moving code to Python 3 to get rid of the many custom built
> > > Python 2 packages.
> > >
> > > Open questions from my side:
> > > - What do I do with those build packages in my repos? How/where do I add
> > > them to hand my work over? Please give some assistance where to put what
> > > (git, nightly, python-packages, java-packages) and how.
> >
> > 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.
> >
> > > - Is there a reason to keep Python 2 or can everything be moved to Python
> > > 3?
> >
> > 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.
> >
> > > - What are the supported OS? I would say RHEL>=7 (remove 6 code), Fedora
> > > >= 29 (28 is EOL in May and I doubt we will be ready for a release by
> > > then). What about SLES? I have seen SLES specific code in there.
> >
> > So far RHEL6+ and Fedora 30+ (29 has been EOLed and removed from COPR).
> > For Spacewalk 2.9 we had also had SLES and Debian clients built but I
> > don't know the current status.
> >
>
> By the time Spacewalk 2.11 is ready for release (or even Spacewalk
> 2.10 for that matter!), RHEL 6 will be EOL (EOL is in November!), so I
> think it's fine to move up the bar to EL7 and higher.
Hey Stefan, Neal, Avi,
please keep in mind Spacewalk 2.10 is the last Spacewalk release planned
by Red Hat with a release date within a month. No further contributions
to Spacewalk are to be expected from Red Hat after May 2020.
Regards,
--
Tomas Lestach
Red Hat Satellite 5 Engineering
>
> As for SUSE and Debian clients, those are actively maintained and
> functional. Both clients are already Python 3 ready, and can be built
> for Python 3 provided their host distros have all the necessary
> dependencies.
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>
>
> ___
>
Re: [Spacewalk-devel] Spacewalk on RHEL8 - Step 1 (of many) completed
Hi Neal, yes, that is what I was trying to say. I won't push Python 2 anywhere :) > This would be cool for anyone to be able to do, actually... Any chance that > could be made public? Do you mean my work? Then it is. I posted it in my first e-mail. If you mean the test environment, then I was teasing Michael a bit. I doubt he has a fully automated test environment. Would be great it it were true though :) Best wishes, Stefan - Ursprüngliche Mail - Von: "Neal Gompa" An: "spacewalk-devel" Gesendet: Donnerstag, 12. März 2020 13:42:43 Betreff: Re: [Spacewalk-devel] Spacewalk on RHEL8 - Step 1 (of many) completed On Thu, Mar 12, 2020 at 7:45 AM Stefan Bluhm 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 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk on RHEL8 - Step 1 (of many) completed
On Thu, Mar 12, 2020 at 7:45 AM Stefan Bluhm 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
Re: [Spacewalk-devel] Spacewalk on RHEL8 - Step 1 (of many) completed
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. 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. @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. Best wishes, Stefan ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk on RHEL8 - Step 1 (of many) completed
Hey folks, > On 12 Mar 2020, at 10:08 pm, Neal Gompa wrote: > >> >> That sounds like a huge amount of great work. Agreed. Fantastic work. > By the time Spacewalk 2.11 is ready for release (or even Spacewalk > 2.10 for that matter!), RHEL 6 will be EOL (EOL is in November!), so I > think it's fine to move up the bar to EL7 and higher. I agree with this too: from an Oracle Linux perspective, we're probably going to just stick with the 2.7 or 2.9 client when we ship the 2.10 server because we hit end of production phase for OL6 in March 2021. Thus, there is no real need for a newer 2.10 client for the older release. Getting the EL7 and higher clients updated for Python 3 is fine, as RHEL7 (and its clones) all have Python 3.6 at least. Just my 0.02c. Cheers, Avi -- Avi Miller Senior Manager Oracle Linux and Virtualization Product Management Phone: +61.3.8616.3496 Preferred pronouns: he/him/his signature.asc Description: Message signed with OpenPGP ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk on RHEL8 - Step 1 (of many) completed
On Thu, Mar 12, 2020 at 7:00 AM Michael Mraka wrote:
>
> Stefan Bluhm:
> > Hello all,
> >
> > TLDR: Spacewalk packages build and can be installed on CentOS 8.
> >
> > as I am working on getting Spacewalk to run on CentOS8/RHEL8, I would like
> > to share my progress here with you, in the hopes that you can contribute or
> > share your experience/knowledge. I am not company sponsored, not a
> > developer nor do I have much other knowledge of Linux.
> >
> > Around three weeks ago, I forked the GIT repo and the COPR repositories. So
> > that is the basis of my current work:
> > https://github.com/sbluhm/spacewalk
> > https://copr.fedorainfracloud.org/coprs/sbluhm/nightly/ #
> > Contains the packages from the original spacewalk nightly
> > https://copr.fedorainfracloud.org/coprs/sbluhm/java-packages/ #
> > Contains 421 Java related and other random packages
> > https://copr.fedorainfracloud.org/coprs/sbluhm/python-packages/ #
> > Contains 115 Python, Perl and other random packages
> > http://dev2.bluhm-de.com/packages # Custom
> > repo for locally compiled or added packages that I was not yet able to
> > build.
> >
> > Primary objective was to hack everything together to get everything to
> > build.
> >
> > I have added and built all required dependencies (mainly Python 2 and Java)
> > and modified the RPM spec files so that it is possible to successfully
> > build all Spacewalk packages. It is also possible to install all Spacewalk
> > packages apart from spacewalk-proxy* and spacewalk-oracle* which I have no
> > idea (or currently care) how to set up.
>
> Hello Stefan,
>
> That sounds like a huge amount of great work.
>
> > Unfortunately, spacewalk-setup fails due to a postgresql configuration
> > error (unrecognized configuration parameter "checkpoint_segments"),
> > otherwise this would have been an additional great achievement.
>
> See commit fe265a597de3f043c22bf7910d2119e9c9b967cd.
> IMHO you just need to change condition in spec to
> %if 0%{?fedora} || 0%{?rhel} >= 8
>
> > Next few steps I see (in no real particular order):
> > - Clean up and verify the git changes and push them to the Spacewalk
> > master. Michael, you will see quite a few SHORT pull requests coming from
> > me in the future. It would be great, if you could sanity check them (as
> > mentioned above, I am not a developer nor do I know what I am doing).
>
> I'll take a look.
>
> > - Fix the compile issues from my local repository and add them to the COPR
> > repos.
> > - Clean up the repos. I probably have more packages built than required.
> > Including already existing RHEL8 packages and/or module conflicts.
> > - Start moving code to Python 3 to get rid of the many custom built Python
> > 2 packages.
> >
> > Open questions from my side:
> > - What do I do with those build packages in my repos? How/where do I add
> > them to hand my work over? Please give some assistance where to put what
> > (git, nightly, python-packages, java-packages) and how.
>
> 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.
>
> > - Is there a reason to keep Python 2 or can everything be moved to Python 3?
>
> 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.
>
> > - What are the supported OS? I would say RHEL>=7 (remove 6 code), Fedora >=
> > 29 (28 is EOL in May and I doubt we will be ready for a release by then).
> > What about SLES? I have seen SLES specific code in there.
>
> So far RHEL6+ and Fedora 30+ (29 has been EOLed and removed from COPR).
> For Spacewalk 2.9 we had also had SLES and Debian clients built but I
> don't know the current status.
>
By the time Spacewalk 2.11 is ready for release (or even Spacewalk
2.10 for that matter!), RHEL 6 will be EOL (EOL is in November!), so I
think it's fine to move up the bar to EL7 and higher.
As for SUSE and Debian clients, those are actively maintained and
functional. Both clients are already Python 3 ready, and can be built
for Python 3 provided their host distros have all the necessary
dependencies.
--
真実はいつも一つ！/ Always, there's only one truth!
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk on RHEL8 - Step 1 (of many) completed
Stefan Bluhm:
> Hello all,
>
> TLDR: Spacewalk packages build and can be installed on CentOS 8.
>
> as I am working on getting Spacewalk to run on CentOS8/RHEL8, I would like to
> share my progress here with you, in the hopes that you can contribute or
> share your experience/knowledge. I am not company sponsored, not a developer
> nor do I have much other knowledge of Linux.
>
> Around three weeks ago, I forked the GIT repo and the COPR repositories. So
> that is the basis of my current work:
> https://github.com/sbluhm/spacewalk
> https://copr.fedorainfracloud.org/coprs/sbluhm/nightly/ # Contains
> the packages from the original spacewalk nightly
> https://copr.fedorainfracloud.org/coprs/sbluhm/java-packages/ # Contains
> 421 Java related and other random packages
> https://copr.fedorainfracloud.org/coprs/sbluhm/python-packages/ # Contains
> 115 Python, Perl and other random packages
> http://dev2.bluhm-de.com/packages # Custom
> repo for locally compiled or added packages that I was not yet able to build.
>
> Primary objective was to hack everything together to get everything to build.
>
> I have added and built all required dependencies (mainly Python 2 and Java)
> and modified the RPM spec files so that it is possible to successfully build
> all Spacewalk packages. It is also possible to install all Spacewalk packages
> apart from spacewalk-proxy* and spacewalk-oracle* which I have no idea (or
> currently care) how to set up.
Hello Stefan,
That sounds like a huge amount of great work.
> Unfortunately, spacewalk-setup fails due to a postgresql configuration error
> (unrecognized configuration parameter "checkpoint_segments"), otherwise this
> would have been an additional great achievement.
See commit fe265a597de3f043c22bf7910d2119e9c9b967cd.
IMHO you just need to change condition in spec to
%if 0%{?fedora} || 0%{?rhel} >= 8
> Next few steps I see (in no real particular order):
> - Clean up and verify the git changes and push them to the Spacewalk master.
> Michael, you will see quite a few SHORT pull requests coming from me in the
> future. It would be great, if you could sanity check them (as mentioned
> above, I am not a developer nor do I know what I am doing).
I'll take a look.
> - Fix the compile issues from my local repository and add them to the COPR
> repos.
> - Clean up the repos. I probably have more packages built than required.
> Including already existing RHEL8 packages and/or module conflicts.
> - Start moving code to Python 3 to get rid of the many custom built Python 2
> packages.
>
> Open questions from my side:
> - What do I do with those build packages in my repos? How/where do I add them
> to hand my work over? Please give some assistance where to put what (git,
> nightly, python-packages, java-packages) and how.
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.
> - Is there a reason to keep Python 2 or can everything be moved to Python 3?
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.
> - What are the supported OS? I would say RHEL>=7 (remove 6 code), Fedora >=
> 29 (28 is EOL in May and I doubt we will be ready for a release by then).
> What about SLES? I have seen SLES specific code in there.
So far RHEL6+ and Fedora 30+ (29 has been EOLed and removed from COPR).
For Spacewalk 2.9 we had also had SLES and Debian clients built but I
don't know the current status.
> - Probably create a wiki page/edit for instructions how to install the
> nightly on RHEL8
>
> Do you see the next steps in the same way? Do you have any other suggestions,
> recommendations, guidelines?
> How can you assist?
>
> I will shift my focus for time being to a different project (evdi) to get my
> second screen working again. Then I will probably be back here.
>
> Best wishes,
>
> Stefan
Regards,
--
Michael Mráka
System Management Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk on RHEL8 - Step 1 (of many) completed
On Wed, Mar 11, 2020 at 8:23 AM Stefan Bluhm wrote: > > Hello all, > > TLDR: Spacewalk packages build and can be installed on CentOS 8. > > as I am working on getting Spacewalk to run on CentOS8/RHEL8, I would like to > share my progress here with you, in the hopes that you can contribute or > share your experience/knowledge. I am not company sponsored, not a developer > nor do I have much other knowledge of Linux. > > Around three weeks ago, I forked the GIT repo and the COPR repositories. So > that is the basis of my current work: > https://github.com/sbluhm/spacewalk > https://copr.fedorainfracloud.org/coprs/sbluhm/nightly/ # Contains > the packages from the original spacewalk nightly > https://copr.fedorainfracloud.org/coprs/sbluhm/java-packages/ # Contains > 421 Java related and other random packages > https://copr.fedorainfracloud.org/coprs/sbluhm/python-packages/ # Contains > 115 Python, Perl and other random packages > http://dev2.bluhm-de.com/packages # Custom > repo for locally compiled or added packages that I was not yet able to build. > > Primary objective was to hack everything together to get everything to build. > > I have added and built all required dependencies (mainly Python 2 and Java) > and modified the RPM spec files so that it is possible to successfully build > all Spacewalk packages. It is also possible to install all Spacewalk packages > apart from spacewalk-proxy* and spacewalk-oracle* which I have no idea (or > currently care) how to set up. > > Unfortunately, spacewalk-setup fails due to a postgresql configuration error > (unrecognized configuration parameter "checkpoint_segments"), otherwise this > would have been an additional great achievement. > This is amazing progress! Congratulations! > Next few steps I see (in no real particular order): > - Clean up and verify the git changes and push them to the Spacewalk master. > Michael, you will see quite a few SHORT pull requests coming from me in the > future. It would be great, if you could sanity check them (as mentioned > above, I am not a developer nor do I know what I am doing). > - Fix the compile issues from my local repository and add them to the COPR > repos. > - Clean up the repos. I probably have more packages built than required. > Including already existing RHEL8 packages and/or module conflicts. > - Start moving code to Python 3 to get rid of the many custom built Python 2 > packages. > > Open questions from my side: > - What do I do with those build packages in my repos? How/where do I add them > to hand my work over? Please give some assistance where to put what (git, > nightly, python-packages, java-packages) and how. 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. > - Is there a reason to keep Python 2 or can everything be moved to Python 3? Everything should move to Python 3, since Python 2 is now EOL and RHEL 7 has a Python 3 interpreter (and EPEL provides a lot of Python 3 packages). Any missing Python 3 packages can be backfilled into EPEL. > - What are the supported OS? I would say RHEL>=7 (remove 6 code), Fedora >= > 29 (28 is EOL in May and I doubt we will be ready for a release by then). > What about SLES? I have seen SLES specific code in there. I would say the server should be able to run on RHEL 7 (CentOS 7) or greater and SLE 15 (openSUSE Leap 15) or greater. That means you can rely on DNF being available and port over all the YUM code to get rid of the YUM dependency. > Do you see the next steps in the same way? Do you have any other suggestions, > recommendations, guidelines? I pretty much agree with your approach. Suggestions made above about how to handle this more sustainably. > How can you assist? I can certainly try to help where I can with package reviews on the Fedora side and reviewing/testing code changes. Not sure how much code work I can commit to at the moment, though. -- 真実はいつも一つ！/ Always, there's only one truth! ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
