LINUX.ORG.RU

nufraw 0.42 + gimp 2.10-9 (-git)

 , nufraw,


0

2

Вот, скомпилял ветку gimp-2.10 (поверх новых babl + gegl тоже из git). Для сборки по крайней мере gegl + gimp нужен уже хотя g++/C поновее, чем у меня были в gcc 4.8/gcc 4.9 — пришлось собирать с помощью clang 7 (который из пакета llvm, который нужен для mesa).

В общем после утаскивания кучи пакетов в сырцах от slackware-current и их сборки (там сейчас *.la файлы убили, а у меня они частично ещё используются — было весело, особенно с двумя libpng: 1.4 и 1.6) наконец-то получилось почти как надо. Собрал ещё nufraw (https://sourceforge.net/p/nufraw/blog/), теперь открывает разные raw и даже в 16-бит на канал. Но при этом автоопределение svg отвалилось, и если выбрать опцию сохранять exif в tiff — то полученный файл как бы имеет две страницы, но открыть можно только первую (по крайней мере в самом Гимпе), вторая судя по всему — метаданные.

Но в целом работает шустро, даже для 32-битного варианта, особенно если дать использовать 3 Гб памяти (максимум на 32-битной платформе).

>>> Просмотр (2880x900, 2275 Kb)

★★★★

Проверено: JB ()
Последнее исправление: cetjs2 (всего исправлений: 2)

Ответ на: комментарий от AP

можно подключить CI, встроенный в гитлаб

this

бомбануло от того, что мы не хотим переезжать на гитхаб

WHAT

обсуждаем на IRC

забавная реакция :)

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

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

Но у него бомбануло от того, что мы не хотим переезжать на гитхаб и дела проекта обсуждаем на IRC

С гитхаба можно Travis CI пользовать - у него весьма шустрые воркеры. sK1/UC2 сборка на трависе ночнухи собирает и автоматом паблишит. Весьма шустро получается.

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

Нет, далеко не новость. Но это единственное разумное объяснение бомбажа :) Кстати, чел мог бы просто из зеркала на гитхабе сделать CI, а не пытаться всех нагнуть на гитхаб.

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

А, теперь, PtiCa, я легко и изящно продемонстрирую тебе то, о чем уже сто раз говорил применительно к AP. Все его ответы «все хорошо, прекрасная маркиза» на самом деле не соответствуют истине и вот почему:

crypt@witch ~/gimp/gimp $ git log  --pretty=format:"%ar: %s" configure.ac |egrep "(GEGL|babl)"
3 weeks ago: configure.ac: require babl >= 0.1.60
3 weeks ago: configure.ac: require GEGL >= 0.4.13
6 weeks ago: configure/app: depend on GEGL 0.4.12
7 weeks ago: configure/app: depend on GEGL 0.4.10
9 weeks ago: app/configure: depend on babl-0.1.58
3 months ago: configure, app: depend on babl-0.1.57
4 months ago: configure.ac: require GEGL >= 0.4.9
4 months ago: configure/app: depend on GEGL 0.4.8
4 months ago: configure/app: depend on babl 0.1.56
4 months ago: configure.ac: require GEGL >= 0.4.7
4 months ago: configure/app: depend on GEGL 0.4.6
4 months ago: configure/app: depend on babl 0.1.54
5 months ago: configure.ac: require GEGL >= 0.4.5
5 months ago: configure.ac: require GEGL >= 0.4.4
5 months ago: configure.ac: require babl >= 0.1.52
6 months ago: configure.ac: require babl >= 0.1.51
6 months ago: configure.ac: require GEGL >= 0.4.3
7 months ago: configure.ac: require babl >= 0.1.50
7 months ago: Revert "depend on babl-0.1.50"
7 months ago: depend on babl-0.1.50
7 months ago: configure/app: depend on GEGL 0.4.2
7 months ago: configure/app: depend on babl-0.1.48
7 months ago: configure: argh! Forgot to AC_SUBST() the GEGL major-minor version.
7 months ago: configure, gimp.pc: do no hardcode the major.minor version of GEGL.
7 months ago: configure.ac: require GEGL >= 0.4.1
7 months ago: configure,app: depend on GEGL-0.4.0
8 months ago: configure.ac: reqire GEGL >= 0.3.34
8 months ago: configure/app: depend on GEGL 0.3.32
8 months ago: configure/app: depend on babl 0.1.46
8 months ago: configure.ac: require babl >= 0.1.45 and GEGL => 0.3.31
9 months ago: depend on GEGL 0.3.30
9 months ago: configure: make clearer the test for native GEGL executable.
10 months ago: configure.ac: require babl >= 0.1.44
10 months ago: configure.ac: require GEGL >= 0.3.29
11 months ago: configure.ac: require babl >= 0.1.42 and GEGL >= 0.3.28
11 months ago: configure: depend on babl 0.1.40 or newer
12 months ago: configure.ac: require GEGL => 0.3.27

То есть ты говоришь: «нужно зафиксировать». AP: «у нас все зафиксировано!» И посмотри сколько раз они бампили основные зависимости! Вы скажете: «ну так репозиторий для конкретного дистра решит проблему!» А вот и нифига. У самих GEGL и babl ситуация точно такая же! Я помню ситуацию с гимпом в районе ubuntu 10.04: под старую убунту сборщики оставляют старый гимп (срез из гита) потому что для установки нового с GEGL и babl полсистемы пересобрать надо, включая glib2, ломая все остальное, а новый гимп (более новый срез из гита) только для новой убунту. Что-то похожее продемонстрировано в топике выше, когда две libpng потребовались.:(

И такая хренотень у гимпа уже лет десять. Но AP как говорил, что все путем, так у него все путем на протяжении многих лет.

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

Мда, у тебя не система — нечто (в хорошем смысле).

Можешь снять .tar всех каталогов, кроме /home и прочих с личной инфой, и выложить куда-нибудь? Потыкать хочется, а самому такое делать — жуткая морока.

Vsevolod-linuxoid ★★★★★
()
Ответ на: комментарий от Deleted

Для тех, кто не понял, я не призываю использовать gcc4 и древние версии специальных либ. Все это собирается и запускается на c7 и ub1404. Как это делается, вообще-то, по-нормальному.

В Ubuntu все меняется между минорными релизами 14.04.1, 14.04.2... ты, очевидно, не в курсе, что 14.04 - это как раз GCC 4.6, а 14.04.4 - это GCC 4.8

также совершенно не понятно, с чего вдруг ты решил вычеркнуть c6 и начать с c7. он еще в поддержке, а твои вкусы тут как бы ни при чем.

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

Да, на убунте я постоянно на такое натыкаюсь, просто не помню уже.

Ну, мне (не применительно к гимпу, а к моим проектам), главное что бы собрано было с минимальным GLIBC_2.*** Обычно высокие glibc не требуются, а возникает лишь из-за сборки в слишком новом дистре. А все остальное, включая компиляторы, можно подложить свеженькие, для конкретного ПО. И в архив. Берем какой-нибудь centos 6 (даже не 7), и смотрим, чего там не хватае (обычно, конечно, очень многого). Но зато потом бинарник будет работать везде. Я думаю лично ты в курсе, просто озвучиваю свои мысли. Гимпом мне не особо хочется заняться, разьве что из спортивного интереса

(прав на счет c6!)

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

Гимпом мне не особо хочется заняться

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

p.s.

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

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

хорошо, что автор топика llvm догадался использовать

тоже мысленно похвалил

новый тулчейн с GCC по-моему целая эпопея добавлять.

просто для инфы, если использовать вот это https://github.com/crosstool-ng/crosstool-ng/ - то нет. Но да, это несколько не тривиально, но работает, причем достаточно гибко.

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

Но раз этого нет сейчас, значит потребности в CI особой нет.

у них есть дженкинс, выше дали ссылки. Для меня лично все прояснилось, я краем глаза поглядел на инфру: просто рук не хватает на все. Проект большой, я представляю примерно, что даже тупо настроить разные конфы сборки CI достаточно трудоемко. У них уже сделано многое. К сожалению, для меня не очевидно, как это расширять, я этот дженкинс ненавижу, он убивает кучу времени

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

у них есть дженкинс, выше дали ссылки

сорян, протупил.

дженкинс ненавижу, он убивает кучу времени

ну да, современные CI попроще будут.

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

AP: «у нас все зафиксировано!»

Выражение «зафиксировано» я понял иначе, поэтому и привёл ссылку на файл, где зафиксированы (т.е. полностью приведены) все зависимости. Но не суть.

Твоя ошибка — в непонимании того, какова роль babl/GEGL. Это проекты, которые используются гимпом на низком уровне (управление тайлами, конвертирование пиксельных форматов и проч.) и развиваются в угоду гимпа.

Бесполезно требовать фиксирования (в твоём понимании) версии babl/GEGL, от которой зависит GIMP, потому что GIMP тогда перестанет развиваться.

За время нынешнего цикла разработки 2.10.х/master в эти библиотеки как минимум попали изменения, необходимые для ускорения производительности, для повышения отзывчивости за счёт распараллеливания операций, не говоря уж о свежем коде поддержки цмика (пока не использутся в гимпе).

Видимо, с твоей точки зрения надо вернуться к старой модели, когда в стабильной ветки были только багфиксы, а новый релиз надо было ждать 4-6 лет (как это было с 2.8 и 2.10). И чтобы новые разработчики снова уходили, потому что ХЗ когда свой код в релизе увидишь.

Такой подход не просто дурацкий, он вредный для проекта. Это доказано практикой последних 10-15 лет разработки.

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

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

Приди и сделай.

Я серьёзно.

У нас была жопа со сборкой для мака. Пришёл Саморуков, которому оно было надо, и занялся вопросом вплотную. Теперь есть регулярные сборки на CircleCI и автоматизированная сборка релизов. Плюс он патчит gtk-osx. Ничего этого без него не было бы.

Не было сборок в самодостаточные пакеты — Жеан взял и сделал флатпак.

Ты считаешь, что нужны статичные сборки — приходи и делай. Хоть аппимидж допиливай, хоть без него, в tar.bz2, как блендер.

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

С одной стороны - бич. Но бывают случаи, и я работал с такими проектами, когда пяток нехилого размера проектов развиваются параллельно, и в результате представляют собой единый проект, просто, фактически модульный. Гимп из той же серии. У меня коммерческий проект, который собирается и автотестируется хз сколько часов, я вижу что тонны ресурсов уходят на поддержку инфраструктуры, что бы всё не рассыпалось. Работает два десятка человек только разработчиков, на наших же плечах CI и инфра, потому что никому нельзя доверять и никогда админ вовремя ничего не подкрутит :) (но они есть, конечно, парни спасают когда совсем ппц =) )

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

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

