See https://www.kde.org/announcements/announce-applications-16.12.0.php for the announcement and https://www.kde.org/announcements/fulllog_applications.php?version=16.12.0 for the reaaaaaaaaally long changelog.
Well done everyone :)
A blog about random things and sometimes about my work translating and developing KDE and anything
Thursday, December 15, 2016
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.
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.
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?
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.
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
KDE Applications 16.12 Schedule finalized
It is available at the usual place https://community.kde.org/Schedules/Applications/16.12_Release_Schedule
Dependency freeze is in 2.5 weeks and Feature Freeze in 3.5 weeks, so hurry up!
Dependency freeze is in 2.5 weeks and Feature Freeze in 3.5 weeks, so hurry up!
Tuesday, August 30, 2016
I'm going to Akademy :)
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!
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!
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
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
KDE Applications 16.04 Schedule finalized
It is available at the usual place https://techbase.kde.org/Schedules/Applications/16.04_Release_Schedule.
Dependency freeze is in 4 weeks and Feature Freeze in 6 weeks, so hurry up!
Dependency freeze is in 4 weeks and Feature Freeze in 6 weeks, so hurry up!