Newest at the top
2025-01-08 17:41:24 +0100 | saulosilva | (~saulosilv@181.216.220.21) (Quit: Client closed) |
2025-01-08 17:41:04 +0100 | <merijn> | ah, no I'm misremebering it seems, it's from 2018 |
2025-01-08 17:40:05 +0100 | <merijn> | sm: So that should be MORE than old enough to require ;) |
2025-01-08 17:39:36 +0100 | <merijn> | 2.4 is the version I used at the start of my phd in 2014 |
2025-01-08 17:39:24 +0100 | <merijn> | anyway, cabal 2.2 is over a decade old, so :p |
2025-01-08 17:38:06 +0100 | <merijn> | sm: At any rate, the core idea is that the semantics of a field will never change for a specific cabal-version, so even if field "foo" changes behaviour in a later version of the spec, any file declaring version X will always use the semantics of 'foo' at time X |
2025-01-08 17:36:52 +0100 | <merijn> | ah, right |
2025-01-08 17:36:43 +0100 | <tomsmeding> | ah |
2025-01-08 17:36:29 +0100 | <tomsmeding> | merijn: the Note here seems to give more certainty https://cabal.readthedocs.io/en/stable/file-format-changelog.html#spec-history |
2025-01-08 17:36:27 +0100 | <merijn> | tomsmeding: In general there's no real reason the spec and cabal-install versions should correspond (they always have and do at the moment, but there's no specific reason) |
2025-01-08 17:35:48 +0100 | <merijn> | tomsmeding: I'm not 100% it's guaranteed |
2025-01-08 17:35:40 +0100 | <tomsmeding> | merijn: "generally"? |
2025-01-08 17:35:22 +0100 | <merijn> | sm: to add onto tomsmeding answer, cabal-version refers to the cabal *spec* i.e. supported features, (generally equal to "the earliest cabal version that supports it") |
2025-01-08 17:34:06 +0100 | merijn | (~merijn@77.242.116.146) merijn |
2025-01-08 17:34:02 +0100 | <hseg> | I thought https://reuse.software might have something, but apparently not |
2025-01-08 17:32:51 +0100 | target_i | (~target_i@user/target-i/x-6023099) target_i |
2025-01-08 17:30:44 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 264 seconds) |
2025-01-08 17:27:30 +0100 | <__monty__> | Maybe it's worth looking into some of the reproducible builds stuff? SALSA and the like? They tend to care about source provenance and licensing is part of that so maybe they have tools that make this easy. |
2025-01-08 17:25:25 +0100 | saulosilva | (~saulosilv@181.216.220.21) saulosilva |
2025-01-08 17:25:15 +0100 | <hseg> | then all would need to be copied, presumably |
2025-01-08 17:24:00 +0100 | <__monty__> | What if the PKG lists multiple license-files? |
2025-01-08 17:23:49 +0100 | merijn | (~merijn@77.242.116.146) merijn |
2025-01-08 17:23:36 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
2025-01-08 17:23:04 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
2025-01-08 17:17:19 +0100 | jespada | (~jespada@2800:a4:113:8c00:655c:4889:ada3:2b47) jespada |
2025-01-08 17:14:20 +0100 | Square2 | (~Square@user/square) Square |
2025-01-08 17:14:01 +0100 | rachelambda8 | (~rachelamb@cust-95-80-25-71.csbnet.se) |
2025-01-08 17:13:20 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
2025-01-08 17:13:03 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
2025-01-08 17:12:46 +0100 | jespada | (~jespada@2800:a4:f9:a300:c8c1:20a5:1a94:f1) (Ping timeout: 244 seconds) |
2025-01-08 17:11:18 +0100 | <hseg> | so in theory, cabal-plan's report could copy them into the license directory |
2025-01-08 17:10:59 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 260 seconds) |
2025-01-08 17:09:54 +0100 | <hseg> | hm, actually just realized the licenses appear under ~/.cabal/store/$HC/$PKG/share/doc/LICENSE |
2025-01-08 17:04:23 +0100 | <tomsmeding> | nice |
2025-01-08 17:03:44 +0100 | alecs | (~alecs@nat16.software.imdea.org) (Ping timeout: 264 seconds) |
2025-01-08 17:02:39 +0100 | <hseg> | yay! |
2025-01-08 17:02:38 +0100 | sm | didn't want to assume |
2025-01-08 17:02:27 +0100 | <tomsmeding> | which is consistent with the `cabal-version: 2.2` note and the fact that the two are synchronised |
2025-01-08 17:02:09 +0100 | <sm> | yup, thanks |
2025-01-08 17:02:02 +0100 | <sm> | it became supported in https://github.com/haskell/cabal/blob/master/Cabal/ChangeLog.md#2200-mikhail-glushenkov-march-2018 I think |
2025-01-08 17:02:00 +0100 | <tomsmeding> | looks like 2.2 and onwards? |
2025-01-08 17:01:26 +0100 | <hseg> | https://0x0.st/8-sC.txt is the list of tags containing that commit |
2025-01-08 17:00:59 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
2025-01-08 17:00:56 +0100 | <tomsmeding> | https://cabal.readthedocs.io/en/stable/file-format-changelog.html#spec-history |
2025-01-08 17:00:54 +0100 | <hseg> | The earliest commit I see in the cabal repo mentioning SPDX is 3dfc0ea466d254fcefb3826d6f15cda30d95cc0a |
2025-01-08 17:00:54 +0100 | <tomsmeding> | > The sequence of specification version numbers is not contiguous because it’s synchronised with the version of the Cabal library. |
2025-01-08 17:00:50 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
2025-01-08 17:00:38 +0100 | <tomsmeding> | naturally :) |
2025-01-08 16:59:56 +0100 | <sm> | nobody puts those in their docs :) |
2025-01-08 16:59:40 +0100 | <sm> | next I hunt for cabal-version release dates |