Saturday, December 22, 2007

bluefish-unstable packages ready for testing

I promised it some time ago and now it has been done: Debian packages for the development tree (1.1 series) of Bluefish are ready for Debian users and called bluefish-unstable. The packages can be installed along with the stable version, so you can safely test new features and give us feedback and bug reports.

NOTE

The packages cannot be (re)built on Etch, because debhelper version 5.0.57 or higher is necessary. I will fix this part of debian/rules soon, so it can be (re)built on Etch too.

docbook-defguide - solving performance and timing issues with native code

Some days ago I wrote down my experiences with packaging docbook-defguide. The main (remaining) issues I mentioned were the resources and the time the package needs to build. Even on an AMD X2 4600+ with 6GB of RAM it needs 7-8 hours.

Today I met with Torsten Werner. He mentioned, that there are some move JVMs I could try. So I tested alternatives to GIJ this night. I found this short summary about free JVMs, which was some kind of interesting.

I began with cacao, which seemed to be fast, but it was killed very early in the build process with an java.lang.OutOfMemory error. Even playing around with the -Xms and -Xmx switches in buildtools/saxon.sh did not help. So I dropped cacao from the list. Seems both cacao and kaffe create similar problems here and are not suitable for building the package.

Second alternative I tried was sablevm. It directly throw out some warnings or errors so I directly dropped it too.

Next JVM was jamvm. But it was as slow as GIJ. So I dropped it from the list of alternatives too.

Then I found an interesting statement in the article I linked somewhere above. The author said, that his perfomance test time with GCJ/GIJ reduced from 433 to 9 seconds, when he compiled his application into a native executable. So I took a fast look through the docbook-defguide build dependencies and found, that Debian already provides a natively compiled Xerces package libxerces2-java-gcj. But there were no packages for libsaxon-java, libxml-commons-resolver1.1-java and docbook-xsl-saxon. So short and dirty: I downloaded the source for these packages, added the necessary stuff to get natively compiled packages too, built and installed them. Fortunately packages with native code already exist for their dependencies JAXP 1.3 and Xerces.

And what should I say: Now building the TDG needs less then 512MB RAM and it builds in around an hour ... even on my system. I will ask the Debian Java maintainers to add -gcj packages for Saxon and XML-Commons and fix my own docbook-xsl-saxon package. This will hopefully help maintaining docbook-defguide.

Monday, December 17, 2007

FYI: docbook-defguide 2.0.17 ready - Sun Java vs. GIJ building the package

Ok guys. After spending several hours of this weekend to package the latest release of Norman Walshs DocBook: The Definitive Guide, I'm now proud to tell you: It's done!

I was able to build the package with the free Java engine (GIJ) so docbook-defguide can stay in main. However, it was some kind of disappointing: Sun Java needs an hour and a maximum heapsize of 512MB to build the package on my system. GIJ needs 16 hours and a maximum heap size of 1GB to build. kaffe, which I tried too, fails much earlier than GIJ with a maximum heap size of 512MB. So I decided against it and for GIJ.

If you know of a way to speed up the build process (besides the possibility to buy a faster system ... except you want to make it your christmas or birthday present for me *g*), don't hesitate to tell me. The packaging files are in the Debian XML/SGML groups SVN repository.

However, expect the package in your Debian repository soon (guess, my sponsor wants to rebuild it, which may need another 1x hours :)).

Update

Ardo van Rangelrooij kindly offered to build the package on an AMD X2 4600+ with 6GB. The build time decreased to at least 7-8 hours. The package will be uploaded to the Debian archive within the next days.

Tuesday, November 20, 2007

LDFLAGS and −−as−needed

Now that I discovered this nice flag I checked a few of my packages. It works nice for the gnome-chemistry-utils application packages. Unfortunately libgcu0 does not benefit from the flag because of libtool bug #347650. However there is an appreciably difference in the dependencies for the plugin and application packages, where the amount of dependencies decreased. For example compare the old

