[devel] Массовая, вероломная и необоснованная кража пакетов

[devel] Массовая, вероломная и необоснованная кража пакетов

[Anton Zhukharev]

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

Вчера вечером участник сообщества grenka совершил массовое изменение ACL
пакетов, используемых с rpm-build-pyproject. Пока большинство
сопровождающих не работало, он удалил исходные пакеты, пересобрал их без
rpm-build-pyproject и в результате сделал себя единственным лидером ACL.

Под удар попало примерно для 240 пакетов.

Пострадали преимущественно сопровождающие из Обнинска — по всей
видимости, из-за личной неприязни. Такое поведение недопустимо ни в
ALT Linux Team, ни в любом другом сообществе.

Мое требование (и, думаю, не только мое) - заблокировать учётную запись
grenka (в идеале — исключить из команды и полностью удалить его учетную
запись, освободив все им занятые пакеты) за нетерпимость и фактическую
кражу интеллектуального труда;

Также прошу:
- вернуть ACL пакетов их прежним владельцам;
- откатить изменения и удалить следы этих действий из %changelog;
- добавить в girar защиту от удаления пакета без явного разрешения
  лидера ACL, даже если установлено @everybody;
- начать активное обсуждение модернизации системы ACL.

Если меры не будут приняты в ближайшее время, я вынужден буду блокировать
задачи grenka в Sisyphus и других репозиториях, поскольку у него не было
основания массово блокировать работу других мейнтейнеров.

Прошу администрацию girar отнестить к этому с пониманием.

Знаю, что grenka попытается оправдаться, назвав эту схему сборки
"вирусной" или "непопулярной". Но политики на способ сборки
Python-пакетов у нас нет, а автоматизация на основе PEP-стандартов
удобна и используется не одним человеком. Личные предпочтения не должны
вести к саботажу чужой работы - и напомню, что с его пакетами так никто
не поступал специально и уже тем более массово (единичные случае были,
согласен, но это не дает право ему красть массово для себя чужие
пакеты; лидерство в сборке python3 так же не дает право этого делать и
считать себя диктаторов в экосистеме в репозитории и творить что только
в голову взбредет).

-- 
Anton Zhukharev
ALT Linux Team

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

[devel] Re: Массовая, вероломная и необоснованная кража пакетов

[Sergey V Turchin]

On Monday, 30 March 2026 10:13:46 MSK Anton Zhukharev wrote:
> Вчера вечером участник сообщества grenka совершил массовое изменение ACL
> пакетов, используемых с rpm-build-pyproject. Пока большинство
> сопровождающих не работало, он удалил исходные пакеты, пересобрал их без
> rpm-build-pyproject и в результате сделал себя единственным лидером ACL.
> 
> Под удар попало примерно для 240 пакетов.
Кто-нибудь или что-нибудь может дать этому объяснение кроме весеннего 
обострения?

[...]

-- 
Regards, Sergey.

Re: [devel] Массовая, вероломная и необоснованная кража пакетов

[Anton Farygin]

Поддерживаю, как пострадавший - если данная ситуация не будет 
исправлена, то нас ждёт паралелльная сборка ещё одной экосистемы питона 
в Sisyphus. Такое поведение недопустимо.

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


On 3/30/26 10:13, Anton Zhukharev wrote:
> Вчера вечером участник сообщества grenka совершил массовое изменение ACL
> пакетов, используемых с rpm-build-pyproject. Пока большинство
> сопровождающих не работало, он удалил исходные пакеты, пересобрал их без
> rpm-build-pyproject и в результате сделал себя единственным лидером ACL.
>
> Под удар попало примерно для 240 пакетов.
>
> Пострадали преимущественно сопровождающие из Обнинска — по всей
> видимости, из-за личной неприязни. Такое поведение недопустимо ни в
> ALT Linux Team, ни в любом другом сообществе.
>
> Мое требование (и, думаю, не только мое) - заблокировать учётную запись
> grenka (в идеале — исключить из команды и полностью удалить его учетную
> запись, освободив все им занятые пакеты) за нетерпимость и фактическую
> кражу интеллектуального труда;
>
> Также прошу:
> - вернуть ACL пакетов их прежним владельцам;
> - откатить изменения и удалить следы этих действий из %changelog;
> - добавить в girar защиту от удаления пакета без явного разрешения
>    лидера ACL, даже если установлено @everybody;
> - начать активное обсуждение модернизации системы ACL.
>
> Если меры не будут приняты в ближайшее время, я вынужден буду блокировать
> задачи grenka в Sisyphus и других репозиториях, поскольку у него не было
> основания массово блокировать работу других мейнтейнеров.
>
> Прошу администрацию girar отнестить к этому с пониманием.
>
> Знаю, что grenka попытается оправдаться, назвав эту схему сборки
> "вирусной" или "непопулярной". Но политики на способ сборки
> Python-пакетов у нас нет, а автоматизация на основе PEP-стандартов
> удобна и используется не одним человеком. Личные предпочтения не должны
> вести к саботажу чужой работы - и напомню, что с его пакетами так никто
> не поступал специально и уже тем более массово (единичные случае были,
> согласен, но это не дает право ему красть массово для себя чужие
> пакеты; лидерство в сборке python3 так же не дает право этого делать и
> считать себя диктаторов в экосистеме в репозитории и творить что только
> в голову взбредет).
>
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Массовая, вероломная и необоснованная кража пакетов

[Stanislav Levin]

