only. In -stable, and in -current before the end of December the
following tools: ls, rm, chflags, find, xinstall and mtree used
a common set of routines to manipulate file flags.
[snip]
tool. At the beginnig of January, because of the proliferation of
utilities using these functions, I
Whichever system they run on. This can be the host machine even for
cross-compiling, if the target root is remote mounted. The main problem
with this in -current is that some install rules put ${DESTDIR} in the
installed files. perl is the main offender.
Which install rules? I'd like to
On Sun, 30 Jan 2000, Mark Murray wrote:
Whichever system they run on. This can be the host machine even for
cross-compiling, if the target root is remote mounted. The main problem
with this in -current is that some install rules put ${DESTDIR} in the
installed files. perl is the main
On Fri, Jan 28, 2000 at 08:30:55PM -0500, John Baldwin wrote:
I don't think we should change yet another thing before a release. The
problem shouldn't have been created this close to a release in the first
place. We have to stop somewhere, and I think we should stop "fixing" right
here,
On Fri, Jan 28, 2000 at 08:30:55PM -0500, John Baldwin wrote:
I don't think we should change yet another thing before a release. The
problem shouldn't have been created this close to a release in the first
place. We have to stop somewhere, and I think we should stop "fixing" right
On Sun, 30 Jan 2000, Brian Somers wrote:
I'm quite happy to DTRT(tm); I'm unsure that backing this change out
_is_ the right thing however. Can we discuss it some more first please?
I think that getflags()/setflags() should stay where they are, but I
can't comment on the namespace
On 30-Jan-00 Josef Karthauser wrote:
On Fri, Jan 28, 2000 at 08:30:55PM -0500, John Baldwin wrote:
I don't think we should change yet another thing before a release. The
problem shouldn't have been created this close to a release in the first
place. We have to stop somewhere, and I
On Sun, Jan 30, 2000 at 04:51:44PM -0500, John Baldwin wrote:
[cut]
With that in mind, the upgrade path is only going
to be broken for a few people who should be reading -current and thus
know how to work around the problem, so I repeal my request for the
changes to be backed out. My
On 29-Jan-00 Bruce Evans wrote:
On Fri, 28 Jan 2000, John Baldwin wrote:
...
Solution:
We need statically built install tools just like we have build tools.
I think we should use the newer versions (i.e. static versions of the
ones we just built under /usr/obj during buildworld that are
In the cross-build case, I would guess that the 'make installworld'
could be run on either machine. It would depend upon which way the
mounts are done. Is the host machine mounted on the target machine or
the other way around. Some people strongly believe it should be one way
or the other.
-On [2128 19:30], John Baldwin ([EMAIL PROTECTED]) wrote:
=== bin/rcp
install -c -s -o root -g wheel -m 4555 -fschg rcp /bin
/usr/libexec/ld-elf.so.1: install: Undefined symbol "string_to_flags"
*** Error code 1
Stop in /usr/src/bin/rcp.
*** Error code 1
This is indicative of a
On 28-Jan-00 Jeroen Ruigrok van der Werven wrote:
=== bin/pwd
install -c -s -o root -g wheel -m 555 pwd /bin
install -c -o root -g wheel -m 444 pwd.1.gz /usr/share/man/man1
=== bin/rcp
install -c -s -o root -g wheel -m 4555 -fschg rcp /bin
/usr/libexec/ld-elf.so.1: install: Undefined
On 28-Jan-00 Jeroen Ruigrok van der Werven wrote:
=== bin/pwd
install -c -s -o root -g wheel -m 555 pwd /bin
install -c -o root -g wheel -m 444 pwd.1.gz /usr/share/man/man1
=== bin/rcp
install -c -s -o root -g wheel -m 4555 -fschg rcp /bin
/usr/libexec/ld-elf.so.1: install:
On 28-Jan-00 Marcel Moolenaar wrote:
On 28-Jan-00 Jeroen Ruigrok van der Werven wrote:
=== bin/pwd
install -c -s -o root -g wheel -m 555 pwd /bin
install -c -o root -g wheel -m 444 pwd.1.gz /usr/share/man/man1
=== bin/rcp
install -c -s -o root -g wheel -m 4555 -fschg rcp /bin
Marcel Moolenaar wrote:
I already have patches (somewhere :-) that solve this problem. I choose not
to apply these before the release. I will fix installworld after the
release. For now, you can use the buildkernel and installkernel targets
(after a buildworld) to solve the (possibly
sgk wrote:
Marcel Moolenaar wrote:
I already have patches (somewhere :-) that solve this problem. I choose not
to apply these before the release. I will fix installworld after the
release. For now, you can use the buildkernel and installkernel targets
(after a buildworld) to solve the
I already have patches (somewhere :-) that solve this problem. I choose
not
to apply these before the release. I will fix installworld after the
release. For now, you can use the buildkernel and installkernel targets
(after a buildworld) to solve the (possibly complex) dependencies
On 28-Jan-00 Marcel Moolenaar wrote:
It's also related to the kernel, where installworld is installing and
subsequently running binaries that won't work with the current kernel. The
same applies to installing shared binaries and running them without the
proper libraries.
Ok, I'll buy that.
On Fri, 28 Jan 2000, John Baldwin wrote:
...
Solution:
We need statically built install tools just like we have build tools.
I think we should use the newer versions (i.e. static versions of the
ones we just built under /usr/obj during buildworld that are linked
against the new
19 matches
Mail list logo
