> Hi, > > On 2/26/19 11:26 AM, Frediano Ziglio wrote: > >> --- > >> .gitlab-ci.yml | 1 - > >> 1 file changed, 1 deletion(-) > >> > >> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml > >> index ab1b2a3..57d3dd9 100644 > >> --- a/.gitlab-ci.yml > >> +++ b/.gitlab-ci.yml > >> @@ -3,7 +3,6 @@ image: fedora:latest > >> before_script: > >> - > > >> dnf install -y 'dnf-command(copr)' make automake autoconf > >> autoconf-archive libtool xz gcc-c++ > >> - libdrm-devel libXrandr-devel > >> - dnf copr enable @spice/nightly -y > >> - dnf builddep spice-streaming-agent -y > >> > > Considering patch 3/3 also gcc-c++ should be removed. > > > Well, this will be true if patch 1/3 is in too, since currently the > builds are created > from another spec file (which I'll update manually so it will work) > In this case it's really twisted! 1- Gitlab uses dnf builddep from spice-streaming-agent nigthly; 2- dnf builddep from spice-streaming-agent nigthly uses the SPEC inside spice-streaming-agent @copr; 3- spice-streaming-agent is generated by copr from SRPM; 4- SRPM is generated from Gitlab from SPEC + TARBALL; 5- this last SPEC is generated from Gitlab using dependencies from SPEC.IN. So why at step 1 not using the same dependencies at step 5? Conceptually the CI should try to use step similar to what an user or developer does. I honestly never used @copr to build spice. > > > Also looks like the tendency is to remove the dependency from > > @spice/nightly. Considering also 1/3 looks like we are creating > > a circular dependency where copr build is launched by Gitlab and > > Gitlab build depends on copr build. > > Indeed, at first i thought to specify the deps and clone spice-protocol > as was done > on other projects, but considering the creation of the nightly builds > directly using > the spec file which is inside the repo, keeping the builddep will reduce > the number > of changes need to be done when a new dependency is added. > > No builddep- spec file + .gitlab-ci.yml require an update. > > With builddep- just update spec, copr build will be created immediately > with this > change so builddep will follow (although !first! gitlab ci run may fail > if it builds > faster than copr) > Another issue which happened multiple times is that copr can be down or having issues which will make Gitlab CI fail. > > > > > I don't know much about how the current copr build are set. > > Who set them? Where are the scripts that generate them? > > > Current state is that a vm with cron job is checking for updates every > few hours > The scripts were mostly done by Pavel an mostly located in > https://gitlab.com/sheriber/copr-build-helper (i need to push recent > changes) > > Moving to gitlab to generate the builds would make it easier to follow > and maintain > It would be good if it was possible to do - make dist - rpmbuild -ts *.tar.xz - mock *.src.rpm (maybe with a manual build & install of spice-protocol) > > > Isn't fedpkg using mock to build? Then why installing > > spice-protocol on the machine? > > No, it builds on the machine itself, actually release may not be needed. > I think rpmbuild –bs will be equal (even better maybe) > I think in copr it works because spice-protocol is a nightly too. > I tried to add the copr as a repo but it didn't let me so i just > installed spice-protocol from git. > > > Snir. > > > > > Frediano > _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel