modulemd 1.3.0

I almost forgot! Last week I released modulemd-1.3.0, the module metadata format specification and its reference Python implementation.

This release defines just three new fields but all of them are pretty important.

  • context, which carries a short hash generated from the module’s name, stream, version and its runtime dependencies. This is a prerequisite for a concept we call “Module Stream Expansion” and serves to uniquely identify a particular module build with its expanded dependencies, differentiating it from any other possible builds with the same name, stream and version. This might sound confusing but the basic idea is we would like to, in a future version, allow module maintainers to specify dependencies like “any platform” or “any platform but f27 with any python 3 on top”. The Module Build Service would then build all variants, each with the same name, stream and version but unique expanded dependencies and an unique context flag. System management utilities would then select the variant that is installable on the particular system, based on modules already deployed, default configuration or any additional information provided for the transaction. See the linked thread for details. context is included in the module’s identifier string, too. Did I mention we finally have a solid naming scheme proposal?
  • arch, which defines the specific hardware architecture the main components (as opposed to those pulled in via the multilib mechanism) of this module artifact are compatible with. This differs from the current common concept of basearch in the sense that this is not the architecture family but rather its specific variant. Not i386 but i586 or i686. Not armhfp but armv7hl. Meant to assist system deployment tools, just like context, arch is also part of the module’s identifier string.
  • eol, which a simple ISO 8601 date denoting the day the module reaches its End of Life. In Fedora we expect to define these in PDC for each module stream with the build system filling it in. Policies regarding module life cycles and service levels have yet to be defined but we already have a field for that. Yay.

All of these are technically optional and none of them should be manually filled in by the packager. modulemd leaves certain details undefined as they’re not all that important for the format — such as how exactly we construct the context hash, what hashing algorithm should be used, or whether this should be the same hash we use for package NVR uniqueness guarantee in koji. The only thing that matters is it’s unique among other modules with the same NSV.

Let’s see how this works out.

Comments disabled

After a few months of going through dozens of spam posts every single day I decided to disable comments on this blog. Just drop me a mail or comment on social websites. Pingbacks should still work, too.

If I’d ever received anything but spam, I would have gone with Akisment, but right now it’s not really worth it.

modulemd 1.2.0

I released modulemd-1.2.0 yesterday, the module metadata reference and its Python manipulation library.

This version defines two new important sections, artifacts and buildopts, and clarifies & extends the format specification a bit, standardizing several profile names (kudos to Tomáš Tomeček) and explaining module inclusion in a somewhat more verbose way.

The new artifacts section allows for listing binary artifacts associated with the module, such as binary RPM NEVRAs. Originally there was no need for this feature as we were expecting to ship each module build in its own separate RPM repository and the RPM artifact lists would have been already provided by repodata in that case. Alas, the current plan is to deliver multiple modules in one repo and the software management tools, such as dnf, need to have means to link binary artifacts in the repository to module metadata. This is how.

        - python2-modulemd-0:1.2.0-1.module_23c5e6b.noarch
        - python3-modulemd-0:1.2.0-1.module_23c5e6b.noarch

The section is optional and should be populated during the compose, for example by pungi.

The buildopts section lets module developers specify additional per component type module-wide build options. Currently this is limited to RPM macros that should be defined in the buildroot.

        macros: |
            %perl_bootstrap 1
            %myarches %{ix86} %{arm}

Note that altering buildopts negatively affects component reuse and is equivalent to a buildroot change.

Additionally, modulemd now provides load_all and dump_all functions for working with modulemd multidocuments, such as those stored in the repodata.

Fedora 25, 26 and EPEL 7 updates have been submitted. Feel free to test and give karma. It might take a few weeks before all the new features are supported by the module build service, pungi and dnf, so be patient.

Minor change in categories

I’ve decided to remove the Fedora category and just make it a tag, leaving all the previous Fedora category posts in Tech. I’ve also decided to publish all the Tech posts on Fedora Planet, not just the Fedora ones.

