1. Another Apple product at home

    Three years ago I wrote blog post about naming company laptops. Last week I got new one. So new name was needed.

    Quest for Arm laptop

    Many things changed during last years. Qualcomm released Snapdragon SoC line for laptops. All were running Microsoft Windows (for Arm) with bastard version of ACPI tables. Took some time for Linux community to get Linux running on those systems. In Device Tree mode as ACPI tables were so bad that it was easier to ignore them.

    Apple released laptops and mini desktops with M1 SoC (in many variants) and then M2 (also with variants). With MacOS on them. Again, Linux community started working on getting Linux running there. Device Tree again.

    Read more…

    Written by Marcin Juszkiewicz on
  2. From a diary of AArch64 porter — Arm CPU features table

    Last week I had some discussions about future and projects where I am involved. And as kind of break I started yet another personal project for fun…

    AArch64 SoC features table

    Let make a table showing which AArch64 SoCs support which processor features. And how bad situation is.

    Read more…

    Written by Marcin Juszkiewicz on
  3. From a diary of AArch64 porter — handling big patches

    There are moments when developers want to make changes in other FOSS projects. Which usually means dealing with patch reviews. On mailing list, on Gerrit, GitHub or any other collaboration platform etc. And it can take quite a long time.

    One note at start: I am giving code patches as examples but post applies to any type of contributions (code, docs, examples, tests etc.).

    Read more…

    Written by Marcin Juszkiewicz on
  4. Is Wayland really a future of desktop?

    Each time I update my Fedora desktop to new release (usually around Beta) I give a try to Wayland. Which shows that I still use X11.

    My setup

    My desktop has Ryzen cpu and NVidia GTX 1050 Ti graphics card. Only one monitor (34” 3440x1440). I use binary blobs as this generation of GPU chipset is not really usable with FOSS driver (nouveau).

    For desktop environment I use KDE. Which means Plasma desktop/panel, Konsole and few KDE apps. Firefox and Chrome as web browsers, Thunderbird for mail, Steam for gaming and Zoom (or Google Meet) for most of video calls.

    Read more…

    Written by Marcin Juszkiewicz on
  5. I am tired of online conferences

    About two and half year passed since start of COVID-19 pandemic. A time when most of conferences got cancelled or went online (with different level of success).

    A conference which should have been a YouTube playlist

    There is saying “a meeting which should have been an email”. For meetings which were complete waste of time for most of attendees. During pandemic several events were “a conference which should have been a YouTube playlist”. Never mind did talks were interesting or not.

    Far too often there was no way to chat with speakers or other “attendees”. Or there was one chat channel per whole conference or track. Also without threading (just one long list of messages) and no way to mention names.

    Life kicks in

    Some time ago one online conference took place. Three days of talks about things which interest me. I had plans to attend several of them. Then life happened — video calls and local stuff. Also several hours of time difference was a problem.

    Good part is that organizers recorded all talks so I can watch them later. I “just” missed a way to get part in chat and Q&A session at the end.

    Started to ignore

    I started to ignore most of invites to such events. Sooner or later videos from them land online so I pick those which interest me.

    Sitting in front of a screen and watching people talking is boring. Especially after over two years of doing it because there was no other way.

    Written by Marcin Juszkiewicz on
  6. Installed top5000 Python packages on AArch64

    It was yet another boring week. I got some thanks for work we did to get Tensorflow running on AArch64 and was asked is there any other Python project which could use our help.

    I had some projects already on my list of things to check. And then found “Top PyPI Packages” website…

    Let install 5000 Python packages

    So I got an idea — let me grab list of top5000 PyPI packages and check how many of them have issues on AArch64.

    The plan was simple. Loop over list and do 3 tasks:

    • create virtualenv
    • install package
    • destroy virtualenv

    This way each package had the same environment and I did not had to worry about version conflicts.

    Virtualenv preparation

    To not repeat creation of virtualenv five thousand times I did it once:

    /opt/python/cp39-cp39/bin/python3 -mvenv venvs/test
    . venvs/test/bin/activate
    pip install -U pip wheel setuptools
    cp -a venvs/test venvs/clean

    This way I had newest versions of “pip”, “wheel” and “setuptools” as part of virtualenv. For a bit of speed “venvs” directory was mounted as “tmpfs”.

    Everything happened inside of “manylinux2014_aarch64” container (so CentOS 7 as OS) with Python 3.9 as interpreter.

    Phase 1

    First phase was simple installation of package wheel as it was available on PyPI:

    pip --only-binary :all: --no-compile ${name_of_package}

    So if package provided only source tarball/zip then it was marked as failed.

    There were 1569 packages which failed to pass this phase. Common issues (other than missing some development headers):

    • INFO: pip is looking at multiple versions of PACKAGE_NAME to determine which version is compatible with other requirements. This could take a while.
    • INFO: pip is looking at multiple versions of <Python from Requires-Python> to determine which version is compatible with other requirements. This could take a while.
    • INFO: This is taking longer than usual. You might need to provide the dependency resolver with stricter constraints to reduce runtime. See https://pip.pypa.io/warnings/backtracking for guidance. If you want to abort this run, press Ctrl + C.
    • ERROR: Cannot install OTHER_PACKAGE_NAME because these package versions have conflicting dependencies.
    • ERROR: Could not find a version that satisfies the requirement OTHER_PACKAGE_NAME (from versions: none)
    • ERROR: Could not find a version that satisfies the requirement OTHER_PACKAGE_NAME==N.V.R (from ANOTHER_PACKAGE_NAME) (from versions: x.y, x.y.z, x.z.z)
    • ERROR: No matching distribution found for OTHER_PACKAGE_NAME

    Note that failure at this phase is allowed as I just want ready to use wheel files.

    Whole process took about 20 hours on Honeycomb.

    Phase 2

    The main difference was getting rid of “—only-binary” and “—no-compile” options from pip install calls.

    Still no additional development packages installed. Cache from phase 1 in use to not re-download/re-build existing wheel files.

    The main issue is how single threaded pip install is. Nevermind that Honeycomb has 16 cpu cores — only one is used (and this is Cortex-A72 so nothing fancy). This makes building times higher than they suppose to be:

    Building wheels for collected packages: pandas, typing
      Building wheel for pandas (setup.py): started
      Building wheel for pandas (setup.py): still running...
      Building wheel for pandas (setup.py): still running...
      Building wheel for pandas (setup.py): still running...
      Building wheel for pandas (setup.py): still running...
      Building wheel for pandas (setup.py): still running...
      Building wheel for pandas (setup.py): still running...
      Building wheel for pandas (setup.py): still running...
      Building wheel for pandas (setup.py): still running...
      Building wheel for pandas (setup.py): still running...
      Building wheel for pandas (setup.py): still running...
      Building wheel for pandas (setup.py): still running...

    There were 313 packages which failed to pass this phase. Issues were similar to those in phase 1 with one exception (as building packages was allowed):

    • ERROR: Could not build wheels for OTHER_PACKAGE_NAME, which is required to install pyproject.toml-based projects

    This phase took about 13 hours on Honeycomb.

    Phase 3

    About 6% packages left. Now it is time to install some development headers:

    • blas-devel
    • bzip2-devel
    • cairo-devel
    • cyrus-sasl-devel
    • gmp-devel
    • gobject-introspection-devel
    • graphviz-devel
    • gtk3-devel
    • httpd-devel
    • krb5-devel
    • lapack-devel
    • libcap-devel
    • libcurl-devel
    • libicu-devel
    • libjpeg-devel
    • libmemcached-devel
    • mariadb-devel
    • ncurses-devel
    • openldap-devel
    • openssl-devel
    • poppler-cpp-devel
    • postgresql-devel
    • protobuf-compiler
    • unixODBC-devel
    • xmlsec1-devel

    I created this list by checking how packages failed to build. It should be longer but CentOS 7 (base of “manylinux2014” container image) does not provide everything needed (for example up-to-date Rust compiler or LLVM).

    Before starting phase 3 run I removed all entries related to “pyobjc” as they are MacOS related so there is no need to waste time again.

    After 3.5 hours I had another 54 packages built.

    Phase 4

    Some packages are not present in CentOS 7 but are present in EPEL repository. So after enabling EPEL (yum install -y epel-release) I installed another set of development packages:

    • augeas-devel
    • boost-devel
    • cargo
    • gdal-devel
    • leptonica-devel
    • leveldb-devel
    • suitesparse-devel
    • portaudio-devel
    • proj
    • protobuf-devel
    • rust
    • zbar-devel

    Some of those packages should be installed in previous step. I did not caught them because build processes failed earlier.

    Before starting round I went through logs and removed everything:

    • failed with “No matching distribution for PACKAGE_NAME
    • failed with “use_2to3 is invalid” (aka “I need old setuptools”)
    • requiring Bazel
    • requiring tensorflow

    At the end I had about one hundred of failed to build packages. For different reasons:

    • missing build dependencies
    • expecting newer libraries than “manylinux2014” (CentOS 7) has
    • not listing all dependencies (everyone has “numpy” installed, right?)
    • being Python 2.7 only
    • using removed modules or classes
    • breaking install to say “this module is deprecated, use OTHER_NAME”
    • not supporting AArch64 architecture


    One hundred of top five thousand packages equals two percent of failures. There were 13 failures in top 1000, another 14 in second thousand.

    Is 2% acceptable amount? I think that it is. Some improvements can still be made but nothing requiring shown. OK, would be nice to get Tensorflow for AArch64 released by upstream under same name (instead of “tensorflow_aarch64” builds done by team at Linaro).

    How to run it?

    After my tweet I had several comments and people wanted to run this test on other architectures, operating systems or devices. So I wrote simple script:

    echo "cleanup after previous runs"
    rm -rf venvs/* logs/*
    echo "Prepare clean virtualenv"
    python3 -mvenv venvs/test
    . venvs/test/bin/activate
    pip install -U pip wheel setuptools
    cp -a venvs/test venvs/clean
    echo "fetch and prepare top5000 list"
    rm top-pypi-packages-30-days.*
    wget https://hugovk.github.io/top-pypi-packages/top-pypi-packages-30-days.json
    grep project top-pypi-packages-30-days.json \
        |sed -e 's/"project": "\(.*\)"/\1/g' > top-pypi-packages-30-days.text
    echo "go through packages"
    mkdir -p logs
    for package in `cat top-pypi-packages-30-days.text`; do
        echo "processing ${package}"
        rm -rf venvs/test
        cp -a venvs/clean venvs/test
        source venvs/test/bin/activate
        pip install --no-input \
            -U --upgrade-strategy=only-if-needed \
            $package | tee logs/${package}.log
        echo "-----------------------------------------------------------------"

    It should work on any operating system capable of running Python. All build dependencies need to be installed first. I suggest mounting “tmpfs” over “venvs/” directory as there will be lot of temporary i/o going on there.

    Once it finish just run grep to check how many packages were installed with success:

    grep "^Successfully installed" logs/*|wc -l

    Please share your results. Contact page lists several ways to catch me.

    Written by Marcin Juszkiewicz on
  7. Monitoring local network devices

    Due to current events it was hard to concentrate on work lately. So I decided to learn something new but still work related.

    In OpenStack Kolla project we provide images with Collectd, Grafana, Influxdb, Prometheus, Telegraf to give people options for monitoring their deployments. I never used any of them. Until now.

    Local setup

    At home I have some devices I could monitor for random data:

    • TrueNAS based NAS
    • OpenWRT based router
    • OpenWRT based access point
    • HoneyComb arm devbox
    • other Linux based computers
    • Home Assistant

    All machines can ping each other so sending data is not a problem.


    For software stack I decided to go for PIG — Prometheus, Influxdb, Grafana.

    I used instruction from blog posts written by Chris Smart:

    Read both — they have more details than I used to mention. Also more graphics.


    Turned out that OpenWRT devices can either use “collectd” or Prometheus node exporter to gather metrics. I had first one installed already (to have some graphs in webUI). If you do not then all you need is this set of commands:

    opkg update
    opkg install luci-app-statistics collectd collectd-mod-cpu \
                 collectd-mod-interface collectd-mod-iwinfo \
                 collectd-mod-load collectd-mod-memory \
                 collectd-mod-network collectd-mod-uptime
    /etc/init.d/luci_statistics enable
    /etc/init.d/collectd enable


    TrueNAS already has reporting in webUI. Can also send data to remote Graphite server. So again I had everything in place for gathering metrics.

    Next step was sorting out data collector and visualisation. There is community provided “Grafana & Influxdb” plugin. Installed it, gave jail a name, set to request own IP and got “grafana.lan” running in a minute.


    At this moment everything is installed for both gathering and visualisation of data. Time for some configuration.

    Logged into jail (“sudo iocage console grafana”) and fun started.


    First Influxdb needed to be configured to accept both “collectd” data from OpenWRT nodes and “graphite” data from TrueNAS. Simple edit of “/usr/local/etc/influxd.conf” file to have this:

      enabled = true
      bind-address = ":25826"
      database = "collectd"
      # retention-policy = ""
      # The collectd service supports either scanning a directory for multiple types
      # db files, or specifying a single db file.
      typesdb = "/usr/local/share/collectd"
      security-level = "none"
      # auth-file = "/etc/collectd/auth_file"

    and that:

      # Determines whether the graphite endpoint is enabled.
      enabled = true
      database = "graphite"
      # retention-policy = ""
      bind-address = ":2003"
      protocol = "tcp"
      consistency-level = "one"

    Save, restart Influxdb (by “service influxd restart”). Next step was creation of databases (add username and password if needed):

    # influx
    > create database collectd
    > create database graphite
    > exit

    And data should be gathered from both OpenWRT (collectd) and TrueNAS (graphite) nodes.


    Here are two ways to do configure OpenWRT based system:

    First one is visiting webUI -> Statistics -> Setup -> Output plugins, then enabling “network” plugin and giving IP of InfluxDB server.

    OpenWRT WebUI -> Statistics -> Setup -> Output plugins
    OpenWRT WebUI -> Statistics -> Setup -> Output plugins
    OpenWRT WebUI Network output plugin configuration
    OpenWRT WebUI Network output plugin configuration

    Second one is simple edit of “/etc/collectd.conf” file:

    LoadPlugin network
    <Plugin network>
            Server "" "25826"

    No idea why it wants IP address instead of FQDN.


    TrueNAS is simple — visit webUI -> System -> Reporting and give address (IP or FQDN) of remote graphite server.

    TrueNAS System Reporting configuration
    TrueNAS System Reporting configuration

    I enabled both “Report CPU usage in percent” and “Graphite separate instances” checkboxes because of Grafana dashboard I use.


    Logged into http://grafana.lan:3000, setup admin account and then setup data sources. Both will be “InfluxDB” type — one for ‘collectd’ database keeping metrics from OpenWRT nodes, second for ‘graphite’ one with data from TrueNAS.

    Use “http://localhost:8086” as URL, provide database names and name each data source in a way telling you which one is which.


    Ok, software installed on all nodes, configuration files edited. Metrics flow to InfluxDB (you can check them using “show series” in Influx shell tool). Time to setup some dashboards in Grafana.

    This is moment where I went for ready ones:

    OpenWRT dashboard

    Hard to tell will I keep it as it provides lot of data on same graphs:

    Overloaded OpenWRT dashboard
    Overloaded OpenWRT dashboard

    I plan to take a look at it and keep what I really need, use some aliases to see WiFi network names instead of interface names, etc.

    TrueNAS dashboard

    Here some editing was needed. Dashboard itself needed timezone change, 24 hours clock, adding ‘da0’ hard disk to graphs and setting ZFS pool names.

    The other edit was in InfluxDB configuration (in “graphite” section) to get some metrics renamed:

      templates = [
        "*.app env.service.resource.measurement",
         "servers.* .host.resource.measurement.field*",

    Effect was nice:

    TrueNAS dashboard
    TrueNAS dashboard

    This one looks like good base. Also suggests me to visit my server wardrobe and check fans in NAS box.


    I need to alter both dashboards to make them show some really usable data. Then add some alerts. And more nodes — there is still no Prometheus in use here gathering metrics from my generic Linux machines. Nor my server.

    Written by Marcin Juszkiewicz on
  8. 2021 timeline

    2021 ended so let me try to mark some interesting moments.


    • Started looking for a new flat. This time to buy not to rent.

    • As kind of experiment I started working on I/O plate for APM Mustang as it never had one. After several hours and versions finally I got something usable. Not perfect but good enough.


    • Online FOSDEM happened. It was the best online conference so far.

    • Friend found me a nice flat. Went, saw, decided to buy.

    • Jon Nettleton from SolidRun asked do I have any interest in a HoneyComb. We discussed and few days later I got HoneyComb at home. Bought things like case and ram for it, used spare nvme and got it working. I use it as build machine for countless projects.

    • Replaced old Netgear router with EspressoBin. I got that SBC from a friend, printed 3d case and sorted out fresh firmware. Now it boots straight from SPI flash and reads operating system from microsd card.

    • After several discussions with developers I wrote how AArch64 perception change when all you used are SBC (compared to being used to AArch64 servers).


    • Another ‘let me explain’ post. This time on U-Boot and generic distro boot as it turned out to be hard to understand/decode for some people.

    • I got an offer of Ampere eMag system. But due to my flat move and shipping/customs issues nothing came from it.


    • Bought flat. Agreed with previous owners on moving date. They started painting walls.

    • Five years at Linaro passed. Still waiting for that glass award.

    • I wrote one tweet and it was enough to get extra AArch64 nodes for Opendev CI.

    • I got “Mars 2020 Helicopter Contributor” badge on GitHub. As one of ~12000 developers.

    • First dose of COVID-19 vaccine.


    • Moved to my own flat. With help from my friends and moving company. Still have a few unpacked boxes.

    • As my daughter had 3 free days in a middle of a week we went for nice trip through museums.

    • Spent some time on designing new structure for home network. EspressoBin got replaced with very small x86-64 system (4 “igb” network interfaces). Finally reached 1Gbps speed on home link.


    • Organizing my new home. Looking for good office furniture ended with buying VS 901 desk and organizer.

    • Second dose of COVID-19 vaccine.


    • Got two Sharp Zaurus palmtops: SL-5500 (collie) and SL-5600 (poodle) from a friend. First model was a device which brought me to working full time on FOSS.

    • My 13 years old daughter asked me what “that huge phone with printer” she saw in anime was. Took me a moment or two to find out that it was fax machine…

    • Crashed my car. No one got hurt. Insurance paid what they had to and I later sold what was left of the car.


    • Vacations! Rented Opel Astra combi and we went for a tour. Met some friends, visited new places (and some old ones). Good time.

    • Friends managed to organize demoscene party in COVID-19 times. So I went to Katowice, Poland and spent great time at Xenium 2021.



    • Left some projects maintained by Arm employees. Open source with closed development process is not something I am fan of. Especially when there is no serious review done on code contributions.

    • I got information that moderators on “Arm Software Developers” Discord are not fans of my comments there. Went through history, dropped most of my posts and left server. Was asked to go back some time later. No longer taking part of conversations there.


    • I was positive! Too bad that it was result of COVID-19 test. 2 weeks of isolation as a result. Boring time with flu-like symptoms. Friends handled my shopping needs.

    • Migrated from Pocketbook Touch HD to Onyx Boox Poke 3. Just to migrate to Onyx Boox Nova 2 three weeks later. Reading books on 7.8” screen is the other experience.


    • Polish demoscene became official Polish cultural heritage.

    • Wrote post about 25 years of using the Internet.

    • Started playing with configuration of my router to get native IPv6/IPv4 setup working. Took far too many attempts and curses but got it done (in 2022).

    • Third dose of COVID-19 vaccine (this time Moderna instead of Pfizer).

    Written by Marcin Juszkiewicz on
Page 3 / 105