[devel] Обновление GHC

[devel] Обновление GHC

[Evgeny Sinelnikov]

Здравствуйте,

хочу снова поднять вопрос по обновлению компилятора 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)

Re: [devel] Обновление GHC

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] Обновление GHC

[Evgeny Sinelnikov]

Здравствуйте,

план бутстрапа следующий:
- 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)

Re: [devel] Обновление GHC

[Ivan Zakharyaschev]

[-- 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

Re: [devel] Обновление GHC

[Evgeny Sinelnikov]

вт, 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 - для загрузки исходников с правильным релизом.

Re: [devel] Обновление GHC

[Evgeny Sinelnikov]

ср, 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)

Re: [devel] Обновление GHC

[Ivan Zakharyaschev]

[-- 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

Re: [devel] Обновление GHC

[Anton Farygin]

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).

Re: [devel] Обновление GHC

[Ivan Zakharyaschev]

[-- 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

Re: [devel] Обновление GHC

[Ivan Zakharyaschev]

[-- 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

Re: [devel] Обновление GHC

[Evgeny Sinelnikov]

Здравствуйте,

сб, 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)

Re: [devel] Обновление GHC

[Aleksey Novodvorsky]

вс, 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, Алексей

Re: [devel] Обновление GHC

[Ivan Zakharyaschev]

[-- 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/
> 
> Готов рассмотреть более уданые варианты, если есть предложения.

Re: [devel] Обновление GHC

[Ivan A. Melnikov]

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.