Moved to Jekyll!

I have decided to change the publication system for my blog from Blogger to static pages generated by Jekyll.

You can find more details at http://blog.ladslezak.cz/2016/05/26/welcome-to-jekyll/.


I also moved the blog to a new address, from now on check this page:

http://blog.ladslezak.cz

Recording a screencast in Linux

Screencasts

A picture is worth a thousand words.

And what if you want to make it even better? What about using an animated image to show some action or progress? Like this one:

Personally I like the animated images on the main project pages at GitHub. See for example git-plus or color-picker Atom plugins. (Or my build-rake plugin displayed above.)

The question is how to record such screencasts?

Screen Recording in Linux

There are several tools for Linux which can be used for screen recording. It also depends it you want to create a standard video file (e.g. for uploading to youtube) or an animated image which can be embedded into web pages.

Standard Video

For recording the desktop to a standard video file (like in AVI or WEBM format) you can use the ffmpeg tool.

To record the screen with audio capture (via PulseAudio) to a WebM file (using open codecs VP9 for video and Opus for audio) use command like this:.

ffmpeg -f pulse -i default -video_size x -framerate 15 -f x11grab -i :0.0+<width>,<height> -b:v 1M -crf 10 output.webm

See these links for more details:

• https://trac.ffmpeg.org/wiki/Capture/Desktop
• https://trac.ffmpeg.org/wiki/Encode/VP8
• https://www.ffmpeg.org/ffmpeg-devices.html#x11grab
• http://www.lxtips.com/2011/07/single-window-screen-capture-script.html

Animated Image

If you want to create an animated image you need to use the GIF image format (you could use an animated PNG as well, but that is not supported by all browsers).

You could use ffmpeg as well (just use output.gif file name), but in my tests the resulting image is too big for using on web pages. It's probably caused by the fact that ffmpeg uses dithering for images with 24bit colors which obviously leads to less compression. Maybe there are some options to tune this, but still writing the position of the recorded area manually is a bit uncomfortable...

Then I found the byzanz tool. It's by default available to install in the openSUSE distribution, simply run:

sudo zypper in byzanz xwininfo

(This will also install xwininfo package, see later why.)

Now you can record the desktop in a similar way like ffmpeg, see the accepted parameters:

byzanz-record --help

Again, you need to manually enter the coordinates of the recorded area if you do not want to record complete screens. And that's not trivial... Fortunately I found this nice byzanz-record-window helper script.

You can install it locally via these commands:

cd ~/bin
wget https://gist.githubusercontent.com/lucy/3042755/raw/eda2b85b51779affbc392a2bb3f1b60ed5fe98ff/byzanz-record-window
chmod a+x byzanz-record-window

The script uses the xwinfo helper to obtain the coordinates of the selected window. They are then passed to the byzanz-record tool.

I'd suggest to use about 3 second delay before starting the actual recording to have some time to get ready (switch to the correct window, position the mouse cursor, etc...).

So the final recording command would look like this:

byzanz-record-window --delay=3 --duration=5 screencast.gif

Final Notes

Be prepared to repeat the recording several times, you'll probably need more than a single attempt. I also found it easier to repeat the recording than editing and rebuilding the animation just to remove the useless parts at the beginning or the end.

Check also the resulting image size, for embedding into web pages it should be as small as possible. If it is too big then decrease the window size, do a shorter recording or avoid too many changes in the image.

The Atom Editor - part II. - The Atom Packages

A Collection of Must Have Atom Packages

The Atom editor calls the extension plugins Packages. The packages can add a new functionality, extend the existing functions or completely replace them. Even the core functions can replaced by an external package.

How to Install Packages

Installing directly from the Atom Editor

It is really easy, in the Setting panel (Ctrl + ,) go to the Install section, search for a package and press the Install button.

Installing from Command Line

Alternatively you can install packages from command line using the `apm` command. Run `apm install package` to install the package. You can also pass multiple packages for mass installation.

Installing Starred Packages

You can mark a package with star - unfortunately only at the Atom web pages, not from the editor itself. Then you can install the starred packages with command "apm stars --install" command.

