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

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

[Dmitry V. Levin]

Hi,

По техническим причинам автоматическое удаление незакоммиченных устаревших
сборочных заданий было выключено в середине прошлого года.  С тех пор
количество несомненно устаревших сборочных заданий неуклонно растёт.

Например, 550 заданий не отправлялось на обработку за последние
полгода, занимая 167 гигабайт места, которое пригодилось бы для новых
сборочных заданий.

По этой причине автоматическое удаление устаревших сборочных заданий
придётся включить снова.  Я предлагаю установить в качестве срока
устаревания полгода.

(Всё это не касается закоммиченных сборочных заданий, которые
архивируются и хранятся отдельно.)


-- 
ldv

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

[Sergey Y. Afonin]

On Monday 26 October 2020, Dmitry V. Levin wrote:

> По этой причине автоматическое удаление устаревших сборочных заданий
> придётся включить снова.  Я предлагаю установить в качестве срока
> устаревания полгода.
 
А как бы хотябы предупреждение сделать, что скоро удаление?
В смысле когда срок будет подходить? Всё же бывает надо какие-то
задания подержать. Скажем за пару недель. Хотя в идеале бы выводить
по task ls остаток.

-- 
С уважением, Сергей Афонин

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

[Anton Farygin]

On 26.10.2020 19:42, Dmitry V. Levin wrote:
> Hi,
>
> По техническим причинам автоматическое удаление незакоммиченных устаревших
> сборочных заданий было выключено в середине прошлого года.  С тех пор
> количество несомненно устаревших сборочных заданий неуклонно растёт.
>
> Например, 550 заданий не отправлялось на обработку за последние
> полгода, занимая 167 гигабайт места, которое пригодилось бы для новых
> сборочных заданий.
>
> По этой причине автоматическое удаление устаревших сборочных заданий
> придётся включить снова.  Я предлагаю установить в качестве срока
> устаревания полгода.
>
> (Всё это не касается закоммиченных сборочных заданий, которые
> архивируются и хранятся отдельно.)
>
>
Было бы отлично сделать этот параметр настраиваемым для каждого 
сборочного задания.

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

[Alexey V. Vissarionov]

On 2020-10-27 08:59:01 +0300, Anton Farygin wrote:

 >> По техническим причинам автоматическое удаление
 >> незакоммиченных устаревших сборочных заданий было выключено
 >> в середине прошлого года. С тех пор количество несомненно
 >> устаревших сборочных заданий неуклонно растёт.
 >> [...]
 >> По этой причине автоматическое удаление устаревших сборочных
 >> заданий придётся включить снова. Я предлагаю установить в
 >> качестве срока устаревания полгода.
 > Было бы отлично сделать этот параметр настраиваемым для
 > каждого сборочного задания.

И кто будет настраивать? Мейнтейнер? Могут быть злоупотребления...

Есть более хитрый вариант: делить эти полгода (или даже год) на
все задания, но с ограничением снизу в неделю. То есть, одинокое
задание, лежащее 4 месяца, имеет шанс пролежать еще пару месяцев,
но если к нему добавится еще десяток - через неделю (минимальный
срок) будут удалены все.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

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

[Sergey Afonin]

On Tuesday 27 October 2020, Alexey V. Vissarionov wrote:

>  > Было бы отлично сделать этот параметр настраиваемым для
>  > каждого сборочного задания.
> 
> И кто будет настраивать? Мейнтейнер? Могут быть злоупотребления...
 
Ограничить тем самым полугодом. С возможностью продления
самостоятельного.

-- 
С уважением, Сергей Афонин.

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

[Dmitry V. Levin]

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 гигабайт места, которое пригодилось бы для новых
> > сборочных заданий.
> >
> > По этой причине автоматическое удаление устаревших сборочных заданий
> > придётся включить снова.  Я предлагаю установить в качестве срока
> > устаревания полгода.
> >
> > (Всё это не касается закоммиченных сборочных заданий, которые
> > архивируются и хранятся отдельно.)
> >
> Было бы отлично сделать этот параметр настраиваемым для каждого 
> сборочного задания.

