On Mon, Aug 24, 2015 at 06:35:00AM +0200, Niels de Vos wrote:
> On Mon, Aug 24, 2015 at 09:01:52AM +0530, Lalatendu Mohanty wrote:
> > On 08/22/2015 10:22 PM, Niels de Vos wrote:
> > >Hi Lala,
> > >
> > >Today I've prepared the glusterfs-coreutils package for the Storage SIG.
> > >Everything works fine, but there is one thing I am unable to get done.
> > >Maybe I am missing certain permissions?
> > >
> > >The new glusterfs-coreutils package would need to be added to the CBS.
> > >This fails for me:
> > >
> > > $ koji -p centos \
> > > add-pkg --owner storage \
> > > storage6-gluster-common-candidate glusterfs-coreutils
> > > SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)
> > >
> > >Doing scratch-builds works fine, so I doubt that the issue really is the
> > >SSL-certificate.
> > >
> > >Could you let me know if I am doing something wrong, or if it is
> > >expected that I can not add new packages?
> > >
> > >Thanks,
> > >Niels
> >
> > Niels,
> >
> > I correct command is "koji add-pkg storage6-gluster-common-candidate
> > glusterfs-coreutils --owner storage". I have executed this and it is added
> > to the SIG now. Let me know you still face the issue.
>
> Thanks, but that really does not work for me... I'd like to add
> userspace-rcu and glusterfs-coreutils to the storage7 channels too, but
> it fails exactly the same as before:
>
> $ koji -p centos add-pkg storage7-gluster-37-candidate userspace-rcu --owner storage
> SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)
>
> $ koji -p centos add-pkg storage7-gluster-common-candidate glusterfs-coreutils --owner storage
> SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)
>
> Note that I use "-p centos" to pick the CentOS profile for Koji, the
> default would connect to Fedora's instance.
Hmm, I think I have a misunderstanding of how things are setup. The
storage6-gluster-common-candidate does not contain any glusterfs
packages, so building glusterfs-coreutils for storage6-gluster-common-*
fails. I guess glusterfs-coreutils needs to be added to
- storage6-gluster-36-*
- storage6-gluster-37-*
- storage7-gluster-36-*
- storage7-gluster-37-*
Adding a little more to this. What would be the best place to document
the structure of the tags that contain which packages? I would like to
see something similar to this:
storage6-common-*
|- base packages/dependencies like centos-storage-release
|
|- storage6-gluster-common-*
| |- dependencies for Gluster, like userspace-rcu
| |
| |- storage6-gluster-35-*
| | '- GlusterFS 3.5 and related packages
| |
| |- storage6-gluster-36-*
| | '- GlusterFS 3.6 and related packages
| |
| |- storage6-gluster-37-*
| : '- GlusterFS 3.7 and related packages
|
'- storage6-..openafs..
'- OpenAFS packages
Which tags would contain a centos-storage-gluster-release package? In
the end, what would users install to get access to the repositories they
need?
Now, glusterfs-coreutils depends on glusterfs >= 3.6, and it is possible
to compile against glusterfs-3.6 but run the binaries with
glusterfs-3.7. To which tag(s) this package be added? Other packages
like scsi-target-utils (with Gluster support) would be an other
candidate for a 'common' tag. Should these all get build for the
different storage6-gluster-36/37 tags?
We also want to have storage7 for CentOS-7 and most likely a reduced set
for storage5. I would prefer to keep the number of builds that need to
be done as small as possible, and share as much as possible between the
different releases.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20150824/8818be37/attachment-0008.sig>