Archive for the ‘KDE’ Category
They do already contain a fix for Bug 306260 – KWin freezes when navigating between windows.
For 12.2 KR49 now includes Tomahawk an alternative to Amarok. Packages such as digikam, calligra etc. were updated to their latest stable release.
UPnP support was disable for the KR49 packages since it causes lots of crashes (if Windows shares are present on the network) and seems unmaintained within KDE, i.e. no fix to look forward to.
Packaging-wise kudos go to Todd, Nico and everybody else doing the packaging in KR49. If you find any packages missing in KR49 compared to KR48 please submit them via the buildservice or drop a note on the opensuse-kde mailinglist.
KDE-wise I would like to thank especially Laurent Montel who contributes a lot to fixing-up kmail2, including adding email backup and import functionality. András Manţia is another developer who helps to get kmail2 into shape and re-worked the filtering for 4.9. (There are of course many more who contribute to KDE!) Since AFAIK both work for KDAB, it is good to see that there are still developers payed to work on KDE while most distros seem to overload their so called KDE-team with non-KDE stuff, resulting in little or no contribution to KDE and just enough time to get packaging done, if at all.
Things I noticed with KDE SC 4.9 so far
In dolphin one can now add extra information to the main view, i.e. next to each item. Actually a nice feature. The sad thing is that it only works for indexed folders. The user cannot know about this and is presented with lots of “-” below each icon instead of just not showing anything if there is nothing to show. Enabling the additional information will block dolphin’s GUI for some time proportional to the amount of items in the current folder. Indexing still has some issues, e.g. nepomuk re-indexes movie and some sound files after every log-in. On top of that instead of just checking the length etc. it reads the whole file, i.e. hundreds of MB just to start all over again after the next log-in.
The places pane presents some new items, i.e. you can add searches to it. While some default searches do not seem to be of any use, i.e. e.g. just list all audio files or pictures from all over the computer, the time-related queries can be quite useful if you are willing to invest the GB needed to build up an index for 70 000 files.
Regarding mail loss, the bugs were unfortunately not fixed yet for online IMAP. There are two issues. a) You lose email if you move it to a local folder and the internet connection breaks down while kmail2 is still downloading the message. b) You also lose email if you pipe the emails in your imap folders through external apps such as bogofilter. For the latter a workaround exists. If you open the properties of the imap folders and enable “always retrieve full message” you will not lose emails because of piping unless a) kicks in.
Apper seems to become more stable. While it still suffers from a – let’s say – incomplete zypper backend for PackageKit on openSUSE, it lets PackageKit processes die within reasonable time and does not block zypper forever anymore.
If you think that you cannot help packaging, you might want to re-consider, since with the open buildservice at build.opensuse.org you can already help packagers with just a few clicks in your browser and without the risk of breaking anything – not only for openSUSE but also for Fedora and other distros.
While creating a new package might be out of scope for most distro users, updating a package is often very easy. All you need is a browser.
To start the small series on how to work with the buildservice’s web front-end, let’s have a look at updating an existing package to a new version. Very often the procedure of updating a package consists of only three steps which can all be done within your browser:
- create a copy of the package to update
- upload a new tarball and change the version string within the package
- submit changes back to the package repo
Example: Updating a package
To make this easy to follow, I will give an example and break down the procedure into tiny steps.
Copying/Branching the package
- log into the open buildservice (you can register for free)
- click on All Projects
- click on the repo the package you want to update is part of, e.g. KDE:Extra
- click on Packages
- click on the package you want to update, e.g. luckybackup
- below the summary, click on Branch package (only available if you are logged-in) and on OK when asked if you really want to branch the package
You are now re-directed to the branched package within your home project. At the top of the website you can see the path to the package, e.g. openSUSE Build Service > Projects > home:username:branches:KDE:Extra > Packages > luckybackup. This shows that the buildservice created a sub-project branches:KDE:Extra within your home project. If you want to navigate there manually you can click on Home Project at the top-right of the website, then on Subprojects and finally on branches:KDE:Extra.
Below that path you have a bar with links which we will use within this example, e.g. Overview, Sources etc.
Within your home project you can alter the package without breaking anything in the original repo. If you messed-up, just remove the package/sub-project and re-try.
Updating the package
Packages are built from tarballs, i.e. archives of the app’s source code. To update the package you have to re-place the existing tarball and alter the version string of the package.
- click on the package within your home project
- click on Sources
You will see the list of files within the package.
- luckybackup.spec: The spec file contains the information on how to build the package. Except for changing the version string you will not have to worry about it in most cases.
- luckybackup.changes: This is a log of the changes applied to the package. You will have to add something like “- updated package to version x.y.z”.
- luckybackup-0.4.6.tar.gz: This is the tarball of the app’s source code. You can get it from the app’s website or create one yourself in case you are updating a git snapshot.
- xyz.patch: Patches that are applied to the source code before building. Most often you will not have to worry about those. Some hints about handling patches – in case it is necessary – will be part of one of the next posts.
Most files are represented as links. If you click on them you can edit them within your browser.
HINT: If you have trouble with the browser editor, e.g. line numbers not fitting the text or underscores not showing-up, change the fixed font to e.g. Droid Sans and increase its size.
While you might want to have a look at the details of the spec file, most often you just need to find the line:
and change it to e.g.
To save the changes click on the save icon at the top of the editor. If you have a look at the spec file it will most probably use that string to determine the file name of the tarball to use for building the package, e.g.:
This means that the tarball with the new version has to be named luckybackup-0.4.7.tar.gz. There are several ways to add a new tarball to a package, the easiest is to download the tarball to your computer and then upload it to the package on the buildservice.
- go to the sources list and remove the old tarball by clicking on the remove icon next to it
- click on add file below the list and select the file on your computer
- only in case it does not have the above mentioned name you will have to enter the correct file name into the input filed
- save changes
Now click on the luckybackup.changes file to add the changes you made to the package. To insert a new item just click on the Insert changes entry template link at the top of the editor.
Re-submitting the package
If you click on Overview or Monitor you can see the build status of the package. Clicking on the status will open the log. You can follow the build process and check for errors. In case the building succeeds you can re-submit the updated package. Re-submitting can still not break anything within the original repo! Only if the submit request is accepted by the repo maintainer the changes will become relevant to the repo.
To re-submit simply click on Sources within the package. You will find a link Show the diff and submit these changes back. Click on it, click on submit and add a comment to the submit request, i.e. what you did. Submit the the diff.
That’s it! The buildservice will automatically send an email to the repo’s maintainers and they will handle your submit request.
Of course building an updated package might fail. The most trivial error is e.g.:
error: File /usr/src/packages/SOURCES/luckybackup-0.4.75.tar.gz: No such file or directory
which tells you that the buildservice cannot find the file you told it to build, i.e. either the file name is wrong or the strings that are assembled to create the file name within the spec file. I will add some more hints on how to resolve other trivial errors in the next post.
Feel free to add comments in order to improve this little howto.
As you can read all over PlanetKDE, Calligra 2.4 has been released. In case you have not found them yet, since quite some time Calligra packages(including Krita) are available for openSUSE users, e.g. in KDE:Release:48. Koffice2 packages are removed.
One of the most re-occuring questions regarding KDE PIM within openSUSE is, how one can sync data with Google. KDE:Release:48 now holds the package akonadi-google which replaces the unmaintained akonadi-google-data package.
Both, Calligra and akonadi-google, will be part of openSUSE 12.2.
Finally I would like to point openSUSE KDE users to the beta packages of Digikam. IMHO Digikam is one of the most active and responsive (including bugs.kde.org handling) projects within KDE – attracting new developers by attracting more users. Those that want to help testing Digikam but are not familiar with building software, can get git snapshot packages from KDE:Unstable:Playground. Beware, those are git snapshots and thus might break some functionality. The package is updated at least once a week, so it should help to check for fixed/new bugs.
KDE packages for openSUSE, including Qt 4.8.1, are ready in the KR48 repo. This release is supposed to solve issues with nepomuk/virtuoso-t consuming a lot of CPU and does of course include a lot of other bugfixes. Unfortunately the mail loss bug that appeared with KDEPIM 4.8.1 in combination with a “pipe through” filter was not fixed. I guess more feedback and a devel who can re-produce the issue is needed.
If adding the repo, remember to not mix KDE:UpdatedApps (KUA) or KDE:Extra with KDE:Release:48. KUA is not needed and for Extra you can find the appropriate repo on the wiki.
If you would like to get into the KDE team at openSUSE, drop by on IRC (#opensuse-kde) and/or join the next meeting taking place next week Wednesday 11.04. 17:00 UTC on that channel.
There are annoying bugs and there are data loss bugs. The problem with the latter is that if people notice them it’s already too late. So I would like to collect all the data loss bugs for KDE PIM in order to attract testers and help debugging them, i.e. find a way for developers to re-produce them reliably.
Also, knowing what can cause data loss enables users to work around these scenarios and hence saves a lot of anger towards the devs.
So please point me to data loss bugs and test those listed already. If bugs are re-producible and confirmed by several users using different distros they are more likely to get fixed. Please do not add another “me too” to bug reports which already have a confirmation for your distro! Please do only test with current packages, i.e. akonadi 1.7.1 and KDE PIM 4.8.1.
Symptoms: body and attachments are lost.
How to reproduce: Disconnect network while akonadi is downloading an email to move it to a local folder.
- Send a very large (long time to download is needed) email to your online imap account.
- Click on the email to make kmail display the “loading screen” in the preview pane.
- Press DEL to move the email to the local trash.
- While akonadi/kmail are still downloading, disconnect the network, e.g. open the networkmanagement plasmoid and untick the “enable network” checkbox.
- The email you deleted was moved to the trash as soon as the network got disconnected, even though downloading was not finished. Hence the email in the trash lost its body and attachments.
Symptoms: Body and attachments lost when piping through external application and adding headers.
How to reproduce: Filter incoming emails through an external app which adds headers.
- Create spam filtering rules for spamassasin (or bogofilter) via kmail’s wizard.
- Make sure they are applied to your imap’s inbox.
- If possible open your imap account in a webmail interface.
- Wait for new email to arrive and check with the webmail interface how the email is replaced. Do not read it, since the bug is not re-producible with read email or by applying filters manually.
- After akonadi/kmail has filtered the email and added the anti-spam tool’s header, open it in both kmail and the webmail interface. Both show that the body and attachments are gone.
- For bogofilter you have to train it first (marking emails as spam and ham) in order for it to actually add any headers, i.e. trigger the bug.
Symptoms: Headers as well as body and attachments are lost.
How to re-produce: This bug was not tested yet with recent packages and does not state a way to re-produce, so if you know how, please add it.
Symptoms: Emails lost if KDE PIM is closed while copying from imap to imap.
How to reproduce: Copy/move an imap folder and close kmail while the transaction is still in progress.
IMO this could be a duplicate of bug 293768.
With one day delay, due to some fixes in KDEPIM, KDE SC 4.8.1 got released and openSUSE packages can be found in the KDE:Release:48 (KR48) repo. Akonadi willl be updated to 1.7.1 shortly in order to fix a possible data loss bug when copying/moving emails.
Potential data loss bug in akonadi filtering
I got a new mail loss bug with 4.8.1 when using bogofilter, set-up via the kmail wizard, on new emails arriving in an imap inbox. As I can see via my webmail interface, they get the bogosity header added and are then written back to the server, i.e. the “old” email is deleted and the new one (including a new date and time) added. Problem is, the new one is empty, i.e. lost all its content but the to/from etc. I can reproduce it, i.e. enabling that filter rule causes the issues, disabling it solves it. It only happens on arriving emails, i.e. I cannot re-produce it by applying the filter manually. Maybe akonadi 1.7.1 fixes it, maybe it is that moving/copying bug the NEWS file mentions. It might be a “personal” bug, i.e. only happening to me, yet you have been warned!
UPDATE: Unfortunately this mail loss bug does neither only happen to me nor is it fixed with akonadi 1.7.1.
UPDATE2: There seems to be another very annoying bug introduced with 4.8.1 which makes kmail2 crash a lot for some people. I do not experience that one although nepomuk and email indexing is enabled in general. Maybe because I disabled it for my imap’s inbox via right-click > folder properties > maintenance. So you can try to disable nepomuk and/or disable some folders’ indexing.
Instructions on how to update KDE are available on the openSUSE wiki. As well as the corresponding repos available in case you need apps from Extra or Playground. Remember, never mix the KDE:UpdatedApps repo or any other repo meant for plain openSUSE 12.1 with KR48, i.e. read the warning on the wiki!
How to know when packages are ready
There have been many asking when packages for 4.8.1 will be available and how one should know when they are ready. Actually that’s quite simple.
a) Easiest method: Wait until the packages are announced on the opensuse-kde mailinglist.
b) Other method:
- Check http://www.kde.org for a release announcement.
- Check whether all packages built successfully and got published. The latter is indicated by the loaded lorry icon at the top of the package table.
- You can also check whether publish flags are on. Before a new release building might already have finished but packages might not get published yet.
- Know what you are doing since without any announcement it could still be the case that disabling publishing was simply forgotten and even though published, packages are not ready for use yet – i.e. better stick to a).
Build numbers vs. changed content
Regarding updates many users confuse build numbers vs. changed package content. If the package management shows that updated packages are available it does not necessarily mean that the content of the package changed, i.e. it could be that it is just a re-build and thus has a higher build number. E.g. kdebase4-workspace-4.8.1-40.i586.rpm does not necessarily contain any updates compared to kdebase4-workspace-4.8.1-4.i586.rpm.
How to know whether a package has changed
If you want to know what/whether a package has changed, you can have a look at the package’s sources, which lists the latest revision comment at the bottom or a package’s revision log, which lists all revisions. These are available in the toolbar at the top after you clicked on a package.
If a package is just a link to another package you can find the original package via the link at the package’s source view.