[Update] net/qbittorrent 4.3.9 to 4.4.2
Updating net/qbittorrent from 4.3.9 to 4.4.2
Changelog:
https://github.com/qbittorrent/qBittorrent/blob/release-4.4.2/Changelog
Some things got fixed upstream so we don't need that on patches
anymore.
I rearrange the WANTLIB when adding some new lib deps.
Tested OK on amd64.
Asking for OKs because we are near the lock of the tree.
Cheers.
Elias mariani@
Index: Makefile.inc
===
RCS file: /cvs/ports/net/qbittorrent/Makefile.inc,v
retrieving revision 1.20
diff -u -p -r1.20 Makefile.inc
--- Makefile.inc11 Mar 2022 19:47:15 - 1.20
+++ Makefile.inc28 Mar 2022 21:39:46 -
@@ -1,7 +1,7 @@
# qmake picks up gcrypt.h even though it's unused
DPB_PROPERTIES = nojunk
-VER = 4.3.9
+VER = 4.4.2
DISTNAME = qbittorrent-${VER}
DIST_SUBDIR = qbittorrent
Index: qbittorrent/Makefile
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent/Makefile,v
retrieving revision 1.17
diff -u -p -r1.17 Makefile
--- qbittorrent/Makefile11 Mar 2022 19:47:15 - 1.17
+++ qbittorrent/Makefile28 Mar 2022 21:39:46 -
@@ -1,8 +1,8 @@
COMMENT = BitTorrent client with Qt interface
-WANTLIB += ${COMPILER_LIBCXX} Qt5Core Qt5Network Qt5Xml boost_system
-WANTLIB += boost_system-mt c crypto execinfo m ssl torrent-rasterbar z
-WANTLIB += GL Qt5DBus Qt5Gui Qt5Svg Qt5Widgets
+WANTLIB += ${COMPILER_LIBCXX} GL Qt5Core Qt5DBus Qt5Gui Qt5Network
+WANTLIB += Qt5Sql Qt5Svg Qt5Widgets Qt5Xml boost_system-mt c crypto
+WANTLIB += execinfo m ssl torrent-rasterbar z
MODULES = lang/python
Index: qbittorrent/distinfo
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent/distinfo,v
retrieving revision 1.16
diff -u -p -r1.16 distinfo
--- qbittorrent/distinfo15 Dec 2021 22:33:09 - 1.16
+++ qbittorrent/distinfo28 Mar 2022 21:39:46 -
@@ -1,2 +1,2 @@
-SHA256 (qbittorrent/qbittorrent-4.3.9.tar.gz) =
Y1NN8fccQhQEPgXMNHqwdTfgAq/2OZ8FNPCw2nywFOo=
-SIZE (qbittorrent/qbittorrent-4.3.9.tar.gz) = 8390945
+SHA256 (qbittorrent/qbittorrent-4.4.2.tar.gz) =
LVusW4N8Pf0hnY42p3cmjufQv604vJS/0B/wf0MHm74=
+SIZE (qbittorrent/qbittorrent-4.4.2.tar.gz) = 9072263
Index: qbittorrent/patches/patch-configure_ac
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent/patches/patch-configure_ac,v
retrieving revision 1.4
diff -u -p -r1.4 patch-configure_ac
--- qbittorrent/patches/patch-configure_ac 11 Mar 2022 19:47:15 -
1.4
+++ qbittorrent/patches/patch-configure_ac 28 Mar 2022 21:39:46 -
@@ -1,21 +1,8 @@
Index: configure.ac
--- configure.ac.orig
+++ configure.ac
-@@ -53,6 +53,12 @@ AC_ARG_ENABLE(qt-dbus,
- [enable_qt_dbus=yes])
-
- # Detect OS
-+AC_MSG_CHECKING([whether OS is OpenBSD])
-+AS_IF([expr "$host_os" : ".*openbsd.*" > /dev/null],
-+ [AC_MSG_RESULT([yes])
-+ LIBS="-lexecinfo $LIBS"],
-+ [AC_MSG_RESULT([no])])
-+
- AC_MSG_CHECKING([whether OS is FreeBSD])
- AS_IF([expr "$host_os" : ".*freebsd.*" > /dev/null],
- [AC_MSG_RESULT([yes])
-@@ -185,7 +191,7 @@ PKG_CHECK_MODULES(libtorrent,
- LIBS="$libtorrent_LIBS $LIBS"])
+@@ -198,7 +198,7 @@ PKG_CHECK_MODULES(libtorrent,
+ [CXXFLAGS="$libtorrent_CFLAGS $CXXFLAGS"
LIBS="$libtorrent_LIBS $LIBS"])])
PKG_CHECK_MODULES(openssl,
- [openssl >= 1.1.1],
Index: qbittorrent/pkg/PLIST
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent/pkg/PLIST,v
retrieving revision 1.4
diff -u -p -r1.4 PLIST
--- qbittorrent/pkg/PLIST 11 Mar 2022 19:47:15 - 1.4
+++ qbittorrent/pkg/PLIST 28 Mar 2022 21:39:46 -
@@ -25,6 +25,7 @@ share/icons/hicolor/72x72/apps/qbittorre
share/icons/hicolor/72x72/status/qbittorrent-tray.png
share/icons/hicolor/96x96/apps/qbittorrent.png
share/icons/hicolor/96x96/status/qbittorrent-tray.png
+share/icons/hicolor/scalable/apps/qbittorrent.svg
share/icons/hicolor/scalable/status/qbittorrent-tray-dark.svg
share/icons/hicolor/scalable/status/qbittorrent-tray-light.svg
share/icons/hicolor/scalable/status/qbittorrent-tray.svg
Index: qbittorrent-nox/Makefile
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent-nox/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- qbittorrent-nox/Makefile11 Mar 2022 19:47:15 - 1.9
+++ qbittorrent-nox/Makefile28 Mar 2022 21:39:46 -
@@ -1,8 +1,9 @@
COMMENT = BitTorrent client with web interface
PKGNAME = qbittorrent-nox-${VER}
-WANTLIB += ${COMPILER_LIBCXX} Qt5Core Qt5Network Qt5Xml boost_system
-WANTLIB += boost_system-mt c crypto execinfo m ssl torrent-ra
Re: [BUG] net/qbittorrent and net/deluge not working
Thanks for the links Theo, I didn't know about those mirrors with the previous builds. Yep, the problem seems to lie with the boost update from 1.76 to 1.77. Using 1.76 works OK. On Mon, Sep 13, 2021 at 6:28 PM Theo Buehler wrote: > On Mon, Sep 13, 2021 at 05:55:51PM -0300, Elias M. Mariani wrote: > > I should add some more info: > > - I tested this on amd64, qbittorrent 4.3.8 was working OK a week or so > > ago. I just tested deluge because it uses the same libraries. > > - Reproduce: pkg_add qbittorrent on -current, run qbittorrent. The same > > applies for deluge. > > I tested both in a vanilla -current machine just to be sure that nothing > > was on the way... > > There was a similar report on bugs (Sep 9): > https://marc.info/?l=openbsd-bugs&m=163120864431955&w=2 > > The timeframe of "one week or so" and the trace make it likely that it > is the boost 1.77 update. > > This is the last snapshot with boost-1.76p0: > https://ftp.hostserver.de/archive/2021-09-05-0105/snapshots/ > If that works and the next snapshot with boost-1.77 is broken... > https://ftp.hostserver.de/archive/2021-09-06-0105/snapshots/ >
Re: [BUG] net/qbittorrent and net/deluge not working
I should add some more info: - I tested this on amd64, qbittorrent 4.3.8 was working OK a week or so ago. I just tested deluge because it uses the same libraries. - Reproduce: pkg_add qbittorrent on -current, run qbittorrent. The same applies for deluge. I tested both in a vanilla -current machine just to be sure that nothing was on the way... I added some interested parties, again I'm not sure where the problem is... I'm just guessing. On Mon, Sep 13, 2021 at 5:49 PM Elias M. Mariani wrote: > net/qbittorrent and net/deluge are broken (at least on amd64). > > Both are using net/libtorrent-rasterbar and devel/boost. I'm guessing > that this is the fallout from some change on the system libraries or > caused by the devel/boost update. > > I'm adding the backtrace frdsdsdom gdb for both to see if someone > with the knowledge on how to debug this can step in, or maybe just > point to where the cause might be. > > Cheers. Elias mariani@ > > net/qbittorrent > (gdb) bt > #0 thrkill () at /tmp/-:3 > #1 0x07bd21e24e1e in _libc_abort () at > /usr/src/lib/libc/stdlib/abort.c:51 > #2 0x07bd21df8326 in wrterror (d=Variable "d" is not available. > ) at /usr/src/lib/libc/stdlib/malloc.c:307 > #3 0x07bd21dfbb56 in findpool (p=0x0, argpool=0x0, foundpool=0x0, > saved_function=0x7bd21e7663a) at /usr/src/lib/libc/stdlib/malloc.c:1332 > #4 0x07bd21df8625 in ofree (argpool=0x7bd9f321ae0, > p=0x316250650a66446b, clear=0, check=0, argsz=0) at > /usr/src/lib/libc/stdlib/malloc.c:1346 > #5 0x07bd21df856b in free (ptr=0x316250650a66446b) at > /usr/src/lib/libc/stdlib/malloc.c:1470 > #6 0x07bd329eea3f in > _ZN5boost4asio6detail18completion_handlerIZNK10libtorrent14session_handle13sync_call_retINS3_13settings_packEMNS3_3aux12session_implEKFS6_vEJEEET_T0_DpOT1_EUlvE_NS0_10io_context19basic_executor_typeINSt3__19allocatorIvEELj011do_completeEPvPNS1_19scheduler_operationERKNS_6system10error_codeEm > () from /usr/local/lib/libtorrent-rasterbar.so.4.0 > #7 0x07bd32868069 in boost::asio::detail::scheduler::do_run_one () > from /usr/local/lib/libtorrent-rasterbar.so.4.0 > #8 0x07bd32867a91 in boost::asio::detail::scheduler::run () from > /usr/local/lib/libtorrent-rasterbar.so.4.0 > #9 0x07bd329cd736 in > _ZNSt3__114__thread_proxyINS_5tupleIJNS_10unique_ptrINS_15__thread_structENS_14default_deleteIS3_ZN10libtorrent7session5startENS7_5flags13bitfield_flagIhNS7_17session_flags_tagEvEEONS7_14session_paramsEPN5boost4asio10io_contextEE3$_0EPvSL_ > () >from /usr/local/lib/libtorrent-rasterbar.so.4.0 > #10 0x07bd847218e1 in _rthread_start (v=Unhandled dwarf expression > opcode 0xa3 > ) at /usr/src/lib/librthread/rthread.c:96 > #11 0x07bd21e840fa in __tfork_thread () at > /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:84 > #12 0x07bd21e840fa in __tfork_thread () at > /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:84 > Current language: auto; currently asm > > net/deluge > (gdb) bt > #0 thrkill () at /tmp/-:3 > #1 0x070ee2686e1e in _libc_abort () at > /usr/src/lib/libc/stdlib/abort.c:51 > #2 0x070ee265a326 in wrterror (d=Variable "d" is not available. > ) at /usr/src/lib/libc/stdlib/malloc.c:307 > #3 0x070ee265db56 in findpool (p=0x0, argpool=0x0, foundpool=0x0, > saved_function=0x70ee26d863a) at /usr/src/lib/libc/stdlib/malloc.c:1332 > #4 0x070ee265a625 in ofree (argpool=0x70eb5edc2f0, > p=0xe14013342e6f0e0e, clear=0, check=0, argsz=0) at > /usr/src/lib/libc/stdlib/malloc.c:1346 > #5 0x070ee265a56b in free (ptr=0xe14013342e6f0e0e) at > /usr/src/lib/libc/stdlib/malloc.c:1470 > #6 0x070e96228f9b in > boost::asio::detail::thread_info_base::allocate > () >from /usr/local/lib/libtorrent-rasterbar.so.4.0 > #7 0x070e964f38d0 in > _ZN5boost4asio6detail22deadline_timer_serviceINS1_18chrono_time_traitsINSt3__16chrono12steady_clockENS0_11wait_traitsIS6_E10async_waitINS4_6__bindIMN10libtorrent3dht11dht_trackerEFvRKNS_6system10error_codeEEJNS4_10shared_ptrISF_EERKNS4_12placeholders4__phILi1EENS0_15any_io_executorEEEvRNSA_19implementation_typeERT_RKT0_ > () from /usr/local/lib/libtorrent-rasterbar.so.4.0 > #8 0x070e964eca45 in libtorrent::dht::dht_tracker::refresh_key () > from /usr/local/lib/libtorrent-rasterbar.so.4.0 > #9 0x070e964ec3e7 in libtorrent::dht::dht_tracker::start () from > /usr/local/lib/libtorrent-rasterbar.so.4.0 > #10 0x070e963b84ed in libtorrent::aux::session_impl::start_dht () from > /usr/local/lib/libtorrent-rasterbar.so.4.0 > #11 0x070e96
[BUG] net/qbittorrent and net/deluge not working
net/qbittorrent and net/deluge are broken (at least on amd64). Both are using net/libtorrent-rasterbar and devel/boost. I'm guessing that this is the fallout from some change on the system libraries or caused by the devel/boost update. I'm adding the backtrace frdsdsdom gdb for both to see if someone with the knowledge on how to debug this can step in, or maybe just point to where the cause might be. Cheers. Elias mariani@ net/qbittorrent (gdb) bt #0 thrkill () at /tmp/-:3 #1 0x07bd21e24e1e in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51 #2 0x07bd21df8326 in wrterror (d=Variable "d" is not available. ) at /usr/src/lib/libc/stdlib/malloc.c:307 #3 0x07bd21dfbb56 in findpool (p=0x0, argpool=0x0, foundpool=0x0, saved_function=0x7bd21e7663a) at /usr/src/lib/libc/stdlib/malloc.c:1332 #4 0x07bd21df8625 in ofree (argpool=0x7bd9f321ae0, p=0x316250650a66446b, clear=0, check=0, argsz=0) at /usr/src/lib/libc/stdlib/malloc.c:1346 #5 0x07bd21df856b in free (ptr=0x316250650a66446b) at /usr/src/lib/libc/stdlib/malloc.c:1470 #6 0x07bd329eea3f in _ZN5boost4asio6detail18completion_handlerIZNK10libtorrent14session_handle13sync_call_retINS3_13settings_packEMNS3_3aux12session_implEKFS6_vEJEEET_T0_DpOT1_EUlvE_NS0_10io_context19basic_executor_typeINSt3__19allocatorIvEELj011do_completeEPvPNS1_19scheduler_operationERKNS_6system10error_codeEm () from /usr/local/lib/libtorrent-rasterbar.so.4.0 #7 0x07bd32868069 in boost::asio::detail::scheduler::do_run_one () from /usr/local/lib/libtorrent-rasterbar.so.4.0 #8 0x07bd32867a91 in boost::asio::detail::scheduler::run () from /usr/local/lib/libtorrent-rasterbar.so.4.0 #9 0x07bd329cd736 in _ZNSt3__114__thread_proxyINS_5tupleIJNS_10unique_ptrINS_15__thread_structENS_14default_deleteIS3_ZN10libtorrent7session5startENS7_5flags13bitfield_flagIhNS7_17session_flags_tagEvEEONS7_14session_paramsEPN5boost4asio10io_contextEE3$_0EPvSL_ () from /usr/local/lib/libtorrent-rasterbar.so.4.0 #10 0x07bd847218e1 in _rthread_start (v=Unhandled dwarf expression opcode 0xa3 ) at /usr/src/lib/librthread/rthread.c:96 #11 0x07bd21e840fa in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:84 #12 0x07bd21e840fa in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:84 Current language: auto; currently asm net/deluge (gdb) bt #0 thrkill () at /tmp/-:3 #1 0x070ee2686e1e in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51 #2 0x070ee265a326 in wrterror (d=Variable "d" is not available. ) at /usr/src/lib/libc/stdlib/malloc.c:307 #3 0x070ee265db56 in findpool (p=0x0, argpool=0x0, foundpool=0x0, saved_function=0x70ee26d863a) at /usr/src/lib/libc/stdlib/malloc.c:1332 #4 0x070ee265a625 in ofree (argpool=0x70eb5edc2f0, p=0xe14013342e6f0e0e, clear=0, check=0, argsz=0) at /usr/src/lib/libc/stdlib/malloc.c:1346 #5 0x070ee265a56b in free (ptr=0xe14013342e6f0e0e) at /usr/src/lib/libc/stdlib/malloc.c:1470 #6 0x070e96228f9b in boost::asio::detail::thread_info_base::allocate () from /usr/local/lib/libtorrent-rasterbar.so.4.0 #7 0x070e964f38d0 in _ZN5boost4asio6detail22deadline_timer_serviceINS1_18chrono_time_traitsINSt3__16chrono12steady_clockENS0_11wait_traitsIS6_E10async_waitINS4_6__bindIMN10libtorrent3dht11dht_trackerEFvRKNS_6system10error_codeEEJNS4_10shared_ptrISF_EERKNS4_12placeholders4__phILi1EENS0_15any_io_executorEEEvRNSA_19implementation_typeERT_RKT0_ () from /usr/local/lib/libtorrent-rasterbar.so.4.0 #8 0x070e964eca45 in libtorrent::dht::dht_tracker::refresh_key () from /usr/local/lib/libtorrent-rasterbar.so.4.0 #9 0x070e964ec3e7 in libtorrent::dht::dht_tracker::start () from /usr/local/lib/libtorrent-rasterbar.so.4.0 #10 0x070e963b84ed in libtorrent::aux::session_impl::start_dht () from /usr/local/lib/libtorrent-rasterbar.so.4.0 #11 0x070e963cfdbf in libtorrent::aux::session_impl::on_dht_router_name_lookup () from /usr/local/lib/libtorrent-rasterbar.so.4.0 #12 0x070e96386759 in libtorrent::resolver::on_lookup () from /usr/local/lib/libtorrent-rasterbar.so.4.0 #13 0x070e96388f48 in _ZNSt3__16__bindIMN10libtorrent8resolverEFvRKN5boost6system10error_codeENS3_4asio2ip23basic_resolver_iteratorINS9_3tcpEEERKNS_12basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEJPS2_RKNS_12placeholders4__phILi1EEERKNSP_ILi2EEESK_EEclIJS7_RKNS9_22basic_resolver_resultsISB_ENS_13__bind_returnISM_NS_5tupleIJSN_SQ_ST_SI_EEENS13_IJDpOT_EEEXsr22__is_valid_bind_returnISM_S14_S18_EE5valueEE4typeES17_ () from /usr/local/lib/libtorrent-rasterbar.so.4.0 #14 0x070e96388aaa in _ZN5boost4asio6detail16resolve_query_opINS0_2ip3tcpENSt3__16__bindIMN10libtorrent8resolverEFvRKNS_6system10error_codeENS3_23basic_resolver_iteratorIS4_EERKNS5_12basic_stringIcNS5_11char_traitsIcEENS5_9allocatorIcEJPS8_RKNS5_12placeholders4__phILi1EEERKNSR_ILi2EEESM_EEENS0_15any_io_executorEE11do_completeEPvPNS1_19scheduler_operationESC_m (
Re: [M. UPDATE] net/qbittorrent 4.3.1 to 4.3.5
New diff based on the excellent recommendation from sthen@.
Comments?
OK?
Cheers.
Elias mariani@
Index: Makefile.inc
===
RCS file: /cvs/ports/net/qbittorrent/Makefile.inc,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile.inc
--- Makefile.inc2 Dec 2020 22:33:17 - 1.14
+++ Makefile.inc25 May 2021 17:53:54 -
@@ -3,7 +3,7 @@
# qmake picks up gcrypt.h even though it's unused
DPB_PROPERTIES = nojunk
-VER = 4.3.1
+VER = 4.3.5
DISTNAME = qbittorrent-${VER}
DIST_SUBDIR = qbittorrent
@@ -22,4 +22,8 @@ MASTER_SITES ?= ${MASTER_SITE_SOURCEFORG
MODULES += x11/qt5
USE_GMAKE =Yes
-CONFIGURE_STYLE = gnu
+
+CONFIGURE_STYLE = autoreconf
+AUTORECONF =${WRKSRC}/bootstrap.sh
+AUTOCONF_VERSION = 2.69
+AUTOMAKE_VERSION = 1.16
Index: qbittorrent/distinfo
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent/distinfo,v
retrieving revision 1.11
diff -u -p -r1.11 distinfo
--- qbittorrent/distinfo2 Dec 2020 22:33:17 - 1.11
+++ qbittorrent/distinfo25 May 2021 17:53:54 -
@@ -1,2 +1,2 @@
-SHA256 (qbittorrent/qbittorrent-4.3.1.tar.gz) =
VQpJb1xzzVep1/Ct2uMGFgu7Qf1R8dBXYxVFViDmsPE=
-SIZE (qbittorrent/qbittorrent-4.3.1.tar.gz) = 7864145
+SHA256 (qbittorrent/qbittorrent-4.3.5.tar.gz) =
3CrtmhW9lwicWMu00PB6LEw0lghS++SGjXmXbi2wOrY=
+SIZE (qbittorrent/qbittorrent-4.3.5.tar.gz) = 8016819
Index: qbittorrent/patches/patch-configure
===
RCS file: qbittorrent/patches/patch-configure
diff -N qbittorrent/patches/patch-configure
--- qbittorrent/patches/patch-configure 6 Feb 2020 20:00:18 - 1.3
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,55 +0,0 @@
-$OpenBSD: patch-configure,v 1.3 2020/02/06 20:00:18 rsadowski Exp $
-
-Index: configure
configure.orig
-+++ configure
-@@ -5478,12 +5478,12 @@ if test -n "$zlib_CFLAGS"; then
- pkg_cv_zlib_CFLAGS="$zlib_CFLAGS"
- elif test -n "$PKG_CONFIG"; then
- if test -n "$PKG_CONFIG" && \
--{ { $as_echo "$as_me:${as_lineno-$LINENO}: \$PKG_CONFIG --exists
--print-errors \"zlib >= 1.2.5.2\""; } >&5
-- ($PKG_CONFIG --exists --print-errors "zlib >= 1.2.5.2") 2>&5
-+{ { $as_echo "$as_me:${as_lineno-$LINENO}: \$PKG_CONFIG --exists
--print-errors \"zlib >= 1.2.3\""; } >&5
-+ ($PKG_CONFIG --exists --print-errors "zlib >= 1.2.3") 2>&5
- ac_status=$?
- $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
- test $ac_status = 0; }; then
-- pkg_cv_zlib_CFLAGS=`$PKG_CONFIG --cflags "zlib >= 1.2.5.2" 2>/dev/null`
-+ pkg_cv_zlib_CFLAGS=`$PKG_CONFIG --cflags "zlib >= 1.2.3" 2>/dev/null`
- test "x$?" != "x0" && pkg_failed=yes
- else
- pkg_failed=yes
-@@ -5495,12 +5495,12 @@ if test -n "$zlib_LIBS"; then
- pkg_cv_zlib_LIBS="$zlib_LIBS"
- elif test -n "$PKG_CONFIG"; then
- if test -n "$PKG_CONFIG" && \
--{ { $as_echo "$as_me:${as_lineno-$LINENO}: \$PKG_CONFIG --exists
--print-errors \"zlib >= 1.2.5.2\""; } >&5
-- ($PKG_CONFIG --exists --print-errors "zlib >= 1.2.5.2") 2>&5
-+{ { $as_echo "$as_me:${as_lineno-$LINENO}: \$PKG_CONFIG --exists
--print-errors \"zlib >= 1.2.3\""; } >&5
-+ ($PKG_CONFIG --exists --print-errors "zlib >= 1.2.3") 2>&5
- ac_status=$?
- $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
- test $ac_status = 0; }; then
-- pkg_cv_zlib_LIBS=`$PKG_CONFIG --libs "zlib >= 1.2.5.2" 2>/dev/null`
-+ pkg_cv_zlib_LIBS=`$PKG_CONFIG --libs "zlib >= 1.2.3" 2>/dev/null`
- test "x$?" != "x0" && pkg_failed=yes
- else
- pkg_failed=yes
-@@ -5521,14 +5521,14 @@ else
- _pkg_short_errors_supported=no
- fi
- if test $_pkg_short_errors_supported = yes; then
-- zlib_PKG_ERRORS=`$PKG_CONFIG --short-errors --print-errors
--cflags --libs "zlib >= 1.2.5.2" 2>&1`
-+ zlib_PKG_ERRORS=`$PKG_CONFIG --short-errors --print-errors
--cflags --libs "zlib >= 1.2.3" 2>&1`
- else
-- zlib_PKG_ERRORS=`$PKG_CONFIG --print-errors --cflags --libs
"zlib >= 1.2.5.2" 2>&1`
-+ zlib_PKG_ERRORS=`$PKG_CONFIG --print-errors --cflags --libs
"zlib >= 1.2.3" 2>&1`
- fi
- # Put the nasty error message in config.log where it belongs
- echo "$zlib_PKG_ERRORS" >&5
-
-- as_fn_error $? "Package requirements (zlib >= 1.2.5.2) were not met:
-+ as_fn_error $? "Package requirements (zlib >= 1.2.3) were not met:
-
- $zlib_PKG_ERRORS
-
Index: qbittorrent/patches/patch-configure_ac
===
RCS file: qbittorrent/patches/patch-configure_ac
diff -N qbittorrent/patches/patch-configure_ac
--- /dev/null 1 Jan 1970 00:00:00 -
+++ qbittorrent/patches/patch-configure_ac 25 May 2021 17:53:54 -
@@ -0,0 +1,20 @@
+$OpenBSD$
+
+Index:
Re: [M. UPDATE] net/qbittorrent 4.3.1 to 4.3.5
I forgot to add: Comments? OK? Thanks! mariani@
[M. UPDATE] net/qbittorrent 4.3.1 to 4.3.5
Changlelog:
https://github.com/qbittorrent/qBittorrent/blob/release-4.3.5/Changelog
New minimum versions are requested to build (zlib>=1.2.11 and
openssl>=1.1.1).
The 'configure' file has been modified accordingly.
Thanks to namn@ for the work on updating net/libtorrent-rasterbar
that was needed to send this update.
Tested on amd64
Cheers.
Elias mariani@
Index: Makefile.inc
===
RCS file: /cvs/ports/net/qbittorrent/Makefile.inc,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile.inc
--- Makefile.inc2 Dec 2020 22:33:17 - 1.14
+++ Makefile.inc24 May 2021 07:00:39 -
@@ -3,7 +3,7 @@
# qmake picks up gcrypt.h even though it's unused
DPB_PROPERTIES = nojunk
-VER = 4.3.1
+VER = 4.3.5
DISTNAME = qbittorrent-${VER}
DIST_SUBDIR = qbittorrent
Index: qbittorrent/distinfo
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent/distinfo,v
retrieving revision 1.11
diff -u -p -r1.11 distinfo
--- qbittorrent/distinfo2 Dec 2020 22:33:17 - 1.11
+++ qbittorrent/distinfo24 May 2021 07:00:39 -
@@ -1,2 +1,2 @@
-SHA256 (qbittorrent/qbittorrent-4.3.1.tar.gz) =
VQpJb1xzzVep1/Ct2uMGFgu7Qf1R8dBXYxVFViDmsPE=
-SIZE (qbittorrent/qbittorrent-4.3.1.tar.gz) = 7864145
+SHA256 (qbittorrent/qbittorrent-4.3.5.tar.gz) =
3CrtmhW9lwicWMu00PB6LEw0lghS++SGjXmXbi2wOrY=
+SIZE (qbittorrent/qbittorrent-4.3.5.tar.gz) = 8016819
Index: qbittorrent/patches/patch-configure
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent/patches/patch-configure,v
retrieving revision 1.3
diff -u -p -r1.3 patch-configure
--- qbittorrent/patches/patch-configure 6 Feb 2020 20:00:18 - 1.3
+++ qbittorrent/patches/patch-configure 24 May 2021 07:00:39 -
@@ -3,52 +3,102 @@ $OpenBSD: patch-configure,v 1.3 2020/02/
Index: configure
--- configure.orig
+++ configure
-@@ -5478,12 +5478,12 @@ if test -n "$zlib_CFLAGS"; then
+@@ -6447,12 +6447,12 @@ if test -n "$openssl_CFLAGS"; then
+ pkg_cv_openssl_CFLAGS="$openssl_CFLAGS"
+ elif test -n "$PKG_CONFIG"; then
+ if test -n "$PKG_CONFIG" && \
+-{ { printf "%s\n" "$as_me:${as_lineno-$LINENO}: \$PKG_CONFIG --exists
--print-errors \"openssl >= 1.1.1\""; } >&5
+- ($PKG_CONFIG --exists --print-errors "openssl >= 1.1.1") 2>&5
++{ { printf "%s\n" "$as_me:${as_lineno-$LINENO}: \$PKG_CONFIG --exists
--print-errors \"openssl >= 1.0.0\""; } >&5
++ ($PKG_CONFIG --exists --print-errors "openssl >= 1.0.0") 2>&5
+ ac_status=$?
+ printf "%s\n" "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+ test $ac_status = 0; }; then
+- pkg_cv_openssl_CFLAGS=`$PKG_CONFIG --cflags "openssl >= 1.1.1" 2>/dev/null`
++ pkg_cv_openssl_CFLAGS=`$PKG_CONFIG --cflags "openssl >= 1.0.0" 2>/dev/null`
+ test "x$?" != "x0" && pkg_failed=yes
+ else
+ pkg_failed=yes
+@@ -6464,12 +6464,12 @@ if test -n "$openssl_LIBS"; then
+ pkg_cv_openssl_LIBS="$openssl_LIBS"
+ elif test -n "$PKG_CONFIG"; then
+ if test -n "$PKG_CONFIG" && \
+-{ { printf "%s\n" "$as_me:${as_lineno-$LINENO}: \$PKG_CONFIG --exists
--print-errors \"openssl >= 1.1.1\""; } >&5
+- ($PKG_CONFIG --exists --print-errors "openssl >= 1.1.1") 2>&5
++{ { printf "%s\n" "$as_me:${as_lineno-$LINENO}: \$PKG_CONFIG --exists
--print-errors \"openssl >= 1.0.0\""; } >&5
++ ($PKG_CONFIG --exists --print-errors "openssl >= 1.0.0") 2>&5
+ ac_status=$?
+ printf "%s\n" "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+ test $ac_status = 0; }; then
+- pkg_cv_openssl_LIBS=`$PKG_CONFIG --libs "openssl >= 1.1.1" 2>/dev/null`
++ pkg_cv_openssl_LIBS=`$PKG_CONFIG --libs "openssl >= 1.0.0" 2>/dev/null`
+ test "x$?" != "x0" && pkg_failed=yes
+ else
+ pkg_failed=yes
+@@ -6490,14 +6490,14 @@ else
+ _pkg_short_errors_supported=no
+ fi
+ if test $_pkg_short_errors_supported = yes; then
+- openssl_PKG_ERRORS=`$PKG_CONFIG --short-errors --print-errors
--cflags --libs "openssl >= 1.1.1" 2>&1`
++ openssl_PKG_ERRORS=`$PKG_CONFIG --short-errors --print-errors
--cflags --libs "openssl >= 1.0.0" 2>&1`
+ else
+- openssl_PKG_ERRORS=`$PKG_CONFIG --print-errors --cflags --libs
"openssl >= 1.1.1" 2>&1`
++ openssl_PKG_ERRORS=`$PKG_CONFIG --print-errors --cflags --libs
"openssl >= 1.0.0" 2>&1`
+ fi
+ # Put the nasty error message in config.log where it belongs
+ echo "$openssl_PKG_ERRORS" >&5
+
+- as_fn_error $? "Package requirements (openssl >= 1.1.1) were not met:
++ as_fn_error $? "Package requirements (openssl >= 1.0.0) were not met:
+
+ $openssl_PKG_ERRORS
+
+@@ -6540,12 +6540,12 @@ if test -n "$zlib_CFLAGS"; then
pkg_cv_zlib_CFLAGS="$zlib_CFLAGS"
elif test -n "$PKG_CONFIG"; then
if test -n "$PKG_CONFIG" && \
--{ { $as_e
Re: update net/libtorrent-rasterbar 1.2.11
still OK mariani@
Tested again with qbittorrent 4.3.5
Just waiting for this update to commit.
Cheers.
On Sun, May 16, 2021 at 6:37 AM Nam Nguyen wrote:
>
> Stuart Henderson writes:
>
> > I suggest using ${MODPY_EGG_VERSION} in setup.py and instead of cp,
> > use "${SUBST_CMD} -m $mode -c $file1 $file2"
>
> >> RCS file: files/setup.py
> >> diff -N files/setup.py
> >> --- /dev/null1 Jan 1970 00:00:00 -
> >> +++ files/setup.py 5 Apr 2021 05:36:16 -
> >> @@ -0,0 +1,195 @@
> >> +#!/usr/bin/env python3
> >
> > ${MODPY_BIN} here perhaps?
>
> Here is a fresh diff. It does the following:
> - Uses ${MODPY_EGG_VERSION} and SUBST_CMD in setup.py to only have to
> update version in one place (from sthen@)
> - Uses ${MODPY_BIN} in ${FILESDIR}/setup.py (from sthen@)
> - Removes -L{LOCALBASE}/lib in ${FILESDIR}/setup.py. Python bindings
> incorrectly linked -ltorrent-rasterbar with
> /usr/local/lib/libtorrent-rasterbar.so.3.0 instead of the freshly
> built ${WRKSRC}/src/.libs/libtorrent-rasterbar.so.4.0.
>
> To do this I modified ${FILESDIR}/setup.py:
> cfg_vars[key] = value.replace('-L${LOCALBASE}/lib/', '')
>
> mariani@ still OK? Looking for another OK in addition to
> commit. Feedback and tests are welcome.
>
> Details
> ===
> Steps to reproduce:
> 1. pkg_add libtorrent-rasterbar (1.2.10p0)
> 2. /usr/local/lib/libtorrent-rasterbar.so.3.0 is picked up.
> 3. install this version 1.2.13
> 4. import libtorrent in python interpreter
>
> $ python3
> Python 3.8.8 (default, Apr 28 2021, 15:17:34)
> [Clang 11.1.0 ] on openbsd6
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import libtorrent
> python3:/usr/local/lib/python3.8/site-packages/libtorrent.cpython-38.so:
> undefined symbol '_ZN10libtorrent14session_handle6pausedE'
> Traceback (most recent call last):
> File "", line 1, in
> ImportError: Cannot load specified object
>
> Set a breakpoint in ${FILESDIR}/setup.py before ext = [Extension(
> import pdb; pdb.set_trace()
>
> Note "-L/usr/local/lib" in BLDSHARED and LDSHARED.
>
> (Pdb) print(cfg_vars)
> {'ABIFLAGS': '', 'AC_APPLE_UNIVERSAL_BUILD': 0,
> 'AIX_GENUINE_CPLUSPLUS': 0, 'ALT_SOABI': 0, 'ANDROID_API_LEVEL': 0,
> 'AR': 'ar', 'ARFLAGS': 'rcs', 'BASECFLAGS': '-Wno-unused-result
> -Wsign-compare -Wunreachable-code', 'BASECPPFLAGS': '', 'BASEMODLIBS':
> '', 'BINDIR': '/usr/local/bin', 'BINLIBDEST':
> '/usr/local/lib/python3.8', 'BLDLIBRARY': '-L. -lpython3.8',
> 'BLDSHARED': 'cc -pthread -shared -fPIC -L/usr/local/lib/
> -L/usr/obj/ports/Python-3.8.8/Python-3.8.8 -L/usr/local/lib/',
> ...
> 'LDSHARED': 'cc -pthread -shared -fPIC -L/usr/local/lib/
> -L/usr/obj/ports/Python-3.8.8/Python-3.8.8 -L/usr/local/lib/'
>
> This is the problematic line with the first two -L/usr/local/lib messing
> up the search path for -ltorrent-rasterbar. With the fix, these two go
> away:
>
> c++ -pthread -shared -fPIC -L/usr/local/lib/
> -L/usr/obj/ports/Python-3.8.8/Python-3.8.8 -L/usr/local/lib/ -O2 -pipe
> bindings/python/src/alert.o
> ...
> -L../../src/.libs -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib
> -ltorrent-rasterbar -lboost_system-mt -lpthread -lboost_system-mt
> -lboost_python38-mt -lpthread -lssl -lcrypto -o
> build/lib.openbsd-6.9-amd64-3.8/libtorrent.cpython-38.so -fvisibility=hidden
> -fvisibility-inlines-hidden /usr/local/lib/libiconv.so.7.0
>
> > On 2021/04/24 01:47, Nam Nguyen wrote:
> >> "Elias M. Mariani" writes:
> >>
> >> > Tested build on amd64.
> >> >
> >> > OK mariani@
> >>
> >> Ping for 1.2.13 update. The diff is pasted inline for convenience. I
> >> would like another OK in addition to mariani@'s, focusing on my proposal
> >> that carrying an old 1.2.11 ${FILESDIR}/setup.py is maintainable (with
> >> backup plan going back to b2 and new setup.py if it ever stops
> >> working). rsadowski@ gave an OK on an older 1.2.11 diff.
> >>
> >> >
> >> > Cheers.
> >> >
> >> >
> >> > On Mon, Apr 5, 2021 at 3:28 AM Nam Nguyen wrote:
> >>
> >> >> Here is a fresh diff with some tweaks. Need some additional feedback on
> >> >> carrying the old 1.2.11 ${FILESDIR}/setup.py.
> &
Re: update net/libtorrent-rasterbar 1.2.11
Tested build on amd64.
OK mariani@
Cheers.
On Mon, Apr 5, 2021 at 3:28 AM Nam Nguyen wrote:
>
> Elias M. Mariani writes:
>
> > Hi.
> > Just giving a bump and attaching a new diff for 1.2.13 based on the
> > previous one from Nam.
>
> Here is a fresh diff with some tweaks. Need some additional feedback on
> carrying the old 1.2.11 ${FILESDIR}/setup.py.
>
> Please find a fresh diff that additionally:
> - remove autotools and use CONFIGURE_STYLE = gnu now that my pull
> request was accepted for 1.2.13. configure now correctly detects the
> default C++ standard. see:
> https://github.com/arvidn/libtorrent/pull/5026
> - removes patches/patch-configure_ac
>
> as before:
> - major bump because check_sym reports removed symbols. one such removed
> symbol is parameter change for add_read_buffer:
> see:
> https://github.com/arvidn/libtorrent/commit/6522fc46f599c49f96d184498e2ce2e4d95ed0ea
> check_sym: https://namtsui.com/public/check_sym_libtorrent.txt
> - carry ${FILESDIR}/setup.py from 1.2.11 because 1.2.12 relies on
> boost-build (see justification inline).
>
> >
> > Tested with qbittorrent (v4.3.1 and v4.3.4.1) and deluge.
> >
> > I need this updated to push a new version of qbittorrent (4.3.4.1).
> >
> > OK?
>
> > On Sat, Feb 6, 2021 at 3:54 AM Elias M. Mariani
> > wrote:
> >>
> >> Tested the diff for 1.2.12 from Nam.
> >> Working OK with qbittorrent 4.3.3.
> >>
> >> portcheck complains about a "1 line(s) longer than 80 chars in
> >> Makefile" but is just the MASTER_SITES one.
> >> make port-lib-depends-check is OK
> >>
> >> OK mariani@
> >>
> >> No opinions about setup.py. I don't have the knowledge to take a
> >> stand.
>
> Carrying an old setup.py is relatively safe. I have a hacky WIP that
> actually successfully builds libtorrent-rasterbar using the new setup.py
> and boost-build (b2). There are unresolved issues:
> - I had to create /usr/local/lib/libtorrent-rasterbar.so because the new
> setup.py cannot cope with openbsd's versioning (e.g.,
> libtorrent-rasterbar.so.4.0)
> - I needed to specify BOOST_ROOT as boost's ${WRKSRC}. This means that
> the boost source, including jamfiles, must be provided.
> - boost must provide b2
>
> It is possible to use b2, but, for now, just carry the old
> setup.py. This can be fleshed out if setup.py ever stops working.
>
> I tested with deluge and qbittorrent. The test suite in a similar state
> with 2 skipped.
>
> >>
> >> Cheers.
> >> Elias.
>
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/net/libtorrent-rasterbar/Makefile,v
> retrieving revision 1.15
> diff -u -p -u -p -r1.15 Makefile
> --- Makefile23 Feb 2021 19:39:32 - 1.15
> +++ Makefile5 Apr 2021 05:36:16 -
> @@ -2,11 +2,11 @@
>
> COMMENT = C++ library implementing a BitTorrent client
>
> -MODPY_EGG_VERSION =1.2.10
> +# remember to update version number in ${FILESDIR}/setup.py
> +MODPY_EGG_VERSION =1.2.13
> DISTNAME = libtorrent-rasterbar-${MODPY_EGG_VERSION}
> -REVISION = 0
>
> -SHARED_LIBS += torrent-rasterbar 3.0 # 10.0.0
> +SHARED_LIBS += torrent-rasterbar 4.0 # 10.0.0
>
> CATEGORIES = net devel
>
> @@ -18,7 +18,7 @@ PERMIT_PACKAGE = Yes
> WANTLIB += ${COMPILER_LIBCXX} boost_python${MODPY_VERSION:C/\.//g}-mt
> WANTLIB += boost_system-mt crypto iconv m ssl
>
> -MASTER_SITES =
> https://github.com/arvidn/libtorrent/releases/download/libtorrent-${MODPY_EGG_VERSION}/
> +MASTER_SITES =
> https://github.com/arvidn/libtorrent/releases/download/v${MODPY_EGG_VERSION}/
>
> MODULES = lang/python
>
> @@ -30,10 +30,7 @@ LIB_DEPENDS =converters/libiconv \
> # boost
> COMPILER = base-clang ports-gcc
>
> -CONFIGURE_STYLE = autoreconf
> -
> -AUTOCONF_VERSION = 2.69
> -AUTOMAKE_VERSION = 1.16
> +CONFIGURE_STYLE = gnu
>
> CONFIGURE_ARGS = --enable-python-binding \
> --enable-tests \
> @@ -53,6 +50,8 @@ CONFIGURE_ARGS += --enable-debug
>
> pre-configure:
> sed -i 's,-Os,,g' ${WRKSRC}/configure
> +# use setup.py from 1.2.11 because >=1.2.12 introduced dependency on
> boost-build
> + @cp ${FILESDIR}/setup.py ${WRKSRC}/bindings/python
>
> pre-test:
> ln -sf ${MODPY_BIN} ${WRKDIR}/bin/python
> Index: distinfo
> =
Re: update net/libtorrent-rasterbar 1.2.11
/patches/patch-include_libtorrent_config_hpp,v
retrieving revision 1.4
diff -u -p -r1.4 patch-include_libtorrent_config_hpp
--- patches/patch-include_libtorrent_config_hpp 4 Sep 2020 04:24:28 -
1.4
+++ patches/patch-include_libtorrent_config_hpp 3 Apr 2021 20:44:01 -
@@ -2,7 +2,7 @@ $OpenBSD: patch-include_libtorrent_confi
Index: include/libtorrent/config.hpp
--- include/libtorrent/config.hpp.orig
+++ include/libtorrent/config.hpp
-@@ -414,6 +414,10 @@ POSSIBILITY OF SUCH DAMAGE.
+@@ -429,6 +429,10 @@ POSSIBILITY OF SUCH DAMAGE.
#define TORRENT_USE_UNC_PATHS 0
#endif
Index: pkg/PLIST
===
RCS file: /cvs/ports/net/libtorrent-rasterbar/pkg/PLIST,v
retrieving revision 1.6
diff -u -p -r1.6 PLIST
--- pkg/PLIST 4 Jan 2021 14:06:35 - 1.6
+++ pkg/PLIST 3 Apr 2021 20:44:02 -
@@ -43,6 +43,7 @@ include/libtorrent/aux_/noexcept_movable
include/libtorrent/aux_/numeric_cast.hpp
include/libtorrent/aux_/openssl.hpp
include/libtorrent/aux_/path.hpp
+include/libtorrent/aux_/pool.hpp
include/libtorrent/aux_/portmap.hpp
include/libtorrent/aux_/proxy_settings.hpp
include/libtorrent/aux_/range.hpp
On Sat, Feb 6, 2021 at 3:54 AM Elias M. Mariani wrote:
>
> Tested the diff for 1.2.12 from Nam.
> Working OK with qbittorrent 4.3.3.
>
> portcheck complains about a "1 line(s) longer than 80 chars in
> Makefile" but is just the MASTER_SITES one.
> make port-lib-depends-check is OK
>
> OK mariani@
>
> No opinions about setup.py. I don't have the knowledge to take a stand.
>
> Cheers.
> Elias.
>
> On Tue, Jan 19, 2021 at 1:01 AM Nam Nguyen wrote:
> >
> > Rafael Sadowski writes:
> >
> > > On Mon Dec 28, 2020 at 04:04:42AM -0800, Nam Nguyen wrote:
> > >> Here is a diff to update libtorrent-rasterbar to 1.2.11, released on
> > >> Nov. 15, 2020.
> >
> > Here is a diff for 1.2.12 which was released on Jan. 5, 2021. I have not
> > yet committed 1.2.11 which was OK rsadowski@, so I'm proposing this
> > newer update instead.
> >
> > changelog: https://github.com/arvidn/libtorrent/releases/tag/v1.2.12
> >
> > This diff additionally:
> > - uses a local copy of 1.2.11's ${WRKSRC}/bindings/setup.py because
> > 1.2.12 relies on boost-build, which has been removed from devel/boost
> >
> > For now, I propose carrying a copy of 1.2.11's
> > ${WRKSRC}/bindings/python/setup.py until boost-build is built
> > again. ${FILESDIR}/setup.py needs to be updated manually with each
> > update (e.g., 1.2.12).
> >
> > Questions:
> > 1. Is carrying an old setup.py worth the maintenance burden?
> > 2. Will boost-build return in the future once python 3 support becomes
> >better? It may not be worth it just for this port.
> >
> > Testing
> > ---
> > I tested consumers in net/deluge and net/qbittorrent. A new unit test is
> > skipped for test_pex, which used to pass. It has been resolved upstream:
> > https://github.com/arvidn/libtorrent/issues/5863
> >
> > >>
> > >> changelog: https://github.com/arvidn/libtorrent/releases/tag/v1.2.11
> > >>
> > >> This diff:
> > >> - bumps library major due to symbol deprecation
> > >> - changes MASTER_SITES to properly download the new release
> > >>
> > >> I tested with qbittorrent and deluge. `make test' skips the same tests
> > >> as the previous release (test_lsd and test_primitives).
> > >>
> > >> OK?
> > >
> > > It has built cleanly and port-wise it looks fine. OK rsadowski@
> > >
> > [snip]
> >
> > Brad Smith writes:
> >
> > > Well the only question I have is if we remove this does anything in
> > > the ports tree
> > > depend it for building anything? If not, then I'd say go with removing
> > > it all together
> > > for the time being until it is updated to be compatible with Python
> > > 3. If the answer
> > > is yes then how many ports?
> >
> > I see from revision 1.103 of devel/boost/Makefile, "boost-build also
> > leaves as collateral damage, its python files aren't ready for python3
> > and it's not clear how useful they are."
> >
> > FreeBSD also reports rare usage of boost-build: "Not one other port out
> > of 30,000 uses boost-build, so it is likely untested."
> >
> > https://github.com/arvidn/libtorrent/issues/5797
> >
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/net/libtorrent-ra
Re: update net/libtorrent-rasterbar 1.2.11
Tested the diff for 1.2.12 from Nam.
Working OK with qbittorrent 4.3.3.
portcheck complains about a "1 line(s) longer than 80 chars in
Makefile" but is just the MASTER_SITES one.
make port-lib-depends-check is OK
OK mariani@
No opinions about setup.py. I don't have the knowledge to take a stand.
Cheers.
Elias.
On Tue, Jan 19, 2021 at 1:01 AM Nam Nguyen wrote:
>
> Rafael Sadowski writes:
>
> > On Mon Dec 28, 2020 at 04:04:42AM -0800, Nam Nguyen wrote:
> >> Here is a diff to update libtorrent-rasterbar to 1.2.11, released on
> >> Nov. 15, 2020.
>
> Here is a diff for 1.2.12 which was released on Jan. 5, 2021. I have not
> yet committed 1.2.11 which was OK rsadowski@, so I'm proposing this
> newer update instead.
>
> changelog: https://github.com/arvidn/libtorrent/releases/tag/v1.2.12
>
> This diff additionally:
> - uses a local copy of 1.2.11's ${WRKSRC}/bindings/setup.py because
> 1.2.12 relies on boost-build, which has been removed from devel/boost
>
> For now, I propose carrying a copy of 1.2.11's
> ${WRKSRC}/bindings/python/setup.py until boost-build is built
> again. ${FILESDIR}/setup.py needs to be updated manually with each
> update (e.g., 1.2.12).
>
> Questions:
> 1. Is carrying an old setup.py worth the maintenance burden?
> 2. Will boost-build return in the future once python 3 support becomes
>better? It may not be worth it just for this port.
>
> Testing
> ---
> I tested consumers in net/deluge and net/qbittorrent. A new unit test is
> skipped for test_pex, which used to pass. It has been resolved upstream:
> https://github.com/arvidn/libtorrent/issues/5863
>
> >>
> >> changelog: https://github.com/arvidn/libtorrent/releases/tag/v1.2.11
> >>
> >> This diff:
> >> - bumps library major due to symbol deprecation
> >> - changes MASTER_SITES to properly download the new release
> >>
> >> I tested with qbittorrent and deluge. `make test' skips the same tests
> >> as the previous release (test_lsd and test_primitives).
> >>
> >> OK?
> >
> > It has built cleanly and port-wise it looks fine. OK rsadowski@
> >
> [snip]
>
> Brad Smith writes:
>
> > Well the only question I have is if we remove this does anything in
> > the ports tree
> > depend it for building anything? If not, then I'd say go with removing
> > it all together
> > for the time being until it is updated to be compatible with Python
> > 3. If the answer
> > is yes then how many ports?
>
> I see from revision 1.103 of devel/boost/Makefile, "boost-build also
> leaves as collateral damage, its python files aren't ready for python3
> and it's not clear how useful they are."
>
> FreeBSD also reports rare usage of boost-build: "Not one other port out
> of 30,000 uses boost-build, so it is likely untested."
>
> https://github.com/arvidn/libtorrent/issues/5797
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/net/libtorrent-rasterbar/Makefile,v
> retrieving revision 1.14
> diff -u -p -u -p -r1.14 Makefile
> --- Makefile4 Jan 2021 14:06:35 - 1.14
> +++ Makefile19 Jan 2021 03:36:35 -
> @@ -2,11 +2,11 @@
>
> COMMENT = C++ library implementing a BitTorrent client
>
> -MODPY_EGG_VERSION =1.2.10
> +# remember to update version number in ${FILESDIR}/setup.py
> +MODPY_EGG_VERSION =1.2.12
> DISTNAME = libtorrent-rasterbar-${MODPY_EGG_VERSION}
> -REVISION = 0
>
> -SHARED_LIBS += torrent-rasterbar 3.0 # 10.0.0
> +SHARED_LIBS += torrent-rasterbar 4.0 # 10.0.0
>
> CATEGORIES = net devel
>
> @@ -18,7 +18,7 @@ PERMIT_PACKAGE = Yes
> WANTLIB += ${COMPILER_LIBCXX} boost_python${MODPY_VERSION:C/\.//g}-mt
> WANTLIB += boost_system-mt crypto iconv m ssl
>
> -MASTER_SITES =
> https://github.com/arvidn/libtorrent/releases/download/libtorrent-${MODPY_EGG_VERSION}/
> +MASTER_SITES =
> https://github.com/arvidn/libtorrent/releases/download/v${MODPY_EGG_VERSION}/
>
> MODULES = lang/python
> MODPY_VERSION =${MODPY_DEFAULT_VERSION_3}
> @@ -54,6 +54,8 @@ CONFIGURE_ARGS += --enable-debug
>
> pre-configure:
> sed -i 's,-Os,,g' ${WRKSRC}/configure
> +# use setup.py from 1.2.11 because >=1.2.12 introduced dependency on
> boost-build
> + @cp ${FILESDIR}/setup.py ${WRKSRC}/bindings/python
>
> pre-test:
> ln -sf ${MODPY_BIN} ${WRKDIR}/bin/python
> Index: distinfo
> ===
> RCS file: /cvs/ports/net/libtorrent-rasterbar/distinfo,v
> retrieving revision 1.8
> diff -u -p -u -p -r1.8 distinfo
> --- distinfo7 Sep 2020 04:24:17 - 1.8
> +++ distinfo19 Jan 2021 03:36:35 -
> @@ -1,2 +1,2 @@
> -SHA256 (libtorrent-rasterbar-1.2.10.tar.gz) =
> 0N0wvcOSZYfEJB9AaNjjliimwfn2z1MZXw6byQAXvvs=
> -SIZE (libtorrent-rasterbar-1.2.10.tar.gz) = 4128498
> +SHA256 (libtorrent-rasterbar-1.2.12.tar.gz) =
> w3RKyfpB9ubr95U4oupnjfdqLLuvOsauLAVFUxTlzOg=
> +SIZE (libtorrent
[M. UPDATE] net/qbittorent 4.3.0.1 to 4.3.1
Update net/qbittorrent 4.3.0.1 to 4.3.1
Changelog:
https://github.com/qbittorrent/qBittorrent/blob/release-4.3.1/Changelog
Tested OK on amd64.
Comments ?
OKs ?
Cheers
Elias mariani@
Index: Makefile.inc
===
RCS file: /cvs/ports/net/qbittorrent/Makefile.inc,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile.inc
--- Makefile.inc25 Oct 2020 22:36:41 - 1.13
+++ Makefile.inc28 Nov 2020 03:43:45 -
@@ -3,7 +3,7 @@
# qmake picks up gcrypt.h even though it's unused
DPB_PROPERTIES = nojunk
-VER = 4.3.0.1
+VER = 4.3.1
DISTNAME = qbittorrent-${VER}
DIST_SUBDIR = qbittorrent
Index: qbittorrent/distinfo
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent/distinfo,v
retrieving revision 1.10
diff -u -p -r1.10 distinfo
--- qbittorrent/distinfo25 Oct 2020 22:36:41 - 1.10
+++ qbittorrent/distinfo28 Nov 2020 03:43:45 -
@@ -1,2 +1,2 @@
-SHA256 (qbittorrent/qbittorrent-4.3.0.1.tar.gz) =
/ZovuqFJEUmpXNeTZuZyj7P6uvt2jlHRdIcw8gI8r+Q=
-SIZE (qbittorrent/qbittorrent-4.3.0.1.tar.gz) = 7781412
+SHA256 (qbittorrent/qbittorrent-4.3.1.tar.gz) =
VQpJb1xzzVep1/Ct2uMGFgu7Qf1R8dBXYxVFViDmsPE=
+SIZE (qbittorrent/qbittorrent-4.3.1.tar.gz) = 7864145
Index: qbittorrent/patches/patch-src_base_utils_gzip_cpp
===
RCS file:
/cvs/ports/net/qbittorrent/qbittorrent/patches/patch-src_base_utils_gzip_cpp,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 patch-src_base_utils_gzip_cpp
--- qbittorrent/patches/patch-src_base_utils_gzip_cpp 17 Sep 2018 09:56:29
- 1.1.1.1
+++ qbittorrent/patches/patch-src_base_utils_gzip_cpp 28 Nov 2020 03:43:45
-
@@ -12,7 +12,7 @@ Index: src/base/utils/gzip.cpp
strm.avail_in = uInt(data.size());
strm.next_out = reinterpret_cast(tmpBuf.data());
strm.avail_out = BUFSIZE;
-@@ -110,7 +110,7 @@ QByteArray Utils::Gzip::decompress(const QByteArray &d
+@@ -113,7 +113,7 @@ QByteArray Utils::Gzip::decompress(const QByteArray &d
strm.zalloc = Z_NULL;
strm.zfree = Z_NULL;
strm.opaque = Z_NULL;
Index: qbittorrent-nox/distinfo
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent-nox/distinfo,v
retrieving revision 1.10
diff -u -p -r1.10 distinfo
--- qbittorrent-nox/distinfo25 Oct 2020 22:36:41 - 1.10
+++ qbittorrent-nox/distinfo28 Nov 2020 03:43:45 -
@@ -1,2 +1,2 @@
-SHA256 (qbittorrent/qbittorrent-4.3.0.1.tar.gz) =
/ZovuqFJEUmpXNeTZuZyj7P6uvt2jlHRdIcw8gI8r+Q=
-SIZE (qbittorrent/qbittorrent-4.3.0.1.tar.gz) = 7781412
+SHA256 (qbittorrent/qbittorrent-4.3.1.tar.gz) =
VQpJb1xzzVep1/Ct2uMGFgu7Qf1R8dBXYxVFViDmsPE=
+SIZE (qbittorrent/qbittorrent-4.3.1.tar.gz) = 7864145
Index: qbittorrent-nox/patches/patch-src_base_utils_gzip_cpp
===
RCS file:
/cvs/ports/net/qbittorrent/qbittorrent-nox/patches/patch-src_base_utils_gzip_cpp,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 patch-src_base_utils_gzip_cpp
--- qbittorrent-nox/patches/patch-src_base_utils_gzip_cpp 17 Sep 2018
09:56:29 - 1.1.1.1
+++ qbittorrent-nox/patches/patch-src_base_utils_gzip_cpp 28 Nov 2020
03:43:45 -
@@ -12,7 +12,7 @@ Index: src/base/utils/gzip.cpp
strm.avail_in = uInt(data.size());
strm.next_out = reinterpret_cast(tmpBuf.data());
strm.avail_out = BUFSIZE;
-@@ -110,7 +110,7 @@ QByteArray Utils::Gzip::decompress(const QByteArray &d
+@@ -113,7 +113,7 @@ QByteArray Utils::Gzip::decompress(const QByteArray &d
strm.zalloc = Z_NULL;
strm.zfree = Z_NULL;
strm.opaque = Z_NULL;
[M. UPDATE] net/qbittorent 4.2.5 to 4.3.0.1
Update net/qbittorrent 4.2.5 to 4.3.0.1
Changelog:
https://github.com/qbittorrent/qBittorrent/blob/release-4.3.0.1/Changelog
Tested OK on amd64.
Comments ?
OKs ?
Cheers
Elias mariani@
Index: Makefile.inc
===
RCS file: /cvs/ports/net/qbittorrent/Makefile.inc,v
retrieving revision 1.12
diff -u -p -r1.12 Makefile.inc
--- Makefile.inc19 Jul 2020 04:02:32 - 1.12
+++ Makefile.inc24 Oct 2020 23:43:59 -
@@ -3,7 +3,7 @@
# qmake picks up gcrypt.h even though it's unused
DPB_PROPERTIES = nojunk
-VER = 4.2.5
+VER = 4.3.0.1
DISTNAME = qbittorrent-${VER}
DIST_SUBDIR = qbittorrent
Index: qbittorrent/distinfo
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent/distinfo,v
retrieving revision 1.9
diff -u -p -r1.9 distinfo
--- qbittorrent/distinfo19 Jul 2020 04:02:32 - 1.9
+++ qbittorrent/distinfo24 Oct 2020 23:43:59 -
@@ -1,2 +1,2 @@
-SHA256 (qbittorrent/qbittorrent-4.2.5.tar.gz) =
i0UICGDxMiuuXhOGb63xMtwaizen6vrGx6MCH6LJeXY=
-SIZE (qbittorrent/qbittorrent-4.2.5.tar.gz) = 7980898
+SHA256 (qbittorrent/qbittorrent-4.3.0.1.tar.gz) =
/ZovuqFJEUmpXNeTZuZyj7P6uvt2jlHRdIcw8gI8r+Q=
+SIZE (qbittorrent/qbittorrent-4.3.0.1.tar.gz) = 7781412
Index: qbittorrent-nox/distinfo
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent-nox/distinfo,v
retrieving revision 1.9
diff -u -p -r1.9 distinfo
--- qbittorrent-nox/distinfo19 Jul 2020 04:02:32 - 1.9
+++ qbittorrent-nox/distinfo24 Oct 2020 23:43:59 -
@@ -1,2 +1,2 @@
-SHA256 (qbittorrent/qbittorrent-4.2.5.tar.gz) =
i0UICGDxMiuuXhOGb63xMtwaizen6vrGx6MCH6LJeXY=
-SIZE (qbittorrent/qbittorrent-4.2.5.tar.gz) = 7980898
+SHA256 (qbittorrent/qbittorrent-4.3.0.1.tar.gz) =
/ZovuqFJEUmpXNeTZuZyj7P6uvt2jlHRdIcw8gI8r+Q=
+SIZE (qbittorrent/qbittorrent-4.3.0.1.tar.gz) = 7781412
Re: graphics/sk1 removal?
Hi Antione. It seems that the developer is working on adapting the project for py3: https://github.com/sk1project/sk1-wx/issues/265#issuecomment-708284955 I think it is OK to drop it, we can recover it from the attic at a later time when the developer finishes upstream. Cheers. Elias. On Sun, Oct 18, 2020 at 6:03 AM Antoine Jacoutot wrote: > > Hi. > > graphics/sk1 is a py2 only application and it is in the way of x11/py-gtk2 > removal (via py-cairo). > Is anyone still using this? > IFAICS there's no effort to move this to python3 and I assume there are > alternatives (libreoffice, scribus...). > > Please speak up :-) > Thanks. > > -- > Antoine >
[M. UPDATE] - devel/py-rope
Update devel/py-rope 0.17.0 to 0.18.0
Changelog:
https://github.com/python-rope/rope/releases/tag/0.18.0
pytest: 194 out of 194 tests passed, 316 warnings
(related to python deprecations).
Tested with devel/spyder OK on amd64 (only consumer).
OKs?
Cheers.
Elias mariani@
Index: Makefile
===
RCS file: /cvs/ports/devel/py-rope/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- Makefile13 Aug 2020 03:44:39 - 1.13
+++ Makefile20 Oct 2020 21:04:24 -
@@ -2,7 +2,7 @@
COMMENT = refactoring library
-MODPY_EGG_VERSION =0.17.0
+MODPY_EGG_VERSION =0.18.0
DISTNAME = rope-${MODPY_EGG_VERSION}
PKGNAME = py-${DISTNAME}
Index: distinfo
===
RCS file: /cvs/ports/devel/py-rope/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- distinfo13 Aug 2020 03:44:39 - 1.6
+++ distinfo20 Oct 2020 21:04:24 -
@@ -1,2 +1,2 @@
-SHA256 (rope-0.17.0.tar.gz) = ZYrWcF9D3PPW3zedqUhlKc8w4C2eoUxWgqqA6zO2SeE=
-SIZE (rope-0.17.0.tar.gz) = 248629
+SHA256 (rope-0.18.0.tar.gz) = eGtcOMUw1IRqpopCYE9htOaaSTOQ48oRuI3w+/3D7QQ=
+SIZE (rope-0.18.0.tar.gz) = 249828
Re: audio/exaile dependencies
Hi Brian.
I see no problem with keeping libnotify, actually I just wanted to
remove py-notify.
The rest was a clean-up that came while looking at it.
So, it's OK for me to keep libnotify as a RUN_DEPENDS.
And, maybe it's needed for more than the plugin, the documentation
could be wrong.
Cheers.
Elias.
On Fri, Sep 11, 2020 at 6:51 PM Brian Callahan wrote:
>
> Hi Elias --
>
> On Friday, September 11, 2020 4:40 PM, Elias M. Mariani
> wrote:
>
> > Hi ports@
> >
> > I recently updated x11/terminator that had a dependency on
> > "devel/py-notify".
> > I noticed that they had switched to using py-gobject3 to access the
> > libnotify library some time ago and this went unnoticed because
> > py-notify installs libnotify.
> >
> > I think that it's the same case with audio/exaile. py-notify is not
> > needed, only libnotify.
> > https://github.com/exaile/exaile/blob/4.0.2/plugins/notify/init.py#L42
> >
> > According to the documentation in the project, libnotify is not
> > required for exaile to work. It's needed for the notify plugin.
> > https://github.com/exaile/exaile/blob/4.0.2/DEPS#L85
> >
> > The tests are returning the same results with or without py-notify.
> > (The tests are broken, py-test is needed).
> >
> > Find attached a diff:
> >
> > - Removing libnotify completely. If it's needed for a given plugin,
> > I think that we should add the rest of the RDEPS for all the other
> > plugins that we can cover or none at all. I'm flexible with libnotify
> > only because it has been there for a while...
> >
>
> I have not used exaile in a long time, and perhaps I should be
> removed as maintainer, but when I did use it I heavily depended on
> the libnotify functionality. If I was still a user of exaile I would
> be very unhappy to see it go.
>
> But I won't stand in the way if this is the direction chosen.
>
> I can look at the tests a little bit later, if no one else beats me
> to it.
>
> ~Brian
>
> > - Removing py-nose as TEST_DEPENDS.
> >
> > - Using py-test to run (fix?) the tests.
> >
> > Tested OK on amd64.
> >
> > My dark motivation for all this is to remove one of the two
> > dependencies that remain on py-notify.
> > Next I will check print/hplip, the only consumer remaining.
> >
> > Cheers.
> > mariani@
> >
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/audio/exaile/Makefile,v
> > retrieving revision 1.42
> > diff -u -p -r1.42 Makefile
> > --- Makefile 9 Jun 2020 16:11:50 - 1.42
> > +++ Makefile 11 Sep 2020 19:58:42 -
> > @@ -6,6 +6,7 @@ COMMENT = music manager and player for G
> >
> > V = 4.0.2
> > DISTNAME = exaile-${V}
> > +REVISION = 0
> >
> > CATEGORIES = audio x11
> >
> > @@ -22,7 +23,7 @@ MODULES = lang/python
> > COMMON_DEPENDS = audio/py-cddb>=1.4${MODPY_FLAVOR} \
> >
> > audio/py-mutagen>=1.11${MODPY_FLAVOR} \\
> >
> > devel/py-gobject3${MODPY_FLAVOR} \\
> >
> >
> > - devel/py-notify>=0.1.1${MODPY_FLAVOR} \\
> >
> >
> >
> > - graphics/py-cairo${MODPY_FLAVOR} \\
> > multimedia/gstreamer1/core \\
> > multimedia/gstreamer1/plugins-good \\
> > x11/dbus-python>=0.82.1${MODPY_FLAVOR}
> >
> >
> >
> > @@ -37,10 +38,9 @@ RUN_DEPENDS = ${COMMON_DEPENDS} \
> >
> > USE_GMAKE = Yes
> >
> > -TEST_TARGET= test
> > +MODPY_PYTEST = Yes
> > PORTHOME = ${WRKDIR}
> > -TEST_DEPENDS= devel/py-nose${MODPY_FLAVOR} \
> >
> > - devel/py-mox3${MODPY_FLAVOR}
> >
> >
> >
> > +TEST_DEPENDS= devel/py-mox3${MODPY_FLAVOR}
> > TEST_ENV= EXAILE_DIR=${WRKOBJ}/test
> >
> > CONFIGURE_STYLE =none
>
>
audio/exaile dependencies
Hi ports@
I recently updated x11/terminator that had a dependency on
"devel/py-notify".
I noticed that they had switched to using py-gobject3 to access the
libnotify library some time ago and this went unnoticed because
py-notify installs libnotify.
I think that it's the same case with audio/exaile. py-notify is not
needed, only libnotify.
https://github.com/exaile/exaile/blob/4.0.2/plugins/notify/__init__.py#L42
According to the documentation in the project, libnotify is not
required for exaile to work. It's needed for the notify plugin.
https://github.com/exaile/exaile/blob/4.0.2/DEPS#L85
The tests are returning the same results with or without py-notify.
(The tests are broken, py-test is needed).
Find attached a diff:
- Removing libnotify completely. If it's needed for a given plugin,
I think that we should add the rest of the RDEPS for all the other
plugins that we can cover or none at all. I'm flexible with libnotify
only because it has been there for a while...
- Removing py-nose as TEST_DEPENDS.
- Using py-test to run (fix?) the tests.
Tested OK on amd64.
My dark motivation for all this is to remove one of the two
dependencies that remain on py-notify.
Next I will check print/hplip, the only consumer remaining.
Cheers.
mariani@
Index: Makefile
===
RCS file: /cvs/ports/audio/exaile/Makefile,v
retrieving revision 1.42
diff -u -p -r1.42 Makefile
--- Makefile9 Jun 2020 16:11:50 - 1.42
+++ Makefile11 Sep 2020 19:58:42 -
@@ -6,6 +6,7 @@ COMMENT = music manager and player for G
V =4.0.2
DISTNAME = exaile-${V}
+REVISION = 0
CATEGORIES = audio x11
@@ -22,7 +23,7 @@ MODULES = lang/python
COMMON_DEPENDS = audio/py-cddb>=1.4${MODPY_FLAVOR} \
audio/py-mutagen>=1.11${MODPY_FLAVOR} \
devel/py-gobject3${MODPY_FLAVOR} \
- devel/py-notify>=0.1.1${MODPY_FLAVOR} \
+ graphics/py-cairo${MODPY_FLAVOR} \
multimedia/gstreamer1/core \
multimedia/gstreamer1/plugins-good \
x11/dbus-python>=0.82.1${MODPY_FLAVOR}
@@ -37,10 +38,9 @@ RUN_DEPENDS =${COMMON_DEPENDS} \
USE_GMAKE =Yes
-TEST_TARGET= test
+MODPY_PYTEST = Yes
PORTHOME = ${WRKDIR}
-TEST_DEPENDS= devel/py-nose${MODPY_FLAVOR} \
- devel/py-mox3${MODPY_FLAVOR}
+TEST_DEPENDS= devel/py-mox3${MODPY_FLAVOR}
TEST_ENV= EXAILE_DIR=${WRKOBJ}/test
CONFIGURE_STYLE =none
Re: Update x11/terminator 1.91 to 1.92
Okey, let's go with the patch.
Do I have your OK ?
Cheers.
mariani@
On Thu, Sep 10, 2020 at 4:28 AM Bjorn Ketelaars wrote:
>
> On Wed 09/09/2020 14:33, Elias M. Mariani wrote:
> > > On 2020/09/09 17:29, Bjorn Ketelaars wrote:
> > > Please sort RDEPS, and group MODPY_*.
> > Done.
> >
> > > 'make test' fails. Maybe this is something that can be fixed by
> > > MODPY_ADJ_FILES?
> > On Wed, Sep 9, 2020 at 2:05 PM Stuart Henderson
> > wrote:
> > > or symlink MODPY_BIN to WRKDIR/bin/python ..
> >
> > I think is better to just call to each file.
> > It seems that They are moving to pytest on the next version:
> > https://github.com/gnome-terminator/terminator/blob/master/pytest.ini
> >
> > So, changes will be needed anyways...
> > Let me know what you guys think.
>
> I think the diff below is a bit nicer:
>
>
> diff --git Makefile Makefile
> index 71e93e721d7..0fe60145b8b 100644
> --- Makefile
> +++ Makefile
> @@ -36,8 +36,7 @@ MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}
> MODPY_DISTUTILS_INSTALL = install --prefix=${LOCALBASE} --root=${DESTDIR}
>
> do-test:
> - ${MODPY_BIN} ${WRKDIST}/tests/test_doctests.py
> - ${MODPY_BIN} ${WRKDIST}/tests/testborg.py
> - ${MODPY_BIN} ${WRKDIST}/tests/testsignalman.py
> + ${SUBST_CMD} ${WRKSRC}/run_tests
> + cd ${WRKSRC} && /bin/sh ./run_tests
>
> .include
> diff --git patches/patch-run_tests patches/patch-run_tests
> new file mode 100644
> index 000..5ece2504985
> --- /dev/null
> +++ patches/patch-run_tests
> @@ -0,0 +1,14 @@
> +$OpenBSD$
> +
> +Index: run_tests
> +--- run_tests.orig
> run_tests
> +@@ -4,7 +4,7 @@ for t in tests/test*; do
> + echo $t
> + file_type=$(file -b $t)
> + case ${file_type} in
> +-*[Pp]ython*) python ${t} ;;
> ++*[Pp]ython*) ${MODPY_BIN} ${t} ;;
> + *Bourne*) bash ${t} ;;
> + *bash*) bash ${t} ;;
> + *perl*) perl ${t} ;;
Re: Update x11/terminator 1.91 to 1.92
> On 2020/09/09 17:29, Bjorn Ketelaars wrote:
> Please sort RDEPS, and group MODPY_*.
Done.
> 'make test' fails. Maybe this is something that can be fixed by
> MODPY_ADJ_FILES?
On Wed, Sep 9, 2020 at 2:05 PM Stuart Henderson wrote:
> or symlink MODPY_BIN to WRKDIR/bin/python ..
I think is better to just call to each file.
It seems that They are moving to pytest on the next version:
https://github.com/gnome-terminator/terminator/blob/master/pytest.ini
So, changes will be needed anyways...
Let me know what you guys think.
Cheers.
mariani@
Index: Makefile
===
RCS file: /cvs/ports/x11/terminator/Makefile,v
retrieving revision 1.21
diff -u -p -r1.21 Makefile
--- Makefile12 Jul 2019 20:51:22 - 1.21
+++ Makefile9 Sep 2020 20:21:32 -
@@ -2,36 +2,42 @@
COMMENT = GTK3 terminal emulator with split-window and tabs
support
-MODPY_EGG_VERSION =1.91
-DISTNAME = terminator-${MODPY_EGG_VERSION}
-REVISION = 1
+VERSION = 1.92
+DISTNAME = terminator-${VERSION}
CATEGORIES = x11
-HOMEPAGE = https://gnometerminator.blogspot.com/p/introduction.html
+HOMEPAGE = https://gnome-terminator.org
# GPLv2
PERMIT_PACKAGE=Yes
-MASTER_SITES =
https://launchpad.net/terminator/gtk3/${MODPY_EGG_VERSION}/+download/
+MASTER_SITES =
https://github.com/gnome-terminator/terminator/releases/download/v${VERSION}/
MODULES = lang/python \
textproc/intltool
RUN_DEPENDS = devel/desktop-file-utils \
devel/gsettings-desktop-schemas \
- devel/py-gobject3 \
- devel/py-notify \
+ devel/libnotify \
+ devel/py-configobj${MODPY_FLAVOR} \
+ devel/py-gobject3${MODPY_FLAVOR} \
devel/vte3 \
- sysutils/py-psutil \
- x11/gtk+3,-guic \
+ sysutils/py-psutil${MODPY_FLAVOR} \
x11/gtk+3 \
+ x11/gtk+3,-guic \
x11/keybinder3
MODPY_SETUPTOOLS = Yes
MODPY_SETUP_ARGS = --without-icon-cache
+MODPY_VERSION =${MODPY_DEFAULT_VERSION_3}
# --single-version-externally-managed option used by MODPY doesn't exist
MODPY_DISTUTILS_INSTALL = install --prefix=${LOCALBASE} --root=${DESTDIR}
+
+do-test:
+ ${MODPY_BIN} ${WRKDIST}/tests/test_doctests.py
+ ${MODPY_BIN} ${WRKDIST}/tests/testborg.py
+ ${MODPY_BIN} ${WRKDIST}/tests/testsignalman.py
.include
Index: distinfo
===
RCS file: /cvs/ports/x11/terminator/distinfo,v
retrieving revision 1.5
diff -u -p -r1.5 distinfo
--- distinfo26 Jun 2018 21:25:04 - 1.5
+++ distinfo9 Sep 2020 20:21:32 -
@@ -1,2 +1,2 @@
-SHA256 (terminator-1.91.tar.gz) = lfduPAJTlW0ZzqsvjacJpJbxuc+bHFuNPNC22jzHvmk=
-SIZE (terminator-1.91.tar.gz) = 910536
+SHA256 (terminator-1.92.tar.gz) = H5TWdq1CyBThWeY3TcqB5OaKwfA/IBM5W6mbacF1c/E=
+SIZE (terminator-1.92.tar.gz) = 910613
Index: pkg/PLIST
===
RCS file: /cvs/ports/x11/terminator/pkg/PLIST,v
retrieving revision 1.9
diff -u -p -r1.9 PLIST
--- pkg/PLIST 29 Jun 2018 22:16:35 - 1.9
+++ pkg/PLIST 9 Sep 2020 20:21:32 -
@@ -2,90 +2,85 @@
bin/remotinator
bin/terminator
bin/terminator.wrapper
-lib/python${MODPY_VERSION}/site-packages/terminator-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info
+lib/python${MODPY_VERSION}/site-packages/terminator-1.92-py${MODPY_VERSION}.egg-info
lib/python${MODPY_VERSION}/site-packages/terminatorlib/
lib/python${MODPY_VERSION}/site-packages/terminatorlib/__init__.py
-lib/python${MODPY_VERSION}/site-packages/terminatorlib/__init__.pyc
+${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/terminatorlib/${MODPY_PYCACHE}/
+lib/python${MODPY_VERSION}/site-packages/terminatorlib/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/terminatorlib/${MODPY_PYCACHE}borg.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/terminatorlib/${MODPY_PYCACHE}config.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/terminatorlib/${MODPY_PYCACHE}container.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/terminatorlib/${MODPY_PYCACHE}cwd.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/terminatorlib/${MODPY_PYCACHE}debugserver.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/terminatorlib/${MODPY_PYCACHE}editablelabel.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/terminatorlib/${MODPY_PYCACHE}encoding.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/terminatorlib/${M
Update x11/terminator 1.91 to 1.92
"New maintainers took care of the project in April of 2020 and moved
the main development over to GitHub."
- From https://launchpad.net/terminator
- Use github as MASTER_SITES.
- Update HOMEPAGE.
- Switch to python3.
- Changelog:
https://github.com/gnome-terminator/terminator/blob/master/CHANGELOG.md#v192-2020-04-18
It seems that devel/py-notify is no longer needed, they use
py3-gobject3 to link against libnotify.
Tested OK on amd64.
Comments?
OK?
Cheers.
Elias mariani@
Index: Makefile
===
RCS file: /cvs/ports/x11/terminator/Makefile,v
retrieving revision 1.21
diff -u -p -r1.21 Makefile
--- Makefile12 Jul 2019 20:51:22 - 1.21
+++ Makefile9 Sep 2020 13:46:28 -
@@ -2,28 +2,30 @@
COMMENT = GTK3 terminal emulator with split-window and tabs
support
-MODPY_EGG_VERSION =1.91
-DISTNAME = terminator-${MODPY_EGG_VERSION}
-REVISION = 1
+VERSION = 1.92
+DISTNAME = terminator-${VERSION}
CATEGORIES = x11
-HOMEPAGE = https://gnometerminator.blogspot.com/p/introduction.html
+HOMEPAGE = https://gnome-terminator.org
# GPLv2
PERMIT_PACKAGE=Yes
-MASTER_SITES =
https://launchpad.net/terminator/gtk3/${MODPY_EGG_VERSION}/+download/
+MASTER_SITES =
https://github.com/gnome-terminator/terminator/releases/download/v${VERSION}/
MODULES = lang/python \
textproc/intltool
+MODPY_VERSION =${MODPY_DEFAULT_VERSION_3}
+
RUN_DEPENDS = devel/desktop-file-utils \
devel/gsettings-desktop-schemas \
- devel/py-gobject3 \
- devel/py-notify \
+ devel/py-configobj${MODPY_FLAVOR} \
+ devel/py-gobject3${MODPY_FLAVOR} \
+ devel/libnotify \
devel/vte3 \
- sysutils/py-psutil \
+ sysutils/py-psutil${MODPY_FLAVOR} \
x11/gtk+3,-guic \
x11/gtk+3 \
x11/keybinder3
Index: distinfo
===
RCS file: /cvs/ports/x11/terminator/distinfo,v
retrieving revision 1.5
diff -u -p -r1.5 distinfo
--- distinfo26 Jun 2018 21:25:04 - 1.5
+++ distinfo9 Sep 2020 13:46:28 -
@@ -1,2 +1,2 @@
-SHA256 (terminator-1.91.tar.gz) = lfduPAJTlW0ZzqsvjacJpJbxuc+bHFuNPNC22jzHvmk=
-SIZE (terminator-1.91.tar.gz) = 910536
+SHA256 (terminator-1.92.tar.gz) = H5TWdq1CyBThWeY3TcqB5OaKwfA/IBM5W6mbacF1c/E=
+SIZE (terminator-1.92.tar.gz) = 910613
Index: pkg/PLIST
===
RCS file: /cvs/ports/x11/terminator/pkg/PLIST,v
retrieving revision 1.9
diff -u -p -r1.9 PLIST
--- pkg/PLIST 29 Jun 2018 22:16:35 - 1.9
+++ pkg/PLIST 9 Sep 2020 13:46:28 -
@@ -2,90 +2,85 @@
bin/remotinator
bin/terminator
bin/terminator.wrapper
-lib/python${MODPY_VERSION}/site-packages/terminator-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info
+lib/python${MODPY_VERSION}/site-packages/terminator-1.92-py${MODPY_VERSION}.egg-info
lib/python${MODPY_VERSION}/site-packages/terminatorlib/
lib/python${MODPY_VERSION}/site-packages/terminatorlib/__init__.py
-lib/python${MODPY_VERSION}/site-packages/terminatorlib/__init__.pyc
+${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/terminatorlib/${MODPY_PYCACHE}/
+lib/python${MODPY_VERSION}/site-packages/terminatorlib/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/terminatorlib/${MODPY_PYCACHE}borg.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/terminatorlib/${MODPY_PYCACHE}config.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/terminatorlib/${MODPY_PYCACHE}container.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/terminatorlib/${MODPY_PYCACHE}cwd.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/terminatorlib/${MODPY_PYCACHE}debugserver.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/terminatorlib/${MODPY_PYCACHE}editablelabel.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/terminatorlib/${MODPY_PYCACHE}encoding.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/terminatorlib/${MODPY_PYCACHE}factory.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/terminatorlib/${MODPY_PYCACHE}freebsd.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/terminatorlib/${MODPY_PYCACHE}ipc.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/terminatorlib/${MODPY_PYCACHE}keybindings.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/terminatorlib/${MODPY_PYCACHE}layoutlauncher.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-package
Re: NEW: net/kdsoap
Looks good to me: + Builds good with minimal requirements in amd64. + make-port-lib-depends-check: OK + make update-plist: Removes one directory: -lib/cmake/ + portcheck: OK I don't have anything to run tests on it. We will know when consumers appear. OK mariani@ Cheers. On Sat, Aug 22, 2020 at 5:25 PM Rafael Sadowski wrote: > > I need kdsoap to update KDE applications to 20.08.0. > > OK? > > Information for inst:kdsoap-1.9.0 > > Comment: > Qt-based client-side and server-side SOAP component > > Description: > KD Soap is a Qt-based client-side and server-side SOAP component. > > It can be used to create client applications for web services and also > provides > the means to create web services without the need for any further component > such as a dedicated web server. > > KD Soap targets C++ programmers who use Qt in their applications. > > Maintainer: The OpenBSD ports mailing-list > > WWW: https://www.kdab.com/development-resources/qt-tools/kd-soap/
Re: cvs diff patch with new directories
That's right. Thanks! A new diff coming soon then. ;) On Wed, Aug 26, 2020 at 4:54 PM Stuart Henderson wrote: > > patch -Ep0 > > On 26 August 2020 20:32:11 "Elias M. Mariani" wrote: > >> Hi ports@, >> Sorry for this silly question. >> I'm trying to generate a diff file for an upcoming x11/lxqt update. >> But if I use "cvs diff > file.diff" and then try to apply it with >> "patch < file.diff" the new directories (*/patches) are not generated >> and the files just... drop in the working directory. (why?) >> The problem goes away if I create the "patches" directories manually. >> Is there a secret flag on cvs diff or patch to generate those directories ? >> I tried looking in man cvs, rcsdiff and patch but I didn't find an >> answer. And my almost zero experience with cvs is not making this >> easier. :) >> >> Cheers. >> Elias mariani@ > >
cvs diff patch with new directories
Hi ports@, Sorry for this silly question. I'm trying to generate a diff file for an upcoming x11/lxqt update. But if I use "cvs diff > file.diff" and then try to apply it with "patch < file.diff" the new directories (*/patches) are not generated and the files just... drop in the working directory. (why?) The problem goes away if I create the "patches" directories manually. Is there a secret flag on cvs diff or patch to generate those directories ? I tried looking in man cvs, rcsdiff and patch but I didn't find an answer. And my almost zero experience with cvs is not making this easier. :) Cheers. Elias mariani@
Re: NEW devel/py-pebble
Looks good to me. OK mariani@ Cheers. On Mon, Aug 10, 2020 at 3:28 PM Björn Ketelaars wrote: > > On Mon 10/08/2020 20:10, Bjorn Ketelaars wrote: > > I would like to import py-pebble, which is needed for a future update of > > devel/py-nbconvert. > > > > DESCR: > > Pebble aims to help managing threads and processes in an easier > > way. It wraps Python’s standard library threading and multiprocessing > > objects. > > > > Output 'make test': > > === 79 passed, 162 skipped in 12.73 seconds > > > > > > OK? > > Oops, DESCR contained an unicode character. New tarball enclosed.
Re: UPDATE: TeX Live 2020
Hi Edd.
I just tested LyX with texlive-2020.
It seems to be working fine.
Side note:
make port-lib-depends-check and portcheck returned some things, OK mariani@
if you look into those (probably some are just heads ups, but I do not know
the port):
make port-lib-depends-check
texlive_base-2020(print/texlive/base,-main):
Missing: pcre.3 from pcre-8.41p2 (/usr/local/bin/xetex)
WANTLIB += pcre
portcheck
executable file: Makefile
1 line(s) longer than 80 chars in Makefile.inc
user settings in port: FETCH_CMD = /usr/bin/ftp -V -m -C -k0
executable file: base/Makefile
executable file: base/distinfo
9 line(s) longer than 80 chars in texmf/Makefile
duplicated assignment of MODRUBY_REV at texmf/Makefile:59
duplicated assignment of MODRUBY_BUILDDEP at texmf/Makefile:60
duplicated assignment of MODRUBY_RUNDEP at texmf/Makefile:61
duplicated assignment of MODPY_BUILDDEP at texmf/Makefile:62
duplicated assignment of MODPY_RUNDEP at texmf/Makefile:63
extra file: texmf/adj.mk
extra file: texmf/man_symlinks.mk
extra file: texmf/manpage_symlinks.mk
extra file: texmf/symlinks.mk
in texmf,-docs: Python module without compiled version, consider using
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py:
share/texmf-dist/doc/generic/c-pascal/prog/fib.py
in texmf,-docs: Python module without compiled version, consider using
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py:
share/texmf-dist/doc/generic/enctex/unimap.py
in texmf,-docs: Python module without compiled version, consider using
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py:
share/texmf-dist/doc/latex/aramaic-serto/serto.py
in texmf,-docs: Python module without compiled version, consider using
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py:
share/texmf-dist/doc/latex/milsymb/manual_scripts/gen_hidden.py
in texmf,-docs: Python module without compiled version, consider using
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py:
share/texmf-dist/doc/latex/milsymb/manual_scripts/gen_symbol_tables.py
in texmf,-docs: Python module without compiled version, consider using
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py:
share/texmf-dist/doc/metapost/metapost-colorbrewer/make_mp_colorbrewer.py
in texmf,-full: Python module without compiled version, consider using
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py:
share/texmf-dist/fonts/source/gregoriotex/convertsfdtottf.py
in texmf,-full: Python module without compiled version, consider using
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py:
share/texmf-dist/fonts/source/gregoriotex/squarize.py
in texmf,-full: Python module without compiled version, consider using
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py:
share/texmf-dist/scripts/changes/pyMergeChanges.py
in texmf,-full: Python module without compiled version, consider using
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py:
share/texmf-dist/scripts/dviasm/dviasm.py
in texmf,-full: Python module without compiled version, consider using
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py:
share/texmf-dist/scripts/latex-papersize/latex-papersize.py
in texmf,-full: Python module without compiled version, consider using
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py:
share/texmf-dist/scripts/lilyglyphs/lily-glyph-commands.py
in texmf,-full: Python module without compiled version, consider using
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py:
share/texmf-dist/scripts/lilyglyphs/lily-image-commands.py
in texmf,-full: Python module without compiled version, consider using
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py:
share/texmf-dist/scripts/lilyglyphs/lily-rebuild-pdfs.py
in texmf,-full: Python module without compiled version, consider using
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py:
share/texmf-dist/scripts/lilyglyphs/lilyglyphs_common.py
in texmf,-full: Python module without compiled version, consider using
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py:
share/texmf-dist/scripts/pygmentex/pygmentex.py
in texmf,-full: Python module without compiled version, consider using
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py:
share/texmf-dist/scripts/pythontex/depythontex.py
in texmf,-full: Python module without compiled version, consider using
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py:
share/texmf-dist/scripts/pythontex/depythontex2.py
in texmf,-full: Python module without compiled version, consider using
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py:
share/texmf-dist/scripts/pythontex/depythontex3.py
in texmf,-full: Python module without compiled version, consider using
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py:
share/texmf-dist/scripts/pythontex/pythontex.py
in texmf,-full: Python module without compiled version, consider using
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py:
share/texmf-dist/scripts/pythontex/pythontex2.py
in texmf,-full: Python module without compiled version, consider using
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py:
share/texmf-dist/scripts/pythontex/pythontex3.py
in texmf,-full: Python module without compiled version, consider using
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py:
share/texmf-dist/scripts/pythontex/pythontex_2to3.py
in texmf,-full:
M. UPDATE: print/lyx 2.3.4.2 to 2.3.5.2
Changelog: https://www.lyx.org/announce/2_3_5_2.txt I don't see anything of impact. Adding PORTROACH so It doesn't inform about version "2.3.x". Tested on amd64. OKs? Cheers. Elias Mariani@ Index: Makefile === RCS file: /cvs/ports/print/lyx/Makefile,v retrieving revision 1.92 diff -u -p -r1.92 Makefile --- Makefile3 Jul 2020 21:13:04 - 1.92 +++ Makefile25 Jul 2020 16:32:39 - @@ -1,9 +1,10 @@ # $OpenBSD: Makefile,v 1.92 2020/07/03 21:13:04 sthen Exp $ +PORTROACH= skipv:2.3.x + COMMENT= graphical frontend for LaTeX (nearly WYSIWYG) -DISTNAME= lyx-2.3.4.2 -REVISION= 0 +DISTNAME= lyx-2.3.5.2 CATEGORIES=print editors Index: distinfo === RCS file: /cvs/ports/print/lyx/distinfo,v retrieving revision 1.18 diff -u -p -r1.18 distinfo --- distinfo16 Mar 2020 02:40:45 - 1.18 +++ distinfo25 Jul 2020 16:32:39 - @@ -1,2 +1,2 @@ -SHA256 (lyx-2.3.4.2.tar.gz) = EQ5jU/Q/Q1mCve8jiZqCEgyXzYwrFBIFNYTsZR3fi+Y= -SIZE (lyx-2.3.4.2.tar.gz) = 27541179 +SHA256 (lyx-2.3.5.2.tar.gz) = Y7dVBdb+0mSn7VH57j5CecHUmjlgwGr+PJTxxyvt6n4= +SIZE (lyx-2.3.5.2.tar.gz) = 27575849 Index: pkg/PLIST === RCS file: /cvs/ports/print/lyx/pkg/PLIST,v retrieving revision 1.28 diff -u -p -r1.28 PLIST --- pkg/PLIST 16 Mar 2020 02:40:45 - 1.28 +++ pkg/PLIST 25 Jul 2020 16:32:39 - @@ -2401,6 +2401,8 @@ share/lyx/layouts/recipebook.layout share/lyx/layouts/report.layout share/lyx/layouts/revtex.layout share/lyx/layouts/revtex4-1.layout +share/lyx/layouts/revtex4-2.layout +share/lyx/layouts/revtex4-x.inc share/lyx/layouts/revtex4.layout share/lyx/layouts/rsphrase.module share/lyx/layouts/sciposter.layout
Re: [update] mail/mu-1.4.1
Hi Miguel.
Not an user of this app so I'm not testing it, I hope someone that can
comes your way.
>From afar looks pretty OK, but you should remove REVISION you sure.
Cheers.
Elias.
On Mon, Apr 27, 2020 at 12:15 PM Miguel wrote:
>
> Hi!
>
> (warning: first port update attempt!)
>
> Please find below an update of mail/mu from 1.2.0 to 1.4.1.
>
> Nothing big worth mentioning, I believe:
> - Use variable to keep version and used it in DISTNAME and MASTER_SITES
> - Update distinfo
> - Refreshed patch (file renamed lib/{parser/utils.cc=>utils/mu-utils.cc}
> - Update PLIST
>
>
> diff --git a/mail/mu/Makefile b/mail/mu/Makefile
> index 2062eae2a347..59ca744309e8 100644
> --- a/mail/mu/Makefile
> +++ b/mail/mu/Makefile
> @@ -1,8 +1,8 @@
> # $OpenBSD: Makefile,v 1.19 2020/01/24 10:36:41 sthen Exp $
>
> COMMENT= maildir indexer and searcher with emacs frontend
> -
> -DISTNAME= mu-1.2.0
> +V= 1.4.1
> +DISTNAME= mu-${V}
> REVISION= 0
>
> CATEGORIES=mail
> @@ -18,7 +18,7 @@ WANTLIB += gmodule-2.0 gobject-2.0 gpg-error gpgme
> gthread-2.0
> WANTLIB += iconv idn2 intl json-glib-1.0 m pcre unistring uuid
> WANTLIB += xapian z
>
> -MASTER_SITES= https://github.com/djcb/mu/releases/download/1.2/
> +MASTER_SITES= https://github.com/djcb/mu/releases/download/${V}/
> EXTRACT_SUFX= .tar.xz
>
> BUILD_DEPENDS= emacs->=24:editors/emacs
> diff --git a/mail/mu/distinfo b/mail/mu/distinfo
> index 437fb1dede15..25f89832cfe7 100644
> --- a/mail/mu/distinfo
> +++ b/mail/mu/distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (mu-1.2.0.tar.xz) = 9jTH8kTcaET/cdw8PhiT5I4ZPKqeDnR+umFjCXdfBTo=
> -SIZE (mu-1.2.0.tar.xz) = 844192
> +SHA256 (mu-1.4.1.tar.xz) =
> 00bbd960821cd7b7ad75246062ad195115dadcdb26bab9beb45167abe35d5dd9
> +SIZE (mu-1.4.1.tar.xz) = 875008
> diff --git a/mail/mu/patches/patch-lib_parser_utils_cc
> b/mail/mu/patches/patch-lib_parser_utils_cc
> index 58e1438e96fa..cef6a7b57378 100644
> --- a/mail/mu/patches/patch-lib_parser_utils_cc
> +++ b/mail/mu/patches/patch-lib_parser_utils_cc
> @@ -1,8 +1,8 @@
> $OpenBSD: patch-lib_parser_utils_cc,v 1.1 2019/07/26 06:41:59 pvk Exp $
> Bring g_vasprintf into scope
> -Index: lib/parser/utils.cc
> lib/parser/utils.cc.orig
> -+++ lib/parser/utils.cc
> +Index: lib/utils/mu-utils.cc
> +--- lib/utils/mu-utils.cc.orig
> lib/utils/mu-utils.cc
> @@ -17,7 +17,7 @@
> ** 02110-1301, USA.
> */
> diff --git a/mail/mu/pkg/PLIST b/mail/mu/pkg/PLIST
> index a24708f574d4..9881f84bfd1a 100644
> --- a/mail/mu/pkg/PLIST
> +++ b/mail/mu/pkg/PLIST
> @@ -8,6 +8,8 @@
> @man man/man1/mu-find.1
> @man man/man1/mu-help.1
> @man man/man1/mu-index.1
> +@man man/man1/mu-info.1
> +@man man/man1/mu-init.1
> @man man/man1/mu-mkdir.1
> @man man/man1/mu-remove.1
> @man man/man1/mu-script.1
> @@ -37,6 +39,8 @@ share/emacs/site-lisp/mu4e/mu4e-draft.el
> share/emacs/site-lisp/mu4e/mu4e-draft.elc
> share/emacs/site-lisp/mu4e/mu4e-headers.el
> share/emacs/site-lisp/mu4e/mu4e-headers.elc
> +share/emacs/site-lisp/mu4e/mu4e-icalendar.el
> +share/emacs/site-lisp/mu4e/mu4e-icalendar.elc
> share/emacs/site-lisp/mu4e/mu4e-lists.el
> share/emacs/site-lisp/mu4e/mu4e-lists.elc
> share/emacs/site-lisp/mu4e/mu4e-main.el
> @@ -47,6 +51,8 @@ share/emacs/site-lisp/mu4e/mu4e-message.el
> share/emacs/site-lisp/mu4e/mu4e-message.elc
> share/emacs/site-lisp/mu4e/mu4e-meta.el
> share/emacs/site-lisp/mu4e/mu4e-meta.elc
> +share/emacs/site-lisp/mu4e/mu4e-org.el
> +share/emacs/site-lisp/mu4e/mu4e-org.elc
> share/emacs/site-lisp/mu4e/mu4e-proc.el
> share/emacs/site-lisp/mu4e/mu4e-proc.elc
> share/emacs/site-lisp/mu4e/mu4e-speedbar.el
> @@ -61,5 +67,3 @@ share/emacs/site-lisp/mu4e/mu4e.el
> share/emacs/site-lisp/mu4e/mu4e.elc
> share/emacs/site-lisp/mu4e/org-mu4e.el
> share/emacs/site-lisp/mu4e/org-mu4e.elc
> -share/emacs/site-lisp/mu4e/org-old-mu4e.el
> -share/emacs/site-lisp/mu4e/org-old-mu4e.elc
>
Re: drop net/GeoIP
OK mariani@
On Tue, Apr 28, 2020 at 8:52 AM Antoine Jacoutot wrote:
>
> On Tue, Apr 28, 2020 at 12:20:44PM +0100, Stuart Henderson wrote:
> > I think it's time for this to go now. No longer used in other ports
> > and the database is EoL. OK?
>
> OK
>
> > Index: devel/quirks/files/Quirks.pm
> > ===
> > RCS file: /cvs/ports/devel/quirks/files/Quirks.pm,v
> > retrieving revision 1.949
> > diff -u -p -r1.949 Quirks.pm
> > --- devel/quirks/files/Quirks.pm 27 Apr 2020 19:52:14 - 1.949
> > +++ devel/quirks/files/Quirks.pm 28 Apr 2020 11:19:36 -
> > @@ -1555,6 +1555,7 @@ my $obsolete_reason = {
> > 'py-iniparse' => 5,
> > 'qtdeclarative-xmllistmodel' => 3,
> > 'jabberd' => 3,
> > + 'GeoIP' => 22,
> > };
> >
> > # reasons for obsolete packages
> > @@ -1581,6 +1582,7 @@ my @msg = (
> > "no longer maintained upstream, suggest sqlitebrowser, kexi", #19
> > "merged into IETF Opus codec, obsolete, audio/mumble uses bundled
> > version now", #20
> > "upstream recommends to use composer to build a drupal site", #21
> > + "the original GeoIP database is end of life; use
> > libmaxminddb/GeoIP2", #22
> > );
> >
> > # ->is_base_system($handle, $state):
> > Index: net/Makefile
> > ===
> > RCS file: /cvs/ports/net/Makefile,v
> > retrieving revision 1.1196
> > diff -u -p -r1.1196 Makefile
> > --- net/Makefile 27 Apr 2020 20:23:00 - 1.1196
> > +++ net/Makefile 28 Apr 2020 11:19:36 -
> > @@ -1,7 +1,6 @@
> > # $OpenBSD: Makefile,v 1.1196 2020/04/27 20:23:00 danj Exp $
> >
> > SUBDIR =
> > - SUBDIR += GeoIP
> > SUBDIR += adns
> > SUBDIR += adsuck
> > SUBDIR += aggregate
> > Index: net/GeoIP/Makefile
> > ===
> > RCS file: net/GeoIP/Makefile
> > diff -N net/GeoIP/Makefile
> > --- net/GeoIP/Makefile16 Jun 2019 23:08:38 - 1.60
> > +++ /dev/null 1 Jan 1970 00:00:00 -
> > @@ -1,50 +0,0 @@
> > -# $OpenBSD: Makefile,v 1.60 2019/06/16 23:08:38 sthen Exp $
> > -
> > -COMMENT-main=find the country where IP address/hostname originates
> > from
> > -COMMENT-db= GeoIP GeoLite database: IPv4/v6 address to country
> > -COMMENT-city=GeoIP GeoLite database: IPv4/v6 address to city
> > -COMMENT-asn= GeoIP GeoLite database: IPv4/v6 address to AS number
> > -
> > -V= 1.6.12
> > -REVISION=2
> > -D= 20180401
> > -DISTNAME=GeoIP-$V
> > -PKGNAME-main=GeoIP-$V
> > -PKGNAME-db= geolite-country-$D
> > -PKGNAME-city=geolite-city-$D
> > -PKGNAME-asn= geolite-asn-$D
> > -PORTROACH= skipv:$V
> > -DISTFILES= ${DISTNAME}${EXTRACT_SUFX} \
> > - geolite-data-$D.tar.xz:0
> > -
> > -SHARED_LIBS += GeoIP9.0 # 7.3
> > -
> > -CATEGORIES= net geo
> > -
> > -HOMEPAGE=https://dev.maxmind.com/geoip/legacy/downloadable/
> > -
> > -# geoip-api-c: LGPLv2.1+
> > -# geolite DBs: CC BY-SA 4.0
> > -PERMIT_PACKAGE= Yes
> > -
> > -WANTLIB-main += c
> > -
> > -MASTER_SITES=
> > https://github.com/maxmind/geoip-api-c/releases/download/v$V/
> > -MASTER_SITES0= https://spacehopper.org/mirrors/
> > -
> > -MULTI_PACKAGES= -main -db -city -asn
> > -RUN_DEPENDS-main= net/GeoIP,-db
> > -
> > -CONFIGURE_STYLE= gnu
> > -SEPARATE_BUILD= Yes
> > -CONFIGURE_ARGS= --datadir=${LOCALSTATEDIR}/db
> > -
> > -post-install:
> > - ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/GeoIP/
> > - ${INSTALL_DATA} ${WRKDIR}/data/* ${PREFIX}/share/examples/GeoIP/
> > - chown -R ${SHAREOWN}:${SHAREGRP} ${PREFIX}/share/examples/GeoIP/
> > -
> > -pre-test:
> > - ln -s ../data ${WRKSRC}/data
> > -
> > -.include
> > Index: net/GeoIP/distinfo
> > ===
> > RCS file: net/GeoIP/distinfo
> > diff -N net/GeoIP/distinfo
> > --- net/GeoIP/distinfo6 Apr 2018 17:14:24 - 1.39
> > +++ /dev/null 1 Jan 1970 00:00:00 -
> > @@ -1,4 +0,0 @@
> > -SHA256 (GeoIP-1.6.12.tar.gz) = Hft0gAPF5Lf9VrqMTNeGYz1db0CVR1hPaRA5g4ljb4A=
> > -SHA256 (geolite-data-20180401.tar.xz) =
> > tN3GrQ5BurBWDSZuB/tuKu6yyLSBvXNXEOeBSWW8mVo=
> > -SIZE (GeoIP-1.6.12.tar.gz) = 473914
> > -SIZE (geolite-data-20180401.tar.xz) = 25773396
> > Index: net/GeoIP/pkg/DESCR-asn
> > ===
> > RCS file: net/GeoIP/pkg/DESCR-asn
> > diff -N net/GeoIP/pkg/DESCR-asn
> > --- net/GeoIP/pkg/DESCR-asn 26 May 2016 15:21:09 - 1.2
> > +++ /dev/null 1 Jan 1970 00:00:00 -
> > @@ -1,9 +0,0 @@
> > -This package contains a snapshot of the free GeoLite ASN databases
> > -under CC BY-SA 4.0 license.
> > -
> > -"This product includes GeoLite data created by MaxMind, available from
> > -http://www.maxmind.com.";
> > -
> > -Free-of-charge city, cou
Re: remote net/jabberd (abandoned project)
If we have alternatives let's not bother with unmaintained software... And yes, maybe someone is using it, but as long as we keep it in the ports tree gives a false sense of continuity... OK mariani@ Cheers. On Mon, Apr 27, 2020 at 9:12 AM Solene Rapenne wrote: > > Taking a look at jabber servers, I found we had net/jabberd which is > abandonned since 1st november 2018. > > Official source repository is archived/read-only > https://github.com/jabberd2/jabberd2 and nothing can happen to it > anymore. It seems no fork made progress compared to the official > repository. > > Official statement from the only jabberd2 developer that he stops > working on it, 20 jan 2018: > https://www.mail-archive.com/jabberd2@lists.xiaoka.com/msg02553.html > > I propose to remove this from ports, it's old and not maintained. > Ejabberd was obsolete in our ports tree but it still developed, this is > one clearly abandoned and dead. > > ok for removal? If so, I'd like to do it before 6.7 so we don't ship > this. >
Re: When installing claws-mail-3.17.4 can't find library croco-0.6.4.0 OpenBSD 6.6
Okey. The explanation: librsvg-2.47.1p1 shouldn't be installed in OpenBSD 6.6. pkg_add can't find the library croco-0.6 in the dependencies of "claws-mail-3.17.4", that is because we recently removed that dependency in 6.7 and librsvg-2.47.1p1 doesn't need nor install libcroco anymore. So, if you had librsvg-2.46.4 (from 6.6) then librsvg resolves the dependency on libcroco. TL;DR: You have a librsvg that is not for 6.6. Why it's installed? I don't know... Did You grabbed packages from snapshots/packages/amd64 or made some installation out of the normal "pkg_add packagename" ? And: You might have other packages not corresponding with 6.6. Cheers. Elias. On Sat, Apr 25, 2020 at 10:10 PM Jon Fineman wrote: > > $: cat /etc/installurl > https://cdn.openbsd.org/pub/OpenBSD > $: > $: echo $PKG_PATH > > $: > > > librsvg-2.47.1p1 is not something I directly installed. Not familiar > with what it is or what it is for. > > > On 2020-04-25 21:03, Elias M. Mariani wrote: > > librsvg-2.47.1p1 ? > > is librsvg-2.46.4 for OpenBSD 6.6: > > https://ftp.openbsd.org/pub/OpenBSD/6.6/packages-stable/amd64/librsvg-2.46.4.tgz > > > > Why do you have librsvg-2.47.1p1 ? > > Where is /etc/installurl or PKG_PATH pointing at? > > > > Cheers. > > Elias. > > > > > > On Sat, Apr 25, 2020 at 9:20 PM Jon Fineman wrote: > >> > >> When trying to install claws-mail I get the bellow error. Prior to this I > >> did a pkg_add -u so I am up to date. > >> > >> The dmesg is below. > >> > >> > >> > >> pkg_add claws-mail > >> Ambiguous: choose package for claws-mail > >> a 0: > >> 1: claws-mail-3.17.4 > >> 2: claws-mail-3.17.4-ldap > >> Your choice: 1 > >> Can't install claws-mail-3.17.4 because of libraries > >> |library croco-0.6.4.0 not found > >> | not found anywhere > >> Direct dependencies for claws-mail-3.17.4 resolve to > >> libcanberra-gtk-0.30p8 libnotify-0.7.8 libetpan-1.9.3 zstd-1.4.4 > >> startup-notification-0.12p6 libb2-0.98.1v0 dbus-glib-0.110p1v0 > >> cyrus-sasl-2.1.27p1 libical-3.0.6 gnutls-3.6.10p0 > >> gtk-update-icon-cache-3.24.13 libnettle-3.5.1p0 enchant-1.6.1p1 > >> libarchive-3.4.0p0 gpgme-1.13.1p0 xz-5.2.4 gtk+2-2.24.32p8 > >> libexecinfo-0.3p2v0 desktop-file-utils-0.24p0 > >> Full dependency tree is glib2-2.62.3 gnome-icon-theme-symbolic-3.12.0p3 > >> curl-7.67.0 cairo-1.16.0 nghttp2-1.40.0 libarchive-3.4.0p0 jasper-2.0.14 > >> sqlite3-3.30.1 .libs-icu4c-64.2p0 libxml-2.9.10 libgcrypt-1.8.5 > >> libical-3.0.6 bzip2-1.0.8 zstd-1.4.4 libunistring-0.9.7 libb2-0.98.1v0 > >> pango-1.42.4p5 libltdl-2.4.2p1 icu4c-65.1p0 gdk-pixbuf-2.40.0p2 > >> libcanberra-gtk-0.30p8 hunspell-1.6.2p0 p11-kit-0.23.18.1 > >> desktop-file-utils-0.24p0 xz-5.2.4 librsvg-2.47.1p1 gtk+2-2.24.32p8 > >> libunbound-1.9.4 shared-mime-info-1.15 atk-2.34.1p1 libgpg-error-1.36p0 > >> gnupg-2.2.12p0 libogg-1.3.4 npth-1.6 harfbuzz-2.6.4p1 tiff-4.1.0 > >> libiconv-1.16p0 libtasn1-4.15.0p0 libnotify-0.7.8 > >> sound-theme-freedesktop-0.8p0 libffi-3.2.1p5 libusb1-1.0.23 > >> libassuan-2.5.1p0 libnettle-3.5.1p0 libksba-1.3.5p2 > >> gnome-icon-theme-3.12.0p5 startup-notification-0.12p6 dbus-glib-0.110p1v0 > >> dbus-1.12.16p0v0 lzo2-2.10p1 libidn2-2.3.0p0 libsecret-0.18.8p0 lz4-1.9.2 > >> pinentry-1.1.0p0 gettext-runtime-0.20.1p0 python-3.7.5p3 pcre-8.41p2 > >> libexecinfo-0.3p2v0 gmp-6.1.2p3 gpgme-1.13.1p0 enchant-1.6.1p1 > >> jpeg-2.0.3v0 graphite2-1.3.13p0 libvorbis-1.3.6 png-1.6.37 > >> gtk-update-icon-cache-3.24.13 cyrus-sasl-2.1.27p1 gnutls-3.6.10p0 > >> db-4.6.21p7v0 libcanberra-0.30p4 aspell-0.60.6.1p10 libetpan-1.9.3 > >> hicolor-icon-theme-0.17 mozilla-dicts-en-GB-1.3p1 fribidi-1.0.7p2 > >> Couldn't install claws-mail-3.17.4 > >>
Re: When installing claws-mail-3.17.4 can't find library croco-0.6.4.0 OpenBSD 6.6
librsvg-2.47.1p1 ? is librsvg-2.46.4 for OpenBSD 6.6: https://ftp.openbsd.org/pub/OpenBSD/6.6/packages-stable/amd64/librsvg-2.46.4.tgz Why do you have librsvg-2.47.1p1 ? Where is /etc/installurl or PKG_PATH pointing at? Cheers. Elias. On Sat, Apr 25, 2020 at 9:20 PM Jon Fineman wrote: > > When trying to install claws-mail I get the bellow error. Prior to this I did > a pkg_add -u so I am up to date. > > The dmesg is below. > > > > pkg_add claws-mail > Ambiguous: choose package for claws-mail > a 0: > 1: claws-mail-3.17.4 > 2: claws-mail-3.17.4-ldap > Your choice: 1 > Can't install claws-mail-3.17.4 because of libraries > |library croco-0.6.4.0 not found > | not found anywhere > Direct dependencies for claws-mail-3.17.4 resolve to libcanberra-gtk-0.30p8 > libnotify-0.7.8 libetpan-1.9.3 zstd-1.4.4 startup-notification-0.12p6 > libb2-0.98.1v0 dbus-glib-0.110p1v0 cyrus-sasl-2.1.27p1 libical-3.0.6 > gnutls-3.6.10p0 gtk-update-icon-cache-3.24.13 libnettle-3.5.1p0 > enchant-1.6.1p1 libarchive-3.4.0p0 gpgme-1.13.1p0 xz-5.2.4 gtk+2-2.24.32p8 > libexecinfo-0.3p2v0 desktop-file-utils-0.24p0 > Full dependency tree is glib2-2.62.3 gnome-icon-theme-symbolic-3.12.0p3 > curl-7.67.0 cairo-1.16.0 nghttp2-1.40.0 libarchive-3.4.0p0 jasper-2.0.14 > sqlite3-3.30.1 .libs-icu4c-64.2p0 libxml-2.9.10 libgcrypt-1.8.5 libical-3.0.6 > bzip2-1.0.8 zstd-1.4.4 libunistring-0.9.7 libb2-0.98.1v0 pango-1.42.4p5 > libltdl-2.4.2p1 icu4c-65.1p0 gdk-pixbuf-2.40.0p2 libcanberra-gtk-0.30p8 > hunspell-1.6.2p0 p11-kit-0.23.18.1 desktop-file-utils-0.24p0 xz-5.2.4 > librsvg-2.47.1p1 gtk+2-2.24.32p8 libunbound-1.9.4 shared-mime-info-1.15 > atk-2.34.1p1 libgpg-error-1.36p0 gnupg-2.2.12p0 libogg-1.3.4 npth-1.6 > harfbuzz-2.6.4p1 tiff-4.1.0 libiconv-1.16p0 libtasn1-4.15.0p0 libnotify-0.7.8 > sound-theme-freedesktop-0.8p0 libffi-3.2.1p5 libusb1-1.0.23 libassuan-2.5.1p0 > libnettle-3.5.1p0 libksba-1.3.5p2 gnome-icon-theme-3.12.0p5 > startup-notification-0.12p6 dbus-glib-0.110p1v0 dbus-1.12.16p0v0 lzo2-2.10p1 > libidn2-2.3.0p0 libsecret-0.18.8p0 lz4-1.9.2 pinentry-1.1.0p0 > gettext-runtime-0.20.1p0 python-3.7.5p3 pcre-8.41p2 libexecinfo-0.3p2v0 > gmp-6.1.2p3 gpgme-1.13.1p0 enchant-1.6.1p1 jpeg-2.0.3v0 graphite2-1.3.13p0 > libvorbis-1.3.6 png-1.6.37 gtk-update-icon-cache-3.24.13 cyrus-sasl-2.1.27p1 > gnutls-3.6.10p0 db-4.6.21p7v0 libcanberra-0.30p4 aspell-0.60.6.1p10 > libetpan-1.9.3 hicolor-icon-theme-0.17 mozilla-dicts-en-GB-1.3p1 > fribidi-1.0.7p2 > Couldn't install claws-mail-3.17.4 > > > > > > > OpenBSD 6.6 (GENERIC.MP) #7: Thu Mar 12 11:55:22 MDT 2020 > > r...@syspatch-66-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 5978714112 (5701MB) > avail mem = 5784809472 (5516MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xdf266000 (27 entries) > bios0: vendor Insyde Corp. version "V1.00" date 03/20/2017 > bios0: Acer Aspire A315-21 > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP MSDM BOOT HPET MCFG WDAT UEFI SSDT IVRS SSDT > SSDT SSDT UEFI SPCR SSDT CRAT TPM2 FPDT ASF! WDRT VFCT SSDT APIC SSDT BGRT > acpi0: wakeup devices GPP1(S4) GPP4(S4) GFX0(S4) GFX1(S4) GFX2(S4) > GFX3(S4) GFX4(S4) EHC1(S3) XHC0(S3) > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpihpet0 at acpi0: 14318180 Hz > acpimcfg0 at acpi0 > acpimcfg0: addr 0xf800, bus 0-63 > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 16 (boot processor) > cpu0: AMD A9-9420 RADEON R5, 5 COMPUTE CORES 2C+3G, 2994.79 MHz, 15-70-00 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,XSAVEOPT > cpu0: 96KB 64b/line 3-way I-cache, 32KB 64b/line 8-way D-cache, 1MB > 64b/line 16-way L2 cache > cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully > associative > cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully > associative > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, IBE > cpu1 at mainbus0: apid 17 (application processor) > cpu1: AMD A9-9420 RADEON R5, 5 COMPUTE CORES 2C+3G, 2994.38 MHz, 15-70-00 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,XSAVEOPT > cpu1: 96KB 64b/line 3-way I-cache, 32KB 64b
M. UPDATE: net/qbittorrent 4.2.4 to 4.2.5
Changelog:
https://github.com/qbittorrent/qBittorrent/blob/release-4.2.5/Changelog#L1
"It contains fixes for two crashes." from:
https://www.qbittorrent.org/news.php
Mostly small bugfixes, nothing of impact.
I don't see why holding for 6.7.
Tested on amd64.
OKs?
Cheers.
Elias mariani@
Index: Makefile.inc
===
RCS file: /cvs/ports/net/qbittorrent/Makefile.inc,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile.inc
--- Makefile.inc23 Apr 2020 21:39:05 - 1.11
+++ Makefile.inc25 Apr 2020 22:47:11 -
@@ -3,7 +3,7 @@
# qmake picks up gcrypt.h even though it's unused
DPB_PROPERTIES = nojunk
-VER = 4.2.4
+VER = 4.2.5
DISTNAME = qbittorrent-${VER}
DIST_SUBDIR = qbittorrent
Index: qbittorrent/distinfo
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent/distinfo,v
retrieving revision 1.8
diff -u -p -r1.8 distinfo
--- qbittorrent/distinfo23 Apr 2020 21:39:05 - 1.8
+++ qbittorrent/distinfo25 Apr 2020 22:47:11 -
@@ -1,2 +1,2 @@
-SHA256 (qbittorrent/qbittorrent-4.2.4.tar.gz) =
LUXSIJETlYp/A/HCj9pwnqp+XF2rXjLmpFtHi1aXtNs=
-SIZE (qbittorrent/qbittorrent-4.2.4.tar.gz) = 7985821
+SHA256 (qbittorrent/qbittorrent-4.2.5.tar.gz) =
i0UICGDxMiuuXhOGb63xMtwaizen6vrGx6MCH6LJeXY=
+SIZE (qbittorrent/qbittorrent-4.2.5.tar.gz) = 7980898
Index: qbittorrent-nox/distinfo
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent-nox/distinfo,v
retrieving revision 1.8
diff -u -p -r1.8 distinfo
--- qbittorrent-nox/distinfo23 Apr 2020 21:39:05 - 1.8
+++ qbittorrent-nox/distinfo25 Apr 2020 22:47:11 -
@@ -1,2 +1,2 @@
-SHA256 (qbittorrent/qbittorrent-4.2.4.tar.gz) =
LUXSIJETlYp/A/HCj9pwnqp+XF2rXjLmpFtHi1aXtNs=
-SIZE (qbittorrent/qbittorrent-4.2.4.tar.gz) = 7985821
+SHA256 (qbittorrent/qbittorrent-4.2.5.tar.gz) =
i0UICGDxMiuuXhOGb63xMtwaizen6vrGx6MCH6LJeXY=
+SIZE (qbittorrent/qbittorrent-4.2.5.tar.gz) = 7980898
M. UPDATE: net/qbittorrent 4.2.3 to 4.2.4
Changelog:
https://github.com/qbittorrent/qBittorrent/blob/release-4.2.4/Changelog#L1
Mostly small bugfixes, nothing of impact.
I don't see why holding for 6.7.
Tested on amd64.
OKs?
Cheers.
Elias mariani@
Index: Makefile.inc
===
RCS file: /cvs/ports/net/qbittorrent/Makefile.inc,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile.inc
--- Makefile.inc4 Apr 2020 18:19:38 - 1.10
+++ Makefile.inc23 Apr 2020 20:09:51 -
@@ -3,7 +3,7 @@
# qmake picks up gcrypt.h even though it's unused
DPB_PROPERTIES = nojunk
-VER = 4.2.3
+VER = 4.2.4
DISTNAME = qbittorrent-${VER}
DIST_SUBDIR = qbittorrent
Index: qbittorrent/distinfo
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- qbittorrent/distinfo4 Apr 2020 18:19:38 - 1.7
+++ qbittorrent/distinfo23 Apr 2020 20:09:51 -
@@ -1,2 +1,2 @@
-SHA256 (qbittorrent/qbittorrent-4.2.3.tar.gz) =
0cbXNUNKnbPXusHopFK8ghVAhp9yIcBjVKjRkUqHp5A=
-SIZE (qbittorrent/qbittorrent-4.2.3.tar.gz) = 7954854
+SHA256 (qbittorrent/qbittorrent-4.2.4.tar.gz) =
LUXSIJETlYp/A/HCj9pwnqp+XF2rXjLmpFtHi1aXtNs=
+SIZE (qbittorrent/qbittorrent-4.2.4.tar.gz) = 7985821
Index: qbittorrent-nox/distinfo
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent-nox/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- qbittorrent-nox/distinfo4 Apr 2020 18:19:38 - 1.7
+++ qbittorrent-nox/distinfo23 Apr 2020 20:09:51 -
@@ -1,2 +1,2 @@
-SHA256 (qbittorrent/qbittorrent-4.2.3.tar.gz) =
0cbXNUNKnbPXusHopFK8ghVAhp9yIcBjVKjRkUqHp5A=
-SIZE (qbittorrent/qbittorrent-4.2.3.tar.gz) = 7954854
+SHA256 (qbittorrent/qbittorrent-4.2.4.tar.gz) =
LUXSIJETlYp/A/HCj9pwnqp+XF2rXjLmpFtHi1aXtNs=
+SIZE (qbittorrent/qbittorrent-4.2.4.tar.gz) = 7985821
Re: python2, remove MESSAGE?
OK mariani@
On Thu, Apr 23, 2020 at 1:23 PM Stuart Henderson wrote:
>
> I don't think it makes sense to suggest making 2.7 the default system Python
> any more, OK for this? I have left UNMESSAGE* because users who have done this
> previously might want a reminder to remove them later.
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/python/2.7/Makefile,v
> retrieving revision 1.66
> diff -u -p -r1.66 Makefile
> --- Makefile23 Apr 2020 07:56:01 - 1.66
> +++ Makefile23 Apr 2020 16:19:49 -
> @@ -10,6 +10,9 @@ PATCHLEVEL = .18
> SHARED_LIBS = python2.7 0.0
> VERSION_SPEC = >=2.7,<2.8
>
> +REVISION-main =0
> +REVISION-idle =0
> +
> CONFIGURE_ARGS += --with-ensurepip=no
> CONFIGURE_ENV += ac_cv_opt_olimit_ok=no
>
> Index: pkg/MESSAGE-idle
> ===
> RCS file: pkg/MESSAGE-idle
> diff -N pkg/MESSAGE-idle
> --- pkg/MESSAGE-idle24 Apr 2011 09:31:46 - 1.1.1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,3 +0,0 @@
> -If you want to use this package as your default system idle, as root
> -create symbolic links like so (overwriting any previous default):
> - ln -sf ${PREFIX}/bin/idle2.7 ${PREFIX}/bin/idle
> Index: pkg/MESSAGE-main
> ===
> RCS file: pkg/MESSAGE-main
> diff -N pkg/MESSAGE-main
> --- pkg/MESSAGE-main3 May 2011 17:18:28 - 1.2
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,6 +0,0 @@
> -If you want to use this package as your default system python, as root
> -create symbolic links like so (overwriting any previous default):
> - ln -sf ${PREFIX}/bin/python2.7 ${PREFIX}/bin/python
> - ln -sf ${PREFIX}/bin/python2.7-2to3 ${PREFIX}/bin/2to3
> - ln -sf ${PREFIX}/bin/python2.7-config ${PREFIX}/bin/python-config
> - ln -sf ${PREFIX}/bin/pydoc2.7 ${PREFIX}/bin/pydoc
>
UPDATE: www/ap2-mod_wsgi 4.6.5 to 4.7.1
Changelogs:
https://github.com/GrahamDumpleton/mod_wsgi/blob/4.7.1/docs/release-notes/version-4.6.6.rst
https://github.com/GrahamDumpleton/mod_wsgi/blob/4.7.1/docs/release-notes/version-4.6.7.rst
https://github.com/GrahamDumpleton/mod_wsgi/blob/4.7.1/docs/release-notes/version-4.6.8.rst
https://github.com/GrahamDumpleton/mod_wsgi/blob/4.7.1/docs/release-notes/version-4.7.0.rst
https://github.com/GrahamDumpleton/mod_wsgi/blob/4.7.1/docs/release-notes/version-4.7.1.rst
Nothing of impact as we only compile the module, we are not using the python
utilities.
But I did notice that several (all) the compilation warnings have disappeared.
Moved from py2 to py3.
I could make a flavor, but I think that is better to just drop the py2 version.
It has no consumers in our tree.
The only "WHAT-IF" would be if someone is using this port to run a py2 app...
When they update in 6.7 (or snapshots) it might cease to function properly.
I think that: "py2 is deprecated" is a nice answer, but I let you decide with
your OKs. :)
WANTLIB += iconv intl added from port-lib-depends-check.
+ Tested with py3-flask on amd64.
I only used it (with py3) to test some flask apps for my personal work.
jca@ (If I remember correctly) give me the idea to send it to ports@.
OKs?
Cheers.
Elias.
Index: Makefile
===
RCS file: /cvs/ports/www/ap2-mod_wsgi/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- Makefile12 Jul 2019 20:50:17 - 1.10
+++ Makefile15 Apr 2020 16:07:48 -
@@ -3,22 +3,23 @@
COMMENT= Python WSGI compliant interface module for Apache2
PKGNAME= ap2-mod_wsgi-${GH_TAGNAME}
-REVISION= 0
CATEGORIES=www
GH_ACCOUNT=GrahamDumpleton
GH_PROJECT=mod_wsgi
-GH_TAGNAME=4.6.5
+GH_TAGNAME=4.7.1
HOMEPAGE= https://modwsgi.readthedocs.io/
# Apache License 2.0
PERMIT_PACKAGE=Yes
-WANTLIB += m pthread ${MODPY_WANTLIB} util
+WANTLIB += iconv intl m pthread ${MODPY_WANTLIB} util
MODULES= lang/python
+
+MODPY_VERSION= ${MODPY_DEFAULT_VERSION_3}
LIB_DEPENDS= ${MODPY_LIB_DEPENDS}
Index: distinfo
===
RCS file: /cvs/ports/www/ap2-mod_wsgi/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo24 Oct 2018 13:13:32 - 1.3
+++ distinfo15 Apr 2020 16:07:48 -
@@ -1,2 +1,2 @@
-SHA256 (mod_wsgi-4.6.5.tar.gz) = XL4F+LmyGp5A1dcib0l2ZDse5eI6LRFLzq402ZSL5eA=
-SIZE (mod_wsgi-4.6.5.tar.gz) = 693825
+SHA256 (mod_wsgi-4.7.1.tar.gz) = JnTlBnGa/mD7wFR8gy6JSNbKouBU1A0zYwmZPm6GfTU=
+SIZE (mod_wsgi-4.7.1.tar.gz) = 696111
Index: pkg/PLIST
===
RCS file: /cvs/ports/www/ap2-mod_wsgi/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -r1.2 PLIST
--- pkg/PLIST 4 Sep 2018 12:46:24 - 1.2
+++ pkg/PLIST 15 Apr 2020 16:07:48 -
@@ -1,3 +1,3 @@
@comment $OpenBSD: PLIST,v 1.2 2018/09/04 12:46:24 espie Exp $
-lib/apache2/mod_wsgi.so
+@so lib/apache2/mod_wsgi.so
share/doc/pkg-readmes/${PKGSTEM}
Re: [UPDATE]: games/freeorion 0.49
Great Tom,
OK mariani@
I tried to compile and got "out-of-memory" issues, but is probably
just my old PC.
That is why I'm taking your word on compiling an running.
Cheers.
Elias.
On Sat, Apr 11, 2020 at 10:52 AM Tom Murphy wrote:
>
> On Fri, Apr 10, 2020 at 11:05:33AM -0300, Elias M. Mariani wrote:
> > Hi Tom,
> > - You should remove REVISION.
> > - The patch has an offset:
> > Patching file CMakeLists.txt using Plan A...
> > Hunk #1 succeeded at 459 (offset 65 lines).
> >
> > A make update-patches should fix it.
> >
> > OK mariani@ with those changes.
> > I take your word on compiling and running. :)
> >
> > Cheers.
> > Elias.
>
> Hi Elias,
>
>Many thanks for the review! I've removed REVISION and
>updated the patch. Here's the new diff below.
>
>Thanks,
>Tom
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/games/freeorion/Makefile,v
> retrieving revision 1.5
> diff -u -p -u -p -r1.5 Makefile
> --- Makefile23 Nov 2019 22:08:42 - 1.5
> +++ Makefile11 Apr 2020 13:50:05 -
> @@ -1,11 +1,10 @@
> # $OpenBSD: Makefile,v 1.5 2019/11/23 22:08:42 cwen Exp $
>
> -V =0.4.8
> +V =0.4.9
> COMMENT = turn-based space empire and galactic conquest computer game
> -DISTNAME = FreeOrion_v${V}_2018-08-23.26f16b0_Source
> +DISTNAME = FreeOrion_v${V}_2020-02-02.db53471_Source
> PKGNAME = freeorion-${V}
> CATEGORIES = games
> -REVISION = 1
>
> HOMEPAGE = https://www.freeorion.org/
> MAINTAINER = Tom Murphy
> @@ -18,7 +17,7 @@ WANTLIB += ${COMPILER_LIBCXX} GL GLEW GL
> WANTLIB += boost_chrono-mt boost_date_time-mt boost_filesystem-mt
> WANTLIB += boost_iostreams-mt boost_locale-mt boost_log-mt boost_log_setup-mt
> WANTLIB += boost_python-mt boost_regex-mt boost_serialization-mt
> -WANTLIB += boost_signals-mt boost_system-mt boost_thread-mt c
> +WANTLIB += boost_system-mt boost_thread-mt c
> WANTLIB += freetype m ogg openal png ${MODPY_WANTLIB} vorbis vorbisenc
> WANTLIB += vorbisfile z
>
> Index: distinfo
> ===
> RCS file: /cvs/ports/games/freeorion/distinfo,v
> retrieving revision 1.1.1.1
> diff -u -p -u -p -r1.1.1.1 distinfo
> --- distinfo3 Oct 2018 11:43:46 - 1.1.1.1
> +++ distinfo11 Apr 2020 13:50:05 -
> @@ -1,2 +1,2 @@
> -SHA256 (FreeOrion_v0.4.8_2018-08-23.26f16b0_Source.tar.gz) =
> 1AXb60Ovt/p2k3zxXNsQsV6BjaFx7B6wPkocPsu6Rvc=
> -SIZE (FreeOrion_v0.4.8_2018-08-23.26f16b0_Source.tar.gz) = 106254059
> +SHA256 (FreeOrion_v0.4.9_2020-02-02.db53471_Source.tar.gz) =
> Vomzpsq55s+8g9joLvMlu54AcRJi0msEbwg+pf3E1uE=
> +SIZE (FreeOrion_v0.4.9_2020-02-02.db53471_Source.tar.gz) = 124662273
> Index: patches/patch-CMakeLists_txt
> ===
> RCS file: /cvs/ports/games/freeorion/patches/patch-CMakeLists_txt,v
> retrieving revision 1.1
> diff -u -p -u -p -r1.1 patch-CMakeLists_txt
> --- patches/patch-CMakeLists_txt1 Nov 2019 19:17:31 - 1.1
> +++ patches/patch-CMakeLists_txt11 Apr 2020 13:50:05 -
> @@ -4,7 +4,7 @@ Remove hardcoded optimisation option.
> Index: CMakeLists.txt
> --- CMakeLists.txt.orig
> +++ CMakeLists.txt
> -@@ -394,7 +394,6 @@ target_compile_options(freeorionparseobj
> +@@ -459,7 +459,6 @@ target_compile_options(freeorionparseobj
> $<$:-fvisibility=hidden>
> $<$:-ftemplate-depth=512>
> $<$:-ftemplate-depth=512>
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/games/freeorion/pkg/PLIST,v
> retrieving revision 1.1.1.1
> diff -u -p -u -p -r1.1.1.1 PLIST
> --- pkg/PLIST 3 Oct 2018 11:43:48 - 1.1.1.1
> +++ pkg/PLIST 11 Apr 2020 13:50:06 -
> @@ -3,10 +3,10 @@
> @bin bin/freeorionca
> @bin bin/freeoriond
> lib/freeorion/
> -lib/freeorion/libGiGi.so
> -lib/freeorion/libGiGiSDL.so
> -lib/freeorion/libfreeorioncommon.so
> -lib/freeorion/libfreeorionparse.so
> +@so lib/freeorion/libGiGi.so
> +@so lib/freeorion/libGiGiSDL.so
> +@so lib/freeorion/libfreeorioncommon.so
> +@so lib/freeorion/libfreeorionparse.so
> share/applications/freeorion.desktop
> share/freeorion/
> share/freeorion/default/
> @@ -48,7 +48,11 @@ share/freeorion/default/data/art/encyclo
>
> share/freeorion/default/data/art/encyclopedia/planet_environments/pt_toxic02.png
>
> share/freeorion/default/data/art/encyclopedia/planet_environments/pt_tundra.png
> share/freeorion/default/data/art/fie
Re: [UPDATE]: games/freeorion 0.49
Hi Tom,
- You should remove REVISION.
- The patch has an offset:
Patching file CMakeLists.txt using Plan A...
Hunk #1 succeeded at 459 (offset 65 lines).
A make update-patches should fix it.
OK mariani@ with those changes.
I take your word on compiling and running. :)
Cheers.
Elias.
On Fri, Apr 10, 2020 at 7:29 AM Tom Murphy wrote:
>
> Hi,
>
> Attached is a diff to bring games/freeorion to 0.4.9.
> I removed boost_signals-mt from WANTLIB since it was
> being listed as an extra lib.
>
> Compiles fine and runs for me.
>
> OK?
>
> Thanks,
> Tom
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/games/freeorion/Makefile,v
> retrieving revision 1.5
> diff -u -p -u -p -r1.5 Makefile
> --- Makefile23 Nov 2019 22:08:42 - 1.5
> +++ Makefile10 Apr 2020 08:55:18 -
> @@ -1,8 +1,8 @@
> # $OpenBSD: Makefile,v 1.5 2019/11/23 22:08:42 cwen Exp $
>
> -V =0.4.8
> +V =0.4.9
> COMMENT = turn-based space empire and galactic conquest computer game
> -DISTNAME = FreeOrion_v${V}_2018-08-23.26f16b0_Source
> +DISTNAME = FreeOrion_v${V}_2020-02-02.db53471_Source
> PKGNAME = freeorion-${V}
> CATEGORIES = games
> REVISION = 1
> @@ -18,7 +18,7 @@ WANTLIB += ${COMPILER_LIBCXX} GL GLEW GL
> WANTLIB += boost_chrono-mt boost_date_time-mt boost_filesystem-mt
> WANTLIB += boost_iostreams-mt boost_locale-mt boost_log-mt boost_log_setup-mt
> WANTLIB += boost_python-mt boost_regex-mt boost_serialization-mt
> -WANTLIB += boost_signals-mt boost_system-mt boost_thread-mt c
> +WANTLIB += boost_system-mt boost_thread-mt c
> WANTLIB += freetype m ogg openal png ${MODPY_WANTLIB} vorbis vorbisenc
> WANTLIB += vorbisfile z
>
> Index: distinfo
> ===
> RCS file: /cvs/ports/games/freeorion/distinfo,v
> retrieving revision 1.1.1.1
> diff -u -p -u -p -r1.1.1.1 distinfo
> --- distinfo3 Oct 2018 11:43:46 - 1.1.1.1
> +++ distinfo10 Apr 2020 08:55:18 -
> @@ -1,2 +1,2 @@
> -SHA256 (FreeOrion_v0.4.8_2018-08-23.26f16b0_Source.tar.gz) =
> 1AXb60Ovt/p2k3zxXNsQsV6BjaFx7B6wPkocPsu6Rvc=
> -SIZE (FreeOrion_v0.4.8_2018-08-23.26f16b0_Source.tar.gz) = 106254059
> +SHA256 (FreeOrion_v0.4.9_2020-02-02.db53471_Source.tar.gz) =
> Vomzpsq55s+8g9joLvMlu54AcRJi0msEbwg+pf3E1uE=
> +SIZE (FreeOrion_v0.4.9_2020-02-02.db53471_Source.tar.gz) = 124662273
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/games/freeorion/pkg/PLIST,v
> retrieving revision 1.1.1.1
> diff -u -p -u -p -r1.1.1.1 PLIST
> --- pkg/PLIST 3 Oct 2018 11:43:48 - 1.1.1.1
> +++ pkg/PLIST 10 Apr 2020 08:55:18 -
> @@ -3,10 +3,10 @@
> @bin bin/freeorionca
> @bin bin/freeoriond
> lib/freeorion/
> -lib/freeorion/libGiGi.so
> -lib/freeorion/libGiGiSDL.so
> -lib/freeorion/libfreeorioncommon.so
> -lib/freeorion/libfreeorionparse.so
> +@so lib/freeorion/libGiGi.so
> +@so lib/freeorion/libGiGiSDL.so
> +@so lib/freeorion/libfreeorioncommon.so
> +@so lib/freeorion/libfreeorionparse.so
> share/applications/freeorion.desktop
> share/freeorion/
> share/freeorion/default/
> @@ -48,7 +48,11 @@ share/freeorion/default/data/art/encyclo
>
> share/freeorion/default/data/art/encyclopedia/planet_environments/pt_toxic02.png
>
> share/freeorion/default/data/art/encyclopedia/planet_environments/pt_tundra.png
> share/freeorion/default/data/art/fields/
> -share/freeorion/default/data/art/fields/rainbow_storm.png
> +share/freeorion/default/data/art/fields/accretion_disc.png
> +share/freeorion/default/data/art/fields/ion_storm.png
> +share/freeorion/default/data/art/fields/molecular_cloud.png
> +share/freeorion/default/data/art/fields/star_forming_nebula_1.png
> +share/freeorion/default/data/art/fields/star_forming_nebula_2.png
> share/freeorion/default/data/art/galaxy_decoration/
> share/freeorion/default/data/art/galaxy_decoration/blue_set/
> share/freeorion/default/data/art/galaxy_decoration/blue_set/gaseous01.png
> @@ -527,6 +531,11 @@ share/freeorion/default/data/art/icons/p
> share/freeorion/default/data/art/icons/planet/tiny.png
> share/freeorion/default/data/art/icons/planet/toxic.png
> share/freeorion/default/data/art/icons/planet/tundra.png
> +share/freeorion/default/data/art/icons/planet_status_attacked.png
> +share/freeorion/default/data/art/icons/planet_status_conquered.png
> +share/freeorion/default/data/art/icons/planet_status_supply.png
> +share/freeorion/default/data/art/icons/planet_status_unhappy.png
> +share/freeorion/default/data/art/icons/planet_status_warning.png
> share/freeorion/default/data/art/icons/ready.png
> share/freeorion/default/data/art/icons/ship_hulls/
>
> share/freeorion/default/data/art/icons/ship_hulls/agregate_asteroid_hull_small.png
> @@ -700,6 +709,7 @@ share/freeorion/default/data/art/icons/s
> share/freeorion/default/data/art/icons/sitrep/tech_researched.png
>
Re: Move x11/kde-applications/kcalcore to devel/kf5/kcalendarcore
OK mariani@ Cheers. Elias. On Sat, Apr 4, 2020 at 11:36 AM Rafael Sadowski wrote: > > On Wed Mar 25, 2020 at 07:22:01AM +0100, Rafael Sadowski wrote: > > kcalendarcore formals kcalcore moved from KDE applications to KDE > > framwork. Attached port based on kcalcore with additional changes: > > > > - Rename to kcalendarcore > > - libKF5CalendarCore bump > > - @pkgpath x11/kde-applications/kcalcore and @conflict kcalcore-* > > - Update tested: > >kcalcore-18.12.0p0->kcalendarcore-5.68.0: ok > > > > OK to import? > > > > pkg_info: > > Information for inst:kcalendarcore-5.68.0 > > > > Comment: > > The KDE calendar access library > > > > Description: > > This library provides access to and handling of calendar data. It supports > > the > > standard formats iCalendar and vCalendar and the group scheduling standard > > iTIP. > > > > Maintainer: Rafael Sadowski > > > > WWW: https://projects.kde.org/projects/frameworks/kcalendarcore > > > > Opinions? It's just an cvs move but it's hard to import ports without an > okay :) >
Re: NEW: devel/kf5/syndication
Hi Rafael,
I think that you are missing a LIB_DEPENDS and WANTLIB.
Also, some dirs are not found by make update-plist.
I send you a diff.
OK mariani@ with those changes.
Cheers.
Elias.
--- MakefileWed Mar 25 03:35:20 2020
+++ Makefile.orig Sat Apr 4 19:22:27 2020
@@ -5,6 +5,8 @@
SHARED_LIBS = KF5Syndication0.0 # 5.68
-WANTLIB += ${COMPILER_LIBCXX} Qt5Core Qt5Xml m
+LIB_DEPENDS += devel/kf5/kcodecs
+
+WANTLIB += ${COMPILER_LIBCXX} KF5Codecs Qt5Core Qt5Xml m
.include
--- pkg/PLIST Sat Apr 4 19:29:07 2020
+++ pkg/PLIST.orig Wed Mar 25 03:31:51 2020
@@ -1,4 +1,5 @@
@comment $OpenBSD: PLIST,v$
+include/KF5/
include/KF5/Syndication/
include/KF5/Syndication/Syndication/
include/KF5/Syndication/Syndication/AbstractParser
@@ -140,11 +141,15 @@
include/KF5/Syndication/syndication/syndication_export.h
include/KF5/Syndication/syndication/tools.h
include/KF5/syndication_version.h
+lib/cmake/
lib/cmake/KF5Syndication/
lib/cmake/KF5Syndication/KF5SyndicationConfig.cmake
lib/cmake/KF5Syndication/KF5SyndicationConfigVersion.cmake
lib/cmake/KF5Syndication/KF5SyndicationTargets${MODCMAKE_BUILD_SUFFIX}
lib/cmake/KF5Syndication/KF5SyndicationTargets.cmake
@lib lib/libKF5Syndication.so.${LIBKF5Syndication_VERSION}
+share/kf5/
+share/kf5/mkspecs/
share/kf5/mkspecs/qt_Syndication.pri
+share/qlogging-categories5/
share/qlogging-categories5/syndication.categories
On Sat, Apr 4, 2020 at 11:37 AM Rafael Sadowski wrote:
>
> On Wed Mar 25, 2020 at 07:38:32AM +0100, Rafael Sadowski wrote:
> > New KDE framework syndication, simple RSS/Atom parser library. All tests
> > passed: 100% tests passed, 0 tests failed out of 3
> >
> > OK to import?
> >
> > Information for inst:syndication-5.68.0
> >
> > Comment:
> > RSS/Atom parser library
> >
> > Description:
> > RSS (0.9/1.0, 0.91..2.0) and Atom (0.3 and 1.0) feeds are supported.
> > syndication offers a unified, format-agnostic view on the parsed feed, so
> > that
> > the using application does not need to distinguish between feed formats.
> >
> > Maintainer: Rafael Sadowski
> >
> > WWW: https://projects.kde.org/projects/frameworks/syndication
>
> ping
>
Re: Move x11/kde-applications/kcontacts to devel/kf5/kcontacts
OK mariani@ Cheers. Elias. On Sat, Apr 4, 2020 at 11:37 AM Rafael Sadowski wrote: > > On Wed Mar 25, 2020 at 07:10:55AM +0100, Rafael Sadowski wrote: > > Please find a attached kcontacts-5.68.0v0.tar.gz. kcontacts moved from > > the KDE applications to the KDE framework. Changes: > > > > - shared lib major bump > > - EPOCH (18.12.0 to 5.68.0) > > - @pkgpath x11/kde-applications/kcontacts > > > > OK? > > Opinions? It's just an cvs move but it's hard to import ports without an > okay :) >
Re: UPDATE: net/qbittorrent 4.2.2 to 4.2.3
Sorry, First time sending an inline patch, with errors...
Thanks to @rsadowski for pointing it out.
OKs?
Cheers.
Elias mariani@
Index: Makefile.inc
===
RCS file: /cvs/ports/net/qbittorrent/Makefile.inc,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile.inc
--- Makefile.inc28 Mar 2020 19:48:15 - 1.9
+++ Makefile.inc4 Apr 2020 02:33:56 -
@@ -3,7 +3,7 @@
# qmake picks up gcrypt.h even though it's unused
DPB_PROPERTIES = nojunk
-VER = 4.2.2
+VER = 4.2.3
DISTNAME = qbittorrent-${VER}
DIST_SUBDIR = qbittorrent
@@ -11,6 +11,8 @@ DIST_SUBDIR = qbittorrent
CATEGORIES ?= net
HOMEPAGE ?=https://www.qbittorrent.org
+
+MAINTAINER = Elias M. Mariani
# GPLv2
PERMIT_PACKAGE = Yes
Index: qbittorrent/distinfo
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- qbittorrent/distinfo28 Mar 2020 19:48:15 - 1.6
+++ qbittorrent/distinfo4 Apr 2020 02:33:56 -
@@ -1,2 +1,2 @@
-SHA256 (qbittorrent/qbittorrent-4.2.2.tar.gz) =
6TYap1X0fGBKLuLyxD+EpMRrGI4k+E6zY+MWfFf2UlM=
-SIZE (qbittorrent/qbittorrent-4.2.2.tar.gz) = 7967426
+SHA256 (qbittorrent/qbittorrent-4.2.3.tar.gz) =
0cbXNUNKnbPXusHopFK8ghVAhp9yIcBjVKjRkUqHp5A=
+SIZE (qbittorrent/qbittorrent-4.2.3.tar.gz) = 7954854
Index: qbittorrent-nox/distinfo
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent-nox/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- qbittorrent-nox/distinfo28 Mar 2020 19:48:15 - 1.6
+++ qbittorrent-nox/distinfo4 Apr 2020 02:33:56 -
@@ -1,2 +1,2 @@
-SHA256 (qbittorrent/qbittorrent-4.2.2.tar.gz) =
6TYap1X0fGBKLuLyxD+EpMRrGI4k+E6zY+MWfFf2UlM=
-SIZE (qbittorrent/qbittorrent-4.2.2.tar.gz) = 7967426
+SHA256 (qbittorrent/qbittorrent-4.2.3.tar.gz) =
0cbXNUNKnbPXusHopFK8ghVAhp9yIcBjVKjRkUqHp5A=
+SIZE (qbittorrent/qbittorrent-4.2.3.tar.gz) = 7954854
UPDATE: net/qbittorrent 4.2.2 to 4.2.3
Update for net/qbittorrent/qbittorrent and net/qbittorrent/qbittorrent-nox
Changelog:
https://github.com/qbittorrent/qBittorrent/blob/release-4.2.3/Changelog
Tested OK on amd64.
Taking MAINTAINER (I forgot the last time...)
OKs?
Cheers.
Elias mariani@
Index: Makefile.inc
===
RCS file: /cvs/ports/net/qbittorrent/Makefile.inc,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile.inc
--- Makefile.inc28 Mar 2020 19:48:15 - 1.9
+++ Makefile.inc4 Apr 2020 02:33:56 -
@@ -3,7 +3,7 @@
# qmake picks up gcrypt.h even though it's unused
DPB_PROPERTIES = nojunk
-VER = 4.2.2
+VER = 4.2.3
DISTNAME = qbittorrent-${VER}
DIST_SUBDIR = qbittorrent
@@ -11,6 +11,8 @@ DIST_SUBDIR = qbittorrent
CATEGORIES ?= net
HOMEPAGE ?=https://www.qbittorrent.org
+
+MAINTAINER = Elias M. Mariani
# GPLv2
PERMIT_PACKAGE = Yes
Index: qbittorrent/distinfo
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- qbittorrent/distinfo28 Mar 2020 19:48:15 - 1.6
+++ qbittorrent/distinfo4 Apr 2020 02:33:56 -
@@ -1,2 +1,2 @@
-SHA256 (qbittorrent/qbittorrent-4.2.2.tar.gz) =
6TYap1X0fGBKLuLyxD+EpMRrGI4k+E6zY+MWfFf2UlM=
-SIZE (qbittorrent/qbittorrent-4.2.2.tar.gz) = 7967426
+SHA256 (qbittorrent/qbittorrent-4.2.3.tar.gz) =
0cbXNUNKnbPXusHopFK8ghVAhp9yIcBjVKjRkUqHp5A=
+SIZE (qbittorrent/qbittorrent-4.2.3.tar.gz) = 7954854
Index: qbittorrent-nox/distinfo
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent-nox/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- qbittorrent-nox/distinfo28 Mar 2020 19:48:15 - 1.6
+++ qbittorrent-nox/distinfo4 Apr 2020 02:33:56 -
@@ -1,2 +1,2 @@
-SHA256 (qbittorrent/qbittorrent-4.2.2.tar.gz) =
6TYap1X0fGBKLuLyxD+EpMRrGI4k+E6zY+MWfFf2UlM=
-SIZE (qbittorrent/qbittorrent-4.2.2.tar.gz) = 7967426
+SHA256 (qbittorrent/qbittorrent-4.2.3.tar.gz) =
0cbXNUNKnbPXusHopFK8ghVAhp9yIcBjVKjRkUqHp5A=
+SIZE (qbittorrent/qbittorrent-4.2.3.tar.gz) = 7954854
Re: UPDATE: net/weechat
Tested on amd64.
make port-lib-depends-check
weechat-ruby-2.8(net/weechat,-ruby):
Extra: c.96 gmp.11 m.10 pthread.26 ruby26.0
Is this right? If It is:
OK mariani@
Cheers.
Elias.
On Mon, Mar 30, 2020 at 1:27 AM Rafael Sadowski wrote:
>
> Simple update to the latest stable version. Changelog:
> https://weechat.org/news/109/20200329-Version-2.8/
>
> OK?
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/net/weechat/Makefile,v
> retrieving revision 1.46
> diff -u -p -u -p -r1.46 Makefile
> --- Makefile21 Feb 2020 15:29:13 - 1.46
> +++ Makefile30 Mar 2020 04:24:53 -
> @@ -6,7 +6,7 @@ COMMENT-python= Python bindings for weec
> COMMENT-ruby= Ruby bindings for weechat
> COMMENT-tcl= Tcl bindings for weechat
>
> -V= 2.7.1
> +V= 2.8
> DISTNAME= weechat-${V}
>
> PKGNAME-main= weechat-${V}
> Index: distinfo
> ===
> RCS file: /cvs/ports/net/weechat/distinfo,v
> retrieving revision 1.25
> diff -u -p -u -p -r1.25 distinfo
> --- distinfo21 Feb 2020 15:29:13 - 1.25
> +++ distinfo30 Mar 2020 04:24:53 -
> @@ -1,2 +1,2 @@
> -SHA256 (weechat-2.7.1.tar.gz) = xBDqe4/ellP4yd+IZ9Pua0zI+4diYLZYhCJ6S/YTlaU=
> -SIZE (weechat-2.7.1.tar.gz) = 4394236
> +SHA256 (weechat-2.8.tar.gz) = adpodOLVg7SkZmsWb1IO5FtqyEVEpKlDQDD4KYmJPIg=
> +SIZE (weechat-2.8.tar.gz) = 4442035
> Index: patches/patch-tests_CMakeLists_txt
> ===
> RCS file: /cvs/ports/net/weechat/patches/patch-tests_CMakeLists_txt,v
> retrieving revision 1.3
> diff -u -p -u -p -r1.3 patch-tests_CMakeLists_txt
> --- patches/patch-tests_CMakeLists_txt 11 Jan 2020 07:26:00 - 1.3
> +++ patches/patch-tests_CMakeLists_txt 30 Mar 2020 04:24:53 -
> @@ -3,7 +3,7 @@ $OpenBSD: patch-tests_CMakeLists_txt,v 1
> Index: tests/CMakeLists.txt
> --- tests/CMakeLists.txt.orig
> +++ tests/CMakeLists.txt
> -@@ -61,7 +61,7 @@ if(ICONV_LIBRARY)
> +@@ -63,7 +63,7 @@ if(ICONV_LIBRARY)
> list(APPEND EXTRA_LIBS ${ICONV_LIBRARY})
> endif()
>
>
Re: UPDATE: net/qbittorrent 4.2.1 to 4.2.2
> Please inline patches. Sorry, using mail.google.com. I will lookup for a client that doesn't break the format of the diff... Bear with me on this one... > Why not using the lang/python module as usual? You are right, I should have used MODULES. Is this OK with you? I used MODPY_BUILDDEP = No to avoid the BUILD_DEPENDS on python. On Fri, Mar 27, 2020 at 12:01 PM Klemens Nanni wrote: > > On Wed, Mar 25, 2020 at 06:17:11AM -0300, Elias M. Mariani wrote: > > Update for net/qbittorrent/qbittorrent and net/qbittorrent/qbittorrent-nox > > > > Changelog: > > https://github.com/qbittorrent/qBittorrent/blob/release-4.2.2/Changelog > > > > Important change: > > - SEARCH: Drop python2 support > > > > So jumping from lang/python/2.7 to lang/python/3.7, this is only a > > RUN_DEPENDS for the search plugins. > > > > Tested OK on amd64. > > > > Taking MAINTAINER (again...) > Please inline patches. > > Why not using the lang/python module as usual? qbittorrent-4.2.2.diff Description: Binary data
UPDATE: net/qbittorrent 4.2.1 to 4.2.2
Update for net/qbittorrent/qbittorrent and net/qbittorrent/qbittorrent-nox Changelog: https://github.com/qbittorrent/qBittorrent/blob/release-4.2.2/Changelog Important change: - SEARCH: Drop python2 support So jumping from lang/python/2.7 to lang/python/3.7, this is only a RUN_DEPENDS for the search plugins. Tested OK on amd64. Taking MAINTAINER (again...) OKs? Cheers. Elias mariani@ qbittorrent-4.2.2.diff Description: Binary data
REVISION: devel/py-jedi and devel/py-parso to python3 only
The only consumers of py-jedi are: - devel/spyder/spyder,python3 - x11/gnome/builder Both using devel/py-jedi,python3, moving to py3-jedi only. Then the only consumer of devel/py-parso becomes: devel/py-jedi,python3 Also moving to py3-parso only. diff missing quirks and Makefile unhooks, will do when committing. I'm not updating them for now, we should check for compatibility with spyder and gnome-builder for that. OK? Cheers. Elias mariani@ py-jedi.diff Description: Binary data py-parso.diff Description: Binary data
Re: UPDATE math/py-pandas-1.0.3
My bad looking at sqlports... OK mariani@ On Sat, Mar 21, 2020 at 12:32 PM Bjorn Ketelaars wrote: > > On Sat 21/03/2020 11:58, Elias M. Mariani wrote: > > This version has: > > python_requires=">=3.6.1" > > (1.0.1 had the same) > > > > If you are sure that this still works on py2 (which still has consumers): > > OK mariani@ > > I'm not sure that I understand you. > > pandas has dropped py2 support in >=0.25.0 [0]. To reflect this, our port > has dropped py2 support as well, and has been migrated to py3-only [1]. > So, I'm pretty sure that pandas does not work on py2. > > All consumers of py-pandas have been migrated to py3: > > $ show-reverse-deps math/py-pandas > databases/py-influxdb,python3 > graphics/py-seaborn > math/mlpack > math/mlpack,-main > math/mlpack,-python > math/mlpack,python3,-python > net/py-siphon,python3 > www/py-bokeh > > [0] https://github.com/pandas-dev/pandas/releases/tag/v0.25.0 > [1] > http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/math/py-pandas/Makefile.diff?r1=1.10&r2=1.11&f=h
Re: UPDATE math/py-pandas-1.0.3
This version has:
python_requires=">=3.6.1"
(1.0.1 had the same)
If you are sure that this still works on py2 (which still has consumers):
OK mariani@
Cheers.
Elias.
On Sat, Mar 21, 2020 at 9:08 AM Bjorn Ketelaars wrote:
>
> Diff below brings py-pandas to 1.0.3, which includes some regression
> fixes and bug fixes. Release notes:
> https://pandas.pydata.org/docs/whatsnew/index.html#release
>
> Tarball does not include all files required for the test suite, as such
> numerous tests fail:
>
> 1.0.1 (currently in ports):
> = 429 failed, 59284 passed, 3479 skipped, 541 xfailed, 5 xpassed, 82
> warnings, 153 error in 4398.30 seconds =
>
> 1.0.3:
> = 435 failed, 59854 passed, 3516 skipped, 559 xfailed, 7 xpassed, 79
> warnings, 153 error in 4301.79 seconds =
>
> Run tested on amd64.
>
> Comments/OK?
>
>
> diff --git Makefile Makefile
> index c51371e4af4..0cf845c5220 100644
> --- Makefile
> +++ Makefile
> @@ -2,7 +2,7 @@
>
> COMMENT = data analysis and manipulation library
>
> -MODPY_EGG_VERSION =1.0.1
> +MODPY_EGG_VERSION =1.0.3
> DISTNAME = pandas-${MODPY_EGG_VERSION}
> PKGNAME = py-${DISTNAME}
>
> diff --git distinfo distinfo
> index ecc217ae441..d7693c18d97 100644
> --- distinfo
> +++ distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (pandas-1.0.1.tar.gz) = PAd2UwjwkdgbZzXU8iQrtDwzLMNGHK5gVD32sQln/ic=
> -SIZE (pandas-1.0.1.tar.gz) = 4852368
> +SHA256 (pandas-1.0.3.tar.gz) = MvQuMi+5A9DhiaTBC3W6cNkJWMxPZqF4HtAn8aHRRYY=
> +SIZE (pandas-1.0.3.tar.gz) = 5003497
> diff --git pkg/PLIST pkg/PLIST
> index 1c5c7fb..cfd6254b9dc 100644
> --- pkg/PLIST
> +++ pkg/PLIST
> @@ -615,6 +615,7 @@
> lib/python${MODPY_VERSION}/site-packages/pandas/tests/arrays/categorical/${MODPY
>
> lib/python${MODPY_VERSION}/site-packages/pandas/tests/arrays/categorical/${MODPY_PYCACHE}test_indexing.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/pandas/tests/arrays/categorical/${MODPY_PYCACHE}test_missing.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/pandas/tests/arrays/categorical/${MODPY_PYCACHE}test_operators.${MODPY_PYC_MAGIC_TAG}pyc
> +lib/python${MODPY_VERSION}/site-packages/pandas/tests/arrays/categorical/${MODPY_PYCACHE}test_replace.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/pandas/tests/arrays/categorical/${MODPY_PYCACHE}test_repr.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/pandas/tests/arrays/categorical/${MODPY_PYCACHE}test_sorting.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/pandas/tests/arrays/categorical/${MODPY_PYCACHE}test_subclass.${MODPY_PYC_MAGIC_TAG}pyc
> @@ -629,6 +630,7 @@
> lib/python${MODPY_VERSION}/site-packages/pandas/tests/arrays/categorical/test_dt
>
> lib/python${MODPY_VERSION}/site-packages/pandas/tests/arrays/categorical/test_indexing.py
>
> lib/python${MODPY_VERSION}/site-packages/pandas/tests/arrays/categorical/test_missing.py
>
> lib/python${MODPY_VERSION}/site-packages/pandas/tests/arrays/categorical/test_operators.py
> +lib/python${MODPY_VERSION}/site-packages/pandas/tests/arrays/categorical/test_replace.py
>
> lib/python${MODPY_VERSION}/site-packages/pandas/tests/arrays/categorical/test_repr.py
>
> lib/python${MODPY_VERSION}/site-packages/pandas/tests/arrays/categorical/test_sorting.py
>
> lib/python${MODPY_VERSION}/site-packages/pandas/tests/arrays/categorical/test_subclass.py
> @@ -1038,6 +1040,7 @@
> lib/python${MODPY_VERSION}/site-packages/pandas/tests/indexes/datetimes/${MODPY_
>
> lib/python${MODPY_VERSION}/site-packages/pandas/tests/indexes/datetimes/${MODPY_PYCACHE}test_datetimelike.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/pandas/tests/indexes/datetimes/${MODPY_PYCACHE}test_formats.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/pandas/tests/indexes/datetimes/${MODPY_PYCACHE}test_indexing.${MODPY_PYC_MAGIC_TAG}pyc
> +lib/python${MODPY_VERSION}/site-packages/pandas/tests/indexes/datetimes/${MODPY_PYCACHE}test_join.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/pandas/tests/indexes/datetimes/${MODPY_PYCACHE}test_misc.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/pandas/tests/indexes/datetimes/${MODPY_PYCACHE}test_missing.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/pandas/tests/indexes/datetimes/${MODPY_PYCACHE}test_ops.${MODPY_PYC_MAGIC_TAG}pyc
> @@ -1054,6 +1057,7 @@
> lib/python${MODPY_VERSION}/site-packages/pandas/tests/indexes/datetimes/test_dat
>
> lib/python${MODPY_VERSION}/site-packages/pandas/tests/indexes/datetimes/test_datetimelike.py
>
> lib/python${MODPY_VERSION}/site-packages/pandas/tests/indexes/datetimes/test_formats.py
>
> lib/python${MODPY_VERSION}/site-packages/pandas/tests/indexes/datetimes/test_indexing.py
> +lib/python${MODPY_VERSION}/site-packages/pandas/tests/indexes/datetimes/test_join.py
>
> lib/python${MODPY_VERSION}/site-packages
Re: UPDATE: devel/py-rope 0.12.0 to 0.16.0
Uff...
You are right...
The worst thing is that I had already done this for py-wurlitzer with
those tweaks...
My bad, thanks for checking.
Committed.
Cheers.
Elias.
On Fri, Mar 20, 2020 at 2:02 AM Bjorn Ketelaars wrote:
>
> On Thu 19/03/2020 21:27, Elias M. Mariani wrote:
> > + Mostly bugfixes.
> > + GPLv2 to LGPLv3+.
> > + spyder3 is the only consumer, so removed py2, py3 only port. (I will
> > unhook py2 from devel/Makefile later).
> > + spyder3 tested, no problems found.
> > + Taking MAINTAINER (again).
> >
> > - Some test failing, the same as in 0.12.0, probably related to docs:
> > FAILED (failures=8, skipped=14)
> > I will check them out when I have more time.
> >
> > OK?
> >
> > Cheers.
> > Elias mariani@
>
> Two comments:
>
> - FLAVOR?=python3 in MAKEFILE should be FLAVOR=python3
> - missing @pkgpath- and @conflict- marker in PLIST
>
> See diff below.
>
> With these OK bket@
>
> Please, do not forget to do a quirks for it.
>
>
> diff --git Makefile Makefile
> index bab36f915c8..ca6967d946d 100644
> --- Makefile
> +++ Makefile
> @@ -2,16 +2,17 @@
>
> COMMENT = refactoring library
>
> -MODPY_EGG_VERSION =0.12.0
> +MODPY_EGG_VERSION =0.16.0
> DISTNAME = rope-${MODPY_EGG_VERSION}
> PKGNAME = py-${DISTNAME}
> -REVISION = 1
>
> CATEGORIES = devel
>
> HOMEPAGE = https://github.com/python-rope/rope
>
> -# GPLv2
> +MAINTAINER = Elias M. Mariani
> +
> +# LGPLv3+
> PERMIT_PACKAGE = Yes
>
> MODULES = lang/python
> @@ -19,10 +20,6 @@ MODPY_PI = Yes
> MODPY_SETUPTOOLS = Yes
>
> FLAVORS = python3
> -FLAVOR ?=
> -
> -.if !${FLAVOR:Mpython3}
> -TEST_DEPENDS +=devel/py-unittest2
> -.endif
> +FLAVOR = python3
>
> .include
> diff --git distinfo distinfo
> index 62c530b498f..abe4fb5f41c 100644
> --- distinfo
> +++ distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (rope-0.12.0.tar.gz) = Ax61Sz7uyJ9DBO3oFple0rk6Ieb7oWvQKv8QoNbCV7c=
> -SIZE (rope-0.12.0.tar.gz) = 246543
> +SHA256 (rope-0.16.0.tar.gz) = 0oMBQsLgRvX8JqAi/mgGdbb0j4HH/B8DqVBwbnRunf4=
> +SIZE (rope-0.16.0.tar.gz) = 243304
> diff --git pkg/PLIST pkg/PLIST
> index 3adfac9f7bc..f442dfe6f44 100644
> --- pkg/PLIST
> +++ pkg/PLIST
> @@ -1,9 +1,12 @@
> @comment $OpenBSD: PLIST,v 1.3 2018/04/26 20:29:26 danj Exp $
> +@conflict py-rope-*
> +@pkgpath devel/py-rope
> lib/python${MODPY_VERSION}/site-packages/rope/
>
> lib/python${MODPY_VERSION}/site-packages/rope-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
>
> lib/python${MODPY_VERSION}/site-packages/rope-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
>
> lib/python${MODPY_VERSION}/site-packages/rope-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/SOURCES.txt
>
> lib/python${MODPY_VERSION}/site-packages/rope-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/dependency_links.txt
> +lib/python${MODPY_VERSION}/site-packages/rope-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt
>
> lib/python${MODPY_VERSION}/site-packages/rope-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
> lib/python${MODPY_VERSION}/site-packages/rope/__init__.py
>
> ${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/rope/${MODPY_PYCACHE}/
UPDATE: devel/py-rope 0.12.0 to 0.16.0
+ Mostly bugfixes. + GPLv2 to LGPLv3+. + spyder3 is the only consumer, so removed py2, py3 only port. (I will unhook py2 from devel/Makefile later). + spyder3 tested, no problems found. + Taking MAINTAINER (again). - Some test failing, the same as in 0.12.0, probably related to docs: FAILED (failures=8, skipped=14) I will check them out when I have more time. OK? Cheers. Elias mariani@ py-rope-0.16.0.diff Description: Binary data
Re: [new] devel/yarn an alternative to npm
Hello Aaron, This is an old submission... Is there any reason to have this tool in the ports tree? I found this mail because I wanted to see if porting VS Code was possible and how much work would require. TL;DR: VS Code uses Yarn to install. Is this the case for lots of ports? I think that there are lots of interesting tools to have: Discord, VS Code, Atom, so on... Most of them depending on npm, yarn, Electron (now we have this one I think). But it seems a lot of work to produce packages with our ports workflow with those tools, you seem to have more insight on the subject. What do you think? Cheers. Elias mariani@ On Thu, Dec 12, 2019 at 2:15 PM Aaron Bieber wrote: > > Hi! > > This is a port of yarn. It's an alternative to npm. > > https://blog.npmjs.org/post/189618601100/binary-planting-with-the-npm-cli > (I will post an update to node when it lands.) > > Unfortunately it suffers from some of the same issues. :P > > DESCR: > Fast: Yarn caches every package it has downloaded, so it never needs to > download the same package again. It also does almost everything concurrently > to > maximize resource utilization. This means even faster installs. > > Reliable: Using a detailed but concise lockfile format and a deterministic > algorithm for install operations, Yarn is able to guarantee that any > installation that works on one system will work exactly the same on another > system. > > Secure: Yarn uses checksums to verify the integrity of every installed > package > before its code is executed. > > OK? Cluestick? "Take yer JS and gtfo?!"? > > -- > PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE
Re: UPDATE: print/lyx 2.3.2 to 2.3.4.2
Sorry, I do not follow. Are you asking me why I send the diff of distinfo? Cheers. On Mon, Mar 16, 2020 at 10:04 AM Marc Espie wrote: > > On Mon, Mar 16, 2020 at 08:26:35AM +, Stuart Henderson wrote: > > On 2020/03/16 00:45, Marc Espie wrote: > > > On Sun, Mar 15, 2020 at 08:08:34PM -0300, Elias M. Mariani wrote: > > > > Sure. > > > > + Added https://ftp.lip6.fr/pub/lyx/stable/2.3.x/ to the top of > > > > MASTER_SITES. (I guess that we want HTTPS first?). > > > > > > We don't really care about https, but the lip6 server is fairly reliable. > > > > I do - it doesn't matter for fetching an existing version where we > > already have hashes, but guards against some problems for updates. > > (obviously not all, but enough to be worthwhile) > > > > > Ping, what's up with your signature diff ? >
Re: UPDATE: print/lyx 2.3.2 to 2.3.4.2
Sure. + Added https://ftp.lip6.fr/pub/lyx/stable/2.3.x/ to the top of MASTER_SITES. (I guess that we want HTTPS first?). + Normalized all to VAR= or VAR+=, without spaces. I know that you already give an OK but if you could check it again it would be great. Cheers. Elias mariani@ On Sun, Mar 15, 2020 at 7:05 PM Stuart Henderson wrote: > > : -DISTNAME=lyx-2.3.2 > : -REVISION=1 > : +DISTNAME=lyx-2.3.4.2 > : > : CATEGORIES= print editors > : > : HOMEPAGE=https://www.lyx.org/ > : > : +MAINTAINER = Elias M. Mariani > > slightly nitpicking, but please use consistent whitespace > > > : MASTER_SITES=ftp://ftp.lyx.org/pub/lyx/stable/2.3.x/ \ > > could you add https://ftp.lip6.fr/pub/lyx/stable/2.3.x/ to the start > of the list please? > > OK. > > > lyx-2.3.4.2.diff Description: Binary data
UPDATE: print/lyx 2.3.2 to 2.3.4.2
+ Taking MAINTAINER. (again...) Announces: https://www.lyx.org/announce/2_3_3.txt * BUILD/INSTALLATION - Fix build with boost 1.69 (bug 11349). - Update bundled boost distribution to 1.68. - Fix warnings with clang 7. - Allow automake 1.16. https://www.lyx.org/announce/2_3_4.txt https://www.lyx.org/announce/2_3_4_2.txt * BUILD/INSTALLATION - avoid annoying warnings with g++ 9. Also from https://www.lyx.org/announce/2_3_1.txt All python scripts distributed with LyX should now be compatible with both python 2.x and python 3.x. So, moving to python3, another unhooked from python2. :) Tested update on an amd64 machine, no problems found. Tests and comments welcome. Waiting for a single OK, just to take MAINTAINER and because I have been away for some time... Cheers. Elias mariani@ lyx-2.3.4.2.diff Description: Binary data
Re: UDPATE devel/spyder (migrate to py3-only)
This is already in the ports tree. I was already looking to do it myself. Looks good to me. Thanks Bjorn for saving me the trouble. :) I'm now working on updating it to the latest version. Taking MAINTAINER when that happens. Cheers. Elias. On Fri, Mar 6, 2020 at 6:56 AM Landry Breuil wrote: > > On Fri, Mar 06, 2020 at 10:39:06AM +0100, Bjorn Ketelaars wrote: > > On Sat 29/02/2020 15:16, Bjorn Ketelaars wrote: > > > I would like to migrate devel/spyder/* to python3-only. This is needed > > > to move forward on several other python ports. > > > > > > There are no consumers. > > > > > > Addition of a quirk to devel/quirks will follow at commit time. > > > > > > Comments/OK? > > > > Ping! > > > > Enclosed an updated diff. > > reads good, i'm ok with this as it also helps testing the py-qt5 update > madness. elias, since you ported it, any attachment to the py2 version ? > > Landry
Re: [UPDATE] devel/py-wurlitzer 1.0.2 -> 2.0.0
Ups... Given that py-spyder-kernels no longer exists: Moving py-wurlitzer to -> py3-wurlitzer - Removed unnecessary patch for setup.py - Unhooked devel/py-wurlitzer from devel/Makefile - Added 'py-wurlitzer' => 'py3-wurlitzer' in quirks (reversion change pending) - FLAVOR ?= to FLAVOR = python3 in Makefile - Added in PLIST: @conflict py-wurlitzer-* @pkgpath net/py-wurlitzer Update tested OK: pkg_add -u py3-wurlitzer py3-wurlitzer-1.0.2p1->2.0.0: ok Tested with spyder3 (unique consumer), no problems found. Looking for OKs. Sorry for the previous mail. Cheers. On Sat, Mar 7, 2020 at 2:34 PM Elias M. Mariani wrote: > > Changelog: > https://github.com/minrk/wurlitzer/blob/2.0.0/CHANGELOG.md > > Nothing of impact. > We only have it on the tree as a dendency of > devel/spyder/py-spyder-kernels,python3 > > Regression tests passing. > > Added myself as a maintainer (again). > > Comments ? OK ? > I'm the original submitter of this port, but It has been a year since > I sent something to the ports tree, so, feedback is most welcome. :) > > Cheers. > Elias. py-wurlitzer.diff Description: Binary data
[UPDATE] devel/py-wurlitzer 1.0.2 -> 2.0.0
Changelog: https://github.com/minrk/wurlitzer/blob/2.0.0/CHANGELOG.md Nothing of impact. We only have it on the tree as a dendency of devel/spyder/py-spyder-kernels,python3 Regression tests passing. Added myself as a maintainer (again). Comments ? OK ? I'm the original submitter of this port, but It has been a year since I sent something to the ports tree, so, feedback is most welcome. :) Cheers. Elias. py-wurlitzer.diff Description: Binary data
Re: Update: sysutils/py-scandir 1.9.0 -> 1.10.0
OK mariani@
On Wed, Mar 20, 2019 at 7:44 PM Kurt Mosiejczuk wrote:
>
> On Wed, Mar 20, 2019 at 11:25:59PM +0100, Klemens Nanni wrote:
>
> > OK kn
>
> > > @@ -32,7 +32,6 @@ TEST_DEPENDS += devel/py-unittest2
> > > .endif
>
> > > do-test:
> > > - cd ${WRKSRC}/test &&\
> > > - env LC_ALL=C.UTF-8 LANG=C.UTF-8 ${MODPY_BIN} run_tests.py
> > > + cd ${WRKSRC}/test && ${SETENV} ${ALL_TEST_ENV} ${MODPY_BIN}
> > > run_tests.py
> > How about omitting this hunk from the update and commit it separately,
> > possibly in a bulk with other test conversions now that remi has landed
> > your final MODPY_PYTEST bits?
>
> We could. I only submitted this one because it isn't actually using
> MODPY_PYTEST. It is running its own tests. I was just taking advantage of
> the fact that we set TEST_ENV to include en_US.UTF-8. I have others I
> have been updating that I haven't submitted yet because MODPY_PYTEST
> hadn't gone in yet. :)
>
> --Kurt
>
Re: UPDATE devel/git-cola
OK mariani@ On Mon, Mar 4, 2019 at 4:17 AM Björn Ketelaars wrote: > > On Mon 11/02/2019 10:16, Björn Ketelaars wrote: > > On Mon 04/02/2019 20:35, Björn Ketelaars wrote: > > > > > > Enclosed diff updates git-cola to 3.3, which fixes some minor issues. > > > Changelog can be found at > > > https://github.com/git-cola/git-cola/blob/master/share/doc/git-cola/relnotes.rst > > > > > > Comments/OK? > > > > Ping... > > Ping >
[UPDATE] textproc/py-xlrd 1.1.0 -> 1.2.0
Changelog: https://github.com/python-excel/xlrd/blob/1.2.0/docs/changes.rst Nothing of impact. We only have it on the tree as a TEST_DEPENDS of math/py-pandas. Regression tests passing. The test from py-pandas are the same as well. Added myself as a maintainer. Comments ? OK ? Elias. py-xlrd-1.2.0.diff Description: Binary data
Re: Update: devel/py-jupyter_client - Add itself to TEST_DEPENDS
Hi Kurt,I think that py-ipykernel depends on py-jupyter_client.So
py-jupyter_client gets installed already.Cheers.Elias.
On Sun, Mar 3, 2019 at 1:50 AM Kurt Mosiejczuk wrote:
>
> While doing some extra testing before pinging on another port, I found
> that "make test" will fail for py-jupyter_client unless one installs
> the package itself by hand. So here I'm adding it to the TEST_DEPENDS
> so that is unnecessary.
>
> --Kurt
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/py-jupyter_client/Makefile,v
> retrieving revision 1.7
> diff -u -p -r1.7 Makefile
> --- Makefile29 Dec 2018 11:53:38 - 1.7
> +++ Makefile3 Mar 2019 04:46:35 -
> @@ -29,6 +29,7 @@ RUN_DEPENDS = devel/py-dateutil${MODPY_
> net/py-zmq${MODPY_FLAVOR} \
> www/py-tornado${MODPY_FLAVOR}
> TEST_DEPENDS = ${RUN_DEPENDS} \
> + ${FULLPKGNAME}:${FULLPKGPATH} \
> devel/ipython${MODPY_FLAVOR}>=5.1.0 \
> devel/py-ipykernel${MODPY_FLAVOR}>=4.5.2 \
> devel/py-test${MODPY_FLAVOR} \
Re: Update: devel/py-py 1.5.3 -> 1.8.0
OK mariani@
On Sun, Feb 24, 2019 at 2:10 AM Kurt Mosiejczuk wrote:
>
> The update on this one was pretty easy. While in there I made the
> test use TEST_ENV and set up the test environment properly based on
> what I learned from semarie while updating py-dateutil.
>
> The testing of the dependencies took a while.
>
> I tested the following that have py-py as a TEST_DEPENDS:
> devel/py-six, devel/py-cheetah, devel/py-prompt-toolkit,
> devel/py-cffi (no actual tests), devel/pudb, devel/py-nbconvert,
> www/py-pylons, www/py-paste, www/pelican, www/py-httpie, www/py-weberror,
> www/py-repoze-profile, security/py-paramiko, and shells/py-qtconsole.
> Every one had the same results with the updated 1.8.0 as the original 1.5.3.
>
> The following two had tests that wouldn't run:
> devel/py-tox and www/py-paste-script
> The original was the same.
>
> devel/spyder takes forever, pulls in lots of dependencies, and then
> complains that HOME isn't set. Although it does that for the old
> version too.
>
> The following had py-py as BUILD_DEPENDS:
> security/letsencrypt/py-acme, databases/py-psycopg2, and textproc/py-sphinx
> All three built fine with the updated py-py.
>
> --Kurt
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/py-py/Makefile,v
> retrieving revision 1.31
> diff -u -p -r1.31 Makefile
> --- Makefile28 Apr 2018 10:41:04 - 1.31
> +++ Makefile24 Feb 2019 05:01:56 -
> @@ -2,7 +2,7 @@
>
> COMMENT= cross-python path, ini-parsing, io, code, log
> facilities
>
> -MODPY_EGG_VERSION =1.5.3
> +MODPY_EGG_VERSION =1.8.0
> DISTNAME= py-${MODPY_EGG_VERSION}
> PKGNAME= py-${DISTNAME}
>
> @@ -21,7 +21,10 @@ FLAVOR?=
>
> TEST_DEPENDS +=devel/py-test${MODPY_FLAVOR}
>
> +TEST_ENV +=LC_CTYPE=C.UTF-8
> +
> do-test:
> - cd ${WRKSRC} && LC_CTYPE=C.UTF-8 ${MODPY_BIN} -m pytest
> + cd ${WRKSRC} && exec ${SETENV} ${MAKE_ENV} ${TEST_ENV} \
> + ${MODPY_BIN} -m pytest
>
> .include
> Index: distinfo
> ===
> RCS file: /cvs/ports/devel/py-py/distinfo,v
> retrieving revision 1.10
> diff -u -p -r1.10 distinfo
> --- distinfo28 Apr 2018 10:41:04 - 1.10
> +++ distinfo24 Feb 2019 05:01:56 -
> @@ -1,2 +1,2 @@
> -SHA256 (py-1.5.3.tar.gz) = Kcn6tJXXUo6Auh40O5WGhPSs5ocyfm94mpS/PRkV+IE=
> -SIZE (py-1.5.3.tar.gz) = 202335
> +SHA256 (py-1.8.0.tar.gz) = 3GObBGpuLP9bvkAZStZZNta6NgtSs8P+HQioLdULXlM=
> +SIZE (py-1.8.0.tar.gz) = 205096
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/devel/py-py/pkg/PLIST,v
> retrieving revision 1.11
> diff -u -p -r1.11 PLIST
> --- pkg/PLIST 28 Apr 2018 10:41:04 - 1.11
> +++ pkg/PLIST 24 Feb 2019 05:01:56 -
> @@ -14,6 +14,7 @@ lib/python${MODPY_VERSION}/site-packages
>
> lib/python${MODPY_VERSION}/site-packages/py/${MODPY_PYCACHE}_builtin.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/py/${MODPY_PYCACHE}_error.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/py/${MODPY_PYCACHE}_std.${MODPY_PYC_MAGIC_TAG}pyc
> +lib/python${MODPY_VERSION}/site-packages/py/${MODPY_PYCACHE}_version.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/py/${MODPY_PYCACHE}_xmlgen.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/py/${MODPY_PYCACHE}test.${MODPY_PYC_MAGIC_TAG}pyc
> lib/python${MODPY_VERSION}/site-packages/py/_builtin.py
> @@ -85,5 +86,6 @@ lib/python${MODPY_VERSION}/site-packages
>
> lib/python${MODPY_VERSION}/site-packages/py/_vendored_packages/${MODPY_PYCACHE}iniconfig.${MODPY_PYC_MAGIC_TAG}pyc
> lib/python${MODPY_VERSION}/site-packages/py/_vendored_packages/apipkg.py
> lib/python${MODPY_VERSION}/site-packages/py/_vendored_packages/iniconfig.py
> +lib/python${MODPY_VERSION}/site-packages/py/_version.py
> lib/python${MODPY_VERSION}/site-packages/py/_xmlgen.py
> lib/python${MODPY_VERSION}/site-packages/py/test.py
>
Re: [M. UPDATE] net/py-zmq 17.1.2 to 18.0.0
On Fri, Feb 22, 2019 at 7:05 AM Jeremie Courreges-Anglas wrote: > I don't understand the SETENV variable. Where is it used? In the MODULE = lang/python. Is needed to parse a file by setup.py. > The two additional diffs below allow me to run tests successfully on > amd64. Great! Thank you. Commiting later today. Cheers. Elias.
[M. UPDATE] net/py-zmq 17.1.2 to 18.0.0
https://pyzmq.readthedocs.io/en/latest/changelog.html - Update bundled libzmq to 4.3.1 (fixes CVE-2019-6250) https://nvd.nist.gov/vuln/detail/CVE-2019-6250 Regression tests on consumers are working equal with this version and the previous one. Comments ? OKs ? Elias. py-zmq-18.0.0.diff Description: Binary data
[M. UPDATE] devel/spyder 3.3.0 -> 3.3.3
This updates devel/spyder/spyder and devel/spyder/py-spyder-kernels https://github.com/spyder-ide/spyder/blob/v3.3.3/CHANGELOG.md https://github.com/spyder-ide/spyder-kernels/blob/v0.4.2/CHANGELOG.md - Added new dependencies for py-spyder-kernels. - Added limits to portroach to stay on the 3.X.Y branch of spyder and on the 0.X.Y branch of py-spyder-kernels, 4.X.Y and 1.X.Y branches are python3 only. - Run tested on amd64, works OK. - No consumers. Comments ? OKs ? Elias. spyder-3.3.3.diff Description: Binary data
[M. UPDATE] devel/py-parso 0.3.1 -> 0.3.4
Changelog: https://github.com/davidhalter/parso/blob/v0.3.4/CHANGELOG.rst Mainly bugfixes. - Added a new test dependency according to setup.py. - Regression tests passing. - Only direct consumer is devel/py-jedi, regression test also passing. - Used on devel/spyder without problems. Comments ? OK ? Elias. py-parso-0.3.4.diff Description: Binary data
[M. UPDATE] devel/py-rope 0.11.0 -> 0.12.0
- Regression tests passing. - The only consumer is devel/spyder, running without problems. Comments ? OK ? Elias. py-rope-0.12.0.diff Description: Binary data
Re: [NEW] devel/py-wurlitzer 1.0.2
Bumping this.
I really need it to update devel/spyder.
Cheers.
Elias.
On Tue, Jan 15, 2019 at 6:12 PM Elias M. Mariani wrote:
>
> Sorry to add more noise to the list but is there someone who can give
> comments on this one ?
> I think that the first version was OK (attached), as Sebastien said,
> is not pretty but it works ok.
>
> Cheers.
> Elias.
>
> On Thu, Jan 3, 2019 at 1:42 PM Elias M. Mariani
> wrote:
> >
> > Well I have been trying to use the fdopen approach that Sebastien proposed.
> > I get different results. (Test fails with this method).
> > I'm not proficient with C, but I'm guessing that using fflush with a
> > different struct changes the expected result ?
> >
> > This is the code that I'm using for testing:
> >
> > fdopen = libc.fdopen
> > fdopen.restype = ctypes.POINTER(ctypes.c_void_p)
> > fdopen.argtypes = [ctypes.c_int, ctypes.c_char_p]
> > c_stdout_p = fdopen(1, b"w")
> > c_stderr_p = fdopen(2, b"w")
> >
> > The original version segfaults, for some reason I have to pass a
> > ctypes.POINTER to the functions, if you pass a int(ctypes.c_void_p) it
> > breaks...
> >
> > Again, maybe someone with better eyes for python/C interfacing sees
> > something that I'm missing.
> > I attach the not working version for those who want to test other things...
> >
> > Cheers.
> > Elias.
> >
> > On Sun, Dec 23, 2018 at 3:32 PM Sebastien Marie wrote:
> > >
> > > On Thu, Dec 20, 2018 at 10:54:28AM -0300, Elias M. Mariani wrote:
> > > > Sorry for pinging, I forgot to add:
> > > > A issue has been opened in upstream's github about this 16 days ago,
> > > > no reply until now:
> > > > https://github.com/minrk/wurlitzer/issues/23
> > > >
> > > > Just to see if they have a more python-sided way of handling this.
> > >
> > > Personally, I found the way it is currently done to be a bit ugly, even
> > > if it is technically correct.
> > >
> > > I think it could be more simple (and portable) to use a fdopen() call
> > > with `1' as descriptor to get a FILE *stdout. It will not be exactly the
> > > same pointer than "stdout" as the FILE struct around the descriptor will
> > > be a new struct, but it should be as functional as "stdout".
> > >
> > > Something like:
> > >
> > > libc = ctypes.CDLL(None)
> > >
> > > fdopen = libc.fdopen
> > > fdopen.restype = ctypes.c_void_p
> > > fdopen.argtypes = [ctypes.c_int, ctypes.c_char_p]
> > >
> > > stdout_p = fdopen(1, "w")
> > > stderr_p = fdopen(2, "w")
> > >
> > > Note that for stderr, the FILE* is normally unbuffered whereas here it
> > > will be buffered (it is ok for stdout).
> > >
> > > > > The main problem is to get the length of FILE, is 152 bytes in amd64,
> > > > > and 88 bytes in i386, no idea in other platforms, but given that this
> > > > > lengths can change, hardcoding this numbers is ugly and bad...
> > >
> > > Well. usually I would agree that hardcoding is bad style.
> > >
> > > But I doubt the underline struct FILE will change often, I think having
> > > it here hardcoded could be acceptable.
> > >
> > > It could be done at the Makefile level this way to have SIZEOF_FILE per
> > > architecture:
> > >
> > > ONLY_FOR_ARCHS =amd64 i386
> > >
> > > # printf("%lu\n", sizeof(FILE));
> > > SIZEOF_FILE-amd64 = 152
> > > SIZEOF_FILE-i386 =88
> > > SIZEOF_FILE = ${SIZEOF_FILE-${MACHINE_ARCH}}
> > >
> > > SUBST_VARS += SIZEOF_FILE
> > >
> > > pre-configure:
> > > ${SUBST_CMD} ${WRKSRC}/wurlitzer.py
> > >
> > > Thanks.
> > > --
> > > Sebastien Marie
py-wurlitzer.tar.gz
Description: GNU Zip compressed data
Updating devel/py-hypothesis
devel/py-hypothesis has been updated from branch 3.* to branch 4.*. In witch the deprecated functions have been removed. https://github.com/HypothesisWorks/hypothesis/blob/hypothesis-python-4.5.6/hypothesis-python/docs/changes.rst#400---2019-01-14 Some ports are using new functionalities from the 4.* branch to run their regression tests, so an update for py-hypothesis is needed. The problem is that regression tests on some ports get broken if we update because they use the deprecated functions. I assume that most of the ports with problems are not updated so that is why they are using the deprecated functions. I think that I should update py-hypothesis anyways, given that regression tests are usually run when the python ports are updated. But I prefer to ask to the list before. This is the list of ports consuming py-hypothesis: audio/py-mutagen devel/py-attrs devel/py-binaryornot devel/py-dateutil devel/py-icalendar devel/py-test productivity/vdirsyncer security/py-PyNaCl security/py-cryptography textproc/py-chardet textproc/py-commonmark Cheers. Elias.
Re: [print/lyx] Missing dependency: texlive-minimal
Hi Alessandro, This also happens with some functions if you don't install texlive_texmf-full, given that I don't want to force people on installing those packages for the use of LyX they aren't in the dependencies. I will consider adding texlive_texmf-minimal and leaving aside texlive_texmf-full. Thanks for the report. Elias. On Sun, Jan 27, 2019 at 4:09 PM Alessandro DE LAURENZIS wrote: > > Dear ports@, Elias > > I was trying LyX and noticed some unexpected errors when making PDFs of > the splash doc and the Introduction section of the on-line help: > > [...] > ! LaTeX Error: File `booktabs.sty' not found. > > > > > > ! Font T1/ppl/m/n/17.28=pplr8t at 17.28pt not loadable: Metric (TFM) > file not found > > > > > ! Math formula deleted: Insufficient symbol fonts. > [...] > > Also some other sty files where missing (sorry, I didn't take note of > the whole list...) > > All works flawlessly after the installation of texlive_texmf-minimal, > that isn't listed among lys' dependencies... > > -- > Alessandro DE LAURENZIS > [mailto:jus...@atlantide.t28.net] > Web: http://www.atlantide.t28.net > LinkedIn: https://www.linkedin.com/in/delaurenzis/
Re: [NEW] devel/py-wurlitzer 1.0.2
Sorry to add more noise to the list but is there someone who can give
comments on this one ?
I think that the first version was OK (attached), as Sebastien said,
is not pretty but it works ok.
Cheers.
Elias.
On Thu, Jan 3, 2019 at 1:42 PM Elias M. Mariani wrote:
>
> Well I have been trying to use the fdopen approach that Sebastien proposed.
> I get different results. (Test fails with this method).
> I'm not proficient with C, but I'm guessing that using fflush with a
> different struct changes the expected result ?
>
> This is the code that I'm using for testing:
>
> fdopen = libc.fdopen
> fdopen.restype = ctypes.POINTER(ctypes.c_void_p)
> fdopen.argtypes = [ctypes.c_int, ctypes.c_char_p]
> c_stdout_p = fdopen(1, b"w")
> c_stderr_p = fdopen(2, b"w")
>
> The original version segfaults, for some reason I have to pass a
> ctypes.POINTER to the functions, if you pass a int(ctypes.c_void_p) it
> breaks...
>
> Again, maybe someone with better eyes for python/C interfacing sees
> something that I'm missing.
> I attach the not working version for those who want to test other things...
>
> Cheers.
> Elias.
>
> On Sun, Dec 23, 2018 at 3:32 PM Sebastien Marie wrote:
> >
> > On Thu, Dec 20, 2018 at 10:54:28AM -0300, Elias M. Mariani wrote:
> > > Sorry for pinging, I forgot to add:
> > > A issue has been opened in upstream's github about this 16 days ago,
> > > no reply until now:
> > > https://github.com/minrk/wurlitzer/issues/23
> > >
> > > Just to see if they have a more python-sided way of handling this.
> >
> > Personally, I found the way it is currently done to be a bit ugly, even
> > if it is technically correct.
> >
> > I think it could be more simple (and portable) to use a fdopen() call
> > with `1' as descriptor to get a FILE *stdout. It will not be exactly the
> > same pointer than "stdout" as the FILE struct around the descriptor will
> > be a new struct, but it should be as functional as "stdout".
> >
> > Something like:
> >
> > libc = ctypes.CDLL(None)
> >
> > fdopen = libc.fdopen
> > fdopen.restype = ctypes.c_void_p
> > fdopen.argtypes = [ctypes.c_int, ctypes.c_char_p]
> >
> > stdout_p = fdopen(1, "w")
> > stderr_p = fdopen(2, "w")
> >
> > Note that for stderr, the FILE* is normally unbuffered whereas here it
> > will be buffered (it is ok for stdout).
> >
> > > > The main problem is to get the length of FILE, is 152 bytes in amd64,
> > > > and 88 bytes in i386, no idea in other platforms, but given that this
> > > > lengths can change, hardcoding this numbers is ugly and bad...
> >
> > Well. usually I would agree that hardcoding is bad style.
> >
> > But I doubt the underline struct FILE will change often, I think having
> > it here hardcoded could be acceptable.
> >
> > It could be done at the Makefile level this way to have SIZEOF_FILE per
> > architecture:
> >
> > ONLY_FOR_ARCHS =amd64 i386
> >
> > # printf("%lu\n", sizeof(FILE));
> > SIZEOF_FILE-amd64 = 152
> > SIZEOF_FILE-i386 =88
> > SIZEOF_FILE = ${SIZEOF_FILE-${MACHINE_ARCH}}
> >
> > SUBST_VARS += SIZEOF_FILE
> >
> > pre-configure:
> > ${SUBST_CMD} ${WRKSRC}/wurlitzer.py
> >
> > Thanks.
> > --
> > Sebastien Marie
py-wurlitzer.tar.gz
Description: GNU Zip compressed data
Re: py-wxPython extras
Hi Jeremie, Yes, I was worried at the time (this thread is from may 2017) for people not no find editra in a "direct" way. At least it happened to me... Now we have devel/spyder witch is a good IDE/editor for python, so the problem is somewhat mitigated. The may not find editra but the will find an editor. :) But if there is a way to pkg_add editra I think it would be more visible. I leave that to the discretion of the people maintaining such port. Cheers. Elias. On Sun, Jan 13, 2019 at 9:30 PM Jeremie Courreges-Anglas wrote: > > On Thu, May 24 2018, "Elias M. Mariani" wrote: > > Hi, > > I was looking for Editra (text editor) and I found that there is not > > port of Editra by itself, It is contained within the py-wxPython port. > > https://github.com/openbsd/ports/blob/439514e8c82c269624be233d533b016d3a63a201/x11/py-wxPython/pkg/PLIST > > > > Shouldn't be better to remove the extras from py-wxPython and having > > those apart ? > > I mean, if you want wxPython maybe you do not want Editra. > > ritchie~$ du -sh /usr/local/lib/python2.7/site-packages/wx/tools/Editra > /usr/local/lib/python2.7/site-packages/wx/tools/XRCed > 8.6M/usr/local/lib/python2.7/site-packages/wx/tools/Editra > 1.3M/usr/local/lib/python2.7/site-packages/wx/tools/XRCed > ritchie ~$ pkg_info -s py-wxPython > Information for inst:py-wxPython-3.0.2.0 > > Size: 64856495 > > Gaining 10M may be worth it, but... > > > And looking for standalone applications inside other ports doesn't > > seem right, I might as well thought that there was no port of Editra. > > making those programs more visible is what matters most IMHO. I would > support such a move. > > However... my tries to update wxPython to the latest 4.x upstream > release were painful (we're using the last "classic", 3.0.x release). > I'm not sure it's a good idea to make the port more complicated *now*. :) > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
[M. UPDATE] x11/py-qtpy 1.5.2 -> 1.6.0
Changelog: https://github.com/spyder-ide/qtpy/blob/v1.6.0/CHANGELOG.md - Add support for QtQuickWidgets. - Regression test passing. - Consumers shouldn't be affected. - Tested running devel/spyder: OK Comments ? OK ? Elias. py-qtpy-1.6.0.diff Description: Binary data
Re: Help updating shells/bash to 5.0
Hi Stephen,
The Makefile in examples/loadables is missing the argument to find libintl.h
You can specify the argument via:
CONFIGURE_ARGS= INTL_INC=-I${LOCALBASE}/include
That wont work either because for *some reason* the INTL_INC variable
is set to " " in the base Makefile:
INTL_DEP= INTL_INC= LIBINTL_H=
So probably you need to remove that line.
With those changes the ports builds fine on amd64, you should check
other things, like WANTLIBs, dependencies, if it runs ?
On a side note, there is no need to specify PKGNAME when DISTNAME is the same:
-DISTNAME= bash-4.4.18
-PKGNAME= bash-4.4.23
+DISTNAME= bash-5.0
I attach a diff with the changes, but again, it lacks some work.
Cheers.
Elias.
On Tue, Jan 8, 2019 at 5:39 AM Stephen Gregoratto wrote:
>
> Bash 5.0 has just been released[1], and I thought I'd try and update the
> port. I'm having problems getting the `seq` builtin to compile.
> I've attached the (truncated) log, but the gist of it is this:
>
> In file included from seq.c:32:
> In file included from ../../bashintl.h:30:
> ../../include/gettext.h:27:11: fatal error: 'libintl.h' file not found
> # include
>
> This happens whether or not the Makefile.in patch is applied.
> Also attached is the cvs diff of my progress. I've disabled the
> PATCHFILES section since there are none available.
>
> [1] https://lists.gnu.org/archive/html/bug-bash/2019-01/msg00063.html
> --
> Stephen Gregoratto
bash.diff
Description: Binary data
[M. UPDATE] print/lyx 2.3.1 -> 2.3.2
Changelog: https://www.lyx.org/announce/2_3_2.txt Mostly bugfixes. amd64: Build => OK Run => OK Comments ? OK ? Elias. lyx-2.3.2.diff Description: Binary data
Re: [NEW] devel/py-wurlitzer 1.0.2
Well I have been trying to use the fdopen approach that Sebastien proposed.
I get different results. (Test fails with this method).
I'm not proficient with C, but I'm guessing that using fflush with a
different struct changes the expected result ?
This is the code that I'm using for testing:
fdopen = libc.fdopen
fdopen.restype = ctypes.POINTER(ctypes.c_void_p)
fdopen.argtypes = [ctypes.c_int, ctypes.c_char_p]
c_stdout_p = fdopen(1, b"w")
c_stderr_p = fdopen(2, b"w")
The original version segfaults, for some reason I have to pass a
ctypes.POINTER to the functions, if you pass a int(ctypes.c_void_p) it
breaks...
Again, maybe someone with better eyes for python/C interfacing sees
something that I'm missing.
I attach the not working version for those who want to test other things...
Cheers.
Elias.
On Sun, Dec 23, 2018 at 3:32 PM Sebastien Marie wrote:
>
> On Thu, Dec 20, 2018 at 10:54:28AM -0300, Elias M. Mariani wrote:
> > Sorry for pinging, I forgot to add:
> > A issue has been opened in upstream's github about this 16 days ago,
> > no reply until now:
> > https://github.com/minrk/wurlitzer/issues/23
> >
> > Just to see if they have a more python-sided way of handling this.
>
> Personally, I found the way it is currently done to be a bit ugly, even
> if it is technically correct.
>
> I think it could be more simple (and portable) to use a fdopen() call
> with `1' as descriptor to get a FILE *stdout. It will not be exactly the
> same pointer than "stdout" as the FILE struct around the descriptor will
> be a new struct, but it should be as functional as "stdout".
>
> Something like:
>
> libc = ctypes.CDLL(None)
>
> fdopen = libc.fdopen
> fdopen.restype = ctypes.c_void_p
> fdopen.argtypes = [ctypes.c_int, ctypes.c_char_p]
>
> stdout_p = fdopen(1, "w")
> stderr_p = fdopen(2, "w")
>
> Note that for stderr, the FILE* is normally unbuffered whereas here it
> will be buffered (it is ok for stdout).
>
> > > The main problem is to get the length of FILE, is 152 bytes in amd64,
> > > and 88 bytes in i386, no idea in other platforms, but given that this
> > > lengths can change, hardcoding this numbers is ugly and bad...
>
> Well. usually I would agree that hardcoding is bad style.
>
> But I doubt the underline struct FILE will change often, I think having
> it here hardcoded could be acceptable.
>
> It could be done at the Makefile level this way to have SIZEOF_FILE per
> architecture:
>
> ONLY_FOR_ARCHS =amd64 i386
>
> # printf("%lu\n", sizeof(FILE));
> SIZEOF_FILE-amd64 = 152
> SIZEOF_FILE-i386 =88
> SIZEOF_FILE = ${SIZEOF_FILE-${MACHINE_ARCH}}
>
> SUBST_VARS += SIZEOF_FILE
>
> pre-configure:
> ${SUBST_CMD} ${WRKSRC}/wurlitzer.py
>
> Thanks.
> --
> Sebastien Marie
v2.tar.gz
Description: GNU Zip compressed data
[M. UPDATE] devel/py-ipykernel 4.9.0 -> 4.10.0
Changelog: https://github.com/ipython/ipykernel/tree/5.1.0 4.10.0: - Fix compatibility with IPython 7.0 - Fix compatibility in cases where sys.stdout can be None These changes shouldn't affect the current consumers. Versions >= 5.0 are python3 only, so we are sticking with 4.X for now. Adding the following option so portroach only gets the 4.X branch: limit:^4.*$$ Regression tests looking good: Ran 95 (1 skipped) Also the following regression tests were executed to check for problems: devel/ipython => OK devel/py-jupyter_client => OK devel/py-jupyter_core => OK devel/py-nbconvert => OK shells/py-qtconsole => OK www/jupyter-notebook => OK devel/spyder runs OK with the change. Cheers. Elias. py-ipykernel-4.10.0.diff Description: Binary data
[M. UPDATE] net/qbittorrent 4.1.4 -> 4.1.5
Changelog: https://github.com/qbittorrent/qBittorrent/blob/release-4.1.5/Changelog Pretty straightforward patch. (the patches were updated to match new files) Nothing significant to say... Tested both net/qbittorrent/qbittorrent and net/qbittorrent/qbittorrent-nox on amd64. Comments, OK? Elias. qbittorrent-4.1.5.diff Description: Binary data
Re: [NEW] devel/py-wurlitzer 1.0.2
Sorry for pinging, I forgot to add: A issue has been opened in upstream's github about this 16 days ago, no reply until now: https://github.com/minrk/wurlitzer/issues/23 Just to see if they have a more python-sided way of handling this. Cheers. Elias. On Wed, Dec 19, 2018 at 11:02 AM Elias M. Mariani wrote: > > https://github.com/minrk/wurlitzer > https://pypi.org/project/wurlitzer/ > > Capture C-level stdout/stderr pipes in Python via os.dup2. > > This package is required to update devel/spyder/py-spyder-kernels and > devel/spyder/spyder. > > Taking Maintainership. > > > A weird patch has to be made in order to make this package to work properly: > The original script calls to the function fflush from libc with a > parameter to stdout or stderr, for that a pointer is needed. > In linux: > c_stdout_p = ctypes.c_void_p.in_dll(libc, 'stdout') > > But OpenBSD doesn't have a defined symbol for 'stdout' in libc, but an > array of FILE structs called __sF, where __sF[1] corresponds to stdout > and __sF[2] to stderr. > > So in order to bring this array to python we need to know the length > of FILE, create an array and then get a pointer for the elements 1 and > 2 of that array. > > The main problem is to get the length of FILE, is 152 bytes in amd64, > and 88 bytes in i386, no idea in other platforms, but given that this > lengths can change, hardcoding this numbers is ugly and bad... > > That's why I added a small C code and a sh script to get the > sizeof(__sF[1]) and passing that value to sed to then patch the python > script. > > Maybe there is a better way of handling the issue, I don't see it... > My only doubt is that libc is used by the package inside the python > script, and if the size of FILE changes, the package should be rebuilt > to refresh the value of the given size. > Should I add libc as a WANTLIB ? > > > Cheers. > Elias.
Re: [M. UPDATE] devel/py-jedi 0.13.1 -> 0.13.2
On Wed, Dec 19, 2018 at 11:55 AM Björn Ketelaars wrote: > $ echo "select fullpkgpath from depends where > dependspath='devel/py-jedi'"|sqlite3 /usr/local/share/sqlports > devel/spyder/spyder > devel/spyder/spyder > > There is only 1 consumer, of which you are the MAINTAINER as well. $ echo "select fullpkgpath from depends where dependspath like 'devel/py-jedi%'"|sqlite3 /usr/local/share/sqlports devel/spyder/spyder devel/spyder/spyder devel/spyder/spyder,python3 devel/spyder/spyder,python3 x11/gnome/builder But, yeah... py-jedi is a soft dependency of gnome-builder in any case.
[NEW] devel/py-wurlitzer 1.0.2
https://github.com/minrk/wurlitzer https://pypi.org/project/wurlitzer/ Capture C-level stdout/stderr pipes in Python via os.dup2. This package is required to update devel/spyder/py-spyder-kernels and devel/spyder/spyder. Taking Maintainership. A weird patch has to be made in order to make this package to work properly: The original script calls to the function fflush from libc with a parameter to stdout or stderr, for that a pointer is needed. In linux: c_stdout_p = ctypes.c_void_p.in_dll(libc, 'stdout') But OpenBSD doesn't have a defined symbol for 'stdout' in libc, but an array of FILE structs called __sF, where __sF[1] corresponds to stdout and __sF[2] to stderr. So in order to bring this array to python we need to know the length of FILE, create an array and then get a pointer for the elements 1 and 2 of that array. The main problem is to get the length of FILE, is 152 bytes in amd64, and 88 bytes in i386, no idea in other platforms, but given that this lengths can change, hardcoding this numbers is ugly and bad... That's why I added a small C code and a sh script to get the sizeof(__sF[1]) and passing that value to sed to then patch the python script. Maybe there is a better way of handling the issue, I don't see it... My only doubt is that libc is used by the package inside the python script, and if the size of FILE changes, the package should be rebuilt to refresh the value of the given size. Should I add libc as a WANTLIB ? Cheers. Elias. py-wurlitzer.tar.gz Description: GNU Zip compressed data
Re: [UPDATE] devel/py-jupyter_core and devel/py-jupyter_client
Follow-up:
A pull request was made to upstream 9 days ago:
https://github.com/jupyter/jupyter_client/pull/412
No reply for now.
In the meantime they made a small update from jupyter-client 5.2.3 to
5.2.4, according with the changelog the changes only affect Windows:
https://github.com/jupyter/jupyter_client/blob/5.2.4/docs/changelog.rst
So find attached the 5.2.4 version of the port instead of the 5.2.3.
On Mon, Dec 10, 2018 at 3:18 PM Elias M. Mariani wrote:
>
> Hi Björn,
> First, thanks for testing, good luck that you found that small but
> important case.
> On my thoughts about the issue, I'm attaching two diff, one with
> py-jupyter_core and one with py-jupyter_client, the later with a patch
> to disable the use of the sticky bit.
> The code actually checks if:
> "if hasattr(stat, 'S_ISVTX')", so I have to assume that the logical
> step would be to extend the "if" to cover our case: We have the sticky
> bit, but we can not use it (leaving root aside), so:
> "if hasattr(stat, 'S_ISVTX') and not sys.platform.startswith('openbsd'):"
>
> The warning is no more on my side, and test are passing, would you
> care to test the patch ?
> By the way, just out of curiosity, you use jupyter for something in
> particular? I'm only updating it to cover the requires to update
> devel/spyder and it would be good to include you in future updates if
> you are interested in testing the changes.
>
> Thanks.
> Elias.
>
> On Sun, Dec 9, 2018 at 3:42 AM Björn Ketelaars
> wrote:
> >
> > On Sat 08/12/2018 17:38, Elias M. Mariani wrote:
> > > py-jupyter_core 4.3.0 to 4.4.0:
> > > Changelog:
> > > https://github.com/jupyter/jupyter_core/blob/4.4.0/docs/changelog.rst
> > >
> > > - Taking maintainership. (already talked to Alexandr)
> > > - HOMEPAGE to HTTPS.
> > > - A little love to the patches to keep working.
> > > - Regression test:
> > >
> > > devel/py-jupyter_core and devel/py-jupyter_core,python3:
> > > 40 passed
> > > Same results for 4.3.0 and 4.4.0.
> > >
> > >
> > > py-jupyter_client 5.1.0 to 5.2.3:
> > > Changelog:
> > > https://github.com/jupyter/jupyter_client/blob/5.2.3/docs/changelog.rst
> > >
> > >
> >
> > For what it is worth, I prefer to look at two separate diffs instead of
> > one. Helps me giving feedback. That said:
> >
> > Both updates look good, and test ok in an existing jupyter-notebook
> > setup. However, jupyter_client gives a warning when opening a workbook:
> >
> > [I 06:41:46.032 NotebookApp] Kernel started:
> > 1a170f9c-4d7a-4646-abac-fff4961889d6
> > /usr/local/lib/python3.6/site-packages/jupyter_client/connect.py:163:
> > RuntimeWarning: Failed to set sticky bit on
> > '/home/bket/.local/share/jupyter/runtime/kernel-1a170f9c-4d7a-4646-abac-fff4961889d6.json':
> > [Errno 79] Inappropriate file type or format:
> > '/home/bket/.local/share/jupyter/runtime/kernel-1a170f9c-4d7a-4646-abac-fff4961889d6.json'
> > Probably not a big deal, but runtime files may be cleaned up periodically.
> > RuntimeWarning,
> >
> > The warning is caused by [1], which tries to set the sticky bit on a
> > file. On OpenBSD the latter is only allowed by the superuser, see
> > sticky(8).
> > Easy fix would be for an user to just ignore the warning. However, I
> > think the behaviour of jupyter_client is wrong, and should be patched.
> > What do you think?
> >
> > [1]
> > https://github.com/jupyter/jupyter_client/blob/master/jupyter_client/connect.py#L152
py-jupyter_core-4.4.0.diff
Description: Binary data
py-jupyter_client-5.2.4.diff
Description: Binary data
[M. UPDATE] devel/py-jedi 0.13.1 -> 0.13.2
Changelog: https://github.com/davidhalter/jedi/blob/v0.13.2/CHANGELOG.rst Small bugfix, consumers shouldn't be affected. Test results: py-jedi 1476 passed, 272 skipped, 4 xfailed py3-jedi 1731 passed, 17 skipped, 4 xfailed Cheers. Elias. py-jedi-0.13.2.diff Description: Binary data
Re: [UPDATE] devel/py-jupyter_core and devel/py-jupyter_client
Hi Björn,
First, thanks for testing, good luck that you found that small but
important case.
On my thoughts about the issue, I'm attaching two diff, one with
py-jupyter_core and one with py-jupyter_client, the later with a patch
to disable the use of the sticky bit.
The code actually checks if:
"if hasattr(stat, 'S_ISVTX')", so I have to assume that the logical
step would be to extend the "if" to cover our case: We have the sticky
bit, but we can not use it (leaving root aside), so:
"if hasattr(stat, 'S_ISVTX') and not sys.platform.startswith('openbsd'):"
The warning is no more on my side, and test are passing, would you
care to test the patch ?
By the way, just out of curiosity, you use jupyter for something in
particular? I'm only updating it to cover the requires to update
devel/spyder and it would be good to include you in future updates if
you are interested in testing the changes.
Thanks.
Elias.
On Sun, Dec 9, 2018 at 3:42 AM Björn Ketelaars
wrote:
>
> On Sat 08/12/2018 17:38, Elias M. Mariani wrote:
> > py-jupyter_core 4.3.0 to 4.4.0:
> > Changelog:
> > https://github.com/jupyter/jupyter_core/blob/4.4.0/docs/changelog.rst
> >
> > - Taking maintainership. (already talked to Alexandr)
> > - HOMEPAGE to HTTPS.
> > - A little love to the patches to keep working.
> > - Regression test:
> >
> > devel/py-jupyter_core and devel/py-jupyter_core,python3:
> > 40 passed
> > Same results for 4.3.0 and 4.4.0.
> >
> >
> > py-jupyter_client 5.1.0 to 5.2.3:
> > Changelog:
> > https://github.com/jupyter/jupyter_client/blob/5.2.3/docs/changelog.rst
> >
> >
>
> For what it is worth, I prefer to look at two separate diffs instead of
> one. Helps me giving feedback. That said:
>
> Both updates look good, and test ok in an existing jupyter-notebook
> setup. However, jupyter_client gives a warning when opening a workbook:
>
> [I 06:41:46.032 NotebookApp] Kernel started:
> 1a170f9c-4d7a-4646-abac-fff4961889d6
> /usr/local/lib/python3.6/site-packages/jupyter_client/connect.py:163:
> RuntimeWarning: Failed to set sticky bit on
> '/home/bket/.local/share/jupyter/runtime/kernel-1a170f9c-4d7a-4646-abac-fff4961889d6.json':
> [Errno 79] Inappropriate file type or format:
> '/home/bket/.local/share/jupyter/runtime/kernel-1a170f9c-4d7a-4646-abac-fff4961889d6.json'
> Probably not a big deal, but runtime files may be cleaned up periodically.
> RuntimeWarning,
>
> The warning is caused by [1], which tries to set the sticky bit on a
> file. On OpenBSD the latter is only allowed by the superuser, see
> sticky(8).
> Easy fix would be for an user to just ignore the warning. However, I
> think the behaviour of jupyter_client is wrong, and should be patched.
> What do you think?
>
> [1]
> https://github.com/jupyter/jupyter_client/blob/master/jupyter_client/connect.py#L152
py-jupyter_core-4.4.0.diff
Description: Binary data
py-jupyter_client-5.2.3.diff
Description: Binary data
Re: UPDATE: x11/kde-applications/klettres
Tested on amd64: Build: OK make port-lib-depends-check: OK portcheck: OK Running the application, I got a couple of hangups, but I'm testing in a VM, full-vanilla FVWM without dbus. So, the application starts, but it hangup in that particular environment, not checked in a more common "KDE" enviroment. Looks good to me. On Sat, Dec 8, 2018 at 12:31 PM Rafael Sadowski wrote: > > > Information for inst:klettres-18.08.2 > > Comment: > alphabet learning application for KDE > > Description: > KLettres aims to help to learn the alphabet and then to read some > syllables in different languages. It is meant to help learning the > very first sounds of a new language, for children or for adults. > > Currently 25 languages are available: Arabic, Czech, Brazilian > Portuguese, Danish, Dutch, British English, English, English Phonix, > French, German, Hebrew, Hungarian, Italian, Kannada, Hebrew, Hindi > Romanized, Low Saxon, Luganda, Malayalam, Norwegian Bokml, Punjabi, > Spanish, Slovak, Ukrainian and Telugu, you can choose them using > the Languages menu. A toolbar with the special characters per > language is provided if you don't have the correct country keyboard > or the keyboard layout to be able to display correctly the accented > letters. > > Maintainer: KDE porting team > > Simple one by one KDE5 klettres update, > > Ok to import? > > Rafael Sadowski
Re: UPDATE: x11/kde-applications/kmplot
Tested on amd64: Build: OK make port-lib-depends-check: OK portcheck: OK Run: OK Looks good to me. On Sat, Dec 8, 2018 at 1:03 PM Rafael Sadowski wrote: > > > Information for inst:kmplot-18.08.2 > > Comment: > mathematical function plotter for KDE > > Description: > KmPlot is a mathematical function plotter for the KDE. > > It has built in a powerfull parser. You can plot different functions > simultaneously and combine their function terms to build new > functions. KmPlot supports functions with parameters and functions > in polar coordinates. Several grid modes are possible. Plots may > be printed with high precision in correct scale. > > Maintainer: KDE porting team > > > Ok to replace KDE4 kmplot? > > Rafael Sadowski
[UPDATE] devel/py-jupyter_core and devel/py-jupyter_client
py-jupyter_core 4.3.0 to 4.4.0: Changelog: https://github.com/jupyter/jupyter_core/blob/4.4.0/docs/changelog.rst - Taking maintainership. (already talked to Alexandr) - HOMEPAGE to HTTPS. - A little love to the patches to keep working. - Regression test: devel/py-jupyter_core and devel/py-jupyter_core,python3: 40 passed Same results for 4.3.0 and 4.4.0. py-jupyter_client 5.1.0 to 5.2.3: Changelog: https://github.com/jupyter/jupyter_client/blob/5.2.3/docs/changelog.rst - Taking maintainership. (already talked to Alexandr) - HOMEPAGE to HTTPS. - Removed no longer necessary patch. - Added new dependencies. - Fixed tests (shells/bash dependency missing) - Regression test: devel/py-jupyter_client 5.1.0: 2 failed, 89 passed, 1 skipped 5.2.3: 1 failed, 93 passed, 2 skipped devel/py-jupyter_client,python3 5.1.0: 2 failed, 89 passed, 1 skipped 5.2.3: 1 failed, 93 passed, 2 skipped Tested direct consumers of both: Format: FULLPKGPATH OLD_RESULT NEW_RESULT devel/py-nbformat 132 passed, 2 warnings 132 passed, 2 warnings devel/py-nbformat,python3 132 passed, 2 warnings 132 passed, 2 warnings devel/py-nbconvert 1 failed, 201 passed, 29 skipped, 3 warnings 1 failed, 201 passed, 29 skipped, 3 warnings devel/py-nbconvert,python3 1 failed, 202 passed, 28 skipped, 3 warnings 1 failed, 202 passed, 28 skipped, 3 warnings devel/py-ipykernel Ran 95 tests, 2 skipped Ran 95 tests, 2 skipped devel/py-ipykernel,python3 Ran 95 tests, 1 skipped Ran 95 tests, 1 skipped shells/py-qtconsole Ran 25 tests Ran 25 tests shells/py-qtconsole,python3 Ran 25 tests Ran 25 tests www/jupyter-notebook Ran 250, 8 skipped Ran 250, 8 skipped www/jupyter-notebook,python3 Ran 250, 8 skipped Ran 250, 8 skipped Cheers. Elias. py-jupyter.diff Description: Binary data
Re: [M. UPDATE] net/qbittorrent 4.1.3 -> 4.1.4
This update is: OK rsadowski@ OK solene@ Someone to commit ? Thanks. Elias. On Wed, Nov 28, 2018 at 5:00 PM Rafael Sadowski wrote: > > On Sat Nov 24, 2018 at 11:10:10PM -0300, Elias M. Mariani wrote: > > Changelog: > > https://www.qbittorrent.org/news.php > > > > Small diff attached. > > Tested on amd64 without problems (both qbittorrent and qbittorrent-nox). > > > > A small tweak on the README for qbittorrent-nox, now is needed to > > specify a locale to have text on the interface... > > > > Cheers. > > Elias. > > OK rsadowski@ qbittorrent-4.1.4.diff Description: Binary data
Re: Updating several ports
Hi Daniel, I dropped the changes long ago, and as you say, they are newer versions for almost every port from that moment to now. I am NOT interested anymore in taking the maintainership. That being said, send the diff to the list when you have it, I can help to test a little. Cheers. Elias. On Sun, Dec 2, 2018 at 4:14 PM Daniel Jakots wrote: > > Hi, > > I plan to look at those ports next week. (Nearly?) All the ports have > seen newer releases since July. I'm probably going to look at your > diff for hint but I doubt I'm going to apply them directly. Two > questions: > - Do you have any updated diff in your tree? No need to look at them if > you don't! I just want to be sure there's no duplicated work but I > can do it directly, it's barely the same amount of work. > - Do you still want to take Maintainership? > > Cheers, > Daniel > > On Tue, 24 Jul 2018 22:33:45 -0300, "Elias M. Mariani" > wrote: > > > To check for the possibility of this updates affecting other ports I > > checked every port using the current versions vs the updated versions, > > the results are attached. > > The format is: > > FULLPKGPATH > > Result using current version > > Result using new version (if differences exist, none if equals) > > > > The only ones giving a different result are: > > www/py-httpie > > 4 failed, 223 passed, 4 skipped, 13 warnings > > Error: fixture is being applied more than once to the same function > > > > devel/py-doit > > 2 failed, 731 passed, 21 skipped > > Error: fixture is being applied more than once to the same function > > > > According to the pytest changelog: > > "Now when @pytest.fixture is applied more than once to the same > > function a ValueError is raised. This buggy behavior would cause > > surprising problems and if was working for a test suite it was mostly > > by accident." > > https://docs.pytest.org/en/latest/changelog.html#pytest-3-6-0-2018-05-23 > > > > So I think that with this we can rest assure that the updates work > > fine. With that I propose to update the versions with the unified > > diff that I attached as well, and the new dependency on py-test-xdist: > > py-test-forked (also attached...). > > Doing the change at once seems to me reasonable given the > > interdependency and also the way in witch I made the tests. > > > > Side notes: > > - I added Remi and Benoitt to the thread because I think they were the > > last ones working with py-httpie and py-doit. And might be interested > > I guess in the results. > > - The results might be wrong given the nature of the tests, sometimes > > errors appear because a conflict with another package and things like > > that, but the point of the tests is not to tests the ports in this > > case, but whether if the new version present any difference with the > > current one. > > > > Cheers. > > Elias. > > > > 2018-07-22 17:50 GMT-03:00 Elias M. Mariani : > > > I will send this piece by piece. > > > Checking the results between the current version and the new one, to > > > see if something differ, and if so, if is because a positive outcome > > > of the update or a bug in the newer version. > > > I think that this will be positive to all, specially those that use > > > pytest in their outgoing effort of updating python ports. > > > > > > Cheers. > > > Elias. > > > > > > 2018-07-22 12:32 GMT-03:00 Elias M. Mariani > > > : > > >> Hi Brian, > > >> You are right, I will test and check a little more about some of > > >> the updates. But bare in mind that I check each one by testing > > >> them one by one, including pytest itself. > > >> Also tested some of my ports to see if the results matched out, > > >> those was: devel/py-parso > > >> devel/py-jedi > > >> textproc/py-xlrd > > >> > > >> And some other random ports, > > >> Even find out that py-click test wasn't working because we should > > >> define LANG=C.UTF-8 before the test, I will check on that later. > > >> > > >> I will make a full report on the results of several test so you and > > >> the others rest assure about the update. > > >> About the changes on pytest, I looked into the changes and > > >> potential problems, didn't find anything that could make problems, > > >> mostly of the things that they changed are just marked as > > >> "deprecated". And
[M. UPDATE] devel/py-pathlib2 2.3.2 -> 2.3.3
Changelog: https://github.com/mcmtroffaes/pathlib2/blob/2.3.3/CHANGELOG.rst - Bring back old deprecated dependency syntax. - Drop Python 3.3 support. - Add Python 3.7 support. Results regression tests from 2.3.2 and 2.3.3 return the same: + Test results for 2.3.2 + py-pathlib2: Ran 396 tests, 125 skipped. py3-pathlib2: Ran 396 tests, 119 skipped. + Test results for 2.3.3 + py-pathlib2: Ran 396 tests, 125 skipped. py3-pathlib2: Ran 396 tests, 119 skipped. Cheers. Elias. py-pathlib2-2.3.3.diff Description: Binary data
Re: [REVISION] x11/lxqt/powermanagement
Yes, I like your text better, I modified it just a little bit.
I copied the original out from meta/gnome:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/meta/gnome/pkg/README-main?rev=1.42
And in for some reason I still modified my rc.conf.local manually...
Cheers.
Elias.
On Wed, Nov 28, 2018 at 2:42 PM Stuart Henderson wrote:
>
> On 2018/11/28 14:34, Elias M. Mariani wrote:
> > Adding a small pkg-readme to explain how to get lxqt-powermanagement to
> > work.
> >
> >
> > Startup
> > ===
> > LXQt Power Management depends on KF5Solid and it needs a system-wide
> > D-Bus daemon to be running in order to work properly. So the need
> > to add "messagebus" to "pkg_scripts" in rc.conf.local(8) or start
> > it manually with "rcctl start messagebus" before starting the LXQt
> > session.
> >
> >
> > Cheers.
> > Elias.
>
> We normally point people at rcctl for these; possible alternative text:
>
>
>
> Startup
> ===
> LXQt Power Management depends on KF5Solid and it needs a system-wide
> D-Bus daemon ("messagebus") to be running in order to work properly.
>
> To enable at boot and start if not already running:
>
> # rcctl enable messagebus
> # rcctl start messagebus
>
>
>
>
>
lxqt-powermanagement-0.13.0p0.diff
Description: Binary data
[REVISION] x11/lxqt/powermanagement
Adding a small pkg-readme to explain how to get lxqt-powermanagement to work. Startup === LXQt Power Management depends on KF5Solid and it needs a system-wide D-Bus daemon to be running in order to work properly. So the need to add "messagebus" to "pkg_scripts" in rc.conf.local(8) or start it manually with "rcctl start messagebus" before starting the LXQt session. Cheers. Elias. lxqt-powermanagement-0.13.0p0.diff Description: Binary data
Re: [REVISION] x11/lxqt/build-tools and x11/lxqt/libqtxdg
Small ping for a small change. On Thu, Nov 15, 2018 at 6:35 AM Elias M. Mariani wrote: > > From George Koehler: > https://marc.info/?l=openbsd-ports&m=154118440613320 > "The build system tries to use link-time optimization (-flto > -fuse-linker-plugin). This fails because -fuse-linker-plugin "is > available in gold or in GNU ld 2.21 or newer" (says man egcc), but > OpenBSD has GNU ld 2.17. > > x11/lxqt/build-tools enables LTO for gcc, so the failure would happen > on ports-gcc arches like powerpc. Most packages outside LXQt don't > enable LTO, so I disabled LTO by modifying x11/lxqt/build-tools." > Thanks to George Koehler for the solution. > > The same applies to x11/lxqt/libqtxdg. > > Thanks landry@ for the bulk with the failure report. > > This should fix the build on non-clang archs. > > Cheers. > Elias. lxqt-gcc-fix.diff Description: Binary data
Re: [UPDATE] print/lyx 2.2.3 -> 2.3.1
Modifications: - Changed from textproc/enchant to textproc/enchant2. - Added x11/qt5/qtx11extras to LIB_DEPENDS. - Configure picked up new WANTLIBs: xcb Qt5X11Extras I love cmake way more than gnu configure... std::regex is been used instead of boost::regex, do we have archs without C++11? Cheers. Elias. On Tue, Nov 27, 2018 at 10:58 PM Elias M. Mariani wrote: > > On Tue, Nov 27, 2018 at 9:03 PM Josh Grosse wrote: > > The only thing I noticed was this port-lib-depends-check complaint: > > > >Missing lib: enchant-2.0 (/usr/local/bin/lyx) (NOT REACHABLE) > >Extra: enchant.6 > Oh, I see. > I build with textproc/enchant and you have installed > textproc/enchant2, so probably the configuration is picking in your > case the newer library. > I will send a new diff tomorrow using textproc/enchant2, it has more > sense than using enchant. > > Thanks for the report! > Elias. lyx-2.3.1.diff Description: Binary data
Re: [UPDATE] print/lyx 2.2.3 -> 2.3.1
On Tue, Nov 27, 2018 at 9:03 PM Josh Grosse wrote: > The only thing I noticed was this port-lib-depends-check complaint: > >Missing lib: enchant-2.0 (/usr/local/bin/lyx) (NOT REACHABLE) >Extra: enchant.6 Oh, I see. I build with textproc/enchant and you have installed textproc/enchant2, so probably the configuration is picking in your case the newer library. I will send a new diff tomorrow using textproc/enchant2, it has more sense than using enchant. Thanks for the report! Elias.
[UPDATE] print/lyx 2.2.3 -> 2.3.1
Changes port-wise:
- Changed from qt4 to qt5.
- Removed a patch no longer needed.
- New patch needed for the case when sizeof(long long) == sizeof(long).
- Take MAINTAINER.
- Removed files/lyx.desktop, 2.3.1 comes with one already.
- Added textproc/hunspell support.
My concerns about the port:
- Need to test if it builds and runs in other archs, only amd64 tested
and I don't want to leave anyone without their lyx...
- I changed to qt5 because I like to use all from a single library if
possible, so changing to qt5 might be a personal bias given that I
maintain almost qt5 ports :), is there any problem with the change ?
- For some reason I require devel/boost to build and test lyx, but the
libraries from boost are not in WANTLIB, they are not required to run
the application, someone has an idea of why is that?
- I tried to use python3, it fails to run some scripts, so I
established python2 as mandatory. I know is the default, but I would
prefer to leave the:
MODPY_VERSION= ${MODPY_DEFAULT_VERSION_2}
So I remember that python3 is no good for now.
- Was there any reason why hunspell wasn't been used ?
Added some people to the CC that might be interested in the update for
what I saw in the list.
Anyways, I tried to explain all the changes, can I have you testing a
little bit ? :)
Cheers.
Elias.
lyx-2.3.1.diff
Description: Binary data
[M. UPDATE] net/qbittorrent 4.1.3 -> 4.1.4
Changelog: https://www.qbittorrent.org/news.php Small diff attached. Tested on amd64 without problems (both qbittorrent and qbittorrent-nox). A small tweak on the README for qbittorrent-nox, now is needed to specify a locale to have text on the interface... Cheers. Elias. qbittorrent-4.1.4.diff Description: Binary data
[REVISION] x11/lxqt/build-tools and x11/lxqt/libqtxdg
>From George Koehler: https://marc.info/?l=openbsd-ports&m=154118440613320 "The build system tries to use link-time optimization (-flto -fuse-linker-plugin). This fails because -fuse-linker-plugin "is available in gold or in GNU ld 2.21 or newer" (says man egcc), but OpenBSD has GNU ld 2.17. x11/lxqt/build-tools enables LTO for gcc, so the failure would happen on ports-gcc arches like powerpc. Most packages outside LXQt don't enable LTO, so I disabled LTO by modifying x11/lxqt/build-tools." Thanks to George Koehler for the solution. The same applies to x11/lxqt/libqtxdg. Thanks landry@ for the bulk with the failure report. This should fix the build on non-clang archs. Cheers. Elias. lxqt-gcc-fix.diff Description: Binary data
[PING] My submissions to ports
Single mail to avoid noise. [M. Update] x11/py-qtpy 1.5.1 -> 1.5.2 https://marc.info/?l=openbsd-ports&m=154101398828762 Soft update. [M. Update] devel/py-jedi 0.12.1 -> 0.13.1 https://marc.info/?l=openbsd-ports&m=154101393628394 Soft update. [NEW?] devel/ipython-docs 5.8.0 https://marc.info/?l=openbsd-ports&m=154108651107576 Re-adding the missing docs of ipython (explanation in the thread). Cheers. Elias.
Re: [NEW?] devel/ipython-docs 5.8.0
Ups... Forgot the tarball... El jue., 1 nov. 2018 a las 12:26, Elias M. Mariani () escribió: > > Until now this docs where packaged with the devel/ipython package. > For reasons regarding circular dependencies now we must build > devel/ipykernel(depends on devel/ipython) before building the docs, > that is why ipython 5.8.0 (recently committed) does not have docs > included. > This package solves the missing piece, this package has no consumers. > > Talked with Maintainer long ago: > https://marc.info/?l=openbsd-ports&m=153559672813813 > > Cheers. > Elias. ipython-docs-5.8.0.tar.gz Description: GNU Zip compressed data
