DBus Interface of Amarok2

"Without music, life would be a mistake." - Friedrich Nietzsche

This time I want to write a short article about something completely different than AutoYaST or anything in that area.
Since I switched to KDE4 with amarok2, my little now-playing scripts for amarok and xchat did not work anymore. The interface to query amarok for the data was changed from dcop to dbus and so I had to google a bit and rewrite the eMail-signature script for kmail and write a new little script for xchat too.
So, how to squeeze the information out of the new amarok2? It's quite easy:

qdbus org.kde.amarok /Player GetMetadata

and that's it. qtbus is part of the libqt4 package and you'll get an output of everything that is interesting and that you can parse easily. Here is my little xchat2 script for example:

#!/usr/bin/perl

use strict;

Xchat::register("wumprock","1.0","Amarok xchat info");
IRC::print("Wumprock 1.0 for XChat \cB\cC3loaded\cC0 :)");
IRC::add_command_handler("curplay", "cmd_amacurplay");

sub cmd_amacurplay {
    my $META = `qdbus org.kde.amarok /Player GetMetadata`;

    my ($ARTIST) = ( $META =~ /artist: (.*)/  ? $1 : "-" );
    my ($TITLE)  = ( $META =~ /title: (.*)/   ? $1 : "not playing" );
    my ($ALBUM)  = ( $META =~ /album: (.*)/   ? $1 : "-" );
    IRC::command("/me is now playing '$TITLE' by '$ARTIST'");
}

You can use /cur_play then in xchat to let everyone who cares (and not) know what you are listening to.

I have a smilar script for kmail to, so I can add the "now playing:" line under my signature but it looks quite the same and so I'll not paste it here.·

happy listening - Uwe

Static Text in Ask dialogs with openSUSE 11.2

With openSUSE 11.2 you can use a new feature of the famous ask-dialogs in AutoYaST. You can add static text to a dialog that requires no user interaction.
That makes it possible for you to put some explanation between widgets or you can create a popup that contains only a text and has to be confirmed like "press okay to start the installation".

<ask>
   <question></question>
   <type>static_text</type>
   <dialog config:type="integer">1</dialog>
   <element config:type="integer">1</element>
   <default><![CDATA["I know a man who gave up smoking, drinking, sex,
and rich food. He was healthy right up to the time
he killed himself."

Johnny Carson
]]>
  </default>
</ask>

happy autoyasting - Uwe

AutoYaST and SLP on openSUSE 11.2

Tell it to me and I will forget.
Show it to me and I might remember.
Make me do it and I will know.
Konfucius

Since openSUSE 11.2 AutoYaST supports the SLP. With autoyast=slp you can tell AutoYaST to query via SLP where it can find the profile. So for example, you can burn a DVD with "autoyast=slp" in the isolinux.cfg file and you can use that DVD in different network topologys then because the location of the autoyast profile is configured on the SLP server in the network. Here is a little example section from my /etc/slp.reg file:

# autoyast
service:autoyast:http://192.168.0.1/my_autoyast.xml,en,65535

AutoYaST will fetch the my_autoyast.xml file then from 192.168.0.1 via http. Of course it's not necessary that the SLP server is running on 192.168.0.1 too.
Another cool feature you get when using SLP is that you can choose between different profiles. If AutoYaST gets more than one profile location from the SLP server it pops up a dialog box to let you choose the right profile:

# /etc/slp.reg
# simple
service:autoyast:http://10.10.0.162/part1.xml,en,65535

# lvm
service:autoyast:http://10.10.0.162/part3.xml,en,65535

have a nice week

bye, Uwe

Why to Confirm? (Part 2)

"Anyone who has never made a mistake has never tried anything new." - Albert Einstein

Last week I started with an article about debugging the autoinstallation process. This week I want to publish the second part of it.

Debug scripts
If something with your self written scripts seems to go wrong, you can turn on the debugging of that scripts with the

<script>
    <debug config:type="boolean">true</debug>
    <feedback config:type="boolean">true</feedback>
    ...
</script>

options. If you don't turn on the feedback option, you won't see a popup but you'll still find the logs of your scripts in the /var/adm/autoinstall/logs/ directory. With feedback turned on, you'll see the log in a popup too that has to be confirmed.

Debugging the ask-dialogs
When you use the ask-dialogs and you want to test it without booting into the installation system, you should extract the complete <ask> part from the profile and store it in an own XML file. You can test the dialogs now with:

yast2 ayast_setup setup filename=/tmp/my_ask.xml

That requires that all <stage> entries in an ask-question are set to "cont" (the default is "initial"). If the <stage> is missing or set to "initial", you won't see anything with the help of "ayast_setup" because those dialogs are only raised up in stage one.
Be aware of the fact that all second stage parts of this XML file are really executed. So if there are some post-scripts in your XML for example, those will be executed too and depending on what you do in your scripts, you might end up with a slightly rearranged system :-)
ayast_setup is a very cool part of AutoYaST that can not only be used to debug your ask-sections (or any other second stage section), but also to configure a complete system with an AutoYaST profile from inside the running system (here is a nice article about it).


Problems with rules
If you use the rules feature to create a profile dynamically, you have some options for debugging too. If you want to see the values of the pre-defined rules (like "memsize", "karch", "mac" ....) you can run the client:

/usr/lib/YaST2/bin/y2base ayast_probe ncurses

You can run it in the installation system (by switching to the console via CTRL+ALT+F2 for example) or in an already installed system too (yast2 ayast_probe).
If you are using custom rules based on a shell script written by you, you can run those scripts to see how they behave in the installation environment. They are stored in /tmp/YaST2-...../rule_.... files. You can grep for that tmp dir via

grep 'Writing rule script into' /var/log/YaST2/y2log

That requires that yast has started at least once and autoyast has fetched the XML profile.
If you don't have problems with the rules scripts, but with the merging, you can merge the XML files like AutoYaST would do it to view the result:

/usr/bin/xsltproc --novalid --param replace "'false'" \
    --param dontmerge1 "'package'" \
    --param with "'a.xml'" --output out.xml \
    /usr/share/autoinstall/xslt/merge.xslt base.xml

The dontmerge parameter can be specified in your rules.xml too (see also the merging documentation).

remote logging
if you want to transfer your logfiles (including y2log messages) to a loghost, you can simply pass the parameter "loghost=10.10.0.162" to your linuxrc parameter list. Of course you need network for that (netsetup=1) and your loghost has to accept log messages from the network (for syslog-ng that requires a udp(ip("0.0.0.0") port(514)); in the config file).

If you want to use a serial console for remote logging, pass the following to your linuxrc parameter list:

earlyprintk=ttyS0,115200 console=ttyS0,115200

115200 might be too much for your system so you might have to reduce it and ttyS0 is hardware dependent of course (might be ttyS1 or so on your system). On the remote system you might want to use screen like screen /dev/ttyS0 115200 then.

Still stuck?
If you are still stuck, you can always write a mail to the AutoYaST mailinglist (you have to subscribe to that list if you want to send mails to it).
It's always a good idea to read the FAQ too.

have fun debugging :-)

ciao, Uwe Gansert