46983 2023-07-19 14:35:01 +0300 [done] join krf10@ 2024-11-02 11:01:09 +0300 1 1 4 Development Team Accounts join unspecified x86_64 Linux CLOSED FIXED https://altlinux.org/Team/Join P5 normal --- 1 ratkinda glebfm arseny glebfm grenka ldv rider zerg cas oldest_to_newest 230007 0 13881 ratkinda 2023-07-19 14:35:01 +0300 Created attachment 13881 ssh public key Псевдоним : krf10 адрес пересылки почты : ratkinda@basealt.ru имя ментора : Sergey Turchin zerg@ Цель : участие в разработке ПО 230008 1 13882 ratkinda 2023-07-19 14:36:13 +0300 Created attachment 13882 gpg public key 230053 2 zerg 2023-07-20 11:42:41 +0300 Подтверждаю. Согласен быть ментором. 230849 3 glebfm 2023-08-04 12:30:00 +0300 (In reply to ratkin from comment #1) > Created attachment 13882 [details] > gpg public key Позвольте поинтересоваться, а как был сформирован этот файл? Вы сами убрали -----BEGIN PGP PUBLIC KEY BLOCK----- и -----END PGP PUBLIC KEY BLOCK----- или воспользовались каким-то инструментом, который их куда-то дел? В любом случае, ключ в таком виде не подойдёт. 230862 4 13882 ratkinda 2023-08-04 13:38:13 +0300 Comment on attachment 13882 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----- 230864 5 13882 ratkinda 2023-08-04 13:42:12 +0300 Comment on attachment 13882 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----- 230865 6 glebfm 2023-08-04 13:47:03 +0300 Приложите, пожалуйста, в виде нового attachment. 230866 7 13981 ratkinda 2023-08-04 13:48:30 +0300 Created attachment 13981 gpg public key 230870 8 glebfm 2023-08-04 13:52:53 +0300 (In reply to ratkin from comment #7) > Created attachment 13981 [details] > gpg public key Ok. Но мне всё равно очень интересно, что случилось с предыдущим вариантом, я не просто так же спросил. :) 230871 9 ratkinda 2023-08-04 13:57:56 +0300 (Ответ для Gleb F-Malinovskiy на комментарий #8) > (In reply to ratkin from comment #7) > > Created attachment 13981 [подробности] [details] > > gpg public key > Ok. > > Но мне всё равно очень интересно, что случилось с предыдущим вариантом, я не > просто так же спросил. :) Просто не выделил те строки в ключе когда копировал) 230872 10 glebfm 2023-08-04 14:00:06 +0300 (In reply to ratkin from comment #9) > (Ответ для Gleb F-Malinovskiy на комментарий #8) > > Но мне всё равно очень интересно, что случилось с предыдущим вариантом, я не > > просто так же спросил. :) > Просто не выделил те строки в ключе когда копировал) Понятно, я уж испугался, что какой-то инструмент стал так делать. 231366 11 zerg 2023-08-14 13:44:24 +0300 Кандидат готов начать вступление. 232125 12 glebfm 2023-08-30 12:54:42 +0300 ssh ключ на gitery.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 2.3. 236027 13 14935 ratkinda 2023-10-31 10:03:25 +0300 Created attachment 14935 new ssh public key 236028 14 14936 ratkinda 2023-10-31 10:06:09 +0300 Created attachment 14936 new gpg public key 236029 15 ratkinda 2023-10-31 10:08:12 +0300 я положил систему и потерял прошлые ключи,можно их заменить на те , которые прикрепил выше? 236577 16 glebfm 2023-11-08 12:15:46 +0300 (In reply to ratkin from comment #15) > я положил систему и потерял прошлые ключи,можно их заменить на те , которые > прикрепил выше? Постарайтесь, пожалуйста, хранить ключи более бережно. 236578 17 glebfm 2023-11-08 12:17:57 +0300 ssh ключ на gitery.alt зарегистрирован. T/J/S -> 2.3. 237270 18 ratkinda 2023-11-16 09:15:58 +0300 Закончилась квота на gitery , прошу увеличить 237288 19 rider 2023-11-16 10:54:14 +0300 https://bugzilla.altlinux.org/enter_bug.cgi?product=Team%20Accounts компонент quota 238800 20 ratkinda 2023-12-11 16:49:58 +0300 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 238846 21 zerg 2023-12-12 12:17:49 +0300 (Ответ для ratkin на комментарий #20) > https://git.altlinux.org/people/krf10/packages/?p=cinelerra-gg.git У нас есть макросы %autoreconf и %configure . 238847 22 zerg 2023-12-12 12:20:38 +0300 (Ответ для ratkin на комментарий #20) > https://git.altlinux.org/people/krf10/packages/?p=python3-module-scrapy.git Вместо python3-dev надо python3-devel. Это нюанс. Бинарь неверняка не являются частью пакета модуля. 238901 23 ratkinda 2023-12-13 09:57:36 +0300 (Ответ для Sergey V Turchin на комментарий #22) > (Ответ для ratkin на комментарий #20) > > https://git.altlinux.org/people/krf10/packages/?p=python3-module-scrapy.git > Вместо python3-dev надо python3-devel. Это нюанс. > Бинарь неверняка не являются частью пакета модуля. через бинарник запускается кравлер, без него не будет работать 238923 24 zerg 2023-12-13 11:23:23 +0300 (Ответ для ratkin на комментарий #23) > через бинарник запускается кравлер, без него не будет работать Если бинарник может работать, как отдельная утилита и не зависит от питоньего модуля, то его надо в отдельный пакет. 242087 25 zerg 2024-02-26 11:26:24 +0300 Подопечный готов собирать пакеты. 243630 26 glebfm 2024-03-27 18:49:41 +0300 ssh ключ на gyle.alt зарегистрирован. Пакет alt-gpgkeys обновлён. Адрес подписан на devel@. T/J/S -> 3.6. 247922 27 zerg 2024-06-21 10:09:31 +0300 Подопечный готов отправлять пакеты в Сизиф. 247924 28 zerg 2024-06-21 10:11:15 +0300 Это, что уже было сделано в рамках исправлений. https://packages.altlinux.org/ru/sisyphus/maintainers/krf10/srpms 247927 29 ratkinda 2024-06-21 10:14:50 +0300 пакеты собранные для 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/ 251128 30 zerg 2024-09-03 14:59:15 +0300 up 252095 31 glebfm 2024-09-24 19:27:48 +0300 Призван рецензент (arseny@) для независимой оценки готовности кандидата. T/J/S -> 4.2. 252259 32 arseny 2024-09-27 12:46:22 +0300 (In reply to Gleb F-Malinovskiy from comment #31) > Призван рецензент (arseny@) для независимой оценки готовности кандидата. > > T/J/S -> 4.2. ACK. Позавчера начал читать dre-ace-tao и немного завяз :(, там по лидеру апстримного проекта плачет не рецензент, а кто-то ещё. Поэтому пока не комментирую работу кандидата. Надеюсь в течение недели дочитать всё из comment 29 и тогда уже комментировать. 252352 33 arseny 2024-09-30 21:07:39 +0300 (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 для сервисов. 252353 34 arseny 2024-09-30 21:09:13 +0300 (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 В зависимости от ответа станет понятно, есть ли тут грубые ошибки упаковки или нет. 252354 35 arseny 2024-09-30 21:15:03 +0300 (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 и питоньи модули посмотрю чуть позже, а пока жду ответов на вопросы. :) 252363 36 zerg 2024-10-01 09:16:01 +0300 (Ответ для Arseny Maslennikov на комментарий #33) > 1) Спек dre-ace-tao новый для Sisyphus, но в нём нет: > %define _unpackaged_files_terminate_build 1 > Эта директива должна была бы подразумеваться по умолчанию, но мы решили так > не делать по просьбе вашего ментора, которому пришлось бы мегасрочно чинить > сотни пакетов — иначе их было бы нельзя обновить или пересобрать. Нет. Я вообще против и сейчас. Для меня это бесполезная опция, ведущая только к дополнительному усложнению сопровождения пакетов. > В новых же пакетах нет ни одной причины не включать эту директиву. Нет ни одной причины её включать для меня. 252365 37 zerg 2024-10-01 09:20:05 +0300 (Ответ для Sergey V Turchin на комментарий #36) > > %define _unpackaged_files_terminate_build 1 > Для меня это бесполезная опция, ведущая > только к дополнительному усложнению сопровождения пакетов. Если хотите включить -- сделайте голосование среди тех, кто собирает _больше_ пакетов, чем я и я соглашусь с результатами. 252368 38 rider 2024-10-01 09:44:25 +0300 (Ответ для Sergey V Turchin на комментарий #36) > (Ответ для Arseny Maslennikov на комментарий #33) > > 1) Спек dre-ace-tao новый для Sisyphus, но в нём нет: > > %define _unpackaged_files_terminate_build 1 > > Эта директива должна была бы подразумеваться по умолчанию, но мы решили так > > не делать по просьбе вашего ментора, которому пришлось бы мегасрочно чинить > > сотни пакетов — иначе их было бы нельзя обновить или пересобрать. > Нет. Я вообще против и сейчас. Для меня это бесполезная опция, ведущая > только к дополнительному усложнению сопровождения пакетов. > > > В новых же пакетах нет ни одной причины не включать эту директиву. > Нет ни одной причины её включать для меня. Я поддерживаю. Мне в моих пакетах очень удобно видеть в логах список файлов, которые я не упаковал. И это поведение ломается любым удалением неупакованных файлов. Опция была бы полезна только в том случае, когда для неё будет добавлена возможность игнорирования файлов по маске. 252376 39 grenka 2024-10-01 10:39:34 +0300 (Ответ для Anton Farygin на комментарий #38) > (Ответ для Sergey V Turchin на комментарий #36) > > (Ответ для Arseny Maslennikov на комментарий #33) > > > 1) Спек dre-ace-tao новый для Sisyphus, но в нём нет: > > > %define _unpackaged_files_terminate_build 1 > > > Эта директива должна была бы подразумеваться по умолчанию, но мы решили так > > > не делать по просьбе вашего ментора, которому пришлось бы мегасрочно чинить > > > сотни пакетов — иначе их было бы нельзя обновить или пересобрать. > > Нет. Я вообще против и сейчас. Для меня это бесполезная опция, ведущая > > только к дополнительному усложнению сопровождения пакетов. > > > > > В новых же пакетах нет ни одной причины не включать эту директиву. > > Нет ни одной причины её включать для меня. > > Я поддерживаю. > Мне в моих пакетах очень удобно видеть в логах список файлов, которые я не > упаковал. > > И это поведение ломается любым удалением неупакованных файлов. > > Опция была бы полезна только в том случае, когда для неё будет добавлена > возможность игнорирования файлов по маске. Я буквально вчера лично писал Арсению "гневное письмо" по поводу обязаловки использования этого макроса. Не думал, что моя нелюбовь к этому макросу найдёт отклик в сердцах других людей. Я тоже собираю много пакетов и тоже категорически против использования этого макроса, так как он больше мешает, чем помогает. Неупакованные файлы довольно ярко отображаются в логах и нет ничего плохого в том, чтобы лишний раз хотя бы бегло глянуть лог. Мало ли, может бросится в глаза ещё что-то. Плюсую против использования этого макроса. 252402 40 arseny 2024-10-01 15:30:20 +0300 (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?). -- Вообще критики правы в том, что этот макрос, как и многие наши меры автоматизированного поддержания порядка в репозитории, вместо помощи мейнтейнеру устроен как кувалда, бьющая его по голове, что плохо. Но лучше что-то, чем совсем ничего. 252403 41 arseny 2024-10-01 15:32:50 +0300 (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 бинарников, т. е. семантика макроса неважна; — для очень толстых программ и библиотек генерацию отладочного инфо вообще приходится выключать из-за ограниченных ресурсов; поэтому на его применении не настаиваю. 252407 42 rider 2024-10-01 15:49:47 +0300 Да, с тем что ментейнер должен уметь пользоваться данным макросом, когда это нужно - согласен. 252413 43 zerg 2024-10-01 17:07:41 +0300 (Ответ для Arseny Maslennikov на комментарий #41) > у нас здесь joinится кандидат; в контексте его пакетов Вот и не надо было выходить за этот контекст. :-) 252415 44 ratkinda 2024-10-01 19:00:22 +0300 (Ответ для 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 они и правда забыли в спеке Ответы на вопросы и исправления скоро подготовлю 252417 45 arseny 2024-10-01 19:15:37 +0300 (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_*. Меньше вызовов программ, меньше самоповторов в коде, код короче. :) 252643 46 ratkinda 2024-10-07 18:59:11 +0300 (Ответ для 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 252645 47 ratkinda 2024-10-07 19:03:02 +0300 (Ответ для 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 эту > информацию, чем имя пакета, в общем случае. Точно так же: решать вам. Мне удобнее имена пакетов, так что предпочёл бы их оставить 252646 48 ratkinda 2024-10-07 19:04:21 +0300 Для aarch64 пока отключил сборку, попробую разобраться что там 252666 49 arseny 2024-10-07 22:33:57 +0300 (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`, а не что-то иное. 252668 50 arseny 2024-10-07 23:10:52 +0300 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) работу, поэтому я обязан об этом упомянуть. Короче, просто напишите нормально. :) 252669 51 ratkinda 2024-10-07 23:21:59 +0300 > Какой инструмент автора спека способен "spec" превратить... в "speak"? это я руками написал, по-ходу в голове разговор был в этот момент) 252683 52 zerg 2024-10-08 09:43:04 +0300 (Ответ для Arseny Maslennikov на комментарий #50) > Какой инструмент автора спека способен "spec" превратить... в "speak"? Тот же, который у меня периодически превращает rpm в rm, legion в leguin и kernel в kdernel. ;-) 252722 53 ratkinda 2024-10-08 23:18:22 +0300 (Ответ для Arseny Maslennikov на комментарий #49) > > h=d71151c02d2fb4fe67a8a33eba484b55d2e91bca;hb=HEAD#l181 > Очень хорошо. Тогда там стоит оставить коммент, что это `-m64`, а не что-то > иное. Оставил коммент, вернул сборку aarch64, настроек из конфигов должно хватать. Поправил changelog. 252774 54 arseny 2024-10-09 15:12:59 +0300 (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"? > это я руками написал, по-ходу в голове разговор был в этот момент) Ну ничего, бывает. Но про инструменты имейте в виду. Не нужно, чтобы инструменты были умнее мейнтейнера. :) 252775 55 arseny 2024-10-09 15:13:14 +0300 (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) 252896 56 zerg 2024-10-11 15:44:17 +0300 (Ответ для Arseny Maslennikov на комментарий #54) > > у меня периодически превращает rpm в rm, legion в leguin и > > kernel в kdernel. ;-) > Кстати, телефонные автокорректы при написании спека тоже лучше выключать. :) Да, они таких слов не знают. ;-) P.S. Это одна из 1-х настроек, отключаемых мной сразу же на смартфоне. 252897 57 zerg 2024-10-11 15:46:49 +0300 (Ответ для Arseny Maslennikov на комментарий #55) > А зачем сжимать? Чем это лучше следующего: > tar: czkawka Да. rpm сверху сожмёт xz, т.е. будет только хуже. Ещё я, напрмер, постоянно пользуюсь gear-rpm --short-circuit, а со сжатием оно прилично медленнее. 252914 58 ratkinda 2024-10-11 19:09:16 +0300 (Ответ для 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, а в целом не вижу причин не указать авторов, лицензию, и доп информацию 253232 59 ratkinda 2024-10-21 18:48:15 +0300 @arseny вы там не забыли про join)? 253377 60 arseny 2024-10-23 18:40:55 +0300 (In reply to ratkin from comment #59) > @arseny вы там не забыли про join)? Пришлось выпасть из контекста, поэтому чуть не забыл. На этой неделе прокомментирую. Если нет — смело пингуйте :) 253582 61 ratkinda 2024-10-29 12:04:11 +0300 (Ответ для Arseny Maslennikov на комментарий #60) > прокомментирую. Если нет — смело пингуйте :) @arseny ping Ещё немного поменял ace-tao, убрал sed, добавил init скрипты для альта(до этого sed просто менял скрипты федоры под альт). 253586 62 arseny 2024-10-29 13:35:21 +0300 (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:. 253587 63 arseny 2024-10-29 13:38:57 +0300 (In reply to ratkin from comment #61) > (Ответ для Arseny Maslennikov на комментарий #60) > > прокомментирую. Если нет — смело пингуйте :) > @arseny ping > > Ещё немного поменял ace-tao, убрал sed, добавил init скрипты для альта(до > этого sed просто менял скрипты федоры под альт). Здо́рово! 253590 64 arseny 2024-10-29 14:04:42 +0300 (In reply to Arseny Maslennikov from comment #55) > (In reply to ratkin from comment #29) > > пакеты собранные для Join: > Я же пока пойду читать питон (task 344185) К питону вопросов особых нет; разве только в качестве URL пакетов с модулями, наверное, стоит указывать URL проекта на pypi.org. 253597 65 arseny 2024-10-29 16:02:15 +0300 (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 не справляется. 253598 66 arseny 2024-10-29 16:06:36 +0300 С моей точки зрения, кандидат научился собирать пакеты разного рода, не допуская грубых ошибок, с точностью до удобной ему манеры работы над спеком, и продемонстрировал, что понимает, что делает. Думаю, можно переходить на следующую стадию T/J/S. 253843 67 glebfm 2024-11-01 16:45:24 +0300 Пользователь добавлен в группу мейнтейнеров. Желаю удачного мейнтейнерства! 253887 68 zerg 2024-11-02 11:01:09 +0300 Уря! 13881 2023-07-19 14:35:01 +0300 2023-10-31 10:03:25 +0300 ssh public key id_ed25519.pub application/vnd.ms-publisher 93 ratkinda c3NoLWVkMjU1MTkgQUFBQUMzTnphQzFsWkRJMU5URTVBQUFBSUlRWDZwOEFuOEIyMUhiTUJaYmJi aDVQM0pxQWp1c1JWS0hLelJtWXRnVkggZHZAcmF0a2luZGEK 13882 2023-07-19 14:36:13 +0300 2023-08-04 13:48:30 +0300 gpg public key file_46983.txt text/plain 3055 ratkinda bVFJTkJHUzNyc3NCRUFDd0dqSTNSWkc5dDJoTWNwZDc5ajRodmcvV3YzUTJFdWw1Uy9RVG1BcEQz UTAyeWM2VQ0Kc0hvQmNvOUxPd0E0UHhZVGVSNFJHR3lpd010dS9CdUIrWDZycDV4OHhjYm1FeWYz VWVCRVFwSmc5Y0lVYlMyUQ0KbytFZmNXUkszUEM3QVVPQW93MEFxZUZGUXpGdk96OW9PcWQ3YnhG QnRMYXE2bWlUSHdWWnkwaTYzY3NqSm9rMQ0KaUtpTkRJYVlubTJQYXkyUHZndW85a0wzK1hoZ2RE OWRUbGk5aDJxS0RzMzNsbzliSytmQlI2RDJleTdTMHdDZA0KYkw1RHFkMzZsaEQ0dFZ4N0JpTHZF bGs4QmRvUUZHMWtLR2dtY0ZHZlFXbUwrVDBHUmordGp4UGw3R1QvY1FPVw0KMEluZGI0YWNYMk5M bG9XaUdOTHBrQUZDeVRORldZTVR3RjdoeDlVMmk3UWtOQ3U3R3BlOXBobGFIc2Q4bHI0Tg0KZUJm dHJKOXNuaU1oNUl3OTNHMmM4UHBjMUpsNVZWVHFuaExTeDFwcVZJNEdCWVZ2Ry9GMTBHYkhNMXdh TE1QRw0Kb0plRGIzZ09GcE10S3pyOTVmUjhmQUFidVpndjI4TEEzMnBCY05hR3VxZ3ZWY2IrRUx6 WTBpNjRGOWdiTG04Nw0KWWtlVnBBb3R1bGdsQ0dXNEE1QmlWMjFEMWhPdnpBMDJydEkyQWg3aVVs NTFoYWNLeTAyakJRWEFqZUVCUjQzUw0KNTVSL1BTQmp5VkMycStWRzdlL0phckhFSkhKeUpqVmJF dnpjc216aDFuSlZqSjRwWkN1OEdtQ096blhQc25PRA0KQXFqdStqVlliV21NbkplT3NoRUphSmY0 SVBkQUl4QTAyUnNuNzBZS2kwcnRRSFp3dTVRaGpuTkhzUUFSQVFBQg0KdENsRVlXNXBhV3d0Vm1s cmRHOXlJRkpoZEd0cGJpQThhM0ptTVRCQVlXeDBiR2x1ZFhndWIzSm5Qb2tDT0FRVA0KQVFnQUln VUNaTGV1eXdJYkF3WUxDUWdIQXdJR0ZRZ0NDUW9MQkJZQ0F3RUNIZ0VDRjRBQUNna1FQNkVGcDBi Vw0KRnBFS2VnLytQWDBrL0pVQlhiYm9abkF1YkIyTDdqd1hxQ0lmS1A3SW54TGQ5ZXNNYW9DTVBt MENiU0FOcElGYQ0KcEJ5U0hrTEJzSWZncVpPenFkU3ZiSTF0QzVRY2p0K2lxcEFrcU5zclZtYjBC aTV0ekNjSkRESmpiT2xCYlpMWQ0KUTY1WTVkZVdta09jMksyMjJJSGZLNjdWTGR5SjZ4aWJKd0JV Q1RINlB6enF4Y3NiQnNUcXd0SDlnYlVuTTMzeA0KVHlxL29ubVJtRXZGRHVDeXo5dGFjb1NMeXZz K0NaajI1NzdWM2xzKzJKWWdaNUxYaHBKVEkyY0p6M0NYK3ljTQ0KTDhtVmZJMi9YTllyZWE0WW9u VnVDWXFEeFdoWlRyZGNSa1hyYjBvVkx5N0NZd1FqblFEcjVkQXk1dURMYVdjTQ0KVFpKMEpvUkEw Wk11MS9hM2JIOGJzZ2c0Y1d6cFhuWjg2K3J5RE5QQ2hreGptTzZUK1dSZFNjZjA2eXlrQ3FBZw0K cGdaOStYWkUwNEV0QXBKTGlHRDBNcHRuMnRlTmUzRVhqVk44ak81MExjRjY0ODEydWpMbDRscDU2 Q0ViOUFnSg0KbnRqdW9FOE5FOGFFZ2N5dzhmbDI4VkF6VXA4V2pHdlJnaXdzUDJmdnB1NmhsazlW YS84ZE02bjVPVHlmbHA2QQ0KbHVnNUtONlppWGxyUXBJQ0JKL2VOelFxSlpVc0R4TXE0RlFZemZH UVQwR1poS2FuV2NONVBoYzJScjhSRkoyVQ0KSE5sVk10dHFmUWQ2V1ZmNGpNQ0w0ajNqV1M3Tjdw aGY3N3NFbWU3SWVEeXVobDd6SVZLSWxURUUvUEFXa1FvVA0KL1RHNkRyZmpqSklkOEE5MEZ5TFB5 azhNd20rWW1oZjM2bzNwVjErdzcvcStNOUFEbmlDNUFnMEVaTGV1eXdFUQ0KQU5BSnVya0NxWC8v dnNVZ2JvQ2xyLysxSDIrYmptdzhSTDRDY2JxczhFRGNRaHQwcGp5dE5FWW1qRkx0UENEcQ0KR3l2 ajdXMXB5NFh3aTJldzhldjI5UG9qOXo2WG1rMHFmZGxrU3BTcVdTUlJYRU92MjNwM1VjYktGU1Zu Z3E0UA0KaFJaZUdIOU9JK3hENTlUSWRobjQrNkFxa1QyYm1xcDNBNW5tVkNFMElGYkVwN1dqd0dX YmJtekpnT2hXanlIbA0KTnNnYUVkZmcvem1ML2Q0cmIwOUdSRlp2a0oxVjNSVSs4SW1lOWxuOVFl NHQvTUJtbEZ0VStLS09SSXVjOEgvRw0KSGNFMkNHWEZKOHdQUUgxandwc3QyN1d1SWFmeWh0dCs5 MHRYWnc3WENlcktPUDZKaWFRWWlNWjh3dFJUN2cwYw0KOWRjVytHMzdyYk1mdWd4TzBvc3BUU1dl aW5sQTQxckxZKzRNbVZraXRjbURwOVRWMG9kL0h2ZlVoczRFd3J1cA0KYm04MHVzMW80ZEtuUzcr aDNrTHpqQ0NUUGs5QmxIVzlzUFNqaEpuZnBGR2djRm9qd3JSakdESEQ2RUhrYzZtRA0KcEtuelYy dkczSzU1a29mSjdiUGIxRkxxMzN3L1R2TG1CRjRveSsvQ0YzaGxJUXczblR6YmlYVzhrckJUOS9Y eQ0Kc2dkYmluV1Y5a2R1Ulo5TDJHUlhhYzN4WGlGcjlpV0JveG1Kb0IvdGloL1BmbmNVNlQ5eWpy MGw1MVR4MVBGZQ0KNlFxNUhFZGNWblAwVTFSdCsvaE9nMnNTRFVYcU1JUGhJTHdEbWZ0MVJCNGJR VVlJS3RDcTRpRFk5ZnZxVzg2ZQ0KMG0rb0pGZ2tMVUhXUmNiYTBvWEEwb2hiNGUwa1VvUmgvNjhU TEkxM3dTSHhBQkVCQUFHSkFoOEVHQUVJQUFrRg0KQW1TM3Jzc0NHd3dBQ2drUVA2RUZwMGJXRnBH cUpRLy9ZR3BnOUVFWDd3K3h0bzlOMDAvdGtCcWZVenF3WFZmbw0KRjVCYWlUOHIxSXRnK1lvejFh RDExbktvalpNUWYzdHZjVGswVWtwbnZnZ2poUTVjazdVQjBQVnNhU0syM25yZw0KNXRLR2JjOFI0 c0J3bW9xM3BkVDNjZ1FqaW5Ucyt3dUp3U2l4blIzelBLQUIyS0xUaklMT200OEtVUnVlcFpEdg0K TUZsZDhzWlQvV0pFNHh0Y2FXSk5ZekpyRkh4LzdkRmlKdWQwRFFMb1lGNWxtZmZNczdoMkFqVkpK Tm9OcFRVTw0KZUFldllUUHBGcVBLZmR5VXF3U1BrZ2dyOHArMzd1Zi80U3pMcCtrOWRtVHNEc1kw R3g3Q1VNVDF4US9YemlDWg0KVGl1bmJNbjNDWkZtSVhyZkFmNDhmUkJGSlNWTTEvUU1VazljQVJ1 V2tWM1ozc3NjaU9laW5tNW9MSFpnK1JmNA0KYnlUUk9IUjdyOXRVMTVLblU5S0pFcjJSRTZvdG1u Ui9IRmFhdCtEaWZDRFBHeG5Gb1lUSFg4NXFNRnBpTFl4OA0KKzZDcHlQalVaaG94VVhWZ1M4ZjNy bE0xMjEzRGI3cHl0dWluYk1scHFIWXpPTm9qa1R4OXVrRytiRU5DNm9GSQ0KV3pOUm5TVWwvOGtV OHdTdlpKOUNPUWt6RWhYcnZOWm4xb0xxa2VIVWZ6Z0FnTEYrNStGdkhqdmJ1cmtxZlBwLw0KM0pi ZEVsR2ZLRFJOQVRZajJCVFcyZmRqWGg4Q3V1ZDJwK29Icmw2ajBzblVvOGw2a1NockpKZVoxam1j cVo0Ug0KSFZLM0RJd0FZY05LU1FnemY5SmJHd3diS1lXZnNVdUdZZ1FQcXhib21rL1l0WWhVRTY5 SmQrSzY4akJnU0IweA0KQ3czU2JnYXpxQlE9DQo9WVZVeQ== 13981 2023-08-04 13:48:30 +0300 2023-10-31 10:06:09 +0300 gpg public key file_46983.txt text/plain 3133 ratkinda LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tDQoNCm1RSU5CR1MzcnNzQkVBQ3dH akkzUlpHOXQyaE1jcGQ3OWo0aHZnL1d2M1EyRXVsNVMvUVRtQXBEM1EwMnljNlUNCnNIb0JjbzlM T3dBNFB4WVRlUjRSR0d5aXdNdHUvQnVCK1g2cnA1eDh4Y2JtRXlmM1VlQkVRcEpnOWNJVWJTMlEN Cm8rRWZjV1JLM1BDN0FVT0FvdzBBcWVGRlF6RnZPejlvT3FkN2J4RkJ0TGFxNm1pVEh3Vlp5MGk2 M2NzakpvazENCmlLaU5ESWFZbm0yUGF5MlB2Z3VvOWtMMytYaGdkRDlkVGxpOWgycUtEczMzbG85 YksrZkJSNkQyZXk3UzB3Q2QNCmJMNURxZDM2bGhENHRWeDdCaUx2RWxrOEJkb1FGRzFrS0dnbWNG R2ZRV21MK1QwR1JqK3RqeFBsN0dUL2NRT1cNCjBJbmRiNGFjWDJOTGxvV2lHTkxwa0FGQ3lUTkZX WU1Ud0Y3aHg5VTJpN1FrTkN1N0dwZTlwaGxhSHNkOGxyNE4NCmVCZnRySjlzbmlNaDVJdzkzRzJj OFBwYzFKbDVWVlRxbmhMU3gxcHFWSTRHQllWdkcvRjEwR2JITTF3YUxNUEcNCm9KZURiM2dPRnBN dEt6cjk1ZlI4ZkFBYnVaZ3YyOExBMzJwQmNOYUd1cWd2VmNiK0VMelkwaTY0RjlnYkxtODcNCllr ZVZwQW90dWxnbENHVzRBNUJpVjIxRDFoT3Z6QTAycnRJMkFoN2lVbDUxaGFjS3kwMmpCUVhBamVF QlI0M1MNCjU1Ui9QU0JqeVZDMnErVkc3ZS9KYXJIRUpISnlKalZiRXZ6Y3NtemgxbkpWako0cFpD dThHbUNPem5YUHNuT0QNCkFxanUralZZYldtTW5KZU9zaEVKYUpmNElQZEFJeEEwMlJzbjcwWUtp MHJ0UUhad3U1UWhqbk5Ic1FBUkFRQUINCnRDbEVZVzVwYVd3dFZtbHJkRzl5SUZKaGRHdHBiaUE4 YTNKbU1UQkFZV3gwYkdsdWRYZ3ViM0puUG9rQ09BUVQNCkFRZ0FJZ1VDWkxldXl3SWJBd1lMQ1Fn SEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0QUFDZ2tRUDZFRnAwYlcNCkZwRUtlZy8rUFgway9K VUJYYmJvWm5BdWJCMkw3andYcUNJZktQN0lueExkOWVzTWFvQ01QbTBDYlNBTnBJRmENCnBCeVNI a0xCc0lmZ3FaT3pxZFN2YkkxdEM1UWNqdCtpcXBBa3FOc3JWbWIwQmk1dHpDY0pEREpqYk9sQmJa TFkNClE2NVk1ZGVXbWtPYzJLMjIySUhmSzY3VkxkeUo2eGliSndCVUNUSDZQenpxeGNzYkJzVHF3 dEg5Z2JVbk0zM3gNClR5cS9vbm1SbUV2RkR1Q3l6OXRhY29TTHl2cytDWmoyNTc3VjNscysySlln WjVMWGhwSlRJMmNKejNDWCt5Y00NCkw4bVZmSTIvWE5ZcmVhNFlvblZ1Q1lxRHhXaFpUcmRjUmtY cmIwb1ZMeTdDWXdRam5RRHI1ZEF5NXVETGFXY00NClRaSjBKb1JBMFpNdTEvYTNiSDhic2dnNGNX enBYblo4NityeUROUENoa3hqbU82VCtXUmRTY2YwNnl5a0NxQWcNCnBnWjkrWFpFMDRFdEFwSkxp R0QwTXB0bjJ0ZU5lM0VYalZOOGpPNTBMY0Y2NDgxMnVqTGw0bHA1NkNFYjlBZ0oNCm50anVvRThO RThhRWdjeXc4ZmwyOFZBelVwOFdqR3ZSZ2l3c1AyZnZwdTZobGs5VmEvOGRNNm41T1R5ZmxwNkEN Cmx1ZzVLTjZaaVhsclFwSUNCSi9lTnpRcUpaVXNEeE1xNEZRWXpmR1FUMEdaaEthbldjTjVQaGMy UnI4UkZKMlUNCkhObFZNdHRxZlFkNldWZjRqTUNMNGozaldTN043cGhmNzdzRW1lN0llRHl1aGw3 eklWS0lsVEVFL1BBV2tRb1QNCi9URzZEcmZqakpJZDhBOTBGeUxQeWs4TXdtK1ltaGYzNm8zcFYx K3c3L3ErTTlBRG5pQzVBZzBFWkxldXl3RVENCkFOQUp1cmtDcVgvL3ZzVWdib0Nsci8rMUgyK2Jq bXc4Ukw0Q2NicXM4RURjUWh0MHBqeXRORVltakZMdFBDRHENCkd5dmo3VzFweTRYd2kyZXc4ZXYy OVBvajl6NlhtazBxZmRsa1NwU3FXU1JSWEVPdjIzcDNVY2JLRlNWbmdxNFANCmhSWmVHSDlPSSt4 RDU5VElkaG40KzZBcWtUMmJtcXAzQTVubVZDRTBJRmJFcDdXandHV2JibXpKZ09oV2p5SGwNCk5z Z2FFZGZnL3ptTC9kNHJiMDlHUkZadmtKMVYzUlUrOEltZTlsbjlRZTR0L01CbWxGdFUrS0tPUkl1 YzhIL0cNCkhjRTJDR1hGSjh3UFFIMWp3cHN0MjdXdUlhZnlodHQrOTB0WFp3N1hDZXJLT1A2Smlh UVlpTVo4d3RSVDdnMGMNCjlkY1crRzM3cmJNZnVneE8wb3NwVFNXZWlubEE0MXJMWSs0TW1Wa2l0 Y21EcDlUVjBvZC9IdmZVaHM0RXdydXANCmJtODB1czFvNGRLblM3K2gza0x6akNDVFBrOUJsSFc5 c1BTamhKbmZwRkdnY0ZvandyUmpHREhENkVIa2M2bUQNCnBLbnpWMnZHM0s1NWtvZko3YlBiMUZM cTMzdy9UdkxtQkY0b3krL0NGM2hsSVF3M25UemJpWFc4a3JCVDkvWHkNCnNnZGJpbldWOWtkdVJa OUwyR1JYYWMzeFhpRnI5aVdCb3htSm9CL3RpaC9QZm5jVTZUOXlqcjBsNTFUeDFQRmUNCjZRcTVI RWRjVm5QMFUxUnQrL2hPZzJzU0RVWHFNSVBoSUx3RG1mdDFSQjRiUVVZSUt0Q3E0aURZOWZ2cVc4 NmUNCjBtK29KRmdrTFVIV1JjYmEwb1hBMG9oYjRlMGtVb1JoLzY4VExJMTN3U0h4QUJFQkFBR0pB aDhFR0FFSUFBa0YNCkFtUzNyc3NDR3d3QUNna1FQNkVGcDBiV0ZwR3FKUS8vWUdwZzlFRVg3dyt4 dG85TjAwL3RrQnFmVXpxd1hWZm8NCkY1QmFpVDhyMUl0ZytZb3oxYUQxMW5Lb2paTVFmM3R2Y1Rr MFVrcG52Z2dqaFE1Y2s3VUIwUFZzYVNLMjNucmcNCjV0S0diYzhSNHNCd21vcTNwZFQzY2dRamlu VHMrd3VKd1NpeG5SM3pQS0FCMktMVGpJTE9tNDhLVVJ1ZXBaRHYNCk1GbGQ4c1pUL1dKRTR4dGNh V0pOWXpKckZIeC83ZEZpSnVkMERRTG9ZRjVsbWZmTXM3aDJBalZKSk5vTnBUVU8NCmVBZXZZVFBw RnFQS2ZkeVVxd1NQa2dncjhwKzM3dWYvNFN6THArazlkbVRzRHNZMEd4N0NVTVQxeFEvWHppQ1oN ClRpdW5iTW4zQ1pGbUlYcmZBZjQ4ZlJCRkpTVk0xL1FNVWs5Y0FSdVdrVjNaM3NzY2lPZWlubTVv TEhaZytSZjQNCmJ5VFJPSFI3cjl0VTE1S25VOUtKRXIyUkU2b3RtblIvSEZhYXQrRGlmQ0RQR3hu Rm9ZVEhYODVxTUZwaUxZeDgNCis2Q3B5UGpVWmhveFVYVmdTOGYzcmxNMTIxM0RiN3B5dHVpbmJN bHBxSFl6T05vamtUeDl1a0crYkVOQzZvRkkNCld6TlJuU1VsLzhrVTh3U3ZaSjlDT1FrekVoWHJ2 TlpuMW9McWtlSFVmemdBZ0xGKzUrRnZIanZidXJrcWZQcC8NCjNKYmRFbEdmS0RSTkFUWWoyQlRX MmZkalhoOEN1dWQycCtvSHJsNmowc25VbzhsNmtTaHJKSmVaMWptY3FaNFINCkhWSzNESXdBWWNO S1NRZ3pmOUpiR3d3YktZV2ZzVXVHWWdRUHF4Ym9tay9ZdFloVUU2OUpkK0s2OGpCZ1NCMHgNCkN3 M1NiZ2F6cUJRPQ0KPVlWVXkNCi0tLS0tRU5EIFBHUCBQVUJMSUMgS0VZIEJMT0NLLS0tLS0NCg== 14935 2023-10-31 10:03:25 +0300 2023-10-31 10:03:25 +0300 new ssh public key id_ed25519.pub application/vnd.ms-publisher 90 ratkinda c3NoLWVkMjU1MTkgQUFBQUMzTnphQzFsWkRJMU5URTVBQUFBSUVhcllnY3lldzZCZjlGS09KV1Iw S3FQbG1IVlBwTE11U3FreU1iNUhnaE0gZHZAa3JmMTAK 14936 2023-10-31 10:06:09 +0300 2023-10-31 10:06:09 +0300 new gpg public key file_46983.txt text/plain 3131 ratkinda LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tDQoNCm1RSU5CR1ZBcENJQkVBREhJ TkR4RHVySjgvUUFTck5KU280bVh3cUpsT2xsS0JzWDhraTVSdEl4VS9KcWxvK3QNCnNwQXFPcUl6 aHRaQW9hVms3L0xXT1ZQeVJ6NE9LaTNqQ3UycDhUZFp2WDNlWEFvdE9ZakxSMi81Tk9qRFlXMVcN CkZJbXdXYmZzTzUzcEZMVE42RXlpTjVUQzdrT3VoalBHbkVQckRyNGRSd3k1VXI3Z2h0aHowM2pX K05sbkdxYmYNCnJZUkNPMUxVVjBrWDRoenBoN0F1TFVld1ErRnZXODVXYS95TGl1Z1ZsU1FZS0lJ bGt4dGVXUnVsbnNGNXJaU3QNCjB6dXc0YzlpaFZ4M0hCQVl1RE11eUdlQXQ5ekdhSzJkYzBnUEtV YXpyLzAxcDl4R3Y5NllSSFFhaFltYnNSdDkNCnZiUTh5ak95MW5Ucys5ZkpMcExkMlMrMEZiZDkx S1RwQ1BDY1JlV2VFVXMrK1BLbnpkN3UvTld0RWdjM3hBcDENCnFYVi8zcHhyZTZKQXNFRXp3S2pj YnJBWmovYnhCM2FFVFgvOXpRMzdEYUVoRm81TGJzUy9XUWR0M2xYZGQzd2UNCkNoenczNnE5R1Fk ZUE5eG0vTFBXZjAxQmtOb1FRRGp4MWFhQzhmZTAxV0NIdDkyVC9qemtTQ0RWTTJEK3FNVkwNCmVN VFRCS3JVTG9yZmwyS244K2pjUTdiMFlSQ1NUN0dWTVhmY1BQS041SndlaEVUNW10K0E1S25LVlho VGkwSlQNCmVGMi9YN1NwdlRPQjBDRStjNGZVVjkwRjR2K01zakZXVFB4RCtUMUdsVUJVbzRyS1d1 N3I0bkxWaEM4b2xtVDYNCk1wc0xWNE9NY2dKUGpXM3pBWGcycDFUSytzS2NkSzJyb0wrOG9rVWRZ ejVjUGdYc0RrdVQzaVJUdHdBUkFRQUINCnRDbEVZVzVwYVd3dFZtbHJkRzl5SUZKaGRHdHBiaUE4 YTNKbU1UQkFZV3gwYkdsdWRYZ3ViM0puUG9rQ09BUVQNCkFRZ0FJZ1VDWlVDa0lnSWJBd1lMQ1Fn SEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0QUFDZ2tRREtGOUpuOUQNClZPU25mUS84RHlaeXNE VlVESlAwZ3BrazI3U1J0NkRWMlJqc2ZPaHBNaUp4Yis3b0dTNWpSc2ZjTVhrenZpajYNCis5eFVP eXRSSHhGWDloN01WOVo0UU43TGd6Wmc5UzhrWVlIeWdpUDVJUnc3RkFPS1liNEgxaFhIQjE5b0h1 dU0NCnRHVCtVK3A5SWpERFNERWQ3Q2Y4RkRLMzczTlRZaXpMdHJkeWNLUzVZY2VUOWlRdDYydytM T0p3aG92VmdRQWUNClZ5UTUxVi9tSUdNME9oZENpendISVBkTDNDVEw2R0RaV3Z4akQ2MmM1TTlQ STdGVGFEREUyc2ZiZmxyODZLVXINCmt3RjZzN1loRTZxRzMwV0VqdmRoNGZKZzcybkg2YmJ2S2NO OGtmNm95TmlBN3NWKy84MXYzcEVtT0drS3FUOG4NCkRxK1JEUVVPbi9vdGZiamp3cTcrM1QxWGxi WDkvSzJyTUp6WEZFRlE4V0hYbnk1eTdjNWFGVTVUTGZRK1pIeEUNCk1uaFFIOWtsZ3MweWNWcTZi ZVZnZCtXZDZIUC9jeHJpbm5pRlA5a1JmK0hacktpRUlTOFZ4Y3BNTFVKQkZ1Z3gNCkphRFBaaFNI OVdRa2t5MUEySzFYSTdVTkp0aVZKZldWVjc4bGlvZ1kwY0JYNjZQYWg3L25oY3BVb0lkaUJldlAN ClAvdnU2WWtwNkRpcXhGekIrYlZjM1phdG9nTUhyeWtjL0tkb0F5NmpqS1JsVjZ2Tnh0eVQvVUIx ZWR5TGpPbHANCi9oaGxIOXlUZmM1aWlUN2REQjZJaWdLV3hFRzVpOC9jcnE1L0U2Y2xLV3lNS2w3 WWErTXlMc1Q1elo4dng3NnoNCjBLZ3YralhXQWgrY0oyNURsdlBaMlZRZTh5d2sxdXBJdGhHZWxm ZkFFNHhxOEhIZTU0TzVBZzBFWlVDa0lnRVENCkFQRUNPdnJBdmtxdnB1RzJ6ckNYbDFFYnA2cFFM bUwyQ1pYRkkwdXdQajMzb0FKOEwvUS9TUXJqVm13YUNKWnUNCjNGc2RqaUxFN2VxZ1Bxa09qUTk1 cTBobXZobEZpcDJuZFIzbVpkZndjbEl6NEw1N1pDbXhvQis2Y3N1dEpzdncNCk02UzQrRVllZWp6 ZW5NSzR4RzR4VUN0WVJEeVhFYXYvSXF4WTVrUUlYMDFxWXpHRlVWNm8xTmEwblJkK1REWDcNClBP VnpFcG9sa3c5cFR1K0xRNm5xOTVLS0VPQlkzR1pxUDkrbmdIbEdVZmFUSFR5YUJGNWtnZGRCZkZj SEVNTUYNCkViMFdNbWludEJuYjFqc2RPYTlhUzltRUJqUXJ0WkRJM1JDaUJaOEw3VnRZUGVKdThC NndUcEg0QVBPbWlIWVgNClI0S3k4QnZvZWdSaDlTb2tGMi9obFN6cExiMExhclhWdWlXL3EzTDB2 djhxVmozVkFkQlZyelg4OFNoT2hjZUoNCjQxM0xhcFFtRUx3N0kyZTBRaTVBZkF0TlN0TXV0WjNt RzhjQjd2cWhkRk1BMWVUcEFadWh1Mlg4a1pud2NPeWcNCkY3bDRzK0tadkxsd2FCSTZhYzljQ1h2 eHlYWDFKY0xTbjg0WTh4OEV4V0tpZEYvUmR0d29pQlowdE8wS05ZSlYNCkN0QnBETDVzN2ZRZ2g2 UjhHRmJYQ2VTSitRYWx4ampoeW13dWtJVlJ0NExJcE9uMzJCb1orbGwzbVFYNXlJMysNCkE4ajlU bjdNWlNwVkxCVHc2MEJVbU05VStIaC9jRWhGdTdDbEhYeFYwdTg2VGdoaDhXWTFkdE9HWnNJMy8x WmINCkRGbFp0YzhnQzkrMFRVUkFZWE0zbnVUaWdTL0Uwa0hnZmZoc1ppR2tkdzVWQUJFQkFBR0pB aDhFR0FFSUFBa0YNCkFtVkFwQ0lDR3d3QUNna1FES0Y5Sm45RFZPU0lqUS8rS2ZyODBoN1A3STdn ekpaZkhaWkVhdlpVOUxxQUZRNTUNCkpCQlI4OW1INWFFZEwzMU4zMkY5L3N6aG1US0FOZ2E0TzdB S01iNDNiNE5OU2tmdTVuNThObVBqQjQ3bEp5QmsNCitHVTdLU3lGc3cxdWtLK3Y2aGo4TDIyQXRt d0xEQTVIUE1HY1E4UkdiTFNWdW9jM0xicjQ3V0ZBWUsrQzhqZ3ENCm5GQ3UrT2xrK0hHN2svTHBD ZDh3RjhFTjZjNmZmWHZnbHJSZFVqazh3Z3R1aTVCZ3puMjdja0Rnajc5L05DR3cNCmN3cTUrUUU0 cUMrZkNaZmwzTEdRa2FVTHptZWszSElJSGVlRHJwUnRSQWRLTXlNN2VoS1RYRXYwNVhldGk3MzgN ClNrcFVRT2FHR2ZDSFBYZFRsU0RVOTE4OWV1aVB3VlNRWExvRysrK05EajVHZDZiNDlkRlZJWDI3 RGl4cGZrYk8NCm1JY2FNTXdGWXdQVklvOVFSVTVzSHNaL0d2ZEJpSzM5REtFZEJGTGwrVWN0RXVI clAwNzBHSWRwUkY3NkpkYk0NClB0bGc1MEJCTVpwRSttblZYaDNhVUtNbkx3WmxqRnNSN0srZEVV Q3IzalF6WmhWdEVWMW9hNkxHeHh3RCtMcVQNCnc2OS9TaiswaTRSRm9YWmhYRkcraFZ6eExsbWxO V0dmbUxKdW1xU3o5YWZuTVdmeVo3TUtFTEpaQmFzQ0tlbEYNCkFyempoU1dNVUVBalNYWHRrZWxB SDRyckNKdGt3aUVWejdWazFDQUM1UmlMS3JmOHNwZWlVOU15aHZMa3FScVkNClJ1UithL0hGSHZU QlhySlJ3U2o3TzhiS3JlMUJwM1hib01GcDY1dm5JRFZMTzdUNEp5MENBeDBlRy9wN3hLbzcNCjhV UFQyeUI2YXhRPQ0KPTc4WjcNCi0tLS0tRU5EIFBHUCBQVUJMSUMgS0VZIEJMT0NLLS0tLS0=