Re: WireGuard for OpenBSD
> Is there any chance of this being made into a port/package, knowing > it's just a snapshot? I have just send my first attempt for a new port "net/wireguard" to this list. Please test and send diffs/PRs, thanks!
NEW: net/wireguard
Hello, Attached is a new port for pre-release snapshots of WireGuard user-space VPN implementation in Go. It is my frst attempt to transcribe Jason's build & install shell script into an OpenBSD port ( https://xn--4db.cc/IKuBc62Z ). -- pkg/DESCR: ***WARNING:*** This is a work in progress and not ready for prime time, with no official "releases" yet. WireGuard is an extremely simple yet fast and modern VPN that utilizes state-of-the-art cryptography. It aims to be faster, simpler, leaner, and more useful than IPSec, while avoiding the massive headache. It intends to be considerably more performant than OpenVPN. https://www.wireguard.com/ https://git.zx2c4.com/wireguard-go/tree/README.md -- So far, I built and tested this port on OpenBSD 6.3-stable amd64 only against the latest snapshot of WG app for Android on Nexus 5X and Samsung S3. This initial port certainly requires more work. But it may facilitate the tracking of frequent pre-release snapshots of WG compared to Jason's shell script. In order to track issues and your PRs, I intend to put it up in a few days at https://github.com/jasperla/openbsd-wip/tree/master/net Thanks, Rolf wireguard-0.0.20180613.tgz Description: application/gzip
security/softhsm2
Hello, Has anyone a port of SoftHSM v2.1.x as a Work-In-Progress? In August last year, there was a discussion about security/softhsm (currently v1.3.7) before v2.x was released http://comments.gmane.org/gmane.os.openbsd.ports/74967 I am trying to use security/softhsm with SSH (ssh-key-gen, ssh-agent) in -current, but failed to add private RSA keys in PKCS8 format to SoftHSM 1.3.7: softhsm --init-token --slot 0 --label "myToken1" ssh-keygen -e -m PKCS8 -f .ssh/id_rsa > .ssh/rsa.pem softhsm --import .ssh/rsa.pem --slot 0 --label "myToken1" --id A1B2 --pin 1234 Decoding error: PKCS #8 private key decoding failed Error: Perhaps wrong path to file, wrong file format, or wrong PIN to file (--file-pin ). Before digging into sources, I thought it may be worth trying SoftHSM 2.1.0 as PKCS#11 provider. Thank you, Rolf
Re: Go-1.4.1 on OpenBSD 5.7 i386 fails with SIGILL: illegal instruction
On Sat, Aug 8, 2015 at 12:22 AM, Ted Unangst wrote: Thanks everyone to your follow-ups. > talk to upstream? this sounds like a bug if the runtime detection is > insufficient. >From what I gathered about Go so far, upstream had already fixed that (see references in my previous posts). The problem might be more subtle, as I am "cross-"building the Go package on a SSE machine, but then install and run it on a non-SSE machine. At build time, the Go system will correctly detect my build host's capabilities, which results in Go system binaries that include SSE instructions. However, these system binaries fail with SIGILL on my non-SSE target as the initial Go loader, linker and other Go system libraries (try to) use SSE instructions at startup time of the Go system, before it actually detects the less capable CPU of my run-time target host. Thus my hypothesis is that the Go package would run fine if I would build it directly on the non-SSE target. But currently, I have no build environment on a ALIX host. Still, I will dig a bit further into the implementation of the Go system while learning it, and while experimenting with gopacket and its sub-libraries such as the recent bsdbpf. > unconditionally disabling sse would be a pessimization for most > users. As I share your concern, I thought that a separate flavour might be a solution. Another much more pragmatic and lighther solutions would be to just add a short note (in the Makefile or package info?) that shows how to rebuild the package for those who want to run Go on non-SSE CPU like Geode LX on ALIX.
Re: Go-1.4.1 on OpenBSD 5.7 i386 fails with SIGILL: illegal instruction
On Thu, Aug 6, 2015 at 5:54 PM, Stuart Henderson wrote:
> I'll see if I can figure something out.
I could get go-1.4.1 and also a "backport" of -1.4.2 which got just
tagged for OpenBSD 5.8 to work with the patches to Makefile below.
Note that no MAKE_ENV is set. though.
> I would expect some, as there's definitely code to do runtime detection.
Indeed, the go binary still includes some SSE instructions that uses
XMM registers, as you indicated probably for detection at run-time.
Today, I want to do more testing using the gopacket library and its
new bsdbpf extension on the PC Engines ALIX, and on APU too.
Regarding the Go port, I am unsure what would be the best way to
proceed, e.g. if a flavor with GO386=387 for i386 without SSE would be
justified for example.
diff for Makefile go-1.4.1 :
@@ -64,7 +67,8 @@
CXX="${CXX}" \
GOROOT=${WRKDIST} \
GOBIN=${WRKDIST}/bin \
- GOROOT_FINAL=${GOROOT} ./make.bash --no-banner
+ GOROOT_FINAL=${GOROOT} \
+ GO386=387 ./make.bash --no-banner
do-test:
@cd ${WRKSRC} && \
diff for Makefile go-1.4.2 :
@@ -1,6 +1,7 @@
# $OpenBSD: Makefile,v 1.25 2015/05/06 08:28:26 jasper Exp $
-ONLY_FOR_ARCHS = ${GO_ARCHS}
+#ONLY_FOR_ARCHS = ${GO_ARCHS}
+ONLY_FOR_ARCHS =amd64 i386
COMMENT = Go programming language
@@ -64,7 +67,8 @@
CXX="${CXX}" \
GOROOT=${WRKDIST} \
GOBIN=${WRKDIST}/bin \
- GOROOT_FINAL=${GOROOT} ./make.bash --no-banner
+ GOROOT_FINAL=${GOROOT} \
+ GO386=387 ./make.bash --no-banner
do-test:
@cd ${WRKSRC} && \
Re: Go-1.4.1 on OpenBSD 5.7 i386 fails with SIGILL: illegal instruction
> I'll try to build go "manually" as per [1] now, just to compare its > binary output with the package build process, and see if GO386=387 has > an effect. > > [1] https://golang.org/doc/install/source The resulting binary of this manual build still has some SSE2 code with XMM registers, though much less than with the package build with 'MAKE_ENV += GO386=387' : git clone https://go.googlesource.com/go cd go git checkout go1.4.1 cd src GO386=387 GOARCH=386 ./make.bash objdump -d /home/rs/goFromSource/go/bin/go | grep xmm So 'GO386=387' appears to have an impact in the manual build, and most checks still pass ok. The good news is, that simply scp /home/rs/goFromSource/go/bin/go from the i386 build host with SSE2/3 over to the ALIX, the go binary works without SIGILL :-) Will need to figure out what I still miss in the package build (I had done 'make clean=all' before 'make package') ...
Re: Go-1.4.1 on OpenBSD 5.7 i386 fails with SIGILL: illegal instruction
Despite the make_env, the go binary still has a ton of SSE2 code using XMM registers: objdump -d /usr/obj/ports/go-1.4.1/fake-i386/usr/local/bin/go | grep xmm 808a559: f2 0f 10 05 e8 3e 45movsd 0x8453ee8,%xmm0 808a561: f2 0f 11 44 24 38 movsd %xmm0,0x38(%esp) 808a61a: f2 0f 10 44 24 60 movsd 0x60(%esp),%xmm0 808a620: f2 0f 11 44 24 60 movsd %xmm0,0x60(%esp) 808a62e: f2 0f 10 44 24 58 movsd 0x58(%esp),%xmm0 808a634: f2 0f 11 44 24 58 movsd %xmm0,0x58(%esp) 808a63a: f2 0f 10 44 24 58 movsd 0x58(%esp),%xmm0 808a640: f2 0f 59 05 00 3f 45mulsd 0x8453f00,%xmm0 808a648: f2 0f 11 44 24 58 movsd %xmm0,0x58(%esp) 808a64e: f2 0f 10 44 24 58 movsd 0x58(%esp),%xmm0 808a654: f2 0f 10 4c 24 60 movsd 0x60(%esp),%xmm1 808a65a: f2 0f 58 c8 addsd %xmm0,%xmm1 ... I'll try to build go "manually" as per [1] now, just to compare its binary output with the package build process, and see if GO386=387 has an effect. [1] https://golang.org/doc/install/source
Re: Go-1.4.1 on OpenBSD 5.7 i386 fails with SIGILL: illegal instruction
On Thu, Aug 6, 2015 at 12:07 PM, Stuart Henderson wrote:
> That's a makefile variable only, not passed to the build. Try this?
Thanks for your diff. Unfortunately, it still does not solve the problem.
Is there any way I can check that the environment variable is indeed
applied to all steps while ("cross-")building the package on my Acer
laptop which has SSE2/SSE3 for my ALIX which has only MMX?
Re: Go-1.4.1 on OpenBSD 5.7 i386 fails with SIGILL: illegal instruction
On Thu, Aug 6, 2015 at 10:49 AM, Rolf Sommerhalder > Thus, I will now
re-build the entire package with this option, re-try,
> and report the outcome...
Being ecouraged by [1] too, I re-build go-1.4.1 package with an
additional line in its Makefile:
.elif ${MACHINE_ARCH} == "i386"
GOARCH =386
GO386 = 387
EXEPREFIX = 8
Unfortunately, the resulting package still aborts with SIGILL on ALIX
with AMD Geode LX.
Thus, I will dig into the package build in oder to verify that the
GO386 parameter is indeed taking effect throughout the build
process...
[1] Golang on the Geode processor
http://blog.nella.org/golang-on-the-geode-processor/
Re: Go-1.4.1 on OpenBSD 5.7 i386 fails with SIGILL: illegal instruction
Stuart, many thanks for your reply, assertions and suggestions!
On Wed, Aug 5, 2015 at 4:04 PM, Stuart Henderson wrote:
> ... can you try setting
> GO386=387 in your environment to disable the cpuid autodetection and see
> if it still does the same?
The problem persists even after adding this environment variable.
However, from [1, 2, 3] I understand, that I need to rebuild the
entire tool-chain, not only re-run the binary from the existing
package.
Thus, I will now re-build the entire package with this option, re-try,
and report the outcome...
> I occasionally run the regression test suite on i386 and amd64 and those
> usually come up OK, however I wouldn't normally do that on a non-SSE2
> machine.
Indeed, it works fine on another i386 machine that has SSE2/3 :-)
$ dmesg
OpenBSD 5.7 (GENERIC) #738: Sun Mar 8 10:59:31 MDT 2015
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
RTC BIOS diagnostic error 80
cpu0: Intel(R) Core(TM)2 Solo CPU U3500 @ 1.40GHz ("GenuineIntel"
686-class) 1.40 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,LAHF,PERF
real mem = 3147714560 (3001MB)
avail mem = 3083931648 (2941MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 08/10/10, SMBIOS rev. 2.6 @ 0xe8180 (28 entries)
bios0: vendor Acer version "V1.28" date 08/10/2010
bios0: Acer Aspire 3810T
...
$ go env
GOARCH="386"
GOBIN=""
GOCHAR="8"
GOEXE=""
GOHOSTARCH="386"
GOHOSTOS="openbsd"
GOOS="openbsd"
GOPATH="/home/rs/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/openbsd_386"
CC="cc"
GOGCCFLAGS="-fPIC -m32 -pthread -fmessage-length=0"
CXX="c++"
CGO_ENABLED="1"
[1] go1.1beta2 app - illegal instruction on LX800 processor Alix Board
https://groups.google.com/forum/#!msg/golang-nuts/v4MYW6sDrRo/nLP8YpiObLUJ
[2] code.google.com go 386 binaries now requiring SSE2?
https://groups.google.com/forum/#!topic/golang-nuts/NsROxh3Dc6M
[3] 386 woes
https://groups.google.com/forum/#!msg/golang-dev/oPOvRr7JU2Y/DAn2jwS38E8J
Go-1.4.1 on OpenBSD 5.7 i386 fails with SIGILL: illegal instruction
Hello list
While the Go 1.4.1 package works fine on OpenBSD 5.7 amd64 (Lenovo
X230 laptop), it fails with i386 (PCengines ALIX with Geode
processor), see output below.
I have put my user into the staff login class, and increased ulimits,
as hinted in
https://github.com/golang/go/wiki/OpenBSD
and
http://homing-on-code.blogspot.ch/2015/03/go-development-on-openbsd.html
Googling reveals some PRs regarding run-time error at Go load-time due
to missing instructions on some i386 processors:
https://code.google.com/p/go/issues/detail?id=4798
https://github.com/golang/go/issues/4798
Fixes #4798, 14 Feb 2013
cmd/8c: disable use of prefetch with GO386=387
https://github.com/golang/go/commit/594360cb1b31a99a349ba03294f5459aff0bc33d
Can anyone confirm that this package should indeed work on i386 as
well, or if there is some more knobs to turn (dis-/enable options in
the BIOS or kernel, etc) that I have missed?
Thanks,
Rolf
$ dmesg
OpenBSD 5.7 (GENERIC) #738: Sun Mar 8 10:59:31 MDT 2015
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
RTC BIOS diagnostic error 80
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD"
586-class) 499 MHz
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
real mem = 267931648 (255MB)
avail mem = 251179008 (239MB)
...
$ pkg_info | grep go
go-1.4.1Go
programming language
$ go version
SIGILL: illegal instruction
PC=0x80a58bf
goroutine 1 [running, locked to thread]:
runtime.mapassign1(0x82f5f80, 0x18738020, 0x1872ff60, 0x1872ff5c)
/usr/local/go/src/runtime/hashmap.go:455 +0x23f fp=0x1872ff4c
sp=0x1872fef0
unicode.init()
/usr/local/go/src/unicode/tables.go:52 +0xaf fp=0x1872ff6c sp=0x1872ff4c
go/parser.init()
/usr/local/go/src/go/parser/parser.go:2462 +0x3f fp=0x1872ff78
sp=0x1872ff6c
main.init()
/usr/local/go/src/cmd/go/zdefaultcc.go:6 +0x3f fp=0x1872ffcc
sp=0x1872ff78
runtime.main()
/usr/local/go/src/runtime/proc.go:58 +0xb7 fp=0x1872fff0 sp=0x1872ffcc
runtime.goexit()
/usr/local/go/src/runtime/asm_386.s:2287 +0x1 fp=0x1872fff4
sp=0x1872fff0
goroutine 2 [runnable]:
runtime.forcegchelper()
/usr/local/go/src/runtime/proc.go:90
runtime.goexit()
/usr/local/go/src/runtime/asm_386.s:2287 +0x1
goroutine 3 [runnable]:
runtime.bgsweep()
/usr/local/go/src/runtime/mgc0.go:82
runtime.goexit()
/usr/local/go/src/runtime/asm_386.s:2287 +0x1
eax 0x0
ebx 0x0
ecx 0x1870c070
edx 0x18738020
edi 0x1b
esi 0x1870c077
ebp 0x0
esp 0x1872fef0
eip 0x80a58bf
eflags 0x10246
cs 0x2b
fs 0x5b
gs 0x63
net/daemonlogger anyone?
Does anyone have a port of Marty Roesch's daemonlogger available? Those posted in late 2007 have been eaten by bit-rot, and the waybackmachine does not have them either http://archives.neohapsis.com/archives/openbsd/2007-11/1150.html http://archives.neohapsis.com/archives/openbsd/2007-11/1298.html Thanks, Rolf
libusb-1.0 anyone?
Hello Sebastian Recently, Sebastian Reitenbach posted an update of gpsd with the comment: "gpsd only supports libusb-1.0, which does not support OpenBSD (yet)..." Since quite a while, I have been working on a port of Gnuradio for OpenBSD. The new Universal Hardware Driver (UHD) for the Universal Software Radio Peripheral (USRP) also depends on libusb-1.0, which is not just an update of our libusb-0.1 as described in http://www.libusb.org/wiki/libusb-1.0 Is there any work in progress of porting libusb-1.0 to OpenBSD, or re-implementing a compatible API such as in FreeBSD? Eventually, another approach might be to implement a wrapper around libusb-0.1 which emulates libusb-1.0 (the inverse has been done). If so, I am interested in trying to help, or to assist with testing it with both gpsd and UHD/USRP1. Thank you, Rolf
Re: NEW: boost-1.39.0
On Tue, May 12, 2009 at 11:47 PM, Marco Peereboom wrote: > ===> Checking files for boost-1.39.0p0 >>> boost_1_39_0.tar.gz doesn't seem to exist on this system. >>> Fetch >>> http://easynews.dl.sourceforge.net/sourceforge/boost/boost_1_39_0.tar.gz. > boost_1_39_0.tar.gz 100% |***| 35508 KB 00:59 >>> Size does not match for /usr/ports/distfiles/boost_1_39_0.tar.gz > > I manually changed distinfo but no love there either. Facing the same over here, thanks.
Re: boost-1.39.0. efforts
> I'd made some effort to update quite old port of boost, Great - I am looking forward to help with testing it. A preliminary port of gnuradio is rotting in my tree, partially because it depends on a more recent boost than is currently in ports. Rolf
User and Group IDs of _zabbix clash with _pound
While attempting to install the new zabbix port, the id 623 of user _zabbix collides with the identical id of user _pound. I run -current kernel as of two days, and synced the source tree just now before making zabbix. At the moment, I am unsure how to assert with ports that their user and group ids are unique. Anyway, many thanks for both ports! Rolf [r...@x61:zabbix]# pwd /usr/ports/net/zabbix [r...@x61:zabbix]# make install ===> zabbix-agent-1.6.4p1 depends on: openldap-client-* - found ===> Verifying specs: lber ldap c kvm m ===> found lber.9.1 ldap.9.1 c.50.1 kvm.9.0 m.5.0 ===> Installing zabbix-agent-1.6.4p1 from /usr/ports/packages/i386/all/ groupadd: can't add group: gid 623 is a duplicate system(/usr/sbin/groupadd, -g, 623, _zabbix) failed: exit(1) useradd: uid 623 is already in use system(/usr/sbin/useradd, -u, 623, -g, _zabbix, -L, daemon, -c, zabbix user, -d, /nonexistent, -s, /sbin/nologin, _zabbix) failed: exit(1) zabbix-agent-1.6.4p1: complete [r...@x61:zabbix]# grep 623 /etc/passwd _pound:*:623:623:pound user:/nonexistent:/sbin/nologin [r...@x61:zabbix]# pkg_info | grep pound libbonobo-2.24.1GNOME component and compound document system pound-2.4.4 HTTP reverse proxy/load balancer/SSL offload
Re: new: misc/omconsole
OK on i386-current with FreeRunner GTA02 running OM2008.9 Thanks Matthieu for these nice tools/ports, Rolf [r...@think:om]# dmesg ugen1 at uhub5 port 1 "OpenMoko Debug Board for Neo1973" rev 2.00/5.00 addr 4 [r...@think:om]# omconsole U-Boot 1.3.2-moko12 (Oct 7 2008 - 21:03:06) I2C: ready DRAM: 128 MB Flash: 2 MB NAND: 256 MiB Found Environment offset in OOB.. Glamo core device ID: 0x3650, Revision 0x0002 USB: S3C2410 USB Deviced Uncompressing Linux... done, booting the kernel. [0.00] Linux version 2.6.24 (bu...@barbie) (gcc version 4.1.2) #1 PREEMPT Thu Nov 6 02:57:37 CST 2008 [0.00] CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0007177 [0.00] Machine: GTA02 [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] On node 0 totalpages: 32768 ... The Openmoko Distribution -- powered by Angstrom om-gta02 ttySAC2 Openmoko P1-Snapshot-20080807 om-gta02 ttySAC2 om-gta02 login: root r...@om-gta02:~# r...@om-gta02:~# df Filesystem 1k-blocks Used Available Use% Mounted on rootfs 252544102108150436 40% / /dev/root 252544102108150436 40% / /dev/root 252544102108150436 40% /dev/.static/dev udev 204872 1976 4% /dev /dev/mmcblk0p1 49792048497872 0% /media/card tmpfs61928 236 61692 0% /var/volatile tmpfs61928 0 61928 0% /dev/shm r...@om-gta02:~#
Re: NEW: security/yersinia
Many thanks to Markus Lude and Fernando Quintero for their kind feedback, which I included in attached yersinia-0.7.1p0. 'make port-lib-depends-check' is now happy. Tested on i386. OK? Thanks, Rolf yersinia-0.7.1p0.tgz Description: Binary data
UPDATE: devel/swig-1.3.6
An almost trivial update, which becomes necessary because it is a dependency of the ham/gnuradio-3.1.2 port on which I am currently working. Tested OK on i386. swig-1.3.36.tgz Description: Binary data
NEW: security/yersinia
Tested on i386, so far. cat pkg/DESCR Yersinia is a layer 2 vulnerability scanner with support for the following protocols: - Cisco Discovery Protocol (CDP) - Dynamic Host Configuration Protocol (DHCP) - IEEE 802.1q - IEEE 802.1x - Dynamic Trunking Protocol (DTP) - Hot Standby Router Protocol (HSRP) - Inter-Switch Link Protocol (ISL) - Spanning Tree Protocol (STP, RSTP) - VLAN Trunking Protocol (VTP) How can I get rid of the follwing error? To me it looks like Makefile needs an additional entry which tells lib-depends-check to check for linet-1.1 in /usr/local/lib/libnet-1.1/ : $ make lib-depends-check /usr/ports/packages/i386/all/yersinia-0.7.1.tgz: Missing lib: net.11 (/usr/local/bin/yersinia) (NOT REACHABLE) *** Error code 1 Stop in /usr/ports/mystuff/security/yersinia-0.7.1 (line 1750 of /usr/ports/infrastructure/mk/bsd.port.mk). $ Thanks for any hints and OKs, Rolf yersinia-0.7.1.tgz Description: Binary data
Re: p5-Apache-Dynagzip anyone?
Attached is a first stab at Apache::Dynazip and its dependencies. p5-Apache-Filter needs a little more work to skip the test while building in unattended/batch mode. So far, I was unable to verify these Perl modules indeed work correctly, e.g. that they indeed compress pages which Apache generates dynamically on i386. Thus, at the moment, I focus on comparing against results obtained with mod_gzip on static pages (mod_gzip is already in ports & packages). Any help, suggestions, or working sample configurations very welcome. Thanks, Rolf p5-Apache-Dynagzip.tgz Description: Binary data p5-Apache-CompressClientFixup.tgz Description: Binary data p5-Apache-Filter.tgz Description: Binary data p5-Compress-LeadingBlankSpaces.tgz Description: Binary data
p5-Apache-Dynagzip anyone?
Hello, Is anyone working on (or has already) a port for Apache::Dynagzip - mod_perl extension for Apache-1.3.X to compress the response with gzip format. http://search.cpan.org/~slava/Apache-Dynagzip-0.16/Dynagzip.pm Thanks, Rolf
New: net/pound-2.4.2: reverse proxy, load balancer and HTTPS front-end
The attached port is based on prior work by Pete Vickers on Pound-1.10,
now updated to the current Pound-2.4.2. It was motivated by our requirement
for filtering HTTP requests. Unfortunately, we could not figure out yet
how to do this with relayd.
Note that building a package from this port requires that thread support
is enabled in OpenSSL. Thus you need to apply the three patches below to
the kernel source tree BEFORE attempting to build the pound package.
We ignore if thread support was left disabled on OpenBSD simply because
it was no needed so far, or if there were other reasons such as concerns
about reliability or security of the resulting OpenSSL library.
We tested our port and the OpenSSL library with thread support on i386
and sparc64.
Please test and commit this port and the source tree patches, if there
are no objections to activate thread support in OpenSSL by default.
Further work on filter support in relayd might eventually make this port
and enabling thread support in OpenSSL redundant later.
Thanks in advance for any feedback,
Rolf
So far, to make Pound ports on OpenBSD, the recommendation was to build
OpenSSL with thread support and install it in parallel to the OpenBSD
default installed (non-threaded) OpenSSL library. However, making a
Pound port on sparc64 following that recipe fails. Some subtle bug in
the assembler specific to non UltraSPARC CPUs (found in SUN Blade 100
for ex.) surfaces while making OpenSSL with threads support. Although
./config no-hw threads no-asm
--openssldir=/usr/ports/net/pound-2.4.2/w-pound-2.4.2/openssl-tmp
resolves this issue at first sight, 'make test' later fails.
To resolve, and also as a presumably cleaner long-term solution that
avoids an installation of another OpenSSL library in parallel, we
propose to modify and remake OpenBSD's OpenSSL native library with
threads support. Thereafter, our Pound port builds cleanly, and "it
just works" without having to recompile OpenSSL and install a second
OpenSSL library.
According to CVS,
http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/Makefile ,
OpenBSD does not use Configure of OpenSSL, but uses pre-compiled
opensslconf.h files that contain options. Therefore, we modify them for
i386 and sparc64 respectively:
diff -u /usr/src/lib/libssl/crypto/arch/i386/opensslconf.h.orig
/usr/src/lib/libssl/crypto/arch/i386/opensslconf.h
--- /usr/src/lib/libssl/crypto/arch/i386/opensslconf.h.orig Tue Sep 3
20:59:55 2002
+++ /usr/src/lib/libssl/crypto/arch/i386/opensslconf.h Thu Apr 17 19:28:50 2008
@@ -10,6 +10,10 @@
#endif /* OPENSSL_DOING_MAKEDEPEND */
+#ifndef OPENSSL_THREADS
+# define OPENSSL_THREADS
+#endif
+
/* The OPENSSL_NO_* macros are also defined as NO_* if the application
asks for it. This is a transient feature that is provided for those
who haven't had the time to do the appropriate changes in their
Note: Apply the above patch to the other archs as well,
e.g. .../arch/sparc64/opensslconf.h, etc.
diff -u /usr/src/lib/libssl/crypto/Makefile.orig
/usr/src/lib/libssl/crypto/Makefile
--- /usr/src/lib/libssl/crypto/Makefile.origSat Feb 24 20:45:52 2007
+++ /usr/src/lib/libssl/crypto/Makefile Thu Apr 17 19:29:58 2008
@@ -28,6 +28,7 @@
CFLAGS+= -DOPENSSL_NO_HW_CSWIFT -DOPENSSL_NO_HW_NCIPHER
-DOPENSSL_NO_HW_ATALLA
CFLAGS+= -DOPENSSL_NO_HW_NURON -DOPENSSL_NO_HW_UBSEC -DOPENSSL_NO_HW_AEP
CFLAGS+= -DOPENSSL_NO_HW_SUREWARE -DOPENSSL_NO_HW_4758_CCA
+CFLAGS+= -DOPENSSL_THREADS
CFLAGS+= -I${.CURDIR}/../${SSLEAYDIST}
CFLAGS+= -I${LCRYPTO_SRC}
SRCS+= o_time.c
diff -u /usr/src/lib/libssl/ssl/Makefile.orig /usr/src/lib/libssl/ssl/Makefile
--- /usr/src/lib/libssl/ssl/Makefile.orig Thu Nov 24 21:49:23 2005
+++ /usr/src/lib/libssl/ssl/MakefileThu Apr 17 19:30:40 2008
@@ -24,6 +24,7 @@
CFLAGS+= -DOPENSSL_NO_IDEA -DTERMIOS -DANSI_SOURCE -DNO_ERR
CFLAGS+= -DOPENSSL_NO_MDC2
CFLAGS+= -DOPENSSL_NO_RC5 -DOPENSSL_NO_KRB5 -DHAVE_DLFCN_H
+CFLAGS+= -DOPENSSL_THREADS
CFLAGS+= -I${.CURDIR}/../${SSLEAYDIST}
SRCS= bio_ssl.c s2_clnt.c s3_both.c s3_srvr.c ssl_err2.c ssl_txt.c\
Then rebuild kernel as well as userland.
Finally, verify that the header file is up-to-date as shown below (why
is this not automagically done by make install, but only done if entire
kernel and/or userland is built?). Our port will only build if the
header file not has these three additional lines which indicate that
OpenSSL now includes thread support:
diff -u /usr/include/openssl/opensslconf.h.orig
/usr/include/openssl/opensslconf.h
--- /usr/include/openssl/opensslconf.h.orig Fri May 23 19:44:54 2008
+++ /usr/include/openssl/opensslconf.h Fri May 23 19:45:08 2008
@@ -10,6 +10,10 @@
#endif /* OPENSSL_DOING_MAKEDEPEND */
+#ifndef OPENSSL_THREADS
+# define OPENSSL_THREADS
+#endif
+
/* The OPENSSL_NO_* macros are also defined as NO_* if the application
asks for it. This is a transient feature that is provided for those
who haven't had the time to do the appropriate changes in
gnuradio & USRP anyone?
Hello ports@, Is anyone working on a port for GNU Radio (gnuradio)? Has anyone tried to use a Universal Software Radio Peripheral (USRP) under OpenBSD? I am attempting to build gnuradio, but still struggling. I have no USRP hardware yet to test with, but considering to purchase one now, also to take advantage of the favourable exchange rate CHF/USD. Thanks, Rolf
PATCH: net-snmp-5.4.1p1 for sparc64
The patch below resolves a "Arithmetic exception (core dumped)" when
performing once snmwalk or snmpget access agent hardware memory
information. Also, on sparc64 the unpatched snmpd consumes all CPU and
memory resources within minutes after starting as in the background.
Interestingly, if run in the foreground (snmpd -f)., it does not hog
those resources and behaves.
Without this patch, these problems occur on sparc64-current, whereas
on i386-current I did not observe them. I noticed the problems already
in 4.1 and before upgrading to net-snmp-5.4.1, but back then, I never
got around to track it down.
Please test and propose improvements for my somewhat naive,
quick&dirty patch before committing. I do not understand the details
of sysctl and uvmexp yet, thus just used getpagesize(3).
OK on sparc64.
Thanks,
Rolf
# diff -urN net-snmp net-snmp-5.4.1p1
diff -urN net-snmp/Makefile net-snmp-5.4.1p1/Makefile
--- net-snmp/Makefile Wed Sep 26 22:03:42 2007
+++ net-snmp-5.4.1p1/Makefile Sun Oct 7 09:40:05 2007
@@ -4,7 +4,7 @@
COMMENT-perl= SNMP modules for Perl
DISTNAME= net-snmp-5.4.1
-PKGNAME-main= ${DISTNAME}
+PKGNAME-main= ${DISTNAME}p1
PKGNAME-perl= p5-SNMP-5.4.1
SHARED_LIBS= netsnmp 7.0 \
netsnmpagent7.0 \
diff -urN net-snmp/patches/patch-agent_mibgroup_hardware_memory_memory_netbsd_c
net-snmp-5.4.1p1/patches/patch-agent_mibgroup_hardware_memory_memory_netbsd_c
--- net-snmp/patches/patch-agent_mibgroup_hardware_memory_memory_netbsd_c
Thu Jan 1 01:00:00 1970
+++
net-snmp-5.4.1p1/patches/patch-agent_mibgroup_hardware_memory_memory_netbsd_c
Sun Oct 7 09:42:54 2007
@@ -0,0 +1,29 @@
+--- agent/mibgroup/hardware/memory/memory_netbsd.c.orig Mon Mar 6
17:23:52 2006
agent/mibgroup/hardware/memory/memory_netbsd.c Sun Oct 7
09:33:56 2007
+@@ -30,7 +30,11 @@
+ long pagesize;
+
+ struct uvmexp uvmexp;
+-intuvmexp_size = sizeof(uvmexp);
++#ifdef __OpenBSD__
++ size_tuvmexp_size = sizeof(uvmexp);
++#else
++ int uvmexp_size = sizeof(uvmexp);
++#endif
+ intuvmexp_mib[] = { CTL_VM, VM_UVMEXP };
+
+ struct vmtotal total;
+@@ -50,7 +54,11 @@
+ sysctl(total_mib,2, &total,&total_size,NULL, 0);
+ sysctl(phys_mem_mib, 2, &phys_mem, &mem_size, NULL, 0);
+ sysctl(user_mem_mib, 2, &user_mem, &mem_size, NULL, 0);
+-pagesize = uvmexp.pagesize;
++#ifdef __OpenBSD__
++ pagesize = getpagesize();
++#else
++ pagesize = uvmexp.pagesize;
++#endif
+
+ /*
+ * ... and save this in a standard form.
+
#
Here is an illustration of the problem on sparc64-current
A) snmpd.conf is minimal:
# cat /etc/snmp/snmpd.conf
rocommunity public
B) snmpd run in the foreground within gdb
[EMAIL PROTECTED]:snmp]# gdb /usr/local/sbin/snmpd
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc64-unknown-openbsd4.2"...(no
debugging symbols found)
(gdb) run -f -Lo -D
..
verbose:sess_select: timer due in 4.996670 sec
verbose:sess_select: setting timer to 4.996670 sec, clear block (was 0)
trace: receive(): snmpd.c, 1144:
snmpd/select: select( numfds=12, ..., tvp=0xfffead10)
trace: receive(): snmpd.c, 1146:
timer: tvp 4.996670
trace: receive(): snmpd.c, 1148:
snmpd/select: returned, count = 0
trace: run_alarms(): snmp_alarm.c, 251:
snmp_alarm: run alarm 2
trace: netsnmp_cpu_get_byIdx(): hardware/cpu/cpu.c, 69:
cpu: cpu_get_byIdx -1 (found)
trace: netsnmp_cpu_get_byIdx(): hardware/cpu/cpu.c, 69:
cpu: cpu_get_byIdx 0 (found)
trace: run_alarms(): snmp_alarm.c, 253:
snmp_alarm: alarm 2 completed
trace: snmp_sess_select_info(): snmp_api.c, 5868:
sess_select: for all sessions: 11 7
sess_select: next alarm 4.996349 sec
verbose:sess_select: timer due in 4.996349 sec
verbose:sess_select: setting timer to 4.996349 sec, clear block (was 0)
trace: receive(): snmpd.c, 1144:
snmpd/select: select( numfds=12, ..., tvp=0xfffead10)
trace: receive(): snmpd.c, 1146:
timer: tvp 4.996349
..
{
C) the above repeats until we launch from another host:
$ snmpwalk -v 2c -c public 172.16.71.6 .
}
..
trace: netsnmp_view_subtree_check(): vacm.c, 532:
9:vacm:checkSubtree: view _all_
trace: netsnmp_view_subtree_check(): vacm.c, 569:
9:vacm:checkSubtree: _all_ matched?
trace: netsnmp_view_subtree_check(): vacm.c, 630:
9:vacm:checkSubtree: (null) matched
trace: netsnmp_view_subtree_check(): vacm.c, 653:
vacm:checkSubtree: , included
trace: snmp_call_callbacks(): callback.c, 336:
callback: END calling callbacks for maj=1 min=12 (1 called)
trace: _callback_unlock(): callback.c, 152:
9:callback:lock: unlocked (APP,null)
trace:
Re: Fix for OpenVPN after route.h changes
Works for me on i386, too. Thanks.
Re: ports soft lock
Can someone commit the rather trivial update for vpnc-0.4.0 which I posted in April, and which I am using since on -current i386, sparc64, and zaurus? Thanks, Rolf
Re: rdesktop patch
Thanks for this patch which applied cleanly and solved the problem of rdesktop crashing upon startup on my Dell Inspiron 4000 laptop running i386-current and xenocara. Interestingly, the unpatched rdesktop so far did not crash on my Dell desktop at work which also runs i386-current and xenocara. Eventually, unpatched rdesktop does not crash on certain video cards? I can provide dmesg of both boxes if anyone is interested. Can you commit this patch to the ports tree, and/or send it upstream? Thanks, Rolf
Re: UPDATE: vpnc 0.4.0
Works OK also on zaurus 4.1-current. Rolf
UPDATE: xplanet-1.2.0
The updated xplanet features bumpmaps, e.g. it uses elevation info to
generate shading behind mountain ridges (see
http://xplanet.sourceforge.net/Gallery/20050418_earth/ for two
samples).
It works fine for me with xenocara on i386 -current.
I patched only a single line, as I do not know yet how to deal
properly with the signbit() function from libgcc++. My inline
replacement is almost equivalent to the two library function calls,
and similar to surrounding code, too.
Please test - thanks,
Rolf
diff -urN --exclude=CVS xplanet/Makefile xplanet1.2.0/Makefile
--- xplanet/MakefileFri Dec 1 17:50:38 2006
+++ xplanet1.2.0/Makefile Sat Apr 28 08:03:52 2007
@@ -2,8 +2,8 @@
COMMENT= "Draw pictures of the earth textured by an image"
-DISTNAME= xplanet-1.1.2
-PKGNAME= ${DISTNAME}p33
+DISTNAME= xplanet-1.2.0
+PKGNAME= ${DISTNAME}
CATEGORIES=astro geo x11
MAINTAINER=Robert Nagy <[EMAIL PROTECTED]>
diff -urN --exclude=CVS xplanet/distinfo xplanet1.2.0/distinfo
--- xplanet/distinfoFri Apr 6 07:49:37 2007
+++ xplanet1.2.0/distinfo Sat Apr 28 08:09:13 2007
@@ -1,5 +1,5 @@
-MD5 (xplanet-1.1.2.tar.gz) = +pr1/CPahTIXLkeal1ZJuQ==
-RMD160 (xplanet-1.1.2.tar.gz) = CJp7IcClewNepb8+Cj8gYDeO2mc=
-SHA1 (xplanet-1.1.2.tar.gz) = FeaMf5/416Gg4+ZN500fr6KRees=
-SHA256 (xplanet-1.1.2.tar.gz) = rGAXNdAMA7+lEcrWPCx2qbQq9CLUrxFR4vmWNyiqCl8=
-SIZE (xplanet-1.1.2.tar.gz) = 1185949
+MD5 (xplanet-1.2.0.tar.gz) = h9YvzfQ60b7sZ3v7bimawQ==
+RMD160 (xplanet-1.2.0.tar.gz) = aAeWKeghlPSDyqDAbXNnJUTvvLs=
+SHA1 (xplanet-1.2.0.tar.gz) = 4AJxH5D1AlZWE6sXonMXXMA1tSw=
+SHA256 (xplanet-1.2.0.tar.gz) = KOs2VB2sQKE/Sw3LoxDsqoJSh/ZAdMUXXSYTaNgpBpU=
+SIZE (xplanet-1.2.0.tar.gz) = 1196496
diff -urN --exclude=CVS xplanet/patches/patch-ProjectionIcosagnomonic_cpp
xplanet1.2.0/patches/patch-ProjectionIcosagnomonic_cpp
--- xplanet/patches/patch-ProjectionIcosagnomonic_cpp Thu Jan 1 01:00:00 1970
+++ xplanet1.2.0/patches/patch-ProjectionIcosagnomonic_cpp Sat Apr 28
17:22:45 2007
@@ -0,0 +1,10 @@
+--- src/libprojection/ProjectionIcosagnomonic.cpp.origTue Jun 14 20:10:36
2005
src/libprojection/ProjectionIcosagnomonic.cpp Sat Apr 28 17:18:02 2007
+@@ -102,7 +102,7 @@
+ double dp1 = PointXYZ::dotP(cp, p1);
+ double dp2 = PointXYZ::dotP(cp, p2);
+
+-return (signbit(dp1) == signbit(dp2) || fabs(dp1) < 1e-10);
++return ((dp1 <0.0) == (dp2 <0.0) || fabs(dp1) < 1e-10);
+ }
+
diff -urN --exclude=CVS xplanet/patches/patch-src_Options_cpp
xplanet1.2.0/patches/patch-src_Options_cpp
--- xplanet/patches/patch-src_Options_cpp Tue May 24 21:15:53 2005
+++ xplanet1.2.0/patches/patch-src_Options_cpp Sat Apr 28 17:11:22 2007
@@ -1,7 +1,7 @@
$OpenBSD: patch-src_Options_cpp,v 1.1.1.1 2005/05/24 19:15:53 robert Exp $
src/Options.cpp.orig Wed Apr 13 13:46:38 2005
-+++ src/Options.cppWed Apr 13 13:47:05 2005
-@@ -100,7 +100,7 @@
+--- src/Options.cpp.orig Tue Jun 14 19:36:45 2005
src/Options.cppSat Apr 28 16:42:07 2007
+@@ -104,7 +104,7 @@ Options::Options() :
oX_(0),
oY_(0),
oZ_(0),
Re: UPDATE: vpnc 0.4.0
The updated port tested also OK under sparc64 -current.
UPDATE: vpnc 0.4.0
Updating IPSec VPN client vpnc from 0.4.0 from 0.3.3 using the
attached diff appears to have solved the problems I did experience
with keep-alives and previously missing re-keying (VPN tunnels froze
within minutes resp. after 6-7 hours) when connecting to a Cisco 3005
from OpenBSD i386 4.1-current. I might still test from sparc64 and
eventually get rid of the four type mismatch warnings. It appears that
most patches from 0.3.3 made it into the upstream distribution, e.g.
0.4.0 builds without patches (but warnings).
Rolf
diff -urN --exclude=CVS vpnc/Makefile vpnc0.4.0/Makefile
--- vpnc/Makefile Fri Aug 4 01:28:12 2006
+++ vpnc0.4.0/Makefile Sun Apr 22 20:06:09 2007
@@ -2,8 +2,8 @@
COMMENT= "client for Cisco 3000 VPN concentrators"
-DISTNAME= vpnc-0.3.3
-PKGNAME= ${DISTNAME}p1
+DISTNAME= vpnc-0.4.0
+PKGNAME= ${DISTNAME}
CATEGORIES=security net
HOMEPAGE= http://www.unix-ag.uni-kl.de/~massar/vpnc/
diff -urN --exclude=CVS vpnc/patches/patch-Makefile
vpnc0.4.0/patches/patch-Makefile
--- vpnc/patches/patch-Makefile Fri Nov 11 20:38:07 2005
+++ vpnc0.4.0/patches/patch-MakefileThu Jan 1 01:00:00 1970
@@ -1,16 +0,0 @@
-$OpenBSD: patch-Makefile,v 1.3 2005/11/11 19:38:07 sturm Exp $
Makefile.orig Sun May 1 22:30:35 2005
-+++ Makefile Fri Nov 4 00:03:54 2005
-@@ -22,9 +22,9 @@ ETCDIR=/etc/vpnc
- SBINDIR=$(PREFIX)/sbin
- MANDIR=$(PREFIX)/share/man
-
--CC=gcc
--CFLAGS=-W -Wall -O -g '-DVERSION="$(shell cat VERSION)"' $(shell
libgcrypt-config --cflags)
--LDFLAGS=-g $(shell libgcrypt-config --libs)
-+CC?=gcc
-+CFLAGS+=-W -Wall '-DVERSION="$(shell cat VERSION)"' $(shell libgcrypt-config
--cflags)
-+LDFLAGS+=$(shell libgcrypt-config --libs)
-
- ifeq ($(shell uname -s), Linux)
- SYSDEP=sysdep-linux.o
diff -urN --exclude=CVS vpnc/patches/patch-tunip_c
vpnc0.4.0/patches/patch-tunip_c
--- vpnc/patches/patch-tunip_c Fri Nov 11 20:38:07 2005
+++ vpnc0.4.0/patches/patch-tunip_c Thu Jan 1 01:00:00 1970
@@ -1,21 +0,0 @@
-$OpenBSD: patch-tunip_c,v 1.3 2005/11/11 19:38:07 sturm Exp $
tunip.c.orig Thu May 5 12:25:00 2005
-+++ tunip.cFri Nov 4 00:09:30 2005
-@@ -436,7 +436,7 @@ int update_sa_addr(struct sa_desc *p)
- if (new_addr.sin_addr.s_addr != p->source.sin_addr.s_addr) {
- char addr1[16];
- p->source.sin_addr = new_addr.sin_addr;
-- strcpy(addr1, inet_ntoa(p->dest.sin_addr));
-+ strlcpy(addr1, inet_ntoa(p->dest.sin_addr), sizeof(addr1));
- syslog(LOG_NOTICE,
- "local address for %s is %s", addr1,
inet_ntoa(p->source.sin_addr));
- return 1;
-@@ -844,7 +844,7 @@ static void vpnc_main_loop(struct peer_d
- || from.sin_addr.s_addr !=
peer->remote_sa->dest.sin_addr.s_addr) {
- /* remote end changed address */
- char addr1[16];
-- strcpy(addr1,
inet_ntoa(peer->remote_sa->dest.sin_addr));
-+ strlcpy(addr1,
inet_ntoa(peer->remote_sa->dest.sin_addr), sizeof(addr1));
- syslog(LOG_NOTICE,
- "spi %u: remote address changed from %s
to %s",
- peer->remote_sa->spi, addr1,
inet_ntoa(from.sin_addr));
diff -urN --exclude=CVS vpnc/patches/patch-vpnc-script
vpnc0.4.0/patches/patch-vpnc-script
--- vpnc/patches/patch-vpnc-script Fri Nov 11 20:38:07 2005
+++ vpnc0.4.0/patches/patch-vpnc-script Thu Jan 1 01:00:00 1970
@@ -1,64 +0,0 @@
-$OpenBSD: patch-vpnc-script,v 1.1 2005/11/11 19:38:07 sturm Exp $
vpnc-script.orig Thu Nov 3 23:39:23 2005
-+++ vpnc-scriptThu Nov 3 23:51:02 2005
-@@ -70,7 +70,7 @@ do_ifconfig() {
- ifconfig "$TUNDEV" inet "$INTERNAL_IP4_ADDRESS" $ifconfig_syntax_ptp
"$INTERNAL_IP4_ADDRESS" netmask 255.255.255.255 mtu 1412 up
- }
-
--if [ -n "$IPROUTE" ]; then
-+if [ -x "$IPROUTE" ]; then
- fix_ip_get_output () {
- sed 's/cache//;s/metric[0-9]\+ [0-9]\+//g'
- }
-@@ -117,7 +117,11 @@ if [ -n "$IPROUTE" ]; then
- }
- else
- get_default_gw() {
-- netstat -r -n | grep '^0.0.0.0' | awk '{print $2}'
-+ if [ "$OS" = "OpenBSD" ]; then
-+ netstat -r -n | grep '^default' | awk '{print $2}'
-+ else
-+ netstat -r -n | grep '^0.0.0.0' | awk '{print $2}'
-+ fi
- }
-
- set_vpngateway_route() {
-@@ -215,15 +219,21 @@ do_connect() {
- echo "$CISCO_BANNER" | while read LINE ; do echo "|" "$LINE" ;
done
- echo
- fi
--
-+
-+ if [ ! -d /var/run/vpnc ]; then
-+ mkdir /var/run/vpnc || exit $?
-+ fi
-+
- do_ifconfig
- set_vpngateway_route
- if [ -n "$CISCO_SPLIT_INC" ]; then
--
Re: Varnish: Anyone Porting Client-Side Reverse Cacheing Proxy?
My Subject: line is flawed - I meant to write 'Server-Side Reverse Proxy' of course, instead of 'Client-Side'. The new, official address of its homepage appears to be http://www.varnish-cache.org Rolf
Varnish: Anyone Porting Client-Side Reverse Cacheing Proxy?
Is anyone working on a port of Varnish v1.01 which was released recently under a BSD license? http://varnish.linpro.no A brief attempt to build it under -current showed that ./configure succeeds, but make fails due to some problem within cludes^and types. I might look closer into it over the next days. Is there any interested to share? Thanks, Rolf
Re: NEW: net/pound (Compact Reverse HTTP/HTTPS Proxy)
On 4/3/06, Pete Vickers <[EMAIL PROTECTED]> wrote: > Thanks for you work on this, but if you take a look at the pound mail > archives (http://www.apsis.ch/pound/pound_list) it can be seen that > pound v2.x is still very cutting edge / development, with lots of > issues regularly discovered. I therefore deliberately did the OpenBSD > port on the stable mature v1.x code base. I think that better > reflects the OpenBSD ethos of security & stability etc. My port also > includes an example with chroot & drop privs configured, and several > diff to make pound more BSD like regarding logging etc. After following the Pound mailing list since v1.6 or so, my assessment is that v2.0 has resolved several issues that existed in v1.x (such as memory leaks for example). The authors consider v2.0 stable, where v2.0.4 include fixes for smaller issues. Actually, v2.0.4 is considered beta because the author invites for testing under heavy load. Since v2.0.4 is out, I observe that the few problems that were posted are mostly related to building it on some platforms, or to issues where Pound is only one element in the entires chain client's browser - backend Web servers (e.g. where the solution is often not involving patching Pound itself, but either adding a functional extension or changing the surrounding setup). > I've enclosed an updated port for v1.10 Thanks for this update from interim v1.9.5, and for having done & posted the initial port in January. The reason which triggered me to update the port to v2.0.4 was that v1.9.5 is not available from the source anymore for downloading. What is the next step to get Pound (any version that is considered acceptable) included into the ports tree? Rolf
Re: NEW: net/pound (Compact Reverse HTTP/HTTPS Proxy)
Hello,
based on Pete's port of "pound" from 12 January 2006, I attempted an
update to its latest version pound-2.0.4. With only minor
modifications in the Makefile, it installs and runs fine under
3.9/i386/ -current as of today.
Rolf
diff -u pound-1.9.5/Makefile pound/Makefile
--- pound-1.9.5/MakefileThu Jan 12 19:49:51 2006
+++ pound/Makefile Sun Apr 2 18:18:32 2006
@@ -3,9 +3,9 @@
# based on application by Robert Segall ([EMAIL PROTECTED])
#
-COMMENT= "SSL reverse proxy and load balancer"
+COMMENT= "HTTP/HTTPS reverse proxy and load balancer"
-VERSION= 1.9.5
+VERSION= 2.0.4
DISTNAME= Pound-${VERSION}
PKGNAME= pound-${VERSION}
CATEGORIES=net
@@ -15,9 +15,9 @@
# need to get a copy of openssl to compile locally with +threads
SUPFILEVER=0.9.8a
SUPDISTNAME= openssl-${SUPFILEVER}
-SUPDISTFILES= ${SUPDISTNAME}.tar.gz:0
+SUPDISTFILES= ${SUPDISTNAME}.tar.gz
BASEDISTFILE= ${DISTNAME}.tgz
-DISTFILES= ${BASEDISTFILE} ${SUPDISTFILES}
+DISTFILES= ${BASEDISTFILE} ${SUPDISTFILES}:0
# LICENSE=GPL
PERMIT_PACKAGE_CDROM= Yes
diff -u pound-1.9.5/distinfo pound/distinfo
--- pound-1.9.5/distinfoThu Jan 12 19:55:22 2006
+++ pound/distinfo Sun Apr 2 15:37:36 2006
@@ -1,8 +1,8 @@
-MD5 (Pound-1.9.5.tgz) = 6db10b610a0d0b64dd05828fccff55db
+MD5 (Pound-2.0.4.tgz) = d7953742a638210eb89cf8deb2cb2112
MD5 (openssl-0.9.8a.tar.gz) = 1d16c727c10185e4d694f87f5e424ee1
-RMD160 (Pound-1.9.5.tgz) = 25e0d1d0a1eaff8f20474c732ff44eef189ccc20
+RMD160 (Pound-2.0.4.tgz) = df3b3bf30d46a2fcecbe03e43f33052fa8bf11f7
RMD160 (openssl-0.9.8a.tar.gz) = f92bb3cc4097cbeb5365f205b6412999d8fc3389
-SHA1 (Pound-1.9.5.tgz) = 6a47f7d6cccd6144cd67b32854fa39a6e4741978
+SHA1 (Pound-2.0.4.tgz) = 19dd78badeec1ccfa7f17ce45ea4e9f214023f4d
SHA1 (openssl-0.9.8a.tar.gz) = 2aaba0f728179370fb3e86b43209205bc6c06a3a
-SIZE (Pound-1.9.5.tgz) = 145000
+SIZE (Pound-2.0.4.tgz) = 143740
SIZE (openssl-0.9.8a.tar.gz) = 3271435
pound.tgz
Description: GNU Zip compressed data
