The Linux Kernel git repo has a spec file that builds the Kernel RPM. However, it does not build perf or any of the other userland tools. I want to build a perf RPM using the same code as is used to build the Kernel RPM.
Here are my debugging notes.
Continue readinghttps://gnome.pages.gitlab.gnome.org/libxml2/xmllint.htmlLets say you want to see what src RPMs are in a given yum repo. If the author used createrepo to create the yum repo, it should be an a fairly standard layout. The following xpath query should pull it out.
Note that you can get xmllint to run the xpath query from libxml2
curl http://$yumserver/$somerepo/ > repo.html
xmllint --html --xpath "//html/body/table/tr/td/a/@href" repo.html | grep srcThe portion of the query a/@href will match a tag like this
<a href="https://blam.src.rpm">I can do anything. I can’t do everything. –Me
Anything worth doing is worth doing in a way you can check in to git. To recall what I did from the command line, I should turn those actions into a persist-able document. Do I? Not often enough. Often I rely on bash history to remind me of what I did last time. Since the machines I work on are out of a global pool, I have been burned by not recording commands before relinquishing a machine.
For complex series of tasks, it makes sense to execute a bash script to perform those tasks, and I have many of these. Shell scripting excels in doing command line tasks. Where it does not do so well is on tasks that are split over multiple machines. While curl is great for pulling and pushing files to webservers, the majority of my remote work requires ssh and scp to set things up. This is where Ansible comes in: If I can make a playbook that records the commands I use to perform that action, I can repeat it on another machine.
Here is what my workflow looks like as I try to get better at it:
Continue readingOne benefit of working in a hardware company is that you actually have hardware. I have worked in software for a long time, and I have learned to appreciate when new servers are not such a scarce resource as to impact productivity. However, hardware in our group needs to be shared amongst a large group of developers, and constantly reserved, assigned, and reprovisioned. We use an install of the booked scheduler to reserve servers. As with many tools, I am most interested in using it in a scripted fashion. Booked comes with an API. Here’s some of the things I can do with it.
Continue readingI competed in two triathlons this summer: Amesbury and Sharon, both in Massachusetts. I want to record my times so I can compare them to future races.
This was a first for me, and I was not ultra-competitive. My goal for each was completion.
Continue readingHow can I create a binary kernel RPM that has patches that have not yet merged into the mainline kernel? One approach to building the Kernel RPM is to use the Makefile option provided with the Kernel. While we typically do this, it does not provide us with the user land tools like perf and its libraries used to test certain patches.
An alternative approach is to take the Fedora Kernel Source RPM that matches the targeted upstream Kernel version, and modify it to apply the set of patches. Here is a walk-through of the process I just got to succeed.
My job requires me to perform operations on multiple machines. These operation can either be against the platform management server (reboot, change firmware options) or via an remote connection to the operating system running on that machine. Here’s how I manage the scripts to simplify my work.
Continue readingsudo 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 reading