Re: [Spacewalk-devel] Spacewalk 2.10 branched

[Michael Mraka]

Stefan Bluhm:
> Hello Michael,

Hello Stefan,

> any chance to get my two pull requests into it?
> 
> PR703 Is low risk (updating http to https in a SPEC file.)

No problem with that one. Merged.

> PR702 Changed backend/satellite_tools/reposync.py to also download the 
> .treeinfo file from a repo. The missing treeinfo file stops provisioning of 
> KVMs.
> Downside is, that the now added treeinfo file causes issues when provisioning 
> CentOS 8 as it includes the Appstream repo, which does not get synced down 
> with reposync.

What problem solves it? Is currently provisioning of all distributins
(Fedora, CentOS 6,7) or CentoOS 8 only broken?

> So eventually, there has to be a code change to automatically strip out 
> linked repositories and addition to the documentation to provide the stripped 
> out repositories as a channel during provisioning. Or auto-creation of the 
> treeinfo file. Apart from that, I would say that the above behaviour would be 
> as designed and should be expected in that way.
> 
> 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 2.10 branched

[Stefan Bluhm]

Hello Michael,

any chance to get my two pull requests into it?

PR703 Is low risk (updating http to https in a SPEC file.)

PR702 Changed backend/satellite_tools/reposync.py to also download the 
.treeinfo file from a repo. The missing treeinfo file stops provisioning of 
KVMs.
Downside is, that the now added treeinfo file causes issues when provisioning 
CentOS 8 as it includes the Appstream repo, which does not get synced down with 
reposync.

So eventually, there has to be a code change to automatically strip out linked 
repositories and addition to the documentation to provide the stripped out 
repositories as a channel during provisioning. Or auto-creation of the treeinfo 
file. Apart from that, I would say that the above behaviour would be as 
designed and should be expected in that way.

Best wishes,

Stefan

- Ursprüngliche Mail -
Von: "Michael Mraka" 
An: "spacewalk-devel" , "spacewalk-list" 

Gesendet: Donnerstag, 27. Februar 2020 16:21:33
Betreff: [Spacewalk-devel] Spacewalk 2.10 branched

Hello Spacewalkers,

We moved on and we are woking towards Spacewalk 2.10 release.
A new git branch SPACEWALK-2.10 has been created for it.
Now it's a release candidate and we are working on stabilization. You
can help with a testing/verification bugs in the nightly repo

https://copr.fedorainfracloud.org/coprs/g/spacewalkproject/nightly/
https://copr.fedorainfracloud.org/coprs/g/spacewalkproject/nightly-client/

and if we find and fix some blocker bugs, we will cherry-pick fixes into
Spacewalk 2.10.

Updated instruction how to install nightly version
https://github.com/spacewalkproject/spacewalk/wiki/HowToInstallNightly

Thanks,

--
Michael Mráka
System Management Engineering, Red Hat

___
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