On 2/26/19 4:41 PM, Frediano Ziglio wrote:
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?
It's the same dependencies but indirectly.
But you are right .gitlab-ci.yml can probably get its dependencies also
from the spec file (hopefully spec.in can be accessed from before_script)
Conceptually the CI should try to use step similar to what an
user or developer does. I honestly never used @copr to build
spice.
I'm not sure if copr is really considered ci but i find it useful
to get easily upstream spice components in vms without compiling
anything.
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)
I do not get the difference, this is kind of what happens now, once
the src.rpm is generated it is being rebuilt in several different fresh
releases (&architectures) which has the nightly-builds as a repo (so
spice-protocol is the latest upstream too)
Snir
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