Вероятно работающий CAD\CAM пакет https://www.gcad3d.org/ и снова поломка linuxcnc с обновлением чего-то питоновского

Nebulosa
pygtk есть и уже собранный в archlinuxcn
Под третий python есть, не спорю. Тут же второй Питон нужен
Какой третий? pygtk чисто под второй питон. Под третий используется python3-gobject
Nebulosa
Перед сборкой PKGBUILD 2.7.15-8 всего лишь запустил такую команду:
pikaur -S bwidget python2-pillow tkimg python2-gtkglext tclx python2-yapps2 boost-python2 boost-python2-libs
Все там собирается лишь один пакет обьявлен устаревшим да и то из за неправильной зависимости которая при этом не мешает сборке, возможно просто не смог поставить python2-yapps2 вместо python-yapps2 потому что он нужен linuxcnc 2.9 а pikaur такие ситуации не обрабатывает
pactree -lu pygtk |pikaur -Si -|grep -A1 -E "(AUR|Ошиб)"
Адрес AUR Git              : https://aur.archlinux.org/pygtk.git
Название                   : pygtk
--
Адрес AUR Git              : https://aur.archlinux.org/libglade.git
Название                   : libglade
--
Адрес AUR Git              : https://aur.archlinux.org/python2-cairo.git
Название                   : python2-cairo
--
Адрес AUR Git              : https://aur.archlinux.org/python2.git
Название                   : python2
--
Адрес AUR Git              : https://aur.archlinux.org/python2-gobject2.git
Название                   : python2-gobject2

pikaur -S bwidget python2-pillow tkimg python2-gtkglext tclx python2-yapps2 boost-python2 boost-python2-libs
[sudo] пароль для oleg:
Чтение баз данных пакетов из репозиториев...
Чтение локальной базы данных пакетов...
Разрешение зависимостей AUR...

:: Будут установлены пакеты из AUR:
 python2-yapps2                                             -> 2.2.0-1
 boost-python2                         1.83.0-1             -> 1.83.0-1
 boost-python2-libs                    1.83.0-1             -> 1.83.0-1
 bwidget                               1.9.16-2             -> 1.9.16-2
 python2-gtkglext                      1.1.0-8              -> 1.1.0-8 [устаревший: 2023/09/22]
 python2-pillow                        6.2.2-3              -> 6.2.2-3
 tclx                                  8.6.2-1              -> 8.6.2-1
 tkimg                                 1.4.16-1             -> 1.4.16-1

:: Приступить к установке? [Y/n]
:: [v] посмотреть описание пакетов   [m] выбрать пакеты вручную
>>
поиск конфликтующих пакетов из AUR...
:: python2-yapps2 и python-yapps2 конфликтуют. Удалить python-yapps2? [y/N] y
vs220
двоеточия : воспринимается TCL как часть пути по видимому с наследования виндовых путей типо C:/Tcl/lib

Это все прекрасно, однако при сборке PKGBUILD работает логика именно Bash и строка

echo "export TCLLIBPATH=${TCLLIBPATH:=/usr/lib/tcltk/linuxcnc}" > ${pkgname}.sh

работает так:

1. Если в системе уже задана переменная TCLLIBPATH то пишем её в файл linuxcnc.sh, получается :
export TCLLIBPATH=<уже заданный путь к библиотеке>
2. Если переменная TCLLIBPATH не задана (не существует или пустая) то тогда пишется в файл linuxcnc.sh:
export TCLLIBPATH=/usr/lib/tcltk/linuxcnc

Все пакеты, которые я выкладываю, проверяю, устанавливаю, и смотрю, что и куда ставится. Этот linuxcnc тоже запускал. В терминале при работе программы "выхлоп" был кристально чистый

Косвенно, что моя логика правильная можно увидеть вот в этом файле, его сделали видимо для того, чтобы обойти ошибку, но в PKGBUILD его даже не используют.

Вообще там очень странно код упаковки написан, такое ощущение, что мейнтейнер не совсем понимает, что там происходит, от этого все ошибки.
vs220
Все там собирается лишь один пакет обьявлен устаревшим да и то из за неправильной зависимости которая при этом не мешает сборке, возможно просто не смог поставить python2-yapps2 вместо python-yapps2 потому что он нужен linuxcnc 2.9 а pikaur такие ситуации не обрабатывает

Если бы была проблема с этим пакетом, я бы так и написал, но всё свелось к тому, что не был собран именно pygtk, о чём мне и сообщил pikaur. Мне с этой версией linuxcnc возиться лень, причины я написал раньше. Сегодня одно, завтра другое устареет.

