https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275030
Gleb Smirnoff changed:
What|Removed |Added
CC||gleb...@freebsd.org
--- Comment #1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275030
--- Comment #18 from gerrit.ku...@aei.mpg.de ---
Are there any news on this? I use this setup (src/obj on NFS) to update
Tier2-platforms via nfs and manually removed the "-p" option as suggested in
the first patch above. Are there any advers
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275030
Alexander Vereeken changed:
What|Removed |Added
CC||Alexander88207@protonmail.c
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275030
--- Comment #17 from Warner Losh ---
(In reply to Martin Birgmeier from comment #16)
So we could use tar, with the following super ugly (and likely not very
portable) formulation:
diff --git a/Makefile.inc1 b/Makefile.inc1
index f47b9f66b
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275030
--- Comment #16 from Martin Birgmeier ---
On the zfs-on-root system I looked for one (of the few) files without uarch not
set and used cp to copy it to root's home dir. The copy has uarch set.
-- Martin
--
You are receiving this mail bec
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275030
--- Comment #15 from Martin Birgmeier ---
Btw tar does not complain if it cannot set flags, although it does set them if
possible (but not on NFS, obviously).
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275030
--- Comment #14 from Martin Birgmeier ---
(In reply to Warner Losh from comment #13)
On two machines with /usr/bin/basename on UFS, the uarch bit is not set. On one
machine with a ZFS root, uarch is set on /usr/bin/basename.
Also, to mini
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275030
--- Comment #13 from Warner Losh ---
(In reply to Martin Birgmeier from comment #12)
We still still don't know why the flags are set on /bin/basename... Until I
understand where they are coming from, or what environment we see them, I'm
lo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275030
--- Comment #12 from Martin Birgmeier ---
(In reply to Warner Losh from comment #11)
How about doing the copy only if the existing target differs from the source?
Something like "cmp -s a b || cp a b". Would that be sufficient to satisfy m
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275030
--- Comment #11 from Warner Losh ---
The -p change was to fix meta mode. Now that I've had a chance to sleep on it
I remember: it was for metamode. filemon catches EVERYTHING that's used to
build a target, including the binaries that are us
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275030
--- Comment #10 from Martin Birgmeier ---
(In reply to Jessica Clarke from comment #4)
Could this be related to bug 249957? - There seem to be races in what make is
doing when timestamps are either truncated to seconds (over NFS) or otherw
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275030
--- Comment #9 from Warner Losh ---
Also NetBSD's import of BSDI patch to ignore EOPNOTSUPP when flags == 0
https://reviews.freebsd.org/D42674
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275030
--- Comment #8 from Warner Losh ---
NetBSD's cp -N: https://reviews.freebsd.org/D42673
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275030
--- Comment #7 from Warner Losh ---
But the best way to fix this would be to import NetBSD's cp's -N flag: don't
copy flags. We don't need them. And I can think of no good that can come from
copying them...
Though I'd really like to unders
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275030
--- Comment #6 from Warner Losh ---
Iirc, copying without -p would not preserve the file's times, which lead to
some dependency breaking. Removing that will break things again. Iirc, there
were other problems fixed that were discovered afte
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275030
--- Comment #5 from Jessica Clarke ---
Given that commit, I am rather hesitant to say we should just go ahead and drop
the -p without first understanding why it was needed in the first place.
--
You are receiving this mail because:
You ar
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275030
--- Comment #4 from Jessica Clarke ---
commit 0e533c72bc300bd90390e950ea9e473b38eeb409
Author: Warner Losh
Date: Mon Aug 24 16:06:11 2020 +
When copying over the binaries, use '-p' to preserve date/time
Although I can't rep
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275030
--- Comment #3 from Martin Birgmeier ---
Created attachment 246393
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=246393&action=edit
[PATCH] enable building with NFS-mounted /usr/obj
--
You are receiving this mail because:
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275030
--- Comment #2 from Ed Maste ---
Alex, Jess - it seems reasonable to me to copy host tools without -p; I'm happy
to land this patch if you agree.
Martin, would you attach a git format patch so that author metadata can be
preserved?
--
Yo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275030
--- Comment #1 from Martin Birgmeier ---
The root cause probably is that files such as /usr/bin/basename have uarch set
in stable/14, but not in releng/12.4.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275030
Bug ID: 275030
Summary: buildworld fails if obj dir is NFS-mounted [patch]
Product: Base System
Version: 14.0-STABLE
Hardware: Any
OS: Any
Status: New
21 matches
Mail list logo
