Screenshot, March 11, 2018

Felt in a mood to tweak my window manager config and features again. The colour scheme is still base16-chalk but I switched to Source Code Pro as the main font. I also started using the tilegap and swallow dwm patches, the latter of which needed some extra patching.

The screenshot features dwm 6.1, xterm 330, mutt 1.9.2, weechat 2.0.1, google-chrome 65.0.3325.146, vim 8.0.1553, portage 2.3.19, screenfetch 3.7.0 & 3.8.0, and zsh 5.4.1.

And yes, I’m looking into Rust. Seems fun so far.

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.

artifacts:
    rpms:
        - 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.

buildopts:
    rpms:
        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.