Arch Linux User Repository

@Toolybird I've run into an issue depending on a kernel while not caring whether it is the LTS or regular or some other kernel. You can fudge it because there are some things both provide, but they are not super appropriate. Has there been an issue opened on any of the kernel packages to add a more generic virtual-provides? Also is it really the kernel or is it the kernel headers that is actually needed here? Perhaps the linux-api-headers package is actually what this needs?

To build in clean chroot I had to add 'linux' to makedepends

I use a personal build of libguestfs and it depends on 'linux' as it should [1]. The Arch repo pkg doesn't do this which seems wrong. Although, it's complicated by the fact that other kernels do exist, but unfortunately there is no virtual "kernel" provides option.

I will begrudgingly add a makedep on 'linux' in the next update.

[1] https://github.com/libguestfs/libguestfs/blob/v1.50.1/appliance/packagelist.in#L108

To build in clean chroot I had to add 'linux' to makedepends.

I get the following error on guestfish usages (inside _create_img function):

Syncing disks.
libguestfs: error: /usr/bin/supermin exited with error status 1.
To see full error messages you may need to enable debugging.
Do:
  export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1
and run the command again.  For further information, read:
  http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs
You can also run 'libguestfs-test-tool' and post the *complete* output
into a bug report or message to the libguestfs mailing list.
==> ERROR: A failure occurred in build().
    Aborting...

Adding export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1 before the first guestfish usage on _create_img, I get the following error:

Syncing disks.
libguestfs: trace: set_verbose true
libguestfs: trace: set_verbose = 0
libguestfs: create: flags = 0, handle = 0x564ed0e6c3b0, program = guestfish
libguestfs: trace: set_pgroup true
libguestfs: trace: set_pgroup = 0
libguestfs: trace: add_drive "img.bin"
libguestfs: trace: add_drive = 0
libguestfs: trace: launch
libguestfs: trace: max_disks
libguestfs: trace: max_disks = 255
libguestfs: trace: get_tmpdir
libguestfs: trace: get_tmpdir = "/tmp"
libguestfs: trace: version
libguestfs: trace: version = <struct guestfs_version = major: 1, minor: 50, release: 1, extra: , >
libguestfs: trace: get_backend
libguestfs: trace: get_backend = "direct"
libguestfs: launch: program=guestfish
libguestfs: launch: version=1.50.1
libguestfs: launch: backend registered: direct
libguestfs: launch: backend registered: libvirt
libguestfs: launch: backend=direct
libguestfs: launch: tmpdir=/tmp/libguestfsRPYiGm
libguestfs: launch: umask=0022
libguestfs: launch: euid=1000
libguestfs: trace: get_cachedir
libguestfs: trace: get_cachedir = "/var/tmp"
libguestfs: begin building supermin appliance
libguestfs: run supermin
libguestfs: command: run: /usr/bin/supermin
libguestfs: command: run: \ --build
libguestfs: command: run: \ --verbose
libguestfs: command: run: \ --if-newer
libguestfs: command: run: \ --lock /var/tmp/.guestfs-1000/lock
libguestfs: command: run: \ --copy-kernel
libguestfs: command: run: \ -f ext2
libguestfs: command: run: \ --host-cpu x86_64
libguestfs: command: run: \ /usr/lib/guestfs/supermin.d
libguestfs: command: run: \ -o /var/tmp/.guestfs-1000/appliance.d
supermin: version: 5.3.2
supermin: package handler: arch/pacman
supermin: acquiring lock on /var/tmp/.guestfs-1000/lock
supermin: build: /usr/lib/guestfs/supermin.d
supermin: reading the supermin appliance
supermin: build: visiting /usr/lib/guestfs/supermin.d/base.tar.gz type gzip base image (tar)
supermin: build: visiting /usr/lib/guestfs/supermin.d/daemon.tar.gz type gzip base image (tar)
supermin: build: visiting /usr/lib/guestfs/supermin.d/excludefiles type uncompressed excludefiles
supermin: build: visiting /usr/lib/guestfs/supermin.d/hostfiles type uncompressed hostfiles
supermin: build: visiting /usr/lib/guestfs/supermin.d/init.tar.gz type gzip base image (tar)
supermin: build: visiting /usr/lib/guestfs/supermin.d/packages type uncompressed packages
supermin: build: visiting /usr/lib/guestfs/supermin.d/udev-rules.tar.gz type gzip base image (tar)
supermin: mapping package names to installed packages
supermin: resolving full list of package dependencies
supermin: build: 188 packages, including dependencies
supermin: build: 46753 files
supermin: build: 25851 files, after matching excludefiles
supermin: build: 25869 files, after adding hostfiles
supermin: build: 25864 files, after removing unreadable files
supermin: build: 25873 files, after munging
supermin: kernel: looking for kernel using environment variables ...
supermin: kernel: looking for kernels in /lib/modules/*/vmlinuz ...
supermin: kernel: looking for kernels in /boot ...
supermin: failed to find a suitable kernel (host_cpu=x86_64).

I looked for kernels in /boot and modules in /lib/modules.

If this is a Xen guest, and you only have Xen domU kernels
installed, try installing a fullvirt kernel (only for
supermin use, you shouldn't boot the Xen guest with it).
libguestfs: error: /usr/bin/supermin exited with error status 1, see debug messages above
libguestfs: trace: launch = -1 (error)
libguestfs: trace: close
libguestfs: closing guestfs handle 0x564ed0e6c3b0 (state 0)
libguestfs: command: run: rm
libguestfs: command: run: \ -rf /tmp/libguestfsRPYiGm
==> ERROR: A failure occurred in build().
    Aborting...

As workaround for "I looked for kernels in /boot and modules in /lib/modules.", adding linux or some kernel in makedepends cause supermin to works and the build to complete.

the checksum validation fails :(

ventoy-fix-array.array.tostring-removal-in-python-3.9.patch ... FAILED

Unfortunately I got the same error as well.

@itsme, thanks. GitHub cannot be trusted to maintain a stable URL...grrr. Will fix.

-index ad556710802..4be7957138a 100755
+index ad556710802e..4be7957138a5 100755

==> Validating source files with sha256sums...
    ventoy-1.0.90.tar.gz ... Passed
    grub-2.04.tar.xz ... Passed
    ventoy-grub-fix-build-with-binutils-2.36.patch ... Passed
    ipxe ... Skipped
    edk2-stable201911.zip ... Passed
    ventoy-fix-ucs-2-lookup-on-python-3.9.patch ... Passed
    ventoy-fix-array.array.tostring-removal-in-python-3.9.patch ... FAILED
    dietlibc-0.34.tar.xz ... Passed
    dietlibc-headers-fix.patch ... Passed
    musl-1.2.3.tar.gz ... Passed
    kernel-headers-musl-4.19.88.tar.gz ... Passed
    fuse-2.9.9.tar.gz ... Passed
    exfat-1.3.0.tar.gz ... Passed
    zlib-1.2.13.tar.gz ... Passed
    squashfs-tools-4.4.tar.gz ... Passed
    device-mapper-1.02.28-2.el5.src.rpm ... Passed
    zstd-1.0.0.tar.gz ... Passed
    xz-embedded-20130513.tar.gz ... Passed
    busybox-1.32.0.tar.bz2 ... Passed
    cryptsetup-1.7.5.tar.xz ... Passed
    wimboot-2.7.3.tar.gz ... Passed
==> ERROR: One or more files did not pass the validity check!
error: failed to download sources for 'ventoy-1.0.90-1': 

@Toolybird Even if it does go away it will move out of the repos into the AUR which would be fine for this package's purpose, but we still have various things depending on it so even that is not happening yet. I bumped it because there was an upstream release.

@alerque, have updated now so hopefully fixed. While I have your attention, what is the plan for exfat-utils? It was going away at one point but was updated recently. I could possibly depend on it here and simplify the build a bit if it is staying.

Oh MacGyver holy bananas! I've several times wanted a source alternative to ventoy-bin and considered making one, seeing this makes me glad I never actually sat down to try.

P.S. As of now this is not passing validity checks. Looks like you forgot to bump checksums after editing a patch.