Important message for Apple Silicon OpenBSD/arm64 users

[Mark Kettenis]

As indicated here:

  https://social.treehouse.systems/@AsahiLinux/112449204541186432

The system firmware that comes with macOS Sonoma 14.5 triggers a bug
in the m1n1 bootloader that is used to boot OpenBSD on these machines.
The bug will prevent OpenBSD from booting on some machines after the
macOS update has been installed.  The recommended fix is to update the
"stage1" m1n1 by booting into macOS and running:

  $ curl https://alx.sh | sh

choosing the 'm' option when prompted to upgrade as indicated in the
aforementioned post.  This should work even if you've already
installed the macOS update.

We've also released a new version of the "apple-boot" firmware (which
contains a "stage2" m1n1) that has a workaround for the bug. To
install this new firmware on OpenBSD 7.5 or -current, you can do:

  # fw_update
  # installboot sd0

This must be done before updating macOS.  You can verify that the
workaround is installed with the following command:

  # eeprom -p | grep m1n1
  asahi,m1n1-stage2-version: '1.4.14'

If the displayed version number is 1.4.14 or later, the workaround is
installed.

OpenBSD 7.4 users should upgrade to OpenBSD 7.5.

Cheers,

Mark

important change: anoncvs (and cvsync) service at openbsd.cs.toronto.edu

[Nick Holland]

tl;dr version: openbsd.cs.toronto.edu anoncvs and cvsync users need to
start using anon...@obsdacvs.cs.toronto.edu and
cvsync://obsdacvs.cs.toronto.edu instead.


Full story:
===
Important notice for those using the mirror at University of Toronto:

Thanks to the OpenBSD Foundation and its donors, we have new hardware
for the mirror at University of Toronto, which will permit us to split
off the various services to separate hardware.

This means if you have been using openbsd.cs.toronto.edu as an anoncvs
server, you need to switch to using
   anon...@obsdacvs.cs.toronto.edu:/cvs
instead.

obsdacvs.cs.toronto.edu is up and ready for you now.  The old server
will continue to serve anoncvs through March (though failure of the old
hw could accelerate our plans), however it is getting its data from
obsdacvs, and its schedule will be adjusted so that it will be a few
hours BEHIND obsdacvs as a motivator to move. :)

Install files *will not* be changing URLs, just anoncvs and cvsync.

Nick.

Important SSH patch coming soon

[Theo de Raadt]

Important SSH patch coming soon.  For now, every on all operating
systems, please do the following:

Add undocumented "UseRoaming no" to ssh_config or use "-oUseRoaming=no"
to prevent upcoming #openssh client bug CVE-2016-0777. More later.

Re: Documentation on rc.conf.local lacks important warning

[Luca Ferrari]

On Wed, Feb 12, 2014 at 10:48 AM, Ingo Schwarze  wrote:
> Even though the misunderstanding does not seem to occur often,
> it does seem somewhat unsurprising because a lot of other software
> encourages the (imho questionable) practice of copying example
> configuration files.

I think the documentation is quite clear, and the practice of copying
a sample file is ...well ugly, but up to know it never confused me.
When copying a sample file you have to point to a src file like
/somehwere/example/file.conf  or /somewhere/file.conf.sample and both
makes it quite clear that they are "samples". In the case of rc.conf
it is pretty much clear that it is NOT a sample file.

I believe that to make it even more clear, instead of writing in the
documentation, the system should be deployed will all the .local files
in place (empty of course), so that there will be no misunderstanding
of what to edit. I don't like this approach since the system would be
potentially filled of files some users do not use, and will cause some
annoying behaviour of shell completion.
So I vote for the documentation first, but it sounds to me quite clear
as it is. As a final thought, the local-file approach is used even by
other platforms, and therefore we are in a "sample" like scenario:
users should be used to edit them properly.

Luca

Re: Documentation on rc.conf.local lacks important warning

[Ingo Schwarze]

Hi Jason,

Jason McIntyre wrote on Wed, Feb 12, 2014 at 09:58:00PM +:
> On Wed, Feb 12, 2014 at 09:13:43PM +0100, Ingo Schwarze wrote:

>> Actually, both mandoc and groff would be happy with stuff like
>>   .Xr boot_alpha 8/alpha
>> and off the top of my head, i don't see which tools might break.
[...]
>> So if you see value in making this explicit, i'd suggest asking on
>> the groff list whether anybody else expects problems, and if not,
>> documenting and using it.

> i wouldn;t want this to happen at all, to be honest. i just wanted to
> point out that you could do it. try adding it to the page, then see how
> ugly it becomes.

No problem, so i'm dropping the idea.

The current way of linking to arch-specific manuals seems completely
acceptable to me, i just wanted to make it clear that if there are
any technical obstacles, it's probably not difficult to overcome
them, if we want to.  Given that we don't want to, that's fine as
well.

Yours,
  Ingo

Re: Documentation on rc.conf.local lacks important warning

[Jason McIntyre]

On Wed, Feb 12, 2014 at 09:13:43PM +0100, Ingo Schwarze wrote:
> Hi Jason,
> 
> Jason McIntyre wrote on Mon, Feb 10, 2014 at 08:29:24AM +:
> > On Sun, Feb 09, 2014 at 03:19:36PM -0800, Philip Guenther wrote:
> >> On Sun, Feb 9, 2014 at 3:02 PM, d...@genunix.com  wrote:
> 
> >>> Question .. where do I get all the man pages?  I have some of them
> >>> but then others are absent :
> >>>
> >>> # man reboot
> >>> REBOOT(8)  OpenBSD System Manager's Manual REBOOT(8)
> >>> [...]
> >>> SEE ALSO
> >>>reboot(2), utmp(5), boot_alpha(8), boot_amd64(8), boot_hp300(8),
> >>>boot_hppa(8), boot_hppa64(8), boot_i386(8), boot_luna88k(8),
> >>>boot_macppc(8), boot_mvme68k(8), boot_mvme88k(8), boot_sparc(8),
> >>>boot_sparc64(8), boot_vax(8), boot_zaurus(8), rc.d(8), rc.shutdown(8),
> >>>savecore(8), shutdown(8), sync(8)
> 
> >> Hmm, that may be incorrect notation for the pages which are
> >> architecture specific: the boot_*(8) manpages are in the architecture
> >> specific sections.  They can be seen on all platforms using the -S
> >> option to man, ala:
> >> 
> >> man -S i386 boot_i386
> >> man -S sparc boot_sparc
> >> ...etc
> >> 
> >> By default, man uses the architecture that you're running, so if
> >> you're running on i386, you should be able to just say
> >> man boot_i386
> >> 
> >> I'm not 100% sure if the cross-references in the SEE ALSO section
> >> should be indicating that; I could have sworn that I saw syntax like
> >> "whatever(8/i386)" elsewhere.  Jason, Ingo, what the Right Thing here?
> 
> > we use 8/i386 notation in man -k (apropos) output, not in man pages,
> > though you can use 8/i386 instead of just 8, and mandoc won;t complain.
> > i suspect ingo will tell us it'll break other tools.
> 
> Actually, both mandoc and groff would be happy with stuff like
> 
>   .Xr boot_alpha 8/alpha
> 
> and off the top of my head, i don't see which tools might break.
> Certainly not our Perl makewhatis(8), it doesn't parse that deeply.
> And mandocdb(8) does the right thing out of the box, using it,
> you can even search for pages containing arch-specific .Xrs:
> 
>$ ./obj/apropos Xr=/alpha
>   halt(8), reboot(8) - stopping and restarting the system
>$ ./obj/apropos -O Xr Xr=/alpha
>   halt(8), reboot(8) - [...] # rc.conf(8) # boot_alpha(8/alpha) # [...]
> 
> Given that neither groff_mdoc(7) nor mdoc(7) mention this possibility,
> i'm not 100% sure all exotic tools will cope, but i don't consider
> problems very likely.  Most tools are quite lenient when parsing
> macro arguments, roff and groff traditionally do almost no validation,
> and most other tools refrain from parsing random content macros,
> anyway.
> 
> So if you see value in making this explicit, i'd suggest asking on
> the groff list whether anybody else expects problems, and if not,
> documenting and using it.
> 

i wouldn;t want this to happen at all, to be honest. i just wanted to
point out that you could do it. try adding it to the page, then see how
ugly it becomes.

jmc

> > in this case it seems clear the intent is to list all the boot_ pages and
> > assume the reader will understand. it's a fair assumption.
> 
> For boot_alpha(8), it's nearly obvious; but stuff like inb(2) may
> confuse readers quite a bit unless the arch is made explicit.
> 
> > the alternative is to remove all the platform dependent cross
> > references.
> 
> That seems like a bad idea.
> 
> > i don;t really have a problem with its current format. we do have other
> > pages that reference (by neccesity) platform dependent pages, though
> > they themselves are usually platform dependent.
> 
> Sure, that mitigates the issue.
> 
> Yours,
>   Ingo

Re: Documentation on rc.conf.local lacks important warning

[patrick keshishian]

On 2/12/14, Giancarlo Razzolini  wrote:
> Em 12-02-2014 07:48, Ingo Schwarze escreveu:
>> Hi,
>>
>> Giancarlo Razzolini wrote on Mon, Feb 10, 2014 at 03:18:39PM -0200:
>>
>>> The main issue here is, that, the human brain, although being this
>>> wonderful machine, makes a lot of assumptions to fill in the gaps, even
>>> when there are *no *gaps to be filled. I don't know if the documentation
>>> needs to be clearer in this specific case.
>> Even though the misunderstanding does not seem to occur often,
>> it does seem somewhat unsurprising because a lot of other software
>> encourages the (imho questionable) practice of copying example
>> configuration files.
>>
>> So here is what i came up with to make this clearer without
>> making it longer or more redundant.
>>
>> OK?
>>   Ingo
>>
>>
>> Index: rc.conf.8
>> ===
>> RCS file: /cvs/src/share/man/man8/rc.conf.8,v
>> retrieving revision 1.20
>> diff -u -r1.20 rc.conf.8
>> --- rc.conf.817 Mar 2012 14:46:40 -  1.20
>> +++ rc.conf.812 Feb 2014 09:40:09 -
>> @@ -49,9 +49,9 @@
>>  .Nm rc.conf
>>  untouched, and instead create and edit a new
>>  .Nm rc.conf.local
>> -file.
>> -Variables set in this file will override variables previously set in
>> -.Nm rc.conf .
>> +file, setting just those variables whose
>> +.Nm rc.conf
>> +default values are intended to be overridden.
>>  .Pp
>>  Some variables are used to turn features on or off.
>>  For example, whether the system runs the
> HI Ingo,
>
> I've sent a patch on tech@, and there was a discussion about it, but
> there wasn't a consensus. I encourage you to join tech and the
> discussion. Send your proposal there too.

maybe some people should lurk more.

--patrick

Re: Documentation on rc.conf.local lacks important warning

[Ingo Schwarze]

Hi Jason,

Jason McIntyre wrote on Mon, Feb 10, 2014 at 08:29:24AM +:
> On Sun, Feb 09, 2014 at 03:19:36PM -0800, Philip Guenther wrote:
>> On Sun, Feb 9, 2014 at 3:02 PM, d...@genunix.com  wrote:

>>> Question .. where do I get all the man pages?  I have some of them
>>> but then others are absent :
>>>
>>> # man reboot
>>> REBOOT(8)  OpenBSD System Manager's Manual REBOOT(8)
>>> [...]
>>> SEE ALSO
>>>reboot(2), utmp(5), boot_alpha(8), boot_amd64(8), boot_hp300(8),
>>>boot_hppa(8), boot_hppa64(8), boot_i386(8), boot_luna88k(8),
>>>boot_macppc(8), boot_mvme68k(8), boot_mvme88k(8), boot_sparc(8),
>>>boot_sparc64(8), boot_vax(8), boot_zaurus(8), rc.d(8), rc.shutdown(8),
>>>savecore(8), shutdown(8), sync(8)

>> Hmm, that may be incorrect notation for the pages which are
>> architecture specific: the boot_*(8) manpages are in the architecture
>> specific sections.  They can be seen on all platforms using the -S
>> option to man, ala:
>> 
>> man -S i386 boot_i386
>> man -S sparc boot_sparc
>> ...etc
>> 
>> By default, man uses the architecture that you're running, so if
>> you're running on i386, you should be able to just say
>> man boot_i386
>> 
>> I'm not 100% sure if the cross-references in the SEE ALSO section
>> should be indicating that; I could have sworn that I saw syntax like
>> "whatever(8/i386)" elsewhere.  Jason, Ingo, what the Right Thing here?

> we use 8/i386 notation in man -k (apropos) output, not in man pages,
> though you can use 8/i386 instead of just 8, and mandoc won;t complain.
> i suspect ingo will tell us it'll break other tools.

Actually, both mandoc and groff would be happy with stuff like

  .Xr boot_alpha 8/alpha

and off the top of my head, i don't see which tools might break.
Certainly not our Perl makewhatis(8), it doesn't parse that deeply.
And mandocdb(8) does the right thing out of the box, using it,
you can even search for pages containing arch-specific .Xrs:

   $ ./obj/apropos Xr=/alpha
  halt(8), reboot(8) - stopping and restarting the system
   $ ./obj/apropos -O Xr Xr=/alpha
  halt(8), reboot(8) - [...] # rc.conf(8) # boot_alpha(8/alpha) # [...]

Given that neither groff_mdoc(7) nor mdoc(7) mention this possibility,
i'm not 100% sure all exotic tools will cope, but i don't consider
problems very likely.  Most tools are quite lenient when parsing
macro arguments, roff and groff traditionally do almost no validation,
and most other tools refrain from parsing random content macros,
anyway.

So if you see value in making this explicit, i'd suggest asking on
the groff list whether anybody else expects problems, and if not,
documenting and using it.

> in this case it seems clear the intent is to list all the boot_ pages and
> assume the reader will understand. it's a fair assumption.

For boot_alpha(8), it's nearly obvious; but stuff like inb(2) may
confuse readers quite a bit unless the arch is made explicit.

> the alternative is to remove all the platform dependent cross
> references.

That seems like a bad idea.

> i don;t really have a problem with its current format. we do have other
> pages that reference (by neccesity) platform dependent pages, though
> they themselves are usually platform dependent.

Sure, that mitigates the issue.

Yours,
  Ingo

Re: Documentation on rc.conf.local lacks important warning

[Giancarlo Razzolini]

Em 12-02-2014 07:48, Ingo Schwarze escreveu:
> Hi,
>
> Giancarlo Razzolini wrote on Mon, Feb 10, 2014 at 03:18:39PM -0200:
>
>> The main issue here is, that, the human brain, although being this
>> wonderful machine, makes a lot of assumptions to fill in the gaps, even
>> when there are *no *gaps to be filled. I don't know if the documentation
>> needs to be clearer in this specific case.
> Even though the misunderstanding does not seem to occur often,
> it does seem somewhat unsurprising because a lot of other software
> encourages the (imho questionable) practice of copying example
> configuration files.
>
> So here is what i came up with to make this clearer without
> making it longer or more redundant.
>
> OK?
>   Ingo
>
>
> Index: rc.conf.8
> ===
> RCS file: /cvs/src/share/man/man8/rc.conf.8,v
> retrieving revision 1.20
> diff -u -r1.20 rc.conf.8
> --- rc.conf.8 17 Mar 2012 14:46:40 -  1.20
> +++ rc.conf.8 12 Feb 2014 09:40:09 -
> @@ -49,9 +49,9 @@
>  .Nm rc.conf
>  untouched, and instead create and edit a new
>  .Nm rc.conf.local
> -file.
> -Variables set in this file will override variables previously set in
> -.Nm rc.conf .
> +file, setting just those variables whose
> +.Nm rc.conf
> +default values are intended to be overridden.
>  .Pp
>  Some variables are used to turn features on or off.
>  For example, whether the system runs the
HI Ingo,

I've sent a patch on tech@, and there was a discussion about it, but
there wasn't a consensus. I encourage you to join tech and the
discussion. Send your proposal there too.

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: Documentation on rc.conf.local lacks important warning

[Ingo Schwarze]

Hi,

Giancarlo Razzolini wrote on Mon, Feb 10, 2014 at 03:18:39PM -0200:

> The main issue here is, that, the human brain, although being this
> wonderful machine, makes a lot of assumptions to fill in the gaps, even
> when there are *no *gaps to be filled. I don't know if the documentation
> needs to be clearer in this specific case.

Even though the misunderstanding does not seem to occur often,
it does seem somewhat unsurprising because a lot of other software
encourages the (imho questionable) practice of copying example
configuration files.

So here is what i came up with to make this clearer without
making it longer or more redundant.

OK?
  Ingo


Index: rc.conf.8
===
RCS file: /cvs/src/share/man/man8/rc.conf.8,v
retrieving revision 1.20
diff -u -r1.20 rc.conf.8
--- rc.conf.8   17 Mar 2012 14:46:40 -  1.20
+++ rc.conf.8   12 Feb 2014 09:40:09 -
@@ -49,9 +49,9 @@
 .Nm rc.conf
 untouched, and instead create and edit a new
 .Nm rc.conf.local
