On 19/01/2024 21.03, Chris Lamb wrote:
Was there any reason to reject >ULONG_MAX? I'm touching this code,
and don't see a reason for it; it looks very arbitrary; especially
since some systems can have 32-bit long, but 64-bit time_t. Should I
just drop that check, or keep it? And why?
There
Hello again,
The build issues has been fixed, feel free to have a look at the PR, any
feedback is very welcome.
Thanks.
On 1/20/24 13:57, Pol Dellaiera wrote:
Hi,
I made a pull request for Nix at https://github.com/NixOS/nixpkgs/pull/282329
There are many issue while building it (see the
Hi,
I made a pull request for Nix at https://github.com/NixOS/nixpkgs/pull/282329
There are many issue while building it (see the log in the PR), but in the end,
it seems to build fine.
On 1/19/24 22:21, Alejandro Colomar wrote:
Hi,
On Fri, Jan 19, 2024 at 12:03:17PM -0800, Chris Lamb
Hi,
On Fri, Jan 19, 2024 at 12:03:17PM -0800, Chris Lamb wrote:
> > I was wondering... maybe I could write a library, libgetnum, and add
> > these functions there. That way, all those code bases in Debian that
> > have the problem we found in gettime() could be fixed easily by just
> > calling
Hey folks,
We've been using the following snippet of code to parse the value of
SOURCE_DATE_EPOCH in the C programming language:
https://reproducible-builds.org/docs/source-date-epoch/#c
I'm not 100% sure who originally wrote this code, but it was probably
sometime in the ~2015 era, and it
