[devel] incoming/girar: проблема производительности.

[devel] incoming/girar: проблема производительности.

[Igor Vlasenko]

1. incoming/girar: проблема видна была издалека.
________________________________________________

Когда-то давно я столкнулся с проблемой, что тогдашний incoming
слишком медленно обрабатывал пакеты. Это стало одной из причин,
почему появился отдельный репозиторий autoimports.

Года 3 назад я написал ряд писем в devel@, которые описывали алгоритмы
параллелизации работы сборочницы, которые позволили бы существенно
(на порядки) повысить ее производительность.

Содержимое этих писем доступно на
https://www.altlinux.org/Girar/Parallel .

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

Дмитрий заинтересовался, но не совсем тем, чем хотелось,
а вопросом, нельзя ли как-то уменьшить число релизов от моих роботов,
что я в итоге сделал для импорта из федоры и магейи,
и начал делать для java.

Полтора года назад, обобщив свой опыт разработки сборочницы для
autoimports, я понял, что нужно делать с incoming/girar,
чтобы облегчить его совместную разработку.

Задним числом мое предложение выглядит так:
разделить girar на серверную и локальную части.
Выделить из girar локальную сборочницу, с помощью которой каждый может
локально у себя сформировать таск, локально его собрать на локальных
архитектурах машины (i586/x86_64 или armh/aarch64) и пропустить через
полный набор тестов girar для таска,
при необходимости локально выпустить новый репозиторий из старого
репозитория и таска и тоже пропустить полученный репозиторий через
полный набор тестов girar для репозитория.

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

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

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

Чтобы показать, что можно сделать от переписывания локальной сборочницы,
я написал тогда письмо в devel@, где сравнил производительность
тогдашней сборочницы (1.000 пак./сут.) со своими скриптами для
autoimports, которые на той же задаче собрать-протестировать task
достигали производительности в пол пакета в секунду (40.000 пак./сут.)

Тогда это письмо осталось не понятым. Народ спрашивал, зачем вообще
нужна производительная сборочница, а я не смог тогда обосновать лучше,
чем "такая производительность нужна для того, чтобы собирать
множество модулей perl и библиотек других языков".

Сейчас у меня, возможно, получится объяснить.
Компьютерный мир сверхмонополистичен. В платном п/о нишу, как правило,
занимает кто-то один. В открытом п/о нишу обычно занимают 2 мейнстримных пакета
и есть хвост экспериментов. 2 браузера, хромиум и фаерфокс, 2
консольных редактора, vim и emacs, 2 графических редактора, gimp и
cinepaint, ...

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

К сожалению, не всем это очевидно. Здесь я чувствую себя героем книг
про АИ и попаданцев. Типичный сеттинг --- АИ. в свое время князья и
бояре московские прощелкали клювом и теперь Москва --- районный центр
Владимирской области с 15 тысячами населения. Герой возвращается в
прошлое, которое можно еще изменить, и рассказывает про альтернативную
Москву, столицу необъятных территорий, мегаполис-миллионник.
А для народа это все сказки, ему в ответ
- Что ты несешь, блаженный. 15 тысяч пакетов по нынешним временам
это же очень и очень круто, а больше и не нужно :(

Каким боком здесь сборочница?
Сборочница выступает в роли логистического ограничителя.
В космосе можно содержать базу в 10 человек. В Антарктиде -- сотню.
В Сибири вдали от рек и дорог -- тысячу.
Если грузы можно доставить по реке или грунтовке, то еще на порядок больше.
Если там крупный морской порт и/ли железная дорога, то пределов росту
нет, была бы за что завозить и что вывозить.
Наша сборочница медленная, и для нас она выступает в роли грунтовки или
мощенного конного тракта. Вроде бы дорога и есть, но реально много пакетов
провезти по ней в дистрибутив не получится.

Что я могу с этим сделать? Полтора года назад, после упомянутого выше
письма в Сизиф, я начал переписывать свои скрипты для autoimports
в прототип локальной сборочницы. При этом нашел еще один резерв для
улучшения быстродействия сборочницы -- за счет оптимизации работы
hasher при работе с неизменным репозиторием.
Одна из таких оптимизаций ---
https://bugzilla.altlinux.org/show_bug.cgi?id=36531
экономия 10 секунд при создании chroot.
Какой это эффект дало бы для сборочницы?
Простой таск с 1 пакетом -- в среднем быстрее на 30 секунд (10 секунд на
сборочный чрут и по 10 секунд на install test chroot для 2-х бинарных
пакетов). На больших транзакциях больше.
К примеру, пересборка perl будет выполняться быстрее на 20 минут,
пересборка python -- быстрее на час.

#36531 -- тривиальный патч: сделать (кусок кода) отключаемым:
if(переменная) { (кусок кода) }.
Но я после недели обсуждений с Дмитрием так и не смог пробить
#36531 в апстрим hasher :(. В итоге форкнул свою копию hasher
и свернул свою разработку прототипа локальной сборочницы. :(

Возможно, проявив большую настойчивость, зудя Дмитрию,
как комар над ухом, еще за неделю и продавил бы патч в апстрим.
Но это было только начало работы над прототипом --
в скриптах от autoimports использовалась еще одна оптимизация
работы hasher -- кеширование рабочего каталога. Там это было
сделано хаком -- хардлинк-копией образца рабочего каталога hasher,
но по хорошему эту возможность нужно было тоже переносить
на уровень hasher. И сколько еще возникнет таких моментов...
А в перспективе, после начальной рабочей версии прототипа,
последовал бы рефакторинг сборочницы с выделением локальной сборочницы в
отдельный независимый от сервера пакет, где счет изменениям
пошел бы на сотни. Если каждый чих рассматривать неделю,
я бы таких задержек не выдержал.
Впрочем, год назад оказался в похожей ситуации с wm-select
https://bugzilla.altlinux.org/show_bug.cgi?id=37190
так что, возможно, такое отношение к патчам со сборочницей не связано.

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

За это время в русле "пчелы против меда" событий произошло мало,
Дмитрий ругал ruby-team, критиковал кого-то, кто отправил пакет
на пересборку зря, но меня не трогал.

Тем неожиданнее стали дальнейшие события.

2. incoming/girar: помощь подкралась незаметно.
_______________________________________________

Весной я взялся опять обновлять perl.
Подвоха я не чувствовал. Там в транзакции 420+ пакетов,
и оптимизировать там, как казалось, нечего, природу не
обмануть, 420+ пакетов придется пересобрать.

Небольшое отступление.
До этого зимой пробовал обновиться до 5.28, подготовил обновление,
но 5 пакетов из транзакции perl были в FTBFS, развешал баги
на починку, и отложил в сторону. К весне дождался,
но как раз вышел 5.30 и нужно было готовить обновление заново.
В отличие от обновления python, обновление perl плотно заскриптовано
и все шаги по обновлению расписаны в методичке прямо в git в папке
perl.git/altlinux/maintainer_notes
http://git.altlinux.org/people/viy/packages/?p=perl.git;a=tree;f=altlinux/maintainer_notes
Поэтому обновление perl проводить на порядок легче, чем вручную.
Нужно заметить, что логистика автоматизированного обновления
напоминает железную дорогу. Рельсы -- это заскриптованные пути
для обновления. Вне рельсов поезд (транзакция) не едет,
это то же самое, что разгрузить груз с поезда в мешки
и тащить вручную -- формально можно, но слишком затратно по сравнению
с доставкой по рельсах, никто так делать не захочет.
Вне заскриптованных маршрутов что угодно забирает сил и времени
на порядки больше. Если куда-то позарез ехать надо,
проще сначала проложить рельсы (заскриптовать).
Пакеты в FTBFS для транзакции perl как красный свет --
в истрии с обновлением 5.28 поезд на рельсах, транзакция загружена,
но путь занят -- поезд не сможет проехать,
пока хоть один пакет из транзакции не собирается.

Итак, занимался я обновлением perl. Отправил, наконец,
транзакцию с perl на сборку. Но утром пришел неожиданный результат --
сборка прервана, у в работу сборочницы вмешался Дмитрий,
который, как оказалось, пришел мне помочь,
а транзакцию остановил, так как ее можно оптимизировать
с использованием task rebuild.

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

Надо сказать, Дмитрий и раньше злоупотреблял своим положением
администратора сборочницы, но когда речь шла об одиночных
пакетах, то обычно была какая-то польза или хотя бы повод,
а вреда от остановки task'а особого не было,
одиночный пакет можно потом перезалить хоть через полгода,
сделанная работа не пропадет зря.

В случае же с транзакциями все наоборот. Транзакция из сотен пакетов,
которая успешно соберется сегодня, завтра уже может и не соберется.
Один из пакетов устарел, или вдруг перестал собираться --
вся транзакция на свалку. Собралась транзакция --- хорошо, задача выполнена.
Не собралась (естественным образом) -- тоже хорошо, узнали
что-то новое, чего раньше не знали и что надо исправлять.

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

Эмоции в корректной форме можно было выразить анекдотом:

В детском саду случилось ЧП: после того, как два солдата починили электропроводку, дети стали материться. Руководитель детского сада – жалобу командиру части, тот вызывает солдат и спрашивает:
-Так, бойцы, на вас тут жалоба – дети после вашей работы воспитателей по матери и отцу склонять начали. Докладайте – это ваших рук дело?
-Никак нет! – отвечают бойцы. -Не ругались вовсе.
-Быть такого не может, – не верит командир. -А инциденты были?
-Был один, но все было благопристойно, товарищ командующий. – докладывает тот, который постарше. -Рядовой Сидоров стоял на стремянке и паял провод, а я держал стремянку, и тут мне на голову стало капать расплавленное олово...
-Ну и!.. – не терпится командиру.
-А я ему и говорю: рядовой Сидоров, разве ты не видишь, что на голову твоему боевому товарищу капает расплавленное олово?

В общем, приложило эмоциями меня сильно, но сдержался,
тем более, транзакцию уже не вернешь.
Постарался пойти навстречу. Предложение Дмитрия было
вполне здравое и не так сложно --- скрипты писались в расчете
и на такой вариант, осталось только явно его выписать
и протестировать (даже нашел баг в сборочнице
#38332 https://bugzilla.altlinux.org/show_bug.cgi?id=38332 )
Через неделю улучшенные скрипты были готовы, можно было продолжать.

Но вместо обновления получился цирк, так как Дмитрий
продолжил мне помогать, а я слова не мог сказать, поскольку
боялся поддаться эмоциям и начать выражаться нецензурно.
Получилась история, когда к Кролику пришел в гости Винни Пух.
Что по этому поводу подумал Кролик, так и осталось тайной.
Дмитрий в простоте своей умудрился еще раз на бис
прервать сборку транзакции, после чего сам смысл пытаться обновить perl
стал под большим вопросом, а потом и вообще "застрял в норе,
закупорив вход" --- обновление оказалось невозможным без починки пакета sdf,
пакета с жестким acl=ldv, о чем Дмитрий даже написал в рассылке,
но как-то чинить пакет или открывать acl не стал.

Проблема была в том, что и Дмитрий действовал не со зла и не нарочно,
но получилось по пословице "простота хуже воровства". И вообще эта
тема со сборочницей будет не понятна большинству майнтайнеров до тех пор,
пока они сами не столкнутся на практике с автоматизированной
обработкой большого числа пакетов.
А развернуто объяснить, вместо ругани, не так просто.

3. incoming/girar: истоки проблемы.
_______________________________________________

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

Со мной Дмитрий пытался оптимизировать майнтайнера к сборочнице,
а я хотел наоборот. Что же мне мешает оптимизироваться?

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

Рассмотрим, к примеру, наше новое полиси по заполнению лицензий.
При ручной работе правку тега License как отдельную задачу
выполнять не выгодно. Это была бы достаточно монотонная
отупляющая работа, тратящая и время человека, и время сборочницы.
При ручной работе выгодно правку тега License выполнять
как сопутствующую работу при релизе пакета. Экономится
и человеческое время (одно обращение к пакету и спек файлу
по двум поводам), и время сборочницы. Минусом является то, что
при этом само внедрение полиси размазывается на годы.
Каждый раз при релизе пакета нужно заодно взглянуть и при необходимости поправить тег.

При автоматизированном подходе все наоборот.
Когда пакетов десятки тысяч, проще написать скрипт - корректор
тега License. Парсим тег License, считаем md5sum LICENSE COPYING
(хвоста файла для MIT лицензий), делаем выводы,
генерируем исправленные пакеты и список сложных случаев.
Очень существенно экономим человеческое время за счет машинного.
Р-р-раз и 100500 пакетов готово.
Второй плюс - полиси внедряется практически мгновенно.
Но нужна нормальная сборочница. Которая способна пересобрать
исправления менее чем за сутки.

Еще раз. Если здесь раздадутся голоса -- зачем насиловать сборочницу,
гонять лишний релиз ради тега License? То ответ -- зачем тогда
принимать полиси, если его внедрение не стоит релиза?
Здесь полиси по заполнению лицензий можно заменить
на shared libs policy. С которым у нас уже 10 лет внедрение все идет и
никак не дойдет. Вот напишу я преобразователь в shared libs policy ...

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


-- 

I V

Re: [devel] incoming/girar: проблема производительности.

[Anton Farygin]

On 27.08.2020 05:29, Igor Vlasenko wrote:
> 1. incoming/girar: проблема видна была издалека.
> ________________________________________________
<skip>
> Не надо жалеть сборочницу, это робот, который работает за электроэнергию.
> "Жалеть" сборочницу и издеваться над людьми --- это и есть извращение.
> Сборочницу не надо "жалеть", ее надо переписать для улучшения
> производительности. Тогда хорошо будет всем.
>
>
Игорь, спасибо за интересное и длинное письмо по этому важному вопросу.

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

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

Но нужно понимать, что эта клёвая фича основана на использовании в 
качестве базы данных файловой системы.

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

Живёт это всё сейчас, вроде как, на ext4 (я могу ошибаться). 
Максимальное количество inodes у ext4 2^32 - 4,294,967,295

Каждый новый таск в репозиторий приводит к тому, что на файловой системе 
появляется около 160 тысяч (а может быть и больше, я давно не смотрел 
цифры) новых записей.

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

Дальше можно порассуждать на предмет смены файловой системы, но я (для 
зеркала архива) проводил сравнение и более-менее рабочим вариантом 
оказалась только zfs, которая работает быстрее всего остального 
подобного, но сильно медленнее ext4.


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

В общем, я бы начал именно отсюда, но у Димы наверняка есть какой-то 
план работ по сборочнице, про который не знает никто, кроме тех, кто 
принимает участие в её разработки.

С другой стороны, если весь perl собирается в одном задании, о мои 
рассуждения о том, что есть какая-то проблема с архивом - ничтожны, и в 
данном случае проблема в чём-то другом.

Что касается лично моего мнения по тому сборочному заданию с perl - на 
мой взгляд, увеличение релиза в пакете для rebuild - это нормальная 
практика и я не вижу в этом ничего плохого, скорее даже наоборот - в 
этом есть некоторый смысл, т.к. (я про это уже неоднократно писал) - в 
процессе rebuild пакет становится другим и было бы неплохо научиться его 
отличать по имени файла, а не только по его содержимому.

авторы фичи с DistTag обещали добавить что-то в имена файлов, но пока 
это всё остановилось на обещаниях.

И ещё пару слов про автоматическую пересборку для мелких исправлений 
пакетов: есть (не)маленькая проблема с тем, что в результате такой 
пересборки может получится не просто изменение тэга License, но и вообще 
другой пакет, с другим содержимым и работающий иначе, чем до 
пересборки.  Просто потому, что необходимые ему для сборки пакеты 
меняются в тех местах, в которых сборочница отследить эти изменения не 
может.

Re: [devel] incoming/girar: проблема производительности.

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2199 bytes --]

On Thu, 27 Aug 2020 10:27:11 +0300 Anton Farygin wrote:
[...]
> Т.е. - для экономии места старые пакеты хардлинкаются в новое место и в 
> него уже добавляются изменения из сборочного задания. Очень простая и 
> очень надёжная схема, при которой риск потери данных минимален и всегда 
> можно взять консистентное состояние репозитория за любой момент времени.
> 
> Живёт это всё сейчас, вроде как, на ext4 (я могу ошибаться). 
> Максимальное количество inodes у ext4 2^32 - 4,294,967,295
> 
> Каждый новый таск в репозиторий приводит к тому, что на файловой системе 
> появляется около 160 тысяч (а может быть и больше, я давно не смотрел 
> цифры) новых записей.
> 
> Т.е. - условно мы можем записать около 26 тысяч сборочных заданий в 
> архив, а после этого из него придётся удалять что-то старое для того, 
> что бы записать что-то новое.

Это полная чушь, поскольку все жесткие ссылки на файл используют
один и тот же inode:

https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Directory_Entries

In an ext4 filesystem, a directory is more or less a flat file that
maps an arbitrary byte string (usually ASCII) to an inode number on
the filesystem. There can be many directory entries across the
filesystem that reference the same inode number--these are known as
hard links, and that is why hard links cannot reference files on
other filesystems. As such, directory entries are found by reading
the data block(s) associated with a directory file for the
particular directory entry that is desired. 

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] incoming/girar: проблема производительности.

[Anton Farygin]

On 27.08.2020 14:54, Andrey Savchenko wrote:
> On Thu, 27 Aug 2020 10:27:11 +0300 Anton Farygin wrote:
> [...]
>> Т.е. - для экономии места старые пакеты хардлинкаются в новое место и в
>> него уже добавляются изменения из сборочного задания. Очень простая и
>> очень надёжная схема, при которой риск потери данных минимален и всегда
>> можно взять консистентное состояние репозитория за любой момент времени.
>>
>> Живёт это всё сейчас, вроде как, на ext4 (я могу ошибаться).
>> Максимальное количество inodes у ext4 2^32 - 4,294,967,295
>>
>> Каждый новый таск в репозиторий приводит к тому, что на файловой системе
>> появляется около 160 тысяч (а может быть и больше, я давно не смотрел
>> цифры) новых записей.
>>
>> Т.е. - условно мы можем записать около 26 тысяч сборочных заданий в
>> архив, а после этого из него придётся удалять что-то старое для того,
>> что бы записать что-то новое.
> Это полная чушь, поскольку все жесткие ссылки на файл используют
> один и тот же inode:
>
> https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Directory_Entries
>
> In an ext4 filesystem, a directory is more or less a flat file that
> maps an arbitrary byte string (usually ASCII) to an inode number on
> the filesystem. There can be many directory entries across the
> filesystem that reference the same inode number--these are known as
> hard links, and that is why hard links cannot reference files on
> other filesystems. As such, directory entries are found by reading
> the data block(s) associated with a directory file for the
> particular directory entry that is desired.
>
Точно. Не хардлинки, а симлинки. Спасибо за замечание.

Re: [devel] архивирование репозиториев

[Dmitry V. Levin]

On Thu, Aug 27, 2020 at 02:59:22PM +0300, Anton Farygin wrote:
> On 27.08.2020 14:54, Andrey Savchenko wrote:
> > On Thu, 27 Aug 2020 10:27:11 +0300 Anton Farygin wrote:
> > [...]
> >> Т.е. - для экономии места старые пакеты хардлинкаются в новое место и в
> >> него уже добавляются изменения из сборочного задания. Очень простая и
> >> очень надёжная схема, при которой риск потери данных минимален и всегда
> >> можно взять консистентное состояние репозитория за любой момент времени.
> >>
> >> Живёт это всё сейчас, вроде как, на ext4 (я могу ошибаться).
> >> Максимальное количество inodes у ext4 2^32 - 4,294,967,295
> >>
> >> Каждый новый таск в репозиторий приводит к тому, что на файловой системе
> >> появляется около 160 тысяч (а может быть и больше, я давно не смотрел
> >> цифры) новых записей.
> >>
> >> Т.е. - условно мы можем записать около 26 тысяч сборочных заданий в
> >> архив, а после этого из него придётся удалять что-то старое для того,
> >> что бы записать что-то новое.
> > Это полная чушь, поскольку все жесткие ссылки на файл используют
> > один и тот же inode:
> >
> > https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Directory_Entries
> >
> > In an ext4 filesystem, a directory is more or less a flat file that
> > maps an arbitrary byte string (usually ASCII) to an inode number on
> > the filesystem. There can be many directory entries across the
> > filesystem that reference the same inode number--these are known as
> > hard links, and that is why hard links cannot reference files on
> > other filesystems. As such, directory entries are found by reading
> > the data block(s) associated with a directory file for the
> > particular directory entry that is desired.
> >
> Точно. Не хардлинки, а симлинки. Спасибо за замечание.

В архиваторе репозиториев используется захардлинкивание симлинков
для уменьшения количества используемых inode'ов.


-- 
ldv

Re: [devel] архивирование репозиториев

[Anton Farygin]

On 27.08.2020 15:09, Dmitry V. Levin wrote:
> On Thu, Aug 27, 2020 at 02:59:22PM +0300, Anton Farygin wrote:
>> On 27.08.2020 14:54, Andrey Savchenko wrote:
>>> On Thu, 27 Aug 2020 10:27:11 +0300 Anton Farygin wrote:
>>> [...]
>>>> Т.е. - для экономии места старые пакеты хардлинкаются в новое место и в
>>>> него уже добавляются изменения из сборочного задания. Очень простая и
>>>> очень надёжная схема, при которой риск потери данных минимален и всегда
>>>> можно взять консистентное состояние репозитория за любой момент времени.
>>>>
>>>> Живёт это всё сейчас, вроде как, на ext4 (я могу ошибаться).
>>>> Максимальное количество inodes у ext4 2^32 - 4,294,967,295
>>>>
>>>> Каждый новый таск в репозиторий приводит к тому, что на файловой системе
>>>> появляется около 160 тысяч (а может быть и больше, я давно не смотрел
>>>> цифры) новых записей.
>>>>
>>>> Т.е. - условно мы можем записать около 26 тысяч сборочных заданий в
>>>> архив, а после этого из него придётся удалять что-то старое для того,
>>>> что бы записать что-то новое.
>>> Это полная чушь, поскольку все жесткие ссылки на файл используют
>>> один и тот же inode:
>>>
>>> https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Directory_Entries
>>>
>>> In an ext4 filesystem, a directory is more or less a flat file that
>>> maps an arbitrary byte string (usually ASCII) to an inode number on
>>> the filesystem. There can be many directory entries across the
>>> filesystem that reference the same inode number--these are known as
>>> hard links, and that is why hard links cannot reference files on
>>> other filesystems. As such, directory entries are found by reading
>>> the data block(s) associated with a directory file for the
>>> particular directory entry that is desired.
>>>
>> Точно. Не хардлинки, а симлинки. Спасибо за замечание.
> В архиваторе репозиториев используется захардлинкивание симлинков
> для уменьшения количества используемых inode'ов.
Ух ты, это же здорово. А где посмотреть исходники ?

в girar я сходу это не увидел.

Re: [devel] архивирование репозиториев

[Dmitry V. Levin]

On Thu, Aug 27, 2020 at 03:14:27PM +0300, Anton Farygin wrote:
> On 27.08.2020 15:09, Dmitry V. Levin wrote:
> > On Thu, Aug 27, 2020 at 02:59:22PM +0300, Anton Farygin wrote:
> >> On 27.08.2020 14:54, Andrey Savchenko wrote:
> >>> On Thu, 27 Aug 2020 10:27:11 +0300 Anton Farygin wrote:
> >>> [...]
> >>>> Т.е. - для экономии места старые пакеты хардлинкаются в новое место и в
> >>>> него уже добавляются изменения из сборочного задания. Очень простая и
> >>>> очень надёжная схема, при которой риск потери данных минимален и всегда
> >>>> можно взять консистентное состояние репозитория за любой момент времени.
> >>>>
> >>>> Живёт это всё сейчас, вроде как, на ext4 (я могу ошибаться).
> >>>> Максимальное количество inodes у ext4 2^32 - 4,294,967,295
> >>>>
> >>>> Каждый новый таск в репозиторий приводит к тому, что на файловой системе
> >>>> появляется около 160 тысяч (а может быть и больше, я давно не смотрел
> >>>> цифры) новых записей.
> >>>>
> >>>> Т.е. - условно мы можем записать около 26 тысяч сборочных заданий в
> >>>> архив, а после этого из него придётся удалять что-то старое для того,
> >>>> что бы записать что-то новое.
> >>> Это полная чушь, поскольку все жесткие ссылки на файл используют
> >>> один и тот же inode:
> >>>
> >>> https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Directory_Entries
> >>>
> >>> In an ext4 filesystem, a directory is more or less a flat file that
> >>> maps an arbitrary byte string (usually ASCII) to an inode number on
> >>> the filesystem. There can be many directory entries across the
> >>> filesystem that reference the same inode number--these are known as
> >>> hard links, and that is why hard links cannot reference files on
> >>> other filesystems. As such, directory entries are found by reading
> >>> the data block(s) associated with a directory file for the
> >>> particular directory entry that is desired.
> >>>
> >> Точно. Не хардлинки, а симлинки. Спасибо за замечание.
> > В архиваторе репозиториев используется захардлинкивание симлинков
> > для уменьшения количества используемых inode'ов.
> Ух ты, это же здорово. А где посмотреть исходники ?
> 
> в girar я сходу это не увидел.

git grep GA_SYMLINK_DIR.

В ext4 есть ограничение на количество хардлинков, которе может быть
у симлинка, я постарался это учесть.


-- 
ldv

Re: [devel] архивирование репозиториев

[Anton Farygin]

On 27.08.2020 15:20, Dmitry V. Levin wrote:
> On Thu, Aug 27, 2020 at 03:14:27PM +0300, Anton Farygin wrote:
>> On 27.08.2020 15:09, Dmitry V. Levin wrote:
>>> On Thu, Aug 27, 2020 at 02:59:22PM +0300, Anton Farygin wrote:
>>>> On 27.08.2020 14:54, Andrey Savchenko wrote:
>>>>> On Thu, 27 Aug 2020 10:27:11 +0300 Anton Farygin wrote:
>>>>> [...]
>>>>>> Т.е. - для экономии места старые пакеты хардлинкаются в новое место и в
>>>>>> него уже добавляются изменения из сборочного задания. Очень простая и
>>>>>> очень надёжная схема, при которой риск потери данных минимален и всегда
>>>>>> можно взять консистентное состояние репозитория за любой момент времени.
>>>>>>
>>>>>> Живёт это всё сейчас, вроде как, на ext4 (я могу ошибаться).
>>>>>> Максимальное количество inodes у ext4 2^32 - 4,294,967,295
>>>>>>
>>>>>> Каждый новый таск в репозиторий приводит к тому, что на файловой системе
>>>>>> появляется около 160 тысяч (а может быть и больше, я давно не смотрел
>>>>>> цифры) новых записей.
>>>>>>
>>>>>> Т.е. - условно мы можем записать около 26 тысяч сборочных заданий в
>>>>>> архив, а после этого из него придётся удалять что-то старое для того,
>>>>>> что бы записать что-то новое.
>>>>> Это полная чушь, поскольку все жесткие ссылки на файл используют
>>>>> один и тот же inode:
>>>>>
>>>>> https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Directory_Entries
>>>>>
>>>>> In an ext4 filesystem, a directory is more or less a flat file that
>>>>> maps an arbitrary byte string (usually ASCII) to an inode number on
>>>>> the filesystem. There can be many directory entries across the
>>>>> filesystem that reference the same inode number--these are known as
>>>>> hard links, and that is why hard links cannot reference files on
>>>>> other filesystems. As such, directory entries are found by reading
>>>>> the data block(s) associated with a directory file for the
>>>>> particular directory entry that is desired.
>>>>>
>>>> Точно. Не хардлинки, а симлинки. Спасибо за замечание.
>>> В архиваторе репозиториев используется захардлинкивание симлинков
>>> для уменьшения количества используемых inode'ов.
>> Ух ты, это же здорово. А где посмотреть исходники ?
>>
>> в girar я сходу это не увидел.
> git grep GA_SYMLINK_DIR.
>
> В ext4 есть ограничение на количество хардлинков, которе может быть
> у симлинка, я постарался это учесть.
>
>
Класс. Спасибо.

т.е. - моё предположение про inodes ошибочно и мы здесь не упрёмся. Т.е. 
- в принципе ничего экстраординарного в большом росте количества заданий 
за счёт роботов нет и архиватор это должен переварить (если опять, же 
учитывать время на создание копии архива на файловой системе, которое 
скорее всего не параллелится и упрётся просто в IO).

Я ведь правильно понял Игоря, что он хочет сборочницу, которая будет 
пропускать десятки тысяч сборочных заданий в день ?

Представляю, какой адской задачей выглядит скопировать этот архив на 
соседний сервер...

А нет ли внутри всей этой машинерии где-то хранилища, в котором собраны 
все бинарные и исходные rpm пакеты за всю историю с именем, равным 
какому-то хешу этого пакета ?

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

Re: [devel] архивирование репозиториев

[Dmitry V. Levin]

On Thu, Aug 27, 2020 at 03:32:53PM +0300, Anton Farygin wrote:
> On 27.08.2020 15:20, Dmitry V. Levin wrote:
> > On Thu, Aug 27, 2020 at 03:14:27PM +0300, Anton Farygin wrote:
> >> On 27.08.2020 15:09, Dmitry V. Levin wrote:
> >>> On Thu, Aug 27, 2020 at 02:59:22PM +0300, Anton Farygin wrote:
> >>>> On 27.08.2020 14:54, Andrey Savchenko wrote:
> >>>>> On Thu, 27 Aug 2020 10:27:11 +0300 Anton Farygin wrote:
> >>>>> [...]
> >>>>>> Т.е. - для экономии места старые пакеты хардлинкаются в новое место и в
> >>>>>> него уже добавляются изменения из сборочного задания. Очень простая и
> >>>>>> очень надёжная схема, при которой риск потери данных минимален и всегда
> >>>>>> можно взять консистентное состояние репозитория за любой момент времени.
> >>>>>>
> >>>>>> Живёт это всё сейчас, вроде как, на ext4 (я могу ошибаться).
> >>>>>> Максимальное количество inodes у ext4 2^32 - 4,294,967,295
> >>>>>>
> >>>>>> Каждый новый таск в репозиторий приводит к тому, что на файловой системе
> >>>>>> появляется около 160 тысяч (а может быть и больше, я давно не смотрел
> >>>>>> цифры) новых записей.
> >>>>>>
> >>>>>> Т.е. - условно мы можем записать около 26 тысяч сборочных заданий в
> >>>>>> архив, а после этого из него придётся удалять что-то старое для того,
> >>>>>> что бы записать что-то новое.
> >>>>> Это полная чушь, поскольку все жесткие ссылки на файл используют
> >>>>> один и тот же inode:
> >>>>>
> >>>>> https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Directory_Entries
> >>>>>
> >>>>> In an ext4 filesystem, a directory is more or less a flat file that
> >>>>> maps an arbitrary byte string (usually ASCII) to an inode number on
> >>>>> the filesystem. There can be many directory entries across the
> >>>>> filesystem that reference the same inode number--these are known as
> >>>>> hard links, and that is why hard links cannot reference files on
> >>>>> other filesystems. As such, directory entries are found by reading
> >>>>> the data block(s) associated with a directory file for the
> >>>>> particular directory entry that is desired.
> >>>>>
> >>>> Точно. Не хардлинки, а симлинки. Спасибо за замечание.
> >>> В архиваторе репозиториев используется захардлинкивание симлинков
> >>> для уменьшения количества используемых inode'ов.
> >> Ух ты, это же здорово. А где посмотреть исходники ?
> >>
> >> в girar я сходу это не увидел.
> > git grep GA_SYMLINK_DIR.
> >
> > В ext4 есть ограничение на количество хардлинков, которе может быть
> > у симлинка, я постарался это учесть.
> >
> Класс. Спасибо.
> 
> т.е. - моё предположение про inodes ошибочно и мы здесь не упрёмся. Т.е. 
> - в принципе ничего экстраординарного в большом росте количества заданий 
> за счёт роботов нет и архиватор это должен переварить (если опять, же 
> учитывать время на создание копии архива на файловой системе, которое 
> скорее всего не параллелится и упрётся просто в IO).
> 
> Я ведь правильно понял Игоря, что он хочет сборочницу, которая будет 
> пропускать десятки тысяч сборочных заданий в день ?
> 
> Представляю, какой адской задачей выглядит скопировать этот архив на 
> соседний сервер...
> 
> А нет ли внутри всей этой машинерии где-то хранилища, в котором собраны 
> все бинарные и исходные rpm пакеты за всю историю с именем, равным 
> какому-то хешу этого пакета ?
> 
> Что бы можно было скачать только его, а дальше раскрутить весь архив 
> скриптами по метаинформации из сборочных заданий.

Да, есть, называется depot.


-- 
ldv

Re: [devel] архивирование репозиториев

[Anton Farygin]

On 27.08.2020 18:59, Dmitry V. Levin wrote:
> On Thu, Aug 27, 2020 at 03:32:53PM +0300, Anton Farygin wrote:
>> On 27.08.2020 15:20, Dmitry V. Levin wrote:
>>> On Thu, Aug 27, 2020 at 03:14:27PM +0300, Anton Farygin wrote:
>>>> On 27.08.2020 15:09, Dmitry V. Levin wrote:
>>>>> On Thu, Aug 27, 2020 at 02:59:22PM +0300, Anton Farygin wrote:
>>>>>> On 27.08.2020 14:54, Andrey Savchenko wrote:
>>>>>>> On Thu, 27 Aug 2020 10:27:11 +0300 Anton Farygin wrote:
>>>>>>> [...]
>>>>>>>> Т.е. - для экономии места старые пакеты хардлинкаются в новое место и в
>>>>>>>> него уже добавляются изменения из сборочного задания. Очень простая и
>>>>>>>> очень надёжная схема, при которой риск потери данных минимален и всегда
>>>>>>>> можно взять консистентное состояние репозитория за любой момент времени.
>>>>>>>>
>>>>>>>> Живёт это всё сейчас, вроде как, на ext4 (я могу ошибаться).
>>>>>>>> Максимальное количество inodes у ext4 2^32 - 4,294,967,295
>>>>>>>>
>>>>>>>> Каждый новый таск в репозиторий приводит к тому, что на файловой системе
>>>>>>>> появляется около 160 тысяч (а может быть и больше, я давно не смотрел
>>>>>>>> цифры) новых записей.
>>>>>>>>
>>>>>>>> Т.е. - условно мы можем записать около 26 тысяч сборочных заданий в
>>>>>>>> архив, а после этого из него придётся удалять что-то старое для того,
>>>>>>>> что бы записать что-то новое.
>>>>>>> Это полная чушь, поскольку все жесткие ссылки на файл используют
>>>>>>> один и тот же inode:
>>>>>>>
>>>>>>> https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Directory_Entries
>>>>>>>
>>>>>>> In an ext4 filesystem, a directory is more or less a flat file that
>>>>>>> maps an arbitrary byte string (usually ASCII) to an inode number on
>>>>>>> the filesystem. There can be many directory entries across the
>>>>>>> filesystem that reference the same inode number--these are known as
>>>>>>> hard links, and that is why hard links cannot reference files on
>>>>>>> other filesystems. As such, directory entries are found by reading
>>>>>>> the data block(s) associated with a directory file for the
>>>>>>> particular directory entry that is desired.
>>>>>>>
>>>>>> Точно. Не хардлинки, а симлинки. Спасибо за замечание.
>>>>> В архиваторе репозиториев используется захардлинкивание симлинков
>>>>> для уменьшения количества используемых inode'ов.
>>>> Ух ты, это же здорово. А где посмотреть исходники ?
>>>>
>>>> в girar я сходу это не увидел.
>>> git grep GA_SYMLINK_DIR.
>>>
>>> В ext4 есть ограничение на количество хардлинков, которе может быть
>>> у симлинка, я постарался это учесть.
>>>
>> Класс. Спасибо.
>>
>> т.е. - моё предположение про inodes ошибочно и мы здесь не упрёмся. Т.е.
>> - в принципе ничего экстраординарного в большом росте количества заданий
>> за счёт роботов нет и архиватор это должен переварить (если опять, же
>> учитывать время на создание копии архива на файловой системе, которое
>> скорее всего не параллелится и упрётся просто в IO).
>>
>> Я ведь правильно понял Игоря, что он хочет сборочницу, которая будет
>> пропускать десятки тысяч сборочных заданий в день ?
>>
>> Представляю, какой адской задачей выглядит скопировать этот архив на
>> соседний сервер...
>>
>> А нет ли внутри всей этой машинерии где-то хранилища, в котором собраны
>> все бинарные и исходные rpm пакеты за всю историю с именем, равным
>> какому-то хешу этого пакета ?
>>
>> Что бы можно было скачать только его, а дальше раскрутить весь архив
>> скриптами по метаинформации из сборочных заданий.
> Да, есть, называется depot.
>
>
Отлично, а он как-то доступен снаружи ?

Re: [devel] архивирование репозиториев

[Dmitry V. Levin]

On Thu, Aug 27, 2020 at 09:26:00PM +0300, Anton Farygin wrote:
> On 27.08.2020 18:59, Dmitry V. Levin wrote:
> > On Thu, Aug 27, 2020 at 03:32:53PM +0300, Anton Farygin wrote:
> >> On 27.08.2020 15:20, Dmitry V. Levin wrote:
> >>> On Thu, Aug 27, 2020 at 03:14:27PM +0300, Anton Farygin wrote:
> >>>> On 27.08.2020 15:09, Dmitry V. Levin wrote:
> >>>>> On Thu, Aug 27, 2020 at 02:59:22PM +0300, Anton Farygin wrote:
> >>>>>> On 27.08.2020 14:54, Andrey Savchenko wrote:
> >>>>>>> On Thu, 27 Aug 2020 10:27:11 +0300 Anton Farygin wrote:
> >>>>>>> [...]
> >>>>>>>> Т.е. - для экономии места старые пакеты хардлинкаются в новое место и в
> >>>>>>>> него уже добавляются изменения из сборочного задания. Очень простая и
> >>>>>>>> очень надёжная схема, при которой риск потери данных минимален и всегда
> >>>>>>>> можно взять консистентное состояние репозитория за любой момент времени.
> >>>>>>>>
> >>>>>>>> Живёт это всё сейчас, вроде как, на ext4 (я могу ошибаться).
> >>>>>>>> Максимальное количество inodes у ext4 2^32 - 4,294,967,295
> >>>>>>>>
> >>>>>>>> Каждый новый таск в репозиторий приводит к тому, что на файловой системе
> >>>>>>>> появляется около 160 тысяч (а может быть и больше, я давно не смотрел
> >>>>>>>> цифры) новых записей.
> >>>>>>>>
> >>>>>>>> Т.е. - условно мы можем записать около 26 тысяч сборочных заданий в
> >>>>>>>> архив, а после этого из него придётся удалять что-то старое для того,
> >>>>>>>> что бы записать что-то новое.
> >>>>>>> Это полная чушь, поскольку все жесткие ссылки на файл используют
> >>>>>>> один и тот же inode:
> >>>>>>>
> >>>>>>> https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Directory_Entries
> >>>>>>>
> >>>>>>> In an ext4 filesystem, a directory is more or less a flat file that
> >>>>>>> maps an arbitrary byte string (usually ASCII) to an inode number on
> >>>>>>> the filesystem. There can be many directory entries across the
> >>>>>>> filesystem that reference the same inode number--these are known as
> >>>>>>> hard links, and that is why hard links cannot reference files on
> >>>>>>> other filesystems. As such, directory entries are found by reading
> >>>>>>> the data block(s) associated with a directory file for the
> >>>>>>> particular directory entry that is desired.
> >>>>>>>
> >>>>>> Точно. Не хардлинки, а симлинки. Спасибо за замечание.
> >>>>> В архиваторе репозиториев используется захардлинкивание симлинков
> >>>>> для уменьшения количества используемых inode'ов.
> >>>> Ух ты, это же здорово. А где посмотреть исходники ?
> >>>>
> >>>> в girar я сходу это не увидел.
> >>> git grep GA_SYMLINK_DIR.
> >>>
> >>> В ext4 есть ограничение на количество хардлинков, которе может быть
> >>> у симлинка, я постарался это учесть.
> >>>
> >> Класс. Спасибо.
> >>
> >> т.е. - моё предположение про inodes ошибочно и мы здесь не упрёмся. Т.е.
> >> - в принципе ничего экстраординарного в большом росте количества заданий
> >> за счёт роботов нет и архиватор это должен переварить (если опять, же
> >> учитывать время на создание копии архива на файловой системе, которое
> >> скорее всего не параллелится и упрётся просто в IO).
> >>
> >> Я ведь правильно понял Игоря, что он хочет сборочницу, которая будет
> >> пропускать десятки тысяч сборочных заданий в день ?
> >>
> >> Представляю, какой адской задачей выглядит скопировать этот архив на
> >> соседний сервер...
> >>
> >> А нет ли внутри всей этой машинерии где-то хранилища, в котором собраны
> >> все бинарные и исходные rpm пакеты за всю историю с именем, равным
> >> какому-то хешу этого пакета ?
> >>
> >> Что бы можно было скачать только его, а дальше раскрутить весь архив
> >> скриптами по метаинформации из сборочных заданий.
> > Да, есть, называется depot.
> >
> Отлично, а он как-то доступен снаружи ?

Сейчас только во внутренней сети, но технически препятствий раздать наружу
нет.


-- 
ldv

Re: [devel] архивирование репозиториев

[Alexey V. Vissarionov]

On 2020-08-27 23:29:15 +0300, Dmitry V. Levin wrote:

 >>>> А нет ли внутри всей этой машинерии где-то хранилища, в
 >>>> котором собраны все бинарные и исходные rpm пакеты за всю
 >>>> историю с именем, равным какому-то хешу этого пакета ?
 >>>> Что бы можно было скачать только его, а дальше раскрутить
 >>>> весь архив скриптами по метаинформации из сборочных заданий.
 >>> Да, есть, называется depot.
 >> Отлично, а он как-то доступен снаружи ?
 > Сейчас только во внутренней сети, но технически препятствий
 > раздать наружу нет.

1. Сколько места оно занимает?
2. rsync откуда?


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] архивирование репозиториев

[Anton Farygin]

On 27.08.2020 23:29, Dmitry V. Levin wrote:
> On Thu, Aug 27, 2020 at 09:26:00PM +0300, Anton Farygin wrote:
>> On 27.08.2020 18:59, Dmitry V. Levin wrote:
>>> On Thu, Aug 27, 2020 at 03:32:53PM +0300, Anton Farygin wrote:
>>>> On 27.08.2020 15:20, Dmitry V. Levin wrote:
>>>>> On Thu, Aug 27, 2020 at 03:14:27PM +0300, Anton Farygin wrote:
>>>>>> On 27.08.2020 15:09, Dmitry V. Levin wrote:
>>>>>>> On Thu, Aug 27, 2020 at 02:59:22PM +0300, Anton Farygin wrote:
>>>>>>>> On 27.08.2020 14:54, Andrey Savchenko wrote:
>>>>>>>>> On Thu, 27 Aug 2020 10:27:11 +0300 Anton Farygin wrote:
>>>>>>>>> [...]
>>>>>>>>>> Т.е. - для экономии места старые пакеты хардлинкаются в новое место и в
>>>>>>>>>> него уже добавляются изменения из сборочного задания. Очень простая и
>>>>>>>>>> очень надёжная схема, при которой риск потери данных минимален и всегда
>>>>>>>>>> можно взять консистентное состояние репозитория за любой момент времени.
>>>>>>>>>>
>>>>>>>>>> Живёт это всё сейчас, вроде как, на ext4 (я могу ошибаться).
>>>>>>>>>> Максимальное количество inodes у ext4 2^32 - 4,294,967,295
>>>>>>>>>>
>>>>>>>>>> Каждый новый таск в репозиторий приводит к тому, что на файловой системе
>>>>>>>>>> появляется около 160 тысяч (а может быть и больше, я давно не смотрел
>>>>>>>>>> цифры) новых записей.
>>>>>>>>>>
>>>>>>>>>> Т.е. - условно мы можем записать около 26 тысяч сборочных заданий в
>>>>>>>>>> архив, а после этого из него придётся удалять что-то старое для того,
>>>>>>>>>> что бы записать что-то новое.
>>>>>>>>> Это полная чушь, поскольку все жесткие ссылки на файл используют
>>>>>>>>> один и тот же inode:
>>>>>>>>>
>>>>>>>>> https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Directory_Entries
>>>>>>>>>
>>>>>>>>> In an ext4 filesystem, a directory is more or less a flat file that
>>>>>>>>> maps an arbitrary byte string (usually ASCII) to an inode number on
>>>>>>>>> the filesystem. There can be many directory entries across the
>>>>>>>>> filesystem that reference the same inode number--these are known as
>>>>>>>>> hard links, and that is why hard links cannot reference files on
>>>>>>>>> other filesystems. As such, directory entries are found by reading
>>>>>>>>> the data block(s) associated with a directory file for the
>>>>>>>>> particular directory entry that is desired.
>>>>>>>>>
>>>>>>>> Точно. Не хардлинки, а симлинки. Спасибо за замечание.
>>>>>>> В архиваторе репозиториев используется захардлинкивание симлинков
>>>>>>> для уменьшения количества используемых inode'ов.
>>>>>> Ух ты, это же здорово. А где посмотреть исходники ?
>>>>>>
>>>>>> в girar я сходу это не увидел.
>>>>> git grep GA_SYMLINK_DIR.
>>>>>
>>>>> В ext4 есть ограничение на количество хардлинков, которе может быть
>>>>> у симлинка, я постарался это учесть.
>>>>>
>>>> Класс. Спасибо.
>>>>
>>>> т.е. - моё предположение про inodes ошибочно и мы здесь не упрёмся. Т.е.
>>>> - в принципе ничего экстраординарного в большом росте количества заданий
>>>> за счёт роботов нет и архиватор это должен переварить (если опять, же
>>>> учитывать время на создание копии архива на файловой системе, которое
>>>> скорее всего не параллелится и упрётся просто в IO).
>>>>
>>>> Я ведь правильно понял Игоря, что он хочет сборочницу, которая будет
>>>> пропускать десятки тысяч сборочных заданий в день ?
>>>>
>>>> Представляю, какой адской задачей выглядит скопировать этот архив на
>>>> соседний сервер...
>>>>
>>>> А нет ли внутри всей этой машинерии где-то хранилища, в котором собраны
>>>> все бинарные и исходные rpm пакеты за всю историю с именем, равным
>>>> какому-то хешу этого пакета ?
>>>>
>>>> Что бы можно было скачать только его, а дальше раскрутить весь архив
>>>> скриптами по метаинформации из сборочных заданий.
>>> Да, есть, называется depot.
>>>
>> Отлично, а он как-то доступен снаружи ?
> Сейчас только во внутренней сети, но технически препятствий раздать наружу
> нет.

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

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

Re: [devel] архивирование репозиториев

[Michael Shigorin]

On Thu, Aug 27, 2020 at 03:32:53PM +0300, Anton Farygin wrote:
> Я ведь правильно понял Игоря, что он хочет сборочницу, которая
> будет пропускать десятки тысяч сборочных заданий в день ?
> Представляю, какой адской задачей выглядит скопировать этот
> архив на соседний сервер...

Насколько понимаю, именно отдельные задания (которые порождают
отдельные состояния репозитория) -- это обход неудобной работы
с большим заданием (мне при возне с питоном и qt5 показалось
даже, что время добавления подзаданий в большое задание где-то
к 50000 заметно на глаз растёт как бы не по экспоненте).

А когда читал письмо Игоря, то в месте насчёт мегаполиса вспомнил
рассказ Евгения Полякова на первом LinuxPiter о том, как "это"
решали в яндексе.  Вкратце -- с POSIX-совместимыми ФС далеко
не уехали, более-менее решать вопросы масштабирования получилось
на объектных хранилищах.

Возможно, стоит как-то так и разделять текущую работу, которая
имеет в целом ограниченный объём, и архив, который в идеале бы
хотелось иметь ограниченным только ёмкостью носителей.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] архивирование репозиториев

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2285 bytes --]

On Thu, 27 Aug 2020 20:31:11 +0300 Michael Shigorin wrote:
> On Thu, Aug 27, 2020 at 03:32:53PM +0300, Anton Farygin wrote:
> > Я ведь правильно понял Игоря, что он хочет сборочницу, которая
> > будет пропускать десятки тысяч сборочных заданий в день ?
> > Представляю, какой адской задачей выглядит скопировать этот
> > архив на соседний сервер...
> 
> Насколько понимаю, именно отдельные задания (которые порождают
> отдельные состояния репозитория) -- это обход неудобной работы
> с большим заданием (мне при возне с питоном и qt5 показалось
> даже, что время добавления подзаданий в большое задание где-то
> к 50000 заметно на глаз растёт как бы не по экспоненте).
> 
> А когда читал письмо Игоря, то в месте насчёт мегаполиса вспомнил
> рассказ Евгения Полякова на первом LinuxPiter о том, как "это"
> решали в яндексе.  Вкратце -- с POSIX-совместимыми ФС далеко
> не уехали, более-менее решать вопросы масштабирования получилось
> на объектных хранилищах.
> 
> Возможно, стоит как-то так и разделять текущую работу, которая
> имеет в целом ограниченный объём, и архив, который в идеале бы
> хотелось иметь ограниченным только ёмкостью носителей.

Так у нас архив и так вынесен на отдельную машину, разве нет?

Как раз 10 дней Дима «скрипты на C» писал для переноса, когда
сборочнице поплохело от нехватки места.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] архивирование репозиториев

[Dmitry V. Levin]

On Thu, Aug 27, 2020 at 08:51:15PM +0300, Andrey Savchenko wrote:
> On Thu, 27 Aug 2020 20:31:11 +0300 Michael Shigorin wrote:
[...]
> > Возможно, стоит как-то так и разделять текущую работу, которая
> > имеет в целом ограниченный объём, и архив, который в идеале бы
> > хотелось иметь ограниченным только ёмкостью носителей.
> 
> Так у нас архив и так вынесен на отдельную машину, разве нет?
> 
> Как раз 10 дней Дима «скрипты на C» писал для переноса, когда
> сборочнице поплохело от нехватки места.

Да, почти всё так (на «скрипты на C» ушло меньше 10 дней, но понадобились
и обычные скрипты написать, чтобы оно дальше работало по новой схеме).


-- 
ldv

Re: [devel] архивирование репозиториев

[Dmitry V. Levin]

On Thu, Aug 27, 2020 at 03:32:53PM +0300, Anton Farygin wrote:
[...]
> т.е. - моё предположение про inodes ошибочно и мы здесь не упрёмся. Т.е. 
> - в принципе ничего экстраординарного в большом росте количества заданий 
> за счёт роботов нет и архиватор это должен переварить (если опять, же 
> учитывать время на создание копии архива на файловой системе, которое 
> скорее всего не параллелится и упрётся просто в IO).
> 
> Я ведь правильно понял Игоря, что он хочет сборочницу, которая будет 
> пропускать десятки тысяч сборочных заданий в день ?

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

Для того, чтобы коммитить условные 17662 задания в сутки, среднее время
на коммит задания должно быть менее 5 секунд.  Сейчас самое быстрое
время, которое уходит на коммит задания - это примерно 30 секунд,
а на коммит более развесистых заданий уходит более 10 минут, см. напр.
лог коммита kernel-image-un-def-5.7.19-alt1 с модулями в
http://git.altlinux.org/tasks/archive/done/_250/256866/logs/events.1.3.log

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


-- 
ldv

Re: [devel] архивирование репозиториев

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 3170 bytes --]

On Fri, 28 Aug 2020 04:28:58 +0300 Dmitry V. Levin wrote:
> On Thu, Aug 27, 2020 at 03:32:53PM +0300, Anton Farygin wrote:
> [...]
> > т.е. - моё предположение про inodes ошибочно и мы здесь не упрёмся. Т.е. 
> > - в принципе ничего экстраординарного в большом росте количества заданий 
> > за счёт роботов нет и архиватор это должен переварить (если опять, же 
> > учитывать время на создание копии архива на файловой системе, которое 
> > скорее всего не параллелится и упрётся просто в IO).
> > 
> > Я ведь правильно понял Игоря, что он хочет сборочницу, которая будет 
> > пропускать десятки тысяч сборочных заданий в день ?
> 
> Сейчас в Сизифе 17662 исходных пакетов, десятки тысяч сборочных заданий
> в сутки означает, что в сутки каждый пакет обновляется в среднем чаще
> одного раза.  Не вижу, какими рациональными причинами могла бы быть
> вызвана такая интенсивность обновления пакетов.
> 
> Для того, чтобы коммитить условные 17662 задания в сутки, среднее время
> на коммит задания должно быть менее 5 секунд.  Сейчас самое быстрое
> время, которое уходит на коммит задания - это примерно 30 секунд,
> а на коммит более развесистых заданий уходит более 10 минут, см. напр.
> лог коммита kernel-image-un-def-5.7.19-alt1 с модулями в
> http://git.altlinux.org/tasks/archive/done/_250/256866/logs/events.1.3.log
> 
> С переездом на более быстрые диски коммит заданий, конечно, заметно
> ускорится, но вряд ли настолько, чтобы коммитить условные 17662 задания
> в сутки.  Опять же не надо забывать про архивацию заданий, там обычная
> скорость записи на обычные диски, и за такими темпами обновления
> репозитория архивация вряд ли угонится.

У нас узким местом часто является не сама сборка пакета, а проверки
и иные действия сборочницы: поиск req/prov, sisyphus_check,
install_check и т.д. и т.п.. Они все (или почти все?)
последовательные и хорошо бы было это реорганизовать.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] архивирование репозиториев

[Leonid Krivoshein]

28.08.2020 9:29, Andrey Savchenko пишет:
> [...]
> У нас узким местом часто является не сама сборка пакета, а проверки
> и иные действия сборочницы: поиск req/prov, sisyphus_check,
> install_check и т.д. и т.п.. Они все (или почти все?)
> последовательные и хорошо бы было это реорганизовать.

Для начала пересмотреть совсем очевидные вещи. Например, тест 
наследования, выполняемый после сборки развесистого пакета, типа 
chromium-gost, хорошо бы сделать ещё и до начала сборки.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] архивирование репозиториев

[Leonid Krivoshein]

27.08.2020 15:20, Dmitry V. Levin пишет:
> On Thu, Aug 27, 2020 at 03:14:27PM +0300, Anton Farygin wrote:
>> On 27.08.2020 15:09, Dmitry V. Levin wrote:
>>> On Thu, Aug 27, 2020 at 02:59:22PM +0300, Anton Farygin wrote:
>>>> On 27.08.2020 14:54, Andrey Savchenko wrote:
>>>>> On Thu, 27 Aug 2020 10:27:11 +0300 Anton Farygin wrote:
>>>>> [...]
>>>>>> Т.е. - для экономии места старые пакеты хардлинкаются в новое место и в
>>>>>> него уже добавляются изменения из сборочного задания. Очень простая и
>>>>>> очень надёжная схема, при которой риск потери данных минимален и всегда
>>>>>> можно взять консистентное состояние репозитория за любой момент времени.
>>>>>>
>>>>>> Живёт это всё сейчас, вроде как, на ext4 (я могу ошибаться).
>>>>>> Максимальное количество inodes у ext4 2^32 - 4,294,967,295
>>>>>>
>>>>>> Каждый новый таск в репозиторий приводит к тому, что на файловой системе
>>>>>> появляется около 160 тысяч (а может быть и больше, я давно не смотрел
>>>>>> цифры) новых записей.
>>>>>>
>>>>>> Т.е. - условно мы можем записать около 26 тысяч сборочных заданий в
>>>>>> архив, а после этого из него придётся удалять что-то старое для того,
>>>>>> что бы записать что-то новое.
>>>>> Это полная чушь, поскольку все жесткие ссылки на файл используют
>>>>> один и тот же inode:
>>>>>
>>>>> https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Directory_Entries
>>>>>
>>>>> In an ext4 filesystem, a directory is more or less a flat file that
>>>>> maps an arbitrary byte string (usually ASCII) to an inode number on
>>>>> the filesystem. There can be many directory entries across the
>>>>> filesystem that reference the same inode number--these are known as
>>>>> hard links, and that is why hard links cannot reference files on
>>>>> other filesystems. As such, directory entries are found by reading
>>>>> the data block(s) associated with a directory file for the
>>>>> particular directory entry that is desired.
>>>>>
>>>> Точно. Не хардлинки, а симлинки. Спасибо за замечание.
>>> В архиваторе репозиториев используется захардлинкивание симлинков
>>> для уменьшения количества используемых inode'ов.
>> Ух ты, это же здорово. А где посмотреть исходники ?
>>
>> в girar я сходу это не увидел.
> git grep GA_SYMLINK_DIR.
>
> В ext4 есть ограничение на количество хардлинков, которе может быть
> у симлинка, я постарался это учесть.

rm -rf ... всё же очень дорогая операция на изначально не 64-бит ФС.
В этом плане jfs рвёт её на части. Может, есть смысл бега для этих фс?


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] архивирование репозиториев

[Dmitry V. Levin]

On Fri, Aug 28, 2020 at 03:58:01AM +0300, Leonid Krivoshein wrote:
[...]
> rm -rf ... всё же очень дорогая операция на изначально не 64-бит ФС.

Непонятно, при чём тут 64-битность.

> В этом плане jfs рвёт её на части. Может, есть смысл бега для этих фс?

В архиве, где традиционные жесткие диски, rm -rf -- это редкая операция.
В сборочнице, которая коммитит задания, просто будут гораздо более быстрые
диски, и эта проблема уйдёт.

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


-- 
ldv

Re: [devel] архивирование репозиториев

[Leonid Krivoshein]

28.08.2020 4:11, Dmitry V. Levin пишет:
> On Fri, Aug 28, 2020 at 03:58:01AM +0300, Leonid Krivoshein wrote:
> [...]
>> rm -rf ... всё же очень дорогая операция на изначально не 64-бит ФС.
> Непонятно, при чём тут 64-битность.

Имею ввиду, что extfs ею изначально не является, но сейчас ext4 работает 
фактически как 64-битная. То есть, она изначально не проектировалась для 
того, чтобы работать так, как она сейчас работает. У неё много кода "для 
поддержки штанов" старому. И структур на диске, частично дублирующих 
свои визави более старых версий. В противовес этому jfs была изначально 
спроектирована сразу "по взрослому" и поддерживается сейчас Линусом лично.


>> В этом плане jfs рвёт её на части. Может, есть смысл бега для этих фс?
> В архиве, где традиционные жесткие диски, rm -rf -- это редкая операция.
> В сборочнице, которая коммитит задания, просто будут гораздо более быстрые
> диски, и эта проблема уйдёт.

По моим наблюдениям на интенсивном в/в ext4 создаёт ощутимую нагрузку на 
CPU, в отличие от jfs. Имеет смысл устроить бега даже на быстрых SSD.


> Что касается других фс, то ext4 - это универсальная файловая система,
> наверняка есть более быстрые, осталось только выяснить, нет ли у них
> недостатков, препятствующих использованию на сборочнице.

Единственный известный мне недостаток jfs -- отсутствие квотирования. 
Семантику поддерживает, но реально никаких квот нет.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] архивирование репозиториев

[Anton Farygin]

On 28.08.2020 03:58, Leonid Krivoshein wrote:
>
>
> 27.08.2020 15:20, Dmitry V. Levin пишет:
>> On Thu, Aug 27, 2020 at 03:14:27PM +0300, Anton Farygin wrote:
>>> On 27.08.2020 15:09, Dmitry V. Levin wrote:
>>>> On Thu, Aug 27, 2020 at 02:59:22PM +0300, Anton Farygin wrote:
>>>>> On 27.08.2020 14:54, Andrey Savchenko wrote:
>>>>>> On Thu, 27 Aug 2020 10:27:11 +0300 Anton Farygin wrote:
>>>>>> [...]
>>>>>>> Т.е. - для экономии места старые пакеты хардлинкаются в новое 
>>>>>>> место и в
>>>>>>> него уже добавляются изменения из сборочного задания. Очень 
>>>>>>> простая и
>>>>>>> очень надёжная схема, при которой риск потери данных минимален и 
>>>>>>> всегда
>>>>>>> можно взять консистентное состояние репозитория за любой момент 
>>>>>>> времени.
>>>>>>>
>>>>>>> Живёт это всё сейчас, вроде как, на ext4 (я могу ошибаться).
>>>>>>> Максимальное количество inodes у ext4 2^32 - 4,294,967,295
>>>>>>>
>>>>>>> Каждый новый таск в репозиторий приводит к тому, что на файловой 
>>>>>>> системе
>>>>>>> появляется около 160 тысяч (а может быть и больше, я давно не 
>>>>>>> смотрел
>>>>>>> цифры) новых записей.
>>>>>>>
>>>>>>> Т.е. - условно мы можем записать около 26 тысяч сборочных заданий в
>>>>>>> архив, а после этого из него придётся удалять что-то старое для 
>>>>>>> того,
>>>>>>> что бы записать что-то новое.
>>>>>> Это полная чушь, поскольку все жесткие ссылки на файл используют
>>>>>> один и тот же inode:
>>>>>>
>>>>>> https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Directory_Entries 
>>>>>>
>>>>>>
>>>>>> In an ext4 filesystem, a directory is more or less a flat file that
>>>>>> maps an arbitrary byte string (usually ASCII) to an inode number on
>>>>>> the filesystem. There can be many directory entries across the
>>>>>> filesystem that reference the same inode number--these are known as
>>>>>> hard links, and that is why hard links cannot reference files on
>>>>>> other filesystems. As such, directory entries are found by reading
>>>>>> the data block(s) associated with a directory file for the
>>>>>> particular directory entry that is desired.
>>>>>>
>>>>> Точно. Не хардлинки, а симлинки. Спасибо за замечание.
>>>> В архиваторе репозиториев используется захардлинкивание симлинков
>>>> для уменьшения количества используемых inode'ов.
>>> Ух ты, это же здорово. А где посмотреть исходники ?
>>>
>>> в girar я сходу это не увидел.
>> git grep GA_SYMLINK_DIR.
>> о
>> В ext4 есть ограничение на количество хардлинков, которе может быть
>> у симлинка, я постарался это учесть.
>
> rm -rf ... всё же очень дорогая операция на изначально не 64-бит ФС.
> В этом плане jfs рвёт её на части. Может, есть смысл бега для этих фс?
>
>
Когда то давным давно я пробовал сделать зеркало архива на разных 
файловых системах.

jfs умерла первой

за ней с небольшим отрывом пошёл xfs

на третьем месте оказался btrfs

на втором пришёл zfs

ext4 была быстрее всех.


Тест был очень простой - заливались архивы (правда, без хардлинков для 
симлинков) и время от времени на произвольном таске делался du -s

  zfs сейчас отлично справляется даже с включенным сжатием.

Re: [devel] архивирование репозиториев

[Leonid Krivoshein]

28.08.2020 8:03, Anton Farygin пишет:
> On 28.08.2020 03:58, Leonid Krivoshein wrote:
>> [...]
>> rm -rf ... всё же очень дорогая операция на изначально не 64-бит ФС.
>> В этом плане jfs рвёт её на части. Может, есть смысл бега для этих фс?
>>
>>
> Когда то давным давно я пробовал сделать зеркало архива на разных 
> файловых системах.
>
> jfs умерла первой
>
> за ней с небольшим отрывом пошёл xfs
>
> на третьем месте оказался btrfs
>
> на втором пришёл zfs
>
> ext4 была быстрее всех.
>
>
> Тест был очень простой - заливались архивы (правда, без хардлинков для 
> симлинков) и время от времени на произвольном таске делался du -s
>
>  zfs сейчас отлично справляется даже с включенным сжатием.
>

А у меня противоположный экспериенс с jfs и zfs. К счастью, никто не 
умер.)) Но с zfs система иногда внезапно висла.

Что значит первой умерла? И как давно это было? О каких архивах речь? Об 
очень больших файлах?


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] архивирование репозиториев

[Anton Farygin]

