configure is unusually picky about tiff version.
While at it, change the (invalid) `-disable-PAM' to `-disable-pam' and
stop requiring particular version of -ljpeg and -ltiff -- anything already
installed will do.
Kris notified the maintainer and myself (the last committer in this port)
yesterday, but the maintainer did not respond yet. Since the port remains
broken, I claim the "timeout" very early.
Notified by: kris
correctly (because then it is not utf8 valid as well)
Force converting the header and the xover data (usenet) to utf-8 in case
it isn't 7bit clean by assuming the header was written in the charset
locale(1) reports. That might be wrong, but I see no other way.
We can't detect the charset in which the header was written in (for
example, xover data doesn't have any informations in it about content-type)
because Content-Type only affecty the message-body.
Approved By: maintainer (implicit)
Taken From: sylpheed-claws gtk2 CVS branch
under long auto*tools name. This is untested as I'm unable to reproduce
the problem on my 6-CURRENT jail.
Reported by: pointyhat via kris
Suggested by: ade
messages should be also converted into utf-8 format.
That fixes the problem I had with wiped out lines containing non-7bit-clean
chars. (like german umlauts)
Bump PORTREVISION
sylpheed-gtk2 authors are informed...
- The email archive referenced is no longer available. Use
marc.theaimsgroup.com archive instead.
- Note that only 2.4.x versions are affected (earlier ones
are not).
Reported by: leeym
existing the Solaris base, and similarly to what happened with NSPR, made
a bad assumption on undefined behavior. This broke locking in various
places in Java, for example, causing the the debugging support to be
totally broken. It is worth someone who knows the Java codebase taking
a look to see what other things could have been broken by this on
FreeBSD 5.x+.
The assumption is that pthread_mutex_trylock(3) on a default-type
mutex will fail with EBUSY. This assumption is wrong for our
libpthread, which returns EDEADLK if the owner thread is trying to
acquire the mutex again with trylock. The behavior of performing a
locking operation on a self-locked default-type mutex is explicitly
undefined for pthread_mutex_lock(3).
The POSIX specification is still not very clear. It defines
pthread_mutex_trylock(3) in terms of pthread_mutex_lock(3) yet
does not say what the defined behavior should be for a self-locked
pthread_mutex_trylock(3) for any of the various mutex types, so it is
ambiguous whether the result is clearly undefined or clearly to return
EBUSY.
It is a one line change whether or not to make libpthread return
EDEADLK in this case, where it seems that most implementations do not.
Reference: http://www.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_lock.html
