Marcin Juszkiewicz

During break between talks I spoke with Rob Taylor and Andreia Gaita about lack of ARM powered servers. And then cute hack appeared in my head…

Rockchip released RK3268 (if I got numbers correctly) which uses four Cortex-A12 cores. There are HDMI dongles with it and 2 GB of ram.

So the idea is: we take 1U server case, glue as many dongles as we can and connect them with USB cables for power and network. Then put some OpenStack or other software to maintain a cloud and it may even work.

The problems Rob noted would be heat and lack of bandwidth. But it would be cute embedded nonsense hack.

For all previous FOSDEM visits I was offline. You know: high roaming costs, not liking to use random open wifi networks etc. But not this time.

I arrived yesterday morning at BRU airport. Planned to buy a simcard there but managed to skip whole shopping part without realising what I did.

But when I arrived in a city centre I noticed a “free wifi” sign at the Novotel hotel so decided to make use of it. Flood of Google+ and Facebook notifications was what I got. Checked in on Foursquare and minute later met XorA with Anya. We took a coffee, discussed about work, life and then went for some walk.

Half hour later I left some small shop with a BASE simcard in my Nexus 5 with 1GB of transfer available. My standard simcard went to the backup phone (Nokia 101 this time). Quick look at Foursquare, Google+ and Facebook and I saw where my friends are and could get in contact. Met Philip, Koen, Vladimir and several other guys, got invited to a dinner etc. Managed to take some portals down in Ingress game as well ;-)

Not that I would not be able to survive without a local simcard. There are lot of open wireless networks in Brussels but how many of them are safe?

Next month will start with conferences… Tomorrow I go for FOSDEM 2014 then one day break (to change bags) and then Devconf.cz in Brno, Czech Republic.

It will be 6th visit at FOSDEM for me. I do not plan to man a booth for any project and hope to find time to visit at least few talks — this year list is quite long:

• A Method for Distributing Applications Independent from the Distro
• Anatomy of kdbus
• ARM: Allwinner sunxi SoC’s and the community behind it
• CentOS: Planning for Variants and the Next Chapter
• Ceph
• Considering the Future of Copyleft
• Cross Distro Automation
• Debian Contributors
• Discover DoudouLinux live!
• GNURadio as a general purpose DSP environment
• How we found a million style and grammar errors in the English Wikipedia
• Introducing the Meson build system
• IP risks for OSS developers
• Is distribution-level package management obsolete?
• Legal issues from a radical community angle
• lima driver: Opening up the Mali instruction set
• Lumicall — an open alternative to Viber
• MINIX 3 on ARM
• No more IPv4
• Nouveau — On-going work, demos and research
• OpenJDK on AArch64 Update
• OpenPandora and a peek into the future
• osmocom: Overview of our SDR projects
• Persistent Memory
• Porting FreeBSD on Xen on ARM
• Reproducible Builds for Debian
• Software Archaeology for Beginners
• State of the X.org foundation
• State of Thunderbird
• Sunxi KMS driver
• Technical introduction to the deeper parts of Sailfish OS, a Qt5-Wayland based mobile OS
• Testing Kernel GFX Drivers
• The evolution of Android’s runtime
• The Lima driver
• UEFI is not your enemy
• Virtualization Dungeon on ARM
• Who ate my battery?
• Why You Should Be an Open Source Project
• Xen on ARM

As usual it would be success if I will manage to see 30% of them as for me FOSDEM is a place to meet people from other projects to share ideas rather than spend time on sessions.

Next will be Devconf.cz but first ARM Hackfest a day before at Red Hat office (an option to check my badge). This conference is more Fedora related and I hope to meet interesting people there to discuss how to do some things. No talks selection as there will much smaller amount of them so I can do it between sessions ;D

If you want to catch me at conferences then use Google Hangout, Facebook Messenger or just mail me. I plan to have local SIM card to be always online.

