exp.c: In function `main':
exp.c:4: warning: declaration of `exp' shadows a global declaration
built-in:0: warning: shadowed declaration is here
--
Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc.
[EMAIL PROTECTED] // FreeBSD Project
___
[EMAIL
With new gcc and -Wshadow, src/bin/ed/re.c shows this warning:
cc -Wshadow -c re.c
re.c: In function `get_compiled_pattern':
re.c:44: warning: declaration of `exp' shadows a global declaration
built-in:0: warning: shadowed declaration is here
It seems local variable exp is conflicted with exp(3
On Tue, 15 Jul 2003, Jun Kuriyama wrote:
JK
JKWith new gcc and -Wshadow, src/bin/ed/re.c shows this warning:
JK
JKcc -Wshadow -c re.c
JKre.c: In function `get_compiled_pattern':
JKre.c:44: warning: declaration of `exp' shadows a global declaration
JKbuilt-in:0: warning: shadowed declaration
If you reinstalled libc with the previous version of ttyname.c your
sshd will likely get confused and refuse access.
Apologies...
Poul-Henning
In message [EMAIL PROTECTED], Poul-Henning Kamp
writes:
phk 2003/06/21 01:16:12 PDT
FreeBSD src repository
Modified files:
Hello,
how can i resolv this warning ?
Gdk-WARNING **: Missing charsets in FontSet creation
i have starting and reciving message with gaim
thanks !
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
On Tue, 2003-06-17 at 14:48, Blaise Takoudjou wrote:
Hello,
how can i resolv this warning ?
Gdk-WARNING **: Missing charsets in FontSet creation
i have starting and reciving message with gaim
This really isn't appropriate to the current@ mailing list. However,
this might be fixed
I've cvsuped to -current from 11-12 march and afer booting new kernel got
repeated messages from kernel to syslog and console.
Mar 13 13:50:38 ws-ilmar kernel: malloc() of 128 with the following
non-sleepablelocks held:
Mar 13 13:50:38 ws-ilmar kernel: exclusive sleep mutex dc0 (network
driver)
Garrett Wollman wrote:
`#if __GNUC__' wouldn't help matters; every preprocessor has to read
and interpret every preprocessor directive (so that `#else' and
`#endif' can be recognized).
I thought that the other discussion had concluded that:
#if 0
...
#else
Or:
Craig Rodrigues wrote:
In sys/syslimits.h, I see:
#if __GNUC__
#warning No user-serviceable parts inside.
#endif
Does the use of #warning need to be protected by
#if __GNUC__ in FreeBSD header files?
Yes. It is a preprocessor directive specific the GCC preprocessor.
This was discussed
Starting today I noticed this warning at bootup:
WARNING: Driver mistake: make_dev(console) called before SI_SUB_DRIVERS
Is there more info I should supply?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
In message [EMAIL PROTECTED], walt writes:
Starting today I noticed this warning at bootup:
WARNING: Driver mistake: make_dev(console) called before SI_SUB_DRIVERS
Is there more info I should supply?
Ooops. No, that is plenty. I'll fix it.
--
Poul-Henning Kamp | UNIX since Zilog Zeus
Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], walt writes:
Starting today I noticed this warning at bootup:
WARNING: Driver mistake: make_dev(console) called before SI_SUB_DRIVERS
Is there more info I should supply?
Ooops. No, that is plenty. I'll fix it.
Yes, fixed now. Thanks
On Sat, 8 Mar 2003 11:19:43 -0500, Craig Rodrigues [EMAIL PROTECTED] said:
Does the use of #warning need to be protected by
#if __GNUC__ in FreeBSD header files?
No, it needs to be replaced by the standard `#error' directive
instead. I asked portmgr to do a run on the portsd cluster
In the last episode (Mar 08), Garrett Wollman said:
On Sat, 8 Mar 2003 11:19:43 -0500, Craig Rodrigues [EMAIL PROTECTED] said:
Does the use of #warning need to be protected by
#if __GNUC__ in FreeBSD header files?
No, it needs to be replaced by the standard `#error' directive
instead. I
upon it anyway? One can even claim that emitting an error or warning *is*
reaction upon the directive.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
preprocessors should interpret directives when they
are dead (ie part of an #if block or #else block that is not to
be compiled).
I tried to use this once, on a cross-platform program I wrote. I
can tell you that some compilers will choke on a #warning, even if
it is inside a #if/#endif. And other
At 2:33 PM -0500 3/8/03, Garance A Drosihn wrote:
By adding that #warning, you are going to have a compile-time error
on some compilers, whether or not you want it. Hiding it inside of
an #if/#endif will help for some compilers, but not on all of them.
Er, I should note that I do like the idea
Garance A Drosihn wrote:
At 2:33 PM -0500 3/8/03, Garance A Drosihn wrote:
By adding that #warning, you are going to have a compile-time error
on some compilers, whether or not you want it. Hiding it inside of
an #if/#endif will help for some compilers, but not on all of them.
Er, I
On Sat, Mar 08, 2003 at 11:19:43AM -0500, Craig Rodrigues wrote:
Hi,
In sys/syslimits.h, I see:
#if __GNUC__
#warning No user-serviceable parts inside.
#endif
Does the use of #warning need to be protected by
#if __GNUC__ in FreeBSD header files? I am working
on something similar
Hi,
In sys/syslimits.h, I see:
#if __GNUC__
#warning No user-serviceable parts inside.
#endif
Does the use of #warning need to be protected by
#if __GNUC__ in FreeBSD header files? I am working
on something similar for machine/limits.h.
Some other header files check for __GNUC__ before using
it would be a good idea to include a warning in
/usr/share/examples/etc/make.conf that says CPUTYPE optimizations may
result in broken code. Maybe it's just my machine, but I've recompiled
several times now and it's consistent (if and only if I build and
install world with CPUTYPE=p4 is the problem
Hi
Just did the following:
dd if=/dev/zero of=/dev/da1 bs=1k count=512 #remove old stuff
fdisk -I da1#cover the entire disk with one da1s1 slice
fdisk da1 #check what's put there
disklabel -rw da1s1 auto#install virgin disklabel
disklabel -e da1s1 #add partition e:,
On Mon, 18 Nov 2002, Vallo Kallaste wrote:
Hi
Just did the following:
dd if=/dev/zero of=/dev/da1 bs=1k count=512 #remove old stuff
fdisk -I da1#cover the entire disk with one da1s1 slice
fdisk da1 #check what's put there
disklabel -rw da1s1 auto#install virgin
heads=255 sectors/track=63 (16065 blks/cyl)
parameters to be used for BIOS calculations are:
cylinders=554 heads=255 sectors/track=63 (16065 blks/cyl)
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid
fstype [fsize bsize bps/cpg]
c: 8899947 63unused0 0 # (Cyl.0*- 553*)
e: 8899947 634.2BSD0 0 0 # (Cyl.0*- 553*)
partition c: partition extends past end of unit
Warning, partition c doesn't start at 0!
Warning
On Mon, Nov 18, 2002 at 01:00:37PM -0800, Julian Elischer
[EMAIL PROTECTED] wrote:
[snip]
In pre-geom days we had a realhack (TM) that would fiddle the
label if you read it direct from the disk. In other words
it fixed it to always look (u relative I think) even if you
read it from
On Mon, 18 Nov 2002, Vallo Kallaste wrote:
On Mon, Nov 18, 2002 at 01:00:37PM -0800, Julian Elischer
[EMAIL PROTECTED] wrote:
[snip]
In pre-geom days we had a realhack (TM) that would fiddle the
label if you read it direct from the disk. In other words
it fixed it to always look
In message: [EMAIL PROTECTED]
Vallo Kallaste [EMAIL PROTECTED] writes:
: partition c: partition extends past end of unit
: Warning, partition c doesn't start at 0!
: Warning, An incorrect partition c may cause problems for standard system utilities
: partition e: partition extends past
Juli Mallett wrote:
find_dependcyType: application/x-java-applet
[ ... ]
It's a bourne shell script, terry, try looking at it.
Then the MIME type is wrong. Certainly, the disposition inline
is wrong.
I've been bombarded with all sorts of crap like this lately
which were DDOS client
Try this then:
#!/bin/sh
#Default options
LINTCONF=LINT.CONF
LINTCONF1=LINT.CONF1
ARCH=`uname -m`
ARCH1=$ARCH
SRCDIR=/sys
START=0
END=0
NOCLEAN=0
TMPDIR=/tmp/makedepend
WD=`pwd`
#Read the command line
while [ $# -ne 0 ]
do
case $1 in
--src-dir)
Andrew Turner wrote:
Name: find_dependcy
find_dependcyType: application/x-java-applet
Encoding: base64
This posting is a Java applet with inline disposition. Do not
* De: Terry Lambert [EMAIL PROTECTED] [ Data: 2002-10-16 ]
[ Subjecte: WARNING: Re: Kernel option dependency finding ]
Andrew Turner wrote:
Name: find_dependcy
find_dependcy
/dev/ccd/ccd.c:1181: warning: long long int format, daddr_t arg (arg
6)
*** Error code 1
This is a routine printf format error. %lld format should only be used
for printing long longs (which should never be used). Here the type is
daddr_t, which happens to be int64_t, which happens to be plain
Bruce Evans wrote:
cc1: warnings being treated as errors
/local0/src2/sys/dev/ccd/ccd.c: In function `ccdiodone':
/local0/src2/sys/dev/ccd/ccd.c:1181: warning: long long int format, daddr_t arg
(arg 6)
*** Error code 1
This is a routine printf format error. %lld format should only
How are you supposed to disable -Werror in kernel builds? Setting
NO_WERROR in the env or passing it to 'make buildkernel' via -D
doesn't work; neither does putting -Wno-error in COPTFLAGS. I get the
following fatal warning when compiling a recent alpha 5.0 kernel under
4.x:
cc -c -O -pipe
On Thu, 12 Sep 2002, Kris Kennaway wrote:
How are you supposed to disable -Werror in kernel builds? Setting
NO_WERROR in the env or passing it to 'make buildkernel' via -D
doesn't work; neither does putting -Wno-error in COPTFLAGS. I get the
following fatal warning when compiling a recent
On Thu, Sep 12, 2002 at 01:52:40PM -0700, Nate Lawson wrote:
NO_WERROR was removed so the only way is to set in your make.conf:
WERROR=
This causes the WERROR?=-Werror to not set the flag.
Thanks, Bill Fenner also told me this on IRC. The directions in
/usr/src/UPDATING need to be fixed
Kris Kennaway [EMAIL PROTECTED] writes:
On Thu, Sep 12, 2002 at 01:52:40PM -0700, Nate Lawson wrote:
(who wants NO_WERROR back or better, warns-clean code more often in
-current)
NO_WERROR is standard in userland; it should work in the kernel too.
Peter removed support for this a while
On Thu, Sep 12, 2002 at 01:27:50PM -0700, Kris Kennaway wrote:
How are you supposed to disable -Werror in kernel builds? Setting
NO_WERROR in the env or passing it to 'make buildkernel' via -D
doesn't work; neither does putting -Wno-error in COPTFLAGS. I get the
following fatal warning when
putting -Wno-error in COPTFLAGS. I get the
following fatal warning when compiling a recent alpha 5.0 kernel under
4.x:
Exactly how were you compiling this? `make buildworld kernel'? Or just
straight compile of the kernel? If the latter I would expect that not to
work too much longer as we
make warning
/usr/ports/Mk/bsd.port.mk, line 2580: warning: duplicate script for
target patch-message ignored
breaks portupgrade of several ports
portupgrade says that Makefile broken on these ports
(I'm not subscribed to freebsd-ports so reply direct, please)
Sincerely, Maxim M. Kazachek
On Fri, Aug 09, 2002 at 07:41:44AM +0200, John Hay wrote:
Hi Ruslan,
During make release I see a lot of these messages:
#
make: no target to make.
/usr/src/Makefile.inc1, line 140: warning: make -f /dev/null -m /usr/src/shar
e/mk CPUTYPE=i386 -V CPUTYPE returned non-zero
On Fri, Aug 09, 2002 at 07:41:44AM +0200, John Hay wrote:
Hi Ruslan,
During make release I see a lot of these messages:
#
make: no target to make.
/usr/src/Makefile.inc1, line 140: warning: make -f /dev/null -m /usr/src/shar
e/mk CPUTYPE=i386 -V CPUTYPE returned
I've switched one of my desktops to using kdm and I've noticed that
w(1) creates suprious warnings because it can't find the tty entry.
$ w
w: /dev/:0: No such file or directory
w: /dev/:0: No such file or directory
2:41AM up 49 mins, 0 users, load averages: 0.05, 0.04, 0.04
USER
Hi Ruslan,
During make release I see a lot of these messages:
#
make: no target to make.
/usr/src/Makefile.inc1, line 140: warning: make -f /dev/null -m /usr/src/shar
e/mk CPUTYPE=i386 -V CPUTYPE returned non-zero status
make: no target to make.
/usr/src/Makefile.inc1, line 140
On Jun 7, 2002 01:27:31 pm +0200, Cyrille Lefevre wrote:
On Fri, Jun 07, 2002 at 02:15:09AM -0400, Trevor Johnson wrote:
Dan Nelson wrote:
[snip]
According to Mr. Schilling's testing, GNU tar 1.13.25 has a bug:
ftp://ftp.fokus.gmd.de/pub/unix/star/testscripts/README.gtarfail . I guess
PS : I've finished to merge diffs from OpenBSD last week, but diffs
w/ NetBSD are really big... so, be patient :P
What about bin/35886?
Björn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
On Wed, Jun 12, 2002 at 03:07:45AM +0200, Bjoern Fischer wrote:
PS : I've finished to merge diffs from OpenBSD last week, but diffs
w/ NetBSD are really big... so, be patient :P
What about bin/35886?
already done using the NetBSD way. the problem is that they use
LC_TIME (hugh!) to pass
On Wed, Jun 12, 2002 at 04:27:19AM +0200, Cyrille Lefevre wrote:
[...]
already done using the NetBSD way. the problem is that they use
LC_TIME (hugh!) to pass the format string to strftime while
LC_TIME isn't suppose to contain any format strings but a locale
name.
Ew! That won't work for my
On Fri, Jun 07, 2002 at 02:15:09AM -0400, Trevor Johnson wrote:
On my friend's BSD/OS system, there is no tar--or rather, it's just a hard
link to pax:
% ls -li `which tar` `which pax`
1819 -r-xr-xr-x 2 bin bin 58288 Jun 12 1998 /bin/pax
1819 -r-xr-xr-x 2 bin bin
On Fri, Jun 07, 2002 at 02:15:09AM -0400, Trevor Johnson wrote:
Dan Nelson wrote:
[snip]
According to Mr. Schilling's testing, GNU tar 1.13.25 has a bug:
ftp://ftp.fokus.gmd.de/pub/unix/star/testscripts/README.gtarfail . I guess
it qualifies as a non-trivial program. :-)
FYI, the current pax
Hi,
I've just noticed that something wrong with the new tar in the base
system (1.13.25) - when extracting some archives it creates 777 dirs,
while permissions in the archive itself are OK (for example GNU make
make-3.79.1.tar.gz - top level dir gets 777 as well as several
other lowel level
Hi,
I've just noticed that something wrong with the new tar in the base
system (1.13.25) - when extracting some archives it creates 777 dirs,
while permissions in the archive itself are OK (for example GNU make
make-3.79.1.tar.gz - top level dir gets 777 as well as several
other lowel
I've just noticed that something wrong with the new tar in the base
system (1.13.25) - when extracting some archives it creates 777 dirs,
while permissions in the archive itself are OK (for example GNU make
make-3.79.1.tar.gz - top level dir gets 777 as well as several
other lowel level
In the last episode (Jun 06), Trevor Johnson said:
I've just noticed that something wrong with the new tar in the base
system (1.13.25) - when extracting some archives it creates 777 dirs,
while permissions in the archive itself are OK (for example GNU make
make-3.79.1.tar.gz - top level
Dan Nelson wrote:
Tar 1.13 is 3 years old, and has many bugs (incremental backups are
unusable, for example).
On the flip side, I hear it respects the umask when running as root...
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the
Hi,
I've just noticed that something wrong with the new tar in the base
system (1.13.25) - when extracting some archives it creates 777 dirs,
while permissions in the archive itself are OK (for example GNU make
make-3.79.1.tar.gz - top level dir gets 777 as well as several
Dan Nelson wrote:
The latest version on ftp://ftp.gnu.org/gnu/tar/ is 1.13. The ones on
ftp://alpha.gnu.org/gnu/tar/ (and everything else on that site) are
considered unstable. I suppose it's too late to suggest tar 1.13 as a
starting point, but maybe this could be kept in mind when
The following message had attachment(s) which contained the viruses:
From : [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject : ÀÖ½À´Ï´Ù
Date :
Message-ID:
AttachmentVirus name Action taken
I cvsuped again. Got the vm_map.c now compiled but now
kernel compilation stops somehwere in ipv6 files.
Can one switch off compiler pickyness?
--
Chris Christoph P. U. Kukulies [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of
On Tue, Mar 19, 2002 at 09:11:05PM +0100, Christoph Kukulies wrote:
I cvsuped again. Got the vm_map.c now compiled but now
kernel compilation stops somehwere in ipv6 files.
Can one switch off compiler pickyness?
From /usr/src/UPDATING:
20020225:
Warnings are now errors in the
On Tue, Mar 19, 2002 at 09:11:05PM +0100, Christoph Kukulies wrote:
I cvsuped again. Got the vm_map.c now compiled but now
kernel compilation stops somehwere in ipv6 files.
Can one switch off compiler pickyness?
Go back and read what config(8) is telling you, it's right there in
front of
On Tue, 19 Mar 2002 12:16:05 PST, Kris Kennaway wrote:
Go back and read what config(8) is telling you, it's right there in
front of you!
You shouldn't be too hard on people about missing config(8)'s output,
given that it's buried if you use the buildkernel target, as
recommended.
Ciao,
On Tue, Mar 19, 2002 at 10:36:15PM +0200, Sheldon Hearn wrote:
On Tue, 19 Mar 2002 12:16:05 PST, Kris Kennaway wrote:
Go back and read what config(8) is telling you, it's right there in
front of you!
You shouldn't be too hard on people about missing config(8)'s output,
given that
On 17-Mar-2002 Robert Watson wrote:
On Sun, 17 Mar 2002, Alfred Perlstein wrote:
* Munehiro Matsuda [EMAIL PROTECTED] [020317 06:36] wrote:
PS. I got another message that happend when I ^C'ed a buildworld earlier,
with same kernel. May be it should go to Alfred Perlstein?
lock
* John Baldwin [EMAIL PROTECTED] [020318 10:24] wrote:
On 17-Mar-2002 Robert Watson wrote:
On Sun, 17 Mar 2002, Alfred Perlstein wrote:
* Munehiro Matsuda [EMAIL PROTECTED] [020317 06:36] wrote:
PS. I got another message that happend when I ^C'ed a buildworld earlier,
with
On 18-Mar-2002 Alfred Perlstein wrote:
* John Baldwin [EMAIL PROTECTED] [020318 10:24] wrote:
On 17-Mar-2002 Robert Watson wrote:
On Sun, 17 Mar 2002, Alfred Perlstein wrote:
* Munehiro Matsuda [EMAIL PROTECTED] [020317 06:36] wrote:
PS. I got another message that happend
* Munehiro Matsuda [EMAIL PROTECTED] [020317 06:36] wrote:
PS. I got another message that happend when I ^C'ed a buildworld earlier,
with same kernel. May be it should go to Alfred Perlstein?
lock order reversal
1st 0xc198eec0 pipe mutex @ ../../../kern/sys_pipe.c:779
2nd 0xc0367fe0
On Sun, 17 Mar 2002, Alfred Perlstein wrote:
* Munehiro Matsuda [EMAIL PROTECTED] [020317 06:36] wrote:
PS. I got another message that happend when I ^C'ed a buildworld earlier,
with same kernel. May be it should go to Alfred Perlstein?
lock order reversal
1st 0xc198eec0 pipe
* Robert Watson [EMAIL PROTECTED] [020317 09:08] wrote:
On Sun, 17 Mar 2002, Alfred Perlstein wrote:
* Munehiro Matsuda [EMAIL PROTECTED] [020317 06:36] wrote:
PS. I got another message that happend when I ^C'ed a buildworld earlier,
with same kernel. May be it should go to
Apparently, On Sun, Mar 17, 2002 at 09:17:22AM -0800,
Alfred Perlstein said words to the effect of;
* Robert Watson [EMAIL PROTECTED] [020317 09:08] wrote:
On Sun, 17 Mar 2002, Alfred Perlstein wrote:
* Munehiro Matsuda [EMAIL PROTECTED] [020317 06:36] wrote:
PS. I
I get this one on every single boot. We're not shipping the snapshot
with that in place, right ?
real memory = 268423168 (262132K bytes)
avail memory = 257003520 (250980K bytes)
acquiring duplicate lock of same type: thrd_sleep
1st @ ../../../vm/vm_map.c:2288
2nd @ ../../../vm/vm_kern.c:172
--- Poul-Henning Kamp [EMAIL PROTECTED] wrote:
I get this one on every single boot. We're not shipping the snapshot
with that in place, right ?
real memory = 268423168 (262132K bytes)
avail memory = 257003520 (250980K bytes)
acquiring duplicate lock of same type: thrd_sleep
1st @
In message [EMAIL PROTECTED], Hiten Pandya w
rites:
I haven't seen this. I built a kernel today, and I have a dual processor
machine. Are you using any special kernel options, such as VFS_BIO_DEBUG
or something, or am I talking nuts? :)
Well, I have. On a single CPU net-booting -current.
--- Poul-Henning Kamp [EMAIL PROTECTED] wrote:
I haven't seen this. I built a kernel today, and I have a dual processor
machine. Are you using any special kernel options, such as VFS_BIO_DEBUG
or something, or am I talking nuts? :)
Well, I have. On a single CPU net-booting -current. No.
On Sat, 16 Mar 2002 10:22:22 +0100,
Poul-Henning Kamp [EMAIL PROTECTED] said:
Poul-Henning acquiring duplicate lock of same type: thrd_sleep
Poul-Henning 1st @ ../../../vm/vm_map.c:2288
Poul-Henning 2nd @ ../../../vm/vm_kern.c:172
(snip)
Poul-Henning
On Sat, 16 Mar 2002, Poul-Henning Kamp wrote:
I get this one on every single boot. We're not shipping the snapshot
with that in place, right ?
I assume this is from Brian's recent VM locking commit. Currently, it's
on the list of commits to back out of the DP1 branch, assuming the issues
On Sat, 16 Mar 2002 22:56:58 +0900,
Seigo Tanimura [EMAIL PROTECTED] said:
Seigo On Sat, 16 Mar 2002 10:22:22 +0100,
Seigo Poul-Henning Kamp [EMAIL PROTECTED] said:
Seigo Poul-Henning acquiring duplicate lock of same type: thrd_sleep
Seigo Poul-Henning 1st @ ../../../vm/vm_map.c:2288
Seigo
I've seen this as well, -current from about 5 days ago, dual proc 1.4GHz
K7 A7M266D with a 13GB IBM UDMA66 drive, GENERIC kernel + hints.
On Sat, 16 Mar 2002, Hiten Pandya wrote:
--- Poul-Henning Kamp [EMAIL PROTECTED] wrote:
I haven't seen this. I built a kernel today, and I have a dual
Although I am still getting the following lock problems when I shut
the system down:
lock order reversal
1st 0xc036afc0 allproc @ ../../../kern/vfs_syscalls.c:452
2nd 0xc7ecce34 filedesc structure @ ../../../kern/vfs_syscalls.c:457
I've been seeing this since Feb 4.
Bill
To
On Mon, Feb 25, 2002 at 02:38:45AM -0500, Mike Barcroft wrote:
Doug Barton [EMAIL PROTECTED] writes:
Mike Barcroft wrote:
Deprecated features should generate warnings.
Ok, then let's call it Undocumented legacy support. I agree that
features we don't want to support anymore
of specifying colours, and
want to hold onto making the deprecated version include warnings.
I could understand your argument if there were A) many different
ways, or B) support for the one legacy method was complicated. But neither
of these are true. Including a warning for something
, and
want to hold onto making the deprecated version include warnings.
Just make the damn thing not work with the deprecated setup,
remove the warnings, and handle the complaints. You're going
to be handling the complaint either way.
Or get rid of the warning, and avoid the complaints, and remove
A couple months ago an improvement was added to the color support of ls
to use a wider variety of colors, indicated by alphabet characters
instead of numbers. While I think this is a good change, it included a
warning when users have the old style numeric flags in their LSCOLORS
variable
Doug Barton [EMAIL PROTECTED] writes:
A couple months ago an improvement was added to the color support of ls
to use a wider variety of colors, indicated by alphabet characters
instead of numbers. While I think this is a good change, it included a
warning when users have the old style
Mike Barcroft wrote:
Doug Barton [EMAIL PROTECTED] writes:
A couple months ago an improvement was added to the color support of ls
to use a wider variety of colors, indicated by alphabet characters
instead of numbers. While I think this is a good change, it included a
warning
Doug Barton [EMAIL PROTECTED] writes:
Mike Barcroft wrote:
Deprecated features should generate warnings.
Ok, then let's call it Undocumented legacy support. I agree that
features we don't want to support anymore should generate warnings that
encourage users to change. However, there
On Thu, 7 Feb 2002, Julian Elischer wrote:
there may be greakage in gdb due th the commit today..
I'm waiting for my buildworld to get sround to it so I can test my fix..
julian
the fix I am looking at testing is:
Index: i386/kvm-fbsd.c
there may be greakage in gdb due th the commit today..
I'm waiting for my buildworld to get sround to it so I can test my fix..
julian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
there may be greakage in gdb due th the commit today..
I'm waiting for my buildworld to get sround to it so I can test my fix..
julian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
On Thu, 7 Feb 2002, Julian Elischer wrote:
there may be greakage in gdb due th the commit today..
I'm waiting for my buildworld to get sround to it so I can test my fix..
julian
the fix I am looking at testing is:
Index: i386/kvm-fbsd.c
This is differences between our lib_baudrate and official variant, fixed
at summer 2001. I constantly ask our ncurses maintainer (Peter) to commit
this since summer 2001, but nothing happens, so I plan to do it in anycase
even taking this file out of vendor branch since the bug must be fixed
ASR is still broken for SMP.
WARNING: Driver mistake: destroy_dev on 154/1
kernel panic: dont do that
Tyan Thunder K7 with 2 1.2GHz Ahtlon's
Adaptec 3200S Rev 3607
Current as of this morning.
--
[EMAIL PROTECTED] 39:FF:7C:52:66:9D:B9:A3 EA:67:3C:7F:D1:B6:30:36
Polymer physicists
Hi,
About two weeks ago(maybe after -current awk updates), awk warns when
I try to install any ports:
/usr/ports/deskutils/dailystrips# make install clean
dailystrips-1.0.20.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
awk: cmd. line:1: warning: escape sequence `\.' treated
In message [EMAIL PROTECTED] Nick Hibma writes:
: Yes. I have no idea why phk has not done this.
Because the asr driver maintainer has asserted a strong lock in the
past and phk doesn't have an asr card.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in
hangs:
a) The kernel is loading
b) acpi.ko is loading
c) Pentium Pro MTRR support enable
d) WARNING: Driver mistake: destroy_dev on 154/0
next is a kernel panic dont do that
So whats on?
Jan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
. I ve
updated all files in /etc and remade all devices. Now a bootup hangs:
a) The kernel is loading
b) acpi.ko is loading
c) Pentium Pro MTRR support enable
d) WARNING: Driver mistake: destroy_dev on 154/0
next is a kernel panic dont do that
Remove the asr driver from your kernel config until
/device.hints and installed the new kernel. I ve
updated all files in /etc and remade all devices. Now a bootup hangs:
a) The kernel is loading
b) acpi.ko is loading
c) Pentium Pro MTRR support enable
d) WARNING: Driver mistake: destroy_dev on 154/0
next is a kernel panic dont do that
Remove
made a new GENERIC kernel and copied the file
: GENERIC.hints to /boot/device.hints and installed the new kernel. I ve
: updated all files in /etc and remade all devices. Now a bootup hangs:
:
: a) The kernel is loading
: b) acpi.ko is loading
: c) Pentium Pro MTRR support enable
: d) WARNING: Driver
) acpi.ko is loading
: c) Pentium Pro MTRR support enable
: d) WARNING: Driver mistake: destroy_dev on 154/0
:
: next is a kernel panic dont do that
:
: Remove the asr driver from your kernel config until somebody
: fixes its use of destroy_dev()
:
: Maybe we should remove it from GENERIC
301 - 400 of 516 matches
Mail list logo
