essary fstatfs() calls and use mmap() based on
> >>> size").
> >>>
> >>> If you only revert usr.bin/xinstall to r366696, and then rebuild it,
> >>> does it still occur?
> >>>
> >>> -Dimitry
> >>
> >> T
tfs() calls and use mmap() based on
size").
If you only revert usr.bin/xinstall to r366696, and then rebuild it,
does it still occur?
-Dimitry
Thank you!
Success with r366696:
…
Re:
<https://lists.freebsd.org/pipermail/freebsd-current/2020-November/077634.html>
please, shoul
t;).
If you only revert usr.bin/xinstall to r366696, and then rebuild it,
does it still occur?
-Dimitry
Thank you!
Success with r366696:
…
Re:
<https://lists.freebsd.org/pipermail/freebsd-current/2020-November/077634.html>
please, should I open a bug for this?
Is the issue
On 22/11/2020 12:00, Dimitry Andric wrote:
…
I'd guess it's an unintended side-effect of
https://svnweb.freebsd.org/base?view=revision&revision=366697
("install(1): Avoid unncessary fstatfs() calls and use mmap() based on
size").
If you only revert usr.bin/xinstall to r
On Wed, 20 Mar 2002, Ruslan Ermilov wrote:
> On Mon, Mar 18, 2002 at 03:26:13PM -0800, Dag-Erling Smorgrav wrote:
> > des 2002/03/18 15:26:13 PST
> >
> > Modified files:
> > usr.bin/xinstall xinstall.c
> > Log:
> > Bump the cutoff mark
Ruslan Ermilov <[EMAIL PROTECTED]> writes:
> OK, I think it's finally the time to borrow mmap(2) comparison in
> chunks from OpenBSD (better viewed as -w diff):
What are you waiting for? Commit! :)
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
w
On Mon, Mar 18, 2002 at 03:26:13PM -0800, Dag-Erling Smorgrav wrote:
> des 2002/03/18 15:26:13 PST
>
> Modified files:
> usr.bin/xinstall xinstall.c
> Log:
> Bump the cutoff mark for comparing files from 8 MB to 16 MB.
>
> Revision Changes
On Tue, Feb 08, 2000 at 11:03:48AM -0700, Warner Losh wrote:
> In message <[EMAIL PROTECTED]>
>Kai=?iso-8859-1?q?_Gro=DFjohann?= writes:
> : Hm. Upon closer inspection, you're right. The following entry has
> : this:
>
> I had thought to put something like
>
> : /
> : | 19990929:
> : |
In message <[EMAIL PROTECTED]> Kai=?iso-8859-1?q?_Gro=DFjohann?=
writes:
: Hm. Upon closer inspection, you're right. The following entry has
: this:
I had thought to put something like
: /
: | 19990929:
: | The sigset_t datatype has been changed from an integral type
: | t
On Tue, Feb 08, 2000 at 01:54:31PM +0100, Kai Gro?johann wrote:
> "Daniel C. Sobral" <[EMAIL PROTECTED]> writes:
>
> > Kai Gro?johann wrote:
> > >
> > > I now think that I should have made a new kernel, first.
> > >
> > > Hm. The file /usr/src/UPDATING doesn't say that I should,[...]
> >
> >
"Daniel C. Sobral" <[EMAIL PROTECTED]> writes:
> Kai Großjohann wrote:
> >
> > I now think that I should have made a new kernel, first.
> >
> > Hm. The file /usr/src/UPDATING doesn't say that I should,[...]
>
> UPDATING does say you need to do that.
Hm. Upon closer inspection, you're right.
Kai Großjohann wrote:
>
> I now think that I should have made a new kernel, first.
>
> Hm. The file /usr/src/UPDATING doesn't say that I should, so maybe I
> can be forgiven for not knowing, and there's nothing in Chapter 17 of
> the Handbook, either.
>
> Do you think making a kernel first wil
[EMAIL PROTECTED] (Kai Großjohann) writes:
> I used my running 3.4 stable to run `make buildworld' on the sources
> from 2000-02-04 or so. I ran across the xinstall problem but worked
> around it, then tried `make installworld', which failed and hosed my
> machine. In o
I used my running 3.4 stable to run `make buildworld' on the sources
from 2000-02-04 or so. I ran across the xinstall problem but worked
around it, then tried `make installworld', which failed and hosed my
machine. In order to make sure that the xinstall workaround wasn't
On Sat, 5 Feb 2000, David O'Brien wrote:
> On Sat, Feb 05, 2000 at 09:51:25AM -0500, John Baldwin wrote:
> > David O`Brien's are probably the easiest:
> > If installworld breaks, then do this:
> >
> > make -k installworld
> > make installworld
>
> Sounds like this should be updated to be:
>
>
This won't give you a statically linked install. You might try adding
'NOSHARED=yes' to the make command below.
Jim Bloom
[EMAIL PROTECTED]
Josef Karthauser wrote:
>
> I've committed the fix. Another way of not tripping over problems is:
>
> # cd /usr/src
;
> make -k installworld
> make installworld
I've committed the fix. Another way of not tripping over problems is:
# cd /usr/src/usr.bin/xinstall
# make clean depend all install
This'll give you an install that's statically linked.
If your install program is already broken
On Sat, Feb 05, 2000 at 09:51:25AM -0500, John Baldwin wrote:
> David O`Brien's are probably the easiest:
> If installworld breaks, then do this:
>
> make -k installworld
> make installworld
Sounds like this should be updated to be:
make -k -DNOFSCHG installworld
make installworld
--
-
ready be in /usr/lib), and the second install
world will complete successfully.
This is my last message on xinstall topic! I'm shutting up...
--
Ruslan Ermilov Sysadmin and DBA of the
[EMAIL PROTECTED]United Commercial Bank,
[EMAIL PROTECTED] FreeBSD
On 04-Feb-00 Ruslan Ermilov wrote:
> Could you please provide then *right* instructions for UPDATING?
David O`Brien's are probably the easiest:
If installworld breaks, then do this:
make -k installworld
make installworld
>> I don't think this needs to be in 4.0. xinstall
On Fri, 4 Feb 2000, John Baldwin wrote:
> >An even easier solution would be to get rid of setflags entirely
> >and put it back in the original sources that embedded it.
>
> Umm, that's bascially what Joe's currently proposed patch does.
>
> /me sighs
>
But that would not fix the insta
On 05-Feb-00 Matthew Dillon wrote:
>:This has an easy solution. One, get rid of setflags usage by reverting
>:the Makefiles somewhat. Two, remove setflags from the headers. Three,
>:make libc have an _XXX_setflags and __weak_reference() it to setflags.
>:This won't break anyone, or make apps n
:This has an easy solution. One, get rid of setflags usage by reverting
:the Makefiles somewhat. Two, remove setflags from the headers. Three,
:make libc have an _XXX_setflags and __weak_reference() it to setflags.
:This won't break anyone, or make apps not be able to use [gs]etflags.
:
:Of cou
On Fri, 4 Feb 2000, John Baldwin wrote:
> > 2. Right after we resolve this issue, your patch (provided that you
> >fix errors Bruce pointed out), should be committed to make it
> >possible to compile -current xinstall in a host environment, e.g.
> >from 3.x (
gt; > Might I advice some more time before we actually do something?
> >> > >
> >> > > What's all this rush-it-in before anyone can actually fix the larger
> >> > > problem?
> >> > >
> >> > I'm positive about
>> > > What's all this rush-it-in before anyone can actually fix the larger
>> > > problem?
>> > >
>> > I'm positive about this as well.
>> >
>>
>> The main reason for the backout isn't the xinstall problem, as this
before anyone can actually fix the larger
> > > problem?
> > >
> > I'm positive about this as well.
> >
>
> The main reason for the backout isn't the xinstall problem, as this
> is a non-problem (it only affects a small window of -current users).
>
Hmm
On Fri, 4 Feb 2000, Marcel Moolenaar wrote:
> The patch looks good, but contains style (ordering) bugs :-)
> I can't actually test the patch, but assume that's been done.
It also contains style (syntax) bugs. `extern' declarations of
functions are not KNF. They are only only necessary to suppo
the larger
> > > problem?
> > >
> > I'm positive about this as well.
> >
>
> The main reason for the backout isn't the xinstall problem, as this
> is a non-problem (it only affects a small window of -current users).
> The reason for adoptin
Josef Karthauser wrote:
> The reason for adopting a fall back solution it that it is not clear that
> setflags/getflags is the best choice of function name for manipulating
> file flags as it's a bit too generic a name. Whilst we're debating
> this point there's no point in having them as librar
about this as well.
>
The main reason for the backout isn't the xinstall problem, as this
is a non-problem (it only affects a small window of -current users).
The reason for adopting a fall back solution it that it is not clear that
setflags/getflags is the best choice of function name for ma
Out of da blue Matt M. aka ([EMAIL PROTECTED]) said:
> I keep seeing stuff about xinstall on this list, but I haven't read anything
> about it anywhere in any of the docs. What is it and should I know about it?
xinstall is the name of the directory and c source file for /usr/bin/instal
I keep seeing stuff about xinstall on this list, but I haven't read anything
about it anywhere in any of the docs. What is it and should I know about it?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
33 matches
Mail list logo
