33151 2017-02-20 16:44:22 +0300 should use /var/run/ instead of /var/lib/run/ 2017-10-26 21:16:03 +0300 1 1 4 Development Sisyphus cups-filters unstable all Linux CLOSED FIXED P3 normal --- 10382 1 imz rider aen lav ldv mike rider vseleznv qa-sisyphus oldest_to_newest 162018 0 imz 2017-02-20 16:44:22 +0300 cups-filters-1.13.3-alt1.S1.x86_64 has hard-coded wrong path: # rpm -qa '*cups*' -l | xargs fgrep /var/lib/run 2>/dev/null /etc/cups/cups-browsed.conf:# DomainSocket /var/lib/run/cups/cups.sock Binary file /usr/sbin/cups-browsed matches # rpm -qf /etc/cups/cups-browsed.conf /usr/sbin/cups-browsed cups-filters-1.13.3-alt1.S1.x86_64 cups-filters-1.13.3-alt1.S1.x86_64 # Of course, there is no such as /var/lib/run -- it should be /var/run . 165225 1 mike 2017-08-13 19:51:51 +0300 Опять %_localstatedir кусается... 166545 2 ldv 2017-10-25 07:00:49 +0300 rpm-build-4.0.4-alt104 produces the following diagnostics: Checking contents of files in /usr/src/tmp/cups-filters-buildroot/ (default) /usr/src/tmp/cups-filters-buildroot/etc/cups/cups-browsed.conf /usr/src/tmp/cups-filters-buildroot/usr/sbin/cups-browsed 028-check_contents.brp: WARNING: Contents of files listed above match pattern /var/lib/(cache|lib|lock|log|nis|run|spool|www|yp)/ 166549 3 rider 2017-10-25 08:12:18 +0300 Дим, я одно не понял - ты %_localstatedir переопределишь в /var или нет ? 166550 4 ldv 2017-10-25 08:17:12 +0300 (In reply to comment #3) > Дим, я одно не понял - ты %_localstatedir переопределишь в /var или нет ? https://bugzilla.altlinux.org/show_bug.cgi?id=10382#c34 https://lists.altlinux.org/pipermail/devel/2017-October/203244.html 166552 5 rider 2017-10-25 08:28:42 +0300 предложил бы какой-то аналог. Ну или в %configure поправить %_localstatedir на %_var. А то сейчас получается так что у нас по умолчанию %configure раскрывается в --localstatedir=/var/lib \ и надо или патчить _все_ пакеты или переопределять %_localstatedir в спеке. И то и то совсем неочевидно. 166553 6 ldv 2017-10-25 08:38:00 +0300 (In reply to comment #5) > предложил бы какой-то аналог. Есть несколько очевидных аналогов, но универсального не видно. > Ну или в %configure поправить %_localstatedir на %_var. Это было бы равносильно изменению значения %_localstatedir примерно в половине случаев. > А то сейчас получается так что у нас по умолчанию %configure раскрывается в > --localstatedir=/var/lib Да, и это не хотелось бы менять по соображениям обратной совместимости. > и надо или патчить _все_ пакеты Видимо, не все, а только те, которые рассчитывают на то, что %_localstatedir раскрывается в /var. Вообще использование макросов с красивыми длинными именами вместо фактических значений -- это зачастую лукавство, потому что поменять значения этих макросов практически нереально. > или переопределять %_localstatedir в спеке. Это один из вариантов, который в некоторых случаях может оказаться оптимальным. > И то и то совсем неочевидно. Хорошего универсального решения не видно. Но скоро должно стать понятно, насколько криво сейчас собираются пакеты в Сизифе. 166554 7 rider 2017-10-25 08:42:03 +0300 > > И то и то совсем неочевидно. > > Хорошего универсального решения не видно. > Но скоро должно стать понятно, насколько криво сейчас собираются пакеты в > Сизифе. Предлагаю всё-таки дополнительно проверить последствия переопределения %_localstatedir в /var, что бы понять, сколько пакетов сломается и при таком исправлении. 166556 8 ldv 2017-10-25 09:01:48 +0300 (In reply to comment #7) > > > И то и то совсем неочевидно. > > > > Хорошего универсального решения не видно. > > Но скоро должно стать понятно, насколько криво сейчас собираются пакеты в > > Сизифе. > > Предлагаю всё-таки дополнительно проверить последствия переопределения > %_localstatedir в /var Каким образом? В нынешней ситуации можно сделать, скажем, grep -Elre '/var/lib/(cache|lib|lock|log|nis|run|spool|www|yp)/' %buildroot А вот какие /var/что-то-там искать в обратном случае, неочевидно, потому список открытый. Можно, наверное, взять все 184 каталога, которые сейчас упакованы в /var/lib/, и проверить, не станут ли они упакованы или просто упоминаться напрямую в /var/, но это будет более хрупкая проверка с точки зрения ложных срабатываний. 166557 9 rider 2017-10-25 09:28:19 +0300 Можно было бы при ежедневной пересборке сравнивать содержимое предыдущего пакета с новым и в случае разницы - куда-то её записывать с информированием ментейнера. 166558 10 rider 2017-10-25 09:32:07 +0300 Под содержимым имеется в виду расположение файлов. Т.е. - если у нас в одном состоянии репозитория пакет собирался с одним содержимым, а после изменения состояния репозитория - листинг пакета стал другим, то это скорее всего можно как минимум считать ошибкой, которую надо исправить пересборкой пакета в новой среде. 166559 11 ldv 2017-10-25 09:37:14 +0300 (In reply to comment #9) > Можно было бы при ежедневной пересборке сравнивать содержимое предыдущего > пакета с новым и в случае разницы - куда-то её записывать с информированием > ментейнера. Если бы содержимое многих пакетов не менялось просто так в результате тестовой пересборки, в этом мог бы быть практический смысл. 166560 12 ldv 2017-10-25 09:40:38 +0300 (In reply to comment #10) > Под содержимым имеется в виду расположение файлов. > > Т.е. - если у нас в одном состоянии репозитория пакет собирался с одним > содержимым, а после изменения состояния репозитория - листинг пакета стал > другим, то это скорее всего можно как минимум считать ошибкой, которую надо > исправить пересборкой пакета в новой среде. Сейчас сравнение листинга пакета в репозитории с листингом свежепересобранного пакета происходит по окончании тестовой пересборки и результат добавляется в лог. Но пример с cups-filters, который мы тут обсуждаем, демонстрирует, что сравнения листинга недостаточно, нужно анализировать ещё и содержимое файлов. 166611 13 ldv 2017-10-26 21:15:34 +0300 А чего это баг репорт не автозакрылся? 166612 14 rider 2017-10-26 21:16:03 +0300 потому что я забыл про него упомнянуть.