[-- Attachment #1.1: Type: text/plain, Size: 2072 bytes --]



On 3/30/26 10:13 AM, Anton Zhukharev wrote:
> Вчера вечером участник сообщества grenka совершил массовое изменение ACL
> пакетов, используемых с rpm-build-pyproject. Пока большинство
> сопровождающих не работало, он удалил исходные пакеты, пересобрал их без
> rpm-build-pyproject и в результате сделал себя единственным лидером ACL.
> 
> Под удар попало примерно для 240 пакетов.
> 
> Пострадали преимущественно сопровождающие из Обнинска — по всей
> видимости, из-за личной неприязни. Такое поведение недопустимо ни в
> ALT Linux Team, ни в любом другом сообществе.
> 
> Мое требование (и, думаю, не только мое) - заблокировать учётную запись
> grenka (в идеале — исключить из команды и полностью удалить его учетную
> запись, освободив все им занятые пакеты) за нетерпимость и фактическую
> кражу интеллектуального труда;

Выражаю сожаление, что глубокая необоснованная личная неприязнь grenka 
ко мне выразилась в совершенно не необходимом спаме в changelog 
(пользователям крайне необходимо знать об эмоциональном состоянии 
собирающего пакет, да?), массовом закрытии acl, блокировке работы и 
подтверждения факта, что не все хотят или готовы работать в сообществе.

Я прошу за это прощение.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [devel] Массовая, вероломная и необоснованная кража пакетов

[Alexandr Shashkin]

[-- Attachment #1.1.1: Type: text/plain, Size: 3022 bytes --]

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

Лично я никогда не крал его пакетов и не исправлял их без его
разрешения. Но в итоге также попал под раздачу. И если бы большая часть
моих пакетов не была с закрытым ACL, то потерял бы их все.

On 30/03/2026 11:11, Stanislav Levin wrote:
>
>
> On 3/30/26 10:13 AM, Anton Zhukharev wrote:
>> Вчера вечером участник сообщества grenka совершил массовое изменение ACL
>> пакетов, используемых с rpm-build-pyproject. Пока большинство
>> сопровождающих не работало, он удалил исходные пакеты, пересобрал их без
>> rpm-build-pyproject и в результате сделал себя единственным лидером ACL.
>>
>> Под удар попало примерно для 240 пакетов.
>>
>> Пострадали преимущественно сопровождающие из Обнинска — по всей
>> видимости, из-за личной неприязни. Такое поведение недопустимо ни в
>> ALT Linux Team, ни в любом другом сообществе.
>>
>> Мое требование (и, думаю, не только мое) - заблокировать учётную запись
>> grenka (в идеале — исключить из команды и полностью удалить его учетную
>> запись, освободив все им занятые пакеты) за нетерпимость и фактическую
>> кражу интеллектуального труда;
>
> Выражаю сожаление, что глубокая необоснованная личная неприязнь grenka 
> ко мне выразилась в совершенно не необходимом спаме в changelog 
> (пользователям крайне необходимо знать об эмоциональном состоянии 
> собирающего пакет, да?), массовом закрытии acl, блокировке работы и 
> подтверждения факта, что не все хотят или готовы работать в сообществе.
>
> Я прошу за это прощение.
>
>
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

-- 
Best regards,
Alexandr Shashkin
Alt Linux Team



[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 5487 bytes --]

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

Re: [devel] Массовая, вероломная и необоснованная кража пакетов

[Alexandr Shashkin]

[-- Attachment #1.1.1: Type: text/plain, Size: 5506 bytes --]

Также выскажусь как пострадавший.

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

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

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

On 30/03/2026 10:13, Anton Zhukharev wrote:
> Вчера вечером участник сообщества grenka совершил массовое изменение ACL
> пакетов, используемых с rpm-build-pyproject. Пока большинство
> сопровождающих не работало, он удалил исходные пакеты, пересобрал их без
> rpm-build-pyproject и в результате сделал себя единственным лидером ACL.
>
> Под удар попало примерно для 240 пакетов.
>
> Пострадали преимущественно сопровождающие из Обнинска — по всей
> видимости, из-за личной неприязни. Такое поведение недопустимо ни в
> ALT Linux Team, ни в любом другом сообществе.
>
> Мое требование (и, думаю, не только мое) - заблокировать учётную запись
> grenka (в идеале — исключить из команды и полностью удалить его учетную
> запись, освободив все им занятые пакеты) за нетерпимость и фактическую
> кражу интеллектуального труда;
>
> Также прошу:
> - вернуть ACL пакетов их прежним владельцам;
> - откатить изменения и удалить следы этих действий из %changelog;
> - добавить в girar защиту от удаления пакета без явного разрешения
>    лидера ACL, даже если установлено @everybody;
> - начать активное обсуждение модернизации системы ACL.
>
> Если меры не будут приняты в ближайшее время, я вынужден буду блокировать
> задачи grenka в Sisyphus и других репозиториях, поскольку у него не было
> основания массово блокировать работу других мейнтейнеров.
>
> Прошу администрацию girar отнестить к этому с пониманием.
>
> Знаю, что grenka попытается оправдаться, назвав эту схему сборки
> "вирусной" или "непопулярной". Но политики на способ сборки
> Python-пакетов у нас нет, а автоматизация на основе PEP-стандартов
> удобна и используется не одним человеком. Личные предпочтения не должны
> вести к саботажу чужой работы - и напомню, что с его пакетами так никто
> не поступал специально и уже тем более массово (единичные случае были,
> согласен, но это не дает право ему красть массово для себя чужие
> пакеты; лидерство в сборке python3 так же не дает право этого делать и
> считать себя диктаторов в экосистеме в репозитории и творить что только
> в голову взбредет).
>
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

-- 
Best regards,
Alexandr Shashkin
Alt Linux Team



[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 5487 bytes --]

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

[devel] Всем закрывать ACL (was: Массовая, вероломная и необоснованная кража пакетов)

[Sergey V Turchin]

On Monday, 30 March 2026 11:18:35 MSK Alexandr Shashkin wrote:

[...]
> Надеюсь администраторы обратят на это внимание и примут меры, потому
> что это создаёт опасный прецедент с "угоном" пакетов. Если ничего не
> изменится, есть риск что участники начнут закрывать ACL пакетов и
> замыкаться на своих "островках", вместо того чтобы договариваться.
К сожалению, я уже давно хожу по этим граблям, поэтому могу только 
посоветовать всем закрывать ACL при первой же возможности, т.к. варианта 
договориться может не возникнуть или просто обсуждение по тихому сдохнет в 
этом списке, как, например, https://lore.altlinux.org/devel/
4485721.ejJDZkT8p0@zerg.malta.altlinux.ru/ .

[...]

-- 
Regards, Sergey.

Re: [devel] Массовая, вероломная и необоснованная кража пакетов

[Anton Zhukharev]

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

On Mon, Mar 30, 2026 at 10:13:46AM +0300, Anton Zhukharev wrote:
> Вчера вечером участник сообщества grenka совершил массовое изменение ACL
> пакетов, используемых с rpm-build-pyproject. Пока большинство
> сопровождающих не работало, он удалил исходные пакеты, пересобрал их без
> rpm-build-pyproject и в результате сделал себя единственным лидером ACL.
> 
> Под удар попало примерно для 240 пакетов.

Приблизительный список пострадавших пакетов:

389-ds-base
conan
python3-module-a2wsgi
python3-module-abi3info
python3-module-aioapcaccess
python3-module-aiodhcpwatcher
python3-module-aioesphomeapi
python3-module-aiohasupervisor
python3-module-aioresponses
python3-module-aiozoneinfo
python3-module-ajsonrpc
python3-module-amqp
python3-module-aria2p
python3-module-astral
python3-module-async-upnp-client
python3-module-asyncinotify
python3-module-automat
python3-module-babi-grammars
python3-module-beautifulsoup4
python3-module-beniget
python3-module-bidict
python3-module-black
python3-module-bleak-retry-connector
python3-module-blinker
python3-module-bluetooth-adapters
python3-module-bluetooth-sensor-state-data
python3-module-boolean.py
python3-module-boto3
python3-module-brotlicffi
python3-module-build
python3-module-casttube
python3-module-certifi
python3-module-chacha20poly1305-reuseable
python3-module-changelog-chug
python3-module-ciso8601
python3-module-cpuinfo
python3-module-cron-converter
python3-module-cssselect
python3-module-dbus-fast
python3-module-detect-test-pollution
python3-module-devpi-client
python3-module-devpi-common
python3-module-devpi-server
python3-module-dill
python3-module-dj-database-url
python3-module-django-ckeditor
python3-module-django-ckeditor-5
python3-module-django-environ
python3-module-djangorestframework
python3-module-dkimpy
python3-module-docutils
python3-module-editables
python3-module-emoji
python3-module-enrich
python3-module-events
python3-module-expandvars
python3-module-factory_boy
python3-module-fastcore
python3-module-faststream
python3-module-file-read-backwards
python3-module-filedepot
python3-module-filelock
python3-module-flask-compress
python3-module-flask-cors
python3-module-flask-restx
python3-module-flask-socketio
python3-module-flit
python3-module-fnvhash
python3-module-freezegun
python3-module-geomag
python3-module-gettext
python3-module-git-pandas
python3-module-graphviz
python3-module-habluetooth
python3-module-harfile
python3-module-hatasmota
python3-module-hiredis
python3-module-home-assistant-bluetooth
python3-module-httptools
python3-module-huawei-lte-api
python3-module-hypothesis-graphql
python3-module-hypothesis-openapi
python3-module-icontract
python3-module-ini2toml
python3-module-installer
python3-module-jaraco-env
python3-module-jaraco-vcs
python3-module-jaraco.classes
python3-module-jaraco.itertools
python3-module-jinja2
python3-module-jq
python3-module-jsonpath-ng
python3-module-jsonrpc-async
python3-module-jsonschema-specifications
python3-module-jwcrypto
python3-module-kdcproxy
python3-module-krb5
python3-module-lark
python3-module-lazy
python3-module-lazy-object-proxy
python3-module-lesscpy
python3-module-libarchive-c
python3-module-libcng_dpapi
python3-module-linkify-it-py
python3-module-loky
python3-module-lru-dict
python3-module-magic-filter
python3-module-marshmallow
python3-module-mashumaro
python3-module-model-bakery
python3-module-more-itertools
python3-module-msal-extensions
python3-module-mypy
python3-module-ncclient
python3-module-netius
python3-module-onigurumacffi
python3-module-onvif-zeep-async
python3-module-outcome
python3-module-packaging
python3-module-paramiko
python3-module-path
python3-module-pathlib2
python3-module-pkg-resources
python3-module-pkginfo
python3-module-pluggy
python3-module-poethepoet
python3-module-portalocker
python3-module-posting
python3-module-propcache
python3-module-proxy-py
python3-module-pyasn1-modules
python3-module-pydocstyle
python3-module-pyga
python3-module-pygls
python3-module-pykodi
python3-module-pylint
python3-module-pymetno
python3-module-pymicro-vad
python3-module-pyparsing
python3-module-pyproject-fmt
python3-module-pyscreenshot
python3-module-pytest-asyncio
python3-module-pytest-benchmark
python3-module-pytest-cov
python3-module-pytest-env
python3-module-pytest-httpbin
python3-module-pytest-ignore-flaky
python3-module-pytest-mock
python3-module-pytest-sugar
python3-module-pytest-testinfra
python3-module-pytest-textual-snapshot
python3-module-python-engineio
python3-module-python-socketio
python3-module-python_utils
python3-module-pytokens
python3-module-pytz
python3-module-quart
python3-module-questionary
python3-module-railroad-diagrams
python3-module-random2
python3-module-redis-py
python3-module-reedsolo
python3-module-remote-pdb
python3-module-requests-file
python3-module-rfc3986
python3-module-rich
python3-module-rich-click
python3-module-rjsmin
python3-module-selenium
python3-module-semantic_version
python3-module-send2trash
python3-module-sh
python3-module-silx
python3-module-sounddevice
python3-module-specfile
python3-module-sphinxcontrib-htmlhelp
python3-module-sphinxext-opengraph
python3-module-sqlalchemy
python3-module-stringcase
python3-module-tabulate
python3-module-tarjan
python3-module-tblib
python3-module-telegram-bot
python3-module-tempora
python3-module-termcolor
python3-module-text-unidecode
python3-module-threadpoolctl
python3-module-time-machine
python3-module-tiny-proxy
python3-module-toml
python3-module-toml-fmt-common
python3-module-tomli
python3-module-tox
python3-module-tox-passenv
python3-module-tox-uv
python3-module-tox-uv-bare
python3-module-tpm2-pytss
python3-module-translationstring
python3-module-treelib
python3-module-trove-classifiers
python3-module-tuya-sharing
python3-module-typing-inspect
python3-module-ufmt
python3-module-unicode-rbnf
python3-module-url-normalize
python3-module-usort
python3-module-uv
python3-module-validators
python3-module-virtualenv
python3-module-voluptuous
python3-module-wakeonlan
python3-module-watchdog
python3-module-websockets
python3-module-webtest
python3-module-wsdiscovery
python3-module-xdot
python3-module-xiaomi-gateway
python3-module-youtube-transcript-api
python3-module-zconfig
python3-module-zeroconf
python3-module-zipp
python3-module-zope-pagetemplate
python3-module-zope.annotation
python3-module-zope.authentication
python3-module-zope.browser
python3-module-zope.contenttype
python3-module-zope.datetime
python3-module-zope.deferredimport
python3-module-zope.deprecation
python3-module-zope.dottedname
python3-module-zope.dublincore
python3-module-zope.exceptions
python3-module-zope.hookable
python3-module-zope.i18nmessageid
python3-module-zope.lifecycleevent
python3-module-zope.sendmail
python3-module-zope.testing
python3-module-zope.testrunner
socli

-- 
Anton Zhukharev
ALT Linux Team

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

Re: [devel] Массовая, вероломная и необоснованная кража пакетов

[Evgeniy Martynenko]

Коллеги, поддерживаю негодование Антона.

Как человек, который только вступает в команду ALT Linux Team, я с 
тревогой наблюдаю за произошедшим. Такое токсичное поведение не только 
нарушает принципы взаимного уважения, но и напрямую вредит репутации 
сообщества.

On 3/30/26 10:13, Anton Zhukharev wrote:
> Вчера вечером участник сообщества grenka совершил массовое изменение ACL
> пакетов, используемых с rpm-build-pyproject. Пока большинство
> сопровождающих не работало, он удалил исходные пакеты, пересобрал их без
> rpm-build-pyproject и в результате сделал себя единственным лидером ACL.
>
> Под удар попало примерно для 240 пакетов.
>
> Пострадали преимущественно сопровождающие из Обнинска — по всей
> видимости, из-за личной неприязни. Такое поведение недопустимо ни в
> ALT Linux Team, ни в любом другом сообществе.
>
> Мое требование (и, думаю, не только мое) - заблокировать учётную запись
> grenka (в идеале — исключить из команды и полностью удалить его учетную
> запись, освободив все им занятые пакеты) за нетерпимость и фактическую
> кражу интеллектуального труда;
>
> Также прошу:
> - вернуть ACL пакетов их прежним владельцам;
> - откатить изменения и удалить следы этих действий из %changelog;
> - добавить в girar защиту от удаления пакета без явного разрешения
>    лидера ACL, даже если установлено @everybody;
> - начать активное обсуждение модернизации системы ACL.
>
> Если меры не будут приняты в ближайшее время, я вынужден буду блокировать
> задачи grenka в Sisyphus и других репозиториях, поскольку у него не было
> основания массово блокировать работу других мейнтейнеров.
>
> Прошу администрацию girar отнестить к этому с пониманием.
>
> Знаю, что grenka попытается оправдаться, назвав эту схему сборки
> "вирусной" или "непопулярной". Но политики на способ сборки
> Python-пакетов у нас нет, а автоматизация на основе PEP-стандартов
> удобна и используется не одним человеком. Личные предпочтения не должны
> вести к саботажу чужой работы - и напомню, что с его пакетами так никто
> не поступал специально и уже тем более массово (единичные случае были,
> согласен, но это не дает право ему красть массово для себя чужие
> пакеты; лидерство в сборке python3 так же не дает право этого делать и
> считать себя диктаторов в экосистеме в репозитории и творить что только
> в голову взбредет).
>
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Массовая, вероломная и необоснованная кража пакетов

[Sergey Bolshakov]

Поддерживаю.
Такого вызывающе неприемлемого поведения участника команды
я не припомню за все время участия в проекте.
Заслуживает отдельного обсуждения то, что такое оказалось
технически возможным.

-- 

Re: [devel] Массовая, вероломная и необоснованная кража пакетов

[Paul Wolneykien]

В Mon, 30 Mar 2026 12:05:40 +0300
Sergey Bolshakov <sbolshakov@altlinux.ru> пишет:

> Заслуживает отдельного обсуждения то, что такое оказалось
> технически возможным.

  Вероятно, verybuddy всё-таки не должно распространяться
на удаление пакетов. А может быть удаление и восстановление
пакета должно сохранять старый ACL.

[devel] Re: Массовая, вероломная и необоснованная кража пакетов

[Sergey V Turchin]

On Monday, 30 March 2026 12:37:55 MSK Paul Wolneykien wrote:
> В Mon, 30 Mar 2026 12:05:40 +0300
> 
> Sergey Bolshakov <sbolshakov@altlinux.ru> пишет:
> > Заслуживает отдельного обсуждения то, что такое оказалось
> > технически возможным.
> 
>   Вероятно, verybuddy всё-таки не должно распространяться
> на удаление пакетов.
Однозначно.

> А может быть удаление и восстановление
> пакета должно сохранять старый ACL.
Тоже было бы неплохо, но если не истёк "период охлаждения".

-- 
Regards, Sergey.

Re: [devel] Массовая, вероломная и необоснованная кража пакетов

[Anton Farygin]

On 3/30/26 12:37, Paul Wolneykien wrote:
> В Mon, 30 Mar 2026 12:05:40 +0300
> Sergey Bolshakov <sbolshakov@altlinux.ru> пишет:
>
>> Заслуживает отдельного обсуждения то, что такое оказалось
>> технически возможным.
>    Вероятно, verybuddy всё-таки не должно распространяться
> на удаление пакетов. А может быть удаление и восстановление
> пакета должно сохранять старый ACL.

Паш, но у меня был отличный мой пакет, которому я владельца сделал 
@python что бы всем сопровождающим экосистему было удобно с ним работать.

и тут меня неожиданно убирают из группы без объяснения причин.

И у меня только один выход - восстановить справедливость через удаление 
пакета и урок на будущее - никогда не доверять группам, в которых лидер 
ведёт себя неприлично.


А т.к. до этого момента таких прецендентов не было - то остаётся просто 
не доверять группам.

Re: [devel] Массовая, вероломная и необоснованная кража пакетов

[Paul Wolneykien]

В Mon, 30 Mar 2026 13:35:11 +0300
Anton Farygin <rider@basealt.ru> пишет:

> On 3/30/26 12:37, Paul Wolneykien wrote:
> > В Mon, 30 Mar 2026 12:05:40 +0300
> > Sergey Bolshakov <sbolshakov@altlinux.ru> пишет:
> >  
> >> Заслуживает отдельного обсуждения то, что такое оказалось
> >> технически возможным.  
> >    Вероятно, verybuddy всё-таки не должно распространяться
> > на удаление пакетов. А может быть удаление и восстановление
> > пакета должно сохранять старый ACL.  
> 
> Паш, но у меня был отличный мой пакет, которому я владельца сделал 
> @python что бы всем сопровождающим экосистему было удобно с ним работать.

  А, там же группа, точно. С группами в ACL мне не приходилось работать.
Почему группа должна быть именно лидером, как это влияет на удобство?
Хотя, даже если группа просто входит в ACL, то сейчас это не помешает
удалить пакет.

> 
> и тут меня неожиданно убирают из группы без объяснения причин.
> 
> И у меня только один выход - восстановить справедливость через удаление 
> пакета и урок на будущее - никогда не доверять группам, в которых лидер 
> ведёт себя неприлично.
> 
> 
> А т.к. до этого момента таких прецендентов не было - то остаётся просто 
> не доверять группам.

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

Re: [devel] Массовая, вероломная и необоснованная кража пакетов

[Anton Farygin]

On 3/30/26 14:06, Paul Wolneykien wrote:
>    Ну, это уже слишком, по-моему. Если лидер группы тебе известен, то
> можно заранее понять, насколько он адекватный.

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

[devel] Re: Массовая, вероломная и необоснованная кража пакетов

[Sergey V Turchin]

On Monday, 30 March 2026 13:48:19 MSK скрылевъ малъ wrote:
> Ну то есть, удалить пакетъ можетъ только лидеръ, это болѣе менѣе осмысленное
> усрѣднённое рѣшеніе, такъ? 
Нет. Предложение было совсем другое.

> ----------------
> Кому: devel@lists.altlinux.org (devel@lists.altlinux.org);
> Тема: [devel] Массовая, вероломная и необоснованная кража пакетов;
> 30.03.2026, 12:38, "Paul Wolneykien" <manowar@altlinux.org>:
> 
> В Mon, 30 Mar 2026 12:05:40 +0300
> Sergey Bolshakov <sbolshakov@altlinux.ru> пишет:
>  
> 
>  Заслуживает отдельного обсуждения то, что такое оказалось
>  технически возможным.
> 
> 
>   Вероятно, verybuddy всё-таки не должно распространяться
> на удаление пакетов. А может быть удаление и восстановление
> пакета должно сохранять старый ACL.
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
> 
>  
>  
> -- 
> Съ уваженіемъ, Павелъ «Малъ» Скрылёвъ
> https://t.me/majioa
> +79055245451
>  


-- 
Regards, Sergey.

Re: [devel] ACL на удаляемые пакеты

[Dmitry V. Levin]

On Mon, Mar 30, 2026 at 12:37:55PM +0300, Paul Wolneykien wrote:
> В Mon, 30 Mar 2026 12:05:40 +0300, Sergey Bolshakov пишет:
> 
> > Заслуживает отдельного обсуждения то, что такое оказалось
> > технически возможным.
> 
>   Вероятно, verybuddy всё-таки не должно распространяться
> на удаление пакетов. А может быть удаление и восстановление
> пакета должно сохранять старый ACL.

Если удаление пакета не будет приводить к удалению ACL на него,
то разница между кривой сборкой пакета и удалением этого пакета
становится незначительной.

В качестве технического решения в первом приближении я бы предложил:
- ACL удаляемых пакетов не удалять;
- обработку @everybody не менять.


-- 
ldv

Re: [devel] ACL на удаляемые пакеты

[Sergey V Turchin]

On Tuesday, 31 March 2026 13:53:45 MSK Dmitry Levin wrote:

[...]
> В качестве технического решения в первом приближении я бы предложил:
> - ACL удаляемых пакетов не удалять;
Тогда в нормальной ситуации может всплыть лидером мантейнер, которого реально 
след давно простыл. Нужен "период охлаждения", после которого ACL удаляется.

> - обработку @everybody не менять.
Полагаю, это простимулирует удаление его из ACL. Хотя, может и правильно.

-- 
Regards, Sergey.

Re: [devel] ACL на удаляемые пакеты

[Paul Wolneykien]

В Tue, 31 Mar 2026 14:06:13 +0300
Sergey V Turchin <zerg@altlinux.org> пишет:

> > В качестве технического решения в первом приближении я бы предложил:
> > - ACL удаляемых пакетов не удалять;  
> Тогда в нормальной ситуации может всплыть лидером мантейнер, которого реально 
> след давно простыл. Нужен "период охлаждения", после которого ACL удаляется.

  Серёж, но ведь у нас есть пакеты, в которых нет @everybody или иных
групп, и мэйнтейнер которых годами не появляется. Поэтому удаление ACL
в обход лидера, фактически, доступно сейчас лишь для части пакетов.
Я считаю, что для этой проблемы нужно искать отдельное решение, не
утешая себя тем, что для части пакетов её можно обойти. А значит
переход на схему, в которой ACL не будет удаляться вместе с пакетом,
сделает всю ситуацию более однозначной.

Re: [devel] ACL на удаляемые пакеты

[Sergey V Turchin]

On Tuesday, 31 March 2026 14:22:32 MSK Paul Wolneykien wrote:

[...]
> у нас есть пакеты, в которых нет @everybody или иных
> групп, и мэйнтейнер которых годами не появляется. Поэтому удаление ACL
> в обход лидера, фактически, доступно сейчас лишь для части пакетов.
> Я считаю, что для этой проблемы нужно искать отдельное решение
Абсолютно согласен.

[...]

-- 
Regards, Sergey.

Re: [devel] ACL на удаляемые пакеты

[Ivan A. Melnikov]

On Tue, Mar 31, 2026 at 01:53:45PM +0300, Dmitry V. Levin wrote:
> On Mon, Mar 30, 2026 at 12:37:55PM +0300, Paul Wolneykien wrote:
> > В Mon, 30 Mar 2026 12:05:40 +0300, Sergey Bolshakov пишет:
> > 
> > > Заслуживает отдельного обсуждения то, что такое оказалось
> > > технически возможным.
> > 
> >   Вероятно, verybuddy всё-таки не должно распространяться
> > на удаление пакетов. А может быть удаление и восстановление
> > пакета должно сохранять старый ACL.
> 
> Если удаление пакета не будет приводить к удалению ACL на него,
> то разница между кривой сборкой пакета и удалением этого пакета
> становится незначительной.
> 
> В качестве технического решения в первом приближении я бы предложил:
> - ACL удаляемых пакетов не удалять;
> - обработку @everybody не менять.

Сохранение ACL удаляемых пакетов легко обойти переименованием
пакета. Вместо python3-module-foo у нас будет python3-module-Foo,
потому что именно так он называется в PyPi, и вот пожалуйста,
новый ACL.

Запрет на удаление пакетов через @everybody не только решает
все подобные проблемы сразу, но и как-то соответствует
ожиданиям от @everybody, по крайней мере моим: я готов
к совместной работе над пакетом с любым участником Team,
до тех пор, пока пакет остаётся в Сизифе и я могу им
пользоваться.

-- 
  wbr,
    iv m.

Re: [devel] ACL на удаляемые пакеты

[Sergey V Turchin]

On Tuesday, 31 March 2026 14:48:29 MSK Ivan Melnikov wrote:

[...]
> Запрет на удаление пакетов через @everybody не только решает
> все подобные проблемы сразу, но и как-то соответствует
> ожиданиям от @everybody, по крайней мере моим
+1
Только, недавно была добавлена фича для обхода этого. При помощи пересборки 
автоматом влетаешь в ACL.

[...]

-- 
Regards, Sergey.

Re: [devel] ACL на удаляемые пакеты

[Sergey Bolshakov]

>>>>> "Sergey" == Sergey V Turchin <zerg@altlinux.org> writes:

 > On Tuesday, 31 March 2026 14:48:29 MSK Ivan Melnikov wrote:
 > [...]
 >> Запрет на удаление пакетов через @everybody не только решает
 >> все подобные проблемы сразу, но и как-то соответствует
 >> ожиданиям от @everybody, по крайней мере моим
да, такие же ожидания.

> +1
 > Только, недавно была добавлена фича для обхода этого. При помощи пересборки 
 > автоматом влетаешь в ACL.
 > [...]
Я не понимаю, какая с этой фичи польза, хотя бы в теории.
Хорошо бы её убрать.

-- 

[devel] Автодобавление в ACL при пересборке пакета @everybody (was: ACL на удаляемые пакеты)

[Sergey V Turchin]

On Tuesday, 31 March 2026 15:09:44 MSK Sergey Bolshakov wrote:
[...]
>  >> Запрет на удаление пакетов через @everybody не только решает
>  >> все подобные проблемы сразу, но и как-то соответствует
>  >> ожиданиям от @everybody, по крайней мере моим
> да, такие же ожидания.
> > +1
>  > Только, недавно была добавлена фича для обхода этого. При помощи
>  > пересборки автоматом влетаешь в ACL.
>  > [...]
> 
> Я не понимаю, какая с этой фичи польза, хотя бы в теории.
Кажется, этого так и не было рассказано при её обсуждении.
Может, настал момент?

> Хорошо бы её убрать.
+1

-- 
Regards, Sergey.

Re: [devel] Автодобавление в ACL при пересборке пакета @everybody

[Anton Farygin]

On 3/31/26 18:06, Sergey V Turchin wrote:
> On Tuesday, 31 March 2026 15:09:44 MSK Sergey Bolshakov wrote:
> [...]
>>   >> Запрет на удаление пакетов через @everybody не только решает
>>   >> все подобные проблемы сразу, но и как-то соответствует
>>   >> ожиданиям от @everybody, по крайней мере моим
>> да, такие же ожидания.
>>> +1
>>   > Только, недавно была добавлена фича для обхода этого. При помощи
>>   > пересборки автоматом влетаешь в ACL.
>>   > [...]
>>
>> Я не понимаю, какая с этой фичи польза, хотя бы в теории.
> Кажется, этого так и не было рассказано при её обсуждении.
> Может, настал момент?
>
>> Хорошо бы её убрать.
> +1
>
https://altlinux.space/girar/girar

Re: [devel] Автодобавление в ACL при пересборке пакета @everybody

[Anton Zhukharev]

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

On Tue, Mar 31, 2026 at 06:11:44PM +0300, Anton Farygin wrote:
> On 3/31/26 18:06, Sergey V Turchin wrote:
> > On Tuesday, 31 March 2026 15:09:44 MSK Sergey Bolshakov wrote:
> > [...]
> >>   >> Запрет на удаление пакетов через @everybody не только решает
> >>   >> все подобные проблемы сразу, но и как-то соответствует
> >>   >> ожиданиям от @everybody, по крайней мере моим
> >> да, такие же ожидания.
> >>> +1
> >>   > Только, недавно была добавлена фича для обхода этого. При помощи
> >>   > пересборки автоматом влетаешь в ACL.
> >>   > [...]
> >>
> >> Я не понимаю, какая с этой фичи польза, хотя бы в теории.
> > Кажется, этого так и не было рассказано при её обсуждении.
> > Может, настал момент?
> >
> >> Хорошо бы её убрать.
> > +1
> >
> https://altlinux.space/girar/girar

https://altlinux.space/girar/girar/commit/46b5e79b8689edacf629ac05499cdca381ddd499

Так точнее ;)

Исправление принято уже.

-- 
Anton Zhukharev
ALT Linux Team

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

Re: [devel] Автодобавление в ACL при пересборке пакета @everybody

[Anton Farygin]

On 3/31/26 18:13, Anton Zhukharev wrote:
> On Tue, Mar 31, 2026 at 06:11:44PM +0300, Anton Farygin wrote:
>> On 3/31/26 18:06, Sergey V Turchin wrote:
>>> On Tuesday, 31 March 2026 15:09:44 MSK Sergey Bolshakov wrote:
>>> [...]
>>>>    >> Запрет на удаление пакетов через @everybody не только решает
>>>>    >> все подобные проблемы сразу, но и как-то соответствует
>>>>    >> ожиданиям от @everybody, по крайней мере моим
>>>> да, такие же ожидания.
>>>>> +1
>>>>    > Только, недавно была добавлена фича для обхода этого. При помощи
>>>>    > пересборки автоматом влетаешь в ACL.
>>>>    > [...]
>>>>
>>>> Я не понимаю, какая с этой фичи польза, хотя бы в теории.
>>> Кажется, этого так и не было рассказано при её обсуждении.
>>> Может, настал момент?
>>>
>>>> Хорошо бы её убрать.
>>> +1
>>>
>> https://altlinux.space/girar/girar
> https://altlinux.space/girar/girar/commit/46b5e79b8689edacf629ac05499cdca381ddd499
>
> Так точнее ;)
>
> Исправление принято уже.

По ссылке можно и фиксы и баги развешивать, я для этого её дал.

Re: [devel] Массовая, вероломная и необоснованная кража пакетов

[Айрат Махмутов]

Поддерживаю и прошу администрацию выполнить просьбы @ancieg.
Действия @grenka неадекватны и направлены против
членов сообщества ALT Linux Team.

То, что он сделал не заслуживает отмены в сообществе,
блокировке и удалению аккаунта.
Для каждого из нас, мейнтейнеров, ALT Linux это уже что-то
личное и поэтому мы должны быть готовы к таким инцидентам,
когда чувства сильнее разума. У меня тоже такое было.
Всё таки @grenka долго терпел и писал в devel,
перед тем как начать действовать.
Подобные действия должны быть недопустимы на сборочнице
на программном уровне.

30.03.2026 10:13, Anton Zhukharev пишет:
> Вчера вечером участник сообщества grenka совершил массовое изменение ACL
> пакетов, используемых с rpm-build-pyproject. Пока большинство
> сопровождающих не работало, он удалил исходные пакеты, пересобрал их без
> rpm-build-pyproject и в результате сделал себя единственным лидером ACL.
>
> Под удар попало примерно для 240 пакетов.
>
> Пострадали преимущественно сопровождающие из Обнинска — по всей
> видимости, из-за личной неприязни. Такое поведение недопустимо ни в
> ALT Linux Team, ни в любом другом сообществе.
>
> Мое требование (и, думаю, не только мое) - заблокировать учётную запись
> grenka (в идеале — исключить из команды и полностью удалить его учетную
> запись, освободив все им занятые пакеты) за нетерпимость и фактическую
> кражу интеллектуального труда;
>
> Также прошу:
> - вернуть ACL пакетов их прежним владельцам;
> - откатить изменения и удалить следы этих действий из %changelog;
> - добавить в girar защиту от удаления пакета без явного разрешения
>    лидера ACL, даже если установлено @everybody;
> - начать активное обсуждение модернизации системы ACL.
>
> Если меры не будут приняты в ближайшее время, я вынужден буду блокировать
> задачи grenka в Sisyphus и других репозиториях, поскольку у него не было
> основания массово блокировать работу других мейнтейнеров.
>
> Прошу администрацию girar отнестить к этому с пониманием.
>
> Знаю, что grenka попытается оправдаться, назвав эту схему сборки
> "вирусной" или "непопулярной". Но политики на способ сборки
> Python-пакетов у нас нет, а автоматизация на основе PEP-стандартов
> удобна и используется не одним человеком. Личные предпочтения не должны
> вести к саботажу чужой работы - и напомню, что с его пакетами так никто
> не поступал специально и уже тем более массово (единичные случае были,
> согласен, но это не дает право ему красть массово для себя чужие
> пакеты; лидерство в сборке python3 так же не дает право этого делать и
> считать себя диктаторов в экосистеме в репозитории и творить что только
> в голову взбредет).
>
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Массовая, вероломная и необоснованная кража пакетов

[Ilya Sorochan]

On Mon Mar 30, 2026 at 10:13 AM MSK, Anton Zhukharev wrote:
> Вчера вечером участник сообщества grenka совершил массовое изменение ACL
> пакетов, используемых с rpm-build-pyproject. Пока большинство
> сопровождающих не работало, он удалил исходные пакеты, пересобрал их без
> rpm-build-pyproject и в результате сделал себя единственным лидером ACL.
>
> Под удар попало примерно для 240 пакетов.
>
> Пострадали преимущественно сопровождающие из Обнинска — по всей
> видимости, из-за личной неприязни. Такое поведение недопустимо ни в
> ALT Linux Team, ни в любом другом сообществе.
>
> Мое требование (и, думаю, не только мое) - заблокировать учётную запись
> grenka (в идеале — исключить из команды и полностью удалить его учетную
> запись, освободив все им занятые пакеты) за нетерпимость и фактическую
> кражу интеллектуального труда;
>
> Также прошу:
> - вернуть ACL пакетов их прежним владельцам;
> - откатить изменения и удалить следы этих действий из %changelog;
> - добавить в girar защиту от удаления пакета без явного разрешения
>   лидера ACL, даже если установлено @everybody;
> - начать активное обсуждение модернизации системы ACL.
>
> Если меры не будут приняты в ближайшее время, я вынужден буду блокировать
> задачи grenka в Sisyphus и других репозиториях, поскольку у него не было
> основания массово блокировать работу других мейнтейнеров.
>
> Прошу администрацию girar отнестить к этому с пониманием.

Откатить изменения звучит вполне разумно.
Банить человека и блочить его задачи означает способствовать отсутствию
нормальной коммуникации. В первую очередь давайте выслушаем grenka@.

> Знаю, что grenka попытается оправдаться, назвав эту схему сборки
> "вирусной" или "непопулярной". Но политики на способ сборки
> Python-пакетов у нас нет, а автоматизация на основе PEP-стандартов
> удобна и используется не одним человеком. Личные предпочтения не должны
> вести к саботажу чужой работы - и напомню, что с его пакетами так никто
> не поступал специально и уже тем более массово (единичные случае были,
> согласен, но это не дает право ему красть массово для себя чужие
> пакеты; лидерство в сборке python3 так же не дает право этого делать и
> считать себя диктаторов в экосистеме в репозитории и творить что только
> в голову взбредет).

Присвоению "живых" пакетов с последующим закрытием ACL нет оправдания. Все же
не хотелось бы просто так терять мейнтейнера, тем более что его усилия могли бы
быть направлены на полиси питона и приведению других пакетов к нему. Без
присвоения и с разумным согласованием, естественно.

Re: [devel] Массовая, вероломная и необоснованная кража пакетов

[Vitaly Lipatov]

Anton Zhukharev писал(а) 30.3.26 10:13:
> Вчера вечером участник сообщества grenka совершил массовое изменение 
> ACL
> пакетов, используемых с rpm-build-pyproject. Пока большинство
> сопровождающих не работало, он удалил исходные пакеты, пересобрал их 
> без
> rpm-build-pyproject и в результате сделал себя единственным лидером 
> ACL.
> 
> Под удар попало примерно для 240 пакетов.
> 
> Пострадали преимущественно сопровождающие из Обнинска — по всей
> видимости, из-за личной неприязни. Такое поведение недопустимо ни в
> ALT Linux Team, ни в любом другом сообществе.
> 
> Мое требование (и, думаю, не только мое) - заблокировать учётную запись
> grenka (в идеале — исключить из команды и полностью удалить его учетную
> запись, освободив все им занятые пакеты) за нетерпимость и фактическую
> кражу интеллектуального труда;
Я бы хотел обсудить, как же так довели человека сопровождающие из 
Обнинска, что он решился на такой поступок. Как так получилось, что вы 
длительное время поддерживали личную неприязнь, не предпринимая никаких 
мер для её урегулирования.
Разрушение сообщества происходит задолго до скулшутинга. Зато потом все 
говорят, какие они были хорошие, и ничего не замечали.

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

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

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

Re: [devel] Массовая, вероломная и необоснованная кража пакетов

[Evgeny Sinelnikov]

пн, 30 мар. 2026 г. в 21:19, Vitaly Lipatov <lav@altlinux.ru>:
>
> Anton Zhukharev писал(а) 30.3.26 10:13:
> > Вчера вечером участник сообщества grenka совершил массовое изменение
> > ACL
> > пакетов, используемых с rpm-build-pyproject. Пока большинство
> > сопровождающих не работало, он удалил исходные пакеты, пересобрал их
> > без
> > rpm-build-pyproject и в результате сделал себя единственным лидером
> > ACL.
> >
> > Под удар попало примерно для 240 пакетов.
> >
> > Пострадали преимущественно сопровождающие из Обнинска — по всей
> > видимости, из-за личной неприязни. Такое поведение недопустимо ни в
> > ALT Linux Team, ни в любом другом сообществе.
> >
> > Мое требование (и, думаю, не только мое) - заблокировать учётную запись
> > grenka (в идеале — исключить из команды и полностью удалить его учетную
> > запись, освободив все им занятые пакеты) за нетерпимость и фактическую
> > кражу интеллектуального труда;
> Я бы хотел обсудить, как же так довели человека сопровождающие из
> Обнинска, что он решился на такой поступок. Как так получилось, что вы
> длительное время поддерживали личную неприязнь, не предпринимая никаких
> мер для её урегулирования.
> Разрушение сообщества происходит задолго до скулшутинга. Зато потом все
> говорят, какие они были хорошие, и ничего не замечали.
>
> Я вот предполагаю, что имели место хитрые подковёрные действия, к
> каждому из которых не придерёшься, и им сложно противостоять, но в
> совокупности они направлены на продвижение своей линии.
>
> Не думаю, что если мы начнём требовать заблокировать учётные записи друг
> друга, это будет на пользу Тим. Нужно уметь договариваться, а не
> прогибать силой или массой.
>

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

В целом, вести конструктивный, убедительный, технический спор - это
сложно, долго и дорого.

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

Когда же аргументы не выглядят убедительно, то никаких других мер не
видно. А это уже вопрос готовности в таком виде сопровождать python, в
принципе. Наверное, так стоило поставить вопрос.





--
Sin (Sinelnikov Evgeny)

Re: [devel] Массовая, вероломная и необоснованная кража пакетов

[Anton Farygin]

On 3/30/26 20:48, Evgeny Sinelnikov wrote:
> Когда же аргументы не выглядят убедительно, то никаких других мер не
> видно. А это уже вопрос готовности в таком виде сопровождать python, в
> принципе. Наверное, так стоило поставить вопрос.

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

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

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

Но до сих пор нет ни одного конструктивного замечания как к 
документации, так и к макросам:

https://www.altlinux.org/Python_packaging_guide

https://packages.altlinux.org/ru/sisyphus/srpms/rpm-build-pyproject/issues/


Кстати, когда я делал генератор python пакетов в zoryn, то я не нашёл 
нигде на www.altlinux.org документации  по старой схеме сборки.

В целом лично мне всё равно как собирать пакеты python, главное поменьше 
ручного труда и побольше автоматизации. Ну и лучше конечно единую 
политику написать и принять.

Re: [devel] Массовая, вероломная и необоснованная кража пакетов

[Anton Midyukov]

30.03.2026 20:58, Anton Farygin пишет:
> On 3/30/26 20:48, Evgeny Sinelnikov wrote:
>> Когда же аргументы не выглядят убедительно, то никаких других мер не
>> видно. А это уже вопрос готовности в таком виде сопровождать python, в
>> принципе. Наверное, так стоило поставить вопрос.
> 
> Большая экосистема с множеством ментейнеров должна регулироваться не письмами в рассылке а зафиксированной политикой сборки пакетов.
> 
> В случае отсутствия единой политики - всегда найдётся кто-то, кто хочет сделать свою работу по сопровождению пакетов проще (на его взгляд, конечно) и обвяжет это каким-то инструментарием.
> 
> К счастью этот инструментарий документированный, открытый, публичный и его можно обсуждать и развивать и им удобно пользоваться.
> 
> Но до сих пор нет ни одного конструктивного замечания как к документации, так и к макросам:
> 
> https://www.altlinux.org/Python_packaging_guide
> 

Почему статья на английском языке?
Автор статьи не знает русского языка?
Для статей на английском языке есть en.altlinux.org
Или это не уважение к сообществу со стороны автора?
Об этом я писал давно:
https://lore.altlinux.org/devel/b1a7b8df-9805-46d4-83f7-af0e21eca051@altlinux.org/

Но неприятие не к этой статье, а к другой:
https://www.altlinux.org/Management_of_Python_dependencies_sources

и конструктивная критика была:
https://lore.altlinux.org/devel/ff5f2ad9-e94d-4ea8-afde-e507164c9875@altlinux.org/

-- 
best regards, Anton Midyukov <antohami@altlinux.org>

Re: [devel] Массовая, вероломная и необоснованная кража пакетов

[Stanislav Levin]

[-- Attachment #1.1: Type: text/plain, Size: 9211 bytes --]



On 3/31/26 12:04 PM, Anton Midyukov wrote:
> 30.03.2026 20:58, Anton Farygin пишет:
>> On 3/30/26 20:48, Evgeny Sinelnikov wrote:
>>> Когда же аргументы не выглядят убедительно, то никаких других мер не
>>> видно. А это уже вопрос готовности в таком виде сопровождать python, в
>>> принципе. Наверное, так стоило поставить вопрос.
>>
>> Большая экосистема с множеством ментейнеров должна регулироваться не письмами в рассылке а зафиксированной политикой сборки пакетов.
>>
>> В случае отсутствия единой политики - всегда найдётся кто-то, кто хочет сделать свою работу по сопровождению пакетов проще (на его взгляд, конечно) и обвяжет это каким-то инструментарием.
>>
>> К счастью этот инструментарий документированный, открытый, публичный и его можно обсуждать и развивать и им удобно пользоваться.
>>
>> Но до сих пор нет ни одного конструктивного замечания как к документации, так и к макросам:
>>
>> https://www.altlinux.org/Python_packaging_guide
>>
> 
> Почему статья на английском языке?
0) почему нет?
1) ожидалось участие не только русскоговорящих
2) большинство терминов англоязычных
3) *мне* так больше *нравится*
4) пока что никто не просил перевести

