Re: [PATCH 2/2] debian: Fix FTCBFS: Skip crc32 test (Closes: #999879)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Nov 20, 2021 at 09:15:48AM -0800, Darrick J. Wong wrote:
> On Sat, Nov 20, 2021 at 08:32:40AM +0100, Helmut Grohne wrote:
> > Hi Dave,
> > 
> > On Sat, Nov 20, 2021 at 10:11:05AM +1100, Dave Chinner wrote:
> > > I don't get it. The crcselftest does not use liburcu in
> > > any way, nor does it try to link against liburcu, so it should not
> > > fail because other parts of xfsprogs use liburcu.
> > > 
> > > What's the build error that occurs?
> > 
> > As the build log shows, that's not technically accurate. You can find
> > logs of test builds for various architecture combinations at
> > http://crossqa.debian.net/src/xfsprogs. This is also available as a link
> > called "cross" in https://tracker.debian.org/xfsprogs.
> > 
> > The relevant part is:
> > |     [TEST]    CRC32
> > | In file included from crc32.c:35:
> > | ../include/platform_defs.h:27:10: fatal error: urcu.h: No such file or directory
> > |    27 | #include <urcu.h>
> > |       |          ^~~~~~~~
> > | compilation terminated.
> > 
> > I failed to figure a good way of dropping either include directive.
> > 
> > > We need to fix the generic cross-build problem in the xfsprogs code,
> > > not slap a distro-specific build band-aid over it.
> > 
> > I fully agree with this in principle. However, when I fail to find that
> > upstreamable solution, I try to at least provide a Debian-specific
> > solution to iterate from.
> > 
> > Can you propose a way to drop either #include?
> 
> Frankly I don't really see the value in crc32selftest when cross
> compiling -- sure, the crc32c code works correctly on the build host,
> but that proves nothing about the (cross-)built binaries that end up in
> the package.

Yup, that's pretty much what I was getting at.

> The selftest code is modular enough that it's included in xfs_io and it
> seems to run in under 500us even on my ancient raspberry pi 3b+
> downclocked to 600mhz.  Why don't we just add it to mkfs and repair?
> Those tools shouldn't be run all that frequently, and now we'll know
> immediately if crc32c is broken on a user's system.
> 
> Then we don't need the build-time selftest at all.

Sounds reasonable, my only concern is what do users do when
xfs-repair fails the self test and they need to fix their
filesystem?

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux