1. Start: Waiting for yumcache lock

    Have you ever tried to build a package under Fedora (or RHEL)? Did you used “mock” for it? If you answered “yes” to both questions I have a task for you: do 2 or 3 builds at SAME time…

    Curses, curses and other ugly words will start in your mind. I have no idea why in days of multiple cpu cores and gigabytes of memory “mock” tool forces users to do one build at time. Sure, there are ways to make several builds at same time but all sucks. And I am going to write why and compare it to “pbuilder” from Debian world.

    Ok, so what “mock” is? It is a tool which do some tasks in defined order:

    • creates chroot with base system
    • installs required development packages
    • creates source package
    • installs build dependencies
    • builds package
    • copies resulting packages and logs into results dir

    So where the problem is? First thing: there are multiple problems ;(

    First issue: mock assumes that there will be one run at time and does it in /var/lib/mock/TARGET/ (where TARGET is ‘fedora-rawhide-aarch64’ for example). This can be solved with “—uniqueext=packagename” argument.

    Second issue: there is ONE yum! Instead of using yum inside of chroot mock is using system one. So if you run few mocks at time (remember: cpu time and memory are cheap) you will see “Start: Waiting for yumcache lock” message for most of time (twice per build).

    Why it drives me mad? Because “pbuilder” in Debian did not have such silly issues. Each build was done in “mktemp” named directory and APT was used inside of chroot. Sure, that could mean more fetching of packages but I had local APT proxy for it which allowed me to do 30-50MB/s downloads.

    And I do not want to mention fact that if you want to configure mock you have to do that system wide…

    Written by Marcin Juszkiewicz on
  2. Internet over GSM abroad? Forget it…

    Several times per year I am abroad for some conferences or holidays. And lack of Internet access from a cellphone there sucks.

    In October I was in Munich, Germany for some internal Red Hat training. Had most of day for sightseeing but doing it without constant access to the Internet was a bit of disaster as I did not have time in previous week to mark interesting spots in Google Maps or to make any notes. And it was Sunday so all stores were closed == no way to buy local prepaid card.

    In February I will visit Brussels, Belgium for FOSDEM and then Brno, Czech Republic for devconf.cz. Local SIM cards for both countries would be nice.

    Did not yet checked Belgium ones yet but did that for Czech Republic. And man… situation there is awful. 200MB for 150CZK from mobil.cz looks like best offer for prepaid. Disaster… I wonder how slow it will be as well.

    But there are exceptions. In United Kingdom and Hong Kong I went to first Three shop and got unlimited data at affordable price. Spain was a bit strange as I had to register SIM card. But for 20€ I got something like 2GB of data.

    In Poland I am topping up my SIM with 100 PLN every 2-3 months and this gives me 6GB of transfer as a bonus. I now have 45GB of data available without any extra costs. And prepaid cards from all operators are available to buy at every corner…

    Written by Marcin Juszkiewicz on
  3. 2013 timeline

    Another year so time for summary post. Mostly spent around AArch64. Changed job. But let go with usual month-by-month style.




    • My blog is now EU cookie crap compliant.
    • Visited Hong Kong again for Linaro Connect Asia. Nice city, good conference. Hint: if you go for street shopping wait for seller to give price and start from 20-40% of it.



    • Left Linaro for good due to end of Canonical<>Linaro contract. This also meant leaving Canonical as I did not want to work there. You may want to read my post from start of May and my good bye Linaro one as well.
    • First discussion with Red Hat about job opportunities.
    • Visited UK for pleasure. London and Cambridge this time. I saw lot of interesting places, did several beers with local friends. Good spent time.
    • Sent ALSA UCM profiles and got it merged. One thing less for distributions to carry.


    • The “we pay you but do not require you to do any work” month at Canonical. Nice move from their side.
    • Visited Pixel Heaven in Warsaw. There was lot of different old computers. One of them was Acorn Archimedes so I was able to play with really old ARM cpus ;)
    • Started playing Ingress because I had 2 hours to return train…
    • Spent some time on Arch Linux ARM forums and found some nice hints for Chromebook usage. Also U-Boot for SPI flash…
    • Wrote post about ARM history which got shared in many places.



    • Got hired by Red Hat as Senior Software Engineer. My wife joked that next position would be Retired Software Engineer ;D
    • Vacations continued.





    • Started merging my stack of AArch64 related patches into Fedora. And into upstream of course. Lot of issues it gave.
    • Got Qt5 nearly complete on AArch64. Still have to get QtWebKit part done but it is close. Good part is that all my patches do not require any contribution agreement papers.

    It was quite good year. Changed job from interesting one at Linaro to also interesting one at Red Hat. Still work on AArch64 porting stuff but this time I have access to real hardware so it goes faster.

    Written by Marcin Juszkiewicz on
  4. I will stay with VirtualBox for a bit longer

    VMWare, VirtualBox, Xen, KVM, LXC and there are probably several other ways to run virtual machine under Linux.

    Years ago I used first one. Then moved to VirtualBox and still use it. But when it comes to rest of list I do not have too much experience. Xen? One of my servers in past was Xen instance. KVM? Maybe used few times to quick boot some ISO image. LXC? never played with.

    From time to time I look at tools I use and check for better replacements. When moved to Fedora I decided to try “virt-manager” to move from VirtualBox to QEMU/KVM. Failed. Tried again…

    Today, after “playing” with virt-manager in Fedora/rawhide I decided to stay with VirtualBox for longer. It may have some issues but runs my WinXP and Linux instances without any extra problems.

    Sorry to say but Virt-manager feels like a tool for its creators only. Error messages which could be in any random language, insisting on using /var/lib/libvirt/images/ for disk images (or do lot of clicks instead) and depending on so many software packages that it will probably take months before someone will finally fix it in rawhide.

    And no, I do not want to go to running QEMU/KVM by hand. It is good for booting image to play with. But I need a way to add/remove USB devices in running system. In an easy way.

    And yes, I know “report all bugs” mantra…

    Written by Marcin Juszkiewicz on
  5. Boże Narodzenia a książki dla dzieci / Christmas and children books

    English version below

    Idą święta. W sobotę Mira poprosiła bym przeczytał jej książkę o Bożym Narodzeniu.

    Książka była tłumaczona z innego języka. Innej kultury.

    Nie żebym miał coś przeciwko indykowi na Wigilię, kalendarzom adwentowym czy świętemu Mikołajowi zostawiającemu prezenty w nocy. Ale wolałbym przeczytać coś bardziej osadzonego w naszych realiach.

    Zarówno u mnie jak i u Ani w rodzinie św. Mikołaj przychodzi w okolicach “pierwszej gwiazdki”, zadaje pytania młodszym i starszym. To jest część świąt, której brak byłby odczuwalny.

    Nie potrzebuję rozrywać “Christmas Crackers” z drugą osobą, zamiast indyka wolę w ten dzień rybkę.

    Mirze różnicę w porze prezentów wyjaśniliśmy w prosty sposób: św. Mikołaj nie ma czasu by odwiedzić wszystkich wieczorem więc niektóre dzieci dostają prezenty w nocy.

    English version

    Christmas is comming. On Saturday my daughter Mira asked me to read her book about it.

    Book was translated from other language. Other culture.

    I do not have anything against turkey on Christmas Eve, advent calendars or Santa leaving presents during night. But I would prefer to read book more related to our way of handling Xmas.

    But both in my and Ania’s families Santa arrives around “a first star”, asks some questions, requests songs etc.

    I do not need to pull Christmas Crackers with other person (did it once) and prefer fish rather than turkey on Christmas’ Eve dinner.

    Our explanation on different timing of leaving presents was quite easy: Santa does not have enough time to visit everyone during evening so children in other countries get their presents during night.

    Chrismas Eve in Poland in wikipedia

    Written by Marcin Juszkiewicz on
  6. From a diary of AArch64 porter — rpm packaging

    In previous part I wrote about code managing issues. Today I want to write more about packaging and other ugly things.

    Each time I see block with check for 32/64 architecture I want to scream. Funny part is in RPM packaging. For example:

    %ifarch x86_64 ppc64 s390x sparc64
    %define bitsize 64
    %define bitsize 32

    Can be replaced with simple “%define bitsize %__isa_bits” so we would not have to patch yet another spec file.

    But developers are smart — always can create some nice way of fsck such thing up…

    if test $ax_arch = x86_64 -o $ax_arch = ppc64 -o $ax_arch = s390x -o $ax_arch = sparc64; then
        libsubdirs="lib64 lib lib64"

    This is from configure of one of libraries which failed to find boost version (as it did it by scanning library paths).

    Such issues are fun. Especially when component builds fine with wrong value and then all packages which depend on it fail in some weird way.

    But sometimes they fail in a way that it is cleanly visible what was wrong. ORBit2 is good example:

    DEBUG: /usr/include/orbit-2.0/orbit/orbit-config.h:9:30: fatal error:
    orbit-config-64.h: No such file or directory

    Everyone see that something is fishy with ORBit2 here. One small patch (similar to %ifarch example) and then all it’s dependencies build just fine.

    So if you are software developer and have such 32/64 checks in your software please consider doing it in a way that another 64bit architecture will not have to patch your code again.

    Written by Marcin Juszkiewicz on
  7. I miss Debian tools

    It is nearly two months since I switched from Debian/Ubuntu to Fedora/RHEL. And I start to miss Debian tools…

    Under Debian (which also means derivatives like Ubuntu) I used simple set of tools and I have found their Fedora replacements:

    Debian Fedora
    dpkg rpm
    apt-get yum/dnf
    apt-cache yum/dnf
    dpkg-buildpackage rpmbuild
    debuild rpmbuild
    pbuilder mock
    debdiff rpmdev-diff
    dgit(?) fedpkg/rhpkg

    The problem with Fedora tools is that they feel like few years behind Debian ones ;(

    While Debian world moved to use “quilt” to manage patches in source packages few years ago, Fedora’s RPM just got it recently so it is hard to find package which makes use of it. Updating patches is far from being pleasure.

    Yum (and it’s younger brother ‘dnf’) work in other way than APT. But are usable and do what they have to. The fun starts when you run “yum upgrade -y” on slow machine (like AArch64 model) and someone will regenerate repository data in meantime — you end with 404 errors cause repodata/ directory uses random file names…

    rpmbuild works. It even has some limited support for running separate steps. But without dependencies between them so “rpmbuild -bi specfile” needs “rpmbuild -bc specfile” first while in Debian world “debian/rules install” is enough. There is also “—short-circuit” option to not clean build directory when you want to go through single steps. But resulting binary packages are tainted and can not be installed without using “—nodeps” switch to RPM. I see a sense behind it but it hit me hard on AArch64 when I was building Qt (do not ask how long it took cause I did it several times during last 2 months).

    Then we have mock. Argh… I put it in one line with pbuilder but it is not worthy. No user setup possible, just one build at time (my machine is now 10% busy) make mock wasting lot of developer time. I opened bugs with feature requests for user config and multiple builds — hope that one day it will appear.

    And last entry is what I like. Both fedpkg and rhpkg allow me to clone git repository of package so I can create patches for packaging in quick way. In Debian world I never used such tool. Under Ubuntu packages were kept in Bazaar repositories but you know already what I think of this SCM.

    Written by Marcin Juszkiewicz on
  8. From a diary of AArch64 porter — autoconf

    One day I will go to software conference with an axe or a knife and will turn a place into slaughterhouse…

    During last few weeks most of my work was related to fixing build issues on AArch64 platform. That’s what I do since September 2012. Just operating system changed from OpenEmbedded to Fedora. And there are days when I want to kill.

    Kill who? Software developers. Some for shipping few years old copies of config.{guess,sub} files. Others for inventing crazy ways of abusing autoconf usage. My latest find was fakeroot.spec which has this precious jewel:

    for type in sysv tcp; do
    mkdir obj-$type
    cd obj-$type
    cat >> configure << 'EOF'
    #! /bin/sh
    exec ../configure "$@"
    chmod +x configure
    cd ..

    By default “%configure” macro updates config.{guess,sub} files. But it does it in place. So no luck here.

    There are countless packages like that. Code for 3rd-party libraries bundled with code may have them as well.

    So if your package uses config.{guess,sub} files then please take a look and do an update of them with new release.

    Written by Marcin Juszkiewicz on
Page 29 / 105