> Автор статьи не знает русского языка?
никто не знает его в совершенстве ;)

> Для статей на английском языке есть en.altlinux.org
> Или это не уважение к сообществу со стороны автора?
неуважение - это требование чего-то.

Согласен, что лучше перенести на англоязычную вики и сделал бы, но как 
тогда, так и сейчас не удается завершить регистрацию (не работает).

> 
> и конструктивная критика была:
> https://lore.altlinux.org/devel/ff5f2ad9-e94d-4ea8-afde-e507164c9875@altlinux.org/
> 

Простите, но не удается найти "объективную" и "конструктивную" критику 
или вопросы. Наверное, проблема в недостаточном знании русского :(

 > 1.) Данный подход полностью ломает идею спек-файла, который по
оригинальной задумке должен хранить _всю_ информацию о пакете. То есть
открыв спек-файл нельзя определить его зависимости, в поиске по спекам
нельзя отгрепать зависимости и так далее.

Чью идею? Кто так решил? Что такое оригинальная задумка? И главный 
вопрос - а почему подходы и взгляды не могут быть изменены со временем?

 > 2.) Спек превращается в результат автогенерации бесчисленного количества
макросов. Раньше подобным автогенератам было место в репозитории
Autoimports, в сизиф же пропускались "очеловеченные" спеки, которые
доступны для чтения и понимания участникам сообщества. Перефразируя
Мартина Фаулера "Скрипты могут писать спеки, понятные сборочнице,
хорошие мейнтейнеры пишут спеки понятные людям".