On 29.08.2020 05:22, Leonid Krivoshein wrote:
>
> 28.08.2020 8:03, Anton Farygin пишет:
>> On 28.08.2020 03:58, Leonid Krivoshein wrote:
>>> [...]
>>> rm -rf ... всё же очень дорогая операция на изначально не 64-бит ФС.
>>> В этом плане jfs рвёт её на части. Может, есть смысл бега для этих фс?
>>>
>>>
>> Когда то давным давно я пробовал сделать зеркало архива на разных 
>> файловых системах.
>>
>> jfs умерла первой
>>
>> за ней с небольшим отрывом пошёл xfs
>>
>> на третьем месте оказался btrfs
>>
>> на втором пришёл zfs
>>
>> ext4 была быстрее всех.
>>
>>
>> Тест был очень простой - заливались архивы (правда, без хардлинков 
>> для симлинков) и время от времени на произвольном таске делался du -s
>>
>>  zfs сейчас отлично справляется даже с включенным сжатием.
>>
>
> А у меня противоположный экспериенс с jfs и zfs. К счастью, никто не 
> умер.)) Но с zfs система иногда внезапно висла.
>
> Что значит первой умерла? И как давно это было? О каких архивах речь? 
> Об очень больших файлах?
>
>
Год назад, на jfs залили порядка 100 миллионов файлов, хардлинков и 
симлинков.

с zfs вообще проблем нет.

Кстати, смотреть на ней начали после твоего совета.

Re: [devel] архивирование репозиториев

[Leonid Krivoshein]

29.08.2020 7:58, Anton Farygin пишет:
> On 29.08.2020 05:22, Leonid Krivoshein wrote:
>>
>> 28.08.2020 8:03, Anton Farygin пишет:
>>> On 28.08.2020 03:58, Leonid Krivoshein wrote:
>>>> [...]
>>>> rm -rf ... всё же очень дорогая операция на изначально не 64-бит ФС.
>>>> В этом плане jfs рвёт её на части. Может, есть смысл бега для этих фс?
>>>>
>>>>
>>> Когда то давным давно я пробовал сделать зеркало архива на разных 
>>> файловых системах.
>>>
>>> jfs умерла первой
>>>
>>> за ней с небольшим отрывом пошёл xfs
>>>
>>> на третьем месте оказался btrfs
>>>
>>> на втором пришёл zfs
>>>
>>> ext4 была быстрее всех.
>>>
>>>
>>> Тест был очень простой - заливались архивы (правда, без хардлинков 
>>> для симлинков) и время от времени на произвольном таске делался du -s
>>>
>>>  zfs сейчас отлично справляется даже с включенным сжатием.
>>>
>>
>> А у меня противоположный экспериенс с jfs и zfs. К счастью, никто не 
>> умер.)) Но с zfs система иногда внезапно висла.
>>
>> Что значит первой умерла? И как давно это было? О каких архивах речь? 
>> Об очень больших файлах?
>>
> Год назад, на jfs залили порядка 100 миллионов файлов, хардлинков и 
> симлинков.
>
> с zfs вообще проблем нет.
>
> Кстати, смотреть на ней начали после твоего совета.

У меня было старое медленное железо, файлов было на пару порядков 
меньше, и было это несколько лет назад на ядрах 2.6~3.14. Хардлинки для 
rsync --link-dest я использовал интенсивно, тут заметно проявлялось 
преимущество jfs, связанное с динамическим выделением inod'ов под 
элементы каталога, поскольку изменения содержимого файлов были 
незначительные. Последние три года, на Альте, не использовал. Так что 
жаль, если так. Но важно, как это всё проверялось, был ли там 
out-of-tree код чего-то ещё, типа zfs, итд.

Независимо от того, будет ext4 или jfs на сборочнице, было бы хорошо 
поставить NVRAM с батарейкой и вынести журнал на неё.

Вообще, ни на одной другой файловой системе rm -rf так сильно не 
тормозит. А если через md или drbd, это вообще мегатормоз, когда речь 
даже о нескольких сотнях тысяч файлов.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] архивирование репозиториев

[Anton Farygin]

On 29.08.2020 17:18, Leonid Krivoshein wrote:
>
> 29.08.2020 7:58, Anton Farygin пишет:
>> On 29.08.2020 05:22, Leonid Krivoshein wrote:
>>>
>>> 28.08.2020 8:03, Anton Farygin пишет:
>>>> On 28.08.2020 03:58, Leonid Krivoshein wrote:
>>>>> [...]
>>>>> rm -rf ... всё же очень дорогая операция на изначально не 64-бит ФС.
>>>>> В этом плане jfs рвёт её на части. Может, есть смысл бега для этих 
>>>>> фс?
>>>>>
>>>>>
>>>> Когда то давным давно я пробовал сделать зеркало архива на разных 
>>>> файловых системах.
>>>>
>>>> jfs умерла первой
>>>>
>>>> за ней с небольшим отрывом пошёл xfs
>>>>
>>>> на третьем месте оказался btrfs
>>>>
>>>> на втором пришёл zfs
>>>>
>>>> ext4 была быстрее всех.
>>>>
>>>>
>>>> Тест был очень простой - заливались архивы (правда, без хардлинков 
>>>> для симлинков) и время от времени на произвольном таске делался du -s
>>>>
>>>>  zfs сейчас отлично справляется даже с включенным сжатием.
>>>>
>>>
>>> А у меня противоположный экспериенс с jfs и zfs. К счастью, никто не 
>>> умер.)) Но с zfs система иногда внезапно висла.
>>>
>>> Что значит первой умерла? И как давно это было? О каких архивах 
>>> речь? Об очень больших файлах?
>>>
>> Год назад, на jfs залили порядка 100 миллионов файлов, хардлинков и 
>> симлинков.
>>
>> с zfs вообще проблем нет.
>>
>> Кстати, смотреть на ней начали после твоего совета.
>
> У меня было старое медленное железо, файлов было на пару порядков 
> меньше, и было это несколько лет назад на ядрах 2.6~3.14. Хардлинки 
> для rsync --link-dest я использовал интенсивно, тут заметно 
> проявлялось преимущество jfs, связанное с динамическим выделением 
> inod'ов под элементы каталога, поскольку изменения содержимого файлов 
> были незначительные. Последние три года, на Альте, не использовал. Так 
> что жаль, если так. Но важно, как это всё проверялось, был ли там 
> out-of-tree код чего-то ещё, типа zfs, итд.
>
> Независимо от того, будет ext4 или jfs на сборочнице, было бы хорошо 
> поставить NVRAM с батарейкой и вынести журнал на неё.
>
> Вообще, ни на одной другой файловой системе rm -rf так сильно не 
> тормозит. А если через md или drbd, это вообще мегатормоз, когда речь 
> даже о нескольких сотнях тысяч файлов.
>
>
ну в данном случае rm -rf и не нужен, и даже скорее вреден.

[devel] zfs Re: архивирование репозиториев

[Vitaly Chikunov]

On Sat, Aug 29, 2020 at 07:58:55AM +0300, Anton Farygin wrote:
> с zfs вообще проблем нет.

ZFS сейчас используется для локального бакапа и бакапа архива в
московском офисе. Единственная проблема, что даже с большим кол-вом
памяти и cache и jil на быстром SSD, не удалось получить большую
скорость работы.

Re: [devel] zfs Re: архивирование репозиториев

[Anton Farygin]

On 29.08.2020 22:28, Vitaly Chikunov wrote:
> On Sat, Aug 29, 2020 at 07:58:55AM +0300, Anton Farygin wrote:
>> с zfs вообще проблем нет.
> ZFS сейчас используется для локального бакапа и бакапа архива в
> московском офисе. Единственная проблема, что даже с большим кол-вом
> памяти и cache и jil на быстром SSD, не удалось получить большую
> скорость работы.
>
А как оценивается скорость работы ? Может быть оно у нас тоже тормозит, 
просто я этого не замечаю.

Re: [devel] zfs Re: архивирование репозиториев

[Vitaly Chikunov]

On Sat, Aug 29, 2020 at 11:11:56PM +0300, Anton Farygin wrote:
> On 29.08.2020 22:28, Vitaly Chikunov wrote:
> > On Sat, Aug 29, 2020 at 07:58:55AM +0300, Anton Farygin wrote:
> > > с zfs вообще проблем нет.
> > ZFS сейчас используется для локального бакапа и бакапа архива в
> > московском офисе. Единственная проблема, что даже с большим кол-вом
> > памяти и cache и jil на быстром SSD, не удалось получить большую
> > скорость работы.
> > 
> А как оценивается скорость работы ? Может быть оно у нас тоже тормозит,
> просто я этого не замечаю.

При копировании задания сначала скриптом делается хардлинкование с уже
существующими локально файлами, а потом rsync всего нового поверх этого.
Так вот, это иногда может занимать до 5 минут (для репозитория одного
задания). Пример из лога:

  2020-08-07 19:34:18 :: Fetch task 255891 (p8)
  2020-08-07 19:34:18 :: Sync /archive/tasks/done/_249/255891
  = pre-linking... 0 links created (in 0.0 seconds)
  + exec rsync -aSHz --delete --no-inc-recursive archive:/archive/tasks/done/_249/255891/ /home/archive/tasks/done/_249/255891/
    rsynced in 0.5 seconds
  2020-08-07 19:34:18 :: Sync /archive//repo/p8/task/_249/255891
  = pre-linking... 118812 links created (in 234.0 seconds)
  + exec rsync -aSHz --delete --no-inc-recursive archive:/archive/repo/p8/task/_249/255891/ /home/archive/repo/p8/task/_249/255891/
    rsynced in 26.5 seconds
  2020-08-07 19:38:39 :: Fetch task 255900 (p9) [66%]

В среднем конечно бывает быстрее:

  = pre-linking... 200614 links created (in 29.6 seconds)
  = pre-linking... 190803 links created (in 36.0 seconds)
  = pre-linking... 200533 links created (in 32.2 seconds)
  = pre-linking... 118858 links created (in 241.8 seconds)
  = pre-linking... 200511 links created (in 32.1 seconds)
  = pre-linking... 190932 links created (in 28.6 seconds)
  = pre-linking... 200526 links created (in 34.9 seconds)
  = pre-linking... 118816 links created (in 18.2 seconds)
  = pre-linking... 190883 links created (in 47.6 seconds)
  = pre-linking... 191003 links created (in 27.2 seconds)
  = pre-linking... 190984 links created (in 27.2 seconds)
  = pre-linking... 190988 links created (in 29.2 seconds)
  = pre-linking... 190993 links created (in 28.5 seconds)
  = pre-linking... 190990 links created (in 32.0 seconds)
  = pre-linking... 190799 links created (in 57.2 seconds)
  = pre-linking... 190946 links created (in 42.2 seconds)
  = pre-linking... 190885 links created (in 29.1 seconds)
  = pre-linking... 190913 links created (in 27.8 seconds)
  = pre-linking... 190900 links created (in 35.4 seconds)
  = pre-linking... 190989 links created (in 27.3 seconds)
  = pre-linking... 190907 links created (in 31.6 seconds)
  = pre-linking... 190980 links created (in 32.8 seconds)

Даже пол минуты-минута для 200К файлов это как-то много. Хотелось бы в
10 раз быстрее. (В это время включено использование ssh find для
определения номеров inode на удаленной стороне и локально их
преобразование в имена файлов через rocksdb. Как я помню, при
тестировании в основном время занимает 2 вызова stat() на zfs).

Re: [devel] zfs Re: архивирование репозиториев

[Anton Farygin]

On 29.08.2020 23:38, Vitaly Chikunov wrote:
> On Sat, Aug 29, 2020 at 11:11:56PM +0300, Anton Farygin wrote:
>> On 29.08.2020 22:28, Vitaly Chikunov wrote:
>>> On Sat, Aug 29, 2020 at 07:58:55AM +0300, Anton Farygin wrote:
>>>> с zfs вообще проблем нет.
>>> ZFS сейчас используется для локального бакапа и бакапа архива в
>>> московском офисе. Единственная проблема, что даже с большим кол-вом
>>> памяти и cache и jil на быстром SSD, не удалось получить большую
>>> скорость работы.
>>>
>> А как оценивается скорость работы ? Может быть оно у нас тоже тормозит,
>> просто я этого не замечаю.
> При копировании задания сначала скриптом делается хардлинкование с уже
> существующими локально файлами, а потом rsync всего нового поверх этого.
> Так вот, это иногда может занимать до 5 минут (для репозитория одного
> задания). Пример из лога:

Да, у нас примерно так же по скорости. Первый раз 40 секунд, второй - 
20. Но zfs живёт поверх ceph.

Что самое плохое - это самый быстрый результат из современных файловых 
систем. btrfs ещё медленнее.

Можно, наверное, посмотреть причину её тормозов, но скорее всего она 
кроется в архитектуре.

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

Re: [devel] zfs Re: архивирование репозиториев

[Alexey V. Vissarionov]

On 2020-08-30 00:12:09 +0300, Anton Farygin wrote:

 >>> А как оценивается скорость работы ? Может быть оно у нас тоже
 >>> тормозит, просто я этого не замечаю.
 >> При копировании задания сначала скриптом делается
 >> хардлинкование с уже существующими локально файлами, а потом
 >> rsync всего нового поверх этого. Так вот, это иногда может
 >> занимать до 5 минут (для репозитория одного задания).
 > Да, у нас примерно так же по скорости. Первый раз 40 секунд,
 > второй - 20. Но zfs живёт поверх ceph. Что самое плохое - это
 > самый быстрый результат из современных файловых систем.

В принципе, не особо удивительно.

 > btrfs ещё медленнее.

Оно еще и корявенькое...

 > Можно, наверное, посмотреть причину её тормозов, но скорее
 > всего она кроется в архитектуре.

Ага. Только не ФС, а хранилища в целом.

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

Дальше это время будет только расти. Экс-по-нен-ци-аль-но (голосом
ежика из мультика, ага).

Я бы в сторону шардинга подумал.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] incoming/girar: проблема производительности.

[Alexey V. Vissarionov]

On 2020-08-27 10:27:11 +0300, Anton Farygin wrote:

 > Что касается лично моего мнения по тому сборочному заданию
 > с perl - на мой взгляд, увеличение релиза в пакете для rebuild -
 > это нормальная практика и я не вижу в этом ничего плохого, скорее
 > даже наоборот - в этом есть некоторый смысл, т.к. (я про это уже
 > неоднократно писал) - в процессе rebuild пакет становится другим
 > и было бы неплохо научиться его отличать по имени файла, а не
 > только по его содержимому.

%version определяют разработчики, %release определяют мейнтейнеры
(и те, и другие - люди), а для роботов электрических есть DistTag -
иерархия вполне логичная, и ломать ее лучше не надо.

 > авторы фичи с DistTag обещали добавить что-то в имена файлов,
 > но пока это всё остановилось на обещаниях.

И очень плохо.

 > И ещё пару слов про автоматическую пересборку для мелких
 > исправлений пакетов: есть (не)маленькая проблема с тем, что
 > в результате такой пересборки может получится не просто
 > изменение тэга License, но и вообще другой пакет, с другим
 > содержимым и работающий иначе, чем до пересборки. Просто
 > потому, что необходимые ему для сборки пакеты меняются в тех
 > местах, в которых сборочница отследить эти изменения не может.

Да. И это вполне ожидаемое поведение (expected behavior).


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] incoming/girar: проблема производительности.

[Igor Vlasenko]

On Thu, Aug 27, 2020 at 10:27:11AM +0300, Anton Farygin wrote:
> > Не надо жалеть сборочницу, это робот, который работает за электроэнергию.
> 
> Я вот тоже чуть чуть сбоку пытаюсь пилить какую-то аналитику по сборочнице
> и, на самом деле, хочу сказать что большая пропускная способность сборочницы
> может вылезти боком в другом месте - в архиве.

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

Можно провести аналогию: допустим, к поселку вела скажем,
не проселочная, а дорога в стиле XIX века, мощеная щебнем
или булыжником. И вот вместо нее провели современную
автостраду. Бабушки в поселке могут переживать ---
"Будут теперь норкоманы ездить".
Но в первом приближении ничего особо не изменится,
кроме удобства -- "Кто ездил, тот и будет ездить,
а кто пешком ходил, тот и будет ходить".

__

I V

Re: [devel] incoming/girar: проблема производительности.

[Anton V. Boyarshinov]

В Fri, 28 Aug 2020 12:25:24 +0300
Igor Vlasenko <vlasenko@imath.kiev.ua> пишет:

> Можно провести аналогию: допустим, к поселку вела скажем,
> не проселочная, а дорога в стиле XIX века, мощеная щебнем
> или булыжником. И вот вместо нее провели современную
> автостраду. 

Если тупиковую автостраду к посёлку -- это огромные деньги на ветер.
Так что, хотя аналогии мало что показывают, данная -- показывает.
Чем строить автостраду с развязками, лучше бы сделали нормальную
двухполоску, а на сэкономленные деньги... тут длинный список....

Re: [devel] incoming/girar: проблема производительности.

[Igor Vlasenko]

On Fri, Aug 28, 2020 at 12:28:39PM +0300, Anton V. Boyarshinov wrote:
> В Fri, 28 Aug 2020 12:25:24 +0300
> Igor Vlasenko <vlasenko@imath.kiev.ua> пишет:
> 
> > Можно провести аналогию: допустим, к поселку вела скажем,
> > не проселочная, а дорога в стиле XIX века, мощеная щебнем
> > или булыжником. И вот вместо нее провели современную
> > автостраду. 
> 
> Если тупиковую автостраду к посёлку -- это огромные деньги на ветер.
> Так что, хотя аналогии мало что показывают, данная -- показывает.
> Чем строить автостраду с развязками, лучше бы сделали нормальную
> двухполоску, а на сэкономленные деньги... тут длинный список....

как раз имел в виду нормальную двухполоску...

-- 

I V

Re: [devel] incoming/girar: проблема производительности.

[Anton Farygin]

On 28.08.2020 12:25, Igor Vlasenko wrote:
> On Thu, Aug 27, 2020 at 10:27:11AM +0300, Anton Farygin wrote:
>>> Не надо жалеть сборочницу, это робот, который работает за электроэнергию.
>> Я вот тоже чуть чуть сбоку пытаюсь пилить какую-то аналитику по сборочнице
>> и, на самом деле, хочу сказать что большая пропускная способность сборочницы
>> может вылезти боком в другом месте - в архиве.
> большвя пропускная способность не означает, что сборочница
> будет тут же загружена. Просто ей пользоваться станет удобнее --
> меньше ждать.
>
> Можно провести аналогию: допустим, к поселку вела скажем,
> не проселочная, а дорога в стиле XIX века, мощеная щебнем
> или булыжником. И вот вместо нее провели современную
> автостраду. Бабушки в поселке могут переживать ---
> "Будут теперь норкоманы ездить".
> Но в первом приближении ничего особо не изменится,
> кроме удобства -- "Кто ездил, тот и будет ездить,
> а кто пешком ходил, тот и будет ходить".
>
> __

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

Но про меньше ждать я согласен - это конечно было бы отлично.

Re: [devel] incoming/girar: проблема производительности.

[Igor Vlasenko]

On Fri, Aug 28, 2020 at 12:34:58PM +0300, Anton Farygin wrote:
> Вот прямо недавно по этому поводу участвовал в дискуссии, основной посыл
> которой заключается в том, что если у вас небольшая деревня, то не надо
> строить в ней хайвей. Стройте узкие, но удобные дороги. Будет комфортнее
> жить.

Как я понимаю ситуацию - денег (железа) в сборочницу _УЖЕ_
вбухано на два хайвея, а пропускная способность
у нее -- как у лесной тропинки, из-за кривых 
алгоритмов в плане проивзводительности.

-- 

I V

Re: [devel] incoming/girar: проблема производительности.

[Michael Shigorin]

On Thu, Aug 27, 2020 at 05:29:53AM +0300, Igor Vlasenko wrote:
> Года 3 назад я написал ряд писем в devel@, которые описывали
> алгоритмы параллелизации работы сборочницы, которые позволили
> бы существенно (на порядки) повысить ее производительность.
> Содержимое этих писем доступно на
> https://www.altlinux.org/Girar/Parallel .

Игорь, спасибо, что наконец рассказал эту историю!
Мы уж действительно переживали -- что с тобой,
а предположить было не из чего.

2 rider: спасибо и за твой рассказ; про архив думал упомянуть,
         хорошо, что сперва прочёл и второе письмо.

> Дмитрий заинтересовался, но не совсем тем, чем хотелось,
> а вопросом, нельзя ли как-то уменьшить число релизов от моих
> роботов, что я в итоге сделал для импорта из федоры и магейи,
> и начал делать для java.

Немножко поправлю: Дима тогда возмутился тем, что на альт
начинают фактически оказывать прямое влияние политики выпуска
Fedora Project -- например, пересборка всего перед каждым
выпуском (осмысленность такого вообще и конкретно у нас --
отдельный интересный вопрос, который когда-то в ключе
(не)использования результатов тестовых пересборок поднимал
led@; но сейчас только сошлюсь на этот факт).

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

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

> Сейчас у меня, возможно, получится объяснить.

Ух! :)

