From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 To: devel@lists.altlinux.org References: <302a1202-cc13-f857-65e5-aed6103953df@dumalogiyamail.ru> From: mikhailnov@altlinux.org Message-ID: <215b4795-a350-daca-15f2-d25446388eaf@dumalogiyamail.ru> Date: Tue, 26 Nov 2019 04:41:20 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: <302a1202-cc13-f857-65e5-aed6103953df@dumalogiyamail.ru> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru-RU Subject: Re: [devel] =?utf-8?b?0J7QsdC90L7QstC70LXQvdC40LUgcmVkaXMg0LIgcDg=?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2019 01:41:28 -0000 Archived-At: List-Archive: List-Post: 26.11.2019 04:22, mikhailnov@altlinux.org пишет: > 26.11.2019 01:32, Leonid Krivoshein пишет: >> Всем привет! >> >> >> Извиняюсь за нюбовский вопрос. Каковы действия при бэкпортировании в p8? >> Собрал тестовое задание #241616. Достаточно проверить с такими >> зависимостями: >> >> $ apt-cache whatdepends redis >> redis-3.0.7-alt1@1454758009 >>   python-module-docker-registry-0.6.1-alt1@1382307574 >>     Требует: redis >> >> Просто, боюсь, с этой штукой на самом деле много чего может отъехать. >> Но без тестовой пересборки не представляю, как это определить. >> Просили закрыть CVE в баге #37533, а бранч "стабильный". >> >> > См. https://security-tracker.debian.org/tracker/CVE-2019-10193 и > https://security-tracker.debian.org/tracker/CVE-2019-10192 > > Их исправления бекпортировали в 3.2.13, которая гораздо ближе к 3.0.7 > в p8, чем 5.0 из сизифа. Наверняка соответствующие коммиты без правок > или с минимальным редиффом лягут на 3.0.7 патчами. > > > https://raw.githubusercontent.com/antirez/redis/3.2/00-RELEASENOTES > ================================================================================ > > Redis 3.2.13     Released Mon Mar 18 17:24:10 CEST 2019 > ================================================================================ > > > Ciritcal fixes backported from Redis 5. Когда нужно бекпортировать что-то, я обычно делаю так: git clone апстримные_исходники git tag | grep версия git checkout tags/<найденный_тег_с_целевой_версией_для_бекпорта> git checkout -b patched-<версия> git cherry-pick <хеш коммита для бекпортирования> Если лег сразу, то отлично, иначе в git status смотрю, где возникли проблемы, правлю их (они помечаются ====== в текстовых файлах), затем: git commit -a Открывается редактирование описания коммита. Туда дописываю что-то вроде: Backport of upstream commit to systemd-230 и при необходимости описание изменений относительно оригинального коммита, например, "dropped tests". Затем делаю git format-patch -1 -s -s - чтобы в патч с Author != я была добавлена пометка о моем участии, чтобы другим людям было понятнее, откуда такой патч взялся. В крупных проектах типа systemd иногда приходится бекпортировать несколько десятков коммитов для закрытия одной CVE, такие действия чреваты тем, что всплывут какие-нибудь косяки: опечатки при бекпортировании, нарушение логики работы, если бекпортирование остановил на таком состоянии, которое было затем изменено в апстриме, т.к. было багованным, и т.д. В таких случаях обычно цепочка коммитов получается задом на перед, т.к. после каждого бекпорта проверяется сборка (а в Альте и в etersoft-build-utils, кстати, есть готовые интеграции rpm с ccache), если коммитов оказалось недостаточно, то бекпортируется следующий. В случае с redis посмотрите, насколкьо большие правки были, может, там проще просто обновить с 3.х до 3.2 и не мучаться, а, может, можно несколько маленьких коммитов приложить, и всё.