Flock to Fedora 2019 Trip Report

I just flew back from Flock 2019 in Budapest, Hungary, and boy are my arms tired!

Flock is the Fedora Project’s annual contributor-focused conference. This was my first time attending Flock, and I’ve only attended a handful of previous conference in general, so I wasn’t sure what to expect. It was also my first-ever experience presenting at a conference, and I’m not a fan of long flights in cramped seats—so I arrived for the conference with a bit of anxiety in addition to jet lag. However, sampling the local food and beverage choices helped me adjust.

I found the four days of events to be filled with interesting sessions that sometimes required difficult choices when deciding what to attend.

Based on my impression of sessions I attended and discussions in which I participated or observed, here are several topics that seemed to be generating a lot of interest and activity within the Fedora community.

Modularity: I attended talks on the topics of whether or not to modularize, mass branching/rebuilding of modules, and modularity and packager experience, as well as presenting my own talk on tools for making modules. There seems to be a general feeling that “modules are hard,” and some people are actively ignoring or avoiding modularity as much as possible. Others have been diligently attempting to make use of modules in cases where, it turns out, they shouldn’t have. So, while modularity may currently have a few rough edges around the corner cases, it’s nothing that a little documentation and user interface improvement shouldn’t take care of! Also, during the Q&A following my talk, a couple RFEs related to scratch module builds were identified and tickets (here and here) were created.

Automated Testing: I attended talks on the topics of automated build checks, gating rawhide packages, human-friendly configuration for testing and gating, and the Fedora CI objective. There are a lot of things happening to improve the quality of Fedora by automating testing and preventing updates from accidentally breaking composes. As with modules, there are still a few rough edges, but it’s real and people are actively working to make it better and easier.

IoT: I only attended the overview of IoT session on this topic, but there are many people interested in getting Fedora to run their light bulbs and the likes. I also attended the minimization talk, which has a lot of promise to make things little—and ties in well with IoT, containers, and almost everything else.

3D User Interaction: While there weren’t any sessions that specifically pertained to this topic, the most valuable benefit I found from attending Flock was the direct interaction with others in the Fedora community who I had previously known only by their IRC/FAS/e-mail user names, or seen on video conferences!

How to configure your Fedora development system to access the Fedora staging infrastructure

This is a brief summary describing how to configure your Fedora development system to access the Fedora staging infrastructure instances of Kerberos, dist-git, Koji, Taskotron, etc. This information was gleaned and extrapolated from various sources including Fedora Modularity Developer Notes and How To Build A Module In Staging.


Make sure that you have Kerberos credentials for the staging realm, STG.FEDORAPROJECT.ORG .  You may need to create a Fedora infra ticket to get your production Fedora Account System (FAS) credentials copied to staging FAS.

fedpkg and dist-git

$ sudo dnf install fedpkg-stage

This installs the fedpkg-stage command along with the staging configuration file /etc/rpkg/fedpkg-stage.conf. fedpkg-stage is identical to the regular fedpkg command, except it uses the staging configuration file–which is equivalent to running fedpkg -C /etc/rpkg/fedpkg-stage.conf ....


An alternate configuration file is needed to access staging Koji. You may not need to prepare one yourself once BugZilla 1422892 is resolved. Otherwise, use this:

$ sudo mkdir /etc/koji
$ sudo cp /etc/koji.conf /etc/koji/stg-config
$ sudo sed -i 's/\.fedoraproject\.org/\.stg\.fedoraproject\.org/' /etc/koji/stg-config
$ sudo sed -i -e '/^krb_rdns/d' -e '$ a anon_retry = true' /etc/koji/stg-config

You can now access staging Koji using koji -c /etc/koji/stg-config ....


Taskotron’s configuration file needs adjustments to communicate with the staging environment. Unfortunately, the runtask command does not currently have an option to specify an alternate configuration file. Thus, you have to modify /etc/taskotron/taskotron.yaml each time you want to switch between production and staging. The following will help:

$ sudo cp /etc/taskotron/taskotron.yaml /etc/taskotron/taskotron.prod.yaml
$ sudo cp /etc/taskotron/taskotron.prod.yaml /etc/taskotron/taskotron.stg.yaml
$ sudo vi /etc/taskotron/taskotron.stg.yaml
# Set the following in /etc/taskotron/taskotron.stg.yaml:
#   koji_url: https://koji.stg.fedoraproject.org/kojihub
#   pkg_url: https://kojipkgs.stg.fedoraproject.org/packages
$ sudo cp /etc/taskotron/taskotron.stg.yaml /etc/taskotron/taskotron.yaml

How to run package-level tests in the Fedora build environment