Ну вот, а что касается гимпа - все это, видимо, будет сделано

Фиксирования старой версии бабла и гегла в зависимостях в обозримом будущем не будет. Это попросту невыгодно для разработки.

Максимум, что возможно — внедрение наработок Ферреро по сборке аппимиджей (сейчас это в докере на CentOS 7).

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

Гонка версий зависимостей - это всеобщий бич.

В понятной для тебя терминологии: зафиксируй sK1 2.0 на UC 1.x. Посмотрим, как ты заговоришь про гонку зависимостей :D

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

по-моему я вобщем все понимаю, но, допустим, что нет.

Видимо, с твоей точки зрения надо вернуться к старой модели, когда в стабильной ветки были только багфиксы, а новый релиз надо было ждать 4-6 лет (как это было с 2.8 и 2.10).

стоп-стоп-стоп! во-первых, хотя это наименее важный вопрос, что изменилось, начиная с 2.10? мы ждем следующих релиз гораздо раньше? когда? позволит ли это уйти от реального версионирования по слепкам а-ля git~20181204?

во-вторых, бампинг версий GEGL&babl был всегда и это совершенно никак не ускорило выход 2.6, 2.8 и 2.10.

в-третьих, то, что нужно девелопить gegl&babl не объясняет, почему для этого нужно брать тулчей чуть ли не из git.

в-четвертых, я готов признать справедливым, что разработчики gimp не хотят иметь стабильный api для gegl&babl, потому что gimp такой быстроразвивающийся (ха-ха) проект. готов признать, что это действительно их дело, но при одном условии. хорошо, объедините тогда для нас, пользователей, ваши низкоуровневые библиотеки gimp с самим gimp (потому что нам нет никакого дела, как вы это там разрабатываете и насколько стабильный ваш внутренний api) и дайте возможно собирать гимп на якобы целевой платформе! (я уж не говорю про план Б: сначала соберите статический билд для Linux, а потом уже для Windows). за каким хреном вы так дерзко поступаете с внешними зависимостями и тулчейном??! вашему gegl&babl так уж необходим glib2 последней версии? я это могу объяснить только хипстерской прытью одного из девелоперов, который спешит опробовать фишечки нового c++ стандарта, а glib2 бампит потому что сидит на федоре.

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

Ты считаешь, что нужны статичные сборки — приходи и делай.

для этого мне придется доказывать всей группе разработчиков, что они должны внести правки в код для этой самой статической сборки. подготовленный проект билдить не сложно, сложно его подготовить. я так и представляю: я прихожу и говорю, ребята, нужно внести правки в Makefile и код для варианта статической сборки, я без понятия, где у вас это лежит, но когда будет можно бидить - дайте мне знать. все сразу бросят свои любимые gegl&babl и пойдут делать статическую сборку.:( особенно тот парень с федорой или с последней убунту побежит править свой код. ему больше всех надо.

а заодно пусть бамп тулчейна согласовывают каждый раз со мной. и я также введу фризы на сторонние зависимости («я серьезно», введу). все готовы к этому?

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

В понятной для тебя терминологии: зафиксируй sK1 2.0 на UC 1.x. Посмотрим, как ты заговоришь про гонку зависимостей :D

Поэтому UC2 в одном бандле с sK1. Много проектов использует бабл и гегл?

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

стоп-стоп-стоп! во-первых, хотя это наименее важный вопрос, что изменилось, начиная с 2.10b?

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

Например, в обозримом будущем в стабильную версию упадёт новый алгоритм заливки областей, упрощающий работу иллюстраторов. А также так называемый space invasion, улучшающий поддержку цветовых пространств кроме sRGB.

во-вторых, бампинг версий GEGL&babl был всегда и это совершенно никак не ускорило выход 2.6, 2.8 и 2.10.

Бампинг версий babl/GEGL позволил выпустить 2.6, 2.8 и 2.10.

в-третьих, то, что нужно девелопить gegl&babl не объясняет, почему для этого нужно брать тулчей чуть ли не из git.

Последний раз зависимость GEGL от внешних библиотек менялась больше года назад: https://gitlab.gnome.org/GNOME/gegl/commits/master/configure.ac

Последний раз зависимость babl от внешних библиотек менялась ХЗ когда (примерно никогда, судя по краткому логу):

https://gitlab.gnome.org/GNOME/babl/commits/master/configure.ac

Апдейты требований GIMP к версиям libpng, glib, Cairo, poppler и LittleCMS связаны с исправлением критических ошибок и уязвимостей.

дайте возможно собирать гимп на якобы целевой платформе!

Бери и собирай. Есть даже скрипты, вытягивающие нужные зависимости.

я уж не говорю про план Б: возьмите ж*пу в охапку и соберите статический билд сначала для Linux, а потом уже для Windows

Мне кажется, ты забыл, где находишься и что обсуждаешь. Это linux.org.ru. Сайт про линукс и свободное ПО. Свободное ПО — проекты сообщества. Ты — часть сообщества. Если тебе что-то надо — возьми свою жопу в охапку и сделай.

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

Приди и сделай.

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

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

Поэтому UC2 в одном бандле с sK1.

Я не знаю, что ты называешь бандлом.

Много проектов использует бабл и гегл?

Как минимум GNOME Photos. Третий по активности разработчик гегла — оттуда.

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

Мне кажется, ты забыл, где находишься и что обсуждаешь. Это linux.org.ru.

да, я-то как раз помню, что это linux.org.ru. а вот ты забываешь, что новые версии gimp'a люди тестируют на винде, потому что на линукс хрен поставишь... мы здесь это обсуждали в прошлый раз. хотя я взял свои слова насчет ж*пы в исходном сообщении.

crypt ★★★★★
()
Последнее исправление: crypt (всего исправлений: 2)
Ответ на: комментарий от Vsevolod-linuxoid

так оно уже ... в смысле «2581835776 ноя 29 04:31 /mnt/sdb1/slax-29-11-2018-test0.iso*» . Но куда его такой выкладывать ...у меня места уже нигде нет :/ (может мэйлу или yandex disk можно обычно карточкой банковской оплатить?)

Andrew-R ★★★★
() автор топика
Ответ на: комментарий от crypt

а вот ты забываешь, что новые версии gimp'a люди тестируют на винде...

Мы только что говорили про Linux и LTS, как ВДРУГ появляются желающие собирать гимп под винду, причём, видимо, прямо из гита, поскольку релизы под винду доступны.

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

Я не помню предыдущее обсуждение этой темы.

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

llvm

нет, это чудо софтостроения я тоже собирал ....благо слакбилд уже был. (но для слабых машин это не вариант.. или ждать, ждать, ждать.... пока соберётся. На меньше чем 1 Гб оперативки может и не собраться толком). Я все эти мозиллы с опен(либре) офисами только на четырёхядернике с 12 Гб ram (!) и стал собирать.... На предыдущем AMD x2 -3800 / 1.25 gb ram я только llvm и прочее для месы собирал, ядра, иксы.. кде3 вот :)

Andrew-R ★★★★
() автор топика
Ответ на: комментарий от Vsevolod-linuxoid

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

Andrew-R ★★★★
() автор топика
Ответ на: комментарий от AP

Я не помню предыдущее обсуждение этой темы.

очень удобно. тем более, что я тебе на спор предложил собрать gimp на старой платформе. ist76 периодически тестирует новые релизы (не из гит!) на скорость. всегда на винде, потому что как ты сам сказал «поскольку релизы под винду доступны.»

p.s.

например тут Gimp 2.9.6 в работе

crypt ★★★★★
()
Ответ на: комментарий от Andrew-R

А в чём проблема создать ещё один аккаунт где угодно? Объём же не по ФИО, а по учетке идет.

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

Vsevolod-linuxoid ★★★★★
()
Последнее исправление: Vsevolod-linuxoid (всего исправлений: 3)
Ответ на: комментарий от AP

связаны с исправлением критических ошибок и уязвимостей.

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

> Последний раз зависимость GEGL от внешних библиотек менялась больше года назад

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

librsvg 2.40.6 при этом в trusty 2.40.2 (не уверен в каком минорном релизе).

если вы не тестируете билд на всех дистрибутивах, то почему вводите ограничения?

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

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

еще раз напоминаю. у вас выходит релиз и люди приходят на linux.org.ru и тестируют на винде(!), потому что для винды у вас есть удобный инсталлер «все включено», а для линукса то ли взлетит, то ли нет. рулетка.

Есть даже скрипты, вытягивающие нужные зависимости.

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

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

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

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

очень удобно. тем более, что я тебе на спор предложил собрать gimp на старой платформе.

Так бы сразу и написал. Я не обязан помнить все дискуссии с тобой.

У меня так и не дошли руки попробовать.

если вы не тестируете билд на всех дистрибутивах, то почему вводите ограничения?

Например, поэтому: https://gitlab.gnome.org/GNOME/gimp/commit/0ce364ee4dd2200e6607a4575af0cc6576...

а для линукса то ли взлетит, то ли нет. рулетка.

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

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

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

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

Резюмирую: прекрати решать за людей, на что им тратить своё неоплачиваемое время, которого им и так не хватает.

AP ★★★★★
()
Ответ на: комментарий от Vsevolod-linuxoid

а, понятно. Впрочем, у меня есть идея ... но реализую её не раньше выходных (всё равно пока заапдейтить хочу месу..там починили galluim nine под nv50/nvc0. Найном я не пользуюсь, но пара фиксов может пригодится.)

Как выложу - создам новую тему.

ПС: про критические обновления в либах - я так понял это не про баги безопасности, а баги, мешающие работе самого Гимпа ....

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

ПС: про критические обновления в либах - я так понял это не про баги безопасности, а баги, мешающие работе самого Гимпа ....

https://gitlab.gnome.org/GNOME/gimp/commit/a5073ad9289f7e05ef38d2ce99dc71e919...

Желающие могут посчитать количество CVE, исправленных в libpng между версиями 1.2.37 (июнь 2009) и 1.6.25 (сентябрь 2016).

https://www.cvedetails.com/vulnerability-list/vendor_id-7294/Libpng.html

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

Желающие могут посчитать количество CVE

оставьте это специалистам. вы же там своими вопросами занимаетесь.

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

да не вопрос, я-то как раз понимаю ситуацию.

Однако явно не пользуешься существующим неофициальным аппимиджем.

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

опять это... «мы 10 лет пилили проект, как хотели, а теперь нашли серебряную пулю, которая решит проблемы за нас».

`GLIBC_2.14' not found

да не работает твой appimage. утомил...

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

да не работает твой appimage. утомил...

И вместо того, чтобы написать про это Андреа, ты делаешь... Что конкретно?

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