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