Not every is or will be strictly related to Fedora while I still think the Planet readers might find them interesting. I think this is kinda clearer.

Screenshot, April 14, 2017

Just playing with some new colors and window layouts. Three columns make much more sense with 4K. I think I will be posting the layout patch upstream…

The screenshot features dwm 6.1, xterm 327, mutt 1.8.0, weechat 1.4, vim 8.0.562, and screenfetch 3.7.0 & 3.8.0. The scheme is called base16-chalk and can be found in Chris Kempson’s base16 repository.

Edit: There’s a very similar patch upstream already so I’ll just share my simple one here, in case anyone’s interested: dwm-master-columns-6.1.diff

modulemd 1.1.0

This is a little belated announcement but let it be known that I released a new version of the module metadata library, modulemd-1.1.0, earlier this week!

This version changes the default behavior of the xmd block a little; it now defaults to being an empty dictionary rather than null. We’re also a lot smarter when it comes to loading the build and runtime dependencies blocks, reading the whole structures rather than assuming they are correct. Last but not least, it now also installs its test suite properly under modulemd.tests. That was a dumb bug. Sorry about that.

Flock 2016 Report

This time in Kraków, Poland.

This was, after Prague in 2014, the second Flock event I’ve attended so far. I got to my hotel on Monday evening and, given this was my first ever visit to the area, I hurried to explore the center a bit and, needless to say, find a decent local pub. The city was surprisingly beautiful and their refreshment wasn’t bad either. Anyway, to the main point!

The fourth year of the conference was held at Best Western Premier from Tuesday to Friday and, as always, it was packed with various talks and workshops, with the main theme, for me at least, being Modularity and Factory 2.0.

Modularity -- it's sweet

I spent most of the first day attending talks about Fedora infrastructure, Koji, COPR, even Docker, and, in the evening, learning about the city history and, well, socializing.

The big, long-awaited Modularity talk and demo took place on Wednesday. Langdon explained the basic idea behind the initiative and showed a short demo we managed to glue together just minutes before (and also during) the presentation — updates within selected update streams, switching between update streams, installation profiles and even a module build, monitoring its progress in a special service called Build Pipeline Overview, or BPO for short. For the time-constrained, Nils and Adam have prepared a quick video demonstrating some of the concepts. I’ll link to the full talk video once it’s published.

The room was full and the overall acceptance was unexpectedly positive, encouraging us to break things even more.

In the following talk, Ralph introduced the high-level concepts behind (not only) Modularity; what problems is our infrastructure and workflow facing today, and how to fix it.

Later that day I also attended the discussion on diversity in open source and a presentation about Insim.

We spent the evening on a boat, sailing the Wisla river, discussing the fascinating topics of the day over a beer.

Thursday and Friday were dedicated to lightning talks and workshops. The top secret Modularity session (it wasn’t announced until morning that day) was held on Thursday afternoon. During the two hours we had we explained how to build one’s very own module and submit it to our build pipeline. However, most of the time we had was dedicated to ad-hoc Q&A, which proved to be more valuable than helping people fight the difficulties of building things with the staging infrastructure — it is still too early and the hands-on experience is, well, suboptimal.

The Friday’s Server SIG Pow-Wow was mostly about Ansible and Rolekit. I didn’t have much to say about this but it got me thinking about how we could possibly integrate these technologies into modulemd and installation profiles. That’s for another post, another time.


All in all, I dare to say Flock #4 was pretty successful. I met a bunch of interesting and knowledgable people, exchanged ideas and opinions, and Polish beer wasn’t too bad either. I might be coming back someday.


It’s only been like ten years or so. Maybe more. I can’t really remember the last time I blogged about anything, anywhere. Well, you know what, I’ve decided to start again with this brand new, state of the art blog. Exciting times.

The focus will be pretty much anything I find interesting but expect mostly technical, free software-related stuff. We’ll see how it goes. Hopefully it won’t die within a week.

Signing off.