https://lwn.net/Articles/889025/#Comments
https://www.opennet.ru/opennews/art.shtml?num=56902

Вышел новый #gnome GNOME. Много недовольных.

Кто-то недоволен тем, что убрали градиенты на кнопках(я из них) - https://blog.brixit.nl/the-end-of-the-nice-gtk-button/ . Лично мне кажется, что политика "все кликабельное имеет градиент" - это очень классно, и упрощает работу с GUI.

Кто-то - процессами разработки. https://informatique-libre.be/swilmet/articles/gnome-gedit-dev-feedback.pdf

Я, как обычно, недоволен пиздежом.

"В число приложений, рекомендуемых для включения по умолчанию в установки GNOME, добавлено два новых приложения - текстовый редактор Text Editor и эмулятор терминала Console. Данные приложения используют GTK 4"

UPD: то, что console использует gtk4 - ошибка перевода новости с https://release.gnome.org/42/

Полез собрать эти чудеса, потому что в живую не видел приложений на gtk4 + libadwaita.

gnome-text-editor собирается из тега, который не прошел CI тесты. https://gitlab.gnome.org/GNOME/gnome-text-editor/-/tags

gnome-console, судя по скриншоту, собрался вообще с gtk3. Я таки попробовал собрать его с gtk4, но:

* #libvte, которая нужна для console, собирается с gtk4 только в транке, тега и релиза про это еще не было вовсе

* сам код console не рассчитан на gtk4

Ну и, куда же без этого, наткнулся на очередной errogance от разрабов GNOME: https://gitlab.gnome.org/GNOME/vte/-/issues/72

Чуваки, как обычно, форсят свою повестку - "API Linux определяет glibc"(по ссылке офигенный комментарий от автора musl, Ричарда Фелкера, про это), "мы не поддерживаем musl", etc. Технически дело в том, чтобы не использовать 1 нестандартный макрос из #glibc, все musl-based дистрибутивы патчат это место - https://git.alpinelinux.org/aports/tree/community/vte3/fix-W_EXITCODE.patch.

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

Мое мнение о разрабах GNOME падают все ниже и ниже плинтуса. Половина из них - #errogant(я тут не могу написать предлагаемый перевод "высокомерный" для этого слова, потому что IMHO значение немного другое) мудаки, имеющие свою нетехническую повестку(реально это воспринимается именно так - "мы тут знаем что API Linux - это glibc, и не дадим вам про это забывать, минорной проблемой, которую просто откажемся чинить, потому что можем").

https://lobste.rs/s/zlanqi/end_nice_gtk_button#c_usyuo5

gnome-text-editor, кстати, ничо так, чистенько, опрятненько, ничего лишнего.

Поддержку перехода на libadwaita(и "1 theme to rule them all"), кстати, я поддерживаю. Жалко только, что libadwaita пока - так себе закос под macOS, надо лучше.

https://www.phoronix.com/news/Glibc-2.36-EAC-Problems

Треш, угар, содомия.

#glibc нарушили базовое предположение про совместимость, что код, собранный со старой glibc на старом Linux, продолжит работать и на новых Linux. #abi

Очень забавно, как Миша крутится, как уж на сковородке, пытаясь представить это как fault от valve:

"DT_GNU_HASH has been around for a decade and a half and can lead to much faster linking and loading times. Most Linux distributions and open-source software have been happily using DT_GNU_HASH for years"

"Ну, все же уже 10 лет используют новый хеш" (ну а все остальные - ССЗБ, видимо)

"With Glibc 2.36, DT_HASH no longer gets set since they dropped "--hash-style=both" since the DT_GNU_HASH is superior, most systems should just be using that, and eliminating the DT_HASH section saves about 1% or 16kB of space for the Glibc shared object"

Серьезно? Сука, сэкономили 16 килобайт в .so?

"Now we'll see what happens with upstream GNU C Library developers around this or if they'll wait it out and punt the ball into Epic Games' court to switch from depending upon DT_HASH to the DT_GNU_HASH that has been widely used on Linux systems for over a decade"

Не, ну раз 10 лет все(?) уже успешно используют новую фичу, то те, кто использует старую - ССЗБ, и их, конечно, можно послать.

Авторы glibc - #errogant(e intended) красноглазые пенсионеры, ничего они не откатят:

https://sourceware.org/pipermail/libc-alpha/2022-August/141304.html

- The choice to have DT_HASH is with the distributions. If this breaks specific applications then those developers need to engage with the ecosystem or adapt their software.

Errogant, потому что они, на голубом глазу, заявляют, что не ломают ABI:

"We aren't breaking ABI when we remove the PLT, remove the old HASH, or other Linux ELF change"...

Нет слов.

Будни #bootstrap

Я тут непоправимо улучшил свою реализацию sudo.

Напомню, что sudo у меня сделан через ssh на localhost, с эскалацией привилегий до root. Это, в том числе, позволяет не иметь #suid бинарников в системе.

К сожалению, у этого решения был недостаток - он не сохранял current work dir. И, в целом, это правильно - зачем же на удаленном серваке ssh выставлять cwd в тот cwd, который у клиента?

Для этого я запилил простенькую программу, https://github.com/pg83/ix/blob/main/pkgs/bin/setcwd/cwd.c, которая выставляет cwd, и делает exec в свой аргумент. Наверняка что-то такое есть в #execline, но, напомню, ее автор - #errogant упырь. То же самое можно было бы накостылять на sh, но тогда пришлось бы заниматься нетривиальным escaping аргументов.

Ну и заюзал ее в своей обертке над ssh - https://github.com/pg83/ix/blob/main/pkgs/bin/sud/runit/ix.sh#L24

Обертка так же прокидывает TMPDIR, через стандартную утилиту env, потому что а где еще создавать временные файлы, кроме как в моем же сессионном TMPDIR?

Другие env переменные моя обертка не прокидывает, и, КМК, это хорошо.

#rant

Я тут разбирался, почему у меня перестал собираться транковый #epiphany, выяснил, что они совершенно не стесняются заносить обратно-несовместимые изменения в нестабильную ветку gtk, и собираться с ней.

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

Но мой сегодняшний текст про другое.

Пока я грепал интернеты на предмет политики изменения epiphany и gtk, наткнулся на вот этот замечательный пост, https://blog.gtk.org/2022/12/15/a-grid-for-the-file-chooser/

(Кстати, пост написан небезызвестным нам господином Класеном)

Пост про то, как какой-то там рефакторинг в #gtk дал возможность запилить фичу, которую пользователи хотели последние 18 лет!

https://bugzilla.gnome.org/show_bug.cgi?id=141154

Теперь, после рефакторинга, это стало "easily possible now".

Прочел я это, сел, и задумался - очень мне интересно, что творилось в голове у человека, который 18 лет не давал запилить эту фичу(потому что #errogant разработчикам #gnome/gtk казалось, что оно будет сделано криво), и, наконец, написал в своем бложике "Judging from the number of likes on the merge request, this is a popular feature. We hope you enjoy it", и "It only took us 18 years"!

Реально, я это читаю как "мы 18 лет не делали популярную/нужную фичу, потому что нам казалась некрасивой/неправильной возможная реализация".

(да, я читал тред в багзилле, и я прекрасно понимаю, что, на самом деле, люди имеют в виду, когда пишут в такой ситуации "ну вы запилите патч, а мы на него посмотрим")

Иногда мне кажется, что разработка некоторых open source проектов totally broken.

Будни #bootstrap

Есть такая библиотека - libidn2.

На своем сайте, https://gitlab.com/libidn/libidn2, они утверждают, что могут (и что это предпочтительно) использовать системную libunistring (про эту всратую либу надо как-нибудь написать отдельно):

"The Libidn2 library may use GNU libunistring for Unicode processing and GNU libiconv for character set conversion. It is recommended to install them before building and installing libidn2. ... When the recommended libunistring is not available, libidn2 uses internal replacement functionality which increases the size of the library. To use the internal libunistring-replacement rather than the system libunistring (even when deemed to be sufficient) you may use..."

Но вот год назад они стали линковать в себя кусок этой самой libunistring статически (вкомпиливать в libunistring.so) - https://gitlab.com/libidn/libidn2/-/commit/c691cdf09c8c172ebaa5926348b8d41f5fadca4c

Что, зачем, а главное - нахера?

https://gitlab.com/libidn/libidn2/-/issues/104

Судя по всему, у них сломался ubsan на libunistring (это еще одна вечная проблема конвенциональных пакетных менеджеров, что собрать всю приложуху с санитайзером примерно невозможно), и они решили это подкостылить у себя, потому что апстрим (как это принято у проекта #GNU) - #errogant упыри, и не хотят сделать у себя лишний каст по какой-то надуманной причине (а на самом деле, потому что это значило бы признать свою неправоту, что, конечно, невозможно) - https://lists.gnu.org/archive/html/bug-gnulib/2022-03/msg00011.html #gnulib

Мораль?

Ее, как обычно, нет.

А вот как великие доебываются до стайлгайда на code review - https://www.phoronix.com/news/Linus-Comments-Bcachefs-6.6 #bcachefs #Kent

"А теперь ты приходишь и говоришь: Дон Корлеоне, мне нужна справедливость. Но ты не просишь с уважением, не предлагаешь дружбу, даже не думаешь обратиться ко мне — крёстный. Нет, ты приходишь ко мне в дом в день свадьбы моей дочери и просишь убивать за деньги"

"I need to know that you understand that if you actually want this upstream, you need to work with upstream.

That very much means *NOT* continuing this "I'll just do it my way". You need to show that you can work with others, that you can work within the framework of upstream, and that not every single thread you get into becomes an argument"

В целом, я не очень уважаю мейнтейнеров open source софта за их #errogant поведение, но тут сложно не согласиться с Линусом, и выглядит это все странно.

https://lwn.net/Articles/947941/

TL;DR - groff (это штука типа tex, только в реальной жизни ее используют для форматирования man pages), однажды очень давно сделали очень правильную вещь - The specified behavior of groff is that an ASCII "-" (Hyphen-Minus) in the input becomes a Hyphen in the output. Это не соответствует поведению оригинальной программы, с которой слизали groff.

Но вот ее текущему мейнтейнеру пришло в голову взять, и отменить это поведение.

Это, очевидно, поломало кучу man pages, потому что вы копируете оттуда "--help" в терминал, и у вас ничего не работает.

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

Автор изменения, конечно, редкостный #errogant мудила, потому что сделал это он, мол, потому, что хотел, чтобы в groff корректно рендерилось какое-то говно мамонта - https://github.com/g-branden-robinson/retypesetting-mathematics, а на то, что это изменение literally ломает тысячи man страниц, ему аще похуй.

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

Думаете, преувеличиваю?

Нет, все ровно так:

"If a person sits down to write a man page from scratch in a text editor, they will have things to learn, and in my opinion the hyphen/minus distinction is one of them. (As the original article suggested, there are in fact four other "ASCII" glyph distinctions to learn about.)
The theme of audience is also applicable to why I made this change in groff upstream. The GNU Project generally releases source archives, not binary packages. The primary consumers of groff releases from GNU are therefore, I would expect, people who already know of the package and desire to obtain it"

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

Короче, в комментах ЖЫР, не упустите!

#cargo #rust

Cargo довольно сильно сопротивляется патчингу исходников.

Натуральный способ патчинга в случае сборки с cargo - это завендорить все исходники, и, перед сборкой, запатчить завендоренное.

Есть вот такой вот тикет https://github.com/rust-lang/cargo/issues/11063 (полагаю, не единственный), там обсуждаются разные всратые решения этой проблемы.

Понятное дело, что #errogant upstream на хую вертел downstream, потому что "собирайтесь как автор кода захотел левой пяткой", а проблемы негров (конкретно, людей, которым нужно собираться в разных необычных окружениях, типа моего) их не волнуют.

Я потырил решение у IBM RedHat сообщества федоры - https://src.fedoraproject.org/rpms/rust//blob/rawhide/f/rust.spec#_615, им, сюрприз-сюрприз, тоже хочется уметь развендоренные исходники, чего бы там себе не воображали школота зумеры разработчики на Rust. Потому что баги в libz/libgit2/openssl патчить им, а не тем, кто принудительно завендорил исходники, без возможности сборки с системным вариантом.

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

Развендориваю я их довольно грубо - сначала ищу все крейты в которых есть c/c++ файлы (https://github.com/pg83/ix/blob/main/pkgs/bld/rust/devendor/scripts/classify.py), потом "обнуляю" сборку этих крейтов (https://github.com/pg83/ix/blob/main/pkgs/bld/rust/devendor/scripts/devendor.sh#L14-L17) Федора развендоривает какие-то заранее известные крейты - https://src.fedoraproject.org/rpms/rust//blob/rawhide/f/rust.spec#_585

Есть такой проект - https://keepassxc.org/

Давно хочу его попробовать, но он собран с Qt5, а мне лень заниматься сборкой Qt5, раз уже есть Qt6.

Есть вот такой тред про порт keepassxc на Qt6 - https://github.com/keepassxreboot/keepassxc/pull/10267

Мало того что мейнтейнеры морозили прогресс по этой деятельности несколько лет, потому что им не хотелось иметь ifdef в кодовой базе (https://github.com/keepassxreboot/keepassxc/issues/7774#issuecomment-1086864573, спойлер - ifdef таки появились), но вот, на днях, вообще отшили внешнего человека, который принес им целый готовый порт на Qt6 (https://github.com/keepassxreboot/keepassxc/issues/7774#issuecomment-1925076778), только потому, что у них кто-то из команды уже такой порт запилил, но не удосужился сделать хотя бы PR с ним.

https://github.com/keepassxreboot/keepassxc/issues/7774#issuecomment-1925086388

Мейнтейнеры keepassxc - #errogant говнюки, что еще можно сказать. Там diff на несколько тысяч строк, раскидываться такой титанической работой - не дело.

Ну и, я так полагаю, через несколько дней поддержка Qt6 там появится - https://github.com/keepassxreboot/keepassxc/pull/10267