Сборка devel/llvm*

Alex Korchmar написал(а) к Eugene Grosbein в Aug 17 08:59:56 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:

AK>> то есть полная противоположность тому, что надо на самом деле - учитывая
AK>> более
AK>> чем скромное количество человекочасов, которые на это приходятся.
EG> Ровно то, что надо - багфиксы included.
то есть мы берем новую версию, выковыриваем из нее дифф со старой, гордо кладем
его в files/ и заявляем, что все сделали правильно - версия не изменилась,
багфикс вот он.

Неудивительно, что желающих этим заниматься ноль.

> Alex
P.S. кстати, по поводу sqlite отдельно - довольно забавно, что USES libtool
(то есть мы зачем-то перегенерируем то, что нам и так дали в архиве, ну, это
в вашей bsd так принято) но при этом используем "релизы" с сайта - при том что
они вообще-то предназначены для рукожопов, у которых нет tcl.
(и да, определенный смысл сборки с нуля, а не из sqlite3.c, как раз есть)

--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Alex Korchmar в Aug 17 16:55:42 по местному времени:

09 авг. 2017, среда, в 07:59 NOVT, Alex Korchmar написал(а):

AK>>> то есть полная противоположность тому, что надо на самом деле - учитывая
AK>>> более
AK>>> чем скромное количество человекочасов, которые на это приходятся.
EG>> Ровно то, что надо - багфиксы included.
AK> то есть мы берем новую версию, выковыриваем из нее дифф со старой, гордо кладем
AK> его в files/ и заявляем, что все сделали правильно - версия не изменилась,
AK> багфикс вот он.

Какую-то чушь ты описал.

AK> P.S. кстати, по поводу sqlite отдельно - довольно забавно, что USES libtool
AK> (то есть мы зачем-то перегенерируем то, что нам и так дали в архиве, ну, это
AK> в вашей bsd так принято) но при этом используем "релизы" с сайта - при том что
AK> они вообще-то предназначены для рукожопов, у которых нет tcl.
AK> (и да, определенный смысл сборки с нуля, а не из sqlite3.c, как раз есть)

Ни слова не понял.

Eugene
--
Поэты - страшные люди. У них все святое.
--- slrn/1.0.2 (FreeBSD)

Alex Korchmar написал(а) к Eugene Grosbein в Aug 17 13:26:03 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:

AK>> то есть мы берем новую версию, выковыриваем из нее дифф со старой, гордо
AK>> кладем
AK>> его в files/ и заявляем, что все сделали правильно - версия не изменилась,
AK>> багфикс вот он.
EG> Какую-то чушь ты описал.
это дословный пересказ действий, вытекающих из процитированного мной
английского текста. Только такие апдейты могут попадать в вет...пеньки
квартальных релизов.

AK>> (и да, определенный смысл сборки с нуля, а не из sqlite3.c, как раз есть)
EG> Ни слова не понял.
sqlite3.c, внезапно, не является исходником sqlite.
Это автогенеренный файл, предназначенный прежде всего для тех, кто хочет
использовать его в своем коде, и не очень при этом интересуется содержимым.


> Alex

--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Alex Korchmar в Aug 17 00:03:18 по местному времени:

09 авг. 2017, среда, в 12:26 NOVT, Alex Korchmar написал(а):

AK>>> то есть мы берем новую версию, выковыриваем из нее дифф со старой, гордо
AK>>> кладем
AK>>> его в files/ и заявляем, что все сделали правильно - версия не
AK> изменилась,
AK>>> багфикс вот он.
EG>> Какую-то чушь ты описал.
AK> это дословный пересказ действий, вытекающих из процитированного мной
AK> английского текста. Только такие апдейты могут попадать в вет...пеньки
AK> квартальных релизов.

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

Eugene
--- slrn/1.0.2 (FreeBSD)

Alex Korchmar написал(а) к Eugene Grosbein в Aug 17 22:30:54 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:

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

> Alex
P.S. впрочем, все это блекнет на фоне сегодняшнего
svn log ports/www/firefox

--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Alex Korchmar в Aug 17 04:27:59 по местному времени:

10 авг. 2017, четверг, в 21:30 NOVT, Alex Korchmar написал(а):

AK>>>>> то есть мы берем новую версию, выковыриваем из нее дифф со старой,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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

Не понял, что такое вторая точка.
Приложить к старой версии diff между ней и новой ничем не отличается
от смены версии на новую, а новая версия часто выпускается ради
новой функциональности.

Eugene
--- slrn/1.0.2 (FreeBSD)

Victor Sudakov написал(а) к Valentin Nechayev в Aug 17 09:13:26 по местному времени:

Dear Valentin,

05 Aug 17 13:01, you wrote to me:
VS>> А с портами поступили как со сторонним софтом, возможно потому что
VS>> это гораздо менее трудозатратно. В страшном сне представляю себе
VS>> FreeBSD Core Team, бэкпортящую исправления в nginx или gnome3
VS>> потому, что на момент выхода всех поддерживаемых релизов эхотага
VS>> зафиксировались такие-то их версии.

VN> Почему так сразу и Core?
VN> А исправления в таком варианте поступают только security. На них можно
VN> и потратиться.

Но откуда взять ресурсы на поддержку security веток для 27 с лишним тысяч портов? Откуда создатели линуксовых дистрибутивов берут такие ресурсы, чтобы бэкпортить security fixes в десятках тысяч софтин?

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

VS>> Точно так же
VS>> с трудом представляю себе Microsoft, фиксящий сторонний виндософт
VS>> самостоятельно вместо того, чтобы предложить обновиться до
VS>> последней версии, поддерживаемой вендором, даже если ради этого
VS>> этом бедному пользователю придется установить 5 разных дотнетов и
VS>> рантаймов.

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