You can also install the starred packages from a different user. So if you want to install all my starred packages simply run "apm stars --user lslezak".

Note: It will install all starred packages, you cannot select individual packages or change the list before installation. So really check what the bundle contains!

Possible Problems

There are thousands of Atom packages available so it means there is a wide variety of packages and you almost sure find a package for a feature you miss.

Too Many Packages?

But that also means there might be several packages providing the same functionality, there might be forks of the same packages, there might be low quality packages... This is a similar situation like with Rubygems, you have to spend some time searching for the best option.

You can use the download number as a very roughly indicator, a high download number usually means the package is good. (Obviously this metrics does not work for the newly published packages or for very specific packages...)

Conflicts

Another drawback of too many packages is that there might be conflicts between packages by chance. The keyboard shortcuts can easily get in conflict because there are not many possibilities for unique and simple shortcuts.

If a shortcut does not work for you then look whether it is actually defined properly in Settings -> Keybindings section. Or you can press Ctrl+ . (dot) to display the keybinding resolver which displays all actions for the pressed keys.

There are two possibilities how to resolve a conflict:

• Simply ignore the conflict and use the command panel (Ctrl + Shift + p) for selecting and running the action.
• If you need to run the action often and you really want to have a shortcut then you can disable the keyboard shortcuts for the conflicting package. If you need the shortcuts for the conflicting package you can remap them in your config file (there is a link at the top of the Keybinding settings page).

If the packages conflict at the UI level (using the same UI element, that can happen if you install another fork of a package) or at the program level then you should probably report an issue at GitHub and ask the maintainers to solve the conflict.

Generic Packages

[Note: Some screenshots are linked from the project pages.]

• open-recent - Adds a new submenu with the recent files and projects, helps when you often switch between multiple projects.

• local-history - Keeps a copy of each file when saved, can help you if you are experimenting and you want to get some change from the history. When you are testing something you usually do not commit every change to Git (you would need to clean them up later) so if you need to have a fine grained history without Git commits this tool can help you. The changes are displayed in a diff tool (meld by default) so you can easily choose which specific parts should be reverted back.

