Daily KDE4 Subversion Packages

tanis · 2008-06-06 14:10:57

Hi again. After struggling with some of the packages I thought I might share my solutions to some problems you might encounter at some point - depending on dependencies you use for
your packages, but not only that. So, here it goes - I hope it is useful

extragear-graphics
        cmake ../../svn -DCMAKE_INSTALL_PREFIX=${KDEDIR} -DCMAKE_BUILD_TYPE=RELEASE
        # Digikam could not be compiled by gcc 4.3.0 with the -O2 optimization:
        # http://www.nabble.com/digikam4-svn-td17016891.html
        # http://sourceforge.net/forum/message.php?msg_id=4959332
        sed -i 's/-O2/-O1/g' digikam/digikam/CMakeFiles/digikam.dir/flags.make
        make DESTDIR=$pkgdir install || return 1

extragear-multimedia
        # Files present in KDEBase as well:
        rm $pkgdir/opt/kde4-svn/share/icons/oxygen/128x128/apps/kmplayer.png
        rm $pkgdir/opt/kde4-svn/share/icons/oxygen/16x16/apps/kmplayer.png
        rm $pkgdir/opt/kde4-svn/share/icons/oxygen/22x22/apps/kmplayer.png
        rm $pkgdir/opt/kde4-svn/share/icons/oxygen/32x32/apps/kmplayer.png
        rm $pkgdir/opt/kde4-svn/share/icons/oxygen/48x48/apps/kmplayer.png
        rm $pkgdir/opt/kde4-svn/share/icons/oxygen/64x64/apps/kmplayer.png
        rm $pkgdir/opt/kde4-svn/share/icons/oxygen/scalable/apps/kmplayer.svgz

kdebindings
    # Right now lots of things break from revision to revision, those additional arguments for cmake worked in one ;)
    -DENABLE_QTRUBY=OFF -DENABLE_KORUNDUM=OFF -DENABLE_QSCINTILLA=OFF -DENABLE_QWT=OFF -DENABLE_SOPRANO=OFF -DENABLE_KROSSPYTHON=OFF -DENABLE_PYKDE4=OFF

kdepim
        # x86_64 needs special version of libassuan, compiled with -fPIC:
        [ "$CARCH" = "x86_64" ] && export CFLAGS="$CLFAGS -fPIC"

kdevelop
        # Exists in KDE-SDK:
        rm $pkgdir/opt/kde4-svn/share/apps/kdevappwizard/templates/qmake_qt4guiapp.tar.bz2

kdevplatform
        # Fix Boost problem with x86_64:
        # http://thread.gmane.org/gmane.comp.lib.boost.devel/172455
        # http://svn.boost.org/trac/boost/ticket/1715
        [ "$CARCH" = "x86_64" ] && CXXFLAGS="$CXXFLAGS -DBOOST_NO_INTRINSIC_INT64_T"

koffice
    graphicsmagick can't be installed in the system, makes compilation of koffice fail

playground-libs
        # Those exist also in kde4-svn-kdelibs:
        rm $pkgdir/opt/kde4-svn/share/apps/cmake/modules/FindEigen.cmake
        rm $pkgdir/opt/kde4-svn/share/apps/cmake/modules/FindPackageHandleStandardArgs.cmake

yuanjiayj · 2008-06-06 14:57:06

I never get gwenview to view images.
Now,I get the info:
gwenview: error while loading shared libraries: libexiv2.so.4: cannot open shared object file: No such file or directory

so I cd /usr/lib, and ln -s ln -s libexiv2.so.2 libexiv2.so.4(I install exiv2 in testing),then run gwenview.
gwenview's GUI run properly, but when I let it to display my user directory, it crashed.

(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 0xb633d6d0 (LWP 4869)]
[New Thread 0xb4074b90 (LWP 4872)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[KCrash handler]
#6  0xb6887f0a in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string () from /usr/lib/libstdc++.so.6
#7  0xb69399ec in Exiv2::Image::comment () from /usr/lib/libexiv2.so.4
#8  0xb75dcd63 in Gwenview::ImageMetaInfoModel::setExiv2Image ()
   from /usr/lib/libgwenviewlib.so.4
#9  0xb75c84ec in Gwenview::Document::setExiv2Image ()
   from /usr/lib/libgwenviewlib.so.4
#10 0xb75c77b7 in Gwenview::AbstractDocumentImpl::setDocumentExiv2Image ()
   from /usr/lib/libgwenviewlib.so.4
#11 0xb75cde68 in Gwenview::LoadingDocumentImpl::slotMetaDataLoaded ()
   from /usr/lib/libgwenviewlib.so.4
#12 0xb75ce335 in Gwenview::LoadingDocumentImpl::qt_metacall ()
   from /usr/lib/libgwenviewlib.so.4
#13 0xb802879b in QMetaObject::activate () from /usr/lib/libQtCore.so.4
#14 0xb8028cf2 in QMetaObject::activate () from /usr/lib/libQtCore.so.4
#15 0xb805c807 in QFutureWatcherBase::finished () from /usr/lib/libQtCore.so.4
#16 0xb7f3083f in QFutureWatcherBasePrivate::sendCallOutEvent ()
   from /usr/lib/libQtCore.so.4
#17 0xb7f30c51 in QFutureWatcherBase::event () from /usr/lib/libQtCore.so.4
#18 0xb6badfbc in QApplicationPrivate::notify_helper ()
   from /usr/lib/libQtGui.so.4
#19 0xb6bb4fae in QApplication::notify () from /usr/lib/libQtGui.so.4
#20 0xb7b45f6d in KApplication::notify () from /usr/lib/libkdeui.so.5
#21 0xb8016f71 in QCoreApplication::notifyInternal ()
   from /usr/lib/libQtCore.so.4
#22 0xb80178c3 in QCoreApplicationPrivate::sendPostedEvents ()
   from /usr/lib/libQtCore.so.4
#23 0xb8017a5d in QCoreApplication::sendPostedEvents ()
   from /usr/lib/libQtCore.so.4
#24 0xb803d8af in ?? () from /usr/lib/libQtCore.so.4
#25 0x00000000 in ?? ()
#0  0xb80b8424 in __kernel_vsyscall ()

And when I try to display some image,it shows:

QObject::connect: Cannot connect (null)::rowsRemoved(const QModelIndex&, int, int) to KFilePlacesView::adaptItemSize()
gwenview(4895)/kio (KIOJob) KDirModel::indexForUrl: KUrl("file:///home/lee/qmmp.png") not found
gwenview(4895)/kio (KDirListerCache) KDirListerCache::emitItemsFromCache: "file:///home/lee" not in cache anymore; this was unexpected

Last edited by yuanjiayj (2008-06-06 15:00:56)

Belitsky.A · 2008-06-06 15:05:21

2yuanjiayj: exiv2 from testing don't work with gvenwiev so use exiv2 from dev repo, add to /etc/pacman.conf this ([dev] must be before [extra]):

[dev]
Server = http://pkg.markconstable.com/dev/$CARCH/

and then in terminal run

sudo pacman -Sy exiv2

Last edited by Belitsky.A (2008-06-06 15:07:38)

Cimi · 2008-06-06 15:18:46

markc wrote:

@Cimi: I doubled checked and I definitely have backup=(etc/xdg/menus/applications.menu) in the kdelibs PKGBUILD but sure enough when I made a simple change to the menu file and reinstalled kdelibs it didn't create a applications.menu.pacnew file. There is more to it, however, in rtfm I notice there is an option in /etc/pacman.conf to ignore upgrading certain files so add NoUpgrade = etc/xdg/menus/applications.menu in the [options] section at the top of pacman.conf and that should do what you want. Please let us know if that works.

and why not something like this?
http://repos.archlinux.org/viewvc.cgi/k … iew=markup

markc · 2008-06-06 15:35:10

@tanis: wonderful, thank you. The 20080607 packages are currently building so I won't try any of these suggestions tonight but I will for tomorrow night (my time is +10 gmt).

It would be good if we could somehow (all) co-operate on a common set of kde-svn packages, for example, instead of you posting these tips here that you (and I or anyone else with suitable perms) directly update a VCS repo which would save a lot of time and be more effective... assuming it's possible to build what both of us (and anyone else) wants from the same source package set. I'm adamant about two points, 1) I do not want to integrate with or use KDE3 apps so using /usr as CMAKE_INSTALL_PREFIX is preferred, 2) I want to keep all original VCS and tarball sources in $SRCDEST (/home/sources by default) because it's just plain easier to manage separate $SRCDEST and source package trees over the long term (rather than try to keep VCS and source tarballs within each source package directory). The first point can easily be resolved by using a global ${KDEDIR} pulled from some common conf file in /etc or ~. The second point is much harder to solve. Either the official makepkg needs to be patched or updated to deal with both the current option of VCS in the source package dir OR in $SRCDEST, or, a wrapper script has to manage the $SRCDEST updates then call makepkg, or, all the ugly and gory details of pulling the VCS sources (into $SRCDEST or $(pwd)) needs to be added to each PKGBUILD. Providing a patch to modify makepkg would be the cleanest *if* the ArchLinux core developers would consider such an option.