Это личное мнение, которое уважаю и принимаю, но это *личное* мнение.

 > 3.) Проблемы с бэкпортами. Вспоминаем сколько спотыкались о другую
"инновационную разработку" под названием ubt.

Абстрактные проблемы, которые не были озвучены. Плюс очевидная попытка 
флеймить про zerg's ubt ;)

 > 4.) Автоматическая генерация зависимостей очевидно порождает мусор.
Поэтому в 180 пакетах из 560 присутствуют костыли под названием
*_filter, которые призваны отфильтровывать список зависимостей. То есть
вместо списка зависимостей, в спеке идёт список _независимостей_.

Автор выражает свое личное мнение, используя усиление конструкции через 
"очевидно". Нет попытки анализа применения фильтров зависимостей, 
которые могут применяться по нескольким причинам. Среди основных
я бы выделил:
- зависимости нет в репозитории и она опциональная
- отсутствие необходимости в зависимости и желание соптимизировать

То есть это - очень *валидные* причины.

 > 5.) В текущем состоянии наш замечательный репозиторий сизифа потерял
консистентность в области питоновских пакетов. Очевидно, что для
обновления или исправления одних пакетов зачастую приходится влезать в
другие. Далеко не у всех есть желание разбираться в модулях собранных
этим необычным способом. Так, например, за последний год было
_испорчено_ несколько ключевых модулей, для бутстрапа нового питона.
Ручки бутстрапа оторваны, списки зависимостей переделаны в
автоматическом режиме, хотя раньше всё было чётко выверено.

