Here’s the current pkg-build status for the upcoming release:

worse
  #hash(("msgpack" . (success build-fail))
        ("turnstile" . (success test-fail))
        ("nvim-client" . (test-fail build-fail))
        ("deferred" . (success test-fail)))
  better
  #hash(("fixture" . (build-fail success))
        ("asyncunit" . (test-fail success))
        ("disposable-test" . (build-fail no-docs)))

msgpack is a TR issue caused by fixes to contract generation (cc @ben @pnwamk)

nvim-client is failing because of msgpack

turnstile is a timeout that happens on the NWU machine but not the Utah machine

deferred has a non-deterministic test failure

where does one see the build results w/ the failing packages?

@samth: Isn’t there already #release-management for that kind of discussion?

@stamourv #release-management is a private channel

Also, thanks for looking into that. We’ll want to re-run that closer to testing.

Should it be?

@pnwamk https://plt.eecs.northwestern.edu/pkg-build/

thanks

@stamourv rather than having a discussion about making it public, I just created this

Fair. That would likely be a tedious discussion.

ok that’s my bug. Because of changing or/c

there’s a function with type (-> InputPort (Rec T (U Bytes (Vectorof T))) that can’t be used in untyped code right now

(oops or/sc) I think because the optimizer used to reduce that to (-> input-port? any/c)

I’m trying to understand why TR expects a flat contract here … seems like it should be ok to put the contract (-> input-port? (or/c (vectorof ....) ....)) on an exported function

That is indeed wrong, but why doesn’t the contract work now?

maybe or/sc is expecting its parts to instantiate to flat contracts?

ok I did a bad job explaining the problem, the type had more cases than (U Bytes (Vector ....) ....), and the real problem was with hashtables

and it looks like this is a bug in msgpack … 1 sec & I’ll send 2 pasteracks

1. this program runs on 6.10.1 http://pasterack.org/pastes/46087
2. this similar program errors on 6.10.1 http://pasterack.org/pastes/70766

the error is right because hashtable keys can’t be mutable vectors

but or/sc was hiding the error

I don’t understand

hashtable keys can certainly be mutable vectors

Can you open a bug about this?

with your current understanding of the issue

is it a hasheq thing?

(the reason why hash wants flat key contracts)

Yes