-file.
-Variables set in this file will override variables previously set in
-.Nm rc.conf .
+file, setting just those variables whose
+.Nm rc.conf
+default values are intended to be overridden.
 .Pp
 Some variables are used to turn features on or off.
 For example, whether the system runs the

Re: Documentation on rc.conf.local lacks important warning

[Giancarlo Razzolini]

Em 10-02-2014 00:53, Nick Holland escreveu:
> On 02/09/14 14:31, VaZub wrote:
>> Sorry, my bad - I assumed that it was only natural for newcomers to
>> copy the file and edit it afterwards instead of creating it from
>> scratch to override some values.
> If you can figure out how to help me write documentation to override
> people's assumptions, please let me know.  I feel a Get Rich Quick
> coming on if you can...
>
>> Obviously, this assumption was based
>> on my ignorance and therefore wrong. You are also right to point out
>> that to "copy the lines" is not the same as "copy the whole file" - I
>> must have missed this particular distinction.
>>
>> The only thing I can put in my defense is that I might have been
>> mislead to some extent by a particular piece of text -
>> http://www.openbsd.org/faq/upgrade47.html#rc.conf. Of course, it is
>> outdated and should not be taken for granted in regards to version
>> 5.4, but it was one of few leads I've found when trying to fix my
>> problem with rc.conf.local file.
> And if you noticed the CONTEXT (you have in the past edited the wrong
> file) and the warning part in italics (delete the line that re-invokes
> this same file -- there twice, in slightly different wording!), it would
> have been quite useful today, too.
>
>> Nevertheless, please forgive me for my foolish assumptions and for
>> taking your time. And thanks for clearing things up.
> There's an art to getting people to read what is on the page and not
> what is in their mind.  I may be better than some at this, but
> obviously, I have a long way to go. :)
>
> Nick.
>
The main issue here is, that, the human brain, although being this
wonderful machine, makes a lot of assumptions to fill in the gaps, even
when there are *no *gaps to be filled. I don't know if the documentation
needs to be clearer in this specific case. Perhaps we could use the same
text from the faq, since it is a little more explicit on what you need
to do. I'll write a patch and send it to tech@.

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: Documentation on rc.conf.local lacks important warning

[Jason McIntyre]

On Sun, Feb 09, 2014 at 03:19:36PM -0800, Philip Guenther wrote:
> On Sun, Feb 9, 2014 at 3:02 PM, d...@genunix.com  wrote:
> > Question .. where do I get all the man pages?  I have some of them
> > but then others are absent :
> >
> >
> > # man reboot
> > REBOOT(8)   OpenBSD System Manager's Manual  
> > REBOOT(8)
> ...
> > SEE ALSO
> >  reboot(2), utmp(5), boot_alpha(8), boot_amd64(8), boot_hp300(8),
> >  boot_hppa(8), boot_hppa64(8), boot_i386(8), boot_luna88k(8),
> >  boot_macppc(8), boot_mvme68k(8), boot_mvme88k(8), boot_sparc(8),
> >  boot_sparc64(8), boot_vax(8), boot_zaurus(8), rc.d(8), rc.shutdown(8),
> >  savecore(8), shutdown(8), sync(8)
> 
> Hmm, that may be incorrect notation for the pages which are
> architecture specific: the boot_*(8) manpages are in the architecture
> specific sections.  They can be seen on all platforms using the -S
> option to man, ala:
> 
> man -S i386 boot_i386
> man -S sparc boot_sparc
> ...etc
> 
> By default, man uses the architecture that you're running, so if
> you're running on i386, you should be able to just say
> man boot_i386
> 
> I'm not 100% sure if the cross-references in the SEE ALSO section
> should be indicating that; I could have sworn that I saw syntax like
> "whatever(8/i386)" elsewhere.  Jason, Ingo, what the Right Thing here?
> 

we use 8/i386 notation in man -k (apropos) output, not in man pages,
though you can use 8/i386 instead of just 8, and mandoc won;t complain.
i suspect ingo will tell us it'll break other tools.

in this case it seems clear the intent is to list all the boot_ pages and
assume the reader will understand. it's a fair assumption.

the alternative is to remove all the platform dependent cross
references.

i don;t really have a problem with its current format. we do have other
pages that reference (by neccesity) platform dependent pages, though
they themselves are usually platform dependent.

jmc

Re: Documentation on rc.conf.local lacks important warning

[Nick Holland]

On 02/09/14 14:31, VaZub wrote:
> Sorry, my bad - I assumed that it was only natural for newcomers to
> copy the file and edit it afterwards instead of creating it from
> scratch to override some values.

If you can figure out how to help me write documentation to override
people's assumptions, please let me know.  I feel a Get Rich Quick
coming on if you can...

> Obviously, this assumption was based
> on my ignorance and therefore wrong. You are also right to point out
> that to "copy the lines" is not the same as "copy the whole file" - I
> must have missed this particular distinction.
> 
> The only thing I can put in my defense is that I might have been
> mislead to some extent by a particular piece of text -
> http://www.openbsd.org/faq/upgrade47.html#rc.conf. Of course, it is
> outdated and should not be taken for granted in regards to version
> 5.4, but it was one of few leads I've found when trying to fix my
> problem with rc.conf.local file.

And if you noticed the CONTEXT (you have in the past edited the wrong
file) and the warning part in italics (delete the line that re-invokes
this same file -- there twice, in slightly different wording!), it would
have been quite useful today, too.

> Nevertheless, please forgive me for my foolish assumptions and for
> taking your time. And thanks for clearing things up.

There's an art to getting people to read what is on the page and not
what is in their mind.  I may be better than some at this, but
obviously, I have a long way to go. :)

Nick.

Re: Documentation on rc.conf.local lacks important warning

[d...@genunix.com]

> Hmm, you never actually came out and said it (no dmesg, ahem), but I'm
> guessing that you're running on sparc64?


Coming from the Solaris world I am clearly operating on a pile of
wrong assumptions. Imagine my surprise where I saw that things like
psrinfo and such are absent.  OKay, not really surprised. However
the MBR data has me perplexed and the data kicked out by "fdisk sd0"
is just insane.

This is the wrong thread for that topic however.

dc

Re: Documentation on rc.conf.local lacks important warning

[Philip Guenther]

On Sun, Feb 9, 2014 at 3:02 PM, d...@genunix.com  wrote:
> Question .. where do I get all the man pages?  I have some of them
> but then others are absent :
>
>
> # man reboot
> REBOOT(8)   OpenBSD System Manager's Manual  REBOOT(8)
...
> SEE ALSO
>  reboot(2), utmp(5), boot_alpha(8), boot_amd64(8), boot_hp300(8),
>  boot_hppa(8), boot_hppa64(8), boot_i386(8), boot_luna88k(8),
>  boot_macppc(8), boot_mvme68k(8), boot_mvme88k(8), boot_sparc(8),
>  boot_sparc64(8), boot_vax(8), boot_zaurus(8), rc.d(8), rc.shutdown(8),
>  savecore(8), shutdown(8), sync(8)

Hmm, that may be incorrect notation for the pages which are
architecture specific: the boot_*(8) manpages are in the architecture
specific sections.  They can be seen on all platforms using the -S
option to man, ala:

man -S i386 boot_i386
man -S sparc boot_sparc
...etc

By default, man uses the architecture that you're running, so if
you're running on i386, you should be able to just say
man boot_i386

I'm not 100% sure if the cross-references in the SEE ALSO section
should be indicating that; I could have sworn that I saw syntax like
"whatever(8/i386)" elsewhere.  Jason, Ingo, what the Right Thing here?


> # man boot_amd64
> man: no entry for boot_amd64 in the manual.
> # man boot_i386
> man: no entry for boot_i386 in the manual.
> # man boot_sparc
> man: no entry for boot_sparc in the manual.
> #

Hmm, you never actually came out and said it (no dmesg, ahem), but I'm
guessing that you're running on sparc64?


Philip Guenther

Re: Documentation on rc.conf.local lacks important warning

[Ted Unangst]

On Sun, Feb 09, 2014 at 18:02, d...@genunix.com wrote:
> # man boot_amd64
> man: no entry for boot_amd64 in the manual.
> # man boot_i386
> man: no entry for boot_i386 in the manual.
> # man boot_sparc
> man: no entry for boot_sparc in the manual.

man -S sparc boot_sparc

Re: Documentation on rc.conf.local lacks important warning

[d...@genunix.com]

>
> You made a mistake, it got explained to you, you acknowledged it, all
> fine. I would only add this: one of the things that is particularly
> outstanding about OpenBSD is the documentation.

Question .. where do I get all the man pages?  I have some of them
but then others are absent :


# man reboot
REBOOT(8)   OpenBSD System Manager's Manual  REBOOT(8)

NAME
 reboot, halt - stopping and restarting the system

SYNOPSIS
 halt [-dnpq]
 reboot [-dnq]

DESCRIPTION
 The halt and reboot utilities flush the file system cache to disk,
 execute the rc.d(8) scripts specified by the pkg_scripts variable defined
 in rc.conf(8) in a reverse order, run the system shutdown script, send
 all running processes a SIGTERM (and subsequently a SIGKILL), and,
 respectively, halt or restart the system.  The action is logged,
 including entering a shutdown record into the login accounting file.

 The options are as follows:

 -d  Causes system to create a dump before rebooting.  This option is
 useful for debugging system dump procedures or capturing the
 state of a corrupted or misbehaving system.  See savecore(8) for
 information on how to recover this dump.

 -n  Prevent file system cache from being flushed.  This option should
 probably not be used.

 -p  Causes the system to power down, if it is being halted, and the
 hardware supports automatic power down.

 See also the description of powerdown, below.

 -q  Quick.  The system is halted or restarted quickly and
 ungracefully, and only the flushing of the file system cache is
 performed.  This option should probably not be used.

 Normally, the shutdown(8) utility is used when the system needs to be
 halted or restarted, giving users advance warning of their impending
 doom.

FILES
 /etc/rc.shutdown  Script which is run at shutdown time.  If it sets the
   variable powerdown to ``YES'', halt will attempt to
   power down the machine after it has halted.

SEE ALSO
 reboot(2), utmp(5), boot_alpha(8), boot_amd64(8), boot_hp300(8),
 boot_hppa(8), boot_hppa64(8), boot_i386(8), boot_luna88k(8),
 boot_macppc(8), boot_mvme68k(8), boot_mvme88k(8), boot_sparc(8),
 boot_sparc64(8), boot_vax(8), boot_zaurus(8), rc.d(8), rc.shutdown(8),
 savecore(8), shutdown(8), sync(8)

HISTORY
 A reboot command appeared in Version 6 AT&T UNIX.

OpenBSD 5.4  June 20, 2012 OpenBSD 5.4
#

# man boot_amd64
man: no entry for boot_amd64 in the manual.
# man boot_i386
man: no entry for boot_i386 in the manual.
# man boot_sparc
man: no entry for boot_sparc in the manual.
#

dc

Re: Documentation on rc.conf.local lacks important warning

[Donald Allen]

On Sun, Feb 9, 2014 at 2:32 PM, VaZub  wrote:
> Sorry, my bad - I assumed that it was only natural for newcomers to
> copy the file and edit it afterwards instead of creating it from
> scratch to override some values. Obviously, this assumption was based
> on my ignorance and therefore wrong. You are also right to point out
> that to "copy the lines" is not the same as "copy the whole file" - I
> must have missed this particular distinction.
>
> The only thing I can put in my defense is that I might have been
> mislead to some extent by a particular piece of text -
> http://www.openbsd.org/faq/upgrade47.html#rc.conf. Of course, it is
> outdated and should not be taken for granted in regards to version
> 5.4, but it was one of few leads I've found when trying to fix my
> problem with rc.conf.local file.
> Nevertheless, please forgive me for my foolish assumptions and for
> taking your time. And thanks for clearing things up.

You made a mistake, it got explained to you, you acknowledged it, all
fine. I would only add this: one of the things that is particularly
outstanding about OpenBSD is the documentation. You may have been
trained (badly) by documentation for other operating environments that
is either inaccurate or incomplete, and so did not read carefully.
OpenBSD is different in this respect -- the people who develop it take
unusual care in making sure it is well-documented, so the
documentation is worth reading and reading carefully.

/Don Allen

>
> V.
>
>
>
> On Sun, Feb 9, 2014 at 9:14 PM, Peter N. M. Hansteen  wrote:
>> VaZub  writes:
>>
>>> Both the man page for rc.conf(8) as well as the official OpenBSD FAQ
>>> (10.3) suggest to avoid editing /etc/rc.conf directly and instead copy
>>> it to /etc/rc.conf.local and edit afterwards.
>>
>> rc.conf(8) says
>>
>>
>>  It is advisable to leave rc.conf untouched, and instead create and edit 
>> a
>>  new rc.conf.local file.  Variables set in this file will override
>>  variables previously set in rc.conf.
>>
>> I suppose it's possible to interpret that as an instruction to copy
>> /etc/rc.conf, but I think this is the first time I've heard anybody
>> admit to doing that.
>>
>> Leaving rc.conf alone is good advice, it's a "treat as binary"
>> file. When its content changes some variable the startup scripts
>> depend on has been added or changed, it's for a good reason that you
>> will find documented in the man pages, release notes and the FAQ.
>>
>> It never occured to me to create rc.conf.local by copying the entire
>> rc.conf, mainly because it makes perfect sense that a file with
>> override values only needs to contain your local customizations,
>> anything else is noise that is likely to be a source of trouble
>> later. This may or may not have been due to actually reading rc.conf
>> and finding the line sourcing rc.conf.local at some point, but anyway
>> it's been a while since my first contact with any of this.  Once you
>> have actually read rc.conf (if not earlier) it should be fairly
>> obvious that rc.conf.local only needs to contain the variables you
>> actually need to change from the default values.
>>
>>> Yet it seems both fail to mention, that in order to prevent your
>>> system from going ballistic after doing this, you should also
>>> comment out or delete a particular line of code in
>>> /etc/rc.conf.local, namely this one: "[ -f /etc/rc.conf.local ] &&
>>> . /etc/rc.conf.local". Not good, especially for those who do follow
>>> official instructions and still suddenly find themselves with a
>>> broken system on their hands for no apparent reason.
>>
>> You did not in fact read the FAQ too carefully, did you?
>> http://www.openbsd.org/faq/faq10.html says
>>
>>   "We strongly suggest you do not alter /etc/rc.conf itself. Instead,
>>create or edit the file /etc/rc.conf.local, copy just the lines you
>>need to change from /etc/rc.conf and adjust them as you like. This
>>makes future upgrades easier -- all the changes are in the one file
>>that isn't touched during upgrade."
>>
>> "copy just the lines you need" -- how can this be made any clearer?
>>
>> - Peter
>>
>> --
>> Peter N. M. Hansteen, member of the first RFC 1149 implementation team
>> http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
>> "Remember to set the evil bit on all malicious network traffic"
>> delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: Documentation on rc.conf.local lacks important warning

[VaZub]

Sorry, my bad - I assumed that it was only natural for newcomers to
copy the file and edit it afterwards instead of creating it from
scratch to override some values. Obviously, this assumption was based
on my ignorance and therefore wrong. You are also right to point out
that to "copy the lines" is not the same as "copy the whole file" - I
must have missed this particular distinction.

The only thing I can put in my defense is that I might have been
mislead to some extent by a particular piece of text -
http://www.openbsd.org/faq/upgrade47.html#rc.conf. Of course, it is
outdated and should not be taken for granted in regards to version
5.4, but it was one of few leads I've found when trying to fix my
problem with rc.conf.local file.
Nevertheless, please forgive me for my foolish assumptions and for
taking your time. And thanks for clearing things up.

V.



On Sun, Feb 9, 2014 at 9:14 PM, Peter N. M. Hansteen  wrote:
> VaZub  writes:
>
>> Both the man page for rc.conf(8) as well as the official OpenBSD FAQ
>> (10.3) suggest to avoid editing /etc/rc.conf directly and instead copy
>> it to /etc/rc.conf.local and edit afterwards.
>
> rc.conf(8) says
>
>
>  It is advisable to leave rc.conf untouched, and instead create and edit a
>  new rc.conf.local file.  Variables set in this file will override
>  variables previously set in rc.conf.
>
> I suppose it's possible to interpret that as an instruction to copy
> /etc/rc.conf, but I think this is the first time I've heard anybody
> admit to doing that.
>
> Leaving rc.conf alone is good advice, it's a "treat as binary"
> file. When its content changes some variable the startup scripts
> depend on has been added or changed, it's for a good reason that you
> will find documented in the man pages, release notes and the FAQ.
>
> It never occured to me to create rc.conf.local by copying the entire
> rc.conf, mainly because it makes perfect sense that a file with
> override values only needs to contain your local customizations,
> anything else is noise that is likely to be a source of trouble
> later. This may or may not have been due to actually reading rc.conf
> and finding the line sourcing rc.conf.local at some point, but anyway
> it's been a while since my first contact with any of this.  Once you
> have actually read rc.conf (if not earlier) it should be fairly
> obvious that rc.conf.local only needs to contain the variables you
> actually need to change from the default values.
>
>> Yet it seems both fail to mention, that in order to prevent your
>> system from going ballistic after doing this, you should also
>> comment out or delete a particular line of code in
>> /etc/rc.conf.local, namely this one: "[ -f /etc/rc.conf.local ] &&
>> . /etc/rc.conf.local". Not good, especially for those who do follow
>> official instructions and still suddenly find themselves with a
>> broken system on their hands for no apparent reason.
>
> You did not in fact read the FAQ too carefully, did you?
> http://www.openbsd.org/faq/faq10.html says
>
>   "We strongly suggest you do not alter /etc/rc.conf itself. Instead,
>create or edit the file /etc/rc.conf.local, copy just the lines you
>need to change from /etc/rc.conf and adjust them as you like. This
>makes future upgrades easier -- all the changes are in the one file
>that isn't touched during upgrade."
>
> "copy just the lines you need" -- how can this be made any clearer?
>
> - Peter
>
> --
> Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> "Remember to set the evil bit on all malicious network traffic"
> delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: Documentation on rc.conf.local lacks important warning

[Peter N. M. Hansteen]

VaZub  writes:

> Both the man page for rc.conf(8) as well as the official OpenBSD FAQ
> (10.3) suggest to avoid editing /etc/rc.conf directly and instead copy
> it to /etc/rc.conf.local and edit afterwards. 

rc.conf(8) says


 It is advisable to leave rc.conf untouched, and instead create and edit a
 new rc.conf.local file.  Variables set in this file will override
 variables previously set in rc.conf.

I suppose it's possible to interpret that as an instruction to copy
/etc/rc.conf, but I think this is the first time I've heard anybody
admit to doing that.  

Leaving rc.conf alone is good advice, it's a "treat as binary"
file. When its content changes some variable the startup scripts
depend on has been added or changed, it's for a good reason that you
will find documented in the man pages, release notes and the FAQ.

It never occured to me to create rc.conf.local by copying the entire
rc.conf, mainly because it makes perfect sense that a file with
override values only needs to contain your local customizations,
anything else is noise that is likely to be a source of trouble
later. This may or may not have been due to actually reading rc.conf
and finding the line sourcing rc.conf.local at some point, but anyway
it's been a while since my first contact with any of this.  Once you
have actually read rc.conf (if not earlier) it should be fairly
obvious that rc.conf.local only needs to contain the variables you
actually need to change from the default values.

> Yet it seems both fail to mention, that in order to prevent your
> system from going ballistic after doing this, you should also
> comment out or delete a particular line of code in
> /etc/rc.conf.local, namely this one: "[ -f /etc/rc.conf.local ] &&
> . /etc/rc.conf.local". Not good, especially for those who do follow
> official instructions and still suddenly find themselves with a
> broken system on their hands for no apparent reason.

You did not in fact read the FAQ too carefully, did you?
http://www.openbsd.org/faq/faq10.html says

  "We strongly suggest you do not alter /etc/rc.conf itself. Instead,
   create or edit the file /etc/rc.conf.local, copy just the lines you
   need to change from /etc/rc.conf and adjust them as you like. This
   makes future upgrades easier -- all the changes are in the one file
   that isn't touched during upgrade."

"copy just the lines you need" -- how can this be made any clearer?

- Peter

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: Documentation on rc.conf.local lacks important warning

[Kirill Bychkov]

On Sun, February 9, 2014 22:28, VaZub wrote:
> Hi all,
>
> There is a small nuisance I've stumbled upon during my first
> experiments with OpenBSD.
>
> Both the man page for rc.conf(8) as well as the official OpenBSD FAQ
> (10.3) suggest to avoid editing /etc/rc.conf directly and instead copy
> it to /etc/rc.conf.local and edit afterwards. Yet it seems both fail

Hi. In FAQ it's suggested to copy needed strings, not the file itself:
"We strongly suggest you do not alter /etc/rc.conf itself. Instead, create or
edit the file /etc/rc.conf.local, copy just the lines you need to change from
/etc/rc.conf and adjust them as you like. "

> to mention, that in order to prevent your system from going ballistic
> after doing this, you should also comment out or delete a particular
> line of code in /etc/rc.conf.local, namely this one:
> "[ -f /etc/rc.conf.local ] && . /etc/rc.conf.local". Not good,
> especially for those who do follow official instructions and still
> suddenly find themselves with a broken system on their hands for no
> apparent reason.
>
> This might seem like a trivial issue for old-timers, and one is sure
> to find the appropriate solution with a little bit of deeper googling,
> but having short relevant notices in the aforementioned manuals could
> save newcomers some introductory frustration. What do you think? Is
> there anyone among those looking after the official documentation up
> to consider such a suggestion?
>
> Regards,
> Vasyl Zubko

Re: Documentation on rc.conf.local lacks important warning

[Barry Grumbine]

The FAQ says the same:
"We strongly suggest you do not alter /etc/rc.conf itself. Instead,
create or edit the file /etc/rc.conf.local, copy just the lines you
need to change from /etc/rc.conf and adjust them as you like."

rc.conf is gives a good hint as well:
# To select the service options you desire, please override these
# options in the file /etc/rc.conf.local

To "override" options in rc.conf, I often do something like:
# grep tftp /etc/rc.conf >> /etc/rc.conf.local

Which gives me something nice to work with:
tftpd_flags=NO  # for normal use: "[chroot dir]"
tftpproxy_flags=NO  # for normal use: ""


-Barry

On Sun, Feb 9, 2014 at 11:44 AM, Kenneth Westerback
 wrote:
> rc.conf(8) says "create and edit a rc.conf.local". Not copy rc.conf.
> I'm not sure what the FAQ says but I'd think it would be similar
> advice.
>
>  Ken
>
> On 9 February 2014 13:28, VaZub  wrote:
>> Hi all,
>>
>> There is a small nuisance I've stumbled upon during my first
>> experiments with OpenBSD.
>>
>> Both the man page for rc.conf(8) as well as the official OpenBSD FAQ
>> (10.3) suggest to avoid editing /etc/rc.conf directly and instead copy
>> it to /etc/rc.conf.local and edit afterwards. Yet it seems both fail
>> to mention, that in order to prevent your system from going ballistic
>> after doing this, you should also comment out or delete a particular
>> line of code in /etc/rc.conf.local, namely this one:
>> "[ -f /etc/rc.conf.local ] && . /etc/rc.conf.local". Not good,
>> especially for those who do follow official instructions and still
>> suddenly find themselves with a broken system on their hands for no
>> apparent reason.
>>
>> This might seem like a trivial issue for old-timers, and one is sure
>> to find the appropriate solution with a little bit of deeper googling,
>> but having short relevant notices in the aforementioned manuals could
>> save newcomers some introductory frustration. What do you think? Is
>> there anyone among those looking after the official documentation up
>> to consider such a suggestion?
>>
>> Regards,
>> Vasyl Zubko

Re: Documentation on rc.conf.local lacks important warning

[Rogier Krieger]

Though I looked on a 5.3 system, rc.conf(8) suggests the following:
"It is advisable to leave rc.conf untouched, and instead create and edit a
new rc.conf.local file."

That's rather different from creating a copy. From a brief look at CVS,
it's the same for -current.

Regards,

Rogier


On Sun, Feb 9, 2014 at 7:28 PM, VaZub  wrote:

> Hi all,
>
> There is a small nuisance I've stumbled upon during my first
> experiments with OpenBSD.
>
> Both the man page for rc.conf(8) as well as the official OpenBSD FAQ
> (10.3) suggest to avoid editing /etc/rc.conf directly and instead copy
> it to /etc/rc.conf.local and edit afterwards. Yet it seems both fail
> to mention, that in order to prevent your system from going ballistic
> after doing this, you should also comment out or delete a particular
> line of code in /etc/rc.conf.local, namely this one:
> "[ -f /etc/rc.conf.local ] && . /etc/rc.conf.local". Not good,
> especially for those who do follow official instructions and still
> suddenly find themselves with a broken system on their hands for no
> apparent reason.
>
> This might seem like a trivial issue for old-timers, and one is sure
> to find the appropriate solution with a little bit of deeper googling,
> but having short relevant notices in the aforementioned manuals could
> save newcomers some introductory frustration. What do you think? Is
> there anyone among those looking after the official documentation up
> to consider such a suggestion?
>
> Regards,
> Vasyl Zubko
>
>


-- 
If you don't know where you're going, any road will get you there.

Re: Documentation on rc.conf.local lacks important warning

[Bret Lambert]

On Sun, Feb 09, 2014 at 08:28:43PM +0200, VaZub wrote:
> Hi all,
> 
> There is a small nuisance I've stumbled upon during my first
> experiments with OpenBSD.
> 
> Both the man page for rc.conf(8) as well as the official OpenBSD FAQ
> (10.3) suggest to avoid editing /etc/rc.conf directly and instead copy
> it to /etc/rc.conf.local and edit afterwards. Yet it seems both fail
> to mention, that in order to prevent your system from going ballistic
> after doing this, you should also comment out or delete a particular
> line of code in /etc/rc.conf.local, namely this one:
> "[ -f /etc/rc.conf.local ] && . /etc/rc.conf.local". Not good,
> especially for those who do follow official instructions and still
> suddenly find themselves with a broken system on their hands for no
> apparent reason.
> 
> This might seem like a trivial issue for old-timers, and one is sure
> to find the appropriate solution with a little bit of deeper googling,
> but having short relevant notices in the aforementioned manuals could
> save newcomers some introductory frustration. What do you think? Is
> there anyone among those looking after the official documentation up
> to consider such a suggestion?

You've probably confused rc.conf.local for rc.local, but it's impossible
to tell, given that you've delivered a polemic, and not a description
of what you tried to do, and how it didn't end up as you expected.

> 
> Regards,
> Vasyl Zubko

Re: Documentation on rc.conf.local lacks important warning

[Kenneth Westerback]

rc.conf(8) says "create and edit a rc.conf.local". Not copy rc.conf.
I'm not sure what the FAQ says but I'd think it would be similar
advice.

 Ken

On 9 February 2014 13:28, VaZub  wrote:
> Hi all,
>
> There is a small nuisance I've stumbled upon during my first
> experiments with OpenBSD.
>
> Both the man page for rc.conf(8) as well as the official OpenBSD FAQ
> (10.3) suggest to avoid editing /etc/rc.conf directly and instead copy
> it to /etc/rc.conf.local and edit afterwards. Yet it seems both fail
> to mention, that in order to prevent your system from going ballistic
> after doing this, you should also comment out or delete a particular
> line of code in /etc/rc.conf.local, namely this one:
> "[ -f /etc/rc.conf.local ] && . /etc/rc.conf.local". Not good,
> especially for those who do follow official instructions and still
> suddenly find themselves with a broken system on their hands for no
> apparent reason.
>
> This might seem like a trivial issue for old-timers, and one is sure
> to find the appropriate solution with a little bit of deeper googling,
> but having short relevant notices in the aforementioned manuals could
> save newcomers some introductory frustration. What do you think? Is
> there anyone among those looking after the official documentation up
> to consider such a suggestion?
>
> Regards,
> Vasyl Zubko

Documentation on rc.conf.local lacks important warning

[VaZub]

Hi all,

There is a small nuisance I've stumbled upon during my first
experiments with OpenBSD.

Both the man page for rc.conf(8) as well as the official OpenBSD FAQ
(10.3) suggest to avoid editing /etc/rc.conf directly and instead copy
it to /etc/rc.conf.local and edit afterwards. Yet it seems both fail
to mention, that in order to prevent your system from going ballistic
after doing this, you should also comment out or delete a particular
line of code in /etc/rc.conf.local, namely this one:
"[ -f /etc/rc.conf.local ] && . /etc/rc.conf.local". Not good,
especially for those who do follow official instructions and still
suddenly find themselves with a broken system on their hands for no
apparent reason.

This might seem like a trivial issue for old-timers, and one is sure
to find the appropriate solution with a little bit of deeper googling,
but having short relevant notices in the aforementioned manuals could
save newcomers some introductory frustration. What do you think? Is
there anyone among those looking after the official documentation up
to consider such a suggestion?

Regards,
Vasyl Zubko

Re: Important: following -current update!

[Nick Holland]

On 04/16/13 06:13, Michał Markowski wrote:
> $ cd /usr/src/sys/arch/`uname -m`/config
> cd: no such file or directory: /usr/src/sys/arch/i386/config
> $ cd /usr/src/sys/arch/`uname -m`/conf
> $
> 
> 
> --- /cvs/www/faq/current.html   Tue Apr 16 11:54:22 2013
> +++ /tmp/current.html   Tue Apr 16 12:10:27 2013
> @@ -597,7 +597,7 @@
>  
>  Update entire source tree using cvs
>  configure and build a new kernel:
> -   cd /usr/src/sys/arch/`uname -m`/config
> +   cd /usr/src/sys/arch/`uname -m`/conf
> config GENERIC  # or GENERIC.MP or whatever config you use
> cd ../compile/GENERIC   # or GENERIC.MP or ...
> make clean
> 
> 
> --
> Michał Markowski
> 

yep, fixed, thanks!

Nick.

Re: Important: following -current update!

[Michał Markowski]

$ cd /usr/src/sys/arch/`uname -m`/config
cd: no such file or directory: /usr/src/sys/arch/i386/config
$ cd /usr/src/sys/arch/`uname -m`/conf
$


--- /cvs/www/faq/current.html   Tue Apr 16 11:54:22 2013
+++ /tmp/current.html   Tue Apr 16 12:10:27 2013
@@ -597,7 +597,7 @@
 
 Update entire source tree using cvs
 configure and build a new kernel:
-   cd /usr/src/sys/arch/`uname -m`/config
+   cd /usr/src/sys/arch/`uname -m`/conf
config GENERIC  # or GENERIC.MP or whatever config you use
cd ../compile/GENERIC   # or GENERIC.MP or ...
make clean


--
Michał Markowski

Important: following -current update!

[Philip Guenther]

While it's often the case that you can leave our steps when building
-current from source, it is sometimes ABSOLUTELY REQUIRED that you
followed the steps precisely.

This is one of those times.

If you build a -current kernel without running config(8) and "make
clean", then the resulting kernel WILL NOT RUN YOUR INSTALLED
USERLAND.  If that happens, you will have to boot from the old kernel
(do you know how?) or boot from an alternate device like a CD.

If you are not 100% comfortable with doing that recovery, then you
should wait and install the next snapshot instead.


Philip Guenther

-- Forwarded message --
From: Philip Guenther 
Date: Mon, Apr 15, 2013 at 8:56 PM
Subject: CVS: cvs.openbsd.org: www
To: source-chan...@cvs.openbsd.org
<...>
Modified files:
faq: current.html

Log message:
statfs change requires strict following of the build steps, or you'll
end up with a userland that can't mount (or remount!) critical filesystems

Is this CVS message important? Trying to update -stable sources.

[John Long]

Hello misc@

Trying to update -stable sources I got the following message:

root@host:/usr/src# cvs -q -d$CVSROOT up -Pd
cvs server: use `cvs add' to create an entry for gnu/usr.bin/gcc/INSTALL

Attempting to comply with cvs's wishes:

root@host:/usr/src# cvs add gnu/usr.bin/gcc/INSTALL
cvs [add aborted]: there is a version in gnu/usr.bin/gcc/INSTALL already

but:

root@host:/usr/src# cat gnu/usr.bin/gcc/INSTALL/CVS/Tag 
TOPENBSD_5_2

Does the cvs message saying to use cvs add mean anything to anybody? Does
this need to be fixed anywhere or can I just ignore it? Or did I miss
something on the cvs add that would have fixed this?

/jl

-- 
ASCII ribbon campaign ( ) Powered by Lemote Fuloong
 against HTML e-mail   X  Loongson MIPS and OpenBSD
   and proprietary/ \http://www.mutt.org
 attachments /   \  Code Blue or Go Home!
 Encrypted email preferred  PGP Key 2048R/DA65BC04 

Message: Important SN�GG Merchant Information !

[SN�GG MEDICAL]

We'd like to inform you that your Secure Messages Center has (1) new
message.

Please login to your SNØGG Merchant Services account and visit the Secure
Message Center section in
order to read the message.

Login to your SNØGG MEDICAL Merchant account

(The Message Center contains only important information about your
account .)

SNØGG MEDICAL. Registration No. 03919014 © 1997-2012. All Rights Reserved

Re: hi, hope you are fine, my Name is Paulina, I will want us to be friends, for something important which I would like to share with u, & we will get to know each other better i am waiting for your r

[paulinadiane27]

Re: hi, hope you are fine, my Name is Paulina, I will want us to be
friends, for something important which I would like to share with u, & we
will get to know each other better i am waiting for your responds, (
distance or colour does not matter ) urs Paul thought you would be
interested in the following article:Italian merchants funded England's
discovery of North America

Evidence that a Florentine merchant house financed the earliest English
voyages to North America, has been published on-line in the academic
journal Historical Research.

Click here to read more on e! Science News

Virtual Merchant - Important Account Information

[Virtual Merchant]

VirtualMerchant

We'd like to inform you that your Secure Messages Center has 1 new
message.

Please login to your VirtualMerchant account and visit the Secure Message
Center section in order to
read the message.

Login to your VirtualMerchant account

(The Message Center contains only important information about your
account .)

Copyright ) 2011 Elavon, Inc. All rights reserved.

Re: Are there any virtualization solutions for OpenBSD? (!important: no package from ports!)

[Henning Brauer]

* Hassan Monfared  [2011-09-19 08:17]:
> why don't you try xen ?
> The XenB. hypervisor, the powerful open source industry standard for
> virtualization, offers a powerful, efficient, and secure feature set for
> virtualization of x86, x86_64, IA64, ARM, and other CPU architectures.

can we please keep this marketing crap off the lists?

not even is this irrelevant marketing speech, it is even more
irrelevant since xen doesn't run on openbsd.

-- 
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de, Full-Service ISP
Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed
Henning Brauer Consulting, http://henningbrauer.com/

Re: Are there any virtualization solutions for OpenBSD? (!important: no package from ports!)

[Tomas Bodzar]

On Tue, Sep 20, 2011 at 9:37 AM, Michel Blais  wrote:
> The're also proxmox ve that is really nice for virtualisation.
>
> http://pve.proxmox.com/wiki/Main_Page

As it's based on OpenVZ and KVM it doesn't seems to be answer on
question in subject.

Re: Are there any virtualization solutions for OpenBSD? (!important: no package from ports!)

[Michel Blais]

The're also proxmox ve that is really nice for virtualisation.

http://pve.proxmox.com/wiki/Main_Page

Re: Are there any virtualization solutions for OpenBSD? (!important: no package from ports!)

[Corey]

On 09/19/2011 09:15 PM, Joel Wiramu Pauling wrote:
>
>
> On 20 September 2011 14:08, Corey  > wrote:
>
> On 09/19/2011 08:04 PM, Joel Wiramu Pauling wrote:
>
> If you are Going to use linux as your dom0 I STRONGLY
> recommend against
> virtual box. Vb is the retarded stillborn twin of kvm. Kvm is
> twice as fast
> in mainline and not controlled by oracle
>
> sent from android handset. Please mind the brevity.
> On Sep 20, 2011 12:44 AM, "Nico Kadel-Garcia" >  wrote:
>
> Maybe so, but it works fine for me in a workstation environment.
> Many things work better than in KVM (video, USB passthrough) and I
> don't see any perceptible speed difference. KVM does seem to use
> less CPU, and that usage is better balanced amongst cores, than
> with VirtualBox. I think KVM is closing the gap, and am prepared
> for Oracle to drop VBox entirely if it suits Ellison's whims.
>
> I wouldn't use VirtualBox in a server environment, but then again
> I don't get the feeling that that is its target environment
>
>
> This is off topic now, but seriously, I use both (Virtualbox has one 
> advantage in that it can host Solaris10 properly). And VB has NO 
> advantages, all of the advantages are to KVM. As for Video use Spice 
> enabled KVM, and USB pass through has been present for yonks.
>
>
> C
>
>
Yes, it is, so I'll make this last comment and be gone.

I guess it comes down to what works best *for you*. SPICE looks cool 
(though I will always think of "Spice" software as something I use to 
model electronic circuitry), but I can't justify screwing around with 
setting up a remote desktop infrastructure *on a single workstation* 
when I can load guest drivers on my VBox guests and it "just works" (I'm 
usually virtualizing Windows). And while I'm aware that KVM supposedly 
supports USB passthrough, it just will not work with my document scanner 
software -- and KVM spews a billion messages on the console when I 
enable the passthrough to boot. VBox on the other hand supports the 
scanner and its software flawlessly.

Don't get me wrong, I like KVM. And more power to its devs. My only 
regret with it it is that qemu will probably eventually depend on KVM 
and not run standalone anymore. But KVM is no panacea. For what *I* do, 
VBox works better and easier.

Re: Are there any virtualization solutions for OpenBSD? (!important: no package from ports!)

[Joel Wiramu Pauling]

On 20 September 2011 14:08, Corey  wrote:

> On 09/19/2011 08:04 PM, Joel Wiramu Pauling wrote:
>
>> If you are Going to use linux as your dom0 I STRONGLY recommend against
>> virtual box. Vb is the retarded stillborn twin of kvm. Kvm is twice as
>> fast
>> in mainline and not controlled by oracle
>>
>> sent from android handset. Please mind the brevity.
>> On Sep 20, 2011 12:44 AM, "Nico Kadel-Garcia"  wrote:
>>
>>  Maybe so, but it works fine for me in a workstation environment. Many
> things work better than in KVM (video, USB passthrough) and I don't see any
> perceptible speed difference. KVM does seem to use less CPU, and that usage
> is better balanced amongst cores, than with VirtualBox. I think KVM is
> closing the gap, and am prepared for Oracle to drop VBox entirely if it
> suits Ellison's whims.
>
> I wouldn't use VirtualBox in a server environment, but then again I don't
> get the feeling that that is its target environment


This is off topic now, but seriously, I use both (Virtualbox has one
advantage in that it can host Solaris10 properly). And VB has NO advantages,
all of the advantages are to KVM. As for Video use Spice enabled KVM, and
USB pass through has been present for yonks.

>
> C

Re: Are there any virtualization solutions for OpenBSD? (!important: no package from ports!)

[Corey]

On 09/19/2011 08:04 PM, Joel Wiramu Pauling wrote:

If you are Going to use linux as your dom0 I STRONGLY recommend against
virtual box. Vb is the retarded stillborn twin of kvm. Kvm is twice as fast
in mainline and not controlled by oracle

sent from android handset. Please mind the brevity.
On Sep 20, 2011 12:44 AM, "Nico Kadel-Garcia"  wrote:

Maybe so, but it works fine for me in a workstation environment. Many 
things work better than in KVM (video, USB passthrough) and I don't see 
any perceptible speed difference. KVM does seem to use less CPU, and 
that usage is better balanced amongst cores, than with VirtualBox. I 
think KVM is closing the gap, and am prepared for Oracle to drop VBox 
entirely if it suits Ellison's whims.


I wouldn't use VirtualBox in a server environment, but then again I 
don't get the feeling that that is its target environment.


C

Re: Are there any virtualization solutions for OpenBSD? (!important: no package from ports!)

[L. V. Lammert]

On Tue, 20 Sep 2011, Joel Wiramu Pauling wrote:

> If you are Going to use linux as your dom0 I STRONGLY recommend against
> virtual box. Vb is the retarded stillborn twin of kvm. Kvm is twice as fast
> in mainline and not controlled by oracle
>
For production use, Xen and orchestrate seems to be getting pretty good
reviews, .. the only advantage to VirtualBox is phpVirtualBox.

Lee

Re: Are there any virtualization solutions for OpenBSD? (!important: no package from ports!)

[Joel Wiramu Pauling]

If you are Going to use linux as your dom0 I STRONGLY recommend against
virtual box. Vb is the retarded stillborn twin of kvm. Kvm is twice as fast
in mainline and not controlled by oracle

sent from android handset. Please mind the brevity.
On Sep 20, 2011 12:44 AM, "Nico Kadel-Garcia"  wrote:
> On Sat, Sep 17, 2011 at 6:17 AM, lancebaynes87 
wrote:
>>
http://unix.stackexchange.com/questions/20917/are-there-any-virtualization-solutions-for-openbsd-important-no-package-from
>>
>> I'm searching for Virtualization solutions:
>>
>> OpenBSD: host
>> CentOS: guest
>>
>> What are my solutions? I'm searching for one that doesn't use packages
from ports. Are there any?
>>
>> Thank you in anticipation.
>
> Do it the other way around. RHEL, CentOS, and Scientific Linux 6.x all
> work well with the "VirtualBox" and other virtualization servers,
> though VirtualBox has the best interface for freeware. And OpenBSD
> runs quite happily in virtualization. I use it for testing OpenBSD
> tools in a primarily RHEL environment, and even use VirtualBox for
> easy virtualization in places where I'm only handed a Windows desktop
> or laptop.
>
> You don't get the same vaunted OS security or kernel performance on
> the serverr, but you do get access to other familiar tools and layouts
> that may not be available in OpenBSD yet. (I do note the availability
> of recent tools I care about in 4.9, such as httpd-2.x and
> libreoffice-3.x and subversion-1.6.x. Good)

Re: Are there any virtualization solutions for OpenBSD? (!important: no package from ports!)

[ropers]

Hassan Monfared wrote:
> subject to  correction of a lock-up bug in OpenBSD to support Xen Hosting

On 19 September 2011 09:20, Tomas Bodzar  wrote:
> And eg. this one is not so hard
> http://marc.info/?l=openbsd-misc&w=2&r=1&s=dom0&q=b

Has anyone (qualified) ever taken an interest in the bug Christoph
mentioned here?

Is this the same issue Hassan just referred to?

There've been long stretches where I've not followed things much, not
even as a user, but the last I heard sort of seemed to indicate that
maybe there wasn't much interest -- in part because real hardware is
generally preferred due to (justified) concerns regarding the security
footprint of virtualisation.

But I don't know what the story is now. Does anyone?

regards,
--ropers

Re: Are there any virtualization solutions for OpenBSD? (!important: no package from ports!)

[Nico Kadel-Garcia]

On Sat, Sep 17, 2011 at 6:17 AM, lancebaynes87  wrote:
> http://unix.stackexchange.com/questions/20917/are-there-any-virtualization-solutions-for-openbsd-important-no-package-from
>
> I'm searching for Virtualization solutions:
>
> OpenBSD: host
> CentOS: guest
>
> What are my solutions? I'm searching for one that doesn't use packages from 
> ports. Are there any?
>
> Thank you in anticipation.

Do it the other way around. RHEL, CentOS, and Scientific Linux 6.x all
work well with the "VirtualBox" and other virtualization servers,
though VirtualBox has the best interface for freeware. And OpenBSD
runs quite happily in virtualization. I use it for testing OpenBSD
tools in a primarily RHEL environment, and even use VirtualBox for
easy virtualization in places where I'm only handed a Windows desktop
or laptop.

You don't get the same vaunted OS security or kernel performance on
the serverr, but you do get access to other familiar tools and layouts
that may not be available in OpenBSD yet. (I do note the availability
of recent tools I care about in 4.9, such as httpd-2.x and
libreoffice-3.x and subversion-1.6.x. Good)

Re: Are there any virtualization solutions for OpenBSD? (!important: no package from ports!)

[Tomas Bodzar]

On Mon, Sep 19, 2011 at 9:02 AM, Hassan Monfared  wrote:
> http://en.wikipedia.org/wiki/Comparison_of_platform_virtual_machinesB (
look
> at Host OS column)

For what? Xen doesn't have OpenBSD in that column and OpenBSD doesn't
have Xen in sources as you can check on OpenBSD pages. Qemu, DosBox
and VAX are in place, but eg. Ldoms doesn't have OpenBSD in that
column even as OpenBSD support that so not so much correct table in
the end.

And eg. this one is not so hard
http://marc.info/?l=openbsd-misc&w=2&r=1&s=dom0&q=b

>
> On Mon, Sep 19, 2011 at 11:30 AM, Hassan Monfared 
> wrote:
>>
>> IB haven'tB tried Xen on OpenBSD as host, but Xen is open source and there
>> was subject toB B correction of a lock-up bug in OpenBSD to support Xen
>> Hosting.
>> NetBSD supports Xen Hostig
>>
>> On Mon, Sep 19, 2011 at 11:03 AM, Tomas Bodzar 
>> wrote:
>>>
>>> On Mon, Sep 19, 2011 at 8:12 AM, Hassan Monfared 
>>> wrote:
>>> > why don't you try xen ?
>>>
>>> Maybe because he asked for solution with OpenBSD as a host and nothing
>>> from packages/ports? ;-)
>>>
>>> > The XenB. hypervisor, the powerful open source industry standard for
>>> > virtualization, offers a powerful, efficient, and secure feature set
>>> > for
>>> > virtualization of x86, x86_64, IA64, ARM, and other CPU architectures.
>>> > visit Xen at www.Xen.org
>>> >
>>> > On Sun, Sep 18, 2011 at 2:10 PM, Tomas Bodzar
>>> > wrote:
>>> >
>>> >> On Sat, Sep 17, 2011 at 12:17 PM, lancebaynes87
>>> >> 
>>> >> wrote:
>>> >> >
>>> >>
>>> >
>>> >
http://unix.stackexchange.com/questions/20917/are-there-any-virtualization-so
>>> > lutions-for-openbsd-important-no-package-from
>>> >> >
>>> >> > I'm searching for Virtualization solutions:
>>> >> >
>>> >> > OpenBSD: host
>>> >> > CentOS: guest
>>> >> >
>>> >> > What are my solutions? I'm searching for one that doesn't use
>>> >> > packages
>>> >> from ports. Are there any?
>>> >>
>>> >> Qemu only or switch to real virtualization Ldoms where OpenBSD runs
>>> >> fine as a host/guest. Not sure how well CentOS runs inside Ldoms if at
>>> >> all :-)
>>> >>
>>> >> >
>>> >> > Thank you in anticipation.

Re: Are there any virtualization solutions for OpenBSD? (!important: no package from ports!)

[Tomas Bodzar]

On Mon, Sep 19, 2011 at 9:00 AM, Hassan Monfared  wrote:
> IB haven'tB tried Xen on OpenBSD as host, but Xen is open source and there
was
> subject toB B correction of a lock-up bug in OpenBSD to support Xen
Hosting.
> NetBSD supports Xen Hostig

OpenBSD doesn't mean NetBSD for a very long time

>
> On Mon, Sep 19, 2011 at 11:03 AM, Tomas Bodzar 
> wrote:
>>
>> On Mon, Sep 19, 2011 at 8:12 AM, Hassan Monfared 
>> wrote:
>> > why don't you try xen ?
>>
>> Maybe because he asked for solution with OpenBSD as a host and nothing
>> from packages/ports? ;-)
>>
>> > The XenB. hypervisor, the powerful open source industry standard for
>> > virtualization, offers a powerful, efficient, and secure feature set for
>> > virtualization of x86, x86_64, IA64, ARM, and other CPU architectures.
>> > visit Xen at www.Xen.org
>> >
>> > On Sun, Sep 18, 2011 at 2:10 PM, Tomas Bodzar
>> > wrote:
>> >
>> >> On Sat, Sep 17, 2011 at 12:17 PM, lancebaynes87
>> >> 
>> >> wrote:
>> >> >
>> >>
>> >
>> >
http://unix.stackexchange.com/questions/20917/are-there-any-virtualization-so
>> > lutions-for-openbsd-important-no-package-from
>> >> >
>> >> > I'm searching for Virtualization solutions:
>> >> >
>> >> > OpenBSD: host
>> >> > CentOS: guest
>> >> >
>> >> > What are my solutions? I'm searching for one that doesn't use
>> >> > packages
>> >> from ports. Are there any?
>> >>
>> >> Qemu only or switch to real virtualization Ldoms where OpenBSD runs
>> >> fine as a host/guest. Not sure how well CentOS runs inside Ldoms if at
>> >> all :-)
>> >>
>> >> >
>> >> > Thank you in anticipation.

Re: Are there any virtualization solutions for OpenBSD? (!important: no package from ports!)

[Hassan Monfared]

http://en.wikipedia.org/wiki/Comparison_of_platform_virtual_machines ( look
at Host OS column)

On Mon, Sep 19, 2011 at 11:30 AM, Hassan Monfared wrote:

> I haven't tried Xen on OpenBSD as host, but Xen is open source and there
> was subject to  correction of a lock-up bug in OpenBSD to support Xen
> Hosting.
> NetBSD supports Xen Hostig
>
> On Mon, Sep 19, 2011 at 11:03 AM, Tomas Bodzar wrote:
>
>> On Mon, Sep 19, 2011 at 8:12 AM, Hassan Monfared 
>> wrote:
>> > why don't you try xen ?
>>
>> Maybe because he asked for solution with OpenBSD as a host and nothing
>> from packages/ports? ;-)
>>
>> > The XenB. hypervisor, the powerful open source industry standard for
>> > virtualization, offers a powerful, efficient, and secure feature set for
>> > virtualization of x86, x86_64, IA64, ARM, and other CPU architectures.
>> > visit Xen at www.Xen.org
>> >
>> > On Sun, Sep 18, 2011 at 2:10 PM, Tomas Bodzar > >wrote:
>> >
>> >> On Sat, Sep 17, 2011 at 12:17 PM, lancebaynes87 <
>> lancebayne...@zoho.com>
>> >> wrote:
>> >> >
>> >>
>> >
>> http://unix.stackexchange.com/questions/20917/are-there-any-virtualization-so
>> > lutions-for-openbsd-important-no-package-from
>> >> >
>> >> > I'm searching for Virtualization solutions:
>> >> >
>> >> > OpenBSD: host
>> >> > CentOS: guest
>> >> >
>> >> > What are my solutions? I'm searching for one that doesn't use
>> packages
>> >> from ports. Are there any?
>> >>
>> >> Qemu only or switch to real virtualization Ldoms where OpenBSD runs
>> >> fine as a host/guest. Not sure how well CentOS runs inside Ldoms if at
>> >> all :-)
>> >>
>> >> >
>> >> > Thank you in anticipation.

Re: Are there any virtualization solutions for OpenBSD? (!important: no package from ports!)

[Hassan Monfared]

I haven't tried Xen on OpenBSD as host, but Xen is open source and there was
subject to  correction of a lock-up bug in OpenBSD to support Xen Hosting.
NetBSD supports Xen Hostig

On Mon, Sep 19, 2011 at 11:03 AM, Tomas Bodzar wrote:

> On Mon, Sep 19, 2011 at 8:12 AM, Hassan Monfared 
> wrote:
> > why don't you try xen ?
>
> Maybe because he asked for solution with OpenBSD as a host and nothing
> from packages/ports? ;-)
>
> > The XenB. hypervisor, the powerful open source industry standard for
> > virtualization, offers a powerful, efficient, and secure feature set for
> > virtualization of x86, x86_64, IA64, ARM, and other CPU architectures.
> > visit Xen at www.Xen.org
> >
> > On Sun, Sep 18, 2011 at 2:10 PM, Tomas Bodzar  >wrote:
> >
> >> On Sat, Sep 17, 2011 at 12:17 PM, lancebaynes87  >
> >> wrote:
> >> >
> >>
> >
> http://unix.stackexchange.com/questions/20917/are-there-any-virtualization-so
> > lutions-for-openbsd-important-no-package-from
> >> >
> >> > I'm searching for Virtualization solutions:
> >> >
> >> > OpenBSD: host
> >> > CentOS: guest
> >> >
> >> > What are my solutions? I'm searching for one that doesn't use packages
> >> from ports. Are there any?
> >>
> >> Qemu only or switch to real virtualization Ldoms where OpenBSD runs
> >> fine as a host/guest. Not sure how well CentOS runs inside Ldoms if at
> >> all :-)
> >>
> >> >
> >> > Thank you in anticipation.

Re: Are there any virtualization solutions for OpenBSD? (!important: no package from ports!)

[Hassan Monfared]

why don't you try xen ?
The XenB. hypervisor, the powerful open source industry standard for
virtualization, offers a powerful, efficient, and secure feature set for
virtualization of x86, x86_64, IA64, ARM, and other CPU architectures.
visit Xen at www.Xen.org

On Sun, Sep 18, 2011 at 2:10 PM, Tomas Bodzar wrote:

> On Sat, Sep 17, 2011 at 12:17 PM, lancebaynes87 
> wrote:
> >
>
http://unix.stackexchange.com/questions/20917/are-there-any-virtualization-so
lutions-for-openbsd-important-no-package-from
> >
> > I'm searching for Virtualization solutions:
> >
> > OpenBSD: host
> > CentOS: guest
> >
> > What are my solutions? I'm searching for one that doesn't use packages
> from ports. Are there any?
>
> Qemu only or switch to real virtualization Ldoms where OpenBSD runs
> fine as a host/guest. Not sure how well CentOS runs inside Ldoms if at
> all :-)
>
> >
> > Thank you in anticipation.

Re: Are there any virtualization solutions for OpenBSD? (!important: no package from ports!)

[Tomas Bodzar]

On Sat, Sep 17, 2011 at 12:17 PM, lancebaynes87  wrote:
> http://unix.stackexchange.com/questions/20917/are-there-any-virtualization-solutions-for-openbsd-important-no-package-from
>
> I'm searching for Virtualization solutions:
>
> OpenBSD: host
> CentOS: guest
>
> What are my solutions? I'm searching for one that doesn't use packages from 
> ports. Are there any?

Qemu only or switch to real virtualization Ldoms where OpenBSD runs
fine as a host/guest. Not sure how well CentOS runs inside Ldoms if at
all :-)

>
> Thank you in anticipation.

Re: Are there any virtualization solutions for OpenBSD? (!important: no package from ports!)

[Jeremie Courreges-Anglas]

> What are my solutions? I'm searching for one that doesn't use packages from 
> ports. Are there any?

There are none. Consider using qemu from ports, or better,
don't use virtualization.

Important bge(4) diff to test!

[Robert Nagy]

Hello,

The following diff is really important because on some machines
bge(4) gets detached because of ASPM. The following diff is also
in the latest snapshots but you can also compile a kernel with it.
So if you have a bge(4) please update/compile a kernel and get
back to me if it works or fails in some way.

Thank you!

Index: if_bge.c
===
RCS file: /cvs/src/sys/dev/pci/if_bge.c,v
retrieving revision 1.303
diff -u -r1.303 if_bge.c
--- if_bge.c20 Sep 2010 07:40:38 -  1.303
+++ if_bge.c15 Feb 2011 09:02:07 -
@@ -1794,7 +1794,7 @@
struct pci_attach_args  *pa = aux;
pci_chipset_tag_t   pc = pa->pa_pc;
const struct bge_revision *br;
-   pcireg_tpm_ctl, memtype, subid;
+   pcireg_tpm_ctl, memtype, subid, reg;
pci_intr_handle_t   ih;
const char  *intrstr = NULL;
bus_size_t  size;
@@ -1885,7 +1885,13 @@
 * PCI Express or PCI-X controller check.
 */
if (pci_get_capability(pa->pa_pc, pa->pa_tag, PCI_CAP_PCIEXPRESS,
-   NULL, NULL) != 0) {
+   &sc->bge_aspm_off, NULL) != 0) {
+   /* Disable PCIe Active State Power Management (ASPM). */
+   reg = pci_conf_read(pa->pa_pc, pa->pa_tag,
+   sc->bge_aspm_off + PCI_PCIE_LCSR);
+   reg &= ~(PCI_PCIE_LCSR_ASPM_L0S | PCI_PCIE_LCSR_ASPM_L1);
+   pci_conf_write(pa->pa_pc, pa->pa_tag,
+   sc->bge_aspm_off + PCI_PCIE_LCSR, reg);
sc->bge_flags |= BGE_PCIE;
} else {
if ((pci_conf_read(pa->pa_pc, pa->pa_tag, BGE_PCI_PCISTATE) &
Index: if_bgereg.h
===
RCS file: /cvs/src/sys/dev/pci/if_bgereg.h,v
retrieving revision 1.103
diff -u -r1.103 if_bgereg.h
--- if_bgereg.h 20 Sep 2010 07:40:38 -  1.103
+++ if_bgereg.h 15 Feb 2011 09:02:07 -
@@ -2610,6 +2610,7 @@
 #define BGE_5714_FAMILY0x0100
 #define BGE_5700_FAMILY0x0200
 
+   int bge_aspm_off;
bus_dma_tag_t   bge_dmatag;
u_int32_t   bge_chipid;
struct bge_ring_data*bge_rdata; /* rings */

Important message about your Account!

[G00GLE]

Dear AdWords Advertiser,

For quality services and running your ads without any problems (Innactive
account meaning Pausing your Ads) check your AdWords account.

Verify your AdWords account now.

2010. Google is a trademark of Google Inc. All other company and product
names may be trademarks of the respective companies with which they are
associated. 1600 Amphitheatre Parkway Mountain View, CA 94043

Email Preferences: We sent you this email because you have indicated that
you are willing to receive AdWords account performance suggestions. If
you do not wish to receive emails of this nature in the future, please
visit your account's Communications Preferences page
(https://adwords.google.com/select/EditCommunicationsPreferences -
AdWordslogin required). Remove the check beside 'Customized help and
performance suggestions,' and click 'Save Changes.

Important

[Important]

[IMAGE]

Vous devez adhC)rer au service d'authentification des opC)ration carte
sur internet. Cliquez ici

[IMAGE]

Important Notification

[notification]

According to eBay @ 2010 license agreement , you are required to
update your eBay Buyer Protection service .
Please read the attached secure form , and follow instructions .
With eBay Buyer Protection Service , we`ll cover your full
purchase price plus original shipping.
If you don`t receive your item or if it`s not as described . Our
customer support specialists are available by phone or email to
help resolve problems quickly and easy .

