Arch Linux User Repository

Hi all

During "checking..." procedure this pops up

checking for libgpiod < 2.0.0... no
configure: WARNING: Could not find libgpiod, not building hal_gpio

So i tested with downgrading to 1.6.4 leading to the conflict before checking is started

looking for conflicting packages...
:: libgpiod-2.1.2-2 and libgpiod-1.6.4-1.6.4-1 are in conflict. Remove libgpiod-1.6.4? [y/N] y

Packages (2) libgpiod-1.6.4-1.6.4-1 [removal]  libgpiod-2.1.2-2

Denying the upgrade to libgpiod-2 will abort the installation. I can live with the hint that there is no libgpiod < 2, but does it have any further downsides?

As InnerBushman already stated the python version check also hit me. I am on 3.13 and checking starts from version 3.12 downwards leading to a final python3 usage. For me it seems like that is the reason for the binaries won't start after successful installation. 3.13 is used by the system, python3 by linuxcnc -> "No module named XY"

I don't understand why or where the check is starting with 3.12, nor how to get it started with 3.13. Getting 3.12 from the AUR leads to an abort on check for "python pango"

checking for python pango module... Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'gi'
no
configure: error: Python pango module not found!

Did anyone successfully install the recent linuxcnc version with python 3.13 already installed?

greez2all Tweety

Compiling realtime hal/components/counter.c
emc/rs274ngc/gcodemodule.cc: In function ‘PyObject* parse_file(PyObject*, PyObject*)’:
emc/rs274ngc/gcodemodule.cc:746:5: error: ‘gettimeofday’ was not declared in this scope
  746 |     gettimeofday(&t0, NULL);
      |     ^~~~~~~~~~~~
Compiling realtime hal/components/encoder_ratio.c
make: *** [Makefile:289: objects/emc/rs274ngc/gcodemodule.o] Error 1
make: *** Waiting for unfinished jobs....
==> ERROR: A failure occurred in build().
    Aborting...

@InnerBushman I've worked on an improved version of the script that sets the environment variable. I could get it spot on but I didn't yet submitted it to @FabioLolix 's repository. Will do in the next two days. If I do not do it until then please post another comment here so I will be reminded.

@FabioLolix I'm sorry if I pissed you off. It was not my intention. I truly appreciate your contributions. I just hope you can understand where I come from as a user. It's often very frustrating to find out the package you manually fixed several times in the past broke again after system update, or that it doesn't compile "as is". As I previously mentioned the prepare() only checked for Python 3.11 and lower while my python was 3.12. It could be that if it detected my highest python version correctly, maybe the compilation would be successful without the need to remove the older versions. I hope we can put this behind us.

@GPereira can we also check if the exported path is empty? Since I don't have anything else in there it leaves a ':' at the end and stops linuxcnc from launching correctly.

[[ :$TCLLIBPATH: != *:/usr/lib/tcltk/linuxcnc:* ]] && export TCLLIBPATH=/usr/lib/tcltk/linuxcnc:$TCLLIBPATH

echo $TCLLIBPATH
/usr/lib/tcltk/linuxcnc:

Then if I run linuxcnc:

LINUXCNC - 2.9.3
Machine configuration directory is '/home/bushman/linuxcnc/configs/my-mill'
Machine configuration file is 'my-mill.ini'
can't find package Linuxcnc
    while executing
"package require Linuxcnc "
    (file "/usr/share/linuxcnc/hallib/check_config.tcl" line 187)

If I export the path without the ':' everything works fine.

Thanks Gonçalo!

 Time spent on debugging installation process could be spent on CNC-ing stuff! :)

@InnerBushman If there is a thing that piss me off is complaining about the stuff I do for free in my free time using ! (even if there is a smiley)

If you don't want to spent time on the installation process use their distributions: https://linuxcnc.org/downloads/

@Tweety using AUR packages means you accept to eventualy deal with build issues here and there. Specially in applications written in C like this one which require much more effort to develop a trouble free Makefile.

If you stick with Arch Linux repositories you get the experience you are expecting since packages are built by Arch Linux servers in clean environments. In that case, issues, like the one you dealt with python, do not occur because the package is built in a freshly configured machine with no additional packages installed and at the end the machine is deleted.

Having that said, and, as you know, there's always packages beyond Arch Linux repositories that we need hence the need for AUR. FabioLolix has shown commitment and is doing a really great job with this package. It is virtually impossible to ensure a successfull build in a package like this one that depends in so many third party components like Python, OpenCV and others. That's why this comment section exists and people are usually very helpful and don't expect anything in return.

Give some praise to FabioLolix, he maintains this package for us for free!

Hi Fabio,

your impression seem to be wrong but I don't want to start a bigger discussion on that.

Python2-yapps2 was already off my system since 2023. I only had python-yapps2 (not python2-*) since then.

For people who run into the same build errors as I did, may find help, if they simply uninstall all python2- packages and reinstall python-yapps2. Followed by a clean install of python2- in case they are still needed.

greez2all

Tweety

The build environment will be as clean as the package manager will make it.

Then it is dirty

I'm not a developer and expect a package defining files to instruct the package manager on how to cleanly build the software.

pkgbuild will never instruct the package manager (btw the build is done by an AUR helper) to do a clean build; don't even makepkg do

Neither I am a developer and sometimes packaging is hard

The build environment will be as clean as the package manager will make it. I don't have immediate control over what pamac does when I click "build" in the GUI. I'm not a developer and expect a package defining files to instruct the package manager on how to cleanly build the software. Time spent on debugging installation process could be spent on CNC-ing stuff! :)

Just wanted to mention that all my problems with building and missing gi module stemmed from improperly detected highest version of python. After I removed python 2.x and 3.9, the installation (build) finished without issues.

Learning to build in clean chroot solved that

https://aur.archlinux.org/packages/linuxcnc#comment-986138

https://aur.archlinux.org/packages/linuxcnc#comment-985912