Re: How to use proot?

[Xiyue Deng]

Marc Espie  writes:

> On Mon, Dec 30, 2019 at 01:11:51PM -0800, Xiyue Deng wrote:
>> (Adding misc@openbsd.org back to CC.)
>> 
>> Marc Espie  writes:
>> 
>> > Just have your ports tree checked out under your mount point.
>> > Next time it will be much faster ;)
>> 
>> Unfortunately my loongson box is extremely slow in both CPU and disk
>> performances and a CVS update usually takes same amount of time.  But
>> it should be faster on more modern systems.
>
> Do you have an amd64 box around ? using it as an NFS server might be
> less painful for some things...

Currently no.  But it's OK as I'm not using the Loongson box for
anything serious yet, just try to see how well OpenBSD works on it as
it's currently the only OS that officially support Loongson that's not
ancient, and so far it's much better than 6.5.


signature.asc
Description: PGP signature

Re: Suggestion: Replace Perl with Lua in the OpenBSD Base System

[Theo de Raadt]

Marc Espie  wrote:

> Removing perl from base would be very painful.
> 
> I don't fancy rewriting all the perl tools in something else (specifically,
> most of the ports and package infrastructure)
> 
> lua would definitely NOT be appropriate for that. The only half valid
> candidate would be python.
> 
> Contrary to what some people might think, the tools in question won't be
> easier to understand and manage if written in another language.
> 

Contrary to what you think, the original proposal didn't come out of
a process called thinking.

Re: Suggestion: Replace Perl with Lua in the OpenBSD Base System

[Marc Espie]

Removing perl from base would be very painful.

I don't fancy rewriting all the perl tools in something else (specifically,
most of the ports and package infrastructure)

lua would definitely NOT be appropriate for that. The only half valid
candidate would be python.

Contrary to what some people might think, the tools in question won't be
easier to understand and manage if written in another language.

Re: Blank/black screen for 6.6 - any general debugging hints?

[Bodie]

On 30.12.2019 19:07, lu hu wrote:

Hello,

I was using 6.5 on a desktop PC.

I did a sysupgrade, but after the blue boot text, I only get 
black/blank screen.


I don't think it is just the screen, since I cannot reach it via 
network.


I booted the 6.6 bsd.rd then did a clean install with 6.6. The same 
issue.


I downloaded the 6.5 bsd.rd/sets and clean installed it. IT WORKED! 
YAY!!!


So looks like, there is some issue with 6.6 on my HW.

So I will probably skip 6.6 on this HW and hope 6.7 will work :)


BUT:

I didn't found any MAN pages, DOCs, how to troubleshoot these kind of
black/blank screen boot issues.

Any hints in general, what can I do next time to avoid a clean install
of the older major version?

Many thanks and wishing peaceful holidays!


https://www.openbsd.org/report.html

Re: How to use proot?

[Marc Espie]

On Mon, Dec 30, 2019 at 01:11:51PM -0800, Xiyue Deng wrote:
> (Adding misc@openbsd.org back to CC.)
> 
> Marc Espie  writes:
> 
> > Just have your ports tree checked out under your mount point.
> > Next time it will be much faster ;)
> 
> Unfortunately my loongson box is extremely slow in both CPU and disk
> performances and a CVS update usually takes same amount of time.  But
> it should be faster on more modern systems.

Do you have an amd64 box around ? using it as an NFS server might be
less painful for some things...

Re: The OpenBSD talk at 36c3

[gbcd]

Case in point: commit messages. as claudio proved, he posited inaccurate 
and

blatantly false assertions that any objective researcher would immediately
realize is obviously wrong but because he's seeking data that confirms his
preconceived notion that "HUR DUR OPENBSD BAD!" he completely misses the 
mark.

rather than think "hmm 75% of commits are only 20 chars or less which seems
unusual let's take a closer look" he shouts "HAH I KNEW IT! OPENBSD d3vZ 
sUx0r!"
classic confirmation bias. my pops, god bless his soul, used to say the way 
you
do one thing is the way you do everything. and the way this kid shows his 
true
colors with this example is the way he approached this whole eisegetic 
charade:
subjectively. and with the burning desire to make you see OpenBSD the way 
he
_feels_ about OpenBSD. not how it is. not what it does or doesn't do. not 
the
uniformly positive experience by its userbase. just how those notoriously 
mean
badguys made him feel that time he kept submitting ports that were rejected 
for
not being up to standard. he made numerous spurious remarks with no 
evidence to
support their veracity. and childish criticisms of development practices 
simply

because he doesn't like it not for any objectively quantifiable metrics of
quality or productivity or security. it really vexes him that OpenBSD 
doesn't
use github and patchwork doesn't it. the only real interest i have in the 
talk
is what exactly was it that hurt him so much that he harbors all this 
resentment
and bitterness. its obvious he's upset because if he had any genuine desire 
to
empower and help people like he said he would make efforts to improve 
something

he saw he could improve rather than spread FUD


At moment, I want my privacy to be protected.
https://mytemp.email/

Re: Hyperbola Gnu Linux changing to Bsd

[Ian Darwin]

On Mon, 30 Dec 2019 at 19:57, Nick Holland  
wrote:

most of them are stupid words.  I just spot checked one of the
"license problems" they think they spotted in the OpenBSD tree.

http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/arch/landisk/include/endian.h?rev=1.2

What exactly are they planning on licensing in that?


I think they've scheduled a half-day committee meeting about that one 
file next week :-)


Remember the history of /bin/false.  History can repeat itself.

Re: Hyperbola Gnu Linux changing to Bsd

[Constantine A. Murenin]

>> https://notabug.org/jadedctrl/libertybsd-scripts-mirror/issues/5

On Mon, 30 Dec 2019 at 19:57, Nick Holland  wrote:
> most of them are stupid words.  I just spot checked one of the
> "license problems" they think they spotted in the OpenBSD tree.
>
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/arch/landisk/include/endian.h?rev=1.2
>
> What exactly are they planning on licensing in that?

Seriously?  Did they somehow miss all of our Makefiles?  None of which
have an appropriate licence header, either?

I think they're toast!

C.

Re: Suggestion: Replace Perl with Lua in the OpenBSD Base System

[Roderick]

On Mon, 30 Dec 2019, Theo de Raadt wrote:

>  wrote:
> 
> > A smaller base afforded to by Lua will reduce the
> > attack surface and complexity of the OpenBSD project as a whole.
> 
> 1) I think that is a baseless and irrelevant claim.
> 
> 2) No.

It is not about the claim, he is trying to sell lua, because lua should be
everywhere, also in the bootloader (they bloated FreeBSDs bootloader by
substituting forth with lua), also in tex, you are forced to install
luatex with the bloat of "texlive".

Lua means moon, from latin luna. Lua phanatics should be called lunatics.

But there is also some python phanaticism. It is a scripting language
more, the only new (horrible) thing seems to be that indentation has 
a meaning, it contains the whole tcl/tk as "tkinter"  that alone 
should be enough for reasonable scripting.

Rodrigo.

Re: Hyperbola Gnu Linux changing to Bsd

[Nick Holland]

On 2019-12-30 14:31, SOUL_OF_ROOT 55 wrote:
...
> What are the opinions of the OpenBSD developers about Hiperbola GNU/Linux?

Just my opinion...

A linux distribution (repacking other people's stuff) that I never
heard of is going to abandon their old work and users in favor of
actually making a new operating system, which will involve actually
making code and making it work "some day".  What could go wrong?

Other than their rather twisted definition of "free", which has
been sufficiently hashed and rehashed, I don't see anything there
to think about.  There's no product.  Just a lot of words.  And
most of them are stupid words.  I just spot checked one of the
"license problems" they think they spotted in the OpenBSD tree.

http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/arch/landisk/include/endian.h?rev=1.2

What exactly are they planning on licensing in that?

When they have something to show...let's be real, I'll probably
ignore that, too.  There's nothing about their goals and
objectives that interests me at all.

Nick.

Re: [own Kernel] LSI megaraid on rkpcie device.

[Olivier]

On Mon, 30 Dec 2019 16:58:22 -0700
"Theo de Raadt"  wrote:

> Olivier  wrote:
> 
> > Hello all,
> > 
> > In first, i would like to wish you happy new year celebrations !
> > 
> > in second i am not developper / hacker. I would like to compile and use a 
> > LSI megaraid adaptater on arm64 (RP64).
> > 
> > In this way i updated /sys/arch/arm64/conf/GENERIC to add a LSI MEGARAID 
> > adaptater
> > mpi*at pci? # LSI Logic Fusion MPT Message Passing 
> > Interface
> > mpii*   at pci? # LSI Fusion MPT Message Passing Interface 
> > II
> > mfi*at pci? # LSI MegaRAID SAS controllers
> > mfii*   at pci? # LSI MegaRAID SAS Fusion controller
> > 
> > 
> > I thank that was sufficient... Maybe too simple to copy paste from i386 
> > conf file... :
> > 
> > Question : Do i have to do something specific to include the drivers mpi* 
> > and fmi* on arch compilation ?
> > 
> > (...)
> > cc -g -Werror -Wall -Wimplicit-function-declaration  -Wno-uninitialized 
> > -Wno-pointer-sign  -Wno-constant-conversion
> > -Wno-address-of-packed-member  -Wframe-larger-than=2047 
> > -march=armv8-a+nofp+nosimd  -fno-omit-frame-pointer 
> > -mno-omit-leaf-frame-pointer
> > -ffixed-x18 -ffreestanding -fno-pie -O2 -pipe -nostdinc -I/sys 
> > -I/sys/arch/arm64/compile/GENERIC.MP/obj -I/sys/arch
> > -I/sys/dev/pci/drm/include  -I/sys/dev/pci/drm/include/uapi  
> > -I/sys/dev/pci/drm/amd/include/asic_reg  -I/sys/dev/pci/drm/amd/include
> > -I/sys/dev/pci/drm/amd/amdgpu  -I/sys/dev/pci/drm/amd/display  
> > -I/sys/dev/pci/drm/amd/display/include  -I/sys/dev/pci/drm/amd/display/dc
> > -I/sys/dev/pci/drm/amd/display/amdgpu_dm  
> > -I/sys/dev/pci/drm/amd/powerplay/inc  
> > -I/sys/dev/pci/drm/amd/powerplay/smumgr
> > -I/sys/dev/pci/drm/amd/powerplay/hwmgr  
> > -I/sys/dev/pci/drm/amd/display/dc/inc  
> > -I/sys/dev/pci/drm/amd/display/dc/inc/hw
> > -I/sys/dev/pci/drm/amd/display/modules/inc -DDDB -DDIAGNOSTIC -DKTRACE 
> > -DACCOUNTING -DKMEMSTATS -DPTRACE -DCRYPTO -DSYSVMSG -DSYSVSEM
> > -DSYSVSHM -DUVM_SWAP_ENCRYPT -DFFS -DFFS2 -DFFS_SOFTUPDATES -DUFS_DIRHASH 
> > -DQUOTA -DEXT2FS -DMFS -DNFSCLIENT -DNFSSERVER -DCD9660 -DUDF
> > -DMSDOSFS -DFIFO -DFUSE -DSOCKET_SPLICE -DTCP_ECN -DTCP_SIGNATURE -DINET6 
> > -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DPIPEX -DMROUTING -DMPLS
> > -DBOOT_CONFIG -DPCIVERBOSE -DUSER_PCICONF -DUSBVERBOSE 
> > -DWSDISPLAY_COMPAT_USL -DWSDISPLAY_COMPAT_RAWKBD 
> > -DWSDISPLAY_DEFAULTSCREENS="6"
> > -DONEWIREVERBOSE -DMULTIPROCESSOR -DMAXUSERS=80 -D_KERNEL -D__arm64__ -MD 
> > -MP  -c /sys/dev/pci/nvme_pci.c
> > cc -g -Werror -Wall -Wimplicit-function-declaration  -Wno-uninitialized 
> > -Wno-pointer-sign  -Wno-constant-conversion
> > -Wno-address-of-packed-member  -Wframe-larger-than=2047 
> > -march=armv8-a+nofp+nosimd  -fno-omit-frame-pointer
> > -mno-omit-leaf-frame-pointer
> > -ffixed-x18 -ffreestanding -fno-pie -O2 -pipe -nostdinc -I/sys 
> > -I/sys/arch/arm64/compile/GENERIC.MP/obj
> > -I/sys/arch -I/sys/dev/pci/drm/include  -I/sys/dev/pci/drm/include/uapi  
> > -I/sys/dev/pci/drm/amd/include/asic_reg
> > -I/sys/dev/pci/drm/amd/include -I/sys/dev/pci/drm/amd/amdgpu  
> > -I/sys/dev/pci/drm/amd/display  -I/sys/dev/pci/drm/amd/display/include
> > -I/sys/dev/pci/drm/amd/display/dc -I/sys/dev/pci/drm/amd/display/amdgpu_dm  
> > -I/sys/dev/pci/drm/amd/powerplay/inc
> > -I/sys/dev/pci/drm/amd/powerplay/smumgr 
> > -I/sys/dev/pci/drm/amd/powerplay/hwmgr  
> > -I/sys/dev/pci/drm/amd/display/dc/inc
> > -I/sys/dev/pci/drm/amd/display/dc/inc/hw 
> > -I/sys/dev/pci/drm/amd/display/modules/inc -DDDB -DDIAGNOSTIC -DKTRACE 
> > -DACCOUNTING
> > -DKMEMSTATS -DPTRACE -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM 
> > -DUVM_SWAP_ENCRYPT -DFFS -DFFS2 -DFFS_SOFTUPDATES -DUFS_DIRHASH -DQUOTA
> > -DEXT2FS -DMFS -DNFSCLIENT -DNFSSERVER -DCD9660 -DUDF -DMSDOSFS -DFIFO 
> > -DFUSE -DSOCKET_SPLICE -DTCP_ECN -DTCP_SIGNATURE -DINET6 -DIPSEC
> > -DPPP_BSDCOMP -DPPP_DEFLATE -DPIPEX -DMROUTING -DMPLS -DBOOT_CONFIG 
> > -DPCIVERBOSE -DUSER_PCICONF -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL
> > -DWSDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_DEFAULTSCREENS="6" -DONEWIREVERBOSE 
> > -DMULTIPROCESSOR -DMAXUSERS=80 -D_KERNEL -D__arm64__ -MD -MP
> > -c /sys/dev/pci/mfi_pci.c
> > 
> > In file included from /sys/dev/pci/mfi_pci.c:37:
> > /sys/dev/ic/mfivar.h:190:20: error: field has incomplete type 'struct 
> > ksensordev'
> > struct ksensordev   sc_sensordev;
> > ^
> > /sys/dev/ic/mfivar.h:190:9: note: forward declaration of 'struct ksensordev'
> > struct ksensordev   sc_sensordev;
> >^
> > 1 error generated.
> > *** Error 1 in /sys/arch/arm64/compile/GENERIC.MP (Makefile:1206 
> > 'mfi_pci.o')
> > 
> > 
> > Thanks in advance.
> 
> Many of our architectures have a per-cpu sensor device.  As a result, such
> an architecture will #include  in .  Other
> architectures skip doing this, and you've just exposed a driver which doesn't
> pull in 

Re: Blank/black screen for 6.6 - any general debugging hints?

[Tom Smyth]

Hi Lu,

at a guess it could be that your hardware needs a  graphics driver
that requires root to run...
since the Xorg security bug ...
OpenBSD dont support graphics drivers that require root privileges to run...
(or something like that) ...
as Christer suggested...  dmesgs need to be included in requests
/feedback (especially about hardware)
hope this helps,

On Mon, 30 Dec 2019 at 18:23, lu hu  wrote:
>
> Hello,
>
> I was using 6.5 on a desktop PC.
>
> I did a sysupgrade, but after the blue boot text, I only get black/blank 
> screen.
>
> I don't think it is just the screen, since I cannot reach it via network.
>
> I booted the 6.6 bsd.rd then did a clean install with 6.6. The same issue.
>
> I downloaded the 6.5 bsd.rd/sets and clean installed it. IT WORKED! YAY!!!
>
> So looks like, there is some issue with 6.6 on my HW.
>
> So I will probably skip 6.6 on this HW and hope 6.7 will work :)
>
>
> BUT:
>
> I didn't found any MAN pages, DOCs, how to troubleshoot these kind of 
> black/blank screen boot issues.
>
> Any hints in general, what can I do next time to avoid a clean install of the 
> older major version?
>
> Many thanks and wishing peaceful holidays!
>