VN> Ну вот эта система внешних реп и решает проблему, аналогичную
VN> стороннему софту у MS.

Ради интереса, а как с этим в других *BSD, если ты знаешь?

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Victor Sudakov написал(а) к Alex Korchmar в Aug 17 09:32:16 по местному времени:

Dear Alex,

05 Aug 17 12:51, you wrote to me:

AK>>> в линуксах не принято запускать automake и требовать зависимости
AK>>> от него, если в пакете изначально есть созданный автором
AK>>> configure. Этот маразм "патамушта могу!" специальный именно для
AK>>> фри. Я обычно удаляю подобные зависимости до запуска make.

VS>> Обновления портов/пакетов у тебя потом не ломаются из-за ручного
VS>> вмешательства?
AK> из-за ручного вмешательства - нет, не ломаются. Может сломаться
AK> из-за того, что автор порта еще чего-то нахреначил в DEPENDS, и
AK> лучше бы это заметить, потому что очень маловероятно что там что-то
AK> полезное, скорее всего оно - вредное.

При очередном обновлении portsnap или кто у тебя там затрёт все твои хаки, нет?

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

Ты мне льстишь. poudriere настраивается крайне просто и работает из коробки. Никакого хакерства и красноглазия в нем нет. Позволяет иметь несколько репозиториев с пакетами, собранным для разных архитектур и с разными опциями сборки - ну так всё это штатными средствами фри и ее системы портов (jail, /var/db/ports для опций и т.п.). Плюс удобнейший веб-интерфейс, в котором видно, что у тебя сейчас собирается, что не собралось и почему, вся статистика сборки etc. Тут же криптографическое подписание пакетов.

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

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

VS>> менее трудозатратно. В страшном сне представляю себе FreeBSD Core
VS>> Team, бэкпортящую исправления в nginx или gnome3 потому, что на
VS>> момент выхода всех поддерживаемых релизов эхотага зафиксировались
VS>> такие-то их версии.
AK> совершенно все равно что там где "зафиксировалось". А вот возможность
AK> поставить за месяц десяток систем, и быть уверенным, что версия nginx
AK> в них одна и та же - чего с freebsd никогда не будет - это как раз
AK> хорошо.

Тут бы не помешали ветки портов, привязанные к релизам. Может такие даже и есть, а я просто не знаю о них? В poudriere можно было бы собирать именно эти ветки для нужных хостов.

Квартальные ветки IMНO - какая-то странная идея.

Но в принципе задача "поставить за месяц десяток систем, и быть уверенным, что версия nginx
в них одна и та же" прекрасно решается отдельным репозиторием, полученным с помощью того же poudriere. Когда в этой версии найдут уязвимости, тогда уж пересборка и "pkg upgrade" на всём десятке систем.

VS>> с трудом представляю себе Microsoft, фиксящий сторонний виндософт
AK> microsoft прекрасненько это делает, в рамках поддерживаемых версий.
AK> Более того, сейчас и отказаться-то от апдейтов какого-нибудь офиса
AK> одновременных с апдейтами базовой системы крайне непросто.

Офис - это тоже микрософт. Апдейты для продуктов Adobe или к примеру Steinberg Микрософт всё же не додумались распространять через свою систему апдейтов. Пользователи должны сами позаботиться о стороннем софте.

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

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

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

А ты чего хотел бы от LTS?

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Victor Sudakov написал(а) к Valentin Nechayev в Aug 17 09:58:24 по местному времени:

Dear Valentin,

05 Aug 17 12:48, you wrote to me:

VN>>> А нельзя ли явно его собрать, чтобы FF пользовался готовым?
VN>>> llvm меняется немного реже :)
VS>> Оно в poudriere так и есть. Если llvm уже собран и лежит в
VS>> репозитории, он пересобираться не будет, в сборочный jail будет
VS>> установлен готовый llvm и прочие зависимости из пакетов.

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

Не очень понял, поясни мысль pls.

Если пакету по BUILD_DEPENDS нужен llvmXX и он уже ранее был собран, он собираться повторно не будет.

VS>> Но есть но: если например сборочный jail обновился из-за
VS>> freebsd-update, то будут пересобраны все пакеты в соответствующем
VS>> репозитории. Часто также из-за какого-нибудь automake-1.15.1_2 ->
VS>> automake-1.15.1_3 по зависимостям пересобирается туча всего.

VS>> Думаю это уже родовое проклятье фревой системы портов/пакетов. В
VS>> линуксах не так?

VN> В тех, что я видел, точно так же. Мелкая правка gcc поднимает
VN> пересборку чуть более, чем всего. Это считается неизбежной ценой.

Я так и подозревал.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Victor Sudakov написал(а) к Alex Korchmar в Aug 17 10:14:24 по местному времени:

Dear Alex,

25 Jul 17 17:18, you wrote to me:

VS>> rm это как-то жестко. В Web интерфейсе poudriere видно, что
VS>> devel/llvm40 собирается ради firefox, а llvm38 ради lang/clang38.
VS>> А clang38 ради security/masscan
AK> я совершенно уверен, что это рукожопость портособирателей.
AK> firefox прекрасненько собирается gcc 4.7.2 (если оторвать внутри
AK> проверку, но тебе такой старый и не надо), который сам собирается за
AK> несколько десятков минут даже на не особо хорошей системе.

В www/firefox/Makefile* вообще не вижу, в каком месте он подтягивает devel/llvm40
Каким-то непрямым образом, что ли.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322