Re: [FIX] make productivity/taskd install proper vars file

[Kent R. Spillner]

On Mon, Feb 08, 2016 at 08:11:22AM +0100, viq wrote:
> Bump

Hrrmmm, the mail I sent about this last week never made it to the list.
I would prefer to commit this fix.

Ok?

Index: Makefile
===
RCS file: /work/cvsroot/ports/productivity/taskd/Makefile,v
retrieving revision 1.5
diff -p -u -r1.5 Makefile
--- Makefile28 Jan 2016 17:15:00 -  1.5
+++ Makefile8 Feb 2016 15:49:27 -
@@ -4,6 +4,7 @@ COMMENT =   lightweight server providing a
 
 DISTNAME = taskd-1.1.0
 CATEGORIES =   productivity net
+REVISION = 0
 
 HOMEPAGE = http://www.taskwarrior.org/
 
@@ -41,6 +42,8 @@ post-install:
${PREFIX}/share/examples/taskd/pki/
${INSTALL_DATA} ${WRKSRC}/pki/README \
${PREFIX}/share/examples/taskd/pki/
+   ${INSTALL_DATA} ${WRKSRC}/pki/vars \
+   ${PREFIX}/share/examples/taskd/pki/vars.dist
${SUBST_DATA} ${FILESDIR}/config \
${PREFIX}/share/examples/taskd/config
 
Index: pkg/PLIST
===
RCS file: /work/cvsroot/ports/productivity/taskd/pkg/PLIST,v
retrieving revision 1.3
diff -p -u -r1.3 PLIST
--- pkg/PLIST   28 Jan 2016 17:15:05 -  1.3
+++ pkg/PLIST   8 Feb 2016 15:49:54 -
@@ -35,6 +35,7 @@ share/examples/taskd/pki/generate.ca
 share/examples/taskd/pki/generate.client
 share/examples/taskd/pki/generate.crl
 share/examples/taskd/pki/generate.server
+share/examples/taskd/pki/vars.dist
 @sample share/examples/taskd/pki/vars
 share/taskd/
 share/taskd/AUTHORS

Re: libvirt pulls wireshark

[Jasper Lievisse Adriaanse]