-- 
Kindest regards,
Tom Smyth.

Re: Suggestion: Replace Perl with Lua in the OpenBSD Base System

[Xiyue Deng]

 writes:

> Hi,
>
> I'd like to bring up the following suggestion:
>
> Would it be desirable for the OpenBSD project to replace Perl with Lua
> in the base system? A smaller base afforded to by Lua will reduce the
> attack surface and complexity of the OpenBSD project as a whole.
>
>   The source contains around 24000 lines of C. Under 64-bit Linux, the
>   Lua interpreter built with all standard Lua libraries takes 247K and
>   the Lua library takes 421K. - https://www.lua.org/about.html
>
>   Lua is free open-source software, distributed under a very liberal
>   license (the well-known MIT license).
>   - https://www.lua.org/about.html
>
> I recognize that this will involve a massive multi-year undertaking and
> I'd like to be part of the effort if it were to arise.
>
> Cheers,
> ansimita

I'm not an OpenBSD developer.  But as we are on this subject, IMHO if
Perl is to be replaced it's better to be Python to take its place, which
also has a very liberal license (BSD-style PSFL) and more importantly
has a massive user base.


signature.asc
Description: PGP signature

Re: Suggestion: Replace Perl with Lua in the OpenBSD Base System

[Edgar Pettijohn]

On 2019-12-30 18:07, ansim...@tutanota.com wrote:

Hi,

I'd like to bring up the following suggestion:

Would it be desirable for the OpenBSD project to replace Perl with Lua
in the base system? A smaller base afforded to by Lua will reduce the
attack surface and complexity of the OpenBSD project as a whole.

   The source contains around 24000 lines of C. Under 64-bit Linux, the
   Lua interpreter built with all standard Lua libraries takes 247K and
   the Lua library takes 421K. - https://www.lua.org/about.html

   Lua is free open-source software, distributed under a very liberal
   license (the well-known MIT license).
   - https://www.lua.org/about.html

I recognize that this will involve a massive multi-year undertaking and
I'd like to be part of the effort if it were to arise.

Cheers,
ansimita



I like lua as a whole, however it isn't extremely useful for system 
administration tasks.


Which I believe is likely the reason for Perl's inclusion.


Edgar

Re: Suggestion: Replace Perl with Lua in the OpenBSD Base System

[ansimita]

Hi Theo,

Noted.

Thanks for the consideration,
ansimita

Dec 31, 2019, 00:15 by dera...@openbsd.org:

>  wrote:
>
>> A smaller base afforded to by Lua will reduce the
>> attack surface and complexity of the OpenBSD project as a whole.
>>
>
> 1) I think that is a baseless and irrelevant claim.
>
> 2) No.
>

Re: Suggestion: Replace Perl with Lua in the OpenBSD Base System

[Theo de Raadt]

 wrote:

> A smaller base afforded to by Lua will reduce the
> attack surface and complexity of the OpenBSD project as a whole.

1) I think that is a baseless and irrelevant claim.

2) No.

Re: Suggestion: Replace Perl with Lua in the OpenBSD Base System

[Martin Schröder]

Am Di., 31. Dez. 2019 um 01:08 Uhr schrieb :
> Would it be desirable for the OpenBSD project to replace Perl with Lua
> in the base system? A smaller base afforded to by Lua will reduce the

IMNSHO no.

You are welcome to fork your OpenLuaBSD project, though.

Looking forward to your first release.

Best
Martin

Re: Hyperbola Gnu Linux changing to Bsd

[zap]

On 12/30/2019 04:19 PM, Ian Darwin wrote:
> On 12/30/19 15:02, Peter Nicolai Mathias Hansteen wrote:
>> The TL;DR version is that taking code or any other body of work that
>> is offered to you under a permissive license and making your changes
>> to it available only under a more restrictive one may be legal in
>> some or all jurisdictions, but it is most certainly a sign of an
>> almost total lack of respect for the people who did the original work.
>
> Not to mention: putting code under a more restrictive license than
> previously, while calling it "more free", is hypocrisy, pure and
> simple. Nothing gnu here, folks.
>
I would say it depends on your perspective, I think the reason he does
that is to make adding non-free software harder in the future.

Keep in mind, proprietary software can spy on you or cause privacy and
security issues... :/

Suggestion: Replace Perl with Lua in the OpenBSD Base System

[ansimita]

Hi,

I'd like to bring up the following suggestion:

Would it be desirable for the OpenBSD project to replace Perl with Lua
in the base system? A smaller base afforded to by Lua will reduce the
attack surface and complexity of the OpenBSD project as a whole.

  The source contains around 24000 lines of C. Under 64-bit Linux, the
  Lua interpreter built with all standard Lua libraries takes 247K and
  the Lua library takes 421K. - https://www.lua.org/about.html

  Lua is free open-source software, distributed under a very liberal
  license (the well-known MIT license).
  - https://www.lua.org/about.html

I recognize that this will involve a massive multi-year undertaking and
I'd like to be part of the effort if it were to arise.

Cheers,
ansimita

Re: [own Kernel] LSI megaraid on rkpcie device.

[Theo de Raadt]

Olivier  wrote:

