Re: [NEW] (ping) slant-0.0.17
> BUILD_DEPENDS=STEM->=0.6.9:www/kwebapp www/kcgi databases/ksql > kcgi and ksql are RDEPS of kwebapp already, so this seems redundant. > > update-plist moves slant-cgi at the end of PLIST. > > port-lib-depends-check reports "curses tls z" as missing. Enclosed fixes these. However, update-plist puts slant-cgi *after* the @exec, but the @exec changes mode on the now-subsequent @bin. Since pkg_create says that exec can't rely on anything after, I put the exec last. slant-0.0.17p0.tgz Description: Binary data
Re: change in devel/cargo module
On Sat, Dec 15, 2018 at 09:26:04AM +0100, Sebastien Marie wrote: > Hi, > > In order to support crates with a '-' in the version (like > "mime_guess-2.0.0-alpha.6"), I need to change devel/cargo module in the > way MODCARGO_CRATES is managed. > > Basically, it changes the 'syntax' like that: > > -MODCARGO_CRATES += aho-corasick-0.6.8 # Unlicense/MIT > +MODCARGO_CRATES += aho-corasick0.6.8 # Unlicense/MIT > > This way, the separation between "crate_name" and "crate_version" is > unambigious. Previously, I just assumed '-' couldn't be present in > version, but it seems I was wrong. > > Changing devel/cargo module, imply changing also customers of the > module: > - devel/cbindgen > - sysutils/exa > - textproc/ripgrep > - www/geckodriver > > The diff belows integrate devel/cargo change and take care of all of > customers. > > REVISION isn't bumped for any port as it changes only the way the > variable is used, but not anything else. So extracted files will be the > same. Reads good, okay
htop off-by-one upstream patch
Hi, A few days ago, I noticed htop crashes sometimes on my system (OpenBSD 6.4), whether it’s coming from the port or built from the upstream source. The port version is more stable but still crashes sometimes at start. I can easily reproduce the issue with the following one-liner: while ( (sleep 0.1 && echo 'q') | htop ); do false; done The loop stops after a few seconds or minutes with a core dump. I fixed the off-by-one error causing the bug in the following patch I submitted to upstream. I’m pretty much new in the OpenBSD world, so reviews and comments from experienced OpenBSD people are highly appreciated. HTML page for web browsers: https://github.com/hishamhm/htop/pull/868 Raw text patch: https://patch-diff.githubusercontent.com/raw/hishamhm/htop/pull/868.patch Regards, Antoine
Re: lang/rust: add clippy and rustfmt subpackages
On Sat, Dec 15, 2018 at 10:37:30AM +0100, Sebastien Marie wrote: > Hi, > > The latest update of lang/rust (1.31) has stabilized clippy (linter) and > rustfmt (code formatter) and there are included in the rustc tarball > (there are strongly linked to rustc internals). > > The diff below enable the compilation of them (it added 20min build > time on my test - amd64 / 4 cores), and package them as subpackages. > > While here, I also packaged rust-gdb as a subpackage, in order to have > devel/gdb as RDEP only for it when installed. Currently, rust-lldb isn't > packaged as testsuite told me it doesn't work. It could be revisited > later. > > REVISION bumped on -main, as rust-gdb script moved to another > subpackage. Looks good with one minor nit: > === > RCS file: pkg/PLIST-clippy > diff -N pkg/PLIST-clippy > --- /dev/null 1 Jan 1970 00:00:00 - > +++ pkg/PLIST-clippy 15 Dec 2018 09:23:03 - > @@ -0,0 +1,7 @@ > +@comment $OpenBSD: PLIST-clippy,v$ > +@bin bin/cargo-clippy > +@bin bin/clip${MODPY_PY_PREFIX}driver ^^ Not sure your want that :)
Re: lang/rust: add clippy and rustfmt subpackages
Thanks for including these but a possibly dumb question. Why subpackages for clippy and rustfmt and not part of the standard rust installation like upstream? If REVISION is bumped anyways for rust-gdb will it still cause issues with other ports or installations? -- Edward Lopez-Acosta
Re: devel/apr: apr_off_t (long long) vs APR_OFF_T_FMT ("ld")
On 2018-12-16, Stefan Sperling wrote: > APR's configure script figures out that off_t is 'long long' on > OpenBSD but at the same time sets APR_OFF_T_FMT to "ld". That sounds like a generic problem that should be fixed generically... > I suspect we should add OS-specific overrides to APR's configure script. ... rather than using OS overrides. *Looks into apr configure script* Sigh. Unfortunately this is all based on sizeof(type1)==sizeof(type2) rather than type1 and type2 being the same. > The patch below does this and fixes the above error. Am I right that this > is what the script should be doing for all OpenBSD architectures? Yes. off_t is long long on all our archs. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: devel/apr: apr_off_t (long long) vs APR_OFF_T_FMT ("ld")
On Sun, Dec 16, 2018 at 03:57:40PM -, Christian Weisgerber wrote: > On 2018-12-16, Stefan Sperling wrote: > > > APR's configure script figures out that off_t is 'long long' on > > OpenBSD but at the same time sets APR_OFF_T_FMT to "ld". > > That sounds like a generic problem that should be fixed generically... > > > I suspect we should add OS-specific overrides to APR's configure script. > > ... rather than using OS overrides. I am kind of afraid that they will say their existing order of checks is intended and that we should add an OS override. Another possible fix for us would be to move the check for 'long long' before the one for 'long' (see below) but I don't know what upstream would say about that. > *Looks into apr configure script* > Sigh. Unfortunately this is all based on sizeof(type1)==sizeof(type2) > rather than type1 and type2 being the same. Yeah it's quite horrible. > > The patch below does this and fixes the above error. Am I right that this > > is what the script should be doing for all OpenBSD architectures? > > Yes. off_t is long long on all our archs. Good to know. Index: configure.in === --- configure.in(revision 1849023) +++ configure.in(working copy) @@ -1613,15 +1613,6 @@ if test "$ac_cv_sizeof_int" = "8"; then int64_value="int" long_value=int int64_strfn="strtoi" -elif test "$ac_cv_sizeof_long" = "8"; then -int64_literal='#define APR_INT64_C(val) (val##L)' -uint64_literal='#define APR_UINT64_C(val) (val##UL)' -int64_t_fmt='#define APR_INT64_T_FMT "ld"' -uint64_t_fmt='#define APR_UINT64_T_FMT "lu"' -uint64_t_hex_fmt='#define APR_UINT64_T_HEX_FMT "lx"' -int64_value="long" -long_value=long -int64_strfn="strtol" elif test "$ac_cv_sizeof_long_long" = "8"; then int64_literal='#define APR_INT64_C(val) (val##LL)' uint64_literal='#define APR_UINT64_C(val) (val##ULL)' @@ -1635,6 +1626,15 @@ elif test "$ac_cv_sizeof_long_long" = "8"; then int64_value="long long" long_value="long long" int64_strfn="strtoll" +elif test "$ac_cv_sizeof_long" = "8"; then +int64_literal='#define APR_INT64_C(val) (val##L)' +uint64_literal='#define APR_UINT64_C(val) (val##UL)' +int64_t_fmt='#define APR_INT64_T_FMT "ld"' +uint64_t_fmt='#define APR_UINT64_T_FMT "lu"' +uint64_t_hex_fmt='#define APR_UINT64_T_HEX_FMT "lx"' +int64_value="long" +long_value=long +int64_strfn="strtol" elif test "$ac_cv_sizeof_longlong" = "8"; then int64_literal='#define APR_INT64_C(val) (val##LL)' uint64_literal='#define APR_UINT64_C(val) (val##ULL)' @@ -1847,15 +1847,15 @@ elif test "$ac_cv_type_off_t" = "yes"; then off_t_size="$ac_cv_sizeof_off_t" # off_t is more commonly a long than an int; prefer that case # where int and long are the same size. -if test "$ac_cv_sizeof_off_t" = "$ac_cv_sizeof_long"; then +if test "$ac_cv_sizeof_off_t" = "$ac_cv_sizeof_long_long"; then +off_t_fmt='#define APR_OFF_T_FMT APR_INT64_T_FMT' +off_t_strfn='apr_strtoi64' +elif test "$ac_cv_sizeof_off_t" = "$ac_cv_sizeof_long"; then off_t_fmt='#define APR_OFF_T_FMT "ld"' off_t_strfn='strtol' elif test "$ac_cv_sizeof_off_t" = "$ac_cv_sizeof_int"; then off_t_fmt='#define APR_OFF_T_FMT "d"' off_t_strfn='strtoi' -elif test "$ac_cv_sizeof_off_t" = "$ac_cv_sizeof_long_long"; then -off_t_fmt='#define APR_OFF_T_FMT APR_INT64_T_FMT' -off_t_strfn='apr_strtoi64' else AC_ERROR([could not determine the size of off_t]) fi
devel/apr: apr_off_t (long long) vs APR_OFF_T_FMT ("ld")
APR's configure script figures out that off_t is 'long long' on OpenBSD but at the same time sets APR_OFF_T_FMT to "ld". This results in a build failure when I try to compile httpd-2.4.37: /home/stsp/svn/src/httpd-2.4.37/server/util_expr_eval.c:1144:56: error: format specifies type 'long' but the argument has type 'apr_off_t' (aka 'long long') [-Werror,-Wformat] return apr_psprintf(ctx->p, "%" APR_OFF_T_FMT, sb.size); ~~~ ^~~ I suspect we should add OS-specific overrides to APR's configure script. The patch below does this and fixes the above error. Am I right that this is what the script should be doing for all OpenBSD architectures? If we decide to patch our port of APR like this, then I will submit my patch upstream as well. Ports which depend on APR would probably need a bump, correct? Index: Makefile === RCS file: /cvs/ports/devel/apr/Makefile,v retrieving revision 1.42 diff -u -p -r1.42 Makefile --- Makefile25 Oct 2017 19:36:46 - 1.42 +++ Makefile16 Dec 2018 12:00:54 - @@ -4,7 +4,7 @@ COMMENT=Apache Portable Runtime V= 1.6.3 DISTNAME= apr-$V -REVISION= 0 +REVISION= 1 SHARED_LIBS += apr-1 6.0 # .6.2 CATEGORIES=devel Index: patches/patch-configure_in === RCS file: /cvs/ports/devel/apr/patches/patch-configure_in,v retrieving revision 1.1 diff -u -p -r1.1 patch-configure_in --- patches/patch-configure_in 25 Oct 2017 19:36:46 - 1.1 +++ patches/patch-configure_in 16 Dec 2018 12:00:16 - @@ -1,9 +1,37 @@ $OpenBSD: patch-configure_in,v 1.1 2017/10/25 19:36:46 naddy Exp $ +Fix mismatch between apr_off_t (long long) and APR_OFF_FMT_T ("ld") + Index: configure.in --- configure.in.orig +++ configure.in -@@ -2281,7 +2281,7 @@ fi +@@ -1828,6 +1828,14 @@ case $host in + long_value="__int64" + int64_strfn="_strtoi64" + ;; ++*-openbsd*) ++int64_t_fmt='#define APR_INT64_T_FMT "lld"' ++uint64_t_fmt='#define APR_UINT64_T_FMT "llu"' ++uint64_t_hex_fmt='#define APR_UINT64_T_HEX_FMT "llx"' ++int64_value="long long" ++long_value="long long" ++int64_strfn="strtoll" ++ ;; + esac + + APR_CHECK_TYPES_COMPATIBLE(ssize_t, int, [ssize_t_fmt="d"]) +@@ -1928,6 +1936,10 @@ elif test "$ac_cv_type_off_t" = "yes"; then + off_t_fmt='#define APR_OFF_T_FMT "I64d"' + off_t_strfn='_strtoi64' + ;; ++*-openbsd*) ++off_t_fmt='#define APR_OFF_T_FMT APR_INT64_T_FMT' ++off_t_strfn='apr_strtoi64' ++ ;; + esac + else +# Fallback on int +@@ -2281,7 +2293,7 @@ fi APR_IFALLYES(header:semaphore.h func:sem_open func:sem_close dnl func:sem_unlink func:sem_post func:sem_wait, hasposixser="1", hasposixser="0") @@ -12,7 +40,7 @@ Index: configure.in hassysvser="0") APR_IFALLYES(func:flock define:LOCK_EX, hasflockser="1", hasflockser="0") APR_IFALLYES(header:fcntl.h define:F_SETLK, hasfcntlser="1", hasfcntlser="0") -@@ -2470,6 +2470,8 @@ else +@@ -2470,6 +2482,8 @@ else fi dnl - Checking for /dev/random @@ -21,7 +49,7 @@ Index: configure.in AC_MSG_CHECKING(for entropy source) why_no_rand="" -@@ -2486,6 +2488,13 @@ AC_ARG_WITH(egd, +@@ -2486,6 +2500,13 @@ AC_ARG_WITH(egd, AC_MSG_RESULT(EGD-compatible daemon) rand="1" ])
Re: devel/apr: apr_off_t (long long) vs APR_OFF_T_FMT ("ld")
On Sun, Dec 16, 2018 at 12:36:43PM +, Stuart Henderson wrote: > On 2018/12/16 13:23, Stefan Sperling wrote: > > APR's configure script figures out that off_t is 'long long' on > > OpenBSD but at the same time sets APR_OFF_T_FMT to "ld". > > > > This results in a build failure when I try to compile httpd-2.4.37: > > > > /home/stsp/svn/src/httpd-2.4.37/server/util_expr_eval.c:1144:56: error: > > format > > specifies type 'long' but the argument has type 'apr_off_t' > > > > (aka 'long long') [-Werror,-Wformat] > > > > return apr_psprintf(ctx->p, "%" APR_OFF_T_FMT, sb.size); > > > > ~~~ ^~~ > > > > > > I suspect we should add OS-specific overrides to APR's configure script. > > The patch below does this and fixes the above error. Am I right that this > > is what the script should be doing for all OpenBSD architectures? > > If we decide to patch our port of APR like this, then I will submit my > > patch upstream as well. > > Makes sense to me, though I'm wondering why I didn't run into this build > failure before. I came across this with a httpd development build (--enable-maintainer-mode) which enables -Werror. Still, it looks like this uncovered an actual problem. > > Ports which depend on APR would probably need a bump, correct? > > The easy way to do that is just bump major in apr's SHARED_LIBS. So this should take care of it? Index: Makefile === RCS file: /cvs/ports/devel/apr/Makefile,v retrieving revision 1.42 diff -u -p -r1.42 Makefile --- Makefile25 Oct 2017 19:36:46 - 1.42 +++ Makefile16 Dec 2018 12:49:55 - @@ -4,8 +4,8 @@ COMMENT=Apache Portable Runtime V= 1.6.3 DISTNAME= apr-$V -REVISION= 0 -SHARED_LIBS += apr-1 6.0 # .6.2 +REVISION= 1 +SHARED_LIBS += apr-1 7.0 # .6.2 CATEGORIES=devel Index: patches/patch-configure_in === RCS file: /cvs/ports/devel/apr/patches/patch-configure_in,v retrieving revision 1.1 diff -u -p -r1.1 patch-configure_in --- patches/patch-configure_in 25 Oct 2017 19:36:46 - 1.1 +++ patches/patch-configure_in 16 Dec 2018 12:00:16 - @@ -1,9 +1,37 @@ $OpenBSD: patch-configure_in,v 1.1 2017/10/25 19:36:46 naddy Exp $ +Fix mismatch between apr_off_t (long long) and APR_OFF_FMT_T ("ld") + Index: configure.in --- configure.in.orig +++ configure.in -@@ -2281,7 +2281,7 @@ fi +@@ -1828,6 +1828,14 @@ case $host in + long_value="__int64" + int64_strfn="_strtoi64" + ;; ++*-openbsd*) ++int64_t_fmt='#define APR_INT64_T_FMT "lld"' ++uint64_t_fmt='#define APR_UINT64_T_FMT "llu"' ++uint64_t_hex_fmt='#define APR_UINT64_T_HEX_FMT "llx"' ++int64_value="long long" ++long_value="long long" ++int64_strfn="strtoll" ++ ;; + esac + + APR_CHECK_TYPES_COMPATIBLE(ssize_t, int, [ssize_t_fmt="d"]) +@@ -1928,6 +1936,10 @@ elif test "$ac_cv_type_off_t" = "yes"; then + off_t_fmt='#define APR_OFF_T_FMT "I64d"' + off_t_strfn='_strtoi64' + ;; ++*-openbsd*) ++off_t_fmt='#define APR_OFF_T_FMT APR_INT64_T_FMT' ++off_t_strfn='apr_strtoi64' ++ ;; + esac + else +# Fallback on int +@@ -2281,7 +2293,7 @@ fi APR_IFALLYES(header:semaphore.h func:sem_open func:sem_close dnl func:sem_unlink func:sem_post func:sem_wait, hasposixser="1", hasposixser="0") @@ -12,7 +40,7 @@ Index: configure.in hassysvser="0") APR_IFALLYES(func:flock define:LOCK_EX, hasflockser="1", hasflockser="0") APR_IFALLYES(header:fcntl.h define:F_SETLK, hasfcntlser="1", hasfcntlser="0") -@@ -2470,6 +2470,8 @@ else +@@ -2470,6 +2482,8 @@ else fi dnl - Checking for /dev/random @@ -21,7 +49,7 @@ Index: configure.in AC_MSG_CHECKING(for entropy source) why_no_rand="" -@@ -2486,6 +2488,13 @@ AC_ARG_WITH(egd, +@@ -2486,6 +2500,13 @@ AC_ARG_WITH(egd, AC_MSG_RESULT(EGD-compatible daemon) rand="1" ])
Re: lang/rust: add clippy and rustfmt subpackages
On Sun, Dec 16, 2018 at 05:43:12AM -0600, Edward Lopez-Acosta wrote: > Thanks for including these but a possibly dumb question. > > Why subpackages for clippy and rustfmt and not part of the standard rust > installation like upstream? except if I miss something, upstream provides clippy and rustfmt separately when using rustup. when building from Rust tarball, the installer build and create separated tarball for all components: - rustc : the compiler - rust-std : std library - rust-docs : documentation - cargo : package manager - clippy : linter - rustfmt : code formatter the port unpacks them and next create openbsd package from that. FYI, debian provides one package for each components (whereas openbsd collapse rustc, rust-std and cargo). > If REVISION is bumped anyways for rust-gdb will > it still cause issues with other ports or installations? I am not sure to understand the question. bumping REVISION means 'pkg_add -u' will see that there is a difference between the two package versions, and update to the newer. the change is with the newer package, a user will not be able to run 'rust-gdb' without first installing 'rust-gdb' package. but the package will take care of having gdb installed first (it wasn't the case before: you could had a 'rust-gdb' script, but not functional). Thanks. -- Sebastien Marie
Re: [NEW] (ping) slant-0.0.17
> It's really not expected that a package runs something which changes > packaged files or their permissions. > > Automatically running something which stops and starts daemons is > also not expected. If we go by the letter of the install process, where we're supposed to "stop/disable all appropriate applications" during upgrades, none of it is necessary except that the database must be upgraded, which in the case of slant means kwebapp-sqldiff passes an upgrade script into slant.db. (I assume that stop/disable means to remove packages from pkg_scripts before upgrading so they don't automatically start upon booting and/or are running during pkg_add -u.) However, this requires users to know that the httpd and slant services must be temporarily disabled. As a user myself, I'd probably never do that. I reboot into bsd.rd, do the stuff, then run pkg_add -u afterward. In this case, slant-collectd/httpd will be running during pkg_add, and the CGI script will also be runnable. So there's a period during which the database schema and the collector/cgi script are out of sync. To counter this, I install the cgi script with mode 0 so it won't be run, then run an upgrade script which stops the slant service, if it's running. It then upgrades the database, sets the cgi script mode, and restart (conditionally) the slant service. I'm not sure which is proper---please let me know and I can make the changes!
UPDATE: bsd.port.mk - Add GitLab support
Hello, I spent some time and added GitLab support to bsd.port.mk in a similar manner as GitHub. Since Microsoft's acquisition of GitHub a large number of projects, including major ones like the freedesktop project, have migrated to GitLab. I also have a number of projects at GitLab that I have been thinking of porting. https://about.gitlab.com/2018/06/03/movingtogitlab/ https://about.gitlab.com/2018/08/20/freedesktop-org-migrates-to-gitlab/ I did some tests on this and it seems to work like the GH_* directives but would like some additional review if possible please. Thank you, -- Edward Lopez-Acosta diff --git bsd.port.mk bsd.port.mk index a31757c39fc..ef76d864c8e 100644 --- bsd.port.mk +++ bsd.port.mk @@ -129,6 +129,7 @@ _ALL_VARIABLES += HOMEPAGE DISTNAME \ SHARED_LIBS TARGETS PSEUDO_FLAVOR \ MAINTAINER AUTOCONF_VERSION AUTOMAKE_VERSION CONFIGURE_ARGS \ GH_ACCOUNT GH_COMMIT GH_PROJECT GH_TAGNAME PORTROACH \ + GL_ACCOUNT GL_COMMIT GL_PROJECT GL_TAGNAME \ PORTROACH_COMMENT MAKEFILE_LIST USE_LLD USE_WXNEEDED COMPILER \ COMPILER_LANGS COMPILER_LINKS SUBST_VARS UPDATE_PLIST_ARGS \ PKGPATHS @@ -620,6 +621,15 @@ GH_PROJECT ?= DISTNAME ?= ${GH_PROJECT}-${GH_TAGNAME:C/^v//} .endif +GL_TAGNAME ?= +GL_COMMIT ?= +GL_ACCOUNT ?= +GL_PROJECT ?= + +.if !empty(GL_PROJECT) && !empty(GL_TAGNAME) +DISTNAME ?= ${GL_PROJECT}-${GL_TAGNAME:C/^v//} +.endif + PKGNAME ?= ${DISTNAME} FULLPKGNAME ?= ${PKGNAME}${FLAVOR_EXT} _MASTER ?= @@ -868,6 +878,18 @@ WRKDIST ?= ${WRKDIR}/${DISTNAME} . endif .endif +.if !empty(GL_TAGNAME) +WRKDIST ?= ${WRKDIR}/${GL_PROJECT}-${GL_TAGNAME:C/^v//} +.elif !empty(GL_COMMIT) +WRKDIST ?= ${WRKDIR}/${GL_PROJECT}-${GL_COMMIT} +.else +. if !defined(DISTNAME) +WRKDIST ?= ${WRKDIR} +. else +WRKDIST ?= ${WRKDIR}/${DISTNAME} +. endif +.endif + WRKSRC ?= ${WRKDIST} .if ${SEPARATE_BUILD:L} != "no" @@ -1184,6 +1206,28 @@ HOMEPAGE ?= https://github.com/${GH_ACCOUNT}/${GH_PROJECT} MASTER_SITES ?= .endif +.if !empty(GL_ACCOUNT) && !empty(GL_PROJECT) +. if !empty(GL_COMMIT) && !empty(GL_TAGNAME) +ERRORS += "Fatal: specifying both GL_TAGNAME and GL_COMMIT is invalid" +. endif +. if ${GL_TAGNAME} == master +ERRORS += "Fatal: using master as GL_TAGNAME is invalid" +. endif +. if !empty(GL_TAGNAME) +MASTER_SITES_GITLAB += \ + https://gitlab.com/${GL_ACCOUNT}/${GL_PROJECT}/-/archive/${GL_TAGNAME:S/$/\//} +. else +MASTER_SITES_GITLAB += \ + https://gitlab.com/${GL_ACCOUNT}/${GL_PROJECT}/-/archive/${GL_COMMIT}/${GL_PROJECT-}${GL_COMMIT:S/$/\//} +. endif + +MASTER_SITES ?= ${MASTER_SITES_GITLAB} +HOMEPAGE ?= https://gitlab.com/${GL_ACCOUNT}/${GL_PROJECT} +.else +# Empty declarations to avoid "variable XXX is recursive" errors +MASTER_SITES ?= +.endif + # I guess we're in the master distribution business! :) As we gain mirror # sites for distfiles, add them to MASTER_SITE_BACKUP @@ -1211,6 +1255,14 @@ DISTFILES ?= ${DISTNAME}${EXTRACT_SUFX} . endif .endif +.if !empty(GL_COMMIT) +DISTFILES ?= ${DISTNAME}-${GL_COMMIT:C/().*/\1/}${EXTRACT_SUFX}{${GL_COMMIT}${EXTRACT_SUFX}} +.else +. if defined(DISTNAME) +DISTFILES ?= ${DISTNAME}${EXTRACT_SUFX} +. endif +.endif + PATCHFILES ?= SUPDISTFILES ?=
production/tryton/5.0: import few modules
Hi, I would like to import a new serie of modules for productivity/tryton/5.0. The tarball contains 32 modules. Diff for Makefile attached. Ports tested on amd64. Summary of the advance regarding all tryton modules: - total modules for tryton-5.0: 128 - currently imported: 52 (+ 32 = 84, after this serie) Thanks. -- Sebastien Marie tryton-modules.tgz Description: application/tar-gz Index: Makefile === RCS file: /cvs/ports/productivity/tryton/5.0/Makefile,v retrieving revision 1.2 diff -u -p -r1.2 Makefile --- Makefile8 Dec 2018 19:08:01 - 1.2 +++ Makefile16 Dec 2018 15:26:14 - @@ -46,22 +46,55 @@ SUBDIR += analytic_account SUBDIR += analytic_invoice SUBDIR += analytic_purchase SUBDIR += analytic_sale +SUBDIR += authentication_sms SUBDIR += bank +SUBDIR += carrier +SUBDIR += carrier_percentage +SUBDIR += carrier_weight +SUBDIR += commission +SUBDIR += commission_waiting SUBDIR += company +SUBDIR += company_work_time +SUBDIR += customs SUBDIR += country SUBDIR += currency +SUBDIR += dashboard +SUBDIR += edocument_uncefact +SUBDIR += edocument_unece +SUBDIR += google_maps +#SUBDIR += ldap_authentication # TODO ldap3 +SUBDIR += notification_email SUBDIR += party +SUBDIR += party_relationship SUBDIR += party_siret SUBDIR += product +SUBDIR += product_attribute +SUBDIR += product_classification +SUBDIR += product_classification_taxonomic +SUBDIR += product_cost_fifo +SUBDIR += product_cost_history SUBDIR += product_measurements +SUBDIR += product_price_list +SUBDIR += product_price_list_dates +SUBDIR += product_price_list_parent +SUBDIR += production +SUBDIR += production_outsourcing +SUBDIR += production_routing +SUBDIR += production_split +SUBDIR += production_work +SUBDIR += production_work_timesheet SUBDIR += purchase SUBDIR += purchase_request +SUBDIR += purchase_shipment_cost SUBDIR += sale# TODO optional pygal +SUBDIR += sale_shipment_cost SUBDIR += sale_supply SUBDIR += sale_supply_drop_shipment SUBDIR += stock SUBDIR += stock_package SUBDIR += stock_shipment_measurements SUBDIR += stock_supply +SUBDIR += timesheet +SUBDIR += web_user .include
Re: NEW net/traccar
On 16/12/2018 16:10, Landry Breuil wrote: That's strange because i still see ${PREFIX}/share/traccar in PLIST but whatever. i see that you've patched templates.rootPath in default.xml, i suppose that's the thing you were referring to. Indeed, templates.rootPath is the fix for the notifications Imported the fixed version with var/empty, thanks for the port ! It's running fine here in basic testing, had to fight a bit with nginx and i still get some web socket connection error popups on the web UI, a README showing how to properly proxyfy/firewall it would be nice in a next iteration. Yes, I will make a README telling how to make the UI listen on 127.0.0.1 only and how to proxyfy it. Restricting the listening ports really has to be made with a firewall at the moment, but that could change in a future revision. smime.p7s Description: S/MIME Cryptographic Signature
Re: [NEW] (ping) slant-0.0.17
> There are two common methods used by programs that depend on database > schema. One is probably best described as "YOLO", i.e. don't bother > checking anything, not ideal but it is very common. The other is to have > a schema version stored in the database and refuse to run if it's not as > expected. > > There are plenty of things in ports that require schema updates from > time to time and I don't think there's a single one that stops running > services etc. In this case, if the collector daemon were running during an update, it'll just halt when it detects the disparity. Which also seems not expected. (The CGI not running is fine, as it'd die if the CGI were mode 0 anyway.) So the choices seem to be do nothing and have the daemon just die, which is not expected; or to have some sort of stop/start facility, which is also not expected. Upon looking back at expected behaviour, the install guide stipulates rebooting after pkg_add -u anyway. So I guess it doesn't matter that the collector dies during pkg_add since we're going to reboot, no? If that's the case, I'll add the version checking and resend.
Re: devel/apr: apr_off_t (long long) vs APR_OFF_T_FMT ("ld")
Stefan Sperling: > Another possible fix for us would be to move the check for 'long long' > before the one for 'long' (see below) but I don't know what upstream > would say about that. I considered this, but it doesn't fix the underlying problem and just inverts the issue. It would work for us, but then platforms where off_t is defined differently on LP64 vs LP32 platforms would get inconsistent format specifiers and types. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: NEW net/traccar
On Sat, Dec 15, 2018 at 10:18:00AM +0100, Renaud Allard wrote: > > > On 14/12/2018 19:05, Landry Breuil wrote: > > > > > : -@newuser _traccar:824:_traccar:daemon:Traccar > > > user:${PREFIX}/share/traccar/:/sbin/nologin > > > : +@newuser _traccar:824:_traccar:daemon:Traccar > > > user:${PREFIX}/share/traccar:/sbin/nologin > > > > Is this $HOME necessary so that it finds its assets or var/empty would > > be better ? minimal testing here seems to show its fine with /var/empty > > but if there are valid reasons for it.. > > Please use the one attached here. $HOME is now /var/empty and I changed the > patch to solve the issues (mainly the application not finding the templates > to send notifications). That's strange because i still see ${PREFIX}/share/traccar in PLIST but whatever. i see that you've patched templates.rootPath in default.xml, i suppose that's the thing you were referring to. Imported the fixed version with var/empty, thanks for the port ! It's running fine here in basic testing, had to fight a bit with nginx and i still get some web socket connection error popups on the web UI, a README showing how to properly proxyfy/firewall it would be nice in a next iteration. Landry
Re: [wip] telegraf (metrics collecting agent)
On Fri, 7 Dec 2018 11:37:02 +0100, Landry Breuil wrote: > looking for okays to import sure, ok danj@ with diff -pruN telegraf/Makefile /usr/ports/sysutils/telegraf/Makefile --- telegraf/Makefile Fri Dec 7 03:25:48 2018 +++ /usr/ports/sysutils/telegraf/Makefile Sun Dec 16 10:36:47 2018 @@ -2,8 +2,6 @@ COMMENT = plugin-driven server agent for collecting metrics -V =1.9.0 -DISTNAME = telegraf-${V} GH_ACCOUNT = influxdata GH_PROJECT = telegraf GH_TAGNAME = 1.9.0 diff -pruN telegraf/pkg/PLIST /usr/ports/sysutils/telegraf/pkg/PLIST --- telegraf/pkg/PLIST Fri Dec 7 05:21:01 2018 +++ /usr/ports/sysutils/telegraf/pkg/PLIST Sun Dec 16 10:55:02 2018 @@ -1,6 +1,6 @@ @comment $OpenBSD: PLIST,v$ -@newgroup _telegraf:824 -@newuser _telegraf:824:_telegraf:daemon:telegraf user:/var/empty:/sbin/nologin +@newgroup _telegraf:825 +@newuser _telegraf:825:_telegraf:daemon:telegraf user:/var/empty:/sbin/nologin @rcscript ${RCDIR}/telegraf @bin bin/stress_test_write @bin bin/telegraf
NEW: net/libunbound
Unbound in base only includes the programs (daemon and tools). I will be wanting the library for an Asterisk update, thfr@ was interested in it a little while ago, and florian@ expressed an interest too. Currently it feels like ports is the best place for this, so here's a proposed port. Any comments/OKs? libunbound.tgz Description: Binary data
Re: [NEW] (ping) slant-0.0.17
There are two common methods used by programs that depend on database schema. One is probably best described as "YOLO", i.e. don't bother checking anything, not ideal but it is very common. The other is to have a schema version stored in the database and refuse to run if it's not as expected. There are plenty of things in ports that require schema updates from time to time and I don't think there's a single one that stops running services etc. -- Sent from a phone, apologies for poor formatting. On 16 December 2018 13:23:09 Kristaps Dzonsons wrote: It's really not expected that a package runs something which changes packaged files or their permissions. Automatically running something which stops and starts daemons is also not expected. If we go by the letter of the install process, where we're supposed to "stop/disable all appropriate applications" during upgrades, none of it is necessary except that the database must be upgraded, which in the case of slant means kwebapp-sqldiff passes an upgrade script into slant.db. (I assume that stop/disable means to remove packages from pkg_scripts before upgrading so they don't automatically start upon booting and/or are running during pkg_add -u.) However, this requires users to know that the httpd and slant services must be temporarily disabled. As a user myself, I'd probably never do that. I reboot into bsd.rd, do the stuff, then run pkg_add -u afterward. In this case, slant-collectd/httpd will be running during pkg_add, and the CGI script will also be runnable. So there's a period during which the database schema and the collector/cgi script are out of sync. To counter this, I install the cgi script with mode 0 so it won't be run, then run an upgrade script which stops the slant service, if it's running. It then upgrades the database, sets the cgi script mode, and restart (conditionally) the slant service. I'm not sure which is proper---please let me know and I can make the changes!
Re: NEW net/traccar
On Sun, Dec 16, 2018 at 04:15:25PM +0100, Renaud Allard wrote: > > > On 16/12/2018 16:10, Landry Breuil wrote: > > > > > That's strange because i still see ${PREFIX}/share/traccar in PLIST but > > whatever. i see that you've patched templates.rootPath in default.xml, i > > suppose that's the thing you were referring to. > > Indeed, templates.rootPath is the fix for the notifications > > > > > Imported the fixed version with var/empty, thanks for the port ! It's > > running fine here in basic testing, had to fight a bit with nginx and i > > still get some web socket connection error popups on the web UI, a > > README showing how to properly proxyfy/firewall it would be nice in a > > next iteration. > > Yes, I will make a README telling how to make the UI listen on 127.0.0.1 > only and how to proxyfy it. Restricting the listening ports really has to be > made with a firewall at the moment, but that could change in a future > revision. A friend of me working on traccar pointed me to https://github.com/traccar/traccar/issues/4066 - i think we should patch out the default.xml file so that it doesnt phone home by default. Landry
www/py-gunicorn : Update to 19.9.0
Hi, ports@: Here is a patch to update www/py-gunicorn to 19.9.0. It both build and run on my amd64 system. And passed the `make test`. Two ports depends on www/py-gunicorn: www/puppetboard and www/py-aiohttp. Both build with the update of gunicorn. Many of www/py-aiohttp tests failed. But the same tests failed with current gunicorn two. Seems the aiohttp in portstree is too old. Comments? wen Index: Makefile === RCS file: /cvs/ports/www/py-gunicorn/Makefile,v retrieving revision 1.20 diff -u -p -r1.20 Makefile --- Makefile4 May 2018 11:37:24 - 1.20 +++ Makefile17 Dec 2018 06:22:11 - @@ -2,7 +2,7 @@ COMMENT = Python WSGI HTTP server -MODPY_EGG_VERSION =19.8.1 +MODPY_EGG_VERSION =19.9.0 DISTNAME = gunicorn-${MODPY_EGG_VERSION} PKGNAME = py-${DISTNAME} CATEGORIES = www Index: distinfo === RCS file: /cvs/ports/www/py-gunicorn/distinfo,v retrieving revision 1.13 diff -u -p -r1.13 distinfo --- distinfo4 May 2018 11:37:24 - 1.13 +++ distinfo17 Dec 2018 06:22:11 - @@ -1,2 +1,2 @@ -SHA256 (gunicorn-19.8.1.tar.gz) = vFkAWXnvttLdfVunLZn4qEIoYq0X/zoW6QBoRjDdKhA= -SIZE (gunicorn-19.8.1.tar.gz) = 415541 +SHA256 (gunicorn-19.9.0.tar.gz) = +iZiCXxm+SD1P3BiHGxYyko8TTQ0IF5gjhIbWztx9PM= +SIZE (gunicorn-19.9.0.tar.gz) = 415774 Index: patches/patch-requirements_test_txt === RCS file: /cvs/ports/www/py-gunicorn/patches/patch-requirements_test_txt,v retrieving revision 1.3 diff -u -p -r1.3 patch-requirements_test_txt --- patches/patch-requirements_test_txt 4 May 2018 11:37:24 - 1.3 +++ patches/patch-requirements_test_txt 17 Dec 2018 06:22:11 - @@ -7,7 +7,7 @@ Index: requirements_test.txt +++ requirements_test.txt @@ -1,3 +1,3 @@ coverage>=4.0,<4.4 # TODO: https://github.com/benoitc/gunicorn/issues/1548 --pytest==3.0.5 --pytest-cov==2.4.0 -+pytest +-pytest==3.2.5 # TODO: upgrade to latest version requires drop support to Python 2.6 +-pytest-cov==2.5.1 ++pytest # TODO: upgrade to latest version requires drop support to Python 2.6 +pytest-cov Index: pkg/PLIST === RCS file: /cvs/ports/www/py-gunicorn/pkg/PLIST,v retrieving revision 1.8 diff -u -p -r1.8 PLIST --- pkg/PLIST 4 May 2018 11:37:24 - 1.8 +++ pkg/PLIST 17 Dec 2018 06:22:11 - @@ -80,8 +80,8 @@ lib/python${MODPY_VERSION}/site-packages ${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/gunicorn/workers/${MODPY_PYCACHE}/ lib/python${MODPY_VERSION}/site-packages/gunicorn/workers/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc ${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/gunicorn/workers/${MODPY_PYCACHE}_gaiohttp.${MODPY_PYC_MAGIC_TAG}pyc -lib/python${MODPY_VERSION}/site-packages/gunicorn/workers/${MODPY_PYCACHE}async.${MODPY_PYC_MAGIC_TAG}pyc lib/python${MODPY_VERSION}/site-packages/gunicorn/workers/${MODPY_PYCACHE}base.${MODPY_PYC_MAGIC_TAG}pyc +lib/python${MODPY_VERSION}/site-packages/gunicorn/workers/${MODPY_PYCACHE}base_async.${MODPY_PYC_MAGIC_TAG}pyc lib/python${MODPY_VERSION}/site-packages/gunicorn/workers/${MODPY_PYCACHE}gaiohttp.${MODPY_PYC_MAGIC_TAG}pyc lib/python${MODPY_VERSION}/site-packages/gunicorn/workers/${MODPY_PYCACHE}geventlet.${MODPY_PYC_MAGIC_TAG}pyc lib/python${MODPY_VERSION}/site-packages/gunicorn/workers/${MODPY_PYCACHE}ggevent.${MODPY_PYC_MAGIC_TAG}pyc @@ -90,8 +90,8 @@ lib/python${MODPY_VERSION}/site-packages lib/python${MODPY_VERSION}/site-packages/gunicorn/workers/${MODPY_PYCACHE}sync.${MODPY_PYC_MAGIC_TAG}pyc lib/python${MODPY_VERSION}/site-packages/gunicorn/workers/${MODPY_PYCACHE}workertmp.${MODPY_PYC_MAGIC_TAG}pyc lib/python${MODPY_VERSION}/site-packages/gunicorn/workers/_gaiohttp.py -lib/python${MODPY_VERSION}/site-packages/gunicorn/workers/async.py lib/python${MODPY_VERSION}/site-packages/gunicorn/workers/base.py +lib/python${MODPY_VERSION}/site-packages/gunicorn/workers/base_async.py lib/python${MODPY_VERSION}/site-packages/gunicorn/workers/gaiohttp.py lib/python${MODPY_VERSION}/site-packages/gunicorn/workers/geventlet.py lib/python${MODPY_VERSION}/site-packages/gunicorn/workers/ggevent.py
Re: [NEW] (ping) slant-0.0.17
On 2018/12/16 11:56, Kristaps Dzonsons wrote: > > BUILD_DEPENDS=STEM->=0.6.9:www/kwebapp www/kcgi databases/ksql > > kcgi and ksql are RDEPS of kwebapp already, so this seems redundant. > > > > update-plist moves slant-cgi at the end of PLIST. > > > > port-lib-depends-check reports "curses tls z" as missing. > > Enclosed fixes these. > > However, update-plist puts slant-cgi *after* the @exec, but the @exec > changes mode on the now-subsequent @bin. Since pkg_create says that > exec can't rely on anything after, I put the exec last. It's really not expected that a package runs something which changes packaged files or their permissions. Automatically running something which stops and starts daemons is also not expected.
Re: devel/apr: apr_off_t (long long) vs APR_OFF_T_FMT ("ld")
On 2018/12/16 13:23, Stefan Sperling wrote: > APR's configure script figures out that off_t is 'long long' on > OpenBSD but at the same time sets APR_OFF_T_FMT to "ld". > > This results in a build failure when I try to compile httpd-2.4.37: > > /home/stsp/svn/src/httpd-2.4.37/server/util_expr_eval.c:1144:56: error: > format > specifies type 'long' but the argument has type 'apr_off_t' > > (aka 'long long') [-Werror,-Wformat] > > return apr_psprintf(ctx->p, "%" APR_OFF_T_FMT, sb.size); > > ~~~ ^~~ > > > I suspect we should add OS-specific overrides to APR's configure script. > The patch below does this and fixes the above error. Am I right that this > is what the script should be doing for all OpenBSD architectures? > If we decide to patch our port of APR like this, then I will submit my > patch upstream as well. Makes sense to me, though I'm wondering why I didn't run into this build failure before. > Ports which depend on APR would probably need a bump, correct? The easy way to do that is just bump major in apr's SHARED_LIBS. > Index: Makefile > === > RCS file: /cvs/ports/devel/apr/Makefile,v > retrieving revision 1.42 > diff -u -p -r1.42 Makefile > --- Makefile 25 Oct 2017 19:36:46 - 1.42 > +++ Makefile 16 Dec 2018 12:00:54 - > @@ -4,7 +4,7 @@ COMMENT= Apache Portable Runtime > > V= 1.6.3 > DISTNAME=apr-$V > -REVISION=0 > +REVISION=1 > SHARED_LIBS += apr-1 6.0 # .6.2 > > CATEGORIES= devel > Index: patches/patch-configure_in > === > RCS file: /cvs/ports/devel/apr/patches/patch-configure_in,v > retrieving revision 1.1 > diff -u -p -r1.1 patch-configure_in > --- patches/patch-configure_in25 Oct 2017 19:36:46 - 1.1 > +++ patches/patch-configure_in16 Dec 2018 12:00:16 - > @@ -1,9 +1,37 @@ > $OpenBSD: patch-configure_in,v 1.1 2017/10/25 19:36:46 naddy Exp $ > > +Fix mismatch between apr_off_t (long long) and APR_OFF_FMT_T ("ld") > + > Index: configure.in > --- configure.in.orig > +++ configure.in > -@@ -2281,7 +2281,7 @@ fi > +@@ -1828,6 +1828,14 @@ case $host in > + long_value="__int64" > + int64_strfn="_strtoi64" > + ;; > ++*-openbsd*) > ++int64_t_fmt='#define APR_INT64_T_FMT "lld"' > ++uint64_t_fmt='#define APR_UINT64_T_FMT "llu"' > ++uint64_t_hex_fmt='#define APR_UINT64_T_HEX_FMT "llx"' > ++int64_value="long long" > ++long_value="long long" > ++int64_strfn="strtoll" > ++;; > + esac > + > + APR_CHECK_TYPES_COMPATIBLE(ssize_t, int, [ssize_t_fmt="d"]) > +@@ -1928,6 +1936,10 @@ elif test "$ac_cv_type_off_t" = "yes"; then > + off_t_fmt='#define APR_OFF_T_FMT "I64d"' > + off_t_strfn='_strtoi64' > + ;; > ++*-openbsd*) > ++off_t_fmt='#define APR_OFF_T_FMT APR_INT64_T_FMT' > ++off_t_strfn='apr_strtoi64' > ++;; > + esac > + else > +# Fallback on int > +@@ -2281,7 +2293,7 @@ fi > APR_IFALLYES(header:semaphore.h func:sem_open func:sem_close dnl >func:sem_unlink func:sem_post func:sem_wait, >hasposixser="1", hasposixser="0") > @@ -12,7 +40,7 @@ Index: configure.in >hassysvser="0") > APR_IFALLYES(func:flock define:LOCK_EX, hasflockser="1", hasflockser="0") > APR_IFALLYES(header:fcntl.h define:F_SETLK, hasfcntlser="1", > hasfcntlser="0") > -@@ -2470,6 +2470,8 @@ else > +@@ -2470,6 +2482,8 @@ else > fi > > dnl - Checking for /dev/random > @@ -21,7 +49,7 @@ Index: configure.in > AC_MSG_CHECKING(for entropy source) > > why_no_rand="" > -@@ -2486,6 +2488,13 @@ AC_ARG_WITH(egd, > +@@ -2486,6 +2500,13 @@ AC_ARG_WITH(egd, > AC_MSG_RESULT(EGD-compatible daemon) > rand="1" > ]) >
Re: UPDATE: inputmethods/uim
Bryan Linton writes: > The first thing I noticed was that the qt4 MULTI_PACKAGE wouldn't > continue building until I manually installed devel/automoc, so it > probably needs adding to the Makefile as either a BUILD or LIB_DEPEND. Can't reproduce here: uim-qt4 builds without automoc of any kind installed. > Considering that all the build failures end with the same error, which is: > > gmake[1]: Entering directory '/usr/obj/ports/uim-1.8.8/uim-1.8.8/scm' > if test -n "/usr/local/bin/csi"; then \ > /usr/local/bin/csi -R syntax-case -q json-parser-expander.scm > jso > n-p= > arser-expanded.scm; \ > fi > error CS2006: Command-line syntax error: Missing '' for '-R' opti > on > error CS2001: Source file '/usr/obj/ports/uim-1.8.8/uim-1.8.8/scm/synta > x-c= > ase' could not be found. It's looking for chicken. But if I patch it to use chicken, there seem to be chicken language errors of some sort, yet the file manages to get installed anyway. Since FreeBSD patches it out, I've done it too; new diff below. Thanks for pointing that out. > I removed those lines and got farther, but the build still fails for me. > Build logs attached below. If I've done something wrong, feel free to > hit me with a cluebat. As far as I can tell there's no actual error in the logs you attached. I can't reproduce; for me everything builds fine even on a fresh -current vmm(4) VM. It would be helpful if you could test removing packages one by one until you find the one that's breaking your build. > Also, as a side note, would it be possible to add a qt5 MULTI_PACKAGE > as well? I'm fine with that, but I'd like to get this update in first. Here's the updated diff that builds even when mono is installed: Index: Makefile === RCS file: /cvs/ports/inputmethods/uim/Makefile,v retrieving revision 1.62 diff -u -p -r1.62 Makefile --- Makefile24 Oct 2018 14:28:06 - 1.62 +++ Makefile16 Dec 2018 23:58:19 - @@ -11,7 +11,7 @@ COMMENT-qt4= uim for QT4 CATEGORIES=inputmethods japanese chinese -V= 1.8.6 +V= 1.8.8 DISTNAME= uim-$V PKGNAME-main= uim-$V PKGNAME-gtk= uim-gtk-$V @@ -19,14 +19,12 @@ PKGNAME-gtk3= uim-gtk3-$V PKGNAME-kde= uim-kde-$V PKGNAME-qt=uim-qt-$V PKGNAME-qt4= uim-qt4-$V -REVISION= 8 -MASTER_SITES= https://github.com/uim/uim/releases/download/uim-$V/ +MASTER_SITES= https://github.com/uim/uim/releases/download/$V/ HOMEPAGE= https://github.com/uim/uim -SHARED_LIBS += gcroots 0.0 # .1.0 SHARED_LIBS += uim-scm 0.0 # .0.0 -SHARED_LIBS += uim 1.0 # .6.0 +SHARED_LIBS += uim 1.1 # .6.0 SHARED_LIBS += uim-custom 0.0 # .2.0 # BSD @@ -46,11 +44,12 @@ USE_GMAKE= Yes RUN_DEPENDS-main= devel/desktop-file-utils -WANTLIB-main += ${cWANTLIB} -WANTLIB-main += Xft anthy anthydic c curses expat ${COMPILER_LIBCXX} -WANTLIB-main += util xcb z +WANTLIB-main += ${cWANTLIB} ${COMPILER_LIBCXX} +WANTLIB-main += Xft anthy anthydic c curses edit expat gcroots +WANTLIB-main += sqlite3 util xcb z -LIB_DEPENDS-main= inputmethods/anthy +LIB_DEPENDS-main= inputmethods/anthy \ + devel/libgcroots WANTLIB-gtk += ${cWANTLIB} @@ -58,7 +57,7 @@ WANTLIB-gtk += Xcomposite Xcursor Xdamag WANTLIB-gtk += atk-1.0 c cairo expat ffi gcroots gdk-x11-2.0 gdk_pixbuf-2.0 WANTLIB-gtk += gio-2.0 glib-2.0 gmodule-2.0 gobject-2.0 graphite2 WANTLIB-gtk += gthread-2.0 gtk-x11-2.0 harfbuzz pango-1.0 pangocairo-1.0 -WANTLIB-gtk += pangoft2-1.0 pcre pixman-1 png pthread +WANTLIB-gtk += pangoft2-1.0 pcre pixman-1 png pthread fribidi WANTLIB-gtk += uim uim-custom uim-scm xcb xcb-render xcb-shm z LIB_DEPENDS-gtk= inputmethods/uim \ @@ -66,11 +65,11 @@ LIB_DEPENDS-gtk=inputmethods/uim \ WANTLIB-gtk3 += ${cWANTLIB} WANTLIB-gtk3 += Xcomposite Xcursor Xdamage Xfixes Xi Xinerama -WANTLIB-gtk3 += Xrandr Xtst atk-1.0 atk-bridge-2.0 atspi c cairo cairo-gobject +WANTLIB-gtk3 += Xrandr atk-1.0 atk-bridge-2.0 atspi c cairo cairo-gobject WANTLIB-gtk3 += dbus-1 expat ffi gcroots gdk-3 gdk_pixbuf-2.0 gio-2.0 WANTLIB-gtk3 += glib-2.0 gmodule-2.0 gobject-2.0 graphite2 gthread-2.0 WANTLIB-gtk3 += gtk-3 harfbuzz pango-1.0 pangocairo-1.0 pangoft2-1.0 -WANTLIB-gtk3 += pcre pixman-1 png pthread uim uim-custom +WANTLIB-gtk3 += pcre pixman-1 png pthread uim uim-custom fribidi WANTLIB-gtk3 += uim-scm xcb xcb-render xcb-shm z epoxy LIB_DEPENDS-gtk3= inputmethods/uim \ @@ -81,6 +80,7 @@ WANTLIB-kde += DCOP GL ICE SM X11-xcb Xc WANTLIB-kde += Xft Xi Xinerama Xmu Xrandr Xt Xxf86vm art_lgpl_2 drm WANTLIB-kde += expat gcroots glapi idn jpeg kdefx lcms mng png pthread WANTLIB-kde += qt-mt ${COMPILER_LIBCXX} uim
qtbase-5.9.6p1 fails to build on -stable/loongson
Hi, As title suggests, qtbase on -stable fails to build. Relevant part from build log: /usr/bin/ld: BFD 2.17 assertion fail /usr/src/gnu/usr.bin/binutils-2.17/bfd/elf64-mips.c:2254 /usr/bin/ld: BFD 2.17 internal error, aborting at /usr/src/gnu/usr.bin/binutils-2.17/bfd/reloc.c line 445 in bfd_get_reloc_size /usr/bin/ld: Please report this bug. clang-6.0: error: linker command failed with exit code 1 (use -v to see invocation) Full build log is also attached. Please advice on how to fix. Thanks! -- manphiz qtbase.log.gz Description: application/gzip signature.asc Description: PGP signature
Re: NEW: net/libunbound
On Sun, Dec 16 2018, Stuart Henderson wrote: > Unbound in base only includes the programs (daemon and tools). > > I will be wanting the library for an Asterisk update, thfr@ was > interested in it a little while ago, and florian@ expressed an > interest too. > > Currently it feels like ports is the best place for this, so > here's a proposed port. I see no reason to adds this to base. The obvious risk with a libunbound port is about base unbound and this port getting out of sync, but I'm not even sure that's a problem. > Any comments/OKs? LGTM I noticed that the Makefile specifies --with-libexpat=/usr even though expat doesn't appear in WANTLIB; but that's not necessarily a problem. pkg/DESCR says: This package contains the validating resolver library from the Unbound distribution (the main Unbound resolver is OpenBSD's base OS). Maybe s/is/in/? Otherwise ok jca@ -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Update to py3-black-18.9beta0
Hi, Here's a diff to update the port to the latest release. Upstream thought it was a good idea to add a webserver for this code formatter: https://github.com/ambv/black#blackd Sadly I think our py-aiohttp is too old for this stuff so I just disabled the installation of the "binary". We can revisit this choice once py-aiohttp has been updated. The tests suite seems to be crippled by this. Basic testing appears to be fine. I'd like to take the maintainership. Comments? OK? Cheers, Daniel Index: Makefile === RCS file: /cvs/ports/textproc/py-black/Makefile,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 Makefile --- Makefile7 Jul 2018 15:17:15 - 1.1.1.1 +++ Makefile17 Dec 2018 00:53:57 - @@ -2,11 +2,13 @@ COMMENT = python code formatter -MODPY_EGG_VERSION =18.6b4 +MODPY_EGG_VERSION =18.9b0 DISTNAME = black-${MODPY_EGG_VERSION} PKGNAME = py-black-${MODPY_EGG_VERSION:S/b/beta/} CATEGORIES = textproc devel + +MAINTAINER = Daniel Jakots HOMEPAGE = https://github.com/ambv/black Index: distinfo === RCS file: /cvs/ports/textproc/py-black/distinfo,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 distinfo --- distinfo7 Jul 2018 15:17:15 - 1.1.1.1 +++ distinfo17 Dec 2018 00:53:57 - @@ -1,2 +1,2 @@ -SHA256 (black-18.6b4.tar.gz) = IhWLicGmtOszOh5l55Gj+LmYzzsRrglK2yVw8x92mkQ= -SIZE (black-18.6b4.tar.gz) = 141556 +SHA256 (black-18.9b0.tar.gz) = 4DCpoo9ULevAiszrJz8iisQieY5SFboqeRpt3qrKIqU= +SIZE (black-18.9b0.tar.gz) = 151371 Index: pkg/PLIST === RCS file: /cvs/ports/textproc/py-black/pkg/PLIST,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 PLIST --- pkg/PLIST 7 Jul 2018 15:17:15 - 1.1.1.1 +++ pkg/PLIST 17 Dec 2018 00:53:57 - @@ -1,6 +1,7 @@ @comment $OpenBSD: PLIST,v 1.1.1.1 2018/07/07 15:17:15 juanfra Exp $ bin/black lib/python${MODPY_VERSION}/site-packages/${MODPY_PYCACHE}black.${MODPY_PYC_MAGIC_TAG}pyc +lib/python${MODPY_VERSION}/site-packages/${MODPY_PYCACHE}blackd.${MODPY_PYC_MAGIC_TAG}pyc lib/python${MODPY_VERSION}/site-packages/black-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/ lib/python${MODPY_VERSION}/site-packages/black-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO lib/python${MODPY_VERSION}/site-packages/black-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/SOURCES.txt @@ -10,6 +11,7 @@ lib/python${MODPY_VERSION}/site-packages lib/python${MODPY_VERSION}/site-packages/black-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt lib/python${MODPY_VERSION}/site-packages/black-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt lib/python${MODPY_VERSION}/site-packages/black.py +lib/python${MODPY_VERSION}/site-packages/blackd.py lib/python${MODPY_VERSION}/site-packages/blib2to3/ lib/python${MODPY_VERSION}/site-packages/blib2to3/Grammar.txt lib/python${MODPY_VERSION}/site-packages/blib2to3/PatternGrammar.txt Index: patches/patch-setup_py === RCS file: patches/patch-setup_py diff -N patches/patch-setup_py --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-setup_py 17 Dec 2018 00:53:58 - @@ -0,0 +1,12 @@ +$OpenBSD$ + +Index: setup.py +--- setup.py.orig setup.py +@@ -57,5 +57,5 @@ setup( + "Topic :: Software Development :: Libraries :: Python Modules", + "Topic :: Software Development :: Quality Assurance", + ], +-entry_points={"console_scripts": ["black=black:main", "blackd=blackd:main [d]"]}, ++entry_points={"console_scripts": ["black=black:main"]}, + )
Re: [UPDATE] CVE-2017-16248: www/p5-Catalyst-Plugin-Static-Simple
Hi, I'm adding the quirks info as well. Can someone check this out please? Charlène. Index: devel/quirks/Makefile === RCS file: /cvs/ports/devel/quirks/Makefile,v retrieving revision 1.670 diff -u -p -r1.670 Makefile --- devel/quirks/Makefile 17 Dec 2018 01:10:00 - 1.670 +++ devel/quirks/Makefile 17 Dec 2018 02:19:49 - @@ -5,7 +5,7 @@ CATEGORIES =devel databases DISTFILES = # API.rev -PKGNAME = quirks-3.63 +PKGNAME = quirks-3.64 PKG_ARCH = * MAINTAINER = Marc Espie Index: devel/quirks/files/Quirks.pm === RCS file: /cvs/ports/devel/quirks/files/Quirks.pm,v retrieving revision 1.684 diff -u -p -r1.684 Quirks.pm --- devel/quirks/files/Quirks.pm17 Dec 2018 01:10:00 - 1.684 +++ devel/quirks/files/Quirks.pm17 Dec 2018 02:19:49 - @@ -1282,6 +1282,7 @@ my $cve = { 'www/iridium' => 'iridium-<2018.5.67', 'www/mozilla-firefox' => 'firefox-<62.0.2p0', 'www/nginx' => 'nginx-<1.4.1', + 'www/p5-Catalyst-Plugin-Static-Simple' => 'p5-Catalyst-Plugin-Static-Simple-<0.36', 'www/p5-CGI-Application' => 'p5-CGI-Application-<4.50p0', 'www/py-requests' => 'py-requests-<2.20.0', 'www/py-requests,python3' => 'py3-requests-<2.20.0', Index: www/p5-Catalyst-Plugin-Static-Simple/Makefile === RCS file: /cvs/ports/www/p5-Catalyst-Plugin-Static-Simple/Makefile,v retrieving revision 1.15 diff -u -p -r1.15 Makefile --- www/p5-Catalyst-Plugin-Static-Simple/Makefile 20 Mar 2016 19:57:16 - 1.15 +++ www/p5-Catalyst-Plugin-Static-Simple/Makefile 17 Dec 2018 02:19:49 - @@ -4,8 +4,7 @@ COMMENT=serving static pages with cata MODULES= cpan PKG_ARCH= * -DISTNAME= Catalyst-Plugin-Static-Simple-0.29 -REVISION= 1 +DISTNAME= Catalyst-Plugin-Static-Simple-0.36 CATEGORIES=www # Perl @@ -15,9 +14,9 @@ RUN_DEPENDS= devel/p5-Moose \ devel/p5-MooseX-Types \ devel/p5-namespace-autoclean \ www/p5-Catalyst-Runtime>=5.80008 \ - mail/p5-MIME-Types>=1.25 + mail/p5-MIME-Types>=2.03 BUILD_DEPENDS= ${RUN_DEPENDS} -TEST_DEPENDS=www/p5-Catalyst-Plugin-SubRequest>=0.15 +TEST_DEPENDS= www/p5-Catalyst-Plugin-SubRequest>=0.15 MAKE_ENV= TEST_POD=Yes Index: www/p5-Catalyst-Plugin-Static-Simple/distinfo === RCS file: /cvs/ports/www/p5-Catalyst-Plugin-Static-Simple/distinfo,v retrieving revision 1.7 diff -u -p -r1.7 distinfo --- www/p5-Catalyst-Plugin-Static-Simple/distinfo 18 Jan 2015 03:15:43 - 1.7 +++ www/p5-Catalyst-Plugin-Static-Simple/distinfo 17 Dec 2018 02:19:49 - @@ -1,2 +1,2 @@ -SHA256 (Catalyst-Plugin-Static-Simple-0.29.tar.gz) = JLCNF2upuiQM6rLZiUalW76SlVp08UT/71LPR4QKUPI= -SIZE (Catalyst-Plugin-Static-Simple-0.29.tar.gz) = 36471 +SHA256 (Catalyst-Plugin-Static-Simple-0.36.tar.gz) = Nrczj5a+9PJoX3pFVbFRl5Oud4O9PW0iyX87cY8wlFQ= +SIZE (Catalyst-Plugin-Static-Simple-0.36.tar.gz) = 44538 On Fri, 7 Dec 2018 20:11:14 +0100 Charlene Wendling wrote: > Hi ports, > > I'm proposing here an update for www/p5-Catalyst-Plugin-Static-Simple, > from 0.29 to 0.36, that also fixes CVE-2017-16248 [1] (directory > traversal) by the way. > > What's new upstream (full changelog there [2]): > > - Fix installation for Perl 5.26+ > - Relax/fix some tests > - Change configuration key to 'Plugin::Static::Simple', using the old > 'static' will issue a warning > > What's new in the port: > > - mail/p5-MIME-Types version requirement bumped > - Tiny spacing fix as well > > Testing: > > - 'make test' passes > - There are 2 consumers, that i've tested [3]: > - www/p5-Catalyst-Devel is fine. > - devel/catalyst-tutorial has one error, caused by (a probably > way too old) www/p5-HTML-FormFu > > Any comments/feedback is welcome! > > Charlène. > > [1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-16248 > [2] > https://metacpan.org/changes/release/ILMARI/Catalyst-Plugin-Static-Simple-0.36 > [3] https://transfer.sh/5aESu/p5-Catalyst-Plugin-Static-Simple.tgz
Re: [M. UPDATE] devel/py-pathlib2 2.3.2 -> 2.3.3
On Sun, 2 Dec 2018 15:36:15 -0300, "Elias M. Mariani" wrote: > Changelog: > https://github.com/mcmtroffaes/pathlib2/blob/2.3.3/CHANGELOG.rst > > - Bring back old deprecated dependency syntax. > - Drop Python 3.3 support. > - Add Python 3.7 support. > > Results regression tests from 2.3.2 and 2.3.3 return the same: > > + Test results for 2.3.2 + > py-pathlib2: Ran 396 tests, 125 skipped. > py3-pathlib2: Ran 396 tests, 119 skipped. > > + Test results for 2.3.3 + > py-pathlib2: Ran 396 tests, 125 skipped. > py3-pathlib2: Ran 396 tests, 119 skipped. ok danj@ Cheers, Daniel
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2018/12/16 01:54:24 Modified files: textproc/ripgrep: distinfo Log message: backout change on distinfo: it wasn't intented to be commit
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2018/12/16 01:50:11 Modified files: devel/cargo: cargo.port.mk devel/cbindgen : Makefile sysutils/exa : Makefile textproc/ripgrep: Makefile distinfo www/geckodriver: Makefile Log message: change MODCARGO_CRATES syntax for devel/cargo module. The new syntax to have version with '-' character: -MODCARGO_CRATES += aho-corasick-0.6.8 # Unlicense/MIT +MODCARGO_CRATES += aho-corasick0.6.8 # Unlicense/MIT update all customers of devel/cargo to use the new syntax ok landry@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2018/12/16 02:19:57 Modified files: lang/rust : Makefile lang/rust/patches: patch-src_etc_rust-gdb lang/rust/pkg : PLIST-main Added files: lang/rust/pkg : DESCR-clippy DESCR-gdb DESCR-rustfmt PLIST-clippy PLIST-gdb PLIST-rustfmt Log message: build clippy (linter) and rustfmt (code formatter) and provide them in subpackages. while here create a subpackage for rust-gdb also. looks good landry@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2018/12/16 08:33:44 Modified files: infrastructure/db: user.list Log message: reserve uid 824 for _traccar, reminded by danj@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: d...@cvs.openbsd.org2018/12/16 09:53:35 Modified files: productivity/tryton/5.0/trytond/files: server.conf Log message: Missed in previous
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: d...@cvs.openbsd.org2018/12/16 09:52:39 Modified files: productivity/tryton/5.0/trytond: Makefile productivity/tryton/5.0/trytond/files: server.conf productivity/tryton/5.0/trytond/pkg: README Log message: Tweak documentation While there, passlib[bcrypt] seems to be just bcrypt so add a rdep on it with and ok semarie@ (maintainer)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2018/12/16 08:08:34 Modified files: sysutils/amazon-ssm-agent: Makefile sysutils/amazon-ssm-agent/patches: patch-makefile Log message: Don't run the checkstyle script to unbreak with new go.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2018/12/16 08:09:58 Log message: Import traccar 4.2, from MAINTAINER Renaud Allard. Traccar is an open source GPS tracking system. It supports more than 170 GPS protocols and more than 1500 models of GPS tracking devices. Traccar can be used with any major SQL database system. It also provides an easy to use REST API. Some of the available features include: * Real-time GPS tracking * Driver behaviour monitoring * Detailed and summary reports * Geofencing functionality * Alarms and notifications * Account and device management * Email and SMS support ok/tweaks sthen@ Status: Vendor Tag: rallard Release Tags: landry_20181216 N ports/geo/traccar/Makefile N ports/geo/traccar/distinfo N ports/geo/traccar/patches/patch-conf_default_xml N ports/geo/traccar/patches/patch-conf_traccar_xml N ports/geo/traccar/pkg/DESCR N ports/geo/traccar/pkg/PLIST N ports/geo/traccar/pkg/traccar.rc No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2018/12/16 08:10:24 Modified files: geo: Makefile Log message: +traccar
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2018/12/16 06:53:22 Modified files: devel/git : Makefile distinfo devel/git/patches: patch-t_t1450-fsck_sh patch-t_test-lib_sh devel/git/pkg : PLIST-main Log message: Update to git-2.20.1 OK benoit
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: d...@cvs.openbsd.org2018/12/16 17:50:28 ports/textproc/py-black/patches Update of /cvs/ports/textproc/py-black/patches In directory cvs.openbsd.org:/tmp/cvs-serv49227/patches Log Message: Directory /cvs/ports/textproc/py-black/patches added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2018/12/16 18:01:24 Modified files: devel/quirks : Makefile devel/quirks/files: Quirks.pm x11/nx : Makefile Removed files: x11/nx/nxssh : Makefile distinfo x11/nx/nxssh/patches: patch-configure patch-includes_h patch-log_h patch-openbsd-compat_openbsd-compat_h patch-readpass_c patch-sshd_c x11/nx/nxssh/pkg: DESCR PLIST x11/nx/opennx : Makefile distinfo x11/nx/opennx/patches: patch-Makefile_in patch-MySession_cpp patch-MyXmlConfig_cpp patch-configure patch-opennxApp_cpp x11/nx/opennx/pkg: DESCR PLIST README Log message: Remove insecure nxssh and obsolete opennx nxssh is based on an old copy of OpenSSH 4.7. Upstream stopped supporting it and it hasn't been updated since import, so it's likely affected by all the issues listed on https://www.openssh.com/security.html since 2008. opennx is a graphical client that uses nxssh under the hood. It is dead upstream, hasn't been updated since 2009 and won't build with wxWidgets3. ok kn@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2018/12/16 18:10:00 Modified files: devel/quirks : Makefile devel/quirks/files: Quirks.pm Log message: Fix sickbeard removal
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2018/12/16 18:08:29 Modified files: devel/quirks : Makefile devel/quirks/files: Quirks.pm telephony/iaxclient: Makefile Removed files: telephony/iaxclient/patches: patch-simpleclient_iaxcomm_calls_cc patch-simpleclient_iaxcomm_frame_cc patch-simpleclient_iaxcomm_ringer_cc telephony/iaxclient/pkg: DESCR-iaxcomm PLIST-iaxcomm Log message: Remove iaxcomm subpackage iaxcomm doesn't build with wxWidgets3, not very surprising since the last beta release was in 2008. Maintainer timeout, ok kn@ rsadowski@ sthen@