Re: KDE 2.2 and KOffice
> Since Ivan has already said he is not intending to back port KDE 2.2 to > potato, it would be nice if we maintained versions of KOffice that use > 2.1.2 libs (at least for those of us who haven't moved beyond potato yet). Cool. Btw, this won't affect the KOffice upload schedule because the potato packages will need to be built on a potato machine which will have the 2.1.2 libs installed anyway, regardless of what happens to sid. Ben. -- Ben Burton [EMAIL PROTECTED] | [EMAIL PROTECTED] http://baasil.humbug.org.au/bab/ Public Key: finger [EMAIL PROTECTED] A man who does not think for himself does not think at all. - Oscar Wilde
Re: "su" Capability Needed In Konqueror
When I launch konqueror with kdesu, the progress dialogs don't appear. -- Sylvain Joyeux (5895) [EMAIL PROTECTED]
Re: KDE 2.2 beta1
On Wed, Jun 27, 2001 at 04:26:06AM +0800, Debian User wrote: > On Tuesday 26 June 2001 08:43, Ivan E. Moore II wrote: > > the quick and dirty: > > > > cd kdelibs (for example) > > debuild > > > > > > that's what I do to build all the packages... debuild is part > > of the devscripts package. I *believe* it depends on all the > > correct bits. debuild will verify that you have all the build > > dependencies installed and if you don't will complain and stop. > > What's the difference between this and dpkg-buildpackage? Which is > better? I *always use dpkg-buildpackage -b -rfakeroot. And well, I > think you still need to do a dh_make to create the debian/rules > template etc. Unless the KDE cvs is already debianized? debuild also > fails without prior debianization. debuild is a frontend to dpkg-buildpackage as well as other bitstaken from it's man page "debuild creates all the files necessary for uploading a Debian package. It first runs dpkg-buildpackage and then runs lintian on the .changes file created (assuming that lintian is installed). Parameters can be passed to both dpkg-buildpackage and lintian, where the parameters are separated by the -L or --lintian option. The allowable options in this case are --no-lintian to skip the lintian step and the --preserve-envvar/-e or --preserve-env/-E options described below in the Environment Variables sec tion." Ivan -- Ivan E. Moore II [EMAIL PROTECTED] http://snowcrash.tdyc.com GPG KeyID=90BCE0DD GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645 8141 90BC E0DD
Re: Patch: kdebase/debian/rules
On Tue, Jun 26, 2001 at 10:25:53PM -0400, Christopher Molnar wrote: > Ivan, > > Would you consider applying the following patch to kdebase/debian/rules? > It makes things compile much better here. > > > Thanks, > Chris > == > > 22:23:03:[EMAIL PROTECTED]/code/kdebase/debian >cvs diff rules > Index: rules > === > RCS file: /home/kde/kdebase/debian/rules,v > retrieving revision 1.191 > diff -u -r1.191 rules > --- rules 2001/06/20 19:16:06 1.191 > +++ rules 2001/06/27 02:23:56 > @@ -24,7 +24,9 @@ > ./configure $(configkde) --without-shadow --with-pam=kde \ > --with-ldap --with-cdparanoia --with-vorbis \ > --libdir=$(kde_libdir) --includedir=$(kde_includedir) \ > - --with-extra-includes=/usr/X11R6/include --without-ssl > + --with-extra-includes=/usr/X11R6/include \ > + --with-extra-includes=/usr/include/kde/arts \ > + --with-extra-includes=/usr/include/kde --without-ssl I don't understand why this would matter. KDE already includes /usr/include/kde and those bits that require stuff under arts/ already do it properly. What's not building...because if it needs the above something is not building and it's not building for everyone who builds KDE. Ivan -- Ivan E. Moore II [EMAIL PROTECTED] http://snowcrash.tdyc.com GPG KeyID=90BCE0DD GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645 8141 90BC E0DD
Re: nspluginviewer crashs with debian version of libqt 2.3.1
On Tue, Jun 26, 2001 at 10:01:38AM -0700, David Bishop wrote: > > Yep, my pluginviewer works great now (using Jen's recompiled qt package). > Now I'm curious, what debian/kde apps *use* qt-gl? Is it more common than I > know? 'Cuz I'm not thinking of anything off the top of my head. Daggon > it, my needs come first! *grin* unfortunatly there is enough call for it that I get yelled at quite a bit when it doesn't work or doesn't exist. To be truthfull I don't think the problem is the GL support of QT...it's the linkage to libpthreads by libGL. If you notice in the backtrace: #3 0x40e43dd4 in pthread_sighandler () from /lib/libpthread.so.0 if someone can come up with a clean solution to all the problems I'd appreciate it. I really haven't been able to find the time to dig more into all of this. We have: libqt built with GL support is required by many users (and I believe by some other packages now) pure_virtual problems when linking against one libqt2 package and running on libqt2-gl (for example...or vice versa) - solved by only having a single package built with gl support. QT linked to GL (and thusly to libpthread) causes some unstability issues in some applications. (flash plugin demonstrates this) I would have no problem going back to the seperate -gl package if and only if someone could track down the pure_virtual problem and provde a fix. My goal is to hopefully find time before woody's release to do due diligance and figure out a proper solution however would appreciate help here. Ivan -- Ivan E. Moore II [EMAIL PROTECTED] http://snowcrash.tdyc.com GPG KeyID=90BCE0DD GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645 8141 90BC E0DD
Re: nspluginviewer crashs with debian version of libqt 2.3.1
On Wednesday 27 June 2001 11:15, Ivan E. Moore II wrote: > To be truthfull I don't think the problem is the GL support of QT...it's > the linkage to libpthreads by libGL. If you notice in the backtrace: > > #3 0x40e43dd4 in pthread_sighandler () from /lib/libpthread.so.0 It may be related to the linkage of pthreads in libGL, but i don't think that the bt is a sign for it. Every bt has the line #3 in it, independent from gl. I think it is the way how apps are started from kdeinit and KCrash captures the crash (i may be wrong though.) i attached gdb to a running nspluginviewer by hand: # gdb nspluginviewer 4674 skip lots of output ... Loaded symbols for /lib/libnss_db.so.2 Reading symbols from /usr/lib/libdb3.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libdb3.so.3 0x40dbdc8e in select () from /lib/libc.so.6 (gdb) cont Continuing. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 4674)] 0x40f53e0a in DisplayList::~DisplayList () from /usr/lib/libGLU.so.1 (gdb) bt #0 0x40f53e0a in DisplayList::~DisplayList () from /usr/lib/libGLU.so.1 #1 0x411086b6 in _fini () from /usr/lib/netscape/476/netscape/plugins/libflashplayer.so #2 0x80565ff in NSPluginInstance::shutdown () #3 0x805a143 in NSPluginInstanceIface::process () #4 0x40606131 in DCOPClient::receive () from /usr/lib/libDCOP.so.1 #5 0x405f90a5 in DCOPClient::processPostedMessagesInternal () from /usr/lib/libDCOP.so.1 #6 0x405f8c3e in dcopServerFile () from /usr/lib/libDCOP.so.1 #7 0x40610fc4 in KDE_IceProcessMessages () from /usr/lib/libDCOP.so.1 #8 0x40608915 in DCOPClient::processSocketData () from /usr/lib/libDCOP.so.1 #9 0x407e5f9f in QObject::activate_signal () from /usr/lib/libqt.so.2 #10 0x4083d958 in QSocketNotifier::activated () from /usr/lib/libqt.so.2 #11 0x4081c542 in QSocketNotifier::event () from /usr/lib/libqt.so.2 #12 0x40791db7 in QApplication::notify () from /usr/lib/libqt.so.2 #13 0x404d10d4 in KApplication::notify () from /usr/lib/libkdecore.so.3 #14 0x80573b4 in socketCallback () #15 0x40cad7f4 in XtAppProcessEvent () from /usr/X11R6/lib/libXt.so.6 #16 0x8057910 in main () #17 0x40d1438b in __libc_start_main () from /lib/libc.so.6 (gdb) It may be just a bug in the pluginviewer related to the unloading of libs (_fini in libflashplayer.so) and not a general problem with the linkage of gl in qt. Jens -- No electrons were harmed during the creation of this message
Re: nspluginviewer crashs with debian version of libqt 2.3.1
On Wed, Jun 27, 2001 at 01:47:52PM +0200, Jens Hoffmann wrote: > On Wednesday 27 June 2001 11:15, Ivan E. Moore II wrote: > > To be truthfull I don't think the problem is the GL support of QT...it's > > the linkage to libpthreads by libGL. If you notice in the backtrace: > > > > #3 0x40e43dd4 in pthread_sighandler () from /lib/libpthread.so.0 > > It may be related to the linkage of pthreads in libGL, but i don't think > that the bt is a sign for it. Every bt has the line #3 in it, independent > from gl. I think it is the way how apps are started from kdeinit and > KCrash captures the crash (i may be wrong though.) yes..but does ever line #3 relate to the pthread_sighandler? -- Ivan E. Moore II [EMAIL PROTECTED] http://snowcrash.tdyc.com GPG KeyID=90BCE0DD GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645 8141 90BC E0DD
qt + gl + problems + etc...
Ok...so with kde 2.2 mostly uploaded (some bits already installed) to sid I turned focus to QT again especially since I've personally had many crashes of konsole due to the whole GL bit. so this lead me to a immediate solution. I still do not like this solution however this is one that I am comfortable in sticking with if a proper one does not arise before woody's release. so your asking...what's the solution??? well...a libqt2-gl package...but not like before. I have created a completely seperate source package (qt-x11-gl) which builds 2 packages: libqt2-gl and libqt-gl-dev. The actual qt library it creates also has been changed. Instead of it providing /usr/lib/libqt.so.* I've renamed the library to libqt-gl so that it can co-exist with a normal (non-gl'd) qt library. So..what does this do for everyone you might ask? allows packages that do not need the GL bits of QT to not have to deal with a library with them compiled in nor the issues surrounding QT + GL + threads. (short answer on this...flash plugin works, no more konsole crashes, etc...) This also allows for applications that do need GL support to still exist within the distribution. (oh yea..and the pure_virtual problems *should* go away) So..what's the drawbacks you might ask? 1: (obvious) yet another package (well 2)...not really that big of a deal 2: anyone who wants their package to link to the GL'd version of QT *must* modify their build process to link to libqt-gl instead of libqt. ( "-lqt-gl" instead of "-lqt") Overall I think this will be a good solution until someone comes up with another better solution. I'm sure I'll get several bug reports from people saying their GL based apps broke and then I'll hear them gripe when I tell them they need to install libqt-gl-dev and modify their source. any major issues before I upload the new packages? Ivan -- Ivan E. Moore II [EMAIL PROTECTED] http://snowcrash.tdyc.com GPG KeyID=90BCE0DD GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645 8141 90BC E0DD
QT 3 issues
Ivan -- Thanks a lot for fixing the libqt3 bugs I posted. I've installed the new packages and they work -- well, almost .. :) I have a couple of issues: * qmake does not seem to be included in qt3-tools. Perhaps a separate package would be justified? * The new Designer allows you to build plugins. I've been taking advantage of this (it's one of the main reasons I'm an early Qt 3 adopter). To build plugins, you need a header or two provided in the Designer source. It would be nice to have these headers distributed with the Qt 3 packages. Let me know if you want help with this stuff. I've never built Debian packages before, but I'm going to have to learn pretty soon anyway .. :) Also, thanks _very_ much for making the libqt3 packages. Very, very cool. I'm beginning to wonder how I got along without the new Designer - the old one seems primitive to me now. thanks very much Michael Ashton <[EMAIL PROTECTED]> The three laws of thermodynamics: 1. You can't win; you can only break even. 2. You can't break even. 3. You can't get out of the game.
Re: QT 3 issues
On Wed, Jun 27, 2001 at 08:27:35PM -0400, Data wrote: > > Ivan -- > > Thanks a lot for fixing the libqt3 bugs I posted. I've installed the new > packages and they work -- well, almost .. :) > > I have a couple of issues: > > * qmake does not seem to be included in qt3-tools. Perhaps a separate > package would be justified? > > * The new Designer allows you to build plugins. I've been taking advantage > of this (it's one of the main reasons I'm an early Qt 3 adopter). To build > plugins, you need a header or two provided in the Designer source. It > would be nice to have these headers distributed with the Qt 3 packages. the -4 version which I uploaded yesterday/day before (has new packages so will be another day at least) contains qmake. (it's in the -dev package) as for the header's...what headers and where do they need to be installed? Ivan -- Ivan E. Moore II [EMAIL PROTECTED] http://snowcrash.tdyc.com GPG KeyID=90BCE0DD GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645 8141 90BC E0DD
KDE 2.2 and AA Fonts...
This has been mentioned a few times, but I haven't seen any solution, or plan, or recognition that it is a bug. I've upgraded from 2.1.1 with working AA Fonts to the recent 2.2 alpha release, and Anti-Aliased fonts have stopped working. Yes, if I, from a Konsole, set QT_XFT to 1 and then run apps, AA works, so it's not an X-Server issue. It seems as if the "Use AA" button under the KDE Control Panel for Look & Feel->Fonts is having no effect. I'd still, ideally, like to see a "Don't use AA" option in Konsole, too (as it's the one thing that tends to look and behave better without AA). Or heck, how 'bout a generic checkbox when you're selecting a font, whether to AA that specific font? But that's straying into the area of core KDE and X functionality... -- . Trevor Phillips - http://jurai.murdoch.edu.au/ . : CWIS Systems Administrator - [EMAIL PROTECTED] : | IT Services - Murdoch University | >--- Member of the #SAS# & #CFC# < | On nights such as this, evil deeds are done. And good deeds, of / | course. But mostly evil, on the whole. / \ -- (Terry Pratchett, Wyrd Sisters) /
Re: KDE 2.2 and AA Fonts...
On Thu, Jun 28, 2001 at 09:42:06AM +0800, Trevor Phillips wrote: > This has been mentioned a few times, but I haven't seen any solution, or plan, > or recognition that it is a bug. > > I've upgraded from 2.1.1 with working AA Fonts to the recent 2.2 alpha > release, > and Anti-Aliased fonts have stopped working. Yes, if I, from a Konsole, set > QT_XFT to 1 and then run apps, AA works, so it's not an X-Server issue. It > seems as if the "Use AA" button under the KDE Control Panel for Look & > Feel->Fonts is having no effect. dunno about alpha release but the current version works just fine. ivan -- Ivan E. Moore II [EMAIL PROTECTED] http://snowcrash.tdyc.com GPG KeyID=90BCE0DD GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645 8141 90BC E0DD
Re: qt + gl + problems + etc...
Sounds great. Though I'm sure you've thought of it, maybe have one of those "notes" that dpkg uses when a user install libqt-gl, saying VERY LOUDLY that they'll have to change the linking option for any qt-gl apps, and emails it to them if they have their priority level too high. Other than that (and the fact that my home desktop can't install 2.2 yet, missing kdelibs3 >=4:2.2-cvsfoo-1 in unstable) and I'm *really* liking this new kde :-) I've been running the alpha at work for the last week (from people.debian.org), and aside from konq's tendency to wonk out at seeminly random places once a day, it's very nice. Please keep up the good work! Many Thanks, D.A.Bishop On Wednesday 27 June 2001 17:57, Ivan E. Moore II wrote: > Ok...so with kde 2.2 mostly uploaded (some bits already installed) to sid I > turned focus to QT again especially since I've personally had many crashes > of konsole due to the whole GL bit. > > so this lead me to a immediate solution. I still do not like this solution > however this is one that I am comfortable in sticking with if a proper > one does not arise before woody's release. > > so your asking...what's the solution??? > > well...a libqt2-gl package...but not like before. I have created a > completely seperate source package (qt-x11-gl) which builds 2 packages: > libqt2-gl and libqt-gl-dev. The actual qt library it creates also has been > changed. Instead of it providing /usr/lib/libqt.so.* I've renamed the > library to libqt-gl so that it can co-exist with a normal (non-gl'd) qt > library. > > So..what does this do for everyone you might ask? > >allows packages that do not need the GL bits of QT to not have to deal > with a library with them compiled in nor the issues surrounding QT + GL + > threads. (short answer on this...flash plugin works, no more konsole > crashes, etc...) This also allows for applications that do need GL support > to still exist within the distribution. (oh yea..and the pure_virtual > problems *should* go away) > > > So..what's the drawbacks you might ask? > > 1: (obvious) yet another package (well 2)...not really that big of a > deal 2: anyone who wants their package to link to the GL'd version of QT > *must* modify their build process to link to libqt-gl instead of libqt. ( > "-lqt-gl" instead of "-lqt") > > Overall I think this will be a good solution until someone comes up with > another better solution. I'm sure I'll get several bug reports from people > saying their GL based apps broke and then I'll hear them gripe when I tell > them they need to install libqt-gl-dev and modify their source. > > any major issues before I upload the new packages? > > Ivan
Re: qt + gl + problems + etc...
well..doing a debconf warning won't do any good for the maintainers of the packages. It'll only annoy any users who install the library. I'm expecting that people will file bug reports rather quickly that apps fail and the maintainers will come yell at me and all will eventually be good. new maintainers will find out by reading documentation or asking me. as for 2.2...beta1 is really nice. kdelibs is in incoming and kdebase is on it's way up right now. Ivan On Wed, Jun 27, 2001 at 09:10:45PM -0600, David Bishop wrote: > > Sounds great. Though I'm sure you've thought of it, maybe have one of those > "notes" that dpkg uses when a user install libqt-gl, saying VERY LOUDLY that > they'll have to change the linking option for any qt-gl apps, and emails it > to them if they have their priority level too high. Other than that (and the > fact that my home desktop can't install 2.2 yet, missing kdelibs3 > >=4:2.2-cvsfoo-1 in unstable) and I'm *really* liking this new kde :-) I've > been running the alpha at work for the last week (from people.debian.org), > and aside from konq's tendency to wonk out at seeminly random places once a > day, it's very nice. Please keep up the good work! > > Many Thanks, > > D.A.Bishop > > On Wednesday 27 June 2001 17:57, Ivan E. Moore II wrote: > > Ok...so with kde 2.2 mostly uploaded (some bits already installed) to sid I > > turned focus to QT again especially since I've personally had many crashes > > of konsole due to the whole GL bit. > > > > so this lead me to a immediate solution. I still do not like this solution > > however this is one that I am comfortable in sticking with if a proper > > one does not arise before woody's release. > > > > so your asking...what's the solution??? > > > > well...a libqt2-gl package...but not like before. I have created a > > completely seperate source package (qt-x11-gl) which builds 2 packages: > > libqt2-gl and libqt-gl-dev. The actual qt library it creates also has been > > changed. Instead of it providing /usr/lib/libqt.so.* I've renamed the > > library to libqt-gl so that it can co-exist with a normal (non-gl'd) qt > > library. > > > > So..what does this do for everyone you might ask? > > > >allows packages that do not need the GL bits of QT to not have to deal > > with a library with them compiled in nor the issues surrounding QT + GL + > > threads. (short answer on this...flash plugin works, no more konsole > > crashes, etc...) This also allows for applications that do need GL support > > to still exist within the distribution. (oh yea..and the pure_virtual > > problems *should* go away) > > > > > > So..what's the drawbacks you might ask? > > > > 1: (obvious) yet another package (well 2)...not really that big of a > > deal 2: anyone who wants their package to link to the GL'd version of QT > > *must* modify their build process to link to libqt-gl instead of libqt. ( > > "-lqt-gl" instead of "-lqt") > > > > Overall I think this will be a good solution until someone comes up with > > another better solution. I'm sure I'll get several bug reports from people > > saying their GL based apps broke and then I'll hear them gripe when I tell > > them they need to install libqt-gl-dev and modify their source. > > > > any major issues before I upload the new packages? > > > > Ivan > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] ---end quoted text--- -- Ivan E. Moore II [EMAIL PROTECTED] http://snowcrash.tdyc.com GPG KeyID=90BCE0DD GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645 8141 90BC E0DD
