If you are new to the zypper-upgraderepo plugin, give a look to the previous article to better understand the mission and the basic usage.

Repository check

The first important change is inherent the way to check a valid repository:

• the HTTP request sent is HEAD instead of GET in order to have a more lightweight answer from the server, being the HTML page not included in the packet;
• the request point directly to the repodata.xml file instead of the folder, that because some server security setting could hide the directory listing and send back a 404 error although the repository works properly.

Check just a few repos

Most of the times we want to check the whole repository’s list at once, but sometimes we want to check few of them to see whether or not they are finally available or ready to be upgraded without looping through the whole list again and again. That’s where the –only-repo switch followed by a list of comma-separated numbers comes in help.

–only-repo switch

All repo by default

The disabled repositories now are shown by default and a new column highlights which of them are enabled or not, keeping their number in sync with the zypper lr output. To see only the enabled ones just use the switch –only-enabled.

Table view

Report view

Beside the table view, the switch –report introduce a new pleasant view using just two columns and spanning the right cell to more rows in order to improve the number of info and the reading quality.

Report view

Other changes

The procedure which tries to discover an alternative URL now dives back and forth the directory list in order to explore the whole tree of folders wherever the access is allowed by the server itself. The side effect is a general improvement also in repo downgrade.

The output in upgrade mode is now verbose and shows a table similar to the checking one, giving details about the changed URLs in the details column.

The server timeout error is now handled through the switch –timeout which allows tweaking the time before to consider an error any late answer from the server itself.

Final thoughts and what’s next

This plugin is practically completed, achieving all the goals needed for its main purpose no other relevant changes are scheduled, so I started thinking of other projects to work in my spare time.

Among them, there is one I am interested in: bring the power of openSUSE software search page to the command line.

However, there are some problems:

• This website doesn’t implement any web API so will be a lot of scraping job;
• There are missing packages while switching from the global research (selecting All distribution) to the specific distribution;
• Packages from Packman are not included.

I have already got some ideas to solve them and did lay down several lines of code, so let’s see what happens!

This tool started as a personal project when a day I was in the need to upgrade my distro quicker than using a traditional ISO image, Zypper was the right tool but I got a little stuck when I had to handle repositories: some of them were not yet upgraded, others changed slightly in the URL path.

Who knows how to Bash the problem is not exactly a nightmare, and so I did until I needed to make a step further.

The result is zypper-upgraderepo Ruby gem which can be integrated as a zypper plugin just installing the zypper-upgraderepo-plugin package.

Installing zypper-upgraderepo-plugin

Installing zypper-upgraderepo-plugin is as easy as:

1. Adding my repo:
   sudo zypper ar https://download.opensuse.org/repositories/home:/FabioMux/openSUSE_Leap_42.3/home:FabioMux.repo
2. Install the package:
   sudo zypper in zypper-upgraderepo-plugin

How to use it

Sometime we want to know the status of current repositories, the command zypper ref does a similar job but it is primarily intended to update the repository’s data and that slow down a bit the whole process.
Instead we can type:

$ zypper upgraderepo --check-current


To know whether or not all the available repositories are upgrade-ready:

$ zypper upgraderepo --check-next


As you can see from the example above all the enabled repositories are ready to upgrade except for the OSS repo which has a slightly different URL.

# The URL used in the openSUSE Leap 42.3
http://download.opensuse.org/distribution/leap/42.3/repo/oss/suse/
# The suggested one for openSUSE Leap 15.0
http://download.opensuse.org/distribution/leap/15.0/repo/oss/


Let’s try again overriding the URL without make any real change:

$ zypper upgraderepo --check-next \
--override-url 8,http://download.opensuse.org/distribution/leap/15.0/repo/oss/


Once everything is ok, and after performed a backup including all the repositories, it’s time to upgrade all the repository at once:

$ sudo zypper upgraderepo --upgrade \
--override-url 8,http://download.opensuse.org/distribution/leap/15.0/repo/oss/


Conclusions

That’s all with the basic commands, more information is available in the wiki page of zypper-upgraderepo gem where all the commands are intended with the only use of the gem, but installing the plugin they are also available as zypper subcommands like shown above, also a man page is available as

$ zypper help upgraderepo


wxRuby is an old but working library based on wxWidgets toolkit, till some day ago the dependency from SWIG 1.3.38 and some small errors raised during the manual compilation, made the use of this library the worst nightmare for beginners who was looking for a fast approach to GUI based programming in Ruby.

After some day spent to investigate about a possible upgrade of the SWIG dependency to the current 2.0 version, i produced some patches to fix this and the other annoying compiling errors, and finally, thanks to the Buildservice infrastructure, a wxRuby RPM compiled from sources with the relative patches are now availables for all openSUSE users!

