On 08/24/2015 10:59 AM, Niels de Vos wrote: > 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: I think we can put it in https://wiki.centos.org/SpecialInterestGroup/Storage/Gluster. > > 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. > >