rBuild 1.2.6 is a maintainence release

• building packages now defaults to no-recurse. Recursion can still be enabled using the --recurse option. (RBLD-311)
• rbuild checkout --derive no longer throws an unhandled exception when called outside a product directory (RBLD-325)
• The rmake strictMode configuration is now set for builds (RBLD-328)

rMake 2.0.5 is a maintainence release

• rMake is now compatible with versions of Conary that implement the proxyMap configuration item. (CNY-3427)

• The copyInConfig configuration item now defaults to False (RMK-1052)
• Since Conary now de-duplicates proxy requests using file locking on individual changesets, rMake now defaults to increasing the open file limit for rMake itself. (RMK-1054)

Conary 2.1.22 is a maintainence release

• A bug introduced in Conary 2.1.21 that prevented `cvc cook` from functioning has been corrected. (CNY-3490) (CNY-3490)
• Fix an inconsistency between Conary and RPM databases when RPM fails to install a requested package. (CNY-3488)
• Rewrite derived package shadow creation code because the previous attempt to support capsules was fragile and frankly a bad idea. (RBLD-326)
• Fix exception when doing a repository cook when the recipe sources a multiurl of mirrors. (CNY-3485)

Conary 2.1.21 is a maintainence release

• The --no-recurse option is now allowed with the "conary migrate" command. This can be used to rebuild a system from a manifest file.
• A no-scripts option has been added. If set, capsule scripts, trove scripts, and tag scripts are skipped during an update. (CNY-3452)
• Conary now records in /var/log/conary the order in which RPM chooses to install encapsulated RPMs. (CNY-3460)
• When RPM fails to unpack a package when being invoked as non-root, Conary will now warn about the failure but will not fail the entire transaction. (CNY-3462)
• Conary now validates RPM capsule operations against the RPM database as early as possible to flag errors when they occur. (CNY-3455)

• Make negative openpgp key cache entries to avoid repeated server queries for keys which don't exist (CNY-3450) (CNY-3450)
• Process directory creation for other file types (CNY-3451)
• Fixed a repository crash when converting a cached changeset for an older client. (CNY-3453)
• The getCapsulesTroveList function was restored to sqldb for use in recreatedb.
• Fixed signing of packages with pycrypto 2.1 (CNY-3465)
• Fixed a bug which caused an internal server error when the same trove permission was applied to more than two roles. (CNY-3469)
• When multiple installed conary components shared an underlying RPM capsule removing one of those components would result in the conary database becoming out of sync with the rpm database (CNY-3470)
• Changesets can contain shared files where one is a diff and the other is not. The diff will be used (CNY-3483)

• Hotspot profiling hooks have been removed. (CNY-3250)
• added cksig script for verifying (and fixing) signatures in a repository
• Add argument to the API for cooking troves to allow someone to specify a changeset file instead of committing the changeset to the repository. (CNY-3466)
• The transport layer is now handling network errors more reliably. (CNY-3429)

As my kids are starting to want to "look for things on the internet", I started caring about what they might accidentally stumble onto, even in an appropriately supervised context.

I had vaguely heard about OpenDNS for some time, but had not really paid much attention to it. A few relatively recent articles on using it to make an internet connection somewhat more "family-friendly" caught my attention, and I finally signed up for a free account to try it out.

I have a local caching bind which forwarded to the nameservers that TWC provides to me (and to which I redirect all outgoing nameserver traffic via firewall rules), and I really haven't noticed nameservice being slow, so the "speed up your internet" advertising from OpenDNS wasn't ringing true. But the ability to filter out the worst of the sites dedicated to things that I think don't have a place in my home was interesting. So I signed up for a free account, changed a few lines in my bind configuration, and packaged and installed ddclient according to OpenDNS's instructions so that OpenDNS will continue to associate my home network with my home network settings on those rare occasions when my IP changes.

We weren't seeing lots of questionable content before the switch, so the fact that we've seen a total of two sites blocked since we signed up for the service is fine. It says that I can establish what I think are reasonable controls and it won't get in the way of normal activities.

Purely because I appreciate the service (I don't really care very much about saving statistics for longer), I signed up for a paid account. This service seems to me to be worth the $9.95/year.

A few days ago, OpenDNS rolled out a new free service called FamilyShield -- you can use a pre-configured set of filters without setting up any account at all merely by using 208.67.222.123 and 208.67.220.123 as your DNS servers (they include detailed instructions for how to do this on many different OS variants). This is exactly the same thing you'd get by signing up for their service and enabling the same set of filters for your account, so it's easy enough to upgrade to their free service if you want to customize the filters -- you just sign up for a free account, change the IP address you use for the resolvers, choose the filters you want, associate your IP address with your account, and (if you, like most people, have a dynamic IP) set up one of the many dynamic DNS clients available (they list several) to keep that association up to date.

I'm just a satisfied customer.