Re: Weird portupgrade error on current amd64 [and powerpc64?]
This looks like a bug in file 5.26. I've just filed an issue on the tracker of file(1): http://bugs.gw.com/view.php?id=543 File 5.26 turned out to have some other nasty bugs like the following, so I'd recommend you avoid it. http://bugs.gw.com/view.php?id=540 Fortunately the port is still at 5.25, so you could replace /usr/bin/file with the one from the port: pkg install file ln -sf /usr/local/bin/file /usr/bin/ However, /usr/lib/libmagic.* cannot be safely replaced like this, so you can only wait for the next update or have to manually revert /usr/src/contrib/file/ and reinstall it from /usr/src/usr.bin/file/. On Mon, 02 May 2016 23:55:47 +0900, junc...@dec.sakura.ne.jp (Tomoaki AOKI) wrote: > > Hi. > > Today I encountered this problem on stable/10 and could determine the > problematic commit is r298920, "Update file to 5.26". > > This commit is MFC of r298192, and reverting it fixes the issue on > head, too. > > What I did (for stable/10) is... > > 1) Running at r298836: No problem. > 2) Update to r298920: Problem is reproduced! > 3) Downgrade to previous commit (r298889): No problem. > > 3) was done by `zfs rollback` to r298836 state, `svnlite up r298889', > and proceeded usual rebuilding procedure. > > Fortunately, there was only 3 commits between r298836 and r298920, > and I got right one in first attempt. > > But unfortunately, fixing portupgrade[-devel] or file/libmagic beyonds > my hand. :-< > > > On Tue, 26 Apr 2016 11:16:14 -0700 > Mark Millard wrote: > > > https://lists.freebsd.org/pipermail/freebsd-ports/2016-April/102983.html > > reported a "Broken pipe" problem with portupgrade on 11.0-CURRENT on amd64. > > > > FYI: I had the/a "Broken pipe" portupgrade problem on powerpc64 under > > 11.0-CURRENT -r298518 on 2016-Apr-23 updating from /usr/ports -r413230 to > > -r413919. If this might be the same I do not know. The relevant part of the > > script log is: > > > > > > Compressing man pages (compress-man) > > > ---> Backing up the old version > > > ---> Uninstalling the old version > > > [Reading data from pkg(8) ... - 68 packages found - done] > > > ---> Deinstalling 'perl5-5.22.1_7' > > > [Reading data from pkg(8) ... - 68 packages found - done] > > > ** Listing the failed packages (-:ignored / *:skipped / !:failed) > > > ! perl5-5.22.1_7(Broken pipe) > > > ---> Skipping 'ports-mgmt/portlint' (portlint-2.16.8) because a > > > requisite package 'perl5-5.22.1_7' (lang/perl5.22) failed (specify -k to > > > force) > > > > ruby was still lang/ruby21 at the time. > > > > I used portmaster instead and everything worked fine. > > > > === > > Mark Millard > > markmi at dsl-only.net > > > > ___ > > freebsd...@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-curre...@freebsd.org" > > > > > -- > Tomoaki AOKIjunc...@dec.sakura.ne.jp > ___ > freebsd...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-curre...@freebsd.org" > -- Akinori MUSHA / https://akinori.org/ pgpft8F0d4sgd.pgp Description: OpenPGP Digital Signature
Re: Weird portupgrade error on current amd64 [and powerpc64?]
This looks like a bug in file 5.26. I've just filed an issue on the tracker of file(1): http://bugs.gw.com/view.php?id=543 File 5.26 turned out to have some other nasty bugs like the following, so I'd recommend you avoid it. http://bugs.gw.com/view.php?id=540 Fortunately the port is still at 5.25, so you could replace /usr/bin/file with the one from the port: pkg install file ln -sf /usr/local/bin/file /usr/bin/ However, /usr/lib/libmagic.* cannot be safely replaced like this, so you can only wait for the next update or have to manually revert /usr/src/contrib/file/ and reinstall it from /usr/src/usr.bin/file/. On Mon, 02 May 2016 23:55:47 +0900, junc...@dec.sakura.ne.jp (Tomoaki AOKI) wrote: > > Hi. > > Today I encountered this problem on stable/10 and could determine the > problematic commit is r298920, "Update file to 5.26". > > This commit is MFC of r298192, and reverting it fixes the issue on > head, too. > > What I did (for stable/10) is... > > 1) Running at r298836: No problem. > 2) Update to r298920: Problem is reproduced! > 3) Downgrade to previous commit (r298889): No problem. > > 3) was done by `zfs rollback` to r298836 state, `svnlite up r298889', > and proceeded usual rebuilding procedure. > > Fortunately, there was only 3 commits between r298836 and r298920, > and I got right one in first attempt. > > But unfortunately, fixing portupgrade[-devel] or file/libmagic beyonds > my hand. :-< > > > On Tue, 26 Apr 2016 11:16:14 -0700 > Mark Millard wrote: > > > https://lists.freebsd.org/pipermail/freebsd-ports/2016-April/102983.html > > reported a "Broken pipe" problem with portupgrade on 11.0-CURRENT on amd64. > > > > FYI: I had the/a "Broken pipe" portupgrade problem on powerpc64 under > > 11.0-CURRENT -r298518 on 2016-Apr-23 updating from /usr/ports -r413230 to > > -r413919. If this might be the same I do not know. The relevant part of the > > script log is: > > > > > > Compressing man pages (compress-man) > > > ---> Backing up the old version > > > ---> Uninstalling the old version > > > [Reading data from pkg(8) ... - 68 packages found - done] > > > ---> Deinstalling 'perl5-5.22.1_7' > > > [Reading data from pkg(8) ... - 68 packages found - done] > > > ** Listing the failed packages (-:ignored / *:skipped / !:failed) > > > ! perl5-5.22.1_7(Broken pipe) > > > ---> Skipping 'ports-mgmt/portlint' (portlint-2.16.8) because a > > > requisite package 'perl5-5.22.1_7' (lang/perl5.22) failed (specify -k to > > > force) > > > > ruby was still lang/ruby21 at the time. > > > > I used portmaster instead and everything worked fine. > > > > === > > Mark Millard > > markmi at dsl-only.net > > > > ___ > > freebsd...@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-curre...@freebsd.org" > > > > > -- > Tomoaki AOKIjunc...@dec.sakura.ne.jp > ___ > freebsd...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-curre...@freebsd.org" > -- Akinori MUSHA / https://akinori.org/ pgp_w8TSPA_mL.pgp Description: OpenPGP Digital Signature
Re: HPT372 UDMA detection problem on current
At Sat, 1 Mar 2003 10:34:50 +0100 (CET), Soeren Schmidt wrote: > > Using the latest CURRENT on my box, the ata driver fails to enable > > UDMA for the ATA133 disks connected to an on-board HPT372 controller. > > > > Besides, UDMA is not enabled for the CD/DVD-ROM drive which is capable > > of UDMA4 either, but this may be a feature or a default, I guess. > > Fixed! Thanks! Now the two disks are running in UDMA6 and the DVD drive in UDMA4 properly. -- / /__ __Akinori.org / MUSHA.org / ) ) ) ) / FreeBSD.org / Ruby-lang.org Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp "It went right by me -- At the time it went over my head I was looking out the window.. I should have looked at your face instead" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HPT372 UDMA detection problem on current
Hi, Using the latest CURRENT on my box, the ata driver fails to enable UDMA for the ATA133 disks connected to an on-board HPT372 controller. Besides, UDMA is not enabled for the CD/DVD-ROM drive which is capable of UDMA4 either, but this may be a feature or a default, I guess. Any ideas? dmesg: atapci0: port 0xc000-0xc0ff,0xbc00-0xbc03, 0xb800-0xb807,0xb400-0xb403,0xb000-0xb007 irq 11 at device 11.0 on pci1 ata2: at 0xb000 on atapci0 ata3: at 0xb800 on atapci0 atapci1: port 0xe000-0xe00f at device 9.0 on pci0 ata0: at 0x1f0 irq 14 on atapci1 ata1: at 0x170 irq 15 on atapci1 acd0: DVD-ROM at ata1-slave PIO4 ar0: 156334MB [19929/255/63] status: READY subdisks: 0 READY ad4: 78167MB [158816/16/63] at ata2-master PIO4 1 READY ad6: 78167MB [158816/16/63] at ata3-master PIO4 pciconf: [EMAIL PROTECTED]:11:0: class=0x010400 card=0x00011103 chip=0x00041103 rev=0x05 hdr=0x00 vendor = 'HighPoint Technologies Inc.' device = 'HPT3xx UDMA66/100/133 EIDE Controller' class= mass storage subclass = RAID [EMAIL PROTECTED]:9:0: class=0x01018a card=0x0c1110de chip=0x01bc10de rev=0xc3 hdr=0x00 vendor = 'Nvidia Corporation' device = 'nForce ATA Controller' class= mass storage subclass = ATA atacontrol list: ATA channel 0: Master: no device present Slave: no device present ATA channel 1: Master: no device present Slave: acd0 ATA/ATAPI rev 5 ATA channel 2: Master: ad4 ATA/ATAPI rev 7 Slave: no device present ATA channel 3: Master: ad6 ATA/ATAPI rev 7 Slave: no device present atacontrol mode 1: Master = ??? Slave = PIO4 atacontrol mode 2: Master = PIO4 Slave = ??? atacontrol mode 3 Master = PIO4 Slave = ??? Regards, -- / /__ __Akinori.org / MUSHA.org / ) ) ) ) / FreeBSD.org / Ruby-lang.org Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp "It went right by me -- At the time it went over my head I was looking out the window.. I should have looked at your face instead" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
CURRENT reboots frequently
I have frequent reboots on my CURRENT box and each time it boots up and falls onto the debugger with the following stack trace after local package initialization: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xfc09423 fault code = supervisor read, page not present instruction pointer = 0x8:0xc03767e0 stack pointer = 0x10:0xd8de4560 frame pointer = 0x10:0xd8de4580 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 676 (procmail) kernel: type 12 trap, code=0 Stopped at namei+0x12c:cmpxchgl%edx,0x50(%ecx) db> tr namei(d8de49c8,0,0,c45b72a0,d8de7ccc) at namei+0x12c vn_open_cred(d8de49c8,d8de4990,0,c150ae80,d8de4970) at vn_open_cred+0x26a nfs_dolock(d8de4ba0,c45b72a0,d8de4690,c45b72a0,c45b72a0) at nfs_dolock+0x2c5 nfs_advlock(d8de4ba0,c45b72a0,c041ed80,c466fe6c,c46788fc) at nfs_advlock+0x58 closef(c462d1a4,c45b72a0,d8de4c18,c02563a0,c083ad80) at closef+0x9c fdfree(c45b72a0,c044a140,0,2,0) at fdfree+0x196 exit1(c45b72a0,0,c46788fc,c45b72a0,805a030) at exit1+0x469 sys_exit(c45b72a0,d8de4d10,4,c45b72a0,1) at sys_exit+0x5e syscall(2f,2f,2f,805a030,2) at syscall+0x2aa Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x280d4d37, esp = 0xbfbffbac, ebp = 0xbfbffbc8 --- Any ideas? -- / /__ __Akinori.org / MUSHA.org / ) ) ) ) / FreeBSD.org / Ruby-lang.org Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp "It went right by me -- At the time it went over my head I was looking out the window.. I should have looked at your face instead" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: moused(8): char signed-ness problem with gcc 3.1
I've submitted a bug report to GCC GNATS: http://gcc.gnu.org/cgi-bin/gnatsweb.pl?database=gcc&pr=6677&cmd=view+audit-trail Let's see how they handle this. -- / /__ __Akinori.org / MUSHA.org / ) ) ) ) / FreeBSD.org / Ruby-lang.org Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp "Somewhere out of a memory.. of lighted streets on quiet nights.." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: moused(8): char signed-ness problem with gcc 3.1
At Thu, 16 May 2002 21:58:56 +1000 (EST),
Bruce Evans wrote:
> > Somehow, specifying -fsigned-char, which I thought was the default,
> > fixed the problem. So, the cause may be in our configuration of gcc?
>
> -fsigned-char doesn't fix it for me. Neither does repacling "char" by
> "signed char".
Oops, I was testing on a different box. Sorry.
> moused is broken too. It assumes that plain chars are signed.
How about this?
Index: moused.c
===
RCS file: /home/ncvs/src/usr.sbin/moused/moused.c,v
retrieving revision 1.55
diff -u -r1.55 moused.c
--- moused.c28 Apr 2002 11:59:30 - 1.55
+++ moused.c16 May 2002 14:15:42 -
@@ -1718,8 +1718,8 @@
return 0;
}
- act->dx = (char)(((pBuf[0] & 0x03) << 6) | (pBuf[1] & 0x3F));
- act->dy = (char)(((pBuf[0] & 0x0C) << 4) | (pBuf[2] & 0x3F));
+ act->dx = (signed char)(((pBuf[0] & 0x03) << 6) | (pBuf[1] & 0x3F));
+ act->dy = (signed char)(((pBuf[0] & 0x0C) << 4) | (pBuf[2] & 0x3F));
break;
case MOUSE_PROTO_GLIDEPOINT: /* GlidePoint */
@@ -1728,8 +1728,8 @@
MouseMan+ */
act->button = (act->obutton & (MOUSE_BUTTON2DOWN | MOUSE_BUTTON4DOWN))
| butmapmss[(pBuf[0] & MOUSE_MSS_BUTTONS) >> 4];
- act->dx = (char)(((pBuf[0] & 0x03) << 6) | (pBuf[1] & 0x3F));
- act->dy = (char)(((pBuf[0] & 0x0C) << 4) | (pBuf[2] & 0x3F));
+ act->dx = (signed char)(((pBuf[0] & 0x03) << 6) | (pBuf[1] & 0x3F));
+ act->dy = (signed char)(((pBuf[0] & 0x0C) << 4) | (pBuf[2] & 0x3F));
break;
case MOUSE_PROTO_MSC: /* MouseSystems Corp */
@@ -1737,15 +1737,15 @@
case MOUSE_PROTO_MARIQUA: /* Mariqua */
#endif
act->button = butmapmsc[(~pBuf[0]) & MOUSE_MSC_BUTTONS];
- act->dx =(char)(pBuf[1]) + (char)(pBuf[3]);
- act->dy = - ((char)(pBuf[2]) + (char)(pBuf[4]));
+ act->dx =(signed char)(pBuf[1]) + (signed char)(pBuf[3]);
+ act->dy = - ((signed char)(pBuf[2]) + (signed char)(pBuf[4]));
break;
case MOUSE_PROTO_JOGDIAL: /* JogDial */
if (rBuf == 0x6c)
- act->dz=-1;
+ act->dz = -1;
if (rBuf == 0x72)
- act->dz=1;
+ act->dz = 1;
if (rBuf == 0x64)
act->button = MOUSE_BUTTON1DOWN;
if (rBuf == 0x75)
@@ -1792,8 +1792,8 @@
case MOUSE_PROTO_BUS: /* Bus */
case MOUSE_PROTO_INPORT: /* InPort */
act->button = butmapmsc[(~pBuf[0]) & MOUSE_MSC_BUTTONS];
- act->dx = (char)pBuf[1];
- act->dy = - (char)pBuf[2];
+ act->dx = (signed char)pBuf[1];
+ act->dy = - (signed char)pBuf[2];
break;
case MOUSE_PROTO_PS2: /* PS/2 */
@@ -1822,7 +1822,7 @@
case MOUSE_MODEL_INTELLI:
case MOUSE_MODEL_NET:
/* wheel data is in the fourth byte */
- act->dz = (char)pBuf[3];
+ act->dz = (signed char)pBuf[3];
if ((act->dz >= 7) || (act->dz <= -7))
act->dz = 0;
/* some compatible mice may have additional buttons */
@@ -1969,10 +1969,10 @@
case MOUSE_PROTO_SYSMOUSE: /* sysmouse */
act->button = butmapmsc[(~pBuf[0]) & MOUSE_SYS_STDBUTTONS];
- act->dx =(char)(pBuf[1]) + (char)(pBuf[3]);
- act->dy = - ((char)(pBuf[2]) + (char)(pBuf[4]));
+ act->dx =(signed char)(pBuf[1]) + (signed char)(pBuf[3]);
+ act->dy = - ((signed char)(pBuf[2]) + (signed char)(pBuf[4]));
if (rodent.level == 1) {
- act->dz = ((char)(pBuf[5] << 1) + (char)(pBuf[6] << 1))/2;
+ act->dz = ((signed char)(pBuf[5] << 1) + (signed char)(pBuf[6] << 1)) >> 1;
act->button |= ((~pBuf[7] & MOUSE_SYS_EXTBUTTONS) << 3);
}
break;
--
/
/__ __Akinori.org / MUSHA.org
/ ) ) ) ) / FreeBSD.org / Ruby-lang.org
Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp
"Somewhere out of a memory.. of lighted streets on quiet nights.."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: moused(8): char signed-ness problem with gcc 3.1
[CC: obrien, who has been working on bringing in gcc 3.1]
At Wed, 15 May 2002 20:46:06 -0700,
Bill Fenner wrote:
> > So - yes - it seems gcc 3.1 does have a problem...
>
> Indeed - easily determined by breaking down the expression.
>
> So, who's gonna report it to gcc-bugs? knu?...
>
> int
> main()
> {
>unsigned char i = 127;
>char j;
>
>printf("%d\n", ((char)(i << 1)));
>j = ((char)(i << 1)) / 2;
>printf("%d\n", j);
>j = ((char)(i << 1));
>printf("%d\n", j / 2);
>return 0;
> }
Somehow, specifying -fsigned-char, which I thought was the default,
fixed the problem. So, the cause may be in our configuration of gcc?
I'll send-pr if it isn't.
--
/
/__ __Akinori.org / MUSHA.org
/ ) ) ) ) / FreeBSD.org / Ruby-lang.org
Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp
"Somewhere out of a memory.. of lighted streets on quiet nights.."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
moused(8): char signed-ness problem with gcc 3.1
I observed gcc 2.95.4 and gcc 3.1 interpret (or maybe optimize) the
following code differently (CFLAGS=-O):
int main(void)
{
unsigned char i = 127;
printf("%d\n", ((char)(i << 1)) / 2);
return 0;
}
gcc 2.95.4 says it's -1, whereas gcc 3.1 says it's 127. On FreeBSD
char should be signed, so I suspect it's a (optimization) bug of gcc
3.1 which should be fixed. Or we'll have to do a mass audit of the
whole src tree to check and fix the similar expressions.
In any case, this behavior makes moused(8) return a stupid value of
127 when you roll the mouse wheel up under ps/2-sysmouse-intellimouse
protocol. Attached is a patch that makes the whole expression look
more logical and works around the above behavior at the same time.
--
/
/__ __Akinori.org / MUSHA.org
/ ) ) ) ) / FreeBSD.org / Ruby-lang.org
Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp
"Somewhere out of a memory.. of lighted streets on quiet nights.."
Index: moused.c
===
RCS file: /home/ncvs/src/usr.sbin/moused/moused.c,v
retrieving revision 1.55
diff -u -r1.55 moused.c
--- moused.c28 Apr 2002 11:59:30 - 1.55
+++ moused.c15 May 2002 17:16:40 -
@@ -1972,7 +1972,7 @@
act->dx =(char)(pBuf[1]) + (char)(pBuf[3]);
act->dy = - ((char)(pBuf[2]) + (char)(pBuf[4]));
if (rodent.level == 1) {
- act->dz = ((char)(pBuf[5] << 1) + (char)(pBuf[6] << 1))/2;
+ act->dz = ((char)(pBuf[5] << 1) + (char)(pBuf[6] << 1)) >> 1;
act->button |= ((~pBuf[7] & MOUSE_SYS_EXTBUTTONS) << 3);
}
break;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/lib/libpam Makefile.inc
Oops, At Thu, 12 Jul 2001 15:26:58 +0900, I wrote: > Actually this doesn't help libpam.so.1, because the new pam modules > (pam_*.so) do not work with it. Which means you need to recompile > the programs linked with it, such as sudo, xdm, and the X server. Xwrapper -- / /__ __Akinori.org / MUSHA.org / ) ) ) ) / FreeBSD.org / Ruby-lang.org Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp "Freeze this moment a little bit longer, make each impression a little bit stronger.. Experience slips away -- Time stand still" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/lib/libpam Makefile.inc
At Mon, 9 Jul 2001 11:16:33 -0700 (PDT), Mark Murray wrote: > markm 2001/07/09 11:16:33 PDT > > Modified files: > lib/libpam Makefile.inc > Log: > Bump the major number. The libraries API has changed incompatibly. Actually this doesn't help libpam.so.1, because the new pam modules (pam_*.so) do not work with it. Which means you need to recompile the programs linked with it, such as sudo, xdm, and the X server. As a workaround, you can overwrite libpam.so.1 with libpam.so.2 and everything should work fine. (Has the compatibility really lost?) -- / /__ __Akinori.org / MUSHA.org / ) ) ) ) / FreeBSD.org / Ruby-lang.org Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp "Freeze this moment a little bit longer, make each impression a little bit stronger.. Experience slips away -- Time stand still" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
OpenSSH 2.9 problems
I have some problems with the newly updated OpenSSH 2.9. 1. Sshd fails to authenticate via PAM. May 5 19:18:07 archon sshd[803]: fatal: PAM setcred failed[6]: Permission denied 2. << ln -s hostname `which ssh`; ./hostname >> doesn't work anymore. It used to slogin to the host in the previous versions but now it just shows the help screen. 3. Somehow the default location of the ssh host key files has been changed from /etc/ssh to /etc. Was it intentional? Any ideas? -- / /__ __Akinori.org / MUSHA.org / ) ) ) ) / FreeBSD.org / Ruby-lang.org Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp "Freeze this moment a little bit longer, make each impression a little bit stronger.. Experience slips away -- Time stand still" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: find(1) -regex/-iregex
At Wed, 21 Feb 2001 15:06:22 +0900, Daniel C. Sobral wrote: > > http://people.FreeBSD.org/~knu/misc/find_regex.diff > > You might have done it, but the version above is not it. :-) Oh, would you please reload it? When you see a function named do_c_regex(), that's it. :) -- / /__ __Akinori.org / MUSHA.org / ) ) ) ) / FreeBSD.org / Ruby-lang.org Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp "We're only at home when we're on the run, on the wing, on the fly" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: find(1) -regex/-iregex
At Wed, 21 Feb 2001 18:53:26 +1300, Craig Carey wrote: > Can an -iname option be provided. Then the FreeBSD find would be > more like GNU find, and lines like this could be written: Yes, it's already implemented as I wrote in the previous mail. > I am doubtful that the -regexp needs to be inferior to the the > -egrep option. What software would break: it was said that there is > no regexp?. There are opinions around saying that egrep is better > than grep. We are not aiming to be that GNU'ish. Being compatible with NetBSD is a good thing in a sense. > What is the -E option: perhaps this?: -eregex > > Suppose it is case sensitive. Then it could be > -eiregex or -ieregex or -eregexi I don't like it somehow.. I chose -E because it is consistent with (our) grep(1) and sed(1). > What about improving 'ls' too?: can there be an option so that it > refuses to list any information about directories (useful in the > above example). Also, is there any plan to stop the wastage of > space in the central columns of "ls"'s output, where it lists > uninteresting information. Maybe a '-p' option, like GNU 'ls' > has. Interesting, but it would be done at some other time. I'd like to focus on regex this time. -- / /__ __ Akinori.org / MUSHA.org / ) ) ) ) / FreeBSD.org / Ruby-lang.org Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp "We're only at home when we're on the run, on the wing, on the fly" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: find(1) -regex/-iregex
At Wed, 21 Feb 2001 14:12:51 +0900,
I wrote:
> At Wed, 21 Feb 2001 12:35:09 +0900,
> Daniel C. Sobral wrote:
> > I'm not familiar with find sources, but it seems to me you execute
> > regcomp() for each file name to be compared? If so... change that! :-)
> > Regcomp() does expensive setup so that regexec() can be run
> > inexpensively many times over.
>
> Indeed. I'll do it soon, thanks.
Updated.
http://people.FreeBSD.org/~knu/misc/find_regex.diff
> > You forgot -E (use extended regexp syntax), and the example you show
> > above is extended regexp syntax, not basic regexp syntax.
Well, it was added after I had posted the original article. The
latest one's find.1 mentions it.
.It Fl E
Interpret regular expressions followed by
.Ic -regex
and
.Ic -iregex
options as extended (modern) regular expressions rather than basic
regular expressions (BRE's). The
.Xr re_format 7
manual page fully describes both formats.
As for the syntax my examples conform to, I think they are valid both
for basic and extended.
True if the whole path of the file matches
.Ar pattern
using regular expression. To match a file named ``./foo/xyzzy'', you
can use the regular expression ``.*/[xyz]*'' or ``.*/foo/.*'', but not
``xyzzy'' or ``/foo/''.
Thanks for your suggestions.
--
/
/__ __Akinori.org / MUSHA.org
/ ) ) ) ) / FreeBSD.org / Ruby-lang.org
Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp
"We're only at home when we're on the run, on the wing, on the fly"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: find(1) -regex/-iregex
At Wed, 21 Feb 2001 12:35:09 +0900, Daniel C. Sobral wrote: > I'm not familiar with find sources, but it seems to me you execute > regcomp() for each file name to be compared? If so... change that! :-) > Regcomp() does expensive setup so that regexec() can be run > inexpensively many times over. Indeed. I'll do it soon, thanks. > You forgot -E (use extended regexp syntax), and the example you show > above is extended regexp syntax, not basic regexp syntax. Noted. -- / /__ __Akinori.org / MUSHA.org / ) ) ) ) / FreeBSD.org / Ruby-lang.org Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp "We're only at home when we're on the run, on the wing, on the fly" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
find(1) -regex/-iregex
Hi,
I have implemented -regex and -iregex options for find(1):
http://people.FreeBSD.org/~knu/misc/find_regex.diff
They are meant to be compatible with those of GNU's and NetBSD's:
-regex :
True if the whole path of the file matches using
basic regular expression. To match a file named
``./foo/xyzzy'', you can use the regular expression
``.*/[xyz]*'' or ``.*/foo/.*'', but not ``xyzzy'' or
``/foo/''.
-iregex :
Like -regex, but the match is case insensitive.
I'd like to commit it after reviews if there is no convincing
objection against it. Any suggestion is welcome.
Thanks,
--
/
/__ __Akinori.org / MUSHA.org
/ ) ) ) ) / FreeBSD.org / Ruby-lang.org
Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp
"We're only at home when we're on the run, on the wing, on the fly"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: find(1) -regex/-iregex
At Wed, 21 Feb 2001 08:42:19 +1300,
Craig Carey wrote:
> What about the -iname option?.
>
> I recently installed GNU 'find' just to get that -iname problem fixed.
>
> Can you do -iname too?.
Thanks for the info. It's added now.
I'm ashamed to say that I couldn't resist implementing -E option to
allow extended regexps. ;) The traditional and POSIX compliant basic
regexp is so hard to handle that you can't even say ".+\.S?o" but
"..*\.S{0,1}o".. (see re_format(7) for details)
Also, I revised the manpage to describe them in detail. Please check
it out:
http://people.FreeBSD.org/~knu/misc/find_regex.diff
> >I'd like to commit it after reviews if there is no convincing
> >objection against it. Any suggestion is welcome.
> >
>
> I would object if it is a new variant of regexp. I'd say it ought
> be between egrep and perl, in its functionality.
I don't think I grasp your meaning.. GNU find(1)'s -regexp uses the
"basic regexp" that is _not_ the "extended regexp" which egrep(1) uses
nor the one perl(1) uses.
Anyway, here lists the facts:
- I implemented -regexp/-iregexp using FreeBSD's standard regex
library which is supposed to be compliant with POSIX.2
- The match is executed with REG_BASIC, which behavior is compatible
with GNU find(1) and NetBSD find(1)
- I, however, added -E so we can use extended regexp ;)
- Perl's regexp is known to be a unique variant that is different
from the "basic regexp" nor the "extended regexp" ;P
> It sounds like a regexp would be nice.
Me too. :)
--
/
/__ __Akinori.org / MUSHA.org
/ ) ) ) ) / FreeBSD.org / Ruby-lang.org
Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp
"We're only at home when we're on the run, on the wing, on the fly"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
libgtop on CURRENT
It is necessary to update libgtop for CURRENT as attached. I haven't
yet got an idea how to fix it to shut up the following error messages,
though.
LibGTop-Server: kvm_getargv (12): Undefined error: 0
LibGTop-Server: kvm_getargv (11): Undefined error: 0
LibGTop-Server: kvm_getargv (10): Undefined error: 0
By the way, you'd better split patches into per-file patches..
--
/
/__ __Akinori.org / MUSHA.org
/ ) ) ) ) / FreeBSD.org / Ruby-lang.org
Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp
"We're only at home when we're on the run, on the wing, on the fly"
Index: Makefile
===
RCS file: /home/ncvs/ports/devel/libgtop/Makefile,v
retrieving revision 1.40
diff -u -r1.40 Makefile
--- Makefile2000/12/28 02:35:31 1.40
+++ Makefile2001/02/15 12:35:38
@@ -7,7 +7,7 @@
PORTNAME= libgtop
PORTVERSION= 1.0.10
-PORTREVISION= 3
+PORTREVISION= 4
CATEGORIES=devel gnome
MASTER_SITES= ${MASTER_SITE_GNOME}
MASTER_SITE_SUBDIR=stable/sources/libgtop
Index: files/patch-aj
===
RCS file: /home/ncvs/ports/devel/libgtop/files/patch-aj,v
retrieving revision 1.2
diff -u -r1.2 patch-aj
--- files/patch-aj 2000/12/28 02:35:34 1.2
+++ files/patch-aj 2001/02/14 16:24:33
@@ -71,9 +71,9 @@
- switch (pinfo [0].kp_proc.p_stat) {
+ switch (pinfo [0].XXX_P_STAT) {
case SIDL:
sysdeps/freebsd/procuid.c.orig Thu Sep 16 16:08:07 1999
-+++ sysdeps/freebsd/procuid.c Fri Dec 22 18:37:41 2000
-@@ -86,13 +86,38 @@
+--- sysdeps/freebsd/procuid.c.orig Fri Sep 17 06:08:07 1999
sysdeps/freebsd/procuid.c Thu Feb 15 01:16:50 2001
+@@ -86,13 +86,42 @@
- buf->uid = pinfo [0].kp_eproc.e_pcred.p_ruid;
- buf->euid = pinfo [0].kp_eproc.e_pcred.p_svuid;
@@ -95,7 +95,11 @@
+#define XXX_E_PGID ki_pgid
+#define XXX_E_TPGID ki_tpgid
+#define XXX_P_NICE ki_nice
++#if __FreeBSD_version >= 500013
++#define XXX_P_PRIORITY ki_pri.pri_user
++#else
+#define XXX_P_PRIORITY ki_priority
++#endif
+#else
+
+#define XXX_P_RUID kp_eproc.e_pcred.p_ruid
@@ -122,8 +126,8 @@
+ buf->nice = pinfo [0].XXX_P_NICE;
+ buf->priority = pinfo [0].XXX_P_PRIORITY;
sysdeps/freebsd/proctime.c.origThu Sep 16 16:08:07 1999
-+++ sysdeps/freebsd/proctime.c Fri Dec 22 22:45:57 2000
+--- sysdeps/freebsd/proctime.c.origFri Sep 17 06:08:07 1999
sysdeps/freebsd/proctime.c Thu Feb 15 01:15:11 2001
@@ -68,5 +68,2 @@
u_quad_t u, st, ut, it, tot;
-#if (__FreeBSD_version < 33)
@@ -150,10 +154,14 @@
- buf->rtime = tv2sec (pinfo [0].kp_proc.p_rtime);
+ buf->rtime = pinfo [0].kp_proc.p_runtime;
#endif
-@@ -194,2 +186,13 @@
+@@ -194,2 +186,17 @@
#else
+#if __FreeBSD_version >= 500013
++#if __FreeBSD_version >= 500016
++ if ((pinfo [0].ki_flag & PS_INMEM)) {
++#else
+ if ((pinfo [0].ki_flag & P_INMEM)) {
++#endif
+ buf->utime = pinfo [0].ki_runtime;
+ buf->stime = 0; /* XXX */
+ buf->cutime = tv2sec (pinfo [0].ki_childtime);
@@ -164,7 +172,7 @@
+
+#else
glibtop_suid_enter (server);
-@@ -224,2 +227,3 @@
+@@ -224,2 +231,3 @@
}
+#endif
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Backward binary compatibility with libc/libm
At Thu, 15 Feb 2001 20:47:57 +0900,
I wrote:
>
> Seems some 4.x/3.x binary that is linked with libm.so does not work on
> 5-CURRENT because libm.so is not properly associated with (the latest)
> libc.so.
>
> So, when a program lets libm refers to __stdout/__stderr from within,
> it fails as follows. :(
>
> /usr/libexec/ld-elf.so.1: /usr/lib/libm.so.2: Undefined symbol "__stderr"
>
> Unfortunately, it applies to some important bits like JDK 1.1.8...
>
> As a workaround, adding LDADD=-lc to src/lib/msun/Makefile seems to
> do the trick and get it working.
Oops, obviously I missed the 'Major bumping of libFOO' thread. Take
msun into account as well, thanks.
--
/
/__ __Akinori.org / MUSHA.org
/ ) ) ) ) / FreeBSD.org / Ruby-lang.org
Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp
"We're only at home when we're on the run, on the wing, on the fly"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Backward binary compatibility with libc/libm
Seems some 4.x/3.x binary that is linked with libm.so does not work on 5-CURRENT because libm.so is not properly associated with (the latest) libc.so. So, when a program lets libm refers to __stdout/__stderr from within, it fails as follows. :( /usr/libexec/ld-elf.so.1: /usr/lib/libm.so.2: Undefined symbol "__stderr" Unfortunately, it applies to some important bits like JDK 1.1.8... As a workaround, adding LDADD=-lc to src/lib/msun/Makefile seems to do the trick and get it working. Ideas, anyone? -- / /__ __Akinori.org / MUSHA.org / ) ) ) ) / FreeBSD.org / Ruby-lang.org Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp "We're only at home when we're on the run, on the wing, on the fly" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: ports/palm/pilot-link Makefile
included... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking for connect... yes
checking for gethostbyname... yes
checking for main in -linet... no
checking whether cc needs -traditional... no
checking return type of signal handlers... void
checking for atexit... yes
checking for strchr... yes
checking for strdup... yes
checking for memcpy... yes
checking for memmove... yes
checking for strtoul... yes
checking for cfmakeraw... yes
checking for cfsetspeed... yes
checking for cfsetispeed... yes
checking for cfsetospeed... yes
checking for sigaction... yes
checking for dup2... yes
checking for inet_aton... yes
checking for gethostname... yes
checking for uname... yes
checking for putenv... yes
checking for cispeed and cospeed members of struct termios... yes
checking for sa_len... yes
checking for Java Development Kit... not found
checking for Tcl... version 8.2 from /usr/local/lib/tcl8.2/tclConfig.sh
checking for Itcl... not found
checking for Tk... version 8.2 from /usr/local/lib/tk8.2/tkConfig.sh
checking for python... /usr/local/bin/python
checking for Python... Python version 1.5.2 in /usr/local/lib/python1.5
checking for maximum warnings compiler flag...
updating cache ./config.cache
creating ./config.status
creating libsock/Makefile
creating libcc/Makefile
creating Makefile
creating dubious/Makefile
creating Python/Makefile
creating Tcl/Makefile
creating Perl5/Makefile.PL
creating Java/Makefile
creating tests/Makefile
creating include/pi-config.h
creating include/pi-sockaddr.h
===> Building for pilot-link-0.9.3
(..snip..)
c++ -I./include -I./include -O -march=pentiumpro -pipe -DREADLINE_2_1
-DLIBDIR=\"/usr/local/pilot/lib\" -DTCL -DTK -I/usr/local/include/tcl8.2
-I/usr/local/include/tk8.2 -I/usr/X11R6/include -c iambicexample.cc
./libtool --mode=link c++ -I./include -I./include -O -march=pentiumpro -pipe
-DREADLINE_2_1 -DLIBDIR=\"/usr/local/pilot/lib\" -DTCL -DTK
-I/usr/local/include/tcl8.2 -I/usr/local/include/tk8.2 -I/usr/X11R6/include
iambicexample.o libsock/libpisock.la getopt.o getopt1.o libcc/libpicc.a -o
iambicexample -lm
c++ -I./include -I./include -O -march=pentiumpro -pipe -DREADLINE_2_1
-DLIBDIR=\"/usr/local/pilot/lib\" -DTCL -DTK -I/usr/local/include/tcl8.2
-I/usr/local/include/tk8.2 -I/usr/X11R6/include iambicexample.o
libsock/.libs/libpisock.so getopt.o getopt1.o libcc/libpicc.a -o .libs/iambicexample
-lm -Wl,--rpath -Wl,/usr/local/pilot/lib
creating iambicexample
/usr/bin/perl5.00503 pilot-undelete.PL > pilot-undelete
chmod +x pilot-undelete
/usr/bin/perl5.00503 ietf2datebook.PL > ietf2datebook
chmod +x ietf2datebook
/usr/bin/perl5.00503 sync-plan.PL > sync-plan
chmod +x sync-plan
(done)
However, if I put either:
CXXFLAGS+= -fPIC
or:
CFLAGS!=${ECHO} "${CFLAGS}" | ${SED} -e 's/-O[0-9a-z]*//g'
(as Kuriyama-san has just added today) it builds fine on 5-CURRENT.
David, would you investigate this?
--
/
/__ __Akinori.org / MUSHA.org
/ ) ) ) ) / FreeBSD.org / Ruby-lang.org
Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp
"We're only at home when we're on the run, on the wing, on the fly"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: setlocale() fails
At Tue, 13 Feb 2001 20:01:28 +0600 (NOVT), [EMAIL PROTECTED] wrote: > Yes this patch permits 'setlocale(LC_ALL, "")' to return > success, but it is not solve the problem totally. It seems to me > that all comparisons of the return value from '__part_load_locale' > in the 'lmessages.c', 'lnumeric.c' and 'lmonetary.c' are reversed now > and your patch correct only one of them (but this one prevents > setlocale to work for all locales but "C" and "POSIX"). All reversed? It seems to me at least the comparison in the line 65 of lmessages.c is correct, and the ones in lnumeric.c and lmonetary.c look fine as well. Let's have your say, Alexey! ;) -- / /__ __ Akinori.org / MUSHA.org / ) ) ) ) / FreeBSD.org / Ruby-lang.org Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp "We're only at home when we're on the run, on the wing, on the fly" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: setlocale() fails
Hi again,
At Tue, 13 Feb 2001 07:21:15 +0900,
I wrote:
> I found that setlocale() always fails on -current.
>
> #include
> #include
>
> int main()
> {
> if (setlocale(LC_ALL, ""))
> puts("ok");
> else
> puts("failed");
> return 0;
> }
>
> This program shows "failed" on -current regardless of the value of
> LANG unless it's other than "C", when it shows "ok" on -stable...
>
> Any ideas?
I found the culprit. Here is a patch which fixes the problem.
Index: lmessages.c
===
RCS file: /home/ncvs/src/lib/libc/locale/lmessages.c,v
retrieving revision 1.4
diff -u -r1.4 lmessages.c
--- lmessages.c 2001/02/12 08:56:39 1.4
+++ lmessages.c 2001/02/13 08:19:04
@@ -55,7 +55,7 @@
ret = __part_load_locale(name, &_messages_using_locale,
messages_locale_buf, "LC_MESSAGES", LCMESSAGES_SIZE_FULL,
(const char **)&_messages_locale);
- if (ret == 0) {
+ if (ret != 0) {
/* Assume that we have incomplete locale file (without
* "yesstr" and "nostr" declared. Try it also.
*/
--
/
/__ __Akinori.org / MUSHA.org
/ ) ) ) ) / FreeBSD.org / Ruby-lang.org
Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp
"We're only at home when we're on the run, on the wing, on the fly"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
src/etc/netstart
Seems you broke an error message of src/etc/netstart when committing a series of quoting style fixes. Please apply the attached patch. Thanks, -- / /__ __Akinori.org / MUSHA.org / ) ) ) ) / FreeBSD.org / Ruby-lang.org Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp "We're only at home when we're on the run, on the wing, on the fly" Index: netstart === RCS file: /home/ncvs/src/etc/netstart,v retrieving revision 1.58 diff -u -r1.58 netstart --- netstart2000/12/17 08:15:57 1.58 +++ netstart2000/12/26 06:00:06 @@ -50,7 +50,7 @@ if [ -f /etc/rc.network ]; then . /etc/rc.network else - echo 'Sorry, I can't find /etc/rc.network - aborting' + echo "Sorry, I can't find /etc/rc.network - aborting" exit 1 fi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskslice.c src/sys/sys diskslice.h src/sys/cam/scsi scsi_cd.c
At Thu, 2 Nov 2000 21:10:34 -0700, Kenneth D. Merry <[EMAIL PROTECTED]> wrote: > > I get the following messages when I hit "cdcontrol -f /dev/cd0 play" > > against a music CD: > > > > Oct 31 16:06:40 archon /boot/kernel/kernel: (cd0:ahc0:0:2:0): READ(10). CDB: 28 0 >0 0 0 1 0 0 1 0 > > Oct 31 16:06:40 archon /boot/kernel/kernel: (cd0:ahc0:0:2:0): ILLEGAL REQUEST >asc:64,0 > > Oct 31 16:06:40 archon /boot/kernel/kernel: (cd0:ahc0:0:2:0): Illegal mode for >this track > > Oct 31 16:06:40 archon /boot/kernel/kernel: (cd0:ahc0:0:2:0): cddone: got error >0x16 back > > > > Though the music goes just fine. > > I've got a patch, see if this fixes the problem. That fixed the problem, thanks. -- / /__ __ / ) ) ) ) /and.or.jp / ruby-lang.org Akinori -Aki- MUSHA aka / (_ / ( (__( @ idaemons.org / FreeBSD.org "We're only at home when we're on the run, on the wing, on the fly" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/compat/linux linux_stats.c
At Thu, 02 Nov 2000 22:15:45 +0100, Poul-Henning Kamp wrote: > >I confirmed linux ls didn't cause panic, so the culprit should belong > >somewhere else. Hopefully phk will catch it for us. :) > > I hope I just did. Please report back if this has or hasn't solve > the problem. Just confirmed that your fix solved the problem! Thanks! knu@archon[3]% uname -a FreeBSD archon.local.idaemons.org 5.0-CURRENT FreeBSD 5.0-CURRENT #25: Fri Nov 3 06:28:04 JST 2000 [EMAIL PROTECTED]:/usr/local/src/sys/compile/ARCHON i386 knu@archon[3]% ls -l /compat/linux/dev total 0 brw-r--r-- 1 root wheel - 0, 0x00010002 Nov 2 20:28 hda brw-r--r-- 1 root wheel - 0, 0x0001000a Nov 2 20:28 hdb crw-rw-rw- 1 root wheel - 2, 2 Nov 2 20:28 null crw-r--r-- 1 root wheel - 202, 0 Nov 2 20:17 rtc lrwxr-xr-x 1 root wheel - 22 Nov 2 20:28 tty0@ -> /compat/linux/dev/tty1 lrwxr-xr-x 1 root wheel - 10 Nov 2 20:28 tty1@ -> /dev/ttyv0 lrwxr-xr-x 1 root wheel - 10 Nov 2 20:28 tty10@ -> /dev/ttyv9 lrwxr-xr-x 1 root wheel - 10 Nov 2 20:28 tty11@ -> /dev/ttyva lrwxr-xr-x 1 root wheel - 10 Nov 2 20:28 tty12@ -> /dev/ttyvb lrwxr-xr-x 1 root wheel - 10 Nov 2 20:28 tty2@ -> /dev/ttyv1 lrwxr-xr-x 1 root wheel - 10 Nov 2 20:28 tty3@ -> /dev/ttyv2 lrwxr-xr-x 1 root wheel - 10 Nov 2 20:28 tty4@ -> /dev/ttyv3 lrwxr-xr-x 1 root wheel - 10 Nov 2 20:28 tty5@ -> /dev/ttyv4 lrwxr-xr-x 1 root wheel - 10 Nov 2 20:28 tty6@ -> /dev/ttyv5 lrwxr-xr-x 1 root wheel - 10 Nov 2 20:28 tty7@ -> /dev/ttyv6 lrwxr-xr-x 1 root wheel - 10 Nov 2 20:28 tty8@ -> /dev/ttyv7 lrwxr-xr-x 1 root wheel - 10 Nov 2 20:28 tty9@ -> /dev/ttyv8 crw-r--r-- 1 root wheel - 200, 0 Nov 2 20:28 vmmon crw-r--r-- 1 root wheel - 149, 0x00010001 Nov 2 20:35 vmnet1 knu@archon[3]% -- / /__ __ / ) ) ) ) /and.or.jp / ruby-lang.org Akinori -Aki- MUSHA aka / (_ / ( (__( @ idaemons.org / FreeBSD.org "We're only at home when we're on the run, on the wing, on the fly" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: i386/20379
Sorry, this should not have sent to current. I've forwarded it to stable, so please follow to that if you have comments on this PR, thanks. -- / /__ __ / ) ) ) ) /and.or.jp / ruby-lang.org Akinori -Aki- MUSHA aka / (_ / ( (__( @ idaemons.org / FreeBSD.org "We're only at home when we're on the run, on the wing, on the fly" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
i386/20379
Would someone take a look at i386/20379, which adds support for Intel 450GX chipset? The fix is simple enough to get into 4.2-RELEASE. Intel 450GX used to be a highend chipset for servers in the PentiumPro era, and such a chipset should be supported by 4.2-RELEASE! :) http://www.freebsd.org/cgi/query-pr.cgi?pr=20379 -- / /__ __ / ) ) ) ) /and.or.jp / ruby-lang.org Akinori -Aki- MUSHA aka / (_ / ( (__( @ idaemons.org / FreeBSD.org "We're only at home when we're on the run, on the wing, on the fly" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/compat/linux linux_stats.c
At Thu, 02 Nov 2000 15:26:29 -0500, Marcel Moolenaar wrote: > > Akinori MUSHA wrote: > > > > At Thu, 2 Nov 2000 14:11:44 -0500 (EST), > > Andrew Gallatin wrote: > > > To clarify -- this is the native /bin/ls and NOT /compat/linux/bin/ls? > > > > Yes. > > How is linux_ustat involved if the panic is caused by a native binary? Not at all. Sorry, that was my mistaken assumption, after all. :( I confirmed linux ls didn't cause panic, so the culprit should belong somewhere else. Hopefully phk will catch it for us. :) -- / /__ __ / ) ) ) ) /and.or.jp / ruby-lang.org Akinori -Aki- MUSHA aka / (_ / ( (__( @ idaemons.org / FreeBSD.org "We're only at home when we're on the run, on the wing, on the fly" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/compat/linux linux_stats.c
At Thu, 2 Nov 2000 14:11:44 -0500 (EST), Andrew Gallatin wrote: > To clarify -- this is the native /bin/ls and NOT /compat/linux/bin/ls? Yes. > I don't suppose you could throw an older kernel on and show the output > of /bin/ls /compat/linux/dev ? Here is the output from the native /bin/ls on 5.0-CURRENT as of two days ago. This operation causes panic on the latest CURRENT: knu@archon[2]% uname -a FreeBSD archon.local.idaemons.org 5.0-CURRENT FreeBSD 5.0-CURRENT #13: Tue Oct 31 15:11:38 JST 2000 [EMAIL PROTECTED]:/usr/local/src/sys/compile/ARCHON i386 knu@archon[2]% ls -l /compat/linux/dev total 0 brw-r--r-- 1 root wheel - 0, 0x00010002 Nov 2 20:28 hda brw-r--r-- 1 root wheel - 0, 0x0001000a Nov 2 20:28 hdb crw-rw-rw- 1 root wheel - 2, 2 Nov 2 20:28 null crw-r--r-- 1 root wheel - 202, 0 Nov 2 20:17 rtc lrwxr-xr-x 1 root wheel - 22 Nov 2 20:28 tty0@ -> /compat/linux/dev/tty1 lrwxr-xr-x 1 root wheel - 10 Nov 2 20:28 tty1@ -> /dev/ttyv0 lrwxr-xr-x 1 root wheel - 10 Nov 2 20:28 tty10@ -> /dev/ttyv9 lrwxr-xr-x 1 root wheel - 10 Nov 2 20:28 tty11@ -> /dev/ttyva lrwxr-xr-x 1 root wheel - 10 Nov 2 20:28 tty12@ -> /dev/ttyvb lrwxr-xr-x 1 root wheel - 10 Nov 2 20:28 tty2@ -> /dev/ttyv1 lrwxr-xr-x 1 root wheel - 10 Nov 2 20:28 tty3@ -> /dev/ttyv2 lrwxr-xr-x 1 root wheel - 10 Nov 2 20:28 tty4@ -> /dev/ttyv3 lrwxr-xr-x 1 root wheel - 10 Nov 2 20:28 tty5@ -> /dev/ttyv4 lrwxr-xr-x 1 root wheel - 10 Nov 2 20:28 tty6@ -> /dev/ttyv5 lrwxr-xr-x 1 root wheel - 10 Nov 2 20:28 tty7@ -> /dev/ttyv6 lrwxr-xr-x 1 root wheel - 10 Nov 2 20:28 tty8@ -> /dev/ttyv7 lrwxr-xr-x 1 root wheel - 10 Nov 2 20:28 tty9@ -> /dev/ttyv8 crw-r--r-- 1 root wheel - 200, 0 Nov 2 20:28 vmmon crw-r--r-- 1 root wheel - 149, 0x00010001 Nov 2 20:35 vmnet1 As you see, hda and hdb are block devices that might cause the panic.. -- / /__ __ / ) ) ) ) /and.or.jp / ruby-lang.org Akinori -Aki- MUSHA aka / (_ / ( (__( @ idaemons.org / FreeBSD.org "We're only at home when we're on the run, on the wing, on the fly" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/compat/linux linux_stats.c
At Fri, 03 Nov 2000 02:02:50 +0900, I wrote: > I'm 100% sure this change caused the panic because the stack trace > showed it panicked at vfinddev() called from linux_ustat(). D'uh, I lied! Actually `ls /compat/linux/dev' panics at: vfinddev() <-- addaliasu() <-- ufs_vinit(). Seems I was 100% confused looking alternatively at source and ddb console. Sorry for the false report, but I'm repoting the truth this time. ;) Anyway, I think you can reproduce the panic by installing vmware2 port and doing `ls /compat/linux/dev'. Regards, -- / /__ __ / ) ) ) ) /and.or.jp / ruby-lang.org Akinori -Aki- MUSHA aka / (_ / ( (__( @ idaemons.org / FreeBSD.org "We're only at home when we're on the run, on the wing, on the fly" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/compat/linux linux_stats.c
At Wed, 1 Nov 2000 22:08:26 -0800 (PST), Marcel Moolenaar wrote: > marcel 2000/11/01 22:08:26 PST > > Modified files: > sys/compat/linux linux_stats.c > Log: > Fix linux_ustat syscall. We only have cdevs now, so looking > for a block device isn't that useful anymore. > > Reported by: Wesley Morgan <[EMAIL PROTECTED]> > Submitted by: gallatin > Acknowledged by: phk After this change, it panics when you perform stat against a linux block device node. Actually, emulators/vmware2 port creates some block device nodes in /compat/linux/dev, so all the vmware2 users still have ones installed. And when they hit `ls /compat/linux/dev' or `pkg_delete vmware-2.0.x.yyy', they will see their boxen panic. ;) I'm 100% sure this change caused the panic because the stack trace showed it panicked at vfinddev() called from linux_ustat(). Please fix it! ;> -- / /__ __ / ) ) ) ) /and.or.jp / ruby-lang.org Akinori -Aki- MUSHA aka / (_ / ( (__( @ idaemons.org / FreeBSD.org "We're only at home when we're on the run, on the wing, on the fly" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskslice.c src/sys/sys diskslice.h src/sys/cam/scsi scsi_cd.c
At Sun, 29 Oct 2000 23:03:02 -0800 (PST), Kenneth Merry wrote: > ken 2000/10/29 23:03:02 PST > > Modified files: > sys/kern subr_diskslice.c > sys/sys diskslice.h > sys/cam/scsi scsi_cd.c > Log: > Write support for the cd(4) driver. I get the following messages when I hit "cdcontrol -f /dev/cd0 play" against a music CD: Oct 31 16:06:40 archon /boot/kernel/kernel: (cd0:ahc0:0:2:0): READ(10). CDB: 28 0 0 0 0 1 0 0 1 0 Oct 31 16:06:40 archon /boot/kernel/kernel: (cd0:ahc0:0:2:0): ILLEGAL REQUEST asc:64,0 Oct 31 16:06:40 archon /boot/kernel/kernel: (cd0:ahc0:0:2:0): Illegal mode for this track Oct 31 16:06:40 archon /boot/kernel/kernel: (cd0:ahc0:0:2:0): cddone: got error 0x16 back Though the music goes just fine. -- / /__ __ / ) ) ) ) /and.or.jp / ruby-lang.org Akinori -Aki- MUSHA aka / (_ / ( (__( @ idaemons.org / FreeBSD.org "We're only at home when we're on the run, on the wing, on the fly" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sendmail related changes
Would you add an UPDATING entry for this? Many people have been reporting problems with the local mailer not knowing these changes. At Tue, 10 Oct 2000 11:19:43 -0700 (PDT), Gregory Neil Shapiro wrote: > The following changes have been made in -CURRENT: > > 1. mail.local(8) is no longer installed as a set-user-id binary. > >If you are using a /etc/mail/sendmail.cf from the default sendmail.cf >included with FreeBSD any time after 3.1.0, you are fine. If you are >using a hand-configured sendmail.cf and mail.local for delivery, check >to make sure the F=S flag is set on the Mlocal line. Those with .mc >files who need to add the flag can do so by adding the following line to >their your .mc file and regenerating the sendmail.cf file: > >MODIFY_MAILER_FLAGS(`LOCAL', `+S')dnl > >Note that FEATURE(`local_lmtp') already does this. > > 2. sendmail(8) is now built with STARTTLS support unless NO_OPENSSL is set. > > 3. The default /etc/mail/sendmail.cf disables the SMTP EXPN and VRFY >commands. > > 4. Now using sendmail's version of vacation(1). > >This change should be transparent except for the new options/features >available. > > 5. The sendmail cf building tools (contrib/sendmail/cf) are installed in >/usr/share/sendmail/cf. > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > -- / /__ __ / ) ) ) ) /and.or.jp / ruby-lang.org Akinori -Aki- MUSHA aka / (_ / ( (__( @ idaemons.org / FreeBSD.org "We're only at home when we're on the run, on the wing, on the fly" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)
At Sun, 23 Jan 2000 10:26:48 +0100 (CET),
Oliver Fromme <[EMAIL PROTECTED]> wrote:
> I don't like bzip2 for the sole fact that it takes _ages_ to
> compress files, compared to gzip. Saving 10% or 20% on disk
> space is not worth wasting >= 10 times more CPU time than gzip.
> Disk space is cheap nowadays, but upgrading to a CPU that is
> 10 times faster is not.
But when one compresses a file with bzip2 and prepare a smaller
distribution, hundreds of people can save their download time. That's
why we compress things. I'd focus on the receivers' side.
Of course a necessary manner is preparing also a gzip'ed file for
those who prefer gzip's less memory usage rather than bzip2's higher
compression. And still, a standard is a standard.
> (I once tried to compress our FreeBSD ISO images with bzip2,
> just to compare the space savings with gzip. I aborted the
> experiment after 6 hours (!). gzip took about 30 minutes.
> Consequently, bzip2 was considered unusable and went into the
> trash can.)
Not everyone wants/needs to compress such a big stuff with bzip2
to waste time. But having bzip2/bunzip2 gives us an option.
> I'd vote for keeping things as they are: bzip2 is fine as
> a port.
Despite all of above, I have to agree that, since whether having bzip2
is already an option thanks to the port. :)
--
/
/__ __
/ ) ) ) ) / http://www.idaemons.org/knu/
Akinori MUSHA aka / (_ / ( (__( mailto:[EMAIL PROTECTED]
"We are but hungry.. Associated Ita-meshi Daemons!"
http://www.idaemons.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)
At Sat, 22 Jan 2000 12:42:55 -0500 (EST), Chuck Robey <[EMAIL PROTECTED]> wrote: > A case would have to be built that bzip2 does something critical that > cannot be done without bzip2. Else, it stays as a fine port. Heck, emacs > is a fine port too, but it'll never get into the base system. Hmm... seems NetBSD folks already have bzip2 in their source tree, while OpenBSD folks not. Then how about us? IMHO, bzip2 tarballs are increasing in number out there because each software is growing bigger and bigger nowadays, and thus in great demand is the better compression: i.e. bzip2 rather than gzip. I don't think we should compress everything with bzip2 instead of gzip, however, I believe we'd better have bunzip2 by default as there are many software which both *.gz and *.bz2 are provided for download, such as Lynx, WindowMaker, GIMP, KDE and Linux kernel. Yes, they are pretty big enough to see the difference between two... .tar.bz2.tar.gz lynx2.8.2rel11.4MB 1.8MB WindowMaeker 0.61.1 1.6MB 1.9MB gimp-1.1.13 6.2MB 8.0MB kdebase-1.1.27.0MB 8.9MB linux-2.2.1412.3MB 15.2MB It's crystal clear bzip2 wins in these cases. and far enough. -- / /__ __ / ) ) ) ) / http://www.idaemons.org/knu/ Akinori MUSHA aka / (_ / ( (__( mailto:[EMAIL PROTECTED] "We are but hungry.. Associated Ita-meshi Daemons!" http://www.idaemons.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
