I would like to have dhall-haskell in Fedora, have questions

[Adam Saleh]

Hi,

I don't think I am ready to go through the package process [1] with this
just yet, but I have questions to ask, so I am writing here :-)

I have been using https://dhall-lang.org/ for some of my
openshift/kubernetes configuration, like it much more than writing out
YAML, and I would like to have it available in Fedora.

I am mostly interested in the cli-utilities that compile dhall files to
various data formats (i.e. bash, yaml, json, text, e.t.c) and provide
development support (linting, language-server, e.t.c.), currently I am
using the statically compiled binaries from their github releases.

I know that there have been some attempts from dhall developer to use nix
to build RPMs, but after they started distributing statically compiled
binaries, they didn't pursue this further.

I can build binaries on my box using stack, but I am not yet sure how to
use fedora-provided utilities (i.e. is it just i.e. 'cabal-rpm builddep &&
cabal-rpm spec dhall && cabal-rpm local dhall' ?).

Here are my questions:

Did anybody try to package Dhall already?

Can I take a stab at it? :-)

Do I correctly assume I should first be able to build the binaries with
fedora-provided infrastructure (and not rely on i.e. nix)?

Should I assume i.e Fedora 31 is tracking Stackage LTS 13 and i.e Fedora 32
would be tracking Stackage LTS 14, when i.e. trying to resolve library
dependencies?

When running dealing with cabal-rpm, what should I do about packages
reported by `cabal-rpm missingdeps`?

Would some of you have time to help me troubleshoot, or answer more of my
questions? :)

Thanks for any response!

Adam

[1]
https://fedoraproject.org/wiki/Haskell_SIG?rd=SIGs/Haskell#New_Package_Proce...
and https://docs.fedoraproject.org/en-US/packaging-guidelines/Haskell/ ?

[Jens-Ulrik Petersen]

Hi Adam, great questions

On Mon, Jan 20, 2020 at 8:18 PM Adam Saleh  wrote:
> I have been using https://dhall-lang.org/ for some of my
> openshift/kubernetes configuration, like it much more than writing out
> YAML, and I would like to have it available in Fedora.

Cool, dhall is nice
> I am mostly interested in the cli-utilities that compile dhall files to
> various data formats (i.e. bash, yaml, json, text, e.t.c) and provide
> development support (linting, language-server, e.t.c.), currently I am
> using the statically compiled binaries from their github releases.

Maybe I (or someone) could make a copr repo in the meantime, would be that
be useful?

I know that there have been some attempts from dhall developer to use nix
> to build RPMs, but after they started distributing statically compiled
> binaries, they didn't pursue this further.

(Even I have struggled with packaging nix: though I have an experimental
copr, though it *might* be out of date, and I am still unsure about the
systemd units.)

I can build binaries on my box using stack, but I am not yet sure how to
> use fedora-provided utilities (i.e. is it just i.e. 'cabal-rpm builddep &&
> cabal-rpm spec dhall && cabal-rpm local dhall' ?).

You can try running `cabal-rpm install --binary dhall` or you might prefer
--standalone.
It ought to work, though I didn't try that yet - if not and you get stuck
please ask.
> Did anybody try to package Dhall already?

I am slowly working through the missing deps with that goal in mind but
help is welcome.
> Can I take a stab at it? :-)

You can, sure
> Do I correctly assume I should first be able to build the binaries with
> fedora-provided infrastructure (and not rely on i.e. nix)?

Yes
> Should I assume i.e Fedora 31 is tracking Stackage LTS 13 and i.e Fedora
> 32 would be tracking Stackage LTS 14, when i.e. trying to resolve library
> dependencies?

That's correct - I forgot to announce here, but I am still planning to
rebase to LTS 14 for F32, but I *think* it shouldn't have a huge impact on
dhall. :)
> When running dealing with cabal-rpm, what should I do about packages
> reported by `cabal-rpm missingdeps`?

cabal-rpm install should generate and builds rpms for the missing packages
(libs) locally.
cabal-rpm ... --standalone will use cabal-install instead to build the
missing deps, generating an rpm for the executables only.

Btw I recommend using cabal-rpm-2.0 which is currently in F31 testing.
(Also unannounced here, here.:)

Would some of you have time to help me troubleshoot, or answer more of my
> questions? :)

Ask away.
And sorry for the slow reply - just saw your mail

Thanks, Jens

[Tristan de CACQUERAY]

Hi, I am interested in such package too, please let me know how can I help.

FWIW i did a copr using the binary release from the dhall-haskell release page here: https://copr.fedorainfracloud.org/coprs/tdecacqu/dhall/builds/

And I am also working on Ansible and Openshift binding here: https://github.com/TristanCacqueray/dhall-ansible and there: https://github.com/TristanCacqueray/dhall-openshift

[Adam Saleh]

Hi,

Tristan, awesome, I might be using the binaries in the meanwhile. I still
would like to get a real srpm going :-)

Jens, I tried to build with the --standalone flag, but for some reason, it
fails when fetching `cborg`

