https://toabctl.wordpress.com/feed

During the last year I developed as a side project a new tool called chimg . That tool is useful to modify a given rootfs chroot directory in a declarative way. It can replace a kernel within a chroot, preseed snaps, install debian packages, add PPAs and more (documentation is in git but not yet published).

The nice thing about this is, that this tool can be integrated into livecd-rootfs (the tool that is usually used to build Ubuntu images) or future tools which might use the craft framework to build images. chimg automatically detects already bind-mounted filesystems (eg. /sys, /proc, …), detects already preseeded snaps and usually does that same thing that livecd-rootfs currently does when eg. replacing an already installed kernel.

Install chimg with:

sudo snap install chimg --classic

An example configuration (eg. config.yaml) to modify a rootfs chroot directory looks like this:

---
kernel: linux-aws
debs:
  - name: shim-signed
  - name: grub-pc
  - name: grub2-common
  - name: ubuntu-cloud-minimal
snap:
  assertion_brand: canonical
  assertion_model: aws-classic
  snaps:
    - name: hello
      channel: latest/stable
files:
  -
    destination: /etc/default/grub.d/70-mysettings.cfg
    content: |+
      GRUB_TIMEOUT=0

cmds_post:
  -
    cmd: |
      echo "Everything done"

This config (stored in config.yaml in this example) can be applied to a newly created (or existing) root filesystem directory. Let’s create one in /tmp/chimg-noble:

sudo mmdebstrap --variant=apt --verbose noble /tmp/chimg-noble

Let’s apply the config changes now:

sudo chimg --log-console chrootfs config.yaml /tmp/chimg-noble

That’s it. The modifications are now applied to the /tmp/chimg-noble directory.

I got a new SSD and did a fresh Ubuntu 23.04 install. What I usually do, is connecting the old disk via USB and copy data over from the old disk to the new SSD.

But my old disk used encrypted ZFS. It took me some time to figure out how to mount that that so here’s what I did.

The old disk gets detected as /dev/sda . There are 2 pools, rpool and bpool in my case. rpool is the one that contains my home directory and also the root directory. Let’s import that pool:

# zpool import -f rpool
# zpool list
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
rpool  1.81T  1.29T   536G        -         -    21%    71%  1.00x    ONLINE  -

After the pool import, there is now the LUKS encrypted keystore available under /dev/zvol/rpool/keystore . That keystore does contain the ZFS key for encrypting/decrypting. so let’s luksOpen that one:

# cryptsetup open /dev/zvol/rpool/keystore rpool-keystore
Enter passphrase for /dev/zvol/rpool/keystore: 
MY_SUPER_SECRET_PASSPHRASE 

And now the newly created mapper device for the opened crypt device:

# mount /dev/mapper/rpool-keystore /mnt/
# ls /mnt/
lost+found  system.key

So system.key is there. Let’s load it so ZFS can use it and clean up:

# cat /mnt/system.key | sudo zfs load-key -L prompt rpool
# umount /mnt
# cryptsetup close rpool-keystore

With zfs list the different datasets can be listed. To mount the /home/$USERNAME database, find the right one, change the mountpoint and mount it (/mnt/home-myuser must be created before):

# zfs list|grep home
rpool/USERDATA/myuser_xq8e3k                                                                        1.22T   478G      986G  /home/myuser
# zfs set mountpoint=/mnt/home-myuser rpool/USERDATA/myuser_xq8e3k
# zfs mount rpool/USERDATA/myuser_xq8e3k
ls /mnt/home-myuser  # this should show the files from your home now

That’s it. The last steps can be repeated to mount any other ZFS dataset (eg. the one for /)

Trying to share a GTK application window with https://meet.google.com/ might not work if you run under a Wayland session.

A workaround is to run a GTK application under XWayland:

GDK_BACKEND=x11 gedit

Now gedit can be shared within google meet.

If you want to share a gnome-terminal window, things are a bit more complicated. gnome-terminal has a client/server architecture so gnome-terminal-server needs to run with the x11 backend.

mkdir -p ~/.config/systemd/user/gnome-terminal-server.service.d/
cat <<EOF > ~/.config/systemd/user/gnome-terminal-server.service.d/override.conf
[Service]
Environment=GDK_BACKEND=x11
EOF
systemctl --user daemon-reload
systemctl --user restart gnome-terminal-server

The last command will kill all your terminals!

Now you can share your gnome-terminal windows again!

I recently blogged about Python packaging with py2pack . Meanwhile I created a new project called metaextract (available on github and pypi) based on the experience I made while improving py2pack.

metaextract does only one thing which is extracting the metadata from a python archive. Here’s an example – the output is JSON:

$ metaextract oslo.log-3.16.0.tar.gz 
{
 "data": {
 "data_files": null, 
 "entry_points": {
 "oslo.config.opts": [
 "oslo.log = oslo_log._options:list_opts"
 ]
 }, 
 "extras_require": {
 "fixtures": [
 "fixtures>=3.0.0 # Apache-2.0/BSD"
 ]
 }, 
 "has_ext_modules": null, 
 "install_requires": [
 "debtcollector>=1.2.0", 
 "oslo.config>=3.14.0", 
 "oslo.context>=2.6.0", 
 "oslo.i18n>=2.1.0", 
 "oslo.serialization>=1.10.0", 
 "oslo.utils>=3.16.0", 
 "pbr>=1.6", 
 "pyinotify>=0.9.6", 
 "python-dateutil>=2.4.2", 
 "six>=1.9.0"
 ], 
 "scripts": null, 
 "setup_requires": [
 "pbr>=1.8"
 ], 
 "tests_require": [
 "bandit>=1.1.0", 
 "coverage>=3.6", 
 "hacking<0.11,>=0.10.0", 
 "mock>=2.0", 
 "oslosphinx!=3.4.0,>=2.5.0", 
 "oslotest>=1.10.0", 
 "python-subunit>=0.0.18", 
 "reno>=1.8.0", 
 "sphinx!=1.3b1,<1.3,>=1.2.1", 
 "testrepository>=0.0.18", 
 "testscenarios>=0.4", 
 "testtools>=1.4.0"
 ]
 }, 
 "version": 1
}

The data is directly extracted from setuptools (or distutils). You can also run metaextract directly for a setup.py file:

$ python setup.py --command-packages=metaextract metaextract

or use it from your code:

$ python
>>> import pprint
>>> from metaextract import utils as meta_utils
>>> pprint.pprint(meta_utils.from_archive("oslo.log-3.16.0.tar.gz"))
{u'data': {u'data_files': None,
 u'entry_points': {u'oslo.config.opts': [u'oslo.log = oslo_log._options:list_opts']},
 u'extras_require': {u'fixtures': [u'fixtures>=3.0.0 # Apache-2.0/BSD']},
 u'has_ext_modules': None,
 u'install_requires': [u'debtcollector>=1.2.0',
 u'oslo.config>=3.14.0',
 u'oslo.context>=2.6.0',
 u'oslo.i18n>=2.1.0',
 u'oslo.serialization>=1.10.0',
 u'oslo.utils>=3.16.0',
 u'pbr>=1.6',
 u'pyinotify>=0.9.6',
 u'python-dateutil>=2.4.2',
 u'six>=1.9.0'],
 u'scripts': None,
 u'setup_requires': [u'pbr>=1.8'],
 u'tests_require': [u'bandit>=1.1.0',
 u'coverage>=3.6',
 u'hacking<0.11,>=0.10.0',
 u'mock>=2.0',
 u'oslosphinx!=3.4.0,>=2.5.0',
 u'oslotest>=1.10.0',
 u'python-subunit>=0.0.18',
 u'reno>=1.8.0',
 u'sphinx!=1.3b1,<1.3,>=1.2.1',
 u'testrepository>=0.0.18',
 u'testscenarios>=0.4',
 u'testtools>=1.4.0']},
 u'version': 1}

I was searching a bit to find a solution to compare versions for RPM packages in Python. So this is a reminder how to do it with the Python bindings for RPM:

$ python
>>> import rpm
>>> v1 = rpm.hdr()
>>> v2 = rpm.hdr()
>>> v1[rpm.RPMTAG_EPOCH] = 0
>>> v2[rpm.RPMTAG_EPOCH] = 0
>>> v1[rpm.RPMTAG_RELEASE] = "0"
>>> v2[rpm.RPMTAG_RELEASE] = "0"
>>> v1[rpm.RPMTAG_VERSION] = "1.2.3"
>>> v2[rpm.RPMTAG_VERSION] = "1.2.4"
>>> rpm.versionCompare(v1, v2)
-1

The return values are documented in the git repository .

• 1 means v1 is higher than v2
• 0 means v1 and v2 are qual
• -1 means v2 is higher than v1

Looks like this is not very well documented so hopefully this helps others.

The standard tool to create new Python packages for openSUSE is py2pack . The tool had some open issues so I decided to spend some time during SUSE’s Hack week to improve the tool.

The main problem with py2pack was, that the metadata detection (to get Requires and BuildRequires for RPM .spec files) was error prone because it parsed the setup.py from a sdist tarball to get the needed metadata. This was failing when

• variables are used for i.e. install_requires or extras_require
• No install_requires are specified (i.e. because pbr together with a requirements.txt file is used)
• the used regular expressions are not matching for various reasons

To get rid of theses problems, another way for getting the metadata was needed. And the new way is a custom distutils command . This command runs the setup.py to receive the metadata. The command can also be used standalone when py2pack is installed:

