> this image highlights content movement from cbs into various places :
> http://www.karan.org/CBS_ContentPromotion.png
Thanks Karanbir for posting that link to the explanatory diagram
That certainly helped my understanding. :-)
So now I am looking at the published builds, rather than koji links
I find
http://cbs.centos.org/repos/storage7-testing/x86_64/os/repoview/
Which seems to me to contain older stuff built from
storage7-testing
http://cbs.centos.org/koji/taginfo?tagID=9
and
http://cbs.centos.org/repos/storage7-gluster-37-candidate/x86_64/os/repovie…
which I try.
# mkdir storage7-gluster-37-candidate
# cd ~/admin/storage7-gluster-37-candidate/
wget --no-verbose --no-parent --recursive --level=1 --no-directories
http://cbs.centos.org/repos/storage7-gluster-37-candidate/x86_64/os/Package…
[root@vm407 storage7-gluster-37-candidate]# ls -alrt
total 4136
-rw-r--r--. 1 root root 46024 Aug 31 16:39
glusterfs-coreutils-0.0.1-0.1.git0c86f7f.el7.x86_64.rpm
-rw-r--r--. 1 root root 46404 Sep 1 10:14
userspace-rcu-devel-0.7.7-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 68672 Sep 1 10:14
userspace-rcu-0.7.7-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 1353308 Oct 14 22:31
glusterfs-server-3.7.5-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 90732 Oct 14 22:31
glusterfs-extra-xlators-3.7.5-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 772464 Oct 14 22:31
glusterfs-client-xlators-3.7.5-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 177420 Oct 14 22:31
glusterfs-cli-3.7.5-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 79104 Oct 14 22:31
glusterfs-api-3.7.5-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 59008 Oct 14 22:31
glusterfs-rdma-3.7.5-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 128812 Oct 14 22:31
glusterfs-fuse-3.7.5-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 26976 Oct 14 22:31
python-gluster-3.7.5-1.el7.noarch.rpm
-rw-r--r--. 1 root root 470360 Oct 14 22:31 glusterfs-3.7.5-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 37996 Oct 14 22:31
glusterfs-ganesha-3.7.5-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 182764 Oct 14 22:31
glusterfs-geo-replication-3.7.5-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 168972 Oct 14 22:31
glusterfs-devel-3.7.5-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 346892 Oct 14 22:31
glusterfs-libs-3.7.5-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 29444 Oct 14 22:31
glusterfs-resource-agents-3.7.5-1.el7.noarch.rpm
-rw-r--r--. 1 root root 36412 Oct 14 22:31
glusterfs-api-devel-3.7.5-1.el7.x86_64.rpm
-rw-r--r--. 1 root root 5595 Oct 21 13:42 index.html
-rw-r--r--. 1 root root 5595 Oct 21 13:42 index.html?C=N;O=D
-rw-r--r--. 1 root root 5595 Oct 21 13:42 index.html?C=M;O=A
-rw-r--r--. 1 root root 5595 Oct 21 13:42 index.html?C=S;O=A
-rw-r--r--. 1 root root 5595 Oct 21 13:42 index.html?C=D;O=A
drwxr-xr-x. 2 root root 4096 Oct 21 13:43 .
drwxr-xr-x. 6 root root 4096 Oct 21 13:59 ..
[root@vm407 storage7-gluster-37-candidate]#
[root@vm407 admin]# cd ..
[root@vm407 admin]# yum localinstall
./storage7-gluster-37-candidate/*.rpm | tee
yum_localinstall_storage7-gluster-37-candidate
<snip>
Error: Package: glusterfs-ganesha-3.7.5-1.el7.x86_64
(/glusterfs-ganesha-3.7.5-1.el7.x86_64)
Requires: nfs-ganesha-gluster
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
[root@vm407 admin]#
A search for nfs-ganesha-gluster
only brought me to obsolete builds:
nfs-ganesha
http://cbs.centos.org/koji/packageinfo?packageID=98
nfs-ganesha-2.1.0-7.el7 2014-10-01 10:45:45
http://cbs.centos.org/koji/buildinfo?buildID=126
which contains:
nfs-ganesha-2.1.0-7.el7.x86_64.rpm
nfs-ganesha-fsal-gluster-2.1.0-7.el7.x86_64.rpm
nfs-ganesha-debuginfo-2.1.0-7.el7.x86_64.rpm
So it appears that I am stuck at that unresolved dependancy.
Any suggestions will be much appreciated.
Thanks In Advance.
:-)
hi,
Quite a few groups in and around the CentOS Project are getting ready to
announce code, releases, images etc. so I thought it might be good to
get a draft of what a good-announcement looks like, as a template others
might ( or might not ) want to follow.
I've had a very brief crack at it here :
https://wiki.centos.org/SpecialInterestGroup/AnnouncingReleases
Everyone in the SIGs space should be able to edit that page, and
add/extend, please do so.
Or just leave comments and patches here on the list, and I'll merge them
into the page.
regards,
--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
hi,
Julien Pivotto is going to undertake bootstrapping the ConfigManagement
SIG, and I've setup a wiki page under the SIG space. We can use this
co-ordinate the initial proposal and also as a way to bring together and
document scope + deliverables from people who would be interested in
joining this effort.
config management is a core component of many infra setups around the
world these days, and i am sure we have a fair level of interest within
the existing SIGs as well as the existing contributor base. So everyone
lets get behind Julien and help with this effort.
He is putting together his initial thoughts at :
https://wiki.centos.org/SpecialInterestGroup/ConfigManagementSIG ; we
can use this centos-devel mailing list as a means of communication and
for questions etc.
Regards,
--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
hi folks,
we've now gotten to a point where we regularly have account requests for
various CentOS resources, to a point where its harder to track things
down constantly.
I'd like to move towards a schedule based admin cycle for the following
resources:
- cbs.centos.org
- ci.centos.org
- devcloud
Ideally, this would run through in a way to have the backlog cleared on
every alternate Monday, for the buildsystem meeting every alternate
Monday to confirm new-users onboarded and followup with any new-user
training we need to run through.
Note that every resource needs some level of support or sponsorship, so
folks requesting accounts should make sure that is in place, before the
next cycle.
ofcourse we would look into emergency and downtime situations as soon as
we are able to.
--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
Starting a new status thread for CentOS 7 POWER Little Endian. On Monday, Arrfab turned over the keys to a pairf of shiny new Fedora 21 ppc64le VMs running atop PowerKVM. I created a f21-ppc64le mock config and built a Linux from Scratch [1] toolchain with CentOS 7.1.1503 sources. This is necessary to jump back in time from Fedora 21 glibc-2.20 to CentOS 7 glibc-2.17. I then proceeded to build enough ppc64le.el7 rpms with the LFS toolchain to construct a minimal c7.01.01-ppc64le mock buildroot.
As of last night, the minimal c7.01.01-ppc64le buildroot is complete and I’m untangling circular dependencies in the CentOS 7.1.1503 source rpms. I’ve built 700 of 2523 source packages so 27% complete with this first pass.
Next, I’ll bootstrap java-1.7.0-openjdk and continue to loop through ppc64le rpm builds with mock. In the next 1-2 weeks, I should have 95+% of the source packages building for ppc64le. At which point we can create the first CentOS 7 ppc64le VMs and rebuild c7.01.02-ppc64le atop CentOS 7 instead of Fedora 21.
CentOS 7.1.1503 ppc64le Alpha images for the early adopters sometime after that.
[1] http://www.linuxfromscratch.org/lfs/view/stable-systemd/
On 11/10/15 03:21, Subhendu Ghosh wrote:
> It would also be useful if the repo definitions did not use
> ReleaseVersion to allow use by CentOS and other distroa.
let me see if we can parametrise those from the jenkins side of things -
should be possible, and we can default to something that works here for
the scl/cbs process.
regards,
>
> Sent from Nine <http://www.9folders.com/>
>
> *From:* Karanbir Singh <mail-lists(a)karan.org>
> *Sent:* Oct 10, 2015 6:29 PM
> *To:* centos-devel(a)centos.org; sclorg(a)redhat.com
> *Subject:* [scl.org] validating scls being built
>
> firstly, apologies for the cross post.
>
> I've setup an example to illustrate some very simple things we can do to
> validate a collection. In this case the vagrant collection.
>
> https://github.com/kbsingh/validate-vagrant-scl has the test script.
>
> It does 2 things:
> 1) makes sure all the rpms we expect to have in the repo are there.
> 2) it will install the collection, run a centos/7 vagrant box, and run
> the centos functional test suite inside the box. if this passes, we can
> assert that vagrant installed ok, was able to run a libvirt backed box
> properly, and was able to provide typical expected functionality.
>
> There maybe 100s more features of the collection we are not testing
> here, but that might not be needed if a simple baseline is established.
> And this test can be run, from triggers in ci.centos.org, watching the 3
> repos we care about for the vagrant collection ( ruby22 / ror41 and
> vagrant itself ).
>
> thoughts ?
>
>
> --
> Karanbir Singh
> +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
> GnuPG Key : http://www.karan.org/publickey.asc
>
> _______________________________________________
> SCLorg mailing list
> SCLorg(a)redhat.com
> https://www.redhat.com/mailman/listinfo/sclorg
>
--
Karanbir Singh, Project Lead, The CentOS Project
+44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS
GnuPG Key : http://www.karan.org/publickey.asc
firstly, apologies for the cross post.
I've setup an example to illustrate some very simple things we can do to
validate a collection. In this case the vagrant collection.
https://github.com/kbsingh/validate-vagrant-scl has the test script.
It does 2 things:
1) makes sure all the rpms we expect to have in the repo are there.
2) it will install the collection, run a centos/7 vagrant box, and run
the centos functional test suite inside the box. if this passes, we can
assert that vagrant installed ok, was able to run a libvirt backed box
properly, and was able to provide typical expected functionality.
There maybe 100s more features of the collection we are not testing
here, but that might not be needed if a simple baseline is established.
And this test can be run, from triggers in ci.centos.org, watching the 3
repos we care about for the vagrant collection ( ruby22 / ror41 and
vagrant itself ).
thoughts ?
--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc