> Thanks, and sorry I missed in your previous mail that things were working
> OK before. In which case it doesn't sound like a configuration problem
> which I wasn't sure about.
Thank you for helping in the debugging, and no need for apologies!
> Do you have any logs that might help tie it
> Look at pfctl -ss -v. Do you have "wscale" values printed for most
> TCP connections?
There's wscale for all the active connections, at least at the moment.
> If not then you are likely creating state on intermediate
> rather than ACK packets (window scaling values are not present in most
there was a stupid little typo in the pf rules I sent: the ssh port is
obvioulys 22, not 20. That was just a typo in the e-mail, not on the server.
Now here's a mysterious one -- I've been working on this for weeks and still
have no clue what's causing it.
I have couple of virtual servers, running *the* latest 64-bit snapshots.
They're backed up using rsync over ssh. For a long time (months / years)
everything was working
> I don't think OpenBSD wants to "profile itself" as anything.
"Our efforts emphasize portability, standardization, correctness, proactive
security and integrated cryptography."
Don't you think the above statement signifies profiling?
IMHO, proactive security could very well include
The world is talking about Google's claimed break-through in quantum computing.
Even if their achievement is real or not, the fact is, that some day relatively
soon "we" (starting from mega corporations and government agencies) will have a
functional quantum computer in their
> And since you are doing this with -current *ALL OVER THE PLACE*
> there are instructions that if you have trouble you should upgrade
> to a snapshot.
Theo, with all due respect, there are many situations where upgrading to a
snapshot really isn't an option.
> Those instructions to exist the
>> Wipe your build directory and try again. Most likely it has some
>> cache files from a previous autoconf run (mincore recently moved to
> You were spot on: rm -rf /usr/xenocara/* fixed it.
The above is incorrect.
Obviously, what I did was rm -rf /usr/xobj/*
My brain is
> Wipe your build directory and try again. Most likely it has some
> cache files from a previous autoconf run (mincore recently moved to
You were spot on: rm -rf /usr/xenocara/* fixed it.
Anybody else having this issue with compiling CURRENT Xenocara?
/usr/xenocara/lib/mesa/src/egl/main/eglglobals.c:166:8: error: implicit decla
ration of function 'mincore' is invalid in C99
O Turvamies tietoturvapalvelut (Turvamies IT Security Services)
I Jyri Hovila
A Opistonkuja 1
N Finnish specialists in OpenBSD based servers, firewalls and secure
> It's not a shortcut,
This, as many things in this world, completely depend on the point of view.
One can not simply say "this is this" or "this is not this", without sufficient
background information and overall understanding of the situation as a whole.
> it is how it's done.
>> rebuild a new kernel, *reboot*, and next launch your make build.
> That is the wrong advice. it is too precise and may still fail.
> The correct advice is: Upgrade to a snapshot.
> That is always the correct advice.
Theo, as an Asperger, I just love how you communicate yourself! =D
Theo: > Upgrade to from a snap.
Thanks, but: NO! XD
Seriously: As crazy as it may sound, I'm very stubborn about following the
CURRENT without taking shortcuts.
Theo: > Not worth explaining what went wrong...
I know that feeling from my personal life. =D
Sebastian: > rebuild a new
When compiling the latest CURRENT (CVS last synced ca. 6 hours ago), the build
crashes due to games/glorkz:
cc -O2 -pipe -Werror-implicit-function-declaration -MD -MP -c
and thanks for the input!
I now (re)understand the reason to compiling the kernel, the userland and
Xenocara in a single-thread fashion is obviously the correct way, at least when
it comes to doing things properly, minimizing the potential for anything
That said, I
There used to be a project called GreenOS, with plans on creating a FreeBSD
based OS for Android devices:
Has anybody here had plans (or tried out?) hacking OpenBSD into some old,
just for the record, and to inform others who may still be at loss regarding
this matter: when compiling stuff (particularly Big Stuff, such as the
userland) on an OpenBSD machine with several CPU cores, it's important to pass
the '-j ' argument to the make command, in order to
to elaborate a bit, the reason I'm interested in getting more detailed
benchmark results for the build processes is that I've noticed there are many
situations where servers with less hardware resources (CPU cores and RAM in
particular) often seem to finish the builds quite a lot
I have a handful of OpenBSD (CURRENT) instances, running on different VPS and
full iron platforms.
Since I use CURRENT, keeping up to date means I have the opportunity to watch
and compare the build process durations of the kernel, the userland, and
For now, I've simply clocked
Mail list logo