$ py2pack fetch oslo.log
$ tar xfz oslo.log-3.11.0.tar.gz 
$ cd oslo.log-3.11.0/
$ python setup.py --command-packages=py2pack get_metadata
running get_metadata
{
 "install_requires": [
 "pbr>=1.6", 
 "six>=1.9.0", 
 "oslo.config>=3.10.0", 
 "oslo.context>=2.4.0", 
 "oslo.i18n>=2.1.0", 
 "oslo.utils>=3.11.0", 
 "oslo.serialization>=1.10.0", 
 "debtcollector>=1.2.0", 
 "pyinotify>=0.9.6", 
 "python-dateutil>=2.4.2"
 ], 
 "entry_points": {
 "oslo.config.opts": [
 "oslo.log = oslo_log._options:list_opts"
 ]
 }, 
 "extras_require": {
 "fixtures": [
 "fixtures>=3.0.0 # Apache-2.0/BSD"
 ]
 }, 
 "tests_require": [
 "hacking<0.11,>=0.10.0", 
 "discover", 
 "python-subunit>=0.0.18", 
 "testrepository>=0.0.18", 
 "testscenarios>=0.4", 
 "testtools>=1.4.0", 
 "mock>=2.0", 
 "oslotest>=1.10.0", 
 "coverage>=3.6", 
 "sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2", 
 "oslosphinx!=3.4.0,>=2.5.0", 
 "reno>=1.6.2", 
 "bandit>=1.0.1"
 ]
}

And of course the command is integrated into py2pack so running:

$ py2pack generate oslo.log -f python-oslo.log.spec

generates a working .spec file. I did a new release on pypi so this work is integrated in version 0.6.3.

Happy packaging!

I have a Cubox-i and these are my notes to install Debian with the standard u-boot and linux kernel from the Debian archive.

Some requirements on the host:

apt-get install qemu-user-static debootstrap

Assuming the SD-Card is available as /dev/sdb :

# define our target device (mmc card) and the directory we use
export TARGETDEV=/dev/sdb
export MNTDIR=/mnt/tmp

# clean some blocks
dd if=/dev/zero of=$TARGETDEV bs=1M count=4

# create a single partition and ext4 filesystem
echo "n
p
1

w
"|fdisk $TARGETDEV
mkfs.ext4 -L rootfs "$TARGETDEV"1

mkdir -p $MNTDIR
mount "$TARGETDEV"1 $MNTDIR
mkdir -p $MNTDIR/etc/{default,flash-kernel}
echo "SolidRun Cubox-i Dual/Quad" >> $MNTDIR/etc/flash-kernel/machine
echo 'LINUX_KERNEL_CMDLINE="root=/dev/mmcblk0p1 rootfstype=ext4 ro rootwait console=ttymxc0,115200 console=tty1"' >> $MNTDIR/etc/default/flash-kernel
echo '/dev/mmcblk0p1 / ext4 defaults,noatime 0 0' >> $MNTDIR/etc/fstab

# get and install packages via debootstrap
qemu-debootstrap --foreign  --include=ntp,ntpdate,less,u-boot,u-boot-tools,flash-kernel,linux-image-armmp,kmod,openssh-server,firmware-linux-free,bash-completion,dialog,fake-hwclock,locales,vim --arch=armhf stretch $MNTDIR http://ftp.de.debian.org/debian/

# copy u-boot files to SD-Card (and it's 69, not 42. See cuboxi README from u-boot source tree)
dd if=$MNTDIR/usr/lib/u-boot/mx6cuboxi/SPL of=$TARGETDEV bs=1K seek=1
dd if=$MNTDIR/usr/lib/u-boot/mx6cuboxi/u-boot.img of=$TARGETDEV bs=1K seek=69

# set root password
chroot $MNTDIR passwd root
# serial console
echo 'T0:23:respawn:/sbin/getty -L ttymxc0 115200 vt100' >> $MNTDIR/etc/inittab

# hostname
echo "cubox" >> $MNTDIR/etc/hostname

# network eth0
cat <<eof>> $MNTDIR/etc/network/interfaces.d/eth0
auto eth0
allow-hotplug eth0
iface eth0 inet dhcp
eof

# loopback
cat <<eof>> $MNTDIR/etc/network/interfaces.d/lo
auto lo
iface lo inet loopback
eof

umount $MNTDIR

That’s it. Insert the SD-Card, connect with Putty or minicom and yo should see a booting system and be able to login.

I released d-feet 0.3.1 today. This is an unstable release and the first release based on Gtk+3, gobject-introspection and gdbus. A lot of code changed and I also removed some parts. If you are a dbus user, please test the release and give some feedback. You can find more information about d-feet on https://live.gnome.org/DFeet/.

Many thanks to Martin Pitt and John Palmieri for testing, suggestions and feedback!

Introspecting NetworkManager on the System Bus

Executed a method call

during the last week i started a small application called pictag to geotag my pictures.

The application is very simple. You select one or more pictures on the list, click on the map and all selected pictures have the exiv tags GPSLongitude, GPSLongitudeRef, GPSLatitude and GPSLatitudeRef set to the selected position. Maybe there are some bugs so make a backup of your pictures before you try it;)

The source is available at launchpad and there’s also a package in my ppa.

Update: Pictag is now available in Ubuntu’s software-center .