LINUX.ORG.RU

New 17.0 profiles in the Gentoo repository

 , ,


1

4

Прилетело вот такое в eselect news

2017-11-30-new-17-profiles
  Title                     New 17.0 profiles in the Gentoo repository
  Author                    Andreas K. Hüttel <dilfridge@gentoo.org>
  Posted                    2017-11-30
  Revision                  1

We have just added (for all arches except arm and mips, these follow
later) a new set of profiles with release version 17.0 to the Gentoo 
repository. These bring three changes:
1) The default C++ language version for applications is now C++14.
   This change is mostly relevant to Gentoo developers. It also
   means, however, that compilers earlier than GCC 6 are masked 
   and not supported for use as a system compiler anymore. Feel 
   free to unmask them if you need them for specific applications.
2) Where supported, GCC will now build position-independent
   executables (PIE) by default. This improves the overall
   security fingerprint. The switch from non-PIE to PIE binaries,
   however, requires some steps by users, as detailed below.
3) Up to now, hardened profiles were separate from the default
   profile tree. Now they are moving into the 17.0 profile
   as a feature there, similar to "no-multilib" and "systemd".

Please migrate away from the 13.0 profiles within the six weeks after
GCC 6.4.0 has been stabilized on your architecture. The 13.0 profiles
will be deprecated then and removed in half a year.

If you are not already running a hardened setup with PIE enabled, then
switching the profile involves the following steps: 
If not already done,
* Use gcc-config to select gcc-6.4.0 or later as system compiler
* Re-source /etc/profile:
    . /etc/profile
* Re-emerge libtool
    emerge -1 sys-devel/libtool
Then, 
* Select the new profile with eselect
* Re-emerge, in this sequence, gcc, binutils, and glibc
    emerge -1 sys-devel/gcc:6.4.0
    emerge -1 sys-devel/binutils
    emerge -1 sys-libs/glibc
* Rebuild your entire system
    emerge -e @world

Switching the profile from 13.0 to 17.0 modifies the settings of 
GCC 6 to generate PIE executables by default; thus, you need to do 
the rebuilds even if you have already used GCC 6 beforehand.
If you do not follow these steps you may get spurious build
failures when the linker tries unsuccessfully to combine non-PIE
and PIE code.

В общем, всё в принципе понятно, я сделал всё до последнего шага, а именно до

emerge -e @world
. Насколько действительно необходимо это делать? Что будет, если я это пропущу, и буду обновлять мир также, как и прежде?.. что может сломаться? Не очень понимаю.

Не хочется пересобирать действительно всё - может, достаточно пересобрать то, что необходимо - какие-то средства сборки, библиотеки?.. Что ещё, кроме gcc, binutils, glibc?

Насколько я знаю, PIE и не-PIE либы/проги не совместимы, поэтому нужно всё пересобирать.

RazrFalcon ★★★★★
()
Ответ на: комментарий от Harald

Вот как бы собрать только C++ программы? Пропустить бинарные пакеты (они «собираются» быстро, только распаковываются, но время впустую, энтропия увеличивается) как-то, исключить из @world (но при этом оставить в world файле, чтобы --depclean их не снёс, да и из возможные runtime зависимости таки пересобрать).

BattleCoder ★★★★★
() автор топика
Ответ на: комментарий от O02eg

Жаль только у меня не skylake, а всего лишь ivy bridge.

BattleCoder ★★★★★
() автор топика
Ответ на: комментарий от LongLiveUbuntu

Типа того, но лучше пройтись по всем библиотекам gcc,binutils, glib - мало ли, и исключить их самих.

anonymous
()
Ответ на: комментарий от anonymous

В общем, вывод такой, что набрать emerge -pe @world, потом пройтись по списку, вручную исключив из него что точно пересобирать не нужно? То есть немного муторно...

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

BattleCoder ★★★★★
() автор топика
Ответ на: комментарий от BattleCoder

Нет, можно equery f gcc binutils glib получить список файлов, потом отфильтровать библиотеки и перечислить их при запуске revdep-rebuild с опцией

--library NAME | -L NAME
Search  for  reverse dependencies for a particular library or group of libraries, rather than every library on the system. This option will unconditionally emerge packages that use the named library. Note: This option is used to force packages using the named library to be rebuilt even if they are not broken. NAME can be a  full  path  to  a library or basic regular expression.
и опцией --exclude исключить сами gcc binutils glib. Теоретически, сам не пробовал.

anonymous
()
Ответ на: комментарий от O02eg

И стали более лучше одеваться?

Это уже по мере обновления системы само произойдет.

