Le 21 août 2016 01:30:34 UTC+02:00, Daniel Hlynskyi <abcz2.upr...@gmail.com> a
écrit :
>still, why 1.1.1970?
Because it is a timestamp with value 0 for Linux files. Or maybe 1, to
distinguish them from pure zero.
> One of @edolstra's commits introduced algorithm,
>that
>sets source epoch time to most recent source change date. Wouldn't that
>be
>better date for /nix/store? Currently datetime in /nix/store carries
>zero
>information.
Yes, having store path time carrying information like the sources epoch could
be useful, but currently the NAR format used to fetch binary substitutes
prevents this. From Nix man:
A NAR archive is like a TAR or Zip archive, but it contains only the
information that Nix considers important. For instance, timestamps are elided
because all files in the Nix store have their timestamp set to 0 anyway.
Likewise, all permissions are left out except for the execute bit, because all
files in the Nix store have 644 or 755 permission.
>
>Also, I'd like to notice that non-epoch-starttime files do exist in my
>store, probably created in nix-shell or nix-build:
Should not happen, really.
>
>[danbst@LX:~]$ ls -ld /nix/store/* | grep -v "Jan 1 1970"
>drwxr-xr-x 3 nixbld1 nixbld 4096 Aug 5 23:26
>/nix/store/7iv1251a6g03m5jjqazd5rfmbqsz67nc-nixos-shell
>drwxr-xr-x 6 root root 4096 Aug 8 05:03
>/nix/store/pb6papnlgg62wkim7qsg8c2jw4izffx8-glibc-2.21
>-rw------- 1 root root 0 Aug 4 22:29
>/nix/store/30q3vgn6p6abfz4xbs47v11wcikf9dqr-plasma-desktop-5.7.2.lock
>-rw------- 1 root root 0 Aug 1 06:03
>/nix/store/59cp809rmyh12p800sln490yr0f93nx7-four-color-theorem-proof.lock
>-rw------- 1 root root 0 Aug 5 23:26
>/nix/store/7iv1251a6g03m5jjqazd5rfmbqsz67nc-nixos-shell.lock
>-rw------- 1 root root 0 Aug 4 00:15
>/nix/store/jv2drjhj8h0blz4lza6xsnraalsvhaf9-munin-2.999.2.lock
>-rw------- 1 root root 0 Aug 4 22:29
>/nix/store/jxkj59ppkpna1xlmpjzdbxqzw49gbgif-plasma-desktop-5.7.2-dev.lock
>-rw------- 1 root root 0 Aug 8 05:03
>/nix/store/pb6papnlgg62wkim7qsg8c2jw4izffx8-glibc-2.21.lock
>-rw------- 1 root root 0 Jul 31 23:24
>/nix/store/v07q9f5k730czvabfzilnsnahdbk19hx-four-color-theorem-src.lock
>-rw------- 1 root root 0 Aug 4 21:58
>/nix/store/vfgv4b1rgm1hkamqczmyals8s66gvq8k-ati-drivers-15.12-4.4.16.lock
>-rw------- 1 root root 0 Aug 9 03:47
>/nix/store/y9asyqxygq39lkmc98cmbqsja5yynwd0-ruby-2.3.1-p0.lock
>-rw------- 1 root root 0 Aug 1 00:20
>/nix/store/zlpqh99xfxqvwcwzj0hly2d07x84whz9-coq-8.3pl4.lock
>
>
>2016-08-20 12:11 GMT+00:00 Vladimír Čunát <vcu...@gmail.com>:
>
>> On 08/14/2016 04:13 PM, Ronny Pfannschmidt wrote:
>> > on nix it is a regular problem for me that zip file generating
>tools fail
>> > due to the epoch time being set to a time that's not supported in
>the
>> > zip format
>> > (mostly python wheels)
>> >
>> > i would like to propose setting that epoch by default to something
>that
>> > is supported by zip
>>
>> We discussed that zip problems aren't that bad to change timestamps
>of
>> /nix/store paths directly (1.1. 1970).
>>
>> For python and similar we have a hook that touches source files after
>> "unpacking" phase - the typical problem is after fetch* other than
>> fetchurl. Typical usage:
>> buildInputs = [ (ensureNewerSourcesHook { year = "1980"; }) ]
>>
>> Note that our generic python builder already does use the hook
>> automatically.
>>
>> --Vladimir
>>
>>
>>
>> _______________________________________________
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>nix-dev mailing list
>nix-dev@lists.science.uu.nl
>http://lists.science.uu.nl/mailman/listinfo/nix-dev
_______________________________________________
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
