Re: UPDATE devel/git-lfs
On Wed 06/06/2018 20:18, Björn Ketelaars wrote: > Enclosed a diff for bringing git-lfs to 2.4.2, which fixes some bugs. > Changelog can be found at > https://github.com/git-lfs/git-lfs/blob/release-2.4/CHANGELOG.md > > Build, and tested OK on amd64. > > OK? Ping!
NEW: sysutils/realpath
Hi ports -- Attached is a new port, sysutils/realpath. realpath is a utility to return resolved physical paths. --- pkg/DESCR: The realpath utility resolves all symbolic links, extra `/' characters and references to /./ and /../ in the path. If path is absent, the current working directory (`.') is assumed. It is a port of the realpath utility from DragonFly BSD. --- I occasionally run into shell scripts that expect the utility. Works fine on amd64 and armv7. OK? ~Brian realpath.tgz Description: Binary data
Re: what to set for PERMIT_PACKAGE in port
Thanks for the help guys! I think I got it now Mitch On Tue, Jun 12, 2018 at 6:17 PM, Stuart Henderson wrote: > On 2018/06/12 23:10, mitchell wodach wrote: >> On 6/12/18, Stuart Henderson wrote: >> > On 2018/06/12 21:26, mitchell wodach wrote: >> >> On 6/9/18, Marc Espie wrote: >> >> > On Fri, Jun 08, 2018 at 06:15:01PM -0500, mitchell wodach wrote: >> >> >> Hi >> >> >> >> >> >> I'm working on porting Freedink. I have the data separate form the >> >> >> game >> >> >> code. >> >> >> The data has multiple licenses. so for PERMIT_PACKAGE in Makefile I >> >> >> should >> >> >> pick the most restrictive license? >> >> > >> >> > What you're saying is highly ambiguous: do the individual data files >> >> > have >> >> > separate licences ? In that case, the most restrictive is appropriate. >> >> > >> >> > Or do you see several licences that apply to all files ? In that case, >> >> > this means the data can be redistributed under any of the licences. In >> >> > that >> >> > case, the least restrictive is appropriate. >> >> > >> >> >> >> I do apologize for the ambiguity of my question. not the greatest >> >> question asker. >> >> I took a look in the upstream source tarball for the data. the files >> >> do have their own separate licences. most of the data is licensed >> >> under zlib. The files that are not under the zlib license are >> >> specified in a separate readme file and have a folder with all the >> >> license texts. so the first case is the one I need to pick. I guess I >> >> have some reading todo lol! >> >> >> >> Thanks, >> >> Mitch >> >> >> > >> > Got a link to the actual distfiles you're looking at? >> > >> > >> yes I do have a link >> >> https://ftp.gnu.org/gnu/freedink/freedink-data-1.08.20170409.tar.gz >> >> The files I looked at are README.txt and README-REPLACEMENTS.txt and >> the directory with license texts in it is called licenses/ > > I would write "various free-distribution licenses; see README.txt and > README-REPLACEMENTS.txt in the distribution". > > (and the main game code is "GPLv3 or newer" so write that as "GPLv3+"). >
Re: NEW: www/mkdocs (with dep of www/py-livereload)
Title of this post updated to reflect the category and both ports included.
Below are the diffs for the two files noted. The PLIST diff is kind of
lengthy.
Not sure what set it to 600 but will look into it for future ports.
--- www/mkdocs/Makefile.origTue Jun 12 18:34:41 2018
+++ www/mkdocs/Makefile Tue Jun 12 18:35:27 2018
@@ -3,7 +3,6 @@
COMMENT = project documentation with Markdown
MODPY_EGG_VERSION =${GH_TAGNAME}
-DISTNAME = mkdocs-${MODPY_EGG_VERSION}
GH_ACCOUNT = mkdocs
GH_PROJECT = mkdocs
--- www/mkdocs/pkg/PLIST.orig Tue Jun 12 18:35:38 2018
+++ www/mkdocs/pkg/PLISTTue Jun 12 18:56:18 2018
@@ -1,6 +1,6 @@
@comment $OpenBSD: PLIST,v$
bin/mkdocs
-${MODPY_COMMNENT}lib/python${MODPY_VERSION}/site-packages/mkdocs/
+lib/python${MODPY_VERSION}/site-packages/mkdocs/
lib/python${MODPY_VERSION}/site-packages/mkdocs-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
lib/python${MODPY_VERSION}/site-packages/mkdocs-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
lib/python${MODPY_VERSION}/site-packages/mkdocs-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/SOURCES.txt
@@ -11,46 +11,46 @@ lib/python${MODPY_VERSION}/site-packages/mkdocs-${MODP
lib/python${MODPY_VERSION}/site-packages/mkdocs-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
lib/python${MODPY_VERSION}/site-packages/mkdocs/__init__.py
lib/python${MODPY_VERSION}/site-packages/mkdocs/__main__.py
-lib/python${MODPY_VERSION}/site-packages/mkdocs/${MODPY_PYCACHE}
-lib/python${MODPY_VERSION}/site-packages/mkdocs/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/mkdocs/${MODPY_PYCACHE}__main__.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/mkdocs/${MODPY_PYCACHE}exceptions.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/mkdocs/${MODPY_PYCACHE}nav.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/mkdocs/${MODPY_PYCACHE}plugins.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/mkdocs/${MODPY_PYCACHE}relative_path_ext.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/mkdocs/${MODPY_PYCACHE}theme.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/mkdocs/${MODPY_PYCACHE}toc.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/mkdocs/${MODPY_PYCACHE}/
+lib/python${MODPY_VERSION}/site-packages/mkdocs/${MODPY_PYCACHE}/__init__.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/mkdocs/${MODPY_PYCACHE}/__main__.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/mkdocs/${MODPY_PYCACHE}/exceptions.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/mkdocs/${MODPY_PYCACHE}/nav.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/mkdocs/${MODPY_PYCACHE}/plugins.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/mkdocs/${MODPY_PYCACHE}/relative_path_ext.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/mkdocs/${MODPY_PYCACHE}/theme.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/mkdocs/${MODPY_PYCACHE}/toc.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/mkdocs/commands/
lib/python${MODPY_VERSION}/site-packages/mkdocs/commands/__init__.py
-lib/python${MODPY_VERSION}/site-packages/mkdocs/commands/${MODPY_PYCACHE}
-lib/python${MODPY_VERSION}/site-packages/mkdocs/commands/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/mkdocs/commands/${MODPY_PYCACHE}build.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/mkdocs/commands/${MODPY_PYCACHE}gh_deploy.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/mkdocs/commands/${MODPY_PYCACHE}new.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/mkdocs/commands/${MODPY_PYCACHE}serve.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/mkdocs/commands/${MODPY_PYCACHE}/
+lib/python${MODPY_VERSION}/site-packages/mkdocs/commands/${MODPY_PYCACHE}/__init__.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/mkdocs/commands/${MODPY_PYCACHE}/build.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/mkdocs/commands/${MODPY_PYCACHE}/gh_deploy.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/mkdocs/commands/${MODPY_PYCACHE}/new.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/mkdocs/commands/${MODPY_PYCACHE}/serve.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/mkdocs/commands/build.py
lib/python${MODPY_VERSION}/site-packages/mkdocs/commands/gh_deploy.py
lib/python${MODPY_VERSION}/site-packages/mkdocs/commands/new.py
lib/python${MODPY_VERSION}/site-packages/mkdocs/commands/serve.py
lib/python${MODPY_VERSION}/site-packages/mkdocs/config/
lib/python${MODPY_VERSION}/site-packages/mkdocs/config/__init__.py
-lib/python${MODPY_VERSION}/site-
Re: what to set for PERMIT_PACKAGE in port
On 2018/06/12 23:10, mitchell wodach wrote: > On 6/12/18, Stuart Henderson wrote: > > On 2018/06/12 21:26, mitchell wodach wrote: > >> On 6/9/18, Marc Espie wrote: > >> > On Fri, Jun 08, 2018 at 06:15:01PM -0500, mitchell wodach wrote: > >> >> Hi > >> >> > >> >> I'm working on porting Freedink. I have the data separate form the > >> >> game > >> >> code. > >> >> The data has multiple licenses. so for PERMIT_PACKAGE in Makefile I > >> >> should > >> >> pick the most restrictive license? > >> > > >> > What you're saying is highly ambiguous: do the individual data files > >> > have > >> > separate licences ? In that case, the most restrictive is appropriate. > >> > > >> > Or do you see several licences that apply to all files ? In that case, > >> > this means the data can be redistributed under any of the licences. In > >> > that > >> > case, the least restrictive is appropriate. > >> > > >> > >> I do apologize for the ambiguity of my question. not the greatest > >> question asker. > >> I took a look in the upstream source tarball for the data. the files > >> do have their own separate licences. most of the data is licensed > >> under zlib. The files that are not under the zlib license are > >> specified in a separate readme file and have a folder with all the > >> license texts. so the first case is the one I need to pick. I guess I > >> have some reading todo lol! > >> > >> Thanks, > >> Mitch > >> > > > > Got a link to the actual distfiles you're looking at? > > > > > yes I do have a link > > https://ftp.gnu.org/gnu/freedink/freedink-data-1.08.20170409.tar.gz > > The files I looked at are README.txt and README-REPLACEMENTS.txt and > the directory with license texts in it is called licenses/ I would write "various free-distribution licenses; see README.txt and README-REPLACEMENTS.txt in the distribution". (and the main game code is "GPLv3 or newer" so write that as "GPLv3+").
Re: what to set for PERMIT_PACKAGE in port
On 6/12/18, mitchell wodach wrote: > On 6/12/18, Stuart Henderson wrote: >> On 2018/06/12 21:26, mitchell wodach wrote: >>> On 6/9/18, Marc Espie wrote: >>> > On Fri, Jun 08, 2018 at 06:15:01PM -0500, mitchell wodach wrote: >>> >> Hi >>> >> >>> >> I'm working on porting Freedink. I have the data separate form the >>> >> game >>> >> code. >>> >> The data has multiple licenses. so for PERMIT_PACKAGE in Makefile I >>> >> should >>> >> pick the most restrictive license? >>> > >>> > What you're saying is highly ambiguous: do the individual data files >>> > have >>> > separate licences ? In that case, the most restrictive is appropriate. >>> > >>> > Or do you see several licences that apply to all files ? In that case, >>> > this means the data can be redistributed under any of the licences. In >>> > that >>> > case, the least restrictive is appropriate. >>> > >>> >>> I do apologize for the ambiguity of my question. not the greatest >>> question asker. >>> I took a look in the upstream source tarball for the data. the files >>> do have their own separate licences. most of the data is licensed >>> under zlib. The files that are not under the zlib license are >>> specified in a separate readme file and have a folder with all the >>> license texts. so the first case is the one I need to pick. I guess I >>> have some reading todo lol! >>> >>> Thanks, >>> Mitch >>> >> >> Got a link to the actual distfiles you're looking at? >> >> > yes I do have a link > > https://ftp.gnu.org/gnu/freedink/freedink-data-1.08.20170409.tar.gz > > The files I looked at are README.txt and README-REPLACEMENTS.txt and > the directory with license texts in it is called licenses/ >
Re: what to set for PERMIT_PACKAGE in port
On 6/12/18, Stuart Henderson wrote: > On 2018/06/12 21:26, mitchell wodach wrote: >> On 6/9/18, Marc Espie wrote: >> > On Fri, Jun 08, 2018 at 06:15:01PM -0500, mitchell wodach wrote: >> >> Hi >> >> >> >> I'm working on porting Freedink. I have the data separate form the >> >> game >> >> code. >> >> The data has multiple licenses. so for PERMIT_PACKAGE in Makefile I >> >> should >> >> pick the most restrictive license? >> > >> > What you're saying is highly ambiguous: do the individual data files >> > have >> > separate licences ? In that case, the most restrictive is appropriate. >> > >> > Or do you see several licences that apply to all files ? In that case, >> > this means the data can be redistributed under any of the licences. In >> > that >> > case, the least restrictive is appropriate. >> > >> >> I do apologize for the ambiguity of my question. not the greatest >> question asker. >> I took a look in the upstream source tarball for the data. the files >> do have their own separate licences. most of the data is licensed >> under zlib. The files that are not under the zlib license are >> specified in a separate readme file and have a folder with all the >> license texts. so the first case is the one I need to pick. I guess I >> have some reading todo lol! >> >> Thanks, >> Mitch >> > > Got a link to the actual distfiles you're looking at? > > yes I do have a link https://ftp.gnu.org/gnu/freedink/freedink-data-1.08.20170409.tar.gz The files I looked at are README.txt and README-REPLACEMENTS.txt and the directory with license texts in it is called licenses/
Re: what to set for PERMIT_PACKAGE in port
On 2018/06/12 21:26, mitchell wodach wrote: > On 6/9/18, Marc Espie wrote: > > On Fri, Jun 08, 2018 at 06:15:01PM -0500, mitchell wodach wrote: > >> Hi > >> > >> I'm working on porting Freedink. I have the data separate form the game > >> code. > >> The data has multiple licenses. so for PERMIT_PACKAGE in Makefile I > >> should > >> pick the most restrictive license? > > > > What you're saying is highly ambiguous: do the individual data files have > > separate licences ? In that case, the most restrictive is appropriate. > > > > Or do you see several licences that apply to all files ? In that case, > > this means the data can be redistributed under any of the licences. In that > > case, the least restrictive is appropriate. > > > > I do apologize for the ambiguity of my question. not the greatest > question asker. > I took a look in the upstream source tarball for the data. the files > do have their own separate licences. most of the data is licensed > under zlib. The files that are not under the zlib license are > specified in a separate readme file and have a folder with all the > license texts. so the first case is the one I need to pick. I guess I > have some reading todo lol! > > Thanks, > Mitch > Got a link to the actual distfiles you're looking at?
Re: what to set for PERMIT_PACKAGE in port
On 6/9/18, Marc Espie wrote: > On Fri, Jun 08, 2018 at 06:15:01PM -0500, mitchell wodach wrote: >> Hi >> >> I'm working on porting Freedink. I have the data separate form the game >> code. >> The data has multiple licenses. so for PERMIT_PACKAGE in Makefile I >> should >> pick the most restrictive license? > > What you're saying is highly ambiguous: do the individual data files have > separate licences ? In that case, the most restrictive is appropriate. > > Or do you see several licences that apply to all files ? In that case, > this means the data can be redistributed under any of the licences. In that > case, the least restrictive is appropriate. > I do apologize for the ambiguity of my question. not the greatest question asker. I took a look in the upstream source tarball for the data. the files do have their own separate licences. most of the data is licensed under zlib. The files that are not under the zlib license are specified in a separate readme file and have a folder with all the license texts. so the first case is the one I need to pick. I guess I have some reading todo lol! Thanks, Mitch
Re: REVISION: databases/py-sqlalchemy
On Tue, Jun 12, 2018 at 06:06:27PM -0300, Elias M. Mariani wrote:
> > Ah I'd forgotten about that, you're right, in which case please just
> > unconditionally set
> >
> > FULLPKGNAME-main = ${MODPY_PY_PREFIX}sqlalchemy-${MODPY_EGG_VERSION}
> >
> > rather than making it flavour-dependent.
>
> OK, yes, that is much nicer!
>
> the only thing that I'm struggling with is the @pkgpath:
> "@pkgpath tells pkg_add that it can be considered as a replacement for
> another pkgpath." - by Stuart Henderson
>
> So, in this case I want PLIST-main to be a replacement of
> databases/py-sqlalchemy and databases/py-sqlalchemy,-python3:
> @pkgpath databases/py-sqlalchemy
> @pkgpath databases/py-sqlalchemy,-python3
> But what about the conflicting files with docs and the current py-sqlalchemy ?
That's fairly trivial, doc should conflict with both *old* versions of
py-sqlalchemy, so that's just two
@conflict
lines in there.
Re: REVISION: databases/py-sqlalchemy
> Ah I'd forgotten about that, you're right, in which case please just
> unconditionally set
>
> FULLPKGNAME-main = ${MODPY_PY_PREFIX}sqlalchemy-${MODPY_EGG_VERSION}
>
> rather than making it flavour-dependent.
OK, yes, that is much nicer!
the only thing that I'm struggling with is the @pkgpath:
"@pkgpath tells pkg_add that it can be considered as a replacement for
another pkgpath." - by Stuart Henderson
So, in this case I want PLIST-main to be a replacement of
databases/py-sqlalchemy and databases/py-sqlalchemy,-python3:
@pkgpath databases/py-sqlalchemy
@pkgpath databases/py-sqlalchemy,-python3
But what about the conflicting files with docs and the current py-sqlalchemy ?
Cheers.
Elias.
Re: REVISION: databases/py-sqlalchemy
On 2018/06/12 17:15, Elias M. Mariani wrote:
> > yes, but you don't need to believe me. use 'make show='.
> You, kind sir... are right.
>
> > no, set that in PKGNAME-main. (you can use MODPY_PY_PREFIX to get py- vs
> > py3-).
> PKGNAME-main = ${MODPY_PY_PREFIX}sqlalchemy-${MODPY_EGG_VERSION}
> Produces:
> py3-sqlalchemy-1.2.7p0-python3.tgz
>
> I dont see any other way that modifying the FULLPKGNAME.
>
> Normally that's done by MODULE= lang/python, but it seems the use of
> multi-packages breaks that.
>
Ah I'd forgotten about that, you're right, in which case please just
unconditionally set
FULLPKGNAME-main = ${MODPY_PY_PREFIX}sqlalchemy-${MODPY_EGG_VERSION}
rather than making it flavour-dependent.
update lang/pypy
ping :)
Re: REVISION: databases/py-sqlalchemy
> yes, but you don't need to believe me. use 'make show='.
You, kind sir... are right.
> no, set that in PKGNAME-main. (you can use MODPY_PY_PREFIX to get py- vs
> py3-).
PKGNAME-main = ${MODPY_PY_PREFIX}sqlalchemy-${MODPY_EGG_VERSION}
Produces:
py3-sqlalchemy-1.2.7p0-python3.tgz
I dont see any other way that modifying the FULLPKGNAME.
Normally that's done by MODULE= lang/python, but it seems the use of
multi-packages breaks that.
Re: REVISION: databases/py-sqlalchemy
On Tue, Jun 12, 2018 at 08:44:19PM +0100, Stuart Henderson wrote: > On 2018/06/12 16:34, Elias M. Mariani wrote: > > > +WANTLIB = #empty > > > +RUN_DEPENDS = #empty > > > +LIB_DEPENDS = #empty > > > > > > - it's a noop, but leave these as they were. just set RUN_DEPENDS-docs to > > > empty > > > and let -main inherit from the default. and WANTLIB/LIB_DEPENDS aren't set > > > by default anyway so no need to override, just set them for -main. > > > > Are you sure that RUN_DEPENDS-docs and WANTLIB-docs overrides > > RUN_DEPENDS and WANTLIB ? > > yes, but you don't need to believe me. use 'make show='. or make dump-vars easiest way to figure out everything on a MULTI_PACKAGES port. It's also exhaustively documented in bsd.port.mk(5) (FLAVORS AND MULTI_PACKAGES subsection)
Re: REVISION: databases/py-sqlalchemy
On 2018/06/12 16:34, Elias M. Mariani wrote:
> > +WANTLIB = #empty
> > +RUN_DEPENDS = #empty
> > +LIB_DEPENDS = #empty
> >
> > - it's a noop, but leave these as they were. just set RUN_DEPENDS-docs to
> > empty
> > and let -main inherit from the default. and WANTLIB/LIB_DEPENDS aren't set
> > by default anyway so no need to override, just set them for -main.
>
> Are you sure that RUN_DEPENDS-docs and WANTLIB-docs overrides
> RUN_DEPENDS and WANTLIB ?
yes, but you don't need to believe me. use 'make show='.
> I had a problem with that, because py-sqlalchemy-docs must not be
> dependable on python2.7 or python3.6m.
>
> > +BUILD_DEPENDS =#empty
> > +BUILD_DEPENDS-main = ${_MODPY_BUILD_DEPENDS}
> > ..
> > # Other DB connectors would work, too.
> > -TEST_DEPENDS = devel/py-test-xdist${MODPY_FLAVOR} \
> > +TEST_DEPENDS-main =devel/py-test-xdist${MODPY_FLAVOR} \
> > devel/py-mock${MODPY_FLAVOR}
> > # On python3, sqlite3 is used.
> > -.if ${FLAVOR} == ""
> > -TEST_DEPENDS +=databases/py-sqlite2${MODPY_FLAVOR}>=2.8.3
> > +.if empty (FLAVOR)
> > +TEST_DEPENDS-main += databases/py-sqlite2${MODPY_FLAVOR}>=2.8.3
> > .endif
> >
> > - these are bogus, BUILD_DEPENDS and TEST_DEPENDS relate to the whole port.
> > subpackages are split only in packaging.
>
> True.
>
> > +.if ${FLAVOR:Mpython3}
> > +FULLPKGNAME-main = py3-sqlalchemy-${MODPY_EGG_VERSION:S/p/./}
> > +FULLPKGPATH-main = databases/py-sqlalchemy${MODPY_FLAVOR}
> > +.endif
> >
> > - leave FULLPKG*-main at the default, you only want to override
> > FULLPKG*-docs.
>
> Wouldn't that produce:
> py-sqlalchemy-1.2.7p0-python3.tgz
> or
> py-sqlalchemy-1.2.7p0-main-python3.tgz?
no, set that in PKGNAME-main. (you can use MODPY_PY_PREFIX to get py- vs py3-).
> > - also missing the @pkgpath marker needed in PLIST-main to allow upgrades to
> > work. you can test by installing the old ones from a snap, building new
> > packages
> > and trying to upgrade with 'env TRUSTED_PKG_PATH=/path/to/new/packages
> > PKG_PATH=/path/to/new/packages pkg_add -u'.
>
> OK, reading the docs... about @pkgpath...
Re: REVISION: databases/py-sqlalchemy
> +WANTLIB = #empty
> +RUN_DEPENDS = #empty
> +LIB_DEPENDS = #empty
>
> - it's a noop, but leave these as they were. just set RUN_DEPENDS-docs to
> empty
> and let -main inherit from the default. and WANTLIB/LIB_DEPENDS aren't set
> by default anyway so no need to override, just set them for -main.
Are you sure that RUN_DEPENDS-docs and WANTLIB-docs overrides
RUN_DEPENDS and WANTLIB ?
I had a problem with that, because py-sqlalchemy-docs must not be
dependable on python2.7 or python3.6m.
> +BUILD_DEPENDS =#empty
> +BUILD_DEPENDS-main = ${_MODPY_BUILD_DEPENDS}
> ..
> # Other DB connectors would work, too.
> -TEST_DEPENDS = devel/py-test-xdist${MODPY_FLAVOR} \
> +TEST_DEPENDS-main =devel/py-test-xdist${MODPY_FLAVOR} \
> devel/py-mock${MODPY_FLAVOR}
> # On python3, sqlite3 is used.
> -.if ${FLAVOR} == ""
> -TEST_DEPENDS +=databases/py-sqlite2${MODPY_FLAVOR}>=2.8.3
> +.if empty (FLAVOR)
> +TEST_DEPENDS-main += databases/py-sqlite2${MODPY_FLAVOR}>=2.8.3
> .endif
>
> - these are bogus, BUILD_DEPENDS and TEST_DEPENDS relate to the whole port.
> subpackages are split only in packaging.
True.
> +.if ${FLAVOR:Mpython3}
> +FULLPKGNAME-main = py3-sqlalchemy-${MODPY_EGG_VERSION:S/p/./}
> +FULLPKGPATH-main = databases/py-sqlalchemy${MODPY_FLAVOR}
> +.endif
>
> - leave FULLPKG*-main at the default, you only want to override FULLPKG*-docs.
Wouldn't that produce:
py-sqlalchemy-1.2.7p0-python3.tgz
or
py-sqlalchemy-1.2.7p0-main-python3.tgz?
> - also missing the @pkgpath marker needed in PLIST-main to allow upgrades to
> work. you can test by installing the old ones from a snap, building new
> packages
> and trying to upgrade with 'env TRUSTED_PKG_PATH=/path/to/new/packages
> PKG_PATH=/path/to/new/packages pkg_add -u'.
OK, reading the docs... about @pkgpath...
Re: UPDATE www/hugo
On 06/12/18 18:43, Stuart Henderson wrote:
On 2018/06/12 18:38, fredl wrote:
Hey,
included is a diff for bringing www/hugo to v0.42.
Changelog can be found at: https://github.com/gohugoio/hugo/releases
ok?
Index: Makefile
===
RCS file: /cvs/ports/www/hugo/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile 11 Jun 2018 21:17:14 - 1.1.1.1
+++ Makefile 12 Jun 2018 16:34:14 -
@@ -3,7 +3,7 @@ ONLY_FOR_ARCHS = ${GO_ARCHS}
COMMENT = fast and flexible static site generator
-VERSION = 0.41
+VERSION = 0.42
GH_ACCOUNT = gohugoio
GH_PROJECT = hugo
GH_TAGNAME = v${VERSION}
Index: distinfo
===
RCS file: /cvs/ports/www/hugo/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo 11 Jun 2018 21:17:14 - 1.1.1.1
+++ distinfo 12 Jun 2018 16:34:14 -
@@ -1,2 +1,2 @@
-SHA256 (hugo-0.41.tar.gz) = NeoFBBcyZ3eIJZyg6Z193YvoUqxuzrqru0yDArU6gJE=
-SIZE (hugo-0.41.tar.gz) = 62943303
+SHA256 (hugo-0.42.tar.gz) = ai7WwqSm5eykSBoyIusghU2WAPXQEZeBrKDzq18o5jw=
+SIZE (hugo-0.42.tar.gz) = 63247625
There are a couple of problems I spotted from a quick look at the makefile,
: COMMENT = fast and flexible static site generator
:
: VERSION = 0.41
: GH_ACCOUNT =gohugoio
: GH_PROJECT =hugo
: GH_TAGNAME =v${VERSION}
no point using VERSION here, it's only used in this one place, but ...
:
: CATEGORIES =www
:
: HOMEPAGE = https://gohugo.io/
:
: MAINTAINER =Kevin Wondratsch
:
: #Apache License 2.0
: PERMIT_PACKAGE_CDROM = Yes
:
: WANTLIB += c pthread
:
: MASTER_SITES = https://files.fairydust.space/
GH_* are for fetching files from github auto-generated tarballs,
you shouldn't have both GH_* and MASTER_SITES set.
Hey,
thanks for your review!
Fixed it!
Ok?
Index: Makefile
===
RCS file: /cvs/ports/www/hugo/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile 11 Jun 2018 21:17:14 - 1.1.1.1
+++ Makefile 12 Jun 2018 16:53:05 -
@@ -1,12 +1,7 @@
# $OpenBSD: Makefile,v 1.1.1.1 2018/06/11 21:17:14 solene Exp $
-ONLY_FOR_ARCHS = ${GO_ARCHS}
COMMENT = fast and flexible static site generator
-
-VERSION = 0.41
-GH_ACCOUNT = gohugoio
-GH_PROJECT = hugo
-GH_TAGNAME = v${VERSION}
+DISTNAME = hugo-0.42
CATEGORIES = www
@@ -22,6 +17,8 @@ WANTLIB += c pthread
MASTER_SITES = https://files.fairydust.space/
MODULES = lang/go
+
+ALL_TARGET = github.com/gohugoio/hugo
SEPARATE_BUILD = Yes
Index: distinfo
===
RCS file: /cvs/ports/www/hugo/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo 11 Jun 2018 21:17:14 - 1.1.1.1
+++ distinfo 12 Jun 2018 16:53:05 -
@@ -1,2 +1,2 @@
-SHA256 (hugo-0.41.tar.gz) = NeoFBBcyZ3eIJZyg6Z193YvoUqxuzrqru0yDArU6gJE=
-SIZE (hugo-0.41.tar.gz) = 62943303
+SHA256 (hugo-0.42.tar.gz) = ai7WwqSm5eykSBoyIusghU2WAPXQEZeBrKDzq18o5jw=
+SIZE (hugo-0.42.tar.gz) = 63247625
UPDATE: emulators/stella 5.1.2 -> 5.1.3
Hi,
Here's an update for emulators/stella from 5.1.2 to 5.1.3. The maintainer
has patched upstream now so there is no need for patch-Makefile and
patch-configure (the patches directory can be removed).
This release also fixes an issue with stella dumping
core while cleaning up SDL textures.
I've also removed --disable-gl flag from configure since that was dropped
a while ago and wasn't being used (as per the upstream maintainer).
Thanks,
Tom
Index: Makefile
===
RCS file: /cvs/ports/emulators/stella/Makefile,v
retrieving revision 1.30
diff -u -p -r1.30 Makefile
--- Makefile31 May 2018 14:07:53 - 1.30
+++ Makefile12 Jun 2018 18:23:19 -
@@ -2,7 +2,7 @@
COMMENT = Atari 2600 VCS emulator
-V =5.1.2
+V =5.1.3
DISTNAME = stella-$V
CATEGORIES = emulators
EXTRACT_SUFX = -src.tar.xz
@@ -26,8 +26,7 @@ CXXFLAGS += -I${X11BASE}/include -I${LO
LDFLAGS += -L${LOCALBASE}/lib
CONFIGURE_STYLE = simple
-CONFIGURE_ARGS += --disable-gl \
- --with-libpng-prefix=${LOCALBASE}/lib
+CONFIGURE_ARGS += --with-libpng-prefix=${LOCALBASE}/lib
USE_GMAKE =Yes
Index: distinfo
===
RCS file: /cvs/ports/emulators/stella/distinfo,v
retrieving revision 1.18
diff -u -p -r1.18 distinfo
--- distinfo31 May 2018 14:07:53 - 1.18
+++ distinfo12 Jun 2018 18:23:19 -
@@ -1,2 +1,2 @@
-SHA256 (stella-5.1.2-src.tar.xz) = d7IQ1Rr35L6IwUAU1Qfkg2e83/a4ulE3k/A18+MKIb0=
-SIZE (stella-5.1.2-src.tar.xz) = 1828112
+SHA256 (stella-5.1.3-src.tar.xz) = 4HQxfCXl1Mq+xFWJCdMBw6dlStYghj8F00IkT+a9/go=
+SIZE (stella-5.1.3-src.tar.xz) = 1828448
Re: REVISION: databases/py-sqlalchemy
On 2018/06/12 15:38, Elias M. Mariani wrote:
> Well, is wasn't like qwt... xD
>
> The problem is using MODULES.
> there is no "MODULES-package" it seems.
> So, in the case of qwt it works, because it uses devel/qmake module
> and the flavor adds another module that is x11/qt4.
> devel/qmake does not add any dependency on qwt.
> In this case the only module is lang/python, but the same reacts
> differently with the flavor, so if you build like qwt you get a
> py-sqlalchemy-docs that uses python2.7 as a run dependency (or
> python3.6).
> I worked it out by copying the depends from the python module to
> DEPENDS-main, and clearing the DEPENDS, so, is almost the same but
> backwards... instead of removing the dependencies and wantlibs from
> the -docs package you have to remove them from the vanilla and add
> them only to the -main package.
>
> This solution could be used by many others python packages that build
> with docs and python3 flavor, like:
> py-lxml, py-paramiko, py-parsing, py-pathlib, py-pexpect, py-psycopg2,
> and that is just by looking at the folders that I have in my vm
> /usr/local/share/doc directory... :D
> If you like it (or maybe needs some modifications...) I could make the
> diff for those as well, but my recommendation would be:
> Lets not make the docs a dependency of the main package!
> So, it takes less time installing from packages, most of the time
> people just want the python package as a dependency without needing
> the docs and examples, so why force those things ?
> If you want the docs, OK, you can pkg_add py-sqlalchemy-docs and you have it.
>
> Attached is the new revision of databases/py-sqlalchemy that build 3
> packages: py3-sqlalchemy. py-sqlalchemy, they both depend on
> py-sqlalchemy-docs.
>
> Cheers.
> Elias.
+WANTLIB = #empty
+RUN_DEPENDS = #empty
+LIB_DEPENDS = #empty
- it's a noop, but leave these as they were. just set RUN_DEPENDS-docs to empty
and let -main inherit from the default. and WANTLIB/LIB_DEPENDS aren't set
by default anyway so no need to override, just set them for -main.
+BUILD_DEPENDS =#empty
+BUILD_DEPENDS-main = ${_MODPY_BUILD_DEPENDS}
..
# Other DB connectors would work, too.
-TEST_DEPENDS = devel/py-test-xdist${MODPY_FLAVOR} \
+TEST_DEPENDS-main =devel/py-test-xdist${MODPY_FLAVOR} \
devel/py-mock${MODPY_FLAVOR}
# On python3, sqlite3 is used.
-.if ${FLAVOR} == ""
-TEST_DEPENDS +=databases/py-sqlite2${MODPY_FLAVOR}>=2.8.3
+.if empty (FLAVOR)
+TEST_DEPENDS-main += databases/py-sqlite2${MODPY_FLAVOR}>=2.8.3
.endif
- these are bogus, BUILD_DEPENDS and TEST_DEPENDS relate to the whole port.
subpackages are split only in packaging.
+.if ${FLAVOR:Mpython3}
+FULLPKGNAME-main = py3-sqlalchemy-${MODPY_EGG_VERSION:S/p/./}
+FULLPKGPATH-main = databases/py-sqlalchemy${MODPY_FLAVOR}
+.endif
- leave FULLPKG*-main at the default, you only want to override FULLPKG*-docs.
- also missing the @pkgpath marker needed in PLIST-main to allow upgrades to
work. you can test by installing the old ones from a snap, building new packages
and trying to upgrade with 'env TRUSTED_PKG_PATH=/path/to/new/packages
PKG_PATH=/path/to/new/packages pkg_add -u'.
Re: NEW: security/tclpledge & security/jimpledge
Now without the confusing TESTFLAGS bits. Stu > -- Original Message -- > From: Stuart Cassoff <3...@bell.net> > Date: June 11, 2018 at 1:02 PM > > > Ping on these, they're real simple. > > > -- Original Message -- > > From: Stuart Cassoff <3...@bell.net> > > Date: June 9, 2018 at 4:59 AM > > > > > > Forgot to mention that they've been tested on amd64 and i386, but only on > > Earth. > > > > > > Stu > > > > > > > -- Original Message -- > > > From: Stuart Cassoff <3...@bell.net> > > > Date: June 7, 2018 at 1:29 AM > > > > > > > > > Tcl and Jim interfaces to pledge(2). > > > > > > Stu > > > jimpledge-1.0-port.tar.gz Description: application/gzip tclpledge-1.0-port.tar.gz Description: application/gzip
qtwebkit consumers are broken
Looks like x11/qt5/qtwebkit is broken. I'm sure all consumers are affected. backtraces below: digikam: Thread 1 received signal SIGTRAP, Trace/breakpoint trap. 0x079d971c05fb in cti_vm_throw () from /usr/local/lib/libQt5WebKit.so.2.1 (gdb) bt #0 0x079d971c05fb in cti_vm_throw () from /usr/local/lib/libQt5WebKit.so.2.1 #1 0x079d971525e7 in JSC::Interpreter::execute(JSC::ProgramExecutable*, JSC::ExecState*, JSC::JSObject*) () from /usr/local/lib/libQt5WebKit.so.2.1 #2 0x079d9726b52e in JSC::evaluate(JSC::ExecState*, JSC::SourceCode const&, JSC::JSValue, JSC::JSValue*) () from /usr/local/lib/libQt5WebKit.so.2.1 #3 0x079d95f83b7d in WebCore::ScriptController::evaluateInWorld(WebCore::ScriptSourceCode const&, WebCore::DOMWrapperWorld*) () from /usr/local/lib/libQt5WebKit.so.2.1 #4 0x079d95f83e06 in WebCore::ScriptController::evaluate(WebCore::ScriptSourceCode const&) () from /usr/local/lib/libQt5WebKit.so.2.1 #5 0x079d96f95511 in WebCore::ScriptElement::executeScript(WebCore::ScriptSourceCode const&) () from /usr/local/lib/libQt5WebKit.so.2.1 #6 0x079d9605e92f in WebCore::HTMLScriptRunner::executePendingScriptAndDispatchEvent(WebCore::PendingScript&) () from /usr/local/lib/libQt5WebKit.so.2.1 #7 0x079d9605e7e4 in WebCore::HTMLScriptRunner::executeParsingBlockingScript() () from /usr/local/lib/libQt5WebKit.so.2.1 #8 0x079d9605f10b in WebCore::HTMLScriptRunner::executeScriptsWaitingForLoad(WebCore::CachedResource*) () from /usr/local/lib/libQt5WebKit.so.2.1 #9 0x079d9605370f in WebCore::HTMLDocumentParser::notifyFinished(WebCore::CachedResource*) () from /usr/local/lib/libQt5WebKit.so.2.1 #10 0x079d960a2453 in WebCore::CachedResource::checkNotify() () from /usr/local/lib/libQt5WebKit.so.2.1 #11 0x079d960f10f9 in WebCore::SubresourceLoader::didFinishLoading(double) () from /usr/local/lib/libQt5WebKit.so.2.1 #12 0x079d9630d2fa in WebCore::QNetworkReplyHandler::finish() () from /usr/local/lib/libQt5WebKit.so.2.1 #13 0x079d9630bb0a in WebCore::QNetworkReplyHandlerCallQueue::flush() () from /usr/local/lib/libQt5WebKit.so.2.1 #14 0x079d9630f40a in WebCore::QNetworkReplyWrapper::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) () from /usr/local/lib/libQt5WebKit.so.2.1 #15 0x079dbc057572 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/local/lib/libQt5Core.so.2.2 #16 0x079d3fbe7dea in QNetworkReply::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) () from /usr/local/lib/libQt5Network.so.2.2 #17 0x079dbc04f952 in QObject::event(QEvent*) () from /usr/local/lib/libQt5Core.so.2.2 #18 0x079ddfef80dc in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/local/lib/libQt5Widgets.so.2.2 #19 0x079ddfef96d9 in QApplication::notify(QObject*, QEvent*) () from /usr/local/lib/libQt5Widgets.so.2.2 #20 0x079dbc0200ba in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/local/lib/libQt5Core.so.2.2 #21 0x079dbc0211c7 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/local/lib/libQt5Core.so.2.2 #22 0x079dbc07e987 in postEventSourceDispatch(_GSource*, int (*)(void*), void*) () from /usr/local/lib/libQt5Core.so.2.2 #23 0x079daff7e889 in g_main_dispatch (context=) at gmain.c:3177 #24 g_main_context_dispatch (context=) at gmain.c:3830 #25 0x079daff7ec93 in g_main_context_iterate (context=, block=, dispatch=, self=) at gmain.c:3903 #26 0x079daff7ed73 in g_main_context_iteration (context=0x79d7b329e00, may_block=0) at gmain.c:3964 #27 0x079dbc07e1cb in QEventDispatcherGlib::processEvents(QFlags) () from /usr/local/lib/libQt5Core.so.2.2 #28 0x079dbc020766 in QCoreApplication::processEvents(QFlags) () from /usr/local/lib/libQt5Core.so.2.2 #29 0x079d993448b7 in Digikam::DSplashScreen::setMessage(QString const&) () from /usr/local/lib/libdigikamcore.so.1.0 #30 0x079dd4cd1c04 in Digikam::DigikamApp::setupActions() () from /usr/local/lib/libdigikamgui.so.1.0 #31 0x079dd4cd57b7 in Digikam::DigikamApp::DigikamApp() () from /usr/local/lib/libdigikamgui.so.1.0 #32 0x079b29902fc0 in main () otter-browser: Thread 1 received signal SIGTRAP, Trace/breakpoint trap. 0x1f261430f4ad in cti_op_construct_NotJSConstruct () from /usr/local/lib/qt5/./libQt5WebKit.so.2.1 (gdb) bt #0 0x1f261430f4ad in cti_op_construct_NotJSConstruct () from /usr/local/lib/qt5/./libQt5WebKit.so.2.1 #1 0x1f26142a85e7 in JSC::Interpreter::execute(JSC::ProgramExecutable*, JSC::ExecState*, JSC::JSObject*) () from /usr/local/lib/qt5/./libQt5WebKit.so.2.1 #2 0x1f26143c152e in JSC::evaluate(JSC::ExecState*, JSC::SourceCode const&, JSC::JSValue, JSC::JSValue*) () from /usr/local/lib/qt5/./libQt5WebKit.so.2.1 #3 0x1f26130d9b7d in WebCore::ScriptController::evaluateInWorld(WebCore::ScriptSourceCode const&, WebCore::DOMWrapperWorld*) () from /usr/local/lib/qt5/./libQt5WebKit
Re: NEW: graphics/digikam [4/4 digikam 5]
On Tue Jun 12, 2018 at 11:04:35AM +0200, Marc Espie wrote: > On Tue, Jun 12, 2018 at 07:16:39AM +0200, Rafael Sadowski wrote: > > On Sun Jun 10, 2018 at 09:23:52PM -0300, Elias M. Mariani wrote: > > > No good. > > > Couldn't get digikam to work. > > > This one will be hard to crack. > > > > > > > Thanks for the feedback. > > > > I run in the same trap. This is new, I'm trying to fix it, I need to > > fix it. I need digikam back. > > If this is new, this is likely to be some kind of buffer overflow that > retguard exposes. > It's defiantly new, webkit. Thread 1 received signal SIGTRAP, Trace/breakpoint trap. 0x079d971c05fb in cti_vm_throw () from /usr/local/lib/libQt5WebKit.so.2.1 (gdb) bt #0 0x079d971c05fb in cti_vm_throw () from /usr/local/lib/libQt5WebKit.so.2.1 #1 0x079d971525e7 in JSC::Interpreter::execute(JSC::ProgramExecutable*, JSC::ExecState*, JSC::JSObject*) () from /usr/local/lib/libQt5WebKit.so.2.1 #2 0x079d9726b52e in JSC::evaluate(JSC::ExecState*, JSC::SourceCode const&, JSC::JSValue, JSC::JSValue*) () from /usr/local/lib/libQt5WebKit.so.2.1 #3 0x079d95f83b7d in WebCore::ScriptController::evaluateInWorld(WebCore::ScriptSourceCode const&, WebCore::DOMWrapperWorld*) () from /usr/local/lib/libQt5WebKit.so.2.1 #4 0x079d95f83e06 in WebCore::ScriptController::evaluate(WebCore::ScriptSourceCode const&) () from /usr/local/lib/libQt5WebKit.so.2.1 #5 0x079d96f95511 in WebCore::ScriptElement::executeScript(WebCore::ScriptSourceCode const&) () from /usr/local/lib/libQt5WebKit.so.2.1 #6 0x079d9605e92f in WebCore::HTMLScriptRunner::executePendingScriptAndDispatchEvent(WebCore::PendingScript&) () from /usr/local/lib/libQt5WebKit.so.2.1 #7 0x079d9605e7e4 in WebCore::HTMLScriptRunner::executeParsingBlockingScript() () from /usr/local/lib/libQt5WebKit.so.2.1 #8 0x079d9605f10b in WebCore::HTMLScriptRunner::executeScriptsWaitingForLoad(WebCore::CachedResource*) () from /usr/local/lib/libQt5WebKit.so.2.1 #9 0x079d9605370f in WebCore::HTMLDocumentParser::notifyFinished(WebCore::CachedResource*) () from /usr/local/lib/libQt5WebKit.so.2.1 #10 0x079d960a2453 in WebCore::CachedResource::checkNotify() () from /usr/local/lib/libQt5WebKit.so.2.1 #11 0x079d960f10f9 in WebCore::SubresourceLoader::didFinishLoading(double) () from /usr/local/lib/libQt5WebKit.so.2.1 #12 0x079d9630d2fa in WebCore::QNetworkReplyHandler::finish() () from /usr/local/lib/libQt5WebKit.so.2.1 #13 0x079d9630bb0a in WebCore::QNetworkReplyHandlerCallQueue::flush() () from /usr/local/lib/libQt5WebKit.so.2.1 #14 0x079d9630f40a in WebCore::QNetworkReplyWrapper::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) () from /usr/local/lib/libQt5WebKit.so.2.1 #15 0x079dbc057572 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/local/lib/libQt5Core.so.2.2 #16 0x079d3fbe7dea in QNetworkReply::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) () from /usr/local/lib/libQt5Network.so.2.2 #17 0x079dbc04f952 in QObject::event(QEvent*) () from /usr/local/lib/libQt5Core.so.2.2 #18 0x079ddfef80dc in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/local/lib/libQt5Widgets.so.2.2 #19 0x079ddfef96d9 in QApplication::notify(QObject*, QEvent*) () from /usr/local/lib/libQt5Widgets.so.2.2 #20 0x079dbc0200ba in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/local/lib/libQt5Core.so.2.2 #21 0x079dbc0211c7 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/local/lib/libQt5Core.so.2.2 #22 0x079dbc07e987 in postEventSourceDispatch(_GSource*, int (*)(void*), void*) () from /usr/local/lib/libQt5Core.so.2.2 #23 0x079daff7e889 in g_main_dispatch (context=) at gmain.c:3177 #24 g_main_context_dispatch (context=) at gmain.c:3830 #25 0x079daff7ec93 in g_main_context_iterate (context=, block=, dispatch=, self=) at gmain.c:3903 #26 0x079daff7ed73 in g_main_context_iteration (context=0x79d7b329e00, may_block=0) at gmain.c:3964 #27 0x079dbc07e1cb in QEventDispatcherGlib::processEvents(QFlags) () from /usr/local/lib/libQt5Core.so.2.2 #28 0x079dbc020766 in QCoreApplication::processEvents(QFlags) () from /usr/local/lib/libQt5Core.so.2.2 #29 0x079d993448b7 in Digikam::DSplashScreen::setMessage(QString const&) () from /usr/local/lib/libdigikamcore.so.1.0 #30 0x079dd4cd1c04 in Digikam::DigikamApp::setupActions() () from /usr/local/lib/libdigikamgui.so.1.0 #31 0x079dd4cd57b7 in Digikam::DigikamApp::DigikamApp() () from /usr/local/lib/libdigikamgui.so.1.0 #32 0x079b29902fc0 in main ()
Re: [UPDATE] graphics/p5-Image-ExifTool
Hi, Thanks for the update and I'm sorry I've not been able to keep updated with this small task. Unfortunately circumstances dictate that I remove myself as maintainer and allow someone else to take over. cheers, --patrick On 6/12/18, Remi Pointel wrote: > Hi, > > attached is the diff to update exiftool to latest release. > > Ok? > > Cheers, > > Remi.
Re: UPDATE www/hugo
On 2018/06/12 18:38, fredl wrote:
> Hey,
>
> included is a diff for bringing www/hugo to v0.42.
> Changelog can be found at: https://github.com/gohugoio/hugo/releases
>
> ok?
>
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/www/hugo/Makefile,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 Makefile
> --- Makefile 11 Jun 2018 21:17:14 - 1.1.1.1
> +++ Makefile 12 Jun 2018 16:34:14 -
> @@ -3,7 +3,7 @@ ONLY_FOR_ARCHS = ${GO_ARCHS}
>
> COMMENT = fast and flexible static site generator
>
> -VERSION = 0.41
> +VERSION = 0.42
> GH_ACCOUNT = gohugoio
> GH_PROJECT = hugo
> GH_TAGNAME = v${VERSION}
> Index: distinfo
> ===
> RCS file: /cvs/ports/www/hugo/distinfo,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 distinfo
> --- distinfo 11 Jun 2018 21:17:14 - 1.1.1.1
> +++ distinfo 12 Jun 2018 16:34:14 -
> @@ -1,2 +1,2 @@
> -SHA256 (hugo-0.41.tar.gz) = NeoFBBcyZ3eIJZyg6Z193YvoUqxuzrqru0yDArU6gJE=
> -SIZE (hugo-0.41.tar.gz) = 62943303
> +SHA256 (hugo-0.42.tar.gz) = ai7WwqSm5eykSBoyIusghU2WAPXQEZeBrKDzq18o5jw=
> +SIZE (hugo-0.42.tar.gz) = 63247625
>
There are a couple of problems I spotted from a quick look at the makefile,
: COMMENT = fast and flexible static site generator
:
: VERSION = 0.41
: GH_ACCOUNT =gohugoio
: GH_PROJECT =hugo
: GH_TAGNAME =v${VERSION}
no point using VERSION here, it's only used in this one place, but ...
:
: CATEGORIES =www
:
: HOMEPAGE = https://gohugo.io/
:
: MAINTAINER =Kevin Wondratsch
:
: #Apache License 2.0
: PERMIT_PACKAGE_CDROM = Yes
:
: WANTLIB += c pthread
:
: MASTER_SITES = https://files.fairydust.space/
GH_* are for fetching files from github auto-generated tarballs,
you shouldn't have both GH_* and MASTER_SITES set.
UPDATE www/hugo
Hey,
included is a diff for bringing www/hugo to v0.42.
Changelog can be found at: https://github.com/gohugoio/hugo/releases
ok?
Index: Makefile
===
RCS file: /cvs/ports/www/hugo/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile 11 Jun 2018 21:17:14 - 1.1.1.1
+++ Makefile 12 Jun 2018 16:34:14 -
@@ -3,7 +3,7 @@ ONLY_FOR_ARCHS = ${GO_ARCHS}
COMMENT = fast and flexible static site generator
-VERSION = 0.41
+VERSION = 0.42
GH_ACCOUNT = gohugoio
GH_PROJECT = hugo
GH_TAGNAME = v${VERSION}
Index: distinfo
===
RCS file: /cvs/ports/www/hugo/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo 11 Jun 2018 21:17:14 - 1.1.1.1
+++ distinfo 12 Jun 2018 16:34:14 -
@@ -1,2 +1,2 @@
-SHA256 (hugo-0.41.tar.gz) = NeoFBBcyZ3eIJZyg6Z193YvoUqxuzrqru0yDArU6gJE=
-SIZE (hugo-0.41.tar.gz) = 62943303
+SHA256 (hugo-0.42.tar.gz) = ai7WwqSm5eykSBoyIusghU2WAPXQEZeBrKDzq18o5jw=
+SIZE (hugo-0.42.tar.gz) = 63247625
Re: UPDATE sysutils/borgbackup
On 06/11/18 21:24, Björn Ketelaars wrote:
> Enclosed a diff for bringing borgbackup to 1.1.6, which is a bug fix and
> small feature improvements release. Changelog can be found at
> https://github.com/borgbackup/borg/blob/1.1.6/docs/changes.rst#version-116-2018-06-11
>
> "${MODPY_CMD} build_ext --inplace" has been moved to pre-test as this is
> only needed for the testing phase.
>
> While here change ${MAINTAINER} mail address.
>
> 'make test' runs successfully. Tested by making, and restoring several
> backups on amd64.
>
> OK?
>
it's working fine, thanks.
ok giovanni@
Cheers
Giovanni
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/sysutils/borgbackup/Makefile,v
> retrieving revision 1.21
> diff -u -p -r1.21 Makefile
> --- Makefile 21 Apr 2018 11:54:55 - 1.21
> +++ Makefile 11 Jun 2018 18:46:10 -
> @@ -2,13 +2,12 @@
>
> COMMENT =deduplicating backup program
>
> -MODPY_EGG_VERSION = 1.1.5
> -REVISION = 0
> +MODPY_EGG_VERSION = 1.1.6
> DISTNAME = borgbackup-${MODPY_EGG_VERSION}
>
> CATEGORIES = sysutils
>
> -MAINTAINER = Bjorn Ketelaars
> +MAINTAINER = Bjorn Ketelaars
>
> # BSD-3
> PERMIT_PACKAGE_CDROM = Yes
> @@ -31,11 +30,11 @@ TEST_DEPENDS += ${RUN_DEPENDS} \
> devel/py-test-benchmark${MODPY_FLAVOR} \
> devel/py-test-xdist${MODPY_FLAVOR}
>
> -post-build:
> - ${MODPY_CMD} build_ext --inplace
> -
> post-install:
> ${INSTALL_MAN} ${WRKSRC}/docs/man/*.1 ${PREFIX}/man/man1/
> +
> +pre-test:
> + ${MODPY_CMD} build_ext --inplace
>
> do-test: fake
> cd ${WRKSRC}; \
> Index: distinfo
> ===
> RCS file: /cvs/ports/sysutils/borgbackup/distinfo,v
> retrieving revision 1.14
> diff -u -p -r1.14 distinfo
> --- distinfo 3 Apr 2018 15:32:25 - 1.14
> +++ distinfo 11 Jun 2018 18:46:10 -
> @@ -1,2 +1,2 @@
> -SHA256 (borgbackup-1.1.5.tar.gz) =
> Q1bmxxKHHziePLHWOC40HqY1+eXGXeHNj80QPQ+2bT0=
> -SIZE (borgbackup-1.1.5.tar.gz) = 3392774
> +SHA256 (borgbackup-1.1.6.tar.gz) =
> odLkdMhdOtPVmz+CCbVUllPIiRIILqAVnSei6AyRCTA=
> +SIZE (borgbackup-1.1.6.tar.gz) = 3441523
>
Re: [NEW] devel/py-pandas
and the attached tar.gz ? Missed by that much... 2018-06-12 11:06 GMT-03:00 Elias M. Mariani : > Sending the new version for test. > The Makefile uses two flavors: > python3 and test > So, if you want to install you just run: > env FLAVOR="" make install > or > env FLAVOR="python3" make install > > That generates everything only once. > > if you want to test: > env FLAVOR="test" make test > or > env FLAVOR="test python3" make test > also building just once but the result is non installable. > > I think is the best choice, if you want to test you build once, if you > want to install you build once, if you want both... well. just build > twice... > Results of the regression tests (using textproc/py-xlrd as a > dependency test witch I just sent to ports@): > python2.7 = 2 failed, 24523 passed, 1675 skipped, 79 xfailed, 24 > xpassed, 86 warnings in 76400.37 seconds > python3.6 = 3 failed, 24619 passed, 1573 skipped, 80 xfailed, 26 > xpassed, 197 warnings in 6313.57 seconds > both OpenBSD-current, amd64. > 2 failures are because the tester tries to invoke "python" as a > command, witch it doesn't (necessarily) exist... Just ignore those > 2... > Also notice the difference in test time between py2 and py3... is > better to use the py3 version to do tests... > Some skips are hardcoded (wt...) others are because we are missing > some test-dependencies, keep in mind that this tests cover pretty much > everything that py-pandas does, just look at the RUN_DEPENDS vs > TEST_DEPENDS and you get an idea of the magnitude of the test. > > So Edd kindly offered to check it out. > Ignore the regression tests, the ideal would be to test it in a real > application to see if really works as the regression tests say. > Also I have been working on ports for some weeks now, but this is the > first with some real logic inside, if Stuart or someone can check the > Makefile to see if some corrections are needed would be great. > > Thanks to all, this pre-port-release was already been made with help > of several people with examples, advises, warnings, etc. > Alexandr Shadchin give me his permission to merge our versions in > openbsd-wip, so, credits to him as well. > > Cheers. > Elias. > > 2018-06-09 19:17 GMT-03:00 Elias M. Mariani : >> Okey, last update: >> - patched the docs building system. >> - while building the docs yo need LOTS of depends and for some reason >> a X session running (yes... I know...). So, either I am doing >> something very wrong or this is a nasty way of building docs. I guess >> that something in the source code uses the backend-gtk part of >> Matplotlib and that triggers the creation of a cursor... because the >> hole process uses the actual code working to build the docs... I get >> lost in this nonsense... >> My Solution will be: build without any docs, use >> http://pandas.pydata.org/pandas-docs/stable/ for that. >> Build py-pandas normally with setuptools and python3 flavor. >> Regression tests will be done by re-building the port, so yes, we >> build the port twice but only for testing, normal build will be done >> just once. >> Any ideas or/and OK ? >> >> Cheers. >> Elias. >> >> >> 2018-06-09 15:59 GMT-03:00 Elias M. Mariani : Not sure if this helps, but the version in openbsd-wip has a (commented) block which looks like it does a second (in-place) build to make the docs: https://github.com/jasperla/openbsd-wip/blob/cb917e8bcdf2b912209f97652eca484494138fa3/math/py-pandas/Makefile#L65-L68 If we really can't get the docs until the package is installed, you could use SUBDIRs, and have a doc subdir BUILD_DEPEND on the main package. >>> >>> Yes, but building the same package twice does not sound nice at all. >>> I will add the py-pandas dependency to build py-pandas-docs, that >>> seems the best solution overall... >>> >>> Cheers. >>> Elias. py-pandas.tar.gz Description: GNU Zip compressed data
Re: [NEW] devel/py-pandas
Sending the new version for test. The Makefile uses two flavors: python3 and test So, if you want to install you just run: env FLAVOR="" make install or env FLAVOR="python3" make install That generates everything only once. if you want to test: env FLAVOR="test" make test or env FLAVOR="test python3" make test also building just once but the result is non installable. I think is the best choice, if you want to test you build once, if you want to install you build once, if you want both... well. just build twice... Results of the regression tests (using textproc/py-xlrd as a dependency test witch I just sent to ports@): python2.7 = 2 failed, 24523 passed, 1675 skipped, 79 xfailed, 24 xpassed, 86 warnings in 76400.37 seconds python3.6 = 3 failed, 24619 passed, 1573 skipped, 80 xfailed, 26 xpassed, 197 warnings in 6313.57 seconds both OpenBSD-current, amd64. 2 failures are because the tester tries to invoke "python" as a command, witch it doesn't (necessarily) exist... Just ignore those 2... Also notice the difference in test time between py2 and py3... is better to use the py3 version to do tests... Some skips are hardcoded (wt...) others are because we are missing some test-dependencies, keep in mind that this tests cover pretty much everything that py-pandas does, just look at the RUN_DEPENDS vs TEST_DEPENDS and you get an idea of the magnitude of the test. So Edd kindly offered to check it out. Ignore the regression tests, the ideal would be to test it in a real application to see if really works as the regression tests say. Also I have been working on ports for some weeks now, but this is the first with some real logic inside, if Stuart or someone can check the Makefile to see if some corrections are needed would be great. Thanks to all, this pre-port-release was already been made with help of several people with examples, advises, warnings, etc. Alexandr Shadchin give me his permission to merge our versions in openbsd-wip, so, credits to him as well. Cheers. Elias. 2018-06-09 19:17 GMT-03:00 Elias M. Mariani : > Okey, last update: > - patched the docs building system. > - while building the docs yo need LOTS of depends and for some reason > a X session running (yes... I know...). So, either I am doing > something very wrong or this is a nasty way of building docs. I guess > that something in the source code uses the backend-gtk part of > Matplotlib and that triggers the creation of a cursor... because the > hole process uses the actual code working to build the docs... I get > lost in this nonsense... > My Solution will be: build without any docs, use > http://pandas.pydata.org/pandas-docs/stable/ for that. > Build py-pandas normally with setuptools and python3 flavor. > Regression tests will be done by re-building the port, so yes, we > build the port twice but only for testing, normal build will be done > just once. > Any ideas or/and OK ? > > Cheers. > Elias. > > > 2018-06-09 15:59 GMT-03:00 Elias M. Mariani : >>> Not sure if this helps, but the version in openbsd-wip has a (commented) >>> block which looks like it does a second (in-place) build to make the >>> docs: >>> https://github.com/jasperla/openbsd-wip/blob/cb917e8bcdf2b912209f97652eca484494138fa3/math/py-pandas/Makefile#L65-L68 >>> >>> If we really can't get the docs until the package is installed, you >>> could use SUBDIRs, and have a doc subdir BUILD_DEPEND on the main >>> package. >> >> Yes, but building the same package twice does not sound nice at all. >> I will add the py-pandas dependency to build py-pandas-docs, that >> seems the best solution overall... >> >> Cheers. >> Elias.
[UPDATE] graphics/p5-Image-ExifTool
Hi,
attached is the diff to update exiftool to latest release.
Ok?
Cheers,
Remi.
Index: Makefile
===
RCS file: /cvs/ports/graphics/p5-Image-ExifTool/Makefile,v
retrieving revision 1.42
diff -u -p -u -p -r1.42 Makefile
--- Makefile 13 Mar 2018 15:27:45 - 1.42
+++ Makefile 12 Jun 2018 13:54:10 -
@@ -2,7 +2,7 @@
COMMENT= read and write meta information in image/audio/video files
-DISTNAME= Image-ExifTool-10.80
+DISTNAME= Image-ExifTool-11.01
CATEGORIES= graphics
HOMEPAGE= http://owl.phy.queensu.ca/~phil/exiftool/
Index: distinfo
===
RCS file: /cvs/ports/graphics/p5-Image-ExifTool/distinfo,v
retrieving revision 1.35
diff -u -p -u -p -r1.35 distinfo
--- distinfo 13 Mar 2018 15:27:45 - 1.35
+++ distinfo 12 Jun 2018 13:54:10 -
@@ -1,2 +1,2 @@
-SHA256 (Image-ExifTool-10.80.tar.gz) = vPiWYAd22O85qGcIG0hCaDftXujKGbU92dhqMXnJPJM=
-SIZE (Image-ExifTool-10.80.tar.gz) = 4347722
+SHA256 (Image-ExifTool-11.01.tar.gz) = cF+/SkLXcsVIr/9MZLPbPpXrNH5bSKzWbdfXcSwZvJw=
+SIZE (Image-ExifTool-11.01.tar.gz) = 4411472
Index: pkg/PLIST
===
RCS file: /cvs/ports/graphics/p5-Image-ExifTool/pkg/PLIST,v
retrieving revision 1.30
diff -u -p -u -p -r1.30 PLIST
--- pkg/PLIST 13 Mar 2018 15:27:45 - 1.30
+++ pkg/PLIST 12 Jun 2018 13:54:10 -
@@ -201,6 +201,7 @@ ${P5SITE}/Image/ExifTool/Unknown.pm
${P5SITE}/Image/ExifTool/VCard.pm
${P5SITE}/Image/ExifTool/Validate.pm
${P5SITE}/Image/ExifTool/Vorbis.pm
+${P5SITE}/Image/ExifTool/WTV.pm
${P5SITE}/Image/ExifTool/WriteCanonRaw.pl
${P5SITE}/Image/ExifTool/WriteExif.pl
${P5SITE}/Image/ExifTool/WriteIPTC.pl
@@ -378,6 +379,7 @@ ${P5SITE}/Image/ExifTool/iWork.pm
@man man/man3p/Image::ExifTool::VCard.3p
@man man/man3p/Image::ExifTool::Validate.3p
@man man/man3p/Image::ExifTool::Vorbis.3p
+@man man/man3p/Image::ExifTool::WTV.3p
@man man/man3p/Image::ExifTool::WriteCanonRaw.3p
@man man/man3p/Image::ExifTool::WriteExif.3p
@man man/man3p/Image::ExifTool::WriteIPTC.3p
NEW: textproc/py-xlrd
Extract data from Excel spreadsheets (.xls and .xlsx, versions 2.0 onwards) on any platform. Pure Python (2.7, 3.4+). Strong support for Excel dates. Unicode-aware. http://www.python-excel.org/ No dependencies. python3 flavor included. Its a dependency to test math/py-pandas. Cheers. Elias.
[new] sysutils/dep - Go's dependency management tool (for now)
Hi, Here is a port of dep, go's dependency manager. Every now and then Go apps don't include the vendor dir and we will have to use dep or similar (glide on occasion) to populate it for proper distfile creation. This tools was used to build the vendor directory for sysutils/fzf for example. >From DESCR: --- dep is a prototype dependency management tool for Go. It requires Go 1.9 or newer to compile. dep is safe for production use. dep is the official experiment, but not yet the official tool. Check out the Roadmap for more on what this means! --- OK? Cheers, Aaron -- PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE dep.tgz Description: Binary data
Re: NEW: textproc/tdom
On 2018/06/11 12:56, Stuart Cassoff wrote:
>
> > -- Original Message --
> > From: Stuart Henderson
> > Date: June 11, 2018 at 12:47 PM
> >
> >
> > On 2018/06/11 10:43, Stuart Cassoff wrote:
> > > Tested on i386 and amd64 at ~22C.
> >
> > DISTNAME = tdom-${V}-src
> > PKGNAME = tdom-${V}
> > ..
> > EXTRACT_SUFX = .tgz
> > ..
> > WRKDIST = ${WRKDIR}/tdom-${V}
> >
> > - I think you should be able to replace the above 4 lines with
> >
> > DISTNAME = tdom-${V}
> > EXTRACT_SUFX = -src.tgz
>
> Yeah, that's great! Thanks!
>
> >
> > Can you explain what's going on with TESTFLAGS please?
> >
>
> Flags passed to tcltest, like with Tcl, Tk and other Tcl extensions.
> So I can test things easier.
>
> $ make test TESTFLAGS='-verbose bstep'
>
Thanks, would you mind putting the related bits for this together in one place
with a comment so it's a bit more obvious what's going on? Otherwise just
reading
the port Makefile it doesn't look useful.
# allow overriding on the make(1) command line; for tcltest
TESTFLAGS =
TEST_FLAGS =TESTFLAGS='${TESTFLAGS}'
Otherwise OK.
Re: [PATCH] ntfs-3g needs OpenBSD specific groupmember() function
On Mon, Jun 04, 2018 at 10:23:14AM +0200, Martin Pieuchot wrote:
> On 04/06/18(Mon) 14:26, Helg wrote:
> > Hi Ports,
> >
> > I have an upcoming patch to FUSE that passes the current process tid,
> > uid, gid and umask to the file system. This has highlighted a bug in the
> > port where the groupmember() function in libntfs-3g/security.c assumes
> > it's runing on Linux where thread information is available in /proc.
> >
> > This diff adds an OpenBSD specific implementation of this function.
>
> We should refrain linking to libkvm. In this particular case you should
> be able to call the KERN_PROC sysctl(2) directly.
I've completely rewritten the patch to use sysctl(2) instead.
ok?
Index: patches/patch-libntfs-3g_security_c
===
RCS file: patches/patch-libntfs-3g_security_c
diff -N patches/patch-libntfs-3g_security_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-libntfs-3g_security_c 4 Jun 2018 14:03:42 -
@@ -0,0 +1,85 @@
+$OpenBSD$
+
+Index: libntfs-3g/security.c
+--- libntfs-3g/security.c.orig
libntfs-3g/security.c
+@@ -47,6 +47,10 @@
+ #ifdef HAVE_SYS_STAT_H
+ #include
+ #endif
++#ifdef __OpenBSD__
++#include
++#include
++#endif
+
+ #include
+ #include
+@@ -1228,6 +1232,68 @@ static BOOL groupmember(struct SECURITY_CONTEXT *scx,
+ close(fd);
+ }
+ }
++ return (ismember);
++}
++
++#elif defined(__OpenBSD__)
++
++static BOOL groupmember(struct SECURITY_CONTEXT *scx, uid_t uid, gid_t gid)
++{
++ struct kinfo_proc *kp;
++ size_t size;
++ int mib[6];
++ int ip, ig;
++ int pcnt;
++ gid_t *g;
++ pid_t tid;
++ BOOL ismember;
++
++ if (scx->vol->secure_flags & (1 << SECURITY_STATICGRPS))
++ ismember = staticgroupmember(scx, uid, gid);
++ else {
++ ismember = FALSE; /* default return */
++ tid = scx->tid;
++ mib[0] = CTL_KERN;
++ mib[1] = KERN_PROC;
++ mib[2] = KERN_PROC_ALL | KERN_PROC_SHOW_THREADS;
++ mib[3] = 0;
++ mib[4] = sizeof(struct kinfo_proc);
++ mib[5] = 0;
++ if (sysctl(mib, 6, NULL, &size, NULL, 0) == -1)
++ ntfs_log_error("Could not get size of process table: "
++ "%s\n", strerror(errno));
++ else {
++ mib[5] = size / sizeof(struct kinfo_proc);
++ kp = malloc(size);
++ if ((kp == NULL) ||
++ (sysctl(mib, 6, kp, &size, NULL, 0) == -1))
++ ntfs_log_error("Could not get process table: "
++ "%s\n", strerror(errno));
++ else {
++ pcnt = size / sizeof(struct kinfo_proc);
++ ip = 0;
++ while ((kp[ip].p_tid != tid) && (ip < pcnt))
++ ip++;
++
++ if (ip < pcnt) {
++ if (kp[ip].p_gid == gid)
++ ismember = TRUE;
++ g = kp[ip].p_groups;
++ ig = 0;
++ while (!ismember
++ && (ig < kp[ip].p_ngroups)
++ && (*g != gid)) {
++ ig++;
++ g++;
++ }
++ if (ig < kp[ip].p_ngroups)
++ ismember = TRUE;
++ }
++ free(kp);
++ }
++ }
++ }
++
+ return (ismember);
+ }
+
Re: update net/toot to 0.18.0
On 2018/06/12 14:26, Klemens Nanni wrote: > New release coming from stable assets this time. Changes since the last > version: > > * Add support for public, tag and list timelines in `toot timeline` > (#52) > * Add `--sensitive` and `--spoiler-text` options to `toot post` (#63) > * Curses app improvements: > * Respect sensitive content, require keypress to show > * Add help modal (press h) > * Misc rendering improvements > > Still works fine for me on amd64, tests pass. > > OK? OK. It's weird that they have slightly different tarballs for the github asset and the version on pypi (no real content changes, just metadata files etc)...
Re: NEW: mkdocs
On 2018/06/10 14:00, Edward Lopez-Acosta wrote:
> I went ahead and clarified the description. Initially I used the one they
> have on their site.
> I also cannot update the title but forgot to include both of these would be
> unde the
> www category.
>
> On Sun, Jun 10, 2018 at 1:38 PM, Ingo Schwarze wrote:
>
> > Hi,
> >
> > Edward Lopez-Acosta wrote on Sun, Jun 10, 2018 at 01:31:46PM -0500:
> >
> > > ---
> > > Overview
> > >
> > > MkDocs is a fast, simple and downright gorgeous static site generator
> > > that's geared towards building project documentation. Documentation
> > > source files are written in Markdown, and configured with a single YAML
> > > configuration file.
> > > ---
> >
> > No time to look at the submission now, but that text needs to be
> > fixed. A DESCR is a description, not a marketing buzzword collection.
> > Besides, there is a contradiction between "downright gorgeous" and
> > "written in Markdown".
> >
> > Yours,
> > Ingo
> >
DISTNAME is just setting DISTNAME to the same as it's already set to, so
can (should) be removed.
After a bit of head-scratching caused by the 600 file mode on Makefile
("make: don't know how to make do-extract" because _pbuild is unable to
read the Makefile) I was able to build.
"make plist" says the following:
Not found: /usr/local/${MODPY_COMMNENT}lib/python3.6/site-packages/mkdocs (in
/usr/ports/www/mkdocs/pkg/PLIST)
it's an obvious typo, but since the port is python3-only there's no need
for MODPY_COMMENT, you can just remove it. Also "make plist" adds / to the
MODPY_CACHE lines (probably also because it's py3-only) so those should
be added.
update net/toot to 0.18.0
New release coming from stable assets this time. Changes since the last
version:
* Add support for public, tag and list timelines in `toot timeline`
(#52)
* Add `--sensitive` and `--spoiler-text` options to `toot post` (#63)
* Curses app improvements:
* Respect sensitive content, require keypress to show
* Add help modal (press h)
* Misc rendering improvements
Still works fine for me on amd64, tests pass.
OK?
Index: Makefile
===
RCS file: /cvs/ports/net/toot/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- Makefile18 Jan 2018 03:55:48 - 1.2
+++ Makefile12 Jun 2018 11:56:29 -
@@ -2,15 +2,14 @@
COMMENT = interact with Mastodon social networks from the command
line
-MODPY_EGG_VERSION =0.17.1
-GH_ACCOUNT = ihabunek
-GH_PROJECT = toot
-GH_TAGNAME = ${MODPY_EGG_VERSION}
+MODPY_EGG_VERSION =0.18.0
+DISTNAME = toot-${MODPY_EGG_VERSION}
CATEGORIES = net
-MAINTAINER = Klemens Nanni
+MAINTAINER = Klemens Nanni
+MASTER_SITES =
https://github.com/ihabunek/toot/releases/download/${MODPY_EGG_VERSION}/
# GPLv3
PERMIT_PACKAGE_CDROM = Yes
Index: distinfo
===
RCS file: /cvs/ports/net/toot/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- distinfo18 Jan 2018 03:55:48 - 1.2
+++ distinfo12 Jun 2018 11:55:08 -
@@ -1,2 +1,2 @@
-SHA256 (toot-0.17.1.tar.gz) = 698M4ouQ4PlD/b7GsU7M+9vjn6eR35iA5g4rgNGqrxg=
-SIZE (toot-0.17.1.tar.gz) = 34149
+SHA256 (toot-0.18.0.tar.gz) = piiHZMXyUqTxfhGw+9ynqB8Agw61Vw3UI3AzE2FzbhM=
+SIZE (toot-0.18.0.tar.gz) = 35588
Index: pkg/PLIST
===
RCS file: /cvs/ports/net/toot/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -r1.2 PLIST
--- pkg/PLIST 18 Jan 2018 03:55:48 - 1.2
+++ pkg/PLIST 12 Jun 2018 11:55:43 -
@@ -37,7 +37,9 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/toot/ui/${MODPY_PYCACHE}/
lib/python${MODPY_VERSION}/site-packages/toot/ui/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/toot/ui/${MODPY_PYCACHE}app.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/toot/ui/${MODPY_PYCACHE}parsers.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/toot/ui/${MODPY_PYCACHE}utils.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/toot/ui/app.py
+lib/python${MODPY_VERSION}/site-packages/toot/ui/parsers.py
lib/python${MODPY_VERSION}/site-packages/toot/ui/utils.py
lib/python${MODPY_VERSION}/site-packages/toot/utils.py
Re: NEW: graphics/digikam [4/4 digikam 5]
On Tue, Jun 12, 2018 at 07:16:39AM +0200, Rafael Sadowski wrote: > On Sun Jun 10, 2018 at 09:23:52PM -0300, Elias M. Mariani wrote: > > No good. > > Couldn't get digikam to work. > > This one will be hard to crack. > > > > Thanks for the feedback. > > I run in the same trap. This is new, I'm trying to fix it, I need to > fix it. I need digikam back. If this is new, this is likely to be some kind of buffer overflow that retguard exposes.
UPDATE: Nextcloud-13.0.4
Hallo,
Small update for Nextcloud to 13.0.4:
https://nextcloud.com/changelog/
OK? Comments?
Cheers.-
--
Sending from my toaster.
Index: Makefile
===
RCS file: /cvs/ports/www/nextcloud/Makefile,v
retrieving revision 1.17
diff -u -p -r1.17 Makefile
--- Makefile8 Jun 2018 14:46:21 - 1.17
+++ Makefile12 Jun 2018 06:16:47 -
@@ -2,7 +2,7 @@
COMMENT= easy and universal access to shared and/or personal
files
-V= 13.0.3
+V= 13.0.4
DISTNAME= nextcloud-${V}
EXTRACT_SUFX= .tar.bz2
Index: distinfo
===
RCS file: /cvs/ports/www/nextcloud/distinfo,v
retrieving revision 1.11
diff -u -p -r1.11 distinfo
--- distinfo8 Jun 2018 14:46:21 - 1.11
+++ distinfo12 Jun 2018 06:16:47 -
@@ -1,2 +1,2 @@
-SHA256 (nextcloud-13.0.3.tar.bz2) =
GDZnVAgA3QRepXgB/t+MooDegrkVgkEqrQfULtcek+Q=
-SIZE (nextcloud-13.0.3.tar.bz2) = 45128672
+SHA256 (nextcloud-13.0.4.tar.bz2) =
GNUUFF/N3Ib0jQpfpKDUsHYXE1obIxBxN6bqPtUZvVQ=
+SIZE (nextcloud-13.0.4.tar.bz2) = 45150220
