| 22 Apr 2025 |
 alexfmpe | then hopefully convert other clans to use us as source of truth and become maintainers here rather than there | 14:45:52 |
| alexfmpe | * I just think the whole 'actually run tests and patch things if maintainer checks out' is fundamentally inevitable, so we might as well enshrine that approach
EDIT: me wrong. Stackage does run (native) test suites, they just don't patch stuff | 14:49:09 |
 hellwolf | is such a bot considered:
- extract the list of haskell packages that has patchhes in nixpkgs
- goes to repo of these packages and open/maintain one issue to inform the package owner?
| 18:41:15 |
 Alyssa Ross | That sounds like the sort of thing some maintainers would consider to be spam and damage our reputation, at least without a manual approval step but possibly even with. | 18:43:35 |
| hellwolf | Hmm, could be too enthusiastic behaviour indeed. But perhaps a centralised place first, and opt-in for notifications | 18:45:12 |
 sterni (he/him) | the issue is decidedly not that maintainers don't know about stuff it's more like they don't read their emails or have other things to do | 23:04:25 |
| sterni (he/him) | another thing I want to add is that these different systems (Stackage, Nixpkgs, Horizon Haskell, head.hackage, …) exist to address different requirements and I think streamlining this is more of a theoretical possibility. I mean why do we package software if Debian has already done it? | 23:08:22 |
| sterni (he/him) | e.g. Stackage does not need to care if the latest version of pandoc is not in their stackage lts solver. It doesn't matter to them when they have to drop a package many people use because they can just use an older solver with basically no drawbacks etc. | 23:09:30 |
| 23 Apr 2025 |
|  @malteneuss:matrix.org left the room. | 08:24:20 |
 Teo (he/him) | You should always have a manual step where you check for existing PRs/issues that do the same thing. Also some maintainers don't want PRs and prefer issues for package bumps. It's tough to automate these things. In terms of automatic notifications, that's what stackage and hackage do already | 09:56:18 |
| hellwolf | I agree. It must be opt-in only. I receive often from GitHub PRs, but I can always opt-out | 10:32:40 |
 maralorn | alexfmpe: Huh. Merging the .jsexe PR into staging has the annoying effect that it will now take a while until it reaches haskell-updates … | 11:25:16 |
| alexfmpe | I mean we can cherry pick | 11:26:26 |
| maralorn | As you wish. I guess I am right now not affected by it. | 11:34:37 |
| alexfmpe | Me neither | 11:46:15 |
| alexfmpe | Getting it mainlined and cached removes the main obstacle | 11:47:03 |
| alexfmpe | By the time anyone is using it and wants to upstream some override we'd probably have it merged into haskell-updates | 11:47:41 |
| sterni (he/him) | Just cherry pick I have a feeling we may doing that a fair bit for 24.11 stuff | 11:54:52 |
| maralorn | 24.11? | 12:33:40 |
| 24 Apr 2025 |
|  @jktr:0x16.de left the room. | 01:16:55 |
|  Leon Vatthauer set a profile picture. | 12:50:31 |
|  Peter Dragos joined the room. | 14:13:49 |
| Peter Dragos | Hey folks, I'm working on getting haskellPackages.accelerate building. I've gotten it building locally against 24.11.
I'd like to make a PR for nixpkgs, so I've checked out nixpkgs/haskell-updates and am editing common-configuration.nix with
accelerate = overrideSrc {
src = pkgs.fetchFromGitHub {
owner = "AccelerateHS";
repo = "accelerate";
rev = "3f681a5091eddf5a3b97f4cd0de32adc830e1117";
sha256 = "sha256-tCcl7wAls+5cBSrqbxfEAJngbV43OJcLJdaC4qqkBxc=";
};
} super.accelerate;
But when I do this, I get
double-conversion >=2.0, formatting >=7.0, microlens >=0.4
if I go into the nix repl, :lf, and inspect nix-repl> legacyPackages.x86_64-linux.haskellPackages.microlens.version I get "0.4.13.1" which should be compatible; and this is the same for double-conversion and formatting as well. Do I need to do something different to get the dependencies picked up properly?
| 14:14:29 |
|  TuXic joined the room. | 14:21:59 |
| maralorn | Peter Dragos: Its likely that those dependencies were not present in the version of accelerate which is in that nixpkgs checkout. You are reusing the derivation for another version of the package there, just swapping the src. | 14:37:35 |
| maralorn | Is there no newer release of accelerate? | 14:38:10 |
| maralorn | A possible solution is to manually add the missing dependencies with further overrides on the package. | 14:39:43 |
| Peter Dragos | I far as I can tell, the latest version of accelerate on hackage has the same base constraints | 14:43:58 |
| Peter Dragos | I'll give this a shot, thanks | 14:44:06 |
| maralorn | Why are you mentioning base constraints? They don’t appear in your error message. | 14:44:58 |
