Archive for the ‘KDE’ Category
- In: KDE | openSUSE
- 5 Comments
As of today KDE SC 4.10 final packages are available for openSUSE 12.2 and Factory users. The new KR410 repo got built and you can replace your KR49 repos with it. KDE SC 4.10 will be part of openSUSE 12.3 and all minor updates for that KDE release will be shipped via the official update channel. Of course KDF does also contain KDE SC 4.10 final.
Currently there are no major bugs known. As already mentioned before, kio_sysinfo got replaced by kinfocenter because kio_sysinfo for openSUSE is unmaintained.
It is recommended to run nepomukcleaner to get rid of all legacy data. Beware though that it might take a long time. If you have nothing valuable in your nepomuk database, it is probably quicker to just remove its data from ~/.kde4/share/apps/nepomuk and start from scratch.
Another thing to note: if nepomuk crashes while indexing you might encounter an almost two years old Qt bug which according to the report, Qt devs are reluctant to fix. The problem of this bug is that after the crash virtuoso-t goes crazy. Thus you have to restart nepomuk via KDE’s systemsettings to make it behave again.
Please report packaging issues to the opensuse-kde mailinglist or #opensuse-kde on IRC. Bugs not specific to openSUSE should be reported upstream at KDE’s bug tracker.
- In: KDE | openSUSE
- 11 Comments
From openSUSE 12.3 on and currently already for the RC packages of KDE SC 4.10, kio_sysinfo will be replaced by kinfocenter. The icon for kinfocenter is still missing in the Kickoff > Computer tab but will be added soon. Until then you can start kinfocenter from the normal Kickoff menu.
The main reason for the replacement is that kio_sysinfo is basically unmaintained and hence bugs do not get fixed.
If you were using kio_sysinfo, please check whether kinfocenter provides all the info and functionality you used with kio_sysinfo. If not, post your suggestions here or to the opensuse-kde mailinglist.
Missing information from kinfocenter’s summary I noticed so far:
- temperatures
- free hard disk space for each partition
- current CPU frequency
Most info is available, even in more detail than kio_sysinfo did show it, yet not as part of the summary. E.g. graphics info, memory stats etc.
- In: KDE | openSUSE
- 2 Comments
The KDE:Distro:Factory repo aka KDF now serves KDE SC 4.10 RC2 packages for openSUSE 12.2 (ARM) and openSUSE Factory. KR410 will be created next week.
The KDE release team has decided to ship a third RC for 4.10. Even though this makes the schedule for 12.3 a bit tight the openSUSE KDE team holds on to the plan to ship KDE SC 4.10 with openSUSE 12.3.
Big thanks to everybody who made this happen!
KR49 now holds KDE SC 4.9.5 packages. Thanks to the packagers involved! You can report issues on the opensuse-kde mailinglist or on IRC in the #opensuse-kde channel.
The latter is also where the next openSUSE KDE team meeting will take place, on Tuesday 8 January 18:30 UTC (19:30 CET).
- In: KDE | openSUSE
- Leave a Comment
The release of KDE SC 4.10 is approaching and RC1 packages are now available for openSUSE 12.2 and Factory users from the KDE:Distro:Factory repo aka KDF. You can test them and report packaging and openSUSE-specific bugs on IRC (#opensuse-kde) or the mailinglist (opensuse-kde). Everything else should be filed upstream at bugs.kde.org.
Big thanks to everybody involved!
KDE:Release:410 aka KR410 will be set-up shortly and published as soon as KDE officially releases the final packages for KDE SC 4.10.
Those using KR49 will have noticed that KDE SC 4.9.4 got already published and 4.9.5 will follow at the end of this month.
The KDE team is also proud to congratulate Raymond Wooninck on his election to the openSUSE board! Given his constant commitment to packaging KDE SC and other apps for openSUSE over the last years, I am sure the openSUSE community will profit from his work as member of the board. Congratulations also to Robert Schweikert, the second candidate who got elected to the openSUSE board.
- In: KDE | openSUSE
- 3 Comments
As announced on the opensuse-kde mailinglist, KDE SC 4.9.3 packages are available from the KR49 repo.
With those packages comes akonadi 1.8.1 which includes a lot of fixes from the recent KDEPIM coding sprint. It should improve performance and more importantly, KDE SC 4.9.3 and akonadi 1.8.1 should solve all known data loss bugs. A special thanks to all the PIM developers putting a lot of effort into improving KDE’s PIM stack!
You can find instructions on how to update on the openSUSE wiki.
- In: KDE | openSUSE
- 2 Comments
As per this email KDE SC 4.9.2 packages for 12.1 and 12.2 openSUSE users are available in the KR49 repos. Thanks to everybody who worked on the packaging!
Another news item to note is that the KDE repos at openSUSE are going to be re-organised, have already been respectively. Their structure does now fit the contributors’ workflow better. If everything goes as planned openSUSE is going to ship KDE SC bugfix releases as official updates, starting with openSUSE 12.3. If you are interested in that topic you can find the summary in the opensuse-kde archives.
- In: KDE | openSUSE
- Leave a Comment
The KR49 repo holds KDE SC 4.9.1 packages for openSUSE users, including openSUSE 12.2 which was released recently. For information on how to update please refer to the openSUSE wiki.
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.
KDE SC 4.9 packages for openSUSE
Posted on: August 3, 2012
- In: KDE | openSUSE
- 8 Comments
The KR49 repo holds KDE SC 4.9 packages for openSUSE users. For information on how to update please refer to the openSUSE wiki.
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.
Kudos
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.
- In: KDE | openSUSE
- 13 Comments
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:
Version: 0.4.6
and change it to e.g.
Version: 0.4.7
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.:
Source0: %{name}-%{version}.tar.gz
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.
Build failing
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.