• sync-settings - Backs up the Atom settings to cloud (GitHub's Gist) which can be later restored. You can easily share the configuration, packages, snippets, etc across several machines (e.g. a desktop and a laptop).
• term3 - Run terminal directly in an Atom tab, run commands without switching to a different window.

Editor Packages

• revert-buffer - Drops all changes and reloads the current file from disk. You can close the file without saving and then reopen it but you would need to file the file in the tree and it would loose the current state (tab position, cursor position).
• change-case - Easily change the case (camel, snake, upper, lower...)
• toggle-quotes - Easily switch between single quote (') and double quotes (")
• highlight-selected - Highlights the selected word in the file, helps with locating functions and variables in the file.
• minimap - Displays a miniature of the file for easy navigation.

Code Completion

• atom-ctags - Improved code completion
• autocomplete-emojis - Auto completes emoji tags
• autocomplete-paths - Auto completes file names

Git Packages

• atomatigit - Adds an optional side bar with Git status and provides some shortcuts for Git commands (stage, commit, push...):

• git-plus - Access to the most used Git commands

I currently combine both, git-plus has direct shortcuts while atomatigit is more interactive (e.g. you can select which changed files to stage and commit).

• git-blame - Displays the "git blame" data next to the text:

• git-history - Displays a commit (diff) from the history of the current file (or a full version)

• git-log - Displays a graph with the Git commits

• line-diff-details - Show and easily revert the changes.

• merge-conflicts - Helps with merging the conflicts.

Additional Language Packages

These packages provide syntax highlighting and support for other file formats and programming languages which are not included in the default set:

• cmake
• cpp14 (extends the standard C++ package)
• diff
• gettext
• haml
• rnc
• rpm-spec

Of course, you can find support for many more languages, just check the available packages.

Ruby Packages

These packages can help you with Ruby development.

• ruby-block - Highlights the matching block at the cursor. When you place the cursor at `end` keyword it highlights the matching `do` or `if` line.

• ruby-block-converter - Easily convert between single line `{}` and multine `do...end` Ruby blocks.

• ruby-quick-test - Runs the test at the cursor, avoid running whole possibly long test suite when fixing just a single test.

Linters

Linters provide live code style checks and/or syntax checks.

• linter - is the base package providing the framework for the specific linters.
• linter-coffeelint - a linter for coffeescrip
• linter-gcc - C and C++ linter using gcc
• linter-ruby - Ruby

• linter-rubocop - There is also Rubocop linter, but unfortunately it requires a recent version of Rubocop (the version used by YaST is too old).

Building tools

For building the sources I basically found two systems:

• build-tools (with build-tools-make extension)

• build (with build-make and build-rake extensions, see the complete list of extensions extensions)

I tried both and it seems that the "build" package is a bit better from the usability point of view. "build-tools" use more complicated keyboard shortcuts and require manual configuration while "build" tries to autodetect the tools used (scans for "Makefile", "Rakefile", etc...).

Web Development

• color-picker - Change CSS colors via visual color picker

• pigments - Another color selection and visualization tool. (Note: I suggest to disable it and enable it only when editing a style sheet. The package treats numbers in a text like "bnc#123456" as a color specification and sets it as the background which looks weird...)

• emmet - expands text like "ul.list>li.item*3" into appropriate HTML structure

• rest-client - A simple REST API client for testing server responses, can be useful for testing the server response.

TODO and FIXME Helpers

• imdone-atom - Scans the project for "FIXME", "TODO" and similar comments. Displays a Trello-like dashboard where you can track the status. The drawback is that it adds some additional tags to each comment (to track the state) so it is not good for project where you do not want to change the code unnecessarily.

• todo-show - Similar to the previous package, but only scans the project. On the other hand it does not touch the code.

Miscellaneous

I found some quite interesting plugins which nicely show the flexibility of Atom.

• lcov-info - Displays code coverage overview and highlights covered and not covered lines. For Ruby you need LCOV coverage generator like simplecov-lcov Ruby gem.
  You need to enable single file output via "SimpleCov::Formatter::LcovFormatter.report_with_single_file = true" option and add the formatter. Unfortunately the generated coverage is saved to "./coverage/lcov/directoryname.lcov" while the lcov-info expects "./coverage/lcov.info" file. You have to move the file manually or enhance the task which runs the test.

• markdown-scroll-sync - A nice enhancement for the builtin Markdown preview package. It keeps the editor position in sync with the preview when scrolling and moving the text.

• regex-railroad-diagram - visualizes regular expressions.

• docblockr - help with writing the documentation comments, scans the function methods and generates a template. Unfortunately the support for Ruby is missing... :-(

• travis-ci-status - Displays a Travis build status icon in the panel. On click it displays details with a direct link to the Travis build.

To be Continued...

The next time we will look at the "hackability" of the Atom editor...

The Atom Editor - part I. - Introduction

The Atom Editor

For the 13th SUSE HackWeek I chose the Atom Editor as the topic.

I wanted to get familiar with it and to learn how to customize it and how to develop new features.

Atom Overview

For the quick overview of the Atom features just watch this video:

If you have more time you can watch this longer video:

Installation

Installation is quite easy, there are pre-built binary packages for the most used Linux distributions. If there is no package for your distribution or it does not work for you then you can build Atom from the sources.

Fortunately for the openSUSE distribution is it easy, just download the RPM package from the main page. It has been built for Fedora 21 but it works without any problem in openSUSE Leap 42.1. (I have tested an older version also in openSUSE 13.2 and it was fine so it should work there as well.)

Setup

I suggest to switch from the default white-on-black scheme to more usual black-on-white which is used by most desktop applications and make switching to the other applications (like a web browser) more eye-friendly.

At the configuration tab (Ctrl + ,) go to the Theme section and select Atom Light as the UI theme and One Light as the syntax theme. You can try the other themes or you can download some new one in the Install section as shown in the videos above.

The Atom Features

Here is a short summary of the features which I found interesting during the short testing. I do not mention the usual editor features and I likely overlooked something. You can also see some features in the videos above.

• The Command Panel (Ctrl+Shift+P) is probably the most important feature. It displays all known commands (the core commands and also from all enabled plugins) with a keyboard shortcut if available. There is also a quick search for looking up.
  So if you cannot remember a shortcut or you do not know where to find a command just simply type it into the search bar and Atom will list all (even fuzzy) matches.
• The Atom authors say it is a hackable editor. I can confirm this, you can very easily change the look or layout or add new features. But let's go into the details in another blogpost...
• Open at GitHub - if you are editing a file which is stored at a GitHub repository you can easily open it in web browser. That's useful if you want to send a position in the code via IM, mail etc...
• Live Markdown preview can be displayed while you are typing. This helps a lot with the correct formatting.

The Atom features can be easily extended by plugins, let's look at them later.

Documentation

You can find the detailed user documentation here.

To Be Continued...

Next time we check some Atom plugins which extend the basic functionality.

SUSE HackWeek12 - YaST: Replacing Travis by Jenkins

Replacing Travis by Jenkins for YaST

I decided to look at the possible Travis replacement as my Hackweek 12 project.

Currently we use both Travis and Jenkins for continuous integration in YaST projects. Unfortunately there are many disadvantages with Travis which require additional work or limit us what we can run in a Travis job. See the hackweek project for the pros and cons summary.

The biggest Travis disadvantage is that the builds are run in a Ubuntu 12.04 system which is 3 years old and it's very difficult to find a recent compiler, Ruby interpreter, libraries,... for it. 

The Jenkins advantage is that it runs on our server and we can run the latest openSUSE very easily and avoid the problem with porting YaST packages to Ubuntu and backporting the development tools.

Jenkins Plugins

I found out that there are several Jenkins plugins which could be used to replace Travis with Jenkins:

• The GitHub plugin - handlers commit hooks sent by GitHub, reports build status back
• The GitHub Pull Request Builder - handles pull request hooks sent by GitHub (similar to the previous plugin, but builds the merged result)
• The Embeddable build status plugin - provides a build status badge (similar to Travis one)

You can install the plugins in your Jenkins instance like this:

• Login into Jenkins
• Go to Manage Jenkins -> Manage Plugins
• In the tab Available select plugins GitHub Plugin, GitHub pull request builder plugin and Embeddable Build Status Plugin and install them

Configuring the GitHub Plugin

• Generate a new access token at GitHub, select public_repo and repo:status. If you want to allow automatic webhook setup select write:repo_hook (you can add/remove the permissions later).
• Add the token to Jenkins -> Manage Jenkins -> Configure System -> GitHub Web Hook section -> OAuth token field
• Put the same token to the "GitHub Pull Request Builder" section, "Access Token" filed.

Create a new Jenkins job for building commits (pull requests are handled separately):

• Select Freestyle project
• Put the Github URL (https://github.com//) to the GitHub project filed
• In the Source Code Management section select Git and put the same URL here
• Make Branch Specifier field empty to build all branches
• In the Build Triggers section - check Build when a change is pushed to GitHub
• Add Build Step -> select Set build status to "pending" on GitHub commit
• Add post-build action - Set build status on GitHub commit
• Configure the other parameters of the build as needed

See more details here.

Configuring the GitHub Pull Request Builder

• Add the created GitHub token to Jenkins -> Manage Jenkins -> Configure System -> GitHub Pull Request Builder section

Create a new job for building pull requests:

• Select Free style project
• Put the Github URL (https://github.com//) to the GitHub project filed
• In the Source Code Management section select Git and put the same URL here
• In Advanced option set Name to origin and Refspec to +refs/pull/*:refs/remotes/origin/pr/*
• Set Branch Specifier to ${sha1}
• In the Build Triggers section - check GitHub Pull Request Builder option
• Check Use github hooks for build triggering option
• Set Commit Status Context to continuous-integration/jenkins-ci/pr (or something like that to have a different ID for pull requests and avoid clashing with the GitHub plugin configured in the previous step

Set Admins or white list users so you do not have to manually trigger builds for trusted developers - the plugin avoids running trusted code at your

Using Both Plugins in One Job?

I tried to use both plugins in a single job to have less jobs but it did not work form me, the pull requests were not processed at all or it did not work at all.

If you find how to solve it let me know...

Coveralls Support?

The question was whether coveralls code coverage can run also outside the Travis environment.

I found out that it is possible, you just need to set the COVERALLS_REPO_TOKEN environment variable and some other variables containing the Git branch, build number, etc... See more details here.

You need to store the token into Jenkins and set it during build.  (You can put the token directly into the .coveralls.yml file, but that's not a good idea for a public Git repository...) Fortunately there is a Jenkins plugin which helps with this, it can inject a secret in to a environment variable. The nice feature is that it can also filter the console output to make sure your password/token does not leak in the build output.

The Current State

I have created some experimental jobs to try the plugins, e.g. yast-registration-github-ci, yast-devtools-github-ci or yast-journal-github-ci.

The jobs are not ready to fully replace the Travis integration, but they work and I my plan is to continue with this project later.

TODO?

There are still many thing to solve:

• Coveralls - pass the Git data (branch name, etc.) from Jenkis, set the  COVERALLS_REPO_TOKEN variable, make sure it's not logged in the console to avoid compromising the value
• Find a way how to define the scripts started in Jenkins. We need to replace the .travis.yml files with something equivalent and share the common parts effectively, very likely as a shared Rake task.
• The current Jenkins jobs use active Git polling, we should switch that to use the GitHub web hooks 

So stay tuned, I'll post updates on this topic...

Bonus Section

During the implementation I found some other interesting possibilities:

Collecting Code Metrics and Code Coverage

The RubyMetrics Jenkins plugin can be used to collect Flog code metrics and RCov code coverage statistics:

That looks nice, but the practical value is low. The code coverage can be collected by Coveralls, which can comment the changes in pull requests, and code quality can be scanned e.g. by CodeClimate which provides more details about the code and better evaluates the code quality in general. More over it offers some hint what and how to fix, not just plain numbers without any clue what's wrong with the code.

So I decided to not use them for YaST.

Writing Jenkins Plugins in Ruby

I found an interesting possibility when playing with Jenkins - it's possible to write a Jenkins plugins in Ruby! There is also an example. Maybe we could simple enhance Jenkins if needed...

Git status in bash prompt - bash-git-prompt

Do you use Git?

Have you ever committed a change into a wrong branch? Have you ever started working on a feature/bug fix without pulling from remote and thus need to rebase and resolve conflicts later? Have you ever forgotten your stashed changes?

With bash-git-prompt tool that's gone!

The tools

Recently I was looking for some tool which would help me to avoid the problems mentioned above.

At first I tried sexy-bash-prompt, but I didn't like the default scheme, it was too different to the usual openSUSE bash command prompt. I tried to customize it, although the code allows some customization I could not make it look like the openSUSE default.

Then I tried bash-git-prompt. This tool is similar to sexy-bash-prompt, but provides more details about the git status. What I really like:

• It prints more details about the current Git status (number of commits behind/ahead of remoter, count of stashed changes,...)
• It periodically fetches the status from remote, if there are new commits on the remote you will be noticed (the check is run every 5 minutes, but it's configurable and can be completely disabled)
• Displays the exit status of the last command, if a command fails you'll see a red X mard and the exit status number. So a failure is more visible on the terminal.

I really recommend to give it a try if you use Git from command line, it can save you same headache...

Installation

Installation is really easy, just run

cd ~
git clone https://github.com/magicmonty/bash-git-prompt.git .bash-git-prompt

If you want to update it later just run "git pull" in that directory.

openSUSE theme

Again the default style is too different, but it turned out that the color and the style can easily changed and bash-git-prompt already provides several styles out of box.

So I decided to create a new style which would mimic the default openSUSE bash prompt as close as possible so you would not notice that you are using bash-git-prompt if you are outside a Git repository.

To use bash-git-prompt with the openSUSE theme simply add this to your ~/.bashrc file:

GIT_PROMPT_THEME=Single_line_openSUSE
source ~/.bash-git-prompt/gitprompt.sh

The next time you start a new shell session bash-git-prompt will be automatically loaded.

Except the exit status at the beginning of the line it looks like the usual openSUSE bash prompt.

Let's see how it can help with Git:

Note: If you do not like the exit status indicator at the beginning of the line then use Single_line_NoExitState_openSUSE theme instead.

Help

You can run git_prompt_help to see what the used symbols mean:

 There are also some examples displayed by git_prompt_examples command:

And if you want to change the colors used in the style you can use git_prompt_color_samples to see all colors available (note: this depends on the terminal configuration, the colors might not be the same in a different terminal):

Note for Midnight Commander Users

I noticed that bash-git-prompt does not work correctly when you use Midnight Commander ("mc"). The problem is that it overwrites the PROMPT_COMMAND shell variable (see more details at

https://www.midnight-commander.org/ticket/2027).

My workaround it to define an alias in ~/.alias file:

alias gp="source ~/.bash-git-prompt/gitprompt.sh"

and run "gp" whenever you want to use the bash-git-prompt functionality in mc subshell.

(The ticket above contains a patch for mc, but you would need to recompile it from sources and maintain it yourselves, i.e. keep it up to date if a security fix is released...)

Cucumber Testing Framework

Cucumber is BDD (behaviour driven development) framework. In contrast to other BDD frameworks (like RSpec) the specification is written in a natural human readable language.

Rubocop-yast

I wanted to write tests for the new Rubocop-yast plugin in some nice way. I started with RSpec, but the tests looked ugly (writing multiline indented Ruby code in a string literal requires extra escaping which makes it quite hard to read...).

Then I looked at the original Zombie Killer tests. They are written in Markdown so they are better readable, you can write some additional comments to the test etc... And how to run the Markdown tests? There is a custom Markdown renderer which converts the Markdown specification into a RSpec test.

Looks nice, but having a custom renderer makes it difficult, we have to maintain it and the Markdown format in specific, there is nothing else similar to it...

Then Cucumber come to my mind! It exactly fits our need! The specification allows to write extra comments and notes, it's readable almost like our Markdown and is a standard tool. The killer feature is multiline docstring parameter. It allows to write indented Ruby code directly without any extra escaping.

You can check how the tests looks here, check the *.feature files. Here is the code which converts the specification into the testing code.

Pros & Cons

Here is the summary of pros & cons I found when starting with Cucumber:

Advantages

• Specification in natural language, readable tests and user stories
• Allows to use other testing framework for running the real tests (like RSpec)

Disadvantages

• Extra code for converting the textual specification to Ruby code
• One more layer between test description and the code (you need to make sure the code really matches the description)
• Test descriptions should describe the high level features (usually the user interaction), they should not describe the low-level implementation details

Ideally the features should be written by managers, designers or other non-technical people. They can describe the required features without any programming skills. That's probably the most important Cucumber feature.

Suitable for Yast?

In my opinion not. Why? We are usually focused on low-level features and we would probably need too much code for converting the specifications to tests. And the tests are usually too different, we would need to write extra conversion for each test and maintain it. The overall benefit would be small in my opinion and would not be worth of doing it.

Moreover the feature descriptions we usually get are hard to convert to a testing code, they are usually too generic or cannot be tested in unit tests (e.g. the installer features).

Links

http://cukes.info/

http://cukes.info/step-definitions.html

https://blog.engineyard.com/2009/15-expert-tips-for-using-cucumber/

http://antonymarcano.com/blog/2010/08/youre-almost-cuking-it/

http://www.elabs.se/blog/15-you-re-cuking-it-wrong

Using Rubocop

Introduction

Rubocop is a Ruby static code analyzer which looks for common code smells and checks the coding style.

Installation

The installation is quite easy, just run "sudo gem install rubocop" command (assuming you have Ruby alredy installed).

Initial Run and Creating the Config File

If there is no .rubocop.yml file in your project root then Rubocop uses the default configuration.

It is a good idea to let Rubocop generate the project default for you, simply run "rubocop --auto-gen-config". This will create .rubocop_todo.yml file which can be used as a template for your initial config file.

The default generated config file disables all checks which fail. That means if you run Rubocop with this config file (or if you remove the _todo suffix) it will report success.

Fixing the Issues

Now you can go one by one disabled check in the created template, enable each check and see where the problem is and whether it's a valid issue according to your style or preferences.

There are basically these solutions how to fix an error reported by Rubocop:

• Fix the issue according to the suggestions reported by Rubocop
• Let Rubocop to fix it for you (does not work for all issues found, but majority of coding style issues, like indentation or white space usage, can be fixed automatically), just add "-a" or "--auto-correct" option. You should manually check the changes done ("git diff") after auto correction, just to be sure the fix was correct and had no side effects.
• Change the expected style (e.g. the default Rubocop style is single quoted string literals, if you prefer double quoted strings in your project then set the different default in the config), see the possible options in the default configuration.
• Disable the check locally in the code (e.g. the rule is valid, but the specific place in the code is an exception where breaking the rule is correct, for example you prefer ".nil?" over "== nil", but in a test you want to check your operator= definition correctly handles nil comparison)
• Disable the check globally

Using Rubocop in CI

To ensure that the coding style is honored during development it is a good idea to run Rubocop at CI (Continuous Integration) server like Travis or Jenkins.

Rubocop in Yast

I tried to start with Rubocop in the Yast registration module which is written from scratch and should not contain ugly code parts introduced by YCP to Ruby conversion.

Initially it reported almost 3000 (!) offenses, but many of them were false positives caused by different coding style defaults (e.g. single quote vs. double quote string literals). After adapting the config style (and relaxing some metric checks which would require non-trivial refactoring) the number of issues was decreased to just about 900.

Majority issues were harmless and related to white space, but some of the checks found really bad code, like this "private" modifier issue.

Thanks to the nice auto correction feature the majority of the issues (~830 which is about 92%) could be fixed automatically. So the number of the manual changes was rather small.

I found only two issues with auto correction - at one place it removed a comment which was inside a removed block (moved outside the block) and in another case it added a trailing space at the end of the line (at that time I had the trailing check disabled so it was not fixed by another check).

You can see all the changes in this pull request.

Result

It was a nice experience with Rubocop as it not only complains what is wrong but also suggests the solution how to fix the found issues. More over it has auto correct feature which works very well and can fix almost all coding styles issues automatically.

So let see if we can use it in more Yast modules...

Adding a new package to the inst-sys (openSUSE installation system) or to the rescue system

Why?

Sometimes you need to add a new RPM to the openSUSE installation system (called inst-sys) or to the rescue image. Especially in Yast development we usually need to include new tools or some new subsystems (like the recent Yast switch to Ruby required adding Ruby interpreter into the inst-sys).

How?

The overall procedure is quite simple, basically you need to modify installation-images package and then remaster the installation medium (or update the boot server, depending how you boot the system). But there are some tricky parts...

Installation-images

This RPM builds file system images (using compressed squashfs to save valuable space) with installation system and the rescue system.

If you want to add a new package then follow these steps:

1. Checkout the installation-images package for your target distribution from OBS, e.g.

   osc co openSUSE:13.1 installation-images

2. Add your new package to the BuildRequires list in the installation-images.spec file
3. Modify the package list for the target file system image, which is stored in *.file_list file. You can find a full example here, there is a diff for adding libyui-qt-graph package to the inst-sys. You can include a complete package or only explicitly listed files (this is usefull if the package is huge and you need just a small file from it).
   Note: If you want to later update the installation-images package used as the base then it is better to use a patch instead of directly modifying the file list. It can be later easily applied to an updated version.
4. Build the package locally using 

   osc build --userootforbuild

   command.
   This will take some time, it needs a lot of packages and building the target file system images is also not trivial.
   The build requires root user, without the extra option it would fail. If you really need to build the package in the OBS server automatically then you need to ask the OBS maintainers for adding an exception for your package.
   (In YaST:Head:installer/installation-images we have such an exception.)

Updating the medium

Updating the boot medium is quite tricky, you need to unpack the /CD1 and /SuSE/openSUSE/CD1 directories from the built installation-images RPM package and overwrite the original files and create the ISO image again.

But I have actually never tried that, in OBS we simply build our own ISO image using a kiwi project.

"New Installer" Details Have Been Published

The details, mentioned in the previous, blog post have been published in the New Installer GitHub wiki page in yast-installation repository.

If you have any questions or comments then ask at the yast-devel mailing list.