Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 guests/vars/mappings.yml             | 12 ++++++++++++
 guests/vars/projects/libvirt-php.yml |  6 ++++++
 2 files changed, 18 insertions(+)
 create mode 100644 guests/vars/projects/libvirt-php.yml

diff --git a/guests/vars/mappings.yml b/guests/vars/mappings.yml
index 4808b12..3290201 100644
--- a/guests/vars/mappings.yml
+++ b/guests/vars/mappings.yml
@@ -831,6 +831,18 @@ mappings:
     OpenSUSE:
     CentOS7:
 
+  php:
+    deb: php-dev
+    rpm: php-devel
+    pkg: php74
+
+  php-imagick:
+    default: php-imagick
+    FreeBSD: php74-pecl-imagick
+    Fedora: php-pecl-imagick
+    CentOS: php-pecl-imagick
+    CentOS8:
+
   pkg-config:
     default: pkgconf
     rpm: pkgconfig
diff --git a/guests/vars/projects/libvirt-php.yml b/guests/vars/projects/libvirt-php.yml
new file mode 100644
index 0000000..c911dc6
--- /dev/null
+++ b/guests/vars/projects/libvirt-php.yml
@@ -0,0 +1,6 @@
+---
+packages:
+  - php
+  - php-imagick
+  - xmllint
+  - xsltproc
-- 
2.26.2

On Tue, 2020-05-05 at 12:48 +0100, Daniel P. Berrangé wrote:
> +  php-imagick:
> +    default: php-imagick
> +    FreeBSD: php74-pecl-imagick
> +    Fedora: php-pecl-imagick
> +    CentOS: php-pecl-imagick
> +    CentOS8:

This could be

  php-imagick:
    deb: php-imagick
    rpm: php-pecl-imagick
    pkg: php74-pecl-imagick
    CentOS8:

This patch is also missing the part where the libvirt-php project is
added to the 'projects' fact for all targets that actually support
building it, which would be all of them but CentOS 8 in this case I
guess?

We're also missing build steps for the project. I understand that,
as we move stuff off CentOS CI and into GitLab CI containers become
more important than VMs, but I think keeping 'lcitool build' working
is still important, if nothing else as a development tool. It
certainly makes my life easier as a reviewer... Not to mention it is
the only way we can currently validate FreeBSD changes.

-- 
Andrea Bolognani / Red Hat / Virtualization

On Tue, May 05, 2020 at 03:05:42PM +0200, Andrea Bolognani wrote:
> On Tue, 2020-05-05 at 12:48 +0100, Daniel P. Berrangé wrote:
> > +  php-imagick:
> > +    default: php-imagick
> > +    FreeBSD: php74-pecl-imagick
> > +    Fedora: php-pecl-imagick
> > +    CentOS: php-pecl-imagick
> > +    CentOS8:
> 
> This could be
> 
>   php-imagick:
>     deb: php-imagick
>     rpm: php-pecl-imagick
>     pkg: php74-pecl-imagick
>     CentOS8:

Ok.

> 
> This patch is also missing the part where the libvirt-php project is
> added to the 'projects' fact for all targets that actually support
> building it, which would be all of them but CentOS 8 in this case I
> guess?
> 
> We're also missing build steps for the project. I understand that,
> as we move stuff off CentOS CI and into GitLab CI containers become
> more important than VMs, but I think keeping 'lcitool build' working
> is still important, if nothing else as a development tool. It
> certainly makes my life easier as a reviewer... Not to mention it is
> the only way we can currently validate FreeBSD changes.

There's a bunch of projects we don't have in Jenkins CI right now, and
I'm trying to get them all wired up into GitLab CI. I don't want to
invest any more time in VM build aspects right now, as I don't have
the time to spend testing & debugging that part too. So I'm only going
to do the minimal required to get container builds work, which is defining
the package lists used to feed the container build. The extra VM build
stuff can be done separately at a later date if we decide we need that
still for CI.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

