Using openSUSE Build Service (OBS)

This is a small article is for programmers who want their application run on different Linux distributions.
OpenSUSE Build Service (OBS) offers such a service where  programmers can compile their applications for various Linux distributions. OBS offers a web client and command line tool.
In this article I only describe how to use the web client to compile a Qt application for some openSUSE versions.
The challenge for this job is to find the right Qt packages and define an appropriate spec file, because unfortunately a standard distribution by default does not deliver all the Qt packages needed for a compilation.

Create a package

The first step is to create a login and a project at OBS.
Done, the next step is to create a package for your application. After creating your package your should see it in the package list in the Overview section. In this example its … Example 😉



Now you can select some repositories i.e. Linux distributions you want to build your application for.  As you can see there a already some repositories activated. This is why these repositories are defined in the 1st Package.

By clicking Add repositories a form appears where you can select and deselect the repositories your application should run on.

If the selected repositories provides all libraries your application needs for a compilation, all is done here.

Add an extra path to the repository

Sometimes a repository does not provide all the libraries needed by your application, in this case you have to add a special path where the build process can find all the libraries needed.

To add a new path to first click on

A dialog form appears where  you can click   The form for adding an additional path appears. Adding a new path is a little bit tricky, because the root directory for looking for additional path is /repositories/ . For example if you need libraries from Qt5.9 you have put KDE:Qt5.9into the form.  This points to  Repository: is selected automatically. finally you can add the path to the repository.

Modify the .spec file

The next step is to modify the spec file.  In this section I only point to some pitfalls you may trap into if you want to use a remote repository.

A word on meta data tag  Version: this is tricky because you can define a variable %{version} by %define version 1.0.0  or setting the meta tag  Version:   1.0.0in which setting the meta tag is the appropriated way. Then you define your buildroot BuildRoot: %{_tmppath}/%{name}-%{version}-build
This works fine if your .tar.gz file follows the standard syntax myapp-1.0.0.tar.gz

This may not work if you omit a version number in your .tar.gz file or you load your package from a remote repository e.g. from github. In this cases %{version} is set automatically.

This means the build process will overwrite the %{version} variable defined by the Version: tag and this may cause some errors where it’s used: e.g.  build path is not found.

So, in this case you leave the tag Version:      empty but don’t leave if out.

If you want to make your package available for multiple distributions you normally have to set some conditions. Especially on openSUSE the distribution numbering is not very consistent so you better have look at this site to checkout how to make it.

Interesting links

Enable RFID/NFC reader on Dell laptops

Some Dell Laptops have a Broadcom 5880 chip set which controls all the smart card and fingerprint readers installed. On Windows there are some tools you can use to work with the RFID-card reader. On linux you can use libchipcard, opensc and openct.

By default the NFC communication is disabled. To enable it first you have to turn in the Bios menu. Enable PM Security under the Security section.

After doing this you use the RFID-card reader only for Dell special authentication issues. Read this article for more information.

For using the contactless reader in your own applications you have to disable the „CV Only Radio Mode“. To do this for your Linux box you have to do the following.

1. Create a DOS bootable USB-Stick

Follow the instructions on this website

2. Get the required software

Download the file Broadcom_Unified-Security-Hu_A07_R210234.exe from this location

Rename Broadcom_Unified-Security-Hu_A07_R210234.exe to

mv Broadcom_Unified-Security-Hu_A07_R210234.exe

unzip it to a directory


copy the DOS folder to the usb stick

cp -R DOS /path/to/usbstick

3. Disable CV-mode

Boot your laptop from the prepared usb stick without any driver (4th menu point)

Enter into the DOS folder

cd DOS

Check chip status

ushdiag -u -stat

you should see something like this

RFID Radio: Present; Enabled 
RFID: Not Locked CV Only Radio: Enabled

We have to disable „CV Only Radio“

ushdiag -u -dd 4

Now ushdiag -u -stat should show

RFID Radio: Present; Enabled
RFID: Not Locked
CV Only Radio: Disabled

If something goes wrong call

ushdiag -h

this shows all the options available

4. Test NFC-reader on Linux

Before you can run a test you have to install the following packages:

    • pcscd
    • pcsc-tools
    • opensc
    • openct

When everything went fine, on Linux you should do the following:

Start pcscd daemon, this depends on your Linux distribution. On opensuse type

rcpcscd start

When you call

opensc-tool -l

you should see something like this

# Detected readers (pcsc) Nr.  Card  Features  Name 
0    No              Broadcom Corp 5880 [Contacted SmartCard] (0123456789ABCD) 00 00 
1    No              Broadcom Corp 5880 [Contactless SmartCard] (0123456789ABCD) 01 00

When you put a an NFC-Card over the reader and your output is like this

# Detected readers (pcsc)
Nr.  Card  Features  Name
0    No              Broadcom Corp 5880 [Contacted SmartCard] (0123456789ABCD) 00 00
1    Yes             Broadcom Corp 5880 [Contactless SmartCard] (0123456789ABCD) 01 00

everything works fine 🙂

This work is based on this articles:


Programming SOAP


This is a short tutorial that is dedicated to help PHP programmers who get in trouble connecting a SOAP-service using the native php5 soap functions.

This part describes how to check a SOAP-call on a command line. If you have trouble connecting a SOAP-Service you should do this first, to ensure you have created a valid SOAP-Request.

To check if your soap-request is well-formed, put it into a file e.g. soaptest.xml and check it with xmllint
xmllint soaptest.xml

If everything is ok, the program will output the file content, otherwise it will throw an error message.

When there appears no error, the second step is to check if the soap-request will produce a response without errors. To check this out we can use the curl program.
Sometimes you have to send several requests to the soap-server. To simplify the requests we create a curl config file (e.g. soapheader.txt) with the appropriate parameters:

header = "Content-Type: text/xml; charset=utf-8"
header = "SOAPAction: urn:<uri to soap-function>"
data = "@soaptest.xml"
url = "<url to soap-service>"

Do the test request:

curl -K soapheader.txt

to format the output we can use xmllint again

curl -K soapheader.txt | xmllint --format -

If you are lucky you will receive a soap-response and if you are very lucky the xml-response is what you expected.
Otherwise there appears no response or rather no output, this occurs when your request produces a server error. To have a look to the server response you can dump the header information to a file (e.g. header.txt):

curl -K soapheader.txt -D header.txt

With this information you should be able to solve your problems 😉