Ошибка репозитория браузера Яндекс в Linux Mint

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

По истечении некоторого времени после установки в систему Яндекс Браузера при выполнении операции на поиск доступных обновлений система стала постоянно выдавать ошибку:

Чтение списков пакетов… Готово                                                
W: Ошибка GPG: http://repo.yandex.ru/yandex-browser/deb beta InRelease: Следующие подписи не могут быть проверены, так как недоступен открытый ключ: NO_PUBKEY 218017D1CC5FDB34
E: Репозиторий «http://repo.yandex.ru/yandex-browser/deb beta InRelease» не подписан.
N: Обновление из этого репозитория нельзя выполнить безопасным способом, и поэтому по умолчанию он отключён.
N: Смотрите справочную страницу apt-secure(8) о создании репозитория и настройке пользователя.

Странно, так как браузер устанавливался из пакета deb, скачанного с официальной страницы Яндекс браузера.

К слову сказать, служба поддержки Яндекса на сообщения реагирует, но ... Ниже пример переписки за 2016 г.

Здравствуйте!
Проблема, о которой Вы нам сообщали, устранена. Пожалуйста, проверьте, возникает ли она в последней версии браузера. Загрузить её можно на странице https://browser.yandex.ru/download/?linux=1 .

В 2017 году ситуация повторяется. Что ж, человек, помоги себе сам.

Идём на репозиторий и попытаемся там чего-нибудь найти. Кстати говоря, по этому адресу можно найти и deb-пакет с длинным названием. Почему тогда при скачивании Яндекс браузера качается пакет с коротким именем Yandex.deb остаётся загадкой.

Хорошо, любопытствуем дальше.

По адресу https://repo.yandex.ru/yandex-browser/ видим, что ключ, всё-таки, присутствует.

Ура! Вот она, нашлась, пропажа наша. Выполняем команды в терминале:

wget https://repo.yandex.ru/yandex-browser/YANDEX-BROWSER-KEY.GPG && sudo apt-key add YANDEX-BROWSER-KEY.GPG && sudo apt update

И система по поводу ключа перестала возмущаться, всё стало хорошо.

Запускаем менеджер обновлений, далее "Правка – Источники приложений – Проверка подлинности ключей" и констатируем присутствие злополучного ключа.

Также Яндекс браузер стал отображаться и в менеджере программ. Указываем в поиске Yandex и видим:

Почему-то при установке deb-пакета браузера Vivaldi и даже Vivaldi snapshot таких ситуаций никогда не возникало и ключ автоматически добавлялся в систему в процессе установки пакета.

Может быть потому, что у меня "гранаты не той системы", в смысле – система "неправильная" ? Неудивительно, что у нас до сих пор не потеряли актуальности три вопроса: 1) кто виноват, 2) что делать и 3) что делать с теми, кто виноват.

📌   Дополнение в 2023 г. Ошибка GPG Яндекс браузера в Linux Mint

Thunderbird+MEGA.nz: вложение больших файлов через MEGA.nz

Почтовый клиент Thunderbird при составлении сообщений может осуществлять операцию вложения в сообщение больших файлов через облачное хранилище MEGA. Совершение подобных действий уже встроено в почтовый клиент Thunderbird для службы облачного хранения box.net. Подробности можно прочитать здесь.

Чтобы почтовый клиент Thunderbird имел возможность соединения с облаком MEGA необходимо установить соответствующее дополнение.

По умолчанию, уже давно в Thunderbird не отображается панель меню.

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

После этого панель меню отобразится.

Вызовите "Инструменты – Дополнения" и перейдите на вкладку управления дополнениями и далее слева переключитесь на "Получить дополнения".

В строке поиска дополнений введите Megabird.

Дополнение Megabird будет отображено. Установите его.

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

Настройте соединение клиента Thunderbird c облаком MEGA. Вызовите в Thunderbird пункт меню "Правка – Настройки" и перейдите в раздел "Вложенные файлы".

Чуть ниже перейдите во вкладку "Исходящие".

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

Выберите службу MEGA, после чего запустится мастер настройки соединения с облаком.

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

Теперь при создании сообщения после команды "Вложить" и выбора файлов при достижении размера файла, при котором включается служба облачного хранения (см. выше в настройках клиента), в нижней части окна составления сообщения появится сообщение: "Это большой файл. Возможно, будет лучше использовать Filelink".

Справа от этого сообщения будут три кнопки. Нажмите "Создать ссылку".

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

Процесс загрузки файла (файлов в облако) будет запущен. В нижней части клиента Thunderbird отобразится информационное сообщение "Идёт процесс создания ссылки на ваш файл. Она появится в теле сообщения по завершении процесса".

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

Все Ваши файлы на MEGA зашифрованы, поэтому процесс создания ссылки будет превышать продолжительсть создания аналогичной ссылки при использовании службы box.net. 

Как только ссылка будет готова, то слева от файла появится значок MEGA, а в окне создания сообщения ссылка на файл.

Аналогично это будет отображено и для других файлов, если Вы вкладываете в сообщение несколько файлов.

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

Сообщение можно отправлять.

Когда получатель Вашего сообщения перейдёт по ссылке,

то ему будет выдан запрос:

Если у него не установлено клиента MEGA и он не имеет учётной записи MEGA, то ему следует нажимать "Загрузить в браузере".

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

В Вашем облаке MEGA вложенные файлы расположены в папке Thunderbird.

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

В отличие от ресурсов файлообмена файл(ы) на Вашем облаке MEGA будут храниться до тех пор, пока Вы их не удалите сами или пока существует Ваш аккаунт на MEGA.

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

Nemo в Linux Mint 18. Пункты "Копировать в" и "Переместить в"

Интересно было бы полюбопытствовать у разработчиков: чем они руководствовались, когда из правого контекстного меню мыши Nemo были убраны пункты "Копировать в" и "Переместить в". Надеюсь, что многие склонны были бы согласиться с тем, что данные пункты являются для пользователя одними из самых необходимых. Тем более, что в Linux Mint 17.2 они ещё имелись, но в 17.3 уже пропали. Мой интерес к данному вопросу подогревался также и тем обстоятельством, что в Live-режиме данные пункты имеются, но после установки системы чудесным образом исчезают.

Как показало "следствие", эти пункты, всё-таки, имеются, но доступны только через меню "Правка", например:

Ну-с, а теперь приступим к "лечению". Установите редактор dconf командой в терминале:  sudo apt install dconf-editor

В том же терминале запустите команду  sudo dconf-editor  или перейдите в "Меню – Администрирование – Редактор dconf".

А теперь поставьте галочку в поле "context-menu-show-all-actions" в секции preferences подраздела nemo раздела org:

После внесения изменений:

Runtu – gtk-update-icon-cache: команда не найдена

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

Всё было неплохо, всё было понятно, мелкие переделки в плане замены одних программ на другие, а также установка нужных не вызывали трудностей.

Однако существовала проблема, которую никак не удавалось решить.

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

Ну мы же все умные! Выбираем тему и в терминале вводим:

sudo gtk-update-icon-cache /usr/share/icons/каталог_темы

И вдруг наступает большой "облом": терминал уведомляет, что такая команда не найдена.

Не буду долго описывать тернистый путь поисков ответов в Интернет. Предложений по решению проблемы было много, но намёк содержался только в одном материале, из которого следовало, что gtk-update-icon-cache является файлом и располагается в каталоге usr/bin

Сначала мной было испытано потрясение, так как именно такого файла в системе не было найдено. Но ... был найден файл gtk-update-icon-cache-3.0

Уже и не надеясь ни на что выполняю в терминале команду:

sudo gtk-update-icon-cache-3.0 /usr/share/icons/каталог_темы

Сюрприз! Кэш-файл успешно создан.

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

Воистину, век живи, век учись, а дураком помрёшь.

Кстати, в Linux Mint присутствуют оба упоминаемых файла.

Post scriptum. После заданного на эту тему вопроса на форуме Runtu в ответ было получено 2 комментария.

1. Я пользуюсь такой командой sudo update-icon-caches /usr/share/icons/*

Пробую. Действительно, кэш-файлы создаются сразу для всех значков, но без вывода сообщения о создании таких файлов.

2. Файл gtk-update-icon-cache в каталоге /usr/bin является частью пакета libgtk2.0-bin, который я не устанавливаю по-умолчанию в дистрибутивы LITE и XFCE, т.к. они тянут с собой по зависимостям libgtk2.0-0 и прочую обвязку GTK+.

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

в ответ получаю

Ну ладно у меня всё ещё имеется природная любознательность. Но обычный пользователь пойдёт спрашивать на форум? Тем более, что в настоящее время поиск ответа на свой вопрос практически на каждом форуме превращается в поиск иголки в стоге сена. А если ещё учесть разгромные предупреждения движка форума типа "Прежде чем задать свой вопрос ....", то желание спрашивать как-то сразу убавляется. Но если нарвёшься на своеобразного гуру, то формирование комплекса собственной неполноценности (хотя бы даже на некоторое время) гарантировано.