If the lzma package is installed, "depthchargectl build" fails:

  $ depthchargectl build --board amd64-generic -vvv
  [...]
  Failed while creating depthcharge image.
  Traceback (most recent call last):
    File "/usr/lib/python3/dist-packages/depthcharge_tools/depthchargectl/_build.py", line 558, in __call__
      mkdepthcharge(
      ~~~~~~~~~~~~~^
          arch=self.board.arch,
          ^^^^^^^^^^^^^^^^^^^^^
      ...<12 lines>...
          verbosity=self.verbosity,
          ^^^^^^^^^^^^^^^^^^^^^^^^^
      )
      ^
    File "/usr/lib/python3/dist-packages/depthcharge_tools/utils/argparse.py", line 863, in __normal_call
      retval = inst(*args, **kwargs)
    File "/usr/lib/python3/dist-packages/depthcharge_tools/utils/argparse.py", line 799, in __call__
      return call(self)
    File "/usr/lib/python3/dist-packages/depthcharge_tools/mkdepthcharge.py", line 960, in __call__
      with vmlinuz.open("r+b") as f, mmap(f.fileno(), 0) as data:
                                     ~~~~^^^^^^^^^^^^^^^
  ValueError: cannot mmap an empty file
  [...]

The reason is that d-t tries decompressing with available programs to see
if the file is compressed, and "lzma -dc /boot/vmlinuz-$(uname -r)"
returns empty output with exit status zero even though the file isn't
compressed by lzma. So we end up trying to process the empty output as
the kernel binary.

Regardless of if the lzma behaviour is a bug, we should check against
this successful-but-empty decompression result when checking if files
are compressed to avoid this.

Luckily lzma isn't automatically installed along with kernel or
initramfs-tools etc., and depthcharge-tools depends on xz-utils which
provides lzma anyway, so I guess it wouldn't be installed except if
installed explicitly (as I did for testing).

Attaching patch I'm planning to commit upstream.