Meson ♥ xmlrpc-c

xmlrpc-c is a lightweight RPC library based on XML and HTTP. For quite some time it’s outdated in Fedora (currently we have 1.32.5 which is older than stable/1.43.06 and even older than super-stable/1.39.11) so I started taking a look why.

Enrico Scholz, previous maintainer of xmlrpc in Fedora, did porting to CMake in 2007 and was supporting it until 2013 and even tried to get it in upstream, but upstream developer didn’t even reply (probably there was some communication, but not in public place). So version of xmlrpc-c we have in Fedora uses this patch-set. Because he gave up on maintaining cmake port and was not anymore interested in maintaining this package it’s oudated and not maintained.

Why not just drop this patch and use upstream’s buildsys? “Current buildsystem is broken and nearly unfixable except for the upstream author.” says Enrico and I tend to agree with him. It’s one of worst buildsystems I have ever seen (it’s common among scientists).

I started rebasing cmake port, but after 15 mins I gave up checking what each macro does there. It’s way better that original one, but cmake doesn’t really make your life easier, so I stopped wasting time and started my own meson port. It took me quite a while to make working meson port, most of the time I spent trying to understand how this make-ish thing generates particular library or even which libraries it generates. So, here it is:

What did I achieve?

  • Cross-compilation for free.
  • Support for all OS out of the box (this is a bit lie since I tested only on linux, but it’s fairly simple to adapt for others). In original build-sys to build on windows you have to manually change some configs, run some different scripts and etc.
  • Maintainable build-sys code (1k of human-readable code vs 5k of function-over-function-with-shell-and-make).
  • Faster compiling. I can’t say that original build-sys is slow (actually it’s very fast since it doesn’t use libtool and all other automake stuff), but with meson I got it ~2 times faster.

What I didn’t achieve (yet?)

  • Building tests, examples, tools (in my TODO list since it’s required for my update in Fedora).
  • Building wininet-client and libwww-client (I’ve never heard about these before and not sure if anyone uses them, so it’s not in my TODO list at this moment).
  • Push changes upstream (once I finish complete porting, I will try to get it upstream).

Funny (actually, no) thing I found in lib/expat/xmltok/Makefile:

# I can't figure out what XML_BYTE_ORDER is, but it doesn't look like the
# code has ever defined it.  That means it's treated like 0 in #if.  Since
# we started using the Gcc -Wundef option, that generates a warning, so
# se set it explicitly to 0 here.


I hope that upstream developer (Bryan Henderson) can make opposite of title so that not only Meson will ♥ xmlrpc-c, but also in opposite way ;). This will make people (package maintainers in first place) happy.

A bit more technical information…
Continue reading →

Building packages in COPR with own settings

Let’s start from some story behind. Let’s look at createrepo_c, it supports building with/without DRPM library. In RPM spec file we have:

%if 0%{?rhel} && 0%{?rhel} <= 7
%bcond_with drpm
%bcond_without drpm

%if %{with drpm}
BuildRequires:  drpm-devel

Which means on RHEL8+ and other distros it will require at the build-time drpm-devel which is correct, and will not require it on RHEL7-. We don’t have drpm package in RHEL7- so it’s correct.

Now I want to build createrepo_c with drpm support for RHEL7 on COPR. I already built drpm there, but createrepo_c will not use drpm because %bcond_with disables option by default and allows you to enable it. Unfortunately (or fortunately) there is no way to pass parameters like --with drpm to COPR like to rpmbuild.. So we need to create package with RPM macros which will enable this option for us. Let’s create it!

Name:           drpm-rpm-macros
Version:        1
Release:        1%{?dist}
Summary:        RPM macros to enable DRPM

License:        Public Domain

BuildArch:      noarch
Provides:       drpm-macros = %{version}-%{release}


We have on EL7 and below %bcond_with drpm, but we want to enable DRPM.

%autosetup -c -D -T

# Nothing to build

mkdir -p %{buildroot}/%{_rpmconfigdir}/macros.d/
echo '%_with_drpm 1' > %{buildroot}/%{_rpmconfigdir}/macros.d/macros.drpm


* Tue Apr 12 2016 Igor Gnatenko <> - 1-1
- Initial package

Now we need to create src.rpm for this package and submit for building to the COPR. Once it’s done we need to modify buildroot options to always install this package. Just open settings of the project, click edit button on interesting chroot (in my case it’s epel-7-x86_64), add drpm-rpm-macros to the packages line and save. In all next builds in this chroot you will have drpm-rpm-macros installed automatically.

Now we can submit building of createrepo_c without any changes and it will be built with enabled drpm feature.

Retro ThinkPad Survey 4: Miscellaneous


Please keep the feedback coming! Click here to take survey 1, here to take survey 2 or here to take survey 3 if you have not responded yet.

You can take survey 4 by clicking here.

“Next week I’ll post a recap of the results and discuss where we are on the project so far. Thanks again for all the passion and time you have put into this effort. We are listening.” © David Hill

Read more

How-to set up network audio server based on PulseAudio and auto-discovered via Avahi

Today i played with my cubietruck and wanted to make network audio server. I just open laptop, connect to WiFi, choose remote sound device in gnome-control-center and listen music.

First of all I’d want to say many thanks to Jonas Wielicki for help with debugging problems and providing his ansible playbook with the same task, Stefan Majewsky who inspired Jonas about configuration management and to Felipe Sateler for tip with permissions.

Server configuration

I have installed minimal Fedora so it means that I don’t have avahi, pulseaudio and other tools in system. Let’s install them:

# dnf install pulseaudio pulseaudio-module-zeroconf avahi

Continue reading →

GUADEC presentation preview: compiling GNOME apps with the Meson build system

If you talk with software developers, sooner or later the topic drifts to tools. The most obvious one is the editor. People really love their editors and are happy to talk about the wonderful features they have and how they increase productivity. The second tool is the compiler, which also receive a lot of praise. The compilers we have today are massively better, faster and more powerful than ones from just 10 years ago. And then there’s the build systems, which are, well…

Sort of tolerated. Maybe. Ish.

The time has come to change that. Meson is a new build system that has been designed from the ground up for one purpose: to increase programmer productivity. The basic tenet is that every second spent writing build definitions is a second wasted, because that time and energy could instead have been spent on code. Every second spent waiting for the build system to do its work is likewise wasted. To demonstrate how Meson tackles this issue, here’s the full definition for building an executable with an external dependency:

project('sampleproject', 'c')
glib = dependency('glib-2.0')
executable('prog', 'prog.c', dependencies : glib)

This is all the developer needs to write. The build system takes care of the grunt work such as debug flags, cross compilation, dependency tracking and so on.

In addition to general features, Meson also has special support for tools used in GNOME development. These include GResources, GObject introspection and the like. This simplicity does not come at the expense of power, as compile times with Meson can be an order of magnitude less than with the Leading Brand build system.

If this has piqued your interest then do come to GUADEC presentation on Sunday, or, if you can’t wait that long, learn about the project yourself at

See you in a few weeks,

Retro ThinkPad Survey 2: Displays, Keyboard, and More

Many of us using ThinkPad (Lenovo or IBM) from day to day, because it’s really comfortable, durable and etc. But new models got some design changes (probably good, but bad for me) like non-hardware-buttons for trackpoint, added trackpad. In previous week David Hill posted first announce and survey about Retro ThinkPad. Users should choose their preferences about keyboard, trackpoint/trackpad, monitor, resolution and etc. and we will get new model with old features (like 7-row keyboard) but with new hardware. Now it’s time to second announce and survey. If you have not completed first survey – please complete it also.

Read original