"очевидно", "не у всех есть желание", "необычным способом", "испорчено", 
"раньше всё было" - маркеры личного субъективного мнения.

 > Автору данного подхода рекомендую доделать свою автоматику таким
образом, чтобы ей можно было пользоваться добровольно. То есть написать
скрипт таким образом, чтобы он из существующих файлов со спецификациями
зависимостей выдирал всё необходимое как сейчас, но добавлял их не в
отдельный json-файл а в привычном для всех виде как BuildRequires в
спек-файле. Я такое уже реализовывал для обновления библиотек openstack.

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

Технически, зависимости формата pep508 резолвятся в конкретном окружении
и *могут* зависеть от множества факторов (например, самые популярные - 
это версия питона и архитектура), поэтому переложить логику маркеров 
зависимостей на условные RPM макросы *мне* не представляется тривиальной 
задачей.

Таким образом,
выражается негативное личное мнение и вся "конструктивная" критика 
сводится к "все было хорошо, что-то поменялось, не хочется разбираться и 
верните как было".



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [devel] Массовая, вероломная и необоснованная кража пакетов

[Denis Medvedev]

On Tue, 31 Mar 2026 13:29:33 +0300
Stanislav Levin <slev@altlinux.org> wrote:

> 
> 
> On 3/31/26 12:04 PM, Anton Midyukov wrote:
> > 30.03.2026 20:58, Anton Farygin пишет:
> >> On 3/30/26 20:48, Evgeny Sinelnikov wrote:
> >>> Когда же аргументы не выглядят убедительно, то никаких других мер не
> >>> видно. А это уже вопрос готовности в таком виде сопровождать python, в
> >>> принципе. Наверное, так стоило поставить вопрос.
> >>
> >> Большая экосистема с множеством ментейнеров должна регулироваться не письмами в рассылке а зафиксированной политикой сборки пакетов.
> >>
> >> В случае отсутствия единой политики - всегда найдётся кто-то, кто хочет сделать свою работу по сопровождению пакетов проще (на его взгляд, конечно) и обвяжет это каким-то инструментарием.
> >>
> >> К счастью этот инструментарий документированный, открытый, публичный и его можно обсуждать и развивать и им удобно пользоваться.
> >>
> >> Но до сих пор нет ни одного конструктивного замечания как к документации, так и к макросам:
> >>
> >> https://www.altlinux.org/Python_packaging_guide
> >>
> > 
> > Почему статья на английском языке?
> 0) почему нет?
> 1) ожидалось участие не только русскоговорящих
> 2) большинство терминов англоязычных
> 3) *мне* так больше *нравится*
> 4) пока что никто не просил перевести
Высказываю официальную просьбу перевести. Для начинающих сборщиков коих у нас
большинство из Росси будет проще.
> 
> > Автор статьи не знает русского языка?
> никто не знает его в совершенстве ;)
> 
> > Для статей на английском языке есть en.altlinux.org
> > Или это не уважение к сообществу со стороны автора?
> неуважение - это требование чего-то.
> 
> Согласен, что лучше перенести на англоязычную вики и сделал бы, но как 
> тогда, так и сейчас не удается завершить регистрацию (не работает).
> 
> > 
> > и конструктивная критика была:
> > https://lore.altlinux.org/devel/ff5f2ad9-e94d-4ea8-afde-e507164c9875@altlinux.org/
> > 
> 
> Простите, но не удается найти "объективную" и "конструктивную" критику 
> или вопросы. Наверное, проблема в недостаточном знании русского :(
> 
>  > 1.) Данный подход полностью ломает идею спек-файла, который по
> оригинальной задумке должен хранить _всю_ информацию о пакете. То есть
> открыв спек-файл нельзя определить его зависимости, в поиске по спекам
> нельзя отгрепать зависимости и так далее.
> 
> Чью идею? Кто так решил? Что такое оригинальная задумка? И главный 
> вопрос - а почему подходы и взгляды не могут быть изменены со временем?
> 
>  > 2.) Спек превращается в результат автогенерации бесчисленного количества
> макросов. Раньше подобным автогенератам было место в репозитории
> Autoimports, в сизиф же пропускались "очеловеченные" спеки, которые
> доступны для чтения и понимания участникам сообщества. Перефразируя
> Мартина Фаулера "Скрипты могут писать спеки, понятные сборочнице,
> хорошие мейнтейнеры пишут спеки понятные людям".
> 
> Это личное мнение, которое уважаю и принимаю, но это *личное* мнение.
> 
>  > 3.) Проблемы с бэкпортами. Вспоминаем сколько спотыкались о другую
> "инновационную разработку" под названием ubt.
> 
> Абстрактные проблемы, которые не были озвучены. Плюс очевидная попытка 
> флеймить про zerg's ubt ;)
> 
>  > 4.) Автоматическая генерация зависимостей очевидно порождает мусор.
> Поэтому в 180 пакетах из 560 присутствуют костыли под названием
> *_filter, которые призваны отфильтровывать список зависимостей. То есть
> вместо списка зависимостей, в спеке идёт список _независимостей_.
> 
> Автор выражает свое личное мнение, используя усиление конструкции через 
> "очевидно". Нет попытки анализа применения фильтров зависимостей, 
> которые могут применяться по нескольким причинам. Среди основных
> я бы выделил:
> - зависимости нет в репозитории и она опциональная
> - отсутствие необходимости в зависимости и желание соптимизировать
> 
> То есть это - очень *валидные* причины.
> 
>  > 5.) В текущем состоянии наш замечательный репозиторий сизифа потерял
> консистентность в области питоновских пакетов. Очевидно, что для
> обновления или исправления одних пакетов зачастую приходится влезать в
> другие. Далеко не у всех есть желание разбираться в модулях собранных
> этим необычным способом. Так, например, за последний год было
> _испорчено_ несколько ключевых модулей, для бутстрапа нового питона.
> Ручки бутстрапа оторваны, списки зависимостей переделаны в
> автоматическом режиме, хотя раньше всё было чётко выверено.
> 
> "очевидно", "не у всех есть желание", "необычным способом", "испорчено", 
> "раньше всё было" - маркеры личного субъективного мнения.
> 
>  > Автору данного подхода рекомендую доделать свою автоматику таким
> образом, чтобы ей можно было пользоваться добровольно. То есть написать
> скрипт таким образом, чтобы он из существующих файлов со спецификациями
> зависимостей выдирал всё необходимое как сейчас, но добавлял их не в
> отдельный json-файл а в привычном для всех виде как BuildRequires в
> спек-файле. Я такое уже реализовывал для обновления библиотек openstack.
> 
> Привычное для каждого человека может быть разным, как и ожидания. 
> Используется попытка выдать свои личные ожидания за общие.
> 
> Технически, зависимости формата pep508 резолвятся в конкретном окружении
> и *могут* зависеть от множества факторов (например, самые популярные - 
> это версия питона и архитектура), поэтому переложить логику маркеров 
> зависимостей на условные RPM макросы *мне* не представляется тривиальной 
> задачей.
> 
> Таким образом,
> выражается негативное личное мнение и вся "конструктивная" критика 
> сводится к "все было хорошо, что-то поменялось, не хочется разбираться и 
> верните как было".
> 
> 



