conf/161835: SVN-detection in sys/conf/newvers.sh fails with subversion-1.7

2011-10-20 Thread David Wolfskill 

>Number: 161835
>Category:   conf
>Synopsis:   SVN-detection in sys/conf/newvers.sh fails with subversion-1.7
>Confidential:   no
>Severity:   non-critical
>Priority:   medium
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Oct 20 15:40:11 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: David Wolfskill
>Release:FreeBSD 10.0-CURRENT i386
>Organization:
Wolfkill & owling Residence
>Environment:
System: FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #626 
r226563M: Thu Oct 20 05:04:03 PDT 2011 
r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386

>Description:
Stock version of sys/conf/newvers.sh looks for ${SYSDIR}/.svn
to determine if ${SYSDIR} is likely to be a subversion working
copy.

This is fine for subsversion-1.6 (and earlier), but as of 1.7,
the only .svn subdirectory in the working copy is at the root of
the working copy.

As a result, if subversion-1.7 is in use, newvers.sh fails to
detect that ${SYSDIR} could be a subversion working copy, and
therefore fails to try to invoke svnversion, so the SVN GRN
doesn't get placed in the uname output -- rather than the above,
it looks more like:

FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #625: Wed 
Oct 19 05:22:52 PDT 2011 
r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC  i386

>How-To-Repeat:
Upgrade to or install the 1.7 version of the devel/subversion
port, ensure that /usr/src is a subversion working copy suitable
for use with subversion-1.7 (and that kernel sources have been
modified), then rebuild the kernel.

After rebooting, examine the output of "uname -a".
>Fix:
Index: sys/conf/newvers.sh
===
--- sys/conf/newvers.sh (revision 226563)
+++ sys/conf/newvers.sh (working copy)
@@ -88,7 +88,7 @@
 i=`${MAKE:-make} -V KERN_IDENT`
 
 for dir in /bin /usr/bin /usr/local/bin; do
-   if [ -d "${SYSDIR}/.svn" -a -x "${dir}/svnversion" ] ; then
+   if [ -d "${SYSDIR}/../.svn" -a -x "${dir}/svnversion" ] ; then
svnversion=${dir}/svnversion
break
fi

[Note: I have tested the above; that's how the original "uname" output
(at the top of the PR) was created; note that it shows the GRN.]
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

misc/161837: sysinstall has a 32 disk limit

2011-10-20 Thread Tim Brody 

>Number: 161837
>Category:   misc
>Synopsis:   sysinstall has a 32 disk limit
>Confidential:   no
>Severity:   serious
>Priority:   low
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Oct 20 16:20:05 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Tim Brody
>Release:8.20
>Organization:
University of Southampton
>Environment:
n/a
>Description:
sysinstall calls libdisk/Disk_Names that has a hard-limit of 32 disk devices. 
On systems (e.g. Sun X4540) with more disks than this some drives will be 
silently ignored. On the X4540 the missing drives include the 4 bootable 
devices, making it impossible to install with sysinstall/fdisk (hence 
severity=high).

This problem was first identified 10 years ago when the number was bumped from 
20 to 32 - http://www.cz.freebsd.org/pub/FreeBSD-cvs/gnats/conf/24503.


Further (but unpatched), sysinstall/devices.c does not free the contents of the 
disks array so will cause a memory leak.
>How-To-Repeat:

>Fix:
Apply attached patch to libdisk, recompile/reinstall libdisk and sysinstall.

Patch attached with submission follows:

Index: libdisk.h
===
--- libdisk.h   (revision 226570)
+++ libdisk.h   (working copy)
@@ -17,9 +17,6 @@
 /* You can define a particular architecture here if you are debugging. */
 /* #define P_DEBUG p_sparc64 */
 
-#define MAX_NO_DISKS   32
-/* Max # of disks Disk_Names() will return */
-
 #define MAX_SEC_SIZE2048  /* maximum sector size that is supported */
 #define MIN_SEC_SIZE   512   /* the sector size to end sensing at */
 
