CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bent...@cvs.openbsd.org 2019/12/12 23:50:55 Modified files: misc/gramps: Makefile distinfo misc/gramps/pkg: PLIST Log message: Update to gramps-5.1.1.
Re: CVS: cvs.openbsd.org: ports
On 12/12, Jasper Lievisse Adriaanse wrote:
> CVSROOT: /cvs
> Module name: ports
> Changes by: jas...@cvs.openbsd.org 2019/12/12 09:21:23
>
> Modified files:
> devel/py-dateutil: Makefile distinfo
> devel/py-dateutil/patches: patch-dateutil_test_test_parser_py
>
> Log message:
> update to py-dateutil-2.8.1
>
This breaks net/py-botocore, check py-dateutil version requirement hardcoded in
${MODPY_SITEPKG}/botocore-1.13.34-py3.7.egg-info/requires.txt:
python-dateutil<2.8.1,>=2.1
For more info on botocore, see here:
https://github.com/boto/botocore/issues/1872
https://github.com/boto/botocore/commit/e87e7a745fd972815b235a9ee685232745aa94f9#diff-380c6a8ebbbce17d55d50ef17d3cf906
--
With best regards,
Pavel Korovin
回复: 回复: 回复: [NEW] devel/py-asgiref
ping ... 发件人: owner-po...@openbsd.org 代表 wen heping 发送时间: 2019年12月6日 9:39 收件人: Kurt Mosiejczuk 抄送: ports@openbsd.org 主题: 回复: 回复: [NEW] devel/py-asgiref Hi, Here is the revised patch: i) Update to 3.2.3 ii) Enable the test since upstream include test program now. Django-3.0 released and it require asgiref. Comments? OK? wen 发件人: owner-po...@openbsd.org 代表 wen heping 发送时间: 2019年9月15日 10:12 收件人: Kurt Mosiejczuk 抄送: ports@openbsd.org 主题: 回复: [NEW] devel/py-asgiref 发件人: Kurt Mosiejczuk 发送时间: 2019年9月15日 9:49 收件人: wen heping 抄送: ports@openbsd.org 主题: Re: [NEW] devel/py-asgiref On Sat, Sep 14, 2019 at 07:22:37AM +, wen heping wrote: > Hi, ports@: > Here is a patch to create devel/py-asgiref, which is required by > the future update of www/py-django/stable. > I defined NO_TEST=yes because the test required some module > that had not been imported OpenBSD ports. >It build well and run well on amd64-head system. > Comments? OK? > wen It shouldn't go in devel. www should be its primary category. devel can be a secondary category. OMG. I imported it into FreeBSD www directory why I put it into devel dir here Don't set NO_TEST, it's unnecesary. Tests aren't bundled right now anyway. I've put in a pull request to include them in the PyPI tarball (https://github.com/django/asgiref/pull/126) The HOMEPAGE should be https. I improved the comment to more accurately reflect what the port is. I also added more information to DESCR. I added MODPY_PYTEST since that is what will be used for the next version when the tests are bundled. The tests *do* run if you pull them in manually. It just skips most of them since we don't yet have py-test-asyncio. I shall submit the py-test-asyncio port later. wen New tarball attached. --Kurt
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: abie...@cvs.openbsd.org 2019/12/12 19:44:10 Modified files: sysutils/facette: Makefile distinfo sysutils/facette/patches: patch-Makefile patch-docs_examples_facette_yaml sysutils/facette/pkg: PLIST Added files: sysutils/facette/patches: patch-web_asset_builtin_go Log message: Update facette to 0.5.1. This fixes the build with the latest node. OK landry@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/12/12 15:30:14 Modified files: net/libunbound : distinfo Log message: oops, was testing something and forgot to remove associated distinfo entries
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/12/12 15:29:35 Modified files: net/libunbound : Makefile distinfo net/libunbound/pkg: PLIST Log message: update to libunbound-1.9.6
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/12/12 14:36:18 Modified files: databases/freetds: Makefile distinfo Log message: update to freetds-1.1.24
Re: Fixing guile2 on powerpc
Hi,
On Wed, 11 Dec 2019 20:50:00 -0500
George Koehler wrote:
> I believe that the files in WRKSRC/prebuilt/32-bit-big-endian are
> broken: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26854
>
> The diff below adds a post-extract target that moves away the prebuilt
> files, so the build ignores them. This fixes the build for me, but
> the build is slow, takes about 24 hours on my G4 at 666 MHz.
>
> On Sun, 8 Dec 2019 13:42:38 -0500
> George Koehler wrote:
>
> > ... Some code
> > might put bad pointers in program objects. I modified guile to
> > look for such code. I added a global "scm_t_uint32 aaa;" and added
> > some checks like "aaa = *pointer". One such check crashed at
> > vm-engine.c:1654 "make-closure":
> >
> > UNPACK_24 (op, dst);
> > offset = ip[1];
> > UNPACK_24 (ip[2], nfree);
> >
> > // FIXME: Assert range of nfree?
> > SYNC_IP ();
> > closure = scm_inline_words (thread, scm_tc7_program | (nfree
> > << 16), nfree + 2);
> > aaa = *(ip + offset);
> > SCM_SET_CELL_WORD_1 (closure, ip + offset);
> > // FIXME: Elide these initializations?
> > for (n = 0; n < nfree; n++)
> > SCM_PROGRAM_FREE_VARIABLE_SET (closure, n, SCM_BOOL_F);
> > SP_SET (dst, closure);
> > NEXT (3);
> >
> > (gdb) print ip
> > $12 = (scm_t_uint32 *) 0xcf1ea3b8
> > (gdb) print offset
> > $13 = -1005191168
> > (gdb) print *(ip + offset)
> > Cannot access memory at address 0xdf76a3b8
> > (gdb) print ip[1]
> > Cannot access memory at address 0xcf1ea3bc
> >
> > I can't read ip[1] in the core dump, but the program did read ip[1]
> > in "offset = ip[1];" before the crash. The call to
> > scm_inline_words(), to allocate the scm_tc7_program object, seems
> > to have also freed the memory where ip points. This might be a
> > problem with the garbage collector.
>
> The failure to read ip[1] was a red herring. Before the crash, `ip`
> pointed to an mmap(2) file. In ktrace(1), the file was somewhere
> under prebuilt/32-bit-big-endian. This mapping disappeared in the
> core dump, so GDB can't access it.
>
> `offset` -1005191168 is 0xc416. This looks like the wrong byte
> order. The correct value might be 0x16c4 = 5828. This would make
> more sense, if ip + offset should be inside the file!
>
> modules/system/vm/assembler.scm can byte-swap values when it emits
> bytecode for a different-endian machine. If a little-endian machine
> wrote the prebuilt/32-bit-big-endian files, and assembler.scm forgot
> to swap `offset`, then it would cause this bug.
>
> powerpc might be the only 32-bit-big-endian arch where OpenBSD builds
> packages. mips64 and sparc64 might be 64-bit-big-endian (but there is
> no prebuilt/64-bit-big-endian, so those arches would bootstrap without
> prebuilt files), and the other arches might be *-little-endian.
>
> With no prebuilt files, the build ran some slow "bootstrap" commands
> on my 666 MHz cpu. (The MPC7447A in my PowerBook G4 can run at 1333
> MHz using apmd(8) and apm -A, but I left it at 666 MHz.) The first
> bootstrap command took more than 100 minutes. The second command took
> just over 4 hours. The next commands continued overnight, and the
> whole build might have taken almost 24 hours. The build passes most
> tests:
>
> SKIP: test-pthread-create-secondary
> FAIL: test-stack-overflow
> FAIL: test-out-of-memory
> ==
> 2 of 38 tests failed
> (1 test was not run)
>
> Here's the diff. I didn't set REVISION because powerpc had no
> package, and I guess that other arches would ignore
> prebuilt/32-bit-big-endian.
> --George
It builds and works fine here, it's sure slow to build, i hope upstream
will provide a working bootstrap. I think we should keep `mv' as it
makes the situation clear.
Thanks a lot :)
OK cwen@
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/guile2/Makefile,v
> retrieving revision 1.23
> diff -u -p -r1.23 Makefile
> --- Makefile 16 Jul 2019 21:29:41 - 1.23
> +++ Makefile 12 Dec 2019 01:02:07 -
> @@ -3,8 +3,6 @@
> # When updating, check that x11/gnome/aisleriot MODGNOME_CPPFLAGS
> # references the proper guile2 includes directory
>
> -BROKEN-powerpc= Segmentation fault (core dumped)
> -
> COMMENT= GNU's Ubiquitous Intelligent Language for
> Extension
> # '
>
> @@ -51,6 +49,10 @@ CONFIGURE_ARGS=--program-suffix=$
> {V}
> # Needed because otherwise regress tests won't build:
> # warning: format '%ji' expects type 'intmax_t', but argument 4 has
> # type 'scm_t_intmax'
> CONFIGURE_ARGS +=--disable-error-on-warning
> +
> +# powerpc: Prevent "Segmentation fault (core dumped)" during build.
> +post-patch:
> + mv ${WRKSRC}/prebuilt/32-bit-big-endian{,-broken}
>
> post-install:
> install -d ${PREFIX}/share/guile/site/${V}/
>
UPDATE: math/R
Dear useRs,
update math/R 3.6.1 -> 3.6.2
- SHARED_LIBS: increase major version number due to removals in dynamic
export changes
$ /usr/src/lib/check_sym libR.so.35.1 libR.so.36.0
libR.so.35.1 --> libR.so.36.0
Dynamic export changes:
removed:
dummy_ii
dummy_ii_ptr
PLT removed:
intpr_
- Update line numbers in patch
- Several lines in PLIST are now marked with "@so" but these files are
no longer in the installed package. Is this expected (i.e., ignored by
the pkg_* machinery or just coincidence)?
All tested packages seems to work without problems; I did not notice
any errors due to the missing .so files.
Works for me on amd64.
OK?
Best regards,
Ingo
Index: Makefile
===
RCS file: /cvs/ports/math/R/Makefile,v
retrieving revision 1.112
diff -u -p -r1.112 Makefile
--- Makefile5 Jul 2019 19:27:30 - 1.112
+++ Makefile12 Dec 2019 13:01:49 -
@@ -1,9 +1,9 @@
# $OpenBSD: Makefile,v 1.112 2019/07/05 19:27:30 feinerer Exp $
COMMENT= powerful math/statistics/graphics language
-DISTNAME= R-3.6.1
+DISTNAME= R-3.6.2
-SO_VERSION=35.1
+SO_VERSION=36.0
.for _lib in R Rblas Rlapack
SHARED_LIBS += ${_lib} ${SO_VERSION}
.endfor
Index: distinfo
===
RCS file: /cvs/ports/math/R/distinfo,v
retrieving revision 1.44
diff -u -p -r1.44 distinfo
--- distinfo5 Jul 2019 19:27:30 - 1.44
+++ distinfo12 Dec 2019 13:01:49 -
@@ -1,2 +1,2 @@
-SHA256 (R-3.6.1.tar.gz) = W6qevT5xrOzcw9ox2QQvsXTVWkKCn4MV8kVwgJeLE4k=
-SIZE (R-3.6.1.tar.gz) = 30463021
+SHA256 (R-3.6.2.tar.gz) = vWWkXN37iPNzcPvO5KyN0/GuvuvkfC+Wj9l3C6K7yVQ=
+SIZE (R-3.6.2.tar.gz) = 33311930
Index: patches/patch-configure
===
RCS file: /cvs/ports/math/R/patches/patch-configure,v
retrieving revision 1.39
diff -u -p -r1.39 patch-configure
--- patches/patch-configure 5 Jul 2019 19:27:30 - 1.39
+++ patches/patch-configure 12 Dec 2019 13:01:49 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-configure,v 1.39 2019/07
Index: configure
--- configure.orig
+++ configure
-@@ -41831,8 +41831,8 @@ fi
+@@ -42057,8 +42057,8 @@ fi
fi
if test "${have_zlib}" = yes; then
@@ -14,7 +14,7 @@ Index: configure
if ${r_cv_header_zlib_h+:} false; then :
$as_echo_n "(cached) " >&6
else
-@@ -41847,7 +41847,7 @@ else
+@@ -42073,7 +42073,7 @@ else
#include
int main() {
#ifdef ZLIB_VERNUM
Index: pkg/PLIST
===
RCS file: /cvs/ports/math/R/pkg/PLIST,v
retrieving revision 1.42
diff -u -p -r1.42 PLIST
--- pkg/PLIST 29 Apr 2019 08:52:48 - 1.42
+++ pkg/PLIST 12 Dec 2019 13:01:49 -
@@ -114,7 +114,7 @@ lib/R/library/KernSmooth/html/
lib/R/library/KernSmooth/html/00Index.html
lib/R/library/KernSmooth/html/R.css
lib/R/library/KernSmooth/libs/
-lib/R/library/KernSmooth/libs/KernSmooth.so
+@so lib/R/library/KernSmooth/libs/KernSmooth.so
lib/R/library/KernSmooth/po/
lib/R/library/KernSmooth/po/de/
lib/R/library/KernSmooth/po/de/LC_MESSAGES/
@@ -163,7 +163,7 @@ lib/R/library/MASS/html/
lib/R/library/MASS/html/00Index.html
lib/R/library/MASS/html/R.css
lib/R/library/MASS/libs/
-lib/R/library/MASS/libs/MASS.so
+@so lib/R/library/MASS/libs/MASS.so
lib/R/library/MASS/po/
lib/R/library/MASS/po/de/
lib/R/library/MASS/po/de/LC_MESSAGES/
@@ -273,7 +273,7 @@ lib/R/library/Matrix/include/Matrix.h
lib/R/library/Matrix/include/Matrix_stubs.c
lib/R/library/Matrix/include/cholmod.h
lib/R/library/Matrix/libs/
-lib/R/library/Matrix/libs/Matrix.so
+@so lib/R/library/Matrix/libs/Matrix.so
lib/R/library/Matrix/po/
lib/R/library/Matrix/po/de/
lib/R/library/Matrix/po/de/LC_MESSAGES/
@@ -404,7 +404,7 @@ lib/R/library/class/html/
lib/R/library/class/html/00Index.html
lib/R/library/class/html/R.css
lib/R/library/class/libs/
-lib/R/library/class/libs/class.so
+@so lib/R/library/class/libs/class.so
lib/R/library/class/po/
lib/R/library/class/po/de/
lib/R/library/class/po/de/LC_MESSAGES/
@@ -453,7 +453,7 @@ lib/R/library/cluster/html/
lib/R/library/cluster/html/00Index.html
lib/R/library/cluster/html/R.css
lib/R/library/cluster/libs/
-lib/R/library/cluster/libs/cluster.so
+@so lib/R/library/cluster/libs/cluster.so
lib/R/library/cluster/po/
lib/R/library/cluster/po/de/
lib/R/library/cluster/po/de/LC_MESSAGES/
@@ -580,7 +580,7 @@ lib/R/library/foreign/html/
lib/R/library/foreign/html/00Index.html
lib/R/library/foreign/html/R.css
lib/R/library/foreign/libs/
-lib/R/library/foreign/libs/foreign.so
+@so lib/R/library/foreign/libs/foreign.so
lib/R/library/foreign/po/
lib/R/library/foreign/po/de/
lib/R/library/foreign/po/de/LC_MESSAGES/
@@ -743,8 +743,8 @@ lib/R/library/grDevices/icc/
lib/R/library/grDevices/icc/srgb
lib/R/library/grDevices/icc/srgb.flate
lib/R/library/grDevices/libs/
[new] devel/yarn an alternative to npm
Hi! This is a port of yarn. It's an alternative to npm. https://blog.npmjs.org/post/189618601100/binary-planting-with-the-npm-cli (I will post an update to node when it lands.) Unfortunately it suffers from some of the same issues. :P DESCR: Fast: Yarn caches every package it has downloaded, so it never needs to download the same package again. It also does almost everything concurrently to maximize resource utilization. This means even faster installs. Reliable: Using a detailed but concise lockfile format and a deterministic algorithm for install operations, Yarn is able to guarantee that any installation that works on one system will work exactly the same on another system. Secure: Yarn uses checksums to verify the integrity of every installed package before its code is executed. OK? Cluestick? "Take yer JS and gtfo?!"? -- PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE yarn.tgz Description: Binary data
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2019/12/12 10:09:47 Modified files: x11/polybar: Makefile x11/polybar/patches: patch-src_modules_temperature_cpp Log message: rework the temperature plugin to remove hardcoded assumptions previously it hardcoded acpitz as the sensor device to query, however some devices (such as the thinkpad X395) lack this particular device. instead use the hwmon-path configuration directive as the device (e.g. ksmn0) and use thermal-zone as the temperature sensor index (e.g. temp0)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/12/12 09:34:19 Modified files: sysutils/reposync: Makefile distinfo sysutils/reposync/pkg: PLIST Log message: update reposync
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2019/12/12 09:25:24 Modified files: sysutils/tmuxinator: Makefile distinfo sysutils/tmuxinator/patches: patch-lib_tmuxinator_config_rb Log message: - update to tmuxinator-1.1.3 - drop maintainership
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2019/12/12 09:22:14 Modified files: sysutils/py-ghmi: Makefile distinfo Log message: update to py-ghmi-1.5.1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2019/12/12 09:21:23 Modified files: devel/py-dateutil: Makefile distinfo devel/py-dateutil/patches: patch-dateutil_test_test_parser_py Log message: update to py-dateutil-2.8.1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2019/12/12 09:16:52 Modified files: security/boofuzz: Makefile distinfo security/boofuzz/patches: patch-setup_py security/boofuzz/pkg: PLIST Log message: update to boofuzz-0.1.6
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: giova...@cvs.openbsd.org2019/12/12 09:10:35 Modified files: mail/p5-Mail-SpamAssassin: Makefile distinfo mail/p5-Mail-SpamAssassin/pkg: PLIST Removed files: mail/p5-Mail-SpamAssassin/patches: patch-lib_Mail_SpamAssassin_Plugin_URILocalBL_pm patch-spamc_getopt_c Log message: Update to 3.4.3 fixes for: CVE-2018-11805 and CVE-2019-12420 Upgrade notice available at https://svn.apache.org/repos/asf/spamassassin/branches/3.4/UPGRADE
Re: update net/dnscrypt-proxy 2.0.35
On Mon 09/12/2019 18:34, Nam Nguyen wrote: > Here is an update to net/dnscrypt-proxy 2.0.35 released December 9, > 2019. > Committed. Thank you!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: b...@cvs.openbsd.org2019/12/12 09:00:21 Modified files: net/dnscrypt-proxy: Makefile distinfo net/dnscrypt-proxy/patches: patch-dnscrypt-proxy_example-dnscrypt-proxy_toml Log message: Update to dnscrypt-proxy-2.0.35. Changelog: https://github.com/DNSCrypt/dnscrypt-proxy/blob/2.0.35/ChangeLog >From Nam Nguyen (maintainer).
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/12/12 07:41:51 Modified files: textproc/pdftk : Makefile distinfo Log message: update to pdftk-3.0.8
aarch64 bulk build report
bulk build on arm64.ports.openbsd.org started on Tue Dec 10 02:01:23 MST 2019 finished at Thu Dec 12 07:25:50 MST 2019 lasted 2D05h24m done with kern.version=OpenBSD 6.6-current (GENERIC.MP) #366: Mon Dec 9 12:29:58 MST 2019 built packages:10299 Dec 10:4061 Dec 11:2660 Dec 12:3577 critical path missing pkgs: http://build-failures.rhaalovely.net/aarch64/2019-12-10/summary.log build failures: 28 http://build-failures.rhaalovely.net/aarch64/2019-12-10/editors/xwpe.log http://build-failures.rhaalovely.net/aarch64/2019-12-10/games/frozen-bubble,-main.log http://build-failures.rhaalovely.net/aarch64/2019-12-10/games/vacuum.log http://build-failures.rhaalovely.net/aarch64/2019-12-10/graphics/gegl04.log http://build-failures.rhaalovely.net/aarch64/2019-12-10/graphics/vulkan-loader.log http://build-failures.rhaalovely.net/aarch64/2019-12-10/lang/compcert.log http://build-failures.rhaalovely.net/aarch64/2019-12-10/lang/pfe.log http://build-failures.rhaalovely.net/aarch64/2019-12-10/net/minio/client.log http://build-failures.rhaalovely.net/aarch64/2019-12-10/net/routinator.log http://build-failures.rhaalovely.net/aarch64/2019-12-10/security/sn0int.log http://build-failures.rhaalovely.net/aarch64/2019-12-10/shells/elvish.log http://build-failures.rhaalovely.net/aarch64/2019-12-10/sysutils/amazon-ecs-cli.log http://build-failures.rhaalovely.net/aarch64/2019-12-10/sysutils/beats/filebeat.log http://build-failures.rhaalovely.net/aarch64/2019-12-10/sysutils/beats/heartbeat.log http://build-failures.rhaalovely.net/aarch64/2019-12-10/sysutils/beats/metricbeat.log http://build-failures.rhaalovely.net/aarch64/2019-12-10/sysutils/beats/packetbeat.log http://build-failures.rhaalovely.net/aarch64/2019-12-10/sysutils/fzf.log http://build-failures.rhaalovely.net/aarch64/2019-12-10/sysutils/node_exporter.log http://build-failures.rhaalovely.net/aarch64/2019-12-10/sysutils/nomad.log http://build-failures.rhaalovely.net/aarch64/2019-12-10/sysutils/rclone.log http://build-failures.rhaalovely.net/aarch64/2019-12-10/sysutils/restic.log http://build-failures.rhaalovely.net/aarch64/2019-12-10/sysutils/serf.log http://build-failures.rhaalovely.net/aarch64/2019-12-10/sysutils/snmp_exporter.log http://build-failures.rhaalovely.net/aarch64/2019-12-10/sysutils/telegraf.log http://build-failures.rhaalovely.net/aarch64/2019-12-10/sysutils/terraform/provider-dns.log http://build-failures.rhaalovely.net/aarch64/2019-12-10/www/hugo.log http://build-failures.rhaalovely.net/aarch64/2019-12-10/x11/e17/elementary.log http://build-failures.rhaalovely.net/aarch64/2019-12-10/x11/qt5/qt3d.log recurrent failures failures/editors/xwpe.log failures/games/frozen-bubble,-main.log failures/games/vacuum.log failures/graphics/gegl04.log failures/lang/pfe.log failures/net/minio/client.log failures/net/routinator.log failures/security/sn0int.log failures/shells/elvish.log failures/sysutils/amazon-ecs-cli.log failures/sysutils/beats/heartbeat.log failures/sysutils/beats/metricbeat.log failures/sysutils/beats/packetbeat.log failures/sysutils/fzf.log failures/sysutils/node_exporter.log failures/sysutils/nomad.log new failures +++ ls-failures Thu Dec 12 07:26:00 2019 resolved failures --- ../old/aarch64/last//ls-failuresTue Dec 3 10:13:27 2019 -failures/games/dxx-rebirth.log -failures/productivity/gnucash.log -failures/sysutils/facette.log
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2019/12/12 07:16:36 Modified files: www/firefox-esr: Makefile mail/mozilla-thunderbird: Makefile Removed files: www/firefox-esr/patches: patch-python_mozbuild_mozbuild_action_node_py mail/mozilla-thunderbird/patches: patch-python_mozbuild_mozbuild_action_node_py Log message: Build adjustments: * remove patch that was applied upstream * devel/nasm is only a build depend on i386/amd64 * build verbosely * limit cargo to MAKE_JOBS okay landry@
Re: postgresql: libc collation issue, linking with ICU
Jeremie Courreges-Anglas - Thu, 12 December 2019 at 11:35:51
> Can you actually use ICU as the default collation algorithm used by
> a database?
it's not totally straightforward but yes, on the schema level it's
possible to override collation:
macos=# CREATE TABLE t (n text COLLATE "fr-FR-x-icu");
CREATE TABLE
macos=# INSERT INTO t (values ('bernard'),('bérénice'),('béatrice'),('boris'));
INSERT 0 4
macos=# SELECT * FROM t ORDER BY n;
n
--
béatrice
bérénice
bernard
boris
(4 rows)
macos=# show lc_collate;
lc_collate
C
(1 row)
macos=# \d t
Table "public.t"
Column | Type | Collation | Nullable | Default
+--+-+--+-
n | text | fr-FR-x-icu | |
however `CREATE DATABASE` and `initdb` does not support this. it's WIP:
https://www.postgresql-archive.org/ICU-for-global-collation-td6099973.html
it is far from ideal but at least having the option to override the
collation on both schema and/or individual query level means a working
sorting.
this is a good article when ICU was introduced:
https://www.2ndquadrant.com/en/blog/icu-support-postgresql-10/
(...i wonder what's the actual situation with mariadb...)
-f
--
tower: "say position." pilot: "position."
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2019/12/12 03:54:50 Modified files: geo/qgis : Makefile distinfo geo/qgis/patches: patch-src_core_CMakeLists_txt patch-src_providers_wms_CMakeLists_txt geo/qgis/pkg : PLIST Log message: Update to qgis 3.10.1
Re: postgresql: libc collation issue, linking with ICU
On Thu, Dec 12 2019, "f.holop" wrote: > Landry Breuil - Thu, 12 December 2019 at 08:51:49 >> On Thu, Dec 12, 2019 at 01:47:25AM +0100, Jeremie Courreges-Anglas wrote: >> > >> > +cc maintainer >> > >> > This has bugged me for some time, I think enabling ICU makes sense. >> > Here's a wip diff. I fear it might cause issues with existing >> > databases. Real world tests would probably help. >> >> I doubt it can have side effects on existing databases as they all have >> a locale (and potential collations) configured during initdb, and adding >> the possibility to use more locales/collations shouldnt affect existing >> ones. Of course, to be tested in the real world :) > > initdb just sets "default" collation/ctype for `template1`. when > collation/ctype needs to be different, `CREATE DATABASE` must use the > template `template0`. > > Collation cannot be changed on a database after it has been created as > it affects the index creation as well. Can you actually use ICU as the default collation algorithm used by a database? Sadly using ICU doesn't seem to be the silver bullet I was hoping for. postgres on Linux distros still defaults to the libc collation backend. You can't just push a button so that ICU is used by default[0]. [0] https://www.postgresql.org/message-id/flat/3366.1498183854%40sss.pgh.pa.us#3366.1498183...@sss.pgh.pa.us So right now it seems that adding ICU might help a few users who can tweak their schemas for their specific needs. That's much less interesting than what I expected. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2019/12/12 02:39:26 Modified files: devel/quirks : Makefile devel/quirks/files: Quirks.pm Log message: Register p5-Geo-IP removal.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2019/12/12 02:38:27 Modified files: net: Makefile Removed files: net/p5-Geo-IP : Makefile distinfo net/p5-Geo-IP/pkg: DESCR PLIST Log message: Remove net/p5-Geo-IP. The GeoIP/GeoLite databases are now legacy, so this module is not useful anymore. Nothing in the ports tree uses it since we disabled the geoip module in AWStats. OK kn@, jca@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2019/12/12 02:27:39 Modified files: misc/dialog: Makefile distinfo Log message: Update dialog to 1.3-20191210.
Re: update: lang/rust
Yes, I sort of agree, but personally I will run with this meanwhile. I now recall what it was that made me do this: wasm. The wasm-pack system requires the version of rustc to match with the wasm32-unknown-unknown target, and I thought it better (read: easier :-) )to use the published target instead of bootstrapping it myself. Esp. if the only reason is to get matching version strings. As the tarball version is containing the githash+date information I thought this was the easiest way. Call me lazy :-) I still had to build rust myself since I wanted 1.39 for other reasons. I won't push for the offical port of yours to contain this, I just wanted to contribute an idea. Do with it what you like. Maybe I will open a ticket with rustc for the tarball to contain the version, it makes sense I think. /Niklas On 2019-12-12 09:15, Sebastien Marie wrote: On Thu, Dec 12, 2019 at 07:52:21AM +0100, Niklas Hallqvist wrote: As a matter of fact I did the same update just a week ago, and ended up in exactly the same patch set as you, except for one thing: The version reported by 'rust -V' normally include the git hash and date, and some rust code out there depends on it (maybe dumb, but nevertheless it is). it is currently expected for build from a tarball. git information is only included when build from a git directory. so I am expecting that any rust installed from distribution to share the same output. (but when installed from rustup, it comes from a build from mozilla which is done using git) if some rust crate depends on it, you should open a bug report. it could be interesting to also open a bug report on rustc itself in order to include the information for tarball too (the tarball contains at least the commit-hash information). Thanks.
Re: postgresql: libc collation issue, linking with ICU
Landry Breuil - Thu, 12 December 2019 at 08:51:49 > On Thu, Dec 12, 2019 at 01:47:25AM +0100, Jeremie Courreges-Anglas wrote: > > > > +cc maintainer > > > > This has bugged me for some time, I think enabling ICU makes sense. > > Here's a wip diff. I fear it might cause issues with existing > > databases. Real world tests would probably help. > > I doubt it can have side effects on existing databases as they all have > a locale (and potential collations) configured during initdb, and adding > the possibility to use more locales/collations shouldnt affect existing > ones. Of course, to be tested in the real world :) initdb just sets "default" collation/ctype for `template1`. when collation/ctype needs to be different, `CREATE DATABASE` must use the template `template0`. Collation cannot be changed on a database after it has been created as it affects the index creation as well. -f -- why is the alphabet in that order? is it because of that song?
Re: update: lang/rust
On Thu, Dec 12, 2019 at 07:52:21AM +0100, Niklas Hallqvist wrote: > As a matter of fact I did the same update just a week ago, and ended up in > exactly the same patch set as you, except for one thing: > > The version reported by 'rust -V' normally include the git hash and date, and > some rust code out there depends on it (maybe dumb, but nevertheless it is). it is currently expected for build from a tarball. git information is only included when build from a git directory. so I am expecting that any rust installed from distribution to share the same output. (but when installed from rustup, it comes from a build from mozilla which is done using git) if some rust crate depends on it, you should open a bug report. it could be interesting to also open a bug report on rustc itself in order to include the information for tarball too (the tarball contains at least the commit-hash information). Thanks. -- Sebastien Marie
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2019/12/12 01:04:55 Modified files: security/exploitdb: Makefile distinfo security/exploitdb/pkg: PLIST Log message: Update to 2019-12-12