I know I've said this before but I will make another attempt at getting a sanitized version of my "mpkg" build script uploaded to the source repo so it can provide yet another example of how to build a set of packages. There are also some build scripts available from the "proaudio" Google Code repo and KDEMod... plus the official AL makeworld script which I haven't even looked at yet, and frugalware and other distros. If we could streamline the source package sets, and also the build systems, then I am sure it would help accelerate our combined efforts to provide a decent set of binary kde-svn (and other) package sets.

Any suggestions or comments are most welcome.

markc · 2008-06-06 16:05:15

@Cimi: good link, thanks. My first impression is that patching KDE to have it's own kde-applications.menu would kind of defeat the purpose of a generic etc/xdg/menus for all desktop/window-managers. As long as the kde-svn kdelibs does not overwrite your current applications.menu then that seems (moreso) the right thing to do (to me) and NoUpgrade should do that.

I think a question would be, are you happy with the GNOME (I assume) provided applications.menu as it appears within your install of these kde svn packages when you log into the kde desktop (but using the GNOME provided applications.menu)? (I don't use GNOME so I have no idea.) If so, then the official ArchLinux NoUpgrade option is the best way to go. If not, and you feel there really is no combined GNOME/KDE menu option possible then patching KDE to have it's own menu set is then preferred. I'd rather not patch kde svn unless it's really essential. Are you happy with the GNOME provided applications.menu when you run KDE4?

Patching a stable KDE install makes sense but any possible patches to KDE4 svn is really best applied to the official upstream subversion repo rather than (for example) my binary packages... simply because subversion based packages are likely to change so often at the whim of the upstream developers, which is out of control and possibly out of sync with any patches that I might apply. As opposed to a stable set of release packages that will not change, and therefor any local or specific distro packaging patches will stick around for the long term.

tanis · 2008-06-06 16:07:26

It would be great to cooperate
The 1) point is easy to do, and now all my packages do just that - they start with: . /etc/profile.d/kde4-svn.sh || return 1
This file (Installed by kde4-svn-common, which contains nothing but this single file - and is dependency of some basic packages) includes following:

export KDEDIR=/opt/kde4-svn
export KDEDIRS=$KDEDIR
export KDEHOME=~/.kde4-svn
export XDG_DATA_DIRS=$KDEDIR/share:$XDG_DATA_DIRS
export PATH=$KDEDIR/bin:$PATH
export LD_LIBRARY_PATH=$KDEDIR/lib:$LD_LIBRARY_PATH
export PKG_CONFIG_PATH=$KDEDIR/lib/pkgconfig:$PKG_CONFIG_PATH
export QT_PLUGIN_PATH=$KDEDIR/lib/kde4/plugins:$QT_PLUGIN_PATH
export CMAKE_LIBRARY_PATH=$KDEDIR/lib:$CMAKE_LIBRARY_PATH
export CMAKE_INCLUDE_PATH=$KDEDIR/include:$CMAKE_INCLUDE_PATH

