On Mon, Oct 25, 2010 at 12:58 AM, Dmitrij Czarkoff <czarkoff@gmail.com> that are better suited to changing the From: header, otherwise If you really want to use mail(1) then i think your best option is to look at using the mta to re-write the From: addressi as suggested earlier, which is typically sendmail, otherwise the closest thing you can get to it is by using the -r Sorry, the actual lines I added to openbsd-localhost.mc are: FEATURE(genericstable, `hash ...

Assuming you're using the out-of-the-box sendmail, you should just need to update /etc/mail/genericstable and follow the directions in the comment at the top of the file to rebuild it. Philip Guenther

I'm using mail(1) to send mail from my Gmail account. The messages I send have my username and hostname in "From" header. Can I somehow alter the "From" header to my gmail address? -- Dmitrij D. Czarkoff

Thank You for this tip, but the problem isn't solved. Does sendmail on OpenBSD read genericstable db by default? -- Dmitrij D. Czarkoff

When it comes to using Sendmail features the only thing you can do is spend time reading about them. There is lot's of information out there. It is quite a complex system which requires a certain level of understanding. Besides, we can only guess what your logs say and if/what the errors you're experiencing are. -- Jamie Paul Griffin GPG Key: DF52D9B0 [demime 1.01d removed an attachment of type application/pgp-signature]

Hi, I've seen BMC local access seems impossible: http://www.mail-archive.com/misc@openbsd.org/msg93376.html Is it really impossible or did I missed some point ? Is there a reason for not implementing a local driver as /usr/src/sys/dev/ipmi.c seems to contain all the code needed to interact with bmc ? Manuel -- ______________________________________________________________________ Manuel Guesdon - OXYMIUM

Received the 4.8 CD set today in Arizona. Many thanks to all the developers from a very satisfied OpenBSD desktop user. Gary

Received 4.8 CD set today in Arizona. Many thanks to all the developers from a very satisfied OpenBSD desktop user. Gary

Well... i guess i was thinking that from the unit identifier in softraid<n> the actual raid volume would be known.

The one piece of information I found a bit unclear in the manual is how to rebuild a degraded mirror: bioctl -R <newchunk> <raid> where *both* the <newchunk> and the <raid> argument are real disknames, as in "bioctl -R sd1 sd2" for a case were physical devices sd0 and sd1 formed a mirror creating the softraid device sd2, and sd1 fell offline. I would indeed have expected the second argument to be softraid<x> The manual states: -R device | channel:target[.lun] Manually kick off ...

How would softraid know which sd to rebuild if 3 are degraded? Not debating the language couldn't be improved but that bit is IMO pretty obvious.

It means you get hardware acceleration :) Intel video driver is probably the best supported on X.

Probably -current and wpi. What I still get are occasional kernel asserts at boot at wpi firmware load and I have to rerun sh /etc/netstart wpi0 to make it work. ciao Luca

I have no idea :) -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting

Well, I have this on a Dell Precision 220 and graphics acceleration doesn't work in X. pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x2500 rev 0x03 agp at pchb0 not configured radeondrm0 at vga1: apic 2 int 16 (irq 9) drm0 at radeondrm0 I figured if there is a "not configured" or "unknown product" associated with anything in the graphics subsystem, then you don't get graphics acceleration or hardware support in general. Hence the: "Intel GM965 Video" rev 0x0c at ...

Just like my dell latitude L400...... ;))))) ...too bad it sports an awful power connector and its battery is dead ...but actually I emptied the battery, so that it's also way lighter ;))) ...and with a new 80G hd ;)))) Then, T61 is perfect for you :)

Analyzing group_show, I found out: winlist = (Window *) xcalloc(sizeof(*winlist), (gc->highstack + 1)); ... TAILQ_FOREACH(cc, &gc->clients, group_entry) { winlist[gc->highstack - cc->stackingorder] = cc->win; client_unhide(cc); } For some reason cc->stackingorder is bigger than gc->highstack (which is 0 in above use case), thus the assignment writes to a negative address relative to winlist. I can reproduce that on OpenBSD 4.8/cwm HEAD as well, it just doesn't crash there because ...

Not always is it ? I have had toswitch from Linux to OpenBSD twice just because of hardware support. --Siju