Bug#627391: ITP: prank -- The Probabilistic Alignment Kit for biological sequences
Package: wnpp Severity: wishlist Owner: Manuel Prinz * Package name: prank Version : 100802 Upstream Author : Ari Loytynoja * URL : http://www.ebi.ac.uk/goldman-srv/prank/src/prank/ * License : GPL2+ Programming Lang: C++ Description : Probabilistic Alignment Kit for biological sequences PRANK is a probabilistic multiple alignment program for DNA, codon and amino-acid sequences. It's based on a novel algorithm that treats insertions correctly and avoids over-estimation of the number of deletion events. . In addition, PRANK borrows ideas from maximum likelihood methods used in phylogenetics and correctly takes into account the evolutionary distances between sequences. Lastly, PRANK allows for defining a potential structure for sequences to be aligned and then, simultaneously with the alignment, predicts the locations of structural units in the sequences. The package was prepared during the Debian Med meeting in Travemünde and is mostly ready for uploading to the archive. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110520094548.GA9730@woodstock
Re: Is tabular data in binary format acceptable for Debian ?
Am Mittwoch, den 20.01.2010, 15:42 +0100 schrieb Andreas Tille: > Yes, but you can not assume that ftpmaster is an R *user* Of course I can't but I do not see why ftpmasters should care how to extract data from these files. The only relevant information to them is that the data is the preferred form of modification. > nor is README.Source a document which is targeting at an end user. True. It's targeted at maintainers. And if one maintains an R package or is interested in maintaining one, I assume(d) that that person is familiar with R. I do not see a use case where such a data export is relevant in (for example) an NMU scenario. If the NMUer needs to change the data, doing a little R scripting is needed anyway, so I can safely assume that person to know R. I understand the use case Martin has mentioned in his email that a user might want to extract/convert that data. In this case, if Debian is really the place to provide that information, it is better suited in README.Debian and a more general place, like r-base, as it is the same for every R extension. There is no need to duplicate that in each and every package, IMHO. Also, in case this changes, one has to update a huge amount of packages. That's also the reason why we do link to quilt and dpatch in that file[0]. I'm sorry if it sounds harsh, that is not my intention. It just feels like a huge overhead for no gain. I've not checked but I guess OOo does not contain information about how to extract all headers from an .odf in README.Source. Best regards Manuel [0] The situation with them is a little different, as they are needed to build a Debian package. Fiddling with .Rdata files is a modification of upstream source. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Is tabular data in binary format acceptable for Debian ?
Am Mittwoch, den 20.01.2010, 11:22 +0100 schrieb Andreas Tille: > On Wed, Jan 20, 2010 at 07:07:38PM +0900, Charles Plessy wrote: > > this time, I disagree with you: all the above is a lot of work that I am not > > willing to do. A user of the R software is able to do this conversion by > > himself, so I do not see what is the added value here. > > Well, my compromise suggestion was intended to be a fallback if > ftpmaster insists on the rejection. I do not expect them to, as they have been very open to reasonable arguments in the past. (At least that is my experience.) Adding HOWTOs to README.Source is IMHO not worth the overhead it produces on the maintainer's side. Every R user knows (well, should know) how to deal with those files. If that's not the case, this is documented elsewhere already. > I understood Ben's wording exactly this way that the R format actually > *is* the prefered format for an R related package - so Ben (and me) are > agreeinig with you that the source format is fine. I understood it this way as well. Speaking as an R user, Rdata is definitely the "preferred form of modification". You load it into R, edit it, save it, done. So +1 for "preferred form of modification". Best regards Manuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#540813: ITP: gamessq -- gamess scheduling frontend
Am Dienstag, den 11.08.2009, 11:00 +0200 schrieb Michael Banck: > Well, for general-purpose job scheduling, see recent threads on > debian-science. There are at least slurm-llnl and gridengine (though > both very heavy-weight), Though SLURM is not the smallest resource manager around, it's very, very easy to set up and maintain -- and well documented. (I know people using it on multi-core desktop machines.) GAMESS input file creation could probably be scripted and used in SLURM via hooks. That said, I have nothing against GamessQ being in Debian. I'd be quite nice to have Gamess in main, though. But that's not going to happen, I fear... Best regards Manuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Alioth - Convert SVN repo to Git
Am Dienstag, den 24.03.2009, 14:40 +0100 schrieb Sandro Tosi:
> Additionally, I'm looking for a post-commit hook that can send the
> commit diff via email to a ml + tagpending the bugs in the diff. I'm
> pretty sure someone out there has this script ready yet, so let's
> share :)
If you have your Git repo on Alioth, everything needed is already
available:
$ git config --add hooks.mailinglist "{user@,l...@lists.}debian.org"
$ cat >hooks/post-receive <
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: MPI binaries location
Hi Jean! Am Dienstag, den 10.03.2009, 17:29 +0100 schrieb Jean Parpaillon: > I'm currently packaging hpcc (HPC Challenge Benchmark). Several binary > packages will be available, each one with different mpi implementations. Is > there a preferred place to put mpi binaries ? I've seen that each mpi > implementation has it's own bin/lib/share/include/etc hierarchy into > /usr/lib/ > > Should I put the binaries into it ? If MPI applications are build against multiple MPI implementations, the usual way is to build binaries like hpcc.openmpi, hpcc.mpich, and so on and use update-alternatives to provide /usr/bin/hpcc. [0] If you'd like to look at an example, have a look at the gromacs source package. Best regards Manuel [0] Don't know about the actual executable name, but you'll get the idea. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Proposal of two new control fields: Build-Recommends and Build-Suggests [long reading]
Hi Fabian! Am Dienstag, den 10.02.2009, 13:25 +0100 schrieb Fabian Greffrath: > Steve Langasek schrieb: > > This is a very bad idea. It interferes with reproducibility of binary > > builds, which is a very important property of Debian packages. Packages > > must *not* build differently based on opportunistic discovery of > > build-dependencies on the system - it's a bug for any package to do so, let > > alone to be specifically encouraging this behavior with debian/control > > fields! > > Alright, this speaks clearly against Build-Recommends. However, would > you consider at least Build-Suggests useful enough to support them? If I got your proposal right, your use-case for Build-Suggests is that the package builds using additionally installed (development) packages, if they are already installed. A different method to achieve the same goal is to add a new option to DEB_BUILD_OPTIONS, in your case "nonfree-codecs" or something alike. You can check if it is set in debian/rules and change the build process accordingly to make use of the additional development packages. It has the drawback that you need to rely on the packages being installed already, so you may need to document it in README.Debian (or somewhere more appropriate) along with the option to pass in DEB_BUILD_OPTIONS but that's the same situation with your suggested Build-Suggests. (And as Neil pointed out, debian/rules should always behave in an "off" mode, meaning that the option only has an effect if it is set explicitely.) So all one needs to do to get the package with the non-free parts is to install the non-free -dev packages and do regular rebuild with DEB_BUILD_OPTIONS="nonfree-codes". That's easy enough, I think, and you do not need to modify the existing tools at all. Best regards Manuel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: ITP: mpi-defaults -- Meta-packages depending on appropriate MPI -dev and -bin packages for each platform
Am Donnerstag, den 20.11.2008, 09:45 -0500 schrieb Adam C Powell IV: > It uses the PETSc system, which Build-Depends on an arch-dependent MPI > implementation, then rules uses readlink to determine which one is the > default alternative, and sets substvars appropriately, whether openmpi, > lam, or mpich*. That way, if we want to change the defaults, we just > need to change the Build-Depends in control. In many other ways it > follows the example of java-common. Sounds good. > Also, I made it GPL 2+, and made the copyright in the model of > java-common. I've no strong feelings about that. > Feedback anyone? I was just wondering why you depend on debhelper >= 3, while compat is set to 5. Souldn't you depend on >= 5 then? All other things look good, though I did not test it yet. Thanks for your work! Best regards Manuel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: ITP: mpi-defaults -- Meta-packages depending on appropriate MPI -dev and -bin packages for each platform
Am Mittwoch, den 19.11.2008, 09:05 -0600 schrieb Dirk Eddelbuettel:
> I think we should put either debian or mpi first. How about
>
> mpi-default-{dev,bin}
>
> or even
>
> mpi-debian-default-{dev,bin}
>
> to make it even clearer that it is just 'us' (ie Debian) defining a default
> for us, rather misconstruing that more than two decades (I'm guessing) of
> competing mpi implementations have ended ? ;-)
Good guessing. But I'm confident we can solve that problem in one way or
another in a shorter time frame.
> Comments ?
Well, why not debian-default-mpi-{bin,dev}? ;)
Seriously, I do not care that much. A name is a name. If we're lucky,
the package might be gone by release of Squeeze.
Best regards
Manuel
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: Should the X packages pre-depend on awk?
Hi Jörg! Am Donnerstag, den 31.07.2008, 09:27 + schrieb Jörg Sommer: > recently, I've installed a new system with a minimal configuration. Then > I've imported my old package selection with dpkg --set-selections and run > apt-get dselect-upgrade. This replaced the mawk package by the gawk > package and installed some X package at the same time. > [...] > But x11-common and many other X packages use awk in their maintainer > scripts. [...] > So, must these packages pre‐depend on awk? No. They can rely on awk to be installed. awk is a dependency of package base-files, which is essential. By that, awk is always installed and x11-common can use awk in the maintainer scripts without the need to declare a dependency. Both the gawk and mawk packages provide the virtual package awk, so as long as base-files is concerned, either one satisfies the dependency. Best regards Manuel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Help: Strange 64bit issue
Hi Andreas! Am Dienstag, den 08.07.2008, 14:26 +0200 schrieb Andreas Tille: > On Mon, 7 Jul 2008, William Pitcock wrote: > > > If you do build-depends on gcc-multilib and g++-multilib, it should fix > > this problem. > > As I said it fixes the build problem - but now I have a package with a > not working executable. I guess it is also a simple 64 bit problem which > might be easily solved by people with multiarch experience: With these fixes it still did not build on my system. I needed to change the Build-Depends on lib64z1-dev into zlib1g-dev to get it to build in a clean pbuilder chroot. > > On Mon, 2008-07-07 at 22:56 +0200, Andreas Tille wrote: > >> > >> svn://svn.debian.org/svn/debian-med/trunk/packages/maq/trunk/ > > If I build this stuff I get a package containing /usr/bin/maq (besides > some Perl scripts). The problem is: > > > $ /usr/bin/maq > -bash: /usr/bin/maq: cannot execute binary file > $ ldd /usr/bin/maq > ldd: exited with unknown exit code (126) I cannot reproduce this on my amd64 machine. With the change mentioned above it builds fine and I'm able to run /usr/bin/maq on both lenny and sid. Some output: $ /usr/bin/maq 2>&1 | head -n 4 Program: maq (Mapping and Assembly with Qualities) Version: 0.6.7 Contact: Heng Li <[EMAIL PROTECTED]> $ file /usr/bin/maq /usr/bin/maq: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), stripped $ ldd /usr/bin/maq linux-vdso.so.1 => (0x7fff2d7fe000) libz.so.1 => /usr/lib/libz.so.1 (0x2abe7d4cd000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x2abe7d6e4000) libm.so.6 => /lib/libm.so.6 (0x2abe7d9f) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2abe7dc7) libc.so.6 => /lib/libc.so.6 (0x2abe7de87000) /lib64/ld-linux-x86-64.so.2 (0x2abe7d2b1000) Best regards Manuel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Help with #472953
Hi Enrico! Am Donnerstag, 19. Juni 2008 23:42:01 schrieb Enrico Zini: > Most important thing, I need the output of these two commands: > > ls /var/lib/apt/lists/*i18n_Translation* /var/lib/apt/lists/ftp.de.debian.org_debian_dists_sid_main_i18n_Translation-de > grep -h ^Description- /var/lib/apt/lists/*i18n_Translation* | cut -d: -f1 > | sort -u Description-de Description-de.noguide Description-md5 > If you would like to help more, then please also: > > 1. git clone git://git.debian.org/git/collab-maint/apt-xapian-index.git > 2. ./testrun > > let me know if it gives you errors or not. $ ./testrun Reading current timestamp failed: [Errno 2] No such file or directory: 'testdb/update-timestamp'. Assuming the index has not been created yet. Reading de translations... Traceback (most recent call last): File "./update-apt-xapian-index", line 410, in addon.obj.init(dict(values = values), progress) File "plugins/translated-desc.py", line 84, in init self.indexers.append(Indexer(lang, file)) File "plugins/translated-desc.py", line 36, in __init__ self.descs[pkg["Package"]] = pkg[desckey] File "/var/lib/python-support/python2.5/debian_bundle/deb822.py", line 95, in __getitem__ return self.__dict[key] KeyError: 'Description-de' > If instead you know exactly how the whole thing works and can directly > point me at the solution Unfortunately, I have no experience with Xapian at all but you can get back to me if you need further testing. Best regards Manuel signature.asc Description: This is a digitally signed message part.
Re: What about use xml for descriptions of packages?
First of all, I did not get it in my first reply that you spoke from a translaters point of view. I just have a very limited view on translation work, so my arguments may not be correct. Am Sonntag, den 25.05.2008, 16:05 +0200 schrieb Fernando Cerezal: > How can a program know if > > * A description sentence with > two lines > > and > > * A description sentence with > two lines > > are the same? As always: by definition. If you define that indentation matters, first one would be treated as two lines and the second as one. If you define that indentation does not matter and bullet points have to be seperated by an empty line (I think POD does something like this), then the first entry is one line. So the problem is a missing definition of how the formating should be treated by a parser, not a new document format. > Or other similar problem: The url of project web page changes, like this: > > Upstream URL: http://www.example.com > Upstream URL: http://www.example.com/project > > This is handled like a modification of the translation, and a > translator for every language needs to review that, and «translate» > it. For this case, the Homepage field exists. By using that, the Description does not need to be touched in any way. > The problem is that the number of descriptions translated grows lower > than the number of packages, and besides this, the translators have to > review older descriptions that have not new information, but change of > format, change of URLs and so on. I see the burdon that it brings to translators but I do not understand how XML may resolve those. URL should IMHO not be in the description as they are subject to change and a better alternative exists. If the format changes, the problem is to detect whether it is a "real" change. Checking for changes in whitespace are equally easy to detect in the old and an XML-based format. If new points are added to list or a point is split into two, you can not automatically detect and correct those in either format. > I think using XML, or HTML, and embed a tiny web browser into > synaptic, we can resolve part of the problem for translations and use > the benefits of HTML, like including images, real links for web pages, > links between packages that can be "easyly" handled. I'm still not convinced that these features have a benefit. > I write XML because is something I know. I mean markup tags. This is valid but I think there are better markup languages for that purpose that do not effect the readability of the document. Also, a lot of parsers for these language exists and they are easily transformable into other formats, such as (X)HTML. > The descriptions have a lot of lists, execute strings, urls, and so on. > If an item of a lists changes, we have to review all the list, find > the change, do it in the translations and send it to revision process. How does XML prevent a review here? > There is no convention with this [Homepage field]. Or if there is, it is not > used. There is. If it's not used, you can file wishlist bugs. > > I still do not see why the current scheme is limited. Can you give > > examples where special markup or links in the texts may be useful? > > lists, links, non-translatable strings (URLs, numbers of version), > changes in tabulation... All such things are covered by more readable markup languages, too. I agree that lists are a problem with the current format. > Perhaps my question is bad presented and it introduces noise to the > list. I'm sorry so. I do not think so. As said, at least I did not see that you spoke from a translator's point of view at first. Best regards Manuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What about use xml for descriptions of packages?
Am Sonntag, den 25.05.2008, 14:40 +0200 schrieb Fernando Cerezal: > I'm thinking about advantages and disadvantages of write the > description of the packages using XML. I like XML but it's a huge pain to write by hand. The current format is easy to read, easy to write and easy to parse. This is important and definitely not the case if it is XML. > I think using XML the descriptions can be rendered in different form > for text and graphical tools. If this something that is really needed, one could think about more sane such as allowing Markdown[1] for Description field. I thought about that for a while now but never really saw the need to have formatted text or code examples in a package description. IMHO those just do not belong there. And for cases where links are needed, special fields as the Homepage field exists which are properly shown in most tools. > As disadvantage, we will need to develop a robot that do format for > the current descriptions and translations and we will have to review > all of them. Ciertainly, this will be an huge job. I'd rather convince people to adpot a new format, not to decide for them whether they want it or not. Change by evolution, not revolution. > However, I think the current scheme of descriptions is very limitied > and is better to do it earlier than translate more descriptions and > then move all to a new format in the future. I still do not see why the current scheme is limited. Can you give examples where special markup or links in the texts may be useful? Best regards Manuel [1] http://en.wikipedia.org/wiki/Markdown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages with empty directories
Am Mittwoch, den 21.11.2007, 05:11 +0100 schrieb Michael Biebl: > All of my packages listed there are false positives. What I noticed > though, are a lot of packages, shipping empty /usr/sbin, /usr/bin/, > /usr/lib/ or /usr/include directories. > This directories, very likely, come from dh-make *.dirs templates. > Imo these template files are wrong and should be cleaned up. gromacs-openmpi is false positive. The empty /usr/bin results from bugs 451991/452047. Best regards Manuel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#441136: ITP: jfftw -- Java library to perform Fast Fourier Transformations (FFT)
Package: wnpp Severity: wishlist Owner: Manuel Prinz <[EMAIL PROTECTED]> X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: jfftw Version : 20070725 Upstream Author : Will Hossack <[EMAIL PROTECTED]> * URL : http://www.ph.ed.ac.uk/~wjh/teaching/Java/fft/ * License : GPL Programming Lang: C, Java Description : Java library to perform Fast Fourier Transformations (FFT) jfftw is a simple, and partial, Java interface to the highly optimised FFTW C-package from Matteo Frigo and Steven Johnson from the Department of Applied Mathematics, MIT. . jfftw is developed by Will Hossack from the School of Physics, University of Edinburgh, Scotland. . Homepage: http://www.ph.ed.ac.uk/~wjh/teaching/Java/fft/ -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (200, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation of Recommends by default on October 1st
Michael Tautschnig wrote: > Please consider two things: > - More than 90% of all processors are installed in embedded systems (of > course, > only on pretty few of them Debian is installed) > - (Debian) Linux is still more widely spread on server systems than on > Desktops > ([1,2] sorry, both are German) Thanks for the links, it was an interesting read! I was aware of the fact that Embedded Devices have to be taken into account, was well as servers and other non-desktop boxes. I don't want to ignore them but I think it's users are skilled enough to deal with the issue. > However, especially Desktop users must be handled with extra care, so probably > staying with the current state really isn't an option. What I'd propose is > not a > debconf question by apt, but rather the debian-installer. I'd follow this > approach for three reasons: > - debconf is used by the d-i anyway already, so no need for the APT-people to > add debconf-stuff > - the d-i may be pre-seeded, so auto-installs using the d-i may avoid > displaying > this question > - In case someone doesn't use d-i to setup systems there will be ways to > modify > the apt configuration anyway (be it copying or editing of config files or > whatever) > > What remains to be discussed is then, whether already installed systems should > get recommended packages or not. To go a little further, what would be a > proper > way of asking users whether they want their settings changed or not (apart > from > apt asking debconf questions). I agree with you here. I think that new installations aren't affected much because there are possibilities to work around the "problem" easily, as you have shown above. So the real problem is in the current transition. I would not like a debconf from apt either but can't really come up with a better solution. The only thing that comes into my mind to use a wrapper for apt-get that checks if APT::Install-Recommends being set in the preferences and prints a warning that the default behavior has changed and pointing to some document that describes the changes. Hope someone has a smarter idea. :) Best regards Manuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation of Recommends by default on October 1st
Russ Allbery wrote: > I think it's also particularly annoying for our two major recommended > package installation interfaces, aptitude and apt-get, to do the opposite > thing by default with this core of a feature. What a recipe for > confusion for the average user who doesn't know the history and doesn't > choose them based on their Recommends-handling behavior! We shouldn't be > substituting tool selection for configuration. Exactly. One thing I quite often experienced by introducing people to Debian is that they get all confused about the different behaviors of apt-get and aptitude. To most users, those tools are a way to install packages, and not knowing their history leads to confusing why they do the same task in different ways. Most of those are totally fine with installing "junk", as it was called by others on this thread. They like it because having all x-drivers on their system allows them to exchange graphic cards without much effort. It's done rarely, I know. But most of them are unexperienced users of either Debian or Linux and want things to "just work" which is the Debian way. And the Social Contract is about our users, and I think an identical behaviour in the apt tools and having Recommends is what the majority of users want. I use aptitude for my everyday work. On my desktop, I really appreciate pulling in Recommends. On cluster compute nodes, I don't. But I can turn it of easily without being "forced" to use apt-get just because I'm on a different type of machine. Compute nodes are what I'd call an "unusual installation", as the Policy states it for Recommends. So are Embedded Devices. (Of course, the definition of "usual" is always vague.) IMHO, having apt-get to install recommended packages is a good choice. It's not hard for the user with special needs to change it, even on a lot of boxes. It's the current Recommends: fields that are broken, not the tools. But IANADD. Best regards Manuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ITP: libpj-java -- The Parallel Java Library
Package: wnpp Severity: wishlist Owner: Manuel Prinz <[EMAIL PROTECTED]> * Package name: libpj-java Version : 20070703 Upstream Author : Alan Kaminsky <[EMAIL PROTECTED]> * URL : http://www.cs.rit.edu/~ark/pj.shtml * License : GPL Programming Lang: Java Description : The Parallel Java Library Parallel Java (PJ) is an API and middleware for parallel programming in 100% Java on shared memory multiprocessor (SMP) parallel computers, cluster parallel computers, and hybrid SMP cluster parallel computers. . Homepage: http://www.cs.rit.edu/~ark/pj.shtml -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable'), (200, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-amd64 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
