My thoughts on Slackware, life and everything

Category: Me (Page 12 of 27)

Thinking about working on KDE 5 again (frameworks, plasma, applications)

qt-kde-620x350During these final days of my relatively long Christmas holiday, I have started looking at the KDE 5 build scripts again. KDE 4 has seen its final release sometime ago, and Patrick shows no signs of updating the KDE in slackware-current, so in order to bring some fresh excitement to KDE users on Slackware, I am pondering an update of the “testing” repository aka the KDE5 repository.

In December, the KDE community released the first tarballs of the “Applications” which is the first step to completion of the new KDE 5 desktop. Remember: the Frameworks 5 came first (a set of modular libraries that expand the functionality of Qt5), Plasma 5 builds a desktop workspace on top of the Frameworks, so that had to come next, and finally there are the Applications which are now ported from the KDE 4 Development Platform to Frameworks 5 slowly.

In particular that recent release of Applications 14.12 (the notation used here is YY.mm) gave me some headaches. Most of these applications are familiar from KDE 4, and only a few are now ready for the Plasma 5 desktop workspace (Kate and KWrite, Konsole, Gwenview, KAlgebra, Kanagram, KHangman, Kig, Parley, KApptemplate and Okteta). It is impossible for me to separate the KDE 5 applications from the KDE 4 applications. Their names have not changed, and whereas I needed to rename a few packages in Frameworks and Plasma in order to prevent a clash with package names in the KDE 4 set, I do not want to do the same for the Applications. After all, when running Plasma 5 you do not want to see both KDE 4 and Plasma 5 versions of the Konsole application in your desktop menu – just the Plasma 5 version. Also, compiling these “Applications 14.12” will cause a lot of KDE 4 packages to be overwritten – for example, marble-4.14.3 with marble-14.12.0 et cetera. That is a one-way road. I can not think of a clean method of separating the old and the new.

In my “preview” of KDE 5, I was able to offer the KDE 5 packages as co-installable to KDE 4 because it was not yet more than Frameworks and Plasma packages – it needed the presence of KDE 4.x in order to provide a meaningfull Plasma 5 workspace. That meant, you could install KDE 5, play around with it for a bit, and then un-install the packages if you had seen enough, without this process touching or destroying the configuration of your KDE 4 environment. That was a good thing, because Plasma 5 was quite unstable at that time, and the whole exercise was not meant to probide an actual day-to-day work environment.

We are now 5 months further in time, and the current state of Frameworks/Plasma 5 combined with the new set of Application releases, should provide a stable platform that is slowly migrating from KDE 4 to 5.

That is why I decided to not stretch my luck and try another co-installable version of KDE 5 but instead go all the way and provide a full upgrade from KDE 4.14.3 to Frameworks/Plasma/Applications. It will take a while because of all the unknowns, but I think I have done most of the preparations now (gathering all the sources, updating the build scripts). It will be a matter of compiling, fixing failures and retracing issues to their resolution.

I think I will also provide scripts for an easy roll-back from the new KDE 5 packages to either the default Slackware packages or else my KDE 4.14.3 packages.

Note that this is going to be relevant and beneficial only to people who are running Slackware-current (our development version) so if you are going to want to try this later on, you need to know what you are up to. Once you will upgrade from KDE 4 to my new KDE 5 packages, it may not be trivial (i.e. without cleaning out your ~/.kde and ~/.local directories) to downgrade at a later point in time.

End transmission.

Eric

Happy New Year of 2015

To all of you who are reading my blog posts: I wish you all the best for this new year of 2015.

May it be a year where religion is not abused as a reason for killing people indiscriminately. May it be a year where people start thinking out of the box in an attempt to solve the big issues of this era. May it be a year where fear of technology is replaced by joining forces to share new technologies and have everyone profit frm them, not just the rich upper classes. May there… well you get the idea.

Don’t forget Slackware in 2015. I won’t forget you guys. In fact, I hope to post soon with news about bringing Netflix playback support to my Chromium package (this time it looks to be for real).

Cheers, Eric

 

Rye Honey Sourdough Bread

Not everybody follows the Google+ community “The art of bread”, so I will duplicate my post about a great bread I baked last week.

Last year during the christmas holiday, I started my bread baking hobby – basically everything created out of yeasted dough. In the beginning I used the regular “fast-action” yeast – commercial granulated yeast available in small sachets. But then I discovered the health benefits of “wild yeasts” and created several “sourdough starters” to experiment with those. It turns out that the breads I bake from my sourdough starters have so much more depth of flavour than the breads I bake with the fast-action commercial yeast… so that’s what we’ve been eating almost exclusively since spring season.

