Re: [NEW/WIP] Qflow porting // [7/7] opensta-20190320

[Alessandro DE LAURENZIS]

Hello Stuart,

On 26/03/2019 11:59, Stuart Henderson wrote:

[...]

I suspect you probably have a symlink for tclsh -> tclsh8.5. The following
is needed to let it build otherwise:

--- Makefile.orig   Tue Mar 26 10:57:14 2019
+++ MakefileTue Mar 26 10:56:23 2019
@@ -32,6 +32,9 @@ CONFIGURE_ARGS = -DTCL_HEADER=${MODTCL_INCDIR}/tcl.h \
  
  NO_TEST =	Yes
  
+pre-configure:

+   cd ${WRKSRC}/etc && ${MODTCL_WISH_ADJ} TclEncode.tcl SwigCleanup.tcl
+
  post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/doc/opensta
${INSTALL_DATA} ${WRKSRC}/doc/OpenSTA.pdf ${PREFIX}/share/doc/opensta

With that added, it's OK sthen@ to import.



You're right, I removed tclsh and wish links to avoid similar issues for 
the future. But while there, maybe it's worth noting that, being both 
TclEncode.tcl and SwigCleanup.tcl run during build, and since they 
launch wish, the following message is displayed:



Application initialization failed: no display name and no $DISPLAY environment 
variable


I don't understand if anything is actually going wrong, since the 
compilation reach the end without problems...


Meanwhile, upstream accepted our patch: patch-etc_SwigCleanup_tcl no 
needed anymore.


Updated tarball attached.

--
Alessandro DE LAURENZIS
[mailto:jus...@atlantide.t28.net]
Web: http://www.atlantide.t28.net
LinkedIn: https://www.linkedin.com/in/delaurenzis/


opensta.tar.gz
Description: application/gzip

Re: graphics/shotwell segfaults on amd64

[Stuart Henderson]

On 2019/03/26 20:25, Josh Grosse wrote:
> I'm trying to figure out a root cause, but am struggling
> because my usual method of preventing stripped modules
> fails when I build shotwell.  Setting $INSTALL_STRIP 
> doesn't have an effect during make fake.
> 
> Size mismatch warnings between libstdc++ and libc++abi occur
> when the application is started, and after displaying thumbnails
> a segfault in libc++abi occurs when the user clicks on any
> thumbnail.
> 
> A console log, backtrace, and dmesg follow.  Any suggestions for capturing
> better data would be appreciated.

> x220$ shotwell
> shotwell:/usr/lib/libstdc++.so.57.0: /usr/lib/libc++abi.so.0.1 : WARNING: 
> symbol(_ZTVN10__cxxabiv120__si_class_type_infoE) size mismatch, relink your 
> program

Well that is very odd, why is it linking libstdc++?
I'm not at all surprised that it's crashing.

graphics/shotwell segfaults on amd64

[Josh Grosse]

I'm trying to figure out a root cause, but am struggling
because my usual method of preventing stripped modules
fails when I build shotwell.  Setting $INSTALL_STRIP 
doesn't have an effect during make fake.

Size mismatch warnings between libstdc++ and libc++abi occur
when the application is started, and after displaying thumbnails
a segfault in libc++abi occurs when the user clicks on any
thumbnail.

A console log, backtrace, and dmesg follow.  Any suggestions for capturing
better data would be appreciated.

Thanks in advance.

--

x220$ shotwell
shotwell:/usr/lib/libstdc++.so.57.0: /usr/lib/libc++abi.so.0.1 : WARNING: 
symbol(_ZTVN10__cxxabiv120__si_class_type_infoE) size mismatch, relink your 
program
shotwell:/usr/lib/libstdc++.so.57.0: /usr/lib/libc++abi.so.0.1 : WARNING: 
symbol(_ZTVN10__cxxabiv120__function_type_infoE) size mismatch, relink your 
program
shotwell:/usr/lib/libstdc++.so.57.0: /usr/lib/libc++abi.so.0.1 : WARNING: 
symbol(_ZTVSt9type_info) size mismatch, relink your program
shotwell:/usr/lib/libstdc++.so.57.0: /usr/lib/libc++abi.so.0.1 : WARNING: 
symbol(_ZTVN10__cxxabiv117__class_type_infoE) size mismatch, relink your program
shotwell:/usr/lib/libstdc++.so.57.0: /usr/lib/libc++abi.so.0.1 : WARNING: 
symbol(_ZTVN10__cxxabiv123__fundamental_type_infoE) size mismatch, relink your 
program
shotwell:/usr/lib/libstdc++.so.57.0: /usr/lib/libc++abi.so.0.1 : WARNING: 
symbol(_ZTVN10__cxxabiv119__pointer_type_infoE) size mismatch, relink your 
program
shotwell:/usr/lib/libstdc++.so.57.0: /usr/lib/libc++abi.so.0.1 : WARNING: 
symbol(_ZTVN10__cxxabiv129__pointer_to_member_type_infoE) size mismatch, relink 
your program
shotwell:/usr/lib/libstdc++.so.57.0: /usr/lib/libc++abi.so.0.1 : WARNING: 
symbol(_ZTVN10__cxxabiv116__enum_type_infoE) size mismatch, relink your program
shotwell:/usr/lib/libstdc++.so.57.0: /usr/lib/libc++abi.so.0.1 : WARNING: 
symbol(_ZTVN10__cxxabiv121__vmi_class_type_infoE) size mismatch, relink your 
program
shotwell:/usr/lib/libstdc++.so.57.0: /usr/lib/libc++abi.so.0.1 : WARNING: 
symbol(_ZTVN10__cxxabiv117__pbase_type_infoE) size mismatch, relink your program
shotwell:/usr/lib/libstdc++.so.57.0: /usr/lib/libc++abi.so.0.1 : WARNING: 
symbol(_ZTVN10__cxxabiv117__array_type_infoE) size mismatch, relink your program

(shotwell:79515): Gtk-1;33mWARNING0m **: 34m19:25:48.0880m: 
gtk_window_present_with_time() should not be called with 0, or GDK_CURRENT_TIME 
as a timestamp, the timestamp should instead be gathered at the time the user 
initiated the request for the window to be shown
Segmentation fault (core dumped)
x220$ egdb /usr/local/bin/shotwell shotwell.core
?1034hGNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-openbsd6.4".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/bin/shotwell...(no debugging symbols 
found)...done.
[New process 593704]
[New process 464506]
[New process 360647]
[New process 124467]
[New process 546624]
[New process 228011]
[New process 387002]
[New process 565161]
[New process 198636]
[New process 184287]
[New process 579951]
[New process 268459]
[New process 615539]
Core was generated by `shotwell'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  is_equal (x=0x137ccba91e80 , 
use_strcmp=false, y=)
at /usr/src/lib/libcxxabi/src/private_typeinfo.cpp:64
64  return x == y;
[Current thread is 1 (process 593704)]
(gdb) bt
#0  is_equal (x=0x137ccba91e80 , 
use_strcmp=false, y=)
at /usr/src/lib/libcxxabi/src/private_typeinfo.cpp:64
#1  __cxxabiv1::__si_class_type_info::has_unambiguous_public_base 
(this=0x137ccba91e80 , info=0x0,
adjustedPtr=0x6, path_below=-878109056) at 
/usr/src/lib/libcxxabi/src/private_typeinfo.cpp:289
#2  0x137d6a060c3f in __cxxabiv1::__dynamic_cast (src_ptr=0x137cee1e0cc0, 
src_type=0x137ccba91e10 ,
dst_type=0x137ccba91e80 , 
src2dst=0)
at 
/usr/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/libsupc++/tinfo.cc:731
#3  0x137ccb9dea59 in 
Exiv2::Internal::TiffSubIfd::doAddChild(std::__1::auto_ptr)
 ()
   from /usr/local/lib/libexiv2.so.11.0
#4  0x137ccb9dd930 in 
Exiv2::Internal::TiffComponent::addChild(std::__1::auto_ptr)
 ()
   from /usr/local/lib/libexiv2.so.11.0
#5  0x137ccb9f721d in 
Exiv2::Internal::TiffReader::visitSubIfd(Exiv2::Internal::TiffSubIfd*) () from 
/usr/local/lib/libexiv2.so.11.0
#6  0x137ccb9df182 in 
Exiv2::In

Re: ocaml fallout (i386): lang/obc

[kwesterback]

I agree.

 Ken

> On Mar 26, 2019, at 2:27 PM, Anil Madhavapeddy  wrote:
> 
> I think this is safe to remove...
> 
>> On 26 Mar 2019, at 18:25, Christopher Zimmermann  wrote:
>> 
>> Hi,
>> 
>> please excuse me for replying so late.
>> This issue is very probably easy to work around.
>> But still I'm wondering whether this is used by anyone.
>> We still ship version 2.9, which only supports i386.
>> According to the homepage version 3.1 will support amd64, too.
>> I would suggest to either update to 3.1 or remove it altogether.
>> 
>> 
>> Christopher
>> 
>> 
>> 
>> This is what the maintainer wrote me in 2015:
>> 
>> On Tue, 24 Feb 2015 22:58:11 +0300
>> Александр Ширяев (Alexander Shiryaev)  wrote:
>> 
 Hi,
 
 you are listed as maintainer of the obc port. Do you know whether
 this is still used by anyone. If yes, I would try and upgrade it.
 
 Christopher
 
>>> 
>>> Hi, Christopher.
>>> 
>>> I do not know who uses it.
>>> 
>>> I made a patch.
>>> 
>>> There is much more interesting, what I use now instead:
>>> https://github.com/aixp/BlackBox
>>> 
>>> Best regards, Alexander.
>> 
>> 
>> 
>> 
>> On Sun, 10 Mar 2019 14:51:34 +
>> Stuart Henderson  wrote:
>> 
>>> ocamlc -g -c -o error.cmo error.ml
>>> File "error.ml", line 223, characters 10-21:
>>> Warning 3: deprecated: Stdlib.String.copy
>>> File "error.ml", line 224, characters 30-59:
>>> Warning 3: deprecated: Stdlib.String.set
>>> Use Bytes.set instead.
>>> File "error.ml", line 224, characters 30-31:
>>> Error: This expression has type string but an expression was expected
>>> of type bytes
>>> gmake[1]: *** [Makefile:88: error.cmo] Error 2
>>> 
>>> Full log below:
>>> 
>> Building on i386-2 under lang/obc  
>>> BDEPENDS =
>>> [devel/ocaml-ocamlbuild;x11/lablgtk2;devel/gmake;lang/tcl/8.5;x11/gtksourceview;lang/ocaml]
>>> DIST = [lang/obc:obc-2.9.7.tar.gz] FULLPKGNAME = obc-2.9.7
>>> RDEPENDS = [lang/ocaml;x11/lablgtk2;x11/gtksourceview]
>>> (Junk lock obtained for i386-2 at 1552196950)
>> Running depends in lang/obc at 1552196950  
>>>  last junk was in www/dillo
>>> /usr/sbin/pkg_add -aI -Drepair gtksourceview-2.10.5p5 lablgtk2-2.18.6
>>> ocaml-4.07.1 ocamlbuild-0.12.0 tcl-8.5.19p4 was: /usr/sbin/pkg_add
>>> -aI -Drepair gmake-4.2.1p0 gtksourceview-2.10.5p5 lablgtk2-2.18.6
>>> ocaml-4.07.1 ocamlbuild-0.12.0 tcl-8.5.19p4 /usr/sbin/pkg_add -aI
>>> -Drepair gtksourceview-2.10.5p5 lablgtk2-2.18.6 ocaml-4.07.1
>>> ocamlbuild-0.12.0 tcl-8.5.19p4 New and changed
>>> readme(s): /usr/local/share/doc/pkg-readmes/tcl-8.5 --- +tcl-8.5.19p4
>>> --- You may wish to add /usr/local/lib/tcl/tcl8.5/man
>>> to /etc/man.conf
>> Running show-prepare-results in lang/obc at 1552196989  
>>> ===> lang/obc
>>> ===> obc-2.9.7 depends on: lablgtk2->=2.14.2p1 -> lablgtk2-2.18.6
>>> ===> obc-2.9.7 depends on: ocaml-=4.07.1 -> ocaml-4.07.1
>>> ===> obc-2.9.7 depends on: tcl->=8.5,<8.6 -> tcl-8.5.19p4
>>> ===> obc-2.9.7 depends on: ocamlbuild-* -> ocamlbuild-0.12.0
>>> ===> obc-2.9.7 depends on: gmake-* -> gmake-4.2.1p0
>>> ===> obc-2.9.7 depends on: gtksourceview-* -> gtksourceview-2.10.5p5
>>> ===>  Verifying specs:  X11 Xcomposite Xcursor Xdamage Xext Xfixes Xi
>>> Xinerama Xrandr Xrender atk-1.0 c cairo curses fontconfig freetype
>>> gdk-x11-2.0 gdk_pixbuf-2.0 gio-2.0 glib-2.0 gobject-2.0 gtk-x11-2.0
>>> gtksourceview-2.0 intl m pango-1.0 pangocairo-1.0 pangoft2-1.0
>>> pthread z ===>  found X11.16.1 Xcomposite.4.0 Xcursor.5.0 Xdamage.4.0
>>> Xext.13.0 Xfixes.6.0 Xi.12.1 Xinerama.6.0 Xrandr.7.1 Xrender.6.0
>>> atk-1.0.21809.2 c.95.0 cairo.13.0 curses.14.0 fontconfig.12.0
>>> freetype.29.0 gdk-x11-2.0.2400.0 gdk_pixbuf-2.0.3200.1 gio-2.0.4200.8
>>> glib-2.0.4201.1 gobject-2.0.4200.8 gtk-x11-2.0.2400.0
>>> gtksourceview-2.0.5.0 intl.6.0 m.10.1 pango-1.0.3800.2
>>> pangocairo-1.0.3800.1 pangoft2-1.0.3800.1 pthread.26.1 z.5.0
>>> gmake-4.2.1p0 gtksourceview-2.10.5p5 lablgtk2-2.18.6 ocaml-4.07.1
>>> ocamlbuild-0.12.0 tcl-8.5.19p4 (Junk lock released for i386-2 at
>>> 1552196990) distfiles size=795687
>> Running build in lang/obc at 1552196990  
>>> ===> lang/obc
>>> ===>  Checking files for obc-2.9.7  
>>> `/mnt/distfiles/obc-2.9.7.tar.gz' is up to date.
>>> ===>  Extracting for obc-2.9.7
>>> ===>  Patching for obc-2.9.7
>>> ===>   Applying OpenBSD patch patch-Makefile_in  
>>> Hmm...  Looks like a unified diff to me...
>>> The text leading up to this was:
>>> --
>>> |$OpenBSD: patch-Makefile_in,v 1.3 2016/08/30 11:02:41 jasper Exp $
>>> |--- Makefile.in.origTue Jan 12 19:26:21 2016
>>> |+++ Makefile.inThu Aug 25 11:08:03 2016
>>> --
>>> Patching file Makefile.in using Plan A...
>>> Hunk #1 succeeded at 92.
>>> done
>>> ===>   Applying OpenBSD patch patch-configure  
>>> Hmm...  Looks like a unified diff to me...
>>> The text leading up to this was:
>>> --
>>> |$OpenBSD: patch-configure,v 1.3 2016/08/30 11:02:41 jasper Exp $
>>> 

