| 9 Oct 2021 |
 hexa | nah, only a partial fix 😕 | 19:25:36 |
| hexa | In reply to @vcunat:matrix.org
Anyway, let's do a new staging-small eval: https://hydra.nixos.org/eval/1712002 restarted with python39 revert | 22:55:24 |
| 10 Oct 2021 |
| hexa | I think python-unstable might become ready tonight for merge into staging | 16:53:48 |
 jonringer | I'm going to do some fixes as well, just give me a few hours :) | 20:56:25 |
| jonringer | actually, if it's going into staging, then just merge when ready | 20:58:24 |
| hexa | jonringer: I think I'm about done. | 23:28:06 |
| jonringer | I'll just do fixes on staging next | 23:30:04 |
| hexa | wfm | 23:33:16 |
| 11 Oct 2021 |
| hexa | and done. Well … bisecting ocrmypdf, but that's going to take a while. | 01:09:23 |
| hexa | bisected to pybind11 2.8.0 bump | 14:09:24 |
| 13 Oct 2021 |
| jonringer | hexa: The pikepdf tests which are failing (and then causing ocrmypdf to fail) because of timeouts. seems like pybind11 2.8.0 has some performance degradation. | 02:34:31 |
| jonringer | tests/test_metadata.py:277:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
args = (1, 1, 1, 0, 0, 0), kwargs = {}, initial_draws = 0
start = 1835476.350838395, result = None, finish = 1835476.600072148
internal_draw_time = 0, runtime = datetime.timedelta(microseconds=249234)
current_deadline = timedelta(milliseconds=200)
@proxies(self.test)
def test(*args, **kwargs):
self.__test_runtime = None
initial_draws = len(data.draw_times)
start = time.perf_counter()
result = self.test(*args, **kwargs)
finish = time.perf_counter()
internal_draw_time = sum(data.draw_times[initial_draws:])
runtime = datetime.timedelta(
seconds=finish - start - internal_draw_time
)
self.__test_runtime = runtime
current_deadline = self.settings.deadline
if not is_final:
current_deadline = (current_deadline // 4) * 5
if runtime >= current_deadline:
> raise DeadlineExceeded(runtime, self.settings.deadline)
E hypothesis.errors.DeadlineExceeded: Test took 249.23ms, which exceeds the deadline of 200.00ms
/nix/store/729144mrgipxk30s2c049w28783r203v-python3.9-hypothesis-6.23.2/lib/python3.9/site-packages/hypothesis/core.py:588: DeadlineExceeded
---------------------------------- Hypothesis ----------------------------------
Falsifying explicit example: test_random_dates(
year=1, month=1, day=1, hour=0, mins=0, sec=0,
)
__________________________ test_random_valid_docinfo ___________________________
[gw6] linux -- Python 3.9.6 /nix/store/kjj6088w5bv56pqnkkcgpv9cw1y8082p-python3-3.9.6/bin/python3.9
> ???
E hypothesis.errors.FailedHealthCheck: Data generation is extremely slow: Only produced 1 valid examples in 11.61 seconds (0 invalid ones and 0 exceeded maximum size). Try decreasing size of the data you're generating (with e.g. max_size or max_leaves parameters).
E See https://hypothesis.readthedocs.io/en/latest/healthchecks.html for more information about this. If you want to disable just this health check, add HealthCheck.too_slow to the suppress_health_check settings for this test.
tests/test_metadata.py:593: FailedHealthCheck
| 02:34:45 |
| jonringer | we could dis able the tests, since we aren't in the business of maintaining performance metrics | 02:35:10 |
| jonringer | * we could disable the tests, since we aren't in the business of maintaining performance metrics | 02:35:15 |
| hexa | I hadn't seen pikepdf fail, only ocrmypdf, and I applied a patch for the later | 03:30:23 |
| hexa | * I hadn't seen pikepdf fail, only ocrmypdf, and I applied a patch for the latter | 03:30:24 |
 Ryan Burns | hexa: Sorry for the bad info on targeting the python-unstable branch. I thought I'd seen people pulling big python updates into python-unstable, but is that decided on more of a per-package basis, and staging should be the typical default? | 03:38:28 |
| hexa | we open the python-unstable branch for automated bulk updated followed by a stabilization period | 03:39:06 |
| hexa | when we deem it stable enough it gets merged into staging | 03:39:15 |
| Ryan Burns | makes sense, thank you | 03:39:46 |
| hexa | so … next staging run, are we waiting for something, something schedule? | 21:25:09 |
| 14 Oct 2021 |
 tomberek | would we want https://github.com/NixOS/nixpkgs/pull/134546 to go into staging instead? | 02:16:51 |
 happysalada | In reply to @hexa:lossy.network
so … next staging run, are we waiting for something, something schedule? I thought we were waiting for unstable to catch up. If staging-next starts now, unstable might take a lot longer to catch up since it has a lower priority. Note that I don't mind either way | 03:27:55 |
| Ryan Burns | unless there is a fix for the stuck x86_64-darwin builders there's nothing to wait for, all the other platforms are idle | 05:20:53 |
 lukegb (he/him) | Yeah, we could start a new staging cycle | 11:32:40 |
| lukegb (he/him) | Anything outstanding that wants to land? | 11:32:56 |
| hexa | give me 30 minutes to take a look through the queue | 11:44:34 |
| hexa | merged what I'm comfortable with. | 12:11:34 |
| lukegb (he/him) | Other things that I think look mostly safe:
- https://github.com/NixOS/nixpkgs/pull/132713/files (CUPS from Apple -> OpenPrinting, inc some security fixes?)
- https://github.com/NixOS/nixpkgs/pull/141352 (certifi bump)
| 12:31:12 |
| hexa | merged certifi, not experience with printers 😛 | 13:58:59 |