А зачем?


-- 
ldv

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

[Nikolai Kostrigin]

27.10.2020 10:18, Dmitry V. Levin пишет:
> 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 гигабайт места, которое пригодилось бы для новых
>>> сборочных заданий.
>>>
>>> По этой причине автоматическое удаление устаревших сборочных заданий
>>> придётся включить снова.  Я предлагаю установить в качестве срока
>>> устаревания полгода.
>>>
>>> (Всё это не касается закоммиченных сборочных заданий, которые
>>> архивируются и хранятся отдельно.)
>>>
>> Было бы отлично сделать этот параметр настраиваемым для каждого 
>> сборочного задания.
> А зачем?

Не все задания нужны в репозитории.

Некоторые собраны для сторонних потребителей, чтобы решить временные
неувязки (те самые "карманы").

При этом "временно" понятие растяжимое и может превышать норму выбранную
для автоудаления.

Я бы предложил разрешить каждому мэйнтэйнеру иметь 1-2-3 (сколько
безболезненно может вынести инфраструктура) "защищенных" от автоудаления
задания, а остальные

подвергать чистке в  установленном порядке.
Для этого, конечно, понадобится соответствующая фича в girar.

>  
>
-- 
Best regards,
Nikolai Kostrigin

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

[Sergey V Turchin]

On Tuesday, 27 October 2020 10:44:01 MSK Nikolai Kostrigin wrote:
> 27.10.2020 10:18, Dmitry V. Levin пишет:
> > 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 гигабайт места, которое пригодилось бы для новых
> >>> сборочных заданий.
> >>> 
> >>> По этой причине автоматическое удаление устаревших сборочных заданий
> >>> придётся включить снова.  Я предлагаю установить в качестве срока
> >>> устаревания полгода.
> >>> 
> >>> (Всё это не касается закоммиченных сборочных заданий, которые
> >>> архивируются и хранятся отдельно.)
> >> 
> >> Было бы отлично сделать этот параметр настраиваемым для каждого
> >> сборочного задания.
> > 
> > А зачем?
> 
> Не все задания нужны в репозитории.
> 
> Некоторые собраны для сторонних потребителей, чтобы решить временные
> неувязки (те самые "карманы").
Если для продления срока будет достаточно пересобрать задание, то это будет 
стимулировать актуализацию зависимостей собранных там пакетов.

> При этом "временно" понятие растяжимое и может превышать норму выбранную
> для автоудаления.
> 
> Я бы предложил разрешить каждому мэйнтэйнеру иметь 1-2-3 (сколько
> безболезненно может вынести инфраструктура) "защищенных" от автоудаления
> задания, а остальные
> 
> подвергать чистке в  установленном порядке.
> Для этого, конечно, понадобится соответствующая фича в girar.


-- 
Regards, Sergey.

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

[Sergey Afonin]

On Tuesday 27 October 2020, Dmitry V. Levin wrote:

> > Было бы отлично сделать этот параметр настраиваемым для каждого 
> > сборочного задания.
> 
> А зачем?
 
Сделать умолчание месяц (или даже неделю, если продлять можно будет)
и возможность задать в интервале до полугода. И лишнее пол года не
будет болтаться (хотя, конечно, и удалять можно самостоятельно, но
тут уже самодисциплина/разное), и нужное можно на подольше.

-- 
С уважением, Сергей Афонин.

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

[Anton Farygin]

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.

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

[Dmitry V. Levin]

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.

Такие задания надо ребейзить время от времени, наверное?


-- 
ldv

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

[Anton Farygin]

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 ? Да, нужно конечно. Это было бы 
тоже неплохо автоматизировать.

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

[Dmitry V. Levin]

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 ? Да, нужно конечно.

Тогда оно по определению не попадает в категорию устаревших заданий,
состояние которых не меняется в течение установленного срока.

> Это было бы тоже неплохо автоматизировать.

Да, это бы тоже пригодилось, но это другая тема.


-- 
ldv

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

[Anton Farygin]

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 прописан.

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

[Paul Wolneykien]

В 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) вот так".

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

[Sergey Afonin]

