Newest at the top
2024-12-24 17:08:21 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
2024-12-24 17:03:42 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
2024-12-24 16:58:36 +0100 | sayurc | (~sayurc@169.150.203.34) sayurc |
2024-12-24 16:52:50 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
2024-12-24 16:48:20 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
2024-12-24 16:45:58 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
2024-12-24 16:40:07 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
2024-12-24 16:35:46 +0100 | xff0x | (~xff0x@p3704193-ipxg12201sapodori.hokkaido.ocn.ne.jp) (Ping timeout: 265 seconds) |
2024-12-24 16:35:07 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
2024-12-24 16:33:15 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
2024-12-24 16:30:32 +0100 | <hseg> | should I perhaps post this to the cabal-install github? |
2024-12-24 16:29:48 +0100 | <int-e> | I can live with a breaking change that only affects a few packages (using those Path modules is not too common) |
2024-12-24 16:29:01 +0100 | <int-e> | Anyway, the real issue I have is that there's no way I can see to *express* that Cabal-3.14 is unfit for building that package. |
2024-12-24 16:28:30 +0100 | <int-e> | So if a generated file isn't backwards compatible... that's very murky. |
2024-12-24 16:28:03 +0100 | <int-e> | Yes but my understanding is that the build tool semantics are not supposed to change either. |
2024-12-24 16:26:43 +0100 | <hseg> | not of the build tool |
2024-12-24 16:26:39 +0100 | <hseg> | note that cabal-version is the version of the .cabal format |
2024-12-24 16:25:45 +0100 | Natch | (~natch@c-92-34-7-158.bbcust.telenor.se) (Ping timeout: 252 seconds) |
2024-12-24 16:25:14 +0100 | <int-e> | Oh I hate the fact that DDG found docs for version 3.4. |
2024-12-24 16:24:39 +0100 | <int-e> | I guess 3.14 should conservatively refuse to work with any package that doesn't specify cabal-version: 3.14 or later? ("refuse" - it can still build Setup executable with an older Cabal version) |
2024-12-24 16:22:15 +0100 | <int-e> | https://cabal.readthedocs.io/en/3.4/cabal-package.html#pkg-field-cabal-version ...okay I'm confused. There used to be a lower bound syntax here but that's discontinued. |
2024-12-24 16:22:06 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
2024-12-24 16:21:29 +0100 | <int-e> | hrm |
2024-12-24 16:20:47 +0100 | <hseg> | indeed, https://hackage.haskell.org/package/chs-cabal-0.1.1.2/revisions/ seems to have deliberately introduced that upper bound? |
2024-12-24 16:19:28 +0100 | <hseg> | https://hackage.haskell.org/package/chs-cabal-0.1.1.2/src/chs-cabal.cabal sets cabal-version to 1.18, so I don't _think_ that's the right place to blame? |
2024-12-24 16:17:52 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
2024-12-24 16:16:51 +0100 | <int-e> | there's a 0.1.1.4 that works with Cabal-3.14? |
2024-12-24 16:16:05 +0100 | <int-e> | well, for 0.1.1.2 at least |
2024-12-24 16:15:25 +0100 | <int-e> | I think what chs-cabal needs is an upper bound on its cabal-version field |
2024-12-24 16:09:11 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds) |
2024-12-24 16:07:19 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 264 seconds) |
2024-12-24 16:06:00 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
2024-12-24 16:05:10 +0100 | ubert | (~Thunderbi@p200300ecdf117cf78af43359d271b243.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
2024-12-24 16:04:24 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 264 seconds) |
2024-12-24 16:02:30 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
2024-12-24 16:02:02 +0100 | <hseg> | ahh -- the problem is the version of the cabal-install package these are built with, I think |
2024-12-24 15:57:43 +0100 | <hseg> | hrm. it seems all the builds build Cabal-3.10.3.0, but windows/nonwindows differ on which newer cabal to build in addition -- 3.12.1.0 (windows, which works) or 3.14.0.0 (nonwindows, which breaks) |
2024-12-24 15:56:28 +0100 | youthlic | (~Thunderbi@user/youthlic) youthlic |
2024-12-24 15:56:21 +0100 | <hseg> | it also builds Cabal-3.10.3.0 |
2024-12-24 15:56:09 +0100 | <hseg> | .. actually, I see multiple Cabals there? |
2024-12-24 15:55:39 +0100 | <hseg> | ah, I see - for some reason, cabal there decided to build with Cabal-3.12.1.0 |
2024-12-24 15:54:33 +0100 | <hseg> | also, why would this not cause trouble with windows? |
2024-12-24 15:53:24 +0100 | tomboy64 | (~tomboy64@user/tomboy64) tomboy64 |
2024-12-24 15:53:19 +0100 | <hseg> | hrm. who should I prod about this? |
2024-12-24 15:52:45 +0100 | tomboy64 | (~tomboy64@user/tomboy64) (Ping timeout: 260 seconds) |
2024-12-24 15:52:35 +0100 | <int-e> | My reasoning is very much guided by actually having that error. |
2024-12-24 15:52:12 +0100 | <int-e> | IIUC |
2024-12-24 15:51:47 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds) |
2024-12-24 15:51:21 +0100 | <int-e> | And that generates a somethingPathsomething file that use that new SymbolicPath abstraction. |
2024-12-24 15:50:06 +0100 | <int-e> | but (evidently) that still doesn't prevent building Setup.{l}hs with Cabal>=3.14 |