> Hello all,
> 
> In first, i would like to wish you happy new year celebrations !
> 
> in second i am not developper / hacker. I would like to compile and use a LSI 
> megaraid adaptater on arm64 (RP64).
> 
> In this way i updated /sys/arch/arm64/conf/GENERIC to add a LSI MEGARAID 
> adaptater
> mpi*at pci? # LSI Logic Fusion MPT Message Passing 
> Interface
> mpii*   at pci? # LSI Fusion MPT Message Passing Interface II
> mfi*at pci? # LSI MegaRAID SAS controllers
> mfii*   at pci? # LSI MegaRAID SAS Fusion controller
> 
> 
> I thank that was sufficient... Maybe too simple to copy paste from i386 conf 
> file... :
> 
> Question : Do i have to do something specific to include the drivers mpi* and 
> fmi* on arch compilation ?
> 
> (...)
> cc -g -Werror -Wall -Wimplicit-function-declaration  -Wno-uninitialized 
> -Wno-pointer-sign  -Wno-constant-conversion
> -Wno-address-of-packed-member  -Wframe-larger-than=2047 
> -march=armv8-a+nofp+nosimd  -fno-omit-frame-pointer 
> -mno-omit-leaf-frame-pointer
> -ffixed-x18 -ffreestanding -fno-pie -O2 -pipe -nostdinc -I/sys 
> -I/sys/arch/arm64/compile/GENERIC.MP/obj -I/sys/arch
> -I/sys/dev/pci/drm/include  -I/sys/dev/pci/drm/include/uapi  
> -I/sys/dev/pci/drm/amd/include/asic_reg  -I/sys/dev/pci/drm/amd/include
> -I/sys/dev/pci/drm/amd/amdgpu  -I/sys/dev/pci/drm/amd/display  
> -I/sys/dev/pci/drm/amd/display/include  -I/sys/dev/pci/drm/amd/display/dc
> -I/sys/dev/pci/drm/amd/display/amdgpu_dm  
> -I/sys/dev/pci/drm/amd/powerplay/inc  -I/sys/dev/pci/drm/amd/powerplay/smumgr
> -I/sys/dev/pci/drm/amd/powerplay/hwmgr  -I/sys/dev/pci/drm/amd/display/dc/inc 
>  -I/sys/dev/pci/drm/amd/display/dc/inc/hw
> -I/sys/dev/pci/drm/amd/display/modules/inc -DDDB -DDIAGNOSTIC -DKTRACE 
> -DACCOUNTING -DKMEMSTATS -DPTRACE -DCRYPTO -DSYSVMSG -DSYSVSEM
> -DSYSVSHM -DUVM_SWAP_ENCRYPT -DFFS -DFFS2 -DFFS_SOFTUPDATES -DUFS_DIRHASH 
> -DQUOTA -DEXT2FS -DMFS -DNFSCLIENT -DNFSSERVER -DCD9660 -DUDF
> -DMSDOSFS -DFIFO -DFUSE -DSOCKET_SPLICE -DTCP_ECN -DTCP_SIGNATURE -DINET6 
> -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DPIPEX -DMROUTING -DMPLS
> -DBOOT_CONFIG -DPCIVERBOSE -DUSER_PCICONF -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL 
> -DWSDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_DEFAULTSCREENS="6"
> -DONEWIREVERBOSE -DMULTIPROCESSOR -DMAXUSERS=80 -D_KERNEL -D__arm64__ -MD -MP 
>  -c /sys/dev/pci/nvme_pci.c
> cc -g -Werror -Wall -Wimplicit-function-declaration  -Wno-uninitialized 
> -Wno-pointer-sign  -Wno-constant-conversion
> -Wno-address-of-packed-member  -Wframe-larger-than=2047 
> -march=armv8-a+nofp+nosimd  -fno-omit-frame-pointer
> -mno-omit-leaf-frame-pointer
> -ffixed-x18 -ffreestanding -fno-pie -O2 -pipe -nostdinc -I/sys 
> -I/sys/arch/arm64/compile/GENERIC.MP/obj
> -I/sys/arch -I/sys/dev/pci/drm/include  -I/sys/dev/pci/drm/include/uapi  
> -I/sys/dev/pci/drm/amd/include/asic_reg
> -I/sys/dev/pci/drm/amd/include -I/sys/dev/pci/drm/amd/amdgpu  
> -I/sys/dev/pci/drm/amd/display  -I/sys/dev/pci/drm/amd/display/include
> -I/sys/dev/pci/drm/amd/display/dc -I/sys/dev/pci/drm/amd/display/amdgpu_dm  
> -I/sys/dev/pci/drm/amd/powerplay/inc
> -I/sys/dev/pci/drm/amd/powerplay/smumgr 
> -I/sys/dev/pci/drm/amd/powerplay/hwmgr  -I/sys/dev/pci/drm/amd/display/dc/inc
> -I/sys/dev/pci/drm/amd/display/dc/inc/hw 
> -I/sys/dev/pci/drm/amd/display/modules/inc -DDDB -DDIAGNOSTIC -DKTRACE 
> -DACCOUNTING
> -DKMEMSTATS -DPTRACE -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM 
> -DUVM_SWAP_ENCRYPT -DFFS -DFFS2 -DFFS_SOFTUPDATES -DUFS_DIRHASH -DQUOTA
> -DEXT2FS -DMFS -DNFSCLIENT -DNFSSERVER -DCD9660 -DUDF -DMSDOSFS -DFIFO -DFUSE 
> -DSOCKET_SPLICE -DTCP_ECN -DTCP_SIGNATURE -DINET6 -DIPSEC
> -DPPP_BSDCOMP -DPPP_DEFLATE -DPIPEX -DMROUTING -DMPLS -DBOOT_CONFIG 
> -DPCIVERBOSE -DUSER_PCICONF -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL
> -DWSDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_DEFAULTSCREENS="6" -DONEWIREVERBOSE 
> -DMULTIPROCESSOR -DMAXUSERS=80 -D_KERNEL -D__arm64__ -MD -MP
> -c /sys/dev/pci/mfi_pci.c
> 
> In file included from /sys/dev/pci/mfi_pci.c:37:
> /sys/dev/ic/mfivar.h:190:20: error: field has incomplete type 'struct 
> ksensordev'
> struct ksensordev   sc_sensordev;
> ^
> /sys/dev/ic/mfivar.h:190:9: note: forward declaration of 'struct ksensordev'
> struct ksensordev   sc_sensordev;
>^
> 1 error generated.
> *** Error 1 in /sys/arch/arm64/compile/GENERIC.MP (Makefile:1206 'mfi_pci.o')
> 
> 
> Thanks in advance.

Many of our architectures have a per-cpu sensor device.  As a result, such
an architecture will #include  in .  Other
architectures skip doing this, and you've just exposed a driver which doesn't
pull in the headers it needs.

[own Kernel] LSI megaraid on rkpcie device.

[Olivier]

Hello all,

In first, i would like to wish you happy new year celebrations !

in second i am not developper / hacker. I would like to compile and use a LSI 
megaraid adaptater on arm64 (RP64).

In this way i updated /sys/arch/arm64/conf/GENERIC to add a LSI MEGARAID 
adaptater
mpi*at pci? # LSI Logic Fusion MPT Message Passing Interface
mpii*   at pci? # LSI Fusion MPT Message Passing Interface II
mfi*at pci? # LSI MegaRAID SAS controllers
mfii*   at pci? # LSI MegaRAID SAS Fusion controller


