Найдено и проверено живым прогоном на этой машине (реальный GTK-рабочий
стол, реальные профили agy) — не по чтению кода.
1. Значок .desktop-записи был .ico. Измерено:
GdkPixbuf.Pixbuf.new_from_file на HermesHub.ico падает с "Compressed
icons are not supported". .desktop-файл с нерендерящейся иконкой меню
приложений и файловый менеджер просто показывают пустым — без ошибки,
молча. PNG в тех же ассетах уже был и загружается (проверено: 256x256).
Подставлен app_icon_256.png.
2. Хаб нельзя было остановить иначе как из терминала. На Windows сервер
стартует из HermesHubWeb.exe, который держит значок в системном трее —
оттуда «Exit» останавливает процесс. На Linux сервер остаётся в фоне
после закрытия окна браузера (так и задумано — не переустанавливать
каждый раз), но ни кнопки в интерфейсе (её нет ни на одной платформе),
ни трея, ни пункта меню не было вовсе. launcher/hermes-hub-stop.sh —
недостающий эквивалент «Exit из трея»: доступен из меню приложений
через собственный .desktop-пункт, использует ту же функцию, что и
install/uninstall. Проверено живым прогоном: сервер запущен, остановлен
через новый лаунчер, curl после этого получает connection refused.
3. uninstall-linux.sh не останавливал работающий хаб перед удалением файлов
— та же причина, что install уже чинил для установки: с
--purge-user-data это ещё и rm -rf каталогов, на которые у живого
процесса открыты файловые дескрипторы. Измерено: сервер, запущенный в
песочнице, оставался в списке процессов после uninstall-linux.sh до этой
правки. Добавлена та же остановка, тем же кодом.
4. stop_running_hub была вписана отдельно в install-linux.sh и
uninstall-linux.sh — две копии, которые разошлись бы при правке одной
незамеченной для другой. Вынесена в installer/lib_stop_running_hub.sh,
источается обоими скриптами и новым лаунчером остановки.
Всё проверено дважды: прямым запуском install-linux.sh/uninstall-linux.sh
в изолированной песочнице (не ~/.hermes) и через собранный
dist/hermes-hub-setup.sh — тот самый файл, который уходит в релиз.
Тесты: 738 -> 740 passed, 2 skipped, 4 deselected. Новый тест на .ico падает
на прежней версии install-linux.sh (проверено git stash) и проходит после
фикса. ruff check . чисто.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Установка на сервере владельца прервалась на проверке: «No module named
'fastapi'». Причин две, и обе в установщике.
Первая: запуск через sudo. Установка пользовательская — всё ложится в
$HOME/.hermes и $HOME/.local/bin, root не нужен. Под sudo домашним каталогом
становится /root, венв Hermes там не находится, и установщик уходит на
системный python. Копия при этом ложится в /root/.hermes, где владелец её не
видит. Теперь запуск через sudo распознаётся и отклоняется с объяснением;
осознанный обход остаётся через HERMES_ALLOW_ROOT=1.
Вторая: системный python в Ubuntu 24.04 помечен EXTERNALLY-MANAGED (PEP 668) и
отклоняет pip install — и обычный, и с --user. Установщик обе неудачи проглатывал
(|| true) и продолжал работу до отказа на проверке. Теперь при защищённом
системном python создаётся собственное окружение $HERMES_HOME/venv, а неудача
установки зависимостей прекращает установку с внятным кодом возврата.
--break-system-packages не применяется: имя флага не преувеличивает.
Пусковик научен той же ветке — иначе запуск уходил бы на системный python,
где зависимостей нет и быть не может.
Проверено исполнением на сервере под непривилегированным пользователем:
окружение создано, зависимости установлены, HERMES_HUB_LINUX_VERIFY_OK,
запуск через sudo отклонён с кодом 3.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
agy 2.0 читает учётные данные не из .gemini/oauth_creds.json — это формат
Gemini CLI. Свой токен он берёт из .gemini/antigravity-cli/antigravity-oauth-token
в виде {"auth_method": ..., "token": {...}}. Хаб этот файл никогда не создавал,
поэтому «Авторизация успешно завершена» соседствовала с ответом
«Please sign in to view available models».
Установлено сравнением рабочего профиля владельца с неработающим: оба имели
oauth_creds.json одинакового размера, различие было только в этом файле.
Значение auth_method («consumer») взято из рабочего профиля, а не выведено
из общих соображений.
Срок годности пишется в обоих видах: expiry_date в миллисекундах для формата
Node и expiry строкой RFC3339 для Go-шного oauth2.Token.
Заодно устранён рост номеров профилей: слот выбирался до входа, когда почта
ещё неизвестна, и повторный вход тем же аккаунтом занимал очередной свободный
слот — один аккаунт владельца расползся на ag-2, ag-3, ag-4. Теперь после
опознания почты учётные данные возвращаются в слот, который этот аккаунт уже
занимает. Функция проверки двойников в проекте была, но её никто не вызывал.
Версия поднята до 0.1.3, чтобы отличать сборки на глаз. Проверка версии в
тестах сверяется с исходником, а не с записанным числом.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Установщик копировал файлы, но работающий сервер не трогал. Процесс
продолжал выполнять прежний код из памяти, и владелец видел старый
интерфейс при новом номере сборки: раздача статики читает файлы с диска,
а вся логика действий живёт в загруженном модуле. Три сборки подряд
ставились в файлы, но не в работу — отсюда «сброс не работает»,
«очистка не работает», «версия не изменилась».
Добавлен шаг 0: остановка процессов хаба до копирования. Ищутся только
процессы текущего пользователя и только по признакам хаба
(antigravity_provider.router.web, hermes_hub_web_entry). Сначала обычное
завершение, десять секунд ожидания, затем принудительное. Если процессы
всё же остались, установка НЕ прерывается — файлы обновляются, а владельцу
сообщается, что старый код продолжит работать, пока он их не снимет.
В итоговом сообщении сказано, что хаб остановлен и его надо запустить
заново, и дана команда для проверки, что поднялся новый код.
609 passed, ruff clean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Владелец просил менять версию сборки. Прежнее указание держать 0.1.1
отменено этим.
Поднято во всех пяти местах, где версия объявлена: version.py,
pyproject.toml, HermesHubSetup.cs, install-linux.sh и
config/compatibility.json. Последний ловится тестом на совпадение с
__version__ — без него прогон падал.
599 passed, ruff clean, релизный гейт 10/10.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Владелец хочет попадать в хаб на сервере по сети, а не через SSH-туннель.
Для этого нужны привязка к 0.0.0.0 и токен: без токена при небlocalhost
привязке сервер отказывается стартовать.
Скрипт ДОПОЛНЯЕТ hub_settings.json, а не переписывает: рядом лежат тема,
интервал обновления квот и параметры маршрутизации. Запись атомарная,
повторный запуск сохраняет прежний токен.
Изменение требует явного --yes, а каталог печатается всегда. Причина не
теоретическая: при отладке скрипт молча взял HERMES_HOME из окружения и
записал настройки не в тестовую копию, а в живой хаб рабочей машины,
привязав его к сети. Откачено, наружу ничего не вышло — адрес читается при
старте, процесс не перезапускался, netstat подтвердил только 127.0.0.1.
Предпросмотр по умолчанию закрывает этот класс ошибки.
Попутно install-linux.sh разворачивает scripts/: они входили в поставку, но
на установленной машине не оказывались, поэтому вспомогательных инструментов
там просто не было.
Проверено на копии настроек: предпросмотр не меняет файл, применение
сохраняет прежние ключи, повторный запуск не меняет токен, посторонний
каталог не затрагивается.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
install-linux.sh читал исходники из $REPO_ROOT, поэтому на каждую машину
приходилось приносить весь клон git. Добавлен build_installer_linux.sh: он
собирает один файл dist/hermes-hub-setup.sh — пролог на shell, строка-маркер
и tar.gz побайтово следом. Пролог обрезает себя по маркеру, распаковывает
хвост во временный каталог и запускает оттуда install-linux.sh. Состав
поставки тот же, что у виндового payload, плюс installer/; виндовые .exe и
__pycache__ из линуксовой поставки вычищаются.
Убран запасной коммит-литерал 'fb23bff' в манифесте: при сборке без git он
подставлял чужой номер сборки, из-за чего установленная версия выглядела
определённой, не будучи ею. Теперь коммит берётся из BUILD_COMMIT, который
кладёт сборщик, иначе — 'не определён'.
Проверено: распаковка проходит, в поставке лежат свежие server.py и app.js,
секретов, ключей и почт в ней нет.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
