Status update, February 2022
Published one day late because of reasons, here is another status update.
Arts
This comes first, because it is what I dedicated most of my time recently. Well, I still have a problem regarding the “art” word as I am really not that great but more of a beginner.
Mostly, I am currently trying to learn and practising:
- Pixel-art; and
- Hand-drawing.
I started with pixel-art first — but as someone who does not know how to draw things properly, I realised that pixel art is not a magical shortcut. One still needs to know how to draw, even if twiddling with pixels.
Here is one realization of mine, using cubes because I can’t draw much more:
For hand drawing I am using Drawabox, and I have nothing special to show here. I am doing the exercises as well as practising on white paper and notebooks, nothing fancy (mostly boxes and triangles, if you really want to be disappointed).
Rust work
Gladis
I have released a new major version of gladis, named 2.0. This is a breaking change, because it is now requiring the latest 0.15 gtk-rs crate, instead of the previous 0.14 version in the 1.x versions series.
There are no major changes regarding the code itself, but there have been many changes in “chore” tasks like described in the CHANGELOG. Mainly, these have been:
- Making the project REUSE-compliant; and
- Making publishing new versions a lot easier, using automated tools.
Making projects REUSE-compliant
For the first point, I am now on making my new and maintained projects adhere to the software REUSE specification. I think that this is a great initiative.
Indeed, as a Debian individual contributor, figuring out the Copyright holders of big projects is always a mess. And if someone else from Redhat or another distribution wants to package the software, but does not know that this copyright checking has already been done in Debian, this madness has to be done again!
Detailing copyright holders directly in upstream using an automated format, instead of distributions, is the sanest solution in my opinion to transfer this burden to upstream (sometimes we are even “gessing” copyright holders by deep inspection of the commit history…).
Making releasing easy
Maintaining a package with two crates and keeping their versions synchronised is an “interesting” problem. I have been doing this manually for most of the history of this crate, but I am done with it. I am now using a set of related tools in order to release new versions (be it patch, minor or major) a breeze.
The tools that I have selected for this purpose are:
- git-cliff for automatic CHANGELOG generation; and
- cargo-release for automating the release process in general (calls git-cliff).
This process probably be more detailed in a dedicated article in the future. It can be (and will eventually be) reused in other crates in order to facilitate releasing.
I am also looking into creating a template for starting out new projects with everything configured, but it seems that Cargo templates are not available yet, so I will probably create a dedicated git repository for that.
Debian work
I have packaged two new fonts:
- fonts-national-park (available in unstable)
- fonts-routed-gothic (still in NEW, see ITP #1004995)
I also updated the popular fonts-ebgaramond to its latest git version in order to get some fixes that have not been published into a new, dedicated version by upstream.
Finally I have started packaging python-dt-schema (ITP #1005301) for my kernel tweaking needs, but after some yak shaking I am now blocked by dependencies planned to be packaged by other individuals, but actually not packaged yet.
Aaaand… that’s all! See you next time.