> Но я после недели обсуждений с Дмитрием так и не смог пробить
> #36531 в апстрим hasher :(. В итоге форкнул свою копию hasher
> и свернул свою разработку прототипа локальной сборочницы. :(

Free software, каким мы его знаем и любим.

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

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

> Надо сказать, Дмитрий и раньше злоупотреблял своим положением
> администратора сборочницы, но когда речь шла об одиночных
> пакетах, то обычно была какая-то польза или хотя бы повод,
> а вреда от остановки task'а особого не было, одиночный пакет
> можно потом перезалить хоть через полгода, сделанная работа
> не пропадет зря.  В случае же с транзакциями все наоборот.

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

  Предлагаю такое правило: если Дима решает помочь с задачей,
  то есть настолько точно знает лучше, как её сделать, что
  вмешивается без вопросов -- значит, Дима берёт на себя
  ответственность за её решение или отмену.

> Эмоции в корректной форме можно было выразить анекдотом:

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

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

Если что -- пиши, позвоню, изложишь в любом виде.
Постараюсь перевести.

> Проблема была в том, что и Дмитрий действовал не со зла и не
> нарочно, но получилось по пословице "простота хуже воровства".

Дима, предлагаю ещё один приём.  Представь, что ты -- Путин,
а несколько процентов команды -- оппозиция.  Не те идиоты,
которые вообще не слушают и только орут "Левин, уходи",
а люди вроде тебя, в целом настроенные конструктивно,
но близко к сердцу принимающие твои ошибки, особенно
оформленные как вроде бы помощь.

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

> Вернемся к истокам. Сборочница рассчитана на условного майнтайнера
> с относительно малым числом но достаточно глубоко сопровождаемых
> пакетов, для которого производительность сборочницы не играет особой
> роли. Пример такого майнтайнера -- сам Дмитрий.
> Для него сборочница комфортна.
> 
> Со мной Дмитрий пытался оптимизировать майнтайнера к сборочнице,
> а я хотел наоборот. Что же мне мешает оптимизироваться?

Ну есть и оптимизация на производительность, но она сосредоточена
скорее в пересборочнице, результаты работы которой отбрасываются
(и это сильно другой инвариант).  И там цель не "как можно
быстрее", а "уложиться с пересборкой всего сизифа в одни сутки"
(здесь, возможно, ещё один заранее не очевидный тебе подводный
камень насчёт роста репозмитория).

> Мешает то, что его оптимизация майнтайнера к сборочнице
> сводится к экономии машинного времени сборочницы
> за счет растраты времени майнтайнера.

Это советский подход, да.

> Рассмотрим, к примеру, наше новое полиси по заполнению лицензий.

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

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

В общем, Дима, перевожу на русский без мата: у тебя уже МАЗ
бастует, причём именно в результате твоих действий (даже не
бездействия), зато без накачки из сопредельных проектов.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] mass rebuilds

[Dmitry V. Levin]

On Thu, Aug 27, 2020 at 12:17:34PM +0300, Michael Shigorin wrote:
[...]
> Немножко поправлю: Дима тогда возмутился тем, что на альт
> начинают фактически оказывать прямое влияние политики выпуска
> Fedora Project -- например, пересборка всего перед каждым
> выпуском

Это верная поправка.  Я тогда выборочно посмотрел, что изменилось
в десятке из сотни обновленных пакетов, и обнаружил, что ничего не
изменилось, кроме номера релиза и записи в %changelog'е.

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

> (осмысленность такого вообще и конкретно у нас --
> отдельный интересный вопрос, который когда-то в ключе
> (не)использования результатов тестовых пересборок поднимал
> led@; но сейчас только сошлюсь на этот факт).

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

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


-- 
ldv

Re: [devel] mass rebuilds

[Anton Farygin]

On 28.08.2020 03:23, Dmitry V. Levin wrote:
> On Thu, Aug 27, 2020 at 12:17:34PM +0300, Michael Shigorin wrote:
>> (осмысленность такого вообще и конкретно у нас --
>> отдельный интересный вопрос, который когда-то в ключе
>> (не)использования результатов тестовых пересборок поднимал
>> led@; но сейчас только сошлюсь на этот факт).
> Я думаю, что мы хотим коммитить такие пересобранные пакеты,
> которые в результате пересборки меняются значимым образом.
>
> Например, при смене мажорной версии gcc имеет смысл пересобрать
> и закоммитить то, что компилируется новой версией gcc.
>
>
Это отличная идея. Можно очень просто вычислить, какие пакеты и кому 
нужны для сборки. И при изменении пакета автоматически запускать 
пересборку всех зависимых с проверкой результата.

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

Re: [devel] mass rebuilds

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1676 bytes --]

On Fri, 28 Aug 2020 08:09:24 +0300 Anton Farygin wrote:
> On 28.08.2020 03:23, Dmitry V. Levin wrote:
> > On Thu, Aug 27, 2020 at 12:17:34PM +0300, Michael Shigorin wrote:
> >> (осмысленность такого вообще и конкретно у нас --
> >> отдельный интересный вопрос, который когда-то в ключе
> >> (не)использования результатов тестовых пересборок поднимал
> >> led@; но сейчас только сошлюсь на этот факт).
> > Я думаю, что мы хотим коммитить такие пересобранные пакеты,
> > которые в результате пересборки меняются значимым образом.
> >
> > Например, при смене мажорной версии gcc имеет смысл пересобрать
> > и закоммитить то, что компилируется новой версией gcc.
> >
> >
> Это отличная идея. Можно очень просто вычислить, какие пакеты и кому 
> нужны для сборки. 

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

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] mass rebuilds

[Anton Farygin]

On 28.08.2020 09:25, Andrey Savchenko wrote:
> On Fri, 28 Aug 2020 08:09:24 +0300 Anton Farygin wrote:
>> On 28.08.2020 03:23, Dmitry V. Levin wrote:
>>> On Thu, Aug 27, 2020 at 12:17:34PM +0300, Michael Shigorin wrote:
>>>> (осмысленность такого вообще и конкретно у нас --
>>>> отдельный интересный вопрос, который когда-то в ключе
>>>> (не)использования результатов тестовых пересборок поднимал
>>>> led@; но сейчас только сошлюсь на этот факт).
>>> Я думаю, что мы хотим коммитить такие пересобранные пакеты,
>>> которые в результате пересборки меняются значимым образом.
>>>
>>> Например, при смене мажорной версии gcc имеет смысл пересобрать
>>> и закоммитить то, что компилируется новой версией gcc.
>>>
>>>
>> Это отличная идея. Можно очень просто вычислить, какие пакеты и кому
>> нужны для сборки.
> Мы с Димой и коллегами обсуждали этот вопрос, когда мне нужен был
> инструмент для построения графа как сборочных, так и установочных
> зависимостей. Оказалось, что в общем случае это вычислить нельзя,
> хотя в большинстве случаев возможно.
>
А в каких случаях не получается вычислить ?

Ну кроме явных закольцованных зависимостей.

Re: [devel] mass rebuilds

[Dmitry V. Levin]

On Fri, Aug 28, 2020 at 09:58:36AM +0300, Anton Farygin wrote:
> On 28.08.2020 09:25, Andrey Savchenko wrote:
> > On Fri, 28 Aug 2020 08:09:24 +0300 Anton Farygin wrote:
> >> On 28.08.2020 03:23, Dmitry V. Levin wrote:
> >>> On Thu, Aug 27, 2020 at 12:17:34PM +0300, Michael Shigorin wrote:
> >>>> (осмысленность такого вообще и конкретно у нас --
> >>>> отдельный интересный вопрос, который когда-то в ключе
> >>>> (не)использования результатов тестовых пересборок поднимал
> >>>> led@; но сейчас только сошлюсь на этот факт).
> >>> Я думаю, что мы хотим коммитить такие пересобранные пакеты,
> >>> которые в результате пересборки меняются значимым образом.
> >>>
> >>> Например, при смене мажорной версии gcc имеет смысл пересобрать
> >>> и закоммитить то, что компилируется новой версией gcc.
> >>>
> >>>
> >> Это отличная идея. Можно очень просто вычислить, какие пакеты и кому
> >> нужны для сборки.
> > Мы с Димой и коллегами обсуждали этот вопрос, когда мне нужен был
> > инструмент для построения графа как сборочных, так и установочных
> > зависимостей. Оказалось, что в общем случае это вычислить нельзя,
> > хотя в большинстве случаев возможно.
> >
> А в каких случаях не получается вычислить ?

Ну а как бы ты предложил их вычислить?

> Ну кроме явных закольцованных зависимостей.

Закольцованные зависимости у нас, конечно, есть, но кольца можно
и разорвать.


-- 
ldv

Re: [devel] mass rebuilds

[Anton Farygin]

On 28.08.2020 19:46, Dmitry V. Levin wrote:
> On Fri, Aug 28, 2020 at 09:58:36AM +0300, Anton Farygin wrote:
>> On 28.08.2020 09:25, Andrey Savchenko wrote:
>>> On Fri, 28 Aug 2020 08:09:24 +0300 Anton Farygin wrote:
>>>> On 28.08.2020 03:23, Dmitry V. Levin wrote:
>>>>> On Thu, Aug 27, 2020 at 12:17:34PM +0300, Michael Shigorin wrote:
>>>>>> (осмысленность такого вообще и конкретно у нас --
>>>>>> отдельный интересный вопрос, который когда-то в ключе
>>>>>> (не)использования результатов тестовых пересборок поднимал
>>>>>> led@; но сейчас только сошлюсь на этот факт).
>>>>> Я думаю, что мы хотим коммитить такие пересобранные пакеты,
>>>>> которые в результате пересборки меняются значимым образом.
>>>>>
>>>>> Например, при смене мажорной версии gcc имеет смысл пересобрать
>>>>> и закоммитить то, что компилируется новой версией gcc.
>>>>>
>>>>>
>>>> Это отличная идея. Можно очень просто вычислить, какие пакеты и кому
>>>> нужны для сборки.
>>> Мы с Димой и коллегами обсуждали этот вопрос, когда мне нужен был
>>> инструмент для построения графа как сборочных, так и установочных
>>> зависимостей. Оказалось, что в общем случае это вычислить нельзя,
>>> хотя в большинстве случаев возможно.
>>>
>> А в каких случаях не получается вычислить ?
> Ну а как бы ты предложил их вычислить?

Пройтись по графу и подсчитать.

Вот попытка это сделать:
curl -s -k "https://repodb.basealt.space/what_depends_src?task=250722"|jq

Считает граф пакетов, которые по сборке и рантайм зависят от пакетов из 
задания 250722 и сортирует их в порядке пересборки.


>
>> Ну кроме явных закольцованных зависимостей.
> Закольцованные зависимости у нас, конечно, есть, но кольца можно
> и разорвать.

Мне вот это сделать как-то было сложно, в автоматическом режиме.

Re: [devel] mass rebuilds

[Dmitry V. Levin]

On Fri, Aug 28, 2020 at 11:23:00PM +0300, Anton Farygin wrote:
> On 28.08.2020 19:46, Dmitry V. Levin wrote:
> > On Fri, Aug 28, 2020 at 09:58:36AM +0300, Anton Farygin wrote:
> >> On 28.08.2020 09:25, Andrey Savchenko wrote:
> >>> On Fri, 28 Aug 2020 08:09:24 +0300 Anton Farygin wrote:
> >>>> On 28.08.2020 03:23, Dmitry V. Levin wrote:
> >>>>> On Thu, Aug 27, 2020 at 12:17:34PM +0300, Michael Shigorin wrote:
> >>>>>> (осмысленность такого вообще и конкретно у нас --
> >>>>>> отдельный интересный вопрос, который когда-то в ключе
> >>>>>> (не)использования результатов тестовых пересборок поднимал
> >>>>>> led@; но сейчас только сошлюсь на этот факт).
> >>>>> Я думаю, что мы хотим коммитить такие пересобранные пакеты,
> >>>>> которые в результате пересборки меняются значимым образом.
> >>>>>
> >>>>> Например, при смене мажорной версии gcc имеет смысл пересобрать
> >>>>> и закоммитить то, что компилируется новой версией gcc.
> >>>>>
> >>>> Это отличная идея. Можно очень просто вычислить, какие пакеты и кому
> >>>> нужны для сборки.
> >>> Мы с Димой и коллегами обсуждали этот вопрос, когда мне нужен был
> >>> инструмент для построения графа как сборочных, так и установочных
> >>> зависимостей. Оказалось, что в общем случае это вычислить нельзя,
> >>> хотя в большинстве случаев возможно.
> >>>
> >> А в каких случаях не получается вычислить ?
> > Ну а как бы ты предложил их вычислить?
> 
> Пройтись по графу и подсчитать.
> 
> Вот попытка это сделать:
> curl -s -k "https://repodb.basealt.space/what_depends_src?task=250722"|jq
> 
> Считает граф пакетов, которые по сборке и рантайм зависят от пакетов из 
> задания 250722 и сортирует их в порядке пересборки.

А как ты определяешь сборочные зависимости?


-- 
ldv

Re: [devel] mass rebuilds

[Anton Farygin]

On 29.08.2020 00:47, Dmitry V. Levin wrote:
> On Fri, Aug 28, 2020 at 11:23:00PM +0300, Anton Farygin wrote:
>> On 28.08.2020 19:46, Dmitry V. Levin wrote:
>>> On Fri, Aug 28, 2020 at 09:58:36AM +0300, Anton Farygin wrote:
>>>> On 28.08.2020 09:25, Andrey Savchenko wrote:
>>>>> On Fri, 28 Aug 2020 08:09:24 +0300 Anton Farygin wrote:
>>>>>> On 28.08.2020 03:23, Dmitry V. Levin wrote:
>>>>>>> On Thu, Aug 27, 2020 at 12:17:34PM +0300, Michael Shigorin wrote:
>>>>>>>> (осмысленность такого вообще и конкретно у нас --
>>>>>>>> отдельный интересный вопрос, который когда-то в ключе
>>>>>>>> (не)использования результатов тестовых пересборок поднимал
>>>>>>>> led@; но сейчас только сошлюсь на этот факт).
>>>>>>> Я думаю, что мы хотим коммитить такие пересобранные пакеты,
>>>>>>> которые в результате пересборки меняются значимым образом.
>>>>>>>
>>>>>>> Например, при смене мажорной версии gcc имеет смысл пересобрать
>>>>>>> и закоммитить то, что компилируется новой версией gcc.
>>>>>>>
>>>>>> Это отличная идея. Можно очень просто вычислить, какие пакеты и кому
>>>>>> нужны для сборки.
>>>>> Мы с Димой и коллегами обсуждали этот вопрос, когда мне нужен был
>>>>> инструмент для построения графа как сборочных, так и установочных
>>>>> зависимостей. Оказалось, что в общем случае это вычислить нельзя,
>>>>> хотя в большинстве случаев возможно.
>>>>>
>>>> А в каких случаях не получается вычислить ?
>>> Ну а как бы ты предложил их вычислить?
>> Пройтись по графу и подсчитать.
>>
>> Вот попытка это сделать:
>> curl -s -k "https://repodb.basealt.space/what_depends_src?task=250722"|jq
>>
>> Считает граф пакетов, которые по сборке и рантайм зависят от пакетов из
>> задания 250722 и сортирует их в порядке пересборки.
> А как ты определяешь сборочные зависимости?

