Hackage: "Build: PlanningFailed"

older
Cabal: Can only one processor core...

Volker Wysk

31 Mar 2024 31 Mar '24

6:16 a.m.

Hello I'm fighting with Hackage. To make things short, I've published my HsShellScript library (was a package candidate before). Here's the library's Hackage page: https://hackage.haskell.org/package/hsshellscript-3.6.2 And there's a button labeled "Build: PlanningFailed". When I click on it, I get the following messages under "Build Log": -----snip----- Resolving dependencies... Error: cabal: Could not resolve dependencies: [__0] trying: hsshellscript-3.6.2 (user goal) [__1] next goal: base (dependency of hsshellscript) [__1] rejecting: base-4.18.1.0/installed-4.18.1.0 (conflict: hsshellscript => base>=4.13.0 && <4.14) [__1] skipping: base-4.19.1.0, base-4.19.0.0, base-4.18.2.0, base-4.18.1.0, base-4.18.0.0, base-4.17.2.1, base-4.17.2.0, base-4.17.1.0, base-4.17.0.0, base-4.16.4.0, base-4.16.3.0, base-4.16.2.0, base-4.16.1.0, base-4.16.0.0, base-4.15.1.0, base-4.15.0.0, base-4.14.3.0, base-4.14.2.0, base-4.14.1.0, base-4.14.0.0 (has the same characteristics that caused the previous version to fail: excluded by constraint '>=4.13.0 && <4.14' from 'hsshellscript') [__1] rejecting: base-4.13.0.0, base-4.12.0.0, base-4.11.1.0, base-4.11.0.0, base-4.10.1.0, base-4.10.0.0, base-4.9.1.0, base-4.9.0.0, base-4.8.2.0, base-4.8.1.0, base-4.8.0.0, base-4.7.0.2, base-4.7.0.1, base-4.7.0.0, base-4.6.0.1, base-4.6.0.0, base-4.5.1.0, base-4.5.0.0, base-4.4.1.0, base-4.4.0.0, base-4.3.1.0, base-4.3.0.0, base-4.2.0.2, base-4.2.0.1, base-4.2.0.0, base-4.1.0.0, base-4.0.0.0, base-3.0.3.2, base-3.0.3.1 (constraint from non-upgradeable package requires installed instance) [__1] fail (backjumping, conflict set: base, hsshellscript) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: base, hsshellscript -----snip----- Why does it reject the base library? The versions conflict, but why does it think the version should be base-4.18.1.0? The library compiles okay on my machine (using "cabal build"). I have this in the hsshellscript.cabal file, under "build-depends:": base >= 4.13.0 && < 4.14 I've got this version information from calling "cabal gen-bounds". Cheers, Volker

Show replies by date

Tom Ellis

31 Mar 31 Mar

6:27 a.m.

On Sun, Mar 31, 2024 at 12:16:45PM +0200, Volker Wysk wrote:

...

Why does it reject the base library? The versions conflict, but why does it think the version should be base-4.18.1.0? The library compiles okay on my machine (using "cabal build"). I have this in the hsshellscript.cabal file, under "build-depends:": base >= 4.13.0 && < 4.14

I've got this version information from calling "cabal gen-bounds". 4.13 was shipped with GHC 8.8 and 4.18 was shipped with 9.6. See https://wiki.haskell.org/Base_package

I guess you called "cabal gen-bounds" with ghc version 8.8 in your PATH but you're now trying to install the library with ghc 9.6 in your PATH. The solution is most likely to change the base bound to < 4.20 (so it works with every version of base released so far). You can avoid uploading a new version of your package by making a package revision to do this, accessed via the link "edit package information" under your package's Hackage page. Tom

Volker Wysk

6:50 a.m.

Hi, Tom! Am Sonntag, dem 31.03.2024 um 11:27 +0100 schrieb Tom Ellis:

...

On Sun, Mar 31, 2024 at 12:16:45PM +0200, Volker Wysk wrote:

...
Why does it reject the base library? The versions conflict, but why does it think the version should be base-4.18.1.0? The library compiles okay on my machine (using "cabal build"). I have this in the hsshellscript.cabal file, under "build-depends:": base >= 4.13.0 && < 4.14

I've got this version information from calling "cabal gen-bounds". 4.13 was shipped with GHC 8.8 and 4.18 was shipped with 9.6. See https://wiki.haskell.org/Base_package

I guess you called "cabal gen-bounds" with ghc version 8.8 in your PATH

That's correct.

...

but you're now trying to install the library with ghc 9.6 in your PATH.

No, I'm just trying to upload it to Hackage properly. That's where I got that error.

...

The solution is most likely to change the base bound to < 4.20 (so it works with every version of base released so far).

Why aren't all the base package versions available? I thought this was one of the purposes of the Cabal system... And wouldn't it be better to remove the upper bound entirely?

...

You can avoid uploading a new version of your package by making a package revision to do this, accessed via the link "edit package information" under your package's Hackage page.

Thanks!! I'm editing the package information next. Cheers, Volker

Volker Wysk

7:15 a.m.

Am Sonntag, dem 31.03.2024 um 12:50 +0200 schrieb Volker Wysk:

...

(...)

...
You can avoid uploading a new version of your package by making a package revision to do this, accessed via the link "edit package information" under your package's Hackage page.

Thanks!! I'm editing the package information next.

I've done that, but the "Build: PlanningFailed" error is still there. And the build log is the old one (with the previous version bounds). Even though the new bounds are displayed on the package's Hackage page... How can I trigger a new build? Cheers, Volker

Volker Wysk

7:18 a.m.

Am Sonntag, dem 31.03.2024 um 13:15 +0200 schrieb Volker Wysk:

...

Am Sonntag, dem 31.03.2024 um 12:50 +0200 schrieb Volker Wysk:

...
(...)

...
You can avoid uploading a new version of your package by making a package revision to do this, accessed via the link "edit package information" under your package's Hackage page.

Thanks!! I'm editing the package information next.

I've done that, but the "Build: PlanningFailed" error is still there. And the build log is the old one (with the previous version bounds). Even though the new bounds are displayed on the package's Hackage page...

How can I trigger a new build?

Never mind, I found it on the "edit package information" page. Volker

Henning Thielemann

7:18 a.m.

On Sun, 31 Mar 2024, Volker Wysk wrote:

...

Am Sonntag, dem 31.03.2024 um 12:50 +0200 schrieb Volker Wysk:

...
(...)

...
You can avoid uploading a new version of your package by making a package revision to do this, accessed via the link "edit package information" under your package's Hackage page.

Thanks!! I'm editing the package information next.

I've done that, but the "Build: PlanningFailed" error is still there. And the build log is the old one (with the previous version bounds). Even though the new bounds are displayed on the package's Hackage page...

How can I trigger a new build?

If you login at Hackage, then under https://hackage.haskell.org/package/hsshellscript/maintain the last item is: "Trigger rebuild"

Volker Wysk

7:23 a.m.

Am Sonntag, dem 31.03.2024 um 13:18 +0200 schrieb Henning Thielemann:

...

On Sun, 31 Mar 2024, Volker Wysk wrote:

...
Am Sonntag, dem 31.03.2024 um 12:50 +0200 schrieb Volker Wysk:

...
(...)

...
You can avoid uploading a new version of your package by making a package revision to do this, accessed via the link "edit package information" under your package's Hackage page.

Thanks!! I'm editing the package information next.

I've done that, but the "Build: PlanningFailed" error is still there. And the build log is the old one (with the previous version bounds). Even though the new bounds are displayed on the package's Hackage page...

How can I trigger a new build?

If you login at Hackage, then under

https://hackage.haskell.org/package/hsshellscript/maintain

the last item is: "Trigger rebuild"

Hmm... That doesn't seem to do anything. I've tried it several times, but I always get only two build reports. These are from before. The "Build: PlanningFailed" message persists. Seems like I need to upload it again. Cheers Volker

Andrew Lelechenko

1:22 p.m.

If triggering rebuild does not work immediately, remove documentation first and trigger rebuild afterwards. There are 4 build reports now: https://hackage.haskell.org/package/hsshellscript-3.6.2/reports/4, but the latest one fails because, as it seems, your package does not actually support GHC 9.6 and newer dependencies. Best regards, Andrew

...

On 31 Mar 2024, at 12:23, Volker Wysk wrote:

Am Sonntag, dem 31.03.2024 um 13:18 +0200 schrieb Henning Thielemann:

