13 марта состоялся выпуск nomacs 3.14 π — просмотрщика изображений с поддержкой множества форматов, включая RAW и psd.

( читать дальше... )

>>> Подробности

10 дней назад состоялся выпуск/обновление сабжа.

Поддержку C++ снова не добавили и по прежнему пока предлагают использовать плагины от версии 8.2.

Новость на opennet появилась сегодня

https://www.reddit.com/r/cpp/comments/f47x4o/202002_prague_iso_c_committee_trip_report_c20_is/

Желающие могут попробовать написать новость.

По виду std::format больше похож на fmt, чем на boost::format, что не может не радовать.

Небольшой обзор есть в статье на Хабре: https://m.habr.com/ru/company/yandex/blog/488588/ от Антона Полухина.

Никак не получается создать правило средствами gnu make, которое собирало бы несколько целей со схожими именами.

Например, пусть есть проект с такой структурой (на самом деле файлов намного больше, но отдельные правила под каждый создавать не хочется)

exe
    /obj
src
    /lib/lib.c
    /tests
        /test-1.c
        /test-2.c
makefile

подкаталоги «exe» пока пустые, о них позже.

имеющиеся файлы:

// lib.c 
#include <stdio.h>

void print_nothing() {
    printf("nothing ");
}

// test-1.c 
#include <stdio.h>
void print_nothing();

int main() {
    print_nothing();
    printf("to say\n");
    return 0;
}

// test-2.c 
#include <stdio.h>
void print_nothing();

int main() {
    print_nothing();
    printf("to say again\n");
    return 0;
}

и собственно сам makefile:

$ cat makefile 
#!/usr/bin/make
MAKEFLAGS = -j 1
CC = gcc

#DOBJ = exe/obj/
#DMOD = exe/mod/
#DEXE = exe/
DOBJ = src/tests/
DMOD = src/tests/
DEXE = src/tests/

MKDIRS  = $(DOBJ) $(DMOD) $(DEXE)

#auxiliary variables
COTEXT = "Compile $(<F)"
LITEXT = "Assemble $@"

