- Enable XIM support per default unless required to disable
- Add WITH_* options to set the default encoding for multi-char
glyph languages including setting to noenc (no encoding)
PR: 26490
Submitted by: The Anarcat <anarcat@tao.ca>
- bsd.port.mk update to use bsd.kde.mk for USE_{QT,KDE}*
- Cleanup corresponding ports for bsd.kde.mk update.
- Fix bsd.kde.mk: use correct kdelibs dependency, put qt at the bottom,
introduce QT_NONSTANDARD variable for nonstandard configure setup.
- Update KDE2 to 2.1.1. Two patches included in x11/kdelibs2 to fix the
proxy authentication that was broken for 2.1.1. Remove old patches.
- Potentially fix kdelibs build for alpha.
- Fix qt-designer 2.3.0 build.
- Ruby stuff left alone since it looks like black magic to me. Should
still work w/ compat shims for older USE_QT[,2] style. Some others
were also left alone for the same reason.
Reviewed by: portmgr, ports (bsd.kde.mk+bsd.port.mk)
Submitted by: David Faure <faure@kde.org> (proxy auth patches)
Alex Zepeda <garbanzo@kde.org> (old patches removal)
o use internal freetype2 for consistency with x11/XFree86-4.
o added xthreads obtained from x11/XFree86-4.
o install "ws" type config sample for xdm.
o build DRI only if kernel source installed in /sys.
o fix Riva128/SGRAM driver(patch-riva_hw.c).
PR: 24338(4.0.2)
Submitted by: maintainer, keith
this involves is this: Cull GL from Qt by default, but still provide a
Qt+GL library that may or may not have threads. Then also provide a Qt
library that has threads but not GL. This allows us to make KDE2 depend
on a library that will *not* have threads, ever. Threads will be
revisited at a later date. Ports that require GL support need to be
updated to use the hacked library, libqtgl.so.4. The net result is that
we bloat our qt2 package by 1.5-2.5MB for compatability. Also, static
qt will not have GL support.
Introduce bsd.kde.mk, which will be tested on bento before becoming
fully activated.
Replace qt22-static with qt2-static, since it's just a proxy. Update
qt-designer to depend on qt23. Also make the old hack to package the
correct lib obsolete by using PLIST_SUB instead.
Miscellaneous changes: remove LIBQTFILE from CONFIGURE_ENV, it's not
used anymore. Solve namespace pollution problems with the devel/pth and
devel/libgnugetopt ports. Hopefully.
Suggested by: ade, asami, sobomax (bsd.kde.mk)
Repocopied by: asami (qt22-static --> qt2-static)
the XFree86 port directory. Before these would generate the files
files/patch-r0[1234] (some of them multiple times), now they will actually
patch the X sources to achieve the desired results.
- patch-0 replaced by 'MAKE_ARGS=' in Makefile
- XF86Setup is no more supported in XFree-4, so patch-8 is removed as well
as corresponding stuff in scripts/configure
- patch-config_cf_Server_tmpl replaced by the setting of InstallXserverSetUID
in scripts/configure
other removed patches are no more necessary.
Note that freetype2 is now part of the base 4.0.3 distribution. The
freetype2 include and libs files are always installed.
o making/installing html manpages.
o replace magic number with macro in DISTNAME.
o move post-extract to post-patch to get as-is distfile after make extract.
work right yet. This needs other eyes to look at in order for me to figure
out what's going on here. Help, please?
Basically, the current situation is this: You can hack the startkde
script to make KDE2 start all the way through, which basically consists of
simply replacing the kdeinit line with "kcminit". However, at certain
points after KDE is done setting things up, processes named "kdeinit" that
are in charge of certain apps go crazy and hit infinite loops somewhere. I
haven't been able to determine where exactly, and if this is related to
threads at all, or if a critical app or similar somehow doesn't get compiled
with threads. Or something like that. *sigh*
Konqueror can startup and seems to work okay in a different window manager,
but it seems to randomly set off a kdeinit proc as above.
Anyhow, this is 2 weeks' worth of debugging on a 4-month-old problem. If
you're using XFree86 4.0.2, I caution against trying this stuff out unless
you're going to help me out and are willing to help me figure out exactly
where the heck things are going awry. Things should still compile and work
just fine for those on XFree86 3.3.6. I decided to leave out these hacks
in nonessential stuff (like kdenetwork et al) because kde2 itself needs to
work with threads first. =)
I guess I can thank my lucky stars JKH's decided to stick with 3.3.6 until
some point in the future when 4.0.x becomes more stable...