Выбираю зависимости (исходных если интересна только сборка) пакетов, для 
которых есть provides у бинарных пакетов из задания. Это если просто. на 
самом деле там ещё учитывается глубина поиска, т.е. - можно рекурсивно 
уйти вглубь (параметр deep=<1,2,3>.

Но больше 3-х уже не успевает в лимит 30 секунд.

Re: [devel] incoming/girar: проблема производительности.

[Dmitry V. Levin]

On Thu, Aug 27, 2020 at 05:29:53AM +0300, Igor Vlasenko wrote:

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

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


-- 
ldv

Re: [devel] incoming/girar: проблема производительности.

[Dmitry V. Levin]

On Thu, Aug 27, 2020 at 12:57:10PM +0300, Dmitry V. Levin wrote:
> On Thu, Aug 27, 2020 at 05:29:53AM +0300, Igor Vlasenko wrote:
> 
> Игорь, это ваше письмо, судя по размеру и детализации - результат
> многомесячного труда, спасибо вам большое за этот труд.
> 
> Надеюсь, вы понимаете, что столь же глубокий и проработанный ответ
> на него объективно займёт примерно столько же времени у человека,
> который посвятит этому всё своё рабочее время.

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

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

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

festival-2.0.95-alt7 [44] (viy,msp,@everybody)
4ti2-1.6.9-alt1_4 [20] (viy,@everybody)
bookkeeper-4.3.2-alt1_7jpp8 [16] (viy,@everybody)
hadoop-2.7.6-alt4_5jpp8 [16] (viy,@everybody)
java-10-openjdk-0:10.0.2.13-alt1_7jpp9 [21] (viy,@everybody)
java-11-openjdk-0:11.0.3.7-alt1_5jpp8 [21] (viy,@everybody)
java-9-openjdk-0:9.0.4.11-alt3_6jpp8 [21] (viy,@everybody)
jss-4.6.2-alt2 [15] (viy,vitty,@everybody)
libhocr-0.10.17-alt4_30 [22] (viy,@everybody)
libwindowswm-1.0.1-alt1_8 [18] (viy,@everybody)
perl-Module-Manifest-Skip-0.23-alt1_15 [19] (viy,@everybody)
protostream-3.0.4-alt1_7jpp8 [16] (viy,@everybody)
rt-4.4.4-alt1_5 [20] (viy,@everybody)

Спасибо,


-- 
ldv

[devel] License Tag Policy (Re: incoming/girar: проблема =?utf-8?b?INC/0YDQvtC40LfQstC+0LTQuNGC0LXQu9GM0L3QvtGB0YLQuC4=?=)

[Sergey Afonin]

On Thursday 27 August 2020, Igor Vlasenko wrote:

> Рассмотрим, к примеру, наше новое полиси по заполнению
> лицензий. 
 
А где новое полиси? Обсуждения были, а по ссылке 
https://www.altlinux.org/License_Tag_Policy последняя
правка всё ещё 10 лет назад.

-- 
С уважением, Сергей Афонин.

Re: [devel] unmaintained packages shall not belong to Sisyphus

[Dmitry V. Levin]

On Thu, Aug 27, 2020 at 05:29:53AM +0300, Igor Vlasenko wrote:
> Дмитрий заинтересовался, но не совсем тем, чем хотелось,
> а вопросом, нельзя ли как-то уменьшить число релизов от моих роботов,
> что я в итоге сделал для импорта из федоры и магейи,

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

Я с самого начала исходил из того, что Sisyphus - это репозиторий пакетов,
у которых есть мантейнеры и пользователи.  Мантейнеры - это люди, которые
пользуются и сопровождают свои пакеты, см.
https://www.altlinux.org/Руководство_начинающего_мейнтейнера_ALT_Linux_Team
К мантейнерам обращаются другие пользователи, когда к пакетам, которые они
сопровождают, есть какие-то вопросы.

Поскольку мантейнеры - это люди, то у них есть естественный предел того
количества пакетов, которые они могут поддерживать.  Мантейнер, который
хотя бы примерно понимает, что поменялось в новой сборке своего пакета,
вряд ли может качественно поддерживать более 200..300 пакетов.  Если у
кого-то в сопровождении находятся 3500+ пакетов, это значит, что среди них
найдётся не более 5%..10% пакетов, которые реально поддерживаются, по
которым можно задать вопросы и получить вразумительные ответы, повесить
багрепорты и получить адекватную реакцию на них.  Остальные 90%..95%
пакетов полностью мантейнят скрипты, и спрос с них соответствующий,
т.е. никакой.  По этим 90%..95% пакетов практически нет экспертизы.

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

Смешивать в одном репозитории пакеты, которые поддерживаются, и которые
полностью сопровождаются скриптами - это плохая идея.  Я думаю, что в этом
вопросе со мной согласны все, кроме Игоря.  Следовательно, с пакетами,
которые не сопровождаются либо полностью сопровождаются скриптами, надо
поступить следующим образом: те пакеты, на которые найдутся мантейнеры,
останутся в Сизифе.  Остальным пакетам придётся покинуть Сизиф и
отправиться в репозиторий для пакетов, которые обслуживают только скрипты.


-- 
ldv

Re: [devel] unmaintained packages shall not belong to Sisyphus

[Dmitry V. Levin]

On Fri, Aug 28, 2020 at 02:06:39AM +0300, Aleksey Novodvorsky wrote:
> пт, 28 авг. 2020 г., 02:01 Dmitry V. Levin wrote:
> > On Thu, Aug 27, 2020 at 05:29:53AM +0300, Igor Vlasenko wrote:
> > > Дмитрий заинтересовался, но не совсем тем, чем хотелось,
> > > а вопросом, нельзя ли как-то уменьшить число релизов от моих роботов,
> > > что я в итоге сделал для импорта из федоры и магейи,
> >
> > Игорь, самая важная тема почти совсем не была раскрыта в вашем письме,
> > вы лишь упомянули её вскользь одной фразой, которую я процитировал.
> >
> > Я с самого начала исходил из того, что Sisyphus - это репозиторий пакетов,
> > у которых есть мантейнеры и пользователи.  Мантейнеры - это люди, которые
> > пользуются и сопровождают свои пакеты, см.
> > https://www.altlinux.org/Руководство_начинающего_мейнтейнера_ALT_Linux_Team
> > К мантейнерам обращаются другие пользователи, когда к пакетам, которые они
> > сопровождают, есть какие-то вопросы.
> >
> > Поскольку мантейнеры - это люди, то у них есть естественный предел того
> > количества пакетов, которые они могут поддерживать.  Мантейнер, который
> > хотя бы примерно понимает, что поменялось в новой сборке своего пакета,
> > вряд ли может качественно поддерживать более 200..300 пакетов.  Если у
> > кого-то в сопровождении находятся 3500+ пакетов, это значит, что среди них
> > найдётся не более 5%..10% пакетов, которые реально поддерживаются, по
> > которым можно задать вопросы и получить вразумительные ответы, повесить
> > багрепорты и получить адекватную реакцию на них.  Остальные 90%..95%
> > пакетов полностью мантейнят скрипты, и спрос с них соответствующий,
> > т.е. никакой.  По этим 90%..95% пакетов практически нет экспертизы.
> >
> > К пакетам, которые полностью мантейнятся скриптами, другой уровень
> > доверия.  Ответственные люди никогда не включат такой пакет в дистрибутив
> > и вряд ли поставят такой пакет в сколь-нибудь значимую систему.
> >
> > Смешивать в одном репозитории пакеты, которые поддерживаются, и которые
> > полностью сопровождаются скриптами - это плохая идея.  Я думаю, что в этом
> > вопросе со мной согласны все, кроме Игоря.  Следовательно, с пакетами,
> > которые не сопровождаются либо полностью сопровождаются скриптами, надо
> > поступить следующим образом: те пакеты, на которые найдутся мантейнеры,
> > останутся в Сизифе.  Остальным пакетам придётся покинуть Сизиф и
> > отправиться в репозиторий для пакетов, которые обслуживают только скрипты.
> 
> Это в принципе скорее верно.
> Но нельзя ли проиллюстрировать статистикой по мейнтейнерам пакетов perl в
> других крупных репозиториях?

Я думаю, что перловые пакеты тут будут не самой удачной иллюстрацией,
поскольку их не так много, как кажется, но если говорить именно про них,
то в Debian есть Debian Perl Group [1], за которой, по данным repology [2],
в Debian Testing числится 3646 пакетов.  Сколько человек в этой группе
и насколько они активны, мне неизвестно.

В Сизифе 2348 пакетов, имя которых начинается на perl,
большая часть из них числится за 4 мантейнерами и одной группой:

$ grep ^perl /ALT/acl/list.packages.sisyphus |awk '{print $2}' |sort |uniq -c |sort -n |awk '$1 > 24 {print}'
    189 crux
    225 lav
    234 naf
    456 @cpan
   1020 viy

Для сравнения, за Игорем в Сизифе числится 3516 пакетов:
$ awk '$2 == "viy" {print}' ALT/acl/list.packages.sisyphus |wc -l
3516
(но мне кажется, что минимум 80% процентов из них - это выхлоп скриптов,
который ни один человек ещё ни разу не видел).

[1] https://wiki.debian.org/Teams/DebianPerlGroup
[2] https://repology.org/maintainer/pkg-perl-maintainers@lists.alioth.debian.org


-- 
ldv

Re: [devel] unmaintained packages shall not belong to Sisyphus

[Dmitry V. Levin]

On Fri, Aug 28, 2020 at 03:19:38AM +0300, Aleksey Novodvorsky wrote:
> пт, 28 авг. 2020 г., 03:05 Dmitry V. Levin <ldv@altlinux.org>:
> > On Fri, Aug 28, 2020 at 02:06:39AM +0300, Aleksey Novodvorsky wrote:
[...]
> > > Но нельзя ли проиллюстрировать статистикой по мейнтейнерам пакетов perl в
> > > других крупных репозиториях?
> >
> > Я думаю, что перловые пакеты тут будут не самой удачной иллюстрацией,
> > поскольку их не так много, как кажется, но если говорить именно про них,
> > то в Debian есть Debian Perl Group [1], за которой, по данным repology [2],
> > в Debian Testing числится 3646 пакетов.  Сколько человек в этой группе
> 
> 19.
> https://launchpad.net/~pkg-perl-maintainers/+members

Хорошо, допустим, их 19.

Если посмотреть, сколько у нас мантейнеров, за которыми числится
более 3 пакетов, имя которых начинается на perl, то их тоже будет 19:

$ grep ^perl ALT/acl/list.packages.sisyphus |awk '{print $2}' |grep -Fv @nobody |sort |uniq -c |awk '$1 > 3 {print}' |wc -l
19

> и насколько они активны, мне неизвестно.

А это гораздо важнее, чем количество.
Потому что 3646/19 пакетов одному мантейнеру поддерживать вполне реально,
а вот 3646/2 - уже нет.


-- 
ldv

Re: [devel] unmaintained packages shall not belong to Sisyphus

[Anton Farygin]

On 28.08.2020 02:01, Dmitry V. Levin wrote:
> Смешивать в одном репозитории пакеты, которые поддерживаются, и которые
> полностью сопровождаются скриптами - это плохая идея.  Я думаю, что в этом
> вопросе со мной согласны все, кроме Игоря.  Следовательно, с пакетами,
> которые не сопровождаются либо полностью сопровождаются скриптами, надо
> поступить следующим образом: те пакеты, на которые найдутся мантейнеры,
> останутся в Сизифе.  Остальным пакетам придётся покинуть Сизиф и
> отправиться в репозиторий для пакетов, которые обслуживают только скрипты.

Не совсем согласен с этим утверждением.

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

Тот же php сопровождается примерно таким способом - основной пакет 
покрыт тестами, модули по возможности тоже.

Обновление выглядит как сборка основного пакета и пересборка скриптом 
зависимых.

Модули появляются по мере необходимости, а не втаскиванием всего и вся.


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

Примерно такая же история c ocaml, в котором идёт мелкое дробление на 
модули и сильное переплетение зависимостей.

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


Скрипты это ерунда. Главное что бы ментейнер успевал реагировать на 
ошибки в своих пакетах.

Re: [devel] unmaintained packages shall not belong to Sisyphus

[Dmitry V. Levin]

On Fri, Aug 28, 2020 at 08:22:18AM +0300, Anton Farygin wrote:
> On 28.08.2020 02:01, Dmitry V. Levin wrote:
> > Смешивать в одном репозитории пакеты, которые поддерживаются, и которые
> > полностью сопровождаются скриптами - это плохая идея.  Я думаю, что в этом
> > вопросе со мной согласны все, кроме Игоря.  Следовательно, с пакетами,
> > которые не сопровождаются либо полностью сопровождаются скриптами, надо
> > поступить следующим образом: те пакеты, на которые найдутся мантейнеры,
> > останутся в Сизифе.  Остальным пакетам придётся покинуть Сизиф и
> > отправиться в репозиторий для пакетов, которые обслуживают только скрипты.
> 
> Не совсем согласен с этим утверждением.
> 
> На самом деле часто встречаются вообще без проблемные пакеты, обновление 
> которых можно поручить скриптам.

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

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

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


-- 
ldv

Re: [devel] unmaintained packages shall not belong to Sisyphus

[Michael Shigorin]

On Fri, Aug 28, 2020 at 02:01:43AM +0300, Dmitry V. Levin wrote:
> Я с самого начала исходил из того, что Sisyphus - это
> репозиторий пакетов, у которых есть мантейнеры и пользователи.
> Мантейнеры - это люди, которые пользуются и сопровождают свои
> пакеты, см.
> https://www.altlinux.org/Руководство_начинающего_мейнтейнера_ALT_Linux_Team

У нас, кстати, до сих пор нет актуального и полного руководства
на тему "как собрать пакет с нуля".  Набросков на вики штук пять.
За прошедший год в МЦСТ, например, написали документацию
разработчика под "Эльбрус"!

> Поскольку мантейнеры - это люди, то у них есть естественный предел того
> количества пакетов, которые они могут поддерживать.  Мантейнер, который
> хотя бы примерно понимает, что поменялось в новой сборке своего пакета,
> вряд ли может качественно поддерживать более 200..300 пакетов.

Это если их замораживать (или уже забросили), реалистичная оценка
ближе к десятку, ну нескольким для человека на ставке или очень
увлечённого.

Люди, которые собирают у нас сотни и тысячи пакетов -- так или
иначе автоматизируют свою работу (во многом дублируя эти усилия,
ага) и обычно сами по себе являются в своём роде титанами.

Ну или чё-то где-то пособирали, потому что кто-то просил,
а потом забросили и не вспоминают, потому как не пользуются
(мой случай).

> Если у кого-то в сопровождении находятся 3500+ пакетов, это
> значит, что среди них найдётся не более 5%..10% пакетов,
> которые реально поддерживаются, по которым можно задать вопросы
> и получить вразумительные ответы, повесить багрепорты и
> получить адекватную реакцию на них.  Остальные 90%..95% пакетов
> полностью мантейнят скрипты, и спрос с них соответствующий,
> т.е. никакой.  По этим 90%..95% пакетов практически нет
> экспертизы.

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

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

Это ещё одна важная и глубокая отдельная тема, разумеется.

> К пакетам, которые полностью мантейнятся скриптами, другой
> уровень доверия.  Ответственные люди никогда не включат такой
> пакет в дистрибутив и вряд ли поставят такой пакет в
> сколь-нибудь значимую систему.

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

> Смешивать в одном репозитории пакеты, которые поддерживаются,
> и которые полностью сопровождаются скриптами - это плохая идея.

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

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

А вот для библиотек -- разве что при явном объявлении войны
уточнённому Игорем опять же в явном виде тезису "лучше дать
хоть какие-то сборки библиотек, чем до нас не дойдёт умаявшийся
собирать всё недостающее для очередного пакета".

> Я думаю, что в этом вопросе со мной согласны все, кроме Игоря.

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

> Следовательно, с пакетами, которые не сопровождаются либо
> полностью сопровождаются скриптами, надо поступить следующим
> образом: те пакеты, на которые найдутся мантейнеры, останутся
> в Сизифе.  Остальным пакетам придётся покинуть Сизиф и
> отправиться в репозиторий для пакетов, которые обслуживают
> только скрипты.

Ядрёну бомбу на сизиф ты уже сбрасывал (принудительный git,
растеряли примерно половину майнтейнеров-админов, вернулись).
Это была бы термоядерная.

Впрочем, если ты готов показать мастеркласс по сборке LO,
я бы даже билетик купил.  Ну или по #38843.

Ergo: возможно, пора вернуться к чему-то вроде RPMS.main,
которое сопровождается более-менее внимательно и пригодно
для твоей машины, при этом не имеет сборочных/установочных
зависимостей от сопровождаемого вручную/скриптами другого.

PS: если _тебе_ нужен LDV Linux, то _ты_ его и делаешь,
а не принуждаешь других сделать тебе то, что не обязаны.
Другие могут подключиться, если им по вкусу результат.
И да, начни с чего-то вроде такого _на берегу_:
http://www.openwall.com/Owl/CONCEPTS.shtml

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] unmaintained packages shall not belong to Sisyphus

[Michael Shigorin]

On Fri, Aug 28, 2020 at 07:30:14PM +0300, Michael Shigorin wrote:
> On Fri, Aug 28, 2020 at 02:01:43AM +0300, Dmitry V. Levin wrote:
> > Следовательно, с пакетами, которые не сопровождаются либо
> > полностью сопровождаются скриптами, надо поступить следующим
> > образом: те пакеты, на которые найдутся мантейнеры, останутся
> > в Сизифе.  Остальным пакетам придётся покинуть Сизиф и
> > отправиться в репозиторий для пакетов, которые обслуживают
> > только скрипты.
> Ядрёну бомбу на сизиф ты уже сбрасывал (принудительный git,
> растеряли примерно половину майнтейнеров-админов, вернулись).
> Это была бы термоядерная.

Собственно, по твоей логике надо объявить анафему
buildreq, findreq и hasher с girar, а собирать
пакеты и контролировать их зависимости вручную.

И вот тут подумалось: это часом не NIH-синдром?

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] unmaintained packages shall not belong to Sisyphus

[Dmitry V. Levin]

On Fri, Aug 28, 2020 at 07:33:32PM +0300, Michael Shigorin wrote:
> On Fri, Aug 28, 2020 at 07:30:14PM +0300, Michael Shigorin wrote:
> > On Fri, Aug 28, 2020 at 02:01:43AM +0300, Dmitry V. Levin wrote:
> > > Следовательно, с пакетами, которые не сопровождаются либо
> > > полностью сопровождаются скриптами, надо поступить следующим
> > > образом: те пакеты, на которые найдутся мантейнеры, останутся
> > > в Сизифе.  Остальным пакетам придётся покинуть Сизиф и
> > > отправиться в репозиторий для пакетов, которые обслуживают
> > > только скрипты.
> > Ядрёну бомбу на сизиф ты уже сбрасывал (принудительный git,
> > растеряли примерно половину майнтейнеров-админов, вернулись).
> > Это была бы термоядерная.
> 
> Собственно, по твоей логике надо объявить анафему
> buildreq, findreq и hasher с girar, а собирать
> пакеты и контролировать их зависимости вручную.

Миша, ты как будто вообще не понял, что я написал.
Совсем-совсем не понял.  А может, и не прочитал вовсе.


-- 
ldv

Re: [devel] unmaintained packages shall not belong to Sisyphus

[Michael Shigorin]

On Fri, Aug 28, 2020 at 07:43:20PM +0300, Dmitry V. Levin wrote:
> > > > Следовательно, с пакетами, которые не сопровождаются
> > > > либо полностью сопровождаются скриптами
> > Собственно, по твоей логике надо объявить анафему
> > buildreq, findreq и hasher с girar, а собирать
> > пакеты и контролировать их зависимости вручную.
> Миша, ты как будто вообще не понял, что я написал.
> Совсем-совсем не понял.  А может, и не прочитал вовсе.

Прочитал, может, что-то не понял.

Но ты ведь согласен, что ручной анализ configure.ac
или там CMakeLists.txt вместе с документацией проекта
куда ближе к настоящему сопровождению, чем buildreq?

И что живой incominger вместо отгораживания скриптами
от живых майнтейнеров -- это куда ближе к тому уровню
требований, который ты сейчас де-факто предъявил Игорю?

Это ведь было действительно здорово -- получать мнение
грамотного человека о том, что стоит поправить в пакете,
который он не стал пересобирать из incoming в сизиф.

Дима, я тебя в лицемерии обвинил, если ты не понял.
Неприятно, но раз анекдот приходится объяснять -- вот.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] unmaintained packages shall not belong to Sisyphus

[Dmitry V. Levin]

On Fri, Aug 28, 2020 at 10:52:16PM +0300, Michael Shigorin wrote:
> On Fri, Aug 28, 2020 at 07:43:20PM +0300, Dmitry V. Levin wrote:
> > > > > Следовательно, с пакетами, которые не сопровождаются
> > > > > либо полностью сопровождаются скриптами
> > > Собственно, по твоей логике надо объявить анафему
> > > buildreq, findreq и hasher с girar, а собирать
> > > пакеты и контролировать их зависимости вручную.
> > Миша, ты как будто вообще не понял, что я написал.
> > Совсем-совсем не понял.  А может, и не прочитал вовсе.
> 
> Прочитал, может, что-то не понял.
> 
> Но ты ведь согласен, что ручной анализ configure.ac
> или там CMakeLists.txt вместе с документацией проекта
> куда ближе к настоящему сопровождению, чем buildreq?
> 
> И что живой incominger вместо отгораживания скриптами
> от живых майнтейнеров -- это куда ближе к тому уровню
> требований, который ты сейчас де-факто предъявил Игорю?
> 
> Это ведь было действительно здорово -- получать мнение
> грамотного человека о том, что стоит поправить в пакете,
> который он не стал пересобирать из incoming в сизиф.
> 
> Дима, я тебя в лицемерии обвинил, если ты не понял.
> Неприятно, но раз анекдот приходится объяснять -- вот.

Нет, это банальное передёргивание.  Здесь такое не прокатит.

Окей, Миша, записываю тебя в сторонники превращения Сизифа в autoimports.


-- 
ldv

Re: [devel] unmaintained packages shall not belong to Sisyphus

[Michael Shigorin]

On Fri, Aug 28, 2020 at 11:04:39PM +0300, Dmitry V. Levin wrote:
> > Но ты ведь согласен, что ручной анализ configure.ac
> > или там CMakeLists.txt вместе с документацией проекта
> > куда ближе к настоящему сопровождению, чем buildreq?
> Нет, это банальное передёргивание.  Здесь такое не прокатит.

Ну наконец-то.

> Окей, Миша, записываю тебя в сторонники превращения Сизифа
> в autoimports.

Здесь такое не прокатит (ц) ;-)

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

И споры о качестве пакетов -- не его подача, а следствие слияния
main и contrib в единый classic при переделке сборочницы,
если правильно помню пояснение то ли твоё, то ли legion@.

Про количество/качество пакетов/майнтейнеров можно долго говорить,
но если ты хочешь больше компетентных майнтейнеров -- стоит
заботиться об "инвестиционном климате", когда так и хочется
принести свои талант и время (и доверие) в проект.

Мне очень понравился тот альт, который я застал в 2001, в том
числе и потому, что там были нужные мне пакеты, собранные не хуже
или лучше того, как было в Black Cat и /usr/local, и даже больше.

Помнится, в книжке "Manage It!" авторства Johanna Rothman
прочитал такое соображение, что лидер -- это не тот, кто идёт
за командой сзади со стимулюсом, а тот, кто идёт спереди,
замечая завалы прежде того, как команда в них уткнулась.

Вот такое тоже понравилось.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] unmaintained packages shall not belong to Sisyphus

[Alexey Gladkov]

On Fri, Aug 28, 2020 at 10:52:16PM +0300, Michael Shigorin wrote:
> On Fri, Aug 28, 2020 at 07:43:20PM +0300, Dmitry V. Levin wrote:
> > > > > Следовательно, с пакетами, которые не сопровождаются
> > > > > либо полностью сопровождаются скриптами
> > > Собственно, по твоей логике надо объявить анафему
> > > buildreq, findreq и hasher с girar, а собирать
> > > пакеты и контролировать их зависимости вручную.
> > Миша, ты как будто вообще не понял, что я написал.
> > Совсем-совсем не понял.  А может, и не прочитал вовсе.
> 
> Прочитал, может, что-то не понял.
> 
> Но ты ведь согласен, что ручной анализ configure.ac
> или там CMakeLists.txt вместе с документацией проекта
> куда ближе к настоящему сопровождению, чем buildreq?
> 
> И что живой incominger вместо отгораживания скриптами
> от живых майнтейнеров -- это куда ближе к тому уровню
> требований, который ты сейчас де-факто предъявил Игорю?
> 
> Это ведь было действительно здорово -- получать мнение
> грамотного человека о том, что стоит поправить в пакете,
> который он не стал пересобирать из incoming в сизиф.
> 
> Дима, я тебя в лицемерии обвинил, если ты не понял.
> Неприятно, но раз анекдот приходится объяснять -- вот.

Ну, значит так рассказал ...

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

Если ты не видишь разницы между мантейнером и скриптом, то значит в сизифе
с сопровождением пакетов всё стало очень плохо.

-- 
Rgrds, legion

Re: [devel] unmaintained packages shall not belong to Sisyphus

[Michael Shigorin]

On Fri, Aug 28, 2020 at 10:19:00PM +0200, Alexey Gladkov wrote:
> Всё-таки есть разница между инструментами помогающими
> мантейнеру и тупому скрипту, который пытается мантейнера
> заменить. Тупой он потому, что кроме как на формальный релиз
> чужого пакета не смотрит и работоспособность не проверяет.

Лёша, а как именно смотрят/проверяют работоспособность те же
findreq/buildreq/hasher? (girar, положим, хоть пытается)

> Если ты не видишь разницы между мантейнером и скриптом, то
> значит в сизифе с сопровождением пакетов всё стало очень плохо.

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

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