Depends: iceweasel | iceape-browser | xulrunner, libart-2.0-2 (>= 2.3.18),
libatk1.0-0 (>= 1.20.0), libc6 (>= 2.6.1-1), libcairo2 (>= 1.4.0), libgcc1 (>= 1:4.2.1), libgconf2-4 (>= 2.13.5),
libgcu0 (<< 0.9), libgcu0 (>= 0.8), libgl1-mesa-glx | libgl1, libglade2-0 (>= 1:2.6.1), libglib2.0-0 (>= 2.14.0),
libglu1-mesa | libglu1, libgnomecanvas2-0 (>= 2.11.1), libgnomeprint2.2-0 (>= 2.17.0),
libgnomeprintui2.2-0 (>= 2.17.0), libgnomevfs2-0 (>= 1:2.17.90), libgoffice-0-4 (>= 0.4.2),
libgsf-1-114 (>= 1.14.7), libgtk2.0-0 (>= 2.12.0), libgtkglext1, libice6 (>= 1:1.0.0), libnspr4-0d (>= 1.8.0.10),
libopenbabel2, liborbit2 (>= 1:2.14.1), libpango1.0-0 (>= 1.18.3), libsm6, libstdc++6 (>= 4.2.1), libx11-6,
libxml2 (>= 2.6.27), libxmu6, libxt6, zlib1g (>= 1:1.2.3.3.dfsg-1)

and the new Depends field for gcu-plugin:

Depends: libc6 (>= 2.6.1-1), libgcc1 (>= 1:4.2.1), libgcu0 (<< 0.9),
libgcu0 (>= 0.8), libglib2.0-0 (>= 2.14.0), libgnomevfs2-0 (>= 1:2.17.90), libgtk2.0-0 (>= 2.12.0),
libnspr4-0d (>= 1.8.0.10), libstdc++6 (>= 4.2.1), libx11-6, libxml2 (>= 2.6.29), iceweasel | iceape-browser |
xulrunner

As another example bluefish now (the next upload) really only shows the necessary dependencies. Compare the current:

Depends: libart-2.0-2 (>= 2.3.18), libaspell15 (>= 0.60),
libatk1.0-0 (>= 1.20.0), libbonobo2-0 (>= 2.15.0), libbonoboui2-0 (>= 2.15.1), libc6 (>= 2.6.1-1),
libcairo2 (>= 1.4.0), libfontconfig1 (>= 2.4.0), libgconf2-4 (>= 2.13.5), libglib2.0-0 (>= 2.14.0),
libgnome2-0 (>= 2.17.3), libgnomecanvas2-0 (>= 2.11.1), libgnomeui-0 (>= 2.17.1),
libgnomevfs2-0 (>= 1:2.17.90), libgtk2.0-0 (>= 2.12.0), libice6 (>= 1:1.0.0), liborbit2 (>= 1:2.14.1),
libpango1.0-0 (>= 1.18.2), libpcre3 (>= 6.0), libpopt0 (>= 1.10), libsm6, libx11-6, libxcomposite1 (>= 1:0.3-1),
libxcursor1 (>> 1.1.2), libxdamage1 (>= 1:1.1), libxext6, libxfixes3 (>= 1:4.0.1), libxi6, libxinerama1,
libxrandr2 (>= 2:1.2.0), libxrender1

to the “upcoming” Depends field:

Depends: libaspell15 (>= 0.60), libc6 (>= 2.7-1), libglib2.0-0 (>= 2.14.0),
libgnomeui-0 (>= 2.17.1), libgnomevfs2-0 (>= 1:2.17.90), libgtk2.0-0 (>= 2.12.0), libpango1.0-0 (>= 1.18.3),
libpcre3 (>= 6.0)

Nice result. I should check (my) other packages too :) Maybe that's also something for debichems TODO list.

Monday, November 12, 2007

GNU make vs. BSD make - a practical problem experience

I'm currently evaluating Olivier Sessinks jailkit to maintain a small cvsd CHROOT with an included SSH server. The cvsd-buildroot command e.g. doesn't handle the libpam-modules dependency in the CHROOT. So I tried to update the Debian packaging files included in the jailkit source. During this work I found some issues with the build environment - e.g. no DESTDIR support and some other stuff (another user already complained, that there might be problems with the SUID installation part for jk_chrootsh, jk_uchroot and jk_procmailwrapper of the Makefiles).

So I began to check and “fix” the Makefiles and the configure script and then sent everything to Olivier. I did not only add the DESTDIR variables. I also made use of built-in rules, common variables (also for implicit rules), ... and such stuff to make the Makefiles shorter and easier to maintain. My fault: I tested everything with GNU make. Now Olivier complained, that BSDs make doesn't work anymore. So we began a short hack session to check for the problems.

