Arch Linux User Repository

Apparently which is only member of base-devel, not base so it needs be an explicit dependency. Oh well, I'll update it again shortly.

Thanks Foucault!

Here's another thing I found: An edge case that occurs when the which package is not installed on the target system. That's rare, but occurred to me when building the package on one system while installing it on another, minimalist system.

In the absence of the which utility, /usr/lib/udev/gpib_udev_fxloader fails in a mysterious way. Installing which solves it.

So this should probably be an explicit dependency of this package.

Thanks for reporting this; I will update the package as soon as I can

The DKMS installation of this package fails with a compile error in /usr/src/linux-gpib-4.3.6/drivers/gpib/gpio/gpib_bitbang.c, which seems to be a driver that is meant for RPi only.

This is probably something that has to be fixed upstream. I got it to compile by removing the gpio directory from the makefile. Patched PKGBUILD by adding

sed -i -e 's/obj-y += gpio\///g' drivers/gpib/Makefile

to the kernel module section of the prepare function.

The firmware loader in the https://aur.archlinux.org/packages/fxload package has changed in a way that breaks integration with this package. E.g., it will not load the firmware of my Agilent 82357B any more. See the remark of the maintainer of the fxload package: https://aur.archlinux.org/packages/fxload#comment-972226.

I solved it by adding -p $BUSNUM,$DEVNUM to the FXLOAD_OPTIONS in /usr/lib/udev/gpib_udev_fxloader. This can be done, e.g., by patching PKGBUILD, adding a line at the end of the prepare function:

sed -i -e 's/fx2/fx2 -p \$BUSNUM,\$DEVNUM/g' usb/gpib_udev_fxloader.in

Is this something that can be added permanently to the package?

plz add aarch64 support. I have tested ok on my ARM Box running Arch Linux ARM.

# PKGBUILD
arch=('i686' 'x86_64' 'aarch64')

With the latest 6.4.4-arch1-1 kernel, the DKMS installation fails:

In file included from ./include/linux/linkage.h:7,
                 from ./arch/x86/include/asm/cache.h:5,
                 from ./include/linux/cache.h:6,
                 from ./arch/x86/include/asm/current.h:9,
                 from ./include/linux/sched.h:12,
                 from ./include/linux/ratelimit.h:6,
                 from ./include/linux/dev_printk.h:16,
                 from ./include/linux/device.h:15,
                 from /var/lib/dkms/linux-gpib/4.3.5/build/compat/include/linux/device.h:82,
                 from /var/lib/dkms/linux-gpib/4.3.5/build/drivers/gpib/include/compat_device_create.h:30,
                 from /var/lib/dkms/linux-gpib/4.3.5/build/drivers/gpib/sys/osinit.c:20:
/var/lib/dkms/linux-gpib/4.3.5/build/drivers/gpib/sys/osinit.c: In function ‘gpib_common_init_module’:
./include/linux/export.h:27:22: error: passing argument 1 of ‘class_create’ from incompatible pointer type [-Werror=incompatible-pointer-types]
   27 | #define THIS_MODULE (&__this_module)
      |                     ~^~~~~~~~~~~~~~~
      |                      |
      |                      struct module *
/var/lib/dkms/linux-gpib/4.3.5/build/drivers/gpib/sys/osinit.c:210:35: note: in expansion of macro ‘THIS_MODULE’
  210 |         gpib_class = class_create(THIS_MODULE, "gpib_common");
      |                                   ^~~~~~~~~~~
In file included from ./include/linux/device.h:31:
./include/linux/device/class.h:230:54: note: expected ‘const char *’ but argument is of type ‘struct module *’
  230 | struct class * __must_check class_create(const char *name);
      |                                          ~~~~~~~~~~~~^~~~

Kernel 5.17: Remove use of slave_id in dma_slave_config

this patch should be applied to build on kernel 5.17.y.

There's no way for me to test whether it builds let alone works for ARM so unless someone can take up that part I'd rather keep it simple. You can always use --ignorearch with makepkg.

thanks a lot @grimler ! I gave it a try and it compiled ok.

Then dkms install, then depmod, ... no issues

I didnt test it on the run yet, but I guess the mantainer could add aarch64 to the architectures list!