CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ben...@cvs.openbsd.org 2020/01/17 00:44:21 Modified files: games/rocksndiamonds: Makefile distinfo Log message: Update to rocksndiamonds-4.1.4.1.
Re: NEW FONTS PORT: jetbrains
On Thu, Jan 16, 2020 at 11:24:50PM +0100, Antoine Jacoutot wrote: > On Thu, Jan 16, 2020 at 05:26:50PM +0100, Marc Espie wrote: > > This font was designed for development, apparently, as part of an IDE, > > and they decided to open up the font (Apache 2.0) > > > > I played with it a bit and it is indeed pleasant. > > > > Fairly straightforward. > > > Why putting DISTNAME in such a weird place? Also I prefer when package names are lowercase. It's already hard enough to search for package in OpenBSD... But maybe that's just me... -- Antoine
Update: textproc/zathura
Builds fine. I don't use it, so I'd appreciate if a user could test it
still works for them. Requires the girara update just sent. zsh tab
completion works without fpath modification.
diff --git Makefile Makefile
index b85e1d4fdad..71df90927f6 100644
--- Makefile
+++ Makefile
@@ -1,6 +1,6 @@
# $OpenBSD: Makefile,v 1.26 2019/07/12 20:50:17 sthen Exp $
-V =0.4.3
+V =0.4.5
REVISION = 0
COMMENT = document viewer for PDF and other formats with a
vi-like UI
DISTNAME = zathura-${V}
@@ -27,7 +27,7 @@ RUN_DEPENDS = devel/desktop-file-utils \
x11/gtk+3,-guic
LIB_DEPENDS = databases/sqlite3 \
devel/libmagic \
- x11/girara>=0.3.2 \
+ x11/girara>=0.3.4 \
print/texlive/base,-synctex
COMPILER = base-clang ports-gcc
diff --git distinfo distinfo
index 22b17339d20..39e35a7ccf4 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (zathura-0.4.3.tar.xz) = fhIZRCbXCWcOD0sLEHyA3SEyKIG1fUoL+aCZmEAv/UE=
-SIZE (zathura-0.4.3.tar.xz) = 145796
+SHA256 (zathura-0.4.5.tar.xz) = DDmXqvvNqq5gpFIvIIra390nWLQyzpTqFvvO6TfLdiw=
+SIZE (zathura-0.4.5.tar.xz) = 152720
diff --git pkg/PLIST pkg/PLIST
index e25874e6b9f..13e05d783e4 100644
--- pkg/PLIST
+++ pkg/PLIST
@@ -19,6 +19,9 @@ share/bash-completion/completions/zathura
share/dbus-1/interfaces/
share/dbus-1/interfaces/org.pwmt.zathura.xml
share/doc/pkg-readmes/${PKGSTEM}
+share/fish/
+share/fish/completions/
+share/fish/completions/zathura.fish
share/icons/hicolor/128x128/apps/org.pwmt.zathura.png
share/icons/hicolor/16x16/apps/org.pwmt.zathura.png
share/icons/hicolor/256x256/apps/org.pwmt.zathura.png
@@ -27,6 +30,7 @@ share/icons/hicolor/64x64/apps/org.pwmt.zathura.png
share/icons/scalable/
share/icons/scalable/apps/
share/icons/scalable/apps/org.pwmt.zathura.svg
+share/locale/ar/LC_MESSAGES/zathura.mo
share/locale/ca/LC_MESSAGES/zathura.mo
share/locale/cs/LC_MESSAGES/zathura.mo
share/locale/de/LC_MESSAGES/zathura.mo
@@ -61,8 +65,8 @@ share/locale/uk_UA/LC_MESSAGES/zathura.mo
share/metainfo/
share/metainfo/org.pwmt.zathura.appdata.xml
share/zsh/
-share/zsh/vendor-completions/
-share/zsh/vendor-completions/_zathura
@tag gtk-update-icon-cache %D/share/icons/hicolor
@tag gtk-update-icon-cache %D/share/icons/scalable
@tag update-desktop-database
+share/zsh/site-functions/
+share/zsh/site-functions/_zathura
UPDATE fonts/ibm-plex to 4.0.2
Diff attached.
Change from previous version includes addition of woff and woff2 fonts
beyond just OTF and TTF distfiles.
Thanks
g
Index: ibm-plex//Makefile
===
RCS file: /cvs/ports/fonts/ibm-plex/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- ibm-plex//Makefile 12 Jul 2019 20:46:12 - 1.9
+++ ibm-plex//Makefile 17 Jan 2020 04:03:28 -
@@ -3,36 +3,28 @@
COMMENT = IBM's corporate type family
CATEGORIES = fonts
-V = 2.0.0
+V = 4.0.2
PKGNAME = ibm-plex-$V
+GH_ACCOUNT = IBM
+GH_PROJECT = plex
+GH_TAGNAME = v${V}
+
# SIL OFL 1.1
PERMIT_PACKAGE = Yes
-MASTER_SITES = https://github.com/IBM/plex/releases/download/v$V/
-
-DISTFILES = OpenType.zip \
- TrueType.zip
-
-DIST_SUBDIR = ibm-plex-$V
-
HOMEPAGE = https://www.ibm.com/plex/
-MODULES = font
-
NO_BUILD = Yes
NO_TEST = Yes
+WRKSRC = ${WRKDIST}/plex-${V}
FONTDIR = ${PREFIX}/share/fonts/ibm-plex
DOCDIR = ${PREFIX}/share/doc/ibm-plex
do-install:
- ${INSTALL_DATA_DIR} ${FONTDIR}
- ${INSTALL_DATA} ${WRKDIST}/OpenType/*/*.otf ${FONTDIR}
- ${INSTALL_DATA} ${WRKDIST}/TrueType/*/*.ttf ${FONTDIR}
-
-post-install:
- ${INSTALL_DATA_DIR} ${DOCDIR}
- ${INSTALL_DATA} ${WRKDIST}/OpenType/IBM-Plex-Sans/license.txt ${DOCDIR}
+ ${INSTALL_DATA_DIR} ${DOCDIR} ${FONTDIR}
+ ${INSTALL_DATA} ${WRKDIST}/{README.md,LICENSE.txt} ${DOCDIR}
+ ${INSTALL_DATA} ${WRKDIST}/IBM-Plex-*/fonts/complete/{otf,ttf,woff,woff2}/* ${FONTDIR}
.include
Index: ibm-plex//distinfo
===
RCS file: /cvs/ports/fonts/ibm-plex/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- ibm-plex//distinfo 11 Jun 2019 07:17:23 - 1.7
+++ ibm-plex//distinfo 17 Jan 2020 04:03:28 -
@@ -1,4 +1,2 @@
-SHA256 (ibm-plex-2.0.0/OpenType.zip) = aCWG4MCHIrUt/TTpJHF4OakKvufFqWYGF/Bhi8cvZtM=
-SHA256 (ibm-plex-2.0.0/TrueType.zip) = zvqebl2gA/UKRnzk9CrzS0J7nBk6v8PjPIAMSrx28cs=
-SIZE (ibm-plex-2.0.0/OpenType.zip) = 6607070
-SIZE (ibm-plex-2.0.0/TrueType.zip) = 7662205
+SHA256 (plex-4.0.2.tar.gz) = xxENxNP361B9tVqmRZIL/R4LKe0v0c8bpOseLGhJ/vk=
+SIZE (plex-4.0.2.tar.gz) = 75546862
Index: ibm-plex//pkg/PLIST
===
RCS file: /cvs/ports/fonts/ibm-plex/pkg/PLIST,v
retrieving revision 1.7
diff -u -p -r1.7 PLIST
--- ibm-plex//pkg/PLIST 11 Jun 2019 07:17:23 - 1.7
+++ ibm-plex//pkg/PLIST 17 Jan 2020 04:03:28 -
@@ -1,213 +1,427 @@
@comment $OpenBSD: PLIST,v 1.7 2019/06/11 07:17:23 bentley Exp $
share/doc/ibm-plex/
-share/doc/ibm-plex/license.txt
+share/doc/ibm-plex/LICENSE.txt
+share/doc/ibm-plex/README.md
share/fonts/
@fontdir share/fonts/ibm-plex/
-share/fonts/ibm-plex/IBMPlexArabic-Bold.otf
-share/fonts/ibm-plex/IBMPlexArabic-Bold.ttf
-share/fonts/ibm-plex/IBMPlexArabic-ExtraLight.otf
-share/fonts/ibm-plex/IBMPlexArabic-ExtraLight.ttf
-share/fonts/ibm-plex/IBMPlexArabic-Light.otf
-share/fonts/ibm-plex/IBMPlexArabic-Light.ttf
-share/fonts/ibm-plex/IBMPlexArabic-Medium.otf
-share/fonts/ibm-plex/IBMPlexArabic-Medium.ttf
-share/fonts/ibm-plex/IBMPlexArabic-Regular.otf
-share/fonts/ibm-plex/IBMPlexArabic-Regular.ttf
-share/fonts/ibm-plex/IBMPlexArabic-SemiBold.otf
-share/fonts/ibm-plex/IBMPlexArabic-SemiBold.ttf
-share/fonts/ibm-plex/IBMPlexArabic-Text.otf
-share/fonts/ibm-plex/IBMPlexArabic-Text.ttf
-share/fonts/ibm-plex/IBMPlexArabic-Thin.otf
-share/fonts/ibm-plex/IBMPlexArabic-Thin.ttf
-share/fonts/ibm-plex/IBMPlexDevanagari-Bold.otf
-share/fonts/ibm-plex/IBMPlexDevanagari-Bold.ttf
-share/fonts/ibm-plex/IBMPlexDevanagari-ExtraLight.otf
-share/fonts/ibm-plex/IBMPlexDevanagari-ExtraLight.ttf
-share/fonts/ibm-plex/IBMPlexDevanagari-Light.otf
-share/fonts/ibm-plex/IBMPlexDevanagari-Light.ttf
-share/fonts/ibm-plex/IBMPlexDevanagari-Medium.otf
-share/fonts/ibm-plex/IBMPlexDevanagari-Medium.ttf
-share/fonts/ibm-plex/IBMPlexDevanagari-Regular.otf
-share/fonts/ibm-plex/IBMPlexDevanagari-Regular.ttf
-share/fonts/ibm-plex/IBMPlexDevanagari-SemiBold.otf
-share/fonts/ibm-plex/IBMPlexDevanagari-SemiBold.ttf
-share/fonts/ibm-plex/IBMPlexDevanagari-Text.otf
-share/fonts/ibm-plex/IBMPlexDevanagari-Text.ttf
-share/fonts/ibm-plex/IBMPlexDevanagari-Thin.otf
-share/fonts/ibm-plex/IBMPlexDevanagari-Thin.ttf
share/fonts/ibm-plex/IBMPlexMono-Bold.otf
share/fonts/ibm-plex/IBMPlexMono-Bold.ttf
+share/fonts/ibm-plex/IBMPlexMono-Bold.woff
+share/fonts/ibm-plex/IBMPlexMono-Bold.woff2
share/fonts/ibm-plex/IBMPlexMono-BoldItalic.otf
share/fonts/ibm-plex/IBMPlexMono-BoldItalic.ttf
+share/fonts/ibm-plex/IBMPlexMono-BoldItalic.woff
+share/fonts/ibm-plex/IBMPlexMono-BoldItalic.woff2
share/fonts/ibm-plex/IBMPlexMono-ExtraLight.otf
share/fonts/ibm-plex/IBMPlexMono-ExtraLight.ttf
+share/fonts/ibm-plex/IBMPlexMono-ExtraLight.woff
+share/fonts/ibm-plex/IBMPlexMono-ExtraLight.woff2
share/fonts/ibm-plex/IBMPlexMono-ExtraLightItalic.otf
share/fonts/ibm-plex/IBMPlexMono-ExtraLightItalic.ttf
Update: x11/girara
Required to update zathura.
Reviewing the diff at https://git.pwmt.org/pwmt/girara/compare/0.3.2...0.3.4
there was a symbol addition (girara_xdg_open_with_working_directory) and
a few exported symbols had a pointer arg made const. I think a minor
bump suffices here. Only consumer seems to be zathura which builds fine.
diff --git Makefile Makefile
index 61a91d9c39d..b749ba0f3a3 100644
--- Makefile
+++ Makefile
@@ -1,9 +1,9 @@
# $OpenBSD: Makefile,v 1.21 2019/07/13 22:12:09 naddy Exp $
COMMENT = user interface library from pwmt
-DISTNAME = girara-0.3.2
+DISTNAME = girara-0.3.4
-SHARED_LIBS += girara-gtk3 1.0 # 3.1
+SHARED_LIBS += girara-gtk3 1.1 # 3.1
EXTRACT_SUFX = .tar.xz
CATEGORIES = x11
diff --git distinfo distinfo
index 8d5d7072b3b..a261da12b08 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (girara-0.3.2.tar.xz) = FwA1OhAfPFIPmyLnnXHqWyaKnsMkeWz55kd12Wuwhs0=
-SIZE (girara-0.3.2.tar.xz) = 58220
+SHA256 (girara-0.3.4.tar.xz) = UfzaWlCmj6vUYftORnod79Ux2vyk9H9oUanrVnVssjI=
+SIZE (girara-0.3.4.tar.xz) = 58708
diff --git pkg/PLIST pkg/PLIST
index 107790e4b90..52e2753df66 100644
--- pkg/PLIST
+++ pkg/PLIST
@@ -20,6 +20,7 @@ include/girara/types.h
include/girara/utils.h
@lib lib/libgirara-gtk3.so.${LIBgirara-gtk3_VERSION}
lib/pkgconfig/girara-gtk3.pc
+share/locale/ar/LC_MESSAGES/libgirara-gtk3-3.mo
share/locale/de/LC_MESSAGES/libgirara-gtk3-3.mo
share/locale/el/LC_MESSAGES/libgirara-gtk3-3.mo
share/locale/eo/LC_MESSAGES/libgirara-gtk3-3.mo
@@ -31,4 +32,5 @@ share/locale/nl/LC_MESSAGES/libgirara-gtk3-3.mo
share/locale/pl/LC_MESSAGES/libgirara-gtk3-3.mo
share/locale/pt_BR/LC_MESSAGES/libgirara-gtk3-3.mo
share/locale/ru/LC_MESSAGES/libgirara-gtk3-3.mo
+share/locale/sv/LC_MESSAGES/libgirara-gtk3-3.mo
share/locale/tr/LC_MESSAGES/libgirara-gtk3-3.mo
sysutils/exa: Fix zsh completion
With this exa completes with no fpath changes.
diff --git Makefile Makefile
index 7bead97a053..83f06082546 100644
--- Makefile
+++ Makefile
@@ -5,6 +5,7 @@ COMMENT = ls alternative written in Rust
GH_ACCOUNT = ogham
GH_PROJECT = exa
GH_TAGNAME = v0.9.0
+REVISION = 0
CATEGORIES = sysutils
@@ -101,8 +102,8 @@ post-install:
${INSTALL_MAN} ${WRKSRC}/contrib/man/exa.1 ${PREFIX}/man/man1/exa.1
${INSTALL_DATA_DIR} ${PREFIX}/share/fish/completions/
${INSTALL_DATA} ${WRKSRC}/contrib/completions.fish
${PREFIX}/share/fish/completions/exa.fish
- ${INSTALL_DATA_DIR} ${PREFIX}/share/zsh/vendor-completions/
- ${INSTALL_DATA} ${WRKSRC}/contrib/completions.zsh
${PREFIX}/share/zsh/vendor-completions/_exa
+ ${INSTALL_DATA_DIR} ${PREFIX}/share/zsh/site-functions/
+ ${INSTALL_DATA} ${WRKSRC}/contrib/completions.zsh
${PREFIX}/share/zsh/site-functions/_exa
${INSTALL_DATA_DIR} ${PREFIX}/share/bash-completion/completions/
${INSTALL_DATA} ${WRKSRC}/contrib/completions.bash
${PREFIX}/share/bash-completion/completions/exa
diff --git pkg/PLIST pkg/PLIST
index f1aa0cfebf9..a9fff2e400f 100644
--- pkg/PLIST
+++ pkg/PLIST
@@ -8,5 +8,5 @@ share/fish/
share/fish/completions/
share/fish/completions/exa.fish
share/zsh/
-share/zsh/vendor-completions/
-share/zsh/vendor-completions/_exa
+share/zsh/site-functions/
+share/zsh/site-functions/_exa
productivity/khard: Fix zsh completion
With this khard tab completes with no fpath changes.
diff --git Makefile Makefile
index c5139bd0b9a..d477a35fdcc 100644
--- Makefile
+++ Makefile
@@ -4,6 +4,7 @@ COMMENT = console CardDAV client
MODPY_EGG_VERSION =0.15.1
DISTNAME = khard-${MODPY_EGG_VERSION}
+REVISION = 0
CATEGORIES = productivity
@@ -42,9 +43,9 @@ post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/examples/khard
${INSTALL_DATA} ${WRKSRC}/misc/khard/khard.conf.example \
${PREFIX}/share/examples/khard
- ${INSTALL_DATA_DIR} ${PREFIX}/share/zsh/vendor-completions
+ ${INSTALL_DATA_DIR} ${PREFIX}/share/zsh/site-functions
${INSTALL_DATA} ${WRKSRC}/misc/zsh/{_khard,_email-khard} \
- ${PREFIX}/share/zsh/vendor-completions
+ ${PREFIX}/share/zsh/site-functions
${INSTALL_DATA_DIR} ${PREFIX}/man/man1
${INSTALL_DATA} ${WRKSRC}/doc/build/man/khard.1 \
${PREFIX}/man/man1
diff --git pkg/PLIST pkg/PLIST
index fe4021b267a..3debf54d97e 100644
--- pkg/PLIST
+++ pkg/PLIST
@@ -41,6 +41,6 @@ lib/python${MODPY_VERSION}/site-packages/khard/version.py
share/examples/khard/
share/examples/khard/khard.conf.example
share/zsh/
-share/zsh/vendor-completions/
-share/zsh/vendor-completions/_email-khard
-share/zsh/vendor-completions/_khard
+share/zsh/site-functions/
+share/zsh/site-functions/_email-khard
+share/zsh/site-functions/_khard
multimedia/mpv: Fix zsh completion
mpv by default installs its zsh completer to site-functions, so just
remove the --zshdir flag. With this change mpv tab completes with no
fpath changes.
diff --git Makefile Makefile
index 9e483bde787..0e4eb3371e7 100644
--- Makefile
+++ Makefile
@@ -5,6 +5,7 @@ COMMENT = movie player based on MPlayer/mplayer2
GH_ACCOUNT = mpv-player
GH_PROJECT = mpv
GH_TAGNAME = v0.31.0
+REVISION = 0
SHARED_LIBS += mpv 0.1 # 1.106
@@ -60,7 +61,6 @@ CONFIGURE_ARGS = --confloaddir=${SYSCONFDIR}/mpv \
--confdir=${LOCALBASE}/share/examples/mpv \
--mandir=${LOCALBASE}/man \
--docdir=${LOCALBASE}/share/examples/mpv \
- --zshdir=${LOCALBASE}/share/zsh/vendor-completions \
--enable-cdda \
--enable-dvdnav \
--enable-libmpv-shared \
diff --git pkg/PLIST pkg/PLIST
index 589241e..cad3f1ef19b 100644
--- pkg/PLIST
+++ pkg/PLIST
@@ -27,5 +27,5 @@ share/icons/hicolor/symbolic/apps/mpv-symbolic.svg
@tag gtk-update-icon-cache %D/share/icons/hicolor
@tag update-desktop-database
share/zsh/
-share/zsh/vendor-completions/
-share/zsh/vendor-completions/_mpv
+share/zsh/site-functions/
+share/zsh/site-functions/_mpv
Re: should we port ssh-copy-id ?
On Tue, Jan 14, 2020, at 00:47, Jan-Piet Mens wrote: > ssh-copy-id [1] is a script to copy one's SSH keys to remote hosts, > ensuring that ~/.ssh and authorized_keys are created with correct > permissions. The script uses ssh(1) to log into a remote machine (using > a login password). > > This script is available in portable OpenSSH [2] and is installed on > many (most?) Linux distributions, macOS, and from a different source > [3], in FreeBSD. > > Would ssh-copy-id from [1] likely be accepted as a port if I attempted > to undertake the task? As a user, I would like this to exist as a port. I miss it regularly.
Re: New: Haxe - high-level strictly-typed language that can build cross-platform applications
ping On Wed, Jan 1, 2020, at 4:37 PM, Thomas Frohwein wrote: > ping > > Attached is a tarball trivially updated to 4.0.5 (last one was 4.0.1). > Still runs the Hello World example, as well as the upcoming hashlink > port. > > On Fri, Dec 6, 2019, at 9:21 AM, Thomas Frohwein wrote: > > Hi, > > > > Please find attached a port of the Haxe language. Haxe is a high-level > > strictly-typed language that can compile to different target languages > > and platforms like JS, C++, C#, Java, Python, Lua, Flash. > > > > Passes make port-lib-depends-check and portcheck. It compiles and runs > > the example Hello World program [1]. I have also used it to build and > > run the upcoming port hashlink, a VM that runs bytecode-compiled Haxe > > applications like the indie game Dead Cells. > > > > Links to other tutorials and examples, and general documentation are > > available at [1]. > > > > A few comments: > > > > * The build doesn't include the CFLAGS. I tried a few ways, but am not > > familiar enough with the OCaml-verse. > > * Would appreciate hosting the tarball somewhere else because I can't > > guarantee uptime. > > > > ok? > > > > [1] https://haxe.org/manual/introduction-hello-world.html > > > > Attachments: > > * haxe.tgz > > -- > > tfrohw...@fastmail.com > > PGP Public Key: > https://pgp.mit.edu/pks/lookup?op=get=0xE1A22D58D20C6D22 > Attachments: > * haxe.tgz -- tfrohw...@fastmail.com PGP Public Key: https://pgp.mit.edu/pks/lookup?op=get=0xE1A22D58D20C6D22
Re: NEW: www/p5-Plack-App-URLMux
Hi, Kind reminder. Port reattached for convenience. On Sun, Jan 05, 2020 at 10:11:47PM +, Mikolaj Kucharski wrote: > My previous email with the tarball for convenience: > > https://marc.info/?l=openbsd-ports=157734267315699=2 > > On Thu, Dec 26, 2019 at 06:43:35AM +, Mikolaj Kucharski wrote: > > Hi, > > > > Created with portgen(1), works for me with Plack from packages snapshot > > on current and on 6.6-stable, make tests pass. > > > > All tests successful. > > Files=9, Tests=70, 2 wallclock secs ( 0.05 usr 0.03 sys + 1.30 cusr 0.31 > > csys = 1.69 CPU) > > Result: PASS > > > > > > Comment: > > map multiple applications in defferent url path > > > > Description: > > Plack::App::URLMux is a PSGI application that can dispatch multiple > > applications based on URL path and host names (a.k.a "virtual hosting") > > and takes care of rewriting SCRIPT_NAME and PATH_INFO. This module is > > based on Plack::App::URLMap module but optimizied to handle a lot of > > urls and has additional rules for parameterized URL and add additional > > parameteres provided to application at mapping URL. -- Regards, Mikolaj p5-Plack-App-URLMux.port.tgz Description: application/tar-gz
[UPDATE] productivity/mcds to version 1.6
Hi all,
I know I submitted version 1.4 not too long ago, terribly sorry
for creating more work. I noticed that diff wasn't applied, so
I'm hoping this update to 1.6 can replace it.
As with any updates I introduced a couple of bugs, hence the jump
to version 1.6.
Diff is attached.
Regards
Tim
Index: Makefile
===
RCS file: /cvs/ports/productivity/mcds/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefile 12 Jul 2019 20:48:59 - 1.3
+++ Makefile 16 Jan 2020 22:46:26 -
@@ -2,23 +2,24 @@
COMMENT = tty-based carddav search tool
-V = 0.9
+V = 1.6
DISTNAME = mcds-${V}
CATEGORIES = productivity
-REVISION = 0
MAINTAINER = Timothy Brown
# GPLv3+
PERMIT_PACKAGE = Yes
-WANTLIB = c curl iconv intl xml2
+# uses pledge()
+WANTLIB = assuan c curl gpg-error gpgme iconv intl xml2
MASTER_SITES = https://github.com/t-brown/mcds/releases/download/v${V}/
LIB_DEPENDS = devel/gettext,-runtime \
net/curl \
- textproc/libxml
+ textproc/libxml \
+ security/gpgme
CONFIGURE_STYLE = gnu
Index: distinfo
===
RCS file: /cvs/ports/productivity/mcds/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo 2 May 2019 15:52:58 - 1.1.1.1
+++ distinfo 16 Jan 2020 22:46:26 -
@@ -1,2 +1,2 @@
-SHA256 (mcds-0.9.tar.gz) = p+H8Q94kiHDDo/pV570uCXZki5YnyC41tUDx8HgARKc=
-SIZE (mcds-0.9.tar.gz) = 194620
+SHA256 (mcds-1.6.tar.gz) = HLSkhSxy00Y/Ft5XQ1FVqwZe1UJrJifDok080B1QXEM=
+SIZE (mcds-1.6.tar.gz) = 203185
Index: pkg/DESCR
===
RCS file: /cvs/ports/productivity/mcds/pkg/DESCR,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 DESCR
--- pkg/DESCR 2 May 2019 15:52:58 - 1.1.1.1
+++ pkg/DESCR 16 Jan 2020 22:46:26 -
@@ -1,2 +1,2 @@
Mcds is a command line tool primarily used as a search query plugin for mutt
-to query a carddav server.
+to query a CardDav server.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/01/16 15:33:54 Modified files: cad/abc: Makefile Log message: add a comment explaining pre-configure
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/01/16 15:32:48 Modified files: cad/abc: Makefile distinfo cad/abc/patches: patch-Makefile Added files: cad/abc/patches: patch-src_base_main_mainReal_c Log message: update to newer cad/abc checkout, from maintainer Alessandro De Laurenzis
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/01/16 15:28:53 Modified files: graphics/ipe : Makefile distinfo graphics/ipe/patches: patch-src_ipe_lua_prefs_lua patch-src_ipelib_ipeplatform_cpp Log message: update to ipe 7.2.12, from maintainer Alessandro De Laurenzis
Re: NEW FONTS PORT: jetbrains
On Thu, Jan 16, 2020 at 05:26:50PM +0100, Marc Espie wrote: > This font was designed for development, apparently, as part of an IDE, > and they decided to open up the font (Apache 2.0) > > I played with it a bit and it is indeed pleasant. > > Fairly straightforward. Why putting DISTNAME in such a weird place? -- Antoine
Re: devel/ddd after libXt update
On 2020/01/16 21:57, Marc Espie wrote: > On Thu, Jan 16, 2020 at 09:35:04PM +0100, Christian Weisgerber wrote: > > (ddd is cruft, the latest release dates from 2009, so this isn't > > really important.) > > What would you recommend as a "simple" gui frontend to (e)gdb then ?... > https://www.gdbgui.com/ is probably about the nicest (it's browser-based), but needs an annoying number of new/updated py-* ports. If a curses UI will do there's always cgdb..
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/01/16 14:24:19 Modified files: telephony/asterisk: Makefile Log message: add a maintainer/debug convenience target to make it easier to adjust internal debug options via "make menuselect" (dep on configure, set user to _pbuild as needed)
Re: [UPDATE] cad/abc 1.01.20180722p0 -> abc-1.01.20200108
Weekly ping!
Diff re-attached.
On 10/01/2020 - 20:45, Alessandro De Laurenzis wrote:
Dear ports@ readers,
The attached diff updates cad/abc to a very recent commit (still no
releases/tags from upstream).
What's new upstream
===
Plenty of new features and bug fixing, including:
- Improvements to the retiming algorithm;
- New command 'symfun' to generate truth table of a symmetric function;
- Support for user-specified wire delays in
- Handling of objects without fanout in %retime;
- New switch -o to 'map' and '' to control gate duplication.
What's new in the port
==
- Updated maintainer email address;
- Updated license string (abc uses an internal copy of "glucose",
released under the MIT license);
- OpenBSD doesn't support RLIMIT_AS, RLIMIT_DATA being the closest
match, see e.g. (1); a new patch is needed for this;
- There is a bunch of "-Wunused-variable" warning messages during
build; I would prefer to reduce the noise and, even if this isn't a
best practice, I switched them off patching the upstream Makefile
(we cannot add the -Wno-unused-variable option through a line in
port's Makefile like the following:
CONFIGURE_ARGS = -DCMAKE_C_FLAGS="${CFLAGS} -Wno-unused-variable"
since it would be overridden by the -Wall explicitly set into the
CFLAGS variable.
It compiles correctly on amd64 and runs ok for a limited set of
test-cases.
(1): https://github.com/OSGeo/gdal/issues/1163
--
Alessandro De Laurenzis
[mailto:jus...@atlantide.mooo.com]
Web: http://www.atlantide.mooo.com
LinkedIn: http://it.linkedin.com/in/delaurenzis
Index: Makefile
===
RCS file: /cvs/ports/cad/abc/Makefile,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 Makefile
--- Makefile12 Jul 2019 20:43:44 - 1.3
+++ Makefile10 Jan 2020 18:46:46 -
@@ -1,18 +1,17 @@
# $OpenBSD: Makefile,v 1.3 2019/07/12 20:43:44 sthen Exp $
COMMENT = system for sequential logic synthesis and verification
-DISTNAME = abc-1.01.20180722
+DISTNAME = abc-1.01.20200108
CATEGORIES = cad
-REVISION = 0
GH_ACCOUNT = berkeley-abc
GH_PROJECT = abc
-GH_COMMIT =ae6716b064c842f45109a88e84dca71fe4cc311f
+GH_COMMIT =144c5be8246800d5bd36dc3e177364063e8d2e40
HOMEPAGE = https://people.eecs.berkeley.edu/~alanmi/abc
-MAINTAINER = Alessandro De Laurenzis
+MAINTAINER = Alessandro De Laurenzis
-# MIT (abc, MiniSat, xSAT), BSD (bzlib, CUDD, satoko), zlib
+# MIT (abc, MiniSat, xSAT, glucose), BSD (bzlib, CUDD, satoko), zlib
PERMIT_PACKAGE = Yes
WANTLIB += ${COMPILER_LIBCXX} c curses m readline
Index: distinfo
===
RCS file: /cvs/ports/cad/abc/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 distinfo
--- distinfo8 Aug 2018 15:24:47 - 1.1.1.1
+++ distinfo10 Jan 2020 18:46:46 -
@@ -1,2 +1,2 @@
-SHA256 (abc-1.01.20180722-ae6716b0.tar.gz) =
Zc9f2Vfbwzn49O61ozQySYos60qulZemoXThSewWHI4=
-SIZE (abc-1.01.20180722-ae6716b0.tar.gz) = 5653452
+SHA256 (abc-1.01.20200108-144c5be8.tar.gz) =
2QyTrZSL6mh0KunYoZuXbsX102cRCMEsNsdEPHu//Dc=
+SIZE (abc-1.01.20200108-144c5be8.tar.gz) = 5739231
Index: patches/patch-Makefile
===
RCS file: /cvs/ports/cad/abc/patches/patch-Makefile,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 patch-Makefile
--- patches/patch-Makefile 8 Aug 2018 15:24:47 - 1.1.1.1
+++ patches/patch-Makefile 10 Jan 2020 18:46:46 -
@@ -3,6 +3,15 @@ $OpenBSD: patch-Makefile,v 1.1.1.1 2018/
Index: Makefile
--- Makefile.orig
+++ Makefile
+@@ -54,7 +54,7 @@ ARCHFLAGS := $(ARCHFLAGS)
+
+ OPTFLAGS ?= -g -O
+
+-CFLAGS+= -Wall -Wno-unused-function -Wno-write-strings -Wno-sign-compare
$(ARCHFLAGS)
++CFLAGS+= -Wall -Wno-unused-function -Wno-write-strings -Wno-sign-compare
-Wno-unused-variable $(ARCHFLAGS)
+ ifneq ($(findstring arm,$(shell uname -m)),)
+ CFLAGS += -DABC_MEMALIGN=4
+ endif
@@ -75,6 +75,9 @@ endif
ABC_READLINE_INCLUDES ?=
Index: patches/patch-src_base_main_mainReal_c
===
RCS file: patches/patch-src_base_main_mainReal_c
diff -N patches/patch-src_base_main_mainReal_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_base_main_mainReal_c 10 Jan 2020 18:46:46 -
@@ -0,0 +1,22 @@
+$OpenBSD$
+
+Index: src/base/main/mainReal.c
+--- src/base/main/mainReal.c.orig
src/base/main/mainReal.c
+@@ -139,7 +139,16 @@ int Abc_RealMain( int argc, char * argv[] )
+ maxMb * (1llu << 20), /* soft limit */
+ maxMb * (1llu << 20) /* hard limit */
+ };
++#ifndef __OpenBSD__
+ setrlimit(RLIMIT_AS, );
++#else
++/*
Re: devel/ddd after libXt update
On Thu, Jan 16, 2020 at 09:35:04PM +0100, Christian Weisgerber wrote: > (ddd is cruft, the latest release dates from 2009, so this isn't > really important.) What would you recommend as a "simple" gui frontend to (e)gdb then ?...
devel/ddd after libXt update
(ddd is cruft, the latest release dates from 2009, so this isn't
really important.)
After the libXt 1.2.0 update in xenocara, devel/ddd fails to build:
--->
/usr/obj/ddd-3.3.12/ddd-3.3.12/ddd/exit.C:815:12: error: no matching function
for call to 'XtAppSetErrorHandler'
(void) XtAppSetErrorHandler(app_context, ddd_xt_error);
^~~~
/usr/X11R6/include/X11/Intrinsic.h:1769:23: note: candidate function not
viable: no known conversion from 'void (String)' (aka 'void (char *)') to 'void
(*)(String) __attribute__((noreturn))' (aka 'void (*)(char *)
__attribute__((noreturn))') for 2nd argument
extern XtErrorHandler XtAppSetErrorHandler(
^
<---
The respective code is this:
--->
static void ddd_xt_error(String message = 0)
{
...
}
void ddd_install_xt_error(XtAppContext app_context)
{
(void) XtAppSetErrorHandler(app_context, ddd_xt_error);
xt_error_app_context = app_context;
}
<---
And the corresponding change in libXt's is this:
--->
extern XtErrorHandler XtAppSetErrorHandler(
XtAppContext /* app_context */,
-XtErrorHandler /* handler */
+XtErrorHandler /* handler */ _X_NORETURN
);
<---
So what's the proper way to fix this? All I have been able to think
of so far is adding _X_NORETURN to the definition of ddd_xt_error().
Index: patches/patch-ddd_exit_C
===
RCS file: patches/patch-ddd_exit_C
diff -N patches/patch-ddd_exit_C
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-ddd_exit_C16 Jan 2020 20:30:07 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+Index: ddd/exit.C
+--- ddd/exit.C.orig
ddd/exit.C
+@@ -769,7 +769,7 @@ static void PostXtErrorCB(XtPointer client_data, XtInt
+
+ static XtAppContext xt_error_app_context = 0;
+
+-static void ddd_xt_error(String message = 0)
++static void ddd_xt_error(String message = 0) _X_NORETURN
+ {
+ ddd_has_crashed = true;
+
--
Christian "naddy" Weisgerber na...@mips.inka.de
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2020/01/16 13:25:43 Modified files: textproc/libxml++: Makefile textproc/libxml++/pkg: PLIST Log message: provide a debug package
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2020/01/16 13:21:16 Modified files: textproc/libxml++3: Makefile distinfo textproc/libxml++3/pkg: PLIST Log message: update to libxml++3-3.2.0
Re: sysutils/fzf: install shell support files
On Thu, Jan 16, 2020 at 05:28:49PM +, Stuart Henderson wrote: > On 2020/01/16 18:05, Paco Esteban wrote: > > Hi Edd, > > > > On Thu, 16 Jan 2020, Edd Barrett wrote: > > > > > Hi, > > > > > > This diff packages the necessary support files for for integrating fzf > > > with shells. > > > > > > With this change, enabling support in (e.g.) zsh is as simple as: > > > > > > ``` > > > export FZF_DEFAULT_OPTS="--ansi" > > > . /usr/local/share/fzf/shell/key-bindings.zsh > > > . /usr/local/share/fzf/shell/completion.zsh > > > ``` > > > > > > OK? > > > > On Nov 28, Aaron Bieber sent a patch to update fzf that included > > something similar, but it was never imported: > > > > https://marc.info/?l=openbsd-ports=157496223810600=2 > > > > I've been using it since with no issues. You may want to take a look > > (he did not put the files in the same place). > > > > Cheers, > > > > -- > > Paco Esteban. > > 5818130B8A6DBC03 > > > > We have standard locations for bash/zsh completion files, not every > port uses them but the majority do and it would probably make sense to > do the same here: > > /usr/local/share/bash-completion/completions > /usr/local/share/zsh/vendor-completions > > There's no equivalent for key-bindings though. vendor-completions is a Debianism that has escaped into upstreams. The Debian reason for the additional folder is site-functions is fully under admin control (like /usr/local for them). Likewise they prefer upstreams use site-functions (so make install'd completers end up in the user controled location) and packages should move the completer to vendor-completions. I think we should use site-functions rather than vendor-completions. This is the zsh upstream supported way. The alternative is to have patches move completers from site-functions to vendor-completions and a patch in shells/zsh to add vendor-completions to the default fpath. These patches should never be merged upstream, so I'm not a fan of it (but it's what Debian does).
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/01/16 11:09:14 Modified files: net/wireshark : Makefile distinfo Log message: update to wireshark-3.2.1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/01/16 11:09:24 Modified files: net/wireshark : Tag: OPENBSD_6_6 Makefile distinfo Log message: update -stable to wireshark-3.0.8
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/01/16 11:08:47 Modified files: net/py-curl: Makefile distinfo net/py-curl/patches: patch-setup_py Log message: update to py-curl 7.43.0.4
Re: sysutils/fzf: install shell support files
On Thu, Jan 16, 2020 at 10:54:41AM -0700, Aaron Bieber wrote:
> +share/bash-completion/
> +share/bash-completion/completions/
> +share/bash-completion/completions/fzf
> +share/zsh/
> +share/zsh/vendor-completions/
> +share/zsh/vendor-completions/_fzf
^^^ I don't think this is right. The "completion files" are not
completion files in the traditional sense. Rather they override what
** does.
I made a diff to put stuff in place for the old version of the port and
tested everything and wrote a README. Sadly we've raced though.
My diff is below. We probably want to merge Aaron's diff with mine.
Index: Makefile
===
RCS file: /cvs/ports/sysutils/fzf/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefile12 Jul 2019 20:49:43 - 1.3
+++ Makefile16 Jan 2020 18:02:39 -
@@ -3,6 +3,7 @@
COMMENT = command-line fuzzy finder
DISTNAME = fzf-0.17.5
+REVISION = 0
CATEGORIES = sysutils
@@ -25,10 +26,33 @@ NO_TEST = Yes
ALL_TARGET = github.com/junegunn/fzf
+
+# Note that unlike zsh and fish, bash has no well-defined site functions
+# directory from which to autoload stuff.
+#
+# Note also that the completion files referenced here are not defining words to
+# complete, but rather overriding what happens when the user requests
+# completion via typing **.
+ZSH_SITE = ${PREFIX}/share/zsh/site-functions
+FISH_SITE =${PREFIX}/share/fish/functions
+BASH_SITE =${PREFIX}/share/fzf/bash
+SUBST_VARS += BASH_SITE FISH_SITE
+
do-install:
${INSTALL_PROGRAM} ${WRKDIR}/go/bin/* ${PREFIX}/bin
${INSTALL_PROGRAM} ${WRKSRC}/bin/* ${PREFIX}/bin
${INSTALL_MAN_DIR} ${PREFIX}/man/man1
${INSTALL_MAN} ${WRKSRC}/man/man1/*.1 ${PREFIX}/man/man1
+
+ ${INSTALL_DATA_DIR} ${ZSH_SITE}
+ ${INSTALL_DATA} ${WRKSRC}/shell/key-bindings.zsh
${ZSH_SITE}/_fzf_key_bindings
+ ${INSTALL_DATA} ${WRKSRC}/shell/completion.zsh
${ZSH_SITE}/_fzf_completion
+
+ ${INSTALL_DATA_DIR} ${FISH_SITE}
+ ${INSTALL_DATA} ${WRKSRC}/shell/key-bindings.fish
${FISH_SITE}/fzf-key-bindings.fish
+
+ ${INSTALL_DATA_DIR} ${BASH_SITE}
+ ${INSTALL_DATA} ${WRKSRC}/shell/key-bindings.bash ${BASH_SITE}
+ ${INSTALL_DATA} ${WRKSRC}/shell/completion.bash ${BASH_SITE}
.include
Index: pkg/PLIST
===
RCS file: /cvs/ports/sysutils/fzf/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- pkg/PLIST 12 Jun 2018 00:10:00 - 1.1.1.1
+++ pkg/PLIST 16 Jan 2020 17:42:06 -
@@ -3,3 +3,15 @@
bin/fzf-tmux
@man man/man1/fzf-tmux.1
@man man/man1/fzf.1
+share/doc/pkg-readmes/${PKGSTEM}
+share/fish/
+share/fish/functions/
+share/fish/functions/fzf-key-bindings.fish
+share/fzf/
+share/fzf/bash/
+share/fzf/bash/completion.bash
+share/fzf/bash/key-bindings.bash
+share/zsh/
+share/zsh/site-functions/
+share/zsh/site-functions/_fzf_completion
+share/zsh/site-functions/_fzf_key_bindings
Index: pkg/README
===
RCS file: pkg/README
diff -N pkg/README
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pkg/README 16 Jan 2020 17:59:25 -
@@ -0,0 +1,46 @@
++---
+| Running ${PKGSTEM} on OpenBSD
++---
+
+Shell Integration
+=
+
+shells/zsh
+--
+
+To enable all support, add this to your ~/.zshrc:
+
+```
+autoload _fzf_key_bindings _fzf_completion
+_fzf_key_bindings
+_fzf_completion
+```
+
+_fzf_key_bindings causes zsh to use fzf for things like CTRL+r and CTRL+t,
+whereas _fzf_completion makes zsh use fzf for ** completion.
+
+shells/bash
+---
+
+To enable all support, add this to your ~/.bashrc:
+
+```
+source ${BASH_SITE}/key_bindings.bash
+source ${BASH_SITE}/completion.bash
+```
+
+These two files have the same roles as their zsh counterparts.
+
+shells/fish
+---
+
+Although the function used to set up fzf is auto-loaded, it can't be used in
+the shell config, so we have to source it anyway. Put the following in
+~/.config/fish/config.fish:
+
+```
+source ${FISH_SITE}/functions/fzf-key-bindings.fish
+fzf_key_bindings
+```
+
+There is no ** completion support for fish.
--
Best Regards
Edd Barrett
http://www.theunixzoo.co.uk
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/01/16 10:57:43 Modified files: geo: Makefile Log message: +pygeoapi
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/01/16 10:57:04 Log message: Import pygeoapi 0.6.0. pygeoapi is a Python server implementation of the OGC API suite of standards, mostly the OGC API Features one previously known as WFS3. ok/tweaks kn@ Status: Vendor Tag: landry Release Tags: landry_20200116 N ports/geo/pygeoapi/Makefile N ports/geo/pygeoapi/distinfo N ports/geo/pygeoapi/pkg/DESCR N ports/geo/pygeoapi/pkg/PLIST No conflicts created by this import
Re: sysutils/fzf: install shell support files
On Thu, 16 Jan 2020 at 17:28:49 +, Stuart Henderson wrote:
> On 2020/01/16 18:05, Paco Esteban wrote:
> > Hi Edd,
> >
> > On Thu, 16 Jan 2020, Edd Barrett wrote:
> >
> > > Hi,
> > >
> > > This diff packages the necessary support files for for integrating fzf
> > > with shells.
> > >
> > > With this change, enabling support in (e.g.) zsh is as simple as:
> > >
> > > ```
> > > export FZF_DEFAULT_OPTS="--ansi"
> > > . /usr/local/share/fzf/shell/key-bindings.zsh
> > > . /usr/local/share/fzf/shell/completion.zsh
> > > ```
> > >
> > > OK?
> >
> > On Nov 28, Aaron Bieber sent a patch to update fzf that included
> > something similar, but it was never imported:
> >
> > https://marc.info/?l=openbsd-ports=157496223810600=2
> >
> > I've been using it since with no issues. You may want to take a look
> > (he did not put the files in the same place).
> >
> > Cheers,
> >
> > --
> > Paco Esteban.
> > 5818130B8A6DBC03
> >
>
> We have standard locations for bash/zsh completion files, not every
> port uses them but the majority do and it would probably make sense to
> do the same here:
>
> /usr/local/share/bash-completion/completions
> /usr/local/share/zsh/vendor-completions
>
> There's no equivalent for key-bindings though.
>
Here is a diff that puts things in the ProperLocation™
I don't use fzf anymore, so it also removes me as the maintainer.
diff --git a/sysutils/fzf/Makefile b/sysutils/fzf/Makefile
index ab4142b5d6b..73e91aef156 100644
--- a/sysutils/fzf/Makefile
+++ b/sysutils/fzf/Makefile
@@ -2,21 +2,19 @@
COMMENT = command-line fuzzy finder
-DISTNAME = fzf-0.17.5
+DISTNAME = fzf-0.19.0
CATEGORIES = sysutils
HOMEPAGE = https://github.com/junegunn/fzf
-MAINTAINER = Aaron Bieber
-
# BSD
PERMIT_PACKAGE = Yes
# uses pledge()
WANTLIB += c pthread
-MASTER_SITES = https://deftly.net/
+MASTER_SITES = https://deftly.net/dist/
MODULES = lang/go
MODGO_TYPE = bin
@@ -30,5 +28,12 @@ do-install:
${INSTALL_PROGRAM} ${WRKSRC}/bin/* ${PREFIX}/bin
${INSTALL_MAN_DIR} ${PREFIX}/man/man1
${INSTALL_MAN} ${WRKSRC}/man/man1/*.1 ${PREFIX}/man/man1
+ ${INSTALL_DATA_DIR} ${PREFIX}/share/zsh/vendor-completions
+ ${INSTALL_DATA_DIR} ${PREFIX}/share/bash-completion/completions
+ ${INSTALL_DATA} ${WRKSRC}/shell/completion.zsh \
+ ${PREFIX}/share/zsh/vendor-completions/_fzf
+ ${INSTALL_DATA} ${WRKSRC}/shell/completion.bash \
+ ${PREFIX}/share/bash-completion/completions/fzf
+
.include
diff --git a/sysutils/fzf/distinfo b/sysutils/fzf/distinfo
index 5f0ecbdddce..4faae15bb64 100644
--- a/sysutils/fzf/distinfo
+++ b/sysutils/fzf/distinfo
@@ -1,2 +1,2 @@
-SHA256 (fzf-0.17.5.tar.gz) = HKKM5mvQ38zuoo71g5/dAS0riCu5/Rs7bQ1miui52EM=
-SIZE (fzf-0.17.5.tar.gz) = 6413887
+SHA256 (fzf-0.19.0.tar.gz) = i0J6FbKUN3Yfy0REV8o1Q4xeb3jA9nA+JhpGfReD9f0=
+SIZE (fzf-0.19.0.tar.gz) = 2316589
diff --git
a/sysutils/fzf/patches/patch-vendor_github_com_junegunn_fzf_src_protector_protector_openbsd_go
b/sysutils/fzf/patches/patch-vendor_github_com_junegunn_fzf_src_protector_protector_openbsd_go
index 0dc61392f85..3c29980ae48 100644
---
a/sysutils/fzf/patches/patch-vendor_github_com_junegunn_fzf_src_protector_protector_openbsd_go
+++
b/sysutils/fzf/patches/patch-vendor_github_com_junegunn_fzf_src_protector_protector_openbsd_go
@@ -12,5 +12,5 @@ Index:
vendor/github.com/junegunn/fzf/src/protector/protector_openbsd.go
+
+// Protect calls OS specific protections like pledge on OpenBSD
+func Protect(s string) {
-+ unix.Pledge(s, nil)
++ unix.PledgePromises(s)
+}
diff --git a/sysutils/fzf/pkg/PLIST b/sysutils/fzf/pkg/PLIST
index 931641a1d69..3352d9f66a6 100644
--- a/sysutils/fzf/pkg/PLIST
+++ b/sysutils/fzf/pkg/PLIST
@@ -3,3 +3,9 @@
bin/fzf-tmux
@man man/man1/fzf-tmux.1
@man man/man1/fzf.1
+share/bash-completion/
+share/bash-completion/completions/
+share/bash-completion/completions/fzf
+share/zsh/
+share/zsh/vendor-completions/
+share/zsh/vendor-completions/_fzf
--
PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/01/16 10:54:14 Modified files: www: Makefile Log message: link py-flask-cors to the build. Note that it defaults to py3 and doesnt provide a py2 flavor.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/01/16 10:53:08 Log message: Import py-flask-cors 3.0.8. A Flask extension for handling Cross Origin Resource Sharing (CORS), making cross-origin AJAX possible. ok kn@ Status: Vendor Tag: landry Release Tags: landryb_20200116 N ports/www/py-flask-cors/Makefile N ports/www/py-flask-cors/distinfo N ports/www/py-flask-cors/pkg/DESCR N ports/www/py-flask-cors/pkg/PLIST No conflicts created by this import
Re: sysutils/fzf: install shell support files
On 2020/01/16 18:05, Paco Esteban wrote: > Hi Edd, > > On Thu, 16 Jan 2020, Edd Barrett wrote: > > > Hi, > > > > This diff packages the necessary support files for for integrating fzf > > with shells. > > > > With this change, enabling support in (e.g.) zsh is as simple as: > > > > ``` > > export FZF_DEFAULT_OPTS="--ansi" > > . /usr/local/share/fzf/shell/key-bindings.zsh > > . /usr/local/share/fzf/shell/completion.zsh > > ``` > > > > OK? > > On Nov 28, Aaron Bieber sent a patch to update fzf that included > something similar, but it was never imported: > > https://marc.info/?l=openbsd-ports=157496223810600=2 > > I've been using it since with no issues. You may want to take a look > (he did not put the files in the same place). > > Cheers, > > -- > Paco Esteban. > 5818130B8A6DBC03 > We have standard locations for bash/zsh completion files, not every port uses them but the majority do and it would probably make sense to do the same here: /usr/local/share/bash-completion/completions /usr/local/share/zsh/vendor-completions There's no equivalent for key-bindings though.
Re: sysutils/fzf: install shell support files
Hi Edd, On Thu, 16 Jan 2020, Edd Barrett wrote: > Hi, > > This diff packages the necessary support files for for integrating fzf > with shells. > > With this change, enabling support in (e.g.) zsh is as simple as: > > ``` > export FZF_DEFAULT_OPTS="--ansi" > . /usr/local/share/fzf/shell/key-bindings.zsh > . /usr/local/share/fzf/shell/completion.zsh > ``` > > OK? On Nov 28, Aaron Bieber sent a patch to update fzf that included something similar, but it was never imported: https://marc.info/?l=openbsd-ports=157496223810600=2 I've been using it since with no issues. You may want to take a look (he did not put the files in the same place). Cheers, -- Paco Esteban. 5818130B8A6DBC03
Re: [new] bat, a 'cat replacement with wings'
Landry Breuil wrote:
> On Thu, Jan 16, 2020 at 09:18:50AM -0700, Theo de Raadt wrote:
> > Stuart Henderson wrote:
> >
> > > On 2020/01/16 15:29, Landry Breuil wrote:
> > > > Hi,
> > > >
> > > > sent this last year but it wasnt imported due to lack of interest, maybe
> > > > more luck this time... yes, its a rust thing.
> > >
> > > portswise OK if you really think it's worth the build time (20 minutes on
> > > a 3.2GHz xeon when its main feature is something which is already
> > > available
> > > in other ports ..).
> >
> > You gotta be kidding me.
>
> Well, apparently the same rust codebase builds 10 times faster on Linux.
> *shrug*
Even 2 minutes is scandelous . The language/compiler/platform seems
both green ("new and unfinished") and not green ("abusive towards
resources").
Re: [new] bat, a 'cat replacement with wings'
On Thu, Jan 16, 2020 at 09:18:50AM -0700, Theo de Raadt wrote: > Stuart Henderson wrote: > > > On 2020/01/16 15:29, Landry Breuil wrote: > > > Hi, > > > > > > sent this last year but it wasnt imported due to lack of interest, maybe > > > more luck this time... yes, its a rust thing. > > > > portswise OK if you really think it's worth the build time (20 minutes on > > a 3.2GHz xeon when its main feature is something which is already available > > in other ports ..). > > You gotta be kidding me. Well, apparently the same rust codebase builds 10 times faster on Linux. *shrug*
NEW FONTS PORT: jetbrains
This font was designed for development, apparently, as part of an IDE, and they decided to open up the font (Apache 2.0) I played with it a bit and it is indeed pleasant. Fairly straightforward. jetbrains.tgz Description: application/tar-gz
Re: [new] bat, a 'cat replacement with wings'
Stuart Henderson wrote: > On 2020/01/16 15:29, Landry Breuil wrote: > > Hi, > > > > sent this last year but it wasnt imported due to lack of interest, maybe > > more luck this time... yes, its a rust thing. > > portswise OK if you really think it's worth the build time (20 minutes on > a 3.2GHz xeon when its main feature is something which is already available > in other ports ..). You gotta be kidding me.
Re: sysutils/fzf: install shell support files
On Thu, Jan 16, 2020 at 03:49:43PM +, Edd Barrett wrote: > Hi, > > On Thu, Jan 16, 2020 at 08:47:43AM -0600, Matthew Martin wrote: > > On Thu, Jan 16, 2020 at 03:32:36PM +0100, Klemens Nanni wrote: > > > On Thu, Jan 16, 2020 at 02:20:09PM +, Edd Barrett wrote: > > > > > > export FZF_DEFAULT_OPTS="--ansi" > > > > . /usr/local/share/fzf/shell/key-bindings.zsh > > > > . /usr/local/share/fzf/shell/completion.zsh > > > > ``` > > > The usual patterns for zsh are the following > > > > > > /usr/local/share/zsh/vendor-completions/_fzf > > > /usr/local/share/zsh/site-functions/_fzf > > > > At least for zsh /usr/local/share/zsh/site-functions/_fzf should be used > > since it's in the default fpath. Not sure where vendor-completions came > > from; it doesn't occur anywhere in the zsh source. > > It'd be good to know when to use which of these two paths. Our packages > seem to use both: Did a grep of vendor-completions in the ports tree. Some of the usages are from flags specified in the port's Makefile (mpv, khard, exa, google-cloud-sdk, and rclone) and others come from the upstream build (quodlibet, keyringer, zathura, xwallpaper). zathura has since changed to site-functions[1] but updating also requires a girara update. I'll take a look at updating both tonight and the first set of ports if no one beats me to them. 1: https://git.pwmt.org/pwmt/zathura/merge_requests/22 > As you say, only site-functions is in the default fpath... > > Also we have two fzf files to install, so do we concatenate them, or call one > _fzf_bindings and the other _fzf_completions, or does one file go in > each of the above directories? > > Do you have to do anything to have functionality loaded from fpath? I > was expecting these files to be automatically sourced, but it seems they > are not... For completers as long as the file is in fpath when compinit is called and starts with a #compdef line it will be automatically picked up and loaded when needed. Other files need to be autoloaded manually.
Re: [new] bat, a 'cat replacement with wings'
On 2020/01/16 15:29, Landry Breuil wrote: > Hi, > > sent this last year but it wasnt imported due to lack of interest, maybe > more luck this time... yes, its a rust thing. portswise OK if you really think it's worth the build time (20 minutes on a 3.2GHz xeon when its main feature is something which is already available in other ports ..).
Re: sysutils/fzf: install shell support files
On Thu, Jan 16, 2020 at 03:49:43PM +, Edd Barrett wrote: > Do you have to do anything to have functionality loaded from fpath? I > was expecting these files to be automatically sourced, but it seems they > are not... I've just figured out that if you have the completions file in site-functions/_fzf, then you can do: autoload _fzf _fzf and then thinks like ctrl+r work. Perhaps that's how it's supposed to be done. -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: sysutils/fzf: install shell support files
Hi, On Thu, Jan 16, 2020 at 08:47:43AM -0600, Matthew Martin wrote: > On Thu, Jan 16, 2020 at 03:32:36PM +0100, Klemens Nanni wrote: > > On Thu, Jan 16, 2020 at 02:20:09PM +, Edd Barrett wrote: > > > > export FZF_DEFAULT_OPTS="--ansi" > > > . /usr/local/share/fzf/shell/key-bindings.zsh > > > . /usr/local/share/fzf/shell/completion.zsh > > > ``` > > The usual patterns for zsh are the following > > > > /usr/local/share/zsh/vendor-completions/_fzf > > /usr/local/share/zsh/site-functions/_fzf > > At least for zsh /usr/local/share/zsh/site-functions/_fzf should be used > since it's in the default fpath. Not sure where vendor-completions came > from; it doesn't occur anywhere in the zsh source. It'd be good to know when to use which of these two paths. Our packages seem to use both: ``` $ find site-functions site-functions site-functions/_cargo site-functions/_the_silver_searcher site-functions/_rg site-functions/_bspc site-functions/_pulseaudio $ find vendor-completions vendor-completions vendor-completions/_zathura vendor-completions/_mpv ``` As you say, only site-functions is in the default fpath... Also we have two fzf files to install, so do we concatenate them, or call one _fzf_bindings and the other _fzf_completions, or does one file go in each of the above directories? Do you have to do anything to have functionality loaded from fpath? I was expecting these files to be automatically sourced, but it seems they are not... -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: sysutils/fzf: install shell support files
On Thu, Jan 16, 2020 at 03:32:36PM +0100, Klemens Nanni wrote: > On Thu, Jan 16, 2020 at 02:20:09PM +, Edd Barrett wrote: > > Hi, > > > > This diff packages the necessary support files for for integrating fzf > > with shells. > > > > With this change, enabling support in (e.g.) zsh is as simple as: > > > > ``` > > export FZF_DEFAULT_OPTS="--ansi" > > . /usr/local/share/fzf/shell/key-bindings.zsh > > . /usr/local/share/fzf/shell/completion.zsh > > ``` > The usual patterns for zsh are the following > > /usr/local/share/zsh/vendor-completions/_fzf > /usr/local/share/zsh/site-functions/_fzf At least for zsh /usr/local/share/zsh/site-functions/_fzf should be used since it's in the default fpath. Not sure where vendor-completions came from; it doesn't occur anywhere in the zsh source.
Re: sysutils/fzf: install shell support files
On Thu, Jan 16, 2020 at 02:20:09PM +, Edd Barrett wrote: > Hi, > > This diff packages the necessary support files for for integrating fzf > with shells. > > With this change, enabling support in (e.g.) zsh is as simple as: > > ``` > export FZF_DEFAULT_OPTS="--ansi" > . /usr/local/share/fzf/shell/key-bindings.zsh > . /usr/local/share/fzf/shell/completion.zsh > ``` The usual patterns for zsh are the following /usr/local/share/zsh/vendor-completions/_fzf /usr/local/share/zsh/site-functions/_fzf Bash does /usr/local/share/bash-completion/completions/fzf /usr/local/share/bash_completion.d/fzf I don't know which of those should be preferred, though; perhaps go with the most common one across ports? At least I think we should not deviate further from this.
broot, a better filesystem navigator
Because we definitely need more rust things to slow down bulks ? See https://dystroy.org/broot for features, apparently works better if integrated with bash or zsh, havent looked at how to integrate it as a ksh function (cf https://dystroy.org/broot/documentation/installation/##installation-completion-the-br-shell-function) ok ? Landry broot-0.11.9.tgz Description: application/tar-gz
[new] bat, a 'cat replacement with wings'
Hi, sent this last year but it wasnt imported due to lack of interest, maybe more luck this time... yes, its a rust thing. cf https://github.com/sharkdp/bat for features. oks? Landry bat-0.12.1.tgz Description: application/tar-gz
sysutils/fzf: install shell support files
Hi,
This diff packages the necessary support files for for integrating fzf
with shells.
With this change, enabling support in (e.g.) zsh is as simple as:
```
export FZF_DEFAULT_OPTS="--ansi"
. /usr/local/share/fzf/shell/key-bindings.zsh
. /usr/local/share/fzf/shell/completion.zsh
```
OK?
Index: Makefile
===
RCS file: /cvs/ports/sysutils/fzf/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefile12 Jul 2019 20:49:43 - 1.3
+++ Makefile16 Jan 2020 14:12:55 -
@@ -3,6 +3,7 @@
COMMENT = command-line fuzzy finder
DISTNAME = fzf-0.17.5
+REVISION = 0
CATEGORIES = sysutils
@@ -30,5 +31,7 @@ do-install:
${INSTALL_PROGRAM} ${WRKSRC}/bin/* ${PREFIX}/bin
${INSTALL_MAN_DIR} ${PREFIX}/man/man1
${INSTALL_MAN} ${WRKSRC}/man/man1/*.1 ${PREFIX}/man/man1
+ ${INSTALL_DATA_DIR} ${PREFIX}/share/fzf/shell
+ ${INSTALL_DATA} ${WRKSRC}/shell/* ${PREFIX}/share/fzf/shell/
.include
Index: pkg/PLIST
===
RCS file: /cvs/ports/sysutils/fzf/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- pkg/PLIST 12 Jun 2018 00:10:00 - 1.1.1.1
+++ pkg/PLIST 16 Jan 2020 14:13:07 -
@@ -3,3 +3,10 @@
bin/fzf-tmux
@man man/man1/fzf-tmux.1
@man man/man1/fzf.1
+share/fzf/
+share/fzf/shell/
+share/fzf/shell/completion.bash
+share/fzf/shell/completion.zsh
+share/fzf/shell/key-bindings.bash
+share/fzf/shell/key-bindings.fish
+share/fzf/shell/key-bindings.zsh
--
Best Regards
Edd Barrett
http://www.theunixzoo.co.uk
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sol...@cvs.openbsd.org 2020/01/16 07:09:20 Modified files: graphics/grafx2: Makefile Added files: graphics/grafx2/patches: patch-fileformats_c Log message: Fix an issue when saving to png bket@ imported a patch from upstream to address to issue ok fcambus@
Re: py-tables on sparc64 [sparc64 bulk build report]
On Thu, Jan 16, 2020 at 08:37:56AM -0500, Kurt Mosiejczuk wrote: > On Thu, Jan 16, 2020 at 01:26:07PM +, Stuart Henderson wrote: > > No sparc64 to test here but this sort of failure usually is reproducible. > > As this is currently built with base-gcc on sparc64, switching to ports-gcc > > is probably the sanest first step. > > COMPILER= base-clang ports-gcc OK. Just this change makes it finish compiling fairly quickly on my test machine. I ran it again just to be sure because it went through so quickly. --Kurt
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: pam...@cvs.openbsd.org 2020/01/16 06:57:29 Modified files: devel : Makefile Log message: + py-fixtures, + py-linecache2, + py-traceback2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: pam...@cvs.openbsd.org 2020/01/16 06:55:48 Log message: import py-traceback2 A backport of traceback to older supported Pythons. This module provides a standard interface to extract, format and print stack traces of Python programs. It exactly mimics the behavior of the Python interpreter when it prints a stack trace. OK bket phessler Status: Vendor Tag: pamela Release Tags: pamela_20200116 N ports/devel/py-traceback2/Makefile N ports/devel/py-traceback2/distinfo N ports/devel/py-traceback2/pkg/DESCR N ports/devel/py-traceback2/pkg/PLIST No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: pam...@cvs.openbsd.org 2020/01/16 06:53:02 Log message: import py-linecache2 A backport of linecache to older supported Pythons. The linecache module allows one to get any line from a Python source file, while attempting to optimize internally, using a cache, the common case where many lines are read from a single file. OK bket phessler Status: Vendor Tag: pamela Release Tags: pamela_20200116 N ports/devel/py-linecache2/Makefile N ports/devel/py-linecache2/distinfo N ports/devel/py-linecache2/pkg/DESCR N ports/devel/py-linecache2/pkg/PLIST No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: pam...@cvs.openbsd.org 2020/01/16 06:48:34 Log message: import py-fixtures Fixtures defines a Python contract for reusable state / support logic, primarily for unit testing. Helper and adaptation logic is included to make it easy to write your own fixtures using the fixtures contract. OK bket phessler Status: Vendor Tag: pamela Release Tags: pamela_20200116 N ports/devel/py-fixtures/Makefile N ports/devel/py-fixtures/distinfo N ports/devel/py-fixtures/pkg/DESCR N ports/devel/py-fixtures/pkg/PLIST No conflicts created by this import
Re: py-tables on sparc64 [sparc64 bulk build report]
On Thu, Jan 16, 2020 at 01:26:07PM +, Stuart Henderson wrote: > On 2020/01/16 07:21, Martin Reindl wrote: > > On Wed, Jan 15, 2020 at 07:49:43PM -0700, k...@openbsd.org wrote: > > > Bulk build on sparc64-0.ports.openbsd.org > > > Started : Sun Jan 12 23:18:35 MST 2020 > > > Finished: Wed Jan 15 19:48:36 MST 2020 > > > Duration: 2 Days 20 hours 30 minutes > > > Built using OpenBSD 6.6-current (GENERIC.MP) #184: Sat Jan 11 18:58:57 > > > MST 2020 > > > http://build-failures.rhaalovely.net/sparc64/2020-01-12/math/py-tables.log > > Is this reproducible? > No sparc64 to test here but this sort of failure usually is reproducible. > As this is currently built with base-gcc on sparc64, switching to ports-gcc > is probably the sanest first step. > COMPILER= base-clang ports-gcc I actually tried that yesterday as a quick in-place fix. Seemed to hang just the same. But, that was after a rough few days and a long drive. My test machine (without trying ports-gcc) is hung on: building 'tables.hdf5extension' extension cc -Wno-unused-result -Wsign-compare -DNDEBUG -O2 -pipe -fPIC -O2 -pipe -O2 -pipe -O2 -pipe -I/usr/local/include -fPIC -DNDEBUG=1 -DHAVE_LZO2_LIB=1 -DHAVE_BZ2_LIB=1 -DHAVE_BLOSC_LIB=1 -Ihdf5-blosc/src -I/usr/local/lib/python3.7/site-packages/numpy/core/include -I/usr/local/include/python3.7m -c tables/hdf5extension.c -o /usr/ports/pobj/py-tables-3.6.1/tables-3.6.1/temp.openbsd-6.6-sparc64-3.7/tables/hdf5extension.o -O2 -pipe -I/usr/local/include -Isrc -DH5_USE_18_API -DH5Acreate_vers=2 -DH5Aiterate_vers=2 -DH5Dcreate_vers=2 -DH5Dopen_vers=2 -DH5Eclear_vers=2 -DH5Eprint_vers=2 -DH5Epush_vers=2 -DH5Eset_auto_vers=2 -DH5Eget_auto_vers=2 -DH5Ewalk_vers=2 -DH5E_auto_t_vers=2 -DH5Gcreate_vers=2 -DH5Gopen_vers=2 -DH5Pget_filter_vers=2 -DH5Pget_filter_by_id_vers=2 -DH5Tarray_create_vers=2 -DH5Tget_array_dims_vers=2 -DH5Z_class_t_vers=2 In file included from /usr/local/lib/python3.7/site-packages/numpy/core/include/numpy/ndarraytypes.h:1816, from /usr/local/lib/python3.7/site-packages/numpy/core/include/numpy/ndarrayobject.h:18, from /usr/local/lib/python3.7/site-packages/numpy/core/include/numpy/arrayobject.h:4, from tables/hdf5extension.c:611: /usr/local/lib/python3.7/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:15:2: warning: #warning "Using deprecated NumPy API, disable it by " "#defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" tables/hdf5extension.c: In function '__pyx_pf_6tables_13hdf5extension_5Array_4_open_array': tables/hdf5extension.c:18511: warning: comparison between signed and unsigned tables/hdf5extension.c: In function '__pyx_pf_6tables_13hdf5extension_7VLArray_10_read_array': tables/hdf5extension.c:26272: warning: comparison between signed and unsigned I'll try the ports-gcc swap and run it again. --Kurt
Re: py-tables on sparc64 [sparc64 bulk build report]
On 2020/01/16 07:21, Martin Reindl wrote: > On Wed, Jan 15, 2020 at 07:49:43PM -0700, k...@openbsd.org wrote: > > Bulk build on sparc64-0.ports.openbsd.org > > > > Started : Sun Jan 12 23:18:35 MST 2020 > > Finished: Wed Jan 15 19:48:36 MST 2020 > > Duration: 2 Days 20 hours 30 minutes > > > > Built using OpenBSD 6.6-current (GENERIC.MP) #184: Sat Jan 11 18:58:57 MST > > 2020 > > http://build-failures.rhaalovely.net/sparc64/2020-01-12/math/py-tables.log > > Is this reproducible? > > -m > No sparc64 to test here but this sort of failure usually is reproducible. As this is currently built with base-gcc on sparc64, switching to ports-gcc is probably the sanest first step. COMPILER= base-clang ports-gcc
Re: py-tables on sparc64 [sparc64 bulk build report]
On Thu, Jan 16, 2020 at 07:21:00AM +0100, Martin Reindl wrote: > On Wed, Jan 15, 2020 at 07:49:43PM -0700, k...@openbsd.org wrote: > > Bulk build on sparc64-0.ports.openbsd.org > > Started : Sun Jan 12 23:18:35 MST 2020 > > Finished: Wed Jan 15 19:48:36 MST 2020 > > Duration: 2 Days 20 hours 30 minutes > > Built using OpenBSD 6.6-current (GENERIC.MP) #184: Sat Jan 11 18:58:57 MST > > 2020 > > http://build-failures.rhaalovely.net/sparc64/2020-01-12/math/py-tables.log > Is this reproducible? I ended up killing this one. It ended up frozen for hours and hours on a single compilation. I even restarted it more than once. I kicked off a build last night on my test machine to see if I could better reproduce it. --Kurt
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/01/16 05:44:23 Modified files: geo/gdal : Makefile Log message: Bump libgdal minor, enabling hdf5/netcdf added symbols to the lib. Bump REVISION while here. discussed with martin@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/01/16 05:43:26 Modified files: geo/gdal/pkg : PLIST-python Log message: Fix python3 flavor packaging, breakage reported by naddy@
Re: graphics/grafx2 crashes when saving to png
On Wed, Jan 15, 2020 at 03:01:29PM +0100, Solene Rapenne wrote: > > > When I save a picture in png file, from gdb I get the following > > > backtrace. This seems to only happen with png, I tried a few others > > > format (xmp, gif, ico, bmp) and they work fine. > > > > > > Tried on amd64, current > > > > > > Program received signal SIGSEGV, Segmentation fault. > > > Save_PNG_Sub (context=0x7f7d53a8, file=, buffer=0x0, > > > buffer_size=0x0) at fileformats.c:6965 > > > 6965fileformats.c: No such file or directory. > > > (gdb) bt > > > #0 Save_PNG_Sub (context=0x7f7d53a8, file=, > > > buffer=0x0, buffer_size=0x0) at fileformats.c:6965 > > > #1 0x0e642c27bd42 in Save_PNG (context=0x7f7d53a8) at > > > fileformats.c:6981 > > > #2 0x0e642c219716 in Save_image (context=0x7f7d53a8) at > > > loadsave.c:1121 > > > #3 0x0e642c1f5739 in Save_picture (type=CONTEXT_MAIN_IMAGE) at > > > buttons.c:3562 > > > #4 0x0e642c220dfa in Main_handler () at engine.c:1584 > > > #5 0x0e642c1d1300 in main (argc=, argv= > > out>) at main.c:1378 > > > > This issue has been addressed upstream, and a patch is available. Tested > > on amd64. > > > > Lets see what fcambus@ thinks of the diff below. > > it fixes the issue for me :) Works for me as well, thanks! OK fcambus@
Snownews moved to github
Hi folks, just a head up snownews has moved to https://github.com/kouya/snownews. needless to say a version bump would also be greatly appreciated. Thxs!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gonz...@cvs.openbsd.org 2020/01/16 02:55:28 Modified files: www/wp-cli : Makefile distinfo Log message: Update for WP-Cli to 2.4.0: https://github.com/wp-cli/wp-cli/releases OK abieber@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gonz...@cvs.openbsd.org 2020/01/16 02:53:39 Modified files: lang/bacon : Makefile distinfo lang/bacon/patches: patch-Makefile_in Log message: Update for Bacon to 3.9.3 "Si compila OK" juanfra@ (maintainer)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gonz...@cvs.openbsd.org 2020/01/16 02:51:58 Modified files: www/py-yarl: Makefile distinfo www/py-yarl/pkg: PLIST Log message: update for Yarl to 1.4.2: https://github.com/aio-libs/yarl/releases OK jung@ (maintainer)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gonz...@cvs.openbsd.org 2020/01/16 02:49:32 Modified files: net/py-zeroconf: Makefile distinfo net/py-zeroconf/pkg: PLIST Log message: Small update for py3-zeroconf to 0.24.4: https://pypi.org/project/zeroconf/0.24.4/ OK jung@ (maintainer)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gonz...@cvs.openbsd.org 2020/01/16 02:46:58 Modified files: sysutils/gource: Makefile distinfo Log message: Update for Gource to 0.51: https://gource.io/ OK bentley@
Re: New release of SILE, outdated port
Thanks for the feedback Stuart.
The rockspec contains the exact versions of various Luarocks that we
test against and will bundle as vendor code with the install if that
option is used during configure. Since you are going the route of
using OS packages, I should mention that in most cases we actually
support lower versions than are listed there. The exception I know
about is Cassowary which has bug fixes in the latest release that we
count on in SILE. I also have a question mark in my mind about
Penlight, I know we used to test old versions and didn't have a
problem, but when the Luarocks got updated with the Github releases we
stopped testing the old builds. I will look into coming up with actual
bonafide minimum supported versions for future releases.
Speaking of which, I see there is a bug in the configure.ac code in
that it is always expecting a Lua rock for bit32, but technically that
is only needed as a shim for Lua 5.1. It can be dispensed with in
later Luas. Luarocks figures this out but the configure script wasn't
so discerning. I will get that fixed in the next dot release. If it
holds up the port process I can expedite a dot release.
https://github.com/sile-typesetter/sile/pull/779
As for "core" — we are aware of the headache this naming has caused
with autoconf and have been around and around on how to fix it.
Unfortunately it would be pretty involved to rename at this point,
although we haven't completely ruled it out. We've tried various ways
of patching things over with autoconf but that doesn't seem to be
possible. I'm kind of holding off pushing for a fix until it becomes
more clear what way we go for Windows builds. At this point there is a
parallel build system using Cmake just for the Windows builds, but if
that actually pans out it might be smart to converge on one build
system for all platforms, whatever that is. While the jurry is out on
that I haven't wanted to do a disruptive refactoring just to
accommodate a warning message from autoconf.
Again feel free to reach out when / if anybody takes this up and tries
to update it. I'll be happy to provide support including upstream
adjustments if they are needed.
On Wed, Jan 15, 2020 at 5:03 PM Stuart Henderson wrote:
>
> On 2020/01/14 14:03, Caleb Maclennan wrote:
> > I'm one of the developers of The SILE Typesetter
> > (https://sile-typesetter.org). A while back there was some interest in
> > compiling it on BSD (see
> > https://github.com/sile-typesetter/sile/issues/425) and we might have
> > addressed the issues involved in the build system in the release that
> > went out yesterday. I see there is a port
> > (http://openports.se/print/sile) as well but it is even more dated.
> >
> > I would be interested in facilitating any upstream changes that need
> > to be made in order for the BSD process to be as smooth as possible.
> > Is there anything I can do to help get the port updated and/or the use
> > of autoconf and Lua dependencies cleaned up so it works nicely out of
> > the gate?
> >
> > Caleb
> >
>
> I've had a quick look, this will take a while as (based on the versions
> listed in sile-dev-1.rockspec) it looks like it will need 5 modules
> porting and 6 updating. I don't see anything relating to dependencies
> that would need changes upstream, it just needs someone interested in
> running sile on OpenBSD to do the work (they need to be OS packages,
> ports aren't allowed to download during build).
>
> btw the directory in the distribution named "core" makes it a bit
> awkward to read autoconf output:
>
> checking for lua52 module directory... ${exec_prefix}/lib/lua/5.2
> checking if LUA_VERSION is defined... yes
> checking lua.h usability... rm: core: is a directory
> yes
> checking lua.h presence... yes
> checking for lua.h... yes
> checking lualib.h usability... rm: core: is a directory
> yes
> checking lualib.h presence... yes
> checking for lualib.h... yes
> checking lauxlib.h usability... rm: core: is a directory
> yes
> checking lauxlib.h presence... yes
> checking for lauxlib.h... yes
> checking luaconf.h usability... rm: core: is a directory
> yes
> checking luaconf.h presence... yes
> checking for luaconf.h... yes
> checking for Lua header version... rm: core: is a directory
> (etc.).
>
