You are not logged in.
Ok, Mark. Thanks a lot for the great packages!
Offline
It seems that there is no libopensync package for i686 either. I tried to compile the package from aur but it failed..
Offline
Have a look here:
http://archlinux.org/pipermail/arch-dev … 07780.html
libopensync: kdepim claims to use a development verision > 0.33; but it didn't. And becvause no other package uses that lib I removed it from the repo
Offline
It seems that there is no libopensync package for i686 either. I tried to compile the package from aur but it failed..
Try with libopensync-unstable from aur.
Offline
Hi there, with the last upgrade it seems that installing kdesupport requires some gstreamer stuff that have quite some gnome dependencies..seems funny to me , I have to install some gnome crap for running kde4. Is there a way to fix it, may be the devs have to correct the gstreamer deps removing gnome deps that probably are not really needed?
Thank you for the packages they work really good!
Offline
@capthookb: there was an official libopensync 0.22 for i686 but I couldn't get 0.22 to build for x86_64 nor 0.37(?) to build for i686... so yes, that package needs looking at and I'll try and get the later version built for both archs, include it in my [dev] section, and then build both kdepim archs against it.
@mangus: yes, I wasn't too happy to see gtk show up on a nice fresh installation but that's probably my fault for installing gstreamer0.10-good-plugins, and even though I added only gstreamer0.10-good as a dependency (as I'm unsure what the minimum gstreamer package is needed to provide mp3 support) it seems something in kdesupport may have used something else from the plugins. Perhaps if I simply remove the gstreamer0.10-good-plugins package then it might purge the need for gtk from kdesupport.
Do we need gstreamer support at all? Dragon seems to work well enough with just xine-lib. There's a mplayer/phonon backend out there somewhere. I think I'd rather spend time on that than gstreamer, unless gstreamer buys us something good that I am not aware of?
Offline
Use libopensync-unstable (0.37) from AUR dudes, Its working - for i686
Offline
@mangus: yes, I wasn't too happy to see gtk show up on a nice fresh installation but that's probably my fault for installing gstreamer0.10-good-plugins, and even though I added only gstreamer0.10-good as a dependency (as I'm unsure what the minimum gstreamer package is needed to provide mp3 support) it seems something in kdesupport may have used something else from the plugins. Perhaps if I simply remove the gstreamer0.10-good-plugins package then it might purge the need for gtk from kdesupport.
Do we need gstreamer support at all? Dragon seems to work well enough with just xine-lib. There's a mplayer/phonon backend out there somewhere. I think I'd rather spend time on that than gstreamer, unless gstreamer buys us something good that I am not aware of?
I don't think so... Is anybody here using gstreamer as kde4 backend? For what I know It's probably broken btw...
I think that if gstreamer is intended to be desktop agnostic , the devs should remove gnome deps in their pkgbuild , may be a bug report should help...
BTW the package that links gstreamer and related stuff is qt-copy!
cheers
Offline
@mangus: yes, sorry about experimenting with qt-copy depends and forgetting to remove the gstreamer dependency. The upstream Qt source uses gstreamer by default for phonon under linux and, I think, the reason they do not use xine-lib is because it's fully or mostly GPL and that can't be used by the non-GPL version of Qt so Trolltech/Nokia have no incentive to include xine-lib. If so then this kind of BS is a good reason not to use Qt at all but that is not possible because (for me) it's the best widget set available and GTK is not an option. Anyway, the phonon in kdesupport does include xine-lib so the clues on how to do so for Qt itself are in kdesupport.
I should have a gui/qt-snapshot (4.5) package available in a few days as I want to finally make a start on learning C++ and Qt, which is the main reason I started these daily svn packages back in February. In fact I'll split out my eth-os (non-kde) packages altogether so I can focus on Qt based apps but keep kde-svn ticking over and, yet again, look into creating standalone PKGBUILDs. I think I'll add a manage_vcs() function to each PKGBUILD and call that from the first line in the standard build() function so it keeps the build() clean and simple... then only that line needs to commented out and the sources=() line made into a fully qualified URL and the PKGBUILD then becomes almost 100% standard (assuming the source tarballs are available somewhere).
The next update will not include the pseudo-split dev and doc packages so qt-copy, kdelibs and kdebase will be a good deal larger.
Offline
The next update will not include the pseudo-split dev and doc packages so qt-copy, kdelibs and kdebase will be a good deal larger.
ok, Is this change forever? we have to remove old kdebase-doc and kdebase-dev packs then , and install the new large package, isn't it?
thanks
Offline
@mangus: forever? yes for now. I'd like to revisit how to streamline some or all of the packages one day but for now it makes it quite a bit simpler to just build each package as a whole. qt-copy, kdelibs and kdebase now include the dev and doc parts so a -f (force) will be needed and then remove qt-copy-dev, kdelibs-dev and kdebase-dev (and the doc equivs) after the latest packages are installed along with their new altered depends=(). The paths are the same so the conflicting parts will just overlay what was there before. Then after that perhaps re-install qt-copy, kdelibs and kdebase.
As mentioned, I'll make another effort to make the PKGBUILDs standalone so anyone can build them. I'll keep building these daily packages but I want to make the process simpler so they can be automatically and more reliably built without me having to manually patch them up. I also thought that makepkg would have an official split method by now, but not yet, so unsplitting them is a simpler solution until makepkg has an official splitting method that I don't have to support.
Damn, I forgot to remove gnokii as a dependency from kdepim because gnokii depends on bluez-libs but anyone using testing has testing/bluez and that conflicts with bluez-libs. Next build.
Offline
Shaman gives me this error
shaman: error while loading shared libraries: libalpm.so.2: cannot open shared object file: No such file or directory
If it ain't broke, broke it then fix it.
Offline
@markc
Thanks very much, After 2year and half I did a reinstall of my whole system and your packages are very good , kde4svn seems in a good state ( until next breakage ;-) )
Offline
@Maki: thanks for the notice, hopefully fixed a few days ago.
@mangus: good to hear a fresh install works well. Yep, 4.2 is shaping up to be a good release.
kdepim is proving ornery at the moment. It's kitchensync (needing libopensync) that won't build and that is holding up the whole kdepim package. That means the removing gnokii tweak did not make it, so the bluez-libs vs testing/bluez conflict remains unresolved which means [testing] users will have to say no to the bluez upgrade.
And FWIW, non kde-svn related, but I got the 0.92 Qt based vlc-git source package (from AUR) to build by copying the extra/live-media package and updating the pkgrel to 2008.09.02 and adding "-fPIC" (for x86_64) to my CFLAGS line in /etc/makepkg.conf. I'll package it up for the [gui] repo in a day or so.
Offline
Is anyone having kded4 crashes (due to communication with dbus) or is it just me?
$kded4
kded(4340): Communication problem with "kded" , it probably crashed.
Error message was: "org.freedesktop.DBus.Error.NoReply" : " "Message did not receive a reply (timeout by message bus)" "
...
Offline
yeah, try disabling powerdavil daemon or wait for the next upgrade.
Offline
Looks like kdebase was not building for the last few days (not for x86_64 anyway) so I just did a manual build and it compiled okay this time so a 20080921 i686 kdebase should be up not long after this post. I just restarted my x86_64 desktop and no sign of a kded crash so far. I'm still not sure what to do about kdepim and libopensync yet. If the waiting game doesn't work in a few more days I'll do something about a manual build of both. Kmail still works for me, akregator bombs out occasionally, but so far it hasn't got to a critical non-working state for me. Let me know if kmail stops working for anyone on i686.
Offline
Thanks. Indeed kded4 doesn't crash anymore after the update of the kdebase package. I don't have problems with kmail,akregator so far. I' ll let you know if anything comes up.
Offline
$ /home/sources/KDE svn up
svn: Can't connect to host 'anonsvn.kde.org': Connection refused
I hope this is only a temporary glitch. There is obviously no point running another build untill anonsvn.kde.org is working again.
Offline
But I think its bug from kde, not from your packages
Offline
Evilside it's not a bug. You just have to move the plasmoids in order not to overlap one another
Offline
Evilside it's not a bug. You just have to move the plasmoids in order not to overlap one another
I move them but the same result
Offline
You could try rm ~/.kde/share/config/plasma* if you don't have a specially customized desktop arrangement. There is also some hardcore plasma info here if anyone hasn't already seen this -> http://aseigo.blogspot.com/2008/09/howt … sktop.html
Offline
You could try rm ~/.kde/share/config/plasma* if you don't have a specially customized desktop arrangement. There is also some hardcore plasma info here if anyone hasn't already seen this -> http://aseigo.blogspot.com/2008/09/howt … sktop.html
I tryed with removing plasma configs but the problem is not in them.
Edit: After the next build I will tell you if the issue still exists.
Last edited by EvilSide (2008-09-22 13:16:40)
Offline
Evilside, you are right. I hadn't updated and i was talking about the previous build. It seems that system tray is being refactored
It hs now settings for hidden icons
Last edited by capthookb (2008-09-22 17:15:19)
Offline