Re: 5.9 discs in the wild. Europe/Switzerland

[Bruno Flueckiger]

On 21.04.2016 05:45, noah pugsley wrote:

Thank you all for the best little correctness focused general purpose
operating system in the known universe.

With all the nonsense created every day, a little sanity now and then, 
is

cherished by the wisest men.


http://noahpugsley.net/59.jpg


Cheers,

-noah

P.S. garbage.fm you both better be at bsdcan. I want to complain about
everything !OpenBSD. And I think you do too.


In Switzerland the package arrived today:

https://www.bsdhowto.ch/?p=102

Thanks to everybody involved.

Cheers,
Bruno

Re: NFS daemon is very slow in server-to-client direction in TCP mode

[Predrag Punosevac]

Matthew Dillon  wrote:

> NFS read performance is primarily client-driven.  usually setting the
> read-ahead (for example, mount_nfs -a 4) is the biggest performance driver
> for reads.  OpenBSD defaults to -a 1 which is basically no read-ahead.  I
> suggest -a 4 at a minimum.  Also make sure the read block size is at least
> 8192 (which is the default).  Bumping it higher should theoretically work
> but see next paragraph.  32768 is reasonable for TCP.  65536 is a bit
> excessive (if it fails completely then the TCP buffers are not being sized
> properly and the NFS protocol implementation is probably deadlocking due to
> the TCP buffer filling up, or due to insufficient TCP buffer space).
> 
> In terms of streaming reads over TCP, it should be possible to stream at
> the full network bandwidth (~90-100 MBytes/sec) as long as the
> implementation creates the TCP connection properly.  The TCP buffers have
> to be made relatively large (I would suggest at least 1MB rx and tx
> buffers), the TCP connection must also use window scaling and must also be
> sure to use TCP_NODELAY.  Otherwise performance will be horrible.   You
> might need to enlist one of the devs to check these parameters, there are
> often quite a few knobs to turn to tune it properly and defaults were set
> very low historically.
> 
> NFS write performance is harder.  With a NFSv3 mount (make sure the mount
> is NFSv3 and not v2) getting good performance depends almost entirely on
> the client-side implementation doing a proper streaming two-phase commit.
> A larger buffer size helps too (32768 is reasonable for TCP).  So I can't
> make any suggestions there.  A larger TCP buffer may help though (again, at
> least a ~1MB TCP buffer is recommended).  The DFly server side won't be a
> bottleneck for either reads or writes.
> caching.  A freshly booted server will have to read the file from storage
> which with a hard drive might have limited bandwidth (e.g. ~70MB/sec).  On
> a remount (umount/mount) to clear the client-side cache, the second run the
> file will be fully cached and the read test will be testing purely network
> bandwidth (e.g. ~90-100 MB/sec).  If no client-side remount occurs then on
> a second or later run some of the data may already be on the client and
> result in no network transaction at all (giving very high perceived but
> test-incorrect results).
> 
> With read-ahead and proper TCP settings the entire data path should be able
> to stream at nearly full bandwidth uncached (for whatever the bw limiter
> is, network or disk).
> 
> -Matt

Matt,

Thank you so much for taking the time to write this long e-mail and
educate me about NFS. I played little bit after sending original message
on the freshly upgraded v4.4.3.1 and this is what I got.

First of all a reality check with my 1Gigabit network. The fastest I
could push TCP packets from my OpenBSD 5.9 amd64 desktop to DragonFly
file server was 600 Mbits/sec. Switching to UDP I can get over 730
Mbits/sec. In practical terms that mean that my network is saturated if
I can push 75MB/s over TCP connection or about 90MB/s if I push using
UDP.

Following your advise I did 

mount_nfs -a 4 -o noatime dfly:/data/nfs/hammer

Over UDP mount I am getting write speed over NFS 29MB/s according to my
trivial dd tests. However I am able to read 71MB/s. 

Best,
Predrag


> 
> 
> On Thu, Apr 21, 2016 at 6:11 PM, Predrag Punosevac 
> wrote:
> 
> > This is a very interested thread. I just played little bit with dd on my
> > desktop machine running OpenBSD 5.9 amd64 NFS-client. NFS server runs on
> > DragonFly BSD 4.4.2. No optimization of any kind has been done. My home
> > network is 1 Gigabit. I will play over the weekend with various block
> > sizes and try to use iozone to get something more interesting.
> >
> > UDP mount
> >
> > write: 17.014003 MB/s
> > read: 22.397014 MB/s
> >
> > TCP mount:
> >
> > write: 9.338817 MB/s
> > read: 20.47062 MB/s
> >
> > Best,
> > Predrag
> >
> > P.S. Yes under the NFS DF is using HAMMER so I am able to get history,
> > snapshot, and all that nifty stuff.

Re: NFS daemon is very slow in server-to-client direction in TCP mode

[Matthew Dillon]

NFS read performance is primarily client-driven.  usually setting the
read-ahead (for example, mount_nfs -a 4) is the biggest performance driver
for reads.  OpenBSD defaults to -a 1 which is basically no read-ahead.  I
suggest -a 4 at a minimum.  Also make sure the read block size is at least
8192 (which is the default).  Bumping it higher should theoretically work
but see next paragraph.  32768 is reasonable for TCP.  65536 is a bit
excessive (if it fails completely then the TCP buffers are not being sized
properly and the NFS protocol implementation is probably deadlocking due to
the TCP buffer filling up, or due to insufficient TCP buffer space).

In terms of streaming reads over TCP, it should be possible to stream at
the full network bandwidth (~90-100 MBytes/sec) as long as the
implementation creates the TCP connection properly.  The TCP buffers have
to be made relatively large (I would suggest at least 1MB rx and tx
buffers), the TCP connection must also use window scaling and must also be
sure to use TCP_NODELAY.  Otherwise performance will be horrible.   You
might need to enlist one of the devs to check these parameters, there are
often quite a few knobs to turn to tune it properly and defaults were set
very low historically.

NFS write performance is harder.  With a NFSv3 mount (make sure the mount
is NFSv3 and not v2) getting good performance depends almost entirely on
the client-side implementation doing a proper streaming two-phase commit.
A larger buffer size helps too (32768 is reasonable for TCP).  So I can't
make any suggestions there.  A larger TCP buffer may help though (again, at
least a ~1MB TCP buffer is recommended).  The DFly server side won't be a
bottleneck for either reads or writes.
caching.  A freshly booted server will have to read the file from storage
which with a hard drive might have limited bandwidth (e.g. ~70MB/sec).  On
a remount (umount/mount) to clear the client-side cache, the second run the
file will be fully cached and the read test will be testing purely network
bandwidth (e.g. ~90-100 MB/sec).  If no client-side remount occurs then on
a second or later run some of the data may already be on the client and
result in no network transaction at all (giving very high perceived but
test-incorrect results).

With read-ahead and proper TCP settings the entire data path should be able
to stream at nearly full bandwidth uncached (for whatever the bw limiter
is, network or disk).

-Matt


On Thu, Apr 21, 2016 at 6:11 PM, Predrag Punosevac 
wrote:

> This is a very interested thread. I just played little bit with dd on my
> desktop machine running OpenBSD 5.9 amd64 NFS-client. NFS server runs on
> DragonFly BSD 4.4.2. No optimization of any kind has been done. My home
> network is 1 Gigabit. I will play over the weekend with various block
> sizes and try to use iozone to get something more interesting.
>
> UDP mount
>
> write: 17.014003 MB/s
> read: 22.397014 MB/s
>
> TCP mount:
>
> write: 9.338817 MB/s
> read: 20.47062 MB/s
>
> Best,
> Predrag
>
> P.S. Yes under the NFS DF is using HAMMER so I am able to get history,
> snapshot, and all that nifty stuff.

upgrade OpenBSD 5.8 to 5.9 daemon: unknown class

[Ultramedia Libertad]

hello

I am upgrade OpenBSD 5.8 to 5.9 and after to reboot

i have follow errors in remote console :
















*init: daemon: unknown class (failed)syslogdsu: daemon: unknown class
(failed)pflogdsu: daemon: unknown class (failed)ntpdsu: daemon: unknown
class (failed)starting RPC daemons:.savecore: no core dumpcheckin quotas:
done.clearing /tmpkern.securelevel: 0 -> 1creating runtime link editor
directory cache.preserving editor files.startings networks daemons: sshdsu:
daemon: unknown class (failed)smtpdsu: daemon: unknown class
(failed)sndiodsu: daemon: unknown class (failed).Thu apr 21 20:06:24
CDI 2016*


y more

please help me attach image

--
editor de sueños

[demime 1.01d removed an attachment of type image/png which had a name of 
Screenshot_2016-04-21_21-14-18.png]

Re: NFS daemon is very slow in server-to-client direction in TCP mode

[Predrag Punosevac]

This is a very interested thread. I just played little bit with dd on my
desktop machine running OpenBSD 5.9 amd64 NFS-client. NFS server runs on
DragonFly BSD 4.4.2. No optimization of any kind has been done. My home
network is 1 Gigabit. I will play over the weekend with various block
sizes and try to use iozone to get something more interesting. 

UDP mount

write: 17.014003 MB/s 
read: 22.397014 MB/s

TCP mount:

write: 9.338817 MB/s
read: 20.47062 MB/s

Best,
Predrag

P.S. Yes under the NFS DF is using HAMMER so I am able to get history,
snapshot, and all that nifty stuff. 

Re: Quick APU2 review

[Chris Cappuccio]

Stuart Henderson [s...@spacehopper.org] wrote:
> >>> Heat: The APUs have an innovative design where the CPU heat sink
> >>> is coupled to the case.  Since this is typically assembled by the
> >>> customer, a lot of attention is drawn to it and people obsess over
> >>> the CPU temperature.  It's a nonissue.
> 
> I've got hold of an APU2C2 now. Agreed - but most of the temperature
> comments where about APU1 where this was not the case, especially with
> the version of OpenBSD that was around when the hardware first became
> available they really were uncomfortably warm. With the 2C2 I'm now
> happy to use it pretty much anywhere I'd use an ALIX.

The APU2 case is slightly cooler. 

My experience is that the heatsink pad failed on some units, it became almost
brittle.

The affected units would crash every few days...

I took apart some 20 initially assembled units with the heatsink pads, and
found some pads brittle, others were perfect.

I just replaced the heatsink pads on all of my APUs (probably 50 by now) with
heatsink paste and they all work perfectly, no crashing ever. Some serve DNS
and DHCP to networks with tens of thousands of devices, some act as redundant
routers, some just collect information via GPIO pins.

The units with low temps and heatsink pads got hotter with the paste, but the
units with bad heatsink pads got cooler with the paste.

It may seem like obsession, but I just want them to be stable :)

The APU1 is fine even in a high temp environment as long as the heatsink
material is working properly.

(PC Engines does not endorse replacing the heatsink pad with paste.)

Chris

Re: Quick APU2 review

[Stuart Henderson]

>>> Heat: The APUs have an innovative design where the CPU heat sink
>>> is coupled to the case.  Since this is typically assembled by the
>>> customer, a lot of attention is drawn to it and people obsess over
>>> the CPU temperature.  It's a nonissue.

I've got hold of an APU2C2 now. Agreed - but most of the temperature
comments where about APU1 where this was not the case, especially with
the version of OpenBSD that was around when the hardware first became
available they really were uncomfortably warm. With the 2C2 I'm now
happy to use it pretty much anywhere I'd use an ALIX.

Re: Unable to boot on APU2C4

[Christer Solskogen]

On Thu, Apr 21, 2016 at 9:23 PM, Kapfhammer, Stefan  wrote:
> You have to type at boot prompt:
> stty com0 115200
> set tty com0
> boot /bsd.rd
>

Aha, much better.
Thanks!

Re: Unable to boot on APU2C4

[Kapfhammer, Stefan]

You have to type at boot prompt:
stty com0 115200
set tty com0
boot /bsd.rd

Using a nullmodem cable with crossed pins
would also be recommended :)

Regards,
Stefan
  Originalnachricht
Von: Christer Solskogen
Gesendet: Donnerstag, 21. April 2016 21:12
An: misc
Betreff: Unable to boot on APU2C4


Hi!

I've gotten my finger on a APU2C4, but I'm not able to install nor
even start OpenBSD on it. I've tried both USB and iPXE and all I ever
get is this:

Booting from Hard Disk...
Booting from :7c00
Using drive 0, partition 3.
Loading.
probing: pc0 com0 com1 mem[638K 3582M 496M a20=on]
disk: hd0+
>> OpenBSD/amd64 BOOT 3.30
boot>
cannot open hd0a:/etc/random.seed: No such file or directory
booting hd0a:/bsd: 3339844+1409808+2413568+0+585728=0x766238
entry point at 0x1001000 [7205c766, 3404, 24448b12, 8680a304]

