>>Thanks for the update! >> >>How will we handle repositories like RPMFusion, EPEL, ELREPO and REMI? >> >>// Roger
I plan on using separate labels for each. There will be a separate mirrorball config and job for each import. --Brett 31 juli 2014, Brett Smith <[email protected]> skrev: > 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> > _______________________________________________ Foresight-devel mailing list [email protected] https://lists.foresightlinux.org/mailman/listinfo/foresight-devel _______________________________________________ Foresight-devel mailing list [email protected] https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
