Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

zlib-0.7.0.0 #7309

Closed
9 of 13 tasks
alaendle opened this issue Feb 8, 2024 · 17 comments
Closed
9 of 13 tasks

zlib-0.7.0.0 #7309

alaendle opened this issue Feb 8, 2024 · 17 comments

Comments

@alaendle
Copy link
Member

alaendle commented Feb 8, 2024

zlib-0.7.0.0 (changelog) (Grandfathered dependencies) is out of bounds for:

I'll add a constraint to zlib for now.

alaendle added a commit that referenced this issue Feb 8, 2024
@andreasabel
Copy link
Contributor

Fixed for Agda and hackage-cli.

@RyanGlScott
Copy link
Contributor

I've applied a Hackage revision to hyphenation-0.8.2.

@andreasabel
Copy link
Contributor

Fixed for hackage-security.

@jappeace
Copy link
Contributor

fixed for keter by version bump

@jgm
Copy link
Contributor

jgm commented Feb 17, 2024

fixed in pandoc 3.1.12

@mbg
Copy link
Contributor

mbg commented Mar 2, 2024

Fixed for wai-saml2 with a metadata revision

@andreasabel
Copy link
Contributor

JuicyPixels fixed by revision:

@mihaimaruseac
Copy link
Contributor

Current state is

zlib-0.7.0.0 (changelog) (Grandfathered dependencies) is out of bounds for:

  • cborg-json-0.2.6.0 (>=0.5 && < 0.7). Ben Gamari [email protected] @bgamari. Used by: benchmark
  • io-streams-1.5.2.2 (>=0.5 && < 0.7). Gregory Collins [email protected] @gregorycollins. Used by: test-suite
  • serialise-0.2.6.1 (>=0.5 && < 0.7). Grandfathered dependencies. Used by: benchmark
  • snap-core-1.0.5.1 (>=0.5 && < 0.7). Grandfathered dependencies. Used by: test-suite

I think we might just disable tests and benchmarks for these packages and enable zlib. Will give it a try later

@andreasabel
Copy link
Contributor

io-streams fixed by revision

@andreasabel
Copy link
Contributor

snap-core fixed by revision

@andreasabel
Copy link
Contributor

Remaining serialise and cborg-json fixed by revision

@mihaimaruseac
Copy link
Contributor

Thank you. This is now fixed.

@andreasabel
Copy link
Contributor

Great @mihaimaruseac !

I see that is a lot of back-and-forth on master:
70f04a9 (HEAD -> master, origin/master) Temporarily allow back testing on aeson-schemas
117774d Remove zlib bound and fix #7309
f41163e Rvert
fb9a20b Try zlib agian
944dfac Revert to green
82c1389 Try zlib bound removal again
632a078 Add new package hs-captcha (#7374)
e113fd6 remove stale comments
b2c4199 Drop broken, stale package
547489a Expect test failure for aeson-schemas (#7376)
1283f46 Drop chronos-bench (#7375)
1f031a1 Restore to green
1f59606 Last test for upper bounds
fb3c7a7 Remove bound on scotty and fix #7345
e4bc5ef Yet one more try
55845bd Yet more try
0bc26d9 One more try again
1dca371 Try again
d351c2f Try agian
6867303 Remove bounds on ansi-terminal, fix #7306
629a7b9 Remove bounds on ansi-terminal

Is this a limitation of the tools? Otherwise, maybe one would only push successful updates to master...

@mihaimaruseac
Copy link
Contributor

It's a mix of both. We can run the tooling locally, but for my system it takes too long. I switched on testing on the CI :)

For build errors, we need to test on the build system, it is too expensive to build everything locally

@andreasabel
Copy link
Contributor

I switched on testing on the CI :)

When it comes to running check on CI, one could add some dedicated branches to the triggers, like ci-*:

name: check
on:
push:
branches: [ master ]
pull_request:
branches: [ master ]

I did so for my projects (before I switched to an "Always PR" policy for simplicity).

For build errors, we need to test on the build system,

I see. How does this work? Does the build system pull master from here?

@mpilgrem
Copy link
Member

mpilgrem commented Apr 20, 2024

EDIT: I am going to re-raise the following as a separate issue, as I think pkg-config now being a de facto prerequisite to use Stackage with Stack (given the number of packages that depend on zlib) is a fundamental one.

I understand that Stack can only build zlib-0.7 with its default Cabal flags (specifically, pkg-config defaulting as true) if executable pkg-config is on the PATH. If zlib-0.7 is included in package sets without setting --flag zlib:-pkg-config should Stackage document that pkg-config is a prerequisite to use its package sets?

@andreasabel
Copy link
Contributor

I am going to re-raise the following as a separate issue,

That would be:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants