39889 2021-04-06 21:50:31 +0300 Просьба собрать cryptography 3.4.7 2021-04-26 22:20:38 +0300 1 1 4 Development Sisyphus python3-module-cryptography unstable x86_64 Linux CLOSED FIXED P5 normal --- 1 lav cow cow grenka vladimir.didenko qa-sisyphus oldest_to_newest 197572 0 lav 2021-04-06 21:50:31 +0300 Просьба собрать cryptography 3.4.7, потребовался для новой версии matrix-synapse. 197573 1 lav 2021-04-06 22:12:58 +0300 Да, vendor для rust нехорошо класть в общий каталог: его надо паковать в отдельный тарбол. Если нужно, могу сделать на свой лад. 197577 2 vladimir.didenko 2021-04-07 09:31:55 +0300 (In reply to Vitaly Lipatov from comment #1) > Да, vendor для rust нехорошо класть в общий каталог: его надо паковать в > отдельный тарбол. > Если нужно, могу сделать на свой лад. Для чистых rust (и, например, go) пакетов я не соглашусь, в данном конкретном случае, возможно, и имеет смысл. Я не против, если вы поправите. Спасибо. 197597 3 lav 2021-04-07 14:59:18 +0300 (Ответ для Владимир Диденко на комментарий #2) > (In reply to Vitaly Lipatov from comment #1) > > Да, vendor для rust нехорошо класть в общий каталог: его надо паковать в > > отдельный тарбол. > > Если нужно, могу сделать на свой лад. > > Для чистых rust (и, например, go) пакетов я не соглашусь, в данном Дело в том, что каталог с исходниками в репозитории должен содержать распакованный тарбол, и вы не имеете права его модифицировать. Конечно, если кто-то поставляет тарбол уже с vendor, тут вопросов нет. 197598 4 vladimir.didenko 2021-04-07 15:21:27 +0300 (In reply to Vitaly Lipatov from comment #3) > Дело в том, что каталог с исходниками в репозитории должен содержать > распакованный тарбол, и вы не имеете права его модифицировать. А почему не имею права? 197599 5 lav 2021-04-07 15:29:30 +0300 (Ответ для Владимир Диденко на комментарий #4) > (In reply to Vitaly Lipatov from comment #3) > > Дело в том, что каталог с исходниками в репозитории должен содержать > > распакованный тарбол, и вы не имеете права его модифицировать. > > А почему не имею права? Потому что это нарушение правил. Содержимое каталога должно обновляться из апстримного тарбола. Меняя там что-то вручную, вы скрываете свои изменения. Я уж не говорю, что другой мантейнер при попытке обновить такой пакет столкнётся с проблемами. 197601 6 vladimir.didenko 2021-04-07 15:44:42 +0300 (In reply to Vitaly Lipatov from comment #5) > Потому что это нарушение правил. Ну вот меня и интересует, каких именно правил? Я не из вредности спрашиваю, а чтобы разобраться. У меня есть несколько go-пакетов, в которых vendor лежит в основной папке. И знаю немало немоих пакетов, которые используют тот же самый принцип. Поэтому, прежде чем бежать все переделывать, хочу разобраться в вопросе. > Содержимое каталога должно обновляться из апстримного тарбола. Меняя там > что-то вручную, вы скрываете свои изменения. Они не скрываются. Импорт/обновление vendor производится отдельным коммитом. И все изменения лежат в папке vendor. Это сложно назвать скрытием. 197604 7 lav 2021-04-07 17:20:17 +0300 (Ответ для Владимир Диденко на комментарий #6) > (In reply to Vitaly Lipatov from comment #5) > > Потому что это нарушение правил. > > Ну вот меня и интересует, каких именно правил? Я не из вредности спрашиваю, > а чтобы разобраться. У меня есть несколько go-пакетов, в которых vendor > лежит в основной папке. И знаю немало немоих пакетов, которые используют тот > же самый принцип. Поэтому, прежде чем бежать все переделывать, хочу > разобраться в вопросе. Лучше паковать vendor в отдельный тарбол (из отдельного каталога, отдельным правилом в .gear/rules — для этого там есть параметры name= и base=). Тогда всё будет наглядно. И может быть, надо появится информация, как этот vendor обновлять. 197605 8 vladimir.didenko 2021-04-07 17:32:31 +0300 (In reply to Vitaly Lipatov from comment #7) > (Ответ для Владимир Диденко на комментарий #6) > > (In reply to Vitaly Lipatov from comment #5) > > > Потому что это нарушение правил. > > > > Ну вот меня и интересует, каких именно правил? Я не из вредности спрашиваю, > > а чтобы разобраться. У меня есть несколько go-пакетов, в которых vendor > > лежит в основной папке. И знаю немало немоих пакетов, которые используют тот > > же самый принцип. Поэтому, прежде чем бежать все переделывать, хочу > > разобраться в вопросе. > Лучше паковать vendor в отдельный тарбол (из отдельного каталога, отдельным > правилом в .gear/rules — для этого там есть параметры name= и base=). > Тогда всё будет наглядно. И может быть, надо появится информация, как этот > vendor обновлять. Заранее прошу прощения за дотошность. Но все-таки хотелось бы разобраться. 1. В данном конкретном случае я могу понять, почему отдельный tarball лучше, поскольку vendor директория спрятана внутрях. А вот дальше не совсем ясно. 2. В чистых rust и go пакетах vendor директория лежит на самом первом уровне, и для всех кто знаком со сборкой rust и go пакетов не является секетом не назначение директории, ни процесс ее обновления. Упаковка vendor директории в отдельный tar архив тут только запутывает. По крайней мере, на мой взгляд. 3. Но судя по комментариям выше есть момент нарушения каких-то правил/договоренностей/лицензий? Вот это самый непонятный для меня вопрос. 197608 9 lav 2021-04-07 18:10:52 +0300 (Ответ для Владимир Диденко на комментарий #8) ... > Заранее прошу прощения за дотошность. Но все-таки хотелось бы разобраться. Без проблем. > 1. В данном конкретном случае я могу понять, почему отдельный tarball лучше, > поскольку vendor директория спрятана внутрях. А вот дальше не совсем ясно. Отдельный тарбол лучше потому, что каталог с исходниками должен формироваться простой распаковкой апстримного тарбола и никак иначе. > 2. В чистых rust и go пакетах vendor директория лежит на самом первом > уровне, и для всех кто знаком со сборкой rust и go пакетов не является > секетом не назначение директории, ни процесс ее обновления. Упаковка vendor > директории в отдельный tar архив тут только запутывает. По крайней мере, на > мой взгляд. Вы ещё не признались, где вы берёте этот vendor. Я всё спрашиваю в контексте существования https://www.altlinux.org/Etersoft-build-utils/extra_sources который направлен на автоматическое обновление скачиваемых компонент типа vendor. > 3. Но судя по комментариям выше есть момент нарушения каких-то > правил/договоренностей/лицензий? Вот это самый непонятный для меня вопрос. Ну я же объяснил, что в каталог распаковывается апстримный тарбол. Обычно это делают командой gear-update которая используется и в etersoft-build-utils (в команде rpmgs или rpmrb, которые обновляют исходники до новой версии) Наверное, будет понятнее, если я напишу, что не нужно думать, что в каталог кладутся файлы, из которых собирается пакет. В каталог распаковывается исходный тарбол без изменений. Дополнительные изменения делаются добавлением патчей (для исправления кода) или добавлением архивов (в случае необходимости добавить что-то стороннее). 197610 10 vladimir.didenko 2021-04-07 18:24:40 +0300 (In reply to Vitaly Lipatov from comment #9) > Вы ещё не признались, где вы берёте этот vendor. > Я всё спрашиваю в контексте существования > https://www.altlinux.org/Etersoft-build-utils/extra_sources > который направлен на автоматическое обновление скачиваемых компонент типа > vendor. $ cargo vendor > > > 3. Но судя по комментариям выше есть момент нарушения каких-то > > правил/договоренностей/лицензий? Вот это самый непонятный для меня вопрос. > Ну я же объяснил, что в каталог распаковывается апстримный тарбол. > Обычно это делают командой > gear-update > которая используется и в etersoft-build-utils (в команде rpmgs или rpmrb, > которые обновляют исходники до новой версии) gear-update не единственный способ обновить исходники. Еще раз, в данном конкретном случае, я согласен, что лучше сделать отдельный tarball. Но обычно в наших rust и go пакетах импортится апстримовский git и сорцы обновляются через git merge. Вот в этом конкретном случае непонятно, зачем нужно вытаскивать vendor в отдельное место. 198108 11 lav 2021-04-25 00:22:46 +0300 (Ответ для Владимир Диденко на комментарий #10) ... > gear-update не единственный способ обновить исходники. Еще раз, в данном > конкретном случае, я согласен, что лучше сделать отдельный tarball. Но > обычно в наших rust и go пакетах импортится апстримовский git и сорцы А где можно почитать об этом способе? Чтобы я попробовал повторить на каком-то конкретном пакете. > обновляются через git merge. Вот в этом конкретном случае непонятно, зачем > нужно вытаскивать vendor в отдельное место. Да, в этом случае там уже и так получается репозиторий-солянка, никакого смысла отделять vendor нет, равно как и собирать из апстримного репозитория. 198109 12 repository-robot 2021-04-25 03:06:05 +0300 python3-module-cryptography-3.4.7-alt1 -> sisyphus: Sun Apr 25 2021 Vitaly Lipatov <lav@altlinux.ru> 3.4.7-alt1 - new version (3.4.7) with rpmgs script (ALT bug 39889) - update src/rust/vendor separately 198138 13 vladimir.didenko 2021-04-26 15:20:32 +0300 (In reply to Vitaly Lipatov from comment #11) > А где можно почитать об этом способе? Чтобы я попробовал повторить на > каком-то конкретном пакете. > Если именно Rust пакеты интересуют, то можно глянуть на ripgrep (пакет не мой) http://git.altlinux.org/gears/r/ripgrep.git Если Go, то fzf (пакет мой) http://git.altlinux.org/gears/f/fzf.git 198159 14 lav 2021-04-26 22:20:38 +0300 (Ответ для Владимир Диденко на комментарий #13) > (In reply to Vitaly Lipatov from comment #11) > > А где можно почитать об этом способе? Чтобы я попробовал повторить на > > каком-то конкретном пакете. > > > > Если именно Rust пакеты интересуют, то можно глянуть на ripgrep (пакет не > мой) > > http://git.altlinux.org/gears/r/ripgrep.git > > Если Go, то fzf (пакет мой) > > http://git.altlinux.org/gears/f/fzf.git Ага, спасибо.