DrRacket refrains from applying errortrace to anything that’s from the main “collects” or from packages that you’re not editing. There are many reasons for that rule, among them that DrRacket cannot in general write to “compiled” directories in those places.

It’s true that I never got around to adding it to pkgs, and I should do that. I think the “distro-build” collection is as intended, though.

If it’s in that collection, then the checklist instruction is wrong

Or maybe the instructions expect a particular current directory?

I don’t see any particular problem, either

I’ve pushed repairs, where the two expanders had different bugs, but the same underlying cause that I hadn’t considered the possibility of internal-definition contexts for 'module-begin mode. I wouldn’t be surprised if you run into further problems, especially with the old expander.

The checklist was wrong; now fixed

I didn’t notice because I do always run the test from its directory

@mflatt Thank you for both of those fixes, though I think ultimately I can get away with neither of them, since the strategy of just using unique, global scopes for namespacing eliminates my need for splicing-syntax-parameterize. (Which almost seems disappointing, since it was a fun use-case, but this approach works a lot better.)

@greg This test continues to be somewhat flaky http://drdr.racket-lang.org/43204/racket/share/pkgs/http/http/request.rkt ; would it make sense to add more retries?

@samth Although I’ve only glanced at it I think @jeapostrophe’s PR from this morning will do that: https://github.com/greghendershott/http/pull/10

That URL definitely responds for me

what if the catalog test runner gave tests the ability to run docker containers? You could make a non-flaky http test suite with that

the issue here is the CI server at http://drdr.racket-lang.org\|drdr.racket-lang.org, which doesn’t have the restrictions that the pkg-build system does

but does apparently have periodic issues reaching http://yahoo.com\|yahoo.com

bizarre

and it’s really genuinely just http://yahoo.com\|yahoo.com, as you can see at that link (click the green back button a bunch of times to see various issues)

the drdr links aren’t working for me

not able to connect

http://downforeveryoneorjustme.com/drdr.racket-lang.org

it works for me

….oh I have https everywhere set to block non-https connections because I was using public wifi hotspots…

it’s yahoo closing the tcp connection so I don’t think there’s much you can do there

yeah but it usually works so i think just retrying a few times should fix it

How often does that test run?

about once an hour

the CI server just runs continously

(it used to be triggered by pushes but we gave up on that when we split the main repo)

gotcha

the main http://drdr.racket-lang.org\|drdr.racket-lang.org page shows the history of all builds

how different are drdr and the package build server?

quite

drdr is intended to be a highly comprehensive test of the main distribution

for example, it builds from source every time, runs tests that need a gui or arbitrary system access or the network, and tests every file in every package in main-distribution and main-distribution-test, and doesn’t have an overall time limit

but it doesn’t build anything that’s not in the main-distribution or needed by it

interesting

gui bits tested with xvfb?

oh by the way @samth, could you add a license to samth/docker-racket-build?

done

perfect, thanks

actually, i want to add the other license too

other license?

apache as well

oh, dual licensing it?

you’re probably better off using just apache instead of using dual licenses

licenses don’t compose as neatly as functions do unfortunately

We’re dual-licensing Racket generally as MIT and Apache, for roughly the same reasons that Rust does

so I want to do the same thing here

oh rust does that? neat

yes

ah, I gotcha, dual licensing means that pull request authors implicitly agree to both

yeah

that’s why I wanted to do it now before you do anything that might get you in trouble with Google Legal

oh, and it actually runs a real X server, not xvfb

good call on license thing then - relicensing stuff that’s partially copyright google would be… not simple, probably

as for real X server: why?

not certain, @jeapostrophe would know better

oh and, how are snapshot and pre-release installers made?

those are built with the distro-build package

do you want the dockerfile to only describe how to build stuff in terms of what’s at http://pre-release.racket-lang.org\|pre-release.racket-lang.org or do you want it to conceivably work in racket CI before those are uploaded anywhere?

mostly the former

the goal is to automate the process when @stamourv sends out an email telling people to do testing items that are on their checklist

current checklist here: https://github.com/racket/racket/wiki/Release-Checklist

and I presume the way that’s done is people take the pre-release installer and install racket with it, then run those tests?

yes

and so this is just automating that process in a nice reproducible way

kk

then I think ill file some issues about stuff we could do

there’s an issue filed already for all the things that don’t work (which may be harder to fix for you), plus a couple of issues about the Docker code

based on what you suggested yesterday

@samth filed issues for all the stuff I could think of off the top of my head