-- 
    

Re: [devel] Массовая, вероломная и необоснованная кража пакетов

[Paul Wolneykien]

В Mon, 30 Mar 2026 21:48:21 +0400
Evgeny Sinelnikov <sin@altlinux.org> пишет:

> пн, 30 мар. 2026 г. в 21:19, Vitaly Lipatov <lav@altlinux.ru>:
> >
> > Anton Zhukharev писал(а) 30.3.26 10:13:  
> > > Вчера вечером участник сообщества grenka совершил массовое изменение
> > > ACL
> > > пакетов, используемых с rpm-build-pyproject. Пока большинство
> > > сопровождающих не работало, он удалил исходные пакеты, пересобрал их
> > > без
> > > rpm-build-pyproject и в результате сделал себя единственным лидером
> > > ACL.
> > >
> > > Под удар попало примерно для 240 пакетов.
> > >
> > > Пострадали преимущественно сопровождающие из Обнинска — по всей
> > > видимости, из-за личной неприязни. Такое поведение недопустимо ни в
> > > ALT Linux Team, ни в любом другом сообществе.
> > >
> > > Мое требование (и, думаю, не только мое) - заблокировать учётную запись
> > > grenka (в идеале — исключить из команды и полностью удалить его учетную
> > > запись, освободив все им занятые пакеты) за нетерпимость и фактическую
> > > кражу интеллектуального труда;  
> > Я бы хотел обсудить, как же так довели человека сопровождающие из
> > Обнинска, что он решился на такой поступок. Как так получилось, что вы
> > длительное время поддерживали личную неприязнь, не предпринимая никаких
> > мер для её урегулирования.
> > Разрушение сообщества происходит задолго до скулшутинга. Зато потом все
> > говорят, какие они были хорошие, и ничего не замечали.
> >
> > Я вот предполагаю, что имели место хитрые подковёрные действия, к
> > каждому из которых не придерёшься, и им сложно противостоять, но в
> > совокупности они направлены на продвижение своей линии.
> >
> > Не думаю, что если мы начнём требовать заблокировать учётные записи друг
> > друга, это будет на пользу Тим. Нужно уметь договариваться, а не
> > прогибать силой или массой.
> >  
> 
> На самом деле, ранее предлагалось сделать то же самое, только
> используя административный ресурс.
> 
> В целом, вести конструктивный, убедительный, технический спор - это
> сложно, долго и дорого.
> 
> Когда другого ресурса нет, остается только такой - предосудительный (и
> я его, если что, не оправдываю). Как минимум, наверное, необходимо
> было зафиксировать цель.
> Тут ведь вопрос, видимо, в том, что переезд на новый питон - это
> нетривиальная сейчас процедура. И начинать стоило с того, чтобы
> обозначить задачу, зафиксировать проблемы, ну, и быть готовым работать
> и убеждать сообщество.
> 
> Когда же аргументы не выглядят убедительно, то никаких других мер не
> видно. А это уже вопрос готовности в таком виде сопровождать python, в
> принципе. Наверное, так стоило поставить вопрос.

  Если я правильно понял, то мы пришли к ситуации, в которой ALT Linux