My first issue: I had to find some BSD make to test it myself. I found it in the freebsd5-buildutils, that contains the freebsd-make command. Then we began to check for incompatibilities and that's the result:

  1. ifdef statements differ in syntax
    • GNU make uses ifdef VAR
    • BSD make uses .ifdef VAR

    solution: We replaced the statement with a construct similar to AM_CONDITIONAL. But we do not use this macro, because it would need to be shipped in aclocal.m4, which is currently not necessary. The code simply sets a variable foo_TRUE to ‘# ‘, if the condition is wrong, or the variable is left empty, if the condition is true:

    if test "x$my_condition" != "xno" ; then
        AC_SUBST([foo_TRUE], [])
    else
        AC_SUBST([foo_TRUE], [# ])
    fi
    FILES = bar
    @foo_TRUE@FILES += foo
  2. prerequisite variables differ in syntax
    • GNU make uses $<, $^, $@, ...
    • BSD make uses ${.IMPSRC}, ${.ALLSRC}, ${.TARGET}, ... (note, that both *SRC variables hold a list of source files)

    Unfortunately both make implementations don't seem to share a variable for the list of prerequisites. So the only solution is to list all prerequisites in the rule again. A variable would be much more comfortable. Maybe one could write a function, that first tests ${.IMPSRC} and falls back to $^. Maybe that's an alternative, but it's IMHO not a very good solution. We've chosen to write down all prerequisites in a rule instead of using a variable. This is a little bit harder to maintain, but it works.

  3. built-in rules are not shared and do not use the same variables
    • GNU make ships built-in rules to build objects from sources and link them; rules consider CPPFLAGS
    • BSD make ships built-in rules to build objects from sources, but there are no rules to link them; rules do not consider CPPFLAGS

    In the case of GNU make, one can simply write:

    myprog: foo.o bar.o

    and GNU make will automatically create foo.o from foo.c (.c.o:, ditto for bar.o) and at least link myprog (.o:). But BSD make will only create the object files. There is no final link-step. So we had to include the rule to link the program in the Makefile.

Finally we got it and it looks good now. I/We learned a lot of new things (I learnd a lot about BSD make) ;), but it took us 1-2 hours to understand and fix the problems.

Here a list of URLs that might give some more information about the programs, their syntax and limitations:

Tuesday, November 6, 2007

Experiences with the “new” fglrx-driver 8.42.3 package

Yesterday I found some minutes to update my kernel. Because I did not have time to compile a 2.6.22 kernel, I simply installed linux-source-k7 (linux-source-2.6-k7). This was a “welcome” occassion to update the ATI/AMD Linux driver for my Radeon X1650 Pro graphics card to their latest version 8.42.3.

As a first step I had to find out, that upgrade from my 8.38.x version did not seem to work properly. I got some error messages regarding the diversions in /usr/lib/fglrx/diversions/. So I purged the fglrx* packages. Then I manually removed the diversions, the (now) empty /usr/lib/fglrx/diversions/ directory and the configuration directory /etc/ati:

$ apt-get remove --purge fglrx-driver fglrx-kernel-src fglrx-control
$ dpkg-divert --remove /usr/llib/libGL.so.1
$ dpkg-divert --remove /usr/llib/libGL.so.1.2
$ rm -rf /usr/lib/fglrx /etc/ati

Then I reinstalled the fglrx* packages, installed the headers linux-headers-2.6-k7 and prepared the flgrx module package with m-a:

$ m-a prepare
$ m-a -l 2.6.22-3-k7 build fglrx

Installing the package and rebooting brought up the system again. glxgears shows around 3000 FPS. However, although everything seems to work properly, I found some log entries and errors, that concern me.

First thing is, that fgl_glxgears refuses to work.

$ fgl_glxgears
Using GLX_SGIX_pbuffer
X Error of failed request:  GLXUnsupportedPrivateRequest
  Major opcode of failed request:  131 (GLX)
  Minor opcode of failed request:  16 (X_GLXVendorPrivate)
  Serial number of failed request:  42
  Current serial number in output stream:  43

Looking into the Xorg.0.log shows me this error:

(EE) fglrx(0): Failed to enable interrupts.

And dmesg shows this:

[fglrx] IRQ_MGR is disabled untill GART_CACHABLE memory will be implemented<6>
[fglrx] Internal AGP support requested, but kernel AGP support active.
[fglrx] Have to use kernel AGP support to avoid conflicts.
[fglrx] AGP detected, AgpState   = 0×1f000217 (hardware caps of chipset)
agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode
agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode
[fglrx] AGP enabled,  AgpCommand = 0×1f000314 (selected caps)
[fglrx:firegl_lock] *ERROR* Process 32648 is using illegal context 0×00000003

This is very similar to everything I read at e.g. phoronix.com. So if you read between the lines: I did not find a solution nor an answer to the shown error message(s) nor the runtime error. So if you know, what's causing this and how it can be solved, please let me know.

At least the good news is: XVideo seems to work again. No juddering video playback. I like that. Now the bad news: It still burdens my CPU (causes a constant usage of 50-70%). I can even observe this effect when the screensaver is running ... and I think, this is NOT the intended design. So I turned off the screensaver for now and simply make the screen go black and lock.

PS: Maybe I will have a look at updating the fglrx manpages (@ATI/AMD: They are still offered for adoption!)

Sunday, November 4, 2007

svn-buildpackage, debian/ only and dpatch-edit-patch

I guess, we (the debichem developers) are not the only people doing some collaborative package maintenance using a SVN-server (just look at svn.debian.org) and svn-buildpackage. To avoid duplication of source code we decided to only keep the Debian packaging files under version control (this also leads to less checkout traffic).

This layout has a problem. You cannot directly create patches, because the SVN of course misses the source code of the package. Fortunately, there is a solution for dpatch users. The dpatch-edit-patch utility provides a switch to handle the above described design: the -b switch. Now all we have to do is, to tell dpatch, where to find the .orig.tar.gz tarball. There is another utility used for this task: dpatch-get-origtargz. This small tool does the following:

  1. check if the tarball can be found in the location given by the DPEP_GETORIGTARGZ environment variable or the conf_getorigtargz option (${HOME}/.dpatch.conf)
  2. try to get the tarball from the Debian archive
  3. try to get the tarball using debian/watch

I don't want to speak about the possibilities 2 and 3. Interesting is the possibility 1. In my case, I have the SVN directories under /usr/local/src/packages/pkg-${PACKAGE} and the tarballs under /usr/local/src/packages/${PACKAGE}. So I tell dpatch the following via ${HOME}/.dpatch.conf:

PACKAGENAME="$(dpkg-parsechangelog | \
        sed -n '/^Source:/{s/^Source:[[:space:]]\+\(.*\)/\1/;p;q}’)”
UPSTREAMVERSION=”$(dpkg-parsechangelog | \
        sed -n ‘/^Version:/{s/^Version:[[:space:]]\+\([0-9]\+:\)\?\([^-]\+\).*/\2/;p;q}’)”

conf_origtargzpath=”/usr/local/src/packages/${PACKAGENAME}”

Now some of you might use different locations of the .orig.tar.gz tarballs. I've created another example dpatch.conf to satisfy such needs. Just adjust the if...else construct to adjust the following ${HOME}/.dpatch.conf for your needs:

PACKAGENAME="$(dpkg-parsechangelog | \
        sed -n '/^Source:/{s/^Source:[[:space:]]\+\(.*\)/\1/;p;q}’)”
UPSTREAMVERSION=”$(dpkg-parsechangelog | \
        sed -n ‘/^Version:/{s/^Version:[[:space:]]\+\([0-9]\+:\)\?\([^-]\+\).*/\2/;p;q}’)”

if [[ `pwd` =~ '^.*/debian-med/trunk/packages/.*$' ]]
then
        conf_origtargzpath=”/usr/local/src/packages/debian-med/trunk/packages/${PACKAGENAME}”
else
        conf_origtargzpath=”/usr/local/src/packages/${PACKAGENAME}”
fi

What about quilt-users? Well, I did not yet use it, so I cannot tell you, what to do here. But I'm sure, there is some way to realize the same behaviour.

Update

The tool svn-do can be used to create quilt patches.

Monday, October 15, 2007

Repository key expired III

The repository archive key had expired at October 10th 2007. The new expire date is October 15th 2008. You will have to update the key in your apt keyring. The updated key can be found at pgp.mit.edu keyserver or locally in ASCII format at wgdd_archive_key.asc. Detailed information can be found in section Archive signing key.

Monday, June 18, 2007

Gabedit, DRAWxtl and libint are on their way into Debian

This is an information for all those users and developers, which are interested in chemistry and computational chemistry packages in Debian: As part of the debichem project at Alioth, I recently added Gabedit, DRAWxtl and libint to our project SVN repository. All packages are in a fairly good state for an upload into the Debian NEW queue. Today we (Michael Banck and me) began with gabedit. The other packages will follow soon (I swear).

Also thanks to Abdul-Rahman Allouche, Larry Finger (and the other DRAWxtl authors) and Edward Valeev for these software packages and their response to my mails :)

