which are slave ports to the stock KDE2 ports with extra Japanese
support patches released from kde.gr.jp after the KDE 2.2 release.
Most of them will be merged into the KDE mainstream, but in the
meantime we need this to have decent support for Japanese language
environment.
PR: ports/30194
Submitted by: SASAKI Katuhiro <sahiro@crest.ocn.ne.jp>
the third dimension
Submitted by: Patrick Li <pat@databits.net>
PR: 29910
She went into a trance, and while she was in the trance,
she gave some latitude and longitude figures. We focused
our satellite cameras on that point and the plane was there.
--President Jimmy Carter
- use ${INSTALL_DATA} for docs, not ${INSTALL_MAN}
- maintainer should be grog@FreeBSD.org, not just 'grog'
PR: 28755
Submitted by: Patrick Li <pat@databits.net>
Approved by: maintainer
Update configure script to be smaller and fix it from trying to grep directories
Update TLS to version for new postfix version
Add missing man pages
PR: 30177
Submitted by: maintainer, slin@infomath.math.nctu.edu.tw
Bump PORTREVISION just in case this is needed.
From Mikhail Teterin:
> Well, for the same reason the xslt.cpp sometimes works -- in fact, it
> worked for everyone, until someone tried it on current.
>
> In essence, the code reads the whole file into a buffer. It then tries
> to turn that buffer into one of qt's string-objects (QCString). The
> class' constructor they chose assumes, it is passed a valid (aka
> \0-terminated) string and goes through the buffer looking for the first
> 0-byte. The file itself does not contain any, so it happily wonders
> behind the real end of the buffer until it either finds a stray 0-byte,
> or seg-faults, trying to read a wrong page.
>
> Apparently, more often than not, some stray 0-byte is there -- no
> surprise. But it will usually create a string that's longer than the
> file size -- unless the 0-byte happens to be right there at the end of
> the buffer. Apparently, the lamer, who wrote it, noticed something
> strange, so he/she explicitly truncates the created QCString object to
> the known size of the file after instantiation:
>
> contents.truncate(xmlFile.size())
>
> My patch modifies the code to use the correct QCString constructor --
> the one, that accepts the maximum size of the string. This does the
> right thing -- once it reaches the end of the buffer, it stops,
> allocates the private storage (I hate C++ for all this buffer copying),
> appends the 0-byte and creates the object of the expected size. No
> truncation is needed....
Thanks to Mikhail for his debugging on this problem; this patch further
removes the hazard of meinproc coredumps.
Submitted by: mi
gets unresolved symbols when accessing fb routines at server startup.
Note, this is apparently already in the mainline XFree86 sources,
so this patch may need to be removed when the port is updated for
the next release of XFree86
Tested by: "Eric S. Van Gyzen" <eric@stat.Duke.EDU>
