You are not logged in.
@capthookb: a good hint, thanks.
@piccolotux: thanks for that, it's been a while now since I've done a fresh install. Re: taglib, the kdesupport package "provides" taglib so as long as the 2 versions do not differ too much (?) then it should not be a problem to let the kdesupport version override the official extra/taglib package... for one xdg/menus solution, see below (untested)... and the overlapping oxygen icons make for a classic bug report at http://bugs.kde.org/simple_search.cgi?id=oxygen+icons as it would be a small oversight and perhaps may even be fixed by now. In general I don't like applying any fixup patches, unless it's a build issue, because the fixes should be applied upstream so everyone benefits.
# add this to /etc/pacman.conf to prevent this file from being overwritten
NoExtract = etc/xdg/menus/applications.menu
Update: krusader (v2 for KDE4) from svn has been added to the [gui] section (it's not an official KDE package). Also, I'm going to split the kde from svn packages back out to their own repo tree in the next day or so, so if your package updates fail then check back here for the correct URLs.
Last edited by markc (2008-07-05 03:11:55)
Offline
Hi Markc
this is a followup to your kind answers. Is there a reason why the path of your packages is not /opt/kde4 or something? I do think it could be more free of installation hassles...
Cheers
Offline
@piccolotux: one reason for not using /opt/kde4 is I'm too lazy to change all the PKGBUILDs and provide a shell profile to match, however, I never intended for these packages to be used in conjunction with extra/kde or KDEmod (stated in the first intro post) as I would personally prefer the PKGBUILDs to be as simple as possible and follow the upstream default KDE layout. Another point of laziness is that if this package set did use /opt/kde4 and was tweaked to co-exist with extra/kde then I would have two extra problems, a lot more people would use them and I'd have a bandwidth issue with my ISP and there would be a different set of problems as more folks tried to use them with a varying set of Archlinux installs and this thread would fill up with "not working with kde3 (or something else)" type posts. So part of the answer to /opt/kde4 is laziness and selfishness and partly "it mostly works the way it is so don't break what doesn't need fixing". The other point is that I am supposed to be releasing my build script which would easily allow anyone else to build these same packages (and help maintain them in the svn source repo) and be able to individually build KDE from svn. I think the average svn update is maybe 20Mb/day (after 2Gb first time download) and the build time is just under 2 hours and easy to put on a cronjob after midnight.
Offline
Thanks markc, very clear and polite. What about your build script? I didn't understand if you will release it or not.. :-)
Offline
@piccolotux: You could try my svn/beta packages, that go into /opt/kde4 or /opt/kde4-svn -> http://bbs.archlinux.org/viewtopic.php?id=49454
Offline
@tanis I did read about your packages and I took a look at your repository's packages. It seems that they're a bit outdated...aren't they? Maybe I'm wrong
Offline
@piccolotux: I think tanis means his source packages are also available and you could use them to build your own binaries. My current working script is very rough and has some hard wired values (inc passwds) and I've always meant to release something a bit more generic that would work on other folks machines. I will just throw what I have into a dev/mpkg package and will try to spend some more time on it sooner than later. If anyone has any ideas or patches then that would be great. Requires the [dev] repo section for the mpkg package or view the pakage contents -> http://eth-os.googlecode.com/svn/trunk/dev/mpkg/
If it works at all then a mpkg build kde kdebase would checkout, or update, trunk from KDEs Subversion repo then build a tarball based on the $pkgver variable in the PKGBUILD, change to the $startdir and proceed with the makepkg -csi build. mpkg build kde might even build all of KDE. It might also create or update the db.tar.gzs and optionally upload the binary packages somewhere. The whole procedure should happen in only 2 areas, $SRCDEST has all the source components including the source pakages themselves, $PKGDEST is where the resulting packages are temporarily stored and then arranged into "distro" folders ready for rsyncing elsewhere. $SRCDEST and $PKGDEST are standard makepkg.conf variables and could be anywhere, defaults are /home/sources and /home/packages.
Offline
@piccolotux: Yes, they are far less up-to-date than Mark's packages - I update them about once a week (and next update will be sometime today).
But you can build them by yourself, package with scripts is available here: http://csclub.uwaterloo.ca/~jkschmid/ar … ts.tar.bz2 .
Just download, unpack it, and run: ./update_all_svn && ./build_all - this will download (or update) svn sources, and build (or at least try to) all packages.
Last edited by tanis (2008-07-07 17:12:32)
Offline
anyone could start amarok?
It always crash after it's Spatter screen displayed.
Offline
@yuanjiayj: mine is version KDE 4.1.60 (KDE 4.2 >= 20080709) and runs okay. I think I had to start it manually from the shell then it ran from the menu (not sure if that is exactly what I did).
I'm not sure what happened to 20080710, maybe the cron job didn't work. 20080711 was a bit late too but I'm running ot now. extragear-graphics and extragear-multimedia didn't build but the amarok from 20080709 is working for me.
Offline
[lee@localhost ~]$ amarok
ALSA lib setup.c:555:(add_elem) Cannot obtain info for CTL elem (MIXER,'IEC958 Playback Default',0,0,0): No such file or directory
ALSA lib setup.c:555:(add_elem) Cannot obtain info for CTL elem (MIXER,'IEC958 Playback Default',0,0,0): No such file or directory
QObject::connect: Cannot connect (null)::rowsInserted( const QModelIndex&, int, int ) to Playlist::RowList::rowsInserted( const QModelIndex &, int, int )
QObject::connect: Cannot connect (null)::rowsRemoved( const QModelIndex&, int, int ) to Playlist::RowList::rowsRemoved( const QModelIndex&, int, int )
QObject::connect: Cannot connect (null)::rowMoved( int, int ) to Playlist::RowList::rowMoved( int, int )
QObject::connect: Cannot connect XmlParseJob::destroyed( QObject* ) to (null)::endProgressOperation( QObject* )
Amarok is crashing!
<unknown program name>(2715)/: Communication problem with "amarok" , it probably crashed.
Error message was: "org.freedesktop.DBus.Error.NoReply" : " "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken." "
[lee@localhost ~]$ 2.0-SVN [___stripped][validity: 0.70][frames: 56]
Amarok has crashed! We are terribly sorry about this :(
But, all is not lost! You could potentially help us fix the crash. Information describing the crash is below, so just click send, or if you have time, write a brief description of how the crash happened first.
Many thanks.
The information below is to help the developers identify the problem, please do not modify it.
======== DEBUG INFORMATION =======
Version: 2.0-SVN
Build date: Jul 8 2008
CC version: 4.3.1
KDElibs: 4.00.85 (KDE 4.0.85 (KDE 4.1 >= 20080703))
Qt: 4.4.0
TagLib: 1.5.0
CPU cores: 1
NDEBUG: true
==== file `which amarok` =======
/usr/bin/amarok: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, stripped
==== (gdb) bt =====================
[Thread debugging using libthread_db enabled]
[New Thread 0xb48e1930 (LWP 2716)]
[New Thread 0xaff8bb90 (LWP 2725)]
[New Thread 0xb0ff3b90 (LWP 2722)]
[New Thread 0xb17f4b90 (LWP 2721)]
[New Thread 0xb2037b90 (LWP 2720)]
[New Thread 0xb288db90 (LWP 2717)]
0xb7f8f424 in __kernel_vsyscall ()
#0 0xb7f8f424 in __kernel_vsyscall ()
#1 0xb7d94acb in waitpid () from /lib/libpthread.so.0
#2 0xb7920a45 in Amarok::Crash::crashHandler ()
from /usr/lib/libamaroklib.so.1
#3 <signal handler called>
#4 0xb781f813 in KDE::StatusBar::newProgressOperationInternal () from /usr/lib/libamaroklib.so.1
#5 0xb07ad969 in XmlParseJob::XmlParseJob ()
from /usr/lib/kde4/libamarok_collection-sqlcollection.so
#6 0xb07b0173 in ScanManager::startFullScan ()
from /usr/lib/kde4/libamarok_collection-sqlcollection.so
#7 0xb07b03b0 in ScanManager::qt_metacall ()
from /usr/lib/kde4/libamarok_collection-sqlcollection.so
#8 0xb7f0082b in QMetaObject::activate ()
from /usr/lib/libQtCore.so.4
#9 0xb7f00d82 in QMetaObject::activate ()
from /usr/lib/libQtCore.so.4
#10 0xb7f078a7 in ?? () from /usr/lib/libQtCore.so.4
#11 0x09145e60 in ?? ()
#12 0xb7f89a64 in ?? () from /usr/lib/libQtCore.so.4
#13 0x00000000 in ?? ()
==== (gdb) thread apply all bt ====
Thread 6 (Thread 0xb288db90 (LWP 2717)):
#0 0xb7f8f424 in __kernel_vsyscall ()
#1 0xb7d90ee2 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
#2 0xb2c71771 in metronom_sync_loop ()
from /usr/lib/libxine.so.1
Thread 5 (Thread 0xb2037b90 (LWP 2720)):
#0 0xb7f8f424 in __kernel_vsyscall ()
#1 0xb4dd49a7 in poll () from /lib/libc.so.6
#2 0xb2084ee4 in ao_alsa_handle_event_thread ()
from /usr/lib/xine/plugins/1.23/xineplug_ao_out_alsa.so
#3 0x00000000 in ?? ()
Thread 4 (Thread 0xb17f4b90 (LWP 2721)):
#0 0xb7f8f424 in __kernel_vsyscall ()
#1 0xb7d90bb5 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
#2 0xb2c83634 in ao_loop () from /usr/lib/libxine.so.1
#3 0x00000000 in ?? ()
Thread 3 (Thread 0xb0ff3b90 (LWP 2722)):
#0 0xb7f8f424 in __kernel_vsyscall ()
#1 0xb4dd49a7 in poll () from /lib/libc.so.6
#2 0xb4c8c612 in g_main_context_iterate ()
from /usr/lib/libglib-2.0.so.0
#3 0xb4c8c941 in g_main_context_iteration ()
from /usr/lib/libglib-2.0.so.0
#4 0xb7f15718 in QEventDispatcherGlib::processEvents ()
from /usr/lib/libQtCore.so.4
#5 0xb7eed77a in QEventLoop::processEvents ()
from /usr/lib/libQtCore.so.4
#6 0xb7eed93a in QEventLoop::exec ()
from /usr/lib/libQtCore.so.4
#7 0xb7e126c3 in QThread::exec ()
from /usr/lib/libQtCore.so.4
#8 0xb2cbc258 in Phonon::Xine::XineThread::run ()
from /usr/lib/kde4/phonon_xine.so
#9 0xb7e15527 in ?? () from /usr/lib/libQtCore.so.4
#10 0x091208d8 in ?? ()
#11 0x00000000 in ?? ()
Thread 2 (Thread 0xaff8bb90 (LWP 2725)):
#0 0xb7f8f424 in __kernel_vsyscall ()
#1 0xb4dd7601 in select () from /lib/libc.so.6
#2 0xb7ed2cd7 in ?? () from /usr/lib/libQtCore.so.4
#3 0x00000008 in ?? ()
#4 0xaff8b288 in ?? ()
#5 0x00000000 in ?? ()
Thread 1 (Thread 0xb48e1930 (LWP 2716)):
#0 0xb7f8f424 in __kernel_vsyscall ()
#1 0xb7d94acb in waitpid () from /lib/libpthread.so.0
#2 0xb7920a45 in Amarok::Crash::crashHandler ()
from /usr/lib/libamaroklib.so.1
#3 <signal handler called>
#4 0xb781f813 in KDE::StatusBar::newProgressOperationInternal () from /usr/lib/libamaroklib.so.1
#5 0xb07ad969 in XmlParseJob::XmlParseJob ()
from /usr/lib/kde4/libamarok_collection-sqlcollection.so
#6 0xb07b0173 in ScanManager::startFullScan ()
from /usr/lib/kde4/libamarok_collection-sqlcollection.so
#7 0xb07b03b0 in ScanManager::qt_metacall ()
from /usr/lib/kde4/libamarok_collection-sqlcollection.so
#8 0xb7f0082b in QMetaObject::activate ()
from /usr/lib/libQtCore.so.4
#9 0xb7f00d82 in QMetaObject::activate ()
from /usr/lib/libQtCore.so.4
#10 0xb7f078a7 in ?? () from /usr/lib/libQtCore.so.4
#11 0x09145e60 in ?? ()
#12 0xb7f89a64 in ?? () from /usr/lib/libQtCore.so.4
#13 0x00000000 in ?? ()
#0 0xb7f8f424 in __kernel_vsyscall ()
I don't know what happened.
Offline
@markc I notice that the 3D molecule editor in kalzium (of kdeedu) is disabled,
Can you enable it ?
Though it need Avogadro as its plugins,and also openbabel 2.2.0 or later!
Thanks very much!
Last edited by yuanjiayj (2008-07-12 02:24:38)
Offline
Hey markc, how stable is the trunk at the moment? You mentioned its already in 4.2 development branch, so are there any major problems or regressions?
Offline
SoftVision,
I'm running trunk (months now) on Arch (using the kdesvn-build tool method of installation), and on Gentoo (using Paludis on one box, and portage on another box).
I continue to see serious progress- it's becoming very usable at this point, much better than any "release" version I've tried since the beginning. For me, there seems no reason to even consider anything else. I've run into no problem that wasn't resolvable, in fact less problems than are currently present with non-truck versions. I'm currently at KDE 4.1.60 (KDE 4.2 >= 20080709).
Once 4.2 final is released, I might consider abandoning trunk, but until then it's too much fun and worth the time spent doing the compiles 1-2 times a week, and keeping up with the new features being implemented. If you enjoy this sort of stuff, I highly recommend giving it a try.
When I have occasion to do another Arch install, I'll give markc's method a try. I've been following the thread, and it seems really well worked out. I would have done so before this, but I already had my Arch partition set up using the "official" kdesvn-build tool installation, and it was working so well I didn't want to switch.
Last edited by wrc1944 (2008-07-12 15:15:13)
Offline
SoftVision,
I'm running trunk (months now) on Arch (using the kdesvn-build tool method of installation), and on Gentoo (using Paludis on one box, and portage on another box).I continue to see serious progress- it's becoming very usable at this point, much better than any "release" version I've tried since the beginning. For me, there seems no reason to even consider anything else. I've run into no problem that wasn't resolvable, in fact less problems than are currently present with non-truck versions. I'm currently at KDE 4.1.60 (KDE 4.2 >= 20080709).
Once 4.2 final is released, I might consider abandoning trunk, but until then it's too much fun and worth the time spent doing the compiles 1-2 times a week, and keeping up with the new features being implemented. If you enjoy this sort of stuff, I highly recommend giving it a try.
When I have occasion to do another Arch install, I'll give markc's method a try. I've been following the thread, and it seems really well worked out. I would have done so before this, but I already had my Arch partition set up using the "official" kdesvn-build tool installation, and it was working so well I didn't want to switch.
Hi wrc1944,
Thanks for the info. I might consider kdesvn-build because it builds and downloads from trunk simultaneously so that is time-saving. I'm worried about the building process though, I don't know how long it would take on my desktop which runs a Pentium 4 2.93Ghz. How often do you update and does it rebuild modules or just make changes to source headers? And yes, I do enjoy tracking KDE's development and implementation of new features. At the moment I'm using KDEmod4 packages but now I might just shift to trunk. I'll give markc's packages a shot if you think the building time would be too long.
Offline
SoftVision,
If you do the kdesvn-build tool method, there's a few things to know before-hand.
First, and most important- if you use the default setup, i.e., the kdesvn source and build directory in /home/your_user, you need about 12GB free space. I think you can configure the .kdesvn-buildrc not to keep the contents of the build directory (which cuts down the required free space), but then you lose the main advantage of the kdesvn-build tool- not having to rebuild the entire installation every time, but just the files that have actually been changed.
I guess you could put kdesvn on another partition, and symlink to it if your /home is too small, and still use the "default" install locations for kde and qt4 in /home. Anyway, the kdesvn-buildrc is very configurable with many options, such as locations, which parts of the packages to build/install, etc. You can use the distro's qt-4.4.0 or opt for qtcopy (building qtcopy takes a huge amount of disk space on /home). I suggest you read thoroughly http://kdesvn-build.kde.org/documentation/ before deciding if this is for you.
You'll need to add some deps with pacman, as not all stuff is included in kdesupport, explained to some extent here. http://techbase.kde.org/index.php?title … Arch_Linux
I found during the compile/configure stage I'm still missing some optional deps that add more features, but can't find some of them with pacman, like gmm++, etc. Not critical, though- I haven't gotten around to installing some them manually.
Hope this helps.
EDIT: Forgot to mention- download the svn version of the kdesvn-buildrc script, NOT the "stable release" version.
Oops- just noticed that July 11 they just released 1.6.2- that should be fine. http://kdesvn-build.kde.org/ Maybe I need to update my script- I'm still using an svn version from 3-4 months ago.
One other thing: In my experience it's a good idea to remove the package sources in kdesvn periodically, especially if you keep having the same error on a specific package. Sometimes even the build directory needs to be refreshed, but that means the next build will have to download and compile the entire thing, and take the normal amount of time a fresh install would..
Last edited by wrc1944 (2008-07-12 17:19:15)
Offline
@yuanjiayj: the only thing I can see about your amarok debug is your version is a week old so maybe you don't have this problem anymore? I'll look into the 3d editor in kalzium.
Update: I managed to get openbabel2 to compile but not indi or qalculator. I added all 3 to the source svn repo. Let's see if openbable2 alone fixes the lack of the kalzium editor. 20080714 may include it.
@wrc1944: thanks for sharing your kdesvn-build script hints. I tried it way back but being a 100K perl script made hacking into it to use PKGBUILDs was going to be a big job. If you care to look at the beginnings of my mpkg script then it wouldn't take too much effort to get it running smoothly in less then 200 lines of bash shell script that anyone could understand and tweak. Ideally, is someone didn't want to build all of kde svn then they could download some of my packages, daily or weekly, and then build certain components themselves, either more regularly or because there is a problem with my packages, or for a langauge(s).
Stability of trunk, the most annoying thing I find is if I run 2 konquerors then one of them will stop working because it can no longer talk to kded. This has been a problem, for me, at least for the last 3 months and at least now I expect it to happen and just quit one browser. About once a week maybe some application will quit with a segfault but it's not annoying enough to classify all of trunk as "unstable". I don't use any composite effects so I'm not sure if that brings on some more problems. I think the main trick with trunk is not to spend oddles of time tweaking things like in kde3, just let it be and get on with using the apps and leave the desktop/plasma mostly alone, except for some exploration to see what's new. There is nothing lacking in kde svn trunk that stops me from doing the work I need to do (mail, browse, edit, occasional yootoob and mp3). I use firefox with firebug a lot but that is nothing to do with kde svn except it leaves a lot of npwrapper processes that I have to manually kill off before doing a build.
Last edited by markc (2008-07-13 09:39:17)
Offline
@markc
Thank you! I have completely translate kalzium.pot to chinese.But the 3d editor is disabled ,so I cannot debug it.kalzium is a edu application,so I want to refine it as accurately as possible.
Avogadro is the key to 3d molecule editor.
Offline
@yuanjiayj: I just now manually rebuilt kdeedu for 20080714 so if you update again then there appears to be an editor in kalzium that was not there before. I'm not sure if openbabel is a makedepends (build time) or a depends (run time) so you may need to install dev/openbabel as well.
@SoftVision: Hey markc, how stable is the trunk at the moment? I misunderstood your question, you mean how stable is trunk since 4.1 was tagged and trunk is now on the way to 4.2... in short, no noticable hiccups beyond the few general niggles (2 konqs conflict) but otherwise no real showstoppers with trunk atm.
Offline
With 4.1.0-20080714 packages konqueror isn't working.
I get messages
konqueror(2493): couldn't create slave: "Unable to create io-slave:
klauncher said: Error loading 'kio_http'.
Probably it will be fixed with the next update.
Offline
With 4.1.0-20080714 packages konqueror isn't working.
I get messageskonqueror(2493): couldn't create slave: "Unable to create io-slave: klauncher said: Error loading 'kio_http'.
Probably it will be fixed with the next update.
I'm getting that error too. Its actually to do with a dependency called 'heimdal' in Arch which got updated so there was breakage from what I know so this should get resolved with an svn update soon.
Offline
SoftVision wrote:
I'm worried about the building process though, I don't know how long it would take on my desktop which runs a Pentium 4 2.93Ghz. How often do you update and does it rebuild modules or just make changes to source headers?
How long it takes depends on how often you update. Of course the first time you build everything, or when you do a complete refresh, it takes much longer. Using an athlon-xp 3000+ (Barton core) with 1GB ram, a fresh build of everthing takes me about 6 hours. I think the athlon-xp I'm using is roughly equivalent to your pentium 4 as far as performance is concerned.
For example, if I do a complete update at two day intervals, it might take only 1-2 hours, depending on how many files have actually changed in trunk. Keep in mind you can also update individual modules, but I've found it better to do the whole list, due to version compatibilty issues (just the nature of svn versions changing constantly). Also, you don't have to build/install everything kde offers- just the kdesupport/other deps, and the basic qt, kdelibs, kdepimlibs, and kdebase modules. The others are pretty much optional, and are mainly added features.
A better way to trim it down (build time and final app binary size) is to specify which parts (packages) of each basic module to build in the .kdesvn-buildrc file, but this too has it's downside. This is sort of like using the Gentoo kde split ebuilds, in that you wind up with only the parts of each module you really want.
However, I found that sometimes not building one package in module A breaks module B, so you really have to know the dependency relationships between the apps contained in each basic module.
One other tip: Use the --debug option at the command line (like, "./kdesvn-build --debug" for everything, and as an example "./kdesvn-build kdegames --debug" for the games module . It's not building bloated "debug code" into the binary, it's just giving you very verbose gcc compiling output so you can't see what's going on. The so-called "--verbose" option they mention gives virtually nothing. However, the different log files are very informative, and are all saved in kdesvn by default.
Last edited by wrc1944 (2008-07-14 19:43:10)
Offline
Hi.
If anyone is interested in debug-enabled version of KDE4, I have created some new repositories: http://bbs.archlinux.org/viewtopic.php?id=49454
@capthookb, SoftVision: I get this error too
Offline
@tanis: what is the total size of your debug packages ?
My x86_64 build has not been working for the past few days so I didn't notice the recent trunk changes for 4.2. As it turns out, I can't build kdebase atm.
I've also changed my repo layout so that the KDE svn packages are under "kde-svn" and my other package sections are now inside "eth-os" (that is, min cli net gui dev max) so anyone using some [gui] and [dev] packages will have to change their pacman.conf [repo] Server settings. There is a softlink from kdesvn/ -> kde-svn/ so it should keep working for the main KDE svn packages but I'd like to remove that link in a week. There is now a "proaudio" section which I'll start updating too. Once I get my "mpkg" version 2 script working with persistent versioning, so I only build a package if my svn repo is actually updated, I may consider building just the kde-svn packages 3 times per day as it takes just under 8 hours to build and upload both i686 and x86_64.
# for i686 users
[kde-svn]
Server = http://pkg.eth-os.org/kde-svn/i686
[gui]
Server = http://pkg.eth-os.org/eth-os/gui/i686
[dev]
Server = http://pkg.eth-os.org/eth-os/dev/i686
# for x86_64 users
[kde-svn]
Server = http://pkg.eth-os.org/kde-svn/x86_64
[gui]
Server = http://pkg.eth-os.org/eth-os/gui/x86_64
[dev]
Server = http://pkg.eth-os.org/eth-os/dev/x86_64
Last edited by markc (2008-08-03 21:21:51)
Offline
@markc:
$ du -hs release/* debug/* lang
473M release/i686
482M release/x86_64
1.5G debug/i686
1.6G debug/x86_64
326M lang
"debug" is compiled with 'RELWITHDEBINFO'. What are your sizes?
Yesterday kdebase compiled fine, now I am experiencing some linking error as well. The same goes for plasma-addons.
Also, kio_http bug is gone, after rebuilding with updated heimdal.
UPDATE: Both kdebase and plasma-addons compile just fine atm.
Last edited by tanis (2008-07-15 14:42:59)
Offline