Name: Richard Dawe
Member since: 2000-06-19 19:34:39
Last Login: 2008-04-26 12:47:18
Homepage: http://homepages.nildram.co.uk/~phekda/richdawe/
Notes:
I used to work on:
DJGPP: This is more than just a port of the GNU utilites to protected-mode DOS. I maintained a number of ports of GNU tools to DJGPP and was the release manager on the DJGPP 2.04 release for the alpha and first beta.
libsocket: This is a networking library which used Windows's low-level device drivers to provide DJGPP programs with the BSD sockets API.
pakke: This is a package manager for DJGPP, which has made using DJGPP a lot easier (for me, at least!).
Now I'm trying to decide what fresh, new and interesting stuff to find out about and work on.
rpm: Filtering dependencies differently for different subpackages
Recently I was trying to work out how to filter rpm Requires/Provides dependencies differently for different subpackages. I was trying to produce a subpackage that was the same as another subpackage, but stripping out some library dependencies. Call the one subpackage foo and the other foo-nodeps. (Don't ask why I was trying to do this.)
rpm has a way of hooking the dependency generation, as described in FilteringAutomaticDependencies at the Fedora wiki. This is pretty magical. You disable rpm's internal dependency generation. You can then override the default external dependency generation scripts (if you want). Normally rpm uses find-requires and find-provides in /usr/lib/rpm, or /usr/lib/rpm/redhat on some Red Hat or Red Hat-derived systems. If you do override the scripts, it's likely you'll want to call them and filter their output.
When you define your own dependency generation scripts, they are applied to all subpackages. There is no information passed to the script to indicate which package/subpackage it is being call for. You can pass arbitrary parameters to your custom find-requires/find-provides scripts. But there are no macros that you can use to pass that in as a parameter (%name is always the main package's name -- there's no %subpackage macro AFACIS).
A solution was to pass that information in via the filesystem. In the %install script I'd create a file per package. Something like this:
mkdir -p %{buildroot}/NOTINSTALLED
touch %{buildroot}/NOTINSTALLED/foo.ghost
touch %{buildroot}/NOTINSTALLED/foo-nodeps.ghost
Then in each package's file list I'd put the appropriate file:
%files ... %ghost /NOTINSTALLED/foo.ghost %files nodeps ... %ghost /NOTINSTALLED/foo-nodeps.ghost
The %ghost ensures that the file isn't installed, but is still passed to the find-requires/find-provides scripts. A custom find-requires script can then find out which subpackage it's being called for. Something like this:
cat > .files if (grep -q -E '^/NOTINSTALLED/foo-nodeps.ghost$' 2>/dev/null); then # Filter out dependencies on libfoo /usr/lib/rpm/find-requires | grep -v -E '^libfoo.so' else /usr/lib/rpm/find-requires fi
FileVault
I enabled FileVault home directory encryption on my work Macbook Pro the other day, which is running Mac OS X Tiger (10.4). I was a little bit hesitant about doing this, because of various horror stories about it not working, or performance being terrible. I made sure I had a proper backup, before starting the process.Syndicated 2008-01-12 08:50:47 (Updated 2008-01-12 08:53:13) from richdawe
Recycling Compact Flourescent Lightbulbs (CFLs)
I read in Scientific American that Compact Flourescent Lightbulbs (CFLs) contain mercury, and some US stores/states have recylcing programmes at stores or kiosks. I didn't realise they contained mercury, and probably would have just thrown them in the bin with my other rubbish. Links:
Compact Fluorescent Light Bulbs at energystar.gov
Compact fluorescent lamp at Wikipedia
Toxic Mercury In CFL Bulbs
lamprecycle.org (not much use here in the UK)
I had a look to see what's on offer in the UK. The "Recycle Now" website doesn't seem to contain any information about how to recycle CFLs. Greenpeace has an article about CFLs, which suggests I should be able to take them back to the retailer. Do I have to prove that I bought the bulb from the retailer in the first place?
File::ExtAttr 1.06, mab2ldif
I released File::ExtAttr 1.06 to fix building on Mac OS X. File::ExtAttr provides an interface to extended file attributes (meta-data) that's consistent across Linux, Mac OS X, *BSD, Solaris.
I also released mab2ldif, which takes a Mork-format address book (e.g.: as used by Thunderbird) and converts it into an LDIF file. You can import the LDIF file into Thunderbird. I wrote this to recover my old Thunderbird address book from an old computer that died. You can actually export the address book from Thunderbird into LDIF, but if Thunderbird won't run, you'll need this tool to get your data back.
richdawe @ 2007-11-04T10:23:00
I saw on Adam Leventhal's blog that Apple ship a DTrace provider for Perl with Leopard:
"Not only did Apple port DTrace, but they've also included a bunch of USDT providers. Perl, Python, Ruby -- they all ship in Leopard with built-in DTrace probes that allow developers to observe function calls, object allocation, and other points of interest from the perspective of that dynamic language."
It's also mentioned on Unix Technology page for Leopard.
I had a quick look to see if Apple had released any patches. I didn't find any -- at some point I should dig around their open source section, to see if it's included in that.
I did find OpenSolaris Bug ID 6355891 asking for Perl support to be added to DTrace.
richdawe certified others as follows:
Others have certified richdawe as follows:
[ Certification disabled because you're not logged in. ]
FOAF updates: Trust rankings are now exported, making the data available to other users and websites. An external FOAF URI has been added, allowing users to link to an additional FOAF file.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!