I thank that was sufficient... Maybe too simple to copy paste from i386 conf 
file... :

Question : Do i have to do something specific to include the drivers mpi* and 
fmi* on arch compilation ?

(...)
cc -g -Werror -Wall -Wimplicit-function-declaration  -Wno-uninitialized 
-Wno-pointer-sign  -Wno-constant-conversion
-Wno-address-of-packed-member  -Wframe-larger-than=2047 
-march=armv8-a+nofp+nosimd  -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
-ffixed-x18 -ffreestanding -fno-pie -O2 -pipe -nostdinc -I/sys 
-I/sys/arch/arm64/compile/GENERIC.MP/obj -I/sys/arch
-I/sys/dev/pci/drm/include  -I/sys/dev/pci/drm/include/uapi  
-I/sys/dev/pci/drm/amd/include/asic_reg  -I/sys/dev/pci/drm/amd/include
-I/sys/dev/pci/drm/amd/amdgpu  -I/sys/dev/pci/drm/amd/display  
-I/sys/dev/pci/drm/amd/display/include  -I/sys/dev/pci/drm/amd/display/dc
-I/sys/dev/pci/drm/amd/display/amdgpu_dm  -I/sys/dev/pci/drm/amd/powerplay/inc  
-I/sys/dev/pci/drm/amd/powerplay/smumgr
-I/sys/dev/pci/drm/amd/powerplay/hwmgr  -I/sys/dev/pci/drm/amd/display/dc/inc  
-I/sys/dev/pci/drm/amd/display/dc/inc/hw
-I/sys/dev/pci/drm/amd/display/modules/inc -DDDB -DDIAGNOSTIC -DKTRACE 
-DACCOUNTING -DKMEMSTATS -DPTRACE -DCRYPTO -DSYSVMSG -DSYSVSEM
-DSYSVSHM -DUVM_SWAP_ENCRYPT -DFFS -DFFS2 -DFFS_SOFTUPDATES -DUFS_DIRHASH 
-DQUOTA -DEXT2FS -DMFS -DNFSCLIENT -DNFSSERVER -DCD9660 -DUDF
-DMSDOSFS -DFIFO -DFUSE -DSOCKET_SPLICE -DTCP_ECN -DTCP_SIGNATURE -DINET6 
-DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DPIPEX -DMROUTING -DMPLS
-DBOOT_CONFIG -DPCIVERBOSE -DUSER_PCICONF -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL 
-DWSDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_DEFAULTSCREENS="6"
-DONEWIREVERBOSE -DMULTIPROCESSOR -DMAXUSERS=80 -D_KERNEL -D__arm64__ -MD -MP  
-c /sys/dev/pci/nvme_pci.c
cc -g -Werror -Wall -Wimplicit-function-declaration  -Wno-uninitialized 
-Wno-pointer-sign  -Wno-constant-conversion
-Wno-address-of-packed-member  -Wframe-larger-than=2047 
-march=armv8-a+nofp+nosimd  -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer
-ffixed-x18 -ffreestanding -fno-pie -O2 -pipe -nostdinc -I/sys 
-I/sys/arch/arm64/compile/GENERIC.MP/obj
-I/sys/arch -I/sys/dev/pci/drm/include  -I/sys/dev/pci/drm/include/uapi  
-I/sys/dev/pci/drm/amd/include/asic_reg
-I/sys/dev/pci/drm/amd/include -I/sys/dev/pci/drm/amd/amdgpu  
-I/sys/dev/pci/drm/amd/display  -I/sys/dev/pci/drm/amd/display/include
-I/sys/dev/pci/drm/amd/display/dc -I/sys/dev/pci/drm/amd/display/amdgpu_dm  
-I/sys/dev/pci/drm/amd/powerplay/inc
-I/sys/dev/pci/drm/amd/powerplay/smumgr -I/sys/dev/pci/drm/amd/powerplay/hwmgr  
-I/sys/dev/pci/drm/amd/display/dc/inc
-I/sys/dev/pci/drm/amd/display/dc/inc/hw 
-I/sys/dev/pci/drm/amd/display/modules/inc -DDDB -DDIAGNOSTIC -DKTRACE 
-DACCOUNTING
-DKMEMSTATS -DPTRACE -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM -DUVM_SWAP_ENCRYPT 
-DFFS -DFFS2 -DFFS_SOFTUPDATES -DUFS_DIRHASH -DQUOTA
-DEXT2FS -DMFS -DNFSCLIENT -DNFSSERVER -DCD9660 -DUDF -DMSDOSFS -DFIFO -DFUSE 
-DSOCKET_SPLICE -DTCP_ECN -DTCP_SIGNATURE -DINET6 -DIPSEC
-DPPP_BSDCOMP -DPPP_DEFLATE -DPIPEX -DMROUTING -DMPLS -DBOOT_CONFIG 
-DPCIVERBOSE -DUSER_PCICONF -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL
-DWSDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_DEFAULTSCREENS="6" -DONEWIREVERBOSE 
-DMULTIPROCESSOR -DMAXUSERS=80 -D_KERNEL -D__arm64__ -MD -MP
-c /sys/dev/pci/mfi_pci.c

In file included from /sys/dev/pci/mfi_pci.c:37:
/sys/dev/ic/mfivar.h:190:20: error: field has incomplete type 'struct 
ksensordev'
struct ksensordev   sc_sensordev;
^
/sys/dev/ic/mfivar.h:190:9: note: forward declaration of 'struct ksensordev'
struct ksensordev   sc_sensordev;
   ^
1 error generated.
*** Error 1 in /sys/arch/arm64/compile/GENERIC.MP (Makefile:1206 'mfi_pci.o')


Thanks in advance.


-- 
burelli.fr 

Re: The OpenBSD talk at 36c3

[gbcd]

frankly the impression the speaker gives is of someone who feels aggrieved
by an OpenBSD dev or more likely some story he heard about Theo or some similar
event affronted this boy's sensibilities and his first instinct was to lash
out as most children do and say "but you're wrong!". it's like a child's
version of tall poppy syndrome where the kid sees someone else getting praise
or attention and they resent it so they start throwing their toys around

his demeanor and metacommunication are telling specially when viewed in the
context of his statements on https://isopenbsdsecu.re/about/

  Because the OpenBSD community is notorious for not being nice and welcoming:
  They’re proud of not having a code of conduct, and were mocking FreeBSD for 
adopting one.
  Theo is known to routinely call people names and being harsh, calling people 
assholes, inaccurate jerk

not having a code of conduct has clearly offended this boy which is slightly
droll. i for one definitely consider it a positive that OpenBSD doesn't have
a coc. people who want to regulate adult behavior are usually very insecure and
incompetent so seek to obtain power by way of decree because they lack the
ability to influence the world in any other capacity

and his presentation can hardly be considered quantitative research but an
arbitrary cherrypick of statements in some weird appeal to authority flex that
misses the mark

i can't help but smile at the audacity the kid has to think he's even capable
of considering things that actual systems developers with more years experience
than he's even been alive haven't cogitated and debated among each other for
exponentially more hours on just one of the mitigations he thinks he's cleverly
dissected than he spent on the entirety of his collective "research". it was a
good laugh but he really should invest his time into building something rather
than trying to tear something down that has contributed immeasurable value to
the community with just one of their many innovations


