Разработчики Debian подвели (https://lists.debian.org/debian-devel-announce/2015/02/msg00...) первые итоги инициативы (https://wiki.debian.org/ReproducibleBuilds) по обеспечению повторяемых сборок пакетов. Обеспечение повторяемости сборки подтверждает, что исполняемый файл собран именно из заявленных исходных текстов и не содержит посторонние закладки, которые, например, могут быть интегрированы в результате использования поражённого в результате атаки компилятора или сборочного инструментария.
В настоящее время повторяемость сборок достигнута для 83.5% пакетов, представленных в репозитории main. Любой пользователь можно лично убедиться, что предлагаемый дистрибутивом бинарный пакет байт в байт совпадает с пакетом, собранным им лично из исходных текстов. Без возможности проверить тождественность бинарной сборки пользователю остаётся лишь слепо доверять сборочной инфраструктуре дистрибутива.<center><a href="https://reproducible.debian.net/reproducible.html">&... src="http://www.opennet.me/opennews/pics_base/0_1423897628.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
На первый взгляд обеспечение повторяемости является достаточно простой задачей, но на деле требуется учитывать множество нюансов, в результате которых при сборке одного и того же исходного кода на выходе получаются не идентичные бинарные файлы. Главным образом различия вызваны непостоянством состава сборочного окружения и добавлением в файл меняющейся во времени информации, такой как данные о дате сборки. Для обеспечения повторяемости необходимо полностью воссоздать эталонное сборочное окружение, использовать те же версии сборочного инструментария, идентичных набор опций и настроек по умолчанию, применять те же методы сортировки списков файлов.
Для оценки различий бинарных пакетов подготовлена специальная утилита debbindiff (https://packages.debian.org/sid/debbindiff), позволяющая детально проанализировать различия. Для многих сборочных инструментов подготовлены патчи (https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolc...), в основном связанные с отключением добавления информации о времени сборки. Для контроля за отклонениями в повторяемости сборки введены в строй (https://jenkins.debian.net/view/reproducible/) несколько систем пересборки пакетов в репозитории unstable, построенных с использованием системы непрерывной интеграции Jenkins и запущенных на разных серверах, настройки и начинка которых отличаются.
URL: https://lists.debian.org/debian-devel-announce/2015/02/msg00...
Новость: http://www.opennet.me/opennews/art.shtml?num=41670
Паранойя это хорошо.
Паранойя, которая не требует от меня никаких телодвижений и не причиняющая неудобств -- это просто офигенно.
А Дебиан ещё лучше:)
А Дебиан без systemd это просто настолько идеально, что именно поэтому и не существует:)
> А Дебиан ещё лучше:)Рад, что и в дебиане наконец-то допёрли до воспроизводимости сборки ;-)
И где же еще это реализовано?Только не надо ваши alt и прочие росы. Ну где ваш патч для libxslt, или этой библиотеки в alt нету?
Какоё ещй патч или имеется ввиду alt patch ? Дык есть оно, как и сама библиотека http://packages.altlinux.org/en/Sisyphus/srpms/libxslt
> Какоё ещй патч или имеется ввиду alt patch?Аналогичный тому, что наваяли для дебиановского пакету.
> Дык есть оно,
> как и сама библиотека http://packages.altlinux.org/en/Sisyphus/srpms/libxsltЭто я успел заметить, как и то что ничего похожего там не обнаруживается.
2013 год... И почему эти патчи до сих пор не в апстриме, дебиан вообще с апстримом работает ?
> 2013 год...Мухоморы еш?
> И почему эти патчи до сих пор не в апстриме
Может потому что обсуждаемый патч датирован январем 2015-го?
> Может потому что обсуждаемый патч датирован январем 2015-го?Он вообще туда не попадёт, как и остальные патчи, потому что:
1) указанные патчи с обычной страницы пакета на packages.debian до сих пор не в апстриме
2) патч почти наверняка завязан на систему сборки и тестирования
>> 2013 год...
> Мухоморы еш?Зайди на packages.debian и погляди на пакет из wheeze. Анстэйбл как и анрелизы не интересуют. РЕчь о патчах с wheeze, которые до сих пор в апстрим не попали.
> еш?Граммар наци, тащи ружье!
*ешь?
И зачем этот патч нужен в альте, где есть своя система безопасной и воспроизводимой сборки пакетов.
> И зачем этот патч нужен в альте, где есть своя система безопасной
> и воспроизводимой сборки пакетов.В этой задачке есть разные аспекты.
Например ?
> Например ?Содержимое пакетов порождают не только компиляторы -- это и конфигурационные, графические файлы, документация. Соответствующие генераторы/конверторы также могут заниматься проставлением временнЫх меток или попросту порождать невоспроизводимый результат.
Например, с помощью альтовской сборочницы была замечена разница в выхлопе graphviz (подозревают cairo) на x86_64 и i586. Это не совсем та же задача, но смежная.
> Например, с помощью альтовской сборочницы была замечена разница в выхлопе graphviz (подозревают
> cairo) на x86_64 и i586. Это не совсем та же
> задача, но смежная.Так ваш "реализатор" уже реализовал патч для этого или только ограничился замечанием? Если последнее - о какой вообще "реализации" может идти речь?
> Так ваш "реализатор" уже реализовал патч для этого или только ограничился замечанием?Некритично (собственно, всплыло при проверке archdep, которая ранее была разработана при обдумывании -- а из какой именно сборки брать noarch).
> Если последнее - о какой вообще "реализации" может идти речь?
Вы перепутали реализацию необходимых условий в технологии и реализацию контроля решения конкретной задачи. В альте озадачились первым, а эта новость -- в первую очередь про второе. Первое фундаментально, но без второго невозможно гарантировать результат.
Там ещё параллельная/последовательная сборка дальше вылезет...
>> Так ваш "реализатор" уже реализовал патч для этого или только ограничился замечанием?
> НекритичноКритично, если понимать воспроизводимость как Debian.
> Вы перепутали реализацию необходимых условий в технологии и реализацию контроля решения
> конкретной задачи. В альте озадачились первым, а эта новость --
> в первую очередь про второе.Вообще-то, новость - про решение практической задачи. Для этого и toolchain патчи написали, и фиксы для отдельных пакетов. Врать потому что - нехорошо. Раз в альте нет реальной воспроизводимости для 100% пакетов, так и не пиши что есть.
А наш пресс-релиз будет потом, когда архив (100%) будут тестировать в штатном порядке.
О какой "воспроизводимости дебиана" тогда ты говоришь, если это касается только анстейбла и стабильные версии это не затрагивает ? Врать, между прочим, нехорошо как и выдавать желаемое за действительное.
> Критично, если понимать воспроизводимость как Debian.Выдохните, успокойтесь, перечитайте. Мне весьма интересно, что получится в дебиане и на какие они _ещё_ грабли наступят -- но _эта_ грабля лежит на параллельной тропинке (между архитектурами), а не именно на той, которая про обеспечение воспроизводимой сборки на _конкретной_ архитектуре (не рассматривая другие). Привёл как пример неожиданностей.
> А наш пресс-релиз будет потом, когда архив (100%) будут тестировать в штатном порядке.
Надеюсь дожить. :)
> И зачем этот патч нужен в альте, где есть своя система безопасной
> и воспроизводимой сборки пакетов.Очень любопытно почему этот патч не нужен в такой "шиштеме".
>> И зачем этот патч нужен в альте, где есть своя система безопасной
>> и воспроизводимой сборки пакетов.
> Очень любопытно почему этот патч не нужен в такой "шиштеме".Сначала про снапшоты чего-нибудь ответь, а потом уже кричи, что дебиан везде первый и все остальные системы раскидал :)
> Сначала про снапшоты чего-нибудь ответь, а потом уже кричи, что дебиан везде
> первый и все остальные системы раскидал :)1) такого утверждения и не было;
2) нет смысла препираться, есть смысл обмениваться опытом и соображениями.
>> Сначала про снапшоты чего-нибудь ответь, а потом уже кричи, что дебиан везде
>> первый и все остальные системы раскидал :)
> 1) такого утверждения и не было;
> 2) нет смысла препираться, есть смысл обмениваться опытом и соображениями.Согласен полностью, но только не в такой манере, какую демонстрирует конкретно этот весь из себя такой дебиановец, ставя всех остальных (в том числе анонимов) в разряд каких-то тупиц и недоумков.
>> Сначала про снапшоты чего-нибудь ответь, а потом уже кричи, что дебиан везде
>> первый и все остальные системы раскидал :)
> 1) такого утверждения и не было;Было другое утверждение: то что ни в ALT, ни в прочих ваших РОСАх - ничего подобного пока не реализовано. В федоре это тоже примерно на том же уровне, что и в Debian.
> 2) нет смысла препираться
Нет смысла врать. Если в ALT имеет место "мы работаем над проблемой" - так и следует честно написать. Нечего стыдиться - никто (ну, насколько я знаю) этого еще не сделал, включая Debian.
> Было другое утверждение: то что ни в ALT, ни в прочих ваших
> РОСАх - ничего подобного пока не реализовано.Это утверждение ложное, т.к. дебиан в плане обеспечения воспроизводимости сборок _в принципе_ отстаёт от альта лет на пять. В фундаментальном, а не деталях.
>> 2) нет смысла препираться
> Нет смысла врать.Вот и не врите. Приходите поучиться, мы ведь не прячем наработки.
>> Было другое утверждение: то что ни в ALT, ни в прочих ваших
>> РОСАх - ничего подобного пока не реализовано.
> Это утверждение ложное, т.к. дебиан в плане обеспечения воспроизводимости сборок _в принципе_
> отстаёт от альта лет на пять. В фундаментальном, а не деталях.Бездоказательные утверждения, особенно такие громкие, я плохо воспринимаю и обычно интересуюсь как раз "деталями". Нет, пока анонсированного "прорыва" - не увидел.
> обычно интересуюсь как раз "деталями"Потому и сказал -- где искать, кого спрашивать. Кстати, dottedmag@{debian,altlinux} может оказаться достаточно компетентным "мостиком" между проектами именно в этом плане.
> Вот и не врите.Как вам уже сказал Прокудин, альт совершенно не умеет донести до ALL что и, главное, нафига там делается. Поэтому он обречен жить с такими претензиями.
> Приходите поучиться, мы ведь не прячем наработки.
Специально может и не прячете. Но мало у кого есть в жизни цель вытаскивать из вас ваши сильные стороны клещами. Вот и...
> Как вам уже сказал Прокудин, альт совершенно не умеет донести до ALL
> что и, главное, нафига там делается. Поэтому он обречен жить с
> такими претензиями.Вопрос не в том, что "умеет или не умеет". Вопрос в том, что никто не интересуется. Уткнулись каждый в своё болото и нахваливают, стараясь по-меньше оглядываться и непременно периодически при этом подкалывать своих "соседей" (людей, использующих отличные от вашего дистрибутивы).
> Специально может и не прячете. Но мало у кого есть в жизни цель вытаскивать из вас ваши сильные стороны клещами. Вот и...Скажите честно, что фраза "Но мало у кого есть в жизни цель вытаскивать из вас ваши сильные стороны клещами" должна была звучать несколько иначе "Но мало у кого есть в жизни цель оглядываться по сторонам в поиске сильных сторон других тысяч дистрибутивов в то самое время, когда над каждым давлеют мифы и штампы о тех или иных дистрибутивах, которым иной раз много лет, но по каким-то причинам каждому не хватает времени/силы воли/ума с ними разобраться и разобраться с этим".
> Вопрос в том, что никто не интересуется.Ну почему, разработчики порой поддерживают контакты, хотя здесь поле непаханое.
> Уткнулись каждый в своё болото и нахваливают, стараясь по-меньше оглядываться
> и непременно периодически при этом подкалывать своих "соседей"
> (людей, использующих отличные от вашего дистрибутивы).Пользователю подкалывать смысла мало, разве что выпендриться. То есть единственный конструктивный вариант, который в таком случае может возникнуть -- это когда пользователю одного дистрибутива разработчик другого дистрибутива что-то нетривиальное рассказал по теме, которой занимаются разработчики первого дистрибутива; если тот пользователь им это сможет донести, не сильно переврав, а им услышанное покажется стоящим дальнейших раскопок и расспросов. Причём перевирание тут не вследствие злонамерения, а вследствие непонимания предметной области и того, какие вопросы будут правильные и что именно значат ответы.
>> Специально может и не прячете. Но мало у кого есть в жизни цель вытаскивать
>> из вас ваши сильные стороны клещами. Вот и...Спасибо, добавил пункт к http://altlinux.org/features со ссылкой на тезисы.
> "Но мало у кого есть в жизни цель оглядываться по сторонам в поиске сильных сторон
> других тысяч дистрибутивов ..."Можно и короче -- "жизнь коротка". :)
>>> Специально может и не прячете. Но мало у кого есть в жизни цель вытаскивать
>>> из вас ваши сильные стороны клещами. Вот и...
> Спасибо, добавил пункт к http://altlinux.org/features со ссылкой на тезисы.Для справки, в тезисах - ни слова про определение воспроизводимости.
> Для справки, в тезисах - ни слова про определение воспроизводимости.Потому и предложил расспросить ldv@ при необходимости.
PS: если кому интересно по той же сертификации -- на альте довольно удобно делать продукты, которые затем можно предоставлять вместе со сборочной системой для предъявления этой самой пересборки.
>> Для справки, в тезисах - ни слова про определение воспроизводимости.
> Потому и предложил расспросить ldv@ при необходимости.Не логично-ли это сделать своим, чтобы не лепить в features странное?
> Не логично-ли это сделать своим, чтобы не лепить в features странное?Логично, конечно. Как и очень многое другое, что ещё только предстоит сделать.
>> Не логично-ли это сделать своим, чтобы не лепить в features странное?
> Логично, конечно. Как и очень многое другое, что ещё только предстоит сделать.Пеар - так пеар, moar так moar, чо. Правильной дорогой идете, товарищи!
В Gentoo.
> И где же еще это реализовано?В альте давно уж.
> Только не надо ваши alt
А где архив снапшотов дебиана, причём не по дням, а по сборкам? Без этого надо быть тем ещё лопухом, чтоб говорить о воспроизводимости окружения. Ну или сильно трудолюбивым человеком, если логи формирования сборочных чрутов (т.е. состав пакетов вплоть до версий) фиксируется.
>> И где же еще это реализовано?
> В альте давно уж."Байт в байт" и проч., или как-то еще "воспроизводимость" определяется?
> "Байт в байт" и проч., или как-то еще "воспроизводимость" определяется?Лучше с ldv@ потолковать, если есть прикладной интерес. Или поднять его тезисы на летних конференциях в Обнинске лет пять-восемь тому.
Текущую систему -- с квантованным переходом состояния репозитория от задания к заданию -- дизайнил at@, на эту тему тоже была статья в тезисах.
Ещё заинтересованным может быть полезно найти Сергея Кубушина (KSI), но то были давние дела и насколько понимаю -- уже неактуальные в связи с тем, что gcc подправили.
>> "Байт в байт" и проч., или как-то еще "воспроизводимость" определяется?
> Лучше с ldv@ потолковать, если есть прикладной интерес. Или поднять его
> тезисы на летних конференциях в Обнинске лет пять-восемь тому. [...]Ответ на вопрос - "не знаю", я правильно понял?
Если бы "байт в байт", то, насколько я понимаю, вы уперлись бы в тот же цитированный выше патч. Раз не уперлись - либо добрая половина репа (libxslt это вам не это!) тестами не покрыта, либо "воспроизводимость" у вас существенно отличается от "байт в байт".
В любом случае, "в альте давно уж" - выглядит "преувеличением" (ц). Аристотель соврать не даст.
> Ответ на вопрос - "не знаю", я правильно понял?Да.
> Если бы "байт в байт", то, насколько я понимаю, вы уперлись бы
> в тот же цитированный выше патч. Раз не уперлись -
> либо добрая половина репа (libxslt это вам не это!)Сомнения берут насчёт "доброй половины", как минимум по моим пакетам _генерация_ чего-либо с применением XSLT штука нечастая.
> В любом случае, "в альте давно уж" - выглядит "преувеличением" (ц)
Как полагаете, проще патч к библиотеке приложить или обеспечить возможность воспроизвести сборочное окружение на N лет назад?
Если интересно, поразглядывайте архив по ссылкам с http://altlinux.org/archive
> Сомнения берут насчёт "доброй половины", как минимум по моим пакетам _генерация_ чего-либо
> с применением XSLT штука нечастая.По popcon - довольно популярный пакетик, но мимо него промахнулись... Маловато, конечно, для статистики, но.
>> Сомнения берут насчёт "доброй половины", как минимум по моим пакетам _генерация_
>> чего-либо с применением XSLT штука нечастая.
> По popcon - довольно популярный пакетик, но мимо него промахнулись...Вы понимаете, где popcon, а где сборочные окружения?
Я подразумеваю, что реализуя поддержку воспроизводимых сборок - ее авторы обратят внимание прежде всего на популярные пакеты (в deb есть еще заголовок Priority на подобную тему). И лишь констатировал, что аналогичный пакет в ALT, похоже, "обошли вниманием".sphinx также пропущен. Хочешь я угадаю, что будет если я захочу пройтись по всем патчам, перечисленным в https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolc... ?
> Я подразумеваю, что реализуя поддержку воспроизводимых сборок - ее авторы обратят
> внимание прежде всего на популярные пакеты (в deb есть еще заголовок Priority
> на подобную тему).Пожалуйста, _внимательно_ перечитайте https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolc... и расскажите, как поняли -- _зачем_ это было сделано.
Не к нужности или ненужности -- мне-то цель понятна и она вполне осмысленная. Но как её понимаете Вы?
> Пожалуйста, _внимательно_ перечитайте https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolc...
> и расскажите, как поняли -- _зачем_ это было сделано.Зачем? Инфраструктурные пакеты - пропатчили для обеспечения возможности воспроизводимой сборки. Прикладные - для воспроизводимости. В каждом случае грабли могут быть иные, некоторые типовые причины там перечислены.
Конкретно патч для libxslt - для обеспечения воспроизводимой сборки документации с использованием libxslt.
>> расскажите, как поняли -- _зачем_ это было сделано.
> пропатчили для обеспечения возможности воспроизводимой сборки.
> Конкретно патч для libxslt - для обеспечения воспроизводимой сборки документации
> с использованием libxslt.Правильно; как полагаете, многие ли пакеты собирают документацию с использованием libxslt?
> Правильно; как полагаете, многие ли пакеты собирают документацию с использованием libxslt?Порядочно, гномовские пакеты например.
>> Правильно; как полагаете, многие ли пакеты собирают документацию
>> с использованием libxslt?
> Порядочно, гномовские пакеты например.Не только (собственно, к моему mkimage-profiles собирает asciidoc -> fop -> libxslt). Но на глаз и по опыту -- относительно немного (в прикладном смысле для результата главное, что это не код, а для инфраструктуры -- что "лечится" в одной точке).
Теперь возвращаемся к #94 и понимаем, что важность выяснения и подобной доработки таких пакетов-генераторов не в "популярности" среди пользователей (бишь по меркам popcon), а в том, насколько часто они встречаются в сборочной среде. На самом деле и это оценка сверху, т.к. такой генерат может и не попасть в итоговые пакеты, но это уже издержки.
>>> Правильно; как полагаете, многие ли пакеты собирают документацию
>>> с использованием libxslt?
>> Порядочно, гномовские пакеты например.
> Не только (собственно, к моему mkimage-profiles собирает asciidoc -> fop -> libxslt).Да, не только.
> Но на глаз и по опыту -- относительно немного (в
> прикладном смысле для результата главное, что это не код, а для
> инфраструктуры -- что "лечится" в одной точке).Одного гнома - более чем много. Ну а для того, чтобы не судить на глаз - есть всякие popcon и, того хуже, build-depends (конечно, это более правильная метрика, но тут не тот случай когда два показателя не коррелируют). Важный это пакет, важный.
> Одного гнома - более чем много. Ну а для того, чтобы
> не судить на глаз - есть всякие popconУф... нет.
> и, того хуже, build-depends
Частично да -- в них может оказаться тот же asciidoc, но не оказаться libxslt в явном виде. Поэтому правильней говорить всё-таки о составе сборочного окружения.
> (конечно, это более правильная метрика, но тут не тот случай
> когда два показателя не коррелируют).Они ортогональны, а правильная метрика -- вообще третья.
> Важный это пакет, важный.
С этим спору нет -- хотелось сообща прийти к пониманию чуть более предметному, чем гадание на попконовой гуще :) Хотя как инструмент popcon, наверное, можно даже почти прямо применить, задействуя при сборках для анализа пакетного наполнения чрутов. Должно быть не хуже, чем хорошо продуманные логи.
> Частично да -- в них может оказаться тот же asciidocНу тогда libxslt - мимо. Так в Debian, не знаю как в alt.
Правильная зависимость, это конечно что-то вроде xmlto.
>> Важный это пакет, важный.
> С этим спору нетНу а раз нет - имеем отсутствие воспроизводимых сборок в ALT.
>> Частично да -- в них может оказаться тот же asciidoc
> Ну тогда libxslt - мимо. Так в Debian, не знаю как в alt.
> Правильная зависимость, это конечно что-то вроде xmlto.Опять ничего не поняли. Важно то, входит ли "проблемный" пакет в _развёрнутые_ сборочные зависимости.
>>> Важный это пакет, важный.
>> С этим спору нет
> Ну а раз нет - имеем отсутствие воспроизводимых сборок в ALT.И тут тоже, ну что за спешка...
Ладно, что могло помочь -- сказал. Если Вы не DD/DM, могу разве что предложить пособирать пакетики руками, прикидывая, что происходит в сборочнице. Может, потихоньку поймёте и перестанете носиться с, как у них это там, tribal thinking, а поможете своему дистрибутиву сделать и внедрить полезную разработку.
Я ведь только порадуюсь, если дебиан станет ещё чуточку лучше :)
>>> Частично да -- в них может оказаться тот же asciidoc
>> Ну тогда libxslt - мимо. Так в Debian, не знаю как в alt.
>> Правильная зависимость, это конечно что-то вроде xmlto.
> Опять ничего не поняли. Важно то, входит ли "проблемный" пакет в
> _развёрнутые_ сборочные зависимости.А это как раз дурацкий критерий для "важности". Впрочем, заострю
внимание лишь на том, что он только увеличит важность пакета...>>>> Важный это пакет, важный.
>>> С этим спору нет
>> Ну а раз нет - имеем отсутствие воспроизводимых сборок в ALT.
> И тут тоже, ну что за спешка...Ну вот. А не "давно уж", как в #45.
> Ладно, что могло помочь -- сказал.
Слушать пробовал?
> Может, потихоньку поймёте и перестанете носиться с, как у них это там, tribal thinking
Ну, когда определение воспроизводимости опущено, нет никаких доказательств того, что toolchain адаптирован для воспроизводимой (в смысле "бит в бит") сборки и просто лепится "фундаментальная поддержка" - это никакое не tribal thinking, шо вы...
>> Опять ничего не поняли. Важно то, входит ли "проблемный" пакет в
>> _развёрнутые_ сборочные зависимости.
> А это как раз дурацкий критерий для "важности". Впрочем, заострю
> внимание лишь на том, что он только увеличит важность пакета...Для ЭТОЙ задачи это ЕДИНСТВЕННЫЙ релевантный критерий. Думать до полного осмысления.
>>> Ну а раз нет - имеем отсутствие воспроизводимых сборок в ALT.
>> И тут тоже, ну что за спешка...
> Ну вот. А не "давно уж", как в #45.Вы чушь ляпнули. Причём я за свои слова отвечаю, а Вы, как обычно (заметьте, не говорю "всегда") -- нет.
> Ну, когда определение воспроизводимости опущено, нет никаких доказательств
У меня есть доказательства того, что Вы совершенно некомпетентны в обсуждаемом вопросе. И доказательства того, что в альте воспроизводимая сборка есть. И понимание того, что обсуждать интегралы с человеком, который два с двумя сложить не в состоянии -- бесполезно.
Хватит балаболить, сделайте сами хоть что-то полезного, нетупая нетварь.
>>>> Ну а раз нет - имеем отсутствие воспроизводимых сборок в ALT.
>>> И тут тоже, ну что за спешка...
>> Ну вот. А не "давно уж", как в #45.
> Вы чушь ляпнули. Причём я за свои слова отвечаю, а Вы,
> как обычно (заметьте, не говорю "всегда") -- нет.#22 (Michael Shigorin): Рад, что и в дебиане наконец-то допёрли до воспроизводимости сборки ;-)
#34 (я): И где же еще это реализовано?
#45 (Michael Shigorin): В альте давно уж.Если имелось в виду "как сделали в Debian" - то в ALT пока такого нет, необходимые патчи отсутствуют.
Если имелось в виду "фундаментальная поддержка воспроизводимости" (тм), то есть основания считать что в Debian уже реализовано не меньше (в списке modified packages нет buildd или pbuilder и т.п.). Подчеркиваю, это до патчей ReproducibleBuilds. А если еще и их учитывать - все куда более грустно.
>> Ну, когда определение воспроизводимости опущено, нет никаких доказательств
> У меня есть доказательства того, что Вы совершенно некомпетентны в обсуждаемом вопросе.Главное не держать их в себе!
> Хватит балаболить, сделайте сами хоть что-то полезного, нетупая нетварь.
Щелкнуть по носу кое-кого - тоже иногда полезно. Я не хочу принизить никого в ALT, но делая безосновательные и провокационные утверждения - ты делаешь соответствующую рекламу сообществу. Кое-что, конечно, сделано иначе (поддержка сборки из git), но утверждать что сделано больше или лучше - никак нельзя. (Использование VCS вообще, видимо, останется в Debian опциональным в обозримом будущем, не говоря уже об обязательном хождении стро^W^Wиспользовании Git. Зато есть мейнтейнеры.)
> Если имелось в виду "как сделали в Debian"Нет; ровно к тому и было упоминание множественности аспектов. Иначе бы так и написал.
> Если имелось в виду "фундаментальная поддержка воспроизводимости" (тм)
Да.
> то есть основания считать что в Debian уже реализовано не меньше
Я достаточно детально разъяснял, почему меньше, причём в принципе (по крайней мере насколько знаю про дебиановую сборочницу, включая сказанное Вами).
> Щелкнуть по носу кое-кого - тоже иногда полезно.
Если интересно, как кое-кто махнёт хвостом -- пожалуй :) Благодарность вам обоим была выражена вполне искренне и без подковырок.
> но утверждать что сделано больше или лучше - никак нельзя.
Можно, если понимать сказанное. Различие в методах изменения репозитория -- примерно как между централизованными и децентрализованными SCM либо как между любой SCM и её отсутствием как таковой (аналогия заведомо неточна, привожу в качестве "осязаемой" оценки).
PS: разумеется, работа по генераторам тоже важна и нужна -- просто это копание с другой стороны туннеля.
>> то есть основания считать что в Debian уже реализовано не меньше
> Я достаточно детально разъяснял, почему меньше, причём в принципеНет, ты не объяснил - ты описал относительно недавние изменения
в сборочной системе ALT. Нафейхоа они нужны дебиану - ты не объяснил.>> но утверждать что сделано больше или лучше - никак нельзя.
> Можно, если понимать сказанное.Могу только надеяться, что если есть кто-то "понявший", то он снизойдет и
перескажет "для идиотов".
> Нет, ты не объяснил - ты описал относительно недавние изменения
> в сборочной системе ALT.Да, за последний десяток лет.
> Нафейхоа они нужны дебиану - ты не объяснил.
А я и не уверен, что именно они нужны дебиану. Просто _с этой_ стороны туннеля такие работы уже проводились, некоторые проблемы известны и решения найдены; такая информация тем, кто _занимается_ дебиановой инфраструктурой и конкретно проектом из этой новости -- может быть интересна. Тем, кто переживает в сторонке -- разве что для общего образования.
Собственно, я здесь такой же "в сторонке", как и Вы, только мимо ушей нужный трафик пролетал (именно по этой теме) и что-то да зацепилось, ну и не стесняюсь переспрашивать по интересному.
> А я и не уверен, что именно они нужны дебиану.Раз инфраструктурные патчи в subj новости отсутствуют - не нужны.
> Раз инфраструктурные патчи в subj новости отсутствуют - не нужны.*sigh*
>> Раз инфраструктурные патчи в subj новости отсутствуют - не нужны.
> *sigh*Подвисшему дистрибутиву - виднее...
Не тратьте время, дебиан будет делать только то, что им в голову взбредёт. Я же говорил, оглядываться их никто не учил, они сами с усами и это их выбор.
> Лучше с ldv@ потолковать, если есть прикладной интерес.Типичный ответ альтов на все вопросы. Послать кого-то куда-то. Подразумевая что всем очевидно - кого, куда и зачем вообще столько возни.
> тезисы на летних конференциях в Обнинске лет пять-восемь тому.
ИМХО такие вещи, если они фича пакетного манагера, должны быть описаны в мане или накрайняк вике. Как вы думаете, сколько людей подорвется заниматься такой археологией без убер-сильной причины?
> Текущую систему -- с квантованным переходом состояния репозитория от задания к заданию
> -- дизайнил at@, на эту тему тоже была статья в тезисах.На самом деле всем нужна работающая система, а не тезисы. А у альтов в результате громкие тезисы и ... пакетный манагер который не может обновлять ядро как пакет, насколько я помню. При том нафига оно вот так - никто внятно сказать не может. Привыкли вот так.
А теперь сравним эти "удобства во дворе" с другими...
Вот например родная билдсистема майнлайнового кернела. Кроме всего прочего - умеет нынче генерить ... ну допустим те же DEB-пакеты. Поэтому можно собрать кернел, ЦИВИЛИЗОВАННО поставить его в мою систему, вместе с модулями и отладочной инфо, если она нужна, погонять это, при том - пакетный манагер обеспечит обновление конфига бутлоадера вообще без моего участия, так что я только ставлю пакет и делаю ребут. Ну а если не понравится - выпилить это нафиг, 1 командой или несколькими клацами мышки. Логически корректно выпилить. От отсутствия хвостов в дирах, до информирования бутлоадера что надо пересканировать список ядер и перестроить меню, чтоб неработоспособными остатками юзверю не светить. Вот такие "мелочи" и отличают серьезные проекты нацеленные на реальные применения от наколенных подeлок "и так сойдет!". В смысле "да что вам, вломак чтоли пару файлов самому стереть?". Да, вломак! У меня для этого в системе пакетный менеджер. Он должен рулить всеми системными файлами. Именно для этого и поставлен.
"обновление конфига бутлоадера вообще без моего участия, так что я только ставлю пакет и делаю ребут."
"Ну а если не понравится - выпилить это нафиг, 1 командой"
"От отсутствия хвостов в дирах, до информирования бутлоадера что надо пересканировать список ядер и перестроить меню, чтоб неработоспособными остатками юзверю не светить"
В альте тоже самое при обновлении/удалении ядра происходит, ЧЯДНТ ?
> В альте тоже самое при обновлении/удалении ядра происходит, ЧЯДНТ ?Дискутируете с человеком, который прочитал набросы ламеров, обчитавшихся пингвинсофтовской "аналитики", плохо её запомнившим (что бывает), но не потратившим и пяти минут на проверку поиском, в виртуалке либо заданным на всякий вопросом. :)
Человек-то неглупый, но налицо очередной случай, когда купился на вброс, запомнил и побежал его ретранслировать. К слову о мемах поопасней.
> Человек-то неглупый, но налицо очередной случай, когда купился на вброс, запомнил и
> побежал его ретранслировать.На самом деле - и как-то так тоже бывает. И опять же, сказать что альты не при чем - не получится. В смысле я когда-то немного повертел в руках альт, но однозначного понимания "а чем это лучше других и зачем оно мне?" за обозримое время у меня не возникло. А неделю ковыряться с микроскопом - на данной планете такой роскоши достоин далеко не любой объект.
> К слову о мемах поопасней.
К слову о мемах поопаснее - там я так смотрю у некоторых "упс, ошибочка вышла" бывают и поколоритнее. Не тому настучали в бубен, не того похитили. А то и вовсе не тот самолет сбили. Так что с ошибочками тоже надо поаккуратнее.
>> Лучше с ldv@ потолковать, если есть прикладной интерес.
> Типичный ответ альтов на все вопросы. Послать кого-то куда-то....где могут сэкономить годы жизни и битья головой об стенку.
> Подразумевая что всем очевидно - кого, куда и зачем вообще столько возни.
Кому тематика интересна -- тем из контекста уже всё ясно. Разве что "@altlinux.org" можно добавить, но кто в тематике ещё и копенгаген -- тем такие мелочи очевидны. :)
> ИМХО такие вещи, если они фича пакетного манагера, должны быть описаны
> в мане или накрайняк вике.Это фича сборочной инфраструктуры.
> Как вы думаете, сколько людей подорвется заниматься
> такой археологией без убер-сильной причины?А тут больше двух-трёх на дистрибутив и не надо. Не та задача, которая решается набивкой в четыре миллиона рук.
> На самом деле всем нужна работающая система, а не тезисы. А у альтов в результате
> громкие тезисы и ... пакетный манагер который не может обновлять ядро как пакет,
> насколько я помню.Вы некомпетентны не то что в вопросе, о котором речь, но и даже в том, который попытались поднять (а он отношения не имел бы, даже если бы чушь, которую Вы ляпнули, была правдой).
В такой ситуации помогает или слушать, уточняя неясное, или не тратить своё и чужое время.
> Вот например родная билдсистема майнлайнового кернела.
> Кроме всего прочего - умеет нынче генерить ... ну допустим те же DEB-пакеты.make rpm там тоже есть, если что.
> при том - пакетный манагер обеспечит обновление конфига бутлоадера
> вообще без моего участия, так что я только ставлю пакет и делаю ребут.Это нынче достижение, что ли? Вы будете таким размахивать перед майнтейнером одного из этих самых загрузчиков в дистрибутиве? :)
> Вот такие "мелочи" и отличают серьезные проекты нацеленные на реальные применения
> от наколенных подeлок "и так сойдет!"._Серьёзные_ проекты отличает фундаментальный подход, а не мощный костылинг.
В этом плане со временем стали более заметны отличия в проектировании тех же dpkg и rpm как средств сборки из исходников (каковое сравнение не в пользу rpm, т.к. формат спеков как раз и проектировался на коленке, насколько знаю).
> ...где могут сэкономить годы жизни и битья головой об стенку.А могут и не сэкономить. И вообще, окажется что своих стен навалом.
> Кому тематика интересна -- тем из контекста уже всё ясно.
Это наверное и есть главная ошибка альтов по жизни.
> -- тем такие мелочи очевидны. :)
Люди ленивы и многим из них может быть элементарно лень разбираться в интимных деталях неведомой фигни. На этой планете много всякого хлама и не затеряться среди него - еще уметь надо.
> Это фича сборочной инфраструктуры.
Ну вот нормальным подходом было бы вкратце сказать: что и зачем. И какие плюсы такого подхода относительно других. Иначе людям может быть не понятно зачем вообще на нечто время тратить.
> А тут больше двух-трёх на дистрибутив и не надо. Не та
> задача, которая решается набивкой в четыре миллиона рук.В смысле? Майнтенанс пакетов и то что вокруг - неплохо параллелится по числу рук. Или вы не о том?
> бы, даже если бы чушь, которую Вы ляпнули, была правдой).
Насколько я помню, обновление кернела в альте требовало какого-то весьма отдельного приседания и делалось иначе чем установка остальных пакетов. Что на мой вкус ощутимый минус. Это безобразие уже перестали практиковать?
> make rpm там тоже есть, если что.
А насколько такой RPM окажется интегрирован с остальными частями именно ВАШЕЙ системы, без мануальщины со стороны того кто майнлайновое ядро билдил? Если я его пакетным манагером поставлю - такой кернел пропишется в список ядер известных бутлоадеру при инсталле? А снесется при сносе пакета? Почистив за собой меню и что там еще? У дебианщиков есть некие оговоренные вызовы хуков, поэтому оно при должной компоновке пакета - работает вот так. Как минимум для бутлоадеров где кто-то подписался майнтайнить такую систему ниппель. А билдсистема кернела в курсе этого положения дел. Ну а с точки зрения всех остальных это - просто пакет, который ставится и сносится совершенно идентично остальным. Обкатать кернел а потом выпилить - просто и удобно. И "хвостов" не остается.
> Это нынче достижение, что ли?
Хм... не знаю даже. Это мелкая, но приятная фича которую можно обнаружить в майнлайне. Удобная для тех кто перестраивает кернел: можно погонять кернел относительно корректно, без гадежа в системе, с минимальными усилиями. И хорошо когда майнлайн в курсе что есть вот такой вид систем и с ним можно интегрироваться, вот так и эдак. На самом деле там тоже свои странности есть, но какая ж программа да без бага?! :)
> Вы будете таким размахивать перед майнтейнером
> одного из этих самых загрузчиков в дистрибутиве? :)Почему сразу 'размахивать'? Вот как майнтайнер можете рассказать: а как и почему ядро из кернелорга пропишется в лично ваш загрузчик? Я вот вижу подозрительный момент: у вас rpm, но ставится apt'ом и поэтому я как-то еще на подлете испытываю подозрения что нормальных хуков там никто под такое чудо-сочетание не сделал, а дурных багов может вылезти огого. Это напрасные подозрения?
> _Серьёзные_ проекты отличает фундаментальный подход, а не мощный костылинг.
И если с этим перестараться - получается какой-нибудь minix. Вроде весь из себя расово верный, но никому не упавший даже бесплатно и с пермиссивной лицензией. Дело в том что предугадать все факторы заранее - дохлый номер. По ходу пьесы придется один фиг адаптивно импровизировать. И хорошо, когда это умеют делать. Ну как тот же Торвальдс и ко, например.
> не в пользу rpm, т.к. формат спеков как раз и проектировался
> на коленке, насколько знаю).Да у дебианщиков тоже можно найти скелетов в шкафу. Например, глядя на энный пакет сложно сказать какая у него лицензия. Придется какие-то раскопки произвести. Там вроде как есть потуги добавления в описание пакета полей с лицензией, но пока я не вижу простого и понятного мне инструментария для всего этого. А то что вижу - требует тратить энное время на разбирательство, самолично. Возможно я где-то протупляю.
> Да у дебианщиков тоже можно найти скелетов в шкафу. Например, глядя на
> энный пакет сложно сказать какая у него лицензия.В смысле, на control файл пакета (или вывод чего-то типа dpkg -s)? А нафейхоа, извините,
там это надо. Чтоб "было как у rpm"?> Придется какие-то раскопки произвести.
Всех раскопок - файл /usr/share/doc/<package>/copyright.
> Там вроде как есть потуги добавления в описание пакета полей с лицензией
Не слышал о таких потугах и вряд-ли услышу. Технически, просто потому
что в Debian нет (и не предвидится) такого понятия как "лицензия пакета". Там
очень щепетильно относятся к лицензионным вопросам, так что в copyright пакета
сохраняют всю информацию о правах и лицензии всех файлов исходника.Так что все счастливы: простые пользователи читают DFSG (все пакеты из main
являются DFSG-совместимыми), вместо кучи лицензий из одноименного rpm поля, а
на радость адвокатоидам есть copyright, где соответствующая информация приведена
по-человечески, а не "как в rpm".
>> ...где могут сэкономить годы жизни и битья головой об стенку.
> А могут и не сэкономить. И вообще, окажется что своих стен навалом.Потому и "могут сэкономить", а не "сэкономят".
>> Кому тематика интересна -- тем из контекста уже всё ясно.
> Это наверное и есть главная ошибка альтов по жизни.Вы всерьёз предлагаете пытаться излагать в деталях тем, кому тематика неинтересна? :)
>> Это фича сборочной инфраструктуры.
> Ну вот нормальным подходом было бы вкратце сказать: что и зачем.
> И какие плюсы такого подхода относительно других. Иначе людям может быть
> не понятно зачем вообще на нечто время тратить.Кому непонятно с двух главных слов, тому не помогут двадцать о подробностях -- всё равно придётся сперва вникать...
>> А тут больше двух-трёх на дистрибутив и не надо.
> В смысле? Майнтенанс пакетов и то что вокруг - неплохо параллелится по числу рук.
> Или вы не о том?Разумеется, не о том -- это интенсивная разработка, а не экстенсивная. Экстенсивным может быть разве что QA вокруг неё.
>> бы, даже если бы чушь, которую Вы ляпнули, была правдой).
> Насколько я помню, обновление кернела в альте требовало какого-то весьма отдельного
> приседания и делалось иначе чем установка остальных пакетов.Ровно такое же, а для повышения удобства -- с учётом того, что множество пакетов с модулями также собираются централизованно вместо затрат времени при dkms на каждом хосте -- есть скрипт update-kernel.
>> make rpm там тоже есть, если что.
> А насколько такой RPM окажется интегрирован с остальными частями именно ВАШЕЙ системы,
> без мануальщины со стороны того кто майнлайновое ядро билдил?Не проверял.
> Если я его пакетным манагером поставлю - такой кернел пропишется в список ядер
> известных бутлоадеру при инсталле? А снесется при сносе пакета?Судя по /usr/lib/rpm/{boot_kernel,grub2}.filetrigger и отсутствию %post в kernel-image-* -- может и получиться.
> У дебианщиков есть некие оговоренные вызовы хуков
Не удивлюсь, если в дебиане такая обработка тоже висит на файлтриггерах (которые вообще-то там и появились, сильно позже добравшись до некоторых rpm-based).
> Вот как майнтайнер можете рассказать: а как и почему
> ядро из кернелорга пропишется в лично ваш загрузчик?Давайте проверим.
> Я вот вижу подозрительный момент: у вас rpm, но ставится apt'ом и поэтому я
> как-то еще на подлете испытываю подозрения что нормальных хуков там никто
> под такое чудо-сочетание не сделал, а дурных багов может вылезти огого.
> Это напрасные подозрения?Именно эти -- точно да, вопрос скорее в том, отработает ли штатно make rpm (может споткнуться об https://bugzilla.altlinux.org/5969).
> А где архив снапшотов дебиана, причём не по дням, а по сборкам?А зачем, чтобы было?
Все что нужно - как раз есть, это snapshot.debian.org. (Ну, т.е. "в прицеле", ибо сейчас main не поддерживает воспроизводимую сборку.)
> Без этого надо быть тем ещё лопухом, чтоб говорить о воспроизводимости окружения.
Можно объяснить дураку в картинках?
> Ну или сильно трудолюбивым человеком, если логи формирования
> сборочных чрутов (т.е. состав пакетов вплоть до версий) фиксируется.Конечно фиксируются, неужели есть такой дистрибутив, где такого не делают. Только причем это?
Чтобы воспроизвести сборку пакета x в момент X - тебе нужен архив дебиан на этот момент (куда включены только воспроизводимые пакеты, конечно) + немного терпения. snapshot.debian.org, в принципе, достаточен для решения этой задачи.
>> А где архив снапшотов дебиана, причём не по дням, а по сборкам?
> А зачем, чтобы было?Затем, что в день попадания в такой архив, скажем, glibc или нового gcc возникнет два состояния, попадающих на один день: "до" и "после"; если же таких изменений на сутки пришлось несколько, то выкрутиться в первом приближении с помощью архива за день раньше для пакетов, собравшихся между сильно изменяющими сборочное окружение практически каждого, так уже не получится. Выход есть и в таком случае -- откатываться до ближайшей известной реперной точки назад, затем воспроизводить одну за другой сборки по логам. Но и это при условии, что логи ведутся и хранятся, а сборки и впрямь воспроизводимы.
>> Без этого надо быть тем ещё лопухом, чтоб говорить о воспроизводимости окружения.
> Можно объяснить дураку в картинках?Дураку не получится, а в паре слов для заинтересованных постарался выше. Если понадобится, поищу и ту статью.
> Чтобы воспроизвести сборку пакета x в момент X - тебе нужен архив
> дебиан на этот момент (куда включены только воспроизводимые пакеты, конечно) +
> немного терпения. snapshot.debian.org, в принципе, достаточен для решения этой задачи.Три реперные точки в сутки, конечно, лучше одной, но по сравнению с альтовской технологией (которая даёт синхронную гарантию, а не полагается на асинхронное зеркалирование) это всё архаика.
PS: пока смотрел, вспомнил -- у нас же есть ещё свёртка, так что некоторое время спустя (определяется наличием дискового пространства) остаются как раз ежесуточные снапшоты, ага.
>>> А где архив снапшотов дебиана, причём не по дням, а по сборкам?
>> А зачем, чтобы было?
> Затем, что в день попадания в такой архив, скажем, glibc или нового
> gcc возникнет два состояния, попадающих на один день: "до" и "после";Ну и? Да хоть двадцать два. Ни какого "на одно и то же" - совершенно разные даты. Скажем, утром в 7:34 и после обеда в 17:10.
> если же таких изменений на сутки пришлось несколько, то выкрутиться в
> первом приближении с помощью архива за день раньше для пакетов, собравшихся
> между сильно изменяющими сборочное окружение практически каждого, так уже не получится.Не совсем понял, из чего они должны выбираться. Каждый пакет собирается в конкретный
момент, состояние архива известно.Плюс, текущая схема подразумевает периодические сборки пакетов с текущим состоянием архива. Если что-то поломается, QA галочку уберет. Соответственно, эту поломку также можно будет воспроизвести, зная состояние архива на момент тестовой сборки. Таки не понимаю в чем фатальный недостаток этой схемы, ради которого ее нужно непременно усложнять.
>> Чтобы воспроизвести сборку пакета x в момент X - тебе нужен архив
>> дебиан на этот момент (куда включены только воспроизводимые пакеты, конечно) +
>> немного терпения. snapshot.debian.org, в принципе, достаточен для решения этой задачи.
> Три реперные точки в сутки, конечно, лучше одной, но по сравнению с
> альтовской технологией (которая даёт синхронную гарантию, а не полагается на асинхронное
> зеркалирование) это всё архаика.Почему три? Доступен полноценный снапшот архива, на любое время.
> Каждый пакет собирается в конкретный момент, состояние архива известно.Каждый собравшийся в архив пакет может поменять сборочное окружение следующих за ним (а может и не поменять).
> Таки не понимаю в чем фатальный недостаток этой схемы, ради которого ее нужно
> непременно усложнять.Усложнение-то невелико, но разница -- как между вероятностью и гарантией.
> Почему три? Доступен полноценный снапшот архива, на любое время.
А, или четыре -- похоже, плавает.
Можно ссылку на снапшот за 14.02.2014 по состоянию на 17:07 GMT (ровно год назад)?
>> Каждый пакет собирается в конкретный момент, состояние архива известно.
> Каждый собравшийся в архив пакет может поменять сборочное окружение следующих за ним
> (а может и не поменять).Да, и? Следующие пакеты все-равно будут собираться с конкретным снапшотом архива. В чем проблема потом это воспроизвести?
>> Почему три? Доступен полноценный снапшот архива, на любое время.
> А, или четыре -- похоже, плавает.
> Можно ссылку на снапшот за 14.02.2014 по состоянию на 17:07 GMT (ровно
> год назад)?Можно, конечно:
deb http://snapshot.debian.org/archive/debian/20140214T170700Z/ wheezy main
Там есть же справка на заглавной странице.
> Да, и? Следующие пакеты все-равно будут собираться с конкретным снапшотом архива.
> В чем проблема потом это воспроизвести?А, ну можно и так делать. Только это автоматически увеличивает минимальный зазор между сборками, ломающими суммарное ABI репозитория, до промежутка между снапшотами -- иначе может получиться так, что сборка на снапшоте N пакетов libA версии V+1 и затем B с libA версии V приведёт к тому, что в следующем снапшоте B будет связан с устаревшей версией библиотеки libA; такое может быть неважным, если libA_V и libA_V+1 как пакеты не пересекаются и могут быть установлены одновременно (условие одновременного нахождения в пуле недостаточно), иначе автоматически возникает unmet (что в debian unstable считается нормальным явлением, в отличие от альта).
>> Можно ссылку на снапшот за 14.02.2014 по состоянию на 17:07 GMT (ровно год назад)?
> deb http://snapshot.debian.org/archive/debian/20140214T170700Z/ wheezy mainНо по ссылке пишут, что это за 2014-02-14 16:22:20. За эти 45 минут ничего не собиралось? (вопрос не требует документального ответа, можно поставить мысленный эксперимент)
> Только это автоматически увеличивает минимальный зазор между сборками, ломающими суммарное ABI репозиторияtransitions и как их готовят.
>>> Можно ссылку на снапшот за 14.02.2014 по состоянию на 17:07 GMT (ровно год назад)?
>> deb http://snapshot.debian.org/archive/debian/20140214T170700Z/ wheezy main
> Но по ссылке пишут, что это за 2014-02-14 16:22:20. За эти
> 45 минут ничего не собиралось?Скорее - это связано с частотой обновления ftp.debian.org, там есть ссылка где можно подробно посмотреть список сохраненных снапшотов за месяц.
> Скорее - это связано с частотой обновления ftp.debian.org, там есть ссылка где
> можно подробно посмотреть список сохраненных снапшотов за месяц.О чём и писал.
Теперь сравните: http://ftp.altlinux.org/pub/distributions/archive/sisyphus/t.../ -- например, http://git.altlinux.org/tasks/archive/done/_136/140101/ пересобрано на базе http://git.altlinux.org/tasks/archive/done/_136/140101/build.../ перед коммитом в репозиторий; информация о сборочной среде для первого подзадания (к примеру) доступна здесь: http://git.altlinux.org/tasks/archive/done/_136/140101/build.../
>> Скорее - это связано с частотой обновления ftp.debian.org, там есть ссылка где
>> можно подробно посмотреть список сохраненных снапшотов за месяц.
> О чём и писал.Эт хорошо, но не худо бы сперва читать.
>> А Дебиан ещё лучше:)
> Рад, что и в дебиане наконец-то допёрли до воспроизводимости сборки ;-)Как опёнковод со стажем, присоединяюсь.
Удалите нах всю эту ветку, офтоп полный
Это конечно хорошая инициатива, хотя никто не может гарантировать, что уже в исходном коде компилятора нет закладки.
Про что и речь. Нет никакой 100% тождественности, пока не решён вопрос о самом главном - доверенном компиляторе. Можно сколько угодно трындеть о процентах и патчах, кидаться ссылками и строить из себя Д'Артаньяна. Видимо майханд из новой волны, судя по сленгу, оттуда и пренебрежительное отношение ко всему, что не является "Debian".
> Видимо майханд из новой волны, судя по сленгу, оттуда и пренебрежительное отношение
> ко всему, что не является "Debian".Вообще-то, у меня пренебрежительное отношение ко всему, что корчит из себя без достаточных оснований.
Если где-то уже сделано лучше - это только хороший повод поучиться. А вот когда только декларируют сделанное, а на деле патчей нема - это уже лишь повод дать тапком по рукам за вранье.
> Нет никакой 100% тождественности, пока не решён вопрос
> о самом главном - доверенном компиляторе.Это вопрос из соседней оперы, отличающейся примерно как авторизация ("да, нужное") от аутентификации ("то же самое").
Т.е. компилятор с закладкой может прекрасно собирать воспроизводимые бинарники специального вида, а доверенный компилятор, ставящий те же timestamp'ы -- может собирать "нужные" бинарники, которые не получается без спец. мер воспроизвести (второй пример высосан из пальца, но вполне реализуем).
Чтобы не доверять слепо (да и то условно, ну да ладно), я должен собрать пакет сам и сравнить его с тем, что проверяю. Окей. Но если я собрал пакет сам, то я просто его поставлю и буду использовать, какая мне уже разница, отличается он от чего бы то ни было?
И что? Поставили пользуйтесь, обновляйте его и поддерживайте сами.
Сколько хватает моего склероза, в FreeBSD до 10 версии это не вызывало каких-то нерешаемых проблем - порты шли в виде сырцов и компилились на месте, с учётом настроенных переменных в /etc/make.conf - не?
а так же поддерживать все необходимое для сборки обновляемых пакетов вовремя и обновления на всех компьютерах где ты пользуешься дебианом. В общем дерзай.
Ты совершаешь ошибку, деля весь мир на чёрное и белое. "Не слепо доверяю" -- не значит "доверяю потому, что имею математическое доказательство." Математического доказательства о каких-либо свойствах реального мира ты не получишь никогда.
Воспроизводимая сборка позволяет тебе, например, проводить выборочные проверки пакетов раз в год -- выбираешь в случайный день года, случайную сотню бинарей и проверяешь. Если ты увидишь расхождения -- это будет свидетельством в пользу наличия закладок. Если не увидишь, то свидетельством в пользу отсутствия. Если ты возьмёшь в руки теорвер, ты сможешь даже оценить весомость этого свидетельства.
Если тебе этого мало, ты можешь мониторить интернет. Вселенная в которой существуют закладки в дебиане, закладываемые системой сборки, будет отличаться от Вселенной, в которой таких закладок нет. Если ты попробуешь представить обе, то ты увидишь эти различия и даже сможешь выработать для себя методику поиска в интернете признаков того, что ты находишься в первой или во второй.
Эти подхода можно использовать по-отдельности или их можно сочетать -- это уж как больше нравится. Второй даст гораздо более достоверные результаты, но только если ты веришь, что в интернете достаточно энтузиастов проверяет пакеты, и не только популярные, но так же и слабопопулярные, которые ты тем не менее используешь.
а вот в Rust повторяемость сборок доступна из коробки. А еще там безопасные указатели. Переходите на Rust!
Давай ты перепишешь линукс на rust, а так же утилиты гну, кде и прочее. Тогда я может быть перейду на rust
Как быть с остальными 16,5%?
Продолжать работать над этим.
> Любой пользователь можно лично убедиться, что предлагаемый дистрибутивом бинарный пакет байт в байт совпадает с пакетом, собранным им лично из исходных текстов.Таки байт в байт? Ну-ну.
а в ELF-файлах хранится дата/время сборки?
> а в ELF-файлах хранится дата/время сборки?дочитал новость до конца, вопрос снимается :)
Ну вот, спохватились. Сколько там этот дистрибутив существовал без возможности его использовать?
> Сколько там этот дистрибутив существовал без возможности его использовать?Когда ходил в походы в прошлом веке, в горах уже попадались дебианщики (2.0 или что тогда было)...
а я знаю этих дебианщиков. они до сих пор живут в горах и смеются...
"своим смешным линукс-смехом" ©
Этот дистрибутив - парадигма стабильности на протяжении вот уже 20 лет. Покажите мне другой такой дистрибутив, который "возможно использовать". Да, и пусть у него будет хотя бы половина от этих 83%.
достаточно нескольких байтов в пределах 1% стобы доказать неравенство тождества
> достаточно нескольких байтовОдного бита.
бит - это необходимое условие, а байт достаточное
> бит - это необходимое условие, а байт достаточноеОдного бита уже достаточно, чтобы уехала контрольная сумма.
чего только не придумают, лишь бы gentoo не ставить.
> чего только не придумают, лишь бы gentoo не ставить.Есть подозрение, что как раз там с воспроизводимой сборкой в смысле этой новости всё крайне грустно -- задачи совсем другие решались, а гибкость и воспроизводимость находятся на разных полюсах этой "качели".
как раз в контексте этой новости бинарная воспроизводимость несколько теряет смысл. убедиться, что "пакет собран из заявленных исходных текстов" в генте значительно проще.
> убедиться, что "пакет собран из заявленных исходных текстов" в генте значительно проще.Уверены, что понимаете слова "сборочное окружение"?
да
Молчи. :)
В данной ситуации сорц-базед дистры сосут причмокивая. Если у тебя в gcc каким-то образом оказалась закладка, то ты не сможешь сравнить бинарь этого gcc и бинари скомпилированные им с эталонными, чтобы проверить, что закладок нет. Ты вынужден верить в то, что тулчайн в твоей системе не содержит закладок.
> Ты вынужден верить в то, что тулчайн в твоей системе
> не содержит закладок.+100500
самый интимный момент...
> В данной ситуации сорц-базед дистры сосут причмокивая. Если у тебя в gcc
> каким-то образом оказалась закладка, то ты не сможешь сравнить бинарь этого
> gcc и бинари скомпилированные им с эталонными, чтобы проверить, что закладок
> нет. Ты вынужден верить в то, что тулчайн в твоей системе
> не содержит закладок.Как раз только в source-based и сможешь. В debian - никак.
Вот это почитай для саморазвития: https://www.linux.org.ru/news/opensource/11314293/page1#comm...
> Как раз только в source-based и сможешь.Нет.
> Вот это почитай для саморазвития: https://www.linux.org.ru/news/opensource/11314293/page1#comm...Там по ссылке написано следующее: "я верю в свой тулчайн и верю что он не содержит закладок." Я об этом и сказал -- доверие пользователя сорц-базед дистра к своему софту упирается в доверие к тулчайну. И проверить это крайне сложно, даже если вытащить жёсткий диск, воткнуть в другую машину и попробовать там разобраться.
и как на фоне этого убедиться, что тот же debian собран без закладок? там тулчейн компилируется в машинные коды проверяющим пользователем? ну повторили вы бинарно сборку с закладкой и дальше что?
В source-based я могу гарантировать, что у меня исходники те, что обещали, и самостоятельно всё собрать. В этом плане мне надо быть уверенным в корректности полутора пакетов, которыми я бутстраплюсь. Их можно хоть намертво зафиксировать лет на десять.
> В source-based я могу гарантировать, что у меня исходники те, что
> обещали, и самостоятельно всё собрать. В этом плане мне надо быть
> уверенным в корректности полутора пакетов, которыми я бутстраплюсь. Их можно хоть
> намертво зафиксировать лет на десять.Плюс проблема в том, что единственный способ проверить бинарь gcc на отсутствие закладок в сорц-базед дистре -- это засунуть этот бинарь в декомпилятор и провести полный аудит результата. Впрочем, можно попытаться скомпилировать им hello-world.c и проверить a.out на отсутствие закладок, но если закладки не будут найдены, то реальный ответ который мы получим: наш gcc не внедряет закладки в hello-world.
Вот если бы в сорц-базед дистре была бы воспроизводимая сборка. Чтобы я мог бы взять свой жёсткий диск, воткнуть в другой компьютер и, собрав на другом компьютере другим тулчайном копию своей системы, сравнить все бинари побитово, то это было бы даааа... это было бы ууу...
А так остаётся лишь верить в то, что в тулчайне нет закладок. Да, это близко к полутора пакетам. Да их можно обновлять очень редко. Но хоть как-то проверить это невозможно. Если десять лет назад доверенный хост с пакетами и их хешами был компрометирован на десять минут, и именно тогда вы взяли оттуда сорцы gcc с закладкой, то все эти десять лет у вас был тулчайн с закладкой. Вне зависимости от того, обновляли ли вы gcc с тех пор или нет.
Достаточно на другой машине собрать gcc, а им - собрать gcc. Можно для сравнения собрать gcc clang и этим собранным gcc пересобрать себя. Если будут различия - дизасм и прочий анализ, вряд ли их будет много. После чего можно этот gcc фиксировать как эталонный.
> Достаточно на другой машине собрать gcc, а им - собрать gcc. Можно
> для сравнения собрать gcc clang и этим собранным gcc пересобрать себя.
> Если будут различия - дизасм и прочий анализ, вряд ли их
> будет много. После чего можно этот gcc фиксировать как эталонный.На другой машине придётся собрать именно эту версию gcc. Если предположить, что в gcc нет багов, которые могут приводить к тому, что оптимизация неустойчива, то этого будет достаточно. Если предположить, что расположение файлов на диске не влияет на работу, configure && make -- если они генеря правила make, а потом обрабатывая их, и обращаясь к списку файлов в директории, сортируют этот список прежде чем использовать, а не используют в том виде в котором ядро выдало. Если не сортируют, то оказывается, что ещё tar может повлиять на воспроизводимость сборки. Я не вижу, как могут повлиять на воспроизводимость флаги -jN для make, но я вот нисколько не буду удивлён, если они могут повлиять.
Это то, что я навскидку придумал. Я не затрагивал, например, работу ld -- я никогда не вникал в деталях что и как он делает, но он выпоняет довольно сложную работу, для того, чтобы даже смена минорной версии могла бы привести к изменению результатов. Всякие там его скрипты, про которые я иногда вижу упоминания, но не вдавался в подробности как они работают, как их писать, патчатся ли эти скрипты мейнтейнерами gentoo, лежат ли они на диске или для ELF они вкомпилированы в ld статически...
Короче, ваш энтузиазм, вида "достаточно взять и собрать", для меня выглядит скорее проявлением эффекта Даннинга-Крюгера, чем аргументом. Может я ошибаюсь, но если так, то намекните хотя бы на свой опыт создания бинарей бит-в-бит на разных машинах.
Так я на бит-в-бит для всего и вся не претендовал. Как раз наоборот - собираем полтора пакета несколько раз, вручную смотрим различия, убеждаемся, что эти различия безвредны и объявляем, что пакеты собраны корректно и заначиваем их до лучших времён в готоовм, бинарном виде. Дальше ими можно бутстрапить новую версию сборочных тулзов и ею - всё остальное, при этом нам побоку, как оно работает - лишь бы все исходники были с контрольными суммами/подписями доверяемой сущности. Если не нужна государственная сертификация - не вижу проблем. Ну а те места, где она нужна, давно пора взорвать динамитом из-за тупости и неэффективности. Альты же эти места любят, поэтому для них такой вариант, разумеется, не покатит.
Но вообще-то я действительно в этом ни черта не сображаю. Просто жизненный опыт подсказывает, что разного рода идеальные решения - вроде математических доказательств корректности, сборки бит-в-бит, чистого функционального подхода и тому подобного - на практике проигрывают более приземлённым решениям.
> Но вообще-то я действительно в этом ни черта не сображаю. Просто жизненный
> опыт подсказывает, что разного рода идеальные решения - вроде математических
> доказательств корректности, сборки бит-в-бит, чистого функционального подхода
> и тому подобного - на практике проигрывают более приземлённым решениям.Стопроцентные решения обычно и впрямь недостижимы или имеют свои крупные проблемы в сравнении с "восьмидесятипроцентными", но та же "сборка бит-в-бит" или "сверка хэшей" как раз являются "более приземлёнными" способами хотя бы уменьшить неопределённость...
Благодаря подначкам, вопросам и (неправильным) ответам тов. myhand и гражданина User294 сделал проверку да написал статейку: http://altlinux.org/reproducibleЛюбой желающий может воспроизвести мой пример, а особо въедливые -- и поискать опровержение (был взят первый попавшийся небольшой пакет из тех, что у меня за последнее время заметно менялись в плане сборки).
> Благодаря подначкам, вопросам и (неправильным) ответам тов. myhandТов. myhand, например, невооруженным глазом видит, что автоматизирована эта сверка через одно место.
> сделал проверку да написал статейку: http://altlinux.org/reproducible
Это говорит о том, что в ALT не сильно хуже, чем в Debian. Но пока не следует что лучше.
> особо въедливые -- и поискать
> опровержение (был взят первый попавшийся небольшой пакет из тех, что у
> меня за последнее время заметно менялись в плане сборки).Да все уже нашли. Берем пакеты, использующие xmlto для документации или sphinx.
>> Благодаря подначкам, вопросам и (неправильным) ответам тов. myhand
> Тов. myhand, например, невооруженным глазом видит, что автоматизирована
> эта сверка через одно место.Вообще не автоматизирована, хотя напрашивается, согласен. А предъявил для выяснения степени истинности утверждения "в альте нет воспроизводимой сборки".
[skip: всё уже сказал]
> А предъявил для выяснения степени
> истинности утверждения "в альте нет воспроизводимой сборки".Так никак не выясняет, см. #143. Добавлю что сборка одного пакета для статистики - непредставительно, мягко говоря.
ЗЫ:
Попробовал воспроизвести билд, увы kvm c CDROM подвис на "Populating /dev". Может 2Gb памяти ему мало для загрузки? С другой стороны, а не жирно ли будет?Вообщем, пациент скорее мертв.
> Попробовал воспроизвести билд, увы kvm c CDROM подвис на "Populating /dev".Давайте параметры запуска, сама-то текстовая livecd-шка должна была стартовать.
PS: лучше не ввязываться в подобные споры, не занимаясь тематикой -- потому как когда говоришь "такого нет", тебе предъявляют наличие даже одного экземпляра, то съезжать на "статистику" получается просто глупо. Собственно, расписывал в деталях ровно для того, чтоб показать -- проблема есть, она сложная и многосторонняя, решать её можно с разных сторон, а вовсе не для мерянья (кроме разве отмечания того очевидного факта, что в альте этим вопросом в прикладном плане задались более десяти лет тому).
PPS про tmpfs: http://lists.altlinux.org/pipermail/devel/2015-February/1994...
>> Попробовал воспроизвести билд, увы kvm c CDROM подвис на "Populating /dev".
> Давайте параметры запускаkvm -net nic,vlan=0,model=e1000,macaddr=DE:AD:BE:EF:43:56 -net tap,vlan=0,ifname=tap0 -no-shutdown -usb -usbdevice tablet -smp 2 -m 2048 -boot menu=on -drive file=a,media=disk,index=0,boot=on -cdrom altlinux-p7-builder-20141212-x86_64.iso -soundhw es1370
Еще говорит "could not insert efivars".
> PS: лучше не ввязываться в подобные споры, не занимаясь тематикой -- потому
> как когда говоришь "такого нет", тебе предъявляют наличие даже одного экземпляра,
> то съезжать на "статистику" получается просто глупо.Ты мне - один (который еще воспроизвести надо, подвисший
Linux - это нечто), а я тебе уже как минимум два, забыл уже? Такая вот статистика.> Собственно, расписывал в
> деталях ровно для того, чтоб показать -- проблема есть, она сложная
> и многосторонняя, решать её можно с разных сторон, а вовсе не
> для мерянья (кроме разве отмечания того очевидного факта, что в альте
> этим вопросом в прикладном плане задались более десяти лет тому).А патчей нет и поныне.
> kvm -net nic,vlan=0,model=e1000,macaddr=DE:AD:BE:EF:43:56 -net tap,vlan=0,ifname=tap0
> -no-shutdown -usb -usbdevice tablet -smp 2 -m 2048 -boot menu=on -drive
> file=a,media=disk,index=0,boot=on -cdrom altlinux-p7-builder-20141212-x86_64.iso
> -soundhw es1370Спасибо, воспроизвёл на 2.2.0 -- похоже, qemu плохеет от "лишних" ядерных модулей; пока собрал времянку без них: http://fly.osdn.org.ua/~mike/iso/tmp/regular-builder-2015021...
Кстати:
qemu-kvm: boot=on|off is deprecated and will be ignored. Future versions will reject this parameter. Please update your scripts.
re #175: поищите udev qemu hang для расширения кругозора, есть у него такая болячка.
> Еще говорит "could not insert efivars".
Да, это efivars.ko в какой-то момент вместо молчаливой загрузки без EFI начал ругаться (надо ещё раз засесть и аккуратно поучитывать все взаимодействия).
>> когда говоришь "такого нет", тебе предъявляют наличие даже одного экземпляра,
>> то съезжать на "статистику" получается просто глупо.
> а я тебе уже как минимум два, забыл уже? Такая вот статистика.Было Ваше утверждение: "нет". Я предъявил. Стало быть, "есть". Точка.
> А патчей нет и поныне.
Вы всё ещё про libxslt (про который объяснил, что такие частные случаи фиксить хорошо и полезно, но это детали надцатого порядка) или про инфраструктуру, где разумней читать коммиты в существующем проекте, а не искать патчи к какому-то сферическому в вакууме?
Да, с новым образом - завелось.> qemu-kvm: boot=on|off is deprecated and will be ignored. Future versions will reject
> this parameter. Please update your scripts.Ну вот Jessie начну тестировать - будет повод.
>>> когда говоришь "такого нет", тебе предъявляют наличие даже одного экземпляра,
>>> то съезжать на "статистику" получается просто глупо.
>> а я тебе уже как минимум два, забыл уже? Такая вот статистика.
> Было Ваше утверждение: "нет". Я предъявил. Стало быть, "есть".Так непонятно что предъявлено. В дебиан тоже есть система сборки пакетов, и ее
не пытаются модифицировать под нужды решения задачи subj.Но помимо этого - в Debian делаются вполне конкретные изменения в
неинфраструктурных пакетах, собственно это и предмет новости. Где все это?> Вы всё ещё про libxslt
Я случайным образом ткнул в один пакет, в этот. Патча нет. Я случайным образом ткнул в другой - все аналогично. Я могу пройтись по остальным патчам из списка subj, надо? У меня результат не вызывает сомнений, но если alt хочет себе такую рекламу - он ее получит.
Раньше все верили что в свичах нету бэкдоров и закладок.
Holger Levsen сообщил http://layer-acht.org/thinking/blog/20150307-reproducible-video/ , чтодоступно видео его с коллегой доклада https://fosdem.org/2015/schedule/event/stretching_out_for_tr.../ по теме 31 января на FOSDEM 2105. +слайды и последние новости https://reproducible.debian.net/sid/index_suite_stats.html начинания.
