Difference between revisions of "Koji Testbed"
From PDP/Grid Wiki
Jump to navigationJump to search| (9 intermediate revisions by 2 users not shown) | |||
| Line 162: | Line 162: | ||
A Koji build will first do a <nowiki>buildSRPMFromSCM</nowiki> job, which will run mock to generate a buildroot, inside of which 'yum groupinstall srpm-build' is run. Later, a <nowiki>buildArch</nowiki> job does the actual building, and here mock runs 'yum groupinstall build'. | A Koji build will first do a <nowiki>buildSRPMFromSCM</nowiki> job, which will run mock to generate a buildroot, inside of which 'yum groupinstall srpm-build' is run. Later, a <nowiki>buildArch</nowiki> job does the actual building, and here mock runs 'yum groupinstall build'. | ||
These groups must be created by us first, and populated with package names that we need to have available at this stage. | These groups must be created by us first, and populated with package names that we need to have available at this stage. | ||
| − | + | koji add-group epel5-build build | |
| − | koji add-group epel5- | + | koji add-group epel5-build srpm-build |
| − | koji add-group epel5- | ||
They need to be populated. Clone from a typical value for the Fedora Koji systems, e.g. | They need to be populated. Clone from a typical value for the Fedora Koji systems, e.g. | ||
| Line 173: | Line 172: | ||
koji add-group-pkg epel5-build srpm-build `koji -s http://koji.fedoraproject.org/kojihub/ | koji add-group-pkg epel5-build srpm-build `koji -s http://koji.fedoraproject.org/kojihub/ | ||
list-groups dist-5E-epel-build srpm-build | tail -n +2 | cut -d: -f1 | grep -v fedpkg` | list-groups dist-5E-epel-build srpm-build | tail -n +2 | cut -d: -f1 | grep -v fedpkg` | ||
| + | |||
| + | As of EPEL7, there's fedpkg-minimal which should be safe (it only requires wget). | ||
Add external repositories to populate the buildroot. | Add external repositories to populate the buildroot. | ||
| Line 194: | Line 195: | ||
This does not hold true for EPEL branches, which are not inheriting from one another. | This does not hold true for EPEL branches, which are not inheriting from one another. | ||
| − | for i in | + | for i in 27 28 ; do |
prev=`expr $i - 1` | prev=`expr $i - 1` | ||
koji add-tag --parent f$prev f$i | koji add-tag --parent f$prev f$i | ||
| − | koji add-tag --parent f$prev-basedeps f$i-basedeps | + | koji add-tag --parent f$prev-basedeps f${i}-basedeps |
| − | koji add-tag --parent f$i --parent f$i-basedeps --arches "i386 x86_64" f$i-build | + | # koji add-tag --parent f$i --parent f$i-basedeps --arches "i386 x86_64" f${i}-build |
| + | koji add-tag --parent f$i --parent f${i}-basedeps --arches "x86_64" f${i}-build | ||
for j in candidates testing release; do | for j in candidates testing release; do | ||
| − | koji add-tag --parent f$i f$i-$j | + | koji add-tag --parent f$i f${i}-$j |
done | done | ||
| − | koji add-external-repo -t f$i-build dist-f$i-base http://mirror.nl.leaseweb.net/fedora/linux/releases/$i/Everything/\$arch/os/ | + | koji add-external-repo -t f${i}-build dist-f${i}-base http://mirror.nl.leaseweb.net/fedora/linux/releases/${i}/Everything/\$arch/os/ |
| − | koji add-target f$i f$i-build $i-candidates | + | # '''NOTE''': up to 27, we should leave out the ''Everything'' for the updates |
| + | koji add-external-repo -t f${i}-build dist-f${i}-updates http://mirror.nl.leaseweb.net/fedora/linux/updates/${i}/Everything/\$arch/ | ||
| + | koji add-target f$i f${i}-build f${i}-candidates | ||
| + | # '''NOTE''': probably need to add priorities to the parents, e.g. using something like | ||
| + | koji edit-tag-inheritance --priority 2 f${i}-build f${i}-basedeps | ||
| + | koji add-tag-inheritance --priority 1 f${i}-build f${i} | ||
done | done | ||
| Line 496: | Line 503: | ||
We've seen the weird situation that the connection between the bridge and the server was semi-severed: the bridge still showed the connection in the output of netstat, but the server lost the connection. The resolution is to restart the server. If the bridge needs to be restarted, the server also needs a restart thereafter. | We've seen the weird situation that the connection between the bridge and the server was semi-severed: the bridge still showed the connection in the output of netstat, but the server lost the connection. The resolution is to restart the server. If the bridge needs to be restarted, the server also needs a restart thereafter. | ||
| + | |||
| + | UPDATE: the cause of this problem lies with the connection being too quiet. Without keepalive the connection will be dropped. It's the stateful firewall's fault. | ||