LongLiveUbuntu ★★★★★
()
Ответ на: комментарий от BattleCoder

Вот как бы собрать только C++ программы?

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

emerge -e world --exclude "$(cat ./yourfile) gcc binutils glibc"

У меня для этого были костыли, но я их потерял вместе с диксом.

r3lgar ★★★★★
()

Будь мужиком, пересобери мир блеять.

anonymous
()
Ответ на: комментарий от deity

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

Тем более зима уже, пусть ноутбук ночью обогревает.

BattleCoder ★★★★★
() автор топика

Сколько ж у тебя пакетов, что проблема такая?

TheAnonymous ★★★★★
()
Ответ на: комментарий от deity

А почему qtwebengine собирается аж целых два часа? qtwebkit намного быстрее, всего лишь сорок минут. Что они там такое понапихали?

Давно не собирал libreoffice, надоело - решил, что libreoffice-bin вполне мне хватит - а вот с qt такое не прокатит, библиотека всё-таки.

По-моему ни один другой qt-пакет так долго не собирается, как qtwebengine...

P.S. Кстати да, ночи не хватило. Увы. вот как раз на этом qtwebengine всё застряло... как проснулся. ¯\_(ツ)_/¯

BattleCoder ★★★★★
() автор топика
Последнее исправление: BattleCoder (всего исправлений: 1)
Ответ на: комментарий от BattleCoder

залез посмотреть сколько времени ушло на сборку

Nova ~ # genlop -t qtwebengine
!!! Error: no merge found for 'qtwebengine'

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

qtwebkit есть патч рабочий по ссылке.

deity ★★★★
()

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

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

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

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

grem ★★★★★
()
Последнее исправление: grem (всего исправлений: 1)
Ответ на: комментарий от deity
    Sun Dec  3 15:16:58 2017 >>> app-office/libreoffice-5.4.3.2
       merge time: 1 hour, 4 minutes and 13 seconds.

 

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

deity ★★★★
()

В генте всегда бесило, что невозможно пересобрать мир со включенным USE=doc.

anonymous
()
Ответ на: комментарий от anonymous

избыточный use - для каждого пакета если нужен ставь, но глобально это тупость имхо

deity ★★★★
()
Ответ на: комментарий от BattleCoder

Я не могу вспомнить, как узнать общее установленное число пакетов в системе. Что-то их отображало, а что не помню.

Ну вот, ядро придётся сначала обновить :) то, которое стоит уже отсутствует в репозитории.

grem ★★★★★
()
Последнее исправление: grem (всего исправлений: 1)
Ответ на: комментарий от grem
equery list '*' | wc -l

лучше так, а то eix, похоже, не разделяет пакеты по слотам при подстчёте

grem ★★★★★
()
Ответ на: комментарий от BattleCoder

Уже почти закончил

Быстро, у меня на core i3 старом долго будет. Подумываю даже закомментить сначала пакеты в сетах, которыми не пользуюсь часто и удалить их c зависимостями depclean'ом. Всё равно фактически заново ставить.

grem ★★★★★
()

Эх, дошли руки наконец-то. 1069 пакетов, понеслось...

sehellion ★★★★★
()

эх гента, вернуться чтоли

x0r ★★★★★
()
Последнее исправление: x0r (всего исправлений: 1)

@world пересобирать не буду, пересобрал @system, всё работает, впрочем и до этого всё работало.

Deleted
()

1762 пакетов... задумался основательно почистить всякий хлам, что за время жизни системы накопился.... но система собиралась в screen.. успешно, кроме пары-тройки пакетов... наверное, стоило сначала почистить? зато несколько вечеров хорошие были, без ноута ))))

CATS
()

Я вот думаю, может поставить app-admin/hardening-check и им поискать что пересобирать надо

$ hardening-check /usr/sbin/sshd 
/usr/sbin/sshd:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: yes
 Read-only relocations: yes
 Immediate binding: yes

anonymous
()

Че то у меня после пересборки мира на 17х профилях quickpkg слома.. потратился или это известный баг а я слоупок?

init_6 ★★★★★
()

New 17.0 profiles breaks sys-libs/glibc multilib functionality

Для !Ъ А теперь со вкусом апельсина! Вот этим комитом.

Для Ъ не будет пишут про (re)emerge of 'sys-libs/glibc-2.25-r9' breaks multilib functionality. Но актуально и для sys-libs/glibc-2.26-r3 (проверено init_6).

Всем щастячка, здаровячка и счастливого шаббата и хануки! А в особенности mgorny!!! Да и всем чмоки в этам чатики.

