Opened 6 years ago
Last modified 5 years ago
#20421 new defect
libgap workspace() doctest failures
Reported by: | jdemeyer | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | sage-7.2 |
Component: | interfaces | Keywords: | random_fail |
Cc: | vbraun | Merged in: | |
Authors: | Reviewers: | ||
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
I regularly get this. I'm not sure whether it is a random failure or not, it might be because of doing make distclean
first:
sage -t src/sage/libs/gap/assigned_names.py ********************************************************************** File "src/sage/libs/gap/assigned_names.py", line 59, in sage.libs.gap.assigned_names.load_or_compute Failed example: workspace(name='globals') Expected: ('...', True) Got: ('/home/jdemeyer/.sage/gap/libgap-globals-4034600654683281042', False) **********************************************************************
Change History (11)
comment:1 Changed 6 years ago by
comment:2 Changed 6 years ago by
For what it's worth I had some doctest failures when the gap
upgrade landed https://github.com/cschwan/sage-on-gentoo/issues/412. They did go away as mysteriously as they came after a couple of beta releases. They were persistent across rebuilding gap/libgap and sage.
comment:3 Changed 6 years ago by
Thats probably a race with building the workspace caches...
comment:4 Changed 6 years ago by
also reproduced on OSX: https://groups.google.com/d/msg/sage-release/iNYoT5KK3pw/EAiAqQmMMQAJ
comment:5 Changed 5 years ago by
I'm getting this pretty regularly in the Docker container. This is probably because the container always starts with a fresh environment, and doesn't have timings for the tests yet, so runs them in a different order. At what point are the "workspace caches" built, and is there some way we can make sure that is done as a prerequisite to this test?
comment:6 follow-up: ↓ 7 Changed 5 years ago by
Just for info: I just got this while upgrading to (lib)gap 4.9 (dev)
comment:7 in reply to: ↑ 6 Changed 5 years ago by
comment:8 follow-up: ↓ 9 Changed 5 years ago by
comment:9 in reply to: ↑ 8 Changed 5 years ago by
Replying to nthiery:
That was with 7.6.beta6 (and some of #22626). So without #22570 I believe.
If you pull Volker's current development tree at https://github.com/vbraun/sage you'll get #22570. I personnaly follow Volker's dev branch so I can anticipate or discover what's going to land for sage-on-gentoo. If you get an angry message from me on a positively reviewed ticket that's because I discovered you made my life harder from pulling on Volker's tree :P
comment:10 follow-up: ↓ 11 Changed 5 years ago by
Don't do that. You can look at the development branch but don't touch it.... commits may be rewritting / removed until it is published.
comment:11 in reply to: ↑ 10 Changed 5 years ago by
Replying to vbraun:
Don't do that. You can look at the development branch but don't touch it.... commits may be rewritting / removed until it is published.
Not the right place to discuss it. But yes I know, and I have been burned a couple of times. But it is very handy for what I do. However it happens on a special branch of the sage-on-gentoo overlay which normal user are not supposed to touch and very few know about.
Happened again. The scenario was:
make distclean
make ptestlong
-> got this failure