Archive for the ‘KDE’ Category

Note for the Akonadi-pgsql users

A regression was introduced in Qt 4.8.5 (and Qt5) while fixing another issue. This will have unexpected effects if you’re using the Postgres backend.

If possible, do not update your Qt installation (or try to downgrade to 4.8.4 for the moment).

Written by krop

17 July 2013 at 06:19

Posted in Akonadi, KDE, kdepim

A new home for KDESvn

A few days ago, the KDESvn repository was converted from Subversion to Git.

But that’s not all…

It’s now hosted on git.kde.org !

A new product was created on bugs.kde.org, Krazy report is available, translations were moved to the KDE infrastructure and the release tarballs will be moved to download.kde.org soon

Welcome home, KDESvn.

Written by krop

8 July 2013 at 11:15

Posted in KDE

Things you should double check twice (or more) before releasing your software

When you start packaging more and more things for your distribution, you realize how things would be easier if upstream was slighly more concerned about how distributions work. Here are a couple examples of things you shall double check before releasing your work.

1/ Don’t install headers with your runtime stuff.

This sounds obvious, right ? Runtime applications should not be used as a build dependency for anything or it’s no longer a runtime thing.

A bad example: kde-runtime
A good example: nepomuk-core

# ls /kde/inst/kde-runtime/include

knotifyconfig.h knotify_export.h knotifyplugin.h

Now, sit and think: How can you use these headers ?
Simple answer, you can’t because they’re installed by a runtime module, which means:

- There’s no CMake config files installed,
– There’s consequently no way to know these headers locations nor how to link to knotify, anyway.

A solution? Don’t installs headers in a runtime-only module or move your code elsewhere.

That’s the reason why a nepomuk-core module was created before the KDE 4.9 release. We then could get rid of all the nepomuk-dms copies in different KDE projects.

2/ Applications icons *MUST* be installed in the hicolor namespace

Bad examples: lots of KDE applications.
A (very) good example: Okular

Because KDE apps are great, they should also look great in non-KDE environments.

Again, let’s sit and think:

myApp.desktop has an Icon=myIcon line and myIcon.png is only installed in the Oxygen namespace.
Now, what happens if a Gnome, XFCE or $whatever_DE_using_a_different_icon_theme user installs myApp?

Simple, the application icon won’t be visible. Despite what was discussed here, the Oxygen icons set shouldn’t be a must-have to use KDE applications.

Quoting the Icon theme spec:

« So, you’re an application author, and want to install application icons so that they work in the KDE and Gnome menus. Minimally you should install a 48×48 icon in the hicolor theme. This means installing a PNG file in $prefix/share/icons/hicolor/48×48/apps. Optionally you can install icons in different sizes. For example, installing a svg icon in $prefix/share/icons/hicolor/scalable/apps means most desktops will have one icon that works for all sizes. You might even want to install icons with a look that matches other well known themes so your application will fit in with some specific desktop environment.

It is recommended that the icons installed in the hicolor theme look neutral, since it is a fallback theme that will be used in combination with some very different looking themes. But if you don’t have any neutral icon, please install whatever icon you have in the hicolor theme so that all applications get at least some icon in all themes.»

(Source)

After reading this, you should also have realized something: Icons/pixmaps used in your applications that do not exist in the hicolor theme should be installed by your application (duplication is not an issue since these icons won’t be installed in the icons theme directory).

Additional note on this: in openSUSE, rpmlint now throws an error if the application icon is defined in a desktop file but is not installed.

3/ Don’t include half the world in your tarball.

While this may be convenient for your build system, this is a maintainance nightmare for packagers and takes hours to rebuild everything when we have to change even a tiny line.

(very) Bad example: Digikam

Let’s examine the Digikam 2.9.0 tarball: its size is ~55 Mb. Once uncompressed, 29% of the data come from the “core” subdir and 25% come from the “extra” one.

Now, let’s see what in this extra dir:

/tmp/digikam-2.9.0 # ls extra
CMakeLists.txt kipi-plugins libkdcraw libkexiv2 libkface libkgeomap libkipi libksane libkvkontakte libmediawiki

Why is that so bad ?

- kipi-plugins can be used at runtime by Gwenview but didn’t get a proper release since ages (it’s nowhere on ftp.kde.org and the last release on sourceforge is more than one year old),
– libkvkontakte is a build requirement for the akonadi-vkontakte resource, but was never released),
– libksane is already shipped with kdegraphics,
etc…

