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-битной платформе).

★★★★★

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

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

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

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

ЯННП. Зависимости слишком новые что ли?

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

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

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

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

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

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

Для «вообще незнакомой» целевой аудитории планируется со временем добавить сборки в AppImage. Andrea Ferrero понемногу дотачивает свой сборочный скрипт под требования апстрима. Надеюсь, Жеан доберется до него к следующему релизу гимпа.

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

flatpack или appimage - какая разница применительно к топику? еженедельные статические билды и то были бы более здравым решением. паковали бы их в deb/rpm/tgz и все. так нет же, надо извратить с flatpack и appimage... когда руки дойдут.

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

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

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

flatpack или appimage - какая разница применительно к топику?

Принципиальная. Аппимиджи как правило собирают на базе LTS и в статике.

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

appimage - это и есть практически тот же статический билд, только без всего гемора

да, и я об этом же. только мы с тобой, видимо, под гемором понимаем разное. для меня установка-распаковка из deb/rpm/tgz куда-нибудь в /opt как раз простой способ. appimage же еще надо «завезти» на какой-нибудь слакваре или centos 6.

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

Распространяется и запускается как один файл (руками делаешь chmod +x только).

По желанию пользователя устанавливает .desktop для быстрого запуска из рабочей оболочки.

В принципе, есть дельта для обновления до новой версии (но пока не видел, чтобы кто-то юзал).

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

appimage же еще надо «завезти» на какой-нибудь слакваре или centos 6

Скачал один файл и запустил, куда уж проще

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

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

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

главное, наверно, не требует root-привилегий? иначе установка deb/rpm одним кликом в «проводнике» делает тоже самое: инсталирует, добавляет .desktop file и репозиторий для проверки обновлений.

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

Нормальным пацанам достаточно интеграции в $PATH

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

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

Согласен. Флатпак - это вишенка на торте. Лично мое мнение - флатпак начинается со сборки под Linux Standard Base. Собрали gimp-bin.tar.xz, проверили на ubuntu 14.04, centos 7 - норм, можно делать flatpak.

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

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

главное, наверно, не требует root-привилегий?

Именно так.

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

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

https://gitlab.gnome.org/GNOME/gimp/blob/gimp-2-10/configure.ac:46

настроить CI

https://build.gimp.org/

И на CircleCI сборка для мака делается, адрес не помню.

опубликовать скрипты сборки.

https://gitlab.gnome.org/GNOME/gimp/tree/gimp-2-10/build

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

Мое почтение за ответы.

Если не ошибаюсь, то воспроизвести сборку поможет непосредственно

https://gitlab.gnome.org/World/gimp-ci/jenkins-dsl/blob/master/vars/gimpBuild...

+

https://gitlab.gnome.org/World/gimp-ci/docker-gimp/blob/master/debian-testing...

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

Народу надо подключаться, кто заинтересован, и клепать типовые окружения для статический и/или bundle сборки на debian-jessie/centos7 или типа того. После этого, все проблемы у массы людей, кто хочет самого свежего гимпа, и у кого проблемы с flatpak, исчезнут. Ну это я так вижу, по небольшому собственному опыту.

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

Да, репозиторий правильный.

С Дженкинсом всё странно. Он вроде работает, от него есть толк. Но рулит им ровно один человек, который не всё время доступен.

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

Максимум, что наблюдал — приходил какой-то наш соотечественник, который хотел помочь с CI. Но у него бомбануло от того, что мы не хотим переезжать на гитхаб и дела проекта обсуждаем на IRC. В общем, ничем это не кончилось.

AP ★★★★★
()
Ответ на: комментарий от 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)
Ответ на: комментарий от 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)
Ответ на: комментарий от crypt

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

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

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

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

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

llvm

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

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

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

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

p.s.

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

crypt ★★★★★
()
Ответ на: комментарий от 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

эC ю эH джEй Oу би AT майл тчк ру

(у меня нет почты для спама, поэтому в таков виде, не хочу светить ящик)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

