${PREFIX}/include/gnome-1.0 instead of plain ${PREFIX}/include, so make
gnome-config return appropriate cpp(1) flags necessary to find those
headers. Bump PORTREVISION accordingly.
may with to modify xterm's title or something after you login to
one. It does not use X11 at all, except to build its Makefile.
Use the simple Makefile of our own, to drop build-dependency on
X11. As a side effect, it will be installed into LOCALBASE,
rather than X11BASE/bin. Bump up PORTREVISION.
setuid root bit, which is off by default. The purpose is to avoid
having users who don't use kcheckpass become vulnerable to a root
exploit. For more details see the actual pkg-message. Bump PORTREVISION
to reflect this change in the package.
As a side note, I'm a little wary about adding something like this so
close to the ports freeze for 4.4-RELEASE. However, I decided that it
was a minimal risk and went ahead with it in the hopes of avoiding the
need for users to run into this "problem" themselves...
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>