Then it stops for a couple of seconds before it reboots like this:
PCEngines apu2
coreboot build 20160311
...

I do not have a mSATA drive in it, yet. But that should not have
anything to do with it, should it?

--
chs

Unable to boot on APU2C4

[Christer Solskogen]

Hi!

I've gotten my finger on a APU2C4, but I'm not able to install nor
even start OpenBSD on it. I've tried both USB and iPXE and all I ever
get is this:

Booting from Hard Disk...
Booting from :7c00
Using drive 0, partition 3.
Loading.
probing: pc0 com0 com1 mem[638K 3582M 496M a20=on]
disk: hd0+
>> OpenBSD/amd64 BOOT 3.30
boot>
cannot open hd0a:/etc/random.seed: No such file or directory
booting hd0a:/bsd: 3339844+1409808+2413568+0+585728=0x766238
entry point at 0x1001000 [7205c766, 3404, 24448b12, 8680a304]

Then it stops for a couple of seconds before it reboots like this:
PCEngines apu2
coreboot build 20160311
...

I do not have a mSATA drive in it, yet. But that should not have
anything to do with it, should it?

-- 
chs

Re: Unable to boot on APU2C4

[Mike Larkin]

On Thu, Apr 21, 2016 at 09:05:17PM +0200, Christer Solskogen wrote:
> Hi!
> 
> I've gotten my finger on a APU2C4, but I'm not able to install nor
> even start OpenBSD on it. I've tried both USB and iPXE and all I ever
> get is this:
> 
> Booting from Hard Disk...
> Booting from :7c00
> Using drive 0, partition 3.
> Loading.
> probing: pc0 com0 com1 mem[638K 3582M 496M a20=on]
> disk: hd0+
> >> OpenBSD/amd64 BOOT 3.30
> boot>
> cannot open hd0a:/etc/random.seed: No such file or directory
> booting hd0a:/bsd: 3339844+1409808+2413568+0+585728=0x766238
> entry point at 0x1001000 [7205c766, 3404, 24448b12, 8680a304]
> 
> Then it stops for a couple of seconds before it reboots like this:
> PCEngines apu2
> coreboot build 20160311
> ...
> 
> I do not have a mSATA drive in it, yet. But that should not have
> anything to do with it, should it?
> 
> -- 
> chs
> 

You're booting /bsd. Were you able to do an install before this using /bsd.rd?

In other words, how did you get to this point?

And if you were able to boot /bsd.rd, please provide a dmesg.

-ml

Re: 5.9 discs in the wild. Europe/Germany

[Norman Golisz]

On Thu Apr 21 2016 15:27, Stefan Wollny wrote:
> Arrived today in Germany :-)
> 
> Thx to everybody who made this possible.

Absolutely. Received mine yesterday (also Germany).

Thank you!

Re: pureftpd virtual users TLS

[Teno Deuter]

Thank you for your valuable help.

As this installation runs in a VirtualBox env and serves testing
purposes, sources aren't retrieved yet. I think I have to get all the
sources first and then apply that change?

On Sat, Apr 9, 2016 at 2:26 AM, Edgar Pettijohn  wrote:
> On 04/07/16 16:06, Teno Deuter wrote:
>>
>> Hi,
>>
>> installed the chrooted version of pureftpd on a 5.9 AMD64 setting and face
>> following issues:
>>
>> 1.
>> TLS with system users works fine but not for the virtual ones! Only plain
>> ftp!
>>
>> 2.
>> seems that the service doesn't always refer to the 'pure-ftpd.conf'! To be
>> more specific.I did define the path of 'pureftpd.pdb' in the configuration
>> file but if I don't use the '-lpuredb' switch in the daemon flags doesn't
>> find it. Also, uncommenting :
>>
>> AltLog w3c:/var/log/pureftpd.log
>>
>> doesn't have any effect either. That file never gets created!
>>
>> Thank you for your support.
>>
> I think its because support for virtual users isn't built in the port.  This
> patch should do what you need.
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/net/pure-ftpd/Makefile,v
> retrieving revision 1.71
> diff -u -p -u -r1.71 Makefile
> --- Makefile14 Oct 2015 10:01:55 -1.71
> +++ Makefile9 Apr 2016 00:17:16 -
> @@ -28,7 +28,8 @@ CONFIGURE_ARGS+= --disable-pie \
>   --with-everything \
>   --with-paranoidmsg \
>   --with-rfc2640 \
> - --with-tls
> + --with-tls \
> + --with-puredb
>
>  MODULES=converters/libiconv