On Tuesday 27 October 2020, Anton Farygin wrote:

> а жалко номер задания, который может оказаться в sources.list прописан.

И на wiki, а, следовательно, и не у одного пользователя.

-- 
С уважением, Сергей Афонин.

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

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1597 bytes --]

On Mon, 26 Oct 2020 19:42:46 +0300 Dmitry V. Levin wrote:
> Hi,
> 
> По техническим причинам автоматическое удаление незакоммиченных устаревших
> сборочных заданий было выключено в середине прошлого года.  С тех пор
> количество несомненно устаревших сборочных заданий неуклонно растёт.
> 
> Например, 550 заданий не отправлялось на обработку за последние
> полгода, занимая 167 гигабайт места, которое пригодилось бы для новых
> сборочных заданий.
> 
> По этой причине автоматическое удаление устаревших сборочных заданий
> придётся включить снова.  Я предлагаю установить в качестве срока
> устаревания полгода.
> 
> (Всё это не касается закоммиченных сборочных заданий, которые
> архивируются и хранятся отдельно.)

Разумное предложение, я поддерживаю.

Однако, если нам приходится экономить 167 GB — это не очень хорошо.
Дисковое пространство всегда должно быть с хорошим запасом.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

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

[Vitaly Lipatov]

Dmitry V. Levin писал 26.10.20 19:42:
> Hi,
> 
> По техническим причинам автоматическое удаление незакоммиченных 
> устаревших
> сборочных заданий было выключено в середине прошлого года.  С тех пор
> количество несомненно устаревших сборочных заданий неуклонно растёт.
> 
> Например, 550 заданий не отправлялось на обработку за последние
> полгода, занимая 167 гигабайт места, которое пригодилось бы для новых
> сборочных заданий.
А мне одному кажется, что 167 Гб это не тот объём, который стоит 
обсуждать?

С другой стороны, явно есть задания, про которые все забыли, и какая 
сборка мусора нужна.

Как уже обсуждалось, нельзя ли сначала сделать возможность включать 
удержания заданий, а потом уже включать удаление?


-- 
С уважением,
Виталий Липатов,
ALT Linux Team

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

[Alexey V. Vissarionov]

On 2020-10-29 03:17:50 +0300, Vitaly Lipatov wrote:

 >> Например, 550 заданий не отправлялось на обработку за последние
 >> полгода, занимая 167 гигабайт места, которое пригодилось бы
 >> для новых сборочных заданий.
 > А мне одному кажется, что 167 Гб это не тот объём, который стоит
 > обсуждать?

С одной стороны - да, по нынешним меркам это не так уж и много.
А с другой - это объем, сравнимый с зеркалом Sisyphus для aarch64,
x86_64 и noarch вместе взятых (сейчас это 46+55+80 == 181 Гб).

 > С другой стороны, явно есть задания, про которые все забыли,
 > и какая сборка мусора нужна.

Разумеется. Но есть и задания, номер которых уже может быть где-то
прибит гвоздями (ну да, в тестовой среде, ибо для промышленной уже
есть смысл создавать собственную репу, но все же).

 > Как уже обсуждалось, нельзя ли сначала сделать возможность
 > включать удержания заданий, а потом уже включать удаление?

Кстати, было бы полезно. Например, не более 3...4 заданий на каждого
мейнтейнера. А то и парочки хватит.

Вижу это как команду lock, параметр --lock для команды build и,
разумеется, комплиментарную к ним команду unlock.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

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

[Andrey Cherepanov]

29.10.2020 03:42, Alexey V. Vissarionov пишет:
> On 2020-10-29 03:17:50 +0300, Vitaly Lipatov wrote:
>
>   >> Например, 550 заданий не отправлялось на обработку за последние
>   >> полгода, занимая 167 гигабайт места, которое пригодилось бы
>   >> для новых сборочных заданий.
>   > А мне одному кажется, что 167 Гб это не тот объём, который стоит
>   > обсуждать?
>
> С одной стороны - да, по нынешним меркам это не так уж и много.
> А с другой - это объем, сравнимый с зеркалом Sisyphus для aarch64,
> x86_64 и noarch вместе взятых (сейчас это 46+55+80 == 181 Гб).
>
>   > С другой стороны, явно есть задания, про которые все забыли,
>   > и какая сборка мусора нужна.
>
> Разумеется. Но есть и задания, номер которых уже может быть где-то
> прибит гвоздями (ну да, в тестовой среде, ибо для промышленной уже
> есть смысл создавать собственную репу, но все же).
>
>   > Как уже обсуждалось, нельзя ли сначала сделать возможность
>   > включать удержания заданий, а потом уже включать удаление?
>
> Кстати, было бы полезно. Например, не более 3...4 заданий на каждого
> мейнтейнера. А то и парочки хватит.

Это зависит от задач, который решает мейнтейнер. А то у меня для заказчиков:

$ girar-show | wc -l
45
$ girar-show | grep -c EPERM
29

И вот что мне с этим всем делать прикажете?

-- 
Andrey Cherepanov
cas@altlinux.org

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

[Alexey V. Vissarionov]

On 2020-10-29 05:29:55 +0300, Andrey Cherepanov wrote:

 >> Но есть и задания, номер которых уже может быть где-то прибит
 >> гвоздями (ну да, в тестовой среде, ибо для промышленной уже
 >> есть смысл создавать собственную репу, но все же).
 >>> Как уже обсуждалось, нельзя ли сначала сделать возможность
 >>> включать удержания заданий, а потом уже включать удаление?
 >> Кстати, было бы полезно. Например, не более 3...4 заданий на
 >> каждого мейнтейнера. А то и парочки хватит.
 > Это зависит от задач, который решает мейнтейнер. А то у меня
 > для заказчиков:
 > $ girar-show | wc -l 45 $ girar-show | grep -c EPERM 29
 > И вот что мне с этим всем делать прикажете?

Что делать, что делать... свою репу делать, вот что :-/

Ибо кому-то система ради системы, а кому-то работать надо. Благо,
каких-то существенных ресурсов это не требует.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

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

[Andrey Cherepanov]

29.10.2020 09:01, Alexey V. Vissarionov пишет:
> On 2020-10-29 05:29:55 +0300, Andrey Cherepanov wrote:
>
>   >> Но есть и задания, номер которых уже может быть где-то прибит
>   >> гвоздями (ну да, в тестовой среде, ибо для промышленной уже
>   >> есть смысл создавать собственную репу, но все же).
>   >>> Как уже обсуждалось, нельзя ли сначала сделать возможность
>   >>> включать удержания заданий, а потом уже включать удаление?
>   >> Кстати, было бы полезно. Например, не более 3...4 заданий на
>   >> каждого мейнтейнера. А то и парочки хватит.
>   > Это зависит от задач, который решает мейнтейнер. А то у меня
>   > для заказчиков:
>   > $ girar-show | wc -l 45 $ girar-show | grep -c EPERM 29
>   > И вот что мне с этим всем делать прикажете?
>
> Что делать, что делать... свою репу делать, вот что :-/
$ girar-show | sed 's/\[[a-z-]\+] //g' | cut -f4 -d ' ' | sort -u | wc -l
4
> Ибо кому-то система ради системы, а кому-то работать надо. Благо,
> каких-то существенных ресурсов это не требует.

Кто-то и с заказчиками разными работает. :)

-- 
Andrey Cherepanov
cas@altlinux.org

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

[Dmitry V. Levin]

On Thu, Oct 29, 2020 at 03:17:50AM +0300, Vitaly Lipatov wrote:
> Dmitry V. Levin писал 26.10.20 19:42:
> > Hi,
> > 
> > По техническим причинам автоматическое удаление незакоммиченных 
> > устаревших
> > сборочных заданий было выключено в середине прошлого года.  С тех пор
> > количество несомненно устаревших сборочных заданий неуклонно растёт.
> > 
> > Например, 550 заданий не отправлялось на обработку за последние
> > полгода, занимая 167 гигабайт места, которое пригодилось бы для новых
> > сборочных заданий.
> А мне одному кажется, что 167 Гб это не тот объём, который стоит 
> обсуждать?