And it works nice. As for the second point - I have two types of packages, those for for svn sources, and those for "normal" sources.
"normal" packages just use normal makepkg behaviour. For svn packages, there is a symlink in every package's directory,
pointing to a directory of this package in a svn tree kept somewhere else, for example for kdelibs it is: svn -> ../../svn_sources/KDE/kdelibs.
When I update svn sources, I just run update script once, before building anything. Later, "build_all" script goes through packages and checks if the svn directory
of the package contains newer revision. If it does, it builds the package (creates a build directory, and from this directory runs cmake ../svn). If the package is built correctly,
it marks the last revision built (for current architecture). Also, I have two chroot's, one for 32 and the other for 64 bit packages, but they use the same sources and pkgbuilds. Scripts are just aware of the architecture they are working for, so all the logs, files and directories created contain the architecture name, if it is possible that two concurrent builds might collide without that.

It works nice, but I don't think it is suitable for official packages, it's more for 'development-experimental snapshots'
If you want to give it a try, you need just to change the content of /etc/profile.d/kde4-svn.sh file installed by one of the packages to point to /usr,
and everything should work fine (Except for different package names, and possibly more collisions) - probably with applications.menu file, and libassuan for x86_64 architecture - right
now I just have separate copy of the library compiled with -fPIC installed automatically into /opt/kde4 - it would collide with official libassuan.

As for the dependencies used for packages, I tried to get as much of each package as I could - I enabled all dependencies it was telling it could use (though I could have missed some),
that didn't cause the compilation to fail (like graphicsmagick), except for Java, Ocaml and C# stuff. And some packages/libraries that are not part of Arch or are too old in Arch's repos.
And Hebrew Spellchecker

markc · 2008-06-06 17:03:17

@tanis: it's 2.30am here and I'm about to go zzz, have you checked how many variables in your /etc/profile.d/kde4-svn.sh are actually needed? As in, are some of them defaults that do not need to be there, or are you playing it safe be declaring and covering "all possibilities"?

As far as some canonical kde-svn build config file is concerned, unless any file in /etc/profile.d/ is made executable then it's not really a "real" Bash source file and could really be somewhere else in /etc, like some more generically named "/etc/kde-svn-build.conf" type file with a ~/.kde-svn-build.conf local user override. I think KDEmod has popularized separate /etc/profile.d kde3 and kde4 source files but, like I say, unless either or both are executable then they're not playing by the strict bash /etc/profile.d/ rules and do not need to be in /etc/profile.d/.

It seems to me that it's only "export KDEDIR=/opt/kde4-svn" and "export KDEHOME=~/.kde4-svn" that provide the distinct and important differences between our two PKGBUILDs, aside from various per pkg build tweaks. I'm not sure all the other variables in your kde4-svn.sh files are actually needed. If not then we really only need to provide global bash env vars of (for example) "export PREFIX=/opt/kde-svn", "export KDEDIR=$PREFIX" and "export KDEHOME=~/.kde4-svn" from any generic /etc based file, with an optional ~/ override. I say PREFIX instead of KDEDIR because I find other non-kde apps also need a "configure --prefix=$PREFIX" which could also be "export KDEDIR=$PREFIX" for kde-svn use... so a $PREFIX variable could apply to non-kde apps, and *my* kde-svn builds, whereas you would need a separate PREFIX and KDEDIR (ie; my PREFIX and KDEDIR would be the same, yours is different, *BSD users may want /usr/local for both, etc).

I'm not trying to be difficult, just suggesting how to generalize just this global config part. How to deal with where the source packages go is another issue.

BTW, one option that could cover a lot of issues is to simply append [ -f /etc/makepkg-local.conf ] && source /etc/makepkg-local.conf to /etc/makepkg.conf and then we could put whatever we care to as global Bash shell variables AND Bash shell functions() in makepkg-local.conf and then those additions would be available inside PKGBUILDs as well as to any independent bash build script that cared to source just /etc/makepkg-local.conf.

Last edited by markc (2008-06-06 17:18:54)

Cimi · 2008-06-06 17:54:19

markc wrote:

