Usually, whenever a new KDE release is published, Gentoo users can update already the same day, as suddenly a complete and polished set of ebuilds appears in the portage tree. (Stay tuned on upcoming wednesday for KDE 4.8.0, it's shaping up very nicely!) How is this possible? Well... let me explain.
If you're a stable version user, you may have never heard of so-called live ebuilds. This is a special variant, usually denoted by a version number ending in 9999, that does not rely on a source tarball. Instead, it contains a URL of a revsion control system (say on anongit.kde.org). When you emerge such a version of a package, the sources of the specified branch are checked out or updated to the newest upstream state, and that is used for building the installation package. Obviously this is not for everyone; depending how well upstream structures commits, things may not build for a while, contain fresh bugs, ... Also, reporting bugs from live versions on Gentoo bugzilla is discouraged as most of the times we can't do anything about it (do it only if you are sure it's a problem with the ebuilds, not with the source). If you're running live, you should be willing to hack yourself and work with upstream.
However, many of the Gentoo KDE team members run these live ebuilds, partly the current bugfix branch (i.e. KDE/4.8), partly even git master. They continuously keep the live ebuilds in the Gentoo KDE overlay updated to the newest state of the source. When a release is made, the corresponding live ebuilds of this branch are copied to the version ebuilds. For example, the KDE/4.8 branch live ebuilds have the version number 4.8.49.9999 (i.e.
kde-base/kdelibs-4.8.49.9999), so when the pre-release tarballs for KDE 4.8.0 were released to the packagers a few days ago, we only had to copy all 4.8.49.9999 ebuilds to 4.8.0 and immediately had a working set for testing. Most problems at that point are only caused by changes in tarball packaging. As distribution packagers get the pre-release tarballs (that still may change due to last-minute bugfixes) a week before the official release date, these can easily be fixed in time.
This also means that KDE maintenance in Gentoo is really a team effort. Whoever moves a released version to the main portage tree and/or commits bugfixes there builds on all the work that the team has done in the overlay in the meantime. Cheers!
Sunday, January 22, 2012
Sunday, January 15, 2012
Calling for brave testers: net-print/cups-1.5.0-r2
Maybe some of you have noticed that CUPS 1.5.0 is still hard-masked. Well, the reason for that is simple- at home, I'm nearly not printing at all, and at work, I have to rely on printing too much to tinker with it on the side a bit. So... if you would like to help, please unmask net-print/cups-1.5.0-r2 and give it a try. You will for sure find some problems, as the only thing I tested looong time ago was building it, never actually running it. Report them on bugs.gentoo.org, and we'll have a look... with a bit of luck, the package mask can then go away at some point. Any feedback (also positive) is appreciated. Cheers!
Tuesday, January 10, 2012
My personal KDEPIM upgrade status
Some time ago when we were filing the first stable request for KDE 4.7 I decided I'd have to give KDEPIM-4.7 also a try. I used to be a pine (and later alpine) user for ages, some time ago I switched to kmail1 (maybe at version 4.2 or so) and have been using it ever since... About the setup, incoming mail is stored and filtered server-side (Novell Groupwise), and accessed as disconnected IMAP.
1) Office desktop.
This one's usually running the latest and greatest KDE RC or beta, with a static IP and something like a 100MBps-FD link to the mail server. No local folders, so this was the natural candidate to test first. I did not even try the data migration, but wiped my entire local configuration of the KDEPIM programs as thoroughly as possible before updating. On the whole this went rather well. From 4.7.3 to 4.7.95 I've seen my share of kmail2 / kontact / akonadi crashes, but none of them really led to bigger problems. Impressively, I could also see each of these crash bugs I hit get fixed on KDE bugzilla in the meantime! Since upgrading to 4.7.97 I haven't had a crash anymore.
The only thing that is really bugging me a the moment is that I absolutely can't drag an e-mail message into another folder (I always have to right-click on the entry in the message list, select "Move to folder", ...). However, that is likely a problem in one of the underlying libraries. :| I would really like to help debugging this problem; if you can give me any clue where to look, please message...
2) Laptop.
Going home for christmas meant spending some time on a train. The days before I had upgraded this box to QT-4.8.0 and KDE+KDEPIM 4.7.95. Again, clean start with a new configuration. On the train I spent some time ironing out bugs there. The GPRS connection was happily going down and up again with every tunnel or less-populated countryside. That's when the akonadi backend started really acting up. When I arrived at my family's place, my e-mail had become fully non-functional (no fetching e-mails, no sending e-mails, the backend making kmail hang, regular crashes, and all fumbling with akonadiconsole did not help). After a while of trying, I gave up, wiped my entire KDEPIM configuration and data and downgraded to 4.4 again. I was impressed how responsive my e-mail program suddenly became.
Talking to other people, it seems that some have problems with bad internet connections, some don't. Maybe I should have used networkmanager, at least Alexxy reports that it's working fine with it.
3) Home desktop.
Well... Here I store my e-mail archive since 1996- that's maildir folders with roughly 50000 messages. Maybe I'll consider upgrading KDEPIM sometime around KDE 4.9.
I'm sorry if this blog entry is demotivating for the program developers. Some time ago I followed part of an animated discussion on irc between a kdepim user and a kdepim developer. Quoting a small part,
1) Office desktop.
This one's usually running the latest and greatest KDE RC or beta, with a static IP and something like a 100MBps-FD link to the mail server. No local folders, so this was the natural candidate to test first. I did not even try the data migration, but wiped my entire local configuration of the KDEPIM programs as thoroughly as possible before updating. On the whole this went rather well. From 4.7.3 to 4.7.95 I've seen my share of kmail2 / kontact / akonadi crashes, but none of them really led to bigger problems. Impressively, I could also see each of these crash bugs I hit get fixed on KDE bugzilla in the meantime! Since upgrading to 4.7.97 I haven't had a crash anymore.
The only thing that is really bugging me a the moment is that I absolutely can't drag an e-mail message into another folder (I always have to right-click on the entry in the message list, select "Move to folder", ...). However, that is likely a problem in one of the underlying libraries. :| I would really like to help debugging this problem; if you can give me any clue where to look, please message...
2) Laptop.
Going home for christmas meant spending some time on a train. The days before I had upgraded this box to QT-4.8.0 and KDE+KDEPIM 4.7.95. Again, clean start with a new configuration. On the train I spent some time ironing out bugs there. The GPRS connection was happily going down and up again with every tunnel or less-populated countryside. That's when the akonadi backend started really acting up. When I arrived at my family's place, my e-mail had become fully non-functional (no fetching e-mails, no sending e-mails, the backend making kmail hang, regular crashes, and all fumbling with akonadiconsole did not help). After a while of trying, I gave up, wiped my entire KDEPIM configuration and data and downgraded to 4.4 again. I was impressed how responsive my e-mail program suddenly became.
Talking to other people, it seems that some have problems with bad internet connections, some don't. Maybe I should have used networkmanager, at least Alexxy reports that it's working fine with it.
3) Home desktop.
Well... Here I store my e-mail archive since 1996- that's maildir folders with roughly 50000 messages. Maybe I'll consider upgrading KDEPIM sometime around KDE 4.9.
I'm sorry if this blog entry is demotivating for the program developers. Some time ago I followed part of an animated discussion on irc between a kdepim user and a kdepim developer. Quoting a small part,
<user> first: fix bugs. second:dont change data formats. third: change gui only if absolutly nessary.While this is of course oversimplifying, both points have clear validity, the first because people have come to rely on the software, the second because it's volunteer work by people enthusiastic about their creation. In the end we'll have to find a good compromise.
<developer> no
<developer> first: have fun; second: make it work for others
Saturday, December 17, 2011
kdepimlibs-4.7.3 imap4 regression fix
Attention Gentoo users: If you're running kmail-4.4.11.1 and kde-4.7.3, and if you have been hit by bug 382411 (problems with local filters, cannot upload unread message on imap; see also here and here), please keyword kde-base/kdepimlibs-4.7.3-r1 and give it a try. (You may want to log out and log back in.) This upgrade seems to fix the problem... If I get some positive feedback, I'll fast-track it for stabilization. Cheers!
Friday, December 9, 2011
Unit tests - a useful thing causing occasional pain
For whoever has never heard that expression, unit tests are a way to test the functionality of a program or library in an automated way, by for example checking the evaluation result of test data. This is a great thing and can help massively in identifying coding mistakes. CMake provides a mechanism, and in many KDE packages test routines are included.
So far, so good, this is the theory, now let's look at reality. In Gentoo, the main KDE distribution is split into 295 (!) packages. Many dont have any tests (oxygen-icons comes to my mind as a nice example). Of those that have, 37 now have all the test routines hard disabled, and I guess a few are missing that I still have to add to the list. Why? Well, first of all, you have to know that compilation usually runs in Gentoo as an unprivileged user detached from any graphical desktop session, and this user also runs the test routines. In addition, tests should also run fine "offline", i.e. without internet connection. One of our developers is running a great thing called a "tinderbox", where build and unit tests in various configurations are automated- in an isolated environment, and possibly even without network access. So, what can go wrong?
PS. This blog post took slightly longer to write since a libreoffice-3.5 build in the background went berserk... load 65, >180 concurrent compilers... :D
So far, so good, this is the theory, now let's look at reality. In Gentoo, the main KDE distribution is split into 295 (!) packages. Many dont have any tests (oxygen-icons comes to my mind as a nice example). Of those that have, 37 now have all the test routines hard disabled, and I guess a few are missing that I still have to add to the list. Why? Well, first of all, you have to know that compilation usually runs in Gentoo as an unprivileged user detached from any graphical desktop session, and this user also runs the test routines. In addition, tests should also run fine "offline", i.e. without internet connection. One of our developers is running a great thing called a "tinderbox", where build and unit tests in various configurations are automated- in an isolated environment, and possibly even without network access. So, what can go wrong?
- The tests need X11. Well, actually we can get around this, with a nice hack called virtualx. A background framebuffer X server is started for the test phase only, and the tests are redirected to that display. Works even sometimes. :o)
- The tests need a dbus session bus. I think we could get around this too, but nobody bothered to do it so far and I'm not a dbus expert.
- The tests need an entire KDE desktop to interact with. Yes, that happens, and unfortunately, we have to disable them in this case, see above.
- The tests try to download a data set from, say, IMDB, CDDB, or similar. Bad, bad, bad, see above.
- Next, the tests pop up dialog boxes asking for user interaction. A window asking for a GnuPG passphrase is my personal favourite...
- And last, what I particularly like is a unit test that fails... and after digging into the test log, I see a fat comment "This does not work yet and needs to be fixed!"
PS. This blog post took slightly longer to write since a libreoffice-3.5 build in the background went berserk... load 65, >180 concurrent compilers... :D
Wednesday, December 7, 2011
Gentoo KDE 4.7.3 going stable now... including KDEPIM
Another KDE version stabilized in Gentoo... x86 is done with KDE 4.7.3 since this morning, amd64 is following right now. For those of you who don't read Portage news items, here's again my message about KDEPIM:
With the new KDE we have finally also been able to stabilize a newer version of digikam and kipi-plugins (both at 2.3.0 now!), and also rekonq gets a big bump to version 0.8.0, which should fix an overdue security bug.
Finally and not related to the stabilization, since yesterday we have a package in the main tree that provides integration of Google calendars / contacts into Akonadi: kde-misc/akonadi-google ... It's a bit experimental still and also not an official release but a packaged snapshot, but anyway, if you are interested, give it a try!
The stable upgrade from KDEPIM 4.4.11.1 to KDEPIM 4.7.3 is a MAJOR upgrade with potential for major breakage. Therefore we will try to keep and support the old, so-far stable KDEPIM 4.4.11.1 as long as possible.In addition there have been a few reports of problems with the Plasma desktop after upgrade. Usually these are caused by single plasmoids malfunctioning, so what should help is to remove some of the plasmoids from your desktop and add them again... Otherwise the upgrade from 4.6 to 4.7 should be pretty much unproblematic, and bring you a shiny new desktop with quite some new features.
If you don't want to upgrade your KDEPIM yet but keep the old version, please download this mask file and add it into your /etc/portage/package.mask.
If you decide to upgrade, please have a look at the upgrade guide first.
With the new KDE we have finally also been able to stabilize a newer version of digikam and kipi-plugins (both at 2.3.0 now!), and also rekonq gets a big bump to version 0.8.0, which should fix an overdue security bug.
Finally and not related to the stabilization, since yesterday we have a package in the main tree that provides integration of Google calendars / contacts into Akonadi: kde-misc/akonadi-google ... It's a bit experimental still and also not an official release but a packaged snapshot, but anyway, if you are interested, give it a try!
Monday, November 14, 2011
The Regensburg nanotube team is growing!
A lot of things have happened recently in our nanotube / nanomechanics research group in Regensburg... First of all, I'd like to congratulate Peter Stiller for finishing off his Diploma thesis and thereby his degree. Peter is immediately continuing as a PhD student, however switching topic from nanomechanics to charge qubits in carbon nanotubes - a newly founded project in the SFB 631. Here we plan to couple electronic quantum states in carbon nanotube double quantum dots to the electric field of a coplanar microwave resonator.
Then, straight from München and the research group of Jan von Delft, Alois Dirnaichner will join us soon as PhD student to work on experimental and theoretical characterization of few-electron states in ultraclean suspended carbon nanotubes. This is a project pursued together with the groups of Milena Grifoni and Christoph Strunk; we hope that the high quality of our carbon nanotubes enables us to do fundamental observations and analysis on unperturbed electronic multi-particle states.
Next, Sabine Kugler joins the nanomechanics team for her MSc thesis project. She will continue the development of chip geometries and materials suitable for combining carbon nanotubes with complex electronics, and help us with the characterization measurements.
Finally, last but not least, Hermann Kraus starts in december as a Diploma student, and will focus on high-frequency electronics at very low temperatures and superconducting nanocircuitry. Time to get these electrons rock'n'roll!
Then, straight from München and the research group of Jan von Delft, Alois Dirnaichner will join us soon as PhD student to work on experimental and theoretical characterization of few-electron states in ultraclean suspended carbon nanotubes. This is a project pursued together with the groups of Milena Grifoni and Christoph Strunk; we hope that the high quality of our carbon nanotubes enables us to do fundamental observations and analysis on unperturbed electronic multi-particle states.
Next, Sabine Kugler joins the nanomechanics team for her MSc thesis project. She will continue the development of chip geometries and materials suitable for combining carbon nanotubes with complex electronics, and help us with the characterization measurements.
Finally, last but not least, Hermann Kraus starts in december as a Diploma student, and will focus on high-frequency electronics at very low temperatures and superconducting nanocircuitry. Time to get these electrons rock'n'roll!
Subscribe to:
Posts (Atom)