I felt it was time to create a rye sourdough starter this year’s christmas holiday period, to see how different the breads would be using this new starter compared to the wheat based starters I have used so far.
My first attempt to bake something with that new starter (a buckwheat and dried cherry sourdough bread) failed miserably because the dough collapsed just when I wanted to bake it (was it overproofed? Too much buckwheat?). I still baked the sticky mess in a dutch oven to keep it together somewhat… and the result was a very nicely tasting clump of very dense bread.The second attempt went a lot better:
rye_honey_sourdough
My wife gave me a book on sourdough by the Swedish baker/writer Martin Johansson. Using his recipe for Rye and Honey sourdough, I ended up with the big loaf in the picture. I never had a sourdough grow so much in volume during its bulk fermentation and proofing stages, it was amazing! This time, the dough kept its strength and structure and gave a perfect result. The added honey creates a beautiful dark and tasty crust, and the crumb is soft, with a delicious blend of the rye and acacia honey.
I never cared much for the rye bread we can buy in the shops here in the Netherlands, but I had been adding 10% rye to my whole-wheat sourdough breads lately and that really improved the flavor of my breads. I am glad I finally tried increasing the rye percentage.Here’s the recipe I followed (slightly adapted from the book).The night before you bake, create a levain – mix the following ingredients and leave them to develop overnight (covered under plastic wrap or a towel):

  • 50 gr rye sourdough (100% hydration)
  • 150 gr water
  • 65 gr rye flour (I used stone-milled whole-grain flour)
  • 35 gr whole wheat flour

The next day (in my case, appr. 10 hours later), mix the following together and leave to autolyse for 30 minutes:

  • yesterday’s levain
  • 30 gr honey
  • 165 gr water (tepid)
  • 325 gr strong white flour (I used  200 gr wholewheat and 100 gr plain flour instead)
  • 75 gr rye flour

After the 30 minutes autolyse, mix into the dough:

  • 8 gr salt

Knead the dough by hand for 10 minutes, then leave it in a covered bowl for its bulk fermentation stage. The recipe estimates this to be 3 to 5 hours, but after 3 hours my dough had expanded to more than double the original volume so at that point I decided to continue with the recipe.

Gently press the air out of the dough and fold it into a ball: stretch a bit of the dough to the side and fold it back to the center. Repeat this while rotating the mass of dough. This brings some tension into the skin of the dough ball you are forming.

Dust a round proofing basket with flour (or use any kind of bowl lined with a tea towel and sprinkle the towel generously with flour), and place the dough in the basket with the seam down (the seam-side will be facing upward in the oven, thus creating opportunity for the bread to crack open while baking). Cover the basket (or place it inside a big plastic shopping bag) to prevent draught from messing with it and leave it alone in your kitchen for a further 1.5 hours of proofing.

In the meantime, place an oven stone or pizza stone roughly in the middle of your oven (if you have one of course… the srone adds heat mass which is beneficial for common household ovens), and a metal tray on the oven floor. Pre-heat the oven to 240 C,

When the dough has proofed sufficiently (and roughly doubled in volume again), turn over the basket onto a silicone mat or a sheet of baking parchment, and shove that onto the baking stone in the oven.
Pour a cup of cold water into the metal tray on the oven floor – that will produce steam and develop a great crust.

Bake for 20 minutes on 240 C with the steam, then lower the temp to 210 C, open the oven door slightly to let the steam escape, close the door again and bake for a further 20 minutes.

The smell! The flavor! One of my best.

Ktown for Slackware – development history available in git

kde4 For a long time I have been keeping copies of the full source directories for every KDE 4 release I have made for Slackware. That is amounting to a lot of megabytes, since I am also keeping the source tarballs, not just the scripts and patches. Traditionally, I have kept one KDE version publicly available for all recent Slackware releases, in my ‘ktown’ package repository at http://alien.slackbook.org/ktown/ . This repository is also available through rsync, not just http (using my primary mirror at rsync://taper.alienbase.nl/mirrors/alien-kde/).

But what was missing (because I am lazy) is a git interface. Now, you could argue that accessing the ktown scripts and patches through git is somewhat pointless, since you would either want the packages (through direct download or using slackpkg+) or the full sources (inclusing the source tarballs, not just the scripts) and the git interface I intend would not be offering that.

However,  with the advance of KDE 5, it starts making sense to use git: primarily for version control and history keeping.

The old KDE 4 releases were self-contained: all sources would be released at the same time, so that I could simply create a toplevel directory of, say, “4.14.3” and put everything that I needed to compile the packages below that directory. Easy-peasy. KDE 5 on the other hand, has abandoned the big coördinated release effort. Instead, the releases are now done for subsets of the Software Collection (old name, no longer used). You’ll find separate uncoördinated releases for the KDE Frameworks, Plasma and the Applications. Of course these are all dependent on each other and require specific  versions to work together, but there is no longer something like a “KDE 5.2.0”.

