Peder Bergebakken Sundt
Peder Bergebakken Sundt
Same on linux. Repro: ```shell podman run -it --rm docker.io/library/python:3.11 /bin/bash -c "pip wheel learn2learn" ```
Also, building wheels on github will let you catch issues like #413 early
Same issue on nixpkgs, likely as a result of bumping vala from 0.56.13 to 0.56.14. EDIT: https://gitlab.gnome.org/GNOME/vala/-/compare/0.56.13...0.56.14
I found that entering a nix bash shell caused everything sourced from /etc/skel to fail, where a lot of the SLURM logic is set up on this host. Here I...
A neat trick if you use direnv to enter the devShell: If the flake outputs its inputs: ```nix outputs = { self, nixpkgs, ... } @ inputs : { inherit...
And `https://api.github.com/repos/owner/repo/tarball/refs/tags/v1.2.3`
You do get a red X in the https://github.com/pulls view when CI fails. Sending messages every time eval fails would cause a storm everytime master fails eval.
Doesn't this work? 
It may be because the editor config checks run in a github action runner, while the ofborg CI checkmarks are set using some other API by the ofborg runners.
We experienced issue this when seeking with visible subs. It seems the end event was skipped, leaving the sub stuck while new ones piled on top.