xsounds.org repo is down

[nponeccop]

If you feel like deprecating ArchHaskell/cblrepo in favour of Stack let us know in Readme

[magthe]

It isn't down any longer.

[nponeccop]

Was i686 repo support dropped? x86_64 works fine

[magthe]

Yupp, see https://mail.haskell.org/pipermail/arch-haskell/2017-February/004986.html and https://mail.haskell.org/pipermail/arch-haskell/2017-March/004987.html

[nponeccop]

Take it as the only vote to keep i686 alive then :)

cblrepo/archhaskell are less useful these days when stack snapshots contain so many packages buildable out of the box.

However build time and to less extent build RAM requirements are still a problem - stack tool itself takes more than 1 hour to build.

So something like an ability to build a stack snapshot as a cblrepo pacman repo would be nice :) I thought even of dropping versioning scheme and using haskell-foo-8.5 for all lts-8.5 packages independently of actual version.

Also note they are not deprecating i686 - they only deprecate fully i686 setup. multilib which is i686 and x86_64 coexisting under the same x86_64 kernel is not at the point of deprecation. So you may look info about ghc support in multilib.

i686 is still good for VPS as many tasks require 2GB VPS or smaller, and in my experience i686 consumes some 30% less ram than x86_64.

[magthe]

Yupp, ArchHaskell adds less value nowadays when we have tools like stack and nix (and an always improving cabal-install). Which is why I've given some thought as to what the future of ArchHaskell should be.

AFAIU multilib isn't really something that's relevant in this context. Having available Haskell libs compiled for i686 for a distro that doesn't support i686 hardware seems pointless.

One contributing factor is that the person who's providing the storage for the repo wants to move to cheaper hosting plan, one with less storage included. Removing the i686 repo helps him do that.

[nponeccop]

The text below is just to clarify why I mentioned multilib.

You already mentioned cheaper hosting plans. i686 serves exactly this purpose. There is no such thing as i686 hardware these days, and that's the reason why it's no longer supported. There's very little chance that anyone will use a 32 bit dedicated server in production these days. And playing with Haskell on an old i686 laptop is hardly pleasant because it uses enormous amounts of RAM for linking.

However pretty many people run i686 code on 64-bit kernels - that's why multilib is not going to die in next few years. And running a i686 application saves you some 30% of RAM which means you can use a cheaper hosting plan. With containers (or chroots for that matter) I can even run an Archlinux Haskell i686 binary on whatever distribution is supported by VPS host.

[magthe]

1. It's a saving in storage, not RAM, that's needed.
2. Reducing storage needs means either reducing the number of packages, or reducing supported platforms.
3. Since ArchLinux will remove the official i686 repos later this year it is rather natural for ArchHaskell to do the same. (I just sped it up by a few months due to a wish to lower costs from the provider of the free hosting.)

On a side note I am curious how many "pretty many" actually is. I know that a lot of people run 32-bit applications on 64-bit Windows. That seems to come from a lot of companies only providing 32-bit versions of their proprietary SW. The little I've read about this suggests that it's not at all as widely used on Linux.