167 Гб за 9 месяцев - это в перспективе слишком много для быстрых дисков,
на которых эти забытые гигабайты размещаются, чтобы пренебречь этим
вопросом.  Некоторые из этих 550 заданий имеют размер, превышающий 5 Гб.

> С другой стороны, явно есть задания, про которые все забыли, и какая 
> сборка мусора нужна.
> 
> Как уже обсуждалось, нельзя ли сначала сделать возможность включать 
> удержания заданий, а потом уже включать удаление?

Я исхожу из того, что долгоживущие задания бывают двух типов:
- те, которые время от времени надо пересобирать из-за того, что базовый
  репозиторий изменяется, это естественным образом предотвращает
  устаревание заданий;
- те, которые следует заархивировать, исключив дальнейшие изменения.


-- 
ldv

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

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1538 bytes --]

On Thu, 29 Oct 2020 09:58:31 +0300 Dmitry V. Levin wrote:
> On Thu, Oct 29, 2020 at 03:17:50AM +0300, Vitaly Lipatov wrote:
> > С другой стороны, явно есть задания, про которые все забыли, и какая 
> > сборка мусора нужна.
> > 
> > Как уже обсуждалось, нельзя ли сначала сделать возможность включать 
> > удержания заданий, а потом уже включать удаление?
> 
> Я исхожу из того, что долгоживущие задания бывают двух типов:
> - те, которые время от времени надо пересобирать из-за того, что базовый
>   репозиторий изменяется, это естественным образом предотвращает
>   устаревание заданий;
> - те, которые следует заархивировать, исключив дальнейшие изменения.

Можно просто скриптом перемещать старые, но незаархивированные
задания на медленные диски. Это позволит их авторам в случае особой
необходимости оживить задание, ну а то, что оно будет немного
медленнее работать — перетерпят.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

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

[Vitaly Lipatov]

Dmitry V. Levin писал 29.10.20 9:58:
> On Thu, Oct 29, 2020 at 03:17:50AM +0300, Vitaly Lipatov wrote:
>> Dmitry V. Levin писал 26.10.20 19:42:
...
>> > Например, 550 заданий не отправлялось на обработку за последние
>> > полгода, занимая 167 гигабайт места, которое пригодилось бы для новых
>> > сборочных заданий.
>> А мне одному кажется, что 167 Гб это не тот объём, который стоит
>> обсуждать?
> 
> 167 Гб за 9 месяцев - это в перспективе слишком много для быстрых 
> дисков,
> на которых эти забытые гигабайты размещаются, чтобы пренебречь этим
> вопросом.  Некоторые из этих 550 заданий имеют размер, превышающий 5 
> Гб.
ok

>> С другой стороны, явно есть задания, про которые все забыли, и какая
>> сборка мусора нужна.
>> 
>> Как уже обсуждалось, нельзя ли сначала сделать возможность включать
>> удержания заданий, а потом уже включать удаление?
> 
> Я исхожу из того, что долгоживущие задания бывают двух типов:
> - те, которые время от времени надо пересобирать из-за того, что 
> базовый
>   репозиторий изменяется, это естественным образом предотвращает
>   устаревание заданий;
> - те, которые следует заархивировать, исключив дальнейшие изменения.
То есть нужна возможность отправлять в архив непринятые задания? Но 
чтобы мантейнер имел мотивацию так делать, другие его долгоживущие 
задания нужно периодически пересобирать. Делать пересборку 
автоматической было бы странно, как-то практичнее поручать запуск 
пересборки тому, кто хочет, чтобы его задание продолжило жить. А чтобы 
он об этом вспомнил, нужны какие-то извещения о таких заданиях.

Я бы предложил для долгоживущих заданий:
- не выводить их в обычном списке ls (а со специальным параметром типа 
ls --hold);
- по истечении какого-то времени (полгода?) снимать с них флаг 
долгоживучести, чтобы мантейнер мог задание удалить или пересобрать и 
отправить обратно в долгоживущие.

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

P.S.
А архив, кроме странного (не первые цифры номера задания, а _число, 
причём невыровненное ведущими нулями) разбиения по подкаталогам, 
отличается только медленными дисками?



-- 
С уважением,
Виталий Липатов,
ALT Linux Team

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

[mikhailnov]

29.10.2020 19:40, Vitaly Lipatov пишет:
> Я бы предложил для долгоживущих заданий:
> - не выводить их в обычном списке ls (а со специальным параметром типа ls --hold);
Чтоб о них точно забыть?))

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

[Vitaly Lipatov]

mikhailnov@altlinux.org писал 11.11.20 1:33:
> 29.10.2020 19:40, Vitaly Lipatov пишет:
>> Я бы предложил для долгоживущих заданий:
>> - не выводить их в обычном списке ls (а со специальным параметром типа 
>> ls --hold);
> Чтоб о них точно забыть?))
Дело в том, что если висит много долгоживущих тасков, очень неудобно 
смотреть на список текущих тасков, особенно если они начинают 
чередоваться. Уезжают за экран и всё такое.


-- 
С уважением,
Виталий Липатов,
ALT Linux Team

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

[Dmitry V. Levin]

On Tue, Oct 27, 2020 at 03:18:31PM +0300, Andrey Cherepanov wrote:
> 26.10.2020 19:42, Dmitry V. Levin пишет:
> > Hi,
> >
> > По техническим причинам автоматическое удаление незакоммиченных устаревших
> > сборочных заданий было выключено в середине прошлого года.  С тех пор
> > количество несомненно устаревших сборочных заданий неуклонно растёт.
> >
> > Например, 550 заданий не отправлялось на обработку за последние
> > полгода, занимая 167 гигабайт места, которое пригодилось бы для новых
> > сборочных заданий.
> >
> > По этой причине автоматическое удаление устаревших сборочных заданий
> > придётся включить снова.  Я предлагаю установить в качестве срока
> > устаревания полгода.
> >
> > (Всё это не касается закоммиченных сборочных заданий, которые
> > архивируются и хранятся отдельно.)
> >
> С какого числа отсчёт протухания начинается?

Что такое отсчёт протухания?

Я пока добавил в вывод task show (и заодно в info.json) поле age,
значением которого является число полных недель с момента последнего изменения
состояния задания.  Например, запись age=0w означает, что прошло меньше
недели.


-- 
ldv

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

[Sergey Afonin]

On Thursday 29 October 2020, Dmitry V. Levin wrote:

> Я пока добавил в вывод task show (и заодно в info.json) поле age,

Ещё бы в ls.

-- 
С уважением, Сергей Афонин.

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

[Anton Farygin]

On 29.10.2020 10:38, Dmitry V. Levin wrote:
> On Tue, Oct 27, 2020 at 03:18:31PM +0300, Andrey Cherepanov wrote:
>> 26.10.2020 19:42, Dmitry V. Levin пишет:
>>> Hi,
>>>
>>> По техническим причинам автоматическое удаление незакоммиченных устаревших
>>> сборочных заданий было выключено в середине прошлого года.  С тех пор
>>> количество несомненно устаревших сборочных заданий неуклонно растёт.
>>>
>>> Например, 550 заданий не отправлялось на обработку за последние
>>> полгода, занимая 167 гигабайт места, которое пригодилось бы для новых
>>> сборочных заданий.
>>>
>>> По этой причине автоматическое удаление устаревших сборочных заданийsk
>>> придётся включить снова.  Я предлагаю установить в качестве срока
>>> устаревания полгода.
>>>
>>> (Всё это не касается закоммиченных сборочных заданий, которые
>>> архивируются и хранятся отдельно.)
>>>
>> С какого числа отсчёт протухания начинается?
> Что такое отсчёт протухания?
>
> Я пока добавил в вывод task show (и заодно в info.json) поле age,
> значением которого является число полных недель с момента последнего изменения
> состояния задания.  Например, запись age=0w означает, что прошло меньше
> недели.

Мне кажется, что было бы гораздо интереснее увидеть, сколько времени 
осталось заданию жить.

Эта информация выглядит ценнее чем то, сколько времени task не изменялся.