Team не способна переехать на новый питон из-за возникших разногласий
или ещё чего-то в этом роде. Соответственно, единственно верным решением
будет не переезжать пока. Не нужно никуда ехать, пока есть проблемы
такого масштаба. Переезд на новый питон это не самоцель. Кажется, ясно,
что лучше иметь работающее сообщество, но сломанный питон, чем наоборот.
Хотя бы потому, что в первом случае и починить питон становится
возможным.

Re: [devel] Массовая, вероломная и необоснованная кража пакетов

[Artem Semenov]

30.03.2026 21:33, Paul Wolneykien пишет:
> В Mon, 30 Mar 2026 21:48:21 +0400
> Evgeny Sinelnikov <sin@altlinux.org> пишет:
> 
>> пн, 30 мар. 2026 г. в 21:19, Vitaly Lipatov <lav@altlinux.ru>:
>>>
>>> Anton Zhukharev писал(а) 30.3.26 10:13:
>>>> Вчера вечером участник сообщества grenka совершил массовое изменение
>>>> ACL
>>>> пакетов, используемых с rpm-build-pyproject. Пока большинство
>>>> сопровождающих не работало, он удалил исходные пакеты, пересобрал их
>>>> без
>>>> rpm-build-pyproject и в результате сделал себя единственным лидером
>>>> ACL.
>>>>
>>>> Под удар попало примерно для 240 пакетов.
>>>>
>>>> Пострадали преимущественно сопровождающие из Обнинска — по всей
>>>> видимости, из-за личной неприязни. Такое поведение недопустимо ни в
>>>> ALT Linux Team, ни в любом другом сообществе.
>>>>
>>>> Мое требование (и, думаю, не только мое) - заблокировать учётную запись
>>>> grenka (в идеале — исключить из команды и полностью удалить его учетную
>>>> запись, освободив все им занятые пакеты) за нетерпимость и фактическую
>>>> кражу интеллектуального труда;
>>> Я бы хотел обсудить, как же так довели человека сопровождающие из
>>> Обнинска, что он решился на такой поступок. Как так получилось, что вы
>>> длительное время поддерживали личную неприязнь, не предпринимая никаких
>>> мер для её урегулирования.
>>> Разрушение сообщества происходит задолго до скулшутинга. Зато потом все
>>> говорят, какие они были хорошие, и ничего не замечали.
>>>
>>> Я вот предполагаю, что имели место хитрые подковёрные действия, к
>>> каждому из которых не придерёшься, и им сложно противостоять, но в
>>> совокупности они направлены на продвижение своей линии.
>>>
>>> Не думаю, что если мы начнём требовать заблокировать учётные записи друг
>>> друга, это будет на пользу Тим. Нужно уметь договариваться, а не
>>> прогибать силой или массой.
>>>   
>>
>> На самом деле, ранее предлагалось сделать то же самое, только
>> используя административный ресурс.
>>
>> В целом, вести конструктивный, убедительный, технический спор - это
>> сложно, долго и дорого.
>>
>> Когда другого ресурса нет, остается только такой - предосудительный (и
>> я его, если что, не оправдываю). Как минимум, наверное, необходимо
>> было зафиксировать цель.
>> Тут ведь вопрос, видимо, в том, что переезд на новый питон - это
>> нетривиальная сейчас процедура. И начинать стоило с того, чтобы
>> обозначить задачу, зафиксировать проблемы, ну, и быть готовым работать
>> и убеждать сообщество.
>>
>> Когда же аргументы не выглядят убедительно, то никаких других мер не
>> видно. А это уже вопрос готовности в таком виде сопровождать python, в
>> принципе. Наверное, так стоило поставить вопрос.
> 
>    Если я правильно понял, то мы пришли к ситуации, в которой ALT Linux
> Team не способна переехать на новый питон из-за возникших разногласий
> или ещё чего-то в этом роде. Соответственно, единственно верным решением
> будет не переезжать пока. Не нужно никуда ехать, пока есть проблемы
> такого масштаба. Переезд на новый питон это не самоцель. Кажется, ясно,
> что лучше иметь работающее сообщество, но сломанный питон, чем наоборот.
> Хотя бы потому, что в первом случае и починить питон становится
> возможным.
По мне стоит вернуть пакеты хозяевам в том виде, в котором они были до 
вмешательства и исключить подобную возможность в будущем. т.е. удаление 
пакетов и т.п. должны становится возможной только для пользователй из 
acl пакета за исключением evrerybody.

