CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: p...@cvs.openbsd.org2020/01/21 00:20:20 Modified files: sysutils/ansible: Makefile distinfo sysutils/ansible/pkg: PLIST-html Log message: Update ansible 2.9.3 -> 2.9.4 Changelog: https://github.com/ansible/ansible/blob/stable-2.9/changelogs/CHANGELOG-v2.9.rst#v2-9-4
Re: CVS: cvs.openbsd.org: ports
On Mon, Jan 20, 2020 at 04:32:01PM -0700, Kurt Miller wrote: > CVSROOT: /cvs > Module name: ports > Changes by: k...@cvs.openbsd.org2020/01/20 16:32:01 > > Added files: > benchmarks/fio : Makefile distinfo > benchmarks/fio/pkg: DESCR PLIST > > Log message: > fio is a IO benchmarking tool that can simulate various user defined > workloads. fio will spawn a number of threads or processes doing a > particular type of IO action as specified by the user. It takes a > number of global parameters, each inherited by the thread unless other > parameters given to them overriding that setting. The typical use of > fio is to write a job file matching the IO load one wants to simulate. Fwiw it conflicts with geo/py-fiona, which also installs bin/fio in the default python2 flavor. Either set the @conflict markers or rename the benchmarks/fio binary to something else in post-install.. [07:46] c64:/usr/ports/benchmarks/fio/ $doas pkg_add py-fiona [07:47] c64:/usr/ports/benchmarks/fio/ $make install ===> Installing fio-3.17 from /usr/ports/packages/amd64/all/ Collision in fio-3.17: the following files already exist /usr/local/bin/fio (py-fiona-1.8.11p0 and fio-3.17) Couldn't install fio-3.17 i *think* pkg_create was supposed to warn about such conflicts but maybe that felt into the cracks. Landry
Remove databases/qt3-sqlite3-plugin
No consumers present in the tree, looks quite useless. Ok to say goodbye?
Update devel/tmake
Yearly grep(1)'ing for "x11/qt3" and "x11/qt4", brings me here.
First thought, delete it. But there is an update and it's may useful.
Tweaks:
- Switch from qt3 to qt5 to access MODQT_* vars, but set MODQT_DEPS=No.
- Install LICENSE file
OK?
Index: Makefile
===
RCS file: /cvs/ports/devel/tmake/Makefile,v
retrieving revision 1.16
diff -u -p -u -p -r1.16 Makefile
--- Makefile12 Jul 2019 20:46:03 - 1.16
+++ Makefile21 Jan 2020 05:44:21 -
@@ -2,8 +2,7 @@
COMMENT= cross-platform makefile tool from TrollTech
-DISTNAME= tmake-1.10
-REVISION = 3
+DISTNAME= tmake-2.12
CATEGORIES=devel
HOMEPAGE= http://sourceforge.net/projects/tmake/
@@ -11,13 +10,15 @@ HOMEPAGE= http://sourceforge.net/project
# Permission to use, copy, modify, and distribute
PERMIT_PACKAGE=Yes
-MASTER_SITES= http://www.linklevel.net/distfiles/
+MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=tmake/}
+EXTRACT_SUFX= .zip
NO_BUILD= Yes
NO_TEST= Yes
PKG_ARCH= *
-MODULES= x11/qt3
+MODULES= x11/qt5
+MODQT_DEPS=No
do-install:
@perl -pi \
@@ -40,6 +41,7 @@ do-install:
${INSTALL_DATA} ${WRKSRC}/lib/$$dir/*
${PREFIX}/share/tmake/$$dir; \
done; \
${INSTALL_DATA_DIR} ${PREFIX}/share/doc/tmake
+ ${INSTALL_DATA} ${WRKSRC}/LICENSE ${PREFIX}/share/doc/tmake
${INSTALL_DATA} ${WRKSRC}/doc/tmake.html
${PREFIX}/share/doc/tmake/tmake.html
${INSTALL_DATA} ${WRKSRC}/doc/tmake_ref.html
${PREFIX}/share/doc/tmake/tmake_ref.html
Index: distinfo
===
RCS file: /cvs/ports/devel/tmake/distinfo,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 distinfo
--- distinfo26 May 2013 09:30:55 - 1.6
+++ distinfo21 Jan 2020 05:44:21 -
@@ -1,2 +1,2 @@
-SHA256 (tmake-1.10.tar.gz) = tu5NtZbPjYUNAX2nSKIf5pEszdcQd4dCESH2HglARsg=
-SIZE (tmake-1.10.tar.gz) = 65562
+SHA256 (tmake-2.12.zip) = AJd/CbGRlEXzHsT5EvZg+xGa61vjvRqvP+RPOd3HVXg=
+SIZE (tmake-2.12.zip) = 187874
Index: patches/patch-bin_tmake
===
RCS file: /cvs/ports/devel/tmake/patches/patch-bin_tmake,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 patch-bin_tmake
--- patches/patch-bin_tmake 28 Feb 2002 14:15:31 - 1.1.1.1
+++ patches/patch-bin_tmake 21 Jan 2020 05:44:21 -
@@ -1,13 +1,21 @@
$OpenBSD: patch-bin_tmake,v 1.1.1.1 2002/02/28 14:15:31 naddy Exp $
bin/tmake.orig Mon Jan 21 10:35:27 2002
-+++ bin/tmake Mon Jan 21 10:51:36 2002
-@@ -66,7 +66,7 @@ $outfile = "";
- %project = ();
- $eval_quit= 0;
+Index: bin/tmake
+--- bin/tmake.orig
bin/tmake
+@@ -96,11 +96,10 @@ sub init
+$platform =~ /^mswin/ && ( $platform = "win32" );
+my $gcc_platform = $platform."-g++";
--$project{"TMAKEPATH"} = $ENV{"TMAKEPATH"} . ";" . $ENV{"HOME"} . "/.tmake/";
-+$project{"TMAKEPATH"} = $ENV{"TMAKEPATH"} .
";%%PREFIX%%/share/tmake/openbsd-g++/;" . $ENV{"HOME"} . "/.tmake/";
+- $project{'TMAKEPATH'} = $ENV{'TMAKEPATH'} . ";"
+- . $ENV{"HOME"} . "/.tmake/;"
+- . $tmake_dir . "lib/$ENV{'TMAKEPATH'};"
+- . $tmake_dir . "lib/$gcc_platform;"
+- . $tmake_dir .
"/usr/lib/tmake-$TMAKE_VERSION/$gcc_platform;";
++ $project{"TMAKEPATH"} = $ENV{"TMAKEPATH"}
++ . ";%%PREFIX%%/share/tmake/openbsd-g++/;"
++ . $ENV{"HOME"}
++ . "/.tmake/";
- while ( @ARGV ) { # parse command line args
- $_ = shift @ARGV;
+my $tmake_conf_path = _template("tmake.conf");
+my $tmake_dir = $tmake_conf_path;
Index: patches/patch-lib_openbsd-g++_tmake_conf
===
RCS file: /cvs/ports/devel/tmake/patches/patch-lib_openbsd-g++_tmake_conf,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 patch-lib_openbsd-g++_tmake_conf
--- patches/patch-lib_openbsd-g++_tmake_conf2 Feb 2003 16:34:02 -
1.2
+++ patches/patch-lib_openbsd-g++_tmake_conf21 Jan 2020 05:44:21 -
@@ -1,9 +1,10 @@
$OpenBSD: patch-lib_openbsd-g++_tmake_conf,v 1.2 2003/02/02 16:34:02 sturm Exp
$
lib/openbsd-g++/tmake.conf.origFri Jan 31 14:25:37 2003
-+++ lib/openbsd-g++/tmake.conf Fri Jan 31 14:36:50 2003
-@@ -7,52 +7,50 @@
+Index: lib/openbsd-g++/tmake.conf
+--- lib/openbsd-g++/tmake.conf.orig
lib/openbsd-g++/tmake.conf
+@@ -7,52 +7,51 @@
TEMPLATE = app
- CONFIG= qt warn_on release
+ CONFIG= warn_on release
-TMAKE_CC = gcc
-TMAKE_CFLAGS =
@@ -36,12 +37,6 @@ $OpenBSD: patch-lib_openbsd-g++_tmake_co
-TMAKE_LIBDIR_QT = $(QTDIR)/lib
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2020/01/20 22:27:19 Modified files: devel/cargo: cargo.port.mk devel/cbindgen : Makefile net/routinator : Makefile Log message: devel/cargo: use edition 2018 syntax by default for installing using cargo the syntax is compatible with older edition, and more crates are using the edition 2018 which require it. avoid using MODCARGO_INSTALL_ARGS just to pass "--path ." ok landry@ (some time ago, the diff was sleeping in my tree)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: d...@cvs.openbsd.org2020/01/20 20:35:49 Modified files: geo/openbsd-developers: Makefile Log message: bump rev for previous
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: d...@cvs.openbsd.org2020/01/20 20:33:47 Modified files: geo/openbsd-developers/files: OpenBSD Log message: make my location slightly less incorrect; spotted by Ross L Richardson
ports unable to resolve dependencies in some cases
I think this following case is when there is a package cached (or created) in the ports tree, but one of its dependencies is not there. devlin$ make ===> py-h5py-2.10.0 depends on: py-numpy-* - not found ===> Verifying install for py-numpy-* in math/py-numpy ===> Installing py-numpy-1.14.6p1 from /usr/ports/packages/sparc64/all/ Can't find blas-3.8.0p0 Can't install lapack-3.8.0p1: can't resolve blas-3.8.0p0 Can't install py-numpy-1.14.6p1: can't resolve lapack-3.8.0p1 Couldn't install blas-3.8.0p0 lapack-3.8.0p1 py-numpy-1.14.6p1 *** Error 1 in /usr/ports/math/py-numpy (/usr/ports/infrastructure/mk/bsd.port.mk:2115 '/var/db/pkg/py-numpy-1.14.6p1/+CONTENTS': @/usr/bin/...) *** Error 2 in /usr/ports/math/py-numpy (/usr/ports/infrastructure/mk/bsd.port.mk:2556 'install': @lock=py-numpy-1.14.6; export _LOCKS_HELD...) *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2239 '/usr/ports/pobj/py-h5py-2.10.0/.dep-math-py-numpy': @unset _DEPENDS_TARGET ...) *** Error 2 in /usr/ports/mystuff/math/h5py (/usr/ports/infrastructure/mk/bsd.port.mk:2556 'all': @lock=py-h5py-2.10.0; export _LOCKS_HELD=...) devlin$ This happens to me fairly frequently, whether it is on that sparc64 box or my amd64 laptop. Yes, I use FETCH_PACKAGES. No, my /etc/installurl is not wrong, because if I then run "pkg_add -a py-numpy" it will resolve everything just fine. So this is something specific to how the ports infrastructure handles the situation. --Kurt
Re: git gui: Tcl version error
On 2020-01-19 13:11, Stuart Henderson wrote: ..but the wish interpreter path is set (eventually) based on whatever version ports is telling it to use, so wish8.5. The only way I can see that it would work is if you run "wish8.6 /usr/local/libexec/git/git-gui". Anyway here is the fix, also moves a file to the correct PLIST and uses the correct wish interpreter path in git-gui--askpass (it's subst'ed in git-gui.sh -> git-gui in git-gui/Makefile, but not in git-gui--askpass) x11/tk +MODTK_VERSION = 8.6 + Hi, Yes, that's the good way to go, thanks. Any Tcl extensions that this (or other 8.6-using ports) require should probably still be built against 8.5. This is fine, they will also load into 8.6. Stu
Re: Debug packages policy?
On Mon, Jan 20, 2020 at 11:31:11PM +0100, Christian Weisgerber wrote: > What's the policy for adding debug packages to ports? > > Is the intend to add debug packages... > * eventually to all ports > or > * only to ports where they seem particularly useful? I think the policy is up for debate really. Nothing has been decided yet. My humble opinion is that "particularly useful" is subjective... -- Antoine
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2020/01/20 16:33:08 Modified files: benchmarks : Makefile Log message: Add fio
Re: UPDATE: multimedia/handbrake 1.3.0 => 1.3.1
On 2020-01-10 9:19 AM, Brian Callahan wrote: Hi ports -- Attached is an update to HandBrake. Please test. Changelog is here: https://github.com/HandBrake/HandBrake/releases/tag/1.3.1 OK? ~Brian Ping.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2020/01/20 16:32:01 Added files: benchmarks/fio : Makefile distinfo benchmarks/fio/pkg: DESCR PLIST Log message: fio is a IO benchmarking tool that can simulate various user defined workloads. fio will spawn a number of threads or processes doing a particular type of IO action as specified by the user. It takes a number of global parameters, each inherited by the thread unless other parameters given to them overriding that setting. The typical use of fio is to write a job file matching the IO load one wants to simulate. okay sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: abie...@cvs.openbsd.org 2020/01/20 16:32:55 Modified files: cad/fritzing : Makefile Removed files: cad/fritzing/patches: patch-phoenix_pro Log message: Switch fritzing to qt5, original diff from rsadowski updates from me. OK rsadowski
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2020/01/20 16:30:06 ports/benchmarks/fio Update of /cvs/ports/benchmarks/fio In directory cvs.openbsd.org:/tmp/cvs-serv51322/fio Log Message: Directory /cvs/ports/benchmarks/fio added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2020/01/20 16:30:22 ports/benchmarks/fio/pkg Update of /cvs/ports/benchmarks/fio/pkg In directory cvs.openbsd.org:/tmp/cvs-serv52025/pkg Log Message: Directory /cvs/ports/benchmarks/fio/pkg added to the repository
Re: UPDATE: devel/gmake 4.2.1 => 4.3
On 2020-01-20 5:57 PM, Christian Weisgerber wrote:
Brian Callahan:
Attached is an update to gmake.
I worked on this independently and comparing the results, I have
some objections:
* We can use the .tar.lz distfile.
* MODGNU_CONFIG_GUESS_DIRS should not be removed but set to the
correct ${WRKSRC}/build-aux.
* Instead of patching tests/scripts/features/exec we can just set
TEST_ENV= SHELL=$$SHELL
and honor the intention of the test.
That's a better solution that I thought of for sure.
* "You should use this name if you have a makefile that is specific
to GNU gmake, and will not be understood by other versions of
gmake."
Uhm, no. You cannot blindly substitute all instances of "make"
with "gmake" in the man page.
* You dropped the comment at the top of patch-src_makeint_h.
These two were just oversights; thanks for catching.
One test fails on arm64 (but the same test fails with 4.2.1 too).
A great opportunity to look into this failure!
Agreed. For completeness, here's the relevant part of the test log:
features/output-sync Error running
/usr/ports/pobj/gmake-4.3/build-aarch64/tests/../make (expected 0; got
512): /usr/ports/pobj/gmake-4.3/build-aarch64/tests/../make -f
work/features/output-sync.mk -j -Orecurse
Error running /usr/ports/pobj/gmake-4.3/build-aarch64/tests/../make
(expected 0; got 512):
/usr/ports/pobj/gmake-4.3/build-aarch64/tests/../make -f
work/features/output-sync.mk.1 -j --output-sync=target
FAILED (13/15 passed)
Digging through the logs, it appears that the two tests are timing out.
This also happened in 4.2.1, which makes me wonder if it's something
specific to my arm64 machine. Anyhow, I can look into it but not for the
next few days.
Obviously needs more testing than I can provide, but here for the
interested.
I'll run an amd64 bulk build with it sometime in the next few days.
The "WARNING: Backward-incompatibility!" changes could break some
cruft.
Yes, this warning coupled with what sthen mentioned about how it will
become the default behavior in the future is what spurred my interest to
update.
~Brian
Re: UPDATE: devel/gmake 4.2.1 => 4.3
Brian Callahan:
> Attached is an update to gmake.
I worked on this independently and comparing the results, I have
some objections:
* We can use the .tar.lz distfile.
* MODGNU_CONFIG_GUESS_DIRS should not be removed but set to the
correct ${WRKSRC}/build-aux.
* Instead of patching tests/scripts/features/exec we can just set
TEST_ENV= SHELL=$$SHELL
and honor the intention of the test.
* "You should use this name if you have a makefile that is specific
to GNU gmake, and will not be understood by other versions of
gmake."
Uhm, no. You cannot blindly substitute all instances of "make"
with "gmake" in the man page.
* You dropped the comment at the top of patch-src_makeint_h.
> One test fails on arm64 (but the same test fails with 4.2.1 too).
A great opportunity to look into this failure!
> Obviously needs more testing than I can provide, but here for the
> interested.
I'll run an amd64 bulk build with it sometime in the next few days.
The "WARNING: Backward-incompatibility!" changes could break some
cruft.
--
Christian "naddy" Weisgerber na...@mips.inka.de
Re: Remove graphics/digikam-kde4
On Sun, Jan 19 2020, Stuart Henderson wrote: > On 2020/01/19 09:46, Rafael Sadowski wrote: >> Since this software was not built for 6.6 and nobody complained, I would >> like to delete it forever. It's marked as broken and nobody is yelling >> that we should fix it (I wouldn't fix it, even if I could). >> >> For those who don't know, we have version 5+ in the tree. Yes, there is >> not easy to merge the old database 4 to verson 5 but it's possible. >> Google for guidance. Upstream is not interested in this problem. >> >> OK to remove digikam4 and no more needed dependencies? >> >> Cheers, >> >> Rafael >> > > OK, same as eigen about merging via @pkgpath or adding to obsolete. +1 -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Debug packages policy?
What's the policy for adding debug packages to ports? Is the intend to add debug packages... * eventually to all ports or * only to ports where they seem particularly useful? -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: [NEW] devel/p5-Version-Compare
On Mon, Jan 20 2020, Andrew Hewus Fresh wrote:
> On Mon, Jan 20, 2020 at 03:00:30PM -0500, Chris Bennett wrote:
>> On Mon, Jan 20, 2020 at 04:15:42PM +0100, Jeremie Courreges-Anglas wrote:
>> > On Sun, Jan 19 2020, Chris Bennett
>> > wrote:
>> > > This tests perl module versions to see which is higher version.
>> > >
>> > > I have set TEST_POD and RELEASE_TESTING.
>> > >
>> > > Unless there is some objection, I will set release and author testing
>> > > in future Perl ports also. The mechanism is there. It seems worthwhile
>> > > to use it, unless this places too big a burden on bulk builds?
>> > >
>> > > Comments?
>> >
>> > It's not our job to do release and documentation testing. Please leave
>> > this out of the Makefile.
>> >
>>
>> Honestly, I picked submitting this simple port exactly to bring up that
>> question.
>>
>> What I am seeing in the ports tree, just looking at devel/p5-* are,
>> for example.
>>
>> devel/p5-Mock-Config (and several others just under devel)
>> has MAKE_ENV += RELEASE_TESTING=Yes TEST_POD=Yes
>>
>> devel/p5-YAML
>> has TEST_ENV += AUTHOR_TESTING=1
>>
>> When I submitted p5-PGObject,
>> https://marc.info/?l=openbsd-ports=157645754310168=2
>>
>> I got a response:
>>
>> This could use "MAKE_ENV=TEST_POD=yes RELEASE_TESTING=''"
>> so that tests work the same no matter the environment.
>>
>> Other than that, OK afresh1@ if someone wants to import.
>> -
>>
>> I don't know what to make of the RELEASE_TESTING='' part.
>
>
> This specifically *disables* release testing, no matter whether someone
> decided to set it in their local environment. It's mostly documenting
> that we are choosing not to run those tests so that in the future folks
> don't try. I usually find that if the release testing Just Works, I
> prefer to enable it.
Disclaimer: I don't do much work in perl ports land.
TEST_POD shouldn't bring additional deps and may warn about crappy
formatting, so it may be useful.
For RELEASE_TESTING, if it just works, fine. But bringing in additional
deps and cruft in the port Makefile really seems over the top. Imagine
if we did this for all ports using automake...
>> So I don't see a clear answer on what is right, wrong or ambivalent.
>> I'm going to at least do this testing myself before submitting, since
>> these are new vs updated ports.
>> But what should or shouldn't end up in the tests in the Makefile
>> I submit?
>
> There is a lot of personal preference there. My preference is to make
> the ports tree not do something different depending on the environment
> as it makes problems easier to understand.
perl.port.mk consistently uses ${SETENV} so there's no way for a user to
leak RELEASE_TESTING or TEST_POD from their environment.
>
>> > Is this library useful for other (upcoming or existing) ports?
>>
>> Yes, this is for upcoming LedgerSMB port.
>> It is in the required section of the cpanfile.
>>
>> https://github.com/ledgersmb/LedgerSMB/blob/master/cpanfile
>>
>> Thanks,
>> Chris Bennett
>>
>>
>>
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [update] nnn 2.8.1 > v2.9
Thank you for the corrections and comments.
On 1/20/20 5:26 PM, Klemens Nanni wrote:
On Mon, Jan 20, 2020 at 03:17:09PM -0400, Dnsgate wrote:
This is a port update for the CLI file manager sysutils/nnn
This patch updates nnn from 2.8.1 to 2.9
Please send diffs inline, not attached.
Changes and version info here:
https://github.com/jarun/nnn/releases/tag/v2.9
Tested on amd64 for a couple of days and I have found it to be more stable
than the previous versions.
Also the new default key bindings are nicer and work better in tiling window
managers like dwm.
I think users will appreciate this update.
All of this is subjective? What makes it "more stable"? What bindings
change?
Yes, this is from my own experience using the application since v1.8 on
OpenBSD
for example, copying large files (>10GB) produced a core dump or an
application hang randomly.
Also, on reading very large remote directories (NFS) the application
hanged.
This is no longer a problem with 2.9.
Again this is in my experience using -current on bare metal (T450s and a
DELL T1700)
The key bindings where changed for 2.9, more info here:
"Sane keybinds and switches"
https://github.com/jarun/nnn/issues/422
Index: Makefile
===
RCS file: /cvs/ports/sysutils/nnn/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- Makefile13 Jan 2020 17:53:31 - 1.4
+++ Makefile20 Jan 2020 21:22:46 -
@@ -2,7 +2,7 @@
COMMENT = the missing terminal file browser for X
-V =2.8.1
+V =2.9
DISTNAME = nnn-v${V}
PKGNAME = nnn-${V}
@@ -21,8 +21,6 @@ MASTER_SITES =https://github.com/jarun
RUN_DEPENDS = shells/bash
-MAKE_FLAGS = CFLAGS_OPTIMIZATION=
-
Why? It now builds with "-O3" again.
Reverted the change.
USE_GMAKE = Yes
NO_TEST = Yes
@@ -30,9 +28,7 @@ WRKDIST = ${WRKDIR}/nnn
do-install:
${INSTALL_PROGRAM} ${WRKSRC}/nnn ${PREFIX}/bin/
- ${INSTALL_PROGRAM} ${WRKSRC}/misc/nlay/nlay ${PREFIX}/bin/
${INSTALL_MAN} ${WRKSRC}/nnn.1 ${PREFIX}/man/man1/
- ${INSTALL_MAN} ${WRKSRC}/misc/nlay/nlay.1 ${PREFIX}/man/man1/
Why?
Also, the PLIST update would be missing, so this is wrong in both ways.
nlay is no longer used by nnn.
See:
https://github.com/jarun/nnn/issues/213
I updated the PLIST and re-tested the build.
${INSTALL_DATA_DIR} ${PREFIX}/share/bash-completion/completions/
${INSTALL_DATA} ${WRKSRC}/misc/auto-completion/bash/nnn-completion.bash
\
Here is the updated diff:
Index: Makefile
===
RCS file: /cvs/ports/sysutils/nnn/Makefile,v
retrieving revision 1.4
diff -u -p -u -r1.4 Makefile
--- Makefile 13 Jan 2020 17:53:31 - 1.4
+++ Makefile 20 Jan 2020 22:00:32 -
@@ -2,7 +2,7 @@
COMMENT = the missing terminal file browser for X
-V = 2.8.1
+V = 2.9
DISTNAME = nnn-v${V}
PKGNAME = nnn-${V}
@@ -30,9 +30,7 @@ WRKDIST = ${WRKDIR}/nnn
do-install:
${INSTALL_PROGRAM} ${WRKSRC}/nnn ${PREFIX}/bin/
- ${INSTALL_PROGRAM} ${WRKSRC}/misc/nlay/nlay ${PREFIX}/bin/
${INSTALL_MAN} ${WRKSRC}/nnn.1 ${PREFIX}/man/man1/
- ${INSTALL_MAN} ${WRKSRC}/misc/nlay/nlay.1 ${PREFIX}/man/man1/
${INSTALL_DATA_DIR} ${PREFIX}/share/bash-completion/completions/
${INSTALL_DATA}
${WRKSRC}/misc/auto-completion/bash/nnn-completion.bash \
Index: distinfo
===
RCS file: /cvs/ports/sysutils/nnn/distinfo,v
retrieving revision 1.2
diff -u -p -u -r1.2 distinfo
--- distinfo 13 Jan 2020 17:53:32 - 1.2
+++ distinfo 20 Jan 2020 22:00:32 -
@@ -1,2 +1,2 @@
-SHA256 (nnn-v2.8.1.tar.gz) = 4Pr45ifU+GBQ9XyzHu4hvw4hOK3vjtVBKwc12ptdh7w=
-SIZE (nnn-v2.8.1.tar.gz) = 91353
+SHA256 (nnn-v2.9.tar.gz) = ugsHsNh7ptZEIlnal22OM+1pjeQygjr7b8b2gBy92fY=
+SIZE (nnn-v2.9.tar.gz) = 99324
Index: pkg/PLIST
===
RCS file: /cvs/ports/sysutils/nnn/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -u -r1.2 PLIST
--- pkg/PLIST 13 Jan 2020 17:53:32 - 1.2
+++ pkg/PLIST 20 Jan 2020 22:00:32 -
@@ -1,7 +1,5 @@
@comment $OpenBSD: PLIST,v 1.2 2020/01/13 17:53:32 bket Exp $
-bin/nlay
@bin bin/nnn
-@man man/man1/nlay.1
@man man/man1/nnn.1
share/bash-completion/
share/bash-completion/completions/
Re: [NEW] devel/p5-Version-Compare
On Mon, Jan 20, 2020 at 01:21:47PM -0800, Andrew Hewus Fresh wrote: > On Mon, Jan 20, 2020 at 03:00:30PM -0500, Chris Bennett wrote: > > On Mon, Jan 20, 2020 at 04:15:42PM +0100, Jeremie Courreges-Anglas wrote: > > > On Sun, Jan 19 2020, Chris Bennett > > > wrote: > > > > This tests perl module versions to see which is higher version. > > > > > > > > I have set TEST_POD and RELEASE_TESTING. > > > > > > > > Unless there is some objection, I will set release and author testing > > > > in future Perl ports also. The mechanism is there. It seems worthwhile > > > > to use it, unless this places too big a burden on bulk builds? > > > > > > > > Comments? > > > > > > It's not our job to do release and documentation testing. Please leave > > > this out of the Makefile. > > > > > > > Honestly, I picked submitting this simple port exactly to bring up that > > question. > > > > What I am seeing in the ports tree, just looking at devel/p5-* are, > > for example. > > > > devel/p5-Mock-Config (and several others just under devel) > > has MAKE_ENV += RELEASE_TESTING=Yes TEST_POD=Yes > > > > devel/p5-YAML > > has TEST_ENV += AUTHOR_TESTING=1 > > > > When I submitted p5-PGObject, > > https://marc.info/?l=openbsd-ports=157645754310168=2 > > > > I got a response: > > > > This could use "MAKE_ENV=TEST_POD=yes RELEASE_TESTING=''" > > so that tests work the same no matter the environment. > > > > Other than that, OK afresh1@ if someone wants to import. > > - > > > > I don't know what to make of the RELEASE_TESTING='' part. > > > This specifically *disables* release testing, no matter whether someone > decided to set it in their local environment. It's mostly documenting > that we are choosing not to run those tests so that in the future folks > don't try. I usually find that if the release testing Just Works, I > prefer to enable it. > > > There is a lot of personal preference there. My preference is to make > the ports tree not do something different depending on the environment > as it makes problems easier to understand. > OK, that helps a lot. I will go ahead and submit with MAKE_ENV=TEST_POD=yes RELEASE_TESTING='' Since LedgerSMB is accounting software, which can have severe consequences to business owners and employees, I want to keep the database testing in for those other dependency modules. I see that PostgreSQL updates often cause problems, so testing seems proper for those ports. I will revise the ports I already submitted. Seriously Thanks! :} -- Chris Bennett
Re: [NEW] benchmarks/fio
On 2020/01/20 16:22, Kurt Miller wrote:
> fio is a IO benchmarking tool that can simulate various user defined
> workloads. fio will spawn a number of threads or processes doing a
> particular type of IO action as specified by the user. It takes a
> number of global parameters, each inherited by the thread unless other
> parameters given to them overriding that setting. The typical use of
> fio is to write a job file matching the IO load one wants to simulate.
>
> tested on aarch64/amd64/i386
>
> okay?
: DPB_PROPERTIES= parallel
I don't feel strongly either way, but that's usually only done for
fairly large ports, or ones on the path to something that blocks a lot
of other ports.
: COMMENT=flexible I/O tester
:
: GH_ACCOUNT= axboe
: GH_PROJECT= fio
: GH_TAGNAME= fio-3.17
: PKGNAME=${GH_TAGNAME}
:
: CATEGORIES= benchmarks
:
: HOMEPAGE= https://github.com/axboe/fio
https://fio.readthedocs.io/ might be better?
:
: MAINTAINER= Kurt Miller
:
: # GPLv2+
It's GPLv2 only. The author also requests that any published results
mention that fio was used and which version (MORAL-LICENSE in the
distribution), it might be nice to add a quick note about that to the
comment?
: PERMIT_PACKAGE= Yes
:
: WANTLIB=c m pthread z
:
: USE_GMAKE= Yes
: SEPARATE_BUILD= Yes
:
: CONFIGURE_STYLE=simple
:
: .include
Hidden behind the pretty-printed "CC " lines it uses
-march=native (which is no good for package builds) and -O3. Could you
add these please so it displays the commands and honours CFLAGS?
MAKE_FLAGS= V=1 \
EXTFLAGS="${CFLAGS}"
CONFIGURE_ARGS= --disable-optimizations \
--disable-native
OK with those or similar.
Re: update to libvips 8.9.0
Le lundi 20 janvier 2020 09:13:52 CET, vous avez écrit : > On Sun, Jan 19, 2020 at 11:00:03PM +0100, Stephane Guedon wrote: > > > It seem you haven't updated the latest Makefile. > > > > Yes I did : newest version number, checked with it. > > > > All I see to miss is maybe my name as maintainer. > > Do I miss more ? > > In Makefile : > - SHARED_LIBS should start at 0.0 > - LIB_DEPENDS should be one dep per line > > Also pkg/DESCR is shorter, any reason why ? Mistake happened. Apologies. libvips.8.9.0.tar.gz Description: application/compressed-tar
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/01/20 14:41:02 Modified files: net/dnscontrol : Makefile Log message: dnscontrol tweaks: - add aarch64 to ONLY_FOR_ARCHS now that it has golang - drop "MODGO_FLAGS= -tags nosystemd", it was only being passed in for tests which it didn't change, and didn't do anything else. - add the default MODGO_FLAGS from go.port.mk to the custom build commands, to honour MAKE_JOBS/debug settings, and display source files being built
Re: [update] net/dnscontrol -> 2.10.0
On 2020/01/20 17:39, Paco Esteban wrote: > Hi > > On Mon, 20 Jan 2020, karlis.mikels...@lf.lv wrote: > > > Hello, > > > > Please find attached patch to update DNSControl to latest stable (2.10.0) > > version. > > It builds and tests pass for me on amd64. It also works fine with my > small dns zones. #546 is specially useful for me. > > Thanks for the update. > > -- > Paco Esteban. > 5818130B8A6DBC03 > Thanks, committed.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/01/20 14:39:06 Modified files: net/dnscontrol : Makefile distinfo Log message: update to dnscontrol-2.10.0, from Karlis Mikelson, thanks Paco Esteban for tests/feedback
Re: [update] nnn 2.8.1 > v2.9
On Mon, Jan 20, 2020 at 03:17:09PM -0400, Dnsgate wrote:
> This is a port update for the CLI file manager sysutils/nnn
>
> This patch updates nnn from 2.8.1 to 2.9
Please send diffs inline, not attached.
> Changes and version info here:
> https://github.com/jarun/nnn/releases/tag/v2.9
>
> Tested on amd64 for a couple of days and I have found it to be more stable
> than the previous versions.
> Also the new default key bindings are nicer and work better in tiling window
> managers like dwm.
>
> I think users will appreciate this update.
All of this is subjective? What makes it "more stable"? What bindings
change?
>Index: Makefile
>===
>RCS file: /cvs/ports/sysutils/nnn/Makefile,v
>retrieving revision 1.4
>diff -u -p -r1.4 Makefile
>--- Makefile 13 Jan 2020 17:53:31 - 1.4
>+++ Makefile 20 Jan 2020 21:22:46 -
>@@ -2,7 +2,7 @@
>
> COMMENT = the missing terminal file browser for X
>
>-V = 2.8.1
>+V = 2.9
> DISTNAME =nnn-v${V}
> PKGNAME = nnn-${V}
>
>@@ -21,8 +21,6 @@ MASTER_SITES = https://github.com/jarun
>
> RUN_DEPENDS = shells/bash
>
>-MAKE_FLAGS = CFLAGS_OPTIMIZATION=
>-
Why? It now builds with "-O3" again.
> USE_GMAKE = Yes
> NO_TEST = Yes
>
>@@ -30,9 +28,7 @@ WRKDIST =${WRKDIR}/nnn
>
> do-install:
> ${INSTALL_PROGRAM} ${WRKSRC}/nnn ${PREFIX}/bin/
>- ${INSTALL_PROGRAM} ${WRKSRC}/misc/nlay/nlay ${PREFIX}/bin/
> ${INSTALL_MAN} ${WRKSRC}/nnn.1 ${PREFIX}/man/man1/
>- ${INSTALL_MAN} ${WRKSRC}/misc/nlay/nlay.1 ${PREFIX}/man/man1/
Why?
Also, the PLIST update would be missing, so this is wrong in both ways.
>
> ${INSTALL_DATA_DIR} ${PREFIX}/share/bash-completion/completions/
> ${INSTALL_DATA} ${WRKSRC}/misc/auto-completion/bash/nnn-completion.bash
> \
[NEW] benchmarks/fio
fio is a IO benchmarking tool that can simulate various user defined workloads. fio will spawn a number of threads or processes doing a particular type of IO action as specified by the user. It takes a number of global parameters, each inherited by the thread unless other parameters given to them overriding that setting. The typical use of fio is to write a job file matching the IO load one wants to simulate. tested on aarch64/amd64/i386 okay? fio.tar.gz Description: application/compressed-tar
Re: [NEW] devel/p5-Version-Compare
On Mon, Jan 20, 2020 at 03:00:30PM -0500, Chris Bennett wrote: > On Mon, Jan 20, 2020 at 04:15:42PM +0100, Jeremie Courreges-Anglas wrote: > > On Sun, Jan 19 2020, Chris Bennett wrote: > > > This tests perl module versions to see which is higher version. > > > > > > I have set TEST_POD and RELEASE_TESTING. > > > > > > Unless there is some objection, I will set release and author testing > > > in future Perl ports also. The mechanism is there. It seems worthwhile > > > to use it, unless this places too big a burden on bulk builds? > > > > > > Comments? > > > > It's not our job to do release and documentation testing. Please leave > > this out of the Makefile. > > > > Honestly, I picked submitting this simple port exactly to bring up that > question. > > What I am seeing in the ports tree, just looking at devel/p5-* are, > for example. > > devel/p5-Mock-Config (and several others just under devel) > has MAKE_ENV += RELEASE_TESTING=Yes TEST_POD=Yes > > devel/p5-YAML > has TEST_ENV += AUTHOR_TESTING=1 > > When I submitted p5-PGObject, > https://marc.info/?l=openbsd-ports=157645754310168=2 > > I got a response: > > This could use "MAKE_ENV=TEST_POD=yes RELEASE_TESTING=''" > so that tests work the same no matter the environment. > > Other than that, OK afresh1@ if someone wants to import. > - > > I don't know what to make of the RELEASE_TESTING='' part. This specifically *disables* release testing, no matter whether someone decided to set it in their local environment. It's mostly documenting that we are choosing not to run those tests so that in the future folks don't try. I usually find that if the release testing Just Works, I prefer to enable it. > So I don't see a clear answer on what is right, wrong or ambivalent. > I'm going to at least do this testing myself before submitting, since > these are new vs updated ports. > But what should or shouldn't end up in the tests in the Makefile > I submit? There is a lot of personal preference there. My preference is to make the ports tree not do something different depending on the environment as it makes problems easier to understand. > > Is this library useful for other (upcoming or existing) ports? > > Yes, this is for upcoming LedgerSMB port. > It is in the required section of the cpanfile. > > https://github.com/ledgersmb/LedgerSMB/blob/master/cpanfile > > Thanks, > Chris Bennett > > > -- andrew - http://afresh1.com Real programmers don't document. If it was hard to write, it should be hard to understand.
[update] nnn 2.8.1 > v2.9
This is a port update for the CLI file manager sysutils/nnn
This patch updates nnn from 2.8.1 to 2.9
Changes and version info here:
https://github.com/jarun/nnn/releases/tag/v2.9
Tested on amd64 for a couple of days and I have found it to be more
stable than the previous versions.
Also the new default key bindings are nicer and work better in tiling
window managers like dwm.
I think users will appreciate this update.
- Lorenzo (dnsgate)
Index: Makefile
===
RCS file: /cvs/ports/sysutils/nnn/Makefile,v
retrieving revision 1.4
diff -u -p -u -r1.4 Makefile
--- Makefile 13 Jan 2020 17:53:31 - 1.4
+++ Makefile 20 Jan 2020 19:13:38 -
@@ -2,7 +2,7 @@
COMMENT = the missing terminal file browser for X
-V = 2.8.1
+V = 2.9
DISTNAME = nnn-v${V}
PKGNAME = nnn-${V}
@@ -21,8 +21,6 @@ MASTER_SITES = https://github.com/jarun
RUN_DEPENDS = shells/bash
-MAKE_FLAGS = CFLAGS_OPTIMIZATION=
-
USE_GMAKE = Yes
NO_TEST = Yes
@@ -30,9 +28,7 @@ WRKDIST = ${WRKDIR}/nnn
do-install:
${INSTALL_PROGRAM} ${WRKSRC}/nnn ${PREFIX}/bin/
- ${INSTALL_PROGRAM} ${WRKSRC}/misc/nlay/nlay ${PREFIX}/bin/
${INSTALL_MAN} ${WRKSRC}/nnn.1 ${PREFIX}/man/man1/
- ${INSTALL_MAN} ${WRKSRC}/misc/nlay/nlay.1 ${PREFIX}/man/man1/
${INSTALL_DATA_DIR} ${PREFIX}/share/bash-completion/completions/
${INSTALL_DATA} ${WRKSRC}/misc/auto-completion/bash/nnn-completion.bash \
Index: distinfo
===
RCS file: /cvs/ports/sysutils/nnn/distinfo,v
retrieving revision 1.2
diff -u -p -u -r1.2 distinfo
--- distinfo 13 Jan 2020 17:53:32 - 1.2
+++ distinfo 20 Jan 2020 19:13:38 -
@@ -1,2 +1,2 @@
-SHA256 (nnn-v2.8.1.tar.gz) = 4Pr45ifU+GBQ9XyzHu4hvw4hOK3vjtVBKwc12ptdh7w=
-SIZE (nnn-v2.8.1.tar.gz) = 91353
+SHA256 (nnn-v2.9.tar.gz) = ugsHsNh7ptZEIlnal22OM+1pjeQygjr7b8b2gBy92fY=
+SIZE (nnn-v2.9.tar.gz) = 99324
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: an...@cvs.openbsd.org 2020/01/20 14:00:38 Modified files: mail/mdsort: Makefile distinfo Log message: Update to mdsort-5.1.0.
Re: [NEW] devel/p5-Version-Compare
On Mon, Jan 20, 2020 at 04:15:42PM +0100, Jeremie Courreges-Anglas wrote: > On Sun, Jan 19 2020, Chris Bennett wrote: > > This tests perl module versions to see which is higher version. > > > > I have set TEST_POD and RELEASE_TESTING. > > > > Unless there is some objection, I will set release and author testing > > in future Perl ports also. The mechanism is there. It seems worthwhile > > to use it, unless this places too big a burden on bulk builds? > > > > Comments? > > It's not our job to do release and documentation testing. Please leave > this out of the Makefile. > Honestly, I picked submitting this simple port exactly to bring up that question. What I am seeing in the ports tree, just looking at devel/p5-* are, for example. devel/p5-Mock-Config (and several others just under devel) has MAKE_ENV += RELEASE_TESTING=Yes TEST_POD=Yes devel/p5-YAML has TEST_ENV += AUTHOR_TESTING=1 When I submitted p5-PGObject, https://marc.info/?l=openbsd-ports=157645754310168=2 I got a response: This could use "MAKE_ENV=TEST_POD=yes RELEASE_TESTING=''" so that tests work the same no matter the environment. Other than that, OK afresh1@ if someone wants to import. - I don't know what to make of the RELEASE_TESTING='' part. So I don't see a clear answer on what is right, wrong or ambivalent. I'm going to at least do this testing myself before submitting, since these are new vs updated ports. But what should or shouldn't end up in the tests in the Makefile I submit? > Is this library useful for other (upcoming or existing) ports? Yes, this is for upcoming LedgerSMB port. It is in the required section of the cpanfile. https://github.com/ledgersmb/LedgerSMB/blob/master/cpanfile Thanks, Chris Bennett
Re: UPDATE: devel/gmake 4.2.1 => 4.3
Bulk obviously needed but I'm not expecting huge problems with 4.3 since they relented on the most controversial change (prerequisites on suffix rules) and made it only apply in POSIX mode. They intend to change it in normal mode in the future, so we will need to keep an eye out for "warning: ignoring prerequisites on suffix rule definition" messages. -- Sent from a phone, apologies for poor formatting. On 20 January 2020 15:40:13 Marc Espie wrote: On Mon, Jan 20, 2020 at 09:58:41AM -0500, Brian Callahan wrote: Hi ports -- Attached is an update to gmake. A changelog can be found here: http://git.savannah.gnu.org/cgit/make.git/tree/NEWS There is a lot of churn because upstream reworked their directory structure. All tests pass on amd64 and mips64. One test fails on arm64 (but the same test fails with 4.2.1 too). Obviously needs more testing than I can provide, but here for the interested. As usual, any gmake update needs at least a bulk...
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: p...@cvs.openbsd.org2020/01/20 12:25:56 Modified files: textproc/py-elasticsearch: Makefile distinfo textproc/py-elasticsearch/pkg: PLIST Log message: Update py-elasticsearch 7.1.0 -> 7.5.1 Changelog: https://github.com/elastic/elasticsearch-py/blob/master/Changelog.rst
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: p...@cvs.openbsd.org2020/01/20 12:04:48 Modified files: sysutils/logstash: Makefile distinfo sysutils/logstash/pkg: PLIST Log message: Update logstash 7.5.0 -> 7.5.1 Relase notes: https://www.elastic.co/guide/en/logstash/7.5/logstash-7-5-1.html
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: p...@cvs.openbsd.org2020/01/20 12:04:04 Modified files: sysutils/beats/filebeat: Makefile distinfo Log message: Update filebeat 7.4.2 -> 7.5.1 Relase notes: https://www.elastic.co/guide/en/beats/libbeat/7.5/release-notes-7.5.1.html
Re: 回复: [NEW] www/p5-Plack-Request-WithEncoding
On Sun, Jan 19, 2020 at 12:57:44PM +, wen heping wrote: > 1 BUILD_DEPENDS line is not need, since there is CONFIGURE_STYLE = > modbuild > 2 p5-Plack should removed from TEST_DEPENDS since it is RUN_DEPENDS > 3 Better replace pkg/DESCR with the module's DESCRIPTION > > Cheers ! > wen Attached is with the above suggestions, except that I left out the last line in the module's DESCRIPTION with the reference to look at link to a section of the DESCRIPTION in particular. I appreciate the help. Porting has changed (very much for the better) since I last did ports. -- Chris Bennett p5-Plack-Request-WithEncoding.tar.gz Description: GNU Zip compressed data
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: p...@cvs.openbsd.org2020/01/20 12:00:40 Modified files: www/kibana : Makefile distinfo www/kibana/pkg : PLIST Log message: Update kibana 7.5.0 -> 7.5.1 Relase notes: https://www.elastic.co/guide/en/kibana/7.5/release-notes-7.5.1.html
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: p...@cvs.openbsd.org2020/01/20 11:59:41 Modified files: textproc/elasticsearch: Makefile distinfo textproc/elasticsearch/pkg: PLIST Log message: Update elasticsearch 7.5.0 -> 7.5.1 Relase notes: https://www.elastic.co/guide/en/elasticsearch/reference/7.5/release-notes-7.5.1.html
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2020/01/20 11:10:23 Modified files: graphics/termtosvg: Makefile distinfo graphics/termtosvg/pkg: PLIST Log message: Update termtosvg to 1.1.0.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: p...@cvs.openbsd.org2020/01/20 10:49:05 Modified files: sysutils/ansible: Makefile distinfo sysutils/ansible/pkg: PLIST-html PLIST-main Log message: Update ansible 2.9.2 -> 2.9.3 Changelog: https://github.com/ansible/ansible/blob/stable-2.9/changelogs/CHANGELOG-v2.9.rst#v2-9-3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2020/01/20 10:42:06 Modified files: sysutils/ggrep : Makefile distinfo Log message: maintenance update to 3.4
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2020/01/20 10:16:14 Modified files: graphics/libansilove: Makefile distinfo Log message: Update libansilove to 1.1.9.
Re: [update] net/dnscontrol -> 2.10.0
Hi On Mon, 20 Jan 2020, karlis.mikels...@lf.lv wrote: > Hello, > > Please find attached patch to update DNSControl to latest stable (2.10.0) > version. It builds and tests pass for me on amd64. It also works fine with my small dns zones. #546 is specially useful for me. Thanks for the update. -- Paco Esteban. 5818130B8A6DBC03
[macppc, all archs] devel/physfs: fix endianness detection
Hi!
--
Backstory:
While trying to test the wip port of VV [0] on macppc, i've found
out that the bundled physfs was not able to detect zipfiles as such on
this platform, and fixed the issue. It appears that VV uses the same
version than devel/physfs.
So i've tried, still on macppc, to see how games/blobby, a physfs
consumer using zip resources files, fares. It appears that blobby is
broken at runtime on all archs, so i've updated blobby [1]. It appears
that while zipfiles are loaded on amd64, they're not on macppc without
the fix i'm proposing here.
--
The problem actually is that physfs' internal endianness detection is
too basic to work. It was missing `__powerpc__', so i used ,
as seen in the already existing lzma patch.
That diff has been tested successfully in a partial bulk against
consumers on amd64 [2], and macppc. According to check_sym, there is
no dynamic changes.
Because the issue is happening at runtime, i had to test the runtime on
2 platforms, so it's pretty lightly tested. Special care has been taken
about texture and sound items. Here are the results with tested
architectures -- i've found no issues due to this patch:
D=no datafiles, P=not on powerpc, L=x86/LE only, !=non-physfs issues
devel/sdl-sound amd64, macppc
emulators/dosbox amd64, macppc (ran DOOM II)
D games/barony
games/blobby amd64, macppc (-wip version)
games/colobot/colobot amd64, !macppc (ppc: hang forever)
games/dxx-rebirth amd64, !macppc (ppc: uchar issue?)
games/gargoyleamd64, macppc
L games/hedgewars amd64
games/lincity-ng amd64, macppc
games/loveamd64, macppc
games/neverball amd64, macppc
games/roadfighter amd64, macppc
P games/solarus/rothamd64
P games/solarus/solarus amd64
P games/solarus/zsdxamd64
P games/solarus/zsxdamd64
L games/sumwars amd64
L games/warzone2100 amd64
Comments/feedback are welcome,
Charlène.
[0] https://github.com/jasperla/openbsd-wip/tree/master/games/vv
[1] https://github.com/jasperla/openbsd-wip/tree/master/games/blobby
[2] https://bin.charlenew.xyz/physfs_logs.tgz
Index: Makefile
===
RCS file: /cvs/ports/devel/physfs/Makefile,v
retrieving revision 1.16
diff -u -p -u -p -r1.16 Makefile
--- Makefile4 Aug 2019 20:52:47 - 1.16
+++ Makefile20 Jan 2020 15:42:04 -
@@ -3,6 +3,7 @@
COMMENT= library to provide abstract access to various archives
DISTNAME= physfs-3.0.2
+REVISION= 0
CATEGORIES=devel
MASTER_SITES= ${HOMEPAGE}downloads/
EXTRACT_SUFX= .tar.bz2
Index: patches/patch-src_physfs_internal_h
===
RCS file: patches/patch-src_physfs_internal_h
diff -N patches/patch-src_physfs_internal_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_physfs_internal_h 20 Jan 2020 15:42:04 -
@@ -0,0 +1,26 @@
+$OpenBSD$
+
+Fix endianess detection on powerpc (and maybe more BE_ARCHS)
+
+Index: src/physfs_internal.h
+--- src/physfs_internal.h.orig
src/physfs_internal.h
+@@ -221,6 +221,10 @@ extern void SZIP_global_init(void);
+ #include
+ #define PHYSFS_BYTEORDER __BYTE_ORDER
+ #else /* __linux__ */
++#ifdef __OpenBSD__
++#include
++#define PHYSFS_BYTEORDER BYTE_ORDER
++#else /* __OpenBSD__ */
+ #if defined(__hppa__) || \
+ defined(__m68k__) || defined(mc68000) || defined(_M_M68K) || \
+ (defined(__MIPS__) && defined(__MISPEB__)) || \
+@@ -230,6 +234,7 @@ extern void SZIP_global_init(void);
+ #else
+ #define PHYSFS_BYTEORDER PHYSFS_LIL_ENDIAN
+ #endif
++#endif /* __OpenBSD__ */
+ #endif /* __linux__ */
+
+
Re: [maintainer update] lang/kawa-3.1
timo.my...@bittivirhe.fi (Timo Myyrä) writes:
> timo.my...@bittivirhe.fi (Timo Myyrä) writes:
>
>> Hi,
>>
>> Kawa got new release with following release notes:
>> - Updates for Java 9 and newer.
>> - Support justification ~<...~> in format (thanks to Helmut Eller).
>> - Partial (and highly experimental) support for the Language Server Protocol
>> (used by editors and IDEs for on-the-fly syntax checking and more).
>> - Revert 3.0 change in allocating closure objects for inlined functions.
>> - Enhancements to arrays to match SRFI 163 and SRFI 164:
>> The type gvector is a “generalized vector”.
>> Add optional port parameter to format-array.
>> The build-array procedure takes an optional setter procedure.
>> New procedures array-shape, ->shape.
>> - In array constructors, index keywords must be all or none: [int[] length:
>> 5 11 22] or [int[] length: 5 1: 22 0: 11].
>> - Various improvements in the Common Lisp implementation, by Helmut Eller.
>> - New --max-errors option.
>> - The classes created by define-record-type now extends kawa.lang.Record,
>> which adds some conveniences, such as printing.
>> - Support for source location ranges with an end position.
>> - Various improvements when running under DomTerm include clickable error
>> message locations.
>> - Many bug-fixes and minor improvements.
>>
>>
>> Seems to build and run nicely on amd64.
>>
>> timo
>>
>> Index: Makefile
>> ===
>> RCS file: /cvs/ports/lang/kawa/Makefile,v
>> retrieving revision 1.19
>> diff -u -p -u -p -r1.19 Makefile
>> --- Makefile 12 Jul 2019 21:02:22 - 1.19
>> +++ Makefile 8 Jan 2020 17:20:51 -
>> @@ -2,8 +2,7 @@
>>
>> COMMENT=Scheme and language framework for the Java platform
>>
>> -DISTNAME= kawa-3.0
>> -REVISION= 0
>> +DISTNAME= kawa-3.1
>> CATEGORIES= lang java
>>
>> HOMEPAGE= https://www.gnu.org/software/kawa/
>> @@ -21,7 +20,7 @@ TEST_DEPENDS= ${RUN_DEPENDS}
>> USE_GMAKE= Yes
>>
>> AUTOCONF_VERSION= 2.69
>> -AUTOMAKE_VERSION= 1.15
>> +AUTOMAKE_VERSION= 1.16
>>
>> WANTLIB+= c curses readline
>> BUILD_DEPENDS= print/texinfo \
>> @@ -30,7 +29,7 @@ BUILD_DEPENDS= print/texinfo \
>>
>> CONFIGURE_STYLE=gnu
>> CONFIGURE_ARGS+=--enable-kawa-frontend
>> -CONFIGURE_ENV+= AUTOMAKE=${LOCALBASE}/bin/automake-1.15 \
>> +CONFIGURE_ENV+= AUTOMAKE=${LOCALBASE}/bin/automake-1.16 \
>> AUTOCONF=${LOCALBASE}/bin/autoconf-2.69
>>
>> MAKE_FLAGS= JAVAC=${JAVA_HOME}/bin/javac \
>> Index: distinfo
>> ===
>> RCS file: /cvs/ports/lang/kawa/distinfo,v
>> retrieving revision 1.5
>> diff -u -p -u -p -r1.5 distinfo
>> --- distinfo 11 May 2018 10:37:17 - 1.5
>> +++ distinfo 8 Jan 2020 17:20:51 -
>> @@ -1,2 +1,2 @@
>> -SHA256 (kawa-3.0.tar.gz) = Hm6FIXvW2MKgw0eIgqRXAxTfa5UHj+exIlkRw5q/OM0=
>> -SIZE (kawa-3.0.tar.gz) = 3393879
>> +SHA256 (kawa-3.1.tar.gz) = WxAGMecB8yaH33ArBFOd5wB2jPr5N0GBV+gaU3sXERg=
>> +SIZE (kawa-3.1.tar.gz) = 3537007
>
> Lets wait a bit with this update, there seems to be minor issues with the
> release. Upstream is working on those and will release 3.1.1 soon. We can then
> update straight to it.
>
> Timo
Ok, here's updated diff which fixes --browse-manual and some smaller issues.
This fixes binary paths in man pages as well.
timo
Index: Makefile
===
RCS file: /cvs/ports/lang/kawa/Makefile,v
retrieving revision 1.19
diff -u -p -u -p -r1.19 Makefile
--- Makefile12 Jul 2019 21:02:22 - 1.19
+++ Makefile20 Jan 2020 15:47:21 -
@@ -2,8 +2,7 @@
COMMENT= Scheme and language framework for the Java platform
-DISTNAME= kawa-3.0
-REVISION= 0
+DISTNAME= kawa-3.1.1
CATEGORIES=lang java
HOMEPAGE= https://www.gnu.org/software/kawa/
@@ -21,7 +20,7 @@ TEST_DEPENDS= ${RUN_DEPENDS}
USE_GMAKE= Yes
AUTOCONF_VERSION= 2.69
-AUTOMAKE_VERSION= 1.15
+AUTOMAKE_VERSION= 1.16
WANTLIB+= c curses readline
BUILD_DEPENDS= print/texinfo \
@@ -30,7 +29,7 @@ BUILD_DEPENDS=print/texinfo \
CONFIGURE_STYLE= gnu
CONFIGURE_ARGS+= --enable-kawa-frontend
-CONFIGURE_ENV+=AUTOMAKE=${LOCALBASE}/bin/automake-1.15 \
+CONFIGURE_ENV+=AUTOMAKE=${LOCALBASE}/bin/automake-1.16 \
AUTOCONF=${LOCALBASE}/bin/autoconf-2.69
MAKE_FLAGS=JAVAC=${JAVA_HOME}/bin/javac \
@@ -55,5 +54,6 @@ pre-patch:
xargs fgrep -l "JAR =" | \
xargs sed -i 's,^JAR =.*,JAR = ${JAVA_HOME}/bin/jar,g'; \
touch ${WRKSRC}/configure.ac
+ sed -i
Re: UPDATE: devel/gmake 4.2.1 => 4.3
On 2020-01-20 10:39 AM, Marc Espie wrote: On Mon, Jan 20, 2020 at 09:58:41AM -0500, Brian Callahan wrote: Hi ports -- Attached is an update to gmake. A changelog can be found here: http://git.savannah.gnu.org/cgit/make.git/tree/NEWS There is a lot of churn because upstream reworked their directory structure. All tests pass on amd64 and mips64. One test fails on arm64 (but the same test fails with 4.2.1 too). Obviously needs more testing than I can provide, but here for the interested. As usual, any gmake update needs at least a bulk... Agreed. Hence my original message. I'm not equipped to run bulks here, so I sent it to the list in the hopes that someone would pick it up...
Re: UPDATE: devel/gmake 4.2.1 => 4.3
On Mon, Jan 20, 2020 at 09:58:41AM -0500, Brian Callahan wrote: > Hi ports -- > > Attached is an update to gmake. > A changelog can be found here: > http://git.savannah.gnu.org/cgit/make.git/tree/NEWS > > There is a lot of churn because upstream reworked their directory structure. > > All tests pass on amd64 and mips64. One test fails on arm64 (but the same > test fails with 4.2.1 too). > > Obviously needs more testing than I can provide, but here for the > interested. As usual, any gmake update needs at least a bulk...
Re: [PATCH] Update inputmethods/anthy from 9100 to 0.4
Bryan, sorry for the double email, as always I forgot to CC ports. On Sun, Jan 19, 2020 at 10:48:18AM +0900, Bryan Linton wrote: > On 2020-01-18 13:16:58, Omar Polo wrote: > > Hi, > > > > On Thu, Jan 09, 2020 at 11:34:34PM +0900, Bryan Linton wrote: > > > Hello ports@ > > > > > > I was attempting to make some changes to inputmethods/anthy for > > > another purpose when I noticed it was woefully out of date. > > > > > > Version 9100h was released in 2009. Version 0.4 was released six > > > months ago (in 2019). > > > > > > [snip] > > > > > > Concerns: > > > > > > * I have not tested the emacs module because I do not use emacs. I > > > have however tested it in Firefox, leafpad, a Japanized xterm, and > > > editors/nvi running in said Japanized xterm. More testing would > > > be appreciated though. > > > > Thanks for working on this! It compiles here, but I cannot judge > > the quality of the patch. Some comments after a bit of testing with > > inputmethod/uim: > > > > Hello, thank you for testing! Some comments follow inline. > > > - firefox (and possibly other programs) need some directories to > >be unveiled [0]. > > > > Yes, I was the one who sent that email too :) I've realized that, but I've left the comment primarly for other interested in testing this. > It's not specific to this update though. Even the old version of > anthy would need those directories unveiled. > > I have another update to anthy that switches it to using a common > directory in line with what Theo suggested later in that thread. But > I wanted to hopefully get this update in-tree before going forward > with that. Oh, this is great! I'm looking forward to it. > > - with gajim (gtk3) and emacs (gtk3) works as expected > > > > Great, thanks! This was the one use-case I couldn't test myself > since I don't use emacs. > > > - xterm and emacs (compiled with the lucid toolkit) sort of. While > >typing, the characters are displayed as rectangles (similarly > >to when a font is missing), but after pressing enter the whole > >word is displayed properly. Also, the selection box does not > >appear in these programs (but these probably are issues with uim > >rather than anthy.) > > > > Yes, this definitely sounds like a uim issue. To be clear, is > this a regression? I.e. Did this work OK before, but broke with > this update? It's not a regression, it's a problem I have with uim plus any programs that use the native X11 input method (and I don't have knowledge on that matter.) I have XMODIFIERS set up as per uim description. Also, I'm sorry, but I've written a confusing comment. (at the time of the last mail) I had tested only emacs with the standard x input method (uim in that case), because I don't have much knowledge of "native emacs input methods" and I confused myself with anthy.el and uim.el... However, I've now tested anthy.el properly and I can confirm that it's *awesome*. The only drawbacks is that it needs LANG=ja_JP.UTF-8, otherwise you get glibberish for some characters (i.e. "\343\200\202" instead of "。") Another thing that I've noticed, the description for anthy says With its complement package anthy-emacs, [...] but here the package is emacs-anthy: $ pkg_info | grep emacs-anthy emacs-anthy-0.4p4 emacs files for anthy (patch below) > Also as a follow-up, can you check whether you're using the > "Anthy" or the "Anthy (UTF-8)" input method in UIM? If it's the > former, does it fix this if you switch it to UTF-8? > > As I mentioned in the initial email, the internals of anthy have > switched to be completely UTF-8. If you're using the old input > method, does switching to "Anthy (UTF-8)" in uim fix this? Ups, I didn't mentioned in the mail, but I have only used "Anthy (UTF-8)", since I got strange (for the lack of a better term) input with "Anthy" (non utf8) too. I have installed anthy to test your patch (I was procastinating installing an input method for japanese.) > Failing that, does running xterm with the script I've pasted in > below fix this? Unfortunately not. I've also installed the font you are using, without success. > snip... So, to recap, anthy.el works, firefox and iridium too, and I have only an issue with uim that's not a regression. Cheers! -- /Omar Polo --- pkg/DESCR-main.orig Tue Nov 21 01:12:40 2006 +++ pkg/DESCR-main Mon Jan 20 14:38:51 2020 @@ -1,7 +1,7 @@ Anthy is a japanese input method library that can be used from many setups. -With its complement package anthy-emacs, it can be used with +With its complement package emacs-anthy, it can be used with emacs, using the simple anthy-agent wedge for communication. It can also be accessed from uim.
Re: [NEW] devel/p5-Version-Compare
On Sun, Jan 19 2020, Chris Bennett wrote: > This tests perl module versions to see which is higher version. > > I have set TEST_POD and RELEASE_TESTING. > > Unless there is some objection, I will set release and author testing > in future Perl ports also. The mechanism is there. It seems worthwhile > to use it, unless this places too big a burden on bulk builds? > > Comments? It's not our job to do release and documentation testing. Please leave this out of the Makefile. Is this library useful for other (upcoming or existing) ports? If not, there's little reason to add it to the tree. If it's useful to you for personal reasons then you taking maintainership would help. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
UPDATE: devel/gmake 4.2.1 => 4.3
Hi ports --
Attached is an update to gmake.
A changelog can be found here:
http://git.savannah.gnu.org/cgit/make.git/tree/NEWS
There is a lot of churn because upstream reworked their directory structure.
All tests pass on amd64 and mips64. One test fails on arm64 (but the
same test fails with 4.2.1 too).
Obviously needs more testing than I can provide, but here for the
interested.
Add debug package while here.
Comments/OKs welcome.
~Brian
Index: Makefile
===
RCS file: /cvs/ports/devel/gmake/Makefile,v
retrieving revision 1.63
diff -u -p -r1.63 Makefile
--- Makefile 13 Sep 2019 16:59:34 - 1.63
+++ Makefile 20 Jan 2020 14:54:49 -
@@ -2,12 +2,10 @@
COMMENT= GNU make
-DISTNAME= make-4.2.1
+DISTNAME= make-4.3
PKGNAME= g${DISTNAME}
-REVISION= 4
CATEGORIES= devel
MASTER_SITES= ${MASTER_SITE_GNU:=make/}
-EXTRACT_SUFX= .tar.bz2
HOMEPAGE= https://www.gnu.org/software/make/
@@ -18,12 +16,13 @@ PERMIT_PACKAGE= Yes
WANTLIB= c iconv intl
+DEBUG_PACKAGES = ${BUILD_PACKAGES}
+
SEPARATE_BUILD= Yes
CONFIGURE_STYLE= gnu
CONFIGURE_ARGS= --program-prefix="g" --without-guile
CONFIGURE_ENV= CPPFLAGS="-I${LOCALBASE}/include" \
LDFLAGS="-L${LOCALBASE}/lib"
-MODGNU_CONFIG_GUESS_DIRS= ${WRKSRC}/config
pre-test:
find ${WRKSRC}/tests/scripts -name \*.orig -delete
Index: distinfo
===
RCS file: /cvs/ports/devel/gmake/distinfo,v
retrieving revision 1.9
diff -u -p -r1.9 distinfo
--- distinfo 25 Jun 2016 19:47:11 - 1.9
+++ distinfo 20 Jan 2020 14:54:49 -
@@ -1,2 +1,2 @@
-SHA256 (make-4.2.1.tar.bz2) = 1uJivzYBtC0rHk74MQAp4dzyAIPFRGtLeqZwgf3/xYk=
-SIZE (make-4.2.1.tar.bz2) = 1407126
+SHA256 (make-4.3.tar.gz) = 4F/d5HxffKRctpfpc4lP9PXXnhO3UO1X17Ztje/Hjhk=
+SIZE (make-4.3.tar.gz) = 2317073
Index: patches/patch-Makefile_in
===
RCS file: /cvs/ports/devel/gmake/patches/patch-Makefile_in,v
retrieving revision 1.4
diff -u -p -r1.4 patch-Makefile_in
--- patches/patch-Makefile_in 25 Jun 2016 19:47:11 - 1.4
+++ patches/patch-Makefile_in 20 Jan 2020 14:54:49 -
@@ -1,12 +1,13 @@
$OpenBSD: patch-Makefile_in,v 1.4 2016/06/25 19:47:11 naddy Exp $
Makefile.in.orig Sat Jun 11 01:03:22 2016
-+++ Makefile.in Fri Jun 24 18:19:09 2016
-@@ -481,7 +481,7 @@ EXTRA_make_SOURCES = vmsjobs.c remote-stub.c remote-cs
- noinst_HEADERS = commands.h dep.h filedef.h job.h makeint.h rule.h variable.h \
- debug.h getopt.h gettext.h hash.h output.h os.h
+Index: Makefile.in
+--- Makefile.in.orig
Makefile.in
+@@ -1039,7 +1039,7 @@ make_SOURCES = $(make_SRCS) $(am__append_1) $(am__appe
+ $(am__append_4) $(am__append_5)
+ EXTRA_make_SOURCES = $(amiga_SRCS) $(vms_SRCS)
+ make_LDADD = $(LIBOBJS) $(GUILE_LIBS) lib/libgnu.a $(GETLOADAVG_LIBS) \
+- @LIBINTL@
++ @LTLIBINTL@
--make_LDADD = @LIBOBJS@ @ALLOCA@ $(GLOBLIB) @GETLOADAVG_LIBS@ @LIBINTL@ \
-+make_LDADD = @LIBOBJS@ @ALLOCA@ $(GLOBLIB) @GETLOADAVG_LIBS@ @LTLIBINTL@ \
- $(GUILE_LIBS) $(am__append_1)
- man_MANS = make.1
- AM_CPPFLAGS = $(GLOBINC) $(am__append_2)
+ AM_CPPFLAGS = -Isrc -I$(top_srcdir)/src -Ilib -I$(top_srcdir)/lib \
+ -DLIBDIR=\"$(libdir)\" -DINCLUDEDIR=\"$(includedir)\" \
Index: patches/patch-doc_make_1
===
RCS file: patches/patch-doc_make_1
diff -N patches/patch-doc_make_1
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-doc_make_1 20 Jan 2020 14:54:49 -
@@ -0,0 +1,216 @@
+$OpenBSD$
+
+Since we install GNU make as gmake replace make with gmake in the
+manpage where it makes sense.
+
+Index: doc/make.1
+--- doc/make.1.orig
doc/make.1
+@@ -1,29 +1,29 @@
+-.TH MAKE 1 "28 February 2016" "GNU" "User Commands"
++.TH GMAKE 1 "28 February 2016" "GNU" "User Commands"
+ .SH NAME
+-make \- GNU make utility to maintain groups of programs
++gmake \- GNU make utility to maintain groups of programs
+ .SH SYNOPSIS
+-.B make
++.B gmake
+ [\fIOPTION\fR]... [\fITARGET\fR]...
+ .SH DESCRIPTION
+ .LP
+ The
+-.I make
++.I gmake
+ utility will determine automatically which pieces of a large program need to
+ be recompiled, and issue the commands to recompile them. The manual describes
+ the GNU implementation of
+-.BR make ,
++.BR gmake ,
+ which was written by Richard Stallman and Roland McGrath, and is currently
+ maintained by Paul Smith. Our examples show C programs, since they are very
+ common, but you can use
+-.B make
++.B gmake
+ with any programming language whose compiler can be run with a shell command.
+ In fact,
+-.B make
++.B gmake
+ is not limited to programs. You can use it to describe any task where some
+ files must be updated automatically from others whenever the others change.
+ .LP
+ To prepare to use
+-.BR make ,
++.BR gmake ,
+ you must write a file called the
+ .I makefile
+ that describes the relationships among files in your program, and the states
[NEW] math/h5py
h5py is a thin, pythonic wrapper around the HDF5 library. Tests on amd64: 526 passed, 20 skipped, 3 xfailed, 2 warnings Further tests, for example on sparc64 welcome (recent experience shows hdf5-related ports are always problematic on non base-clang archs)! -m h5py.tgz Description: application/tar-gz
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2020/01/20 06:32:26 Modified files: databases/ports-readmes-dancer: Makefile distinfo Log message: fix two bugs in search, as reported by solene@, thanks
Re: [update] geo/traccar -> 4.7
On 1/20/20 12:41 PM, Stuart Henderson wrote:
Will look soon (this evening or tomorrow probably). Could you please add
a README section showing users how to set login.conf for more FDs please,
with several hundred already taken by the listen ports it gets tight fairly
quickly :-)
OK, that one is with an append to the README file
Index: Makefile
===
RCS file: /cvs/ports/geo/traccar/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile 6 Jan 2020 20:57:31 - 1.8
+++ Makefile 20 Jan 2020 12:29:42 -
@@ -1,8 +1,7 @@
# $OpenBSD: Makefile,v 1.8 2020/01/06 20:57:31 sthen Exp $
COMMENT = modern GPS tracking platform
-V = 4.5
-REVISION = 1
+V = 4.7
PKGNAME = traccar-${V}
DISTNAME = traccar-other-${V}
EXTRACT_SUFX = .zip
Index: distinfo
===
RCS file: /cvs/ports/geo/traccar/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo 22 May 2019 09:44:48 - 1.3
+++ distinfo 20 Jan 2020 12:29:42 -
@@ -1,2 +1,2 @@
-SHA256 (traccar-other-4.5.zip) = ZE2swcDdeHzn6dXFCt+Xxh/fOSIcfK66IB+Gc6P1GYk=
-SIZE (traccar-other-4.5.zip) = 53640425
+SHA256 (traccar-other-4.7.zip) = yjZ1P5ppdhPT47pVVfyWXcXryQn//PcIwD2G0grSJVE=
+SIZE (traccar-other-4.7.zip) = 56124485
Index: pkg/PLIST
===
RCS file: /cvs/ports/geo/traccar/pkg/PLIST,v
retrieving revision 1.5
diff -u -p -r1.5 PLIST
--- pkg/PLIST 6 Jan 2020 20:57:31 - 1.5
+++ pkg/PLIST 20 Jan 2020 12:29:42 -
@@ -26,26 +26,26 @@ share/traccar/conf/traccar.xml
@owner
@group
share/traccar/lib/
-share/traccar/lib/HikariCP-3.3.1.jar
+share/traccar/lib/HikariCP-3.4.2.jar
share/traccar/lib/activation-1.1.1.jar
share/traccar/lib/animal-sniffer-annotations-1.14.jar
share/traccar/lib/antlr-2.7.2.jar
share/traccar/lib/aopalliance-1.0.jar
-share/traccar/lib/aopalliance-repackaged-2.5.0.jar
-share/traccar/lib/asm-5.0.3.jar
-share/traccar/lib/asm-analysis-5.0.3.jar
-share/traccar/lib/asm-commons-5.0.3.jar
-share/traccar/lib/asm-tree-5.0.3.jar
-share/traccar/lib/asm-util-5.0.3.jar
+share/traccar/lib/aopalliance-repackaged-2.6.1.jar
+share/traccar/lib/asm-7.1.jar
+share/traccar/lib/asm-analysis-7.1.jar
+share/traccar/lib/asm-commons-7.1.jar
+share/traccar/lib/asm-tree-7.1.jar
+share/traccar/lib/asm-util-7.1.jar
share/traccar/lib/ch-commons-charset-3.0.2.jar
share/traccar/lib/ch-commons-util-6.0.2.jar
share/traccar/lib/ch-smpp-6.0.0-netty4-beta-3.jar
share/traccar/lib/checker-compat-qual-2.0.0.jar
share/traccar/lib/commons-beanutils-1.9.2.jar
share/traccar/lib/commons-chain-1.1.jar
-share/traccar/lib/commons-codec-1.12.jar
+share/traccar/lib/commons-codec-1.13.jar
share/traccar/lib/commons-collections-3.2.1.jar
-share/traccar/lib/commons-collections4-4.2.jar
+share/traccar/lib/commons-collections4-4.4.jar
share/traccar/lib/commons-compress-1.18.jar
share/traccar/lib/commons-digester-1.8.jar
share/traccar/lib/commons-jexl-2.1.1.jar
@@ -60,23 +60,24 @@ share/traccar/lib/error_prone_annotation
share/traccar/lib/guava-25.1-android.jar
share/traccar/lib/guice-4.2.2.jar
share/traccar/lib/guice-assistedinject-4.2.2.jar
-share/traccar/lib/h2-1.4.199.jar
-share/traccar/lib/hk2-api-2.5.0.jar
-share/traccar/lib/hk2-locator-2.5.0.jar
-share/traccar/lib/hk2-utils-2.5.0.jar
+share/traccar/lib/h2-1.4.200.jar
+share/traccar/lib/hk2-api-2.6.1.jar
+share/traccar/lib/hk2-locator-2.6.1.jar
+share/traccar/lib/hk2-utils-2.6.1.jar
share/traccar/lib/ical4j-2.0.5.jar
share/traccar/lib/j2objc-annotations-1.1.jar
-share/traccar/lib/jackson-annotations-2.9.8.jar
-share/traccar/lib/jackson-core-2.9.8.jar
-share/traccar/lib/jackson-databind-2.9.8.jar
-share/traccar/lib/jackson-datatype-jsr353-2.9.8.jar
-share/traccar/lib/jackson-jaxrs-base-2.9.8.jar
-share/traccar/lib/jackson-jaxrs-json-provider-2.9.8.jar
-share/traccar/lib/jackson-module-jaxb-annotations-2.9.8.jar
-share/traccar/lib/jakarta.annotation-api-1.3.4.jar
-share/traccar/lib/jakarta.inject-2.5.0.jar
-share/traccar/lib/jakarta.ws.rs-api-2.1.5.jar
-share/traccar/lib/javassist-3.22.0-CR2.jar
+share/traccar/lib/jackson-annotations-2.9.9.jar
+share/traccar/lib/jackson-core-2.9.9.jar
+share/traccar/lib/jackson-databind-2.9.9.jar
+share/traccar/lib/jackson-datatype-jsr353-2.9.9.jar
+share/traccar/lib/jackson-jaxrs-base-2.9.9.jar
+share/traccar/lib/jackson-jaxrs-json-provider-2.9.9.jar
+share/traccar/lib/jackson-module-jaxb-annotations-2.9.9.jar
+share/traccar/lib/jakarta.annotation-api-1.3.5.jar
+share/traccar/lib/jakarta.inject-2.6.1.jar
+share/traccar/lib/jakarta.validation-api-2.0.2.jar
+share/traccar/lib/jakarta.ws.rs-api-2.1.6.jar
+share/traccar/lib/javassist-3.25.0-GA.jar
share/traccar/lib/javax.activation-api-1.2.0.jar
share/traccar/lib/javax.inject-1.jar
share/traccar/lib/javax.json-1.1.4.jar
@@ -87,67 +88,65 @@ share/traccar/lib/jaxb-api-2.3.1.jar
share/traccar/lib/jaxb-core-2.3.0.1.jar
Re: should we port ssh-copy-id ?
On 2020/01/20 10:59, Landry Breuil wrote: > On Mon, Jan 20, 2020 at 08:50:05PM +1100, Antoine Jacoutot wrote: > > Same for regular users from skel > > Ah, wasnt sure about it since i didnt find the corresponding commit, but > thanks for confirming :) > > > All that to say that 'ensuring that ~/.ssh and authorized_keys are > created with correct permissions' shouldnt be the reason for porting > ssh-copy-id - but only to actually copy the key.. :) > > > > On 20 Jan 2020, at 19:29, Landry Breuil wrote: > > > > > > On Tue, Jan 14, 2020 at 09:47:11AM +0100, Jan-Piet Mens wrote: > > >> ssh-copy-id [1] is a script to copy one's SSH keys to remote hosts, > > >> ensuring > > >> that ~/.ssh and authorized_keys are created with correct permissions. The > > >> script uses ssh(1) to log into a remote machine (using a login password). > > > > > > Fwiw, on OpenBSD ~/.ssh and authorized_keys are created with correct > > > permissions by default, at least for user root... > > > > > > https://marc.info/?l=openbsd-cvs=148688978308030=2 > > > > > > ssh-copy-id is for copying keys onto any random OS.
Re: [update] geo/traccar -> 4.7
Will look soon (this evening or tomorrow probably). Could you please add
a README section showing users how to set login.conf for more FDs please,
with several hundred already taken by the listen ports it gets tight fairly
quickly :-)
On 2020/01/20 07:18, Renaud Allard wrote:
> Hello,
>
> Here is a patch to update traccar to v4.7. There have been lots of new
> protocols added.
>
> Race Dynamics - GPS protocol from a company from Bangalore
> RST - MultiPortal (company from Brazil)
> PT215 - ThinkRace communication protocol
> PacificTrack - telematics protocol from a California company
> Topin - ZhongXun Topin (similar to GT06 protocol)
> OutSafe - GPS protocol from a Mexican company called Sigaba
> Solar Powered - protocol from a Shenzhen hardware company
> Motor - another Chinese GPS protocol
> Omnicomm - fuel monitoring solutions
> S168 - solar powered GPS ear tags for livestock
> VNETGPS - protocol from VNET (Viet Nam Electronics)
> Blue - communication protocol from ExtremTrac
> PST - PST Eletronica open protocol from Brazil
>
> Please note that if you installed version 4.0 or newer without upgrading
> from any earlier version. The index on device and time columns was
> missing, which was causing very slow reports. The issue is fixed now,
> but note that it might take a while to create an index, so be patient
> when you start server first time after upgrade.
>
> Regards
> Index: Makefile
> ===
> RCS file: /cvs/ports/geo/traccar/Makefile,v
> retrieving revision 1.8
> diff -u -p -r1.8 Makefile
> --- Makefile 6 Jan 2020 20:57:31 - 1.8
> +++ Makefile 20 Jan 2020 06:16:03 -
> @@ -1,8 +1,7 @@
> # $OpenBSD: Makefile,v 1.8 2020/01/06 20:57:31 sthen Exp $
>
> COMMENT =modern GPS tracking platform
> -V = 4.5
> -REVISION = 1
> +V = 4.7
> PKGNAME =traccar-${V}
> DISTNAME = traccar-other-${V}
> EXTRACT_SUFX = .zip
> Index: distinfo
> ===
> RCS file: /cvs/ports/geo/traccar/distinfo,v
> retrieving revision 1.3
> diff -u -p -r1.3 distinfo
> --- distinfo 22 May 2019 09:44:48 - 1.3
> +++ distinfo 20 Jan 2020 06:16:03 -
> @@ -1,2 +1,2 @@
> -SHA256 (traccar-other-4.5.zip) = ZE2swcDdeHzn6dXFCt+Xxh/fOSIcfK66IB+Gc6P1GYk=
> -SIZE (traccar-other-4.5.zip) = 53640425
> +SHA256 (traccar-other-4.7.zip) = yjZ1P5ppdhPT47pVVfyWXcXryQn//PcIwD2G0grSJVE=
> +SIZE (traccar-other-4.7.zip) = 56124485
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/geo/traccar/pkg/PLIST,v
> retrieving revision 1.5
> diff -u -p -r1.5 PLIST
> --- pkg/PLIST 6 Jan 2020 20:57:31 - 1.5
> +++ pkg/PLIST 20 Jan 2020 06:16:03 -
> @@ -26,26 +26,26 @@ share/traccar/conf/traccar.xml
> @owner
> @group
> share/traccar/lib/
> -share/traccar/lib/HikariCP-3.3.1.jar
> +share/traccar/lib/HikariCP-3.4.2.jar
> share/traccar/lib/activation-1.1.1.jar
> share/traccar/lib/animal-sniffer-annotations-1.14.jar
> share/traccar/lib/antlr-2.7.2.jar
> share/traccar/lib/aopalliance-1.0.jar
> -share/traccar/lib/aopalliance-repackaged-2.5.0.jar
> -share/traccar/lib/asm-5.0.3.jar
> -share/traccar/lib/asm-analysis-5.0.3.jar
> -share/traccar/lib/asm-commons-5.0.3.jar
> -share/traccar/lib/asm-tree-5.0.3.jar
> -share/traccar/lib/asm-util-5.0.3.jar
> +share/traccar/lib/aopalliance-repackaged-2.6.1.jar
> +share/traccar/lib/asm-7.1.jar
> +share/traccar/lib/asm-analysis-7.1.jar
> +share/traccar/lib/asm-commons-7.1.jar
> +share/traccar/lib/asm-tree-7.1.jar
> +share/traccar/lib/asm-util-7.1.jar
> share/traccar/lib/ch-commons-charset-3.0.2.jar
> share/traccar/lib/ch-commons-util-6.0.2.jar
> share/traccar/lib/ch-smpp-6.0.0-netty4-beta-3.jar
> share/traccar/lib/checker-compat-qual-2.0.0.jar
> share/traccar/lib/commons-beanutils-1.9.2.jar
> share/traccar/lib/commons-chain-1.1.jar
> -share/traccar/lib/commons-codec-1.12.jar
> +share/traccar/lib/commons-codec-1.13.jar
> share/traccar/lib/commons-collections-3.2.1.jar
> -share/traccar/lib/commons-collections4-4.2.jar
> +share/traccar/lib/commons-collections4-4.4.jar
> share/traccar/lib/commons-compress-1.18.jar
> share/traccar/lib/commons-digester-1.8.jar
> share/traccar/lib/commons-jexl-2.1.1.jar
> @@ -60,23 +60,24 @@ share/traccar/lib/error_prone_annotation
> share/traccar/lib/guava-25.1-android.jar
> share/traccar/lib/guice-4.2.2.jar
> share/traccar/lib/guice-assistedinject-4.2.2.jar
> -share/traccar/lib/h2-1.4.199.jar
> -share/traccar/lib/hk2-api-2.5.0.jar
> -share/traccar/lib/hk2-locator-2.5.0.jar
> -share/traccar/lib/hk2-utils-2.5.0.jar
> +share/traccar/lib/h2-1.4.200.jar
> +share/traccar/lib/hk2-api-2.6.1.jar
> +share/traccar/lib/hk2-locator-2.6.1.jar
> +share/traccar/lib/hk2-utils-2.6.1.jar
> share/traccar/lib/ical4j-2.0.5.jar
> share/traccar/lib/j2objc-annotations-1.1.jar
>
Re: [PATCH] Update inputmethods/anthy from 9100 to 0.4
On 2020-01-19 14:16:34, Stuart Henderson wrote:
> On 2020/01/09 23:34, Bryan Linton wrote:
> > Hello ports@
> >
> > I was attempting to make some changes to inputmethods/anthy for
> > another purpose when I noticed it was woefully out of date.
> >
> > [...]
> >
> > Questions:
>
> I've not otherwise looked at it, but answering questions:
>
> > * Is setting "DISTFILES = anthy_$V.orig.tar.gz" the best way to cope
> > with the naming of the tarball?
>
> This is better:
>
> V = 0.4
> DISTNAME = anthy_$V.orig
> WRKDIST = ${WRKDIR}/anthy-$V
>
> > * Does the version changing from 9100h to 0.4 require setting EPOCH?
> > It seems to have updated fine on my system, but I don't know the
> > details of when EPOCH is needed.
>
> Yes. EPOCH is needed whenever the version number goes "backwards"
> according to packages-specs(7) format.
>
Thanks for the tips. Updated patch attached.
Changes from previous patch
===
* Add EPOCH to cope with version change (9100h -> 0.4)
* Use DISTNAME and WRKDIST instead of DISTFILES.
--
Bryan
Index: Makefile
===
RCS file: /cvs/ports/inputmethods/anthy/Makefile,v
retrieving revision 1.25
diff -u -r1.25 Makefile
--- Makefile12 Jul 2019 20:47:12 - 1.25
+++ Makefile20 Jan 2020 10:24:51 -
@@ -3,12 +3,14 @@
COMMENT-main = japanese input method
COMMENT-emacs =emacs files for anthy
-V =9100h
-DISTNAME = anthy-$V
+V =0.4
+DISTNAME = anthy_$V.orig
+WRKDIST = ${WRKDIR}/anthy-$V
PKGNAME-main = anthy-$V
PKGNAME-emacs =emacs-anthy-$V
-REVISION-main = 2
-REVISION-emacs = 4
+REVISION-main = 0
+REVISION-emacs = 0
+EPOCH =0
SHARED_LIBS += anthydic 1.0 # .1.0
SHARED_LIBS += anthy1.0 # .1.0
@@ -16,14 +18,14 @@
CATEGORIES = inputmethods japanese
-HOMEPAGE = https://anthy.osdn.jp/
+HOMEPAGE = https://wiki.debian.org/Teams/DebianAnthy
-# GPL, part LGPL
+# GPLv3, parts are LGPLv3 and/or LGPLv2+
PERMIT_PACKAGE = Yes
WANTLIB-main = c m
-MASTER_SITES = ${MASTER_SITE_OSDN_JP:=anthy/37536/}
+MASTER_SITES = http://deb.debian.org/debian/pool/main/a/anthy/
FAKE_FLAGS = sysconfdir=$(PREFIX)/share/examples/anthy
Index: distinfo
===
RCS file: /cvs/ports/inputmethods/anthy/distinfo,v
retrieving revision 1.5
diff -u -r1.5 distinfo
--- distinfo18 Jan 2015 03:14:16 - 1.5
+++ distinfo20 Jan 2020 10:24:51 -
@@ -1,2 +1,2 @@
-SHA256 (anthy-9100h.tar.gz) = 0lbwdfAYtKPLDRZe1hUf2kun2xYhcn4OtUVptuInVUc=
-SIZE (anthy-9100h.tar.gz) = 4446148
+SHA256 (anthy_0.4.orig.tar.gz) = /fWQvupwk/Myex7udgE+STbkxmWefMAd0f3W5vLpyfc=
+SIZE (anthy_0.4.orig.tar.gz) = 5619024
Index: patches/patch-src-util_anthy_el
===
RCS file: patches/patch-src-util_anthy_el
diff -N patches/patch-src-util_anthy_el
--- patches/patch-src-util_anthy_el 7 Dec 2013 23:42:04 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,12 +0,0 @@
-$OpenBSD: patch-src-util_anthy_el,v 1.1 2013/12/07 23:42:04 yasuoka Exp $
src-util/anthy.el.orig Sat Nov 30 10:40:43 2013
-+++ src-util/anthy.el Sat Nov 30 10:40:55 2013
-@@ -892,7 +892,7 @@
-((event-matches-key-specifier-p event 'backspace) 8)
-(t
- (char-to-int (event-to-character event)
--last-command-char))
-+last-command-event))
-
- ;;
- ;;
Index: pkg/PLIST-main
===
RCS file: /cvs/ports/inputmethods/anthy/pkg/PLIST-main,v
retrieving revision 1.5
diff -u -r1.5 PLIST-main
--- pkg/PLIST-main 22 May 2015 11:31:16 - 1.5
+++ pkg/PLIST-main 20 Jan 2020 10:24:51 -
@@ -2,18 +2,17 @@
@pkgpath inputmethods/anthy
@bin bin/anthy-agent
@bin bin/anthy-dic-tool
-@bin bin/anthy-morphological-analyzer
include/anthy/
include/anthy/anthy.h
include/anthy/dicutil.h
include/anthy/input.h
-lib/libanthy.a
+@static-lib lib/libanthy.a
lib/libanthy.la
@lib lib/libanthy.so.${LIBanthy_VERSION}
-lib/libanthydic.a
+@static-lib lib/libanthydic.a
lib/libanthydic.la
@lib lib/libanthydic.so.${LIBanthydic_VERSION}
-lib/libanthyinput.a
+@static-lib lib/libanthyinput.a
lib/libanthyinput.la
@lib lib/libanthyinput.so.${LIBanthyinput_VERSION}
lib/pkgconfig/anthy.pc
Re: should we port ssh-copy-id ?
Am 20.01.2020 10:59 schrieb Landry Breuil: On Mon, Jan 20, 2020 at 08:50:05PM +1100, Antoine Jacoutot wrote: Same for regular users from skel Ah, wasnt sure about it since i didnt find the corresponding commit, but thanks for confirming :) All that to say that 'ensuring that ~/.ssh and authorized_keys are created with correct permissions' shouldnt be the reason for porting ssh-copy-id - but only to actually copy the key.. :) Maybe the *target* of this ssh-copy-id is not an openbsd box - or not a "modern" one. AFAIR this .ssh/authorized_keys create+ensure modes was added last year (or 2018)? -- pb
Re: should we port ssh-copy-id ?
On Mon, Jan 20, 2020 at 08:50:05PM +1100, Antoine Jacoutot wrote: > Same for regular users from skel Ah, wasnt sure about it since i didnt find the corresponding commit, but thanks for confirming :) All that to say that 'ensuring that ~/.ssh and authorized_keys are created with correct permissions' shouldnt be the reason for porting ssh-copy-id - but only to actually copy the key.. :) > > On 20 Jan 2020, at 19:29, Landry Breuil wrote: > > > > On Tue, Jan 14, 2020 at 09:47:11AM +0100, Jan-Piet Mens wrote: > >> ssh-copy-id [1] is a script to copy one's SSH keys to remote hosts, > >> ensuring > >> that ~/.ssh and authorized_keys are created with correct permissions. The > >> script uses ssh(1) to log into a remote machine (using a login password). > > > > Fwiw, on OpenBSD ~/.ssh and authorized_keys are created with correct > > permissions by default, at least for user root... > > > > https://marc.info/?l=openbsd-cvs=148688978308030=2 > > >
Re: should we port ssh-copy-id ?
Same for regular users from skel — Antoine > On 20 Jan 2020, at 19:29, Landry Breuil wrote: > > On Tue, Jan 14, 2020 at 09:47:11AM +0100, Jan-Piet Mens wrote: >> ssh-copy-id [1] is a script to copy one's SSH keys to remote hosts, ensuring >> that ~/.ssh and authorized_keys are created with correct permissions. The >> script uses ssh(1) to log into a remote machine (using a login password). > > Fwiw, on OpenBSD ~/.ssh and authorized_keys are created with correct > permissions by default, at least for user root... > > https://marc.info/?l=openbsd-cvs=148688978308030=2 >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/01/20 02:42:38 Modified files: geo/pygeoapi : Makefile Log message: Use a more 'standard' PKGNAME: py3-pygeoapi-0.6.0 - req'd by sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/01/20 02:09:06 Modified files: geo/mdal : Makefile distinfo Log message: Update to mdal 0.4.1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/01/20 02:05:41 Modified files: x11/xfce4/xfce4-whiskermenu: Makefile distinfo x11/xfce4/xfce4-whiskermenu/pkg: PLIST Log message: Update to xfce4-whiskermenu 2.3.5
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/01/20 02:03:52 Modified files: textproc/zathura/plugins: Makefile.inc textproc/zathura/plugins/cb: Makefile textproc/zathura/plugins/cb/pkg: PLIST textproc/zathura/plugins/djvu: Makefile distinfo textproc/zathura/plugins/djvu/pkg: PLIST textproc/zathura/plugins/mupdf: Makefile distinfo textproc/zathura/plugins/mupdf/pkg: PLIST textproc/zathura/plugins/poppler: Makefile distinfo textproc/zathura/plugins/poppler/pkg: PLIST textproc/zathura/plugins/ps: Makefile textproc/zathura/plugins/ps/pkg: PLIST Removed files: textproc/zathura/plugins/mupdf/patches: patch-zathura-pdf-mupdf_search_c Log message: Update to zathura plugins: djvu 0.2.9 pdf-mupdf 0.3.5 (remove mupdf 1.16 compat patch from upstream) pdf-poppler 0.3.0 fix WANTLIB all around, use @so markers in PLISTs, factorize DISTNAME, MASTER_SITES & HOMEPAGE. ok sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/01/20 02:01:51 Modified files: textproc/zathura/core: Makefile distinfo textproc/zathura/core/pkg: PLIST Log message: Update to zathura 0.4.5. Diff from Matthew Martin with WANTLIB fixes on top, ok sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/01/20 02:00:32 Modified files: x11/girara : Makefile distinfo x11/girara/pkg : PLIST Log message: Update to girara 0.3.4. Diff from Matthew Martin, with WANTLIB fixes on top.
[update] net/dnscontrol -> 2.10.0
Hello, Please find attached patch to update DNSControl to latest stable (2.10.0) version. Major Changes: New Provider: Azure DNS (#547) Switched from govendor to go modules for dependencies (#587) Upgraded to Go 1.13 (#550) Provider-specific changes: Ghandi: Support for multi-TXT records (#545) Ghandi: Print actual changes to be pushed (#546) Vultr: Added support for SSHFP records (#531) CloudFlare: Add ability to manage UniversalSSL (#496) CloudFlare: Support API tokens (#555) Route 53: Add AWS_PROFILE functionality (#567) Minor cleanups: Documentation and typo cleanup (#586, #582, #571, #565, #560, #556, #507) Kind regards, KarlisCommon subdirectories: net/dnscontrol.orig/CVS and net/dnscontrol/CVS diff -u net/dnscontrol.orig/Makefile net/dnscontrol/Makefile --- net/dnscontrol.orig/Makefile Mon Jan 20 09:07:53 2020 +++ net/dnscontrol/Makefile Mon Jan 20 09:08:50 2020 @@ -8,7 +8,7 @@ GH_ACCOUNT = StackExchange GH_PROJECT = dnscontrol -GH_TAGNAME = v2.9 +GH_TAGNAME = v2.10.0 CATEGORIES = net diff -u net/dnscontrol.orig/distinfo net/dnscontrol/distinfo --- net/dnscontrol.orig/distinfo Mon Jan 20 09:07:53 2020 +++ net/dnscontrol/distinfo Mon Jan 20 09:09:47 2020 @@ -1,2 +1,2 @@ -SHA256 (dnscontrol-2.9.tar.gz) = bD5zm1bGTi5BoMsj9N68PbaImsoKeAFscw740eQnCeg= -SIZE (dnscontrol-2.9.tar.gz) = 4362882 +SHA256 (dnscontrol-2.10.0.tar.gz) = CdcWNBcvSYxdK3PW9scUOfTYiodM+zrcTLvrgd3vcKY= +SIZE (dnscontrol-2.10.0.tar.gz) = 6700485 Common subdirectories: net/dnscontrol.orig/pkg and net/dnscontrol/pkg
Re: should we port ssh-copy-id ?
On Tue, Jan 14, 2020 at 09:47:11AM +0100, Jan-Piet Mens wrote: > ssh-copy-id [1] is a script to copy one's SSH keys to remote hosts, ensuring > that ~/.ssh and authorized_keys are created with correct permissions. The > script uses ssh(1) to log into a remote machine (using a login password). Fwiw, on OpenBSD ~/.ssh and authorized_keys are created with correct permissions by default, at least for user root... https://marc.info/?l=openbsd-cvs=148688978308030=2
Re: update to libvips 8.9.0
On Sun, Jan 19, 2020 at 11:00:03PM +0100, Stephane Guedon wrote: > > It seem you haven't updated the latest Makefile. > > Yes I did : newest version number, checked with it. > > All I see to miss is maybe my name as maintainer. > Do I miss more ? > In Makefile : - SHARED_LIBS should start at 0.0 - LIB_DEPENDS should be one dep per line Also pkg/DESCR is shorter, any reason why ?
