[Spice-devel] [spice-gtk v1 00/10] Flatpak + CI

[Marc-André Lureau]

Hi

On Mon, Feb 11, 2019 at 2:57 PM Victor Toso <victortoso at redhat.com> wrote:
>
> On Mon, Feb 11, 2019 at 02:44:23PM +0100, Marc-André Lureau wrote:
> > Hi
> >
> > On Mon, Feb 11, 2019 at 2:21 PM Victor Toso <victortoso at redhat.com> wrote:
> > >
> > > Hi,
> > >
> > > On Mon, Feb 11, 2019 at 02:06:19PM +0100, Marc-André Lureau wrote:
> > > > Hi
> > > >
> > > > On Mon, Feb 11, 2019 at 1:59 PM Victor Toso <victortoso at redhat.com> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > On Mon, Feb 11, 2019 at 01:09:41PM +0100, Marc-André Lureau wrote:
> > > > > > > Having a virt-viewer flatpak does not mean _not_ having a
> > > > > > > spicy.flatkpak (to me); one is full featured spice client while
> > > > > > > the other a testing tool...
> > > > > >
> > > > > > It looks like a lot of duplication of flatpak effort. Maybe you could
> > > > > > simply ship spicy in virt-viewer flatpak, so it could be run from
> > > > > > command line (please no .desktop)
> > > > >
> > > > > Is the fact that we are installing a .desktop for spicy the only
> > > > > issue here or you don't want to see a flatpak of spicy in the
> > > > > gitlab-ci anyway? (btw, I'm not planning to upload this to any
> > > > > flatpak provider).
> > > >
> > > > What's the point in building a spice-gtk flatpak then, when you
> > > > have virt-viewer flatpak?
> > >
> > > You replied my question with another question.
> > >
> > > My main motivation is that spicy is self contained in spice-gtk,
> > > smaller and targeted to be a testing tool, so, testing spice-gtk
> > > changes.
> >
> > I see, you would like CI build version readily available.
>
> As you can see by browsing the link in the cover letter
>
>     https://gitlab.freedesktop.org/victortoso/spice-gtk/-/jobs/105184/artifacts/browse
>
> > (kind of a waste of space to me, but it may be useful)
>
> 1.1 MB. To avoid waste of space, the flatkpak is not generated
> automatically but manually, that is, you have to click on this
> 'job' in the CI to activate it; besides that, the artifact is set
> to expire_in: 2 days

Ok, I don't see much point in having it built in the CI then

>
> > virt-viewer with only --enable-spice-gtk shouldn't have much more
> > dependencies though.
>
> > > If I add virt-viewer -> flatpak or msi installer to gitlab-ci's
> > > artifacts, that's out of scope of spice-gtk although I'll be
> > > using it all the time...
> >
> > Oh you are thinking about building virt-viewer from spice-gtk CI?
> > interesting... I wonder if there are mechanisms already to trigger
> > rebuilds of dependent projects, I am pretty sure there are
> > solutions to that. And flatpak build can pull from upstream
> > repository master I guess.
>
> My interest is testing spice/spice-gtk only. So, to regenerate
> virt-viewer flatpak from spice-gtk CI because there is a new
> commit in virt-viewer is totally out of context, for me.

No, but your interest seems to have a flatpak readily available when
doing a commit in spice-gtk.

>
> I'd be glad if virt-viewer was in gitlab, close to no knowledge
> around Pagure infra.
>
> I still don't know if your earlier concern around .desktop is due
> the fact we are installing it (patch 04/10) or with spicy
> flatkpak itself.

I am concern about distributing spice-gtk and spicy in new forms in
general. The .desktop is pretty much a no-go to me. The flatpak I
don't really understand what we need / want it for.


-- 
Marc-André Lureau