Home Home > 2012
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

Archive for 2012

How kiwi can help to cleanup your system

September 25th, 2012 by

After some iterations of updating the system with zypper dup or yast and some years of service with the system you will find out that there is a lot of dust which is obsolete or has been forgotten. Recently I had the problem that I need to move my 32bit system to a 64bit system and thus the way to go was to migrate the running system into an image description, build a 64bit image from it and install that on the 64bit machine. But the most important part was to cleanup the running system and find out what it really contains. The report kiwi migrate created here was helpful and so I think it might be helpful for others too. Just call:

kiwi –migrate mySystem

It will end up with some data below /tmp/mySystem which of course can be removed at any time without any risk. Most interesting is the html report generated which you can view with any browser. So far kiwi collects the following information:

  • kernel version and kernel specific kmp packages
  • hardware dependent packages
  • installed gem packages
  • repository checkouts
  • rpm packages installed multiple times
  • rpm packages which could not be found according to the current repo setup including version and repo information
  • tree of modified files, packaged but changed
  • tree of custom files, those which doesn’t belong to any package or other part of the bullet list

basically the use case of kiwi migrate is to migrate the running system into an appliance description but I’m not there yet. There is still room for improvement but I think it still can help to cleanup the system and to see what is installed on the system and not managed by a package manager

I have tested this since openSUSE 11.4

Remember to have fun 🙂

Updates for openSUSE Edu Li-f-e

September 15th, 2012 by

With the release of openSUSE Edu Li-f-e 12.2, we also have new KDE waiting in the official update repository. To resolve a couple of conflicts you will need to add Education:update repository before running yast2 online_update.

Follow these steps:

- Add Education:update repository by using this 1-click install, remain subscribed to the suggested repositories or via command line:
  zypper ar obs://Education:update/openSUSE_12.2 Education:update then run yast2 online-update.
 - select replacement for kioaudiocd
 - select deinstallation of yast2-qt-branding-life
 - Proceed with the update

Announcing the release of openSUSE Edu Li-f-e 12.2

September 14th, 2012 by

openSUSE Education team once again presents Li-f-e (Linux for Education) built on hot new openSUSE 12.2 including all the post release updates. As always this edition of Li-f-e comes bundled with a lot of softwares useful for students, teachers, as well as IT admins of educational institutions. Apart from stable versions of KDE and Gnome, Cinnamon is also available.Sugar desktop suite makes a comeback thanks to the work of Xin Wang packaging it. Li-f-e also give full multimedia experience right out of the box without having to install anything extra. The live installable DVD iso stands at 3.3G as an incredible array of softwares from open source world are available on it, we have not just bundled them in, but have tried to integrate it with the distribution to give everything a seamless feel.

(more…)

live-fat-stick

September 13th, 2012 by

So you got a bunch of different openSUSE 12.2 live isos downloaded, to test them on a real machine you have to either burn them to CD/DVD or create live USB stick. Creating CD/DVD is a total waste after booting it once or twice. Creating bootable USB stick is a better thing to do, however openSUSE Hybrid iso creates USB stick that is not usable for any other purpose and the remaining space is locked till you make another partition, and even then the partition is not available on windows(tm).

(more…)

openSUSE Conference 2012 – How to build RPMs

September 4th, 2012 by

Don’t forget to bring your friends!

Editing KIWI configurations with Emacs

August 31st, 2012 by

I recently decided to do all my work in emacs and even though the learning speed is a bit slow, I thought I would share what I discoverd regarding editing the KIWI config files. Kiwi has the schema file for the elements and their attributes but unfortunately by default Emacs is unaware of it’s schema location. So first create a schema location file as below and save it.

<locatingRules xmlns="http://thaiopensource.com/ns/locating-rules/1.0">
<transformURI fromPattern="*.xml" toPattern="*.rnc"/>

<uri pattern=”*.kiwi” typeId=”KIWI”/>
<typeId id=”KIWI” uri=”/usr/share/kiwi/modules/KIWISchema.rnc”/>
</locatingRules>

I saved it as $HOME/.emacs.d/data/myschemas.xml. Now add this to your Emac’s init file for autoloading the nxml mode for kiwi files in addition to the xml files

(setq auto-mode-alist
(cons '("\\.\\(xml\\|kiwi\\|xsl\\|rng\\|xhtml\\)\\'" . nxml-mode)
auto-mode-alist))

and add this code for nxml mode to locate the kiwi schema file when you edit a kiwi config file

(eval-after-load 'rng-loc
'(add-to-list 'rng-schema-locating-files (concat user-emacs-directory "data/myschemas.xml")))

Now have fun with Emacs, Kiwi and your openSUSE

Testing LTSP on openSUSE 12.2

August 23rd, 2012 by

With openSUSE 12.2 almost here, we have been working hard to get LTSP experience on this release better than ever. Thanks to the power of KIWI and some great scripting by Alex Savin, KIWI-LTSP has a lot of new features and improvements.

Here is how to get started:

(more…)

osc2: syntax update

August 16th, 2012 by

Hi,

as I already I wrote in an earlier post the last week I worked on implementing osc2’s “request”
command. In order to create a new submit request the user has to run
osc request create --submit api://src_project/src_package api://tgt_project
What’s still needed is a way to specify a revision of the src_package. It isn’t possible
to introduce a “–revision ” option because it’s possible to specify multiple submit
actions for a request (so we can’t distinguish to which –submit action a revision
belongs to).
Finally I implemented darix’ cool idea: simply use a svn-like syntax:
osc request create --submit api://src_project/src_package@rev api://tgt_project

Marcus

[gsoc] osc2 client – summary of week 12

August 15th, 2012 by

Hi,

here’s a small summary of the 12th (coding) week. The last week I continued
the work on the new user interface. As a result the “request” command is more
or less implemented. Yesterday I pushed the current code and it’s also possible
to play around with it:

  • checkout the code [1]
  • cd osc2/osc/cli
  • export PYTHONPATH=/path/to/osc2
  • python cli.py -h (for more information)

Example:
In order to list a request it is sufficient to run
“python cli.py request api://your_project” (Note: all https requests are
_insecure_ – so far the certificate etc. is not checked).

Some implementation details:
In my last mail/post I described how a new (sub)command can be specified
so I’ll leave out the details here.
In the following I’ll shortly explain how the arguments specified by the
user at the commandline are passed to a function (which does the actual
work – like listing the requests).


class RequestList(CommandDescription, Request):
    """
    ...
    """
    cmd = 'list'
    args = 'api://project?/package?'
    opt_user = Option('U', 'user', 'list only requests for USER')
    func = call(request.list)

As we can see the project and package parameters are optional. After
the parsing process a so called “info” object is returned which encapsulates
the specified arguments. Assume the user runs “request list api://test_prj”
then the info object has the following attributes:


    info.apiurl = the default apiurl
    info.project = 'test_prj'
    info.package = None

The question is how can we pass this data to the request.list function?
A simple (and naive) approach would be to simply pass the “info” object
to the request.list function that is “list” has the following signature
“def list(info)”. As a consequence inside the method we always have to
use “info.project”, “info.package” etc. which is a bit awkward – at least
for parameters which are quite frequently used in the method definition.

So it would be nice if there’s a way to pass frequently used parameters
directly to the method (that is they’re declared as formal parameters
in the method definition) and infrequently used parameters can still be
accessed via the info object. Exactly like this it is currently
implementend in osc2.

So the following signatures would be correct for our example:


    def list(project, package, info)
    def list(project, package, user)
    def list(project, package, user, info)
    def list(project, info)
    def list(info, project)
    def list(project)  # using the info object is not mandatory
    def list()  # quite useless...
    ...

Invalid signatures:


    def list(prj, pkg, info)
    def list(foo, info)
    ...

So it is up to the developer how to define the signature of the
request.list function – it is not completely dictated by osc:)

Marcus

[1] https://github.com/openSUSE/osc2

[gsoc] osc2 client – summary of week 11

August 7th, 2012 by

Hi,

here’s a small summary of the 11th (coding) week. Last week I worked on
implementing the new commandline interface. While doing so I faced several
“issues”:

  • How to combine argparse and our oscargs url-like syntax?
    Basically we have to run our oscargs parser on the result which is
    returned by argparse.ArgumentParser’s parse_args method. The problem is
    that both parsers have a different “syntax” that is using a naive approach
    will lead to some redundancies (we specify the ui twice: one time for
    argparse and one time for oscargs). In order to avoid this we need some
    “interface” to which the oscargs syntax is passed and which configures
    the argparse parser accordingly.
  • How to support custom commands?
    We also have to provide an “easy” way to specify custom commands.
    Additionally it might be handy if existing commands can be enhanced
    (either by adding additional options etc. or by adding a new subcommand
    etc.). The best would be if the user simply drop his/her plugins in a
    specific directory and osc will scan this directory and use the new
    plugins/commands.
  • Specifying the ui programmatically is somehow confusing/cluttered. It would
    be much better if the ui can be specified in a more “declarative” way
    without the syntactic “overhead” (well that’s a bit exaggerated) which
    is needed to configure the parser. Additionally it would be nice to have
    a convenient way to specify a multi line description for a command
    (hardcoding the str into the source makes the code “harder” to read).

