CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2020/06/02 23:20:54 Modified files: devel/kdevelop : Makefile distinfo devel/kdevelop/pkg: PLIST Log message: Update kdevelop to 5.5.2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2020/06/02 23:20:34 Modified files: x11/tellico: Makefile distinfo Removed files: x11/tellico/patches: patch-src_utils_iso5426converter_cpp Log message: Update tellico to 3.3.1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2020/06/02 23:13:46 Modified files: x11/kde-applications/ark: Makefile x11/kde-applications/ark/pkg: PLIST x11/kde-applications/artikulate: Makefile x11/kde-applications/artikulate/pkg: PLIST x11/kde-applications/audiocd-kio: Makefile x11/kde-applications/audiocd-kio/pkg: PLIST x11/kde-applications/blinken: Makefile x11/kde-applications/blinken/pkg: PLIST x11/kde-applications/bomber: Makefile x11/kde-applications/bomber/pkg: PLIST x11/kde-applications/bovo: Makefile x11/kde-applications/bovo/pkg: PLIST x11/kde-applications/cantor: Makefile x11/kde-applications/cantor/pkg: PLIST x11/kde-applications/cervisia: Makefile x11/kde-applications/cervisia/pkg: PLIST x11/kde-applications/dolphin: Makefile x11/kde-applications/dolphin/pkg: PLIST x11/kde-applications/dolphin-plugins: Makefile x11/kde-applications/dolphin-plugins/pkg: PLIST x11/kde-applications/dragon: Makefile x11/kde-applications/dragon/pkg: PLIST x11/kde-applications/filelight: Makefile x11/kde-applications/filelight/pkg: PLIST x11/kde-applications/granatier: Makefile x11/kde-applications/granatier/pkg: PLIST x11/kde-applications/grantleetheme: Makefile x11/kde-applications/grantleetheme/pkg: PLIST x11/kde-applications/gwenview: Makefile x11/kde-applications/gwenview/pkg: PLIST x11/kde-applications/juk: Makefile x11/kde-applications/juk/pkg: PLIST x11/kde-applications/kalgebra: Makefile x11/kde-applications/kalgebra/pkg: PLIST x11/kde-applications/kalzium: Makefile x11/kde-applications/kalzium/pkg: PLIST x11/kde-applications/kamera: Makefile x11/kde-applications/kamera/pkg: PLIST x11/kde-applications/kanagram: Makefile x11/kde-applications/kanagram/pkg: PLIST x11/kde-applications/kapman: Makefile x11/kde-applications/kapman/pkg: PLIST x11/kde-applications/kapptemplate: Makefile x11/kde-applications/kapptemplate/pkg: PLIST x11/kde-applications/katomic: Makefile x11/kde-applications/katomic/pkg: PLIST x11/kde-applications/kbackup: Makefile x11/kde-applications/kbackup/pkg: PLIST x11/kde-applications/kblackbox: Makefile x11/kde-applications/kblackbox/pkg: PLIST x11/kde-applications/kblocks: Makefile x11/kde-applications/kblocks/pkg: PLIST x11/kde-applications/kbounce: Makefile x11/kde-applications/kbounce/pkg: PLIST x11/kde-applications/kbreakout: Makefile x11/kde-applications/kbreakout/pkg: PLIST x11/kde-applications/kbruch: Makefile x11/kde-applications/kbruch/pkg: PLIST x11/kde-applications/kcachegrind: Makefile x11/kde-applications/kcachegrind/pkg: PLIST x11/kde-applications/kcalc: Makefile x11/kde-applications/kcalc/pkg: PLIST x11/kde-applications/kcharselect: Makefile x11/kde-applications/kcharselect/pkg: PLIST x11/kde-applications/kcolorchooser: Makefile x11/kde-applications/kcolorchooser/pkg: PLIST x11/kde-applications/kcron: Makefile x11/kde-applications/kcron/pkg: PLIST x11/kde-applications/kde-dev-utils: Makefile x11/kde-applications/kde-dev-utils/pkg: PLIST x11/kde-applications/kdeedu-data: Makefile x11/kde-applications/kdeedu-data/pkg: PLIST x11/kde-applications/kdenetwork-filesharing: Makefile x11/kde-applications/kdenetwork-filesharing/pkg: PLIST x11/kde-applications/kdesdk-thumbnailers: Makefile x11/kde-applications/kdesdk-thumbnailers/pkg: PLIST x11/kde-applications/kdf: Makefile x11/kde-applications/kdf/pkg: PLIST x11/kde-applications/kdialog: Makefile x11/kde-applications/kdialog/pkg: PLIST x11/kde-applications/kdiamond: Makefile x11/kde-applications/kdiamond/pkg: PLIST x11/kde-applications/keditbookmarks: Makefile x11/kde-applications/keditbookmarks/pkg: PLIST x11/kde-applications/kfind: Makefile x11/kde-applications/kfind/pkg: PLIST x11/kde-applications/kfloppy: Makefile x11/kde-applications/kfloppy/pkg: PLIST x11/kde-applications/kfourinline: Makefile x11/kde-applications/kfourinline/pkg: PLIST x11/kde-applications/kgeography: Makefile x11/kde-applications/kgeography/pkg: PLIST x11/kde-applications/kgoldrunner: Makefile x11/kde-applications/kgoldrunner/pkg: PLIST x11/kde-applications/khangman: Makefile x11/kde-applications/khangman/pkg: PLIST x11/kde-applications/khelpcenter: Makefile
Re: Update lang/ecl to 20.4.24
On Tue, Jun 2, 2020, at 12:20, Timo Myyrä wrote: > > > On Tue, Jun 2, 2020, at 12:16, Ingo Feinerer wrote: > > On Tue, Jun 02, 2020 at 07:01:57AM +0300, Timo Myyrä wrote: > > > Did you get the maxima tests to run as well? I didn't have success yet > > > with those although the compilation worked. > > > > How did you run the tests? > > > > `make test` runs a test suite but the results are only written to a log > > file (pobj/maxima-5.43.2/maxima-5.43.2/tests/ecl-test.sh.log). As the > > tests take some time the test suite might appear to hang. > > > > The same test suite can be triggered manually if you start xmaxima and > > click on the `Maxima->Run Tests` menu entry. The output is immediately > > shown in the input/output window. > > > > Best regards, > > Ingo > > > > I did use the make test. Wondered a bit about the lack of output mut > noticed with ktrace it has doing the tests so I waited. I'll check > again later to see if the exact failure. > > Timo > > I run the tests and got following output: Running the testsuite... ;;; Loading #P"/usr/local/lib/ecl/sb-bsd-sockets.fas" ;;; Loading #P"/usr/local/lib/ecl/sockets.fas" Maxima 5.43.2 http://maxima.sourceforge.net using Lisp ECL 20.4.24 Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) build_info() (%o1) Maxima version: "5.43.2" Maxima build date: "2020-05-31 08:38:24" Host type: "x86_64-unknown-openbsd6.7" Lisp implementation type: "ECL" Lisp implementation version: "20.4.24" User dir: "/maxima-5.43.2_writes_to_HOME/.maxima" Temp dir: "/tmp" Object dir: "/usr/ports/pobj/maxima-5.43.2/maxima-5.43.2/binary/5_43_2/ecl/20_4_24" Frontend: false (%i2) testsuite_files:append(["rtest_ask.mac"],testsuite_files) (%o2) [rtest_ask.mac, [rtest_rules], rtestnset, [rtest1, [115, 183, 185, 186]], [rtest1a, [33]], [rtest2, [86, 95]], rtest4, [rtest5], [rtest6, [43, 45, 46]], rtest6a, rtest6b, rtest7, rtest9, [rtest9a], [rtest10, [24, 25]], [rtest11], rtest13, rtest13s, [rtest14, [145, 201, 233, 234, 249, 250, 251, 252, 267, 297, 298, 307, 310, 312, 315, 319]], rtest15, [rtest16, [50, 524, 525, 561]], rtestode, rtestode_zp, rtest3, [rtest8, [104]], [rtest12, [76, 78]], rexamples, [rtesthyp, [105, 112, 113, 123, 124, 128]], [rtest_hypgeo, [143]], rtestmt19937, rtest_allnummod, rtestconjugate, [rtestsum, [3, 4, 18, 75]], [rtest_trig], rtest_zeta, rtest_diff_invtrig, rtest_scalarp, rtest_everysome, [rtestint, [232]], rtest_numth, rtestifactor, [rtest_equal, [157, 160]], rtest_abs, [rtest_taylor, [88, 91, 97, 104, 128, 129]], [rtest_dot], rtest_mset, rtest_boolean, rtest_round, [rtest_map, [2, 3, 4]], [rtest_sign, [21, 25, 30, 40, 65, 72, 79]], rtest_algebraic, [rtest_gamma], rtest_expintegral, rtest_signum, rtest_lambert_w, [rtest_elliptic, [129, 143]], rtest_integrate, rtest_integrate_special, [rtest_sqrt, [89]], [rtest_carg, [40, 41]], [rtest_log], [rtest_power, [19, 20, 26, 58, 65]], rtestdefstruct, [rtest_limit], rtest_powerseries, [rtest_laplace, [29, 49, 50, 51, 54, 59, 60, 61, 62, 78, 80]], rtest_plotoptions, rtest_algsys, rtest_trace] (%i3) run_testsuite(share_tests = true) Testsuite run for ECL 20.4.24: Running tests in rtest_ask.mac: 135/135 tests passed Running tests in rtest_rules: 119/119 tests passed Running tests in rtestnset: 617/617 tests passed Running tests in rtest1: ** Problem 115 (line 341) *** Input: (batch(file_search(test_readbase_maxima, file_search_tests)), test_readbase_maxima()) Result: read and interpret /usr/ports/pobj/maxima-5.43.2/maxima-5.43.2/tests/test_readbase_maxima.mac (%i1) test_readbase_maxima():=[4,3,2,1,40,30,20,10] (%o1) test_readbase_maxima() := [4, 3, 2, 1, 40, 30, 20, 10] [4, 3, 2, 1, 40, 30, 20, 10] ... Which was correct, but was expected to be wrong due to a known bug in Maxima or ECL. 185/185 tests passed (not counting 4 expected errors) The following 1 problem passed but was expected to fail: (115) Running tests in rtest1a: 34/34 tests passed (not counting 1 expected errors) Running tests in rtest2: 287/287 tests passed (not counting 2 expected errors) Running tests in rtest4: 94/94 tests passed Running tests in rtest5: 83/83 tests passed Running tests in rtest6: ** Problem 43 (line 166) *** Input: (string(2.0e-7), (%% = 2.0e-7) or (%% = 2.0E-7) or %%) Result: true ... Which was correct, but was expected to be wrong due to a known bug in Maxima or ECL. ** Problem 45 (line 172) *** Input: 1 (string(--), (%% = 9.765625e-4) or (%% = 9.765625E-4) or %%) 1024.0 Result: true ... Which was correct, but was expected to be wrong due to a known bug in Maxima or ECL. 42/42 tests passed (not counting 3 expected errors) The following 2 problems passed but were expected to fail:
Re: NEW: security/pivy
ping? On Mon, May 25, 2020 at 08:01:58PM +1000, Jonathan Matthew wrote: > Hi, > > Here's a new port, security/pivy, a set of tools for using PIV tokens (like > Yubikeys) as an SSH agent, for encrypting data at rest, and more. > > pkg/DESCR: > Pivy is an implementation of a simple PIV client with minimal dependencies. > It contains a pivy-tool binary which can conduct basic operations using > PIV cards, and the pivy-agent, which implements the SSH agent protocol as > a drop-in replacement for the OpenSSH ssh-agent command (except that the > keys it contains are always on a PIV card). > > "PIV cards" notably includes Yubico Yubikey devices such as the NEO and > Yubikey4, which can store up to 24 keys by using the "retired key" slots > (which this agent supports). > > > I've built and used this on amd64 and armv7, and built it on sparc64. > > ok to import?
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2020/06/02 18:39:53 Modified files: lang/ocaml-camlp4: Makefile Log message: Unbreak PKGSPEC I shoudn't have introduced EPOCH in the revert to camlp4-4.08+1, it was not needed (the update to camlp4-4.10+1 didn't build) and it lead to this PKGSPEC issue that I overlooked. This fixes net/mldonkey, the last consumer of camlp4. Reported by naddy@
Re: purritobin-0.1.2 - new package + dependencies
On 6/2/20 8:50 AM, Stuart Henderson wrote: > On 2020/06/01 22:13, Brian Callahan wrote: >> Hi Aisha -- >> >> ‐‐‐ Original Message ‐‐‐ >> On Sunday, May 31, 2020 10:03 PM, Aisha Tammy wrote: >> >>> Hi, >>> >>> I've attached the port again, with a few more fixes. >>> >>> Would love to see this added. >>> >>> A few words about this port: >>> >>> It is a minimalistic pastebin client which allows you to also >>> >>> paste encrypted texts and has a simple javascript decryptor frontend. >>> >>> It is asynchronous and allows you to limit the paste size and a >>> >>> location where the pastes are stored. >>> >>> It uses unveil and pledge to make sure that only the necessary >>> >>> folders and permissions are used. >>> >>> Really hope this can be added and would love to get any advice about >>> >>> how to improve this port :) >>> >>> Aisha >> >> Thanks for the ports. I've attached improved versions of the ports >> that address what I'll talk about in this email. I'll take each >> separately. >> >> usockets: >> * I see that it compiles with -std=c11, so we need to have a >> COMPILER=base-clang ports-gcc line. >> * The Makefile has some -O3 lines, so those go. It also has some -flto >> lines. I don't believe all our archs can support -flto at the moment >> so I removed them too. >> * I am not sure why you create and install a shared version of this >> library. It seems like upstream intends for this to be statically >> linked into executables. Indeed, you don't even use the shared >> version of the library in PurritoBin, so I think it can go. >> * Your patch to the Makefile causes everything to be recompiled at >> fake time. >> * Not related to your port, but too bad that we are stuck using libuv >> (it can use kqueue but it uses extensions from FreeBSD that we don't >> have). >> >> uwebsockets: >> * Upstream claims this is a web server so I moved the category to www. >> Devel is quite full. Otherwise this port is quite straightforward. >> >> purritobin: >> * Since you're using the static version of usocket, we can simplify >> your depends lists. >> >> ~Brian >> > > > > > purritobin > - Makefile: > - add "uses pledge()" above wantlib as done in other ports will do thanks! > - pkg/DESCR: > - trailing blank line > - s/writted/written will fix thanks! > > All these static libraries mean that things won't get updated > automatically when a library is updated. Say you install purritobin > and there is a later security fix to usockets; purritobin won't be > updated unless you manually force it (e.g. by bumping REVISION). > The normal way of handling this with almost everything else in ports > is to use shared libraries. > I totally agree but upstream has mandated that this library is to be used static only and with -flto -O3 (which Brian has removed stating unsupported archs, thanks brian!). Upstream have also rejected my patch to add shared libraries :( and is adamant on using both the above flags (which was a separate issue that was raised, to remove the flags and make them optional depending on distribution) Does ports not handle such an automated revision bump for static libraries that get updated? (am just asking, I don't know the intricacies and details of shared/static library things) I am not sure how to resolve this conflict... an aside: why was -O3 removed, upstream has it present and wants it to be there? Aisha
Re: [new] databases/pgtap (and databases/p5-TAP-Parser-SourceHandler-pgTAP dep)
On Sat, May 23, 2020 at 10:46:00AM +0200, Landry Breuil wrote:
> Hi,
>
> here are two new ports, one for pgtap (https://pgtap.org/) and one for
> TAP::Parser::SourceHandler::pgTAP which provides the pg_prove script,
> used to run the regress tests for the upcoming 3.0.0 version of
> geo/pgrouting.
>
> pgtap is a postgresql extension to run regress tests using the TAP framework.
>
> thanks to the nice testing bits from postgresql.port.mk, i can easily
> run the pgtap tests themselves, and only some of them fail due to
> user/ownership issues that i think cant be worked around on OpenBSD,
> since we run build bits with fixed users (be it with PORTS_PRIVSEP or
> not):
>
> # Failed test 1: "db_owner_is(db, user, desc) should pass"
> # have: false
> # want: true
> # Failed test 3: "db_owner_is(db, user, desc) should have the proper
> diagnostics"
> # have: have: landry
> # want: postgres
> # want:
> # Failed test 4: "db_owner_is(db, user) should pass"
> # have: false
> # want: true
> # Failed test 6: "db_owner_is(db, user) should have the proper diagnostics"
> # have: have: landry
> # want: postgres
> # want:
> # Failed test 12: "db_owner_is(db, non-user) should have the proper
> diagnostics"
> # have: have: landry
> # want: __not__postgres
> # want: have: postgres
> # want: __not__postgres
> # Looks like you failed 5 tests of 411
> Failed 5/411 subtests
>
> looking for feedback from the pgsql wizards (or perl wizards even!) and oks to
> import.
>
> Landry
Looking over pgtap. I am seeing some strange (to me) issues.
It uses gmake and it's a perl port.
It comes with the Perl Makefile already built. Never seen that yet.
It also wants to pull in files from itself that are already installed
outside of the ports tree in order to run tests. Otherwise the tests
stop at:
ERROR: could not open extension control file
"/usr/local/share/postgresql/extension/pgtap.control": No such file or
directory
cp pgtap.control to /usr/local/share/postgresql/extension/pgtap.control
moved things along a little further, so it is looking there.
The above errors Landry had (and I also had) only occur if pgtap is
installed first. The ports documentation suggests an easy fix for that
by setting PGUSER=postgres this way: gmake installcheck PGUSER=postgres
I tried a variety of configure and modules, but that did not work,
erroring out almost right away. (cpan, modbuild, perl).
Looking upstream, this is how they have the Makefile in package and on
git.
Makefile from submitted port:
# $OpenBSD$
V = 1.1.0
COMMENT = unit testing for PostgreSQL
DISTNAME = pgtap-${V}
CATEGORIES =databases
EXTRACT_SUFX = .zip
HOMEPAGE = https://pgtap.org/
# PostgreSQL
PERMIT_PACKAGE= Yes
MASTER_SITES = https://api.pgxn.org/dist/pgtap/${V}/
MODULES = databases/postgresql
SUBST_VARS += V
USE_GMAKE = Yes
BUILD_DEPENDS = databases/postgresql
RUN_DEPENDS = databases/p5-TAP-Parser-SourceHandler-pgTAP
TEST_DEPENDS = ${BUILD_PKGPATH}
TEST_ENV+=ALLOW_MISSING_EXTENSIONS=1
MODPOSTGRESQL_TEST_CMD = ${LOCALBASE}/bin/psql -c 'CREATE EXTENSION pgtap;' && \
${MAKE_PROGRAM} ${ALL_TEST_FLAGS} -f ${MAKE_FILE} ${TEST_TARGET}
.include
Thanks
--
Chris Bennett
[new] sysutils/web2ldap and co
Hello, Here are three new ports, two deps, and the one piece de resistance, web2ldap. sysutils/web2ldap - web-based LDAP client devel/py-xlwt - dep for exporting LDAP query results as XLS files devel/py-ldap0 - web2ldap's interface to the OpenLDAP libraries The author of web2ldap and py-ldap0 has been very responsive to some questions I had a few months ago and accepted a change to make it easier to manage on the BSDs as a whole. More information here: https://web2ldap.de/ Project upstream here: https://gitlab.com/ae-dir/web2ldap I've been using this in my own tree for several months now with no issues. That being said, I hope I didn't get complacent in the submission. Completely understand if this is too niche to warrant being included in the tree. If not so terribly niche, feedback? Thanks, Lucas web2ldap.tgz Description: Binary data
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/06/02 15:55:14 Modified files: x11/i3-mousedrag: Makefile Log message: s/DEBUG_PACKAGS/DEBUG_PACKAGES/
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/06/02 14:09:55 Modified files: editors/vim: Makefile distinfo editors/vim/patches: patch-runtime_filetype_vim patch-runtime_syntax_make_vim patch-src_configure_ac editors/vim/pkg: PLIST-lang PLIST-main Log message: update to vim-8.2.885
Re: update games/godot to 3.2.1
Omar Polo writes: > Thomas Frohwein writes: > >> Thanks for this diff and the interest in the port. > > I don't know why but I've completely overlooked the MAINTAINER variable > in the makefile, and assumed that the port was without one. I should > have cc'd you in the first place, I'm sorry. > >> On Fri, May 29, 2020 at 03:15:11PM +0200, Omar Polo wrote: >> [...] >>> On my machine (amdgpu) it leaves a core file around but otherwise is >>> working; on my friend machine (inteldrm) it doesn't core dumps. We >> >> Can you provide some details about the core dump? Does Godot crash on >> amdgpu? Can you share a backtrace with gdb(egdb) from ports? I don't >> understand if this is just like the already known bugs with amdgpu at >> this point or something new. > > The amdgpu vs inteldrm was a red herring, the cause is the window > manager. If I close the game (or the editor window) either by > left-clicking its icon in tint2 or with the cwm keybinding, Godot logs: > > X connection to :0 broken (explicit kill or server shutdown). > Pure virtual function called! > > That's why I got that dump every time. I still haven't asked my friend, > but I suspect he quits either by or Scene -> quit. > > The (not so useful I fear) stacktrace is the following: > > [...] > > I'm rebuilding Godot with DEBUG_PACKAGES set to make the stacktrace more > useful. > > (note that DEBUG_PACKAGES is not included in the updated diff) It took me so long to write that email that in the meantime I've finished compiling Godot. Here's the stacktrace with debug symbols: ; egdb `which godot` godot.core [...] Reading symbols from /usr/local/bin/godot...Reading symbols from /usr/local/bin/.debug/godot.dbg...done. done. [New process 169208] [New process 229753] [New process 597609] [New process 618785] [New process 403724] [New process 234137] [New process 238415] [New process 576300] Core was generated by `godot'. Program terminated with signal SIGABRT, Aborted. #0 thrkill () at -:3 3 -: No such file or directory. [Current thread is 1 (process 169208)] (gdb) bt #0 thrkill () at -:3 #1 0x06c349be7fce in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51 #2 0x06c29464911c in abort_message (format=) at /usr/src/lib/libcxxabi/src/abort_message.cpp:77 #3 0x06c294649352 in __cxa_pure_virtual () at /usr/src/lib/libcxxabi/src/cxa_virtual.cpp:17 #4 0x06c0727b6a06 in AudioDriverDummy::thread_func ( p_udata=0x6c072d1caa8 ) at servers/audio/audio_driver_dummy.cpp:68 #5 0x06c070a277bb in ThreadPosix::thread_callback (userdata=0x6c2eee0aa50) at drivers/unix/thread_posix.cpp:74 #6 0x06c276d4e361 in _rthread_start (v=) at /usr/src/lib/librthread/rthread.c:96 #7 0x06c349bcae48 in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:77 #8 0x in ?? () (gdb) ...so the culprit is the AudioDriverDummy and even my deduction about the window manager was wrong. (the friend that's helping me testing the update is using the additional patch that brings back libao so he doesn't even reach that code path) I'll take a look at the audio_driver_dummy code in the following days.
Re: update games/godot to 3.2.1
Thomas Frohwein writes:
> Thanks for this diff and the interest in the port.
I don't know why but I've completely overlooked the MAINTAINER variable
in the makefile, and assumed that the port was without one. I should
have cc'd you in the first place, I'm sorry.
> On Fri, May 29, 2020 at 03:15:11PM +0200, Omar Polo wrote:
> [...]
>> On my machine (amdgpu) it leaves a core file around but otherwise is
>> working; on my friend machine (inteldrm) it doesn't core dumps. We
>
> Can you provide some details about the core dump? Does Godot crash on
> amdgpu? Can you share a backtrace with gdb(egdb) from ports? I don't
> understand if this is just like the already known bugs with amdgpu at
> this point or something new.
The amdgpu vs inteldrm was a red herring, the cause is the window
manager. If I close the game (or the editor window) either by
left-clicking its icon in tint2 or with the cwm keybinding, Godot logs:
X connection to :0 broken (explicit kill or server shutdown).
Pure virtual function called!
That's why I got that dump every time. I still haven't asked my friend,
but I suspect he quits either by or Scene -> quit.
The (not so useful I fear) stacktrace is the following:
; egdb `which godot` godot.core
[...]
Reading symbols from /usr/local/bin/godot...(no debugging symbols found)...done.
[New process 125523]
[New process 452006]
[New process 330887]
[New process 200582]
Core was generated by `godot'.
Program terminated with signal SIGABRT, Aborted.
#0 thrkill () at -:3
3 -: No such file or directory.
[Current thread is 1 (process 125523)]
(gdb) bt
#0 thrkill () at -:3
#1 0x114ce6265fce in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51
#2 0x114cdefcb11c in abort_message (format=)
at /usr/src/lib/libcxxabi/src/abort_message.cpp:77
#3 0x114cdefcb352 in __cxa_pure_virtual ()
at /usr/src/lib/libcxxabi/src/cxa_virtual.cpp:17
#4 0x114a9f9b7806 in ?? ()
#5 0x114a9dc286db in ?? ()
#6 0x114cff782361 in _rthread_start (v=)
at /usr/src/lib/librthread/rthread.c:96
#7 0x114ce6248e48 in __tfork_thread ()
at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:77
#8 0x in ?? ()
(gdb)
I'm rebuilding Godot with DEBUG_PACKAGES set to make the stacktrace more
useful.
(note that DEBUG_PACKAGES is not included in the updated diff)
By the way, do you know why the scons module explicitly disables ccache?
I was hoping to reduce the compilation time, but even with
USE_CCACHE=Yes and forcing NO_CCACHE=No scons still uses c++
>> working; on my friend machine (inteldrm) it doesn't core dumps. We
>> tested everything but the networking stuff AFAIK.
>
> As your patch includes disabling ssl in favor of mbedtls, I would think
> that some networking should be tested.
I'm still learning godot. I'm going to study how to test this properly
and report back.
>> I didn't have the time (yet) to fully debug this issue.
>>
>> Do I have to reset the REVISION back to 0 since this changes the port
>> version?
>
> Yes, REVISION is only used if changes happen in the package while the
> version doesn't change. It effectively adds pX to the package. See
> packages-specs(7) and bsd.port.mk(5). So just remove the REVISION line
> when updating the port's version.
done!
> [...]
>> - pulseaudio is still disabled: I have a WIP patch (not included) to
>> bring back audio support using libao. I plan to submit it soon
>> after this update
>
> I would be _very_ interested in this after the update. I've been trying
> to come up with an sndio backend myself, but haven't got it to work so
> far.
It's basically a revert of #2840[0] ("Revert libao audio driver", it's a
revert of a revert...) with adjustments to match the changes in the
AudioDriver.
After a quick search on the github issues, it seems that they added the
libao support explicitly to support sndio, but then later they removed
it without an explanation (or I didn't found it).
My plan was to handle this directly with upstream, but since mid April I
am no longer able to run Godot from master (i.e. after the merge of the
vulkan branch). I can still build it, but it doesn't start due to some
error in the vulkan loader I don't understand (and didn't have the time
to investigate further.)
> [...]
>> - in 3.1 they replaced openssl with mbedtls, hence the removal of ssl
>> from WANTLIB
>
> Must be a bundled mbedtls, as nothing is added to WANTLIB and/or
> LIB_DEPENDS. Might be better to find a way to use our ports version...
also done!
> [...]
>
> I haven't tested this yet. I am comparing it with the diff that I have
> been working on and will get back to you. Your diff is much longer than
> what I had (537 vs 199 lines). I'm gonna see what we need.
That's quite a difference. I just started by bumping the version and
then patching until it ran :)
If you find unnecessary hunks I'll be more than happy to drop them.
> Port updates are usually preferred as inline diff. Just make
Re: Firefox and MIME
On Tue, 02 Jun 2020 at 17:07:18 +0100, Laurence Tratt wrote:
> At some point recently our mozilla-firefox port stopped automatically opening
> downloaded files for me. pkg/README says:
>
> Due to unveil(2) limiting filesystem access, only the default MIME
> handler registered for a given type can be chosen when opening a
> downloaded file. For example, to use the mupdf package to read
> PDFs, it must be registered as the default with XDG:
>
> $ xdg-mime default mupdf.desktop application/pdf
>
> And, indeed, I have had that set for some while and it used to work fine.
> However, when I click on a PDF link in Firefox, it now brings up the
> (not-very-useful because of unveil!) "launch application" window.
>
> I'm sure I'm missing out on something obvious, but I'm not sure what it might
> be (and I know someone else who's equally baffled). In case it's relevant,
> I'm using XFCE (so DBUS is running) on -current as of a couple of days ago,
> with the firefox-76.0p0 package on amd64. If anyone has any pointers, I know
> at least two of us who will welcome them!
Firefox tries to execute xdg-open to parse the MIME stuff and run
the appropriate handler for application/pdf.
https://github.com/mozilla/gecko-dev/blob/c686b5d5614da653c20c689cea96a80ae598a1a1/toolkit/system/gnome/nsGIOService.cpp#L504-L514
Up until Glib 2.64.2, this was done by executing gio-launch-desktop
with xdg-open as an argument. This worked out for us because
xdg-open is a shell script and gio-launch-desktop was a binary, so
we could just unveil /usr/local/bin/gio-launch-desktop in Firefox's
unveil.main.
This changed as of updating our Glib port to 2.64.2 a few weeks ago,
and now Glib no longer ships with gio-launch-desktop, trying to run
xdg-open via /bin/sh directly:
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1362/diffs
I'm not sure how best to handle this going forward, but unveiling
/bin/sh is not a good idea.
Perhaps we include a small compiled utility with Firefox that just
hard-codes execve("/usr/local/bin/xdg-open", ...) and then unveil
that binary instead of gio-launch-desktop? Firefox would still need
modifying to exec that utility directly instead of using Glib's
g_app_info_create_from_commandline.
FWIW, the old .mailcap style handling still works, where you list
each binary specifically in ~/.mailcap and add it to your own
unveil.main.
Re: [Update] textproc/p5-LaTeX-Driver : Update to 1.0.0
On Sun, May 24, 2020 at 03:25:56AM +, wen heping wrote: >No other ports depends on textproc/p5-LaTeX-Driver. I originally ported this in. An upcoming port does depend on this. Thanks for the update. -- Chris Bennett
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: feine...@cvs.openbsd.org2020/06/02 10:33:09 Modified files: sysutils/udfclient: Makefile distinfo Log message: Update to UDFclient 0.8.11 >From Josh Grosse (MAINTAINER)
Re: Firefox and MIME
On Tue, Jun 02, 2020 at 05:07:18PM +0100, Laurence Tratt wrote: > At some point recently our mozilla-firefox port stopped automatically opening > downloaded files for me. pkg/README says: > > Due to unveil(2) limiting filesystem access, only the default MIME > handler registered for a given type can be chosen when opening a > downloaded file. For example, to use the mupdf package to read > PDFs, it must be registered as the default with XDG: > > $ xdg-mime default mupdf.desktop application/pdf > > And, indeed, I have had that set for some while and it used to work fine. > However, when I click on a PDF link in Firefox, it now brings up the > (not-very-useful because of unveil!) "launch application" window. > > I'm sure I'm missing out on something obvious, but I'm not sure what it might > be (and I know someone else who's equally baffled). In case it's relevant, > I'm using XFCE (so DBUS is running) on -current as of a couple of days ago, > with the firefox-76.0p0 package on amd64. If anyone has any pointers, I know > at least two of us who will welcome them! I have some computers/profiles where downloading files/pdfs works, some where it doesnt, some where downloading files with a name end up with a wrong name under /tmp/mozilla_landry0/foo.part instead of ~/Downloads/rightname.rightext and i personally have no time/interest to debug this, which is code im *not* responsible for - and i still dont understand all its intricacies/implementation details. Never tried the xdg-mime knob either. So all that to say i think you should talk to jcs@ :) Landry
Re: [update] mail/exim -> 4.94
On 6/2/20 2:14 PM, Stuart Henderson wrote:
On 2020/06/02 14:08, Renaud Allard wrote:
On 6/2/20 2:05 PM, Stuart Henderson wrote:
On 2020/06/02 09:02, Renaud Allard wrote:
Hello,
Here is a short diff to update exim to 4.94
The patch is still needed isn't it?
The patch was conflicting with some changes in the source. Instead of trying
to modify the patch, I removed it. I didn't have any problems without the
patch. I think it might have been put there to cope with very old versions
of gcc and it's probably not necessary anymore. It's probably better to keep
our changes to the minimum.
Please don't just remove a patch because there's a conflict, there is a
reason why it was added that is clear from cvs history. OpenBSD still
uses very old versions of GCC.
Indeed, it seems those 2 flags are not yet in gcc 3.3. Let's go with
your modification instead.
We could do it like this instead though: (also pass in CC correctly,
and regen patches on Local/Makefile).
Index: Makefile
===
RCS file: /cvs/ports/mail/exim/Makefile,v
retrieving revision 1.130
diff -u -p -r1.130 Makefile
--- Makefile9 Jan 2020 20:43:15 - 1.130
+++ Makefile2 Jun 2020 12:13:11 -
@@ -3,7 +3,7 @@
COMMENT-main =flexible mail transfer agent
COMMENT-eximon = X11 monitor tool for Exim MTA
-VERSION = 4.93.0.4
+VERSION = 4.94
DISTNAME =exim-${VERSION}
PKGNAME-main =exim-${VERSION}
FULLPKGNAME-eximon = exim-eximon-${VERSION}
@@ -35,7 +35,7 @@ LIB_DEPENDS-main =converters/libiconv \
RUN_DEPENDS-eximon = ${PKGPATH},-main
LIB_DEPENDS-eximon = devel/pcre
-MAKE_FLAGS += FULLECHO=
+MAKE_FLAGS += FULLECHO= CC="${CC}" CFLAGS="${CFLAGS}"
PSEUDO_FLAVORS = no_eximon
FLAVORS = mysql postgresql sqlite3 ldap sasl
Index: distinfo
===
RCS file: /cvs/ports/mail/exim/distinfo,v
retrieving revision 1.40
diff -u -p -r1.40 distinfo
--- distinfo9 Jan 2020 20:43:15 - 1.40
+++ distinfo2 Jun 2020 12:13:11 -
@@ -1,2 +1,2 @@
-SHA256 (exim-4.93.0.4.tar.gz) = qHtu9QY5JoD6R+sSGbbDxbEwy5o8bw4MTsht2jD6dkM=
-SIZE (exim-4.93.0.4.tar.gz) = 2480960
+SHA256 (exim-4.94.tar.gz) = X+Rdm8+mfZR9cHr8MWzTbFMUcPaLJAk0Ia26Sq+BC9k=
+SIZE (exim-4.94.tar.gz) = 2515734
Index: patches/patch-Local_Makefile
===
RCS file: /cvs/ports/mail/exim/patches/patch-Local_Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 patch-Local_Makefile
--- patches/patch-Local_Makefile10 Dec 2019 23:21:37 - 1.3
+++ patches/patch-Local_Makefile2 Jun 2020 12:13:11 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-Local_Makefile,v 1.3 201
Index: Local/Makefile
--- Local/Makefile.orig
+++ Local/Makefile
-@@ -100,7 +100,7 @@
+@@ -99,7 +99,7 @@
# /usr/local/sbin. The installation script will try to create this directory,
# and any superior directories, if they do not exist.
@@ -12,7 +12,7 @@ Index: Local/Makefile
#--
-@@ -116,7 +116,7 @@ BIN_DIRECTORY=/usr/exim/bin
+@@ -115,7 +115,7 @@ BIN_DIRECTORY=/usr/exim/bin
# don't exist. It will also install a default runtime configuration if this
# file does not exist.
@@ -21,7 +21,7 @@ Index: Local/Makefile
# It is possible to specify a colon-separated list of files for CONFIGURE_FILE.
# In this case, Exim will use the first of them that exists when it is run.
-@@ -133,7 +133,7 @@ CONFIGURE_FILE=/usr/exim/configure
+@@ -132,7 +132,7 @@ CONFIGURE_FILE=/usr/exim/configure
# deliveries. (Local deliveries run as various non-root users, typically as
the
# owner of a local mailbox.) Specifying these values as root is not
supported.
@@ -30,7 +30,7 @@ Index: Local/Makefile
# If you specify EXIM_USER as a name, this is looked up at build time, and the
# uid number is built into the binary. However, you can specify that this
-@@ -211,11 +211,11 @@ SPOOL_DIRECTORY=/var/spool/exim
+@@ -210,11 +210,11 @@ SPOOL_DIRECTORY=/var/spool/exim
# If you are buliding with TLS, the library configuration must be done:
# Uncomment this if you are using OpenSSL
@@ -44,7 +44,7 @@ Index: Local/Makefile
# TLS_LIBS=-L/usr/local/openssl/lib -lssl -lcrypto
# Uncomment this if you are using GnuTLS
-@@ -338,7 +338,7 @@ TRANSPORT_SMTP=yes
+@@ -337,7 +337,7 @@ TRANSPORT_SMTP=yes
# This one is special-purpose, and commonly not required, so it is not
# included by default.
@@ -53,7 +53,7 @@ Index: Local/Makefile
#--
-@@ -347,9 +347,9 @@ TRANSPORT_SMTP=yes
+@@ -346,9 +346,9 @@ TRANSPORT_SMTP=yes
# MBX, is included only when requested. If you do not know what this is
about,
#
Re: update for ports-fvwm to 2.6.9
On Tue, 2 Jun 2020 08:59:33 -0600
Thomas Frohwein :
> ping
>
> On Tue, May 19, 2020 at 04:03:20PM -0600, Thomas Frohwein wrote:
> > On Fri, Apr 10, 2020 at 10:54:06AM +0200, Rafael Sadowski wrote:
> > [...]
> > > > - upstream distfiles for fvicons are gone and can't find
> > > > replacement. Therefore, MASTER_SITES0 set to
> > > > https://ftp.openbsd.org/pub/OpenBSD/distfiles/. Or rather
> > > > remove?
> > >
> > > I would remove the icons if there are gone upstream but this is my
> > > personal opinion.
> >
> > ping with updated diff that removes fvicons, which makes the port
> > much simpler.
> >
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/x11/fvwm2/Makefile,v
> > retrieving revision 1.67
> > diff -u -p -r1.67 Makefile
> > --- Makefile12 Jul 2019 20:51:11 - 1.67
> > +++ Makefile19 May 2020 21:59:10 -
> > @@ -1,21 +1,15 @@
> > # $OpenBSD: Makefile,v 1.67 2019/07/12 20:51:11 sthen Exp $
> >
> > -COMMENT-main= multiple virtual desktop window manager, with
> > icons -COMMENT-fvicons=multiple virtual desktop window manager icons
> > -COMMENT-fvwm2= multiple virtual desktop window manager,
> > without icons +COMMENT= multiple virtual desktop window
> > manager
> > -VERSION= 2.6.5
> > +VERSION= 2.6.9
> > DISTNAME= fvwm-${VERSION}
> > -PKGNAME-main= fvwm2+fvicons-${VERSION}
> > -FULLPKGNAME-fvicons=fvicons-${VERSION}
> > -PKGNAME-fvwm2= fvwm2-${VERSION}
> > -REVISION= 6
> > +PKGNAME= fvwm2-${VERSION}
> >
> > CATEGORIES= x11
> >
> > -DISTFILES= ${DISTNAME}${EXTRACT_SUFX}
> > fvwm_icons-20070101.tar.gz -
> > HOMEPAGE= http://www.fvwm.org/
> > +MAINTAINER=Thomas Frohwein
> >
> > # GPL/BSD-like (badly worded)
> > PERMIT_PACKAGE=Yes
> > @@ -25,15 +19,13 @@ WANTLIB += c cairo curses fontconfig fre
> > WANTLIB += gio-2.0 glib-2.0 gobject-2.0 iconv intl m png
> > WANTLIB += readline rsvg-2 z
> >
> > -MASTER_SITES= ftp://ftp.fvwm.org/pub/fvwm/version-2/
> > +MASTER_SITES=
> > https://github.com/fvwmorg/fvwm/releases/download/${VERSION}/
> > LIB_DEPENDS+= graphics/png \
> > x11/gnome/librsvg
> >
> > BUILD_DEPENDS= textproc/libxslt
> >
> > -MULTI_PACKAGES=-main -fvwm2 -fvicons
> > -
> > FLAVORS= debug
> > FLAVOR?=
> >
> > @@ -41,17 +33,13 @@ FLAVOR?=
> > CONFIGURE_ARGS+= --enable-debug-msgs
> > .endif
> >
> > -PKG_ARCH-fvicons= *
> > -LIB_DEPENDS-fvicons=
> > -WANTLIB-fvicons=
> > -FULLPKGPATH-fvicons= ${PKGPATH},-fvicons
> > -
> > SUBST_VARS=VERSION
> >
> > SEPARATE_BUILD= Yes
> > CONFIGURE_STYLE= gnu
> > CONFIGURE_ARGS += --disable-bidi \
> > --disable-gtk \
> > + --enable-mandoc \
> > --without-gnome \
> > --without-rplay-library \
> > --without-stroke-library
> > @@ -59,8 +47,6 @@ CONFIGURE_ENV += CPPFLAGS="${CPPFLAGS} -
> > LDFLAGS="${LDFLAGS} -L${LOCALBASE}/lib"
> >
> > post-install:
> > - ${INSTALL_DATA_DIR} ${PREFIX}/share/pixmaps/fvwm
> > - ${INSTALL_DATA} ${WRKDIR}/fvwm_icons-20070101/*.xpm
> > ${PREFIX}/share/pixmaps/fvwm/
> > - ${INSTALL_DATA} ${WRKSRC}/sample.fvwmrc/system.fvwm2rc
> > ${PREFIX}/share/fvwm
> > + ${INSTALL_DATA} ${WRKSRC}/default-config/config
> > ${PREFIX}/share/fvwm
> > .include
> > Index: distinfo
> > ===
> > RCS file: /cvs/ports/x11/fvwm2/distinfo,v
> > retrieving revision 1.14
> > diff -u -p -r1.14 distinfo
> > --- distinfo18 Jan 2015 03:15:53 - 1.14
> > +++ distinfo19 May 2020 21:59:10 -
> > @@ -1,4 +1,2 @@
> > -SHA256 (fvwm-2.6.5.tar.gz) =
> > 8B+dqAdoUvjbEU+Q8rB1jCHSZeKVj84EKJ5Be866EtE= -SHA256
> > (fvwm_icons-20070101.tar.gz) =
> > oL5qSSCzjVj/7+QwdYvB2QEtfHSrZWDL1udYpb3q6yw= -SIZE
> > (fvwm-2.6.5.tar.gz) = 3449177 -SIZE (fvwm_icons-20070101.tar.gz) =
> > 363286 +SHA256 (fvwm-2.6.9.tar.gz) =
> > G8ZM88zQBzAIdYFoMnqCZbgFne+bI5tFHWufqyzDka4= +SIZE
> > (fvwm-2.6.9.tar.gz) = 3942859 Index: patches/patch-bin_Makefile_in
> > ===
> > RCS file: /cvs/ports/x11/fvwm2/patches/patch-bin_Makefile_in,v
> > retrieving revision 1.1 diff -u -p -r1.1 patch-bin_Makefile_in
> > --- patches/patch-bin_Makefile_in 26 Apr 2011 18:50:46
> > - 1.1 +++ patches/patch-bin_Makefile_in 19 May
> > 2020 21:59:10 - @@ -1,11 +1,12 @@
> > $OpenBSD: patch-bin_Makefile_in,v 1.1 2011/04/26 18:50:46 shadchin
> > Exp $ bin/Makefile.in.orig Fri Mar 4 08:47:50 2011
> > -+++ bin/Makefile.inFri Mar 4 08:48:13 2011
> > -@@ -710,14 +710,13 @@ info: info-am
> > +Index: bin/Makefile.in
> > +--- bin/Makefile.in.orig
> > bin/Makefile.in
> > +@@ -835,14 +835,13 @@ info: info-am
> >
> > info-am:
> >
> > --install-data-am: install-data-local install-man
> >
Re: [update] mail/exim -> 4.94
On 6/2/20 2:05 PM, Stuart Henderson wrote: On 2020/06/02 09:02, Renaud Allard wrote: Hello, Here is a short diff to update exim to 4.94 The patch is still needed isn't it? The patch was conflicting with some changes in the source. Instead of trying to modify the patch, I removed it. I didn't have any problems without the patch. I think it might have been put there to cope with very old versions of gcc and it's probably not necessary anymore. It's probably better to keep our changes to the minimum. smime.p7s Description: S/MIME Cryptographic Signature
Firefox and MIME
At some point recently our mozilla-firefox port stopped automatically opening downloaded files for me. pkg/README says: Due to unveil(2) limiting filesystem access, only the default MIME handler registered for a given type can be chosen when opening a downloaded file. For example, to use the mupdf package to read PDFs, it must be registered as the default with XDG: $ xdg-mime default mupdf.desktop application/pdf And, indeed, I have had that set for some while and it used to work fine. However, when I click on a PDF link in Firefox, it now brings up the (not-very-useful because of unveil!) "launch application" window. I'm sure I'm missing out on something obvious, but I'm not sure what it might be (and I know someone else who's equally baffled). In case it's relevant, I'm using XFCE (so DBUS is running) on -current as of a couple of days ago, with the firefox-76.0p0 package on amd64. If anyone has any pointers, I know at least two of us who will welcome them! Laurie
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/02 10:04:26 Modified files: x11/gnome/orca : Makefile distinfo x11/gnome/orca/pkg: PLIST Log message: Update to orca-3.36.3.
lang/guile2 info doc
Hello,
I would like lang/guile2 did not delete the info pages at installation. It
is very convenient (or rather a must) for coding in one tmux pane and
browse the info library reference in the other pane.
It seems there is no maintainer of the package now. Could somebody just
comment out the last line of the Makefile (i.e. "rm -rf ${PREFIX}/info")
and commit?
Perhaps not many users need guile installed, but for those who do, the
documentation is crucial.
Thanks!
Jan
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/06/02 09:32:33 Modified files: www/firefox-esr: Tag: OPENBSD_6_7 Makefile distinfo Log message: MFC: Update to firefox-esr 68.9.0. See https://www.mozilla.org/en-US/firefox/68.9.0/releasenotes/ Fixes https://www.mozilla.org/en-US/security/advisories/mfsa2020-21/
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2020/06/02 09:29:59 Modified files: graphics/libpano13: Makefile Log message: are you kidding me ? remove useless lines from Makefile
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/06/02 09:29:32 Modified files: www/firefox-esr: Makefile distinfo www/firefox-esr-i18n: Makefile.inc distinfo Log message: Update to firefox-esr 68.9.0. See https://www.mozilla.org/en-US/firefox/68.9.0/releasenotes/ Fixes https://www.mozilla.org/en-US/security/advisories/mfsa2020-21/
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/06/02 09:27:27 Modified files: www/mozilla-firefox: Makefile distinfo www/mozilla-firefox/files: mozilla-firefox.1 pledge.content pledge.gpu pledge.main unveil.content unveil.gpu unveil.main www/mozilla-firefox/patches: patch-dom_ipc_ContentChild_cpp www/firefox-i18n: Makefile.inc distinfo Removed files: www/mozilla-firefox/patches: patch-dom_crypto_WebCryptoTask_cpp patch-netwerk_srtp_src_crypto_cipher_aes_gcm_nss_c patch-security_manager_ssl_OSKeyStore_cpp patch-third_party_prio_moz_build Log message: Update to firefox 77.0. See https://www.mozilla.org/en-US/firefox/77.0/releasenotes/ Fixes https://www.mozilla.org/en-US/security/advisories/mfsa2020-20/ * remove patches from https://hg.mozilla.org/mozilla-central/rev/463069687b3d * add $OpenBSD$ CVS IDs to pledge/unveil config files, from kn@ - link to pkg-readme in mozilla-firefox(1) - this manpage shoplifted somewhere on the interweb could definitely need a proper rewrite.. tested by naddy@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/06/02 09:23:35 Modified files: mail/mozilla-thunderbird: Makefile Log message: bump REVISION for mozilla.port.mk changes
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/06/02 09:22:18 Modified files: www/mozilla: mozilla.port.mk Log message: Bump requirement to nss 3.53. Technically, requirement is at 3.52 (#1629594) and later on 3.52.1 (#1637369) but this cant harm. while here, remove --with-system-bz2 from CONFIGURE_ARGS, the dependency on bzip2 was removed in #1418425 for firefox 62..
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/06/02 09:18:09 Modified files: security/nss : Makefile distinfo security/nss/patches: patch-nss_Makefile Log message: Update to nss 3.53, requirement for gecko 78. See https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.53_release_notes
Re: NEW: devel/msbuild - build system for .NET
On Tue, Jun 02, 2020 at 08:58:26AM -0600, Thomas Frohwein wrote: > ping Attaching tarball without NO_TEST based on aja@'s comment, in case someone wants to try out the test target.
Re: update for ports-fvwm to 2.6.9
ping
On Tue, May 19, 2020 at 04:03:20PM -0600, Thomas Frohwein wrote:
> On Fri, Apr 10, 2020 at 10:54:06AM +0200, Rafael Sadowski wrote:
> [...]
> > > - upstream distfiles for fvicons are gone and can't find replacement.
> > > Therefore, MASTER_SITES0 set to
> > > https://ftp.openbsd.org/pub/OpenBSD/distfiles/. Or rather remove?
> >
> > I would remove the icons if there are gone upstream but this is my
> > personal opinion.
>
> ping with updated diff that removes fvicons, which makes the port much
> simpler.
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/x11/fvwm2/Makefile,v
> retrieving revision 1.67
> diff -u -p -r1.67 Makefile
> --- Makefile 12 Jul 2019 20:51:11 - 1.67
> +++ Makefile 19 May 2020 21:59:10 -
> @@ -1,21 +1,15 @@
> # $OpenBSD: Makefile,v 1.67 2019/07/12 20:51:11 sthen Exp $
>
> -COMMENT-main=multiple virtual desktop window manager, with icons
> -COMMENT-fvicons=multiple virtual desktop window manager icons
> -COMMENT-fvwm2= multiple virtual desktop window manager, without icons
> +COMMENT= multiple virtual desktop window manager
>
> -VERSION= 2.6.5
> +VERSION= 2.6.9
> DISTNAME=fvwm-${VERSION}
> -PKGNAME-main=fvwm2+fvicons-${VERSION}
> -FULLPKGNAME-fvicons=fvicons-${VERSION}
> -PKGNAME-fvwm2= fvwm2-${VERSION}
> -REVISION=6
> +PKGNAME= fvwm2-${VERSION}
>
> CATEGORIES= x11
>
> -DISTFILES= ${DISTNAME}${EXTRACT_SUFX} fvwm_icons-20070101.tar.gz
> -
> HOMEPAGE=http://www.fvwm.org/
> +MAINTAINER= Thomas Frohwein
>
> # GPL/BSD-like (badly worded)
> PERMIT_PACKAGE= Yes
> @@ -25,15 +19,13 @@ WANTLIB += c cairo curses fontconfig fre
> WANTLIB += gio-2.0 glib-2.0 gobject-2.0 iconv intl m png
> WANTLIB += readline rsvg-2 z
>
> -MASTER_SITES=ftp://ftp.fvwm.org/pub/fvwm/version-2/
> +MASTER_SITES=
> https://github.com/fvwmorg/fvwm/releases/download/${VERSION}/
>
> LIB_DEPENDS+=graphics/png \
> x11/gnome/librsvg
>
> BUILD_DEPENDS= textproc/libxslt
>
> -MULTI_PACKAGES= -main -fvwm2 -fvicons
> -
> FLAVORS= debug
> FLAVOR?=
>
> @@ -41,17 +33,13 @@ FLAVOR?=
> CONFIGURE_ARGS+= --enable-debug-msgs
> .endif
>
> -PKG_ARCH-fvicons=*
> -LIB_DEPENDS-fvicons=
> -WANTLIB-fvicons=
> -FULLPKGPATH-fvicons= ${PKGPATH},-fvicons
> -
> SUBST_VARS= VERSION
>
> SEPARATE_BUILD= Yes
> CONFIGURE_STYLE= gnu
> CONFIGURE_ARGS +=--disable-bidi \
> --disable-gtk \
> + --enable-mandoc \
> --without-gnome \
> --without-rplay-library \
> --without-stroke-library
> @@ -59,8 +47,6 @@ CONFIGURE_ENV +=CPPFLAGS="${CPPFLAGS} -
> LDFLAGS="${LDFLAGS} -L${LOCALBASE}/lib"
>
> post-install:
> - ${INSTALL_DATA_DIR} ${PREFIX}/share/pixmaps/fvwm
> - ${INSTALL_DATA} ${WRKDIR}/fvwm_icons-20070101/*.xpm
> ${PREFIX}/share/pixmaps/fvwm/
> - ${INSTALL_DATA} ${WRKSRC}/sample.fvwmrc/system.fvwm2rc
> ${PREFIX}/share/fvwm
> + ${INSTALL_DATA} ${WRKSRC}/default-config/config ${PREFIX}/share/fvwm
>
> .include
> Index: distinfo
> ===
> RCS file: /cvs/ports/x11/fvwm2/distinfo,v
> retrieving revision 1.14
> diff -u -p -r1.14 distinfo
> --- distinfo 18 Jan 2015 03:15:53 - 1.14
> +++ distinfo 19 May 2020 21:59:10 -
> @@ -1,4 +1,2 @@
> -SHA256 (fvwm-2.6.5.tar.gz) = 8B+dqAdoUvjbEU+Q8rB1jCHSZeKVj84EKJ5Be866EtE=
> -SHA256 (fvwm_icons-20070101.tar.gz) =
> oL5qSSCzjVj/7+QwdYvB2QEtfHSrZWDL1udYpb3q6yw=
> -SIZE (fvwm-2.6.5.tar.gz) = 3449177
> -SIZE (fvwm_icons-20070101.tar.gz) = 363286
> +SHA256 (fvwm-2.6.9.tar.gz) = G8ZM88zQBzAIdYFoMnqCZbgFne+bI5tFHWufqyzDka4=
> +SIZE (fvwm-2.6.9.tar.gz) = 3942859
> Index: patches/patch-bin_Makefile_in
> ===
> RCS file: /cvs/ports/x11/fvwm2/patches/patch-bin_Makefile_in,v
> retrieving revision 1.1
> diff -u -p -r1.1 patch-bin_Makefile_in
> --- patches/patch-bin_Makefile_in 26 Apr 2011 18:50:46 - 1.1
> +++ patches/patch-bin_Makefile_in 19 May 2020 21:59:10 -
> @@ -1,11 +1,12 @@
> $OpenBSD: patch-bin_Makefile_in,v 1.1 2011/04/26 18:50:46 shadchin Exp $
> bin/Makefile.in.orig Fri Mar 4 08:47:50 2011
> -+++ bin/Makefile.in Fri Mar 4 08:48:13 2011
> -@@ -710,14 +710,13 @@ info: info-am
> +Index: bin/Makefile.in
> +--- bin/Makefile.in.orig
> bin/Makefile.in
> +@@ -835,14 +835,13 @@ info: info-am
>
> info-am:
>
> --install-data-am: install-data-local install-man
> +-install-data-am: install-configDATA install-data-local install-man
> +install-data-am: install-man
>
> install-dvi: install-dvi-am
> Index: patches/patch-config_h_in
> ===
> RCS file: patches/patch-config_h_in
> diff -N
Re: NEW: devel/msbuild - build system for .NET
ping
On Tue, May 19, 2020 at 03:27:51PM -0600, Thomas Frohwein wrote:
> Hi,
>
> This is a port of MSBuild, the build system for .NET. lang/mono ships with
> xbuild which was an initial replacement for MSBuild, however since the more
> official integration of mono into .NET, xbuild has been deprecated by mono for
> several years now. Of note, that happened without MSBuild actually shipping
> with mono.
>
> At this point there is a growing list of .NET projects that only build with
> MSBuild. That's the raison d'etre for this port.
>
> This port is heavily inspired by FreeBSD's port which helped me simplify
> things
> and find some solutions. It bootstraps itself with a bundled MSBuild assembly
> that is invoked with mono, and pulls in a gargantuan (1G after extraction)
> amount of NuGet dependencies via a bundled NuGet assembly. I have created a
> separate tar.xz of those dependencies, so that it builds without internet
> connection.
>
> Passes make port-lib-depends-check and portcheck. I have built a few projects
> like the latest (upstream) version of games/openra which refuses to work with
> xbuild successfully. There are still a lot of projects that look for
> non-existant components which are likely included with Microsoft's dotnet/
> corefx/coreclr distributions.
>
> Other things of note about the port:
>
> - This is not the very latest version upstream, but newer ones seem to require
> dotnet CLI. It's the same as in FreeBSD's tree though.
> - Versioning is confusing between mono's 0.06, and the MSBuild versioning. I
> chose 15.8pre0 based on what FreeBSD does ("15.8-preview")
> - The license is MIT. There are 137 NuGet packages in the build. These are a
> mix of MIT, Apache-2.0, and Microsoft .NET library license [1]
> - 'make test' doesn't work at this point, therefore is disabled (see comment
> in
> Makefile)
>
> Thanks to bcallah@ for hosting the NuGet dependencies.
>
> Comments, concerns, ok's are welcome.
>
> [1] https://dotnet.microsoft.com/en/dotnet_library_license.htm
Re: update games/godot to 3.2.1
Thanks for this diff and the interest in the port. On Fri, May 29, 2020 at 03:15:11PM +0200, Omar Polo wrote: [...] > On my machine (amdgpu) it leaves a core file around but otherwise is > working; on my friend machine (inteldrm) it doesn't core dumps. We Can you provide some details about the core dump? Does Godot crash on amdgpu? Can you share a backtrace with gdb(egdb) from ports? I don't understand if this is just like the already known bugs with amdgpu at this point or something new. > working; on my friend machine (inteldrm) it doesn't core dumps. We > tested everything but the networking stuff AFAIK. As your patch includes disabling ssl in favor of mbedtls, I would think that some networking should be tested. > I didn't have the time (yet) to fully debug this issue. > > Do I have to reset the REVISION back to 0 since this changes the port > version? Yes, REVISION is only used if changes happen in the package while the version doesn't change. It effectively adds pX to the package. See packages-specs(7) and bsd.port.mk(5). So just remove the REVISION line when updating the port's version. [...] > - pulseaudio is still disabled: I have a WIP patch (not included) to > bring back audio support using libao. I plan to submit it soon > after this update I would be _very_ interested in this after the update. I've been trying to come up with an sndio backend myself, but haven't got it to work so far. [...] > - in 3.1 they replaced openssl with mbedtls, hence the removal of ssl > from WANTLIB Must be a bundled mbedtls, as nothing is added to WANTLIB and/or LIB_DEPENDS. Might be better to find a way to use our ports version... [...] I haven't tested this yet. I am comparing it with the diff that I have been working on and will get back to you. Your diff is much longer than what I had (537 vs 199 lines). I'm gonna see what we need. Port updates are usually preferred as inline diff. Just make sure your mail client doesn't mangle whitespace.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: p...@cvs.openbsd.org2020/06/02 08:30:33 Modified files: databases/postgresql: Makefile distinfo databases/postgresql/pkg: PLIST-docs Log message: update to 12.3 ok jeremy@
Re: [new] databases/pgtap (and databases/p5-TAP-Parser-SourceHandler-pgTAP dep)
On Tue, Jun 02, 2020 at 09:17:49AM +0200, Landry Breuil wrote: > On Sat, May 23, 2020 at 10:46:00AM +0200, Landry Breuil wrote: > > Hi, > > > > here are two new ports, one for pgtap (https://pgtap.org/) and one for > > TAP::Parser::SourceHandler::pgTAP which provides the pg_prove script, > > used to run the regress tests for the upcoming 3.0.0 version of > > geo/pgrouting. > > > > pgtap is a postgresql extension to run regress tests using the TAP > > framework. > > > > thanks to the nice testing bits from postgresql.port.mk, i can easily > > run the pgtap tests themselves, and only some of them fail due to > > user/ownership issues that i think cant be worked around on OpenBSD, > > since we run build bits with fixed users (be it with PORTS_PRIVSEP or > > not): > > > > # Failed test 1: "db_owner_is(db, user, desc) should pass" > > # have: false > > # want: true > > # Failed test 3: "db_owner_is(db, user, desc) should have the proper > > diagnostics" > > # have: have: landry > > # want: postgres > > # want: > > # Failed test 4: "db_owner_is(db, user) should pass" > > # have: false > > # want: true > > # Failed test 6: "db_owner_is(db, user) should have the proper diagnostics" > > # have: have: landry > > # want: postgres > > # want: > > # Failed test 12: "db_owner_is(db, non-user) should have the proper > > diagnostics" > > # have: have: landry > > # want: __not__postgres > > # want: have: postgres > > # want: __not__postgres > > # Looks like you failed 5 tests of 411 > > Failed 5/411 subtests > > > > looking for feedback from the pgsql wizards (or perl wizards even!) and oks > > to > > import. > > Anyone ? Would like to move forward with pgrouting 3.0, and those two ports > will allow me fixing regress tests. And pgtap could be used by other pg* > ports.. > > Landry I'll have a look. Wizard in neither, but user of both. I also have a port I'm working on with testing problems. -- Chris Bennett
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2020/06/02 08:09:53 Modified files: graphics/digikam: Makefile Log message: Add missing dependency devel/kf5/kcalendarcore
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jtur...@cvs.openbsd.org 2020/06/02 08:09:16 Modified files: lang : Makefile Log message: +microscheme
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jtur...@cvs.openbsd.org 2020/06/02 08:07:40 Log message: Import ports/lang/microscheme. ok abieber@ Microscheme is a Scheme subset designed for Atmel microcontrollers, especially as found on Arduino boards. Status: Vendor Tag: jturner Release Tags: jturner_20200602 N ports/lang/microscheme/Makefile N ports/lang/microscheme/distinfo N ports/lang/microscheme/pkg/DESCR N ports/lang/microscheme/pkg/PLIST N ports/lang/microscheme/patches/patch-makefile No conflicts created by this import
Re: new: lang/microscheme
James Turner writes: > On Mon, Jun 01, 2020 at 04:37:01PM -0400, James Turner wrote: >> Attached is a new port for lang/microscheme. I plan on using this to >> run a scheme based firmware on my atreus keyboard [0]. oks? >> > > I have successfully used this port to install the menelaus firmware on > my atreus keyboard. Neat! I KS'd the Atreus2 - would be fun to use something like this on it! OK abieber@ > >> Information for inst:microscheme-0.9.4 >> >> Comment: >> scheme subset for atmel microcontrollers >> >> Description: >> Microscheme is a Scheme subset designed for Atmel microcontrollers, >> especially as found on Arduino boards. >> >> Maintainer: James Turner >> >> WWW: https://ryansuchocki.github.io/microscheme/ >> >> [0] https://git.sr.ht/~technomancy/menelaus -- PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE
Re: new: lang/microscheme
On Mon, Jun 01, 2020 at 04:37:01PM -0400, James Turner wrote: > Attached is a new port for lang/microscheme. I plan on using this to > run a scheme based firmware on my atreus keyboard [0]. oks? > I have successfully used this port to install the menelaus firmware on my atreus keyboard. > Information for inst:microscheme-0.9.4 > > Comment: > scheme subset for atmel microcontrollers > > Description: > Microscheme is a Scheme subset designed for Atmel microcontrollers, > especially as found on Arduino boards. > > Maintainer: James Turner > > WWW: https://ryansuchocki.github.io/microscheme/ > > [0] https://git.sr.ht/~technomancy/menelaus
Re: CVS: cvs.openbsd.org: ports
> On Jun 1, 2020, at 4:01 PM, Christopher Zimmermann wrote: > > On Mon, Jun 01, 2020 at 09:35:26PM +0200, Antoine Jacoutot wrote: >>> On Mon, Jun 01, 2020 at 12:04:50AM -0600, Christopher Zimmermann wrote: >>> CVSROOT:/cvs >>> Module name:ports >>> Changes by:chr...@cvs.openbsd.org2020/06/01 00:04:50 >>> >>> Modified files: >>>math/coq : Makefile distinfo >>>math/coq/pkg : PFRAG.dynlink-native PFRAG.native >>> PFRAG.no-native PLIST >>> >>> Log message: >>> Upgrade math/coq to 8.11.1 >>> >>> ok daniel@ >> >> This seems to have broken lang/compcert: >> >> ===> lang/compcert >> ===> Generating configure for compcert-3.7 >> ===> Configuring for compcert-3.7 >> Testing assembler support for CFI directives... yes >> Testing linker support for '-no-pie' / '-nopie' option... yes, '-no-pie' >> Testing Coq... version 8.11.1 -- UNSUPPORTED >> Error: CompCert requires one of the following Coq versions: 8.11.0, 8.10.2, >> 8.10.1, 8.10.0, 8.9.1, 8.9.0, 8.8.2, 8.8.1, 8.8.0 >> Testing OCaml... version 4.09.0 -- good! > > This was expected. I just forgot about compcert when I committed math/coq. > This was my fault. daniel@ ? OK to commit below patch as already done > upstream? > > Christopher > > > Here's the fix: > I fixed it a slightly different way. Let me know if any problems post the fix.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dan...@cvs.openbsd.org 2020/06/02 06:58:22 Modified files: lang/compcert : Makefile distinfo lang/compcert/patches: patch-Makefile Log message: Update to commit 08491de0 for coq 8.11.1 support.
UPDATE x11/herbstluftwm 0.7.2 -> 0.8.2
Hello ports@,
Find an update for herbstluftwm, jointly done with Florian (in CC).
We'll take maintainership of the port while at it.
Too many fixes and improvements to list. Find them in [0].
Portwise:
- Upstream changed build system to CMake. That allows us to get rid of
FAKE_FLAGS.
- Dist tarball includes compiled manpages. Use them instead of building
ourselves, saving a depend on asciidoc.
- We no longer install the HTML versions of manpages. We aren't sure if
this is the prefered way, given there are the manpages already, so let
us know if we should re-add them.
- Makefile aesthetics: reorder according to Makefile.template and align
values. That's a lot whitespace churn.
- Fixes for portcheck and make port-lib-depends-check. glib-2.0 and
intl are out of WANTLIB and glib-2.0 is not a dep.
- hlwm now ships tests! Sadly, they rely on pyewmh[1] and
pytest-xfvb[2]. Porting pyewmh was a piece of cake; didn't manage to
make pytest-xfvb run its own tests, as it seems it isn't running a new
Xvfb as a subprocess while executing internal pytest tests. Also I'm
not sure if importing 2 ports for being able to run tests is
desirable. So, for the time being, keep NO_TEST=Yes.
- We aren't sure if we should add x11/dmenu to RUN_DEPENDS. One of the
4 scripts it installs to /etc/xdg/herbstluftwm needs it, but that
script isn't referenced by the others, unlike the case x11/dzen2.
Advice is welcome in here, too.
- PLIST changes:
- HTML manuals are gone (as said, can be added back)
- share/examples/herbstluftwm/ -> share/doc/herbstluftwm/examples/,
which is what upstream ships as docs
- share/examples/herbstluftwm/xdg/herbstluftwm/ ->
share/examples/herbstluftwm/
- dmenu_run_hlwm was being installed to bin/; now resides in
share/examples/herbstluftwm/
- Bash completions in share/bash-completion/completions/herbstclient,
ZSH completions in share/zsh/site-functions/ and now support for
fish too
- mv share/{applications,xsessions}/herbstluftwm.desktop
We have been using it without problems in amd64 and i386.
Inlined is the cvs diff -w output. The "real" patch is attached.
-Lucas
[0]: https://raw.githubusercontent.com/herbstluftwm/herbstluftwm/master/NEWS
[1]: https://github.com/parkouss/pyewmh
[2]: https://github.com/The-Compiler/pytest-xvfb
Index: Makefile
===
RCS file: /home/cvs/ports/x11/herbstluftwm/Makefile,v
retrieving revision 1.15
diff -u -p -w -r1.15 Makefile
--- Makefile17 Oct 2019 20:23:03 - 1.15
+++ Makefile2 Jun 2020 12:38:35 -
@@ -1,39 +1,52 @@
# $OpenBSD: Makefile,v 1.15 2019/10/17 20:23:03 rsadowski Exp $
COMMENT = manual tiling window manager
-DISTNAME = herbstluftwm-0.7.2
+DISTNAME = herbstluftwm-0.8.2
CATEGORIES = x11
HOMEPAGE = https://herbstluftwm.org/
+MAINTAINER = Lucas , \
+ Florian Viehweger
+
# BSD
PERMIT_PACKAGE = Yes
-WANTLIB += X11 Xext Xinerama c glib-2.0 intl m pthread ${COMPILER_LIBCXX}
+WANTLIB += X11 Xext Xinerama Xrandr c m pthread ${COMPILER_LIBCXX}
MASTER_SITES = https://herbstluftwm.org/tarballs/
# c++11
COMPILER = base-clang ports-gcc
-LIB_DEPENDS += devel/glib2
+MODULES += devel/cmake
RUN_DEPENDS += devel/desktop-file-utils \
shells/bash \
x11/dzen2,-gadgets
-CPPFLAGS +=-I${LOCALBASE}/include
-USE_GMAKE =Yes
-MAKE_FLAGS = LDFLAGS= VERBOSE= COLOR=0 CC='${CC}' LDXX='${CXX}' CXX='${CXX}'
-
-BASEDIR = ${PREFIX}/share/examples/herbstluftwm
-FAKE_FLAGS = SYSCONFDIR="${BASEDIR}" \
- EXAMPLESDIR="${BASEDIR}" \
- ZSHCOMPLETIONDIR="${BASEDIR}/zsh/functions/Completion/X" \
- MANDIR="${PREFIX}/man" \
- PREFIX="${PREFIX}" \
- XSESSIONSDIR="${PREFIX}/share/applications"
+# tarball already includes generated manpages
+# saves depend on asciidoc
+CONFIGURE_ARGS += -DWITH_DOCUMENTATION=NO
+# requires unported pyewmh, pytest-xvfb and maybe more
NO_TEST = Yes
+
+post-install:
+ ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/herbstluftwm
+ ${INSTALL_SCRIPT} ${WRKINST}/etc/xdg/herbstluftwm/autostart \
+ ${PREFIX}/share/examples/herbstluftwm/
+ mv ${WRKINST}/etc/xdg/herbstluftwm/dmenu_run_hlwm \
+ ${PREFIX}/share/examples/herbstluftwm/
+ ${INSTALL_SCRIPT} ${WRKINST}/etc/xdg/herbstluftwm/panel.sh \
+ ${PREFIX}/share/examples/herbstluftwm/
+ ${INSTALL_SCRIPT} ${WRKINST}/etc/xdg/herbstluftwm/restartpanels.sh \
+ ${PREFIX}/share/examples/herbstluftwm/
+ ${INSTALL_MAN} ${WRKSRC}/doc/herbstclient.1 \
+ ${PREFIX}/man/man1/herbstclient.1
+ ${INSTALL_MAN} ${WRKSRC}/doc/herbstluftwm.1 \
+ ${PREFIX}/man/man1/herbstluftwm.1
+ ${INSTALL_MAN} ${WRKSRC}/doc/herbstluftwm-tutorial.7 \
+
Re: purritobin-0.1.2 - new package + dependencies
On 2020/06/01 22:13, Brian Callahan wrote: > Hi Aisha -- > > ‐‐‐ Original Message ‐‐‐ > On Sunday, May 31, 2020 10:03 PM, Aisha Tammy wrote: > > > Hi, > > > > I've attached the port again, with a few more fixes. > > > > Would love to see this added. > > > > A few words about this port: > > > > It is a minimalistic pastebin client which allows you to also > > > > paste encrypted texts and has a simple javascript decryptor frontend. > > > > It is asynchronous and allows you to limit the paste size and a > > > > location where the pastes are stored. > > > > It uses unveil and pledge to make sure that only the necessary > > > > folders and permissions are used. > > > > Really hope this can be added and would love to get any advice about > > > > how to improve this port :) > > > > Aisha > > Thanks for the ports. I've attached improved versions of the ports > that address what I'll talk about in this email. I'll take each > separately. > > usockets: > * I see that it compiles with -std=c11, so we need to have a > COMPILER=base-clang ports-gcc line. > * The Makefile has some -O3 lines, so those go. It also has some -flto > lines. I don't believe all our archs can support -flto at the moment > so I removed them too. > * I am not sure why you create and install a shared version of this > library. It seems like upstream intends for this to be statically > linked into executables. Indeed, you don't even use the shared > version of the library in PurritoBin, so I think it can go. > * Your patch to the Makefile causes everything to be recompiled at > fake time. > * Not related to your port, but too bad that we are stuck using libuv > (it can use kqueue but it uses extensions from FreeBSD that we don't > have). > > uwebsockets: > * Upstream claims this is a web server so I moved the category to www. > Devel is quite full. Otherwise this port is quite straightforward. > > purritobin: > * Since you're using the static version of usocket, we can simplify > your depends lists. > > ~Brian > purritobin - Makefile: - add "uses pledge()" above wantlib as done in other ports - pkg/DESCR: - trailing blank line - s/writted/written All these static libraries mean that things won't get updated automatically when a library is updated. Say you install purritobin and there is a later security fix to usockets; purritobin won't be updated unless you manually force it (e.g. by bumping REVISION). The normal way of handling this with almost everything else in ports is to use shared libraries.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: feine...@cvs.openbsd.org2020/06/02 06:48:47 Modified files: net/kdeconnect-kde: Makefile Added files: net/kdeconnect-kde/patches: patch-data_org_kde_kdeconnect_open_desktop Log message: Update home page and fix invalid */* MIME type
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/06/02 06:44:19 Modified files: mail/exim : Makefile distinfo mail/exim/patches: patch-Local_Makefile patch-src_lookups_spf_c Removed files: mail/exim/patches: patch-OS_Makefile-OpenBSD Log message: update to exim-4.94, from Renaud Allard. rather than patching to remove CFLAGS unsupported by gcc 4.2, just pass in CFLAGS via MAKE_FLAGS instead (also pass in CC).
Re: [update] mail/exim -> 4.94
On 2020/06/02 14:23, Renaud Allard wrote: > > > On 6/2/20 2:14 PM, Stuart Henderson wrote: > > On 2020/06/02 14:08, Renaud Allard wrote: > > > > > > > > > On 6/2/20 2:05 PM, Stuart Henderson wrote: > > > > On 2020/06/02 09:02, Renaud Allard wrote: > > > > > Hello, > > > > > > > > > > Here is a short diff to update exim to 4.94 > > > > > > > > The patch is still needed isn't it? > > > > > > > > > > The patch was conflicting with some changes in the source. Instead of > > > trying > > > to modify the patch, I removed it. I didn't have any problems without the > > > patch. I think it might have been put there to cope with very old versions > > > of gcc and it's probably not necessary anymore. It's probably better to > > > keep > > > our changes to the minimum. > > > > Please don't just remove a patch because there's a conflict, there is a > > reason why it was added that is clear from cvs history. OpenBSD still > > uses very old versions of GCC. > > > > Indeed, it seems those 2 flags are not yet in gcc 3.3. Let's go with your > modification instead. Or 4.2.1. Not sure when they were added, maybe around 4.6 sometime. I'll commit it then.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2020/06/02 06:28:06 Modified files: graphics/evince: Makefile distinfo Log message: update to evince-3.36.3
Re: [update] mail/exim -> 4.94
On 2020/06/02 14:08, Renaud Allard wrote:
>
>
> On 6/2/20 2:05 PM, Stuart Henderson wrote:
> > On 2020/06/02 09:02, Renaud Allard wrote:
> > > Hello,
> > >
> > > Here is a short diff to update exim to 4.94
> >
> > The patch is still needed isn't it?
> >
>
> The patch was conflicting with some changes in the source. Instead of trying
> to modify the patch, I removed it. I didn't have any problems without the
> patch. I think it might have been put there to cope with very old versions
> of gcc and it's probably not necessary anymore. It's probably better to keep
> our changes to the minimum.
Please don't just remove a patch because there's a conflict, there is a
reason why it was added that is clear from cvs history. OpenBSD still
uses very old versions of GCC.
We could do it like this instead though: (also pass in CC correctly,
and regen patches on Local/Makefile).
Index: Makefile
===
RCS file: /cvs/ports/mail/exim/Makefile,v
retrieving revision 1.130
diff -u -p -r1.130 Makefile
--- Makefile9 Jan 2020 20:43:15 - 1.130
+++ Makefile2 Jun 2020 12:13:11 -
@@ -3,7 +3,7 @@
COMMENT-main = flexible mail transfer agent
COMMENT-eximon = X11 monitor tool for Exim MTA
-VERSION = 4.93.0.4
+VERSION = 4.94
DISTNAME = exim-${VERSION}
PKGNAME-main = exim-${VERSION}
FULLPKGNAME-eximon = exim-eximon-${VERSION}
@@ -35,7 +35,7 @@ LIB_DEPENDS-main =converters/libiconv \
RUN_DEPENDS-eximon = ${PKGPATH},-main
LIB_DEPENDS-eximon = devel/pcre
-MAKE_FLAGS += FULLECHO=
+MAKE_FLAGS += FULLECHO= CC="${CC}" CFLAGS="${CFLAGS}"
PSEUDO_FLAVORS = no_eximon
FLAVORS = mysql postgresql sqlite3 ldap sasl
Index: distinfo
===
RCS file: /cvs/ports/mail/exim/distinfo,v
retrieving revision 1.40
diff -u -p -r1.40 distinfo
--- distinfo9 Jan 2020 20:43:15 - 1.40
+++ distinfo2 Jun 2020 12:13:11 -
@@ -1,2 +1,2 @@
-SHA256 (exim-4.93.0.4.tar.gz) = qHtu9QY5JoD6R+sSGbbDxbEwy5o8bw4MTsht2jD6dkM=
-SIZE (exim-4.93.0.4.tar.gz) = 2480960
+SHA256 (exim-4.94.tar.gz) = X+Rdm8+mfZR9cHr8MWzTbFMUcPaLJAk0Ia26Sq+BC9k=
+SIZE (exim-4.94.tar.gz) = 2515734
Index: patches/patch-Local_Makefile
===
RCS file: /cvs/ports/mail/exim/patches/patch-Local_Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 patch-Local_Makefile
--- patches/patch-Local_Makefile10 Dec 2019 23:21:37 - 1.3
+++ patches/patch-Local_Makefile2 Jun 2020 12:13:11 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-Local_Makefile,v 1.3 201
Index: Local/Makefile
--- Local/Makefile.orig
+++ Local/Makefile
-@@ -100,7 +100,7 @@
+@@ -99,7 +99,7 @@
# /usr/local/sbin. The installation script will try to create this directory,
# and any superior directories, if they do not exist.
@@ -12,7 +12,7 @@ Index: Local/Makefile
#--
-@@ -116,7 +116,7 @@ BIN_DIRECTORY=/usr/exim/bin
+@@ -115,7 +115,7 @@ BIN_DIRECTORY=/usr/exim/bin
# don't exist. It will also install a default runtime configuration if this
# file does not exist.
@@ -21,7 +21,7 @@ Index: Local/Makefile
# It is possible to specify a colon-separated list of files for
CONFIGURE_FILE.
# In this case, Exim will use the first of them that exists when it is run.
-@@ -133,7 +133,7 @@ CONFIGURE_FILE=/usr/exim/configure
+@@ -132,7 +132,7 @@ CONFIGURE_FILE=/usr/exim/configure
# deliveries. (Local deliveries run as various non-root users, typically as
the
# owner of a local mailbox.) Specifying these values as root is not supported.
@@ -30,7 +30,7 @@ Index: Local/Makefile
# If you specify EXIM_USER as a name, this is looked up at build time, and the
# uid number is built into the binary. However, you can specify that this
-@@ -211,11 +211,11 @@ SPOOL_DIRECTORY=/var/spool/exim
+@@ -210,11 +210,11 @@ SPOOL_DIRECTORY=/var/spool/exim
# If you are buliding with TLS, the library configuration must be done:
# Uncomment this if you are using OpenSSL
@@ -44,7 +44,7 @@ Index: Local/Makefile
# TLS_LIBS=-L/usr/local/openssl/lib -lssl -lcrypto
# Uncomment this if you are using GnuTLS
-@@ -338,7 +338,7 @@ TRANSPORT_SMTP=yes
+@@ -337,7 +337,7 @@ TRANSPORT_SMTP=yes
# This one is special-purpose, and commonly not required, so it is not
# included by default.
@@ -53,7 +53,7 @@ Index: Local/Makefile
#--
-@@ -347,9 +347,9 @@ TRANSPORT_SMTP=yes
+@@ -346,9 +346,9 @@ TRANSPORT_SMTP=yes
# MBX, is included only when requested. If you do not know what this is about,
# leave these settings commented out.
@@ -66,7 +66,7 @@ Index: Local/Makefile
Re: [update] mail/exim -> 4.94
On 2020/06/02 09:02, Renaud Allard wrote:
> Hello,
>
> Here is a short diff to update exim to 4.94
The patch is still needed isn't it?
> Regards
> Index: Makefile
> ===
> RCS file: /cvs/ports/mail/exim/Makefile,v
> retrieving revision 1.130
> diff -u -p -u -r1.130 Makefile
> --- Makefile 9 Jan 2020 20:43:15 - 1.130
> +++ Makefile 2 Jun 2020 06:53:56 -
> @@ -3,7 +3,7 @@
> COMMENT-main = flexible mail transfer agent
> COMMENT-eximon = X11 monitor tool for Exim MTA
>
> -VERSION =4.93.0.4
> +VERSION =4.94
> DISTNAME = exim-${VERSION}
> PKGNAME-main = exim-${VERSION}
> FULLPKGNAME-eximon = exim-eximon-${VERSION}
> Index: distinfo
> ===
> RCS file: /cvs/ports/mail/exim/distinfo,v
> retrieving revision 1.40
> diff -u -p -u -r1.40 distinfo
> --- distinfo 9 Jan 2020 20:43:15 - 1.40
> +++ distinfo 2 Jun 2020 06:53:56 -
> @@ -1,2 +1,2 @@
> -SHA256 (exim-4.93.0.4.tar.gz) = qHtu9QY5JoD6R+sSGbbDxbEwy5o8bw4MTsht2jD6dkM=
> -SIZE (exim-4.93.0.4.tar.gz) = 2480960
> +SHA256 (exim-4.94.tar.gz) = X+Rdm8+mfZR9cHr8MWzTbFMUcPaLJAk0Ia26Sq+BC9k=
> +SIZE (exim-4.94.tar.gz) = 2515734
> Index: patches/patch-OS_Makefile-OpenBSD
> ===
> RCS file: patches/patch-OS_Makefile-OpenBSD
> diff -N patches/patch-OS_Makefile-OpenBSD
> --- patches/patch-OS_Makefile-OpenBSD 27 Dec 2019 22:31:01 - 1.7
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,14 +0,0 @@
> -$OpenBSD: patch-OS_Makefile-OpenBSD,v 1.7 2019/12/27 22:31:01 sthen Exp $
> -
> -Index: OS/Makefile-OpenBSD
> OS/Makefile-OpenBSD.orig
> -+++ OS/Makefile-OpenBSD
> -@@ -5,7 +5,7 @@ CHGRP_COMMAND=/usr/sbin/chgrp
> - CHMOD_COMMAND=/bin/chmod
> -
> - CC=cc
> --CFLAGS=-O2 -Wall -Wno-parentheses -Wno-self-assign
> -Wno-logical-op-parentheses
> -+CFLAGS=-O2 -Wall -Wno-parentheses
> - CFLAGS += -DTAINT_CHECK_SLOW
> -
> - LIBS=-lm
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2020/06/02 05:47:10 Modified files: devel/capstone : Makefile.inc devel/capstone/main: distinfo devel/capstone/main/patches: patch-Makefile patch-arch_Mips_MipsDisassembler_c devel/capstone/main/pkg: PLIST devel/capstone/python: Makefile distinfo Log message: bugfix update to capstone-4.0.2 ok benoit@ (MAINTAINER)
[update] mail/exim -> 4.94
Hello,
Here is a short diff to update exim to 4.94
Regards
Index: Makefile
===
RCS file: /cvs/ports/mail/exim/Makefile,v
retrieving revision 1.130
diff -u -p -u -r1.130 Makefile
--- Makefile 9 Jan 2020 20:43:15 - 1.130
+++ Makefile 2 Jun 2020 06:53:56 -
@@ -3,7 +3,7 @@
COMMENT-main = flexible mail transfer agent
COMMENT-eximon = X11 monitor tool for Exim MTA
-VERSION = 4.93.0.4
+VERSION = 4.94
DISTNAME = exim-${VERSION}
PKGNAME-main = exim-${VERSION}
FULLPKGNAME-eximon = exim-eximon-${VERSION}
Index: distinfo
===
RCS file: /cvs/ports/mail/exim/distinfo,v
retrieving revision 1.40
diff -u -p -u -r1.40 distinfo
--- distinfo 9 Jan 2020 20:43:15 - 1.40
+++ distinfo 2 Jun 2020 06:53:56 -
@@ -1,2 +1,2 @@
-SHA256 (exim-4.93.0.4.tar.gz) = qHtu9QY5JoD6R+sSGbbDxbEwy5o8bw4MTsht2jD6dkM=
-SIZE (exim-4.93.0.4.tar.gz) = 2480960
+SHA256 (exim-4.94.tar.gz) = X+Rdm8+mfZR9cHr8MWzTbFMUcPaLJAk0Ia26Sq+BC9k=
+SIZE (exim-4.94.tar.gz) = 2515734
Index: patches/patch-OS_Makefile-OpenBSD
===
RCS file: patches/patch-OS_Makefile-OpenBSD
diff -N patches/patch-OS_Makefile-OpenBSD
--- patches/patch-OS_Makefile-OpenBSD 27 Dec 2019 22:31:01 - 1.7
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,14 +0,0 @@
-$OpenBSD: patch-OS_Makefile-OpenBSD,v 1.7 2019/12/27 22:31:01 sthen Exp $
-
-Index: OS/Makefile-OpenBSD
OS/Makefile-OpenBSD.orig
-+++ OS/Makefile-OpenBSD
-@@ -5,7 +5,7 @@ CHGRP_COMMAND=/usr/sbin/chgrp
- CHMOD_COMMAND=/bin/chmod
-
- CC=cc
--CFLAGS=-O2 -Wall -Wno-parentheses -Wno-self-assign -Wno-logical-op-parentheses
-+CFLAGS=-O2 -Wall -Wno-parentheses
- CFLAGS += -DTAINT_CHECK_SLOW
-
- LIBS=-lm
smime.p7s
Description: S/MIME Cryptographic Signature
Re: ok? games/sauerbraten diff add ppc
On Tue, Jun 02, 2020 at 12:39:07AM +0200, ale...@mail.com wrote: > Tested on current, barely playable on my machine but works fine. thanks, committed > > Index: games/sauerbraten/Makefile > === > RCS file: /cvs/ports/games/sauerbraten/Makefile,v > retrieving revision 1.8 > diff -u -p -u -r1.8 Makefile > --- games/sauerbraten/Makefile14 Jul 2019 02:16:51 - 1.8 > +++ games/sauerbraten/Makefile1 Jun 2020 22:25:16 - > @@ -1,6 +1,6 @@ > # $OpenBSD: Makefile,v 1.8 2019/07/14 02:16:51 naddy Exp $ > > -ONLY_FOR_ARCHS= i386 amd64 > +ONLY_FOR_ARCHS= i386 amd64 macppc > > COMMENT-main=sauerbraten client > COMMENT-data=sauerbraten data > >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2020/06/02 03:22:26 Modified files: games/sauerbraten: Makefile Log message: add macppc to sauerbraten arch list from ale...@mail.com
Re: Update lang/ecl to 20.4.24
On Tue, Jun 2, 2020, at 12:16, Ingo Feinerer wrote: > On Tue, Jun 02, 2020 at 07:01:57AM +0300, Timo Myyrä wrote: > > Did you get the maxima tests to run as well? I didn't have success yet > > with those although the compilation worked. > > How did you run the tests? > > `make test` runs a test suite but the results are only written to a log > file (pobj/maxima-5.43.2/maxima-5.43.2/tests/ecl-test.sh.log). As the > tests take some time the test suite might appear to hang. > > The same test suite can be triggered manually if you start xmaxima and > click on the `Maxima->Run Tests` menu entry. The output is immediately > shown in the input/output window. > > Best regards, > Ingo > I did use the make test. Wondered a bit about the lack of output mut noticed with ktrace it has doing the tests so I waited. I'll check again later to see if the exact failure. Timo
Re: Update lang/ecl to 20.4.24
On Tue, Jun 02, 2020 at 07:01:57AM +0300, Timo Myyrä wrote: > Did you get the maxima tests to run as well? I didn't have success yet > with those although the compilation worked. How did you run the tests? `make test` runs a test suite but the results are only written to a log file (pobj/maxima-5.43.2/maxima-5.43.2/tests/ecl-test.sh.log). As the tests take some time the test suite might appear to hang. The same test suite can be triggered manually if you start xmaxima and click on the `Maxima->Run Tests` menu entry. The output is immediately shown in the input/output window. Best regards, Ingo
aarch64 bulk build report
bulk build on arm64.ports.openbsd.org started on Sat May 30 07:41:23 MDT 2020 finished at Tue Jun 2 01:50:49 MDT 2020 lasted 2D18h09m done with kern.version=OpenBSD 6.7-current (GENERIC.MP) #633: Fri May 29 11:05:51 MDT 2020 built packages:10924 May 30:3692 May 31:1298 Jun 1:3406 Jun 2:2527 critical path missing pkgs: http://build-failures.rhaalovely.net/aarch64/2020-05-30/summary.log build failures: 12 http://build-failures.rhaalovely.net/aarch64/2020-05-30/editors/xwpe.log http://build-failures.rhaalovely.net/aarch64/2020-05-30/graphics/vulkan-loader.log http://build-failures.rhaalovely.net/aarch64/2020-05-30/lang/pfe.log http://build-failures.rhaalovely.net/aarch64/2020-05-30/net/gnugk.log http://build-failures.rhaalovely.net/aarch64/2020-05-30/sysutils/nomad.log http://build-failures.rhaalovely.net/aarch64/2020-05-30/sysutils/rclone.log http://build-failures.rhaalovely.net/aarch64/2020-05-30/sysutils/telegraf.log http://build-failures.rhaalovely.net/aarch64/2020-05-30/sysutils/terragrunt.log http://build-failures.rhaalovely.net/aarch64/2020-05-30/telephony/resiprocate,.log http://build-failures.rhaalovely.net/aarch64/2020-05-30/x11/e17/elementary.log http://build-failures.rhaalovely.net/aarch64/2020-05-30/x11/qt5/qtwebengine.log http://build-failures.rhaalovely.net/aarch64/2020-05-30/x11/spice-gtk.log recurrent failures failures/editors/xwpe.log failures/graphics/vulkan-loader.log failures/lang/pfe.log failures/sysutils/nomad.log failures/sysutils/telegraf.log failures/sysutils/terragrunt.log failures/x11/e17/elementary.log failures/x11/qt5/qtwebengine.log new failures +++ ls-failures Tue Jun 2 01:51:00 2020 +failures/net/gnugk.log +failures/sysutils/rclone.log +failures/telephony/resiprocate,.log +failures/x11/spice-gtk.log resolved failures --- ../old/aarch64/last//ls-failuresWed May 27 18:17:25 2020 -failures/devel/tbb.log -failures/x11/kde4/amor.log -failures/x11/kde4/parley.log -failures/x11/kde4/pim.log -failures/x11/kde4/runtime,-locale.log -failures/x11/kde4/superkaramba.log
Re: UPDATE: net/prosody 0.11.5 from maintainer
On Fri, May 29, 2020 at 02:22:27PM +, Lucas wrote: > Lucas wrote: > > Okey, updated patch in here. It still runs OK in my server. > > The bump never ends. Sorry - commited!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/06/02 01:22:46 Modified files: net/prosody: Makefile distinfo net/prosody/patches: patch-prosody_cfg_lua_dist net/prosody/pkg: prosody.rc Log message: Update to prosody 0.11.5, from MAINTAINER Lucas. Fixes rc script to use the right pexp.
Re: [new] databases/pgtap (and databases/p5-TAP-Parser-SourceHandler-pgTAP dep)
On Sat, May 23, 2020 at 10:46:00AM +0200, Landry Breuil wrote: > Hi, > > here are two new ports, one for pgtap (https://pgtap.org/) and one for > TAP::Parser::SourceHandler::pgTAP which provides the pg_prove script, > used to run the regress tests for the upcoming 3.0.0 version of > geo/pgrouting. > > pgtap is a postgresql extension to run regress tests using the TAP framework. > > thanks to the nice testing bits from postgresql.port.mk, i can easily > run the pgtap tests themselves, and only some of them fail due to > user/ownership issues that i think cant be worked around on OpenBSD, > since we run build bits with fixed users (be it with PORTS_PRIVSEP or > not): > > # Failed test 1: "db_owner_is(db, user, desc) should pass" > # have: false > # want: true > # Failed test 3: "db_owner_is(db, user, desc) should have the proper > diagnostics" > # have: have: landry > # want: postgres > # want: > # Failed test 4: "db_owner_is(db, user) should pass" > # have: false > # want: true > # Failed test 6: "db_owner_is(db, user) should have the proper diagnostics" > # have: have: landry > # want: postgres > # want: > # Failed test 12: "db_owner_is(db, non-user) should have the proper > diagnostics" > # have: have: landry > # want: __not__postgres > # want: have: postgres > # want: __not__postgres > # Looks like you failed 5 tests of 411 > Failed 5/411 subtests > > looking for feedback from the pgsql wizards (or perl wizards even!) and oks to > import. Anyone ? Would like to move forward with pgrouting 3.0, and those two ports will allow me fixing regress tests. And pgtap could be used by other pg* ports.. Landry pgtap-1.1.0.tgz Description: application/tar-gz p5-TAP-Parser-SourceHandler-pgTAP-3.35.tgz Description: application/tar-gz
