Господа, чтобы не плодить темы спрошу здесь... Обнаружил на https://pkgs.org/download/lazarus, что у них для Магии 6.1 раздаётся Lazarus 1.2.4. А в Mageia Cauldron лежит вожделенный и наилюбимейший Lazarus 1.8.4. Есть ли шанс, что 1.8.4 переползёт в 6.1 или горшок - это для Mageia 7? smile

2 (2018-11-13 20:42:17 отредактировано saahriktu)

alex_q_2000 пишет:

Есть ли шанс, что 1.8.4 переползёт в 6.1 или горшок - это для Mageia 7? smile

Cauldron - это будущая Mageia 7. Однако, некоторые пакеты могут и бэкпортироваться. Другой вопрос, что у пакетов могут быть и дополнительные зависимости, и тогда придётся бэкпортировать значительную гроздь пакетов. А кому это нужно? Тут уже только на свой страх и риск, а не для стабильной ветки.

Например, lazarus 1.8.4 требует fpc 3-ей версии. А в Магейе 6.1 - fpc 2.6.4. Так что, придётся тащить ещё и fpc 3.0.4. Как это повлияет на зависимости каких-нибудь пакетов - надо внимательно смотреть.

Mageia 7 x86_64 / FVWM
Спасибо сказали: alex_q_20001

3

alex_q_2000⇓ пишет:

Есть ли шанс, что 1.8.4 переползёт в 6.1 или горшок - это для Mageia 7?

Я давно бекпортировал его для себя. Нужно было написать на скорую руку утилитку.
Есть в моем репозитории http://packages.gb2bel.ru/mageia6/RPMS/x86_64/ версия 1.8.4 и fpc 3.0.4

Чем больше я работаю админом, тем больше понимаю,
насколько волшебна фраза - "Нет технической возможности!"

==============================================
Mageia 6  MATE x86_64
Спасибо сказали: alex_q_20001

4 (2018-11-14 12:38:28 отредактировано alex_q_2000)

saahriktu⇓ пишет:

Cauldron - это будущая Mageia 7. Однако, некоторые пакеты могут и бэкпортироваться. Другой вопрос, что у пакетов могут быть и дополнительные зависимости, и тогда придётся бэкпортировать значительную гроздь пакетов.

Вот и мне интересно, как XliN умудрился fpc бэкпортировать, ведь он требует ld из binutils не ниже 2.26 (upd). Вернее, он его даже не требует явно, он давал ошибку на этапе сборки. Как понимаю, "бэкпортировать", - значит отправлять "взад". А как называется операция, если портировать "наверх"? Фронтпортирование? smile

XliN⇓ пишет:

Я давно бекпортировал его для себя. Нужно было написать на скорую руку утилитку.

Скачал, поставил. И ведь работает, зараза такая. )) А какие были нюансы? Я тоже хочу научиться бэкпортировать. Как Вы его урезонили с ld?

Пойду осуществлять "взадпортирование". Однако, что-то мне подсказывает (может я и не прав), что святой компилятор не желательно "скрещивать" с тем, под что он не затачивался. Попробовать стоит, однозначно. С другой стороны, "вживляя" в систему обновленный компоновщик (через прилепливание зеркал Cauldron), это автоматически отметает сборку пакетов из сишных исходников, поскольку такой пакет уже при установке на не обновлённом компе пользователя будет требовать этого обновления и не встанет. Вот такая чехарда, блин... drinks

5 (2018-11-14 19:40:49 отредактировано alex_q_2000)

XliN⇓ пишет:

Есть в моем репозитории http://packages.gb2bel.ru/mageia6/RPMS/x86_64/ версия 1.8.4 и fpc 3.0.4

Теперь я просто так не отстану ведь... big_smile
Делал вот так:

+ открыть спойлер

Бэкпортирование Lazarus-1.8.4 из Mageia Cauldron в Mageia 6.1
---
#ставим rpmbuild
urpmi --auto rpmbuild

#ставим для fpc
urpmi --auto mysql-devel postgresql-devel texlive-dist
#ставим для lazarus
urpmi --auto gdb gtk2-devel

#Скачиваем с https://pkgs.org и ставим пакеты *.rpm
urpmi --auto fpc fpc-src

#Скачиваем с https://pkgs.org и копируем в ./src пакеты fpc*src.rpm и lazarus*.src.rpm
cd ./src
rpmbuild --rebuild ./*.rpm

Через полтора часа это месево превращается в нужные пакеты, которые лежат в ~/rpmbuild/RPMS

Здесь вот свежий Lazarus-1.8.4 для Mageia-6.1 i586

А с x86_64 вот эта ошибка: /usr/bin/ld: /usr/lib64/fpc/3.0.4/units/x86_64-linux/rtl/cprt0.o: unrecognized relocation (0x2a) in section `.text' Почему i586 бэкпортировалось нормально - загадка. А у Вас как раз x86_64 рабочий. Куда мне рыть теперь? yikes

6 (2018-11-15 00:38:27 отредактировано saahriktu)

alex_q_2000 пишет:

Вот и мне интересно, как XliN умудрился fpc бэкпортировать, ведь он требует ld из binutils не ниже 2.26 (upd). Вернее, он его даже не требует явно, он давал ошибку на этапе сборки.

У меня тоже спокойно собралось старым ld. И без всяких дополнительных зависимостей.

Делал так:

  • Скачал fpc-3.0.4-6.mga7.src.rpm и lazarus-1.8.4-3.mga7.src.rpm

  • Начал собирать fpc. Засыпалось на ошибке, что нужен новый fpc.

  • Скачал уже собранный пакет fpc-3.0.4-6.mga7.x86_64.rpm также прямо из Cauldron'а и обновил из него fpc.

  • Новый fpc спокойно собрался уже как fpc-3.0.4-6.mga6.x86_64.rpm и fpc-src-3.0.4-6.mga6.x86_64.rpm (ещё собрались fpc-debuginfo-3.0.4-6.mga6.x86_64.rpm и fpc-doc-3.0.4-6.mga6.x86_64.rpm, но они не так важны). Поставил fpc из новых пакетов.

  • Собрал новым fpc новый lazarus и получил требуемый lazarus-1.8.4-3.mga6.x86_64.rpm. Обновил из него lazarus.

Вот и всё.

Всё что требовалось и весь результат: https://yadi.sk/d/kgpoNCmVTIrcMA

+ открыть спойлер

https://image.ibb.co/gCmUpf/screenshot1542230059.jpg

Замечание от админа: saahriktu, большие картинки всё таки убирайте под спойлер, это касается всех, уж больно много читабельного места они занимают.

Mageia 7 x86_64 / FVWM
Спасибо сказали: Zomby, alex_q_20002

7

saahriktu⇓ пишет:

У меня тоже спокойно собралось старым ld. И без всяких дополнительных зависимостей.

Урра! Сбылась моя мечта о новом Лазаре! Пошёл запихивать его быстрее в репу, пока не отобрали...

saahriktu, XliN - ещё раз спасибо! От великой ноши избавили; у меня ведь 4-ре виртуалки были задействованы 5.1+6.1 для разработок и сборки пакетов отдельно. И всё из-за отсутствия свежей версии Лазаря. Сейчас всё на двух 6.1 и я доволен как слон! Госпади, неужели конец мучениям... ))

p.s. А этот материал про бэкпортирование я сейчас срочно законспектирую... drinks

8

saahriktu пишет:

Вот и всё.

На магее 6.1 x86_64 в процессе установки нового lazarus, в /etc рядом со старым fpc.cfg создался файл fpc.cfgnew.
Потребовалось ручками прибить старый конфиг и переименовать новый в fpc.cfg, иначе при запуске Lazarus ругается,
что "не найдена system.ppu, проверьте fpc.cfg".

Mageia6, KDE, LXQt, x86_64.
Человек человеку - волк, а зомби зомби - зомби!

9

Zomby пишет:

На магее 6.1 x86_64 в процессе установки нового lazarus, в /etc рядом со старым fpc.cfg создался файл fpc.cfgnew.
Потребовалось ручками прибить старый конфиг и переименовать новый в fpc.cfg, иначе при запуске Lazarus ругается,
что "не найдена system.ppu, проверьте fpc.cfg".

Я когда жонглировал пакетами fpc по пути подчистил старые конфиги и поставил новый fpc в систему уже без прежних конфигов в /etc. Поэтому на эти грабли наступить у меня и не получилось.

Mageia 7 x86_64 / FVWM

10

На obs надо указать лишь url пакета, и бэкпорт делается автоматически.

С уважением, руководитель образовательного направления Mageia - EduMagic

11

Вышел Lazarus 2.0.0: https://yadi.sk/d/Tilhgh70ThslNQ .

Mageia 7 x86_64 / FVWM
Спасибо сказали: alex_q_20001

12

Вышел Lazarus 2.0.2. https://yadi.sk/d/UvaPdwTZeXCe9A , https://yadi.sk/d/riQFShizeLX1vQ .

Mageia 7 x86_64 / FVWM
Спасибо сказали: alex_q_20001

13

saahriktu⇓ пишет:

Вышел Lazarus 2.0.2.

Здравствуйте, saahriktu.
Поскольку Вы у нас главный по красноглазию, решил проконсультироваться... smile
Сижу я и уже третий час смотрю, как выполняется cmake --build . (kodi-18.2-Leia собираю для Mageia-6.1), который скачал с гитхаба. Вчера весь день компилил до посинения, всё зависимости подбирал. Несколько пакетов из Магии-7 пришлось бэкпортировать, заработало. Неужели все здоровенные программы собираются по полдня? Может быть есть какой-нибудь волшебный ключ для cmake (make), чтобы пятая точка не затекала от напряжения? Ну правда - ужас, как долго... drinks

14

Если у процессора больше чем одно ядро, то есть целый ряд вариантов.

Если cmake'ом генирируется обычный Makefile, то потом можно

Консоль: user
[user@localhost ~]$ make -jN

, куда вместо N подставить нужное количество потоков для параллельной сборки.

Можно сгенерировать файлы для такого сборочного инструмента как ninja, и тогда достаточно просто

Консоль: user
[user@localhost ~]$ ninja

Также можно пробовать выставлять переменную окружения CMAKE_BUILD_PARALLEL_LEVEL (её значение также задаёт число параллельных процессов).

Mageia 7 x86_64 / FVWM

15

saahriktu⇓ пишет:

Если у процессора больше чем одно ядро, то есть целый ряд вариантов.

Очешуенно! Огромное спасибо. Обязательно попробую... yikes

16

Здравствуйте, saahriktu. smile
Давно я к Вам не приставал и вот время пришло, уж не обессудьте. Интересуюсь вот чем...

При сборке/пересборке пакетов из *.src.rpm, еноты обычно преследуют цель "Ничего не делать". Поэтому каждый уважающий себя енот стремится всё вокруг себя автоматизировать и желательно на халяву. Например, если делать rpmbuild -ba ./*.spec, то для сборки пакета требуются пакеты из секций BuildRequires. Например, вот такая простыня:

+ открыть спойлер
BuildRequires:  autoconf
BuildRequires:  cmake
BuildRequires:  ninja
BuildRequires:  pkgconfig(expat)
BuildRequires:  ffmpeg-devel
BuildRequires:  pkgconfig(cwiid)
BuildRequires:  pkgconfig(libass)
BuildRequires:  pkgconfig(libcdio)
BuildRequires:  crossguid-devel
BuildRequires:  pkgconfig(libcurl)
BuildRequires:  flatbuffers-devel
BuildRequires:  cmake(fmt)
BuildRequires:  pkgconfig(freetype2)
BuildRequires:  pkgconfig(fribidi)
BuildRequires:  pkgconfig(dvdread)
BuildRequires:  pkgconfig(dvdnav)
BuildRequires:  pkgconfig(lzo2)
BuildRequires:  pkgconfig(openssl)
BuildRequires:  pcre2-devel
BuildRequires:  pkgconfig(libpcrecpp)
BuildRequires:  rapidjson
BuildRequires:  pkgconfig(sqlite3)
BuildRequires:  pkgconfig(taglib)
BuildRequires:  pkgconfig(tinyxml)
BuildRequires:  pkgconfig(alsa)
BuildRequires:  pkgconfig(avahi-core)
BuildRequires:  pkgconfig(bluez)
BuildRequires:  pkgconfig(libbluray)
BuildRequires:  pkgconfig(libcap)
BuildRequires:  pkgconfig(libcec)
BuildRequires:  pkgconfig(dbus-1)
BuildRequires:  pkgconfig(lcms2)
BuildRequires:  pkgconfig(liblircclient0)
BuildRequires:  pkgconfig(libmicrohttpd)
BuildRequires:  pkgconfig(libnfs)
BuildRequires:  pkgconfig(libpulse)
BuildRequires:  pkgconfig(python2)
BuildRequires:  pkgconfig(smbclient)
BuildRequires:  sndio-devel
BuildRequires:  pkgconfig(libudev)
BuildRequires:  pkgconfig(libxslt)
BuildRequires:  graphviz
BuildRequires:  doxygen
BuildRequires:  pkgconfig(egl)
BuildRequires:  pkgconfig(gl)
BuildRequires:  pkgconfig(glu)
BuildRequires:  pkgconfig(libdrm)
BuildRequires:  pkgconfig(mariadb)
BuildRequires:  pkgconfig(libplist)
BuildRequires:  pkgconfig(libupnp)
BuildRequires:  pkgconfig(xrandr)
BuildRequires:  pkgconfig(libjpeg)
BuildRequires:  pkgconfig(dvdnav)
BuildRequires:  pkgconfig(libpng)
BuildRequires:  pkgconfig(uuid)
BuildRequires:  pkgconfig(libxslt)
BuildRequires:  pkgconfig(x11)
BuildRequires:  pkgconfig(zlib)
BuildRequires:  giflib-devel
BuildRequires:  git-core
BuildRequires:  glibc-devel
BuildRequires:  java-openjdk-headless
BuildRequires:  shairplay-devel
BuildRequires:  swig
BuildRequires:  groovy
BuildRequires:  apache-commons-lang
BuildRequires:  yasm
BuildRequires:  pkgconfig(fstrcmp)

Сейчас эти БуилдРегуиресы приходится выковыривать лапами и ставить вручную. Может быть есть способ пересобрать пакет с автоматической доустановкой нужного добра? drinks

17

alex_q_2000 пишет:

Может быть есть способ пересобрать пакет с автоматической доустановкой нужного добра?

Есть, например, mock. Причём этот mock считается наиболее правильным способом сборки пакетов в отличие от просто rpmbuild. Потому, что, например, если просто запустить rpmbuild, то собранные бинарники могут слинковаться с дополнительными библиотеками, которые есть в системе, и которые не указаны в зависимостях пакета. И тогда установка пакета с этими бинарниками не притянет автоматически пакеты с этими библиотеками, и юзеру надо будет руками вычислять каким бинарникам каких библиотек не хватило, искать эти пакеты и устанавливать их руками.

mock же каждый раз разворачивает в chroot новую систему с указанными зависимостями, и собирает пакет именно в этой песочнице, где у бинарников нет возможности слинковаться с другими библиотеками. Заодно юзер получает возможность разворачивать в chroot самые разные rpm-based дистрибутивы и собирать под них пакеты. Так можно, например, сидя в Магейе собирать пакеты также, например, под Федору, openSUSE, CentOS, ALT, Росу,... и т.д. И, наоборот, сидя, например, в Федоре можно собирать пакеты под Магейю.

Сборочные сетевые сервисы наподобие build.opensuse.org и copr.fedorainfracloud.org используют именно mock, предоставляя юзерам возможность собирать свои пакеты под самые разные дистрибутивы.

Но есть и минусы. Например, появляется кэш mock'а, где он начинает хранить пакеты. Впрочем, можно настроить где именно он будет. При этом, да, каждый раз всё будет разворачиваться заново, а это дополнительный жор системных ресурсов.

Но тут уж кому что нужно и удобнее.

Mageia 7 x86_64 / FVWM

18 (2019-05-16 17:38:13 отредактировано alex_q_2000)

saahriktu⇓ пишет:

Но тут уж кому что нужно и удобнее.

Спасибо за развёрнутый ответ. Надо будет почитать про этот "mock". roll Хотя, специально чрутиться в голое окружение, где нет ни сети, ни локали, ни зеркал ни пятого ни десятого... бррр... всё лапами надо будет впердоливать, конфиги ковырять... Что-то уж очень сложно выглядит конструкция. Может парсер какой нарисовать, чтобы все Регуиресы + БуилдРегуиресы выудил из спека и поставил? Ну типа, скормил ему спек и пошёл курить. Я в замешательстве. big_smile

UPD: мегаскрипт...

Консоль

#!/bin/bash
#В каталоге со спеком...
echo "Install dependencies..."
urpmi --auto $(grep "^BuildRequires:" $(pwd)/*.spec | grep -v "%" | awk '{ print $2 }')

19

urpmi --auto $(grep "^BuildRequires:" $(pwd)/*.spec | grep -v "%" | awk '{ print $2 }')

На каких-нибудь

pkgconfig(libcdio)

оно будет ломаться. Это не имя пакета, тут ещё надо вычислять нужный пакет.

А так-то бы, конечно, всё было бы просто. Но нужно ещё придумать как обрабатывать такие ситуации.

Mageia 7 x86_64 / FVWM

20 (2019-05-16 20:45:34 отредактировано alex_q_2000)

saahriktu⇓ пишет:

На каких-нибудь
pkgconfig(libcdio)
оно будет ломаться. Это не имя пакета, тут ещё надо вычислять нужный пакет.

Такие ставлю руками: urpmi --auto "pkgconfig(libcdio)" в терминале. Главное - в кавычки запихать. А  если делать без кавычек, т.е. urpmi --auto pkgconfig(libcdio), но из скрипта, тоже прекрасно отрабатывает. В спеке же кавычек нет и работает. Скриптом уже воспользовался, кстати. Можно его расширить, если нужно и запихать в noarch.rpm, чтобы поиметь в системе ещё одну команду. Поставил пакетик, зашёл в каталог со спеком и например скомандовал: deps. Всё, urpmi полез в репу, притащил чего надо, а дальше по ситуации... Как Вам такой план? roll

А сейчас я уже третий час собираю Kodi-18.2 (Mageia-7-i586) на одном ядре. Кстати, пока Вы не пропали... Вопрос, возможно глупый... Нельзя ли как-нибудь смотреть общий персентаж исполнения rpmbuild? А то я потерялся во времени, сколько он тут месит уже эту бодягу... smile

Здесь скрипт и пример спека...

21

Нельзя ли как-нибудь смотреть общий персентаж исполнения rpmbuild?

Чего нет - того нет. Есть опции "-v" и "-vv" для подробной и наиболее подробной информации о процессе сборки соответственно.

Mageia 7 x86_64 / FVWM

22 (2019-05-18 08:10:02 отредактировано alex_q_2000)

saahriktu⇓ пишет:

Чего нет - того нет. Есть опции "-v" и "-vv" для подробной и наиболее подробной информации о процессе сборки соответственно.

Жаль. Ну ладно. smile Вот, выстругал на досуге скрипт для автоустановки Буилд-Регуиресов из спека и собираюсь его заплющить в deps-x.x-x.mga6.noarch.rpm. Может быть есть какие-нибудь дополнения/коррективы к нему? Вы всё-таки часто спеки правите. Или и так сойдёт?

+ открыть спойлер

Консоль

#!/bin/bash

#The script is intended for automatic installation
#of Mageia Linux package build dependencies from the *.spec-file
#Script URL: https://cloud.mail.ru/public/K4Zb/22x8rTi82
#MRC URL: https://forum.mageia.org.ru/viewtopic.p … 277#p30277

clear

#Если есть файл(ы) *.spec, берём имя последнего в списке (spec=)
if [[ -z $(find $(pwd) -maxdepth 1 -name '*.spec') ]]; then
  read -p "The *.spec-file not found in this directory. Press Enter to exit..."
  exit 1
     else
  spec=$(ls $(pwd)/*.spec | tail -n1);
fi;

#Выводим из спека имя пакета, с которым работаем
echo "Search build requires for \"$(grep "^Name:" $spec | awk '{ print $2 }')\"..."
echo "---"

#Забираем из спека все строки "BuildRequires:" и столбец-2 (deps=)
deps=$(grep "^BuildRequires:" $spec | grep -v "%" | awk '{ print $2 }')

#Если зависимости найдены, предлагаем их к установке
if [ -n "$deps" ]; then
  echo -e "Dependences list:\n"; echo "$deps"; echo "---";
  read -p "Press Enter to install or Ctrl+C for cancel operation..."; echo;
  urpmi --auto $deps
     else
  read -p "The build requires not found in $spec. Press Enter to exit..."
  exit 0
fi;

echo "---"; read -p "The procedure is completed. Press Enter to exit..."

upd 17.05.19: deps=$(grep "^BuildRequires:" $spec | grep -v "%" | awk '{ print $2 }') - Только столбец 2. Другие могут содержать сравнения версий. - Алиасы (%).
upd 18.05.19: if [[ -z $(find $(pwd) -maxdepth 1 -name '*.spec') ]]; + -maxdepth 1

23

alex_q_2000 пишет:

Может быть есть какие-нибудь дополнения/коррективы к нему?

Наверное, нет.

Mageia 7 x86_64 / FVWM

24

saahriktu⇓ пишет:

Наверное, нет.

Ну тогда вот, ещё один мега-инструмент для сборки RPM - пакет deps: https://cloud.mail.ru/public/K4Zb/22x8rTi82

Ставим пакет, заходим в каталог со спеком и даём команду deps. Устанавливаем предложенные зависимости (провИдесы) и собираем пакет как обычно: rpmbuild -ba ./*.spec. Проверил его в Mageia-6 и 7 + подсобрал несколько рпм. Вроде всё месит. Добавил в "Плюшевый", пусть будет... drinks

25

Здравствуйте, saahriktu!
Я опять с глупыми вопросами. Сразу отмечу, что мне можно их задавать, поскольку я виндузятник. yikes
Нашёл в сети некий porg. Если ему скормить "make install" в каталоге с исходником в виде:

porg -lp имя_программы_в_базе_porg "make install"

...то после установки программы в систему он может отдать список установленных файлов:

porg -f имя_программы_в_базе_porg

У него есть даже гуй-менеджер установленного добра - grop. Показывает список пропущенных через него "make install-ов".

Однако, всё это выглядит как-то уж очень уныло в плане ковыряния пальцами, да и пакета такого нет в Магии, пришлось и его из исходников лепить. Может быть есть более цивилизованный способ выудить список файлов программы после make install? Заранее благодарен...