September 2006 - CRUX - lists.crux.nu

Want to checkout sources from SVN_site!
by Eric M. Fortner 16 Sep '06

16 Sep '06

Okay I am searching but need to hurry on this one. I have to rebuild my cd and want to use the Makefile from Head on the svnweb page but can not figure out how to check out the whole trunk from scratch. Can some please point me to the help page or give me the key string I need .........svn checkout http://crux.nu.....? ....please! Regards.... Eric

1 0

[security] crux-2.2/ports/opt/thunderbird/
by crux＠crux.nu 15 Sep '06

15 Sep '06

This is a notification of a security related commit in crux-2.2/ports/opt/thunderbird/: thunderbird: updated to version 1.5.0.7 - see http://www.mozilla.org/projects/security/known-vulnerabilities.html#thunder… Commit information: Author: jaeger Date: 2006-09-15 16:15:19 +0200 (Fri, 15 Sep 2006) URL http://crux.nu/svnweb/CRUX/revision/?rev=1887

1 0

[security] crux-2.2/ports/opt/firefox/
by crux＠crux.nu 15 Sep '06

15 Sep '06

This is a notification of a security related commit in crux-2.2/ports/opt/firefox/: firefox: updated to version 1.5.0.7 - see http://www.mozilla.org/projects/security/known-vulnerabilities.html#firefox… Commit information: Author: jaeger Date: 2006-09-15 05:16:09 +0200 (Fri, 15 Sep 2006) URL http://crux.nu/svnweb/CRUX/revision/?rev=1883

1 0

RE: Building X11R7.1
by Darran Kartaschew 14 Sep '06

14 Sep '06