@Cimi: good link, thanks. My first impression is that patching KDE to have it's own kde-applications.menu would kind of defeat the purpose of a generic etc/xdg/menus for all desktop/window-managers. As long as the kde-svn kdelibs does not overwrite your current applications.menu then that seems (moreso) the right thing to do (to me) and NoUpgrade should do that.
I think a question would be, are you happy with the GNOME (I assume) provided applications.menu as it appears within your install of these kde svn packages when you log into the kde desktop (but using the GNOME provided applications.menu)? (I don't use GNOME so I have no idea.) If so, then the official ArchLinux NoUpgrade option is the best way to go. If not, and you feel there really is no combined GNOME/KDE menu option possible then patching KDE to have it's own menu set is then preferred. I'd rather not patch kde svn unless it's really essential. Are you happy with the GNOME provided applications.menu when you run KDE4?
Patching a stable KDE install makes sense but any possible patches to KDE4 svn is really best applied to the official upstream subversion repo rather than (for example) my binary packages... simply because subversion based packages are likely to change so often at the whim of the upstream developers, which is out of control and possibly out of sync with any patches that I might apply. As opposed to a stable set of release packages that will not change, and therefor any local or specific distro packaging patches will stick around for the long term.

I would like to see this patch applied for 2 reasons:
1) fidelity with the official kdelibs (also, if tobias is patching kdelibs then it should be a reason for this)
2) It seems better to have a different menu for every DE, also I find the applications.menu provided by gnome better suited, it is also translated and works for kde too since it's not providing GNOME-custom directories

I will ask JGC about why gnome is not using gnome-applications.menu

ozar · 2008-06-09 16:20:07

Cimi wrote:

i686 (@testing @unstable):
kstartupconfig4
kdostartupconfig4: symbol lookup error: /usr/lib/libkdecore.so.5: undefined symbol: _Z7qstrcmpRK10QByteArrayS1_
This is a fresh install from your packages, I haven't got any kde packages before (I'm a gnome developer )

Oops... I just did a fresh install with the current packages and got the same error.

I've deleted the entire install, but will try again later today and will reinstall qt-copy to see if that works the way it apparently did for Cimi (according to his followup post).

anykey · 2008-06-09 16:27:36

after running those packages for what, two months now, I have finally switched back to kde 3.5.9 from the kdemod project.

My opinion so far: great work markc and tanis, and thanks for showing me a glimpse of kde4. But till the kde-devs get their act together, I am put off by too many breakages for now...

Just wanted to thank you and spray some blame on the kde project in general. It is next to impossible to file bugs to kde4 because you never even know *why* something crashed (you mostly have a hard time to figure out *what* exactly crashed).

markc · 2008-06-09 16:47:21

@ozar: that's really odd. I did a fresh 32bit install 48 hours ago and didn't get that error. strings /usr/lib/libkdecore.so.5.1.0 | grep Z7qstrcmpRK10QByteArrayS1 returns the right string so it's definitely there in 20080610.

@anykey: you did well to last all of 2 months! I agree that the final polish is still lacking and stability progress seems to have slowed down even though there is a freeze. At this rate it will be 4.2 at the end of this year before kde4 will start to take over where 3.5.9 left off. I dual boot into Kubuntu 3.5.9 occasionally and it sure is nice to use something that works reliably, and feels solid. Glad you enjoyed the ride for a while.

I'm away for a week so any devel from me has to be put on the back burner. Hopefully my build computer will behave itself and keep uploading the daily builds all by itself.

ozar · 2008-06-09 17:19:16

markc wrote:

@ozar: that's really odd. I did a fresh 32bit install 48 hours ago and didn't get that error. strings /usr/lib/libkdecore.so.5.1.0 | grep Z7qstrcmpRK10QByteArrayS1 returns the right string so it's definitely there in 20080610.

Hi, Mark!

I really didn't pay close attention to what packages were being installed, but I think Qt 4.3.4 from extra was installed. Is that what should have been installed?

Edit: Oh, and I installed only selected packages rather than use pacman -S kde-svn (or kde-svn-all), so maybe that made the difference.

Last edited by ozar (2008-06-09 17:36:29)

tanis · 2008-06-09 18:09:15

@ozar: Do this:
$ pacman -Q qt
$ pacman -Q qt-copy

It will tell you if you have Qt or Qt-Copy installed. If it is Qt 4.3.4, it is bad. You should be using qt-copy, although Qt 4.4 from [testing] would work properly too. 4.3 is wrong and it won't work for sure.

ozar · 2008-06-09 19:41:33