А то, что мои патчи с кусочками про "spec cleanup" (например,
упорядочить метаданные в порядке, рекомендованном издавна в
http://altlinux.org/ALT_Packaging_HOWTO#Порядок_тэгов),
регулярно заворачивают -- в некотором смысле забавно:
человеку-то я такое отошлю, потратив время, а вот скрипту
и отсылать бы не стал (потому как там заведомо "лишь бы
собралось/заработало", эстетические требования не стоят).

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

PS: да, кстати, alsa в сизифе майнтейнится тоже скриптами.
Самопальными, на коленке, под задачу, но иначе было слишком
много ошибок вроде "собрал на самом деле старое", помнится.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] unmaintained packages shall not belong to Sisyphus

[Alexey Gladkov]

On Fri, Aug 28, 2020 at 11:46:54PM +0300, Michael Shigorin wrote:
> On Fri, Aug 28, 2020 at 10:19:00PM +0200, Alexey Gladkov wrote:
> > Всё-таки есть разница между инструментами помогающими
> > мантейнеру и тупому скрипту, который пытается мантейнера
> > заменить. Тупой он потому, что кроме как на формальный релиз
> > чужого пакета не смотрит и работоспособность не проверяет.
> 
> Лёша, а как именно смотрят/проверяют работоспособность те же
> findreq/buildreq/hasher? (girar, положим, хоть пытается)

Ты всё ещё путаешь инструмент для мантейнера и мантейнера, который
применяет инструмент.

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

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

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

И ни один скрипт не заменит мантейнера. Если вы не тянете сопровождать
столько пакетов, то уменьшайте пакетную базу. Импорт из других
репозиториев выглядит жалко.

> PS: да, кстати, alsa в сизифе майнтейнится тоже скриптами.
> Самопальными, на коленке, под задачу, но иначе было слишком
> много ошибок вроде "собрал на самом деле старое", помнится.

Мне очень жаль это слышать. Я думал, что alsa хотя бы проверяется, но
спасибо за прояснение.

-- 
Rgrds, legion

Re: [devel] unmaintained packages shall not belong to Sisyphus

[Konstantin Lepikhov]

Hi Alexey!

On 08/29/2020, at 01:52:28 AM you wrote:

> On Fri, Aug 28, 2020 at 11:46:54PM +0300, Michael Shigorin wrote:
> > On Fri, Aug 28, 2020 at 10:19:00PM +0200, Alexey Gladkov wrote:
> > > Всё-таки есть разница между инструментами помогающими
> > > мантейнеру и тупому скрипту, который пытается мантейнера
> > > заменить. Тупой он потому, что кроме как на формальный релиз
> > > чужого пакета не смотрит и работоспособность не проверяет.
> > 
> > Лёша, а как именно смотрят/проверяют работоспособность те же
> > findreq/buildreq/hasher? (girar, положим, хоть пытается)
> 
> Ты всё ещё путаешь инструмент для мантейнера и мантейнера, который
> применяет инструмент.
> 
> То что ты перечислил это инструменты, которые помогают мантейнеру
> формировать зависимости и производить воспроизводимую сборку пакета.
> 
> Но потом пакет нужно проверять т.е. не только прогнать тесты из пакета
> (которые чаще всего хреновые), а поставить и посмотреть, что пакет
> действительно работает.
+1 Кстати, ровно по этому было обсуждение про _реальную_ поддержку
архитектур в Сизифе, а не какие-то сборочницы с эмуляторами.

> 
> > > Если ты не видишь разницы между мантейнером и скриптом, то
> > > значит в сизифе с сопровождением пакетов всё стало очень плохо.
> > 
> > В мире с сопровождением пакетов всё стало очень плохо, об этом и
> > АЕН не первый год говорит прямым текстом.  Похоже, накрениваться
> > начало лет десять назад ещё.
> 
> И ни один скрипт не заменит мантейнера. Если вы не тянете сопровождать
> столько пакетов, то уменьшайте пакетную базу. Импорт из других
> репозиториев выглядит жалко.
Тема всплывает крайне регулярно и по тому что происходит, imports это
скорее диверсия, а не "помощь". До сих пор остается актуальным
высказывание моего коллеги по работе, который попробовал сидеть на сизифе
и потом горько заметил что "сизиф это помойка нерабочего софта и
прикольных игрушек". Т.е. на игрушки время есть ;)

Современный софт крайне комплексная штука, поэтому неправильно просто
собрать пакет, надо понять зачем его собирать вообще и иметь желание этим
результатом пользоваться. А то будет как с тем багом про работу ejabberd в
docker[1].

1. https://bugzilla.altlinux.org/show_bug.cgi?id=36895

-- 
WBR et al.

[devel] [JT] баланс/динамика: пакеты/майнтейнеры (was: unmaintained packages shall not belong to Sisyphus)

[Michael Shigorin]

On Mon, Aug 31, 2020 at 12:14:56PM +0200, Konstantin Lepikhov wrote:
> > > Лёша, а как именно смотрят/проверяют работоспособность те же
> > > findreq/buildreq/hasher? (girar, положим, хоть пытается)
> > Ты всё ещё путаешь инструмент для мантейнера и мантейнера,
> > который применяет инструмент.

Да ладно!

> > Но потом пакет нужно проверять т.е. не только прогнать тесты
> > из пакета (которые чаще всего хреновые), а поставить и
> > посмотреть, что пакет действительно работает.
> +1 Кстати, ровно по этому было обсуждение про _реальную_ поддержку
> архитектур в Сизифе, а не какие-то сборочницы с эмуляторами.

Костик, на сборочнице всё на железе и собирается, если что;
armh на aarch64, умеющем v7hf, а mipsel -- на mips64el,
иначе по памяти (да и мощностям) было бы совсем грустно.

> > > > Если ты не видишь разницы между мантейнером и скриптом, то
> > > > значит в сизифе с сопровождением пакетов всё стало очень плохо.
> > > В мире с сопровождением пакетов всё стало очень плохо, об этом и
> > > АЕН не первый год говорит прямым текстом.  Похоже, накрениваться
> > > начало лет десять назад ещё.
> > И ни один скрипт не заменит мантейнера.

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

> > Если вы не тянете сопровождать столько пакетов, то уменьшайте
> > пакетную базу. Импорт из других репозиториев выглядит жалко.
> Тема всплывает крайне регулярно и по тому что происходит,
> imports это скорее диверсия, а не "помощь".

Это скорее набор заготовок (порой просто работающих, из моего
опыта), от которых настоящему майнтейнеру(tm) уже ближе рыть.

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

Передай человеку, что он забыл баги развесить -- хотя бы скриптом.
Ну и что у нас на сизиф обычно перебираются те, кто умеет водить
бранч (или хотя бы почитал ссылки с http://altlinux.org/sisyphus).

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

Грамотность -- тоже штука многоплановая, но не требовать же на
join ещё и экзамен по русскому (хотя бы пунктуации)...

---------------------------------------------------------------

Мне кажется, вы сейчас немного не с того конца слона заходите,
други мои.  Да, было бы клёво, если бы на каждые полтора пакета
в сизифе вдруг нашёлся майнтейнер вашего уровня.  Или хотя бы
просто выделенный.  Беда с этим та, о которой давно говорит АЕН,
в набат бьёт Игорь, а вы делаете вид, что при недостаче хлеба
решение простое -- надо переходить на крендельки: их вообще мало.

Да, надо искать, приводить, поддерживать в становлении на крыло
(а уже сверхзвуковых -- так ещё и учиться учитывать) коллег.

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

А из схожих по направленности (хоть в чём-то) дистрибутивов
с именно компактной пакетной базой припоминается Owl.

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

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] suggested tags order

[Aleksei Nikiforov]

28.08.2020 23:46, Michael Shigorin пишет:> А то, что мои патчи с
кусочками про "spec cleanup" (например,
> упорядочить метаданные в порядке, рекомендованном издавна в
> http://altlinux.org/ALT_Packaging_HOWTO#Порядок_тэгов),
> регулярно заворачивают -- в некотором смысле забавно:
> человеку-то я такое отошлю, потратив время, а вот скрипту
> и отсылать бы не стал (потому как там заведомо "лишь бы
> собралось/заработало", эстетические требования не стоят).

Спасибо за ссылку на эту документацию. Посмотрел, но есть вопрос: почему
serial (он же epoch) идёт после version и release? Насколько я знаю, при
вычислении версии пакета serial/epoch имеет больший вес, чем version и
release. Лично мне удобнее читать Epoch/Version/Release, а не
Version/Release/Epoch. Чем мотивирован такой порядок?

Re: [devel] suggested tags order

[Sergey V Turchin]

On Monday, 31 August 2020 10:53:10 MSK Aleksei Nikiforov wrote:
> 28.08.2020 23:46, Michael Shigorin пишет:> А то, что мои патчи с
> кусочками про "spec cleanup" (например,
> 
> > упорядочить метаданные в порядке, рекомендованном издавна в
> > http://altlinux.org/ALT_Packaging_HOWTO#Порядок_тэгов),
> > регулярно заворачивают -- в некотором смысле забавно:
> > человеку-то я такое отошлю, потратив время, а вот скрипту
> > и отсылать бы не стал (потому как там заведомо "лишь бы
> > собралось/заработало", эстетические требования не стоят).
> 
> Спасибо за ссылку на эту документацию. Посмотрел, но есть вопрос: почему
> serial (он же epoch) идёт после version и release? Насколько я знаю, при
> вычислении версии пакета serial/epoch имеет больший вес, чем version и
> release. Лично мне удобнее читать Epoch/Version/Release, а не
Мне удобнее Name/Version/Release/Epoch.

> Version/Release/Epoch. Чем мотивирован такой порядок?
Чтобы был порядок, иначе будет то Name/Epoch/Version, то Name/Version/Release.

-- 
Regards, Sergey.

Re: [devel] suggested tags order

[Paul Wolneykien]

В Mon, 31 Aug 2020 14:46:15 +0300
Sergey V Turchin <zerg@altlinux.org> пишет:

> > Version/Release/Epoch. Чем мотивирован такой порядок?  
> Чтобы был порядок, иначе будет то Name/Epoch/Version, то
> Name/Version/Release.

  Рискну предположить, что мотивирован тем, что в апстриме нет "epoch".
В апстриме версия пакета, допустим, просто "2.3.1", а новая эпоха
нумерации версий потребовалась исключительно в рамках нашего
репозитория — это же технический обход "сбоя" в нумерации версий.
Поэтому удобно, открыв спек, первым делом увидеть версию так, как она
пишется в апстриме.

Re: [devel] hasher ALT#36531

[Dmitry V. Levin]

On Thu, Aug 27, 2020 at 05:29:53AM +0300, Igor Vlasenko wrote:
[...]
> Что я могу с этим сделать? Полтора года назад, после упомянутого выше
> письма в Сизиф, я начал переписывать свои скрипты для autoimports
> в прототип локальной сборочницы. При этом нашел еще один резерв для
> улучшения быстродействия сборочницы -- за счет оптимизации работы
> hasher при работе с неизменным репозиторием.
> Одна из таких оптимизаций ---
> https://bugzilla.altlinux.org/show_bug.cgi?id=36531
> экономия 10 секунд при создании chroot.
> Какой это эффект дало бы для сборочницы?
> Простой таск с 1 пакетом -- в среднем быстрее на 30 секунд (10 секунд на
> сборочный чрут и по 10 секунд на install test chroot для 2-х бинарных
> пакетов). На больших транзакциях больше.
> К примеру, пересборка perl будет выполняться быстрее на 20 минут,
> пересборка python -- быстрее на час.
> 
> #36531 -- тривиальный патч: сделать (кусок кода) отключаемым:
> if(переменная) { (кусок кода) }.
> Но я после недели обсуждений с Дмитрием так и не смог пробить
> #36531 в апстрим hasher :(. В итоге форкнул свою копию hasher
> и свернул свою разработку прототипа локальной сборочницы. :(

Извините, Игорь, но я решительно не понимаю, о чём вы пишите:
это совершенно не стыкуется с моими данными.

Вот у меня, допустим,
unchecked_initroot_cache="$(sed '/^task[[:space:]]\+/!d;s///;q' /path/to/Sisyphus/files/list/task.info)"

Первый hsh --init (uncached) занимает около 24 секунд,
второй hsh --init (fully cached) занимает около 2 (двух) секунд.
Какой-то последующий partially cached hsh --init
(unchecked_initroot_cache поменялся, а чрут нет) занимает около 12 секунд.

Вот свежезакоммиченное задание, в котором много install checks:
https://lists.altlinux.org/pipermail/sisyphus-incominger/2020-August/580593.html
Там сплошные "no need to repeat, install check SKIPPED", это значит,
что выполнялся только hsh --init, там эти 2 секунды хорошо видно.

Игорь, вы пишите про какую-то оптимизацию, которая даёт результат
10 секунд на развёртывание сборочного чрута.  А у нас уже 2 секунды.

Игорь, у нас уже 2 секунды, а у вас ещё 10 секунд.
Вот когда у вас будет 1 секунда, тогда и поговорим про оптимизацию hasher,
договорились?

Я бы мог добавить сюда добавить пару анекдотов про автострады,
но мне кажется, что и без них всё ясно.


-- 
ldv

Re: [devel] hasher ALT#36531

[Igor Vlasenko]

On Fri, Aug 28, 2020 at 07:40:10PM +0300, Dmitry V. Levin wrote:
> Игорь, вы пишите про какую-то оптимизацию, которая даёт результат
> 10 секунд на развёртывание сборочного чрута.  А у нас уже 2 секунды.

Гм. Дмитрий, наверное, вы не внимательно смотрели описание.
Измерения выполнялись на машине altair на композитном репозитории:
sisyphus+autoimports/x86_64.
Такой репозиторий содержит 35.000+17.000=52.000 пакетов,
10 секунд это для него.

а у вас, как понимаю, ниспльзовался чистый sisyphus/x86_64
с 17.000 пакетов. Вы получили 2 секунды.

Для меня 10 секунд * 1.000 пакетов = 3 часа экономии для
скриптов autoimports.

Но в контексте чистого сизифа попробуйте провести
замеры на Raspberry Pi 3/4, c sisyphus/aarch64 и armh.
Думаю, там тоже будет далеко не 2 секунды экономии.

Впрочем, ALT#36531 -- это, по сути, быстрый хак,
нацеленный минимизировать вмешательство в код hasher.

Он играет вспомогательную роль для другого хака с 
cp -rl закешированного hasher_workdir.

По хорошему, вместо ALT#36531 в hasher нужна
полноценная поддержка кеширования метаданных
при работе с постоянным репозиторием.

Наверно, ету тему нужно описать подробнее,
отдельным письмом.




-- 

I V

Re: [devel] automatic License

[Dmitry V. Levin]

On Thu, Aug 27, 2020 at 05:29:53AM +0300, Igor Vlasenko wrote:
[...]
> Рассмотрим, к примеру, наше новое полиси по заполнению лицензий.
> При ручной работе правку тега License как отдельную задачу
> выполнять не выгодно. Это была бы достаточно монотонная
> отупляющая работа, тратящая и время человека, и время сборочницы.
> При ручной работе выгодно правку тега License выполнять
> как сопутствующую работу при релизе пакета. Экономится
> и человеческое время (одно обращение к пакету и спек файлу
> по двум поводам), и время сборочницы. Минусом является то, что
> при этом само внедрение полиси размазывается на годы.
> Каждый раз при релизе пакета нужно заодно взглянуть и при необходимости поправить тег.
> 
> При автоматизированном подходе все наоборот.
> Когда пакетов десятки тысяч, проще написать скрипт - корректор
> тега License. Парсим тег License, считаем md5sum LICENSE COPYING
> (хвоста файла для MIT лицензий), делаем выводы,
> генерируем исправленные пакеты и список сложных случаев.
> Очень существенно экономим человеческое время за счет машинного.
> Р-р-раз и 100500 пакетов готово.
> Второй плюс - полиси внедряется практически мгновенно.

Вы и правда верите в то, что md5sum LICENSE COPYING даст вам приемлемый
результат?  Если бы это было бы так, то зачем были бы нужны все эти
проекты по распознаванию условий распространения софта?

К сожалению, md5sum LICENSE COPYING не сможет отличить даже GPL-2.0-only
от GPL-2.0-or-later, потому что эта разница находится в других файлах.

Собирать много пакетов быстро - это вполне востребованная задача,
особенно когда исходники не меняются, как в том примере с gcc.

Но если ваш пример был призван проиллюстрировать востребованность
этой задачи, то пример вышел неудачный.


-- 
ldv

Re: [devel] automatic License

[Igor Vlasenko]

On Fri, Aug 28, 2020 at 08:55:32PM +0300, Dmitry V. Levin wrote:
> К сожалению, md5sum LICENSE COPYING не сможет отличить даже GPL-2.0-only
> от GPL-2.0-or-later, потому что эта разница находится в других файлах.

Гм. действительно. Вылетело из головы, когда писал.
Надо будет добавить поиск в исходниках соответствующих
юридических оборотов в библиотеку SourceAnalyzer.

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

Кстати. Эта фраза выше про LICENSE COPYING должна была
висеть на страничке License policy в красной рамочке.
Но ее там нет, потому что и самой страницы License policy
на altlinux wiki нет. Налицо нарушение
https://www.altlinux.org/Policy_Policy .

Хорошо, хоть перед внесением изменений в sisyphus_check
было письмо в devel@, хоть какие-то приличия были соблюдены.
Но отсутствие официальной документации не есть гуд.
Без нее люди по пути наименьшего сопротивления подберут
простейший вариант, лишь бы sisyphus_check не шумел.
Робот здесь в тему, он сможет проверить за людьми.

Это Дмитрий, вам укор, что разводите бардак вместо ordung'а.

Впрочем, наша Policy_Policy очень емко характеризует сама себя:

Действующая политика Sisyphus. Политика действует с 14 марта 2008. 
Ответственный за проведение политики в жизнь — куда-то смылся. 

Перефразируя классиков, так и хочется сказать, что
в ALT linux две беды: бардак и дороги (сборочница).


-- 

I V

Re: [devel] automatic License

[Alexey Gladkov]

On Sun, Aug 30, 2020 at 11:14:07AM +0300, Igor Vlasenko wrote:
> On Fri, Aug 28, 2020 at 08:55:32PM +0300, Dmitry V. Levin wrote:
> > К сожалению, md5sum LICENSE COPYING не сможет отличить даже GPL-2.0-only
> > от GPL-2.0-or-later, потому что эта разница находится в других файлах.
> 
> Гм. действительно. Вылетело из головы, когда писал.
> Надо будет добавить поиск в исходниках соответствующих
> юридических оборотов в библиотеку SourceAnalyzer.

Я не видел ни одного проекта, который бы проверял лицензию правильно. Даже
в гугле [1] считают расстояние левенштейна для текстов лицензий.

[1] https://github.com/google/licenseclassifier/

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

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

> Хорошо, хоть перед внесением изменений в sisyphus_check
> было письмо в devel@, хоть какие-то приличия были соблюдены.
> Но отсутствие официальной документации не есть гуд.
> Без нее люди по пути наименьшего сопротивления подберут
> простейший вариант, лишь бы sisyphus_check не шумел.
> Робот здесь в тему, он сможет проверить за людьми.

Я уверен, что не сможет.

> Это Дмитрий, вам укор, что разводите бардак вместо ordung'а.

Про лицензии вам корить нужно меня, а не Диму. Так что этот упрёк тоже не
по адресу. Скорее, если бы этой темой занимался он, то всё было бы сделано
правильно.

-- 
Rgrds, legion

Re: [devel] automatic License

[Igor Vlasenko]

On Sun, Aug 30, 2020 at 12:09:17PM +0200, Alexey Gladkov wrote:
> > Гм. действительно. Вылетело из головы, когда писал.
> > Надо будет добавить поиск в исходниках соответствующих
> > юридических оборотов в библиотеку SourceAnalyzer.
> 
> Я не видел ни одного проекта, который бы проверял лицензию правильно. Даже
> в гугле [1] считают расстояние левенштейна для текстов лицензий.
> [1] https://github.com/google/licenseclassifier/

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

В отличие от гугла, мне нужен не полный охват,
а охват типичных случаев. Нетипичные слусаи можно обработать и вручную.

-- 

I V

Re: [devel] automatic License

[Alexey Gladkov]

On Sun, Aug 30, 2020 at 03:44:23PM +0300, Igor Vlasenko wrote:
> On Sun, Aug 30, 2020 at 12:09:17PM +0200, Alexey Gladkov wrote:
> > > Гм. действительно. Вылетело из головы, когда писал.
> > > Надо будет добавить поиск в исходниках соответствующих
> > > юридических оборотов в библиотеку SourceAnalyzer.
> > 
> > Я не видел ни одного проекта, который бы проверял лицензию правильно. Даже
> > в гугле [1] считают расстояние левенштейна для текстов лицензий.
> > [1] https://github.com/google/licenseclassifier/
> 
> Спасибо, занес себе в закладки.
> Но расстояние левенштейна это для всяких патологических
> случаев, вроде MIT-подобных лицензий, и то,
> для их прореживания есть рабочие хаки.

Расстояние левенштейна не подходит совсем для лицензий. Если я в лицензию
добавлю три символа ("permitted" -> "not permitted"), то лицензия
изменится на противоположную, а расстояние левенштейна будет утверждать,
что тексты на 99% одинаковые.

> В отличие от гугла, мне нужен не полный охват,
> а охват типичных случаев. Нетипичные слусаи можно обработать и вручную.

В этом плане 'diff -wB ...' будет вести себя правильнее при условии
дополнительной обработки адресов и синонимов.

А вот если лицензий больше одной, то будет очень сложно понять это "и" или
"или".

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

-- 
Rgrds, legion

Re: [devel] automatic License

[Michael Shigorin]

On Sun, Aug 30, 2020 at 05:21:34PM +0200, Alexey Gladkov wrote:
> Если за роботом всё равно нужно будет перепроверять (а это нужно будет
> делать в любом случае), то в таком роботе я не вижу смысла.

Как с buildreq? :)

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] automatic License

[Alexey Gladkov]

On Sun, Aug 30, 2020 at 06:36:20PM +0300, Michael Shigorin wrote:
> On Sun, Aug 30, 2020 at 05:21:34PM +0200, Alexey Gladkov wrote:
> > Если за роботом всё равно нужно будет перепроверять (а это нужно будет
> > делать в любом случае), то в таком роботе я не вижу смысла.
> 
> Как с buildreq? :)

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

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

-- 
Rgrds, legion

Re: [devel] automatic License

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 6095 bytes --]

On Sun, 30 Aug 2020 17:21:34 +0200 Alexey Gladkov wrote:
> On Sun, Aug 30, 2020 at 03:44:23PM +0300, Igor Vlasenko wrote:
> > On Sun, Aug 30, 2020 at 12:09:17PM +0200, Alexey Gladkov wrote:
> > > > Гм. действительно. Вылетело из головы, когда писал.
> > > > Надо будет добавить поиск в исходниках соответствующих
> > > > юридических оборотов в библиотеку SourceAnalyzer.
> > > 
> > > Я не видел ни одного проекта, который бы проверял лицензию правильно. Даже
> > > в гугле [1] считают расстояние левенштейна для текстов лицензий.
> > > [1] https://github.com/google/licenseclassifier/
> > 
> > Спасибо, занес себе в закладки.
> > Но расстояние левенштейна это для всяких патологических
> > случаев, вроде MIT-подобных лицензий, и то,
> > для их прореживания есть рабочие хаки.
> 
> Расстояние левенштейна не подходит совсем для лицензий. Если я в лицензию
> добавлю три символа ("permitted" -> "not permitted"), то лицензия
> изменится на противоположную, а расстояние левенштейна будет утверждать,
> что тексты на 99% одинаковые.

Это легко решается весовым коэффициентом. Впрочем, Ваш пример не
реалистичный, т.к. большинство лицензий типовые.

По-моему, Ваша ошибка в том, что Вы предполагаете, что роботы будут
всегда всё разбирать. Нет, это не так. Они будут разбирать типовые
ситуации, где можно однозначно сказать (например, семейство GPL
где автор не может вставить "not" где-либо, да и вообще менять
текст лицензий). Если типовая проверка не сработает, то всё
останется на ручную работу, как и было раньше.

И, насколько я знаю, у viy все роботы примерно так сейчас
и работают: тот же logoved разбирает типовые ситуации где есть
шаблонный и однозначный алгоритм действий, а все сложные случаи
вываливаются в отдельную корзиночку.

> > В отличие от гугла, мне нужен не полный охват,
> > а охват типичных случаев. Нетипичные слусаи можно обработать и вручную.
> 
> В этом плане 'diff -wB ...' будет вести себя правильнее при условии
> дополнительной обработки адресов и синонимов.
> 
> А вот если лицензий больше одной, то будет очень сложно понять это "и" или
> "или".
> 
> Вот и получается, что тривиальные случаи мантейнер и сам без труда
> выставит, а сложные только мантейнер (и то не всегда) сможет разобрать.
> Если за роботом всё равно нужно будет перепроверять (а это нужно будет
> делать в любом случае), то в таком роботе я не вижу смысла.

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

По поводу корректности указания лицензий: для *большинства* srpm
пакетов они у нас сейчас указаны некорректно, если учитывать
случаи, когда перечислены не все лицензии. Потому что у нас by
design предполагается, что у name.rpm и name.srpm одна и та же
лицензия, что в большинстве неверно, поскольку:

а) бинарники являются результатом объединения лицензий путём
неявного перелицензирования;

б) есть лицензии на код, который используется при сборке или просто
есть в исходниках, но в бинарник не попадает: например, сборочные
скрипты или m4, которые часто отличаются от лицензии пакета и в
srpm должны быть указаны, строго говоря.

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