On Sun, Feb 07, 2016 at 06:06:48PM -0500, Jiri B wrote:
> We need to explicitly disable pulling of wireshark inside libvirt port
> or if not, libvirt port should has subpackage (as Fedora[1] does) for
> wireshark dissector plugin (IMO not much used on OpenBSD).
> 
> j.
Thanks, I'll handle it. The diff is not right as the REVISION bump is not
needed (for the package doesn't change). I agree there's little point in
adding a wireshark subpackage, at least I've never had any need for it.
 
> [1] https://pkgs.fedoraproject.org/cgit/rpms/libvirt.git/tree/libvirt.spec
> 
> ...
> configure: wireshark_dissector: yes (CFLAGS='-I/usr/local/include/wireshark' 
> LIBS='-L/usr/local/lib -lwireshark')
> ...
> configure: Wireshark dissector: yes
> ...
> mkdir -p wireshark/src/libvirt
> cd wireshark/src && \
> LIBVIRT_VERSION=1.3.1 \
>   /usr/bin/perl 
> /home/jirib/openbsd/pobj/libvirt-1.3.1/libvirt-1.3.1/tools/wireshark/util/genxdrstub.pl
>  \
>   
> /home/jirib/openbsd/pobj/libvirt-1.3.1/libvirt-1.3.1/src/remote/remote_protocol.x
>  
> /home/jirib/openbsd/pobj/libvirt-1.3.1/libvirt-1.3.1/src/remote/qemu_protocol.x
>  
> /home/jirib/openbsd/pobj/libvirt-1.3.1/libvirt-1.3.1/src/remote/lxc_protocol.x
>  
> /home/jirib/openbsd/pobj/libvirt-1.3.1/libvirt-1.3.1/src/rpc/virkeepaliveprotocol.x
> Use of uninitialized value in subroutine entry at 
> /home/jirib/openbsd/pobj/libvirt-1.3.1/libvirt-1.3.1/tools/wireshark/util/genxdrstub.pl
>  line 580.
> Cannot open file /libvirt/remote.h: No such file or directory at 
> /home/jirib/openbsd/pobj/libvirt-1.3.1/libvirt-1.3.1/tools/wireshark/util/genxdrstub.pl
>  line 581.
> Makefile:3200: recipe for target 'wireshark/src/libvirt/protocol.h' failed
> gmake[3]: *** [wireshark/src/libvirt/protocol.h] Error 2
> gmake[3]: Leaving directory 
> '/home/jirib/openbsd/pobj/libvirt-1.3.1/libvirt-1.3.1/tools'
> Makefile:2105: recipe for target 'all' failed
> gmake[2]: *** [all] Error 2
> gmake[2]: Leaving directory 
> '/home/jirib/openbsd/pobj/libvirt-1.3.1/libvirt-1.3.1/tools'
> Makefile:2004: recipe for target 'all-recursive' failed
> gmake[1]: *** [all-recursive] Error 1
> gmake[1]: Leaving directory 
> '/home/jirib/openbsd/pobj/libvirt-1.3.1/libvirt-1.3.1'
> Makefile:1899: recipe for target 'all' failed
> gmake: *** [all] Error 2
> *** Error 2 in . 
> (/home/jirib/cvs/openbsd-ports/infrastructure/mk/bsd.port.mk:2773 
> '/home/jirib/openbsd/pobj/libvirt-1.3.1/.build_done')
> *** Error 1 in /usr/ports/sysutils/libvirt 
> (/home/jirib/cvs/openbsd-ports/infrastructure/mk/bsd.port.mk:2495 'all')
>   
> ~~~
> Index: Makefile
> ===
> RCS file: /cvs/ports/sysutils/libvirt/Makefile,v
> retrieving revision 1.46
> diff -u -p -r1.46 Makefile
> --- Makefile17 Jan 2016 14:25:12 -  1.46
> +++ Makefile7 Feb 2016 23:05:05 -
> @ -3,7 +3,7 @@
>  COMMENT=   tool/library for managing platform virtualization
>  
>  DISTNAME=  libvirt-1.3.1
> -REVISION=  0
> +REVISION=  1
>  CATEGORIES=sysutils devel
>  
>  SHARED_LIBS += virt-qemu 0.4 # 1003.0
> @ -49,6 +49,7 @@ CONFIGURE_ARGS+=  ${CONFIGURE_SHARED} \
> --without-netcf \
> --without-network \
> --without-login-shell \
> +   --without-wireshark-dissector \
>  # OpenBSD can't act as a virtualization host, so no need for libvirtd.
>  # If support is added, subtitute /var/lib/{xen,virt,libvirt,...} with /var/db
>  CONFIGURE_ARGS+=   --without-libvirtd
> ~~~
> 

-- 
jasper

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2016/02/08 01:12:47

Modified files:
sysutils/libvirt: Makefile 

Log message:
explicitly disable wireshark dissector so it won't get picked up at configure 
time

found the hard way by jiri b

Re: Update net/mcabber to 1.0.1 - was (Re: Call for help updating a port (net/mcabber).)

[Markus Hennecke]

On Mon, 8 Feb 2016, Christoph R. Murauer wrote:

> > You'll learn soon that sending patches as attachments is a wonderful
> > way to get people angry.
> 
> Sorry, was not my intention. I saw often attachments so, I thought it
> is the prefered way. I also like inline things more.
> 
> > These lines were in PLIST on purpose.  If "make update-plist" deletes
> > them, you should take care to re-add them.
> >
> > Otherwise this update seems fine.
> 
> As it was my first patch ever, I did it from scratch (the plist part
> was my fault).

Looks good!

 
> Index: Makefile
> ===
> RCS file: /cvs/ports/net/mcabber/Makefile,v
> retrieving revision 1.23
> diff -u -p -r1.23 Makefile
> --- Makefile  10 Nov 2015 20:38:19 -  1.23
> +++ Makefile  8 Feb 2016 01:32:50 -
> @@ -3,7 +3,7 @@
>  SHARED_ONLY= Yes
> 
>  COMMENT= console jabber client
> -DISTNAME=mcabber-1.0.0
> +DISTNAME=mcabber-1.0.1
>  CATEGORIES=  net
> 
>  HOMEPAGE=http://mcabber.com/
> Index: distinfo
> ===
> RCS file: /cvs/ports/net/mcabber/distinfo,v
> retrieving revision 1.10
> diff -u -p -r1.10 distinfo
> --- distinfo  10 Nov 2015 20:38:19 -  1.10
> +++ distinfo  8 Feb 2016 01:32:50 -
> @@ -1,2 +1,2 @@
> -SHA256 (mcabber-1.0.0.tar.bz2) =
> VHa8ujleC5Ungj9am85yUVF1b2hc4tz2+tPb5QoVcDI=
> -SIZE (mcabber-1.0.0.tar.bz2) = 602173
> +SHA256 (mcabber-1.0.1.tar.bz2) =
> V5pForyURFUBLKmzCPfzRU76u+DDbGcjr3YaofMJLZM=
> +SIZE (mcabber-1.0.1.tar.bz2) = 604661
> 
> 
> 
> 

CVS: cvs.openbsd.org: ports

[Juan Francisco Cantero Hurtado]

CVSROOT:/cvs
Module name:ports
Changes by: juan...@cvs.openbsd.org 2016/02/08 18:33:39

Modified files:
lang/racket: Tag: OPENBSD_5_7 Makefile 
Added files:
lang/racket/patches: Tag: OPENBSD_5_7 
 
patch-share_pkgs_web-server-lib_web-server_dispatchers_filesystem-map_rkt 

Log message:
SECURITY: Fix a vulnerability in the Racket web server.

http://article.gmane.org/gmane.comp.lang.racket.user/30142

CVS: cvs.openbsd.org: ports

[Juan Francisco Cantero Hurtado]

CVSROOT:/cvs
Module name:ports
Changes by: juan...@cvs.openbsd.org 2016/02/08 19:02:49

Modified files:
lang/gambit: Makefile 

Log message:
Remove the comment. The workaround fixed the build.

update: databases/pgbadger 3.5 to 7.3

[Abel Abraham Camarillo Ojeda]

hi

attached patch updates pgbadger,
also I'd like to take maintainership if no one
cares.
I'm unsure about the PLIST change, tough...

comments, ok?

thanks.
Index: Makefile
===
RCS file: /cvs/ports/databases/pgbadger/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile10 Aug 2013 16:07:50 -  1.1.1.1
+++ Makefile9 Feb 2016 03:56:02 -
@@ -2,15 +2,20 @@
 
 COMMENT =  advanced PostgreSQL log analyzer
 
-DISTNAME = pgbadger-3.5
+DISTNAME = pgbadger-7.3
 CATEGORIES =   databases
 
 HOMEPAGE = http://dalibo.github.io/pgbadger/
+MAINTAINER =   Abel Abraham Camarillo Ojeda 
 
-# GPLv2
+# same as postgres:
+# BSD
 PERMIT_PACKAGE_CDROM = Yes
 
-MASTER_SITES = ${MASTER_SITE_SOURCEFORGE:=pgbadger/}
+GH_ACCOUNT =   dalibo
+GH_PROJECT =   pgbadger
+GH_TAGNAME =   v7.3
+
 CONFIGURE_STYLE =  perl
 
 .include 
Index: distinfo
===
RCS file: /cvs/ports/databases/pgbadger/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo10 Aug 2013 16:07:50 -  1.1.1.1
+++ distinfo9 Feb 2016 03:56:02 -
@@ -1,2 +1,2 @@
-SHA256 (pgbadger-3.5.tar.gz) = XSVgI+Yvc7DC+9v0eNqvYyrEe35dstuPYb+W1cFNT+U=
-SIZE (pgbadger-3.5.tar.gz) = 106899
+SHA256 (pgbadger-7.3.tar.gz) = 6nCOu339xNy2vc9fMz4CGLw5RjGrHr5nA/3WzsUjQsE=
+SIZE (pgbadger-7.3.tar.gz) = 334483
Index: pkg/PLIST
===
RCS file: /cvs/ports/databases/pgbadger/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- pkg/PLIST   10 Aug 2013 16:07:50 -  1.1.1.1
+++ pkg/PLIST   9 Feb 2016 03:56:02 -
@@ -1,3 +1,3 @@
 @comment $OpenBSD: PLIST,v 1.1.1.1 2013/08/10 16:07:50 landry Exp $
 bin/pgbadger
-@man man/man1/pgbadger.1
+@man man/man1/pgbadger.1p

xstatbar memory leak

[Stuart Henderson]

I just noticed xstatbar using "quite a lot" more memory than I was
expecting. Does anyone fancy trying to track down the leak? It doesn't
look like any flags are needed to trigger the leak, but using "-s 0"
to avoid sleeping between updates makes it very easy to spot.

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2016/02/08 19:31:23

Modified files:
security/clamav: Makefile 
security/clamav/patches: patch-etc_clamd_conf_sample 

Log message:
uncomment the "User _clamav" line in sample config.

clamd won't run without editing this file anyway, but in case somebody
doesn't notice this line while reviewing the file, use a better default.

CVS: cvs.openbsd.org: ports

[Masao Uebayashi]

CVSROOT:/cvs
Module name:ports
Changes by: uebay...@cvs.openbsd.org2016/02/08 20:36:58

Modified files:
sysutils/ipmitool: Makefile 
Added files:
sysutils/ipmitool/patches: patch-src_plugins_open_open_h 

Log message:
Adapt to newly added ipmi(4) cdev on amd64 and i386.

OK sthen@

Re: Fix fd_set usage in Qt4

[Theo de Raadt]

>This fixes stack smashing I've seen in Okteta.
>
>The problem is that fd_set by default uses limit (FD_SETSIZE) of 1024,
>unless FD_SETSIZE is set before including the  header.
>The Qt4 source code contains some checks, but backtrace from GDB tells
>they're not enough. Instead of spending time on looking what's missed,
>I've just replaced select(2) with poll(2). Given that code actually
>shrunk, and I see no crashes anymore, I think it should go in.
>
>I suppose this could be a security issue, as you could somehow trigger
>stack smashing, but I can't see anything harder than local DoS for now.
>But this could be different for some Qt-based apps. There are more
>select(2) calls which I'm willing to tweak before, though. This patch
>just fixes a problem I faced.
>
>Remember that Qt4 is EOL, so we don't have to bother about pushing
>those patches upstream. On the other side, Qt5 wants same treatment.
>Not sure that all platforms Qt5 runs on support poll(2) correctly,
>though.

Shocking.

(I have been talking about fd_set overflows for almost 15 years, and a
few people helped me fix our entire base tree around that time)

Re: [PATCH] Fix duplicity manpage

[Jérémie Courrèges-Anglas]

tro...@kagu-tsuchi.com writes:

> Seems that with the change to duplicity 0.7, the default sftp backend changed.
> The manpage was being patched to say the default was pexpect over paramiko.
> This is no longer true.  Remove the manpage changes.

Was there a rationale for changing the default again?

> Not sure if the REVISION needs to be bumped or not for this.

It would.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: Firefox 44 font change

[Christian Weisgerber]

On 2016-02-07, Landry Breuil  wrote:

> A quick look at the 'list of bugs fixed in this release' (link at the
> bottom of the page) yields to some fontconfig-related bugs like
> https://bugzilla.mozilla.org/show_bug.cgi?id=1180560

Yes, that's it.
Switching gfx.font_rendering.fontconfig.fontlist.enabled back to false
restores the previous behavior.

"To support the unicode-range descriptor for webfonts, font matching
under Linux now uses the same font matching code shared with other
platforms. On Linux, this code uses fontconfig for platform font
family lookups so font substitutions will still work. But in some
cases complex font substitution rules may no longer work as they
did before. Please file a bug if you run into a problem with Firefox
not respecting a given fontconfig configuration."

I admit, I have no idea what's intended and what's a bug here.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: make does not cp/link to CDROM_SITE properly if DIST_SUBDIR used

[Stuart Henderson]

On 2016/02/08 12:44, dan mclaughlin wrote:
> i am assuming that the distfiles on the cdrom preserve the same structure
> as on the ftp sites and also created during builds.

This won't have been noticed because there are no distfiles on the
cdrom, PERMIT_DISTFILES_CDROM is no longer permitted in a port, so it
would probably make sense to get rid of CDROM_SITE support as well.

> to illustrate:
> 
> $ env CDROM_SITE=/home/olddistfiles DISTDIR=/home/distfiles make fetch
> ===>  Checking files for bash-4.3.42
> cp: /home/olddistfiles/bash-4.3.30.tar.gz: No such file or directory
> >> Fetch http://ftpmirror.gnu.org/bash/bash-4.3.30.tar.gz
> bash-4.3.30.tar.gz 100% |***|  7790 KB00:10
> cp: /home/olddistfiles/bash43-031: No such file or directory
> >> Fetch http://ftpmirror.gnu.org/bash/bash-4.3-patches/bash43-031
> bash43-031   100% |*|  3689   00:00
> ...

For what I think you're trying to do, you can use MASTER_SITE_BACKUP
and MASTER_SITE_OVERRIDE to file:///home/olddistfiles/${DIST_SUBDIR}

CVS: cvs.openbsd.org: ports

[Landry Breuil]

CVSROOT:/cvs
Module name:ports
Changes by: lan...@cvs.openbsd.org  2016/02/08 12:22:56

ports/graphics/gegl03/patches

Update of /cvs/ports/graphics/gegl03/patches
In directory cvs.openbsd.org:/tmp/cvs-serv19238/patches

Log Message:
Directory /cvs/ports/graphics/gegl03/patches added to the repository

CVS: cvs.openbsd.org: ports

[Landry Breuil]

CVSROOT:/cvs
Module name:ports
Changes by: lan...@cvs.openbsd.org  2016/02/08 12:28:47

Added files:
graphics/gegl03/patches: patch-operations_external_tiff-load_c 

Log message:
Fix build on big-endian archs by correcting a typo in a probably never
tested big-endian only codepath.. sigh. Tested on macppc & sparc64.

Re: NEW: www/tbb - Tor Browser Bundle

[attila]

Landry Breuil  writes:

> On Mon, Nov 16, 2015 at 09:07:46AM -0600, attila wrote:
>> 
>> attila  writes:
>> 
>> > attila  writes:
>> >
>> >> attila  writes:
>> >>
>> >>> attila  writes:
>> >>>
>>  attila  writes:
>> 
>> > Hi ports@,
>> >
>> > I have been informed that my previous email re Tor Browser Bundle was
>> > malformed: the Content-Type header on the message says text/plain but
>> > should be multipart/mixed, which causes many (most?) MUAs to throw up
>> > all over it.  I'm not sure where the fault lies yet, and apologize for
>> > the screwed up attachment.
>> >
>> > In the interests of simplicity and efficacy the tarball can be found
>> > here: http://bits.haqistan.net/~attila/tbb.tgz
>> >
>> > Sorry.
>> >
>> > Pax, -A
>> 
>>  I've updated http://bits.haqistan.net/~attila/tbb.tgz with the
>>  just-completed update to Tor Browser 4.5.3.  Tested on amd64.
>> 
>>  So... update & ping.
>> 
>>  Pax, -A
>> >>>
>> >>> Reupdate & reping:
>> >>>
>> >>> I brought the ports up to the current version, which is now 5.0.3.
>> >>> I've also solved my attachment woes; updated ports attached (URL above
>> >>> has new bits as well).  Tested on amd64.  There are packages available
>> >>> for testing at:
>> >>> http://mirrors.nycbug.org/pub/snapshots/packages/amd64/
>> >>> The README file there might be helpful if you want to test.
>> >>>
>> >>> FWIW, the GH repository is: https://github.com/torbsd/openbsd-ports
>> >>> YMMV.
>> >>>
>> >>> Pax, -A
>> >>
>> >> Re-reupdate & re-reping:
>> >>
>> >> Thanks to Daniel Jakots for pointing out that the inter-package
>> >> dependencies were all balled up and led to problems.  Updated ports
>> >> attached with better deps, updated packages for testing available at
>> >> the nycbug URL, above.
>> >>
>> >> Pax, -A
>> >
>> > Re*ping.  I know some people have been using the packages we put up
>> > for testing purposes.  I also know this is potentially sort of a
>> > controversial (set of) port(s) and that everyone is busy but if anyone
>> > could be troubled to take a look and give some feedback that would
>> > be great.
>> >
>> > Attaching the latest version of the ports for completeness.
>> >
>> > Pax, -A
>> 
>> Ping.
>
> I had a quick look a while ago at the Makefile. I would *really* prefer
> you to shrink it by reusing www/mozilla MODULE, provided you work out
> the correct changes that would be needed for tbb without breaking the
> other users of the module. Instead of copy-pasting-cargo-culting what's
> in the module...