I did another fresh install and this time saw that it was indeed trying to install Qt straight out of the 'extra' repo as a dependency, apparently because I installed only selected packages rather than the group. I said no to that and installed qt-copy first, then went on with my selected packages and kde4 started up just fine.

Now that I'm up and running I've gotta to tell you, the latest snapshots seem to be more buggy than ever.

dpc · 2008-06-11 17:41:50

Belitsky.A wrote:

2yuanjiayj: exiv2 from testing don't work with gvenwiev so use exiv2 from dev repo, add to /etc/pacman.conf this ([dev] must be before [extra]):
[dev]
Server = http://pkg.markconstable.com/dev/$CARCH/
and then in terminal run
sudo pacman -Sy exiv2

error: failed retrieving file 'dev.db.tar.gz' from pkg.markconstable.com : Not Found
error: failed to synchronize dev: Not Found

dpc · 2008-06-11 17:49:46

How can I make all files and directories to be handled by konqueror (which rules) and not by the dolphin (which sucks ).

Belitsky.A · 2008-06-11 18:04:46

dpc wrote:

Belitsky.A wrote:
2yuanjiayj: exiv2 from testing don't work with gvenwiev so use exiv2 from dev repo, add to /etc/pacman.conf this ([dev] must be before [extra]):
[dev]
Server = http://pkg.markconstable.com/dev/$CARCH/
and then in terminal run
sudo pacman -Sy exiv2
error: failed retrieving file 'dev.db.tar.gz' from pkg.markconstable.com : Not Found
error: failed to synchronize dev: Not Found

Replace $CARCH with your processor architecture ($CARCH is either i686 or x86_64)

Last edited by Belitsky.A (2008-06-11 18:14:08)

markc · 2008-06-12 06:42:25

@dpc: System Settings -> Advanced -> File Associations -> Inode -> directory and add and/or move Konqueror to the top of the "Application Preference Order" list. I've gradually grown to prefer Dolphin now, but then I still use Konsole for most file system manipulation except for when plugging in USB storage devices, then a gui file manager really helps.

@Belitsky.A: thanks, I will rewrite the first first post to be more helpful when I get back home in a week or so.

clinx · 2008-06-14 15:19:14

Hey Guys,

Is it correct, that the icon theme is a mix of Crystal and Oxygen?

Last edited by clinx (2008-06-14 19:29:30)

lee_connell · 2008-06-15 13:40:04

Is there a changelog somewhere for 4.1 so I can track what is being committed each day before updating to lastest build?

clinx · 2008-06-16 05:00:08

@lee_connell: http://www.commit-digest.org/updates.rdf

Is it correct, that the icon theme is a mix of Crystal and Oxygen?

Rebuild the icon cache.

markc · 2008-06-17 12:49:54

Well it looks like we'll have a KDE3 file/folder desktop facsimile within KDE4 after all. I'm excited about plasma and what it will have to offer but I really miss the old KDE3 desktop system. It was so simple to dump files there and use it as a staging area to deal with files in general, and as old-school as it may be, it is an intuitive interface for newbies and oldies alike. Aaron Seigo has posted a video showing how the folderview plasmoid can be made into a background desktop where it behaves (almost, more work needs to be done) just like the old KDE3 desktop, but only way better because it's just one component of the plasma desktop. At the moment it doesn't persistently save the file/folder icon positions so it's not really usable yet but apparently that will come in time for the 4.1 release (maybe another week for us, by the heat surrounding the issue). It also does not have a background color/image or any way to configure this kind of interaction until maybe 4.2 (again, probably sometime in August for us). If you haven't seen it yet then the video is really worth watching...

http://plasma.kde.org/media/folderview_containment.ogg

and here is a related posting with a little more info and another video...

http://osnews.com/story/19866/FolderVie … ntegration

If you want to try it out then drop out of plasma (easy if you use startx) and edit ~/.kde/share/config/plasma-appletsrc and look for the plugin=desktop line in the first [Containments][1] stanza and change it to plugin=folderview, or for kicks clock, or any plasmoid, and it will become the desktop background. You can glean plasmoid labels by listing /usr/lib/kde4/plasma_applet_*. And just for that kick, here's a screenshot of the analog clock as the desktop background...

http://markconstable.com/markc_desktop_20080616.jpg

Last edited by markc (2008-06-17 13:04:14)

