VTK re-compile (for Python) with PowerCrust algorithm support

The following was performed with VTK 5.8 and Python 2.7.8 on Debian Wheezy x86_64.

  1. Get the VTK source-code: http://vtk.org/VTK/resources/software.html
  2. Get the Tim Hutton’s PowerCrust C++ source-code: https://github.com/timhutton/vtkpowercrust
  3. Unzip both archives
  4. Copy the C++ files (.cxx & .h) into VTK/Hybrid
  5. Edit VTK/Hybrib/CMakeLists.txt and add the PowerCrust .cxx file
  6. cd VTK; mkdir build; cd build; ccmake ..
  7. Set desired installation directory
  8. Turn on BUILD_SHARED_LIBS, VTK_USE_RENDERING, VTK_WRAP_PYTHON
  9. While on ccmake first configured [c] and then generate [g]
  10. make && make install
  11. cd Wrapping/Python; python setup.py install
  12. Assuming all go well export the VTK libraries: export LD_LIBRARY_PATH=/<installation_path>/lib/vtk-5.8
Advertisements

Disable internal audio

Have been working with Ardour lately and the multiple audio devices (internal + PCI) have been causing issues both on output and input. The easiest workaround is removing totally the unused sound card, which in my case was the internal Intel HDA. The single step required was to blacklist the module of the sound card. You can identify the module by “lspci” and then blacklisting the module is straight forward:

vi /etc/modprobe.d/blacklist

and add the line

blacklist <module name>

A single reboot should do the job or you could unload the module instantly. Although, reboot would confirm whether the blacklist function worked or not.

Remote cPanel backup via FTP

Here is the scenario:

– Domain that needs to be backed up (public_html, mail, database).
– Only access available via cPanel and FTP.
– Need automated daily full backup.

Solution:

– Take full backup on server and compress its contents (cronjob on remote server)
– Download via FTP the compressed file to the local machine (cronjob on local machine).
– Delete compressed file.

There might be tools that do this, although I didn’t come across any while looking on the web. I implemented a simple solution based on bash scripts that gets the task done.

backup.sh: Goes on the remote server to run as a cronjob.
ftp.sh: Runs locally (on the machine that will store the backup) as a cronjob.
.netrc: Defines the FTP account details (stored in /home/$user/.netrc)

Gmail SMTP relay with Postfix

The following configuration has been performed in Debian but should apply in any Linux distro with Postfix installation. The task quite simple: use Gmail as SMTP relay for outgoing email traffic.

1) At first place I had to install the following packages and turn off sendmail:

apt-get install postfix mailutils libsasl2-2 ca-certificates libsasl2-modules
service sendmail stop

2) Then edit the configuration file at /etc/postfix/main.cf by adding the following options at the end of the file:

# Gmail SMTP relay
relayhost = [smtp.gmail.com]:587
smtp_use_tls=yes
smtp_sasl_auth_enable = yes 
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_sasl_security_options =

3) Create the authentication file at /etc/postfix/sasl_passwd and set the right permissions:

[smtp.gmail.com]:587    <username>@gmail.com:<password>
chmod 400 /etc/postfix/sasl_passwd

Make sure the file is owned by the user who runs the Postfix daemon.
4) Reload Postfix:

service postfix reload

5) Confirm the configuration is actually working by sending a test mail:

echo "Test mail from postfix" | mail -s "Test Postfix" pkritikakos@isbs.gr

The sender of the email should be the given Gmail account. Also, in the “Sent” folder of the Gmail account you should see the email you have sent with Postfix.

If your domain is using Gmail’s infrastructure for handling emails, you can replace @gmail.com with your domain and use the corresponding account details.

NOTE: This configuration will be sending any system message as “username@gmail.com” and therefore is not advised to be used in multi-user environment.

Android SQLite Adapter class

Working with an SQLite database on Android can require some times more effort than what you should really give. For instance, if you ship a pre-configured and populated database with an application, you would need first to copy over the database to the specific database directory and then open it for reading and/or writing data to it. The SQLiteOpenHelper class provides a few methods that make life a bit easier but it does not provide a copy method for handling this issue. In addition to this, a check method would be required before copying the database and so on. Following on this, I implemented a SQLite adapter class to cover my needs as bellow:

– Copy database to the correct directory.
– Open and close the database.
– Execute raw SQL query.
– Execute SQL query for string, int, long, double.
– Drop table.
– Return count of a table.
– Download a db copy from Internet and replace local one.

Source code at GitHub.

Android SDK x86_64 – adb, libraries, emulator issues

I have installed the latest Android SDK on Fedora 17 x86_64 version. I’ve chosen the bundle for my platform, expecting it would work straight away, but that was not the case. The adb (Android Debug Brdige) needs to make use of the of libraries for the i686 version, such as glibc, ncurses and tdc++. Errors look as usual:

/lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory

In addition to these I required to install libz for the SDK to perform correctly without any errors. Simply linking from /lib64 to /lib wouldn’t work, as adb would exit with segmentation fault, something expectable since it deals with different architecture’s libraries.  The following command will install all the required packages (with a couple of dependencies) to get that bit working:

yum install glibc.i686 ncurses0libs.i686 libstdc++.i686 libzeitgeist.i686

In addition to the libraries issues for the adb, the emulator binary that lunches the Android emulation images is also targeted for i686. The bundle comes with emulator-x86_64 but when you lunch an AVD (Android Virtual Device) through the ADT Manager, it wouldn’t start the emulator as the binary was failing to execute and wouldn’t pick automatically the x86_64 version. In this case a simple link would work. I renamed the initial i686 binary to emulator-32, and linked emulator-x86_64 to emulator. The actual AVD would then start as it should and operated normally, being able to install applications via the Android SDK.

Converting OS X .plist to XML

The failure of my MacBook Pro seems that it didn’t cost much in terms on data loss, actually all the really crucial data were there. There are though some bits here and there that need to be moved over to my Linux box. One of the most important for everyday use the was the feed list for my RSS Aggregator. I was using the elegant, nice and simple NewsFire which uses binary plists (XML-like) for storing the feed list and I was never bothered exporting the feed list to OPML. The plist command in OS X can convert the .plist file into a .xml file, however I had no other Mac to do this operation or copy over the plist and export in OPML from there. Therefore I had to find a workaround for getting the plist working on RSSOwl or Liferea. Found the Perl plutil for Linux which converted the binary plist to standard XML. RSSOwl managed then to import the XML with all the blogs’ feeds as on NewsFire.

Regarding liferea, it wouldn’t import the XML file as it wasn’t proper OPML. But since RSSOwl imported the XMl file, I exported the feed list as OPML, which would be imported into Liferea or any other application.