arts copilation problem
I cann't compile the Head of arts it gives: Making all in qtmcop make[2]: Entering directory `/home/tester/KDE/arts/qtmcop' /home/tester/KDE/qt-copy/bin/moc ./qiomanager_p.h -o qiomanager_p.moc source='qiomanager.cc' object='qiomanager.lo' libtool=yes \ depfile='.deps/qiomanager.Plo' tmpdepfile='.deps/qiomanager.TPlo' \ depmode=gcc /bin/sh ../admin/depcomp \ /bin/sh ../libtool --silent --mode=compile --tag=CXX g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../mcop -I/home/tester/KDE/include -I/home/tester/KDE/qt-copy/include -I /usr/X11R6/include -I../libltdl -I/home/tester/KDE/qt-copy/include -DQT_THREAD _SUPPORT -D_REENTRANT -Wnon-virtual-dtor -Wno-long-long -Wundef -Wall -pedanti c -W -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -ansi -D_XOPEN_SOURCE= 500 -D_BSD_SOURCE -Wcast-align -Wconversion -O2 -fno-exceptions -fno-check-new -ftemplate-depth-99 -c -o qiomanager.lo `test -f qiomanager.cc || echo './'`qio manager.cc /bin/sh ../libtool --silent --mode=link --tag=CXX g++ -Wnon-virtual-dtor -Wno-l ong-long -Wundef -Wall -pedantic -W -Wpointer-arith -Wmissing-prototypes -Wwrite -strings -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -O2 - fno-exceptions -fno-check-new -ftemplate-depth-99-o libqtmcop.la.closure li bqtmcop_la_closure.lo -no-undefined -version-info 1:0 -R /home/tester/KDE/lib -R /home/tester/KDE/qt-copy/lib -R /usr/X11R6/lib -L/home/tester/KDE/qt-copy/lib -L/usr/X11R6/lib qiomanager.lo ../mcop/libmcop.la -lqt-mt -lpng -lz -lm -lXext -lX11 -lSM -lICE -lpthread libtool: link: warning: `-version-info' is ignored for programs .libs/qiomanager.o: In function `Arts::QIOWatch::staticMetaObject(void)': .libs/qiomanager.o(.text+0xd12): undefined reference to `QMetaObject::new_metaob ject(char const *, QMetaObject *, QMetaData const *, int, QMetaData const *, int , QMetaProperty const *, int, QMetaEnum const *, int, bool (*)(QObject *, int, i nt, QVariant *), QClassInfo const *, int)' .libs/qiomanager.o: In function `Arts::QIOWatch::qt_static_property(QObject *, i nt, int, QVariant *)': .libs/qiomanager.o(.text+0xe95): undefined reference to `QMetaObject::qt_static_ property(QObject *, int, int, QVariant *)' .libs/qiomanager.o: In function `Arts::QTimeWatch::staticMetaObject(void)': .libs/qiomanager.o(.text+0xfc2): undefined reference to `QMetaObject::new_metaob ject(char const *, QMetaObject *, QMetaData const *, int, QMetaData const *, int , QMetaProperty const *, int, QMetaEnum const *, int, bool (*)(QObject *, int, i nt, QVariant *), QClassInfo const *, int)' .libs/qiomanager.o: In function `Arts::QTimeWatch::qt_static_property(QObject *, int, int, QVariant *)': .libs/qiomanager.o(.text+0x1141): undefined reference to `QMetaObject::qt_static _property(QObject *, int, int, QVariant *)' .libs/qiomanager.o: In function `__static_initialization_and_destruction_0': .libs/qiomanager.o(.text+0x11a8): undefined reference to `QMetaObjectCleanUp::QM etaObjectCleanUp(char const *, QMetaObject *(*)(void))' .libs/qiomanager.o(.text+0x11c7): undefined reference to `QMetaObjectCleanUp::QM etaObjectCleanUp(char const *, QMetaObject *(*)(void))' collect2: ld returned 1 exit status make[2]: *** [libqtmcop.la.closure] Error 1 make[2]: Leaving directory `/home/tester/KDE/arts/qtmcop' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/tester/KDE/arts' make: *** [all] Error 2 Can anybody help me?
Re: Fwd: Re: KMail Folder Disappeared!?!?! -- Index Recreation
Quit kmail, delete the index files, i.e rm ~/Mail/.Data.index*, and restart kmail and it should reappear. Nick I tried the above and did not work in my case. After much work I gave up, deleted ~/.kde/config/apps/kmailrc and began again. All of my email directories were recreated except for my Data dir. Now I assume that something has been changed about the file. Can anyone give me a way to recover a maildir into KMail? -- -rw---1 oracle oracle 3022742791 2002-10-20 20:12 Data the mail is in a mbox file not a maildir so options are you can go through it by hand looking for the problem I did a 'apt-cache search mbox' and there are a few that might help 'mail-expire' looks interesting mail-expire is a small and fast script that scans mbox files for messages that are older than given maximum age and moves them to another (compressed) mailbox file or just deletes them. you could get to move all mail more than day old to a new mbox and then uncompress it and try that Nick
Ruminations on package locations
(PS: Please CC me; I'm not on the list). (PPS: Prescript, not postscript). (PPPS: Not GhostScript, either). Hi all, First off, let me apologize for apparently causing some confusion. The 3.0.3 release was the first where the debs were stored on download.xx.k.o. There were a few reasons: * kde3.geniussystems.net was down, and I couldn't get on to WhizNDR- * k.o is mirrored by most ISPs in Estonia * (read between the lines on that last one, it's really not hard) * It was basically the standard location for packages for every distribution ... except us. Personally, I think that's where they should stay. Of course, a perfect world would see g++ 3.2 in sid and fully transitioned now, but there you go. I personally regard KDE2.2 as (largely) irrelevant to Debian, and focus my (limited) efforts on KDE3 - I've had exams lately (my most recent one, the Indonesian oral exam, was 1h30m ago, see Advogato's recentlog if you want to know more about it) and no Internet connection at home. KDE3.1 is close to being released, and people are already thinking of KDE3.2 (seeing as 3.1 is branched, and there's a post-3.1 branch ...). I personally think that, until g++ 3.2 is fully working and transitioned in sid (yeah, yeah, I know that's slightly backwards, stuff it, I'm absolutely fucking stuffed here. Dad woke me up at 6:20am. Didn't go back to sleep, and I was studying till rather late last night. UGH), KDE3 should be in neither sid, nor experimental. That leaves us with three options: * run with a setup akin to k3.g.n + IMHO not the right way to go - not enough mirrors, reliability or bandwidth; witness my situation with 3.0.3. * keep using download.xx.k.o + not a terribly bad idea, really. Feels sort of perverse putting out-of-KDE stuff in there tho * take Joey up on his suggestion and revive k.d.o + probably the best option if we can get it run on gluck, or something. So, I believe we should either organize k.d.o on gluck/klecker/satie/whatever, as Joey said, or maintain the rough status quo, but unify all the repositories to just be the one repository under download.xx.k.o. This has the advantage of being fully mirrored, etc. I don't, however, believe it should be dumped into experimental, partially for the reasons Ben summed up - it's full of other shit, among other things. Hopefully KDE3 will be a smooth transition (migration complete within 4-7 days), and I'd be only too happy to help with it after the 20th of November (well, last exam, and there's going to be a gigantic party then for obvious reasons, so make it the 21st). I just want to see it done *right*. As the most-commented story ever on DebianPlanet can attest to, it's already somewhat of a debacle, so I don't want to see it dragged out longer, or made worse. I personally believe everyone should just settle on the one individual option, and leave it at that. If we can settle on a status quo which is one sources.list line per user, get all the Debian KDE maintainers (myself, David, Ben, other-Daniel, Chris, Ralf) to work on that, that would be pretty ace. I'd even create a site (probably using junpei[1] for simplicity) to track all of this, and give information, though probably not as acid-tipped at the XSF. Apologies if this email seems rambling and incomprehensible; it is. I've just had one of the most stressful days I've ever had, I've only had 3 hours' sleep, thanks to Dad, and I'm leaving in under 5 minutes to go to the pub and drown myself in beer, and get absolutely shitcaned in pool. Hopefully you all get the idea. Enjoy, d [1]: http://www.trinity.unimelb.edu.au/~dstone/junpei/ (This rambling piece of crap doesn't necessarily reflect the opinions of Trinity, blah blah etc etc wank wank). -- Daniel Stone [EMAIL PROTECTED] Developer, Trinity College, University of Melbourne pgpBHi2Y7wHo2.pgp Description: PGP signature
Current kde.org Debian packages
Am I right in assuming these packages have been compiled against gcc 2.95? There's a lot of talk about incompatibilities in moving to gcc 3.2, however I haven't seen any discussion on the problems that will be faced by users like me who are using packages from the KDE 3.x.x series. I hope we don't have a lot of enthusiastic but disappointed users :-}. -Andy
Re: OpenPGP Plugin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 23 October 2002 12:28 am, Hasso Tepper wrote: David Pashley wrote: It is a bit easier than ralf thinks, but still not particularly easy. run: apt-get install libgpgme-dev apt-get source libgpgme6 cd in to gpgme source dir edit debian/rules and add --enable-gpgmeplugin to the configure line [0] run debuild -us -uc then copy the debian/tmp/usr/lib/gpgme dir to /usr/lib In kmail, load both of the .so files in /usr/lib/gpgme. You should fine that they now work. NOTE: THIS IS NOT SUPPORTED AND THE FILES WILL NOT BE DEALT WITH BY THE PACKAGING SYSTEM [0] You will need to check the correct name for this option. use ./configure --help But it is not enough to _use_ plugin. You will need gpg-agent and pinentry as well. It will allow you to read PGP/MIME emails, but not send them. -- Hasso - -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9tmQ0YsCKa6wDNXYRAsdfAJ9gtOL2gzUP5W/pL2xlXoI1k2TbkQCgpJzC x7r2/cnO5oXGSTn5j/6GYHU= =yFOB -END PGP SIGNATURE-
Re: Current kde.org Debian packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 23 October 2002 10:30, Andy Saxena wrote: Am I right in assuming these packages have been compiled against gcc 2.95? There's a lot of talk about incompatibilities in moving to gcc 3.2, however I haven't seen any discussion on the problems that will be faced by users like me who are using packages from the KDE 3.x.x series. If you compile a KDE app with gcc 3.2 on KDE 3.0.4 for sid, the program won't work. KDE/Qt are compiled with gcc 2.95 (the standard g++ command at the time of the build) Ralf I hope we don't have a lot of enthusiastic but disappointed users :-}. -Andy - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9tqUYu0nKi+w1Ky8RAjceAJ9L6NNx1pcAdRo90VE2H/X3xVd0qACfZrk1 XqJco2I8cWM9mXseSej9RmI= =DFmL -END PGP SIGNATURE-
unsubscribe
unsubscribe
mc konsole qt
- ... , qt gdb. - , .http://bugs.kde.org/show_bug.cgi?id=44993.
Re: debian unter vmware
hello, I think it would be better if you could tipe your question in english. wolfgang - No love left in me. No eyes to see the heaven beside me. My time is yet to come so I'll be forever yours. Nightwish - Century Child - Forever Yours
Re: arts copilation problem
On the last episode (Wednesday 23 October 2002 08:03), Arash Bijanzadeh wrote: I cann't compile the Head of arts it gives: .libs/qiomanager.o(.text+0x11c7): undefined reference to `QMetaObjectCleanUp::QM etaObjectCleanUp(char const *, QMetaObject *(*)(void))' collect2: ld returned 1 exit status make[2]: *** [libqtmcop.la.closure] Error 1 make[2]: Leaving directory `/home/tester/KDE/arts/qtmcop' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/tester/KDE/arts' make: *** [all] Error 2 Can anybody help me? It seems to me a QT problem. If you compile HEAD you should also use HEAD'S QT. If it's already so, try waiting some days and cvsupdate it again. Ciao, Paolo -- If Linux is not Unix then Windows are not Gates Anonymous, XXI Century
unsubscribe
unsubscribe
Re: Ruminations on package locations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 23 Oct 2002 20:40, Daniel Stone wrote: If we can settle on a status quo which is one sources.list line per user, get all the Debian KDE maintainers (myself, David, Ben, other-Daniel, Chris, Ralf) to work on that, that would be pretty ace. - From a user's perspective I'd prefer experimental to ftp.kde.org. experimental is much more clearly part of debian so it is clear that the packages will be the official packages once the bugs are ironed out, as opposed to someone being helpful and puting up an apt repository. Thanks to gnome2, experimental is already in my sources.list with low priority so it isn't yet another Packages.gz to download each day (since it is accessed via FTP, kde's repository is quite slow to check). From a developer's perspective, experimental makes it easier to package programs that depend on KDE3. Having said all that, I don't feel very strongly about it. Corrin -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9tzGVi5A0ZsG8x8cRAtHvAJ46b4nncSA4sa2zkbD0gBBPCtOftwCeNhra 1XcI7gH4i0cj0dxmROLWwy8= =4rNY -END PGP SIGNATURE-
Re: Ruminations on package locations
On Thu, Oct 24, 2002 at 12:32:33PM +1300, Corrin Lakeland scrawled: On Wed, 23 Oct 2002 20:40, Daniel Stone wrote: If we can settle on a status quo which is one sources.list line per user, get all the Debian KDE maintainers (myself, David, Ben, other-Daniel, Chris, Ralf) to work on that, that would be pretty ace. - From a user's perspective I'd prefer experimental to ftp.kde.org. experimental is much more clearly part of debian so it is clear that the packages will be the official packages once the bugs are ironed out, as opposed to someone being helpful and puting up an apt repository. Thanks to gnome2, experimental is already in my sources.list with low priority so it isn't yet another Packages.gz to download each day (since it is accessed via FTP, kde's repository is quite slow to check). From a developer's perspective, experimental makes it easier to package programs that depend on KDE3. Only problem is that experimental, as Ben said, contains a whole bunch of other stuff. A lot of users want to use KDE3, and it's not that experimental. They don't want to drag other stuff in. You can, BTW, access KDE's repository via HTTP. I agree with you that it makes life easier, but we could just give all packagers of KDE apps access to the repository, whether it be on gluck or ktown(.k.o). Currently, myself, Chris, Ben, David, and others have access to the ktown account. :) d (Ugh. Hangover). -- Daniel Stone [EMAIL PROTECTED] Developer, Trinity College, University of Melbourne pgpOsFz8wK88b.pgp Description: PGP signature
KDevelop: API-Index conundrum
KDevelop (2.13) is trying to make a fool of me. It does not show the KDE3 docs in the help tree below Qt/KDE Libraries. It does show entries for projects I have created (one of them deleted in the meantime). Where are these settings stored? I've searched everywhere I could think of and then some more and didn't find it. Michael -- Michael Schuerig If at first you don't succeed... mailto:[EMAIL PROTECTED] try, try again. http://www.schuerig.de/michael/ --Jerome Morrow, Gattaca
Re: why kde and gnome's menu situation sucks
On Mon, Oct 21, 2002 at 12:06:05AM -0400, Joey Hess scrawled:
Debian should follow the lead of every other major distro and offer the
exact same menu layout throughout.
-- http://debianplanet.net/node.php?id=831
I cannot help but shudder when I read that comment in this negative
Debian review. We *led* the way: we wrote menu, we put everything in
menu, we made every window manager (even twm, for crying out loud!) use
menu. And then gnome and kde came along, and we threw all that out the
window. No excuses: This stinks. We should be able to do much better.
Not necessarily. When I use KDE, I largely want to use KDE apps. I
personally think GNOME/KDE should offer their own menus, with a submenu
in each category for Non-{GNOME,KDE} Applications. I don't see a
problem with this, i.e. how our KDE3 packages do it.
--
Daniel Stone [EMAIL PROTECTED] [EMAIL PROTECTED]
Developer - http://kopete.kde.org, http://www.kde.org
Proof BitMover are community-focussed:
http://marc.theaimsgroup.com/?l=linux-kernelm=103384262016750w=2
pgpKD2PknYWbu.pgp
Description: PGP signature
