I want to merge https://github.com/coq/coq/pull/15560 today so we have time to fix any issues that occur and not do it when people are working during the week.
There are some issues standing however, such as with the jobs in the CI.
I see that performance tests takes around 00:23:58 before
Now it hit the limit, looks like it was restarted, let's see what is happening.
fiat-crypto was also taking 1:40
Logs for an old fiat-crypto job don't show COQNATIVE
But the new one does
https://gitlab.com/coq/coq/-/jobs/2636082744
I can't tell if this is because some hiding flags were tweaked
that big link doesn't work for me
https://gitlab.com/coq/coq/-/jobs/2636082744 is perf tests not fiat-crypto
Ali Caglayan said:
I want to merge https://github.com/coq/coq/pull/15560 today so we have time to fix any issues that occur and not do it when people are working during the week.
weird logic
if people aren't working who's finding issues?
My thinking is that if we merge this during next week, then many PRs will have to be rebased as people are working on them.
I don't understand
how does a couple days change the number of conflicting prs?
Isn't it better to merge ASAP to find issues ASAP?
If we merge next week, and there is a huge issue (not that I think there will be) suddenly everybody's CI doesn't work etc.
it should be merged when it's ready not based on trying to guess timing
If we merge today and find there is a huge issue, we have the whole weekend to fix it rather than trying to quickly fix it throughout the week
that means asking people to commit to working during the weekend
It is ready to be merged today, I am trying to let everybody know that I will do it
Do you think it should wait? If so why?
if there's a huge issue that CI didn't catch what makes you think you'll catch it before people work with the PR
Ali Caglayan said:
Do you think it should wait? If so why?
I don't know if it should wait, I just reject all reasoning talking about the weekend
The reason I bring up the weekend is because I have time to help fix things.
is it really ready? what about the CI issues?
Performance tests now passed
I've restarted fiat-crypto, if its done then good I will merge
The issue with coqbot on older branches may or may not be fixable, I will take a look now.
Not fixable is not an option. We are not just talking about breaking some very old branches. We are also talking about breaking the current 8.16.0 release.
I won't merge if coqbot is not fixable
Actually you know what. Merging coqbot after this PR seems super flaky to me. I think I will delay merging till next week.
I will try to make a backwards compatible coqbot patch today, and I can even deploy it to check it is working fine. Then both the CI for the new dune PR should be green and other PRs too.
OK I've made a patch to coqbot which I am currently deploying.
If it works for other PRs then I will create a PR for coqbot.
This will mean that coqbot will be able to handle before and after #15560.
A couple of things:
build:base
to build stdlib doc (as Coq coudln't built it from installed sources). Now that works, so we have two jobs as opposed to one before. That motivated me to go and update coqbot for this. But the big problem I see is that coq/bot is embedding configuration in its source code. It should not do that, otherwise indeed as branches evolves, it is a mess to keep up to date.coqbot needs to have a higher level understanding of the Github/GItlab API in order to be configurable. That way we can say "add a new CI job, point to this URL in a check, etc.".
This is not something that is easy to implement and will take some time to design.
For now, following the spaghetti and updating links now and then seems to work.
For now it works, but it is a bit time sink
I lost hours with that manual config setup
Let me know Ali when you want me to rebase the PR
You can rebase it now if you like
We can also start a bench
Fingers crossed tomorrow it is green :)
Yes, I'll start the bench
I will leave merging till Monday tho so we have more eyes
It should be, it's seen a lot of iterations
let's merge when it is ready, but I think it is ready
we also need to sync with the Docker people @Erik Martin-Dorel
and opam dev
this PR finally achieves a very good thing
the files in Coq repos should be the ones is core-dev
also, the build is finally split in several packages
and all the features we'd like are supported
What about docker needs to be synced? Are the dev images not working?
There is a special coq.opam.docker
which is not needed anymore
Create an issue in the coq-docker repo then
Fiat doesn't look good
Its already more than 2 hrs
In master takes close to 3 hours usually
flags coq is built are not changed
already in master is built using dune
tho we set release mode now
which should be the default, it could be the case that release mode in flambda is slower than dev mode?
wouldn't be the first time that -O2 makes things slower
but that's IMO orthogonal to this PR, the jobs you mention are all already very close to timeout and are timing out in unrelated PRs from time to time
I bet if someone would spend time optimizig flambda flags for Coq we'd see an speedup
Moreover some more tests were added to performance that are making the thing fail
performance is working now, I'm not sure what you mean
the tests were removed
I saw the exponential test for extraction was added, that made it timeout
now removed
(now = some time yesterday)
Thanks for the update
https://github.com/coq-community/coq-performance-tests/pull/22#issuecomment-1165010862
Emilio Jesús Gallego Arias said:
we also need to sync with the Docker people Erik Martin-Dorel
Thanks @Emilio Jesús Gallego Arias for the ping;
can you confirm what should be done regarding dune in docker-coq? (just skimmed your discussion so far, sorry)
FTR, currently all images provide dune 3.2.0:
https://github.com/coq-community/docker-base/blob/a98293eef30ab09ddcb7ad453ced4e657fee6a2f/images.yml#L9
but two versions of dune have been released last week:
https://github.com/ocaml/dune/releases
@Erik Martin-Dorel , the change concerns the coq.opam.docker file
and coq.dev packages
where is the coq.opam.docker
file used?
I couldn't see it, let me clone
it is used by the --locked
option of the opam install
command
here: https://github.com/coq-community/docker-coq/blob/master/coq/dev/Dockerfile#L21
ah ok, I searched for the full thing, I see is just the suffix
so I think we can remove that
anyway and as soon as coq.opam.docker
is changed in coq#master
, this trigger a rebuild of the image coqorg/coq:dev
How can we test #15560 with the docker image?
I just did remove coq.opam.docker there, now it should work fine
but note that there are 3 packages to pin
coq-core, core-stdlib, and coq
and for coqide
coqide-sever and coqide
what plan do you have in mind?
testing #15560 with docker-coq before merging the PR?
in which case I can create a temporary image that tracks the underlying PR branch
I don't know how to test that, but I'd be nice if we can test it
that puts finally an end to the several opam files
now the opam files in the coq repos are canonical for coq.dev
and for pin
yes, it's better to test it before merging… and needing yet another PR 😅
yes I think so
I'll be happy to follow the strategy you think is best
We have improved in that PR the opam testing we do in CI too
quite a bit
actually I wonder if we could have some setup in core-dev
that just tells opam "look for the opam files in the repos"
as already we specify
BTW @Emilio Jesús Gallego Arias does this testing requires dune 3.3.x ?
because as I told beforehand, currently coqorg/base assumes dune 3.2.0
This is all dune 2.9
Erik Martin-Dorel said:
what plan do you have in mind?
testing #15560 with docker-coq before merging the PR?
done: see the following GitLab CI pipeline that should take ~30':
https://gitlab.com/coq-community/docker-coq/-/pipelines/572405390
Thanks a lot @Erik Martin-Dorel ; Coq indeed depends on Dune 2.9
or higher, we had to raise the dep due to some bugs that were affecting us, for example in the generation of opam files which we'd like to use
Btw I checked that the CI of the consolidation PR is all green now (from the previous run)
And it looks like the newly deployed coqbot is working fine for this PR
To check it hasn't broken anything in older branches I've reset the refman job here https://github.com/coq/coq/pull/16180
However it doesn't seem to be working
https://gitlab.com/coq/coq/-/jobs/2637491035
This is not coqbot related AFAICT
ERROR: Job failed: failed to pull image "registry.gitlab.com/coq/coq:bionic_coq-V2022-05-20-cb9fc1de6b" with specified policies [always]: Error response from daemon: manifest for registry.gitlab.com/coq/coq:bionic_coq-V2022-05-20-cb9fc1de6b not found: manifest unknown: manifest unknown (manager.go:203:0s)
I've reset it like 5 times now, is there something going on with the docker images?
It can't be related to the coqbot or consolidation PR right?
Is it because the job is old?
yes, it's older than the most recent image so its image got cleaned up
Merging soon
(bracing for impact)
Don't brace just yet, still waiting for @Erik Martin-Dorel because he wants to merge something before
Yes, thanks (give me 15' and I'm back to my office)
This kind of PR is like a twin-engine Aeoroflot tupolev bound for Omsk, it's always better to bring your own parachute and brace constantly, just in case.
I apologize in advance @Pierre-Marie Pédrot if we disappoint you and in the it just turns out to be a ride in 25cts plastic horse machine
Fingers crossed :) IIUC we can expect the coqorg/coq:dev docker image to work fine once this is merged?
@Matthieu Sozeau Yes, Erik took care of that.
merged
is it possible that this broke the coq.dev opam packages?
[ERROR] The installation of coq failed at "make COQ_USE_DUNE= install".
#=== ERROR while installing coq.dev ===========================================#
# context 2.1.1 | linux/x86_64 | ocaml-variants.4.14.0+options | https://coq.inria.fr/opam/core-dev#2022-06-25 15:20
# path ~/.opam/coq-test/.opam-switch/build/coq.dev
# command ~/.opam/opam-init/hooks/sandbox.sh install make COQ_USE_DUNE= install
# exit-code 2
# env-file ~/.opam/log/coq-837414-1861ee.env
# output-file ~/.opam/log/coq-837414-1861ee.out
### output ###
# To install Coq using dune, use 'dune build -p P && dune install P'
# where P is any of the packages defined by opam files in the root dir
# make: *** [Makefile.dune:170: install] Error 1
I did opam update && opam upgrade
, to no avail
Yes, https://github.com/coq/opam-coq-archive/pull/1923 not merged yet
ah, okay. Iris CI will fail until that happens then, so I'd appreciate a quick merge. :)
(FWIW this looks like a coordination issue to me, if the Coq PR was merged knowing that would break opam.)
I was aware of the coordination problem, and was correctly noted in my todo, I just literally couldn't get to the keyboard in time
Hi @Ralf Jung
In the meantime, note that you can prepend your opam install coq.dev
command with some opam git pinning to use the official upstream-committed .opam files:
opam pin add -n -y -k git coq-core.dev "git+https://github.com/coq/coq#master"
opam pin add -n -y -k git coq-stdlib.dev "git+https://github.com/coq/coq#master"
opam pin add -n -y -k git coq.dev "git+https://github.com/coq/coq#master"
opam install -j "$(nproc)" coq.dev
that doesn't really help for CI, where we have infrastructure to very easily say "install that version of that package" but not "run this arbitrary code"
Emilio Jesús Gallego Arias said:
I was aware of the coordination problem, and was correctly noted in my todo, I just literally couldn't get to the keyboard in time
fair.
I hope the opam PR gets merged quickly then. :)
Last updated: Oct 12 2024 at 12:01 UTC