Бэкпортировать libc6 версии 2.29 в Debian Buster (stable)

Можно пересобрать DEB-SRC более нового Glibc в твоей целевой системе. Как правильно собирать пакеты .deb.... (комментарий)

Вообще, в мою openSUSE новый Glibc вставал без пересборки, просто пакеты из более новых версий системы. Возможно, в Debian что-то по зависимостям не так. Поэтому просто пересобери DEB-SRC в своей системе.

Можешь также сравнить при помощи Meld старый и новый SPEC-файл (директорию debian в старых и новых исходниках). Вдруг что-то радикально изменилось, и нужно вносить изменения вручную.

как правильно собирать deb-src я знаю, спасибо.
дело в том, что control в deb-src libc6 2.31 содержит в себе:

Breaks: ... openssh-server (<< 1:8.1p1-5), libgegl-0.4-0 (<< 0.4.18),

что какбэ приведёт к тому, что я не попросту не смогу поставить GIMP и sshd в свою систему.

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

а вот deb-src для libc6 2.29 (минимально необходимая мне версия, в репозитории buster'а — 2.28) я пока не могу сходу найти.

собственно, об этом и вопрос.

Странно, как новый Glibc может ломать что-либо вообще.

Что насчёт обновить заодно и openssh и gegl?

Что насчёт обновить заодно и openssh и gegl?

The following packages will be upgraded:

  blueman libavcodec58 libavcodec58:i386 libavdevice58 libavfilter7 libavformat58 libavresample4 libavresample4:i386 libavutil56 libavutil56:i386 libcairo-gobject-perl libcairo-perl libcdio-cdda2
  libcdio-paranoia2 libcups2 libcups2:i386 libcurl3-gnutls libfreetype6 libfreetype6:i386 libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-0:i386 libgdk-pixbuf2.0-common libgirepository-1.0-1
  libglib-object-introspection-perl libglib-perl libglib2.0-0 libglib2.0-0:i386 libgnutls30 libgnutls30:i386 libgpm2:i386 libjson-glib-1.0-0 libjson-glib-1.0-0:i386 libjson-glib-1.0-common
  liblocale-gettext-perl libmount1 libmount1:i386 libnewt0.52 libnm0 libp11-kit0 libp11-kit0:i386 libpcre2-8-0 libpcsc-perl libpostproc55 libpython3-stdlib librubberband2 libsdl2-2.0-0
  libsdl2-2.0-0:i386 libselinux1 libselinux1:i386 libsnappy1v5 libsnappy1v5:i386 libswresample3 libswresample3:i386 libswscale5 libtasn1-6 libtasn1-6:i386 libtext-charwidth-perl libtext-iconv-perl
  libva-drm2 libva-drm2:i386 libva-wayland2 libva-x11-2 libva-x11-2:i386 libva2 libva2:i386 libwayland-server0 libzstd1 libzstd1:i386 network-manager p11-kit-modules perl perl-base ppp python3
  python3-apt python3-cairo python3-cffi-backend python3-dbus python3-gi python3-gi-cairo python3-minimal python3-pycurl

можно, конечно, но тогда уж проще bullseye накатить, чего я не хочу делать по иным причинам (новые версии некоторого софта, например XFCE, Network Manager, и ещё пара неочевидных вещей работают объективно хуже)

Странно, как новый Glibc может ломать что-либо вообще.

ещё раз: это написано английским по белому в рецепте сборки пакета.

т.е. какой-то меинтейнер вписал руками, что libc6 2.31 breaks libgegl-0.4-0 версии меньше, чем 0.4.18.
почему он это сделал — отдельный вопрос

там ещё более весёлые штуки, вроде

Package: libc6-dev
Breaks: libc6-dev-amd64-cross (<< 2.31~), libgcc-10-dev (<< 10-20200321-1~), libgcc-7-dev (<< 7.5.0-6~), libgcc-8-dev (<< 8.4.0-2~), libgcc-9-dev (<< 9.3.0-5~), libperl5.26 (<< 5.26.1-3), python3.7 (<< 3.7.7-1+b1), python3.8 (<< 3.8.2-1+b1)

libgegl можно попробовать пересобрать из DEB-SRC. Тогда он не потянет за собой обновляться пол-системы. Вот исподники: https://launchpad.net/ubuntu/ source/gegl/0.4.18-1

см. пост выше, пробелма не только в libgegl, там более фундаментальные штуки

Перечитал. Не-не, смотри, вот допустим у тебя пока что старая версия Glibc в системе. Теперь тебе надо установить новый openssh-server и libgegl, после чего можно будет накатывать новый Glibc.

Первый действием пересобираешь ssl и gegl, обновиви их до нужных версий.

Вторым действием устанавливаешь Glibc.

установка libc6 версии 2.29 решила бы все мои проблемы, если бы я был уверен в том, что она не Breaks: что-нибудь.

Ну не знаю, я вот обновлял в своей системе Glibc 2.7 до 2.17, и ничего не сломалось. 2.18 и более новая вставать не хочет, обидно (

мне нужна конкретно 2.29 (или выше), потому что это жёсткая зависимость для Mesa 20 (libgl1-mesa-dri=20.3.4-1)

Mesa 18 (которая в Debian Buster) и даже Mesa 19 не знает о моей слишком модной видеокарте, и поэтому 3D не работает:

ann@silvermoon:~$ glxgears 
pci id for fd 4: 8086:9a49, driver (null)
i965_dri.so does not support the 0x9a49 PCI ID.
libGL error: failed to create dri screen
libGL error: failed to load driver: i965

> потому что это жёсткая зависимость для Mesa 20

Пересобери Месу )

не получится уже, так как build dependencies не ставятся из-за того, что новый libc6-dev по его словам несовместим с старым питоном.

mesa20 и libc6 уже стоят из testing'а, и ничего не предвещало беды (С)


(нет, серьёзно, всю жизнь пихал в Debian Stable либц и мезу из тестинга и всё всегда работало и не ломало до такой степени)

Мне кажется, что если пересобрать Месу со старым Glibc, то она будет зависесть от старого Glibc. Как и любая другая прога. Просто верни старую версию libc6-dev

Зависимость от нового Glibc образовалась из-за того, что бинарники используют какие-то новые функции или вызовы. А чтобы не использовали, надо пересборать со старым Glibc.

Я по этой причине собираю весь свой совт в CentOS 6, SLES 11 и Debian 6.

не подскажешь, как малой кровью узнать, какие пакеты в системе требуют libc6 версии N или больше?

кроме как парсить список пакетов и в цикле чекать

Попробовать сделать даунгрейд через synaptic, не применяя изменений. А он подскажет.

Ну не знаю, я вот обновлял в своей системе Glibc 2.7 до 2.17, и ничего не сломалось.

Это в каком году было?

2.18 небось хочет каких-нибудь компиляторов/утилей посвежей и ядро не ниже какого-то.

Странно, как новый Glibc может ломать что-либо вообще.

Изменение поведения memcpy в glibc привело к странным ошибкам

почему он это сделал — отдельный вопрос

Был багрепорт, где попросили добавить, они и добавили.

А почему ты пытаешься бекпортировать libc? Обычно же предлагается бекпортировать само приложение и вспомогательные библиотеки.

либц — один deb-src
меза — куча пакетов, зависимостей, не факт, что 20 меза заведётся с libc6 2.28 и вот это всё

Это было в 2015 году.

Пакетов Месы много, а пакет с исходниками Месы - один.

С libc6 2.28 конечно заведётся. Это ОЧЕНЬ новая версия Glibc. Уверен что новая Меса и с Glibc 2.2.5 прекрасно будет работать, если её скомпилировать с ней.

Подозреваю XY-проблему. Чего ты хочешь этим добиться? Запустить какую-то конкретную программу можно и без таких сомнительных решений.

не факт, что 20 меза заведётся с libc6 2.28 и вот это всё

В Ubuntu же заводится.

либц — один deb-src

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

не факт, что 20 меза заведётся с libc6 2.28

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

в общем, так оказалось действительно проще.
Mesa 20 собралась, установилась и работает.

не подскажешь, как собрать на x86_64 хосте *.deb-пакеты для i386?

apt build-dep mesa:i386 говорит, что исходного пакета для данной архитектуры не найдено.

как собрать на x86_64 хосте *.deb-пакеты для i386?

В 32-битном chroot’е. Базовую систему можно подготовить с помощью debootstrap --arch=i386. В chroot нужно заходить с помощью linux32 bash, а не просто bash, чтобы uname -m сообщал о том, что это 32-битная система. Некоторые пакеты без этого не собираются. Не забудь bind’ами прокинуть в chroot /dev, /dev/pts, /proc и /sys.