KDE 3 / KDE 4 compatibility
Hi guys, I'd like to sum up some of my thoughts on how things will proceed with KDE into next year and how we can at least try to get things as easy as possible for the users. Library mess and the prefix The main problem as we all know on debian compared to e.g. SuSE is that it uses /usr as the prefix for all KDE versions. That per se wouldn't be a problem if KDE wouldn't cause problems. For most developers it isn't an issue at all because they just think, use another prefix and be done. SuSE e.g. used /opt/kde for KDE 1 /opt/kde2 for KDE 2 /opt/kde3 for KDE 3 and will probably use /opt/kde4 for KDE 4. This avoids collisions with packages totally but this doesn't make KDE better in terms of usage with systems that use a single prefix. The result was that during the KDE 2 to KDE 3 move, KDE didn't take care enough of libraries and kde modules in terms of major numbers for libraries and the installation location of modules. One reason for this has certainly been that sometimes a library can be a module at the same time. This requires installing the library itself plus the symlinks up to the major version plus the .la file so it gets accessible via dlopen as a module. When a major version increas happens, the library packages will collide in the .la file necessarily. We've tried to reduce this and to clean up KDE 3 to some extend but this hasn't been completed yet. Last week at the developer conference when we had Matthias Ettrich's talk about Qt 4 coming next year, it got obvious that KDE will switch to Qt 4 as soon as possible for the project. That means that KDE 3.2 will probably be the last release that will stay compatible with KDE 3 and the next major release will be KDE 4; there won't be too much time to make a KDE 3.3 release. For those who after the release of sarge will want to continue using sarge with all of it's KDE programs that rely on kdelibs4 (from KDE 3.x) this will turn out to be a problem as soon as they want to use KDE 4 - the same nightmare will happen to those programs like with KDE 2 programs as soon as KDE 3 got installed on woody. The solution is therefore to make sure that libs that are modules as well become a separate file as a module. I talked to Dirk and this has already happened to the annoying libkhtml, effectively we now have /usr/lib/libkhtml.so.* /usr/lib/kde3/khtmlpart.so/.la This allows us to move the libkhtml.la file from the kdelibs4 package to the kdelibs4-dev package. For all libkdeinit_ libraries Dirk has told me that .so and .la files can safely be moved to the -dev package as well. The only outstanding issues now are libkdeprint_mananagement.la (lib and module, needs split-up like khmtl) /usr/lib/kaddprinterwizard.so/.la which should be a module and is installed at the wrong location. I already have the above issues fixed and will commit updated install files and a changed control file that introduces a conflict for kdelibs4-dev with kdelibs4 (<< 4:3.1.90). On the libkdeprint_management and kaddprinterwizard I'm still trying to get those issues fixed. Effectively this will mean that a user who will have sarge installed can: - upgrade to KDE 3.2 once released - upgrade to KDE 4 once he has kdelibs4_3.2.0 or higher installed that will bring a non-conflict against kdelibs5 for KDE 4 for kdelibs4. For unstable, this will mean that when KDE 3.2 gets in we don't have to conflict to KDE 4 for the applications that are based on KDE 3 libs but can be installed at the same time; so the user can have kdelibs4 and kdelibs5 installed. I'm not yet sure how this will work out on the kdelibs-bin package yet; I hope that won't have any influence. What I would like to know is now (probably calc and bab can say somethng there): - do we have the same issues with arts and koffice and kdebase ? (I think I remember something like this darkly) Ralf -- We're not a company, we just produce better code at less costs. Ralf Nolden [EMAIL PROTECTED] The K Desktop Environment The KDevelop Project http://www.kde.org http://www.kdevelop.org pgpafeKc3USKd.pgp Description: signature
Re: Qt 3.2 bug with 3.1.3 ?
On Dienstag, 2. September 2003 12:41, Bernhard Rosenkraenzer wrote: > On Tue, 2 Sep 2003, Ralf Nolden wrote: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=208267 > > > > Can someone approve that or is that a bug yet unknown ? > > Absolutely not reproducable here (we use Qt 3.2.1 and KDE_3_1_BRANCH from > about 2 weeks ago). Martin, da ist nix :-) Ich kann das hier auch nicht feststellen und ich hab 3.2.1 und KDE 3.1.3. Ralf > > LLaP > bero -- We're not a company, we just produce better code at less costs. Ralf Nolden [EMAIL PROTECTED] The K Desktop Environment The KDevelop Project http://www.kde.org http://www.kdevelop.org pgpCxVb06Dqit.pgp Description: signature
Re: KDE 3 / KDE 4 compatibility
On Tue, Sep 02, 2003 at 04:21:55PM +0200, Ralf Nolden wrote: Content-Description: signed data > Hi guys, > > I'd like to sum up some of my thoughts on how things will proceed with KDE > into next year and how we can at least try to get things as easy as possible > for the users. > > Library mess and the prefix > > The main problem as we all know on debian compared to e.g. SuSE is that it > uses /usr as the prefix for all KDE versions. That per se wouldn't be a > problem if KDE wouldn't cause problems. For most developers it isn't an issue > at all because they just think, use another prefix and be done. SuSE e.g. > used > > /opt/kde for KDE 1 > /opt/kde2 for KDE 2 > /opt/kde3 for KDE 3 > > and will probably use /opt/kde4 for KDE 4. This avoids collisions with > packages totally but this doesn't make KDE better in terms of usage with > systems that use a single prefix. > > The result was that during the KDE 2 to KDE 3 move, KDE didn't take care > enough of libraries and kde modules in terms of major numbers for libraries > and the installation location of modules. One reason for this has certainly > been that sometimes a library can be a module at the same time. This requires > installing the library itself plus the symlinks up to the major version plus > the .la file so it gets accessible via dlopen as a module. > > When a major version increas happens, the library packages will collide in > the .la file necessarily. We've tried to reduce this and to clean up KDE 3 to > some extend but this hasn't been completed yet. Last week at the developer > conference when we had Matthias Ettrich's talk about Qt 4 coming next year, > it got obvious that KDE will switch to Qt 4 as soon as possible for the > project. That means that KDE 3.2 will probably be the last release that will > stay compatible with KDE 3 and the next major release will be KDE 4; there > won't be too much time to make a KDE 3.3 release. Once KDE 4 is being worked on upstream we will need to try to get all the rest of the mess cleaned up. Hopefully we will have time. :) > For those who after the release of sarge will want to continue using sarge > with all of it's KDE programs that rely on kdelibs4 (from KDE 3.x) this will > turn out to be a problem as soon as they want to use KDE 4 - the same > nightmare will happen to those programs like with KDE 2 programs as soon as > KDE 3 got installed on woody. > > The solution is therefore to make sure that libs that are modules as well > become a separate file as a module. I talked to Dirk and this has already > happened to the annoying libkhtml, effectively we now have > > /usr/lib/libkhtml.so.* > /usr/lib/kde3/khtmlpart.so/.la > > This allows us to move the libkhtml.la file from the kdelibs4 package to the > kdelibs4-dev package. For all libkdeinit_ libraries Dirk has told me that .so > and .la files can safely be moved to the -dev package as well. These have happened on KDE 3.1.x ? Also on KDE 3.2 the last time I built it, last week, it did not have versioned SO for the libkdeinit_ binaries, so all that was provided was .so/.la ... > The only outstanding issues now are > > libkdeprint_mananagement.la (lib and module, needs split-up like khmtl) > /usr/lib/kaddprinterwizard.so/.la which should be a module and is installed at > the wrong location. > > I already have the above issues fixed and will commit updated install files > and a changed control file that introduces a conflict for kdelibs4-dev with > kdelibs4 (<< 4:3.1.90). > > On the libkdeprint_management and kaddprinterwizard I'm still trying to get > those issues fixed. Do the above need to be fixed for KDE 3.1.x ? > Effectively this will mean that a user who will have sarge installed can: > > - upgrade to KDE 3.2 once released > - upgrade to KDE 4 once he has kdelibs4_3.2.0 or higher installed that will > bring a non-conflict against kdelibs5 for KDE 4 for kdelibs4. > > For unstable, this will mean that when KDE 3.2 gets in we don't have to > conflict to KDE 4 for the applications that are based on KDE 3 libs but can > be installed at the same time; so the user can have kdelibs4 and kdelibs5 > installed. The user will need to be able to upgrade from KDE 3.1.x -> KDE 4.x since this is probably how it will actually happen in Debian dist upgrades... KDE 3.2 won't make it into sarge barring some major problem with sarge release. However, KDE 4 very well might make it into sarge+1. Also, to allow KDE 3 and KDE 4 to be coinstallable would require splitting the various lib packages into library per package (I think?), since each library doesn't necessarily bump sover, right? > I'm not yet sure how this will work out on the kdelibs-bin package yet; I hope > that won't have any influence. > > What I would like to know is now (probably calc and bab can say somethng > there): > > - do we have the same issues with arts and koffice and kdebase ? (I think I > remember something like this darkly)
Re: KDE 3 / KDE 4 compatibility
On Dienstag, 2. September 2003 19:27, Chris Cheney wrote: > Once KDE 4 is being worked on upstream we will need to try to get all > the rest of the mess cleaned up. Hopefully we will have time. :) No, we have to sort out the mess for KDE 3.2. KDE 4 will introduce way too many other problems, beleive me :-) This is why I'm bugging everyone right now to fix the issues since the meeting last week. > > This allows us to move the libkhtml.la file from the kdelibs4 package to > > the kdelibs4-dev package. For all libkdeinit_ libraries Dirk has told me > > that .so and .la files can safely be moved to the -dev package as well. > > These have happened on KDE 3.1.x ? Also on KDE 3.2 the last time I > built it, last week, it did not have versioned SO for the libkdeinit_ > binaries, so all that was provided was .so/.la ... No, this is all HEAD, not the branch. I moved that already today. > > > The only outstanding issues now are > > > > libkdeprint_mananagement.la (lib and module, needs split-up like khmtl) > > /usr/lib/kaddprinterwizard.so/.la which should be a module and is > > installed at the wrong location. This has been fixed - coolo did a wrong commit and cleaned it up, dirk fixed it a second time. Now the kaddprinterwizard program gets build again plus the kaddprinterwizard.so/.la get installed in /usr/lib/kde3. The question is just why /usr/lib/kde3/kprinterwizard.so/.la is in kdelibs-bin; it should be in kdelibs4. I found another outstanding one, knotify.so/.la. > > > > I already have the above issues fixed and will commit updated install > > files and a changed control file that introduces a conflict for > > kdelibs4-dev with kdelibs4 (<< 4:3.1.90). > > > > On the libkdeprint_management and kaddprinterwizard I'm still trying to > > get those issues fixed. > > Do the above need to be fixed for KDE 3.1.x ? No, you can't fix that for KDE 3.1 anymore. This is too late; you'll just introduce new bugs when trying to backport. This will unfortunately only be reasonable in HEAD, so - also unfortunately - we can't make sarge already KDE 4 compatible. This has to be done when KDE 3.2 enters unstable, but that again means for a sarge user if he installs KDE 3.2 kdelibs for sarge he'll be able to use all KDE 3 programs in sarge even with KDE 4 (that's the goal at least). > The user will need to be able to upgrade from KDE 3.1.x -> KDE 4.x since > this is probably how it will actually happen in Debian dist upgrades... > KDE 3.2 won't make it into sarge barring some major problem with sarge > release. However, KDE 4 very well might make it into sarge+1. Yes, and KDE 3.2 before. That means with sid we can introduce a KDE 3.x kdelibs set that lets the user use KDE 3 apps from sarge on sid (or, to be more precise, lets the packagers and developers some more time when a program isn't available as a KDE 4 program; sid can easily ship the KDE 3 version unlike sarge which had to have all KDE 2.x programs removed/upgraded to KDE 3). > > Also, to allow KDE 3 and KDE 4 to be coinstallable would require > splitting the various lib packages into library per package (I think?), > since each library doesn't necessarily bump sover, right? No, doesn't. The sover will be bumped on KDE 4 no matter what because Qt 4 will bump the sover as well. This mistake happened to us from KDE 2 -> KDE 3 with qt-2 to qt-3 where KDE didn't bump the sover cleanly. > > - do we have the same issues with arts and koffice and kdebase ? (I think > > I remember something like this darkly) > > Yes, there are similiar problems with arts... arts doesn't have a fscking > module dir at all, it puts all its modules into /usr/lib. Also, the > /usr/lib/mcop dir isn't versioned so may cause additional difficulties, > but I'm not sure. Can you get into contact with Stefan Westerfeld and Stephan Kulow please to resolve those issues ? If they can't be solved then the work on KDE 3.2 is more or less bogus I think :-) if there isn't a different way to solve the issues. > Also, I don't know if they have all been cleaned up on KDE 3.2 but > various other official kde apps stuck kparts into /usr/lib, that > definitely needs to be verified/fixed before KDE 3.2/4 release. Yes. As we're having detailed installation lists we need to go through them and fix those issues now or at least in the coming one to two month, otherwise we'll carry that burden over into KDE 3.2 where the master plan of having compatibility between KDE 3 apps and a KDE 4 desktop won't be possible on debian again. Ralf > > Chris -- We're not a company, we just produce better code at less costs. Ralf Nolden [EMAIL PROTECTED] The K Desktop Environment The KDevelop Project http://www.kde.org http://www.kdevelop.org pgp5zDhrORnJx.pgp Description: signature
kdelibs-bin and kdelibs4 libs moving
Hi Calc, anything about moving the kaddprinterwizard.so/.la and knotify.so/.la to kdelibs4 from kdelibs-bin ? We need to do that too to have a clean upgrade path; kaddprinterwizard.so/.la is already moved to /usr/lib/kde3 as a kde module. Ralf -- We're not a company, we just produce better code at less costs. Ralf Nolden [EMAIL PROTECTED] The K Desktop Environment The KDevelop Project http://www.kde.org http://www.kdevelop.org pgp7NYrcXDifQ.pgp Description: signature
please use release tarballs :-)
Hi, FYI, while communicating with Matt Zimmerman a couple of weeks back on security issues for KDE (that the woody debs on kde.org have those fixed as well - Martin Schulze included that info while he was doing that) we were discussing things like that the KDE packages in sid are made from CVS checkouts rather than from the original release tarballs. Matt would prefer to get them build from the release tarballs with patchsets against CVS if you need them - however, this is none of my business so you might want to check with Matt how to proceed with your next upload as that's probably the last chance to do it the way the security team would like to have things done for sarge. I know making patchsets for every change requires a lot of time and effort but you should seriously think about doing it; it will ensure more quality control and give the security team a better base in case they will receive security patches from KDE - again this is my personal opinion, I'm not a debian developer yet that I could do this on my own but I would be willing to help there. Ralf -- We're not a company, we just produce better code at less costs. Ralf Nolden [EMAIL PROTECTED] The K Desktop Environment The KDevelop Project http://www.kde.org http://www.kdevelop.org pgpoyIJWQ3OIG.pgp Description: signature
Re: please use release tarballs :-)
On Tue, Sep 02, 2003 at 11:09:55PM +0200, Ralf Nolden wrote: Content-Description: signed data > Hi, > > FYI, while communicating with Matt Zimmerman a couple of weeks back on > security issues for KDE (that the woody debs on kde.org have those fixed as > well - Martin Schulze included that info while he was doing that) we were > discussing things like that the KDE packages in sid are made from CVS > checkouts rather than from the original release tarballs. Matt would prefer > to get them build from the release tarballs with patchsets against CVS if you > need them - however, this is none of my business so you might want to check > with Matt how to proceed with your next upload as that's probably the last > chance to do it the way the security team would like to have things done for > sarge. For one thing, we always need the updates from branch, KDE is notoriously buggy, just look at the bug list sometime ;). However, the orig.tar.gz in 99% of the cases is the KDE_3_1_X_RELEASE export minus all the autocrap and CVS dir crap that upstream ships in their tarballs. If debian f*cking supported decent change support, not just text diff then this could be 100% the case. Sometimes binary files change (eg png's) and in those cases I have to stuff them in orig.tar.gz since going through the uuencode/etc process is a REALLY BIG PITA. The resulting diff.gz that is built for uploads includes KDE_3_1_BRANCH (minus binary stuff) since the last release plus the autocrap. A new security release shouldn't be very hard to do for KDE 3 since you would just need to do a current KDE_3_1_BRANCH export and build it. I will never ship pristine upstream tarballs due to the CVS dir issue which Debian officially doesn't want either... so its a no win situation, someone in Debian will always be bitching. > I know making patchsets for every change requires a lot of time and effort but > you should seriously think about doing it; it will ensure more quality > control and give the security team a better base in case they will receive > security patches from KDE - again this is my personal opinion, I'm not a > debian developer yet that I could do this on my own but I would be willing to > help there. In future releases I can provide the diff.gz for security releases if wanted. I didn't provide them on 2.2 releases since I didn't maintain KDE during that time (not really anyway) and the build system was a mess, etc. Chris BTW - I make it a habit to never fix things directly in the diff.gz, if needed I make debian specific changes and then create diffs for them in the debian/patches dir.
Re: please use release tarballs :-)
On Mittwoch, 3. September 2003 00:00, Chris Cheney wrote: > On Tue, Sep 02, 2003 at 11:09:55PM +0200, Ralf Nolden wrote: > Content-Description: signed data > > > Hi, > > > > FYI, while communicating with Matt Zimmerman a couple of weeks back on > > security issues for KDE (that the woody debs on kde.org have those fixed > > as well - Martin Schulze included that info while he was doing that) we > > were discussing things like that the KDE packages in sid are made from > > CVS checkouts rather than from the original release tarballs. Matt would > > prefer to get them build from the release tarballs with patchsets against > > CVS if you need them - however, this is none of my business so you might > > want to check with Matt how to proceed with your next upload as that's > > probably the last chance to do it the way the security team would like to > > have things done for sarge. > > For one thing, we always need the updates from branch, KDE is > notoriously buggy, just look at the bug list sometime ;). However, the > orig.tar.gz in 99% of the cases is the KDE_3_1_X_RELEASE export minus all > the autocrap and CVS dir crap that upstream ships in their tarballs. If > debian f*cking supported decent change support, not just text diff then > this could be 100% the case. Sometimes binary files change (eg png's) and > in those cases I have to stuff them in orig.tar.gz since going through the > uuencode/etc process is a REALLY BIG PITA. The resulting diff.gz that is I know that also. The java stuff contains binaries as well, so this was kind of hard to track down if you update from the branch. At least I try to use the release tarballs in my woody builds which worked quite ok for 3.1.3 and I guess 3.1.4 will be smooth as well. I wonder why the CVS dirs are not supported though; they contain the release tag and even if you'd update from CVS or use the branch the security team could track down the information by the revision number that your orig.tar.gz would ship in the CVS dirs. > > I will never ship pristine upstream tarballs due to the CVS dir issue > which Debian officially doesn't want either... so its a no win situation, > someone in Debian will always be bitching. I know :-( > > Chris > > BTW - I make it a habit to never fix things directly in the diff.gz, if > needed I make debian specific changes and then create diffs for them in > the debian/patches dir. That's what I meant. -- We're not a company, we just produce better code at less costs. Ralf Nolden [EMAIL PROTECTED] The K Desktop Environment The KDevelop Project http://www.kde.org http://www.kdevelop.org pgpAerYafuGeN.pgp Description: signature
Re: KDE 3 / KDE 4 compatibility
On Tue, Sep 02, 2003 at 10:29:34PM +0200, Ralf Nolden wrote: Content-Description: signed data > On Dienstag, 2. September 2003 19:27, Chris Cheney wrote: > > > Once KDE 4 is being worked on upstream we will need to try to get all > > the rest of the mess cleaned up. Hopefully we will have time. :) > No, we have to sort out the mess for KDE 3.2. KDE 4 will introduce way too > many other problems, beleive me :-) This is why I'm bugging everyone right > now to fix the issues since the meeting last week. I was under the impression that no binary incompatible changes could happen before KDE 4? > > > The only outstanding issues now are > > > > > > libkdeprint_mananagement.la (lib and module, needs split-up like khmtl) > > > /usr/lib/kaddprinterwizard.so/.la which should be a module and is > > > installed at the wrong location. > This has been fixed - coolo did a wrong commit and cleaned it up, dirk fixed > it a second time. Now the kaddprinterwizard program gets build again plus the > kaddprinterwizard.so/.la get installed in /usr/lib/kde3. > > The question is just why /usr/lib/kde3/kprinterwizard.so/.la is in > kdelibs-bin; it should be in kdelibs4. In KDE 3.1 kaddprinterwizard appears to be a binary/library speed hack. It is similiar to the libkdeinit_* binaries in KDE 3.2. Was the binary not supposed to really be built, if so we could remove that in BRANCH and then move the so/la to /usr/lib/kde3? There is no /usr/lib/kde3/kprinterwizard.so/.la in KDE 3.1, perhaps you typo'd? > I found another outstanding one, knotify.so/.la. knotify, at least in KDE 3.1, is also another one of the binary/library speed hacks eg libkdeinit_* > > > - do we have the same issues with arts and koffice and kdebase ? (I think > > > I remember something like this darkly) > > > > Yes, there are similiar problems with arts... arts doesn't have a fscking > > module dir at all, it puts all its modules into /usr/lib. Also, the > > /usr/lib/mcop dir isn't versioned so may cause additional difficulties, > > but I'm not sure. > > Can you get into contact with Stefan Westerfeld and Stephan Kulow please to > resolve those issues ? If they can't be solved then the work on KDE 3.2 is > more or less bogus I think :-) if there isn't a different way to solve the > issues. Ok, will try to convince them to fix that issue... Thanks, Chris Side note: I wonder if the dists installing stuff into /opt could be declared non LSB conforming... /opt is reserved for 3rd party apps only, similiar to how /usr/local is only for local admin stuff. (This isn't a Debian only decision...)
Re: kdelibs-bin and kdelibs4 libs moving
On Tue, Sep 02, 2003 at 10:32:06PM +0200, Ralf Nolden wrote: Content-Description: signed data > Hi Calc, > > anything about moving the kaddprinterwizard.so/.la and knotify.so/.la to > kdelibs4 from kdelibs-bin ? We need to do that too to have a clean upgrade > path; kaddprinterwizard.so/.la is already moved to /usr/lib/kde3 as a kde > module. See my other message regarding those two libraries, they both appear to be speed hacks for binaries on KDE 3.1... Chris
Re: KDE 3 / KDE 4 compatibility
> What I would like to know is now (probably calc and bab can say > somethng there): > > - do we have the same issues with arts and koffice and kdebase ? (I > think I remember something like this darkly) I don't thinking supporting simultaneous koffice versions is something we need to be worried about. Arts and kdelibs are modules that everything else depends on, and so it is desirable to support multiple versions of them. KOffice on the other hand is basically a set of applications, and so I see no specific reason for users to want older versions installed (at least any more than users might want older versions of vim, xfig, whatever installed). Ben.
Re: qt-copy/debian updated
> Let us know if there are any problems so far beyond the usual style/font > breakage :-) Hi. I've done exactly that, still can't compile kde. Same error as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=208213 Just in case it's useful. Regards, -- ricardo galli GPG id C8114D34 http://mnm.uib.es/~gallir/
Konsole / Fonts / Qt 3.2.1
I just noticed that Qt 3.2.1 shows fonts that fontconfig doesn't know about, including CJK fonts. I thought this bug had been fixed already before. If this is intended behaviour for some reason let me know why. :) Thanks, Chris Example: # fc-list ':spacing=mono' | cut -f 1 -d ":" | sort -u Bitstream Vera Sans Mono CentSchbook Mono BT Clean Console Courier Courier 10 Pitch Courier New Courier10 BT Cursor Dingbats Fixed FreeMono Lucida Console Lucida Sans Typewriter LucidaTypewriter Nimbus Mono L OCR A Extended Terminal Konsole sees: Bitstream Vera Sans Mono CentSchbook Mono BT Clean Clean [Schumacher] Console Console [Misc] Courier Courier 10 Pitch Courier New Courier [Adobe] Courier [Bitstream] Courier [Cronyx] Courier10 BT Dingbats Fangsong Ti Fixed Fixed [Cronyx] Fixed [Jis] Fixed [Misc] Fixed [Screen] Fixed [Sony] FreeMono Gothic Lucida Console Lucida Sans Typewriter LucidaTypewriter LucidaTypewriter [B&h] Mincho Nil [Cronyx] Nil [Misc] Nimbus Mono L OCR A Extended Proof Song Ti Terminal Terminal [Bitstream] Terminal [Dec] pgpUcBoGbaFnU.pgp Description: PGP signature
Bitmap fonts
With both versions, the one available in Sid, and the other built with qt-copy/debian. Bitmap fonts are not being replaces by truetype fonts (i.e. Helvetica -> Arial). The following fonts.conf rule is not applied: true Helvetica Arial I didn't toch any fontconfig/freetype configuration. I just realised it. For example check at http://www.theregister.co.uk/content/61/32619.html (the title of the article is not antialiased). With a xset -fp /usr/X11R6/lib/X11/fonts/100dpi/ the text is shown antialiased again. But this didn't happen few days before. Again, I'm not sure when this was broken, but I'm sure with 3.1 it worked fine. Regards, -- ricardo galli GPG id C8114D34 http://mnm.uib.es/~gallir/
Re: Konsole / Fonts / Qt 3.2.1
> I just noticed that Qt 3.2.1 shows fonts that fontconfig doesn't know > about, including CJK fonts. I thought this bug had been fixed already I've also seen it three days ago. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=207959 I think is related to the other mail I've sent to the list (sorry, I'm not a qt|kde|Debian developer, so I'm not susbcribed, I read you via web). -- ricardo galli GPG id C8114D34 http://mnm.uib.es/~gallir/
Re: qt-copy/debian updated
On Wed, Sep 03, 2003 at 01:39:47AM +0200, Ricardo Galli wrote: > > Let us know if there are any problems so far beyond the usual style/font > > breakage :-) > > Hi. > > I've done exactly that, still can't compile kde. Same error as > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=208213 > > Just in case it's useful. You need newer KDE from KDE_3_1_BRANCH (I think). Chris
