| 20 Oct 2023 |
 stigo | Yeah made it a lot easier to have access to that :) | 14:04:43 |
| stigo | In reply to @janne.hess:helsinki-systems.de
There's also my rt update (which includes security fixes) that also updates some perl packages so it will conflict :/ I foresee one conflict with DateExtract, but no prob to resolve | 14:06:19 |
 Janne Heß | In reply to @stigo:matrix.org
I foresee one conflict with DateExtract, but no prob to resolve ah nice I already feared it was more | 14:06:36 |
| stigo | Dont think so | 14:06:43 |
| stigo | There are some issues with the Paranoid patch, which annoys me. Will look at that one later today. | 14:09:41 |
| stigo | In reply to @janne.hess:helsinki-systems.de
I asked Vladimir on how to get a jobset. Maybe he's already the correct person ;) I'm a bit of a hydra-noob, but it's possible to manually control jobs right? | 14:18:25 |
| Janne Heß | In reply to @stigo:matrix.org
I'm a bit of a hydra-noob, but it's possible to manually control jobs right? you mean the jobs that are being built? | 14:18:47 |
| stigo | In reply to @janne.hess:helsinki-systems.de
you mean the jobs that are being built? Like choosing when to start a large build, want to fix i.e. Paranoid first | 14:19:22 |
| Janne Heß | In reply to @stigo:matrix.org
Like choosing when to start a large build, want to fix i.e. Paranoid first nope, that's completely random. both of these things | 14:19:57 |
| Janne Heß | you can make the jobset manual, then somebody has to manually trigger a new evaluation rather than a timer running. but once the evaluation is complete, it will immediatly start building | 14:20:21 |
| stigo | Automatic should be OK then I guess | 14:21:15 |
|  vcunat joined the room. | 15:19:55 |
| Janne Heß | stigo: There's Vladimir | 15:20:09 |
| Janne Heß | His last messages from our DM:
From staging?
Isn't that bad for such a jobset?
It can mix in failures unrelated to the perl updates that haven't been discovered yet.
| 15:20:32 |
| vcunat | I suggest staging-next as the branch to base onto right now. (But still targeting staging in the PR.) | 15:21:10 |
| vcunat | As a compromise between freshness and risk of confusion by unrelated failures. | 15:21:50 |
| vcunat | It also has evals on Hydra, so those can be used as comparison base. | 15:22:40 |
| stigo | sure, rebased onto staging-next | 15:33:32 |
| vcunat | Just x86_64-linux for now, I guess. | 15:41:41 |
| stigo | sure, that's fine | 15:42:52 |
| stigo | vcunat: thx btw :) | 15:43:51 |
| Janne Heß | https://hydra.nixos.org/jobset/nixpkgs/pr-262304-perl-updates | 15:53:30 |
| stigo | Built the directly changed perlPackages and perl536Packages on x86_64-linux, all were OK | 16:25:07 |
| stigo | Hoping to keep only one perl5 one day tho.. | 16:26:31 |
| 21 Oct 2023 |
 qbit | seems PLS is missing a dep | 11:36:10 |
| qbit | Future::Queue https://github.com/NixOS/nixpkgs/pull/262524 | 11:43:38 |
| stigo | Just some issues with commit messages, otherwise looks good to me | 12:24:34 |
| stigo | (It's very useful that commit messages are consistent, since it enables some nice git | grep type hacks from time to time) | 12:25:15 |
| qbit | oh woops - i knew that .. it's what I get for submitting before coffee \o/ | 12:37:12 |
| 23 Oct 2023 |
| stigo | Waiting for hydra to pick up the perl-updates branch and test the latest changes after another rebase from staging-next. If hydra agrees, then I think we're good to merge it into staging. | 03:22:41 |
