Ladislav's blog
Tuesday, July 31, 2012
OpenSUSE Hackweek VIII - New WebYaST home page
I noticed in the previous post that we want to have new cool home pages for WebYaST.
We started at our Appliance Workshop and last week I continued as a Hackweek VIII project and the new page is now available here:
If you have any comments just post them here! Thank you for your feedback!
Labels:
webyast
OpenSUSE Hackweek VIII - New WebYaST Demo Appliance
I decided to work on WebYaST home page and finish the WebYaST demo appliance.
Some time ago we had a workshop where we decided to create cool web pages for our projects. We started with WebYaST. The goal is to create a nice looking web presentation.
And we want to have some WebYaST demo so users could easily try it without any setup or installation. So we decided to create a WebYaST demo appliance in SUSE Studio which can be used as a LiveCD or USB stick or even directly in Studio testdrive in a web browser (no need to download anything!).
This is really easy as Studio has WebYaST support built-in, just go into Configuration -> Appliance tab and check Enable WebYaST check box at the very bottom of the page. And that's it!
Studio will add all needed WebYaST packages, opens port at firewall (54984) and autostarts WebYaST at boot.
But if we want to have a really nice demo we still need to do some improvements...
Originally I started with KDE desktop but WebYaST basically does not depend on any desktop environment so I switched to LXDE which takes less space and should run faster than KDE (especially on slower machines).
SUSE Studio supports autologin configuration (Configuration -> Desktop) so users do not have to enter any password to start graphical session, that's nice.
Another nice feature is automatic application start, so we can easily start Firefox. The only problem was that in testdrive WebYaST was sometimes started later than Firefox which obviously displayed error page. This is solved by 5 second delay before starting Firefox.
This was the hard part and it's quite tricky. When you first time connect to a running WebYaST instance in Firefox you'll see a certificate warning. The problem is that WebYaST generates a self-signed certificate (when there is no existing certificate yet) which is not trusted so Firefox displays that warning. And this might be scary for beginner users, we want our users to try WebYaST without any doubts...
Then I found certutil tool available in mozilla-nss-tools package in openSUSE. This can be used to import a certificate to Firefox from command line. So for WebYaST this means running this command for the default user:
(See certutil --help for more details.)
The only problem is that Firefox uses profiles (named configurations) stored at random generated directory which is created at first start. And that directory must exist before executing the certutil command.
This is solved by overlay files in Studio, there is a prepared directory with the default Firefox profile.
The problem is that the random hostname is automatically generated and we cannot easily change that in the URL for Firefox.
The trick is to use IP address directly instead of a host name. The WebYaST certificate in the demo appliance is generated for host 127.0.0.1 and URL for Firefox is set to https://127.0.0.1:54984.
See yastwc overlay file for all certificate related changes.
The final WebYaST demo appliance is available in SUSE Studio Gallery. You can easily try WebYaST as a LiveCD/LiveUSB stick or directly in your browser in Studio testdrive.
And how to use it? That's really simple! Just boot the image, wait until Firefox with WebYaST login dialog opens. Then use root user name with linux password to log into WebYaST.
Have a lot of fun!
Some time ago we had a workshop where we decided to create cool web pages for our projects. We started with WebYaST. The goal is to create a nice looking web presentation.
And we want to have some WebYaST demo so users could easily try it without any setup or installation. So we decided to create a WebYaST demo appliance in SUSE Studio which can be used as a LiveCD or USB stick or even directly in Studio testdrive in a web browser (no need to download anything!).
Including WebYaST in an openSUSE-12.1 SUSE Studio Appliance
This is really easy as Studio has WebYaST support built-in, just go into Configuration -> Appliance tab and check Enable WebYaST check box at the very bottom of the page. And that's it!
Studio will add all needed WebYaST packages, opens port at firewall (54984) and autostarts WebYaST at boot.
But if we want to have a really nice demo we still need to do some improvements...
Appliance Fine-tuning
Originally I started with KDE desktop but WebYaST basically does not depend on any desktop environment so I switched to LXDE which takes less space and should run faster than KDE (especially on slower machines).
SUSE Studio supports autologin configuration (Configuration -> Desktop) so users do not have to enter any password to start graphical session, that's nice.
Another nice feature is automatic application start, so we can easily start Firefox. The only problem was that in testdrive WebYaST was sometimes started later than Firefox which obviously displayed error page. This is solved by 5 second delay before starting Firefox.
Importing WebYaST Certificate into Firefox
This was the hard part and it's quite tricky. When you first time connect to a running WebYaST instance in Firefox you'll see a certificate warning. The problem is that WebYaST generates a self-signed certificate (when there is no existing certificate yet) which is not trusted so Firefox displays that warning. And this might be scary for beginner users, we want our users to try WebYaST without any doubts...
Then I found certutil tool available in mozilla-nss-tools package in openSUSE. This can be used to import a certificate to Firefox from command line. So for WebYaST this means running this command for the default user:
# certutil -A -n "Webyast certificate" -t "C,," -d /home/tux/.mozilla/firefox/*.default \ -i /etc/lighttpd/certs/webyast.pem
(See certutil --help for more details.)
The only problem is that Firefox uses profiles (named configurations) stored at random generated directory which is created at first start. And that directory must exist before executing the certutil command.
This is solved by overlay files in Studio, there is a prepared directory with the default Firefox profile.
Server Name in the Generated certificate
During tests I found out that there is a problem with certificate server name and the URL. Firefox displayed a certificate error when opening https://localhost:54984 with message saying that the certificate is valid for linux-foobar server only (with foobar replaced by some random characters).The problem is that the random hostname is automatically generated and we cannot easily change that in the URL for Firefox.
The trick is to use IP address directly instead of a host name. The WebYaST certificate in the demo appliance is generated for host 127.0.0.1 and URL for Firefox is set to https://127.0.0.1:54984.
See yastwc overlay file for all certificate related changes.
The Final WebYaST Demo Appliance
The final WebYaST demo appliance is available in SUSE Studio Gallery. You can easily try WebYaST as a LiveCD/LiveUSB stick or directly in your browser in Studio testdrive.
And how to use it? That's really simple! Just boot the image, wait until Firefox with WebYaST login dialog opens. Then use root user name with linux password to log into WebYaST.
Have a lot of fun!
Labels:
appliance,
demo,
suse studio,
webyast
Tuesday, January 24, 2012
Switching from Gettext to FastGettext in a Rails3 app
From Gettext to FastGettext
In SLMS we use Gettext for i18n support. Unfortunately it doesn't work with new Rails 3. But we found out that there is FastGettext Ruby gem which does work with Rails 3 and we decided to switch to this different implementation.In this blogpost I'll describe the needed steps when switching from Gettext to FastGettext. And here also are solutions for some problems we found during the transition.
Using the new Ruby gems
You will need these new Ruby gems:- fast_gettext: https://github.com/grosser/fast_gettext
- gettext_i18n_rails: https://github.com/grosser/gettext_i18n_rails (FastGettext Rails integration)
- rails-i18n: https://github.com/svenfuchs/rails-i18n (Default Rails translations)
The first step is to remove the old Gettext gems and replace them by FastGettext gems.
So replace these gems in your Gemfile:
gem 'locale' gem 'locale_rails' gem 'gettext' gem 'gettext_activerecord' gem 'gettext_rails'
gem 'fast_gettext' # 0.4.3 contains fixes in #'rake gettext:store_model_attributes' task gem 'gettext_i18n_rails', '>= 0.4.3' # rails-i18n provides translations for ActiveRecord # validation error messages gem 'rails-i18n' # needed to collect translatable strings # not needed at production group :development do # needed for HAML support (optional) gem 'ruby_parser' # no need to load the gem via require # we only need the rake tasks gem 'gettext', '>= 1.9.3', :require => false end
Then you need to initialize FastGettext, create config/initializers/fast_gettext.rb file:
# define your text domain FastGettext.add_text_domain 'foo', :path => File.join(File.dirname(__FILE__), '..', '..', 'locale') # set the default textdomain FastGettext.default_text_domain = 'foo' # set available locales # (note: the first one is used as a fallback if you try to set an unavailable locale) FastGettext.default_available_locales = ["en_US","ar","cs","de","es",...]
class ApplicationController < ActionController::Base
# replace these old Gettext calls:
# init_gettext "your_domain"
# GetText.textdomain("your_domain")
# by this:
include FastGettext::Translation
before_filter :set_users_locale
def set_users_locale
I18n.locale = FastGettext.set_locale(params[:locale] || cookies[:locale] ||
request.env['HTTP_ACCEPT_LANGUAGE'] || 'en_US')
cookies[:locale] = I18n.locale if cookies[:locale] != I18n.locale.to_s
end
end
Note: The application needs to be restarted after any change in the translations.
Solved Problems
Automatic detection of available locales
Using fixed list in the available locales list might not be nice, especially if you want to dynamically add new translations later. In this case you need to find the available locales dynamically at start. The solution si to put this code to config/initializers/fast_gettext.rb file:# put 'en_US' as first, the first item is used as a fallback
# when requested locale (via ?locale= URL parameter) is not found
FastGettext.default_available_locales = ["en_US"]
# get available locales automatically
Dir[File.join(File.dirname(__FILE__), '..', '..', 'locale', "/*/LC_MESSAGES/*.mo")].each do |l|
if l.match(/\/([^\/]+)\/LC_MESSAGES\/.*\.mo$/) && !FastGettext.default_available_locales.include?($1)
FastGettext.default_available_locales << $1
end
end
Language and Country Separator in locale name
Rails native localization support uses I18n module for translation support. The problem is that it uses dash (-) separator between langugage and country code in locale names.This makes a problem when using with standard gettext locale schema which uses underscore (_) as the separator. For example translations from rails-i18n gem will not be found when the current locale in en_US, it expects en-US locale.
The problem can be solved by defining locale fallbacks like this (put this to config/initializers/fast_gettext.rb file):
# enable fallback handling I18n::Backend::Simple.include(I18n::Backend::Fallbacks) # set some locale fallbacks needed for ActiveRecord translations # located in rails_i18n gem (e.g. there is en-US.yml translation) I18n.fallbacks[:"en_US"] = [:"en-US", :en] I18n.fallbacks[:"en_GB"] = [:"en-GB", :en] I18n.fallbacks[:"pt_BR"] = [:"pt-BR", :pt] I18n.fallbacks[:"zh_CN"] = [:"zh-CN"] I18n.fallbacks[:"zh_TW"] = [:"zh-TW"] I18n.fallbacks[:"sv"] = [:"sv-SE"]
Including source file name and line number is the final POT file
By default when you run 'rake gettext:find' task to collect the translatable string the output will not contain the source file name and the line number. It's very useful if you get a feedback from translator (like a typo in the original message) then you don't have to scan all file but you immediately know where to fix the problem.If you want to change this behavior and include the line numbers add this configuration to config/initializers/fast_gettext.rb file:
# configure default msgmerge parameters (the default contains "--no-location" option # which removes code lines from the final POT file) Rails.application.config.gettext_i18n_rails.msgmerge = ["--sort-output", "--no-wrap"]
Sorting messsages in the final POT file
The 'rake gettext:find' task sorts the messages in the final POT file alphabetically. The advantage is that if you add a new string and regenerate the file then the files will be similar and the diff will be small.The problem is that the sorting is done at the merge step, when merging the new found translation wit the old ones. At the very first run (when the final POT file does not exist yet) the merge step is skipped and thus the messages are not sorted. This can be fixed by starting the task once more (the second run will find existing messages and do the merge with sorting).
But the problem is that you can easily forget to run the task for the second run. The workaround is to create an empty target POT file when the it doesn't exist yet. Unfortunately simple touch command is not sufficient (msgmerge failed for me with some strange UTF-8 error), we have to create valid POT but without any messages.
The workaround it to put this code to lib/tasks/gettext.rake file:
# 'gettext:find' sorts the messages alphabetically only when it is merging existing messages
# copying empty pot file from the template forces sorting even at the first run
namespace :gettext do
task :create_pot_template do
FileUtils.cp("locale/template.pot", "locale/textdomain.pot") unless File.exists?("locale/textdomain.pot")
end
end
# add task dependency
task :'gettext:find' => :'gettext:create_pot_template'
# SOME DESCRIPTIVE TITLE. # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER # This file is distributed under the same license as the PACKAGE package. # FIRST AUTHOR <email@address>, YEAR. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: version 0.0.1\n" "POT-Creation-Date: 2012-01-16 17:56+0100\n" "PO-Revision-Date: 2012-01-16 17:56+0100\n" "Last-Translator: FULL NAME <email@address>\n" "Language-Team: LANGUAGE <ll@li.org>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=INTEGER; plural=EXPRESSION;\n"
Automatic translation in HAML files
It is possible to extend HAML parser to automatically translate all plain text strings. The advantage is than you don't have to explicitly use _() function and you cannot forget to mark a text to translation.This can be done using this code snippet. Save it to a file, remove the require calls at the beginning (they are obsoleted and do not work with new gettext) and require it in your ApplicationController.
Then you need to add support to 'rake gettext:find' task. Save this code snippet to lib/haml_parser.rb file. You need to replace require 'gettext/parser/ruby' by require 'gettext/tools/parser/ruby' so it works with newer gettext gem.
Then put this to lib/tasks/gettext.rake file:
# extend the HAML parser to extract plain text messages
# to support automatic translations (without need to mark the text with _())
namespace :gettext do
task :haml_parser do
require 'haml_parser'
end
end
# extend the HAML parser before collecting the translatable texts
task :'gettext:find' => :'gettext:haml_parser'
Tuesday, October 11, 2011
OpenSUSE Hackweek VII - Hacking USB Joysticks in YaST
Introduction
This hackweek I spent playing with joysticks in YaST and hwinfo (libhd).
YaST already has a module for configuring joysticks, but I only supported Gameport joysticks which are quite obsoleted these days.
AFAIK all recent mainboards do not have gamport connectors (just a pin header) or the gameport is completely missing. And if you want to buy a joystick you will find only USB models anyway.
There was a note in the YaST module that it only supports Gameport joysticks but some users find it confusing.
So I decided to change the situation and do something interesting during my Hackweek project - to add USB joystick support to YaST.
Hacking
The support in YaST actually has three parts. YaST uses libhd (from hwinfo package) for hardware detection, than there is yast2-hardware-detection package which is a libhd wrapper converting C functions and data to YCP (the main YaST language) and finally there is yast2-sound package which contains the joystick configuration module.
The first step was to add USB joystick support to hwinfo so it could be used for joystick detection. The problem was that hwinfo found the USB joystick device but it didn't know that it's a joystick and reported it as an unclassified generic USB device and also the joystick result was empty:
# hwinfo --usb [...removed not relevant info...] 12: USB 00.0: 0000 Unclassified device [Created at usb.122] Unique ID: JPTW.MyFI+3nAFw7 Parent ID: FKGF.4Nx_qoDfSd7 SysFS ID: /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3/2-1.3:1.0 SysFS BusID: 2-1.3:1.0 Hardware Class: unknown Model: "KYE Flight2000 F-23 Joystick" Hotplug: USB Vendor: usb 0x0458 "KYE Systems" Device: usb 0x1004 "Flight2000 F-23 Joystick" Revision: "1.02" Driver: "usbhid" Driver Modules: "usbhid" Device File: /dev/input/event5 Device Files: /dev/input/event5, /dev/input/by-id/usb-0458_4-axis_8-button_joystick-event-joystick, /dev/input/by-path/pci-0000:00:1d.0-usb-0:1.3:1.0-event-joystick Device Number: char 13:69 Speed: 1.5 Mbps Module Alias: "usb:v0458p1004d0102dc00dsc00dp00ic03isc00ip00" Config Status: cfg=no, avail=yes, need=no, active=unknown Attached to: #8 (Hub) # hwinfo --joystick #
So the detection code was there, it just needed small improvement. This was rather easy.
Then I checked also hwinfo --joystick output, it was fine.
Then I put an old low-end sound (Sound Blaster 128 PCI) with gameport into my PC and connected an old analog joystick. The old YaST joystick module worked fine I and I configured it.
Then I checked hwinfo --joystick output again and the analog joystick was not found. It turned out that the hwinfo code actually could never detect any joystick. So I also added Gameport support and fixed Gameport joystick detection.
So at this point I had working joystick detection, but I wanted to improve it a little bit. I wanted detect and report some joystick properties, like number of buttons and axes it has. This turned out to be similar to mouse button detection which already worked fine. So again not a big problem.
The detection part was ready, then I just added passing joystick details into the yast2-hardware-detection layer so it could be used from YaST.
The most complicated part was the YaST joystick module itself because it supported only gameport joystick and USB joysticks could not be simply added to the UI and also the internal structure had to be completely rewritten.
The Outcome
So what has been changed?
The hwinfo --joystick output will contain all detected joysticks (both USB and Gameport):
# hwinfo --joystick 24: USB 00.0: 10d00 Joystick [Created at usb.122] Unique ID: o2Ga.iGyiCvRqXrA Parent ID: FKGF.4Nx_qoDfSd7 SysFS ID: /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.7/2-1.7:1.0 SysFS BusID: 2-1.7:1.0 Hardware Class: joystick Model: "KYE Flight2000 F-23 Joystick" Hotplug: USB Vendor: usb 0x0458 "KYE Systems" Device: usb 0x1004 "Flight2000 F-23 Joystick" Revision: "1.02" Driver: "usbhid" Driver Modules: "usbhid" Device File: /dev/input/event6 (/dev/input/js1) Device Files: /dev/input/event6, /dev/input/js1, /dev/input/by-id/usb-0458_4-axis_8-button_joystick-event-joystick, /dev/input/by-path/pci-0000:00:1d.0-usb-0:1.7:1.0-event-joystick, /dev/input/by-id/usb-0458_4-axis_8-button_joystick-joystick, /dev/input/by-path/pci-0000:00:1d.0-usb-0:1.7:1.0-joystick Device Number: char 13:70 Speed: 1.5 Mbps Module Alias: "usb:v0458p1004d0102dc00dsc00dp00ic03isc00ip00" Buttons: 8 Axes: 6 Config Status: cfg=no, avail=yes, need=no, active=unknown Attached to: #20 (Hub) 25: Gameport 00.0: 10d00 Joystick [Created at input.316] Unique ID: pJ6W.6RgETWGhHg1 Parent ID: i_aO.F2uWXyTiEa3 SysFS ID: /pci0000:00/0000:00:1e.0/0000:04:02.0/gameport0/input/input58 Hardware Class: joystick Model: "Analog 4-axis 4-button joystick" Vendor: 0x0001 Device: 0x000f "Analog 4-axis 4-button joystick" Device File: /dev/input/event5 (/dev/input/js0) Device Files: /dev/input/event5, /dev/input/js0, /dev/input/by-path/pci-0000:04:02.0-event-joystick, /dev/input/by-path/pci-0000:04:02.0-joystick Device Number: char 13:69 Buttons: 4 Axes: 4 Config Status: cfg=no, avail=yes, need=no, active=unknown Attached to: #16 (Multimedia audio controller)
The changes are highlighted: it correctly finds the joystick, reports number of axes and buttons, /dev/input/jsX device name is reported, game port joystick is found and for game port joysticks it reports also the sound card to which it is attached to.
The changes in the YaST module are best described by the following screen shots. Let's start with the old YaST module:
![]() |
| The old YaST module with one configured Gameport joystick |
![]() |
| When the computer doesn't have any game port the old module displayed just this message although an USB joystick could be attached. |
![]() |
| Old joystick test dialog, notice the wrong number of buttons and axes, also using progress bars is not appropriate for this dialog |
Here is the new updated YaST module:
![]() |
| Both USB and Gameport joysticks are displayed with more details |
As a bonus I have added hotplug handling into the joystick module - if you plug or unplug any USB joystick the table get refreshed. AFAIK that is unique feature among all YaST modules...
All these changes have been submitted to Factory/12.1 and should be available in 12.1-RC1 when released.
Friday, September 2, 2011
Improved Disk Usage Estimation in YaST Installer
Disk Usage
YaST installer estimates used disk space in the final installed system. This is possible thanks to the disk usage metadata in installation repository (located in file suse/setup/descr/packages.DU.gz).
This file contains disk usage statistics for every package, so YaST needs just to sum them for all selected packages. (Actually it's slightly more complicated, the disk usage is stored per directory, so YaST/libzypp has to sum it up according to the proposed disk partitioning. Imagine you have separate /usr or /boot partition...)
The Problem
This works well, but the problem is that the final sum does not match the real value you find after installation is completed.
For example in openSUSE-12.1-M3 in default KDE installation the installer estimates this disk usage:
But if you install the system and check the real disk usage you will find these numbers:
So the difference between estimated and real available free space is about 800MB! That's quite a lot!
In this case it was not a problem, but if the target partition was smaller, YaST could tell that there would be e.g. 500MB free space but the installation would actually fail because of not enough free space. This problem was reported several times in Novell bugzilla, e.g. bnc#263275, bnc#495251 and more.
Improvement
So where is the extra space spent? Why it doesn't match? There are basically these reasons:
Current State
I have added all the above mentioned extra space into the YaST installer (except the FS fragmentation, that is hard to implement and would not significantly change the estimation.)
The most difficult task was to figure out the default journal size depending the partition size. I had to look to the respective mkfs utility sources. Some options (like reserved space) might be also set in the YaST partitioner so the space calculation has to read and check the partitioning options.
If you are interested in the implementation details the relevant commit can be found in http://lists.opensuse.org/yast-commit/2011-08/msg00377.html
Result
After patching the installer the estimated sizes (for the same installation) are:
This pretty matches the real disk usage mentioned above. It's not exactly the same, but it's a big improvement. And it actually will never be perfect as it will be always a guess (just more or less good).
The improvement has been submitted to Factory and will be available in openSUSE-12.1-Beta.
To Do
The only thing which is missing is Btrfs support.I'll have to check the mkfs.btrfs utility or Btrfs documentation. So far I have found out that after formatting 8GB partition using Btrfs df reports about 7.2GB free space. I have to found out how the final free space corresponds to the partition size. Moreover Btrfs supports transparent file compression, snapshots, etc. which also make the estimation more complicated...
If you have any note on this feature just add a comment to this blog post. Thank you!
YaST installer estimates used disk space in the final installed system. This is possible thanks to the disk usage metadata in installation repository (located in file suse/setup/descr/packages.DU.gz).
This file contains disk usage statistics for every package, so YaST needs just to sum them for all selected packages. (Actually it's slightly more complicated, the disk usage is stored per directory, so YaST/libzypp has to sum it up according to the proposed disk partitioning. Imagine you have separate /usr or /boot partition...)
The Problem
This works well, but the problem is that the final sum does not match the real value you find after installation is completed.
For example in openSUSE-12.1-M3 in default KDE installation the installer estimates this disk usage:
Free: 3.3GB
Used: 3.1GB
Total: 6.4GB
Used: 3.1GB
Total: 6.4GB
But if you install the system and check the real disk usage you will find these numbers:
# df -h / Filesystem Size Used Avail Use% Mounted on /dev/sda2 6,4G 3,7G 2,5G 61% /
So the difference between estimated and real available free space is about 800MB! That's quite a lot!
In this case it was not a problem, but if the target partition was smaller, YaST could tell that there would be e.g. 500MB free space but the installation would actually fail because of not enough free space. This problem was reported several times in Novell bugzilla, e.g. bnc#263275, bnc#495251 and more.
Improvement
So where is the extra space spent? Why it doesn't match? There are basically these reasons:
- Files not owned by any package - the repository metadata contains just disk usage for files owned by packages (the files which are in RPMs), it doesn't and cannot know anything about files which are created at runtime outside of RPM package files.
The files are mainly (with usual size in default installation)- RPM database (contains info about the installed packages): 42MB
- Zypp cache (contains info about the configured software repositories): 38MB
- System logs: 14MB
- Config backup files: 10MB
- Kernel initrd: 10MB
- ... and many more small files, but they almost don't affect the overall size so they can be ignored
- File system fragmentation - space is allocated in blocks, so small files effectively take more space than their total size. (ReiserFS is an exception, it supports tail joining.)
- File system's journal - modern file systems use journaling so the file system is in consistent state after system crash or power failure. On the other hand the journal takes some space, for example default Ext3/Ext4 journal size is 128MB (but it can be smaller, depending on partition size and block size). The journal decreases the usable free space.
- Reserved space for root user - Ext file systems by default reserve 5% space for root user. RPM explicitly checks for non-root space (even if it is running as root and could actually use the space), the reserved space also decreases the usable free space.
Current State
I have added all the above mentioned extra space into the YaST installer (except the FS fragmentation, that is hard to implement and would not significantly change the estimation.)
The most difficult task was to figure out the default journal size depending the partition size. I had to look to the respective mkfs utility sources. Some options (like reserved space) might be also set in the YaST partitioner so the space calculation has to read and check the partitioning options.
If you are interested in the implementation details the relevant commit can be found in http://lists.opensuse.org/yast-commit/2011-08/msg00377.html
Result
After patching the installer the estimated sizes (for the same installation) are:
Free: 2.6GB
Used: 3.8GB
Total: 6.4GB
Used: 3.8GB
Total: 6.4GB
This pretty matches the real disk usage mentioned above. It's not exactly the same, but it's a big improvement. And it actually will never be perfect as it will be always a guess (just more or less good).
The improvement has been submitted to Factory and will be available in openSUSE-12.1-Beta.
To Do
The only thing which is missing is Btrfs support.I'll have to check the mkfs.btrfs utility or Btrfs documentation. So far I have found out that after formatting 8GB partition using Btrfs df reports about 7.2GB free space. I have to found out how the final free space corresponds to the partition size. Moreover Btrfs supports transparent file compression, snapshots, etc. which also make the estimation more complicated...
If you have any note on this feature just add a comment to this blog post. Thank you!
Labels:
disk usage,
free space,
yast
Monday, April 18, 2011
Installing latest Intel graphics driver to openSUSE 11.4
(Edit: The bug has been fixed in openSUSE update repository, you do not need to compile the driver manually anymore, just install the latest update for xorg-x11-driver-video package.)
I have upgraded my home PC to Intel i5-2500K CPU (Sandy Bridge family). The CPU has a new integrated graphics core (Intel HD 3000) and it works out-of-box in openSUSE-11.4 including 3D and composition. The only problem I noticed are broken popup menus and buttons in title bars in KDE. Esp. broken popups are very annoying as they are hardly usable, see e.g. https://bugs.freedesktop.org/attachment.cgi?id=45061.
Fortunately Intel has released updated X driver version 2.15 which fixes this problem. Here is a step by step how to install the updated driver in openSUSE 11.4.
Maybe someone can pack the driver into a RPM package in the openSUSE build service, but for me this solution is sufficient...
I have upgraded my home PC to Intel i5-2500K CPU (Sandy Bridge family). The CPU has a new integrated graphics core (Intel HD 3000) and it works out-of-box in openSUSE-11.4 including 3D and composition. The only problem I noticed are broken popup menus and buttons in title bars in KDE. Esp. broken popups are very annoying as they are hardly usable, see e.g. https://bugs.freedesktop.org/attachment.cgi?id=45061.
Fortunately Intel has released updated X driver version 2.15 which fixes this problem. Here is a step by step how to install the updated driver in openSUSE 11.4.
- Install xorg-x11-server-sdk package
sudo zypper in xorg-x11-server-sdk
- Download http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.15.0.tar.bz2
- Unpack the archive
tar xfjv xf86-video-intel-2.15.0.tar.bz2
- Now compile the driver:
cd xf86-video-intel-2.15.0
(If you have installed 32-bit system then use /usr/lib path in the second command.)
./configure --prefix=/usr --libdir=/usr/lib64
make - Install the driver (will overwrite the files from RPM package)
sudo make install
- Restart the X server (simply relogin to a new session)
Maybe someone can pack the driver into a RPM package in the openSUSE build service, but for me this solution is sufficient...
Thursday, September 16, 2010
openSUSE Conference 2010
This year the openSUSE conference takes place 20-23 October in Nürnberg, Germany. See more details and the schedule here. I'll have a presentation and a workshop there. I don't have the final plan yet ready so here I'd like to ask for your opinions in advance. If you have any idea or if you are interested in a specific topic for the presentation or the workshop let me know via comments below.
WebYaST - Presentation
My plan is to do a similar presentation as I had at LinuxTag event this year. But because here I'll have more time (+15 minutes) I'll show more details and I'll show how to install it in openSUSE-11.3.
Developing RoR Application in NetBeans - Workshop
Because I'm developing WebYaST using Netbeans IDE I'd like to share some nice tips and tricks how to make developing of Rails apps better. I used VIM for editing (and I still use it for non-Rails work) but I wanted something better. Of course, there is a rails plugin for VIM but that didn't help me much. Then I tried NetBeans and I was pleased by the features it has.
So this workshop will be rather an introduction to possibilities of NetBeans and if you are using a plain text editor for Rails development you should definitely come and see it.
I'm still thinking about the content - what application should we use for this session? We could use WebYaST but we could also start from scratch generating a very simple Rails app... I guess I'll leave it on the attendees to decide what they want to hack on, I'll prepare both possibilities... And of course, if you already have your own app you could use it.
WebYaST - Presentation
My plan is to do a similar presentation as I had at LinuxTag event this year. But because here I'll have more time (+15 minutes) I'll show more details and I'll show how to install it in openSUSE-11.3.
Developing RoR Application in NetBeans - Workshop
Because I'm developing WebYaST using Netbeans IDE I'd like to share some nice tips and tricks how to make developing of Rails apps better. I used VIM for editing (and I still use it for non-Rails work) but I wanted something better. Of course, there is a rails plugin for VIM but that didn't help me much. Then I tried NetBeans and I was pleased by the features it has.
So this workshop will be rather an introduction to possibilities of NetBeans and if you are using a plain text editor for Rails development you should definitely come and see it.
I'm still thinking about the content - what application should we use for this session? We could use WebYaST but we could also start from scratch generating a very simple Rails app... I guess I'll leave it on the attendees to decide what they want to hack on, I'll prepare both possibilities... And of course, if you already have your own app you could use it.
Monday, June 14, 2010
WebYaST at Linuxtag 2010
LinuxTag - June 9-12, 2010
This year I took part of the LinuxTag event in Berlin. It is the biggest Linux and Open Source event in Germany and probably in Europe. See more details here.
Booths
There were many booths at the event, every major distribution like openSUSE, Gentoo, Ubuntu... had a booth were users could try the latest version and talk with the developers.
And you could also meet people from interesting projects like KDE, FFmpeg, XBMC and so on. I found interesting the demos which showed Linux in embedded devices or there were even robots running Linux.
Presentations
I hadn't much time to visit the presentations but I visited a presentation about Communtu, which is a web server where you can build your customized DVD Ubuntu image. You can add a software bundle which is not included in Ubuntu by default. So you don't have to search for additional repositories and install packages from them.It's somewhat similar to SUSE Studio, but with less features and targeted to Ubuntu users.
WebYaST
I had a talk about WebYaST which a new web based remote management for Linux.It's a an open source project and it's a successor of YaST.
The main difference between YaST and WebYaST is that WebYaST is a web application in contrast to YaST which is a standard desktop application. WebYaST is accessed via a web browser.
Another difference is that WebYaST supports access control, so you don't have to use the root account for managing the remote machine, you can use any regular user provided the he/she has the access right granted via PolicyKit.
In WebYaST we try reusing the existing code from YaST if possible, but we want to have the YaST dependency as small as possible so for example installing patches is done via PackageKit.
You can find more details in the slides which I made available online using slideshare.net service or at the main WebYaST wikipage.
I thought that there could have been more attendees in my talk, but the hall was really big and even relatively big group of people seemed small there. Anyway, the presentation was successful in my opinion and I hope I spread a word about WebYaST...
If you visited my presentation and have a comment about it please write it below. Thank you for any feedback!
Wednesday, June 3, 2009
Renaming a Rake task
Rake has a class for creating packaging task which builds a compressed package from the sources. It's called Rake::PackageTask and it's quite easy to use it, see the documentation.
Unfortunately the name of the created task is package and it's hardcoded so it cannot be changed.
Yast uses make and the standard targets are package and package-local.
We wanted to use the same targets in the Web Yast which uses Ruby on Rails and Rake as the make replacement.
The problem is how to change the package task name. In Ruby it's possible to change or extend even the core classes like String or Object, which might be good or bad because you can break all Ruby applications very easily... But this feature allow us to extend Rake as we need.
The following code adds rename method to Rake::Task class:
And an example how to use it:
It was quite difficult to figure out the rake internals, so I hope it will help somebody else...
Unfortunately the name of the created task is package and it's hardcoded so it cannot be changed.
Yast uses make and the standard targets are package and package-local.
- package-local - build a tarball source package
- package - does some checks (like SVN repository update check, syntax check, runs the testsuite...) to ensure that the built package follows some rules so it will less likely break something.
We wanted to use the same targets in the Web Yast which uses Ruby on Rails and Rake as the make replacement.
The problem is how to change the package task name. In Ruby it's possible to change or extend even the core classes like String or Object, which might be good or bad because you can break all Ruby applications very easily... But this feature allow us to extend Rake as we need.
The following code adds rename method to Rake::Task class:
# add rename_task method to Rake::Application
# it has an internal hash with name -> Rake::Task mapping
module Rake
class Application
def rename_task(task, oldname, newname)
if @tasks.nil?
@tasks = {}
end
@tasks[newname.to_s] = task
if @tasks.has_key? oldname
@tasks.delete oldname
end
end
end
end
# add new rename method to Rake::Task class
# to rename a task
class Rake::Task
def rename(new_name)
if !new_name.nil?
old_name = @name
if old_name == new_name
return
end
@name = new_name.to_s
application.rename_task(self, old_name, new_name)
end
end
end
And an example how to use it:
# rename 'package' task to 'package-local' task
Rake::Task[:package].rename(:"package-local")
It was quite difficult to figure out the rake internals, so I hope it will help somebody else...
Labels:
rake,
rename task,
ruby,
ruby on rails
Monday, May 18, 2009
Debugging Ruby on Rails Application
How to debug a Ruby on Rails application?
I needed to debug a Ruby on Rails application which I just have started to develop. I put some logging commands to the code but it's not as good as using a full debugger for inspecting internal data at runtime.
What's needed?
For debugging a Rails application ruby-debug gem is needed. It can be installed by command sudo gem install ruby-debug in Linux or as a package from an installation repository.
How to start the debugger?
At first, the place in the application where the debugger should be started must be marked by debugger keyword.
Then the application must be started in the debugger - it's simple, just use --debugger option of the starting script, e.g. script/server --debugger.
How to use the debugger?
When the application executes debugger command it stops and a debugger session is opened in the terminal.
It supports these basic commands:
l (line) - print the source script
c (continue) - stop the debug session at continue executing the application
bt (backtrace) - print the execution stack (which functions were called)
n (next) - execute the next command
s (step) - execute the next command, step inside a function
h (help) - will list more available commands with details
Moreover it's possible to use normal ruby commands to print or inspect the current objects, using e.g. object.class, objec.inspect methods. And it's also possible to modify the current variables, just use var = value command.
This makes the debugger really powerful, it's far better than simple puts command!
I needed to debug a Ruby on Rails application which I just have started to develop. I put some logging commands to the code but it's not as good as using a full debugger for inspecting internal data at runtime.
What's needed?
For debugging a Rails application ruby-debug gem is needed. It can be installed by command sudo gem install ruby-debug in Linux or as a package from an installation repository.
How to start the debugger?
At first, the place in the application where the debugger should be started must be marked by debugger keyword.
Then the application must be started in the debugger - it's simple, just use --debugger option of the starting script, e.g. script/server --debugger.
How to use the debugger?
When the application executes debugger command it stops and a debugger session is opened in the terminal.
It supports these basic commands:
l (line) - print the source script
c (continue) - stop the debug session at continue executing the application
bt (backtrace) - print the execution stack (which functions were called)
n (next) - execute the next command
s (step) - execute the next command, step inside a function
h (help) - will list more available commands with details
Moreover it's possible to use normal ruby commands to print or inspect the current objects, using e.g. object.class, objec.inspect methods. And it's also possible to modify the current variables, just use var = value command.
This makes the debugger really powerful, it's far better than simple puts command!
Labels:
debug,
debugging,
ruby,
ruby on rails
Subscribe to:
Posts (Atom)







