So linux-flashplugin has been removed. So what? Stop bitching already.
cvs -d /home/ncvs co -D "1 april 2006" -d linux-flashplugin6 ports/www/linux-flashplugin6
Enough said.
]]>It started after a regular Xorg upgrade. According to various mailing lists, that particular upgrade caused similar problems to a lot of people, so I tried different suggested fixes. No luck.
A bit later, Xorg on FreeBSD was modified to fix the reported problems. But the upgrade did not fix my problem.
Eventually I came to a realization that it is likely that the problem is not with the mouse driver or with any other part of Xorg. Rather, it was a problem with synergy client interaction with the new xcb. I even found a problem report with a supposed fix to the problem. By the time I’ve found it, the fix was committed to the synergy port, and was subsequently rolled back because it lead to other problems. I tried the patch in the PR anyway. Still did not help me.
Not wanting to spend too much time on this, I was coping with the delays and only occasionally, when annoyed more than usual, was trying to find another fix. Unsuccessfully, I must add, until this morning, when I discovered synergy+, a maintenance fork of the original synergy. I was not aware that synergy+ is basically a drop-in replacement to synergy, the binaries having the same names as in the original. Better still, synergy+ client works just fine with the original synergy server. So I’ve decided to give it a shot, removed the synergy package, and installed the synergy+ port. Voila, the freezes are gone. I am a happy camper now.
]]>sysutils/smartmontools port
smartctl
stopped working if run as non-root.
I did not investigate whether it is because of the change
in the way smartctl operates,
or whether it just stopped to be setuid root.
Normally I don’t mind going root to run smartctl by hand,
but it presents a bit of a problem for the hddtemp_smartctl
Munin
plugin.
One possible solution is to add the munin user to the operator group,
add the following two lines to /etc/devfs.conf:
perm ata 0660
perm xpt0 0660
And finally, run sh /etc/rc.d/devfs restart.
Being the dummy that I am, I only thought about a simpler solution
when composing this post: just add user root into the [hddtemp_smartctl] section
of your munin/plugin-conf.d/plugins.conf file.
Besides being simpler, this method has an added advantage: an updated
version of the
sysutils/munin-node port
can easily incorporate this change.
Dag-Erling: hint, hint. :-)
The tags were not created by users but were
instead generated from a couple of fields
taken from every
port’s Makefile,
so it was not exactly a “social” software.
There was some limited amount of discussion on FreeBSD mailing lists, and a publicly accessible readonly SVN repository was created by my friend Erwin, but the overall interest was rather low.
Over time I moved on and basically stopped working on the project, but recently I had an idea - not exactly to re-surrect it, but to make it more easy for people who are interested to contribute.
Enter port-tags at github.
Github is a tool
to host git repositories
of your open-source projects.
Anybody can easily clone your repository,
fork it completely, or submit their
changes back to you.
I only started using it today,
so I cannot say much about its features
and how convenient they are,
but from what I’ve heard,
it is very very nice.
So, if you are interested,
and have got round tuits to spare,
please hack on port-tags - maybe
some good will eventually come out of it.
recoverdisk(1) utility.
Since it turned out to be a life- (well, disk-) saving device, and it is covered by the beer-ware license, I definitely owe phk a beer.
Yesterday morning I discovered that my server is down. After traveling to the server room (there is no remote console) and pretending that my index finger is square in its cross-section, my investigation showed that there is something fishy with the system disk (which is backed up but not mirrored).
Namely, there are bad blocks, and periodic scripts that run at night touch some of them, which leads to bad things.
Now, the first thing I did was to order a replacement disk. The problem was that it won’t arrive until the beginning of next week and I want the box up and running now. Even worse, during the weekend I am going to be in Stockholm for the Nordic Perl Workshop (oh, and by the way I still have a presentation to prepare), and thus won’t be able to fix things that require my presence on-site.
After asking around, I got pointed in the direction of recoverdisk(1)
by Phil.
Thankfully, recoverdisk /dev/ad4 told me exactly how many
bad blocks there are (one) and what offsets they are at.
The next step was to make the on-disk controller to remap the block to one of the good reserve sectors on the disk. While I am sure that there are programs that will do just that, I am not aware of any that run on FreeBSD.
Besides, having the offsets, it was a trivial task to quickly create a simple one-shot program that writes something to the bad block, so that the disk will have an opportunity to remap the sector all by itself.
The only problem I had with this was that I could not open(2)
the raw disk for writing while any partitions were mounted
on it. I was ready to move the disk to another box to
run the program there,
but Flemming has helpfully told me that doing
sysctl kern.geom.debugflags=16 will do the trick. And it did.
Thanks, Flemming!
After this there are four more steps - run recoverdisk again
to make sure everything’s fine, run fsck on all partitions,
put the box online, and move
the system to the new and shiny disk when it finally arrives.
While this last step will have to wait a bit more, the fact that you are reading this shows that everything else worked.
I do realize that the primary purpose of the recoverdisk(1)
is to salvage the data from media that has gone hopelessly bad.
Nevertheless, I think that my example shows that it is pretty darn
useful in other cases as well.
Several people helped me along the way. I have not yet mentioned Lars, who did some heavy lifting, and Kristoffer for doing the network magic with subnet routing when the box was moved to another, closer location.
Lessons learned:
remote console is useful;
mirroring the system disk is essential.
Open question: what does phk do with all the beers he is getting when I know for a fact that he does not drink much?
]]>I thought it was a great idea and started including a link to a CPAN’s distribution Changes file in my commits some time ago.
What I did not like was that those links looked like this:
http://search.cpan.org/src/JESSE/Template-Declare-0.27/Changes
FreeBSD’s commit messages are preserved in our repository and mail archives forever, for a suitable definition of “forever”. On the other hand, CPAN authors are encouraged to clean up old and obsolete versions promptly.
Thus there is a discrepancy between expected time of life of the link in the commit message and the link contents.
While older CPAN distributions can still be found on BackPAN, it only provides links to tarballs and not individual files like Changes.
Luckily, it turns out that version-less links like
http://search.cpan.org/dist/Template-Declare/Changes
work just fine, redirecting to the most recent version of the file. This is acceptable, since Changes is expected to be a prepend-only file, so the information the commit message was trying to link to can (almost) always be found there.
]]>A quick search turned up this, which, from the look of it, in order for it to work requires every feed to be explicitly marked with a tag which is set up as public.
This by itself is rather cumbersome, and you have to remember to do that for every new feed you subscribe to, otherwise you’ll defeat the purpose of making periodic backups in the first place.
Luckily, there is a better solution. There is a nice little module on CPAN, WebService::Google::Reader by gray, which uses an unofficial Google Reader API to do various nifty things with your Google Reader subscription, including OPML export.
This means that after installing the module you can simply put the following command into your crontab (only command itself is shown, see crontab(5) manual page to find out what else you will want to put in there):
env GOOGLE_USERNAME=your-username-typically@gmail.com \
GOOGLE_PASSWORD=your-user-password \
perl -MWebService::Google::Reader -e \
'print WebService::Google::Reader->new(
username => $ENV{GOOGLE_USERNAME},
password => $ENV{GOOGLE_PASSWORD})->opml' \
> /where/to/put/greader.opml
You will have to make the above to be one long line to satisfy crontab syntax, and of course remember to use a real username, password, and the path to the resulting OPML file.
Unfortunately, the most recent version
of the module (which is 0.03 at the time of this writing)
has a minor bug which prevents
the opml() method from working correctly.
So you will need to do a little patching.
Before installing the module,
edit the source file lib/WebService/Google/Reader/Constants.pm,
look for a string subscribtions,
and fix the spelling
(finding correct spelling is left as an exercise for the reader).
Then proceed installing the module as usual.
Hopefully, this step won’t be necessary in a couple of days’ time when a new version of the module is released.
If you are a FreeBSD user like myself,
you may choose instead to
fetch a skeleton of the port of the module.
Unpack it in /usr/ports/www/
and install it as you would any other port.
I intend to add the port to the ports collection as soon as our current ports freeze is over.
Enjoy!
]]>
So linux-flashplugin has been removed. So what? Stop bitching already.
cvs -d /home/ncvs co -D "1 april 2006" -d linux-flashplugin6 ports/www/linux-flashplugin6
Enough said.
]]>
If you are bored and think about making yet another CPAN module into a FreeBSD port, you might find this useful.
Get yourself a local CPAN mirror. Don’t worry, you won’t need the whole deal, the most recent versions of every module will suffice. This boils down to just under 700 MB. It’ll take a while the first time around, but after that it’ll require less time than your regular /home/ncvs updates.
Install devel/p5-CPAN-Mini port, then run
minicpan -l ~/share/CPAN/ \
-r ftp://ftp.funet.fi/pub/languages/perl/CPAN/ -p
Here ~/share/CPAN is a directory of your choosing. Similarly, choose a CPAN mirror closest to you instead of ftp.funet.fi.
Install devel/p5-File-Random port. Then fetch this script, and modify the hard-coded path to CPAN.
Each time you run it, it will present you with some recent CPAN module that does not yet exist in the ports collection.
Please don’t forget to submit a PR. ;-)
There is no step 3.
]]>
Yesterday I finally found time to wade through some of my outdated p5 ports. It is obvious that the monkey poo job of testing them with all three perls can be automated, but I never got really fed up with the procedure before. So I wrote yet another port-related automation script, which I’d like to describe here.
First, a little about my setup.
I use three jails for testing. There is a port58 jail which has lang/perl5.8 installed. There is a ports56 jail (with lang/perl5). And there is a j4 jail, which is a bit of a strange beast, since it is a 4.11 i386 jail (with system perl 5.005_03), so it took some tinkering to make that work on my 5.4 amd64 host system.
All three jails sit on a private subnet, and I can ssh -l root to them using my ssh key. They get populated with a freshly cvsupped ports collection via cpdup, a nifty little tool by Matt Dillon.
So, the manual procedure is basically:
The script to automate this task is called test-port. It is somewhat hackish, being a quick and dirty job, but it is usable.
Test-port makes use of other scripts, which I wrote over time and was using extensively, namely
build_mtree for creating an mtree of a jail.
plist for checking the current file structure against a tree created with build_mtree and generating a plist delta.
cpdup-port for copying a port or the whole port tree to the jails.
cpport for listing recently modified files (useful when committing stuff).
If you think you can have a use for those scripts, be my guest. If you make any improvements to them, I would like to hear about it — they do need improvements (in particular, they are not usable without modifications outside of my setup).
]]>
54 messages and counting, 4 commits (including one backout), and all I wanted was to rename patchfiles with the percent sign in them to something more sensible!
A hint to the next would-be bikeshed initiator: misc/kde3-i18n-sr@Latn port.