Re: [patch] unbreak textproc/filepp

2017-12-23 Thread Matthew Clarke
Sat, Dec 23, 2017 at 10:05:27 +0100, Landry Breuil may have written:

> On Fri, Dec 22, 2017 at 04:29:47PM -0800, Matthew Clarke wrote:
> > Hi.
> > 
> > The textproc/filepp port has no maintainer, and the current filepp package
> > installs a filepp script that won't run due to the following error:
> > 
> > Global symbol "$DESTDIR" requires explicit package name (did you forget 
> > to declare "my $DESTDIR"?) at /usr/local/bin/filepp line 43.
> > Execution of /usr/local/bin/filepp aborted due to compilation errors.

[ snip ]

> > [ ... ]  Would a ports
> > committer please review the following diff, and commit it if it's OK?
> 
> 
> Hmm technically the filepp script isn't right since its buildsystem
> replaces @moduledir@ by what ends up in moduledir, defaulting to
> $prefix/share/filepp/modules, and $prefix is assigned ${DESTDIR} by the
> openbsd build system.
> -
> The moduledir is also set in the filepp script.  If you do not run
> configure for whatever reason you should also change @moduledir@ on
> line 40 to the directory you intend to install the modules in (or
> delete the whole line if you are not using modules).
> -
> There should be some TRUEPREFIX here..
> 
> so i think the following is "more correct" in case TRUEPREFIX changes
> someday:

Agreed.  Thanks for the review and comments.

BTW, the diff in your email had spaces, not tabs, so patch(1) rejected it,
but it worked fine when I applied it by hand.

-- 
"With your own code to haunt you, who needs users?"
-- Maarten Wiltink



[patch] unbreak textproc/filepp

2017-12-22 Thread Matthew Clarke
Hi.

The textproc/filepp port has no maintainer, and the current filepp package
installs a filepp script that won't run due to the following error:

Global symbol "$DESTDIR" requires explicit package name (did you forget 
to declare "my $DESTDIR"?) at /usr/local/bin/filepp line 43.
Execution of /usr/local/bin/filepp aborted due to compilation errors.

Line 43 of /usr/local/bin/filepp reads:

push(@INC, "${DESTDIR}/usr/local/share/filepp/modules");

I've used filepp successfully on OpenBSD before, but not for a couple of
years or so.  Reviewing the port history, I see that revision 1.6 (October
2015) of textproc/filepp/Makefile removed the following code:

post-configure:
   @perl -pi -e 's,\$${DESTDIR},,g;' ${WRKSRC}/filepp

Reverting that change makes filepp work again, but introduces the
following warning into the "configure" phase of the build:

Unescaped left brace in regex is deprecated, passed through in regex; 
marked by <-- HERE in m/\${ <-- HERE DESTDIR}/ at -e line 1.

Switching from perl to sed is one way to avoid the warning.  Would a ports
committer please review the following diff, and commit it if it's OK?
Thanks.

Index: Makefile
===
RCS file: /cvs/ports/textproc/filepp/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile15 Nov 2017 21:28:05 -  1.8
+++ Makefile22 Dec 2017 23:44:37 -
@@ -3,7 +3,7 @@
 COMMENT =  cpp-like generic file pre-processor
 
 DISTNAME = filepp-1.8.0
-REVISION = 2
+REVISION = 3
 CATEGORIES =   textproc devel
 MASTER_SITES = http://www-users.york.ac.uk/~dm26/filepp/
 
@@ -16,5 +16,8 @@ CONFIGURE_STYLE = gnu dest
 NO_BUILD = Yes
 PKG_ARCH = *
 TEST_TARGET =  fulltest
+
+post-configure:
+   sed -i 's,$${DESTDIR},,g' ${WRKSRC}/filepp
 
 .include 

-- 
"On two occasions I have been asked [by members of Parliament!], `Pray, Mr.
Babbage, if you put into the machine wrong figures, will the right answers
come out?'  I am not able rightly to apprehend the kind of confusion of
ideas that could provoke such a question."  -- Charles Babbage



Re: [UPDATE] shells/tcsh to 6.20.00

2017-09-02 Thread Matthew Clarke
Thu, Aug 17, 2017 at 14:38:42 +0200, Frederic Cambus may have written:

> Hi ports@,
> 
> Here is a diff to update tcsh to 6.20.00.
> 
> Comments? OK?

I've been running with this in heavy daily use for the past week, and
haven't encountered any problems.

OpenBSD 6.2-beta (GENERIC.MP) #45: Sat Aug 26 10:24:08 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

-- 
"With your own code to haunt you, who needs users?"
-- Maarten Wiltink



Re: [PATCH] make TortoiseHg work again

2015-02-26 Thread Matthew Clarke
Thu, Feb 26, 2015 at 11:13:46 +0100, Remi Pointel may have written:

 Le 23-02-2015 18:31, Matthew Clarke a ??crit??:
 Hi.
 
 [ Sent this to the devel/tortoisehg maintainer a week ago yesterday. ]
 [ No response yet.  Is this too late for 5.7? ]
 
 Since the Mercurial update from 3.0 to 3.2.3, TortoiseHg 3.0 refuses
 to run, saying it requires Mercurial 3.0.n or 3.1.n.  Here's a diff to
 update TortoiseHg to version 3.3, which requires Mercurial 3.2.n or 3.3.n.
 Lightly tested on i386.
 
 Hi,
 
 sorry for the delay...
 
 I don't understand why you need the config.py part?

Yeah, I should have explained that bit.

 This is the diff, does it works fine for you?
 
 Cheers,
 
 Remi.

No, sorry.  TortoiseHg 3.3 determines the location of the following files
at run-time:

- The license terms text file, when the License button on the
  About TortoiseHg dialogue is pressed.

- The translation (tortoisehg.mo) files, used if a language
  other than English is requested (e.g., via LANG or LC_ALL).

- The .png file containing the TortoiseHg logo to show at the
  top of the About TortoiseHg dialogue.