You saw in my initial release of KDE 5 packages that I simply named the toplevel directory “5”, i.e. without minor numbers. My plan for the future is to stick to that number until Frameworks and Plasma move away from 5.x. Inside the “5” directory you will see future partial updates: whenever new Frameworks, Plasma and Applications tarballs are released, I will update one or more of these at the same time, but not necessarily all of them at the same time.

This poses a problem for my internal version control. Copying directory trees every time I refresh a subsection, will create a big mess with greater risk of not being able to go back to a previous point in time, in particular for the “deps” packages but I also see a risk of not being able to retrace working combinations of Frameworks, Plasma and Applications.

Therefore I have decided to move my ktown sources and scripts into a git repository. What I did, was take every final increment of every KDE release since KDE 4.6 for which I have ever created packages, and build a git version control history using those sources. The git repository has a master branch which will be the release which I consider most recent and stable. At the moment, that is 4.14.3. Every release will have its own branch too. There are branches for 4.6.5, 4.7.4, 4.8.4, 4.9.5, 4.10.5, 4.11.5, 4.12.5, 4.13.3, 4.14.3 and 5 at the moment, and you’ll find them here:

http://taper.alienbase.nl/gitweb/?p=ktown.git

I think this will work best for future development on KDE. Currently, the patches in there are mostly gzipped, since this is what Slackware wants, but I am thinking about creating “unzipped” branches for recent releases, so that it will be easier to peek into the patches.

Any feedback, tips etc, let me know.

Eric

Edit – Tue Dec 23 12:26:25 UTC 2014:

I have added a cgit interface as well: http://taper.alienbase.nl/cgit/ktown/

Handbrake – lost for Slackware

handbrake_logo Yesterday, I read about the newest release of Handbrake, the powerful video transcoder. I have handbrake in my Slackware repository, so I decided to dissect the source tarball for the 0.10.0 release and see what was needed to compile it into a package.

Boo hoo.

Handbrake 0.10.0 switched from a GTK+2 to a GTK+3 graphical user interface. Not only that, but it requires a version of GTK+3 that is not even contained in Slackware-current. We have 3.8.2 while handbrake uses functionality which was introduced with 3.10. We’re out in the cold, folks!

You might debate whether Slackware’s GTK+3 is not too old anyway, but then again, GTK releases are notorious for breaking all kinds of stuff thanks to ABI incompabilities. Slackware does not contain GNOME, so there is little reason to stay uptodate on the GTK+3 front when running the risk to break dependent packages.

Anyway, it means that you will not be getting a new handbrake package from me anymore. Perhaps when Slackware-current adopts a newer GTK+3 stack, I can reconsider. But even in that case, Slackware 14.1 and older will have to stick with handbrake 0.9.9 as the last release which will compile.

If time permits I will investigate the possibility of statically compiling GTK+3 plus several of other GTK+3 dependendants into the handbrake package. But that needs time which I do not have. You might already have guessed that – this blog has been pretty silent during the past month. Work related frustrations augmented by family issues, resulting in shifting priorities. To me, Slackware essentially is a hobby, it does not have to make me any money (even though some of you donated, for which my eternal gratefulness) and real life sometimes takes over.

If all you wanted to know was about handbrake then you can leave now.

So I’ll rant on if you cared to stay. Handbrake – big disappointment yesterday I must confess. I really liked that program. There’s also this general feeling of depression I have over the state of GNU/Linux, the Open Source community. my work on Slackware, and whether I can still make a difference. The effort I have put into Slackware, promoting the distro and Open Source in general, I’ve always enjoyed doing that. But the fun is eroding away, and there is this sense of stagnation. Things are moving perpendicular to the direction I want to go in. I am going to need some time for reflection around the end of 2014 and find a way to get invigorated again. Suggestions on a direction to take are welcome. There is not so much action around the distro currently. KDE 4 is about frozen, and KDE 5 is not mature. No joy there. LXQt seems to have jumped from Qt4 to Qt5, another step i do not like. Chromium dropped support for compiling NaCL support into 32-bit package – precisely the reason why I hate it that I need to depend on binary toolchains that are impossible to compile on Slackware. And what to do with my ARM port – I am looking at the mountain of work required to revive it. The list of recent frustrations is much longer than that, but you get the point… it all feels so pointless.

Depressed, you say? You bet! It must be an autumn feeling. Where’s the exit? Going to grab me a beer.

Eric

« Older posts Newer posts »

© 2025 Alien Pastures

Theme by Anders NorenUp ↑