On 08/05/17 13:44, Sandro Bonazzola wrote: > > > On Fri, Mar 17, 2017 at 10:49 AM, Sandro Bonazzola <sbonazzo at redhat.com > <mailto:sbonazzo at redhat.com>> wrote: > > > > On Thu, Mar 16, 2017 at 6:17 PM, Fabian Arrotin <arrfab at centos.org > <mailto:arrfab at centos.org>> wrote: > > On 15/03/17 16:58, Karanbir Singh wrote: > > On 15/03/17 09:28, Fabian Arrotin wrote: > > > >> So my understanding is that the problem relies on the fact that there > >> isn't even a policy around Extras repository now. So it's up to the > >> people allowed to build/sign/push to know what they'll add in Extras, > >> and only in the arches they care about. > > > > https://wiki.centos.org/AdditionalResources/Repositories > <https://wiki.centos.org/AdditionalResources/Repositories> has a > > definition for the Extras repos. on C7 it should include what is > > upstream in the Extras/ repos ( provided we are able to build it ), and > > other things that are needed sometimes to build content in base / updates. > > > > In addition to this, Extras should contain all centos-release-* files > > from the SIG's. > > > > The only other content that should make it into Extras should be content > > vetted by the core sig, considered fundamental to user experience or > > tooling for user experience. ie. a fairly high barrier to entry. > > > > Does that give us enough policy wording for Extras ? Do we have > > exceptions we need to work through ? > > > > Sounds good. So with that definition in mind, how can we be sure > that > Extras is then built/distributed in parallel for all arches, so that > then it can be safely enabled within CBS ? > > -- > Fabian Arrotin > The CentOS Project | http://www.centos.org > gpg key: 56BEC54E | twitter: @arrfab > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org <mailto:CentOS-devel at centos.org> > https://lists.centos.org/mailman/listinfo/centos-devel > <https://lists.centos.org/mailman/listinfo/centos-devel> > > > > Adding here notes I sent in a different thread, for reference. > I'm facing some discrepancies in repositories structure for ppc64le. > > In x86_64 qemu-kvm-ev is shipped within > http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/ > <http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/> > which is the path I was expecting. Now, looking at ppc64le I see it > shipped within: > http://mirror.centos.org/altarch/7/extras/ppc64le/Packages/ > <http://mirror.centos.org/altarch/7/extras/ppc64le/Packages/> > and being extras enabled by default it overrides qemu-kvm shipped by > core os. > Can we at least replicate the same structure between > http://mirror.centos.org/centos/7 > <http://mirror.centos.org/centos/7> and http://mirror.centos.org/altarch/7 > <http://mirror.centos.org/altarch/7> ? > > > Any update? have you tried to reach out to the SIG's responsible for the content ? > > > > next, I see cockpit available for x86_64 in > http://mirror.centos.org/centos/7/extras/x86_64/Packages/ > <http://mirror.centos.org/centos/7/extras/x86_64/Packages/> > but it's missing in > http://mirror.centos.org/altarch/7/extras/ppc64le/Packages/ > <http://mirror.centos.org/altarch/7/extras/ppc64le/Packages/> > > I see cockpit in fedora > ppc64le: https://koji.fedoraproject.org/koji/buildinfo?buildID=869569 <https://koji.fedoraproject.org/koji/buildinfo?buildID=869569> > so it should be possible to get it on centos as well. > Can you please build it? > > > Any update? > we build parts of cockpit as a part of the atomic stack - since thats not on PPC, i think you might need to setup a suiteable target and maintain that yourself - the atomic stack isnt going to be able to do this. regards -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc