Re: update net/deluge 2.0.3
Nam Nguyen writes:
> This is an update for net/deluge 2.0.3, released June 12, 2019. It uses
> the updated net/libtorrent-rasterbar sent in a previous e-mail:
> https://marc.info/?l=openbsd-ports&m=157767835916456&w=2
>
> Changelogs: https://deluge.readthedocs.io/en/latest/changelog.html
> https://deluge.readthedocs.io/en/latest/releases/2.0.html
>
> "Migrated to Python 3 with minimal support retained for Python 2.7."
> Python3 bindings don't work for libtorrent-rasterbar, as reported by
> FreeBSD: https://github.com/arvidn/libtorrent/issues/4204. As such, I
> propose monitoring the situation and migrating to python 3 in the
> future, while keeping python 2 in this proposed update.
>
> tj@ mentioned that net/deluge-ltconfig will no longer work with this
> update and should be marked IGNORE until it can be updated.
>
> I had patch-deluge_ui_gtk3_common_py which fixed deluge crashing on
> startup due to a failure to register deluge as the default magnet uri
> with dbus. I do not think it is needed anymore so it is not part of this
> proposed update.
>
> https://www.namtsui.com/cgi-bin/cvsweb/ports/net/deluge/patches/Attic/patch-deluge_ui_gtk3_common_py?rev=1.1&content-type=text/x-cvsweb-markup
Here is a revised diff that moves deluge to python 3, using the proposed
fixes for devel/boost and proposed update for net/libtorrent-rasterbar.
Here is a quick way to test that the libtorrent python 3 bindings are
working.
$ python3 -c "from deluge._libtorrent import lt; print(lt.version)"
1.2.3.0
>
> Feedback and tests are welcome.
boost fix: https://marc.info/?l=openbsd-ports&m=157941202507663&w=2
libtorrent-rasterbar update:
https://marc.info/?l=openbsd-ports&m=157941739108514&w=2
Index: Makefile
===
RCS file: /cvs/ports/net/deluge/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- Makefile12 Jul 2019 20:48:24 - 1.7
+++ Makefile19 Jan 2020 07:07:25 -
@@ -3,8 +3,7 @@
COMMENT = bittorrent client
DISTNAME = deluge-${MODPY_EGG_VERSION}
-MODPY_EGG_VERSION =1.3.15
-REVISION = 3
+MODPY_EGG_VERSION =2.0.3
CATEGORIES = net
@@ -13,23 +12,28 @@ HOMEPAGE = https://www.deluge-torrent.or
# GPLv3+
PERMIT_PACKAGE = Yes
-MASTER_SITES = https://ftp.osuosl.org/pub/deluge/source/
+MASTER_SITES = https://ftp.osuosl.org/pub/deluge/source/2.0/
EXTRACT_SUFX = .tar.xz
MODULES = lang/python \
textproc/intltool
+MODPY_VERSION =${MODPY_DEFAULT_VERSION_3}
MODPY_SETUPTOOLS = Yes
-BUILD_DEPENDS =devel/py-xdg \
+BUILD_DEPENDS =devel/py-wheel,python3 \
+ devel/py-xdg,python3 \
net/libtorrent-rasterbar \
- textproc/py-chardet
+ textproc/py-chardet,python3
RUN_DEPENDS = devel/desktop-file-utils \
- devel/py-twisted \
- devel/py-xdg \
- graphics/py-Pillow \
+ devel/py-gobject3,python3 \
+ devel/py-rencode,python3 \
+ devel/py-setproctitle,python3 \
+ devel/py-twisted,python3 \
+ devel/py-xdg,python3 \
+ graphics/py-Pillow,python3 \
net/libtorrent-rasterbar \
- textproc/py-chardet \
- www/py-mako \
+ textproc/py-chardet,python3 \
+ www/py-mako,python3 \
x11/gtk+3,-guic \
x11/py-gtk2
Index: distinfo
===
RCS file: /cvs/ports/net/deluge/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo8 Feb 2018 06:32:10 - 1.1.1.1
+++ distinfo19 Jan 2020 07:07:25 -
@@ -1,2 +1,2 @@
-SHA256 (deluge-1.3.15.tar.xz) = qWQFFA48vFaebgVhZeKJpensZuA2wyfzkSxz0EnM+Sw=
-SIZE (deluge-1.3.15.tar.xz) = 1467368
+SHA256 (deluge-2.0.3.tar.xz) = fnro5soqK/DUhyJ87PgeJzMvC5K1Z8wr2jjkfYWdqJE=
+SIZE (deluge-2.0.3.tar.xz) = 1777624
Index: patches/patch-deluge_ui_gtkui_preferences_py
===
RCS file: patches/patch-deluge_ui_gtkui_preferences_py
diff -N patches/patch-deluge_ui_gtkui_preferences_py
--- patches/patch-deluge_ui_gtkui_preferences_py31 Oct 2018 12:41:50
- 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,24 +0,0 @@
-$OpenBSD: patch-deluge_ui_gtkui_preferences_py,v 1.1 2018/10/31 12:41:50
ajacoutot Exp $
-
-From 38d7b7cdfde3c50d6263602ffb03af92fcbfa52e Mon Sep 17 00:00:00 2001
-From: Calum Lind
-Date: Sat, 13 May 2017 00:05:48 +0100
-Subject: [GTKUI] Fix keyerror showing prefs
-
-Index: deluge/ui/gtkui/preferences.py
deluge/ui/gtkui/preferences.py.orig
Re: update net/libtorrent-rasterbar 1.2.3
Klemens Nanni writes:
> On Sun, Dec 29, 2019 at 07:57:46PM -0800, Nam Nguyen wrote:
>> Python 2 is used because python 3 is currently problematic, as
>> reported by FreeBSD. https://github.com/arvidn/libtorrent/issues/4204
> Perhaps some other issue, I don't quite recall, but broken Python 3
> support is what halted my efforts earlier this year trying to update it.
>
> For now, I wasted enough time on this and have no plans to give it
> another before upstream fully supports Python 3, sorry.
Here is a new diff updating libtorrent-rasterbar to 1.2.3 incorporating
feedback from kn@ that:
* Uses fix for devel/boost python 3 bindings
https://marc.info/?l=openbsd-ports&m=157941202507663&w=2
* Stays with current build system and not cmake
* Runs unit tests
* SHARED_LIBS comment # 10.0.0. From `set (SOVERSION "10")' in
CMakeLists.txt.
The unit tests take 17 minutes to run, and they are run in
parallel. This gives the impression that the test suite is frozen since
you get no sense of progress until it is complete. The benefit of cmake
would be that although the tests are run sequentially, it prints out
progress. However, this is not compelling enough to switch to cmake, so
I propose just saying on the current build system. (I had failed to give
a reason for the move to cmake in my initial proposal.)
In my initial proposal I noted that test_web_seed_http and test_url_seed
were important unit tests. I managed to resolve test_url_seed with
apatch to OpenBSD's devel/boost at
boost/asio/detail/impl/socket_ops.ipp. I have not yet solved the web
seed test. I will incorporate my work upstream with boost asio instead
of carrying a patch.
https://github.com/arvidn/libtorrent/issues/4211
>
>> Testing
>> ===
>> Feedback and tests are welcome because this is a major update. I tested
>> it by downloading and seeding a linux ISO. I did not get to test a thin
>> client / server setup for example.
> qbittorrent is another consumer, did you test this as well?
I tested qbittorrent, and it works. I will post the qbittorrent update
shortly. I had rushed the initial port update without testing
it.
Feedback and tests are welcome.
>
> Port-wise looks good so far, but as per above I haven't tested any of
> it; a few comments/nits inline.
>
>> -SHARED_LIBS += torrent-rasterbar 1.0 # 9.0.0
>> +SHARED_LIBS += torrent-rasterbar 2.0 # 9.0.0
> I think upstream's version got bumped to 10.0.0 or so, did you check?
>
>> -MODULES = lang/python
>> +MODULES = devel/cmake \
>> +lang/python
>> +
>> +MODPY_SETUPTOOLS = Yes
> Perhaps leave a comment about Python 3 being broken?
>
>> --- /dev/null1 Jan 1970 00:00:00 -
>> +++ patches/patch-include_libtorrent_buffer_hpp 30 Dec 2019 02:32:22
>> -
>> @@ -0,0 +1,23 @@
>> +$OpenBSD$
> Please add a brief comment such that it appears in `make patch'
> output.
snip
>> Index: patches/patch-test_setup_transfer_cpp
>> ===
>> RCS file: patches/patch-test_setup_transfer_cpp
>> diff -N patches/patch-test_setup_transfer_cpp
>> --- /dev/null1 Jan 1970 00:00:00 -
>> +++ patches/patch-test_setup_transfer_cpp30 Dec 2019 02:32:22 -
>> @@ -0,0 +1,14 @@
>> +$OpenBSD$
> Same here.
>
>> +Index: test/setup_transfer.cpp
>> +--- test/setup_transfer.cpp.orig
>> test/setup_transfer.cpp
>> +@@ -604,7 +604,7 @@ std::string get_python()
>> +if (sz == buf.size() - 1) return buf.data();
>> +}
>> + #endif
>> +- return "python";
>> ++ return "${MODPY_BIN}";
> Perhaps you can replace the entire patch and SUBST_CMD with below?
>
> pre-test:
> ln -s ${MODPY_BIN} ${WRKDIR}/python
Index: Makefile
===
RCS file: /cvs/ports/net/libtorrent-rasterbar/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile12 Jul 2019 20:48:31 - 1.8
+++ Makefile19 Jan 2020 06:24:04 -
@@ -2,10 +2,10 @@
COMMENT = C++ library implementing a BitTorrent client
-MODPY_EGG_VERSION =1.1.13
+MODPY_EGG_VERSION =1.2.3
DISTNAME = libtorrent-rasterbar-${MODPY_EGG_VERSION}
-SHARED_LIBS += torrent-rasterbar 1.0 # 9.0.0
+SHARED_LIBS += torrent-rasterbar 2.0 # 10.0.0
CATEGORIES = net devel
@@ -14,13 +14,13 @@ HOMEPAGE = https://libtorrent.org/
# BSD3
PERMIT_PACKAGE = Yes
-WANTLIB += boost_chrono-mt boost_python boost_random-mt boost_system-mt
-WANTLIB += crypto m ssl
+WANTLIB += boost_python3 boost_system-mt crypto m ssl
WANTLIB += ${COMPILER_LIBCXX} ${MODPY_WANTLIB}
MASTER_SITES =
https://github.com/arvidn/libtorrent/releases/download/libtorrent-${MODPY_EGG_VERSION:S/./_/g}/
MODULES = lang/python
+MODPY_VERSION =${MODPY_DEFAULT_VERSION_3}
BUILD_DEPENDS =devel/libtool
@@ -32,12 +32,15 @@ COMPILER =
Re: [big endian] add NOT_FOR_ARCHS to emulators/citra
On Sat, Jan 18, 2020 at 10:57:21AM +0100, Charlene Wendling wrote:
> Hi,
> > http://build-failures.rhaalovely.net/powerpc/last/emulators/citra.log
> > http://build-failures.rhaalovely.net/sparc64/last/emulators/citra.log
> > http://build-failures.rhaalovely.net/mips64/last/emulators/citra.log
> I don't have much to say. Citra has endianness issues, even with recent
> versions [0].
> OK?
> Charlène.
> [0] https://github.com/citra-emu/citra/issues/4571
ok kmos
--Kurt
> Index: Makefile
> ===
> RCS file: /cvs/ports/emulators/citra/Makefile,v
> retrieving revision 1.11
> diff -u -p -u -p -r1.11 Makefile
> --- Makefile 12 Jul 2019 20:46:08 - 1.11
> +++ Makefile 18 Jan 2020 09:49:47 -
> @@ -1,5 +1,8 @@
> # $OpenBSD: Makefile,v 1.11 2019/07/12 20:46:08 sthen Exp $
>
> +# See https://github.com/citra-emu/citra/issues/4571
> +NOT_FOR_ARCHS = ${BE_ARCHS}
> +
> BROKEN-i386 =undefined reference to `operator delete(void*,
> std::align_val_t)', etc.
>
> USE_WXNEEDED = Yes
>
[NEW] www/p5-Plack-Request-WithEncoding
An extension to Plack::Request Any comments? Thanks! -- Chris Bennett p5-Plack-Request-WithEncoding.tar.gz Description: GNU Zip compressed data
[NEW] www/p5-Plack-Builder-Conditionals
An extension to Plack::Builder Comments? Thanks! -- Chris Bennett p5-Plack-Builder-Conditionals.tar.gz Description: GNU Zip compressed data
devel/boost fix python 3 bindings
This diff for devel/boost fixes python 3 bindings and is needed for
upcoming updates to net/libtorrent-rasterbar and net/deluge. CC
maintainers and kn@ because python 3 bindings were a blocker for a
net/libtorrent-rasterbar update.
* Fixes python 3 bindings
* Bumps REVISION-main
* Bumps SO_VERSION because libboost_python3.so.9.0 now correctly uses
python 3 bringing with it modified function signatures like
init_module.
* Contains an upstream compilation fix for python 3.7
before fix:
$ nm -g /usr/local/lib/libboost_python3.so.9.0
0003d210 T _ZN5boost6python6detail11init_moduleEPKcPFvvE
$ nm -g /usr/local/lib/libboost_python.so.9.0
0003d210 T _ZN5boost6python6detail11init_moduleEPKcPFvvE
after fix:
$ nm -g /usr/local/lib/libboost_python3.so.9.0
0003b730 T _ZN5boost6python6detail11init_moduleER11PyModuleDefPFvvE
$ nm -g /usr/local/lib/libboost_python.so.9.0
0003d210 T _ZN5boost6python6detail11init_moduleEPKcPFvvE
boost/python/module_init.hpp:
# if PY_VERSION_HEX >= 0x0300
BOOST_PYTHON_DECL PyObject* init_module(PyModuleDef&, void(*)());
#else
BOOST_PYTHON_DECL PyObject* init_module(char const* name, void(*)());
#endif
After the fix it now correctly uses python 2 and python 3 bindings. The
way I arrived at this was to see that list.o was compiled with:
"clang++" -c -x c++ -O2 -pipe -pthread -O2 -pipe -pthread -O3 -Wno-inline
-Wall -m64 -O2 -pipe -pthread -O2 -pipe -pthread -DBOOST_ALL_NO_LIB=1
-DBOOST_PYTHON_SOURCE -DBOOST_PYTHON_STATIC_LIB -DNDEBUG -I"."
-I"/usr/local/include/python3.7m" -o
"bin.v2/libs/python/build/clang-gnu-linux-8.0.1/release/link-static/pch-off/threadapi-pthread/list.o"
"libs/python/src/list.cpp"
Then, list.o was reused in the creation of libboost_python3.so.9.0 and
libboost_python.so.9.0. list.o was never recompiled against python 2.
"clang++" -o
"bin.v2/libs/python/build/clang-gnu-linux-8.0.1/release/pch-off/threadapi-pthread/libboost_python3.so.9.0"
-Wl,-soname -Wl,libboost_python3.so.9.0 -shared -Wl,--start-group
"bin.v2/libs/python/build/clang-gnu-linux-8.0.1/release/pch-off/threadapi-pthread/list.o"
"clang++" -o
"bin.v2/libs/python/build/clang-gnu-linux-8.0.1/release/pch-off/threadapi-pthread/libboost_python.so.9.0"
-Wl,-soname -Wl,libboost_python.so.9.0 -shared -Wl,--start-group
"bin.v2/libs/python/build/clang-gnu-linux-8.0.1/release/pch-off/threadapi-pthread/list.o"
My plan was to:
1. Build only python 3 bindings using --with-python and stash the
objects in ${PY3_DIR}.
2. Delete list .o objects to force recompilation.
3. Rebuild entire project with python 2.
Now, during step 3, it will rebuild list.o against python 2.
"clang++" -c -x c++ -O2 -pipe -pthread -O2 -pipe -pthread -O3 -Wno-inline
-Wall -m64 -O2 -pipe -pthread -O2 -pipe -pthread -DBOOST_ALL_NO_LIB=1
-DBOOST_PYTHON_SOURCE -DBOOST_PYTHON_STATIC_LIB -DNDEBUG -I"."
-I"/usr/local/include/python2.7" -o
"bin.v2/libs/python/build/clang-gnu-linux-8.0.1/release/link-static/pch-off/threadapi-pthread/list.o"
"libs/python/src/list.cpp"
Also, boostrap.sh contains:
using python : $PYTHON_VERSION : $PYTHON_ROOT ;
This was not expressive enough for my needs to simply provide
$PYTHON_VERSION and $PYTHON_ROOT. Instead I use sed to get lines of the
form:
using python : 2.7 : /usr/local : /usr/local/include/python2.7 ;
using python : 3.7 : /usr/local : /usr/local/include/python3.7m ;
Sources:
tools/build/src/tools/python.jam
https://stackoverflow.com/questions/28830653/build-boost-with-multiple-python-versions
https://www.boost.org/doc/libs/1_67_0/libs/python/doc/html/building/configuring_boost_build.html
The patch is an upstream fix for a compilation error with python 3.7.
https://github.com/boostorg/python/commit/660487c43fde76f3e64f1cb2e644500da92fe582
boost 1.67 changes the python naming convention to be of the form
libboost_python{27,37}.so.9.0. boost 1.67 also tries to allow building
against multiple versions of python in one run of b2. While my initial
approach was to try to backport 1.67 fixes alluded to in the changelog,
I quickly abandoned this effort because I was not getting
libtorrent-rasterbar to link properly. `make port-lib-depends-check'
inside libtorrent-rasterbar would report that boost_python3 was
unused. I suggest revisiting this during the next boost update.
https://www.boost.org/users/history/version_1_67_0.html
https://github.com/boostorg/python/commit/d4d41d94aecc9f8098aabd3587fcb95458451f71
Python:
The library name now includes the version suffix of the Python
version used to compile it. For example, a variant compiled with
Python 2.7 will produce library names boost_python27 and
boost_numpy27, etc.. Combined with a related fix in Boost.Build,
this means that it is now possible to build variants for multiple
Python versions in a single build process.
To test I tried games/freeorion and games/vegastrike, which compiled and
started fine. graphics/openexr compiled fine but no f
[NEW] devel/p5-Version-Compare
This tests perl module versions to see which is higher version. I have set TEST_POD and RELEASE_TESTING. Unless there is some objection, I will set release and author testing in future Perl ports also. The mechanism is there. It seems worthwhile to use it, unless this places too big a burden on bulk builds? Comments? Thanks! -- Chris Bennett p5-Version-Compare.tar.gz Description: GNU Zip compressed data
Re: [PATCH] Update inputmethods/anthy from 9100 to 0.4
On 2020-01-18 13:16:58, Omar Polo wrote: > Hi, > > On Thu, Jan 09, 2020 at 11:34:34PM +0900, Bryan Linton wrote: > > Hello ports@ > > > > I was attempting to make some changes to inputmethods/anthy for > > another purpose when I noticed it was woefully out of date. > > > > Version 9100h was released in 2009. Version 0.4 was released six > > months ago (in 2019). > > > > [snip] > > > > Concerns: > > > > * I have not tested the emacs module because I do not use emacs. I > > have however tested it in Firefox, leafpad, a Japanized xterm, and > > editors/nvi running in said Japanized xterm. More testing would > > be appreciated though. > > Thanks for working on this! It compiles here, but I cannot judge > the quality of the patch. Some comments after a bit of testing with > inputmethod/uim: > Hello, thank you for testing! Some comments follow inline. > - firefox (and possibly other programs) need some directories to >be unveiled [0]. > Yes, I was the one who sent that email too :) It's not specific to this update though. Even the old version of anthy would need those directories unveiled. I have another update to anthy that switches it to using a common directory in line with what Theo suggested later in that thread. But I wanted to hopefully get this update in-tree before going forward with that. > - with gajim (gtk3) and emacs (gtk3) works as expected > Great, thanks! This was the one use-case I couldn't test myself since I don't use emacs. > - xterm and emacs (compiled with the lucid toolkit) sort of. While >typing, the characters are displayed as rectangles (similarly >to when a font is missing), but after pressing enter the whole >word is displayed properly. Also, the selection box does not >appear in these programs (but these probably are issues with uim >rather than anthy.) > Yes, this definitely sounds like a uim issue. To be clear, is this a regression? I.e. Did this work OK before, but broke with this update? Also as a follow-up, can you check whether you're using the "Anthy" or the "Anthy (UTF-8)" input method in UIM? If it's the former, does it fix this if you switch it to UTF-8? As I mentioned in the initial email, the internals of anthy have switched to be completely UTF-8. If you're using the old input method, does switching to "Anthy (UTF-8)" in uim fix this? Failing that, does running xterm with the script I've pasted in below fix this? > (note that I used emacs with the x input method, just like with > firefox and gajim, not with uim.el) > > With ibus the situation is a bit different: it recognize anthy, but > it does not seems to work. You can switch the input method, but > nothing more. Again, this might be simply a problem with ibus > and/or my setup. > I saw your followup email that this works OK, which is good to know! > P.S. I'm curious, what do you mean with "japanized xterm"? > I use the following script to launch xterm when I want to use Japanese in it. I'm not sure if the line running uim-xim is needed anymore, since I now launch uim from my .xsession file, but the second line sets the locale to Japanese and changes the font to a Japanese one. -8<- % cat bin/jxterm.sh #!/bin/sh env LC_CTYPE=ja_JP.UTF-8 uim-xim & env LC_ALL=ja_JP.UTF-8 xterm -fa "Sazanami Gothic" -fs 16 $1 # Keep messages in English #env LANG=ja_JP.UTF-8 LC_MESSAGES=en_US.UTF-8 xterm -fa "Sazanami Gothic" -fs 16 -8<- This not only lets me see Japanese text displayed in xterm, but sets any programs I run in it to be "Japanese" for lack of a better way of explaining it. I.e. in a normal xterm, when I run mutt the top line is: q:Quit d:Del u:Undel s:Save m:Mail r:Reply g:Group ?:Help However when I run it in a "Japanized" xterm (with LC_ALL set to Japanese), the top line is instead: q:中止 d:削除 u:削除を取り消し s:保存 m:メール r:返信 g:全員に返信 ?:ヘルプ and all other messages are displayed in Japanese instead of English. The third line would retain messages in English instead of localizing them as above. Anyway, thank you again for testing! -- Bryan > [0] https://marc.info/?l=openbsd-ports&m=157811336612326&w=2 > > > * The IM I use on top of anthy (inputmethods/uim) produced utter > > gibberish until I realized that I needed to switch it from "Anthy" > > to "Anthy (UTF-8). A note in current.html like the attached > > should probably be added so that users have a smoother upgrade > > path. > > > > > > Please let me know if I can make any other improvements to the port. > > > > Thank you! > > > > -- > > Bryan > > > > > Index: Makefile > > === > > RCS file: /cvs/ports/inputmethods/anthy/Makefile,v > > retrieving revision 1.25 > > diff -u -r1.25 Makefile > > --- Makefile12 Jul 2019 20:47:12 - 1.25 > > +++ Makefile9 Jan 2020 14:25:29 - > > @@ -3,8 +3,9 @@ > > COMMENT-main = japanese input method > > COM
update p5-IO-stringy 2.111 to p5-IO-Stringy 2.113 (yes, name changed)
I need the updated version for a new port. Information for inst:p5-IO-stringy-2.111p0 Required by: p5-CGI-Simple-1.115 p5-Config-IniFiles-3.02p0 p5-MIME-tools-5.509 The new version also includes examples now. Should I go ahead and change the name, test the other three ports with it and submit with the new name if all passes the tests? Or does something else need to happen? Thanks -- Chris Bennett
sparc64 bulk build report
Bulk build on sparc64-0.ports.openbsd.org Started : Wed Jan 15 23:06:07 MST 2020 Finished: Sat Jan 18 14:37:38 MST 2020 Duration: 2 Days 15 hours 32 minutes Built using OpenBSD 6.6-current (GENERIC.MP) #188: Wed Jan 15 08:10:26 MST 2020 Built 9715 packages Number of packages built each day: Jan 15: 1277 Jan 16: 6596 Jan 17: 1768 Jan 18: 74 Critical path missing pkgs: http://build-failures.rhaalovely.net/sparc64/2020-01-15/summary.log Build failures: 68 http://build-failures.rhaalovely.net/sparc64/2020-01-15/cad/magic.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/cad/netgen.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/cad/qucs.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/chinese/libpinyin.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/comms/xastir.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/devel/kf5/kdeclarative.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/devel/kf5/kinit.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/devel/kf5/kmediaplayer.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/devel/kf5/knewstuff.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/devel/kf5/knotifyconfig.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/devel/kf5/kross.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/devel/kf5/purpose.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/devel/py-kiwisolver.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/devel/py-unicorn.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/devel/rebar,erlang21.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/emulators/BasiliskII.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/emulators/citra.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/emulators/fs-uae.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/games/pokerth.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/games/xevil.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/geo/gdal,python3,-main.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/geo/postgis.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/geo/spatialite/gis.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/geo/spatialite/libgaiagraphics.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/graphics/asymptote.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/graphics/colord-gtk.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/graphics/ffmpegthumbnailer.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/lang/apl.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/lang/janet.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/lang/squeak/vm.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/mail/kopano/core.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/math/py-scikit-learn.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/multimedia/mkvtoolnix,no_x11.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/multimedia/synfig.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/net/bro.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/net/dleyna/renderer.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/net/dleyna/server.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/net/mutella.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/net/telegram-purple.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/print/hplip,-common.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/productivity/glabels.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/productivity/gnucash.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/sysutils/ansible.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/sysutils/collectd,-main.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/telephony/iaxclient.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/telephony/pjsua,-main.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/www/newsboat.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/www/ruby-passenger,ruby27.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/x11/gnome/bijiben.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/x11/gnome/builder.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/x11/gnome/weather.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/x11/gnome/zenity.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/x11/gtk+4.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/x11/kde-applications/dragon.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/x11/kde-applications/filelight.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/x11/kde-applications/kcron.log http://build-failures.rhaalovely.net/sparc64/2020-01-15/x11/kde-applications/keditbookmarks.log http://build-failures.rhaalovely.net/spa
Re: games/dMagnetic: Looove the do-test
Hello. I am truly sorry... I found a bug, and I was forced to do a new release. I will use the Makefile from the ports and upload a new patch tomorrow. I. AM. TRULY. SORRY! Thomas > Stuart Henderson hat am 17. Januar 2020 um 23:20 > geschrieben: > > > On 2020/01/17 18:44, Thomas Dettbarn wrote: > > Would it be a feasible approach to compare the checksums for an OpenBSD > > testsuite? > > > > With those parameters, the output will not be affected by anything written > > in the .ini file, but it would already be testing a lot of things necessary > > to play the classic games from Magnetic Scrolls on different platforms. > > (you do need to have a valid copy of the game, of course) > > Oh, that's a good idea. Done :) >
Re: [NEW] sysutils/ssh-copy-id
p1 can't be used in PKGNAME as it conflicts with REVISION, usual practice is to replace p with pl, e.g. Fixed, thank you. New port attached. -JP ssh-copy-id,1.tgz Description: application/tar-gz
Re: graphics/jpeg: enable turbojpeg
On 18/01/20 21:14 +, Stuart Henderson wrote: > On 2020/01/18 07:57, Thomas Frohwein wrote: > > Hi, > > > > This diff below enables turbojpeg header/SO to be built. Bringing this > > up because turbojpeg is a build requirement for upcoming port of > > hashlink (https://hashlink.haxe.org/). > > > > ok? > > +cc Robert, was there a particular reason for disabling this when you > switched graphics/jpeg to libjpeg-turbo, or was it just because we didn't > need it? > > I'd be happier having this put through a bulk build (or test builds for > the various browsers, but they take so long to build that it's easier to > just do a full bulk-build in this case I think), I can do that after my > current i386 build has finished. > I think there was no particular reason.
Re: graphics/jpeg: enable turbojpeg
On 2020/01/18 07:57, Thomas Frohwein wrote:
> Hi,
>
> This diff below enables turbojpeg header/SO to be built. Bringing this
> up because turbojpeg is a build requirement for upcoming port of
> hashlink (https://hashlink.haxe.org/).
>
> ok?
+cc Robert, was there a particular reason for disabling this when you
switched graphics/jpeg to libjpeg-turbo, or was it just because we didn't
need it?
I'd be happier having this put through a bulk build (or test builds for
the various browsers, but they take so long to build that it's easier to
just do a full bulk-build in this case I think), I can do that after my
current i386 build has finished.
It would also be good to get some tests on at least one gcc arch.
> Index: Makefile
> ===
> RCS file: /cvs/ports/graphics/jpeg/Makefile,v
> retrieving revision 1.66
> diff -u -p -r1.66 Makefile
> --- Makefile 1 Jan 2020 14:24:59 - 1.66
> +++ Makefile 18 Jan 2020 14:33:06 -
> @@ -5,9 +5,11 @@ COMMENT= SIMD-accelerated JPEG codec rep
> V= 2.0.4
> DISTNAME=libjpeg-turbo-${V}
> PKGNAME= jpeg-${V}
> +REVISION=0
> EPOCH= 0
>
> SHARED_LIBS+=jpeg70.0# 64.0
> +SHARED_LIBS+=turbojpeg 0.0 # 2.0.4
>
> CATEGORIES= graphics
> DPB_PROPERTIES= parallel
> @@ -27,8 +29,7 @@ MODULES=devel/cmake
> BUILD_DEPENDS= devel/yasm
> .endif
>
> -CONFIGURE_ARGS+= -DCMAKE_INSTALL_PREFIX="${PREFIX}" \
> - -DWITH_TURBOJPEG=False
> +CONFIGURE_ARGS+= -DCMAKE_INSTALL_PREFIX="${PREFIX}"
> DEBUG_PACKAGES= ${BUILD_PACKAGES}
>
> post-install:
> @@ -37,7 +38,5 @@ post-install:
> ${PREFIX}/share/doc/jpeg
> ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/jpeg
> ${INSTALL_DATA} ${WRKSRC}/example.txt ${PREFIX}/share/examples/jpeg
> - # the turbojpeg wrapper library is disabled
> - rm ${PREFIX}/lib/pkgconfig/libturbojpeg.pc
>
> .include
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/graphics/jpeg/pkg/PLIST,v
> retrieving revision 1.17
> diff -u -p -r1.17 PLIST
> --- pkg/PLIST 1 Jan 2020 14:24:59 - 1.17
> +++ pkg/PLIST 18 Jan 2020 14:33:06 -
> @@ -3,14 +3,19 @@
> @bin bin/djpeg
> @bin bin/jpegtran
> @bin bin/rdjpgcom
> +@bin bin/tjbench
tjbench uses libm, so WANTLIB needs syncing.
> @bin bin/wrjpgcom
> include/jconfig.h
> include/jerror.h
> include/jmorecfg.h
> include/jpeglib.h
> +include/turbojpeg.h
> @static-lib lib/libjpeg.a
> @lib lib/libjpeg.so.${LIBjpeg_VERSION}
> +@static-lib lib/libturbojpeg.a
> +@lib lib/libturbojpeg.so.${LIBturbojpeg_VERSION}
> lib/pkgconfig/libjpeg.pc
> +lib/pkgconfig/libturbojpeg.pc
> @man man/man1/cjpeg.1
> @man man/man1/djpeg.1
> @man man/man1/jpegtran.1
>
Re: [NEW] sysutils/ssh-copy-id
On 2020/01/18 11:10, Jan-Piet Mens wrote:
> Hello!
>
> This is a new port for ssh-copy-id(1), a script to copy one's SSH
> keys to remote hosts, ensuring that ~/.ssh and authorized_keys are
> created with correct permissions
>
> Tested on 6.6-CURRENT
>
> Previous discussion [1], and I've adopted Bryan's suggestion of using the
> portable OpenSSH mirror with apologies to Stuart for having made him create
> and have to destroy the mirror at [2] :-)
>
> -JP
>
> [1] https://marc.info/?l=openbsd-ports&m=157901150806726&w=2
> [2] https://spacehopper.org/ssh-copy-id-20161215.tar.gz
> V= 8.1p1
> PKGNAME=ssh-copy-id-${V}
> DISTNAME= openssh-${V}
> DIST_SUBDIR=${PKGNAME}
> CATEGORIES= sysutils
p1 can't be used in PKGNAME as it conflicts with REVISION, usual practice
is to replace p with pl, e.g.
DISTNAME= openssh-8.1p1
PKGNAME=ssh-copy-id-8.1pl1
or
V= 8.1p1
DISTNAME= openssh-${V}
PKGNAME=ssh-copy-id-${V:S/p/pl/}
DIST_SUBDIR isn't useful.
Re: py-tables on sparc64 [sparc64 bulk build report]
On Thu, Jan 16, 2020 at 08:59:31AM -0500, Kurt Mosiejczuk wrote:
> On Thu, Jan 16, 2020 at 08:37:56AM -0500, Kurt Mosiejczuk wrote:
> > On Thu, Jan 16, 2020 at 01:26:07PM +, Stuart Henderson wrote:
>
> > > No sparc64 to test here but this sort of failure usually is reproducible.
> > > As this is currently built with base-gcc on sparc64, switching to
> > > ports-gcc
> > > is probably the sanest first step.
>
> > > COMPILER= base-clang ports-gcc
>
> OK. Just this change makes it finish compiling fairly quickly on my test
> machine. I ran it again just to be sure because it went through so
> quickly.
Thanks. While there I'd refine tests a bit more.
With the diff below:
Ran 6355 tests in 1580.823s
FAILED (errors=2, skipped=13)
The REVISION bump might not be strictly necessary but should I include it
anyway?
-m
Index: Makefile
===
RCS file: /cvs/ports/math/py-tables/Makefile,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 Makefile
--- Makefile10 Jan 2020 13:30:41 - 1.1
+++ Makefile18 Jan 2020 18:10:11 -
@@ -6,6 +6,7 @@ MODPY_EGG_VERSION= 3.6.1
DISTNAME= tables-${MODPY_EGG_VERSION}
PKGNAME= py-${DISTNAME}
CATEGORIES=math
+REVISION= 0
HOMEPAGE= https://www.pytables.org/
MAINTAINER=Martin Reindl
@@ -13,12 +14,13 @@ MAINTAINER= Martin Reindl
[UPDATE] graphics/ipe 7.2.12 -> 7.2.13
Dear ports@ readers, The attached diff (gzip-ed in order to avoid issues with MSDOS line endings in emailing) updates graphics/ipe to the latest release. What's new upstream === (extracted from news.txt): * IpePresenter now available on MacOS. * Allow online Latex-compilation using "latexonline.cc" service. Ipe is now fully usable without a Latex installation on your computer. * Views can now be named, and view names can be used instead of numbers in iperender and ipetoipe (feature #136). * Add directory containing Ipe document to TEXINPUTS when running Latex (feature #243). * Add button to use external editor for Latex preamble (feature #261). * Handle stroke opacity correctly in properties panel (bug #252). * Set Qt size policy for labels to fixed for better resizing behaviour (bug #261). * Various fixes. What's new in the port == - Updated maintainer's email address; - bumped shared libraries major number. Other modifications are trivial updates. Lightly tested on amd64 only. All the best -- Alessandro De Laurenzis [mailto:jus...@atlantide.mooo.com] Web: http://www.atlantide.mooo.com LinkedIn: http://it.linkedin.com/in/delaurenzis ipe.diff.gz Description: application/gunzip
[UPDATE] graphics/xdot 1.0p0 -> 1.1
Dear ports@ readers,
The attached diff updates graphics/xdot to the latest release.
What's new upstream
===
- Use theme background on DotWidget;
- Faster rendering of large graphs;
- Treat sub-graphs as nodes;
- Support "outputorder" attribute when drawing.
What's new in the port
==
- Updated maintainer's email address;
- ${MODPY_COMMENT} lines updated in PLIST.
Lightly tested on amd64 only.
All the best
--
Alessandro De Laurenzis
[mailto:jus...@atlantide.mooo.com]
Web: http://www.atlantide.mooo.com
LinkedIn: http://it.linkedin.com/in/delaurenzis
Index: Makefile
===
RCS file: /cvs/ports/graphics/xdot/Makefile,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 Makefile
--- Makefile12 Jul 2019 20:47:11 - 1.3
+++ Makefile18 Jan 2020 16:18:37 -
@@ -2,14 +2,13 @@
COMMENT = interactive viewer for Graphviz dot graphs
-MODPY_EGG_VERSION = 1.0
+MODPY_EGG_VERSION = 1.1
DISTNAME = xdot-${MODPY_EGG_VERSION}
-REVISION = 0
CATEGORIES = graphics
HOMEPAGE = https://github.com/jrfonseca/xdot.py
-MAINTAINER = Alessandro De Laurenzis
+MAINTAINER = Alessandro De Laurenzis
# GPLv3
PERMIT_PACKAGE = Yes
Index: distinfo
===
RCS file: /cvs/ports/graphics/xdot/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 distinfo
--- distinfo25 Apr 2019 06:04:43 - 1.1.1.1
+++ distinfo18 Jan 2020 16:18:37 -
@@ -1,2 +1,2 @@
-SHA256 (xdot-1.0.tar.gz) = fgZ4ltcpr4Lx/QdY4mXxKZRNRpww9VDj8V29t1HMQqE=
-SIZE (xdot-1.0.tar.gz) = 26507
+SHA256 (xdot-1.1.tar.gz) = 4VxT2A3Id3QCpyWO6+bL85XQQIX/lpm7/66R3w7MJDM=
+SIZE (xdot-1.1.tar.gz) = 28315
Index: pkg/PLIST
===
RCS file: /cvs/ports/graphics/xdot/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 PLIST
--- pkg/PLIST 25 Apr 2019 06:04:43 - 1.1.1.1
+++ pkg/PLIST 18 Jan 2020 16:18:37 -
@@ -9,12 +9,12 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/xdot-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
lib/python${MODPY_VERSION}/site-packages/xdot/__init__.py
lib/python${MODPY_VERSION}/site-packages/xdot/__main__.py
-lib/python${MODPY_VERSION}/site-packages/xdot/${MODPY_PYCACHE}/
+${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/xdot/${MODPY_PYCACHE}/
lib/python${MODPY_VERSION}/site-packages/xdot/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/xdot/${MODPY_PYCACHE}__main__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/xdot/dot/
lib/python${MODPY_VERSION}/site-packages/xdot/dot/__init__.py
-lib/python${MODPY_VERSION}/site-packages/xdot/dot/${MODPY_PYCACHE}/
+${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/xdot/dot/${MODPY_PYCACHE}/
lib/python${MODPY_VERSION}/site-packages/xdot/dot/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/xdot/dot/${MODPY_PYCACHE}lexer.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/xdot/dot/${MODPY_PYCACHE}parser.${MODPY_PYC_MAGIC_TAG}pyc
@@ -24,7 +24,7 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/xdot/dot/scanner.py
lib/python${MODPY_VERSION}/site-packages/xdot/ui/
lib/python${MODPY_VERSION}/site-packages/xdot/ui/__init__.py
-lib/python${MODPY_VERSION}/site-packages/xdot/ui/${MODPY_PYCACHE}/
+${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/xdot/ui/${MODPY_PYCACHE}/
lib/python${MODPY_VERSION}/site-packages/xdot/ui/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/xdot/ui/${MODPY_PYCACHE}actions.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/xdot/ui/${MODPY_PYCACHE}animation.${MODPY_PYC_MAGIC_TAG}pyc
Re: should we port ssh-copy-id ?
On Sat, Jan 18, 2020 at 10:14:57AM +0100, Jan-Piet Mens wrote: > > I assume a better distfile would be OpenSSH portable tarballs. > > It occurred to me, but I assumed the original source repository of the > script would be the cleaner method. > > > ./openssh-8.0p1/contrib/ssh-copy-id > > Would there be a reason for using 8.0p1 instead of 8.1p1 ? No, I just downloaded the wrong tarball. :-) > -JP > >
Re: NEW: sysutils/coreboot-utils
On 18/01/2020 15:22, Klemens Nanni wrote: On Wed, Jan 15, 2020 at 10:41:40PM +0100, Klemens Nanni wrote: Here's a start for something I've wanted for a while already: a small collection of selected tools I need to manipulate firmware images. This includes extracting/adding certain regions, changing files inside the coreboot file system, swapping payloads, dumping/analyzing specific parts, etc. The number of tools at upstream is huge and many of them are platform specific, require patches or simply don't work at platforms other than Linux, but with such a package I no loner have to spin up Linux VMs to tinker around unless I want to build new images. I have patches for other tools around but those need polishing, so this is the basic package with generic handling for tools; adding new ones is trivial--perhaps this enables other interested users to add their favourite tool? Information for inst:coreboot-utils-4.11 Comment: collection of utilities to work with firmware images Description: coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. As an Open Source project it provides auditability and maximum control over technology. While it is not (yet) possible to build coreboot firmware on OpenBSD, this package contains the following utilities to work with existing images: * ifdtool Extract and dump Intel Firmware Descriptor information Maintainer: Klemens Nanni WWW: https://coreboot.org New tarball with MAKE_CMD now being inlined after feedback from laundry. CC is now also being honored by all tools; eventually I should fix their Makefiles to not set certain variables in stone, but that needs to be done with/in upstream. This tarball now contains the following tools: * cbmem CBMEM parser to read e.g. timestamps and console log * ectool Dumps the RAM of a laptop's Embedded/Environmental Controller (EC) * ifdtoolExtract and dump Intel Firmware Descriptor information All three work perfectly on my X230. Feedback? OK to import and continue in-tree? ok benoit@ to import !
graphics/jpeg: enable turbojpeg
Hi,
This diff below enables turbojpeg header/SO to be built. Bringing this
up because turbojpeg is a build requirement for upcoming port of
hashlink (https://hashlink.haxe.org/).
ok?
Index: Makefile
===
RCS file: /cvs/ports/graphics/jpeg/Makefile,v
retrieving revision 1.66
diff -u -p -r1.66 Makefile
--- Makefile1 Jan 2020 14:24:59 - 1.66
+++ Makefile18 Jan 2020 14:33:06 -
@@ -5,9 +5,11 @@ COMMENT= SIMD-accelerated JPEG codec rep
V= 2.0.4
DISTNAME= libjpeg-turbo-${V}
PKGNAME= jpeg-${V}
+REVISION= 0
EPOCH= 0
SHARED_LIBS+= jpeg70.0# 64.0
+SHARED_LIBS+= turbojpeg 0.0 # 2.0.4
CATEGORIES=graphics
DPB_PROPERTIES=parallel
@@ -27,8 +29,7 @@ MODULES= devel/cmake
BUILD_DEPENDS= devel/yasm
.endif
-CONFIGURE_ARGS+= -DCMAKE_INSTALL_PREFIX="${PREFIX}" \
--DWITH_TURBOJPEG=False
+CONFIGURE_ARGS+= -DCMAKE_INSTALL_PREFIX="${PREFIX}"
DEBUG_PACKAGES=${BUILD_PACKAGES}
post-install:
@@ -37,7 +38,5 @@ post-install:
${PREFIX}/share/doc/jpeg
${INSTALL_DATA_DIR} ${PREFIX}/share/examples/jpeg
${INSTALL_DATA} ${WRKSRC}/example.txt ${PREFIX}/share/examples/jpeg
- # the turbojpeg wrapper library is disabled
- rm ${PREFIX}/lib/pkgconfig/libturbojpeg.pc
.include
Index: pkg/PLIST
===
RCS file: /cvs/ports/graphics/jpeg/pkg/PLIST,v
retrieving revision 1.17
diff -u -p -r1.17 PLIST
--- pkg/PLIST 1 Jan 2020 14:24:59 - 1.17
+++ pkg/PLIST 18 Jan 2020 14:33:06 -
@@ -3,14 +3,19 @@
@bin bin/djpeg
@bin bin/jpegtran
@bin bin/rdjpgcom
+@bin bin/tjbench
@bin bin/wrjpgcom
include/jconfig.h
include/jerror.h
include/jmorecfg.h
include/jpeglib.h
+include/turbojpeg.h
@static-lib lib/libjpeg.a
@lib lib/libjpeg.so.${LIBjpeg_VERSION}
+@static-lib lib/libturbojpeg.a
+@lib lib/libturbojpeg.so.${LIBturbojpeg_VERSION}
lib/pkgconfig/libjpeg.pc
+lib/pkgconfig/libturbojpeg.pc
@man man/man1/cjpeg.1
@man man/man1/djpeg.1
@man man/man1/jpegtran.1
Re: NEW: sysutils/coreboot-utils
On Wed, Jan 15, 2020 at 10:41:40PM +0100, Klemens Nanni wrote: > Here's a start for something I've wanted for a while already: a small > collection of selected tools I need to manipulate firmware images. > > This includes extracting/adding certain regions, changing files inside > the coreboot file system, swapping payloads, dumping/analyzing specific > parts, etc. > > The number of tools at upstream is huge and many of them are platform > specific, require patches or simply don't work at platforms other than > Linux, but with such a package I no loner have to spin up Linux VMs to > tinker around unless I want to build new images. > > I have patches for other tools around but those need polishing, so this > is the basic package with generic handling for tools; adding new ones > is trivial--perhaps this enables other interested users to add their > favourite tool? > > Information for inst:coreboot-utils-4.11 > > Comment: > collection of utilities to work with firmware images > > Description: > coreboot is an extended firmware platform that delivers a lightning > fast and > secure boot experience on modern computers and embedded systems. As an > Open > Source project it provides auditability and maximum control over > technology. > > While it is not (yet) possible to build coreboot firmware on OpenBSD, > this > package contains the following utilities to work with existing images: > > * ifdtool Extract and dump Intel Firmware Descriptor information > > Maintainer: Klemens Nanni > > WWW: https://coreboot.org New tarball with MAKE_CMD now being inlined after feedback from laundry. CC is now also being honored by all tools; eventually I should fix their Makefiles to not set certain variables in stone, but that needs to be done with/in upstream. This tarball now contains the following tools: * cbmem CBMEM parser to read e.g. timestamps and console log * ectool Dumps the RAM of a laptop's Embedded/Environmental Controller (EC) * ifdtoolExtract and dump Intel Firmware Descriptor information All three work perfectly on my X230. Feedback? OK to import and continue in-tree? coreboot-utils.tgz Description: Binary data
Re: [big endian] add NOT_FOR_ARCHS to emulators/citra
ok thfr@ and thanks for the research!
On Sat, Jan 18, 2020, at 2:57 AM, Charlene Wendling wrote:
> Hi,
>
> > http://build-failures.rhaalovely.net/powerpc/last/emulators/citra.log
> > http://build-failures.rhaalovely.net/sparc64/last/emulators/citra.log
> > http://build-failures.rhaalovely.net/mips64/last/emulators/citra.log
>
> I don't have much to say. Citra has endianness issues, even with recent
> versions [0].
>
> OK?
>
> Charlène.
>
>
> [0] https://github.com/citra-emu/citra/issues/4571
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/emulators/citra/Makefile,v
> retrieving revision 1.11
> diff -u -p -u -p -r1.11 Makefile
> --- Makefile 12 Jul 2019 20:46:08 - 1.11
> +++ Makefile 18 Jan 2020 09:49:47 -
> @@ -1,5 +1,8 @@
> # $OpenBSD: Makefile,v 1.11 2019/07/12 20:46:08 sthen Exp $
>
> +# See https://github.com/citra-emu/citra/issues/4571
> +NOT_FOR_ARCHS = ${BE_ARCHS}
> +
> BROKEN-i386 =undefined reference to `operator delete(void*,
> std::align_val_t)', etc.
>
> USE_WXNEEDED = Yes
>
--
tfrohw...@fastmail.com
PGP Public Key: https://pgp.mit.edu/pks/lookup?op=get&search=0xE1A22D58D20C6D22
Re: BoUML 7.9 for OpenBSD 6.6 x86_64
Hi Bruno, cont...@bouml.fr wrote on Sat, Jan 18, 2020 at 11:44:49AM +0100: > I am the author of BoUML [1], in the past up to the release 4.23 I > distributed it under the GPL license, them the releases 5.x was not > free, and finally since the release 7.0 BoUML is free of use but I > decided to not distribute the sources. > > On openBSD you still distribute the old release 4.23 (the last in open > source) http://openports.se/devel/bouml > > Few days ago a user asked me to package the last release (7.9) for > openBSD 6.6 x86_64, I made it and it is available on my site, see > https://www.bouml.fr/download.html#openBSD > > That user also said me I should submit the package to the ports list on > openBSD community, but I imagine this is not compatible with your > requirements because I do not give the sources, am I wrong ? There is no simple "yes" or "no" answer. In principle, all of the following can be included in the OpenBSD ports tree: - non-free software - non-open-source freeware (like yours IIUC) - free software (either copylefted and truely free) OpenBSD developer and porter time is limited, and sometimes even inclusion of very good software gets delayed because a porter needs to come round to it. If upstream authors make users jump through hoops (like by not making their software fully free), that may or may not dampen the interest of individual porters and hence may or may not delay inclusion, in the worst case indefinitely. (For example, personally, i strongly favor fully free and open software, but several ports of software that isn't fully free do exist and are not frowned upon, unless they cause undue maintenance burden.) There is a practical problem, though. Ports development is only done on OpenBSD -current. You cannot submit a port for any -stable release, not even for the latest one (6.6 currently). In the -current branch, there is no promise whatsoever of API or even ABI stability. For example, libc tends to have an API or ABI break every few months, and these are neither scheduled, nor is there any prior warning in public. For that reason, it is *much* easier to port software to OpenBSD when source code is available. You would probably have to do a formal upstream release right after every OpenBSD API/ABI break (not sure whether there is a simpler solution). Currently, there isn't even a developer maintaining our devel/bouml port. Of course, you could maintain it yourself if you are willing to do regular testing on OpenBSD-current and willing to answer questions about the port. Then, for each upstream release, you still need to attract the interest of a developer to get the update committed. Yours, Ingo -- Ingo Schwarze http://www.openbsd.org/ http://mandoc.bsd.lv/
Re: PATCH: security/gpgme: allow cmake to find .so files
Hi,
On Sun, Feb 24, 2019 at 09:42:50PM +0100, Caspar Schutijser wrote:
> [...]
Here is a new attempt to explain why I am sending this patch.
The patch below allows the libraries provided by this port to be found
with cmake. This does not appear to be necessary for the ports tree
(the ports that use gpgme can be built, after all), however I do need
this in order to build a piece of software outside the ports tree
that uses gpgme.
Ports that have similar patches:
databases/xapian-core
devel/gwenhywfar
graphics/prison
productivity/aqbanking
x11/polkit-qt
x11/polkit-qt5
I successfully build-tested mail/trojita and x11/kde4/pim; these ports
depends on gpgme *and* use cmake.
Thanks,
Caspar Schutijser
Index: Makefile
===
RCS file: /cvs/ports/security/gpgme/Makefile,v
retrieving revision 1.56
diff -u -p -r1.56 Makefile
--- Makefile15 Aug 2019 18:20:21 - 1.56
+++ Makefile18 Jan 2020 12:23:54 -
@@ -7,7 +7,7 @@ VERSION = 1.13.1
DISTNAME = gpgme-${VERSION}
PKGNAME-main = gpgme-${VERSION}
PKGNAME-qt = gpgme-qt-${VERSION}
-REVISION = 0
+REVISION = 1
CATEGORIES = security devel
@@ -68,6 +68,10 @@ CONFIGURE_ARGS +=--enable-languages=''
# needed for the regression tests
USE_GMAKE =Yes
+
+pre-configure:
+ ${SUBST_CMD} ${WRKSRC}/lang/cpp/src/GpgmeppConfig.cmake.in.in
+ ${SUBST_CMD} ${WRKSRC}/lang/qt/src/QGpgmeConfig.cmake.in.in
# The tests target gpg2. Running with gpg version 1 will give:
# `./t-support.h:160: GPGME: Invalid crypto engine'
Index: patches/patch-lang_cpp_src_GpgmeppConfig_cmake_in_in
===
RCS file: patches/patch-lang_cpp_src_GpgmeppConfig_cmake_in_in
diff -N patches/patch-lang_cpp_src_GpgmeppConfig_cmake_in_in
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-lang_cpp_src_GpgmeppConfig_cmake_in_in18 Jan 2020
12:23:54 -
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+Index: lang/cpp/src/GpgmeppConfig.cmake.in.in
+--- lang/cpp/src/GpgmeppConfig.cmake.in.in.orig
lang/cpp/src/GpgmeppConfig.cmake.in.in
+@@ -63,8 +63,8 @@ add_library(Gpgmepp SHARED IMPORTED)
+
+ set_target_properties(Gpgmepp PROPERTIES
+ INTERFACE_INCLUDE_DIRECTORIES
"@resolved_includedir@/gpgme++;@resolved_includedir@"
+- INTERFACE_LINK_LIBRARIES
"pthread;@resolved_libdir@/libgpgme@libsuffix@;@LIBASSUAN_LIBS@"
+- IMPORTED_LOCATION "@resolved_libdir@/libgpgmepp@libsuffix@"
++ INTERFACE_LINK_LIBRARIES
"pthread;@resolved_libdir@/libgpgme@libsuffix@.${LIBgpgme_VERSION};@LIBASSUAN_LIBS@"
++ IMPORTED_LOCATION
"@resolved_libdir@/libgpgmepp@libsuffix@.${LIBgpgmepp_VERSION}"
+ )
+
+ if(CMAKE_VERSION VERSION_LESS 2.8.12)
Index: patches/patch-lang_qt_src_QGpgmeConfig_cmake_in_in
===
RCS file: patches/patch-lang_qt_src_QGpgmeConfig_cmake_in_in
diff -N patches/patch-lang_qt_src_QGpgmeConfig_cmake_in_in
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-lang_qt_src_QGpgmeConfig_cmake_in_in 18 Jan 2020 12:23:54
-
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+Index: lang/qt/src/QGpgmeConfig.cmake.in.in
+--- lang/qt/src/QGpgmeConfig.cmake.in.in.orig
lang/qt/src/QGpgmeConfig.cmake.in.in
+@@ -64,7 +64,7 @@ add_library(QGpgme SHARED IMPORTED)
+ set_target_properties(QGpgme PROPERTIES
+ INTERFACE_INCLUDE_DIRECTORIES
"@resolved_includedir@/qgpgme;@resolved_includedir@"
+ INTERFACE_LINK_LIBRARIES "Gpgmepp;Qt5::Core"
+- IMPORTED_LOCATION "@resolved_libdir@/libqgpgme@libsuffix@"
++ IMPORTED_LOCATION
"@resolved_libdir@/libqgpgme@libsuffix@.${LIBqgpgme_VERSION}"
+ )
+
+ if(CMAKE_VERSION VERSION_LESS 2.8.12)
Re: [base-gcc] Unbreak multimedia/synfig
Ping :)
On Sat, 11 Jan 2020 22:05:46 +0100
Charlene Wendling wrote:
>
> > http://build-failures.rhaalovely.net/powerpc/2019-12-25/multimedia/synfig.log
> > http://build-failures.rhaalovely.net/sparc64/2020-01-05/multimedia/synfig.log
>
> In fact the problem lies in devel/etl.
>
> Upstream already fixed that [0]. With the below diff it fixes the
> build of multimedia/synfig{,studio}, the only consumers, on powerpc
> [1].
>
> amd64 is still fine with it.
>
> Comments/feedback are welcome,
>
> Charlène.
>
>
> [0]
> https://github.com/synfig/synfig/commit/cb05b072fe6fffb4433140c631f422bdbc036722
> [1] https://bin.charlenew.xyz/etl_logs.tgz
>
Index: Makefile
===
RCS file: /cvs/ports/devel/etl/Makefile,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 Makefile
--- Makefile12 Jul 2019 20:44:08 - 1.7
+++ Makefile11 Jan 2020 20:59:28 -
@@ -3,6 +3,7 @@
COMMENT = C++ class and template library
V =1.2.1
+REVISION = 0
DISTNAME = ETL-${V}
PKGNAME = etl-${V}
Index: patches/patch-ETL__pen_h
===
RCS file: patches/patch-ETL__pen_h
diff -N patches/patch-ETL__pen_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-ETL__pen_h11 Jan 2020 20:59:28 -
@@ -0,0 +1,18 @@
+$OpenBSD$
+
+Unbreak consumers on !clang archs, from:
+https://github.com/synfig/synfig/commit/cb05b072fe6fffb4433140c631f422bdbc036722
+
+Index: ETL/_pen.h
+--- ETL/_pen.h.orig
ETL/_pen.h
+@@ -136,7 +136,8 @@ class generic_pen (public)
+ typedef int value_type;
+ value_type x,y;
+ difference_type(value_type x, value_type y):x(x),y(y) { }
+- value_type &operator[](int i)const { return i?y:x; }
++ const value_type &operator[](int i) const { return i?y:x; }
++ value_type &operator[](int i) { return i?y:x; }
+ };
+
+ protected:
Re: [PATCH] Update inputmethods/anthy from 9100 to 0.4
On Sat, Jan 18, 2020 at 01:16:58PM +0100, Omar Polo wrote:
> Hi,
>
> On Thu, Jan 09, 2020 at 11:34:34PM +0900, Bryan Linton wrote:
> > Hello ports@
> >
> > I was attempting to make some changes to inputmethods/anthy for
> > another purpose when I noticed it was woefully out of date.
> >
> > Version 9100h was released in 2009. Version 0.4 was released six
> > months ago (in 2019).
> >
> > [snip]
> >
> > Concerns:
> >
> > * I have not tested the emacs module because I do not use emacs. I
> > have however tested it in Firefox, leafpad, a Japanized xterm, and
> > editors/nvi running in said Japanized xterm. More testing would
> > be appreciated though.
>
> Thanks for working on this! It compiles here, but I cannot judge
> the quality of the patch. Some comments after a bit of testing with
> inputmethod/uim:
> - firefox (and possibly other programs) need some directories to
>be unveiled [0].
> - with gajim (gtk3) and emacs (gtk3) works as expected
> - xterm and emacs (compiled with the lucid toolkit) sort of. While
>typing, the characters are displayed as rectangles (similarly
>to when a font is missing), but after pressing enter the whole
>word is displayed properly. Also, the selection box does not
>appear in these programs (but these probably are issues with uim
>rather than anthy.)
>
> (note that I used emacs with the x input method, just like with
> firefox and gajim, not with uim.el)
>
> With ibus the situation is a bit different: it recognize anthy, but
> it does not seems to work. You can switch the input method, but
> nothing more. Again, this might be simply a problem with ibus
> and/or my setup.
Sorry for the follow up, but it seems that anthy works ibus too.
I just find out by accident that in inside inkscape I'm able to
fully use ibus+anthy. The reason why on xterm, gajim and emacs
(gtk3) ibus doesn't seem to work must be something really specific
to my setup and not the anthy update.
cheers!
> P.S. I'm curious, what do you mean with "japanized xterm"?
>
> [0] https://marc.info/?l=openbsd-ports&m=157811336612326&w=2
>
> > * The IM I use on top of anthy (inputmethods/uim) produced utter
> > gibberish until I realized that I needed to switch it from "Anthy"
> > to "Anthy (UTF-8). A note in current.html like the attached
> > should probably be added so that users have a smoother upgrade
> > path.
> >
> >
> > Please let me know if I can make any other improvements to the port.
> >
> > Thank you!
> >
> > --
> > Bryan
> >
>
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/inputmethods/anthy/Makefile,v
> > retrieving revision 1.25
> > diff -u -r1.25 Makefile
> > --- Makefile12 Jul 2019 20:47:12 - 1.25
> > +++ Makefile9 Jan 2020 14:25:29 -
> > @@ -3,8 +3,9 @@
> > COMMENT-main = japanese input method
> > COMMENT-emacs =emacs files for anthy
> >
> > -V =9100h
> > +V =0.4
> > DISTNAME = anthy-$V
> > +DISTFILES =anthy_$V.orig.tar.gz
> > PKGNAME-main = anthy-$V
> > PKGNAME-emacs =emacs-anthy-$V
> > REVISION-main = 2
> > @@ -16,14 +17,14 @@
> >
> > CATEGORIES = inputmethods japanese
> >
> > -HOMEPAGE = https://anthy.osdn.jp/
> > +HOMEPAGE = https://wiki.debian.org/Teams/DebianAnthy
> >
> > -# GPL, part LGPL
> > +# GPLv3, parts are LGPLv3 and/or LGPLv2+
> > PERMIT_PACKAGE = Yes
> >
> > WANTLIB-main = c m
> >
> > -MASTER_SITES = ${MASTER_SITE_OSDN_JP:=anthy/37536/}
> > +MASTER_SITES = http://deb.debian.org/debian/pool/main/a/anthy/
> >
> > FAKE_FLAGS = sysconfdir=$(PREFIX)/share/examples/anthy
> >
> > Index: distinfo
> > ===
> > RCS file: /cvs/ports/inputmethods/anthy/distinfo,v
> > retrieving revision 1.5
> > diff -u -r1.5 distinfo
> > --- distinfo18 Jan 2015 03:14:16 - 1.5
> > +++ distinfo9 Jan 2020 14:25:29 -
> > @@ -1,2 +1,2 @@
> > -SHA256 (anthy-9100h.tar.gz) = 0lbwdfAYtKPLDRZe1hUf2kun2xYhcn4OtUVptuInVUc=
> > -SIZE (anthy-9100h.tar.gz) = 4446148
> > +SHA256 (anthy_0.4.orig.tar.gz) =
> > /fWQvupwk/Myex7udgE+STbkxmWefMAd0f3W5vLpyfc=
> > +SIZE (anthy_0.4.orig.tar.gz) = 5619024
> > Index: patches/patch-src-util_anthy_el
> > ===
> > RCS file: patches/patch-src-util_anthy_el
> > diff -N patches/patch-src-util_anthy_el
> > --- patches/patch-src-util_anthy_el 7 Dec 2013 23:42:04 - 1.1
> > +++ /dev/null 1 Jan 1970 00:00:00 -
> > @@ -1,12 +0,0 @@
> > -$OpenBSD: patch-src-util_anthy_el,v 1.1 2013/12/07 23:42:04 yasuoka Exp $
> > src-util/anthy.el.orig Sat Nov 30 10:40:43 2013
> > -+++ src-util/anthy.el Sat Nov 30 10:40:55 2013
> > -@@ -892,7 +892,7 @@
> > -((event-matches-key-specifier-p event 'backspace) 8)
> > -(t
> > - (char-to-int (event-to-char
BoUML 7.9 for OpenBSD 6.6 x86_64
Hi, I am the author of BoUML [1], in the past up to the release 4.23 I distributed it under the GPL license, them the releases 5.x was not free, and finally since the release 7.0 BoUML is free of use but I decided to not distribute the sources. On openBSD you still distribute the old release 4.23 (the last in open source) http://openports.se/devel/bouml Few days ago a user asked me to package the last release (7.9) for openBSD 6.6 x86_64, I made it and it is available on my site, see https://www.bouml.fr/download.html#openBSD That user also said me I should submit the package to the ports list on openBSD community, but I imagine this is not compatible with your requirements because I do not give the sources, am I wrong ? Kind regards, Bruno Pagès Links: -- [1] https://www.bouml.fr/index.html
Re: [PATCH] Update inputmethods/anthy from 9100 to 0.4
Hi,
On Thu, Jan 09, 2020 at 11:34:34PM +0900, Bryan Linton wrote:
> Hello ports@
>
> I was attempting to make some changes to inputmethods/anthy for
> another purpose when I noticed it was woefully out of date.
>
> Version 9100h was released in 2009. Version 0.4 was released six
> months ago (in 2019).
>
> [snip]
>
> Concerns:
>
> * I have not tested the emacs module because I do not use emacs. I
> have however tested it in Firefox, leafpad, a Japanized xterm, and
> editors/nvi running in said Japanized xterm. More testing would
> be appreciated though.
Thanks for working on this! It compiles here, but I cannot judge
the quality of the patch. Some comments after a bit of testing with
inputmethod/uim:
- firefox (and possibly other programs) need some directories to
be unveiled [0].
- with gajim (gtk3) and emacs (gtk3) works as expected
- xterm and emacs (compiled with the lucid toolkit) sort of. While
typing, the characters are displayed as rectangles (similarly
to when a font is missing), but after pressing enter the whole
word is displayed properly. Also, the selection box does not
appear in these programs (but these probably are issues with uim
rather than anthy.)
(note that I used emacs with the x input method, just like with
firefox and gajim, not with uim.el)
With ibus the situation is a bit different: it recognize anthy, but
it does not seems to work. You can switch the input method, but
nothing more. Again, this might be simply a problem with ibus
and/or my setup.
P.S. I'm curious, what do you mean with "japanized xterm"?
[0] https://marc.info/?l=openbsd-ports&m=157811336612326&w=2
> * The IM I use on top of anthy (inputmethods/uim) produced utter
> gibberish until I realized that I needed to switch it from "Anthy"
> to "Anthy (UTF-8). A note in current.html like the attached
> should probably be added so that users have a smoother upgrade
> path.
>
>
> Please let me know if I can make any other improvements to the port.
>
> Thank you!
>
> --
> Bryan
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/inputmethods/anthy/Makefile,v
> retrieving revision 1.25
> diff -u -r1.25 Makefile
> --- Makefile 12 Jul 2019 20:47:12 - 1.25
> +++ Makefile 9 Jan 2020 14:25:29 -
> @@ -3,8 +3,9 @@
> COMMENT-main = japanese input method
> COMMENT-emacs = emacs files for anthy
>
> -V = 9100h
> +V = 0.4
> DISTNAME = anthy-$V
> +DISTFILES = anthy_$V.orig.tar.gz
> PKGNAME-main = anthy-$V
> PKGNAME-emacs = emacs-anthy-$V
> REVISION-main = 2
> @@ -16,14 +17,14 @@
>
> CATEGORIES = inputmethods japanese
>
> -HOMEPAGE = https://anthy.osdn.jp/
> +HOMEPAGE = https://wiki.debian.org/Teams/DebianAnthy
>
> -# GPL, part LGPL
> +# GPLv3, parts are LGPLv3 and/or LGPLv2+
> PERMIT_PACKAGE = Yes
>
> WANTLIB-main = c m
>
> -MASTER_SITES = ${MASTER_SITE_OSDN_JP:=anthy/37536/}
> +MASTER_SITES = http://deb.debian.org/debian/pool/main/a/anthy/
>
> FAKE_FLAGS = sysconfdir=$(PREFIX)/share/examples/anthy
>
> Index: distinfo
> ===
> RCS file: /cvs/ports/inputmethods/anthy/distinfo,v
> retrieving revision 1.5
> diff -u -r1.5 distinfo
> --- distinfo 18 Jan 2015 03:14:16 - 1.5
> +++ distinfo 9 Jan 2020 14:25:29 -
> @@ -1,2 +1,2 @@
> -SHA256 (anthy-9100h.tar.gz) = 0lbwdfAYtKPLDRZe1hUf2kun2xYhcn4OtUVptuInVUc=
> -SIZE (anthy-9100h.tar.gz) = 4446148
> +SHA256 (anthy_0.4.orig.tar.gz) = /fWQvupwk/Myex7udgE+STbkxmWefMAd0f3W5vLpyfc=
> +SIZE (anthy_0.4.orig.tar.gz) = 5619024
> Index: patches/patch-src-util_anthy_el
> ===
> RCS file: patches/patch-src-util_anthy_el
> diff -N patches/patch-src-util_anthy_el
> --- patches/patch-src-util_anthy_el 7 Dec 2013 23:42:04 - 1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,12 +0,0 @@
> -$OpenBSD: patch-src-util_anthy_el,v 1.1 2013/12/07 23:42:04 yasuoka Exp $
> src-util/anthy.el.orig Sat Nov 30 10:40:43 2013
> -+++ src-util/anthy.elSat Nov 30 10:40:55 2013
> -@@ -892,7 +892,7 @@
> - ((event-matches-key-specifier-p event 'backspace) 8)
> - (t
> - (char-to-int (event-to-character event)
> --last-command-char))
> -+last-command-event))
> -
> - ;;
> - ;;
> Index: pkg/PLIST-main
> ===
> RCS file: /cvs/ports/inputmethods/anthy/pkg/PLIST-main,v
> retrieving revision 1.5
> diff -u -r1.5 PLIST-main
> --- pkg/PLIST-main22 May 2015 11:31:16 - 1.5
> +++ pkg/PLIST-main9 Jan 2020 14:25:29 -
> @@ -2,18 +2,17 @@
> @pkgpath inputmethods/anthy
> @bin bin/anthy-agent
> @bin bin/anthy-dic-tool
> -@bin bin/anthy-morphological-analyzer
> include/anthy/
> include/anthy/anthy.h
> include/anthy/dicutil.h
> include/anthy/input.h
> -lib/li
mips64 bulk build report
bulk build on octeon.ports.openbsd.org started on Wed Jan 8 18:23:28 UTC 2020 finished at Thu Jan 16 01:33:43 UTC 2020 lasted 08D07h10m done with kern.version=OpenBSD 6.6-current (GENERIC.MP) #12: Wed Jan 8 17:51:08 UTC 2020 built packages:9313 Jan 8:1543 Jan 9:1321 Jan 10:851 Jan 11:574 Jan 12:483 Jan 13:578 Jan 14:725 Jan 15:2326 Jan 16:911 build failures: 75 http://build-failures.rhaalovely.net/mips64/2020-01-08/audio/mscore.log http://build-failures.rhaalovely.net/mips64/2020-01-08/cad/magic.log http://build-failures.rhaalovely.net/mips64/2020-01-08/cad/netgen.log http://build-failures.rhaalovely.net/mips64/2020-01-08/chinese/libchewing.log http://build-failures.rhaalovely.net/mips64/2020-01-08/chinese/libpinyin.log http://build-failures.rhaalovely.net/mips64/2020-01-08/devel/cgdb.log http://build-failures.rhaalovely.net/mips64/2020-01-08/devel/coccinelle.log http://build-failures.rhaalovely.net/mips64/2020-01-08/devel/libpeas.log http://build-failures.rhaalovely.net/mips64/2020-01-08/devel/py-unicorn,python3.log http://build-failures.rhaalovely.net/mips64/2020-01-08/devel/pygame,python3.log http://build-failures.rhaalovely.net/mips64/2020-01-08/devel/rebar,erlang21.log http://build-failures.rhaalovely.net/mips64/2020-01-08/devel/sdcc.log http://build-failures.rhaalovely.net/mips64/2020-01-08/editors/vim,no_x11,ruby.log http://build-failures.rhaalovely.net/mips64/2020-01-08/emulators/citra.log http://build-failures.rhaalovely.net/mips64/2020-01-08/emulators/openmsx.log http://build-failures.rhaalovely.net/mips64/2020-01-08/emulators/ppsspp.log http://build-failures.rhaalovely.net/mips64/2020-01-08/emulators/retroarch.log http://build-failures.rhaalovely.net/mips64/2020-01-08/games/astromenace.log http://build-failures.rhaalovely.net/mips64/2020-01-08/games/eduke32.log http://build-failures.rhaalovely.net/mips64/2020-01-08/games/frozen-bubble,-main.log http://build-failures.rhaalovely.net/mips64/2020-01-08/games/hyperrogue.log http://build-failures.rhaalovely.net/mips64/2020-01-08/games/postal.log http://build-failures.rhaalovely.net/mips64/2020-01-08/games/stone-soup.log http://build-failures.rhaalovely.net/mips64/2020-01-08/games/vacuum.log http://build-failures.rhaalovely.net/mips64/2020-01-08/games/valyriatear.log http://build-failures.rhaalovely.net/mips64/2020-01-08/geo/gpstk.log http://build-failures.rhaalovely.net/mips64/2020-01-08/graphics/colord-gtk.log http://build-failures.rhaalovely.net/mips64/2020-01-08/graphics/enblend-enfuse.log http://build-failures.rhaalovely.net/mips64/2020-01-08/graphics/gimp/stable.log http://build-failures.rhaalovely.net/mips64/2020-01-08/graphics/openimageio.log http://build-failures.rhaalovely.net/mips64/2020-01-08/inputmethods/scim.log http://build-failures.rhaalovely.net/mips64/2020-01-08/lang/STk.log http://build-failures.rhaalovely.net/mips64/2020-01-08/lang/gforth.log http://build-failures.rhaalovely.net/mips64/2020-01-08/lang/gpc.log http://build-failures.rhaalovely.net/mips64/2020-01-08/lang/janet.log http://build-failures.rhaalovely.net/mips64/2020-01-08/lang/parrot.log http://build-failures.rhaalovely.net/mips64/2020-01-08/lang/pfe.log http://build-failures.rhaalovely.net/mips64/2020-01-08/lang/quickjs.log http://build-failures.rhaalovely.net/mips64/2020-01-08/mail/dspam,-main.log http://build-failures.rhaalovely.net/mips64/2020-01-08/mail/kopano/core.log http://build-failures.rhaalovely.net/mips64/2020-01-08/math/gbc.log http://build-failures.rhaalovely.net/mips64/2020-01-08/math/mlpack,-main.log http://build-failures.rhaalovely.net/mips64/2020-01-08/multimedia/assimp.log http://build-failures.rhaalovely.net/mips64/2020-01-08/multimedia/mkvtoolnix,no_x11.log http://build-failures.rhaalovely.net/mips64/2020-01-08/multimedia/synfigstudio.log http://build-failures.rhaalovely.net/mips64/2020-01-08/net/dleyna/renderer.log http://build-failures.rhaalovely.net/mips64/2020-01-08/net/dleyna/server.log http://build-failures.rhaalovely.net/mips64/2020-01-08/net/pure-ftpd,ldap.log http://build-failures.rhaalovely.net/mips64/2020-01-08/net/telegram-purple.log http://build-failures.rhaalovely.net/mips64/2020-01-08/net/utox.log http://build-failures.rhaalovely.net/mips64/2020-01-08/net/wireshark,-main.log http://build-failures.rhaalovely.net/mips64/2020-01-08/plan9/drawterm.log http://build-failures.rhaalovely.net/mips64/2020-01-08/print/hplip,-common.log http://build-failures.rhaalovely.net/mips64/2020-01-08/security/botan2.log http://build-failures.rhaalovely.net/mips64/2020-01-08/shells/ksh93.log http://build-failures.rhaalovely.net/mips64/2020-01-08/sysutils/collectd,-main.log http://build-failures.rhaalovely.net/mips64/2020-01-08/sysutils/u-boot,aarch64.log http://build-failures.rhaalovely.net/mips64/2020-01-08/telephony/iaxclient.log http://build-failures.rhaalovely.net/mips64/2020-01-08/textproc/apertium-dicts/crh.log http://build-failures.rhaalovely.net/mips64/2020-01-08/textproc/apertium-dicts/tur.log http://build-failures.rhaalovely.net/mips64/2020-01-
Re: PATCH: mail/isync: don't crash when using Tunnel
On Sat, Jan 18, 2020 at 10:31:56AM +0100, Caspar Schutijser wrote: > Below is a patch that I submitted to upstream a while ago (which was > committed). Without the patch, mbsync crashes on OpenBSD when using > the Tunnel option in the configuration file. Committed, thanks.
Re: should we port ssh-copy-id ?
I've submitted a port at [1]. -JP [1] https://marc.info/?l=openbsd-ports&m=157934217426742&w=2
[NEW] sysutils/ssh-copy-id
Hello! This is a new port for ssh-copy-id(1), a script to copy one's SSH keys to remote hosts, ensuring that ~/.ssh and authorized_keys are created with correct permissions Tested on 6.6-CURRENT Previous discussion [1], and I've adopted Bryan's suggestion of using the portable OpenSSH mirror with apologies to Stuart for having made him create and have to destroy the mirror at [2] :-) -JP [1] https://marc.info/?l=openbsd-ports&m=157901150806726&w=2 [2] https://spacehopper.org/ssh-copy-id-20161215.tar.gz ssh-copy-id.tgz Description: application/tar-gz
[big endian] add NOT_FOR_ARCHS to emulators/citra
Hi,
> http://build-failures.rhaalovely.net/powerpc/last/emulators/citra.log
> http://build-failures.rhaalovely.net/sparc64/last/emulators/citra.log
> http://build-failures.rhaalovely.net/mips64/last/emulators/citra.log
I don't have much to say. Citra has endianness issues, even with recent
versions [0].
OK?
Charlène.
[0] https://github.com/citra-emu/citra/issues/4571
Index: Makefile
===
RCS file: /cvs/ports/emulators/citra/Makefile,v
retrieving revision 1.11
diff -u -p -u -p -r1.11 Makefile
--- Makefile12 Jul 2019 20:46:08 - 1.11
+++ Makefile18 Jan 2020 09:49:47 -
@@ -1,5 +1,8 @@
# $OpenBSD: Makefile,v 1.11 2019/07/12 20:46:08 sthen Exp $
+# See https://github.com/citra-emu/citra/issues/4571
+NOT_FOR_ARCHS =${BE_ARCHS}
+
BROKEN-i386 = undefined reference to `operator delete(void*,
std::align_val_t)', etc.
USE_WXNEEDED = Yes
PATCH: mail/isync: don't crash when using Tunnel
Hi,
Below is a patch that I submitted to upstream a while ago (which was
committed). Without the patch, mbsync crashes on OpenBSD when using
the Tunnel option in the configuration file.
Thanks,
Caspar Schutijser
Index: Makefile
===
RCS file: /cvs/ports/mail/isync/Makefile,v
retrieving revision 1.41
diff -u -p -r1.41 Makefile
--- Makefile12 Jul 2019 20:47:28 - 1.41
+++ Makefile18 Jan 2020 09:23:04 -
@@ -3,6 +3,7 @@
COMMENT= synchronize IMAP4 and maildir mailboxes
DISTNAME= isync-1.3.1
+REVISION= 0
CATEGORIES=mail
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=isync/}
Index: patches/patch-src_socket_c
===
RCS file: patches/patch-src_socket_c
diff -N patches/patch-src_socket_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_socket_c 18 Jan 2020 09:23:04 -
@@ -0,0 +1,30 @@
+$OpenBSD$
+
+https://sourceforge.net/p/isync/isync/ci/7607e53d56f9470ee221cd5b644dda829f54b005/
+
+commit 7607e53d56f9470ee221cd5b644dda829f54b005
+Author: Caspar Schutijser
+Date: Sun Aug 18 10:38:48 2019 +0200
+
+Do not crash when using Tunnel in an IPv6-enabled build
+
+socket_connected() is also called on the tunnel pipe.
+
+amends 3ceb55310.
+
+Index: src/socket.c
+--- src/socket.c.orig
src/socket.c
+@@ -545,8 +545,10 @@ static void
+ socket_connected( conn_t *conn )
+ {
+ #ifdef HAVE_IPV6
+- freeaddrinfo( conn->addrs );
+- conn->addrs = 0;
++ if (conn->addrs) {
++ freeaddrinfo( conn->addrs );
++ conn->addrs = 0;
++ }
+ #endif
+ conf_notifier( &conn->notify, 0, POLLIN );
+ socket_expect_read( conn, 0 );
Re: should we port ssh-copy-id ?
I assume a better distfile would be OpenSSH portable tarballs. It occurred to me, but I assumed the original source repository of the script would be the cleaner method. ./openssh-8.0p1/contrib/ssh-copy-id Would there be a reason for using 8.0p1 instead of 8.1p1 ? -JP