As far i googled this should be the first distro to have a precompiled and working wxruby gem among its repositories (being compiled from sources the gem is generated for 32 and 64 bits architecture from Buildservice itself), so Rubyists take a look on software.opensuse.org, select the package coming from my home project account and enjoy!

With current YaST, plenty of tasks that system administrator could image are doable using understandable UI: creating users, bootloader configuration, network setup and even Apache configuration. However, it has its drabacks. While being do-it-all tool, it comes with large package dependency even for only simple tasks. It is largely written in an outdated language which has its roots in last century and only few people in the world know it. It lacks the testing abilities of modern languages. It is SUSE specific and lacks larger developer community.

So last year, we (actually, Josef) came with the idea for YaST++: new configuration library that could be a common layer for configuration tools in SUSE (and beyond). Such library should provide simple and understandable API for all tools around. Written in up-to-date language many people know and like, so they can join the development (spoiler: we chose Ruby). Offering bindings  to various other languages, so different tools could benefit from it,

Now, this “YaST++” does not actually mean to be replacement of current YaST (with its Qt/GTK/ncurses UI), but it could replace the lower layer of YaST, which is doing the real system configuration. And it would be open for other library users as well: the obvious targets for now are WebYaST and SUSE Studio, but we’d like to see if other tools are interested: even from non-SUSE world.

From architecture point, YaST++ is itself divided into two layers, we call them YLib and config agents. YLib is the high-level library, providing the API (like ‘create user’, ‘set new time zone’ etc.). Config agents form the lower layer, that is actually touching the system. This low level consits of D-BUS services, which are running as a root (thus have the full access to the system) but are started only for users with proper permissions (we are using polkit for policies definition). So YaST++ offers role based access management, where specific users can be allowed to do specific sets of actions. For more, check our architecture document (still WIP).

We’ve started to work on several modules (none of them is finished, though). Let’s look at example in module for users configuration (packages yast++lib-users and config_agent-passwd). Look at example code in ‘users_read’ script of examples subdirectory. With simple ruby call of

YLib::Users::read({})

you get the list of current users. If the script gets additional parameters, it can list e.g. all data about selected user, or only specific information about all:

> ./users_read root
{“gid”=>”0”, “name”=>”root”, “uid”=>”0”, “shell”=>”/bin/bash”, “password”=>”x”, “home”=>”/root”}

> ./users_read only name
{“result”=>[“Batch jobs daemon”, “User for Avahi”, “bin”, “Daemon”, “dnsmasq”, “FTP account”, “Games account”, “User for haldaemon”, “User for OpenLDAP”, “LightDM daemon”, “Printing daemon”, “Mailer daemon”, “Manual pages viewer”, “User for D-Bus”, “MySQL database admin”, “News system”, “user for nginx”, “nobody”, “NTP daemon”, “User for build service backend”, “openslp daemon”, “PolicyKit”, “Postfix Daemon”, “PulseAudio daemon”, “qemu user”, “Router ADVertisement Daemon for”, “root”, “RealtimeKit”, “Smart Card Reader”, “user for smolt”, “SSH daemon”, “NFS statd daemon”, “Novell Customer Center User”, “TFTP account”, “usbmuxd daemon”, “Unix-to-Unix CoPy system”, “WWW daemon apache”, “User for YaST-Webservice”, “LXDE Display Manager daemon”]}

YaST++ developement is in its early stage (even the name is not final), but we already have something to offer.

Check the code and documentation at github project. There’s already a simple tutorial for those who want to try writing new parts.

Download packages from Build Service project.

Comment/propose/oppose in public YaST mailing list.

class T
  def test
    puts "test"
  end

  def lest
    puts "lest"
  end

  def m
    test
  end
end


T.new.m
T.send(:define_method,:m_a) { lest }
T.send(:alias_method, :m_old, :m)
T.send(:alias_method, :m, :m_a)
T.new.m
T.send(:alias_method, :m, :m_old)
T.send(:undef_method, :m_a)
T.send(:undef_method, :m_old)
T.new.m

as you can see after modification class is exact same as before ( except if there is method a, but it is possible to handle it via introspection and dynamic choose of method). I don’t need to change whole stack of calls to add parameter or introduce new singleton class which can have flag.
I hope it help someone with his fix of not so well written piece of software.

• ActiveResource Behavior
• Actively maintained ( and will be due to SLMS support )
• Tightly developed with guys from studio team
• Well documented with yard
• Good test coverage

I think then a lot of glory words is better to show example. It is example based on example from documentation.
Example goal is simple. Create new appliance in studio, add own cool rpm and build appliance with it. It can be useful to test your new version of software in stable environment and have automatic appliance in which you can test it.

  require 'rubygems'
  require 'studio_api'

  # Fill up Studio credentials (user name, API key, API URL)
  # See https://susestudio.com/user/show_api_key if you are using SUSE Studio online
  connection = StudioApi::Connection.new('user', 'pwd', 'https://susestudio.com/api/v1/user')
  # Setup the connection for all ActiveResource based class
  StudioApi::Util.configure_studio_connection connection

  # Find template with KDE4 for SLE11SP1
  templates = StudioApi::TemplateSet.find(:all).find {|s| s.name == "default" }.template
  template = templates.find { |t| t.name == "SLED 11 SP1, KDE 4 desktop" }
  # clone template to new appliance
  appliance = StudioApi::Appliance.clone template.appliance_id, :name => "New cool appliance", :arch => "i686"
  puts "Created appliance #{appliance.inspect}"

  #add own rpm built agains SLED11_SP1
  File.open("/home/jreidinger/rpms/cool_rpm-1.0-1.60.noarch.rpm","r") do |f|
    StudioApi::Rpm.upload f, "SLED11_SP1"
  end
  # and choose it in appliance ( and of course add repository with own rpms)
  appliance.add_user_repository
  appliance.add_package "cool_rpm", :version => "1.0-1.60"
  #check if appliance is OK, like dependency problems with new rpm
  if appliance.status.state != "ok"
    raise "appliance is not OK - #{appliance.status.issues.inspect}"
  end
  
  build = StudioApi::RunningBuild.new(:appliance_id => appliance.id, :image_type => "xen")
  build.save
  build.reload
  while build.state != "finished"
    puts "building (#{build.state}) - #{build.percent}%"
    sleep 5
    build.reload
  end

  final_build = StudioApi::Build.find build.id
  puts "Appliance to download: #{final_build.download_url}"

So I hope that you like interface how I design it. Of course I welcome any suggestion how to improve it. You can use comments here, novell bugzilla or issues on github.
How to install it:

• In opensuse: 1-click for 11.3 and 1-click for factory
• alternative possible everywhere is to use
  gem install studio_api

At the end few useful links if you are interested:
repository on github
yard documentation
gem at rubygems.org

Thanks for attention and I welcome any comments

Usually need install the wxGTK libraries and the gem wxruby (or wxruby-ruby19 if using ruby 1.9) and start creating your own scripts.

$ sudo zypper in wxGTK wxGTK-gl
$ sudo gem install wxruby

But sometimes we could find an Error for a wrong compatibilty between the installed version of the wxGTK libraries and the wrapper library included in the gem.

/usr/lib/ruby/gems/1.8/gems/wxruby-2.0.1-x86-linux/lib/wxruby2.so:
symbol _ZN13wxAuiNotebook14ShowWindowMenuEv, version WXU_2.8.5 not defined in file libwx_gtk2u_aui-2.8.so.0 with link time reference -
/usr/lib/ruby/gems/1.8/gems/wxruby-2.0.1-x86-linux/lib/wxruby2.so

When an error like this appear, the unique solution is recompile the gem.

What we need:

• rubygems: Tool for manage the ruby’s gems;
• rake: the Ruby’s version of the popular make, will help us to compile wxRuby;
• wxGTK, wxGTK-gl, wxGTK-devel: Library and headers needed for run our scripts and produce the object’s file;
• SWIG: Build the wrapper classes in Ruby from the C++ sources, wxRuby 2.0.1 need the version 1.3.8;
• gcc-c++: The C++ compiler used for build the wrapper library;
• wxRuby: We have to download the source’s package directly from Rubyforge.

Added the repository which contains the Ruby extensions (warning to the portion of the address that refers the version of openSUSE), we can proceed with the installation confirming the request of the dependent packages:

$ sudo zypper ar http://download.opensuse.org/repositories/devel:/languages:/ruby:/extensions/openSUSE_11.3/ RubyExtensions
$ sudo zypper ref
$ sudo zypper install rubygems rubygem-rake gcc-c++ wxGTK-devel rubygem-ffi-swig-generator make

It’s time to download the sources of SWIG version 1.3.38 from sourceforge, then uncompress and install it:

tar -xvf swig-1.3.38.tar.gz
cd swig-1.3.38
./configure && make
sudo make install

All the packages are ready, we have to set some environment variables before continue:

export SWIG_CMD=/usr/local/bin/swig
export WXRUBY_EXCLUDED=GLCanvas
export WXRUBY_VERSION=2.0.1

The second instruction is important for ignore all the references to the openGL library, which are not availables in unicode version.

The next step is download the wxRuby’s source from Rubyforge and start to compile

tar -xvf wxruby-2.0.1.tar.gz
cd wxruby-2.0.1
rake

After this procedure end you can remove the old gem and build & install the new:

rake gem
sudo gem install wxruby-2.0.1-x86-linux.gem

Personally, I needed recompile wxRuby in openSUSE 11.2; with the new version (11.3) standard packages work fine, anyway i wished share my experience for someone could meet the same trouble in the future :))