А дальше предоставить разбираться с сетуацией участникам конфликта.

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

Re: [devel] Массовая, вероломная и необоснованная кража пакетов

[Paul Wolneykien]

В Mon, 30 Mar 2026 20:19:23 +0300
Vitaly Lipatov <lav@altlinux.ru> пишет:

> Anton Zhukharev писал(а) 30.3.26 10:13:
> > Вчера вечером участник сообщества grenka совершил массовое изменение 
> > ACL
> > пакетов, используемых с rpm-build-pyproject. Пока большинство
> > сопровождающих не работало, он удалил исходные пакеты, пересобрал их 
> > без
> > rpm-build-pyproject и в результате сделал себя единственным лидером 
> > ACL.
> > 
> > Под удар попало примерно для 240 пакетов.
> > 
> > Пострадали преимущественно сопровождающие из Обнинска — по всей
> > видимости, из-за личной неприязни. Такое поведение недопустимо ни в
> > ALT Linux Team, ни в любом другом сообществе.
> > 
> > Мое требование (и, думаю, не только мое) - заблокировать учётную запись
> > grenka (в идеале — исключить из команды и полностью удалить его учетную
> > запись, освободив все им занятые пакеты) за нетерпимость и фактическую
> > кражу интеллектуального труда;  
> Я бы хотел обсудить, как же так довели человека сопровождающие из 
> Обнинска, что он решился на такой поступок. Как так получилось, что вы 
> длительное время поддерживали личную неприязнь, не предпринимая никаких 
> мер для её урегулирования.

  Допускаю, что у обоих сторон конфликта могут быть аргументы,
касающиеся "состояния репозитория", "качества пакетов" и прочих
подобных вещей. ИМХО, это называется ставить телегу вперёд лошади.

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

  Поддерживаю. Сообщество ALT устроено так, что за каждым пакетом стоит
человек. И если с этим человеком не получается договориться (Гренка не
смог договориться с Ивановым или же Иванов не смог договориться с
Гренкой -- всё одно), то СДЕЛАТЬ НИЧЕГО НЕЛЬЗЯ. Практическим отражением
такого положения вещей является тот факт, что у нас не предусмотрен
"разджоин", то есть упразднение членства.

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