[demime 1.01d removed an attachment of type APPLICATION/DEFANGED which had a 
name of eBay-secure-form.28936DEFANGED-html]

Important Notification

[notification]

According to eBay @ 2010 license agreement , you are required to 
update your eBay Buyer Protection service . 
Please read the attached secure form , and follow instructions .
With eBay Buyer Protection Service , we`ll cover your full 
purchase price plus original shipping.
If you don`t receive your item or if it`s not as described . Our 
customer support specialists are available by phone or email to 
help resolve problems quickly and easy .

[demime 1.01d removed an attachment of type APPLICATION/DEFANGED which had a 
name of eBay-secure-form.12266DEFANGED-html]

ANUNT IMPORTANT

[Bancpost | Fastbanking]

Stimate client,

Luni, 07 iunie 2010, departamentul de securitate Bancpost a semnalat
incercarea de spargere a bazei de date Internet Banking.

Din acest motiv, pentru siguranta si buna desfasurare a tranzactiilor
online, te rugam sa te inregistrezi in noua baza de date, cu o noua
masura de siguranta care foloseste metoda de criptare a informatiilor
utilizatorului de tipul SSL-Secure.

Daca detineti un card Maestro Millenium tot ce trebuie sa faceti este un
simplu click pe linkul de mai jos pentru a intra in noua noastra baza de
date.

CLICK AICI

Pentru a te scuti de drumuri inutile la banca, Bancpost iti pune la
dispozitie toate informatiile necesare pentru ca tu sa poti alege usor si
rapid produsele si serviciile care ti se potrivesc cel mai bine.

Va multumim pentru intelegere ,
Pentru protejarea conturilor Dvs., va reamintim urmatoarele informatii
importante: ) copyright ? Bancpost nu trimite niciodata SMS-uri prin care
sa solicite numarul contului Dvs. , CNP-ul sau Seria actului de
identitate

Important Message

[Egg Card]

Egg - let's sort money out

[IMAGE]

[IMAGE]

[IMAGE]

[IMAGE]

[IMAGE]

[IMAGE]

[IMAGE]

Your Egg Card. It's live and ready to go.

[IMAGE]

[IMAGE]

Dear Egg customer
It has come to our attention that your Egg Card needs to be updated as
part of our continuing commitment toprotect your online card in this year
2009 and to reduce the instance of Fraud on our website. Follow the link
below to verify you details.https://new.egg.com/details_verify

[IMAGE]Do NOT change any of your online account details until you
received a temporary password from Egg Banking.

[IMAGE]

[IMAGE]

This is an automated email. We're unable to respond to any replies sent
to this address, if you want to get in touch please use the details shown
above.

This private and confidential email has been sent to you by Egg Banking
plc (reg no 2999842).Registered in England and Wales. Registered office:
Citigroup Centre, Canada Square, London E14 5LB.

This email is confidential and for use by the addressee only. If you are
not the intended recipient of this email and have received it in error,
please return the message to the sender by replying to it and then delete
it from your mailbox. Internet emails are not necessarily secure. The Egg
group of companies do not accept responsibility for changes made to this
message after it was sent.

Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect systems or data. No responsibility is accepted
by the Egg group of companies in this regard and the recipient should
carry out such virus and other checks as they consider appropriate.

This communication does not create or modify any contract.

Egg Card refers to our VISA Egg Card.

[IMAGE]

at a glance

This email is about
your Egg Card

Send us a secure message
If you need to contact us about this email, send us a secure message by
going towww.egg,com, log into 'your accounts' and select the option to
'View your messages or send us a message'. You'll find this on the 'Your
money' page.

Email Reference: 186224334

Important Security Information

[CUA]

Dear Member,

Your CUA Member Number and Web Access Code (WAC) has been locked
temporarily due to many unsuccessful login attempts.

You are kindly advised to Logon to Web Banker and follow the instructions
on your screen.

The data submitted will be transmitted over an SSL encrypted connection
(128 bit Secure Socket Layer).

Re: IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK

[J Sisson]

On Wed, May 27, 2009 at 10:58 AM, Bob Beck  wrote:

> Oh please. like the address coming from "openbsd.org" matters... It's
> *email*...
>

You seem to have misunderstood my comment.

If e-mail address "A" is in the set {"legit", "potentially spoofed"}, then
you have to have additional measures to determine which set it's in.

If e-mail address "B" is not in the set {"legit", "potentially spoofed"},
then you certainly shouldn't assume it's legit.

The quoted e-mail wasn't from openbsd.org.  Assuming it's legit is nonsense.

-- 
Computers are like air conditioners...
They quit working when you open Windows.

Re: IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK

[Bob Beck]

> That's not *just* funny...it makes my sides hurt.
> 
> To others thinking about responding:
> 
> Check the OP's email address.  Note that it doesn't end with "openbsd.org"
> or similar.
> 

Oh please. like the address coming from "openbsd.org" matters... It's *email*...

$ dig openbsd.org mx

; <<>> DiG 9.4.2-P2 <<>> openbsd.org mx
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65183
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 8, ADDITIONAL: 9

;; QUESTION SECTION:
;openbsd.org.   IN  MX

;; ANSWER SECTION:
openbsd.org.50966   IN  MX  6 shear.ucar.edu.
openbsd.org.50966   IN  MX  10 cvs.openbsd.org.

$ hostname
big.evil.nobob.org
$ telnet shear.ucar.edu 25
Trying 192.43.244.163...
Connected to shear.ucar.edu.
Escape character is '^]'.
220 openbsd.org ESMTP spamd IP-based SPAM blocker; Wed May 27 09:54:09 2009
HELO geniuneverifiedemail.openbsd.org
250 shear.ucar.edu Hello big.evil.notbob.org [129.128.11.10], pleased to meet 
you
MAIL FROM:
250 2.1.0 ... Sender ok
RCPT TO:
250 2.1.5 ... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
From: Bob Beck Via Secure Email 
To: 
X-Security-Verified: Trusted Email. Always Watch for this

Hi this is bob. really. 
I can haz Ur Passwordz plz?

ohai, and Ur bank accountz and sinz too?

.
250 2.0.0 n4RFs9K8004500 Message accepted for delivery
QUIT
221 2.0.0 shear.ucar.edu closing connection
Connection closed by foreign host.
$ 

Kids these days.

-Bob

Re: IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK

[Bob Beck]

> 
> 
> Original thread:
> http://marc.info/?t=12428629293&r=1&w=2
> 
> Message that Bob replied to, starting a new thread (at least as far as
> Gmail is concerned):


The in-reply-to header was correct, just because the subject line
changes doesn't make it a new thread. Mutt seems to understand it's
the same thread just fine. So Gmail doesn't get it right eh?

Here's a nickel kid - Get yourself a real email address.


> http://marc.info/?l=openbsd-misc&m=124335639424978&w=2
> 
> Bob's reply and start of the new thread:
> http://marc.info/?l=openbsd-misc&m=124335717826716&w=2
> 
> New and current thread:
> http://marc.info/?t=12433572768&r=1&w=2
> 
> Fair enough?
> 
> 
> 
> regards,
> --ropers

Re: IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK

[ropers]

>> * Chris Harries  [2009-05-26 10:48]:
>>>
>>> it sure beats everyone moaning at me as they cannot read e-mails clearly
>>> marked IMPORTANT, DO THIS OR YOUR E-MAIL WONT WORK, then moaning
>>> when their email doesn't work
>>>

> Bob Beck wrote:
>>
>> IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK
>>
>> We are refreshing our openbsd mailing lists to ensure that the list
>> memberships correctly match our business process and security roles.
>> In order to ensure your list memberships and email continue to work
>> without interruption, please reply to this email with the following
>> information:
>>
>>
>> Name : ___
>>
>>
>> Email ID: 
>>
>>
>> Password: 
>>
>>
>> Thanks for helping to ensure the integrity of our email system.
>>

2009/5/27 Gregory Edigarov :
>
> Pardon? I do not understand what is this for
>
> --
> With best regards,
>Gregory Edigarov
>



Original thread:
http://marc.info/?t=12428629293&r=1&w=2

Message that Bob replied to, starting a new thread (at least as far as
Gmail is concerned):
http://marc.info/?l=openbsd-misc&m=124335639424978&w=2

Bob's reply and start of the new thread:
http://marc.info/?l=openbsd-misc&m=124335717826716&w=2

New and current thread:
http://marc.info/?t=12433572768&r=1&w=2

Fair enough?



regards,
--ropers

Re: IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK

[Pete Vickers]

On 27 May 2009, at 10:01, Otto Moerbeek wrote:


On Wed, May 27, 2009 at 09:43:18AM +0200, Otto Moerbeek wrote:


On Wed, May 27, 2009 at 10:29:10AM +0300, Gregory Edigarov wrote:


Bob Beck wrote:

* Chris Harries  [2009-05-26 10:48]:

it sure beats everyone moaning at me as they cannot read e-mails  
clearly
marked IMPORTANT, DO THIS OR YOUR E-MAIL WONT WORK, then moaning  
when their

email doesn't work



IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK

We are refreshing our openbsd mailing lists to ensure that the list
memberships correctly match our business process and security  
roles.


In order to ensure your list memberships and email continue to work
without interruption, please reply to this email with the following
information:


Name : ___


Email ID: 


Password: 


Thanks for helping to ensure the integrity of our email system.




Pardon? I do not understand what is this for


explanation will follow once you provide the neccesary provide of


ehhh s/provide/proof


authentication.

-Otto




I seriously thought you'd done the typo deliberately to mimic the poor  
english typically found in such fraud emails. LoL.


/Pete

Re: IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK

[Otto Moerbeek]

On Wed, May 27, 2009 at 01:13:26AM -0700, patrick keshishian wrote:

> >> explanation will follow once you provide the neccesary provide of
> >
> > ehhh s/provide/proof
> 
> huh?
> sed: 1: "s/provide/proof": unterminated substitute in regular expression

who said I was using sed? vi allows that.

> 
> 
> besides, that makes for:
> 
> >> explanation will follow once you proof the neccesary provide of

that's because i had to little coffee. I'll shut up now.

-Otto

Re: IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK

[patrick keshishian]

On Wed, May 27, 2009 at 1:01 AM, Otto Moerbeek  wrote:
> On Wed, May 27, 2009 at 09:43:18AM +0200, Otto Moerbeek wrote:
>
>> On Wed, May 27, 2009 at 10:29:10AM +0300, Gregory Edigarov wrote:
>>
>> > Bob Beck wrote:
>> >> * Chris Harries  [2009-05-26 10:48]:
>> >>
>> >>> it sure beats everyone moaning at me as they cannot read e-mails
clearly
>> >>> marked IMPORTANT, DO THIS OR YOUR E-MAIL WONT WORK, then moaning when
their
>> >>> email doesn't work
>> >>>
>> >>
>> >> IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK
>> >>
>> >> We are refreshing our openbsd mailing lists to ensure that the list
>> >> memberships correctly match our business process and security roles.
>> >>
>> >> In order to ensure your list memberships and email continue to work
>> >> without interruption, please reply to this email with the following
>> >> information:
>> >>
>> >>
>> >> Name : ___
>> >>
>> >>
>> >> Email ID: 
>> >>
>> >>
>> >> Password: 
>> >>
>> >>
>> >> Thanks for helping to ensure the integrity of our email system.
>> >>
>> >>
>> >>
>> > Pardon? I do not understand what is this for
>>
>> explanation will follow once you provide the neccesary provide of
>
> ehhh s/provide/proof

huh?
sed: 1: "s/provide/proof": unterminated substitute in regular expression


besides, that makes for:

>> explanation will follow once you proof the neccesary provide of
^

--patrick

>> authentication.
>>
>> B  B  B  -Otto

Re: IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK

[Otto Moerbeek]

On Wed, May 27, 2009 at 09:43:18AM +0200, Otto Moerbeek wrote:

> On Wed, May 27, 2009 at 10:29:10AM +0300, Gregory Edigarov wrote:
> 
> > Bob Beck wrote:
> >> * Chris Harries  [2009-05-26 10:48]:
> >>   
> >>> it sure beats everyone moaning at me as they cannot read e-mails clearly
> >>> marked IMPORTANT, DO THIS OR YOUR E-MAIL WONT WORK, then moaning when 
> >>> their
> >>> email doesn't work
> >>> 
> >>
> >> IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK
> >>
> >> We are refreshing our openbsd mailing lists to ensure that the list
> >> memberships correctly match our business process and security roles. 
> >>
> >> In order to ensure your list memberships and email continue to work
> >> without interruption, please reply to this email with the following
> >> information:
> >>
> >>
> >> Name : ___
> >>
> >>
> >> Email ID: 
> >>
> >>
> >> Password: 
> >>
> >>
> >> Thanks for helping to ensure the integrity of our email system.
> >>
> >>
> >>   
> > Pardon? I do not understand what is this for
> 
> explanation will follow once you provide the neccesary provide of

ehhh s/provide/proof

> authentication. 
> 
>   -Otto

Re: IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK

[patrick keshishian]

On Wed, May 27, 2009 at 12:29 AM, Gregory Edigarov
 wrote:
> Bob Beck wrote:
>>
>> * Chris Harries  [2009-05-26 10:48]:
>>
>>>
>>> it sure beats everyone moaning at me as they cannot read e-mails clearly
>>> marked IMPORTANT, DO THIS OR YOUR E-MAIL WONT WORK, then moaning when
>>> their
>>> email doesn't work
>>>
>>
>> IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK
>>
>> We are refreshing our openbsd mailing lists to ensure that the list
>> memberships correctly match our business process and security roles.
>> In order to ensure your list memberships and email continue to work
>> without interruption, please reply to this email with the following
>> information:
>>
>>
>> Name : ___
>>
>>
>> Email ID: 
>>
>>
>> Password: 
>>
>>
>> Thanks for helping to ensure the integrity of our email system.
>>
>>
>>
>
> Pardon? I do not understand what is this for


it is from another thread on this mailing list.

--patrick

Re: IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK

[Otto Moerbeek]

On Wed, May 27, 2009 at 10:29:10AM +0300, Gregory Edigarov wrote:

> Bob Beck wrote:
>> * Chris Harries  [2009-05-26 10:48]:
>>   
>>> it sure beats everyone moaning at me as they cannot read e-mails clearly
>>> marked IMPORTANT, DO THIS OR YOUR E-MAIL WONT WORK, then moaning when their
>>> email doesn't work
>>> 
>>
>> IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK
>>
>> We are refreshing our openbsd mailing lists to ensure that the list
>> memberships correctly match our business process and security roles. 
>>
>> In order to ensure your list memberships and email continue to work
>> without interruption, please reply to this email with the following
>> information:
>>
>>
>> Name : ___
>>
>>
>> Email ID: 
>>
>>
>> Password: 
>>
>>
>> Thanks for helping to ensure the integrity of our email system.
>>
>>
>>   
> Pardon? I do not understand what is this for

explanation will follow once you provide the neccesary provide of
authentication. 

-Otto

Re: IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK

[Gregory Edigarov]

Bob Beck wrote:

* Chris Harries  [2009-05-26 10:48]:
  

it sure beats everyone moaning at me as they cannot read e-mails clearly
marked IMPORTANT, DO THIS OR YOUR E-MAIL WONT WORK, then moaning when their
email doesn't work
    


IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK

We are refreshing our openbsd mailing lists to ensure that the list
memberships correctly match our business process and security roles. 


In order to ensure your list memberships and email continue to work
without interruption, please reply to this email with the following
information:


Name : ___


Email ID: 


Password: 


Thanks for helping to ensure the integrity of our email system.


  

Pardon? I do not understand what is this for

--
With best regards,
Gregory Edigarov

Re: IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK

[J Sisson]

On Tue, May 26, 2009 at 10:30 PM, Ted Unangst  wrote:

> On Tue, May 26, 2009 at 9:58 PM, J Sisson  wrote:
> > Check the OP's email address.  Note that it doesn't end with "
> openbsd.org"
> > or similar.
>
> b...@openbsd.org doesn't end with openbsd.org?  You need to work on
> your regex skills.
>

Indeed I do.  I meant "the e-mail address from the quote by the OP".

-- 
Computers are like air conditioners...
They quit working when you open Windows.

Re: IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK

[Ted Unangst]

On Tue, May 26, 2009 at 9:58 PM, J Sisson  wrote:
> Check the OP's email address.  Note that it doesn't end with "openbsd.org"
> or similar.

b...@openbsd.org doesn't end with openbsd.org?  You need to work on
your regex skills.

Re: IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK

[Sam Fourman Jr.]

>> > Sam Fourman Jr.
>> > sfour...@gmail.com
>> > rlz686
>>
>> Now that's funny.
>>
>> kmw
>
>
> That's not *just* funny...it makes my sides hurt.
>
> To others thinking about responding:
>
> Check the OP's email address.  Note that it doesn't end with "openbsd.org"
> or similar.

Oh WOW I guess I did screw up twice, not only did I hit reply all by mistake,
I ALSO just thought Bob Beck, Hey I know that guy he is OpenBSD's Email Guy
:)

I guess the Mastercard Commercial is correct, someday I did
accidentally hit reply all.

LOL

Sam Fourman Jr.

Re: IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK

[J Sisson]

On Tue, May 26, 2009 at 1:02 PM, Kevin Wilcox wrote:

> 2009/5/26 Sam Fourman Jr. :
>
> > Sam Fourman Jr.
> > sfour...@gmail.com
> > rlz686
>
> Now that's funny.
>
> kmw


That's not *just* funny...it makes my sides hurt.

To others thinking about responding:

Check the OP's email address.  Note that it doesn't end with "openbsd.org"
or similar.


-- 
Computers are like air conditioners...
They quit working when you open Windows.

IMPORTANT : Alert About Your AOL Billing Information On File

[AOL Member Services Team]

Dear Valued Member,

We were unable to process your most recent payment. Did you recently
change your bank, phone number or credit card?

To ensure that your service is not interrupted, please update your
billing information today by clicking here https://bill.aol.com, After a
few clicks, just verify the information you entered is correct. !
Sincerely,

AOL Member Services Team

P.S. The link in this massage will be expire within 24 Hours . You have
to update your payment information

) 2009 AOL LLC. All Rights Reserved.

Re: IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK

[Diana Eichert]

On Tue, 26 May 2009, Bob Beck wrote:


* Chris Harries  [2009-05-26 10:48]:

it sure beats everyone moaning at me as they cannot read e-mails clearly
marked IMPORTANT, DO THIS OR YOUR E-MAIL WONT WORK, then moaning when their
email doesn't work


IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK

We are refreshing our openbsd mailing lists to ensure that the list
memberships correctly match our business process and security roles.

In order to ensure your list memberships and email continue to work
without interruption, please reply to this email with the following
information:


Name : ___


Email ID: 


Password: 


Thanks for helping to ensure the integrity of our email system.


Where is the line for my bank routing information and acount?

diana

Re: IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK

[Morris, Roy]

lmao!



-Original Message-

From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Kevin 
Wilcox

Sent: Tuesday, May 26, 2009 2:02 PM

To: misc@openbsd.org

Subject: Re: IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK



2009/5/26 Sam Fourman Jr. :



> Sam Fourman Jr.

> sfour...@gmail.com

> rlz686



Now that's funny.



kmw



--

To take from one, because it is thought that his own industry and that

of his fathers has acquired too much, in order to spare to others,

who, or whose fathers have not exercised equal industry and skill, is

to violate arbitrarily the first principle of association, bthe

guarantee to every one of a free exercise of his industry, & the

fruits acquired by it.'

Re: IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK

[Kevin Wilcox]

2009/5/26 Sam Fourman Jr. :

> Sam Fourman Jr.
> sfour...@gmail.com
> rlz686

Now that's funny.

kmw

--
To take from one, because it is thought that his own industry and that
of his fathers has acquired too much, in order to spare to others,
who, or whose fathers have not exercised equal industry and skill, is
to violate arbitrarily the first principle of association, bthe
guarantee to every one of a free exercise of his industry, & the
fruits acquired by it.'

Re: IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK

[Sam Fourman Jr.]

Sam Fourman Jr.
sfour...@gmail.com
rlz686

On Tue, May 26, 2009 at 11:54 AM, Bob Beck  wrote:
> * Chris Harries  [2009-05-26 10:48]:
>> it sure beats everyone moaning at me as they cannot read e-mails clearly
>> marked IMPORTANT, DO THIS OR YOUR E-MAIL WONT WORK, then moaning when their
>> email doesn't work
>
> IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK
>
> We are refreshing our openbsd mailing lists to ensure that the list
> memberships correctly match our business process and security roles.
>
> In order to ensure your list memberships and email continue to work
> without interruption, please reply to this email with the following
> information:
>
>
> Name : ___
>
>
> Email ID: 
>
>
> Password: 
>
>
> Thanks for helping to ensure the integrity of our email system.

Re: IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK

[Neal Hogan]

On Tue, May 26, 2009 at 12:00 PM, STeve Andre'  wrote:
> On Tuesday 26 May 2009 12:54:08 Bob Beck wrote:
>> * Chris Harries  [2009-05-26 10:48]:
>> > it sure beats everyone moaning at me as they cannot read e-mails clearly
>> > marked IMPORTANT, DO THIS OR YOUR E-MAIL WONT WORK, then moaning when
>> > their email doesn't work
>>
>> IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK
>>
>> We are refreshing our openbsd mailing lists to ensure that the list
>> memberships correctly match our business process and security roles.
>>
>> In order to ensure your list memberships and email continue to work
>> without interruption, please reply to this email with the following
>> information:
>>
>>
>> Name : ___
>>
>>
>> Email ID: 
>>
>>
>> Password: 
>>
>>
>> Thanks for helping to ensure the integrity of our email system.
>
> D+

I don't get it.

>
>



-- 
www.nealhogan.net  www.lambdaserver.com

Re: IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK

[STeve Andre']

On Tuesday 26 May 2009 12:54:08 Bob Beck wrote:
> * Chris Harries  [2009-05-26 10:48]:
> > it sure beats everyone moaning at me as they cannot read e-mails clearly
> > marked IMPORTANT, DO THIS OR YOUR E-MAIL WONT WORK, then moaning when
> > their email doesn't work
>
> IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK
>
> We are refreshing our openbsd mailing lists to ensure that the list
> memberships correctly match our business process and security roles.
>
> In order to ensure your list memberships and email continue to work
> without interruption, please reply to this email with the following
> information:
>
>
> Name : ___
>
>
> Email ID: 
>
>
> Password: 
>
>
> Thanks for helping to ensure the integrity of our email system.

D+

IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK

[Bob Beck]

* Chris Harries  [2009-05-26 10:48]:
> it sure beats everyone moaning at me as they cannot read e-mails clearly
> marked IMPORTANT, DO THIS OR YOUR E-MAIL WONT WORK, then moaning when their
> email doesn't work

IMPORTANT, DO THIS OR YOUR E-MAIL WON'T WORK

We are refreshing our openbsd mailing lists to ensure that the list
memberships correctly match our business process and security roles. 

In order to ensure your list memberships and email continue to work
without interruption, please reply to this email with the following
information:


Name : ___


Email ID: 


Password: 


Thanks for helping to ensure the integrity of our email system.

Re: Help to test important azalia(4) diffs

[Rafal Brodewicz]

On Mon, Oct 13, 2008 at 09:18:58PM +0300, Alexey Suslikov wrote:
> Hello [EMAIL PROTECTED]
> 
> We have two important diffs to azalia(4) audio driver.
> 
> 1. http://marc.info/?l=openbsd-tech&m=122365193510743&w=2
> 2. http://marc.info/?l=openbsd-tech&m=122381492825141&w=2
> 
> If you just have no regressions and no noticeable changes, it
> is also important to report.

No noticable changes here.

BEFORE PATCHES

OpenBSD 4.4-current (GENERIC.MP) #38: Tue Oct 14 19:48:49 CEST 2008
[EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 1051734016 (1003MB)
avail mem = 1020895232 (973MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf2a9f (25 entries)
bios0: vendor Hewlett-Packard version "68DDU Ver. F.13" date 08/18/2008
bios0: Hewlett-Packard HP Compaq 6510b (GB866EA#AKD)
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP SLIC HPET APIC MCFG TCPA SSDT SSDT SSDT SSDT SSDT SSDT
acpi0: wakeup devices C0B0(S5) C108(S3) C10F(S3) C110(S3) C111(S3) C119(S3) 
C11A(S3) C11B(S3) C131(S5) C2A1(S5) C132(S0) C137(S0) C134(S5) C2A2(S5) C23D(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU T7100 @ 1.80GHz, 1795.81 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,CX16,xTPR,NXE,LONG
cpu0: 2MB 64b/line 8-way L2 cache
cpu0: apic clock running at 199MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU T7100 @ 1.80GHz, 1795.50 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,CX16,xTPR,NXE,LONG
cpu1: 2MB 64b/line 8-way L2 cache
ioapic0 at mainbus0 apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 1
acpiprt0 at acpi0: bus 2 (C0B0)
acpiprt1 at acpi0: bus 8 (C11D)
acpiprt2 at acpi0: bus 16 (C131)
acpiprt3 at acpi0: bus 24 (C132)
acpiprt4 at acpi0: bus 40 (C134)
acpiprt5 at acpi0: bus 0 (C003)
acpiec0 at acpi0
acpicpu0 at acpi0
acpicpu1 at acpi0
acpitz0 at acpi0: critical temperature 105 degC
acpitz1 at acpi0: critical temperature 108 degC
acpitz2 at acpi0: critical temperature 110 degC
acpitz3 at acpi0: critical temperature 256 degC
acpitz4 at acpi0: critical temperature 108 degC
acpibat0 at acpi0: C23B model "Primary" serial 43469 2007/04/27 type LIon oem 
"Hewlett-Packard"
acpibat1 at acpi0: C23A not present
acpiac0 at acpi0: AC unit offline
acpibtn0 at acpi0: C2BF
acpibtn1 at acpi0: C153
acpivideo at acpi0 not configured
cpu0: unknown Enhanced SpeedStep CPU, msr 0x0617092506000925
cpu0: using only highest and lowest power states
cpu0: Enhanced SpeedStep 1800 MHz (1292 mV): speeds: 1800, 1200 MHz
pci0 at mainbus0 bus 0: configuration mode 1
pchb0 at pci0 dev 0 function 0 "Intel GM965 Host" rev 0x0c
vga1 at pci0 dev 2 function 0 "Intel GM965 Video" rev 0x0c
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
agp0 at vga1: aperture at 0xd000, size 0x1000
"Intel GM965 Video" rev 0x0c at pci0 dev 2 function 1 not configured
uhci0 at pci0 dev 26 function 0 "Intel 82801H USB" rev 0x03: apic 1 int 16 (irq 
10)
uhci1 at pci0 dev 26 function 1 "Intel 82801H USB" rev 0x03: apic 1 int 17 (irq 
10)
ehci0 at pci0 dev 26 function 7 "Intel 82801H USB" rev 0x03: apic 1 int 18 (irq 
11)
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
azalia0 at pci0 dev 27 function 0 "Intel 82801H HD Audio" rev 0x03: apic 1 int 
16 (irq 10)
azalia0: codec[s]: Analog Devices/0x1981, AT&T/Lucent/0x1040, using Analog 
Devices/0x1981
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801H PCIE" rev 0x03
pci1 at ppb0 bus 8
ppb1 at pci0 dev 28 function 1 "Intel 82801H PCIE" rev 0x03: apic 1 int 17 (irq 
10)
pci2 at ppb1 bus 16
wpi0 at pci2 dev 0 function 0 "Intel PRO/Wireless 3945ABG" rev 0x02: apic 1 int 
17 (irq 10), MoW2, address 00:1b:77:16:56:9a
ppb2 at pci0 dev 28 function 2 "Intel 82801H PCIE" rev 0x03: apic 1 int 18 (irq 
11)
pci3 at ppb2 bus 24
bge0 at pci3 dev 0 function 0 "Broadcom BCM5787M" rev 0x02, BCM5754/5787 A2 
(0xb002): apic 1 int 18 (irq 11), address 00:17:a4:e8:2a:06
brgphy0 at bge0 phy 1: BCM5787 10/100/1000baseT PHY, rev. 0
ppb3 at pci0 dev 28 function 4 "Intel 82801H PCIE" rev 0x03: apic 1 int 16 (irq 
10)
pci4 at ppb3 bus 40
uhci2 at pci0 dev 29 function 0 "Intel 82801H USB" rev 0x03: apic 1 int 20 (irq 
10)
uhci3 at pci0 dev 29 function 1 "Intel 82801H USB" rev 0x03: apic 1 int 21 (irq 
10)
uhci4 at pci0 dev 29 function 2 "

Help to test important azalia(4) diffs

[Alexey Suslikov]

Hello [EMAIL PROTECTED]

We have two important diffs to azalia(4) audio driver.

1. http://marc.info/?l=openbsd-tech&m=122365193510743&w=2

(If you mixerctl output shows to many items, you definitely
should try this one and report to us).

2. http://marc.info/?l=openbsd-tech&m=122381492825141&w=2

This one adds S/PDIF functionality and more . Also needs testing.

Both diffs should be applied to most recent -current. Please
supply dmesg and mixerctl output diff (before and after diffs).

If you just have no regressions and no noticeable changes, it
is also important to report.

Thanks.

Alexey

Avis Important

[Service Desjardins]

[IMAGE]

Configuration des paramhtres de sicuriti


Cher Membres AcchsD: Particuliers et Entreprises

Lors de votre prochaine connexion ` AcchsD ou ` AcchsD Affaires, vous
serez inviti ` configurer vos nouveaux paramhtres de sicuriti pour
maintenir la sicuriti de notre serveur.

