Re: Bug#983706: gzip FTBFS on mips64el: FAIL: timestamp

Adrian Bunk <[email protected]> 于2021年3月1日周一 下午5:27写道：
>
> On Mon, Mar 01, 2021 at 10:59:20AM +0800, YunQiang Su wrote:
> > Adrian Bunk <[email protected]> 于2021年3月1日周一 上午7:13写道：
> > >
> > > Source: gzip
> > > Version: 1.10-2
> > > Severity: serious
> > > Tags: ftbfs
> > >
> > > https://buildd.debian.org/status/fetch.php?pkg=gzip&arch=mips64el&ver=1.10-3&stamp=1614531854&raw=0
> >
> > It seems due to some problem of kernel or filesystem:
> >...
> > > On the porterbox eller, 1.10-2 fails the same as 1.10-3.
> > > 1.10-3 builds in a buster chroot.
>
> This implies that what changed is in userspace.
>
> >...
> > On x86:
> > syq@vm208:~$ touch -t 196912312359.59 in
> > syq@vm208:~$ ls -l in
> > -rw-r--r-- 1 syq syq 0 Dec 31  1969 in
> > syq@vm208:~$ cp -a in in.xx
> > syq@vm208:~$ ls -l in.xx
> > -rw-r--r-- 1 syq syq 0 Dec 31  1969 in.xx
> >
> > On mips:
> > syq@m530-2:~/tmp/gzip/gzip-1.10/builddir$ ls -l in
> > -rw-r--r-- 1 syq syq 0 Dec 31  1969 in
> > syq@m530-2:~/tmp/gzip/gzip-1.10/builddir$ cp -a in in.xx
> > syq@m530-2:~/tmp/gzip/gzip-1.10/builddir$ ls -l in.xx
> > -rw-r--r-- 1 syq syq 0 Feb  7  2106 in.xx
>
> On eller the difference is that in buster
> the "ls -l in" already shows the 2106 date:
>
> (buster_mips64el-dchroot)bunk@eller:~$ ls -l in
> -rw-r--r-- 1 bunk bunk 0 Feb  7  2106 in
>
> (sid_mips64el-dchroot)bunk@eller:~$ ls -l in
> -rw-r--r-- 1 bunk bunk 0 Dec 31  1969 in

With some digging, we found the real problem:
    mips64 has y2106 problem

the struct stat in asm/stat.h, the timestamp is unsigned int (uint32_t),
so in the SYS_stat, -1 is converted to 0xffffff.

Then in glibc wrapper of stat, 0xffffffff need to convert to int64_t, then,
it is converted to 2016.

So, current, for gzip, we can just ignore the test fails on mips64el.

To solve this problem: I guess that we can wrap `statx' instead of
`stat' in glibc.
Since the timestamp in bits/stat.h is 64bit, there will no ABI broken.

>
>
> cu
> Adrian



-- 
YunQiang Su