Re: 5.9 discs in the wild. Europe/Germany

[Stefan Wollny]

Arrived today in Germany :-)

Thx to everybody who made this possible.

Best,
STEFAN


Am 04/21/16 um 05:45 schrieb noah pugsley:
> Thank you all for the best little correctness focused general purpose
> operating system in the known universe.
> 
> With all the nonsense created every day, a little sanity now and then, is
> cherished by the wisest men.
> 
> 
> http://noahpugsley.net/59.jpg
> 
> 
> Cheers,
> 
> -noah
> 
> P.S. garbage.fm you both better be at bsdcan. I want to complain about
> everything !OpenBSD. And I think you do too.

Re: VLAN in 5.9 - NAT problem

[Radek]

SOLVED!
The problem was in /etc/hostname.vlan* (not in /etc/pf.conf) 
I removed VLAN's MAC addresses and NAT started to work. 

BEFORE (5.4):
#cat /etc/hostname.trunk0 
trunkproto lacp trunkport em0 trunkport em1 lladdr 00:01:02:03:11:11
up
#cat /etc/hostname.vlan*
inet 10.0.30.254 255.255.255.0 NONE vlan 300 vlandev trunk0 lladdr 
00:01:02:03:03:00 description "Interface VLAN-SERV"
inet 10.0.8.254 255.255.255.0 NONE vlan 308 vlandev trunk0 lladdr 
00:01:02:03:03:08  description "Interface VLAN-308I"
inet 10.0.9.254 255.255.255.0 NONE vlan 309 vlandev trunk0 lladdr 
00:01:02:03:03:09 description "Interface VLAN-309I"
inet 10.0.10.254 255.255.255.0 NONE vlan 310 vlandev trunk0 lladdr 
00:01:02:03:03:10 description "Interface VLAN-310I"
inet 10.0.11.254 255.255.255.0 NONE vlan 311 vlandev trunk0 lladdr 
00:01:02:03:03:11 description "Interface VLAN-311I"
inet 10.0.40.254 255.255.255.0 NONE vlan 400 vlandev trunk0 lladdr 
00:01:02:03:04:00 description "Interface VLAN-PRAC"

AFTER (5.9):
#cat /etc/hostname.trunk0 
trunkproto lacp trunkport em0 trunkport em1 lladdr 00:01:02:03:11:11
up
#cat /etc/hostname.vlan*
inet 10.0.30.254 255.255.255.0 NONE vlan 300 vlandev trunk0 description 
"Interface VLAN-SERV"
inet 10.0.8.254 255.255.255.0 NONE vlan 308 vlandev trunk0 description 
"Interface VLAN-308I"
inet 10.0.9.254 255.255.255.0 NONE vlan 309 vlandev trunk0 description 
"Interface VLAN-309I"
inet 10.0.10.254 255.255.255.0 NONE vlan 310 vlandev trunk0 description 
"Interface VLAN-310I"
inet 10.0.11.254 255.255.255.0 NONE vlan 311 vlandev trunk0 description 
"Interface VLAN-311I"
inet 10.0.40.254 255.255.255.0 NONE vlan 400 vlandev trunk0 description 
"Interface VLAN-PRAC"

All vlan* interfaces have trunk0's MAC now (all the same). Hope it is not a 
problem.


On Tue, 19 Apr 2016 15:27:21 +0200
Radek  wrote:

> Thanks for all your replies.
> 
> > I think dhcpd.interfaces is a relic?  For the longest time I've simply
> > been specifying my interfaces in dhcpd_flags.
> Good idea, but deleting /etc/dhcpd.interfaces does not make any change.
> 
> > Since you did not submit a full pf.conf, I have no chance of knowing if you 
> > do a later pass that changes the NAT state.
> This is my full /etc/pf.conf now:
> pass out on rl0 inet from vlan309:network to any nat-to rl0
> 
> I have noticed that my NAT is working if there is running #tcpdump -i vlan309
> NAT works with:
> pass out on rl0 inet from vlan309:network to any nat-to rl0
> or with:
> match out on rl0 inet from vlan309:network nat-to rl0
> pass out on rl0
> 
> If I terminate #tcpdump -i vlan309, NAT stops working too.
> 
> Any idea?
> 
> 
> On Mon, 18 Apr 2016 16:42:00 -0400
> "Brian S. Vangsgaard"  wrote:
> 
> > pass out on rl0 inet from vlan309:network to any nat-to rl0
> > 
> > match out on rl0 inet from vlan:309:network nat-to rl0
> > pass out on rl0
> > 
> > Since you did not submit a full pf.conf, I have no chance of knowing if you 
> > do a later pass that changes the NAT state.
> > 
> > You could use tags for more fine-grained control.
> > 
> > 
> > #cat /etc/rc.conf.local
> > dhcpd_flags="vlan300 vlan308 vlan309 vlan310 vlan311 vlan400"
> > pf_rules=/etc/pf.conf
> > 
> > #cat /etc/dhcpd.interfaces
> > vlan300
> > vlan308
> > vlan309
> > vlan310
> > vlan311
> > vlan400
> > 
> > #cat /etc/hostname.em0
> > up
> > 
> > #cat /etc/hostname.em1
> > up
> > 
> > #cat /etc/hostname.trunk0
> > trunkproto lacp trunkport em0 trunkport em1 lladdr 00:01:02:03:11:11
> > up
> > 
> > #cat /etc/hostname.vlan300
> > inet 10.0.30.254 255.255.255.0 NONE vlan 300 vlandev trunk0 lladdr 
> > 00:01:02:03:03:00 description "Interface VLAN-SERV"
> > 
> > #cat /etc/hostname.vlan308
> > inet 10.0.8.254 255.255.255.0 NONE vlan 308 vlandev trunk0 lladdr 
> > 00:01:02:03:03:08 description "Interface VLAN-308I"
> > 
> > #cat /etc/hostname.vlan309
> > inet 10.0.9.254 255.255.255.0 NONE vlan 309 vlandev trunk0 lladdr 
> > 00:01:02:03:03:09 description "Interface VLAN-309I"
> > [...]
> > 
> > 
> > 
> > @2. Then I removed trunk0. DHCPserver works, clients get IP. NAT does not 
> > work still.
> > 
> > #cat /etc/pf.conf [changed to very short and simple for tests]
> > pass out on rl0 inet from vlan309:network to any nat-to rl0
> > 
> > #cat /etc/rc.conf.local
> > dhcpd_flags="vlan300 vlan308 vlan309 vlan310 vlan311 vlan400"
> > pf_rules=/etc/pf.conf
> > 
> > #cat /etc/dhcpd.interfaces
> > vlan300
> > vlan308
> > vlan309
> > vlan310
> > vlan311
> > vlan400
> > 
> > #cat /etc/hostname.em0
> > up
> > 
> > #cat /etc/hostname.vlan300
> > inet 10.0.30.254 255.255.255.0 NONE vlan 300 vlandev em0 lladdr 
> > 00:01:02:03:03:00 description "Interface VLAN-SERV"
> > 
> > #cat /etc/hostname.vlan308
> > inet 10.0.8.254 255.255.255.0 NONE vlan 308 vlandev em0 lladdr 
> > 00:01:02:03:03:08 description "Interface VLAN-308I"
> > 
> > #cat /etc/hostname.vlan309
> > inet 10.0.9.254 255.255.255.0 NONE vlan 309 vlandev em0 lladdr 
> > 00:01:02:03:03:09 description "Interface 

Re: NFS daemon is very slow in server-to-client direction in TCP mode

[Steven Surdock]

I seem to be experiencing this as well, but I have no access to the client
side as it is a wireless camera.  Is there anything that can be done on the
server side?

-Steve S.

Re: 5.9 discs in the wild. North America

[Edgar Pettijohn]