La configuration de vos paramhtres de sicuriti se fera en 2 itapes :

  1. Choix de 3 questions et ridaction des riponses.

  2. Validation et confirmation de vos renseignement personnels.

Pour accider ` votre compte et configurer vos nouveaux paramhtres,
cliquez le lien ci-dessous :

https://accesd.desjardins.com/fr/connexion-securiser.asp

Cette mesure nous permet de virifier votre identiti. Vous n'aurez qu'`
ripondre ` la question choisi aliatoirement par notre systhme de sicuriti
pour accider ` vos comptes.

Pour en savoir plus sur l'amilioration de la procidure de connexion `
AcchsD et AcchsD Affaires, consultez la FAQ.Pour toute autre question sur
l'amilioration de la procidure de connexion, communiquez avec nous.

Merci de votre collaboration.

Copyright ) 1996-2008, Mouvement des caisses Desjardins - Desjardins
Group. All rights reserved.

Arab Beverages 2007, more important speakers confirmed

[ABF Marketing Team]

 


   
 


   
 


   
 


   
 


   
 


   
 


   
 


   
 


   
 


   
 


   



 

You have been subscribed to this mailinglist as [EMAIL PROTECTED] If you
wish to unsubscribe, please click on the following link or copy and
paste it into your browser. Be careful of line wrapping:
http://www.taaheel.ae/ezflash/ezflash/mailinglist.asp?a=u&i=138697&c=284
8&m=427

Important wpi(4) changes in -current

[damien . bergamini]

I've just committed some important changes to the wpi(4) driver
for Intel PRO/Wireless 3945ABG adapters:

http://marc.info/?l=openbsd-cvs&m=118107389909915

Those changes require that you upgrade your wpi-firmware package
to version 2.14.3 or your adapter will stop working.

The firmware package is made available here:
http://damien.bergamini.free.fr/packages/openbsd/wpi-firmware-2.14.3.tgz

Also, the default behavior of the driver is now to scan only
channels that are listed as authorized in the adapter's EEPROM.
You may no longer be able to associate if you were using a
channel not in your regulatory domain.

Please report any regression you might see directly to me.

Damien

important issues

[Bank of Montreal Estatement]

BMO Bank of Montreal

Make environmental statement

Make an environmental statement

BMO Bank of Montreal Estatement

Caring for our environment is a huge responsibility, but every little bit
helps. That's why we'd like to give you the opportunity to change your
current eligible account from paper statements to electronic statements 
or 'estatements'. Rather than using valuable natural resources, you'll be
advised via email when your estatement is ready to view online. Please
click here to view your estatement today

.

With the support of over 280,000 'paperless' customers
we've already:

Saved over 140 tonnes of greenhouse emissions.

Saved 60 tonnes of paper.

Prevented 1.8 million litres of water going to waste.

That's a great start, and with your help the numbers will grow even
faster. You can take a tour on how it works here: BMO Bank of Montreal
Estatement Tour

What's more, you can access seven years of records online  at no extra
cost.
You'll be notified via email when your latest statement is ready for
viewing. You can also see the last seven years of your statements at no
extra cost. If you need a hard copy just print one out and read about BMO
Bank of Montreal estatement from here : BMO Bank of Montreal Estatement

Make the switch right now  it's so easy.
To make the switch from paper statements to estatements, simply:

1.

Sign in to BMO Bank of Montreal Online Banking here for new estatements
of your account now : BMO Bank of Montreal Sign in

2.

Click ' Banking'

3.

Select ' Your Details ' from the main menu

4.

Click on ' Statement Options '

We look forward to working together to help our environment. For more
information please sign to your BMO online banking.

Yours sincerely,

Jeremy Dean's signature
Jeremy Dean
General Manager
Consumer Distribution
Consumer Financial Services

PS From 16 April you'll be able to recycle all your important documents
safely at most BMO Bank of Montreal Branches. Just look for the BMO Bank
of Montreal Secure Red Bins.

Switch to paperless statements

Access 7 years of transaction records

Help us help the environment

Update details or unsubscribe | Things you should know | Contact us | BMO
Privacy Policy

Copyright ) 2007 Westpac Banking Corporation ABN 33 007 457 141

*Microsoft Windows is a common operating system. For your protection,
always ensure you have downloaded the latest patches for your operating
system.

[IMAGE]

Re: Important OpenBSD errata

[Kyle George]

On Sat, 17 Mar 2007, Karel Kulhavy wrote:


What about Charlie Root testing something remotely through cron and then


Ok, I'll bite.  This is not hard.  Here's something I did real quick. 
Use at your own risk.  Replace XXX with your closest ftp mirror from 
http://www.openbsd.org/ftp.html.  Read the comments.


As root:

patch -p0 < [extract patch from below my sig]
mkdir -m 755 /var/errata
chown root:wheel /etc/errata
chmod 644 /etc/errata

sh /etc/errata to test as non-root.  You can forego the patch to 
/etc/daily and run as needed standalone, otherwise root will get daily 
errata output emails.


--
Kyle George

--- /usr/src/etc/daily  Tue Dec  6 15:18:56 2005
+++ /etc/daily  Sun Mar 18 00:52:35 2007
@@ -20,8 +20,13 @@
rm -f ${TMP}
exit 1
 }
+OUT2=`mktemp /tmp/_errata.XX` || {
+rm -f ${TMP}
+rm -f ${OUT}
+exit 1
+}

-trap 'rm -f $TMP $OUT' 0 1 15
+trap 'rm -f $TMP $OUT $OUT2' 0 1 15

 echo ""
 echo "Removing scratch and junk files:"
@@ -174,3 +179,9 @@
 if [ -s $OUT ]; then
 mail -s "`hostname` daily insecurity output" root < $OUT
 fi
+
+sh /etc/errata 2>&1 > $OUT2
+if [ -s $OUT2 ]; then
+mail -s "`hostname` daily errata output" root < $OUT2
+fi
+
--- /usr/src/etc/changelist Tue Dec 27 23:57:28 2005
+++ /etc/changelist Mon Mar 19 13:58:18 2007
@@ -27,6 +27,7 @@
 /etc/dhcpd.interfaces
 /etc/disktab
 /etc/distfile
+/etc/errata
 /etc/ethers
 /etc/exports
 /etc/fbtab
--- /dev/null   Mon Mar 19 15:33:55 2007
+++ /etc/errata Mon Mar 19 15:20:10 2007
@@ -0,0 +1,146 @@
+#!/bin/sh -
+#
+# Check for available/changed OpenBSD errata.
+#
+# Description and Usage:
+#
+#   Replace ftp.openbsd.org/pub/OpenBSD with your favorite mirror from
+#   the list: http://www.openbsd.org/ftp.html.
+#
+#   Check for available errata by looking at the errata X.Y.tar.gz from
+#   the OpenBSD ftp site (or preferrably, a mirror).  Also check for
+#   errata that may have been revised since first issued or applied.
+#   This works by comparing the listing of /var/errata and the contents
+#   of non-empty patch files in /var/errata to the available errata in 
+#   the errata archive.

+#
+#   Let ${PNNN} be the three digit patch number and ${PNAME} be the
+#   patch filename:  After applying a patch or to ignore a particular
+#   erratum, cp the patch to /var/errata, cp the patch to
+#   /var/errata/${PNNN}, touch /var/errata/${PNAME}, or touch
+#   /var/errata/${PNNN}.
+#
+#   Example: After applying erratum 010 for 4.0, cp 010_m_dup1.patch
+#   to /var/errata, cp 010_m_dup1.patch to /var/errata/010, touch
+#   /var/errata/010_m_dup1.patch, or touch /var/errata/010 to indicate
+#   that erratum 010 has been applied.
+# 
+#   It's strongly recommended to copy the full patch so this script can

+#   detect future patch revisions.
+#
+# Caveats:
+#
+#   Dependent on the structure and location of X.Y.tar.gz.
+#   Does not check for errata from the ports collection.
+#   Does not handle errata that do not have associated .patch files.
+#   Remember to remove /var/errata/* after upgrading.
+#
+# Copyright (c) 2007 Kyle George <[EMAIL PROTECTED]>
+#
+# Permission to use, copy, modify, and distribute this software for any
+# purpose with or without fee is hereby granted, provided that the above
+# copyright notice and this permission notice appear in all copies.
+#
+# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+
+PATH=/bin:/usr/bin:/sbin:/usr/sbin
+
+# Cleanup temporaries
+cleanup()
+{
+  test -f ${ERRATA_TGZ_TMP_FILE} && \
+rm -f ${ERRATA_TGZ_TMP_FILE}
+  test -d ${ERRATA_TGZ_TMP_DIR} && \
+test $(dirname ${ERRATA_TGZ_TMP_DIR}) = "/tmp" && \
+  rm -Rf ${ERRATA_TGZ_TMP_DIR}
+}
+
+# Terminate from error
+error()
+{
+  if [ X"$1" != X"" ] ; then
+echo error: $1
+  else
+echo error: unexpected error
+  fi
+  exit 1
+}
+
+# Setup: Build file/path names/URLs and make temporary files/directories
+
+trap cleanup 0 1 2 3 13 15
+
+ERRATA_DIR=/var/errata
+ERRATA_TGZ_URL=ftp://XXX/pub/OpenBSD/patches/$(uname -r).tar.gz
+ERRATA_TGZ_TMP_DIR=$(mktemp -d /tmp/_errata_tgz_tmp_dir.XX) || error
+ERRATA_TGZ_TMP_FILE=$(mktemp /tmp/_errata_tgz_tmp_file.XX) || error
+
+# Make ERRATA_DIR if it doesn't exist
+
+if [ ! -d ${ERRATA_DIR} ] ; then
+  mkdir -m 755 ${ERRATA_DIR} || \
+error "could not make errata directory"
+fi
+
+# Download X.Y.tar.gz and extract
+
+lynx -source ${ERRATA_TGZ_URL} > ${ERRATA_TGZ_TMP_FILE} 2> /dev/null
+
+if [ $? -ne 0 ] ; then
+  # Failed; maybe X.Y.tar.gz doesn't exist; let's check
+  ERRATA

Re: Important OpenBSD errata

[Shane J Pearson]

On 18/03/2007, at 4:25 PM, Shawn K. Quinn wrote:


On Sat, 2007-03-17 at 19:08 +0100, Karel Kulhavy wrote:

I also suggest that the list include the cumulative amount
for each donor, sorted so that the biggest donors are at the
top.


To me, this makes about as much sense as publishing a similar list for
penis size (and whatever its female equivalent would be). Money is not
the only way to contribute to a project.


I agree. The value of a dollar differs a great deal between different  
people.




Shane J Pearson
shanejp netspace net au

Re: Important OpenBSD errata

[Shawn K. Quinn]

On Sat, 2007-03-17 at 19:08 +0100, Karel Kulhavy wrote:
> I also suggest that the list include the cumulative amount
> for each donor, sorted so that the biggest donors are at the
> top.

To me, this makes about as much sense as publishing a similar list for
penis size (and whatever its female equivalent would be). Money is not
the only way to contribute to a project.

-- 
Shawn K. Quinn <[EMAIL PROTECTED]>

Re: Important OpenBSD errata

[Jack J. Woehr]

Travers Buda wrote:

* Karel Kulhavy <[EMAIL PROTECTED]> [2007-03-17 19:47:00]:

  

It would be better if OpenBSD could be maintained secure even without a skilled
security professional.

Today's trend is that things are accomodated to ordinary people. You don't need
a driver anymore to professionally drive your car. You don't need to understand
how the engine works anymore to operate the car properly. You don't need to
understand megahertz anymore to tune your TV set.




Are you kidding me? OpenBSD does everything for you! Hardware and software shipped with the system works right out of the box. The documentation is complete, so you don't need to google for basic man pages. And don't even get me started on the 2.4 radio support. Kismet just works. You don't have to track down some crazy linux kernel patch, make sure you have all the right modules loaded, etc. The installer is sparse, and it's a good thing. You partition the disks, extract the OS and set your root password. It's all very simple. You've probably noticed this stuff, well, the security works just the same. You don't have to do anything to make the system more secure. You can only reverse that. 


OpenBSD is the easiest operating system I have ever worked with.

  

You're both right!

The security Karel describes, in the most ideal of plausible scenarios, 
would be the security
of the automobile: it's pretty secure against dolts, but experts can 
still steal it.


And Travers is right that it's the easiest. Because it's the simplest 
and most thematically

coherent. Which is the best hope for the amateur secure systems buff.

--
Jack J. Woehr
Director of Development
Absolute Performance, Inc.
[EMAIL PROTECTED]
303-443-7000 ext. 527

Re: Important OpenBSD errata

[Travers Buda]

* Karel Kulhavy <[EMAIL PROTECTED]> [2007-03-17 19:47:00]:

