shoorick: (Рыжий)
Надоело, что под Убунту 12.04 LTS не всегда есть свежие версии софта даже в сторонних хранилищах — решил наконец-то обновить домашнюю систему прямо сейчас, не дожидаясь семнадцатого года.

Выяснил, что Убунту теперь предлагает обновляться не до следующей версии, а до ближайшей LTS-версии, что, конечно, в четыре раза лучше, чем было когда-то, но ещё в два раза медленнее, чем хотелось бы. Но делать нечего — обновляемся, как предлагают, в несколько этапов — 12.04 LTS (Precise Pangolin) → 14.04 LTS (Trusty Tahr) → 16.04 LTS (Xenial Xerus).

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

Терминал

http://shoorick.ru/2016/09/11/small-step/
shoorick: (Default)
Обновил на рабочей машине FreeBSD с версии 7.2 до 8.0 — при этом перл с версии 5.10 вернулся на 5.8.

upd/18:16: Обновил перл обратно на 5.10, стал обновлять зависимое от него ПО, а обновить коллекцию портов — забыл. В итоге получил массу сообщений вроде такого:
Downgrading 'p5-TimeDate-1.20,1' to 'p5-TimeDate-1.16,1' (devel/p5-TimeDate)
Балда!
shoorick: (Default)
Задумался, делать ли в Lingua::RU::Inflect проверку наличия элемента в списке циклом (который работает везде) или же взять появившийся в 5.10 оператор ~~.

Вроде бы, с одной стороны, требовать от юзера апгрейдить перл только лишь из-за того, что мне лень писать цикл — нехорошо. Более того, заставлять апгрейдиться на живом сервере (а потом ещё надо будет perl-after-upgrade делать, что тоже потребует какого-то времени) — совсем никуда не годится.

С другой стороны, компактный код, при том, что пишется быстрее, ещё и понятнее выглядит.

P. S. В /var/db/pkg/perl-5.10.1/+REQUIRED_BY обнаружил строку bsdpan-Lingua-RU-Inflect-0.01 — откуда она там? В /var/db/pkg/perl-5.8.9_3/+REQUIRED_BY её нет. И вообще, откуда у меня вдруг два параллельных перла-то взялось? Я, вроде, версию 5.10 специально не ставил...

upd/17:40: Снёс 5.8, оставил только 5.10. Но вот как провернуть безболезненный апгрейд на сервере? Что-то я опасаюсь ненулевого даунтайма. А, возможно, и на час он может растянуться, что плохо.

upd/14.04.2010: Пока я тут думаю, вышла версия 5.12. В портах ещё нет.
shoorick: (Default)
Обновил trac 0.11.5 → 0.11.6. Нечаянно. Специально, помня предыдущий апдейт, я его бы обновлять не стал. Как всегда, всё сломалось. Пока пытался починить, выяснил, что в системе одновременно было установлено три питона: python24-2.4.5_4, python25-2.5.4_2, python26-2.6.4. Апач пытался найти трак среди приложений питона 2.5, при том, что основным был питон 2.6.

Починить удалось путём отсечения Змею двух голов из трёх замены двух старых версий питона на одну новую (portuprgade -o lang/python26 lang/python25; env FORCE_PKG_REGISTER=1 portuprgade -o lang/python26 lang/python25) и последующей пересборкой апачного mod_python.

Попутно, раз уж взялся налаживать trac, всё-таки настроил автоматическое приписывание комментариев к тикетам — трак может, встретив в комментарии к коммиту ссылку на тикет (например, вида re #123), добавить в этот тикет комментарий, а в некоторых случаях (fix #456)— и закрыть его.

Раньше подобный фокус не удавался: на машине используется много хранилищ трака и лишь одно, общее — у subversion; в результате hooks/post-commit всегда получал один и тот же адрес SVN-хранилища, вне зависимости от того, в какой из частей дерева был сделан коммит. Научить скрипт распознавать, в какой части дерева сделаны изменения и, соответственно, к какому траковому проекту обращаться — задача тривиальная; странно, что я не сделал это два года назад. В общем, надо добавить в hooks/post-commit одну строку, и ещё одну — поменять:
PROJECT=`/path/to/svnlook dirs-changed $REPOS -r $REV | head -n 1 | cut -f1 -d/`
TRAC_ENV="/path/to/trac/db/$PROJECT"
shoorick: (Default)
Обновил (давно уже) на localhost subversion до 1.5.1 — svn на тестовом сервере стал ругаться на рабочие копии, созданные на localhost.
Обновил вчера на сервере subversion до 1.6.2 — svn на локалхосте стал ругаться...
Обновил на localhost subversion 1.5.1 → 1.6.2 — стал ругаться trac (сегодня утром дошло, что надо было обновить и py-subversion).
Обновил trac 0.11.3 → 0.11.4 — трак совсем загнулся, пробовал чинить, перенацеливал когда-то сделанный симлинк — помогало, но не очень.

Почитал логи, постучал в бубен — не помогло. Ушёл гулять.

Пришёл утром — обновил py-subversion — всё заработало.
shoorick: (Default)
Захотелось странного — обновить каталист с 5.7 до 5.8: в новом обещали всякий much easer да much faster. Ну и обновил. А до кучи — и остальные перловые модули, что были в портах. В результате и зайцев не спас, и перед партизанами неудобно выяснилось (чё, спрашивается, сразу не посмотрел?), что в портах каталист старый — 5.71001 и после обновления всё загнулось: и свежие, ещё не закоммиченные версии разрабатываемого сайта, и более старые.

Причина крылась в том, что некоторые модули поменялись, а некоторые — вообще стали deprecated, например, Catalyst::Model::DBIC и http://search.cpan.org/perldoc?Catalyst::Plugin::Authentication::Store::DBIC. И в DBIx::Class что-то поломалось.

Решилось пляской с бубном перегенерацией модулей, описывающих структуру базы данных, командой
script/app_create.pl model Dbase DBIC::Schema Dbase create=static dbi:mysql:БД[:хост] логин пароль
При этом модули создались не там, где раньше, а на один уровень глубже — в каталоге Result.

Пробовал задавать create=dynamic, чтобы поменьше получалось — не выходит: сервер не запускается. Пришлось пока остановиться на этом методе. Почитал мануалы, попробовал погуглить — без особого успеха. Домой пришёл лишь в 22:45.

P. S. Видя такой бардак, решил до кучи и перл проапгрейдить до 5.8.9 — проапгрейдил, но наткнулся на очередные грабли: в портах почему-то нет Catalyst::Plugin::RequireSSL — пришлось ставить через perl -MCPAN -e shell.
shoorick: (Default)
Незаметно для себя проапгрейдил на юниксовых машинах perl с 5.8.8 на 5.8.9 — куча скриптов перестала работать, потому что перл стал искать модули в новых местах. Выполнил:
man perl-after-upgrade
perl-after-upgrade
perl-after-upgrade -f
Помогло.
shoorick: (Default)
Заапгрейдил на домашней банке FreeBSD с 6.2 до 7.0.
В целом, работает. Правда, NTFS-ные партиции перестали монтироваться. Но, вроде, мне попадался метод решения — нагуглю ещё раз, исправлю.

А там и на рабочей обновлю.

Profile

shoorick: (Default)
shoorick

December 2016

S M T W T F S
    1 23
45678910
11121314151617
18 19 2021222324
25262728293031

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 19th, 2017 03:18 pm
Powered by Dreamwidth Studios