...
On Sun, 31 Mar 2024, Volker Wysk wrote:

...
Am Sonntag, dem 31.03.2024 um 12:50 +0200 schrieb Volker Wysk:

...
(...)

...
You can avoid uploading a new version of your package by making a package revision to do this, accessed via the link "edit package information" under your package's Hackage page.

Thanks!! I'm editing the package information next.

I've done that, but the "Build: PlanningFailed" error is still there. And the build log is the old one (with the previous version bounds). Even though the new bounds are displayed on the package's Hackage page...

How can I trigger a new build?

If you login at Hackage, then under

https://hackage.haskell.org/package/hsshellscript/maintain

the last item is: "Trigger rebuild"

Hmm... That doesn't seem to do anything. I've tried it several times, but I always get only two build reports. These are from before. The "Build: PlanningFailed" message persists. Seems like I need to upload it again.

Cheers Volker _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Volker Wysk

1 Apr 1 Apr

7:20 a.m.

Am Sonntag, dem 31.03.2024 um 18:22 +0100 schrieb Andrew Lelechenko:

...

If triggering rebuild does not work immediately, remove documentation first and trigger rebuild afterwards.

There are 4 build reports now: https://hackage.haskell.org/package/hsshellscript-3.6.2/reports/4, but the latest one fails because, as it seems, your package does not actually support GHC 9.6 and newer dependencies.

Yes, that's what it looks like. It's good that you noticed it. I'm a Linux user (with Ubuntu 22.04 LTS). My GHC (8.8.4) comes with the haskell-platform metapackage. GHC 9.8.2 should be included in Ubuntu 24.04 LTS. I see no easy way to get a running GHC 9.6. now, so I can fix it. According to https://wiki.haskell.org/Base_package , my GHC version, 8.8.4, should have been released between Jul 2019 and Mar 2020. That's way before my Ubuntu 22.04 distribution. I don't get it, why such an old version is being shipped. The ghc version in the newest Ubuntu (23.10) is old too... So for now, I'll change the upper bound of the base package version back to 4.14 and support only GHC 8.8. Until I have a running Haskell platform with the newest GHC version again. Looks like I have to install it manually, not via apt. Cheers, Volker

Iustin Pop

7:29 a.m.

On 2024-04-01 13:20:37, Volker Wysk wrote:

...

Am Sonntag, dem 31.03.2024 um 18:22 +0100 schrieb Andrew Lelechenko:

...
If triggering rebuild does not work immediately, remove documentation first and trigger rebuild afterwards.

There are 4 build reports now: https://hackage.haskell.org/package/hsshellscript-3.6.2/reports/4, but the latest one fails because, as it seems, your package does not actually support GHC 9.6 and newer dependencies.

Yes, that's what it looks like. It's good that you noticed it.

I'm a Linux user (with Ubuntu 22.04 LTS). My GHC (8.8.4) comes with the haskell-platform metapackage. GHC 9.8.2 should be included in Ubuntu 24.04 LTS. I see no easy way to get a running GHC 9.6. now, so I can fix it.

According to https://wiki.haskell.org/Base_package , my GHC version, 8.8.4, should have been released between Jul 2019 and Mar 2020. That's way before my Ubuntu 22.04 distribution. I don't get it, why such an old version is being shipped. The ghc version in the newest Ubuntu (23.10) is old too...

Because the way entire toolchains and the associated libraries are built and transitioned, you can't simply upgrade the compiler. A GHC or Perl of Python transition in Debian (and thus Ubuntu) takes 1-2 months to fully roll out, and more so probably for compiled things such as Haskell. Plus, the entire distribution is stabilised before the final released. So you should count at least 6 months, if not a year, before the distribution release date. Debian's Haskell group could always use more hands as well ;-) Just use ghcup or a more recent distribution within a VM to debug and test. regards, iustin

Henning Thielemann

7:38 a.m.

On Mon, 1 Apr 2024, Iustin Pop wrote:

...

Because the way entire toolchains and the associated libraries are built and transitioned, you can't simply upgrade the compiler. A GHC or Perl of Python transition in Debian (and thus Ubuntu) takes 1-2 months to fully roll out, and more so probably for compiled things such as Haskell. Plus, the entire distribution is stabilised before the final released.