Still waiting for mine in the Houston area :(

Sent from my iPhone

> On Apr 20, 2016, at 10:45 PM, noah pugsley  wrote:
> 
> Thank you all for the best little correctness focused general purpose
> operating system in the known universe.
> 
> With all the nonsense created every day, a little sanity now and then, is
> cherished by the wisest men.
> 
> 
> http://noahpugsley.net/59.jpg
> 
> 
> Cheers,
> 
> -noah
> 
> P.S. garbage.fm you both better be at bsdcan. I want to complain about
> everything !OpenBSD. And I think you do too.

scim-anthy may be wrong (5.9 i386)

[Tuyosi Takesima]

hi all .


i do command [ scim-anthy ] , and at [  global setup ] i remove check of
[Others] .

but i do again scim-setup , check mark is on [Others] namely no change .

so i think that something is wrong with scim-anthy of 5.9 i386.

at present i use ibus-anthy , and this works well .
-
regards

Re: Python requirements.

[Jay Patel]

Hi Muhammad,

I did fresh install of 5.9 amd64 and tried to run it , it shows me this
error:

Traceback (most recent call last):
  File "manage.py", line 9, in 
execute_from_command_line(sys.argv)
  File
"/usr/local/lib/python2.7/site-packages/django/core/management/__init__.py",
line 399, in execute_from_command_line
utility.execute()
  File
"/usr/local/lib/python2.7/site-packages/django/core/management/__init__.py",
line 392, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
  File
"/usr/local/lib/python2.7/site-packages/django/core/management/__init__.py",
line 272, in fetch_command
klass = load_command_class(app_name, subcommand)
  File
"/usr/local/lib/python2.7/site-packages/django/core/management/__init__.py",
line 75, in load_command_class
module = import_module('%s.management.commands.%s' % (app_name, name))
  File "/usr/local/lib/python2.7/site-packages/django/utils/importlib.py",
line 40, in import_module
__import__(name)
  File
"/usr/local/lib/python2.7/site-packages/south/management/commands/__init__.py",
line 10, in 
import django.template.loaders.app_directories
  File
"/usr/local/lib/python2.7/site-packages/django/template/loaders/app_directories.py",
line 25, in 
raise ImproperlyConfigured('ImportError %s: %s' % (app, e.args[0]))
django.core.exceptions.ImproperlyConfigured: ImportError djcelery: cannot
import name _uuid_generate_random



everything seems to work on 5.8 though.. only problem in 5.8 is getting
gunicorn to work with it


Thanks,
Jay

On Tue, Apr 19, 2016 at 5:17 PM, Muhammad Muntaza 
wrote:

>
> On Apr 16, 2016 11:45 AM, "Jay Patel"  wrote:
> >
> > Hi all,
> Hi,
> >
> > Greetings! is it better to install Django and gunicorn using pip or via
> > Pkg_add only like py-django ?
> I install Django from tar.gz source with this command:
> $ doas python setup.py install
>
> Because I want to use python 2 and Django 1.8
> >
> > because i am having some trouble with gunicorn installed via pip.
> >
> > I am using 5.8 amd64 bit .
> >
> Upgrade to 5.9
>
> Muhammad Muntaza bin Hatta

Re: 5.9 discs in the wild.

[Maurice McCarthy]

5.9 arrived Swansea UK 16 April, while I was away at work :)

Re: scanner HP scanjet4370 not working

[Stuart Henderson]

On 2016-04-20, Eda Sky  wrote:
> A)
> Yes I read, unfortunately I do not see there's nothing there that would
> help me.

Did you read the sane-backends and hplip-common READMEs as well?

> probably a bug in sane-backends.

Since you said it works (with slightly older software versions) on Linux,
I would first look at configuration/permissions.

>>> $ dmesg
>>> OpenBSD 5.9-current (GENERIC.MP) #1690: Thu Mar 31 09:41:46 MDT 2016
>>>dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
>>> cpu0: Genuine Intel(R) CPU U2500 @ 1.20GHz ("GenuineIntel"
>>> 686-class) 1.20 GHz
>>> ...
>>> ugen1 at uhub0 port 5 "hewlett packard hp scanjet" rev 2.00/1.00 addr 2

When you include an OpenBSD dmesg, don't trim it. They're not that long and you
might be removing something important.

Re: 5.9 discs in the wild.

[Peter Kane]

On Wed, Apr 20, 2016 at 08:45:18PM -0700, noah pugsley wrote:
> Thank you all for the best little correctness focused general purpose
> operating system in the known universe.
> 
> With all the nonsense created every day, a little sanity now and then, is
> cherished by the wisest men.
> 
> 
> http://noahpugsley.net/59.jpg
> 
> 
> Cheers,
> 
> -noah
> 
> P.S. garbage.fm you both better be at bsdcan. I want to complain about
> everything !OpenBSD. And I think you do too.
> 

Also arrived in New Zealand. Thanks.

Peter