Разгребать это всё руками не реалистично. Да и не разребает у нас
никто. Так что разумная автоматизация улучшит процесс.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] automatic License

[Alexey Gladkov]

On Sun, Aug 30, 2020 at 06:58:24PM +0300, Andrey Savchenko wrote:
> > Расстояние левенштейна не подходит совсем для лицензий. Если я в лицензию
> > добавлю три символа ("permitted" -> "not permitted"), то лицензия
> > изменится на противоположную, а расстояние левенштейна будет утверждать,
> > что тексты на 99% одинаковые.
> 
> Это легко решается весовым коэффициентом. Впрочем, Ваш пример не
> реалистичный, т.к. большинство лицензий типовые.

Я же не истина в последней инстанции. Попробуйте подобрать этот
коэффициент и поугадывать лицензии.

> По-моему, Ваша ошибка в том, что Вы предполагаете, что роботы будут
> всегда всё разбирать. Нет, это не так. Они будут разбирать типовые
> ситуации, где можно однозначно сказать (например, семейство GPL
> где автор не может вставить "not" где-либо, да и вообще менять
> текст лицензий). Если типовая проверка не сработает, то всё
> останется на ручную работу, как и было раньше.

Для типовой ситуации есть diff -wB. Если эта проверка не прошла, то это
уже не типовой случай.

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

> И, насколько я знаю, у viy все роботы примерно так сейчас
> и работают: тот же logoved разбирает типовые ситуации где есть
> шаблонный и однозначный алгоритм действий, а все сложные случаи
> вываливаются в отдельную корзиночку.

Если робот не на 100% выполняет какую-то задачу, то за ним нужно
перепроверять. Раз я сажусь перепроверять, то по сути делаю эту работу
сам. И да, за всё время существования этих репокопов я его патчами никогда
не воспользовался потому что я открываю патч, смотрю в него, вижу ложное
срабатывание и закрываю.

> > > В отличие от гугла, мне нужен не полный охват,
> > > а охват типичных случаев. Нетипичные слусаи можно обработать и вручную.
> > 
> > В этом плане 'diff -wB ...' будет вести себя правильнее при условии
> > дополнительной обработки адресов и синонимов.
> > 
> > А вот если лицензий больше одной, то будет очень сложно понять это "и" или
> > "или".
> > 
> > Вот и получается, что тривиальные случаи мантейнер и сам без труда
> > выставит, а сложные только мантейнер (и то не всегда) сможет разобрать.
> > Если за роботом всё равно нужно будет перепроверять (а это нужно будет
> > делать в любом случае), то в таком роботе я не вижу смысла.
> 
> У больших пакетов могут быть десятки лицензий, их сложно все найти,
> нужно перечитывать все заголовки всех файлов, т.к. общие файлы вида
> LICENSES/COPYING обычно содержат не всё. Здесь роботы очень полезны
> будут.

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

> По поводу корректности указания лицензий: для *большинства* srpm
> пакетов они у нас сейчас указаны некорректно, если учитывать
> случаи, когда перечислены не все лицензии. Потому что у нас by
> design предполагается, что у name.rpm и name.srpm одна и та же
> лицензия, что в большинстве неверно, поскольку:
> 
> а) бинарники являются результатом объединения лицензий путём
> неявного перелицензирования;
> 
> б) есть лицензии на код, который используется при сборке или просто
> есть в исходниках, но в бинарник не попадает: например, сборочные
> скрипты или m4, которые часто отличаются от лицензии пакета и в
> srpm должны быть указаны, строго говоря.

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

> Мало того, для многих подпакетов у нас некорректно указаны
> лицензии, потому что подпакет часто является малым подмножеством
> общего кода и к нему применимы лишь некоторые из лицензией
> основного пакета.
> 
> Разгребать это всё руками не реалистично. Да и не разребает у нас
> никто. Так что разумная автоматизация улучшит процесс.

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

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

-- 
Rgrds, legion

Re: [devel] automatic License

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1553 bytes --]

On Sun, 30 Aug 2020 18:40:50 +0200 Alexey Gladkov wrote:
> On Sun, Aug 30, 2020 at 06:58:24PM +0300, Andrey Savchenko wrote:
> > Мало того, для многих подпакетов у нас некорректно указаны
> > лицензии, потому что подпакет часто является малым подмножеством
> > общего кода и к нему применимы лишь некоторые из лицензией
> > основного пакета.
> > 
> > Разгребать это всё руками не реалистично. Да и не разребает у нас
> > никто. Так что разумная автоматизация улучшит процесс.
> 
> К сожалению, у нас не до конца сформировано то самое пресловутое полиси на
> лицензии и то как их обозначать. Если есть желание двинуть эту тему
> вперёд, то давайте откроем новый тред.

Нужно сперва понять насколько это нужно нашему сообществу, а то уже
смотрят косо в духе "снова вы тут со своими лицензиями".
 
> Если интересно, я могу рассказать из-за чего я вообще полез в эти авгиевы
> конюшни.
 
Интересно, очень.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] automatic License

[Alexey Gladkov]

On Sun, Aug 30, 2020 at 08:27:06PM +0300, Andrey Savchenko wrote:
> > К сожалению, у нас не до конца сформировано то самое пресловутое полиси на
> > лицензии и то как их обозначать. Если есть желание двинуть эту тему
> > вперёд, то давайте откроем новый тред.
> 
> Нужно сперва понять насколько это нужно нашему сообществу, а то уже
> смотрят косо в духе "снова вы тут со своими лицензиями".
>  
> > Если интересно, я могу рассказать из-за чего я вообще полез в эти авгиевы
> > конюшни.
>  
> Интересно, очень.

Попробую ответить сразу на всё.

Я исследовал идею сделать зеркало нашего git.alt на github так как у меня
очень богатый опыт работы с последним.

Встал сугубо практичный вопрос: какие репозитории можно публиковать там?
Поскольку не хотелось подставляться и организацию не подставить.

Я начал смотреть, а что же у нас есть под свободной лицензией и
выяснилось, что у нас совсем нет информации об этом. В некоторых случаях
нет вообще никакой информации о том под какой лицензией пакет или же прямо
написано 'Distributable (Unknown)'. Я подробно уже писал об этом и не буду
ещё раз писать про пассажи в тэге License.

Ок, подумал, может я чего-то не знаю. Поскольку задача не уникальна я
поговорил как эту задачу решают дистрибутивостроители. Как они решают,
какие пакеты можно класть в альтовый дистрибутив или решение, ведь у нас
есть пакеты с 'non-commercial use'. Выяснилось, что у нас это делается это
хитрыми grep'ами по тэгу license и последующей обработкой т.е. это
довольно ощутимая боль.

Несмотря на то, что идея с github c треском провалилась вопрос
лицензионной чистоты остался. Мы можем хорошо так подставиться и под "мы"
я имею мы в виду широком смысле - мы - компании, делающие решения на
основе этой пакетной базы, мы - пользователи (не все пакеты я могу ставить
к себе на ноут). Думаю, мысль понятна.

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

-- 
Rgrds, legion

Re: [devel] automatic License

[Michael Shigorin]

On Sun, Aug 30, 2020 at 08:15:52PM +0200, Alexey Gladkov wrote:
> > > Если интересно, я могу рассказать из-за чего я вообще полез
> > > в эти авгиевы конюшни.
> > Интересно, очень.
> Я исследовал идею сделать зеркало нашего git.alt на github

Так понятней, спасибо.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] automatic License

[Igor Vlasenko]

On Sun, Aug 30, 2020 at 12:09:17PM +0200, Alexey Gladkov wrote:
> Про лицензии вам корить нужно меня, а не Диму. Так что этот упрёк тоже не
> по адресу. Скорее, если бы этой темой занимался он, то всё было бы сделано
> правильно.

Если решите заняться написанием странички полиси,
обратите, пожалуйста, внимание, что есть такая страница
https://www.altlinux.org/License_Tag_Policy
ее надо либо удалить, либо стереть мусор и взять за основу.

> > Но отсутствие официальной документации не есть гуд.
> > Без нее люди по пути наименьшего сопротивления подберут
> > простейший вариант, лишь бы sisyphus_check не шумел.
> > Робот здесь в тему, он сможет проверить за людьми.
> Я уверен, что не сможет.

А вы опишите проблему на страничке полиси.
так, чтобы даже робот понял :)

P.S.
Мужик, проходя мимо забора воинской части, слышит странные команды:
– Зеленым вверх! Зеленым вверх! Вверх зеленым, я сказал!
Удивился мужик и посмотрел в щелочку, а это оказалось солдаты под предводительством прапора сажают деревья

-- 

I V

Re: [devel] will be fatal in Perl 5.30

[Dmitry V. Levin]

On Thu, Aug 27, 2020 at 05:29:53AM +0300, Igor Vlasenko wrote:
[...]
> Но вместо обновления получился цирк, так как Дмитрий
> продолжил мне помогать, а я слова не мог сказать, поскольку
> боялся поддаться эмоциям и начать выражаться нецензурно.
> Получилась история, когда к Кролику пришел в гости Винни Пух.
> Что по этому поводу подумал Кролик, так и осталось тайной.
> Дмитрий в простоте своей умудрился еще раз на бис
> прервать сборку транзакции, после чего сам смысл пытаться обновить perl
> стал под большим вопросом, а потом и вообще "застрял в норе,
> закупорив вход" --- обновление оказалось невозможным без починки пакета sdf,
> пакета с жестким acl=ldv, о чем Дмитрий даже написал в рассылке,
> но как-то чинить пакет или открывать acl не стал.

Игорь, вот моё письмо:
https://lists.altlinux.org/pipermail/devel/2020-April/210720.html

Оно не про sdf, оно про все пакеты, которые гарантированно сломаются
при обновлении perl до версии >= 5.30.

Это письмо было отправлено 4 месяца назад.
Тогда в списке пакетов "will be fatal in Perl 5.30" было 16 пакетов.
Сейчас в Сизифе таких пакетов 15 (спасибо grenka@ за исправление gnuplot),
прогресс налицо.

Но виноват, конечно, Дмитрий, который не открыл acl на sdf.

Игорь, а давайте поставим эксперимент?  Я перевешу пакет sdf на вас,
и мы посмотрим, как быстро вы его исправите.  Идёт?


-- 
ldv

Re: [devel] will be fatal in Perl 5.30

[Michael Shigorin]

On Fri, Aug 28, 2020 at 09:26:03PM +0300, Dmitry V. Levin wrote:
> Игорь, а давайте поставим эксперимент?  Я перевешу пакет sdf на вас,
> и мы посмотрим, как быстро вы его исправите.  Идёт?

Ты забыл извиниться за неконституционное вмешательство в чужие задания
и пообещать, что больше так не будешь.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] will be fatal in Perl 5.30

[Dmitry V. Levin]

On Fri, Aug 28, 2020 at 10:46:59PM +0300, Michael Shigorin wrote:
[...]
> Ты забыл извиниться за неконституционное вмешательство в чужие задания
> и пообещать, что больше так не будешь.

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


-- 
ldv

Re: [devel] will be fatal in Perl 5.30

[Michael Shigorin]

On Fri, Aug 28, 2020 at 10:58:34PM +0300, Dmitry V. Levin wrote:
> > Ты забыл извиниться за неконституционное вмешательство
> > в чужие задания и пообещать, что больше так не будешь.
> Миша, когда ты повторяешь чужие выдумки, не разобравшись
> в предмете, то у тебя складывается такая репутация, что потом,
> когда ты скажешь что-нибудь более обоснованное, тебя уже не
> воспринимают всерьёз.

Бывает и такое, порой меня подводят люди, которым доверяю.

Но слова Игоря о том, что обе крупных транзакции по обновлению
perl были прерваны тобой (в одном из случаев -- с благим
пожеланием перетащить на rebuild), тобой опровергнуты не были,
из чего я сделал вывод, что так и было.

Если было иначе -- расскажи по возможности своё понимание,
мне важно.  Сами задания сходу в sisyphus-incominger@ не нашёл,
по ~s FAILED ~h viy@ ~h perl\.git вижу только #250536, которое
споткнулось на "$* is no longer supported as of Perl 5.30 at
/usr/share/perl5/sdf/subs.pl line 624".

Игорь, ты часом не это принял за вмешательство Димы?

http://lists.altlinux.org/pipermail/sisyphus-incominger/2020-April/568629.html

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] will be fatal in Perl 5.30

[Dmitry V. Levin]

On Fri, Aug 28, 2020 at 11:19:10PM +0300, Michael Shigorin wrote:
> On Fri, Aug 28, 2020 at 10:58:34PM +0300, Dmitry V. Levin wrote:
> > > Ты забыл извиниться за неконституционное вмешательство
> > > в чужие задания и пообещать, что больше так не будешь.
> > Миша, когда ты повторяешь чужие выдумки, не разобравшись
> > в предмете, то у тебя складывается такая репутация, что потом,
> > когда ты скажешь что-нибудь более обоснованное, тебя уже не
> > воспринимают всерьёз.
> 
> Бывает и такое, порой меня подводят люди, которым доверяю.
> 
> Но слова Игоря о том, что обе крупных транзакции по обновлению
> perl были прерваны тобой (в одном из случаев -- с благим
> пожеланием перетащить на rebuild), тобой опровергнуты не были,
> из чего я сделал вывод, что так и было.
> 
> Если было иначе -- расскажи по возможности своё понимание,
> мне важно.  Сами задания сходу в sisyphus-incominger@ не нашёл,
> по ~s FAILED ~h viy@ ~h perl\.git вижу только #250536, которое
> споткнулось на "$* is no longer supported as of Perl 5.30 at
> /usr/share/perl5/sdf/subs.pl line 624".

Моё вмешательство было ограничено
- письмами:
  https://lists.altlinux.org/pipermail/devel/2020-April/210502.html
  https://lists.altlinux.org/pipermail/devel/2020-April/210689.html
  https://lists.altlinux.org/pipermail/devel/2020-April/210720.html
  https://lists.altlinux.org/pipermail/devel/2020-April/210721.html
  https://lists.altlinux.org/pipermail/devel/2020-April/210722.html
- доработкой rpm-build-perl:
  https://lists.altlinux.org/pipermail/devel/2020-April/210707.html
- одним явным disapprove:

----- Forwarded message from Girar task disapprove <girar-task-disapprove@altlinux> -----

Date: Sat, 4 Apr 2020 16:12:11 +0000
From: Girar task disapprove <girar-task-disapprove@altlinux>
To: Igor Vlasenko <viy@altlinux>
Cc: girar-task-approve-sisyphus@altlinux
Subject: [#249391] ldv has added disapproval of subtask #2000

Dear Igor Vlasenko!

Dmitry V. Levin has added a disapproval of subtask #2000 of task #249391:
2000:00-tmp-vim.git=8.2.0011-alt1.1

The text of disapproval follows:

NAK: "rebuild with new perl 5.30.2" does not require a release bump.

-- 
http://git.altlinux.org/tasks/249391

----- End forwarded message -----


-- 
ldv

Re: [devel] will be fatal in Perl 5.30

[Dmitry V. Levin]

On Sat, Aug 29, 2020 at 01:11:30AM +0300, Dmitry V. Levin wrote:
> On Fri, Aug 28, 2020 at 11:19:10PM +0300, Michael Shigorin wrote:
> > On Fri, Aug 28, 2020 at 10:58:34PM +0300, Dmitry V. Levin wrote:
> > > > Ты забыл извиниться за неконституционное вмешательство
> > > > в чужие задания и пообещать, что больше так не будешь.
> > > Миша, когда ты повторяешь чужие выдумки, не разобравшись
> > > в предмете, то у тебя складывается такая репутация, что потом,
> > > когда ты скажешь что-нибудь более обоснованное, тебя уже не
> > > воспринимают всерьёз.
> > 
> > Бывает и такое, порой меня подводят люди, которым доверяю.
> > 
> > Но слова Игоря о том, что обе крупных транзакции по обновлению
> > perl были прерваны тобой (в одном из случаев -- с благим
> > пожеланием перетащить на rebuild), тобой опровергнуты не были,
> > из чего я сделал вывод, что так и было.
> > 
> > Если было иначе -- расскажи по возможности своё понимание,
> > мне важно.  Сами задания сходу в sisyphus-incominger@ не нашёл,
> > по ~s FAILED ~h viy@ ~h perl\.git вижу только #250536, которое
> > споткнулось на "$* is no longer supported as of Perl 5.30 at
> > /usr/share/perl5/sdf/subs.pl line 624".
> 
> Моё вмешательство было ограничено
> - письмами:
>   https://lists.altlinux.org/pipermail/devel/2020-April/210502.html
>   https://lists.altlinux.org/pipermail/devel/2020-April/210689.html
>   https://lists.altlinux.org/pipermail/devel/2020-April/210720.html
>   https://lists.altlinux.org/pipermail/devel/2020-April/210721.html
>   https://lists.altlinux.org/pipermail/devel/2020-April/210722.html
> - доработкой rpm-build-perl:
>   https://lists.altlinux.org/pipermail/devel/2020-April/210707.html
> - одним явным disapprove:

Запамятовал, не одним, а несколькими явными disapprove, один из которых
я тут процитировал.

> ----- Forwarded message from Girar task disapprove <girar-task-disapprove@altlinux> -----
> 
> Date: Sat, 4 Apr 2020 16:12:11 +0000
> From: Girar task disapprove <girar-task-disapprove@altlinux>
> To: Igor Vlasenko <viy@altlinux>
> Cc: girar-task-approve-sisyphus@altlinux
> Subject: [#249391] ldv has added disapproval of subtask #2000
> 
> Dear Igor Vlasenko!
> 
> Dmitry V. Levin has added a disapproval of subtask #2000 of task #249391:
> 2000:00-tmp-vim.git=8.2.0011-alt1.1
> 
> The text of disapproval follows:
> 
> NAK: "rebuild with new perl 5.30.2" does not require a release bump.
> 
> -- 
> http://git.altlinux.org/tasks/249391
> 
> ----- End forwarded message -----


-- 
ldv

Re: [devel] will be fatal in Perl 5.30

[Igor Vlasenko]

On Fri, Aug 28, 2020 at 11:19:10PM +0300, Michael Shigorin wrote:
> Но слова Игоря о том, что обе крупных транзакции по обновлению
> perl были прерваны тобой (в одном из случаев -- с благим
> пожеланием перетащить на rebuild), тобой опровергнуты не были,
> из чего я сделал вывод, что так и было.
> 
> Игорь, ты часом не это принял за вмешательство Димы?

нет, именно отмены ручками. Дима в соседнем письме вспомнил.

-- 

I V

Re: [devel] will be fatal in Perl 5.30

[Igor Vlasenko]

On Fri, Aug 28, 2020 at 09:26:03PM +0300, Dmitry V. Levin wrote:
> Сейчас в Сизифе таких пакетов 15 (спасибо grenka@ за исправление gnuplot),
> прогресс налицо.
> Но виноват, конечно, Дмитрий, который не открыл acl на sdf.

Они не блокируют процесс сборки perl 5.30,
просто после попадания perl 5.30 уйдут в FTBFS.
а вот пакет sdf блокирует -- при пересборке
openldap c perl 5.30 используется sdf :(
 
> Игорь, а давайте поставим эксперимент?  Я перевешу пакет sdf на вас,
> и мы посмотрим, как быстро вы его исправите.  Идёт?

исправил еще вчера, так что эксперимент не выйдет.

кстати, вот еще один перловый пакет в аналогичной ситуации
с залоченным acl: 
grepmail        at ldv
Алексей отошел от perl, стало быть, вы майнтайнер и acl разлочивать вам.
Этот пакет 5 лет нуждается в обновлении.

Можно провести эксперимент на нем.

-- 

I V