We are now on the home stretch of the road to KDE 4.0, but KDE still needs extensive user testing to make sure everything arrives in the best possible shape for the release. There is a pressing need for users to be able to get hold of very up-to-date builds of KDE, especially if they want to participate in Krush days and pick up last-minute regressions, confirm proposed fixes, and avoid re-reporting recently fixed bugs, preferably without having to wait for their chosen distro to provide packages. KDE4Daily VM aims to provide such a service.
KDE4Daily is an experimental attempt at accomplishing the above goals using the Qemu virtualisation technology. End-users download the initial KDE4Daily 0.0.1 image (containing the now somewhat dated revision 734472), run it in Qemu and use the built-in installer scripts to upgrade the KDE 4 install to the latest revision provided, so that they can always test-out bleeding edge revisions pulled straight from Subversion. Upgrades are intended to use up relatively little bandwidth (20-50MB for a day's worth of updates is typical; bridge updates which condense a week's worth into one package bring this down to an average of 10MB or so) and be quick to apply (5 minutes per update is common, although bridge updates can take 10-15 minutes).
Because Qemu is distro-agnostic, you do not need to worry about distros or libraries or dependencies or suchlike; in fact, you can even test out KDE 4 while running Windows! The downside is that eye-candy such as KWin's new Composite-based effects will not be testable as Qemu does not support hardware graphics acceleration, and everything will generally feel a lot more sluggish than is the case with a native install.
An extensive FAQ is provided at the KDE4Daily homepage, above; please feel free to ask any further questions in the Dot comments section. Also, note that KDE4Daily has not yet had any real testers apart from myself, so please be prepared for "teething trouble" such as botched upgrades and bandwidth issues! Enjoy, and remember that the more people test, the better KDE 4.0 will be. As an added incentive for trying it out, you can try out the rapidly-developing Plasma as it progresses too!
Comments
Will probably try this out soon. When using the binary releases of Kubuntu, I'm often not sure if a particular bug has already been fixed or not. This will give me more reason to file bugs;-)
Keep up the good work
regards Simon
Hi all,
A bridge update to r739427 (~2 days old) is currently available; this is a 70MB download that takes (on my machine) about 10 minutes to apply. An update to r740406 is prepared (which I *think* contains Konqueror's new "Undo Close Tab" feature, courtesy of Eduardo Robles Elvira and David Faure!), but not yet uploaded. I'm going to wait around for some successful upgrade reports before making that available, and then hopefully settle into a rhythm of an update every day, depending on whether all targetted modules happen to be compilable at the time.
A few known issues:
- Sometimes logging into your new KDE4Daily session will crash the first time after an upgrade. Please re-try as it almost invariably works the second time.
- KSnapshot does not appear to function inside of Qemu, so if you want to take snapshots, please use the version of KSnapshot in your host machine.
- Krita does not start due to a missing dependency; from the command-line, within your KDE4Daily VM session please enter:
sudo apt-get install libglew1
and enter the password ("kde4daily")
- Processing of backtraces is very slow, especially the first time; please don't let this put you off submitting valuable backtraces!
Above all else, please download, help seed, play, test and have fun!
Ok, second post, then. *Grumbles*
Oh, and I'd like to thank aseigo, jos, riddell and annma for their support in getting this mini-project (and my very first contribution to KDE!) off the ground :)
Minimum recommended hardware?
There's some info on this on in the "What do I need?" section of the homepage, but processor-wise I run it on my Pentium M 1.73GHz OK. RAM is the bottleneck - I'd recommend at least 512MB. If you are going to be submitting backtraces, I'd recommend much more - 1GB, say.
Just to state the almost very obvious;
the above specs are NOT general KDE minimum requirements :)
1 GB isn't much these days, I hope "everybody" have that.
If not, a good reason upgrade!
I promise I will seed these torrents 24/7 until KDE 4.2 is out.
I've *never* had more than 768mb.
:(
http://digg.com/software/Test_Latest_Builds_with_KDE4Daily_and_be_part_o...
Great work guys! Now I will have something to play with over the weekend. ;-)
On my desktop I'm used to VirtualBox. Is there any possibility to convert qemu into VirtualBox Files? Or will the qemu File work "out-of-the-box"?
Hi there,
Thanks for the kind words!
I've actually tried this myself, and it "worked" in that it created a bootable and runnable VirtualBox image. However, I could not get internet access from within the VM in VirtualBox, and I'm not sure whether this is due to the image needing to be re-configured or whether VirtualBox needs some magic in order to allow the image to connect to the internet.
Anyway, uncompress the .bz from the torrent, install Qemu if not already installed, and try:
qemu-img convert kde4daily-0_0_1_r734472-qcow.img -O vmdk kde4daily-0_0_1_r734472-virtualbox.vmdk
This should give you an image that will work with VirtualBox, possibly without (essential :/) internet capability.
Please give it a try and report your findings :)
Actually, there is a better and cleaner way to transform a qemu image to a virtualbox image:
http://liquidat.wordpress.com/2007/11/23/howto-transform-a-qemu-image-to...
At the end of the text you also find a note about the network problem and how to fix it.
But the VirtualMachine is really a great thing, thx!
Liquidat has just blogged on precisely this topic - check it out!
http://liquidat.wordpress.com/2007/11/23/howto-transform-a-qemu-image-to...
Hi SSJ!
Yes it worked for me too! I converted the image with your command described above and just made a "ifup eth0" and "dhclient" as root in the KDE4 session under VirtualBox without any problems.
Thanks for this great piece of Software. You rock! :-)
... needs more, umm, beta testers. ;-)
This is a brilliant idea. And you can always use kvm ( http://kvm.qumranet.com/ ) to speed things up!
It would be cool if kde4 could be rolled up into a klick bundle that could then be run in a Xephyr window. This would cut the overhead of the emulation and give people a better idea as to the performance of the environment. Is this even possible? I remember a coulple of years ago, one of the nifty klick bundles was a standalone E17 desktop that would load up in Xnest.
I don't have any experience with Klik, but the same KDE4 install that I provide (i.e. the contents of /storage/tmp/kde4dev) can be used with Xephyr (I've tried it).
If Klik could provide all the required dependencies, then I suspect such a thing should be possible :)
Well its more like you'd have to provide all the dependencies to Klik. You could set it up to automatically build everyday. And then setup a script to run the app within Xephyr.
Sounds like a lot of work and bandwidth though. :)
Xephyr supports Composite, no? Do Kwin's effects work in Xephyr?
AFAIK, only very recent snapshots of Xephyr support composite, unlikely it's already widely available in distros.
Good idea, but why not make it a standard distro that you can install on your hard drive?
Really, for convenience - most people probably don't want to install a whole new distro just to check out the latest KDE4 (or maybe they do - what do people here think?).
If anyone wants to step up and take a shot at doing this, please be my guest - there's not much different from a standard Kubuntu 7.04 server install + KDM3 - the list of installed packages can be found by
dpkg --list
the KDE4 install itself is wholly contained in
/storage/tmp/kde4dev
and the scripts in
~/kde4dailyupdater
the paths etc are set in the .bashrc/ .bash_profile. The KDE4 .desktop file is a clumsy hack of an old one and can be found in /usr/share/xsessions. That's probably the full list of all real differences.
Another thought that occurred to me is that it might be possible (if you have a big stack of CDs that you want to use up ;)) to use the image to generate your own up-to-date LiveCD everyday, for playing with "natively", as it were. I have no idea how this could be accomplished, however, but suspect that it is possible in theory if anyone has a burning desire to give it a shot :)
And if the network isn't automatically configured for you, try the tip mentionned here:
http://liquidat.wordpress.com/2007/11/23/howto-transform-a-qemu-image-to...
The 2 following lines got me a working network from the vmdk image:
sudo ifconfig eth1 up
sudo dhclient eth1
openSUSE is doing this already for some months:
http://en.opensuse.org/KDE4
unless i have missed something, they do not - they provide kde4 packages for opensuse and livecd (which is popular and very good), but this entry is about qemu virtual image.
it is possible that the live cd could be booted in a virtual environment, but i´m not sure whether it supports the same way of updating this virtual image does.
You can install openSUSE into qemu.
"The KDE:KDE4 build service project offers SVN trunk snapshots updated usually weekly."
Weekly being the key word there...
Quote: "The KDE4Daily project was created to help people try out and test KDE4 without having to log out to boot from a LiveCD."
A LiveCD can be run in a virtualizer so I see no advantage of providing a virtualizer specific image file.
The whole point is updating. LiveCD's do have creative ways to allow themselves to be upgraded, but Qemu seems like a much more straightforward solution.
Install from a live-cd to a virtual harddrive, works fine.
Heh, or just download the virtual hard drive. Which is what this project is!
To quiet users' headache, please, follow this advice
1) Distribute VM images compressed with 7z with at least 64MB (I suggest 96 or 128MB dictionary - but it requires a 64bit version of Linux) dictionary using Ultra compression mode
2) Provide end users with xdelta binary diffs between daily releases.
3) Remove all unnecessary stuff from the image. I cannot believe KDE4 image takes so much space (I can compress my Fedora 8 with entire KDE3.5.8 to 500MB image)
Thanks for the advice, but the torrent is already active and it would be a huge pain to re-compress and re-upload :( If I do a "refresh" image down the line, I'll be sure to take your suggestion into account!
The image also contains KDM3 (I want the user to always be able to see a graphical login, even if the KDE4 install is broken), so this and its dependencies probably add a little to the bloat.
Ok, looking at my logs, it seems that a few people have dared the upgrade procedure and, since no one has appeared here to berate me, I assume they went absolutely, 100% perfectly ;)
So I'll make the latest prepared revision available, and get a new one building while I go to bed. Enjoy!
I have downloaded the file via torrent 2 times now, but unpacking with ark keeps failing with an error. Is the file brocken? Does anyone else have the same problem?
Try using bunzip2 from the command-line. Quite a few people seem to be using it successfully, so it should be fine. The MD5 of the compressed file should be 3ea6287f5052d26645e83ea91e1555b3. Hope this helps!
Thanks that worked. Seems like I have to report a bug against ark
Username and Password for login, anyone?
found the problem: The keybord layout was the problem.
why not just use opensuse. Their kde 4 repository is updated daily, so people can test and report bugs better with the full install
Basically, because I was completely unaware of this service :)
because it probably wouldn´t work that well for people using other distributions or even - windows ;)
You can install SuSE without problems, in a virtualized enviroment (VirtualBox for example).
Where can you get daily builds for OpenSuse from?
I checked with their KDE 4 page,
http://en.opensuse.org/KDE4
there you only find this link to the build service KDE 4 directory:
http://download.opensuse.org/repositories/KDE:/KDE4/openSUSE_Factory/rep...
And the mentioned SVN version 738441 in the package number is a 6 days old KDE svn version:
http://websvn.kde.org/?pathrev=738441
If you install the first two ymp files (KDE4-BASIS.ymp and KDE4-DEFAULT.ymp) from the KDE4 directory that you mentioned then you will have a default KDE4 enviroment and you will be fine for future updates.
Yes, but that wasn't the point. The original statement was that there are daily updates for OpenSuse, and I can't find them.
If you install the files that I mentioned then you will get a daily update. I do an update ever single day. Just use the Yast Software installer and search for KDE4 you will see the file that can be updated shown in blue. Simple click on one with the right mouse button and update all in the list.
No, you don't get a daily update. The ymp-files only add
http://download.opensuse.org/repositories/KDE:/KDE4/
as a repository, which does not contain daily updates. Maybe weekly ones, but not daily ones. If you don't believe me, check the svn version of your installed KDE 4 files and compare it with the one from KDE SVN. The current KDE 4 packages in the OpenSuse repositories are for example of version 742646 which is already some days old.
Awesome work!
A suggestion: I notice that primary partition is about 1gb and I think that too tight. I installed kernel-headers for compiling Virtualbox's Guest Additions and i almost run out of space.Any chance for getting this bigger?
Btw, I've tested the update system and it works perfectly, great job :)
Bye.