`GLIBC_2.14' not found

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

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

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

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

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

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

nufraw 0.42 + gimp 2.10-9 (-git) (комментарий)

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

Первоочередная задача разработчика — писать код, а не сборочки херачить.

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

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

В том то и дело, что бампают по поводу и без оного. В энтерпрайзе если решил бампнуть, будь добр обеспечь сборку софтины напр. под Ubuntu 12.04 и бампай себе на здоровье (от поддержки Ubuntu 10.04 отказались буквально летом). И такая хрень не только в гимпе. Вот напр. в августе пришлось делать отдельный подпроект WiX.Py не потому что NIH, а потому что авторы wixl (родом из Редхата) ведут себя ровно также - собрать их софтину из сорцов можно только на самой свежей федорке (и то не факт).

А потом удивляемся, почему пользователей Linux стабильно 1%. Да потому что под венду изголяются и WinXP саппортить (2001го года), а Linux 16го года уже ппц какое старье и сборки под него моветон.

Гимп, кстати, саппортится под Win7 (2009й год) - какбэ немалый зазор для трудящихся.

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

В кровавом энтерпрайзе это одно и тоже.

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

А потом удивляемся, почему пользователей Linux стабильно 1%.

Совсем не поэтому.

Да потому что под венду изголяются и WinXP саппортить (2001го года)

Ты очень давно не видел минимальные требования к фотошопу, иллюстратору и твоему любимому корелдро. Подсказываю: Microsoft Windows 7 with Service Pack 1, Windows 8.1, or Windows 10.

а Linux 16го года уже ппц какое старье и сборки под него моветон.

AppImage примерно под системы 2015-2016 года и собирают.

Гимп, кстати, саппортится под Win7 (2009й год)

Удивительная новость.

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

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

У нас в клаудах все кодеры еще и девопсы - работа такое :)

Ты очень давно не видел минимальные требования к фотошопу...

Я не про коммерсов говорю, а про свободный софт - собирают под XP и еще и хвалятся «вон какое молоко моя корова дает»

AppImage примерно под системы 2015-2016 года и собирают.

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

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

Я не про коммерсов говорю, а про свободный софт - собирают под XP и еще и хвалятся «вон какое молоко моя корова дает»

Я таких давно не видел. Нас после релиза 2.10 кляли за то, что с апгрейдом до более нового glib отвалился XP, а Krita — за то же самое в ветке 4.х (Qt прекратил поддержку). Последнее с поддержкой XP, что мне попадалось — это Valentina (вот там Роман про это прямо чуть ли не с гордостью пишет, да).

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

Скорость запуска аппимиджа страдает скорее из-за распаковки образа. Впрочем, спорить не буду.

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

Скорость запуска аппимиджа страдает скорее из-за распаковки образа. Впрочем, спорить не буду.

И то и другое - sK1 на убунте стартует практически моментально, потому как кайро, гткшные либы, лцмс, питон уже стартовали и эти либы закешированы в памяти. Холодный старт на винде гораздо медленнее, потому как весь стек библиотек (кроме виджетов wx) чужеродный для системы.

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

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

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

Дебиан 8 (именно 8, олдстэйбл) здесь как пример нормального дистрибутива, совершенно не дружественного к свежему софту. А под архитектуру arm наверняка никто не удосужился собрать пакетов.

Если надо потыкать гимп 5 минут, то можно найти где нибудь комп с виндой и потыкать там. Если надо потыкать посерьёзнее, то надо потратить 2 часа, один из которых вполне можно потратить на лайв-флешку или виртуалку со свежим дистром.

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

совершенно не дружественного к свежему софту.

с чего ты взял? дебиан олдстейбл только недавно получил апдейт 8u11, как и в убунту они подтягивают версии библиотек между минорными апдейтами, ломая совместимость с предыдущими релизами. этот случай с дистром 2015-2016 года как раз очень хорошо перекрывается appimage, про который в этом треде уже достаточно. так что твой дебиан олд-стейбл свежачок вполне себе. а вот на винде гимп и правда можно запустить на розливе 2007 года. тут как бы разница с твоим дебианов в 10 лет.

p.s.

nufraw 0.42 + gimp 2.10-9 (-git) (комментарий)

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

а вот на винде гимп и правда можно запустить на розливе 2007 года.

«Windows 7 Service Pack 1 (SP1) was announced on March 18, 2010.»

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

дебиан не считался бы самым стабильным так долго, если бы подтягивал какие то новые библиотеки. Собственно я по пальцам могу пересчитать пакеты, версия которых обновлялась за весь цикл поддержки релиза. Файерфокс и дрова nvidia, больше ничего в голову не призодит. Ещё clamAV

Да, есть сид, анстэйбл, тэстинг и бэкпорты. Но все эти ветки это совсем другое.

А то что цикл поддержки у линуксов стал меньше винды, это да. Дебиан по меркам какой нибудь федоры или убунты ещё редкосный тормоз. Гимпа 2.10 в восьмёрке можно получить только ручками, зато я ещё год могу наслаждаться приложениями кде4 и не париться с современным глюкодромом.

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

не считался бы самым стабильным так долго, если бы подтягивал какие то новые библиотеки.

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

так что appimage на нем взлетает как раз по причине относительной свежести. с той же ubuntu LTS могло быть больше проблем.

Дебиан по меркам какой нибудь федоры или убунты ещё редкосный тормоз.

у убунту общий срок поддержки больше.

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