August is a busy month for birthdays!

This all starts with openSUSE, on August 9th. Seven years ago, the development of SUSE Linux opened up and openSUSE was born. The openSUSE project is actually pretty young, compared to the other projects delivering distributions. But it has 20-years old roots... I joined the project in February 2008, and I've seen the community grow and become more and more involved and, more importantly to me, in charge.

On August 15th, we celebrate the birthday of the GNOME project. Miguel announced the GNU Network Object Model Environment Desktop project fifteen years ago. I'm happy the letters in GNOME don't stand for anything anymore ;-) It's been a long ride, with the great GNOME 1.0 release in 1999 (let's be honest, it was crappy by today's standards — I tried GNOME back then, and quickly gave up), the GNOME 2.0 release in 2002 (I joined the project around that time, I still remember the excitement in the community) and the recent GNOME 3.0 release in 2011 (I can't believe I wrote the 3.0 plan more than three years ago already...). Even though I'm less involved nowadays, GNOME is my family.

And finally, on August 16th, Debian reaches a new milestone. In 1993, the imminent release of the first version was announced, which makes the project nineteen years old now. I've always loved Debian, and I've long wondered whether I should become a Debian Developer, but I never made the jump as I chose to focus on upstream activities instead for my free time. And then I joined openSUSE. But it's never too late, so who knows, maybe one day...

I use what those three projects deliver daily, literally. Many thanks to everyone who made and still make this possible!

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

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

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>

Short version

• If you can't reach me at my @cgoncalves.info, use @cgoncalves.pt from now on.
• Google Apps doesn't allow one to switch a primary domain with an alias. Had to migrate all data by myself...

A not so short version

Migrating emails

#!/bin/bash

imapsync \

--host1 imap.gmail.com \

--user1 account@old-domain.com \

--passfile1 ./passfile1 \

--ssl1 \

--host2 imap.gmail.com \

--user2 account@new-domain.com \

--passfile2 ./passfile2 \

--ssl2 \

--authmech1 LOGIN \

--authmech2 LOGIN \

--useheader 'Message-Id' \

--useheader 'X-Gmail-Received'

Back to Google Apps drama

Conclusion

The KR49 repo holds KDE SC 4.9 packages for openSUSE users. For information on how to update please refer to the openSUSE wiki.

UPnP support was disable for the KR49 packages since it causes lots of crashes (if Windows shares are present on the network) and seems unmaintained within KDE, i.e. no fix to look forward to.

Kudos

Packaging-wise kudos go to Todd, Nico and everybody else doing the packaging in KR49.  If you find any packages missing in KR49 compared to KR48 please submit them via the buildservice or  drop a note on the opensuse-kde mailinglist.

KDE-wise I would like to thank especially Laurent Montel who contributes a lot to fixing-up kmail2, including adding email backup and import functionality. András Manţia is another developer who helps to get kmail2 into shape and re-worked the filtering for 4.9.  (There are of course many more who contribute to KDE!) Since AFAIK both work for KDAB, it is good to see that there are still developers payed to work on KDE while most distros seem to overload their so called KDE-team with non-KDE stuff, resulting in little or no contribution to KDE and just enough time to get packaging done, if at all.

Things I noticed with KDE SC 4.9 so far

In dolphin one can now add extra information to the main view, i.e. next to each item. Actually a nice feature. The sad thing is that it only works for indexed folders. The user cannot know about this and is presented with lots of “-” below each icon instead of just not showing anything if there is nothing to show. Enabling the additional information will block dolphin’s GUI for some time proportional to the amount of items in the current folder. Indexing still has some issues, e.g. nepomuk re-indexes movie and some sound files after every log-in. On top of that instead of just checking the length etc. it reads the whole file, i.e. hundreds of MB just to  start all over again after the next log-in.

The places pane presents some new items, i.e. you can add searches to it. While some default searches do not seem to be of any use, i.e. e.g. just list all audio files or pictures from all over the computer, the time-related queries can be quite useful if you are willing to invest the GB needed to build up an index for 70 000 files.

Regarding mail loss, the bugs were unfortunately not fixed yet for online IMAP. There are two issues. a) You lose email if you move it to a local folder and the internet connection breaks down while kmail2 is still downloading the message. b) You also lose email if you pipe the emails in your imap folders through external apps such as bogofilter. For the latter a workaround exists. If you open the properties of the imap folders and enable “always retrieve full message” you will not lose emails because of piping unless a) kicks in.

Apper seems to become more stable. While it still suffers from a – let’s say – incomplete zypper backend for PackageKit on openSUSE, it lets PackageKit processes die within reasonable time and does not block zypper forever anymore.