init_6 ★★★★★
()
Ответ на: комментарий от BattleCoder

Не понял, что делать-то?

Если не жалко места quickpkg --include-unmodified-config=y $(eix --installed --only-names --nocolor) если жалко quickpkg sys-libs/glibc. Ещё лучше скачать и иметь свежий stage3 про запас.

Я вроде бы мир пересобрал, ничего не отвалилось

Баг выражается в циклическом preserve rebuild sys-devel/gcc из-за 32х битных либ в /lib32 на 17х профилях. sys-devel/gcc пересобрать невозможно. Дальше только фэйлы и глобальнопипец ибо glibc тоже приходит северный полярный лис.

Или я просто ещё не знаю этого?

Кто знает...

init_6 ★★★★★
()
Ответ на: комментарий от init_6

Ещё лучше скачать и иметь свежий stage3 про запас.

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

BattleCoder ★★★★★
() автор топика
Ответ на: комментарий от BattleCoder

ОК. Надеюсь, поправят.

Я надеюсь что успешно похмелятся а профиль я себе уже и сам откатил.

Ещё учти что фэйл может привести к неработоспособности всей системы поэтому live usb или второй линукс или бекап работоспособного конфига ;) в общем ты понял.

init_6 ★★★★★
()
Последнее исправление: init_6 (всего исправлений: 1)
Ответ на: комментарий от BattleCoder

Последствия bug#640796 вот такая ошибка:

!!! existing preserved libs:
>>> package: sys-libs/glibc-2.26-r3
 *  - /lib32/libpthread-2.26.so
 *  - /lib32/libpthread.so.0
 *      used by /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/32/libasan.so.4.0.0 (sys-devel/gcc-7.2.0)
 *      used by /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/32/libatomic.so.1.2.0 (sys-devel/gcc-7.2.0)
 *      used by /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/32/libgomp.so.1.0.0 (sys-devel/gcc-7.2.0)
 *      used by 2 other files
 *  - /lib32/libm-2.26.so
 *  - /lib32/libm.so.6
 *      used by /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/32/libasan.so.4.0.0 (sys-devel/gcc-7.2.0)
 *      used by /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/32/libstdc++.so.6.0.24 (sys-devel/gcc-7.2.0)
 *      used by /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/32/libubsan.so.0.0.0 (sys-devel/gcc-7.2.0)
 *  - /lib32/libdl-2.26.so
 *  - /lib32/libdl.so.2
 *      used by /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/32/libasan.so.4.0.0 (sys-devel/gcc-7.2.0)
 *      used by /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/32/libgomp.so.1.0.0 (sys-devel/gcc-7.2.0)
 *      used by /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/32/libubsan.so.0.0.0 (sys-devel/gcc-7.2.0)
 *      used by /usr/lib32/libsandbox.so (sys-apps/sandbox-2.12)
 *  - /lib32/libc-2.26.so
 *  - /lib32/libc.so.6
 *      used by /usr/bin/lddlibc4 (sys-libs/glibc-2.26-r3)
 *      used by /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/32/libasan.so.4.0.0 (sys-devel/gcc-7.2.0)
 *      used by /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/32/libatomic.so.1.2.0 (sys-devel/gcc-7.2.0)
 *      used by 13 other files
 *  - /lib32/ld-2.26.so
 *  - /lib32/ld-linux.so.2
 *      used by /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/32/libasan.so.4.0.0 (sys-devel/gcc-7.2.0)
 *      used by /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/32/libstdc++.so.6.0.24 (sys-devel/gcc-7.2.0)
 *  - /lib32/librt-2.26.so
 *  - /lib32/librt.so.1
 *      used by /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/32/libasan.so.4.0.0 (sys-devel/gcc-7.2.0)
 *      used by /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/32/libubsan.so.0.0.0 (sys-devel/gcc-7.2.0)
Use emerge @preserved-rebuild to rebuild packages using these libraries

И вот в этом месте уже всё. Всмысле gcc неработоспособен из-за того, что sys-libs/glibc уже пришел северный полярный лис. Версии glibc, gcc как видно из бага несущественны потому что ломает их профиль.

init_6 ★★★★★
()
Ответ на: комментарий от init_6

breaks multilib functionality
из-за 32х битных либ в /lib32

Поскольку давно не сидел за десктопной джентой и пользуюсь ею только как сервером x64 с no-multilib, поинтересуюсь, а зачем нынче вообще нужен зоопарк из 32/64 либ? Что его тянет? Только проприетарщина и wine?

GAMer ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.