[CentOS-devel] CentOS 7 extras for alternative arches and Koji workflow.

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