tracking changes between pypi package releases
I wondered if there is some tracking for differences between packages published on pypi, something that stores this information in a format similar to debdiff..
I wondered if there is some tracking for differences between packages published on pypi, something that stores this information in a format similar to debdiff..
Been looking into some existant sshd implementations in go. Most of the projects on github seem to use the standard x/crypto/ssh lib.
Besides several bugfixes, the latest version now supports using higher compression levels and logging to syslog facility. I also finished packaging and official packages are now available,
Next year my son will turn 4. I have quit playing computer games for a pretty long time now, but recently i questioned myself: what will be the first computer game hes going to play? Why not create a simple game by myself?
Latest virtnbdbackup version now supports backing up remote libvirt hosts, too. No installation on the hypervisor required anymore:
Had some time to add more features to my libvirt backup utility, now it supports:
Everyone knows that an application exit code should change based on the success, error or maybe warnings that happened during execution.
fs.com s5850 and s8050 series type switches have a secret mode which lets you enter a regular shell from the switch cli, like so:
In my last article i showed how to use the new features included in Debian Bullseye to easily create backups of your libvirt managed domains.
The libvirt and qemu versions in Debian Bullseye support a new feature that allows for easier backup and recovery of virtual machines. Instead of using snapshots for backup operation, its now possible to enable dirty bitmaps. Other hypervisors tend to call this “changed block tracking”.
I depend on full provisioned virtual machine images for CI and unfortunately a major part of our customers still uses parts of the software i need to test on Windows 10. My environment uses vagrant for provisioning Windows 10 based images and then executes several tasks using the vagrant provisioning feature.
Running a CI testsuite on Intel (or ARM) based hardware is quite common these days. Most of the time the software stacks involved are containers (insert your favourite container orchestrator here) or other neat solutions such as vagrant that allow to spin up pristine test environments.
Github actions are a nice thing, spin up your preferred operating system and execute some tests. While implementing them in one of my projects, i had to trial and error and: waiting for the tests to complete is an annoying situation!
This story starts with me having to simulate a faulty disk device for testing. The Linux Kernel Device mapper is a good solution for this, so i created a faulty device with a simple file backend: