On 08/30/16 10:20, Jonathan Perkin wrote:
* On 2016-08-30 at 15:44 BST, Jason Bacon wrote:On 08/30/16 03:21, Jonathan Perkin wrote:* On 2016-08-29 at 15:12 BST, Jason Bacon wrote:I found the following page, which appears to contain a rather Old package set from 2014: https://pkgsrc.joyent.com/install-on-linux/ 1) Is anyone out there is presently working on bulk builds for EL? If so, I would love to coordinate with you so we don't waste our time on duplicated effort.Yes, I've continued these builds for trunk - I just haven't gotten around to updating the above page and announcing them. You can see the results of these daily bulk builds on the pkgsrc-bulk@ list, e.g.: http://mail-index.netbsd.org/pkgsrc-bulk/2016/08/30/msg013085.html http://mail-index.netbsd.org/pkgsrc-bulk/2016/08/28/msg013079.html 32-bit and 64-bit take it in turns each day, just in case a build takes >24 hours. The packages are synced to: https://pkgsrc.joyent.com/packages/Linux/trunk/2) Roughly how long does it take to do a bulk build of the entire tree on a single high-end server? I was thinking of doing builds on one of our production clusters, but I'm leaning against it due to some issues with leakage of Yum packages into certain builds. I think it would be safer to do the builds on a dedicated server with a minimal CentOS installation.The above builds are performed on 7-core 7GB KVM instances in the Joyent cloud, using 7 concurrent chroots, and are generally done in less than 12 hours. I think a full from-scratch build takes around 24 to 30 hours. Our KVM implementation definitely isn't optimal, so you will probably see faster builds than this on native hardware, as well as being able to bump up the concurrency.Fantastic, thanks! So I poked around your site a bit and found bootstrap-trunk-x86_64.tar.gz. I then attempted to substitute it into the instructions at https://pkgsrc.joyent.com/install-on-linux/ The installation breaks itself the first time I run pkgin upgrade, full-upgrade, or install. I attached the script that produced the output below as well as pkg_install-err.log.Yeh, I need to update the bootstrap kit to include the new GPG key. I'll let you know when I've done this so you can test the packages for me prior to announcing them. Thanks,
Great, I'll look forward to working with this. A couple more things: 1) Will you be posting quarterly snapshots for CentOS as well as trunk?2) Is it possible to "relocate" packages using pkgin, or are they confined to the prefix set in the bootstrap process? I don't believe they can be relocated, but I'd love to be told I'm wrong.
One of the beautiful features of pkgsrc for research support is the ability to easily install multiple pkgsrc trees. It's important for use to leave old versions of software in place for several years so that researchers have continuity over long projects, can reproduce results exactly when renewing a grant, etc. Hence, we have multiple snapshots in place at any time, e.g. /sharedapps/pkg-2015Q3, /sharedapps/pkg-2016Q1, etc. When someone needs a newer version of something, we just bootstrap a whole new tree and leave the old ones alone.
If I have to do my own bulk builds for each of these prefixes, that's fine, but it seems wise to ask before expending the effort.
Regardless, having binary packages available for /usr/pkg will help us a lot. I maintain a local installation on each machine here for system software and basic user tools like text editors, etc.
Regards,
Jason
--
Those who spend their lives in the shallows see their whole world in turmoil
every time the wind blows.
Those who explore the depths see only ripples at the surface of an otherwise
serene world.