cl-update спамит мне в почту. Надо это прекратить пожалуйста.

Обновил сегодня ~amd64 CLD.

Особенность первая: у меня в make.conf было PORTDIR_OVERLAY="/usr/local/portage", в котором я развлекаюсь. Поскольку конфиг layman парсился после этой переменной и содержал в себе $PORTDIR_OVERLAY, мой локальный оверлей корректно добавлялся после оверлеев layman. После того как скрипты разрезали мне make.conf на части и перенесли, source /var/lib/layman/make.conf оказался в 0-base и, соответственно, начал парситься первым. Остаток make.conf уехал в custom, и PORTDIR_OVERLAY оттуда перекрыл мне оверлеи layman. Решил исправлением PORTDIR_OVERLAY="$PORTDIR_OVERLAY /usr/local/portage" в custom.

Особенность вторая: больше нет отдельного бинарного подпрофиля, основной профиль теперь бинарный. Соответственно если вы не хотите бинарей добавьте FEATURES="-getbinpkg" в make.conf/custom.

Особенность третья: в /etc/crontab появилось

19 * * * *      root    /usr/bin/nice -n19 /usr/sbin/cl-update -p --wait-another-update off

и спамит мне в почту некрасивыми письмами. Как это прекратить штатными методами? clt шаблон сваять? Спасибо за заботу, но обновляться предпочитаю вручную. Или пусть хотя бы спамит мне в почту красивыми письмами и не так часто. Раз в неделю будет достаточно мне. И почему напрямую туда, есть ведь /etc/cron.daily/ и т.п. Почему бы туда скриптик не положить, а я аккуратно сделаю его неисполняемым например, или переложу куда нужно, не залезая в сам crontab, который кстати редактировать надо через утилиту “crontab”, а не напрямую скриптами туда писать. Кстати, теперь кошерно обновляться через cl-update? eix-sync && emerge -auD --newuse world более некошерно?

Особенность четвёртая: поломалась calculate-console-gui. Не цепляется к calculate-core, говорит

[Errno 1] _ssl.c:510: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol 

python-updater запускал, не помогло.

По последним двум пунктам жду ответов…

[Errno 1] _ssl.c:510: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol

Машина перезагружалась после обновления?

Кстати, теперь кошерно обновляться через cl-update? eix-sync && emerge -auD --newuse world более некошерно?

Можно обновлять старым способом.

есть ведь /etc/cron.daily/ и т.п. Почему бы туда скриптик не положить,

Сейчас скрипт запускается раз в час, причем на каждой машине минуты выставлены случайным образом (чтобы все машины не ломились на git сервер за обновлениями ). cron.XXX запускается каждые десять минут, причем выравнивается на кратные десяти.

Как это прекратить штатными методами? clt шаблон сваять?

Штатных средств пока нет. Закомментируйте строчку в crontab.

Mikhail Hiretsky wrote:

[Errno 1] _ssl.c:510: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol

Машина перезагружалась после обновления?

Да, конечно. Гуголь говорит http://bugs.python.org/issue21462

Сейчас скрипт запускается раз в час, причем на каждой машине минуты выставлены случайным образом (чтобы все машины не ломились на git сервер за обновлениями ). cron.XXX запускается каждые десять минут, причем выравнивается на кратные десяти.

Как это прекратить штатными методами? clt шаблон сваять?

Штатных средств пока нет. Закомментируйте строчку в crontab.

Я вообще удивлён, что мне это приходится объяснять… Я понимаю, что у большинства local mta не настроен и в /root/dead.letter они не смотрят, но это же не повод каждый час слать бессмысленный спам. Во первых, в plain ASCII выхлоп утилиты выглядит ужасно, во вторых, за сутки 24 письма, за неделю 168, за месяц… Я конечно могу это зафильтровать, что лишний раз докажет бессмысленность этой информации. Выход - направьте выхлоп скрипта в null, пусть он только об ошибках сообщает например. Я не против идеи автоматически синхронизировать оверлеи и базу eix, это хорошая идея, просто делать это надо молча.

А вот предпринимать попыток обновления системы, даже с --pretend, в автоматическом режиме IMHO не стоит. Или только в случае интерактивно залогиненого в ГУИ юзера, причем с уведомлением ему в ГУИ, а не на почту. Можно и на почту, но 1(один) раз, при изменении списка обновлений.

Mikhail Hiretsky wrote:

Можно обновлять старым способом.

У меня перестал работать eix-sync

Говорит только это:

 * Выполняются !-хуки
 * Запуск /usr/sbin/cl-core --method update --sync --skip-eix-update
Конфигурация системы
 * Исправление настроек ...                                                  [ ok ]
 * Обновление списка пакетов в системе ...                                   [ ok ]
 * Обновление конфигурационных файлов ...                                    [ ok ]
 * Обновление системы завершено!
 * Копирую старую базу данных в /var/cache/eix/previous.eix
 * Запуск eix-update
Чтение настроек Portage ..
Построение базы данных (/var/cache/eix/portage.eix) ..
[0] "gentoo" /usr/portage (кэш: metadata-md5-or-flat)
     Чтение категории 162|162 (100%) Готово               