Index: disk.c
===
--- disk.c  (revision 226570)
+++ disk.c  (working copy)
@@ -190,7 +190,7 @@
 char **
 Disk_Names()
 {
-   int disk_cnt;
+   int i, disk_cnt;
char **disks;
int error;
size_t listsize;
@@ -205,30 +205,36 @@
if (listsize == 0)
return (NULL);
 
-   disks = malloc(sizeof *disks * (1 + MAX_NO_DISKS));
-   if (disks == NULL)
+   disk1 = disklist = (char *)calloc(listsize + 1, sizeof *disklist);
+   if (disklist == NULL)
return NULL;
-   disk1 = disklist = (char *)malloc(listsize + 1);
-   if (disklist == NULL) {
-   free(disks);
-   return NULL;
-   }
-   memset(disks,0,sizeof *disks * (1 + MAX_NO_DISKS));
-   memset(disklist, 0, listsize + 1);
+
error = sysctlbyname("kern.disks", disklist, &listsize, NULL, 0);
if (error || disklist[0] == 0) {
free(disklist);
-   free(disks);
return NULL;
}
-   for (disk_cnt = 0; disk_cnt < MAX_NO_DISKS; disk_cnt++) {
+
+   disk_cnt = 1;
+   for (i = 0; i < listsize; ++i) {
+   if (disklist[i] == ' ')
+   disk_cnt++;
+   }
+
+   disks = calloc(disk_cnt + 1, sizeof *disks);
+   if (disks == NULL) {
+   free(disklist);
+   return NULL;
+   }
+
+   for (i = 0; i < disk_cnt; ++i) {
disk2 = strsep(&disk1, " ");
if (disk2 == NULL)
break;
-   disks[disk_cnt] = strdup(disk2);
-   if (disks[disk_cnt] == NULL) {
-   for (disk_cnt--; disk_cnt >= 0; disk_cnt--)
-   free(disks[disk_cnt]);
+   disks[i] = strdup(disk2);
+   if (disks[i] == NULL) {
+   for (i--; i >= 0; i--)
+   free(disks[i]);
free(disklist);
free(disks);
return (NULL);


>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/161721: [boot] compiling kernel with KVA_PAGES=512 does not allow system to boot

2011-10-20 Thread Alan Cox 

On 10/19/2011 15:58, Remko Lodder wrote:

Hello Kes,

Thank you for responding to my closure. Sadly the PR list should 
contain only
Problem REcords (PR's) so personally I do not think a wish list item 
should be

kept open.

Though, we might want to ask Alan whether this is something we can and 
will work

at or not. If the latter, well it's a pity but then we won't work on it.



Kes,

Your problem report doesn't include any details on the panic that 
occurs.  Could you please provide this?


Is this problem occurring with or without the use of PAE?  If I presume 
that you are not using PAE, then setting KVA_PAGES to 512 makes the 
kernel address space 2 GB in size.


Have you ever tried a slightly smaller setting for KVA_PAGES, for 
example, 508?


Remko,

I suspect this a bug, specifically, arithmetic overflow is occurring 
somewhere because 32-bit arithmetic is being used and the kernel address 
space is 2^31 bytes in size.


I would recommend that you reopen this PR, and assign it to me.  While 
you can certainly shoot yourself in the foot by messing with low-level 
configuration, like KVA_PAGES, in this case, I think we may have a bug.


Alan



On Oct 19, 2011, at 8:55 PM, Коньков Евгений wrote:



rFo> Synopsis: [boot] compiling kernel with KVA_PAGES=512 does not 
allow system to boot


rFo> State-Changed-From-To: open->closed
rFo> State-Changed-By: remko
rFo> State-Changed-When: Tue Oct 18 18:27:15 UTC 2011
rFo> State-Changed-Why:
rFo> If you fiddle with kernel settings you should be aware of what 
you are
rFo> doing. The KVA pages is a problem that popped up before and is 
mentioned

rFo> enough. I do not think this is a PR worth, apologies if this offends
rFo> you.

rFo> http://www.freebsd.org/cgi/query-pr.cgi?pr=161721


This is option to make FreeBSD better, so may be some developer in
future see this weakness and implements that.
If it will be closes it will be fogotten
So may be reopen it with very low priority as wish list, not PR

Thank you

--
С уважением,
Коньков mailto:kes-...@yandex.ru



--
/"\   With kind regards,| re...@elvandar.org 
\ /   Remko Lodder| re...@freebsd.org 
XFreeBSD| http://www.evilcoder.org
/ \   The Power to Serve| Quis custodiet ipsos custodes



___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/161721: [boot] compiling kernel with KVA_PAGES=512 does not allow system to boot

2011-10-20 Thread remko 
Synopsis: [boot] compiling kernel with KVA_PAGES=512 does not allow system to 
boot

State-Changed-From-To: closed->open
State-Changed-By: remko
State-Changed-When: Thu Oct 20 19:22:24 UTC 2011
State-Changed-Why: 
Per request of Alan, reopen the ticket and assign it to him.
Thanks for taking care of this Alan!


Responsible-Changed-From-To: freebsd-bugs->alc
Responsible-Changed-By: remko
Responsible-Changed-When: Thu Oct 20 19:22:24 UTC 2011
Responsible-Changed-Why: 
Per request of Alan, reopen the ticket and assign it to him.
Thanks for taking care of this Alan!

http://www.freebsd.org/cgi/query-pr.cgi?pr=161721
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re[2]: kern/161721: [boot] compiling kernel with KVA_PAGES=512 does not allow system to boot

2011-10-20 Thread Коньков Евгений 

   Hi

   >

   On 10/19/2011 15:58, Remko Lodder wrote:


   Hello Kes,

   Thank you for responding to my closure. Sadly the PR list should
   contain only

   Problem REcords (PR's) so personally I do not think a wish list item
   should be

   kept open.

   Actually, as I think, may be I have wrong, but I think so. I have a
   'Problem' so I 'Report' it.

   Thank you for your attention.

   >

   Though, we might want to ask Alan whether this is something we can and
   will work

   at or not. If the latter, well it's a pity but then we won't work on
   it.

   Kes,

   Your problem report doesn't include any details on the panic that
   occurs.  Could you please provide this?

   [1]http://www.freebsd.org/cgi/query-pr.cgi?pr=161458

   Here I make new slice and compile and install world and kernel to that
   slice and trying to boot from it.

   I get system halted on this stage:

   Oct 10 13:52:22 syslogd: kernel boot file is /boot/kernel/kernel

   Oct 10 13:52:22 kernel: Copyright (c) 1992-2011 The FreeBSD Project.

   Oct 10 13:52:22 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988,
   1989, 1991, 1992, 1993, 1994

   Oct 10 13:52:22 kernel: The Regents of the University of California.
   All rights reserved.

   Oct 10 13:52:22 kernel: FreeBSD is a registered trademark of The
   FreeBSD Foundation.

   Oct 10 13:52:22 kernel: FreeBSD 9.0-BETA2 #11: Thu Oct 6 18:02:28 EEST
   2011

   Oct 10 13:52:22 kernel: @:/usr/obj/usr/src/sys/KES_KERN_v9 i386

   But as I discover later it was a bug (problem) with KVA_PAGES, I have
   added that option to GENERIC

   and in new installed slice I have no /boot/loader.conf file, so system
   is halt.

   on old slice I have /boot/loader.conf, so I have no problem with
   KVA_PAGES option.

   I know, that FreeBSD automatically reboot if something nasty is
   happen.

   but in this case even no coredumps are present.

   >

   Is this problem occurring with or without the use of PAE?  If I
   presume that you are not using PAE, then setting KVA_PAGES to 512
   makes the kernel address space 2 GB in size.

   Have you ever tried a slightly smaller setting for KVA_PAGES, for
   example, 508?

   Ok, I will try 508 and report results.

   >

   Remko,

   I suspect this a bug, specifically, arithmetic overflow is occurring
   somewhere because 32-bit arithmetic is being used and the kernel
   address space is 2^31 bytes in size.

   I would recommend that you reopen this PR, and assign it to me.  While
   you can certainly shoot yourself in the foot by messing with low-level
   configuration, like KVA_PAGES, in this case, I think we may have a
   bug.

   I do not know how to reopen, there is no any such button // ((

   Please describe where I can read about how to reopen?

   >

   Alan

   On Oct 19, 2011, at 8:55 PM, Kon'kov Evgenij wrote:

   rFo> Synopsis: [boot] compiling kernel with KVA_PAGES=512 does not
   allow system to boot

   rFo> State-Changed-From-To: open->closed

   rFo> State-Changed-By: remko

   rFo> State-Changed-When: Tue Oct 18 18:27:15 UTC 2011

   rFo> State-Changed-Why:

   rFo> If you fiddle with kernel settings you should be aware of what
   you are

   rFo> doing. The KVA pages is a problem that popped up before and is
   mentioned

   rFo> enough. I do not think this is a PR worth, apologies if this
   offends

   rFo> you.

   rFo> [2]http://www.freebsd.org/cgi/query-pr.cgi?pr=161721

   This is option to make FreeBSD better, so may be some developer in

   future see this weakness and implements that.

   If it will be closes it will be fogotten

   So may be reopen it with very low priority as wish list, not PR

   Thank you

   --

   S uvazheniem,

   Kon'kov  [3]mailto:kes-...@yandex.ru

   --

   /"\   With kind regards,   | [4]re...@elvandar.org

   \ /   Remko Lodder   | [5]re...@freebsd.org

   XFreeBSD   | [6]http://www.evilcoder.org

   / \   The Power to Serve  | Quis custodiet ipsos custodes

   --

   S uvazheniem,

Kon'kov  [7]mailto:kes-...@yandex.ru

References

   1. http://www.freebsd.org/cgi/query-pr.cgi?pr=161458
   2. http://www.freebsd.org/cgi/query-pr.cgi?pr=161721
   3. mailto:kes-...@yandex.ru
   4. mailto:re...@elvandar.org
   5. mailto:re...@freebsd.org
   6. http://www.evilcoder.org/
   7. mailto:kes-...@yandex.ru
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/161837: [libdisk] [patch] sysinstall(8) has a 32 disk limit

2011-10-20 Thread linimon 
Old Synopsis: sysinstall has a 32 disk limit
New Synopsis: [libdisk] [patch] sysinstall(8) has a 32 disk limit

Responsible-Changed-From-To: freebsd-bugs->freebsd-sysinstall
Responsible-Changed-By: linimon
Responsible-Changed-When: Thu Oct 20 19:34:42 UTC 2011
Responsible-Changed-Why: 
reclassify and assign.

http://www.freebsd.org/cgi/query-pr.cgi?pr=161837
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: conf/161843: SVN-detection in sys/conf/newvers.sh fails with subversion-1.7

2011-10-20 Thread linimon 
Synopsis: SVN-detection in sys/conf/newvers.sh fails with subversion-1.7

State-Changed-From-To: open->closed
State-Changed-By: linimon
State-Changed-When: Thu Oct 20 19:36:52 UTC 2011
State-Changed-Why: 
Duplicate of conf/161835.

http://www.freebsd.org/cgi/query-pr.cgi?pr=161843
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

bin/161846: bsdgrep causes regression in www/firefox port

2011-10-20 Thread Guido Falsi 

>Number: 161846
>Category:   bin
>Synopsis:   bsdgrep causes regression in www/firefox port
>Confidential:   no
>Severity:   non-critical
>Priority:   low
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Oct 20 23:10:09 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Guido Falsi
>Release:9.0-RC1
>Organization:
none
>Environment:
amd64 9.0-RC1

(sorry I don't have the affected machine available right now. I'll followup 
with the full details)
>Description:
On the affected machine I have 9.0-RC1 and WITH_BSD_GREP defined in src.conf.

Today I tried rebuilding the firefox port and it failed in a strange way on the 
file mozilla-release/js/src/jslock.cpp.

The problem disappeared after replacing gnugrep as the default grep.

After investigation I found out the problem happens in the configure stage, two 
files are generated in that directory: js-confdefs.h  and js-config.h.

in jsconfdefs there is a "#define JS_THREADSAFE 1" line, while in js-config I 
find "#undef JS_THREADSAFE", this breaks the build due to the order in which 
these two files are included. With gnugrep the files have the same define.(why 
the firefox build system should put the same defines in two files is beyond me, 
BTW)

I'm still trying to investigate this one further to identify exactly where is 
the faulty invocation of grep. I'm anyway posting this PR since this is already 
fully reproducible and maybe someone with a better knowledge about the firefox 
build process or the autotools can find the exact point of failure faster than 
me.

Here are the full files.

js-confdefs.h:
/* List of defines generated by configure. Included with preprocessor flag,
 * -include, to avoid long list of -D defines on the compile command-line.
 * Do not edit.
 */

#ifndef _JS_CONFDEFS_H_
#define _JS_CONFDEFS_H_

#define AVMPLUS_64BIT 1
#define AVMPLUS_AMD64 1
#define AVMPLUS_UNIX 1
#define CPP_THROW_NEW throw()
#define D_INO d_ino
#define EDITLINE 1
#define FEATURE_NANOJIT 1
#define HAVE_64BIT_OS 1
#define HAVE_CLOCK_MONOTONIC 1
#define HAVE_CPP_ACCESS_CHANGING_USING 1
#define HAVE_CPP_AMBIGUITY_RESOLVING_USING 1
#define HAVE_CPP_DYNAMIC_CAST_TO_VOID_PTR 1
#define HAVE_CPP_EXPLICIT 1
#define HAVE_CPP_MODERN_SPECIALIZE_TEMPLATE_SYNTAX 1
#define HAVE_CPP_NAMESPACE_STD 1
#define HAVE_CPP_NEW_CASTS 1
#define HAVE_CPP_PARTIAL_SPECIALIZATION 1
#define HAVE_CPP_TYPENAME 1
#define HAVE_CPP_UNAMBIGUOUS_STD_NOTEQUAL 1
#define HAVE_DIRENT_H 1
#define HAVE_DLADDR 1
#define HAVE_DLOPEN 1
#define HAVE_FCHMOD 1
#define HAVE_FLOCKFILE 1
#define HAVE_GETC_UNLOCKED 1
#define HAVE_GETOPT_H 1
#define HAVE_GETPAGESIZE 1
#define HAVE_I18N_LC_MESSAGES 1
#define HAVE_ICONV 1
#define HAVE_ICONV_WITH_CONST_INPUT 1
#define HAVE_INT16_T 1
#define HAVE_INT32_T 1
#define HAVE_INT64_T 1
#define HAVE_LCHOWN 1
#define HAVE_LOCALECONV 1
#define HAVE_LOCALECONV 1
#define HAVE_LOCALTIME_R 1
#define HAVE_MBRTOWC 1
#define HAVE_MEMMOVE 1
#define HAVE_MEMORY_H 1
#define HAVE_MMINTRIN_H 1
#define HAVE_NL_TYPES_H 1
#define HAVE_POSIX_FALLOCATE 1
#define HAVE_POSIX_MEMALIGN 1
#define HAVE_RANDOM 1
#define HAVE_SBRK 1
#define HAVE_SETLOCALE 1
#define HAVE_SIGINFO_T 1
#define HAVE_SNPRINTF 1
#define HAVE_SSIZE_T 1
#define HAVE_STATVFS 1
#define HAVE_STRERROR 1
#define HAVE_STRNDUP 1
#define HAVE_STRTOK_R 1
#define HAVE_ST_BLKSIZE 1
#define HAVE_SYS_CDEFS_H 1
#define HAVE_SYS_MOUNT_H 1
#define HAVE_SYS_STATVFS_H 1
#define HAVE_THREAD_TLS_KEYWORD 1
#define HAVE_TM_ZONE_TM_GMTOFF 1
#define HAVE_UINT 1
#define HAVE_UINT16_T 1
#define HAVE_UNISTD_H 1
#define HAVE_VALLOC 1
#define HAVE_VA_COPY 1
#define HAVE_VA_LIST_AS_ARRAY 1
#define HAVE_VISIBILITY_ATTRIBUTE 1
#define HAVE_VISIBILITY_HIDDEN_ATTRIBUTE 1
#define HAVE_WCRTOMB 1
#define HAVE_X11_XKBLIB_H 1
#define HAVE___CXA_DEMANGLE 1
#define JSGC_TESTPILOT 1
#define JS_ALIGN_OF_POINTER 8
#define JS_BITS_PER_WORD_LOG2 6
#define JS_BYTES_PER_DOUBLE 8
#define JS_BYTES_PER_WORD 8
#define JS_CPU_X64 1
#define JS_HAS_CTYPES 1
#define JS_HAVE_STDINT_H 1
#define JS_METHODJIT 1
#define JS_MONOIC 1
#define JS_POLYIC 1
#define JS_POLYIC_TYPED_ARRAY 1
#define JS_PUNBOX64 1
#define JS_THREADSAFE 1
#define JS_TRACER 1
#define MALLOC_H 
#define MOZ_DLL_SUFFIX ".so"
#define NEW_H 
#define NS_ALWAYS_INLINE __attribute__((always_inline))
#define NS_ATTR_MALLOC __attribute__((malloc))
#define NS_NORETURN __attribute__((noreturn))
#define NS_WARN_UNUSED_RESULT __attribute__((warn_unused_result))
#define STATIC_EXPORTABLE_JS_API 1
#define STDC_HEADERS 1
#define UNIX_ASYNC_DNS 1
#define VA_COPY va_copy
#define XP_UNIX 1
#define _REENTRANT 1
#define _THREAD_SAFE 1

#endif /* _JS_CONFDEFS_H_ */

js-config.h:
/* js-config.h.  Generated automatically by configure.  */
/* -*- Mode: C; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 4 -*-
 * vim: set ts=8 sw=4 et tw=78:
 *
 * * BEGIN LICENSE BLOCK *

conf/161847: [patch] reaper of the dead: remove ancient devfs example

2011-10-20 Thread Eitan Adler 

>Number: 161847
>Category:   conf
>Synopsis:   [patch] reaper of the dead: remove ancient devfs example
>Confidential:   no
>Severity:   non-critical
>Priority:   low
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  change-request
>Submitter-Id:   current-users
>Arrival-Date:   Thu Oct 20 23:10:10 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Eitan Adler
>Release:
>Organization:
>Environment:
>Description:
x11@ no longer sees the need to keep "vga" example in /etc/devfs.conf
>How-To-Repeat:

>Fix:


Patch attached with submission follows:

Index: devfs.conf
===
--- devfs.conf  (revision 226554)
+++ devfs.conf  (working copy)
@@ -31,9 +31,6 @@
 #
 # Examples:
 
-# Historically X depended on this, but version 4.3.0 doesn't seem to anymore
-#link  ttyv0   vga
-
 # Commonly used by many ports
 #link  acd0cdrom
 


>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: bin/161846: bsdgrep causes regression in www/firefox port

2011-10-20 Thread Nali Toja 
The following reply was made to PR bin/161846; it has been noted by GNATS.

From: Nali Toja 
To: Guido Falsi 
Cc: bug-follo...@freebsd.org
Subject: Re: bin/161846: bsdgrep causes regression in www/firefox port
Date: Thu, 20 Oct 2011 23:48:20 +

 Guido Falsi  writes:
 
 >>Environment:
 > amd64 9.0-RC1
 
 What revision it's based on? Do you have /stable/9@226573 commit?
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

kern/161854: _gsskrb5_pname_to_uid lname lookup fails, breaks nfs/kerberos

2011-10-20 Thread Harry Coin 

>Number: 161854
>Category:   kern
>Synopsis:   _gsskrb5_pname_to_uid lname lookup fails, breaks nfs/kerberos
>Confidential:   no
>Severity:   serious
>Priority:   high
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Oct 21 04:00:19 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Harry Coin
>Release:8Stable
>Organization:
Quiet Fountain LLC
>Environment:
amd64
>Description:
Notice in

http://svnweb.freebsd.org/base/head/kerberos5/lib/libgssapi_krb5/pname_to_uid.c?revision=181344&view=markup

..
OM_uint32
34  _gsskrb5_pname_to_uid(OM_uint32 *minor_status, const gss_name_t pname,
35  const gss_OID mech, uid_t *uidp)
36  {
37  krb5_context context;
38  krb5_const_principal name = (krb5_const_principal) pname;
39  krb5_error_code kret;
40  char lname[MAXLOGNAME + 1], buf[128];
41  struct passwd pwd, *pw;


52 getpwnam_r(lname, &pwd, buf, sizeof(buf), &pw);

128 is too small.  Any non-trivial use of kerberos via nfs fails to record the 
correct user names.
>How-To-Repeat:
Put some debug writes in there, you'll notice when kerberos is being used no 
user names authenticate.  kerberos on nfs is essentially broken if the total 
length of the strings in the passwd structure exceed 128 bytes.  Given the 
password itself can be 128 characters, much less the gecos, dir, shell, etc. 
etc



>Fix:
-40 char lname[MAXLOGNAME + 1], buf[128];
+40 char lname[MAXLOGNAME + 1], buf[1204];



>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: bin/161526: commit references a PR

2011-10-20 Thread dfilter service 
The following reply was made to PR bin/161526; it has been noted by GNATS.

From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: bin/161526: commit references a PR
Date: Fri, 21 Oct 2011 05:37:52 + (UTC)

 Author: trociny
 Date: Fri Oct 21 05:37:40 2011
 New Revision: 226591
 URL: http://svn.freebsd.org/changeset/base/226591
 
 Log:
   MFC r226403:
   
   In r225809 the intention was to send VEOF only once if STDIN was not a
   terminal. Unfortunately the fix was incorrect and for flushtime > 0 it
   keept sending VEOF.
   
   Sent VEOF generates ^D\b\b echoed by the terminal, which was reported
   in bin/161526. Note, we still send VEOF at least once. Otherwise
   commands like below would hang forever:
   
 echo 1 |script /tmp/script.out cat
   
   PR:  bin/161526
   Reported by: Adrian Wontroba , Stefan Bethke 

   Tested by:   Stefan Bethke 
   Approved by: re (kib)
 
 Modified:
   stable/9/usr.bin/script/script.c
 Directory Properties:
   stable/9/usr.bin/script/   (props changed)
 
 Modified: stable/9/usr.bin/script/script.c
 ==
 --- stable/9/usr.bin/script/script.c   Thu Oct 20 22:38:24 2011
(r226590)
 +++ stable/9/usr.bin/script/script.c   Fri Oct 21 05:37:40 2011
(r226591)
 @@ -163,12 +163,15 @@ main(int argc, char *argv[])
FD_SET(master, &rfd);
if (readstdin)
FD_SET(STDIN_FILENO, &rfd);
 -  if ((!readstdin && ttyflg) || flushtime > 0) {
 -  tv.tv_sec = !readstdin && ttyflg ? 1 :
 -  flushtime - (tvec - start);
 +  if (!readstdin && ttyflg) {
 +  tv.tv_sec = 1;
tv.tv_usec = 0;
tvp = &tv;
readstdin = 1;
 +  } else if (flushtime > 0) {
 +  tv.tv_sec = flushtime - (tvec - start);
 +  tv.tv_usec = 0;
 +  tvp = &tv;
} else {
tvp = NULL;
}
 ___
 svn-src-...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
 
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: bin/161526: commit references a PR

2011-10-20 Thread dfilter service 
The following reply was made to PR bin/161526; it has been noted by GNATS.

From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: bin/161526: commit references a PR
Date: Fri, 21 Oct 2011 05:41:40 + (UTC)

 Author: trociny
 Date: Fri Oct 21 05:40:30 2011
 New Revision: 226592
 URL: http://svn.freebsd.org/changeset/base/226592
 
 Log:
   MFC r226403:
   
   In r225809 the intention was to send VEOF only once if STDIN was not a
   terminal. Unfortunately the fix was incorrect and for flushtime > 0 it
   keept sending VEOF.
   
   Sent VEOF generates ^D\b\b echoed by the terminal, which was reported
   in bin/161526. Note, we still send VEOF at least once. Otherwise
   commands like below would hang forever:
   
 echo 1 |script /tmp/script.out cat
   
   PR:  bin/161526
   Reported by: Adrian Wontroba , Stefan Bethke 

   Tested by:   Stefan Bethke 
 
 Modified:
   stable/8/usr.bin/script/script.c
 Directory Properties:
   stable/8/usr.bin/script/   (props changed)
 
 Modified: stable/8/usr.bin/script/script.c
 ==
 --- stable/8/usr.bin/script/script.c   Fri Oct 21 05:37:40 2011
(r226591)
 +++ stable/8/usr.bin/script/script.c   Fri Oct 21 05:40:30 2011
(r226592)
 @@ -168,12 +168,15 @@ main(int argc, char *argv[])
FD_SET(master, &rfd);
if (readstdin)
FD_SET(STDIN_FILENO, &rfd);
 -  if ((!readstdin && ttyflg) || flushtime > 0) {
 -  tv.tv_sec = !readstdin && ttyflg ? 1 :
 -  flushtime - (tvec - start);
 +  if (!readstdin && ttyflg) {
 +  tv.tv_sec = 1;
tv.tv_usec = 0;
tvp = &tv;
readstdin = 1;
 +  } else if (flushtime > 0) {
 +  tv.tv_sec = flushtime - (tvec - start);
 +  tv.tv_usec = 0;
 +  tvp = &tv;
} else {
tvp = NULL;
}
 ___
 svn-src-...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
 
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: bin/161526: commit references a PR

2011-10-20 Thread dfilter service 
The following reply was made to PR bin/161526; it has been noted by GNATS.

From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: bin/161526: commit references a PR
Date: Fri, 21 Oct 2011 05:42:32 + (UTC)

 Author: trociny
 Date: Fri Oct 21 05:41:20 2011
 New Revision: 226593
 URL: http://svn.freebsd.org/changeset/base/226593
 
 Log:
   MFC r226403:
   
   In r225809 the intention was to send VEOF only once if STDIN was not a
   terminal. Unfortunately the fix was incorrect and for flushtime > 0 it
   keept sending VEOF.
   
   Sent VEOF generates ^D\b\b echoed by the terminal, which was reported
   in bin/161526. Note, we still send VEOF at least once. Otherwise
   commands like below would hang forever:
   
 echo 1 |script /tmp/script.out cat
   
   PR:  bin/161526
   Reported by: Adrian Wontroba , Stefan Bethke 

   Tested by:   Stefan Bethke 
 
 Modified:
   stable/7/usr.bin/script/script.c
 Directory Properties:
   stable/7/usr.bin/script/   (props changed)
 
 Modified: stable/7/usr.bin/script/script.c
 ==
 --- stable/7/usr.bin/script/script.c   Fri Oct 21 05:40:30 2011
(r226592)
 +++ stable/7/usr.bin/script/script.c   Fri Oct 21 05:41:20 2011
(r226593)
 @@ -167,12 +167,15 @@ main(int argc, char *argv[])
FD_SET(master, &rfd);
if (readstdin)
FD_SET(STDIN_FILENO, &rfd);
 -  if ((!readstdin && ttyflg) || flushtime > 0) {
 -  tv.tv_sec = !readstdin && ttyflg ? 1 :
 -  flushtime - (tvec - start);
 +  if (!readstdin && ttyflg) {
 +  tv.tv_sec = 1;
tv.tv_usec = 0;
tvp = &tv;
readstdin = 1;
 +  } else if (flushtime > 0) {
 +  tv.tv_sec = flushtime - (tvec - start);
 +  tv.tv_usec = 0;
 +  tvp = &tv;
} else {
tvp = NULL;
}
 ___
 svn-src-...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
 
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"