```
Running cabal-rpm install cborg
cborg-0.2.1.0 in Stackage lts-13
cborg-0.2.1.0 in Stackage lts-13
cborg-0.2.1.0 in Stackage lts-13
ghc-cborg
dos2unix: converting file cborg.cabal to Unix format...
cabal-rpm: cborg.cabal: renameFile:renamePath:rename: unsupported operation
(Invalid cross-device link)
cabal-rpm: cabal-rpm install cborg failed with exit code 1
```

I tried to use cabal-rpm-2.0 (downloaded forms stack) with the same result.
Will try to run this in a container, maybe cabal-rpm doesn't like my
disk-layout?

Adam

On Tue, Jan 28, 2020 at 1:30 PM Tristan de CACQUERAY 
wrote:
> Hi, I am interested in such package too, please let me know how can I help.
>
> FWIW i did a copr using the binary release from the dhall-haskell release
> page here: https://copr.fedorainfracloud.org/coprs/tdecacqu/dhall/builds/
>
> And I am also working on Ansible and Openshift binding here:
> https://github.com/TristanCacqueray/dhall-ansible and there:
> https://github.com/TristanCacqueray/dhall-openshift
> _______________________________________________
> haskell mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]...

[Jens-Ulrik Petersen]

On Tue, Jan 28, 2020 at 11:09 PM Adam Saleh  wrote:
> Tristan, awesome, I might be using the binaries in the meanwhile. I still
> would like to get a real srpm going :-)

I have created: https://copr.fedorainfracloud.org/coprs/petersen/dhall/
If people could test it that would be great.
> Jens, I tried to build with the --standalone flag, but for some reason, it
> fails when fetching `cborg`

:
> cabal-rpm: cborg.cabal: renameFile:renamePath:rename: unsupported
> operation (Invalid cross-device link)

:
> I tried to use cabal-rpm-2.0 (downloaded forms stack) with the same
> result. Will try to run this in a container, maybe cabal-rpm doesn't like
> my disk-layout?

Thanks for trying - if you can file a bug report in bugzilla or github I
will certainly look into it.

Thanks, Jens

[Tristan de CACQUERAY]

Hi Jens,

that version is quite old (1.19.1 is from 2018), and it is missing the `json-to-dhall` utility.
Here is a tentative bump here: https://github.com/fedora-haskell/dhall/pull/1

-Tristan

[Jens-Ulrik Petersen]

Thanks a lot, I merged and have updated my copr.

Jens

On Sat, 8 Feb 2020, 03:40 Tristan de CACQUERAY,  wrote:
> Hi Jens,
>
> that version is quite old (1.19.1 is from 2018), and it is missing the
> `json-to-dhall` utility.
> Here is a tentative bump here:
> https://github.com/fedora-haskell/dhall/pull/1
>
> -Tristan
> _______________________________________________
> haskell mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]...

[Jens-Ulrik Petersen]

I also add dhall- yaml to the packaging. :)

I forgot to follow up here. :)
Let me know if spot anything else.

Jens

[Tristan Cacqueray]

On Tue, Feb 11, 2020 at 09:19 Jens-Ulrik Petersen wrote:
> I also add dhall- yaml to the packaging. :)
>
> I forgot to follow up here. :)
> Let me know if spot anything else.
>
> Jens

Hi Jens,

would it possible to also include the Dhall devel files too?

Thanks!
-Tristan

[Jens-Ulrik Petersen]

Sorry keep missing the mails...

On Tue, Feb 11, 2020 at 11:24 AM Tristan Cacqueray 
wrote:
> would it possible to also include the Dhall devel files too?

Can you expand on the use-case?

The short answer for the current copr is that it is not so easy but let me
think on it.
I think better to get dhall into Fedora itself: progress is being made - 5
more package reviews left.

Jens

[Jens-Ulrik Petersen]

Or what did you mean by devel files exactly?

Jens

[Tristan Cacqueray]

On Mon, Feb 17, 2020 at 18:16 Jens-Ulrik Petersen wrote:
> Or what did you mean by devel files exactly?
>
> Jens

I meant the files that enable using the haskell dhall binding[0].
I guess this would be named ghc-dhall-devel, like it is done for
xmonad.

Though I agree it would be better to get the cli tool into Fedora
first.

Thanks,
-Tristan

[0]: https://hackage.haskell.org/package/dhall-1.30.0/docs/Dhall.html

[Jens-Ulrik Petersen]

I think I also replied already in github, but for the record:

On Mon, Feb 17, 2020 at 8:52 PM Tristan Cacqueray 
wrote:
> On Mon, Feb 17, 2020 at 18:16 Jens-Ulrik Petersen wrote:
> > Or what did you mean by devel files exactly?
>
> I meant the files that enable using the haskell dhall binding[0].
> I guess this would be named ghc-dhall-devel

Okay, the problem is the way the copr is built currently using
cabal-install makes this quite difficult.

If you need it locally for something I would suggest just to cabal install
it yourself, or via stack.

Anyway hopefully dhall will land in Fedora before too long.

Jens