[Cuirass] Wrong type: #f in cuirass/templates.scm

  • Done
  • quality assurance status badge
Details
3 participants
  • John Kehayias
  • Tobias Geerinckx-Rice
  • Mathieu Othacehe
Owner
unassigned
Submitted by
Tobias Geerinckx-Rice
Severity
normal
T
T
Tobias Geerinckx-Rice wrote on 14 Nov 2021 12:14
(address . bug-guix@gnu.org)(name . Mathieu Othacehe)(address . othacehe@gnu.org)
87o86n0ywy.fsf@nckx
Guix,

The following page refuses to load:

Toggle snippet (9 lines)
~$ curl -LI https://ci.guix.gnu.org/build/1618120/details
HTTP/1.1 404 Not Found
Server: nginx
Date: Sun, 14 Nov 2021 11:16:01 GMT
Content-Type: text/plain;charset=utf-8
Content-Length: 42
Connection: keep-alive

Here's what gets logged in cuirass-web.log:

Toggle snippet (17 lines)
2021-11-14T12:13:51 GET /build/1618120/details
In cuirass/http.scm:
747:13 5 (url-handler _ _)
In cuirass/templates.scm:
740:22 4 (build-details ((#:derivation . "/gnu/store/0rks1d?")
?) ?)
In srfi/srfi-1.scm:
603:19 3 (map2 (1287823 1287827 1289462 1289463 1289464 # # #
?) ?)
In cuirass/templates.scm:
747:51 2 (_ 1287823 _)
215:4 1 (status-class _)
In ice-9/boot-9.scm:
1685:16 0 (raise-exception _ #:continuable? _)
In procedure =: Wrong type: #f

Kind regards,

T G-R
-----BEGIN PGP SIGNATURE-----

iIMEARYKACsWIQT12iAyS4c9C3o4dnINsP+IT1VteQUCYZDwPQ0cbWVAdG9iaWFz
LmdyAAoJEA2w/4hPVW15WeEBAPFzDiKHsUk1ns5Tt+rF6AlmdfCSJG+w6TDlnVad
9KXOAQDLNpqlvYhsnrFBLLb09EZ1o+V0aguBRAtimZXsej2YBg==
=RO7u
-----END PGP SIGNATURE-----

T
T
Tobias Geerinckx-Rice wrote on 14 Nov 2021 12:25
87k0hb0ygk.fsf@nckx
I forgot what I once knew:

Tobias Geerinckx-Rice via Bug reports for GNU Guix ???
Toggle quote (2 lines)
Due to an unrelated Cuirass(/Guile?) bug -I wouldn't work either
way:

HTTP/1.1 404 Not Found

but the page is still broken regardless.

Kind regards,

T G-R
-----BEGIN PGP SIGNATURE-----

iIMEARYKACsWIQT12iAyS4c9C3o4dnINsP+IT1VteQUCYZDyiw0cbWVAdG9iaWFz
LmdyAAoJEA2w/4hPVW15wkIA/1JR5wFl1xGGn9sElQNQKBSn9/FoKtd5ES/6R4UB
94dOAP9m4DZPpo6Y+9VzzZrA+evJ6C1jArQDPJ7qfBmxJxg3CQ==
=6Zee
-----END PGP SIGNATURE-----

J
J
John Kehayias wrote on 14 Nov 2021 17:31
Re: [Cuirass] Wrong type: #f in cuirass/templates.scm
(name . 51837@debbugs.gnu.org)(address . 51837@debbugs.gnu.org)
LYWoAW2M21lJTM1xI4u_jwDNKlz8NsBt5TZmrG5Tib6HnIcgu7R4XabyOFx5qo34UfzMQMoXOiTID_183AlNepCbmWx83cNejaeQLU6iUAw=@protonmail.com
I've noticed not getting build detail pages for in-progress or scheduled builds. I definitely noticed in the last few days with trying to see the builds with the core-updates-frozen-batched-changes merge (there was a long gc job forceably killed, maybe other wonkiness?). But I can't be sure if it was before that as well.
J
J
John Kehayias wrote on 14 Nov 2021 17:59
(name . 51837@debbugs.gnu.org)(address . 51837@debbugs.gnu.org)
5hDJbAf1B1LjubDM0_aWbxYtPP_3B7xgacGp1ran3hvasRNRhaN44MOwOcmMkwCx5xH_eJnyxILH_R0qwmxaKl64aXtJe8VLqZrlhcKXwD4=@protonmail.com
Toggle quote (2 lines)
> I've noticed not getting build detail pages for in-progress or scheduled builds. I definitely noticed in the last few days with trying to see the builds with the core-updates-frozen-batched-changes merge (there was a long gc job forceably killed, maybe other wonkiness?). But I can't be sure if it was before that as well.

I take that back, seeing (recent, at least) failed builds also not show the detail pages, like https://ci.guix.gnu.org/build/1618541/details
M
M
Mathieu Othacehe wrote on 29 Nov 2021 14:26
Re: bug#51837: [Cuirass] Wrong type: #f in cuirass/templates.scm
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)(address . 51837-done@debbugs.gnu.org)
87tufvjdoa.fsf@gnu.org
Hello Tobias,

This error was likely caused by the core-updates-frozen-batched-changes
specification removal in Cuirass. Some builds keep referring to removed
specifications causing unexpected behaviours.

The strange thing is that I'm using the "DELETE CASCADE" SQL property
that should remove Builds pointing to a removed specification
automatically.

Regardless of this misunderstanding, it might not be great idea to
remove specifications altogether because a build that is added by the
core-updates-frozen specification might be referred by the master
specification once the merge has happened.

I introduced specification deactivation with
to work around this problem.

This is not yet deployed, but I think it should solve the issue you
reported.

Thanks,

Mathieu
Closed
?