Thursday, June 15, 2017

KDE Applications 17.08 Schedule finalized

It is available at the usual place https://community.kde.org/Schedules/Applications/17.08_Release_Schedule

Dependency freeze is in 4 weeks and Feature Freeze in 5 weeks, so hurry up!

Thursday, April 20, 2017

Okular 1.1 released!

Today KDE Applications 17.04 was released.

It includes Okular 1.1, it contains a nice set of features:
* Add annotation resize functionality
* Add support for auto-calculation of form contents via JavaScript
* Allow to rotate the page view using two-finger pinches on a touchscreen
* Change pages in presentation mode by swiping on touch screen
* Added support for Links that change the Optional Content visibility status
* Allow to disable automatic search while typing
* Allow to create bookmarks from the Table Of Contents

This release was brought to you by Albert Astals Cid, Oliver Sander, Luigi Toscano, Martin T. H. Sandsmark, Tobias Deiminger, Antonio Rojas, Burkhard Lück, Christoph Feck, Elvis Angelaccio, Gilbert Assaf, Heiko Becker, Hrvoje Senjan, Marco Scarpetta, Miklós Máté, Pino Toscano, Yuri Chornoivan.

Tuesday, April 04, 2017

Akademy 2017 Call for Papers deadline is in a week!

The Akademy 2017 Call for Papers ends April 10th at 23:59:59 CEST.

Surely you have interesting stuff to share with the community, so go to https://akademy.kde.org/2017/cfp and submit a proposal!

Tuesday, March 07, 2017

Okular table selection mode is amazing

I case you didn't know ;)


Okular has a amazing table select mode where you select an area and Okular will auto detect rows and columns on it (you can fine-tune it afterwards) and then you can directly copy&paste to a spreadsheet :)

It's mostly tested on PDF files, but should work the same on any of the formats we support text extraction.

Update: This feature is not new, just i got to use it today ;) Video at https://www.youtube.com/watch?v=E8XWI06tltY

Wednesday, March 01, 2017

Okular Form Field auto-updating (Work In Progress)

You can see it in https://www.youtube.com/watch?v=fCLFkpaW3Ug

As the description of the YouTube video says:

Form 14 updates from Form 13 values as defined by the PDF file.
There's a few bugs left:
* To make the page contents update i need to edit another form in the page of the form that is being auto updated
* The contents of the "editable" Form are not updated. (The form is actually not editable since it's readonly)

And also a pile of uncommited and unreviewed patches, and probably only works for very simple files like this one, but it's a start :)


Update: It works fine now and everything has been commited :) https://www.youtube.com/watch?v=S-zmHc3WUhs

Thursday, February 16, 2017

Wednesday, December 07, 2016

The dangers of stable/LTS/supported versions

Ubuntu 14.04 LTS is supported until April 2019 and ships poppler 0.24.5 http://packages.ubuntu.com/search?suite=trusty&searchon=names&keywords=libpoppler-dev

