I don't know exactly what causes the b_to_q message. It is most likely
a race in close. You can first-open tty's that are blocked in last-close,
and having this open succeed is very important for unblocking the close
usi9ng comcontrol /dev/foo drainwait small, but the tty system doesn't
seem
2) Bug is in os delivered gcc but not in port gcc.
a) port has more or less patches / os gcc has been modified
-- Didn't someone told they are the same?
b) other options were set at compile time
-- Why dont change to the same in the port?
Leads it to a
Hi All,
Has anybody seen this message before?
CPU: Pentium III/Pentium III Xeon/Celeron (595.58-MHz 686-class CPU)
Origin = GenuineIntel Id = 0x686 Stepping = 6
Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PA
T,PSE36,MMX,FXSR,SSE
real memory = 134152192
With apologies for an incomplete report, I am including the (manually
transcribed) dump information. I have been able to network boot from a
combination of the boot.flp and bin distribution (though there are
problems with getting sysinstall to find disks that prevent that approach
so far) and
Jan Stocker wrote:
[ ... DWARF vs. setjmp/longjmp ... ]
A little bit... most of you argumenting about binary incompatibility
for -stable. OK... no chance to do it there, its my opinion too. But why not
doing it for current and using that most common dwarf unwinding now (for a
later ia64
On Thu, Mar 14, 2002 at 05:54:40PM -0800, Alex Zepeda wrote:
As far as Qt goes, rip out that objprelink crap. Without it Qt will build
and work just fine. At least Qt 3.whatever works for me. I don't know
why objprelink isn't working correctly for Qt, but I don't really care.
For me
Doug Barton [EMAIL PROTECTED] writes:
1. phk malloc debugging flags enabled by default. Solutions include
recompiling apps, and toggling things off in /etc/malloc.conf.
No recompiling needed; if you don't like the default options, just
# ln -s aj /etc/malloc.conf
2. pam modules break
On Fri, Mar 15, 2002 at 01:37:39PM +0100, Jan Stocker wrote:
A little bit... most of you argumenting about binary incompatibility
for -stable. OK... no chance to do it there, its my opinion too. But why not
doing it for current and using that most common dwarf unwinding now (for a
There is no
I have installed current on a sym53c896 scsi controller but can't boot.
It has two disks with boot manager installed and I get the F1 F5 options
but neither do anything by clicking or by waiting. I can boot from
floppy or cd and mount da0s1a, execute commands from bin and sbin but
I cannot get
On Thu, 14 Mar 2002, Nate Williams wrote:
Only in very rare cases do we run into a problem where we have to create
a branch. In that case, the developer responsible for the release
creates a branch from his checked out tree (there's no law against
creating a branch from sources that are
Hi
Just tried again with newly built world and kernel using vim from ports.
This is built with ATHENA widget support and the only difference in
make.conf from default is CPUTYPE=i686. What's wrong with -current? Gvim
will build and work well under -stable.
/usr/ports/editors/vim/Makefile:
At 2:17 PM -0500 3/15/02, Robert Watson wrote:
My feeling is that at this point, we probably should just use
Perforce due to limitations in CVS.
This seems fine to me. I am uneasy about perforce in cases
where someone is developing something which is *meant* to be
merged back into the main
Emiel Kollof [EMAIL PROTECTED] writes:
Why not test for it like this (or similar):
[ -x /usr/sbin/kldxref ] /usr/bin/kldxref (etcetera...)
A better solution is
@(kldxref ${DESTDIR}${KMODDIR} || \
echo Ignoring non-fatal kldxref failure)
DES
--
Dag-Erling Smorgrav -
John Indra [EMAIL PROTECTED] writes:
Glad to know that there is no problem with malloc() in -CURRENT. But I still
think that this must be addressed in Perl. So maybe, the stock Perl should
be built against its own malloc library?
No! That would break anything that loads system libraries into
I guess it's possible to change over entirely. That would
mean we would loase a.out support because the GNU tools are
becoming incapable of supporting a.out (all machines we
run on are Linux machines syndrome).
If we really wanted to avoid problems like this in the future,
we'd just scrap
Hi
I just went -current with my Compaq Armada E700 laptop.
Coming from -stable.
I'm a bit puzzled by:
WKB ~: apm
APM version: 1.2
APM Managment: Enabled
AC Line status: off-line
Battery status: charging
Remaining battery life: invalid value (0x)
Remaining battery time: unknown
Number
On Fri, Mar 15, 2002 at 04:54:59PM -0500, Kenneth Culver wrote:
At the risk of being yelled at, I have a question: Why do we still need to
support a.out? I know that a lot of people MIGHT still have some a.out
binaries lying around, but FreeBSD's default binary format has been ELF
for 3 or 4
At the risk of being yelled at, I have a question: Why do we still need to
support a.out? I know that a lot of people MIGHT still have some a.out
binaries lying around, but FreeBSD's default binary format has been ELF
for 3 or 4 years (Since 3.0-3.1 I believe). I'm not saying that we
On Fri, Mar 15, 2002 at 05:26:37PM -0500, Kenneth Culver wrote:
At the risk of being yelled at, I have a question: Why do we still need to
support a.out? I know that a lot of people MIGHT still have some a.out
...
Rather than offer $0.02, send the patch.
Well, I was just asking if it is
Dag-Erling Smorgrav wrote:
| 3. xconsole causes periodic panics. The problem (according to BDE) is a
| well-know bug in printf(9), caused by The TIOCCONS ioctl ... panics when
| printf() is called while sched_lock is held. I reported this bug in
| October 2001, if anyone wants to look
Kenneth Culver wrote:
At the risk of being yelled at, I have a question: Why do we still need to
support a.out? I know that a lot of people MIGHT still have some a.out
binaries lying around, but FreeBSD's default binary format has been ELF
for 3 or 4 years (Since 3.0-3.1 I believe). I'm not
Hiten Pandya [EMAIL PROTECTED] writes:
I have a tru 5.0-CURRENT environment.. also.. is there any changes where
my ENABLE_NLS dillema can be solved..
s/dillema/dilemma/. It's not a dilemma, anyway; it's an issue, a
condition, a situation, a problem, a failure; a conundrum (though not
in the
I've recompiled kernet right before building qt... And have great prob
with compiling -CURRENT right before Mar 8... I've installed -CURRENT SNAP
on 20020219 which seems have broken binutils... Because xv and some other
my packages coredumped with bus error (libpng issue, seemed to be solved
Feb
Greg Black [EMAIL PROTECTED] writes:
Dag-Erling Smorgrav wrote:
| Ages-old, very difficult to fix. Just don't use xconsole.
You left out the final sentence with the suggested alternative.
There is no suggested alternative. The problem is well-known and has
been around for a long time, and
We aren't changing this for GCC 2.95 in 5-CURRENT. PEROID. There is
zero reason for subjecting users to this ABI change for what would be
gained.
If you want to do something productive, submit patches that Bmake GCC 3.1
(which move us to Dwarf2 unwinding as a product).
Oh ok, that's
At the risk of being yelled at, I have a question: Why do we still need to
support a.out? I know that a lot of people MIGHT still have some a.out
binaries lying around, but FreeBSD's default binary format has been ELF
for 3 or 4 years (Since 3.0-3.1 I believe). I'm not saying that we
Kenneth Culver wrote:
Other reasons I haven't even thought of yet 8-).
Yeah, I was just wondering if there were issues making us keep a.out stuff
in FreeBSD aside from the I wanna run 2.2.x programs issue.
Linking with third party a.out libraries.
Other reasons I haven't even thought
[ Trim the CC's a bit ]
On Fri, Mar 15, 2002 at 04:00:08PM -0800 I heard the voice of
Terry Lambert, and lo! it spake thus:
Kenneth Culver wrote:
Other reasons I haven't even thought of yet 8-).
Yeah, I was just wondering if there were issues making us keep a.out stuff
in FreeBSD
[Cc's trimmed]
Kenneth Culver wrote:
| (ttypa):{1078}% file /usr/local/lib/netscape/communicator-4.7.us.bin
| /usr/local/lib/netscape/communicator-4.7.us.bin: FreeBSD/i386 compact
|demand paged dynamically linked executable
|
| Now, if you'd like to talk Netscape into building a version
!
I have gotten today's snapshot, 5.0-20020315-CURRENT, created the
kernel and mfsroot 1.44 floppies, and attempted to boot a desktop
machine from them. This is (from my 4.5-STABLE hard drive):
CPU: Pentium III/Pentium III Xeon/Celeron (733.13-MHz 686-class CPU)
Origin = GenuineIntel Id
It's less slow and much more reliable than mozilla and remains the only
available browser that can access most of the sites I need to access.
That's odd, I've never had any mozilla problems. All I know is that it
doesn't crash on sites that Netscape crashes on (anything java) and for me
it
That's odd, I've never had any mozilla problems. All I know is that it
doesn't crash on sites that Netscape crashes on (anything java) and for
me it runs much faster than netscape. It loads slower, but renders pages
much faster, and I tend to load my browser once per day, and just leave
it
On Sat, 16 Mar 2002, Greg Black wrote:
[Cc's trimmed]
Kenneth Culver wrote:
| (ttypa):{1078}% file /usr/local/lib/netscape/communicator-4.7.us.bin
| /usr/local/lib/netscape/communicator-4.7.us.bin: FreeBSD/i386 compact
|demand paged dynamically linked executable
|
| Now, if
On Friday 15 March 2002 08:53 pm, Kenneth Culver wrote:
| (ttypa):{1078}% file /usr/local/lib/netscape/communicator-4.7.us.bin
| /usr/local/lib/netscape/communicator-4.7.us.bin: FreeBSD/i386 compact
|demand paged dynamically linked executable
|
| Now, if you'd like to talk Netscape into
Err--the linux netscape 6 runs fine. It's also quite slow to load, but
so far appears to be rather robust.
Cheers,
Ben
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Brian
T.Schellenberger
Sent: Friday, March 15, 2002 10:41 PM
To: Kenneth
[Unnecessary carbon copies trimmed.]
On Fri, 15 Mar 2002 22:41:26 -0500, Brian T.Schellenberger [EMAIL PROTECTED] said:
If you mean the FreeBSD-native netscape 4.x; yes, it's perfectly
silly to run *that*.
I don't see anything silly about it. It works with all the Web sites
I care about
Hi.
In [EMAIL PROTECTED], Maxim M. Kazachek wrote:
I've installed qt23 from ports painlessly
Does uic command provided by qt23 port work on your system? On my
-CURRENT (updated in Mar 11), that binary was linked with weird
liblcms.so_edata as next:
% ldd uic
uic:
libqutil.so.1 =
Hi.
In [EMAIL PROTECTED], Will Andrews wrote:
Um.. objprelink is disabled if OSVERSION = 500029. So it is
already ripped out for -current.
I think it better to rip objprelink out of kde port on -CURRENT, too. On
my -CURRENT (updated in Mar 11), many kde binaries build with using
objprelink
something
very broken with the install floppies, or with me. If it is me,
*please* let me know!
I have gotten today's snapshot, 5.0-20020315-CURRENT, created the
kernel and mfsroot 1.44 floppies, and attempted to boot a desktop
machine from them. This is (from my 4.5-STABLE hard drive):
CPU
Brian T.Schellenberger wrote:
Well, the linux-netscape 4 is the only browser I know that can handle Java
pages on FreeBSD.
Are there others?
If you mean the FreeBSD-native netscape 4.x; yes, it's perfectly silly to run
*that*.
4.7 does this just fine, if you don't move the mouse until
Garrett Wollman [EMAIL PROTECTED] writes:
What problems do you have with it?
Slow. Eats memory. Crashes all the time. Does not save state
between sessions. Does not render HTML 4 properly. Does not support
CSS properly. Does not zoom. Does not display PNG properly.
Incorrectly ignores
Dag-Erling Smorgrav wrote:
Garrett Wollman [EMAIL PROTECTED] writes:
What problems do you have with it?
Slow. Eats memory. Crashes all the time. Does not save state
between sessions. Does not render HTML 4 properly. Does not support
CSS properly. Does not zoom. Does not display PNG
Hi All,
After the import of libz 1.1.4, rpm (from ports) dumps core when
trying to install linux_base.
# make install
=== Installing for linux_base-6.1_1
setup-2.0.5-1.noarch.rpm
filesystem-1.3.5-1.noarch.rpm
basesystem-6.0-4.noarch.rpm
ldconfig-1.9.5-15.i386.rpm
Segmentation fault - core
43 matches
Mail list logo
