https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: x11-drivers/OpenTabletDriver-bin-0.5.3.1 fails to compile. Discovered on: amd64 (internal ref: guru_ci) NOTE: This machine uses GCC-11: https://gcc.gnu.org/gcc-11/porting_to.html
Created attachment 705366 [details] build.log build log and emerge --info
My machine, the one that ive been testing with also uses gcc11. it seems like the process is failing at "udevadm control --reload || die;". Is there some reason that udev would fail to reload, perhaps it's not installed? I may need to add a new USE flag if that's the case, or maybe you're using the commit before I added virtual/udev as a USE flag.
I don't see virtual/udev in the installed package list here. This was probably tested before that change was made. Likely fixed by: https://github.com/gentoo/guru/commit/0ba9361cde86eb4ea5040404f8f65d75da0efd23
(In reply to Theo Anderson from comment #3) > Likely fixed by: > https://github.com/gentoo/guru/commit/ > 0ba9361cde86eb4ea5040404f8f65d75da0efd23 Hi, I don't think so. Please note the commit SHA in the build log.
(In reply to Agostino Sarubbo from comment #4) > (In reply to Theo Anderson from comment #3) > > Likely fixed by: > > https://github.com/gentoo/guru/commit/ > > 0ba9361cde86eb4ea5040404f8f65d75da0efd23 > > Hi, I don't think so. > > > Please note the commit SHA in the build log. Are you able to run the command "udevadm control --reload" yourself in a terminal (both as user and root)? I would like to verify if this is an issue pertaining to the ebuild or your system to help debug further.
Well there's the problem, udevadm is a systemd tool. I doubt it's necessary to run that command
(In reply to Theo Anderson from comment #6) > Well there's the problem, udevadm is a systemd tool. I doubt it's necessary > to run that command You're probably right, I should say that the build was adapted from an AUR build for arch linux, so it was probably necessary there, however, I am also not using systemd, yet the command works for me so I was unaware that this was systemd specific. I guess I will most likely have to put a udev USE flag in my next commit that provides the command.
(In reply to ethannij from comment #5) > (In reply to Agostino Sarubbo from comment #4) > > (In reply to Theo Anderson from comment #3) > > > Likely fixed by: > > > https://github.com/gentoo/guru/commit/ > > > 0ba9361cde86eb4ea5040404f8f65d75da0efd23 > > > > Hi, I don't think so. > > > > > > Please note the commit SHA in the build log. > > Are you able to run the command "udevadm control --reload" yourself in a > terminal (both as user and root)? I would like to verify if this is an issue > pertaining to the ebuild or your system to help debug further. It looks like it is returning 2 here (from root): udevadm control --reload ; echo $? 2
from what i'm reading online, a 2 means that the file cannot be found. check if /lib/udev/rules.d or /etc/udev/rules.d exists for udev to refresh, otherwise it probably isnt installing to the udev directory properly.
Looks like I was wrong on that front, /usr/bin/udevadm seems to be systemd specific but /bin/udevadm isn't.
guru_tinderbox has reproduced this issue with version 0.5.3.3 - Updating summary.
With the next release of OTD (when it is available) I will try to add a systemd USE flag, so if that happened to be the problem that should resolve it. As of now I'm not entirely sure what the issue is or could be.
