CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2019/09/26 23:56:17 Modified files: devel/quirks : Makefile devel/quirks/files: Quirks.pm Log message: register opencv-docs removal
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2019/09/26 23:49:56 Modified files: graphics/opencv: Makefile distinfo graphics/opencv/patches: patch-cmake_OpenCVFindLibsVideo_cmake patch-modules_core_src_system_cpp graphics/opencv/pkg: PLIST-java PLIST-main Added files: graphics/opencv/patches: patch-CMakeLists_txt Removed files: graphics/opencv/patches: patch-modules_dnn_src_torch_THGeneral_cpp graphics/opencv/pkg: DESCR-docs PLIST-docs Log message: Update opencv to 3.4.7 Notable port changes: - Remove -docs to avoid java conflicts with JDK 8 and 11. - Upstream switched completely to github - Sort CONFIGURE_ARGS - Add patch to install licenses files at the old location. - ONLY_FOR_ARCHS-java = aarch64 amd64 i386 ok kurt@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rpoin...@cvs.openbsd.org2019/09/26 23:48:12 Modified files: security/py-ropper: Makefile distinfo Removed files: security/py-ropper/patches: patch-ropper_console_py Log message: update ropper to 1.12.5. ok pirofti@ license has changed from GPL to BSD, from kmos@.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rpoin...@cvs.openbsd.org2019/09/26 23:46:30 Modified files: devel/py-filebytes: Makefile distinfo Log message: update fileytes to 0.9.21. ok kmos@.
valgrind diff to fix run memcheck on amd64
Hi ports,
This is a patch for running valgrind memcheck on amd64. I corrected
the following two problems.
- FS register can be used.
- Fixed a problem that strip command rewrites offset and align of
memcheck ELF file.
Index: Makefile
===
RCS file: /cvs/ports/devel/valgrind/Makefile,v
retrieving revision 1.19
diff -u -p -r1.19 Makefile
--- Makefile12 Jul 2019 20:46:03 - 1.19
+++ Makefile27 Sep 2019 03:08:46 -
@@ -38,4 +38,10 @@ AUTORECONF = /bin/sh ./autogen.sh
.if ${PROPERTIES:Mclang}
# replace -lgcc
MAKE_FLAGS = TOOL_LDADD_COMMON=-lcompiler_rt
+# XXX The '-s' option was not specified when executing the install command.
+# Instead '--strip-all' is now executed at link time.
+# strip command rewrite offset and align in ELF file. Therefor, when valgrind
+# launch memcheck-amd64-openbsd, an Abort trap occurs in the execvp() system
+# call.
+INSTALL_STRIP =
.endif
Index: patches/patch-VEX_priv_guest_amd64_helpers_c
===
RCS file: patches/patch-VEX_priv_guest_amd64_helpers_c
diff -N patches/patch-VEX_priv_guest_amd64_helpers_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-VEX_priv_guest_amd64_helpers_c27 Sep 2019 03:08:46
-
@@ -0,0 +1,16 @@
+--- VEX/priv/guest_amd64_helpers.c.orig
VEX/priv/guest_amd64_helpers.c
+@@ -3744,6 +3744,13 @@ void LibVEX_GuestAMD64_initialise (
/*OUT*/VexGuestAMD64State* vex_state )
+/* HACK: represent the offset associated with %fs==0. This
+ assumes that %fs is only ever zero. */
+vex_state->guest_FS_ZERO = 0;
++#if defined(__OpenBSD__)
++{
++ int fs;
++ __asm__("mov %%fs,%0" : "=r" (fs));
++ vex_state->guest_FS_ZERO = fs;
++}
++#endif
+
+vex_state->guest_RIP = 0;
+
Index: patches/patch-VEX_priv_guest_amd64_toIR_c
===
RCS file: patches/patch-VEX_priv_guest_amd64_toIR_c
diff -N patches/patch-VEX_priv_guest_amd64_toIR_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-VEX_priv_guest_amd64_toIR_c 27 Sep 2019 03:08:46 -
@@ -0,0 +1,205 @@
+--- VEX/priv/guest_amd64_toIR.c.orig
VEX/priv/guest_amd64_toIR.c
+@@ -312,7 +312,11 @@ static IROp mkSizedOp ( IRType ty, IROp op8 )
+|| op8 == Iop_Shl8 || op8 == Iop_Shr8 || op8 == Iop_Sar8
+|| op8 == Iop_CmpEQ8 || op8 == Iop_CmpNE8
+|| op8 == Iop_CasCmpNE8
++#if !defined(__OpenBSD__)
+|| op8 == Iop_Not8 );
++#else
++ || op8 == Iop_Not8 || op8 == Iop_MovFromSeg8);
++#endif
+switch (ty) {
+ case Ity_I8: return 0 +op8;
+ case Ity_I16: return 1 +op8;
+@@ -709,6 +713,12 @@ static Bool haveF3 ( Prefix pfx ) {
+return toBool((pfx & PFX_F3) > 0);
+ }
+
++#if defined(__OpenBSD__)
++static Bool haveFS( Prefix pfx ) {
++ return toBool((pfx & PFX_FS) > 0);
++}
++#endif
++
+ static Bool have66 ( Prefix pfx ) {
+return toBool((pfx & PFX_66) > 0);
+ }
+@@ -1213,7 +1223,6 @@ static void putIRegRexB ( Int sz, Prefix pfx, UInt
lo3bits, IRExpr* e )
+));
+ }
+
+-
+ /* Functions for getting register numbers from modrm bytes and REX
+when we don't have to consider the complexities of integer subreg
+accesses.
+@@ -3137,6 +3146,136 @@ ULong dis_op2_G_E ( VexAbiInfo* vbi,
+ }
+
+
++#if defined(__OpenBSD__)
++/* Handle binary integer instructions of the form
++ op S, G, E meaning
++ op segment reg, reg, reg
++ Is passed the a ptr to the modRM byte, the actual operation, and the
++ data size. Returns the address advanced completely over this
++ instruction.
++
++ S(segment) is reg.
++ G(src) is reg.
++
++ OP %S:%G, tmp
++ PUT tmp, %E
++*/
++static
++Int dis_op3_S_G_E ( VexAbiInfo* vbi,
++Prefix pfx,
++IROpop,
++Int size,
++Longdelta0,
++/*OUT*/HChar* buf)
++{
++ IRType ty= szToITy(size);
++ IRTemp dst1 = newTemp(ty);
++ IRTemp off = newTemp(ty);
++ IRTemp dst0 = newTemp(ty);
++ Long delta = delta0;
++ UChar modrm = getUChar(delta0++);
++ UChar rm= (modrm & 7);
++
++ assign(dst0, getIRegG(size, pfx, modrm));
++ assign(off, getIRegE(size, pfx, modrm | 0xc0));
++ assign(dst1, binop(op, mkexpr(dst0), mkexpr(off)));
++ putIRegG(size, pfx, modrm, mkexpr(dst1));
++
++ if (rm == 0x4) {
++ UChar tmp = getUChar(delta0++);
++ vassert(tmp == 0x24);
++ } else if (rm == 0x05) {
++ UChar tmp = getUChar(delta0++);
++ vassert(tmp == 0x00);
++ }
++
++ DIS(buf, "%s(%s)", segRegTxt(pfx),
++ nameIRegRexB(haveASO(pfx) ? 4 : 8, pfx, rm));
++
++ return delta0 - delta;
++}
++
++static void
++dis_op3_assignDst(IROp op, Int size, IRTemp src, IRTemp dst, IRTemp off)
++{
++ switch (size) {
++ case 4: {
++ IRTemp src1 = newTemp(szToITy(8));
Re: chromium-77.0.3865.90 and Aw, Snap! everywhere
On Thu, Sep 26, 2019 at 11:22:23PM +, Mikolaj Kucharski wrote:
> Hi,
>
> Does anyone else sees chrome not usable with latest snapshot? After
> starting the browser it crashes any tab with "Aw, Snap!". At the same
> time when I start the browser dmesg is full of pledge entries from
> chrome (see below output) and chrome.core is left in $HOME.
I'm seeing this too with chromium-77.0.3865.90. It works fine with
chromium-76.0.3809.132.
>From what I can tell it seems the chromium renderer process is missing
a pledge.
39948 chrome STRU promise="stdio rpath flock prot_exec recvfd sendfd
ps"
39948 chrome CALL getpriority(PRIO_PROCESS,0)
39948 chrome PLDG getpriority, "id", errno 1 Operation not permitted
..
https://github.com/openbsd/ports/blob/961e5936cdffea36f0041c7153c960ae65ad2ff3/www/chromium/patches/patch-services_service_manager_sandbox_openbsd_sandbox_openbsd_cc#L301
You'll need to use chrome --no-sandbox at least until this can be
looked at by the maintainer, or if possible reinstall the older
chromium package.
> I upgraded to:
>
> $ sysctl -n kern.version
> OpenBSD 6.6-beta (GENERIC.MP) #327: Thu Sep 26 11:36:51 MDT 2019
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> and packages snapshot to:
>
> $ awk '/digital-signature/ {print $NF}' /var/db/pkg/quirks-3.181/+CONTENTS
> signify2:2019-09-26T17:01:40Z:external
>
> $ awk '/digital-signature/ {print $NF}'
> /var/db/pkg/chromium-77.0.3865.90/+CONTENTS
> signify2:2019-09-26T16:55:04Z:external
>
> $ dmesg
> ...
> chrome[49746]: pledge "id", syscall 100
> chrome[92387]: pledge "id", syscall 100
> chrome[85549]: pledge "id", syscall 100
> chrome[68279]: pledge "id", syscall 100
> chrome[94240]: pledge "id", syscall 100
> chrome[90180]: pledge "id", syscall 100
> chrome[66584]: pledge "id", syscall 100
> chrome[63381]: pledge "id", syscall 100
> chrome[73033]: pledge "id", syscall 100
> chrome[90867]: pledge "id", syscall 100
> chrome[85108]: pledge "id", syscall 100
> chrome[48198]: pledge "id", syscall 100
> chrome[7576]: pledge "id", syscall 100
> chrome[7576]: pledge "stdio", syscall 197
> chrome[92089]: pledge "id", syscall 100
> chrome[56583]: pledge "id", syscall 100
> chrome[2955]: pledge "id", syscall 100
> chrome[2955]: pledge "stdio", syscall 197
> chrome[35028]: pledge "id", syscall 100
> chrome[12759]: pledge "id", syscall 100
> chrome[22687]: pledge "id", syscall 100
> chrome[21924]: pledge "id", syscall 100
> chrome[99193]: pledge "id", syscall 100
> chrome[32604]: pledge "id", syscall 100
> chrome[84867]: pledge "id", syscall 100
> chrome[6284]: pledge "id", syscall 100
> chrome[6284]: pledge "stdio", syscall 197
> chrome[4125]: pledge "id", syscall 100
> chrome[33735]: pledge "id", syscall 100
> chrome[77972]: pledge "id", syscall 100
> chrome[25419]: pledge "id", syscall 100
> chrome[72435]: pledge "id", syscall 100
> chrome[904]: pledge "id", syscall 100
>
> --
> Regards,
> Mikolaj
>
>
[update] www/edbrowse to 3.7.5.1
Hola! Here is a trivial diff to bring edbrowse up to the latest version. Changelog here: https://github.com/CMB/edbrowse/blob/master/CHANGES#L26-L74 (Note, there is no release files for 3.7.6) OK? -- PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: abie...@cvs.openbsd.org 2019/09/26 20:07:46 Modified files: lang/node : Makefile distinfo lang/node/patches: patch-Makefile patch-common_gypi patch-deps_npm_lib_npm_js patch-deps_openssl_config_Makefile patch-deps_openssl_config_bn_conf_no-asm_h patch-deps_openssl_config_dso_conf_no-asm_h patch-deps_openssl_config_generate_gypi_pl patch-deps_openssl_config_opensslconf_no-asm_h patch-deps_uv_src_unix_openbsd_c patch-lib_module_js patch-node_gypi patch-tools_test_py lang/node/pkg : PLIST Log message: Update node to the latest LTS. Changelog here: https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V10.md#10.16.3 Builds firefox fine. sthen@ tested an i386 build and it went OK. OK sthen@
chromium-77.0.3865.90 and Aw, Snap! everywhere
Hi,
Does anyone else sees chrome not usable with latest snapshot? After
starting the browser it crashes any tab with "Aw, Snap!". At the same
time when I start the browser dmesg is full of pledge entries from
chrome (see below output) and chrome.core is left in $HOME.
I upgraded to:
$ sysctl -n kern.version
OpenBSD 6.6-beta (GENERIC.MP) #327: Thu Sep 26 11:36:51 MDT 2019
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
and packages snapshot to:
$ awk '/digital-signature/ {print $NF}' /var/db/pkg/quirks-3.181/+CONTENTS
signify2:2019-09-26T17:01:40Z:external
$ awk '/digital-signature/ {print $NF}'
/var/db/pkg/chromium-77.0.3865.90/+CONTENTS
signify2:2019-09-26T16:55:04Z:external
$ dmesg
...
chrome[49746]: pledge "id", syscall 100
chrome[92387]: pledge "id", syscall 100
chrome[85549]: pledge "id", syscall 100
chrome[68279]: pledge "id", syscall 100
chrome[94240]: pledge "id", syscall 100
chrome[90180]: pledge "id", syscall 100
chrome[66584]: pledge "id", syscall 100
chrome[63381]: pledge "id", syscall 100
chrome[73033]: pledge "id", syscall 100
chrome[90867]: pledge "id", syscall 100
chrome[85108]: pledge "id", syscall 100
chrome[48198]: pledge "id", syscall 100
chrome[7576]: pledge "id", syscall 100
chrome[7576]: pledge "stdio", syscall 197
chrome[92089]: pledge "id", syscall 100
chrome[56583]: pledge "id", syscall 100
chrome[2955]: pledge "id", syscall 100
chrome[2955]: pledge "stdio", syscall 197
chrome[35028]: pledge "id", syscall 100
chrome[12759]: pledge "id", syscall 100
chrome[22687]: pledge "id", syscall 100
chrome[21924]: pledge "id", syscall 100
chrome[99193]: pledge "id", syscall 100
chrome[32604]: pledge "id", syscall 100
chrome[84867]: pledge "id", syscall 100
chrome[6284]: pledge "id", syscall 100
chrome[6284]: pledge "stdio", syscall 197
chrome[4125]: pledge "id", syscall 100
chrome[33735]: pledge "id", syscall 100
chrome[77972]: pledge "id", syscall 100
chrome[25419]: pledge "id", syscall 100
chrome[72435]: pledge "id", syscall 100
chrome[904]: pledge "id", syscall 100
--
Regards,
Mikolaj
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/09/26 16:01:47 Modified files: mail/roundcubemail: Makefile net/librenms : Makefile www/composer : Makefile www/nextcloud : Makefile Log message: drop MODPHP_VERSION=7.3, it is now the default
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/09/26 15:59:31 Modified files: databases/pg_stats_reporter: Makefile databases/pgfouine: Makefile devel/boris: Makefile geo/mapserver : Makefile mail/kopano/core: Makefile mail/z-push: Makefile misc/gpsd : Makefile multimedia/yle-dl: Makefile net/icinga/web2: Makefile net/icinga/web2-module-director: Makefile net/nagios/nagios: Makefile net/nfsen : Makefile net/php-weathermap: Makefile net/zabbix : Makefile productivity/baikal: Makefile productivity/davical: Makefile textproc/tcpdf : Makefile www/awl: Makefile www/dokuwiki : Makefile www/drupal7/core7: Makefile www/drush : Makefile www/mollify: Makefile www/php-predis : Makefile www/phpldapadmin: Makefile www/phppgadmin : Makefile www/phpvirtualbox: Makefile www/pnp4nagios : Makefile www/racktables : Makefile www/sabredav : Makefile www/selfoss: Makefile www/syweb : Makefile www/wp-cli : Makefile x11/kde4/kcachegrind: Makefile Log message: REVISION bumps for php default version switch to 7.3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/09/26 15:59:02 Modified files: www/phpmyadmin : Makefile Log message: bump REVISION for php default version switch drop mcrypt dependency, it hasn't been recommended by upstream since 2015 and is no longer bundled in php core. (it is available by pecl, but things generally shouldn't be using it these days).
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/09/26 15:57:42 Modified files: www/pear : Makefile distinfo www/pear/pkg : PLIST-main Log message: update to pear-1.10.9 (this is the current stable version listed on PEAR, though there is a newer one in github). fixes things with php 7.2+. switch to github /raw/ upstream rather than a self-hosted .phar file
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/09/26 15:55:58 Modified files: lang/php : php.port.mk Log message: switch default php version to 7.3, bumps/fixes to follow
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2019/09/26 15:52:48 Modified files: devel : Makefile Log message: Hook py-bitcoinlib up to the build
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2019/09/26 15:49:36 Log message: devel/py-bitcoinlib This Python3 library provides an easy interface to the bitcoin data structures and protocol. From Clem Atis Feedback and tweaks from myself, sthen, and rsadowski ok sthen rsadowski Status: Vendor Tag: kmos Release Tags: kmos_20190926 N ports/devel/py-bitcoinlib/Makefile N ports/devel/py-bitcoinlib/distinfo N ports/devel/py-bitcoinlib/pkg/DESCR N ports/devel/py-bitcoinlib/pkg/PLIST No conflicts created by this import
some new hs-ports
Hi, here are 6 new hs-ports (from Greg Steuck, with some minor tweaks by me) that are required for the ghc update. Attached tarballs are relative to /usr/ports/devel. When updating ghc, the following ports will be removed: devel/hs-mtl, devel/hs-parsec, devel/hs-stm, devel/hs-text, textproc/hs-stringsearch, so the number of hs-ports doesn't explode ;-) ok to import them? Ciao, Kili ps: comments and descriptions: *** devel/hs-base-compat: Comment: a compatibility layer for base Description: The scope of base-compat is to provide functions available in later versions of base to a wider (older) range of compilers. In addition, successful library proposals that have been accepted to be part of upcoming versions of base are also included. This package is not intended to replace base, but to complement it. *** devel/hs-byteable: Comment: type class for sequence of bytes Description: Abstract class to manipulate sequence of bytes The use case of this class is abstracting manipulation of types that are just wrapping a bytestring with stronger and more meaniful name. *** devel/hs-mono-traversable: Comment: type classes for working with monomorphic containers Description: Type classes for mapping, folding, and traversing monomorphic and polymorphic containers. Haskell is good at operating over polymorphic containers such as a list [a]. A monomorphic container is one such as Text which has a type Text that does not expose a type variable for the underlying characters. *** devel/hs-unliftio-core: Comment: typeclass for unlifting monads to IO Description: Provides the core MonadUnliftIO typeclass, instances for base and transformers, and basic utility functions. Typically, you'll want to use the unliftio library, which provides more functionality (and a much better description). *** devel/hs-unordered-containers: Comment: efficient hashing-based container types Description: Efficient hashing-based container types. The containers have been optimized for performance critical use, both in terms of large data quantities and high speed. The declared cost of each operation is either worst-case or amortized, but remains valid even if structures are shared. *** devel/hs-vector-algorithms: Comment: efficient algorithms for vector arrays Description: Efficient algorithms for sorting vector arrays. At some stage other vector algorithms may be added. hs-base-compat.tgz Description: application/tar-gz hs-byteable.tgz Description: application/tar-gz hs-mono-traversable.tgz Description: application/tar-gz hs-unliftio-core.tgz Description: application/tar-gz hs-unordered-containers.tgz Description: application/tar-gz hs-vector-algorithms.tgz Description: application/tar-gz
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2019/09/26 15:28:04 Modified files: devel/py-urwid : Makefile Log message: Adding Clem Atis as MAINTAINER
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/09/26 15:14:42 Modified files: net/icinga/web2/pkg: PLIST Log message: fix bogus MODPHP_VERSION subst
Re: NEW: games/fallingtime
Hi, On Mon, 23 Sep 2019 18:29:03 -0400 Brian Callahan wrote: > Hi ports -- > > Attached is a new port, games/fallingtime. FallingTime is a game > where you are a constantly falling ball. > > --- > pkg/DESCR: > FallingTime is an arcade game inspired by Fall Down. Like the Fall > Down games, you are a ball and you must fall into the holes to avoid > being crushed by the top of the screen! > --- > > Simple port; works well on amd64. > > OK? It builds and runs fine on macppc. Colors aren't off as well. OK cwen@ > ~Brian >
UPDATE: Nextcloud-16.0.5
Hello,
Update for Nextcloud to 16.0.5:
https://nextcloud.com/changelog/
OK? Comments?
Cheers.-
--
- gonzalo
Index: Makefile
===
RCS file: /cvs/ports/www/nextcloud/Makefile,v
retrieving revision 1.42
diff -u -p -r1.42 Makefile
--- Makefile21 Aug 2019 13:26:01 - 1.42
+++ Makefile26 Sep 2019 17:52:21 -
@@ -2,7 +2,7 @@
COMMENT= easy and universal access to shared and/or personal
files
-V= 16.0.4
+V= 16.0.5
DISTNAME= nextcloud-${V}
EXTRACT_SUFX= .tar.bz2
Index: distinfo
===
RCS file: /cvs/ports/www/nextcloud/distinfo,v
retrieving revision 1.27
diff -u -p -r1.27 distinfo
--- distinfo21 Aug 2019 13:26:01 - 1.27
+++ distinfo26 Sep 2019 17:52:21 -
@@ -1,2 +1,2 @@
-SHA256 (nextcloud-16.0.4.tar.bz2) =
4GMAJR7JNaG8mPqQpKVr9JQrDlWdYKGRt+Sdj/2f7NA=
-SIZE (nextcloud-16.0.4.tar.bz2) = 61914385
+SHA256 (nextcloud-16.0.5.tar.bz2) =
hwnGT6d2/XMcjl8asl1ZKi5pDl4YqBYBzM82N5X65VE=
+SIZE (nextcloud-16.0.5.tar.bz2) = 62129676
Index: pkg/PLIST
===
RCS file: /cvs/ports/www/nextcloud/pkg/PLIST,v
retrieving revision 1.30
diff -u -p -r1.30 PLIST
--- pkg/PLIST 21 Aug 2019 13:26:01 - 1.30
+++ pkg/PLIST 26 Sep 2019 17:52:22 -
@@ -5050,8 +5050,12 @@ nextcloud/apps/accessibility/l10n/he.js
nextcloud/apps/accessibility/l10n/he.json
nextcloud/apps/accessibility/l10n/hi_IN.js
nextcloud/apps/accessibility/l10n/hi_IN.json
+nextcloud/apps/accessibility/l10n/hr.js
+nextcloud/apps/accessibility/l10n/hr.json
nextcloud/apps/accessibility/l10n/hu.js
nextcloud/apps/accessibility/l10n/hu.json
+nextcloud/apps/accessibility/l10n/id.js
+nextcloud/apps/accessibility/l10n/id.json
nextcloud/apps/accessibility/l10n/is.js
nextcloud/apps/accessibility/l10n/is.json
nextcloud/apps/accessibility/l10n/it.js
@@ -5064,6 +5068,8 @@ nextcloud/apps/accessibility/l10n/lt_LT.
nextcloud/apps/accessibility/l10n/lt_LT.json
nextcloud/apps/accessibility/l10n/mk.js
nextcloud/apps/accessibility/l10n/mk.json
+nextcloud/apps/accessibility/l10n/nb.js
+nextcloud/apps/accessibility/l10n/nb.json
nextcloud/apps/accessibility/l10n/nl.js
nextcloud/apps/accessibility/l10n/nl.json
nextcloud/apps/accessibility/l10n/nn_NO.js
@@ -5092,6 +5098,8 @@ nextcloud/apps/accessibility/l10n/tr.js
nextcloud/apps/accessibility/l10n/tr.json
nextcloud/apps/accessibility/l10n/uk.js
nextcloud/apps/accessibility/l10n/uk.json
+nextcloud/apps/accessibility/l10n/vi.js
+nextcloud/apps/accessibility/l10n/vi.json
nextcloud/apps/accessibility/l10n/zh_CN.js
nextcloud/apps/accessibility/l10n/zh_CN.json
nextcloud/apps/accessibility/l10n/zh_TW.js
@@ -5785,6 +5793,8 @@ nextcloud/apps/dav/l10n/gl.js
nextcloud/apps/dav/l10n/gl.json
nextcloud/apps/dav/l10n/he.js
nextcloud/apps/dav/l10n/he.json
+nextcloud/apps/dav/l10n/hr.js
+nextcloud/apps/dav/l10n/hr.json
nextcloud/apps/dav/l10n/hu.js
nextcloud/apps/dav/l10n/hu.json
nextcloud/apps/dav/l10n/hu_HU.js
@@ -6618,6 +6628,8 @@ nextcloud/apps/federation/l10n/gl.js
nextcloud/apps/federation/l10n/gl.json
nextcloud/apps/federation/l10n/he.js
nextcloud/apps/federation/l10n/he.json
+nextcloud/apps/federation/l10n/hr.js
+nextcloud/apps/federation/l10n/hr.json
nextcloud/apps/federation/l10n/hu.js
nextcloud/apps/federation/l10n/hu.json
nextcloud/apps/federation/l10n/hu_HU.js
@@ -6642,6 +6654,8 @@ nextcloud/apps/federation/l10n/lt_LT.js
nextcloud/apps/federation/l10n/lt_LT.json
nextcloud/apps/federation/l10n/lv.js
nextcloud/apps/federation/l10n/lv.json
+nextcloud/apps/federation/l10n/mk.js
+nextcloud/apps/federation/l10n/mk.json
nextcloud/apps/federation/l10n/mn.js
nextcloud/apps/federation/l10n/mn.json
nextcloud/apps/federation/l10n/nb.js
@@ -8100,6 +8114,8 @@ nextcloud/apps/files_rightclick/l10n/gl.
nextcloud/apps/files_rightclick/l10n/gl.json
nextcloud/apps/files_rightclick/l10n/he.js
nextcloud/apps/files_rightclick/l10n/he.json
+nextcloud/apps/files_rightclick/l10n/hr.js
+nextcloud/apps/files_rightclick/l10n/hr.json
nextcloud/apps/files_rightclick/l10n/hu.js
nextcloud/apps/files_rightclick/l10n/hu.json
nextcloud/apps/files_rightclick/l10n/is.js
@@ -8654,6 +8670,8 @@ nextcloud/apps/files_texteditor/l10n/gl.
nextcloud/apps/files_texteditor/l10n/gl.json
nextcloud/apps/files_texteditor/l10n/he.js
nextcloud/apps/files_texteditor/l10n/he.json
+nextcloud/apps/files_texteditor/l10n/hr.js
+nextcloud/apps/files_texteditor/l10n/hr.json
nextcloud/apps/files_texteditor/l10n/hu.js
nextcloud/apps/files_texteditor/l10n/hu.json
nextcloud/apps/files_texteditor/l10n/hy.js
@@ -9366,6 +9384,8 @@ nextcloud/apps/firstrunwizard/l10n/gl.js
nextcloud/apps/firstrunwizard/l10n/gl.json
nextcloud/apps/firstrunwizard/l10n/he.js
nextcloud/apps/firstrunwizard/l10n/he.json
Re: firefox does not see printer
On Thu, 26 Sep 2019 at 17:58:42 +0200, Sebastien Marie wrote:
> On Thu, Sep 26, 2019 at 04:36:08PM +0200, Jan Stary wrote:
> > This is current/amd64 with firefox-68.0.2
> >
> > Firefox does not offer any prtinters in the printing dialogue
> > except (Print to file").
> >
> > lpd/lpr itself works fine. This is my /etc/printcap:
> > lp:lp=:rm=147.32.232.36:rp=lp:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs:
> > Each of "date | lpr" and "lpr file.pdf" works.
> >
> > I removed the entire ~/.mozilla directory fo make sure
> > it is not some of my firefox settings.
> >
> > Is this known?
> > Is a fix known?
> >
> > Jan
> >
>
> It is a bit complex to explain, but in short: you can't use lpr with firefox.
>
> If I recall correctly, the problem is firefox removed the support of
> Postscript
> option, and the side effect was "Print using lpr" was removed too (it is
> declared as "postscript")
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1322756
> https://bugzilla.mozilla.org/show_bug.cgi?id=1425188
>
> I don't recall if it is something that should be corrected in GTK ("lpr" needs
> to be declared as accepting pdf) or in firefox.
Yeah, this makes the "Print to LPR" option show up in Firefox's
print dialog but this seems like something that should be addressed
upstream with Gtk if this is to be properly fixed.
Index: modules/printbackends/lpr/gtkprintbackendlpr.c
--- modules/printbackends/lpr/gtkprintbackendlpr.c.orig
+++ modules/printbackends/lpr/gtkprintbackendlpr.c
@@ -390,9 +390,12 @@ gtk_print_backend_lpr_init (GtkPrintBackendLpr *backen
{
GtkPrinter *printer;
- printer = gtk_printer_new (_("Print to LPR"),
-GTK_PRINT_BACKEND (backend),
-TRUE);
+ printer = g_object_new (GTK_TYPE_PRINTER,
+ "name", _("Print to LPR"),
+ "backend", backend,
+ "is-virtual", TRUE,
+ "accepts-pdf", TRUE,
+ NULL);
gtk_printer_set_has_details (printer, TRUE);
gtk_printer_set_icon_name (printer, "printer");
gtk_printer_set_is_active (printer, TRUE);
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2019/09/26 11:21:42 Modified files: mail/opensmtpd-filters/libopensmtpd: Makefile distinfo Log message: Fix libopensmtpd to correctly interpret IPv6 addresses, which caused crashes after smtpd changed the forward. Bug found and fix tested by mikolaj kucharski name OK jasper@
Re: lang/go: make test vs PORTS_PRIVSEP=Yes
On 19-09-26 17:36:25, Theo Buehler wrote:
> On Fri, Sep 27, 2019 at 01:32:38AM +1000, Joel Sing wrote:
> > On 19-09-26 16:14:44, Theo Buehler wrote:
> > > On Thu, Sep 26, 2019 at 11:09:16PM +1000, Joel Sing wrote:
> > > > On 19-09-26 13:06:51, Stuart Henderson wrote:
> > > > > On 2019/09/26 09:44, Theo Buehler wrote:
> > > > > > I noticed two problems with go's 'make test' when PORTS_PRIVSEP=Yes:
> > > > > > both having to do with _pbuild's home being /nonexistent:
> > > > > >
> > > > > > failed to initialize build cache at /nonexistent/.cache/go-build:
> > > > > > mkdir /nonexistent: permission denied
> > > > > >
> > > > > > and
> > > > > >
> > > > > > --- FAIL: TestUserHomeDir (0.00s)
> > > > > > os_test.go:2350: stat /nonexistent: no such file or directory
> > > > > > FAIL
> > > > > >
> > > > > > both problems can be worked around by setting the GOCACHE and HOME
> > > > > > environment variables to something different than /nonexistent.
> > > > > >
> > > > > > Since do-build alreday sets GOCACHE=${WRKDIST}/go-cache, it seems
> > > > > > reasonable to do the same for do-test independently of
> > > > > > PORTS_PRIVSEP.
> > > > >
> > > > > FWIW that one's OK with me.
> > > > >
> > > > > > I'm less sure about the proper solution for TestHomeDir and would
> > > > > > like
> > > > > > to have some advice on that. Setting HOME to ${WRKDIST} or a
> > > > > > temporary
> > > > > > directory works and is in line with the custom PATH, but seems very
> > > > > > kludgy and might have undesirable side effects for other tests in
> > > > > > the
> > > > > > future. One could patch the TestHomeDir test to skip the Stat and
> > > > > > IsDir
> > > > > > part if the user is _pbuild. I'm not too worried about the
> > > > > > TestHomeDir
> > > > > > per se but rather the fact that its failure takes out a sizable
> > > > > > number
> > > > > > of later tests.
> > > > >
> > > > > Patching the TestHomeDir test might also have side effects in the
> > > > > future..
> > > > > Setting PORTHOME=${WRKDIR} is fairly common in ports in general, so
> > > > > that
> > > > > would probably be my first choice (I think it's better in WRKDIR
> > > > > rather
> > > > > than WRKDIST).
> > > >
> > > > Agreed. It is going to be preferable to set HOME to a sensible
> > > > location, rather than patch tests - ok jsing@.
> > >
> > > Ok, thanks.
> > >
> > > Setting PORTHOME=${WRKDIST} works directly. Using WRKDIR does work in
> > > the sense that all tests pass, but it leads to an ugly complaint about
> > > a missing GOPATH:
> > >
> > > $ make test
> > > ===> Regression tests for go-1.13
> > > missing $GOPATH
> > >
> > > To avoid this complaint, I added GOPATH=WRKDIR to the environment. Also,
> > > the reason why the poisoned PORTHOME didn't work is the custom do-test
> > > target that bypasses the default test environment. After pulling in
> > > ALL_TEST_ENV, one could now make use of the TEST_ENV mechanism, but I
> > > don't want to interfere too much with jsing's choices.
> > >
> > > Index: Makefile
> > > ===
> > > RCS file: /var/cvs/ports/lang/go/Makefile,v
> > > retrieving revision 1.71
> > > diff -u -p -r1.71 Makefile
> > > --- Makefile 15 Sep 2019 02:00:34 - 1.71
> > > +++ Makefile 26 Sep 2019 14:10:47 -
> > > @@ -34,6 +34,7 @@ SEPARATE_BUILD =simple
> > > CONFIGURE_STYLE =None
> > > SUBST_VARS = GOCFG
> > >
> > > +PORTHOME = ${WRKDIR}
> > > WRKDIST =${WRKDIR}/go
> > > WRKSRC = ${WRKDIST}/src
> > >
> > > @@ -94,8 +95,11 @@ do-build:
> > > do-test:
> > > @cd ${WRKSRC} && \
> > > ulimit -d $$(ulimit -H -d) -n 256 && \
> > > + ${SETENV} ${ALL_TEST_ENV} \
> > > CC="${CC}" \
> > > CXX="${CXX}" \
> > > + GOCACHE=${WRKDIST}/go-cache \
> > > + GOPATH=${WRKDIR} \
> > > PATH=${WRKDIST}/bin:${PATH} \
> > > /bin/ksh -c "exec 3>&-; exec 4>&-; ./run.bash"
> >
> > Given this is already a special snowflake, it might be simpler to
> > just do:
>
> this (with WRKDIR replaced with WRKDIST) was my initial patch.
>
> This also has this problem:
>
> ===> Regression tests for go-1.13
> missing $GOPATH
>
> I'm fine with that if that's not a concern.
That's easily fixed/avoided as well:
Index: Makefile
===
RCS file: /cvs/ports/lang/go/Makefile,v
retrieving revision 1.71
diff -u -p -u -p -r1.71 Makefile
--- Makefile15 Sep 2019 02:00:34 - 1.71
+++ Makefile26 Sep 2019 16:20:10 -
@@ -96,6 +96,9 @@ do-test:
ulimit -d $$(ulimit -H -d) -n 256 && \
CC="${CC}" \
CXX="${CXX}" \
+ GOCACHE=${WRKDIST}/go-cache \
+ GOPATH=${WRKDIST} \
+ HOME=${WRKDIR} \
PATH=${WRKDIST}/bin:${PATH} \
Re: firefox does not see printer
On Thu, Sep 26, 2019 at 04:36:08PM +0200, Jan Stary wrote:
> This is current/amd64 with firefox-68.0.2
>
> Firefox does not offer any prtinters in the printing dialogue
> except (Print to file").
>
> lpd/lpr itself works fine. This is my /etc/printcap:
> lp:lp=:rm=147.32.232.36:rp=lp:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs:
> Each of "date | lpr" and "lpr file.pdf" works.
>
> I removed the entire ~/.mozilla directory fo make sure
> it is not some of my firefox settings.
>
> Is this known?
> Is a fix known?
>
> Jan
>
It is a bit complex to explain, but in short: you can't use lpr with firefox.
If I recall correctly, the problem is firefox removed the support of Postscript
option, and the side effect was "Print using lpr" was removed too (it is
declared as "postscript")
https://bugzilla.mozilla.org/show_bug.cgi?id=1322756
https://bugzilla.mozilla.org/show_bug.cgi?id=1425188
I don't recall if it is something that should be corrected in GTK ("lpr" needs
to be declared as accepting pdf) or in firefox.
So if you want to stay with lpr, you have the "print to file" and next print
this file (it is what I am doing, but I don't print very often).
--
Sebastien Marie
Re: add pledge to devel/cvsweb
On Thu, Sep 26, 2019 at 05:27:08PM +0200, Solene Rapenne wrote:
> Hi, now that we have OpenBSD::pledge I thought it would be nice to use
> it in devel/cvsweb
>
> I've been able to tight it to "rpath proc exec prot_exec", removing
> wpath and cpath was possible by commenting lines piping STDERROR to
> /dev/null, that doesn't mean creating dev/null is not required anymore,
> it's still required for cvsweb to work correctly (due to rlog I think).
>
> I updated pkg/README because this requires OpenBSD/Pledge.pm and a so
> file to be copied into the chroot too.
>
> I had some testing on www repository by lot of people and it worked
> perfectly.
Be careful that error messages do not show up on the web pages
generated by not redirecting stderr...
-Otto
>
>
> Index: Makefile
> ===
> RCS file: /data/cvs/ports/devel/cvsweb/Makefile,v
> retrieving revision 1.62
> diff -u -p -r1.62 Makefile
> --- Makefile 12 Jul 2019 20:44:07 - 1.62
> +++ Makefile 26 Sep 2019 14:24:53 -
> @@ -3,7 +3,7 @@
> COMMENT= CGI script to browse CVS repository trees
>
> DISTNAME=cvsweb-2.0.6
> -REVISION=27
> +REVISION=28
> CATEGORIES= devel www
> HOMEPAGE=http://www.freebsd.org/projects/cvsweb.html
>
> Index: patches/patch-cvsweb_cgi
> ===
> RCS file: /data/cvs/ports/devel/cvsweb/patches/patch-cvsweb_cgi,v
> retrieving revision 1.13
> diff -u -p -r1.13 patch-cvsweb_cgi
> --- patches/patch-cvsweb_cgi 7 Apr 2013 20:07:24 - 1.13
> +++ patches/patch-cvsweb_cgi 26 Sep 2019 15:21:46 -
> @@ -1,6 +1,7 @@
> $OpenBSD: patch-cvsweb_cgi,v 1.13 2013/04/07 20:07:24 naddy Exp $
> cvsweb.cgi.orig Thu Sep 26 22:56:05 2002
> -+++ cvsweb.cgi Sun Apr 7 14:15:55 2013
> +Index: cvsweb.cgi
> +--- cvsweb.cgi.orig
> cvsweb.cgi
> @@ -1,4 +1,4 @@
> -#!/usr/bin/perl -wT
> +#!/usr/bin/perl -w
> @@ -37,7 +38,27 @@ $OpenBSD: patch-cvsweb_cgi,v 1.13 2013/0
> );
>
> @LOGSORTKEYS = qw(cvs date rev);
> -@@ -2014,20 +2009,6 @@ sub doDiff($$) {
> +@@ -249,7 +244,10 @@ EOM
> +
> + use Time::Local ();
> + use IPC::Open2 qw(open2);
> ++use OpenBSD::Pledge;
> +
> ++pledge( qw( rpath proc exec prot_exec ) ) || die "Can't pledge: $!";
> ++
> + # Check if the zlib C library interface is installed, and if yes
> + # we can avoid using the extra gzip process.
> + eval { require Compress::Zlib; };
> +@@ -1578,7 +1576,7 @@ sub openOutputFilter() {
> + open(STDOUT, "|-") and return;
> +
> + # child of child
> +-open(STDERR, '>/dev/null');
> ++#open(STDERR, '>/dev/null');
> + exec($output_filter) or exit -1;
> + }
> +
> +@@ -2014,20 +2012,6 @@ sub doDiff($$) {
> my @difftype = @{$difftype->{'opts'}};
> my $human_readable = $difftype->{'colored'};
>
> @@ -58,7 +79,24 @@ $OpenBSD: patch-cvsweb_cgi,v 1.13 2013/0
> if ($human_readable) {
> if ($hr_ignwhite) {
> push @difftype, '-w';
> -@@ -2658,7 +2639,7 @@ sub printLog($;$) {
> +@@ -2128,14 +2112,14 @@ sub getDirLogs($$@) {
> +
> + #can't use -r as - is allowed in tagnames, but
> misinterpreated by rlog..
> + if (!open($fh, "-|")) {# child
> +-open(STDERR, '>/dev/null'); # rlog may complain; ignore.
> ++#open(STDERR, '>/dev/null'); # rlog may complain;
> ignore.
> + openOutputFilter();
> + exec($CMD{rlog}, @files) or exit -1;
> + }
> + } else {
> +
> + if (!open($fh, "-|")) {# child
> +-open(STDERR, '>/dev/null'); # rlog may complain; ignore.
> ++#open(STDERR, '>/dev/null'); # rlog may complain;
> ignore.
> + openOutputFilter();
> + exec($CMD{rlog}, '-r', @files) or exit -1;
> + }
> +@@ -2658,7 +2642,7 @@ sub printLog($;$) {
> if (/^1\.1\.1\.\d+$/) {
> print " (vendor branch)";
> }
> Index: pkg/README
> ===
> RCS file: /data/cvs/ports/devel/cvsweb/pkg/README,v
> retrieving revision 1.18
> diff -u -p -r1.18 README
> --- pkg/README2 May 2019 18:58:38 - 1.18
> +++ pkg/README26 Sep 2019 14:24:47 -
> @@ -22,7 +22,7 @@ cd /var/www/usr
> mkdir -p bin lib libdata/perl5 libexec
>
> cd /var/www/usr/libdata/perl5
> -mkdir -p File IPC Time warnings `arch -s`-openbsd/auto/{Cwd,Fcntl} unicore
> +mkdir -p File IPC Time warnings `arch
> -s`-openbsd/auto/{Cwd,Fcntl,OpenBSD/Pledge} `arch -s`-openbsd/OpenBSD unicore
>
> # The "annotate" function requires this empty file:
> #
> @@ -72,6 +72,8 @@ cp -p /usr/libdata/perl5/`arch -s`-openb
> cp -p /usr/libdata/perl5/`arch -s`-openbsd/DynaLoader.pm .
> cp -p /usr/libdata/perl5/`arch -s`-openbsd/Fcntl.pm .
> cp -p
Re: firefox does not see printer
On Thu, Sep 26, 2019 at 04:36:08PM +0200, Jan Stary wrote: > This is current/amd64 with firefox-68.0.2 > > Firefox does not offer any prtinters in the printing dialogue > except (Print to file"). > > lpd/lpr itself works fine. This is my /etc/printcap: > lp:lp=:rm=147.32.232.36:rp=lp:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs: > Each of "date | lpr" and "lpr file.pdf" works. > > I removed the entire ~/.mozilla directory fo make sure > it is not some of my firefox settings. > > Is this known? > Is a fix known? > > Jan > I know with gtk2 you had to add something like gtk-print-backends = "file,lpr" to your ~/.gtkrc-2.0 config file before firefox would offer up lpr printing. I'm guessing you have to do something similar in the gtk3 settings file, which is located in ~/.config/gtk-3.0/settings.ini. Everything should go under a [Settings] header. -- James Turner
Re: lang/go: make test vs PORTS_PRIVSEP=Yes
On Fri, Sep 27, 2019 at 01:32:38AM +1000, Joel Sing wrote:
> On 19-09-26 16:14:44, Theo Buehler wrote:
> > On Thu, Sep 26, 2019 at 11:09:16PM +1000, Joel Sing wrote:
> > > On 19-09-26 13:06:51, Stuart Henderson wrote:
> > > > On 2019/09/26 09:44, Theo Buehler wrote:
> > > > > I noticed two problems with go's 'make test' when PORTS_PRIVSEP=Yes:
> > > > > both having to do with _pbuild's home being /nonexistent:
> > > > >
> > > > > failed to initialize build cache at /nonexistent/.cache/go-build:
> > > > > mkdir /nonexistent: permission denied
> > > > >
> > > > > and
> > > > >
> > > > > --- FAIL: TestUserHomeDir (0.00s)
> > > > > os_test.go:2350: stat /nonexistent: no such file or directory
> > > > > FAIL
> > > > >
> > > > > both problems can be worked around by setting the GOCACHE and HOME
> > > > > environment variables to something different than /nonexistent.
> > > > >
> > > > > Since do-build alreday sets GOCACHE=${WRKDIST}/go-cache, it seems
> > > > > reasonable to do the same for do-test independently of PORTS_PRIVSEP.
> > > >
> > > > FWIW that one's OK with me.
> > > >
> > > > > I'm less sure about the proper solution for TestHomeDir and would like
> > > > > to have some advice on that. Setting HOME to ${WRKDIST} or a
> > > > > temporary
> > > > > directory works and is in line with the custom PATH, but seems very
> > > > > kludgy and might have undesirable side effects for other tests in the
> > > > > future. One could patch the TestHomeDir test to skip the Stat and
> > > > > IsDir
> > > > > part if the user is _pbuild. I'm not too worried about the TestHomeDir
> > > > > per se but rather the fact that its failure takes out a sizable number
> > > > > of later tests.
> > > >
> > > > Patching the TestHomeDir test might also have side effects in the
> > > > future..
> > > > Setting PORTHOME=${WRKDIR} is fairly common in ports in general, so that
> > > > would probably be my first choice (I think it's better in WRKDIR rather
> > > > than WRKDIST).
> > >
> > > Agreed. It is going to be preferable to set HOME to a sensible
> > > location, rather than patch tests - ok jsing@.
> >
> > Ok, thanks.
> >
> > Setting PORTHOME=${WRKDIST} works directly. Using WRKDIR does work in
> > the sense that all tests pass, but it leads to an ugly complaint about
> > a missing GOPATH:
> >
> > $ make test
> > ===> Regression tests for go-1.13
> > missing $GOPATH
> >
> > To avoid this complaint, I added GOPATH=WRKDIR to the environment. Also,
> > the reason why the poisoned PORTHOME didn't work is the custom do-test
> > target that bypasses the default test environment. After pulling in
> > ALL_TEST_ENV, one could now make use of the TEST_ENV mechanism, but I
> > don't want to interfere too much with jsing's choices.
> >
> > Index: Makefile
> > ===
> > RCS file: /var/cvs/ports/lang/go/Makefile,v
> > retrieving revision 1.71
> > diff -u -p -r1.71 Makefile
> > --- Makefile15 Sep 2019 02:00:34 - 1.71
> > +++ Makefile26 Sep 2019 14:10:47 -
> > @@ -34,6 +34,7 @@ SEPARATE_BUILD = simple
> > CONFIGURE_STYLE = None
> > SUBST_VARS = GOCFG
> >
> > +PORTHOME = ${WRKDIR}
> > WRKDIST = ${WRKDIR}/go
> > WRKSRC = ${WRKDIST}/src
> >
> > @@ -94,8 +95,11 @@ do-build:
> > do-test:
> > @cd ${WRKSRC} && \
> > ulimit -d $$(ulimit -H -d) -n 256 && \
> > + ${SETENV} ${ALL_TEST_ENV} \
> > CC="${CC}" \
> > CXX="${CXX}" \
> > + GOCACHE=${WRKDIST}/go-cache \
> > + GOPATH=${WRKDIR} \
> > PATH=${WRKDIST}/bin:${PATH} \
> > /bin/ksh -c "exec 3>&-; exec 4>&-; ./run.bash"
>
> Given this is already a special snowflake, it might be simpler to
> just do:
this (with WRKDIR replaced with WRKDIST) was my initial patch.
This also has this problem:
===> Regression tests for go-1.13
missing $GOPATH
I'm fine with that if that's not a concern.
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/go/Makefile,v
> retrieving revision 1.71
> diff -u -p -u -p -r1.71 Makefile
> --- Makefile 15 Sep 2019 02:00:34 - 1.71
> +++ Makefile 26 Sep 2019 15:31:29 -
> @@ -96,6 +96,8 @@ do-test:
> ulimit -d $$(ulimit -H -d) -n 256 && \
> CC="${CC}" \
> CXX="${CXX}" \
> + GOCACHE=${WRKDIST}/go-cache \
> + HOME=${WRKDIR} \
> PATH=${WRKDIST}/bin:${PATH} \
> /bin/ksh -c "exec 3>&-; exec 4>&-; ./run.bash"
>
>
Re: lang/go: make test vs PORTS_PRIVSEP=Yes
On 19-09-26 16:14:44, Theo Buehler wrote:
> On Thu, Sep 26, 2019 at 11:09:16PM +1000, Joel Sing wrote:
> > On 19-09-26 13:06:51, Stuart Henderson wrote:
> > > On 2019/09/26 09:44, Theo Buehler wrote:
> > > > I noticed two problems with go's 'make test' when PORTS_PRIVSEP=Yes:
> > > > both having to do with _pbuild's home being /nonexistent:
> > > >
> > > > failed to initialize build cache at /nonexistent/.cache/go-build: mkdir
> > > > /nonexistent: permission denied
> > > >
> > > > and
> > > >
> > > > --- FAIL: TestUserHomeDir (0.00s)
> > > > os_test.go:2350: stat /nonexistent: no such file or directory
> > > > FAIL
> > > >
> > > > both problems can be worked around by setting the GOCACHE and HOME
> > > > environment variables to something different than /nonexistent.
> > > >
> > > > Since do-build alreday sets GOCACHE=${WRKDIST}/go-cache, it seems
> > > > reasonable to do the same for do-test independently of PORTS_PRIVSEP.
> > >
> > > FWIW that one's OK with me.
> > >
> > > > I'm less sure about the proper solution for TestHomeDir and would like
> > > > to have some advice on that. Setting HOME to ${WRKDIST} or a temporary
> > > > directory works and is in line with the custom PATH, but seems very
> > > > kludgy and might have undesirable side effects for other tests in the
> > > > future. One could patch the TestHomeDir test to skip the Stat and IsDir
> > > > part if the user is _pbuild. I'm not too worried about the TestHomeDir
> > > > per se but rather the fact that its failure takes out a sizable number
> > > > of later tests.
> > >
> > > Patching the TestHomeDir test might also have side effects in the future..
> > > Setting PORTHOME=${WRKDIR} is fairly common in ports in general, so that
> > > would probably be my first choice (I think it's better in WRKDIR rather
> > > than WRKDIST).
> >
> > Agreed. It is going to be preferable to set HOME to a sensible
> > location, rather than patch tests - ok jsing@.
>
> Ok, thanks.
>
> Setting PORTHOME=${WRKDIST} works directly. Using WRKDIR does work in
> the sense that all tests pass, but it leads to an ugly complaint about
> a missing GOPATH:
>
> $ make test
> ===> Regression tests for go-1.13
> missing $GOPATH
>
> To avoid this complaint, I added GOPATH=WRKDIR to the environment. Also,
> the reason why the poisoned PORTHOME didn't work is the custom do-test
> target that bypasses the default test environment. After pulling in
> ALL_TEST_ENV, one could now make use of the TEST_ENV mechanism, but I
> don't want to interfere too much with jsing's choices.
>
> Index: Makefile
> ===
> RCS file: /var/cvs/ports/lang/go/Makefile,v
> retrieving revision 1.71
> diff -u -p -r1.71 Makefile
> --- Makefile 15 Sep 2019 02:00:34 - 1.71
> +++ Makefile 26 Sep 2019 14:10:47 -
> @@ -34,6 +34,7 @@ SEPARATE_BUILD =simple
> CONFIGURE_STYLE =None
> SUBST_VARS = GOCFG
>
> +PORTHOME = ${WRKDIR}
> WRKDIST =${WRKDIR}/go
> WRKSRC = ${WRKDIST}/src
>
> @@ -94,8 +95,11 @@ do-build:
> do-test:
> @cd ${WRKSRC} && \
> ulimit -d $$(ulimit -H -d) -n 256 && \
> + ${SETENV} ${ALL_TEST_ENV} \
> CC="${CC}" \
> CXX="${CXX}" \
> + GOCACHE=${WRKDIST}/go-cache \
> + GOPATH=${WRKDIR} \
> PATH=${WRKDIST}/bin:${PATH} \
> /bin/ksh -c "exec 3>&-; exec 4>&-; ./run.bash"
Given this is already a special snowflake, it might be simpler to
just do:
Index: Makefile
===
RCS file: /cvs/ports/lang/go/Makefile,v
retrieving revision 1.71
diff -u -p -u -p -r1.71 Makefile
--- Makefile15 Sep 2019 02:00:34 - 1.71
+++ Makefile26 Sep 2019 15:31:29 -
@@ -96,6 +96,8 @@ do-test:
ulimit -d $$(ulimit -H -d) -n 256 && \
CC="${CC}" \
CXX="${CXX}" \
+ GOCACHE=${WRKDIST}/go-cache \
+ HOME=${WRKDIR} \
PATH=${WRKDIST}/bin:${PATH} \
/bin/ksh -c "exec 3>&-; exec 4>&-; ./run.bash"
Re: [UPDATE] security/py-ropper
On Thu, Sep 26, 2019 at 07:52:33AM +0200, Remi Pointel wrote:
> Hi,
>
> this diff updates ropper to latest release.
>
> Ok?
>
> Cheers,
>
> Remi.
OK.
> Index: Makefile
> ===
> RCS file: /cvs/ports/security/py-ropper/Makefile,v
> retrieving revision 1.5
> diff -u -p -u -p -r1.5 Makefile
> --- Makefile 12 Jul 2019 20:49:35 - 1.5
> +++ Makefile 26 Sep 2019 05:50:55 -
> @@ -2,10 +2,9 @@
>
> COMMENT =rop gadget finder and binary information tool
>
> -MODPY_EGG_VERSION = 1.11.10
> +MODPY_EGG_VERSION = 1.12.5
> DISTNAME = ropper-${MODPY_EGG_VERSION}
> PKGNAME =py-${DISTNAME}
> -REVISION = 1
>
> CATEGORIES = security
>
> Index: distinfo
> ===
> RCS file: /cvs/ports/security/py-ropper/distinfo,v
> retrieving revision 1.2
> diff -u -p -u -p -r1.2 distinfo
> --- distinfo 2 Jan 2019 06:33:17 - 1.2
> +++ distinfo 26 Sep 2019 05:50:55 -
> @@ -1,2 +1,2 @@
> -SHA256 (ropper-1.11.10.tar.gz) = uNFDnYpu97k3GEcrAojuiKWVNyMEZ3LwNf6YmxweXW4=
> -SIZE (ropper-1.11.10.tar.gz) = 65765
> +SHA256 (ropper-1.12.5.tar.gz) = DevhcizzVtgjyravsr632K1sZEFHl4wf9UpbNEicdBg=
> +SIZE (ropper-1.12.5.tar.gz) = 68836
> Index: patches/patch-ropper_console_py
> ===
> RCS file: patches/patch-ropper_console_py
> diff -N patches/patch-ropper_console_py
> --- patches/patch-ropper_console_py 31 Mar 2019 04:39:11 - 1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,16 +0,0 @@
> -$OpenBSD: patch-ropper_console_py,v 1.1 2019/03/31 04:39:11 jasper Exp $
> -
> -UnboundLocalError: local variable 'f' referenced before assignment
> -
> -Index: ropper/console.py
> ropper/console.py.orig
> -+++ ropper/console.py
> -@@ -254,7 +254,7 @@ class Console(cmd.Cmd):
> - elif format == 'S':
> - f = 'string'
> - else:
> --raise RopperError('wrong format: %s' % f)
> -+raise RopperError('wrong format: %s' % format)
> -
> - self.__cprinter.println(self.__rs.asm(code, arch, f))
> -
add pledge to devel/cvsweb
Hi, now that we have OpenBSD::pledge I thought it would be nice to use
it in devel/cvsweb
I've been able to tight it to "rpath proc exec prot_exec", removing
wpath and cpath was possible by commenting lines piping STDERROR to
/dev/null, that doesn't mean creating dev/null is not required anymore,
it's still required for cvsweb to work correctly (due to rlog I think).
I updated pkg/README because this requires OpenBSD/Pledge.pm and a so
file to be copied into the chroot too.
I had some testing on www repository by lot of people and it worked
perfectly.
Index: Makefile
===
RCS file: /data/cvs/ports/devel/cvsweb/Makefile,v
retrieving revision 1.62
diff -u -p -r1.62 Makefile
--- Makefile12 Jul 2019 20:44:07 - 1.62
+++ Makefile26 Sep 2019 14:24:53 -
@@ -3,7 +3,7 @@
COMMENT= CGI script to browse CVS repository trees
DISTNAME= cvsweb-2.0.6
-REVISION= 27
+REVISION= 28
CATEGORIES=devel www
HOMEPAGE= http://www.freebsd.org/projects/cvsweb.html
Index: patches/patch-cvsweb_cgi
===
RCS file: /data/cvs/ports/devel/cvsweb/patches/patch-cvsweb_cgi,v
retrieving revision 1.13
diff -u -p -r1.13 patch-cvsweb_cgi
--- patches/patch-cvsweb_cgi7 Apr 2013 20:07:24 - 1.13
+++ patches/patch-cvsweb_cgi26 Sep 2019 15:21:46 -
@@ -1,6 +1,7 @@
$OpenBSD: patch-cvsweb_cgi,v 1.13 2013/04/07 20:07:24 naddy Exp $
cvsweb.cgi.origThu Sep 26 22:56:05 2002
-+++ cvsweb.cgi Sun Apr 7 14:15:55 2013
+Index: cvsweb.cgi
+--- cvsweb.cgi.orig
cvsweb.cgi
@@ -1,4 +1,4 @@
-#!/usr/bin/perl -wT
+#!/usr/bin/perl -w
@@ -37,7 +38,27 @@ $OpenBSD: patch-cvsweb_cgi,v 1.13 2013/0
);
@LOGSORTKEYS = qw(cvs date rev);
-@@ -2014,20 +2009,6 @@ sub doDiff($$) {
+@@ -249,7 +244,10 @@ EOM
+
+ use Time::Local ();
+ use IPC::Open2 qw(open2);
++use OpenBSD::Pledge;
+
++pledge( qw( rpath proc exec prot_exec ) ) || die "Can't pledge: $!";
++
+ # Check if the zlib C library interface is installed, and if yes
+ # we can avoid using the extra gzip process.
+ eval { require Compress::Zlib; };
+@@ -1578,7 +1576,7 @@ sub openOutputFilter() {
+ open(STDOUT, "|-") and return;
+
+ # child of child
+- open(STDERR, '>/dev/null');
++ #open(STDERR, '>/dev/null');
+ exec($output_filter) or exit -1;
+ }
+
+@@ -2014,20 +2012,6 @@ sub doDiff($$) {
my @difftype = @{$difftype->{'opts'}};
my $human_readable = $difftype->{'colored'};
@@ -58,7 +79,24 @@ $OpenBSD: patch-cvsweb_cgi,v 1.13 2013/0
if ($human_readable) {
if ($hr_ignwhite) {
push @difftype, '-w';
-@@ -2658,7 +2639,7 @@ sub printLog($;$) {
+@@ -2128,14 +2112,14 @@ sub getDirLogs($$@) {
+
+ #can't use -r as - is allowed in tagnames, but
misinterpreated by rlog..
+ if (!open($fh, "-|")) {# child
+- open(STDERR, '>/dev/null'); # rlog may complain; ignore.
++ #open(STDERR, '>/dev/null'); # rlog may complain;
ignore.
+ openOutputFilter();
+ exec($CMD{rlog}, @files) or exit -1;
+ }
+ } else {
+
+ if (!open($fh, "-|")) {# child
+- open(STDERR, '>/dev/null'); # rlog may complain; ignore.
++ #open(STDERR, '>/dev/null'); # rlog may complain;
ignore.
+ openOutputFilter();
+ exec($CMD{rlog}, '-r', @files) or exit -1;
+ }
+@@ -2658,7 +2642,7 @@ sub printLog($;$) {
if (/^1\.1\.1\.\d+$/) {
print " (vendor branch)";
}
Index: pkg/README
===
RCS file: /data/cvs/ports/devel/cvsweb/pkg/README,v
retrieving revision 1.18
diff -u -p -r1.18 README
--- pkg/README 2 May 2019 18:58:38 - 1.18
+++ pkg/README 26 Sep 2019 14:24:47 -
@@ -22,7 +22,7 @@ cd /var/www/usr
mkdir -p bin lib libdata/perl5 libexec
cd /var/www/usr/libdata/perl5
-mkdir -p File IPC Time warnings `arch -s`-openbsd/auto/{Cwd,Fcntl} unicore
+mkdir -p File IPC Time warnings `arch
-s`-openbsd/auto/{Cwd,Fcntl,OpenBSD/Pledge} `arch -s`-openbsd/OpenBSD unicore
# The "annotate" function requires this empty file:
#
@@ -72,6 +72,8 @@ cp -p /usr/libdata/perl5/`arch -s`-openb
cp -p /usr/libdata/perl5/`arch -s`-openbsd/DynaLoader.pm .
cp -p /usr/libdata/perl5/`arch -s`-openbsd/Fcntl.pm .
cp -p /usr/libdata/perl5/`arch -s`-openbsd/auto/Fcntl/Fcntl.so ./auto/Fcntl/
+cp -p /usr/libdata/perl5/`arch -s`-openbsd/OpenBSD/Pledge.pm ./OpenBSD/
+cp -p /usr/libdata/perl5/`arch -s`-openbsd/auto/OpenBSD/Pledge/Pledge.so
./auto/OpenBSD/Pledge/
# You also need to enable slowcgi(8):
Re: firefox does not see printer
On Sep 26 20:05:06, dmitry.sen...@gmail.com wrote:
> Install gtk{2,3}-cups packages
I would like to stay with the base lpd/lpr,
which seems to work fine except in firefox ...
Jan
Re: firefox does not see printer
On Sep 26 10:11:59, j...@openbsd.org wrote: > On Thu, 26 Sep 2019 at 16:36:08 +0200, Jan Stary wrote: > > This is current/amd64 with firefox-68.0.2 > > > > Firefox does not offer any prtinters in the printing dialogue > > except (Print to file"). > > > > lpd/lpr itself works fine. This is my /etc/printcap: > > lp:lp=:rm=147.32.232.36:rp=lp:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs: > > Each of "date | lpr" and "lpr file.pdf" works. > > > > I removed the entire ~/.mozilla directory fo make sure > > it is not some of my firefox settings. > > > > Is this known? > > Is a fix known? > > Printing in Firefox is handled through Gtk 3. > > Gtk should present a "Print to LPR" option in that common print > dialog by way of > /usr/local/lib/gtk+3/3.0.0/printbackends/libprintbackend-lpr.so, I do have /usr/local/lib/gtk-3.0/3.0.0/printbackends/libprintbackend-lpr.so as provided by gtk+3-3.24.10 (was gtk-3.0 vs gtk+3.0 a typo?). > which is supposed to get loaded/registered dynamically according to > gtk_print_backends in ~/.config/gtk-3.0/settings.ini or the default > at build-time, which includes it according to x11/gtk+3: > > # configure will disable lpr in default gtk-print-backends if cups is > found > MAKE_FLAGS= GTK_PRINT_BACKENDS="file,lpr,cups,cloudprint" I didn't use that so far; now I have $ cat ~/.config/gtk-3.0/settings.ini gtk-print-backends="lpr" which is probably not the right syntax, as firefox/gtk says on startup (firefox:58612): Gtk-WARNING **: 17:21:25.416: Failed to parse /home/hans/.config/gtk-3.0/settings.ini: Key file does not start with a group > I'm taking a look into why that lpr backend doesn't load... Thank you Jan
Re: firefox does not see printer
Oh come on. When one thing doesn't work, the answer isn't
to tell someone to use something else. Your reply is irresponsible.
dmitry.sensei wrote:
> Install gtk{2,3}-cups packages
>
> чт, 26 сент. 2019 г., 19:37 Jan Stary :
>
> > This is current/amd64 with firefox-68.0.2
> >
> > Firefox does not offer any prtinters in the printing dialogue
> > except (Print to file").
> >
> > lpd/lpr itself works fine. This is my /etc/printcap:
> > lp:lp=:rm=147.32.232.36:
> > rp=lp:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs:
> > Each of "date | lpr" and "lpr file.pdf" works.
> >
> > I removed the entire ~/.mozilla directory fo make sure
> > it is not some of my firefox settings.
> >
> > Is this known?
> > Is a fix known?
> >
> > Jan
> >
> >
Re: firefox does not see printer
On Thu, 26 Sep 2019 at 16:36:08 +0200, Jan Stary wrote: > This is current/amd64 with firefox-68.0.2 > > Firefox does not offer any prtinters in the printing dialogue > except (Print to file"). > > lpd/lpr itself works fine. This is my /etc/printcap: > lp:lp=:rm=147.32.232.36:rp=lp:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs: > Each of "date | lpr" and "lpr file.pdf" works. > > I removed the entire ~/.mozilla directory fo make sure > it is not some of my firefox settings. > > Is this known? > Is a fix known? Printing in Firefox is handled through Gtk 3. Gtk should present a "Print to LPR" option in that common print dialog by way of /usr/local/lib/gtk+3/3.0.0/printbackends/libprintbackend-lpr.so, which is supposed to get loaded/registered dynamically according to gtk_print_backends in ~/.config/gtk-3.0/settings.ini or the default at build-time, which includes it according to x11/gtk+3: # configure will disable lpr in default gtk-print-backends if cups is found MAKE_FLAGS= GTK_PRINT_BACKENDS="file,lpr,cups,cloudprint" I'm taking a look into why that lpr backend doesn't load...
Re: firefox does not see printer
Install gtk{2,3}-cups packages
чт, 26 сент. 2019 г., 19:37 Jan Stary :
> This is current/amd64 with firefox-68.0.2
>
> Firefox does not offer any prtinters in the printing dialogue
> except (Print to file").
>
> lpd/lpr itself works fine. This is my /etc/printcap:
> lp:lp=:rm=147.32.232.36:
> rp=lp:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs:
> Each of "date | lpr" and "lpr file.pdf" works.
>
> I removed the entire ~/.mozilla directory fo make sure
> it is not some of my firefox settings.
>
> Is this known?
> Is a fix known?
>
> Jan
>
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/09/26 08:55:22 Modified files: cad/xschem : Makefile distinfo cad/xschem/pkg : PLIST Log message: update to xschem 2.9.2, from maintainer Hannu Vuolasaho
Re: Update: cad/xschem to 2.9.2
Ping Has anyone looked at this? Best regards, Hannu Vuolasaho ke 18. syysk. 2019 klo 23.51 Hannu Vuolasaho (vuokkose...@gmail.com) kirjoitti: > > Hello! > > Here is update for xschem 2.9.2 and fix wish setting line. > > All ather tcl files are purely procedure files. > > Best regards, > Hannu Vuolasaho
Re: firefox does not see printer
On Sep 26 16:36:08, h...@stare.cz wrote: > lpd/lpr itself works fine. This is my /etc/printcap: > lp:lp=:rm=147.32.232.36:rp=lp:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs: > Each of "date | lpr" and "lpr file.pdf" works. However, in /var/spool/output/lpd/, there is a nonempty "lock" file saying 41838 cfA005biblio.stare.cz and a nonempty "status" file saying sending to 147.32.232.36 long after the printing has finished (and long after tcpdump has stopped reporting any traffic with the printer). I see the same on my other machines with lpd running. Is that a bug in lpd? Is it be related to firefox not seeing the printer? Jan
firefox does not see printer
This is current/amd64 with firefox-68.0.2 Firefox does not offer any prtinters in the printing dialogue except (Print to file"). lpd/lpr itself works fine. This is my /etc/printcap: lp:lp=:rm=147.32.232.36:rp=lp:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs: Each of "date | lpr" and "lpr file.pdf" works. I removed the entire ~/.mozilla directory fo make sure it is not some of my firefox settings. Is this known? Is a fix known? Jan
Re: Update net/py-websocket-client to 0.56.0
On Fri, Sep 20, 2019 at 03:24:38PM +0200, clematis wrote:
> Here's an update for net/py-websocket-client from 0.37.0 to 0.56.0
> build and install OK on amd64
Minor changes compared to the initial submission.
- Changed PKGNAME = py-${DISTNAME} for consistency
- Add MAINTAINER
- Removed unnecessary MODPY_PI_DIR and RUN_DEPENDS
> In regards to tests:
> platform openbsd6 -- Python 3.7.4, pytest-4.4.0, py-1.8.0, pluggy-0.11.0
> 22 passed, 10 skipped, 20 warnings
> Deprecation warnings due to assertEquals (with an s at the end) being
> used. assertEqual has to be used now.
Same result. Also ran py2.7 tests, Ran 32 OK (Skipped 10).
> Looking at reverse-deps, I could build and install OK on amd64:
> net/py-socketio-client
> net/py-ripe.atlas.cousteau
> net/py-ripe.atlas.tools
> The ripe-atlas tools worked and ran OK.
OK.
New diff attached.
Comments? OK?
Thanks,
--
clematis (0x7e96fd2400fe7b59)
Index: Makefile
===
RCS file: /cvs/ports/net/py-websocket-client/Makefile,v
retrieving revision 1.8
diff -r1.8 Makefile
5c5
< MODPY_EGG_VERSION = 0.37.0
---
> MODPY_EGG_VERSION = 0.56.0
7,8c7
< PKGNAME = py-websocket-client-${MODPY_EGG_VERSION}
< REVISION =2
---
> PKGNAME = py-${DISTNAME}
12c11
< HOMEPAGE =https://github.com/liris/websocket-client
---
> HOMEPAGE =https://github.com/websocket-client/websocket-client
14c13,15
< # LGPLv2.1+
---
> MAINTAINER = Clem Atis
>
> # BSD 3-Clause
18d18
< MODPY_PI_DIR =w/websocket-client
24,25d23
<
< RUN_DEPENDS = devel/py-six${MODPY_FLAVOR}
Index: distinfo
===
RCS file: /cvs/ports/net/py-websocket-client/distinfo,v
retrieving revision 1.3
diff -r1.3 distinfo
1,2c1,2
< SHA256 (websocket_client-0.37.0.tar.gz) =
Z4skbYFrlAGK9Sl+cpFRYOL+sELgzeGpOX9QKsOlL0E=
< SIZE (websocket_client-0.37.0.tar.gz) = 194246
---
> SHA256 (websocket_client-0.56.0.tar.gz) =
> H9VSCHi2i4S1dIuzDlkrENCpFSnVOD909JZOcrKX/To=
> SIZE (websocket_client-0.56.0.tar.gz) = 36951
Index: pkg/PLIST
===
RCS file: /cvs/ports/net/py-websocket-client/pkg/PLIST,v
retrieving revision 1.2
diff -r1.2 PLIST
1c1
< @comment $OpenBSD: PLIST,v 1.2 2015/12/07 21:16:25 sthen Exp $
---
> @comment $OpenBSD: PLIST,v$
8a9
> lib/python${MODPY_VERSION}/site-packages/websocket/${MODPY_PYCACHE}_cookiejar.${MODPY_PYC_MAGIC_TAG}pyc
19a21
> lib/python${MODPY_VERSION}/site-packages/websocket/_cookiejar.py
29d30
< lib/python${MODPY_VERSION}/site-packages/websocket/cacert.pem
33a35
> lib/python${MODPY_VERSION}/site-packages/websocket/tests/${MODPY_PYCACHE}test_cookiejar.${MODPY_PYC_MAGIC_TAG}pyc
37a40
> lib/python${MODPY_VERSION}/site-packages/websocket/tests/test_cookiejar.py
Re: lang/go: make test vs PORTS_PRIVSEP=Yes
On Thu, Sep 26, 2019 at 11:09:16PM +1000, Joel Sing wrote:
> On 19-09-26 13:06:51, Stuart Henderson wrote:
> > On 2019/09/26 09:44, Theo Buehler wrote:
> > > I noticed two problems with go's 'make test' when PORTS_PRIVSEP=Yes:
> > > both having to do with _pbuild's home being /nonexistent:
> > >
> > > failed to initialize build cache at /nonexistent/.cache/go-build: mkdir
> > > /nonexistent: permission denied
> > >
> > > and
> > >
> > > --- FAIL: TestUserHomeDir (0.00s)
> > > os_test.go:2350: stat /nonexistent: no such file or directory
> > > FAIL
> > >
> > > both problems can be worked around by setting the GOCACHE and HOME
> > > environment variables to something different than /nonexistent.
> > >
> > > Since do-build alreday sets GOCACHE=${WRKDIST}/go-cache, it seems
> > > reasonable to do the same for do-test independently of PORTS_PRIVSEP.
> >
> > FWIW that one's OK with me.
> >
> > > I'm less sure about the proper solution for TestHomeDir and would like
> > > to have some advice on that. Setting HOME to ${WRKDIST} or a temporary
> > > directory works and is in line with the custom PATH, but seems very
> > > kludgy and might have undesirable side effects for other tests in the
> > > future. One could patch the TestHomeDir test to skip the Stat and IsDir
> > > part if the user is _pbuild. I'm not too worried about the TestHomeDir
> > > per se but rather the fact that its failure takes out a sizable number
> > > of later tests.
> >
> > Patching the TestHomeDir test might also have side effects in the future..
> > Setting PORTHOME=${WRKDIR} is fairly common in ports in general, so that
> > would probably be my first choice (I think it's better in WRKDIR rather
> > than WRKDIST).
>
> Agreed. It is going to be preferable to set HOME to a sensible
> location, rather than patch tests - ok jsing@.
Ok, thanks.
Setting PORTHOME=${WRKDIST} works directly. Using WRKDIR does work in
the sense that all tests pass, but it leads to an ugly complaint about
a missing GOPATH:
$ make test
===> Regression tests for go-1.13
missing $GOPATH
To avoid this complaint, I added GOPATH=WRKDIR to the environment. Also,
the reason why the poisoned PORTHOME didn't work is the custom do-test
target that bypasses the default test environment. After pulling in
ALL_TEST_ENV, one could now make use of the TEST_ENV mechanism, but I
don't want to interfere too much with jsing's choices.
Index: Makefile
===
RCS file: /var/cvs/ports/lang/go/Makefile,v
retrieving revision 1.71
diff -u -p -r1.71 Makefile
--- Makefile15 Sep 2019 02:00:34 - 1.71
+++ Makefile26 Sep 2019 14:10:47 -
@@ -34,6 +34,7 @@ SEPARATE_BUILD = simple
CONFIGURE_STYLE = None
SUBST_VARS = GOCFG
+PORTHOME = ${WRKDIR}
WRKDIST = ${WRKDIR}/go
WRKSRC = ${WRKDIST}/src
@@ -94,8 +95,11 @@ do-build:
do-test:
@cd ${WRKSRC} && \
ulimit -d $$(ulimit -H -d) -n 256 && \
+ ${SETENV} ${ALL_TEST_ENV} \
CC="${CC}" \
CXX="${CXX}" \
+ GOCACHE=${WRKDIST}/go-cache \
+ GOPATH=${WRKDIR} \
PATH=${WRKDIST}/bin:${PATH} \
/bin/ksh -c "exec 3>&-; exec 4>&-; ./run.bash"
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/09/26 07:54:54 Modified files: audio/audacity : Makefile distinfo audio/audacity/patches: patch-src_AudacityApp_cpp patch-src_AudioIO_cpp patch-src_MemoryX_h audio/audacity/pkg: PLIST Log message: update to audacity-2.3.2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/09/26 07:47:44 Modified files: lang/php/7.3 : Tag: OPENBSD_6_5 Makefile distinfo lang/php/7.3/patches: Tag: OPENBSD_6_5 patch-php_ini-production Log message: update -stable to php-7.3.10
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/09/26 07:46:19 Modified files: lang/php/7.3 : Makefile distinfo lang/php/7.3/patches: patch-php_ini-production Log message: update to php-7.3.10
[UPDATE] security/py-ropper
Hi,
this diff updates ropper to latest release.
Ok?
Cheers,
Remi.
Index: Makefile
===
RCS file: /cvs/ports/security/py-ropper/Makefile,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 Makefile
--- Makefile 12 Jul 2019 20:49:35 - 1.5
+++ Makefile 26 Sep 2019 05:50:55 -
@@ -2,10 +2,9 @@
COMMENT = rop gadget finder and binary information tool
-MODPY_EGG_VERSION = 1.11.10
+MODPY_EGG_VERSION = 1.12.5
DISTNAME = ropper-${MODPY_EGG_VERSION}
PKGNAME = py-${DISTNAME}
-REVISION = 1
CATEGORIES = security
Index: distinfo
===
RCS file: /cvs/ports/security/py-ropper/distinfo,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 distinfo
--- distinfo 2 Jan 2019 06:33:17 - 1.2
+++ distinfo 26 Sep 2019 05:50:55 -
@@ -1,2 +1,2 @@
-SHA256 (ropper-1.11.10.tar.gz) = uNFDnYpu97k3GEcrAojuiKWVNyMEZ3LwNf6YmxweXW4=
-SIZE (ropper-1.11.10.tar.gz) = 65765
+SHA256 (ropper-1.12.5.tar.gz) = DevhcizzVtgjyravsr632K1sZEFHl4wf9UpbNEicdBg=
+SIZE (ropper-1.12.5.tar.gz) = 68836
Index: patches/patch-ropper_console_py
===
RCS file: patches/patch-ropper_console_py
diff -N patches/patch-ropper_console_py
--- patches/patch-ropper_console_py 31 Mar 2019 04:39:11 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,16 +0,0 @@
-$OpenBSD: patch-ropper_console_py,v 1.1 2019/03/31 04:39:11 jasper Exp $
-
-UnboundLocalError: local variable 'f' referenced before assignment
-
-Index: ropper/console.py
ropper/console.py.orig
-+++ ropper/console.py
-@@ -254,7 +254,7 @@ class Console(cmd.Cmd):
- elif format == 'S':
- f = 'string'
- else:
--raise RopperError('wrong format: %s' % f)
-+raise RopperError('wrong format: %s' % format)
-
- self.__cprinter.println(self.__rs.asm(code, arch, f))
-
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/09/26 07:23:37 Modified files: net/kea: Makefile distinfo net/kea/patches: patch-src_bin_keactrl_keactrl_conf_in net/kea/pkg: PLIST Added files: net/kea/patches: patch-src_bin_keactrl_kea-ctrl-agent_conf_pre patch-src_bin_keactrl_kea-dhcp-ddns_conf_pre patch-src_bin_keactrl_kea-dhcp4_conf_pre patch-src_bin_keactrl_kea-dhcp6_conf_pre patch-src_bin_keactrl_kea-netconf_conf_pre patch-src_bin_keactrl_keactrl_in Removed files: net/kea/patches: patch-src_bin_keactrl_kea-ca_conf_pre patch-src_bin_keactrl_kea_conf_pre patch-src_lib_asiolink_io_service_h patch-src_lib_asiolink_tcp_acceptor_h patch-src_lib_asiolink_tcp_socket_h patch-src_lib_asiolink_udp_socket_h patch-src_lib_asiolink_unix_domain_socket_cc patch-src_lib_util_watch_socket_cc Log message: update to kea-1.6.0 no response to a call for testing on ports@; i intend to remove this port if nobody steps up to maintain or at least test diffs when sent out. (1.7.0 is out now as well).
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/09/26 07:18:29 Modified files: mail/pear-Mail-Mime: Makefile distinfo mail/pear-Mail-Mime/pkg: PLIST Log message: update to pear-Mail-Mime-1.10.3
Re: lang/go: make test vs PORTS_PRIVSEP=Yes
On 19-09-26 13:06:51, Stuart Henderson wrote:
> On 2019/09/26 09:44, Theo Buehler wrote:
> > I noticed two problems with go's 'make test' when PORTS_PRIVSEP=Yes:
> > both having to do with _pbuild's home being /nonexistent:
> >
> > failed to initialize build cache at /nonexistent/.cache/go-build: mkdir
> > /nonexistent: permission denied
> >
> > and
> >
> > --- FAIL: TestUserHomeDir (0.00s)
> > os_test.go:2350: stat /nonexistent: no such file or directory
> > FAIL
> >
> > both problems can be worked around by setting the GOCACHE and HOME
> > environment variables to something different than /nonexistent.
> >
> > Since do-build alreday sets GOCACHE=${WRKDIST}/go-cache, it seems
> > reasonable to do the same for do-test independently of PORTS_PRIVSEP.
>
> FWIW that one's OK with me.
>
> > I'm less sure about the proper solution for TestHomeDir and would like
> > to have some advice on that. Setting HOME to ${WRKDIST} or a temporary
> > directory works and is in line with the custom PATH, but seems very
> > kludgy and might have undesirable side effects for other tests in the
> > future. One could patch the TestHomeDir test to skip the Stat and IsDir
> > part if the user is _pbuild. I'm not too worried about the TestHomeDir
> > per se but rather the fact that its failure takes out a sizable number
> > of later tests.
>
> Patching the TestHomeDir test might also have side effects in the future..
> Setting PORTHOME=${WRKDIR} is fairly common in ports in general, so that
> would probably be my first choice (I think it's better in WRKDIR rather
> than WRKDIST).
Agreed. It is going to be preferable to set HOME to a sensible
location, rather than patch tests - ok jsing@.
> > Index: Makefile
> > ===
> > RCS file: /var/cvs/ports/lang/go/Makefile,v
> > retrieving revision 1.71
> > diff -u -p -r1.71 Makefile
> > --- Makefile15 Sep 2019 02:00:34 - 1.71
> > +++ Makefile26 Sep 2019 07:15:03 -
> > @@ -96,6 +96,7 @@ do-test:
> > ulimit -d $$(ulimit -H -d) -n 256 && \
> > CC="${CC}" \
> > CXX="${CXX}" \
> > + GOCACHE=${WRKDIST}/go-cache \
> > PATH=${WRKDIST}/bin:${PATH} \
> > /bin/ksh -c "exec 3>&-; exec 4>&-; ./run.bash"
> >
> >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2019/09/26 07:00:21 Modified files: devel/spidermonkey60: Makefile Added files: devel/spidermonkey60/patches: patch-js_src_jit_ProcessExecutableMemory_cpp Log message: Allow mmap(2) to select a suitable random address by providing NULL as the hint address. Fixes x11/gnome/gjs build on aarch64 at least. okay jasper@ jcs@
Re: Retire python2
On 2019/09/26 08:12, Daniel Dickman wrote:
> (Moved from: “Adding binary renaming facility to python.port.mk”)
>
> > On Sep 25, 2019, at 5:47 AM, Stuart Henderson wrote:
> >
> > imo, if there's a good reason to keep the py2 version (used by something
> > else in the ports tree, or possibly if it includes a useful compiled
> > iextension) then split the port.
> >
> > but if the py2 version isn't really useful and is holding back an update,
> > drop the py2 version.
>
> I’m wondering how you’re thinking about this. Something like the below?
>
> Change:
>
> FLAVORS = python3
> FLAVOR ?=
>
> To:
>
> FLAVORS = python3
> FLAVOR = python3
>
> (Note, I purposely remove the ? above to avoid ability to override FLAVOR.)
>
> I think this approach would minimize changes in reverse dependencies that
> depend on a FLAVOR.
For the sake of consistency I was mostly thinking of following the
current py3-only ports and use MODPY_VERSION=${MODPY_DEFAULT_VERSION_3}
without a flavour, it's not too much work to find and update reverse
dep's.
> An alternative approach would be to drop the FLAVORS completely and make what
> used to be the python3 flavor the new package. But I think that approach
> might be a bit more complicated because of the reverse dependencies.
>
> Is there an easier migration path?
>
My favourite fix would be to get rid of the unflavoured versions and
have FLAVOR=python27 (and change FLAVOR=python3 to FLAVOR=python37 to
allow us to have multiple 3.x versions ..)
This is a fair chunk of work to put in place (a hackathon project,
perhaps), and then we would need to use a different mechanism
for "de-conflicting" installed scripts*, but it would make it easier
to get new major python versions tested before switching the bulk of
the ports tree across, or to cope if we have something important
that is hard to update to work with a newer python version.
Perhaps some might consider this overengineering though :)
* maybe by installing all scripts with a suffix "foo-37", and then a
symlink "foo -> foo-37" only in the "main" version...
Retire python2
(Moved from: “Adding binary renaming facility to python.port.mk”) > On Sep 25, 2019, at 5:47 AM, Stuart Henderson wrote: > > imo, if there's a good reason to keep the py2 version (used by something > else in the ports tree, or possibly if it includes a useful compiled > iextension) then split the port. > > but if the py2 version isn't really useful and is holding back an update, > drop the py2 version. I’m wondering how you’re thinking about this. Something like the below? Change: FLAVORS = python3 FLAVOR ?= To: FLAVORS = python3 FLAVOR = python3 (Note, I purposely remove the ? above to avoid ability to override FLAVOR.) I think this approach would minimize changes in reverse dependencies that depend on a FLAVOR. An alternative approach would be to drop the FLAVORS completely and make what used to be the python3 flavor the new package. But I think that approach might be a bit more complicated because of the reverse dependencies. Is there an easier migration path?
Re: TEST_POD [was Re: [Update] net/p5-Net-BGP : Update to 0.17]
On 2019/09/18 13:24, Gleydson Soares wrote: > > > > On 18 Sep 2019, at 12:26, Stuart Henderson wrote: > > > >> On 2019/09/18 05:48, Gleydson Soares wrote: > >> > >> > On 18 Sep 2019, at 04:40, Stuart Henderson wrote: > > On 2019/09/18 02:15, wen heping wrote: > Hi, ports@: > > Here is a patch for net/p5-Net-BGP: > i) Update to 0.17 > ii) Add TEST_POD=yes > >>> > >>> I've been wondering for a while... what's the point in using TEST_POD > >>> in ports? Isn't that more of an "author test" kind of thing? > >>> > >> > >> Some p5- ports fails on regress since it depends on p5- pod packages you > >> mean disabling pod tests? > > > > I mean, what's the point in enabling POD tests for things that don't > > normally do them? > > > > sure, adding no-op dependencies is wrong... > It's not usually a no-op dependency, rather it enables tests that seem to me to only be of real interest to the author..
Re: lang/go: make test vs PORTS_PRIVSEP=Yes
On 2019/09/26 09:44, Theo Buehler wrote:
> I noticed two problems with go's 'make test' when PORTS_PRIVSEP=Yes:
> both having to do with _pbuild's home being /nonexistent:
>
> failed to initialize build cache at /nonexistent/.cache/go-build: mkdir
> /nonexistent: permission denied
>
> and
>
> --- FAIL: TestUserHomeDir (0.00s)
> os_test.go:2350: stat /nonexistent: no such file or directory
> FAIL
>
> both problems can be worked around by setting the GOCACHE and HOME
> environment variables to something different than /nonexistent.
>
> Since do-build alreday sets GOCACHE=${WRKDIST}/go-cache, it seems
> reasonable to do the same for do-test independently of PORTS_PRIVSEP.
FWIW that one's OK with me.
> I'm less sure about the proper solution for TestHomeDir and would like
> to have some advice on that. Setting HOME to ${WRKDIST} or a temporary
> directory works and is in line with the custom PATH, but seems very
> kludgy and might have undesirable side effects for other tests in the
> future. One could patch the TestHomeDir test to skip the Stat and IsDir
> part if the user is _pbuild. I'm not too worried about the TestHomeDir
> per se but rather the fact that its failure takes out a sizable number
> of later tests.
Patching the TestHomeDir test might also have side effects in the future..
Setting PORTHOME=${WRKDIR} is fairly common in ports in general, so that
would probably be my first choice (I think it's better in WRKDIR rather
than WRKDIST).
> Index: Makefile
> ===
> RCS file: /var/cvs/ports/lang/go/Makefile,v
> retrieving revision 1.71
> diff -u -p -r1.71 Makefile
> --- Makefile 15 Sep 2019 02:00:34 - 1.71
> +++ Makefile 26 Sep 2019 07:15:03 -
> @@ -96,6 +96,7 @@ do-test:
> ulimit -d $$(ulimit -H -d) -n 256 && \
> CC="${CC}" \
> CXX="${CXX}" \
> + GOCACHE=${WRKDIST}/go-cache \
> PATH=${WRKDIST}/bin:${PATH} \
> /bin/ksh -c "exec 3>&-; exec 4>&-; ./run.bash"
>
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org 2019/09/26 05:59:20
Modified files:
www/chromium : Makefile
www/chromium/pkg: PLIST-electron
Log message:
add .zip to the ELECTRON_ARCH string which is only used to substitute in
PLISTs (electron/releases/electron-v6.0.3-openbsd-${ELECTRON_ARCH} etc),
this will prevent share/icons/hicolor/64x64 from being accidentally written
as share/icons/hicolor/64${ELECTRON_ARCH}. looks ok to robert@
[Update] devel/p5-System-Command : Update to 1.119
Hi, ports@:
Here is a patch for devel/p5-System-Command:
i) Update to 1.119
ii) Add AUTHOR_TESTING=yes to MKAE_ENV, then it could
run pod tests.
iii) Remove CONFIGURE_STYLE = modbuild
It build well and passed all tests on amd64-head system. It
was required by update of devel/p5-Git-Repository.
One port depends on it :p5-Git-Repository.
Comments? OK?
wen
Index: Makefile
===
RCS file: /cvs/ports/devel/p5-System-Command/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- Makefile12 Jul 2019 20:45:07 - 1.6
+++ Makefile26 Sep 2019 11:46:31 -
@@ -4,17 +4,13 @@ COMMENT = object for running system com
MODULES = cpan
PKG_ARCH = *
-DISTNAME = System-Command-1.07
+DISTNAME = System-Command-1.119
CATEGORIES = devel
-REVISION = 0
-
# perl
PERMIT_PACKAGE = Yes
-CONFIGURE_STYLE = modbuild
-
-MAKE_ENV +=TEST_POD=yes
+MAKE_ENV +=TEST_POD=yes AUTHOR_TESTING=yes
TEST_DEPENDS = devel/p5-Test-Output
Index: distinfo
===
RCS file: /cvs/ports/devel/p5-System-Command/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo1 May 2014 06:59:28 - 1.3
+++ distinfo26 Sep 2019 11:46:31 -
@@ -1,2 +1,2 @@
-SHA256 (System-Command-1.07.tar.gz) =
hDKsJCHQMOeU5c0IE3V54/VQ0sQw2Clu7s1v0E6uxWA=
-SIZE (System-Command-1.07.tar.gz) = 13261
+SHA256 (System-Command-1.119.tar.gz) =
yMn7HlJ8UkY8qxR2UA7+pwOWoLYr6mJdLW+uqZTcRuc=
+SIZE (System-Command-1.119.tar.gz) = 30479
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/p5-System-Command/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- pkg/PLIST 20 Jul 2011 18:04:48 - 1.1.1.1
+++ pkg/PLIST 26 Sep 2019 11:46:31 -
@@ -1,4 +1,7 @@
@comment $OpenBSD: PLIST,v 1.1.1.1 2011/07/20 18:04:48 jasper Exp $
${P5SITE}/System/
+${P5SITE}/System/Command/
${P5SITE}/System/Command.pm
+${P5SITE}/System/Command/Reaper.pm
@man man/man3p/System::Command.3p
+@man man/man3p/System::Command::Reaper.3p
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: chr...@cvs.openbsd.org 2019/09/26 05:04:50 Added files: lang/ocaml-camlp4/patches: patch-configure Log message: Add patch that was missing in the OCaml 4.09.0 update
Re: rspamd with opensmtpd-filter-rspamd, missing X-Spam-Symbols
Hi,
September 22, 2019 6:23 PM, "Florian Obser" wrote:
> I recently moved from
>
> action "mda_with_aliases" mda \
> "/usr/local/bin/rspamc --mime --exec '/usr/local/libexec/dovecot/dovecot-lda
> -f %{sender} -d
> %{dest:strip} -a %{dest}'" \
> alias user vmail
>
> to
>
> filter rspamd proc-exec "filter-rspamd"
>
> and
>
> action "mda_with_aliases" mda \
> "/usr/local/libexec/dovecot/dovecot-lda -f '%{sender}' -d '%{dest:strip}' -a
> '%{dest}'" \
> alias user vmail
>
> I used to get a bunch of X-Spam-* header lines telling me why a mail got
> classified as spam / ham,
> e.g.:
>
> [...]
>
> The documentation has this to say:
>
> "The milter headers module (formerly known as rmilter headers) has
> been added in Rspamd 1.5 to provide a relatively simple way to
> configure adding/removing of headers via Rmilter
> (the alternative being to use the API)."
> ^^^ ^^^
>
> So maybe opensmtpd-filter-rspamd using the API and I have to push a
> different button?
>
> Any insight would be appreciated.
> Thanks,
> Florian
>
No different button to push, the X-Spam-Symbols will be added but I need to
figure out
where to get them.
The `rspamc` utility added them itself but my `filter-rspamd` need to figure
out where
they are so it can actually create the header.
I'll sort that out soon
Re: net/ntp: normalize adjustment before calling adjtime(2)
I disagreed early on in the discussion but I've come around,
and believe this system call can require normalized tv's.
Scott Cheloha wrote:
> Hey,
>
> detha wrote on tech@ recently about how adjtime(2) now sets EINVAL
> if delta->tv_nsec < 0, which breaks xntpd's clock retardation.
>
> Given the rarity of this syscall I'd rather patch the software than
> restore the 4.4BSD behavior. I skimmed codesearch.debian.net and
> outside of noise from language bindings, noise from test suites, and
> noise from compilers, I found very little code using the call. NTP
> and its various forks/rewrites, ptpd, systemd... that's about it. How
> many callers are there in OpenBSD ports?
>
> The attached patch should fix ntpd's problem. I have only compiled
> it. Unsure if this is the right way to submit this. I fetched,
> extracted, and built, then I made my edit and did update-patches and
> this file was the result. So I think I'm close. At least, if you
> put this patch into ports/net/ntp/patches/patch-libntp_systime_c
> I think you'll be good to go.
>
> detha: could you check if this fixes the problem?
>
> Index: libntp/systime.c
> --- libntp/systime.c.orig
> +++ libntp/systime.c
> @@ -344,6 +344,10 @@ adj_systime(
> if (isneg) {
> adjtv.tv_sec = -adjtv.tv_sec;
> adjtv.tv_usec = -adjtv.tv_usec;
> + if (adjtv.tv_usec < 0) {
> + adjtv.tv_sec -= 1;
> + adjtv.tv_usec += 100;
> + }
> sys_residual = -sys_residual;
> }
> if (adjtv.tv_sec != 0 || adjtv.tv_usec != 0) {
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: c...@cvs.openbsd.org2019/09/26 04:36:53 Modified files: x11/waimea : Makefile Added files: x11/waimea/patches: patch-src_Resources_cc patch-src_Resources_hh patch-src_Window_cc Log message: waimea: unbreak with ports-gcc by fixing a namespace clash. Also move HOMEPAGE to https and refresh WANTLIB. Tested on sparc64 by kmos@ and macppc by me. OK kmos@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/09/26 04:22:41 Modified files: productivity/gnucash: Makefile Log message: set -DGNC_SHELL=/bin/sh instead of forcing a BDEP on bash, now that I've been able to do a successful build with it
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2019/09/26 04:17:10 Modified files: www/puppetboard: Makefile distinfo Log message: update 1.0.0 -> 1.1.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2019/09/26 04:15:56 Modified files: databases/py-puppetdb: Makefile distinfo databases/py-puppetdb/pkg: PLIST Log message: Update 1.0.0 -> 1.2.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/09/26 03:54:11 Modified files: security/pecl-mcrypt: Makefile distinfo Log message: update to pecl-mcrypt-1.0.3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: chr...@cvs.openbsd.org 2019/09/26 03:46:11 Modified files: devel/cil : Makefile devel/coccinelle: Makefile devel/dune : Makefile devel/frama-c : Makefile devel/ocaml-biniou: Makefile devel/ocaml-cppo: Makefile devel/ocaml-easy-format: Makefile devel/ocaml-graph: Makefile devel/ocaml-menhir: Makefile devel/ocaml-ocamlbuild: Makefile devel/ocaml-parmap: Makefile devel/ocaml-pcre: Makefile devel/ocaml-yojson: Makefile graphics/ocaml-cairo: Makefile graphics/pdfsandwich: Makefile lang/ocaml-camlp5: Makefile math/ocaml-num : Makefile math/ocaml-zarith: Makefile net/mldonkey : Makefile net/unison/2.4x: Makefile net/unison/2.5x: Makefile textproc/hevea : Makefile x11/kde-applications/kalzium: Makefile x11/lablgtk2 : Makefile x11/lablgtk3 : Makefile graphics : Makefile lang/ocaml-camlp4: Makefile sysutils/findlib: Makefile sysutils/findlib/pkg: PLIST lang/ocaml : Makefile distinfo lang/ocaml/patches: patch-configure_ac Added files: lang/ocaml/pkg : DESCR PFRAG.dynlink-native PFRAG.native PLIST Removed files: lang/ocaml/pkg : DESCR-graphics DESCR-main PFRAG.dynlink-native-graphics PFRAG.dynlink-native-main PFRAG.native-graphics PFRAG.native-main PLIST-graphics PLIST-main Log message: Update OCaml to 4.09 reviewed ports wise and help with @pkgpath, ok by sthen@ reviewed and help with bytecode-only plists, minor nits and ok by jca@ tested on sparc 64 by @jca tested on aarch64 by Kurt Miller tested on amd64 by me Thanks for reviews and testing!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: chr...@cvs.openbsd.org 2019/09/26 03:33:14 Log message: Import graphics/ocaml-graphics This was formally shipped with the OCaml compiler distribution, but is now a seperate project. ok jca@, krw@, sthen@ Status: Vendor Tag: chrisz Release Tags: chrisz_20190926 N ports/graphics/ocaml-graphics/Makefile N ports/graphics/ocaml-graphics/distinfo N ports/graphics/ocaml-graphics/pkg/DESCR N ports/graphics/ocaml-graphics/pkg/PLIST N ports/graphics/ocaml-graphics/pkg/PFRAG.native N ports/graphics/ocaml-graphics/patches/patch-src_unix_open_c No conflicts created by this import
lang/go: make test vs PORTS_PRIVSEP=Yes
I noticed two problems with go's 'make test' when PORTS_PRIVSEP=Yes:
both having to do with _pbuild's home being /nonexistent:
failed to initialize build cache at /nonexistent/.cache/go-build: mkdir
/nonexistent: permission denied
and
--- FAIL: TestUserHomeDir (0.00s)
os_test.go:2350: stat /nonexistent: no such file or directory
FAIL
both problems can be worked around by setting the GOCACHE and HOME
environment variables to something different than /nonexistent.
Since do-build alreday sets GOCACHE=${WRKDIST}/go-cache, it seems
reasonable to do the same for do-test independently of PORTS_PRIVSEP.
I'm less sure about the proper solution for TestHomeDir and would like
to have some advice on that. Setting HOME to ${WRKDIST} or a temporary
directory works and is in line with the custom PATH, but seems very
kludgy and might have undesirable side effects for other tests in the
future. One could patch the TestHomeDir test to skip the Stat and IsDir
part if the user is _pbuild. I'm not too worried about the TestHomeDir
per se but rather the fact that its failure takes out a sizable number
of later tests.
Index: Makefile
===
RCS file: /var/cvs/ports/lang/go/Makefile,v
retrieving revision 1.71
diff -u -p -r1.71 Makefile
--- Makefile15 Sep 2019 02:00:34 - 1.71
+++ Makefile26 Sep 2019 07:15:03 -
@@ -96,6 +96,7 @@ do-test:
ulimit -d $$(ulimit -H -d) -n 256 && \
CC="${CC}" \
CXX="${CXX}" \
+ GOCACHE=${WRKDIST}/go-cache \
PATH=${WRKDIST}/bin:${PATH} \
/bin/ksh -c "exec 3>&-; exec 4>&-; ./run.bash"
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2019/09/26 00:46:39 Modified files: security/hcxtools: Makefile distinfo Log message: Update 5.1.6 -> 5.2.2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2019/09/26 00:41:33 Modified files: archivers/ruby-minitar: Makefile distinfo Log message: Update 0.8 -> 0.9
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2019/09/26 00:37:40 Modified files: security/wpscan: Makefile distinfo security/wpscan/pkg: PLIST Log message: Update 3.6.3 -> 3.7.1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2019/09/26 00:36:48 Modified files: security/ruby-cms_scanner: Makefile distinfo Log message: Update 0.5.7 -> 0.6.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2019/09/26 00:35:09 Modified files: textproc/ruby-nokogiri: Makefile distinfo textproc/ruby-nokogiri/pkg: PLIST Log message: Update 1.10.1 -> 1.10.4 update required for an update of cms_scanner OK jeremy@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2019/09/26 00:34:02 Modified files: net/ruby-public_suffix: Makefile distinfo net/ruby-public_suffix/pkg: PLIST Log message: Update 3.1.0 -> 4.0.1 now possible with updated addressable
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2019/09/26 00:32:37 Modified files: www/ruby-addressable: Makefile distinfo Log message: Update 2.6.0 -> 2.7.0 now that opt_parse_validator is updated, and relaxed dependencies to addressable OK jeremy@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2019/09/26 00:30:51 Modified files: devel/ruby-opt_parse_validator: Makefile distinfo Log message: Update 1.7.4 -> 1.8.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2019/09/26 00:29:20 Modified files: devel/ruby-activesupport: Makefile distinfo devel/ruby-activesupport/pkg: PLIST Log message: Update 5.2.3 -> 6.0.0 now that new dependency zeitwerk is in
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2019/09/26 00:26:55 Modified files: devel : Makefile Log message: hook up ruby-zeitwerk
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2019/09/26 00:25:46 Log message: import ruby Zeitwerk Zeitwerk implements constant autoloading with Ruby semantics. Each gem and application may have their own independent autoloader, with its own configuration, inflector, and logger. Supports autoloading, preloading, reloading, and eager loading. a new dependency needed to update activesupport. OK jeremy@ Status: Vendor Tag: sebastia Release Tags: sebastia_20190926 N ports/devel/ruby-zeitwerk/Makefile N ports/devel/ruby-zeitwerk/distinfo N ports/devel/ruby-zeitwerk/pkg/DESCR N ports/devel/ruby-zeitwerk/pkg/PLIST No conflicts created by this import
