Arch Linux User Repository

@mdf done

Can you add xlnx_pcie_xvc to features? It enables a new driver I recently submitted.

Please change source to git+https from git+http.

/lib/udev/rules.d/60-openocd.rules GROUP="plugdev", TAG+="uaccess"

In contrast, for instance, "/usr/lib/udev/rules.d/69-libftdi.rules" does not use GROUP="plugdev", but only TAG+="uaccess".

André, please address this issue.

https://bugs.archlinux.org/task/35602 and https://bugzilla.redhat.com/show_bug.cgi?id=815093

" Sure, we must entirely get rid of that crap. "plugdev" is a very misguided and fundamentally wrong Ubuntuism."

But, then, Arch is not Fedora. In particular, from the Arch bug, "Note its caveat, it [uaccess] does not work over SSH." I'm very fond of using ssh over wifi when I want a portable keyboard and screen. Still, using ssh is no limitation at all if I am also already logged-in to the machine into which a device is "plugged", as far as I can tell.

Admittedly, this systemd/Fedora recommended "best practice" is either a very old - circa 2012 - or a relatively recent - circa 2018 - change to systemd policy, depending upon a person's opinion about the quality of systemd documentation:

https://github.com/OpenCBM/OpenCBM/pull/8 Use of TAG+="uaccess" instead of GROUP and MODE

https://enotty.pipebreaker.pl/2012/05/23/linux-automatic-user-acl-management/ Linux automatic user ACL management

To resolve this, either: getent group plugdev >/dev/null || groupadd -r plugdev

or, preferably: sed -i 's/, GROUP="plugdev"//' "$pkgdir/usr/share/$_pkgbase/contrib/60-openocd.rules"

or:

https://github.com/systemd/systemd/issues/4288 Document the uaccess mechanism / dynamic device permissions

"We should also give some hints for people writing udev rules (e.g. for package maintainers or upstream developers). E.g. if it is ok to use TAG+="uaccess" directly or it's better to use ID_* variables and letting 70-uaccess.rules do the tagging."

Which is to say, after reading through /usr/lib/udev/rules.d/70-uaccess.rules, and then choosing some general class of device from there, which could apply to, say, "JTAG adapters and flash memory programmers", then, instead of applying TAG+="uaccess" directly, apply some new ENV{ID_PLUGDEV}="1" rule, and then plead with systemd "upstream" to modify 70-uaccess.rules to include a custom ENV{ID_PLUGDEV}=="?*", TAG+="uaccess" rule.

Of course, this last alternative seems completely unnecessary and undesirable, but it is another option.

Thanks for reporting Tom. I've added aarch64 to the arch list as suggested.

Builds fine for rpi3 by adding aarch64 to the arch list. Thanks, Tom

[tom@rpi3 openocd-git]$ git diff  
diff --git a/PKGBUILD b/PKGBUILD
index c82ddda..a64d90a 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -9,10 +9,10 @@

 _pkgbase=openocd
 pkgname=openocd-git
-pkgver=0.10.0.r523.g2a3b709aa
+pkgver=0.10.0.r581.g1b864d6e4
 pkgrel=1
 pkgdesc="Debugging, in-system programming and boundary-scan testing for embedded target devices (git version)"
-arch=('i686' 'x86_64' 'arm')
+arch=('i686' 'x86_64' 'arm' 'aarch64')
 url="http://openocd.org"
 license=('GPL')
 depends=('libftdi' 'libftdi-compat' 'libusb' 'libusb-compat' 'hidapi' )
[tom@rpi3 openocd-git]$ 

I'd like to second AndrevS's request to change the mirror used. Sourceforge fetch speed is incredibly poor.

When building using aursync I get a build error telling me that sime temporary file logpipe.XXXX could not be removed. When building manually using makepkg this works out-of-the-box. Has anyone similar effects?

SourceForge's git is so slow it takes hours and then fails to complete. Using the mirror (git://repo.or.cz/openocd.git) instead gets the source in no time.

According to this bulletin: http://openocd.org/2012/11/sourceforge-upgrade/

The git url has changed (in 2012, no less, but it seems to have kept going until recently), so that now _gitroot should be:

_gitroot=git://git.code.sf.net/p/openocd/code

Until I changed that line, it wouldn't build.