| 22 May 2021 |
|  andi- set a profile picture. | 13:34:06 |
|  dualinverter joined the room. | 16:11:32 |
|  pwmosquito joined the room. | 16:22:04 |
 John Ericson | sterni: hmm ok | 17:06:26 |
| John Ericson | i just assumed there was some issue with glibc static | 17:06:37 |
| John Ericson | but would be cool if there wasn't | 17:06:43 |
 sterni (he/him) | from reading the code I got the impression that at the time there was no glibc.static and it wasn't changed since then, but I could be wrong | 17:31:02 |
| sterni (he/him) | pennae: with -j1 tests no longer fail, so seems to be indeed a race condition | 18:41:19 |
 pennae | good to know :< | 18:46:12 |
| sterni (he/him) | upstream knows™ now | 18:48:24 |
| pennae | heh, SEP :D | 18:48:36 |
| sterni (he/him) | also I really have to add a proper way to pass flags to the test invocation | 18:48:37 |
| sterni (he/him) | the testTarget trick I have been doing is something to be ashamed of | 18:49:01 |
| * pennae check what that could be | 18:50:36 |
| pennae | .. eh, could be worse | 18:51:38 |
| sterni (he/him) | it's just a bit annoying ideally we wann just reuse mkDerivation's checkFlags, but we already have it called testTarget | 18:52:36 |
 maralorn | sterni: cdepillabout: I am wondering how we should go about problems were people fix stuff upstream and then we have to decide if we workaround it or bump our hackage snapshot to fix our build error. I wish there was a solution to somehow bump only this one package … | 18:55:42 |
| sterni (he/him) | this is the moment where I go I told you so right? :p | 18:56:07 |
| sterni (he/him) | it's a bit unfortunate, but I think we may also get away with bumping the hackage pin as well | 18:56:26 |
| sterni (he/him) | other than that we can just use overrideSrc in this case I'm pretty sure | 18:56:53 |
| sterni (he/him) | I checked earlier doing a bump of hackage only has a sizeable diff, but it's hard to say if it'd break anything ofc | 18:57:24 |
| maralorn | The question is if we could (and want) introduce a distinction between the hackage-snapshot used for generation and the hackage-snapshot used for taking prefered-versions. | 18:59:02 |
| maralorn | Oh, actually. No that I phrase it that way, I don‘t think it would be that hard. | 18:59:40 |
| sterni (he/him) | we could probably do the same thing as for stackage and just generate a list of all the versions from the snapshot | 18:59:46 |
| maralorn | But it certainly comes with a complexity cost. | 18:59:54 |
| sterni (he/him) | then we could update the snapshot independently of that without regenerating the lsit | 19:00:02 |
| maralorn | In reply to @sternenseemann:systemli.org
we could probably do the same thing as for stackage and just generate a list of all the versions from the snapshot That will generate a lot of additional noise in the git-repo. | 19:00:26 |
| sterni (he/him) | I also wonder if there would be any performance cost on hackage2nix | 19:00:27 |
| maralorn | sterni: The update-hackage script passes the hackage version and the preferred-versions separately to hackage2nix. So it would be pretty easy to give it different preferred versions. | 19:02:40 |
| sterni (he/him) | oh right forgot that was a thing | 19:05:25 |