(Actually, 3.0 did this too, but I didn't notice until testing 3.3.)

The code that determines those locations is installed as
lib/python/${MODPY_VERSION}/site-packages/tortoisehg/util/paths.py,
and it tries to import the locations as variable settings from
lib/python/${MODPY_VERSION}/site-packages/tortoisehg/util/config.py.

If we don't install a config.py, the code in paths.py derives locations
relative to the grandparent of the directory holding paths.py, so
TortoiseHg ends up looking for the following, none of which exist.

- The license terms in file
  lib/python/${MODPY_VERSION}/site-packages/COPYING.txt.

- The translation files in sub-directories of
  lib/python/${MODPY_VERSION}/site-packages/locale.

- The .png file containing the TortoiseHg logo in
  lib/python/${MODPY_VERSION}/site-packages/icons.

I created config.py in post-extract, so it would exist before TortoiseHg
setup.py was run, because that setup.py includes the following code:

--
# Create a config.py.  Distributions will need to supply their own
cfgfile = os.path.join('tortoisehg', 'util', 'config.py')
if not os.path.exists(cfgfile) and not os.path.exists('.hg/requires'):
f = open(cfgfile, w)
f.write('bin_path = /usr/bin\n')
f.write('license_path = /usr/share/doc/tortoisehg/Copying.txt.gz\n')
f.write('locale_path  = /usr/share/locale\n')
f.write('icon_path= /usr/share/pixmaps/tortoisehg/icons\n')
f.write('nofork   = True\n')
f.close()
--

With that config.py created by setup.py, TortoiseHg ends up looking for
the following, which don't exist or don't contain what TortoiseHg is
looking for.

- The license terms in file
  /usr/share/doc/tortoisehg/Copying.txt.gz.

- The translation files in sub-directories of
  /usr/share/locale.

- The .png file containing the TortoiseHg logo in
  /usr/share/pixmaps/tortoisehg/icons.

There's already a patch for setup.py, and I thought about extending it to
patch the block of code that creates config.py, but I haven't learned yet
how to combine ${SUBST} and make patch.  A separate files/config.py and
post-extract: ${SUBST_DATA} in Makefile seemed cleaner.

A couple of other things I should have explained about my proposed diff:

1. RUN_DEPENDS on devel/mercurial.  I proposed this change in Makefile:

--
@@ -23,9 +23,19 @@
 
 RUN_DEPENDS =  ${BUILD_DEPENDS} \
editors/py-qscintilla \
-   devel/mercurial=3.0 \
+   devel/mercurial=3.2,3.4 \
devel/py-iniparse
--

I got the Mercurial 3.0 - 3.2.3 update on a test machine a few weeks ago,
but it wasn't until a couple of weeks later that I next tried to actually
run hg and thg on that test machine, and found out that TortoiseHg 3.0
refused to run with Mercurial 3.2.3.  Tightening the devel/mercurial RDEP
in the TortoiseHg package would have made the problem visible when pkg_add
updated Mercurial.

Hmm.  I wonder if I can automate pulling the Mercurial RDEP versions from
the TortoiseHg sources.  No time now, and that can wait until after 5.7
anyway.  For now, I've included at the end of this message an updated
proposed patch with a comment before the RUN_DEPENDS block in Makefile.

2. Packaging COPYING.txt.  I proposed these changes in Makefile:

--
 NO_TEST =  Yes
+
+SHAREDIR

[PATCH] make TortoiseHg work again

2015-02-23 Thread Matthew Clarke
Hi.

[ Sent this to the devel/tortoisehg maintainer a week ago yesterday. ]
[ No response yet.  Is this too late for 5.7? ]

Since the Mercurial update from 3.0 to 3.2.3, TortoiseHg 3.0 refuses
to run, saying it requires Mercurial 3.0.n or 3.1.n.  Here's a diff to
update TortoiseHg to version 3.3, which requires Mercurial 3.2.n or 3.3.n.
Lightly tested on i386.

Index: Makefile
===
RCS file: /cvs/ports/devel/tortoisehg/Makefile,v
retrieving revision 1.16
diff -u -r1.16 Makefile
--- Makefile19 May 2014 19:16:17 -  1.16
+++ Makefile16 Feb 2015 03:59:24 -
@@ -2,7 +2,7 @@
 
 COMMENT =  series of applications for Mercurial
 
-MODPY_EGG_VERSION =3.0
+MODPY_EGG_VERSION =3.3
 DISTNAME = tortoisehg-${MODPY_EGG_VERSION}
 
 CATEGORIES =   devel
@@ -23,9 +23,19 @@
 
 RUN_DEPENDS =  ${BUILD_DEPENDS} \
editors/py-qscintilla \
-   devel/mercurial=3.0 \
+   devel/mercurial=3.2,3.4 \
devel/py-iniparse
 
 NO_TEST =  Yes
+
+SHAREDIR = ${PREFIX}/share/tortoisehg
+
+post-extract:
+   @${SUBST_DATA} -c ${FILESDIR}/config.py \
+   ${WRKSRC}/tortoisehg/util/config.py
+
+post-install:
+   ${INSTALL_DATA_DIR} ${SHAREDIR}
+   ${INSTALL_DATA} ${WRKSRC}/COPYING.txt ${SHAREDIR}
 
 .include bsd.port.mk
Index: distinfo
===
RCS file: /cvs/ports/devel/tortoisehg/distinfo,v
retrieving revision 1.13
diff -u -r1.13 distinfo
--- distinfo19 May 2014 19:16:17 -  1.13
+++ distinfo14 Feb 2015 21:08:51 -
@@ -1,2 +1,2 @@
-SHA256 (tortoisehg-3.0.tar.gz) = ylNx0NcgsPViEBNhLlReo4b+krXfSpxpa3LbvnFupKc=
-SIZE (tortoisehg-3.0.tar.gz) = 8237239
+SHA256 (tortoisehg-3.3.tar.gz) = CHrwKLtUohYqMaLdgaFKPx8eEurd5CiQpImrEfcgHNs=
+SIZE (tortoisehg-3.3.tar.gz) = 8210712
Index: files/config.py
===
RCS file: files/config.py
diff -N files/config.py
--- /dev/null   1 Jan 1970 00:00:00 -
+++ files/config.py 16 Feb 2015 04:30:28 -
@@ -0,0 +1,6 @@
+# $OpenBSD$
+bin_path = ${TRUEPREFIX}/bin
+license_path = ${TRUEPREFIX}/share/tortoisehg/COPYING.txt
+locale_path  = ${TRUEPREFIX}/share/locale
+icon_path= ${TRUEPREFIX}/share/pixmaps/tortoisehg/icons
+nofork   = False
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/tortoisehg/pkg/PLIST,v
retrieving revision 1.10
diff -u -r1.10 PLIST
--- pkg/PLIST   19 May 2014 19:16:17 -  1.10
+++ pkg/PLIST   16 Feb 2015 03:45:51 -
@@ -80,16 +80,14 @@
 lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/htmldelegate.pyc
 lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/htmlui.py
 lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/htmlui.pyc
-lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/i18n.py
-lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/i18n.pyc
 lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/icons_rc.py
 lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/icons_rc.pyc
+lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/infobar.py
+lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/infobar.pyc
 lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/lexers.py
 lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/lexers.pyc
 lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/lfprompt.py
 lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/lfprompt.pyc
-lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/license.py
-lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/license.pyc
 lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/manifestmodel.py
 lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/manifestmodel.pyc
 lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/matching.py
@@ -102,8 +100,6 @@
 lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/modeltest.pyc
 lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/mq.py
 lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/mq.pyc
-lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/mqutil.py
-lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/mqutil.pyc
 lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/p4pending.py
 lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/p4pending.pyc
 lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/pbranch.py
@@ -112,6 +108,8 @@
 lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/postreview.pyc
 lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/postreview_ui.py
 lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/postreview_ui.pyc
+lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/prune.py
+lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/prune.pyc
 

Re: net/psi 0.15 from packages does not connect to any jabber server

2013-07-14 Thread Matthew Clarke
Sun, Jul 14, 2013 at 22:37:31 +0600, Alexandr Shadchin may have written:

 On Fri, Jun 14, 2013 at 04:43:11PM +0500, dmitry.sensei wrote:
  Hi!
  
  net/psi 0.15 from packages does not connect to any jabber server.
  for exapmple vk.com jabber.ru xmpp.yandex.ru talkr.im xmpp.odnoklassniki.ru
  chat.facebook.com.
  
 [snip]
 
 I'm sorry for the long answer, too little time.
 This diff should solve this issue.
 
 Now _res has minimal support:
 not define nsaddr_list, only nscount, therefore jdns could not determine
 dns server.
 
 Comments ? Ok ?
 
 -- 
 Alexandr Shadchin

[ snip patch ]

I was about to add a me too to dmitry.sensei's problem report when I saw
the patch.

Patch works for me; psi can connect to talk.google.com again.

Thanks.
-- 
On two occasions I have been asked [by members of Parliament!], `Pray, Mr.
Babbage, if you put into the machine wrong figures, will the right answers
come out?'  I am not able rightly to apprehend the kind of confusion of
ideas that could provoke such a question.  -- Charles Babbage



Re: UPDATE: tcsh - 6.16.00

2009-07-17 Thread Matthew Clarke
Thu, Jul 16, 2009 at 03:41:50PM +0100, Stuart Henderson may have written:

 On 2009/07/17 00:25, Ian McWilliam wrote:
  Stuart Henderson wrote:
  I don't use it myself, could any tcsh users please give this
  update a spin? thanks.
  
  
  Works fine for me on Amd64.
  
  version tcsh 6.16.00 (Astron) 2008-09-30 (amd64-amd-OpenBSD) options
  wide,nls,dl,al,kan,sm,rh,color,filec
  
  
  Version 6.17.00 was released on July 10, so maybe we should take that
  for a spin.
  
  ftp://ftp.astron.com/pub/tcsh/
 
 thanks, nice of them to update the website :-)

Used it all day today; no problems.

tcsh 6.17.00 (Astron) 2009-07-10 (i386-intel-OpenBSD) options 
wide,nls,dl,al,kan,sm,rh,color,filec

-- 
Shoot for the moon.  If you miss, you're among stars.



Re: UPDATE: rdesktop 1.6.0

2008-06-19 Thread Matthew Clarke
Wed, Jun 18, 2008 at 12:53:39PM +0200, Giovanni Bechis may have written:

 It works well @i386, PLIST updated and PKGNAME removed.
  Cheers
   Giovanni

[ snip patch ]

Works well on i386 here.

- connect to XP Pro on laptop at 1024x768
- connect to XP Pro on other laptop at 1680x1050
- connect to XP Pro in qemu on local system at 1680x1050

You might want to add libsamplerate (audio/libsamplerate) to the port's
dependencies, as that library will be found and used if it is installed.
I could't tell that the presence of libsamplerate made any difference to
the few sounds that I've heard during testing so far, though.

-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.  -- Kernighan
-- quoted by Quentyn Taylor



typo in net/yt/pkg/DESCR

2007-10-30 Thread Matthew Clarke

No MAINTAINER listed in Makefile, so hello [EMAIL PROTECTED]

Trivial typo fix:

Index: net/yt/pkg/DESCR
===
RCS file: /cvs/ports/net/yt/pkg/DESCR,v
retrieving revision 1.2
diff -u -r1.2 DESCR
--- net/yt/pkg/DESCR21 Feb 2007 13:50:18 -  1.2
+++ net/yt/pkg/DESCR30 Oct 2007 19:31:46 -
@@ -1,3 +1,3 @@
 yt is an extensible Lua script to fetch videos from YouTube.com. You can
-(and probaly should) customize it to use your preferred encoding tool.
+(and probably should) customize it to use your preferred encoding tool.
 By default it uses graphics/ffmpeg.


-- 
Perfection [in design] is achieved not when there is nothing left to add,
but rather when there is nothing left to take away.
-- Antoine de Saint-Exupery