| 15 Feb 2022 |
Linux Hackerman | Hm, I've been trying to mix lovesegfault's changes from https://github.com/NixOS/nixpkgs/pull/157072 in as well. Not sure if this is actually something we should do or not though | 19:27:08 |
Linux Hackerman | I think it does make sense to have a single version of hydra in nixpkgs. And I think the hydra package in nixpkgs is a bit "second-class" given that upstream development and the hno deployment use flakes. | 19:31:13 |
Linux Hackerman | Any opinions? | 19:31:33 |
Linux Hackerman | Though I'm pretty sure that if we have only a single hydra package, we should also only have a single hydra test :) | 19:31:50 |
Linux Hackerman | * Though I'm pretty sure that if we have only a single hydra package, we should also only have a single hydra test, so if I do pull in lovesegfault's changes I'll also add that :) | 19:33:27 |
Rick (Mindavi) | In reply to @linus.heckemann:matrix.mayflower.de Any opinions? My opinion is that we should have only 1 version. One can always override if need be | 19:49:31 |
Linux Hackerman | I've opened https://github.com/NixOS/nixpkgs/pull/160202 with the current state, it's not quite finished yet though. | 19:53:34 |
| 16 Feb 2022 |
| @packetgrill:automattic.com left the room. | 06:09:17 |
ma27 | In reply to @linus.heckemann:matrix.mayflower.de I think it does make sense to have a single version of hydra in nixpkgs. And I think the hydra package in nixpkgs is a bit "second-class" given that upstream development and the hno deployment use flakes. agreed. The multiple package thing is a relict from https://github.com/NixOS/nixpkgs/pull/83600 | 14:14:33 |
@grahamc:nixos.org | A tricky thing is there are quite likely still people using hydra before the old version. Maybe it would make sense to have pkgs.hydra be the default, and pkgs.hydra-migrate be available as a fallback. | 14:46:58 |
| 17 Feb 2022 |
trofi | I thihk hydra's UI does not show all jobsets: https://hydra.nixos.org/project/nixpkgs
I expected to see binutils-2.36 there, but looks like it's not there. If I look at the browser history in can find it: https://hydra.nixos.org/jobset/nixpkgs/binutils-2.36
| 08:23:57 |
trofi | * I think hydra's UI does not show all jobsets: https://hydra.nixos.org/project/nixpkgs
I expected to see binutils-2.36 there, but looks like it's not there. If I look at the browser history in can find it: https://hydra.nixos.org/jobset/nixpkgs/binutils-2.36
| 08:24:10 |
hexa | yup, jobsets can be set hidden | 11:27:15 |
| Ash joined the room. | 13:31:32 |
trofi | Ah, tricky. | 21:21:58 |
| 18 Feb 2022 |
| Rev. CornWallace III (novus ordo seclorum) changed their display name from Chuck Winter to Chuck Winter (vi/vim). | 04:12:53 |
| Rev. CornWallace III (novus ordo seclorum) changed their display name from Chuck Winter (vi/vim) to Chuck Winter. | 04:21:46 |
| Tseb removed their profile picture. | 11:18:03 |
| Tseb removed their display name Tseb (Old). | 11:48:49 |
| Tseb left the room. | 12:59:15 |
| 19 Feb 2022 |
| Rhys joined the room. | 08:15:26 |
ma27 | as I'm currently going through my open PRs, anybody out there who wants to take a look at my oldest open PR (https://github.com/NixOS/hydra/pull/743,
Add a filter for maintainers in the jobset-eval view) these days? %) | 19:56:04 |
| 21 Feb 2022 |
| Rev. CornWallace III (novus ordo seclorum) changed their display name from Chuck Winter to Chinchilla Wetreat. | 00:48:21 |
| Rickard Nilsson joined the room. | 13:02:39 |
@grahamc:nixos.org | I'd love a C++-competent review of https://github.com/NixOS/hydra/pull/1163 before I merge it in ~4h | 13:31:29 |
trofi | I think it's ok. (std::string) job["drvPath"] is a bit non-idiomatic. std::string (job["drvPath"]) would be more natural. | 15:13:30 |
| 25 Feb 2022 |
| @schnecfk:ruhr-uni-bochum.de joined the room. | 10:57:54 |
| 28 Feb 2022 |
| Florian | W3F changed their display name from Florian | W3F to Florian | W3F - OoO 02.03.. | 10:15:42 |
toonn | Feature request: It would be really sweet if a default comparison could be set that is different from just the previous eval of a jobset. Example use case, when developing something targeting staging-next I'm only interested in comparing jobs to a specific staging-next evaluation. Finding that evaluation by the staging-next commit the branch is based on is a tedious process and if it's been | 12:43:52 |
toonn | a while since I looked at an evaluation I have probably forgotten the point of comparison and need to go digging for it again. | 12:43:54 |