P.S. Перед тем как собрать linuxcnc я удалил все пакеты которые были установлены для версии 2.9, пишу на всякий случай. Эту коллизию пакетов как у вас я и не увидел, т.к. данного пакета у меня и не было перед сборкой
Nebulosa
1. Если в системе уже задана переменная TCLLIBPATH то пишем её в файл linuxcnc.sh, получается :
export TCLLIBPATH=<уже заданный путь к библиотеке>
2. Если переменная TCLLIBPATH не задана (не существует или пустая) то тогда пишется в файл linuxcnc.sh:
export TCLLIBPATH=/usr/lib/tcltk/linuxcnc
а надо добавить путь к уже сушествующему если он есть пути (например TCLLIBPATH= /test /usr/lib/tcltk/linuxcnc )

Nebulosa
проверяю
проверте
export TCLLIBPATH=/test
export TCLLIBPATH=${TCLLIBPATH:=/usr/lib/tcltk/linuxcnc}
echo $TCLLIBPATH
vs220
проверте
export TCLLIBPATH=/test
export TCLLIBPATH=${TCLLIBPATH:=/usr/lib/tcltk/linuxcnc}
echo $TCLLIBPATH

$ export TCLLIBPATH=/test
export TCLLIBPATH=${TCLLIBPATH:=/usr/lib/tcltk/linuxcnc}
echo $TCLLIBPATH
/test

Эм.. всё сработало как и должно быть. Еще раз - переменная TCLLIBPATH задаётся один раз - она либо /test, либо /usr/lib/tcltk/linuxcnc. Когда вы, видимо, стараетесь записать /test:/usr/lib/tcltk/linuxcnc то она и будет восприниматься как целиком единый путь, которого в системе не существует.

Для того, чтобы разбирать пути вида /test:/usr/lib/tcltk/linuxcnc на составные - нужно писать ещё один обработчик, который будет разбивать строку на части, по символу ":".

Например, есть переменная PATH где записаны пути похожим образом, обработчик запусков, считывает строку целиком, потом разбивает её на массив путей и потом уже ищет нужный файл по порядку. Здесь же мы один раз указываем где конкретно лежит нужная библиотека, без переборок и лишних путей.

Как ещё это понятней объяснить, я не знаю :)
Nebulosa
всё сработало как и должно быть.
Должны добавляться пути через пробел
/test   /usr/lib/tcltk/linuxcnc
а не оставляться старый как в вашем случае
https://wiki.tcl-lang.org/page/TCLLIBPATH

export TCLLIBPATH=/test
echo $TCLLIBPATH
/test
export TCLLIBPATH="$TCLLIBPATH  /usr/lib/tcltk/linuxcnc
echo $TCLLIBPATH
/test  /usr/lib/tcltk/linuxcnc
vs220
https://wiki.tcl-lang.org/page/TCLLIBPATH

Прочитал вашу ссылку, там внизу есть занятный пример, который показывает, что в эту переменную они засовывают несколько путей (делают bash-массив путей), при этом, разделителем у них является пробел (что логично, так массивы в bash и работают). Причём, надо ещё и пробелы до и после элементов массива ставить, т.е. правильной строкой будет " /test /usr/lib/tcltk/linuxcnc " - именно с пробелами.

А теперь возвращаясь к началу - зачем городить массив из путей, если достаточно одного рабочего пути? Это нужно для каких-то очень специфичных случаев (ниже пишут про MingW), а для linuxcnc достаточно одного пути, с которым, повторюсь, всё и работает cразу правильно. Данный файл кладётся в папку /etc/profile.d/ и запускается программа со сразу нужной переменной окружения.
Nebulosa
а для linuxcnc достаточно одного пути, с которым, повторюсь, всё и работает cразу правильно. Данный файл кладётся в папку /etc/profile.d/ и запускается программа со сразу нужной переменной окружения.
Если в системе установлена другая программа на tcl со своим TCLLIBPATH то она не будет работать, корректно добавлять новый путь к уже существующему а не затирать старый новым
vs220
Если в системе установлена другая программа на tcl со своим TCLLIBPATH то она не будет работать, корректно добавлять новый путь к уже существующему а не затирать старый новым

Нет же.

Переменная существует только для конкретной сессии.

Например, открываем консоль:
$ echo $LANG; export LANG=C; echo $LANG
en_GB.UTF-8
C

Открываем вторую консоль рядом, там старое значение:
$ echo $LANG
en_GB.UTF-8

Ну или попробуйте задать TCLLIBPATH в одной консоли, а во второй консоли этой переменной не будет существовать.
$ export TCLLIBPATH=test; echo $TCLLIBPATH
test

$ echo $TCLLIBPATH

 
Зарегистрироваться или войдите чтобы оставить сообщение.