1.1, Анонимс (?), 20:04, 30/03/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
> В Guix можно использовать Software Heritage для получения кода, если репозиторий из которого собран пакет, перестал существовать
> и проверить что бинарные файлы собраны именно из этого кода без добавления скрытых изменений
Однако, полезная вещь.
| |
|
2.4, Stax (ok), 20:52, 30/03/2019 [^] [^^] [^^^] [ответить]
| +5 +/– |
Тем, что hasher недостаточно для задачи, которую тут решают?
Тут привязка к зависимостям не на уровне версий пакетов, а конкретной ревизии (коммита) сорцов для каждого проекта. И проверка идентичности сборки, если не совпал хэш с требуемым - значит что-то пошло не так. Добиваются совпадения бит-в-бит.
В альтернативах типа mock или hasher привязка на уровне обычных зависимостей, где может обновится сборка при той же формальной (с точки зрения пакета) версии, но из-за изменений сборка с новой версией не будет идентична бит-в-бит. Ну и результирующую контрольную сумму никто с эталоном не сверяет, там просто никто не ведет никаких эталонов.
Хотя вот тут какое-то совпадение хешей показали https://www.altlinux.org/%D0%92%D0%BE%D1%81%;D0%BF%D1%80%D0%BE%D0%B8%D0%B7%D0%B2%D0%BE%D0%B4%D0%B8%D0%BC%D0%B0%D1%8F_%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0
Но в плане качества это ничем не лучше того же remock (https://github.com/kholia/ReproducibleBuilds)
И на этот хэш никто потом не завязывается (в смысле требования получать тот же хэш при последующих сборках)
| |
|
3.5, Аноним (5), 21:05, 30/03/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
Ну а как там все-таки разруливается, что компиляция программулины компилятором gcc 8.1 приведет к такой-то бинари, а компилятором gcc 8.2 - вот к такой? И с каких это пор одна лишь ревизия gcc достаточна? - он сам по себе может быть собран с патчами или без, с такими-то опциями или сякими-то. Не бывает четкой связи между "ревизией (коммитом) сорцов" и бинарем. А чтобы она случилась, нужно сверхгигантское количество предпосылок и допущений.
| |
|
4.6, Stax (ok), 23:04, 30/03/2019 [^] [^^] [^^^] [ответить]
| +/– |
> без, с такими-то опциями или сякими-то. Не бывает четкой связи между
> "ревизией (коммитом) сорцов" и бинарем. А чтобы она случилась, нужно сверхгигантское
> количество предпосылок и допущений.
Судя по документу, у них как раз мегарепа с копией исходников всех проектов. Т.е. git clone (ну или иное, если изначально не гит) для всего вообще, что используется. И ссылка на коммит в этой их копии это однозначно конкретные исходники.
И когда они такое делают для абсолютно всех зависимостей, получается идентичность.
Разумеется, версию gcc также менять нельзя...
| |
4.21, J.L. (?), 18:46, 01/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Ну а как там все-таки разруливается, что компиляция программулины компилятором gcc 8.1
> приведет к такой-то бинари, а компилятором gcc 8.2 - вот к
> такой? И с каких это пор одна лишь ревизия gcc достаточна?
> - он сам по себе может быть собран с патчами или
> без, с такими-то опциями или сякими-то. Не бывает четкой связи между
> "ревизией (коммитом) сорцов" и бинарем. А чтобы она случилась, нужно сверхгигантское
> количество предпосылок и допущений.
вы не понимаете суть
у вас есть версия в которой написано что собрана она таким-то компилятором с такой то ревизии из проекта Heritage
вы можете проверить это экспериментальным путём
а если авторы пакета не способны предоставить указание о версии компилятора и номере ревизии из проекта Heritage (или аналога), то вы им говорите что они скриптокидихацкеры, и бинарный пакет у них брать не будете
| |
4.23, Wladmis (ok), 20:00, 01/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Ну а как там все-таки разруливается, что компиляция программулины компилятором gcc 8.1
> приведет к такой-то бинари, а компилятором gcc 8.2 - вот к
> такой? И с каких это пор одна лишь ревизия gcc достаточна?
> - он сам по себе может быть собран с патчами или
> без, с такими-то опциями или сякими-то. Не бывает четкой связи между
> "ревизией (коммитом) сорцов" и бинарем. А чтобы она случилась, нужно сверхгигантское
> количество предпосылок и допущений.
Очевидно, что результат сборки пакетов есть результат некоторой функции сборки от друх переменный: исходников и сборочного окружения. И результаты для одних и тех же исходников, но разных сборочных окружений, может различаться. Поэтому для воспроизведения сборки необходимо хранить информацию о сборочном окружении для кадого собранного пакета. Не знаю, что сделано в Heritage, в ALT для информация о них хранится в сборочных тасках и заносится в индекс собранных пакетов.
| |
|
|
2.10, myhand (ok), 09:26, 31/03/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
ALT Linux не запрещен на территории Российской Федерации! А этот ваш, который на Х - может с самими террористами связан.
| |
|
3.12, Аноним (12), 10:33, 31/03/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
Каждый фрагмент кода рекламируемой Вами сборки имеет отечественный копирайт? Причем числящийся не за частным лицом или частной компанией, а за государственным учреждением? Очевидно, нет. В таком случае данный дистрибутив не имеет ровно никаких отличий от любого иного дистрибутива. Его упоминание в каких-то там реестрах не означает ничего, кроме фактов упоминания в реестрах.
| |
|
4.17, myhand (ok), 13:32, 31/03/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Дык в том-то и соль, что ALT - в "каких-то там реестрах" не упоминается. Это вы все норовите софтом, пропагандирующим всякое гейство, пользоваться.
Хорошо, что хоть Роскомнадзор стоит на страже - иначе как у ALT пользовательская база-то появится?
| |
|
3.22, J.L. (?), 18:46, 01/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
> ALT Linux не запрещен на территории Российской Федерации!
это временно
| |
|
2.20, Wladmis (ok), 21:08, 31/03/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Чем это лучше hasher от ALT Linux?
Hasher решает другую задачу: изолированной сборки пакетов, которая исключает влияние хост-системы на сборочное окружение и наоборот. Software Heritage же — это репозиторий исходных кодов, из которых были собраны пакеты, и информации о бинарных сборок этих пакетов. В ALT этому ближе gears-репозитории и индексы исходных пакетов.
| |
2.24, freehck (ok), 20:33, 01/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Чем это лучше hasher от ALT Linux?
Вообще-то тут правильнее сравнивать с Gears.
Hasher -- это более низкоуровневый инструмент, аналог дебиановского pbuilder-а, ну или рхеловского mock.
Что касается сравнения с Gears, то правильный ответ -- ничем. Эти инструменты заточены под оси с принципиально разными архитектурными подходами. Да, они выполняют в них схожий функционал, но они не могут заменить друг друга от слова совсем.
| |
|
1.7, yoda (?), 01:25, 31/03/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
>полного архива всех доступных в Сети исходных текстов
Могущественное сосредоточение датацентров правительства ощущаю я.
| |
1.14, Аноним (14), 12:11, 31/03/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
GUIX хорошая идея, но на убунту накатить не осилил за пару часов, собственно на этом решил и забть.
| |
|
2.26, Аноним (26), 22:49, 05/04/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
На openSUSE сделал следующее:
$ zypper in guix
$ sudo systemctl enable --now guix-daemon.service
Дальше выполнил пункты 7-8 здесь (substitute server authorisation и application setup): http://guix.info/manual/en/Binary-Installation.html#Binary-Installation
И всё работает.
Если в вашем дистре пока нет guix, то следуйте инструкциям начиная с первого пункта или соберите "родной" для вашего дистра пакет (deb/rpm/etc.). Я в своё время сделал ebuild для Gentoo, когда его ещё не было ни в одном оверлее или в основной репе Gentoo, и это было крайне просто.
FYI, поделюсь опытом своей ошибки в начале. guix refresh будет пытаться сам определить наличие более свежих версий пакетов в апстриме с разных источников. С опцией --update он будет заменять файлы с определениями пакетов на диске. Не пытайтесь вызвать эту команду без аргументов и без надобности, скорее всего она провалился из-за rate limit'ов на github и других серверах. Если же в качестве аргументов команды указать список пакетов для рефреша, то наличие новых версий будет проверено лишь для них, и это вполне безопасно. Если вы не собираетесь самостоятельно обновлять пакеты до версий, определений которых ещё нет в git-репе guix, и бинарных пакетов для которых ещё нет на substitute-серверах, то команда guix refresh вам не нужна. Вместо этого обновляйте определения из git-репы через guix pull и бинарные пакеты через guix package -u. Кроме того, guix pull обновляет и сам пакетный менеджер guix вместе со всеми его модулями, но при этом не затрагивает то, что было установлено через хостовой пакетный менеджер. Фактически у каждого пользователя guix на одной машине может быть его отдельная копия, или даже несколько разных копий.
P.S. Если будет жалеться на отсутствие /usr/lib/libgit2 или /usr/lib64/libgit2, то установите libgit2-devel или libgit2-dev в вашем хостовом дистре.
| |
|
3.27, Аноним (26), 22:51, 05/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
Небольшая поправка: пункт 7 в моём случае выглядел так:
$ guix archive --authorize < /usr/share/guix/ci.guix.info.pub
| |
|
|
|