RHEL 7.3 ships poppler 0.26.5 (I may be wrong, https://git.centos.org/summary/?r=rpms/poppler is the best info i could find, Red Hat does not make easy to know what you're buying)

Debian stable (Jessie) ships poppler 0.26.5 https://packages.debian.org/search?suite=jessie&searchon=names&keywords=libpoppler-dev

Current release is poppler 0.49 https://poppler.freedesktop.org/releases.html

This means that people are running stable versions and thinking they are secure, but if we trust security specialists, [almost] every crash can be exploited, and I'm almost sure neither Ubuntu nor RedHat nor Debian have backported all of the crash fixes of the more than 20 releases and 2 years of development behind those *very old* versions they are shipping.

I don't know how/if this can be fixed, but i honestly think we're giving users a false sense of security by letting them run those versions.

No one "works" on Poppler

I thought that was obvious, but today someone thought that i was "working" as "paid working" on it.

No, I don't get paid for the work i do on Poppler.

It's my computing hobby, and on top of that it's not even my "primary" computing hobby, lots of KDE stuff take precedence over it, and i guess Gnome stuff may also take precedence for Carlos (second top commiter according to the git shortlog)

Aside a few paid contributions and some patches that may have come from people that use the software on their business (and we could file them under "paid" since they did the fix as part of their job) no one has a paid job that is mainly "work on poppler".

I guess we've done a good enough job as hobbyist :)

Obviously we could do better, so if you have lots of money and are interested in making free software PDF rendering beter please hire someone to help us (no, this is not me asking for money, I've a good enough job already).

And if you don't have money but you have some free time and like to help, join us :)

And if you really really have some free time or lots of money you could port Okular, Evince et al to pdfium and see if it's actually better/worse than poppler.

Tuesday, November 15, 2016

Finding a valid build order for KDE repositories

KDE has been lately been growing quite a bit in repositories, and it's not always easy to tell what needs to be build before, do i build first kdepim-apps-libs or pimcommon?

A few days ago i was puzzled by the same question and realized we have the answer in the dependency-data-* files from the kde-build-metadata repository.

They define what depends on what so what we need to do is just build a graph with those dependencies and get a valid build order from it.

Thankfully python already has a module for graphs and stuff so build-order.py was not that hard to write.

So say you want to know a valid build order for the stable repositories based on kf5-qt5

Here it is

Note i've been saying *a* valid build order, not *the* valid build order, since there are various orders that are valid since not every repo depends other repos.

Now i wonder, does anyone else find this useful? And if so to which repository do you think i should commit such script?

KDE Applications 16.12 branches created

The dependency freeze for KDE Applications 16.12 is on since November 10

For all repositories part of the KDE Applications 16.12 release the Applications/16.12 branch has been created.

The list of modules+branches that will be part of the release is at https://cgit.kde.org/sysadmin/release-tools.git/tree/modules.git?h=Applications/16.12

Please make sure the list is correct. If it's not please email release-team at kde.org *NOW*

From now on master is open for feature changes, but remember that all your fixes also should get to the Applications/16.12 branch (my suggestion, commit fixes to Applications/16.12 and then merge that branch to master)

KDE Applications 16.12 Beta (version number 16.11.80) will be tagged November 17 at 23:59 UTC

Once the Beta is tagged no more features can be added.

Sunday, October 23, 2016

Tuesday, August 30, 2016

I'm going to Akademy :)





I'm coming back home on Tuesday afternoon-ish so if you want to catch me for something be sure to make it before then :)

See you in Berlin!

Saturday, July 02, 2016

KDE Applications 16.08 Schedule finalized

It is available at the usual place https://community.kde.org/Schedules/Applications/16.08_Release_Schedule

Dependency freeze is in 2 weeks and Feature Freeze in 3 weeks, so hurry up!

Tuesday, May 03, 2016

Akademy 2016 travel support

If you want to attend Akademy 2016 but are a bit short on money, that is no excuse :)

Read https://mail.kde.org/pipermail/kde-community/2016q2/002758.html for more info on how the KDE e.V. can help you!

Friday, March 11, 2016

Workaround for trouble with updating akonadi tables

I was just updating the Kubuntu packages that move from akonadi 15.08 to 15.12.1 and sadly akonadi failed to migrate with this error


Adding new foreign key constraints
"ALTER TABLE PimItemFlagRelation ADD FOREIGN KEY (PimItem_id) REFERENCES PimItemTable(id) ON UPDATE CASCADE ON DELETE CASCADE"
Updating index failed:
Sql error: Cannot add or update a child row: a foreign key constraint fails (`akonadi`.`#sql-6ea8_3`, CONSTRAINT `#sql-6ea8_3_ibfk_1` FOREIGN KEY (`PimItem_id`) REFERENCES `pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE) QMYSQL: Unable to execute query
Query: ALTER TABLE PimItemFlagRelation ADD FOREIGN KEY (PimItem_id) REFERENCES PimItemTable(id) ON UPDATE CASCADE ON DELETE CASCADE
""
Unable to initialize database.

Bug 354536 will be fixed with the akonadi 15.12.3 release next week.

Lucky meanwhile amazing Dan was ready to help me workaround the issue.

You need to start mysql (if that's what you're using as akonadi backend)
mysqld --defaults-file=$HOME/.local/share/akonadi/mysql.conf --datadir=$HOME/.local/share/akonadi/db_data --socket=/tmp/akonadi-mysql.socket

then connect to it
mysql -S /tmp/akonadi-mysql.socket

And run a series of sql commands
http://paste.ubuntu.com/15344766/

After that shut down mysql
mysqladmin -S /tmp/akonadi-mysql.socket shutdown

And start akonadi and you should be golden again
akonadictrl start

Wednesday, February 10, 2016

Sunday, September 27, 2015

KDE dinner in Berlin - October 3

This weekend the KDE e.V. board is going to have an in-person board meeting in Berlin.

We would like you to join us for dinner on Saturday 3 around 19:00 (location still undecided, suggestions accepted).

If you are interested in talking about KDE, KDE e.V., Free Software, Open Source, today's elections in Catalonia or any other random talk and want to have a good time let me know that you're coming (latest by Wednesday night).

Saturday, September 26, 2015

September 26: SystemSettings and KCMs bug triaging day!

Today/Tomorrow September 26 is SystemSettings and KCMs bug triaging day.

As described by Jeremy in this post in the KDE Gardening mailing list the purpose is:

1. Triage all bugs in the systemsettings product (and maybe the kcm product too).
2. If a bug is reproducible still, comment on it and find someone that knows how to fix it and convince them to do so.
3. Find maintainers for as many of the kcms as we can.

This is something anyone with a relatively new Plasma installed can help with so join us on September 26 at the #kde-devel IRC channel!

Personally I'll be on from 10am Spanish time until around 4pm with some lunch time in between.

More info at the gardening wiki for SystemSettings

Tuesday, August 18, 2015

Using git the proper way for correct release changelogs

If you look at kdenlive's changelog for KDE Applications 15.08 and for KDE Applications 15.04.3 you'll see that "Fix autosave not working when opening project file from command line or click in file browser" shows up in both.

On the other hand if you have a look at gwenview, in 15.04.3 it shows "Make saving thumbnails work again" while it's not part of 15.08.

Does that mean that this bug got lost?

No, gwenview is actually the correct thing, we should not mention a bug again for 15.08 if it was released in 15.04.3, since well it's been released already :D

So why does kdenlive, marble and others show commits in the two places?

Because their developers are not doing the proper git-thing of commiting to the oldest supported branch and then merging up to master, so for git it's two different commits instead of the same (in case of the kdenlive commit in question it'd be https://quickgit.kde.org/?p=kdenlive.git&a=commit&h=cc55a9cea5c2f029744f8aba79a362fd302ec0bb and https://quickgit.kde.org/?p=kdenlive.git&a=commit&h=28b3cc7b5141fcc2fed84433b9fe9851c35b7e08).

Commiting the fix to the oldest supported branch and then merging up has lots of other benefits (like making sure you never forget a fix in master), but maybe this is the one that finally convinces more devs to switch to it, nicer changelogs ;)