Finally I ended up with a small DSL which can be used to specify the
ui in a “declarative” way (the initial idea + syntax is taken from the
django framework (see [1])).

Example:
Assume we want to implement a request command which consists (for the
sake of simplicity) of 2 subcommands “list” and “accept”. This can be
specified like the following:


# file: osc/cli/request/ui.py

class Request(CommandDescription, OscCommand):
     """Show and modify requests."""
     cmd = 'request'

class RequestList(CommandDescription, Request):
     """List requests.

     By default open requests for a specific project or package will be
     listed.

     Examples:
     osc request list api://
     osc request list api://project
     osc request list api://project/package

     """
     cmd = 'list'
     args = 'api://project?/package?'
     opt_user = Option('U', 'user', 'list only requests for USER')
     opt_group = Option('G', 'group', 'list only requests for GROUP')
     opt_state = Option('s', 'state', 'list only requests with state STATE',
                        choices=['new', 'review', 'accepted', 'revoked',
                        'declined', 'superseded'], action='append')
     func = request_list

class RequestAccept(CommandDescription, Request):
     """Accept a specific request.

     ...

     """
     cmd = 'accept'
     args = 'api://reqid'
     func = request_accept

In order to add the request command it is sufficient to add an

     import osc.cli.request.ui

statement to the main cli module. This produces the following output:

marcus@linux:~/osc2/osc/cli> python cli.py request -h
usage: cli.py request [-h] {list,accept} ...

Show and modify requests.

positional arguments:
  {list,accept}
    list         List requests.
    accept       Accept a specific request.

optional arguments:
  -h, --help     show this help message and exit
marcus@linux:~/osc2/osc/cli>


and

marcus@linux:~/osc2/osc/cli> python cli.py request list -h
usage: cli.py request list [-h]
                           [-s {new,review,accepted,revoked,declined,superseded}]
                           [-G GROUP] [-U USER]
                           api://project?/package?

List requests.

    By default open requests for a specific project or package will be
    listed.

    Examples:
    osc request list api://
    osc request list api://project
    osc request list api://project/package

positional arguments:
  api://project?/package?

optional arguments:
  -h, --help            show this help message and exit
  -s {new,review,accepted,revoked,declined,superseded}, --state {new,review,accepted,revoked,declined,superseded}
                        list only requests with state STATE
  -G GROUP, --group GROUP
                        list only requests for GROUP
  -U USER, --user USER  list only requests for USER
marcus@linux:~/osc2/osc/cli>

How does it work?
First of all each class which defines a command or subcommand has to inherit
from class “CommandDescription”. If a subcommand is to be defined it also
has to inherit from the “parent” command (that is in our example “RequestList”
and “RequestAccept” inherit from class “Request” (which in turn inherits from
class “OscCommand” (from this class all toplevel commands have to inherit))).
In short: with the help of the inheritance hierarchy it is possible to define
a command <- subcommand hierarchy.

Note: actually the classes "RequestList" and "RequestAccept" only inherit
from "CommandDescription". The "parent" command base class is only needed
for a "marking" purpose (it is filtered out with the help of a metaclass
when the concrete class is "constructed" – I'll leave out the details for
now and may write a dedicated blogpost about it).

Now the remaining task is to define and implement the commands (note: we will
definitely not finish the project on the "suggested pencils down" date and
use the week until the "firm pencils down" date for coding…).

Marcus

[1] https://docs.djangoproject.com/en/1.4/topics/db/models

Here’s a small example how to modify an existing command:

# plugins/myrequestaccept.py
from osc.cli.description import Option
import osc.cli.request.ui

class MyRequestAccept(osc.cli.request.ui.RequestAccept):
     # add a new option
     opt_foo = Option('f', 'foo', help='foo option')

This leads to

marcus@linux:~/osc2/osc/cli> python cli.py request accept -h
usage: cli.py request accept [-h] [-f FOO] api://reqid

positional arguments:
  api://reqid

optional arguments:
  -h, --help         show this help message and exit
  -f FOO, --foo FOO  foo option
marcus@linux:~/osc2/osc/cli>