You may not have heard about it yet, but a new feature was recently added to the Fedora build environment (i.e., Koji and Taskotron) that allows package-level tests to be added to dist-git that will be run when a build is kicked off. This is a quick how-to guide for doing so.


  1. If you are trying this for the first time, it would be a good idea to do so using the staging instances of dist-git, Koji, etc. See How to configure your Fedora development system to access the Fedora staging infrastructure for  instructions.
  2. There is currently (as of 29 March 2017) some oddness when triggering tests to run in staging dist-git. The Taskotron code goes through and tries to clone the dist-git repository with a branch matching the fXX in the NVR. If it can’t find that, it assumes rawhide and gets master. However, rawhide is still f26 in staging. Unfortunately, the f26 branch in staging dist-git may or may not contain the full package source files, as well has having improperly configured commit rights. Thus, for the time being, the f25 branch in staging dist-git should to be used for tests.
  3. Currently (as of 29 March 2017), there may be some oddness triggering tests to run from a branch other than master in production dist-git. Thus, for the time being, the master branch in production dist-git should to be used for tests.


  1. Install the necessary development packages and complete the Fedora development setup and Taskotron setup on your Fedora development machine:
    $ sudo dnf install fedora-packager
    $ fedora-packager-setup
    # configure ssh keys
    $ sudo dnf install libtaskotron
    $ sudo usermod -aG taskotron $USER
    # log out and back in for the new group assignment to take effect
  2. Identify the Fedora package for which you will be adding tests. You will need commit rights to the package in order to actually add any tests. It would also be a good idea to get in contact with the current Fedora packagers/maintainers to let them know what you’re up to!
  3. Check out the package from dist-git using the Fedora RPM packaging utility, fedpkg.
  4. Create a test subdirectory in the Fedora dist-git repository for the package for which you are adding tests.
  5. Within the RPM test directory, create a subdirectory for each test. Name it something useful that identifies the test. If is related to a BugZilla, consider starting the name of the subdirectory with the BugID and include a brief summary of the test. For example, “bz123456-foo-needs-to-support-bar”.
  6. Inside the per-test subdirectory, create/copy test scripts, etc. to run the desired test. You can find some trivial examples in the packages libtaskotron and python-avocado.
  7. Inside the per-test subdirectory, create a file named runtask.yml using the following as an example. It runs “make run” as a shell command (which happens to be the standard method by which beakerlib tests are run). See the Taskotron documentation for details on the format of this file and the directives that can be used. Note that this simple task does NOT reports its results to ResultsDB.
    name: bz123456-foo-needs-to-support-bar
    desc: "Tests BZ#123456 - Foo needs to support bar."
    maintainer: your_userid
        - koji_build
        - arch
        - make
        - name: download the build
            action: download
            koji_build: ${koji_build}
            arch: $arch
            target_dir: ${workdir}/rpms
        - name: install the build
            - dnf install -y ${workdir}/rpms/*.rpm
        - name: run test
            - make run
  8. The following example is slightly more complex. It runs python code that generates a specially formatted YAML results file that gets reported to ResultsDB.
    name: bz123456-foo-needs-to-support-bar
    desc: "Tests BZ#123456 - Foo needs to support bar."
    maintainer: your_userid
        - koji_build
        - arch
        - name: install the build
            - dnf install -y ${workdir}/rpms/*.rpm
        - name: run bz123456-foo-needs-to-support-bar
            file: run_test.py
            callable: run
            koji_build: ${koji_build}
            arch: ${arch}
            artifactsdir: ${artifactsdir}
        export: test_output
        - name: report results to resultsdb
            results: ${test_output}
  9. Inside the per-test subdirectory, you should create a README file in reStructuredText (RST) or Markdown (MD) format that explains your test and how to run it. Following is an example README.rst.
    name: bz123456-foo-needs-to-support-bar
    This is an example task for `Taskotron <https://fedoraproject.org/wiki/Taskotron>`_ that implements a test that foo supports bar (BugZilla #123456).
    Standalone you can run it like this::
      $ make run
    Through taskotron runner you can run it like this::
      $ runtask -i foo-1.1-111.fc25 -t koji_build -a noarch runtask.yml
  10. Test your test to make sure it runs locally directly from the shell, and through libtaskotron by running the runtask command similar to the README example shown in the previous step. You may need to run as root using sudo depending on what your task does.
  11. Bump the package release number in the package spec file to get it to rebuild in Koji.
  12. Commit your changes to the dist-git repository.
  13. Submit a package build in Koji using fedpkg build. Note that Taskotron does NOT currently run tests from dist-git when performing a “scratch” build.
  14. Results (if reported) can be found in ResultsDB (production/staging) after the build has finished if you query for it. Item would be NVR, testcase would be whatever you put into the formula (which should get standardized some day soon).
  15. If the task crashes or fails to report results, you won’t see a result in ResultsDB. But, you should at least see it in the Tasoktron dist-git builders log (production/staging) and ExecDB (production/staging).

Good luck!