Our SVN repository further contains Debian packaging files for the MOLDEN software package. Unfortunately we are currently not allowed to ship the MOLDEN source or binaries within Debian. However, you can use our SVN repository to build the package for yourself. Just install the svn-buildpackage package, download the MOLDEN source tarball and our SVN (wnpp/molden/), configure svn-buildpackage for this setup (a complete how-to will follow soon) and then build the package by running svn-buildpackage.

If you are interested in our work and/or if you want to help, subscribe to our mailing list and meet us there.

Monday, May 21, 2007

gURLChecker accepted into Debian

gURLChecker has been officially packaged for the Debian distribution. I'm therefor going to remove my own package of this piece of software from my repository. Updating to the official Debian packages should work without problems.

Monday, May 14, 2007

Etch, sftp and the rssh shell

And finally I discovered an issue. SFTP did not work anymore. The debug session showed:

[..]
debug1: Sending subsystem: sftp
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.2 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 0

The user only has the RSSH shell (sftp enabled) and he is further limited by the following entry in .ssh/authorized_keys:

command="/usr/lib/sftp-server" [SSH-key]

But this doesn't work anymore. /usr/lib/sftp-server now is a symlink to /usr/lib/openssh/sftp-server and I had to change the .ssh/authorized_keys for the user to:

command="/usr/lib/openssh/sftp-server" [SSH-key]

and access is granted again.

Update

This one can be found in syslog:

rssh[xxx]: user XXX attempted to execute forbidden commands
rssh[xxx]: command: /usr/lib/sftp-server

Sarge -> Etch transition

Yesterday I've finally updated my server from Sarge to Etch (around 300 packages to update, 100 newly installed, 15 to remove). The whole transition went smooth in a screen session in about 4 hours or so.

  1. I began with a normal upgrade as suggested by the release notes.
  2. The next step introduced the new initrd-tools and libc6 to the system ...
  3. ... followed by the installation of a new linux-image and udev.
  4. The last step in updating the packages involved a complete dist-upgrade.
  5. Then it was time for a reconfiguration of all the services, that installed massively changed config files [1] and fixing all the chroots and broken package configurations caused by package transitions.
  6. The reboot brought up the system at first go. Checking with dmesg and bootlogd did not show any serious issues: /dev ok and all services up and running with the new kernel. So besides a few modules, which are not longer available or changed their name, no issues occured.
  7. With the new system up and running I did some cleanup, removing unused packages and those, that were removed in Etch (all together around 25).

That's all. New system up and running (with a few configuration works left) and no need to restore the system from the image :). So yes, I'm satisfied. Let's see, if issues will occur later.

[1] In this case I installed the package maintainers version and re-added my changes later.

Thursday, February 15, 2007

Let file(1) recognize a chemical MIME type - the next level

As written earlier, the file command may detect chemical MIME types, if you feed its database with the necessary definition rules. Now check out the cmd.magic.mime file and run the file command with

$ file -m cmd.magic.mime -i your_test_file.ext

for one or more chemical files. The detection is limited to chemical MIME types, that have magic pattern in the chemical-mime-data database.

The file cmd.magic.mime was created via XSLT conversion of the original chemical-mime-data database and can be used for KDE and file(1). One of the following package releases (probably 0.1.95) will provide it.

Update

Unfortunately this magic.mime file cannot be used for KDE. As pointed out by David Faure, KDE uses an older syntax that doesn't know e.g. the search type. So I have to find another solution for KDE or wait for better days.

Tuesday, February 13, 2007

Let file(1) recognize a chemical MIME type

Ok, it's 8 o'clock in the morning and I need some sleep. But first let's show you some small example, how to detect chemical MIME types with the file(1) command. Put the following stuff into your /etc/magic (the local magic data configuration file for the file(1) command):

0               string          VjCD0100                CDX binary file
>8              belong          0x04030201
>>12            bequad          0x0000000000000000
>>>20           beshort         0x0000
>>>>34          string          ChemDraw                written with ChemDraw
>>>>>42         string          x                       b%.4s
>>>>22          beshort         0x0080                  (new format)
>>>>22          beshort         0x0000                  (old format)

Now search for a CDX (ChemDraw binary) file and run the file command:

$ find . -name "*.cdx" -exec file "{}" ";"
./example.cdx: data (that's really broken)
./dummy.cdx: lif file (that's a CACTVS file in reality)
./x-chemdraw/structures25-27.cdx: CDX binary file written with ChemDraw 4.5 (old format)
./x-chemdraw/structures96-101.cdx: CDX binary file written with ChemDraw 4.5 (old format)
./x-chemdraw/structures40-48.cdx: CDX binary file written with ChemDraw 4.5 (old format)
./x-chemdraw/dimethylamine.cdx: CDX binary file written with ChemDraw 7.0 (old format)
./x-chemdraw/dimethylaminesimple.cdx: CDX binary file (old format)
./x-chemdraw/untitled.cdx: CDX binary file written with ChemDraw 8.0 (new format)
./x-chemdraw/structures1-12.cdx: CDX binary file written with ChemDraw 4.5 (old format)

Why I do this? The chemical-mime-data package contains magic pattern, that can be used to automatically create the rules for the file command too, so file(1) can determine the chemical MIME type too. Expect a stylesheet to extract this information from the database soon.

And now I will get some sleep.

Update

And here, how to recognize the MIME type. Add the following to /etc/magic.mime:

0               string          VjCD0100
>8              belong          0x04030201
>>12            bequad          0x0000000000000000
>>>20           beshort         0x0000
>>>>22          beshort         0x0080                  chemical/x-cdx
>>>>22          beshort         0x0000                  chemical/x-cdx

and run the file(1) command with the -i switch:

$ find . -name "*.cdx" -exec file -i "{}" ";"
./example.cdx: application/octet-stream
./dummy.cdx: application/octet-stream
./x-chemdraw/structures25-27.cdx: chemical/x-cdx
./x-chemdraw/structures96-101.cdx: chemical/x-cdx
./x-chemdraw/structures40-48.cdx: chemical/x-cdx
./x-chemdraw/dimethylamine.cdx: chemical/x-cdx
./x-chemdraw/dimethylaminesimple.cdx: chemical/x-cdx
./x-chemdraw/untitled.cdx: chemical/x-cdx
./x-chemdraw/structures1-12.cdx: chemical/x-cdx

And now I really get some sleep. Cheerio!

Monday, February 5, 2007

chemical-mime-data 0.1.94 released

Today I released a new version of the chemical-mime-data package, namely 0.1.94. This version adds and improves support for various chemical MIME types (see below). It fixes several build issues and improves some detection and build stuff. The RH bug #225095 (SF.net bug #1616568) has been fixed. The TODO list is now also a little bit shorter, because several items (source and package documentation) have been done with this release too.

This version adds support for:

  • chemical/x-cactvs-ascii
  • chemical/x-cactvs-binary
  • chemical/x-cactvs-table
  • chemical/x-cdxml
  • chemical/x-gamess-output
  • chemical/x-gulp
  • chemical/x-ncbi-asn1
  • chemical/x-ncbi-asn1-binary
  • chemical/x-ncbi-asn1-xml

Support has been improved for:

  • chemical/x-cdx
  • chemical/x-cml
  • chemical/x-cif
  • chemical/x-dmol
  • chemical/x-gamess-input
  • chemical/x-gaussian-input
  • chemical/x-gaussian-log
  • chemical/x-genbank
  • chemical/x-hin
  • chemical/x-inchi
  • chemical/x-inchi-xml
  • chemical/x-mdl-rxnfile
  • chemical/x-mmcif
  • chemical/x-mol2
  • chemical/x-msi-car
  • chemical/x-msi-hessian
  • chemical/x-msi-mdf
  • chemical/x-msi-msi
  • chemical/x-pdb
  • chemical/x-shelx

The full release changelog can found at the SF.net project site.

An updated Debian package will be available soon in the experimental tree (not in sid because of the release freeze).

Saturday, February 3, 2007

Ubuntu packaging support stopped / Ubuntu-Unterstützung gestoppt

English: Ubuntu support will be stopped and the repository for packages built for Ubuntu removed.

Deutsch: Ich möchte Ubuntu nicht länger unterstützen und habe alle Pakete für Ubuntu aus dem Repository entfernt.