| 25 Apr 2026 |
|  @axeman:pub.solar left the room. | 09:04:52 |
 eldritchcookie | I would assume the package gets into haskell-updates in the next time they regenerate hackage-packages.nix. The HACKING.md says that each member is responsible for updating the packages for a 2 week period, i assume they must always do something in that period so they probably run the scripts at least once.
Assuming they always run the scripts mentioned under the second header the scripts are ran at least once per 2 weeks, further assuming no unexpected we can expect it to take at most 2 weeks for an update. these are just assumptions based on the current documentation please have a backup plan in case it takes longer.
Also why is that relevant? can you apply an overlay to the package set you use? if yes i wouldn't wait and just use callHackageDirect via the self argument of the overlay | 14:50:30 |
| eldritchcookie | # callHackageDirect
# :: { pkg :: Text, ver :: Text, sha256 :: Text }
# -> AttrSet
# -> HaskellPackage
#
# This function does not depend on all-cabal-hashes and therefore will work
# for any version that has been released on hackage as opposed to only
# versions released before whatever version of all-cabal-hashes you happen
# to be currently using.
callHackageDirect =
{
pkg,
ver,
sha256,
candidate ? false,
rev ? {
revision = null;
sha256 = null;
},
}:
args:
<body>
| 14:55:49 |
 alexfmpe | pretty much this, though the 2 weeks is more of a rough estimate for maintainer rotation of that duty | 15:25:11 |
| alexfmpe | most of the time we bump hackage alonside a minor stackage bump | 15:25:47 |
| alexfmpe | "Current PR:" in the channel description will show the state of current bump, so you can guesstimate (2 weeks - age) for the next | 15:26:29 |
| alexfmpe | in pratice it varies wildly depending on breakage, some have taken days, some have taken several weeks | 15:26:47 |
| alexfmpe | and major stackage bumps can take months until merged | 15:27:05 |
| 26 Apr 2026 |
 aiya | "why is it relevant?" if by "it" you mean my entire question, it's cause i'm trying to fix a broken package that was fixed upstream and am deciding whether it's worth it to fix in nixpkgs. if you mean just the not on stackage part, idk i thought it might've been relevant | 00:10:34 |
| alexfmpe | https://github.com/NixOS/nixpkgs/issues/130556 | 00:32:40 |
| alexfmpe | cabal v1-build and cabal v1-test workarounds seem to work on your repo | 00:33:08 |
| eldritchcookie | can cabal v1-build build only some select components? i would ideally have a method that works with multiple public libraries | 12:53:29 |
 andromeda | I am building a package with pkgs.haskellPackages.callCabal2nix. I assume it doesn't have the capability to fetch+build source-repository-package es in cabal.project? | 13:25:26 |
| andromeda | * I am building a package with pkgs.haskellPackages.callCabal2nix. I assume it doesn't have the capability to fetch+build source-repository-packages in cabal.project? | 13:25:34 |
| alexfmpe | callCabal2nix ignores cabal.project | 14:11:22 |
| alexfmpe | so you'd need to either duplicate that override, or maybe do something like a git submodule to keep single source of truth (never tried the later method) | 14:12:08 |
| alexfmpe | hackage.nix lets you take cabal.project into account, and also use the solver, but it's an entirely different beast | 14:12:32 |
| alexfmpe | a more heavy handed workaround mentioned in there involves a flag to decide whether to specify build-tool-depends so you can skip it when using shellFor and let cabal get it from path there | 14:15:14 |
| alexfmpe | nix-build worked for me on your repo, it's the integration between shellFor and cabal-install where things go wrong | 14:15:49 |
| andromeda | In reply to @alexfmpe:matrix.org
hackage.nix lets you take cabal.project into account, and also use the solver, but it's an entirely different beast what makes that an entirely different beast? | 14:17:44 |
| alexfmpe | https://input-output-hk.github.io/haskell.nix/motivation.html#comparison-with-nixpkgs | 14:18:25 |
| alexfmpe | that's somewhat outdated, it's not necessarily better for cross, but the rest stands | 14:19:00 |
| andromeda | that... seems like overkill. I'mma go with keeping the cabal.project in sync enough with the flake. | 14:21:01 |
 sterni | cabal-install v2 commands expect build-tool-depends to be registered in the package db which Nix environments don't do because it is wrong from the perspective of the dependency separation: build tools go to nativeBuildInputs and not into (propagated)BuildInputs. Only the latter get folded into the package db. There is an open issue about this. Only affects developer environments.