So you should count at least 6 months, if not a year, before the distribution release date. Debian's Haskell group could always use more hands as well ;-)

Just use ghcup or a more recent distribution within a VM to debug and test.

One can use Nix to install newer versions even under Ubuntu. I actually install the Linux binary tarballs and compress them in a squasfs, because every GHC installation consumes more than a gigaton of harddisk space.

Volker Wysk

3 Apr 3 Apr

1:43 a.m.

Am Montag, dem 01.04.2024 um 13:38 +0200 schrieb Henning Thielemann:

...

On Mon, 1 Apr 2024, Iustin Pop wrote:

...
Because the way entire toolchains and the associated libraries are built and transitioned, you can't simply upgrade the compiler. A GHC or Perl of Python transition in Debian (and thus Ubuntu) takes 1-2 months to fully roll out, and more so probably for compiled things such as Haskell. Plus, the entire distribution is stabilised before the final released.

So you should count at least 6 months, if not a year, before the distribution release date. Debian's Haskell group could always use more hands as well ;-)

Just use ghcup or a more recent distribution within a VM to debug and test.

One can use Nix to install newer versions even under Ubuntu. I actually install the Linux binary tarballs and compress them in a squasfs, because every GHC installation consumes more than a gigaton of harddisk space.

Yes, my ~/.ghcup directory has 4.7 Gigabytes... That's a litte heavy. But so what? It's the age of terabyte SSDs. Cheers Volker

Brandon Allbery

1 Apr 1 Apr

11:41 a.m.

Debian pretty much didn't have a Haskell maintainers group for much of that time period. There's a new group now, but it's taking time for them to modernize everything. On Mon, Apr 1, 2024 at 7:29 AM Iustin Pop wrote:

...

On 2024-04-01 13:20:37, Volker Wysk wrote:

...
Am Sonntag, dem 31.03.2024 um 18:22 +0100 schrieb Andrew Lelechenko:

...
If triggering rebuild does not work immediately, remove documentation first and trigger rebuild afterwards.

There are 4 build reports now: https://hackage.haskell.org/package/hsshellscript-3.6.2/reports/4 , but the latest one fails because, as it seems, your package does not actually support GHC 9.6 and newer dependencies.

Yes, that's what it looks like. It's good that you noticed it.

I'm a Linux user (with Ubuntu 22.04 LTS). My GHC (8.8.4) comes with the haskell-platform metapackage. GHC 9.8.2 should be included in Ubuntu 24.04 LTS. I see no easy way to get a running GHC 9.6. now, so I can fix it.

According to https://wiki.haskell.org/Base_package , my GHC version, 8.8.4, should have been released between Jul 2019 and Mar 2020. That's way before my Ubuntu 22.04 distribution. I don't get it, why such an old version is being shipped. The ghc version in the newest Ubuntu (23.10) is old too...

Because the way entire toolchains and the associated libraries are built and transitioned, you can't simply upgrade the compiler. A GHC or Perl of Python transition in Debian (and thus Ubuntu) takes 1-2 months to fully roll out, and more so probably for compiled things such as Haskell. Plus, the entire distribution is stabilised before the final released.

So you should count at least 6 months, if not a year, before the distribution release date. Debian's Haskell group could always use more hands as well ;-)

Just use ghcup or a more recent distribution within a VM to debug and test.

regards, iustin _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- brandon s allbery kf8nh allbery.b@gmail.com

Volker Wysk

3 Apr 3 Apr

1:41 a.m.

Am Montag, dem 01.04.2024 um 13:29 +0200 schrieb Iustin Pop:

...

On 2024-04-01 13:20:37, Volker Wysk wrote:

...
Am Sonntag, dem 31.03.2024 um 18:22 +0100 schrieb Andrew Lelechenko:

...
If triggering rebuild does not work immediately, remove documentation first and trigger rebuild afterwards.

There are 4 build reports now: https://hackage.haskell.org/package/hsshellscript-3.6.2/reports/4, but the latest one fails because, as it seems, your package does not actually support GHC 9.6 and newer dependencies.

Yes, that's what it looks like. It's good that you noticed it.

I'm a Linux user (with Ubuntu 22.04 LTS). My GHC (8.8.4) comes with the haskell-platform metapackage. GHC 9.8.2 should be included in Ubuntu 24.04 LTS. I see no easy way to get a running GHC 9.6. now, so I can fix it.

According to https://wiki.haskell.org/Base_package , my GHC version, 8.8.4, should have been released between Jul 2019 and Mar 2020. That's way before my Ubuntu 22.04 distribution. I don't get it, why such an old version is being shipped. The ghc version in the newest Ubuntu (23.10) is old too...

Because the way entire toolchains and the associated libraries are built and transitioned, you can't simply upgrade the compiler. A GHC or Perl of Python transition in Debian (and thus Ubuntu) takes 1-2 months to fully roll out, and more so probably for compiled things such as Haskell. Plus, the entire distribution is stabilised before the final released.

So you should count at least 6 months, if not a year, before the distribution release date. Debian's Haskell group could always use more hands as well ;-)

Just use ghcup or a more recent distribution within a VM to debug and test.

I've installed it via ghcup. That was easy! Thanks for the tip. I've uploaded hsshellscript to Hackage now. It seems like all works, but there is no build report. Volker

Andrew Lelechenko

1 Apr 1 Apr

5:20 p.m.

Just use ghcup (https://www.haskell.org/ghcup/install/)? Best regards, Andrew

...

On 1 Apr 2024, at 12:20, Volker Wysk wrote:

Am Sonntag, dem 31.03.2024 um 18:22 +0100 schrieb Andrew Lelechenko:

...
If triggering rebuild does not work immediately, remove documentation first and trigger rebuild afterwards.

There are 4 build reports now: https://hackage.haskell.org/package/hsshellscript-3.6.2/reports/4, but the latest one fails because, as it seems, your package does not actually support GHC 9.6 and newer dependencies.

Yes, that's what it looks like. It's good that you noticed it.

I'm a Linux user (with Ubuntu 22.04 LTS). My GHC (8.8.4) comes with the haskell-platform metapackage. GHC 9.8.2 should be included in Ubuntu 24.04 LTS. I see no easy way to get a running GHC 9.6. now, so I can fix it.

According to https://wiki.haskell.org/Base_package , my GHC version, 8.8.4, should have been released between Jul 2019 and Mar 2020. That's way before my Ubuntu 22.04 distribution. I don't get it, why such an old version is being shipped. The ghc version in the newest Ubuntu (23.10) is old too...

So for now, I'll change the upper bound of the base package version back to 4.14 and support only GHC 8.8. Until I have a running Haskell platform with the newest GHC version again. Looks like I have to install it manually, not via apt.

Cheers, Volker _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Volker Wysk

3 Apr 3 Apr

1:44 a.m.

Am Montag, dem 01.04.2024 um 22:20 +0100 schrieb Andrew Lelechenko:

...

Just use ghcup (https://www.haskell.org/ghcup/install/)?

Done. It seems to work now. But no build report on Hackage... Volker

Brandon Allbery

31 Mar 31 Mar

10:51 a.m.

On Sun, Mar 31, 2024 at 6:51 AM Volker Wysk wrote:

...

Why aren't all the base package versions available? I thought this was one of the purposes of the Cabal system...

And wouldn't it be better to remove the upper bound entirely?

`base` is special, since it's tightly linked to the compiler (the compiler hardcodes the addresses of key data types and values, such as `Bool` and specifically `True` so it can compile guards). As such, it is impossible to pick a different version of `base` for use with a given compiler version. Removing the upper bound has the opposite problem: if `base` changes enough (say, a wholesale change from `String` to `Text`, not that that seems likely to happen in the near term) you will be claiming that your code is compatible with it. -- brandon s allbery kf8nh allbery.b@gmail.com

Volker Wysk

11:30 a.m.

Am Sonntag, dem 31.03.2024 um 10:51 -0400 schrieb Brandon Allbery:

...

On Sun, Mar 31, 2024 at 6:51 AM Volker Wysk wrote:

...
Why aren't all the base package versions available? I thought this was one of the purposes of the Cabal system...

And wouldn't it be better to remove the upper bound entirely?

`base` is special, since it's tightly linked to the compiler (the compiler hardcodes the addresses of key data types and values, such as `Bool` and specifically `True` so it can compile guards). As such, it is impossible to pick a different version of `base` for use with a given compiler version.

Removing the upper bound has the opposite problem: if `base` changes enough (say, a wholesale change from `String` to `Text`, not that that seems likely to happen in the near term) you will be claiming that your code is compatible with it.

This makes sense. So what happens when a new GHC version is released? It depends on the version of the base package, which it ships. When the base package doesn't get an API-breaking change, then all is well. When it *does* have such a change, all the Hackage packages must be checked for compatibility with the new compiler version, and the upper bound of the base package version must be adjusted. That sounds like a lot of effort. It would be major happening in the Haskell community. This makes sense, too. Thanks, now it's clear. Volker

Brandon Allbery

11:39 a.m.

On Sun, Mar 31, 2024 at 11:30 AM Volker Wysk wrote:

...

So what happens when a new GHC version is released? It depends on the version of the base package, which it ships. When the base package doesn't get an API-breaking change, then all is well.

There's an implicit contract that such major changes will be guarded behind an epoch version bump, so you'll see many packages depending on `base < 5`.

...

When it *does* have such a change, all the Hackage packages must be checked for compatibility with the new compiler version, and the upper bound of the base package version must be adjusted. That sounds like a lot of effort. It would be major happening in the Haskell community.

See https://ghc.gitlab.haskell.org/head.hackage/ . In short, a large proportion of Hackage (I think corresponding to the most recent Stackage LTS?) is tested regularly, and needed changes to packages are made as overlays in head.hackage and submitted upstream before releases. -- brandon s allbery kf8nh allbery.b@gmail.com

Bryan Richter

11:58 a.m.

Hi all, On Sun, 31 Mar 2024 at 13:51, Volker Wysk wrote:

...

Hi, Tom!

Am Sonntag, dem 31.03.2024 um 11:27 +0100 schrieb Tom Ellis:

...
On Sun, Mar 31, 2024 at 12:16:45PM +0200, Volker Wysk wrote:

...
Why does it reject the base library? The versions conflict, but why

does it

...

...
...
think the version should be base-4.18.1.0? The library compiles okay on my machine (using "cabal build"). I have this in the hsshellscript.cabal file, under "build-depends:": base >= 4.13.0 && < 4.14

...
but you're now trying to install the library with ghc 9.6 in your PATH.

No, I'm just trying to upload it to Hackage properly. That's where I got that error.

I guess the problem here is that the Hackage Builder itself is using GHC 9.6, while Volker had been building with GHC 8.8. Therefore, Hackage was stuck trying to use base-4.18.1.0. I think that is the direct answer to Volker's question. I can imagine there may be follow-up questions, however...

Volker Wysk

12:09 p.m.

Am Sonntag, dem 31.03.2024 um 18:58 +0300 schrieb Bryan Richter:

...

Hi all,

On Sun, 31 Mar 2024 at 13:51, Volker Wysk wrote:

...
Hi, Tom!

Am Sonntag, dem 31.03.2024 um 11:27 +0100 schrieb Tom Ellis:

...
On Sun, Mar 31, 2024 at 12:16:45PM +0200, Volker Wysk wrote:

...
Why does it reject the base library? The versions conflict, but why does it think the version should be base-4.18.1.0? The library compiles okay on my machine (using "cabal build"). I have this in the hsshellscript.cabal file, under "build-depends:": base >= 4.13.0 && < 4.14

...
but you're now trying to install the library with ghc 9.6 in your PATH.

No, I'm just trying to upload it to Hackage properly. That's where I got that error.

I guess the problem here is that the Hackage Builder itself is using GHC 9.6, while Volker had been building with GHC 8.8. Therefore, Hackage was stuck trying to use base-4.18.1.0. I think that is the direct answer to Volker's question. I can imagine there may be follow-up questions, however...

Yes, that's right. And the follow-up question is: Why aren't all base package versions available to the Hackage Builder? Brandon answered that and made it clear. Cheers Volker

412

Age (days ago)

415

Last active (days ago)

List overview

Download

20 comments

7 participants

participants (7)

Andrew Lelechenko
Brandon Allbery
Bryan Richter
Henning Thielemann
Iustin Pop
Tom Ellis
Volker Wysk

Hackage: "Build: PlanningFailed"

tags

participants (7)