[1] "calculate" /var/lib/layman/calculate (кэш: parse|ebuild*#metadata-md5#metadata-flat#assign)
     Чтение категории 162|162 (100%) Готово           
Применение масок ..
Расчёт хеш-таблиц ..
Запись файла базы данных /var/cache/eix/portage.eix ..
База данных содержит 17658 пакетов в 162 категориях.
 * Вызов eix-diff
Сравнение баз данных (17658 -> 17658 пакетов)
 * Статистика времени:
     2 секунд для синхронизация
     3 секунд для eix-update
     2 секунд для eix-diff
     7 секунд всего

В результате обновление портажей не происходит.

eselect profile list что выводит?

Данила Жукоцкий wrote:

Выход - направьте выхлоп скрипта в null

Упустил. Поправлю.

Особенность четвёртая: поломалась calculate-console-gui. Не цепляется к calculate-core

Если создать нового пользователя - удастся соединиться?

Mikhail Hiretsky wrote:

eselect profile list что выводит?

  [1]   default/linux/amd64/13.0
  [2]   default/linux/amd64/13.0/selinux
  [3]   default/linux/amd64/13.0/desktop
  [4]   default/linux/amd64/13.0/desktop/gnome
  [5]   default/linux/amd64/13.0/desktop/gnome/systemd
  [6]   default/linux/amd64/13.0/desktop/kde
  [7]   default/linux/amd64/13.0/desktop/kde/systemd
  [8]   default/linux/amd64/13.0/developer
  [9]   default/linux/amd64/13.0/no-multilib
  [10]  default/linux/amd64/13.0/x32
  [11]  hardened/linux/amd64
  [12]  hardened/linux/amd64/selinux
  [13]  hardened/linux/amd64/no-multilib
  [14]  hardened/linux/amd64/no-multilib/selinux
  [15]  hardened/linux/amd64/x32
  [16]  hardened/linux/uclibc/amd64
  [17]  hardened/linux/musl/amd64

Я так понимаю слетел выбор текущего профиля?
У меня был выбран бинарный. Систему ставил 2 недели назад на чистый комп. И как я понимаю бинарный профиль стоял по умолчанию.

Mikhail Hiretsky wrote:

Данила Жукоцкий wrote:

Выход - направьте выхлоп скрипта в null

Упустил. Поправлю.

Благодарю. Уважаю вашу команду именно за вменяемость.

Особенность четвёртая: поломалась calculate-console-gui. Не цепляется к calculate-core

Если создать нового пользователя - удастся соединиться?

Попробую позже, но не понимаю что это даст. Настройки утилиты и ключи\сертификаты я в профиле пользователя уже сносил, ключи\сертификаты calculate-core тоже, самоподписный root сертификат пересоздавал… Что даст эксперимент с новым пользователем?

Данила Жукоцкий wrote:

Попробую позже, но не понимаю что это даст. Настройки утилиты и ключисертификаты я в профиле пользователя уже сносил, ключисертификаты calculate-core тоже, самоподписный root сертификат пересоздавал… Что даст эксперимент с новым пользователем?

Вы же не писали, что уже пересоздавали сертификаты и прочее, поэтому я предложил простой способ проверки работоспособности calculate-core.

Mikhail Hiretsky wrote:

Данила Жукоцкий wrote:

Попробую позже, но не понимаю что это даст. Настройки утилиты и ключисертификаты я в профиле пользователя уже сносил, ключисертификаты calculate-core тоже, самоподписный root сертификат пересоздавал… Что даст эксперимент с новым пользователем?

Вы же не писали, что уже пересоздавали сертификаты и прочее, поэтому я предложил простой способ проверки работоспособности calculate-core.

calculate-core запускается без ошибок, запущен, root сертификат создал без проблем и ошибок.

Попробуйте перекомпилить dev-python/sudsds

Mikhail Hiretsky wrote:

Попробуйте перекомпилить dev-python/sudsds

Не помогло. revdep-rebuild ошибок тоже не нашёл. Ещё она упав в трей и свернувшись не разворачивается двойным кликом. Приходится щёлкать правой кнопкой, делать “exit program” и снова запускать.

Mikhail Hiretsky wrote:

Попробуйте перекомпилить dev-python/sudsds

Это не оно? http://bugs.python.org/issue21462
Сообщение об ошибке полностью идентично.

ssl.c:510: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol>

WSDL доступен по этому адресу https://127.0.0.1:8888/?wsdl ?

Mikhail Hiretsky wrote:

WSDL доступен по этому адресу https://127.0.0.1:8888/?wsdl ?

Михаил, что такое WSDL и как мне это проверить? Браузер при заходе на ссылку сказал

При соединении с 127.0.0.1:8888 произошла ошибка. 
SSL получило запись, длина которой превышает максимально допустимую. 
(Код ошибки: ssl_error_rx_record_too_long)

Какой версии openssl, python, dev-python/m2crypto ?

Прозрачный прокси, iptables не настраивался?

Mikhail Hiretsky wrote:

Какой версии openssl, python, dev-python/m2crypto ?

[ebuild   R    ] dev-libs/openssl-1.0.1i  USE="(sse2) tls-heartbeat zlib -bindist -gmp -kerberos -rfc3779 -static-libs {-test} -vanilla" ABI_X86="32 (64) (-x32)" 0 KiB
[ebuild   R    ] dev-lang/python-2.7.8:2.7  USE="gdbm ipv6 ncurses readline sqlite ssl threads (wide-unicode) xml -berkdb -build -doc -examples -hardened -tk -wininst" 0 KiB
[ebuild   R    ] dev-python/m2crypto-0.21.1-r1::calculate  USE="-doc -examples" 0 KiB

Прозрачный прокси, iptables не настраивался?

Нет.

 # netstat -t tcp -ap | grep 8888
tcp        0      0 *:8888                  *:*                     LISTEN      26051/python2.7
 # ps -x | grep 26051
26051 ?        Ssl    0:04 /usr/bin/python2.7 /usr/sbin/cl-core --pid-file /var/run/cl_core.pid --start

Система 32 или 64 бита?

Mikhail Hiretsky wrote:

Система 32 или 64 бита?

 # uname -a
Linux supercomp 3.15.10-calculate #4 SMP Wed Aug 20 00:20:28 SAMT 2014 x86_64 Quad-Core AMD Opteron(tm) Processor 2389 AuthenticAMD GNU/Linux