Take it from someone who has been working with ports on OpenBSD for 12+
years, FLAVORs are not the answer.
Unless you have an idea about how to get rid of W+X mappings in WebKit
and py-cryptography, just mount /home with wxallowed, or use a different
filesystem for home directories for users that need virtualenv.
You could use /usr/local/home if you don't want an extra filesystem.
Monday, April 30, 2018
artwork.html not listing 6.3 release
Hi All,
I noticed the 6.3 release is not listed here:
https://www.openbsd.org/artwork.html
I'm assuming it would be listed and would link here:
https://www.openbsd.org/63.html
Sorry for the noise if 6.3 is intentionally absent from the artwork page.
I noticed the 6.3 release is not listed here:
https://www.openbsd.org/artwork.html
I'm assuming it would be listed and would link here:
https://www.openbsd.org/63.html
Sorry for the noise if 6.3 is intentionally absent from the artwork page.
Re: no route to host (when there is a route )
I'm not an expert but i had same issue while using 6.1 as a guest os on a
kvm.
I updated to 6.2 and problem vanished.
On Tue, 1 May 2018, 09:07 Tom Smyth, <tom.smyth@wirelessconnect.eu> wrote:
> Hello,
>
> I have encountered this issue for a while, it happens irregularly
> on my systems on this lan
> basically when the issue occurs
> I cant route out the interface with the default route on it,
> I cant ping the gateway
> I cant see the arp of the gateway
> but i can see the routes installed in the routing table
>
>
> are there other commands I should be looking at to debug it more
> Im using
>
> ifconfig
> arp
> route
>
> when i run run sh /etc/netstart em0
> then normal operation returns
>
> The only (unusual network config) im using is that im deploying
> more specific static routes (than the connected route) to allow
> clients on a non broadcast network to route to each other
> ie if a client wants to talk to another client send packet to default
> gateway
> (icmp redirects are off on the gateway)
>
> the output of ping and arp when it happens are as follows
> # ping 5.134.92.1
> PING 5.134.92.1 (5.134.92.1): 56 data bytes
> ping: sendto: No route to host
> ping: wrote 5.134.92.1 64 chars, ret=-1
> ping: sendto: No route to host
> ping: wrote 5.134.92.1 64 chars, ret=-1
> ping: sendto: No route to host
> ping: wrote 5.134.92.1 64 chars, ret=-1
> --- 5.134.92.1 ping statistics ---
> 3 packets transmitted, 0 packets received, 100.0% packet loss
>
> #ifconfig em0
> em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> lladdr 00:0d:b9:46:33:50
> index 1 priority 0 llprio 3
> groups: egress
> media: Ethernet autoselect (100baseTX full-duplex)
> status: active
> inet 5.134.92.142 netmask 0xfffffc00 broadcast 5.134.95.255
>
>
>
>
>
> below is an output of the routing table when it is not working
>
> # route -n -T0 show
> Routing tables
>
> Internet:
> Destination Gateway Flags Refs Use Mtu Prio
> Iface
> default 5.134.92.1 UGS 2 78893 - 8 em0
> 224/4 127.0.0.1 URS 0 609 32768 8 lo0
> 5.134.92/22 5.134.92.142 UC 0 0 - 4 em0
> 5.134.92/23 5.134.92.1 UGS 0 80897 - 8 em0
> 5.134.94/23 5.134.92.1 UGS 0 396 - 8 em0
> 5.134.92.142 00:0d:b9:46:33:50 UHLl 0 52 - 1 em0
> 5.134.95.255 5.134.92.142 UHb 0 0 - 1 em0
> 127/8 127.0.0.1 UGRS 0 0 32768 8 lo0
> 127.0.0.1 127.0.0.1 UHl 1 6 32768 1 lo0
> 185.55.204/23 5.134.92.1 UGS 0 24 - 8 em0
> 185.55.206/23 5.134.92.1 UGS 0 21 - 8 em0
>
> Internet6:
> Destination Gateway
> Flags Refs Use Mtu Prio Iface
> ::/96 ::1 UGRS
> 0 0 32768 8 lo0
> ::/104 ::1 UGRS
> 0 0 32768 8 lo0
> ::1 ::1 UHl
> 14 14 32768 1 lo0
> ::127.0.0.0/104 ::1 UGRS
> 0 0 32768 8 lo0
> ::224.0.0.0/100 ::1 UGRS
> 0 0 32768 8 lo0
> ::255.0.0.0/104 ::1 UGRS
> 0 0 32768 8 lo0
> ::ffff:0.0.0.0/96 ::1 UGRS
> 0 0 32768 8 lo0
> 2002::/24 ::1 UGRS
> 0 0 32768 8 lo0
> 2002:7f00::/24 ::1 UGRS
> 0 0 32768 8 lo0
> 2002:e000::/20 ::1 UGRS
> 0 0 32768 8 lo0
> 2002:ff00::/24 ::1 UGRS
> 0 0 32768 8 lo0
> fe80::/10 ::1 UGRS
> 0 0 32768 8 lo0
> fec0::/10 ::1 UGRS
> 0 0 32768 8 lo0
> fe80::1%lo0 fe80::1%lo0 UHl
> 0 0 32768 1 lo0
> ff01::/16 ::1 UGRS
> 21 21 32768 8 lo0
> ff01::%lo0/32 ::1 Um
> 0 1 32768 4 lo0
> ff02::/16 ::1 UGRS
> 21 21 32768 8 lo0
> ff02::%lo0/32 ::1 Um
> 0 1 32768 4 lo0
>
>
>
> ---------------------------------------------
> ---------------------------------------------
>
> below is the output of the routing table when it is working
> # route -n -T0 show
> Routing tables
>
> Internet:
> Destination Gateway Flags Refs Use Mtu Prio
> Iface
> default 5.134.92.1 UGS 5 51573 - 8 em0
> 224/4 127.0.0.1 URS 0 1060 32768 8 lo0
> 5.134.92/22 5.134.92.142 UC 1 0 - 4 em0
> 5.134.92/23 5.134.92.1 UGS 0 116 - 8 em0
> 5.134.94/23 5.134.92.1 UGS 0 51 - 8 em0
> 5.134.92.1 de:10:0d:96:90:34 UHLc 5 180 - 4 em0
> 5.134.92.142 00:0d:b9:46:33:50 UHLl 0 80378 - 1 em0
> 5.134.95.255 5.134.92.142 UHb 0 0 - 1 em0
> 127/8 127.0.0.1 UGRS 0 0 32768 8 lo0
> 127.0.0.1 127.0.0.1 UHl 1 6 32768 1 lo0
> 185.55.204/23 5.134.92.1 UGS 0 12 - 8 em0
> 185.55.206/23 5.134.92.1 UGS 0 6 - 8 em0
>
> Internet6:
> Destination Gateway
> Flags Refs Use Mtu Prio Iface
> ::/96 ::1 UGRS
> 0 0 32768 8 lo0
> ::/104 ::1 UGRS
> 0 0 32768 8 lo0
> ::1 ::1 UHl
> 14 14 32768 1 lo0
> ::127.0.0.0/104 ::1 UGRS
> 0 0 32768 8 lo0
> ::224.0.0.0/100 ::1 UGRS
> 0 0 32768 8 lo0
> ::255.0.0.0/104 ::1 UGRS
> 0 0 32768 8 lo0
> ::ffff:0.0.0.0/96 ::1 UGRS
> 0 0 32768 8 lo0
> 2002::/24 ::1 UGRS
> 0 0 32768 8 lo0
> 2002:7f00::/24 ::1 UGRS
> 0 0 32768 8 lo0
> 2002:e000::/20 ::1 UGRS
> 0 0 32768 8 lo0
> 2002:ff00::/24 ::1 UGRS
> 0 0 32768 8 lo0
> fe80::/10 ::1 UGRS
> 0 0 32768 8 lo0
> fec0::/10 ::1 UGRS
> 0 0 32768 8 lo0
> fe80::1%lo0 fe80::1%lo0 UHl
> 0 0 32768 1 lo0
> ff01::/16 ::1 UGRS
> 21 21 32768 8 lo0
> ff01::%lo0/32 ::1 Um
> 0 1 32768 4 lo0
> ff02::/16 ::1 UGRS
> 21 21 32768 8 lo0
> ff02::%lo0/32 ::1 Um
> 0 1 32768 4 lo0
>
>
> em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> lladdr 00:0d:b9:46:33:50
> index 1 priority 0 llprio 3
> groups: egress
> media: Ethernet autoselect (100baseTX full-duplex)
> status: active
> inet 5.134.92.142 netmask 0xfffffc00 broadcast 5.134.95.255
>
>
>
> ----------------------------------------------------------------------------------
>
> ----------------------------------------------------------------------------------
>
>
>
kvm.
I updated to 6.2 and problem vanished.
On Tue, 1 May 2018, 09:07 Tom Smyth, <tom.smyth@wirelessconnect.eu> wrote:
> Hello,
>
> I have encountered this issue for a while, it happens irregularly
> on my systems on this lan
> basically when the issue occurs
> I cant route out the interface with the default route on it,
> I cant ping the gateway
> I cant see the arp of the gateway
> but i can see the routes installed in the routing table
>
>
> are there other commands I should be looking at to debug it more
> Im using
>
> ifconfig
> arp
> route
>
> when i run run sh /etc/netstart em0
> then normal operation returns
>
> The only (unusual network config) im using is that im deploying
> more specific static routes (than the connected route) to allow
> clients on a non broadcast network to route to each other
> ie if a client wants to talk to another client send packet to default
> gateway
> (icmp redirects are off on the gateway)
>
> the output of ping and arp when it happens are as follows
> # ping 5.134.92.1
> PING 5.134.92.1 (5.134.92.1): 56 data bytes
> ping: sendto: No route to host
> ping: wrote 5.134.92.1 64 chars, ret=-1
> ping: sendto: No route to host
> ping: wrote 5.134.92.1 64 chars, ret=-1
> ping: sendto: No route to host
> ping: wrote 5.134.92.1 64 chars, ret=-1
> --- 5.134.92.1 ping statistics ---
> 3 packets transmitted, 0 packets received, 100.0% packet loss
>
> #ifconfig em0
> em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> lladdr 00:0d:b9:46:33:50
> index 1 priority 0 llprio 3
> groups: egress
> media: Ethernet autoselect (100baseTX full-duplex)
> status: active
> inet 5.134.92.142 netmask 0xfffffc00 broadcast 5.134.95.255
>
>
>
>
>
> below is an output of the routing table when it is not working
>
> # route -n -T0 show
> Routing tables
>
> Internet:
> Destination Gateway Flags Refs Use Mtu Prio
> Iface
> default 5.134.92.1 UGS 2 78893 - 8 em0
> 224/4 127.0.0.1 URS 0 609 32768 8 lo0
> 5.134.92/22 5.134.92.142 UC 0 0 - 4 em0
> 5.134.92/23 5.134.92.1 UGS 0 80897 - 8 em0
> 5.134.94/23 5.134.92.1 UGS 0 396 - 8 em0
> 5.134.92.142 00:0d:b9:46:33:50 UHLl 0 52 - 1 em0
> 5.134.95.255 5.134.92.142 UHb 0 0 - 1 em0
> 127/8 127.0.0.1 UGRS 0 0 32768 8 lo0
> 127.0.0.1 127.0.0.1 UHl 1 6 32768 1 lo0
> 185.55.204/23 5.134.92.1 UGS 0 24 - 8 em0
> 185.55.206/23 5.134.92.1 UGS 0 21 - 8 em0
>
> Internet6:
> Destination Gateway
> Flags Refs Use Mtu Prio Iface
> ::/96 ::1 UGRS
> 0 0 32768 8 lo0
> ::/104 ::1 UGRS
> 0 0 32768 8 lo0
> ::1 ::1 UHl
> 14 14 32768 1 lo0
> ::127.0.0.0/104 ::1 UGRS
> 0 0 32768 8 lo0
> ::224.0.0.0/100 ::1 UGRS
> 0 0 32768 8 lo0
> ::255.0.0.0/104 ::1 UGRS
> 0 0 32768 8 lo0
> ::ffff:0.0.0.0/96 ::1 UGRS
> 0 0 32768 8 lo0
> 2002::/24 ::1 UGRS
> 0 0 32768 8 lo0
> 2002:7f00::/24 ::1 UGRS
> 0 0 32768 8 lo0
> 2002:e000::/20 ::1 UGRS
> 0 0 32768 8 lo0
> 2002:ff00::/24 ::1 UGRS
> 0 0 32768 8 lo0
> fe80::/10 ::1 UGRS
> 0 0 32768 8 lo0
> fec0::/10 ::1 UGRS
> 0 0 32768 8 lo0
> fe80::1%lo0 fe80::1%lo0 UHl
> 0 0 32768 1 lo0
> ff01::/16 ::1 UGRS
> 21 21 32768 8 lo0
> ff01::%lo0/32 ::1 Um
> 0 1 32768 4 lo0
> ff02::/16 ::1 UGRS
> 21 21 32768 8 lo0
> ff02::%lo0/32 ::1 Um
> 0 1 32768 4 lo0
>
>
>
> ---------------------------------------------
> ---------------------------------------------
>
> below is the output of the routing table when it is working
> # route -n -T0 show
> Routing tables
>
> Internet:
> Destination Gateway Flags Refs Use Mtu Prio
> Iface
> default 5.134.92.1 UGS 5 51573 - 8 em0
> 224/4 127.0.0.1 URS 0 1060 32768 8 lo0
> 5.134.92/22 5.134.92.142 UC 1 0 - 4 em0
> 5.134.92/23 5.134.92.1 UGS 0 116 - 8 em0
> 5.134.94/23 5.134.92.1 UGS 0 51 - 8 em0
> 5.134.92.1 de:10:0d:96:90:34 UHLc 5 180 - 4 em0
> 5.134.92.142 00:0d:b9:46:33:50 UHLl 0 80378 - 1 em0
> 5.134.95.255 5.134.92.142 UHb 0 0 - 1 em0
> 127/8 127.0.0.1 UGRS 0 0 32768 8 lo0
> 127.0.0.1 127.0.0.1 UHl 1 6 32768 1 lo0
> 185.55.204/23 5.134.92.1 UGS 0 12 - 8 em0
> 185.55.206/23 5.134.92.1 UGS 0 6 - 8 em0
>
> Internet6:
> Destination Gateway
> Flags Refs Use Mtu Prio Iface
> ::/96 ::1 UGRS
> 0 0 32768 8 lo0
> ::/104 ::1 UGRS
> 0 0 32768 8 lo0
> ::1 ::1 UHl
> 14 14 32768 1 lo0
> ::127.0.0.0/104 ::1 UGRS
> 0 0 32768 8 lo0
> ::224.0.0.0/100 ::1 UGRS
> 0 0 32768 8 lo0
> ::255.0.0.0/104 ::1 UGRS
> 0 0 32768 8 lo0
> ::ffff:0.0.0.0/96 ::1 UGRS
> 0 0 32768 8 lo0
> 2002::/24 ::1 UGRS
> 0 0 32768 8 lo0
> 2002:7f00::/24 ::1 UGRS
> 0 0 32768 8 lo0
> 2002:e000::/20 ::1 UGRS
> 0 0 32768 8 lo0
> 2002:ff00::/24 ::1 UGRS
> 0 0 32768 8 lo0
> fe80::/10 ::1 UGRS
> 0 0 32768 8 lo0
> fec0::/10 ::1 UGRS
> 0 0 32768 8 lo0
> fe80::1%lo0 fe80::1%lo0 UHl
> 0 0 32768 1 lo0
> ff01::/16 ::1 UGRS
> 21 21 32768 8 lo0
> ff01::%lo0/32 ::1 Um
> 0 1 32768 4 lo0
> ff02::/16 ::1 UGRS
> 21 21 32768 8 lo0
> ff02::%lo0/32 ::1 Um
> 0 1 32768 4 lo0
>
>
> em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> lladdr 00:0d:b9:46:33:50
> index 1 priority 0 llprio 3
> groups: egress
> media: Ethernet autoselect (100baseTX full-duplex)
> status: active
> inet 5.134.92.142 netmask 0xfffffc00 broadcast 5.134.95.255
>
>
>
> ----------------------------------------------------------------------------------
>
> ----------------------------------------------------------------------------------
>
>
>
no route to host (when there is a route )
Hello,
I have encountered this issue for a while, it happens irregularly
on my systems on this lan
basically when the issue occurs
I cant route out the interface with the default route on it,
I cant ping the gateway
I cant see the arp of the gateway
but i can see the routes installed in the routing table
are there other commands I should be looking at to debug it more
Im using
ifconfig
arp
route
when i run run sh /etc/netstart em0
then normal operation returns
The only (unusual network config) im using is that im deploying
more specific static routes (than the connected route) to allow
clients on a non broadcast network to route to each other
ie if a client wants to talk to another client send packet to default gateway
(icmp redirects are off on the gateway)
the output of ping and arp when it happens are as follows
# ping 5.134.92.1
PING 5.134.92.1 (5.134.92.1): 56 data bytes
ping: sendto: No route to host
ping: wrote 5.134.92.1 64 chars, ret=-1
ping: sendto: No route to host
ping: wrote 5.134.92.1 64 chars, ret=-1
ping: sendto: No route to host
ping: wrote 5.134.92.1 64 chars, ret=-1
--- 5.134.92.1 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
#ifconfig em0
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:0d:b9:46:33:50
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 5.134.92.142 netmask 0xfffffc00 broadcast 5.134.95.255
below is an output of the routing table when it is not working
# route -n -T0 show
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 5.134.92.1 UGS 2 78893 - 8 em0
224/4 127.0.0.1 URS 0 609 32768 8 lo0
5.134.92/22 5.134.92.142 UC 0 0 - 4 em0
5.134.92/23 5.134.92.1 UGS 0 80897 - 8 em0
5.134.94/23 5.134.92.1 UGS 0 396 - 8 em0
5.134.92.142 00:0d:b9:46:33:50 UHLl 0 52 - 1 em0
5.134.95.255 5.134.92.142 UHb 0 0 - 1 em0
127/8 127.0.0.1 UGRS 0 0 32768 8 lo0
127.0.0.1 127.0.0.1 UHl 1 6 32768 1 lo0
185.55.204/23 5.134.92.1 UGS 0 24 - 8 em0
185.55.206/23 5.134.92.1 UGS 0 21 - 8 em0
Internet6:
Destination Gateway
Flags Refs Use Mtu Prio Iface
::/96 ::1 UGRS
0 0 32768 8 lo0
::/104 ::1 UGRS
0 0 32768 8 lo0
::1 ::1 UHl
14 14 32768 1 lo0
::127.0.0.0/104 ::1 UGRS
0 0 32768 8 lo0
::224.0.0.0/100 ::1 UGRS
0 0 32768 8 lo0
::255.0.0.0/104 ::1 UGRS
0 0 32768 8 lo0
::ffff:0.0.0.0/96 ::1 UGRS
0 0 32768 8 lo0
2002::/24 ::1 UGRS
0 0 32768 8 lo0
2002:7f00::/24 ::1 UGRS
0 0 32768 8 lo0
2002:e000::/20 ::1 UGRS
0 0 32768 8 lo0
2002:ff00::/24 ::1 UGRS
0 0 32768 8 lo0
fe80::/10 ::1 UGRS
0 0 32768 8 lo0
fec0::/10 ::1 UGRS
0 0 32768 8 lo0
fe80::1%lo0 fe80::1%lo0 UHl
0 0 32768 1 lo0
ff01::/16 ::1 UGRS
21 21 32768 8 lo0
ff01::%lo0/32 ::1 Um
0 1 32768 4 lo0
ff02::/16 ::1 UGRS
21 21 32768 8 lo0
ff02::%lo0/32 ::1 Um
0 1 32768 4 lo0
---------------------------------------------
---------------------------------------------
below is the output of the routing table when it is working
# route -n -T0 show
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 5.134.92.1 UGS 5 51573 - 8 em0
224/4 127.0.0.1 URS 0 1060 32768 8 lo0
5.134.92/22 5.134.92.142 UC 1 0 - 4 em0
5.134.92/23 5.134.92.1 UGS 0 116 - 8 em0
5.134.94/23 5.134.92.1 UGS 0 51 - 8 em0
5.134.92.1 de:10:0d:96:90:34 UHLc 5 180 - 4 em0
5.134.92.142 00:0d:b9:46:33:50 UHLl 0 80378 - 1 em0
5.134.95.255 5.134.92.142 UHb 0 0 - 1 em0
127/8 127.0.0.1 UGRS 0 0 32768 8 lo0
127.0.0.1 127.0.0.1 UHl 1 6 32768 1 lo0
185.55.204/23 5.134.92.1 UGS 0 12 - 8 em0
185.55.206/23 5.134.92.1 UGS 0 6 - 8 em0
Internet6:
Destination Gateway
Flags Refs Use Mtu Prio Iface
::/96 ::1 UGRS
0 0 32768 8 lo0
::/104 ::1 UGRS
0 0 32768 8 lo0
::1 ::1 UHl
14 14 32768 1 lo0
::127.0.0.0/104 ::1 UGRS
0 0 32768 8 lo0
::224.0.0.0/100 ::1 UGRS
0 0 32768 8 lo0
::255.0.0.0/104 ::1 UGRS
0 0 32768 8 lo0
::ffff:0.0.0.0/96 ::1 UGRS
0 0 32768 8 lo0
2002::/24 ::1 UGRS
0 0 32768 8 lo0
2002:7f00::/24 ::1 UGRS
0 0 32768 8 lo0
2002:e000::/20 ::1 UGRS
0 0 32768 8 lo0
2002:ff00::/24 ::1 UGRS
0 0 32768 8 lo0
fe80::/10 ::1 UGRS
0 0 32768 8 lo0
fec0::/10 ::1 UGRS
0 0 32768 8 lo0
fe80::1%lo0 fe80::1%lo0 UHl
0 0 32768 1 lo0
ff01::/16 ::1 UGRS
21 21 32768 8 lo0
ff01::%lo0/32 ::1 Um
0 1 32768 4 lo0
ff02::/16 ::1 UGRS
21 21 32768 8 lo0
ff02::%lo0/32 ::1 Um
0 1 32768 4 lo0
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:0d:b9:46:33:50
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 5.134.92.142 netmask 0xfffffc00 broadcast 5.134.95.255
----------------------------------------------------------------------------------
----------------------------------------------------------------------------------
I have encountered this issue for a while, it happens irregularly
on my systems on this lan
basically when the issue occurs
I cant route out the interface with the default route on it,
I cant ping the gateway
I cant see the arp of the gateway
but i can see the routes installed in the routing table
are there other commands I should be looking at to debug it more
Im using
ifconfig
arp
route
when i run run sh /etc/netstart em0
then normal operation returns
The only (unusual network config) im using is that im deploying
more specific static routes (than the connected route) to allow
clients on a non broadcast network to route to each other
ie if a client wants to talk to another client send packet to default gateway
(icmp redirects are off on the gateway)
the output of ping and arp when it happens are as follows
# ping 5.134.92.1
PING 5.134.92.1 (5.134.92.1): 56 data bytes
ping: sendto: No route to host
ping: wrote 5.134.92.1 64 chars, ret=-1
ping: sendto: No route to host
ping: wrote 5.134.92.1 64 chars, ret=-1
ping: sendto: No route to host
ping: wrote 5.134.92.1 64 chars, ret=-1
--- 5.134.92.1 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
#ifconfig em0
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:0d:b9:46:33:50
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 5.134.92.142 netmask 0xfffffc00 broadcast 5.134.95.255
below is an output of the routing table when it is not working
# route -n -T0 show
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 5.134.92.1 UGS 2 78893 - 8 em0
224/4 127.0.0.1 URS 0 609 32768 8 lo0
5.134.92/22 5.134.92.142 UC 0 0 - 4 em0
5.134.92/23 5.134.92.1 UGS 0 80897 - 8 em0
5.134.94/23 5.134.92.1 UGS 0 396 - 8 em0
5.134.92.142 00:0d:b9:46:33:50 UHLl 0 52 - 1 em0
5.134.95.255 5.134.92.142 UHb 0 0 - 1 em0
127/8 127.0.0.1 UGRS 0 0 32768 8 lo0
127.0.0.1 127.0.0.1 UHl 1 6 32768 1 lo0
185.55.204/23 5.134.92.1 UGS 0 24 - 8 em0
185.55.206/23 5.134.92.1 UGS 0 21 - 8 em0
Internet6:
Destination Gateway
Flags Refs Use Mtu Prio Iface
::/96 ::1 UGRS
0 0 32768 8 lo0
::/104 ::1 UGRS
0 0 32768 8 lo0
::1 ::1 UHl
14 14 32768 1 lo0
::127.0.0.0/104 ::1 UGRS
0 0 32768 8 lo0
::224.0.0.0/100 ::1 UGRS
0 0 32768 8 lo0
::255.0.0.0/104 ::1 UGRS
0 0 32768 8 lo0
::ffff:0.0.0.0/96 ::1 UGRS
0 0 32768 8 lo0
2002::/24 ::1 UGRS
0 0 32768 8 lo0
2002:7f00::/24 ::1 UGRS
0 0 32768 8 lo0
2002:e000::/20 ::1 UGRS
0 0 32768 8 lo0
2002:ff00::/24 ::1 UGRS
0 0 32768 8 lo0
fe80::/10 ::1 UGRS
0 0 32768 8 lo0
fec0::/10 ::1 UGRS
0 0 32768 8 lo0
fe80::1%lo0 fe80::1%lo0 UHl
0 0 32768 1 lo0
ff01::/16 ::1 UGRS
21 21 32768 8 lo0
ff01::%lo0/32 ::1 Um
0 1 32768 4 lo0
ff02::/16 ::1 UGRS
21 21 32768 8 lo0
ff02::%lo0/32 ::1 Um
0 1 32768 4 lo0
---------------------------------------------
---------------------------------------------
below is the output of the routing table when it is working
# route -n -T0 show
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 5.134.92.1 UGS 5 51573 - 8 em0
224/4 127.0.0.1 URS 0 1060 32768 8 lo0
5.134.92/22 5.134.92.142 UC 1 0 - 4 em0
5.134.92/23 5.134.92.1 UGS 0 116 - 8 em0
5.134.94/23 5.134.92.1 UGS 0 51 - 8 em0
5.134.92.1 de:10:0d:96:90:34 UHLc 5 180 - 4 em0
5.134.92.142 00:0d:b9:46:33:50 UHLl 0 80378 - 1 em0
5.134.95.255 5.134.92.142 UHb 0 0 - 1 em0
127/8 127.0.0.1 UGRS 0 0 32768 8 lo0
127.0.0.1 127.0.0.1 UHl 1 6 32768 1 lo0
185.55.204/23 5.134.92.1 UGS 0 12 - 8 em0
185.55.206/23 5.134.92.1 UGS 0 6 - 8 em0
Internet6:
Destination Gateway
Flags Refs Use Mtu Prio Iface
::/96 ::1 UGRS
0 0 32768 8 lo0
::/104 ::1 UGRS
0 0 32768 8 lo0
::1 ::1 UHl
14 14 32768 1 lo0
::127.0.0.0/104 ::1 UGRS
0 0 32768 8 lo0
::224.0.0.0/100 ::1 UGRS
0 0 32768 8 lo0
::255.0.0.0/104 ::1 UGRS
0 0 32768 8 lo0
::ffff:0.0.0.0/96 ::1 UGRS
0 0 32768 8 lo0
2002::/24 ::1 UGRS
0 0 32768 8 lo0
2002:7f00::/24 ::1 UGRS
0 0 32768 8 lo0
2002:e000::/20 ::1 UGRS
0 0 32768 8 lo0
2002:ff00::/24 ::1 UGRS
0 0 32768 8 lo0
fe80::/10 ::1 UGRS
0 0 32768 8 lo0
fec0::/10 ::1 UGRS
0 0 32768 8 lo0
fe80::1%lo0 fe80::1%lo0 UHl
0 0 32768 1 lo0
ff01::/16 ::1 UGRS
21 21 32768 8 lo0
ff01::%lo0/32 ::1 Um
0 1 32768 4 lo0
ff02::/16 ::1 UGRS
21 21 32768 8 lo0
ff02::%lo0/32 ::1 Um
0 1 32768 4 lo0
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:0d:b9:46:33:50
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 5.134.92.142 netmask 0xfffffc00 broadcast 5.134.95.255
----------------------------------------------------------------------------------
----------------------------------------------------------------------------------
Re: new: games/barony
Why not but would like to take maintainer ship here. Regards.
On 1 May 2018 at 03:49, Brian Callahan <bcallah@devio.us> wrote:
>
> On 04/30/18 18:57, David CARLIER wrote:
>
>> A small update to install instead into ${LOCALBASE}/share/barony as
>> request
>> by @bcallah.
>>
>
> Attached is a better version with fixes and a proper pkg/README.
>
> OK?
>
> ~Brian
>
>
> On 30 April 2018 at 21:35, Brian Callahan <bcallah@devio.us> wrote:
>>
>> (Responding from my phone so apologies)
>>> Download the Linux version and extract it with unzip.
>>>
>>>
>>>
>>> Sent from my Verizon, Samsung Galaxy smartphone
>>>
>>> -------- Original message --------
>>> From: David CARLIER <devnexen@gmail.com>
>>> Date: 4/30/18 2:10 PM (GMT-05:00)
>>> To: Timo Myyrä <timo.myyra@bittivirhe.fi>
>>> Cc: Solene Rapenne <solene@perso.pw>, OpenBSD ports <ports@openbsd.org>
>>> Subject: Re: new: games/barony
>>>
>>> I checked the Gog com ... do not find the folders needed to get started
>>> the
>>> game ! e.g images maps items music sounds lang ...
>>>
>>> On 30 April 2018 at 15:05, Timo Myyrä <timo.myyra@bittivirhe.fi> wrote:
>>>
>>> David CARLIER <devnexen@gmail.com> writes:
>>>>
>>>> Thanks for the feedback, in case you can always force the Debug mode
>>>>>
>>>> via
>>>
>>>> cmake e.g. -DCMAKE_BUILD_TYPE=Debug
>>>>> If I recall correctly you re running it into ppc arch ? Would like to
>>>>>
>>>> see
>>>
>>>> classic x86 archs users feedbacks too.
>>>>> Will try myself in some hours.
>>>>>
>>>>> On 30 April 2018 at 11:01, Solene Rapenne <solene@perso.pw> wrote:
>>>>>
>>>>> Thomas Frohwein writes:
>>>>>>
>>>>>> On Fri, Mar 30, 2018 at 12:42:36AM +0200, Solene Rapenne wrote:
>>>>>>>
>>>>>>> I tried it on amd64 - installed the package, downloaded Barony:
>>>>>>>
>>>>>> Cursed
>>>
>>>> Edition
>>>>>>
>>>>>>> from gog.com, innoextract, then copied all the game files to
>>>>>>> /usr/local/share/games/barony. It counts through all the
>>>>>>>
>>>>>> 400-something
>>>
>>>> assets
>>>>>>
>>>>>>> that it loads, but afterwards just exits without any error.
>>>>>>>
>>>>>>> The version on gog.com is listed as 2.0.7 and is probably
>>>>>>>
>>>>>> outdated. I
>>>
>>>> think
>>>>>>
>>>>>>> a README with some details on this and maybe the game data folder
>>>>>>>
>>>>>> may
>>>
>>>> be
>>>>
>>>>> useful.
>>>>>>>
>>>>>>> I'll probably have to wait for an update on gog.com before being
>>>>>>>
>>>>>> able
>>>
>>>> to test.
>>>>>>
>>>>>> GOG now has 3.1.4 version. I still can't get the game to work, using
>>>>>> latest port version.
>>>>>>
>>>>>> I did :
>>>>>>
>>>>>> $ innoextract 'setup_barony_cursed_edition_3.1.4_(20340).exe'
>>>>>> $ doas rsync -av tmp/ /usr/local/share/games/barony/
>>>>>> $ barony
>>>>>> [12-58-43] Data path is /usr/local/share/games/barony
>>>>>> $ echo $?
>>>>>> $ 1
>>>>>>
>>>>>> I don't succeed having a backtrace with gdb.
>>>>>>
>>>>>> Same issue seems to happen on amd64 here.
>>>> Haven't tested yet with debug build.
>>>>
>>>> Timo
>>>>
>>>>
>
On 1 May 2018 at 03:49, Brian Callahan <bcallah@devio.us> wrote:
>
> On 04/30/18 18:57, David CARLIER wrote:
>
>> A small update to install instead into ${LOCALBASE}/share/barony as
>> request
>> by @bcallah.
>>
>
> Attached is a better version with fixes and a proper pkg/README.
>
> OK?
>
> ~Brian
>
>
> On 30 April 2018 at 21:35, Brian Callahan <bcallah@devio.us> wrote:
>>
>> (Responding from my phone so apologies)
>>> Download the Linux version and extract it with unzip.
>>>
>>>
>>>
>>> Sent from my Verizon, Samsung Galaxy smartphone
>>>
>>> -------- Original message --------
>>> From: David CARLIER <devnexen@gmail.com>
>>> Date: 4/30/18 2:10 PM (GMT-05:00)
>>> To: Timo Myyrä <timo.myyra@bittivirhe.fi>
>>> Cc: Solene Rapenne <solene@perso.pw>, OpenBSD ports <ports@openbsd.org>
>>> Subject: Re: new: games/barony
>>>
>>> I checked the Gog com ... do not find the folders needed to get started
>>> the
>>> game ! e.g images maps items music sounds lang ...
>>>
>>> On 30 April 2018 at 15:05, Timo Myyrä <timo.myyra@bittivirhe.fi> wrote:
>>>
>>> David CARLIER <devnexen@gmail.com> writes:
>>>>
>>>> Thanks for the feedback, in case you can always force the Debug mode
>>>>>
>>>> via
>>>
>>>> cmake e.g. -DCMAKE_BUILD_TYPE=Debug
>>>>> If I recall correctly you re running it into ppc arch ? Would like to
>>>>>
>>>> see
>>>
>>>> classic x86 archs users feedbacks too.
>>>>> Will try myself in some hours.
>>>>>
>>>>> On 30 April 2018 at 11:01, Solene Rapenne <solene@perso.pw> wrote:
>>>>>
>>>>> Thomas Frohwein writes:
>>>>>>
>>>>>> On Fri, Mar 30, 2018 at 12:42:36AM +0200, Solene Rapenne wrote:
>>>>>>>
>>>>>>> I tried it on amd64 - installed the package, downloaded Barony:
>>>>>>>
>>>>>> Cursed
>>>
>>>> Edition
>>>>>>
>>>>>>> from gog.com, innoextract, then copied all the game files to
>>>>>>> /usr/local/share/games/barony. It counts through all the
>>>>>>>
>>>>>> 400-something
>>>
>>>> assets
>>>>>>
>>>>>>> that it loads, but afterwards just exits without any error.
>>>>>>>
>>>>>>> The version on gog.com is listed as 2.0.7 and is probably
>>>>>>>
>>>>>> outdated. I
>>>
>>>> think
>>>>>>
>>>>>>> a README with some details on this and maybe the game data folder
>>>>>>>
>>>>>> may
>>>
>>>> be
>>>>
>>>>> useful.
>>>>>>>
>>>>>>> I'll probably have to wait for an update on gog.com before being
>>>>>>>
>>>>>> able
>>>
>>>> to test.
>>>>>>
>>>>>> GOG now has 3.1.4 version. I still can't get the game to work, using
>>>>>> latest port version.
>>>>>>
>>>>>> I did :
>>>>>>
>>>>>> $ innoextract 'setup_barony_cursed_edition_3.1.4_(20340).exe'
>>>>>> $ doas rsync -av tmp/ /usr/local/share/games/barony/
>>>>>> $ barony
>>>>>> [12-58-43] Data path is /usr/local/share/games/barony
>>>>>> $ echo $?
>>>>>> $ 1
>>>>>>
>>>>>> I don't succeed having a backtrace with gdb.
>>>>>>
>>>>>> Same issue seems to happen on amd64 here.
>>>> Haven't tested yet with debug build.
>>>>
>>>> Timo
>>>>
>>>>
>
Ocaml and OPAM
Good Morning
I have recently started using ocaml and opam on OpenBSD, but some the packages i use need Ocaml 4.06, i use opam switch to update.
I was just wondering if anyone is working on updating Ocaml and with the soon to be release OPAM 2, updating opam?
I know chrisz@ looks after OPAM and avsm@ looks after ocaml.
If no one is, was just wondering the best process to update ocaml?
Cheers
Adam
I have recently started using ocaml and opam on OpenBSD, but some the packages i use need Ocaml 4.06, i use opam switch to update.
I was just wondering if anyone is working on updating Ocaml and with the soon to be release OPAM 2, updating opam?
I know chrisz@ looks after OPAM and avsm@ looks after ocaml.
If no one is, was just wondering the best process to update ocaml?
Cheers
Adam
NEW: devel/samurai
Index: cmake.port.mk
===================================================================
RCS file: /cvs/ports/devel/cmake/cmake.port.mk,v
retrieving revision 1.63
diff -u -p -r1.63 cmake.port.mk
--- cmake.port.mk 26 Jan 2018 13:11:14 -0000 1.63
+++ cmake.port.mk 1 May 2018 03:51:27 -0000
@@ -8,12 +8,17 @@ MAKE_ENV+=LIB${_n}_VERSION=${_v}
.endfor
USE_NINJA ?= Yes
+USE_SAMURAI ?= No
# XXX: Ninja is broken on m88k
.if ${MACHINE_ARCH} == "m88k"
USE_NINJA = No
.endif
+.if ${USE_SAMURAI:L} == "yes"
+USE_NINJA = No
+.endif
+
.if ${USE_NINJA:L} == "yes"
BUILD_DEPENDS += devel/ninja>=1.5.1
_MODCMAKE_GEN = Ninja
@@ -25,6 +30,34 @@ MODCMAKE_INSTALL_TARGET = cd ${WRKBUILD}
${FAKE_SETUP} ${NINJA} ${NINJA_FLAGS} ${FAKE_TARGET}
MODCMAKE_TEST_TARGET = cd ${WRKBUILD} && exec ${SETENV} ${ALL_TEST_ENV} \
${NINJA} ${NINJA_FLAGS} ${TEST_FLAGS} ${TEST_TARGET}
+
+.if !target(do-build)
+do-build:
+ @${MODCMAKE_BUILD_TARGET}
+.endif
+
+.if !target(do-install)
+do-install:
+ @${MODCMAKE_INSTALL_TARGET}
+.endif
+
+.if !target(do-test)
+do-test:
+ @${MODCMAKE_TEST_TARGET}
+.endif
+
+.elif ${USE_SAMURAI:L} == "yes"
+BUILD_DEPENDS += devel/samurai
+_MODCMAKE_GEN = Ninja
+SAMURAI ?= samu
+SAMURAI_FLAGS ?= -v -j ${MAKE_JOBS}
+CONFIGURE_ARGS += -DCMAKE_MAKE_PROGRAM:String=${SAMURAI}
+MODCMAKE_BUILD_TARGET = cd ${WRKBUILD} && exec ${SETENV} ${MAKE_ENV} \
+ ${SAMURAI} ${SAMURAI_FLAGS} ${ALL_TARGET}
+MODCMAKE_INSTALL_TARGET = cd ${WRKBUILD} && exec ${SETENV} ${MAKE_ENV} \
+ ${FAKE_SETUP} ${SAMURAI} ${SAMURAI_FLAGS} ${FAKE_TARGET}
+MODCMAKE_TEST_TARGET = cd ${WRKBUILD} && exec ${SETENV} ${ALL_TEST_ENV} \
+ ${SAMURAI} ${SAMURAI_FLAGS} ${TEST_FLAGS} ${TEST_TARGET}
.if !target(do-build)
do-build:
Hi ports --
Attached is a new port, devel/samurai. Samurai is a ninja-compatible
build tool written in C.
---
pkg/DESCR:
samurai is a ninja-compatible build tool written in C99 with a focus on
simplicity, speed, and portability.
samurai implements the ninja build language through version 1.8.2. It
uses the same format for .ninja_log and .ninja_deps as ninja, currently
version 5 and 3 respectively.
It is largely feature-complete and supports most of the same options as
ninja.
---
Samurai can be used as a drop-in replacement for Ninja with CMake.
Notably, samurai does not do the random build order thing that ninja
does, but samurai has built everything I have thrown at it without
issue. To make testing easy, I'm including a patch for cmake.port.mk --
then all you have to do is go to a port that uses cmake and add
USE_SAMURAI=Yes to the port Makefile. Note that I am not seriously
proposing to commit the cmake.port.mk change, unless people think that
it'd be useful to have a backup to ninja.
OK?
~Brian
===================================================================
RCS file: /cvs/ports/devel/cmake/cmake.port.mk,v
retrieving revision 1.63
diff -u -p -r1.63 cmake.port.mk
--- cmake.port.mk 26 Jan 2018 13:11:14 -0000 1.63
+++ cmake.port.mk 1 May 2018 03:51:27 -0000
@@ -8,12 +8,17 @@ MAKE_ENV+=LIB${_n}_VERSION=${_v}
.endfor
USE_NINJA ?= Yes
+USE_SAMURAI ?= No
# XXX: Ninja is broken on m88k
.if ${MACHINE_ARCH} == "m88k"
USE_NINJA = No
.endif
+.if ${USE_SAMURAI:L} == "yes"
+USE_NINJA = No
+.endif
+
.if ${USE_NINJA:L} == "yes"
BUILD_DEPENDS += devel/ninja>=1.5.1
_MODCMAKE_GEN = Ninja
@@ -25,6 +30,34 @@ MODCMAKE_INSTALL_TARGET = cd ${WRKBUILD}
${FAKE_SETUP} ${NINJA} ${NINJA_FLAGS} ${FAKE_TARGET}
MODCMAKE_TEST_TARGET = cd ${WRKBUILD} && exec ${SETENV} ${ALL_TEST_ENV} \
${NINJA} ${NINJA_FLAGS} ${TEST_FLAGS} ${TEST_TARGET}
+
+.if !target(do-build)
+do-build:
+ @${MODCMAKE_BUILD_TARGET}
+.endif
+
+.if !target(do-install)
+do-install:
+ @${MODCMAKE_INSTALL_TARGET}
+.endif
+
+.if !target(do-test)
+do-test:
+ @${MODCMAKE_TEST_TARGET}
+.endif
+
+.elif ${USE_SAMURAI:L} == "yes"
+BUILD_DEPENDS += devel/samurai
+_MODCMAKE_GEN = Ninja
+SAMURAI ?= samu
+SAMURAI_FLAGS ?= -v -j ${MAKE_JOBS}
+CONFIGURE_ARGS += -DCMAKE_MAKE_PROGRAM:String=${SAMURAI}
+MODCMAKE_BUILD_TARGET = cd ${WRKBUILD} && exec ${SETENV} ${MAKE_ENV} \
+ ${SAMURAI} ${SAMURAI_FLAGS} ${ALL_TARGET}
+MODCMAKE_INSTALL_TARGET = cd ${WRKBUILD} && exec ${SETENV} ${MAKE_ENV} \
+ ${FAKE_SETUP} ${SAMURAI} ${SAMURAI_FLAGS} ${FAKE_TARGET}
+MODCMAKE_TEST_TARGET = cd ${WRKBUILD} && exec ${SETENV} ${ALL_TEST_ENV} \
+ ${SAMURAI} ${SAMURAI_FLAGS} ${TEST_FLAGS} ${TEST_TARGET}
.if !target(do-build)
do-build:
Hi ports --
Attached is a new port, devel/samurai. Samurai is a ninja-compatible
build tool written in C.
---
pkg/DESCR:
samurai is a ninja-compatible build tool written in C99 with a focus on
simplicity, speed, and portability.
samurai implements the ninja build language through version 1.8.2. It
uses the same format for .ninja_log and .ninja_deps as ninja, currently
version 5 and 3 respectively.
It is largely feature-complete and supports most of the same options as
ninja.
---
Samurai can be used as a drop-in replacement for Ninja with CMake.
Notably, samurai does not do the random build order thing that ninja
does, but samurai has built everything I have thrown at it without
issue. To make testing easy, I'm including a patch for cmake.port.mk --
then all you have to do is go to a port that uses cmake and add
USE_SAMURAI=Yes to the port Makefile. Note that I am not seriously
proposing to commit the cmake.port.mk change, unless people think that
it'd be useful to have a backup to ninja.
OK?
~Brian
acpidump: RSDT entry 3 is corrupt
I'm seeing "acpidump: RSDT entry 3 is corrupt" in my boot messages
on 6.3/amd64. The motherboard is an ASUS P5Q Pro Turbo with a Q6600.
IIRC, there's a way to extract the table so someone clueful can come-up
with a workaround for ASUS's failure to comply with the standard?
Meghan
on 6.3/amd64. The motherboard is an ASUS P5Q Pro Turbo with a Q6600.
IIRC, there's a way to extract the table so someone clueful can come-up
with a workaround for ASUS's failure to comply with the standard?
Meghan
Re: new: games/barony
On 04/30/18 18:57, David CARLIER wrote:
> A small update to install instead into ${LOCALBASE}/share/barony as request
> by @bcallah.
Attached is a better version with fixes and a proper pkg/README.
OK?
~Brian
> On 30 April 2018 at 21:35, Brian Callahan <bcallah@devio.us> wrote:
>
>> (Responding from my phone so apologies)
>> Download the Linux version and extract it with unzip.
>>
>>
>>
>> Sent from my Verizon, Samsung Galaxy smartphone
>>
>> -------- Original message --------
>> From: David CARLIER <devnexen@gmail.com>
>> Date: 4/30/18 2:10 PM (GMT-05:00)
>> To: Timo Myyrä <timo.myyra@bittivirhe.fi>
>> Cc: Solene Rapenne <solene@perso.pw>, OpenBSD ports <ports@openbsd.org>
>> Subject: Re: new: games/barony
>>
>> I checked the Gog com ... do not find the folders needed to get started the
>> game ! e.g images maps items music sounds lang ...
>>
>> On 30 April 2018 at 15:05, Timo Myyrä <timo.myyra@bittivirhe.fi> wrote:
>>
>>> David CARLIER <devnexen@gmail.com> writes:
>>>
>>>> Thanks for the feedback, in case you can always force the Debug mode
>> via
>>>> cmake e.g. -DCMAKE_BUILD_TYPE=Debug
>>>> If I recall correctly you re running it into ppc arch ? Would like to
>> see
>>>> classic x86 archs users feedbacks too.
>>>> Will try myself in some hours.
>>>>
>>>> On 30 April 2018 at 11:01, Solene Rapenne <solene@perso.pw> wrote:
>>>>
>>>>> Thomas Frohwein writes:
>>>>>
>>>>>> On Fri, Mar 30, 2018 at 12:42:36AM +0200, Solene Rapenne wrote:
>>>>>>
>>>>>> I tried it on amd64 - installed the package, downloaded Barony:
>> Cursed
>>>>> Edition
>>>>>> from gog.com, innoextract, then copied all the game files to
>>>>>> /usr/local/share/games/barony. It counts through all the
>> 400-something
>>>>> assets
>>>>>> that it loads, but afterwards just exits without any error.
>>>>>>
>>>>>> The version on gog.com is listed as 2.0.7 and is probably
>> outdated. I
>>>>> think
>>>>>> a README with some details on this and maybe the game data folder
>> may
>>> be
>>>>>> useful.
>>>>>>
>>>>>> I'll probably have to wait for an update on gog.com before being
>> able
>>>>> to test.
>>>>>
>>>>> GOG now has 3.1.4 version. I still can't get the game to work, using
>>>>> latest port version.
>>>>>
>>>>> I did :
>>>>>
>>>>> $ innoextract 'setup_barony_cursed_edition_3.1.4_(20340).exe'
>>>>> $ doas rsync -av tmp/ /usr/local/share/games/barony/
>>>>> $ barony
>>>>> [12-58-43] Data path is /usr/local/share/games/barony
>>>>> $ echo $?
>>>>> $ 1
>>>>>
>>>>> I don't succeed having a backtrace with gdb.
>>>>>
>>> Same issue seems to happen on amd64 here.
>>> Haven't tested yet with debug build.
>>>
>>> Timo
>>>
> A small update to install instead into ${LOCALBASE}/share/barony as request
> by @bcallah.
Attached is a better version with fixes and a proper pkg/README.
OK?
~Brian
> On 30 April 2018 at 21:35, Brian Callahan <bcallah@devio.us> wrote:
>
>> (Responding from my phone so apologies)
>> Download the Linux version and extract it with unzip.
>>
>>
>>
>> Sent from my Verizon, Samsung Galaxy smartphone
>>
>> -------- Original message --------
>> From: David CARLIER <devnexen@gmail.com>
>> Date: 4/30/18 2:10 PM (GMT-05:00)
>> To: Timo Myyrä <timo.myyra@bittivirhe.fi>
>> Cc: Solene Rapenne <solene@perso.pw>, OpenBSD ports <ports@openbsd.org>
>> Subject: Re: new: games/barony
>>
>> I checked the Gog com ... do not find the folders needed to get started the
>> game ! e.g images maps items music sounds lang ...
>>
>> On 30 April 2018 at 15:05, Timo Myyrä <timo.myyra@bittivirhe.fi> wrote:
>>
>>> David CARLIER <devnexen@gmail.com> writes:
>>>
>>>> Thanks for the feedback, in case you can always force the Debug mode
>> via
>>>> cmake e.g. -DCMAKE_BUILD_TYPE=Debug
>>>> If I recall correctly you re running it into ppc arch ? Would like to
>> see
>>>> classic x86 archs users feedbacks too.
>>>> Will try myself in some hours.
>>>>
>>>> On 30 April 2018 at 11:01, Solene Rapenne <solene@perso.pw> wrote:
>>>>
>>>>> Thomas Frohwein writes:
>>>>>
>>>>>> On Fri, Mar 30, 2018 at 12:42:36AM +0200, Solene Rapenne wrote:
>>>>>>
>>>>>> I tried it on amd64 - installed the package, downloaded Barony:
>> Cursed
>>>>> Edition
>>>>>> from gog.com, innoextract, then copied all the game files to
>>>>>> /usr/local/share/games/barony. It counts through all the
>> 400-something
>>>>> assets
>>>>>> that it loads, but afterwards just exits without any error.
>>>>>>
>>>>>> The version on gog.com is listed as 2.0.7 and is probably
>> outdated. I
>>>>> think
>>>>>> a README with some details on this and maybe the game data folder
>> may
>>> be
>>>>>> useful.
>>>>>>
>>>>>> I'll probably have to wait for an update on gog.com before being
>> able
>>>>> to test.
>>>>>
>>>>> GOG now has 3.1.4 version. I still can't get the game to work, using
>>>>> latest port version.
>>>>>
>>>>> I did :
>>>>>
>>>>> $ innoextract 'setup_barony_cursed_edition_3.1.4_(20340).exe'
>>>>> $ doas rsync -av tmp/ /usr/local/share/games/barony/
>>>>> $ barony
>>>>> [12-58-43] Data path is /usr/local/share/games/barony
>>>>> $ echo $?
>>>>> $ 1
>>>>>
>>>>> I don't succeed having a backtrace with gdb.
>>>>>
>>> Same issue seems to happen on amd64 here.
>>> Haven't tested yet with debug build.
>>>
>>> Timo
>>>
[New] citra - 3DS emulator
Please find attached this port of the 3DS emulator citra. It can run homebrew
and other 3DS roms. Comes with a commandline binary (citra) and a Qt one
(citra-qt). Like many other emulators, it requires USE_WXNEEDED to run
unfortunately. Based on my testing, the emulation speed seems good for 2D
games, but 3D games run a little sluggish on this i7-6820HQ with Intel HD
Graphics 530.
A few notes on the port:
- versioning - right now based on numbering of nightly (670). Alternatives might
be the date of the nightly, e.g. 20180427. Let me know if there's a
preference.
- listed license information on all relevant builtin libs. Let me know if this
is too detailed.
- I tried to disable builtin dependencies where possible, like cryptopp and
enet.
- I can't get soundtouch from ports to work because of a type incompatibility
short* vs. float* (same problem exists for dolphin emulator). Apparently
these ports are set up for integer samples, while our ports version is not
(additional information can be found here:
https://www.surina.net/soundtouch/README.html
under 3.1 Supported sample data formats for anyone who might be luckier than
me in troubleshooting this).
- The inclusion of submodules follows the way it's been done with
emulators/ppsspp.
- I disabled WebService which is for telemetry and pulls in additional
dependencies.
I put my fastmail email address as maintainer email. I'm planning to switch all
the ports with my ymail address to this one over time. Will keep ymail address
still available for the lifecycle of 6.3.
All tests pass in 'make test'.
and other 3DS roms. Comes with a commandline binary (citra) and a Qt one
(citra-qt). Like many other emulators, it requires USE_WXNEEDED to run
unfortunately. Based on my testing, the emulation speed seems good for 2D
games, but 3D games run a little sluggish on this i7-6820HQ with Intel HD
Graphics 530.
A few notes on the port:
- versioning - right now based on numbering of nightly (670). Alternatives might
be the date of the nightly, e.g. 20180427. Let me know if there's a
preference.
- listed license information on all relevant builtin libs. Let me know if this
is too detailed.
- I tried to disable builtin dependencies where possible, like cryptopp and
enet.
- I can't get soundtouch from ports to work because of a type incompatibility
short* vs. float* (same problem exists for dolphin emulator). Apparently
these ports are set up for integer samples, while our ports version is not
(additional information can be found here:
https://www.surina.net/soundtouch/README.html
under 3.1 Supported sample data formats for anyone who might be luckier than
me in troubleshooting this).
- The inclusion of submodules follows the way it's been done with
emulators/ppsspp.
- I disabled WebService which is for telemetry and pulls in additional
dependencies.
I put my fastmail email address as maintainer email. I'm planning to switch all
the ports with my ymail address to this one over time. Will keep ymail address
still available for the lifecycle of 6.3.
All tests pass in 'make test'.
Re: Troubleshooting rl instability on OpenBSD 6.1
On 01/05/18 11:10, Nick Holland wrote:
> Here's the thing. There are rules to the game with every OS. With
> OpenBSD, if you have to stay up to date -- the support tail is only
> about a year long, and that is really only security issues.
I accept this, no problem with that whatsoever, you can't support a
particular release infinitely. If that were important, I'd be paying
megabucks for some "enterprise" solution.
> So, what are you after? A magic, secret sysctl, "sysctl
> rl.work.properly=1" ? Nope, no such thing.
How about rl.tellmewhatsgoingon=1? :-) You know, maybe log something to
the kernel log when a packet is received, when a packet is transmitted,
etc. Something lower-level than pflogd.
I was hoping there might be some flag to enable some debug logging to
troubleshoot it further. Like the sort of debug logging that might've
been used to develop the driver in the first place.
Stuart Henderson provided some commands that could be useful in tracking
this, and I've got those noted down. Catching the problem has been the
tricky bit as it's intermittent, which is always the hardest type of
problem to solve. I do intend to look into this.
I've also turned up the logging on the switch. So far, no log messages
have been reported by said switch.
> Sorry. A patch to fix it?
> Not going to happen against 6.1, 6.2, or even 6.3, most likely. -current
> is where development happens, only security issues and maybe some
> behavior regressions are ever pushed back to old releases...not
> operational improvements, new features, or new hw support.
A patch against -current would be fine. I'd then know to work around
the issue until 6.4 comes out, then the problem would be truly fixed.
As discovered earlier, the source file that builds rl has not changed
since before 6.1 was released.
Essentially, I am already running the -current version of rl. What
isn't -current, is everything else. That could be a factor too.
> Now, rl chips were considered the worst pieces of network junk around
> until the ARM systems started sprouting networking chips. Don't get me
> wrong, I've used a lot of them, and had pretty good luck with them, but
> a lot of people I respect and who know better than me hate the #$%^ things.
Yeah, not my favourite chip either… but it's what Advantech picked,
probably on price. Unfortunately, unless I want to break out the solder
re-work station and bodge on a new chip, it's what I'm stuck with.
> You say a couple things that catch my eye -- 1) 6.1 is over a year old,
> and you say you have been battling the problem for a month. So
> something changed. That's hinting hw, not sw. (typically. Or the load
> changed. or something). 2) you say you had "similar" problems with
> another OS. Similar to what, I'm not sure, but that sounds like you
> have a HW problem. Keep in mind, when it comes to networks, it's not
> just the computer -- the wire and the switch are also all suspect.
I accept this too. I was asking in case there was a known issue or if
there was a way to confirm absolutely where the problem might lie.
It's a question of "here's a problem; what avenues have I got available
for debugging it". Not, "here's a problem, I demand you fix it
immediately!" There's a *big* difference.
As it happens, the industrial PC was a freebie and may have developed
faults that are not yet diagnosed, so it may be that the answer is
replace it with something new.
OpenBSD has been a good platform for this, so I'd be looking to replace
with something that can run this OS.
> But it boils down to this: if you want help on OpenBSD, you play by the
> rules and run either -current or at least a supported release (and if
> you contend it's an OS issue, you verify it still exists in -current!).
> If you don't need OpenBSD help...this isn't the place. And if you can
> say with certainty, "everything is the same", you will have no trouble
> adding debugging info and figure out your own problem.
I'll be clear on this: I am not looking for a backported fix to OpenBSD 6.1.
We don't even know what needs fixing yet. There might be an edge case
that's tripping something up. That edge case might be "your PCI bus is
stuffed because of vibration from too many Superhornets flying overhead"
(the box came from a RAAF base). It might be that "in rare cases,
register bit X doesn't get set when event Y occurs, do Z as a
workaround". This is unknown.
What I was trying to determine was:
1. whether there are known issues with this combination of
hardware/software? (e.g. maybe it's known that some 100-BaseT Ethernet
chip does not play nice with 1000-BaseT switches?)
2. whether there are additional debugging flags, commands or tools that
might help debug whether a given Ethernet frame was received, acted
upon, or replied to
Option 2 would then lead to "what causes this state", and ultimately, a
fix in -current. If I want the backport to 6.1, guess what, I have the
code, it's within my power to backport that myself if that's what I
truly want.
Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
> Here's the thing. There are rules to the game with every OS. With
> OpenBSD, if you have to stay up to date -- the support tail is only
> about a year long, and that is really only security issues.
I accept this, no problem with that whatsoever, you can't support a
particular release infinitely. If that were important, I'd be paying
megabucks for some "enterprise" solution.
> So, what are you after? A magic, secret sysctl, "sysctl
> rl.work.properly=1" ? Nope, no such thing.
How about rl.tellmewhatsgoingon=1? :-) You know, maybe log something to
the kernel log when a packet is received, when a packet is transmitted,
etc. Something lower-level than pflogd.
I was hoping there might be some flag to enable some debug logging to
troubleshoot it further. Like the sort of debug logging that might've
been used to develop the driver in the first place.
Stuart Henderson provided some commands that could be useful in tracking
this, and I've got those noted down. Catching the problem has been the
tricky bit as it's intermittent, which is always the hardest type of
problem to solve. I do intend to look into this.
I've also turned up the logging on the switch. So far, no log messages
have been reported by said switch.
> Sorry. A patch to fix it?
> Not going to happen against 6.1, 6.2, or even 6.3, most likely. -current
> is where development happens, only security issues and maybe some
> behavior regressions are ever pushed back to old releases...not
> operational improvements, new features, or new hw support.
A patch against -current would be fine. I'd then know to work around
the issue until 6.4 comes out, then the problem would be truly fixed.
As discovered earlier, the source file that builds rl has not changed
since before 6.1 was released.
Essentially, I am already running the -current version of rl. What
isn't -current, is everything else. That could be a factor too.
> Now, rl chips were considered the worst pieces of network junk around
> until the ARM systems started sprouting networking chips. Don't get me
> wrong, I've used a lot of them, and had pretty good luck with them, but
> a lot of people I respect and who know better than me hate the #$%^ things.
Yeah, not my favourite chip either… but it's what Advantech picked,
probably on price. Unfortunately, unless I want to break out the solder
re-work station and bodge on a new chip, it's what I'm stuck with.
> You say a couple things that catch my eye -- 1) 6.1 is over a year old,
> and you say you have been battling the problem for a month. So
> something changed. That's hinting hw, not sw. (typically. Or the load
> changed. or something). 2) you say you had "similar" problems with
> another OS. Similar to what, I'm not sure, but that sounds like you
> have a HW problem. Keep in mind, when it comes to networks, it's not
> just the computer -- the wire and the switch are also all suspect.
I accept this too. I was asking in case there was a known issue or if
there was a way to confirm absolutely where the problem might lie.
It's a question of "here's a problem; what avenues have I got available
for debugging it". Not, "here's a problem, I demand you fix it
immediately!" There's a *big* difference.
As it happens, the industrial PC was a freebie and may have developed
faults that are not yet diagnosed, so it may be that the answer is
replace it with something new.
OpenBSD has been a good platform for this, so I'd be looking to replace
with something that can run this OS.
> But it boils down to this: if you want help on OpenBSD, you play by the
> rules and run either -current or at least a supported release (and if
> you contend it's an OS issue, you verify it still exists in -current!).
> If you don't need OpenBSD help...this isn't the place. And if you can
> say with certainty, "everything is the same", you will have no trouble
> adding debugging info and figure out your own problem.
I'll be clear on this: I am not looking for a backported fix to OpenBSD 6.1.
We don't even know what needs fixing yet. There might be an edge case
that's tripping something up. That edge case might be "your PCI bus is
stuffed because of vibration from too many Superhornets flying overhead"
(the box came from a RAAF base). It might be that "in rare cases,
register bit X doesn't get set when event Y occurs, do Z as a
workaround". This is unknown.
What I was trying to determine was:
1. whether there are known issues with this combination of
hardware/software? (e.g. maybe it's known that some 100-BaseT Ethernet
chip does not play nice with 1000-BaseT switches?)
2. whether there are additional debugging flags, commands or tools that
might help debug whether a given Ethernet frame was received, acted
upon, or replied to
Option 2 would then lead to "what causes this state", and ultimately, a
fix in -current. If I want the backport to 6.1, guess what, I have the
code, it's within my power to backport that myself if that's what I
truly want.
Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
Re: Problem with OpenBSD as nfs client
Thank you so much Eike
mount_nfs -T works perfectly.
So i added TCP option in my fstab and all my shares are automatically
mounted.
Philippe
--
Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
mount_nfs -T works perfectly.
So i added TCP option in my fstab and all my shares are automatically
mounted.
Philippe
--
Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
Re: Troubleshooting rl instability on OpenBSD 6.1
On 04/30/18 18:04, Stuart Longland wrote:
> On 01/05/18 03:00, Solene Rapenne wrote:
>>
>> Stuart Longland writes:
>>
>>> On 29/04/18 18:08, Solene Rapenne wrote:
>>>>
>>>> Stuart Longland writes:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I've got an Advantech UNO-1150G industrial PC running OpenBSD 6.1 acting
>>>>> as an ADSL router, public NTP server and DNS server. dmesg info:
>>>>>
>>>>>> OpenBSD 6.1 (GENERIC) #291: Sat Apr 1 13:49:08 MDT 2017
>>>>
>>>> OpenBSD 6.1 isn't supported anymore, please upgrade.
>>>>
>>>
>>> Upgrade what? The OS, the router? If I'm 100% certain that moving to
>>> 6.2/6.3 will fix rl, then sure, but this answer is not helpful, as I've
>>> been battling this problem for over a month.
>>
>> Maybe your issue is fixed in 6.2 or 6.3, who knows. 6.1 isn't supported
>> anymore and you use it on a router connecting to the Internet. I can
>> only recommend upgrading.
>>
>
> It might conversely also be made worse by 6.2 or 6.3. In theory, it
> shouldn't, but then again, in theory, I shouldn't have been getting this
> problem either.
>
> An update of the OS will have to wait until I can purchase another CF
> card to load with OpenBSD 6.3 and migrate the configuration.
>
> Alternatively, if the problem is hardware, I can just replace the whole
> box. Updating OpenBSD on the existing one would be a waste of time.
>
> I need a way of ruling out the hardware as being an issue. Until then,
> OpenBSD 6.1 stays, unless the debugging facilities in 6.2/6.3 are
> drastically different that make troubleshooting this problem easier.
>
> I think I've tracked down the driver source here:
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ic/rtl81x9.c
> The log suggests it has not changed since the release of OpenBSD 6.1.
>
Here's the thing. There are rules to the game with every OS. With
OpenBSD, if you have to stay up to date -- the support tail is only
about a year long, and that is really only security issues.
So, what are you after? A magic, secret sysctl, "sysctl
rl.work.properly=1" ? Nope, no such thing. Sorry. A patch to fix it?
Not going to happen against 6.1, 6.2, or even 6.3, most likely. -current
is where development happens, only security issues and maybe some
behavior regressions are ever pushed back to old releases...not
operational improvements, new features, or new hw support.
Now, rl chips were considered the worst pieces of network junk around
until the ARM systems started sprouting networking chips. Don't get me
wrong, I've used a lot of them, and had pretty good luck with them, but
a lot of people I respect and who know better than me hate the #$%^ things.
You say a couple things that catch my eye -- 1) 6.1 is over a year old,
and you say you have been battling the problem for a month. So
something changed. That's hinting hw, not sw. (typically. Or the load
changed. or something). 2) you say you had "similar" problems with
another OS. Similar to what, I'm not sure, but that sounds like you
have a HW problem. Keep in mind, when it comes to networks, it's not
just the computer -- the wire and the switch are also all suspect.
But it boils down to this: if you want help on OpenBSD, you play by the
rules and run either -current or at least a supported release (and if
you contend it's an OS issue, you verify it still exists in -current!).
If you don't need OpenBSD help...this isn't the place. And if you can
say with certainty, "everything is the same", you will have no trouble
adding debugging info and figure out your own problem.
Nick.
> On 01/05/18 03:00, Solene Rapenne wrote:
>>
>> Stuart Longland writes:
>>
>>> On 29/04/18 18:08, Solene Rapenne wrote:
>>>>
>>>> Stuart Longland writes:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I've got an Advantech UNO-1150G industrial PC running OpenBSD 6.1 acting
>>>>> as an ADSL router, public NTP server and DNS server. dmesg info:
>>>>>
>>>>>> OpenBSD 6.1 (GENERIC) #291: Sat Apr 1 13:49:08 MDT 2017
>>>>
>>>> OpenBSD 6.1 isn't supported anymore, please upgrade.
>>>>
>>>
>>> Upgrade what? The OS, the router? If I'm 100% certain that moving to
>>> 6.2/6.3 will fix rl, then sure, but this answer is not helpful, as I've
>>> been battling this problem for over a month.
>>
>> Maybe your issue is fixed in 6.2 or 6.3, who knows. 6.1 isn't supported
>> anymore and you use it on a router connecting to the Internet. I can
>> only recommend upgrading.
>>
>
> It might conversely also be made worse by 6.2 or 6.3. In theory, it
> shouldn't, but then again, in theory, I shouldn't have been getting this
> problem either.
>
> An update of the OS will have to wait until I can purchase another CF
> card to load with OpenBSD 6.3 and migrate the configuration.
>
> Alternatively, if the problem is hardware, I can just replace the whole
> box. Updating OpenBSD on the existing one would be a waste of time.
>
> I need a way of ruling out the hardware as being an issue. Until then,
> OpenBSD 6.1 stays, unless the debugging facilities in 6.2/6.3 are
> drastically different that make troubleshooting this problem easier.
>
> I think I've tracked down the driver source here:
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ic/rtl81x9.c
> The log suggests it has not changed since the release of OpenBSD 6.1.
>
Here's the thing. There are rules to the game with every OS. With
OpenBSD, if you have to stay up to date -- the support tail is only
about a year long, and that is really only security issues.
So, what are you after? A magic, secret sysctl, "sysctl
rl.work.properly=1" ? Nope, no such thing. Sorry. A patch to fix it?
Not going to happen against 6.1, 6.2, or even 6.3, most likely. -current
is where development happens, only security issues and maybe some
behavior regressions are ever pushed back to old releases...not
operational improvements, new features, or new hw support.
Now, rl chips were considered the worst pieces of network junk around
until the ARM systems started sprouting networking chips. Don't get me
wrong, I've used a lot of them, and had pretty good luck with them, but
a lot of people I respect and who know better than me hate the #$%^ things.
You say a couple things that catch my eye -- 1) 6.1 is over a year old,
and you say you have been battling the problem for a month. So
something changed. That's hinting hw, not sw. (typically. Or the load
changed. or something). 2) you say you had "similar" problems with
another OS. Similar to what, I'm not sure, but that sounds like you
have a HW problem. Keep in mind, when it comes to networks, it's not
just the computer -- the wire and the switch are also all suspect.
But it boils down to this: if you want help on OpenBSD, you play by the
rules and run either -current or at least a supported release (and if
you contend it's an OS issue, you verify it still exists in -current!).
If you don't need OpenBSD help...this isn't the place. And if you can
say with certainty, "everything is the same", you will have no trouble
adding debugging info and figure out your own problem.
Nick.
Re: [Patch] Python for non wxallowed /usr/local
I was trying to say that port maintainer added wxneded to python and fixed
issues with packages
that use WX (i.e. py- cryptography). I assume they did not work without of
it.
And now they work for python running in /usr/local (because it is
wxallowed by default).
I am not native English speaker, so I have some problems expressing my
thoughts. Sorry.
> My patch may and will break ports which depend on W|X,
And with out of it virtualenv (one of the most used packages) is broken.
If we keep default python with wxneeded then nothing will brake, right?
And those, who need virtualenv will have ability to simply "pk_add
python3-nowx".
Now they have to rebuild python from ports disabling USE_WXNEEDED manually,
which could be cumbersome (i.e. I do not have ports on server, I need to
build package on another machine, update it etc).
From my point of view that is what happens:
1) secuirity is slightly decreased because we run wxenabled app on
wxallowed /usr/local by default
2) one of the most popular packages is broken (virtualenv in home does not
work)
issues with packages
that use WX (i.e. py- cryptography). I assume they did not work without of
it.
And now they work for python running in /usr/local (because it is
wxallowed by default).
I am not native English speaker, so I have some problems expressing my
thoughts. Sorry.
> My patch may and will break ports which depend on W|X,
And with out of it virtualenv (one of the most used packages) is broken.
If we keep default python with wxneeded then nothing will brake, right?
And those, who need virtualenv will have ability to simply "pk_add
python3-nowx".
Now they have to rebuild python from ports disabling USE_WXNEEDED manually,
which could be cumbersome (i.e. I do not have ports on server, I need to
build package on another machine, update it etc).
From my point of view that is what happens:
1) secuirity is slightly decreased because we run wxenabled app on
wxallowed /usr/local by default
2) one of the most popular packages is broken (virtualenv in home does not
work)
Re: Best Practices python virtualenv
The only difference is venv creates link to python, it does not copy binary
itself.
You now have
python3 -> /usr/local/bin/python3
in your venv.
Since /usr/local/ has wxallowed by default (see your /etc/fstab) it works.
Does it affect security?
In theory -- yes, because python can now create WX pages.
One may say that it sounds paranoic, and in fact it is,
but OpenBSD is _paranoic_ about security.
That is why it has W^X.
They left wxallowed for /usr/local because there are a lot
of software in ports, written by less "secure paranoics" than openbsd
developers, and
this software needs WX.
Some python packages are good examples.
Python port maintainer added wxneeded to python because
of these packages.
But if you do not use any of these packages, you can
disable wxneeded removing any (theoretical) threat that may use WX.
That will make python more secure and (as side-effect) fix virtualenv
problems.
It is less important for developer laptop, but if you can improve security,
why
not?
You will not create "big security hole" with your current approach.
You will not create it even by adding wxallowed to /home.
So, it is not a critical issue.
But I feel that decreasing security by running wxneeded app with
out of good reason(if you do not need these packages of course) is not
"OpenBSD way":)
itself.
You now have
python3 -> /usr/local/bin/python3
in your venv.
Since /usr/local/ has wxallowed by default (see your /etc/fstab) it works.
Does it affect security?
In theory -- yes, because python can now create WX pages.
One may say that it sounds paranoic, and in fact it is,
but OpenBSD is _paranoic_ about security.
That is why it has W^X.
They left wxallowed for /usr/local because there are a lot
of software in ports, written by less "secure paranoics" than openbsd
developers, and
this software needs WX.
Some python packages are good examples.
Python port maintainer added wxneeded to python because
of these packages.
But if you do not use any of these packages, you can
disable wxneeded removing any (theoretical) threat that may use WX.
That will make python more secure and (as side-effect) fix virtualenv
problems.
It is less important for developer laptop, but if you can improve security,
why
not?
You will not create "big security hole" with your current approach.
You will not create it even by adding wxallowed to /home.
So, it is not a critical issue.
But I feel that decreasing security by running wxneeded app with
out of good reason(if you do not need these packages of course) is not
"OpenBSD way":)
Re: [Patch] Python for non wxallowed /usr/local
On Tue, 1 May 2018 03:13:23 +0300, IL Ka <kazakevichilya@gmail.com>
wrote:
> To fix it, I rebuild python from ports using USE_WXNEEDED=no
> It solved my problem, but I do not want to build Python from ports,
> so better solution would be to
> * Accept your patch and create 2 flavors of python
> * Or set USE_WXNEEDED=no by default
Can you stop being selfish for a minute and quit being focused on your
sole usage?
> Virtualenv is de-facto standard, it is not good to break it
> because some modules need WX.
But I guess it's perfectly fine to break other usage than yours.
Stop talking and start working on patches that would be accepted (read
sthen's email in this thread for the guidance).
wrote:
> To fix it, I rebuild python from ports using USE_WXNEEDED=no
> It solved my problem, but I do not want to build Python from ports,
> so better solution would be to
> * Accept your patch and create 2 flavors of python
> * Or set USE_WXNEEDED=no by default
Can you stop being selfish for a minute and quit being focused on your
sole usage?
> Virtualenv is de-facto standard, it is not good to break it
> because some modules need WX.
But I guess it's perfectly fine to break other usage than yours.
Stop talking and start working on patches that would be accepted (read
sthen's email in this thread for the guidance).
Re: [Patch] Python for non wxallowed /usr/local
On Tue, May 01, 2018 at 03:13:23AM +0300, IL Ka wrote:
> Hi,
>
> > Can you please give me a link to fix?
> Sorry, I misunderstood you.
>
You said "thank you for fixing py-cryptography".
I didn't notice that fix.
> I run snapshot and it has wxallowed for /usr/local by default (I haven't
> touched it).
> $ grep wxallowed /etc/fstab
> 4154a363527e316f.h /usr/local ffs rw,wxallowed,nodev 1 2
>
> python is wxneeded since 2016 in OpenBSD:
> https://github.com/openbsd/ports/blame/master/lang/python/Makefile.inc#L127
>
> $ readelf -a $(which python3) | grep WX
> OPENBSD_WXNEED 0x0000000000000000 0x0000000000000000 0x0000000000000000
>
> So, it now works perfectly.
>
> But virtualenv is broken because it copies file to my home,
> and /home is not wxallowed.
>
> I do not use any package that needs WX, so I am not able to use virtualenv
> for no good reason.
>
> To fix it, I rebuild python from ports using USE_WXNEEDED=no
> It solved my problem, but I do not want to build Python from ports,
> so better solution would be to
> * Accept your patch and create 2 flavors of python
> * Or set USE_WXNEEDED=no by default
>
> Virtualenv is de-facto standard, it is not good to break it
> because some modules need WX.
>
> And enabling "wxneeded" for python generally decreases security.
>
> > it's better to patch W|X ports
> Yes, but is not it better to disable wxneeded and then try to patch them
> or create two flavors until they are fixed?
>
My patch may and will break ports which depend on W|X,
so that users have to manually install wx flavor.
> Ilya.
> Hi,
>
> > Can you please give me a link to fix?
> Sorry, I misunderstood you.
>
You said "thank you for fixing py-cryptography".
I didn't notice that fix.
> I run snapshot and it has wxallowed for /usr/local by default (I haven't
> touched it).
> $ grep wxallowed /etc/fstab
> 4154a363527e316f.h /usr/local ffs rw,wxallowed,nodev 1 2
>
> python is wxneeded since 2016 in OpenBSD:
> https://github.com/openbsd/ports/blame/master/lang/python/Makefile.inc#L127
>
> $ readelf -a $(which python3) | grep WX
> OPENBSD_WXNEED 0x0000000000000000 0x0000000000000000 0x0000000000000000
>
> So, it now works perfectly.
>
> But virtualenv is broken because it copies file to my home,
> and /home is not wxallowed.
>
> I do not use any package that needs WX, so I am not able to use virtualenv
> for no good reason.
>
> To fix it, I rebuild python from ports using USE_WXNEEDED=no
> It solved my problem, but I do not want to build Python from ports,
> so better solution would be to
> * Accept your patch and create 2 flavors of python
> * Or set USE_WXNEEDED=no by default
>
> Virtualenv is de-facto standard, it is not good to break it
> because some modules need WX.
>
> And enabling "wxneeded" for python generally decreases security.
>
> > it's better to patch W|X ports
> Yes, but is not it better to disable wxneeded and then try to patch them
> or create two flavors until they are fixed?
>
My patch may and will break ports which depend on W|X,
so that users have to manually install wx flavor.
> Ilya.
Re: Best Practices python virtualenv
Not to disagree but if using python3 -m venv in home works and home is not
mounted as wxallowed is there still a security issue with this workflow?
Granted at this point talking about a development workstation and not a server.
So while I am at it I guess I should ask is what you are saying more from a
serving python web app perspective, security wise?
Just trying to understand what I seem to be missing.
Ken
On Tue, May 01, 2018 at 03:18:00AM +0300, IL Ka wrote:
> It is up to you, but I still belive that best solution is to rebuild python
> without of wxneeded.
> 1) It improves security
> 2) It fixes your virtualenv issue.
>
> If you do not use packages that need WX, why do you need wxneed?
mounted as wxallowed is there still a security issue with this workflow?
Granted at this point talking about a development workstation and not a server.
So while I am at it I guess I should ask is what you are saying more from a
serving python web app perspective, security wise?
Just trying to understand what I seem to be missing.
Ken
On Tue, May 01, 2018 at 03:18:00AM +0300, IL Ka wrote:
> It is up to you, but I still belive that best solution is to rebuild python
> without of wxneeded.
> 1) It improves security
> 2) It fixes your virtualenv issue.
>
> If you do not use packages that need WX, why do you need wxneed?
Re: Best Practices python virtualenv
It is up to you, but I still belive that best solution is to rebuild python
without of wxneeded.
1) It improves security
2) It fixes your virtualenv issue.
If you do not use packages that need WX, why do you need wxneed?
without of wxneeded.
1) It improves security
2) It fixes your virtualenv issue.
If you do not use packages that need WX, why do you need wxneed?
Re: [Patch] Python for non wxallowed /usr/local
Hi,
> Can you please give me a link to fix?
Sorry, I misunderstood you.
I run snapshot and it has wxallowed for /usr/local by default (I haven't
touched it).
$ grep wxallowed /etc/fstab
4154a363527e316f.h /usr/local ffs rw,wxallowed,nodev 1 2
python is wxneeded since 2016 in OpenBSD:
https://github.com/openbsd/ports/blame/master/lang/python/Makefile.inc#L127
$ readelf -a $(which python3) | grep WX
OPENBSD_WXNEED 0x0000000000000000 0x0000000000000000 0x0000000000000000
So, it now works perfectly.
But virtualenv is broken because it copies file to my home,
and /home is not wxallowed.
I do not use any package that needs WX, so I am not able to use virtualenv
for no good reason.
To fix it, I rebuild python from ports using USE_WXNEEDED=no
It solved my problem, but I do not want to build Python from ports,
so better solution would be to
* Accept your patch and create 2 flavors of python
* Or set USE_WXNEEDED=no by default
Virtualenv is de-facto standard, it is not good to break it
because some modules need WX.
And enabling "wxneeded" for python generally decreases security.
> it's better to patch W|X ports
Yes, but is not it better to disable wxneeded and then try to patch them
or create two flavors until they are fixed?
Ilya.
> Can you please give me a link to fix?
Sorry, I misunderstood you.
I run snapshot and it has wxallowed for /usr/local by default (I haven't
touched it).
$ grep wxallowed /etc/fstab
4154a363527e316f.h /usr/local ffs rw,wxallowed,nodev 1 2
python is wxneeded since 2016 in OpenBSD:
https://github.com/openbsd/ports/blame/master/lang/python/Makefile.inc#L127
$ readelf -a $(which python3) | grep WX
OPENBSD_WXNEED 0x0000000000000000 0x0000000000000000 0x0000000000000000
So, it now works perfectly.
But virtualenv is broken because it copies file to my home,
and /home is not wxallowed.
I do not use any package that needs WX, so I am not able to use virtualenv
for no good reason.
To fix it, I rebuild python from ports using USE_WXNEEDED=no
It solved my problem, but I do not want to build Python from ports,
so better solution would be to
* Accept your patch and create 2 flavors of python
* Or set USE_WXNEEDED=no by default
Virtualenv is de-facto standard, it is not good to break it
because some modules need WX.
And enabling "wxneeded" for python generally decreases security.
> it's better to patch W|X ports
Yes, but is not it better to disable wxneeded and then try to patch them
or create two flavors until they are fixed?
Ilya.
Re: Best Practices python virtualenv
I happen to like python and will be the first I reach for for many simple or
even some bigger tasks. Nothing against those other languages. I actually have a
special place in my heart for perl, but with the perl 5 vs 6 thing I wonder on
the longer term future of the language.
Honestly I need to get the rust off of my c skills.
Ken
PS - please don't let me perl comment start any flame wars... please please
> My current position is to simply avoid python in favour of c,perl,sh
> and even php.
>
even some bigger tasks. Nothing against those other languages. I actually have a
special place in my heart for perl, but with the perl 5 vs 6 thing I wonder on
the longer term future of the language.
Honestly I need to get the rust off of my c skills.
Ken
PS - please don't let me perl comment start any flame wars... please please
> My current position is to simply avoid python in favour of c,perl,sh
> and even php.
>
Re: Best Practices python virtualenv
Thanks for all the responses but it seems an alternate solution presented by
another user in a direct reply is to use python3 - m venv. Basically using the
venv built in to python3 as opposed to the legacy method of py-virtualenv that I
typically only have to use for older python 2 code bases.
Thanks all for the replies.
Ken
On Mon, Apr 30, 2018 at 06:23:32PM -0400, Dave Voutila wrote:
> Ken MacKenzie <ken@mack-z.com> writes:
>
> > Is there a recommended best practice when setting up an environment with
> > python
> > virtualenv with regards to wxallowed.
>
> AFAIK nothing official.
>
> >
> > My typical workflow is under my home directory I have a
> > dev/language/project/.venv type structure. I guess the simple solution is to
> > mount /home as wxallowed in /etc/fstab, but is that truly the preferred way.
> > Seems to make a new attack surface for anything in home.
> >
>
> Turning off any default mitigations is probably the opposite of "preferred".
>
> > The other option I am thinking is to create a dev-username location in
> > /usr/local somewhere and then ln -s that into my home structure accordingly.
> >
> > Since I am new to OpenBSD I figured I would ask first and did not find much
> > on
> > this topic other than third parties that seem to want to casually just add
> > home
> > to wxallowed.
> >
>
> I've been too lazy to dig into and "fix" this in the py{2,3}-virtualenv
> port. The main issue is it copies the binary for the target python
> executable and doesn't symlink it. It's really not a bug and more an
> adaptation issue so I've not been inclined.
>
> However, symbolic links to /usr/local/bin/python work fine if they're
> located on partitions that aren't mounted wxallowed. I'd imagine if
> virtualenv created a symlink things would "just work."
>
> So what I do, instead of teaching virtualenv to symlink instead of copy,
> is just confine my virtualenvs to /usr/local/venv (owned by root:wsrc).
>
> I then just activate via the usual means of the activate script:
>
> kogelvis$ . /usr/local/venv/my-project/bin/activate
>
> Typically, on other systems, I'd locate it in ~/.venv but for my
> personal machine it's not an issue.
>
> I do set an environment variable:
>
> WORKON_HOME=/usr/local/venv
>
> in .profile so I can configure tools like emacs major modes to point to
> where I want them to create/find virtual environments.
>
> > Thanks in advance for any guidance,
> >
> > Ken
another user in a direct reply is to use python3 - m venv. Basically using the
venv built in to python3 as opposed to the legacy method of py-virtualenv that I
typically only have to use for older python 2 code bases.
Thanks all for the replies.
Ken
On Mon, Apr 30, 2018 at 06:23:32PM -0400, Dave Voutila wrote:
> Ken MacKenzie <ken@mack-z.com> writes:
>
> > Is there a recommended best practice when setting up an environment with
> > python
> > virtualenv with regards to wxallowed.
>
> AFAIK nothing official.
>
> >
> > My typical workflow is under my home directory I have a
> > dev/language/project/.venv type structure. I guess the simple solution is to
> > mount /home as wxallowed in /etc/fstab, but is that truly the preferred way.
> > Seems to make a new attack surface for anything in home.
> >
>
> Turning off any default mitigations is probably the opposite of "preferred".
>
> > The other option I am thinking is to create a dev-username location in
> > /usr/local somewhere and then ln -s that into my home structure accordingly.
> >
> > Since I am new to OpenBSD I figured I would ask first and did not find much
> > on
> > this topic other than third parties that seem to want to casually just add
> > home
> > to wxallowed.
> >
>
> I've been too lazy to dig into and "fix" this in the py{2,3}-virtualenv
> port. The main issue is it copies the binary for the target python
> executable and doesn't symlink it. It's really not a bug and more an
> adaptation issue so I've not been inclined.
>
> However, symbolic links to /usr/local/bin/python work fine if they're
> located on partitions that aren't mounted wxallowed. I'd imagine if
> virtualenv created a symlink things would "just work."
>
> So what I do, instead of teaching virtualenv to symlink instead of copy,
> is just confine my virtualenvs to /usr/local/venv (owned by root:wsrc).
>
> I then just activate via the usual means of the activate script:
>
> kogelvis$ . /usr/local/venv/my-project/bin/activate
>
> Typically, on other systems, I'd locate it in ~/.venv but for my
> personal machine it's not an issue.
>
> I do set an environment variable:
>
> WORKON_HOME=/usr/local/venv
>
> in .profile so I can configure tools like emacs major modes to point to
> where I want them to create/find virtual environments.
>
> > Thanks in advance for any guidance,
> >
> > Ken
new misc/posixtestsuite
Hi,
I would like to run the POSIX test suite within OpenBSD regress.
The easiest way to import and compile the tests seems to be a port.
Note that there are a lot of C tests that do not compile. The build
error is not fatal, it generates just a log messages.
The package contains the sources, the build output and the successfully
created test binaries. This allows run the tests and post process
the results.
Comment:
open POSIX test suite
Description:
The Open POSIX Test Suite is a test suite for POSIX 2001 APIs, not
tied to specific implementations. It provides conformance, functional,
and stress testing. Initial focus is on Threads, Clocks & Timers,
Signals, Message Queues, and Semaphores.
To run POSIX test suite on a regular basis as a OpenBSD regression
test, compile the software as a port. All files needed to run the
tests are installed as package. The port specific tool posixtestsuite
creates a run time environment, runs the tests, and stores the
results in the current directory.
ok?
bluhm
I would like to run the POSIX test suite within OpenBSD regress.
The easiest way to import and compile the tests seems to be a port.
Note that there are a lot of C tests that do not compile. The build
error is not fatal, it generates just a log messages.
The package contains the sources, the build output and the successfully
created test binaries. This allows run the tests and post process
the results.
Comment:
open POSIX test suite
Description:
The Open POSIX Test Suite is a test suite for POSIX 2001 APIs, not
tied to specific implementations. It provides conformance, functional,
and stress testing. Initial focus is on Threads, Clocks & Timers,
Signals, Message Queues, and Semaphores.
To run POSIX test suite on a regular basis as a OpenBSD regression
test, compile the software as a port. All files needed to run the
tests are installed as package. The port specific tool posixtestsuite
creates a run time environment, runs the tests, and stores the
results in the current directory.
ok?
bluhm
Re: [Patch] Python for non wxallowed /usr/local
On Mon, Apr 30, 2018 at 03:22:21PM -0700, Il Ka wrote:
> Thank you for fixing py-cryptography in /usr/local,
> but we now have python that can't be launched from home
> (because it is not wxallowed).
>
Hi!
Can you please give me a link to fix?
(I hope you didn't say sarcasm)
> And it breaks virtualenv:
> https://marc.info/?l=openbsd-misc&m=152510694522191&w=2
>
> virtualenv is used by almost any python developer, and we rendered
> it to unusable, unless one mount home with wxallowed
> or rebuild python from ports disabling this option.
>
> Even if I do not need py-cryptography I have to pay the price.
>
> Could we please create two flavors or revert this change?
> I can create patch and send it to port maintainer.
>
This part seems to be complicated, it's better to patch
W|X ports to get rid of USE_WXNEEDED in Python.
>
>
> --
> Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-ports-f108501.html
>
> Thank you for fixing py-cryptography in /usr/local,
> but we now have python that can't be launched from home
> (because it is not wxallowed).
>
Hi!
Can you please give me a link to fix?
(I hope you didn't say sarcasm)
> And it breaks virtualenv:
> https://marc.info/?l=openbsd-misc&m=152510694522191&w=2
>
> virtualenv is used by almost any python developer, and we rendered
> it to unusable, unless one mount home with wxallowed
> or rebuild python from ports disabling this option.
>
> Even if I do not need py-cryptography I have to pay the price.
>
> Could we please create two flavors or revert this change?
> I can create patch and send it to port maintainer.
>
This part seems to be complicated, it's better to patch
W|X ports to get rid of USE_WXNEEDED in Python.
>
>
> --
> Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-ports-f108501.html
>
Re: new: games/barony
A small update to install instead into ${LOCALBASE}/share/barony as request
by @bcallah.
On 30 April 2018 at 21:35, Brian Callahan <bcallah@devio.us> wrote:
> (Responding from my phone so apologies)
> Download the Linux version and extract it with unzip.
>
>
>
> Sent from my Verizon, Samsung Galaxy smartphone
>
> -------- Original message --------
> From: David CARLIER <devnexen@gmail.com>
> Date: 4/30/18 2:10 PM (GMT-05:00)
> To: Timo Myyrä <timo.myyra@bittivirhe.fi>
> Cc: Solene Rapenne <solene@perso.pw>, OpenBSD ports <ports@openbsd.org>
> Subject: Re: new: games/barony
>
> I checked the Gog com ... do not find the folders needed to get started the
> game ! e.g images maps items music sounds lang ...
>
> On 30 April 2018 at 15:05, Timo Myyrä <timo.myyra@bittivirhe.fi> wrote:
>
> > David CARLIER <devnexen@gmail.com> writes:
> >
> > > Thanks for the feedback, in case you can always force the Debug mode
> via
> > > cmake e.g. -DCMAKE_BUILD_TYPE=Debug
> > > If I recall correctly you re running it into ppc arch ? Would like to
> see
> > > classic x86 archs users feedbacks too.
> > > Will try myself in some hours.
> > >
> > > On 30 April 2018 at 11:01, Solene Rapenne <solene@perso.pw> wrote:
> > >
> > >>
> > >> Thomas Frohwein writes:
> > >>
> > >> > On Fri, Mar 30, 2018 at 12:42:36AM +0200, Solene Rapenne wrote:
> > >> >
> > >> > I tried it on amd64 - installed the package, downloaded Barony:
> Cursed
> > >> Edition
> > >> > from gog.com, innoextract, then copied all the game files to
> > >> > /usr/local/share/games/barony. It counts through all the
> 400-something
> > >> assets
> > >> > that it loads, but afterwards just exits without any error.
> > >> >
> > >> > The version on gog.com is listed as 2.0.7 and is probably
> outdated. I
> > >> think
> > >> > a README with some details on this and maybe the game data folder
> may
> > be
> > >> > useful.
> > >> >
> > >> > I'll probably have to wait for an update on gog.com before being
> able
> > >> to test.
> > >>
> > >> GOG now has 3.1.4 version. I still can't get the game to work, using
> > >> latest port version.
> > >>
> > >> I did :
> > >>
> > >> $ innoextract 'setup_barony_cursed_edition_3.1.4_(20340).exe'
> > >> $ doas rsync -av tmp/ /usr/local/share/games/barony/
> > >> $ barony
> > >> [12-58-43] Data path is /usr/local/share/games/barony
> > >> $ echo $?
> > >> $ 1
> > >>
> > >> I don't succeed having a backtrace with gdb.
> > >>
> >
> > Same issue seems to happen on amd64 here.
> > Haven't tested yet with debug build.
> >
> > Timo
> >
>
by @bcallah.
On 30 April 2018 at 21:35, Brian Callahan <bcallah@devio.us> wrote:
> (Responding from my phone so apologies)
> Download the Linux version and extract it with unzip.
>
>
>
> Sent from my Verizon, Samsung Galaxy smartphone
>
> -------- Original message --------
> From: David CARLIER <devnexen@gmail.com>
> Date: 4/30/18 2:10 PM (GMT-05:00)
> To: Timo Myyrä <timo.myyra@bittivirhe.fi>
> Cc: Solene Rapenne <solene@perso.pw>, OpenBSD ports <ports@openbsd.org>
> Subject: Re: new: games/barony
>
> I checked the Gog com ... do not find the folders needed to get started the
> game ! e.g images maps items music sounds lang ...
>
> On 30 April 2018 at 15:05, Timo Myyrä <timo.myyra@bittivirhe.fi> wrote:
>
> > David CARLIER <devnexen@gmail.com> writes:
> >
> > > Thanks for the feedback, in case you can always force the Debug mode
> via
> > > cmake e.g. -DCMAKE_BUILD_TYPE=Debug
> > > If I recall correctly you re running it into ppc arch ? Would like to
> see
> > > classic x86 archs users feedbacks too.
> > > Will try myself in some hours.
> > >
> > > On 30 April 2018 at 11:01, Solene Rapenne <solene@perso.pw> wrote:
> > >
> > >>
> > >> Thomas Frohwein writes:
> > >>
> > >> > On Fri, Mar 30, 2018 at 12:42:36AM +0200, Solene Rapenne wrote:
> > >> >
> > >> > I tried it on amd64 - installed the package, downloaded Barony:
> Cursed
> > >> Edition
> > >> > from gog.com, innoextract, then copied all the game files to
> > >> > /usr/local/share/games/barony. It counts through all the
> 400-something
> > >> assets
> > >> > that it loads, but afterwards just exits without any error.
> > >> >
> > >> > The version on gog.com is listed as 2.0.7 and is probably
> outdated. I
> > >> think
> > >> > a README with some details on this and maybe the game data folder
> may
> > be
> > >> > useful.
> > >> >
> > >> > I'll probably have to wait for an update on gog.com before being
> able
> > >> to test.
> > >>
> > >> GOG now has 3.1.4 version. I still can't get the game to work, using
> > >> latest port version.
> > >>
> > >> I did :
> > >>
> > >> $ innoextract 'setup_barony_cursed_edition_3.1.4_(20340).exe'
> > >> $ doas rsync -av tmp/ /usr/local/share/games/barony/
> > >> $ barony
> > >> [12-58-43] Data path is /usr/local/share/games/barony
> > >> $ echo $?
> > >> $ 1
> > >>
> > >> I don't succeed having a backtrace with gdb.
> > >>
> >
> > Same issue seems to happen on amd64 here.
> > Haven't tested yet with debug build.
> >
> > Timo
> >
>
Re: Best Practices python virtualenv
Ken MacKenzie <ken@mack-z.com> writes:
> Is there a recommended best practice when setting up an environment with
> python
> virtualenv with regards to wxallowed.
AFAIK nothing official.
>
> My typical workflow is under my home directory I have a
> dev/language/project/.venv type structure. I guess the simple solution is to
> mount /home as wxallowed in /etc/fstab, but is that truly the preferred way.
> Seems to make a new attack surface for anything in home.
>
Turning off any default mitigations is probably the opposite of "preferred".
> The other option I am thinking is to create a dev-username location in
> /usr/local somewhere and then ln -s that into my home structure accordingly.
>
> Since I am new to OpenBSD I figured I would ask first and did not find much
> on
> this topic other than third parties that seem to want to casually just add
> home
> to wxallowed.
>
I've been too lazy to dig into and "fix" this in the py{2,3}-virtualenv
port. The main issue is it copies the binary for the target python
executable and doesn't symlink it. It's really not a bug and more an
adaptation issue so I've not been inclined.
However, symbolic links to /usr/local/bin/python work fine if they're
located on partitions that aren't mounted wxallowed. I'd imagine if
virtualenv created a symlink things would "just work."
So what I do, instead of teaching virtualenv to symlink instead of copy,
is just confine my virtualenvs to /usr/local/venv (owned by root:wsrc).
I then just activate via the usual means of the activate script:
kogelvis$ . /usr/local/venv/my-project/bin/activate
Typically, on other systems, I'd locate it in ~/.venv but for my
personal machine it's not an issue.
I do set an environment variable:
WORKON_HOME=/usr/local/venv
in .profile so I can configure tools like emacs major modes to point to
where I want them to create/find virtual environments.
> Thanks in advance for any guidance,
>
> Ken
> Is there a recommended best practice when setting up an environment with
> python
> virtualenv with regards to wxallowed.
AFAIK nothing official.
>
> My typical workflow is under my home directory I have a
> dev/language/project/.venv type structure. I guess the simple solution is to
> mount /home as wxallowed in /etc/fstab, but is that truly the preferred way.
> Seems to make a new attack surface for anything in home.
>
Turning off any default mitigations is probably the opposite of "preferred".
> The other option I am thinking is to create a dev-username location in
> /usr/local somewhere and then ln -s that into my home structure accordingly.
>
> Since I am new to OpenBSD I figured I would ask first and did not find much
> on
> this topic other than third parties that seem to want to casually just add
> home
> to wxallowed.
>
I've been too lazy to dig into and "fix" this in the py{2,3}-virtualenv
port. The main issue is it copies the binary for the target python
executable and doesn't symlink it. It's really not a bug and more an
adaptation issue so I've not been inclined.
However, symbolic links to /usr/local/bin/python work fine if they're
located on partitions that aren't mounted wxallowed. I'd imagine if
virtualenv created a symlink things would "just work."
So what I do, instead of teaching virtualenv to symlink instead of copy,
is just confine my virtualenvs to /usr/local/venv (owned by root:wsrc).
I then just activate via the usual means of the activate script:
kogelvis$ . /usr/local/venv/my-project/bin/activate
Typically, on other systems, I'd locate it in ~/.venv but for my
personal machine it's not an issue.
I do set an environment variable:
WORKON_HOME=/usr/local/venv
in .profile so I can configure tools like emacs major modes to point to
where I want them to create/find virtual environments.
> Thanks in advance for any guidance,
>
> Ken
Re: [Patch] Python for non wxallowed /usr/local
Thank you for fixing py-cryptography in /usr/local,
but we now have python that can't be launched from home
(because it is not wxallowed).
And it breaks virtualenv:
https://marc.info/?l=openbsd-misc&m=152510694522191&w=2
virtualenv is used by almost any python developer, and we rendered
it to unusable, unless one mount home with wxallowed
or rebuild python from ports disabling this option.
Even if I do not need py-cryptography I have to pay the price.
Could we please create two flavors or revert this change?
I can create patch and send it to port maintainer.
--
Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-ports-f108501.html
but we now have python that can't be launched from home
(because it is not wxallowed).
And it breaks virtualenv:
https://marc.info/?l=openbsd-misc&m=152510694522191&w=2
virtualenv is used by almost any python developer, and we rendered
it to unusable, unless one mount home with wxallowed
or rebuild python from ports disabling this option.
Even if I do not need py-cryptography I have to pay the price.
Could we please create two flavors or revert this change?
I can create patch and send it to port maintainer.
--
Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-ports-f108501.html
Re: Best Practices python virtualenv
Hello.
Short answer: if you do not need py-cryptography and QtWebKit, just rebuild
python from ports disabling
USE_WXNEEDED.
I run Django using virtualenv in my $HOME and it works.
Long answer:
To use mmap(2) with PROT_EXEC | PROT_WRITE you need to link binary with
-z wxneeded (See ld(1)).
It adds OPENBSD_WXNEEDED header to binary.
You can check it with
$ readelf -a /usr/local/bin/python2 | grep WX
There should be "OPENBSD_WXNEED".
With out of it, mmap(2) returns "Not supported" for such requests.
When mounted with out of wxallowed, binaries with this header can't be
executed.
You will get "Permission denied".
At some moment, people found that py-cryptography and QtWebKit
need this header, so they added USE_WXNEEDED=yes to port.
http://openbsd-archive.7691.n7.nabble.com/Patch-Python-for-non-wxallowed-usr-local-td335767.html
See /usr/ports/lang/python/Makefile.inc
See also /usr/ports/infrastructure/mk/bsd.port.mk
for how this option is used and how Makefile.inc is included.
/usr/local has wxallowed, so py-cryptography and QtWebKit works there.
But they did not care about virtualenv.
We now have python linked with wxneeded by default:
$ readelf -a /usr/local/bin/python2 | grep WX
OPENBSD_WXNEED 0x0000000000000000 0x0000000000000000 0x0000000000000000
and its execution is not allowed on FS mounted with out of wxallowed.
To fix it, simply rebuild python with this option disabled.
Better solution is to create to flavors of python (with this option and
with out), but
that has not been done.
Ilya.
Short answer: if you do not need py-cryptography and QtWebKit, just rebuild
python from ports disabling
USE_WXNEEDED.
I run Django using virtualenv in my $HOME and it works.
Long answer:
To use mmap(2) with PROT_EXEC | PROT_WRITE you need to link binary with
-z wxneeded (See ld(1)).
It adds OPENBSD_WXNEEDED header to binary.
You can check it with
$ readelf -a /usr/local/bin/python2 | grep WX
There should be "OPENBSD_WXNEED".
With out of it, mmap(2) returns "Not supported" for such requests.
When mounted with out of wxallowed, binaries with this header can't be
executed.
You will get "Permission denied".
At some moment, people found that py-cryptography and QtWebKit
need this header, so they added USE_WXNEEDED=yes to port.
http://openbsd-archive.7691.n7.nabble.com/Patch-Python-for-non-wxallowed-usr-local-td335767.html
See /usr/ports/lang/python/Makefile.inc
See also /usr/ports/infrastructure/mk/bsd.port.mk
for how this option is used and how Makefile.inc is included.
/usr/local has wxallowed, so py-cryptography and QtWebKit works there.
But they did not care about virtualenv.
We now have python linked with wxneeded by default:
$ readelf -a /usr/local/bin/python2 | grep WX
OPENBSD_WXNEED 0x0000000000000000 0x0000000000000000 0x0000000000000000
and its execution is not allowed on FS mounted with out of wxallowed.
To fix it, simply rebuild python with this option disabled.
Better solution is to create to flavors of python (with this option and
with out), but
that has not been done.
Ilya.
Re: Troubleshooting rl instability on OpenBSD 6.1
On 01/05/18 03:00, Solene Rapenne wrote:
>
> Stuart Longland writes:
>
>> On 29/04/18 18:08, Solene Rapenne wrote:
>>>
>>> Stuart Longland writes:
>>>
>>>> Hi all,
>>>>
>>>> I've got an Advantech UNO-1150G industrial PC running OpenBSD 6.1 acting
>>>> as an ADSL router, public NTP server and DNS server. dmesg info:
>>>>
>>>>> OpenBSD 6.1 (GENERIC) #291: Sat Apr 1 13:49:08 MDT 2017
>>>
>>> OpenBSD 6.1 isn't supported anymore, please upgrade.
>>>
>>
>> Upgrade what? The OS, the router? If I'm 100% certain that moving to
>> 6.2/6.3 will fix rl, then sure, but this answer is not helpful, as I've
>> been battling this problem for over a month.
>
> Maybe your issue is fixed in 6.2 or 6.3, who knows. 6.1 isn't supported
> anymore and you use it on a router connecting to the Internet. I can
> only recommend upgrading.
>
It might conversely also be made worse by 6.2 or 6.3. In theory, it
shouldn't, but then again, in theory, I shouldn't have been getting this
problem either.
An update of the OS will have to wait until I can purchase another CF
card to load with OpenBSD 6.3 and migrate the configuration.
Alternatively, if the problem is hardware, I can just replace the whole
box. Updating OpenBSD on the existing one would be a waste of time.
I need a way of ruling out the hardware as being an issue. Until then,
OpenBSD 6.1 stays, unless the debugging facilities in 6.2/6.3 are
drastically different that make troubleshooting this problem easier.
I think I've tracked down the driver source here:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ic/rtl81x9.c
The log suggests it has not changed since the release of OpenBSD 6.1.
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
>
> Stuart Longland writes:
>
>> On 29/04/18 18:08, Solene Rapenne wrote:
>>>
>>> Stuart Longland writes:
>>>
>>>> Hi all,
>>>>
>>>> I've got an Advantech UNO-1150G industrial PC running OpenBSD 6.1 acting
>>>> as an ADSL router, public NTP server and DNS server. dmesg info:
>>>>
>>>>> OpenBSD 6.1 (GENERIC) #291: Sat Apr 1 13:49:08 MDT 2017
>>>
>>> OpenBSD 6.1 isn't supported anymore, please upgrade.
>>>
>>
>> Upgrade what? The OS, the router? If I'm 100% certain that moving to
>> 6.2/6.3 will fix rl, then sure, but this answer is not helpful, as I've
>> been battling this problem for over a month.
>
> Maybe your issue is fixed in 6.2 or 6.3, who knows. 6.1 isn't supported
> anymore and you use it on a router connecting to the Internet. I can
> only recommend upgrading.
>
It might conversely also be made worse by 6.2 or 6.3. In theory, it
shouldn't, but then again, in theory, I shouldn't have been getting this
problem either.
An update of the OS will have to wait until I can purchase another CF
card to load with OpenBSD 6.3 and migrate the configuration.
Alternatively, if the problem is hardware, I can just replace the whole
box. Updating OpenBSD on the existing one would be a waste of time.
I need a way of ruling out the hardware as being an issue. Until then,
OpenBSD 6.1 stays, unless the debugging facilities in 6.2/6.3 are
drastically different that make troubleshooting this problem easier.
I think I've tracked down the driver source here:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ic/rtl81x9.c
The log suggests it has not changed since the release of OpenBSD 6.1.
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
Re: new: games/barony
David CARLIER writes:
> @bcallah found out the Linux version is ok (we both checked the windows
> version) from the previous comments all the assets are inside
> data/noarch/game subfolder
>
> On 30 April 2018 at 22:29, Solene Rapenne <solene@perso.pw> wrote:
>
>>
>> David CARLIER writes:
>>
>> > I checked the Gog com ... do not find the folders needed to get started
>> the
>> > game ! e.g images maps items music sounds lang ...
>> >
>>
>> So, I assume that the port is not usable by GOG customers ? :/
>>
I saw bcallah@ mail a few minutes after sending mine. I used unzip on
the linux version, the game works! I will take a look on the port itself
now.
> @bcallah found out the Linux version is ok (we both checked the windows
> version) from the previous comments all the assets are inside
> data/noarch/game subfolder
>
> On 30 April 2018 at 22:29, Solene Rapenne <solene@perso.pw> wrote:
>
>>
>> David CARLIER writes:
>>
>> > I checked the Gog com ... do not find the folders needed to get started
>> the
>> > game ! e.g images maps items music sounds lang ...
>> >
>>
>> So, I assume that the port is not usable by GOG customers ? :/
>>
I saw bcallah@ mail a few minutes after sending mine. I used unzip on
the linux version, the game works! I will take a look on the port itself
now.
ThinkPad T480s - Elantech v4 clickpad configuration
Hi,
I've got a ThinkPad T480s that comes with an Elantech v4 Clickpad + Trackpoint (firmware version 0x7f3001).
Out of the box, this firmware version is unsupported and cannot be configured, but it does attach as a basic PS/2 mouse input. Unfortunately for me, this means "tap-to-click" is permanently enabled.
I'm fine with touchpads, but I consider "tap-to-click" to be an abomination of a feature that should have been named "tap-to-destroy-everything-by-mistake". I was willing to do whatever was necessary to disable it.
I applied the following patch to enable this firmware version:
Index: src/sys/dev/pckbc/pms.c
===================================================================
RCS file: /cvs/src/sys/dev/pckbc/pms.c,v
retrieving revision 1.86
diff -u -p -u -r1.86 pms.c
--- src/sys/dev/pckbc/pms.c 29 Apr 2018 08:50:04 -0000 1.86
+++ src/sys/dev/pckbc/pms.c 30 Apr 2018 19:43:12 -0000
@@ -1939,7 +1939,8 @@ elantech_get_hwinfo_v4(struct pms_softc
return (-1);
if (((fw_version & 0x0f0000) >> 16) != 6 &&
- (fw_version & 0x0f0000) >> 16 != 8)
+ ((fw_version & 0x0f0000) >> 16) != 8 &&
+ ((fw_version & 0x0f0000) >> 16) != 15)
return (-1);
elantech->fw_version = fw_version;
The clickpad is now configurable and appears to work, so I can use the laptop without "tap-to-annoy" happening every 5 seconds. However, this patch breaks the trackpoint because there is no support implemented for it yet.
Whenever the trackpoint is touched, it spews out the errors "unknown packet" and "not in sync yet, discard input". The most common unknown packet value is 0x00. After a bit of research, I found that Elantech v4 trackpoint packets are supposed to identify themselves with a value of 0x06. I have yet to determine why the trackpoint packets have the wrong value. For now, I've just disabled the trackpoint in UEFI settings to eliminate the error messages.
I've got a ThinkPad T480s that comes with an Elantech v4 Clickpad + Trackpoint (firmware version 0x7f3001).
Out of the box, this firmware version is unsupported and cannot be configured, but it does attach as a basic PS/2 mouse input. Unfortunately for me, this means "tap-to-click" is permanently enabled.
I'm fine with touchpads, but I consider "tap-to-click" to be an abomination of a feature that should have been named "tap-to-destroy-everything-by-mistake". I was willing to do whatever was necessary to disable it.
I applied the following patch to enable this firmware version:
Index: src/sys/dev/pckbc/pms.c
===================================================================
RCS file: /cvs/src/sys/dev/pckbc/pms.c,v
retrieving revision 1.86
diff -u -p -u -r1.86 pms.c
--- src/sys/dev/pckbc/pms.c 29 Apr 2018 08:50:04 -0000 1.86
+++ src/sys/dev/pckbc/pms.c 30 Apr 2018 19:43:12 -0000
@@ -1939,7 +1939,8 @@ elantech_get_hwinfo_v4(struct pms_softc
return (-1);
if (((fw_version & 0x0f0000) >> 16) != 6 &&
- (fw_version & 0x0f0000) >> 16 != 8)
+ ((fw_version & 0x0f0000) >> 16) != 8 &&
+ ((fw_version & 0x0f0000) >> 16) != 15)
return (-1);
elantech->fw_version = fw_version;
The clickpad is now configurable and appears to work, so I can use the laptop without "tap-to-annoy" happening every 5 seconds. However, this patch breaks the trackpoint because there is no support implemented for it yet.
Whenever the trackpoint is touched, it spews out the errors "unknown packet" and "not in sync yet, discard input". The most common unknown packet value is 0x00. After a bit of research, I found that Elantech v4 trackpoint packets are supposed to identify themselves with a value of 0x06. I have yet to determine why the trackpoint packets have the wrong value. For now, I've just disabled the trackpoint in UEFI settings to eliminate the error messages.
Re: new: games/barony
@bcallah found out the Linux version is ok (we both checked the windows
version) from the previous comments all the assets are inside
data/noarch/game subfolder
On 30 April 2018 at 22:29, Solene Rapenne <solene@perso.pw> wrote:
>
> David CARLIER writes:
>
> > I checked the Gog com ... do not find the folders needed to get started
> the
> > game ! e.g images maps items music sounds lang ...
> >
>
> So, I assume that the port is not usable by GOG customers ? :/
>
version) from the previous comments all the assets are inside
data/noarch/game subfolder
On 30 April 2018 at 22:29, Solene Rapenne <solene@perso.pw> wrote:
>
> David CARLIER writes:
>
> > I checked the Gog com ... do not find the folders needed to get started
> the
> > game ! e.g images maps items music sounds lang ...
> >
>
> So, I assume that the port is not usable by GOG customers ? :/
>
Re: new: games/barony
David CARLIER writes:
> I checked the Gog com ... do not find the folders needed to get started the
> game ! e.g images maps items music sounds lang ...
>
So, I assume that the port is not usable by GOG customers ? :/
> I checked the Gog com ... do not find the folders needed to get started the
> game ! e.g images maps items music sounds lang ...
>
So, I assume that the port is not usable by GOG customers ? :/
Re: new: games/barony
I was able to run the game with the Linux version indeed thanks ! (from
data/noarch/game/* folder content)
On 30 April 2018 at 21:35, Brian Callahan <bcallah@devio.us> wrote:
> (Responding from my phone so apologies)
> Download the Linux version and extract it with unzip.
>
>
>
> Sent from my Verizon, Samsung Galaxy smartphone
>
> -------- Original message --------
> From: David CARLIER <devnexen@gmail.com>
> Date: 4/30/18 2:10 PM (GMT-05:00)
> To: Timo Myyrä <timo.myyra@bittivirhe.fi>
> Cc: Solene Rapenne <solene@perso.pw>, OpenBSD ports <ports@openbsd.org>
> Subject: Re: new: games/barony
>
> I checked the Gog com ... do not find the folders needed to get started the
> game ! e.g images maps items music sounds lang ...
>
> On 30 April 2018 at 15:05, Timo Myyrä <timo.myyra@bittivirhe.fi> wrote:
>
> > David CARLIER <devnexen@gmail.com> writes:
> >
> > > Thanks for the feedback, in case you can always force the Debug mode
> via
> > > cmake e.g. -DCMAKE_BUILD_TYPE=Debug
> > > If I recall correctly you re running it into ppc arch ? Would like to
> see
> > > classic x86 archs users feedbacks too.
> > > Will try myself in some hours.
> > >
> > > On 30 April 2018 at 11:01, Solene Rapenne <solene@perso.pw> wrote:
> > >
> > >>
> > >> Thomas Frohwein writes:
> > >>
> > >> > On Fri, Mar 30, 2018 at 12:42:36AM +0200, Solene Rapenne wrote:
> > >> >
> > >> > I tried it on amd64 - installed the package, downloaded Barony:
> Cursed
> > >> Edition
> > >> > from gog.com, innoextract, then copied all the game files to
> > >> > /usr/local/share/games/barony. It counts through all the
> 400-something
> > >> assets
> > >> > that it loads, but afterwards just exits without any error.
> > >> >
> > >> > The version on gog.com is listed as 2.0.7 and is probably
> outdated. I
> > >> think
> > >> > a README with some details on this and maybe the game data folder
> may
> > be
> > >> > useful.
> > >> >
> > >> > I'll probably have to wait for an update on gog.com before being
> able
> > >> to test.
> > >>
> > >> GOG now has 3.1.4 version. I still can't get the game to work, using
> > >> latest port version.
> > >>
> > >> I did :
> > >>
> > >> $ innoextract 'setup_barony_cursed_edition_3.1.4_(20340).exe'
> > >> $ doas rsync -av tmp/ /usr/local/share/games/barony/
> > >> $ barony
> > >> [12-58-43] Data path is /usr/local/share/games/barony
> > >> $ echo $?
> > >> $ 1
> > >>
> > >> I don't succeed having a backtrace with gdb.
> > >>
> >
> > Same issue seems to happen on amd64 here.
> > Haven't tested yet with debug build.
> >
> > Timo
> >
>
data/noarch/game/* folder content)
On 30 April 2018 at 21:35, Brian Callahan <bcallah@devio.us> wrote:
> (Responding from my phone so apologies)
> Download the Linux version and extract it with unzip.
>
>
>
> Sent from my Verizon, Samsung Galaxy smartphone
>
> -------- Original message --------
> From: David CARLIER <devnexen@gmail.com>
> Date: 4/30/18 2:10 PM (GMT-05:00)
> To: Timo Myyrä <timo.myyra@bittivirhe.fi>
> Cc: Solene Rapenne <solene@perso.pw>, OpenBSD ports <ports@openbsd.org>
> Subject: Re: new: games/barony
>
> I checked the Gog com ... do not find the folders needed to get started the
> game ! e.g images maps items music sounds lang ...
>
> On 30 April 2018 at 15:05, Timo Myyrä <timo.myyra@bittivirhe.fi> wrote:
>
> > David CARLIER <devnexen@gmail.com> writes:
> >
> > > Thanks for the feedback, in case you can always force the Debug mode
> via
> > > cmake e.g. -DCMAKE_BUILD_TYPE=Debug
> > > If I recall correctly you re running it into ppc arch ? Would like to
> see
> > > classic x86 archs users feedbacks too.
> > > Will try myself in some hours.
> > >
> > > On 30 April 2018 at 11:01, Solene Rapenne <solene@perso.pw> wrote:
> > >
> > >>
> > >> Thomas Frohwein writes:
> > >>
> > >> > On Fri, Mar 30, 2018 at 12:42:36AM +0200, Solene Rapenne wrote:
> > >> >
> > >> > I tried it on amd64 - installed the package, downloaded Barony:
> Cursed
> > >> Edition
> > >> > from gog.com, innoextract, then copied all the game files to
> > >> > /usr/local/share/games/barony. It counts through all the
> 400-something
> > >> assets
> > >> > that it loads, but afterwards just exits without any error.
> > >> >
> > >> > The version on gog.com is listed as 2.0.7 and is probably
> outdated. I
> > >> think
> > >> > a README with some details on this and maybe the game data folder
> may
> > be
> > >> > useful.
> > >> >
> > >> > I'll probably have to wait for an update on gog.com before being
> able
> > >> to test.
> > >>
> > >> GOG now has 3.1.4 version. I still can't get the game to work, using
> > >> latest port version.
> > >>
> > >> I did :
> > >>
> > >> $ innoextract 'setup_barony_cursed_edition_3.1.4_(20340).exe'
> > >> $ doas rsync -av tmp/ /usr/local/share/games/barony/
> > >> $ barony
> > >> [12-58-43] Data path is /usr/local/share/games/barony
> > >> $ echo $?
> > >> $ 1
> > >>
> > >> I don't succeed having a backtrace with gdb.
> > >>
> >
> > Same issue seems to happen on amd64 here.
> > Haven't tested yet with debug build.
> >
> > Timo
> >
>
Re: new: games/barony
(Responding from my phone so apologies)Download the Linux version and extract it with unzip.
Sent from my Verizon, Samsung Galaxy smartphone
-------- Original message --------From: David CARLIER <devnexen@gmail.com> Date: 4/30/18 2:10 PM (GMT-05:00) To: Timo Myyrä <timo.myyra@bittivirhe.fi> Cc: Solene Rapenne <solene@perso.pw>, OpenBSD ports <ports@openbsd.org> Subject: Re: new: games/barony
I checked the Gog com ... do not find the folders needed to get started the
game ! e.g images maps items music sounds lang ...
On 30 April 2018 at 15:05, Timo Myyrä <timo.myyra@bittivirhe.fi> wrote:
> David CARLIER <devnexen@gmail.com> writes:
>
> > Thanks for the feedback, in case you can always force the Debug mode via
> > cmake e.g. -DCMAKE_BUILD_TYPE=Debug
> > If I recall correctly you re running it into ppc arch ? Would like to see
> > classic x86 archs users feedbacks too.
> > Will try myself in some hours.
> >
> > On 30 April 2018 at 11:01, Solene Rapenne <solene@perso.pw> wrote:
> >
> >>
> >> Thomas Frohwein writes:
> >>
> >> > On Fri, Mar 30, 2018 at 12:42:36AM +0200, Solene Rapenne wrote:
> >> >
> >> > I tried it on amd64 - installed the package, downloaded Barony: Cursed
> >> Edition
> >> > from gog.com, innoextract, then copied all the game files to
> >> > /usr/local/share/games/barony. It counts through all the 400-something
> >> assets
> >> > that it loads, but afterwards just exits without any error.
> >> >
> >> > The version on gog.com is listed as 2.0.7 and is probably outdated. I
> >> think
> >> > a README with some details on this and maybe the game data folder may
> be
> >> > useful.
> >> >
> >> > I'll probably have to wait for an update on gog.com before being able
> >> to test.
> >>
> >> GOG now has 3.1.4 version. I still can't get the game to work, using
> >> latest port version.
> >>
> >> I did :
> >>
> >> $ innoextract 'setup_barony_cursed_edition_3.1.4_(20340).exe'
> >> $ doas rsync -av tmp/ /usr/local/share/games/barony/
> >> $ barony
> >> [12-58-43] Data path is /usr/local/share/games/barony
> >> $ echo $?
> >> $ 1
> >>
> >> I don't succeed having a backtrace with gdb.
> >>
>
> Same issue seems to happen on amd64 here.
> Haven't tested yet with debug build.
>
> Timo
>
Sent from my Verizon, Samsung Galaxy smartphone
-------- Original message --------From: David CARLIER <devnexen@gmail.com> Date: 4/30/18 2:10 PM (GMT-05:00) To: Timo Myyrä <timo.myyra@bittivirhe.fi> Cc: Solene Rapenne <solene@perso.pw>, OpenBSD ports <ports@openbsd.org> Subject: Re: new: games/barony
I checked the Gog com ... do not find the folders needed to get started the
game ! e.g images maps items music sounds lang ...
On 30 April 2018 at 15:05, Timo Myyrä <timo.myyra@bittivirhe.fi> wrote:
> David CARLIER <devnexen@gmail.com> writes:
>
> > Thanks for the feedback, in case you can always force the Debug mode via
> > cmake e.g. -DCMAKE_BUILD_TYPE=Debug
> > If I recall correctly you re running it into ppc arch ? Would like to see
> > classic x86 archs users feedbacks too.
> > Will try myself in some hours.
> >
> > On 30 April 2018 at 11:01, Solene Rapenne <solene@perso.pw> wrote:
> >
> >>
> >> Thomas Frohwein writes:
> >>
> >> > On Fri, Mar 30, 2018 at 12:42:36AM +0200, Solene Rapenne wrote:
> >> >
> >> > I tried it on amd64 - installed the package, downloaded Barony: Cursed
> >> Edition
> >> > from gog.com, innoextract, then copied all the game files to
> >> > /usr/local/share/games/barony. It counts through all the 400-something
> >> assets
> >> > that it loads, but afterwards just exits without any error.
> >> >
> >> > The version on gog.com is listed as 2.0.7 and is probably outdated. I
> >> think
> >> > a README with some details on this and maybe the game data folder may
> be
> >> > useful.
> >> >
> >> > I'll probably have to wait for an update on gog.com before being able
> >> to test.
> >>
> >> GOG now has 3.1.4 version. I still can't get the game to work, using
> >> latest port version.
> >>
> >> I did :
> >>
> >> $ innoextract 'setup_barony_cursed_edition_3.1.4_(20340).exe'
> >> $ doas rsync -av tmp/ /usr/local/share/games/barony/
> >> $ barony
> >> [12-58-43] Data path is /usr/local/share/games/barony
> >> $ echo $?
> >> $ 1
> >>
> >> I don't succeed having a backtrace with gdb.
> >>
>
> Same issue seems to happen on amd64 here.
> Haven't tested yet with debug build.
>
> Timo
>
Re: swi-pl : tiny edition!
Hi,
I think that you can build your own package of swi-prolog by modifying
the Makefile in the ports tree, just read here:
http://www.swi-prolog.org/build/prerequisites.html
About what each of the dependencies do, remove the ones that you don't
want from LIB_DEPENDS and make a new PLIST for the package.
If not, you should look for the maintainer and ask him if it can make
pseudo-flavors for optional dependencies.
Just out of curiosity, why do you need a smaller version ?
Elias.
2018-04-30 3:38 GMT-03:00 Mayuresh Kathe <mayuresh@devio.us>:
> i don't have the skills nor the experience to accomplish this, so here.
> can there be a swi-pl-tiny edition of swi-prolog?
> as it stands today, swi-prolog has a whole lot of dependencies, as here;
> gmp, libexecinfo, pcre, ossp-uuid, jpeg, bzip2, lz, xz, libarchive, db,
> iodbc.
> it would be really helpful to have that tiny edition for a project i am
> working towards for and under openbsd.
> thanks.
>
I think that you can build your own package of swi-prolog by modifying
the Makefile in the ports tree, just read here:
http://www.swi-prolog.org/build/prerequisites.html
About what each of the dependencies do, remove the ones that you don't
want from LIB_DEPENDS and make a new PLIST for the package.
If not, you should look for the maintainer and ask him if it can make
pseudo-flavors for optional dependencies.
Just out of curiosity, why do you need a smaller version ?
Elias.
2018-04-30 3:38 GMT-03:00 Mayuresh Kathe <mayuresh@devio.us>:
> i don't have the skills nor the experience to accomplish this, so here.
> can there be a swi-pl-tiny edition of swi-prolog?
> as it stands today, swi-prolog has a whole lot of dependencies, as here;
> gmp, libexecinfo, pcre, ossp-uuid, jpeg, bzip2, lz, xz, libarchive, db,
> iodbc.
> it would be really helpful to have that tiny edition for a project i am
> working towards for and under openbsd.
> thanks.
>
Re: ICMPv6 Neighbor Advertisement PF Weirdness
I solved the problem described in my last email.
The problem was that we copy pasted the IPv6 address for each vlan
interface, and then changed part of the address for each interface, but
failed to change the prefix length to 64. This meant that each vlan
interface had a different address, but shared the same subnet with other
interfaces. Obviously this resulted in an "unusual" route table -- but it
is unclear to us why the previously described PF problem manifested in the
way it did -- especially given that the ICMPv6 packet used link-local
addresses, and the pass rule did not filter on interface. Seems like it is
possibly a bug.
Joe
On Mon, Apr 30, 2018 at 12:31 PM, Joe Crivello <josephcrivello@gmail.com>
wrote:
> Hello --
>
> While configuring a new firewall, I noticed that pflog0 was showing that
> some ICMPv6 neighbor advertisement packets were being blocked in on vlan51,
> which is a sub-interface of vmx1 (a vmxnet3 interface using VGT). I added a
> PF rule allowing this traffic to pass. However, even after adding the rule
> and flushing all state, the traffic was still being reported as blocked in
> by pflog0. Thinking that there might be something else wrong with the rule
> set, I made the pass rule "quick" and inserted it as the first pass rule in
> the set. This still didn't work.
>
> See below for (1) the first two rules of the rule set (they are the only
> ones that matter in this example), (2) a tcpdump that was run after the
> rule set was applied and states were flushed, showing the blocked traffic,
> and (3) the interface configurations in question.
>
> # pfctl -sr
> FILTER RULES:
> block drop log all label "Block all"
> pass in quick on any inet6 proto ipv6-icmp all icmp6-type neighbradv
>
> # tcpdump -netvvi pflog0 "icmp6 && ip6[40] == 136"
> tcpdump: WARNING: snaplen raised from 116 to 160
> tcpdump: listening on pflog0, link-type PFLOG
> rule 1/(match) [uid 0, pid 91607] block in on vlan51:
> fe80::1905:23c0:fe7a:dcfe > ff02::1: [|icmp6] (len 32, hlim 255)
> ^C
> 7 packets received by filter
> 0 packets dropped by kernel
>
> # ifconfig vmx1
> vmx1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> lladdr 00:0c:29:50:66:d1
> index 2 priority 0 llprio 3
> media: Ethernet autoselect (10GbaseT)
> status: active
> inet6 fe80::20c:29ff:fe50:66d1%vmx1 prefixlen 64 scopeid 0x2
>
> # ifconfig vlan51
> vlan51: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> lladdr 00:0c:29:50:66:d1
> description: <SNIP>
> index 7 priority 0 llprio 3
> encap: vnetid 51 parent vmx1
> groups: vlan inetusr resolverusr
> media: Ethernet autoselect (10GbaseT)
> status: active
> inet6 fe80::20c:29ff:fe50:66d1%vlan51 prefixlen 64 scopeid 0x7
> inet 10.84.51.1 netmask 0xffffff00 broadcast 10.84.51.255
> inet6 <SNIP>::1 prefixlen 56
>
> The firewall is a VMware ESXi 6.5 virtual machine running
> SecurityRouter.org 6.2-lyra -- which is a distribution based on OpenBSD 6.2.
>
> Thinking that this might be a problem with the vmx(4) driver, we changed
> the network interface to emulated E1000e (em(4)), no change. Also tried
> adding "allow-opts" to the pass rule, no change.
>
> I understand this list isn't meant to support SecurityRouter.org's
> distribution of OpenBSD... but does anyone see something obviously wrong
> with my rule set or my expectations of how it should behave? Are there
> known problems with using VGT on VMware ESXi with vmx(4) and em(4) drivers?
> I reviewed the 6.2 errata and didn't see anything pertinent.
>
> Joe
>
>
The problem was that we copy pasted the IPv6 address for each vlan
interface, and then changed part of the address for each interface, but
failed to change the prefix length to 64. This meant that each vlan
interface had a different address, but shared the same subnet with other
interfaces. Obviously this resulted in an "unusual" route table -- but it
is unclear to us why the previously described PF problem manifested in the
way it did -- especially given that the ICMPv6 packet used link-local
addresses, and the pass rule did not filter on interface. Seems like it is
possibly a bug.
Joe
On Mon, Apr 30, 2018 at 12:31 PM, Joe Crivello <josephcrivello@gmail.com>
wrote:
> Hello --
>
> While configuring a new firewall, I noticed that pflog0 was showing that
> some ICMPv6 neighbor advertisement packets were being blocked in on vlan51,
> which is a sub-interface of vmx1 (a vmxnet3 interface using VGT). I added a
> PF rule allowing this traffic to pass. However, even after adding the rule
> and flushing all state, the traffic was still being reported as blocked in
> by pflog0. Thinking that there might be something else wrong with the rule
> set, I made the pass rule "quick" and inserted it as the first pass rule in
> the set. This still didn't work.
>
> See below for (1) the first two rules of the rule set (they are the only
> ones that matter in this example), (2) a tcpdump that was run after the
> rule set was applied and states were flushed, showing the blocked traffic,
> and (3) the interface configurations in question.
>
> # pfctl -sr
> FILTER RULES:
> block drop log all label "Block all"
> pass in quick on any inet6 proto ipv6-icmp all icmp6-type neighbradv
>
> # tcpdump -netvvi pflog0 "icmp6 && ip6[40] == 136"
> tcpdump: WARNING: snaplen raised from 116 to 160
> tcpdump: listening on pflog0, link-type PFLOG
> rule 1/(match) [uid 0, pid 91607] block in on vlan51:
> fe80::1905:23c0:fe7a:dcfe > ff02::1: [|icmp6] (len 32, hlim 255)
> ^C
> 7 packets received by filter
> 0 packets dropped by kernel
>
> # ifconfig vmx1
> vmx1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> lladdr 00:0c:29:50:66:d1
> index 2 priority 0 llprio 3
> media: Ethernet autoselect (10GbaseT)
> status: active
> inet6 fe80::20c:29ff:fe50:66d1%vmx1 prefixlen 64 scopeid 0x2
>
> # ifconfig vlan51
> vlan51: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> lladdr 00:0c:29:50:66:d1
> description: <SNIP>
> index 7 priority 0 llprio 3
> encap: vnetid 51 parent vmx1
> groups: vlan inetusr resolverusr
> media: Ethernet autoselect (10GbaseT)
> status: active
> inet6 fe80::20c:29ff:fe50:66d1%vlan51 prefixlen 64 scopeid 0x7
> inet 10.84.51.1 netmask 0xffffff00 broadcast 10.84.51.255
> inet6 <SNIP>::1 prefixlen 56
>
> The firewall is a VMware ESXi 6.5 virtual machine running
> SecurityRouter.org 6.2-lyra -- which is a distribution based on OpenBSD 6.2.
>
> Thinking that this might be a problem with the vmx(4) driver, we changed
> the network interface to emulated E1000e (em(4)), no change. Also tried
> adding "allow-opts" to the pass rule, no change.
>
> I understand this list isn't meant to support SecurityRouter.org's
> distribution of OpenBSD... but does anyone see something obviously wrong
> with my rule set or my expectations of how it should behave? Are there
> known problems with using VGT on VMware ESXi with vmx(4) and em(4) drivers?
> I reviewed the 6.2 errata and didn't see anything pertinent.
>
> Joe
>
>
[update] libconfig 1.7.2
? libconfig-1.5-libconfig++.so.10.0
? libconfig-1.5-libconfig.so.10.0
? libconfig-1.7.2-libconfig++.so.10.0
? libconfig-1.7.2-libconfig.so.10.0
Index: Makefile
===================================================================
RCS file: /cvs/ports/devel/libconfig/Makefile,v
retrieving revision 1.18
diff -u -r1.18 Makefile
--- Makefile 26 Jul 2017 22:45:18 -0000 1.18
+++ Makefile 30 Apr 2018 20:15:20 -0000
@@ -2,22 +2,21 @@
COMMENT= library for manipulating structured configuration files
-DISTNAME= libconfig-1.5
-REVISION = 1
+DISTNAME= libconfig-1.7.2
-SHARED_LIBS += config 10.0 # 11.0
-SHARED_LIBS += config++ 10.0 # 11.0
+SHARED_LIBS += config 11.0 # 11.2
+SHARED_LIBS += config++ 11.0 # 11.2
CATEGORIES= devel
-HOMEPAGE= http://www.hyperrealm.com/libconfig/libconfig.html
+HOMEPAGE= https://hyperrealm.github.io/libconfig/
# LGPLv2.1
PERMIT_PACKAGE_CDROM= Yes
WANTLIB += m ${COMPILER_LIBCXX}
-MASTER_SITES= http://www.hyperrealm.com/libconfig/
+MASTER_SITES= https://hyperrealm.github.io/libconfig/dist/
CONFIGURE_STYLE= gnu
Index: distinfo
===================================================================
RCS file: /cvs/ports/devel/libconfig/distinfo,v
retrieving revision 1.9
diff -u -r1.9 distinfo
--- distinfo 4 Jun 2015 05:26:17 -0000 1.9
+++ distinfo 30 Apr 2018 20:15:20 -0000
@@ -1,2 +1,2 @@
-SHA256 (libconfig-1.5.tar.gz) = 4x2qOQ2ORGHIgwUS/i4Tuho9agKiMFoCQp7sYeaHA/Y=
-SIZE (libconfig-1.5.tar.gz) = 644432
+SHA256 (libconfig-1.7.2.tar.gz) = fDx6nHP/MwIIQ4bpb5A+tizgaVO7FmYjX6x0NjoW+tk=
+SIZE (libconfig-1.7.2.tar.gz) = 721362
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/devel/libconfig/pkg/PLIST,v
retrieving revision 1.6
diff -u -r1.6 PLIST
--- pkg/PLIST 22 May 2015 11:31:12 -0000 1.6
+++ pkg/PLIST 30 Apr 2018 20:15:20 -0000
@@ -2,6 +2,11 @@
include/libconfig.h
include/libconfig.h++
@info info/libconfig.info
+lib/cmake/
+lib/cmake/libconfig/
+lib/cmake/libconfig/libconfigConfig.cmake
+lib/cmake/libconfig++/
+lib/cmake/libconfig++/libconfig++Config.cmake
lib/libconfig++.a
lib/libconfig++.la
@lib lib/libconfig++.so.${LIBconfig++_VERSION}
Hi,
small update with a new upstream website on github (noticed it because
the actual MASTER_SITES is a 404), i've only build-tested all the
consumers (umurmur, eliot, sslh, cvechecker and compton) and they were
fine - please test it if you actually use them !
Landry
? libconfig-1.5-libconfig.so.10.0
? libconfig-1.7.2-libconfig++.so.10.0
? libconfig-1.7.2-libconfig.so.10.0
Index: Makefile
===================================================================
RCS file: /cvs/ports/devel/libconfig/Makefile,v
retrieving revision 1.18
diff -u -r1.18 Makefile
--- Makefile 26 Jul 2017 22:45:18 -0000 1.18
+++ Makefile 30 Apr 2018 20:15:20 -0000
@@ -2,22 +2,21 @@
COMMENT= library for manipulating structured configuration files
-DISTNAME= libconfig-1.5
-REVISION = 1
+DISTNAME= libconfig-1.7.2
-SHARED_LIBS += config 10.0 # 11.0
-SHARED_LIBS += config++ 10.0 # 11.0
+SHARED_LIBS += config 11.0 # 11.2
+SHARED_LIBS += config++ 11.0 # 11.2
CATEGORIES= devel
-HOMEPAGE= http://www.hyperrealm.com/libconfig/libconfig.html
+HOMEPAGE= https://hyperrealm.github.io/libconfig/
# LGPLv2.1
PERMIT_PACKAGE_CDROM= Yes
WANTLIB += m ${COMPILER_LIBCXX}
-MASTER_SITES= http://www.hyperrealm.com/libconfig/
+MASTER_SITES= https://hyperrealm.github.io/libconfig/dist/
CONFIGURE_STYLE= gnu
Index: distinfo
===================================================================
RCS file: /cvs/ports/devel/libconfig/distinfo,v
retrieving revision 1.9
diff -u -r1.9 distinfo
--- distinfo 4 Jun 2015 05:26:17 -0000 1.9
+++ distinfo 30 Apr 2018 20:15:20 -0000
@@ -1,2 +1,2 @@
-SHA256 (libconfig-1.5.tar.gz) = 4x2qOQ2ORGHIgwUS/i4Tuho9agKiMFoCQp7sYeaHA/Y=
-SIZE (libconfig-1.5.tar.gz) = 644432
+SHA256 (libconfig-1.7.2.tar.gz) = fDx6nHP/MwIIQ4bpb5A+tizgaVO7FmYjX6x0NjoW+tk=
+SIZE (libconfig-1.7.2.tar.gz) = 721362
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/devel/libconfig/pkg/PLIST,v
retrieving revision 1.6
diff -u -r1.6 PLIST
--- pkg/PLIST 22 May 2015 11:31:12 -0000 1.6
+++ pkg/PLIST 30 Apr 2018 20:15:20 -0000
@@ -2,6 +2,11 @@
include/libconfig.h
include/libconfig.h++
@info info/libconfig.info
+lib/cmake/
+lib/cmake/libconfig/
+lib/cmake/libconfig/libconfigConfig.cmake
+lib/cmake/libconfig++/
+lib/cmake/libconfig++/libconfig++Config.cmake
lib/libconfig++.a
lib/libconfig++.la
@lib lib/libconfig++.so.${LIBconfig++_VERSION}
Hi,
small update with a new upstream website on github (noticed it because
the actual MASTER_SITES is a 404), i've only build-tested all the
consumers (umurmur, eliot, sslh, cvechecker and compton) and they were
fine - please test it if you actually use them !
Landry
Re: NEW: net/frrouting
2018-04-30 20:43 GMT+02:00 Aaron A. Glenn <aag@bsd.network>:
> * Stuart Henderson <stu@spacehopper.org> [2018-04-30 12:54]:
>>
>> Same root cause for all, there are just a couple of lines that need to
>> be copied over and tweaked from the quagga port.
>>
>
> I managed to figure out alll that was wrong there, but am now presented
> with something wrong in the actual code base itself.
>
> frr# /usr/local/sbin/isisd
> 2018/04/30 17:35:00 errors: ISIS: Failure to chdir to /etc/frr/, errno: 13
> frr# /usr/local/sbin/bgpd
> 2018/04/30 17:35:02 errors: BGP: Failure to chdir to /etc/frr/, errno: 13
> frr# /usr/local/sbin/ospfd
> 2018/04/30 17:35:03 errors: OSPF: Failure to chdir to /etc/frr/, errno: 13
I had those issues with your port earlier today but only when using
rcctl, not when launching the daemons manually.
$ doas rcctl -d start frr_zebra
doing _rc_parse_conf
doing _rc_quirks
frr_zebra_flags >-f /etc/frr/zebra.conf<
doing _rc_parse_conf /var/run/rc.d/frr_zebra
doing _rc_quirks
doing rc_check
frr_zebra
doing rc_start
doing _rc_wait start
doing rc_check
2018/04/30 22:01:27 errors: ZEBRA: Failure to chdir to /etc/, errno: 13
doing _rc_rm_runfile
(failed)
$ doas /usr/local/sbin/zebra -f /etc/frr/zebra.conf
2018/04/30 22:03:11 errors: ZEBRA: if_ioctl(SIOCGIFMEDIA) failed:
Inappropriate ioctl for device
2018/04/30 22:03:11 errors: ZEBRA: if_ioctl(SIOCGIFMEDIA) failed:
Inappropriate ioctl for device
2018/04/30 22:03:11 errors: ZEBRA: if_ioctl(SIOCGIFMEDIA) failed:
Inappropriate ioctl for device
^Z[1] + Suspended doas /usr/local/sbin/zebra -f /etc/frr/zebra.co
$ ps aux | grep zeb
_frr 7354 0.0 0.1 1832 5156 p2 T 10:03PM 0:00.02
/usr/local/sbin/zebra -f /etc/frr/zebra.conf
(same goes for bgpd, didn't tried the others).
> * Stuart Henderson <stu@spacehopper.org> [2018-04-30 12:54]:
>>
>> Same root cause for all, there are just a couple of lines that need to
>> be copied over and tweaked from the quagga port.
>>
>
> I managed to figure out alll that was wrong there, but am now presented
> with something wrong in the actual code base itself.
>
> frr# /usr/local/sbin/isisd
> 2018/04/30 17:35:00 errors: ISIS: Failure to chdir to /etc/frr/, errno: 13
> frr# /usr/local/sbin/bgpd
> 2018/04/30 17:35:02 errors: BGP: Failure to chdir to /etc/frr/, errno: 13
> frr# /usr/local/sbin/ospfd
> 2018/04/30 17:35:03 errors: OSPF: Failure to chdir to /etc/frr/, errno: 13
I had those issues with your port earlier today but only when using
rcctl, not when launching the daemons manually.
$ doas rcctl -d start frr_zebra
doing _rc_parse_conf
doing _rc_quirks
frr_zebra_flags >-f /etc/frr/zebra.conf<
doing _rc_parse_conf /var/run/rc.d/frr_zebra
doing _rc_quirks
doing rc_check
frr_zebra
doing rc_start
doing _rc_wait start
doing rc_check
2018/04/30 22:01:27 errors: ZEBRA: Failure to chdir to /etc/, errno: 13
doing _rc_rm_runfile
(failed)
$ doas /usr/local/sbin/zebra -f /etc/frr/zebra.conf
2018/04/30 22:03:11 errors: ZEBRA: if_ioctl(SIOCGIFMEDIA) failed:
Inappropriate ioctl for device
2018/04/30 22:03:11 errors: ZEBRA: if_ioctl(SIOCGIFMEDIA) failed:
Inappropriate ioctl for device
2018/04/30 22:03:11 errors: ZEBRA: if_ioctl(SIOCGIFMEDIA) failed:
Inappropriate ioctl for device
^Z[1] + Suspended doas /usr/local/sbin/zebra -f /etc/frr/zebra.co
$ ps aux | grep zeb
_frr 7354 0.0 0.1 1832 5156 p2 T 10:03PM 0:00.02
/usr/local/sbin/zebra -f /etc/frr/zebra.conf
(same goes for bgpd, didn't tried the others).
Re: NEW: x11/kde-applications/libkdcraw
On Mon, Apr 30, 2018 at 08:56:32PM +0300, Vadim Zhukov wrote:
> вс, 29 апр. 2018 г., 11:04 Rafael Sadowski <rafael@sizeofvoid.org>:
> >
> > $ cat x11/kde-applications/libkdcraw/pkg/DESCR
> > Libkdcraw is a C++ interface around LibRaw library used to decode RAW picture
> > files.
> >
> > Looks simple but it feels like a trap. libkdcraw-17.12.3 has no
> > conflicts with libkdcraw from KDE4 but we can't just commit because all
> > KDE4 applications will grep/find libkdcraw-17.12.3 instead
> > libkdcraw-4.*, which is wrong.
> >
> > Any (simple) clue?
> >
> > Ok to import?
>
> If you're sure that libkdcraw from KF5 and KDE4 lands co-exist nicely,
> and while we have users for both, just give them different names. Say,
> name new port kf5-libkdcraw, like it's done for some items under
> devel/kf5 already.
Well, imo that's not really necessary if we have the correct use of
@option values, that both can be coinstalled etc. It's ugly to have
prefixes and suffixes everywhere in pkgnames, and makes it harder for
upgrades..
> вс, 29 апр. 2018 г., 11:04 Rafael Sadowski <rafael@sizeofvoid.org>:
> >
> > $ cat x11/kde-applications/libkdcraw/pkg/DESCR
> > Libkdcraw is a C++ interface around LibRaw library used to decode RAW picture
> > files.
> >
> > Looks simple but it feels like a trap. libkdcraw-17.12.3 has no
> > conflicts with libkdcraw from KDE4 but we can't just commit because all
> > KDE4 applications will grep/find libkdcraw-17.12.3 instead
> > libkdcraw-4.*, which is wrong.
> >
> > Any (simple) clue?
> >
> > Ok to import?
>
> If you're sure that libkdcraw from KF5 and KDE4 lands co-exist nicely,
> and while we have users for both, just give them different names. Say,
> name new port kf5-libkdcraw, like it's done for some items under
> devel/kf5 already.
Well, imo that's not really necessary if we have the correct use of
@option values, that both can be coinstalled etc. It's ugly to have
prefixes and suffixes everywhere in pkgnames, and makes it harder for
upgrades..
UPDATE devel/git-cola
Diff below brings git-cola to the latest version (3.1). Overview on
fixes and additions can be found at
https://github.com/git-cola/git-cola/blob/master/share/doc/git-cola/relnotes.rst
- upstream switched to py.test to execute the test suite instead of
nosetests
- instead of patching Makefile to make it compatible with OpenBSD's
make just switch to gnake. The patch is too big, and too hard to
maintain
- drop patch which has been committed upstream
make test runs successfully, and (lightly) tested on amd64.
Comments/OKs?
Index: Makefile
===================================================================
RCS file: /cvs/ports/devel/git-cola/Makefile,v
retrieving revision 1.21
diff -u -p -r1.21 Makefile
--- Makefile 18 Feb 2018 11:35:48 -0000 1.21
+++ Makefile 30 Apr 2018 18:27:59 -0000
@@ -2,7 +2,7 @@
COMMENT = python powered git gui
-MODPY_EGG_VERSION= 3.0
+MODPY_EGG_VERSION= 3.1
DISTNAME = ${GH_PROJECT}-${MODPY_EGG_VERSION}
GH_ACCOUNT = git-cola
@@ -29,7 +29,9 @@ RUN_DEPENDS = devel/desktop-file-utils \
x11/py-qt4
TEST_DEPENDS = devel/py-mock \
- devel/py-nose
+ devel/py-test
+
+USE_GMAKE = Yes
MODPY_ADJ_FILES= share/git-cola/bin/git-xbase
Index: distinfo
===================================================================
RCS file: /cvs/ports/devel/git-cola/distinfo,v
retrieving revision 1.8
diff -u -p -r1.8 distinfo
--- distinfo 18 Feb 2018 11:35:48 -0000 1.8
+++ distinfo 30 Apr 2018 18:27:59 -0000
@@ -1,2 +1,2 @@
-SHA256 (git-cola-3.0.tar.gz) = YZWPmY1GGOCc4N1HNBGSGBjRPfg48yEC713tmEoNGlA=
-SIZE (git-cola-3.0.tar.gz) = 1218820
+SHA256 (git-cola-3.1.tar.gz) = p6CD+EaXpW7nyRDM/GgNNsXER8a1o1IuAb/53pFHT1c=
+SIZE (git-cola-3.1.tar.gz) = 1179782
Index: patches/patch-Makefile
===================================================================
RCS file: /cvs/ports/devel/git-cola/patches/patch-Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 patch-Makefile
--- patches/patch-Makefile 18 Feb 2018 11:35:48 -0000 1.3
+++ patches/patch-Makefile 30 Apr 2018 18:27:59 -0000
@@ -1,8 +1,6 @@
$OpenBSD: patch-Makefile,v 1.3 2018/02/18 11:35:48 bket Exp $
-Avoid dep on gnu make
-
-Avoid use of nosetest --with-doctest as this causes a regression test to fail
+Avoid use of pytest --with-doctest as this causes a regression test to fail
with "ImportError (Could not load inotify functions from libc)". Failure is
caused by the doctest module testing a piece of code that is linux-only. This
code is not used when running git-cola on OpenBSD.
@@ -10,39 +8,12 @@ code is not used when running git-cola o
Index: Makefile
--- Makefile.orig
+++ Makefile
-@@ -26,9 +26,6 @@ TAR = tar
- # Flags
+@@ -53,7 +53,7 @@ ifdef V
+ else
+ QUIET = --quiet
+ endif
+-PYTEST_FLAGS = $(QUIET) $(TEST_VERBOSE) --doctest-modules
++PYTEST_FLAGS = $(QUIET) $(TEST_VERBOSE)
FLAKE8_FLAGS = --max-line-length=80 --statistics --doctests --format=pylint
PYLINT_FLAGS = --rcfile=.pylintrc
--ifdef color
-- PYLINT_FLAGS += --output-format=colorized
--endif
-
- # These values can be overridden on the command-line or via config.mak
- prefix = $(HOME)
-@@ -44,7 +41,6 @@ cola_app = $(CURDIR)/$(cola_app_base)
- cola_version = $(shell $(PYTHON) bin/git-cola version --brief)
- cola_dist := $(cola_base)-$(cola_version)
-
--NOSE_FLAGS = --with-doctest
- NOSE_FLAGS += --with-id
- NOSE_FLAGS += --exclude=sphinxtogithub
- NOSE_FLAGS += --exclude=extras
-@@ -59,16 +55,7 @@ setup_args += --force
- setup_args += --install-scripts=$(bindir)
- setup_args += --record=build/MANIFEST
- setup_args += --install-lib=$(coladir)
--ifdef DESTDIR
-- setup_args += --root=$(DESTDIR)
-- export DESTDIR
--endif
--export prefix
--
--# If NO_VENDOR_LIBS is specified on the command line then pass it to setup.py
--ifdef NO_VENDOR_LIBS
-- setup_args += --no-vendor-libs
--endif
-+setup_args += --root=$(DESTDIR)
-
- PYTHON_DIRS = cola
- PYTHON_DIRS += test
+ ifdef color
Index: patches/patch-cola_app_py
===================================================================
RCS file: /cvs/ports/devel/git-cola/patches/patch-cola_app_py,v
retrieving revision 1.3
diff -u -p -r1.3 patch-cola_app_py
--- patches/patch-cola_app_py 18 Feb 2018 11:35:48 -0000 1.3
+++ patches/patch-cola_app_py 30 Apr 2018 18:27:59 -0000
@@ -5,7 +5,7 @@ Use ssh-askpass implementation from xeno
Index: cola/app.py
--- cola/app.py.orig
+++ cola/app.py
-@@ -81,7 +81,7 @@ def setup_environment():
+@@ -86,7 +86,7 @@ def setup_environment():
elif sys.platform == 'darwin':
askpass = resources.share('bin', 'ssh-askpass-darwin')
else:
Index: patches/patch-test_git_test_py
===================================================================
RCS file: patches/patch-test_git_test_py
diff -N patches/patch-test_git_test_py
--- patches/patch-test_git_test_py 18 Feb 2018 11:35:48 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,31 +0,0 @@
-$OpenBSD: patch-test_git_test_py,v 1.1 2018/02/18 11:35:48 bket Exp $
-
-test_tag and test_show assume that source has been fetched using git, and that
-full history is availabe. These tests fail as we are using a release tarball.
-
-Adapted from
-https://github.com/git-cola/git-cola/commit/4c9d36ae021262a6559a1ae240c31e768bca0b37
-
-Index: test/git_test.py
---- test/git_test.py.orig
-+++ test/git_test.py
-@@ -219,19 +219,6 @@ class GitCommandTest(unittest.TestCase):
- version = self.git.version()[STDOUT]
- self.failUnless(version.startswith('git version'))
-
-- def test_tag(self):
-- """Test running 'git tag'"""
-- tags = self.git.tag()[STDOUT].splitlines()
-- if os.getenv('GIT_COLA_NO_HISTORY', False):
-- return
-- self.failUnless('v1.0.0' in tags)
--
-- def test_show(self):
-- """Test running 'git show'"""
-- oid = 'HEAD'
-- content = self.git.show(oid)[STDOUT]
-- self.failUnless(content.startswith('commit '))
--
- def test_stdout(self):
- """Test overflowing the stdout buffer"""
- # Write to stdout only
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/devel/git-cola/pkg/PLIST,v
retrieving revision 1.10
diff -u -p -r1.10 PLIST
--- pkg/PLIST 18 Feb 2018 11:35:48 -0000 1.10
+++ pkg/PLIST 30 Apr 2018 18:27:59 -0000
@@ -51,6 +51,7 @@ share/git-cola/icons/dark/folder.svg
share/git-cola/icons/dark/gear.svg
share/git-cola/icons/dark/git-branch.svg
share/git-cola/icons/dark/git-cola.svg
+share/git-cola/icons/dark/git-commit.svg
share/git-cola/icons/dark/git-compare.svg
share/git-cola/icons/dark/git-merge.svg
share/git-cola/icons/dark/link-external.svg
@@ -98,6 +99,7 @@ share/git-cola/icons/folder.svg
share/git-cola/icons/gear.svg
share/git-cola/icons/git-branch.svg
share/git-cola/icons/git-cola.svg
+share/git-cola/icons/git-commit.svg
share/git-cola/icons/git-compare.svg
share/git-cola/icons/git-merge.svg
share/git-cola/icons/link-external.svg
@@ -141,6 +143,8 @@ share/git-cola/lib/cola/compat.py
share/git-cola/lib/cola/compat.pyc
share/git-cola/lib/cola/core.py
share/git-cola/lib/cola/core.pyc
+share/git-cola/lib/cola/dag.py
+share/git-cola/lib/cola/dag.pyc
share/git-cola/lib/cola/decorators.py
share/git-cola/lib/cola/decorators.pyc
share/git-cola/lib/cola/diffparse.py
@@ -221,6 +225,8 @@ share/git-cola/lib/cola/widgets/browse.p
share/git-cola/lib/cola/widgets/browse.pyc
share/git-cola/lib/cola/widgets/cfgactions.py
share/git-cola/lib/cola/widgets/cfgactions.pyc
+share/git-cola/lib/cola/widgets/clone.py
+share/git-cola/lib/cola/widgets/clone.pyc
share/git-cola/lib/cola/widgets/commitmsg.py
share/git-cola/lib/cola/widgets/commitmsg.pyc
share/git-cola/lib/cola/widgets/common.py
@@ -253,6 +259,8 @@ share/git-cola/lib/cola/widgets/grep.py
share/git-cola/lib/cola/widgets/grep.pyc
share/git-cola/lib/cola/widgets/highlighter.py
share/git-cola/lib/cola/widgets/highlighter.pyc
+share/git-cola/lib/cola/widgets/imageview.py
+share/git-cola/lib/cola/widgets/imageview.pyc
share/git-cola/lib/cola/widgets/log.py
share/git-cola/lib/cola/widgets/log.pyc
share/git-cola/lib/cola/widgets/main.py
fixes and additions can be found at
https://github.com/git-cola/git-cola/blob/master/share/doc/git-cola/relnotes.rst
- upstream switched to py.test to execute the test suite instead of
nosetests
- instead of patching Makefile to make it compatible with OpenBSD's
make just switch to gnake. The patch is too big, and too hard to
maintain
- drop patch which has been committed upstream
make test runs successfully, and (lightly) tested on amd64.
Comments/OKs?
Index: Makefile
===================================================================
RCS file: /cvs/ports/devel/git-cola/Makefile,v
retrieving revision 1.21
diff -u -p -r1.21 Makefile
--- Makefile 18 Feb 2018 11:35:48 -0000 1.21
+++ Makefile 30 Apr 2018 18:27:59 -0000
@@ -2,7 +2,7 @@
COMMENT = python powered git gui
-MODPY_EGG_VERSION= 3.0
+MODPY_EGG_VERSION= 3.1
DISTNAME = ${GH_PROJECT}-${MODPY_EGG_VERSION}
GH_ACCOUNT = git-cola
@@ -29,7 +29,9 @@ RUN_DEPENDS = devel/desktop-file-utils \
x11/py-qt4
TEST_DEPENDS = devel/py-mock \
- devel/py-nose
+ devel/py-test
+
+USE_GMAKE = Yes
MODPY_ADJ_FILES= share/git-cola/bin/git-xbase
Index: distinfo
===================================================================
RCS file: /cvs/ports/devel/git-cola/distinfo,v
retrieving revision 1.8
diff -u -p -r1.8 distinfo
--- distinfo 18 Feb 2018 11:35:48 -0000 1.8
+++ distinfo 30 Apr 2018 18:27:59 -0000
@@ -1,2 +1,2 @@
-SHA256 (git-cola-3.0.tar.gz) = YZWPmY1GGOCc4N1HNBGSGBjRPfg48yEC713tmEoNGlA=
-SIZE (git-cola-3.0.tar.gz) = 1218820
+SHA256 (git-cola-3.1.tar.gz) = p6CD+EaXpW7nyRDM/GgNNsXER8a1o1IuAb/53pFHT1c=
+SIZE (git-cola-3.1.tar.gz) = 1179782
Index: patches/patch-Makefile
===================================================================
RCS file: /cvs/ports/devel/git-cola/patches/patch-Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 patch-Makefile
--- patches/patch-Makefile 18 Feb 2018 11:35:48 -0000 1.3
+++ patches/patch-Makefile 30 Apr 2018 18:27:59 -0000
@@ -1,8 +1,6 @@
$OpenBSD: patch-Makefile,v 1.3 2018/02/18 11:35:48 bket Exp $
-Avoid dep on gnu make
-
-Avoid use of nosetest --with-doctest as this causes a regression test to fail
+Avoid use of pytest --with-doctest as this causes a regression test to fail
with "ImportError (Could not load inotify functions from libc)". Failure is
caused by the doctest module testing a piece of code that is linux-only. This
code is not used when running git-cola on OpenBSD.
@@ -10,39 +8,12 @@ code is not used when running git-cola o
Index: Makefile
--- Makefile.orig
+++ Makefile
-@@ -26,9 +26,6 @@ TAR = tar
- # Flags
+@@ -53,7 +53,7 @@ ifdef V
+ else
+ QUIET = --quiet
+ endif
+-PYTEST_FLAGS = $(QUIET) $(TEST_VERBOSE) --doctest-modules
++PYTEST_FLAGS = $(QUIET) $(TEST_VERBOSE)
FLAKE8_FLAGS = --max-line-length=80 --statistics --doctests --format=pylint
PYLINT_FLAGS = --rcfile=.pylintrc
--ifdef color
-- PYLINT_FLAGS += --output-format=colorized
--endif
-
- # These values can be overridden on the command-line or via config.mak
- prefix = $(HOME)
-@@ -44,7 +41,6 @@ cola_app = $(CURDIR)/$(cola_app_base)
- cola_version = $(shell $(PYTHON) bin/git-cola version --brief)
- cola_dist := $(cola_base)-$(cola_version)
-
--NOSE_FLAGS = --with-doctest
- NOSE_FLAGS += --with-id
- NOSE_FLAGS += --exclude=sphinxtogithub
- NOSE_FLAGS += --exclude=extras
-@@ -59,16 +55,7 @@ setup_args += --force
- setup_args += --install-scripts=$(bindir)
- setup_args += --record=build/MANIFEST
- setup_args += --install-lib=$(coladir)
--ifdef DESTDIR
-- setup_args += --root=$(DESTDIR)
-- export DESTDIR
--endif
--export prefix
--
--# If NO_VENDOR_LIBS is specified on the command line then pass it to setup.py
--ifdef NO_VENDOR_LIBS
-- setup_args += --no-vendor-libs
--endif
-+setup_args += --root=$(DESTDIR)
-
- PYTHON_DIRS = cola
- PYTHON_DIRS += test
+ ifdef color
Index: patches/patch-cola_app_py
===================================================================
RCS file: /cvs/ports/devel/git-cola/patches/patch-cola_app_py,v
retrieving revision 1.3
diff -u -p -r1.3 patch-cola_app_py
--- patches/patch-cola_app_py 18 Feb 2018 11:35:48 -0000 1.3
+++ patches/patch-cola_app_py 30 Apr 2018 18:27:59 -0000
@@ -5,7 +5,7 @@ Use ssh-askpass implementation from xeno
Index: cola/app.py
--- cola/app.py.orig
+++ cola/app.py
-@@ -81,7 +81,7 @@ def setup_environment():
+@@ -86,7 +86,7 @@ def setup_environment():
elif sys.platform == 'darwin':
askpass = resources.share('bin', 'ssh-askpass-darwin')
else:
Index: patches/patch-test_git_test_py
===================================================================
RCS file: patches/patch-test_git_test_py
diff -N patches/patch-test_git_test_py
--- patches/patch-test_git_test_py 18 Feb 2018 11:35:48 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,31 +0,0 @@
-$OpenBSD: patch-test_git_test_py,v 1.1 2018/02/18 11:35:48 bket Exp $
-
-test_tag and test_show assume that source has been fetched using git, and that
-full history is availabe. These tests fail as we are using a release tarball.
-
-Adapted from
-https://github.com/git-cola/git-cola/commit/4c9d36ae021262a6559a1ae240c31e768bca0b37
-
-Index: test/git_test.py
---- test/git_test.py.orig
-+++ test/git_test.py
-@@ -219,19 +219,6 @@ class GitCommandTest(unittest.TestCase):
- version = self.git.version()[STDOUT]
- self.failUnless(version.startswith('git version'))
-
-- def test_tag(self):
-- """Test running 'git tag'"""
-- tags = self.git.tag()[STDOUT].splitlines()
-- if os.getenv('GIT_COLA_NO_HISTORY', False):
-- return
-- self.failUnless('v1.0.0' in tags)
--
-- def test_show(self):
-- """Test running 'git show'"""
-- oid = 'HEAD'
-- content = self.git.show(oid)[STDOUT]
-- self.failUnless(content.startswith('commit '))
--
- def test_stdout(self):
- """Test overflowing the stdout buffer"""
- # Write to stdout only
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/devel/git-cola/pkg/PLIST,v
retrieving revision 1.10
diff -u -p -r1.10 PLIST
--- pkg/PLIST 18 Feb 2018 11:35:48 -0000 1.10
+++ pkg/PLIST 30 Apr 2018 18:27:59 -0000
@@ -51,6 +51,7 @@ share/git-cola/icons/dark/folder.svg
share/git-cola/icons/dark/gear.svg
share/git-cola/icons/dark/git-branch.svg
share/git-cola/icons/dark/git-cola.svg
+share/git-cola/icons/dark/git-commit.svg
share/git-cola/icons/dark/git-compare.svg
share/git-cola/icons/dark/git-merge.svg
share/git-cola/icons/dark/link-external.svg
@@ -98,6 +99,7 @@ share/git-cola/icons/folder.svg
share/git-cola/icons/gear.svg
share/git-cola/icons/git-branch.svg
share/git-cola/icons/git-cola.svg
+share/git-cola/icons/git-commit.svg
share/git-cola/icons/git-compare.svg
share/git-cola/icons/git-merge.svg
share/git-cola/icons/link-external.svg
@@ -141,6 +143,8 @@ share/git-cola/lib/cola/compat.py
share/git-cola/lib/cola/compat.pyc
share/git-cola/lib/cola/core.py
share/git-cola/lib/cola/core.pyc
+share/git-cola/lib/cola/dag.py
+share/git-cola/lib/cola/dag.pyc
share/git-cola/lib/cola/decorators.py
share/git-cola/lib/cola/decorators.pyc
share/git-cola/lib/cola/diffparse.py
@@ -221,6 +225,8 @@ share/git-cola/lib/cola/widgets/browse.p
share/git-cola/lib/cola/widgets/browse.pyc
share/git-cola/lib/cola/widgets/cfgactions.py
share/git-cola/lib/cola/widgets/cfgactions.pyc
+share/git-cola/lib/cola/widgets/clone.py
+share/git-cola/lib/cola/widgets/clone.pyc
share/git-cola/lib/cola/widgets/commitmsg.py
share/git-cola/lib/cola/widgets/commitmsg.pyc
share/git-cola/lib/cola/widgets/common.py
@@ -253,6 +259,8 @@ share/git-cola/lib/cola/widgets/grep.py
share/git-cola/lib/cola/widgets/grep.pyc
share/git-cola/lib/cola/widgets/highlighter.py
share/git-cola/lib/cola/widgets/highlighter.pyc
+share/git-cola/lib/cola/widgets/imageview.py
+share/git-cola/lib/cola/widgets/imageview.pyc
share/git-cola/lib/cola/widgets/log.py
share/git-cola/lib/cola/widgets/log.pyc
share/git-cola/lib/cola/widgets/main.py
Subscribe to:
Posts (Atom)