| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| newer-deps | =================================================================== | no | ||||
| fix-test-timing | Resolve timing issue in the test Creating the TokenBucket far away from the actual tests means that the TokenBucket can accumulate a partial token before the start time for the first test is taken. After the first requested token exhausts the burst size it doesn't take the full time that would usually be required before the second token can be allocated. Most of the time this doesn't seem to be a problem, but on some architectures (armhf, mipsel) it seems to cause semi-consistent test failurses. Strictly speaking the same problem still exists with this patch, as the TokenBucket is still created before the start time of the test is taken, but with the current layout this inaccuracy usually balances out with the time added at the end, because the end time of the test is taken slightly after the last token is allocated. This also fixes that the test was overly lenient for all but the first test. All test are run with n+1 iterations to account for the initial burst token contained in the freshly created bucket, but only the first test gets to actually allocate that token. All others have to wait for a new token to be generated. This patch has not been forwarded to upstream yet, because at the time of writing it, I did not have access to my GitHub account. One I have I will (hopefully) forward it in a timely manner. |
Sven Bartscher <kritzefitz@debian.org> | no | debian upstream |