[devel] [#202589] EPERM (try 2) bootloader-utils.git=0.5.0-alt1
Mikhail Efremov
sem на altlinux.org
Пт Мар 23 17:24:12 MSK 2018
On Fri, 23 Mar 2018 16:51:19 +0300 Mikhail Efremov wrote:
> On Fri, 23 Mar 2018 15:11:13 +0300 Paul Wolneykien wrote:
> > 23.03.2018 07:52, Alexey V. Vissarionov пишет:
> > > On 2018-03-23 02:03:27 +0300, Paul Wolneykien wrote:
> > >
> > > >> Вообще хорошо бы досмотреть собранное в пропавшем уже
> > > >> http://webery.altlinux.org/task/198627 (а ещё лучше со
> > > >> смерженным bootloader-utils.git)
> > > > Ок, я смержу.
> > >
> > > С утра пораньше прочитал это, как будто ты смердишь. Сильно
> > > удивился, прочитал еще пару раз - дошло. Но как-то совсем уж
> > > http://bash.im/quote/449514 получается...
> >
> > Тщательно вымылся (= совершил ритуальное омовение) и сделал мерж на
> > свежую голову:
> >
> >
> > http://git.altlinux.org/people/manowar/packages/bootloader-utils.git?p=bootloader-utils.git;a=shortlog;h=refs/heads/master
> >
> > Выбор ядра по умолчанию пришлось обернуть в функцию вместо прибитого
> > гвоздями `readlink /boot/vmlinuz`. Обработка каждого нового файла
> > начинается с того, что VMLINUZ_PREFIX возвращается в исходное значение.
> >
> > Если всё устраивает, то как удобнее: pull или новое задание и approve?
>
> Я пора бегло взглянул, постараюсь еще посмотреть позже.
Посмотрел kernel.filetrigger:
1. SHARFILE нигде не определяется
2. Игры с переопределением VMLINUZ_PREFIX - это что-то ужасное.
Раз теперь префиксы могут быть разные, то надо обернуть все
использования в функции и передавать значение префикса как аргумент,
например.
> Я, конечно, предпочел бы rebase без тегов/изменений в спеке
> вместо merge, а то тяжело смотреть. Но это несколько больше работы,
> ладно.
> Пока у меня 2 вопроса:
> Как commit message 'Seems to work' отражает сделанные в этом коммите
> изменения?
> Почему это все еще версия 0.5.1, а не 0.6 или, учитывая объем
> изменений, даже 1.0.0?
>
--
WBR, Mikhail Efremov
Подробная информация о списке рассылки Devel