NEW: editors/qownnotes
Hi, Attached is a port of qownnotes-23.9.4. an open source notepad with markdown support and todo list manager, which works together with nextcloud notes. OK to import? qownnotes.tar.gz Description: application/tar-gz
update of py-click 8.0.4 -> 8.1.7
All reverse deps built ok, including py-elasticsearch-curator which no
longer seems to have a restriction on click 8.1.x.
ok?
Index: Makefile
===
RCS file: /cvs/ports/devel/py-click/Makefile,v
retrieving revision 1.19
diff -u -p -u -r1.19 Makefile
--- Makefile15 Nov 2022 00:23:22 - 1.19
+++ Makefile19 Sep 2023 23:50:50 -
@@ -1,9 +1,6 @@
COMMENT= command line library for Python
-# a few deprecated things are removed in 8.1 so holding off on that
-# for now; other software (especially py-elasticsearch-curator) is
-# quite restrictive about click versions
-MODPY_EGG_VERSION= 8.0.4
+MODPY_EGG_VERSION= 8.1.7
DISTNAME= click-${MODPY_EGG_VERSION}
PKGNAME= py-click-${MODPY_EGG_VERSION}
Index: distinfo
===
RCS file: /cvs/ports/devel/py-click/distinfo,v
retrieving revision 1.5
diff -u -p -u -r1.5 distinfo
--- distinfo15 Nov 2022 00:23:22 - 1.5
+++ distinfo19 Sep 2023 23:50:50 -
@@ -1,2 +1,2 @@
-SHA256 (click-8.0.4.tar.gz) = hFjXsSh8X7EoyQ4jOBz5nc3nS+r2x/9jhM6E1v4JCts=
-SIZE (click-8.0.4.tar.gz) = 329520
+SHA256 (click-8.1.7.tar.gz) = yphTrUWeeH4hkiEVeMyQfnWU4pTHzMg0MQcitBucpt4=
+SIZE (click-8.1.7.tar.gz) = 336121
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/py-click/pkg/PLIST,v
retrieving revision 1.6
diff -u -p -u -r1.6 PLIST
--- pkg/PLIST 15 Nov 2022 00:23:22 - 1.6
+++ pkg/PLIST 19 Sep 2023 23:50:50 -
@@ -16,8 +16,6 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/click/${MODPY_PYCACHE}_termui_impl.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/click/${MODPY_PYCACHE}_textwrap.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/click/${MODPY_PYCACHE}_textwrap.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/click/${MODPY_PYCACHE}_unicodefun.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
-lib/python${MODPY_VERSION}/site-packages/click/${MODPY_PYCACHE}_unicodefun.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/click/${MODPY_PYCACHE}_winconsole.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/click/${MODPY_PYCACHE}_winconsole.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/click/${MODPY_PYCACHE}core.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
@@ -45,7 +43,6 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/click/_compat.py
lib/python${MODPY_VERSION}/site-packages/click/_termui_impl.py
lib/python${MODPY_VERSION}/site-packages/click/_textwrap.py
-lib/python${MODPY_VERSION}/site-packages/click/_unicodefun.py
lib/python${MODPY_VERSION}/site-packages/click/_winconsole.py
lib/python${MODPY_VERSION}/site-packages/click/core.py
lib/python${MODPY_VERSION}/site-packages/click/decorators.py
[Maintainer Update] lang/node v18.18.0
* Updates lang/node to the latest revision of the LTS release branch.
* Use SITES
Node dropped the node-gyp binary in this release, which has been deprecated for
a while. As far as I can tell, the only port that's actually building a node
extension is lang/node itself, so this shouldn't cause any fallout.
www/mozilla-firefox, devel/swig and devel/yarn still build and run. I gave up on
www/chromium half-way through the build, but honestly see no reason why it
should
break either.
Built and tested on amd64 and arm64.
ok?Index: Makefile
===
RCS file: /cvs/ports/lang/node/Makefile,v
retrieving revision 1.126
diff -u -p -r1.126 Makefile
--- Makefile 15 Aug 2023 13:46:30 - 1.126
+++ Makefile 19 Sep 2023 21:03:48 -
@@ -5,17 +5,17 @@ USE_WXNEEDED = Yes
COMMENT = JavaScript runtime built on Chrome's V8 JavaScript engine
-NODE_VERSION = v18.17.1
+NODE_VERSION = v18.18.0
PLEDGE_VER = 1.1.3
-DISTFILES = node-pledge-{}${PLEDGE_VER}.tar.gz:0 \
- ${DISTNAME}-headers.tar.gz \
+DISTFILES = ${DISTNAME}-headers.tar.gz \
${DISTNAME}.tar.xz
+DISTFILES.pledge = node-pledge-{}${PLEDGE_VER}.tar.gz
DISTNAME = node-${NODE_VERSION}
PKGNAME = ${DISTNAME:S/v//g}
EPOCH = 0
-MASTER_SITES0 = https://github.com/qbit/node-pledge/archive/
+SITES.pledge = https://github.com/qbit/node-pledge/archive/
CATEGORIES = lang devel
@@ -98,8 +98,6 @@ post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/node
${INSTALL_DATA} ${FULLDISTDIR}/${DISTNAME}-headers.tar.gz \
${PREFIX}/share/node/${DISTNAME}-headers.tar.gz
- ln -fs ${TRUEPREFIX}/lib/node_modules/npm/bin/node-gyp-bin/node-gyp \
- ${PREFIX}/bin/node-gyp;
rm -r ${PREFIX}/lib/node_modules/npm/node_modules/node-pledge/build/node_gyp_bins
cd ${PREFIX}/lib/node_modules/npm/node_modules && for x in *; do \
mv $$x ../..; \
Index: distinfo
===
RCS file: /cvs/ports/lang/node/distinfo,v
retrieving revision 1.71
diff -u -p -r1.71 distinfo
--- distinfo 15 Aug 2023 13:46:31 - 1.71
+++ distinfo 19 Sep 2023 21:03:48 -
@@ -1,6 +1,6 @@
SHA256 (node-pledge-1.1.3.tar.gz) = fEaXvLg6hYEJ69K+mgQFizf8DiJY2/DtyFJB/pEanVU=
-SHA256 (node-v18.17.1-headers.tar.gz) = BO5D9bJyADec9TH5VNTeKJtIcMNhYcSNQn+nQb4+Z/s=
-SHA256 (node-v18.17.1.tar.xz) = 8hXPA9DwDwesC2dMaBn4BMFULhbxUtoEmAAirsz15lo=
+SHA256 (node-v18.18.0-headers.tar.gz) = 3NwDNUJuPiT44f9p1t3SFyw+Q5bobb9LeiyXPXLeR4U=
+SHA256 (node-v18.18.0.tar.xz) = 5NTbrDY02Z+JLwDbR9p4+YSTwzlYLoqV+y3Vn1z+D5A=
SIZE (node-pledge-1.1.3.tar.gz) = 3167
-SIZE (node-v18.17.1-headers.tar.gz) = 8576937
-SIZE (node-v18.17.1.tar.xz) = 40788836
+SIZE (node-v18.18.0-headers.tar.gz) = 8712286
+SIZE (node-v18.18.0.tar.xz) = 40813264
Index: patches/patch-Makefile
===
RCS file: /cvs/ports/lang/node/patches/patch-Makefile,v
retrieving revision 1.18
diff -u -p -r1.18 patch-Makefile
--- patches/patch-Makefile 4 May 2023 12:25:23 - 1.18
+++ patches/patch-Makefile 19 Sep 2023 21:03:48 -
@@ -16,7 +16,7 @@ Index: Makefile
build-addons: | $(NODE_EXE) test/addons/.buildstamp
+
+build-pledge: $(NODE_EXE)
-+ $(NODE) deps/npm/node_modules/node-gyp/bin/node-gyp rebuild \
++ $(NODE) deps/npm/node_modules/node-gyp/bin/node-gyp.js rebuild \
+ --directory="deps/npm/node_modules/node-pledge" \
+ --nodedir="$(shell pwd)" && \
+ $(RM) -rf deps/npm/node_modules/node-pledge/build/Release/{.deps,../Makefile,obj.target}
Index: patches/patch-common_gypi
===
RCS file: /cvs/ports/lang/node/patches/patch-common_gypi,v
retrieving revision 1.29
diff -u -p -r1.29 patch-common_gypi
--- patches/patch-common_gypi 7 Jul 2023 10:44:15 - 1.29
+++ patches/patch-common_gypi 19 Sep 2023 21:03:48 -
@@ -18,14 +18,14 @@ Index: common.gypi
+, '-Wl,-rpath,${EOPENSSL_LIB}'
+],
}],
- ],
- 'conditions': [
+ ['_toolset=="host"', {
+ 'conditions': [
@@ -426,7 +427,7 @@
- 'ldflags': [ '-m32' ],
- }],
- [ 'target_arch=="ppc64" and OS not in "aix os400"', {
--'cflags': [ '-m64', '-mminimal-toc' ],
-+'cflags': [ '-m64' ],
- 'ldflags': [ '-m64' ],
- }],
- [ 'target_arch=="s390x" and OS=="linux"', {
+ 'ldflags': [ '-m32' ],
+ }],
+ [ 'host_arch=="ppc64" and OS not in "aix os400"', {
+-'cflags': [ '-m64', '-mminimal-toc' ],
++'cflags': [ '-m64' ],
+ 'ldflags': [ '-m64' ],
+ }],
+ [ 'host_arch=="s390x" and OS=="linux"', {
Index: patches/patch-deps_npm_bin_node-gyp-bin_node-gyp
===
RCS file: patches/patch-deps_npm_bin_node-gyp-bin_node-gyp
diff -N patches/patch-deps_n
Re: [Maintainer Update] print/ghostscript/gnu 10.02.0
Not intended as a ping, but updating the diff to use SITES rather than
MASTER_SITES.
On 9/14/23 19:54, Volker Schlecht wrote:
Ghostscript just released version 10.02.0
The major change is the removal of the old PDF interpreter.
The new one has been the default since 10.0.0 and the possibility to
fall back to the old PDF interpreter is gone since 10.01.0.
I'm not aware that this caused any trouble, so I don't expect any
with this final step.
Builds and runs on amd64 and rebuilds as many reverse deps as I could find.
ok?Index: Makefile
===
RCS file: /cvs/ports/print/ghostscript/gnu/Makefile,v
retrieving revision 1.127
diff -u -p -r1.127 Makefile
--- Makefile 23 Jun 2023 15:11:05 - 1.127
+++ Makefile 19 Sep 2023 21:36:12 -
@@ -1,12 +1,12 @@
COMMENT = PostScript and PDF interpreter
-VERSION = 10.01.2
+VERSION = 10.02.0
DISTNAME = ghostscript-${VERSION}
EXTRACT_SUFX = .tar.xz
CATEGORIES = lang print
-SHARED_LIBS = gs 18.0
+SHARED_LIBS = gs 18.1
-MASTER_SITES = https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/download/gs${VERSION:S/.//g}/
+SITES = https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/download/gs${VERSION:S/.//g}/
PORTROACH = site:https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/
Index: distinfo
===
RCS file: /cvs/ports/print/ghostscript/gnu/distinfo,v
retrieving revision 1.22
diff -u -p -r1.22 distinfo
--- distinfo 23 Jun 2023 15:11:05 - 1.22
+++ distinfo 19 Sep 2023 21:36:12 -
@@ -1,2 +1,2 @@
-SHA256 (ghostscript-10.01.2.tar.xz) = SNB5JCosoCouR6dqUs36gYsq12nCurAK0El90TVg5+c=
-SIZE (ghostscript-10.01.2.tar.xz) = 67571808
+SHA256 (ghostscript-10.02.0.tar.xz) = +gjOAWsw0mKT3DIsY1NpGs7ZT9Nmemjt5/9TldcfzQs=
+SIZE (ghostscript-10.02.0.tar.xz) = 67955320
Index: pkg/PLIST
===
RCS file: /cvs/ports/print/ghostscript/gnu/pkg/PLIST,v
retrieving revision 1.35
diff -u -p -r1.35 PLIST
--- pkg/PLIST 12 Apr 2023 15:12:39 - 1.35
+++ pkg/PLIST 19 Sep 2023 21:36:12 -
@@ -57,7 +57,7 @@ share/doc/ghostscript/${VERSION}/
share/doc/ghostscript/${VERSION}/COPYING
share/doc/ghostscript/${VERSION}/GS9_Color_Management.pdf
share/doc/ghostscript/${VERSION}/Ghostscript.pdf
-share/doc/ghostscript/${VERSION}/News.htm
+share/doc/ghostscript/${VERSION}/News.html
share/ghostscript/
share/ghostscript/${VERSION}/
share/ghostscript/${VERSION}/lib/
Re: [wip] devel/{pyside6,pyside6-tools,shiboken6}
On 2023/09/19 22:07, Johannes Thyssen Tishman wrote:
> Hi everyone,
>
> I'm currently working on porting the following three FreeCAD
> dependencies:
>
> PySide6: Python Qt bindings for Qt 6
> PySide6-tools: PySide6 development tools
> Shiboken6: Python binding generator for C++ libraries
>
> Since their sources are provided as a single tarball, I think they
> should be ported as sub-packages of one port with MULTI_PACKAGES.
> However this is the first time I'm trying to use this feature and I'm
> struggling to make it work. I initially made a separate port for each of
> them by adapting ${WRKSRC} so that I could tell their *_DEPENDS,
> WANTLIBs and PLISTs apart. Now that all three ports are finished, I've
> merged them into one and suffixed their specific COMMENT, WANTLIB and
> {LIB,RUN}_DEPENDS accordingly with a sub-package name.
>
> The problem is that the PySide6 (-main) sub-package depends on the
> SHARED_LIBS installed by the Shiboken6 (-shiboken) sub-package, which of
> course is throwing me an error.
I think this maybe because you haven't generated PLISTs with the
libraries included. AFAIK you need to do the build without the
internal deps/wantlib listed first, then generate PLISTs, then you
can add them.
What is more of a problem for the all-in-one approach is that building
some parts requires finding python modules done as part of the shiboken
build, and the way that the build is being run in this port, that
doesn't work, it's not passing in a PYTHONPATH that allows it to find
them.
It seems that the build is intended to be run by their python setup.py
scripts which then call cmake - whereas you're calling cmake directly,
which might be reponsible for this.
Anyway separate ports probably seems like less of a headache to me
for this.
I would probably group them under one dir, x11/pyside6 (not devel/),
with subdirs for the different things and share common parts via
x11/pyside6/Makefile.inc
ports/x11/pyside6/pyside6
ports/x11/pyside6/tools
ports/x11/pyside6/shiboken
> Another issue that I'm having is that the Shiboken6 port installs both
> libraries and a Python module, so I'm not sure if this should be split
> as well. What is the convention in this kind of case?
Not split.
> Lastly, when running 'make port-lib-depends-check' for both Shiboken6
> and PySide6-tools, I'm getting a warning like the following:
>
> > Missing lib: clang.8 (/usr/local/bin/shiboken6) (NOT REACHABLE)
>
> I think this is due to clang being a runtime dependency for this ports.
> I've had a similar issue in the past with another port and, if I
> remember correctly, this was due to the library not being present in
> LIB_DEPENDS. However here I've tried adding devel/llvm/13 to LIB_DEPENDS
> and using the lang/clang module and I'm still getting the error. Any
> idea what could be causing this?
check-lib-depends doesn't properly handle libraries in subdirs.
Re: devel/yarn - still needed?
On Tue Sep 19, 2023 at 9:38 PM CEST, Stuart Henderson wrote: > On 2023/09/19 13:13, Aaron Bieber wrote: > > On 9/19/23 13:10, Stuart Henderson wrote: > > > On 2023/09/19 21:00, Volker Schlecht wrote: > > > > Cc: abieber@ > > > > > > > > I just came across our port of devel/yarn, which appears to be both very > > > > old and by now, very underutilized. > > Doesn't seem all that old? 2022 and only one version behind the > latest on https://github.com/yarnpkg/yarn/releases/ Without wanting to imply anything: Yarn 1.x has been in maintenance mode since January 2020 and will eventually stop being supported if it hasn't happened already: "This repository holds the sources for Yarn 1.x (latest version at the time of this writing being 1.22). New releases (at this time the 3.2.3, although we're currently working on our next major) are tracked on the yarnpkg/berry repository, this one here being mostly kept for historical purposes and the occasional hotfix we publish to make the migration from 1.x to later releases easier." https://github.com/yarnpkg/yarn
[wip] devel/{pyside6,pyside6-tools,shiboken6}
Hi everyone,
I'm currently working on porting the following three FreeCAD
dependencies:
PySide6: Python Qt bindings for Qt 6
PySide6-tools: PySide6 development tools
Shiboken6: Python binding generator for C++ libraries
Since their sources are provided as a single tarball, I think they
should be ported as sub-packages of one port with MULTI_PACKAGES.
However this is the first time I'm trying to use this feature and I'm
struggling to make it work. I initially made a separate port for each of
them by adapting ${WRKSRC} so that I could tell their *_DEPENDS,
WANTLIBs and PLISTs apart. Now that all three ports are finished, I've
merged them into one and suffixed their specific COMMENT, WANTLIB and
{LIB,RUN}_DEPENDS accordingly with a sub-package name.
The problem is that the PySide6 (-main) sub-package depends on the
SHARED_LIBS installed by the Shiboken6 (-shiboken) sub-package, which of
course is throwing me an error. I know that library interdependencies
between sub-packages are possible since bsd.port.mk(5) mentions the
following:
> ... any LIB_DEPENDS-sub that references the current port will be
> ignored as a build dependency, in order to avoid recursion. ...
So how can I make this work? Is it possible to have a sub-package depend
on another sub-package SHARED_LIBS? FreeBSD has separate ports for each
of these dependencies[1][2][3], but for example the Arch Linux port
seems to be only one with multiple packages[4].
Another issue that I'm having is that the Shiboken6 port installs both
libraries and a Python module, so I'm not sure if this should be split
as well. What is the convention in this kind of case?
Lastly, when running 'make port-lib-depends-check' for both Shiboken6
and PySide6-tools, I'm getting a warning like the following:
> Missing lib: clang.8 (/usr/local/bin/shiboken6) (NOT REACHABLE)
I think this is due to clang being a runtime dependency for this ports.
I've had a similar issue in the past with another port and, if I
remember correctly, this was due to the library not being present in
LIB_DEPENDS. However here I've tried adding devel/llvm/13 to LIB_DEPENDS
and using the lang/clang module and I'm still getting the error. Any
idea what could be causing this?
Apologies in advance for the many questions. I've attached both the
combined port and the individual ones in case anyone wants to check them
out. I'd be very grateful for any guidance or feedback anyone could
provide.
Thank you.
Kind regards,
Johannes Thyssen Tishman
[1] https://github.com/freebsd/freebsd-ports/tree/main/devel/pyside6
[2] https://github.com/freebsd/freebsd-ports/tree/main/devel/pyside6-tools
[3] https://github.com/freebsd/freebsd-ports/tree/main/devel/shiboken6
[4]
https://gitlab.archlinux.org/archlinux/packaging/packages/pyside6/-/blob/main/PKGBUILD?ref_type=heads
individual.tar.gz
Description: GNU Zip compressed data
combined.tar.gz
Description: GNU Zip compressed data
Re: devel/yarn - still needed?
On Tue Sep 19, 2023 at 9:05 PM CEST, Aaron Bieber wrote: > On 9/19/23 13:00, Volker Schlecht wrote: > > Cc: abieber@ > > > > I just came across our port of devel/yarn, which appears to be both very > > old and by now, very underutilized. > > > > The last discussions about yarn that I saw on the list were about WIP > > efforts to port VSCode, to which an ancient devel/yarn doesn't seem to > > be the key either. > > > > Any reason to still keep it around? > > Probably not. The MainReason™ for the port was to give people a working > yarn. Out of the box > it doesn't know the path to `node`. With no regard to my: Is that still a problem since we fixed that with a metaphoric hammer? https://github.com/openbsd/ports/blob/master/lang/node/patches/patch-src_env_cc
Re: devel/yarn - still needed?
On 2023/09/19 13:13, Aaron Bieber wrote:
> On 9/19/23 13:10, Stuart Henderson wrote:
> > On 2023/09/19 21:00, Volker Schlecht wrote:
> > > Cc: abieber@
> > >
> > > I just came across our port of devel/yarn, which appears to be both very
> > > old and by now, very underutilized.
Doesn't seem all that old? 2022 and only one version behind the
latest on https://github.com/yarnpkg/yarn/releases/
> > > The last discussions about yarn that I saw on the list were about WIP
> > > efforts to port VSCode, to which an ancient devel/yarn doesn't seem to
> > > be the key either.
> > >
> > > Any reason to still keep it around?
> > >
> > security/vault/Makefile:
> >
> > : # UI prebuilt with: cd ui; yarn install; npm rebuild node-sass; yarn run
> > build
> > : DISTNAME= vault-vendored-${VERSION}
> > : PKGNAME=vault-${VERSION}
> > :
> > : ### Vault UI
> > : MODGO_FLAGS=-tags=ui
> > : MASTER_SITES= https://distfiles.tristero.se/
> >
>
> Wonder if it would make sense to add devel/yarn as a build dep for cases
> like this?
>
I don't think so - it's not used during build, only to prepare updates
(and that would restrict the archs on whih vault can be built; node's
ONLY_FOR_ARCHS is shorter than vault's).
Re: devel/yarn - still needed?
On Tue Sep 19, 2023 at 9:10 PM CEST, Stuart Henderson wrote:
> security/vault/Makefile:
>
> : # UI prebuilt with: cd ui; yarn install; npm rebuild node-sass; yarn run
> build
> : DISTNAME= vault-vendored-${VERSION}
> : PKGNAME=vault-${VERSION}
> :
> : ### Vault UI
> : MODGO_FLAGS=-tags=ui
> : MASTER_SITES= https://distfiles.tristero.se/
Ack, I was only looking for direct dependencies.
Re: devel/yarn - still needed?
On 9/19/23 13:10, Stuart Henderson wrote:
On 2023/09/19 21:00, Volker Schlecht wrote:
Cc: abieber@
I just came across our port of devel/yarn, which appears to be both very
old and by now, very underutilized.
The last discussions about yarn that I saw on the list were about WIP
efforts to port VSCode, to which an ancient devel/yarn doesn't seem to
be the key either.
Any reason to still keep it around?
security/vault/Makefile:
: # UI prebuilt with: cd ui; yarn install; npm rebuild node-sass; yarn run build
: DISTNAME= vault-vendored-${VERSION}
: PKGNAME=vault-${VERSION}
:
: ### Vault UI
: MODGO_FLAGS=-tags=ui
: MASTER_SITES= https://distfiles.tristero.se/
Wonder if it would make sense to add devel/yarn as a build dep for cases
like this?
Re: devel/yarn - still needed?
On 2023/09/19 21:00, Volker Schlecht wrote:
> Cc: abieber@
>
> I just came across our port of devel/yarn, which appears to be both very
> old and by now, very underutilized.
>
> The last discussions about yarn that I saw on the list were about WIP
> efforts to port VSCode, to which an ancient devel/yarn doesn't seem to
> be the key either.
>
> Any reason to still keep it around?
>
security/vault/Makefile:
: # UI prebuilt with: cd ui; yarn install; npm rebuild node-sass; yarn run build
: DISTNAME= vault-vendored-${VERSION}
: PKGNAME=vault-${VERSION}
:
: ### Vault UI
: MODGO_FLAGS=-tags=ui
: MASTER_SITES= https://distfiles.tristero.se/
Re: devel/yarn - still needed?
On 9/19/23 13:00, Volker Schlecht wrote: Cc: abieber@ I just came across our port of devel/yarn, which appears to be both very old and by now, very underutilized. The last discussions about yarn that I saw on the list were about WIP efforts to port VSCode, to which an ancient devel/yarn doesn't seem to be the key either. Any reason to still keep it around? Probably not. The MainReason™ for the port was to give people a working yarn. Out of the box it doesn't know the path to `node`.
devel/yarn - still needed?
Cc: abieber@ I just came across our port of devel/yarn, which appears to be both very old and by now, very underutilized. The last discussions about yarn that I saw on the list were about WIP efforts to port VSCode, to which an ancient devel/yarn doesn't seem to be the key either. Any reason to still keep it around?
Re: cad/kicad status
On September 19, 2023 9:01:51 AM MDT, Marc Espie wrote: >On Tue, Sep 19, 2023 at 04:58:31PM +0200, Marc Espie wrote: >> I don't know who's interested in that port, but the main archive from >> the site doesn't match at all what we have in the backups. For starters, >> our archive is 45MB long, whereas the main site retrieves a file that's 322MB >> long (!) >> >> This does take more or less forever to fetch to fall on its nose, basically, >> and should most probably get looked at! > >(I should also mention we're off by 7 months and a major release, >6.0.11 to 7.0.7) > I have a WIP for the 7 conversion, but have had no time to fully pursue it. -- Tracey Emery Sent from my phone.
Re: cad/kicad status
On Tue, Sep 19, 2023 at 04:58:31PM +0200, Marc Espie wrote: > I don't know who's interested in that port, but the main archive from > the site doesn't match at all what we have in the backups. For starters, > our archive is 45MB long, whereas the main site retrieves a file that's 322MB > long (!) > > This does take more or less forever to fetch to fall on its nose, basically, > and should most probably get looked at! (I should also mention we're off by 7 months and a major release, 6.0.11 to 7.0.7)
cad/kicad status
I don't know who's interested in that port, but the main archive from the site doesn't match at all what we have in the backups. For starters, our archive is 45MB long, whereas the main site retrieves a file that's 322MB long (!) This does take more or less forever to fetch to fall on its nose, basically, and should most probably get looked at!
Re: update lang/fennel; move man pages to a -docs subpackage
Hi Omar, Omar Polo wrote on Tue, Sep 19, 2023 at 02:30:08PM +0200: > I have to note that one could end up installing only the -docs > package, is it a concern? If a user explicitely says "pkg_add fennel-docs" without saying "pkg_add fennel", sure, they only get the documentation installed. But that's what they asked for, so i don't see a problem there. Occasionally, it might even be useful, for example when a user on a very slow network connection wants to look at the documentation before deciding whether they really want to download the code (and the other dependencies like lua). Maybe not the usual case - when you want to study documentation, you usually also want to play around a bit with the program - but clearly not harmful. It certainly won't be the only package containing documentation only and no code. Consider, for example, books/man-pages-posix. Yours, Ingo
update net/libstrophe and profanity
This is a late update to libstrophe and profanity.
https://github.com/strophe/libstrophe/releases/tag/0.12.3
https://github.com/profanity-im/profanity/releases/tag/0.14.0
portwise is not particular interesting, but some further testing is
not bad since I think I only use 1% of the features or so :-)
I plan to commit this next week unless issues arise.
Thanks,
Index: net/libstrophe/Makefile
===
RCS file: /home/cvs/ports/net/libstrophe/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- net/libstrophe/Makefile 9 Aug 2022 08:17:02 - 1.10
+++ net/libstrophe/Makefile 19 Sep 2023 09:54:02 -
@@ -1,6 +1,6 @@
COMMENT = simple, lightweight XMPP C library
-V =0.12.2
+V =0.12.3
DISTNAME = libstrophe-${V}
SHARED_LIBS = strophe 4.0 # 12.1
Index: net/libstrophe/distinfo
===
RCS file: /home/cvs/ports/net/libstrophe/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- net/libstrophe/distinfo 9 Aug 2022 08:17:02 - 1.7
+++ net/libstrophe/distinfo 19 Sep 2023 09:54:06 -
@@ -1,2 +1,2 @@
-SHA256 (libstrophe-0.12.2.tar.gz) =
re3KHP/2oXCVqqfifuz/LNPWCAh/Vf4ek5WmqxqJN0A=
-SIZE (libstrophe-0.12.2.tar.gz) = 581031
+SHA256 (libstrophe-0.12.3.tar.gz) =
dZ+bvv8go5LIP66BRFXNm82q6BJWspAW93fLwHDYlEU=
+SIZE (libstrophe-0.12.3.tar.gz) = 579381
Index: net/profanity/Makefile
===
RCS file: /home/cvs/ports/net/profanity/Makefile,v
retrieving revision 1.29
diff -u -p -r1.29 Makefile
--- net/profanity/Makefile 13 Nov 2022 15:28:49 - 1.29
+++ net/profanity/Makefile 19 Sep 2023 12:38:44 -
@@ -1,7 +1,6 @@
COMMENT = console based XMPP client
-DISTNAME = profanity-0.13.1
+DISTNAME = profanity-0.14.0
CATEGORIES = net
-REVISION = 1
HOMEPAGE = https://profanity-im.github.io/
@@ -16,9 +15,9 @@ MASTER_SITES =https://profanity-im.gith
WANTLIB += assuan c crypto curl curses ereadline expat ffi gcrypt
WANTLIB += gio-2.0 glib-2.0 gmodule-2.0 gobject-2.0 gpg-error
-WANTLIB += gpgme iconv intl m nghttp2 otr pcre2-8 pthread ${MODPY_WANTLIB}
-WANTLIB += qrencode signal-protocol-c sqlite3 ssl strophe util
-WANTLIB += z
+WANTLIB += gpgme iconv intl m nghttp2 nghttp3 ngtcp2 ngtcp2_crypto_openssl
+WANTLIB += otr pcre2-8 pthread python3.10 qrencode signal-protocol-c
+WANTLIB += sqlite3 ssl strophe util z
MODULES += lang/python
Index: net/profanity/distinfo
===
RCS file: /home/cvs/ports/net/profanity/distinfo,v
retrieving revision 1.16
diff -u -p -r1.16 distinfo
--- net/profanity/distinfo 13 Oct 2022 07:19:27 - 1.16
+++ net/profanity/distinfo 19 Sep 2023 12:33:27 -
@@ -1,2 +1,2 @@
-SHA256 (profanity-0.13.1.tar.gz) = K1B1Jy5+ydnJkVQuWSsdR0//iMYcZufiMJatMG7SyEo=
-SIZE (profanity-0.13.1.tar.gz) = 903811
+SHA256 (profanity-0.14.0.tar.gz) = /SP/04oxkHl0poCjkAyVnhTUThbx+33yvbf2xnvXz38=
+SIZE (profanity-0.14.0.tar.gz) = 936272
Index: net/profanity/pkg/PLIST
===
RCS file: /home/cvs/ports/net/profanity/pkg/PLIST,v
retrieving revision 1.11
diff -u -p -r1.11 PLIST
--- net/profanity/pkg/PLIST 13 Oct 2022 07:19:28 - 1.11
+++ net/profanity/pkg/PLIST 19 Sep 2023 12:35:22 -
@@ -56,7 +56,6 @@ lib/libprofanity.la
@man man/man1/profanity-notify.1
@man man/man1/profanity-occupants.1
@man man/man1/profanity-omemo.1
-@man man/man1/profanity-os.1
@man man/man1/profanity-otr.1
@man man/man1/profanity-outtype.1
@man man/man1/profanity-ox-setup.1
@@ -68,6 +67,7 @@ lib/libprofanity.la
@man man/man1/profanity-prefs.1
@man man/man1/profanity-presence.1
@man man/man1/profanity-priority.1
+@man man/man1/profanity-privacy.1
@man man/man1/profanity-privileges.1
@man man/man1/profanity-quit.1
@man man/man1/profanity-receipts.1
@@ -91,6 +91,7 @@ lib/libprofanity.la
@man man/man1/profanity-states.1
@man man/man1/profanity-status.1
@man man/man1/profanity-statusbar.1
+@man man/man1/profanity-strophe.1
@man man/man1/profanity-sub.1
@man man/man1/profanity-subject.1
@man man/man1/profanity-theme.1
@@ -99,6 +100,7 @@ lib/libprofanity.la
@man man/man1/profanity-tls.1
@man man/man1/profanity-tray.1
@man man/man1/profanity-url.1
+@man man/man1/profanity-vcard.1
@man man/man1/profanity-vercheck.1
@man man/man1/profanity-who.1
@man man/man1/profanity-win.1
Re: [new port] productivity/topydo
Am Tue, Sep 19, 2023 at 02:28:35PM +0100 schrieb Stuart Henderson:
> On 2023/09/19 13:45, Martin Ziemer wrote:
> > This tarball contains a port of topydo, a todo.txt implementation in
> > python.
> >
> > Tested all three modes (cli, prompt and columns).
> >
> > Use it on my daily driver with no problems.
>
> couple of tweaks, then it's OK sthen@
Just tested the new tar and everything works as expected.
>
> : --- Makefile.orig Tue Sep 19 12:23:20 2023
> : +++ MakefileTue Sep 19 14:20:36 2023
> : @@ -4,7 +4,6 @@ MODPY_EGG_VERSION= 0.14
> : GH_ACCOUNT=topydo
> : GH_PROJECT=topydo
> : GH_TAGNAME=${MODPY_EGG_VERSION}
> : -PKGNAME= topydo-${MODPY_EGG_VERSION}
>
> the default set by GH_* is good enough
>
> : CATEGORIES=productivity
> :
> : HOMEPAGE= https://topydo.org/
> : @@ -14,13 +13,13 @@ MAINTAINER= Martin Ziemer
> : # GPLv3
> : PERMIT_PACKAGE=Yes
> :
> : -TEST_DEPENDS = devel/py-freezegun${MODPY_FLAVOR}
> : +TEST_DEPENDS = devel/py-freezegun${MODPY_FLAVOR}
>
> various whitespace nits
>
> : -RUN_DEPENDS = devel/py-arrow${MODPY_FLAVOR} \
> : - devel/py-urwid${MODPY_FLAVOR} \
> : - sysutils/py-watchdog${MODPY_FLAVOR} \
> : - devel/py-icalendar${MODPY_FLAVOR} \
> : - devel/py-prompt_toolkit${MODPY_FLAVOR}
> : +RUN_DEPENDS = devel/py-arrow${MODPY_FLAVOR} \
> : + devel/py-urwid${MODPY_FLAVOR} \
> : + sysutils/py-watchdog${MODPY_FLAVOR} \
> : + devel/py-icalendar${MODPY_FLAVOR} \
> : + devel/py-prompt_toolkit${MODPY_FLAVOR}
> :
> : MODULES= lang/python
> : MODPY_PYBUILD= setuptools
Re: [new port] productivity/topydo
On 2023/09/19 13:45, Martin Ziemer wrote:
> This tarball contains a port of topydo, a todo.txt implementation in
> python.
>
> Tested all three modes (cli, prompt and columns).
>
> Use it on my daily driver with no problems.
couple of tweaks, then it's OK sthen@
: --- Makefile.orig Tue Sep 19 12:23:20 2023
: +++ Makefile Tue Sep 19 14:20:36 2023
: @@ -4,7 +4,6 @@ MODPY_EGG_VERSION=0.14
: GH_ACCOUNT= topydo
: GH_PROJECT= topydo
: GH_TAGNAME= ${MODPY_EGG_VERSION}
: -PKGNAME= topydo-${MODPY_EGG_VERSION}
the default set by GH_* is good enough
: CATEGORIES= productivity
:
: HOMEPAGE=https://topydo.org/
: @@ -14,13 +13,13 @@ MAINTAINER= Martin Ziemer
: # GPLv3
: PERMIT_PACKAGE= Yes
:
: -TEST_DEPENDS = devel/py-freezegun${MODPY_FLAVOR}
: +TEST_DEPENDS = devel/py-freezegun${MODPY_FLAVOR}
various whitespace nits
: -RUN_DEPENDS =devel/py-arrow${MODPY_FLAVOR} \
: - devel/py-urwid${MODPY_FLAVOR} \
: - sysutils/py-watchdog${MODPY_FLAVOR} \
: - devel/py-icalendar${MODPY_FLAVOR} \
: - devel/py-prompt_toolkit${MODPY_FLAVOR}
: +RUN_DEPENDS =devel/py-arrow${MODPY_FLAVOR} \
: + devel/py-urwid${MODPY_FLAVOR} \
: + sysutils/py-watchdog${MODPY_FLAVOR} \
: + devel/py-icalendar${MODPY_FLAVOR} \
: + devel/py-prompt_toolkit${MODPY_FLAVOR}
:
: MODULES= lang/python
: MODPY_PYBUILD= setuptools
:
topydo.tgz
Description: application/tar-gz
Re: update lang/fennel; move man pages to a -docs subpackage
On 2023/09/19 12:38:52 +0100, Stuart Henderson wrote:
> On 2023/09/19 11:32, Ingo Schwarze wrote:
> > Hi Omar,
> >
> > Omar Polo wrote on Tue, Sep 19, 2023 at 10:10:44AM +0200:
> >
> > > However, I disliked to ship the same set of man pages four times, so
> > > here's an attempt to move them to a -docs subpackage. (thanks sthen@
> > > for pointing me at www/squid)
> >
> > I wouldn't consider saving the diskspace for three manual pages the
> > main benefit, even though that hardly hurts, either. It seems more
> > important that your approach of making a subpackage prevents apropos(1)
> > from listing multiple pages and making the user wonder whether they
> > differ, possibly wasting their time running diff(1).
> >
> > This is even likely to become worse in the near future when man(1)
> > starts warning that there are multiple manual pages of the same name
> > in the same section.
> >
> > However, *if* you expect that the pages are likely to actually
> > become different in the future, that might be a reason against
> > making this subpackage. Then again, if that happens, it would
> > also be an option to merge them back in after it happens.
>
> They won't; the different flavours are merely building with different
> versions of lua, the manuals are unaffected.
Currently they don't change and I don't expect them to change in the
future.
> > > Note that RUN_DEPENDS-docs is needed otherwise (via lua.port.mk and
> > > global RUN_DEPENDS) it ends up depending on lang/lua,${FLAVOR} and
> > > that will break subsequent build (the plist register the deps on one
> > > flavor, when building the next one the plist would differ)
> >
> > Again, i don't think these technical considerations are the only
> > reason for RUN_DEPENDS-docs. I general, i stongly feel that if
> > you say "pkg_add food", that should absolutely install all the
> > documentation for the "foo" daemon. I mean, how is the user
> > supposed to use it if there is no documentation? We want sane
> > defaults, and installing software without documentation is not
> > exactly sane. Why should we send the user on a wild goose chase
> > to search for a "foo" documentation package after they alraedy
> > said they want food?
> >
> > I certainly don't want to emulate the bad habit of some Linux
> > distros to not install documentation unless the user goes an extra
> > mile specifically asking for it.
Completely agree.
> Explicitly setting RUN_DEPENDS-docs to makes sense,
> but I think we should also have "RUN_DEPENDS-main += lang/fennel,-docs".
There is already a RUN_DEPENDS-main += lang/fennel,-docs, so nevermind
which flavor(s) you install the -docs subpackage will always be
installed as dependency.
It was at the top together with the FULLPKGNAME/PATH bits, so easy to
miss. I've moved it in a more usual position near the end.
I have to note that one could end up installing only the -docs
package, is it a concern?
> Otherwise the ports aspects look correct to me.
>
> > > However, I'm not sure I'm overthinking it and just rename the three
> > > new manpages to fennel-${V}-XYZ instead of doing a subpackage would be
> > > preferred.
> >
> > I did not audit this ports-wise, but i do like your general idea.
> > It doesn't feel like overengineering to me, there appear to be actual
> > benefits from the user perspective.
>
> Agreed.
>
> > > +SITES = https://git.sr.ht/~technomancy/fennel/archive/
>
> btw, I think this could probably change to DIST_TUPLES if wanted.
right, while we're here it also further semplifies the makefile.
Ingo, Sthen, thanks!
Index: Makefile
===
RCS file: /home/cvs/ports/lang/fennel/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- Makefile26 Dec 2022 11:05:59 - 1.2
+++ Makefile19 Sep 2023 12:17:07 -
@@ -1,8 +1,14 @@
-COMMENT = Lisp dialect that runs on Lua ${MODLUA_VERSION}
+COMMENT-main = Lisp dialect that runs on Lua ${MODLUA_VERSION}
+COMMENT-docs = Documentation for fennel
-V =1.2.1
-PKGNAME = fennel-$V
-FULLPKGNAME = fennel-${FLAVOR}-${V}
+V =1.3.1
+DIST_TUPLE = srht technomancy fennel $V .
+FULLPKGPATH-main = lang/fennel,-main,${FLAVOR}
+FULLPKGNAME-main = fennel-${FLAVOR}-${V}
+
+# -docs isn't flavoured, so overwrite its default name/path
+FULLPKGNAME-docs = fennel-docs-$V
+FULLPKGPATH-docs = ${PKGPATH},-docs
CATEGORIES = lang
@@ -13,9 +19,7 @@ MAINTAINER = Omar Polo
# MIT
PERMIT_PACKAGE = Yes
-MASTER_SITES = https://git.sr.ht/~technomancy/fennel/archive/
-
-DISTFILES =fennel-{}$V${EXTRACT_SUFX}
+MULTI_PACKAGES = -main -docs
MODULES = lang/lua
@@ -29,13 +33,14 @@ ALL_TARGET =build
MAKE_FLAGS += LUA=${MODLUA_BIN} \
LUA_VERSION=${MODLUA_VERSION} \
LUA_LIB_DIR=${MODLUA_LIBDIR}
-FAKE_FLAGS += PREFIX=${TRUEPREFIX}
+FAKE_FLAGS += PREFIX=${TRUEPREFIX} \
+
UPDATE: net/nextcloudclient-3.10.0
Hi.
Update for net/nextcloudclient v3.10.0
Changelog:
3.10.0 https://github.com/nextcloud/desktop/releases/v3.10.0
3.9.4 https://github.com/nextcloud/desktop/releases/v3.9.4
Obrigado!
--
Adriano
Index: Makefile
===
RCS file: /cvs/ports/net/nextcloudclient/Makefile,v
retrieving revision 1.54
diff -u -p -r1.54 Makefile
--- Makefile24 Aug 2023 06:16:21 - 1.54
+++ Makefile19 Sep 2023 12:03:39 -
@@ -2,7 +2,7 @@ USE_WXNEEDED = Yes
COMMENT = desktop sync client for Nextcloud
-V =3.9.3
+V =3.10.0
DISTNAME = nextcloudclient-${V}
GH_ACCOUNT = nextcloud
@@ -13,8 +13,8 @@ CATEGORIES = net
HOMEPAGE = https://nextcloud.com
-SHARED_LIBS += nextcloudsync 12.0 # 3.9.1
-SHARED_LIBS += nextcloud_csync 6.0 # 3.9.1
+SHARED_LIBS += nextcloudsync 13.0 # 3.10.0
+SHARED_LIBS += nextcloud_csync 6.1 # 3.10.0
SHARED_LIBS += nextcloudsync_vfs_suffix 1.0 # 3.9.0
MAINTAINER = Adriano Barbosa
Index: distinfo
===
RCS file: /cvs/ports/net/nextcloudclient/distinfo,v
retrieving revision 1.43
diff -u -p -r1.43 distinfo
--- distinfo24 Aug 2023 06:16:21 - 1.43
+++ distinfo19 Sep 2023 12:03:39 -
@@ -1,2 +1,2 @@
-SHA256 (nextcloudclient-3.9.3.tar.gz) =
QCdaKUC/vQDXS/7L3nua8gCZhQ3RZIB5L1NSr6f7U/o=
-SIZE (nextcloudclient-3.9.3.tar.gz) = 15752014
+SHA256 (nextcloudclient-3.10.0.tar.gz) =
CLoDQISahTcbEKT2kEmiXs8pBIUiGAuZqRSnCX7FA0k=
+SIZE (nextcloudclient-3.10.0.tar.gz) = 13529232
Re: [PATCH] Update devel/objfw to 1.0.3
On Thu, Sep 14 2023, Jonathan Schleifer wrote: > Patch attached this time to be 100% sure my MUA doesn't screw it up. Committed, thanks. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
[new port] productivity/topydo
This tarball contains a port of topydo, a todo.txt implementation in python. Tested all three modes (cli, prompt and columns). Use it on my daily driver with no problems. topydo.tgz Description: application/tar-gz
Re: update lang/fennel; move man pages to a -docs subpackage
On 2023/09/19 11:32, Ingo Schwarze wrote:
> Hi Omar,
>
> Omar Polo wrote on Tue, Sep 19, 2023 at 10:10:44AM +0200:
>
> > The update itself is straightforward and all tests are passing.
> > However, upstream added three more man pages (for a total of four now)
> > which would get shipped in all of four fennel flavors (lua5[1-3]).
> >
> > Now, this is practice works, i.e. even if you have installed all the
> > flavors `man fennel-api' works and since all the manpages are
> > identical it's not really important if mandoc chooses fennel-5.1-api
> > or fennel-5.4-api.
> >
> > However, I disliked to ship the same set of man pages four times, so
> > here's an attempt to move them to a -docs subpackage. (thanks sthen@
> > for pointing me at www/squid)
>
> I wouldn't consider saving the diskspace for three manual pages the
> main benefit, even though that hardly hurts, either. It seems more
> important that your approach of making a subpackage prevents apropos(1)
> from listing multiple pages and making the user wonder whether they
> differ, possibly wasting their time running diff(1).
>
> This is even likely to become worse in the near future when man(1)
> starts warning that there are multiple manual pages of the same name
> in the same section.
>
> However, *if* you expect that the pages are likely to actually
> become different in the future, that might be a reason against
> making this subpackage. Then again, if that happens, it would
> also be an option to merge them back in after it happens.
They won't; the different flavours are merely building with different
versions of lua, the manuals are unaffected.
> > Note that RUN_DEPENDS-docs is needed otherwise (via lua.port.mk and
> > global RUN_DEPENDS) it ends up depending on lang/lua,${FLAVOR} and
> > that will break subsequent build (the plist register the deps on one
> > flavor, when building the next one the plist would differ)
>
> Again, i don't think these technical considerations are the only
> reason for RUN_DEPENDS-docs. I general, i stongly feel that if
> you say "pkg_add food", that should absolutely install all the
> documentation for the "foo" daemon. I mean, how is the user
> supposed to use it if there is no documentation? We want sane
> defaults, and installing software without documentation is not
> exactly sane. Why should we send the user on a wild goose chase
> to search for a "foo" documentation package after they alraedy
> said they want food?
>
> I certainly don't want to emulate the bad habit of some Linux
> distros to not install documentation unless the user goes an extra
> mile specifically asking for it.
Explicitly setting RUN_DEPENDS-docs to makes sense,
but I think we should also have "RUN_DEPENDS-main += lang/fennel,-docs".
Otherwise the ports aspects look correct to me.
> > However, I'm not sure I'm overthinking it and just rename the three
> > new manpages to fennel-${V}-XYZ instead of doing a subpackage would be
> > preferred.
>
> I did not audit this ports-wise, but i do like your general idea.
> It doesn't feel like overengineering to me, there appear to be actual
> benefits from the user perspective.
Agreed.
> > +SITES = https://git.sr.ht/~technomancy/fennel/archive/
btw, I think this could probably change to DIST_TUPLES if wanted.
Re: update lang/fennel; move man pages to a -docs subpackage
Hi Omar,
Omar Polo wrote on Tue, Sep 19, 2023 at 10:10:44AM +0200:
> The update itself is straightforward and all tests are passing.
> However, upstream added three more man pages (for a total of four now)
> which would get shipped in all of four fennel flavors (lua5[1-3]).
>
> Now, this is practice works, i.e. even if you have installed all the
> flavors `man fennel-api' works and since all the manpages are
> identical it's not really important if mandoc chooses fennel-5.1-api
> or fennel-5.4-api.
>
> However, I disliked to ship the same set of man pages four times, so
> here's an attempt to move them to a -docs subpackage. (thanks sthen@
> for pointing me at www/squid)
I wouldn't consider saving the diskspace for three manual pages the
main benefit, even though that hardly hurts, either. It seems more
important that your approach of making a subpackage prevents apropos(1)
from listing multiple pages and making the user wonder whether they
differ, possibly wasting their time running diff(1).
This is even likely to become worse in the near future when man(1)
starts warning that there are multiple manual pages of the same name
in the same section.
However, *if* you expect that the pages are likely to actually
become different in the future, that might be a reason against
making this subpackage. Then again, if that happens, it would
also be an option to merge them back in after it happens.
> Note that RUN_DEPENDS-docs is needed otherwise (via lua.port.mk and
> global RUN_DEPENDS) it ends up depending on lang/lua,${FLAVOR} and
> that will break subsequent build (the plist register the deps on one
> flavor, when building the next one the plist would differ)
Again, i don't think these technical considerations are the only
reason for RUN_DEPENDS-docs. I general, i stongly feel that if
you say "pkg_add food", that should absolutely install all the
documentation for the "foo" daemon. I mean, how is the user
supposed to use it if there is no documentation? We want sane
defaults, and installing software without documentation is not
exactly sane. Why should we send the user on a wild goose chase
to search for a "foo" documentation package after they alraedy
said they want food?
I certainly don't want to emulate the bad habit of some Linux
distros to not install documentation unless the user goes an extra
mile specifically asking for it.
> However, I'm not sure I'm overthinking it and just rename the three
> new manpages to fennel-${V}-XYZ instead of doing a subpackage would be
> preferred.
I did not audit this ports-wise, but i do like your general idea.
It doesn't feel like overengineering to me, there appear to be actual
benefits from the user perspective.
Yours,
Ingo
Re: new ports needed to unbreak devel/spyder
On 2023/09/16 15:27:21 -0400, Daniel Dickman wrote: > Thanks to Stuart, I've just imported a few new ports needed to update > devel/spyder back to a working state, but we still need a few more new > ports to go. > > So looking for ok's to import the attached. > > ok's would be needed starting from the most indented nodes in the tree > first, and then working our way up the tree. The tarball can just be > extrated into /usr/ports. > > Here's the dependency tree of the new ports, so ideally I could get ok's > starting with autopep8, pydocstyle and helpdev) -- devel/py-python-language-server works for me in my basic testing (eglot on Emacs with a few simple scripts.) I'd sort RUN_DEPENDS. ok op@. I'd call the port devel/pyls, since it's what I'd expect.
Re: new ports needed to unbreak devel/spyder
On 2023/09/16 15:27:21 -0400, Daniel Dickman wrote: > Thanks to Stuart, I've just imported a few new ports needed to update > devel/spyder back to a working state, but we still need a few more new > ports to go. > > So looking for ok's to import the attached. > > ok's would be needed starting from the most indented nodes in the tree > first, and then working our way up the tree. The tarball can just be > extrated into /usr/ports. > ok for devel/autopep8 with: - a fixed COMMENT and DESCR (i guess due a copy-paste from another port.) - remove the commented FLAVOR/S lines. (IIRC for "binaries" we don't use the py3 flavor, or is it needed in this case?) - a dependency on py3-codestyle: % autopep8 foo.py Traceback (most recent call last): File "/usr/local/bin/autopep8", line 5, in from autopep8 import main File "/usr/local/lib/python3.10/site-packages/autopep8.py", line 93, in import pycodestyle ModuleNotFoundError: No module named 'pycodestyle' the latest version seems to be 2.0.4, any reason to import 1.6.0 instead? not a huge issue, can be updated once it's on-tree.
update lang/fennel; move man pages to a -docs subpackage
The update itself is straightforward and all tests are passing.
However, upstream added three more man pages (for a total of four now)
which would get shipped in all of four fennel flavors (lua5[1-3]).
Now, this is practice works, i.e. even if you have installed all the
flavors `man fennel-api' works and since all the manpages are
identical it's not really important if mandoc chooses fennel-5.1-api
or fennel-5.4-api.
However, I disliked to ship the same set of man pages four times, so
here's an attempt to move them to a -docs subpackage. (thanks sthen@
for pointing me at www/squid)
Note that RUN_DEPENDS-docs is needed otherwise (via lua.port.mk and
global RUN_DEPENDS) it ends up depending on lang/lua,${FLAVOR} and
that will break subsequent build (the plist register the deps on one
flavor, when building the next one the plist would differ)
However, I'm not sure I'm overthinking it and just rename the three
new manpages to fennel-${V}-XYZ instead of doing a subpackage would be
preferred.
Index: Makefile
===
RCS file: /home/cvs/ports/lang/fennel/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- Makefile26 Dec 2022 11:05:59 - 1.2
+++ Makefile18 Sep 2023 15:52:07 -
@@ -1,8 +1,16 @@
-COMMENT = Lisp dialect that runs on Lua ${MODLUA_VERSION}
+COMMENT-main = Lisp dialect that runs on Lua ${MODLUA_VERSION}
+COMMENT-docs = Documentation for fennel
-V =1.2.1
+V =1.3.1
PKGNAME = fennel-$V
-FULLPKGNAME = fennel-${FLAVOR}-${V}
+FULLPKGPATH-main = lang/fennel,-main,${FLAVOR}
+FULLPKGNAME-main = fennel-${FLAVOR}-${V}
+
+# -docs isn't flavoured, so overwrite its default name/path
+FULLPKGNAME-docs = fennel-docs-$V
+FULLPKGPATH-docs = ${PKGPATH},-docs
+RUN_DEPENDS-main+= lang/fennel,-docs
+RUN_DEPENDS-docs =
CATEGORIES = lang
@@ -13,7 +21,9 @@ MAINTAINER = Omar Polo
# MIT
PERMIT_PACKAGE = Yes
-MASTER_SITES = https://git.sr.ht/~technomancy/fennel/archive/
+MULTI_PACKAGES = -main -docs
+
+SITES =https://git.sr.ht/~technomancy/fennel/archive/
DISTFILES =fennel-{}$V${EXTRACT_SUFX}
@@ -29,13 +39,13 @@ ALL_TARGET =build
MAKE_FLAGS += LUA=${MODLUA_BIN} \
LUA_VERSION=${MODLUA_VERSION} \
LUA_LIB_DIR=${MODLUA_LIBDIR}
-FAKE_FLAGS += PREFIX=${TRUEPREFIX}
+FAKE_FLAGS += PREFIX=${TRUEPREFIX} \
+ MAN_DIR=${PREFIX}
WRKDIST = ${WRKDIR}/${PKGNAME}
post-install:
chmod +x ${PREFIX}/bin/fennel
cd ${PREFIX}/bin && mv fennel fennel-${MODLUA_VERSION}
- cd ${PREFIX}/man/man1 && mv fennel.1 fennel-${MODLUA_VERSION}.1
.include
Index: distinfo
===
RCS file: /home/cvs/ports/lang/fennel/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo24 Dec 2022 08:57:07 - 1.1.1.1
+++ distinfo18 Sep 2023 11:20:49 -
@@ -1,2 +1,2 @@
-SHA256 (fennel-1.2.1.tar.gz) = ZlSq23ZZu/iNOHkZA5JXPhrjkIfqr1CE6V9F246CrVE=
-SIZE (fennel-1.2.1.tar.gz) = 271590
+SHA256 (fennel-1.3.1.tar.gz) = gz2Qt+me3Uh0A/Uf38PLsmO/lltyqRS7u7AVbGEy1GU=
+SIZE (fennel-1.3.1.tar.gz) = 293564
Index: pkg/DESCR
===
RCS file: pkg/DESCR
diff -N pkg/DESCR
--- pkg/DESCR 24 Dec 2022 08:57:07 - 1.1.1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,16 +0,0 @@
-Fennel is a programming language that brings together the speed,
-simplicity, and reach of Lua with the flexibility of a lisp syntax and
-macro system.
-
- - Full Lua compatibility: Easily call any Lua function or library from
- Fennel and vice-versa.
-
- - Zero overhead: Compiled code should be just as efficient as
- hand-written Lua.
-
- - Compile-time macros: Ship compiled code with no runtime dependency on
- Fennel.
-
- - Embeddable: Fennel is a one-file library as well as an executable.
- Embed it in other programs to support runtime extensibility and
- interactive development.
Index: pkg/DESCR-docs
===
RCS file: pkg/DESCR-docs
diff -N pkg/DESCR-docs
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pkg/DESCR-docs 19 Sep 2023 08:09:09 -
@@ -0,0 +1 @@
+Manual pages for fennel.
Index: pkg/DESCR-main
===
RCS file: pkg/DESCR-main
diff -N pkg/DESCR-main
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pkg/DESCR-main 24 Dec 2022 08:57:07 -
@@ -0,0 +1,16 @@
+Fennel is a programming language that brings together the speed,
+simplicity, and reach of Lua with the flexibility of a lisp syntax and
+macro system.
+
+ - Full Lua compatibility: Easily call any Lua function or library from
+ Fennel and vice-versa.
+
+ - Zero overhead: Compiled code should be just as efficient as
+ hand-written Lua.
+
+ - Compile-time macros: Ship compiled code with
