CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2014/05/26 00:48:59 Modified files: net/gssdp : Makefile distinfo net/gssdp/pkg : PLIST Log message: update to gssdp-0.14.8
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2014/05/26 06:24:28 Modified files: devel/py-gobject3: Makefile distinfo Log message: Update to py-gobject3 3.12.2.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2014/05/26 08:37:07 Modified files: devel/pep8 : Makefile distinfo devel/pep8/pkg : PLIST Log message: Update to pep8-1.5.6. Remove mpi@ from maintainer as per his request. ok mpi@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2014/05/26 10:52:36 Modified files: www/webkit : Makefile distinfo www/webkit/patches: patch-GNUmakefile_in Log message: Minor update to WebKit 2.4.3.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2014/05/26 13:24:28 Modified files: x11/qt4: Makefile Added files: x11/qt4/patches: patch-mkspecs_features_unix_gdb_dwarf_index_prf Log message: Fix a GNU-ism in a sed expression that gets copied into generated Makefiles.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2014/05/26 13:48:35 Modified files: sysutils/mcollective: Makefile Log message: re-install NO_BUILD, but add ruby to BUILD_DEPENDS. noticed by several
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: r...@cvs.openbsd.org2014/05/26 14:09:54 Modified files: sysutils/ansible: Makefile distinfo Log message: Update ansible to 1.6.2 OK aja@ landry@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2014/05/26 15:51:36 Modified files: net/p5-Net-DNS : Makefile distinfo Removed files: net/p5-Net-DNS/patches: patch-lib_Net_DNS_Resolver_Base_pm Log message: - update p5-Net-DNS to 0.76 - remove patch, it has been fixed upstream
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2014/05/26 15:57:43 Modified files: devel/p5-File-Find-Object-Rule: Makefile distinfo Log message: update p5-File-Find-Object-Rule to 0.0305
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2014/05/26 16:27:52 Modified files: security/p5-Net_SSLeay: Makefile distinfo Log message: update p5-Net-SSLeay to 1.63
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2014/05/26 17:30:33 Modified files: security/p5-IO-Socket-SSL: Makefile distinfo Log message: update p5-IO-Socket-SSL to 1.989
Re: firefox download issue
Hi, Same problem since the upgrade to openbsd 5.5 amd64 but only with Firefox 26.0, no problem before on 5.4 amd64 stable. I uninstalled it and go with firefox 24.5.0 ESR without problem. Le 25/05/2014 22:59, Landry Breuil a écrit : On Sun, May 25, 2014 at 10:16:04AM +0200, Jan Stary wrote: On May 21 10:55:25, pkesh...@gmail.com wrote: On 5/21/14, Fabian Raetz fabian.ra...@gmail.com wrote: Hi folks, i'm seeing a weird behavour in Firefox 30 beta (it was there already in 29 though). When downloading something, nothing happens. I opened the Show all Downloads Library and saw that there is an entry for the downloaded file but either it is marked as Failed or as Canceled. After clicking the Retry button, the Download starts as expected. For a (long) while I have seen similar issue. I say similar because, even though the Downloads window indicates Failed, the download is inprogress and it completes properly. Same here. Adding me too without providing more information never fixed any bug. Landry
Re: update for print/lilypond
On 23-May 6:53, Matthias Kilian wrote: [resent to ports@] Hi, Based on your diffs, I end up with the diff below. For now, only test-built and packaged on amd64; I'll do some testing with some of my old .ly fikes next weekend. Testbuilds (and real functional tests) on other platforms (at least i386) are welcome, of course. Some more notes: - make port-lib-depends-check compains about some extra libraries (gmodule-2.0.4000 gthread-2.0.4000 iconv.6), but running ldd(1) on the lilypond executable lists them, so I keep them in WANTLIB-main. - there three warnings about %d format strings used for size_t arguments; I did *not* add appropriate patches for now, because at least in one case using %zd would be wrong (that check against the the SCM object 'max-markup-depth'). I'll have to talk to upstream about this. Ciao, Kili I've tested it now on both i386 and amd64 platforms I ran a 50+ page score and a 30+ page Violin Etude book (among other things) on both platforms running current as of the 22nd of May. Of note is that the amd64 platform uses double the memory footprint to compile the document and hits the default ulimit on larger works. Thanks! Graeme
NEW games/dunelegacy
Hi! This one was sitting for a long time in openbsd-wip. Reminded by Edd Barrett with some tweaks from him. Dune Legacy is an effort by a handful of developers to revitalize the first-ever real-time strategy game. The original game was the basis for the hugely successful Command and Conquer series, and the gameplay has been replicated an extended to a wide variety of storylines and series. Note that it requires original Dune 2 data files. Tested for a long time at least by Edd and myself. If noone objects, I'm going to import it. dunelegacy.tar.gz Description: GNU Zip compressed data
Re: NEW games/dunelegacy
hmm, on Mon, May 26, 2014 at 11:47:55AM +0400, Kirill Bychkov said that Dune Legacy is an effort by a handful of developers to revitalize the first-ever real-time strategy game. The original game was the basis for the hugely successful Command and Conquer series, and the gameplay has been replicated an extended to a wide variety of storylines and series. no comment about the port, but strictly speaking dune II was not the first-ever real-time strategy game :) -f -- black holes resulted when MS tried to beat a deadline!
Re: NEW games/dunelegacy
On Mon, May 26, 2014 at 09:57:10AM +0200, frantisek holop wrote: no comment about the port, but strictly speaking dune II was not the first-ever real-time strategy game :) https://github.com/jasperla/openbsd-wip/commit/60077d1638c6b1d575d1e293eb417fc3393a89b7 ;) -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
xscorch core dump on amd64 snapshot
Hi, $ xscorch XScorch version 0.2.1-pre2 Copyright(c) 2000-2004 Justin David Smith Copyright(c) 2000-2009 Jacob Luna Lundberg Licensed under the GNU General Public License, version 2 See the Help menu for the license and a list of contributors. config_file_load: failed to load registry version 2 config_file_load: trying to load using older reader. config_file_load: please update your config file by resaving it. Segmentation fault (core dumped) $ (gdb) bt #0 0x1e14cc0011c4 in gdk_gc_set_foreground () from /usr/local/lib/libgdk-x11-2.0.so.2400.0 #1 0x1e12c1225fc4 in __register_frame_info () from /usr/local/bin/xscorch #2 0x1e12c1225215 in __register_frame_info () from /usr/local/bin/xscorch #3 0x1e12c1217085 in __register_frame_info () from /usr/local/bin/xscorch #4 0x1e12c122c667 in sc_sound_setup_gtk () from /usr/local/bin/xscorch #5 0x1e14c4c8f6db in g_timeout_dispatch () from /usr/local/lib/libglib-2.0.so.4000.0 #6 0x1e14c4c8ede2 in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.4000.0 #7 0x1e14c4c90f0e in g_main_context_iterate () from /usr/local/lib/libglib-2.0.so.4000.0 #8 0x1e14c4c91ea5 in g_main_loop_run () from /usr/local/lib/libglib-2.0.so.4000.0 #9 0x1e14c56f6b31 in gtk_main () from /usr/local/lib/libgtk-x11-2.0.so.2400.0 #10 0x1e12c1209a08 in __register_frame_info () from /usr/local/bin/xscorch #11 0x1e12c1209791 in ?? () from /usr/local/bin/xscorch #12 0x in ?? () (gdb) $ ls -lh xscorch.core -rw--- 1 user user 6.3M May 26 14:35 xscorch.core $ $ pkg_info -c xscorch Information for inst:xscorch-0.2.1p3-pre2 Comment: Scorched Earth-clone $ sysctl kern.version kern.version=OpenBSD 5.5-current (GENERIC.MP) #139: Wed May 21 09:38:42 MDT 2014 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP $ $ sudo pcidump -vx 0:2:0 0:2:0: Intel HD Graphics 4600 0x: Vendor ID: 8086 Product ID: 0416 0x0004: Command: 0007 Status: 0090 0x0008: Class: 03 Subclass: 00 Interface: 00 Revision: 06 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00 0x0010: BAR mem 64bit addr: 0xa000/0x0040 0x0018: BAR mem prefetchable 64bit addr: 0x9000/0x1000 0x0020: BAR io addr: 0x4000/0x0040 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 17aa Product ID: 3801 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 01 Line: 07 Min Gnt: 00 Max Lat: 00 0x0090: Capability 0x05: Message Signaled Interrupts (MSI) 0x00d0: Capability 0x01: Power Management 0x00a4: Capability 0x13: PCI Advanced Features 0x: 04168086 0097 0306 0x0010: a004 900c 0x0020: 4001 380117aa 0x0030: 0090 0107 $ using cwm(1) as window manager. PS: cc me, not subscribed to this list
akpop3d does not work out of the box
The upgrade notes for 5.5 suggest that akpop3d might work as a
replacement for the popa3d that was removed from base. Is there a trick
to using this daemon? akpop3d does not seem to manage locks correctly:
# tail /var/log/maillog
May 23 23:27:16 vm akpop3d[4954]: Connection from 127.0.0.1:27515
May 23 23:27:16 vm akpop3d[6121]: Authenticated eradman
May 23 23:27:21 vm akpop3d[6121]: failed to lock maildrop:
/var/mail/eradman:
File exists
# ls /var/mail/eradman*
-rw--- 1 eradman users 2334 May 3 23:28 eradman
-rw-r- 1 eradman _akpop3d 5 May 26 08:38 eradman.lock
I ended up using solid-pop3d which was trivial to install. I've been
using nginx from ports to provide SSL access:
# pf.conf
block in on ! lo0 proto tcp to port pop3
# nginx.conf
mail {
server_name vm.eradman.com;
auth_http localhost:9000;
proxy on;
ssl_protocols TLSv1 SSLv3;
ssl_certificate /etc/mail/certs/vm.eradman.com.crt;
ssl_certificate_key /etc/mail/certs/vm.eradman.com.key;
pop3_auth plain apop cram-md5;
server {
protocolpop3;
listen 995;
ssl on;
pop3_auth plain;
}
}
--
Eric Radman
Re: firefox download issue
On Wed, May 21, 2014 at 06:42:41PM +0200, Fabian Raetz wrote:
Hi folks,
i'm seeing a weird behavour in Firefox 30 beta (it was there already in
29 though).
When downloading something, nothing happens. I opened the
Show all Downloads Library and saw that there is an entry
for the downloaded file but either it is marked as Failed or as
Canceled. After clicking the Retry button, the Download starts as
expected.
I've recorded a small video which demostrates the issue.
http://mischi.selfhost.bz/Firefox30beta-SafeMode-Download-issue.webm
My first suggestion was, that some AddOns like Vimperator messed
somthing up. But after installing the Beta i reseted all and started
in Safe Mode.
Does anyone else seeing this?
Regards,
Fabian
Hi,
i've started looking through the firefox codebase to eventually fix the
bug. Later today i will create a bug report upstream.
I'm looking for some help in interpreting my test results because
they make not much sense to me (My C skills are not that good atm).
So any help in understanding this further is highly appreciated :)
So here's what i found so far:
In Firefox are basically two components responsible for downloading
files. When downloading files via clicking on an url the relevant
component is the DownloadLegacyTransfer which can be found in the file
toolkit/components/jsdownloads/src/DownloadLegacy.js and this is
the component where things go wrong.
DownloadLegacyTransfer is a XPCOM Component and is used from C++ code.
The C++ code calls the init method which is implemented in javascript
and looks like this:
toolkit/components/jsdownloads/src/DownloadLegacy.js:208
-
init: function DLT_init(aSource,
aTarget,
aDisplayName,
aMIMEInfo,
aStartTime,
aTempFile,
aCancelable,
aIsPrivate)
{
}
---
The parameter aIsPrivate is a boolean which should be true
when we are in a private browsing session otherwise aIsPrivate
should be false.
Badly, on OpenBSD aIsPrivate is somehow always true!!!
This leads to all kind of wrong decisions in the following codepath.
Basically all downloads are associating with a private session,
and these private downloads will not be visualized in a public
session.
This behaviour can be verified by opening a second Firefox Window in
private session mode. Now download a file in either the
normal or the private session window and you will see, that the download
is always visualized in the private session window.
--
So i dig into the C++ side to see why aIsPrivate is always true.
To my surprise the value on the C++ side is correct and is false
when not in a private session.
Here the relevant code snippet that calls the init method:
uriloader/exthandler/nsExternalHelperAppService.cpp:2078
---
...
rv = transfer-Init(mSourceUrl, target, EmptyString(),
mMimeInfo, mTimeDownloadStarted, mTempFile, this,
channel NS_UsePrivateBrowsing(channel));
...
---
So on the C++ side aIsPrivate is false and somehow the JS side
retrives true. Curious! :)
To ease debugging i stored the aIsPrivate expression in a temp variable:
---
...
bool mytest = false;
...
mytest = channel NS_UsePrivateBrowsing(channel);
printf(Right before init: %d\n, mytest);
rv = transfer-Init(mSourceUrl, target, EmptyString(),
mMimeInfo, mTimeDownloadStarted, mTempFile, this,
mytest);
...
---
Huh, after this change, i see correct results on the JS side.
aIsPrivate is now false as it should be. o0
But not always! I test with different files from a OpenBSD snapshot
directory. To me it looks like aIsPrivate is set correctly except in cases
where the downloaded file is too small.
Curious too!
So when downloading base.tgz, install.iso, install.fs they have a
correct aIsPrivate value of false (Both on C++ and JS side).
Downloading xetc.tgz or etc.tgz they have a wrong aIsPrivate value of
true. (On the C++ side, aIsPrivate is false as expected, only the JS
side sees a wrong aIsPrivate of true like before my change.)
So something is weird. Any suggestions what could be wrong
or what to include in the bug report?
Regards,
Fabian
Re: firefox download issue
On Mon, May 26, 2014 at 04:27:52PM +0200, Fabian Raetz wrote:
On Wed, May 21, 2014 at 06:42:41PM +0200, Fabian Raetz wrote:
Hi folks,
i'm seeing a weird behavour in Firefox 30 beta (it was there already in
29 though).
When downloading something, nothing happens. I opened the
Show all Downloads Library and saw that there is an entry
for the downloaded file but either it is marked as Failed or as
Canceled. After clicking the Retry button, the Download starts as
expected.
I've recorded a small video which demostrates the issue.
http://mischi.selfhost.bz/Firefox30beta-SafeMode-Download-issue.webm
My first suggestion was, that some AddOns like Vimperator messed
somthing up. But after installing the Beta i reseted all and started
in Safe Mode.
Does anyone else seeing this?
Regards,
Fabian
Hi,
i've started looking through the firefox codebase to eventually fix the
bug. Later today i will create a bug report upstream.
I'm looking for some help in interpreting my test results because
they make not much sense to me (My C skills are not that good atm).
So any help in understanding this further is highly appreciated :)
So here's what i found so far:
In Firefox are basically two components responsible for downloading
files. When downloading files via clicking on an url the relevant
component is the DownloadLegacyTransfer which can be found in the file
toolkit/components/jsdownloads/src/DownloadLegacy.js and this is
the component where things go wrong.
DownloadLegacyTransfer is a XPCOM Component and is used from C++ code.
The C++ code calls the init method which is implemented in javascript
and looks like this:
toolkit/components/jsdownloads/src/DownloadLegacy.js:208
-
init: function DLT_init(aSource,
aTarget,
aDisplayName,
aMIMEInfo,
aStartTime,
aTempFile,
aCancelable,
aIsPrivate)
{
}
---
The parameter aIsPrivate is a boolean which should be true
when we are in a private browsing session otherwise aIsPrivate
should be false.
Badly, on OpenBSD aIsPrivate is somehow always true!!!
This leads to all kind of wrong decisions in the following codepath.
Basically all downloads are associating with a private session,
and these private downloads will not be visualized in a public
session.
This behaviour can be verified by opening a second Firefox Window in
private session mode. Now download a file in either the
normal or the private session window and you will see, that the download
is always visualized in the private session window.
--
So i dig into the C++ side to see why aIsPrivate is always true.
To my surprise the value on the C++ side is correct and is false
when not in a private session.
Here the relevant code snippet that calls the init method:
uriloader/exthandler/nsExternalHelperAppService.cpp:2078
---
...
rv = transfer-Init(mSourceUrl, target, EmptyString(),
mMimeInfo, mTimeDownloadStarted, mTempFile, this,
channel NS_UsePrivateBrowsing(channel));
...
---
So on the C++ side aIsPrivate is false and somehow the JS side
retrives true. Curious! :)
To ease debugging i stored the aIsPrivate expression in a temp variable:
---
...
bool mytest = false;
...
mytest = channel NS_UsePrivateBrowsing(channel);
printf(Right before init: %d\n, mytest);
rv = transfer-Init(mSourceUrl, target, EmptyString(),
mMimeInfo, mTimeDownloadStarted, mTempFile, this,
mytest);
...
---
Huh, after this change, i see correct results on the JS side.
aIsPrivate is now false as it should be. o0
But not always! I test with different files from a OpenBSD snapshot
directory. To me it looks like aIsPrivate is set correctly except in cases
where the downloaded file is too small.
Curious too!
So when downloading base.tgz, install.iso, install.fs they have a
correct aIsPrivate value of false (Both on C++ and JS side).
Downloading xetc.tgz or etc.tgz they have a wrong aIsPrivate value of
true. (On the C++ side, aIsPrivate is false as expected, only the JS
side sees a wrong aIsPrivate of true like before my change.)
So something is weird. Any suggestions what could be wrong
or what to include in the bug report?
Nice findings! Re-thinking about this, i really think this might loosely
be related to something called OS.File (which, as you can guess by the
name, is a JS API to deal with filesystem access... cf
https://developer.mozilla.org/en-US/docs/JavaScript_OS.File) which
Re: NEW: uhexen2
On Sun, May 25, 2014 at 04:57:37PM +0100, Edd Barrett wrote: On Sun, May 25, 2014 at 09:57:30PM +1000, Jonathan Gray wrote: The binaries were compiled by changing the ENABLE_OLD_RETAIL and ENABLE_OLD_DEMO settings in h2config.h to 1 and then make DEMO=1 It seems the demo pak works without the above hacks.. Or am I missing something? ENABLE_OLD_DEMO is apparently for the original demo. Perhaps there would be some bugs without DEMO=1 with later version of the demo. The flavour could always be added at a later date if needed.
Update: net/transmission 2.83
Update of net/transmission to 2.83. Some of our old patches can
go away and I decided that removing the many warning options isn't
worth the effort.
Untested. It builds, but I've done zero actual data transfers with it.
Does anybody want to take over maintainership of this port? I rarely
use BitTorrent at all these days, and if I do, I only run the daemon
client.
Index: Makefile
===
RCS file: /cvs/ports/net/transmission/Makefile,v
retrieving revision 1.93
diff -u -p -r1.93 Makefile
--- Makefile3 Feb 2014 13:30:52 - 1.93
+++ Makefile26 May 2014 19:11:51 -
@@ -4,10 +4,7 @@ COMMENT-main= BitTorrent command line an
COMMENT-gtk= BitTorrent client with GTK+ interface
COMMENT-qt=BitTorrent client with Qt interface
-VER= 2.82
-REVISION-main= 1
-REVISION-gtk= 1
-REVISION-qt= 0
+VER= 2.83
DISTNAME= transmission-${VER}
PKGNAME-main= transmission-${VER}
PKGNAME-gtk= transmission-gtk-${VER}
@@ -17,7 +14,7 @@ HOMEPAGE= http://www.transmissionbt.com/
MAINTAINER=Christian Weisgerber na...@openbsd.org
-# GPLv2
+# GPLv2+
PERMIT_PACKAGE_CDROM= Yes
MASTER_SITES= http://download.transmissionbt.com/files/
Index: distinfo
===
RCS file: /cvs/ports/net/transmission/distinfo,v
retrieving revision 1.47
diff -u -p -r1.47 distinfo
--- distinfo22 Aug 2013 17:34:33 - 1.47
+++ distinfo26 May 2014 19:11:51 -
@@ -1,2 +1,2 @@
-SHA256 (transmission-2.82.tar.xz) =
OZZlEIffZ6hfHhtKkrG1GN3v3YTGVLjfb7zLC5HwNSI=
-SIZE (transmission-2.82.tar.xz) = 3172024
+SHA256 (transmission-2.83.tar.xz) =
sOGwUBZ+f3G2jgGo1VuYSoKP6IDfmr+8YoHLKg19FDM=
+SIZE (transmission-2.83.tar.xz) = 3136752
Index: patches/patch-configure
===
RCS file: patches/patch-configure
diff -N patches/patch-configure
--- patches/patch-configure 3 Feb 2014 13:30:52 - 1.32
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,48 +0,0 @@
-$OpenBSD: patch-configure,v 1.32 2014/02/03 13:30:52 dcoppa Exp $
-
-Unbreak with miniupnpc=1.9
-
configure.orig Fri Aug 9 04:49:21 2013
-+++ configure Mon Feb 3 13:05:57 2014
-@@ -11800,8 +11800,8 @@ if test 0 = 0; then
- else
- supported_build=no
- if test x$GCC = xyes ; then
--CFLAGS=$CFLAGS -g -O0
--CXXFLAGS=$CXXFLAGS -g -O0
-+: CFLAGS=$CFLAGS -g -O0
-+: CXXFLAGS=$CXXFLAGS -g -O0
- fi
- fi
- if test x$supported_build = xno; then
-@@ -16193,7 +16193,7 @@ esac
-
- if test x$GCC = xyes ; then
-
--CFLAGS=$CFLAGS -std=gnu99 -ggdb3 -Wall -W -Wpointer-arith
-Wformat-security -Wcast-align -Wundef -Wcast-align -Wstrict-prototypes
-Wmissing-declarations -Wmissing-format-attribute -Wredundant-decls
-Wnested-externs -Wunused-parameter -Wwrite-strings -Winline -Wfloat-equal
-+: CFLAGS=$CFLAGS -std=gnu99 -ggdb3 -Wall -W -Wpointer-arith
-Wformat-security -Wcast-align -Wundef -Wcast-align -Wstrict-prototypes
-Wmissing-declarations -Wmissing-format-attribute -Wredundant-decls
-Wnested-externs -Wunused-parameter -Wwrite-strings -Winline -Wfloat-equal
-
- { $as_echo $as_me:${as_lineno-$LINENO}: checking gcc version 5
- $as_echo_n checking gcc version... 6; }
-@@ -16205,10 +16205,10 @@ $as_echo_n checking gcc version... 6; }
- { $as_echo $as_me:${as_lineno-$LINENO}: result: $GCC_VERSION 5
- $as_echo $GCC_VERSION 6; }
- if test $GCC_VERSION_NUM -ge 304; then
--CFLAGS=$CFLAGS -Wextra -Wdeclaration-after-statement
-Winit-self
-+: CFLAGS=$CFLAGS -Wextra -Wdeclaration-after-statement
-Winit-self
- fi
- if test $GCC_VERSION_NUM -ge 403; then
--CFLAGS=$CFLAGS -Wvariadic-macros
-+: CFLAGS=$CFLAGS -Wvariadic-macros
- fi
- fi
-
-@@ -18223,7 +18223,7 @@ main ()
- upnpDiscover( 2000, NULL, NULL, 0, 0, errno );
- UPNP_GetValidIGD( devlist, urls, data, lanaddr, sizeof( lanaddr ) );
- UPNP_GetSpecificPortMappingEntry( urls.controlURL, data.first.servicetype,
--portStr, TCP, intClient, intPort, NULL, NULL, NULL
);
-+portStr, TCP, NULL, intClient, intPort, NULL, NULL,
NULL );
-
- ;
- return 0;
Index: patches/patch-gtk_main_c
===
RCS file: patches/patch-gtk_main_c
diff -N patches/patch-gtk_main_c
--- patches/patch-gtk_main_c18 Nov 2013 16:51:23 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,17 +0,0 @@
-$OpenBSD: patch-gtk_main_c,v 1.1 2013/11/18 16:51:23 naddy Exp $
-
-Disable help entry in menu while the URL returns 404.
-http://www.transmissionbt.com/help/gtk/2.8x/
-
gtk/main.c.origFri Aug 9 04:46:06 2013
-+++ gtk/main.c Mon Nov 18 16:12:09 2013
-@@ -268,6 +268,9 @@ refresh_actions (gpointer gdata)
- canUpdate = 0;
- gtk_tree_selection_selected_foreach
NEW: net/ucspi-tcp
Hi, this is the UCSPI-TCP [0] implementation from Daniel J. Bernstein with the IPv6 Patch [1] from Felix von Leitner. It is a tcpserver and tcpclient program like inetd. It is the tcp socket corresponding port to net/ucspi-unix. This port is similar to the unix socket ucspi port. If any thing is wrong with this port, please tell me. I will fix it. bye, Jan [0] http://cr.yp.to/ucspi-tcp.html [1] http://www.fefe.de/ucspi/ ucspi-tcp.tar.gz Description: application/tar-gz
Re: NEW: net/ucspi-tcp
On 2014/05/26 23:30, Jan Klemkow wrote: Hi, this is the UCSPI-TCP [0] implementation from Daniel J. Bernstein with the IPv6 Patch [1] from Felix von Leitner. It is a tcpserver and tcpclient program like inetd. It is the tcp socket corresponding port to net/ucspi-unix. This port is similar to the unix socket ucspi port. If any thing is wrong with this port, please tell me. I will fix it. bye, Jan [0] http://cr.yp.to/ucspi-tcp.html [1] http://www.fefe.de/ucspi/ that patches directory is a bit extreme... ucspi-tcp/patches/patch-usr_local_man_man1_tcpclient_1 ucspi-tcp/patches/patch-usr_local_man_man1_tcpserver_1 ucspi-tcp/patches/patch-FILES ucspi-tcp/patches/patch-Makefile ucspi-tcp/patches/patch-TARGETS ucspi-tcp/patches/patch-addcr_1 ucspi-tcp/patches/patch-argv0_1 ucspi-tcp/patches/patch-date@_1 ucspi-tcp/patches/patch-delcr_1 ucspi-tcp/patches/patch-dns_h ucspi-tcp/patches/patch-dns_dfd_c ucspi-tcp/patches/patch-dns_domain_c ucspi-tcp/patches/patch-dns_dtda_c ucspi-tcp/patches/patch-dns_ip_c ucspi-tcp/patches/patch-dns_ip6_c ucspi-tcp/patches/patch-dns_ipq_c ucspi-tcp/patches/patch-dns_ipq6_c ucspi-tcp/patches/patch-dns_name_c ucspi-tcp/patches/patch-dns_nd_c ucspi-tcp/patches/patch-dns_nd6_c ucspi-tcp/patches/patch-dns_packet_c ucspi-tcp/patches/patch-dns_random_c ucspi-tcp/patches/patch-dns_rcip_c ucspi-tcp/patches/patch-dns_rcrw_c ucspi-tcp/patches/patch-dns_resolve_c ucspi-tcp/patches/patch-dns_sortip6_c ucspi-tcp/patches/patch-dns_transmit_c ucspi-tcp/patches/patch-dns_txt_c ucspi-tcp/patches/patch-error_h ucspi-tcp/patches/patch-finger@_1 ucspi-tcp/patches/patch-fixcr_1 ucspi-tcp/patches/patch-fmt_xlong_c ucspi-tcp/patches/patch-haveip6_h1 ucspi-tcp/patches/patch-haveip6_h2 ucspi-tcp/patches/patch-hier_c ucspi-tcp/patches/patch-http@_1 ucspi-tcp/patches/patch-ip4_h ucspi-tcp/patches/patch-ip6_h ucspi-tcp/patches/patch-ip6_fmt_c ucspi-tcp/patches/patch-mconnect_1 ucspi-tcp/patches/patch-old-rules_c ucspi-tcp/patches/patch-pathexec_h ucspi-tcp/patches/patch-pathexec_env_c ucspi-tcp/patches/patch-recordio_1 ucspi-tcp/patches/patch-remoteinfo_h ucspi-tcp/patches/patch-remoteinfo6_c ucspi-tcp/patches/patch-rules_c ucspi-tcp/patches/patch-scan_ip6_c ucspi-tcp/patches/patch-scan_xlong_c ucspi-tcp/patches/patch-socket_h ucspi-tcp/patches/patch-socket_bind_c ucspi-tcp/patches/patch-socket_accept6_c ucspi-tcp/patches/patch-socket_bind6_c ucspi-tcp/patches/patch-socket_conn_c ucspi-tcp/patches/patch-socket_conn6_c ucspi-tcp/patches/patch-socket_getifidx_c ucspi-tcp/patches/patch-socket_getifname_c ucspi-tcp/patches/patch-socket_ip4loopback_c ucspi-tcp/patches/patch-socket_local6_c ucspi-tcp/patches/patch-socket_recv6_c ucspi-tcp/patches/patch-socket_remote6_c ucspi-tcp/patches/patch-socket_send6_c ucspi-tcp/patches/patch-socket_tcp6_c ucspi-tcp/patches/patch-socket_udp6_c ucspi-tcp/patches/patch-socket_v4mappedprefix_c ucspi-tcp/patches/patch-socket_v6any_c ucspi-tcp/patches/patch-socket_v6loopback_c ucspi-tcp/patches/patch-str_h ucspi-tcp/patches/patch-str_chr_c ucspi-tcp/patches/patch-str_diff_c ucspi-tcp/patches/patch-str_len_c ucspi-tcp/patches/patch-str_start_c ucspi-tcp/patches/patch-stralloc_h ucspi-tcp/patches/patch-stralloc_catb_c ucspi-tcp/patches/patch-stralloc_cats_c ucspi-tcp/patches/patch-stralloc_opyb_c ucspi-tcp/patches/patch-stralloc_opys_c ucspi-tcp/patches/patch-tcp-environ_5 ucspi-tcp/patches/patch-tcpcat_1 ucspi-tcp/patches/patch-tcpclient_1 ucspi-tcp/patches/patch-tcpclient_c ucspi-tcp/patches/patch-tcprules_1 ucspi-tcp/patches/patch-tcprules_c ucspi-tcp/patches/patch-tcprulescheck_1 ucspi-tcp/patches/patch-tcpserver_1 ucspi-tcp/patches/patch-tcpserver_c ucspi-tcp/patches/patch-timeoutconn_h ucspi-tcp/patches/patch-timeoutconn6_c ucspi-tcp/patches/patch-tryip6_c ucspi-tcp/patches/patch-who@_1
