Re: [solved]: vi: How to display German umlauts?

2024-07-09 Thread Страхиња Радић
Дана 24/07/09 07:00PM, Anon Loli написа:
> > All that's missing is the URL to the source code of that wonderful
> > editor... if it exists at all.
> > 
> 
> It's currently offline, off the internet, as far as I know, it was last hosted
> on my eepsite, but circumstances mandated that I had to take down the epsite
> because the site was outdated and insecure due to the circumstances
> It's not usable and probably won't be as beautiful as Neatvi or Arab-friendly

Right... "circumstances". How convenient.

By the way, this function:

sourcesize()
{
find . -name '*.[ch]' -exec wc -l {} \; |
awk '{
size = $1
f = $2
sum += size
printf "%10d %s\n", size, f
}
END{
printf "%10d total\n", sum
}'
}

gives

550599 total

when run in the root of Vim's repository. Aside from being a rough
estimate (it doesn't distinguish comment lines from real code), that
includes X11 code and various other features which could be opted out.

Anyway, vis[1] (vise(1) in OpenBSD: `pkg_add vis`) has some of the
functionality I mentioned earlier, and supports Unicode. The above 
function gives

 28927 total

for vis.

[1]: https://github.com/martanne/vis



Re: [solved]: vi: How to display German umlauts?

2024-07-09 Thread Anon Loli
On Tue, Jul 09, 2024 at 08:20:53PM +0200, Страхиња Радић wrote:
> Дана 24/07/09 04:02PM, Anon Loli написа:
> > That's why I use vi, and am working on my own text editor.. I don't know if
> > it'll ever be good, but I'm aiming for Vi-like simplicity, suckless code 
> > base
> > and Vim-like features (only most useful ones, the rest would be in a
> > patch-form, like suckless.org has)
> > Also when I said "am working", it's more like "was working and will work on 
> > it
> > again", but I have a problem right now which has paused my programming 
> > life...
> > I'm working on it
> > If you're interested, perhaps one day you'll want to test it out..
> 
> All that's missing is the URL to the source code of that wonderful
> editor... if it exists at all.
> 

It's currently offline, off the internet, as far as I know, it was last hosted
on my eepsite, but circumstances mandated that I had to take down the epsite
because the site was outdated and insecure due to the circumstances
It's not usable and probably won't be as beautiful as Neatvi or Arab-friendly

I'm hesitant to upload it anywhere before I setup my site.. I want to have SOME
reputaiton or something, and for that I need my website back online
When I put it back online, I'm thinking about making it something similar to
cGit, but without git, instead my own version control system and stuff...
Ideally I'd want my site written in C, and since it would be minimalistic, that
should be easy

TLS/SSL is replaced/handled by I2P so one less thing to worry about



Re: [solved]: vi: How to display German umlauts?

2024-07-09 Thread Страхиња Радић
Дана 24/07/09 04:02PM, Anon Loli написа:
> That's why I use vi, and am working on my own text editor.. I don't know if
> it'll ever be good, but I'm aiming for Vi-like simplicity, suckless code base
> and Vim-like features (only most useful ones, the rest would be in a
> patch-form, like suckless.org has)
> Also when I said "am working", it's more like "was working and will work on it
> again", but I have a problem right now which has paused my programming life...
> I'm working on it
> If you're interested, perhaps one day you'll want to test it out..

All that's missing is the URL to the source code of that wonderful
editor... if it exists at all.



Re: [solved]: vi: How to display German umlauts?

2024-07-09 Thread Anon Loli
On Tue, Jul 09, 2024 at 06:36:46PM +0200, prx wrote:
> 
> 
> Le 9 juillet 2024 18:02:31 GMT+02:00, Anon Loli  a 
> écrit :
> >On Tue, Jul 09, 2024 at 12:38:02PM +0200, rfab...@mhsmail.ch wrote:
> >> Dear Страхиња Радић,
> >> dear Jan,
> >> dear Christian
> >> 
> >> Thanks a lot for your prompt and helpful answers!
> >> 
> >> ---
> >> Am 2024-07-08 20:35, schrieb Страхиња Радић:
> >> > vi lacks a lot of built-in quality of life features that Vim has.
> >> 
> >> Yes, I know Vim from Arch Linux. But for OpenBSD, I'd like to try to
> >> stick to the base install as close as possible.
> >> 
> >> ---
> >> Am 2024-07-08 21:05, schrieb Jan Stary:
> >> > On Jul 08 18:55:11, rfab...@mhsmail.ch wrote:
> >> > > As I'd rather not switch to vim, I'd be very grateful for any tips
> >> > > concerning the display of umlauts in vi.
> >> > 
> >> > vi can't do it.
> >> 
> >> Thanks for confirming, Jan!
> >> 
> >> ---
> >> Am 2024-07-08 22:07, schrieb Christian Weisgerber:
> >> > There's a port and package of nvi-2.2.1, which is a close relative
> >> > of the base system nvi that has been extended with wide character
> >> > support.
> >> 
> >> I have just installed nvi, and the umlauts are displayed correctly.
> >> Many thanks for this tip!
> >> 
> >> ---
> >> I'm very grateful for the help misc@openbsd.org offers. A big thank
> >> you to all the list contributors - and of course to all the contributors
> >> and committers of OpenBSD itself. My family and I are very happy
> >> to be able to use it for our daily home office work.
> >> 
> >> Best regards
> >> 
> >> Rolf
> >> 
> >> 
> >> 
> >> 
> >
> >Once upon a time I decided to take a look at Vim source code
> >I did a wc -l, and it gave me like 70 LOC of *.c and *.h files like what
> >the fuck?
> >Do you know how much 700k of SLOC is?
> >Terry Davis made a reasonably good OS in just 100k of SLOC!
> >Very easy to hide malicious stuff like the backdoor that was in xz!
> >
> >That's why I use vi, and am working on my own text editor.. I don't know if
> >it'll ever be good, but I'm aiming for Vi-like simplicity, suckless code base
> >and Vim-like features (only most useful ones, the rest would be in a
> >patch-form, like suckless.org has)
> >Also when I said "am working", it's more like "was working and will work on 
> >it
> >again", but I have a problem right now which has paused my programming 
> >life...
> >I'm working on it
> >If you're interested, perhaps one day you'll want to test it out..
> >
> >I'm not sure about the license thought... as I despise licenses and even 
> >having
> >a copyleft license like CC is getting on my nerves, software should be free,
> >and non-personal information should be free, too, without any IP or a
> >requirement for a file "LICENSE".. those are just my 2 cents..
> >It's a little more complicated than that, let's just say that I don't want
> >being required to specify a LICENSE file... I'm just curious about the
> >consequences, would you use a open source peace of software that in the 
> >README
> >says "you can use it for whatever you want with no strings attached, and 
> >that's
> >about it."?
> >
> >I'm probably rambling needlessly again, that's why none care about what I say
> >
> 
> Maybe look at neatvi:
> => https://github.com/aligrudi/neatvi
> 
> Even if I still prefer nvi and its soft wrapping.
> 
> 

Oh, wow!
That looks hella impressive!
My text editor which is ALMOST functional (you can view and go up/down, but not
edit files yet, text is in buffer), and is like 600 SLOC, where Neatvi is 8000
SLOC...
But my editor doesn't have proper UTF-8 support, highlighting, any real
advanced functions, right-left support or those things found in kmap.h,
DIGRAPHS.
OK, I'm kindof lying when I say it has no highlighting, the cursor is
highlighted, and if we're talking escape sequences, that part should be easy
and like 50SLOC, depending on language and what-not
And the developer of Neatvi seems to be much more advanced than myself, in C.

I'm definitely giving Neatvi a try, after checking out it's source code thank
you, very much!
I still think that I'll make my own thing, I already learnt a whole lot, like
techinques for managing arrays/buffers by which I mean memory, which can be
useful like everywhere

I think that ANY project can be beneficial for the skill/experience
Like I never worked with hexidecimal or whatever 0x7f is

>>> actually checking out the source code mid-email
Dude advanced poll(2) code? Fuck yeah!
It's a little sad that by default C PL doesn't highlight for (u)int8-64.. but
for Go it does that lol..

Also I'm not sure how safe it is when it comes to handling escape sequences,
but I bet that the developer thought of that, he seems advanced
I also realize that there's a ton of string manipulation, and the program
manages command queries and stuff, it could easily somehow have a command that
runs something malicious
Honestly I don't even know what I'm looking for... I doubt it'd do a `rm -Rf
~/*` lol and for networking acces

Re: [solved]: vi: How to display German umlauts?

2024-07-09 Thread prx



Le 9 juillet 2024 18:02:31 GMT+02:00, Anon Loli  a 
écrit :
>On Tue, Jul 09, 2024 at 12:38:02PM +0200, rfab...@mhsmail.ch wrote:
>> Dear Страхиња Радић,
>> dear Jan,
>> dear Christian
>> 
>> Thanks a lot for your prompt and helpful answers!
>> 
>> ---
>> Am 2024-07-08 20:35, schrieb Страхиња Радић:
>> > vi lacks a lot of built-in quality of life features that Vim has.
>> 
>> Yes, I know Vim from Arch Linux. But for OpenBSD, I'd like to try to
>> stick to the base install as close as possible.
>> 
>> ---
>> Am 2024-07-08 21:05, schrieb Jan Stary:
>> > On Jul 08 18:55:11, rfab...@mhsmail.ch wrote:
>> > > As I'd rather not switch to vim, I'd be very grateful for any tips
>> > > concerning the display of umlauts in vi.
>> > 
>> > vi can't do it.
>> 
>> Thanks for confirming, Jan!
>> 
>> ---
>> Am 2024-07-08 22:07, schrieb Christian Weisgerber:
>> > There's a port and package of nvi-2.2.1, which is a close relative
>> > of the base system nvi that has been extended with wide character
>> > support.
>> 
>> I have just installed nvi, and the umlauts are displayed correctly.
>> Many thanks for this tip!
>> 
>> ---
>> I'm very grateful for the help misc@openbsd.org offers. A big thank
>> you to all the list contributors - and of course to all the contributors
>> and committers of OpenBSD itself. My family and I are very happy
>> to be able to use it for our daily home office work.
>> 
>> Best regards
>> 
>> Rolf
>> 
>> 
>> 
>> 
>
>Once upon a time I decided to take a look at Vim source code
>I did a wc -l, and it gave me like 70 LOC of *.c and *.h files like what
>the fuck?
>Do you know how much 700k of SLOC is?
>Terry Davis made a reasonably good OS in just 100k of SLOC!
>Very easy to hide malicious stuff like the backdoor that was in xz!
>
>That's why I use vi, and am working on my own text editor.. I don't know if
>it'll ever be good, but I'm aiming for Vi-like simplicity, suckless code base
>and Vim-like features (only most useful ones, the rest would be in a
>patch-form, like suckless.org has)
>Also when I said "am working", it's more like "was working and will work on it
>again", but I have a problem right now which has paused my programming life...
>I'm working on it
>If you're interested, perhaps one day you'll want to test it out..
>
>I'm not sure about the license thought... as I despise licenses and even having
>a copyleft license like CC is getting on my nerves, software should be free,
>and non-personal information should be free, too, without any IP or a
>requirement for a file "LICENSE".. those are just my 2 cents..
>It's a little more complicated than that, let's just say that I don't want
>being required to specify a LICENSE file... I'm just curious about the
>consequences, would you use a open source peace of software that in the README
>says "you can use it for whatever you want with no strings attached, and that's
>about it."?
>
>I'm probably rambling needlessly again, that's why none care about what I say
>

Maybe look at neatvi:
=> https://github.com/aligrudi/neatvi

Even if I still prefer nvi and its soft wrapping.




Re: [solved]: vi: How to display German umlauts?

2024-07-09 Thread Anon Loli
On Tue, Jul 09, 2024 at 12:38:02PM +0200, rfab...@mhsmail.ch wrote:
> Dear Страхиња Радић,
> dear Jan,
> dear Christian
> 
> Thanks a lot for your prompt and helpful answers!
> 
> ---
> Am 2024-07-08 20:35, schrieb Страхиња Радић:
> > vi lacks a lot of built-in quality of life features that Vim has.
> 
> Yes, I know Vim from Arch Linux. But for OpenBSD, I'd like to try to
> stick to the base install as close as possible.
> 
> ---
> Am 2024-07-08 21:05, schrieb Jan Stary:
> > On Jul 08 18:55:11, rfab...@mhsmail.ch wrote:
> > > As I'd rather not switch to vim, I'd be very grateful for any tips
> > > concerning the display of umlauts in vi.
> > 
> > vi can't do it.
> 
> Thanks for confirming, Jan!
> 
> ---
> Am 2024-07-08 22:07, schrieb Christian Weisgerber:
> > There's a port and package of nvi-2.2.1, which is a close relative
> > of the base system nvi that has been extended with wide character
> > support.
> 
> I have just installed nvi, and the umlauts are displayed correctly.
> Many thanks for this tip!
> 
> ---
> I'm very grateful for the help misc@openbsd.org offers. A big thank
> you to all the list contributors - and of course to all the contributors
> and committers of OpenBSD itself. My family and I are very happy
> to be able to use it for our daily home office work.
> 
> Best regards
> 
> Rolf
> 
> 
> 
> 

Once upon a time I decided to take a look at Vim source code
I did a wc -l, and it gave me like 70 LOC of *.c and *.h files like what
the fuck?
Do you know how much 700k of SLOC is?
Terry Davis made a reasonably good OS in just 100k of SLOC!
Very easy to hide malicious stuff like the backdoor that was in xz!

That's why I use vi, and am working on my own text editor.. I don't know if
it'll ever be good, but I'm aiming for Vi-like simplicity, suckless code base
and Vim-like features (only most useful ones, the rest would be in a
patch-form, like suckless.org has)
Also when I said "am working", it's more like "was working and will work on it
again", but I have a problem right now which has paused my programming life...
I'm working on it
If you're interested, perhaps one day you'll want to test it out..

I'm not sure about the license thought... as I despise licenses and even having
a copyleft license like CC is getting on my nerves, software should be free,
and non-personal information should be free, too, without any IP or a
requirement for a file "LICENSE".. those are just my 2 cents..
It's a little more complicated than that, let's just say that I don't want
being required to specify a LICENSE file... I'm just curious about the
consequences, would you use a open source peace of software that in the README
says "you can use it for whatever you want with no strings attached, and that's
about it."?

I'm probably rambling needlessly again, that's why none care about what I say



Re: "intel(0): switch to mode 640x400" on Thinkpad T410

2024-07-09 Thread Walter Alejandro Iglesias
On Tue, 9 Jul 2024 21:24:01 +1000 Jonathan Gray wrote: 
> On Tue, Jul 09, 2024 at 10:02:40AM -, Stuart Henderson wrote:
> > On 2024-07-08, Jan Stary  wrote:
> > > This is current/amd64 on a Thinkpad T410 (full dmesg below).
> > > Strangely, upon booting, xenodm sets the resolution to 640x480:
> > >
> > > [   974.100] (II) intel(0): Modeline "1440x900"x0.0   96.10  1440 1488 
> > > 1552 1728  900 903 909 926 -hsync -vsync (55.6 kHz eP)
> > > [   974.100] (II) intel(0): Modeline "1440x900"x0.0   80.30  1440 1488 
> > > 1552 1728  900 903 909 926 -hsync -vsync (46.5 kHz e)
> > > [   994.984] (II) intel(0): switch to mode 640x400@60.0 on LVDS1 using 
> > > pipe 0, position (0, 0), rotation normal, reflection none
> > 
> > shouldn't that be using modesetting rather than intel? or is the machine 
> > too old?
>
> > > inteldrm0: msi, IRONLAKE, gen 5
>
> xserver/hw/xfree86/common/xf86pciBus.c
>
> 
> revision 1.14
> date: 2017/09/25 15:05:57;  author: matthieu;  state: Exp;  lines: +2 -0;  
> commitid: wvjaQqtz2qvU9jZw;
> Force Intel Ironlake chipsets to use the xf86-video-intel driver.
> stsp@ reported that modesetting(4) has been reported unreliable
> on his laptop, while intel(4) works.
>
>  to be removed after 6.2 to figure out and fix the issue.
>
> ok kettenis@, also discussed briefly with deraadt@ during EuroBSDCon.
> 
>
> the intel driver requires pci access so won't work with
> startx as we stopped installing Xorg setuid
>

I remember many years ago modesetting wasn't reliable in this machine.
I also had issues with intel SNA acceleration (I had to use UXA).
Currently seems to work fine.  But, I can't tell for sure, I'm not using
this machine every day.



A Write-up on Fighting SPAM with the help of OpenBSD

2024-07-09 Thread Lari Huttunen
Greetings,

I composed a (somewhat opinionated) write-up on my blog about fighting SPAM
with the help of OpenBSD and rspamd. The reason I'm writing about it on this
list is that I want to give a shoutout Joel Carnat for his excellent write-up
on the subject (linked in my post).

I would love to hear your thoughts and any additional insight you might have on
the topic.

https://public-exposure.inform.social/post/a-tour-through-the-spam-fighting-state-of-the-art/

Best regards,

Lari Huttunen
-- 
Current projects:
 - https://www.huttu.net | hacking for good
 - https://public-exposure.inform.social | a blog on defensive cyber security



[solved]: vi: How to display German umlauts?

2024-07-09 Thread rfabris

Dear Страхиња Радић,
dear Jan,
dear Christian

Thanks a lot for your prompt and helpful answers!

---
Am 2024-07-08 20:35, schrieb Страхиња Радић:

vi lacks a lot of built-in quality of life features that Vim has.


Yes, I know Vim from Arch Linux. But for OpenBSD, I'd like to try to
stick to the base install as close as possible.

---
Am 2024-07-08 21:05, schrieb Jan Stary:

On Jul 08 18:55:11, rfab...@mhsmail.ch wrote:

As I'd rather not switch to vim, I'd be very grateful for any tips
concerning the display of umlauts in vi.


vi can't do it.


Thanks for confirming, Jan!

---
Am 2024-07-08 22:07, schrieb Christian Weisgerber:

There's a port and package of nvi-2.2.1, which is a close relative
of the base system nvi that has been extended with wide character
support.


I have just installed nvi, and the umlauts are displayed correctly.
Many thanks for this tip!

---
I'm very grateful for the help misc@openbsd.org offers. A big thank
you to all the list contributors - and of course to all the contributors
and committers of OpenBSD itself. My family and I are very happy
to be able to use it for our daily home office work.

Best regards

Rolf






Re: "intel(0): switch to mode 640x400" on Thinkpad T410

2024-07-09 Thread Jonathan Gray
On Tue, Jul 09, 2024 at 10:02:40AM -, Stuart Henderson wrote:
> On 2024-07-08, Jan Stary  wrote:
> > This is current/amd64 on a Thinkpad T410 (full dmesg below).
> > Strangely, upon booting, xenodm sets the resolution to 640x480:
> >
> > [   974.100] (II) intel(0): Modeline "1440x900"x0.0   96.10  1440 1488 1552 
> > 1728  900 903 909 926 -hsync -vsync (55.6 kHz eP)
> > [   974.100] (II) intel(0): Modeline "1440x900"x0.0   80.30  1440 1488 1552 
> > 1728  900 903 909 926 -hsync -vsync (46.5 kHz e)
> > [   994.984] (II) intel(0): switch to mode 640x400@60.0 on LVDS1 using pipe 
> > 0, position (0, 0), rotation normal, reflection none
> 
> shouldn't that be using modesetting rather than intel? or is the machine too 
> old?

> > inteldrm0: msi, IRONLAKE, gen 5

xserver/hw/xfree86/common/xf86pciBus.c


revision 1.14
date: 2017/09/25 15:05:57;  author: matthieu;  state: Exp;  lines: +2 -0;  
commitid: wvjaQqtz2qvU9jZw;
Force Intel Ironlake chipsets to use the xf86-video-intel driver.
stsp@ reported that modesetting(4) has been reported unreliable
on his laptop, while intel(4) works.

 to be removed after 6.2 to figure out and fix the issue.

ok kettenis@, also discussed briefly with deraadt@ during EuroBSDCon.


the intel driver requires pci access so won't work with
startx as we stopped installing Xorg setuid

> 
> > If I ctrl-alt-del the running X, it restarts with 1440x900;
> > both X logs below, the point is that the restarted xenodm
> > no longer chooses the 640x400 mode:
> >
> > [  1022.036] (II) intel(0): Modeline "1440x900"x0.0   96.10  1440 1488 1552 
> > 1728  900 903 909 926 -hsync -vsync (55.6 kHz eP)
> > [  1022.036] (II) intel(0): Modeline "1440x900"x0.0   80.30  1440 1488 1552 
> > 1728  900 903 909 926 -hsync -vsync (46.5 kHz e)
> >
> > So I have a simple workaround, but why is that happening?
> > How can I debug that?
> >
> > Jan
> >
> >
> >
> > dmesg:
> >
> > OpenBSD 7.5-current (GENERIC.MP) #173: Mon Jul  8 03:04:31 MDT 2024
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > real mem = 8357658624 (7970MB)
> > avail mem = 8081145856 (7706MB)
> > random: good seed from bootblocks
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0010 (78 entries)
> > bios0: vendor LENOVO version "6IET75WW (1.35 )" date 02/01/2011
> > bios0: LENOVO 2537BN8
> > acpi0 at bios0: ACPI 4.0
> > acpi0: sleep states S0 S3 S4 S5
> > acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET ASF! SLIC BOOT SSDT TCPA 
> > DMAR SSDT SSDT SSDT
> > acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP1(S4) EXP2(S4) EXP3(S4) 
> > EXP4(S4) EXP5(S4) EHC1(S3) EHC2(S3) HDEF(S4)
> > acpitimer0 at acpi0: 3579545 Hz, 24 bits
> > acpiec0 at acpi0
> > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> > cpu0 at mainbus0: apid 0 (boot processor)
> > cpu0: Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz, 2926.14 MHz, 06-25-05, 
> > patch 0007
> > cpu0: cpuid 1 
> > edx=bfebfbff
> >  
> > ecx=29ae3ff
> > cpu0: cpuid 6 eax=7 ecx=1
> > cpu0: cpuid 7.0 edx=9c00
> > cpu0: cpuid a vers=3, gp=4, gpwidth=48, ff=3, ffwidth=48
> > cpu0: cpuid 8001 edx=28100800 ecx=1
> > cpu0: cpuid 8007 edx=100
> > cpu0: MELTDOWN
> > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 4-way I-cache, 256KB 
> > 64b/line 8-way L2 cache, 3MB 64b/line 12-way L3 cache
> > cpu0: smt 0, core 0, package 0
> > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> > cpu0: apic clock running at 133MHz
> > cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
> > cpu1 at mainbus0: apid 1 (application processor)
> > cpu1: Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz, 2926.23 MHz, 06-25-05, 
> > patch 0007
> > cpu1: smt 1, core 0, package 0
> > cpu2 at mainbus0: apid 4 (application processor)
> > cpu2: Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz, 2926.39 MHz, 06-25-05, 
> > patch 0007
> > cpu2: smt 0, core 2, package 0
> > cpu3 at mainbus0: apid 5 (application processor)
> > cpu3: Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz, 2926.42 MHz, 06-25-05, 
> > patch 0007
> > cpu3: smt 1, core 2, package 0
> > ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped
> > acpimcfg0 at acpi0
> > acpimcfg0: addr 0xe000, bus 0-255
> > acpihpet0 at acpi0: 14318179 Hz
> > acpiprt0 at acpi0: bus 0 (PCI0)
> > acpiprt1 at acpi0: bus -1 (PEG_)
> > acpiprt2 at acpi0: bus 2 (EXP1)
> > acpiprt3 at acpi0: bus 3 (EXP2)
> > acpiprt4 at acpi0: bus -1 (EXP3)
> > acpiprt5 at acpi0: bus 5 (EXP4)
> > acpiprt6 at acpi0: bus 13 (EXP5)
> > acpibtn0 at acpi0: LID_(wakeup)
> > acpibtn1 at acpi0: SLPB(wakeup)
> > acpipci0 at acpi0 UNCR
> > acpipci1 at acpi0 PCI0: 0x 0x0011 0x0001
> > acpicmos0 at acpi0
> > tpm0 at acpi0 TPM_ 1.2 (TIS) addr 0xfed4/0x5000, device 0x104a rev 
> > 0x4e
> > acpibat0 at acpi0: BAT0 model "42T4751" serial  1780 type LION oem "SANYO"
> > acpiac0 at acpi0: AC unit online
> > 

Re: "intel(0): switch to mode 640x400" on Thinkpad T410

2024-07-09 Thread Walter Alejandro Iglesias
On Tue, 9 Jul 2024 10:02:40 - (UTC) Stuart Henderson wrote:
> On 2024-07-08, Jan Stary  wrote:
> > This is current/amd64 on a Thinkpad T410 (full dmesg below).
> > Strangely, upon booting, xenodm sets the resolution to 640x480:
> >
> > [   974.100] (II) intel(0): Modeline "1440x900"x0.0   96.10  1440 1488 1552 
> > 1728  900 903 909 926 -hsync -vsync (55.6 kHz eP)
> > [   974.100] (II) intel(0): Modeline "1440x900"x0.0   80.30  1440 1488 1552 
> > 1728  900 903 909 926 -hsync -vsync (46.5 kHz e)
> > [   994.984] (II) intel(0): switch to mode 640x400@60.0 on LVDS1 using pipe 
> > 0, position (0, 0), rotation normal, reflection none
>
> shouldn't that be using modesetting rather than intel? or is the machine too 
> old?

In my t410, even not using any xorg.conf, xenodm(1) tries to load the
intel driver, startx(1) doesn't.  Notice the difference between both
Xorg.0.log files:


Running startx(1)


[  3481.653] 
X.Org X Server 1.21.1.13
X Protocol Version 11, Revision 0
[  3481.654] Current Operating System: OpenBSD mamuca.roquesor.com 7.5 
GENERIC.MP#174 amd64
[  3481.654]  
[  3481.654] Current version of pixman: 0.42.2
[  3481.655]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[  3481.655] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  3481.657] (==) Log file: "/home/morlock/.local/share/xorg/Xorg.0.log", Time: 
Tue Jul  9 12:09:16 2024
[  3481.657] (==) Using system config directory 
"/usr/X11R6/share/X11/xorg.conf.d"
[  3481.658] (==) No Layout section.  Using the first Screen section.
[  3481.658] (==) No screen section available. Using defaults.
[  3481.658] (**) |-->Screen "Default Screen Section" (0)
[  3481.658] (**) |   |-->Monitor ""
[  3481.658] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[  3481.658] (**) Allowing byte-swapped clients
[  3481.658] (==) Automatically adding devices
[  3481.658] (==) Automatically enabling devices
[  3481.658] (==) Not automatically adding GPU devices
[  3481.658] (==) Automatically binding GPU devices
[  3481.658] (==) Max clients allowed: 256, resource mask: 0x1f
[  3481.658] (==) FontPath set to:
/usr/X11R6/lib/X11/fonts/misc/,
/usr/X11R6/lib/X11/fonts/TTF/,
/usr/X11R6/lib/X11/fonts/OTF/,
/usr/X11R6/lib/X11/fonts/Type1/,
/usr/X11R6/lib/X11/fonts/100dpi/,
/usr/X11R6/lib/X11/fonts/75dpi/
[  3481.658] (==) ModulePath set to "/usr/X11R6/lib/modules"
[  3481.658] (II) The server relies on wscons to provide the list of input 
devices.
If no devices become available, reconfigure wscons or disable 
AutoAddDevices.
[  3481.658] (II) Loader magic: 0xd9d14c08500
[  3481.658] (II) Module ABI versions:
[  3481.658]X.Org ANSI C Emulation: 0.4
[  3481.658]X.Org Video Driver: 25.2
[  3481.658]X.Org XInput driver : 24.4
[  3481.658]X.Org Server Extension : 10.0
[  3481.659] (--) Using wscons driver on /dev/ttyC4
[  3481.692] (WW) checkDevMem: failed to open /dev/xf86 and /dev/mem
(Permission denied)
Check that you have set 'machdep.allowaperture=1'
in /etc/sysctl.conf and reboot your machine
refer to xf86(4) for details
[  3481.692]linear framebuffer access unavailable
[  3481.692] (II) LoadModule: "glx"
[  3481.693] (II) Loading /usr/X11R6/lib/modules/extensions/libglx.so
[  3481.696] (II) Module glx: vendor="X.Org Foundation"
[  3481.696]compiled for 1.21.1.13, module version = 1.0.0
[  3481.697]ABI class: X.Org Server Extension, version 10.0
[  3481.697] (==) Matched modesetting as autoconfigured driver 0
[  3481.697] (==) Assigned the driver to the xf86ConfigLayout
[  3481.697] (II) LoadModule: "modesetting"
[  3481.697] (II) Loading /usr/X11R6/lib/modules/drivers/modesetting_drv.so
[  3481.698] (II) Module modesetting: vendor="X.Org Foundation"
[  3481.698]compiled for 1.21.1.13, module version = 1.21.1
[  3481.698]Module class: X.Org Video Driver
[  3481.698]ABI class: X.Org Video Driver, version 25.2
[  3481.698] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[  3481.698] (WW) Falling back to old probe method for modesetting
[  3481.709] (II) modeset(0): using default device
[  3481.709] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[  3481.709] (II) modeset(0): Creating default Display subsection in Screen 
section
"Default Screen Section" for depth/fbbpp 24/32
[  3481.709] (==) modeset(0): Depth 24, (==) framebuffer bpp 32
[  3481.709] (==) modeset(0): RGB weight 888
[  3481.709] (==) modeset(0): Default visual is TrueColor
[  3481.709] (II) Loading sub module "glamoregl"
[  3481.709] (II) LoadModule: "glamoregl"
[  3481.711] (II) Loading /usr/X11R6/lib/modules/libglamoregl.so
[  3481.743] (II) Module glamoregl:

Re: "intel(0): switch to mode 640x400" on Thinkpad T410

2024-07-09 Thread Stuart Henderson
On 2024-07-08, Jan Stary  wrote:
> This is current/amd64 on a Thinkpad T410 (full dmesg below).
> Strangely, upon booting, xenodm sets the resolution to 640x480:
>
> [   974.100] (II) intel(0): Modeline "1440x900"x0.0   96.10  1440 1488 1552 
> 1728  900 903 909 926 -hsync -vsync (55.6 kHz eP)
> [   974.100] (II) intel(0): Modeline "1440x900"x0.0   80.30  1440 1488 1552 
> 1728  900 903 909 926 -hsync -vsync (46.5 kHz e)
> [   994.984] (II) intel(0): switch to mode 640x400@60.0 on LVDS1 using pipe 
> 0, position (0, 0), rotation normal, reflection none

shouldn't that be using modesetting rather than intel? or is the machine too 
old?

> If I ctrl-alt-del the running X, it restarts with 1440x900;
> both X logs below, the point is that the restarted xenodm
> no longer chooses the 640x400 mode:
>
> [  1022.036] (II) intel(0): Modeline "1440x900"x0.0   96.10  1440 1488 1552 
> 1728  900 903 909 926 -hsync -vsync (55.6 kHz eP)
> [  1022.036] (II) intel(0): Modeline "1440x900"x0.0   80.30  1440 1488 1552 
> 1728  900 903 909 926 -hsync -vsync (46.5 kHz e)
>
> So I have a simple workaround, but why is that happening?
> How can I debug that?
>
>   Jan
>
>
>
> dmesg:
>
> OpenBSD 7.5-current (GENERIC.MP) #173: Mon Jul  8 03:04:31 MDT 2024
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8357658624 (7970MB)
> avail mem = 8081145856 (7706MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0010 (78 entries)
> bios0: vendor LENOVO version "6IET75WW (1.35 )" date 02/01/2011
> bios0: LENOVO 2537BN8
> acpi0 at bios0: ACPI 4.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET ASF! SLIC BOOT SSDT TCPA 
> DMAR SSDT SSDT SSDT
> acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP1(S4) EXP2(S4) EXP3(S4) 
> EXP4(S4) EXP5(S4) EHC1(S3) EHC2(S3) HDEF(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpiec0 at acpi0
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz, 2926.14 MHz, 06-25-05, patch 
> 0007
> cpu0: cpuid 1 
> edx=bfebfbff
>  
> ecx=29ae3ff
> cpu0: cpuid 6 eax=7 ecx=1
> cpu0: cpuid 7.0 edx=9c00
> cpu0: cpuid a vers=3, gp=4, gpwidth=48, ff=3, ffwidth=48
> cpu0: cpuid 8001 edx=28100800 ecx=1
> cpu0: cpuid 8007 edx=100
> cpu0: MELTDOWN
> cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 4-way I-cache, 256KB 
> 64b/line 8-way L2 cache, 3MB 64b/line 12-way L3 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 133MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz, 2926.23 MHz, 06-25-05, patch 
> 0007
> cpu1: smt 1, core 0, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz, 2926.39 MHz, 06-25-05, patch 
> 0007
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 5 (application processor)
> cpu3: Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz, 2926.42 MHz, 06-25-05, patch 
> 0007
> cpu3: smt 1, core 2, package 0
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xe000, bus 0-255
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (PEG_)
> acpiprt2 at acpi0: bus 2 (EXP1)
> acpiprt3 at acpi0: bus 3 (EXP2)
> acpiprt4 at acpi0: bus -1 (EXP3)
> acpiprt5 at acpi0: bus 5 (EXP4)
> acpiprt6 at acpi0: bus 13 (EXP5)
> acpibtn0 at acpi0: LID_(wakeup)
> acpibtn1 at acpi0: SLPB(wakeup)
> acpipci0 at acpi0 UNCR
> acpipci1 at acpi0 PCI0: 0x 0x0011 0x0001
> acpicmos0 at acpi0
> tpm0 at acpi0 TPM_ 1.2 (TIS) addr 0xfed4/0x5000, device 0x104a rev 
> 0x4e
> acpibat0 at acpi0: BAT0 model "42T4751" serial  1780 type LION oem "SANYO"
> acpiac0 at acpi0: AC unit online
> acpithinkpad0 at acpi0: version 1.0
> "*pnp0c14" at acpi0 not configured
> "PNP0C14" at acpi0 not configured
> acpicpu0 at acpi0: C3(350@245 mwait.3@0x20), C2(500@205 mwait.3@0x10), 
> C1(1000@3 mwait.1), PSS
> acpicpu1 at acpi0: C3(350@245 mwait.3@0x20), C2(500@205 mwait.3@0x10), 
> C1(1000@3 mwait.1), PSS
> acpicpu2 at acpi0: C3(350@245 mwait.3@0x20), C2(500@205 mwait.3@0x10), 
> C1(1000@3 mwait.1), PSS
> acpicpu3 at acpi0: C3(350@245 mwait.3@0x20), C2(500@205 mwait.3@0x10), 
> C1(1000@3 mwait.1), PSS
> acpipwrres0 at acpi0: PUBS, resource for EHC1, EHC2
> acpitz0 at acpi0: critical temperature is 100 degC
> acpivideo0 at acpi0: VID_
> acpivout0 at acpivideo0: LCD0
> acpivideo1 at acpi0: VID_
> cpu0: using IvyBridge MDS workaround
> cpu0: Enhanced SpeedStep 2926 MHz: speeds: 2667, 2666, 2533, 2399, 2266, 
> 2133, 1999, 1866, 1733, 1599, 1466, 1333, 1199 MHz
> pci0 at mainbus0 bus 255
> pchb0 at pci0 dev 0 function

Re: "intel(0): switch to mode 640x400" on Thinkpad T410

2024-07-09 Thread Walter Alejandro Iglesias
I also have a T410 running the latest snaptshot.  The screen of my
laptop is 1280x800.  I can't reproduce your issue.

Probably this has nothing to do with your issue but I'd like to call the
attention to this error:

  (EE) AIGLX error: dlopen of /usr/X11R6/lib/modules/dri/i965_dri.so failed 
(File not found)
  (EE) AIGLX error: unable to load driver i965

It's present in both two Xorg.0.log you pasted.  And now I realize it is
in my /var/log/Xorg.log.0 too.  Curiously that error doesn't appear when
I use startx(1) (in ~/.local/share/xorg/Xorg.0.log).

My desktop machine has also a integrated intel graphic card and I don't
see that error, neither using startx nor using xenodm.


   Walter



Re: smtpd warn: not enough disk space

2024-07-09 Thread Stuart Henderson
On 2024-07-09, Christian Schulte  wrote:
>
>
> On 07.07.24 03:51, Jeremy Evans wrote:
>> On Fri, Jul 5, 2024 at 9:16 PM Christian Schulte > > wrote:
>> 
>> Just wondering how the postgresql
>> port is configured. Really should setup quotas automatically when
>> pkg_adding in a way, just to ensure, that no one ever runs into a
>> situation, that there is no way out of a disk full situation.

The port can't sanely do that, because it doesn't know how the admin
has configured their system.

Also, openbsd doesn't enable filesystem quotas by default.

> I did not criticize the postgresql port in any way. I am just 
> suggesting, that when you want to setup a postgresql server in a 
> fire-and-forget way of things, it would be cool to restrict it from 
> eating up all available storage.

That is simple, use a separate filesystem for /var/postgresql.

-- 
Please keep replies on the mailing list.



Re: smtpd warn: not enough disk space

2024-07-09 Thread Stuart Henderson
On 2024-07-09, Christian Schulte  wrote:
>For example: Just 
> remove the patches in this directory - well a lot of them - and see how 
> those GNU folks have turned into complete idiots. I don't get it.
>
> https://github.com/openbsd/ports/tree/master/devel/gettext/patches

A lot of those patches are to avoid triggering warnings from ld when
linking other programs which use the gettext library due to the
api warnings openbsd has for some libc functions.


-- 
Please keep replies on the mailing list.



Re: Hard freeze during `pkg_add -u` on -current

2024-07-09 Thread Stuart Henderson
Only thing I can really suggest at that point is uninstalling packages
and reinstalling them. The steps would be similar to those in faq 15
"Duplicating Installed Packages on Another Machine" but rather than
transferring "list" to another machine, pkg_delete /var/db/pkg/* and
install them locally.

If the pkg database in too bad a state to pkg_delete, you could produce
a list, move /var/db/pkg out of the way, and pkg_add using that list
over the top - there will be "missing package registration, do you want
to fix?" questions which you can answer yes to.



On 2024/07/05 15:01, Ronald Dahlgren wrote:
> Thank you for the reply, Stuart.
> 
> Running pkg_check startout out fine and then went off the rails. The output 
> is captured here ->
> https://sw.gy/files/pkg_check.html
> 
> The control characters passed through xterm and a clipboard so they may not 
> be accurate. Here
> are some screenshots of the original:
> 
> https://sw.gy/files/pkg_check-1.png
> https://sw.gy/files/pkg_check-2.png
> 
> Thankfully this behavior did not crash the system :)
> 
> Ron
> 
> On Fri, Jul 5, 2024 at 12:33 PM Stuart Henderson  
> wrote:
> 
> On 2024-07-05, Ronald Dahlgren  wrote:
> > --cbf9af061c80339e
> > Content-Type: text/plain; charset="UTF-8"
> > Content-Transfer-Encoding: quoted-printable
> >
> > Hello,
> >
> > On July 2nd, I updated a machine to the latest snapshot and rebooted. It
> > came back without issue. I then issued `pkg_add -U`. This machine was 
> last
> > updated on June 6th, so not terribly long ago. Partway during the 
> process,
> > the disk indicated it was full (not true) and no commands were available
> > (ls, cd, etc). Unable to do anything, I terminated my SSH session and
> > attempted to reconnect. The machine failed to respond to pings. I had
> > someone onsite reboot the machine. It then came back up. I did not try 
> the
> > `pkg_add -u` command again. Inspection showed that partitions had 
> plenty of
> > available space and inodes.
> >
> > The daily insecurity output that ran the following day, on Wednesday the
> > 3rd, had this unusual snippet:
> >
> > ```
> > vmm-firmware-1.16.3p0 firmware binary images for vmm(4) driver
> > -xz-5.4.5            library and tools for XZ and LZMA compressed files
> > +xz-5.6.2
> > /??^L???.???/?..??/??$???+DESC???/?
> >  
> +CONTENTS0^L+REQUIRED_BY??=
> > 
> ???=
> > 
> ???=
> > 
> ???=
> > 
> ???=
> > ??
> >  zsh-5.9p0           Z shell, Bourne shell-compatible
> > ```
> 
> The filesystem holding /var/db/pkg has some corruption.
> I'd try running pkg_check and allow it to repair, reinstall xz
> "pkg_add -r -D installed xz", and see how you get on.
> 
> > Given the package with the wacky description is `xz`, I'm more concerned
> > than I would be otherwise.
> 
> The same could have happened to any package, there's nothing special
> about xz there.
> 
> > I can see in `/var/log/messages` the snapshot update occurred without
> > issue. Logs after the physical reboot show no core dump and only have
> > complaints about filesystems not being properly unmounted - expected 
> when
> > the plug is pulled.
> >
> > Are there any other logs I can check and share to help get to the 
> bottom of
> > this? The impacted computer has been running current and humming along
> > happily in a network closet for over a year.
> 
> Not sure about the disk full message (spurious seems unlikely - if space
> is ok, is some filesystem tight on inodes? df -hi) or the hang.
> 
> --
> Please keep replies on the mailing list.
> 
>