Build Nodes --
New Build Nodes are configured and active. Old virtual build nodes are out of the cluster build53 [is: x86 x86_64] (36 slots) build54 [is: x86 x86_64] (36 slots) build55 [is: x86 x86_64] (36 slots) build56 [is: x86 x86_64] (36 slots) Sync of repos -- Wrote a simple rsync scripts for Fedora and CentOS and dropped them in /home/mirror/bin so we can cron the syncs. Fedora 20 -- Processing of Fedora continues. It was very slow going until this week when I took time to make mirrorball a little more efficient. There have been a few checksum errors with rpms but other than that chugging along with processing Fedora 20. CentOS 7 -- Started syncing the CentOS 7 beta today. The plan is to use Fedora 20 to import the beta once we finish processing Fedora 20. The beta will go on a beta label and hopefully I will have it working well enough to start the CentOS 7 import once it is available. Plan on importing centosplus, extras, and fasttrack to separate labels. Mirrorball updates -- Mirrorball is the python code we use to update manifests for encapsulated distros. It looks for packages to update by comparing the yum repo to the conary repo. If a pkg is newer in the yum repo then on the conary label it updates the package manifest, commits, and sends it to the list of packages to be built. I am pretty sure I properly fixed mirrorball's long pause every time it started on a new chunk of updates To be clear the pause in mirrorball was silliness on my part. I break the update up into 96 packages at a time... this allows me to load the 4 build nodes evenly with a build per real processor. Every time mirrorball swung around to do another 96 it makes a Conary Source to rpm Source map... it was taking a long time (like 30 minutes). Turns out when you instantiate the conaryhelper to do this it clears the cache so it was rebuilding the sourceMaps from the label every 96 packages... it was never a problem until Fedora and its 65000 pkgs. No need for that during a single update run so now we do it at the beginning of the update and pass the sourceMaps along until all the updates are processed then if we have to do anything like order or build a group after the update the cache gets cleared and rebuilt (hopefully with the latest troves we built) -- Brett C. Smith [email protected] Sr Software Developer Platform Deployment Technologies (919)531-6635 -- x16635 _______________________________________________ Foresight-devel mailing list [email protected] https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
