Showing posts with label problems. Show all posts
Showing posts with label problems. Show all posts

Tuesday, November 29, 2011

Compiling Zeitgeist data sources plugins on Fedora 15...

I'm constantly in search for some way that will help me organize myself. I tend to do many things at once and keeping track of all of them is hard. One of the possibilites I wanted to try for a long time now was Zeitgeist. Basically, Zeitgeist records all your activities and they can be viewed later with gnome-activity-journal application. This system isn't finished yet, for example, it lacks better integration with many applications. Also, better options to manipulate that data are necessary, but all in all, it sounds promising.

In Fedora 15 there are already packages for Zeitgeist as well as for gnome-activity-journal. But the problem is that plugins for Zeitgeist are not packaged. This means that on Fedora Zeitgeist tracks only opened documents, not, e.g., what Web pages you were surfing. So I decided to compile Zeitgeist data sources, and  while doing so I had some problems for which I saw posted questions on how to resolve them, but without any answers. So I decided to document what I had to do in order to get this package to work.

Prerequisites

Before configuring and compiling package be certain that you have all appropriate development packages installed. Minimally those are:
  • libzeitgeist-devel
  • xulrunner-devel

Modifying system files

You'll need some editing of system files. I had a problem that pkg-config didn't recognize libxul. If you run the following command:
pkg-config --list-all
and you don't see libxul in the output than probably you have that same problem. It turned out that the problem were MPI files (if you didn't install any MPI libraries/tools you won't have that problem). In all of them pkg-config reported error and stopped further processing with a result that it didn't parse libxul file, and consequently, didn't report it's existence. This, further, confused ZDS configure script into thinking that there is no Firefox 4.0. Next, there is an error in configure script itself leading it to assume that Firefox 3.6 is installed! All wrong.

So, you need to edit the following files: mpich2-c.pc, mpich2-cxx.pc, mpich2-f77.pc, and mpich2-f90.pc. All of them are placed in /usr/lib64/pkgconfig directory. In each file you'll find an if statement:
if test "no" = yes; then
    plib=something
else
    plib=
fi
Remove that if statement, and also, remove string -l${plib} in line that starts with Lib:. If it happens that you don't have some of those files, just skip to the next one.

There was also a problem with libxul.pc file itself. In it you'll find the following line:
Version: 2
Which has a problem that pkgconfig doesn't treat that as 2.0 but strictly as 2. So, in ZDS configure script there is a requirement  that libxul is >= 2.0 which, for some strange reason, isn't true. Anyway, change the previos line to read as follows:
Version: 2.0
And that's for system changes.

Obtaining, patching and compiling the source

Grab Zeitgeist data sources (ZDS) tarball from the Launchpad site. I used version 0.8.0.1. Also, unpack the source and enter into the newly created directory. All the directory references that follow are relative to that directory.

The only thing you need to patch is to tell that Firefox extension will work for Firefox versions greater than 4.0. To do that, open file firefox-40-libzg/extension/install.rdf and the line that reads:
<em:maxVersion>4.0.*</em:maxVersion>
change into
<em:maxVersion>9.0.*</em:maxVersion>
Next, you need to configure the source. Before configuration, you have to say to configure script to use additional switch when invoking C++ compiler that will turn on some extensions used in XUL (e.g. char16_t type):
export CXXFLAGS=-std=gnu++0x
Now, run configure, then make, and finally (as root user), make install:
./configure
make
su
make install
And that should be it!

Note for Fedora 16

After writing this post, I installed Fedora 16. The steps necessary to compile data sources are almost the same. But, there is already gedit-plugin available in Fedora repository. If this is a problem, or not, I don't know yet. In any case, you can disable gedit plugin during configuration process.

One additional thing I had a problem with was the following error message:
emacs: error while loading shared libraries: libotf.so.0: cannot open shared object file: No such file or directory
This error message will occur only if you have Emacs plugin enabled and you don't have libotf installed. This is some weird problem in which one package (I think some MPI package) reports that it provides libotf which makes Emacs' dependency satisfied. But this libotf isn't the one that Emacs expects (and can find for that matter) and thus Emacs can not start. Anyway, just install package libotf and that should be it.

Thursday, November 17, 2011

Zimbra 7 and domain wide disclaimer...

In Zimbra 7 it is not necessary any more to hack scripts in order to get domain wide disclaimer. At least not if you want to add the same disclaimer to every mail that passes through your mail server. In case you want more control, like not attaching it to some mails, then you'll have to resort again to scripts and hacking.

So, to add disclaimer, the following would do:
zmprov mcf zimbraDomainMandatoryMailSignatureText <text disclaimer>
zmprov mcf zimbraDomainMandatoryMailSignatureHTML <html disclaimer>
zmprov mcf zimbraDomainMandatoryMailSignatureEnabled TRUE
and finally, reload amavis configuration using
zmamavisdctl reload
Note that whenever you change any of the previous three attributes you have to restart amavis. Those attributes are accessed only when amavis is started and they are used as an input to configuration writing routines.

You can query current values using gcf instead of mcf (don't forget to leave out last arguments because you are not setting values!).

Well, now, there were some problems.

The first one is that you disclaimer has probably more that one line, anyway more that you are prepared to type. In that case you can put it into a file and then use backtick shell notation with cat command to place the content of a file into appropriate place. Don't forget to place double quotes around everything so that spaces are not interpreted by the shell (like this "`cat somefile`")! There are other methods too, but this hack worked for me. Well, almost, becuse when text version of a disclaimer was attached to the text only mail, everything after the first line was cut off. HTML on the other hand worked, but, it also suffered from the second problem. And the second problem is...

The second problem is that I have Croatian in disclaimer which means it's encoded using UTF-8, and that, for some reason, doesn't play well with the LDAP, or some command inbetween, that transfers text/html disclaimer into LDAP. But I noticed that other tools, e.g. vi/vim, even bash, behaved strangely upon encountering some Croatian character. Trying to set environment variable LANG to en_US.utf8 before executing zmprov command didn't work either! And the command locale showed that C was still used. I managed to fix this by commenting out the following two lines in ~zimbra/.bash_profile file:
#export LANG=C
#export LC_ALL=C
After that (don't forget to login/logout) bash and vi started to work as expected but Zimbra still was messing up the disclaimer. That is, until I restarted amavis again. Then, it worked. In case it still doesn't work, set HTML attribute using zmprov command and restart amavis again!

This locale setting is nothing new in Zimbra. I checked previous version of Zimbra and it was also there. But until now I never had to put UTF8 into LDAP and so I never had hit this particular error.

This has left me with the last problem, text attachment isn't working as it should. So, I opened amavis configuration file /opt/zimbra/conf/amavisd.conf to see what's exactly going on. In there, I found that the file with the disclaimer should be in /opt/zimbra/data/altermime directory and it should be named _OPTION_.txt. Well, it is there but not called _OPTION_.txt. It could be that some postprocessing is performed on the values in amavis configuration file, but I ignored that as it is not important. What is important is that the file with disclaimer is called global-default.txt and it had wrong content, i.e. only the first line of the disclaimer. For a quick test I replaced it with the disclaimer I wanted to have, and voila, it worked!!!

So, why is there an error? I'll investigate later since now I have to do other things. :)

About Me

scientist, consultant, security specialist, networking guy, system administrator, philosopher ;)

Blog Archive