* [devel] Обновление GHC @ 2019-03-12 17:48 Evgeny Sinelnikov 2019-03-14 15:33 ` Dmitry V. Levin ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Evgeny Sinelnikov @ 2019-03-12 17:48 UTC (permalink / raw) To: ALT Linux Team development discussions; +Cc: eugine.kosenko Здравствуйте, хочу снова поднять вопрос по обновлению компилятора Haskell: Для истории: https://lists.altlinux.org/pipermail/devel/2018-November/205967.html https://lists.altlinux.org/pipermail/sisyphus/2018-May/366749.html https://lists.altlinux.org/pipermail/devel/2018-May/204407.html https://bugzilla.altlinux.org/show_bug.cgi?id=31193 https://bugzilla.altlinux.org/show_bug.cgi?id=34731 У меня готов бутстрап 7.6.1 -> 7.10.3 -> 7.10.3 -> 8.6.3. Пакеты успешно пересбораны хешере. Сборка 7.10.3 в сборочнице прошла успешно, большая часть патчей по поддержке aarch64 отпилена, потому что больше не нужна. Из интересного, с haskell теперь идут динамические модули, которые требуются во время работы, но кладутся в /usr/{lib,lib64}/ghc-X.Y.Z/package-version/libHSpackage-version.soname Из-за этого новый ghc не запускается без смонтированного /proc. Я это поправил переложив динамичческие либы в отдельный /usr/{lib,lib64}/ghc-X.Y.Z/lib каталог и прописав его в /etc/ld.so.conf.d/ghc-version.conf Далее, в rpm-build-haskell исправлена генерация зависимостей, а также при сборке модулей для динамических библиотек прописана опция --dynlibdir to %_libdir/$compiler/lib/ Готов рассмотреть более уданые варианты, если есть предложения. Поскольку ничего критичного новые сборки ghc не провайдят, предлагаю начать постепенный бустрап этих сборок в сизиф. Когда новый ghc будет готов по количеству модулей к сборке зависимых от него приложений, пересборать их на новом ghc. PS: Нашёл наработки Евгения Косенко: ftp://kosenko.net.ua/pub/repos/haskell/x86_64/ попробую найти в них что-нибудь интересное (пока медленно качаются). Из интересного ghc-common c ghc-wrapper на манер gcc. -- Sin (Sinelnikov Evgeny) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] Обновление GHC 2019-03-12 17:48 [devel] Обновление GHC Evgeny Sinelnikov @ 2019-03-14 15:33 ` Dmitry V. Levin 2019-03-15 10:07 ` Evgeny Sinelnikov 2019-03-16 22:52 ` Ivan Zakharyaschev 2 siblings, 1 reply; 14+ messages in thread From: Dmitry V. Levin @ 2019-03-14 15:33 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 1811 bytes --] On Tue, Mar 12, 2019 at 09:48:07PM +0400, Evgeny Sinelnikov wrote: > Здравствуйте, > > хочу снова поднять вопрос по обновлению компилятора Haskell: > > Для истории: > https://lists.altlinux.org/pipermail/devel/2018-November/205967.html > https://lists.altlinux.org/pipermail/sisyphus/2018-May/366749.html > https://lists.altlinux.org/pipermail/devel/2018-May/204407.html > https://bugzilla.altlinux.org/show_bug.cgi?id=31193 > https://bugzilla.altlinux.org/show_bug.cgi?id=34731 > > У меня готов бутстрап 7.6.1 -> 7.10.3 -> 7.10.3 -> 8.6.3. > > Пакеты успешно пересбораны хешере. Сборка 7.10.3 в сборочнице прошла > успешно, большая часть патчей по поддержке aarch64 отпилена, потому > что больше не нужна. > > Из интересного, с haskell теперь идут динамические модули, которые > требуются во время работы, но кладутся в > /usr/{lib,lib64}/ghc-X.Y.Z/package-version/libHSpackage-version.soname > > Из-за этого новый ghc не запускается без смонтированного /proc. Я это > поправил переложив динамичческие либы в отдельный > /usr/{lib,lib64}/ghc-X.Y.Z/lib каталог и прописав его в > /etc/ld.so.conf.d/ghc-version.conf > > Далее, в rpm-build-haskell исправлена генерация зависимостей, а также > при сборке модулей для динамических библиотек прописана опция > --dynlibdir to %_libdir/$compiler/lib/ > > Готов рассмотреть более уданые варианты, если есть предложения. > > Поскольку ничего критичного новые сборки ghc не провайдят, предлагаю > начать постепенный бустрап этих сборок в сизиф. Когда новый ghc будет > готов по количеству модулей к сборке зависимых от него приложений, > пересборать их на новом ghc. Я не понял из этого плана, сколько версий ghc будет в репозитории во время этого бутстрапа, и что в это время будет происходить с модулями? -- ldv [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] Обновление GHC 2019-03-14 15:33 ` Dmitry V. Levin @ 2019-03-15 10:07 ` Evgeny Sinelnikov 2019-03-15 17:07 ` Ivan Zakharyaschev 0 siblings, 2 replies; 14+ messages in thread From: Evgeny Sinelnikov @ 2019-03-15 10:07 UTC (permalink / raw) To: ALT Linux Team development discussions Здравствуйте, план бутстрапа следующий: - 4 шага на сборку самого ghc (четыре таски): + 7.10.3 собираем с помощью 7.6.1 + пересобираем 7.10.3 собираем с помощью 7.10.3; 8.2.2 собираем с помощью 7.10.3 + пересобираем 8.2.2 собираем с помощью 8.2.2; 8.6.4 собираем с помощью 8.2.2 + пересобираем 8.6.4 собираем с помощью 8.6.4; основные модули для 8.6.4 (cabal-install + зависимости) - генерация и сборка модулей под бинарники pandoc, shellcheck, xmonad*, ztail С модулями 7.6.1 на протяжении всего этого процесса ничего не происходит, они продолжают ставиться и работать, по зависимостям ничего не должно разъехаться до момента пересечения по предоставляемым бинарникам в /usr/bin. А если их явно никто не требует, то и с ними проблем быть не должно. То есть, если бинарник /usr/bin/cabal предоставляется пакетом ghc7.6.1-cabal-install и начнёт предоставляться пакетом ghc8.6.3-cabal-install, то критично это, насколько я понимаю, только если apt-cache whatdepends /usr/bin/cabal выкатит список зависимостей: $ apt-cache whatdepends /usr/bin/cabal W: Невозможно найти пакет /usr/bin/cabal Модули для 7.10.3 и 8.2.2 мне было собирать некогда, как пакеты я бы их оставил, с добавлением минимального набора модулей (cabal-install + зависимости). Для обновления модулей у нас предусмотрен инструмент cabal2rpm, с помощью него удобно получить полный набор gear-репозиториев под все новые модули. С ходу я от него не добился двух вещей - правильной генерации сборочных зависимостей и обновления уже собраных модулей. Кроме того cabal2rpm предполагает, что ему передают тарболы с модулями, а это уже не рабочий вариант, как оказалось. Дело в том, что тарболы, которые качают вручную из http://hackage.haskell.org/ неполноценны, в них лежит нулевая ревизия cabal-файла. Правильную ревизию умеет подкладывать cabal get, поэтому я рассчитываю научить cabal2rpm брать не траболы, сразу распакованные с помощью cabal get каталоги и делать уже с них gear-update. Я на низком старте жду отмашки, что мы готовы к этому сценарию. чт, 14 мар. 2019 г. в 19:33, Dmitry V. Levin <ldv@altlinux.org>: > > On Tue, Mar 12, 2019 at 09:48:07PM +0400, Evgeny Sinelnikov wrote: > > Здравствуйте, > > > > хочу снова поднять вопрос по обновлению компилятора Haskell: > > > > Для истории: > > https://lists.altlinux.org/pipermail/devel/2018-November/205967.html > > https://lists.altlinux.org/pipermail/sisyphus/2018-May/366749.html > > https://lists.altlinux.org/pipermail/devel/2018-May/204407.html > > https://bugzilla.altlinux.org/show_bug.cgi?id=31193 > > https://bugzilla.altlinux.org/show_bug.cgi?id=34731 > > > > У меня готов бутстрап 7.6.1 -> 7.10.3 -> 7.10.3 -> 8.6.3. > > > > Пакеты успешно пересбораны хешере. Сборка 7.10.3 в сборочнице прошла > > успешно, большая часть патчей по поддержке aarch64 отпилена, потому > > что больше не нужна. > > > > Из интересного, с haskell теперь идут динамические модули, которые > > требуются во время работы, но кладутся в > > /usr/{lib,lib64}/ghc-X.Y.Z/package-version/libHSpackage-version.soname > > > > Из-за этого новый ghc не запускается без смонтированного /proc. Я это > > поправил переложив динамичческие либы в отдельный > > /usr/{lib,lib64}/ghc-X.Y.Z/lib каталог и прописав его в > > /etc/ld.so.conf.d/ghc-version.conf > > > > Далее, в rpm-build-haskell исправлена генерация зависимостей, а также > > при сборке модулей для динамических библиотек прописана опция > > --dynlibdir to %_libdir/$compiler/lib/ > > > > Готов рассмотреть более уданые варианты, если есть предложения. > > > > Поскольку ничего критичного новые сборки ghc не провайдят, предлагаю > > начать постепенный бустрап этих сборок в сизиф. Когда новый ghc будет > > готов по количеству модулей к сборке зависимых от него приложений, > > пересборать их на новом ghc. > > Я не понял из этого плана, сколько версий ghc будет в репозитории во время > этого бутстрапа, и что в это время будет происходить с модулями? > > > -- > ldv > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBCAAGBQJcinQ8AAoJEAVFT+BVnCUIQaQP/112Bx35zxPBN4b/C5pNr/bA > 1+aYAi82IXML0AQlrF7tddUEg/Roq2Sz12dvrYr1zEWxZW4e8kkFTs/7ZcWeZEDF > IJSZ8sODlzuBk7K4Y1XSkkz2/kU4c72RKNAuvR1b+P7K31c2RPXfD+m0Gs287q3E > S0oAZSfJcMxsO98YBmPBAT6kto9zwhd3bFdNUfaYowwHcJu4dJS/h4pFHH92fRKI > pAeYzx8duAcNS49UmD1idqKrACKBD8Iv/LNTRwh/wQ31WeMl3bEiKRckNBiSgOuM > PSw1VkRnEYDb3vxyaRFSsmE2bYbqaZC6eoa7Wqv0TpqGOw5oU4saqu2iugHfBqAh > J0RcD9V7XzkWp3byzY4neP58UawiLvMZgSc94x+B6Z+WzVtcfCmP5jopBFjt9O3f > YR0+/O4ulEWVL+1RPXfJWQuzuKdbE+wkWyMQCTmxQs05BZ6CiUvwLfTS5WBZXVMx > tMgLBzKRFbWdP4u7PGi/iXtqwoxNGdBZIbhk9106PNwJhn2aqUvAks2RR2NZkkuS > SqU6duBbcEt5bv7/Qm37U89Azac3maUpTQxvYdqceUaDz5JaKMIP5xnGFj3NoMF7 > Iwg7yYGH45+tnWSzJFVn5JwfQeycfyRwfW2S/Ga5groaboWXGTun915z801qfy+F > Hbx+sJEzA1Cy076stqQA > =7FWR > -----END PGP SIGNATURE----- > _______________________________________________ > Devel mailing list > Devel@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/devel -- Sin (Sinelnikov Evgeny) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] Обновление GHC 2019-03-15 10:07 ` Evgeny Sinelnikov @ 2019-03-15 17:07 ` Ivan Zakharyaschev 1 sibling, 0 replies; 14+ messages in thread From: Ivan Zakharyaschev @ 2019-03-15 17:07 UTC (permalink / raw) To: ALT Linux Team development discussions [-- Attachment #1: Type: text/plain, Size: 1990 bytes --] Hello! On Fri, 15 Mar 2019, Evgeny Sinelnikov wrote: > план бутстрапа следующий: По-моему, хороший план. > - 4 шага на сборку самого ghc (четыре таски): > + 7.10.3 собираем с помощью 7.6.1 > + пересобираем 7.10.3 собираем с помощью 7.10.3; 8.2.2 собираем с > помощью 7.10.3 > + пересобираем 8.2.2 собираем с помощью 8.2.2; 8.6.4 собираем с помощью 8.2.2 > + пересобираем 8.6.4 собираем с помощью 8.6.4; основные модули для > 8.6.4 (cabal-install + зависимости) > - генерация и сборка модулей под бинарники pandoc, shellcheck, xmonad*, ztail > С модулями 7.6.1 на протяжении всего этого процесса ничего не > происходит, они продолжают ставиться и работать, по зависимостям > ничего не должно разъехаться до момента пересечения по предоставляемым > бинарникам в /usr/bin. А если их явно никто не требует, то и с ними > проблем быть не должно. То есть, если бинарник /usr/bin/cabal Можно ещё предварительно выделить пакет с бинарником pandoc, перепроверить зависимости: кому нужен для сборки бинарник, нужно ставить зависимость на pandoc, а кому библиотека -- на ghc7.6.1-pandoc. Потом сразу после сборки ghc8.6.3-pandoc в том же задании отключить создание пакета с бинарником из ghc7.6.1-pandoc. > предоставляется пакетом ghc7.6.1-cabal-install и начнёт > предоставляться пакетом ghc8.6.3-cabal-install, то критично это, > насколько я понимаю, только если apt-cache whatdepends /usr/bin/cabal > выкатит список зависимостей: > $ apt-cache whatdepends /usr/bin/cabal > W: Невозможно найти пакет /usr/bin/cabal > > Модули для 7.10.3 и 8.2.2 мне было собирать некогда, как пакеты я бы > их оставил, с добавлением минимального набора модулей (cabal-install + > зависимости). Я бы тоже оставил. * * * Размножение исходных пакетов с модулями произойлёт по мере сборки модулей для новой версии ghc. Но что поделаешь, не такая уж большая неприятность. Пытаться объединять я бы не стал, потому что разные версии пакетов приспособлены для разных версий ghc. -- Best regards, Ivan ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <CAB_XSX2kV6iM2z+K-+GSrKdV==ejo5r_ycMKAMhSZK-1=4sibA@mail.gmail.com>]
* Re: [devel] Обновление GHC @ 2019-04-02 19:47 ` Evgeny Sinelnikov 2019-04-03 16:17 ` Ivan Zakharyaschev 2 siblings, 1 reply; 14+ messages in thread From: Evgeny Sinelnikov @ 2019-04-02 19:47 UTC (permalink / raw) To: ALT Linux Team development discussions вт, 2 апр. 2019 г. в 12:26, Eugine Kosenko <eugine.kosenko@gmail.com>: > > пт, 15 бер. 2019 о 12:07 Evgeny Sinelnikov <sin@altlinux.org> пише: >> >> 8.6.4 (cabal-install + зависимости) >> - генерация и сборка модулей под бинарники pandoc, shellcheck, xmonad*, ztail > > > От cabal сейчас отказываются. Нужно выходить на stack, это сейчас принятая инфраструктура. Ну, это сильно сказано, мне кажется. Это же немного разные инструменты, хотя и дублирующие какие-то свои функции. Stack - это для разработки. Я бы не сказал, что это для деплоя подходящий инструмент. С ним получается набор контейнеров. Даже не под приложение, а под экземпляр разрабатываемого проекта. >> >> Для обновления модулей у нас предусмотрен инструмент cabal2rpm, с >> помощью него удобно получить полный набор gear-репозиториев под все >> новые модули. С ходу я от него не добился двух вещей - правильной >> генерации сборочных зависимостей и обновления уже собраных модулей. >> Кроме того cabal2rpm предполагает, что ему передают тарболы с >> модулями, а это уже не рабочий вариант, как оказалось. > > > У меня есть комплект самописных скриптов на fish, которые позволяют выстраивать нужные зависимости и собирать массово нужные пакеты. Правда, все это "на коленке". Если интересно, постараюсь на выходные привести все в порядок и выложить "как есть". > >> Дело в том, что тарболы, которые качают вручную из >> http://hackage.haskell.org/ неполноценны, в них лежит нулевая ревизия >> cabal-файла. Правильную ревизию умеет подкладывать cabal get, поэтому >> я рассчитываю научить cabal2rpm брать не траболы, сразу распакованные >> с помощью cabal get каталоги и делать уже с них gear-update. > > > По ходу cabal2rpm иногда глючит не по детски, я где-то пяток пакетов руками правил. Но в рамках моей обертки она стреляет неплохо. А как, конкретно? Давайте исправлять. >> >> Я на низком старте жду отмашки, что мы готовы к этому сценарию. > > > Если не торопимся, то могу помочь с модулями. Но это не раньше выходных --- я сейчас сильно загружен. А самая большая проблема у меня была именно со сборкой "ядер" --- ghc нужной версии. На моем ноуте собирается примерно 15-20 часов, цикл отладки дикий. Надеюсь, правда, на этой неделе нарастить память. Опять же, модули собираются достаточно быстро, у меня весь комплект собирается за 4-5 часов. Процесс мы начали. Меня приостановил неочевидный момент. А именно, поломка сборки 8.2.2 под mipsel. Особенность там похожая, что и на aarch64 - сборка via gcc, unregistered архитектуры. Для aarch64 - это, возможно, исправимая ошибка. А вот под mipsel не хватает памяти, как у 32-битной платформы, в которой в пространстве пользователя доступна не более 2Гб виртуальной памяти. В общем, 8.2.2 уже в сизифе. 8.6.4 протестиован. Я им уже пользуюсь: #225531 TESTED #4 [test-only] sisyphus ghc.git=8.2.2-alt2 ghc.git=8.6.4-alt1 Первый этап после его приезда завершается. Начинается сборка модулей. Из ключевой момент, который хочется поправить - это автоматическая генерация сборочных зависимостей в cabal2gear. На первом шаге я планирую использовать связку - cabal install --dry-run для поиска зависимостей; - cabal get - для загрузки исходников с правильным релизом. ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <CAB_XSX1=kLp=z3mb9=c+k7N-P4987+18Uz83SLZ9FK9PokeM4g@mail.gmail.com>]
* Re: [devel] Обновление GHC @ 2019-04-03 12:33 ` Evgeny Sinelnikov 0 siblings, 0 replies; 14+ messages in thread From: Evgeny Sinelnikov @ 2019-04-03 12:33 UTC (permalink / raw) To: ALT Linux Team development discussions ср, 3 апр. 2019 г. в 11:44, Eugine Kosenko <eugine.kosenko@gmail.com>: > > вт, 2 квіт. 2019 о 22:44 Evgeny Sinelnikov <sin@altlinux.org> пише: >> >> > От cabal сейчас отказываются. Нужно выходить на stack, это сейчас принятая инфраструктура. >> >> Ну, это сильно сказано, мне кажется. Это же немного разные >> инструменты, хотя и дублирующие какие-то свои функции. Stack - это для >> разработки. Я бы не сказал, что это для деплоя подходящий инструмент. >> С ним получается набор контейнеров. Даже не под приложение, а под >> экземпляр разрабатываемого проекта. > > > Немного не согласен, но это тема для отдельного разговора... > >> > По ходу cabal2rpm иногда глючит не по детски, я где-то пяток пакетов руками правил. Но в рамках моей обертки она стреляет неплохо. >> >> А как, конкретно? Давайте исправлять. > > > С ходу точно не вспомню. Кажется, когда там многострочные description, у него вылетает парсинг другой информации и в результате выходит голый шаблон с макросами. Не было времени с этим разбираться. Глюканул только пяток пакетов из почти 200, поэтому оказалось проще исправить руками. А без разбирательства я не посчитал нужным вешать баг. У меня был глюк с тем, что нечитаемый description. Здесь нужны примеры. > > В выходные подниму архивы, может, воспроизведу что-то конкретное. Хорошо. >> >> Процесс мы начали. Меня приостановил неочевидный момент. А именно, >> поломка сборки 8.2.2 под mipsel. Особенность там похожая, что и на >> aarch64 - сборка via gcc, unregistered архитектуры. Для aarch64 - это, >> возможно, исправимая ошибка. А вот под mipsel не хватает памяти, как у >> 32-битной платформы, в которой в пространстве пользователя доступна не >> более 2Гб виртуальной памяти. >> >> В общем, 8.2.2 уже в сизифе. 8.6.4 протестиован. Я им уже пользуюсь: >> #225531 TESTED #4 [test-only] sisyphus ghc.git=8.2.2-alt2 ghc.git=8.6.4-alt1 > > > Несколько версий в системе и переключение между ними через alternatives и/или wrapper тоже сделано? Нет пока, я думаю, что отлаживать сразу две проблемы не стоит. Лучше получить рабочий ghc, а следующим шагом сделать wrapper, как в gcc. > > Я не тороплюсь с переездом, потому что под последние версии gcc не собирается stack и yesod. Я сам был вынужден вернуться к 8.2.2 после того, как уже сидел на 8.4.1. Причем стабильную конфигурацию нашел только с помощью stack snapshot. Это к вопросу о деплойменте, кстати... stack на ghc 8.6.3 я уже собирал. С ним всё должно быть в порядке. yesold нужно проверить. -- Sin (Sinelnikov Evgeny) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] Обновление GHC 2019-04-02 19:47 ` Evgeny Sinelnikov @ 2019-04-03 16:17 ` Ivan Zakharyaschev 2019-04-03 16:20 ` Anton Farygin 2 siblings, 1 reply; 14+ messages in thread From: Ivan Zakharyaschev @ 2019-04-03 16:17 UTC (permalink / raw) To: ALT Linux Team development discussions [-- Attachment #1: Type: text/plain, Size: 981 bytes --] Hello! On Tue, 2 Apr 2019, Eugine Kosenko wrote: > Если не торопимся, то могу помочь с модулями. Но это не раньше выходных --- > я сейчас сильно загружен. А самая большая проблема у меня была именно со > сборкой "ядер" --- ghc нужной версии. На моем ноуте собирается примерно > 15-20 часов, цикл отладки дикий. Надеюсь, правда, на этой неделе нарастить > память. Опять же, модули собираются достаточно быстро, у меня весь комплект > собирается за 4-5 часов. Если Вы в team, то можно собирать на team.alt. Из .ssh/config: Host team.alt HostName team.altlinux.org Port 222 User imz IdentityFile ~/.ssh/id_rsa_imz-vaio -- Best regards, Ivan ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] Обновление GHC 2019-04-03 16:17 ` Ivan Zakharyaschev @ 2019-04-03 16:20 ` Anton Farygin 2019-04-03 17:13 ` Ivan Zakharyaschev 0 siblings, 1 reply; 14+ messages in thread From: Anton Farygin @ 2019-04-03 16:20 UTC (permalink / raw) To: ALT Linux Team development discussions, Ivan Zakharyaschev 03.04.2019 19:17, Ivan Zakharyaschev пишет: > Hello! > > On Tue, 2 Apr 2019, Eugine Kosenko wrote: > >> Если не торопимся, то могу помочь с модулями. Но это не раньше выходных --- >> я сейчас сильно загружен. А самая большая проблема у меня была именно со >> сборкой "ядер" --- ghc нужной версии. На моем ноуте собирается примерно >> 15-20 часов, цикл отладки дикий. Надеюсь, правда, на этой неделе нарастить >> память. Опять же, модули собираются достаточно быстро, у меня весь комплект >> собирается за 4-5 часов. > Если Вы в team, то можно собирать на team.alt. Из .ssh/config: > > Host team.alt > HostName team.altlinux.org > Port 222 > User imz > IdentityFile ~/.ssh/id_rsa_imz-vaio Наверное надо кому-то написать, что бы добавили аккаунт ? $ ssh team.alt ssh: rider@team.altlinux.org: Permission denied (publickey). ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] Обновление GHC 2019-04-03 16:20 ` Anton Farygin @ 2019-04-03 17:13 ` Ivan Zakharyaschev 2019-04-03 17:29 ` Ivan Zakharyaschev 0 siblings, 1 reply; 14+ messages in thread From: Ivan Zakharyaschev @ 2019-04-03 17:13 UTC (permalink / raw) To: ALT Linux Team development discussions [-- Attachment #1: Type: text/plain, Size: 1115 bytes --] On Wed, 3 Apr 2019, Anton Farygin wrote: > 03.04.2019 19:17, Ivan Zakharyaschev пишет: > > Hello! > > > > On Tue, 2 Apr 2019, Eugine Kosenko wrote: > > > > > Если не торопимся, то могу помочь с модулями. Но это не раньше выходных > > > --- > > > я сейчас сильно загружен. А самая большая проблема у меня была именно со > > > сборкой "ядер" --- ghc нужной версии. На моем ноуте собирается примерно > > > 15-20 часов, цикл отладки дикий. Надеюсь, правда, на этой неделе нарастить > > > память. Опять же, модули собираются достаточно быстро, у меня весь > > > комплект > > > собирается за 4-5 часов. > > Если Вы в team, то можно собирать на team.alt. Из .ssh/config: > > > > Host team.alt > > HostName team.altlinux.org > > Port 222 > > User imz > > IdentityFile ~/.ssh/id_rsa_imz-vaio > Наверное надо кому-то написать, что бы добавили аккаунт ? > > $ ssh team.alt > ssh: rider@team.altlinux.org: Permission denied (publickey). Наверное. К тому же там может быть какой-то твой старый ключ. [imz@team ~]$ l -d /home/rider drwx------ 15 rider rider 4096 Jan 14 2015 /home/rider/ -- Best regards, Ivan ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] Обновление GHC 2019-04-03 17:13 ` Ivan Zakharyaschev @ 2019-04-03 17:29 ` Ivan Zakharyaschev 0 siblings, 0 replies; 14+ messages in thread From: Ivan Zakharyaschev @ 2019-04-03 17:29 UTC (permalink / raw) To: ALT Linux Team development discussions [-- Attachment #1: Type: text/plain, Size: 1255 bytes --] On Wed, 3 Apr 2019, Ivan Zakharyaschev wrote: > On Wed, 3 Apr 2019, Anton Farygin wrote: > > > 03.04.2019 19:17, Ivan Zakharyaschev пишет: > > > Hello! > > > > > > On Tue, 2 Apr 2019, Eugine Kosenko wrote: > > > > > > > Если не торопимся, то могу помочь с модулями. Но это не раньше выходных > > > > --- > > > > я сейчас сильно загружен. А самая большая проблема у меня была именно со > > > > сборкой "ядер" --- ghc нужной версии. На моем ноуте собирается примерно > > > > 15-20 часов, цикл отладки дикий. Надеюсь, правда, на этой неделе нарастить > > > > память. Опять же, модули собираются достаточно быстро, у меня весь > > > > комплект > > > > собирается за 4-5 часов. > > > Если Вы в team, то можно собирать на team.alt. Из .ssh/config: > > > > > > Host team.alt > > > HostName team.altlinux.org > > > Port 222 > > > User imz > > > IdentityFile ~/.ssh/id_rsa_imz-vaio > > Наверное надо кому-то написать, что бы добавили аккаунт ? > > > > $ ssh team.alt > > ssh: rider@team.altlinux.org: Permission denied (publickey). > > Наверное. К тому же там может быть какой-то твой старый ключ. Я обращался к glebfm@ или ldv@ > [imz@team ~]$ l -d /home/rider > drwx------ 15 rider rider 4096 Jan 14 2015 /home/rider/ -- Best regards, Ivan ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <CAB_XSX0nnQn1GF1PS8MSOaavDRAGPb5Tio2bRCj5C1jWQmzQ2A@mail.gmail.com>]
[parent not found: <CAB_XSX1eS51XFdXnbr02XWbtGTyZTN=sMEeChaavDwYQdP6wXA@mail.gmail.com>]
* Re: [devel] Обновление GHC @ 2019-04-11 9:21 ` Evgeny Sinelnikov 0 siblings, 1 reply; 14+ messages in thread From: Evgeny Sinelnikov @ 2019-04-11 9:21 UTC (permalink / raw) To: ALT Linux Team development discussions Здравствуйте, сб, 6 апр. 2019 г. в 18:15, Eugine Kosenko <eugine.kosenko@gmail.com>: > > И еще есть подозрение, что после установки в системе stack никаких модулей больше не понадобится. У меня stack, даже после того, как я собрал и установил в системе yesod, все-равно пересобрал часть пакетов в свой собственный слой. Я так и не понял, чем ему не понравился системный yesod и некоторые пакеты, что он использует. Кроме того, stack позволяет развернуть любой план, в котором будет любая версия ghc вплоть до 8.6.4. > > Возможно, это не comme il faut с точки зрения управления пакетами, но у меня такая же ситуация с Emacs MELPA --- я предпочитаю ставить модули Emacs через нее, а не через rpm. И то же самое было с cabal и node, хотя последний я пока всерьез не разворачивал. > Дело не только "дурном" или "не дурном" стиле с точки зрения управления пакетами. Дело в том, что предложение использовать, например stack, как то, после чего "никаких модулей больше не понадобится" - это подход разработчика. И сам GHC на это вполне ориентирован. Непонятно как сочетать этот подход "для разработчика" с подходом "для пользователя". В этом ведь смысл дистрибутивных решений. Мы собрали конечный код и хотим его передать пользователю. Зачем мне для этого stack? Для того, чтобы в стиле Gentoo требовать от каждого пользователя собирать у себя в домашнем каталоге конкретное приложение? А как быть с тем, чтобы это приложение легло в систему и было доступно не только одному пользователю. Я предлагаю в этом плане такой подход: - Кроме GHC в сизифе необходимо обеспечить возможность инструментарий для сборки приложений; - Для возможности разработки необходимо обеспечить в сизифе cabal-install и stack - по сути, оба эти инструмента имеют смысл, у каждого из них есть своё сообщество и отдельный репозиторий: https://www.stackage.org/ http://hackage.haskell.org/ - Подготовить для сборки приложений инструмент позволяющий генерацию сборочных зависимостей с помощью cabal2gear. > сб, 6 квіт. 2019 о 16:56 Eugine Kosenko <eugine.kosenko@gmail.com> пише: >>>> >>>> Для обновления модулей у нас предусмотрен инструмент cabal2rpm, с >>>> помощью него удобно получить полный набор gear-репозиториев под все >>>> новые модули. С ходу я от него не добился двух вещей - правильной >>>> генерации сборочных зависимостей и обновления уже собраных модулей. >>>> Кроме того cabal2rpm предполагает, что ему передают тарболы с >>>> модулями, а это уже не рабочий вариант, как оказалось. >>> >>> >>> У меня есть комплект самописных скриптов на fish, которые позволяют выстраивать нужные зависимости и собирать массово нужные пакеты. Правда, все это "на коленке". Если интересно, постараюсь на выходные привести все в порядок и выложить "как есть". Да, было бы очень неплохо. Ещё было бы неплохо воспользоваться этими инструментами для сборки cabal-install и stack, а также pandoc, shellcheck, xmonad. >> >> >> В общем, пересмотрел свои инструменты. Я беру зависимости из конкретно выбранного плана сборки для выбранного снапшота stackage. Задаю в рамках этого плана один или несколько модулей-целей. Потом с помощью самописной утилиты на haskell вытягиваю все зависимости из плана сборки и упорядочиваю все необходимые пакеты в виде списка имен и версий пакетов, которые нужно собрать. >> >> А потом уже с помощью fish-скриптов собираю последовательно все пакеты и устанавливаю их в систему. Для каждого пакета из списка вытягиваю его из хранилища, создаю две копии --- оригинал и измененную, делаю нулевой патч (позже объясню, зачем) и генерирую spec-файл с помощью cabal2rpm. Потом я делаю сборку дважды: при первом проходе в spec-файл добавляются зависимости с помощью банального buildreq, а затем уже производится финальная сборка. После этого пакет ставится в системе, и происходит переход к следующему пакету. Процесс в общем медленный, а спеки, может быть, немного грязные, но в целом все достаточно надежно. Автоматически было собрано около 90% всех пакетов. >> >> В остатке проблемы только в трех случаях. Во всех трех ситуациях проще было исправить все вручную, чем городить новые автоматы. Во-первых, это пакеты, у которых имена содержат прописные буквы (HUnit, QuickCheck). Во-вторых, в нескольких местах глючил cabal2rpm. Эту проблему сейчас повторить не удалось, а запускать весь процесс заново, только чтобы поймать эти модули считаю пока нецелесообразным. И, наконец, некоторое количество cabal-файлов содержат неправильную информацию о версиях зависимостей. Поэтому я бы не полагался так сильно на возможности cabal и cabal2rpm. В последнем случае я вручную проверял правильные зависимости по сайту hackage.haskell.org, и изменял версии прямо в cabal-файле в каталоге с измененной версией. После этого повторял сборку, которая автоматически строила нужный патч на cabal-файл. Неудобно, но мне хватило терпение сделать все это руками. >> >> Если интересно, могу выложить исходники утилиты для получения списка сборки и скрипты. Утилита более-менее задокументирована, а вот скрипты могу дать только "как есть". Просто не понимаю, нужно ли их вообще "причесывать". Причёсывать сразу не обязательно. Давайте обновим пакеты, завершим переезд и потом их "причешем". Ну, или посмотрим, может что-то и сразу "причешем". -- Sin (Sinelnikov Evgeny) ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <CAB_XSX3-xLhNNuzduSY381UcVWycJcb1EmHsJDHVrrZyBfc-ew@mail.gmail.com>]
* Re: [devel] Обновление GHC @ 2019-04-14 16:39 ` Aleksey Novodvorsky 0 siblings, 0 replies; 14+ messages in thread From: Aleksey Novodvorsky @ 2019-04-14 16:39 UTC (permalink / raw) To: ALT Linux Team development discussions вс, 14 апр. 2019 г. в 19:22, Eugine Kosenko <eugine.kosenko@gmail.com>: > > чт, 11 квіт. 2019 о 12:17 Evgeny Sinelnikov <sin@altlinux.org> пише: >> >> Непонятно как сочетать этот подход "для разработчика" с подходом "для >> пользователя". В этом ведь смысл дистрибутивных решений. Мы собрали >> конечный код и хотим его передать пользователю. Зачем мне для этого >> stack? Для того, чтобы в стиле Gentoo требовать от каждого >> пользователя собирать у себя в домашнем каталоге конкретное >> приложение? > > > А как быть с тем, чтобы это приложение легло в систему и было доступно > > не только одному пользователю. > > Хых, судя по популярности docker, и учитывая немерянные размеры современных дисков, пользователь тоже предпочитает получать решения по типу "all inclusive". Спорить не буду, потому как отлично понимаю, что это прямой путь к bloatware, но видимо, намучавшись с различными разновидностями "package hell", народ, видимо, предпочитает выбрать меньшее из зол. > >> >>> У меня есть комплект самописных скриптов на fish, которые позволяют выстраивать нужные зависимости и собирать массово нужные пакеты. Правда, все это "на коленке". Если интересно, постараюсь на выходные привести все в порядок и выложить "как есть". >> >> Да, было бы очень неплохо. Ещё было бы неплохо воспользоваться этими >> инструментами для сборки cabal-install и stack, а также pandoc, >> shellcheck, xmonad. > > > Пока проверю, насколько это все эффективно на предложенном наборе. В рамках плана lts-11.4 (https://www.stackage.org/lts-11.4) я уже собрал cabal-install-2.0.0.1, он есть в том репозитории, который я уже опубликовал. Теперь попробую собрать xmonad-0.13, ShellCheck-0.4.7 и pandoc-2.1.2. Все это под ghc8.2.2. Если интересует что-то более свежее, нужно брать другой план. > > Если смогу разобраться с тем, что писал 9 месяцев назад, то думаю, и другие смогут... Коллеги, так как комплект ghc, кажется, не пересекается с заданием python-3.7, то сейчас можно его собирать. :) Rgrds, Алексей ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] Обновление GHC 2019-03-12 17:48 [devel] Обновление GHC Evgeny Sinelnikov 2019-03-14 15:33 ` Dmitry V. Levin @ 2019-03-16 22:52 ` Ivan Zakharyaschev 2 siblings, 0 replies; 14+ messages in thread From: Ivan Zakharyaschev @ 2019-03-16 22:52 UTC (permalink / raw) To: ALT Linux Team development discussions; +Cc: eugine.kosenko [-- Attachment #1: Type: text/plain, Size: 1313 bytes --] Hello! On Tue, 12 Mar 2019, Evgeny Sinelnikov wrote: > Из интересного, с haskell теперь идут динамические модули, которые > требуются во время работы, но кладутся в > /usr/{lib,lib64}/ghc-X.Y.Z/package-version/libHSpackage-version.soname > > Из-за этого новый ghc не запускается без смонтированного /proc. Я это Помню эту осбенность, мы её заметили, когда glebfm@ бутстрапил наш ghc для mipsel с помощью чуть более свежего (наверное) ghc из Debian. Там в rpath написано $ORIGIN, поэтому для его интерпретации нужен /proc/. (Такая же особенность есть у каких-то java-пакетов.) Правда, спустя год или около того, при бутстрапе ghc для ppc64 с помощью ghc из Debian почему-то эта особенность уже не проявилась, насколько я помню. > поправил переложив динамичческие либы в отдельный > /usr/{lib,lib64}/ghc-X.Y.Z/lib каталог и прописав его в > /etc/ld.so.conf.d/ghc-version.conf Кажется, если в имени .so-файла есть версия, то нет особой необходимости их раскладывать в свои директории, и это решение годится. Больше ничего в голову не приходит на эту тему. > Далее, в rpm-build-haskell исправлена генерация зависимостей, а также > при сборке модулей для динамических библиотек прописана опция > --dynlibdir to %_libdir/$compiler/lib/ > > Готов рассмотреть более уданые варианты, если есть предложения. ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <CAB_XSX3EqaK=F=-P9UmErN=ddvn+OVxBCPaJJem=-eaE+cVwCg@mail.gmail.com>]
* Re: [devel] Обновление GHC @ 2019-04-07 4:42 ` Ivan A. Melnikov 0 siblings, 0 replies; 14+ messages in thread From: Ivan A. Melnikov @ 2019-04-07 4:42 UTC (permalink / raw) To: ALT Linux Team development discussions On Sat, Apr 06, 2019 at 04:27:44PM +0300, Eugine Kosenko wrote: > И да, при установке ghc8.2.2 выстреливает серия вот таких предупреждений: > > Warning: haddock-html: > /usr/share/doc/ghc8.2.2-8.2.2/libraries/filepath-1.4.1.2 doesn't exist or > isn't a directory > Warning: haddock-interfaces: > /usr/share/doc/ghc8.2.2-8.2.2/libraries/unix-2.7.2.2/unix.haddock doesn't > exist or isn't a file > Warning: haddock-html: /usr/share/doc/ghc8.2.2-8.2.2/libraries/unix-2.7.2.2 > doesn't exist or isn't a directory > Warning: haddock-interfaces: > /usr/share/doc/ghc8.2.2-8.2.2/libraries/ghc-boot-th-8.2.2/ghc-boot-th.haddock > doesn't exist or isn't a file > Warning: haddock-html: > /usr/share/doc/ghc8.2.2-8.2.2/libraries/ghc-boot-th-8.2.2 doesn't exist or > isn't a directory > Warning: haddock-interfaces: > /usr/share/doc/ghc8.2.2-8.2.2/libraries/process-1.6.1.0/process.haddock > doesn't exist or isn't a file > ... > > Это у меня что-то сломано, или это сборка такая "грязная"? C ghc8.2.2 у > меня такие же проблемы. Это происходит, если с ghc8.2.2 не ставить пакет ghc8.2.2-doc: файлтриггер пока не умеет работать с таким разделением. -- wbr, iv m. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2019-04-14 16:39 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-03-12 17:48 [devel] Обновление GHC Evgeny Sinelnikov 2019-03-14 15:33 ` Dmitry V. Levin 2019-03-15 10:07 ` Evgeny Sinelnikov 2019-03-15 17:07 ` Ivan Zakharyaschev 2019-04-02 19:47 ` Evgeny Sinelnikov 2019-04-03 12:33 ` Evgeny Sinelnikov 2019-04-03 16:17 ` Ivan Zakharyaschev 2019-04-03 16:20 ` Anton Farygin 2019-04-03 17:13 ` Ivan Zakharyaschev 2019-04-03 17:29 ` Ivan Zakharyaschev 2019-04-11 9:21 ` Evgeny Sinelnikov 2019-04-14 16:39 ` Aleksey Novodvorsky 2019-03-16 22:52 ` Ivan Zakharyaschev 2019-04-07 4:42 ` Ivan A. Melnikov
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git