> Koji is very opinionated about how RPMs and specfiles should look, > AFAIK
Actually, koji does not care much. Fedora packaging rules are enforced by package reviewers. > More specifically, Koji usually assumes the starting point for the > build process would be a specfile This is correct though. > Does fedora have an s390x server associated to it? They used to have s390 emulators running for that purpose iirc. Best regards Martin Sivak On Thu, Nov 16, 2017 at 6:27 PM, Barak Korren <[email protected]> wrote: > On 16 November 2017 at 18:52, Viktor Mihajlovski > <[email protected]> wrote: >> >> Short update, with yesterday's API model 4.2.25 release, there's basic >> support for s390 available in ovirt-engine. At this point in time, there >> are no ovirt yum repositories for the s390x architecture - not sure what >> the process would be to add s390x repositories and how to build the >> binary RPMs at least for the host packages (i.e. vdsm-*). Maybe it would >> possible to use the s390-koji infrastructure used to build Fedora for s390x? > > Koji is very opinionated about how RPMs and specfiles should look, > AFAIK A pretty massive amount of work would be needed to make > everything that is needed for a node to build on it, and then we would > end up with a process that is quite different with how we currently do > builds for other platforms. > > (I might be wrong about this, since some oVirt packages get also built > as part of the CentOS virt SIG, and that is done using Koji as well) > > More specifically, Koji usually assumes the starting point for the > build process would be a specfile, while in oVirt we typically > generated the specfile and then the RPM as part of a bigger build > process. > > Does fedora have an s390x server associated to it? > We do use the same basic environment setup tool - mock - as the basis > of our build infrastructure, so if Fedora is actually emulating s390x > is some way while using mock, we might be able to do the same thing. > > Just for general knowledge, the process for building oVirt repos, is > to have *-build-artifacts-* jobs for each project that build RPM's > after patches get merged, and then have the change-queue to collect > the built packages, rung them through ovirt-system-tests (a.k.a. OST) > and finally deposit them into the 'tested' rpoe, from which they are > copied nightly to the '*-snapshot' repos. > > OST only tests for CentOS 7/x86_64 ATM, but we bring along packages > for other distros and architectures via the same process while > assuming that if a package for a given commit works for CentOS > 7/x86_64 it would probably work for other platforms as well... > > -- > Barak Korren > RHV DevOps team , RHCE, RHCi > Red Hat EMEA > redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted > _______________________________________________ > Devel mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/devel _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