On Tue, 2020-05-05 at 14:19 +0100, Daniel P. Berrangé wrote:
> On Tue, May 05, 2020 at 03:05:42PM +0200, Andrea Bolognani wrote:
> > This patch is also missing the part where the libvirt-php project is
> > added to the 'projects' fact for all targets that actually support
> > building it, which would be all of them but CentOS 8 in this case I
> > guess?
> > 
> > We're also missing build steps for the project. I understand that,
> > as we move stuff off CentOS CI and into GitLab CI containers become
> > more important than VMs, but I think keeping 'lcitool build' working
> > is still important, if nothing else as a development tool. It
> > certainly makes my life easier as a reviewer... Not to mention it is
> > the only way we can currently validate FreeBSD changes.
> 
> There's a bunch of projects we don't have in Jenkins CI right now, and
> I'm trying to get them all wired up into GitLab CI. I don't want to
> invest any more time in VM build aspects right now, as I don't have
> the time to spend testing & debugging that part too. So I'm only going
> to do the minimal required to get container builds work, which is defining
> the package lists used to feed the container build. The extra VM build
> stuff can be done separately at a later date if we decide we need that
> still for CI.

I guess I'll have to put my money where my mouth is and add the build
steps myself. That's fair. Please at least update the inventory so
that it accurately records which targets are supposed to be able to
build the new project.

-- 
Andrea Bolognani / Red Hat / Virtualization

On Tue, May 05, 2020 at 03:31:55PM +0200, Andrea Bolognani wrote:
> On Tue, 2020-05-05 at 14:19 +0100, Daniel P. Berrangé wrote:
> > On Tue, May 05, 2020 at 03:05:42PM +0200, Andrea Bolognani wrote:
> > > This patch is also missing the part where the libvirt-php project is
> > > added to the 'projects' fact for all targets that actually support
> > > building it, which would be all of them but CentOS 8 in this case I
> > > guess?
> > > 
> > > We're also missing build steps for the project. I understand that,
> > > as we move stuff off CentOS CI and into GitLab CI containers become
> > > more important than VMs, but I think keeping 'lcitool build' working
> > > is still important, if nothing else as a development tool. It
> > > certainly makes my life easier as a reviewer... Not to mention it is
> > > the only way we can currently validate FreeBSD changes.
> > 
> > There's a bunch of projects we don't have in Jenkins CI right now, and
> > I'm trying to get them all wired up into GitLab CI. I don't want to
> > invest any more time in VM build aspects right now, as I don't have
> > the time to spend testing & debugging that part too. So I'm only going
> > to do the minimal required to get container builds work, which is defining
> > the package lists used to feed the container build. The extra VM build
> > stuff can be done separately at a later date if we decide we need that
> > still for CI.
> 
> I guess I'll have to put my money where my mouth is and add the build
> steps myself. That's fair. Please at least update the inventory so
> that it accurately records which targets are supposed to be able to
> build the new project.

That's only required for VM builds, and would  use of the "all"
wildcard when building VMs, so I'm not wanting to do that, as I
won't have tested anything related to VMs.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

On Tue, 2020-05-05 at 14:49 +0100, Daniel P. Berrangé wrote:
> On Tue, May 05, 2020 at 03:31:55PM +0200, Andrea Bolognani wrote:
> > Please at least update the inventory so
> > that it accurately records which targets are supposed to be able to
> > build the new project.
> 
> That's only required for VM builds, and would  use of the "all"
> wildcard when building VMs, so I'm not wanting to do that, as I
> won't have tested anything related to VMs.

It also serves as documentation for our expectations when it comes to
which project can be built on which platform, and was intended to
prevent the use of

  ./lctiool $action $target $project

when $target is known not to support $project, even though we didn't
enfore that for 'update' and 'build' in order to make

  ./lcitool $action all all

work smoothly, and 'dockerfile' lost the check in one of your
recent patches...

-- 
Andrea Bolognani / Red Hat / Virtualization

On Tue, May 05, 2020 at 04:33:48PM +0200, Andrea Bolognani wrote:
> On Tue, 2020-05-05 at 14:49 +0100, Daniel P. Berrangé wrote:
> > On Tue, May 05, 2020 at 03:31:55PM +0200, Andrea Bolognani wrote:
> > > Please at least update the inventory so
> > > that it accurately records which targets are supposed to be able to
> > > build the new project.
> > 
> > That's only required for VM builds, and would  use of the "all"
> > wildcard when building VMs, so I'm not wanting to do that, as I
> > won't have tested anything related to VMs.
> 
> It also serves as documentation for our expectations when it comes to
> which project can be built on which platform, and was intended to
> prevent the use of
> 
>   ./lctiool $action $target $project
> 
> when $target is known not to support $project, even though we didn't
> enfore that for 'update' and 'build' in order to make
> 
>   ./lcitool $action all all
> 
> work smoothly, and 'dockerfile' lost the check in one of your
> recent patches...

