Re: [Spice-devel] [PATCH 1/3] Add copr Makefile
> On 2/26/19 7:40 PM, Frediano Ziglio wrote: > >> --- > >> .copr/Makefile | 21 + > >> 1 file changed, 21 insertions(+) > >> create mode 100644 .copr/Makefile > >> > >> diff --git a/.copr/Makefile b/.copr/Makefile > >> new file mode 100644 > >> index 000..53b1b1b > >> --- /dev/null > >> +++ b/.copr/Makefile > >> @@ -0,0 +1,21 @@ > >> +PROTOCOL_GIT_REPO = https://gitlab.freedesktop.org/spice/spice-protocol > >> +BUILD = make automake autoconf autoconf-archive libtool xz gcc-c++ fedpkg > >> + > >> +srpm: > >> + dnf install -y $(BUILD) > >> + > >> + # get upstream spice protocol > >> + git clone $(PROTOCOL_GIT_REPO) > >> + cd spice-protocol ; ./autogen.sh ; make install > > > > I would use && to avoid ignoring error and a /usr prefix: > > > > cd spice-protocol && ./autogen.sh --prefix=/usr && make install > > You need root permissions to be able to install under /usr > Even to install in /usr/local and to use dnf install. > Does copr builder run as root ? > Apparently that script is run as root. > Uri > ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 1/3] Add copr Makefile
On 2/26/19 7:40 PM, Frediano Ziglio wrote: --- .copr/Makefile | 21 + 1 file changed, 21 insertions(+) create mode 100644 .copr/Makefile diff --git a/.copr/Makefile b/.copr/Makefile new file mode 100644 index 000..53b1b1b --- /dev/null +++ b/.copr/Makefile @@ -0,0 +1,21 @@ +PROTOCOL_GIT_REPO = https://gitlab.freedesktop.org/spice/spice-protocol +BUILD = make automake autoconf autoconf-archive libtool xz gcc-c++ fedpkg + +srpm: + dnf install -y $(BUILD) + + # get upstream spice protocol + git clone $(PROTOCOL_GIT_REPO) + cd spice-protocol ; ./autogen.sh ; make install I would use && to avoid ignoring error and a /usr prefix: cd spice-protocol && ./autogen.sh --prefix=/usr && make install You need root permissions to be able to install under /usr Does copr builder run as root ? Uri ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 1/3] Add copr Makefile
> ---
> .copr/Makefile | 21 +
> 1 file changed, 21 insertions(+)
> create mode 100644 .copr/Makefile
>
> diff --git a/.copr/Makefile b/.copr/Makefile
> new file mode 100644
> index 000..53b1b1b
> --- /dev/null
> +++ b/.copr/Makefile
> @@ -0,0 +1,21 @@
> +PROTOCOL_GIT_REPO = https://gitlab.freedesktop.org/spice/spice-protocol
> +BUILD = make automake autoconf autoconf-archive libtool xz gcc-c++ fedpkg
> +
> +srpm:
> + dnf install -y $(BUILD)
> +
> + # get upstream spice protocol
> + git clone $(PROTOCOL_GIT_REPO)
> + cd spice-protocol ; ./autogen.sh ; make install
I would use && to avoid ignoring error and a /usr prefix:
cd spice-protocol && ./autogen.sh --prefix=/usr && make install
> +
> + # get dependencies
> + dnf install -y `grep BuildRequires\: spice-streaming-agent.spec.in | awk
> '{$$1=""; print $$0}' | sed "s/\bspice-protocol\b// ; s/>.*//" | tr -s "\n"
> " "`
it got me a bit of time to read, why not:
dnf install -y `sed '/^BuildRequires:/!d; s/.*://;
s/\bspice-protocol\b//; s/>.*//' spice-streaming-agent.spec.in`
the tr command is not needed, when expanded the shell will strip and
collapse the spaces, by default IFS contains a space, a tab and a new line.
> + # build this project
> + PKG_CONFIG_PATH=/usr/local/share/pkgconfig ./autogen.sh
With the change above (prefix), just
./autogen.sh
> +
> + # create source rpm
> + sed -i -E "s/(^Release:[[:space:]]*)([^%]*)/\1`date
> +'%Y%m%d%H%M.spice.nigthly'`/" spice-streaming-agent.spec
> + make dist
> + md5sum *tar* | head -n1 > "sources"
I would be a bit more specific with a
md5sum *.tar.xz | head -n1 > "sources"
I remember I had some hard time with some machines which were
ordering in a different way the files as the language were
different from my machine.
> + fedpkg --release "epel7" --path . srpm
Here "--path ." is the default
> + cp *src.rpm $(outdir)
Frediano
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 2/3] Update .gitlab-ci.yml
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 () 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 2/3] Update .gitlab-ci.yml
> 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [spice-gtk] usb-redir: use persistent libusb device on Windows
> On Fri, Feb 22, 2019 at 2:06 PM Christophe Fergeau
> wrote:
> >
> > Hi,
> >
> > On Thu, Feb 21, 2019 at 09:37:06AM +0200, Yuri Benditovich wrote:
> > > On Wed, Feb 20, 2019 at 6:03 PM Christophe Fergeau
> > > wrote:
> > > > > static SpiceUsbDevice*
> > > > > spice_usb_device_manager_find_device(SpiceUsbDeviceManager *self,
> > > > > const int bus, const int
> > > > > address)
> > > > > @@ -970,6 +914,16 @@ static void
> > > > > spice_usb_device_manager_add_dev(SpiceUsbDeviceManager *self,
> > > > > if (desc.bDeviceClass == LIBUSB_CLASS_HUB)
> > > > > return;
> > > > >
> > > > > +if (spice_usb_device_manager_find_device(self,
> > > > > +libusb_get_bus_number(libdev),
> > > > > +
> > > > > libusb_get_device_address(libdev)))
> > > > > {
> > > > > +SPICE_DEBUG("device not added %04x:%04x (%p)",
> > > > > +desc.idVendor,
> > > > > +desc.idProduct,
> > > > > +libdev);
> > > > > +return;
> > > > > +}
> > > > > +
> > > >
> > > > I did not understand why we need this?
> > >
> > > There are several reasons:
> > > 1. It is possible that the hot plug procedure for Linux might be
> > > called more than once for the same device (this is mentioned in libusb
> > > API).
> >
> > It's
> > http://libusb.sourceforge.net/api-1.0/group__hotplug.html#gae6c5f1add6cc754005549c7259dc35ea
> > and this can happen at coldplug time (ie when using
> > LIBUSB_HOTPLUG_ENUMERATE), so exactly the race I was worried about
> > before.
> >
> > > 2. If second instance of usb-device-manager created (as it happens at
> > > time of remote-viewer termination),
> >
> > It sounds weird that we create a new one when exiting, probably
> > something we can/should get rid of if this starts causing problems.
> >
> > > existing one receives each device that already present.
> > > 3. It is much simpler to exclude device duplication than later look
> > > why they present.
> >
> >
> > All of these explanations would be very useful to have in the log of a
> > separate commit.
> >
> > > > > +#ifdef G_OS_WIN32
> > > > > static void spice_usb_device_manager_uevent_cb(GUdevClient
> > > > > *client,
> > > > > - const gchar
> > > > > *action,
> > > > > - GUdevDevice
> > > > > *udevice,
> > > > > + libusb_device
> > > > > *libdev,
> > > > > + gboolean add,
> > > > > gpointer
> > > > > user_data)
> > > > > {
> > > > > SpiceUsbDeviceManager *self =
> > > > > SPICE_USB_DEVICE_MANAGER(user_data);
> > > > >
> > > > > -if (g_str_equal(action, "add"))
> > > > > -spice_usb_device_manager_add_udev(self, udevice);
> > > > > -else if (g_str_equal (action, "remove"))
> > > > > -spice_usb_device_manager_remove_udev(self, udevice);
> > > > > +if (add)
> > > > > +spice_usb_device_manager_add_dev(self, libdev);
> > > > > +else
> > > > > +spice_usb_device_manager_remove_dev(self,
> > > > > +libusb_get_bus_number(libdev),
> > > > > +
> > > > > libusb_get_device_address(libdev));
> > > >
> > > > This could almost reuse spice_usb_device_manager_hotplug_cb somehow,
> > > > but
> > > > I'm not sure this is worth it.
> > >
> > > What I'm expected to do to address this note?
> >
> > Just random thoughts, maybe you'll think this could be a useful
> > improvement, maybe you already considered it and rejected it, maybe it's
> > not a good idea, I don't know. I don't have any expectations, just
> > something that could be useful to mention.
> >
> >
> > > > > @@ -1889,9 +1751,7 @@ static SpiceUsbDeviceInfo
> > > > > *spice_usb_device_new(libusb_device *libdev)
> > > > > info->pid = pid;
> > > > > info->ref = 1;
> > > > > info->isochronous = probe_isochronous_endpoint(libdev);
> > > > > -#ifndef G_OS_WIN32
> > > > > info->libdev = libusb_ref_device(libdev);
> > > > > -#endif
> > > > >
> > > > > return info;
> > > > > }
> > > > > @@ -2027,14 +1887,11 @@ static void
> > > > > spice_usb_device_unref(SpiceUsbDevice *device)
> > > > >
> > > > > ref_count_is_0 = g_atomic_int_dec_and_test(>ref);
> > > > > if (ref_count_is_0) {
> > > > > -#ifndef G_OS_WIN32
> > > > > libusb_unref_device(info->libdev);
> > > > > -#endif
> > > >
> > > > Most of the 'persistent' libusb_device changes for Windows are in the
> > > > hunks before this, but they also depend on some rework of the hotplug
> > > > detection in GUdevClient.
> > >
> > > What I'm expected to do to address this note?
> >
> > Just a comment that could be useful to me in the future, or to other
> > people looking at
Re: [Spice-devel] [PATCH 2/3] Update .gitlab-ci.yml
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) 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) 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 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 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [RFC spice-streaming-agent 0/3] Integration with copr build system
HI, On 2/26/19 10:43 AM, Victor Toso wrote: Hi, On Tue, Feb 26, 2019 at 10:26:36AM +0200, Snir Sheriber wrote: Hi, On 2/25/19 6:20 PM, Victor Toso wrote: Hi, On Mon, Feb 25, 2019 at 04:56:44PM +0200, Snir Sheriber wrote: This is an example for integration of copr and gitlab so that any git update will generate a copr build automatically. Doing that for whole our repos will allow to get an updated upstream repo without maintaining a running vm somewhere. (although i'm still not sure what to do with the mingw builds yet) If this is agreed i'll start adding specs and copr Makefiles to all projects Suggestions and more elegant scripting are welcome Working example*: any push tohttps://gitlab.com/sheriber/spice-streaming-agent-ci will generate upstream builds here: https://copr.fedorainfracloud.org/coprs/snir/spice-project/package/spice-streaming-agent/ *require to configure a small gitlab webhook. What kind of hook? Just to configure gitlab to trigger the copr repo webhook link every push in gitlab project settings->integrations Does this configuration involve storing some ssh key or something else for auth purposes? There is an option for some token but it is not seems to be supported by copr There is also a ssl verification of the webhook endpoint just to make sure it has valid certificate (but this is not very impotent for us since the endpoint is copr) IIUC the only auth is the webhook URL which has some key that is known only for copr's project owner (and gitlab), also they probably validating this was triggered from the git repository that matches the one which defined in copr. The fedpkg needs some ssh and/or kerberos ticket, no? Forgot to mention, no, it is used just for creating srpm locally I think it should be safe to push 2/3 and 3/3 while 1/3 stays as RFC. Indeed, 2&3 are not very related Ack then? Yep, LGTM! I didn't test but I trust you did :) Thanks! In regards to the RFC, I'm in favor of moving such tasks to gitlab as well. So, +1 for me for the idea. I'd move the Makefile as a job in gitlab-ci.yml itself. This Makefile is located specifically there to integrate with copr so that every time a copr build is invoked this script is executed to generate the srpm for the current build (instead of PUSHING SRPM FROM external vm as we do now). (a copr build is invoked when the webhook url is triggered i.e every push) Seehttps://docs.pagure.org/copr.copr/user_documentation.html#make-srpm Snir. What I would like to understand is how copr will get the outcome of make srpm to deploy, for instance, what you mentioned in the cover letter: Copr runs this Makefile in some vm/container and expect the outcome to be in $outdir it's explained here: https://docs.pagure.org/copr.copr/user_documentation.html#make-srpm Snir https://copr.fedorainfracloud.org/coprs/snir/spice-project/package/spice-streaming-agent/ Again, not against it, just trying to understand how will things work. no worries :) Cheers Cheers, Snir Sheriber (3): Add copr Makefile https://docs.pagure.org/copr.copr/user_documentation.html#make-srpm Update .gitlab-ci.yml I think we should leave builddep for installing the deps, it will be updated automatically when spec file BuildRequiers is updated (gitlab ci may fail on the first ci iteration after such update but will converge on the second one) Update spec.in .copr/Makefile| 21 + .gitlab-ci.yml| 1 - spice-streaming-agent.spec.in | 1 + 3 files changed, 22 insertions(+), 1 deletion(-) create mode 100644 .copr/Makefile -- 2.19.1 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 2/3] Update .gitlab-ci.yml
> > --- > .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. 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. I don't know much about how the current copr build are set. Who set them? Where are the scripts that generate them? Isn't fedpkg using mock to build? Then why installing spice-protocol on the machine? Frediano ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 3/3] Update spec.in
> > gcc-c++ is not being installed on fedora 29 builds Acked-by: Frediano Ziglio > --- > spice-streaming-agent.spec.in | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/spice-streaming-agent.spec.in b/spice-streaming-agent.spec.in > index 6206cdc..3874c2e 100644 > --- a/spice-streaming-agent.spec.in > +++ b/spice-streaming-agent.spec.in > @@ -13,6 +13,7 @@ BuildRequires: catch-devel > BuildRequires: pkgconfig(udev) > BuildRequires: libdrm-devel > BuildRequires: libXrandr-devel > +BuildRequires: gcc-c++ > # we need /usr/sbin/semanage program which is available on different > # packages depending on distribution > Requires(post): /usr/sbin/semanage ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [RFC spice-streaming-agent 0/3] Integration with copr build system
Hi, On Tue, Feb 26, 2019 at 10:26:36AM +0200, Snir Sheriber wrote: > Hi, > > > On 2/25/19 6:20 PM, Victor Toso wrote: > > Hi, > > > > On Mon, Feb 25, 2019 at 04:56:44PM +0200, Snir Sheriber wrote: > > > This is an example for integration of copr and gitlab so that > > > any git update will generate a copr build automatically. > > > Doing that for whole our repos will allow to get an updated > > > upstream repo without maintaining a running vm somewhere. > > > (although i'm still not sure what to do with the mingw builds yet) > > > > > > If this is agreed i'll start adding specs and copr Makefiles > > > to all projects > > > > > > Suggestions and more elegant scripting are welcome > > > > > > Working example*: > > > any push to https://gitlab.com/sheriber/spice-streaming-agent-ci > > > will generate upstream builds here: > > > https://copr.fedorainfracloud.org/coprs/snir/spice-project/package/spice-streaming-agent/ > > > > > > *require to configure a small gitlab webhook. > > What kind of hook? > > > Just to configure gitlab to trigger the copr repo webhook link every push > in gitlab project settings->integrations Does this configuration involve storing some ssh key or something else for auth purposes? > > The fedpkg needs some ssh and/or kerberos ticket, no? > > > > I think it should be safe to push 2/3 and 3/3 while 1/3 stays as > > RFC. > > > Indeed, 2&3 are not very related > > Ack then? Yep, LGTM! I didn't test but I trust you did :) > > In regards to the RFC, I'm in favor of moving such tasks to > > gitlab as well. So, +1 for me for the idea. I'd move the Makefile > > as a job in gitlab-ci.yml itself. > > > This Makefile is located specifically there to integrate with > copr so that every time a copr build is invoked this script is > executed to generate the srpm for the current build (instead of > PUSHING SRPM FROM external vm as we do now). > (a copr build is invoked when the webhook url is triggered i.e every push) > > See https://docs.pagure.org/copr.copr/user_documentation.html#make-srpm > > Snir. What I would like to understand is how copr will get the outcome of make srpm to deploy, for instance, what you mentioned in the cover letter: https://copr.fedorainfracloud.org/coprs/snir/spice-project/package/spice-streaming-agent/ Again, not against it, just trying to understand how will things work. Cheers > > Cheers, > > > > > Snir Sheriber (3): > > >Add copr Makefile > > > https://docs.pagure.org/copr.copr/user_documentation.html#make-srpm > > >Update .gitlab-ci.yml > > > I think we should leave builddep for installing the deps, it will be > > > updated > > > automatically when spec file BuildRequiers is updated (gitlab ci may > > > fail > > > on the first ci iteration after such update but will converge on the > > > second > > > one) > > >Update spec.in > > > > > > .copr/Makefile| 21 + > > > .gitlab-ci.yml| 1 - > > > spice-streaming-agent.spec.in | 1 + > > > 3 files changed, 22 insertions(+), 1 deletion(-) > > > create mode 100644 .copr/Makefile > > > > > > -- > > > 2.19.1 > > > > > > ___ > > > Spice-devel mailing list > > > Spice-devel@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/spice-devel signature.asc Description: PGP signature ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [RFC spice-streaming-agent 0/3] Integration with copr build system
Hi, On 2/25/19 6:20 PM, Victor Toso wrote: Hi, On Mon, Feb 25, 2019 at 04:56:44PM +0200, Snir Sheriber wrote: This is an example for integration of copr and gitlab so that any git update will generate a copr build automatically. Doing that for whole our repos will allow to get an updated upstream repo without maintaining a running vm somewhere. (although i'm still not sure what to do with the mingw builds yet) If this is agreed i'll start adding specs and copr Makefiles to all projects Suggestions and more elegant scripting are welcome Working example*: any push to https://gitlab.com/sheriber/spice-streaming-agent-ci will generate upstream builds here: https://copr.fedorainfracloud.org/coprs/snir/spice-project/package/spice-streaming-agent/ *require to configure a small gitlab webhook. What kind of hook? Just to configure gitlab to trigger the copr repo webhook link every push in gitlab project settings->integrations The fedpkg needs some ssh and/or kerberos ticket, no? I think it should be safe to push 2/3 and 3/3 while 1/3 stays as RFC. Indeed, 2&3 are not very related Ack then? In regards to the RFC, I'm in favor of moving such tasks to gitlab as well. So, +1 for me for the idea. I'd move the Makefile as a job in gitlab-ci.yml itself. This Makefile is located specifically there to integrate with copr so that every time a copr build is invoked this script is executed to generate the srpm for the current build (instead of pushing srpm from external vm as we do now). (a copr build is invoked when the webhook url is triggered i.e every push) See https://docs.pagure.org/copr.copr/user_documentation.html#make-srpm Snir. Cheers, Snir Sheriber (3): Add copr Makefile https://docs.pagure.org/copr.copr/user_documentation.html#make-srpm Update .gitlab-ci.yml I think we should leave builddep for installing the deps, it will be updated automatically when spec file BuildRequiers is updated (gitlab ci may fail on the first ci iteration after such update but will converge on the second one) Update spec.in .copr/Makefile| 21 + .gitlab-ci.yml| 1 - spice-streaming-agent.spec.in | 1 + 3 files changed, 22 insertions(+), 1 deletion(-) create mode 100644 .copr/Makefile -- 2.19.1 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
