fortunes(6) typo

2013-04-01 Thread Jason McIntyre
pesky amino acids! ok?
jmc

Index: fortunes
===
RCS file: /cvs/src/games/fortune/datfiles/fortunes,v
retrieving revision 1.44
diff -u -r1.44 fortunes
--- fortunes10 Feb 2013 15:21:28 -  1.44
+++ fortunes 1 Apr 2013 07:49:00 -
@@ -8735,7 +8735,7 @@
 Message will arrive in the mail.
 Destroy, before the FBI sees it.
 %
-methionylglutaminylarginyltyrosylglutamylserylleucylphenylalanylalanylglutaminylleucyllysylglutamylarginyllysylglutamylglycylalanylphenylalanylvalylprolylphenylalanylvalylthreonylleucylglycylaspartylprolylglycylisoleucylglutamylglutaminylserylleucyllysylisoleucylaspartylthreonylleucylisoleucylglutamylalanylglycylalanylaspartylalanylleucylglutamylleucylglycylisoleucylprolylphenylalanylserylaspartylprolylleucylalanylaspartylglycylprolylthreonylisoleucylglutaminylasparaginylalanylthreonylleucylarginylalanylphenylalanylalanylalanylglycylvalylthreonylprolylalanylglutaminylcysteinylphenylalanylglutamylmethionylleucylalanylleucylisoleucylarginylglutaminyllysylhistidylprolylthreonylisoleucylprolylisoleucylglycylleucylleucylmethionyltyrosylalanylasparaginylleucylvalylphenylalanylasparaginyllysylglycylisoleucylaspartylglutamylphenylalanyltyrosylalanylglutaminylcysteinylglutamyllysylvalylglycylvalylaspartylserylvalylleucylvalylalanylaspartylvalylprolylvalylglutaminylglutamylserylalany!
 
lprolylphenylalanylarginylglutaminylalanylalanylleucylarginylhistidylasparaginylvalylalanylprolylisoleucylphenylalanylisoleucylcysteinylprolylprolylaspartylalanylaspartylaspartylaspartylleucylleucylarginylglutaminylisoleucylalanylseryltyrosylglycylarginylglycyltyrosylthreonyltyrosylleucylleucylserylarginylalanylglycylvalylthreonylglycylalanylglutamylasparaginylarginylalanylalanylleucylprolylleucylasparaginylhistidylleucylvalylalanyllysylleucyllysylglutamyltyrosylasparaginylalanylalanylprolylprolylleucylglutaminylglycylphenylalanylglycylisoleucylserylalanylprolylaspartylglutaminylvalyllysylalanylalanylisoleucylaspartylalanylglycylalanylalanylglycylalanylisoleucylserylglycylserylalanylisoleucylvalyllysylisoleucylisoleucylglutamylglutaminylhistidylasparaginylisoleucylglutamylprolylglutamyllysylmethionylleucylalanylalanylleucyllysylvalylphenylalanylvalylglutaminylprolylmethionyllysylalanylalanylthreonylarginylserine,n.:
+methionylglutaminylarginyltyrosylglutamylserylleucylphenylalanylalanylglutaminylleucyllysylglutamylarginyllysylglutamylglycylalanylphenylalanylvalylprolylphenylalanylvalylthreonylleucylglycylaspartylprolylglycylisoleucylglutamylglutaminylserylleucyllysylisoleucylaspartylthreonylleucylisoleucylglutamylalanylglycylalanylaspartylalanylleucylglutamylleucylglycylisoleucylprolylphenylalanylserylaspartylprolylleucylalanylaspartylglycylprolylthreonylisoleucylglutaminylasparaginylalanylthreonylleucylarginylalanylphenylalanylalanylalanylglycylvalylthreonylprolylalanylglutaminylcysteinylphenylalanylglutamylmethionylleucylalanylleucylisoleucylarginylglutaminyllysylhistidylprolylthreonylisoleucylprolylisoleucylglycylleucylleucylmethionyltyrosylalanylasparaginylleucylvalylphenylalanylasparaginyllysylglycylisoleucylaspartylglutamylphenylalanyllyrosylalanylglutaminylcysteinylglutamyllysylvalylglycylvalylaspartylserylvalylleucylvalylalanylaspartylvalylprolylvalylglutaminylglutamylserylalany!
 
lprolylphenylalanylarginylglutaminylalanylalanylleucylarginylhistidylasparaginylvalylalanylprolylisoleucylphenylalanylisoleucylcysteinylprolylprolylaspartylalanylaspartylaspartylaspartylleucylleucylarginylglutaminylisoleucylalanylseryltyrosylglycylarginylglycyltyrosylthreonyltyrosylleucylleucylserylarginylalanylglycylvalylthreonylglycylalanylglutamylasparaginylarginylalanylalanylleucylprolylleucylasparaginylhistidylleucylvalylalanyllysylleucyllysylglutamyltyrosylasparaginylalanylalanylprolylprolylleucylglutaminylglycylphenylalanylglycylisoleucylserylalanylprolylaspartylglutaminylvalyllysylalanylalanylisoleucylaspartylalanylglycylalanylalanylglycylalanylisoleucylserylglycylserylalanylisoleucylvalyllysylisoleucylisoleucylglutamylglutaminylhistidylasparaginylisoleucylglutamylprolylglutamyllysylmethionylleucylalanylalanylleucyllysylvalylphenylalanylvalylglutaminylprolylmethionyllysylalanylalanylthreonylarginylserine,n.:
The chemical name for tryptophan synthetase A protein, a
1,913-letter enzyme with 267 amino acids.
-- Mrs. Byrne's Dictionary of Unusual, Obscure, and



Re: fortunes(6) typo

2013-04-01 Thread Philip Guenther
On Sun, Mar 31, 2013 at 11:49 PM, Jason McIntyre j...@kerhand.co.uk wrote:

 pesky amino acids! ok?

...

 The chemical name for tryptophan synthetase A protein, a
 1,913-letter enzyme with 267 amino acids.
 -- Mrs. Byrne's Dictionary of Unusual, Obscure, and


Hmm, how is it spelled in Mrs. Byrne's dictionary?  If she misspelled it,
well, perhaps we should add [sic], for the added laughs, but fixing it
seems wrong to me...


Philip


remove invalid evergreen ids from radeondrm

2013-04-01 Thread Jonathan Gray
It seems some people were confused about what should
be in radeondrm. In CHIP_* terms:

HD6320 is PALM
HD5450 is CEDAR

These are both evergreen/R800 parts we have no support for and
should not be listed.

Index: radeon_drv.c
===
RCS file: /cvs/src/sys/dev/pci/drm/radeon_drv.c,v
retrieving revision 1.63
diff -u -p -r1.63 radeon_drv.c
--- radeon_drv.c18 Mar 2013 12:36:51 -  1.63
+++ radeon_drv.c1 Apr 2013 10:15:32 -
@@ -667,8 +667,6 @@ const static struct drm_pcidev radeondrm
CHIP_RV770|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD4890,
CHIP_RV770|RADEON_NEW_MEMMAP},
-   {PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD6320,
-   CHIP_RV770|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD4100,
CHIP_RS880|RADEON_NEW_MEMMAP|RADEON_IS_IGP},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD4200,
@@ -681,8 +679,6 @@ const static struct drm_pcidev radeondrm
CHIP_RS880|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD4290,
CHIP_RS880|RADEON_NEW_MEMMAP|RADEON_IS_IGP},
-   {PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD5450,
-   CHIP_RS880|RADEON_NEW_MEMMAP},
 {0, 0, 0}
 };
 



Active PS/2 Multiplexing

2013-04-01 Thread Tobias Stoeckmann
Hi,

this issue is already quite old, but let's see if anyone else has still
issues with active PS/2 multiplexing.

Active PS/2 multiplexing is a method to attach multiple input devices on
your AUX PS/2 slot.  This should be as of today of no real use anymore,
since it's easier to just add a USB device instead of getting into this
mess ...

But if you are as lucky as I am, you might have a laptop that uses this
mechanism for your touchpad.  Without having this diff active, your
touchpad will behave totally weird, like jumping cursors and random
clicking whenever you touch it.  So if you suffer from that, give this
patch a try.

Would like to get some feedback!


Tobias

PS: For the record and previously involved developers:  It's basically
Miod's old diff with my fix for suspend and resume to reactive multiplexing
if available.

Index: arch/hppa/gsc/gsckbc.c
===
RCS file: /var/www/cvs/src/sys/arch/hppa/gsc/gsckbc.c,v
retrieving revision 1.14
diff -u -p -r1.14 gsckbc.c
--- arch/hppa/gsc/gsckbc.c  10 Aug 2012 17:49:31 -  1.14
+++ arch/hppa/gsc/gsckbc.c  1 Apr 2013 14:56:22 -
@@ -469,7 +469,7 @@ pckbc_poll_data1(iot, ioh, ioh_c, slot, 
bus_space_tag_t iot;
bus_space_handle_t ioh, ioh_c;
pckbc_slot_t slot;
-   int checkaux;   /* ignored on hppa */
+   struct pckbc_internal *t;   /* ignored on hppa */
 {
int i;
u_char stat;
@@ -568,7 +568,7 @@ pckbc_flush(self, slot)
 {
struct pckbc_internal *t = self;
 
-   pckbc_poll_data1(t-t_iot, t-t_ioh_d, t-t_ioh_d, slot, 0);
+   pckbc_poll_data1(t-t_iot, t-t_ioh_d, t-t_ioh_d, slot, t);
 }
 
 int
@@ -580,7 +580,7 @@ pckbc_poll_data(self, slot)
struct pckbc_slotdata *q = t-t_slotdata[slot];
int c;
 
-   c = pckbc_poll_data1(t-t_iot, t-t_ioh_d, t-t_ioh_d, slot, 0);
+   c = pckbc_poll_data1(t-t_iot, t-t_ioh_d, t-t_ioh_d, slot, t);
if (c != -1  q  CMD_IN_QUEUE(q)) {
/* we jumped into a running command - try to
 deliver the response */
@@ -655,7 +655,7 @@ pckbc_poll_cmd1(t, slot, cmd)
return;
}
for (i = 10; i; i--) { /* 1s ??? */
-   c = pckbc_poll_data1(iot, ioh, ioh, slot, 0);
+   c = pckbc_poll_data1(iot, ioh, ioh, slot, t);
if (c != -1)
break;
}
@@ -696,7 +696,7 @@ pckbc_poll_cmd1(t, slot, cmd)
else
i = 10; /* 1s ??? */
while (i--) {
-   c = pckbc_poll_data1(iot, ioh, ioh, slot, 0);
+   c = pckbc_poll_data1(iot, ioh, ioh, slot, t);
if (c != -1)
break;
}
Index: dev/ic/i8042reg.h
===
RCS file: /var/www/cvs/src/sys/dev/ic/i8042reg.h,v
retrieving revision 1.5
diff -u -p -r1.5 i8042reg.h
--- dev/ic/i8042reg.h   18 Aug 2001 15:30:39 -  1.5
+++ dev/ic/i8042reg.h   1 Apr 2013 14:46:09 -
@@ -44,3 +44,17 @@
 #defineKC8_MENABLE 0x02/* enable mouse interrupt */
 #defineKC8_KENABLE 0x01/* enable keyboard interrupt */
 #defineCMDBYTE (KC8_TRANS|KC8_CPU|KC8_MENABLE|KC8_KENABLE)
+
+/*
+ * Defines for Active PS/2 Multiplexing
+ */
+
+#defineKBC_APM_ENB10xf0
+#defineKBC_APM_ENB20x56
+#defineKBC_APM_ENB30xa4
+
+#defineKBC_APM_DIS10xf0
+#defineKBC_APM_DIS20x56
+#defineKBC_APM_DIS30xa5
+
+#defineKBC_APM_PREFIX(p)   (0x90 | (p))
Index: dev/ic/pckbc.c
===
RCS file: /var/www/cvs/src/sys/dev/ic/pckbc.c,v
retrieving revision 1.33
diff -u -p -r1.33 pckbc.c
--- dev/ic/pckbc.c  15 Feb 2013 08:49:51 -  1.33
+++ dev/ic/pckbc.c  1 Apr 2013 15:03:38 -
@@ -105,8 +105,20 @@ void pckbc_poll(void *);
 int pckbc_cmdresponse(struct pckbc_internal *, pckbc_slot_t, u_char);
 void pckbc_start(struct pckbc_internal *, pckbc_slot_t);
 int pckbcintr_internal(struct pckbc_internal *, struct pckbc_softc *);
+int pckbc_enable_apm(struct pckbc_internal *);
+int pckbc_disable_apm(struct pckbc_internal *);
 
-const char *pckbc_slot_names[] = { kbd, aux };
+const char *pckbc_slot_names[] = {
+   kbd slot,
+#ifdef PCKBC_APM
+   aux slot #0,
+   aux slot #1,
+   aux slot #2,
+   aux slot #3,
+#else
+   aux slot
+#endif
+};
 
 #define KBC_DEVCMD_ACK 0xfa
 #define KBC_DEVCMD_RESEND  0xfe
@@ -137,31 +149,58 @@ pckbc_send_cmd(bus_space_tag_t iot, bus_
return (1);
 }
 
+/*
+ * NOTE: Active PS/2 Multiplexing behaviour is only checked if t != NULL.
+ * This behaviour is intentional.
+ */
 int
 pckbc_poll_data1(bus_space_tag_t iot, bus_space_handle_t ioh_d,
-

Sendmail 8.14.6 errata

2013-04-01 Thread Jérémie Courrèges-Anglas
Hi,

while working on the Sendmail port, I noticed this:

https://www.sendmail.com/sm/open_source/download/8.14.6/

I included this patch in my (still WIP) port, but I figured it would be
better if it were fixed in base first.

Regards,
-- 
Jérémie Courrèges-Anglas
GPG Key fingerprint: 61DB D9A0 00A4 67CF 2A90  8961 6191 8FBF 06A1 1494



Re: [NEW] ugold(4) driver for Microdia's USB TEMPer variant

2013-04-01 Thread Luis Coronado
Sasano,

your patch applies without problems in -current.

This is what I see:

uname -a:
$ uname -a
OpenBSD obsdbox.ticoit.net 5.3 GENERIC.MP#15 amd64

from dmesg:
OpenBSD 5.3-current (GENERIC.MP) #15: Mon Apr  1 13:44:48 CST 2013
.
.
.
uhidev3 at uhub4 port 2 configuration 1 interface 0 RDing TEMPerV1.2 rev
2.00/0.01 addr 3
uhidev3: iclass 3/1, 1 report id
ugold0 at uhidev3 reportid 1
uhidev4 at uhub4 port 2 configuration 1 interface 1 RDing TEMPerV1.2 rev
2.00/0.01 addr 3
uhidev4: iclass 3/1
ugold1 at uhidev4
ugold1: type ds75/12bit (temperature)
uhidev5 at uhub3 port 1 configuration 1 interface 0 RDing TEMPerV1.2 rev
2.00/0.01 addr 3
uhidev5: iclass 3/1, 1 report id
ugold2 at uhidev5 reportid 1
uhidev6 at uhub3 port 1 configuration 1 interface 1 RDing TEMPerV1.2 rev
2.00/0.01 addr 3
uhidev6: iclass 3/1
ugold3 at uhidev6
ugold3: type ds75/12bit (temperature)

sysctl hw.sensors:
hw.sensors.ugold1.temp0=30.50 degC (inner)
hw.sensors.ugold3.temp0=33.75 degC (inner)

usbdevs -vd:
Controller /dev/usb3:
addr 1: full speed, self powered, config 1, UHCI root hub(0x),
Intel(0x8086), rev 1.00
  uhub3
 port 1 addr 3: low speed, power 100 mA, config 1, TEMPerV1.2(0x7401),
RDing(0x0c45), rev 0.01
   uhidev5
   uhidev6
 port 2 addr 2: low speed, power 98 mA, config 1, USB Optical
Mouse(0xc054), Logitech(0x046d), rev 54.00
   uhidev0
Controller /dev/usb4:
addr 1: full speed, self powered, config 1, UHCI root hub(0x),
Intel(0x8086), rev 1.00
  uhub4
 port 1 addr 2: low speed, power 100 mA, config 1, HP USB Multimedia
Keyboard(0x0841), CHICONY(0x04f2), rev 1.00
   uhidev1
   uhidev2
 port 2 addr 3: low speed, power 100 mA, config 1, TEMPerV1.2(0x7401),
RDing(0x0c45), rev 0.01
   uhidev3
   uhidev4

So far so good. Icinga is happy.

-luis




On Sun, Mar 31, 2013 at 2:56 AM, SASANO Takayoshi u...@mx5.nisiq.net wrote:

 Hello,

 I rewrote patched uthum(4) to new ugold(4) driver.
 Thanks for advice by yuo@ and deraadt@.

 The diff for -current's /usr/src/sys is large to send mailing-list,
 so here is the URL:

 http://www2192ue.sakura.ne.jp/~uaa/gomitext/2013/20130331/20130331.diff

 If you want to try ugold(4) and already use Microdia's-variant-patched
 uthum(4) driver, revert original uthum(4).

 ok or comments, please.

 Cheers,
 --
 SASANO Takayoshi u...@mx5.nisiq.net




sys/socket.h __BSD_VISIBLE

2013-04-01 Thread James Turner
I've come across a piece of software that defines __POSIX_C_SOURCE which
causes __BSD_VISIBLE to bet set to 0.

In sys/socket.h if __BSD_VISIBLE is 0 sys/_types.h is included instead
of sys/types.h. This is fine however in three cases we reference
u_int8_t (2) and u_int64_t (1) which requires sys/types.h.

If we change these to __uint8_t and __uint64_t they work with either
types.h or _types.h. Does this make sense? Will there be any side
effects?

-- 
James Turner
Index: sys/sys/socket.h
===
RCS file: /cvs/src/sys/sys/socket.h,v
retrieving revision 1.82
diff -u -p -r1.82 socket.h
--- sys/sys/socket.h15 Sep 2012 00:47:08 -  1.82
+++ sys/sys/socket.h2 Apr 2013 02:40:46 -
@@ -186,7 +186,7 @@ struct  splice {
  * addresses.
  */
 struct sockaddr {
-   u_int8_tsa_len; /* total length */
+   __uint8_tsa_len;/* total length */
sa_family_t sa_family;  /* address family */
charsa_data[14];/* actually longer; address value */
 };
@@ -204,10 +204,10 @@ struct sockaddr {
  * occurrences (including header file) to __ss_len.
  */
 struct sockaddr_storage {
-   u_int8_tss_len; /* total length */
+   __uint8_t   ss_len; /* total length */
sa_family_t ss_family;  /* address family */
unsigned char   __ss_pad1[6];   /* align to quad */
-   u_int64_t   __ss_pad2;  /* force alignment for stupid compilers 
*/
+   __uint64_t  __ss_pad2;  /* force alignment for stupid compilers 
*/
unsigned char   __ss_pad3[240]; /* pad to a total of 256 bytes */
 };
 


Re: sys/socket.h __BSD_VISIBLE

2013-04-01 Thread Ted Unangst
On Mon, Apr 01, 2013 at 22:54, James Turner wrote:
 I've come across a piece of software that defines __POSIX_C_SOURCE which
 causes __BSD_VISIBLE to bet set to 0.
 
 In sys/socket.h if __BSD_VISIBLE is 0 sys/_types.h is included instead
 of sys/types.h. This is fine however in three cases we reference
 u_int8_t (2) and u_int64_t (1) which requires sys/types.h.
 
 If we change these to __uint8_t and __uint64_t they work with either
 types.h or _types.h. Does this make sense? Will there be any side
 effects?
 

I believe the correct type would be uint8_t or uint64_t. Those should be
visible (I think). A quick look indicates that maybe they aren't, so that
won't work.

There won't be any side effects from using __uint64_t, but I think of it
more like a building block for another type. Not to be used directly.

I would like to believe that posix allows int64_t to be visible after
including socket.h since they use it in their sample sockaddr_storage
implementation, but the text doesn't seem to allow that.

Maybe the __uint64_t type is the way to go.



Re: sys/socket.h __BSD_VISIBLE

2013-04-01 Thread Philip Guenther
On Mon, Apr 1, 2013 at 8:35 PM, Ted Unangst t...@tedunangst.com wrote:

 On Mon, Apr 01, 2013 at 22:54, James Turner wrote:
  I've come across a piece of software that defines __POSIX_C_SOURCE which
  causes __BSD_VISIBLE to bet set to 0.
 
  In sys/socket.h if __BSD_VISIBLE is 0 sys/_types.h is included instead
  of sys/types.h. This is fine however in three cases we reference
  u_int8_t (2) and u_int64_t (1) which requires sys/types.h.
 
  If we change these to __uint8_t and __uint64_t they work with either
  types.h or _types.h. Does this make sense? Will there be any side
  effects?

 I believe the correct type would be uint8_t or uint64_t. Those should be
 visible (I think). A quick look indicates that maybe they aren't, so that
 won't work.

 There won't be any side effects from using __uint64_t, but I think of it
 more like a building block for another type. Not to be used directly.


Disagree.  Indeed, I just committed James's diff (plus one additional
change to CMSG_DATA()).

(Thanks, James!)

Philip Guenther


Re: sys/socket.h __BSD_VISIBLE

2013-04-01 Thread Ted Unangst
On Mon, Apr 01, 2013 at 20:40, Philip Guenther wrote:

 There won't be any side effects from using __uint64_t, but I think of it
 more like a building block for another type. Not to be used directly.

 
 Disagree.  Indeed, I just committed James's diff (plus one additional
 change to CMSG_DATA()).

My (admittedly weak) rationale is that if a struct contains a field, I would
like to be able to declare local variables of the same type as that field.
And I don't want my local variables in my code to be using __int types.



Re: sys/socket.h __BSD_VISIBLE

2013-04-01 Thread Philip Guenther
On Mon, Apr 1, 2013 at 9:06 PM, Ted Unangst t...@tedunangst.com wrote:

 My (admittedly weak) rationale is that if a struct contains a field, I
 would
 like to be able to declare local variables of the same type as that field.
 And I don't want my local variables in my code to be using __int types.


In the specific cases here, sa_len and __ss_pad2, the answers are no, you
should *not* be modelling variables on those!.  sa_len should only be used
by code using routing-domain sockets, and there are macros for setting it
after you've updated the socket, and you shouldn't be modelling your own
data structures after what routing sockets do on the wire.

Reusing the type of an double-underbar-prefix *padding* member gets you
hurt in back alleys.

Note that the stuff that it makes sense to copy into your own data
structures does use real, public types.


Philip Guenther