LINUX.ORG.RU

Команда patch не переименовывает файл

 


0

1

Я тут последовательно обновляю ядро 3.16.7 до 3.16.85, и на 3.16.9 произошёл затык. Вот фрагмент патча:

--- a/drivers/gpu/drm/nouveau/core/subdev/gpio/nv92.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/gpio/nv94.c
@@ -25,7 +25,7 @@
 #include "priv.h"
 
 void
-nv92_gpio_intr_stat(struct nouveau_gpio *gpio, u32 *hi, u32 *lo)
+nv94_gpio_intr_stat(struct nouveau_gpio *gpio, u32 *hi, u32 *lo)
 {
 	u32 intr0 = nv_rd32(gpio, 0x00e054);
 	u32 intr1 = nv_rd32(gpio, 0x00e074);

Как видите, патч переименовывает файл. Но файл остаётся под тем же именем. Патчинг производится командой patch -s -F0 -E -p1 --no-backup-if-mismatch -i $PATCH_DIR Почитал в мане описания параметров, вроде ни один не должен к такому приводить. Может наоборот, надо что-то добавить?

★★★★★

Последнее исправление: ZenitharChampion (всего исправлений: 2)

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

PPP328 ★★★★★
()
Ответ на: комментарий от ZenitharChampion

patch не переименовывает файлы. Ты что-то делаешь неправильно. Или предполагается этот «патч» применять каким-то другим способом.

TeopeTuK ★★★★
()
Ответ на: комментарий от anonymous

Изначально я повысил версию ядра с 3.0 аж до 4.9, но появились проблемы. Поэтому я решил осуществлять постепенную миграцию на новое ядро, начав с 3.16.

ZenitharChampion ★★★★★
() автор топика
Ответ на: комментарий от TeopeTuK

> patch не переименовывает файлы.

Странно. И ведь это же официальный патч с kernel.org. Как его тогда накладывать?

// На самом деле не с kernel.org, а с launchpad.net, потому что Canonical выпускала патчи с 3.16.8 по 3.16.35. Потом kernel.org просто продолжил это. Тем не менее, изменение было бэкпортировано из 3.17, а значит патч, переименовывающий файл, может быть и на kernel.org тоже.

Я видел такие патчи (переименовывающие файл) и раньше. Например этот патч переименовывает «apparmor-compatibility-patch-for-v5-interface» в «apparmor-profiles-seq_file» (первая часть патча). Раньше файл назывался «добавление совместимости с v5 интерфейсом», а теперь «seq file», и мне непонятно, какой из них тащить в 3.16: старый или новый? Выглядит, как будто новый не добавляет обратной совместимости с нужной мне версией AppArmor.

Но что-то я отошёл от темы. В идеале, нужно внести изменение в файл apply-patches, чтобы вместо patch использовался git apply из комментария xaizek. Но это изменение слишком глобальное, и неизвестно, какие «подводные камни» привнесёт с собой. Поэтому я или внесу изменение в файл patch-3.16.9, или в SPEC-файл внесу костыль, который переименует файл. Думаю, это разовый случай, так что один раз можно.

ZenitharChampion ★★★★★
() автор топика
Последнее исправление: ZenitharChampion (всего исправлений: 6)
Ответ на: комментарий от ZenitharChampion

Странно. И ведь это же официальный патч с kernel.org. Как его тогда накладывать?

В идеале, нужно внести изменение в файл apply-patches

Так у тебя ванильные исходники или из пакета для OpenSUSE? Или ты сам пытаешься собрать пакет для OpenSUSE из ванильных исходников?

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

proud_anon ★★★★★
()
Ответ на: комментарий от proud_anon

Я взял ядро 3.16.7 из openSUSE 13.2. В репозитории Updates его обновляли 3 года, с 2014 по 2017 год. Не обновляя при этом номер версии. Фактически, так как директория patches.fixes насчитывает сотни патчей внутри себя, это никакое не 3.16.7, а примерно 3.16.50. Работает, кстати, замечательно: IOMMU, Xen, всё не глючит.

Я добавляю патчи из апстрима. Добавление каждого патча сопровождается удалением всех патчей SUSE, которые дублируют те, которые были приняты в апстрим (чейнжлоги выглядят так). В теории, после добавления последнего патча, директория patches.fixes должна остаться пустой.

ZenitharChampion ★★★★★
() автор топика
Последнее исправление: ZenitharChampion (всего исправлений: 3)
Ответ на: комментарий от ZenitharChampion

Неужели у тебя нет какого-нибудь более продуктивного занятия?

В репозитории Updates его обновляли 3 года, с 2014 по 2017 год. Не обновляя при этом номер версии.

Ну вот теперь ты понимаешь, почему в дистрибутивах так делают.

Если очень надо, то, я думаю, надо следовать практике, которая принята в SUSE. Я не знаю, как именно там делают, но предполагаю, что создают новый пакет на основе новых исходников и переносят в него свои патчи, если они ещё нужны.

proud_anon ★★★★★
()
git init
git add .
git commit -m init
git apply patch

А так у тебя ж и так ведро в гит, то есть просто git apply.

invy ★★★★★
()
Последнее исправление: invy (всего исправлений: 1)
Ответ на: комментарий от proud_anon

> Ну вот теперь ты понимаешь, почему в дистрибутивах так делают.

В openSUSE как раз-таки добавляют патчи из апстрима. Выглядит это так: выходит 0-day уязвимость - в patches.fixes/ появляется патч. Патч висит там до того момента, пока не выпускается кумулятивный патч от kernel.org. Тогда патч от kernel.org принимают, а ворох файлов удаляют.

С 3.16 был особый случай, потому что апстрим дропнул эту версию довольно рано. Поэтому и 3.16.7, хотя фактически 3.16.50. А так, например, у ядер 4.4, минорная версия довольно большая.

// Грег возобновил поддержку 3.16 спустя где-то год после прекращения. Когда кончилась поддержка Debian 8, тогда и кончилась поддержка 3.16 на kernel.org. Сейчас действует LTSS-поддержка Debian 8, но там обновили ядро до 4.9.

Так что касаемо сабжевого вопроса. Я наверное вставлю «костыль», а скрипт обновлять не буду. Если кто-то умеет грамотно обновить скрипт, чтобы сделать более правильно - буду рад :-) Заодно и в апстрим SUSE двинете его.

ZenitharChampion ★★★★★
() автор топика
Последнее исправление: ZenitharChampion (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.