Re: [RFR] Примечания к выпуску

[Sergey Alyoshin]

Михаил, спасибо за ваши усилия.

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

Layout файловой системы предлагаю перевести как раскладку файловой системы,
но не против и компоновки.

Re: [RFR] po-debconf://uif/ru.po

[Sergey Alyoshin]

On Wed, May 18, 2022 at 4:29 PM  wrote:
>
> В Ср, 18/05/2022 в 16:09 +0300, Sergey Alyoshin пишет:
> > Да, в кавычках лучше.
>
> Однако в оригинальном сообщении пункты выбора ведь не используются. И в
> первоначальном варианте перевода речь также шла не о названиях пунктов
> меню, а об их значениях.
> Я всё же считаю, что нам как переводчикам не стоит выдумывать то, чего
> нет в оригинале. Если уж и переделывать это сообщение с указанием
> пунктов меню, то следует делать это через предложение изменения шаблона
> сопровождающим пакета, а не в нашей песочнице.
>

Особой выдумки я не вижу, только небольшое дополнение для ясности.
В оригинале явное соответствие "workstation" (даже в кавычках) и
debian-edu-router:

"workstation" "debian-edu-router" "don't touch"

"Please choose whether the firewall should be configured now with a simple "
"\"workstation\" setup, given a specialized Debian Edu Router configuration, "
"or left unconfigured so that you can manually edit /etc/uif/uif.conf."

"Выберите настройку межсетевого экрана: рабочая станция для простой "
"конфигурации, маршрутизатор Debian Edu для специальной конфигурации или "
"оставьте без изменения, чтобы вы могли вручную отредактировать /etc/uif/"
"uif.conf."

Re: [RFR] po-debconf://uif/ru.po

[Sergey Alyoshin]

On Wed, May 18, 2022 at 3:57 PM  wrote:
>
> В Ср, 18/05/2022 в 11:06 +0300, Sergey Alyoshin пишет:
> > Он отмечен для перевода и мы его переводим. Я думаю лучше в этом меню
> > "маршрутизатор Debian Edu" вместо "маршрутизатор debian-edu".
>
> У других команд тоже то так, то эдак: fr перевели как "маршрутизатор
> debian-edu", а cs оставили без изменения.
>
> > Я предлагаю в пояснении сначала указывать пункт меню, а потом его
> > смысл.
> > "рабочая станция для конфигурации" (в переводе "рабочая станция для
> > простой конфигурации") означает, выбирайте пункт "рабочая станция"
> > для
> > "простой конфигурации".
>
> Так ведь здесь не пункты меню указаны, а лишь их расшифровка. Поэтому в
> оригинале "Debian Edu Router" и написано не так, как выше.
> Если считать их названиями пунктов меню, то их вообще следует поместить
> в кавычки.

Да, в кавычках лучше.

Re: [RFR] po-debconf://uif/ru.po

[Sergey Alyoshin]

Здравствуйте, Алексей

On Wed, May 18, 2022 at 4:10 AM  wrote:
>
> Здравствуйте, Сергей. Спасибо за ответ.
>
> В Вт, 17/05/2022 в 21:12 +0300, Sergey Alyoshin пишет:
> > > msgstr "маршрутизатор debian-edu"
>
> Насчёт этого пункта я в сомнениях. Конкретно здесь это выглядит как имя
> профиля, переводить которое, как мне кажется, не стоит.
> Возможно, следует вообще не пытаться переводить "Debian Edu Router" и
> компанию да оставить их как есть. Как думаете?

Он отмечен для перевода и мы его переводим. Я думаю лучше в этом меню
"маршрутизатор Debian Edu" вместо "маршрутизатор debian-edu".

> > > "Выберите настройку межсетевого экрана: рабочая станция для простой
> > "
> > > "конфигурации, маршрутизатор Debian Edu для специальной
> > конфигурации или "
> > > "оставьте без изменения, чтобы вы могли вручную отредактировать
> > /etc/uif/"
> >
>
> Здесь не соглашусь. Что значит "рабочая станция для конфигурации"?

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

> Основное "действующее лицо" здесь — это конфигурация, а не рабочая
> станция, и выбирается именно конфигурация, которая создана для рабочей
> станции.
> Насчёт "оставить без изменений": дело в том, что при чистой установке и
> выборе этого пункта упомянутый файл вообще не создаётся, что больше
> соответствует состоянию "ненастроенный", нежели "без изменений"; с
> другой стороны, при обновлении больше подходит ваш вариант. Пожалуй,
> "оставить без изменений" всё же наименьшее из зол, поэтому использую
> его — спасибо.

Именно, не создается и не изменяется, "без изменений".


> > 3. Last-Translator лучше указать на английском, так к вам будет проще
> > обращаться сопровождающему пакета.
> >
>
> Всё же, пожалуй, оставлю как есть — уж не обессудьте.
>

Re: [RFR] po-debconf://uif/ru.po

[Sergey Alyoshin]

Несколько замечаний:

1.
40c40
< msgstr "debian-edu-router"
---
> msgstr "маршрутизатор debian-edu"

2. Я думаю проще понять суть выбора, если элементы соответствуют
объяснению и указаны до объяснения:
56,58c56,58
< "Выберите, как настроить межсетевой экран: простая конфигурация для рабочей "
< "станции, специальная конфигурация для маршрутизатора Debian Edu, или же "
< "оставить его ненастроенным, чтобы вы могли вручную отредактировать /etc/uif/"
---
> "Выберите настройку межсетевого экрана: рабочая станция для простой "
> "конфигурации, маршрутизатор Debian Edu для специальной конфигурации или "
> "оставьте без изменения, чтобы вы могли вручную отредактировать /etc/uif/"

3. Last-Translator лучше указать на английском, так к вам будет проще
обращаться сопровождающему пакета.


On Mon, May 16, 2022 at 3:12 AM  wrote:
>
> Привет.
> Обновил перевод настроечных сообщений пакета uif — прошу проверить.
--- ru2.po	2022-05-17 20:53:08.169629610 +0300
+++ ru.po	2022-05-17 21:08:23.503281914 +0300
@@ -3,7 +3,7 @@
 # This file is distributed under the same license as the PACKAGE package.
 #
 # Yuri Kozlov , 2008.
-# Алексей Шилин , 2022.
+# Aleksej Shilin , 2022.
 #
 msgid ""
 msgstr ""
@@ -11,7 +11,7 @@
 "Report-Msgid-Bugs-To: u...@packages.debian.org\n"
 "POT-Creation-Date: 2022-05-06 19:27+0200\n"
 "PO-Revision-Date: 2022-05-16 02:30+0300\n"
-"Last-Translator: Алексей Шилин \n"
+"Last-Translator: Aleksej Shilin \n"
 "Language-Team: Russian \n"
 "Language: ru\n"
 "MIME-Version: 1.0\n"
@@ -37,7 +37,7 @@
 #. Choices
 #: ../templates:1001
 msgid "debian-edu-router"
-msgstr "debian-edu-router"
+msgstr "маршрутизатор debian-edu"
 
 #. Type: select
 #. Description
@@ -53,9 +53,9 @@
 "\"workstation\" setup, given a specialized Debian Edu Router configuration, "
 "or left unconfigured so that you can manually edit /etc/uif/uif.conf."
 msgstr ""
-"Выберите, как настроить межсетевой экран: простая конфигурация для рабочей "
-"станции, специальная конфигурация для маршрутизатора Debian Edu, или же "
-"оставить его ненастроенным, чтобы вы могли вручную отредактировать /etc/uif/"
+"Выберите настройку межсетевого экрана: рабочая станция для простой "
+"конфигурации, маршрутизатор Debian Edu для специальной конфигурации или "
+"оставьте без изменения, чтобы вы могли вручную отредактировать /etc/uif/"
 "uif.conf."
 
 #. Type: string

Re: lightweight mail list software

[Sergey Matveev]

Приветствую!

*** Hleb Valoshka [2021-03-28 13:32]:
>Учитывая, что софт для рассылок админить не приходилось, хочу спросить
>у сообщества, что больше подойдёт для этой задачи. Желательно с
>минимальной необходимостью в администрировании.

Я бы порекомендовал mlmmj: http://mlmmj.org/

* требует только интеграции с почтовым сервером -- админится без
  какого-либо web-интерфейса, который ещё надо как-то запускать. Всё
  (адреса разработчиков) в простых текстовых файлах
* одним touch control/... можно настраивать требования к тому, кто и как
  может писать в рассылку (надо ли подписываться или ещё чего)
* умеет VERP, не будет проблем с SPF
* по умолчанию не трогает Reply-To, да и вообще ничего не делает толком
  с заголовками, пока явно ему не будет сказано

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF


signature.asc
Description: PGP signature

Re: актуальный софт для инкрементального backup

[Sergey Spiridonov]

On Wed, 25 Nov 2020 17:27:31 +0200
Sohin Vyacheslav  wrote:

> Посоветуйте плз актуальный софт для удобного (в плане конфигурации) 
> инкрементального резервного копирования десятков, в перспективе сотен 
> серверов linux.

backuppc, но как у него с сотнями серверов будет, не знаю 

-- 
С уважением, Сергей Спиридонов

Re: [RFR] po://apt-listbugs/po/ru.po

[Sergey Alyoshin]

 Спасибо, Алексей.

On Mon, Nov 23, 2020 at 2:14 AM  wrote:
>
> Доперевёл (и кое-где поправил) apt-listbugs. Прошу проверить и
> высказать ваши замечания и комментарии.

Re: Новичок и Gtimelog

[Sergey Alyoshin]

Здравствуйте, Алексей

On Wed, Jul 22, 2020 at 10:43 PM Алексей Куновский  wrote:
>
> Здравствуйте. Я никогда ничего не сопровождал ранее и не участвовал в 
> свободных проектах, но очень хотелось бы попробовать. И тут очень кстати 
> подвернулась программа для учёта времени Gtimelog, которая не переведена на 
> русский язык
> https://i18n.debian.org/l10n-pkg-status/g/gtimelog.html

Сначала надо узнать не сделан ли уже перевод, особенное если перевод большой:

* Проверить в актуальной версии в официальном [2] репозитории проекта [2]

* Иногда переводы делают на различных web-платформах (transifex.com,
pootle) это должно быть указано на официальном сайте проекта

* Проверить в трекере ошибок (официальном проекта и пакета в
Debian/Ubuntu) не был ли предложен перевод

* Спросить разработчиков предлагали ли им перевод проекта

Понять какая система используется для перевода (локализации), это
может быть gettext, Qt QTranslator и пр.

* Система gettext, судя по файлам в пакете
/usr/share/locale/en/LC_MESSAGES/gtimelog.mo
/usr/share/locale/lt/LC_MESSAGES/gtimelog.mo

Кратко ознакомьтесь с gettext, какие инструменты есть для работы с ним.

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

Для gettext в результате надо создать файл gtimelog.po из файла
шаблона .pot (src/gtimelog/po/gtimelog.pot в репозитории проекта
gtimelog), чтобы получить /usr/share/locale/ru/LC_MESSAGES/gtimelog.mo

Перед началом перевода разрабатываемой версии следует обновить файл
шаблона .pot, чтобы он соответствовал текущим исходным текстам.

Также перевести некоторые строки для значка программы в меню и на
рабочем столе и, при желании, документацию (man и пр.).

Отправить перевод в систему отслеживания ошибок [3] или список
рассылки официального проекта и следить за его включением, исправлять
замечания.

Поддерживать перевод в актуальном состоянии для новых выпусков программы.


> Есть ли какая-нибудь инструкция для новичков в этом деле? Также на мой взгляд 
> строк в файле локализации несколько больше, чем в интерфейсе видно, а 
> контекст употребления их явно важен.

> Возможно ли без чтения всех исходников получить информацию о том, где и как 
> увидеть те строки, которые я переводить собрался?

Зачастую можно без исходных текстов. В файле перевода .po есть
информация о файле (или файлах) и строке исходного текста, где
используется данная строка.

Чтобы увидеть результат самый "простой" способ -- собрать
разрабатываемую версию программы. Для текущей версии в вашей системе
надо добавить файл /usr/share/locale/ru/LC_MESSAGES/gtimelog.mo.
Учтите, что в зависимости от версии программы оригинальные строки, а
следовательно и перевод отличаются, поэтому ваш перевод для текущей
версии программы не обязательно на 100% подойдёт к новой выпускаемой
версии. Но так можно сделать для своего обучения процессу.


[1] https://gtimelog.org/
[2] https://github.com/gtimelog/gtimelog
[3] https://github.com/gtimelog/gtimelog/issues

Re: Публикация GPG-ключей

[Sergey Matveev]

*** Tim Sattarov [2020-06-14 22:20]:
>А вот кстати, что благородные доны думают про keybase.io?

Лично я особо ничего не могу про него сказать, так как с ходу даже не
помнил что именно это за ресурс. Ну ещё один способ получить ключ, с
которым связаны всякие сторонние ресурсы. Не знаю что сказать :-). Не
все захотят разглашать о себе свои связи между различными ресурсами, кто
не против, то почему бы и нет. Но лично я не припомню чтобы оттуда
загружал чьи-либо публичные ключи. Да и свой загружать туда смысла нет,
ибо я мало на каких ресурсах имею имею учётные записи, поэтому связанных
identities, кроме личного домена и подобных, не будет.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF


signature.asc
Description: PGP signature

Re: Публикация GPG-ключей

[Sergey Matveev]

ыдают ошибки и, возможно у
меня какая-нибудь корявая версия dirmngr, но зачастую помогает только
killall dirmngr и снова перезапрос ключа с KS-ов.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF


signature.asc
Description: PGP signature

Re: Публикация GPG-ключей

[Sergey Matveev]

*** Dmitry Alexandrov [2020-06-14 14:48]:
>(Да и вообще, мне казалось, что SRV указатели типа 
>_openpgpkey._tcp.stargrave.org из стандарта выкинули, не?)

Похоже и "wkd." нету тоже теперь и вместо него "openpgpkey.":
https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-09
https://wiki.gnupg.org/WKDHosting

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF


signature.asc
Description: PGP signature

Re: Публикация GPG-ключей

[Sergey Matveev]

*** Dmitry Alexandrov [2020-06-14 14:48]:
>Да вот чтобы далеко не ходить — возьмем хотя бы вас.  Откуда я могу ваш ключ 
>получить без проблем, как не с кейсервера?  Из WKD?  А вот шиш: WKD, как вы 
>совершенно справедливо пишете, опирается X.509, а ваша директория подписана 
>самопальным сертификатом:

Keyserver -- ничем не защищённый источник (возможно PKI). WKD с
недоверенным trust anchor-ом (как в вашем случае): точно такой же
недоверенный источник. И в том и в другом случае вы наверняка будете
использовать WoT для решения можно ли доверять полученному ключу. Плюс
из DANE можно достать ещё попробовать, который возможно "защищён"
DNSSEC-ом, и точно также всё равно потребует WoT например.

Всё это методы получения ключа, не более. Некоторые дополнительно могут
предоставлять какие-то trust anchor-ы от которых вы *возможно* сможете
отталкиваться (PKI (CA для TLS, root в DNSSEC)).

Keyserver не вариант: я не контролирую что там за ключ, какие подписи на
нём -- любой может там поставить какую-нибудь подпись и загрузить на
сервер. А мне не хочется отвечать за мусор там расположенный. Не говоря
про загрузку ключей с такими же UID-ами как и у меня: конечному
пользователю, пытающемуся получить мой ключ, это только геморрой. А
DANE, WKD -- это то, что под моим контролем.

>(Да и вообще, мне казалось, что SRV указатели типа 
>_openpgpkey._tcp.stargrave.org из стандарта выкинули, не?)

Надо будет посмотреть. Если выкинули, то уберу за ненадобностью,
поднимал то давно.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF


signature.asc
Description: PGP signature

Re: Публикация GPG-ключей

[Sergey Matveev]

*** Dmitry Alexandrov [2020-06-14 08:54]:
>GPG по-умолчанию WKD для retrievingʼа¹ вполне себе использует.  В том числе, 
>емнип, и в Дебиане.

На тему разных вариантов получения ключей я как-то статью написал:
https://www.opennet.ru/tips/2986_pgp_gnupg_key_sign.shtml
>
>Вернер Кох (мэйнтейнер GPG), когда весь этот бардак только начинался, мне 
>вообще сообщил, что сервера ключей не нужны, и должны умереть как класс.

Тоже поддерживаю эту идею что keyserver-а не нужны как класс.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF


signature.asc
Description: PGP signature

Re: Debian 10, SSD, full disk encryption

[Sergey Matveev]

*** Ihor Antonov [2020-05-26 11:54]:
>В догонку - у меня есть пара серверов с 
>1 Гб оперативки, на них ZFS, все работает хорошо уже больше двух лет.

Подтверждаю! И у меня тоже есть машины с 1GB RAM с ZFS-ом везде
(хранилища и root), которым по 3-4 года -- работают без нареканий и
проблем.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: Debian 10, SSD, full disk encryption

[Sergey Matveev]

*** sergio [2020-05-26 17:51]:
>Нет, ТRIМ говорят исключительно для облегчения работы GC, а на Wear
>leveling влиять возможности нет.

Тут я не силён, но считал что: на wear leveling оно не влияет -- это
безусловно, однако знания о неиспользуемых страницах SSD (те, которые ОС
пометила TRIM-ом как "свободное место") может быть использовано
контроллером SSD для их переиспользования вместо уже изношенных страниц.
SSD, опять же, насколько слышал, имеют какой-то запас резервных блоков,
которые заменят изношенные. Когда их запас подойдёт к концу, то при
попытке записи в изношенных (а других же и нет) -- будет выдаваться
ошибка. В случае же, когда резервные иссякли, но ещё есть штатно
доступные свободные -- они прозрачно могут быть использованы. Свободное
место на диске (помеченное TRIM-ом) как-бы приравнивается к доступным
резервным блокам, что существенно может продлить работу с накопителем,
если он не забивается битком. Именно поэтому и есть же рекомендация о
том, что можно оставлять неиспользуемым место на SSD для резерва (хоть
партицию выделить для резервивания места и не трогать её вообще).

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: Debian 10, SSD, full disk encryption

[Sergey Matveev]

*** Maksim Dmitrichenko [2020-05-26 17:37]:
>Мне всё-таки кажется, что ZFS на лэптопе с одним диском - это overkill.

А я уверен что нет. Живу с ZFS-ом уже много лет на ноутбуке (сначала 4GB
RAM, теперь 8GB) и не соглашусь по другому.
http://www.stargrave.org/ZFS-proscons.html

>Ейный драйвер и оперативки хавает больше

Для кэширования, всё верно, ибо оно эффективно. Когда надо, то память
оно освобождает (ну как минимум в FreeBSD).

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: Fwd: Новая версия российского дистрибутива Astra Linux Common Edition

[Sergey B Kirpichev]

Дебиановцев к попилам все-равно не пропустят, так чего переживать от
художеств очередного "российского дистрибутива"?  Пусть уж ваши
жаба с гадюкой сами разбираются...

Re: Debian 10, SSD, full disk encryption

[Sergey Matveev]

*** Maksim Dmitrichenko [2020-05-23 01:47]:
>2) А что собственно с TRIM? Почитал какой-то flame war, что дескать TRIM
>уменьшает безопасность шифрования. Что, прям так сильно бьет?

TRIM это просто утечка знаний/информации о том что вы там что-то у себя
удаляется, а также конкретные места где вы это что-то удалили. Если
злоумышленник, видя ваш зашифрованный диск (как? другой вопрос),
отправил вам файл по почте, файл к вам упал и сохранился на диске: он
видит изменение какого-то блока (+плюс блоки метаинформации). А когда вы
удалили файл, то он видит, что именно этот блок снова стал пустым и он с
высокой долей вероятностью может сказать что файл удалён (или переписан,
если это CoW ФС типа ZFS или btrfs).

В общем, утечка метаинформации есть и тут уж каждый сам решает готов он
на такую жертву пойти или нет. Лично мне кажется, что преобладающему
большинству пользователей будет пофиг на подобное. Поэтому смело можно
(и нужно!) использовать TRIM.

Кстати, в native ZFS шифровании точно такая же проблема: подобная
метаинформация тоже утекает злоумышленнику (как и кол-во используемого
места например). В этой рассылке уже как-то обсуждался native ZFS
encryption vs ZFS over LUKS/whatever. В принципе, LUKS/whatever (даже с
TRIM) более безопасен, но тоже из серии сильно гипотетически
теоретических атак на которые на практике даже внимания обращать не стоит.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: Почтовый клиент и gmail

[Sergey Matveev]

*** ugoday [2020-04-21 11:56]:
>https://www.djcbsoftware.nl/code/mu/mu4e.html

Тоже могу порекомендовать этот софт! Использую с ~20 GiB почты и Mutt-ом.
Шустро индексирует, хорошо ищет.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: Discourse

[Sergey B Kirpichev]

On Sun, Apr 12, 2020 at 11:03:54AM +0300, Pavel Volkov wrote:
> организации полноценного модерирования.

Debian SJW^WAnti-Harassment^W^WCommunity Team джва года это ждали!11

Re: Прошу помощи в bash-скрипт - кавычки

[Sergey Matveev]

*** Victor Wagner [2020-03-11 14:50]:
>Просто перл надо ВЫУЧИТЬ. В нем есть все, что есть в awk, sed и tr, и
>многое-многое другое. А то приходят люди с визуалбейсковским
>бэкграундом и начинают текст обрабатывать на perl с помощью функций
>substr и index. 

Полностью поддерживаю! Плюс это всё зачастую в Perl ещё можно и в
one-liner писать, заменяя sed/tr/whatever. Плюс Perl везде одинаков (+-)
и его скрипты будут одинаково работать как под BSD, так и под GNU
системами, в отличии от sed/grep/awk, GNU версии которых отличаются от
BSD ощутимо. Плюс из коробки, без дополнительных модулей, в нём и с
файлами и с сокетами можно вполне себе работать, что тоже может
пригодиться. Плюс он относительно легковесен (учитывая кучу возможностей
в его единственном бинарнике!) и я встречал из коробки его даже в
OpenWRT каком-нибудь (ну такие вот дистрибутивы с ним попадались), да и
зачастую он в любом дистрибутиве идёт из коробки, в отличии от
Python/Lua/Ruby/whatever. А нежелание людей изучить ровно этот один
инструмент мне не понятны, тем более, когда при этом выбирают кучу
других, зачастую тоже их не зная, да ещё и страдая от несовместимости
реализаций (bsd vs gnu).

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF


signature.asc
Description: PGP signature

Re: выравнивание раздела: кому верить, fdisk или parted?

[Sergey Spiridonov]

On Fri, 13 Dec 2019 00:58:55 +0300
"Andrey Jr. Melnikov"  wrote:

> > Во-первых размер странный, не находишь? Почему он не дотягивает один
> > блок в 512 байт до 65536? Если это число из железа, то либо
> > железо сообщает неправильный размер, либо драйвер его
> > неправильно интерпретирует. А значит его можно подправить в
> > драйвере.  
> Нет, не странный. Это дело двух USB железок какой поток данных они
> будут гонять.

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

А значение, между тем, более чем странное (либо его интерпретация). И
оно может использоваться не только в партед.


>  [...]  
> Потому, что parted - гендерно-нейтральная поделка.

Ну допустим и что дальше? Может быть баг-репорты слать не надо? Или 
пользоваться запрещено?


> Вот тебе с моей машины:
> 
> # grep . /sys/block/sd*/queue/optimal_io_size
> /sys/block/sda/queue/optimal_io_size:0

... 
> Изволите перестать писать на диски? Или писать по 0 байт?

Если бы я знал все ответы, не пришёл бы сюда за советом.

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

Глянь что у тебя в

cat /sys/block/sd*/queue/minimum_io_size

У меня там стоит 512 или 4096.


>  А те, кто может вотнуть
> неформатированный блочный девайс - обладают знаниями про fdsik. А
> гнутый parted он опционален, в базовой поставке его нет.

А раз он опционален и в базовой поставке его нет то... Что? Баги
репортить и фиксить не надо? Пользоваться им запрещено? Ну тогда это
надо прописать в документации Дебиана. "Не пользуйтесь ничем, если оно
не в базовой поставке".


> Угадал. То, что ты не знаешь, что делашь - я сразу написал. И то, что
> ты не можешь внятно описать проблему - тоже.
 
Ну уж как могу. За это прошу простить, если чем-то кого-то обидел.

-- 
С уважением, Сергей Спиридонов

Re: выравнивание раздела: кому верить, fdisk или parted?

[Sergey Spiridonov]

On Tue, 10 Dec 2019 17:19:01 +0300
"Andrey Jr. Melnikov"  wrote:

> Sergey Spiridonov  wrote:
> > В Thu, 5 Dec 2019 17:38:02 +0300 (MSK)
> > yuri.nefe...@gmail.com пишет:  
> 
> > >   Боюсь, что баг-репорт не поможет, хотя можете попробовать.  
> 
> > Ну да, они скажут что виноват драйвер кернела, который
> > неправильно понимает УСБ-Контроллер... Наверное надо куда-то в
> > кернел писать?  
> 
> Лучше в спортлото. Цифирка, которая в optimal_io - это к USB UASP
> относится. К твоему диску - нет.

Не понял тебя. В соответствующий драйвер можно USB UASP внести
изменение, и он будет поправлять optimal_io, в зависимости от усб
идентификатора, то есть возвращать либо 0 либо 33554432, вместо
33553920, как сейчас.

> > Я согласен уже на всё, но какой брать отступ? Какие для этого есть
> > правила???  
> 
> Никакой.

В смысле 0?
 
> > Я потом раздел шифрую люксом, это как-то влияет?  
> Да, всё тормозит на шифровании.

Я читал что шифрование само по себе не должно добавлять много тормозов,
если ЦПУ поддерживает аппаратное ускорение  AES. По крайней мере, так
пишут собаководы [1]. И это для SSD! Для шпинделя должно быть вообще
незаметно, ведь поток данных в разы меньше. Сам проверял это записывая
большой файл на вышеупомянутую зашифрованную шпиндельную Тошибу.
Скорость записи в 260МБ/с меня вполне устроила. При записи тучи мелких
файлов скорость записи падает да 10-20МБ/с, но можно ли винить в этом
шифрование, я пока не знаю, пока возможности сравнить нет.

https://www.phoronix.com/scan.php?page=article=2019-linux-encrypt=1

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

> > Спасибо за помощь. Блин, 2019 год, а в линуксе проблема разбить
> > винт. Куда катится мир?  
> 
> Нет проблем в 2019 году с винтами. Есть проблемы с теми, кто это
> пытается делать не понимая.

Ну ОК, будем считать что я не понимаю. В конце концов это недалеко от
правды.

...


> Поэтому, для обычного HDD все эти сказки про скорости и выравнивания -
> обычный маркетинговый fud. Для SSD по большей части тоже, т.к.
> контроллеры умнеют, а все веселые картинки про "драматичесике
> изменения скорости" видны только из далекого прошлого. А ведь в
> 3D-NAND уже размер блока 16K+2208 spare, но что-то никто не бегает с
> align 16K и размером сектора в 16k вместо 4k.

То есть по-твоему выравнивание вообще не играют значения, если я
правильно понял. ОК, спасибо за совет.

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

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

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

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

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

Re: непонятная ошибка ядра в дмесг

[Sergey Spiridonov]

Привет

В Sun, 8 Dec 2019 10:22:27 +0300
Иван Лох  пишет:

> On Sun, Dec 08, 2019 at 04:29:05AM +0100, Sergey Spiridonov wrote:
> > Привет всем
> > 
> > Не могу нагуглить, что означает это ошибка. Буду благодарен
> > если кто-то подскажет. Похоже что связано с сетью, может ли это
> > быть проблема с сетевой картой? Сетевая карта встроенная в ASRock
> > Z97 Extreme9  
> 
> Поскольку ошибка произошла скорее всего при вызове
> ip6tables-nft-restore, то я бы посмотрел, что именно он restore) 