At moment, I want my privacy to be protected.
https://mytemp.email/

Re: Hyperbola Gnu Linux changing to Bsd

[Constantine A. Murenin]

On Mon, 30 Dec 2019 at 15:24, Ian Darwin  wrote:
>
> On 12/30/19 15:02, Peter Nicolai Mathias Hansteen wrote:
> > The TL;DR version is that taking code or any other body of work that is 
> > offered to you under a permissive license and making your changes to it 
> > available only under a more restrictive one may be legal in some or all 
> > jurisdictions, but it is most certainly a sign of an almost total lack of 
> > respect for the people who did the original work.
>
> Not to mention: putting code under a more restrictive license than
> previously, while calling it "more free", is hypocrisy, pure and simple.
> Nothing gnu here, folks.


Has anything ever came out of these Linux-libre projects that fork
purely for GPL reasons?  I thought they usually work simply by
removing the things out without having the expertise to ever write any
suitable replacements; e.g., they'll probably first remove
fw_update(1) to break your wireless, then after a few years, they'll
find a little bit of freely redistributable microcode in various
Ethernet drivers of OpenBSD, and will break those drivers as well,
without ever providing any replacements, either, of course.


Theo has previously addressed this whole question of
freely-redistributable proprietary microcode/firmware in OpenBSD,
urging the (GNU) people to stop loading the OpenBSD devs with more
tasks:


* http://web.archive.org/web/20060603230017/http://kerneltrap.org/node/6550

* http://archive.is/CARbI



:Jeremy Andrews: Each OpenBSD release includes a theme song that
goes along with the release's artwork. OpenBSD 3.9's theme song is
titled "Blob!". Can you explain what binary blobs are and why they're
a problem?
:
:Theo de Raadt: Vendors often try to hand off two kinds of binary
code to us, which they expect we will happily incorporate into our
system (and then, hopefully, we will shut up).
:
:The first kind to mention is firmwares. Firmwares (like for
instance on a Intel wireless card, or a such) are binary pieces of
code that will run on the little processor that is on the wireless
card. As an operating system, we need to load the code out to the
card. To include a firmware in OpenBSD, we simply need a nice
copyright statement from the vendor that lets us distribute the
firmware. Some vendors won't even go that far, though.
:
:The second kind of binary data vendors feed us are blobs. This is
code that is expected to be linked against the operating system and
run on the host processor. There are many problems with this. First
off, can we trust the code to do what it should do? I don't think so.
If there is a bug, can we fix it? No, as developers our hands are
tied, and if our user community runs into bugs it just makes us look
bad. Therefore when faced with the choice of supporting a device very
poorly (as the blob would force us to) we instead choose to wait until
we (or someone else) can reverse engineer it or.
:
:Jeremy Andrews: What is it about binary firmware that you're
willing to ship it, versus binary blobs? How can you trust the
firmware binary to do what it should do? And what if the firmware has
a bug?
:
:Theo de Raadt: Quite honestly I prefer chips which have no
firmware, and instead use correctly designed hardware logic, which our
driver must then drive. Note that most ethernet chipsets do not use a
processor, but many scsi chipsets do. Most IDE chipsets do not, but
for wireless devices ... it is about half and half. This clearly has
to do with the complexity of the data flow problem being dealt with.
:
:But in the end, if we wish to support any such devices, we must
be practical. We must accept the risk that there is a flaw in the
firmware. (Is that not what many of us have been coping with for years
now with Prism wireless chipsets and their firmware update tools?) But
the legal climate is a real problem for us -- that is why we must get
copyright permission to distribute the firmware images. Once they are
distributed... at least the device works.
:
:Of course, also note that we don't want to become Hermes (the
architecture of the Lucent/Prism/Symbol chip) assembly language
programmers... we have more than enough to do. Just a specific
example. Please, people, don't load us up with more tasks ;)
:
:Jeremy Andrews: Blobs seem especially common with wireless
ethernet cards and graphics cards, why is that?
:
:Theo de Raadt: Graphics cards have gotten to this point because
of their complexity. But these blobs also cope with lots of bugs in
the devices. These bugs are because graphics cards are devloped very
quickly now, and the hope is that software would work around the
hardware bugs.
:
:I don't know why any wireless cards use blobs. In fact, very few
do. They should just document their chips. There's a lot of hogwash
flying around about FCC rules, but if that was a concern of theirs
they should just design their chips to lock the channels in hardware.
But of course, noone in Taiwan does. So did the 

Re: Hyperbola Gnu Linux changing to Bsd

[Ian Darwin]

On 12/30/19 15:02, Peter Nicolai Mathias Hansteen wrote:

The TL;DR version is that taking code or any other body of work that is offered 
to you under a permissive license and making your changes to it available only 
under a more restrictive one may be legal in some or all jurisdictions, but it 
is most certainly a sign of an almost total lack of respect for the people who 
did the original work.


Not to mention: putting code under a more restrictive license than 
previously, while calling it "more free", is hypocrisy, pure and simple. 
Nothing gnu here, folks.

Re: How to use proot?

[Xiyue Deng]

(Adding misc@openbsd.org back to CC.)

Marc Espie  writes:

> Just have your ports tree checked out under your mount point.
> Next time it will be much faster ;)

Unfortunately my loongson box is extremely slow in both CPU and disk
performances and a CVS update usually takes same amount of time.  But
it should be faster on more modern systems.

>
> We're still shackled to our slow ffs. Copying files does take time.

Hope there will be some work to improve FFS performance in the future.


signature.asc
Description: PGP signature

Re: midiplay and FAQ ?

[Paul Wisehart]

On Mon, Dec 30, 2019 at 08:34:45AM +0100, Bodie wrote:
> 
> 
> On 28.12.2019 20:25, Paul Wisehart wrote:
> > I'm on a recently upgraded OpenBSD 6.6 machine.
> > 
> > I'm reading about midiplay here:
> > https://www.openbsd.org/faq/faq13.html#midi
> > 
> > There is no midiplay command on the machine, but there is on a 6.5
> > machine.  In the man view for midiplay the last entry is at 6.4r:
> > https://man.openbsd.org/OpenBSD-6.4/midiplay.1
> > 
> > Was midiplay removed, and midicat is the goto tool to play midi
> > files?
> 
> Original discussion from Alexandre
> 
> https://marc.info/?l=openbsd-tech=154275017321897=2
 
Thanks for that link!
I have a hardware midi synth connected by a midi cable.
I'm going to dig out the latest version and try compiling it.

Re: Hyperbola Gnu Linux changing to Bsd

[Peter Nicolai Mathias Hansteen]

[ as always, speaking only for myself but with some years’ experience in the 
OpenBSD end of things ]

> 30. des. 2019 kl. 20:31 skrev SOUL_OF_ROOT 55 :
>> 
>> *This will not be a "distro"*, but a hard fork of the OpenBSD kernel and
>> userspace including new code written under GPLv3 and LGPLv3 to replace 
>> GPL-incompatible
>> parts
>> 
>> and non-free ones
>> .

I would not hold my breath waiting for any kind of public, official response 
from the OpenSBD project as such, but from my experience this part -- making 
changes to code under the simple and permissive BSD license available only 
under GPLv3 or LGPLv3 -- is almost certain to be considered counter-productive 
in OpenBSD circles.

Dual licensing would have permitted merging of useful changes back to the 
OpenBSD tree, while making changes GPL-only will just make the «hard» fork a an 
ever more divergent variant, assuming the coding activity reaches any 
significant level.

Then again, there is no way the people who took this initiative could not have 
known this.

The TL;DR version is that taking code or any other body of work that is offered 
to you under a permissive license and making your changes to it available only 
under a more restrictive one may be legal in some or all jurisdictions, but it 
is most certainly a sign of an almost total lack of respect for the people who 
did the original work.

Judging by earlier discussions of similar efforts, this one too will the face 
of it be just quietly ignored by the OpenBSD community.

If the parallell and diverging effort does turn up useful ideas, those ideas 
will be re-thought and re-implemented in the OpenBSD way under a BSD license.

Obviously some effort could be spared if the work went ahead under compatible 
licenses, but the GNU side appears to have decided against such a reasonable 
path. I for one find that regrettable, but I am also not in a position to 
influence either side.

> What are the opinions of the OpenBSD developers about Hiperbola GNU/Linux?

Prepare to, and please accept, being ignored. If this thread drags on, with 
crossposts and all, a significant number of our readers will find it all 
annoying enough that avoidable unpleasantness may result.

All the best,
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.






signature.asc
Description: Message signed with OpenPGP

Re: Hyperbola Gnu Linux changing to Bsd

[SOUL_OF_ROOT 55]

Em seg, 30 de dez de 2019 00:59, SOUL_OF_ROOT 55 
escreveu:

> Hi!
>
> It is written in article  Free GNU/Linux distributions:
>
> "If one of these distros ever does include or propose anything nonfree,
> that must have happened by mistake, and the developers are committed to
> removing it. If you find nonfree software or documentation in one of these
> distributions, you can report the problem, and earn GNU Bucks
> , while we inform the developers
> so they can fix the problem."
>
> Reference: https://www.gnu.org/distros/free-distros.en.html
>
> Hyperbola Gnu Linux changing to Bsd:
>
> Announcing HyperbolaBSD Roadmap
>
> 2019-12-21 - Luke R.
>
> Due to the Linux kernel rapidly proceeding down an unstable path, we are
> planning on implementing *a completely new OS derived from several BSD
> implementations*.
>
> This was not an easy decision to make, but we wish to use our time and
> resources to create a viable alternative to the current operating system
> trends which are actively seeking to undermine user choice and freedom.
>
> *This will not be a "distro"*, but a hard fork of the OpenBSD kernel and
> userspace including new code written under GPLv3 and LGPLv3 to replace 
> GPL-incompatible
> parts
> 
>  and non-free ones
> .
>
> Reasons for this include:
>
>- Linux kernel forcing adaption of DRM, including HDCP
>.
>- Linux kernel proposed usage of Rust
> (which contains freedom flaws
> and
>a centralized code repository that is more prone to cyber attack and
>generally requires internet access to use.)
>- Linux kernel being written without security and in mind. (KSPP is
>basically a dead project and Grsec is no longer free software)
>- Many GNU userspace and core utils are all forcing adaption of
>features without build time options to disable them. E.g. (PulseAudio
> / SystemD / Rust
>
> 
> / Java  as
>forced dependencies)
>
> As such, we will continue to *support the Milky Way branch until 2022* when
> our legacy Linux-libre kernel reaches End of Life.
>
> Future versions of Hyperbola will be using HyperbolaBSD which will have
> the *new kernel, userspace and not be ABI compatible with previous
> versions*.
>
> *HyperbolaBSD is intended to be modular and minimalist* so other projects
> will be able to re-use the code under free license.
>
>
> References:
>
> https://www.hyperbola.info/news/announcing-hyperbolabsd-roadmap/
>
> https://forums.hyperbola.info/viewtopic.php?id=315
>
> Hiperbola GNU/Linux is not free!
>
> It is all!
>

What are the opinions of the OpenBSD developers about Hiperbola GNU/Linux?

>

Re: Blank/black screen for 6.6 - any general debugging hints?

[Christer Solskogen]

Could you post a dmesg for 6.5 and for current?

On Mon, Dec 30, 2019, 19:12 lu hu  wrote:

> Hello,
>
> I was using 6.5 on a desktop PC.
>
> I did a sysupgrade, but after the blue boot text, I only get black/blank
> screen.
>
> I don't think it is just the screen, since I cannot reach it via network.
>
> I booted the 6.6 bsd.rd then did a clean install with 6.6. The same issue.
>
> I downloaded the 6.5 bsd.rd/sets and clean installed it. IT WORKED! YAY!!!
>
> So looks like, there is some issue with 6.6 on my HW.
>
> So I will probably skip 6.6 on this HW and hope 6.7 will work :)
>
>
> BUT:
>
> I didn't found any MAN pages, DOCs, how to troubleshoot these kind of
> black/blank screen boot issues.
>
> Any hints in general, what can I do next time to avoid a clean install of
> the older major version?
>
> Many thanks and wishing peaceful holidays!
>
>

Blank/black screen for 6.6 - any general debugging hints?

[lu hu]

Hello,

I was using 6.5 on a desktop PC.

I did a sysupgrade, but after the blue boot text, I only get black/blank screen.

I don't think it is just the screen, since I cannot reach it via network.

I booted the 6.6 bsd.rd then did a clean install with 6.6. The same issue.

I downloaded the 6.5 bsd.rd/sets and clean installed it. IT WORKED! YAY!!!

So looks like, there is some issue with 6.6 on my HW.

So I will probably skip 6.6 on this HW and hope 6.7 will work :)


BUT:

I didn't found any MAN pages, DOCs, how to troubleshoot these kind of 
black/blank screen boot issues.

Any hints in general, what can I do next time to avoid a clean install of the 
older major version?

Many thanks and wishing peaceful holidays!

Re: The OpenBSD talk at 36c3

[Karl Pettersson]

On Mon, Dec 30, 2019 at 11:46:58AM +0100, Claudio Jeker wrote:
 
> Sorry but 25k is no where close to 75% of 202198.
> Seems he did count words not characters.
> 

Yes, the author has published code for generating the chart:
https://isopenbsdsecu.re/mitigations/development_practises/

The count is generated by "awk '{ print NF}'", which should count words
separated by space if no field separator is specified.

> -- 
> :wq Claudio
> 

Re: The OpenBSD talk at 36c3

[Edgar Pettijohn]

On Dec 30, 2019 5:31 AM, Kevin Chadwick  wrote:
>
>
> > I liked the presentation.  An excerpt from https://isopenbsdsecu.re/about/:
> >> This website was done because studying mitigations is fun, not to get 
> >> involved in a huge flamewars or endless bike-shedding on mailing lists.
>
> It is not my place to comment, however I will say that it did not read to me 
> as
> unbiased. Perhaps things like embargos were mentioned in the video. There are
> significant mis-understandings and perhaps mis-informations, with at times
> oppositional mistakes in the slides. My initial opinion is that very limited
> research effort happened to aid credibility, not in order to create a fair and
> comprehensive report.
>
> I welcome the praise on unveil and pledge though. It would be nice, if there 
> was
> an OpenBSD version of GCP app engine for the less serious but easily scalable
> web services!
>

