Re: [new] lnav, a log navigator
On Sat, Aug 04, 2018 at 05:30:21PM +0200, Landry Breuil wrote:
> Hi,
>
> here's a quick port for http://lnav.org/, a logfile navigator with
> advanced features (cf http://lnav.org/features/)
> Colors are a bit jumbled here and there but it seems to work fine in
> basic testing.
>
> Landry
I am in interest for such port.
But some remarks:
- several printf("%ld") for time_t. these should be %lld
- the port seems to use sys/queue.h in particular way: it mixes class
and struct. I dunno what would be the effect.
- the test suite of the port failed
--
Sebastien Marie
[UPDATE] games/freeciv 2.6.0
Hi,
update to 2.6 and enable client authentication.
OK?
Christoher
Index: Makefile
===
RCS file: /cvs/ports/games/freeciv/Makefile,v
retrieving revision 1.119
diff -u -p -r1.119 Makefile
--- Makefile29 Jun 2018 22:16:13 - 1.119
+++ Makefile5 Aug 2018 00:21:38 -
@@ -4,13 +4,11 @@ COMMENT-main= Civilization clone for X11
COMMENT-client=Freeciv client
COMMENT-share= shared data files for Freeciv
-VERSION= 2.5.11
+VERSION= 2.6.0
DISTNAME= freeciv-${VERSION}
PKGNAME-main= freeciv-server-${VERSION}
PKGNAME-client=freeciv-client-${VERSION}
PKGNAME-share= freeciv-share-${VERSION}
-REVISION-main= 2
-REVISION-client=1
CATEGORIES=games
@@ -22,15 +20,15 @@ PERMIT_PACKAGE_CDROM= Yes
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=freeciv/}
EXTRACT_SUFX= .tar.bz2
-cWANTLIB += bz2 c crypto curl iconv intl lzma m nghttp2 pthread ssl z
+cWANTLIB += bz2 c crypto curl iconv intl lzma m nghttp2 pthread sqlite3 ssl z
cWANTLIB += ${MODLUA_WANTLIB}
WANTLIB-main += curses readline ${cWANTLIB}
-WANTLIB-client += X11 Xcomposite Xcursor Xdamage Xext Xfixes Xi Xtst
+WANTLIB-client += X11 Xcomposite Xcursor Xdamage Xext Xfixes Xi
WANTLIB-client += Xinerama Xrandr Xrender atk-1.0 atk-bridge-2.0 atspi
WANTLIB-client += cairo cairo-gobject dbus-1 epoxy expat ffi fontconfig
-WANTLIB-client += freetype gdk-3 gdk_pixbuf-2.0 gio-2.0 glib-2.0
+WANTLIB-client += freetype fribidi gdk-3 gdk_pixbuf-2.0 gio-2.0 glib-2.0
WANTLIB-client += gmodule-2.0 gobject-2.0 graphite2 gthread-2.0 gtk-3
WANTLIB-client += harfbuzz pango-1.0 pangocairo-1.0 pangoft2-1.0 pcre
WANTLIB-client += pixman-1 png xcb xcb-render xcb-shm ${cWANTLIB}
@@ -38,12 +36,14 @@ WANTLIB-client += pixman-1 png xcb xcb-r
WANTLIB-share=
MODULES= lang/lua
-MODLUA_VERSION = 5.2
+MODLUA_VERSION = 5.3
BUILD_DEPENDS= devel/gettext-tools
LIB_DEPENDS-main= archivers/xz \
+ databases/sqlite3 \
net/curl
LIB_DEPENDS-client=archivers/xz \
+ databases/sqlite3 \
net/curl \
x11/gtk+3
@@ -71,7 +71,8 @@ CONFIGURE_ENV+= CPPFLAGS="-I${LOCALBASE}
CONFIGURE_ARGS=--with-ggz-client=no \
--enable-mapimg=no \
- --enable-sys-lua
+ --enable-sys-lua \
+ --enable-fcdb=sqlite3
MULTI_PACKAGES=-main -share
Index: distinfo
===
RCS file: /cvs/ports/games/freeciv/distinfo,v
retrieving revision 1.28
diff -u -p -r1.28 distinfo
--- distinfo14 Apr 2018 11:17:04 - 1.28
+++ distinfo5 Aug 2018 00:21:38 -
@@ -1,2 +1,2 @@
-SHA256 (freeciv-2.5.11.tar.bz2) = TJxSaVL+l3y0swK4zPdXmP0GbG3eZw9y9nf+SWQlmq0=
-SIZE (freeciv-2.5.11.tar.bz2) = 40940090
+SHA256 (freeciv-2.6.0.tar.bz2) = fCA5kZjWx9hG/tmmmwLgETSuU0Cjrg+Z0eOAY63myZk=
+SIZE (freeciv-2.6.0.tar.bz2) = 51912466
Index: pkg/PLIST-client
===
RCS file: /cvs/ports/games/freeciv/pkg/PLIST-client,v
retrieving revision 1.17
diff -u -p -r1.17 PLIST-client
--- pkg/PLIST-client29 Jun 2018 22:16:13 - 1.17
+++ pkg/PLIST-client5 Aug 2018 00:21:39 -
@@ -9,6 +9,7 @@
@comment lib/libfreeciv.la
@man man/man6/freeciv-client.6
@man man/man6/freeciv-gtk2.6
+@man man/man6/freeciv-gtk3.22.6
@comment @man man/man6/freeciv-gtk3.6
@man man/man6/freeciv-modpack.6
@comment @man man/man6/freeciv-mp-cli.6
@@ -16,13 +17,55 @@
@comment man/man6/freeciv-mp-gtk3.6
@comment man/man6/freeciv-mp-qt.6
@comment @man man/man6/freeciv-qt.6
+@man man/man6/freeciv-ruledit.6
@comment @man man/man6/freeciv-sdl.6
+@man man/man6/freeciv-sdl2.6
@comment @man man/man6/freeciv-xaw.6
share/appdata/
share/appdata/freeciv-gtk3.appdata.xml
share/appdata/freeciv-mp-gtk3.appdata.xml
share/applications/freeciv-mp-gtk3.desktop
share/applications/freeciv.desktop
+share/freeciv/amplio2/
+share/freeciv/amplio2.tilespec
+share/freeciv/amplio2/activities.png
+share/freeciv/amplio2/activities.spec
+share/freeciv/amplio2/bases.png
+share/freeciv/amplio2/bases.spec
+share/freeciv/amplio2/cities.png
+share/freeciv/amplio2/cities.spec
+share/freeciv/amplio2/explosions.png
+share/freeciv/amplio2/explosions.spec
+share/freeciv/amplio2/fog.png
+share/freeciv/amplio2/fog.spec
+share/freeciv/amplio2/grid.png
+share/freeciv/amplio2/grid.spec
+share/freeciv/amplio2/hills.png
+share/freeciv/amplio2/hills.spec
+share/freeciv/amplio2/maglev.png
+share/freeciv/amplio2/maglev.spec
+share/freeciv/amplio2/mountains.png
+share/freeciv/amplio2/mountains.spec
+share/freeciv/amplio2/nuke.png
+share/freeciv/amplio2/nuke.spec
+share/freeciv/amplio2/ocean.png
+share/freeciv/amplio2/ocean.spec
+share/freeciv/amplio2/select-alpha.png
+share/freeciv/amplio2/select.spec
+share/freeciv/amplio2/terrain1.png
+share
Re: NEW: games/openclonk
Hi ports -- On 06/16/18 00:53, Brian Callahan wrote: Hi ports -- Attached is a new port, games/openclonk. OpenClonk is a tactical action game focusing on controlling Clonks. --- pkg/DESCR: OpenClonk is a free multiplayer action game in which you control Clonks, small but witty and nimble humanoid beings. The game is mainly about mining, settling and fast-paced melees. OpenClonk is not just a game but also a versatile 2D game engine that allows the creation of mods. It is the successor of the shareware game series Clonk and thus inherits many of its features. --- Submitting this on behalf of bentley@, who submitted an older version of this some time ago, which I've used as the basis of this port. Hence, I did not put myself as MAINTAINER in case he wants it (but will add myself if he doesn't). Works for me on amd64. OK? ~Brian Updated tarball attached. Still works for me and is a fun game, I promise :) ~Brian openclonk.tgz Description: Binary data
python types, ino_t and off_t
Hi ports@,
I'm tying to port a python package that uses the dirent struct
defining the fields like this:
_fields_ = (
('d_ino', ctypes.c_uint32), # must be uint32, not ulong
('d_off', ctypes.c_long),
('d_reclen', ctypes.c_ushort),
('d_type', ctypes.c_ubyte),
('d_namlen', ctypes.c_ubyte),
('d_name', ctypes.c_char * 256),
)
Now, aren't ino_t and off_t architecture dependent ? If not, how do I
find the length of each types ?
The others are defined in the dirent description.
If dependent of the architecture, I should find a way of using the
real definitions in python...
Cheers.
Elias.
Re: Stray lines in PLIST
On Sat, Aug 04, 2018 at 12:54:55PM -0300, Elias M. Mariani wrote: > Same doubts here. > Cheers. > Elias. > > 2018-08-04 11:29 GMT-03:00 Alessandro DE LAURENZIS : > > Dear ports@ readers, > > > > working on a new port, I noticed that some stray lines began to appear in > > PLIST: > > > > man/ja_JP.EUC/cat3f/ > > man/ja_JP.EUC/man3f/ > > man/ja_JP.EUC/man3p/ > > > > This has been already reported (see e.g. [1]), but differently from what > > landry@ suggested, my system is up-to-date (-current, 4 Aug snapshot) and > > same my port tree. > > > > Any hints? > > Ah, yep. My bad, should be easy to fix.
Re: [new] lnav, a log navigator
Landry Breuil wrote: > Hi, > > here's a quick port for http://lnav.org/, a logfile navigator with > advanced features (cf http://lnav.org/features/) > Colors are a bit jumbled here and there but it seems to work fine in > basic testing. > > Landry port is OK for me but the software itself doesn't seem stable. I can crash it with the following sequence: $ rm -fr ~/.lnav (to be sure it's clean) $ lnav /var/log/messages $ press F to go at the start of the file $ q to exit, it stays stuck using CPU and must be killed also, the man page gives the example "lnav -s" which isn't even a valid flag of lnav.
Re: www/chromium build time
Christian Weisgerber: > With the update from Chromium 67 to 68, the build time of www/chromium > has exploded and it now determines the overall duration of an amd64 > bulk build. > > I'll try a build with dpb -p instead of the default of > -p. That went quite well. Total build time was a little over 23 hours. chromium itself ended up on the fastest machine, where it took somewhat over 9 hours and finished well before the end of the overall build. Unsurprising observation with -p/1: Hosts get even more overbooked, since parallel jobs end up sharing the host with long-running other builds (ghc, pypy, etc). Probably inefficient, but no ill effects. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Stray lines in PLIST
Same doubts here. Cheers. Elias. 2018-08-04 11:29 GMT-03:00 Alessandro DE LAURENZIS : > Dear ports@ readers, > > working on a new port, I noticed that some stray lines began to appear in > PLIST: > > man/ja_JP.EUC/cat3f/ > man/ja_JP.EUC/man3f/ > man/ja_JP.EUC/man3p/ > > This has been already reported (see e.g. [1]), but differently from what > landry@ suggested, my system is up-to-date (-current, 4 Aug snapshot) and > same my port tree. > > Any hints? > > [1] https://marc.info/?l=openbsd-ports&m=153329716225262&w=2 > > -- > Alessandro DE LAURENZIS > [mailto:jus...@atlantide.t28.net] > Web: http://www.atlantide.t28.net > LinkedIn: http://it.linkedin.com/in/delaurenzis >
Re: [NEW/WIP] Qflow porting // abc
Hi Brian, On 08/04/18 09:13, Brian Callahan wrote: [...] There appear to be stray lines in pkg/PLIST: man/ja_JP.EUC/cat3f/ man/ja_JP.EUC/man3f/ man/ja_JP.EUC/man3p/ But now that I think about it, I've heard reports from other users about `make plist` writing out these lines in other ports too so I'm wondering if something changed recently... but it's late here I'll track it down in the morning if no one else beats me to it. Ooops... I didn't notice that... No idea what's happening. I found this: [1], but my system and port tree are both updated. Sent a separate message to ports@ to help tracking the problem. Thanks for the heads up [1] https://marc.info/?l=openbsd-ports&m=153329716225262&w=2 -- Alessandro DE LAURENZIS [mailto:jus...@atlantide.t28.net] Web: http://www.atlantide.t28.net LinkedIn: http://it.linkedin.com/in/delaurenzis
[new] lnav, a log navigator
Hi, here's a quick port for http://lnav.org/, a logfile navigator with advanced features (cf http://lnav.org/features/) Colors are a bit jumbled here and there but it seems to work fine in basic testing. Landry lnav.tgz Description: application/tar-gz
Re: [NEW] devel/libdivecomputer-subsurface
Hi Kristaps, Kristaps Dzonsons BSD.LV wrote on Fri, Aug 03, 2018 at 01:34:58AM +0200: > Enclosed are both subsurface.tgz See my previous mail, which also contained more changes and also asked for OKs. > and libdivecomputer.tgz, which have the noted change. > (Both are now in misc.) Both tested on amd64. > (I do have a utility that uses libdivecomputer and will submit it soon.) Regarding libdivecomputer, i'm looking for OKs and for confirmation from kristaps@ for the attached version: * License check successfully redone. * Restore the AES removal patches; don't be illegal... * WANTLIB += m according to lib-depends-check and ldd(1). * Move USE_GMAKE up according to Makefile.template ordering. * CONFIGURE_ENV = ac_cv_prog_DOXYGEN=, or it will pick it up. * Do not build HTML documentation, we install mdoc(7) files. * NO_TEST is not needed; there is an empty test infrastructure. * Fix the test for compiler flags in ./configure: for -Wrestrict, clang warns, but exits 0 anyway, resulting in the flag being used, which causes lots of noise in the build log. * With these changes, configure, build, and fake logs look sane. OK? Ingo libdivecomputer.tgz Description: application/tar-gz
Stray lines in PLIST
Dear ports@ readers, working on a new port, I noticed that some stray lines began to appear in PLIST: man/ja_JP.EUC/cat3f/ man/ja_JP.EUC/man3f/ man/ja_JP.EUC/man3p/ This has been already reported (see e.g. [1]), but differently from what landry@ suggested, my system is up-to-date (-current, 4 Aug snapshot) and same my port tree. Any hints? [1] https://marc.info/?l=openbsd-ports&m=153329716225262&w=2 -- Alessandro DE LAURENZIS [mailto:jus...@atlantide.t28.net] Web: http://www.atlantide.t28.net LinkedIn: http://it.linkedin.com/in/delaurenzis
[update] vdirsyncer 0.16.7
Hi,
this is and update for vdirsyncer to version 0.16.7.
It now requires py3-click-log > 0.3.0 (which I sent with my previous mail).
My personal contacts and calendar entries sync fine with it.
OK?
Remi
Index: Makefile
===
RCS file: /cvs/ports/productivity/vdirsyncer/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- Makefile16 Oct 2017 21:41:24 - 1.5
+++ Makefile4 Aug 2018 08:55:32 -
@@ -2,13 +2,13 @@
COMMENT = synchronize calendars and contacts
-MODPY_EGG_VERSION =0.16.3
+MODPY_EGG_VERSION =0.16.7
DISTNAME = vdirsyncer-${MODPY_EGG_VERSION}
CATEGORIES = productivity
HOMEPAGE = https://vdirsyncer.pimutils.org/
-MAINTAINER = Remi Locherer
+MAINTAINER = Remi Locherer
# BSD3
PERMIT_PACKAGE_CDROM = Yes
@@ -24,7 +24,7 @@ BUILD_DEPENDS = textproc/py-sphinx${MOD
${RUN_DEPENDS}
RUN_DEPENDS = devel/py-atomicwrites${MODPY_FLAVOR} \
- devel/py-click-log${MODPY_FLAVOR}>=0.2.0 \
+ devel/py-click-log${MODPY_FLAVOR}>=0.3.0 \
devel/py-click-threading${MODPY_FLAVOR} \
www/py-requests-toolbelt${MODPY_FLAVOR}
Index: distinfo
===
RCS file: /cvs/ports/productivity/vdirsyncer/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo16 Oct 2017 21:41:24 - 1.4
+++ distinfo4 Aug 2018 08:57:40 -
@@ -1,2 +1,2 @@
-SHA256 (vdirsyncer-0.16.3.tar.gz) =
/F9sUiXViLAe4iU1inwJYoOJaiompPAsllHPk6Jb/DY=
-SIZE (vdirsyncer-0.16.3.tar.gz) = 113327
+SHA256 (vdirsyncer-0.16.7.tar.gz) =
bJvPubywEkbIO6b4VRz1TFivMyMhB1VIX8I7t4SFEu8=
+SIZE (vdirsyncer-0.16.7.tar.gz) = 112786
[update] py-click-log 0.3.2
Hi,
this updates py-click-log to version 0.3.2.
vdirsyncer from ports does not work with this. An update for it comes with
my next mail. No other port depends on it.
While here add myself as maintainer
OK?
Remi
Index: Makefile
===
RCS file: /cvs/ports/devel/py-click-log/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- Makefile30 Aug 2017 16:52:13 - 1.2
+++ Makefile4 Aug 2018 10:08:46 -
@@ -2,13 +2,15 @@
COMMENT = logging integration for Python click
-MODPY_EGG_VERSION =0.2.0
+MODPY_EGG_VERSION =0.3.2
DISTNAME = click-log-${MODPY_EGG_VERSION}
PKGNAME = py-${DISTNAME}
CATEGORIES = devel
HOMEPAGE = https://github.com/click-contrib/click-log
+
+MAINTAINER = Remi Locherer
# MIT
PERMIT_PACKAGE_CDROM = Yes
Index: distinfo
===
RCS file: /cvs/ports/devel/py-click-log/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- distinfo30 Aug 2017 16:52:13 - 1.2
+++ distinfo19 Jul 2018 21:47:10 -
@@ -1,2 +1,2 @@
-SHA256 (click-log-0.2.0.tar.gz) = F2oIX6y3726j6y6Zh+yOiwv7nBcxo/OAdGT7EGV3Wa4=
-SIZE (click-log-0.2.0.tar.gz) = 9665
+SHA256 (click-log-0.3.2.tar.gz) = Fv0co/xrFsmM6mOs8atHTqjmdoSdxmnYavr7DtcAMSQ=
+SIZE (click-log-0.3.2.tar.gz) = 9523
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/py-click-log/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- pkg/PLIST 8 Mar 2017 02:40:41 - 1.1.1.1
+++ pkg/PLIST 19 Jul 2018 21:49:03 -
@@ -9,7 +9,7 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/click_log/__init__.py
${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/click_log/${MODPY_PYCACHE}/
lib/python${MODPY_VERSION}/site-packages/click_log/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/click_log/${MODPY_PYCACHE}core.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/click_log/${MODPY_PYCACHE}options.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/click_log/core.py
+lib/python${MODPY_VERSION}/site-packages/click_log/${MODPY_PYCACHE}core.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/click_log/options.py
+lib/python${MODPY_VERSION}/site-packages/click_log/${MODPY_PYCACHE}options.${MODPY_PYC_MAGIC_TAG}pyc
Re: security update: www/git 1.1 to 1.2.1
On Sat, Aug 04, 2018 at 09:16:08AM +0200, Landry Breuil wrote: > And it is fixed by the update, which returns a 400 error code now. Thanks for testing, committed now.
Re: security update: www/git 1.1 to 1.2.1
On Sat, Aug 04, 2018 at 09:10:09AM +0200, Landry Breuil wrote: > On Fri, Aug 03, 2018 at 10:45:46PM +0200, Klemens Nanni wrote: > > 1.2.1 fixes a directory traversal bug: > > https://bugs.chromium.org/p/project-zero/issues/detail?id=1627 > > I've tried exploiting the bug locally and didnt manage to read files > from /var/www, but whatever. cgit still works with the update, so ok. > Whoops, spoke too fast, it is indeed pretty bad: $curl https://fqdn/repo/objects/?path=../../../../etc/resolv.conf And it is fixed by the update, which returns a 400 error code now.
Re: [NEW/WIP] Qflow porting // abc
Hi Alessandro --
On 08/04/18 02:39, Alessandro DE LAURENZIS wrote:
Ciao Brian,
On 08/03/18 21:07, Brian Callahan wrote:
[...]
I used the following comment line, detailing the tools/libs present
in /src and the corresponding licenses:
# MIT (abc, minisat), BSD (bzlib, CUDD), zlib
I'm not sure these are entirely correct? bzlib should be listed under
the zlib license, no? There might be other license marker tweaks
needed so please double check.
Let me explain what I did in order to collect the license info:
[... snip ...]
$ pwd
/usr/ports/pobj/abc-1.01.20180722/abc-ae6716b064c842f45109a88e84dca71fe4cc311f
$ find . -name "*LICENSE*" -o -name "*license*" -o -name "*copy*" -o
-name "*COPY*"
./copyright.txt
./src/bdd/cudd/license
./src/misc/bzlib/LICENSE
./src/misc/zlib/license
./src/sat/bsat/license
./src/sat/bsat2/LICENSE
./src/sat/satoko/LICENSE
./src/sat/xsat/license
[... snip ...]
So, as Stuart noticed, on top of abc itself (released under the MIT
license), there are:
- local copies of CUDD, bzlib and zlib;
- a slightly modified version of MiniSat (bsat, bsat2, released under
the same MIT license);
- xSAT, based on bsat and released under the MIT license;
-satoko, released under the 2-clause BSD license.
CUDD uses the 3-clause BSD license, so I merged it with MiniSat/xSAT
under a generic BSD tag.
bzlib is part of bzip2 and is released under a BSD-style license (not
the zlib one as you guessed).
I did not guess. I read ${WRKSRC}/src/misc/bzlib/LICENSE. Clauses 2 and
3 are identical to the zlib license. But our ports tree also uses a BSD
marker for bzip2 so it's not worth quibbling over. Perhaps "BSD-style"
if we want to be extremely precise but I don't think it matters.
zlib has its own license.
I tweaked a bit the license marker line, hoping it's more complete now:
# MIT (abc, MiniSat, xSAT), BSD (bzlib, CUDD, satoko), zlib
[...]>> do-install target required a tweak in order to take the
executable
from ${WRKDIR}/build-${MACHINE_ARCH}. Should I set SEPARATE_BUILD too?
cmake sets SEPARATE_BUILD for you. Use WRKBUILD instead of that
WRKDIR/build-MACHINE_ARCH thing.
Fixed.
New tarball attached.
There appear to be stray lines in pkg/PLIST:
man/ja_JP.EUC/cat3f/
man/ja_JP.EUC/man3f/
man/ja_JP.EUC/man3p/
But now that I think about it, I've heard reports from other users about
`make plist` writing out these lines in other ports too so I'm wondering
if something changed recently... but it's late here I'll track it down
in the morning if no one else beats me to it.
~Brian
Re: security update: www/git 1.1 to 1.2.1
On Fri, Aug 03, 2018 at 10:45:46PM +0200, Klemens Nanni wrote: > 1.2.1 fixes a directory traversal bug: > https://bugs.chromium.org/p/project-zero/issues/detail?id=1627 I've tried exploiting the bug locally and didnt manage to read files from /var/www, but whatever. cgit still works with the update, so ok.
Re: [NEW/WIP] Qflow porting // [2/7] Yosys
Hi Stuart,
On 08/03/18 17:56, Alessandro DE LAURENZIS wrote:
Hi Stuart,
On 08/03/18 13:21, Stuart Henderson wrote:
On 2018/08/03 12:23, Alessandro DE LAURENZIS wrote:
I think we need the line:
FAKE_FLAGS = PREFIX="${LOCALBASE}"
since PREFIX is explicitly set to /usr/local in upstream Makefile when
undefined.
That should probably be PREFIX="${TRUEPREFIX}"
Fixed
Finally, portcheck gives the following message:
Python module without compiled version, consider using ${MODPY_BIN}
${MODPY_LIBDIR}/compileall.py: share/yosys/python3/smtio.py
cad/yosys
I don't know if it's acceptable (and, if not, how to remove it...)
Python normally creates pyc files for imported modules if the directory
is writable. We pre-create these so that if e.g. someone runs the program
as root, we don't get stray pyc files left behind after uninstall.
You can remove it by using ${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py
to create the pyc file.
Added it in post-install target:
post-install:
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py \
${PREFIX}/share/yosys/python3
- compiler name forced to eg++;
Don't hardcode this, use MAKE_FLAGS= CXX="${CXX}" etc.
Fixed
Different story for kernel/yosys.cc:
- we need to include sys/wait.h;
- code requires the process executable base path; Linux has
/proc/self/exe
and I see that there are solutions for APPLE and WIN32 too; OpenBSD
doesn't
have a ready-to-use function; this is the closest thing that comes to my
mind:
std::string proc_self_dirname()
{
// No direct way to get the process executable base path
char path[PATH_MAX];
ssize_t buflen = sizeof(path);
char *res = realpath(getenv("_"), path);
if (!res) {
log_error("getenv(\"_\") failed: %s\n",strerror(errno));
}
*(strrchr(path, '/')+1) = '\0';
while (buflen > 0 && path[buflen-1] != '/')
buflen--;
return std::string(path, buflen);
}
If you think that's acceptable, I'll submit the patch upstream.
IMO hardcoding the path is the most sensible way for ports.
As discussed (thanks for your explanation), I patched to use ${PREFIX}
and then added:
pre-build:
${SUBST_CMD} ${WRKSRC}/kernel/yosys.cc
pdflatex is used to compile manual, application notes and presentations
during build; it's part of print/texlive_base, which is a large port;
should
we stay with it or do you have alternatives to suggest?
That's not really a problem. If it needs pdflatex, list the dependency.
>> pdflatex is used to compile manual, application notes and
presentations
during build; it's part of print/texlive_base, which is a large port;
should
we stay with it or do you have alternatives to suggest?
That's not really a problem. If it needs pdflatex, list the dependency.
Actually I noticed that the corresponding target isn't run by default.
Should I force it? I mean, is the extra documentation normally installed
in other ports?
New tarball attached.
There is a local copy of MiniSat in ./libs, so I tweaked a bit the
license markers:
# ISC (yosys), MIT (MiniSat)
New tarball attached.
--
Alessandro DE LAURENZIS
[mailto:jus...@atlantide.t28.net]
Web: http://www.atlantide.t28.net
LinkedIn: http://it.linkedin.com/in/delaurenzis
yosys.tar.gz
Description: application/gzip