Ага, похоже в это время стартовал shorewall6, надо было сразу в dmesg
посмотеть...

Dec  6 05:01:57 believer shorewall[2117]: ip6tables-restore v1.8.2 (nf_tables): 
unknown option "--icmpv6-type"
Dec  6 05:01:57 believer shorewall[2117]: Error occurred at line: 76
Dec  6 05:01:57 believer shorewall[2117]: Try `ip6tables-restore -h' or 
'ip6tables-restore --help' for more information.
Dec  6 05:01:57 believer shorewall[2117]:ERROR: iptables-restore Failed. 
Input is in /var/lib/shorewall6/.ip6tables-restore-input
Dec  6 05:01:57 believer root: ERROR:Shorewall6 start failed
Dec  6 05:01:58 believer shorewall[2117]: Preparing ip6tables-restore input...
Dec  6 05:01:58 believer shorewall[2117]:
Running /sbin/ip6tables-restore...

Наверное версия iptables и ядра не совместимы из-за того что ядро у
меня из бэкпортс. Пока не могу перегружаться, завтра проверю эту теорию.
-- 
C уважением, Сергей Спиридонов

Re: выравнивание раздела: кому верить, fdisk или parted?

[Sergey Spiridonov]

On Fri, 6 Dec 2019 12:51:18 +0300
sergio  wrote:

> On 06/12/2019 12:24, Sergey Spiridonov wrote:
> 
> > Хорошая идея на первый взгляд. Но почему-то fdisk всё равно делает
> > отступ. Может быть в этом есть какой-то сокрытый смысл?  
> 
> А в вашем представлении сама таблица разделов места не занимает?

А, точно! Попробую без таблицы.

-- 
С уважением, Сергей Спиридонов

Re: выравнивание раздела: кому верить, fdisk или parted?

[Sergey Spiridonov]

On Fri, 6 Dec 2019 12:12:10 +0300 (MSK)
yuri.nefe...@gmail.com wrote:


>   Мне кажется, 2048s для начала раздела довольно оптимальный
>   выбор. Не вижу причин брать больший отступ.

А ведь это ещё не всё. Ведь само ядро использует это неверное значение
optimal_io_size  для ввода-вывода!

Надо, выходит, всё равно править драйвер? Сейчас проверил скорость
копирования - 17 МБ/с при подключённом через SATA диске. Через УСБ -
ещё в два раза меньше.

-- 
С уважением, Сергей Спиридонов

Re: выравнивание раздела: кому верить, fdisk или parted?

[Sergey Spiridonov]

Привет

On Fri, 6 Dec 2019 08:08:50 +0300
sergio  wrote:

> On 06/12/2019 07:16, Sergey Spiridonov wrote:
> 
> > Какой отступ лучше брать?  
> 
> Лучше не напрягать мозг и не делать ни отступов ни таблиц разделов.

Хорошая идея на первый взгляд. Но почему-то fdisk всё равно делает
отступ. Может быть в этом есть какой-то сокрытый смысл?

-- 
С уважением, Сергей Спиридонов

Re: выравнивание раздела: кому верить, fdisk или parted?

[Sergey Spiridonov]

В Fri, 6 Dec 2019 04:23:05 +0100
Sergey Spiridonov  пишет:

> Или лучше достать диск, разбить на разделы и вставить обратно? А не
> будет ли при этом потом проблем с УСБ контроллером?

Вытащил диск, подключил напрямую. Теперь 

# cat /sys/block/sdd/queue/optimal_io_size
0

# cat /sys/block/sdd/queue/minimum_io_size
4096

Какой отступ лучше брать?

-- 
С уважением, Сергей Спиридонов

Re: выравнивание раздела: кому верить, fdisk или parted?

[Sergey Spiridonov]

В Thu, 5 Dec 2019 17:38:02 +0300 (MSK)
yuri.nefe...@gmail.com пишет:

>   Боюсь, что баг-репорт не поможет, хотя можете попробовать.

Ну да, они скажут что виноват драйвер кернела, который
неправильно понимает УСБ-Контроллер... Наверное надо куда-то в кернел
писать?

 
>   Одно из возможных объяснений:
>   ICY BOX IB-366StU3+B - это ведь enclosure for USB 3.0?

Да

>   Если контролер этой штуки прописывает optimal_io_size
>   как 33553920 (65535*512) то выравнивается именно на эту величину.

Угу, по крайней мере кернел сообщает эту цифру. 

# cat   /sys/block/sdd/queue/optimal_io_size
33553920, что и даёт искомые 65535 при делении на 512.

# cat /sys/block/sdd/queue/minimum_io_size
4096

>   Так что остается один путь, сделать разбиение вручную.

Я согласен уже на всё, но какой брать отступ? Какие для этого есть
правила???

Например, если я правильно понял, fdisk отступил 2048 логических
сектора по 512 байт. Это хорошо? Это нормально? Или лучше отступить
65536? Может ошибка контроллера - сообщать 65535 вместо 65536. Или это
неправильная интерпретация стандарта, одни считают от 0, другие от 1?

Или лучше достать диск, разбить на разделы и вставить обратно? А не
будет ли при этом потом проблем с УСБ контроллером?

Я потом раздел шифрую люксом, это как-то влияет?

Спасибо за помощь. Блин, 2019 год, а в линуксе проблема разбить винт.
Куда катится мир?
-- 
С уважением, Сергей Спиридонов

Re: выравнивание раздела: кому верить, fdisk или parted?

[Sergey Spiridonov]

В Wed, 4 Dec 2019 07:31:26 +0300 (MSK)
yuri.nefe...@gmail.com пишет:

>У parted есть опция unit
>(parted) print unit "s"
> 
>Посмотрите, что она выдаст.

В общем, что с выравниванием по цилиндру, что с "оптимальным"
выравниванием, режет физический сектор на куски.

Почему - непонятно. При это  fdisk делает выравнивает на 4096 байт.
Наверное надо слать багрепорт на партед?


# parted -a cyl /dev/sdd
GNU Parted 3.2
Using /dev/sdd
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mkpart primary 0% 100%
(parted) print unit  "s"
Model: ICY BOX IB-366StU3+B (scsi)
Disk /dev/sdd: 14000519643136B
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End  Size File system  Name
Flags 1  17408B  14000519626239B  14000519608832B
primary

(parted) print
Model: ICY BOX IB-366StU3+B (scsi)
Disk /dev/sdd: 27344764928s
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start  End   Size  File system  Name Flags
 1  34s27344764894s  27344764861s   primary



# parted -a opt /dev/sdd
GNU Parted 3.2
Using /dev/sdd
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) rm
1 (parted) mkpart primary 0% 100%
(parted) print unit
"s" Model: ICY BOX IB-366StU3+B (scsi)
Disk /dev/sdd: 14,0TB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End SizeFile system  Name Flags
 1  33,6MB  14,0TB  14,0TB   primary

(parted)
print Model: ICY BOX IB-366StU3+B (scsi)
Disk /dev/sdd: 27344764928s
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End   Size  File system  Name Flags
 1  65535s  27344740889s  27344675355s   primary

-- 
С уважением, Сергей Спиридонов

выравнивание раздела: кому верить, fdisk или parted?

[Sergey Spiridonov]

Всем привет

создаю раздел на винчестере

# parted -a opt /dev/sdd
(parted) mkpart primary 0% 100%

(parted) print 

Number  Start   End SizeFile system  Name Flags
 1  33,6MB  14,0TB  14,0TB   primary

проверяем выравнивание

(parted) align-check opt
1 1 aligned

теперь с помощью fdisk:

# fdisk /dev/sdd

: p

Disk /dev/sdd: 12,8 TiB, 14000519643136 bytes, 27344764928 sectors
Disk model: IB-366StU3+B
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: 82DD924B-BF0E-40FF-9037-1FD4E7307D26

Device Start End Sectors  Size Type
/dev/sdd1  65535 27344740889 27344675355 12,8T Linux filesystem

Partition 1 does not start on physical sector boundary.


Кто из них врёт?
-- 
С уважением, Сергей Спиридонов

Re: Не просыпается видеокарта

[Sergey Spiridonov]

Привет

On Mon, 29 Jul 2019 07:21:26 +0300
Victor Wagner  wrote:

> Тут после апгрейда на buster обнаружил на
> двух компьютерах следующий эффект -
> иногда после выключения экрана по таймауту компьютер не реагирует на
> нажатие клавиши и не включает экран. Иногда - нет и все просыпается
> нормально. Закономерности не заметил.

У меня такое же происходит на нвидия на десктопе иногда.

> Помогает нажатие Сtrl-Alt-F1 и переключение на текстовую консоль.
> После этого нажимаю Alt-F7 и на экране появляется надпись
> "Сессия заблокирована, вы будете перенаправлены на диалог
> разблокировки через несколько секунд". Что и происходит.

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

Помогет преключение на ctrl-alt-f1, а потом случайное
тыкание между ctrk-alt-f8, ctrl-alt-f7. Или это
https://askubuntu.com/questions/557833/how-to-unlock-locked-session

Причём на десктопе с dualseat с нвидия началось ещё до бустера, а с
бустером вроде прекратилось. А на десктопе с нвидия без dualseat с
бутером усилилось.

Наверняка это всё проделки системд.

-- 
С уважением, Сергей Спиридонов

Re: «Единственный мне известный логичный язык - это Tcl»

[Sergey B Kirpichev]

On Tue, Oct 01, 2019 at 12:41:00AM +0300, Dmitry Alexandrov wrote:
> Вы так говорите, будто в «Схеме» специальную форму от функции отличить можно.

Ну вообще-то - можно.  Как правило, специальная форма - специально
вычисляется.  Например:
scheme@(guile-user)> (if #f (/ 1 0) 1)
$2 = 1
scheme@(guile-user)> (+ #f (/ 1 0) 1)
:7:6: Throw to key `numerical-overflow' with args `("/" 
"Numerical overflow" #f #f)'.

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.

Re: Устанавливается посторонний софт по умолчанию

[Sergey B Kirpichev]

On Thu, Jul 11, 2019 at 09:21:19AM +0500, Лев Аржанов wrote:
>Население Японии составляет 126 млн человек. России — 146 млн. Думаю, что
>с точки зрения разработчиков русский язык не менее и не более
>экзотический, чем японский.

А если учесть, что соотношение разработчиков (по крайней
мере DD) из этих стран - совершенно обратное, причем различается
еще в 4 раза...

Fwd: rms в России

[Sergey Matveev]

- Forwarded message from Ineiev -

Date: Tue, 11 Jun 2019 05:20:04 +
From: Ineiev 
To: gnupg...@gnupg.org
Subject: [gnupg-ru] rms в России
Message-ID: <20190611052004.GA2231@desdichado>

Многоуважаемые подписчики!

В конце августа rms будет в Санкт-Петербурге; есть возможность
пригласить его выступить в других частях России.

Для этого ему нужно будет предоставить (0) помещение для лекции,
(1) возможность пригласить достаточное количество слушателей,
(2) оплату переезда из СПб.

Приглашение следует согласовать с ним до конца июня.

Благодарю за внимание!

P.S. прошу переслать это объявление в другие рассылки и форумы,
которым это может быть интересно.



___
Gnupg-ru mailing list
gnupg...@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-ru


- End forwarded message -

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF


signature.asc
Description: PGP signature

Re: крик души :)

[Sergey B Kirpichev]

On Mon, May 20, 2019 at 07:42:10PM +0100, Stanislav Maslovski wrote:
> Меня упорно не покидает ощущение, что с каждым новым релизом
> качество софта в Debian деградирует.
> 
> Что с этим делать, граждане? Так как это, похоже, нынче глобальный
> тренд...

С ощущениями посоветовать сложно.  Может валерианку?

Не хочите Debian - попробуете не-Debian:
http://www.gnu.org/software/guix/

Re: что случилось с дебиан вики? debian wiki

[Sergey Spiridonov]

В Fri, 22 Mar 2019 16:13:19 +0300
Dmitry Alexandrov <321...@gmail.com> пишет:

> Sergey Spiridonov  wrote:
> > пару недель не могу зайти в Дебиановскую вики, когда открываю

...

> > Что случилось?  
> 
> Ну, очевидно, вас там забанили по адресу.  Пишите на
> .  Для большей информативности еще
> можно проверить, касается ли это также вашего IPv6-адреса.

Да, написал в debian-ad...@lists.debian.org, получил любопытный ответ.
Оказывается меня забанили потому что я пытался зарегистрироваться в
вики на мой почтовый адрес - sena at s73.work.

Домен верхнего уровня (TLD) work у них внесён в чёрный список, и у них
скрипт автоматом банит все ай-пи адреса, с которых пытаются
зарегистрироваться с почтовым адресом в домене верхнего уровня work.

И мне посоветовали попробовать другой почтовый вдрес.

Вот теперь думаю, как бы им повежливей написать, что они неправы?
-- 
С уважением, Сергей Спиридонов

Re: что случилось с дебиан вики? debian wiki

[Sergey Spiridonov]

В Fri, 22 Mar 2019 22:03:59 +0300
sergio  пишет:

> On 22/03/2019 13:31, Sergey Spiridonov wrote:
> 
> > $ sudo tcptraceroute wiki.debian.org 443  
> 
> 
> А теперь curl https://wiki.debian.org


$ curl https://wiki.debian.org

403 Forbidden
Forbidden
pYou are not allowed to access this!/p

Re: Генерация pool-based репозиториев

[Sergey Spiridonov]

Привет

On Tue, 26 Feb 2019 12:24:48 +0300
Victor Wagner  wrote:


> Коллеги,
> 
> А чем в наше время можно генерировать pool-based репозитории, КРОМЕ
> reprepro?

reprepro меня не устроил потому что

1. не может добавить один и тот же пакет к нескольким дистрибутивам
2. не может добавить несколько версий одного пакета

Я пользуюсь freight. Мои потребности полностью удовлетворяет. Им можно
пользоваться вообще с командной строки

https://github.com/freight-team/freight

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

На эту папку натравливаю 20-строчный скриптик (могу прислать), которые
вызывает freight с параметром соответствующим имени папки - тот
генерирует/обновляет локальный репозиторий и потом с помощью rsync
закидываю на сервер. 

rsync нужно использовать в два прохода для репозиториев, типа такого


rsync --password-file=$HOME/rsync.repo.secret -aH --numeric-ids \
  --exclude 'Packages*' --exclude 'Sources*' --exclude 'Release*' \
  --exclude=InRelease --include='i18n/by-hash/**'
  --exclude='i18n/*' \
  --exclude 'ls-lR*'  ./freight/cache/* \
  u...@repo.mooo.com::repo/dir

rsync --password-file=$HOME/rsync.repo.secret -aH --numeric-ids \
  --delete ./freight/cache/* \
  u...@repo.mooo.com::repo/dir


-- 
Best regards, Sergey Spiridonov

Re: что случилось с дебиан вики? debian wiki

[Sergey Spiridonov]

On Thu, 14 Mar 2019 18:17:43 +0300
sergio  wrote:

> tcptraceroute в студию

$ sudo tcptraceroute wiki.debian.org 443
Selected device br0, address 192.168.12.145, port 34701 for outgoing
packets Tracing the path to wiki.debian.org (82.195.75.112) on TCP port
443 (https), 30 hops max 1  192.168.12.1  0.333 ms  0.295 ms  0.290 ms
 2  192.168.42.1  0.470 ms  0.453 ms  0.474 ms
 3  62.155.241.178  6.913 ms  7.011 ms  7.669 ms
 4  217.239.44.22  10.861 ms  17.224 ms  11.901 ms
 5  te-0-0-2-686.core1.fra1.ix.f.man-da.net (87.190.232.204)  11.475
ms  11.676 ms  11.728 ms 6  te-0-0-4-0.core1.rz.hda.da.man-da.net
(82.195.67.178)  12.072 ms  11.603 ms  11.909 ms 7
te-2-0-0-0.cust2.rz.hda.da.man-da.net (82.195.80.10)  12.091 ms  11.772
ms  11.858 ms 8  gw-ext.manda.debian.org (82.195.78.118)  12.103 ms
11.921 ms  12.063 ms 9  wilder.debian.org (82.195.75.112) [open]
12.304 ms  12.599 ms  12.175 ms

li...@mail.ru wrote:

> Куки удаляли, кэш чистили?

Да и пробовал с разных компьютеров

-- 
Best regards, Sergey Spiridonov

Re: [RFR] po://apt/po/ru.po

[Sergey Alyoshin]

On Fri, Feb 8, 2019 at 1:02 PM Galina Anikina  wrote:
>
> В Чт, 07/02/2019 в 19:57 +0300, Алексей Шилин пишет:
> > Привет.
> >
> > Подоспела новая порция изменений в переводе APT. Прошу проверить.
>
> Прочитала ru.po.diff.
>
> В конце
>
>  #: cmdline/apt.cc
>  msgid "remove packages"
>
> не надо переводить?
>

Нет, это формат .diff (один из), в нем показаны сделанные _изменения_:
строки начинающиеся с '+' добавлены, а с '-' удалены.

Re: dpkg --help

[Sergey Alyoshin]

On Mon, Oct 15, 2018 at 9:54 AM Galina Anikina  wrote:
>
> При выводе dpkg --help увидела смесь английского и русского (Локаль
> глобально - LANG=ru_RU.UTF-8)
> А если файл ru.po переведён, то возникает логический вопрос - откуда
> здесь взялся кусок текста - не переведённый на русский?

Или файл .po не актуальный, или или эти строки в исходном коде не отмечены
"функциями" для перевода и не попали в .po.

Re: po4a-gettextize_адресует к groff

[Sergey Alyoshin]

On Sun, Oct 14, 2018 at 8:18 AM Galina Anikina  wrote:
>
> Подскажите пожалуйста -
> при попытке "перегнать" из man-а в .po выдало следующее-
> $ po4a-gettextize -f man -M UTF-8 --debug --master grep.1 --po
> grep_1_man_eng.po
> grep.1:2: (po4a::man)
>   В этой странице определяется новый макрос с помощью «.de».
> Данная команда не поддерживается, так как po4a не является полноценным
> анализатором groff.
>
> То есть значит надо воспользоваться какими то программами, входящими в
> комплект пакета "groff"?
> Может кто знает?

Насколько я вижу, man в grep не переведён ни на один язык. Поэтому
сначала надо узнать, что сделать чтобы усилия не пропали зря.
Спросить можно у команды https://translationproject.org/team/ru.html

В grep оригинал man на texinfo, который po4a должен понимать.

Re: ddpt вопросы

[Sergey Alyoshin]

On Tue, Oct 9, 2018 at 9:51 PM Galina Anikina  wrote:
>
> Подскажите пожалуйста.
> Зарегистрировалась на https://ddtp2.debian.net/ddtss/index.cgi/ru
> Написали, что пришлют письмо для подтверждения - тишина...
> Прошёл день
> Я что-то делаю не так?
> Войти не могу - не активирован аккаунт ещё. :-(((

Проверил, письмо получил (в спам).

Re: apt описание на DDTP вычитка_через apt show apt

[Sergey Alyoshin]

On Tue, Oct 9, 2018 at 10:19 PM Galina Anikina  wrote:
>
> Касательно описания APT, которое выдаёт
>
> apt show apt (то есть это описание располагается на DDTP)
>
> Надо бы чуть подправить
>
> Включены следующие инструменты:
>
> было
>   * apt-get для получения пакетов и информации о них из
> достоверных источников и для установки, обновления и удаления
> пакетов вместе с их зависимостями
>
> может так -
>   * apt-get для получения пакетов и информации о них из
> достоверных источников, и для установки, обновления, удаления
> пакетов вместе с их зависимостями

Как насчёт:

   * apt-get для получения пакетов и информации о них из
 достоверных источников, для установки, обновления и удаления
 пакетов вместе с их зависимостями

> Поставить запятую перед "и", хотя в 99 процентах случаев перед "и" не
> ставится запятая, здесь всё же надо поставить, так как одна часть мысли
> закончилась и начинается идти речь о второй части.
> И далее убрать другую "и" и поставить там запятую.
>
>
>   * apt-cache для запроса доступной информации об установленных и
> доступных для установки пакетов
>
> Здесь дважды повторяется слова с корнем "установ*"
>
> Может так -
>   * apt-cache для запроса доступной информации об уже меющихся пакетах
> в системе и
> доступных для установки пакетов

Думаю в этом месте лучше техническая ясность, поэтому оставить как есть.

> было
>   * apt-key в качестве интерфейса для управления ключами для
> проверки ключей аутентификации
>
> может так -
>   * apt-key в качестве интерфейса управления ключами, проверки их
> подлинности

   * apt-key в качестве интерфейса управления ключами и проверки их
 подлинности

> Это связано с тем, что здесь дважды используется "для" и дважды "ключи"

Re: for_DDTP_devscript_ledgersmb_libxfce4util7

[Sergey Alyoshin]

Почему не через web-интерфейс?

Re: Сервер DDTP работает

[Sergey Alyoshin]

On Thu, Oct 4, 2018 at 1:02 PM Galina Anikina  wrote:
>
> В Вт, 02/10/2018 в 12:44 +0300, Sergey Alyoshin пишет:
> > 35 переводов описаний пакетов требуют рецензирования,
> > присоединяйтесь!
> >
> > https://ddtp2.debian.net/ddtss/index.cgi/ru
>
> Я сходила ранее туда почитала и поняла, что они бы хотели получать
> патчами. И поэтому ничего делать не стала :-(( Я знаю что делают патчи
> - накладывают заплатки на код программ, а как их самому делать ...
> Боюсь сделать что-то не так. Думала, что там это организовано что-то
> типа - как файл "po". Если подскажите попроще вариант редактирования
> русского описания (без патчей), то я почитаю их, из тех, что имеются в
> наличии (ну вот к примеру если бы можно было читать как я читаю русские
> страницы на debian.org, в российском сегменте, в формате html).
>
> И плюс надо бы завести туда русское описание APT. Вот я заглянула в
> русифицированную программу Aptitude, нашла APT и да - вижу её описание
> на английском языке. А очень жаль, ведь программа APT отлично
> русифицирована, даёт понятные рекомедации и сообщения и её бы
> обязательно надо "довести до ума" и перевести на русский язык её
> "лицо". То есть это фактически как бы краткая аннотация программы.

Это именно перевод описаний пакетов, никаких патчей не надо, перевод
описания выполняется в текстовом поле браузера [1] (или скопировав в
_текстовый_ редактор) и должен соответствовать нескольким простым
правилам.

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

[1] https://ddtp2.debian.net/ddtss/index.cgi/ru

Re: Сервер DDTP работает

[Sergey Alyoshin]

35 переводов описаний пакетов требуют рецензирования, присоединяйтесь!

https://ddtp2.debian.net/ddtss/index.cgi/ru

Re: thunar - множественное число в файле ru.po и в других аналогичных файлах

[Sergey Alyoshin]

On Wed, Sep 19, 2018 at 11:50 AM Galina Anikina  wrote:
>
> Открыла посмотреть
> ru.po__from_thunar_1.8.1.orig_20180919_Debian_Unstable программой
> poedit. А программа жёлтым уведомила, что множественное число не
> соответствует русскому языку.

Thunar соответствует: 4-ая форма это дробное число (например 1,5
яблока) и обычно не используется.

Так как перевод Thunar выполняется на Transifex, то используется их
правило из 4-х форм для всех переводов на русский.
См.  http://cldr.unicode.org/index/cldr-spec/plural-rules


> Ведь должно же быть единообразное оформление po-файлов?

В Thunar менять проблематично, так как Transifex правы, в остальных
переводах указывать 4-ре формы без дробных чисел тоже смысла нет.

Re: apt 1.7.0~rc1

[Sergey Alyoshin]

On Wed, Sep 19, 2018 at 10:09 AM Galina Anikina  wrote:
>
> В Ср, 19/09/2018 в 09:58 +0300, Sergey Alyoshin пишет:
> > On Wed, Sep 19, 2018 at 9:49 AM Galina Anikina 
> > wrote:
> > > E: Порождённый процесс /usr/sbin/apt-listbugs apt вернул
> > > код ошибки (10)
> > > E: Failure running script /usr/sbin/apt-listbugs apt
> > >
> > "Созданный процесс", и с чего вдруг apt подпрограмма?
>
>
> Смотрите - это звучит сейчас так
> > > Порождённый процесс  apt вернул код ошибки
>
> По моему не состыкуются падежи.
> То есть что хотели сказать?

Если не нравится "порождённый":
Созданный apt процесс  вернул код ошибки

Re: apt 1.7.0~rc1

[Sergey Alyoshin]

On Wed, Sep 19, 2018 at 9:49 AM Galina Anikina  wrote:
>
> В версии apt 1.7.0~rc1
>
> выдаёт так
> ...
> Получено 18,4 MB за 23с (804 kB/s)
> Получение сообщений об ошибках... Завершено
> Анализ информации об
> обнаруженных/исправленных ошибках... Завершено
> serious ошибок в apt
> (1.6.4 → 1.7.0~rc1) <Нерешённые>
>  b1 - #909155 - apt-cache show multiple
> packages produces invalid output
> Сводка:
>  apt(1 ошибка)
> Действительно
> установить/обновить указанные выше пакеты? [Y/n/?/...] n
> ***
> 
> ** Выход с ошибкой для
> прерывания установки. **
> ***
> 
> E: Порождённый процесс /usr/sbin/apt-listbugs apt вернул
> код ошибки (10)
> E: Failure running script /usr/sbin/apt-listbugs apt
>
>
> Выражение
> "E: Порождённый процесс /usr/sbin/apt-listbugs apt вернул код ошибки
> (10)"
>
> может лучше выразить мысль так-
>  "Взаимосвязанная процедура apt /usr/sbin/apt-listbugs вернула код
> ошибки"
>
> Или
> Подпрограмма apt  вернула код ошибки
> Смежная программа 
>
> Вызванный программой apt процесс вернул код ошибки.
> Вызванный ранее программой apt процесс вернул код ошибки.

"Созданный процесс", и с чего вдруг apt подпрограмма?

Re: ledgersmb_Version 1.5.21+ds-2_опечатки

[Sergey Alyoshin]

On Sun, Sep 9, 2018 at 7:55 AM Galina Anikina  wrote:
>
> В Пт, 07/09/2018 в 13:24 +0300, Sergey Alyoshin пишет:
> > а почему так сильно отличаются эти два файла po?
> > > В "*ds-1" говорится про настраивание административных параметров, а
> > > в
> > > "1.5.21+ds-2" - непосредственно применяются бухгалтерские термины и
> > > нет
> > > ничего про администрирование.
> > У вас во вложении
> > 1) Перевод интерфейса программы
> > 2) Перевод вопросов настройки программы debconf (обновление которого
> > Юрий Козлов сделал быстрее)
>
> То есть в дальнейшем эти два блока будут объединены в один файл ru.po
> (в данном пакете)?
>

В один пакет, но в разных файлах.
Перевод интерфейса в файле пакета usr/share/ledgersmb/locale/po/ru.po
Перевод debconf (объединённый для всех языков) в файле пакета DEBIAN/templates

Re: ledgersmb_Version 1.5.21+ds-2_опечатки

[Sergey Alyoshin]

On Fri, Sep 7, 2018 at 1:05 PM Gali Anikina  wrote:

> Да, и вопрос к Sergey Alyoshin  - вот Вы
> доперевели ru.po из пакета ledgersmb 1.5.21+ds-1, взятого отсюда
> https://lists.debian.org/debian-l10n-russian/2018/07/msg00038.html (в
> июле 2018), а почему так сильно отличаются эти два файла po?
> В "*ds-1" говорится про настраивание административных параметров, а в
> "1.5.21+ds-2" - непосредственно применяются бухгалтерские термины и нет
> ничего про администрирование. Разве может так сильно измениться пакет
> от версии к версии? Или я что-то не так сравниваю?

У вас во вложении
1) Перевод интерфейса программы
2) Перевод вопросов настройки программы debconf (обновление которого
Юрий Козлов сделал быстрее)

Re: Опечатки в переводе

[Sergey Alyoshin]

On Fri, Aug 24, 2018 at 6:59 PM Lev Lamberov  wrote:
>
> Пт 24 авг 2018 @ 21:10 Vladimir Shestakov :
>
> > https://www.debian.org/News/2018/20180714
> > "четвёртом обновлении" -> "пятом обновлении"
> > "исправление сборка на s390x" -> "исправление сборки на s390x"
> > "столкновению хэшей" -> "коллизии хэшей"
>
> > https://www.debian.org/security/2018/dsa-4261
> > "через внешней программы" -> "через внешнюю программу"
>
> > https://www.debian.org/security/2018/dsa-4262
> > Вместо "PHP-инфраструктуре" лучше перевести как "PHP-фреймворке". Термин
> > фреймворк уже вполне устоялся (https://ru.wikipedia.org/wiki/Фреймворк).
>
> > https://www.debian.org/security/2018/dsa-4264
> > Аналогично вместо инфраструктуры лучше использовать термин фреймворк.
>
> > https://www.debian.org/security/2018/dsa-4272
> > "Тот же эффект можно достичь" -> "Того же эффекта можно достичь"
>
> Исправил. Спасибо!
>
> Вопрос к участникам списка рассылки. Кто как считает, какой перевод
> термина "framework" лучше использовать?

Я за программную платформу.

https://ru.wikipedia.org/wiki/Фреймворк

Re: разобрать и собрать initrd

[Sergey B Kirpichev]

On Wed, Aug 22, 2018 at 04:32:03PM +0300, sergio wrote:
> On 22/08/2018 11:19, Sergey B Kirpichev wrote:
> > Как-то так:
> > gunzip -c -9 ../$(ARCH).orig/install.amd/initrd.gz | cpio -i -d -H newc 
> > --no-absolute-filenames
> > find . | cpio -o -H newc | gzip -9 > ../$(ARCH)/install.amd/initrd.gz
> 
> Это уже всё давно не правда. У вас по-прежнему etch?

Это wheezy, если я правильно помню.  Кусок макефайла, который правит
диск для последующей нарезки.  Должен работать и на stretch, хотя
не уверен что проверялось.

Re: разобрать и собрать initrd

[Sergey B Kirpichev]

On Wed, Aug 22, 2018 at 04:11:31AM +0300, sergio wrote:
> А как в этом нашем дебиане разобрать initrd (что бы поменять в нём файл) и
> собрать обратно?

Как-то так:
-->8--
initrd: $(ARCH).orig preseed.cfg.clean
mkdir initrd
cd initrd && \
gunzip -c -9 ../$(ARCH).orig/install.amd/initrd.gz | \
sudo cpio -i -d -H newc --no-absolute-filenames
sudo cp preseed.cfg.clean initrd/preseed.cfg

$(ARCH)/install.amd/initrd.gz: initrd initrd/preseed.cfg
cd initrd && find . | cpio -o -H newc | gzip -9 > 
../$(ARCH)/install.amd/initrd.gz
-->8--

Re: ledgersmb 1.5.21+ds-1: Please update debconf PO for the ledgersmb

[Sergey Alyoshin]

On Wed, Jul 25, 2018 at 6:55 AM, Robert James Clay  wrote:
> Hi,
>
>
>
> You are noted as the last translator of the debconf translation for
> ledgersmb. The English template has been changed, and now some messages are
> marked "fuzzy" in your translation or are missing.
>
> I would be grateful if you could take the time and update it.
>
> Please send the updated file to me, or submit it as a wishlist bug against
> ledgersmb.

Updated file.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the ledgersmb package.
#
# Yuri Kozlov , 2012.
msgid ""
msgstr ""
"Project-Id-Version: ledgersmb 1.5.21+ds-1\n"
"Report-Msgid-Bugs-To: ledger...@packages.debian.org\n"
"POT-Creation-Date: 2018-03-23 21:01-0400\n"
"PO-Revision-Date: 2018-07-29 21:02+0300\n"
"Last-Translator: Sergey Alyoshin \n"
"Language-Team: Russian \n"
"Language: ru\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: VIM 8.0\n"
"Plural-Forms: nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && n"
"%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2);\n"

#. Type: string
#. Description
#: ../templates:2001
msgid "Database administrative user login:"
msgstr "Учётная запись администратора баз данных:"

#. Type: string
#. Description
#: ../templates:2001
msgid ""
"Please enter the login of the LedgerSMB database administrative user. This "
"login is needed for the administrative web user interface, typically at "
"http://localhost:5762/setup.pl.;
msgstr ""
"Введите учётную запись администратора базы данных LedgerSMB. Эта запись "
"требуется для веб-интерфейса управления, обычно располагающегося по адресу "
"http://localhost:5762/setup.pl.;

#. Type: password
#. Description
#: ../templates:3001
msgid "Database administrative user password:"
msgstr "Пароль к административной учётной записи:"

#. Type: password
#. Description
#: ../templates:3001
msgid ""
"Please enter the password of the LedgerSMB database administrative user. "
"This password is needed for the administrative web user interface, typically "
"at http://localhost:5762/setup.pl.;
msgstr ""
"Введите пароль к учётной записи администратора базы данных LedgerSMB. Этот "
"пароль требуется для веб-интерфейса управления, обычно располагающегося по "
"адресу http://localhost:5762/setup.pl.;

#. Type: select
#. Description
#: ../templates:4001
msgid "Web Reverse Proxy to configure?"
msgstr "Обратный веб-прокси для настройки?"

#. Type: select
#. Description
#: ../templates:4001
msgid ""
"The LedgerSMB application now defaults to being made available on port 5762, "
"and being run directly by Starman. If other access is needed, a Reverse "
"Proxy can be configured using Apache or Nginx or Lighttpd or Varnish, or you "
"can leave the choice as None if it is not needed or if the web proxy will be "
"set up remotely."
msgstr ""
"Теперь LedgerSMB по умолчанию прослушивает порт 5762 и запускается напрямую "
"от Starman. Если требуется другой доступ, то может быть настроен обратный "
"прокси с использованием Apache, Nginx, Lighttpd или Varnish. Оставьте выбор "
"как None, если другой доступ не требуется или веб-прокси будет установлен "
"удалённо." 

#. Type: select
#. Description
#: ../templates:4001
msgid ""
"For more details, please see the Web Proxy section that can be found in the /"
"usr/share/doc/ledgersmb/README.Debian file."
msgstr ""
"Дополнительную информацию см. в разделе Web Proxy в файле "
"/usr/share/doc/ledgersmb/README.Debian."

#, fuzzy
#~| msgid "Configure LedgerSMB automatically?"
#~ msgid "Configure LedgerSMB Database administrative user automatically?"
#~ msgstr "Настроить LedgerSMB автоматически?"

#, fuzzy
#~| msgid ""
#~| "The configuration program for the package can automatically configure "
#~| "some aspects of LedgerSMB, such as the LedgerSMB database user."
#~ msgid ""
#~ "The configuration program for the package can automatically configure the "
#~ "LedgerSMB database user. Enable if you want to do that, disable if not."
#~ msgstr ""
#~ "Программа настройки пакета может автоматически настроить некоторые "
#~ "параметры LedgerSMB, такие как учётная запись базы данных LedgerSMB."

#, fuzzy
#~| msgid ""
#~| "More general information about the initial configuration of the "
#~| "application can be found in /usr/share/doc/ledgersmb/README.Debian."
#~ msgid ""
#~ "More information about the configuration of the database administrative "
#~ "user can be found in /usr/share/doc/ledgersmb/README.Debian."
#~ msgstr ""
#~ "Дополнительную информацию о начальной настройке приложения можно найти в "
#~ "файле /usr/share/doc/ledgersmb/README.Debian."

Re: linuxinfo 3.0.0-1: Please update the PO translation for the package linuxinfo

[Sergey Alyoshin]

On Tue, Jul 24, 2018 at 7:39 PM, Helge Kreutzmann  wrote:
> Hi,
>
> You are noted as the last translator of the translation for
> linuxinfo. The English template has been changed, and now some messages
> are marked "fuzzy" in your translation or are missing.
> I would be grateful if you could take the time and update it.
> Please send the updated file to me, or submit it as a wishlist bug
> against linuxinfo.
>
> The deadline for receiving the updated translation is
> Thu, 23 Aug 2018 18:29:39 +0200.

Updated file.
# Copyright (C) YEAR Helge Kreutzmann 
# This file is distributed under the same license as the linuxinfo package.
#
# Yuri Kozlov , 2014.
msgid ""
msgstr ""
"Project-Id-Version: linuxinfo 3.0.0\n"
"Report-Msgid-Bugs-To: Helge Kreutzmann \n"
"POT-Creation-Date: 2018-07-23 18:55+0200\n"
"PO-Revision-Date: 2018-07-29 20:34+0300\n"
"Last-Translator: Sergey Alyoshin \n"
"Language-Team: Russian \n"
"Language: ru\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && n"
"%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2);\n"
"X-Generator: VIM 8.0\n"

#: linuxinfo.c:57
msgid "Unknown"
msgstr "Неизвестно"

#: linuxinfo.c:57
msgid "One"
msgstr "Один"

#: linuxinfo.c:57
msgid "Two"
msgstr "Два"

#: linuxinfo.c:57
msgid "Three"
msgstr "Три"

#: linuxinfo.c:57
msgid "Four"
msgstr "Четыре"

#: linuxinfo.c:57
msgid "Five"
msgstr "Пять"

#: linuxinfo.c:57
msgid "Six"
msgstr "Шесть"

#: linuxinfo.c:57
msgid "Seven"
msgstr "Семь"

#: linuxinfo.c:57
msgid "Eight"
msgstr "Восемь"

#: linuxinfo.c:57
msgid "Nine"
msgstr "Девять"

#: linuxinfo.c:57
msgid "Ten"
msgstr "Десять"

#: linuxinfo.c:57
msgid "Eleven"
msgstr "Одиннадцать"

#: linuxinfo.c:57
msgid "Twelve"
msgstr "Двенадцать"

#: linuxinfo.c:81
#, c-format
msgid " -h   print this help\n"
msgstr " -h   показать эту справку\n"

#: linuxinfo.c:82
#, c-format
msgid " -v   print linuxinfo version\n"
msgstr " -v   показать версию linuxinfo\n"

#: linuxinfo.c:89
#, c-format
msgid "Unsupported option or file %s not found.\n"
msgstr "Неподдерживаемый параметр или файл %s не найден.\n"

#: linuxinfo.c:98
#, c-format
msgid "Could not open %s.\n"
msgstr "Невозможно открыть %s.\n"

#: linuxinfo.c:124
#, c-format
msgid "processor"
msgid_plural "processors"
msgstr[0] "процессор"
msgstr[1] "процессора"
msgstr[2] "процессоров"

#: linuxinfo.c:127
#, c-format
msgid ", %s total bogomips, %sM RAM\n"
msgstr ", %s всего bogomips, %sM RAM\n"

#: linuxinfo.c:134
#, c-format
msgid "System library %s\n"
msgstr "Системная библиотека %s\n"

#: linuxinfo_common.c:148
#, c-format
msgid "Could not stat /proc/meminfo, result can be inaccurate\n"
msgstr ""
"Не удалось получить сведения о /proc/meminfo, результат может быть неточным\n"

#: linuxinfo_common.c:238
#, c-format
msgid "PCRE2 compilation failed at offset %d: %s\n"
msgstr "Ошибка составления PCRE2 при смещении %d: %s\n"

#: linuxinfo_common.c:274
#, c-format
msgid "Matching error %d\n"
msgstr "Ошибка соответствия %d\n"

Re: Файл-менеджер с тегами

[Sergey Spiridonov]

On Mon, 25 Jun 2018 13:49:01 +0300
Артеменко Никита  wrote:

>  Пересылаемое сообщение  
> 23.06.2018, 20:39, "Артеменко Никита" :
> 
> Здравствуйте все!
> 
> Мне хочется странного. Нужен файловый менеджер, который позволяет
> присваивать теги файлам, а потом сортировать эти файлы по тегам, при
> этом он должен уметь делать это на нескольких дисках одновременно, в
> т. ч. на сменных носителях. Если не трудно, можете посоветовать что
> нибудь годное?  Конец пересылаемого сообщения 
> 
> 
https://habr.com/post/374465/


-- 
Best regards, Sergey Spiridonov

Сервер DDTP работает

[Sergey Alyoshin]

https://ddtp2.debian.net/ddtss/index.cgi/ru

35 пактов требуют рецензирования, присоединяйтесь!

Re: multilingual spell checker

[Sergey Matveev]

*** sergio [2018-04-16 10:21]:
>Каждый раз копируешь в вим а потом обратно?

Вся работа с текстом всегда и так происходит в Vim.
Ну а вообще да, если надо проверить, то скопирую в него.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: multilingual spell checker

[Sergey Matveev]

*** sergio [2018-04-16 10:06]:
>Хочу поинтересоваться, вдруг в современном мире линукс стало возможным,
>проверять орфографию на нескольких языках сразу? (Как в уютном виме, который
>делает так, сколько я его помню.)

Лично я всю жизнь проверяю в Vim и английский и русский одновременно,
в его родном spellchecker.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: Перевод "Руководства сопровождающего Debian"

[Sergey Alyoshin]

2018-04-14 20:30 GMT+03:00 Lev Lamberov <dogs...@debian.org>:
> Сб 14 апр 2018 @ 18:41 Sergey Alyoshin <alyoshi...@gmail.com>:
>>
>>  #. (itstool) path: abstract/simpara
>>  #: debmake-doc.en.xml:48
>> @@ -84,7 +84,7 @@ msgstr ""
>>  #. (itstool) path: bookinfo/copyright
>>  #: debmake-doc.en.xml:50
>>  msgid "2014-2015 Osamu Aoki"
>> -msgstr "2014-2015 Осаму Аоки"
>> +msgstr "2014—2015 Осаму Аоки"
>
> А почему тут и далее "copyright" предлагается не переводить?

При переводе оставляется как есть по ГОСТ Р 7.0.1-2003
http://docs.cntd.ru/document/1200032004

Я бы оставил только символ (c)


>>  #. (itstool) path: footnote/simpara
>>  #: debmake-doc.en.xml:95
>> @@ -179,9 +179,9 @@ msgid ""
>>  "programming, too."
>>  msgstr ""
>>  "Вам необходимо знать немного о программировании в Unix, но от вас "
>> -"определённо не требуется быть волшебником. Вы можете узнать об основах "
>> -"управления системой Debian из <_:ulink-1/>. Там же вы можете найти ссылки 
>> на "
>> -"ресурсы, с помощью которых можно изучить программирование в Unix."
>> +"определённо не требуется быть экспертом. Вы можете узнать об основах "
>> +"управления системой Debian из <_:ulink-1/>. Там же можно найти ссылки на "
>> +"ресурсы для изучения программирования в Unix."
>
> "быть волшебником" звучит веселее, "быть экспертом" как-то слишком
> официально. Пока исправил на "быть экспертом", посмотрим, что другие
> думают.


Wizard'ом принято называть "сильного гуру" Unix.

https://groups.google.com/forum/#!topic/net.jokes/YKlEQCYHbJA

Re: Перевод "Руководства сопровождающего Debian"

[Sergey Alyoshin]

0001-Update-ru.po-with-make-html.patch.gz
Description: application/gzip
From 3915c4fcf3c1403755b46329bb9f7923e5346aec Mon Sep 17 00:00:00 2001
From: Sergey Alyoshin <alyoshi...@gmail.com>
Date: Sat, 14 Apr 2018 18:27:13 +0300
Subject: [PATCH 2/2] Change ru.po

---
 po/ru.po | 48 
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/po/ru.po b/po/ru.po
index 789c63e..4b38e61 100644
--- a/po/ru.po
+++ b/po/ru.po
@@ -50,12 +50,12 @@ msgid ""
 "examples."
 msgstr ""
 "Оно сконцентрировано на современном стиле создания пакетов и содержит "
-"множество простых примеров."
+"множество простых примеров:"
 
 #. (itstool) path: listitem/simpara
 #: debmake-doc.en.xml:27
 msgid "POSIX shell script packaging"
-msgstr "Создание пакета, содеращего сценарий командной оболочки POSIX"
+msgstr "Создание пакета, содержащего сценарий командной оболочки POSIX"
 
 #. (itstool) path: listitem/simpara
 #: debmake-doc.en.xml:32
@@ -65,12 +65,12 @@ msgstr "Создание пакета, содержащего сценарий 
 #. (itstool) path: listitem/simpara
 #: debmake-doc.en.xml:37
 msgid "C with Makefile/Autotools/CMake"
-msgstr "C с Makefile/Autotools/CMake"
+msgstr "C и Makefile/Autotools/CMake"
 
 #. (itstool) path: listitem/simpara
 #: debmake-doc.en.xml:42
 msgid "multiple binary packages with shared library etc."
-msgstr "несколько двоичных пакетов с разделяемой библиотекой и т. д."
+msgstr "Несколько двоичных пакетов с разделяемой библиотекой и т. д."
 
 #. (itstool) path: abstract/simpara
 #: debmake-doc.en.xml:48
@@ -84,7 +84,7 @@ msgstr ""
 #. (itstool) path: bookinfo/copyright
 #: debmake-doc.en.xml:50
 msgid "2014-2015 Osamu Aoki"
-msgstr "2014-2015 Осаму Аоки"
+msgstr "2014—2015 Осаму Аоки"
 
 #. (itstool) path: legalnotice/simpara
 #: debmake-doc.en.xml:56
@@ -130,8 +130,8 @@ msgid ""
 "“Making a Debian Package (AKA the Debmake Manual)”, copyright © 1997 Jaldhar "
 "Vyas."
 msgstr ""
-"«Создание пакета Debian (руководство по debmake)», все права защищены © 1997 "
-"Джалдхар Виас."
+"«Создание пакета Debian (руководство по debmake)», copyright © 1997 "
+"Джалдхар Виас"
 
 #. (itstool) path: listitem/simpara
 #: debmake-doc.en.xml:79
@@ -139,7 +139,7 @@ msgid ""
 "“The New-Maintainer’s Debian Packaging Howto”, copyright © 1997 Will Lowe."
 msgstr ""
 "«Практическое руководство нового сопровождающего по созданию пакетов "
-"Debian», все права защищены © 1997 Уилл Лоу."
+"Debian», copyright © 1997 Уилл Лоу"
 
 #. (itstool) path: listitem/simpara
 #: debmake-doc.en.xml:84
@@ -147,9 +147,9 @@ msgid ""
 "“Debian New Maintainers’ Guide”, copyright © 1998-2002 Josip Rodin, "
 "2005-2014 Osamu Aoki, 2010 Craig Small, and 2010 Raphaël Hertzog."
 msgstr ""
-"«Руководство начинающего разработчика Debian», авторское право © 1998-2002 "
-"Джосип Родин, 2005-2014 Осаму Аоки, 2010 Крэйг Смолл, а также 2010 Рафаэль "
-"Херцог."
+"«Руководство начинающего разработчика Debian», copyright © 1998—2002 "
+"Джосип Родин, 2005—2014 Осаму Аоки, 2010 Крэйг Смолл, а также 2010 Рафаэль "
+"Херцог"
 
 #. (itstool) path: legalnotice/simpara
 #: debmake-doc.en.xml:89
@@ -168,7 +168,7 @@ msgstr "Предисловие"
 #. (itstool) path: simpara/ulink
 #: debmake-doc.en.xml:95
 msgid "Debian Reference"
-msgstr "Справочник Debian"
+msgstr "Справочника Debian"
 
 #. (itstool) path: footnote/simpara
 #: debmake-doc.en.xml:95
@@ -179,9 +179,9 @@ msgid ""
 "programming, too."
 msgstr ""
 "Вам необходимо знать немного о программировании в Unix, но от вас "
-"определённо не требуется быть волшебником. Вы можете узнать об основах "
-"управления системой Debian из <_:ulink-1/>. Там же вы можете найти ссылки на "
-"ресурсы, с помощью которых можно изучить программирование в Unix."
+"определённо не требуется быть экспертом. Вы можете узнать об основах "
+"управления системой Debian из <_:ulink-1/>. Там же можно найти ссылки на "
+"ресурсы для изучения программирования в Unix."
 
 #. (itstool) path: preface/simpara
 #: debmake-doc.en.xml:95
@@ -190,7 +190,7 @@ msgid ""
 "encountered following situations:"
 msgstr ""
 "Если вы уже в какой-то степени являетесь опытным пользователем Debian <_:"
-"footnote-1/>, то вы можете столкнутся со следующими ситуациями:"
+"footnote-1/>, то можете столкнутся со следующими ситуациями:"
 
 #. (itstool) path: listitem/simpara
 #: debmake-doc.en.xml:

Re: актуальный софт против спама

[Sergey Matveev]

Приветствую!

*** sl...@vivaldi.net [2018-04-03 21:28]:
>Кто в курсе, что на данный момент актуально для борьбы со спамом:

Номер один для борьбы со спамом это проверка на reverse DNS -- работает
очень эффективно. В Postfix, например, имеется из коробки. А второе это
greylisting -- отсеивает бОльшую часть, но требуется (для Postfix)
дополнительный демон. http://www.stargrave.org/Spam.html

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: Почтовый клиент

[Sergey Matveev]

*** Sergey Matveev [2018-03-29 21:27]:
>Если канал слабый и ещё и обрывающийся, то лично я использовал бы NNCP:[...]

В пятых на почтовый сервер для такой отправки писем не надо поднимать
никаких POP3/IMAP4. Хотя, если предполагается использование параллельно
с этим и других клиентов, то наверное придётся.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: Почтовый клиент

[Sergey Matveev]

*** Artem Chuprina [2018-03-29 15:31]:
>Слабый канал и дорого — это два противоречащих одно другому условия. В
>смысле, если выполняются сразу оба, то мы в жопе. И надо понимать, в
>какой мы сегодня позе.

Если канал слабый и ещё и обрывающийся, то лично я использовал бы NNCP:
http://www.nncpgo.org/. Предполагая что почтовый сервер свой, постоянно
подключённый к Интернету и принимающий почту. Чтобы с него забирать её
(полностью копируя), то нужно чтобы, например, Postfix все приходящие
письма отправлял через NNCP транспорт на нужный компьютер: 
http://www.nncpgo.org/Postfix.html
как это делают с транспортом UUCP. И забирать эту почту через NNCP
демон. Во-первых, будет сразу аутентифицированный и шифрованный канал
(никаких TLS, SSH, VPN не надо между вами и почтовым сервером с которого
забираете). Во-вторых, почтовые сообщения жмутся (zlib) перед отправкой.
В-третьих, поддерживается докачка (с дешёвым (десятки байт) handshake и
понимаем что конкретно надо докачать и откуда) любого сообщения.
В-четвёртых, если имеется несколько почтовых ящиком для разных целей и
предполагается что они разного приоритета (для почтовых рассылок один,
для личной переписки другой, как минимум), то можно Postfix-у сказать
чтобы с разных ящиков он в NNCP отправлял пакеты с указанием приоритета
(niceness) и при связи с его демоном просасывать более приоритетные
письма, только потом докачивая и продолжая работать с менее важными.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: Системы управления сервером?

[Sergey Matveev]

*** Alexander Gerasiov [2018-03-24 14:48]:
>при работе с джунами очень удобно ткнуть мышой в место в
>коде/диффе и написать, что тут не так и как поправить. Особенно, когда
>таких мест десяток. Без этого приходится либо сажать рядом и
>показывать, либо в ядерном стиле, когда дифф в почте комментируется
>инлайн.
>Так что не надо топить вебинтерфейсы, у них иногда действительно есть плюсы.

А я вот подобное делаю через самописный плагин для Vim:
https://git.stargrave.org/cgit.cgi/gerrvim.git/tree/doc/gerrvim.txt
Используется для работы с Gerrit, в котором есть JSON API. Суть
плагина проста: открываем файлы в коммите которые нужно
откомментировать, выделяем конкретные строки визуальным выделением, \cc,
появляется окно с вводом комментария,  и оно закрывается, сохраняя в
временный файл все аггрегированные комментарии, затем запускаем скрипт
преобразующий их в JSON и посылающий в Gerrit. Раньше он применялся не
только для Gerrit, но для подготовки комментариев к коду и для других
систем.

Я много лет комментировал код, как вы это назвали, inline-ом в патчах и
оставлял в виде комментария в Redmine/Trac системах. Потом не один год
провёл в Gerrit, где web-интерфейс в котором можно тыкнуть на строчки и
написать комментарий. Лично мне web-интерфейс не кажется удобным и нигде
не видел чтобы он был удобен. Если это нужно выполнить раз в полгода, то
тогда да, почему бы и нет. Но если с этим сталкиваться каждый день, если
это постоянный инструмент для ежедневного ревью, то ничто не сравнится с
окружением настроенным лично под себя, в удобном виде в редакторе
(Vim/Emacs) и почтовом клиенте. Не бывает инструментов одинаково удобных
для всех -- а web-интерфейсы это как-раз насильно диктуемая одна
программа для всех.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: Вот и проголосовали

[Sergey B Kirpichev]

Граждане-господа-товарищи, ну я понимаю что весна.  Но причем
тут Debian-то?

Re: Вот и проголосовали

[Sergey B Kirpichev]

WTF?!

https://www.debian.org/vote/2018/vote_001
У нас все впереди еще.  Типа.

Re: Проблема с правами доступа в Debian

[Sergey Alyoshin]

2018-03-19 11:56 GMT+03:00 Galina Anikina :

> В данном случае вопрос шифрования находится ещё на стадии изучения, а
> две системы установлены в качестве эксперимента на компе, где сам себе
> хозяин.
>
> Насчёт поменять UID - спасибо сделаю, но всё же хотелось бы, чтобы
> проверялось не только по UID а и по имени пользователю и если они не
> совпадают, то программа должна уведомить root-а в момент монтирования и
> возможно предложить какое-то решение.
> Это был бы логичный разумный вариант разрешения данного вопроса.
> Кстати вот ещё пример на тему - обоснования зачем это надо-
>
> Представьте школу и учитель информатики установил на один компьютер в
> сети систему и ввёл пользователей 1 и 2.

Для такого есть способы сетевой аутентификации пользователей.


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

Так во всех UNIX'ах.

Думаю, максимум что можно сделать, предупреждать при установке системы,
что может быть такая ситуация и описать её в руководстве по установке.


> Или если пользователь 2-ой хочет просмотреть каталог 1-го - где у них
> совпадают UID, но не совпадают имена - надо выдать окно предупреждения
> - что поскольку UID и имя пользователя не совпадают на 100 проентов, то
> эту операцию может сделать только суперпользователь и отказать этому
> желающему.
> Такой вариант решения был был компромиссным и правильным.

Это полумера, где уверенность что этот новый tobik тот прежний tobik?  Вместо
одного идентификатора, будет идентификатор и имя? Ничем не лучше.
Идентификаторы специально отделены от имен пользователей.

Переставите диск в другой компьютер, кто-то будет знать пароль
суперпользователя и спокойно просмотрит ваши файлы (и tobika тоже). Хотите
приватности -- шифруйте (если надолго, то и резервные копии).

Re: Проблема с правами доступа в Debian

[Sergey Alyoshin]

2018-03-19 7:50 GMT+03:00 Galina Anikina :
> Суть в следующем:
>
> нахожусь пользователем rimma на sda5 с установленной системой
> Debian_Buster/sid__Unstable
>
> примонтировала sda3 с Debian Stable 9_4 - чтобы wallpappers перебросить
> с sda3 на sda5
>
> И получается абсурд
> я могу посмотреть (полазить в нём) каталог не такого же пользователя
> (если он совпал по имени - например rimma), а чужого - другого
> пользователя (например tobik-а)!
> К примеру я сейчас rimma и нахожусь на sda5, примонтировала sda3, далее
> смотрю тот соседний раздел - home
> и вижу что всё перепутано с правами!
>
> Вот в
> xfce4-terminal 0.8.7.1
>
> mount /dev/sda3 /mnt
>
> rimma@tamrik:~$ ls -All /mnt/home/
> итого 32
> drwx-- 50 tobik tobik 24576 мар 18 13:24 rimma
> drwx-- 15 rimma  rimma   4096 мар 15 16:21 tobik
> drwxr-xr-x  5 tobik tobik  4096 мар 15 17:10 y_walpappers
>
> rimma@tamrik:~$ ls -All /mnt/home/rimma/
> ls: невозможно открыть каталог '/mnt/home/rimma/': Отказано в доступе
> (хотя на sda5 я сейчас пользователь rimma)

По выводу ls ясно, что владелец /mnt/home/rimma tobik, а не rimma.

Видимо у вас разные идентификаторы пользователя на разных системах,
а проверка прав по идентификатору пользователя, не по имени.

Скажем, на старой системе tobik UID 1000, rimma UID 1001, а на новой наоборот,
потому что один пользователь был создан раньше другого. UID можно поменять.

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


> rimma@tamrik:~$ ls -All /mnt/home/tobik/
> итого 100
> -rw--- 1 rimma rimma 6 мар 15 16:21  .bash_history
> ..
>
> rimma@tamrik:~$
>
> Ха а "чужого" - tobik-а разрешает просмотреть!

Потому что владелец "чужого" тут rimma.


> Хотела написать об этой проблеме ещё пару лет назад, но поскольку надо
> было писать на английском 
> Короче подумала, что кто-то заметит и напишет. Вот прошло время и "воз
> и ныне там"!
>
> Возможно этот баг уже зарегистирован, не смотрела, там сложно читать

Это не ошибка, особенность.

Re: internet radio pleer

[Tarasov Sergey]

15.03.2018 19:33, D. H. пишет:

On 15/03/18 02:53 AM, Dmitry Nezhevenko wrote:

Это кажется так.. По факту бывают USB наушники.. Или USB комплекты для
громкой связи в переговорках... Или даже банальная USB веб-камера с заметно
более качественным микрофоном микрофоном.

А еще звук по HDMI бывает.

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


Бывает много всего. Но в процентном соотношении сколько таких
конфигураций? 1% - 2%?



У меня на домашнем компе 4 звуковухи (встроенная,две внешних и от 
видеокарты). И не поверите, всеми пользуюсь.
Сын может сказку к себе в комнату включить, я в другую комнату подать 
звук на усилок, плюс на компе в это время могут что-то смотреть и слушать.
В данном вопросе на PulseAudio я не нарадуюсь - у меня сын и дочка могут 
аудиопоток куда хотят увести.

Re: internet radio pleer

[Sergey Matveev]

*** D. H. [2018-03-15 18:11]:
>Ага, а лучше винил и слушать на профессиональном оборудовании а не usb
>звуковухах

Винил нет не лучше.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: internet radio pleer

[Sergey Matveev]

*** D. H. [2018-03-15 17:41]:
>Но при том качестве аудио файлов что валяются в сети,
>воспроизводятся с ютубов и прочей браузерной ерунды разница в качестве
>психосоматическая.

Ну так надо качать FLAC-и и покупать CD-диски. Без сарказма.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: internet radio pleer

[Sergey Matveev]

*** D. H. [2018-03-15 07:14]:
>А зачем USB звуковушки? Ещё встречаются ноуты\десктопы без звуковых карт?

Музыку вы будете слушать через встроенную звуковуху ноутбука?
Через USB можно подключить качественную.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: из man в po программой po4a-gettextize пишет-Данный файл создан с помощью Pod::Man

[Sergey Alyoshin]

2018-03-14 16:23 GMT+03:00 Gali Anikina :
> Подскажите, каким способом задействовать модуль в po4a
>
>
> Хотела преобразовать из man в po -  man по po4a.
>
> $ po4a-gettextize -f man -M UTF-8 --debug --master po4a.1p --po
> po4a_1_p_man_rus.po
>
> $ po4a.1p:1: (po4a::man)
>Данный файл создан с помощью Pod::Man. Преобразуйте файл POD
> с помощью модуля pod из программы po4a.

Насколько я понимаю, программа определила, что po4a.1p создан из формата pod и
предлагает использовать оригинал в формате pod (уже c параметром -f pod).

Оригинал pod можно получить из исходных кодов po4a. Но запускать вручную po4a в
исходных кодах po4a уже нет смысла, так как он и так запускается при сборке и
вы получаете готовые для перевода .pot и .po.

Re: RFR apt-listchanges

[Sergey Alyoshin]

2018-03-09 18:13 GMT+03:00 Gali Anikina :
>> И подскажите пожалуйста - как man преобразовать в po?

po4a -M UTF-8 -f man -m man.1 -p man.pot

Re: RFR apt-listchanges

[Sergey Alyoshin]

2018-03-09 18:13 GMT+03:00 Gali Anikina :
> Можно ещё кое-что у вас уточнить? Посылать надо в комплекте - переведённые
> все маны в пакете? А если переведёшь 1 из примерно 30 руководств, потом ещё
> и тд? Например coreutils содержит много man-ов? Понятно, что для начала
> лучше взять пакет с небольшим количеством man-ов. Но всё же я хотела
> уточнить. Так как в coreutils есть много разных руководств, часть из них
> используют простые люди (те не программисты), например du и dd, а часть -
> профессионалы, например mkfifo.
> И подскажите пожалуйста - как man преобразовать в po?

Зависит от сопровождающего. Я думаю, man'ы при таком количества должны
принимать и по одному. Если делать вычитку/рецензирование, наверное, лучше
некоторыми группами.

Re: Перевод apt 1.6

[Sergey Alyoshin]

Предложения по переводу

2018-03-09 11:24 GMT+03:00 Gali Anikina :
> #: apt-pkg/contrib/fileutl.cc apt-pkg/contrib/gpgv.cc
> apt-pkg/deb/debsystem.cc
> #: cmdline/apt-dump-solver.cc
> #, c-format
> msgid "Waited for %s but it wasn't there"
> msgstr "Ожидалось завершение процесса %s, но он не был запущен"

"Ожидание %s, но его нет"


> #: cmdline/apt-dump-solver.cc
> msgid ""
> "Usage: apt-dump-solver\n"
> "\n"
> "apt-dump-solver is an interface to store an EDSP scenario in\n"
> "a file and optionally forwards it to another solver.\n"
> msgstr ""
> "Использование: apt-dump-solver\n"
> "\n"
> "apt-dump-solver есть интерфейс, расположенный в сценарии EDSP в файле \n"
> "and optionally forwards it to another solver.\n"

"Использование: apt-dump-solver\n"
"\n"
"apt-dump-solver -- интерфейс хранения сценария EDSP в файле\n"
"и возможности передачи его другому решателю.\n"

Если solver по переводу решатель, был planner?

Не ставьте пробел перед '\n' (особенно если его нет в оригинале). При выводе в
терминал, если пробел не поместиться в строку, то будет перенесён на новую, а
потом будет перенос \n, то есть получится визуально пустая строка (с одним
пробелом).

Re: apt-1.6~beta1 перевожу, там немного

[Sergey Alyoshin]

2018-03-08 10:36 GMT+03:00 Sergey Alyoshin <alyoshi...@gmail.com>:
> 2018-03-08 7:38 GMT+03:00 Gali Anikina <meril...@yandex.ru>:
>>
>>
>> 07.03.2018 16:11, Sergey Alyoshin пишет:
>>>
>>> 2018-03-07 14:56 GMT+03:00 Gali Anikina <meril...@yandex.ru>:
>>>>
>>>> Подскажит- может кто знает как самой из исходных создать файл pot или po?
>>>
>>>
>>> Код xgettext
>>> (make -C po update-po)
>>
>>
>> Это мы программе make указываем каталог po в исходных.
>> Она пишет - по русски, что не может его найти.
>> А если внутри исходников нет такого каталога и вообще нет po или pot-файла?
>> Например пакет htop
>> Хотела взять маленький po и его по быстрому перевести (для "нарабатывания
>> навыков") :-
>> Не получилось по быстрому, там нет - ни po, ни pot.
>
> Если там нет po (или другой системы перевода, например, Qt Linguist .ts) и 
> есть
> желание перевести, то надо отметить в исходном коде строки _() и N_() (и 
> другие
> с количеством, с контекстом), включить заголовочные файлы с определением этих
> макросов или функций, добавить в настройку (autoconf или другие) поддержку
> gettext. Потом выполнить make -C po update-po.
>
> Если программа не переведена ни на один язык, может лучше заняться другой?

Но если решили, то стоит сначала сообщить об этом разработчикам программы.

Re: apt-1.6~beta1 перевожу, там немного

[Sergey Alyoshin]

2018-03-08 7:38 GMT+03:00 Gali Anikina <meril...@yandex.ru>:
>
>
> 07.03.2018 16:11, Sergey Alyoshin пишет:
>>
>> 2018-03-07 14:56 GMT+03:00 Gali Anikina <meril...@yandex.ru>:
>>>
>>> Подскажит- может кто знает как самой из исходных создать файл pot или po?
>>
>>
>> Код xgettext
>> (make -C po update-po)
>
>
> Это мы программе make указываем каталог po в исходных.
> Она пишет - по русски, что не может его найти.
> А если внутри исходников нет такого каталога и вообще нет po или pot-файла?
> Например пакет htop
> Хотела взять маленький po и его по быстрому перевести (для "нарабатывания
> навыков") :-
> Не получилось по быстрому, там нет - ни po, ни pot.

Если там нет po (или другой системы перевода, например, Qt Linguist .ts) и есть
желание перевести, то надо отметить в исходном коде строки _() и N_() (и другие
с количеством, с контекстом), включить заголовочные файлы с определением этих
макросов или функций, добавить в настройку (autoconf или другие) поддержку
gettext. Потом выполнить make -C po update-po.

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

Re: apt-1.6~beta1 перевожу, там немного

[Sergey Alyoshin]

2018-03-07 14:56 GMT+03:00 Gali Anikina :
> 07.03.2018 12:19, Lev Lamberov пишет:
>>
>> Об это стоит сообщить разработчикам через систему отслеживания ошибок.
>> За одно есть мотивация разобраться с reportbug.
>
>
> Подскажит- может кто знает как самой из исходных создать файл pot или po?

Код xgettext
(make -C po update-po)

Текст в .po po4a

Из .mo в .po msgunfmt
Проверка .po msgfmt -cv
Объединение и переносы строк msgmerge

Re: надо ли переводить некоторые названия переменных в функции на языке Си

[Sergey Alyoshin]

2018-03-06 17:01 GMT+03:00 Sergey Alyoshin <alyoshi...@gmail.com>:
> Я думаю что это своеобразный способ унификации
> строк и первая буква пропускается при выводе сообщения программой, видимо были
> причины не использовать возможность указать контекст. Надо посмотреть по коду.

В .pot файле в самом начале есть комментарий к переводу этих строк.
Первую букву надо оставить не переведённой.

Re: надо ли переводить некоторые названия переменных в функции на языке Си

[Sergey Alyoshin]

2018-03-06 16:39 GMT+03:00 Gali Anikina :

>> Это вопрос про вывод программой строк отмеченных N_()?
>>
> Да, то есть строки вида "N_("aextended attribute")" переводить не буду -
> заглянула в книгу Програмирование на языке Си Подбельский В.В. и Фомин С.С.
> Москва Финансы и статистика 2001, у них при создании структуры так
> перечисляются внутри структурные типы и если программист хочет, то может
> добавить описания - например так-
> N_("aextended attribute");  /*текст*/
> Вот если бы в этом файле были такие пояснения напротив вводимых структурных
> типов, тогда да-эти пояснения надо было бы переводить, но они бы не повлияли
> на работу программы, а сами названия структурных типов - "N_("aextended
> attribute")" не трогать. Исходя из этого я и сделала вывод, что эти строки
> не надо переводить.

Если бы их не надо был переводить, они не были бы отмечены N_() для перевода
(deferred translations). Это не названия переменных или полей структуры, это
массив из константных строк. Я думаю что это своеобразный способ унификации
строк и первая буква пропускается при выводе сообщения программой, видимо были
причины не использовать возможность указать контекст. Надо посмотреть по коду.

В целом действительные названия функций, если они и попали в перевод,
переводить, разумеется, не надо, как их переведённые искать по исходному коду
или сообщать об ошибке?

Re: надо ли переводить некоторые названия переменных в функции на языке Си

[Sergey Alyoshin]

2018-03-06 7:14 GMT+03:00 Gali Anikina :
> При переводе po программы e2fsck столкнулась с такой проблемой
>
> Надо перевести
> #: e2fsck/message.c:116
> msgid "aextended attribute"

Может быть, игнорировать первый символ (т.е. "расширенные атрибуты"), или
посмотреть как сделали переводы на другие языки.


> Например
> The bad blocks inode
> мог бы там выглядеть как
> Иноде плохого блок   - и далее N иноде

Я бы не переводил inode, т.е. "inode сбойных блоков".

> msgstr ""

inode групповой квоты

> msgstr ""

inode загрузчика


> Поскольку данная программа используется для проверки файловых систем, то в
> какие-то моменты она выдаёт сообщения пользователю. В Си это делается через
> print* - разные их варианты, а здесь получается по другому.

