X Server failing about libfreetype.so.24.0 with latest snapshot

2015-06-29 Thread Thomas Schmidt 
Hi,
I just updated from a 5.7-current snapshot (15th June) to a recent one
(29th June).
Now, when I try to 'startx' I get the following error:

$ startx
xauth: (stdin):1:  bad display name "turin.local:0" in "add" command

/usr/X11R6/bin/X: can't load library 'libfreetype.so.24.0'
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error
xauth: (argv):1:  bad display name "turin.local:0" in "remove" command

$ cat .xinitrc
cwm

Is anyone else seeing this? I'll try the next snapshot as soon as it's
available.

$ dmesg
OpenBSD 5.7-current (GENERIC.MP) #1063: Mon Jun 15 00:54:48 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4062691328 (3874MB)
avail mem = 3935686656 (3753MB)
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 "6IET83WW (1.43 )" date 04/12/2012
bios0: LENOVO 2537G98
acpi0 at bios0: rev 2
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) UART(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 520 @ 2.40GHz, 1197.24 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 132MHz
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 520 @ 2.40GHz, 1197.00 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz, 1197.00 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 5 (application processor)
cpu3: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz, 1197.00 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 2, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpimcfg0 at acpi0 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)
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
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model "42T4912" serial 11240 type LION oem "LGC"
acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit offline
acpithinkpad0 at acpi0
cpu0: Enhanced SpeedStep 1197 MHz: speeds: 2400, 2399, 2266, 2133, 1999, 1866, 
1733, 1599, 1466, 1333, 1199 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core Host" rev 0x02
vga1 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x02
intagp0 at vga1
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: 1280x800
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel 3400 MEI" rev 0x06 at pci0 dev 22 function 0 not configured
em0 at pci0 dev 25 function 0 "Intel 82577LM" rev 0x06: msi, address

dmesg(8) incomplete?

2015-03-12 Thread Thomas Schmidt 
Hi,
I am a pretty new user so please forgive any uninformed statements.

I just spent a few hours trying to figure out why my dmesg displays an
old kernel (May 5th), when I just compiled a new one (for recent -stable
patches). I've looked pretty much everywhere and retraced every step
until finally giving up and starting to compose a mail to get help.
Then, when pasting my dmesg output into the mail I realized that there
were multiple system messages from multiple startups in the dmesg output,
and that everything was fine with my system.
Now, except for a few threads from 200[367], even now that I know what
I'm looking for I don't see this behaviour documented anywhere. Since
there is no other record of this behaviour my knowldge is probably
incomplete but attached is a patch - I borrowed some wordings from a mail
from Theo[1] - that adds this information to the dmesg manpage.

Best Regards,
Thomas

[1] http://marc.info/?l=openbsd-misc&m=115272548814461&w=2


Index: src/sbin/dmesg/dmesg.8
===
RCS file: /cvs/src/sbin/dmesg/dmesg.8,v
retrieving revision 1.15
diff -u -p -u -r1.15 dmesg.8
--- src/sbin/dmesg/dmesg.8  13 Jan 2015 10:07:58 -  1.15
+++ src/sbin/dmesg/dmesg.8  13 Mar 2015 03:14:45 -
@@ -45,6 +45,11 @@
 .Nm
 displays the contents of the system message buffer.
 It is most commonly used to review system startup messages.
+If the kernel finds that the
+.Nm
+buffer in the kernel address space is still intact after reboot, it does
+not clear it, but appends to it, resulting in the output of messages from
+multiple startups. This is so that crash-related data will be retained.
 .Pp
 The options are as follows:
 .Bl -tag -width Ds

Re: qsort.3 big O notation

2015-03-03 Thread Thomas Schmidt 
In the most recent algorithms lecture I heard we used log for base 2, ln for 
base e, and lg for base 10. But asymptotically the base doesn't matter and the 
notation coventions differ. So I'd also go for consistency with other 
documentation. 

On March 3, 2015 5:48:20 PM CET, frantisek holop  wrote:
>Joerg Sonnenberger, 03 Mar 2015 17:28:
>> On Tue, Mar 03, 2015 at 05:02:39PM +0100, frantisek holop wrote:
>> > i leave the battle about lg vs log to others,
>> > but i prefer 'log' as there is a man page for that
>> > and there is none for 'lg'...
>> 
>> If anything, it should be "log" because that is the name of the
>> mathematical function. libm is completely irrelevant in this context.
>
>'lg' is also a valid name
>(altough i admit i didn't know, i was used to log2)
>https://en.wikipedia.org/wiki/Logarithm#Particular_bases
>
>as Tedu pointed out lg = log2 and lg != log
>
>but i think my point is still kind of valid,
>as there is log2(3) and no lg(3).
>
>i find it relevant that libm should also use
>the most common, easiest names where possible...
>it is kind of nice to be able to do 'man log2'
>after reading 'man qsort', a kind of indirect
>cross reference.
>
>-f
>-- 
>illiterate?  write for a free brochure!

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.