unsigned long geek = random(); » pkgsrc

Re-bootstrapping pkgsrc

Michael-John Turner — Sat, 26 Jul 2008 10:43:11 +0000

pkgsrc doesn’t officially support re-bootstrapping once it’s been installed (ie updating the core packages by doing a fresh bootstrap). There is a way to force one by removing a few core packages first though:pkg_delete -ff bootstrap-mk-files bmake tnftp pax pkg_install cd /usr/pkgsrc/bootstrap ./bootstrap

As long as the fresh bootstrap is done using the same parameters as used originally (prefix, database directory, etc), everything should work as before.

I tested this a short while ago on an OS X 10.5 system using a pkgsrc -current tree and it worked perfectly.

pkgsrc on FreeBSD/sparc64 6.2

Michael-John Turner — Mon, 16 Jul 2007 17:49:44 +0000

Although FreeBSD is a platform supported by pkgsrc, only i386 supported is explicitly mentioned and the most recent bootstrap binaries are for FreeBSD/i386 5.3. Being the adventurous chap I am, I decided to bootstrap from source on my dual CPU Ultra 60 running FreeBSD/sparc64 6.2. In true pkgsrc style, it Just Worked. Since bootstrapping, I’ve build a number of fairly large packages without problem: zsh, ncurses, vim, postfix, perl.

Why pkgsrc and not ports on a FreeBSD system? Well, I have a finely tuned pkgsrc environment that builds packages with my set of defaults (MIT Kerberos support, for example), so I decided to stick with what works well for me.

South African pkgsrc distfiles mirror

Michael-John Turner — Tue, 26 Dec 2006 10:11:05 +0000

A few weeks ago I contacted Internet Solutions and they are now kindly hosting a local pkgsrc distfiles mirror. To use it, simply add the following to your /etc/mk.conf:
MASTER_SITE_OVERRIDE=ftp://ftp.is.co.za/NetBSD/packages/distfiles/

If a file isn’t found at the local mirror, the pkgsrc fetch Makefile target will fetch it from another (non-local) mirror.

CVS repository change

Michael-John Turner — Thu, 25 May 2006 04:23:06 +0000

Over the past few weeks SourceForge.net has been moving projects from cvs.sf.net to projectname.cvs.sf.net. Not wanting to delete my currently checked out copy of pkgsrc-wip and check out again, I needed to update CVS/Root in each checked out directory. Neil gave me this useful snippet to accomplish exactly this:find . -type f -name "Root" | grep "/CVS/" | xargs sed -i -e 's/cvs.sf.net/pkgsrc-wip.cvs.sf.net/'

It assumes a sed which supports the -i option – NetBSD’s doesn’t, so I used perl -i -p -e instead (I could also have installed textproc/gsed from pkgsrc, but I already had perl installed).

Firefox is not bloated

Michael-John Turner — Mon, 17 Apr 2006 19:51:37 +0000

Today I had to rebuild Mozilla Firefox due to the release of 1.5.0.2. Unfortunately, due to my choice of platform (NetBSD/alpha), I have to build my own binary from scratch and can’t just do a delta binary update. The build timings on a 500Mhz EV56 AlphaServer 800:real 608m54.243s user 507m15.788s sys 77m30.249s

Yes, it took 10 hours to build a web browser…

Lisp for NetBSD/sparc64 redux

Michael-John Turner — Mon, 13 Feb 2006 19:27:27 +0000

Sometimes I love being proven wrong, and this is one such occasion. As a follow-up to my earlier post, a few people have pointed out to me that Embedded Common Lisp (ECL) works on NetBSD/sparc64. Yay!

There is a package in pkgsrc-wip. It didn’t compile cleanly on my -current system (it includes rather than ), but I’ll submit a patch to the maintainer to fix that.

fluxter

Michael-John Turner — Mon, 13 Feb 2006 19:07:38 +0000

Yesterday I discovered a neat piece of software to complement my Fluxbox desktop – fluxter. It’s a pager that’s faster than bbpager, can be embedded in the slit and tracks the style of the current theme.

I’ve commited a package to pkgsrc-wip.

No Lisp for NetBSD/sparc64

Michael-John Turner — Tue, 07 Feb 2006 21:35:22 +0000

One of the disadvantages of using a slightly less mainstream CPU architecture: there’s no Lisp interpreter for NetBSD/sparc64 available in pkgsrc. Not even DrScheme compiles.

pkgsrc and CPU specific optimizations

Michael-John Turner — Mon, 06 Feb 2006 04:56:20 +0000

For a while now I’ve been using devel/cpuflags to optimize my pkgsrc-built binaries. It determines the best compiler flags based upon the current CPU type, thereby creating a binary optimized for the current CPU. It’s a little “rice“, but for certain packages, like OpenSSL, it can make quite a difference (and yes, I know that for the majority of software on the majority of CPUs it won’t make any noticeable difference). To make package organization easier, I’ve made a few additions to my mk.conf(5) to group my packages by target CPU type.

To call cpuflags for every build, I have the following in /etc/mk.conf (my LOCALBASE is /usr/local):.sinclude "/usr/local/share/mk/cpuflags.mk" CPUTYPE:=`/usr/local/bin/cpuflags | sed 's/-mcpu=//'`
The second line sets the value of the CPUTYPE variable to the CPU type we’re optimizing for (for example, “supersparc” for SuperSPARC CPUs).

Packages are then installed into the following location:PACKAGES?=${WRKOBJDIR}/packages/${OS_VERSION}/${MACHINE_ARCH}/${CPUTYPE}
This installs packages into directories based on the operating system version, machine architecture and target CPU. For example, a target directory could be “packages/3.0_STABLE/sparc/supersparc”. Works nicely when one has a number of different architectures and target CPUs.