Re: package conflicts to fix or process somehow
Hi,
Am Samstag, September 15, 2018 12:12 CEST, Marc Espie schrieb:
> (resend, something burped on the first try, I can't find it in the archives)
>
> The python stuff seems to be files to rename or remove.
>
> Chicken and mono do install stuff that's WAY too short.
>
> The rest, well, that's for maintainer to decide.
>
> Anyway, those are unregistered conflicts right now.
>
> If not fixed soon, they should be marked as conflicting.
>
> cmark-0.28.3(textproc/cmark),py-commonmark-0.7.4(textproc/py-commonmark)
> /usr/local/bin/cmark
I'm looking into py-commonmark, which has this in the post-install:
post-install:
for i in ${PREFIX}/bin/*; do \
mv $${i} $${i}${MODPY_BIN_SUFFIX} ;\
done
Is the MODPY_BIN_SUFFIX gone?
This port only installs python3 FLAVOR, and it's the only binary that goes
to ${PREFIX}/bin, so should be easy to rename the 'cmark' to 'commonmark'
to resolve the conflict.
Just wanted to know if I didn't miss anything with regard to the
MODPY_BIN_SUFFIX?
On an a bit older box, cmark installs as cmark-3
cheers,
Sebastian
Re: backuppc FastCgiExternalServer error on apache2
On Sat, Sep 15, 2018 at 12:23:54PM -0400, Maarten Lippmann wrote:
>
> > > 1. there is a full dependency of the current backuppc package in ports on
> > > samba, even if your backups are only tar or rsync based.
> > > The backuppc process won't run if it can't find
> > > /usr/local/bin/smbclient.
> > > We should really add samba to the backuppc package dependencies as a
> > > result.
> > No, look at the Makefile:
> >
> > # XXX one of them needed as runtime dep... buildep to get them found by
> > # configure
> > BUILD_DEPENDS = archivers/gtar \
> > net/samba \
> > net/rsync \
> > devel/p5-File-RsyncP
> >
> > What if you dont want to backup windows clients ? you dont need samba
> > dependency.
> I based my statement on below error when starting BackupPC:
> # /usr/local/bin/BackupPC
> 2018-09-15 11:59:15 $Conf{NmbLookupPath} = '/usr/local/bin/nmblookup' is not
> a valid executable program
>
> However, you are absolutely right, this error only happens if
> $Conf{SmbClientPath}
> and
> $Conf{NmbLookupPath}
> are uncommented. Which they are by default in the /etc/backuppc/config.pl
> that comes with the package.
> If we care to improve this so backupc just runs after installation without
> samba, a potential change would be to have these lines commented out in the
> installer package and add a comment to
> /usr/local/share/doc/pkg-readmes
> explaining a need to uncomment these (and obviously get the samba package)
> in case smb based backups are desired.
Yes, that seems to be the reasonable thing to do. Comment out those
lines in the default config, and amend the README. Among the other
improvements you're planning :)
[NEW] devel/py-arrow 0.12.1 (cookiecutter porting cont.)
== Arrow is a lightweight library which makes working with dates and times simpler. This is done by including an API which supports many common scenarios. Arrow can also easily generate time span, ranges and more while being a drop in replacement for the standard datetime module. == This is required for the cookiecutter project I am porting. - Tests require py-chai, which I also submitted back on Aug 31, 2018, and all pass for both python 2 and 3. - Package builds successfully on amd64 for both py2 and 3. - Only missing dependency is py-chai mentioned above. Can this be merged please? Thank you, -- Edward Lopez-Acosta py-arrow-0.12.1.tar.gz Description: application/gzip
new: net/go-ipfs
Hi all.
Please find the attached port of go-ipfs [0].
Also attached is a patch to infrastructure/db/user.list
to reserve a uid/gid for _ipfs.
I'm running an ipfs node at home and pinned a "Hello, OpenBSD!"
file [1] for you :)
DESCR:
IPFS is a global, versioned, peer-to-peer filesystem. It combines good ideas
from Git, BitTorrent, Kademlia, SFS, and the Web. It is like a single
bittorrent swarm, exchanging git objects. IPFS provides an interface as
simple as the HTTP web, but with permanence built in. You can also mount the
world at /ipfs.
Two questions:
1)
The tar.gz provided by upstream contains files at the root without an go-ipfs
folder. I did the following to unpack everything in WRKDIST instead of in
WRKDIR directly. Is there a better approch to do this?
EXTRACT_ONLY =
post-extract:
mkdir -p ${WRKDIST}
tar xzf "${FULLDISTDIR}/${DISTNAME}${EXTRACT_SUFX}" -C ${WRKDIST}
2)
By default, ipfs creates all files in ~/.ipfs. This can be changed by
specifing IPFS_PATH. Personally I don't like a hidden folder at /var/ipfs/.ipfs
which is why I set IPFS_PATH=/var/ipfs in the rc file.
This requires users of ipfs to always remember to set IPFS_PATH=/var/ipfs
What would you prefer?
2.1) Setting HOME of the _ipfs user to /var/ipfs and have the data
under /var/ipfs/.ipfs.
2.2) Setting IPFS_PATH=/var/ipfs in the rc file and whenever a user wants to
interact with ipfs.
Cheers,
Fabian
[0] https://ipfs.io/
[1] https://gateway.ipfs.io/ipfs/Qmb7s5nUsLvCQDsXymui2bSt9imsQBzEVviaJRrhyzeBUD
diff --git a/infrastructure/db/user.list b/infrastructure/db/user.list
index fc8521ab6fd..db8d79c3ab6 100644
--- a/infrastructure/db/user.list
+++ b/infrastructure/db/user.list
@@ -327,3 +327,4 @@ id usergroup port options
816_libpostal geo/libpostal
817 _netshot _netshotsysutils/netshot
818 _vnu _vnuwww/vnu
+819 _ipfs _ipfs net/go-ipfs
go-ipfs.tar.gz
Description: Binary data
Re: UPDATE news/py-yenc
Looks good to me.
Cheers.
Elias.
2018-09-15 12:03 GMT-03:00 Björn Ketelaars :
> Enclosed a diff for bringing py-yenc to 0.4.0, which is meant to be
> backward compatible with 0.3 [0]. Tested ok with its consumer
> news/sabnzbd, and 'make test' runs successfully on amd64.
>
> - HOMEPAGE gives a 404. Instead use pip
> - Drop MAINTAINER as mails bounce with 'message wasn't delivered to
> osk...@sefirosu.org because the domain sefirosu.org couldn't be found'
> - Drop patches as these have been addressed upstream
>
> ok?
>
> [0] https://bitbucket.org/dual75/yenc/overview
>
>
> diff --git Makefile Makefile
> index c7d3be8b0d8..10c8dd350c2 100644
> --- Makefile
> +++ Makefile
> @@ -2,26 +2,21 @@
>
> COMMENT= yEnc encoding/decoding extension for Python
>
> -DISTNAME= yenc-0.3
> +MODPY_EGG_VERSION= 0.4.0
> +DISTNAME= yenc-${MODPY_EGG_VERSION}
> PKGNAME= py-${DISTNAME}
> -REVISION = 5
> CATEGORIES=news
>
> -HOMEPAGE= http://www.hellanzb.com/
> -MASTER_SITES= ${HOMEPAGE}hellanzb-content/
> -
> -MAINTAINER=Mikko Tolmunen
> -
> # GPLv2
> PERMIT_PACKAGE_CDROM= Yes
>
> -MODULES= lang/python
> -
> WANTLIB= pthread ${MODPY_WANTLIB}
>
> -TEST_DEPENDS= news/py-yenc
> +MODULES= lang/python
> +MODPY_PI= Yes
> +MODPY_SETUPTOOLS= Yes
>
> -CFLAGS+= -g -O2
> +TEST_DEPENDS= news/py-yenc
>
> post-install:
> ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/py-yenc
> diff --git distinfo distinfo
> index f47bd36b3fb..0ed668472d5 100644
> --- distinfo
> +++ distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (yenc-0.3.tar.gz) = +wT+p8WCE0Vgj6AXKM5TVrbfstPkaeWeP9MbiPRfsxM=
> -SIZE (yenc-0.3.tar.gz) = 42740
> +SHA256 (yenc-0.4.0.tar.gz) = LCSiSdYnr4zhylpLW9I3o0tshZ9x9V8LCe02n3Sf1Nk=
> +SIZE (yenc-0.4.0.tar.gz) = 64237
> diff --git patches/patch-setup_py patches/patch-setup_py
> deleted file mode 100644
> index af615d499ea..000
> --- patches/patch-setup_py
> +++ /dev/null
> @@ -1,11 +0,0 @@
> -$OpenBSD: patch-setup_py,v 1.1.1.1 2007/12/17 00:57:35 merdely Exp $
> setup.py.orig Fri Dec 14 06:50:56 2007
> -+++ setup.py Fri Dec 14 06:51:30 2007
> -@@ -38,6 +38,6 @@ setup(
> - license = "GPL",
> - package_dir = { '': 'lib' },
> - py_modules = ["yenc"],
> -- ext_modules =
> [Extension("_yenc",["src/_yenc.c"],extra_compile_args=["-O2","-g"])]
> -+ ext_modules = [Extension("_yenc",["src/_yenc.c"])]
> - )
> -
> diff --git patches/patch-test_test_py patches/patch-test_test_py
> deleted file mode 100644
> index f009533d0dd..000
> --- patches/patch-test_test_py
> +++ /dev/null
> @@ -1,11 +0,0 @@
> test/test.py.orig Thu Feb 19 01:11:46 2004
> -+++ test/test.py Tue Dec 11 19:36:46 2007
> -@@ -32,7 +32,7 @@ from binascii import crc32
> - from stat import *
> -
> - def main():
> -- os.system("dd if=/dev/urandom of=sampledata bs=1M count=1")
> -+ os.system("dd if=/dev/urandom of=sampledata bs=1048576 count=1")
> - file_in = open("sampledata","r")
> - file_out = open("sampledata.out","w")
> - data = file_in.read()
> diff --git pkg/PLIST pkg/PLIST
> index 07c9a77664a..74b5626aea2 100644
> --- pkg/PLIST
> +++ pkg/PLIST
> @@ -1,14 +1,19 @@
> @comment $OpenBSD: PLIST,v 1.1.1.1 2007/12/17 00:57:35 merdely Exp $
> lib/python${MODPY_VERSION}/site-packages/_yenc.so
> -lib/python${MODPY_VERSION}/site-packages/yenc-0.3-py${MODPY_VERSION}.egg-info
> +lib/python${MODPY_VERSION}/site-packages/yenc-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
> +lib/python${MODPY_VERSION}/site-packages/yenc-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
> +lib/python${MODPY_VERSION}/site-packages/yenc-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/SOURCES.txt
> +lib/python${MODPY_VERSION}/site-packages/yenc-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/dependency_links.txt
> +lib/python${MODPY_VERSION}/site-packages/yenc-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
> lib/python${MODPY_VERSION}/site-packages/yenc.py
> lib/python${MODPY_VERSION}/site-packages/yenc.pyc
> -share/doc/py-yenc/
> -share/doc/py-yenc/README
> -share/doc/py-yenc/yenc-draft.1.3.txt
> -share/examples/py-yenc/
> -share/examples/py-yenc/logo.ync
> -share/examples/py-yenc/ydecode.py
> -share/examples/py-yenc/ydecode_Decoder.py
> -share/examples/py-yenc/yencode.py
> -share/examples/py-yenc/yencode_Encoder.py
> +share/doc/${MODPY_PY_PREFIX}yenc/
> +share/doc/${MODPY_PY_PREFIX}yenc/README
> +share/doc/${MODPY_PY_PREFIX}yenc/yenc-draft.1.3.txt
> +share/examples/${MODPY_PY_PREFIX}yenc/
> +share/examples/${MODPY_PY_PREFIX}yenc/logo.gif
> +share/examples/${MODPY_PY_PREFIX}yenc/logo.ync
> +share/examples/${MODPY_PY_PREFIX}yenc/ydecode.py
> +share/examples/${MODPY_PY_PREFIX}yenc/ydecode_Decoder.py
> +share/examples/${MODPY_PY_PREFIX}yenc/yencode.py
> +share/
new: lang/solidity
Hi all. Attached is a new port for Solidity [0]. Normaly I use the Solidity compiler from NPM in combination with truffle [1]. However, the version from NPM does not support the SMT solver feature through Z3 or CVC4 which is why i'm interested in a native Solidity compiler package with the SMT solver enabled through math/z3. The attached port is identical to the one in openbsd-wip. I've used this package succesfully in some of my personal projects and played with the SMT solver, too. Everything works as expected so far. DESCR: Solidity is a contract-oriented, high-level language for implementing smart contracts. It was influenced by C++, Python and JavaScript and is designed to target the Ethereum Virtual Machine (EVM). Cheers, Fabian [0] https://solidity.readthedocs.io/en/v0.4.25/ [1] https://truffleframework.com/docs/truffle/overview solidity.tar.gz Description: Binary data
Interest in x11/jgmenu port?
Just found an menu application that is designed to work with x11/tint2 and x11/menu-cache. I think an x11/jgmenu port would add flexibility for those use lightweight WMs. https://github.com/johanmalm/jgmenu It is active and has been adapted by BunsenLabs (continuation of CrunchBang). Upstream mentions he has built in OpenBSD. With x11/menu-cache, and x11/openbox pipe menus, it would provide freedesktop menu integration and do away with manual edits. I submitted a howto on DaemonForums that results in a lightweight desktop. A bare framework of applications is provided in part to provide placeholders in the menu structure. Use of jgmenu would allow a user to start with a largely empty menus and easily customize their build by adding xdg compliant ports. It also could provide a "start" tint2 button to launch a menu, LXDE/MATE/KDE/LXQt style. -- J. Scott Heppler
Re: UPDATE: shells/zsh
On Sat Sep 15, 2018 at 06:37:44PM +0200, Klemens Nanni wrote:
> On Sat, Sep 15, 2018 at 10:04:26AM +0200, Rafael Sadowski wrote:
> > +MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=zsh/} \
> > + http://www.zsh.org/pub/
> Has TLS.
>
Thanks!
Index: Makefile
===
RCS file: /cvs/ports/shells/zsh/Makefile,v
retrieving revision 1.88
diff -u -p -u -p -r1.88 Makefile
--- Makefile21 Apr 2018 09:24:06 - 1.88
+++ Makefile16 Sep 2018 17:03:23 -
@@ -2,7 +2,7 @@
COMMENT= Z shell, Bourne shell-compatible
-V= 5.5.1
+V= 5.6.2
DISTNAME= zsh-$V
CATEGORIES=shells
@@ -10,8 +10,10 @@ MAINTAINER= Pierre-Emmanuel Andre https://www.zsh.org/
-MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=zsh/}
-MASTER_SITES+= http://www.zsh.org/pub/
+MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=zsh/} \
+ https://www.zsh.org/pub/
+
+EXTRACT_SUFX= .tar.xz
# BSD
PERMIT_PACKAGE_CDROM= Yes
@@ -23,15 +25,17 @@ LIB_DEPENDS=converters/libiconv \
AUTOCONF_VERSION=2.69
CONFIGURE_STYLE=autoconf
-CONFIGURE_ENV= CPPFLAGS="-I${LOCALBASE}/include" \
-LDFLAGS="-L${LOCALBASE}/lib"
+CONFIGURE_ENV= CPPFLAGS="-I${LOCALBASE}/include" \
+ LDFLAGS="-L${LOCALBASE}/lib"
+
CONFIGURE_ARGS=--enable-zsh-mem \
--enable-zsh-secure-free \
--enable-maildir-support \
- --with-tcsetpgrp \
+ --enable-function-subdirs \
--enable-multibyte \
--enable-pcre \
- --disable-gdbm
+ --disable-gdbm \
+ --with-tcsetpgrp
SUBST_VARS=V
@@ -42,22 +46,18 @@ TEST_FLAGS= INSTALL_PROGRAM="install -c
INSTALL="install -c" \
TMPPREFIX=${WRKBUILD}/tmp \
TERM=xterm
-EXTFILES= Misc/checkmail Misc/run-help \
- Misc/sticky-note Misc/zcalc \
- Misc/zed Misc/zkbd \
- Calendar/calendar_add Example/cat Example/zless
+
+EXTFILES= Functions/Misc/checkmail Functions/Misc/run-help \
+ Functions/Misc/run-help-ip Functions/Misc/sticky-note \
+ Functions/Misc/zcalc Functions/Misc/zed Functions/Misc/zkbd \
+ Functions/Calendar/calendar_add Functions/Example/cat \
+ Functions/Example/zless Test/ztst.zsh Test/runtests.zsh \
+ Util/reporter Util/check-tmux-state Doc/zsh.texi
pre-configure:
.for i in ${EXTFILES}
sed -i -e "s,/bin/zsh,${TRUEPREFIX}/bin/zsh,g" \
- ${WRKSRC}/Functions/${i}
+ ${WRKSRC}/${i}
.endfor
- @find ${WRKSRC} -name "*.orig" -delete
-
-post-install:
- ${INSTALL_DATA_DIR} ${PREFIX}/share/zsh/$V/scripts/
-
-pre-test:
- rm -f ${WRKDIR}/bin/chgrp
.include
Index: distinfo
===
RCS file: /cvs/ports/shells/zsh/distinfo,v
retrieving revision 1.28
diff -u -p -u -p -r1.28 distinfo
--- distinfo21 Apr 2018 09:24:34 - 1.28
+++ distinfo16 Sep 2018 17:03:23 -
@@ -1,2 +1,2 @@
-SHA256 (zsh-5.5.1.tar.gz) = d0yqieeupfM8MDPL/9k+KHB/crpRSceXCeSObC0u4IA=
-SIZE (zsh-5.5.1.tar.gz) = 4578700
+SHA256 (zsh-5.6.2.tar.xz) = pQvWbAVX6OyjuPok6F0N5TPnddeiLfBC2pBIhiN1Lp4=
+SIZE (zsh-5.6.2.tar.xz) = 3077368
Index: pkg/PLIST
===
RCS file: /cvs/ports/shells/zsh/pkg/PLIST,v
retrieving revision 1.49
diff -u -p -u -p -r1.49 PLIST
--- pkg/PLIST 21 Apr 2018 09:24:06 - 1.49
+++ pkg/PLIST 16 Sep 2018 17:03:23 -
@@ -61,1103 +61,1165 @@ lib/zsh/${V}/zsh/zutil.so
share/zsh/
share/zsh/${V}/
share/zsh/${V}/functions/
-share/zsh/${V}/functions/VCS_INFO_adjust
-share/zsh/${V}/functions/VCS_INFO_bydir_detect
-share/zsh/${V}/functions/VCS_INFO_check_com
-share/zsh/${V}/functions/VCS_INFO_detect_bzr
-share/zsh/${V}/functions/VCS_INFO_detect_cdv
-share/zsh/${V}/functions/VCS_INFO_detect_cvs
-share/zsh/${V}/functions/VCS_INFO_detect_darcs
-share/zsh/${V}/functions/VCS_INFO_detect_fossil
-share/zsh/${V}/functions/VCS_INFO_detect_git
-share/zsh/${V}/functions/VCS_INFO_detect_hg
-share/zsh/${V}/functions/VCS_INFO_detect_mtn
-share/zsh/${V}/functions/VCS_INFO_detect_p4
-share/zsh/${V}/functions/VCS_INFO_detect_svk
-share/zsh/${V}/functions/VCS_INFO_detect_svn
-share/zsh/${V}/functions/VCS_INFO_detect_tla
-share/zsh/${V}/functions/VCS_INFO_formats
-share/zsh/${V}/functions/VCS_INFO_get_cmd
-share/zsh/${V}/functions/VCS_INFO_get_data_bzr
-share/zsh/${V}/functions/VCS_INFO_get_data_cdv
-share/zsh/${V}/functions/VCS_INFO_get_data_cvs
-share/zsh/${V}/functions/VCS_INFO_get_data_darcs
-share/zsh/${V}/functions/VCS_INFO_get_data_fossil
-share/zsh/${V}/functions/VCS_INFO_get_data_git
-share/zsh/${V}/functions/VCS_INFO_get_data_hg
-share/zsh/${V}/functions/VCS_INFO_get_data_mtn
-share/zsh/${V}/functions/VCS_INFO_get_data_p4
-shar
Re: [UPDATE] x11/tint2 16.2 -> 16.6.1
On Sun Sep 16, 2018 at 12:34:47PM -0400, Brian Callahan wrote: > > On 09/16/18 11:37, Heppler, J. Scott wrote: > > In the interim there has been one minor patch that addresses icon > > spacing for executors in vertical panels. FreeBSD bugzilla has no > > reports for code base 16.6. 16.6.1 just addressed a regression in the > > Debian Build code. There may be a newer release tag in the upcoming > > weeks. > > I still think we should get 16.6.1 in though. > Tested with i3 on amd64. Works fine here and detect i3 workspaces. If you want to commit it, ok rsadowski@
Re: [UPDATE] x11/tint2 16.2 -> 16.6.1
On 09/16/18 11:37, Heppler, J. Scott wrote: In the interim there has been one minor patch that addresses icon spacing for executors in vertical panels. FreeBSD bugzilla has no reports for code base 16.6. 16.6.1 just addressed a regression in the Debian Build code. There may be a newer release tag in the upcoming weeks. I still think we should get 16.6.1 in though. ~Brian From an OpenBSD standpoint, the port is cleaner and more intuitive - should be easier to maintain going forward. I also think it is likely that the next release will be very close to the upcoming ports freeze. My intent would be to update the next release tag in 6.5 -Scott H. On Sep 16, 2018: 09:58, Brian Callahan wrote: On 09/05/18 00:56, Heppler, J. Scott wrote: Prior posts had two mistakes with the patchs. The line count was off and the first correction had a typo exampls now corrected to examples. On top of that, I was doing something wrong with cvs diff - the corrected patches were not showing up in the *diff. Runs on my current amd64 openbox wm. Anyway this should be good. Sorry for the noise Works for me too. OK for me if someone wants to commit (or let me know and I'll commit). ~Brian On Aug 30, 2018: 18:46, Brian Callahan wrote: On 08/30/18 00:23, Heppler, J. Scott wrote: After I uploaded the v2 diff, it occurred to me that PKGNAME would not be needed if I used the 16.6.1 tag. The attached diff removes PKGNAME. Builds/Runs -current/amd64 openbox. Scott I think this is right. Though when I ran `make update-patches` one of the patches got regen'd so it'll get committed with that little tweak. Anyone want to give an ok? ~Brian
Re: [UPDATE] x11/tint2 16.2 -> 16.6.1
In the interim there has been one minor patch that addresses icon spacing for executors in vertical panels. FreeBSD bugzilla has no reports for code base 16.6. 16.6.1 just addressed a regression in the Debian Build code. There may be a newer release tag in the upcoming weeks. From an OpenBSD standpoint, the port is cleaner and more intuitive - should be easier to maintain going forward. I also think it is likely that the next release will be very close to the upcoming ports freeze. My intent would be to update the next release tag in 6.5 -Scott H. On Sep 16, 2018: 09:58, Brian Callahan wrote: On 09/05/18 00:56, Heppler, J. Scott wrote: Prior posts had two mistakes with the patchs. The line count was off and the first correction had a typo exampls now corrected to examples. On top of that, I was doing something wrong with cvs diff - the corrected patches were not showing up in the *diff. Runs on my current amd64 openbox wm. Anyway this should be good. Sorry for the noise Works for me too. OK for me if someone wants to commit (or let me know and I'll commit). ~Brian On Aug 30, 2018: 18:46, Brian Callahan wrote: On 08/30/18 00:23, Heppler, J. Scott wrote: After I uploaded the v2 diff, it occurred to me that PKGNAME would not be needed if I used the 16.6.1 tag. The attached diff removes PKGNAME. Builds/Runs -current/amd64 openbox. Scott I think this is right. Though when I ran `make update-patches` one of the patches got regen'd so it'll get committed with that little tweak. Anyone want to give an ok? ~Brian -- J. Scott Heppler Penguin Innovations - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - NOTICE: This e-mail message and any attachments may contain legally privileged and confidential information intended solely for the use of the intended recipients. If you are not an intended recipient, you are hereby notified that you have received this message in error and any review, dissemination, distribution, copying, or other unauthorized use of this email and any attachment is strictly prohibited. If you have received this email in error, please notify the sender immediately and delete the message and any attachments from your system.
Re: package conflicts to fix or process somehow
On Sat, 15 Sep 2018 12:12:42 +0200, Marc Espie wrote:
> py-dtopt-0.1p6(devel/py-dtopt),py3-dtopt-0.1p6(devel/py-dtopt,python3)
> /usr/local/share/doc/py-dtopt/index.txt
Yes, Elias pointed it out, this port should probably be removed (see
Subject: [REMOVE] devel/py-dtopt [2/2])
> py-setuptools_trial-0.6.0(devel/py-setuptools_trial),py3-setuptools_trial-0.6.0(devel/py-setuptools_trial,python3)
> /usr/local/share/doc/python-setuptools_trial/COPYING.SPL.txt
> /usr/local/share/doc/python-setuptools_trial/README.rst
imho there's no point in shipping these files. But if someone
disagrees, feel free to work on a diff :)
Index: Makefile
===
RCS file: /cvs/ports/devel/py-setuptools_trial/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile22 Jun 2018 22:02:09 - 1.1.1.1
+++ Makefile16 Sep 2018 14:45:15 -
@@ -5,6 +5,7 @@ COMMENT=setuptools plugin for unit tes
MODPY_EGG_VERSION= 0.6.0
DISTNAME= setuptools_trial-${MODPY_EGG_VERSION}
PKGNAME= py-${DISTNAME}
+REVISION= 0
CATEGORIES=devel
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/py-setuptools_trial/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- pkg/PLIST 22 Jun 2018 22:02:09 - 1.1.1.1
+++ pkg/PLIST 16 Sep 2018 14:45:15 -
@@ -14,6 +14,6 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/setuptools_trial/${MODPY_PYCACHE}setuptools_trial.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/setuptools_trial/_version.py
lib/python${MODPY_VERSION}/site-packages/setuptools_trial/setuptools_trial.py
-share/doc/python-setuptools_trial/
-share/doc/python-setuptools_trial/COPYING.SPL.txt
-share/doc/python-setuptools_trial/README.rst
+@comment share/doc/python-setuptools_trial/
+@comment share/doc/python-setuptools_trial/COPYING.SPL.txt
+@comment share/doc/python-setuptools_trial/README.rst
Re: [UPDATE] x11/tint2 16.2 -> 16.6.1
On 09/05/18 00:56, Heppler, J. Scott wrote: Prior posts had two mistakes with the patchs. The line count was off and the first correction had a typo exampls now corrected to examples. On top of that, I was doing something wrong with cvs diff - the corrected patches were not showing up in the *diff. Runs on my current amd64 openbox wm. Anyway this should be good. Sorry for the noise Works for me too. OK for me if someone wants to commit (or let me know and I'll commit). ~Brian On Aug 30, 2018: 18:46, Brian Callahan wrote: On 08/30/18 00:23, Heppler, J. Scott wrote: After I uploaded the v2 diff, it occurred to me that PKGNAME would not be needed if I used the 16.6.1 tag. The attached diff removes PKGNAME. Builds/Runs -current/amd64 openbox. Scott I think this is right. Though when I ran `make update-patches` one of the patches got regen'd so it'll get committed with that little tweak. Anyone want to give an ok? ~Brian
Re: [NEW] devel/wabt
On 09/15/18 15:09, Brian Callahan wrote: On 09/03/18 15:54, Brian Callahan wrote: On 09/03/18 15:30, Fabian Raetz wrote: On Fri, Aug 31, 2018 at 05:38:53PM -0400, Brian Callahan wrote: On 08/31/18 12:25, Fabian Raetz wrote: On Fri, Aug 31, 2018 at 02:40:26PM +0200, Raphael Graf wrote: Hi Fabian On 08/31/18 02:00, Fabian Raetz wrote: On Thu, Aug 30, 2018 at 06:49:34PM -0400, Brian Callahan wrote: On 08/30/18 18:35, Brian Callahan wrote: Hi Fabian -- On 08/30/18 17:28, Fabian Raetz wrote: On Thu, Aug 30, 2018 at 05:12:35PM -0400, Brian Callahan wrote: Hi Fabian -- On 08/30/18 16:42, Fabian Raetz wrote: Hi all. i've been using the "WebAssembly Binary Toolkit" lately and thought i create a proper port for it. The port doesn't support running the tests as they require some git submodules including the gtest source. Sadly, my cmake skills are not good enough to make the build system use gtest from ports so i decided against it for the moment. In case you wanna compile a small WebAssembly programm yourself, take a look at https://jameshfisher.com/2017/10/13/webassembly-hello-world.html Cheers, Fabian HOMEPAGE: https://github.com/WebAssembly/wabt DESCR: WABT (we pronounce it "wabbit") is a suite of tools for WebAssembly, including: wat2wasm: translate from WebAssembly text format to the WebAssembly binary format wasm2wat: the inverse of wat2wasm, translate from the binary format back to the text format (also known as a .wat) wasm-objdump: print information about a wasm binary. Similiar to objdump. wasm-interp: decode and run a WebAssembly binary file using a stack-based interpreter wat-desugar: parse .wat text form as supported by the spec interpreter (s-expressions, flat syntax, or mixed) and print "canonical" flat format wasm2c: convert a WebAssembly binary file to a C source and header Is this different from the wabt port I ok'd here? https://marc.info/?l=openbsd-ports&m=152950481400669&w=2 There are some subtle differences. The port I sent is in the category "devel" instead of "lang". Also, I packaged version 1.0.5 where the local patch is already included. DESCR is also slightly different with regards to formating. Otherwise both port are equal :) I changed the DESCR formatting to be different than both of them: --- WABT (we pronounce it "wabbit") is a suite of tools for WebAssembly, including: wat2wasm: translate from WebAssembly text format to the WebAssembly binary format wasm2wat: the inverse of wat2wasm, translate from the binary format back to the text format (also known as a .wat) wasm-objdump: print information about a wasm binary. Similiar to objdump. wasm-interp: decode and run a WebAssembly binary file using a stack-based interpreter wat-desugar: parse .wat text form as supported by the spec interpreter (s-expressions, flat syntax, or mixed) and print "canonical" flat format wasm2c: convert a WebAssembly binary file to a C source and header --- Thanks for your review :) I attached a new tar which integrates your feedback. Some comments inline ... It reads better for my eyes but I guess these things eventually become a matter of opinion. On the more necessary side of things: * the build picks up a -Werror that has to go I patched the CMakeLists.txt. Is there a better way to this? * CMake will pick up re2c if you have it installed so either set -DRUN_RE2C=OFF in CONFIGURE_ARGS or add a BDEP on re2c. Added the BDEP because the option is on by default. re2c is only needed when you make changes to the lexer, I would prefer not to make this a build dependency. Hi. Yes, you're right. Attached is a new tarball which uses the included lexer by adding -DRUN_RE2C=OFF and removed the BUILD_DEPENDS. A few more things, then I think it's ok for import. * Bonus newline at the end of pkg/DESCR * Usually I see COMPILER=base-clang ports-gcc but I don't know how much that matters nowadays * Judging by the CMakeLists.txt, python is only used running the tests, since we are using the prebuilt stuff. So maybe better is to remove the find_package for Python from CMakeLists.txt and then we can get rid of the python MODULE. Hi. I've incorporated your feedback and attached a new tar. Thank you. This version is ok for me. General ping that I have yet to receive an ok for this. And committed. Thanks everyone. ~Brian ~Brian ~Brian Thanks, Fabian ~Brian Thanks, Fabian * It's C++11, so needs a COMPILER line. Done. * It looks for, and finds, python. Do we need to add MODULES=lang/python? There's no MAINTAINER. Either of you want to do it? I would take it and added myself as MAINTAINER if that's ok for Raphael sure.. And now that I think about it, I think I like this living in lang/. devel/ is overloaded, and we can at least justify this one living somewhere el
Re: aarch64 bulk build report
On 2018-09-16, phess...@openbsd.org wrote: > new failures > +failures/lang/rust.log "datasize limit is too low" > resolved failures > [...] This is misleading. Some of these weren't built because they were taken out by the rust failure. -- Christian "naddy" Weisgerber na...@mips.inka.de
[NEW] sysutils/py-analyzemft
Hi, attached is the port of analyzeMFT: a program to parse the MFT files from an NTFS filesystem. Information: $ pkg_info py-analyzemft Information for inst:py-analyzemft-2.0.19 Comment: parse the MFT file from an NTFS filesystem Description: analyzeMFT.py is designed to fully parse the MFT file from an NTFS filesystem and present the results as accurately as possible in multiple formats. Maintainer: Remi Pointel WWW: https://pypi.python.org/pypi/analyzeMFT Ok? Cheers, Remi. py-analyzemft-2.0.19.tar.gz Description: application/gzip
Re: aarch64 bulk build report - lang/rust
On Sun, Sep 16, 2018 at 12:19:04AM -0600, phess...@openbsd.org wrote:
> bulk build on arm64.ports.openbsd.org
> started on Fri Sep 14 15:00:56 MDT 2018
> finished at Sun Sep 16 00:15:15 MDT 2018
> lasted 02D02h14m
> done with kern.version=OpenBSD 6.4-beta (GENERIC.MP) #172: Fri Sep 14
> 10:40:32 MDT 2018
>
> http://build-failures.rhaalovely.net/aarch64/2018-09-14/lang/rust.log
Just to confirm the problem is known.
error: couldn't load codegen backend
"/usr/obj/ports/rust-1.28.0/rustc-bootstrap-aarch64-1.28.0-20180803/lib/rustlib/aarch64-unknown-openbsd/codegen-backends/librustc_codegen_llvm-llvm.so":
"Cannot load specified object"
the bootstrap rustc-bootstrap-aarch64-1.28.0-20180803 used for building
1.28.0 isn't self contained. it needs libc++.so.1.0.
the problem was rustc loads librustc_codegen_llvm-llvm.so at runtime and
this library needs libc++.so. But my bootstrap was built only with
compile-time libraries in consideration... so I missed it. my bad.
The diff for lang/rust 1.29.0 address the problem.
I prefered to generated bootstrap for 1.29 instead of regenerating
bootstrap for 1.28 due to build time on aarch64: I need several days for
building it.
Alternatively, manually adding libc++.so.1.0 under
${WRKSRC}/rustc-bootstrap-aarch64-1.28.0-20180803/lib will workaround
the problem, and let's rust to package, and dependencies to build.
Thanks.
--
Sebastien Marie
