36872 2019-06-06 12:24:10 +0300 сломался pkgfind(kernel-image-std-def#1:4.19.46-alt1) 2019-06-13 14:26:36 +0300 1 1 4 Development Sisyphus apt unstable all Linux CLOSED WORKSFORME P3 normal --- 35529 1 zerg imz boyarsh glebfm imz ldv placeholder vt qa-sisyphus oldest_to_newest 182263 0 zerg 2019-06-06 12:24:10 +0300 pkgfind() в скриптах перестал находить пакет ядра при агрументе вида kernel-image-std-def#1:4.19.46-alt1 Предлагаю починить или хотя бы сказать, что указать для rpmbuiqry -qf --qf '%{ХРЕНЗНАЕТ}' /boot/vmlinuz-4.19.46-std-def-alt1` чтоб добыть тот ID. Конкретно, в apt-scripts-nvidia проблема. 182266 1 imz 2019-06-06 12:32:48 +0300 Я ещё посмотрю в apt-scripts-nvidia -- что можно сделать попереносимее. > Предлагаю починить или хотя бы сказать, что указать для rpmbuiqry -qf --qf '%{ХРЕНЗНАЕТ}' /boot/vmlinuz-4.19.46-std-def-alt1` чтоб добыть тот ID. Ну да, я бы исходил из того, что нельзя полагаться на конкретный формат этого ID. (Как его сформирует APT, может меняться от версии к версии.) Например, в remove-old-kernels теперь даётся команда apt-get remove kernel-image-std-def=1:4.19.46-alt1 (со знаком "равно"). 182267 2 zerg 2019-06-06 12:49:59 +0300 (В ответ на комментарий №1) > kernel-image-std-def=1:4.19.46-alt1 (со знаком "равно"). Для pkgfind() не работает. В каком формате можно указать для pkgfind()? 182274 3 zerg 2019-06-06 14:52:02 +0300 При этом pkgfind("kernel-image-std-def#1:4.19.46-alt1@1559056711") работает 182287 4 imz 2019-06-07 12:01:18 +0300 (In reply to comment #0) > pkgfind() в скриптах перестал находить пакет ядра при агрументе вида > kernel-image-std-def#1:4.19.46-alt1 > > Предлагаю починить или хотя бы сказать, что указать для > rpmbuiqry -qf --qf '%{ХРЕНЗНАЕТ}' /boot/vmlinuz-4.19.46-std-def-alt1` > чтоб добыть тот ID. > > Конкретно, в apt-scripts-nvidia проблема. Предлагаю присвоить значение (pkg_kernel_prov_name, pkg_kernel_prov_verstr) прямо из результата os.getexecout("rpmquery-strictdep -f /boot/vmlinuz-" .. kernel_name) разрезав по знаку =. Вместо вот этого кода поиска Provides пакета с ядром (rpmquery-strictdep тоже ищет его лучший Provides): kernel_pkg_nameversion = os.getexecout("rpmquery -f --qf '%{NAME}#%{EPOCH}:%{VERSION}-%{RELEASE}' /boot/vmlinuz-" .. kernel_name) pkg_kernel = pkgfind(kernel_pkg_nameversion) if pkg_kernel == nil then kernel_pkg_nameversion = os.getexecout("rpmquery -f --qf '%{NAME}' /boot/vmlinuz-" .. kernel_name) pkg_kernel = pkgfind(kernel_pkg_nameversion) if pkg_kernel == nil then apterror(_("Package not found for your current kernel ") .. kernel_name .. " .") return end end -- print("Kernel " .. kernel_pkg_nameversion) pkg_kernel_name = pkgname(pkg_kernel) pkg_kernel_ver = pkgvercur(pkg_kernel) pkg_kernel_prov_name = {} pkg_kernel_prov_verstr = {} kernel_provlist = verprovlist(pkg_kernel_ver) for i, kprov in ipairs(kernel_provlist) do if string.find(kprov.name, "kernel-image-", 0, true) == 1 then pkg_kernel_prov_name = kprov.name pkg_kernel_prov_verstr = kprov.verstr -- print("Kernel provide " .. pkg_kernel_prov_name .. "#" .. pkg_kernel_prov_verstr) end end Пример работы в p8 (пакет rpmquery-strictdep): [root@prodesk ~]# rpmquery-strictdep -f /boot/vmlinuz-4.4.14-std-def-alt0.M80P.1 kernel-image-std-def = 1:4.4.14-alt0.M80P.1 [root@prodesk ~]# rpmquery-strictdep -f /boot/vmlinuz-4.9.180-std-def-alt0.M80P.1 kernel-image-std-def = 1:4.9.180-alt0.M80P.1 Пример работы в Sisyphus: [root@prodesk /]# rpmquery-strictdep -f /boot/vmlinuz-5.0.19-un-def-alt1 kernel-image-un-def = 1:5.0.19-alt1:sisyphus+230627.100.1.3 Пример работы в p8 в другом режиме: [root@prodesk ~]# allow_deps_with_beginning_dot=1 rpmquery-strictdep -f /boot/vmlinuz-4.9.180-std-def-alt0.M80P.1 .p8.231262.100.1.1-kernel-image-std-def-1:4.9.180-alt0.M80P.1 [root@prodesk ~]# Я могу попробовать реализовать эту идею чуть позже. 182289 5 zerg 2019-06-07 16:49:00 +0300 (В ответ на комментарий №4) > Вместо вот этого кода поиска Provides пакета с ядром (rpmquery-strictdep тоже > ищет его лучший Provides): 1. Этот код у меня работает с момента появления пакета и я уже обновлял его в c7, например. Не хочу попасть когда-нибудь на несовместимость. 2. Ты по сути предлагаешь всё переписывать на bash. 3. Скриптинг от этого не починится. Эти идентификаторы негде не возьмёшь даже чтоб захакать. 182290 6 imz 2019-06-07 17:11:06 +0300 (In reply to comment #5) > (В ответ на комментарий №4) > > Вместо вот этого кода поиска Provides пакета с ядром (rpmquery-strictdep тоже > > ищет его лучший Provides): > 1. Этот код у меня работает с момента появления пакета и я уже обновлял его в > c7, например. Не хочу попасть когда-нибудь на несовместимость. Я сделал rpmquery-strictdep, чтобы облегчить переносимость. (Для потребностей kernel-build-tools и rpmrebuild-arepo) $ ls -1 /ALT/*/noarch/RPMS.classic/rpmquery-strictdep-* /ALT/c7.1/noarch/RPMS.classic/rpmquery-strictdep-1-alt1.noarch.rpm /ALT/c8.1/noarch/RPMS.classic/rpmquery-strictdep-1-alt1.noarch.rpm /ALT/p8/noarch/RPMS.classic/rpmquery-strictdep-1-alt1.noarch.rpm /ALT/Sisyphus/noarch/RPMS.classic/rpmquery-strictdep-1-alt1.noarch.rpm $ > 2. Ты по сути предлагаешь всё переписывать на bash. Та часть, которая вызывает rpm -qf и получает некую полезную информацию. (Это необязательно APT-овый идентификатор для твоего скрипта судя по нему.) Этот вызов и так делается с помощью внешнего инструмента, потому что владельца файла через APT не получается определить, надо обращаться к rpm. > 3. Скриптинг от этого не починится. Эти идентификаторы негде не возьмёшь даже > чтоб захакать. Судя по скрипту, нам необязательно брать эти идентификаторы. (Сконструировать --qf можно, но это будет не очень переносимо.) Там же дальше в том куске, который я процитировал, в итоге нам интересен только Provides, который мы сравниваем с Requires пакетов с модулями. Идентификатор для других целей вроде не нужен. pkg_kernel_prov_name = kprov.name pkg_kernel_prov_verstr = kprov.verstr 182291 7 zerg 2019-06-07 17:23:08 +0300 (В ответ на комментарий №6) > > 3. Скриптинг от этого не починится. > Судя по скрипту Нет. Я имел ввиду, что желания соваться в скриптинг apt более не предвидится с такими плясками. > Я сделал rpmquery-strictdep, чтобы облегчить переносимость. (Для потребностей > kernel-build-tools и rpmrebuild-arepo) Уже хорошо. 182292 8 imz 2019-06-07 17:37:43 +0300 (In reply to comment #7) > (В ответ на комментарий №6) > > > 3. Скриптинг от этого не починится. > > Судя по скрипту > Нет. Я имел ввиду, что желания соваться в скриптинг apt более не предвидится с > такими плясками. Со скриптингом не ожидается проблем, если в скрипте используются только внутренние сущности apt. Все такие скрипты после последних изменений будут так же хорошо работать, даже лучше (потому что verstrcmp будет правильно определять направление upgrade -- раньше он не мог учесть buildtime, хотя у нас быо позволено иметь пакеты, различающиеся только им). Если используются не только внутренние сущности APT, то тогда ой, может не совпасть. (Я вижу другой потенциальный выход для обсуждаемого скрипта в том, чтобы делать аналог rpm -qf функциями apt, но таких мне неизвестно.) 182293 9 imz 2019-06-07 17:47:14 +0300 (In reply to comment #8) > (In reply to comment #7) > > (В ответ на комментарий №6) > > > > 3. Скриптинг от этого не починится. > > > Судя по скрипту > > Нет. Я имел ввиду, что желания соваться в скриптинг apt более не предвидится с > > такими плясками. > > Со скриптингом не ожидается проблем, если в скрипте используются только > внутренние сущности apt. Все такие скрипты после последних изменений будут так > же хорошо работать, даже лучше (потому что verstrcmp будет правильно определять > направление upgrade -- раньше он не мог учесть buildtime, хотя у нас быо > позволено иметь пакеты, различающиеся только им). В lua, правда, кажется, не хватет помимо verstrcmp() (интерфейса к CmpVersion(), определяющего направление upgrade) аналогичного интерфейса к CheckDep() для определения удовлетворения зависимости. 182295 10 zerg 2019-06-07 17:53:07 +0300 (В ответ на комментарий №8) > Я вижу другой потенциальный выход для обсуждаемого скрипта в том, > чтобы делать аналог rpm -qf функциями apt Для обсуждаемого скрипта я бы сразу попросил current_kernel_pkg(). А так да. pkg_by_file() и installed_kernel_pkgs() было бы прекрасно. 182324 11 zerg 2019-06-10 12:10:47 +0300 (В ответ на комментарий №8) > Если используются не только внутренние сущности APT, то тогда ой, может не совпасть. Чтобы apt обслуживал сам себя -- вообще не обязательно на lua делать, а в остальных случаях будет необходимость использования внешних сущностей. (В ответ на комментарий №9) > В lua, правда, кажется, не хватет помимо verstrcmp() (интерфейса к > CmpVersion(), определяющего направление upgrade) аналогичного интерфейса к > CheckDep() для определения удовлетворения зависимости. Это да. Чтобы можно было определить зависимость, например, по version-release, не указывая epoch, disttag и т.д.. В spec-файле ж можно зависимости без disttag указывать. 182325 12 zerg 2019-06-10 12:11:53 +0300 Сделал через rpmquery-strictdep. 182336 13 zerg 2019-06-10 17:26:58 +0300 (В ответ на комментарий №9) > В lua, правда, кажется, не хватет помимо verstrcmp() (интерфейса к > CmpVersion(), определяющего направление upgrade) аналогичного интерфейса к > CheckDep() для определения удовлетворения зависимости. Какой-нибудь resolvedep(str1, str2), чтоб говорило больше, меньше или удовлетворяет. Причём, полагаю, именно строковые параметры, т.к. вытащить строку из зависимости легко при помощи dep.verstr . 182337 14 zerg 2019-06-10 17:39:41 +0300 (В ответ на комментарий №13) > Какой-нибудь resolvedep(str1, str2), чтоб говорило больше, меньше или удовлетворяет. Ой, в зависимости же не только версия. lazyverstrcmp(str1, str2) :-) 182387 15 imz 2019-06-13 14:26:36 +0300 (In reply to comment #12) > Сделал через rpmquery-strictdep. Спасибо! Добавил соотвествующий Conflicts во все новые apt (Sisyphus, p9, p8, c8.1, c7.1) вместе с копированием этого пакета в те бранчи.