On (2002/11/12 22:17), Doug Barton wrote:
> In case another vote is needed, I've always been opposed to the wrapper.
> tobez and I put some work into getting the use.perl script in the port
> to DTRT shortly after the demise of base perl, and I'm still willing to
> help fine tune it if needed.
I
Galen Sampson wrote:
> One thing that I found interesting during mergemaster was the grouping of
> changes. For instance mergemaster determined that my /etc/group file was
> lacking some groups. The 4 groups that needed changing were on adjacent lines.
> Mergemaster gave me the option of mergin
Hello all,
After updating to -current sources last night I found that I can reproduce an
internal compiler error with my own source code. I'm not sure if it is related
to the internal compiler error people are having with the ports are not.
the command:
g++ -Wall -c btree.cpp
generates the e
suken woo wrote:
> In file included from
> ../../../../src/solaris/hpi/native_threads/src/threads_md.c:27:
> /usr/include/sys/resource.h:61: field `ru_utime' has incomplete type
> /usr/include/sys/resource.h:62: field `ru_stime' has incomplete type
"struct timeval" is not in scope.
Modify the fil
[ I don't want to hijack David Wolfskill's thread so I am starting a new one.
I did see David's problem (see his message ``Weird error during "make
installworld"'') but that one hasn't reappeared on my home system since I
rebooted after first seeing it. ]
===> share/zoneinfo
umask 022; cd /disk0/u
Loren James Rittle wrote:
> > FWIW: symbol versioning is incredibly broken. It attempts to
> > do in UNIX what interface versioning does in Windows, through
> > the use of class factories accessed via IUnknown.
>
> You might be absolutely correct in general. However, please read
> http://gcc.gnu
I've had a problem with a SuperMicro 2010H server crashing when
attempting to run an SMP kernel. I've noticed a lot of this lately,
but this seem to be crashing in the clock code. Below is the console
output from power-up to crash. If I use an UP kernel of the same
vintage there is no problem.
John Angelmo wrote:
This was posted earlier in [EMAIL PROTECTED]
Hello
I have a Compaq evo n115, everything seems to be found by FreeBSD-Current but the sound dosn't work
This seems to be the important part:
pcm0: port 0x1850-0x1853,0x1854-0x1857,0x1000-0x10ff irq 5 at device 7.5 on pci0
David O'Brien wrote:
>
> On Fri, Nov 08, 2002 at 08:58:44AM +, Mark Murray wrote:
> > IMVHO, the perl wrapper should be removed altogether, and the
> > perl port's "use.port" symlink-creating feature should be used
> > instead.
>
> Do we have consensus on this? The perl wrapper really isn't
On Sat, Nov 09, 2002 at 04:27:12PM +0100, Eirik Nygaard wrote:
> I have rewritten the rmuser.perl script into C. But got no experiense with at, and I
>see the the perl port got a function that removes any at jobs for the user being
>removed. So I wonderd if anyone could make a patch that does tha
On Tue, Nov 12, 2002 at 05:53:03PM -0800, Galen Sampson wrote:
> IIRC the old mergemaster merged changes like this one line at a time.
I don't recall it ever behaving this way, but I could be wrong.
Kris
msg46594/pgp0.pgp
Description: PGP signature
hi,all:
errors occurred during make with native_threads.
e -I../../../../src/share/hpi/export -D_REENTRANT -DNATIVE
-DUSE_PTHREADS -DMOOT
_PRIORITIES -DNO_INTERRUPTIBLE_IO-c -o
../../../../build/bsd-i386/tmp/java/h
pi/native_threads/obj/threads_md.o
../../../../src/solaris/hpi/native_threa
Hello all,
After looking in the mailling list archives for problems with mergemaster and
reading the man page I noticed the -p option. I have been building the world
with the sequence (as denoted in the handbook section 21.4):
"make buildworld, make buildkernel, make installkernel, reboot, make
Hello All,
I just cvsup'd -current last night and ran "make buildworld, make buildkernel,
make installkernel, reboot, make installworld, mergemaster" (thus updating my
system from a May -current).
One thing that I found interesting during mergemaster was the grouping of
changes. For instance mer
On Tue, 12 Nov 2002, Juli Mallett wrote:
> * De: Nate Lawson <[EMAIL PROTECTED]> [ Data: 2002-11-12 ]
> [ Subjecte: sleep(1) behavior ]
> > I've found an interesting contradiction and was wondering what behavior
> > sleep should have. It checks for a command line flag with getopt(3) and
> >
* De: Nate Lawson <[EMAIL PROTECTED]> [ Data: 2002-11-12 ]
[ Subjecte: sleep(1) behavior ]
> I've found an interesting contradiction and was wondering what behavior
> sleep should have. It checks for a command line flag with getopt(3) and
> exits with usage() if it finds one. However, it
I've found an interesting contradiction and was wondering what behavior
sleep should have. It checks for a command line flag with getopt(3) and
exits with usage() if it finds one. However, it then checks for a '-' or
'+' sign. If negative, it behaves like "sleep 0" and exits
immediately. This c
Is there any documentation of how to cross-build different versions of FreeBSD ?
- aW
Only if you unpack the contents of CDROM #2 from a -STABLE system
into a chroot environment.
Specifically, the compiler and FFS changes have added a number of
incompatabilities
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
< said:
> But why not just this?
> static __inline void
> __fd_zero(fd_set *p, __size_t n)
> {
> memset(p->fds_bits, 0, _howmany(n, _NFDBITS));
> }
Because a declaration of memset() is not permitted in that context.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROT
< said:
> /* 1003.2-1992 */
> -#if __POSIX_VISIBLE >= 199209
> +#if __POSIX_VISIBLE >= 199209 || __XSI_VISIBLE
> size_tconfstr(int, char *, size_t);
> int getopt(int, char * const [], const char *);
__XSI_VISIBLE should never be non-zero when __POSIX_VISIBLE is less
than 199506, so
> Marc Recht <[EMAIL PROTECTED]> writes:
> I've had the attached patch in my tree for a while. I'll try and get
> it and the patch committed today.
static __inline void
__fd_zero(fd_set *p, __size_t n)
{
n = _howmany(n, _NFDBITS);
while (n > 0)
< said:
> I'm thinking more of it like an aggregation. IMHO it should be possible,
> if the user wants to, to get POSIX 199506 and BSD.
That would be very difficult, since FreeBSD never supported that
version (indeed, never even claimed support for that version). In
order to make this happen, so
On Tue, Nov 12, 2002 at 10:58:12PM +, Mark Murray wrote:
> > On Tue, Nov 12, 2002 at 08:15:09AM -0500, Garance A Drosihn wrote:
> >
> > > I would rather have some explicit list of filenames where we have
> > > good reason to delete them, and then adapt the above script to at
> > > least tell t
One of the gohan machines apparently wedged up (the kernel was
running, but the network stack was not responding to connection
requests). Breaking into DDB from the console shows that the
following processes are running:
pid proc addruid ppid pgrp flag stat wmesgwchan cmd
7
> On Tue, Nov 12, 2002 at 08:15:09AM -0500, Garance A Drosihn wrote:
>
> > I would rather have some explicit list of filenames where we have
> > good reason to delete them, and then adapt the above script to at
> > least tell the user about the remaining files. Perhaps even delete
> > them, but o
On Tue, Nov 12, 2002 at 08:15:09AM -0500, Garance A Drosihn wrote:
> I would rather have some explicit list of filenames where we have
> good reason to delete them, and then adapt the above script to at
> least tell the user about the remaining files. Perhaps even delete
> them, but only *after*
I have been trying to cvsup since yesterday to get this fixed, so it
appears to still be broken, anyone else seeing this?
anding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-p
rototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -c /us
r/src/sys/dev
Sheldon Hearn wrote:
> It's a known problem. Consider reading the -current mailing list to
> keep up to date with known problems. It was discussed last week.
>
> No solution is known at this time. Use dd(1) instead of cp(1) as an
> interim workaround.
Actually, it's fixable 3 ways:
o Fu
Jason Vervlied wrote:
> I am having problems with a Samba share on my -current box, I just
> installed from 20021103-SNAP. I did recompile my kernel with the following
> options.
[ ... ]
> I also added the SMP options to the kernel. I used the same options under
> -stable and experineced no issue
On Tue, Nov 12, 2002 at 07:23:51PM +0100, Poul-Henning Kamp wrote:
> >I just tried this, and it seems to work fine.
> >So TSC seems to work, and i8254 does not seem to work.
>
> And ACPI doesn't work either, right ?
That's right, doing:
sysctl -w kern.timecounter.hardware=ACPI-safe
does not work
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
-
This email was sent
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
-
This email was sent
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
-
This email was sent
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
-
This email was sent
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
-
This email was sent
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
-
This email was sent
In message <[EMAIL PROTECTED]>, Craig Rodrigues writes:
>On Tue, Nov 12, 2002 at 05:44:36PM +, David Malone wrote:
>> On Tue, Nov 12, 2002 at 10:20:00AM -0500, Craig Rodrigues wrote:
>> > However, this fix (adding kern.timecounter.hardware=i8254 to /etc/sysctl.conf)
>> > does not seem to work a
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
-
This email was sent
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
FUCK SCOTT LONG AND FUCK BILL FUMEROLA
-
This email was sent
OK; this is a bit strange, and I've come up with a circumvention (read
"really ugly bloody hack"), but my real concern is that this may be a
manifestation or symptom of something broken in some subtle way. The
note is rather long- winded; sorry about that, but I didn't see a better
way to do this.
On Tue, Nov 12, 2002 at 05:44:36PM +, David Malone wrote:
> On Tue, Nov 12, 2002 at 10:20:00AM -0500, Craig Rodrigues wrote:
> > However, this fix (adding kern.timecounter.hardware=i8254 to /etc/sysctl.conf)
> > does not seem to work anymore. The clock still runs too fast.
>
> Could you try k
> On Tue, Nov 12, 2002 at 12:34:23PM +, Mark Murray wrote:
> > > Do we have consensus on this? The perl wrapper really isn't working out
> > > for all the cases I hoped it would when I committed it.
> >
> > Yes, I think so. DES (The author?) doesn't mind. I'm for removal and so is
> > Kris.
>
On Tue, Nov 12, 2002 at 10:20:00AM -0500, Craig Rodrigues wrote:
> However, this fix (adding kern.timecounter.hardware=i8254 to /etc/sysctl.conf)
> does not seem to work anymore. The clock still runs too fast.
Could you try kern.timecounter.hardware=TSC - this worked for someone
else sometime las
On Tue, Nov 12, 2002 at 12:34:23PM +, Mark Murray wrote:
> > Do we have consensus on this? The perl wrapper really isn't working out
> > for all the cases I hoped it would when I committed it.
>
> Yes, I think so. DES (The author?) doesn't mind. I'm for removal and so is
> Kris.
Why does DES
On Tue, Nov 12, 2002 at 05:18:13PM +0100, Poul-Henning Kamp wrote:
> Are you saying that the i8254 also runs twice as fast as it should ?
It looks like it. Here is some additional output from
dmesg. Does it give a clue?
Calibrating clock(s) ... TSC clock: 400911902 Hz, i8254 clock: 1193190 Hz
C
In message <[EMAIL PROTECTED]>, Tilman Linneweh writes:
>> I have a problem with my ASUS P5A-B motherboard, where the timer
>> runs too fast. This is with -CURRENT, cvsup'd from 1.5 weeks ago.
>>
>> I encountered this problem before, and found a fix which worke;:
>>
>http://docs.freebsd.org/cgi/
> I have a problem with my ASUS P5A-B motherboard, where the timer
> runs too fast. This is with -CURRENT, cvsup'd from 1.5 weeks ago.
>
> I encountered this problem before, and found a fix which worke;:
>
>http://docs.freebsd.org/cgi/getmsg.cgi?fetch=145760+0+archive/2002/freebsd-current/200209
Hi,
I have a problem with my ASUS P5A-B motherboard, where the timer
runs too fast. This is with -CURRENT, cvsup'd from 1.5 weeks ago.
I encountered this problem before, and found a fix which worke;:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=145760+0+archive/2002/freebsd-current/20020915.free
On Tue, Nov 12, 2002 at 15:28:41 +0100, Dag-Erling Smorgrav wrote:
> "Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> > There was USE_LASTLOG on the way, which is currently on and checked before
> > DISABLE_LASTLOG, so DISABLE_LASTLOG does nothing. See loginrec.c
>
> No, USE_LASTLOG is not defin
"Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> There was USE_LASTLOG on the way, which is currently on and checked before
> DISABLE_LASTLOG, so DISABLE_LASTLOG does nothing. See loginrec.c
No, USE_LASTLOG is not defined if DISABLE_LASTLOG is defined. See
defines.h.
DES
--
Dag-Erling Smorgra
On Tue, Nov 12, 2002 at 15:11:04 +0100, Dag-Erling Smorgrav wrote:
> Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> > I think the idea is that we should define NO_SSH_LASTLOG in config.h.
>
> Actually, I think the problem is that DISABLE_LASTLOG should imply
> NO_SSH_LASTLOG but doesn't.
There
Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> I think the idea is that we should define NO_SSH_LASTLOG in config.h.
Actually, I think the problem is that DISABLE_LASTLOG should imply
NO_SSH_LASTLOG but doesn't.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMA
"Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> It physically eliminates "Last loging" comes from sshd, but not fix wrong
> _time_ printed by print_pam_messages() in my case (first prompt), as I
> already write, there is JUST time, not LAST time.
That is a separate bug, probably in pam_lastlog.
On (2002/11/12 08:55), Jason Vervlied wrote:
> I am having problems with a Samba share on my -current box, I just
> installed from 20021103-SNAP. I did recompile my kernel with the following
> options.
I'll bet your problem as nothing to do with Samba. What you have is a
problem with smbfs.
> H
I am having problems with a Samba share on my -current box, I just
installed from 20021103-SNAP. I did recompile my kernel with the following
options.
options SMBFS
options NETSMB
options NETSMBCRYPTO
options LIBMCHAIN
options LIBICONV
I also added the SMP
On Tue, Nov 12, 2002 at 14:47:51 +0100, Dag-Erling Smorgrav wrote:
> "Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> > BTW, double-testes options.print_lastlog looks suspiciuos. For what
> > print_pam_messages() used here? It is unclear to me.
>
> I think the idea is that we should define NO_SS
"Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> BTW, double-testes options.print_lastlog looks suspiciuos. For what
> print_pam_messages() used here? It is unclear to me.
I think the idea is that we should define NO_SSH_LASTLOG in config.h.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To U
On Tue, Nov 12, 2002 at 14:26:58 +0100, Dag-Erling Smorgrav wrote:
> pam.d is not relevant, sshd_config is.
I sent it to you privately.
> des@des ~% ssh localhost
> Last login: Tue Nov 12 14:25:39 2002 from :0.0
It is "Last login" with right time comes from sshd itself (second in my
case). It m
"Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> I have standard /etc/pam.d from latest -current.
pam.d is not relevant, sshd_config is.
> Before I'll send you my /etc/ssh config, I think there is more simple way
> to find it out.
>
> I have a question: which one prompt _you_ have?
des@des ~%
At 11:13 PM + 11/8/02, Mark Murray wrote:
> > I mean *all* the cruft -- old modules and config files,
> > deprecated binaries and man pages, even old shlibs if it's safe.
>
> I agree with you, and I was giving an example that a lesser
> form of this is already required during the upgrade.
On Tue, Nov 12, 2002 at 14:01:43 +0100, Dag-Erling Smorgrav wrote:
> "Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> > On Tue, Nov 12, 2002 at 12:37:13 +0100, Dag-Erling Smorgrav wrote:
> > > "Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> > > > Old bugfix for double "Last login:" was spammed i
"Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> On Tue, Nov 12, 2002 at 12:37:13 +0100, Dag-Erling Smorgrav wrote:
> > "Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> > > Old bugfix for double "Last login:" was spammed in 3rd time, causing
> > > following printout:
> > I can't reproduce this h
On Tue, Nov 12, 2002 at 12:37:13 +0100, Dag-Erling Smorgrav wrote:
> "Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> > Old bugfix for double "Last login:" was spammed in 3rd time, causing
> > following printout:
>
> I can't reproduce this here.
Look at session.c, one "Last login" comes from
> On Fri, Nov 08, 2002 at 08:58:44AM +, Mark Murray wrote:
> > IMVHO, the perl wrapper should be removed altogether, and the
> > perl port's "use.port" symlink-creating feature should be used
> > instead.
>
> Do we have consensus on this? The perl wrapper really isn't working out
> for all th
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
"Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> Old bugfix for double "Last login:" was spammed in 3rd time, causing
> following printout:
I can't reproduce this here.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-curr
This was posted earlier in [EMAIL PROTECTED]
Hello
I have a Compaq evo n115, everything seems to be found by FreeBSD-Current but the
sound dosn't work
This seems to be the important part:
pcm0: port 0x1850-0x1853,0x1854-0x1857,0x1000-0x10ff irq 5 at device
7.5 on pci0
So that works, but
Well I'm not getting Hard Locks when I try running dnet on a
SMP kernel. Instead I've gotten the following panics.
It turns out I can run a single non threaded dnet process when
I invoke it thus: 'dnet -cpunum 0'
-
lock order rev
On Fri, Nov 08, 2002 at 08:58:44AM +, Mark Murray wrote:
> IMVHO, the perl wrapper should be removed altogether, and the
> perl port's "use.port" symlink-creating feature should be used
> instead.
Do we have consensus on this? The perl wrapper really isn't working out
for all the cases I hope
David Wolfskill wrote:
Did you remember to create /boot/device.hints?
Cheers,
david
Hi,
the file didn't exist so i just copied the /usr/src/sys/i386/conf/GENERIC.hints
to /boot/device.hints. I think it is ok because i compiled the GENERIC-kernel.
Unfortunately it doesn't help. The machine hang
Hello,
I believe that everybody here knows about the "slow msdosfs" problem, that
is AFAIK caused by implementation without clustering.
For me this is very annoying, because I use digital camera, and ZIP drive,
and FAT on both of them. Speed is about 10 times lower than it could be..
I would like
"Wilkinson,Alex" wrote:
> In a dual boot situation, is it possible to be logged into -CURRENT and
> build -STABLE ( ie -STABLE filesystems live on separate fdisk partitions
> and are exported ) ?
Only if you unpack the contents of CDROM #2 from a -STABLE system
into a chroot environment.
Specific
Loren James Rittle wrote:
> FYI, the libstdc++-v3 maintainers on the FSF side are only
> guaranteeing forward ABI compatibility of any sort if libstdc++.so is
> built with symbol versioning and symbol hiding.
FWIW: symbol versioning is incredibly broken. It attempts to
do in UNIX what interface v
74 matches
Mail list logo