AMD announced their new SoC: Opteron A1100. But instead of yet another x86-64 chip it is AArch64 one.

It is visible that they made Server-on-Chip but give me one and I will make a desktop computer from it. All it takes is USB 3.0 controller and graphics card with HDMI audio.

I wonder will it boot UEFI or U-Boot…

More information and slides are in Anandtech article.

I finally sent Xulrunner support for AArch64 upstream. From 76KB patch I went to 14 patches with 132KB in total due to other diff options like more context lines.

Will not bother with whole history of a patch. It involved three external projects:

• libffi (merged upstream long time ago, xulrunner needs to update their copy)
• double-conversion (see Qt/AArch64 post for details) also update needed
• libevent got fix for deprecated syscalls which needs to be merged into xulrunner’s copy

Splitting patch went quite easy thanks to help from Xulrunner developers: mstange froydnj Tomcat Ms2ger glandium which told me how to submit my patch, which already existing bugs to update and who assign to code reviews.

And for patches please go to dependency tree of bug #962534.

And one note: AArch64 big endian was not fully covered. Endianness info was provided in most places for both little and big options.

In over a year of my work as AArch64 porter I saw a lot of patches. But Qt one has the most interesting history.

Around year ago when I was building whatever possible during my Linaro work we got to the point when Qt jumped into a queue. Build failed but fixing was quite easy — all I had to do was to take “webkitgtk” patch written by Riku Voipio and apply it to Qt 4. Resulting file landed in “meta-aarch64” layer of OpenEmbedded and is still there.

Time passed. More common distributions like Debian, Fedora, OpenSUSE, Ubuntu (alphabetical order) started working on their AArch64 ports. And one day Fedora and Ubuntu started working on building Qt 4. I do not know who wrote QAtomic stuff but I saw few versions/iterations of it and it took me quite long time (first on model, then on real hardware) to get it fully working in Fedora — used Ubuntu version of patches.

Up to this moment it was over 9 months and still no upstreaming was done. So one day I decided to go for it and opened QTBUG #35442. Then reopened issue #33 in “double-conversion” project (which is used in few places in Qt) as they got good fix and merged wrong one (but it is fixed now). For that one I opened a request to update to newer version of “double-conversion” as QTBUG #35528.

But story did not end there. As Qt 4 development is more or less ended I was asked to provide fixes for Qt 5. Took me a while. Had to create a graph of build time dependencies between Qt 5 components (had to break few in meantime) and slowly module after module I got most of it built.

There were 3 components which required patching:

• qtdeclarative (issue #33, QTBUG #35528)
• qtscript (WebKit related, sent by Riku Voipio as Qt change #74927)
• qtwebkit (sent as Qt change #74851)

First one is solved upstream and waits for Qt guys. I was told that 5.3 will get it updated. Second one is already reviewed and merged. Last one left and here is a problem as it looks like the only person who does QtWebKit code reviews is Allan Sandfeld Jensen but he can not review code he sent. I am not able to do that due to Qt Contributor License Agreement which needs to be signed and (due to legal stuff) I can not do that.

So how it looks now? I would say that quite good. One 3rd party project needs update (in two places of Qt 5) and one patch needs to get through code review. I still need to send package updates to Fedora bug tracker. Ubuntu will need to merge patches when they move to 5.2 version.

Fedora 18 just became EOL. Most of the people do not care as F20 is present so they can run it on their PCs. But there is a group of users which may care.

All those people with ARMv5t hardware are left with Debian/armel now as there is no other big distribution supporting their devices anymore. Someone will ask “what about Ångström or Gentoo?” but who sane would build Gentoo on armv5te?

I do not remember when last time I used something with arm926 core (or similar - like Kirkwood). Probably few years ago when helped friend to get Sheevaplug booting into Debian.

But there are still Sheevaplugs, Guruplugs, *plugs and QNAP devices out there serving their users with selected services. And some of their owners will have to decide what next…

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…