Hi!
> 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
Hi!
> 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
Hi,
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.
-j.
--
+358-404-177133 (WhatsApp)
jyri.hov...@turvamies.fi
Hello everyone!
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.
Really?
"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
Hi everyone!
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
Hi again!
>> Wipe your build directory and try again. Most likely it has some
>> cache files from a previous autoconf run (mincore recently moved to
>> libc).
> 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
Hi!
> Wipe your build directory and try again. Most likely it has some
> cache files from a previous autoconf run (mincore recently moved to
> libc).
You were spot on: rm -rf /usr/xenocara/* fixed it.
Thank you!
- Jyri
Hi!
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
0
C Finland
P Kymenlaakso
T Kouvola
Z 46900
O Turvamies tietoturvapalvelut (Turvamies IT Security Services)
I Jyri Hovila
A Opistonkuja 1
M i...@turvamies.fi
U https://turvamies.fi/
B +358-404-177133
X n/a
N Finnish specialists in OpenBSD based servers, firewalls and secure
communications
> 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.
Again: "how
>> 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
This
Hi!
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
Hi!
When compiling the latest CURRENT (CVS last synced ca. 6 hours ago), the build
crashes due to games/glorkz:
...
===> games
===> games/adventure
cc -O2 -pipe -Werror-implicit-function-declaration -MD -MP -c
Hi,
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
breaking down.
That said, I
Hi everyone!
There used to be a project called GreenOS, with plans on creating a FreeBSD
based OS for Android devices:
https://www.freebsdnews.com/2012/07/09/greenos-freebsd-based-project-android-devices/
Has anybody here had plans (or tried out?) hacking OpenBSD into some old,
rootable
Hi,
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
benefit
Hi again,
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
Hi!
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
Xenocara.
For now, I've simply clocked
20 matches
Mail list logo
