Re: 6.5 PowerPC Packages
On 2019 May 13 (Mon) at 21:17:16 -0400 (-0400), Steven Shockley wrote: :On 5/9/2019 10:55 AM, Theo de Raadt wrote: :> The real reason is because we're low on current for the flux capacitor, :> after shifting time for the early 6.5 release. Not all the machines :> were able to fit into back seat of the Delorian. : :Wouldn't that be low on -release or -stable? : -release packages. We currently do not offically build -stable packages. -- If you stand on your head, you will get footprints in your hair.
Re: USB sound card not playing
i use 6.6 snapshots and USB sound card . the card play youtube well including sound . -- $ dmesg | grep audio uaudio0 at uhub2 port 4 configuration 1 interface 1 "C-Media Electronics Inc. USB Audio Device" rev 1.10/1.00 addr 5 uaudio0: class v1, full-speed, sync, channels: 2 play, 1 rec, 8 ctls audio0 at uaudio0 uaudio0: can't reset interface uaudio0: can't reset interface audio0 detached uaudio0 detached uaudio0 at uhub3 port 6 configuration 1 interface 1 "C-Media Electronics Inc. USB Audio Device" rev 1.10/1.00 addr 4 uaudio0: class v1, full-speed, sync, channels: 2 play, 1 rec, 8 ctls audio0 at uaudio0 -- from 竹島強
Re: 6.5 PowerPC Packages
On 5/9/2019 10:55 AM, Theo de Raadt wrote: > The real reason is because we're low on current for the flux capacitor, > after shifting time for the early 6.5 release. Not all the machines > were able to fit into back seat of the Delorian. Wouldn't that be low on -release or -stable?
Re: sndio? aucat -i s.wav: "default: couldn't open audio device"
Thank you Troy! however, it does not even get to "trying pars...": - # AUCAT_DEBUG=4 SIO_DEBUG=4 aucat -i ./sound.wav default: couldn't open audio device # AUCAT_DEBUG=4 SNDIO_DEBUG=4 aucat -i ./sound.wav _aucat_open: host= unit=0 devnum=0 opt=default /tmp/sndio-0/sock0: No such file or directory /tmp/sndio/sock0: connected _aucat_rmsg: eof aucat_init: mode refused /dev/audio0: Invalid argument default: couldn't open audio device --- sndiod is showing this in first window (output for one command after another): - sock(sock|ini): created listen(/tmp/sndio/sock0|ini): processed in 12288us sock,rmsg,widl: AUTH message helper: recv: cmd = 0, num = 0, mode = 3, fd = -1 helper: send: cmd = 3, num = 0, mode = 0, fd = -1 helper(helper|ini): processed in 117724us helper: recv: cmd = 0, num = 0, mode = 1, fd = -1 helper: send: cmd = 3, num = 0, mode = 0, fd = -1 helper(helper|ini): processed in 236610us sock,rmsg,widl: HELLO message sock,rmsg,widl: hello from , mode = 1, ver 7 aucat0: reused snd0 pst=cfg: device requested worker: send: cmd = 0, num = 0, mode = 3, fd = -1 worker: recv: cmd = 3, num = 0, mode = 0, fd = -1 worker: send: cmd = 0, num = 0, mode = 1, fd = -1 worker: recv: cmd = 3, num = 0, mode = 0, fd = -1 worker: send: cmd = 0, num = 0, mode = 2, fd = -1 worker: recv: cmd = 3, num = 0, mode = 0, fd = -1 snd0 pst=cfg: rsnd/0: failed to open audio device sock,rmsg,widl: closing sock(sock|zom): destroyed sock(sock|zom): processed in 480270us helper: recv: cmd = 0, num = 0, mode = 2, fd = -1 helper: send: cmd = 3, num = 0, mode = 0, fd = -1 helper(helper|ini): processed in 121869us sock(sock|ini): created sock,rmsg,widl: AUTH message helper: recv: cmd = 0, num = 0, mode = 3, fd = -1 helper: send: cmd = 3, num = 0, mode = 0, fd = -1 helper(helper|ini): processed in 123518us helper: recv: cmd = 0, num = 0, mode = 1, fd = -1 helper: send: cmd = 3, num = 0, mode = 0, fd = -1 helper(helper|ini): processed in 235601us sock,rmsg,widl: HELLO message sock,rmsg,widl: hello from , mode = 1, ver 7 aucat0: reused snd0 pst=cfg: device requested worker: send: cmd = 0, num = 0, mode = 3, fd = -1 worker: recv: cmd = 3, num = 0, mode = 0, fd = -1 worker: send: cmd = 0, num = 0, mode = 1, fd = -1 worker: recv: cmd = 3, num = 0, mode = 0, fd = -1 worker: send: cmd = 0, num = 0, mode = 2, fd = -1 worker: recv: cmd = 3, num = 0, mode = 0, fd = -1 snd0 pst=cfg: rsnd/0: failed to open audio device sock,rmsg,widl: closing sock(sock|zom): destroyed sock(sock|zom): processed in 482938us helper: recv: cmd = 0, num = 0, mode = 2, fd = -1 helper: send: cmd = 3, num = 0, mode = 0, fd = -1 helper(helper|ini): processed in 131729us On Mon, May 13, 2019 at 5:07 PM Troy Martin wrote: > On Monday, May 13, 2019 at 1:54 PM, Juan Zuluaga wrote: > > sb0 at isa0 port 0x220/24 irq 5 drq 1: dsp v3.02 > > midi0 at sb0: > > audio0 at sb0 > > opl at sb0 not configured > > It appears you have an ISA Sound Blaster 16 of some sort. IIRC early > SB cards were unable to handle 48 kHz sample rates and would quietly > choke on them. Try running aucat as: > > # AUCAT_DEBUG=4 SIO_DEBUG=4 aucat -i ./sound.wav > > ...and see if it chokes on after "trying pars = 48000/16/6". > > -- > Troy > >
Re: sndio? aucat -i s.wav: "default: couldn't open audio device"
On Monday, May 13, 2019 at 1:54 PM, Juan Zuluaga wrote: > sb0 at isa0 port 0x220/24 irq 5 drq 1: dsp v3.02 > midi0 at sb0: > audio0 at sb0 > opl at sb0 not configured It appears you have an ISA Sound Blaster 16 of some sort. IIRC early SB cards were unable to handle 48 kHz sample rates and would quietly choke on them. Try running aucat as: # AUCAT_DEBUG=4 SIO_DEBUG=4 aucat -i ./sound.wav ...and see if it chokes on after "trying pars = 48000/16/6". -- Troy
Re: 6.5 PowerPC Packages
Awesome! Thank you for the status update. On Sun, May 12, 2019 at 6:33 PM Christian Weisgerber wrote: > > On 2019-05-09, Christian Weisgerber wrote: > > > The build has been running for 25 days so far, across two machines, > > and the packages will be uploaded once they are finished. > > I just signed the packages. They'll become available in a day or so. > > -- > Christian "naddy" Weisgerber na...@mips.inka.de >
sndio? aucat -i s.wav: "default: couldn't open audio device"
Hello all,
I have audio trouble: no sound whatsoever, and error messages.
In a first terminal window, as root, I typed
# sndiod -ddd
In a second terminal window I typed
# file ./sound.wav
./sound.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16
bit, mono 11025 Hz
# aucat -i ./sound.wav
default: couldn't open audio device
The first terminal window shows this:
petal# sndiod -ddd
snd0 pst=cfg.default: rec=0:1 play=0:1 vol=23170 dup
helper(helper|ini): created
worker(worker|ini): created
listen(/tmp/sndio/sock0|ini): created
sock(sock|ini): created
listen(/tmp/sndio/sock0|ini): processed in 6261us
sock,rmsg,widl: AUTH message
helper: recv: cmd = 0, num = 0, mode = 3, fd = -1
helper: send: cmd = 3, num = 0, mode = 0, fd = -1
helper(helper|ini): processed in 123554us
helper: recv: cmd = 0, num = 0, mode = 1, fd = -1
helper: send: cmd = 3, num = 0, mode = 0, fd = -1
helper(helper|ini): processed in 236812us
sock,rmsg,widl: HELLO message
sock,rmsg,widl: hello from , mode = 1, ver 7
aucat0: overwritten slot 0
snd0 pst=cfg: device requested
worker: send: cmd = 0, num = 0, mode = 3, fd = -1
worker: recv: cmd = 3, num = 0, mode = 0, fd = -1
worker: send: cmd = 0, num = 0, mode = 1, fd = -1
worker: recv: cmd = 3, num = 0, mode = 0, fd = -1
worker: send: cmd = 0, num = 0, mode = 2, fd = -1
worker: recv: cmd = 3, num = 0, mode = 0, fd = -1
snd0 pst=cfg: rsnd/0: failed to open audio device
sock,rmsg,widl: closing
sock(sock|zom): destroyed
sock(sock|zom): processed in 484951us
helper: recv: cmd = 0, num = 0, mode = 2, fd = -1
helper: send: cmd = 3, num = 0, mode = 0, fd = -1
helper(helper|ini): processed in 121169us
This is an ancient Thinkpad 380D laptop. Sound was working
before OpenBSD. Some time ago I installed OpenBSD 6.0,
and the last couple of days I have updated 6.1, 6.2.,... up to 6.5
Permissions:
petal# ls -la /dev/sound*
lrwxr-xr-x 1 root wheel 6 Jan 14 2018 /dev/sound -> sound0
crw-rw-rw- 1 root wheel 42, 0 Jan 14 2018 /dev/sound0
crw-rw-rw- 1 root wheel 42, 1 Jan 14 2018 /dev/sound1
crw-rw-rw- 1 root wheel 42, 2 Jan 14 2018 /dev/sound2
petal# ls -la /dev/audio*
crw-rw-rw- 1 root wheel 42, 0 May 12 17:37 /dev/audio0
crw-rw-rw- 1 root wheel 42, 1 May 12 17:37 /dev/audio1
crw-rw-rw- 1 root wheel 42, 2 May 12 17:37 /dev/audio2
crw-rw-rw- 1 root wheel 42, 192 May 12 17:37 /dev/audioctl0
crw-rw-rw- 1 root wheel 42, 193 May 12 17:37 /dev/audioctl1
crw-rw-rw- 1 root wheel 42, 194 May 12 17:37 /dev/audioctl2
/etc/group says that I (user) am in wheel.
While being still being in OpenBSD 6.0 I followed part of the
installation instructions from http://www.sndio.org/install.html
(yes, for linux) and typed
#mkdir /var/run/sndiod
#useradd -g audio -s /sbin/nologin -d /var/run/sndiod sndiod
Here is dmesg:
OpenBSD 6.5 (GENERIC) #1: Wed Apr 24 22:04:27 CEST 2019
r...@syspatch-65-i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem = 83378176 (79MB)
avail mem = 66617344 (63MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 09/02/99, BIOS32 rev. 0 @ 0xfd860
apm0 at bios0: Power Management spec V1.2
pcibios0 at bios0: rev 2.1 @ 0xfd8a0/0x800
pcibios0: PCI BIOS has 2 Interrupt Routing table entries
pcibios0: PCI Exclusive IRQs: 11
pcibios0: PCI Interrupt Router at 000:01:0 ("Intel 82371 ISA and IDE" rev 0x00)
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc/0x8000
cpu0 at mainbus0: (uniprocessor)
cpu0: Intel Pentium/MMX ("GenuineIntel" 586-class) 153 MHz, 05-04-04
cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,MMX,MELTDOWN
cpu0: F00F bug workaround installed
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82437MX" rev 0x02
pcib0 at pci0 dev 1 function 0 "Intel 82371 ISA and IDE" rev 0x03
vga1 at pci0 dev 3 function 0 "Neomagic Magicgraph 128ZV" rev 0x02
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcic3 at pci0 dev 19 function 0 "Cirrus Logic CL-PD6729" rev 0x07
pcic3 controller 0: has sockets A and B
pcmcia0 at pcic3 controller 0 socket 0
pcmcia1 at pcic3 controller 0 socket 1
wdc2 at pcmcia1 function 0 "Key Technology Corp., FC1307 " port 0x400/16: irq 3
wd0 at wdc2 channel 0 drive 0:
wd0: 1-sector PIO, LBA, 968MB, 1984000 sectors
wd1 at wdc2 channel 0 drive 1:
wd1: 1-sector PIO, CHS, 68MB, 1024 cyl, 8 head, 17 sec, 139264 sectors
wd0(wdc2:0:0): using BIOS timings
wd1(wdc2:0:1): using BIOS timings
pcic3: interrupting at irq 4
pcic3: irq 4, polling enabled
isa0 at pcib0
isadma0 at isa0
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
com0: irq 4 already in use
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
wdc0 at isa0 port 0x1f0/8 irq 14
wd2 at wdc0 channel 0 drive 0:
wd2: 16-sector PIO, LBA, 3909MB, 8007552 sectors
atapiscsi0 at wdc0 channel 0 drive 1
scsibus1
Stunnel 5.44 server side 'exec = pppd' runs second child 'pppd' process after reconnection
I'm trying to make stunnel wrapped ppp connection to achieve bidirectional data transfer over stunnel like shown below. Stunnel client --connect-->Stunnel server pppd client --connect-->pppd server 10.0.1.2 <--data--> 10.0.1.1 OpenBSD 6.4amd64 with Stunnel 5.44 server works till stunnel retries 'exec = pppd' section once stunnel client is reconnected. 'exec = pppd' section retries after a short network related communication lag also. Previous 'pppd' child instance haven't killed by stunnel 5.44 before new instance started. So second 'pppd' process started and runs simultaneously with the first 'pppd' and link down. Restarting Stunnel server can clear child 'pppd' processes. So newly reestablished 'pppd' link between 10.0.1.1 <--> 10.0.1.2 endpoints works till next interconnection. Does stunnel server have an option to start only one instance in 'exec' section or what should be done to fix this? Any suggestions highly appreciated. # ps -axu | grep pppd user 43231 0.0 0.0 476 0:00.01 persist lock passive 10.0.1.1:10.0.1.2 local noauth (pppd) user 39187 0.0 0.0 468 0:00.01 persist lock passive 10.0.1.1:10.0.1.2 local noauth (pppd) # tail -n 10 /var/log/daemon pppd[39187] pppd 2.3.5 started by user, uid 0 pppd[43231] Using interface ppp1 pppd[43231] Connect: ppp0 <--> /dev/ttyp2 pppd[43231] Local IP address 10.0.1.1 pppd[43231] Remote IP address 10.0.1.2 pppd[39187] pppd 2.3.5 started by user, uid 0 pppd[39187] Using interface ppp0 pppd[39187] Connect: ppp0 <--> /dev/ttyp5 pppd[39187] Couldn't set interface address: Address 10.0.1.1 or destination 10.0.1.2 already exists Stunnel configurations for server and client: 1. Server's configuration ... foreground = yes debug = 7 socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 ;socket = l:SO_LINGER=1:60 ; Session cache sessionCacheSize = 100 sessionCacheTimeout = 600 stack = 65536 TIMEOUTbusy = 600 TIMEOUTconnect = 10 TIMEOUTidle = 43200 TIMEOUTclose = 5 [ppp] accept = LOCAL-IP:PORT exec = /usr/sbin/pppd execargs = lock 10.0.1.1:10.0.1.2 local debug noauth ;execargs = lock passive 10.0.1.1:10.0.1.2 local debug noauth pty = yes CAfile = ca.crt cert = server.crt key = server.key verifyChain = yes 2. Stunnel client's configuration ... foreground = yes debug = 7 socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 ; Session cache sessionCacheSize = 1 sessionCacheTimeout = 600 failover = rr [ppp] client = yes retry = yes connect = REMOTE-IP:PORT exec = /usr/sbin/pppd execargs = defaultroute persist lock passive 10.0.1.2:10.0.1.1 local debug noauth name ppp-client pty = yes CAfile = ca.crt cert = client.crt key = client.key verifyChain = yes checkHost = REMOTE-HOSTNAME ;checkIP = 1.2.3.4
Re: When will be created a great desktop experience for OpenBSD?
On Mon, May 13, 2019 at 02:04:13PM -0400, Nathan Hartman wrote: > On Mon, May 13, 2019 at 1:26 PM Steve Litt > wrote: > > > As I travel this earth I continue to be amazed at peoples' fascination > > with tiny fonts. Perhaps that's to pack more stuff on the screen. But > > then they go on to make the text low contrast in the name of "pretty", > > thereby locking out those who can't correct to 20/20. And just to rub > > salt in the wounds, they always make their tiny black background > > terminals transparent, so random noise can confuse further. > > > > SteveT > > > I am similarly amazed. > > User interfaces have gotten progressively > worse over the last 15 years and the trend > continues. Nowadays, computer interfaces are designed for people who don't know nor care about computers. Different times... -- Antoine
Re: When will be created a great desktop experience for OpenBSD?
On Mon, May 13, 2019 at 1:26 PM Steve Litt wrote: > As I travel this earth I continue to be amazed at peoples' fascination > with tiny fonts. Perhaps that's to pack more stuff on the screen. But > then they go on to make the text low contrast in the name of "pretty", > thereby locking out those who can't correct to 20/20. And just to rub > salt in the wounds, they always make their tiny black background > terminals transparent, so random noise can confuse further. > > SteveT I am similarly amazed. User interfaces have gotten progressively worse over the last 15 years and the trend continues. >
Re: samba : snapshots of 6.5
hi all ! yesterday i newly installed openbsd snapshots , i managed to start samba . hi# date ; /etc/rc.d/samba start ; date Tue May 14 02:36:22 JST 2019 smbd(ok) nmbd(ok) Tue May 14 02:36:48 JST 2019 namely 26 seconds hi# hi# testparm rlimit_max: increasing rlimit_max (128) to minimum Windows limit (16384) Registered MSG_REQ_POOL_USAGE Registered MSG_REQ_DMALLOC_MARK and LOG_CHANGED Load smb config files from /etc/samba/smb.conf rlimit_max: increasing rlimit_max (128) to minimum Windows limit (16384) Processing section "[homes]" Processing section "[printers]" Loaded services file OK. Server role: ROLE_STANDALONE Press enter to see a dump of your service definitions # Global parameters [global] dns proxy = No log file = /var/log/samba/smbd.%m max log size = 50 server role = standalone server server string = Samba Server idmap config * : backend = tdb [homes] browseable = No comment = Home Directories read only = No [printers] browseable = No comment = All Printers path = /var/spool/samba printable = Yes - regards
Re: When will be created a great desktop experience for OpenBSD?
On Fri, 10 May 2019 23:32:18 +0200 ropers wrote: > On 08/05/2019, Steve Litt wrote: > > ...you'd better crank way up on its fonts. Fvwm fonts > > are so small that if you have bad vision, you can't read the screen > > well enough to increase the font size. > > > > It's easy for a well-sighted person to reduce fonts, but for the > > poorly sighted person who can't read the screen in the first place, > > it's a long, difficult process. > > Have you or has anyone ever set up Compiz zoom (Enhanced Zoom Desktop > in ccsm) on an OpenBSD box? I don't even know what Desktop > Environments and Window Managers would be compatible with it, and this > isn't something I have tried, but it may be worth investigating in > your situation. Not really. How do I set up or enable compiz (if I even wanted it) if I can't read the screen's 9point low contrast fonts? As I travel this earth I continue to be amazed at peoples' fascination with tiny fonts. Perhaps that's to pack more stuff on the screen. But then they go on to make the text low contrast in the name of "pretty", thereby locking out those who can't correct to 20/20. And just to rub salt in the wounds, they always make their tiny black background terminals transparent, so random noise can confuse further. SteveT
ANN: pledge(1) security utility
**SPLASH** I've been made to walk the plank! *hastily assembles flotilla of blowfish* https://fremissant.net/pledge https://marc.info/?l=openbsd-tech=155762556220352=2 Your captain (master?) has spoken, and you are not allowed to know under which promises the processes on your system are running (though you can try to grep for this information in the sources if you have source). Not even if you are root; and not even yourself (pid 0). Or, you can run my patch and have all this and more, safely. It is compliant with the pledge mandate that promises can never be increased, and indeed with all the intricacies of pledge(2) semantics. [If it isn't, please send an email.] I don't much care who runs it besides me, though I do sense this is a pivotal project: either everything I ever did will get released after this, or silence. This gesture in particular was made to increase the security of my own system, learn some systems programming, and above all as an expression of my appreciation for UNIX generally. If it helps others to any of those things, so much the better. I'll keep the project pages (link at top) up to date, and decide the pledge(1) licence soon. I've uploaded a patched amd64 kernel image (built from mid-April OpenBSD -current sources), as well as compatible pledge(1) executable, in case you want to play in a VM. I've not installed 6.5 locally yet, but when I do I'll update the available images. If this work interests you, by all means feel free to contact me privately, you probably won't find me on the lists. Cheerio, Andy.
Re: Blind OpenBSD users
On 05/13/19 08:49, Aaron Bieber wrote: On Mon, 13 May 2019 at 11:24:57 +0300, Dumitru Moldovan wrote: On Fri, May 10, 2019 at 08:05:08AM -0600, Aaron Bieber wrote: Hi misc@! I am looking to understand / enhance the OpenBSD experience for blind users. Do we have any blind users reading misc that can offer any insight into their usecases / pain points / work flows / wants? I am sure OpenBSD is lacking on this front, so use cases in *nix would also be helpful. [...] Hope that helps! Not a blind user here... Also, was hoping someone more knowledgeable would step in to answer. As far as I can tell, there is no a11y support in OpenBSD's native console, so it seems blind users can only use graphical applications under OpenBSD. Thanks for the info! I am not blind but until recent surgery, I was severely visually handicaped and I offer one piece of advice from my experience: Ensure that every piece of text can be increased in size (or the underlying fonts increased). It was very frustrating to have to reach for my magnifying glasses when informative/error messages came up much smaller that my default setting. N.
Re: Blind OpenBSD users
On Mon, 13 May 2019 at 11:24:57 +0300, Dumitru Moldovan wrote: > On Fri, May 10, 2019 at 08:05:08AM -0600, Aaron Bieber wrote: > > Hi misc@! > > > > I am looking to understand / enhance the OpenBSD experience for blind users. > > > > Do we have any blind users reading misc that can offer any insight into > > their > > usecases / pain points / work flows / wants? I am sure OpenBSD is lacking on > > this front, so use cases in *nix would also be helpful. > > I've worked for the GNOME project as a translator some years ago. I > know from the strings I've translated that they worked hard on a11y > (accessibility). I don't use GNOME anymore (except through its most > basic libs, such as GTK+), but I think it's usable under OpenBSD. > > A couple of links to get you going: > * https://help.gnome.org/users/gnome-help/stable/a11y.html.en > * https://wiki.gnome.org/Accessibility > > KDE has a similar a11y initiative, but it seems less entrenched than > GNOME's one: https://userbase.kde.org/System_Settings/Accessibility. > Even their tutorial suggests using the KDE apps under a GNOME desktop > when using a screen reader: > https://techbase.kde.org/Development/Tutorials/Accessibility/Screen_Reader_Setup#Screen_Readers > > Another interesting link I've found, touching on both GNOME and KDE, > but also listing alternatives to GNOME's Orca screen reader: > https://www.freedesktop.org/wiki/Accessibility/. > > Hope that helps! Not a blind user here... Also, was hoping someone > more knowledgeable would step in to answer. As far as I can tell, > there is no a11y support in OpenBSD's native console, so it seems blind > users can only use graphical applications under OpenBSD. Thanks for the info! > -- PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE
Re: i3bar not working after 6.5 upgrade
On May 13, 2019 2:58 AM, shadrock uhuru wrote: > > > > On 5/13/19 1:35 AM, shadrock uhuru wrote: > > hi everyone > > since upgrading to 6.5 my i3bar no longer works. > > i have not changed the configuration in any way > > when i run the i3status command manually in a terminal the bar is not > > displayed but the correct infomation that would be on the i3bar is > > echoed to the terminal. > > the message on the right hand of the i3bar is > > error: status_command not found or is missing a library dependency > > (exit 127) > > the left hand side of the bar is functioning correctly > > the following is from the i3 log file. > > > > grep i3bar 'i3log-2019-05-12-0-41-37' > > > > 05/12/19 00:41:40 - config_parser.c:parse_config:267 - CONFIG(line > > 152): # Start i3bar to display a workspace bar (plus the system > > information i3status > > 05/12/19 00:41:41 - Starting bar process: i3bar --bar_id=bar-0 > > --socket="/tmp/i3-shadrock.Q7Rfx2/ipc-socket.80799" > > 05/12/19 00:41:41 - executing: i3bar --bar_id=bar-0 > > --socket="/tmp/i3-shadrock.Q7Rfx2/ipc-socket.80799" > > 05/12/19 00:41:41 - WM_CLASS changed to i3bar (instance), i3bar (class) > > 05/12/19 00:41:41 - WM_NAME changed to "i3bar for output LVDS-1" > > 05/12/19 00:41:41 - Checking window 0x00e3 (class i3bar) > > 05/12/19 00:41:41 - Checking window 0x00e3 (class i3bar) > > [/usr/obj/ports/i3-4.16.1/i3-4.16.1/../i3-4.16.1/i3bar/src/child.c:468] > > ERROR: Child (pid: 72679) unexpectedly exited with status 127 > > > > > how do i debug for a missing library ? > shadrock > LD_DEBUG=1
Re: 6.5 : console font : no spleen?
On Mon, May 13, 2019 at 09:38:43AM +, Mayuresh Kathe wrote: > i thought "spleen" was made the new default console > font under 6.5+, it doesn't look like it's there on > my fresh install under amd64? It does if you have an EFI install (w/ efifb(4)), or have a graphics device supported by inteldrm(4) or radeondrm(4). (But you didn't send a dmesg, so ...)
6.5 : console font : no spleen?
i thought "spleen" was made the new default console font under 6.5+, it doesn't look like it's there on my fresh install under amd64?
Re: Blind OpenBSD users
On Fri, May 10, 2019 at 08:05:08AM -0600, Aaron Bieber wrote: Hi misc@! I am looking to understand / enhance the OpenBSD experience for blind users. Do we have any blind users reading misc that can offer any insight into their usecases / pain points / work flows / wants? I am sure OpenBSD is lacking on this front, so use cases in *nix would also be helpful. I've worked for the GNOME project as a translator some years ago. I know from the strings I've translated that they worked hard on a11y (accessibility). I don't use GNOME anymore (except through its most basic libs, such as GTK+), but I think it's usable under OpenBSD. A couple of links to get you going: * https://help.gnome.org/users/gnome-help/stable/a11y.html.en * https://wiki.gnome.org/Accessibility KDE has a similar a11y initiative, but it seems less entrenched than GNOME's one: https://userbase.kde.org/System_Settings/Accessibility. Even their tutorial suggests using the KDE apps under a GNOME desktop when using a screen reader: https://techbase.kde.org/Development/Tutorials/Accessibility/Screen_Reader_Setup#Screen_Readers Another interesting link I've found, touching on both GNOME and KDE, but also listing alternatives to GNOME's Orca screen reader: https://www.freedesktop.org/wiki/Accessibility/. Hope that helps! Not a blind user here... Also, was hoping someone more knowledgeable would step in to answer. As far as I can tell, there is no a11y support in OpenBSD's native console, so it seems blind users can only use graphical applications under OpenBSD.
Re: i3bar not working after 6.5 upgrade
On 5/13/19 1:35 AM, shadrock uhuru wrote: > hi everyone > since upgrading to 6.5 my i3bar no longer works. > i have not changed the configuration in any way > when i run the i3status command manually in a terminal the bar is not > displayed but the correct infomation that would be on the i3bar is > echoed to the terminal. > the message on the right hand of the i3bar is > error: status_command not found or is missing a library dependency > (exit 127) > the left hand side of the bar is functioning correctly > the following is from the i3 log file. > > grep i3bar 'i3log-2019-05-12-0-41-37' > > 05/12/19 00:41:40 - config_parser.c:parse_config:267 - CONFIG(line > 152): # Start i3bar to display a workspace bar (plus the system > information i3status > 05/12/19 00:41:41 - Starting bar process: i3bar --bar_id=bar-0 > --socket="/tmp/i3-shadrock.Q7Rfx2/ipc-socket.80799" > 05/12/19 00:41:41 - executing: i3bar --bar_id=bar-0 > --socket="/tmp/i3-shadrock.Q7Rfx2/ipc-socket.80799" > 05/12/19 00:41:41 - WM_CLASS changed to i3bar (instance), i3bar (class) > 05/12/19 00:41:41 - WM_NAME changed to "i3bar for output LVDS-1" > 05/12/19 00:41:41 - Checking window 0x00e3 (class i3bar) > 05/12/19 00:41:41 - Checking window 0x00e3 (class i3bar) > [/usr/obj/ports/i3-4.16.1/i3-4.16.1/../i3-4.16.1/i3bar/src/child.c:468] > ERROR: Child (pid: 72679) unexpectedly exited with status 127 > > how do i debug for a missing library ? shadrock
i3bar not working after 6.5 upgrade
hi everyone since upgrading to 6.5 my i3bar no longer works. i have not changed the configuration in any way when i run the i3status command manually in a terminal the correct information that would be on the i3bar is echoed to the terminal. the message on the right hand of the i3bar is error: status_command not found or is missing a library dependency (exit 127) the left hand side of the bar displays the workspace the following is from the i3 log file. grep i3bar 'i3log-2019-05-12-0-41-37' 05/12/19 00:41:40 - config_parser.c:parse_config:267 - CONFIG(line 152): # Start i3bar to display a workspace bar (plus the system information i3status 05/12/19 00:41:41 - Starting bar process: i3bar --bar_id=bar-0 --socket="/tmp/i3-shadrock.Q7Rfx2/ipc-socket.80799" 05/12/19 00:41:41 - executing: i3bar --bar_id=bar-0 --socket="/tmp/i3-shadrock.Q7Rfx2/ipc-socket.80799" 05/12/19 00:41:41 - WM_CLASS changed to i3bar (instance), i3bar (class) 05/12/19 00:41:41 - WM_NAME changed to "i3bar for output LVDS-1" 05/12/19 00:41:41 - Checking window 0x00e3 (class i3bar) 05/12/19 00:41:41 - Checking window 0x00e3 (class i3bar) [/usr/obj/ports/i3-4.16.1/i3-4.16.1/../i3-4.16.1/i3bar/src/child.c:468] ERROR: Child (pid: 72679) unexpectedly exited with status 127
Re: NSD & Unbound refusing to bind to IPv6 when anycast flag set ?
(moving from misc to tech)
On 2019-05-11, Rachel Roch wrote:
> I'm still learning IPv6 intricacies, so forgive me if this is a silly
> question.
>
> When I have interfaces set in the standard manner, e.g.:
>
> inet6 2001:DB8:beef::1 128
> up
>
> NSD and Unbound will bind to that address without problem.
>
> However if I add the anycast flag:
> inet6 2001:DB8:beef::1 128 anycast
> up
>
> and then destroy and re-create the interfaces and pkill and relaunch unbound
> and NSD, they both complain bitterly:
>
> [2019-05-11 21:00:51.665] nsd[43360]: notice: nsd starting (NSD 4.1.27)
> [2019-05-11 21:00:51.666] nsd[43360]: error: can't bind udp socket: Can't
> assign requested address
> [2019-05-11 21:00:51.666] nsd[43360]: error: server initialization failed,
> nsd could not be started
> [1557604863] unbound[69433:0] error: can't bind socket: Can't assign
> requested address for 2001:DB8:beef::1 port 53[1557604863] unbound[69433:0]
> fatal error: could not open ports
>
> The interface shows correctly in ifconfig so I don't know what the problem is
> ?
>
> This is on OpenBSD 6.5 if it makes any difference.
>
>
RFC3513 says this:
o An anycast address must not be used as the source address of
an IPv6 packet.
o An anycast address must not be assigned to an IPv6 host, that
is, it may be assigned to an IPv6 router only.
And to help ensure this, the kernel denies binding to an address marked
with the anycast flag (see netinet6/in6_pcb.c).
This was obsoleted by RFC4291, including this change:
o The restrictions on using IPv6 anycast addresses were removed because
there is now sufficient experience with the use of anycast addresses,
the issues are not specific to IPv6, and the GROW working group is
working in this area.
So I think this restriction can now be removed, at least with this
change, but more might be needed.
Index: in6_pcb.c
===
RCS file: /cvs/src/sys/netinet6/in6_pcb.c,v
retrieving revision 1.108
diff -u -p -r1.108 in6_pcb.c
--- in6_pcb.c 4 Oct 2018 17:33:41 - 1.108
+++ in6_pcb.c 13 May 2019 07:28:02 -
@@ -185,10 +185,6 @@ in6_pcbaddrisavail(struct inpcb *inp, st
sin6->sin6_port = lport;
/*
-* bind to an anycast address might accidentally
-* cause sending a packet with an anycast source
-* address, so we forbid it.
-*
* We should allow to bind to a deprecated address,
* since the application dare to use it.
* But, can we assume that they are careful enough
@@ -197,8 +193,8 @@ in6_pcbaddrisavail(struct inpcb *inp, st
* flag to control the bind(2) behavior against
* deprecated addresses (default: forbid bind(2)).
*/
- if (ifa && ifatoia6(ifa)->ia6_flags & (IN6_IFF_ANYCAST|
- IN6_IFF_TENTATIVE|IN6_IFF_DUPLICATED|IN6_IFF_DETACHED))
+ if (ifa && ifatoia6(ifa)->ia6_flags & (IN6_IFF_TENTATIVE|
+ IN6_IFF_DUPLICATED|IN6_IFF_DETACHED))
return (EADDRNOTAVAIL);
}
if (lport) {
Re: amd64 May 12 snapshot: extent_alloc_region: extent `ioport' (0x0 - 0xffff)
Hi, On Sun, May 12, 2019 at 11:42:00PM -0700, Greg Steuck wrote: > My snapshot installation routine[1] worked for May 11th snapshots and > breaks on May 12. I have a reason to suspect fowl play by QEMU (running on > Linux) because I can only trigger the error when the same instance that > just finished the install then fails to reboot into a newly installed > system. If I boot the image into a separate qemu instance, it boots > just fine. > [1] > https://github.com/google/syzkaller/blob/master/tools/create-openbsd-gce-ci.sh > > Here's the panic fragment in case it helps somebody to diagnose the issue. > Because the whole script is running in expect(1) I can't easily get a more > complete log > extent_alloc_region: extent `ioport' (0x0 - 0x) > extent_alloc_region: start 0x397d08e8, end 0x397d08e80001 > panic: extent_alloc_region: region lies outside extent > Stopped at db_enter+0x10: popq%rbp > TIDPIDUID PRFLAGS PFLAGS CPU COMMAND > * 0 0 0 0x1 0x2000K swapper > db_enter(10,820078f0,282,8,81939c80,820078f0) at > db_enter+0x10 > panic(81acd0d7,81acd0d7,397d08e8,81d69140,397d08e80001,2) > at panic+0x128 > extent_alloc_region(81d69140,397d08e8,2,10,3ced4451d34a019e,16) > at extent_alloc_region+0x31b > bus_space_map(81c38c68,397d08e8,2,0,80021510,81c38c68) > at bus_space_map+0x96 > acpi_map_pmregs(80021400,80021400,b296f5ec31720e1a,800022000850,80021400,80021478) > at acpi_map_pmregs+0x222 > acpi_attach_common(80021400,f6850,8538a42a2600eff,80023180,82007c58,81d0d6b0) > at acpi_attach_common+0x1b5 > config_attach(80023180,81d09848,82007c58,816f9240,75168f425d9711b9,50) > at config_attach+0x1ee > bios_attach(80023100,80023180,82007db8,80023100,e7cf2825b72b017d,80023100) > at bios_attach+0x71d > config_attach(80023100,81d043a0,82007db8,815dd580,75168f425da54253,82007db8) > at config_attach+0x1ee > mainbus_attach(0,80023100,0,0,7baefe45dce7d4a4,0) at > mainbus_attach+0x8 Try the following fix by kettenis@ committed yesterday: https://marc.info/?l=openbsd-cvs=155767639531163=2
Re: EDIT: When will be created a user-friendly and easy-to-use variant for OpenBSD?
This. 1000+ On 5/12/19 11:15 PM, Christopher Turkel wrote: OpenBSD is use friendly and easy to use On Sunday, May 12, 2019, Quantum Robin wrote: In 2019 still there is not a user-friendly and easy-to-use variant of OpenBSD. However, the new "OS108" is seeking to improve this with a NetBSD operating system paired with the MATE desktop environment. So, OS108, a derivative of NetBSD, has just been released: https://os108.org/?ez_cid=CLIENT_ID(AMP_ECID_EZOIC) When will be created a user-friendly and easy-to-use variant for OpenBSD?
amd64 May 12 snapshot: extent_alloc_region: extent `ioport' (0x0 - 0xffff)
My snapshot installation routine[1] worked for May 11th snapshots and breaks on May 12. I have a reason to suspect fowl play by QEMU (running on Linux) because I can only trigger the error when the same instance that just finished the install then fails to reboot into a newly installed system. If I boot the image into a separate qemu instance, it boots just fine. [1] https://github.com/google/syzkaller/blob/master/tools/create-openbsd-gce-ci.sh Here's the panic fragment in case it helps somebody to diagnose the issue. Because the whole script is running in expect(1) I can't easily get a more complete log extent_alloc_region: extent `ioport' (0x0 - 0x) extent_alloc_region: start 0x397d08e8, end 0x397d08e80001 panic: extent_alloc_region: region lies outside extent Stopped at db_enter+0x10: popq%rbp TIDPIDUID PRFLAGS PFLAGS CPU COMMAND * 0 0 0 0x1 0x2000K swapper db_enter(10,820078f0,282,8,81939c80,820078f0) at db_enter+0x10 panic(81acd0d7,81acd0d7,397d08e8,81d69140,397d08e80001,2) at panic+0x128 extent_alloc_region(81d69140,397d08e8,2,10,3ced4451d34a019e,16) at extent_alloc_region+0x31b bus_space_map(81c38c68,397d08e8,2,0,80021510,81c38c68) at bus_space_map+0x96 acpi_map_pmregs(80021400,80021400,b296f5ec31720e1a,800022000850,80021400,80021478) at acpi_map_pmregs+0x222 acpi_attach_common(80021400,f6850,8538a42a2600eff,80023180,82007c58,81d0d6b0) at acpi_attach_common+0x1b5 config_attach(80023180,81d09848,82007c58,816f9240,75168f425d9711b9,50) at config_attach+0x1ee bios_attach(80023100,80023180,82007db8,80023100,e7cf2825b72b017d,80023100) at bios_attach+0x71d config_attach(80023100,81d043a0,82007db8,815dd580,75168f425da54253,82007db8) at config_attach+0x1ee mainbus_attach(0,80023100,0,0,7baefe45dce7d4a4,0) at mainbus_attach+0x8 Complete log: + today=may12 + IP=35.238.236.99 + IMAGE=ci-openbsd-may12-root + INSTANCE=ci-openbsd + /usr/local/google/home/gnezdo/s/syzkaller/tools/create-openbsd-gce-ci.sh % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 404M 100 404M0 0 107M 0 0:00:03 0:00:03 --:--:-- 107M install.site etc/installurl etc/rc.conf.local etc/rc.local etc/sysctl.conf 1+0 records in 1+0 records out 4096 bytes (4.1 kB, 4.0 KiB) copied, 0.000239465 s, 17.1 MB/s Executing 'genisoimage -C 16,207248 -M /dev/fd/3 -l -R -graft-points /6.5/amd64/site65.tgz=site65.tgz /auto_install.conf=auto_install.conf /disklabel.template=disklabel.template /etc/boot.conf=boot.conf /etc/random.seed=random.seed | builtin_dd of=install65-amd64-patched.iso obs=32k seek=12953' I: -input-charset not specified, using utf-8 (detected in locale settings) Rock Ridge signatures found Total translation table size: 0 Total rockridge attributes bytes: 2521 Total directory bytes: 8192 Path table size(bytes): 48 Max brk space used 0 207433 extents written (405 MB) builtin_dd: 192*2KB out @ average infx1352KBps install65-amd64-patched.iso: copying volume descriptor(s) Formatting 'disk.raw', fmt=raw size=10737418240 spawn qemu-system-x86_64 -nographic -smp 2 -drive if=virtio,file=disk.raw,format=raw -cdrom install65-amd64-patched.iso -net nic,model=virtio -net user -boot once=d -m 4000 -enable-kvm >> OpenBSD/amd64 CDBOOT 3.43 boot> booting cd0a:/6.5/amd64/bsd.rd: 3695441+1532928+3889016+0+593920 [372197+128+451296+300417]=0xa57ad0 entry point at 0x81001000 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2019 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.5-current (RAMDISK_CD) #17: Sun May 12 01:00:54 MDT 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 4177387520 (3983MB) avail mem = 4046807040 (3859MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf68a0 (11 entries) bios0: vendor SeaBIOS version "1.10.2-1" date 04/01/2014 bios0: QEMU Standard PC (i440FX + PIIX, 1996) acpi0 at bios0: rev 0 acpi0: tables DSDT FACP APIC HPET acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: QEMU Virtual CPU version 2.5+, 2594.27 MHz, 06-06-03 cpu0: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,x2APIC,HV,NXE,LONG,LAHF,MELTDOWN cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: apic clock running at 999MHz cpu
ftp.usa.openbsd.org mirror unavailable Monday afternoon through Wednesday morning
RIT is doing two overnight power outages again starting 5pm (EDT) Monday May 13th. Accordingly, ftp5.usa.openbsd.org (which is also ftp3.usa.openbsd.org and ftp.usa.openbsd.org) will be down from Monday Afternoon until the power comes back on Wednesday morning on May 15th. --Kurt Mosiejczuk