Это вопрос про вывод программой строк отмеченных N_()?

Re: RFR apt-listchanges

[Sergey Alyoshin]

Лев, при всем уважении, но git, emacs и даже reportbug для перевода не
обязательны и не надо ими запугивать новичка.

Переводы без вопросов принимаются как файлы .po или архивы (gzip, bz2,
tar для файла не нужен, только для архива каталога).
И отправляются по email на b...@debian.org с описанием в теле письма и
приложением архива ru.po.gz

Например:

Package: apt-listbugs
Version: 0.1.22
Priority: wishlist
Tags: l10n

Я думаю этого достаточно при небольшом количестве объёмных переводов.

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

По поводу git (как и других систем контроля версий), переводчику
бывает нужно получить исходные коды (это можно сделать скопировав
актуальный архив исходных кодов), чтобы обновить .po файл, если этого
не успели сделать разработчики, обычно это выполняет команда
  make -C po update-po

Отправлять патчи .po не вижу смысла, так как наложить их может не
получиться. Так как .po обрабатывается программами, а не только
человеком, то проблемы могут быть даже с количеством символов в строке
для переноса. Я отправляю патчи, только чтобы другие переводчики могли
быстро просмотреть изменения, высказать замечания и это не git
format-patch.

Re: RFR apt-listchanges