Re: ocaml fallout (i386): lang/obc

[Anil Madhavapeddy]

I think this is safe to remove...

> On 26 Mar 2019, at 18:25, Christopher Zimmermann  wrote:
> 
> Hi,
> 
> please excuse me for replying so late.
> This issue is very probably easy to work around.
> But still I'm wondering whether this is used by anyone.
> We still ship version 2.9, which only supports i386.
> According to the homepage version 3.1 will support amd64, too.
> I would suggest to either update to 3.1 or remove it altogether.
> 
> 
> Christopher
> 
> 
> 
> This is what the maintainer wrote me in 2015:
> 
> On Tue, 24 Feb 2015 22:58:11 +0300
> Александр Ширяев (Alexander Shiryaev)  wrote:
> 
>>> Hi,
>>> 
>>> you are listed as maintainer of the obc port. Do you know whether
>>> this is still used by anyone. If yes, I would try and upgrade it.
>>> 
>>> Christopher
>>> 
>> 
>> Hi, Christopher.
>> 
>> I do not know who uses it.
>> 
>> I made a patch.
>> 
>> There is much more interesting, what I use now instead:
>> https://github.com/aixp/BlackBox
>> 
>> Best regards, Alexander.
> 
> 
> 
> 
> On Sun, 10 Mar 2019 14:51:34 +
> Stuart Henderson  wrote:
> 
>> ocamlc -g -c -o error.cmo error.ml
>> File "error.ml", line 223, characters 10-21:
>> Warning 3: deprecated: Stdlib.String.copy
>> File "error.ml", line 224, characters 30-59:
>> Warning 3: deprecated: Stdlib.String.set
>> Use Bytes.set instead.
>> File "error.ml", line 224, characters 30-31:
>> Error: This expression has type string but an expression was expected
>> of type bytes
>> gmake[1]: *** [Makefile:88: error.cmo] Error 2
>> 
>> Full log below:
>> 
> Building on i386-2 under lang/obc  
>>   BDEPENDS =
>> [devel/ocaml-ocamlbuild;x11/lablgtk2;devel/gmake;lang/tcl/8.5;x11/gtksourceview;lang/ocaml]
>> DIST = [lang/obc:obc-2.9.7.tar.gz] FULLPKGNAME = obc-2.9.7
>>   RDEPENDS = [lang/ocaml;x11/lablgtk2;x11/gtksourceview]
>> (Junk lock obtained for i386-2 at 1552196950)
> Running depends in lang/obc at 1552196950  
>>   last junk was in www/dillo
>> /usr/sbin/pkg_add -aI -Drepair gtksourceview-2.10.5p5 lablgtk2-2.18.6
>> ocaml-4.07.1 ocamlbuild-0.12.0 tcl-8.5.19p4 was: /usr/sbin/pkg_add
>> -aI -Drepair gmake-4.2.1p0 gtksourceview-2.10.5p5 lablgtk2-2.18.6
>> ocaml-4.07.1 ocamlbuild-0.12.0 tcl-8.5.19p4 /usr/sbin/pkg_add -aI
>> -Drepair gtksourceview-2.10.5p5 lablgtk2-2.18.6 ocaml-4.07.1
>> ocamlbuild-0.12.0 tcl-8.5.19p4 New and changed
>> readme(s): /usr/local/share/doc/pkg-readmes/tcl-8.5 --- +tcl-8.5.19p4
>> --- You may wish to add /usr/local/lib/tcl/tcl8.5/man
>> to /etc/man.conf
> Running show-prepare-results in lang/obc at 1552196989  
>> ===> lang/obc
>> ===> obc-2.9.7 depends on: lablgtk2->=2.14.2p1 -> lablgtk2-2.18.6
>> ===> obc-2.9.7 depends on: ocaml-=4.07.1 -> ocaml-4.07.1
>> ===> obc-2.9.7 depends on: tcl->=8.5,<8.6 -> tcl-8.5.19p4
>> ===> obc-2.9.7 depends on: ocamlbuild-* -> ocamlbuild-0.12.0
>> ===> obc-2.9.7 depends on: gmake-* -> gmake-4.2.1p0
>> ===> obc-2.9.7 depends on: gtksourceview-* -> gtksourceview-2.10.5p5
>> ===>  Verifying specs:  X11 Xcomposite Xcursor Xdamage Xext Xfixes Xi
>> Xinerama Xrandr Xrender atk-1.0 c cairo curses fontconfig freetype
>> gdk-x11-2.0 gdk_pixbuf-2.0 gio-2.0 glib-2.0 gobject-2.0 gtk-x11-2.0
>> gtksourceview-2.0 intl m pango-1.0 pangocairo-1.0 pangoft2-1.0
>> pthread z ===>  found X11.16.1 Xcomposite.4.0 Xcursor.5.0 Xdamage.4.0
>> Xext.13.0 Xfixes.6.0 Xi.12.1 Xinerama.6.0 Xrandr.7.1 Xrender.6.0
>> atk-1.0.21809.2 c.95.0 cairo.13.0 curses.14.0 fontconfig.12.0
>> freetype.29.0 gdk-x11-2.0.2400.0 gdk_pixbuf-2.0.3200.1 gio-2.0.4200.8
>> glib-2.0.4201.1 gobject-2.0.4200.8 gtk-x11-2.0.2400.0
>> gtksourceview-2.0.5.0 intl.6.0 m.10.1 pango-1.0.3800.2
>> pangocairo-1.0.3800.1 pangoft2-1.0.3800.1 pthread.26.1 z.5.0
>> gmake-4.2.1p0 gtksourceview-2.10.5p5 lablgtk2-2.18.6 ocaml-4.07.1
>> ocamlbuild-0.12.0 tcl-8.5.19p4 (Junk lock released for i386-2 at
>> 1552196990) distfiles size=795687
> Running build in lang/obc at 1552196990  
>> ===> lang/obc
>> ===>  Checking files for obc-2.9.7  
>> `/mnt/distfiles/obc-2.9.7.tar.gz' is up to date.
>> ===>  Extracting for obc-2.9.7
>> ===>  Patching for obc-2.9.7
>> ===>   Applying OpenBSD patch patch-Makefile_in  
>> Hmm...  Looks like a unified diff to me...
>> The text leading up to this was:
>> --
>> |$OpenBSD: patch-Makefile_in,v 1.3 2016/08/30 11:02:41 jasper Exp $
>> |--- Makefile.in.origTue Jan 12 19:26:21 2016
>> |+++ Makefile.in Thu Aug 25 11:08:03 2016
>> --
>> Patching file Makefile.in using Plan A...
>> Hunk #1 succeeded at 92.
>> done
>> ===>   Applying OpenBSD patch patch-configure  
>> Hmm...  Looks like a unified diff to me...
>> The text leading up to this was:
>> --
>> |$OpenBSD: patch-configure,v 1.3 2016/08/30 11:02:41 jasper Exp $
>> |--- configure.orig  Tue Jan 12 19:26:22 2016
>> |+++ configure   Thu Aug 25 11:08:03 2016
>> --
>> Patching file configure using Plan A...
>> Hunk #1 succeeded at 369

net/py-slixmpp optional deps

[Jeremie Courreges-Anglas]

Hi,

py-slixmpp failed to build in the last sparc64 bulk:

  http://build-failures.rhaalovely.net//sparc64/2019-03-04/net/py-slixmpp.log

This can be reproduced on clang archs if both libidn and py3-cython are
installed.

The diff below adds the optional deps and the paths to /usr/local to
solve the build error.  Upstream says:

  Building

  Slixmpp can make use of cython to improve performance on critical
  modules. To do that, cython3 is necessary along with libidn headers.
  Otherwise, no compilation is needed.

make test doesn't show a performance improvement but maybe that's not
the point of a testsuite.

I should add that I have no idea whether python's "stringprep" and
libidn(1) are functionally equivalent.  If you prefer to disable cython
support instead then setup.py needs a patch.

Thoughts?


Index: Makefile
===
RCS file: /cvs/ports/net/py-slixmpp/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- Makefile7 Feb 2019 21:31:32 -   1.11
+++ Makefile26 Mar 2019 15:03:43 -
@@ -3,6 +3,7 @@
 COMMENT =  slixmpp is an elegant Python library for XMPP
 
 MODPY_EGG_VERSION =1.4.2
+REVISION = 0
 DISTNAME = slixmpp-${MODPY_EGG_VERSION}
 PKGNAME =  py3-${DISTNAME}
 CATEGORIES =   net
@@ -12,6 +13,8 @@ MAINTAINER =  Kurt Mosiejczuk 

Re: NEW: m17n (internationalization library)

[Kevin Lo]

On Tue, Mar 26, 2019 at 10:30:40AM +, Stuart Henderson wrote:
> On 2018/12/24 21:32, Eric Brown wrote:
> > Stuart Henderson  writes:
> > 
> > > On 2018/12/24 16:05, Anthony J. Bentley wrote:
> > >> Stuart Henderson writes:
> > >> > - fonts is a better category
> > >> 
> > >> print/ might be better than fonts/; other font-related software exists
> > >> there like fontforge, t1utils, freetype.
> > >> 
> > >> I think it makes sense to just keep actual fonts under fonts/. It looks
> > >> like the only ports under fonts/ that don't actually contain fonts (ttf,
> > >> ttc, pcf, otf, pfb) are mftrace and zh-bg5{ps,pdf}.
> > >> 
> > >
> > > That would make sense too, if mftrace and zh-bg5{ps,pdf} are moved out ..
> > 
> > Thanks all for your comments.  Since I don't see a firm resolution as to
> > where libotf should go, I followed Brian's lead and used devel/libotf.
> > 
> > Also, I propagated your suggestions for libotf through to the other
> > ports, and they pass portcheck and port-lib-depends-check.
> > 
> > Attached are three new archives that have updated ports.
> > 
> > Thanks again,
> > Eric
> > 
> 
> Here's a tweaked version.
> 
> I've refactored the m17n ports into misc/m17n/db and misc/m17n/lib
> because they would normally be updated together and share some common
> build setup.
> 
> m17n-lib was missing various build dependencies which I've explicitly
> added.
> 
> Attached as one file.  Any comments/OKs?

Looks good and tested on amd64.  ok kevlo@

Re: [NEW/WIP] Qflow porting // [7/7] opensta-20190320

[Stuart Henderson]

On 2019/03/26 08:22, Alessandro DE LAURENZIS wrote:
> Hello Stuart,
> 
> On 22/03/2019 19:26, Stuart Henderson wrote:
> > On 2019/03/22 16:29, Alessandro DE LAURENZIS wrote:
> > > My main concern with the port is related to the license; although it is
> > > clear that the software is released under the GPLv3, as confirmed by all
> > > source code file headers, I'm puzzled; the README.md ends as follows:
> > > 
> > > > ## License
> > > > 
> > > > Copyright (c) 2019, Parallax Software, Inc.
> > > > All rights reserved.
> > > > 
> > > > No part of this document may be copied, transmitted or
> > > > disclosed in any form or fashion without the express
> > > > written consent of Parallax Software, Inc.
> > > 
> > > What do you think?
> > 
> > odd. can you ask upstream about that please?
> > 
> 
> I flagged the problem upstream and they promptly amended the Copyright
> notice (they use some filter to extract the open source version from the
> proprietary one, see [1]).

Great!

> Updated tarball attached; note that I have added:
> 
> COMPILER = base-clang ports-gcc base-gcc
> 
> since this is C++11
> 
> Also, reported the reinterpret_cast issue upstream [2] to see if it is
> possible to remove the only patch we currently require (this should not
> prevent to import, though).
> 
> [1] https://github.com/abk-openroad/OpenSTA/issues/17
> 
> [2] https://github.com/abk-openroad/OpenSTA/issues/20
> 
> -- 
> Alessandro DE LAURENZIS
> [mailto:jus...@atlantide.t28.net]
> Web: http://www.atlantide.t28.net
> LinkedIn: https://www.linkedin.com/in/delaurenzis/

I suspect you probably have a symlink for tclsh -> tclsh8.5. The following
is needed to let it build otherwise:

--- Makefile.orig   Tue Mar 26 10:57:14 2019
+++ MakefileTue Mar 26 10:56:23 2019
@@ -32,6 +32,9 @@ CONFIGURE_ARGS = -DTCL_HEADER=${MODTCL_INCDIR}/tcl.h \
 
 NO_TEST =  Yes
 
+pre-configure:
+   cd ${WRKSRC}/etc && ${MODTCL_WISH_ADJ} TclEncode.tcl SwigCleanup.tcl
+
 post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/doc/opensta
${INSTALL_DATA} ${WRKSRC}/doc/OpenSTA.pdf ${PREFIX}/share/doc/opensta

With that added, it's OK sthen@ to import.

Re: NEW: m17n (internationalization library)

[Stuart Henderson]

On 2018/12/24 21:32, Eric Brown wrote:
> Stuart Henderson  writes:
> 
> > On 2018/12/24 16:05, Anthony J. Bentley wrote:
> >> Stuart Henderson writes:
> >> > - fonts is a better category
> >> 
> >> print/ might be better than fonts/; other font-related software exists
> >> there like fontforge, t1utils, freetype.
> >> 
> >> I think it makes sense to just keep actual fonts under fonts/. It looks
> >> like the only ports under fonts/ that don't actually contain fonts (ttf,
> >> ttc, pcf, otf, pfb) are mftrace and zh-bg5{ps,pdf}.
> >> 
> >
> > That would make sense too, if mftrace and zh-bg5{ps,pdf} are moved out ..
> 
> Thanks all for your comments.  Since I don't see a firm resolution as to
> where libotf should go, I followed Brian's lead and used devel/libotf.
> 
> Also, I propagated your suggestions for libotf through to the other
> ports, and they pass portcheck and port-lib-depends-check.
> 
> Attached are three new archives that have updated ports.
> 
> Thanks again,
> Eric
> 

Here's a tweaked version.

I've refactored the m17n ports into misc/m17n/db and misc/m17n/lib
because they would normally be updated together and share some common
build setup.

m17n-lib was missing various build dependencies which I've explicitly
added.

Attached as one file.  Any comments/OKs?

$ tar tzf /tmp/libotf-m17n.tgz
devel/libotf
devel/libotf/Makefile
devel/libotf/distinfo
devel/libotf/pkg
devel/libotf/pkg/DESCR
devel/libotf/pkg/PLIST
misc/m17n
misc/m17n/lib
misc/m17n/lib/Makefile
misc/m17n/lib/distinfo
misc/m17n/lib/patches
misc/m17n/lib/patches/patch-configure
misc/m17n/lib/patches/patch-example_Makefile_in
misc/m17n/lib/pkg
misc/m17n/lib/pkg/DESCR
misc/m17n/lib/pkg/PLIST
misc/m17n/db
misc/m17n/db/Makefile
misc/m17n/db/distinfo
misc/m17n/db/pkg
misc/m17n/db/pkg/DESCR
misc/m17n/db/pkg/PLIST
misc/m17n/Makefile
misc/m17n/Makefile.inc



libotf-m17n.tgz
Description: application/tar-gz

Re: [update] py-attrs-18.2.0

[Stuart Henderson]

On 2019/03/25 21:32, Daniel Jakots wrote:
> On Tue, 26 Mar 2019 01:20:00 +, Stuart Henderson
>  wrote:
> 
> > > > Here is a diff to bump devel/py-attrs version. This is required
> > > > for yle-dl update.  
> > 
> > You were lucky and got away with it with that one, but plists for
> > python ports should be updated with FLAVOR=python3.
> 
> What do you mean?

Regenerating the plist with py3 now I get this.

$ FLAVOR=python3 make plist
===>  Updating plist for py3-attrs-18.2.0
Reading existing plist for py3-attrs-18.2.0
Scanning /usr/obj/ports/py-attrs-18.2.0-python3/fake-amd64-python3
Figuring out tie points
Tieing loose objects
Copying objects
Stripping directories from devel/py-setuptools,python3
Stripping directories from lang/python/3.6,-main
Stripping directories from devel/gettext
Stripping directories from converters/libiconv
Stripping directories from archivers/bzip2
Stripping directories from databases/sqlite3
Stripping directories from devel/libffi
Stripping directories from archivers/xz
/usr/ports/devel/py-attrs/pkg/PLIST changed
$ acvs di
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/py-attrs/pkg/PLIST,v
retrieving revision 1.3
diff -u -p -r1.3 PLIST
--- pkg/PLIST   26 Mar 2019 00:57:17 -  1.3
+++ pkg/PLIST   26 Mar 2019 07:29:29 -
@@ -1,29 +1,29 @@
 @comment $OpenBSD: PLIST,v 1.3 2019/03/26 00:57:17 danj Exp $
 lib/python${MODPY_VERSION}/site-packages/attr/
 lib/python${MODPY_VERSION}/site-packages/attr/__init__.py
+lib/python${MODPY_VERSION}/site-packages/attr/__init__.pyi
 ${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/attr/${MODPY_PYCACHE}/
 
lib/python${MODPY_VERSION}/site-packages/attr/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/attr/__init__.pyi
-lib/python${MODPY_VERSION}/site-packages/attr/_compat.py
 
lib/python${MODPY_VERSION}/site-packages/attr/${MODPY_PYCACHE}_compat.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/attr/_config.py
 
lib/python${MODPY_VERSION}/site-packages/attr/${MODPY_PYCACHE}_config.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/attr/_funcs.py
 
lib/python${MODPY_VERSION}/site-packages/attr/${MODPY_PYCACHE}_funcs.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/attr/_make.py
 
lib/python${MODPY_VERSION}/site-packages/attr/${MODPY_PYCACHE}_make.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/attr/converters.py
 
lib/python${MODPY_VERSION}/site-packages/attr/${MODPY_PYCACHE}converters.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/attr/${MODPY_PYCACHE}exceptions.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/attr/${MODPY_PYCACHE}filters.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/attr/${MODPY_PYCACHE}validators.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/attr/_compat.py
+lib/python${MODPY_VERSION}/site-packages/attr/_config.py
+lib/python${MODPY_VERSION}/site-packages/attr/_funcs.py
+lib/python${MODPY_VERSION}/site-packages/attr/_make.py
+lib/python${MODPY_VERSION}/site-packages/attr/converters.py
 lib/python${MODPY_VERSION}/site-packages/attr/converters.pyi
 lib/python${MODPY_VERSION}/site-packages/attr/exceptions.py
-lib/python${MODPY_VERSION}/site-packages/attr/${MODPY_PYCACHE}exceptions.${MODPY_PYC_MAGIC_TAG}pyc
 lib/python${MODPY_VERSION}/site-packages/attr/exceptions.pyi
 lib/python${MODPY_VERSION}/site-packages/attr/filters.py
-lib/python${MODPY_VERSION}/site-packages/attr/${MODPY_PYCACHE}filters.${MODPY_PYC_MAGIC_TAG}pyc
 lib/python${MODPY_VERSION}/site-packages/attr/filters.pyi
 lib/python${MODPY_VERSION}/site-packages/attr/py.typed
 lib/python${MODPY_VERSION}/site-packages/attr/validators.py
-lib/python${MODPY_VERSION}/site-packages/attr/${MODPY_PYCACHE}validators.${MODPY_PYC_MAGIC_TAG}pyc
 lib/python${MODPY_VERSION}/site-packages/attr/validators.pyi
 
lib/python${MODPY_VERSION}/site-packages/attrs-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
 
lib/python${MODPY_VERSION}/site-packages/attrs-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO

It was only an ordering change in this case, but in many ports
regenerating the plist without setting FLAVOR will break them.

(I know you know this danj, just want to make it clear for readers
on ports@).

Re: [NEW/WIP] Qflow porting // [7/7] opensta-20190320

[Alessandro DE LAURENZIS]

Hello Stuart,

On 22/03/2019 19:26, Stuart Henderson wrote:

On 2019/03/22 16:29, Alessandro DE LAURENZIS wrote:

My main concern with the port is related to the license; although it is
clear that the software is released under the GPLv3, as confirmed by all
source code file headers, I'm puzzled; the README.md ends as follows:


## License

Copyright (c) 2019, Parallax Software, Inc.
All rights reserved.

No part of this document may be copied, transmitted or
disclosed in any form or fashion without the express
written consent of Parallax Software, Inc.


What do you think?


odd. can you ask upstream about that please?



I flagged the problem upstream and they promptly amended the Copyright 
notice (they use some filter to extract the open source version from the 
proprietary one, see [1]).


Updated tarball attached; note that I have added:

COMPILER = base-clang ports-gcc base-gcc

since this is C++11

Also, reported the reinterpret_cast issue upstream [2] to see if it is 
possible to remove the only patch we currently require (this should not 
prevent to import, though).


[1] https://github.com/abk-openroad/OpenSTA/issues/17

[2] https://github.com/abk-openroad/OpenSTA/issues/20

--
Alessandro DE LAURENZIS
[mailto:jus...@atlantide.t28.net]
Web: http://www.atlantide.t28.net
LinkedIn: https://www.linkedin.com/in/delaurenzis/


opensta.tar.gz
Description: application/gzip