Hi Will, Thanks for the link... really seems like the bz2/tgz tarballs that are available for download are borked... Looks like the only way to get x11r7.1 to compile successfully with all the patches is to download the whole lot via git! Doesn't really help me, since I don't have an active internet connection at home, and therefore am restricted to downloading it all at work and git has been blocked on the firewall/proxy here at work. (Hence why I went the bz2 tarball option for installation). :( PS. I can get passed the fault described in the link by manually patching the libX11 bz2 package, but there seems to be others in there that I have missed, and hence why xkbcomp fails... Darran ________________________________ From: William Lewis [mailto:minutemaidpark@hotmail.com] Sent: Thursday, 14 September 2006 10:06 To: Darran Kartaschew Subject: RE: Building X11R7.1 It may have something to do with this... http://lists.freedesktop.org/archives/xorg/2006-June/015852.html Maybe that will get you started... Will ________________________________ > Subject: RE: Building X11R7.1 > Date: Thu, 14 Sep 2006 08:37:39 +1000 > From: darran.kartaschew(a)pcanu.com.au > To: crux(a)lists.crux.nu > > > >-----Original Message----- > >From: crux-bounces(a)lists.crux.nu [mailto:crux-bounces@lists.crux.nu] On > Behalf Of lucas(a)die.net.au > >Sent: Tuesday, 12 September 2006 13:12 > >To: crux(a)lists.crux.nu > >Subject: Re: Building X11R7.1 > > > On Tue, Sep 12, 2006 at 12:02:13PM +1000, Darran Kartaschew wrote: > > Hi Guys, > > > > I'm currently reinstalling CRUX (due to a HDD failure), and decided to > > > try out Danm's v2.2 AMD64 test build. > > > > Being one for trying new stuff, I've successfully installed the latest > > > kernel revision and have decided to try out X11R7.1 from X.org (If I > > stuff it up, nothing's lost due to being a clean install). > > > > Anyway, I'm only getting about 90% the way through the install, with > > an error on xkbcomp causing a floating point exception when rebuilding > > > the keyboard template files? > > > > I've googled quite a bit and haven't come across anyone else with the > > same error. That leads me to believe that it may be distro related, > > rather than a bug in X (but if it's s bug, does anyone have a patch?). > > Or could it be related to GCC 4.0.3? (I know there are issues with > > Mozilla and gcc4.0.3). > > > > So if anyone has successfully built X11R7.1 on CRUX v2.2 (AMD64) using > > > gcc 4.0.3, can you please let me know how and what you did? > > > > If an upgrade to gcc 4.1.x is required, some pointers on the best way > > to update it would be appreciated. > > > > I'm trying to install straight from the bz2 tarballs (using that > > script provided), and have read through the README several times... (I > > > don't have an active internet connection at home, and the firewall at > > work currently blocks git:// so can't get the absolutely bleeding edge > > > source). > > > > Cheers, Darran > > > > PS. I do realise that Dan's build of CRUX v2.2 (AMD64) is considered a > > > test version and the build/project is effectively dead... > > PPS. A copy of this email has been sent to the crux64 ml, but don't > > know how many people still sunscribe to it... > > > >I'm been using danm's crux64 and x11r7 for a while now, I didn't > encounter any problems (short of having to modify a few ports that were > written with x11r6 in mind), and that is with gcc 4.0.3. > > > >Perhaps you could post the log for the build. More than 2 eyes are > better than 2...or something. > > > > > -- > Hi Guys, > > I've attached the last few lines of the compile output, and it's on the > execution of xkbcomp to generate compat.dir that xkbcomp generates a > floating point exception (not seen in the log). If you would like the > full log, let me know and I'll email it to you. (only 226kB bzip2). > > The build was started using the following command: > > # PATH=/usr/X11R7/bin:$PATH ./build-from-tarballs.sh -m > /opt/src_/X11R7/Mesa-6.5 /usr/X11R7 > > Darran > > ------------------- > > Building data module component xkbdata-X11R7.0-1.0.1... > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking whether to enable maintainer-specific portions of Makefiles... > no > checking for xkbcomp... /usr/X11R7/bin/xkbcomp > configure: creating ./config.status > config.status: creating Makefile > config.status: creating semantics/Makefile > config.status: creating keycodes/Makefile > config.status: creating keycodes/sgi/Makefile > config.status: creating keycodes/digital/Makefile > config.status: creating keymap/Makefile > config.status: creating keymap/sun/Makefile > config.status: creating keymap/digital/Makefile > config.status: creating keymap/sgi/Makefile > config.status: creating geometry/Makefile > config.status: creating geometry/digital/Makefile > config.status: creating geometry/sgi/Makefile > config.status: creating geometry/ibm/Makefile > config.status: creating compat/Makefile > config.status: creating rules/Makefile > config.status: creating symbols/Makefile > config.status: creating symbols/pc/Makefile > config.status: creating symbols/nec/Makefile > config.status: creating symbols/xfree68/Makefile > config.status: creating symbols/sony/Makefile > config.status: creating symbols/sgi/Makefile > config.status: creating symbols/macintosh/Makefile > config.status: creating symbols/sun/Makefile > config.status: creating symbols/fujitsu/Makefile > config.status: creating symbols/digital/Makefile > config.status: creating symbols/hp/Makefile > config.status: creating torture/Makefile > config.status: creating types/Makefile > config.status: creating config.h > make all-recursive > make[1]: Entering directory > `/opt/src_/X11R7/X11R7/data/xkbdata-X11R7.0-1.0.1' > Making all in semantics > make[2]: Entering directory > `/opt/src_/X11R7/X11R7/data/xkbdata-X11R7.0-1.0.1/semantics' > make[2]: Nothing to be done for `all'. > make[2]: Leaving directory > `/opt/src_/X11R7/X11R7/data/xkbdata-X11R7.0-1.0.1/semantics' > Making all in keycodes > make[2]: Entering directory > `/opt/src_/X11R7/X11R7/data/xkbdata-X11R7.0-1.0.1/keycodes' > Making all in digital > make[3]: Entering directory > `/opt/src_/X11R7/X11R7/data/xkbdata-X11R7.0-1.0.1/keycodes/digital' > make[3]: Nothing to be done for `all'. > make[3]: Leaving directory > `/opt/src_/X11R7/X11R7/data/xkbdata-X11R7.0-1.0.1/keycodes/digital' > Making all in sgi > make[3]: Entering directory > `/opt/src_/X11R7/X11R7/data/xkbdata-X11R7.0-1.0.1/keycodes/sgi' > make[3]: Nothing to be done for `all'. > make[3]: Leaving directory > `/opt/src_/X11R7/X11R7/data/xkbdata-X11R7.0-1.0.1/keycodes/sgi' > make[3]: Entering directory > `/opt/src_/X11R7/X11R7/data/xkbdata-X11R7.0-1.0.1/keycodes' > rm -f keycodes.dir > /usr/X11R7/bin/xkbcomp -lfhlpR -o keycodes.dir '*' > make[3]: Leaving directory > `/opt/src_/X11R7/X11R7/data/xkbdata-X11R7.0-1.0.1/keycodes' > make[2]: Leaving directory > `/opt/src_/X11R7/X11R7/data/xkbdata-X11R7.0-1.0.1/keycodes' > Making all in keymap > make[2]: Entering directory > `/opt/src_/X11R7/X11R7/data/xkbdata-X11R7.0-1.0.1/keymap' > Making all in sun > make[3]: Entering directory > `/opt/src_/X11R7/X11R7/data/xkbdata-X11R7.0-1.0.1/keymap/sun' > make[3]: Nothing to be done for `all'. > make[3]: Leaving directory > `/opt/src_/X11R7/X11R7/data/xkbdata-X11R7.0-1.0.1/keymap/sun' > Making all in digital > make[3]: Entering directory > `/opt/src_/X11R7/X11R7/data/xkbdata-X11R7.0-1.0.1/keymap/digital' > make[3]: Nothing to be done for `all'. > make[3]: Leaving directory > `/opt/src_/X11R7/X11R7/data/xkbdata-X11R7.0-1.0.1/keymap/digital' > Making all in sgi > make[3]: Entering directory > `/opt/src_/X11R7/X11R7/data/xkbdata-X11R7.0-1.0.1/keymap/sgi' > make[3]: Nothing to be done for `all'. > make[3]: Leaving directory > `/opt/src_/X11R7/X11R7/data/xkbdata-X11R7.0-1.0.1/keymap/sgi' > make[3]: Entering directory > `/opt/src_/X11R7/X11R7/data/xkbdata-X11R7.0-1.0.1/keymap' > rm -f keymap.dir > /usr/X11R7/bin/xkbcomp -lfhlpR -o keymap.dir '*' > make[3]: Leaving directory > `/opt/src_/X11R7/X11R7/data/xkbdata-X11R7.0-1.0.1/keymap' > make[2]: Leaving directory > `/opt/src_/X11R7/X11R7/data/xkbdata-X11R7.0-1.0.1/keymap' > Making all in compat > make[2]: Entering directory > `/opt/src_/X11R7/X11R7/data/xkbdata-X11R7.0-1.0.1/compat' > rm -f compat.dir > /usr/X11R7/bin/xkbcomp -lfhlpR -o compat.dir '*' > make[2]: Leaving directory > `/opt/src_/X11R7/X11R7/data/xkbdata-X11R7.0-1.0.1/compat' > make[1]: Leaving directory > `/opt/src_/X11R7/X11R7/data/xkbdata-X11R7.0-1.0.1' ________________________________ Express yourself with gadgets on Windows Live Spaces Try it! <http://discoverspaces.live.com?source=hmtag1&loc=us>

1 0

Diverting from upstream
by Mark Rosenstand 08 Sep '06

08 Sep '06

Hi, One of my personal likings of CRUX is that it's easy to customize and extend. Because it (used to?) keep as close to upstream as possible, there tend to be fewer distribution-specific bugs. A couple of days ago I saw that the openbox port was moving a file because the maintainer thought it was misplaced, but it wasn't (see http://crux.nu/svnweb/CRUX/revision/?rev=1781) - since the maintainer happened to be tilman, the change was reverted 5 seconds after I told him it was bogus and 10 seconds before I requested a revert :) I've been using/packaging the dchroot utility from Debian for a while. It's a small setuid utility to allow regular users to chroot into a specified list of directories. Because the path of 'su' is hardcoded to /bin/su and CRUX keeps su in /usr/bin/su, I've only used it for Debian chroots (running on CRUX) so far. Now, the other day I accidently looked at the shadow Pkgfile, and to my surprise su is actually installed in /bin and then moved manually to /usr/bin. To avoid these kinds of distribution-specific problems, I'm kindly asking packagers to think twice before deciding to divert from upstream - perhaps even limiting it to "required for essential functioning of the package" and basic CRUX integration (no nls, man-pages in /usr/man, etc.) :)

3 6

RE: Diverting from upstream
by William Lewis 08 Sep '06

08 Sep '06

> Subject: Re: Diverting from upstream> From: mark(a)borkware.net> To: crux(a)lists.crux.nu> Date: Fri, 8 Sep 2006 12:59:35 +0200> > On Fri, 2006-09-08 at 12:25 +0200, Tilman Sauerbeck wrote:> > Mark Rosenstand [2006-09-08 11:53]:> > > On Fri, 2006-09-08 at 11:27 +0200, Tilman Sauerbeck wrote:> > > > Mark Rosenstand [2006-09-08 10:44]:> > > > > > > > > One of my personal likings of CRUX is that it's easy to customize and> > > > > extend. Because it (used to?) keep as close to upstream as possible,> > > > > there tend to be fewer distribution-specific bugs.> > > > > > > > We _still_ do. But it's probably related to the fact that we don't read> > > > all of the code of the software we're packaging and that we don't fix> > > > any and all bug (-> Debian ;D).> > > > > > Totally fair, and that's also why I argue that keeping close to (if not> > > verbatim) upstream is the best bet for a project the size of CRUX.> > > > Sure, I think everyone agrees here.> > :)> > > > Unfortunately I've had to fork some opt packages lately. For example, I> > > depend largely on GTK+ (GNOME desktop) so I just don't dare to patch it> > > for something I have no clue what does> > > (http://crux.nu/svnweb/CRUX/revision?rev=1701)> > > > You could had asked Matt, Johannes, or me about it (it was kinda a group> > effort to get that bug nailed :)> > The patch has been incorporated into GTK+ 2.10.2, btw. See the changelog> > for the bug ID (it's tiny, I'm too lazy to look it up right now).> > > > I think it's safe to assume that your GTK maintainer depends largely on> > GTK+/Gnome, too...> > > > I think applying that patch was the right thing to do...> > If it was a bug fix, sure! The problem is that there were no description> of what it did, "added cptn's modified stock icon patch" doesn't tell> much. The fact that it fixed a bug, and preferably what bug it fixed as> well as it was applied upstream would have been really nice additions to> that commit message. (This is a general problem, I think. Take> http://crux.nu/svnweb/CRUX/revision/?rev=1678 for instance.)> > > > I think that recently there have been a growing number of patches in> > > core and opt - are upstreams just getting insane? I get the feeling that> > > the heavy patching is also the primary reason we're stucked with years> > > old versions of things such as grub.> > > > I don't share the feeling that core and opt are getting more patches> > recently. I'm not saying it's not true, I just didn't notice it.> > It could just be me being more sensitive to this :)> > > Regarding grub - the version we're using isn't actively developed> > anymore AFAIK. Switching to the new development branch seems a bit risky> > to me. I'd rather stick to the old version here.> > I'm all for sticking to the widely used 0.x branch, but 0.95 is 2.5> years old and 0.97 have been available for more than a year.> > The patches applied to 0.95 include additions of essential features such> as support for splash images, and there's so many that they're> distributed in an out-of-tree tarball!> > > > > > To avoid these kinds of distribution-specific problems, I'm kindly> > > > > asking packagers to think twice before deciding to divert from upstream> > > > > - perhaps even limiting it to "required for essential functioning of the> > > > > package" and basic CRUX integration (no nls, man-pages in /usr/man,> > > > > etc.) :)> > > > > > > > Uh uh, I actually thought twice before doing that Openbox commit.> > > > I even contact upstream, ziomg! ;)> > > > > > Ah, true, you said that. I shouldn't have used that as an example, it> > > was rather a case of "shit happens" :)> > > > > > The autoconf 2.60 mandir patch was probably a better example.> > > > Agreed, that was a bit silly. We also already discussed that matter ;)> > I don't see how one case of "shit happens" and one case of sillyness> > shows a trend of messing up opt ;D> > Those were just the ones on the top of my head, but I have to admit that> I don't understand what all the shadow patches are for. Some comments in> the patch headers or in the Pkgfile would be warmly welcomed - after all> there's a lot of tinkerers in the CRUX crowd (cruwd? OK, no more coffee> on my day off) :)> I have to agree with this, and more than once, I've been bitten by the shadow port in particular. Just last night I was trying to update dbus, and when I went through the pre-install items (as distributed in the port's README), I couldn't execute useradd -n -g because of the port. Even removing the -n option still gave me an error about those two being mutually exclusive. I can figure it out, it's just that I don't want to. And I think the shadow patches may be to blame. If not, shouldn't the README in dbus be changed? _________________________________________________________________ Check the weather nationwide with MSN Search: Try it now! http://search.msn.com/results.aspx?q=weather&FORM=WLMTAG

2 1

blocksize
by Matthias Pfeifer 08 Sep '06

08 Sep '06

Hello list, What would be a good number for the blocksize of an ext3 root-filesystem. My root-fs is 4.7 Gb and it keeps everything instead of home. After installation of crux and some additional packages (linux, gnuplot, tetex, prolog, xemacs, lmbench) and keeping the sources - there are 3.5 Gb in use (2.0 Gb for sources where only tetex takes 865 Mb). Are these common values? Is it possible that these numbers are too big and that this is due to my blocksize? I guess i have a default value... A directory node taks 4k. Is this my blocksize? What would be a good value? How do i figure out the exact value? How is the blocksize related to the pagesize? Do they have to be equal? Is there a problem with a too low blocksize, is there any? Please help.. matthias pfeifer PS: Is there a way to search the list-archive?

2 5

Server Migration documentation rsync update
by Clemens Koller 07 Sep '06

07 Sep '06

Hello! I've just tempted to follow http://crux.nu/Main/ServerMigration to get an pretty old CRUX2.1 server updated from the old ports collection to the new one. The ports.prt.tar.gz part works fine but rsync-2.6.7 is not available at samba.org at the mentioned place. It's 2.6.8 now. After updating the Pkgfile and the md5, everything seems to work fine. Can you please update your rsync.prt.tar.gz? Attached are my changes. Beside that, the document is fine! Next step would be a CRUX 2.1 to CRUX 2.2 migration. A link to some documentation for that would be fine... Best greets, -- Clemens Koller _______________________________ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19 --- Pkgfile~ 2006-03-13 22:15:05.000000000 +0100 +++ Pkgfile 2006-08-08 10:39:18.000000000 +0200 @@ -4,7 +4,7 @@ # Depends on: openssh name=rsync -version=2.6.7 +version=2.6.8 release=1 source=(http://samba.org/ftp/$name/$name-$version.tar.gz \ rsyncd.conf rsyncd rsync.driver) 082a9dba1f741e6591e5cd748a1233de rsync-2.6.8.tar.gz 7e01fb425c40a8c10c86f3a80aec9e41 rsync.driver a71995f22768c931c5649a1336d25ffb rsyncd b4e95fa8c8f3ae13cfdf616abd6a3960 rsyncd.conf

10 26

CRUX from LFS
by Clemens Koller 07 Sep '06

07 Sep '06

Hi There! I want to migrate a selfmade proprietary LFS embedded powerpc system to follow the CRUX look&feel by hosting port repositories for my architecture and use the crux package tools to keep several of those machines in sync and up to date. 1. Is there some documentation available for the lazy guys (i.e. from the CRUX-PPC folks) to avoid duplicate brainwork? Any pointers would be appreciated. 2. Is it possible / a good idea to build the ports db by package-by-package migration (installation / update) via my own ports tree just starting it, installing over the existing system? And once this is finished, is it a good idea to remove the files carefully from the filesystem which are not part of a package in the db? Is there a way to show/remove stale files from the system which are not needed (not in the db) anymore? Thanks, -- Clemens Koller _______________________________ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19

3 3

Re: CRUX from LFS
by Clemens Koller 07 Sep '06

07 Sep '06

Hi, Giorgio Giorgio Agrelli wrote: > Hello Clemens, > Unfortunately we don't have a mailing list... we might open one international > mailing list on slackware.it, i have to ask a friend... Do you think it could > be helpful?? I'm not sure about how many persons would subscribe to it, > probably very few... but if that could help the development and the users... > well, let's do it! ;-) Hmm, I prefer mailing lists because the main OpenSource development communication is going on in mailing lists. I am subscribed to about 15 lists. Checking 15 different places for information is just not efficient for me. >> (BTW: cruxppc.sunsite.dk is way too slow for serious work over here) > > > are you talking about the forum??? well the new look is really ugly i think, > i've been asking giulivo to change that but he became lazy lately... :-( > But it doesn't look so slow to me... I don't care much about the design, as long as the content is okay. But the speed is reallly far off comfortable! It takes about 10 seconds to load http://cruxppc.sunsite.dk/wp/index.php to see the content, about 10 more seconds to finish loading with the white background. Reading the forum means getting a coffee-addict first. I see no way to get me on that train. >> I think that my system - an MPC8540 embedded PPC (BookE, e500 core) >> should be able to get along with the default ppc stuff most of the time. > > > I hope it will! :) anyway if you want to join the development team, you're > welcome... Thanks! > we should change quite a bit of things (site, forum, cvs accounts > on sunsite) to manage working together, but i hope we will eventually manage > to have things fixed. I hardly work with cvs. I prefer git which is more powerful. As already mentioned, I think about getting a root-server for all my stuff. Hmm... pkgtools, prt-get, httpup are working fine - out of the x86 tree. I just have to manually get rid of my old out-of-db files first when I install packages. An example of the new ppc stuff as of today: root@ecam:/usr/ports/core/udev$ pkgmk -i =======> Package '/usr/ports/core/udev/udev#096-4.pkg.tar.gz' is up to date. =======> Installing '/usr/ports/core/udev/udev#096-4.pkg.tar.gz'. pkgadd /usr/ports/core/udev/udev#096-4.pkg.tar.gz etc/udev/rules.d/25-lfs.rules etc/udev/udev.conf sbin/udevcontrol sbin/udevd usr/bin/udevinfo usr/bin/udevtest usr/sbin/udevmonitor pkgadd: listed file(s) already installed (use -f to ignore and overwrite) =======> ERROR: Installing '/usr/ports/core/udev/udev#096-4.pkg.tar.gz' failed. root@ecam:/usr/ports/core/udev$ prt-get listinst httpup ports prt-get Is there already a way to get the conflicting files out of my LFS-tree moved to i.e. var/lib/pkg/removed/... and with the names written to a logfile? The -f is too destructive for me, I want to be able to go back to the previous version if I run into troubles. > The point is that i suspect giulivo is not interested any more in the > development of crux-ppc; in the past he destroyed big part of the work i did > on 64bit systems and on documentation (and of course i was mad for that so for > a long while i wasn't willing to do anything for crux-ppc) to have something > similar to crux 2.2 the quick and dirty way. Then he abandoned the thing > again, and left the cvs in a complete mess and i wasn't able to work with all > those screwed up files any more... > Well this stuff is irrelevant to you i'm telling just to explain our > "lazyness" lately... Okay, I understand. Time squeezes all men under it's foot like a bug. Just to give you a focus: For me, I am doing this (ppc stuff) at work for the company in this project (an embedded mobile high performance framegrabber). We have some Mac G4's here as well, with CRUX-2.0 on it. There was also a G5/64 but no CRUX on it yet due n/a of a distribution. I do have several x86 and x86-64 with crux on it at the company and at home. > The cvs tree is really messy now, anyway you should only look at ppc directory > now and gcc64 if your processor is 64bit (core and opt are obsolete); with the > new tree layout we only have ports that differ from the x86 tree (we used to > have all the ports, even the ones that were identical). I am 32bit only. We don't have a G5/64 here yet. I am just about to start a new tree... my toolchain (arch=ppc, -me500) (selfmade from scratch) will be in there as well in the future. > If you look at the cvs comments, sometimes there is an hint about the > differences... i proposed to add a field in the pkgfile to explain that but > none wanted to do that so we didn't do that any more... That's a pity. That's exactly the information which makes me happy. :-( > Anyway on the toolchain stuff and on other things you can ask me by mail if > you wish. Jep... currently, I have to get an efficient (hacked) solution as quick as possible as we want to go to a fair by sept. 26 and some new hardware should be up and running also. But after that and some vacation, I will be around to spend some time to crux, too, hopefully. :-) Best greets, Clemens Koller _______________________________ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19

1 0