[Sergey Alyoshin]

2018-03-04 0:32 GMT+03:00 Lev Lamberov :

>> написала так - подойдёт?-
>> Сообщения, поступившие от APT:
>
>ОК, хороший нейтральный вариант.

Можно "Сообщения от APT:"


>> Слово "дескриптор" узкоспециализировано и простому человеку оно
>> малоизвестно или он его вообще не знает.
>
> Никогда не встречал варианта "заголовок файла". Всё же от заголовка в
> смысле header это сильно отличается. Как не спутать?
>
> Вот перевод из словаря:
> https://www.multitran.ru/c/m.exe?CL=1=file+descriptor=1
>
> Вот статья из вики (в русской версии там именно "дескриптор"):
> https://en.wikipedia.org/wiki/File_descriptor

Речь именно о файловом дескрипторе (файла из переменной окружения
$APT_HOOK_INFO_FD).
Я не посмотрел код и понял неправильно. Сообщение какое есть и
придётся переводить его
узкоспециализированно.

Re: RFR apt-listchanges

[Sergey Alyoshin]

2018-03-02 18:00 GMT+03:00 Gali Anikina :
> Здравствуйте.
> Доперевела apt-listchanges  ru.po с git
> Проверьте пожалуйста
> Через reportbug не получилось - первый раз пыталась пользоваться :-((
> Если нормально - то может кто-то пошлет через reportbug ?
> Приложение ru.po
> Галина

Изменения (diff.txt) и изменённый файл (ru.po).

P.S. Похоже что перенос строк в прилагаемом вами файле в формате DOS?


diff.txt.gz
Description: application/gzip


ru.po.gz
Description: application/gzip

Re: Backup

[Sergey Spiridonov]

Привет

On Thu, 15 Feb 2018 22:59:07 +0300
artiom  wrote:

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

Под описание полностью подходит backuppc. Единственное чего нет из
коробки - репликации в облако, но это несложно доделать - просто по
крону закидывать хранилище в облако.

Бэкап через Интернет и репликация в Интернет накладывает ограничение на
объём данных/ширину канала, но это не сильно зависит от приложения.

Я сам пользуюсь backuppc больше десятка лет для бэкапа до 15 машин.
-- 
С уважением, Сергей Спиридонов

Re: Снова о ZFS

[Sergey Matveev]

*** Sergey Matveev [2018-01-16 00:15]:
>https://blogs.oracle.com/darren/zfs-encryption-what-is-on-disk
>Не знаю поменялось ли это в ZFS-е, но там говорят что L2ARC недоступен
>для использования зашифрованным dataset-ам.

Статья устарела. В https://youtu.be/frnLiXclAMo где точно актуальный
разработчик они L2ARC уже шифруют.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: Снова о ZFS

[Sergey Matveev]

*** artiom [2018-01-18 21:53]:
>А что там за проблема с тем, что зеркало будет обеспечивать GEOM, была?

Ну как минимум зачем это делать когда ZFS это тоже может? Во-первых,
меньше на одну прослойку из gmirror (или что там). Во-вторых, ZFS сам
это всё будет подхватывать. В-третьих, resilvering зеркала в ZFS, если
оно не сильно забито, существенно быстрее происходит чем обычного
RAID-а. Обычный RAID понятия не имеет какие данные актуальны на каком
диске -- он по сути делает последовательное полное чтение с одного диска
и запись на другой. А ZFS, увидев что диск был частью зеркала, найдёт
его последние актуальные данные и ссинхронизирует только diff. Если диск
не был в зеркале, то зальёт на него только полезную нагрузку
(терабайтный pool заполнен на 50 гигабайт? только эти 50 GB и будут
записаны на зеркало). В-четвёртых, если данные испортились на каком-либо
из дисков (ну ошибки, сыпется что-то), то из-за контрольных сумм точно
известно где данные корректные и он их восстановит на втором
(self-healing типа).

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: тормоза ZFS

[Sergey Matveev]

*** Alex Kicelew [2018-01-17 23:13]:
>Поэтому может кто-нибудь (возможно, Sergey Matveev:)
>знает, можно ли как-нибудь понять, за каким чертом он минут 5-15 читает
>диск.

Ух, даже не знаю что тут сказать. Вообще не могу предположить что именно
ZFS мог бы делать. В фоне на долго ZFS обычно может делать только три
вещи, как правило: scrub, resilver и destroy (когда async_destroy
включен). На чтение из них только scrub работает. Но ARC сам по себе не
будет просто так брать и освобождаться -- аналогично кэшу обычной ФС
(cached поле в top/free). ARC уменьшиться в размерах только если
какое-то приложение хочет памяти больше чем осталось -- тогда его
вытесняют. ZFS может тупить например на секунды, допустим десятки секунд
-- сбрасывая буферы TXG на диски, но тут нет речи о минутах. Мне кажется
что это кто-то сторонний что-то начинает делать.

Я не мало работал на системах с 4, 8 и 16 GB памяти и везде с HDD. 4 GB
отличаются только тем, что по-умолчанию отключен read prefetch (но он
ничего не может сделать чтобы система на минуты уходила "тупить").
Нагрузки были самые разные: и sequential read/write больших файлов и
PostgreSQL с десятками GB БД и MongoDB которые упирались в IOPS диска.
Но везде FreeBSD/HardenedBSD. Так что может быть это какие-то косяки в
Linux реализации? Хотя коллега с GNU/Linux говорит что у него на 4 GB с
HDD ни разу ничего похожего на ваше поведение не встречалось. Но мне
кажется что это не в ZFS дело, раз размер ARC уменьшается -- его значит
кто-то другой вытесняет.

Можно попробовать например кэшировать только метаинформацию в ARC,
возможно только для заданных dataset-ов, выставив zfs set
primarycache=metadata. Не исключено что data регулярно вытесняет
metadata и диск вынужден снова и снова лезть за ней на диск. Но это
мысли в слух.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: Снова о ZFS

[Sergey Matveev]

|6 TB (50%)  |6 
(1/VDEV) |
|-+---++-++-++---|
|12   |4 x 3 disk Mirror  |3000|1000 |1200|400  |4 TB (33%)  |8 
(2/VDEV) |
|-+---++-++-++---|
|12   |1 x 12 disk RAID-Z1|250 |250  |1100|1100 |11 TB (92%) |1 
 |
|-+---++-++-++---|
|12   |2 x 6 disk RAID-Z1 |500 |500  |1000|1000 |10 TB (83%) |2 
(1/VDEV) |
|-+---++-++-++---|
|12   |3 x 4 disk RAID-Z1 |750 |750  |900 |900  |9 TB (75%)  |3 
(1/VDEV) |
|-+---++-++-++---|
|12   |1 x 12-disk RAID-Z2|250 |250  |1000|1000 |10 TB (83%) |2 
 |
|-+---++-++-++---|
|12   |2 x 6-disk RAID-Z2 |500 |500  |800 |800  |8 TB (66%)  |4 
(2/VDEV) |
|-+---++-++-++---|
|12   |1 x 12-disk RAID-Z3|250 |250  |900 |900  |9 TB (75%)  |3 
 |
|-+---++-++-++---|
|12   |2 x 6-disk RAID-Z3 |500 |500  |600 |600  |6TB (50%)   |6 
(3/VDEV) |
++

++
|Disks|Config |ReadIOPS|WriteIOPS|ReadMB/s|WriteMB/s|Usable 
Space|Fault Tolerance|
|-+---++-++-++---|
|36   |18 x 2 disk Mirror |9000|4500 |3600|1800 |18 TB (50%) 
|18 (1/VDEV)|
|-+---++-++-++---|
|36   |12 x 3 disk Mirror |9000|3000 |3600|1200 |12 TB (33%) 
|24 (2/VDEV)|
|-+---++-++-++---|
|36   |1 x 36 disk RAID-Z2|250 |250  |3400|3400 |34 TB (94%) |2 
 |
|-+---++-++-++---|
|36   |2 x 18 disk RAID-Z2|500 |500  |3200|3200 |32 TB (89%) |4 
(2/VDEV) |
|-+---++-++-++---|
|36   |4 x 9 disk RAID-Z2 |1000|1000 |2800|2800 |28 TB (78%) |8 
(2/VDEV) |
|-+---++-++-++---|
|36   |6 x 6 disk RAID-Z2 |1500|1500 |2400|2400 |24 TB (66%) 
|12 (2/VDEV)|
+----+

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: Снова о ZFS

[Sergey Matveev]

*** artiom [2018-01-16 08:37]:
>- Либо я использую ZFS шифрование и теряю L2ARC (т.е. часть
>производительности).
>- Либо я использую Gely, усложняю систему и теряю часть возможностей и
>производительности ZFS.

Ну насчёт заметной потери (чтобы об этом можно было думать)
производительности не уверен, ну а так да -- всё верно.

>- Докупаю 2x100 Гб (достаточно 50 Гб или не стоит жадничать?) в зеркало.
>- На них делаю два раздела поверх gely: OS и ZIL.
>- SSD на 250 Гб отвожу под L2ARC (корзина на 2.5" забита, там три диска
>всего).
>- На SAS делаю Gely слой (предполагается, что все диско-специфичные
>ioctl будут проброшены вниз, но так ли это?).
>- Организую из 4-х SAS ZRAID1 (достаточно ли 1, а не 2?).

Раз ZIL в зеркале, то вопрос надёжности снят.

По поводу ioctl ничего не могу сказать, не задавался этим вопросом.

RAIDZ какого уровня это tradeoff между кол-ом дисков сколько могут
вылететь, IOPS-ами, потерянным местом -- можно и 1, можно и 2. В
домашних условиях сервер же будет под "присмотром" -- поэтому вылет
диска будет обнаружен во вменяемое время и заменён для resilver-а.

Не забыть что и ZIL и L2ARC разделы тоже надо поверх GELI сделать. Я
кстати L2ARC делаю поверх раздела зашифрованного одноразовым ключом
(geli onetime gpt/SSDCACHE ; zpool add storage cache gpt/SSDCACHE.eli):
после перезагрузки он конечно всё "потеряет", но зато ключи нигде не
надо хранить и загружать.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: Снова о ZFS

[Sergey Matveev]

*** artiom [2018-01-16 00:06]:
>Я смотрю с другой стороны: есть пространство на SSD. Оно либо будет не
>использовано, либо использовано под ZIL/L2ARC. Почему бы и нет?

Согласен. Но лучше под кэш :-), лично по мне. Хуже не будет, а профит
очень даже можно получить. А выделенное место под ZIL на системе где
возможно вообще fsync-ов софт делать не будет -- полностью бесполезно.

Ещё кстати L2ARC может использоваться для хранения таблиц дедупликации.
Она требует приличных объёмов памяти (зависит количества от того как всё
устроено, как данные лежат, но говорят про 5 гигабайт RAM/L2ARC нужно на
терабайт данных). Сам, правда, не пробовал никогда.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: Снова о ZFS

[Sergey Matveev]

Есть вот статья про ZFS шифрование:
https://blogs.oracle.com/darren/zfs-encryption-what-is-on-disk
Не знаю поменялось ли это в ZFS-е, но там говорят что L2ARC недоступен
для использования зашифрованным dataset-ам. ZIL точно шифруется. В общем
лично для себя я отмечаю что GELI/LUKS спокойнее как-то использовать,
без вот этих вот особенностей что L2ARC будет недоступен.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: Снова о ZFS

[Sergey Matveev]

*** artiom [2018-01-15 23:25]:
>SSD на 250 Гб, чем ещё забить? Возможно, конечно, L2ARC организовать. Надо?

Лично я бы точно не ZIL-ом бы его забивал и вряд ли бы вообще (если нет
нагруженного PostgreSQL или Postfix какого-нибудь) под него выделял
что-то. ZIL может быть абсолютно бесполезен и, как мне кажется, для
большинства он таков. А вот L2ARC почему бы и нет.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: Снова о ZFS

[Sergey Matveev]

*** artiom [2018-01-15 00:29]:
>Вот это наталкивает на мысли (пусть оно и для ZIL):
>"After a crash, ZFS will attempt to replay the ZIL contents. SSDs
>themselves have a volatile write cache, so they may lose data during a
>bad shutdown. To ensure the ZFS write cache replay has all of your
>inflight writes, the SSD devices used for dedicated ZIL devices should
>have power protection. HGST makes a number of devices that are
>specifically targeted as dedicated ZFS ZIL devices."

А, ну то бишь это как и HDD специально сделанные для NAS решений: как бы
без write cache-а. Разумно. Действительно полезно. На HDD часто просто
можно отключать этот write cache и нивелировать проблемы внезапного
выключения.

>Оттуда же (насчёт производительности):
>"A key thing to know here is a ZFS vdev gives the IOPs performance of
>one device in the vdev. That means that if you create a RAIDZ2 of ten
>drives, it will have the capacity of 8 drives but it will have the IOPs
>performance of a single drive."

Для random IOPS всё верно. Sequential read будет всё же быстрее.

>>> Вопрос по загрузке возникает. В Linux эта проблема решается через
>>> вынесение ядра и initrd с cryptsetup на отдельный раздел. Здесь тоже самое?
>Каким образом (FreeBSD давно был)? Нужен отдельный незашифрованный раздел?

Да, просто отдельный раздел где будет загрузчик с ядром и модулями
которые они подгружают. В самом man-е GELI есть примеры касающиеся boot:
https://www.unix.com/man-page/FreeBSD/8/geli/
(/boot/loader.conf)

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF