Copy to Clipboard in QT

The first time I tried to implement clipboard copy in QT all seemed easy. Just call setText on QClipboard object.

QClipboard* clipboard = QApplication::clipboard();
clipboard->setText(text);

Really simple and it doesn’t really work. Well, actually, it depends. If you run this under Windows, it works perfectly. If you run this under Linux, it works until you try to paste into Terminal window. Once you do, you will surprisingly see that clipboard used for Terminal isn’t the same clipboard as for the rest of system. But then you read documentation again and learn a bit about selection clipboard.

QClipboard* clipboard = QApplication::clipboard();

clipboard->setText(text, QClipboard::Clipboard);

if (clipboard->supportsSelection()) {
    clipboard->setText(text, QClipboard::Selection);
}

And now you have a fool-proof setup for both Linux and Windows, right? Well, you’ll notice that in Linux some copy operations are simply ignored. You believe you copied text but the old clipboard content gets pasted. So you copy again just to be sure and it works. Since failure is sporadic at best, you might even convince something is wrong with you keyboard.

However, the issue is actually in timing of clipboard requests. If your code proceeds immediately with other tasks Linux (actually it’s X11 problem but let’s blame Linux ;)) might not recognize the new clipboard content. What you need is a bare minimum pause to be sure system had chance to take control and store the new clipboard information.

QClipboard* clipboard = QApplication::clipboard();

clipboard->setText(text, QClipboard::Clipboard);

if (clipboard->supportsSelection()) {
    clipboard->setText(text, QClipboard::Selection);
}

#if defined(Q_OS_LINUX)
    QThread::msleep(1); //workaround for copied text not being available...
#endif

And now this code finally works for both Linux and Windows.

Adding WinBox to Ubuntu Applications Menu

If you need to run Mikrotik’s WinBox under Ubuntu, solution is wine and 64-bit WinBox download. It works, as far as I can tell, flawlessly. However, I found dropping to command line every time I want to run it, a bit annoying.

Adding WinBox to activities is a two step process. The first step being creation of winbox.desktop file. In its simplest form it can look something like this

[Desktop Entry]
Type=Application
Name=WinBox
Exec=wine ^^/home/user/Apps/winbox64.exe^^

Then, to get application officially registered, we just need to let system know about it:

sudo desktop-file-install winbox.desktop

And this is all it takes for WinBox to find it’s home among other applications.

Installing UEFI ZFS Root on Ubuntu 19.10

There is a newer version of this guide for Ubuntu 20.04.

With Ubuntu 19.10 there is finally (experimental) ZFS setup option. And frankly, you should use it instead of the manual installation procedure. However, manual installation does offer it’s advantages - especially when it comes to pool layout and naming. If manual installation is needed, there is great Root on ZFS installation guide that’s part of ZFS-on-Linux project but its final ZFS layout is a bit too complicated for my taste. Here is my somewhat simplified version of the same intended for a singe disk installations.

After booting into Ubuntu desktop installation we want to get a root prompt. All further commands are going to need root credentials anyhow.

sudo -i

The very first step should be setting up a few variables - disk, pool, host name, and user name. This way we can use them going forward and avoid accidental mistakes. Just make sure to replace these values with ones appropriate for your system.

DISK=/dev/disk/by-id/^^ata_disk^^
POOL=^^ubuntu^^
HOST=^^desktop^^
USER=^^user^^

To start the fun we need debootstrap package. With 19.10 ZFS is available in main repository so we don’t need to add universe as in the previous Ubuntu versions.

apt install --yes debootstrap

General idea of my disk setup is to maximize amount of space available for pool with the minimum of supporting partitions. If you are planning to have multiple kernels, increasing boot partition size might be a good idea. Major change as compared to my previous guide is partition numbering. While having partition layout different than partition order had its advantages, a lot of partition editing tools would simply “correct” the partition order to match layout and thus cause issues down the road.

sgdisk --zap-all                        $DISK

sgdisk -n1:1M:+127M -t1:EF00 -c1:EFI    $DISK
sgdisk -n2:0:+512M  -t2:8300 -c2:Boot   $DISK
sgdisk -n3:0:0      -t3:8309 -c3:Ubuntu $DISK

sgdisk --print                          $DISK

Unless there is a major reason otherwise, I like to use disk encryption.

cryptsetup luksFormat -q --cipher aes-xts-plain64 --key-size 512 \
    --pbkdf pbkdf2 --hash sha256 $DISK-part3

Of course, you should also then open device. I liku to use disk name as the name of mapped device, but really anything goes.

LUKSNAME=`basename $DISK`
cryptsetup luksOpen $DISK-part3 $LUKSNAME

Finally we’re ready to create system ZFS pool.

zpool create -o ashift=12 -O compression=lz4 -O normalization=formD \
    -O acltype=posixacl -O xattr=sa -O dnodesize=auto -O atime=off \
    -O canmount=off -O mountpoint=none -R /mnt/install $POOL /dev/mapper/$LUKSNAME
zfs create -o canmount=noauto -o mountpoint=/ $POOL/root
zfs mount $POOL/root

Assuming UEFI boot, two additional partitions are needed. One for EFI and one for booting. Unlike what you get with the official guide, here I don’t have ZFS pool for boot partition but a plain old ext4. I find potential fixup works better that way and there is a better boot compatibility. If you are thinking about mirroring, making it bigger and ZFS might be a good idea. For a single disk, ext4 will do.

yes | mkfs.ext4 $DISK-part2
mkdir /mnt/install/boot
mount $DISK-part2 /mnt/install/boot/

mkfs.msdos -F 32 -n EFI $DISK-part1
mkdir /mnt/install/boot/efi
mount $DISK-part1 /mnt/install/boot/efi

Bootstrapping Ubuntu on the newly created pool is next. This will take a while.

debootstrap eoan /mnt/install/

zfs set devices=off $POOL

Our newly copied system is lacking a few files and we should make sure they exist before proceeding.

echo $HOST > /mnt/install/etc/hostname
sed "s/ubuntu/$HOST/" /etc/hosts > /mnt/install/etc/hosts
sed '/cdrom/d' /etc/apt/sources.list > /mnt/install/etc/apt/sources.list
cp /etc/netplan/*.yaml /mnt/install/etc/netplan/

If you are installing via WiFi, you might as well copy your wireless credentials:

mkdir -p /mnt/install/etc/NetworkManager/system-connections/
cp /etc/NetworkManager/system-connections/* /mnt/install/etc/NetworkManager/system-connections/

Finally we’re ready to “chroot” into our new system.

mount --rbind /dev  /mnt/install/dev
mount --rbind /proc /mnt/install/proc
mount --rbind /sys  /mnt/install/sys
chroot /mnt/install \
    /usr/bin/env DISK=$DISK POOL=$POOL USER=$USER LUKSNAME=$LUKSNAME \
    bash --login

Let’s not forget to setup locale and time zone.

locale-gen --purge "en_US.UTF-8"
update-locale LANG=en_US.UTF-8 LANGUAGE=en_US
dpkg-reconfigure --frontend noninteractive locales

dpkg-reconfigure tzdata

Now we’re ready to onboard the latest Linux image.

apt update
apt install --yes --no-install-recommends linux-image-generic linux-headers-generic

Followed by boot environment packages.

apt install --yes zfs-initramfs cryptsetup keyutils grub-efi-amd64-signed shim-signed

Since we’re dealing with encrypted data, we should auto mount it via crypttab. If there are multiple encrypted drives or partitions, keyscript really comes in handy to open them all with the same password. As it doesn’t have negative consequences, I just add it even for a single disk setup.

echo "$LUKSNAME UUID=$(blkid -s UUID -o value $DISK-part3) none \
    luks,discard,initramfs,keyscript=decrypt_keyctl" >> /etc/crypttab
cat /etc/crypttab

To mount EFI and boot partitions, we need to do some fstab setup too:

echo "PARTUUID=$(blkid -s PARTUUID -o value $DISK-part2) \
    /boot ext4 noatime,nofail,x-systemd.device-timeout=5s 0 1" >> /etc/fstab
echo "PARTUUID=$(blkid -s PARTUUID -o value $DISK-part1) \
    /boot/efi vfat noatime,nofail,x-systemd.device-timeout=5s 0 1" >> /etc/fstab
cat /etc/fstab

Now we get grub started and update our boot environment. Due to Ubuntu 19.10 having some kernel version kerfuffle, we need to manually create initramfs image. As before, boot cryptsetup discovery errors during mkinitramfs and update-initramfs as OK.

KERNEL=`ls /usr/lib/modules/ | cut -d/ -f1 | sed 's/linux-image-//'`
update-initramfs -u -k $KERNEL

Grub update is what makes EFI tick.

update-grub
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Ubuntu \
    --recheck --no-floppy

Finally we install out GUI environment. It’ll take ages.

apt-get install --yes ubuntu-desktop samba

Short package upgrade will not hurt.

apt dist-upgrade --yes

We can omit creation of the swap dataset but I personally find a small one handy.

zfs create -V 4G -b $(getconf PAGESIZE) -o compression=off -o logbias=throughput \
    -o sync=always -o primarycache=metadata -o secondarycache=none $POOL/swap
mkswap -f /dev/zvol/$POOL/swap
echo "/dev/zvol/$POOL/swap none swap defaults 0 0" >> /etc/fstab
echo RESUME=none > /etc/initramfs-tools/conf.d/resume

If one is so inclined, /home directory can get a separate dataset too.

rmdir /home
zfs create -o mountpoint=/home $POOL/home

And now we create the user.

adduser $USER

The only remaining task before restart is to assign extra groups to user and make sure its home has correct owner.

usermod -a -G adm,cdrom,dip,lpadmin,plugdev,sambashare,sudo $USER
chown -R $USER:$USER /home/$USER

As install is ready, we can exit our chroot environment.

exit

And cleanup our mount points.

umount /mnt/install/boot/efi
umount /mnt/install/boot
mount | grep -v zfs | tac | awk '/\/mnt/ {print $3}' | xargs -i{} umount -lf {}
zpool export -a

After the reboot you should be able to enjoy your installation.

reboot

PS: There are versions of this guide using the native ZFS encryption for other Ubuntu versions: 21.10 and 20.04

PPS: For LUKS-based ZFS setup, check the following posts: 20.04, 19.04, and 18.10.

Using Different Key for GitHub Push

If your default id_rsa key is different than the one you use for GitHub, it’s still possible to use simple git push regardless. Trick is in adding mapping to identity file in ~/.ssh/config:

Host github.com
  User git
  IdentityFile ^^~/.ssh/id_rsa_github^^
  IdentitiesOnly yes

This will ensure all communication with github.com uses id_rsa_github key.

Coloring Make Output

Considering how verbose make output is, it’s really easy to miss warnings or errors. What we need is a bit of color. However, make being such an old program, doesn’t support any ANSI coloring. However, since both errors and warnings have standardized formats, it’s relativelly easy to use grep to color them.

For example:

make | grep --color=always -e '^Makefile:[0-9]\+:.*' -e '^'

This will color all lines following the Makefile:number: format in default color. Extending this for catching errors is similar as there is just an extra match of “.Stop”:

make | grep --color=always -e '^Makefile:[0-9]\+:.*  Stop\.$' -e '^'

But what if we want to have warnings in yellow and errors in red? Well, then we get to use GREP_COLOR variable and pass grep twice:

make | GREP_COLOR='01;31' grep --color=always -e '^Makefile:[0-9]\+:.*  Stop\.$' -e '^' \
     | GREP_COLOR='01;33' grep --color=always -e '^Makefile:[0-9]\+:.*' -e '^'

And yes, the order of greps is important as we first want to capture errors. Matched lines are to be colored red (01;31) and prefixed with ANSI escape sequence thus preventing the second grep matching. Lines matching the second grep will get similar treatment, just in yellow (01;33).

Instead of remembering this, we can create a new amake function that will do the coloring:

function amake() {
    make "$@" 2>&1 | \
        GREP_COLOR='01;31' grep --color=always -e '^Makefile:[0-9]\+:.*  Stop\.$' -e '^' | \
        GREP_COLOR='01;33' grep --color=always -e '^Makefile:[0-9]\+:.*' -e '^'
}

So, now when we call function, we can see issues a bit more quickly:

amake