| 12 Aug 2021 |
 Vladimír Čunát | As for pulling the plug, I think the main problem is in the parts that are hard to decentralize (e.g. queue runner) | 14:03:14 |
 lukegb (he/him) | I don't think it's a case of "we need always running decentralized infrastructure" | 15:15:12 |
| lukegb (he/him) | It's more a case of "what is the plan if packet goes away" | 15:15:24 |
 sterni | packet doesn't even have to walk away | 15:16:52 |
| sterni | what if they have a serious network or power outtage or even … uh a fire | 15:17:03 |
| Vladimír Čunát | Network or power outage shouldn't last long enough to really hurt us. Cache etc. is separate. | 15:18:19 |
| lukegb (he/him) | Hydra isn't really a service we need to run at 5 9s or anything | 15:18:45 |
 Amine Chikhaoui | I think there is enough budget to cover unforeseen problems ? (https://opencollective.com/nixos#category-BUDGET) until a plan is figured out for when something unexpected happens | 15:21:47 |
| sterni | I don't think having the money is enough to be honest | 16:06:34 |
| sterni | the freenode -> matrix switch has if anything shown that if you have to scramble to find a solution in the moment the outcome will not be 100% satisfying and there is no room to get consensus for the drawbacks (which is probably the most problematic about this) | 16:07:41 |
| 14 Aug 2021 |
| lukegb (he/him) | bringing up https://github.com/NixOS/nixpkgs/issues/115425 again; can we disable wendy on hydra please? (set maxjobs back to 0) | 14:36:10 |
| sterni | why don't we have a feature for sse 4.2 or such? isn't that precisely what that field is for? | 14:38:02 |
| lukegb (he/him) | wendy just doesn't do very well on big-parallel jobs anyway (e.g. Chrome builds) | 14:39:20 |
| lukegb (he/him) | if we want to eke all the life we can from wendy then we should remove the big-parallel required feature and add features for processor extensions to all the builders that do have them | 14:40:36 |
| lukegb (he/him) | but at the moment: the work wendy is doing could be done faster and better by one of the other workers | 14:41:14 |
| Vladimír Čunát | My understanding is that wendy got switched to big-parallel jobs exactly in order to avoid pytorch. | 15:35:53 |
| lukegb (he/him) | Yeah, but then I made pytorch big-parallel because the build takes a long time and is parallelisable xD | 15:43:18 |
| Vladimír Čunát | Oh, I didn't notice the reply and found out independently. | 15:51:25 |
| Vladimír Čunát | From what I've seen, wendy really is more trouble than worth. | 15:53:03 |
| 15 Aug 2021 |
| lukegb (he/him) | grahamc (he/him): can I get a new hydra jobset ala staging (with... whatever shares are appropriate) pointed at https://github.com/lukegb/nixpkgs.git xcrypt? This is for https://github.com/NixOS/nixpkgs/issues/112371 | 02:16:50 |
| Vladimír Čunát | In reply to @lukegb:zxcvbnm.ninja
grahamc (he/him): can I get a new hydra jobset ala staging (with... whatever shares are appropriate) pointed at https://github.com/lukegb/nixpkgs.git xcrypt? This is for https://github.com/NixOS/nixpkgs/issues/112371 I wonder if building all individual packages is an overkill. Only relatively few packages use the library, I think; Arch list: https://archlinux.org/todo/libxcrypt-rebuild/
It might make sense to start just locally. Or do a -small jobset and then (using that from cache) try those packages locally.
A potential risk: I wonder if some build scripts might just silently turn off some features when failing to find libcrypt (or even try to only find it during runtime). But I'd hope the impact won't be significant here.
| 08:25:53 |
| Vladimír Čunát |
It might make sense to start just locally.
Anyway, gcc won't build, so there's not much to do yet :-)
../../../../gcc-10.3.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:143:10:
crypt.h: No such file or directory
| 09:35:52 |
| Vladimír Čunát | *
It might make sense to start just locally.
Anyway, gcc won't build, so there's not much to rebuild yet :-)
../../../../gcc-10.3.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:143:10:
crypt.h: No such file or directory
| 09:36:33 |
| lukegb (he/him) | I guess my point was: it's going to be a full rebuild anyway, even of unrelated packages | 10:50:29 |
| lukegb (he/him) | For the same reason as glibc version bumps are full rebuilds | 10:50:41 |
| lukegb (he/him) | I guess maybe I'll just merge it into staging and then we can fix it there rather than have a new jobset if we're reluctant to do that | 11:07:27 |
| lukegb (he/him) | In reply to @vcunat:matrix.org
It might make sense to start just locally.
Anyway, gcc won't build, so there's not much to rebuild yet :-)
../../../../gcc-10.3.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:143:10:
crypt.h: No such file or directory
Oh right, that's fixed locally, I haven't pushed it yet | 11:09:58 |
| Vladimír Čunát | Yes, it will be a full rebuild either way, but the extra jobset would serve to find breakages, not to utilize those binaries (because staging/next is somewhere else or would move in the meantime anyway). | 11:44:47 |
| Vladimír Čunát | Right now Hydra is fully utilized by staging-next - and I believe it should take precedence even if I created your jobset immediately. (the current iteration has been stabilizing for more than two weeks already) | 11:50:04 |
| lukegb (he/him) | One of the problems we're going to run into though is that bootstrapping it is hard, because they don't ship tarball releases | 12:52:45 |
