sudo virt-install --name fedora40 --os-variant fedora40 --disk /var/lib/libvirt/images/Fedora-Cloud-Base-Generic.x86_64-40-1.14.qcow2 --import --cloud-init root-ssh-key=/home/ayoung/.ssh/id_rsa.pub
Before code goes up stream, it should be rigorously tested. In order to do so, we build Kernels based on the corresponding Fedora version, as Fedora tracks Linux Stable fairly closely. However, we want to be able to distinguish between a Kernel we build with one that comes from Fedora.
Continue readingIf you have a config fragment that you want included in your Linux config file, you can use the make system to add it to the existing config. For example, I have a file called: kernel/configs/ampere-topic-mctp.config that looks like this:
CONFIG_MCTP_TRANSPORT_PCC=mThis tells the make system to change CONFIG_MCTP_TRANSPORT_PCC from the default (=n) to module (=m) when building. To include this config fragment, I append it to the make file command to build the config file. For example:
make olddefconfig ampere-topic-mctp.configThis can be done with multiple fragments.
git rebase HEAD~4 --exec 'git commit --amend --author "Adam Young admiyo@os.amperecomputing.com" --no-edit'Developing long running tasks might be my least favorite coding activity. I love writing and debugging code…I’d be crazy to be in this profession if I did not. But when a task takes long enough, your attention wanders and you get out of the zone.
Building the Linux Kernel takes time. Even checking the Linux Kernel out of git takes a non-trivial amount of time. The Ansible work I did back in the OpenStack days to build and tear down environments took a good bit of time as well. How do I keep from getting out of the zone while coding on these? It is hard, but here are some techniques.
As much as I try to be a “real” programmer, the reality is that we need automation, and setting up automation is a grind. A necessary grind.
One thing that I found frustrating was that, in order to test our automation, I needed to kick off a pipeline in our git server (gitlab, but the logic holds for others) even though the majority of the heavy lifting was done in a single bash script.
In order to get to the point where we could run that script in a gitlab runner, we needed to install a bunch of packages (Dwarves, Make, and so forth) as well as do some SSH Key provisioning in order to copy the artifacts off to a server. The gitlab-ci.yml file ended up being a couple doze lines long, and all those lines were bash commands.
So I pulled the lines out of gitlab-ci.yml and put them into the somewhat intuitively named file workflow.sh. Now my gitlab-ci.yml file is basically a one liner that calls workflow.sh.
But I also made it so workflow.sh can be called from the bash command line of a new machine. This is the key part. By doing this, I am creating automation that the rest of my team can use without relying on gitlab. Since the automation will be run from gitlab, no one can check in a change that breaks the CI, but they can make changes that will make life easier for them on the remote systems.
The next step is to start breaking apart the workflow into separate pipelines, due to CI requirements. To do this, I do three things:
The reason for the last split is to keep logic from creeping into the pipeline functions. They are merely interfaces to the single set of logic in functions.sh.
The goal of having the separate functions source-able is to be able to run interior steps of the overall processing without having to run the end-to-end work. This is to save the sitting-around time for waiting for a long running process to complete….more on that in a future article.
Things have diverged a bit from the docs. Just want to document here what I got working:
I had already checked out Keystone and run the unit tests.
I needed uwsgi
sudo apt install uwsgi-core
sudo apt install uwsgi-plugin-python3
Then a modified command line to run the server:
uwsgi --http-socket 127.0.0.1:5000 --plugin /usr/lib/uwsgi/plugins/python3_plugin.so --wsgi-file $(which keystone-wsgi-public)This got me the last part
https://stackoverflow.com/questions/31330905/uwsgi-options-wsgi-file-and-module-not-recognized
Musescore is a wonderful tool. It has made a huge impact on my musical development over the past couple decades. Sheet music is the primary way I communicate and record musical ideas, and Musescore the tool and musecore.com have combined to make a process that works for me and my musical needs.
I have also spent a few years writing software, and the methods that we have learned to use in software development have evolved due to needs of scale and flexibility. I would like to apply some of those lessons to how I manage sheet music. But there are disconnects.
The biggest issue I have is that I want the same core song in multiple different but related formats. The second biggest issue is that I want to be able to make changes to a song, and to collaborate with other composers in making those changes.
Continue readingAny new technology requires a mental effort to understand. When trying to automate the boring stuff, one decision I have to make is whether to use straight shell scripting or whether to perform that operation using Ansible. What I want to do is look at a simple Ansible playbook I have written, and then compare what the comparable shell script would look like to determine if it would help my team to use Ansible or not in this situation.
Continue reading