Update to lts-24.29.

[alaendle]

I'm still in progress of testing this on my laptop - unfortunately this takes days (and is still running) for the build-up of the postgres-DB and I couldn't test if this integrates with our existing database or S3.

So maybe I should limit the build-up to only scan the latest major LTS releases + nightlies from 2026 locally.

However, could you provide a read-only S3 credentials on a private channel, so that I can check if this integration works still well? I wouldn't expect any problems, but you never know.

So while this might be a more aggressive alternative to #358, I think we couldn't wait for this PR to be fully tested; nonetheless I add this as a draft PR so that everyone is aware, and could already view the changes.

[chreekat]

The amount of time it takes to build the database from scratch is a real bottleneck! I suspect it could be a lot faster, and having some kind of cutoff to make it even faster for CI would also be good.

Anyway I'll see what I can do about read-only credentials. It might take some time because I'm at FOSDEM and really slammed with other work anyway.

[alaendle]

Hurray, from my perspective this change works as expected; at least it can parse and display the results. Things I still want to do:

• Test S3 integration
• Look at the nix stuff - as far as I understood the server needs to build here - for now I directly build all the stuff via stack

[chreekat]

I've had success using localstack as a provider of a local S3 interface, if you want to try it out.

[alaendle]

Local S3 isn't my problem, I already running minio for simulation. But isn't the server only using the data from S3? So I thought it might be a better test to use the real data. Also I have no idea how I could fake/upload meaningful data to my local S3 service.

At the moment I'm looking at the nix integration; I try to use haskell.nix to avoid the need to synchronize nix expressions with stack.yaml - also if this makes things impure. At the moment I struggle with input-output-hk/haskell.nix#2423 (which is basically commercialhaskell/stackage#7847) - it's really a mess that GHC ships with a set of libraries that in combination don't compile with default flags - but that's another topic. If I succeed I will replace the nix-files with haskell.nix ones (only as a suggestion and to be able to discuss on code what should be improved).

[alaendle]

Okay, I now use haskell.nix, not sure if this integrates well with the rest of the nix-infrastructure for the server. I just find it lot easier to derive everything from the stack.yaml file, than to have to maintain every dependency as a nix-expression - but be aware that we are no longer "nix-pure" with this approach. However I have verified that everything seems to build and run well (e.g. by testing nix run .#stackage-server:exe:stackage-server).

From my point this PR would be ready for review and if agreed implementation. So please let me know if I could do further validation or if we need additional changes.

[chreekat]

Very cool. I never got haskell.nix to work for me, but if it makes it easier to sync the stack build and the nix (flake) output, I would take it. I was always unhappy that the Flake build and the Stack build were not synchronized.

I am not sure what you mean by "nix pure". Do you mean you have to break the Nix sandbox?

I have been at FOSDEM and then sick for the last week. I'll get to this as soon as I can.

[alaendle]

My knowledge of nix is ​​very superficial, so I may have chosen the wrong terms, but what I basically mean is that the execution can no longer be derived purely from nix expressions: https://nix.dev/manual/nix/2.26/language/import-from-derivation.
(as far as I've understand this was the case before, and this quality was lost - we want the build to depend on the contents of our stack project)

Your primary focus should be on getting completely healthy again.

Also, since we managed to get through the end of the month and the snapshots are being updated again, this isn't quite so urgent anymore.

I would still like to integrate this, though—it still carries a certain risk, as I haven't been able to test everything, but we would have a current basis for further changes or corrections.

[chreekat]

I am still interested in deriving everything from stack.yaml, but my heart tells me that haskell.nix is an additional complexity burden that I can't handle. If something stops working, I don't know who to turn to. It is more complex than I can deal with. At least with nixpkgs I feel like I have a small clue. So the situation sucks but I think I need to stick with my generated nix for now.

The good news is that I had the time to make the changes -- they are in #362 . I'm just going to add a nix flake check and cachix push to the pipeline, then go fix stackage.

P.S. while nix flake check works on this PR, it doesn't actually check what I check on master, and in fact I think the package would be broken (the equivalent check from master would fail).

I appreciate that you took the time to make this patch. Hopefully a better option will turn up some day.

[chreekat]

#362 is merged. I'll deploy it next and make sure stackage is functional again.