Stan Hu

Fix Daylight Savings parsing

3

Previously the offset change for Daylight Savings was unnecessarily added all the time, resulting in this discrepancy when the local time was set to UTC-7: ```ruby Time.parse('2020-11-01 00:00:00') => 2020-11-01...

## Problem description While trying to debug through a bunch of nested blocks and Enumerators, I see `Destination frame (0) is out of range (-1)`. I think is a debugger...

Add liveness health check support

8

When MailRoom is run in Kubernetes, we have found occasions where MailRoom appears to have attempted to stop running, but `Net::IMAP` is stuck waiting for threads (https://github.com/ruby/net-imap/issues/14). This commit adds...

Fix build errors with multiple Lua libraries

5

This commit fixes two items: 1. Previously `configure` would search for Lua in known paths, but this could cause the Makefile to use inconsistent header and library paths. For example,...

Use a minimum of 1 thread per core for CPU total calculation

6

## Description In some LXD containers running with VT-x hardware virtualization, it appears that threads per core is 0, resulting in a total number of CPUs of 0. Add a...

Fall back to /proc/cpuinfo if lscpu doesn't have CPU totals

1

## Description https://github.com/chef/ohai/pull/1454 made `lscpu` the primary way Ohai gathers CPU data, but the parser doesn't handle the output from a Raspberry Pi 4 Cortex-A72. For example, an ARM cluster...

lscpu parser doesn't parse Raspberry Pi 4 (ARM Cortex-A72) output

4

## Description As a result of https://github.com/chef/ohai/pull/1454, `node['cpu']` is nil since the `lscpu` output is not parsed properly. I would have expected the fallback to go to `/proc/cpuinfo`. ## Ohai...

CPU total is 0 when threads-per-core is 0

1

## Description Since https://github.com/chef/ohai/pull/1454, using `node['cpu']['total']` appears to return 0 for some virtualized platforms when `threads per core` is 0. This was reported in https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6895. ## Ohai Version v17.9.0 ##...

Stale Rugged::Config#each_key values if another process changes .git/config

1

This looks like a regression from libgit2 0.28.0, but I'm not sure yet if it's a Rugged issue or a libgit2 one. Here's a sample reproduction: ```ruby require 'rugged' repo...

I noticed that nothing in `Rugged::Blob` makes any attempt to convert blob text to the filtered output via `.gitattributes` (e.g. CRLF output). In libgit2, I see [calls to `git_blob_filtered_content()`](https://github.com/libgit2/libgit2/blob/77394a27af283b366fa8bb444d29670131bfa104/tests/filter/blob.c#L33), but...