From a packager point of view, this raises several issues:
– We have to split the packages in sub-packages that can clash when they’re also shipped with KDE,
– We usually don’t want to use embedded 3rd party libraries and prefer some proper releases.
– And more important, a couple libraries that are used to develop other applications don’t have a release cycle.

4/ Embedded 3rd party stuff should not be mandatory

Bad example: qt-creator.

Instead of requiring Botan at build time, qt-creator ships a copy. It could be easily patched out before the 2.6 pre-releases in order to use the distribution Botan. With qt-creator 2.6, it suddenly required more work:

- Commit fcc9ba4 not only updated the botan version, it also merged everything in an ugly blob.

While packaging qt-creator 2.6 beta, some includes had to be added in several places to build with the system botan instead of this blob.

You may think it can’t be worse for packagers? I’m sorry to disappoint you…

- Commit 6f7ce3f4 added a Qt specific patch to the 3rd party embedded Botan. So, now, we not only have to patch qt-creator in order to use the distro Botan, we also have to revert a commit in order to make qt-creator build.

Really, if you can’t resist the temptation to add 3rd party applications in your tarballs, at least:

- make sure to add an option to disable it,

- don’t alter the 3rd party code… and even in this case…

5/ Make sure your application still builds if embedded 3rd party libraries can be disabled

Bad example: Qt5

Qt5 provides a configure option to use the system pcre library. Nothing really new, Qt4 also has the -system-pcre option.

However, for some unknown reason, the system pcre wasn’t found. Using the -v option gives some clues:

PCRE auto-detection… ()
g++ -c -pipe -O2 -Wall -W -fPIE -I/usr/include -I../../../mkspecs/linux-g++ -I. -I/usr/include -I/usr/include/pgsql -I/usr/include/pgsql/server -I/usr/include/mysql -o pcre.o pcre.cpp
g++ -Wl,-O1 -o pcre pcre.o -L/usr/lib64 -lpcre16
/usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: cannot find -lpcre16
collect2: error: ld returned 1 exit status
gmake: *** [pcre] Error 1
PCRE disabled.

You may wonder where this -lpcre16 comes from and you will likely not find a reason. It’s just hardcoded in qtbase/config.tests/unix/pcre/pcre.pro.
It doesn’t matter whether the libpcre pkgconfig file mentions Libs: -L${libdir} -lpcre, this file is just ignored.

*EDIT 2012-11-07* This issue comes from a lack of documentation when using  ./configure –help.  -system-pcre means… “Check whether pcre was built with –enable-pcre16″.
The 7th point could be: “Packagers are not seers, don’t forget docs or build howtos.”

6/ Make sure your application runs if installed in a custom prefix (iow: don’t assume everyone has the same setup as you)
Bad example: plasma (more precisely, libplasma, so this also breaks kactivities)

A couple months ago, Jenkins appeared in the KDE infrastructure. It’s quite nice to detect missing dependencies and includes here and there.

The secret: Jenkins installs everything in a different prefix, updates its environment variables and tries the next target. But what would happen if you try to run KDE with such a setup ?

I can answer: almost all works fine. All… but Plasma. This is kinda problematic since it became unavoidable to run KDE.

What happens in such cases:

- Activities don’t work (the bar is empty),
– You can’t add widgets (same behavior),

I suppose installing kde-workspace in a different prefix than kdelibs is enough to reproduce this issue.

There are probably lots of other minor or real issues that make packagers cry every night, add them in the comments, maybe I’ll write a part#2 :-)

Written by krop

6 November 2012 at 23:22

Posted in KDE

BKO: How to look for duplicate bugs (without wasting too much time)

One of the best Bugzilla feature is its search interface. You can look for almost anything, a comment, an author, a modification date, a bug flag and so on…

Those who sometimes make some noise and suggest to throw away bugs.kde.org and replace it with <insert a random tracker name> are usually not the ones who triage bugs.

The downside: Bugzilla advanced search interface is quite complex…

So, what about saving some time ?

 

Using and abusing bookmarks and shortcuts to find duplicate bugs

Let’s try with Konqueror…

  • Open the Web Shortcuts kcm Settings > Configure Konqueror > Web Shortcuts

  • Let’s create a new shortcut

Shortcuts: Choose something you won’t forget easily ;)

Shortcut URL: https://bugs.kde.org/buglist.cgi?product=kmail&longdesc=\{@}&longdesc_type=allwordssubstr&bug_severity=crash

To search in more than a product, add several product parameters, eg: product=kmail&product=kontact

The longdesc will be replaced by our search string.

Note: on older Bugzilla versions, this parameter is called long_desc. so, use longdesc or long_desc but don’t mix them

bug_severity=crash : We’ll only look for crashes

 

Our shortcut is ready, what about testing now ?

Let’s try with a recurrent crash from 2009: enter  kmailc:KIO::Slave::Deref in Konqueror

 

and the result:

 

Using another browser ? No problemo !

  • Opera

Open Tools > Preferences > Search and press Add

 

  • Firefox

Open Bookmarks > Show All Bookmarks > Select (or create) a new folder > Organize > New Bookmark

 

etc…  Note that %s is used in these browsers.

To reduce the amount of result, you can also look for several lines of the backtrace: eg  kmailc KIO::Slave::deref KIO::Slave::gotInput

 

HOWTO…

- Look for normal bugs or wish reports ? / List the critical bugs ?

the bug_severity parameter accepts the following values: critical, grave, major, crash, normal, minor, wishlist

eg: &bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=normal&bug_severity=minor will look for all but crash and wishlist reports.

- Look only for bugs marked as FIXED ?

Add  &bug_status=FIXED to the search URL

the bug_status parameter accepts the following values: UNCONFIRMED, NEW, ASSIGNED, REOPENED, RESOLVED, NEEDSINFO, VERIFIED, CLOSED

- Find normal duplicate bugs ?

This is a bit harder, look for words, synonyms…

eg: kmailw toolbar returns https://bugs.kde.org/buglist.cgi?product=kmail&longdesc=toolbar&long_desc_type=allwordssubstr&bug_severity=wishlist here

 

 

 

Written by krop

18 May 2012 at 12:00

Posted in Bugzilla, KDE

Is Kmail still being developed?

This question was posted on the KDE forum a few days ago and deserves an answer.

Yes, KMail is maintained, It even has a new maintainer since a few months. Laurent Montel now takes care of KMail2 and already made an awesome work.

So, what’s the state of KMail in KDE 4.7 ?

Since the 4.7.0 tag, 556 commits were made in kdepim/kmail.
But KMail is no longer a monolithic block, so let’s add:

  • 207 commits in kdepim/mailcommon,
  • 51 commits in kdepim/mailfilteragent.
  • 98 commits in kdepim/messagecomposer,
  • 43 commits in kdepim/messagecore,
  • 54 commits in kdepim/messagelist,
  • 153 commits in kdepim/messageviewer,

Still not convinced ? Let’s head to the KDE Bugs Tracker

Since the creation of the KMail2 product, 690 bugs were marked as RESOLVED.

Amongst those:

  • 11 bugs were marked as UPSTREAM (bug in one of the KDEPIM/KDE dependencies)
  • 4 bugs were marked as DOWNSTREAM (distribution/packaging bug)
  • 6 bugs were marked as WONTFIX
  • 67 bugs were marked as INVALID
  • 77 bugs were marked as WORKSFORME (the reporter cannot reproduce the issue)
  • 178 bugs were marked as DUPLICATE (!!)
  • 324 bugs were marked as FIXED

Still according to our bugs tracker,

  • 14 bugs were explicitly marked as fixed in 4.7.2
  • 24 bugs were explicitly marked as fixed in 4.7.3
  • 24 bugs were explicitly marked as fixed in 4.7.4
  • 15 bugs were explicitly marked as fixed in 4.8

