[CentOS-devel] CentOS 7 extras for alternative arches and Koji workflow.
Karanbir Singh
mail-lists at karan.org
Wed May 17 22:49:23 UTC 2017
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
More information about the CentOS-devel
mailing list