Bug 38287
| Summary: | Задать жёсткую зависимость на версию openssl у бинарного пакета ntp | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Vera Blagoveschenskaya <vercha> |
| Component: | ntp | Assignee: | Sergey Y. Afonin <asy> |
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
| Severity: | enhancement | ||
| Priority: | P5 | CC: | asy, glebfm, ldv, mcpain, mike, rider, sotor |
| Version: | unstable | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
Что-то тут не так. Вот это OpenSSL version mismatch. Built against 101000af, you have 1010104f Built against OpenSSL OpenSSL 1.1.0j 20 Nov 2018, using version OpenSSL 1.1.1d 10 Sep 2019 у меня воспроизводится. Причина понятна: после обновления OpenSSL не пересобрали ntp. Вопрос сразу к ldv@: а такие неочевидные штуки сборочница как-то может ловить? А вот с ntp из задания 248359 это не воспроизводится у меня. В итоге простой запуск ntp-keygen всё равно даёт ошибку (error:0909006C:PEM routines:get_name:no start line), но на несоответствие версий OpenSSL не ругается уже. (In reply to Vera Blagoveschenskaya from comment #0) > При выполнении команды ntp-keygen ошибка: > OpenSSL version mismatch. Built against 101000af, you have 1010104f Это, всё же, только предупреждение. Но почему и с p14 на стенде вылезло я по прежнему не понимаю. > Verify RSA-MD5 certificate fails > error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message > digest algorithm А это последствие того, что в новом OpenSSL отключили MD5. Надо пока использовать "-c RSA-SHA1" например. Оказывается у них есть баг про MD5: https://bugs.ntp.org/show_bug.cgi?id=2518 Я немного дописал. (In reply to Vera Blagoveschenskaya from comment #0) > При выполнении команды ntp-keygen ошибка: > OpenSSL version mismatch. Built against 101000af, you have 1010104f > Built against OpenSSL OpenSSL 1.1.0j 20 Nov 2018, using version OpenSSL > 1.1.1d 10 Sep 2019 Это проблема сборочницы. Вероятно enhancement, если это вообще исправимо. > Verify RSA-MD5 certificate fails > error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message > digest algorithm По этому поводу завёл Bug 38300 (Ответ для Sergey Y. Afonin на комментарий #4) > (In reply to Vera Blagoveschenskaya from comment #0) > > > При выполнении команды ntp-keygen ошибка: > > OpenSSL version mismatch. Built against 101000af, you have 1010104f > > Built against OpenSSL OpenSSL 1.1.0j 20 Nov 2018, using version OpenSSL > > 1.1.1d 10 Sep 2019 > > Это проблема сборочницы. Вероятно enhancement, если это вообще исправимо. А при чём тут сборочница? Это ntp сам по себе решил, что версия не совпала, set:versions так не посчитали -- кто-то из них неправ. (In reply to Gleb F-Malinovskiy from comment #5) > > Это проблема сборочницы. Вероятно enhancement, если это вообще исправимо. > > А при чём тут сборочница? Это ntp сам по себе решил, что версия не совпала, > set:versions так не посчитали -- кто-то из них неправ. Я пока не знаю, зачем ntp это проверяет и выдаёт предупреждение. Но может в сборочнице можно сделать какой-то список явных зависимостей на тему, что требуется пересобирать? На самом деле есть минимум ещё один кандидат, который просто так не ловится. Оказалось, что при обновлении gpsd до 3.19 надо было явно пересобрать gqrx. Но это отдел тестирования на пересборке репозитория отловил правда. Не знаю пока, это что-то разовое было, или всегда так будет. (In reply to Vera Blagoveschenskaya from comment #0) > При выполнении команды ntp-keygen ошибка: > OpenSSL version mismatch. Built against 101000af, you have 1010104f > Built against OpenSSL OpenSSL 1.1.0j 20 Nov 2018, using version OpenSSL > 1.1.1d 10 Sep 2019 Ну это просто древний баг в пакете ntp. (In reply to Sergey Y. Afonin from comment #6) > Я пока не знаю, зачем ntp это проверяет и выдаёт предупреждение. Но может в > сборочнице можно сделать какой-то список явных зависимостей на тему, что > требуется пересобирать? Если вы знаете, чтобы между пакетами были противоестественные зависимости, просто запишите их в спек-файле. А мы потом покритикуем. (In reply to Dmitry V. Levin from comment #7) > Если вы знаете, Если вы хотите, конечно. (In reply to Dmitry V. Levin from comment #7) > > Я пока не знаю, зачем ntp это проверяет и выдаёт предупреждение. Но может в > > сборочнице можно сделать какой-то список явных зависимостей на тему, что > > требуется пересобирать? > > Если вы знаете, чтобы между пакетами были противоестественные зависимости, > просто запишите их в спек-файле. А мы потом покритикуем. А что, в спек-файле есть такие зависимости, которые говорят, что "вон тот пакет надо непременно всегда пересобрать если я пересобрался"? :-) (In reply to Sergey Y. Afonin from comment #9) > (In reply to Dmitry V. Levin from comment #7) > > > > Я пока не знаю, зачем ntp это проверяет и выдаёт предупреждение. Но может в > > > сборочнице можно сделать какой-то список явных зависимостей на тему, что > > > требуется пересобирать? > > > > Если вы знаете, чтобы между пакетами были противоестественные зависимости, > > просто запишите их в спек-файле. А мы потом покритикуем. > > А что, в спек-файле есть такие зависимости, которые говорят, что "вон тот > пакет надо непременно всегда пересобрать если я пересобрался"? :-) В точности наоборот: в "том пакете" можно указать жёсткую зависимость. (In reply to Dmitry V. Levin from comment #10) > > А что, в спек-файле есть такие зависимости, которые говорят, что "вон тот > > пакет надо непременно всегда пересобрать если я пересобрался"? :-) > > В точности наоборот: в "том пакете" можно указать жёсткую зависимость. А как? Requires: name = %EVR очевидно же, что не годится. Нужна логика вида Requires: name (and rebuild if %EVR changed). (In reply to Sergey Y. Afonin from comment #11) > (In reply to Dmitry V. Levin from comment #10) > > > > А что, в спек-файле есть такие зависимости, которые говорят, что "вон тот > > > пакет надо непременно всегда пересобрать если я пересобрался"? :-) > > > > В точности наоборот: в "том пакете" можно указать жёсткую зависимость. > > А как? Requires: name = %EVR очевидно же, что не годится. Почему не годится? > Нужна логика вида Requires: name (and rebuild if %EVR changed). Что значит rebuild в Requires? (In reply to Dmitry V. Levin from comment #12) > > А как? Requires: name = %EVR очевидно же, что не годится. > > Почему не годится? Я может не очень понятно написал в 6-ом комментарии. Речь не про привязку к конкретной версии, а про пересборку с любой новой версией. Практически то же самое, что делает set version (не даёт пропустить задание без, как минимум, пересборки зависимого пакета), но в ситуации, котогда set version не срабатывает ввиду других причин необходимости, отличных от проверяемых set version. (In reply to Sergey Y. Afonin from comment #13) > (In reply to Dmitry V. Levin from comment #12) > > > > А как? Requires: name = %EVR очевидно же, что не годится. > > > > Почему не годится? > > Я может не очень понятно написал в 6-ом комментарии. Речь не про привязку к > конкретной версии, а про пересборку с любой новой версией. Практически то же > самое, что делает set version (не даёт пропустить задание без, как минимум, > пересборки зависимого пакета), но в ситуации, котогда set version не > срабатывает ввиду других причин необходимости, отличных от проверяемых set > version. Повторю ещё раз: - эта проверка в ntp очевидно неправильная; - в пакетах бывают (возможно, зря, но бывают) жёсткие привязки к версиям других пакетов. Посмотрите, например, gvfs.spec (In reply to Dmitry V. Levin from comment #14) > Повторю ещё раз: > - эта проверка в ntp очевидно неправильная; При чём тут конкретно ntp? Во-первых я уже привёл один пример другого пакета. Во-вторых зачем-то же сделали копирование пересборкой, а не оставили просто копирование. > - в пакетах бывают (возможно, зря, но бывают) жёсткие привязки к версиям > других пакетов. Посмотрите, например, gvfs.spec Привязка к версии в данном случае не рассматривается. И всё же это фичереквест для сборочничы, а не для какого-то конкретного пакета. Если он не может быть реализован, либо нужность его переоценена, надо закрыть, как WONTFIX. Пожалуйста, не надо перевешивать ошибки, найденные в конкретном пакете, на инфраструктуру. Пожалуйста не надо перевешивать на пакет заявку на фичу на инфраструктуру, которая иллюстрируется НЕ ошибкой на пакете. Данное сообщение на пакете ntp НЕ ЯВЛЯЕТСЯ ОШИБКОЙ и НЕ ВЛИЯЕТ НА РАБОТОСПОСОБНОСТЬ! Если кто-то ещё не понял, настоящей ошибкой на ntp тут было Verify RSA-MD5 certificate fails error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest Оно не имеет абсолютно никакого отношения к ПРЕДУПРЕЖДЕНИЮ про версию SSL и это Bug 38300. Если вы не хотите понимать, что я вам написал, то я не буду больше тратить на это время. Внепакетных зависимостей не бывает. (In reply to Dmitry V. Levin from comment #20) > Если вы не хотите понимать, что я вам написал, Я хорошо понимаю, что хотите сказать Вы, а вот Вы, очевидно, не понимаете, что хочу сказать я. Понятно только, что мы совершенно про разное. > то я не буду больше тратить на это время. Внепакетных зависимостей не бывает. Хорошо. на girar уже есть данные о том, какие пакеты что используют в runtime и при сборке. В принципе технически отправить на пересборку не должно быть сложным. Но - если у содержимого пакета есть runtime зависимость на версию другого пакета, а в rpm пакете такая зависимость не зафиксирована, то это ошибка. Нужно просто прописать у ntp более жёстку зависимость на версию openssl, с которой он собрался. В этом случае при сборке следующей версии openssl его сразу пересоберут. (In reply to Anton Farygin from comment #22) > В принципе технически отправить на пересборку не должно быть сложным. Но - > если у содержимого пакета есть runtime зависимость на версию другого пакета, > а в rpm пакете такая зависимость не зафиксирована, то это ошибка. > > Нужно просто прописать у ntp более жёстку зависимость на версию openssl, с > которой он собрался. > > В этом случае при сборке следующей версии openssl его сразу пересоберут. Как это сделать, не залезая в спек? (In reply to Sergey Y. Afonin from comment #23) > > В этом случае при сборке следующей версии openssl его сразу пересоберут. > > Как это сделать, не залезая в спек? Другими словами, есть ли в rpm макрос, который определяет что-то аналогичное %EVR, но для пакета из BuildRequires? Если есть, то я тогда не прав. А если нет, то тогда это фичереквест для сборочницы. Или rpm. (In reply to Dmitry V. Levin from comment #14) > Повторю ещё раз: > - эта проверка в ntp очевидно неправильная; > - в пакетах бывают (возможно, зря, но бывают) жёсткие привязки к версиям > других пакетов. Посмотрите, например, gvfs.spec Есть и другие примеры, помимо gvfs.spec: $ git grep '^Requires: [^=]* = %{get_SVR' j/javazi/javazi.spec:Requires: tzdata = %{get_SVR tzdata} $ git grep -Fw '%{get_dep' f/fuse-7z/fuse-7z.spec:Requires: %{get_dep fuse} g/gvfs/gvfs.spec:Requires: %{get_dep fuse3} i/itest/itest.spec:Requires: %{get_dep libqt4-core} k/kde4-basket/basket.spec:Requires: %{get_dep kde4libs} p/polkit-qt-1/policykit-qt.spec:Requires: %{get_dep libqt4-core} s/sawfish/sawfish.spec:Requires: %{get_dep rep-gtk} Зависит от требуемой степени жёсткости. (In reply to Dmitry V. Levin from comment #25) > > других пакетов. Посмотрите, например, gvfs.spec Тут почти всё задано жёстко. Есть get_dep(), но на общем объёме не заметно. > Есть и другие примеры, помимо gvfs.spec: > > $ git grep '^Requires: [^=]* = %{get_SVR' > j/javazi/javazi.spec:Requires: tzdata = %{get_SVR tzdata} А вот это то самое, да. $ git grep '^Requires: [^%]*%{get_version'
a/attica/attica.spec:Requires: libqt4-core >= %{get_version libqt4-core}
k/kde4-kmldonkey/kmldonkey.spec:Requires: kde4libs >= %{get_version kde4libs}
k/kde4-smb4k/smb4k.spec:Requires: kde4libs >= %{get_version kde4libs}
k/kdevplatform/kdevplatform.spec:Requires: kde4libs >= %{get_version kde4libs}
k/kdevplatform/kdevplatform.spec:Requires: kde4libs >= %{get_version kde4libs}
k/kdevplatform/kdevplatform.spec:Requires: kde4libs >= %{get_version kde4libs}
k/kdevplatform/kdevplatform.spec:Requires: kde4libs >= %{get_version kde4libs}
k/kdevplatform/kdevplatform.spec:Requires: kde4libs >= %{get_version kde4libs}
l/libtag-extras/libtag-extras.spec:Requires: libtag >= %{get_version libtag}
l/licq/licq.spec:Requires: kde4libs >= %{get_version kde4libs}
l/licq/licq.spec:Requires: libqt4-core >= %{get_version libqt4-core}
p/phonon/phonon.spec:Requires: libqt4-core >= %{get_version libqt4-core}
p/polkit-qt-1/policykit-qt.spec:Requires: libqt4-core >= %{get_version libqt4-core}
q/qimageblitz/qimageblitz.spec:Requires: libqt4-core >= %{get_version libqt4-core}
В общем, много есть разных примеров.
Достаточно было grep "^%get_" /usr/lib/rpm/x86_64-linux/macros но спасибо. :-) (In reply to Sergey Y. Afonin from comment #28) > Достаточно было grep "^%get_" /usr/lib/rpm/x86_64-linux/macros Но что-то не получается... Requires: libcrypto = %{get_version libssl-devel} Локально это работает, но вот в сборочнице не очень: error: line 51: Version required: Requires: libcrypto = Я правильно понимаю, что не работать это может только по причине отсутствия libssl-devel на момент исполнения? Но зависимость на libssl-devel уже и через BuildPreReq описал. Сейчас в последней итерации попробовал в get_version написать libcrypto1.1, то же самое. (In reply to Sergey Y. Afonin from comment #29) > (In reply to Sergey Y. Afonin from comment #28) > > > Достаточно было grep "^%get_" /usr/lib/rpm/x86_64-linux/macros > > Но что-то не получается... > > Requires: libcrypto = %{get_version libssl-devel} > > Локально это работает, но вот в сборочнице не очень: > error: line 51: Version required: Requires: libcrypto = В дополнение ко всему, пакета libcrypto ещё и нет. Попробуйте %(rpmquery --qf 'Requires: %%{NAME} = %%{VERSION}' libcrypto1.1) (In reply to Dmitry V. Levin from comment #30) > > Requires: libcrypto = %{get_version libssl-devel} > > > > Локально это работает, но вот в сборочнице не очень: > > error: line 51: Version required: Requires: libcrypto = > > В дополнение ко всему, пакета libcrypto ещё и нет. Попробуйте Так ругается же на отсутствие версии, а не пакета. По поводу пакета: в openssl есть "Provides: libcrypto = %version-%release". > %(rpmquery --qf 'Requires: %%{NAME} = %%{VERSION}' libcrypto1.1) Так работает. А Requires: libcrypto1.1 = %{get_version libcrypto1.1} не работает тоже, хотя я не очень понимаю разницу в этом случае. Вообще привязка к версии в имени - это то что хочется избежать как раз. В принципе вот это тоже сработало, и вроде бы как пока задумано: %(rpmquery --qf 'Requires: libcrypto = %%{VERSION}' libssl-devel) (In reply to Sergey Y. Afonin from comment #31) > Вообще привязка к версии в имени - это то что хочется избежать как раз. В > принципе вот это тоже сработало, и вроде бы как пока задумано: > > %(rpmquery --qf 'Requires: libcrypto = %%{VERSION}' libssl-devel) libcrypto - это версионированный provides, так что по идее тоже должно работать. |
Description
Vera Blagoveschenskaya 2020-03-27 15:45:41 MSK