Created attachment 13882 [details]
gpg public key

Подтверждаю. Согласен быть ментором.

(In reply to ratkin from comment #1)
> Created attachment 13882 [details]
> gpg public key

Позвольте поинтересоваться, а как был сформирован этот файл?
Вы сами убрали -----BEGIN PGP PUBLIC KEY BLOCK----- и -----END PGP PUBLIC KEY BLOCK----- или воспользовались каким-то инструментом, который их куда-то дел?

В любом случае, ключ в таком виде не подойдёт.

Comment on attachment 13882 [details]
gpg public key

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBGS3rssBEACwGjI3RZG9t2hMcpd79j4hvg/Wv3Q2Eul5S/QTmApD3Q02yc6U
sHoBco9LOwA4PxYTeR4RGGyiwMtu/BuB+X6rp5x8xcbmEyf3UeBEQpJg9cIUbS2Q
o+EfcWRK3PC7AUOAow0AqeFFQzFvOz9oOqd7bxFBtLaq6miTHwVZy0i63csjJok1
iKiNDIaYnm2Pay2Pvguo9kL3+XhgdD9dTli9h2qKDs33lo9bK+fBR6D2ey7S0wCd
bL5Dqd36lhD4tVx7BiLvElk8BdoQFG1kKGgmcFGfQWmL+T0GRj+tjxPl7GT/cQOW
0Indb4acX2NLloWiGNLpkAFCyTNFWYMTwF7hx9U2i7QkNCu7Gpe9phlaHsd8lr4N
eBftrJ9sniMh5Iw93G2c8Ppc1Jl5VVTqnhLSx1pqVI4GBYVvG/F10GbHM1waLMPG
oJeDb3gOFpMtKzr95fR8fAAbuZgv28LA32pBcNaGuqgvVcb+ELzY0i64F9gbLm87
YkeVpAotulglCGW4A5BiV21D1hOvzA02rtI2Ah7iUl51hacKy02jBQXAjeEBR43S
55R/PSBjyVC2q+VG7e/JarHEJHJyJjVbEvzcsmzh1nJVjJ4pZCu8GmCOznXPsnOD
Aqju+jVYbWmMnJeOshEJaJf4IPdAIxA02Rsn70YKi0rtQHZwu5QhjnNHsQARAQAB
tClEYW5paWwtVmlrdG9yIFJhdGtpbiA8a3JmMTBAYWx0bGludXgub3JnPokCOAQT
AQgAIgUCZLeuywIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQP6EFp0bW
FpEKeg/+PX0k/JUBXbboZnAubB2L7jwXqCIfKP7InxLd9esMaoCMPm0CbSANpIFa
pBySHkLBsIfgqZOzqdSvbI1tC5Qcjt+iqpAkqNsrVmb0Bi5tzCcJDDJjbOlBbZLY
Q65Y5deWmkOc2K222IHfK67VLdyJ6xibJwBUCTH6PzzqxcsbBsTqwtH9gbUnM33x
Tyq/onmRmEvFDuCyz9tacoSLyvs+CZj2577V3ls+2JYgZ5LXhpJTI2cJz3CX+ycM
L8mVfI2/XNYrea4YonVuCYqDxWhZTrdcRkXrb0oVLy7CYwQjnQDr5dAy5uDLaWcM
TZJ0JoRA0ZMu1/a3bH8bsgg4cWzpXnZ86+ryDNPChkxjmO6T+WRdScf06yykCqAg
pgZ9+XZE04EtApJLiGD0Mptn2teNe3EXjVN8jO50LcF64812ujLl4lp56CEb9AgJ
ntjuoE8NE8aEgcyw8fl28VAzUp8WjGvRgiwsP2fvpu6hlk9Va/8dM6n5OTyflp6A
lug5KN6ZiXlrQpICBJ/eNzQqJZUsDxMq4FQYzfGQT0GZhKanWcN5Phc2Rr8RFJ2U
HNlVMttqfQd6WVf4jMCL4j3jWS7N7phf77sEme7IeDyuhl7zIVKIlTEE/PAWkQoT
/TG6DrfjjJId8A90FyLPyk8Mwm+Ymhf36o3pV1+w7/q+M9ADniC5Ag0EZLeuywEQ
ANAJurkCqX//vsUgboClr/+1H2+bjmw8RL4Ccbqs8EDcQht0pjytNEYmjFLtPCDq
Gyvj7W1py4Xwi2ew8ev29Poj9z6Xmk0qfdlkSpSqWSRRXEOv23p3UcbKFSVngq4P
hRZeGH9OI+xD59TIdhn4+6AqkT2bmqp3A5nmVCE0IFbEp7WjwGWbbmzJgOhWjyHl
NsgaEdfg/zmL/d4rb09GRFZvkJ1V3RU+8Ime9ln9Qe4t/MBmlFtU+KKORIuc8H/G
HcE2CGXFJ8wPQH1jwpst27WuIafyhtt+90tXZw7XCerKOP6JiaQYiMZ8wtRT7g0c
9dcW+G37rbMfugxO0ospTSWeinlA41rLY+4MmVkitcmDp9TV0od/HvfUhs4Ewrup
bm80us1o4dKnS7+h3kLzjCCTPk9BlHW9sPSjhJnfpFGgcFojwrRjGDHD6EHkc6mD
pKnzV2vG3K55kofJ7bPb1FLq33w/TvLmBF4oy+/CF3hlIQw3nTzbiXW8krBT9/Xy
sgdbinWV9kduRZ9L2GRXac3xXiFr9iWBoxmJoB/tih/PfncU6T9yjr0l51Tx1PFe
6Qq5HEdcVnP0U1Rt+/hOg2sSDUXqMIPhILwDmft1RB4bQUYIKtCq4iDY9fvqW86e
0m+oJFgkLUHWRcba0oXA0ohb4e0kUoRh/68TLI13wSHxABEBAAGJAh8EGAEIAAkF
AmS3rssCGwwACgkQP6EFp0bWFpGqJQ//YGpg9EEX7w+xto9N00/tkBqfUzqwXVfo
F5BaiT8r1Itg+Yoz1aD11nKojZMQf3tvcTk0UkpnvggjhQ5ck7UB0PVsaSK23nrg
5tKGbc8R4sBwmoq3pdT3cgQjinTs+wuJwSixnR3zPKAB2KLTjILOm48KURuepZDv
MFld8sZT/WJE4xtcaWJNYzJrFHx/7dFiJud0DQLoYF5lmffMs7h2AjVJJNoNpTUO
eAevYTPpFqPKfdyUqwSPkggr8p+37uf/4SzLp+k9dmTsDsY0Gx7CUMT1xQ/XziCZ
TiunbMn3CZFmIXrfAf48fRBFJSVM1/QMUk9cARuWkV3Z3ssciOeinm5oLHZg+Rf4
byTROHR7r9tU15KnU9KJEr2RE6otmnR/HFaat+DifCDPGxnFoYTHX85qMFpiLYx8
+6CpyPjUZhoxUXVgS8f3rlM1213Db7pytuinbMlpqHYzONojkTx9ukG+bENC6oFI
WzNRnSUl/8kU8wSvZJ9COQkzEhXrvNZn1oLqkeHUfzgAgLF+5+FvHjvburkqfPp/
3JbdElGfKDRNATYj2BTW2fdjXh8Cuud2p+oHrl6j0snUo8l6kShrJJeZ1jmcqZ4R
HVK3DIwAYcNKSQgzf9JbGwwbKYWfsUuGYgQPqxbomk/YtYhUE69Jd+K68jBgSB0x
Cw3SbgazqBQ=
=YVUy
-----END PGP PUBLIC KEY BLOCK-----

Comment on attachment 13882 [details]
gpg public key

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBGS3rssBEACwGjI3RZG9t2hMcpd79j4hvg/Wv3Q2Eul5S/QTmApD3Q02yc6U
sHoBco9LOwA4PxYTeR4RGGyiwMtu/BuB+X6rp5x8xcbmEyf3UeBEQpJg9cIUbS2Q
o+EfcWRK3PC7AUOAow0AqeFFQzFvOz9oOqd7bxFBtLaq6miTHwVZy0i63csjJok1
iKiNDIaYnm2Pay2Pvguo9kL3+XhgdD9dTli9h2qKDs33lo9bK+fBR6D2ey7S0wCd
bL5Dqd36lhD4tVx7BiLvElk8BdoQFG1kKGgmcFGfQWmL+T0GRj+tjxPl7GT/cQOW
0Indb4acX2NLloWiGNLpkAFCyTNFWYMTwF7hx9U2i7QkNCu7Gpe9phlaHsd8lr4N
eBftrJ9sniMh5Iw93G2c8Ppc1Jl5VVTqnhLSx1pqVI4GBYVvG/F10GbHM1waLMPG
oJeDb3gOFpMtKzr95fR8fAAbuZgv28LA32pBcNaGuqgvVcb+ELzY0i64F9gbLm87
YkeVpAotulglCGW4A5BiV21D1hOvzA02rtI2Ah7iUl51hacKy02jBQXAjeEBR43S
55R/PSBjyVC2q+VG7e/JarHEJHJyJjVbEvzcsmzh1nJVjJ4pZCu8GmCOznXPsnOD
Aqju+jVYbWmMnJeOshEJaJf4IPdAIxA02Rsn70YKi0rtQHZwu5QhjnNHsQARAQAB
tClEYW5paWwtVmlrdG9yIFJhdGtpbiA8a3JmMTBAYWx0bGludXgub3JnPokCOAQT
AQgAIgUCZLeuywIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQP6EFp0bW
FpEKeg/+PX0k/JUBXbboZnAubB2L7jwXqCIfKP7InxLd9esMaoCMPm0CbSANpIFa
pBySHkLBsIfgqZOzqdSvbI1tC5Qcjt+iqpAkqNsrVmb0Bi5tzCcJDDJjbOlBbZLY
Q65Y5deWmkOc2K222IHfK67VLdyJ6xibJwBUCTH6PzzqxcsbBsTqwtH9gbUnM33x
Tyq/onmRmEvFDuCyz9tacoSLyvs+CZj2577V3ls+2JYgZ5LXhpJTI2cJz3CX+ycM
L8mVfI2/XNYrea4YonVuCYqDxWhZTrdcRkXrb0oVLy7CYwQjnQDr5dAy5uDLaWcM
TZJ0JoRA0ZMu1/a3bH8bsgg4cWzpXnZ86+ryDNPChkxjmO6T+WRdScf06yykCqAg
pgZ9+XZE04EtApJLiGD0Mptn2teNe3EXjVN8jO50LcF64812ujLl4lp56CEb9AgJ
ntjuoE8NE8aEgcyw8fl28VAzUp8WjGvRgiwsP2fvpu6hlk9Va/8dM6n5OTyflp6A
lug5KN6ZiXlrQpICBJ/eNzQqJZUsDxMq4FQYzfGQT0GZhKanWcN5Phc2Rr8RFJ2U
HNlVMttqfQd6WVf4jMCL4j3jWS7N7phf77sEme7IeDyuhl7zIVKIlTEE/PAWkQoT
/TG6DrfjjJId8A90FyLPyk8Mwm+Ymhf36o3pV1+w7/q+M9ADniC5Ag0EZLeuywEQ
ANAJurkCqX//vsUgboClr/+1H2+bjmw8RL4Ccbqs8EDcQht0pjytNEYmjFLtPCDq
Gyvj7W1py4Xwi2ew8ev29Poj9z6Xmk0qfdlkSpSqWSRRXEOv23p3UcbKFSVngq4P
hRZeGH9OI+xD59TIdhn4+6AqkT2bmqp3A5nmVCE0IFbEp7WjwGWbbmzJgOhWjyHl
NsgaEdfg/zmL/d4rb09GRFZvkJ1V3RU+8Ime9ln9Qe4t/MBmlFtU+KKORIuc8H/G
HcE2CGXFJ8wPQH1jwpst27WuIafyhtt+90tXZw7XCerKOP6JiaQYiMZ8wtRT7g0c
9dcW+G37rbMfugxO0ospTSWeinlA41rLY+4MmVkitcmDp9TV0od/HvfUhs4Ewrup
bm80us1o4dKnS7+h3kLzjCCTPk9BlHW9sPSjhJnfpFGgcFojwrRjGDHD6EHkc6mD
pKnzV2vG3K55kofJ7bPb1FLq33w/TvLmBF4oy+/CF3hlIQw3nTzbiXW8krBT9/Xy
sgdbinWV9kduRZ9L2GRXac3xXiFr9iWBoxmJoB/tih/PfncU6T9yjr0l51Tx1PFe
6Qq5HEdcVnP0U1Rt+/hOg2sSDUXqMIPhILwDmft1RB4bQUYIKtCq4iDY9fvqW86e
0m+oJFgkLUHWRcba0oXA0ohb4e0kUoRh/68TLI13wSHxABEBAAGJAh8EGAEIAAkF
AmS3rssCGwwACgkQP6EFp0bWFpGqJQ//YGpg9EEX7w+xto9N00/tkBqfUzqwXVfo
F5BaiT8r1Itg+Yoz1aD11nKojZMQf3tvcTk0UkpnvggjhQ5ck7UB0PVsaSK23nrg
5tKGbc8R4sBwmoq3pdT3cgQjinTs+wuJwSixnR3zPKAB2KLTjILOm48KURuepZDv
MFld8sZT/WJE4xtcaWJNYzJrFHx/7dFiJud0DQLoYF5lmffMs7h2AjVJJNoNpTUO
eAevYTPpFqPKfdyUqwSPkggr8p+37uf/4SzLp+k9dmTsDsY0Gx7CUMT1xQ/XziCZ
TiunbMn3CZFmIXrfAf48fRBFJSVM1/QMUk9cARuWkV3Z3ssciOeinm5oLHZg+Rf4
byTROHR7r9tU15KnU9KJEr2RE6otmnR/HFaat+DifCDPGxnFoYTHX85qMFpiLYx8
+6CpyPjUZhoxUXVgS8f3rlM1213Db7pytuinbMlpqHYzONojkTx9ukG+bENC6oFI
WzNRnSUl/8kU8wSvZJ9COQkzEhXrvNZn1oLqkeHUfzgAgLF+5+FvHjvburkqfPp/
3JbdElGfKDRNATYj2BTW2fdjXh8Cuud2p+oHrl6j0snUo8l6kShrJJeZ1jmcqZ4R
HVK3DIwAYcNKSQgzf9JbGwwbKYWfsUuGYgQPqxbomk/YtYhUE69Jd+K68jBgSB0x
Cw3SbgazqBQ=
=YVUy
-----END PGP PUBLIC KEY BLOCK-----

Приложите, пожалуйста, в виде нового attachment.

Created attachment 13981 [details]
gpg public key

(In reply to ratkin from comment #7)
> Created attachment 13981 [details]
> gpg public key
Ok.

Но мне всё равно очень интересно, что случилось с предыдущим вариантом, я не просто так же спросил. :)

(Ответ для Gleb F-Malinovskiy на комментарий #8)
> (In reply to ratkin from comment #7)
> > Created attachment 13981 [details] [подробности] [details]
> > gpg public key
> Ok.
> 
> Но мне всё равно очень интересно, что случилось с предыдущим вариантом, я не
> просто так же спросил. :)
Просто не выделил те строки в ключе когда копировал)

(In reply to ratkin from comment #9)
> (Ответ для Gleb F-Malinovskiy на комментарий #8)
> > Но мне всё равно очень интересно, что случилось с предыдущим вариантом, я не
> > просто так же спросил. :)
> Просто не выделил те строки в ключе когда копировал)

Понятно, я уж испугался, что какой-то инструмент стал так делать.

Кандидат готов начать вступление.

ssh ключ на gitery.alt зарегистрирован.
Адрес для пересылки создан.

T/J/S -> 2.3.

Created attachment 14935 [details]
new ssh public key

Created attachment 14936 [details]
new gpg public key

я положил систему и потерял прошлые ключи,можно их заменить на те , которые прикрепил выше?

(In reply to ratkin from comment #15)
> я положил систему и потерял прошлые ключи,можно их заменить на те , которые
> прикрепил выше?

Постарайтесь, пожалуйста, хранить ключи более бережно.

ssh ключ на gitery.alt зарегистрирован.

T/J/S -> 2.3.

Закончилась квота на gitery , прошу увеличить

https://bugzilla.altlinux.org/enter_bug.cgi?product=Team%20Accounts компонент quota

https://git.altlinux.org/people/krf10/packages/?p=dre-ace-tao.git;a=summary
https://git.altlinux.org/people/krf10/packages/?p=cinelerra-gg.git;a=summary
https://git.altlinux.org/people/krf10/packages/?p=python3-module-scrapy.git;a=summary
https://git.altlinux.org/people/krf10/packages/?p=czkawka.git;a=summary
https://git.altlinux.org/people/krf10/packages/?p=nyxt.git;a=summary

(Ответ для ratkin на комментарий #20)
> https://git.altlinux.org/people/krf10/packages/?p=cinelerra-gg.git
У нас есть макросы %autoreconf и %configure .

(Ответ для ratkin на комментарий #20)
> https://git.altlinux.org/people/krf10/packages/?p=python3-module-scrapy.git
Вместо python3-dev надо python3-devel. Это нюанс.
Бинарь неверняка не являются частью пакета модуля.

(Ответ для Sergey V Turchin на комментарий #22)
> (Ответ для ratkin на комментарий #20)
> > https://git.altlinux.org/people/krf10/packages/?p=python3-module-scrapy.git
> Вместо python3-dev надо python3-devel. Это нюанс.
> Бинарь неверняка не являются частью пакета модуля.

через бинарник запускается кравлер, без него не будет работать

(Ответ для ratkin на комментарий #23)
> через бинарник запускается кравлер, без него не будет работать
Если бинарник может работать, как отдельная утилита и не зависит от питоньего модуля, то его надо в отдельный пакет.

Подопечный готов собирать пакеты.

ssh ключ на gyle.alt зарегистрирован.
Пакет alt-gpgkeys обновлён.
Адрес подписан на devel@.

T/J/S -> 3.6.

Подопечный готов отправлять пакеты в Сизиф.

Это, что уже было сделано в рамках исправлений. https://packages.altlinux.org/ru/sisyphus/maintainers/krf10/srpms

пакеты собранные для Join:
https://packages.altlinux.org/ru/tasks/345179/
https://packages.altlinux.org/ru/tasks/344215/
https://packages.altlinux.org/ru/tasks/344757/
https://packages.altlinux.org/ru/tasks/344185/

up

Призван рецензент (arseny@) для независимой оценки готовности кандидата.

T/J/S -> 4.2.

(In reply to Gleb F-Malinovskiy from comment #31)
> Призван рецензент (arseny@) для независимой оценки готовности кандидата.
> 
> T/J/S -> 4.2.

ACK.

Позавчера начал читать dre-ace-tao и немного завяз :(, там по лидеру апстримного проекта плачет не рецензент, а кто-то ещё. Поэтому пока не комментирую работу кандидата. Надеюсь в течение недели дочитать всё из comment 29 и тогда уже комментировать.

(In reply to ratkin from comment #29)
> пакеты собранные для Join:
> https://packages.altlinux.org/ru/tasks/345179/

dre-ace-tao:

1) Спек dre-ace-tao новый для Sisyphus, но в нём нет:
  %define _unpackaged_files_terminate_build 1
Эта директива должна была бы подразумеваться по умолчанию, но мы решили так не делать по просьбе вашего ментора, которому пришлось бы мегасрочно чинить сотни пакетов — иначе их было бы нельзя обновить или пересобрать. В новых же пакетах нет ни одной причины не включать эту директиву. Реально ненужный файл из buildroot можно удалить (или заставить сборочный код его туда не ставить, если тот легко править, как в случае https://mesonbuild.com).
Соответственно, в логе сборки видим:
  [00:15:24] warning: Installed (but unpackaged) file(s) found:
  [00:15:24]     /etc/rc.d/init.d/init.info
  [00:15:24]     /etc/rc.d/init.d/start_d.ins
  [00:15:24]     /etc/rc.d/init.d/stop_d.ins
К ним, кстати, ещё вернёмся далее.

2) Вижу по истории спека, что почищен всякий мёртвый код, но не до конца: в спеке всё ещё остались:
  %%if 0%{?fedora} > 8
  %%endif
  %%if 0%{?suse_version}
  %%endif
Предлагаю развернуть эти блоки (либо оставить содержимое, либо нет)

Часто авторы апстримов не умеют и не хотят писать спеки пакетов, делают это только от большой нужды.
Здесь видно, что авторы апстрима решили натянуть один RPM-спек на вообще любые системы, куда пакет мог бы быть установлен.
Это значительно усложняет чтение спека, ALT-only спек был бы короче.
Ну и далее в том же духе: стоило бы поменять местами наполнение platform_macros.GNU и условные макроподстановки, "вывернуть наизнанку":
  %if %{?_with_inline:1}%{!?_with_inline:0}
  %define inline -D__ACE_INLINE__ -U__ACE_NO_INLINE__
  %else
  %define inline -D__ACE_NO_INLINE__ -U__ACE_INLINE__
  %endif
  
  cat >> $ACE_ROOT/include/makeinclude/platform_macros.GNU <<EOF
  ssl = 1
  
  %if %{?_with_inline:1}%{!?_with_inline:0}
  inline = 1
  %else
  inline = 0
  %endif
  
  %if %{?_with_xt:1}%{!?_with_xt:0}
  xt = 1
  ace_xtreactor = 1
  x11 = 1
  tao_xtresource = 1
  %endif
  
  %if %{?_with_tk:1}%{!?_with_tk:0}
  ace_tkreactor = 1
  tao_tkresource = 1
  tk = 1
  %endif
  
  %if %{?_with_fl:1}%{!?_with_fl:0}
  fl = 1
  tao_flresource = 1
  ace_flreactor = 1
  %endif
  
  %if %{?_with_qt:1}%{!?_with_qt:0}
  qt4 = 1
  gl = 1
  ace_qt4reactor = 1
  tao_qt4resource = 1
  %endif
  EOF
Меньше fork+exec, короче паста.
Чуть ниже, где buildbits = 64, они забыли aarch64 (или, если проект родом из нулевых и ранее, не думали, что этим кончится). (В этом, кстати, прошу разобраться, здесь может быть зарыта серьёзная ошибка упаковки под aarch64) И т. п.

3) Видно, что приходится очень много раз ручками звать команду install(1). У неё есть опция `-v`. Пожалуйста, включайте её; это сильно повысит полезность лога сборки, куда попадают стандартные потоки rpmbuild. Ну, и аналогично с mv -v, cp -v, ln -v, chmod -c, ..., хотя там могут быть и исключения.

Мелкие (мелочные) замечания, они же nitpicks, nits:
— скриптлеты у tao-* однотипны, а иногда просто совпадают; возможно, они напрашиваются на макрофикацию — по крайней мере, пока мы не ввели дистрибутивный механизм резервации UID для сервисов.

(In reply to ratkin from comment #29)
> пакеты собранные для Join:
> https://packages.altlinux.org/ru/tasks/345179/
В спеке есть вот этот фрагмент:
https://git.altlinux.org/tasks/345179/gears/100/git?p=git;a=blob;f=ace-tao.spec;h=eb1ff505e253943f96e91c211ddbf97b629b1eb4;hb=be051e8f04ce4279a84279528a4313a81532bc00#l1378
Вопросы _к кандидату_:
— зачем там под %buildroot создаются симлинки в никуда? Тем более, что они потом unpackaged, что мы с вами увидели выше. Тем более, что потом их приходится выфильтровывать из цикла.
— обоснуйте, пожалуйста, выбор выражений для sed в строках 1386-1391. Уверены ли вы, что номера строк сохранятся в будущих релизах?

Ещё вопросы к кандидату:
— чего призваны добиться следующие строки:
  85 Requires(post):   /sbin/install-info
  86 Requires(preun):  /sbin/install-info
— Нужна ли вообще поддержка следующего случая? Я не эксперт по ace и tao, интересуюсь. Понятно, что главным экспертом по ace и tao в ALT Linux Team будет наш кандидат. :)
  160 %if 0%{?make_nosrc}
  161 # Leave out the distro for now
  162 NoSource: 0
  163 %endif
— Зачем здесь прямые зависимости на файлы? Неужели autoreq не справляется?
  466 Requires: %_libdir/libX11.so
  467 Requires: %_libdir/libXt.so

В зависимости от ответа станет понятно, есть ли тут грубые ошибки упаковки или нет.

(In reply to ratkin from comment #29)
> пакеты собранные для Join:
> https://packages.altlinux.org/ru/tasks/344757/

fwbackups:

Не вижу define _unpackaged_files_terminate_build 1.
Соответственно:
  [00:00:06] warning: Installed (but unpackaged) file(s) found:
  [00:00:06]     /usr/share/metainfo/com.diffingo.fwbackups.metainfo.xml

В коммите https://git.altlinux.org/tasks/344757/gears/200/git?p=git;a=commitdiff;h=39f3ef45e254febb327ee7840166b6cd51af1806
пропали runtime-зависимости на:
  /usr/bin/crontab
  tar
  rsync
Нужны ли они, сейчас и в прошлом?

На заметку: gear поддерживает вариант директивы `copy?:`.
`man 5 gear-rules`:
  ... unmatched patterns are ignored instead of causing errors.
Удобно, если патчи стали не нужны, и *.patch не раскрывается ни во что.
Но решать вам.
Ещё на заметку: у нас есть провайды вида python3(x) для чего-либо, доступного по import x; на мой взгляд, логичнее указывать в спеке в BR эту информацию, чем имя пакета, в общем случае. Точно так же: решать вам.

> https://packages.altlinux.org/tasks/344215/
> https://packages.altlinux.org/tasks/344185/
cargo и питоньи модули посмотрю чуть позже, а пока жду ответов на вопросы. :)

(Ответ для Arseny Maslennikov на комментарий #33)
> 1) Спек dre-ace-tao новый для Sisyphus, но в нём нет:
>   %define _unpackaged_files_terminate_build 1
> Эта директива должна была бы подразумеваться по умолчанию, но мы решили так
> не делать по просьбе вашего ментора, которому пришлось бы мегасрочно чинить
> сотни пакетов — иначе их было бы нельзя обновить или пересобрать.
Нет. Я вообще против и сейчас. Для меня это бесполезная опция, ведущая только к дополнительному усложнению сопровождения пакетов.

> В новых же пакетах нет ни одной причины не включать эту директиву.
Нет ни одной причины её включать для меня.

(Ответ для Sergey V Turchin на комментарий #36)
> >   %define _unpackaged_files_terminate_build 1
> Для меня это бесполезная опция, ведущая
> только к дополнительному усложнению сопровождения пакетов.
Если хотите включить -- сделайте голосование среди тех, кто собирает _больше_ пакетов, чем я и я соглашусь с результатами.

(Ответ для Sergey V Turchin на комментарий #36)
> (Ответ для Arseny Maslennikov на комментарий #33)
> > 1) Спек dre-ace-tao новый для Sisyphus, но в нём нет:
> >   %define _unpackaged_files_terminate_build 1
> > Эта директива должна была бы подразумеваться по умолчанию, но мы решили так
> > не делать по просьбе вашего ментора, которому пришлось бы мегасрочно чинить
> > сотни пакетов — иначе их было бы нельзя обновить или пересобрать.
> Нет. Я вообще против и сейчас. Для меня это бесполезная опция, ведущая
> только к дополнительному усложнению сопровождения пакетов.
> 
> > В новых же пакетах нет ни одной причины не включать эту директиву.
> Нет ни одной причины её включать для меня.

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

И это поведение ломается любым удалением неупакованных файлов.

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

(Ответ для Anton Farygin на комментарий #38)
> (Ответ для Sergey V Turchin на комментарий #36)
> > (Ответ для Arseny Maslennikov на комментарий #33)
> > > 1) Спек dre-ace-tao новый для Sisyphus, но в нём нет:
> > >   %define _unpackaged_files_terminate_build 1
> > > Эта директива должна была бы подразумеваться по умолчанию, но мы решили так
> > > не делать по просьбе вашего ментора, которому пришлось бы мегасрочно чинить
> > > сотни пакетов — иначе их было бы нельзя обновить или пересобрать.
> > Нет. Я вообще против и сейчас. Для меня это бесполезная опция, ведущая
> > только к дополнительному усложнению сопровождения пакетов.
> > 
> > > В новых же пакетах нет ни одной причины не включать эту директиву.
> > Нет ни одной причины её включать для меня.
> 
> Я поддерживаю.
> Мне в моих пакетах очень удобно видеть в логах список файлов, которые я не
> упаковал.
> 
> И это поведение ломается любым удалением неупакованных файлов.
> 
> Опция была бы полезна только в том случае, когда для неё будет добавлена
> возможность игнорирования файлов по маске.

Я буквально вчера лично писал Арсению "гневное письмо" по поводу обязаловки использования этого макроса. Не думал, что моя нелюбовь к этому макросу найдёт отклик в сердцах других людей. Я тоже собираю много пакетов и тоже категорически против использования этого макроса, так как он больше мешает, чем помогает. Неупакованные файлы довольно ярко отображаются в логах и нет ничего плохого в том, чтобы лишний раз хотя бы бегло глянуть лог. Мало ли, может бросится в глаза ещё что-то.

Плюсую против использования этого макроса.

(In reply to Anton Farygin from comment #38)
> (Ответ для Sergey V Turchin на комментарий #36)
> > (Ответ для Arseny Maslennikov на комментарий #33)
> > > 1) Спек dre-ace-tao новый для Sisyphus, но в нём нет:
> > >   %define _unpackaged_files_terminate_build 1
> > > Эта директива должна была бы подразумеваться по умолчанию, но мы решили так
> > > не делать по просьбе вашего ментора, которому пришлось бы мегасрочно чинить
> > > сотни пакетов — иначе их было бы нельзя обновить или пересобрать.
> > Нет. Я вообще против и сейчас. Для меня это бесполезная опция, ведущая
> > только к дополнительному усложнению сопровождения пакетов.
> > 
> > > В новых же пакетах нет ни одной причины не включать эту директиву.
> > Нет ни одной причины её включать для меня.
> 
> Я поддерживаю.
> Мне в моих пакетах очень удобно видеть в логах список файлов, которые я не
> упаковал.
> 
> И это поведение ломается любым удалением неупакованных файлов.

Это вполне разумное желание. У мейнтейнера есть (и никто не отнимает) право явно решить, что определённые файлы (возможно, по маске/глобу) не нужны, а у всей Team есть право увидеть в логе, что произошло.

Но это решение, на мой взгляд, должно присутствовать в спеке (т. е. попасть в СКВ, а ещё лучше быть там задокументированным) как явное: мол, строчки в спеке "мейнтейнер явно проигнорировал список файловых путей", они появились в коммите (т. е. sign-off деяние), строчки в логе с перечислением проигнорированных файлов.
Проще должно быть не только мейнтейнеру, но и всем остальным.

Явный rm -vf %buildroot/pattern1 %buildroot/pattern2 %buildroot/pattern3 в конце секции %install — пойдёт:
+ в спеке присутствует (явно, командой)
+ в логе присутствует (опция --verbose)
­+ можно по glob
- недостаток: длинно писать (общий префикс %buildroot у всех путей).
* сводка о неупакованных файлах будет не в конце, а после %install, но, с другой стороны, она и сейчас не в конце, а иногда на пару-тройку экранов раньше (перед строчками Wrote: на каждый rpm-артефакт).

Иначе говоря, я бы предложил _u_f_t_b 1 по умолчанию + какое-то устраивающее всех решение для явного игнора файлов, удовлетворяющее предыдущим абзацам. Например, стоило бы обсудить, в какой части лога мейнтейнерам удобно видеть список неупакованных путей (в конце? в секции %install?).

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

(In reply to Arseny Maslennikov from comment #40)
> (In reply to Anton Farygin from comment #38)
> > (Ответ для Sergey V Turchin на комментарий #36)
> > > (Ответ для Arseny Maslennikov на комментарий #33)
> > > > 1) Спек dre-ace-tao новый для Sisyphus, но в нём нет:
> > > >   %define _unpackaged_files_terminate_build 1
> > > > Эта директива должна была бы подразумеваться по умолчанию, но мы решили так
> > > > не делать по просьбе вашего ментора, которому пришлось бы мегасрочно чинить
> > > > сотни пакетов — иначе их было бы нельзя обновить или пересобрать.
> > > Нет. Я вообще против и сейчас. Для меня это бесполезная опция, ведущая
> > > только к дополнительному усложнению сопровождения пакетов.
> > > 
> > > > В новых же пакетах нет ни одной причины не включать эту директиву.
> > > Нет ни одной причины её включать для меня.
> > 
> > Я поддерживаю.
> > Мне в моих пакетах очень удобно видеть в логах список файлов, которые я не
> > упаковал.
> > 
> > И это поведение ломается любым удалением неупакованных файлов.
> 
> Это вполне разумное желание. У мейнтейнера есть (и никто не отнимает) право
> явно решить, что определённые файлы (возможно, по маске/глобу) не нужны, а у
> всей Team есть право увидеть в логе, что произошло.
> 
> Но это решение, на мой взгляд, должно присутствовать в спеке (т. е. попасть
> в СКВ, а ещё лучше быть там задокументированным) как явное: мол, строчки в
> спеке "мейнтейнер явно проигнорировал список файловых путей", они появились
> в коммите (т. е. sign-off деяние), строчки в логе с перечислением
> проигнорированных файлов.
> Проще должно быть не только мейнтейнеру, но и всем остальным.
> 
> Явный rm -vf %buildroot/pattern1 %buildroot/pattern2 %buildroot/pattern3 в
> конце секции %install — пойдёт:
> + в спеке присутствует (явно, командой)
> + в логе присутствует (опция --verbose)
> ­+ можно по glob
> - недостаток: длинно писать (общий префикс %buildroot у всех путей).
> * сводка о неупакованных файлах будет не в конце, а после %install, но, с
> другой стороны, она и сейчас не в конце, а иногда на пару-тройку экранов
> раньше (перед строчками Wrote: на каждый rpm-артефакт).
> 
> Иначе говоря, я бы предложил _u_f_t_b 1 по умолчанию + какое-то устраивающее
> всех решение для явного игнора файлов, удовлетворяющее предыдущим абзацам.
> Например, стоило бы обсудить, в какой части лога мейнтейнерам удобно видеть
> список неупакованных путей (в конце? в секции %install?).
> 
> --
> Вообще критики правы в том, что этот макрос, как и многие наши меры
> автоматизированного поддержания порядка в репозитории, вместо помощи
> мейнтейнеру устроен как кувалда, бьющая его по голове, что плохо. Но лучше
> что-то, чем совсем ничего.

Но это всё касается возобновившейся дискуссии о _u_f_t_b 1 по умолчанию. А у нас здесь joinится кандидат; в контексте его пакетов от отсутствия _u_f_t_b 1 в спеке произошли грубые ошибки упаковки, которые бы этот макрос предотвратил, а файлов не так много, чтобы этот макрос мешал. Если _u_f_t_b 1 мешает итеративной работе над спеком, его можно на ранних стадиях этой работы задать в 0, а на поздних (до сборочницы) задать в 1.
Я категорически против того, чтобы приучать новых участников Team к неряшливости, хоть никто из людей ей и не чужд; она и без помощи ментора/рецензента заводится, незачем помогать этому процессу. (Конечно, явный игнор файловых путей мейнтейнером из предыдущего коммента ничего общего с неряшливостью не имеет, а, напротив, ей противоположен)

Есть ещё _stripped_files_terminate_build, но:
— чтобы он помогал, нужно разбираться в отладочном инфо для бинарников, в причинах, почему оно может не генерироваться, etc.,
— если пакет noarch, там нет arch-specific бинарников, т. е. семантика макроса неважна;
— для очень толстых программ и библиотек генерацию отладочного инфо вообще приходится выключать из-за ограниченных ресурсов;
поэтому на его применении не настаиваю.

Да, с тем что ментейнер должен уметь пользоваться данным макросом, когда это нужно - согласен.

(Ответ для Arseny Maslennikov на комментарий #41)
> у нас здесь joinится кандидат; в контексте его пакетов
Вот и не надо было выходить за этот контекст. :-)

(Ответ для Arseny Maslennikov на комментарий #33)
> Ну и далее в том же духе: стоило бы поменять местами наполнение
> platform_macros.GNU и условные макроподстановки, "вывернуть наизнанку":
>   %if %{?_with_inline:1}%{!?_with_inline:0}
>   %define inline -D__ACE_INLINE__ -U__ACE_NO_INLINE__
>   %else
>   %define inline -D__ACE_NO_INLINE__ -U__ACE_INLINE__
>   %endif
>   
>   cat >> $ACE_ROOT/include/makeinclude/platform_macros.GNU <<EOF
>   ssl = 1
>   
>   %if %{?_with_inline:1}%{!?_with_inline:0}
>   inline = 1
>   %else
>   inline = 0
>   %endif
>   
>   %if %{?_with_xt:1}%{!?_with_xt:0}
>   xt = 1
>   ace_xtreactor = 1
>   x11 = 1
>   tao_xtresource = 1
>   %endif
>   
>   %if %{?_with_tk:1}%{!?_with_tk:0}
>   ace_tkreactor = 1
>   tao_tkresource = 1
>   tk = 1
>   %endif
>   
>   %if %{?_with_fl:1}%{!?_with_fl:0}
>   fl = 1
>   tao_flresource = 1
>   ace_flreactor = 1
>   %endif
>   
>   %if %{?_with_qt:1}%{!?_with_qt:0}
>   qt4 = 1
>   gl = 1
>   ace_qt4reactor = 1
>   tao_qt4resource = 1
>   %endif
>   EOF
> Меньше fork+exec, короче паста.
Не очень понял что имеется в виду под вывернуть наизнанку

(Ответ для Arseny Maslennikov на комментарий #34)
> — зачем там под %buildroot создаются симлинки в никуда? Тем более, что они
> потом unpackaged, что мы с вами увидели выше. Тем более, что потом их
> приходится выфильтровывать из цикла.
> — обоснуйте, пожалуйста, выбор выражений для sed в строках 1386-1391.
> 
Эту часть я посмотрел в https://packages.altlinux.org/ru/p5/srpms/ace-tao-ciao/specfiles/

про aarch64 они и правда забыли в спеке
Ответы на вопросы и исправления скоро подготовлю

(In reply to ratkin from comment #44)
> (Ответ для Arseny Maslennikov на комментарий #33)
> > Ну и далее в том же духе: стоило бы поменять местами наполнение
> > platform_macros.GNU и условные макроподстановки, "вывернуть наизнанку":
> >   %if %{?_with_inline:1}%{!?_with_inline:0}
> >   %define inline -D__ACE_INLINE__ -U__ACE_NO_INLINE__
> >   %else
> >   %define inline -D__ACE_NO_INLINE__ -U__ACE_INLINE__
> >   %endif
> >   
> >   cat >> $ACE_ROOT/include/makeinclude/platform_macros.GNU <<EOF
> >   ssl = 1
> >   
> >   %if %{?_with_inline:1}%{!?_with_inline:0}
> >   inline = 1
> >   %else
> >   inline = 0
> >   %endif
> >   
> >   %if %{?_with_xt:1}%{!?_with_xt:0}
> >   xt = 1
> >   ace_xtreactor = 1
> >   x11 = 1
> >   tao_xtresource = 1
> >   %endif
> >   
> >   %if %{?_with_tk:1}%{!?_with_tk:0}
> >   ace_tkreactor = 1
> >   tao_tkresource = 1
> >   tk = 1
> >   %endif
> >   
> >   %if %{?_with_fl:1}%{!?_with_fl:0}
> >   fl = 1
> >   tao_flresource = 1
> >   ace_flreactor = 1
> >   %endif
> >   
> >   %if %{?_with_qt:1}%{!?_with_qt:0}
> >   qt4 = 1
> >   gl = 1
> >   ace_qt4reactor = 1
> >   tao_qt4resource = 1
> >   %endif
> >   EOF
> > Меньше fork+exec, короче паста.
> Не очень понял что имеется в виду под вывернуть наизнанку
Сейчас в спеке вызовы cat >> f вложены в макроветвления — и тогда эти вызовы должны быть отдельными (в зависимости от значений _with_* они либо присутствуют, либо отсутствуют).
Я имел в виду следующую трансформацию: вложить макроветвления в вызов cat >> f; в частности, тогда достаточно только одного обращения к cat, а содержимое общего heredoc будет зависеть от _with_*.
Меньше вызовов программ, меньше самоповторов в коде, код короче. :)

(Ответ для Arseny Maslennikov на комментарий #34)
> Вопросы _к кандидату_:
> — зачем там под %buildroot создаются симлинки в никуда? Тем более, что они
> потом unpackaged, что мы с вами увидели выше. Тем более, что потом их
> приходится выфильтровывать из цикла.
Убрал симлинки

> — обоснуйте, пожалуйста, выбор выражений для sed в строках 1386-1391.
> Уверены ли вы, что номера строк сохранятся в будущих релизах?
> 
выражения для sed я подсмотред(написал выше), номера строк не менялись с 2009
> Ещё вопросы к кандидату:
> — чего призваны добиться следующие строки:
>   85 Requires(post):   /sbin/install-info
>   86 Requires(preun):  /sbin/install-info
> — Нужна ли вообще поддержка следующего случая? Я не эксперт по ace и tao,
> интересуюсь. Понятно, что главным экспертом по ace и tao в ALT Linux Team
> будет наш кандидат. :)
>   160 %if 0%{?make_nosrc}
>   161 # Leave out the distro for now
>   162 NoSource: 0
>   163 %endif
Данные строки не нужны, удалил их
> — Зачем здесь прямые зависимости на файлы? Неужели autoreq не справляется?
>   466 Requires: %_libdir/libX11.so
>   467 Requires: %_libdir/libXt.so
там чуть выше было написана причина 
# The xorg package naming scheme changed, use specific files for now.
# old -> Requires: xorg-x11-devel
# new -> Requires: libX11-devel
Заменил на пакеты

Так же дочистил спек и добавил verbose опции.
buildbits=64 для aarch поставить нельзя т.к. это просто добаляет опцию -m64 которой там нет, хотя вот здесь aarch64 учитывается https://git.altlinux.org/tasks/345179/gears/300/git?p=git;a=blob;f=ACE_wrappers/ace/config-linux-common.h;h=d71151c02d2fb4fe67a8a33eba484b55d2e91bca;hb=HEAD#l181

(Ответ для Arseny Maslennikov на комментарий #35)
> (In reply to ratkin from comment #29)
> > пакеты собранные для Join:
> > https://packages.altlinux.org/ru/tasks/344757/
> 
> fwbackups:
> 
> Не вижу define _unpackaged_files_terminate_build 1.
> Соответственно:
>   [00:00:06] warning: Installed (but unpackaged) file(s) found:
>   [00:00:06]     /usr/share/metainfo/com.diffingo.fwbackups.metainfo.xml

Добавил файл в пакет
> 
> В коммите
> https://git.altlinux.org/tasks/344757/gears/200/git?p=git;a=commitdiff;
> h=39f3ef45e254febb327ee7840166b6cd51af1806
> пропали runtime-зависимости на:
>   /usr/bin/crontab
>   tar
>   rsync
> Нужны ли они, сейчас и в прошлом?
> 
они скорее Recommended так что убрал
> На заметку: gear поддерживает вариант директивы `copy?:`.
> `man 5 gear-rules`:
>   ... unmatched patterns are ignored instead of causing errors.
> Удобно, если патчи стали не нужны, и *.patch не раскрывается ни во что.
Поправил на этот вариант
> Но решать вам.
> Ещё на заметку: у нас есть провайды вида python3(x) для чего-либо,
> доступного по import x; на мой взгляд, логичнее указывать в спеке в BR эту
> информацию, чем имя пакета, в общем случае. Точно так же: решать вам.
Мне удобнее имена пакетов, так что предпочёл бы их оставить

Для aarch64 пока отключил сборку, попробую разобраться что там

(In reply to ratkin from comment #46)
> (Ответ для Arseny Maslennikov на комментарий #34)
> > Вопросы _к кандидату_:
> > — зачем там под %buildroot создаются симлинки в никуда? Тем более, что они
> > потом unpackaged, что мы с вами увидели выше. Тем более, что потом их
> > приходится выфильтровывать из цикла.
> Убрал симлинки
OK.
(In reply to ratkin from comment #46)
> (Ответ для Arseny Maslennikov на комментарий #34)
> > — обоснуйте, пожалуйста, выбор выражений для sed в строках 1386-1391.
> > Уверены ли вы, что номера строк сохранятся в будущих релизах?
> > 
> выражения для sed я подсмотред(написал выше)
Ага. Ну вот не надо бездумно повторять за людьми.
> номера строк не менялись с 2009
Это если и успокаивает, то совсем чуть-чуть. От этого код не прекращает быть неоправданно трудным в ручном чтении.
(In reply to ratkin from comment #46)
> (Ответ для Arseny Maslennikov на комментарий #34)
> > Ещё вопросы к кандидату:
> > — чего призваны добиться следующие строки:
> >   85 Requires(post):   /sbin/install-info
> >   86 Requires(preun):  /sbin/install-info
> > — Нужна ли вообще поддержка следующего случая? Я не эксперт по ace и tao,
> > интересуюсь. Понятно, что главным экспертом по ace и tao в ALT Linux Team
> > будет наш кандидат. :)
> >   160 %if 0%{?make_nosrc}
> >   161 # Leave out the distro for now
> >   162 NoSource: 0
> >   163 %endif
> Данные строки не нужны, удалил их
Хорошо.
> > — Зачем здесь прямые зависимости на файлы? Неужели autoreq не справляется?
> >   466 Requires: %_libdir/libX11.so
> >   467 Requires: %_libdir/libXt.so
> там чуть выше было написана причина 
> # The xorg package naming scheme changed, use specific files for now.
> # old -> Requires: xorg-x11-devel
> # new -> Requires: libX11-devel
> Заменил на пакеты
OK, хорошо.
Правильно, что написали комментарий: я поленился тогда убедиться, что эту строчку вы вписали, а не real@ и те, у кого он взял ранние версии спека.
> Так же дочистил спек и добавил verbose опции.
Вижу, поменяли местами вложенность. Любо!

> buildbits=64 для aarch поставить нельзя т.к. это просто добаляет опцию -m64
> которой там нет, хотя вот здесь aarch64 учитывается
> https://git.altlinux.org/tasks/345179/gears/300/git?p=git;a=blob;
> f=ACE_wrappers/ace/config-linux-common.h;
> h=d71151c02d2fb4fe67a8a33eba484b55d2e91bca;hb=HEAD#l181
Очень хорошо. Тогда там стоит оставить коммент, что это `-m64`, а не что-то иное.

https://git.altlinux.org/tasks/345179/gears/300/git?p=git;a=commitdiff;h=f8570569477a7802b222a0dc1820821fff1d93a9
> @@ -2227,6 +2168,9 @@ fi
>  %endif
>  
>  %changelog
> +* Fri Oct 04 2024 Daniil-Viktor Ratkin <krf10@altlinux.org> 8.0.1-alt2
> +- speak clean up
> +
>  * Tue Aug 06 2024 Daniil-Viktor Ratkin <krf10@altlinux.org> 8.0.1-alt1
>  - new version
>  

Формально это будет минорная претензия, ничем не отличающаяся от других возражений по наполнению rpm changelog, но это предложение меня ввергло в смятение, как когда-то Глеба повреждённое представление GPG-ключа.
Любопытно, это <strong><u>чем</u></strong> же вы умудрились так написать. :) Какой инструмент автора спека способен "spec" превратить... в "speak"?
Это надиктовано голосовому помощнику, что ли, или просто составлено LLM? Если да, это в принципе отбрасывает тень на вклад того, кто так делает; не надо так. Мы, в отличие от других проектов, если я что-нибудь не прозевал, пока не сталкивались с тем, чтобы мейнтейнеры от своего имени вносили в ALT непроверенный/неисправленный LLM-генерат, но вряд ли хотели бы попасть в такую ситуацию (как и в ситуацию, где мейнтейнер приносит зловредный код на сборочницу и в репозиторий). Мы мейнтейнерам доверяем.
The process of joining ALT Linux Team включает не только обучение кандидата в альтотиму собирать пакеты и нажимать правильные кнопки, но и установление взаимного доверия и опыт погружения в командную (team) работу, поэтому я обязан об этом упомянуть.

Короче, просто напишите нормально. :)

> Какой инструмент автора спека способен "spec" превратить... в "speak"?
это я руками написал, по-ходу в голове разговор был в этот момент)

(Ответ для Arseny Maslennikov на комментарий #50)
> Какой инструмент автора спека способен "spec" превратить... в "speak"?
Тот же, который у меня периодически превращает rpm в rm, legion в leguin и kernel в kdernel. ;-)

(Ответ для Arseny Maslennikov на комментарий #49)
> > h=d71151c02d2fb4fe67a8a33eba484b55d2e91bca;hb=HEAD#l181
> Очень хорошо. Тогда там стоит оставить коммент, что это `-m64`, а не что-то
> иное.
Оставил коммент, вернул сборку aarch64, настроек из конфигов должно хватать.
Поправил changelog.

(In reply to Sergey V Turchin from comment #52)
> (Ответ для Arseny Maslennikov на комментарий #50)
> > Какой инструмент автора спека способен "spec" превратить... в "speak"?
> Тот же, который у меня периодически превращает rpm в rm, legion в leguin и
> kernel в kdernel. ;-)
Кстати, телефонные автокорректы при написании спека тоже лучше выключать. :)

(In reply to ratkin from comment #51)
> > Какой инструмент автора спека способен "spec" превратить... в "speak"?
> это я руками написал, по-ходу в голове разговор был в этот момент)
Ну ничего, бывает. Но про инструменты имейте в виду. Не нужно, чтобы инструменты были умнее мейнтейнера. :)

(In reply to ratkin from comment #29)
> пакеты собранные для Join:
> https://packages.altlinux.org/ru/tasks/344215/
> https://packages.altlinux.org/ru/tasks/344185/

czkawka:

Посмотрел я на чкавку.

Два вопроса: оба из них точно касаются и dre-ace-tao тоже, кстати.

1) У вас в gear-правилах:
     tar.gz: czkawka
И в спеке:
   8 Source0: %name-%version.tar.gz
То есть в дереве под git-коммитом каталог (который, как известно[1], тоже git-дерево), из него программе gear предписано собрать сжатый tarball, а потом RPM в сборочном окружении (вызвав tar, конечно) распакует его на место. А зачем сжимать? Чем это лучше следующего:
     tar: czkawka

[1] https://maryrosecook.com/blog/post/git-from-the-inside-out

2) В списках файлов подпакетов присутствует директива %doc и какие-то файлы там у неё. С какой целью вы её там указали и чего хотели бы добиться?

Эти вопросы чаще всего не имеют целью указать на ошибку; для большинства правил упаковки, не обеспеченных автопроверкой, бывают исключения, и важно, чтобы мейнтейнер/кандидат дал на них обоснованный ответ сам, и:
* либо понимал, что тут исключение, и почему,
* либо признал ошибку,
* либо иным образом обосновал свою позицию (возможно, глядящую в будущее) и был убедителен.
Вот на вопрос про %doc есть ответ третьего типа ;), но мне интересен ответ Даниила-Виктора.

Я же пока пойду читать питон (task 344185)

(Ответ для Arseny Maslennikov на комментарий #54)
> > у меня периодически превращает rpm в rm, legion в leguin и
> > kernel в kdernel. ;-)
> Кстати, телефонные автокорректы при написании спека тоже лучше выключать. :)
Да, они таких слов не знают. ;-)

P.S.
Это одна из 1-х настроек, отключаемых мной сразу же на смартфоне.

(Ответ для Arseny Maslennikov на комментарий #55)
> А зачем сжимать? Чем это лучше следующего:
>      tar: czkawka
Да. rpm сверху сожмёт xz, т.е. будет только хуже.
Ещё я, напрмер, постоянно пользуюсь gear-rpm --short-circuit, а со сжатием оно прилично медленнее.

(Ответ для Arseny Maslennikov на комментарий #55)

>    8 Source0: %name-%version.tar.gz
> То есть в дереве под git-коммитом каталог (который, как известно[1], тоже
> git-дерево), из него программе gear предписано собрать сжатый tarball, а
> потом RPM в сборочном окружении (вызвав tar, конечно) распакует его на
> место. А зачем сжимать? Чем это лучше следующего:
>      tar: czkawka
как я понял причин сжимать нету, уберу сжатие
> 
> 2) В списках файлов подпакетов присутствует директива %doc и какие-то файлы
> там у неё. С какой целью вы её там указали и чего хотели бы добиться?
> 
В czkawka в каждом пакете разные readme, в которых есть подсказки про использование и описано в чём разница в пакетах, changelog там указан для самой программы и при обновлении версии там можно узнать что поменялось,а вот лицензии в каждом пакете вероятно излишни(то же касается ace-tao).

В ace-tao %doc есть в каждом пакете, это вероятно излишне т.к. файлы там одинаковые, их думаю достаточно было указать в основном пакете libace, а в целом не вижу причин не указать авторов, лицензию, и доп информацию

@arseny вы там не забыли про join)?

(In reply to ratkin from comment #59)
> @arseny вы там не забыли про join)?

Пришлось выпасть из контекста, поэтому чуть не забыл. На этой неделе прокомментирую. Если нет — смело пингуйте :)

(Ответ для Arseny Maslennikov на комментарий #60)
> прокомментирую. Если нет — смело пингуйте :)
@arseny ping

Ещё немного поменял ace-tao, убрал sed, добавил init скрипты для альта(до этого sed просто менял скрипты федоры под альт).

(In reply to ratkin from comment #58)
> (Ответ для Arseny Maslennikov на комментарий #55)
> 
> >    8 Source0: %name-%version.tar.gz
> > То есть в дереве под git-коммитом каталог (который, как известно[1], тоже
> > git-дерево), из него программе gear предписано собрать сжатый tarball, а
> > потом RPM в сборочном окружении (вызвав tar, конечно) распакует его на
> > место. А зачем сжимать? Чем это лучше следующего:
> >      tar: czkawka
> как я понял причин сжимать нету,
Ну, в общем, да.

> уберу сжатие
OK, увидел. :)

> > 2) В списках файлов подпакетов присутствует директива %doc и какие-то файлы
> > там у неё. С какой целью вы её там указали и чего хотели бы добиться?
> > 
> В czkawka в каждом пакете разные readme, в которых есть подсказки про
> использование и описано в чём разница в пакетах, changelog там указан для
> самой программы и при обновлении версии там можно узнать что поменялось,а
> вот лицензии в каждом пакете вероятно излишни(то же касается ace-tao).
> 
> В ace-tao %doc есть в каждом пакете, это вероятно излишне т.к. файлы там
> одинаковые, их думаю достаточно было указать в основном пакете libace, а в
> целом не вижу причин не указать авторов, лицензию, и доп информацию

Ладно. Я думал, что у вас %doc не сработает в подпакетах, но, если взглянуть на пакеты из задания, то всё там правильно упаковалось согласно спеку.

На самом деле класть лицензии в пакет необязательно, хоть они и лежат во многих пакетах по старой памяти.
Лицензии, строго говоря, у нас лежат в пакете common-licenses; это не только сокращает к-во копий текстов лицензий, но и полезно с точки зрения маркировки пакета лицензиями на его содержимое (для машинного разбора удобнее взять тег License:, чем догадываться, где там в пакете текст лицензии и что он означает). В существующих спеках в альте наблюдается некоторый разнобой с этим, но давно планируется навести порядок.
Если у вас в пакете необычная лицензия, то надо в теге License: своего спека указать либо её SPDX-идентификатор, либо `ALT-$ID` и под этим ID положить в common-licenses текст лицензии; см, например, ALT-Zsh.
Если же типичная лицензия, то достаточно просто её указать в License:.

(In reply to ratkin from comment #61)
> (Ответ для Arseny Maslennikov на комментарий #60)
> > прокомментирую. Если нет — смело пингуйте :)
> @arseny ping
> 
> Ещё немного поменял ace-tao, убрал sed, добавил init скрипты для альта(до
> этого sed просто менял скрипты федоры под альт).
Здо́рово!

(In reply to Arseny Maslennikov from comment #55)
> (In reply to ratkin from comment #29)
> > пакеты собранные для Join:
> Я же пока пойду читать питон (task 344185)

К питону вопросов особых нет; разве только в качестве URL пакетов с модулями, наверное, стоит указывать URL проекта на pypi.org.

(In reply to ratkin from comment #29)
> пакеты собранные для Join:
> https://packages.altlinux.org/ru/tasks/345179/
> https://packages.altlinux.org/ru/tasks/344215/
> https://packages.altlinux.org/ru/tasks/344757/
> https://packages.altlinux.org/ru/tasks/344185/

В общем, тут меня всё более-менее устраивает.

В цели вступления написано:
(In reply to ratkin from comment #0)
> Цель : участие в разработке ПО
Т. е. в ELF надо шарить хотя бы на среднем (intermediate) уровне.

Можно было бы ещё попросить ув. кандидата правильно обновить/упаковать какую-нибудь бинарную разделяемую библиотеку, но я сходу не подберу годный пакет. Можно какую-нибудь уже упакованную и заброшенную — например, по данным repology — взять.

Ну или хотя бы посоветую ознакомиться вот с этой для начала страничкой:
https://www.altlinux.org/Shared_Libs_Policy_Comments
Смысл в том, чтобы:
— отделять пакет с lib$name.so.* от пакета с lib$name.so и остального;
— обеспечить соустанавливаемость двух таких пакетов с библиотеками разных версий ABI в одну систему.
В debian, например, так делают пару десятков лет или более, а в arch не делают до сих пор. Пока мы это не автоматизировали, надо явно за таким следить, иначе в ряде ситуаций наш apt не справляется.

С моей точки зрения, кандидат научился собирать пакеты разного рода, не допуская грубых ошибок, с точностью до удобной ему манеры работы над спеком, и продемонстрировал, что понимает, что делает. Думаю, можно переходить на следующую стадию T/J/S.

Пользователь добавлен в группу мейнтейнеров.

Желаю удачного мейнтейнерства!

Уря!