[devel] Q: срок автоматического удаления устаревших сборочных заданий

Paul Wolneykien manowar на altlinux.org
Вт Окт 27 14:11:01 MSK 2020


В Tue, 27 Oct 2020 13:54:28 +0300
Anton Farygin <rider на basealt.ru> пишет:

> On 27.10.2020 12:07, Dmitry V. Levin wrote:
> > On Tue, Oct 27, 2020 at 12:03:55PM +0300, Anton Farygin wrote:  
> >> On 27.10.2020 11:57, Dmitry V. Levin wrote:  
> >>> On Tue, Oct 27, 2020 at 11:35:14AM +0300, Anton Farygin wrote:  
> >>>> On 27.10.2020 10:18, Dmitry V. Levin wrote:  
> >>>>> On Tue, Oct 27, 2020 at 08:59:01AM +0300, Anton Farygin wrote:  
> >>>>>> On 26.10.2020 19:42, Dmitry V. Levin wrote:  
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> По техническим причинам автоматическое удаление
> >>>>>>> незакоммиченных устаревших сборочных заданий было выключено в
> >>>>>>> середине прошлого года.  С тех пор количество несомненно
> >>>>>>> устаревших сборочных заданий неуклонно растёт.
> >>>>>>>
> >>>>>>> Например, 550 заданий не отправлялось на обработку за
> >>>>>>> последние полгода, занимая 167 гигабайт места, которое
> >>>>>>> пригодилось бы для новых сборочных заданий.
> >>>>>>>
> >>>>>>> По этой причине автоматическое удаление устаревших сборочных
> >>>>>>> заданий придётся включить снова.  Я предлагаю установить в
> >>>>>>> качестве срока устаревания полгода.
> >>>>>>>
> >>>>>>> (Всё это не касается закоммиченных сборочных заданий, которые
> >>>>>>> архивируются и хранятся отдельно.)
> >>>>>>>  
> >>>>>> Было бы отлично сделать этот параметр настраиваемым для каждого
> >>>>>> сборочного задания.  
> >>>>> А зачем?
> >>>>>  
> >>>> ну, например, у меня есть задание, которое нужно оставить
> >>>> практически навсегда.  (на время жизни p9).
> >>>>
> >>>> #250722 EPERM #9 p9 alsa-topology-conf.git=1.2.3-alt1
> >>>> alsa-ucm-conf.git=1.2.3-alt1 libalsa.git=1.2.3.2-alt1
> >>>> alsa-utils.git=1.2.3-alt1 alsa-plugins.git=1.2.2-alt1
> >>>> tinycompress.git=1.2.3-alt1 pulseaudio.git=13.99.1-alt0.M90P.
> >>>>
> >>>> Его попробовали потестировать и в нём есть регресс, из-за
> >>>> которого его коммитить в branch нельзя, а при этом есть железо
> >>>> (например acer swift 3 модель 2020 года), микрофон на котором
> >>>> начинает работать только с новой альсой, пульсом и ядром из
> >>>> sisyphus.  
> >>> Такие задания надо ребейзить время от времени, наверное?
> >>>  
> >> Под rebase ты имеешь в виду rebuild ? Да, нужно конечно.  
> > Тогда оно по определению не попадает в категорию устаревших заданий,
> > состояние которых не меняется в течение установленного срока.
> >  
> >> Это было бы тоже неплохо автоматизировать.  
> > Да, это бы тоже пригодилось, но это другая тема.
> >
> >  
> Ну как другая, я забываю делать rebase для задания и оно может
> случайно удалиться.
> 
> Жалко не содержимое - его как раз можно восстановить, а жалко номер 
> задания, который может оказаться в sources.list прописан.

  Тогда это FR: своеобразный такой DNS для связи произвольного имени
с произвольным номером задания. Или "выложите моё задание № такой-то
по HTTP(S) вот так".


Подробная информация о списке рассылки Devel