Okay, finally, I have done at least this much.  The attached update to
the five ports is mostly about switching to the www/mozilla MODULE,
thanks to your patch for bundled nss.  It also brings us up to TBB
5.5.  Tested on amd64 with whatever the latest snapshot was on 5 Feb
(don't recall now, don't have amd64 handy ATM :-()

> Is the .mozconfig hackery really needed ?

The @CONFIG_GUESS@ token in .mozconfig does not seem to get s///'ed
correctly by autoconf.  I don't have my build machine available right
now but I seem to recall that firefox-esr doesn't ship with a
.mozconfig file, but Tor browser does... could be wrong.  When I get
my buildbox back I'll look at this again.  I'm guessing that this hack
and the other post-extract sed hack for baseconfig.mk can be sussed
out and turned into patches for upstream instead.

> The @exec lines in the PLIST should go at the bottom.

Done.

> I think you dont need files/firefox.desktop, and do you really need
> files/profiles.ini ?

This is tor-browser.desktop now.  The profiles.ini file is
unfortunately necessary given the way I pre-populate ~/.tor-browser
but if there's a better way... this is just how they do it in the
bundle.

> Have you tried leaving the .xpi files compressed in their respective
> dirs at runtime (eventually unzipping/patching/rezipping) as you comment
> in Makefile.inc line 68 ? Iirc this should also work and is 'nicer' to
> the filesystem..

I finally just grokked in fullness what you were saying here (sorry, a
bit slow).  Given that I already have a start-tor-browser shell script
in place to set things up we could instead switch to having .xpi files
in distribution/extensions (or wherever) and unpack them when
~/.tor-browser is populated.  I'm sorry I didn't get to it before now,
maybe the rest of what I've done can be critiqued and I'll make this
change and test it when I get my buildbox back.

> I'm still not a fan of having this in-tree, but i'd like opinions from
> other porters & tor users (users, not fanboys please) here - especially
> pascal since he's the tor maintainer :)

I'd really like those opinions, too, if they're out there...

There are packages for amd64 available for testing:

Re: NEW: www/tbb - Tor Browser Bundle

[attila]

attila  writes:

> Landry Breuil  writes:
>
>> On Mon, Nov 16, 2015 at 09:07:46AM -0600, attila wrote:
>>> 
>>> attila  writes:
>>> 
>>> > attila  writes:
>>> >
>>> >> attila  writes:
>>> >>
>>> >>> attila  writes:
>>> >>>
>>>  attila  writes:
>>> 
>>> > Hi ports@,
>>> >
>>> > I have been informed that my previous email re Tor Browser Bundle was
>>> > malformed: the Content-Type header on the message says text/plain but
>>> > should be multipart/mixed, which causes many (most?) MUAs to throw up
>>> > all over it.  I'm not sure where the fault lies yet, and apologize for
>>> > the screwed up attachment.
>>> >
>>> > In the interests of simplicity and efficacy the tarball can be found
>>> > here: http://bits.haqistan.net/~attila/tbb.tgz
>>> >
>>> > Sorry.
>>> >
>>> > Pax, -A
>>> 
>>>  I've updated http://bits.haqistan.net/~attila/tbb.tgz with the
>>>  just-completed update to Tor Browser 4.5.3.  Tested on amd64.
>>> 
>>>  So... update & ping.
>>> 
>>>  Pax, -A
>>> >>>
>>> >>> Reupdate & reping:
>>> >>>
>>> >>> I brought the ports up to the current version, which is now 5.0.3.
>>> >>> I've also solved my attachment woes; updated ports attached (URL above
>>> >>> has new bits as well).  Tested on amd64.  There are packages available
>>> >>> for testing at:
>>> >>> http://mirrors.nycbug.org/pub/snapshots/packages/amd64/
>>> >>> The README file there might be helpful if you want to test.
>>> >>>
>>> >>> FWIW, the GH repository is: https://github.com/torbsd/openbsd-ports
>>> >>> YMMV.
>>> >>>
>>> >>> Pax, -A
>>> >>
>>> >> Re-reupdate & re-reping:
>>> >>
>>> >> Thanks to Daniel Jakots for pointing out that the inter-package
>>> >> dependencies were all balled up and led to problems.  Updated ports
>>> >> attached with better deps, updated packages for testing available at
>>> >> the nycbug URL, above.
>>> >>
>>> >> Pax, -A
>>> >
>>> > Re*ping.  I know some people have been using the packages we put up
>>> > for testing purposes.  I also know this is potentially sort of a
>>> > controversial (set of) port(s) and that everyone is busy but if anyone
>>> > could be troubled to take a look and give some feedback that would
>>> > be great.
>>> >
>>> > Attaching the latest version of the ports for completeness.
>>> >
>>> > Pax, -A
>>> 
>>> Ping.
>>
>> I had a quick look a while ago at the Makefile. I would *really* prefer
>> you to shrink it by reusing www/mozilla MODULE, provided you work out
>> the correct changes that would be needed for tbb without breaking the
>> other users of the module. Instead of copy-pasting-cargo-culting what's
>> in the module...
>
> Okay, finally, I have done at least this much.  The attached update to
> the five ports is mostly about switching to the www/mozilla MODULE,
> thanks to your patch for bundled nss.  It also brings us up to TBB
> 5.5.  Tested on amd64 with whatever the latest snapshot was on 5 Feb
> (don't recall now, don't have amd64 handy ATM :-()
>

As per ancient custom, I forgot the frigging tarball... attached here.

>> Is the .mozconfig hackery really needed ?
>
> The @CONFIG_GUESS@ token in .mozconfig does not seem to get s///'ed
> correctly by autoconf.  I don't have my build machine available right
> now but I seem to recall that firefox-esr doesn't ship with a
> .mozconfig file, but Tor browser does... could be wrong.  When I get
> my buildbox back I'll look at this again.  I'm guessing that this hack
> and the other post-extract sed hack for baseconfig.mk can be sussed
> out and turned into patches for upstream instead.
>
>> The @exec lines in the PLIST should go at the bottom.
>
> Done.
>
>> I think you dont need files/firefox.desktop, and do you really need
>> files/profiles.ini ?
>
> This is tor-browser.desktop now.  The profiles.ini file is
> unfortunately necessary given the way I pre-populate ~/.tor-browser
> but if there's a better way... this is just how they do it in the
> bundle.
>
>> Have you tried leaving the .xpi files compressed in their respective
>> dirs at runtime (eventually unzipping/patching/rezipping) as you comment
>> in Makefile.inc line 68 ? Iirc this should also work and is 'nicer' to
>> the filesystem..
>
> I finally just grokked in fullness what you were saying here (sorry, a
> bit slow).  Given that I already have a start-tor-browser shell script
> in place to set things up we could instead switch to having .xpi files
> in distribution/extensions (or wherever) and unpack them when
> ~/.tor-browser is populated.  I'm sorry I didn't get to it before now,
> maybe the rest of what I've done can be critiqued and I'll make this
> change and test it when I get my buildbox back.
>
>> I'm still not a fan of having this in-tree, but i'd like opinions from
>> other porters & tor users (users, 

make does not cp/link to CDROM_SITE properly if DIST_SUBDIR used

[dan mclaughlin]

i am assuming that the distfiles on the cdrom preserve the same structure
as on the ftp sites and also created during builds.

to illustrate:

$ env CDROM_SITE=/home/olddistfiles DISTDIR=/home/distfiles make fetch
===>  Checking files for bash-4.3.42
cp: /home/olddistfiles/bash-4.3.30.tar.gz: No such file or directory
>> Fetch http://ftpmirror.gnu.org/bash/bash-4.3.30.tar.gz
bash-4.3.30.tar.gz 100% |***|  7790 KB00:10
cp: /home/olddistfiles/bash43-031: No such file or directory
>> Fetch http://ftpmirror.gnu.org/bash/bash-4.3-patches/bash43-031
bash43-031   100% |*|  3689   00:00
...


i modified the makefile to echo what it is doing:

$ env CDROM_SITE=/home/olddistfiles DISTDIR=/home/distfiles make fetch
===>  Checking files for bash-4.3.42
cd /home/distfiles/bash
test -f bash-4.3.30.tar.gz && exit 0
if cp -f /home/olddistfiles/bash-4.3.30.tar.gz .; then exit 0; fi
cp: /home/olddistfiles/bash-4.3.30.tar.gz: No such file or directory
>> Fetch http://ftpmirror.gnu.org/bash/bash-4.3.30.tar.gz
bash-4.3.30.tar.gz 100% |***|  7790 KB00:14
cd /home/distfiles/bash
test -f bash43-031 && exit 0
if cp -f /home/olddistfiles/bash43-031 .; then exit 0; fi
cp: /home/olddistfiles/bash43-031: No such file or directory
>> Fetch http://ftpmirror.gnu.org/bash/bash-4.3-patches/bash43-031
bash43-031   100% |*|  3689   00:00


when checking for existing files, it changes to the directory the files
should be in ie FULLDISTDIR, $DISTDIR/bash in the above case.


if CDROM_SITE used, then the code below is run

.  if defined(FETCH_SYMLINK_DISTFILES)
_CDROM_OVERRIDE = if ln -s ${CDROM_SITE}/$$f .; then exit 0; fi
.  else
_CDROM_OVERRIDE = if cp -f ${CDROM_SITE}/$$f .; then exit 0; fi
.  endif


via
f=$f; \
${_CDROM_OVERRIDE}; \


the problem is that the file it tries to copy or link to is the filename
in DISTDIR, not FULLDISTDIR.

so in the case of bash, it tries

'cp -f ${CDROM_SITE}/bash-4.3.30.tar.gz'

instead of

'cp -f ${CDROM_SITE}/bash/bash-4.3.30.tar.gz'


the fix is trivial:

--- infrastructure/mk/bsd.port.mk.orig  Thu Jan  7 04:25:02 2016
+++ infrastructure/mk/bsd.port.mk   Mon Feb  8 12:37:24 2016
@@ -2960,7 +2960,7 @@ ${DISTDIR}/$p:
@lock=${@:T}.dist; ${_SIMPLE_LOCK}; install -d ${DISTDIR_MODE} ${@:H}; \
cd ${@:H}; \
test -f ${@:T} && exit 0; \
-   f=$f; \
+   f=$p; \
${_CDROM_OVERRIDE}; \
for site in ${$m}; do \
file=$@.part; \


run again with the above change, and echo statements:

$ env DISTDIR=/home/distfiles CDROM_SITE=/home/olddistfiles make fetch
===>  Checking files for bash-4.3.42
cd /home/distfiles/bash
test -f bash-4.3.30.tar.gz && exit 0
if cp -f /home/olddistfiles/bash/bash-4.3.30.tar.gz .; then exit 0; fi
cd /home/distfiles/bash
test -f bash43-031 && exit 0
if cp -f /home/olddistfiles/bash/bash43-031 .; then exit 0; fi

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2016/02/08 12:07:44

Modified files:
net/icinga/core2: Makefile 

Log message:
mark BROKEN-powerpc to avoid wasting build time; linker issues.

`.gnu.linkonce.t._ZN6icinga5ValueC1EPNS_6ObjectE' referenced in section 
`.gnu.linkonce.r._ZN6icinga5ValueC1EPNS_6ObjectE' of 
lib/base/CMakeFiles/base.dir/boolean-script.cpp.o: defined in discarded section 
`.gnu.linkonce.t._ZN6icinga5ValueC1EPNS_6ObjectE' of 
lib/base/CMakeFiles/base.dir/boolean-script.cpp.o

Re: make does not cp/link to CDROM_SITE properly if DIST_SUBDIR used

[dan mclaughlin]

On Mon, 8 Feb 2016 18:09:06 + Stuart Henderson  wrote:
> On 2016/02/08 12:44, dan mclaughlin wrote:
> > i am assuming that the distfiles on the cdrom preserve the same structure
> > as on the ftp sites and also created during builds.
> 
> This won't have been noticed because there are no distfiles on the
> cdrom, PERMIT_DISTFILES_CDROM is no longer permitted in a port, so it
> would probably make sense to get rid of CDROM_SITE support as well.
> 
> > to illustrate:
> > 
> > $ env CDROM_SITE=/home/olddistfiles DISTDIR=/home/distfiles make fetch
> > ===>  Checking files for bash-4.3.42
> > cp: /home/olddistfiles/bash-4.3.30.tar.gz: No such file or directory
> > >> Fetch http://ftpmirror.gnu.org/bash/bash-4.3.30.tar.gz
> > bash-4.3.30.tar.gz 100% |***|  7790 KB00:10
> > cp: /home/olddistfiles/bash43-031: No such file or directory
> > >> Fetch http://ftpmirror.gnu.org/bash/bash-4.3-patches/bash43-031
> > bash43-031   100% |*|  3689   00:00
> > ...
> 
> For what I think you're trying to do, you can use MASTER_SITE_BACKUP
> and MASTER_SITE_OVERRIDE to file:///home/olddistfiles/${DIST_SUBDIR}
> 

that may be what i want, though i usually use FETCH_SYMLINK_DISTFILES so
they don't get copied, which from what i can tell can't be done with
MASTER_SITE_*. (i'll work around that if CDROM_SITE is being phased out,
if need be.)

i found a clear bug with MASTER_SITE_OVERRIDE though:

$ env DISTDIR=/home/distfiles MASTER_SITE_OVERRIDE=Yes \
> MASTER_SITE_BACKUP='file:///home/olddistfiles/${DIST_SUBDIR}/' make fetch
===>  Checking files for bash-4.3.42
>> Fetch Yesbash-4.3.30.tar.gz
ftp: Yesbash-4.3.30.tar.gz: no address associated with name
ftp> by


it comes from this code:

.if ${MASTER_SITE_OVERRIDE:L} == "no"
MASTER_SITES := ${MASTER_SITES} ${MASTER_SITE_BACKUP}
.else
MASTER_SITES := ${MASTER_SITE_OVERRIDE} ${MASTER_SITES}
.endif


that last OVERRIDE should be BACKUP (since it's obviously prepending the
'Yes' to the file for the url.


there's another similar instance too. patch below.

--- infrastructure/mk/bsd.port.mk.orig  Thu Jan  7 04:25:02 2016
+++ infrastructure/mk/bsd.port.mk   Mon Feb  8 13:59:48 2016
@@ -1202,7 +1202,7 @@ MASTER_SITES ?=
 .if ${MASTER_SITE_OVERRIDE:L} == "no"
 MASTER_SITES := ${MASTER_SITES} ${MASTER_SITE_BACKUP}
 .else
-MASTER_SITES := ${MASTER_SITE_OVERRIDE} ${MASTER_SITES}
+MASTER_SITES := ${MASTER_SITE_BACKUP} ${MASTER_SITES}
 .endif
 
 _warn_checksum = :
@@ -1218,7 +1218,7 @@ _warn_checksum += ;echo ">>> MASTER_SITES${_I} not end
 .if ${MASTER_SITE_OVERRIDE:L} == "no"
 MASTER_SITES${_I} := ${MASTER_SITES${_I}} ${MASTER_SITE_BACKUP}
 .else
-MASTER_SITES${_I} := ${MASTER_SITE_OVERRIDE} ${MASTER_SITES${_I}}
+MASTER_SITES${_I} := ${MASTER_SITE_BACKUP} ${MASTER_SITES${_I}}
 .endif
 .  endif
 .endfor


but that just reveals a different problem, that it doesn't recognize
MASTER_SITE_BACKUP (even though the man page says it is a "User setting").

$ env DISTDIR=/home/distfiles MASTER_SITE_OVERRIDE=Yes \
> MASTER_SITE_BACKUP='file:///home/olddistfiles/${DIST_SUBDIR}/' make fetch
===>  Checking files for bash-4.3.42
>> Fetch http://ftp.openbsd.org/pub/OpenBSD/distfiles/bash/bash-4.3.30.tar.gz
bash-4.3.30.tar.gz   8% |** |   640 KB--:-- ETA^


adding some echos

$ env DISTDIR=/home/distfiles MASTER_SITE_OVERRIDE=Yes \
> MASTER_SITE_BACKUP='file:///home/olddistfiles/' make fetch
===>  Checking files for bash-4.3.42
===>  MASTER_SITE_OVERRIDE=Yes
===>  MASTER_SITE_BACKUP=http://ftp.openbsd.org/pub/OpenBSD/distfiles/bash/ 
ftp://ftp.usa.openbsd.org/pub/OpenBSD/distfiles/bash/ 
http://ftp.fr.openbsd.org/pub/OpenBSD/distfiles/bash/
===>  MASTER_SITES=http://ftp.openbsd.org/pub/OpenBSD/distfiles/bash/ 
ftp://ftp.usa.openbsd.org/pub/OpenBSD/distfiles/bash/ 
http://ftp.fr.openbsd.org/pub/OpenBSD/distfiles/bash/ 
http://ftpmirror.gnu.org/bash/ https://ftp.gnu.org/gnu/bash/ 
http://ftp.funet.fi/pub/gnu/prep/bash/ ftp://ftp.gnu.org/gnu/bash/ 
ftp://ftp.cs.tu-berlin.de/pub/gnu/bash/ http://mirrors.dotsrc.org/gnu/bash/ 
http://ftp.kddilabs.jp/GNU/bash/ http://ftp.nluug.nl/pub/gnu/bash/
>> Fetch http://ftp.openbsd.org/pub/OpenBSD/distfiles/bash/bash-4.3.30.tar.gz
bash-4.3.30.tar.gz  13% |   |  1024 KB--:-- 
ETA^C
http fetch aborted.


so it's ignoring the the value being set by the user. now this is a bit of a
mystery to me, since i can't find where it is being set at all.

$ pwd
/usr/ports/infrastructure/mk
$ grep MASTER_SITE_BACKUP *
bsd.port.mk:MASTER_SITES := ${MASTER_SITES} ${MASTER_SITE_BACKUP}
bsd.port.mk:MASTER_SITES := ${MASTER_SITE_BACKUP} ${MASTER_SITES}
bsd.port.mk:MASTER_SITES${_I} := ${MASTER_SITES${_I}} ${MASTER_SITE_BACKUP}
bsd.port.mk:MASTER_SITES${_I} := ${MASTER_SITE_BACKUP} ${MASTER_SITES${_I}}
bsd.port.mk.orig:MASTER_SITES := ${MASTER_SITES} ${MASTER_SITE_BACKUP}
bsd.port.mk.orig:MASTER_SITES${_I} := 

Re: [PATCH] Fix duplicity manpage

[trondd]

On Mon, February 8, 2016 7:59 am, Jérémie Courrèges-Anglas wrote:
> tro...@kagu-tsuchi.com writes:
>
>> Seems that with the change to duplicity 0.7, the default sftp backend
>> changed.
>> The manpage was being patched to say the default was pexpect over
>> paramiko.
>> This is no longer true.  Remove the manpage changes.
>
> Was there a rationale for changing the default again?
>
>

Ok, it looks like we used to patch the default in globals.py but that
variable isn't there anymore so the patch went away.

Would we rather change the default (however that would work in 0.7) to
pexpect again?  Paramiko doesn't work for me as it doesn't understand
ed25519 ssh keys but I don't know if that is a global problem for all
OpenBSD users.

Tim.

Re: NEW: www/tbb - Tor Browser Bundle

[Landry Breuil]

On Mon, Feb 08, 2016 at 02:53:16PM -0600, attila wrote:
> 
> Landry Breuil  writes:



> > Have you tried leaving the .xpi files compressed in their respective
> > dirs at runtime (eventually unzipping/patching/rezipping) as you comment
> > in Makefile.inc line 68 ? Iirc this should also work and is 'nicer' to
> > the filesystem..
> 
> I finally just grokked in fullness what you were saying here (sorry, a
> bit slow).  Given that I already have a start-tor-browser shell script
> in place to set things up we could instead switch to having .xpi files
> in distribution/extensions (or wherever) and unpack them when
> ~/.tor-browser is populated.  I'm sorry I didn't get to it before now,
> maybe the rest of what I've done can be critiqued and I'll make this
> change and test it when I get my buildbox back.

Fwiw, in TB 45 (and, i suppose, FX 45 but ours doesnt ship default
extensions) the bundled xpi's stay installed as xpi, and that works just
fine. There should be no need to unpack them in /usr/local, nor in the
user profile - if i got it right, you copy those extensions to the user
profile ? why ?

Landry

alpha-1.ports.openbsd.org bulk build report

[Landry Breuil]

Fwiw,

for those who care about exotic archs, alpha has lots of failures
because (among others) we dont build libGL/libGLU there anymore.
other failures are probably toolchain segfaults.

Landry

- Forwarded message from Landry Breuil  
-

bulk build on alpha-1.ports.openbsd.org
started on  Sat Jan 30 03:06:07 MST 2016
finished at Mon Feb 8 14:58:45 MST 2016
lasted 10D04h52m
done with kern.version=OpenBSD 5.9-beta (GENERIC.MP) #348: Fri Jan 29 00:21:55 
MST 2016

built packages:6692
Jan 30:578
Jan 31:273
Feb 1:766
Feb 2:380
Feb 3:359
Feb 4:362
Feb 5:492
Feb 6:508
Feb 7:487
Feb 8:2486

build failures: 85
http://build-failures.rhaalovely.net//alpha/2016-01-30/audio/xmms.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/databases/tdb.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/devel/cppcheck.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/devel/fox.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/devel/libmemcached.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/devel/libsigc++-2.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/devel/libtalloc.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/devel/liburcu.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/devel/ocaml-menhir.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/devel/ode.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/devel/p5-SDL.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/devel/plib.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/devel/py-subvertpy.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/devel/sdl2.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/devel/ti-msp430gcc.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/emulators/dosbox.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/emulators/mednafen.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/emulators/vice.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/games/abuse.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/games/alephone/alephone.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/games/armagetronad.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/games/astromenace.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/games/blobby.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/games/boswars.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/games/brumbrumrally.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/games/dangerdeep.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/games/egoboo.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/games/f1spirit.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/games/foobillard.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/games/freedroidrpg.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/games/lincity-ng.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/games/manaplus.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/games/meandmyshadow.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/games/naev/base.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/games/oolite.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/games/pacman-arena.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/games/pingus.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/games/prboom.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/games/prboom-plus.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/games/residualvm.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/games/stone-soup.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/games/taisei.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/games/valyriatear.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/games/wizznic.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/graphics/cfdg.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/graphics/clutter/cogl.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/graphics/freeglut.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/graphics/freeimage.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/graphics/ftgl.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/graphics/glew.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/graphics/glpng.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/graphics/lsys.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/graphics/py-cairo.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/graphics/py3-cairo.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/graphics/quesoglc.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/graphics/tesseract/tesseract.log
http://build-failures.rhaalovely.net//alpha/2016-01-30/graphics/waffle.log

Re: jdk 1.8 compilation

[Yozo TODA]

thanks Karel and Bryan,

I succeeded to compile JDK 1.8 with "ulimit -d 480".
(didn't check how many is minimum required,
 just 480 (KB) was enough for my environment.)

% (ulimit -d 4800 ; make package ...)

time(cpu-seconds)unlimited
file(blocks) unlimited
coredump(blocks) unlimited
data(kbytes) 480
stack(kbytes)4096
lockedmem(kbytes)331940
memory(kbytes)   994268
nofiles(descriptors) 512
processes256
===>  Checking files for jdk-1.8.0.45
`/usr/ports/distfiles/jdk/openjdk-8u45b14-bsd-port-20150618.tar.xz' is up to 
date.
>> (SHA256) jdk/openjdk-8u45b14-bsd-port-20150618.tar.xz: OK
..
- Build times ---
Start 2016-02-07 23:25:44
End   2016-02-08 02:53:36
00:01:37 corba
00:01:46 demos
00:08:35 docs
00:50:32 hotspot
00:05:02 images
00:00:55 jaxp
00:01:45 jaxws
02:15:28 jdk
00:01:29 langtools
00:00:42 nashorn
03:27:52 TOTAL
-
Finished building OpenJDK for target 'all'
===>  Faking installation for jdk-1.8.0.45
.. (snip)

-- yozo.

Re: Update net/mcabber to 1.0.1 - was (Re: Call for help updating a port (net/mcabber).)

[Christoph R. Murauer]

[ ... ]

>> As it was my first patch ever, I did it from scratch (the plist part
>> was my fault).
>
> Looks good!

@all thanks for help and feedback.

[PATCH] duplicity restore pexpect as default ssh backend

[trondd]

If we would rather restore pexpect as the default ssh backend instead of 
paramiko,
this should do it.

Tim.

Index: Makefile
===
RCS file: /cvs/ports/sysutils/duplicity/Makefile,v
retrieving revision 1.35
diff -u -p -r1.35 Makefile
--- Makefile17 Jan 2016 05:30:31 -  1.35
+++ Makefile8 Feb 2016 23:37:51 -
@@ -7,6 +7,7 @@ COMMENT =   encrypted backup using rsync a
 
 MODPY_EGG_VERSION = 0.7.06
 DISTNAME = duplicity-${MODPY_EGG_VERSION}
+REVISION = 0
 
 CATEGORIES =   sysutils
 
Index: patches/patch-duplicity_backends_ssh_paramiko_backend_py
===
RCS file: patches/patch-duplicity_backends_ssh_paramiko_backend_py
diff -N patches/patch-duplicity_backends_ssh_paramiko_backend_py
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-duplicity_backends_ssh_paramiko_backend_py8 Feb 2016 
23:37:51 -
@@ -0,0 +1,13 @@
+$OpenBSD$
+--- duplicity/backends/ssh_paramiko_backend.py.origMon Feb  8 18:16:06 2016
 duplicity/backends/ssh_paramiko_backend.py Mon Feb  8 18:17:19 2016
+@@ -375,8 +375,6 @@ Are you sure you want to continue connecting (yes/no)?
+ 
+ return sshconfig.lookup(host)
+ 
+-duplicity.backend.register_backend("sftp", SSHParamikoBackend)
+-duplicity.backend.register_backend("scp", SSHParamikoBackend)
+ duplicity.backend.register_backend("paramiko+sftp", SSHParamikoBackend)
+ duplicity.backend.register_backend("paramiko+scp", SSHParamikoBackend)
+-duplicity.backend.uses_netloc.extend(['sftp', 'scp', 'paramiko+sftp', 
'paramiko+scp'])
++duplicity.backend.uses_netloc.extend(['paramiko+sftp', 'paramiko+scp'])
Index: patches/patch-duplicity_backends_ssh_pexpect_backend_py
===
RCS file: patches/patch-duplicity_backends_ssh_pexpect_backend_py
diff -N patches/patch-duplicity_backends_ssh_pexpect_backend_py
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-duplicity_backends_ssh_pexpect_backend_py 8 Feb 2016 
23:37:51 -
@@ -0,0 +1,13 @@
+$OpenBSD$
+--- duplicity/backends/ssh_pexpect_backend.py.orig Mon Feb  8 18:22:28 2016
 duplicity/backends/ssh_pexpect_backend.py  Mon Feb  8 18:24:06 2016
+@@ -287,6 +287,8 @@ class SSHPExpectBackend(duplicity.backend.Backend):
+ commandline = ("%s %s %s" % (self.sftp_command, globals.ssh_options, 
self.host_string))
+ self.run_sftp_command(commandline, commands)
+ 
++duplicity.backend.register_backend("sftp", SSHPExpectBackend)
++duplicity.backend.register_backend("scp", SSHPExpectBackend)
+ duplicity.backend.register_backend("pexpect+sftp", SSHPExpectBackend)
+ duplicity.backend.register_backend("pexpect+scp", SSHPExpectBackend)
+-duplicity.backend.uses_netloc.extend(['pexpect+sftp', 'pexpect+scp'])
++duplicity.backend.uses_netloc.extend(['sftp', 'scp', 'pexpect+sftp', 
'pexpect+scp'])