DTESTS=src/tests/
TESTS=$(basename $(notdir $(wildcard $(DTESTS)/*.c)))
TESTSOBJ=$(addsuffix .o, $(TESTS))
$(info TESTS: $(TESTS))
$(info TESTSOBJ: $(TESTSOBJ))

all: $(DEXE)$(TESTS)
#building rules
$(DEXE)$(TESTS): %: $(MKDIRS) %.o
        @echo $(LITEXT)
        @$(CC) $(DOBJ)*.o -o $@

#compiling rules
$(DOBJ)lib.o: src/lib/lib.c
        @echo $(COTEXT)
        @$(CC) -c $< -o $@

$(DOBJ)$(TESTSOBJ): %.o: %.c \
        $(DOBJ)lib.o
        @echo $(COTEXT)
        @$(CC) -c $< -o $@

– этот попытка использовать Static Pattern Rules.

Но в результате собирается только test-2:

$ make
TESTS: test-2 test-1
TESTSOBJ: test-2.o test-1.o
Compile lib.c
Compile test-2.c
Assemble src/tests/test-2
make: *** No rule to make target 'test-1.c', needed by 'test-1.o'.  Stop.

Уже пару дней не могу сообразить как это сделать, а создавать под сотню правил очень не хочется.

А вот теперь о подкаталогах в exe: в makefile есть закоментированные строки

#DOBJ = exe/obj/
#DMOD = exe/mod/
#DEXE = exe/

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

В конце прошлого начале этого года ряд компаний по традиции обновили своикроссплатформенные компиляторы и дополнительные инструменты, прежде всего для распараллеливания вычислений, для разработки на языках C, C++ и Fortran (в обязательном порядке):

PGI 2020.1. Community Edition версия компилятора выходит пару раз в год и по условиям лицензии ей разрешается пользоваться год с момента выхода. Текущая такая версия PGI CE 19.10.

Intel Parallel Studio XE 2020.

Absoft Pro Fortran 2020 - для разработки только на Fortran.

NAG Fortran Compiller 7.0.

AOCC 2.1 - набор компиляторов на основе llvm 9.0 (clang, flang) с патчами от AMD. Предположу, что в состав входит flang на основе старого проекта, а не переименованный f18, который собираются включить в поставку llvm 11, если снова не опоздают.

Во всех, где это возможно, заявлена полная поддержка C++17, местами продолжили добавлять/обновлять начальную поддержку C++20 и Fortran 2018.

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

В ряде дистрибутивов есть так называемые contrib или community репозитории.

Например, в Rosa явно указано, что пакеты из репозитория contrib собираются членами сообщества и не проверяются QA.

В Arch это пакеты принятые из AUR некими Trusted Users, которые ещё не «ментейнеры/разработчики» (почему?), но которых в тоже время, насколько я понял, непонятно самих кто контролирует в плане качества скриптов, которые ими пишутся. При этом

Некоторые из этих пакетов в конечном итоге могут оказаться в репозиториях core или extra, если разработчики посчитают их важными для дистрибутива.

В Debian я вообще не понял, что это такое.

В Gentoo аналог этому сейчас проект в стадии бета GURU. Proxy Maintainers не совсем то, так как QA там всё же «дерут» в хорошем смысле и пакеты находятся в основном дереве.

Кто и как решает важен ли пакет для дистрибутива или нет для переноса в основные репозитории? То есть перенос возможен только если пакетом станет заниматься официальный ментейнер?

С момента новости прошло несколько месяцев. В рамках включения кода в проект llvm компилятор f18 был переименован в flang (т.е. в рамках llvm теперь называется так же, как ранее разрабатывавшийся проект на C).

Планировалось, что код нового flang добавят в кодовую базу llvm перед заморозкой кодовой базы 20 января перед выходом 10-й версии, но не успели. Потому запланированные мероприятия откладываются. Возможно, успеют к заморозке 11-й версии llvm.

На одном из компов eix достаточно странно себя ведёт:

• Для ряда пакетов в выводе информации статуса указывает [?] вместо [I] - я бы ещё понял, если бы установленная версия уже отсутствовала в дереве, но это не так.
• Не отображает замаскированные пакеты посредством добавления [m] перед именем файла.

Система устанавливалась год назад; обновляется раз в 2-3 месяца; специально никакие конфиги для eix не правились.

На другом компе с более старой установкой такой проблемы нет. Не то, чтобы сильно мешало, но странно. Что значит вывод [?] из чтения man eix не совсем ясно, как и то, чем именно отличились эти пакеты, кроме того, что они размаскированы?

Со вчерашнего дня (23 декабря) пакеты остались без ментейнера. Удалять их из дерева пока никто не собирается.

Себе я их взять не смогу. О планах удаления python2.7 (все они его требуют) из дерева мне тоже пока ничего не известно.

Upd:

dev-vcs/mercurial-server остался без ментейнера с 9 января 2020.

dev-vcs/mercurial снова поддерживается ментейнером с 25 января 2020.

Список составлен на основе списка указанных шрифтов сайта https://www.fontsquirrel.com. В перечне из этого списка здесь не указан шрифт гарнитура Monoid. Не спрашивайте, почему. Мультивыбора нет.

Только нашёл нормальный клиент для android - Revolution IRC (поддерживает авторизацию через SASL), как выясняется, что его автор больше не может заниматься его разработкой.

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

Есть ещё (из бесплатных) CloudIRC, по отзывам неплохой и имеет bouncer, но обязательно требует аккаунт в своём сервисе, даже если bouncer не нужен.

Или же остаётся qicr, но им я тоже не пользовался.

К сожалению, с 28 октября пакеты media-gfx/{gimp,mypaint-brushes}, media-libs/{babl,gegl,libmypaint} остались без ментейнера. Действующий ментейнер, по какой-то причине решил прекратить свою деятельность по их поддержке. Старые версии просто так никуда не исчезнут, но до тех пор, пока не появится новый официальный ментейнер, не факт, что ebuild’ы для него будут обновлять. Возможно, кто-то и будет рассматривать pull-request’ы для него на github, но не факт.

Есть ли желающие продолжить поддержку пакета через проект proxy-maint? Или, возможно, кто-нибудь из присутствующих на ЛОР действующих gentoo dev захочет взять себе эти пакеты?

20-летию проекта Gentoo и приближающемуся 15-летию выхода выпуска Gentoo 2004.3 посвящается.

Gentoo is proud to present the world with Gentoo Linux 2004.3!

This is the final release of 2004 and is the culmination of the work of each of our developers. The main focus for this release was fixing bugs in previous releases and making the release tools more robust and easier to use.

источник

Именно так начиналось сообщение пресс-релиза к выпуску очередной версии дистрибутива Gentoo - Gentoo 2004.3, вышедшего 15 ноября 2004 года. Это было то далёкое и тёмное время, когда Gentoo издавался 4 раза в год в виде live-cd, который содержал загрузочный диск, stage3, слепок дерева portage, набор файлов в каталоге distfiles (драйвера fglrx и nvidia в комплекте) и документацию по установке и настройке - Gentoo Handbook. В дополнение к live-cd поставлялся packagecd, содержащий некоторые скомпилированные пакеты, например, практически все необходимые пакеты для полной установки kde-3.3.0, gnome-2.6.2 и xfce-4.0.6, и даже такие пакеты как openoffice-bin-1.1.3, mozilla-thunderbird-0.8, evolution-1.4.6, mozilla-firefox-1.0_pre, k3b-0.11.17, xmms-1.2.10.

Признаюсь честно, что впервые Gentoo я тогда ставил не с дисков этого выпуска. Скорее всего, это был Gentoo 2004.2 или 2004.1, но образы дисков того времени у меня сохранились только от 2004.3. К тому моменту в общежитии факультета все, как мне сказали, уже наигрались с SUSE Linux и популярность набирал Gentoo, который мне и предложил попробовать поставить однокурсник. С тех пор на мне лежит проклятие любого пользователя Gentoo, известное как «ожидание ebuild’а».

Представленные скриншоты сделаны в VirtualBox после загрузки образа в режиме livecd и после установки системы и дополнительной установкой KDE-3.3.0 с упомянутого packagecd. К сожалению, многие пакеты не удаётся собрать из исходников, так как для сборки они требуют патчи (отключать их было лень), которые уже недоступны для скачивания с зеркал.

В процессе настройки ядра 2.4.26 были выбраны следующие опции конфигурации:

Code maturity level options --->
    [*] Prompt for development and/or incomplete code/drivers

Processor type and features --->
    (Pentium-II/Celeron(Coppermine)) Processor family
    [*] Symmetric multi-processing support

Block devices --->
    <*> Loopback device support

ATA/IDE/MFM/RLL support --->
    IDE, ATA and ATAPI Block devices --->
        <*> Include IDE/ATA-2 DISK support
        [ ] Use multi-mode by default
        [*] Auto-Geometry Resizing support

Network device support --->
    Ethernet (1000 Mbit) --->
        <M> Intel(R) PRO/1000 Gigabit Ethernet Support

Character devices --->
    <*> /dev/agpgart (AGP Support)
    [*] Intel 440LX/BZ/GX and ... support
    [*] Intel I810I815I830M (on-board) support
    Direct Rendering Manager (XFree86 DRI support) --->
        [*] Direct Rendering Manager (XFree86 DRI support)
        <*> Intel I810
        [*] Enable XFree 4.1 ioctl interface by default

File systems --->
<*> Reiserfs support
<*> Ext3 journaling file system support
<*> DOS FAT fs support
<*> MSDOS fs support
<*> VFAT (Windows-95) fs support
<*> Squashed file system support
[*] Microsoft Joliet CDROM extensions
[*] NTFS file system support (read only)
<*> UDF file system support (read only)
[*] Virtual memory file system support (former shm fs)
[*] /proc file system support
[*] /dev file system support (EXPERIMENTAL)
[*] Automatically mount at boot
[ ] /dev/pts file system for Unix98 PTYs

Network File Systems --->
    <*> SMB file system support (to mount Windows shares etc.)\
    [*] Use a default NLS (NEW)
            Default Remote NLS Option: "cp866" (NEW)

Partition Types --->
    [*] Advanced partition selection
    [*] PC BIOS (MSDOS partition tables) support
    [*] Windows Logical Disk Manager (Dynamic Disk) support (EXPERIMENTAL) (NEW)

Native Language Support --->    
    Default NLS Option: "koi8-r" (NEW)
    <*> Codepage 437 (United States, Canada) (NEW)
    <*> Codepage 866 (Cyrillic/Russia) (NEW)
    <*> Windows CP1251 (Bulgarian, Belarusian) (NEW)
    <*> NLS ISO 8859-1 (Latin 1; Western European Languages) (NEW)
    <*> NLS ISO 8859-5 (Cyrillic) (NEW)
    <*> NLS KOI8-R (Russian) (NEW)
    <*> NLS UTF8 (NEW)

Console drivers --->
    [*] VGA text console
    [*] Video mode selection support
    Frame-buffer support --->
        [*] Support frame buffer devices (EXPERIMENTAL) (NEW)
        (Tux) Frame buffer Boot Logo
        [*] VESA VGA graphics console (NEW)

USB Support --->
<*> EHCI HCD (USB 2.0) support (EXPERIMENTAL)
<*> UHCI Alternative (x86. StrongARM, isosynchronous mode)
<*> OHCI (Compaq, iMacs, OPTi, SiS, ALi, ...) support
<*> USB Human Interface Device (full HID) support

Как более быстрый вариант можно было использовать genkernel all, который собрал бы ядро и модули в том же составе, что используется в самом live-cd.

Русскую локаль в терминале настроил указав в /etc/rc.conf опции KEYMAP="ru4" (переключение по CapsLock), CONSOLEFONT="cyr-sun16", CONSOLETRANSLATION="koi8-r_to_uni". Как уже упоминал, пересобрать glibc, из-за недоступности патчей, не было возможности, поэтому в konsole (kde) вместо кириллицы у меня отображались ?, но в других графических приложениях ввод кириллицы отображался нормально. Возможно, не хватало шрифтов и/или указания путей к ним в xorg.conf.

В самом файле /etc/X11/xorg.conf для успешного запуска сессии в другом терминале (т.к. использовался framebuffer) я создал секции InputDevice (указал Option "XkbOptions" "grp:switch,grp:alt_shift_toggle"), Device c заданием Driver "vesa" и BusID "PCI:0:2:0", Screen с указание режима 1024х768 - вряд ли мой монитор тогда поддерживал больше :)

KDE 3.3.0 до сих пор выглядит очень круто. К сожалению, его kxkb тогда (как и сейчас) я так и не смог заставить переключать раскладку, поэтому приходилось либо переключать её мышкой в трее по флажку, либо отрубить kxkb и пользоваться указанной выше опцией xorg.conf. Оформление окон Plastik я выбрал вместо варианта по умолчанию, так как он мне всегда нравился больше всего. И, конечно же, очень удобной фичей была возможность чтения man-страниц прямо в браузере konqueror.

Примерно полтора месяца назад у родителей перестал включаться их Samsung SF511-S01 (Intel Core i3 2310M 2.1 ГГц, GeForce GT 520M, 1366 x 768). На нём в своё время в dual boot стояла Gentoo, а чуть позже, после многолетнего перерыва в обновлениях, Rosa Linux.

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

Поэтому пока они задумались о покупке нового ноутбука до 30 тыс. Из их пожеланий - чтобы был слабее прошлого и с таким же размером экрана (15.6 дюймов)

Из моих пожеланий всё же посмотреть на ноутбуки

• обязательно новый;
• с разрешением 1920х1080;
• исключительно с HDD (500-1000 Гб);
• по всей видимости с core i3 7020U (не знаю можно смотреть в сторону с ryzen 3 и найти с ним что-нибудь нормальное?);
• Возможность расширения памяти, т.к. за такие деньги 6 или 8 гб, видимо, мне не найти, а значит, покупка будет с 4 Гб.

Кажется пока всё. Пока из претендентов:

• Dell Inspiron 3584-5178, 15.6", Intel Core i3 7020U 2.3ГГц, 4Гб, 1000Гб, Intel HD Graphics 620
• Lenovo IdeaPad 330-15IKB, 15.6", Intel Core i3 7020U 2.3ГГц, 4Гб, 500Гб, Intel HD Graphics 620

Насколько это удачные модели и модели лучше?
Возможно, стоит добавить ещё тыс. 5 и рассмотреть ноутбуки с ryzen5?

Update:
По мере обсуждения и выбора ноутбука бюджет покупки был увеличен до 37300 рублей и приобретён Dell Inspiron 3583-3122 (чёрный, win10): i3-8145u, ram 8 gb (занят один слот), ssd 256 gb (m.2 2280).

Документация к нему на оф. сайте достаточно обширная. Даже инструкция по разборке и обслуживанию внутренностей есть. Судя по ним из внутренних разъёмов только M.2 2280, два слота под память.

Загрузиться с флешки на нём не успел, так как образ на ней не поддерживал загрузку с UEFI, но его и Secure Boot можно отключить в настройках bios. Они действительно настолько же разнообразные, как описано в руководстве, что для ноутбуков достаточно необычно, на мой взгляд.

В связи с недавней новостью (Bitbucket прекращает поддержку mercurial) стало интересно, какими системами контроля версий пользуются пользователи LOR. Скорее всего первое место по популярности займёт git, но это не снижает ценности других систем в зависимости от потребностей в рамках работы над каким-либо проектом.

Постарался внести в список наиболее часто упоминаемые, как мне кажется, VCS. Доступен мультивыбор.

p.s.
Вариант «храню архивы, не пользуюсь VCS» включает в себя и просто создание копий директорий и/или файлов без архивирования.

21 сентября 2019 г. Apache Foundation объявил о выходе корректирующего выпуска Apache OpenOffice 4.1.7.

Основные изменения:

• Добавлена поддержка AdoptOpenJDK.
• Исправлена ошибка, приводящая к возможным падениям при выполнении кода Freetype.
• Исправлено падение приложения Writer при использовании «Врезки» («Frame») в OS/2.
• Исправлена ошибка, приводящая к тому, что логотип Apache OpenOffice TM на экране загрузки имел другой фон.
• Обновлены словари Asturian (ast), English (en-GB).

Примечания к выпуску.
Страница загрузки.

>>> Подробности

Логотип Arch Linux давно не давал мне покоя и сегодня ночью я решил предпринять вторую попытку. Тем более, что тогда я, похоже, просто не догадался для Virtuabox установить пакет, который сейчас называется xf86-video-vmware (WAT!?).

Раньше у Arch была расширенная версия инструкции по установке «Beginners’ guide» - насколько помню, достаточно подробное руководство, которое ничем не уступало Gentoo Handbook. Сейчас по какой-то причине его больше нет. Из-за этого, если пользователь давно не устанавливал систему, то ему, к сожалению, придётся перечитать сначала кучу документации в arch wiki (она есть и действительно хорошая), а то и вовсе будет проще открыть gentoo handbook (я так не делал), который содержит более подробные инструкции.

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

Из раздела настройки сети парой переходов можно добраться до статьи о dhcpcd, где сообщат, что сервис нужно start/enable и отправят читать статью о systemd, не приводя примера команды о_О. Серьёзно, после окончания настройки системы я могу не трогать сервисы годами, да и зачем?

Что случилось с документацией и почему из неё так старательно убраны все примеры из-за чего процесс установки настолько затягивается, если пользователь не помнит упомянутых команд?

Если опустить этот момент, то сам процесс установки даже упростился. На этапе установки набора base не предлагают что-то прописывать в конфиг. Кажется раньше наборы в одном из файлов конфигурации нужно было указывать или я с чем-то путаю. После установки набора base (nano в нём тоже есть) я установил только grub, mc, virtualbox-guest-utils, xf86-video-vmware, plasma-desktop, konsole, dolphin, opera и получил готовое рабочее окружение. В целом процесс занял не больше чем занял бы в случае, например, debian net-install.

Pacman работает действительно шустро. Пока не нашёл, где можно посмотреть список установленных мной пакетов без зависимостей, то есть то, что я привёл выше? И не успел поискать можно ли создавать что-то похожее на sets из gentoo, то есть свои наборы, а не готовые из репозитория?

Для унификации сборки пакетов и обновлений хочется удалить на физическом компе из CFLAGS параметр -march=native. Насколько безопасно для работоспособности системы будет смешивать пакеты со старыми настройками и новыми? Чую, что не должно поломаться, но всё равно неуютно.:)

В данный момент у меня в make.conf такие настройки:

CFLAGS="-march=native -O2 -pipe"
CXXFLAGS="${CFLAGS}"

В виртуалке (переносимая на разные компы) для тестов такие настройки:

CFLAGS="-O2 -pipe"
CXXFLAGS="${CFLAGS}"

Окружение и список пакетов в них примерно одинаковый, поэтому из виртуалки можно притащить бинарные архивы и распаковать в систему (и потом один раз собирать, а не 2). Или можно не торопясь потихоньку заменять? Тем более, что мне могут поставлять сборки с теми же настройками системы, как в виртуалке. CHOST прописан одинаковый.

Как обычно осуществляется разграничение прав доступа к репозитория git, когда некоторым авторизованным пользователям нужно запретить доступ даже на чтение из определённых каталогов?

Можно ли это сделать, например, в gitolite? Всё что нашёл о нём, что можно выставлять права доступа на чтение группе пользователей на ветки.

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

Возможно, подобная настройка реализуется в gitlab, но хотелось бы что-то «полегче».

Какие ещё бесплатные git серверы для разворачивания в своей сети сейчас ещё популярны? Можно ли подобное реализовать в Kallithea?

Может кто-нибудь ещё проверить, воспроизводится ли «баг» (или опции всё же разделяться должны всегда?)

Дано (возможно, что не так критично, что данные разнесены):

• глобальный конфиг git с указанной почтой и gpg-подписью;
• локальный конфиг в одной из реп с указанным именем.

Создаём коммит командой git commit -Ss или ребейзим ранее созданный коммит командой git commit --amend -Ss и видим, что строка Signed-off-by: имя фамилия <email> не добавляется в текст коммита.

Если выполнять команды как git commit -S -s или git commit --amend -S -s, то указанная строка появляется в тексте коммита.

Это для git-2.21. Для более новых (2.23 вышел, кстати) не проверял.