Easiest workaround is to use the cabal-install v1 commands which check PATH for tools as well. | 14:33:49 |
| sterni | ah alex already answered, nvm. | 14:34:29 |
| sterni | aiya: I bumped Hackage two days ago, you can follow the progress there: https://github.com/NixOS/nixpkgs/pull/510883. Giving a timeline is hard, but the answer is weeks unfortunately at the moment. | 14:36:14 |
| aiya | sterni i see, so maybe it is worth fixing, could you please elaborate on your latest comment here (https://github.com/NixOS/nixpkgs/pull/506489#discussion_r3110806985)? apologies, i don't fully understand it | 20:02:42 |
| 27 Apr 2026 |
|  👿👿👿M̸̙̜̔̇Ǎ̴͎̙͔G̸̞̈N̸͔͍̝͗͋̾Ő̷͖̼͈̽̚L̷̻͚̓̔I̷̛͔̰̟̔Å̴̩̍ ̷̦̒̇͝M̷̱̠̺̉̎A̵̼̎͗͘Ỹ̸̬̲͂̕H̷̙̖͂Ē̷͉̦̌͒M̶͈̥̽̐ 👹👹👹👹😈😈😈 changed their display name from M̸̙̜̔̇Ǎ̴͎̙͔G̸̞̈N̸͔͍̝͗͋̾Ő̷͖̼͈̽̚L̷̻͚̓̔I̷̛͔̰̟̔Å̴̩̍ ̷̦̒̇͝M̷̱̠̺̉̎A̵̼̎͗͘Ỹ̸̬̲͂̕H̷̙̖͂Ē̷͉̦̌͒M̶͈̥̽̐ Houston, we've had a Microsoft to M̸̙̜̔̇Ǎ̴͎̙͔G̸̞̈N̸͔͍̝͗͋̾Ő̷͖̼͈̽̚L̷̻͚̓̔I̷̛͔̰̟̔Å̴̩̍ ̷̦̒̇͝M̷̱̠̺̉̎A̵̼̎͗͘Ỹ̸̬̲͂̕H̷̙̖͂Ē̷͉̦̌͒M̶͈̥̽̐. | 00:11:10 |
| 👿👿👿M̸̙̜̔̇Ǎ̴͎̙͔G̸̞̈N̸͔͍̝͗͋̾Ő̷͖̼͈̽̚L̷̻͚̓̔I̷̛͔̰̟̔Å̴̩̍ ̷̦̒̇͝M̷̱̠̺̉̎A̵̼̎͗͘Ỹ̸̬̲͂̕H̷̙̖͂Ē̷͉̦̌͒M̶͈̥̽̐ 👹👹👹👹😈😈😈 changed their display name from M̸̙̜̔̇Ǎ̴͎̙͔G̸̞̈N̸͔͍̝͗͋̾Ő̷͖̼͈̽̚L̷̻͚̓̔I̷̛͔̰̟̔Å̴̩̍ ̷̦̒̇͝M̷̱̠̺̉̎A̵̼̎͗͘Ỹ̸̬̲͂̕H̷̙̖͂Ē̷͉̦̌͒M̶͈̥̽̐ to 👿👿👿M̸̙̜̔̇Ǎ̴͎̙͔G̸̞̈N̸͔͍̝͗͋̾Ő̷͖̼͈̽̚L̷̻͚̓̔I̷̛͔̰̟̔Å̴̩̍ ̷̦̒̇͝M̷̱̠̺̉̎A̵̼̎͗͘Ỹ̸̬̲͂̕H̷̙̖͂Ē̷͉̦̌͒M̶͈̥̽̐ 👹👹👹👹😈😈😈. | 00:12:37 |
|  @psy1ynce:matrix.org left the room. | 01:34:06 |