IIUC,  "lcitool build  libvirt-fedora-32 all" will try to build all
projects in the host's inventory. So if we add libvirt-rust, to the host
inventory we need to full the full VM setup for the project, otherwise
we'll break this build.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

On Tue, 2020-05-05 at 15:51 +0100, Daniel P. Berrangé wrote:
> On Tue, May 05, 2020 at 04:33:48PM +0200, Andrea Bolognani wrote:
> > On Tue, 2020-05-05 at 14:49 +0100, Daniel P. Berrangé wrote:
> > > That's only required for VM builds, and would  use of the "all"
> > > wildcard when building VMs, so I'm not wanting to do that, as I
> > > won't have tested anything related to VMs.
> > 
> > It also serves as documentation for our expectations when it comes to
> > which project can be built on which platform, and was intended to
> > prevent the use of
> > 
> >   ./lctiool $action $target $project
> > 
> > when $target is known not to support $project, even though we didn't
> > enfore that for 'update' and 'build' in order to make
> > 
> >   ./lcitool $action all all
> > 
> > work smoothly, and 'dockerfile' lost the check in one of your
> > recent patches...
> 
> IIUC,  "lcitool build  libvirt-fedora-32 all" will try to build all
> projects in the host's inventory. So if we add libvirt-rust, to the host
> inventory we need to full the full VM setup for the project, otherwise
> we'll break this build.

Mh, that's correct. Another consequence of not really having planned
for things to be introduced only partially.

-- 
Andrea Bolognani / Red Hat / Virtualization

On Tue, May 05, 2020 at 02:19:27PM +0100, Daniel P. Berrangé wrote:
> On Tue, May 05, 2020 at 03:05:42PM +0200, Andrea Bolognani wrote:
> > On Tue, 2020-05-05 at 12:48 +0100, Daniel P. Berrangé wrote:
> > > +  php-imagick:
> > > +    default: php-imagick
> > > +    FreeBSD: php74-pecl-imagick
> > > +    Fedora: php-pecl-imagick
> > > +    CentOS: php-pecl-imagick
> > > +    CentOS8:
> > 
> > This could be
> > 
> >   php-imagick:
> >     deb: php-imagick
> >     rpm: php-pecl-imagick
> >     pkg: php74-pecl-imagick
> >     CentOS8:
> 
> Ok.

Actually that's not right, because it gives the wrong RPM name
for OpenSuse.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

On Tue, 2020-05-05 at 14:22 +0100, Daniel P. Berrangé wrote:
> On Tue, May 05, 2020 at 02:19:27PM +0100, Daniel P. Berrangé wrote:
> > On Tue, May 05, 2020 at 03:05:42PM +0200, Andrea Bolognani wrote:
> > > On Tue, 2020-05-05 at 12:48 +0100, Daniel P. Berrangé wrote:
> > > > +  php-imagick:
> > > > +    default: php-imagick
> > > > +    FreeBSD: php74-pecl-imagick
> > > > +    Fedora: php-pecl-imagick
> > > > +    CentOS: php-pecl-imagick
> > > > +    CentOS8:
> > > 
> > > This could be
> > > 
> > >   php-imagick:
> > >     deb: php-imagick
> > >     rpm: php-pecl-imagick
> > >     pkg: php74-pecl-imagick
> > >     CentOS8:
> > 
> > Ok.
> 
> Actually that's not right, because it gives the wrong RPM name
> for OpenSuse.

Yeah, you're right. A slightly improved version would be

  php-imagick:
    default: php-imagick
    pkg: php74-pecl-imagick
    CentOS: php-pecl-imagick
    Fedora: php-pecl-imagick
    CentOS8:

-- 
Andrea Bolognani / Red Hat / Virtualization