Luchesar ILIEV Luchesar ILIEV databases/gdbm 1.8.3 to 1.9.1 upgrade problems Luchesar ILIEV https://www.ideaconsult.net/web/luchesar/blogs/-/blogs/databases-gdbm-1-8-3-to-1-9-1-upgrade-problems 2011-09-12T20:34:34Z 2011-09-12T20:20:22Z <p> Today, the <a href="http://www.freshports.org/databases/gdbm/">gdbm</a> version in FreeBSD's ports has been updated to 1.9.1. After the upgrade, you might notice that some programs (notably, Apache, subversion, git) fail with the following message:</p> <p> <code>/libexec/ld-elf.so.1: Shared object "libgdbm.so.3" not found, required by "&lt;programname&gt;"</code></p> <p> The reason for this behaviour is that the version of libgdbm has been bumped from 3 to 4, ie, there's now <code>libgdbm.so.4</code> instead of<code> libgdbm.so.3</code> in<code> /usr/local/lib</code>. The solution is simple, albeit perhaps somewhat time consuming on a desktop system with a lot of packages that depending on gdbm:</p> <p> <code>portupgrade -frv gdbm-1\*</code></p> <p> or</p> <p> <code>portmaster -r gdbm-1\*</code></p> <p> A few ports also have libgdbm.so.3 hardcoded in their Makefiles. At least with net/avahi-app and audio/pulseaudio there seem to be no harmful effects from fixing their Makefile (where LIB_DEPENDS is defined, gdbm.3 needs simply to be replaced by gdbm.4).<br />  </p> Luchesar ILIEV 2011-09-12T20:20:22Z ImageMagick fails with "error: expected '#pragma omp' clause before 'omp_throttle'" Luchesar ILIEV https://www.ideaconsult.net/web/luchesar/blogs/-/blogs/imagemagick-fails-with-error:-expected-pragma-omp-clause-before-omp_throttle 2011-10-14T02:19:17Z 2011-04-02T17:06:41Z <p> If you try to upgrade or install ImageMagick on FreeBSD with the <code>IMAGEMAGICK_OPENMP</code> option enabled, you might encounter the following error:</p> <p> <code>magick/composite.c: In function 'TextureImage':<br /> magick/composite.c:2776: error: expected '#pragma omp' clause before 'omp_throttle'<br /> magick/composite.c:2824: error: expected '#pragma omp' clause before 'omp_throttle'<br /> gmake[1]: *** [magick/magick_libMagickCore_la-composite.lo] Error 1<br /> gmake[1]: *** Waiting for unfinished jobs....<br /> gmake[1]: Leaving directory `/usr/ports/graphics/ImageMagick/work/ImageMagick-6.6.7-10'<br /> gmake: *** [all] Error 2<br /> *** Error code 1</code><br /> <br /> The solution is pretty simple: use newer version of GCC than the one in base (4.6 from ports is confirmed to do the job), e.g.</p> <p> <code># cd /usr/ports/graphics/ImageMagick &amp;&amp; USE_GCC=4.6 make</code></p> <p> <strong>2011-10-14:</strong> That turned out to be rather n<span class="st">aïve interpretation. The problem seems to be caused by devel/ccache, although why exactly it's happening is a matter of further investigation. In addition, merely using CCACHE_RECACHE doesn't help for some reason; one has to use CCACHE_DISABLE or, better yet, entirely remove ccache from PATH to avoid the issue. The reason why using different gcc version helps is simple: it forces ccache to not use the cached results. So, again, the easiest solution is simply to disable ccache for this specific build.</span></p> Luchesar ILIEV 2011-04-02T17:06:41Z Subclipse fails with org.eclipse.swt.SWTException: Invalid thread access Luchesar ILIEV https://www.ideaconsult.net/web/luchesar/blogs/-/blogs/subclipse-fails-with-org-eclipse-swt-swtexception:-invalid-thread-access 2011-03-14T19:17:14Z 2011-03-14T19:01:07Z <p> I encountered this problem while trying to checkout Liferay's source in Eclipse, using the Subclipse plugin. The manifestation was as follows:</p> <p> * anonymous access to the SVN required empty password; saving of the empty password didn't seem to work;<br /> * on pressing 'Finish' in the wizard, either Subclipse, or the whole Eclipse would give an error message, which presents itself in the log files as:</p> <blockquote> <pre> !ENTRY org.eclipse.core.jobs 4 2 2011-03-14 20:47:56.033 !MESSAGE An internal error occurred during: "SVN Checkout". !STACK 0 org.eclipse.swt.SWTException: Invalid thread access at org.eclipse.swt.SWT.error(SWT.java:4083) at org.eclipse.swt.SWT.error(SWT.java:3998) at org.eclipse.swt.SWT.error(SWT.java:3969) at org.eclipse.swt.widgets.Widget.error(Widget.java:466) at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:404) at org.eclipse.swt.widgets.Control.isVisible(Control.java:3175) at org.eclipse.swt.widgets.ProgressBar.timerProc(ProgressBar.java:276) at org.eclipse.swt.widgets.Display.windowTimerProc(Display.java:4378) at org.tigris.subversion.javahl.SVNClient.list(Native Method) at org.tigris.subversion.javahl.SVNClient.list(SVNClient.java:201) at org.tigris.subversion.javahl.SVNClient.list(SVNClient.java:187) at org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.getList(AbstractJhlClientAdapter.java:332) at org.tigris.subversion.subclipse.core.commands.CheckoutCommand.basicRun(CheckoutCommand.java:100) at org.tigris.subversion.subclipse.core.commands.CheckoutCommand$1.run(CheckoutCommand.java:222) at org.tigris.subversion.subclipse.core.SVNProviderPlugin$6.run(SVNProviderPlugin.java:497) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975) at org.tigris.subversion.subclipse.core.SVNProviderPlugin.run(SVNProviderPlugin.java:492) at org.tigris.subversion.subclipse.core.commands.CheckoutCommand.run(CheckoutCommand.java:220) at org.tigris.subversion.subclipse.ui.operations.CheckoutAsProjectOperation.execute(CheckoutAsProjectOperation.java:99) at org.tigris.subversion.subclipse.ui.operations.CheckoutAsProjectOperation.execute(CheckoutAsProjectOperation.java:68) at org.tigris.subversion.subclipse.ui.operations.SVNOperation.run(SVNOperation.java:89) at org.eclipse.team.internal.ui.actions.JobRunnableContext.run(JobRunnableContext.java:144) at org.eclipse.team.internal.ui.actions.JobRunnableContext$ResourceJob.runInWorkspace(JobRunnableContext.java:72) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) </pre> </blockquote> <p> According to <a href="http://subclipse.tigris.org/wiki/JavaHL#head-3a1d2d3c54791d2d751794e5d6645f1d77d95b32">this wiki article</a>, the problem is with GNOME keyring. The proposed solution worked flawlessly; hence, I quote it here:</p> <blockquote> <p class="line874"> <em>There is currently a bug in the new support for GNOME keyring in Subversion 1.6. It works OK when using the command line, but not when other users of the libraries use it. Until this is fixed, you can workaround the problem by turning off this feature. To do this, open the file ~/.subversion/config and add the following:</em></p> <pre> [auth] ### Set password stores used by Subversion. They should be ### delimited by spaces or commas. The order of values determines ### the order in which password stores are used. ### Valid password stores: ### gnome-keyring (Unix-like systems) ### kwallet (Unix-like systems) ### keychain (Mac OS X) ### windows-cryptoapi (Windows) password-stores = </pre> <p></p> <p><em>The empty value for "password-stores" disables the feature. Passwords will be stored in plain text in the auth folder as with all previous version of Subversion.</em></p> </blockquote> Luchesar ILIEV 2011-03-14T19:01:07Z Tip of the day: bash-completion and SSH Luchesar ILIEV https://www.ideaconsult.net/web/luchesar/blogs/-/blogs/tip-of-the-day:-bash-completion-and-ssh 2011-03-06T12:22:30Z 2011-03-06T12:13:34Z <p> <a href="http://www.freshports.org/shells/bash-completion/">shells/bash-completion</a> is arguably the best friend of any lazy system administrator (as long as you're not hard-core FreeBSD fan enough to stick to <a href="http://www.tcsh.org">tcsh</a>). Did you know that it was actually 'completing' also the ssh(1) and scp(1) commands?</p> <p> First of all, it is able to auto-complete the host name, as long as it is present in ~/.ssh/known_hosts. But, even more impressively, it also completes the directory and file names of the remote host - at the expense of some ssh traffic, of course.</p> <p> And a word of warning here: if you enter wrong hostname, and then try to auto-complete a directory or file name, expect your shell to freeze for some time, while bash-completion is desperately trying to connect to the host.</p> Luchesar ILIEV 2011-03-06T12:13:34Z Default Python in FreeBSD changes from 2.6 to 2.7; problems with upgrade. Luchesar ILIEV https://www.ideaconsult.net/web/luchesar/blogs/-/blogs/default-python-in-freebsd-changes-from-2-6-to-2-7-problems-with-upgrade 2011-03-06T10:43:50Z 2011-03-06T10:31:20Z <p> If you follow the notes in <a href="http://www.freebsd.org/cgi/cvsweb.cgi/ports/UPDATING">/usr/ports/UPDATING</a> (and you would be wise to do), you must know that the default <a href="http://www.python.org/">Python</a> version in FreeBSD has been changed from 2.6.x to 2.7.x. The upgrade of Python itself is unproblematic; however, you might see errors while running '<code>cd /usr/ports/lang/python &amp;&amp; make upgrade-site-packages</code>' of the type:</p> <blockquote> <p> <code>/usr/local/bin/g-ir-scanner: not found</code></p> </blockquote> <p> These have nothing to do with Python, but rather require you to first upgrade <code>devel/gobject-introspection</code>. After that, 'make upgrade-site-packages' should finish successfully without further problems.</p> Luchesar ILIEV 2011-03-06T10:31:20Z Installing/upgrading LibreOffice on a headless system Luchesar ILIEV https://www.ideaconsult.net/web/luchesar/blogs/-/blogs/installing-upgrading-libreoffice-on-a-headless-system 2011-03-05T20:27:37Z 2011-03-05T20:10:03Z <p> While it might at first seem a bit strange why would you need an office suite like <a href="http://www.libreoffice.org">LibreOffice</a> on a headless system, there's at least one good reason for it - the ability to convert between different formats. In fact, both OpenOffice.org and LibreOffice explicitly support headless mode.</p> <p> A headless system with FreeBSD will likely have</p> <p> <code>WITHOUT_X11=yes</code></p> <p> defined in <a href="http://www.freebsd.org/cgi/man.cgi?query=make.conf&amp;apropos=0&amp;sektion=5&amp;manpath=FreeBSD+9-current&amp;format=html"><code>/etc/make.conf</code></a> (note that it doesn't matter whether the variable is set to 'yes', 'true', '1' or even 'no', 'false' or '0' - what counts is whether it is set at all or not; the contents are irrelevant). This should make some ports automagically disable X11 bindings or other stuff that relies on X11.</p> <p> LibreOffice builds well with this variable defined, with one important exception, however: the <a href="http://www.freshports.org/graphics/cairo/">graphics/cairo</a> port. Cairo itself build without issues, too, but when you get to building LibreOffice, it will complain about missing cairo-xlib. And the problem here is that cairo-xlib is not built when WITHOUT_X11 is defined.</p> <p> Overcoming this is actually easy (perhaps there's even more elegant solution, but I haven't had the time to investigate further). Just comment out WITHOUT_X11 in make.conf temporarily, (force) upgrade Cairo, then uncomment it back, and finally build LibreOffice. This will work with subsequent updates to LO as well; it's only necessary to comment WITHOUT_X11 when (and only while) upgrading Cairo.</p> Luchesar ILIEV 2011-03-05T20:10:03Z Tip of the day: Snapshots in ZFS, part I Luchesar ILIEV https://www.ideaconsult.net/web/luchesar/blogs/-/blogs/tip-of-the-day:-snapshots-in-zfs-part-i 2011-02-25T02:12:23Z 2011-02-25T01:39:40Z <p> You probably already know how useful filesystem snapshots can be. ZFS, in particular, has a very flexible and powerful implementation of this mechanism. Quoting the <a href="http://www.freebsd.org/cgi/man.cgi?query=zfs&amp;apropos=0&amp;sektion=0&amp;manpath=FreeBSD+9-current&amp;format=html">zfs(1M)</a> man page:</p> <blockquote> <p> <em>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A snapshot is a read-only copy of a file system&nbsp; or&nbsp; volume.&nbsp; Snapshots<br /> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; can&nbsp; be&nbsp; created extremely quickly, and initially consume no additional<br /> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; space within the pool. As data within the active dataset&nbsp; changes,&nbsp; the<br /> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; snapshot&nbsp; consumes&nbsp; more&nbsp; data&nbsp; than would otherwise be shared with the<br /> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; active dataset.</em></p> </blockquote> <p> Creating snapshots is easy:</p> <p> <code>zfs snapshot [-r] [-o property=value]...<br /> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; filesystem@snapname|volume@snapname</code></p> <p> Of special interest is the -r option. Quoting again the man page,</p> <blockquote> <p> <em>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -r<br /> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Recursively&nbsp; create snapshots of all descendent datasets. Snap-<br /> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shots are taken atomically, so&nbsp; that&nbsp; all&nbsp; recursive&nbsp; snapshots<br /> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; correspond to the same moment in time.</em></p> </blockquote> <p> For example, to take a snapshot of all filesystems in the pool zroot, you'd execute:</p> <p> <code>zfs snapshot -r zroot@somesnapshotname</code></p> <p> The importance of the atomical nature of the process cannot be emphasized well enough. A complete pool consisting of tens of filesystems (actually, the number doesn't matter much) is processed in an instant. This makes creating backups of complete systems a breeze (I'll cover zfs send-ing and receive-ing in a separate blog entry, but don't hesitate to check the man page again).</p> <p> Listing the snapshots on a system is possible with the zfs list subcommand:</p> <p> &nbsp;<code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; zfs list [-rH] [-o property[,...]] [ -t type[,...]]<br /> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ -s property ] ... [ -S property ] ... [filesystem|volume|snapshot]<br /> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...</code><br /> <br /> Here's the simplest way to use it, which shows all snapshots on all filesystems and volumes:</p> <p> <code>zfs list -t snapshot</code></p> <p> Deleting snapshots is also easy. However, be <strong>very careful</strong> when you specify the name of the snapshot. If you accidentally omit the snapshot part (@snapshotname), and especially if you're using the -r option, you could easily lose <strong>lots of information</strong> without any way to get it back (save from a backup). Again, double check that you've specified a snapshot name (and the correct one), and not the filesystem name alone.</p> <p> Here's how to destroy all snapshots we created earlier:</p> <p> <code>zfs destroy -r zroot@somesnapshotname</code></p> <p> And for a third time, <strong>DO NOT</strong> do this, unless it is what you want (and it means virtually emptying the pool):</p> <p> <code>zfs destroy -r zroot</code></p> <p> I'll leave the topic on how to actually use snapshots for the next blog entry, but you might check the <a href="http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#Using_ZFS_Snapshots">relevant entry</a> in the ZFS Best Practices Guide meanwhile.</p> Luchesar ILIEV 2011-02-25T01:39:40Z Tip of the day: Checking whether your FreeBSD ports are up to date. Luchesar ILIEV https://www.ideaconsult.net/web/luchesar/blogs/-/blogs/tip-of-the-day:-checking-whether-your-freebsd-ports-are-up-to-date 2011-02-18T12:58:49Z 2011-02-18T12:50:28Z <p> Up until recently, I recommended using portversion(1) from <em>ports-mgmt/portupgrade</em> the following way:</p> <p> <code>portversion -Fv | grep -v up-to-date</code></p> <p> There is, however, a much simpler, and almost as effective way:</p> <p> <code>portversion -vL =</code></p> Luchesar ILIEV 2011-02-18T12:50:28Z [Heads Up] FreeBSD Perl port updated to 5.12.3 Luchesar ILIEV https://www.ideaconsult.net/web/luchesar/blogs/-/blogs/[heads-up]-freebsd-perl-port-updated-to-5-12-3 2011-03-06T10:45:36Z 2011-01-25T22:09:31Z <p> In case you haven't noticed, FreeBSD's lang/perl5.12 port has been updated to version 5.12.3, which requires to update everything that depends on it. Here's the relevant entry from UPDATING:</p> <pre> 20110125: AFFECTS: users of lang/perl5.12 AUTHOR: skv .at. FreeBSD .dot. org lang/perl5.12 has been updated to 5.12.3. You should update everything that depends on perl. The easiest way to do that is to use "perl-after-upgrade" script supplied with lang/perl5.12. Please see its manual page for details. If you want to switch to lang/perl5.12 from lang/perl5.{8,10} please follow instructions in the entry 20100715 in this file. </pre> <br /> Luchesar ILIEV 2011-01-25T22:09:31Z