* [devel] Обновление redis в p8
@ 2019-11-25 22:32 Leonid Krivoshein
2019-11-26 1:22 ` mikhailnov
0 siblings, 1 reply; 7+ messages in thread
From: Leonid Krivoshein @ 2019-11-25 22:32 UTC (permalink / raw)
To: ALT Linux Team development discussions
Всем привет!
Извиняюсь за нюбовский вопрос. Каковы действия при бэкпортировании в p8?
Собрал тестовое задание #241616. Достаточно проверить с такими
зависимостями:
$ apt-cache whatdepends redis
redis-3.0.7-alt1@1454758009
python-module-docker-registry-0.6.1-alt1@1382307574
Требует: redis
Просто, боюсь, с этой штукой на самом деле много чего может отъехать.
Но без тестовой пересборки не представляю, как это определить.
Просили закрыть CVE в баге #37533, а бранч "стабильный".
--
Best regards,
Leonid Krivoshein.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [devel] Обновление redis в p8
2019-11-25 22:32 [devel] Обновление redis в p8 Leonid Krivoshein
@ 2019-11-26 1:22 ` mikhailnov
2019-11-26 1:41 ` mikhailnov
0 siblings, 1 reply; 7+ messages in thread
From: mikhailnov @ 2019-11-26 1:22 UTC (permalink / raw)
To: devel
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [devel] Обновление redis в p8
2019-11-26 1:22 ` mikhailnov
@ 2019-11-26 1:41 ` mikhailnov
0 siblings, 1 reply; 7+ messages in thread
From: mikhailnov @ 2019-11-26 1:41 UTC (permalink / raw)
To: devel
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 <hash> to systemd-230
и при необходимости описание изменений относительно оригинального
коммита, например, "dropped tests".
Затем делаю git format-patch -1 -s
-s - чтобы в патч с Author != я была добавлена пометка о моем участии,
чтобы другим людям было понятнее, откуда такой патч взялся.
В крупных проектах типа systemd иногда приходится бекпортировать
несколько десятков коммитов для закрытия одной CVE, такие действия
чреваты тем, что всплывут какие-нибудь косяки: опечатки при
бекпортировании, нарушение логики работы, если бекпортирование остановил
на таком состоянии, которое было затем изменено в апстриме, т.к. было
багованным, и т.д. В таких случаях обычно цепочка коммитов получается
задом на перед, т.к. после каждого бекпорта проверяется сборка (а в
Альте и в etersoft-build-utils, кстати, есть готовые интеграции rpm с
ccache), если коммитов оказалось недостаточно, то бекпортируется следующий.
В случае с redis посмотрите, насколкьо большие правки были, может, там
проще просто обновить с 3.х до 3.2 и не мучаться, а, может, можно
несколько маленьких коммитов приложить, и всё.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [devel] Обновление redis в p8
@ 2019-11-26 12:46 ` mikhailnov
2019-11-26 14:11 ` Sergey Afonin
0 siblings, 2 replies; 7+ messages in thread
From: mikhailnov @ 2019-11-26 12:46 UTC (permalink / raw)
To: devel
26.11.2019 13:57, Leonid Krivoshein пишет:
>
>
> 26.11.2019 4:41, mikhailnov@altlinux.org пишет:
>> 26.11.2019 04:22, mikhailnov@altlinux.org пишет:
>>> 26.11.2019 01:32, Leonid Krivoshein пишет:
>>>> [...]
>>>> Просто, боюсь, с этой штукой на самом деле много чего может отъехать.
>>>> Но без тестовой пересборки не представляю, как это определить.
>>>> Просили закрыть 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 патчами.
>>>
>
> Это понятно. Вопрос-то был в определении того, что стоит проверить.
> Вообще, просили обновить версию в p8.
> Для c8/c8.1, вероятно, именно так и стоило бы поступить: поднять до
> 3.2.13.
> Но для p8 хотелось бы рискнуть поднять побольше -- взял из p9
> последнюю версию.
Вопрос довольно странный, при таком большом поднятии версии в
_стабильном_ бранче надо прочитать все changelog-и между версиями и,
если они недостаточно подробные, изучить коммиты, а затем собрать новую
версию, откатив какие-либо ломающие совместимость правки и/или
задействовать сборочные опции, улучшающие совместимость, при наличии
таковых. При обновлении systemd с 230 до 243 в rosa2016.1 это заняло
несколько недель. Риск странный. Раз вы не знакомы с redis, как ни
крутите, не придумаете всё, что можно проверить. А для продакшена такое
внезапное обновление будет неприятным сюрпризом. Но я не знаком с redis,
может, там просто за цифрами в версии гонятся.
Не знаю, как в Альте принято, но делать рассинхрон сертифицированных и
обычных веток тоже весьма странно.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [devel] Обновление redis в p8
@ 2019-11-26 14:08 ` Anton Farygin
2019-11-26 14:10 ` Anton Farygin
0 siblings, 1 reply; 7+ messages in thread
From: Anton Farygin @ 2019-11-26 14:08 UTC (permalink / raw)
To: devel
On 26.11.2019 16:56, Leonid Krivoshein wrote:
>
>
> 26.11.2019 15:46, mikhailnov@altlinux.org пишет:
>> 26.11.2019 13:57, Leonid Krivoshein пишет:
>>>
>>> Это понятно. Вопрос-то был в определении того, что стоит проверить.
>>> Вообще, просили обновить версию в p8.
>>> Для c8/c8.1, вероятно, именно так и стоило бы поступить: поднять до
>>> 3.2.13.
>>> Но для p8 хотелось бы рискнуть поднять побольше -- взял из p9
>>> последнюю версию.
>>
>> Вопрос довольно странный, при таком большом поднятии версии в
>> _стабильном_ бранче надо прочитать все changelog-и между версиями и,
>> если они недостаточно подробные, изучить коммиты, а затем собрать
>> новую версию, откатив какие-либо ломающие совместимость правки и/или
>> задействовать сборочные опции, улучшающие совместимость, при наличии
>> таковых. При обновлении systemd с 230 до 243 в rosa2016.1 это заняло
>> несколько недель. Риск странный. Раз вы не знакомы с redis, как ни
>> крутите, не придумаете всё, что можно проверить. А для продакшена
>> такое внезапное обновление будет неприятным сюрпризом. Но я не знаком
>> с redis, может, там просто за цифрами в версии гонятся.
>>
>> Не знаю, как в Альте принято, но делать рассинхрон сертифицированных
>> и обычных веток тоже весьма странно.
>>
>
> Вы говорите всё совершенно верно, так и стоило поступить, но даже
> ахнуть не успел, Обнинск очень оперативно сработал, пакет может
> попасть в p8 в любой момент. Вот что бывает, когда берусь за
> нетипичные для меня задачи. А у нас принято -- кто сломал, тот потом и
> чинит.
>
Можно тормознуть, это же не проблема. Но раз их тесты регрессий не
выявили, то...
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [devel] Обновление redis в p8
2019-11-26 14:08 ` Anton Farygin
@ 2019-11-26 14:10 ` Anton Farygin
0 siblings, 0 replies; 7+ messages in thread
From: Anton Farygin @ 2019-11-26 14:10 UTC (permalink / raw)
To: devel
On 26.11.2019 17:08, Anton Farygin wrote:
> On 26.11.2019 16:56, Leonid Krivoshein wrote:
>>
>>
>> 26.11.2019 15:46, mikhailnov@altlinux.org пишет:
>>> 26.11.2019 13:57, Leonid Krivoshein пишет:
>>>>
>>>> Это понятно. Вопрос-то был в определении того, что стоит проверить.
>>>> Вообще, просили обновить версию в p8.
>>>> Для c8/c8.1, вероятно, именно так и стоило бы поступить: поднять до
>>>> 3.2.13.
>>>> Но для p8 хотелось бы рискнуть поднять побольше -- взял из p9
>>>> последнюю версию.
>>>
>>> Вопрос довольно странный, при таком большом поднятии версии в
>>> _стабильном_ бранче надо прочитать все changelog-и между версиями и,
>>> если они недостаточно подробные, изучить коммиты, а затем собрать
>>> новую версию, откатив какие-либо ломающие совместимость правки и/или
>>> задействовать сборочные опции, улучшающие совместимость, при наличии
>>> таковых. При обновлении systemd с 230 до 243 в rosa2016.1 это заняло
>>> несколько недель. Риск странный. Раз вы не знакомы с redis, как ни
>>> крутите, не придумаете всё, что можно проверить. А для продакшена
>>> такое внезапное обновление будет неприятным сюрпризом. Но я не
>>> знаком с redis, может, там просто за цифрами в версии гонятся.
>>>
>>> Не знаю, как в Альте принято, но делать рассинхрон сертифицированных
>>> и обычных веток тоже весьма странно.
>>>
>>
>> Вы говорите всё совершенно верно, так и стоило поступить, но даже
>> ахнуть не успел, Обнинск очень оперативно сработал, пакет может
>> попасть в p8 в любой момент. Вот что бывает, когда берусь за
>> нетипичные для меня задачи. А у нас принято -- кто сломал, тот потом
>> и чинит.
>>
> Можно тормознуть, это же не проблема. Но раз их тесты регрессий не
> выявили, то...
И да, я смотрю на оперативный город в окно и поражаюсь его оперативности.
При чём тут город....
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [devel] Обновление redis в p8
2019-11-26 12:46 ` mikhailnov
@ 2019-11-26 14:11 ` Sergey Afonin
1 sibling, 0 replies; 7+ messages in thread
From: Sergey Afonin @ 2019-11-26 14:11 UTC (permalink / raw)
To: ALT Linux Team development discussions
On Tuesday 26 November 2019, mikhailnov@altlinux.org wrote:
> Не знаю, как в Альте принято, но делать рассинхрон сертифицированных
> и обычных веток тоже весьма странно.
Тут рассинхронизация достаточно сильная ещё со времён c7. Причём
рассинхронизация разнонаправленная: что-то старее, что-то новее.
--
С уважением, Сергей Афонин.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-11-26 14:11 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-25 22:32 [devel] Обновление redis в p8 Leonid Krivoshein
2019-11-26 1:22 ` mikhailnov
2019-11-26 1:41 ` mikhailnov
2019-11-26 12:46 ` mikhailnov
2019-11-26 14:08 ` Anton Farygin
2019-11-26 14:10 ` Anton Farygin
2019-11-26 14:11 ` Sergey Afonin
ALT Linux Team development discussions
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
public-inbox-index devel
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.devel
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git