Even on points where they showed OpenBSD as being late to the game they always 
finished first. I researched Linux seccomp awhile back. It is a mess to use 
compared to a couple of lines of pledge/unveil. Much better long term to get it 
right so it's useable.

Edgar

Re: The OpenBSD talk at 36c3

[Martijn van Duren]

On 12/30/19 11:46 AM, Claudio Jeker wrote:
> On Sun, Dec 29, 2019 at 01:29:12PM +0100, Henry Jensen wrote:
>> Greetings,
>>
>> for those who didn't watched it, there is an accompanied site at
>> https://isopenbsdsecu.re/
>>
>> Summary: There are a lot of claims. The speaker basically said, that
>> some mitigations are "cool", but other, more or less, useless.
>>
>> Further accusations are, that OpenBSD still uses e-mail and cvs and not
>> more advanced CI tools.
>>
>> I can't say anything to the more technical claims about useless
>> mitigations, since I am not a OS developer. Is there going to be a
>> response from the OpenBSD team?
>>
> 
> One thing that everyone can check is the claim that 50% of our commit
> messages are less than 10 chars long and 75% are less than 20 chars.
> Using the git repo you can run something like this and get the numbers
> yourself.
> 
> openbsd-git> git log --log-size --format="%B" | grep '^log size ' | cut -f
> 3 -d ' ' | awk '{ t++; if ($1 <= 10) s++; if ($1 <= 20) m++; else l++; }
> END { print s " <= 10 char"; print m " <= 20 char"; print l " rest"; print
> t " total" }'
> 
> 12386 <= 10 char
> 25894 <= 20 char
> 176304 rest
> 202198 total
> 
> Sorry but 25k is no where close to 75% of 202198.
> Seems he did count words not characters.
> 
And of those messages the vast majority are sync and regen which are
done to whip the built/sets infrastructure back into shape after a major
change (addition or deletion) and don't need any additional information.

$ git log --log-size --format="%B" | \
awk '/^log size/{
  if (matches == 1) {messages[line]++; line = ""}
  matches = 0;
  if ($3 <= 10) { matches = 1}
}
{
  if (matches == 1 && $0 !~ /^log size/) {line = line tolower($0)}
}
END {
  for (line in messages){ print messages[line]": "line}
}' | \
sort -n | tail
107: tweaks;
115: spelling
117: regen.
135: indent
183: oops
249: spacing
416: knf
441: typo
1902: regen
4915: sync

Re: off-topic

[infoomatic]

here is another version:

https://github.com/notqmail/notqmail

I switched to postfix long time ago, never looked back.


Am 30.12.19 um 14:09 schrieb Gustavo Rios:

Is qmail dead ?

Does anyone here use openbsd with qmail+ldap ?

Re: off-topic

[Kevin Chadwick]

On 2019-12-30 13:09, Gustavo Rios wrote:
> Is qmail dead ?
> 

Not Dead (I would hope the original unpatched verson is)
https://www.fehcom.de/sqmail/sqmail.html

> Does anyone here use openbsd with qmail+ldap ?
> 

I switched to OpenSMTPD

off-topic

[Gustavo Rios]

Is qmail dead ?

Does anyone here use openbsd with qmail+ldap ?

-- 
Pag Bem Fácil Ltda
www.pagbemfacil.com.br

Re: The OpenBSD talk at 36c3

[Kevin Chadwick]

> I liked the presentation.  An excerpt from https://isopenbsdsecu.re/about/:
>> This website was done because studying mitigations is fun, not to get 
>> involved in a huge flamewars or endless bike-shedding on mailing lists.

It is not my place to comment, however I will say that it did not read to me as
unbiased. Perhaps things like embargos were mentioned in the video. There are
significant mis-understandings and perhaps mis-informations, with at times
oppositional mistakes in the slides. My initial opinion is that very limited
research effort happened to aid credibility, not in order to create a fair and
comprehensive report.

I welcome the praise on unveil and pledge though. It would be nice, if there was
an OpenBSD version of GCP app engine for the less serious but easily scalable
web services!

Re: Going back to release from current installation p

[Ingo Schwarze]

Hi,

n...@web.de wrote on Sun, Dec 29, 2019 at 08:40:40PM +0100:

> thanks for your answers.  There is not really such big of a problem
> with going back to -current.

Usually, downgrading an OpenBSD installation simply doesn't work at all.
As you saw, it typically breaks in one way or another, so don't do it.

> There just seems to be a bug with the current version of rspamd's
> milter.

When you see a bug in -current, going back to -stable is never a good
idea.  Instead, help to identify the bug and get it fixed.  That's the
whole point of running -current, after all.

> Where it bounces alot of messages "warning: milter
> unix:public/rspamd_proxy.sock: can't read SMFIC_BODYEOB reply packet
> header: Undefined error: 0".
> This problem seems to only exist with the package in current and not
> in release.

The maintainer of the mail/rspamd port is likely to overlook this
report in this thread (given that it is on misc@ and given the
Subject:).  Besides, this report is extremely brief, i'm not
convinced it contains sufficient information to understand the
problem.  But since i don't use spamd, i'm not sure.

The latest commit to the mail/rspamd port was on 2019/12/29 21:35:02.
Make sure you have a package built with that commit, and if the
problem persists, post a report to ports@ with as much detail as
you can.  You may also Cc: the maintainer in case of regressions,
in this case sthen@.

Yours,
  Ingo

Re: The OpenBSD talk at 36c3

[Claudio Jeker]

On Sun, Dec 29, 2019 at 01:29:12PM +0100, Henry Jensen wrote:
> Greetings,
> 
> for those who didn't watched it, there is an accompanied site at
> https://isopenbsdsecu.re/
> 
> Summary: There are a lot of claims. The speaker basically said, that
> some mitigations are "cool", but other, more or less, useless.
> 
> Further accusations are, that OpenBSD still uses e-mail and cvs and not
> more advanced CI tools.
> 
> I can't say anything to the more technical claims about useless
> mitigations, since I am not a OS developer. Is there going to be a
> response from the OpenBSD team?
> 

One thing that everyone can check is the claim that 50% of our commit
messages are less than 10 chars long and 75% are less than 20 chars.
Using the git repo you can run something like this and get the numbers
yourself.

openbsd-git> git log --log-size --format="%B" | grep '^log size ' | cut -f
3 -d ' ' | awk '{ t++; if ($1 <= 10) s++; if ($1 <= 20) m++; else l++; }
END { print s " <= 10 char"; print m " <= 20 char"; print l " rest"; print
t " total" }'

12386 <= 10 char
25894 <= 20 char
176304 rest
202198 total

Sorry but 25k is no where close to 75% of 202198.
Seems he did count words not characters.

-- 
:wq Claudio

Re: pipe html mail to links

[Maurice McCarthy]

On 30/12/2019, putridsou...@gmail.com  wrote:
>> Should this not just need a .mailcap entry:
>>
>> text/html; /usr/local/bin/lynx -dump -force_html %s
>
> I tried your way only changed: lynx -> links
> .mailcap
> text/html; /usr/local/bin/links -dump %s
>
> But mail did not call links when I tried to
> read a html mail using "p [message]" command.
>

The pipe command is pi not p but I cannot help further sorry. Don't
use mail much.