lee_connell · 2008-06-17 20:52:53

@Clinx: thank you!, however it looks like it's only updated every 7 days, maybe its a recap of the last seven days, what's been done? how about a daily changelog?

Also glad they're giving the ability for people who want it, to add desktop items as they did with KDE3. Very good idea.

Last edited by lee_connell (2008-06-17 20:57:03)

markc · 2008-06-18 04:57:57

@lee_connell: http://cia.vc/stats/project/kde maybe the best interface and it's RSS feed of http://cia.vc/stats/project/kde/.rss, otherwise the best is to use the commit filter but it's not very friendly, http://commitfilter.kde.org/.

FWIW, I've got a x86_64 firefox 3 build working (using it now) so it'll most likely be included, plus i686, in 20080619 (or the next day) from the [gui] section. This is a good read http://www.ibm.com/developerworks/libra … 04wa-ffox3

Update: the firefox packages are up, it's called firefox (not firefox3) so consider removing your current firefox (2) first. It lives in /usr/lib/firefox-3.0 (not /opt/mozilla) so except for the package name it would almost live along side firefox (2). Just comment out any [gui] section in /etc/pacman.conf if this could be a problem or you are unsure about this firefox3 package overriding any current firefox. I know this forum is about KDE4 but FF with Firebug can't be replaced at this stage, and of course, there is all the buzz about FF today. The Firebug extension for FF3 is at http://getfirebug.com/releases/ (v1.1beta). I also removed a few lines from chrome/res/forms.css which makes it look a bit better under KDE4 and I ripped a "normal looking" set of icons from Kubuntu. This is a first time package build so there may a few minor glitches so if anyone has any suggestions or wants to rebuild it then it's...

cd /some/where
svn co http://code.google.com/p/eth-os/source/browse/trunk/gui/firefox
cd firefox
wget http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.0/source/firefox-3.0-source.tar.bz2
makepkg -csi

Last edited by markc (2008-06-18 14:09:20)

Arch Linux

#276 2008-06-06 14:10:57

Re: Daily KDE4 Subversion Packages

#277 2008-06-06 14:57:06

Re: Daily KDE4 Subversion Packages

#278 2008-06-06 15:05:21

Re: Daily KDE4 Subversion Packages

#279 2008-06-06 15:18:46

Re: Daily KDE4 Subversion Packages

#280 2008-06-06 15:35:10

Re: Daily KDE4 Subversion Packages

#281 2008-06-06 16:05:15

Re: Daily KDE4 Subversion Packages

#282 2008-06-06 16:07:26

Re: Daily KDE4 Subversion Packages

#283 2008-06-06 17:03:17

Re: Daily KDE4 Subversion Packages

#284 2008-06-06 17:54:19

Re: Daily KDE4 Subversion Packages

#285 2008-06-09 16:20:07

Re: Daily KDE4 Subversion Packages

#286 2008-06-09 16:27:36

Re: Daily KDE4 Subversion Packages

#287 2008-06-09 16:47:21

Re: Daily KDE4 Subversion Packages

#288 2008-06-09 17:19:16

Re: Daily KDE4 Subversion Packages

#289 2008-06-09 18:09:15

Re: Daily KDE4 Subversion Packages

#290 2008-06-09 19:41:33

Re: Daily KDE4 Subversion Packages

#291 2008-06-11 17:41:50

Re: Daily KDE4 Subversion Packages

#292 2008-06-11 17:49:46

Re: Daily KDE4 Subversion Packages

#293 2008-06-11 18:04:46

Re: Daily KDE4 Subversion Packages

#294 2008-06-12 06:42:25

Re: Daily KDE4 Subversion Packages

#295 2008-06-14 15:19:14

Re: Daily KDE4 Subversion Packages

#296 2008-06-15 13:40:04

Re: Daily KDE4 Subversion Packages

#297 2008-06-16 05:00:08

Re: Daily KDE4 Subversion Packages

#298 2008-06-17 12:49:54

Re: Daily KDE4 Subversion Packages

#299 2008-06-17 20:52:53

Re: Daily KDE4 Subversion Packages

#300 2008-06-18 04:57:57

Re: Daily KDE4 Subversion Packages

Board footer