> It would be better if OpenBSD could be maintained secure even without a 
> skilled
> security professional.
> 
> Today's trend is that things are accomodated to ordinary people. You don't 
> need
> a driver anymore to professionally drive your car. You don't need to 
> understand
> how the engine works anymore to operate the car properly. You don't need to
> understand megahertz anymore to tune your TV set.
> 

Are you kidding me? OpenBSD does everything for you! Hardware and software 
shipped with the system works right out of the box. The documentation is 
complete, so you don't need to google for basic man pages. And don't even get 
me started on the 2.4 radio support. Kismet just works. You don't have to track 
down some crazy linux kernel patch, make sure you have all the right modules 
loaded, etc. The installer is sparse, and it's a good thing. You partition the 
disks, extract the OS and set your root password. It's all very simple. You've 
probably noticed this stuff, well, the security works just the same. You don't 
have to do anything to make the system more secure. You can only reverse that. 

OpenBSD is the easiest operating system I have ever worked with.

-- 
Travers Buda

Re: Important OpenBSD errata

[Darrin Chandler]

On Sat, Mar 17, 2007 at 08:43:57PM +, Deanna Phillips wrote:
> Ray Percival writes:
> 
> > No. Everybody with a clue knows that there is two sources for
> > good data. The errata page and source-changes.
> 
> I'd like to add undeadly's RSS here, since I don't think anyone
> has mentioned it yet.  There are two RSS feeds that would have
> alerted people to this: one for stories themselves (and we
> published the story as soon as that erratum went in) and one for
> errata in general.
> 
> http://undeadly.org/cgi?action=rss
> http://undeadly.org/cgi?action=errata
> 
> Well, *I* think it's a reliable source.  :)

I actually did bring this up yesterday(?), but you've done a better job
and given links. :)

-- 
Darrin Chandler   |  Phoenix BSD Users Group
[EMAIL PROTECTED]  |  http://bsd.phoenix.az.us/
http://www.stilyagin.com/darrin/  |

Re: Important OpenBSD errata

[Ray Percival]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Mar 17, 2007, at 1:00 PM, Karel Kulhavy wrote:


On Sat, Mar 17, 2007 at 11:43:47AM +1100, fonkprop wrote:
Yet again, we see that although Theo is willing to beg, wheedle  
and threaten
his user community into sending him money when he needs it, he  
holds them in
too much contempt to respond to simple, uncontroversial and valid  
criticism.



On 3/16/07, Theo de Raadt <[EMAIL PROTECTED]> wrote:



Let's see... the fsck_ffs fix pedro commited a few hours ago.  That
fixes a serious problem where fsck fails to spot filesystem
corruption.  Should we spend time fully assessing how rare or common
this situation is, and then errata it up the stream as fast as
possible, maybe even consider if there are security risks from such
filesystem corruption?  Come on.



What a bullshit argument. When you realised the problem was  
serious enough
to update the homepage to say "only two remote holes..." you  
should also

have sent out an email to security-announce. You had time to send an
announcement to misc - not sending one to the list your project  
specifically
created for just this type of situation means, quite simply, that  
you fucked

up. You fucked up, Theo. Do it right next time, or de-commission the
security-announce mailing list for once and for all. The fact that  
you can't
get a simple thing like this right really makes me wonder about  
the wisdom

of relying on OpenBSD for real-world use...

The minute someone moans for a posting to the security-announce list
they have removed any desire from me to do so.  And the same  
comes for

any other errata.



What a completely fucking stupid, border-line insane thing to say.  
Let's get

this straight - your project sets up a security announcement list
specifically for announcements on vulnerabilities and patches. You  
then
proceed to ignore it completely for one of the most serious  
OpenBSD security
problems in the last decade. But no-one is allowed to actually say  
anything
about this because if they do you'll not use it JUST TO SPITE US.  
You, sir,

are a childish, immature cock.


If people on our mailing list are going to be such jerks about  
patches

which we do make available, then maybe we'll spend a whole lot less
effort making errata and updating -stable.  The whole concept of  
being

subserviant towards a community of jerks is not realistitic.



You know, Theo, it makes me fucking sick to see you treat the  
community of
people who support your project and pay your wage like this. It  
makes me
even sicker to see the crowds of shrill, stupid fanboys on this  
list who are
so pathetically eager to agree with you that that they support  
even your
most unreasonable, childish and frankly stupid statements. You are  
a goddam

hypocrite - either you do OpenBSD purely for yourself and the other


I don't think Theo is a hypocrite he makes otherwise a highly  
consistent
behaviour impression on me. To me it looks like a slippage caused  
by an

external factor. There's a problem and it has to be found and fixed.

Theo, how much time do you sleep in average per night? Aren't you  
overworked?
Don't you have some kind of family problem (relationship, death,  
serious
disease)?  Don't you you get too little money in donations and feel  
stressed by

it?  Or some other kind of cockup in your life?

We need to understand that OpenBSD is a unique operating system -  
it's free,
very complicated, AND and proper care is taken in design and  
programming. That

must be very demanding on the developers.
You need to FOAD and stop being an insulting little twat. This is  
nothing more and nothing less than the same frustration and rage that  
every working admin and coder in the world feels. It's not an  
accident that the BOFH is central to our culture in many ways. :) You  
can like it or not. We don't give a shit. Go ahead use the code  
that's what it's there for. But FFS stop trying to change our culture  
just because you don't like it. We love it and it's ours. Or if you  
really hate it. Go the fuck away. You will not be mourned or missed.  
You are a luser of the worst kind. To deny a man the right to blow  
off steam or to start insulting him because he does is just sick and  
wrong. So stop it. Now.


CL<
developers (in which case I will stop financially supporting the  
project,

and everyone else should too) or you recognise that what really keeps
OpenBSD going is the group of people that advocate OpenBSD, use it  
in the
real world, and buy your goddamn CDs and t-shirts to keep you  
going... The
idiots on misc that support you when you treat your users this  
badly aren't

the real friends of OpenBSD.




They do not preach that their God will rouse them a little before the  
nuts work loose.

iD8DBQFF/Fwj5B7p9jYarz8RAjjLAJ4ockK+w3JFQQtCdeaZ0XvAuawU9QCgoOPm
gql5uZkp9G58bxHcork=
=by3C
-END PGP SIGNATURE-

Re: Important OpenBSD errata

[Deanna Phillips]

Ray Percival writes:

> No. Everybody with a clue knows that there is two sources for
> good data. The errata page and source-changes.

I'd like to add undeadly's RSS here, since I don't think anyone
has mentioned it yet.  There are two RSS feeds that would have
alerted people to this: one for stories themselves (and we
published the story as soon as that erratum went in) and one for
errata in general.

http://undeadly.org/cgi?action=rss
http://undeadly.org/cgi?action=errata

Well, *I* think it's a reliable source.  :)

Re: Important OpenBSD errata

[Theo de Raadt]

> I get a kick out of people who are too slack to spend the two hours
> of reading and twenty minutes of unattended execution time it takes
> to CVS or patch a kernel and compile it.

Some of these people clearly think they are entitled.

But they are not entitled.  Nothing entitles them to anything.  There
is no contract, there is no promise, there is nothing, nothing,
nothing, and nothing.

They should just be thankful.

If they continue to be so rude, they'll get less.  They won't get more
-- they'll get less.  It's not human nature to give more to jerks.

Re: Important OpenBSD errata

[Ben Calvert]

christ.
buddha.

the thread that would not die.

i invoke godwins law in a (probably ) unsuccessful attempt to end the  
insanity:

nazi nazi holocaust, nazi.



On Mar 17, 2007, at 12:09 PM, Karel Kulhavy wrote:


[demime 1.01d removed an attachment of type application/pkcs7-signature which 
had a name of smime.p7s]

Re: Important OpenBSD errata

[Karel Kulhavy]

On Sat, Mar 17, 2007 at 11:43:47AM +1100, fonkprop wrote:
> Yet again, we see that although Theo is willing to beg, wheedle and threaten
> his user community into sending him money when he needs it, he holds them in
> too much contempt to respond to simple, uncontroversial and valid criticism.
> 
> 
> On 3/16/07, Theo de Raadt <[EMAIL PROTECTED]> wrote:
> 
> >
> > Let's see... the fsck_ffs fix pedro commited a few hours ago.  That
> > fixes a serious problem where fsck fails to spot filesystem
> > corruption.  Should we spend time fully assessing how rare or common
> > this situation is, and then errata it up the stream as fast as
> > possible, maybe even consider if there are security risks from such
> > filesystem corruption?  Come on.
> 
> 
> What a bullshit argument. When you realised the problem was serious enough
> to update the homepage to say "only two remote holes..." you should also
> have sent out an email to security-announce. You had time to send an
> announcement to misc - not sending one to the list your project specifically
> created for just this type of situation means, quite simply, that you fucked
> up. You fucked up, Theo. Do it right next time, or de-commission the
> security-announce mailing list for once and for all. The fact that you can't
> get a simple thing like this right really makes me wonder about the wisdom
> of relying on OpenBSD for real-world use...
> 
> The minute someone moans for a posting to the security-announce list
> > they have removed any desire from me to do so.  And the same comes for
> > any other errata.
> 
> 
> What a completely fucking stupid, border-line insane thing to say. Let's get
> this straight - your project sets up a security announcement list
> specifically for announcements on vulnerabilities and patches. You then
> proceed to ignore it completely for one of the most serious OpenBSD security
> problems in the last decade. But no-one is allowed to actually say anything
> about this because if they do you'll not use it JUST TO SPITE US. You, sir,
> are a childish, immature cock.
> 
> 
> > If people on our mailing list are going to be such jerks about patches
> > which we do make available, then maybe we'll spend a whole lot less
> > effort making errata and updating -stable.  The whole concept of being
> > subserviant towards a community of jerks is not realistitic.
> 
> 
> You know, Theo, it makes me fucking sick to see you treat the community of
> people who support your project and pay your wage like this. It makes me
> even sicker to see the crowds of shrill, stupid fanboys on this list who are
> so pathetically eager to agree with you that that they support even your
> most unreasonable, childish and frankly stupid statements. You are a goddam
> hypocrite - either you do OpenBSD purely for yourself and the other

I don't think Theo is a hypocrite he makes otherwise a highly consistent
behaviour impression on me. To me it looks like a slippage caused by an
external factor. There's a problem and it has to be found and fixed.

Theo, how much time do you sleep in average per night? Aren't you overworked?
Don't you have some kind of family problem (relationship, death, serious
disease)?  Don't you you get too little money in donations and feel stressed by
it?  Or some other kind of cockup in your life?

We need to understand that OpenBSD is a unique operating system - it's free,
very complicated, AND and proper care is taken in design and programming. That
must be very demanding on the developers.

CL<
> developers (in which case I will stop financially supporting the project,
> and everyone else should too) or you recognise that what really keeps
> OpenBSD going is the group of people that advocate OpenBSD, use it in the
> real world, and buy your goddamn CDs and t-shirts to keep you going... The
> idiots on misc that support you when you treat your users this badly aren't
> the real friends of OpenBSD.

Re: Important OpenBSD errata

[Woodchuck]

On Fri, 16 Mar 2007, Darren Spruell wrote:

> On 3/16/07, Martin Schrvder <[EMAIL PROTECTED]> wrote:
> [snip blah blah blah...]
> 
>   I want
> everyone trying to make that point to think of all the software
> vendors they deal with, including the commercial software vendors to
> whom you pay thousands (and depending on the size of your
> organization, millions) of dollars to per year. Can you say that you
> get SMTP notifications from all of them? The answer, if you're in any
> situation resembling what I've been in for the last decade, is no. 

To focus this even more, I managed some VAX/VMS machines in the
1980's, supporting about a half dozen aero engineers and programmers.
The software support contract for VMS ran me around 5-7 thousand
USD a year, in the dollars of the day, say $15K/yr in current money,
which got us mailed magtapes when there were bug fixes or new
versions, and great boxes of paper when the documentation changed.
This was not the most extreme level of support available, which
would have included a field engineer to come around and patch the
systems within 24 hrs or such.  This did not include support for
such extras as the Fortran, C or Pascal compilers or other "fluff".
This did not include the VMS license itself, just the support on
it.  And, at that time, Digital was considered a responsive,
cost-effective solution, and it was.

With OpenBSD, I get a system that is at least as robust, much more
capable, but with support that fixes bugs before I hear of them.
(And I listen.)  I get this for almost nothing.  Digital actually
warranteed their software (unheard of these days, at least in the
PeeCee world), i.e. if it didn't work, you'd get it fixed, and
quickly.  OpenBSD doesn't warrantee anything, but they fix things
as fast as Digital used to (24-48 hrs).

Did I mention what a VAX/VMS source code license cost?  I seem to
recall 100K$ being mentioned.

I get a kick out of people who are too slack to spend the two hours
of reading and twenty minutes of unattended execution time it takes
to CVS or patch a kernel and compile it.  I would have killed to
have the VMS kernel sources.

Dave

Re: Important OpenBSD errata

[Jason George]

>> > Free Software:  "You don't pay back, you pay forward."
>> >   -- Robert A. Heinlein
>> 
>> I was trying to decide if I should reply, and if so, how.
>> 
>> I looked for your name on the donations list.  I don't see it.
>
>Out of curiosity, when I bought several t-shirts at the kd85 shop in Belgium,
>does actually a part of it go to the donations list and do I pop there up with
>few dollars?
>
>I also suggest that the list include the cumulative amount for each donor,
>sorted so that the biggest donors are at the top.

You are assuming that all things revolve around $$$.  What about 
gifts-in-kind?  There are instances where donations of professional services 
which have benefitted the project could easily (and significantly) outrank 
large cash donations.  What's the book value of someone who donated hardware 
and provides the impetus to make new ports or to fix support for esoteric 
hardware?  These things do not lend themselves to a linear scale of ranking.  
Thanks for being a jerk and attempting to marginalize the work done by a large 
number of people over the last 12+ years.  Oh wait, that's what the donations 
list is... a list of who helped, roughly in order.

>Personally, it would motivate me more. I would have a feeling of control what's
>actually done with my money. If Theo somehow published some breakdown of the
>spending, even better. If he actually assigned my donation to a concrete thing
>(i. e. Packet filter development,...), that would be even better. 
>
>I would also have a motivation to compete for the topmost positions, with
>sending money as my weapon :) I could boast to my friends look I paid xxx of
>OpenBSD and I am the xth biggest donor and the packet filter you are using is
>actually paid from that.

Unless you're talking about Canadian or American monetary figures starting in 
the mid-5-digits, there's no way you'll be able to start to claim any form of 
significant sponsorship of any major new OpenBSD subsystem.

Some donations actually go directly to paying for costs incurred in specific 
areas.  Unfortunately, small donations might only go to paying for a portion 
of something.  There are a number of recent examples of fund raising drives to 
get a particular piece of gear to a certain developer.  People make donations 
for various reasons, but I've never heard of anyone wanting to claim that they 
ensured that the air baffles and extra power cable were in their name.

>People are not computers, they decide based on emotions, and if you tune the
>psychological aspect of the thing you can induce better emotions without
>actually compromising your ideology.  If other people think the same way like
>me, then Theo would start getting more donations if he changed to that system. 

People buying things due to emotion alone is a recipe for a potential mess 
over the long-term.  I won't go into a treatise on personal consumer debt and 
the fundamental motivations behind why people make decisions that are mostly 
clearly non-optimal.

People who use OpenBSD and are active donors are more likely to be heavily 
rational and understand implicitly why they are putting money into the 
coffers.

>Sometimes I wonder how much money goes to paying Theo's time, how much into
>paying other people like artists, how much into buying hardware, and if
>something of that isn't actually financed in an inefficient way. If I saw the
>real numbers, these concerns would probably vanish.


Wow.  It's like you're doing due diligence work before purchasing a company.  
The issue is that OpenBSD isn't a company.  It's essentially uses a finance 
model that is most easily described as "cost recovery".  There isn't a lot of 
surplus in the finances.  If extras exist, they are redeployed, akin to a 
re-investment of profit in a company.

This isn't Redhat, which is fully commercialized.  There aren't fancy offices 
with frosted glass.  There aren't receptionists.  There's no mailroom.  
Actually, I'd suggest that the vast majority of open source projects are 
decidedly NOT like Redhat.  They are still principally volunteer-run with a 
smattering of people who derive some form of salary or monetary remuneration.

I'm going to explicitly use a portion of the script from "A Few Good Men", a 
1992 movie with Tom Cruise and Jack Nicholson.  It clearly doesn't map 
directly and completely to OpenBSD but there are significant number of 
parallels in the words spoken by Nicholson's character that equally apply.
If I need to explain what applies, then there are bigger problems.  The 
references should be pretty much intuitively obvious.

Col. Jessep: Son, we live in a world that has walls, and those walls have to be 
guarded by men with guns. Whose gonna do it? You? You, Lt. Weinburg? I have a 
greater responsibility than you could possibly fathom. You weep for Santiago, 
and you curse the marines. You have that luxury. You have the luxury of not 
knowing what I know. That Santiago's death, while tragi