KMail bugs closed since KDE 4.7.3 (only the reports explicitly marked as fixed-in 4.7.4 are listed):

  • 143059 printing of mails ignores if part of the mail is blinded out
  • 258117 Cannot create Mailing List filter via context menu
  • 259422 Kmail ignores trash folder setting. It moves deleted emails to the local trash folder.
  • 263587 BCC addresses shows bcc’s to “To:” recipient
  • 278060 Mailing list detection does not work
  • 280649 Kontact crash when closing
  • 282652 Setting up filters for Distribution lists does not work
  • 284789 Does not remember mail transport
  • 285134 Closing the drop action popup by clicking somewhere else will execute a “move” operation instead of “cancel”
  • 285508 subject line is always spell checked with default dictionary
  • 285623 emails are not sent until restart of mail dispatcher agent
  • 285653 Thousands of errors “Select Failed, server replied A000… NO Mailbox …
  • 285814 Shortcut for moving mail to folder does not move to folder highlighted in dialog
  • 285878 search mail – unusable sort by date
  • 286505 kmail no more send mails
  • 286615 Encrypted email not decrypted in-time for printing
  • 286663 Kontact crashed when canceling creation of sieve script
  • 286827 Unable to reply to an encapsulated message
  • 286875 Redirected email is stored in wrong sent-folder
  • 286889 Move Thread to Trash Context Menu
  • 286922 edited mail from outbox deleted after closing
  • 287367 Kmail is truncating recipients in “reply to all”
  • 287696 redirected mail isn’t marked as redirected (or forwarded)
  • 287779 Copy Email then Paste As Attachment does not work as expected

Written by krop

7 December 2011 at 22:30

Posted in Bugzilla, KDE, kdepim

How to setup your external SQL server for Akonadi

The reasons why Akonadi starts its own database instance are sometimes unclear to users.
In a perfect world, Akonadi, Amarok, Digikam… would use the same database but well… stop dreaming, the reality is different, there are valid reasons.

Currently Akonadi can start and work with both MySQL (and variants) or Postgresql.  It even supports using an external server.

You may wonder why we prefer starting a dedicated instance of your favorite server. There are two main reasons for that:

  • Users should not have to be root to set up Akonadi. Using an external server means you have to create a user, grant him some privileges and create a database before starting Akonadi; In fact, users should not have to bother about what Akonadi is.
  • Akonadi needs some special settings to work correctly. For obvious reasons, the Akonadi server cannot change your central MySQL settings.

 

How to configure your external server ?

The answer for MySQL is easy: use the same settings as the internal server.

For desktop users: mysql-global.conf

For mobile users: mysql-global-mobile.conf

The wait_timeout tweak is *very* important. The default value is 8 hours and once reached, you end up with this error: MySQL server has gone away QMYSQL: Unable to execute query which leads to all kind of issues (eg. 219710#3226400#c8)

 

Using an external Postresql server is also possible but you must have standard_conforming_strings = on in your postgres.conf. If off, Akonadi will not be able to fill its tables and you end up with issues such as bug 267807.

The Postgres doc claims «the default will change to on in a future release for improved standards compliance» since 8.2. Nothing happened yet…

 

 

 

Written by krop

21 July 2011 at 23:24

Posted in Akonadi, KDE, kdepim

Show your Yahoo calendars in KOrganizer ? so easy…

A few days ago, Jeremy explained how to add your Google calendars to Kontact, how about doing the same with your Yahoo calendars ?

Thanks to the DAV resource, adding external calendars became quite easy, let’s see how to do.

Start KOrganizer, in the calendars list, right-click and select ‘Add Calendar’

In the list of calendars type, select the DAV groupware resource and press ‘OK’

In the groupware server list, choose  Zimbra then ‘Next’

Now enter ‘caldav.calendar.yahoo.com‘ in the Host field and check the Use secure connection box. Do NOT add https:// before the URL

After pressing ‘Next’, press the Test connection button

and enter your Yahoo login and password

The earlier dialog will tell you if anything went wrong

You’re almost done, after pressing next, you may change the display name (that will appear in the KOrganizer calendars list) and press edit

The next dialog will show your settings for this resource. Click on fetch to make sure your Yahoo calendars are correctly listed

Voila, if you press OK to the opened dialogs now, your calendars will magically appear in KOrganizer

But… hey wait, have you noticed the carddav item in the previous dialog ? What happens if we try to add our Yahoo contacts ? Let’s see…

Press the Add button

Choose CardDAV.

In the Remote URL field, enter https://carddav.address.yahoo.com/principals/users/your_yahoo_email_address

In the Username field, enter your email

Press OK to the opened dialogs and You will see the result the next time you launch KAdressbook

Written by krop

29 April 2011 at 23:57

Posted in KDE, kdepim

Follow

Get every new post delivered to your Inbox.