Re: GCC-4.6-20120608 has a corrupt archive or a bad checksum
On 06/12/12 12:04, Gerald Pfeifer wrote: John Merryweather Cooper wrote: Bad distfile or checksum for lang/gcc46 The mirror you are using per your e-mail -- ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/sources.redhat.com/ -- provides a broken image. I have done several downloads myself, from the original source and other mirrors, and always get the correct checksum (and a matching tarball), that is, the one matching gcc46/distinfo in FreeBSD Ports CVS. If you download directly from ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120608/gcc-4.6-20120608.tar.bz2 and put that into ports/distfiles, that should work? Alternatively, download repeatedly until it hits a different mirror? Gerald ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org Well, that's exactly the point. It never got me to any other mirrors. Repeated runs always ended the same way even with me manually deleted the distfile before each run. -- John M. Cooper -- -- John M. Cooper ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: GCC-4.6-20120608 has a corrupt archive or a bad checksum
On 06/13/12 20:37, John Merryweather Cooper wrote: On 06/12/12 12:04, Gerald Pfeifer wrote: John Merryweather Cooper wrote: Bad distfile or checksum for lang/gcc46 The mirror you are using per your e-mail -- ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/sources.redhat.com/ -- provides a broken image. I have done several downloads myself, from the original source and other mirrors, and always get the correct checksum (and a matching tarball), that is, the one matching gcc46/distinfo in FreeBSD Ports CVS. If you download directly from ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120608/gcc-4.6-20120608.tar.bz2 and put that into ports/distfiles, that should work? Alternatively, download repeatedly until it hits a different mirror? Gerald ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org Well, that's exactly the point. It never got me to any other mirrors. Repeated runs always ended the same way even with me manually deleted the distfile before each run. -- John M. Cooper Finally got it from: = gcc-4.6-20120608.tar.bz2 doesn't seem to exist in /usr/ports/distfiles//. = Attempting to fetch http://mirrors.kernel.org/sources.redhat.com/gcc/snapshots/4.6-20120608/gcc-4.6-20120608.tar.bz2 gcc-4.6-20120608.tar.bz264 MB 597 kBps Clearly a bad mirror. -- John M. Cooper -- -- John M. Cooper ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
GCC-4.6-20120608 has a corrupt archive or a bad checksum
Bad distfile or checksum for lang/gcc46 jmcooper@g7-HP$ sudo make checksum Making GCC 4.6.4.20120608 for FreeBSD 9.0 target=x86_64-portbld-freebsd9.0 === License check disabled, port has not defined LICENSE === Found saved configuration for gcc-4.6.4.20120608 = SHA256 Checksum mismatch for gcc-4.6-20120608.tar.bz2. = SHA256 Checksum OK for ecj-4.5.jar. === Refetch for 1 more times files: gcc-4.6-20120608.tar.bz2 Making GCC 4.6.4.20120608 for FreeBSD 9.0 target=x86_64-portbld-freebsd9.0 === License check disabled, port has not defined LICENSE === Found saved configuration for gcc-4.6.4.20120608 = gcc-4.6-20120608.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/. = Attempting to fetch ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/sources.redhat.com/gcc/snapshots/4.6-20120608/gcc-4.6-20120608.tar.bz2 Making GCC 4.6.4.20120608 for FreeBSD 9.0 target=x86_64-portbld-freebsd9.0 === License check disabled, port has not defined LICENSE === Found saved configuration for gcc-4.6.4.20120608 = SHA256 Checksum mismatch for gcc-4.6-20120608.tar.bz2. = SHA256 Checksum OK for ecj-4.5.jar. === Giving up on fetching files: gcc-4.6-20120608.tar.bz2 Make sure the Makefile and distinfo file (/usr/ports/lang/gcc46/distinfo) are up to date. If you are absolutely sure you want to override this check, type make NO_CHECKSUM=yes [other args]. *** [checksum] Error code 1 -- -- John M. Cooper ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why Are You NOT Using FreeBSD ?
On 06/10/12 09:54, Martin Sugioarto wrote: Am Sun, 10 Jun 2012 11:37:09 +0100 schrieb Chris Reescr...@freebsd.org: Er... people always test their commits. Sometimes edge cases will creep in, such as the libreoffice failure which was due to different configurations, but to suggest that the commit wasn't tested is quite frankly insulting-- it built on a clean system perfectly well. Hi, I don't mean to insult anyone. As I have already told, I am really thankful that people invest their precious time into updating the ports collection. Whatever clean system means. It is surely not the default case that someone has got a freshly installed set of ports. Among all the default problems with ports, libreoffice[1] adds to the group of annoyances[2] at the moment. I don't know when I have seen portmaster -ad run through successfully last time. I need more and more -x options to exclude ports which fail to build. [1] german/libreoffice and libreoffice fails all the time in (LOCALIZED_LANG is set to de): Module 'lingucomponent' delivered successfully. 12 files copied, 2 files unchanged --- Oh dear - something failed during the build - sorry ! For more help with debugging build errors, please see the section in: http://wiki.documentfoundation.org/Development internal build errors: ERROR: error 65280 occurred while making /usr/workdir-ports/usr/ports/editors/libreoffice/work/libreoffice-core-3.5.2.2/vcl/prj it seems that the error is inside 'vcl', please re-run build inside this module to isolate the error and/or test your fix: --- Whatever this tries to tell me. I don't get it. This is a completely useless error message for me. [2] The default annoyances are for example: - After updating perl, php or whatever, it makes sense to enforce updating the modules that belong to these ports. I've seen 100x the same message that p5-XML-Parser does not work and know what it means, but this should be resolved by the port system. I mean, when you update perl, the perl modules won't work anymore. This is totally clear and it makes sense to update them first before going on. - When specifying WITHOUT_X11 the ports should respect this and not try to pull in the X11 variants of ports. I regularly see some ports pulling ImageMagick instead of the already installed ImageMagick-nox11. I still do not fully understand what is going on with WITHOUT_GNOME, but I'll try to figure it out later. But I am quite sure that some ports pull in unneeded Gnome dependencies. - Ports are being marked as interactive and stop the update process. The idea behind portmaster was (earlier) to avoid interactive building of ports and ask all the needed questions, before the builds start. I mean, earlier, I could get out and enjoy some coffee outdoors, now I have to sit at the keyboard. This is unacceptable! ;) - It would be nice to have a mechanism that tells you that your perl, mysql or whatever is not the default version anymore and you should consider updating to the default (and recommended) port. Martin From /etc/defaults/periodic.conf: # 400.status-pkg weekly_status_pkg_enable=YES# Find out-of-date pkgs pkg_version=pkg_version # Use this program pkg_version_index=/usr/ports/INDEX-9 # Use this index file There's an override script in ports-mgmt/portupgrade that uses it's database, also. -- -- John M. Cooper ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [RFC/P] Port System Re-Engineering (Repost from -ports@)
Aryeh M. Friedman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [Repost from [EMAIL PROTECTED] As has been hashed out in -ports@ over the last few days there is at least a need to examine weither or not the current ports system should remain as is or potentially be re-engineered in the future (estimates if and when needed vary from ASAP to 10-15 years). I have volunteered to undertake a feasibility/pilot project to examine what changes (if any) are needed in the system (for the purposes of this thread I will not venture any of my own suggestions). I have the following broad questions for people: 1. What is more important to your personal use of FreeBSD (the ports system, the underlaying OS, some other aspect)? Underlying OS. 2. How frequently do you interact with the ports systems and what is the most common interaction you have with it? Daily. Updating. 3. What is the single best aspect of the current system? Easy to implement ports. 4. What is the single worst aspect of the current system? Slow rebuild of portupgrade database (much improved in recent versions). 5. If you where a new FreeBSD user how would your answers above change? If you where brand new to UNIX how whould they change? In my experience, people from a Windoze background don't understand dependencies at all. Everything just happens under the hood during the install. This gives the impression that installing software works better under Windoze, but this impression is false. Dependency bugs (in the form of inconsistent/out-dated DLLs) have been a source of instability since the beginning. 6. Assuming that there was no additional work on your behalf would you use a new system if it corrected your answer to number 4? Yes. 7. Same as question 6 but for your answer on question 3? However, to be acceptable, porting software into the build environment as to be at least as easy as it is now. In fact, porting is far more important than installing. 8. How long have you used FreeBSD and/or UNIX in general? This is my 8th year. 9. That is your primary use(s) for your FreeBSD machine(s) (name upto 3)? Development, port maintenance, writing (desktop applications). 10. Assuming there is no functional difference what is your preferred installation method for 3rd party software? In the best of all possible worlds, installs would be self-contained (they would install correctly on the target with no intervention from the user). In the real world, I want 3rd party software to follow the ports system (whatever it may be). If 3rd part software does NOT track the ports systems, all manner of difficult-to-debug bugs will propagate. 11. On a scale from 1 to 10 (10 being the best) please rate the importance of the following aspects of the ports system? a. User Interface a = 4 (but see GNOME, KDE, and Webmin) b. Consistency of behaviors and interactions b = 8 c. Accuracy in dependant port installations c = 10 d. Internal record keeping d = 6 e. Granularity's of the port management system e = 8 12. Please rate your personal technical skill level? High. - -- Aryeh M. Friedman FloSoft Systems Developer, not business, friendly http://www.flosoft-systems.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHVBBj358R5LPuPvsRArclAKC8fVFVsva2DPmOQdTWw+/CT+wGywCfWvPl hbX2FSUdh6C61xTDJqnWf/M= =iCiu -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Bulk] Re: loader on Dell INSPIRON 1501: BTX halted
Torfinn Ingolfsen wrote: On Fri, 26 Oct 2007 19:51:51 +0300 Kostik Belousov [EMAIL PROTECTED] wrote: Take patch from http://people.freebsd.org/~kib/realbtx (rev. 2). The new loader is at the same location, but it seems that I did not saved new boot2. You need to install both boot block and loader obtained from the build with the realbtx patch applied, to you USB HDD drive. Just for fun, I tested this patch on an Acer Aspire 5672AWLMi laptop. (See this page[1] for my adventures with this laptop.) This laptop doesn't say BTX halted, it just scrolls a lot of text (register dumps?) across the screen forever. I did: cd /usr/src/sys patch ../.../realbtx.2.patch cd boot/i386 make Then I copied the files to the usb hdd (da0) with boot0cfg -B -b /usr/obj/usr/src/sys/boot/i386/boot0/boot0 da0 mount /dev/da0s1a /mnt cp -v /usr/obj/usr/src/sys/boot/i386/loader/loader /mnt/boot Is this the correct way to do it? Then I unmounted the disk and tried to boot it. Unfortunately, nothing changed. When booted (from usb hdd) the laptop still scrolls text across the screen forever. I have to turn it off with the power button. Should this patch work on my laptop? 1) http://tingox.googlepages.com/aceraspireas5672andfreebsd The realbtx.2.patch does not fix the hang during boot of my HP Pavillion dv9420us. The boot stops just like before, right after the Copyright message and text=?? it freezes and only a power cycle will bring it to life. Currently, I work around the boot hang by pressing spacebar starting just before the BIOS splash disappears; and then press enter at the boot slice prompt. jmc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: loader on Dell INSPIRON 1501: BTX halted
Daniel O'Connor wrote: On Sat, 10 Nov 2007, Torfinn Ingolfsen wrote: On Fri, 26 Oct 2007 19:51:51 +0300 Kostik Belousov [EMAIL PROTECTED] wrote: Take patch from http://people.freebsd.org/~kib/realbtx (rev. 2). The new loader is at the same location, but it seems that I did not saved new boot2. You need to install both boot block and loader obtained from the build with the realbtx patch applied, to you USB HDD drive. Just for fun, I tested this patch on an Acer Aspire 5672AWLMi laptop. (See this page[1] for my adventures with this laptop.) This laptop doesn't say BTX halted, it just scrolls a lot of text (register dumps?) across the screen forever. You could try this one as well.. http://people.freebsd.org/~jhb/patches/btx_crx.patch Although I have tried both and it works for some systems but not others (eg Supermicro C2SBA bombs scrolling stack dumps over and over so fast I can't take a picture of it). I should be getting another system like it soon so I can test it again, hopefully I'll get time to add some 'go slow' routines to the stack trace so I can actually record it :) btx_crx.patch doesn't apply cleanly to btx.S in FreeBSD 7.0-BETA2 jmc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: named.conf restored to hint zone for the root by default
Jo Rhett wrote: On Aug 3, 2007, at 5:25 PM, Doug Barton wrote: I'm getting tired of repeating this. A lot of really smart people are lined up on BOTH sides of this issue. You might want to take another look at the threads about this on the OARC list (or even this list for that matter) and try to have an open mind. Repeating this is a bad idea over and over again doesn't make it more true. No, they aren't. I'm actually quite amazed at your resistance to hearing what is being said. Several people (not a lot) think that slaving the root zone makes some good operational sense in specific scenarios. One person thought that the world would be a better place if it were operationally possible. NOBODY thinks that this will work in the real world, today, in a stable manner. NOBODY thinks that having *every* home user slaving the root makes good sense, even if it was operationally possible. And NOBODY thinks that just doing it without asking first was a good way to handle it. I'm really not sure why I wasted the keystrokes to write this, because you've been consistently willing to ignore pretty much everything said to you so far. I guess I'm just praying that perhaps, just maybe, this time you'll start paying attention. I would appreciate it if the personal attacks ceased. As an observer with no ax to grind on this issue, it is apparent that slaving the root zone is technically possible, but not necessarily good policy. It would be nice if those arguing against slaving the root zone would articulate the specific effects on top-tier servers and quantify them. As it is, this thread is painful to read because of the dross-to-substance ratio being rather high. jmc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
WAS: misc/113825: WARN Error in FreeBSD 6.2-STABLE (/usr/src/lib/libc/rpc/getpublickey.c)
Sigh . . .
Here are the patches I was trying to upload when the PR was closed
without mercy. :)
jmc
# Patch for misc/113825 for csup
#
# To apply this patch:
# STEP 1: Chdir to the source directory.
# STEP 2: Run the 'applypatch' program with this patch file as input.
#
# If you do not have 'applypatch', it is part of the 'makepatch' package
# that you can fetch from the Comprehensive Perl Archive Network:
# http://www.perl.com/CPAN/authors/Johan_Vromans/makepatch-x.y.tar.gz
# In the above URL, 'x' should be 2 or higher.
#
# To apply this patch without the use of 'applypatch':
# STEP 1: Chdir to the source directory.
# STEP 2: Run the 'patch' program with this file as input.
#
End of Preamble
Patch data follows
diff -c 'contrib/csup/proto.c.old' 'contrib/csup/proto.c'
Index: ./contrib/csup/proto.c.old
*** ./contrib/csup/proto.c.old Tue Jun 19 04:29:42 2007
--- ./contrib/csup/proto.c Tue Jun 19 05:31:31 2007
***
*** 68,74
};
static voidkiller_start(struct killer *, struct mux *);
! static void *killer_run(void *);
static voidkiller_stop(struct killer *);
static int proto_waitconnect(int);
--- 68,74
};
static voidkiller_start(struct killer *, struct mux *);
! static voidkiller_run(void *);
static voidkiller_stop(struct killer *);
static int proto_waitconnect(int);
***
*** 963,968
--- 963,970
/* Start the killer thread. It is used to protect against some signals
during the multi-threaded run so that we can gracefully fail. */
+ typedef void *(*start_routine)(void *);
+
static void
killer_start(struct killer *k, struct mux *m)
{
***
*** 976,988
sigaddset(k-sigset, SIGTERM);
sigaddset(k-sigset, SIGPIPE);
pthread_sigmask(SIG_BLOCK, k-sigset, NULL);
! error = pthread_create(k-thread, NULL, killer_run, k);
if (error)
err(1, pthread_create);
}
/* The main loop of the killer thread. */
! static void *
killer_run(void *arg)
{
struct killer *k;
--- 978,991
sigaddset(k-sigset, SIGTERM);
sigaddset(k-sigset, SIGPIPE);
pthread_sigmask(SIG_BLOCK, k-sigset, NULL);
! error = pthread_create(k-thread, NULL, (start_routine)killer_run, k);
if (error)
err(1, pthread_create);
}
/* The main loop of the killer thread. */
!
! static void
killer_run(void *arg)
{
struct killer *k;
End of Patch data
ApplyPatch data follows
# Data version: 1.0
# Date generated : Tue Jun 19 06:52:53 2007
# Generated by: makepatch 2.03
# Recurse directories : Yes
# Excluded files : (\A|/).*\~\Z
# (\A|/).*\.a\Z
# (\A|/).*\.bak\Z
# (\A|/).*\.BAK\Z
# (\A|/).*\.elc\Z
# (\A|/).*\.exe\Z
# (\A|/).*\.gz\Z
# (\A|/).*\.ln\Z
# (\A|/).*\.o\Z
# (\A|/).*\.obj\Z
# (\A|/).*\.olb\Z
# (\A|/).*\.old\Z
# (\A|/).*\.orig\Z
# (\A|/).*\.rej\Z
# (\A|/).*\.so\Z
# (\A|/).*\.Z\Z
# (\A|/)\.del\-.*\Z
# (\A|/)\.make\.state\Z
# (\A|/)\.nse_depinfo\Z
# (\A|/)core\Z
# (\A|/)tags\Z
# (\A|/)TAGS\Z
# p 'contrib/csup/proto.c.old' 25477 1182245491 0100644
End of ApplyPatch data
End of Patch kit [created: Tue Jun 19 06:52:53 2007]
Patch checksum: 96 2948 4469
Checksum: 114 3601 58469
# Patch for misc/113825 for ggated
#
# To apply this patch:
# STEP 1: Chdir to the source directory.
# STEP 2: Run the 'applypatch' program with this patch file as input.
#
# If you do not have 'applypatch', it is part of the 'makepatch' package
# that you can fetch from the Comprehensive Perl Archive Network:
# http://www.perl.com/CPAN/authors/Johan_Vromans/makepatch-x.y.tar.gz
# In the above URL, 'x' should be 2 or higher.
#
# To apply this patch without the use of 'applypatch':
# STEP 1: Chdir to the source directory.
# STEP 2: Run the 'patch' program with this file as input.
#
End of Preamble
Patch data follows
diff -c 'sbin/ggate/ggated/ggated.c.old' 'sbin/ggate/ggated/ggated.c'
Index: ./sbin/ggate/ggated/ggated.c.old
*** ./sbin/ggate/ggated/ggated.c.oldMon Jun 18 23:05:16 2007
--- ./sbin/ggate/ggated/ggated.cMon Jun 18 23:08:02 2007
***
*** 756,761
--- 756,762
error = pthread_mutex_unlock(outqueue_mtx);
assert(error == 0);
}
+ return arg;
}
static void *
***
*** 810,815
WAS: misc/113825: WARN Error in FreeBSD 6.2-STABLE (/usr/src/lib/libc/rpc/getpublickey.c)
Maybe you would like unified diff's better? Sorry . . .
jmc
# misc/113825
#
# To apply this patch:
# STEP 1: Chdir to the source directory.
# STEP 2: Run the 'applypatch' program with this patch file as input.
#
# If you do not have 'applypatch', it is part of the 'makepatch' package
# that you can fetch from the Comprehensive Perl Archive Network:
# http://www.perl.com/CPAN/authors/Johan_Vromans/makepatch-x.y.tar.gz
# In the above URL, 'x' should be 2 or higher.
#
# To apply this patch without the use of 'applypatch':
# STEP 1: Chdir to the source directory.
# STEP 2: Run the 'patch' program with this file as input.
#
End of Preamble
Patch data follows
diff -ruN 'contrib/csup/proto.c.old' 'contrib/csup/proto.c'
Index: ./contrib/csup/proto.c.old
--- ./contrib/csup/proto.c.old Tue Jun 19 04:29:42 2007
+++ ./contrib/csup/proto.c Tue Jun 19 05:31:31 2007
@@ -68,7 +68,7 @@
};
static void killer_start(struct killer *, struct mux *);
-static void*killer_run(void *);
+static void killer_run(void *);
static void killer_stop(struct killer *);
static int proto_waitconnect(int);
@@ -963,6 +963,8 @@
/* Start the killer thread. It is used to protect against some signals
during the multi-threaded run so that we can gracefully fail. */
+typedef void *(*start_routine)(void *);
+
static void
killer_start(struct killer *k, struct mux *m)
{
@@ -976,13 +978,14 @@
sigaddset(k-sigset, SIGTERM);
sigaddset(k-sigset, SIGPIPE);
pthread_sigmask(SIG_BLOCK, k-sigset, NULL);
- error = pthread_create(k-thread, NULL, killer_run, k);
+ error = pthread_create(k-thread, NULL, (start_routine)killer_run, k);
if (error)
err(1, pthread_create);
}
/* The main loop of the killer thread. */
-static void *
+
+static void
killer_run(void *arg)
{
struct killer *k;
End of Patch data
ApplyPatch data follows
# Data version: 1.0
# Date generated : Tue Jun 19 07:31:02 2007
# Generated by: makepatch 2.03
# Recurse directories : Yes
# Excluded files : (\A|/).*\~\Z
# (\A|/).*\.a\Z
# (\A|/).*\.bak\Z
# (\A|/).*\.BAK\Z
# (\A|/).*\.elc\Z
# (\A|/).*\.exe\Z
# (\A|/).*\.gz\Z
# (\A|/).*\.ln\Z
# (\A|/).*\.o\Z
# (\A|/).*\.obj\Z
# (\A|/).*\.olb\Z
# (\A|/).*\.old\Z
# (\A|/).*\.orig\Z
# (\A|/).*\.rej\Z
# (\A|/).*\.so\Z
# (\A|/).*\.Z\Z
# (\A|/)\.del\-.*\Z
# (\A|/)\.make\.state\Z
# (\A|/)\.nse_depinfo\Z
# (\A|/)core\Z
# (\A|/)tags\Z
# (\A|/)TAGS\Z
# p 'contrib/csup/proto.c.old' 25477 1182245491 0100644
End of ApplyPatch data
End of Patch kit [created: Tue Jun 19 07:31:02 2007]
Patch checksum: 73 2412 32655
Checksum: 91 3047 19426
# misc/113825
#
# To apply this patch:
# STEP 1: Chdir to the source directory.
# STEP 2: Run the 'applypatch' program with this patch file as input.
#
# If you do not have 'applypatch', it is part of the 'makepatch' package
# that you can fetch from the Comprehensive Perl Archive Network:
# http://www.perl.com/CPAN/authors/Johan_Vromans/makepatch-x.y.tar.gz
# In the above URL, 'x' should be 2 or higher.
#
# To apply this patch without the use of 'applypatch':
# STEP 1: Chdir to the source directory.
# STEP 2: Run the 'patch' program with this file as input.
#
End of Preamble
Patch data follows
diff -ruN 'sbin/ggate/ggated/ggated.c.old' 'sbin/ggate/ggated/ggated.c'
Index: ./sbin/ggate/ggated/ggated.c.old
--- ./sbin/ggate/ggated/ggated.c.oldMon Jun 18 23:05:16 2007
+++ ./sbin/ggate/ggated/ggated.cMon Jun 18 23:08:02 2007
@@ -756,6 +756,7 @@
error = pthread_mutex_unlock(outqueue_mtx);
assert(error == 0);
}
+ return arg;
}
static void *
@@ -810,6 +811,7 @@
}
free(req);
}
+ return arg;
}
static void
End of Patch data
ApplyPatch data follows
# Data version: 1.0
# Date generated : Tue Jun 19 07:35:00 2007
# Generated by: makepatch 2.03
# Recurse directories : Yes
# Excluded files : (\A|/).*\~\Z
# (\A|/).*\.a\Z
# (\A|/).*\.bak\Z
# (\A|/).*\.BAK\Z
# (\A|/).*\.elc\Z
# (\A|/).*\.exe\Z
# (\A|/).*\.gz\Z
# (\A|/).*\.ln\Z
# (\A|/).*\.o\Z
# (\A|/).*\.obj\Z
#
Yet Another Screenshot of a GNOME 2.18 Desktop
See attached URL. This is a Screenshot of GNOME 2.18 on my Dell 5100 Laptop. http://www.borgsdemons.com/images/Screenshot.png jmc ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why does FBSD always assume it's on an 8080 CPU?
Chris H. wrote: ...or when will FreeBSD support Pentium features? I want to apologize in advance if this should be on the kern@ But it seemed apropriate for this list too and I'm already on it. I've noticed building kernels, that since v. = 5 that during the phase 2/3 all the lines echoed to the screen contain: -mno-mmx -mno-3dnow -mno-sse -mno-sse2 ... As Pentium have been the norm for many years now, why aren't these /assumed/? I'm building on several SMP PIII's and a build is in process now on a PIV Athalon running 6.2 the source and ports tree were cvsupped 01-25 @02:03:00 -0800. Yet this current kernel build is echoing these same -mno- lines. I have machinei386 cpuI686_CPU deviceapic uncommented and I386_CPU, I486_CPU I586_CPU commented. I have grepped the /src/sys/conf/NOTES as well as the /src/sys/i386/conf/NOTES Yet the only case I find relating to this is on line: 130 in: /src/sys/i386/conf/NOTES which reads: # CPU_ENABLE_SSE enables SSE/MMX2 instructions support. This is default # on I686_CPU and above. Default? hmmm... not as far as I can tell. Anyway, I would *greatly* appreciate any insight on this issue. Do I need to pollute my make.conf file to achive a Pentium kernel? Thank you very much for all your time and consideration. --Chris Context switching. We already preserve the core CPU state and the FPU state between context switches. Adding MMX into the mix means preserving an MMX state (since it can clobber the FPU state) and so forth. jmc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/92785: Using exported filesystem on OS/2 NFS client causes filesystem freeze
Kostik Belousov wrote: On Fri, Dec 15, 2006 at 03:12:58PM +0100, Ulrich Spoerlein wrote: A tcpdump of the session can be found at: http://coyote.dnsalias.net/rpc.pcap (9kB) Am I right that all you did was ls -l root of nfs mount ? Does OS/2 supports the notion of .. directory ? Could you do just ls -l .. from nfs client and then try stat root of exported fs on the server (i think it shall hang) ? My hypothesis is that LOOKUP RPC for .. causes directory vnode lock leak in nfs_namei. After that, mountd hang is just consequence. Yes, OS/2 supports the .. directory. FAT, HPFS, and JFS all have a .. directory. jmc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cardbus0: CIS pointer != 0 problem.
Steve Kargl wrote: I have a colleague who installed FreeBSD 6.1-stable onto an Alienware MJ-12 laptop. A verbose dmesg is at http://troutmask.apl.washington.edu/~kargl/alienware.dmesg We are trying to getting his wireless nic up, but seem to have run into a cardbus issue. I've built a custom kernel and stripped out all unneeded device drives. During boot,r we see cardbus0: CIS pointer is 0! cardbus0: Resource not specified in CIS: id=10, size=100 cardbus0: Resource not specified in CIS: id=14, size=0 cardbus0: Resource not specified in CIS: id=1c, size=100 cardbus0: Resource not specified in CIS: id=24, size=80 cbb alloc res fail found- vendor=0x10de, dev=0x0299, revid=0xa1 bus=2, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit Has anyone seen this problem and do you have some recommendations to fix or work around the issue? This message most commonly comes up when the NIC/PCCARD is NOT supported by a native FreeBSD driver. For example: cardbus0: CIS pointer is 0! cardbus0: Resource not specified in CIS: id=10, size=2000 ndis0: Belkin 802.11g Network Adapter mem 0xf6002000-0xf6003fff irq 11 at device 0.0 on cardbus0 ndis0: NDIS API version: 5.1 ndis0: Ethernet address: 00:11:50:7b:ba:b1 is the output for my Broadcom-based wireless NIC. I use a WinDoze driver and the ndis interface. jmc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to use firefox
Mihir Sanghavi wrote: Hi, I have installed firefox using pkg_add -r firefox and now want to use xterm i tried using xterm and it says: Cannot open display and display not set It sounds like X is not running. Anyway Firefox has very little to do with xterm. jmc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vfs.usermount seem to have no effect...
Evren Yurtesen wrote: I tried to let my user to mount floppy however it doesnt work...see below: %ls -al /dev/fd0 crw-rw-rw- 1 root operator0, 98 Jun 30 18:22 /dev/fd0 %ls -al /mnt total 4 drwxrwxrwx 2 root wheel 512 May 1 2005 . drwxr-xr-x 20 root wheel 512 Jun 30 18:21 .. %mount /dev/fd0 /mnt mount: /dev/fd0: Operation not permitted %sysctl -a | grep vfs.usermount vfs.usermount: 1 %uname -a FreeBSD perpetual.my.domain 6.1-STABLE FreeBSD 6.1-STABLE #0: Fri Jun 23 20:07:07 EEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PERPETUAL i386 % The same problem exists for dos partitions etc. am I missing something here? Thanks, Evren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Well, the mount point has to be owned and have suitable permissions for mounting. For example, to mount my DVD drive while NOT logged on as root, I have a mounting point: $HOME/cdrom in my home directory and an appropriate entry in my /etc/fstabs. jmc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: trap 12: supervisor write, page not present on 6.1-STABLE Tue May 16 2006
Stanislaw Halik wrote: On Tue, Jun 27, 2006, Stanislaw Halik wrote: 6.1-STABLE crashed on me. I'm providing a backtrace. Could any of you, experienced people, suggest me if it's a hardware problem or is it an error inside the OS? [...] More info follows: #7 0xc058e01a in ip_ctloutput (so=0xd68d5d90, sopt=0xd68d5c80) at /usr/src/sys/netinet/ip_output.c:1210 1210inp-inp_ip_tos = optval; Current language: auto; currently c (kgdb) p inp $1 = (struct inpcb *) 0x0 I have identical traps on 6.1-STABLE with my Dell Inspiron 5100. I note that these traps only occur (randomly) when I'm using NDIS to drive my wireless card. jmc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quality of FreeBSD
Igor Robul wrote: Karl Denninger wrote: Ok, Robert, but then here's the question How come the ATA code which was very stable in 4.x was screwed with in a production release, breaking it, with no path backwards to the working code? I had not ANY problems with ATA on several mothersboards, both SMP and uniproc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] The VIA SATA onboard controller on my server works (and has worked) flawlessly. I have two identical 80G Maxtor SATA drives connected to it and have had absolutely no problems and excellent performance. Even my Dell Inspirion 5100--with a few hiccups--has made great progress and is mostly functional. jmc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[BUG REPORT] Off by one error in initializing unit number forPCCARD NICs in both recent 4.8-STABLE and 5.1-RELEASE
Because of the nature of this bug, I have no network access on my FreeBSD machine and so I'm filing this off my wife's laptop. I can't send-pr in any other manner. Would someone please post this SYSTEM IBM 380XD Thinkpad Laptop running either a recent (post-May) 4.8-STABLE or 5.1-RELEASE (off the ISO images off ftp.freebsd.org). The 5.1 kernel was recompiled with OLDCARD support since NEWCARD fails in other ways. Using Compaq Netelligent 10/100 PCCARD Nic or NetGear Wireless (xe and wi respectively) SYMPTOMS Boot and detect occur normally. However, as the PCCARD device is being brought up, the PCCARD subsystem is starting with a unit number of -1 instead of 0. Hence, I get messages indicating attempts to start xe-1 which always fail. Prior to May, STABLE was fine. When I recompiled STABLE and found myself without network access. I decided to install a clean install of 5.1-RELEASE. To my chagrin, the same problem exists on 5.1-RELEASE too. WORKAROUND None known. jmc ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recent -STABLE dying on install in opencrypto
Nope. I tried again (actually, this is the fifth build attempt) with identical results. :) I've done a make update before each build and it breaks the same way each time (the last two builds have modified nothing in the world/kernel tree). jmc On Thu, 2002-11-21 at 20:30, Kris Kennaway wrote: On Thu, Nov 21, 2002 at 08:16:05PM -0800, John Merryweather Cooper wrote: It looks like there's an error in the install routines for opencrypto. Everything builds fine, but the installworld results in: This was only MFCed about 2 hours ago. You might have cvsupped in the middle of the change. Please wait a few hours and try again. Kris -- John Merryweather Cooper [EMAIL PROTECTED] University of Idaho To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: creative sound card
By the vendor ID, you may need to disable the on-board VIA chip first. On Fri, 2002-11-01 at 16:57, TOH, Boon-Wee wrote: Hi, Has anyone been able to get a Creative Soundblaster Live! Value to work on FreeBSD? I am running 4.7-STABLE. My dmesg output is as follows: pci0: unknown card (vendor=0x1106, dev=0x3057) at 7.4 pcm0: Creative EMU10K1 port 0xe000-0xe01f irq 10 at device 9.0 on pci0 My kernel config is as follows: device pcm device sbc # Creative Card Appreciate if anyone can give some advice. Rgds, BW To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message -- _ | |V| / ' || MacroHard -- \ \_| | | \_, || the perfection of form over | --|| substance, marketing over | Web: http://www.borgsdemons.com || performance, and greed over | AIM: johnmcooper || design . . .| Yahoo: john_m_cooper || | =/ Public Key: http://www.borgsdemons.com/Personal/pgpkey.asc | =\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: make kernel fails after cvsup
This is the same problem I reported earlier. It appears that the updated USB stuff is trying to make a uvisor module, but the rest of the USB driver is not up to the task. On Thu, 2002-08-08 at 19:16, jbw wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I just upgrade my src...make build, make install worked fine. But I received the following error when trying to build my kernel.. === uvisor cc -O -pipe -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-protot ypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extens ions -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/../include -mpreferred-stack -boundary=2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmiss ing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi - c /usr/src/sys/modules/uvisor/../../dev/usb/uvisor.c /usr/src/sys/modules/uvisor/../../dev/usb/uvisor.c: In function `uvisor_attach': /usr/src/sys/modules/uvisor/../../dev/usb/uvisor.c:325: warning: implicit declar ation of function `usbd_add_drv_event' /usr/src/sys/modules/uvisor/../../dev/usb/uvisor.c:325: `USB_EVENT_DRIVER_ATTACH ' undeclared (first use in this function) /usr/src/sys/modules/uvisor/../../dev/usb/uvisor.c:325: (Each undeclared identif ier is reported only once /usr/src/sys/modules/uvisor/../../dev/usb/uvisor.c:325: for each function it app ears in.) /usr/src/sys/modules/uvisor/../../dev/usb/uvisor.c: In function `uvisor_detach': /usr/src/sys/modules/uvisor/../../dev/usb/uvisor.c:372: `USB_EVENT_DRIVER_DETACH ' undeclared (first use in this function) /usr/src/sys/modules/uvisor/../../dev/usb/uvisor.c: In function `uvisor_init': /usr/src/sys/modules/uvisor/../../dev/usb/uvisor.c:396: too many arguments to fu nction `usbd_do_request_flags' /usr/src/sys/modules/uvisor/../../dev/usb/uvisor.c: In function `uvisor_close': /usr/src/sys/modules/uvisor/../../dev/usb/uvisor.c:485: too many arguments to fu nction `usbd_do_request_flags' *** Error code 1 Stop in /usr/src/sys/modules/uvisor. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/unifex. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. What do I need to do to get this to compile correctly? TIA jbw -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9UyXpFqigFUYbBbIRAlelAKCAUfd+wqWITPlk6w6gxWr5/3oz6wCgiX34 2PL6k3k7r+Q7Rw3o51/KbHU= =78ka -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message -- _ | |V| / ' || MacroHard -- \ \_| | | \_, || the perfection of form over | --|| substance, marketing over | Web: http://www.borgsdemons.com || performance, and greed over | AIM: johnmcooper || design . . .| =/ Public Key: http://www.borgsdemons.com/Personal/pgpkey.asc | =\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: USE_GCC=3.1 CPUTYPE
Well, ALL the Ada ports cause problems if CFLAGS gets set to an -march
that adagcc can't handle. For a good test case for you, try out
devel/gvd. If -march ends up having a gcc 2.95x or later CPU argument,
it's guaranteed to choke. :) The GNAT port itself has been hacked to
ignore CFLAGS, but this denies the Ada compiler the use of -march in
it's libraries and code.
jmc
On Tue, 2002-07-23 at 20:41, Jesse Gross wrote:
Here is what I have come up with. This will use the newer CPU targets
if GCC 3.1 is being used either by a port or in make.conf. Otherwise if
the stock compiler is being used the old targets are used. It will not
break compatibility in anyway that I know of.
I realize that it is prefered for new stuff to go in -current, but this
is not applicable due to the fact that -current uses GCC 3.1 as the
stock compiler. Since this is a patch to -stable, I would appreciate if
people would beat on it some and tell me about it.
As far as the Ada stuff goes, is there a specific port that causes
problems or something else I can look at?
Jesse Gross
Index: bsd.cpu.mk
===
RCS file: /home/ncvs/src/share/mk/bsd.cpu.mk,v
retrieving revision 1.2.2.5
diff -u -3 -p -r1.2.2.5 bsd.cpu.mk
--- bsd.cpu.mk2002/07/19 08:09:32 1.2.2.5
+++ bsd.cpu.mk2002/07/24 03:32:45
@@ -28,28 +28,66 @@ CPUTYPE = k7
.if !defined(NO_CPU_CFLAGS) || !defined(NO_CPU_COPTFLAGS)
. if ${MACHINE_ARCH} == i386
-. if ${CPUTYPE} == k7
-_CPUCFLAGS = -march=k6 # gcc doesn't support athlon yet, but it will
-. elif ${CPUTYPE} == k6-2
+. if ${CC}==gcc31 ${CXX}==g++31 # If GCC 3.1 is being used, new
CPU targets can be used
+. if ${CPUTYPE} == athlon-xp
+_CPUCFLAGS = -march=athlon-xp
+. elif ${CPUTYPE} == athlon-mp
+_CPUCFLAGS = -march=athlon-mp
+. elif ${CPUTYPE} == athlon-4
+_CPUCFLAGS = -march=athlon-4
+. elif ${CPUTYPE} == k7
+_CPUCFLAGS = -march=athlon
+. elif ${CPUTYPE} == k6-2
+_CPUCFLAGS = -march=k6-2
+. elif ${CPUTYPE} == k6
_CPUCFLAGS = -march=k6
-. elif ${CPUTYPE} == k6
+. elif ${CPUTYPE} == k5
+_CPUCFLAGS = -march=pentium
+. elif ${CPUTYPE} == p4
+_CPUCFLAGS = -march=pentium4
+. elif ${CPUTYPE} == p3
+_CPUCFLAGS = -march=pentium3
+. elif ${CPUTYPE} == p2
+_CPUCFLAGS = -march=pentium2
+. elif ${CPUTYPE} == i686
+_CPUCFLAGS = -march=pentiumpro
+. elif ${CPUTYPE} == i586/mmx
+_CPUCFLAGS = -march=pentium-mmx
+. elif ${CPUTYPE} == i586
+_CPUCFLAGS = -march=pentium
+. elif ${CPUTYPE} == i486
+_CPUCFLAGS = -march=i486
+. endif
+. else
+. if ${CPUTYPE} == athlon-xp
+_CPUCFLAGS = -march=k6
+. elif ${CPUTYPE} == athlon-mp
+_CPUCFLAGS = -march=k6
+. elif ${CPUTYPE} == athlon-4
+_CPUCFLAGS = -march=k6
+. elif ${CPUTYPE} == k7
+_CPUCFLAGS = -march=k6
+. elif ${CPUTYPE} == k6-2
+_CPUCFLAGS = -march=k6
+. elif ${CPUTYPE} == k6
_CPUCFLAGS = -march=k6
-. elif ${CPUTYPE} == k5
+. elif ${CPUTYPE} == k5
_CPUCFLAGS = -march=pentium
-. elif ${CPUTYPE} == p4
+. elif ${CPUTYPE} == p4
_CPUCFLAGS = -march=pentiumpro
-. elif ${CPUTYPE} == p3
+. elif ${CPUTYPE} == p3
_CPUCFLAGS = -march=pentiumpro
-. elif ${CPUTYPE} == p2
+. elif ${CPUTYPE} == p2
_CPUCFLAGS = -march=pentiumpro
-. elif ${CPUTYPE} == i686
+. elif ${CPUTYPE} == i686
_CPUCFLAGS = -march=pentiumpro
-. elif ${CPUTYPE} == i586/mmx
+. elif ${CPUTYPE} == i586/mmx
_CPUCFLAGS = -march=pentium
-. elif ${CPUTYPE} == i586
+. elif ${CPUTYPE} == i586
_CPUCFLAGS = -march=pentium
-. elif ${CPUTYPE} == i486
+. elif ${CPUTYPE} == i486
_CPUCFLAGS = -march=i486
+. endif
. endif
. elif ${MACHINE_ARCH} == alpha
. if ${CPUTYPE} == ev6
Index: make.conf
===
RCS file: /home/ncvs/src/etc/defaults/Attic/make.conf,v
retrieving revision 1.97.2.70
diff -u -3 -p -r1.97.2.70 make.conf
--- make.conf 2002/07/18 13:34:52 1.97.2.70
+++ make.conf 2002/07/24 03:35:51
@@ -22,7 +22,7 @@
# NO_CPU_CFLAGS variable below.
# Currently the following CPU types are recognized:
# Intel x86 architecture:
-# (AMD CPUs) k7 k6-2 k6 k5
+# (AMD CPUs) athlon-xp athlon-mp athlon-4 k7 k6-2 k6 k5
# (Intel CPUs) p4 p3 p2 i686 i586/mmx i586 i486 i386
# Alpha/AXP architecture: ev6 pca56 ev56 ev5 ev45 ev4
#
__
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
--
_
| |V| / ' || MacroHard -- \
\_| | | \_, || the perfection of form over |
--|| substance, marketing over |
Web: http://www.borgsdemons.com || performance, and greed over |
AIM: johnmcooper || design . . .|
Re: Do VIA 83C572 USB controllers suck or is it just me?
On Wed, 2002-07-10 at 20:33, Nick Sayer wrote: I have a desktop machine with an Asus A7V133 motherboard. It's based around the VIA KT133A chipset. I tend to have a lot more problems with USB devices (under FreeBSD) on these controllers than with, say, my Vaio laptop, which purports to be based on the Intel 440 BX chipset (with a PIIX4 USB controller). The latest outrage is that I am doing some work on a USB audio device driver to clean it up a bit. It works *perfectly* plugged into the Vaio, but when it's plugged into the Asus machine, I get a trap panic the instant I try and play anything. I can't diagnose the trap because the dump doesn't happen, for unknown reasons. I'm almost at the point of going out and getting a PCI USB controller card for the damn thing. Is it just me? Well, my DFI AK74-EC works fine with USB devices (ZIP drive and a camera) and has the KT133A chipset. The only limitation I have experienced is camera (and not motherboard) related--my Fuji FinePix 4900Z is recognized only at a ugen and not as a umass. I'm still scratching my head on that one. But the USB works fine otherwise. -- _ | |V| / ' || MacroHard -- \ \_| | | \_, || the perfection of form over | --|| substance, marketing over | Web: http://www.borgsdemons.com || performance, and greed over | AIM: johnmcooper || design . . .| =/ Public Key: http://www.borgsdemons.com/Personal/pgpkey.asc | =\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Buildworld broken in -STABLE no usr.sbin/i4b/man/ifpi2.4 manpage
On Sat, 2002-04-27 at 14:33, Jeremy L. Stock wrote: Looks like /usr/sbin/i4b/man/ifpi2.4 was never MFC'ed so the Makefile commit by gj 1.2.2.4 breaks the build. I have the same problem here. Could someone please MFC ifpi2.4? -- _ | |V| / ' || MacroHard -- \ \_| | | \_, || the perfection of form over | --|| substance, marketing over | Web: http://www.borgsdemons.com || performance, and greed over | AIM: johnmcooper || design . . .| =/ Public Key: http://www.borgsdemons.com/Personal/pgpkey.asc | =\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: 4.4-STABLE hanging problem with ibm thinkpad laptop
On 2001.11.03 23:08 Jason Hunt wrote: I have an IBM Thinkpad 560E laptop. I was running a 4.4-STABLE from September, and it was great. I cvsup'd to 4.4-STABLE on November 3rd, and now when I reboot or shutdown, it kills daemons, synch's disks, and shows the uptime. Normally it would either reboot or turn the machine off, or tell you to press and key to reboot and you can turn it off manually. Instead, it hangs and I have to hard-reboot the machine. Any help? The generic kernel did this as well. Actually, the behavior you have now is 90% of what is supposed to happen. Something was wrong if you weren't seeing the daemons get killed, syncing of disks, etc. It looks like the problem is that you're getting a shutdown even when you want a reboot. Well, the laptop types should be able to suggest some kernel options that might get you somewhere there, but it sounds like cycling power at the end of the shutdown will get you most of what you want. Obviously, since I don't have a laptop running FreeBSD, your mileage may vary . . . -- jmc || MacroHard --\ || the perfection of form over | --|| substance, marketing over | Web: http://www.borgsdemons.com || performance, and greed over | || design . . . | ===/ Public Key: http://www.borgsdemons.com/Personal/pgpkey.asc| ===\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: [Fwd: Warning: could not send message for past 4 hours]
On 2001.10.01 12:54 Michael Sierchio wrote: WTF is this happening? You have a reverse-DNS problem(s) with your e-mail. FreeBSD.org is setup to reject mail that doesn't satisfy reverse-DNS tests. It's an anti-SPAM measure increasingly common on the net. Scream at your ISP to get their DNS configuration fixed--it took mine quite awhile . . . :( -- jmc MacroHard -- the perfection of form over substance, marketing over performance, and greed over design . . . To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: KDE 2.2 4.4
On Wed, Aug 15, 2001 at 07:00:05PM -, [EMAIL PROTECTED] wrote: What are the chances of KDE 2.2 making it into the ports tree before 4.4 is - RELEASE'd? ---end quoted text--- I believe KDE 2.2 is already in the ports tree. At least, that's what appears to be building on my machine at the moment . . . jmc PGP signature
Re: question about wc on for NON-critical workstation (no flamebait)
On 2001.07.24 10:09 j mckitrick wrote: For day to day use (programming, netscape, email, etc) will wc on show any performance improvement? jcm -- o-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-o | Jonathon McKitrick ~ | | I prefer the term 'Artificial Person' myself. | o-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-o To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message Try it . . . the answer is yes . . . and like everything else in life (especially entities that are built for speed), it's a calculated risk. jmc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: make world every week?
On 2001.07.24 19:41 jett wrote: im running freebsd 4.3-stable and every friday night i'm updating my sources via cvsup. my question is do i have to always build the world after every cvsup so that i may stay stable? jett Please turn off the double-pump of HTML. It makes replying a mess . . . No. I cvsup frequently, but I only make when something of interest has changed. Then I make world make kernel KERNCONF=your_kernel_config. jmc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Strange mouse bahviour in FBSD 4.3 and XFree86 4.1.0
On 2001.06.20 13:58 Hartmann, O. wrote: Dear Sirs. I posted here several postings about a problem with one of our FBSD 4.3-STABLE boxes. This machine has been cvsupdated today, XFRee864.1.0_4 has been installed several days ago (by a fresh compilation). One of the earlier problems is the following: I can not shutdown this machine by being remotely loged in using shutdown -r now. I always have to use shutdown -r -o now to do the task. On all other maschines that works! The machine I speak about is a AMD K7 800 MHz based on ASUS A7V PCB and IBM DTLA 307030. The videoadaptor is a ELSA Erazor III Pro. See the following dmesg-output . The new problem is hard to describe. It seems one way like a hardware fault, but another way the fault of some FBSD subsystems. Description: Using /dev/sysmouse and moused as the basic mouse system, we have a Logitech optical USB port mouse attached to this machine. The USB mouse is connected to a HUB located at a Iiyama 18 inch LCD screen (bit that doesn't matter, I tried the USB port directly or a PS/2 mouse with the same effect). On the X11 screen, the mouse rushes uncontrollable over the screen, jumping, shivers around, not reacting on pressed buttons. It looks like having used the wrong protocol with earlier XFree types. But there is no misconfiguration, this configuration worked since approximately I switched over to XFree86 4.1.0 and/or did a cvsupdate. When leaving the X-session, Xserver drops a core, reporting something about an illegal instruction after resetting the mouese! When in terminal mode (no X), the mouse shivers and jumps also uncontroleable on the screen. I exchanged the mouese with a simple PS/2 mouse and sometimes I have a pointer, sometimes not (using sysmouse/moused). In X11 the phenomenon of a jumping and rushing mouse is not as obvious as with the USB type, but it is also faulty. The mouse disappears or is unuseable. The kernel reports a mouse at psm0, but in X (chooser) there is no access/movement of it. Sometimes, while having luck moving it around, it seems to drop spontanously button presses around. This machine is without graphical device or mouse accessible and works perfect. I can use it remotely without problems. It seems really to be related to something like sysmouse/moused/mouse/XFree86 or FreeBSD's driver for the mouse system. Does anyone heared about such strange things due a bug of FreeBSD/XFree86 4.1.0? If not, this really seems to be a massive hardware related problem. On the other hand: We have a lot of self-made X11 Terminals around here for our students, based on a DFI AK74EC main PCB, Duron 700, Gigabyte GA660+ video board, using Logitech 3 button PS/2 mice. They are cvsupdated 7 days ago, XFree86 4.1.0 has been build several days ago. These diskless booting terminals do not show any kind of disruption of mouse access or movement ... -- MfG O. Hartmann [EMAIL PROTECTED] IT-Administration des Institut fuer Physik der Atmosphaere (IPA) Johannes Gutenberg Universitaet Mainz Becherweg 21 55099 Mainz Tel: +496131/3924662 (Maschinensaal) Tel: +496131/3924144 FAX: +496131/3923532 I have had similar, but less severe, experiences recently with my mouse--a Logitech MouseMan+. I don't get the illegal instruction error as above (but this maybe because I use startx and OH uses xdm?) But the erratic mouse cursor and the dropping of random clicks makes XFree86-4 operation somewhat more painful than I'd like at the moment. My configuration: Adapter: Diamond Mutlimedia Viper 770 Ultra (nVidia TNT2 Ultra with 32 megs) Mouse: Logitech MouseMan+ connected to PS/2 port jmc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: unknown option TCP_RESTRICT_RST ?
On 2001.06.10 13:05 Nuno Teixeira wrote: Hello to all, I allways used TCP_RESTRICT_RST on my firewall/kernel configuration. I'm tracking STABLE and the last build was on 2001-06-06. Today, 2001-06-10, when I'm make buildkernel I got the error: unknown option TCP_RESTRICT_RST . Does this option has been deprecated? Thanks very much, -- Nuno Teixeira Dir. Técnico pt-quorum.com I believe support for it needs to be compiled-in to your kernel. Look at LINT, etc. for details. jmc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
make world broken in kerberosIV
Using the lastest cvsup (about 30 minutes old now), make world dies while building in kerberosIV. Several undefined references in sra.o (all to symbols beginning with pam_) occur. This file is in ./kerberosIV/libexec/telnetd/. jmc P.S. Something's screwy with sendmail, won't send through my remote smtp server to FreeBSD.org anymore. Bummer . . . :) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Frankenstein Port: /usr/ports/www/jakarat-tomcat
John Polstra wrote: In article [EMAIL PROTECTED], Kent Stewart [EMAIL PROTECTED] wrote: David W. Chapman Jr. wrote: That's just it I believe the problem is fixed, or at the cvs one, not the cvsup one(if there is a problem with cvsup). Once you delete your checkout file all is well and fixed No, it isn't fixed or at least because a very recent update from cvsup13 doesn't work. The first thing it does is checkout the two patch files and tomcat.sh. Then, it tries to delete the directory, which fails because it isn't empty. Let me try to clear up the confusion. There's a combination of things going on. 1. There was a problem in the CVS repository. I fixed that manually during the weekend. The repository is fine now. 2. My manual fix of the repository provoked a bug in CVSup which is affecting some people. I had run a bunch of tests before making the repository fix, but my tests were inadequate to find this particular problem. I know more or less what is happening and will be able to fix the bug, but you shouldn't wait for that. You should work around it (see below). 3. The nature of the bug is such that it creates a bogus entry in the checkouts file. That causes the problem to keep happening until the checkouts file is repaired manually or removed. I posted instructions on how to fix the file in a separate mail. Basically, you have to edit the checkouts file and delete all lines containing jakarta-tomcat. 4. Removing the checkouts file works too, but it's a sledge hammer approach and is better avoided. There's useful information in there, so it's better not to throw it away. 5. Somebody suggested adding an entry to the refuse file to ignore the jakarta-tomcat port. That probably hides the problem, but it doesn't really fix anything. The breakage is still there in your checkouts file. Therefore I don't recommend using the refuse file as a work-around. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa Yes, nuking /usr/sup/ports-all/checkout.cvs:. works. Might be nice if this feature of cvs was quashed with a fairly heavy sledge hammer. :) jmc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: make world still broken around krb4_version bug--when will the patch reach stable?
Nat Lanza wrote: John Merryweather Cooper [EMAIL PROTECTED] writes: I'm open to other suggestions, and I'll do the rm -rfd /usr/src if I absolutely have to, but I'd rather avoid it. I just tried deleting /usr/src, re-cvsupping, and rebuilding, and it still dies at the same spot as others have reported: cc -O -pipe -march=pentiumpro -I/usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/include -I/usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I/usr/src/kerberos5/lib/libasn1/../../include -I/usr/obj/usr/src/kerberos5/lib/libasn1 -Wall -I/usr/src/kerberos5/lib/libasn1/../../include -I/usr/src/kerberos5/lib/libasn1/../../include -DHAVE_CONFIG_H -DKRB5_KRB4_COMPAT -DKRB4 -DINET6 -static -o make-print-version /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken/make-print-version.c In file included from /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken/make-print-version.c:49: /usr/src/kerberos5/lib/libasn1/../../include/version.h:3: conflicting types for `krb4_version' /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken/make-print-version.c:47: previous declaration of `krb4_version' *** Error code 1 Stop in /usr/src/kerberos5/lib/libasn1. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Clearly, this isn't an artifact of a corrupted local copy of the tree; I think it's genuinely broken, and would love to see a fix. --nat -- nat lanza --- there are no whole truths; [EMAIL PROTECTED] all truths are half-truths http://www.cs.cmu.edu/~magus/ --- -- alfred north whitehead Then I won't bother zapping /usr/src. Your make tail is identical to mine. jmc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: problem with plip stealing clock
Peter Jeremy wrote: On 2001-Apr-30 08:29:31 -0700, John Merryweather Cooper [EMAIL PROTECTED] wrote: While using my main workstation as a local FTP for my laptop over plip, I noticed that FreeBSD was losing track of time at a prodigious rate. PLIP receives/transmits each IP packet inside a loop at splhigh(). If either system is slow, or the MTU is too high, the time taken to transfer each packet can exceed 1 tick - meaning that clock interrupt is lost. Other PIO peripherals (ethernet or disk) will aggravate the problem. I suspect transfering between a AMD Duron 700 and an Intel 386SX/20 qualifies . . . :) Couldn't the plip interface arbitrate this though by driving it's bus cycle at the pace of the slowest system? I'm sure, in practice, that the rarest use of plip is between two machines of nearly equal CPU speed. Probably, my use is fairly typical. If my damn laptop had a network port, I'd use that--but the Token Ring 16/4 Adapter seems as rare a gold for my ancient AST Premium Exec 386SX/20 . . . :) Probably wouldn't work with FreeBSD anyway . . . bummer. I did have the problem with PLIP between my 386 laptop and 486 desktop until I reduced the MTU to 512. Anything magical about 512 (or is lower better here). If lower is better, how low can I go (I guess I'll find out). Have you considered using a PPP link running at 115.2kbps instead? You will find it a lot more CPU friendly. Yes. Not looking forward to buying yet another single-purpose cable. The null modem I have doesn't seem to do the trick anymore. Peter jmc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: problem with plip stealing clock
Thomas T. Veldhouse wrote: Sounds like hardware to me. You probably want to run a time program via cron to periodically update the clock rate. Well, that may be, but it was pretty well-behaved hardware until I used plip--no clock drift whatsoever. I have the daemon running at boot to update off of an external time source, but it seems pretty clear to me that the timer tick interrupt is getting clobbered--else why the drift only when plip is running a transfer? jmc Tom Veldhouse [EMAIL PROTECTED] - Original Message - From: John Merryweather Cooper [EMAIL PROTECTED] To: FreeBSD-STABLE Mailing List [EMAIL PROTECTED] Sent: Monday, April 30, 2001 10:29 AM Subject: problem with plip stealing clock While using my main workstation as a local FTP for my laptop over plip, I noticed that FreeBSD was losing track of time at a prodigious rate. Over about five hours of downloading to my laptop, my main workstation lost close to 3.5 hours of time off its clock. During pulses of IO, the mouse also becomes very sluggish under X. I'd expect some slowdown because FreeBSD doesn't appear to use the DMA channel, but I never expected to see the affect on the clock--e.g., this message will say about 8:30 when the real time here is more like 12:00. Sounds like a bug to me . . . Any thoughts on how to work around/solve this? jmc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: XTERM
"Robert T.G. Tan" wrote: I tried /etc/ttys: ttyv5 "/usr/X11R6/bin/xdm -nodaemon" xterm-color on secure but I didn't get the xterm-color value for TERM. Also looked for some resource that would define the TERM value, but couldn't find it.. tnx, rotan. Robert T.G. Tan([EMAIL PROTECTED])@2001.04.22 12:40:46 +: Where does TERM get set, if not in ~/.*rc, or /etc/whatever-default-configs I by-pass the X resource stuff (which I haven't quite figured out) and use the following in my .shrc # for non-X sessions use Java 1.1.8 JAVA_HOME=/usr/local/jdk1.1.8; export JAVA_HOME # adjust TERM to color xterm under X # use linux Java under X if [ $TERM = "xterm" ]; then TERM=xterm-color; export TERM JAVA_HOME=/usr/local/linux-jdk1.3.0; export JAVA_HOME fi # add appropriate java to path JAVA_PATH=$JAVA_HOME/bin PATH=$JAVA_PATH:$PATH; export PATH This allows me to do two things: 1) display color directory listings in Gnome-Term, rxvt, and/or eterm; and 2) switch my java from 1.1.8 to the linux-1.3.0 for all my X sessions (so that Star Office works somewhat better). jmc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
