Tuesday, November 2, 2010

Re: tar 1.23 --remove-files option is seriously broken

tar 1.24 fixed the --remove-files option problem.

http://savannah.gnu.org/forum/forum.php?forum_id=6565

Item posted by Sergey Poznyakoff on Sun 24 Oct 2010 10:56:57 PM UTC.

GNU tar 1.24 is available for download. Main changes in this release:

  • The --full-time option.
  • More reliable directory traversal when creating archives
  • --dereference consistency.
  • Extracts symlink attributes, such as last-modified time and link permissions, if the operating system supports this.
  • Fixed spurious error diagnostics on broken pipe.
  • Fixed --remove-files bug (previous version would fail to remove a directory which contained symlinks to another files within that directory).
  • Allows to use --label together with --update.
  • The options --record-size and --tape-length (-L) accept size suffixes.
  • Fixed dead loop on extracting existing symlinks with the -k option.
See the NEWS file for a detailed list of changes.

Saturday, October 23, 2010

tar 1.23 --remove-files option is seriously broken

I noticed tar behaves strange on Ubuntu 10.10.
Soon I found 10.10 has tar 1.23 and --remove-files option in tar 1.23 is seriously broken when it tries to archive a symbolic link. The option supposed to remove the link automatically after archiving it, but it actually removes the file the symlink is pointing to :(

This post is reporting the same issue.

http://osdir.com/ml/bug-tar-gnu/2010-03/msg00026.html

Subject: [Bug-tar] broken --remove-files in tar-1.23 -
msg#00026
List: bug-tar-gnu

Option --remove-files seems to be broken in version 1.23.

Example:
--------
$ mkdir -p a/b
$ ln -s b a/c
$ tar --remove-files -czf a.tar.gz a
tar: /home/build/tmp/a: Cannot rmdir: Directory not empty
tar: Exiting with failure status due to previous errors
--------

Always passes in version 1.22.

Alexander Kozlov
Comp Biol, KTH,
Stockholm, Sweden

The solution is either reverting to 1.22 or applying the patch posted by Sergey:

http://osdir.com/ml/bug-tar-gnu/2010-03/msg00029.html

Monday, June 7, 2010

emacs: "murrine_style_draw_box: assertion `height >= -1 failed" solved

The annoying warnings of emacs on Ubuntu 10.4:

** (emacs:23587): CRITICAL **: murrine_style_draw_box: assertion `height >= -1' failed

can be fixed by modifying the following line in /usr/share/themes/Ambiance/gtk-2.0/gtkrc from:

GtkRange::trough-under-steppers = 0

to:

GtkRange::trough-under-steppers = 1

Thanks to Alf on https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/538499

Sunday, June 6, 2010

Building Ruby: readline and tk

So I installed libreadline5-dev instead of libreadline6-dev:

$ sudo apt-get remove libreadline6-dev
$ sudo apt-get install libreadline5-dev

Then ext/readline/extconf.rb seems happy:

$ cd ext/readline
$ ruby extconf.rb
checking for tgetnum() in -lncurses... yes
checking for readline/readline.h... yes
checking for readline/history.h... yes
checking for readline() in -lreadline... yes
...

And, for tk support, the simplest way is to download ActiveTcl from http://www.activestate.com/activetcl/downloads and install it. ext/tk/extconf.rb looks for ActiveTcl.

Friday, June 4, 2010

Ruby now rejects to link readline 6

It took a while for me to figure out why I can't enable readline in ruby any more.
The revision 28118 (06/01/2010) has changed readline/extconf.rb to reject readline V6.

According to ruby-core:25272, it is addressing a GPLv3 issue. Here's from the original post:

Hello.

Recently readline 6.0 was released and its license was changed from GPLv2+ (GPL version 2 and any later) to GPLv3+ [1][2]
Unfortunately Ruby's license is still under GPLv2 and Ruby's original license [3], which is incompatible with GPLv3 [4]. So unless Ruby's license is changed to "GPLv2+ or Ruby's original license" or so , Ruby's readline module cannot be shipped any more. Note that "Ruby's original license" is regarded as incompatible with GPL [5].

So please change the Ruby's license to GPLv3 (and GPLv2) compat.

[1] http://tiswww.case.edu/php/chet/readline/rltop.html
[2] https://www.redhat.com/archives/fedora-devel-list/2009-July/msg00192.html
[3] http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/trunk/COPYING?view=co
[4] https://fedoraproject.org/wiki/Licensing#GPL_Compatibility_Matrix
[5] https://fedoraproject.org/wiki/Licensing

Sunday, May 9, 2010

Building ruby 1.9.3dev

First time building ruby. These steps seem working.

$ svn co http://svn.ruby-lang.org/repos/ruby/trunk ruby
$ autoconf
$ CFLAGS="-U_FORTIFY_SOURCE" ./configure --with-baseruby=/usr/bin/ruby --prefix=/home/toshi/built
$ make
$ make test
$ make install

Looks like I need to specify --with-baseruby with working ruby. So actually I needed to install ruby 1.8 from the distribution:

$ sudo apt-get install ruby

Also -U_FORTIFY_SOURCE is needed. Otherwise I hit "longjmp causes uninitialized stack frame" errors during "make test" just like http://bugs.winehq.org/show_bug.cgi?id=21405

Saturday, March 13, 2010

Mounting VirutalBox shared folder

I had this mysterious failure.

$ sudo mount -t vboxsf -o uid=1000,gid=1000 Projects ~/Projects.ext
/sbin/mount.vboxsf: mounting failed with the error: Protocol error

It turned out the problem was my local directory named 'Projects' in the current directory. It looks like mount.vboxsf thinks I'm instructing to mount the local directory 'Projects' instead of the shared folder 'Projects'. If I cd to a directory that doesn't have a 'Projects', the same command was successful. Annoying :(