Будни #bootstrap

У меня по этой задаче (upver libc++) наступило замечательное состояние "да я ебал".

В конце-концов, это не моя война. Хотят люди из LLVM чистить код - пускай сами имеют дело со сломанными проектами.

А я взял, и:

* https://github.com/pg83/ix/blob/main/pkgs/lib/c%2B%2B/19/patched/0.diff - вернул удаленную специализацию char_traits. Коллеги из clang решили, что создавать std::basic_string из любого типа - это плохо, а на эту возможность заложился много кто.

* Откатил https://github.com/llvm/llvm-project/commit/f9dd885cb6e6b70deff935689bb0dfb7d5b6a1a4 Самое интересное, что в транке у них это уже откачено, а в стабильной ветке - нет. https://github.com/llvm/llvm-project/commit/4f79ef4efff432a93005b156726587c8c5a5ac17

После этого все прошло более-менее нормально.

#tcmalloc пижже - https://t.iss.one/itpgchannel/369

(fun fact - так же является аллокатором по умолчанию в двух больших поисковых компаниях!)

Но в выборе между jemalloc и mimalloc, конечно, побеждает mimalloc.

Меня тут спрашивают, почему давно нет историй про #bootstrap (а мемасиков, наоборот, с лихвой).

Все потому, что, последние две недели, вечерами и выходными, я собирал Chromium.

Предыдущая попытка была ажно вот тут - https://t.iss.one/itpgchannel/534, и, насколько я сейчас понимаю, она была обречена на поражение, хорошо, что я тогда это гиблое дело бросил.

Моему пакетнику нужно было набраться мощи, как выразительной, так и наполнением утилит и библиотек, чтобы это стало реалистичным.

TL;DR - я сделал!

На этот раз я подошел к делу очень системно:

* Системно нашел последний snapshot Chromium в Alpine, в котором еще не было Rust - https://gitlab.alpinelinux.org/alpine/aports/-/commit/2b73ae849e016647a7b5c0d79d92b0b0574aac1a

* Системно попиздил все патчи из Alpine (потому что musl) - https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/community/chromium

* Cистемно воссоздал все нужное окружение (потому что clang-17 оно собирается, а вот clang-19 - нет) - https://github.com/pg83/ix/blob/main/pkgs/bin/chromium/ix.sh#L4

* Системно продрался через ошибки сборки, потом через ошибки линковки, а потом и через падения на старте.

Падения были вокруг NSS модуля, и я думал, что я поседею, пока это дебажил:

* Найти место, где случилась ошибка, было сложно, потому что она несколько раз преобразовывалась из одного пространства error codes в другое, и грепать это было решительно невозможно.

* А потом нужно было понять, почему же падает инициализация генератора случайных чисел в NSS...

Падало оно вот в этом блоке кода - https://github.com/nss-dev/nss/blob/master/lib/freebl/drbg.c#L237-L241

Я, признаться, долго не мог понять, почему оно в этом месте падало, грешил сначала на какой-нибудь многопоточный race, но потом обнаружил, что, если запустить это вне дерева Chromium, в отдельном небольшом примере, то все работает, как надо.

Long story short - в NSS есть https://github.com/nss-dev/nss/blob/master/lib/freebl/drbg.c#L234 (SHA256_Update), а еще SHA256_Update есть в boringssl, которая лежит в исходниках Chromium. И, так уж получилось, версия из boringssl победила, поэтому, конечно, там получалась какая-то дичь, а не хеш.

В общем, в воскресенье оно кое-как заработало, без 3D ускорения, и без живого root CA, но заработало, и это прямо вау!

https://github.com/thepowersgang/mrustc #mrustc

Чувак, конечно, монстр.

Сейчас он умеет в #bootstrap 1.74, и это снова очень близкО к trunk.

Респект, уважуха, мы таких безумцев очень любим.

Будни #bootstrap

Запилил более лучшую изоляцию сборочных нод, чем было раньше.

Запилил, потому что пионеры из rust никак не могут понять, что не нужно лазить в систему, когда не просят.

Проявлялось это так - когда я запускал rust, собранный динамически с musl, на glibc-based системе, он лез в эту систему, ему от этого сносило крышу, и он начинал сыпать нерелевантными ошибками.

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

Когда я пилил эту изоляцию, то выяснилось прекрасное - cargo не может работать без /dev/random, потому что он там где-то инициализирует libgit2, а тот требует наличие /dev/random. Тут, конечно, пионеры и те, и эти, потому что зачем карге инициализировать libgit2, когда у меня под ногами не git, ну а требование libgit2 - это вообще клиника.

Герметичная сборка my ass, ага.

Сделал я это пока совсем по рабоче-крестьянски, не в graph executor (что было бы правильнее), а прямо на уровне основного сборочного шаблона - https://github.com/pg83/ix/blob/main/pkgs/die/sh0.sh#L29-L33, по флажку.

Флажок я выставил на весь свой CI, и, конечно, у меня волосы зашевелились примерно везде, когда стало понятно, насколько часто всякие левые сборки лезут в /bin и прочее. Чинил CI, наверное, с неделю.

Саму изоляцию тоже соорудил из подручных средств, потому что так получилось проще в моменте, из unshare + chroot:

https://github.com/pg83/ix/blob/main/pkgs/bld/jail/scripts/jail.sh
https://github.com/pg83/ix/blob/main/pkgs/bld/jail/scripts/jail0.sh

Проще, потому что другие средства требуют от системы больше, чем user namespaces, а мне лень было с этим разбираться.

Будни #bootstrap

В общем, я сумел, по модулю #gir для gdk-pixbuf.

Я хз, как у них там все сделано в их CI, но у меня не получилось воспроизвести их техпроцесс так, чтобы он давал такой же результат, как у них.

После того, как я продрался через все хитросплетения их говноскриптов, в сухом остатке у меня случился вот такой вот diff, между их результатом, и моим:

- <type name="pid_t" c:type="pid_t"/>
+ <type name="gint" c:type="pid_t"/>

В их техпроцессе где-то есть нормализация pid_t (про который их код ничего не знает), до gint, про который их код что-то знает.

Дальше эта разница "пробулькивалась" по куче сгенеренных файлов, и приводила к их частичной неработоспосбности (просто часть сгенеренных методов становилась недоступной).

Их магию про это я не нашел, но долил немного своей - https://github.com/pg83/ix/blob/main/pkgs/bld/gir/fix/scripts/fix.sh.

Угу, прошелся регулярочкой поверх, и дальше это все как-то заработало.

Будни #bootstrap

Случился новый релиз svt-av1, принес красивое:

https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/cmake/cpuinfo.cmake?ref_type=heads#L67-68

Что у нас тут написано?

* Заюзали новую либу, от pytorch, вроде, ничего страшного - https://github.com/pytorch/cpuinfo

* Завендорили, причем самым всратым в cmake способом, через FETCH_CONTENT (никогда, никогда так не делайте)

* Самая мякотка - завендорили какой-то васянский форк, https://github.com/1480c1/cpuinfo, наверное, вирус какой-то.

* Прикопали хеш от zip файла - https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/cmake/cpuinfo.cmake?ref_type=heads#L76 Никогда, никогда этого не делайте, ВСЕ известные мне хранилища исходников генерят их нестабильно. Через пару итераций очистки кеша в его gitlab этот хеш протухнет:

https://t.iss.one/itpgchannel/916
https://t.iss.one/itpgchannel/424
https://t.iss.one/itpgchannel/937

Все это, конечно, вызывает некоторую фрустрацию.

Будни #bootstrap

В саппортный чат #stal/ix (не ищите, там нет ничего интересного) пришел интересный коллега, и рассказал, что он случайно пришел к такому же дизайну пакетного менеджера, и OS на его основе:

https://ccx.te2000.cz/stagit/pthbs/file/README.html (диздок 1-в-1 как у IX)

Понятное дело, что тут очень много схожего с прародителями, типа Nix/Guix, но вот есть важная деталь, которая обеспечивает новизну этого дизайна:

"Jinja-based templating system for generating package definitions for pthbs"

https://ccx.te2000.cz/stagit/mrrl/file/templates/pkg/bison.html - вот, например, его пакет с bison.

Много общего с тем, как устроено у меня.

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

Будни #bootstrap

Таки нашел в себе силы разметить пакеты данными, нужными для https://repology.org/docs/requirements

https://github.com/pg83/store/blob/main/dump.json

Размечено, по грубым прикидкам, до 3/4 моей пакетной базы, остальное придется допиливать вручную.

Ждем валидации данных, надеемся, держим за меня кулачки.

Будни #bootstrap

Одной из причин, по которой я решил встать в repology, стало то, что мой дистрибутив стал слишком большим.

Не вообще большим, а большим для одного основного мейнтейнера.

Обновлять полторы тыщи пакетов - это от получаса в день и выше, а позволить себе тратить столько времени на это я не могу.

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

Та-да-да-да!

https://github.com/stal-ix/ix/pull/679

Первый мерж в stable, где бОльшая часть upver, порядка 150 пакетов, была сделана с помощью моей новой автоматизированной системы по обновлению.

Она майнит пакеты, проверяет, что новая версия собирается (пока без пересборки всей репы, на это у меня пока не хватает инфры, но и так уже очень хорошо), и пушит в мой dev!

Я бы сказал, что это открывает дорогу к 10000 пакетов и дальше (на одного мейнтейнера), но, к сожалению, в процессе все еще есть вещи, которые плохо масштабируются, типа обновления clang.

Будни #bootstrap

https://www.phoronix.com/news/Meson-1.8-Released

Вышел новый #meson, вышел и вышел.

Давно хотелось написать, что #meson - это oss система сборки, от который у меня постоянный butthurt.

Ее автор - классический пример "есть только два мнения по любому предмету - мое, и неправильное".

С каждым новым релизом meson он постоянно ломает какие-то мои use case.

Например, раньше у него был fallback при поиске кодогенераторов - если не получалось найти через pkg-config, то он просто искал в PATH.

Мне это было очень удобно, потому что, когда мне нужно собрать программу с glib, то там есть две части - неопсредственно libglib.a, и, скажем, какой-нить кодоген, типа glib-mkenums (не суть, что это такое).

И эти две части должны быть собраны под разные платформы, в случае кросс-компиляции.

И получается так, что в одном glib.pc должно быть описание как таргетной части (пути к libglib.a), так и хостовой части, а так собрать этот пакет невозможно в принципе.

Ну вот я просто раньше убирал пути до этих программ из glib.pc, и пользовался fallback, про который написал выше.

Однажды это сломалось.

Чтобы оно "как-то" заработало, пришлось в glib.pc нагенерить записей вида:

...
glib-mkenums=glib-mkenums
...

Тем самым, meson получает нужную ему запись, и дальше просто зовет ее, находя в PATH.

Я в курсе, что в meson можно иметь разный PKG_CONFIG_PATH для host и target графов, но это не очень хорошо мне модельно подходит, ну и так никто, кроме meson, не делает.

Будни #bootstrap

Одна голова хорошо, а больше - лучше!

Мне тут коллеги, которые пытаются пользоваться IX, справедливо указали, что мне надо собирать все с "-Wl,-icf=safe -Wl,--gc-sections -faddrsig -ffunction-sections -fdata-sections", потому что это сильно уменьшает размер получающихся бинарей.

Случайная выборка из 100 бинарей показала такой результат - было 115M, стало 91M. Особенно это эффектно выглядит на примере clang, полный комплект был 2.1G, стал 700M, экономия в три раза!

Хорошо владеть своим дистрибутивом Linux, от идеи до коммита в stable прошла всего неделя (благодаря тому, что у меня враппер над clang, и не нужно мудохаться с тем, чтобы править сборку каждого пакета на предмет нужных флагов), https://github.com/stal-ix/ix/pull/693.

Я вот думаю, что бы было, если бы такое принести в Fedora, или там в Arch?..

Будни #bootstrap

Внезапно пришло в голову, что, если у меня есть CI, который строит все пакеты, то я могу построить отображение binary -> package name (https://github.com/pg83/ix/blob/main/pkgs/die/scripts/bins.json), и сделать более удобный ix run:

pg:home# ./ix run zstd --help
*** Zstandard CLI (64-bit) v1.5.7, by Yann Collet ***

Compress or decompress the INPUT file(s); reads from STDIN if INPUT is `-` or not provided.

Usage: zstd [OPTIONS...] [INPUT... | -] [-o OUTPUT]
...

Пока там прилично мусора, но уже выглядит полезным.

Будни #bootstrap #rootfs

https://huggingface.co/datasets/stal-ix/rootfs/tree/main

Под давлением общественности, начал готовить регулярные снепшоты rootfs для #stal/ix - можно скачать, войти в них, с помощью вашей любимой контейнерной изоляции (minijail/bwrap/pivit_root/chroot (только не забудьте про сеть, маунты /dev, /proc, /sys)), и можно попробовать позапускать команды из настоящего, живого, #stal/ix.

Будни #bootstrap

За прошедшее время я завел себе полный кеш исходников на huggingface (счастья и здоровья этим проклятым капиталистам, пока они дают околобесплатный хостинг для произвольного объема данных) - https://huggingface.co/datasets/stal-ix/pkgsrc/tree/main, и на ghcr.io (это место, где github хранит контейнерные слои, там unlimited, в отличие от github lfs) - https://github.com/orgs/stal-ix/packages. Этим проклятым капиталистам тоже счастья и здоровья, ага.

Я, кстати, такой не один, на ghcr.io "хостится" homebrew.

В общем, кажется, в таком setup проекту (пока) больше не нужны зеркала, поддерживаемые нашими бравыми пользователями, потому что эти два зеркала предсказуемее, и позволяют получить гарантированный результат.

Поэтому я взял, и удалил пользовательские зеркала из конфига - https://github.com/pg83/ix/commit/869f6bf18ebf1709ea3ee2ac3eacf90037596725

А пост я пишу, чтобы еще раз сказать спасибо всем тем, кто поддерживал зеркала проекта в сложное время! Вам, конечно, тоже счастья и здоровья!

#mirror, the end.

Будни #bootstrap

Случилось страшное, два одинаковых питона, собранных на двух разных хостах моей #homelab #lab:

lab1 # python3
Python 3.12.7 (main, Jun  9 2025, 09:12:41) [Clang 20.1.5 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> import uuid
>>> ^D

lab2 # python3
Python 3.12.7 (main, Jun 10 2025, 11:25:34) [Clang 20.1.5 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> import uuid
Traceback (most recent call last):
  File "<console>", line 1, in <module>
ModuleNotFoundError: No module named 'uuid'
>>>

Я, конечно, предположил где такое может происходить (python frozen.py во втором случае не сумел понять, что используется модуль uuid, и не добавил его в заморозку), но выглядит максимально всрато.

Такие configure скрипты нам не нужны!

Будни #bootstrap, #ix

pg:home# ./ix build bin/b64 --target=freebsd-x86_64
...
pg:home# readelf -a .../bin/base64 | grep OS/ABI
  OS/ABI: UNIX - FreeBSD

Будни #bootstrap

Собрал под freebsd какое-то значимое количество пакетов, в том числе, графических приложений.

Был приятно удивлен:

* Под freebsd есть свой libudev, с linux compatible интерфейсами
* Под freebsd компилируются, и, наверное, работают, основные библиотеки для ввода - libinput, libevdev, libmtdev, и так далее. Мне, например, казалось, что они linux only. То есть, freebsd тут пошли по пути наименьшего сопротивления, поддерживая такой же ABI в /dev/, как и в Linux.
* Соответственно, собираются libdrm, libwayland и mesa, практически "из коробки". В целом, неудивительно.

Был просто шокирован тем, что почти все эти библиотеки имеют в себе include <linux/input.h>, то есть, изначально они были linux-only, а в freebsd есть пакет, который предоставляет этот заголовок, реализованный в соответствующих терминах freebsd.

Лично мне нравится прагматичность подхода, и отсутствие борьбы с ветряными мельницами. Есть готовый код, и давайте подстроим OS ABI так, чтобы этот код просто работал.

При сборке curl под freebsd стала падать библиотека libgpg-error, причем с ошибкой, которая мне показалась знакомой.

Долго вспоминал, и вспомнил - https://t.iss.one/itpgchannel/1665. Вот тут я чинил кросс-компиляцию этой либы, правда, не для freebsd.

Полез читать, почему не помог прошлый фикс.

Нашел прекрасное - https://github.com/gpg/libgpg-error/blob/master/configure.ac#L634

Что тут написано?

Что, если мы кросскомпилируем, то, если кросс-компилируем под Linux, то сделать магию из https://t.iss.one/itpgchannel/1665, а иначе сказать "ну не шмогла я". Офигенные, блин, тесты.

Починил я это весьма изящно - https://github.com/pg83/ix/blob/main/pkgs/lib/gpg/error/ix.sh#L36. Типа, сказал, что под freebsd надо сделать точно так же, как под Linux.

https://www.phoronix.com/news/Rust-Debian-2025

"around 8% of the source packages in Debian Sid are building against at least one librust-* package. That 8% figure for Debian source packages building against at least one Rust library package is around double of what it is for Debian 12 "Bookworm". Quite a significant uptake over the past few years and it's only continuing to grow with more open-source projects introducing varying levels of Rust integration"

Понятное дело, что это librsvg, или какие-нить кодеки, которые не являются обязательными, но против них нужно собраться, чтобы получить "полный" пакет, но, тем не менее, цифра довольно внушительная.

У меня против Rust собирается ровно 0 от базовой системы, потому что librsvg для загрузки иконок в gtk я переписал на кастомный #svg loader over #lunasvg/#skia/#svgren (по выбору), и убрал все эти опциональные зависимости.

Ну просто потому, что Rust не является #bootstrap абельным (я не могу собрать его из исходников, не имея под рукой готовый компилятор Rust, подробности в моей эпопее с #mrustc), а это зашквар.