Re: OpenBSD maintainers Spring cleaning
On 6/6/19 12:54 AM, Daniel Jakots wrote: Some people mailed me after I posted the list here and no one said it was in their spam. If people receive a lot of mails and receive that one from an "unknown" email address (understand non @openbsd.org), and the mail looks like some kind of phishing attempt, they may have deleted it on sight. I was also reluctant at answering because I didn't know the mail address from the sender. Next time, I think it might be interesting to send it from an @openbsd.org mail address. Of course, from the official servers with SPF/DKIM, etc set up correctly. smime.p7s Description: S/MIME Cryptographic Signature
Re: UPDATE: SQLMap-1.3.6
On Tue, Jun 04, 2019 at 02:42:38PM +0200, Gonzalo L. Rodriguez wrote:
> Hello,
>
> Update for SQLMap to 1.3.5:
>
> https://github.com/sqlmapproject/sqlmap/releases/tag/1.3.6
>
> OK? Comments?
I've tested this lightly and it's working fine for me.
>
> Cheers.-
>
> --
>
> - gonzalo
> Index: Makefile
> ===
> RCS file: /cvs/ports/security/sqlmap/Makefile,v
> retrieving revision 1.19
> diff -u -p -r1.19 Makefile
> --- Makefile 9 May 2019 14:03:14 - 1.19
> +++ Makefile 4 Jun 2019 12:40:39 -
> @@ -4,7 +4,7 @@ COMMENT = penetration testing tool to d
>
> GH_ACCOUNT = sqlmapproject
> GH_PROJECT = sqlmap
> -GH_TAGNAME = 1.3.5
> +GH_TAGNAME = 1.3.6
>
> CATEGORIES = security
>
> @@ -14,6 +14,7 @@ HOMEPAGE = http://sqlmap.org/
> PERMIT_PACKAGE_CDROM = Yes
>
> MODULES =lang/python
> +MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}
>
> MODPY_ADJ_FILES = sqlmap.py
>
> Index: distinfo
> ===
> RCS file: /cvs/ports/security/sqlmap/distinfo,v
> retrieving revision 1.15
> diff -u -p -r1.15 distinfo
> --- distinfo 9 May 2019 14:03:14 - 1.15
> +++ distinfo 4 Jun 2019 12:40:39 -
> @@ -1,2 +1,2 @@
> -SHA256 (sqlmap-1.3.5.tar.gz) = NMEW896DGuPqtyFrkzylo9u2qRr0lw+1nbdGURABj/g=
> -SIZE (sqlmap-1.3.5.tar.gz) = 7430961
> +SHA256 (sqlmap-1.3.6.tar.gz) = JlN42T1POgJevf1eUCpntMA9FNZjgWFcT08S5jZwvdQ=
> +SIZE (sqlmap-1.3.6.tar.gz) = 7452711
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/security/sqlmap/pkg/PLIST,v
> retrieving revision 1.15
> diff -u -p -r1.15 PLIST
> --- pkg/PLIST 9 May 2019 14:03:14 - 1.15
> +++ pkg/PLIST 4 Jun 2019 12:40:39 -
> @@ -4,41 +4,174 @@ share/sqlmap/
> share/sqlmap/.github/
> share/sqlmap/.github/CODE_OF_CONDUCT.md
> share/sqlmap/.github/CONTRIBUTING.md
> -share/sqlmap/.github/ISSUE_TEMPLATE.md
> +share/sqlmap/.github/ISSUE_TEMPLATE/
> +share/sqlmap/.github/ISSUE_TEMPLATE/bug_report.md
> +share/sqlmap/.github/ISSUE_TEMPLATE/feature_request.md
> +share/sqlmap/.pylintrc
> share/sqlmap/.travis.yml
> share/sqlmap/COMMITMENT
> share/sqlmap/LICENSE
> +${MODPY_COMMENT}share/sqlmap/${MODPY_PYCACHE}/
> +share/sqlmap/${MODPY_PYCACHE}sqlmap.${MODPY_PYC_MAGIC_TAG}pyc
> +share/sqlmap/${MODPY_PYCACHE}sqlmapapi.${MODPY_PYC_MAGIC_TAG}pyc
> +share/sqlmap/data/
> +share/sqlmap/data/procs/
> +share/sqlmap/data/procs/README.txt
> +share/sqlmap/data/procs/mssqlserver/
> +share/sqlmap/data/procs/mssqlserver/activate_sp_oacreate.sql
> +share/sqlmap/data/procs/mssqlserver/configure_openrowset.sql
> +share/sqlmap/data/procs/mssqlserver/configure_xp_cmdshell.sql
> +share/sqlmap/data/procs/mssqlserver/create_new_xp_cmdshell.sql
> +share/sqlmap/data/procs/mssqlserver/disable_xp_cmdshell_2000.sql
> +share/sqlmap/data/procs/mssqlserver/dns_request.sql
> +share/sqlmap/data/procs/mssqlserver/enable_xp_cmdshell_2000.sql
> +share/sqlmap/data/procs/mssqlserver/run_statement_as_user.sql
> +share/sqlmap/data/procs/mysql/
> +share/sqlmap/data/procs/mysql/dns_request.sql
> +share/sqlmap/data/procs/mysql/write_file_limit.sql
> +share/sqlmap/data/procs/oracle/
> +share/sqlmap/data/procs/oracle/dns_request.sql
> +share/sqlmap/data/procs/postgresql/
> +share/sqlmap/data/procs/postgresql/dns_request.sql
> +share/sqlmap/data/shell/
> +share/sqlmap/data/shell/README.txt
> +share/sqlmap/data/shell/backdoors/
> +share/sqlmap/data/shell/backdoors/backdoor.asp_
> +share/sqlmap/data/shell/backdoors/backdoor.aspx_
> +share/sqlmap/data/shell/backdoors/backdoor.jsp_
> +share/sqlmap/data/shell/backdoors/backdoor.php_
> +share/sqlmap/data/shell/stagers/
> +share/sqlmap/data/shell/stagers/stager.asp_
> +share/sqlmap/data/shell/stagers/stager.aspx_
> +share/sqlmap/data/shell/stagers/stager.jsp_
> +share/sqlmap/data/shell/stagers/stager.php_
> +share/sqlmap/data/txt/
> +share/sqlmap/data/txt/common-columns.txt
> +share/sqlmap/data/txt/common-outputs.txt
> +share/sqlmap/data/txt/common-tables.txt
> +share/sqlmap/data/txt/keywords.txt
> +share/sqlmap/data/txt/smalldict.txt
> +share/sqlmap/data/txt/user-agents.txt
> +share/sqlmap/data/txt/wordlist.tx_
> +share/sqlmap/data/udf/
> +share/sqlmap/data/udf/README.txt
> +share/sqlmap/data/udf/mysql/
> +share/sqlmap/data/udf/mysql/linux/
> +share/sqlmap/data/udf/mysql/linux/32/
> +share/sqlmap/data/udf/mysql/linux/32/lib_mysqludf_sys.so_
> +share/sqlmap/data/udf/mysql/linux/64/
> +share/sqlmap/data/udf/mysql/linux/64/lib_mysqludf_sys.so_
> +share/sqlmap/data/udf/mysql/windows/
> +share/sqlmap/data/udf/mysql/windows/32/
> +share/sqlmap/data/udf/mysql/windows/32/lib_mysqludf_sys.dll_
> +share/sqlmap/data/udf/mysql/windows/64/
> +share/sqlmap/data/udf/mysql/windows/64/lib_mysqludf_sys.dll_
> +share/sqlmap/data/udf/postgresql/
>
Re: [update] textproc/lowdown
> On Jun 5, 2019, at 10:46 PM, Bryan Vyhmeister wrote: > >> On Fri, May 31, 2019 at 06:17:41PM +0200, Paco Esteban wrote: >>> On Thu, 23 May 2019, Micah Muer wrote: >>> >>> Here is a simple diff to update lowdown from 0.4.2 to 0.4.3. >>> >>> The changelog is very short: >>> Version 0.4.3, 2019-04-01 Fix a segmentation fault. >>> >>> I tested this on OpenBSD -current on amd64. It works fine from what I >>> see. >> >> Works just fine for me also on amd64. > > maintainer ok > > Looks good to me. Thanks for the doing the update. If someone else could > ok and commit, that would be great. Committed. Thanks. > > Bryan >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dan...@cvs.openbsd.org 2019/06/05 21:18:34 Modified files: textproc/lowdown: Makefile distinfo Log message: Update to lowdown 0.4.3; from Micah Muer. ok Bryan Vyhmeister (MAINTAINER).
Re: [update] textproc/lowdown
On Fri, May 31, 2019 at 06:17:41PM +0200, Paco Esteban wrote: > On Thu, 23 May 2019, Micah Muer wrote: > > > Here is a simple diff to update lowdown from 0.4.2 to 0.4.3. > > > > The changelog is very short: > > > > >Version 0.4.3, 2019-04-01 > > > > > >Fix a segmentation fault. > > > > I tested this on OpenBSD -current on amd64. It works fine from what I > > see. > > Works just fine for me also on amd64. maintainer ok Looks good to me. Thanks for the doing the update. If someone else could ok and commit, that would be great. Bryan
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: l...@cvs.openbsd.org2019/06/05 20:24:00 Modified files: security/burpsuite: Makefile Log message: Burp Suite Community Edition needs jdk 1.8 to run properly, so set its MODJAVA_VER to 1.8; feedback/ok ian@ While here: * Add a reminder about checking if future updates will work with jdk 11 (text borrowed from sthen@) * Switch to the new PERMIT_* markers (thanks to naddy@ for confirming that this is the right way to do this) * Change the HOMEPAGE to use https
Re: OpenMP for both clang and GCC, part II
On 6/5/19 8:37 PM, j...@bitminer.ca wrote: On 2019-06-05 17:59, Brian Callahan wrote: On 6/5/19 7:42 PM, j...@bitminer.ca wrote: TLDR: Multi-core is a thing. Let's do it the OpenMP way. My diffs to come. I know some devs have thought about this before. I'm looking for comments or advice on how I can help this along. The clang in base (and flang in ports) currently support OpenMP directives with the -fopenmp option. They are missing the runtime. The LLVM OpenMP runtime could be supplied as a port. The GNU C, C++ and Fortran in ports (gcc version 8.3) currently support OpenMP directives and with a small patch can add OpenMP support to their runtime libraries (gcc-libs). The two OpenMP runtimes (GCC and LLVM) can coexist this way. Example ports, compiler, build system, and status/issues: devel/boost (base-clang gcc-ports, unique build, uncertain support) devel/cmake (base-clang gcc-ports, simple, fails to correctly find OpenMP) graphics/lensfun (base-clang gcc-ports, cmake, unswitchable OpenMP) graphics/GraphicsMagick (base-clang gcc-ports, gnu configure, OpenMP disabled) Proposed changes: - identify ports with embedded (hidden) OpenMP support and patch to disable it (I guess from 10 to 40 such ports aside from the 7 that turn it off now) - fix cmake (and other build systems) to detect both OpenMP implementations - add a new port devel/libomp containing the LLVM OpenMP runtime for clang/flang - patch gcc-libs package to deliver OpenMP runtime support for GNU c/c++/fortran - help port maintainers build with OpenMP flavors if they want it (I have patches for cmake, gcc-libs, and a proposed new devel/libomp package). Eventually ports maintaners will migrate to OpenMP as they can or want to. Users will adopt flavors such as -withopenmp, or -noopenmp, as they become available. Some issues and questions: - this will work for amd64, but will it work for arm64, sparc? Others? - should the flavors be -withopenmp or -noopenmp? - how to successfully detect 90% or more of ports with hidden OpenMP support? I will do this and am looking for advice on how best to approach it. Any pre-existing info would be very welcome. Does anyone have comments? I'll be submitting diffs as I can. --John On LLVM OpenMP: https://marc.info/?l=openbsd-ports=155642976702196=2 ~Brian Yes, and also I saw some of your posts to ports from a couple of years ago regarding checking for openmp use. https://marc.info/?l=openbsd-ports=151051634223013=2 Did you get further that what is stated in the post? I'm thinking math/ and geo/ and graphics/ as the most likely. --John Nope. I don't own a machine that could run a bulk in any reasonable amount of time. ~Brian
Re: OpenMP for both clang and GCC, part II
On 2019-06-05 17:59, Brian Callahan wrote: On 6/5/19 7:42 PM, j...@bitminer.ca wrote: TLDR: Multi-core is a thing. Let's do it the OpenMP way. My diffs to come. I know some devs have thought about this before. I'm looking for comments or advice on how I can help this along. The clang in base (and flang in ports) currently support OpenMP directives with the -fopenmp option. They are missing the runtime. The LLVM OpenMP runtime could be supplied as a port. The GNU C, C++ and Fortran in ports (gcc version 8.3) currently support OpenMP directives and with a small patch can add OpenMP support to their runtime libraries (gcc-libs). The two OpenMP runtimes (GCC and LLVM) can coexist this way. Example ports, compiler, build system, and status/issues: devel/boost (base-clang gcc-ports, unique build, uncertain support) devel/cmake (base-clang gcc-ports, simple, fails to correctly find OpenMP) graphics/lensfun (base-clang gcc-ports, cmake, unswitchable OpenMP) graphics/GraphicsMagick (base-clang gcc-ports, gnu configure, OpenMP disabled) Proposed changes: - identify ports with embedded (hidden) OpenMP support and patch to disable it (I guess from 10 to 40 such ports aside from the 7 that turn it off now) - fix cmake (and other build systems) to detect both OpenMP implementations - add a new port devel/libomp containing the LLVM OpenMP runtime for clang/flang - patch gcc-libs package to deliver OpenMP runtime support for GNU c/c++/fortran - help port maintainers build with OpenMP flavors if they want it (I have patches for cmake, gcc-libs, and a proposed new devel/libomp package). Eventually ports maintaners will migrate to OpenMP as they can or want to. Users will adopt flavors such as -withopenmp, or -noopenmp, as they become available. Some issues and questions: - this will work for amd64, but will it work for arm64, sparc? Others? - should the flavors be -withopenmp or -noopenmp? - how to successfully detect 90% or more of ports with hidden OpenMP support? I will do this and am looking for advice on how best to approach it. Any pre-existing info would be very welcome. Does anyone have comments? I'll be submitting diffs as I can. --John On LLVM OpenMP: https://marc.info/?l=openbsd-ports=155642976702196=2 ~Brian Yes, and also I saw some of your posts to ports from a couple of years ago regarding checking for openmp use. https://marc.info/?l=openbsd-ports=151051634223013=2 Did you get further that what is stated in the post? I'm thinking math/ and geo/ and graphics/ as the most likely. --John
Re: OpenMP for both clang and GCC, part II
On 6/5/19 7:42 PM, j...@bitminer.ca wrote: TLDR: Multi-core is a thing. Let's do it the OpenMP way. My diffs to come. I know some devs have thought about this before. I'm looking for comments or advice on how I can help this along. The clang in base (and flang in ports) currently support OpenMP directives with the -fopenmp option. They are missing the runtime. The LLVM OpenMP runtime could be supplied as a port. The GNU C, C++ and Fortran in ports (gcc version 8.3) currently support OpenMP directives and with a small patch can add OpenMP support to their runtime libraries (gcc-libs). The two OpenMP runtimes (GCC and LLVM) can coexist this way. Example ports, compiler, build system, and status/issues: devel/boost (base-clang gcc-ports, unique build, uncertain support) devel/cmake (base-clang gcc-ports, simple, fails to correctly find OpenMP) graphics/lensfun (base-clang gcc-ports, cmake, unswitchable OpenMP) graphics/GraphicsMagick (base-clang gcc-ports, gnu configure, OpenMP disabled) Proposed changes: - identify ports with embedded (hidden) OpenMP support and patch to disable it (I guess from 10 to 40 such ports aside from the 7 that turn it off now) - fix cmake (and other build systems) to detect both OpenMP implementations - add a new port devel/libomp containing the LLVM OpenMP runtime for clang/flang - patch gcc-libs package to deliver OpenMP runtime support for GNU c/c++/fortran - help port maintainers build with OpenMP flavors if they want it (I have patches for cmake, gcc-libs, and a proposed new devel/libomp package). Eventually ports maintaners will migrate to OpenMP as they can or want to. Users will adopt flavors such as -withopenmp, or -noopenmp, as they become available. Some issues and questions: - this will work for amd64, but will it work for arm64, sparc? Others? - should the flavors be -withopenmp or -noopenmp? - how to successfully detect 90% or more of ports with hidden OpenMP support? I will do this and am looking for advice on how best to approach it. Any pre-existing info would be very welcome. Does anyone have comments? I'll be submitting diffs as I can. --John On LLVM OpenMP: https://marc.info/?l=openbsd-ports=155642976702196=2 ~Brian
OpenMP for both clang and GCC, part II
TLDR: Multi-core is a thing. Let's do it the OpenMP way. My diffs to come. I know some devs have thought about this before. I'm looking for comments or advice on how I can help this along. The clang in base (and flang in ports) currently support OpenMP directives with the -fopenmp option. They are missing the runtime. The LLVM OpenMP runtime could be supplied as a port. The GNU C, C++ and Fortran in ports (gcc version 8.3) currently support OpenMP directives and with a small patch can add OpenMP support to their runtime libraries (gcc-libs). The two OpenMP runtimes (GCC and LLVM) can coexist this way. Example ports, compiler, build system, and status/issues: devel/boost (base-clang gcc-ports, unique build, uncertain support) devel/cmake (base-clang gcc-ports, simple, fails to correctly find OpenMP) graphics/lensfun (base-clang gcc-ports, cmake, unswitchable OpenMP) graphics/GraphicsMagick (base-clang gcc-ports, gnu configure, OpenMP disabled) Proposed changes: - identify ports with embedded (hidden) OpenMP support and patch to disable it (I guess from 10 to 40 such ports aside from the 7 that turn it off now) - fix cmake (and other build systems) to detect both OpenMP implementations - add a new port devel/libomp containing the LLVM OpenMP runtime for clang/flang - patch gcc-libs package to deliver OpenMP runtime support for GNU c/c++/fortran - help port maintainers build with OpenMP flavors if they want it (I have patches for cmake, gcc-libs, and a proposed new devel/libomp package). Eventually ports maintaners will migrate to OpenMP as they can or want to. Users will adopt flavors such as -withopenmp, or -noopenmp, as they become available. Some issues and questions: - this will work for amd64, but will it work for arm64, sparc? Others? - should the flavors be -withopenmp or -noopenmp? - how to successfully detect 90% or more of ports with hidden OpenMP support? I will do this and am looking for advice on how best to approach it. Any pre-existing info would be very welcome. Does anyone have comments? I'll be submitting diffs as I can. --John
Re: OpenBSD maintainers Spring cleaning
On Wed, 5 Jun 2019 22:59:20 +0100, Stuart Henderson wrote: > Annoying as some of those people I would really have expected to > reply if they received it (unless they are just being obtuse which > doesn't help anyone..), and of course there are others who are > exactly the ones that we need to get dropped because waiting for > unresponsive maintainers to reply to emails about their ports is a > real waste of time for ports submitters and committers. > > So it's hard to say whether the mails got spam-filtered or just > ignored. I would be surprised if it was spam. I'm aware of only 4 problems, 3 of them were because my spf was initially hard fail and it was sent to @openbsd.org addresses. I quickly changed my spf to soft fail and sent the two that were never delivered. Another developer had the same problem but I didn't get any bounce in this case and the developer found the mail in the spam. The fourth one is a user that said it was in the spam and it was after my spf change so I don't know which caused it. Some people mailed me after I posted the list here and no one said it was in their spam. iirc I changed my spf before I sent emails to any non @openbsd.org address so I doubt it could have caused any problem. (Always dog food stuff :)). > I've reformatted the list alphabetically : Here's the updated one: aaron bieberalex feinberg alexander shiryaev amarendra godbole amaury gauthier andrew aldridge can erkin acar david schaefer diego casati douglas william thrift edward gallon sylvestre genadijus paleckis helen koike hermann gottschalk holger mauermannibrahim khalifa jakob schlyter james e keenan james wrightjason meltzer jasper lievisse adriaanse jeff bachteljeff rhyason joel sing johan fredinjon olsson jonathan armani josh rivel jung lee kevin wondratschlaurent moccellin lazaros koromilas ljuba nedeljkovic mario lang marius eriksen masao uebayashi mathieu sauve-frankel matteo cantoni matthias pitzl michael knudsen michael paddon michael reedmike larkin nicholas marriott nick nauwelaertspatrick keshishian patrick wildt patrikas kugrinas patsy pete fritchman rene maroufiromain gaillegueroman kravchuk suzuki hitoshi thomas wood todd t. fries vadim zhukovvlad glagolev vladimir popov vladimir tamara patino wolfgang rupprecht yasuoka masahiko > > How do we proceed from here? > > I would keep the ones from reasonably active committers as-is > (abieber jasper job jsing mlarkin nicm patrick yasuoka) and drop the > others unless they reply to this mail to say that they're still around > and interested. > > Easy to add others back in if they later decide they do want to > continue to maintain the ports but we need to draw a line somewhere. Sure, I'll provide a list of maintainers/ports to be cleaned for review. Thanks! Daniel
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dan...@cvs.openbsd.org 2019/06/05 16:43:01 Modified files: math/py-sympy : Makefile distinfo math/py-sympy/patches: patch-setup_py math/py-sympy/pkg: PLIST Log message: Update to py-sympy-1.4 and take maintainer.
Re: NEW: audio/rubberband 1.8.2
On 2019/06/04 14:10, Raphael Graf wrote:
> On Sun, May 26, 2019 at 09:43:59PM +0200, Raphael Graf wrote:
> > On Sun, May 26, 2019 at 03:58:18PM +0100, Stuart Henderson wrote:
> > > On 2019/05/26 16:45, Raphael Graf wrote:
> > > > On Sun, May 12, 2019 at 05:53:06PM +0200, Raphael Graf wrote:
> > > > > Rubber Band is a library and utility program that permits changing the
> > > > > tempo and pitch of an audio recording independently of one another.
> > > > >
> > > > > https://breakfastquay.com/rubberband/
> > > > >
> > > > > Older versions of this port have been submitted before:
> > > > > https://github.com/jasperla/openbsd-wip/tree/master/audio/rubberband
> > > > > https://marc.info/?l=openbsd-ports=148460134815562=2
> > > > >
> > > > > It would be nice to have because it enables important functionality in
> > > > > audio/hydrogen. Other ports like multimedia/mpv could benefit as well.
> > > > >
> > > > > I've tested on amd64, i386 and macppc.
> > > > >
> > > > > Comments, tests or OKs are welcome.
> > > > >
> > > >
> > > > Anyone willing to ok this?
> > > >
> > >
> > > Please replace
> > >
> > > V =1.8.2
> > > DISTNAME = rubberband-${V}
> > > EXTRACT_SUFX = .tar.bz2
> > > DISTFILES =rubberband-${V}${EXTRACT_SUFX}
> > >
> > > with
> > >
> > > DISTNAME = rubberband-1.8.2
> > > EXTRACT_SUFX = .tar.bz2
> >
> > sure, done..
> >
> > >
> > > I think we need to at least check ports where the word 'rubberband'
> > > shows up in build logs to try to identify other ports that might pick
> > > this up and either disable or add as a dependency. Here's the list,
> > > though most Qt ones are probably junk noise in the logs (there's some Qt
> > > source file with rubberband in the name).
> > >
> > > audio/hydrogen
> > > audio/lmms
> > > cad/pcb
> > > devel/qt-creator
> > > games/enigma
> > > geo/qgis
> > > graphics/inkscape
> > > graphics/kdiagram
> > > multimedia/mpv
> > > textproc/wkhtmltopdf
> > > x11/kde-applications/dolphin
> > > x11/py-qt4
> > > x11/py-qt5
> > > x11/py-wxPython
> > > x11/qt4
> > > x11/qt5/qtbase
> > > x11/qt5/qtwebkit
> > >
> >
> > I've checked them all, they do not pick it up.
> > (The only real candidates are hydrogen and mpv.)
> >
>
> Any news on this one?
>
> I find rubberband very useful.
> Compared to soundtouch, it seems to produce much better quality.
> I'm not an audiophile, but I can hear a difference between these two:
>
> $ rubberband --time 0.5 input.wav output.wav
> $ soundstretch input.wav output.wav -tempo=100
>
It needs to use the same COMPILER line as other c++ things (in particular
as ladspa/vamp-plugin-sdk) to avoid c++ standard library conflicts on
!clang arches.
Otherwise OK.
Re: OpenBSD maintainers Spring cleaning
On 2019/06/02 10:45, Daniel Jakots wrote: > On Fri, 10 May 2019 13:04:35 -0400, Daniel Jakots wrote: > > > On Tue, 30 Apr 2019 17:50:24 -0400, Daniel Jakots > > wrote: > > > > > We decided to email each maintainer to verify OpenBSD port > > > maintainers can be reached and wish to remain active. I'm going to > > > send these emails over the next few days. > > > > All emails should have been sent. I replied to all the answers I got > > so far so if you didn't get any reply from me, please consider I > > didn't get your pong. > > > > And please answer no matter what you believe as in "danj knows I'm > > active". Let's assume I don't, so I can cross your name out. > > So here's the name of the maintainers I didn't hear of (it's prefixed > with the date when their email was sent): > ... Annoying as some of those people I would really have expected to reply if they received it (unless they are just being obtuse which doesn't help anyone..), and of course there are others who are exactly the ones that we need to get dropped because waiting for unresponsive maintainers to reply to emails about their ports is a real waste of time for ports submitters and committers. So it's hard to say whether the mails got spam-filtered or just ignored. I've reformatted the list alphabetically : aaron bieberalex feinberg alexander shiryaev amarendra godbole amaury gauthier andrew aldridge can erkin acar david carlier david schaefer diego casatidouglas william thrift edward gallon sylvestregenadijus paleckis helen koike hermann gottschalk holger mauermannibrahim khalifa jakob schlyter james e keenan james wright jason meltzer jasper lievisse adriaanse jeff bachtel jeff rhyasonjob snijdersjoel sing johan fredinjon olsson jonathan armani josh rivel jung leekevin wondratsch kristaps dzonsons laurent moccellin lazaros koromilas ljuba nedeljkovic mario lang marius eriksen masao uebayashi mathieu sauve-frankel matteo cantoni matthias pitzl michael knudsen michael paddon michael reedmike larkin nicholas marriott nick nauwelaertspatrick keshishian patrick wildt patrikas kugrinas patsy pete fritchman rene maroufiromain gaillegueroman kravchuk suzuki hitoshi thomas wood todd t. fries vadim zhukovvlad glagolev vladimir popov vladimir tamara patino wen heping wolfgang rupprecht yasuoka masahiko > How do we proceed from here? I would keep the ones from reasonably active committers as-is (abieber jasper job jsing mlarkin nicm patrick yasuoka) and drop the others unless they reply to this mail to say that they're still around and interested. Easy to add others back in if they later decide they do want to continue to maintain the ports but we need to draw a line somewhere.
Re: "vfprintf %s NULL" during bulk build
On 2019/06/05 23:08, Markus Lude wrote:
> On Wed, Jun 05, 2019 at 09:06:48PM +0100, Stuart Henderson wrote:
> > While reviewing syslog to look for realpath problems I noticed these,
> > in case anyone cares:
> >
> > GUPnPAV-1.0: vfprintf %s NULL in "URL: %s, ID: %s."
> > desktoptojson: vfprintf %s NULL in "Warning: %s (%s:%u, %s) "
> > mono: vfprintf %s NULL in "%s %2d %02d:%02d:%02d%.*s %d%s"
> > valac: vfprintf %s NULL in " value="%s""
> > xpcshell: vfprintf %s NULL in "%s: Resetting desktop app info dirs from %s
> > to %s"
> > gst-plugin-scanner: vfprintf %s NULL in "%s%s"
> >
> > (The last one was quite special because it was followed by "last message
> > repeated 44329 times", though looking at older logs that seems unusual).
>
> in messages log:
> first vfprintf entry starting at may 4th:
> firefox: vfprintf %s NULL in "%s: Resetting desktop app info dirs from %s to
> %s"
> a few times per day, all with firefox
>
> The first entry on may 4th was while updating packages, among them
> firefox. I still have a log of package update if anyone is interested.
That one is from a debug print in libgio-2,
glib-2.60.3/gio/gdesktopappinfo.c:
1484 /* If the XDG dirs configuration has changed (expected only during
tests),
1485* clear and reload the state. */
1486 if (g_strcmp0 (desktop_file_dirs_config_dir, user_config_dir) != 0)
1487 {
1488 g_debug ("%s: Resetting desktop app info dirs from %s to %s",
1489G_STRFUNC, desktop_file_dirs_config_dir, user_config_dir);
I'm not convinced syslogging this is doing much good ..
Re: "vfprintf %s NULL" during bulk build
On Wed, Jun 05, 2019 at 09:06:48PM +0100, Stuart Henderson wrote: > While reviewing syslog to look for realpath problems I noticed these, > in case anyone cares: > > GUPnPAV-1.0: vfprintf %s NULL in "URL: %s, ID: %s." > desktoptojson: vfprintf %s NULL in "Warning: %s (%s:%u, %s) " > mono: vfprintf %s NULL in "%s %2d %02d:%02d:%02d%.*s %d%s" > valac: vfprintf %s NULL in " value="%s"" > xpcshell: vfprintf %s NULL in "%s: Resetting desktop app info dirs from %s to > %s" > gst-plugin-scanner: vfprintf %s NULL in "%s%s" > > (The last one was quite special because it was followed by "last message > repeated 44329 times", though looking at older logs that seems unusual). in messages log: first vfprintf entry starting at may 4th: firefox: vfprintf %s NULL in "%s: Resetting desktop app info dirs from %s to %s" a few times per day, all with firefox The first entry on may 4th was while updating packages, among them firefox. I still have a log of package update if anyone is interested. Regards Markus
"vfprintf %s NULL" during bulk build
While reviewing syslog to look for realpath problems I noticed these, in case anyone cares: GUPnPAV-1.0: vfprintf %s NULL in "URL: %s, ID: %s." desktoptojson: vfprintf %s NULL in "Warning: %s (%s:%u, %s) " mono: vfprintf %s NULL in "%s %2d %02d:%02d:%02d%.*s %d%s" valac: vfprintf %s NULL in " value="%s"" xpcshell: vfprintf %s NULL in "%s: Resetting desktop app info dirs from %s to %s" gst-plugin-scanner: vfprintf %s NULL in "%s%s" (The last one was quite special because it was followed by "last message repeated 44329 times", though looking at older logs that seems unusual).
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2019/06/05 13:49:41 Modified files: devel : Makefile Log message: +py-cooldict +py-pefile
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2019/06/05 13:46:20 Log message: import py-cooldict-1.04 Small collection of useful dict-like structures. feedback & ok kn@ Status: Vendor Tag: jasper Release Tags: jasper_20190506 N ports/devel/py-cooldict/Makefile N ports/devel/py-cooldict/distinfo N ports/devel/py-cooldict/pkg/DESCR N ports/devel/py-cooldict/pkg/PLIST No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2019/06/05 13:44:18 Log message: import py-pefile-2018.8.8 pefile is a multi-platform Python module to parse and work with Portable Executable (aka PE) files. Most of the information contained in the PE headers is accessible as well as all sections' details and their data. ok kn@ Status: Vendor Tag: jasper Release Tags: jasper_20190506 N ports/devel/py-pefile/Makefile N ports/devel/py-pefile/distinfo N ports/devel/py-pefile/pkg/DESCR N ports/devel/py-pefile/pkg/PLIST No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2019/06/05 13:31:44 Modified files: net/p5-OSPF-LSDB: Makefile distinfo Log message: update p5-OSPF-LSDB to 1.11
Re: UPDATE: games/julius
On 5/27/19 10:51 AM, Brian Callahan wrote: Hi ports -- This is a simple update to games/julius. Sending a diff in case someone is clang smarter than me. Right now, the tests are compiled with the --coverage flag, which causes undefined symbol linker errors. I made a patch to remove the --coverage flag, but perhaps someone knows what library I need to link with to resolve the undefined symbol errors. ~Brian Ping. Or should I just go ahead since the diff doesn't affect the game at all, just people who want to run `make test' ~Brian
aarch64 bulk build report
bulk build on arm64.ports.openbsd.org started on Sun Jun 2 04:23:59 MDT 2019 finished at Wed Jun 5 12:29:14 MDT 2019 lasted 04D01h05m done with kern.version=OpenBSD 6.5-current (GENERIC.MP) #35: Sun Jun 2 02:36:40 MDT 2019 built packages:9862 Jun 2:3725 Jun 3:1281 Jun 4:1633 Jun 5:3222 critical path missing pkgs: http://build-failures.rhaalovely.net/aarch64/2019-06-02/summary.log build failures: 30 http://build-failures.rhaalovely.net/aarch64/2019-06-02/audio/chromaprint.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/comms/gnuradio.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/comms/lcdproc.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/devel/py-unicorn.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/devel/qbs.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/editors/texworks,-lua.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/editors/xwpe.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/editors/zile.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/games/frozen-bubble,-main.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/games/vacuum.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/geo/qlandkartegt.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/graphics/openimageio.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/graphics/openscenegraph.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/graphics/ufraw.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/lang/erlang/21.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/lang/guile2.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/lang/pfe.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/mail/kopano/core.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/misc/openbabel.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/security/aircrack-ng.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/www/chromium.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/www/w3m,image.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/x11/e17/elementary.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/x11/gnome/gjs.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/x11/gtk+4,-cloudprint.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/x11/kde4/kopete.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/x11/kde4/plasma-addons.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/x11/kde4/smokeqt.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/x11/kde4/zeroconf-ioslave.log http://build-failures.rhaalovely.net/aarch64/2019-06-02/x11/qt5/qt3d,,-main.log recurrent failures failures/audio/chromaprint.log failures/comms/gnuradio.log failures/comms/lcdproc.log failures/editors/xwpe.log failures/games/frozen-bubble,-main.log failures/games/vacuum.log failures/geo/qlandkartegt.log failures/graphics/openimageio.log failures/graphics/openscenegraph.log failures/graphics/ufraw.log failures/lang/pfe.log failures/mail/kopano/core.log failures/misc/openbabel.log failures/security/aircrack-ng.log failures/www/chromium.log failures/x11/e17/elementary.log failures/x11/gnome/gjs.log failures/x11/gtk+4,-cloudprint.log failures/x11/kde4/kopete.log failures/x11/kde4/zeroconf-ioslave.log failures/x11/qt5/qt3d,,-main.log new failures +++ ls-failures Wed Jun 5 12:34:03 2019 +failures/devel/py-unicorn.log +failures/devel/qbs.log +failures/editors/texworks,-lua.log +failures/editors/zile.log +failures/lang/erlang/21.log +failures/lang/guile2.log +failures/www/w3m,image.log +failures/x11/kde4/plasma-addons.log +failures/x11/kde4/smokeqt.log resolved failures --- ../old/aarch64/last//ls-failuresThu May 30 21:43:51 2019 -failures/devel/libcoap.log -failures/geo/mapserver,-main.log -failures/net/gtk-gnutella.log -failures/telephony/asterisk,imap,-calendar.log -failures/x11/gnome/builder.log
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2019/06/05 12:31:50 Modified files: www/chromium : Makefile distinfo Log message: update to 75.0.3770.80; this brings us back to the stable channel again
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2019/06/05 08:27:02 Modified files: sysutils/telegraf: Makefile sysutils/telegraf/pkg: telegraf.rc Log message: log telegraf output to syslog, as done for influxdb. from Joel Carnat.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rpoin...@cvs.openbsd.org2019/06/05 08:23:18 Modified files: math/z3: Makefile Log message: use GH_TAGNAME, spotted by sthen@. ok sthen@.
Re: [UPDATE] math/z3
On 2019/06/05 16:10, Remi Pointel wrote:
> > The GH_* stuff in this is broken. If GH_ACCOUNT and GH_PROJECT are
> > present there should always be GH_TAGNAME or GH_COMMIT.
>
> Exactly, attached is the diff using GH_TAGNAME.
>
> I need to set DISTNAME because by default "DISTNAME =
> ${GH_PROJECT}-${GH_TAGNAME:C/^v//}" and PKGNAME because the upper Z of the
> tag of this release.
>
> Ok?
>
> Cheers,
>
> Remi.
> Index: Makefile
> ===
> RCS file: /cvs/ports/math/z3/Makefile,v
> retrieving revision 1.14
> diff -u -p -u -p -r1.14 Makefile
> --- Makefile 5 Jun 2019 05:44:54 - 1.14
> +++ Makefile 5 Jun 2019 13:58:28 -
> @@ -3,11 +3,13 @@
> COMMENT =Z3 theorem prover
>
> VERSION =4.8.5
> -DISTNAME = Z3-${VERSION}
> -PKGNAME =${DISTNAME:L}
>
> GH_ACCOUNT = Z3Prover
> GH_PROJECT = z3
> +GH_TAGNAME = ${GH_PROJECT:U}-${VERSION}
> +
> +DISTNAME = ${GH_TAGNAME}
> +PKGNAME =${DISTNAME:L}
>
> SHARED_LIBS =z3 2.0 # 4.8
>
Thanks, OK.
Re: [UPDATE] math/z3
The GH_* stuff in this is broken. If GH_ACCOUNT and GH_PROJECT are
present there should always be GH_TAGNAME or GH_COMMIT.
Exactly, attached is the diff using GH_TAGNAME.
I need to set DISTNAME because by default "DISTNAME =
${GH_PROJECT}-${GH_TAGNAME:C/^v//}" and PKGNAME because the upper Z of
the tag of this release.
Ok?
Cheers,
Remi.
Index: Makefile
===
RCS file: /cvs/ports/math/z3/Makefile,v
retrieving revision 1.14
diff -u -p -u -p -r1.14 Makefile
--- Makefile 5 Jun 2019 05:44:54 - 1.14
+++ Makefile 5 Jun 2019 13:58:28 -
@@ -3,11 +3,13 @@
COMMENT = Z3 theorem prover
VERSION = 4.8.5
-DISTNAME = Z3-${VERSION}
-PKGNAME = ${DISTNAME:L}
GH_ACCOUNT = Z3Prover
GH_PROJECT = z3
+GH_TAGNAME = ${GH_PROJECT:U}-${VERSION}
+
+DISTNAME = ${GH_TAGNAME}
+PKGNAME = ${DISTNAME:L}
SHARED_LIBS = z3 2.0 # 4.8
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/06/05 07:26:58 Modified files: www/py-httpie : Makefile www/py-httpie/pkg: PLIST Log message: in lieu of a proper manpage, install httpie's README.rst, it has fairly sophisticated support for POSTs etc which is and it isn't clear from "http -h" how to use it all. ok Paco Esteban (maintainer)
Re: [update] www/py-httpie
On Wed, 05 Jun 2019, Stuart Henderson wrote: > Committed. Thanks ! > Since there is no manpage, ok to add this? > ... It makes sense. The "guide" is pretty comprehensive. Pitty that's not a proper man page. Cheers, -- Paco Esteban. https://onna.be/gpgkey.asc 9A6B 6083 AD9E FDC2 0EAF 5CB3 5818 130B 8A6D BC03
net/megatools: unbreak on gcc archs
Hi, there have been attempts to unbreak megatools on gcc archs by forcing C99 mode but this is not enough. -std=c99 disables some extensions used by this port, namely anonymous unions. -std=gnu99 helps getting past that, but linking then fails because the code uses _Static_assert from C11. So here's a diff to force the use of base-clang or ports-gcc; both default to -std=gnu11. Drop our only patch while here. ok? Index: Makefile === RCS file: /cvs/ports/net/megatools/Makefile,v retrieving revision 1.17 diff -u -p -r1.17 Makefile --- Makefile19 Dec 2018 08:21:44 - 1.17 +++ Makefile5 Jun 2019 12:52:05 - @@ -5,7 +5,7 @@ PORTROACH = limit:[0-9]\.tar\.gz COMMENT = command line client application for Mega DISTNAME = megatools-1.10.2 -REVISION = 1 +REVISION = 2 CATEGORIES = net @@ -21,6 +21,7 @@ WANTLIB += ssl MASTER_SITES = https://megatools.megous.com/builds/ +COMPILER = base-clang ports-gcc BUILD_DEPENDS =devel/gobject-introspection \ textproc/asciidoc LIB_DEPENDS = devel/glib2 \ @@ -31,8 +32,6 @@ CONFIGURE_STYLE = gnu MAKE_FLAGS = VERBOSE=1 CONFIGURE_ARGS = --disable-introspection - -CFLAGS += -std=c99 SEPARATE_BUILD = Yes Index: patches/patch-Makefile_in === RCS file: patches/patch-Makefile_in diff -N patches/patch-Makefile_in --- patches/patch-Makefile_in 27 Oct 2018 07:32:57 - 1.1 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,17 +0,0 @@ -$OpenBSD: patch-Makefile_in,v 1.1 2018/10/27 07:32:57 bentley Exp $ - -Build in C99 mode. From upstream 5acf268ba4e3df7fb7ebcab5bfef0a5a986fef8c. - -Index: Makefile.in Makefile.in.orig -+++ Makefile.in -@@ -408,7 +408,8 @@ AM_CFLAGS = \ - $(LIBCURL_CFLAGS) \ - -DG_LOG_DOMAIN=\"Mega\" \ - -I$(srcdir)/lib \ -- -I$(srcdir) -+ -I$(srcdir) \ -+ -std=c99 - - - # }}} -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/06/05 06:54:03 Modified files: games/gargoyle : Makefile distinfo games/gargoyle/patches: patch-Jamrules patch-garglk_launchgtk_c patch-tads_Jamfile games/gargoyle/pkg: PLIST Removed files: games/gargoyle/patches: patch-garglk_Jamfile patch-garglk_glk_h patch-terps_bocfel_process_h Log message: update gargoyle to a newer git checkout (there hasn't been a release since 2011, but it still receives occasional commits). unbreaks sdl audio so reenable that, also unbreaks build with ports-gcc.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: j...@cvs.openbsd.org2019/06/05 06:38:56
Modified files:
mail/opensmtpd-extras: Makefile
Log message:
Drop COMPILER to unbreak on sparc64 and other gcc archs
The way WANTLIB* and LIB_DEPENDS were set up, ${COMPILER_LIBCXX} ended
up in WANTLIB-main without gcc-libs ending up in LIB_DEPENDS-main;
pkg_create then failed because it had no way to reach a package
providing libestdc++. This kind of breakage had been spotted in several
ports after switching the C++ ports to "COMPILER = base-clang
ports-gcc". I'm not sure yet how these problems could be avoided.
Maybe additional checks in portcheck(1)?
Anyway, opensmtpd-extras was mechanically switched to COMPILER because
WANTLIB-mysql contained ${COMPILER_LIBCXX}. This is currently not
needed, and since opensmtpd-extras is a C-only port, let's just drop
COMPILER.
ok sthen@ giovanni@ (maintainer)
Re: [NEW] net/dnscontrol 2.9
Thanks, it's committed.
On 2019/06/04 16:41, Klemens Nanni wrote:
> On Tue, Jun 04, 2019 at 12:00:46PM +0100, Stuart Henderson wrote:
> > Ah thanks, that's much tidier.
> Yes, but `do-install' wasn't quite right. Attached is a version that
> actually works (with wxallowed /tmp/): builds, installs and tests fine.
>
> > There's no restriction on writing to /tmp during builds, all sorts of
> > things will break if that is blocked.
> >
> > Seems go does this as standard, so it's probably a good idea to figure
> > out how to tell it to place the go-build directory inside WRKDIR (maybe
> > it's possible to use WRKBUILD) but that said, it shouldn't block an
> > individual port when pretty much all the go ports in-tree already do
> > this.
> Yeah, we can try this in a different diff.
>
> Also, simply setting SEPARATE_BUILD=no will also break, so leaving this
> untouched as well.
>
> OK kn
> # $OpenBSD$
>
> COMMENT = manage DNS configuration across any number of DNS hosts
>
> GH_ACCOUNT = StackExchange
> GH_PROJECT = dnscontrol
> GH_TAGNAME = v2.9
>
> CATEGORIES = net
>
> HOMEPAGE =https://stackexchange.github.io/dnscontrol/
>
> # MIT
> PERMIT_PACKAGE = Yes
>
> WANTLIB = c pthread
>
> MODULES = lang/go
>
> MODGO_FLAGS +=-tags nosystemd
> MODGO_TEST_FLAGS += -provider BIND
>
> do-build:
> cd ${WRKSRC} && ${MODGO_CMD} generate
> cd ${WRKSRC} && ${MODGO_CMD} build
> cd ${WRKSRC}/cmd/convertzone && ${MODGO_CMD} build
>
> do-install:
> ${INSTALL_PROGRAM} ${WRKSRC}/dnscontrol ${PREFIX}/bin/
> ${INSTALL_PROGRAM} ${WRKSRC}/cmd/convertzone/convertzone ${PREFIX}/bin/
>
> do-test:
> cd ${WRKSRC}/integrationTest && ${MODGO_TEST_CMD}
>
> .include
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/06/05 05:43:48 Modified files: net: Makefile Log message: +dnscontrol
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/06/05 05:43:21 Log message: import net/dnscontrol, from Karlis Mikelsons, much tidying and ok from kn@ DNSControl is a system for maintaining DNS zones. It has two parts: a domain specific language (DSL) for describing DNS zones plus software that processes the DSL and pushes the resulting zones to DNS providers such as Route53, CloudFlare, and Gandi. It can talk to Microsoft ActiveDirectory and it generates the most beautiful BIND zone files ever. Status: Vendor Tag: sthen Release Tags: sthen_20190605 N ports/net/dnscontrol/Makefile N ports/net/dnscontrol/distinfo N ports/net/dnscontrol/pkg/DESCR N ports/net/dnscontrol/pkg/PLIST No conflicts created by this import
Re: [update] www/py-httpie
On 2019/05/08 14:50, Paco Esteban wrote:
> Hi ports@,
>
> Here's a diff to update www/py-httpie to its latest version 1.0.2
> Changes since the actual version on ports (0.9.8) are:
>
> * Fixed tests for installation with pyOpenSSL.
> * Removed external URL calls from tests.
> * Added --style=auto which follows the terminal ANSI color styles.
> * Added support for selecting TLS 1.3 via --ssl=tls1.3 (available once
> implemented in upstream libraries).
> * Added true/false as valid values for --verify (in addition to yes/no) and
> the boolean value is case-insensitive.
> * Changed the default --style from solarized to auto (on Windows it stays
> fruity).
> * Fixed default headers being incorrectly case-sensitive.
> * Removed Python 2.6 support.
> * Fixed README.
>
> I would also like to take maintainership of this port if that's ok.
Committed.
Since there is no manpage, ok to add this?
Index: Makefile
===
RCS file: /cvs/ports/www/py-httpie/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- Makefile5 Jun 2019 11:27:51 - 1.13
+++ Makefile5 Jun 2019 11:29:11 -
@@ -3,6 +3,7 @@
COMMENT = command-line HTTP client
MODPY_EGG_VERSION =1.0.2
+REVISION = 0
GH_TAGNAME = ${MODPY_EGG_VERSION}
GH_ACCOUNT = jkbrzt
GH_PROJECT = httpie
@@ -32,5 +33,9 @@ pre-test:
# check for docutils presence then calls rst2pseudoxml.py
# our docutils installs rst2pseudoxml
rm ${WRKSRC}/tests/test_docs.py
+
+post-install:
+ ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/httpie
+ ${INSTALL_DATA} ${WRKSRC}/README.rst ${PREFIX}/share/doc/httpie/
.include
Index: pkg/PLIST
===
RCS file: /cvs/ports/www/py-httpie/pkg/PLIST,v
retrieving revision 1.4
diff -u -p -r1.4 PLIST
--- pkg/PLIST 5 Jun 2019 11:27:51 - 1.4
+++ pkg/PLIST 5 Jun 2019 11:29:11 -
@@ -63,3 +63,5 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/httpie/plugins/manager.py
lib/python${MODPY_VERSION}/site-packages/httpie/sessions.py
lib/python${MODPY_VERSION}/site-packages/httpie/utils.py
+share/doc/httpie/
+share/doc/httpie/README.rst
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/06/05 05:27:51 Modified files: www/py-httpie : Makefile distinfo www/py-httpie/pkg: PLIST Log message: update to httpie-1.0.2, from Paco Esteban, taking maintainer (plus regen plist)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/06/05 05:21:56 Modified files: productivity/khard: Makefile distinfo productivity/khard/pkg: PLIST Log message: update to khard-0.13.0, from Paco Esteban (taking maintainer), minor tweaks from me (whitespace, regen plist)
Re: [update] www/py-httpie
Ping !
Anyone using httpie ?
On Wed, 22 May 2019, Paco Esteban wrote:
> Ping !
>
> On Wed, 08 May 2019, Paco Esteban wrote:
>
> > Hi ports@,
> >
> > Here's a diff to update www/py-httpie to its latest version 1.0.2
> > Changes since the actual version on ports (0.9.8) are:
> >
> > * Fixed tests for installation with pyOpenSSL.
> > * Removed external URL calls from tests.
> > * Added --style=auto which follows the terminal ANSI color styles.
> > * Added support for selecting TLS 1.3 via --ssl=tls1.3 (available once
> > implemented in upstream libraries).
> > * Added true/false as valid values for --verify (in addition to yes/no) and
> > the boolean value is case-insensitive.
> > * Changed the default --style from solarized to auto (on Windows it stays
> > fruity).
> > * Fixed default headers being incorrectly case-sensitive.
> > * Removed Python 2.6 support.
> > * Fixed README.
> >
> > I would also like to take maintainership of this port if that's ok.
> >
> > Cheers,
> > Paco.
> >
> >
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/www/py-httpie/Makefile,v
> > retrieving revision 1.11
> > diff -u -p -u -r1.11 Makefile
> > --- Makefile28 Apr 2019 20:51:59 - 1.11
> > +++ Makefile8 May 2019 12:45:10 -
> > @@ -2,16 +2,16 @@
> >
> > COMMENT = command-line HTTP client
> >
> > -MODPY_EGG_VERSION =0.9.8
> > +MODPY_EGG_VERSION =1.0.2
> > GH_TAGNAME = ${MODPY_EGG_VERSION}
> > GH_ACCOUNT = jkbrzt
> > GH_PROJECT = httpie
> > DISTNAME = httpie-${MODPY_EGG_VERSION}
> > -REVISION = 0
> >
> > CATEGORIES = www net
> >
> > -HOMEPAGE = http://httpie.org
> > +HOMEPAGE = https://httpie.org
> > +MAINTAINER = Paco Esteban
> >
> > # BSD
> > PERMIT_PACKAGE_CDROM = Yes
> > Index: distinfo
> > ===
> > RCS file: /cvs/ports/www/py-httpie/distinfo,v
> > retrieving revision 1.5
> > diff -u -p -u -r1.5 distinfo
> > --- distinfo2 May 2017 07:24:25 - 1.5
> > +++ distinfo8 May 2019 12:45:10 -
> > @@ -1,2 +1,2 @@
> > -SHA256 (httpie-0.9.8.tar.gz) = XMxl3Y5gqTEPV1walgDzzH2vhwTMiL9sQBGLNlm5jcc=
> > -SIZE (httpie-0.9.8.tar.gz) = 268608
> > +SHA256 (httpie-1.0.2.tar.gz) = 8R9ezbzAVxqoZfspzV22i6a85PFaWq4/J6MtGbCFTck=
> > +SIZE (httpie-1.0.2.tar.gz) = 765210
> >
> > --
> > Paco Esteban.
> > https://onna.be/gpgkey.asc
> > 9A6B 6083 AD9E FDC2 0EAF 5CB3 5818 130B 8A6D BC03
> >
>
> --
> Paco Esteban.
> https://onna.be/gpgkey.asc
> 9A6B 6083 AD9E FDC2 0EAF 5CB3 5818 130B 8A6D BC03
>
--
Paco Esteban.
https://onna.be/gpgkey.asc
9A6B 6083 AD9E FDC2 0EAF 5CB3 5818 130B 8A6D BC03
Re: [update] productivity/khard
Ping !
Anyone using khard ?
On Wed, 22 May 2019, Paco Esteban wrote:
> Ping !
>
> On Wed, 08 May 2019, Paco Esteban wrote:
>
> > Hi ports@,
> >
> > Here's a diff to update khard to its latest version 0.13.0
> > Directly from changelog:
> >
> > v0.13.0: 2018-12-25
> > - New action postaddress: lists all postal (addresses analog to email and
> > phone actions, #196)
> > - New zsh completion function for email addresses
> > - New config variables for the contact table section in khard.conf:
> > preferred_email_address_type and preferred_phone_number_type
> > - Slight speed improvements
> > - Test suite created
> > - Several bug fixes
> >
> > There are tests now, so I removed the NO_TEST and added MODPY_TEST.
> > They all pass with make test.
> >
> > I put the zsh completion on ${PREFIX}/share/zsh/vendor-completions as I
> > have seen that sysutils/google-cloud-sdk and other do the same.
> >
> > Finally, I don't mind to take maintainership of this port too.
> >
> > Cheers,
> > Paco.
> >
> >
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/productivity/khard/Makefile,v
> > retrieving revision 1.2
> > diff -u -p -u -r1.2 Makefile
> > --- Makefile28 Apr 2019 20:51:46 - 1.2
> > +++ Makefile8 May 2019 18:48:57 -
> > @@ -2,13 +2,13 @@
> >
> > COMMENT = console CardDAV client
> >
> > -MODPY_EGG_VERSION =0.12.2
> > +MODPY_EGG_VERSION =0.13.0
> > DISTNAME = khard-${MODPY_EGG_VERSION}
> > -REVISION = 0
> >
> > CATEGORIES = productivity
> >
> > HOMEPAGE = https://github.com/scheibler/khard
> > +MAINTAINER = Paco Esteban
> >
> > # GPLv3
> > PERMIT_PACKAGE_CDROM = Yes
> > @@ -18,6 +18,7 @@ MODULES = lang/python
> > MODPY_PI = Yes
> > MODPY_SETUPTOOLS = Yes
> > MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}
> > +MODPY_TEST = Yes
> >
> > RUN_DEPENDS = devel/py-atomicwrites${MODPY_FLAVOR} \
> > devel/py-configobj${MODPY_FLAVOR} \
> > @@ -25,11 +26,12 @@ RUN_DEPENDS = devel/py-atomicwrites${MO
> > textproc/py-unidecode${MODPY_FLAVOR} \
> > textproc/py-vobject${MODPY_FLAVOR}
> >
> > -NO_TEST = Yes
> > -
> > post-install:
> > ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/khard
> > ${INSTALL_DATA} ${WRKSRC}/misc/khard/khard.conf.example \
> > ${PREFIX}/share/examples/khard
> > + ${INSTALL_DATA_DIR} ${PREFIX}/share/zsh/vendor-completions
> > + ${INSTALL_DATA} ${WRKSRC}/misc/zsh/{_khard,_email-khard} \
> > + ${PREFIX}/share/zsh/vendor-completions
> >
> > .include
> > Index: distinfo
> > ===
> > RCS file: /cvs/ports/productivity/khard/distinfo,v
> > retrieving revision 1.1.1.1
> > diff -u -p -u -r1.1.1.1 distinfo
> > --- distinfo1 Oct 2018 10:37:58 - 1.1.1.1
> > +++ distinfo8 May 2019 18:48:57 -
> > @@ -1,2 +1,2 @@
> > -SHA256 (khard-0.12.2.tar.gz) =
> > 9193d2d07cdb69cc6e35a0732111efb92bbfba854a1dd42b4f9c91a52a16c507
> > -SIZE (khard-0.12.2.tar.gz) = 5064055
> > +SHA256 (khard-0.13.0.tar.gz) = /JPQuR9+aIqPYIlrT/exlo1rTLWNgPypl3Iyw6aO0tM=
> > +SIZE (khard-0.13.0.tar.gz) = 5083020
> > Index: pkg/PLIST
> > ===
> > RCS file: /cvs/ports/productivity/khard/pkg/PLIST,v
> > retrieving revision 1.1.1.1
> > diff -u -p -u -r1.1.1.1 PLIST
> > --- pkg/PLIST 1 Oct 2018 10:37:58 - 1.1.1.1
> > +++ pkg/PLIST 8 May 2019 18:48:57 -
> > @@ -31,3 +31,7 @@ lib/python${MODPY_VERSION}/site-packages
> > lib/python${MODPY_VERSION}/site-packages/khard/version.py
> > share/examples/khard/
> > share/examples/khard/khard.conf.example
> > +share/zsh/
> > +share/zsh/vendor-completions/
> > +share/zsh/vendor-completions/_email-khard
> > +share/zsh/vendor-completions/_khard
> >
> > --
> > Paco Esteban.
> > https://onna.be/gpgkey.asc
> > 9A6B 6083 AD9E FDC2 0EAF 5CB3 5818 130B 8A6D BC03
> >
>
> --
> Paco Esteban.
> https://onna.be/gpgkey.asc
> 9A6B 6083 AD9E FDC2 0EAF 5CB3 5818 130B 8A6D BC03
>
--
Paco Esteban.
https://onna.be/gpgkey.asc
9A6B 6083 AD9E FDC2 0EAF 5CB3 5818 130B 8A6D BC03
Re: mail/opensmtpd-extras: drop COMPILER and unbreak on gcc archs
On 6/5/19 12:53 PM, Stuart Henderson wrote:
> On 2019/06/05 01:50, Jeremie Courreges-Anglas wrote:
>>
>> opensmtpd-extras fails to package on sparc64:
>>
>>
>> http://build-failures.rhaalovely.net//sparc64/2019-05-14/mail/opensmtpd-extras%2C-main.log
>>
>> The problem is that ${COMPILER_LIBCXX} (libestdc++) is added
>> automatically to WANTLIB but gcc-libs isn't registered in
>> LIB_DEPENDS-main, so pkg_create rightfully complains.
>>
>> The weird thing is that opensmtpd-extras is a C-only port, it builds
>> just fine on sparc64 using base-gcc. I don't know why the -mysql
>> subpackage had ${COMPILER_LIBCXX} in WANTLIB. Maybe because of the dep
>> on a previous libmysqlclient? make port-lib-depends-check/repackage
>> says it is not needed any more, and COMPILER isn't needed either.
>>
>> So, ok for the diff below?
>
> OK. Yes that is exactly why it had ${COMPILER_LIBCXX}.
>
ok for me as well.
Giovanni
Re: [UPDATE] math/z3
On 2019/06/04 14:45, Remi Pointel wrote:
> Hi,
>
> this diff updates z3 to latest release.
>
> Ok?
>
> Cheers,
>
> Remi.
> Index: Makefile
> ===
> RCS file: /cvs/ports/math/z3/Makefile,v
> retrieving revision 1.13
> diff -u -p -u -p -r1.13 Makefile
> --- Makefile 28 Apr 2019 20:51:42 - 1.13
> +++ Makefile 4 Jun 2019 12:45:10 -
> @@ -2,14 +2,14 @@
>
> COMMENT =Z3 theorem prover
>
> -VERSION =4.8.4
> -DISTNAME = z3-${VERSION}
> -REVISION = 1
> +VERSION =4.8.5
> +DISTNAME = Z3-${VERSION}
> +PKGNAME =${DISTNAME:L}
>
> GH_ACCOUNT = Z3Prover
> GH_PROJECT = z3
The GH_* stuff in this is broken. If GH_ACCOUNT and GH_PROJECT are
present there should always be GH_TAGNAME or GH_COMMIT.
Re: mail/opensmtpd-extras: drop COMPILER and unbreak on gcc archs
On 2019/06/05 01:50, Jeremie Courreges-Anglas wrote:
>
> opensmtpd-extras fails to package on sparc64:
>
>
> http://build-failures.rhaalovely.net//sparc64/2019-05-14/mail/opensmtpd-extras%2C-main.log
>
> The problem is that ${COMPILER_LIBCXX} (libestdc++) is added
> automatically to WANTLIB but gcc-libs isn't registered in
> LIB_DEPENDS-main, so pkg_create rightfully complains.
>
> The weird thing is that opensmtpd-extras is a C-only port, it builds
> just fine on sparc64 using base-gcc. I don't know why the -mysql
> subpackage had ${COMPILER_LIBCXX} in WANTLIB. Maybe because of the dep
> on a previous libmysqlclient? make port-lib-depends-check/repackage
> says it is not needed any more, and COMPILER isn't needed either.
>
> So, ok for the diff below?
OK. Yes that is exactly why it had ${COMPILER_LIBCXX}.
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/mail/opensmtpd-extras/Makefile,v
> retrieving revision 1.26
> diff -u -p -r1.26 Makefile
> --- Makefile 24 Nov 2018 11:27:49 - 1.26
> +++ Makefile 4 Jun 2019 23:34:25 -
> @@ -14,6 +14,7 @@ PKGNAME-pgsql= opensmtpd-extras-pgsql-$
> PKGNAME-python= opensmtpd-extras-python-${V}
> PKGNAME-redis= opensmtpd-extras-redis-${V}
> EPOCH= 0
> +REVISION=0
>
> CATEGORIES= mail
>
> @@ -27,13 +28,11 @@ MULTI_PACKAGES= -main -mysql -pgsql -py
> # BSD
> PERMIT_PACKAGE_CDROM=Yes
>
> -WANTLIB= c crypto event m pthread ssl sqlite3 z
> -WANTLIB-mysql= c crypto event ssl m pthread ${COMPILER_LIBCXX}
> mysqlclient
> +WANTLIB-main=c crypto event m pthread ssl sqlite3 z
> +WANTLIB-mysql= c crypto event iconv ssl m pthread mysqlclient z
> WANTLIB-pgsql= c crypto event ssl pq
> WANTLIB-python= c crypto event ssl m util pthread
> ${MODPY_WANTLIB}
> WANTLIB-redis= c crypto event ssl hiredis
> -
> -COMPILER = base-clang ports-gcc base-gcc
>
> MASTER_SITES=${HOMEPAGE}archives/
>
>
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ben...@cvs.openbsd.org 2019/06/05 01:17:29 Modified files: net/p5-Net-SFTP-Foreign: Makefile distinfo Log message: Update to p5-Net-SFTP-Foreign-1.90.
