My thoughts on Slackware, life and everything

Month: December 2014 (Page 1 of 2)

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.

(Wine-) Pipelight update – careful upgrade

pipelight-logo After a long time of silence (but ongoing development as shown in their git repository) the Pipelight developers released a new stable pipelight a few weeks ago. I created Slackware packages for this (Slackware 14.0 and newer) but before you upgrade, please read the words of caution at the end of this post, they will save you some frustration.

The new pipelight is a bugfix release: after Google deprecated NPAPI plugins, the focus for Pipelight team has been better support for Firefox. As stated in the release notes, most of the remaining bugs should now be in Wine, not in pipelight. That has also lead to more focus on what used to be called “wine-compholio”. the team’s patch-set for wine that implements the Windows browser plugin support. The name “wine-compholio” has changed to “Wine Staging” which is now even used as the default wine version on Fedora. I am not willing to go that far, so there is still a separate wine-pipelight package that you have to install on Slackware in order to use my pipelight package.

Remember that you can always get the latest Windows plugin releases (an important feature in case of security fixes) without having to wait for me creating a new package. Just run the command “pipelight-plugin –update” as root. After doing that, the next time your browser loads the pipelight plugin, it will automatically download the newest version of your installed Windows plugin(s).

I know that some people are grumbling whenever someone develops a program for Linux that enables the use of Windows software (emulated or otherwise), such as wine or pipelight. The fact is, if you want to watch Netflix on your Slackware computer, and you do not want to install Google Chrome, then Mozilla Firefox combined with pipelight and MS SilverLight is still the only way to achieve this. Chromium does not support NPAPI either and the Widevine CDM can not be made to work as it does in Chrome. Also, software using Silverlight is still widespread in school systems. I will welcome the future implementation of EME in Firefox that will allow separate download and use of Content Decryption Modules (CDM) like Widevine which is used by Chrome for streaming Netflix. Then, Google Chrome nor pipelight/silverlight will be necessary any longer. Accepting that DRM is here to stay and can still be made compatible to Open Source and Free Choice is the start and I am glad that Mozilla thought hard and long about the apparent clash and came up with a sane solution.

Anyway, enough of the ranting.

In my original post about pipelight, you will find full installation and configuration instructions, as well as a troubleshooting section. That blog article is also referred to on the pipelight.net support page. Let me remind you that you need to go multilib if you want to use pipelight on 64-bit Slackware.

Package location (uploads expected later today, I thought it was more important to have this blog page up first):

A note of caution when upgrading to my pipelight-0.2.8 package:

This only applies to 64-bit Slackware!!!

I have made one important change to the file locations of the 64-bit pipelight package. The file “libpipelight.so” is a 64-bit shared library, but the previous 64-bit pipelight packages would install this file into “/usr/lib/pipelight/libpipelight.so”. That is not the correct location for 64-bit libraries, so the new package installs this file as “/usr/lib64/pipelight/libpipelight.so”.

This has the side effect that your pipelight stops working. The error message(if you start firefox in a terminal) will be something like “pluginInitOkay(): incompatible version of pluginloader.exe“. Don’t worry, you can remedy this.

These are the steps you have to take in order to fix this (it’s a one-time action):

As root user: remove all old copies of the library created by earlier pipelight versions:

# rm -r /usr/lib/pipelight

As your own user account, list all plugins you have currently enabled (copy that command’s output because you have to re-enable them in a later step):

$ pipelight-plugin --list-enabled

That command basically checks your “~/.mozilla/plugins/” directory for symlinks named “libpipelight*.so”. If you look inside that directory, you will notice that all these symlinks are pointing to the no longer existing location “/usr/lib/pipelight”. So, you first remove those symlinks:

$ pipelight-plugin --disable-all

And re-create them properly (still as your own user account):

pipelight-plugin --enable <your previously enabled plugin(s)>

That’s all. Have fun! Eric

 

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/

LibreOffice 4.3.5 built for Slackware, with 4.4.0 not far off

There was an announcement a few days ago by The Document Foundation about their latest release. LibreOffice 4.3.5 is now available for download. When browsing the download directories, I noticed that sources for 4.4.0 are already present there, but since there is no public announcement yet, I chose to ignore those sources for now. The 4.3.5 release targets “individual and enterprise users” and fixes 70 bugs compared to the previous version – which is perfect for a Slackware 14.1 user.

But I think the upcoming 4.4.0 version will not be as stable and therefore I may not be compiling packages for it as soon as the sources go public. Maybe I will target only slackware-current, but only if I have time (a libreoffice package compilation for a single architecturetakes roughly 14 hours here in a virtual machine).

My LibreOffice 4.3.5 packages for Slackware 14.1 and -current are ready for download from the usual mirror locations:

Reminder to all of you who also have my KDE 5 packages installed: do not use the updated harfbuzz from my ‘ktown‘ repository because it will break LibreOffice. If you are using Matteo Rossini’s slackpkg+ extension to slackpkg then you can configure it so that Slackware’s own harfbuzz package is preferred over the version which accompanies my KDE 5 packages. See this LQ thread for the details.

Have fun! Eric

New chromium and chromium-dev packages

chromium_iconMy previous post already mentioned the updated chromium sources. I have now compiled those into Slackware packages (for 14.1 and -current).

For the curious among you, I have additionally refreshed my chromium-dev packages. Chromium-dev is the development release of the browser (there’s also a “beta” channel but I don’t care about that too much). By play-testing the development release from time to time, I am prepared and do not get nasty surprises when the stable channel jumps to a higher major release (the jump from 38 to 39 was quite intrusive in terms of SlackBuild script).

Chromium-dev packages have the version number 41.0.2236.0. (and are only made available for slackware-current). The version of the stable Chromium is now at 39.0.2171.95.

Get the Chromium packages in one of the usual locations:

Change “chromium” to “chromium-dev” and you have the URL for the development release.

Eric

« Older posts

© 2024 Alien Pastures

Theme by Anders NorenUp ↑