On Mon, Aug 29, 2005 at 08:59:52AM -0400, Prarit Bhargava wrote:
> Looks like the ia64 kernel has been turned off again ;)
The ia64 build boxes were a little flaky lsat week, so I turned off
ia64 so we could get something built at all. That situation
seems to have resolved itself.
> It seems to compile and boot on my systems -- could we get that turned
> back on?
I pushed one through late last night. (2.6.13-1.1526)
I guess it just missed the rawhide push cut-off.
The libdps and libdpstk libraries have been deprecated for several
releases of the X Window System now (approximately 2 years or more),
and upstream X.Org has disabled them from being built in X11R7.
Generally speaking, this is not a problem because there has never
been an open source DPS server-side extension in the XFree86 or
X.Org X servers, so the DPS functionality is generally not useful
anyway, and is more or less unused - which is the primary reason
it was deprecated upstream.
This change should have very small effect overall on developers
at large, however it is possible that some applications in Fedora
Core, Fedora Extras, or elsewhere, might have optional DPS support,
and might currently have it enabled by default still. Since DPS
has been publically deprecated for several years now however, it is
likely there are not many applications building with DPS support
by default currently.
Nonetheless, as a notice to all Fedora Core and Fedora Extras
developers, and other rpm package maintainers out there, please
check all of your rpm packages which link to X libraries, and
examine them for build or runtime dependencies on libdps and
libdpstk. If you find any such packages, have a look at their
./configure options to see if they have an option to disable
DPS support. Normally this should be something like:
Please update your packages as soon as possible to remove the
dependency on DPS, as the DPS libraries will vanish soon in
rawhide, once the modular X11R7 gets integrated into our
If anyone has any questions or concerns about the obsolescence
of the dps libraries, please subscribe to the
xorg(a)lists.freedesktop.org mailing list where you may discuss
any concerns to the relevant upstream X.Org developers.
Thanks in advance.
 The http://dps.sf.net project, was an OSS project to implement
DPS support for the XFree86 server, however that code was never
integrated into XFree86 nor X.Org sources, and has not to the
best of my knowledge ever been shipped by many OS distributions
(if any at all). The DPS project has long since been abandoned
by it's primary developer, and has been dead for years now.
With the kernel 2.6.11-1.35_FC3 and 2.6.12-1.1372_FC3 I can't use a
program. Starting up it complains: undefined symbol: initPAnsiStrings
There was no problem with all kernels before 2.6.11-1.35_FC3
a) is there a chance to get initPAnsiStrings back in the next kernel
b) does someone know where I can get the kernel before 2.6.11-1.35_FC3
(I removed it accidentally because of space issues, don't even remember
the version number)? The download servers and the mirrors I tried have
just the actual version available.
(It's my online banking program, would be quite nice to have it working
in the not so far future :-) )
I try here the last 1.1-0.2.8.deerpark.alpha2 firefox. Runs fine, but
some little things.
- Closing tabs with loaded pages is slow
- download dialog window opens very slow
- preferences dialog (changing before a font) closes very slow
+ big/long webpages with many ads or flash are now very fast rendered
and scrolling is very fast. :)
Is this faster rendering from the new cairo in firefox, now again
I think the same goes for my loved gnome-terminal 2.11.2 which is now
with transparent BG under gtk2+-2.8 so fast on the nautilus desktop, cool!
with the last xorg from rawhide the mtrr are not written for my GeForce
6800 Go mobile 256MB (Dell Inspiron 9300 Pentium M 750 2MB L2).
I get only after booting in X from /proc/mtrr:
reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0xfeda0000 (4077MB), size= 128KB: write-through, count=1
Where is the video card?
Should it not include something like:
reg02: base=0xc0000000 (3072MB), size= 256MB: write-combining, count=1
which I have now manually echo´ed after reading the linear framebuffer
address from the Xorg.0.log:
(--) NVIDIA(0): Linear framebuffer at 0xC0000000
(--) NVIDIA(0): MMIO registers at 0xDD000000
Or is this our beloved newest nVidia closed source driver, which makes
problems here? Then, shame on me...
[root@amd64-3000 development]# rpm -qa | grep koffice
Added 15 new packages, deleted 0 old in 1.83 seconds
--> Populating transaction set with selected packages.
---> Package koffice-kword.x86_64 0:1.4.1-4.fc4 set to be
---> Package koffice-core.x86_64 0:1.4.1-4.fc4 set to be updated
---> Package koffice-filters.x86_64 0:1.4.1-4.fc4 set to be
---> Package koffice-devel.x86_64 0:1.4.1-4.fc4 set to be
--> Running transaction check
--> Processing Dependency: libgs.so.7()(64bit) for package:
--> Finished Dependency Resolution
Error: Missing Dependency: libgs.so.7()(64bit) is needed by
koffice needs to be rebuilt with libgs.so.8. Which I've
done. Why does yum keep wanting to upgrade to the extras
One issue: the installed koffice where built --target=i486
( don't ask).
rpm -q koffice-core.i486
But, why would yum try to install an x86_64 set? Will it
always try to install the preferred target if another target