Re: UPDATE: security/opendnssec
Hi Patrik, Pavel, > On Sun, Dec 30, 2018 at 03:27:42PM +0100, Rafael Sadowski wrote: > > On Sun Nov 18, 2018 at 04:57:55PM +0300, Pavel Korovin wrote: > > > Dear all, > > > please find the update for the latest OpenDNSSEC attached. > > > Tested with sqlite3, softhsm/softhsm2 on amd64. > > > Also tested migration from v1.4 (enforcer database migration is > > > required for v2). Спасибо Pavel for the v2 port. If I may ask, are there any specific OpenBSD related things to keep in mind while running OpenDNSSec v2? I ask this because it appears that there are some changes in the architecture in this version. > > It seems I missed this work completely somehow, sorry about that! > > Nice to see you are working on both opendnssec and softhsm 2.x :). > > I am actually not running opendnssec any more[1], if you would like to > take over maintainership I would be fine with that. This goes for > softhsm 1.x as well. > > > > > Is there any howto to migrate from 1.4? A note or an howto/link to > > current.html would be nice! > > > > There is an official note about this here: > https://wiki.opendnssec.org/pages/viewpage.action?pageId=10125376#HowdoI...?-UpgradeOpenDNSSEC1.4.9toOpenDNSSEC2.0 > > -- > Patrik Lundin > > [1]: https://blog.sigterm.se/posts/to-the-cloud-dns-edition/ Tack så mycket Patrik for that informative blog post. Could I request you to please help me with my queries: 1) Since the capability to run OpenBSD virtual machines is now present in the base, would you still suggest running authoritative DNS in "cloud" vs on VMs in on-premise/rented baremetal OpenBSD machines? I ask this because I have trouble relying on cloud, and as I have learnt, "free" in cloud usually translates to "you do not know how you pay". 2) Could you please elaborate on the custom built DNS server daemon? I find that very interesting, especially when combined with OpenDNSSEC. Dhanyavaad. Regards, ab -|-|-|-|-|-|-|--
[UPDATE] www/newsboat to 2.14
Hi ports@,
Here is a diff to update newsboat to 2.14, which now depends on Rust
and Cargo. All the work was done by semarie@.
I've been running newsboat for three weeks with this diff and haven't
noticed any regressions, but more testing would definitely be welcome.
Comments? OK?
Index: Makefile
===
RCS file: /cvs/ports/www/newsboat/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- Makefile27 Sep 2018 09:15:27 - 1.6
+++ Makefile18 Jan 2019 11:57:46 -
@@ -2,7 +2,7 @@
COMMENT = RSS/Atom feed reader for text terminals
-V =2.13
+V =2.14
DISTNAME = newsboat-$V
CATEGORIES = www
@@ -23,6 +23,86 @@ EXTRACT_SUFX = .tar.xz
COMPILER = base-clang ports-gcc
+DISTFILES += ${DISTNAME}${EXTRACT_SUFX}
+MODULES = devel/cargo
+
+MODCARGO_BUILD = No
+MODCARGO_INSTALL = No
+MODCARGO_TEST =No
+
+MODCARGO_CRATES += aho-corasick0.6.9 # Unlicense/MIT
+MODCARGO_CRATES += argon2rs0.2.5 # MIT
+MODCARGO_CRATES += arrayvec0.4.9 # MIT/Apache-2.0
+MODCARGO_CRATES += autocfg 0.1.1 # Apache-2.0/MIT
+MODCARGO_CRATES += backtrace 0.3.13 # MIT/Apache-2.0
+MODCARGO_CRATES += backtrace-sys 0.1.26 # MIT/Apache-2.0
+MODCARGO_CRATES += bitflags1.0.4 # MIT/Apache-2.0
+MODCARGO_CRATES += blake2-rfc 0.2.18 # MIT OR Apache-2.0
+MODCARGO_CRATES += cc 1.0.26 # MIT/Apache-2.0
+MODCARGO_CRATES += cfg-if 0.1.6 # MIT/Apache-2.0
+MODCARGO_CRATES += chrono 0.4.6 # MIT/Apache-2.0
+MODCARGO_CRATES += cloudabi0.0.3 # BSD-2-Clause
+MODCARGO_CRATES += constant_time_eq0.1.3 # CC0-1.0
+MODCARGO_CRATES += dirs1.0.4 # MIT OR Apache-2.0
+MODCARGO_CRATES += failure 0.1.3 # MIT OR Apache-2.0
+MODCARGO_CRATES += failure_derive 0.1.3 # MIT OR Apache-2.0
+MODCARGO_CRATES += fuchsia-zircon 0.3.3 # BSD-3-Clause
+MODCARGO_CRATES += fuchsia-zircon-sys 0.3.3 # BSD-3-Clause
+MODCARGO_CRATES += idna0.1.5 # MIT/Apache-2.0
+MODCARGO_CRATES += lazy_static 1.2.0 # MIT/Apache-2.0
+MODCARGO_CRATES += libc0.2.45 # MIT OR Apache-2.0
+MODCARGO_CRATES += lock_api0.1.5 # Apache-2.0/MIT
+MODCARGO_CRATES += matches 0.1.8 # MIT
+MODCARGO_CRATES += memchr 2.1.2 # Unlicense/MIT
+MODCARGO_CRATES += nodrop 0.1.13 # MIT/Apache-2.0
+MODCARGO_CRATES += num-integer 0.1.39 # MIT/Apache-2.0
+MODCARGO_CRATES += num-traits 0.2.6 # MIT/Apache-2.0
+MODCARGO_CRATES += once_cell 0.1.6 # MIT OR Apache-2.0
+MODCARGO_CRATES += parking_lot 0.6.4 # Apache-2.0/MIT
+MODCARGO_CRATES += parking_lot_core0.3.1 # Apache-2.0/MIT
+MODCARGO_CRATES += percent-encoding1.0.1 # MIT/Apache-2.0
+MODCARGO_CRATES += proc-macro2 0.4.24 # MIT/Apache-2.0
+MODCARGO_CRATES += quote 0.6.10 # MIT/Apache-2.0
+MODCARGO_CRATES += rand0.4.3 # MIT/Apache-2.0
+MODCARGO_CRATES += rand0.5.5 # MIT/Apache-2.0
+MODCARGO_CRATES += rand0.6.1 # MIT/Apache-2.0
+MODCARGO_CRATES += rand_chacha 0.1.0 # MIT/Apache-2.0
+MODCARGO_CRATES += rand_core 0.2.2 # MIT/Apache-2.0
+MODCARGO_CRATES += rand_core 0.3.0 # MIT/Apache-2.0
+MODCARGO_CRATES += rand_hc 0.1.0 # MIT/Apache-2.0
+MODCARGO_CRATES += rand_isaac 0.1.1 # MIT/Apache-2.0
+MODCARGO_CRATES += rand_pcg0.1.1 # MIT/Apache-2.0
+MODCARGO_CRATES += rand_xorshift 0.1.0 # MIT/Apache-2.0
+MODCARGO_CRATES += redox_syscall 0.1.44 # MIT
+MODCARGO_CRATES += redox_users 0.2.0 # MIT
+MODCARGO_CRATES += regex 1.1.0 # MIT/Apache-2.0
+MODCARGO_CRATES += regex-syntax0.6.4 # MIT/Apache-2.0
+MODCARGO_CRATES += remove_dir_all 0.5.1 # MIT/Apache-2.0
+MODCARGO_CRATES += rustc-demangle 0.1.11 # MIT/Apache-2.0
+MODCARGO_CRATES += rustc_version 0.2.3 # MIT/Apache-2.0
+MODCARGO_CRATES += scoped_threadpool 0.1.9 # MIT
+MODCARGO_CRATES += scopeguard 0.3.3 # MIT/Apache-2.0
+MODCARGO_CRATES += semver 0.9.0 # MIT/Apache-2.0
+MODCARGO_CRATES += semver-parser 0.7.0 # MIT/Apache-2.0
+MODCARGO_CRATES += smallvec0.6.7 # MIT/Apache-2.0
+MODCARGO_CRATES += syn 0.15.23 # MIT/Apache-2.0
+MODCARGO_CRATES += synstructure0.10.1 # MIT
+MODCARGO_CRATES += tempfile3.0.5 # MIT/Apache-2.0
+MODCARGO_CRATES += thread_local0.3.6 # Apache-2.0/MIT
+MODCARGO_CRATES += time0.1.41 # MIT/Apache-2.0
+MODCARGO_CRATES += ucd-util0.1.3 # MIT/Apache-2.0
+MODCARGO_CRATES += unicode-bidi0.3.4 # MIT / Apache-2.0
+MODCARGO_CRATES += unicode-normalization 0.1.7 # MIT/Apache-2.0
+MODCARGO_CRATES += unicode-xid 0.1.0 # MIT/Apache-2.0
+MODCARGO_CRATES += unreacha
Re: x11/qt5/{qtgraphicaleffects,qtquickcontrols*} when not x86
On Tue, 5 Feb 2019 13:02:52 +0100
Charlene Wendling wrote:
> Hi!
>
> On Tue, 5 Feb 2019 00:02:15 -0500
> George Koehler wrote:
>
> > This mail is about the OpenBSD ports of
> > - x11/qt5/qtgraphicaleffects
> > - x11/qt5/qtquickcontrols
> > - x11/qt5/qtquickcontrols2
> >
> > These ports work on amd64 and i386, but are broken on aarch64,
> > powerpc, and probably other platforms. Each port has .qmlc files in
> > its PLIST. Each port runs qmlcachegen (from x11/qt5/qtdeclarative)
> > to build .qmlc files from .qml files, but this tool writes machine
> > code (like x86 or x86-64 code) and gets disabled in other platforms.
> > Each port fails in the package phase if the .qmlc files don't exist.
>
> Yes, there are *.jsc as well with the same problem.
>
> landry@ gave me some hints, we could use the QML_DISABLE_DISK_CACHE
> environment variable and disable all those cache files everywhere. But
> according to the Qt people, there will be a performance drawback [1]
> if we do it that way.
>
> > From the (arm64) aarch64 bulk of 3 Feb 2019:
> > > http://build-failures.rhaalovely.net/aarch64/2019-01-31/x11/qt5/qtgraphicaleffects.log
> > > http://build-failures.rhaalovely.net/aarch64/2019-01-31/x11/qt5/qtquickcontrols,-examples.log
> > > http://build-failures.rhaalovely.net/aarch64/2019-01-31/x11/qt5/qtquickcontrols2.log
> >
> > From the (macppc) powerpc bulk of 4 Feb 2019:
> > > http://build-failures.rhaalovely.net//powerpc/2019-01-12/x11/qt5/qtgraphicaleffects.log
> > > http://build-failures.rhaalovely.net//powerpc/2019-01-12/x11/qt5/qtquickcontrols.log
> > > http://build-failures.rhaalovely.net//powerpc/2019-01-12/x11/qt5/qtquickcontrols2.log
> >
> > I found some logic in qt5/qtdeclarative in
> > WRKSRC/src/qml/jsruntime/qv4global_p.h that defines V4_ENABLE_JIT
> > on some platforms. I suspect that qmlcachegen uses the JIT to
> > write .qmlc files, but I am less than sure.
> >
> > The JIT is enabled if:
> > - we are x86 or x86-64 and an OS in a list including OpenBSD.
> > - we are arm 32-bit, and something about Thumb is true, but I don't
> > know whether it is true in OpenBSD.
> > - we are arm 64-bit, but only for Linux or QNX, not for OpenBSD.
> > - we are mips 32-bit and Linux.
> >
> > From this, I guess that qmlcachegen on OpenBSD can write .qmlc files
> > only for i386 or amd64.
>
> The implied code called by WRKSRC/tools/qmlcachegen/qmlcachegen.cpp
> [2] can be found in WRKSRC/src/qml/jit/qv4isel_masm.cpp [3]. I was
> more optimist than you are and i tend to trust your reading more than
> mine :)
>
> > When a qmake project does `CONFIG += qmlcache`, it checks if
> > qmlcachegen can target this platform. If not, qmake outputs a line,
> > > Project MESSAGE: QML cache generation requested but target
> > > architecture * is not supported.
> > where * is a name like "arm64" or "power". You can see this
> > line in dpb's .log files.
> >
> > If you have installed qtdeclarative, and you know your own QT_ARCH
> > (see /usr/local/lib/qt5/mkspecs/qconfig.pri), then you can run
> >
> > $ /usr/local/lib/qt5/bin/qmlcachegen --target-architecture * \
> > > --check-if-supported; echo $?
> >
> > In my amd64 vm, where QT_ARCH = x86_64, it echoes 0 so .qmlc is
> > supported. In my macppc machine, where QT_ARCH = power, it echoes 1
> > so .qmlc is not supported. You can only check your own arch,
> > because qmlcachegen might not cross to other arches.
> >
> > The fix might be to move .qmlc files from PLIST to PFRAG.qmlc, but
> > I have not yet tried to do so.
>
> What can i say is that i was able to run lxqt on macppc without any
> issues without these cached files.
>
> I had the same idea initially, but sthen@ proposed a better (imho)
> alternative, introducing a MODQT5_COMMENT the same way Python does it
> with MODPY_COMMENT, so we don't have to use PFRAGs.
>
> I've packaged successfully these 3 ports with the diff i'm attaching
> but reversed the conditional since then, according to your findings.
>
> This hasn't been tested elsewhere that on macppc for now, and i needed
> to do a make clean=plist before make package. I can't guarantee it's
> perfect, but i felt like it was time to share it, to avoid duplicating
> our work.
My change to SUBST_VARS made VERSION not being expanded, actually
breaking packaging with the other x11/qt5 ports includig ${VERSION}
in PLISTs.
I'm joining a new diff that fixes that on my macppc and amd64 machines.
Charlène.
>
>
> > --
> > George Koehler
> >
>
>
> [1]
> https://blog.qt.io/blog/2019/01/11/qt-5-12-lts-road-faster-qml-application-startup/
> [2]
> https://github.com/qt/qtdeclarative/blob/ba6de61acd3129ad1435f6bca7f564385212f95c/tools/qmlcachegen/qmlcachegen.cpp
> [3]
> https://github.com/qt/qtdeclarative/blob/5.9/src/qml/jit/qv4isel_masm.cpp#L1645
qt5.diff
Description: Binary data
Re: [New] x11/xdgmenumaker 1.5
Anyone interested? Reattaching the tarball. On 2/2/19 4:11 PM, Alessandro DE LAURENZIS wrote: Hello, Second, for all tests involving icon paths (-i option), the following > Gtk critical error is issued:> >> (xdgmenumaker:69800): Gtk-CRITICAL **: 11:22:30.780: >> gtk_icon_theme_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' >> failed ERROR: You need to run xdgmenumaker inside an X session. test suite need an active X11 display to work, so I added TEST_IS_INTERACTIVE = X11; on top of that, I patched the upstream test Makefile, changing LANG=xxx in LANG=C. Now all tests are pass, except: - those referring to a stranger locales (el_GR.utf8, de_DE.utf8, fr_FR.utf8), not supported by OpenBSD; - those that produce menus with icons, which are expected to fail, as per author warning (see [1]). I think the port is ready to import. Just let me know what you think. Updated tarball attached. [1] https://github.com/gapan/xdgmenumaker/blob/master/TESTS -- Alessandro DE LAURENZIS [mailto:jus...@atlantide.t28.net] Web: http://www.atlantide.t28.net LinkedIn: https://www.linkedin.com/in/delaurenzis/ xdgmenumaker.tar.gz Description: application/gzip
Re: password-store depends on gnupg-1.4.23?
On Wed, Feb 06, 2019 at 11:32:54PM +0100, Sebastian Benoit wrote: > $ doas pkg_delete gnupg-1.4.23p1 > can't delete gnupg-1.4.23p1 without deleting password-store-1.7.3 > Delete them as well ? [y/N/a] > > but password-store has security/gnupg2 as dependency, not gnupg-1.4... > > Port: password-store-1.7.3 > Path: security/password-store > Info: simple password store > Maint: David Dahlberg > Index: security > L-deps: > B-deps: archivers/xz devel/gmake > R-deps: converters/base64 devel/git graphics/libqrencode misc/gnugetopt > security/gnupg2 shells/bash sysutils/colortree x11/xclip > Archs: any > > $ pkg_info | grep gnupg > gnupg-1.4.23p1 GNU privacy guard - a free PGP replacement > gnupg-2.2.12GNU privacy guard - a free PGP replacement > > Is there some magic i have to do? Basically, things don't work like you think they do. By default, you get a dependency on PKGSPEC which does default to gnupg-* and by default, while building ports, you get pointed to security/gnupg2, which ends up being @depend gnupg-*:security/gnupg2:gnupg-2.2.12 e.g., any gnupg will satisfy the dependency. This is documented, AND deliberate. Most ports have different stems when they're different. And this also allows distinct flavors to "take over" when it makes sense. That's also why you can specify a PKGSPEC in a dependent port to make sure those kinds of ambiguities get resolved. See, for instance, how the gcc ports do it.
Re: x11/qt5/{qtgraphicaleffects,qtquickcontrols*} when not x86
On Thu, Feb 07, 2019 at 01:09:30PM +0100, Charlene Wendling wrote:
> On Tue, 5 Feb 2019 13:02:52 +0100
> Charlene Wendling wrote:
>
> > This hasn't been tested elsewhere that on macppc for now, and i needed
> > to do a make clean=plist before make package. I can't guarantee it's
> > perfect, but i felt like it was time to share it, to avoid duplicating
> > our work.
>
> My change to SUBST_VARS made VERSION not being expanded, actually
> breaking packaging with the other x11/qt5 ports includig ${VERSION}
> in PLISTs.
>
> I'm joining a new diff that fixes that on my macppc and amd64 machines.
If the PLIST doesnt change on x86 then no bump is needed, and since it
didnt package before on !x86 no bump is needed there either. I like this
diff - ok for me.
Re: Update: textproc/py-unidecode 0.04.20 -> 1.0.23
On 2019/02/06 18:55, Kurt Mosiejczuk wrote: > This is not as big a jump as it might appear. Upstream fixed their > versioning by going from 0.04.21 to 1.0.22 last year. So this is really > just two point revisions newer. committed. > I got rid of the special handling and switched it back to MODPY_PI. > The version numbers are normal now and the special handling didn't > seem to work anyway since the package version was 0.04.20, and not > the 0.4.20 that seemed to be intended. it was meant for making the file be fetchable, rather than changing the version number in DISTNAME.
Re: UPDATE: www/gitea
Stuart, thanks! Fixed in the attached diff.
OK to update? Robert?
On 02/05, Stuart Henderson wrote:
> On 2019/02/05 18:17, Pavel Korovin wrote:
> > --- pkg/README 4 Sep 2018 12:46:24 - 1.2
> > +++ pkg/README 4 Feb 2019 22:01:25 -
> > @@ -4,15 +4,48 @@ $OpenBSD: README,v 1.2 2018/09/04 12:46:
> > | Running ${PKGSTEM} on OpenBSD
> > +---
> >
> > -Gitea can be setup to serve HTTP requests on its own, or can run behind
> > -HTTP proxy like relayd(8) or nginx(8). Another option is to let OpenBSD
> > -httpd(8) serve HTTP requests and pass it to Gitea via FastCGI protocol.
> > +Initial configuration
> > +=
> > +By default ${PKGSTEM} listens on all configured IP addresses, TCP port
> > 3000.
> .
> > +
> > +Running ${PKGSTEM} with PostsgreSQL
> > +==
> > +If you want to use ${PKGSTEM} with PostgreSQL as backend database, please
> > note
> .
>
> I don't think it is an improvement to use ${PKGSTEM} in the text in README.
>
--
With best regards,
Pavel Korovin
Index: Makefile
===
RCS file: /cvs/ports/www/gitea/Makefile,v
retrieving revision 1.15
diff -u -p -r1.15 Makefile
--- Makefile28 Jan 2019 11:46:26 - 1.15
+++ Makefile7 Feb 2019 12:49:47 -
@@ -2,7 +2,7 @@
COMMENT = compact self-hosted Git service
-VERSION = 1.7.0
+VERSION = 1.7.1
GH_ACCOUNT = go-gitea
GH_PROJECT = gitea
GH_TAGNAME = v${VERSION}
@@ -23,8 +23,7 @@ MODULES = lang/go
MODGO_ENV =PATH="${PORTPATH}" CFLAGS="${CFLAGS}"
MODGO_FLAGS += -tags "sqlite cert"
-RUN_DEPENDS = devel/git \
- shells/bash
+RUN_DEPENDS = devel/git
ALL_TARGET = code.gitea.io/${GH_PROJECT}
WRKSRC = ${MODGO_WORKSPACE}/src/${ALL_TARGET}
Index: distinfo
===
RCS file: /cvs/ports/www/gitea/distinfo,v
retrieving revision 1.8
diff -u -p -r1.8 distinfo
--- distinfo28 Jan 2019 11:46:26 - 1.8
+++ distinfo7 Feb 2019 12:49:47 -
@@ -1,2 +1,2 @@
-SHA256 (gitea-1.7.0.tar.gz) = L91NUbIvQMA+alXAZdr7z60WyhSt9PCTzu2J5ZSA9nk=
-SIZE (gitea-1.7.0.tar.gz) = 20829587
+SHA256 (gitea-1.7.1.tar.gz) = eii6w2zwbhqQwt9pIlannSnMbmUqqJ9Md4M7moSBpUE=
+SIZE (gitea-1.7.1.tar.gz) = 20834721
Index: patches/patch-custom_conf_app_ini_sample
===
RCS file: /cvs/ports/www/gitea/patches/patch-custom_conf_app_ini_sample,v
retrieving revision 1.3
diff -u -p -r1.3 patch-custom_conf_app_ini_sample
--- patches/patch-custom_conf_app_ini_sample28 Jan 2019 11:46:26 -
1.3
+++ patches/patch-custom_conf_app_ini_sample7 Feb 2019 12:49:47 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-custom_conf_app_ini_samp
Index: custom/conf/app.ini.sample
--- custom/conf/app.ini.sample.orig
+++ custom/conf/app.ini.sample
-@@ -7,12 +7,12 @@
+@@ -7,19 +7,19 @@
; App name that shows in every page title
APP_NAME = Gitea: Git with a cup of tea
; Change it if you run locally
@@ -15,10 +15,19 @@ Index: custom/conf/app.ini.sample
[repository]
-ROOT =
+-SCRIPT_TYPE = bash
+ROOT = ${LOCALSTATEDIR}/gitea/gitea-repositories
- SCRIPT_TYPE = bash
++SCRIPT_TYPE = sh
; Default ANSI charset
ANSI_CHARSET =
+ ; Force every new repository to be private
+ FORCE_PRIVATE = false
+ ; Default privacy setting when creating a new repository, allowed values:
last, private, public. Default is last which means the last setting used.
+-DEFAULT_PRIVATE = last
++DEFAULT_PRIVATE = private
+ ; Global limit of repositories per user, applied at creation time. -1 means
no limit
+ MAX_CREATION_LIMIT = -1
+ ; Mirror sync queue length, increase if mirror syncing starts hanging
@@ -52,7 +52,7 @@ LOCAL_WIKI_PATH = tmp/local-wiki
; Whether repository file uploads are enabled. Defaults to `true`
ENABLED = true
@@ -28,15 +37,33 @@ Index: custom/conf/app.ini.sample
; One or more allowed types, e.g. image/jpeg|image/png. Nothing means any
file type
ALLOWED_TYPES =
; Max size of each file in megabytes. Defaults to 3MB
+@@ -82,7 +82,7 @@ THEME_COLOR_META_TAG = `#6cc644`
+ ; Max size of files to be displayed (default is 8MiB)
+ MAX_DISPLAY_FILE_SIZE = 8388608
+ ; Whether the email of the user should be shown in the Explore Users page
+-SHOW_USER_EMAIL = true
++SHOW_USER_EMAIL = false
+ ; Set the default theme for the Gitea install
+ DEFAULT_THEME = gitea
+
@@ -147,7 +147,7 @@ SSH_DOMAIN = %(DOMAIN)s
; The network interface the builtin SSH server should listen on
SSH_LISTEN_HOST =
; Port number to be exposed in clone URL
-SSH_PORT = 22
-+SSH_PORT =
++SSH_PORT =
; The port number the builtin SSH server should listen on
SSH_LISTEN_PORT = %(SSH_PORT)s
; Root path of SSH directory, default is
UPDATE: Nextcloud-15.0.4
Hello,
Update for Nextcloud to 15.0.4:
https://nextcloud.com/changelog/
OK? Comments?
Cheers.-
--
Sending from my toaster.
Index: Makefile
===
RCS file: /cvs/ports/www/nextcloud/Makefile,v
retrieving revision 1.32
diff -u -p -r1.32 Makefile
--- Makefile15 Jan 2019 15:38:53 - 1.32
+++ Makefile7 Feb 2019 13:00:46 -
@@ -2,7 +2,7 @@
COMMENT= easy and universal access to shared and/or personal
files
-V= 15.0.2
+V= 15.0.4
DISTNAME= nextcloud-${V}
EXTRACT_SUFX= .tar.bz2
Index: distinfo
===
RCS file: /cvs/ports/www/nextcloud/distinfo,v
retrieving revision 1.20
diff -u -p -r1.20 distinfo
--- distinfo15 Jan 2019 15:38:53 - 1.20
+++ distinfo7 Feb 2019 13:00:46 -
@@ -1,2 +1,2 @@
-SHA256 (nextcloud-15.0.2.tar.bz2) =
wfTMM+OZlN2+Z3c3C2LDC3rlITagUwwLmSJ3CAPKD+o=
-SIZE (nextcloud-15.0.2.tar.bz2) = 36224830
+SHA256 (nextcloud-15.0.4.tar.bz2) =
+H2wR8F09WPjkaIslZ2aznZ8oU7w+X/DlPMGH8Y9j3c=
+SIZE (nextcloud-15.0.4.tar.bz2) = 47648166
Index: pkg/PLIST
===
RCS file: /cvs/ports/www/nextcloud/pkg/PLIST,v
retrieving revision 1.23
diff -u -p -r1.23 PLIST
--- pkg/PLIST 15 Jan 2019 15:38:53 - 1.23
+++ pkg/PLIST 7 Feb 2019 13:00:49 -
@@ -4949,8 +4949,8 @@ nextcloud/apps/activity/appinfo/routes.p
nextcloud/apps/activity/appinfo/signature.json
nextcloud/apps/activity/appinfo/update.php
nextcloud/apps/activity/css/
-nextcloud/apps/activity/css/settings.css
-nextcloud/apps/activity/css/style.css
+nextcloud/apps/activity/css/settings.scss
+nextcloud/apps/activity/css/style.scss
nextcloud/apps/activity/docs/
nextcloud/apps/activity/docs/create.md
nextcloud/apps/activity/docs/endpoint-v2.md
@@ -5598,6 +5598,8 @@ nextcloud/apps/dav/l10n/el.js
nextcloud/apps/dav/l10n/el.json
nextcloud/apps/dav/l10n/en_GB.js
nextcloud/apps/dav/l10n/en_GB.json
+nextcloud/apps/dav/l10n/eo.js
+nextcloud/apps/dav/l10n/eo.json
nextcloud/apps/dav/l10n/es.js
nextcloud/apps/dav/l10n/es.json
nextcloud/apps/dav/l10n/es_419.js
@@ -10045,6 +10047,8 @@ nextcloud/apps/nextcloud_announcements/l
nextcloud/apps/nextcloud_announcements/l10n/el.json
nextcloud/apps/nextcloud_announcements/l10n/en_GB.js
nextcloud/apps/nextcloud_announcements/l10n/en_GB.json
+nextcloud/apps/nextcloud_announcements/l10n/eo.js
+nextcloud/apps/nextcloud_announcements/l10n/eo.json
nextcloud/apps/nextcloud_announcements/l10n/es.js
nextcloud/apps/nextcloud_announcements/l10n/es.json
nextcloud/apps/nextcloud_announcements/l10n/es_419.js
@@ -11032,6 +11036,8 @@ nextcloud/apps/support/l10n/
nextcloud/apps/support/l10n/.gitkeep
nextcloud/apps/support/l10n/af.js
nextcloud/apps/support/l10n/af.json
+nextcloud/apps/support/l10n/bg.js
+nextcloud/apps/support/l10n/bg.json
nextcloud/apps/support/l10n/ca.js
nextcloud/apps/support/l10n/ca.json
nextcloud/apps/support/l10n/cs.js
@@ -12808,9 +12814,671 @@ nextcloud/core/css/variables.scss
nextcloud/core/css/whatsnew.scss
nextcloud/core/doc/
nextcloud/core/doc/admin/
+nextcloud/core/doc/admin/_images/
+nextcloud/core/doc/admin/_images/2-updates.png
+nextcloud/core/doc/admin/_images/2fa-admin-settings.png
+nextcloud/core/doc/admin/_images/2fa-app-install.png
+nextcloud/core/doc/admin/_images/add_storage.png
+nextcloud/core/doc/admin/_images/admin_filehandling-1.png
+nextcloud/core/doc/admin/_images/admin_filehandling-2.png
+nextcloud/core/doc/admin/_images/amazons3.png
+nextcloud/core/doc/admin/_images/antivirus-app.png
+nextcloud/core/doc/admin/_images/antivirus-config.png
+nextcloud/core/doc/admin/_images/antivirus-daemon-socket.png
+nextcloud/core/doc/admin/_images/antivirus-daemon.png
+nextcloud/core/doc/admin/_images/antivirus-executable.png
+nextcloud/core/doc/admin/_images/antivirus-logging.png
+nextcloud/core/doc/admin/_images/applicable.png
+nextcloud/core/doc/admin/_images/apps_overview.png
+nextcloud/core/doc/admin/_images/apps_store.png
+nextcloud/core/doc/admin/_images/auth_mechanism.png
+nextcloud/core/doc/admin/_images/auth_rsa.png
+nextcloud/core/doc/admin/_images/authentication-types.png
+nextcloud/core/doc/admin/_images/automated_tagging_sample_rule.png
+nextcloud/core/doc/admin/_images/code-integrity-admin.png
+nextcloud/core/doc/admin/_images/code-integrity-notification.png
+nextcloud/core/doc/admin/_images/create_public_share-10.png
+nextcloud/core/doc/admin/_images/create_public_share-6.png
+nextcloud/core/doc/admin/_images/create_public_share-8.png
+nextcloud/core/doc/admin/_images/create_public_share-9.png
+nextcloud/core/doc/admin/_images/dropbox-oc.png
+nextcloud/core/doc/admin/_images/enable-app.png
+nextcloud/core/doc/admin/_images/encryption1.png
+nextcloud/core/doc/admin/_images/encryption10.png
+nextcloud/core/doc/admin/_images/encryption12.png
+nextcloud/core/doc/admin/_image
Re: enigmail and thunderbird
On Wed, Feb 06, 2019 at 07:29:05PM +0100, Giovanni Bechis wrote:
> On 2/6/19 8:47 AM, Otto Moerbeek wrote:
> > Hi,
> >
> > on current enigmail does not seem to work well, if the passphrase in
> > gpg-agent is expired, it does not present a dialog to get it and
> > signing fails. If I seperately update the passpharse in gpg-agent via
> > a command line request enigmail is able to sign.
> >
> > Is this known? Any possible fix?
> >
> untested diff follows.
> Cheers
> Giovanni
>
It does not make any difference for me,
-Otto
> Index: Makefile
> ===
> RCS file: /var/cvs/ports/mail/enigmail/Makefile,v
> retrieving revision 1.45
> diff -u -p -r1.45 Makefile
> --- Makefile 5 Oct 2018 18:53:33 - 1.45
> +++ Makefile 6 Feb 2019 18:19:44 -
> @@ -5,7 +5,7 @@ ONLY_FOR_ARCHS = i386 amd64 powerpc spar
> COMMENT-main = GnuPG extension for Thunderbird
> COMMENT-seamonkey = GnuPG extension for Seamonkey
>
> -V = 2.0.8
> +V = 2.0.9
> DISTNAME = enigmail-${V}
> PKGNAME-main = ${PKGNAME}
> PKGNAME-seamonkey = enigmail-seamonkey-${V}
> Index: distinfo
> ===
> RCS file: /var/cvs/ports/mail/enigmail/distinfo,v
> retrieving revision 1.25
> diff -u -p -r1.25 distinfo
> --- distinfo 5 Oct 2018 18:53:33 - 1.25
> +++ distinfo 6 Feb 2019 18:19:50 -
> @@ -1,2 +1,2 @@
> -SHA256 (enigmail-2.0.8.tar.gz) = 9sTwVcf9r0NHOe+Ae5qLHSpEihGCIRPVGIPQUmLRUtc=
> -SIZE (enigmail-2.0.8.tar.gz) = 2525691
> +SHA256 (enigmail-2.0.9.tar.gz) = +gMJwHCJgqSUI5fpF7h/dUJWip/vZL2vUD8NAPqsmlE=
> +SIZE (enigmail-2.0.9.tar.gz) = 2541100
> Index: patches/patch-Makefile
> ===
> RCS file: /var/cvs/ports/mail/enigmail/patches/patch-Makefile,v
> retrieving revision 1.1
> diff -u -p -r1.1 patch-Makefile
> --- patches/patch-Makefile4 Sep 2016 14:58:59 - 1.1
> +++ patches/patch-Makefile6 Feb 2019 18:23:30 -
> @@ -1,7 +1,17 @@
> $OpenBSD: patch-Makefile,v 1.1 2016/09/04 14:58:59 giovanni Exp $
> Makefile.origFri Jun 10 15:08:01 2016
> -+++ Makefile Fri Jun 10 15:08:34 2016
> -@@ -33,7 +33,7 @@ xpi:
> +Index: Makefile
> +--- Makefile.orig
> Makefile
> +@@ -3,7 +3,7 @@
> + # file, You can obtain one at https://mozilla.org/MPL/2.0/.
> +
> + XPI_MODULE = enigmail
> +-XPI_MODULE_VERS = 2.0.8
> ++XPI_MODULE_VERS = 2.0.9
> +
> + DEPTH = .
> +
> +@@ -32,7 +32,7 @@ xpi: $(DIRS)
> $(srcdir)/util/genxpi $(XPIFILE) $(XPI_MODULE_VERS) $(DIST) $(srcdir)
> $(XPI_MODULE) $(ENABLE_LANG)
>
> check:
portcheck: improve checking of DESCR and PLIST/PFRAG
Hi ports,
During an out-of-band discussion with afresh1@, he told me that he found
out that portcheck can't find a missing pkg/DESCR.
With the current portcheck, if a PLIST is present then DESCR detection
is not really done (and the opposite is true), because they share the
same variable to assert their presence.
As a result, i'm proposing a diff that splits PLIST/PFRAG and DESCR
detection, and adds similar support for subpackages as well.
It has been tested by torturing x11/qt4 and x11/dwm, but there may be
corner cases in the ports tree that my changes don't cover.
Comments and feedback are welcome!
Charlène.
Index: portcheck
===
RCS file: /cvs/ports/infrastructure/bin/portcheck,v
retrieving revision 1.126
diff -u -p -r1.126 portcheck
--- portcheck 16 Nov 2018 10:08:38 - 1.126
+++ portcheck 7 Feb 2019 12:25:40 -
@@ -831,6 +831,15 @@ sub_checks() {
local dir=$1; shift
local subpkg=$1; shift
local flavor
+ local pkgitem
+
+ # DESCR/PLIST existence for ports without FLAVOR/SUBPACKAGE is tested
+ # in check_pkg_dir() already.
+ for pkgitem in DESCR PLIST; do
+ [[ $subpkg != "-" && ! -f "pkg/$pkgitem$subpkg" ]] &&
+ err "$pkgitem$subpkg missing in pkg (or not a file)"
+ done
+
for flavor in "$@"; do
# avoid extra noise
[[ ${flavor#no_} != ${flavor} &&
@@ -1636,7 +1645,8 @@ check_pkg_dir() {
subst_cmd=$1
shift
fi
- local empty=true
+ local empty_descr=true
+ local empty_plist=true
local F
local plist
@@ -1645,7 +1655,7 @@ check_pkg_dir() {
dir="${dir#./}"
for F in "$dir"/* "$dir"/.*; do case "${F##*/}" in
DESCR?(-*))
- empty=false
+ empty_descr=false
[[ -f $F ]] ||
err "$F is not a file"
check_trailing_whitespace "$F"
@@ -1658,7 +1668,7 @@ check_pkg_dir() {
;;
PFRAG.shared?(-*))
- empty=false
+ empty_plist=false
[[ -n $subst_cmd ]] && check_subst_vars "$F" "$subst_cmd"
check_plist_file "$F"
plist=PLIST${F##*/PFRAG.+([!-])}
@@ -1666,7 +1676,7 @@ check_pkg_dir() {
;;
PFRAG.*|PLIST?(-*))
- empty=false
+ empty_plist=false
[[ -n $subst_cmd ]] && check_subst_vars "$F" "$subst_cmd"
check_plist_file "$F"
;;
@@ -1714,8 +1724,10 @@ check_pkg_dir() {
handle_extra_file "$F"
;;
esac; done
-
- $empty && err "$dir directory does not contain either DESCR, PFRAG or
PLIST files"
+
+ [[ "$empty_descr" = true ]] && err "$dir does not contain a DESCR file"
+ [[ "$empty_plist" = true ]] && err "$dir does not contain PFRAG or
PLIST files"
+
}
# Checks made:
Re: texlive & evince
On Mon, Feb 04 2019, Edd Barrett wrote:
> Hi,
>
> On Sat, Feb 02, 2019 at 12:25:55AM +0100, Matthias Kilian wrote:
>> > - In tex live, put synctex into its own subpackage and LIB_DEPEND it.
>> > - In tex live, move synctex into -mktexlsr. Evince already LIB_DEPENDS
>> > this.
>> > - Patch evince to always use its internal copy.
>> >
>> > FWIW, I'm leaning towards the first option.
>>
>> First or third.
>
> Alright, so here's a diff which makes the new -syntex subpackage in
> texlive and another which adjusts evince to use it. See attached.
>
> I've tested `pkg_add -u` and all seems well. It seems the inequality
> conflict constraint is essential, otherwise `pkg_add -u` isn't smart
> enough to avoid collisions. Please check my work carefully.
> Index: pkg/PLIST-synctex
> ===
> RCS file: pkg/PLIST-synctex
> diff -N pkg/PLIST-synctex
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ pkg/PLIST-synctex 4 Feb 2019 17:39:55 -
> @@ -0,0 +1,15 @@
> +@comment $OpenBSD$
> +@conflict teTeX_base-*
> +@conflict pdfjam-*
> +@conflict ht-<2
> +@conflict texlive_texmf-buildset-<2018
> +@conflict texlive_base-<2018p1
The last line looks fine but I doubt that you need to copy the other
@conflict lines. Were the -synctex files once provided by one of those
packages?
Note that you can't just put this in, you also need to bump some
RUN_DEPENDS (and thus REVISION) in texlive/texmf/Makefile, else
pkg_create will complain:
--8<--
===> Building package for texlive_texmf-docs-2018p0
Create /usr/ports/packages/amd64/no-arch/texlive_texmf-docs-2018p0.tgz
Creating package texlive_texmf-docs-2018p0
checking dependencies|print/texlive/base,-main
Error: Dependency texlive_base-2018p0 doesn't match FULLPKGNAME:
texlive_base-2018p1
checksumming...
Error: @depend print/texlive/base,-main:texlive_base-2018p0:texlive_base-2018p1
pattern texlive_base-2018p0 doesn't match default texlive_base-2018p1
Fatal error: can't continue
at /usr/libdata/perl5/OpenBSD/PkgCreate.pm line 1675.
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2027
'/usr/ports/packages/amd64/no-arch/texlive_texmf-docs-2018p0.tgz')
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2488
'_internal-package')
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2467 'package')
*** Error 1 in /usr/ports/print/texlive/texmf
(/usr/ports/infrastructure/mk/bsd.port.mk:3459 'repackage')
-->8--
As already discussed, I don't understand how it helps for those depends
to be that strict. Aren't files more commonly moved between
texlive/texmf subpackages, rather than from texlive/base to
texlive/texmf? Unless I'm missing something, we may easily avoid the
problem by only stating minimal versions: less chances for errors and less
churn for pkg_add -u. Please find a diff below.
> As far as I can see, you cannot build evince without synctex, so even
> the light flavor has to pull in synctex.
Well, as mentioned by kili there's also the option to force evince to
always use its internal copy. This means one more copy of synctex to
watch for security/portability issues, but on the other hand this would
decouple evince and texlive updates. Not a bad idea given the recent,
undocumented API/ABI break in libsynctex...
https://github.com/jlaurens/synctex/issues/23
Thoughts / ok?
Index: Makefile
===
RCS file: /cvs/ports/print/texlive/texmf/Makefile,v
retrieving revision 1.56
diff -u -p -r1.56 Makefile
--- Makefile24 Jan 2019 16:38:41 - 1.56
+++ Makefile5 Feb 2019 03:04:38 -
@@ -24,8 +24,9 @@ PKGNAME-docs =texlive_texmf-docs-${V}
PKGNAME-context = texlive_texmf-context-${V}
PKGNAME-buildset = texlive_texmf-buildset-${V}
-REVISION-main =0
-REVISION-docs =0
+REVISION-main =1
+REVISION-docs =1
+REVISION-buildset =0
NO_BUILD = Yes
NO_TEST = Yes
@@ -42,16 +43,16 @@ MODRUBY_RUNDEP =No
MODPY_BUILDDEP = No
MODPY_RUNDEP = No
-RUN_DEPENDS-main +=texlive_base-${V}p0:print/texlive/base,-main \
+RUN_DEPENDS-main +=texlive_base->=${V}p0:print/texlive/base,-main \
${FULLPKGNAME-buildset}:print/texlive/texmf,-buildset
RUN_DEPENDS-full = ${FULLPKGNAME-main}:print/texlive/texmf,-main \
${MODPY_RUN_DEPENDS} \
${_MODLUA_RUNDEPENDS}
RUN_DEPENDS-context += ${FULLPKGNAME-full}:print/texlive/texmf,-full \
${MODRUBY_RUNDEPENDS}
-RUN_DEPENDS-docs +=texlive_base-${V}p0:print/texlive/base,-main \
+RUN_DEPENDS-docs +=texlive_base->=${V}p0:print/texlive/base,-main \
x11/p5-Tk
-RUN_DEPENDS-buildset +=
texlive_mktexlsr-${V}:print/texlive/base,-mktexlsr
+RUN_DEPENDS-buildset +=
texlive_mktexlsr->=${V}:print/texlive/base,-mktexlsr
[NEW] converters/bdf2psf
Hi ports@, Here is a new port: converters/bdf2psf. >From DESCR: The program bdf2psf translates BDF fonts to PSF format. It accepts fonts with arbitrary size of the font matrix. If the width of the glyph matrix of the source font is 7 or 9 pixels then it generates fonts with width of 8 pixels. Comments? OK? bdf2psf.tar.gz Description: application/tar-gz
llvm-7.0.1 fallout: lang/crystal
Hi, I'm not sure you were notified so here's a heads-up: lang/crystal doesn't build any more after the update to clang 7 in both base and ports. build log (with unprintable characters suppressed): --8<-- ===> Cleaning for crystal-0.26.1p1 ===> crystal-0.26.1p1 depends on: llvm-=7.0.1 -> llvm-7.0.1p3 ===> crystal-0.26.1p1 depends on: llvm->=7.0.1 -> llvm-7.0.1p3 ===> crystal-0.26.1p1 depends on: gmake-* -> gmake-4.2.1p0 ===> crystal-0.26.1p1 depends on: libiconv-* -> libiconv-1.14p3 ===> crystal-0.26.1p1 depends on: boehm-gc-* -> boehm-gc-7.6.0p2 ===> crystal-0.26.1p1 depends on: libevent-* -> libevent-2.0.22p1 ===> crystal-0.26.1p1 depends on: pcre-* -> pcre-8.41p2 ===> crystal-0.26.1p1 depends on: libyaml-* -> libyaml-0.1.7 ===> Verifying specs: c++ c++abi pthread c event_core event_extra gc iconv m pcre yaml c++ c++abi pthread ===> found c++.2.1 c++abi.0.1 pthread.26.1 c.95.0 event_core.1.1 event_extra.0.1 gc.4.0 iconv.6.0 m.10.1 pcre.3.0 yaml.0.0 ===> Checking files for crystal-0.26.1p1 `/usr/ports/distfiles/crystal-0.26.1.tar.gz' is up to date. `/usr/ports/distfiles/crystal-0.26.1-OpenBSD6.4.tar.gz' is up to date. `/usr/ports/distfiles/shards-0.26.1.tar.gz' is up to date. >> (SHA256) crystal-0.26.1.tar.gz: OK >> (SHA256) crystal-0.26.1-OpenBSD6.4.tar.gz: OK >> (SHA256) shards-0.26.1.tar.gz: OK ===> Extracting for crystal-0.26.1p1 ===> Patching for crystal-0.26.1p1 ===> Compiler link: gcc -> /usr/local/bin/clang ===> Compiler link: cc -> /usr/local/bin/clang ===> Compiler link: clang -> /usr/local/bin/clang ===> Compiler link: g++ -> /usr/local/bin/clang++ ===> Compiler link: c++ -> /usr/local/bin/clang++ ===> Compiler link: clang++ -> /usr/local/bin/clang++ ===> Generating configure for crystal-0.26.1p1 ===> Configuring for crystal-0.26.1p1 ===> Building for crystal-0.26.1p1 mkdir -p /usr/ports/pobj/crystal-0.26.1/crystal-0.26.1/.build # Link the compiler from the pre-built bootstrap object cd /usr/ports/pobj/crystal-0.26.1/crystal-0.26.1 && CXX=c++ gmake llvm_ext libcrystal [33mUsing /usr/local/bin/llvm-config [version=7.0.1][0m c++ -c -o src/llvm/ext/llvm_ext.o src/llvm/ext/llvm_ext.cc -I/usr/local/include -O2 -pipe -fno-ret-protector -mno-retpoline -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections -DNDEBUG -fno-exceptions -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS [1msrc/llvm/ext/llvm_ext.cc:89:17: [0m[0;1;31merror: [0m[1mconflicting types for 'LLVMDIBuilderCreateFunction'[0m LLVMMetadataRef LLVMDIBuilderCreateFunction( [0;1;32m^ [0m[1m/usr/local/include/llvm-c/DebugInfo.h:277:17: [0m[0;1;30mnote: [0mprevious declaration is here[0m LLVMMetadataRef LLVMDIBuilderCreateFunction( [0;1;32m^ [0m[1msrc/llvm/ext/llvm_ext.cc:109:17: [0m[0;1;31merror: [0m[1mconflicting types for 'LLVMDIBuilderCreateLexicalBlock'[0m LLVMMetadataRef LLVMDIBuilderCreateLexicalBlock(DIBuilderRef Dref, [0;1;32m^ [0m[1m/usr/local/include/llvm-c/DebugInfo.h:292:17: [0m[0;1;30mnote: [0mprevious declaration is here[0m LLVMMetadataRef LLVMDIBuilderCreateLexicalBlock( [0;1;32m^ [0m[1msrc/llvm/ext/llvm_ext.cc:118:17: [0m[0;1;31merror: [0m[1mconflicting types for 'LLVMDIBuilderCreateBasicType'[0m LLVMMetadataRef LLVMDIBuilderCreateBasicType(DIBuilderRef Dref, [0;1;32m^ [0m[1m/usr/local/include/llvm-c/DebugInfo.h:536:1: [0m[0;1;30mnote: [0mprevious declaration is here[0m LLVMDIBuilderCreateBasicType(LLVMDIBuilderRef Builder, const char *Name, [0;1;32m^ [0m[1msrc/llvm/ext/llvm_ext.cc:130:17: [0m[0;1;31merror: [0m[1mconflicting types for 'LLVMDIBuilderGetOrCreateTypeArray'[0m LLVMMetadataRef LLVMDIBuilderGetOrCreateTypeArray(DIBuilderRef Dref, [0;1;32m^ [0m[1m/usr/local/include/llvm-c/DebugInfo.h:420:17: [0m[0;1;30mnote: [0mprevious declaration is here[0m LLVMMetadataRef LLVMDIBuilderGetOrCreateTypeArray(LLVMDIBuilderRef Builder, [0;1;32m^ [0m[1msrc/llvm/ext/llvm_ext.cc:139:17: [0m[0;1;31merror: [0m[1mconflicting types for 'LLVMDIBuilderGetOrCreateArray'[0m LLVMMetadataRef LLVMDIBuilderGetOrCreateArray(DIBuilderRef Dref, [0;1;32m^ [0m[1m/usr/local/include/llvm-c/DebugInfo.h:929:17: [0m[0;1;30mnote: [0mprevious declaration is here[0m LLVMMetadataRef LLVMDIBuilderGetOrCreateArray(LLVMDIBuilderRef Builder, [0;1;32m^ [0m[1msrc/llvm/ext/llvm_ext.cc:148:1: [0m[0;1;31merror: [0m[1mconflicting types for 'LLVMDIBuilderCreateSubroutineType'[0m LLVMDIBuilderCreateSubroutineType(DIBuilderRef Dref, LLVMMetadataRef File, [0;1;32m^ [0m[1m/usr/local/include/llvm-c/DebugInfo.h:435:1: [0m[0;1;30mnote: [0mprevious declaration is here[0m LLV
Re: llvm-7.0.1 fallout: lang/crystal
On 2019/02/07 18:02, Jeremie Courreges-Anglas wrote: > > Hi, > > I'm not sure you were notified so here's a heads-up: lang/crystal > doesn't build any more after the update to clang 7 in both base and > ports. Not handled upstream yet. https://github.com/crystal-lang/crystal/issues/6754
Re: update sysutils/reed-alert
On Thu, Jan 31, 2019 at 08:03:51AM +0100, Solene Rapenne wrote:
> On Wed, Jan 16, 2019 at 03:22:41PM +0100, Solene Rapenne wrote:
> > Hi
> >
> > upgrade to reed-alert 1.04, the release adds a :reminder parameter for each
> > check if you want to be notified again every n runs when a check is in a
> > failure state.
> >
> > Index: Makefile
> > ===
> > RCS file: /data/cvs/ports/sysutils/reed-alert/Makefile,v
> > retrieving revision 1.1.1.1
> > diff -u -p -r1.1.1.1 Makefile
> > --- Makefile31 Oct 2018 11:19:08 - 1.1.1.1
> > +++ Makefile16 Jan 2019 14:06:41 -
> > @@ -1,7 +1,7 @@
> > # $OpenBSD: Makefile,v 1.1.1.1 2018/10/31 11:19:08 solene Exp $
> >
> > COMMENT = system monitoring and alert notifier
> > -DISTNAME = reed-alert-v1.03
> > +DISTNAME = reed-alert-v1.04
> > PKGNAME = ${DISTNAME:S/-v/-/}
> > EXTRACT_SUFX = .tgz
> > CATEGORIES = sysutils
> > Index: distinfo
> > ===
> > RCS file: /data/cvs/ports/sysutils/reed-alert/distinfo,v
> > retrieving revision 1.1.1.1
> > diff -u -p -r1.1.1.1 distinfo
> > --- distinfo31 Oct 2018 11:19:08 - 1.1.1.1
> > +++ distinfo16 Jan 2019 14:06:44 -
> > @@ -1,2 +1,2 @@
> > -SHA256 (reed-alert-v1.03.tgz) =
> > P0pu38BUVqb1KxARFfGzWv4L3XHzVq9icbaCexwCpZY=
> > -SIZE (reed-alert-v1.03.tgz) = 11179
> > +SHA256 (reed-alert-v1.04.tgz) =
> > 8GbMdtGW/+XELq2/MDAF5vOnoQfskUtWO8hapG2fDL0=
> > +SIZE (reed-alert-v1.04.tgz) = 11616
> >
>
> ping
>
pong ?
I'm the author of this software, there are little changes and it works
on my production servers.
remove atf-allwinner and u-boot-pinebook
After the recent updates to u-boot and arm-trusted-firmware, we no
longer need u-boot-pinebook or atf-allwinner. Any patches they have,
have already been upstreamed and the new packages now work better than
the old ones.
This adds pkgpath's and quirks entries. Not included is the cvs rm for
sysutils/atf-allwinner and sysutils/u-boot-pinebook.
OK?
Index: sysutils/arm-trusted-firmware/Makefile
===
RCS file: /cvs/openbsd/ports/sysutils/arm-trusted-firmware/Makefile,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 Makefile
--- sysutils/arm-trusted-firmware/Makefile 7 Feb 2019 07:23:50 -
1.8
+++ sysutils/arm-trusted-firmware/Makefile 7 Feb 2019 18:20:54 -
@@ -9,6 +9,8 @@ GH_PROJECT= arm-trusted-firmware
GH_COMMIT= 7d3884000d671ece18788791de875229f983f079
DISTNAME= arm-trusted-firmware-2.1beta0
+REVISION= 0
+
CATEGORIES=sysutils
# BSD
Index: sysutils/arm-trusted-firmware/pkg/PLIST
===
RCS file: /cvs/openbsd/ports/sysutils/arm-trusted-firmware/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 PLIST
--- sysutils/arm-trusted-firmware/pkg/PLIST 21 Oct 2018 00:13:54 -
1.2
+++ sysutils/arm-trusted-firmware/pkg/PLIST 7 Feb 2019 18:16:34 -
@@ -1,4 +1,5 @@
@comment $OpenBSD: PLIST,v 1.2 2018/10/21 00:13:54 jsg Exp $
+@pkgpath sysutils/atf-allwinner
share/arm-trusted-firmware/
share/arm-trusted-firmware/rk3399-bl31.elf
share/arm-trusted-firmware/sun50i_a64-bl31.bin
Index: sysutils/u-boot/Makefile
===
RCS file: /cvs/openbsd/ports/sysutils/u-boot/Makefile,v
retrieving revision 1.50
diff -u -p -u -p -r1.50 Makefile
--- sysutils/u-boot/Makefile7 Feb 2019 07:29:04 - 1.50
+++ sysutils/u-boot/Makefile7 Feb 2019 19:01:56 -
@@ -7,7 +7,7 @@ FLAVOR?=arm
COMMENT= U-Boot firmware
VERSION= 2019.01
-REVISION= 3
+REVISION= 4
DISTNAME= u-boot-${VERSION}
PKGNAME= u-boot-${FLAVOR}-${VERSION:S/-//}
FULLPKGNAME= ${PKGNAME}
Index: sysutils/u-boot/pkg/PFRAG.aarch64
===
RCS file: /cvs/openbsd/ports/sysutils/u-boot/pkg/PFRAG.aarch64,v
retrieving revision 1.9
diff -u -p -u -p -r1.9 PFRAG.aarch64
--- sysutils/u-boot/pkg/PFRAG.aarch64 17 Jan 2019 20:41:47 - 1.9
+++ sysutils/u-boot/pkg/PFRAG.aarch64 7 Feb 2019 18:16:58 -
@@ -1,4 +1,5 @@
@comment $OpenBSD: PFRAG.aarch64,v 1.9 2019/01/17 20:41:47 kettenis Exp $
+@pkgpath sysutils/u-boot-pinebook
share/u-boot/
share/u-boot/a64-olinuxino/
share/u-boot/a64-olinuxino/sunxi-spl.bin
Index: devel/quirks/Makefile
===
RCS file: /cvs/openbsd/ports/devel/quirks/Makefile,v
retrieving revision 1.698
diff -u -p -u -p -r1.698 Makefile
--- devel/quirks/Makefile 6 Feb 2019 18:22:15 - 1.698
+++ devel/quirks/Makefile 7 Feb 2019 19:02:29 -
@@ -5,7 +5,7 @@ CATEGORIES =devel databases
DISTFILES =
# API.rev
-PKGNAME = quirks-3.91
+PKGNAME = quirks-3.92
PKG_ARCH = *
MAINTAINER = Marc Espie
Index: devel/quirks/files/Quirks.pm
===
RCS file: /cvs/openbsd/ports/devel/quirks/files/Quirks.pm,v
retrieving revision 1.712
diff -u -p -u -p -r1.712 Quirks.pm
--- devel/quirks/files/Quirks.pm6 Feb 2019 18:22:15 - 1.712
+++ devel/quirks/files/Quirks.pm7 Feb 2019 18:18:09 -
@@ -318,6 +318,8 @@ my $stem_extensions = {
'zh-bg5ps' => 'bg5ps',
'zh-bg5pdf' => 'bg5pdf',
'wxWidgets-gtk2' => 'wxWidgets-gtk3',
+ 'atf-allwinner' => 'arm-trusted-firmware',
+ 'u-boot-pinebook' => 'u-boot-aarch64',
};
my $obsolete_reason = {
--
If I had any humility I would be perfect.
-- Ted Turner
Re: [UPDATE] net/prosody to 0.11.1
On Wed, 6 Feb 2019 11:21:00 +0100, Henrik Friedrichsen wrote: > On Sun, Jan 27, 2019 at 11:21:53AM +0100, Henrik Friedrichsen wrote: > > And another small update to 0.11.2: > > Final ping. It'd be nice to have this in before the 6.6 freeze. > Sorry for the delay. I committed your diff, thanks! Daniel
[UPDATE] devel/p5-MooseX-Types-Common 0.001002 -> 0.001014
Here is an update for MooseX::Types::Common. There are 9 years of changelog to read [1] but no backward incompatible change. What's new in the port: - Use Module::Build::Tiny now - *_DEPENDS overhaul Testing: - 'make test' passes - There are 65 consumers that i've tested [2]. I've met no new issue due to that update. Comments/feedback are welcome! Charlène. [1] https://metacpan.org/source/ETHER/MooseX-Types-Common-0.001014/Changes [2] https://transfer.sh/10gshc/p5-MooseX-Types-Common.tgz Index: Makefile === RCS file: /cvs/ports/devel/p5-MooseX-Types-Common/Makefile,v retrieving revision 1.7 diff -u -p -u -p -r1.7 Makefile --- Makefile20 Mar 2016 19:56:30 - 1.7 +++ Makefile7 Feb 2019 20:25:46 - @@ -4,8 +4,7 @@ COMMENT=library of commonly used type MODULES= cpan PKG_ARCH= * -DISTNAME= MooseX-Types-Common-0.001002 -REVISION= 0 +DISTNAME= MooseX-Types-Common-0.001014 CATEGORIES=devel MAINTAINER=Jim Razmus II @@ -13,9 +12,10 @@ MAINTAINER= Jim Razmus II Index: distinfo === RCS file: /cvs/ports/devel/p5-MooseX-Types-Common/distinfo,v retrieving revision 1.2 diff -u -p -u -p -r1.2 distinfo --- distinfo18 Jan 2015 03:13:31 - 1.2 +++ distinfo7 Feb 2019 20:25:46 - @@ -1,2 +1,2 @@ -SHA256 (MooseX-Types-Common-0.001002.tar.gz) = eXaBQP4jt0APGHyR3JBPSK4ghv7Spe7ae3is+YqgrVU= -SIZE (MooseX-Types-Common-0.001002.tar.gz) = 16897 +SHA256 (MooseX-Types-Common-0.001014.tar.gz) = 75Nxi20vJA1QtcOssadLTCoZGGllFHAAGoK+HzXQ7w8= +SIZE (MooseX-Types-Common-0.001014.tar.gz) = 32971
Re: Update: py-slixmpp 1.4.1 -> 1.4.2
On Sun, 3 Feb 2019 20:04:00 -0500, Kurt Mosiejczuk wrote: > Another small point release. It was a very straightforward update and > all tests passed. Isn't there a new plugin for xep 0335? Cheers, Daniel
Re: remove atf-allwinner and u-boot-pinebook
On 2019/02/07 20:04, Peter Hessler wrote:
> After the recent updates to u-boot and arm-trusted-firmware, we no
> longer need u-boot-pinebook or atf-allwinner. Any patches they have,
> have already been upstreamed and the new packages now work better than
> the old ones.
>
> This adds pkgpath's and quirks entries. Not included is the cvs rm for
> sysutils/atf-allwinner and sysutils/u-boot-pinebook.
>
> OK?
>
>
> Index: sysutils/arm-trusted-firmware/Makefile
> ===
> RCS file: /cvs/openbsd/ports/sysutils/arm-trusted-firmware/Makefile,v
> retrieving revision 1.8
> diff -u -p -u -p -r1.8 Makefile
> --- sysutils/arm-trusted-firmware/Makefile7 Feb 2019 07:23:50 -
> 1.8
> +++ sysutils/arm-trusted-firmware/Makefile7 Feb 2019 18:20:54 -
> @@ -9,6 +9,8 @@ GH_PROJECT= arm-trusted-firmware
> GH_COMMIT= 7d3884000d671ece18788791de875229f983f079
> DISTNAME=arm-trusted-firmware-2.1beta0
>
> +REVISION=0
> +
This needs EPOCH=0 in order that the atf-allwinner -> arm-trusted-firmware
update path will work. With a quirks "sidegrade", version numbers are still
compared, and 2.1beta0p0 is "lower" than atf-allwinner-20180403.
> COMMENT= U-Boot firmware
> VERSION= 2019.01
> -REVISION=3
> +REVISION=4
> DISTNAME=u-boot-${VERSION}
This is OK because the u-boot-aarch64 version number is already "higher"
than the u-boot-pinebook version (0.0.20181109).
The rest is all good.
Re: WIP: mail/postsrsd
On 2019/01/04 16:32, Giovanni Bechis wrote:
> On 7/27/18 12:09 PM, Stuart Henderson wrote:
> > On 2018/07/27 10:15, Giovanni Bechis wrote:
> >> Hi,
> >> attached a port of postsrsd, an srs forwarding daemon for postfix.
> >> A couple of doubts:
> >> - It uses a secret file created at build time with "dd if=/dev/urandom
> >> bs=18 count=1 | /usr/bin/openssl base64 -e",
> >> should we add a README on how to create it ?
> >
> > If it needs something that isn't clear from the upstream documentation,
> > then adding it to a pkg-readme makes sense. (Not quite sure why they use
> > dd | openssl rather than just openssl rand -base64 18 though!)
> >
> >> - the Linux startup script uses something like that:
> >> ---
> >> SRS_DOMAIN=`postconf -h mydomain || true`
> >> daemon $DAEMON -d "$SRS_DOMAIN"
> >> ---
> >>
> >> Does it make sense to write a similar rc script or is it better to let the
> >> user configure it by hand and add it to rc.local ?
> >
> > That seems like too much magic to me, setting postsrsd_flags in
> > rc.conf.local
> > by hand seems a better idea. That's something that would definitely fit for
> > a pkg-readme.
> >
> > The rc script is missing from your tar.
> >
>
> new diff after a lot of time.
> comments ? ok ?
> Cheers
> Giovanni
> Index: user.list
> ===
> RCS file: /var/cvs/ports/infrastructure/db/user.list,v
> retrieving revision 1.336
> diff -u -p -r1.336 user.list
> --- user.list 29 Dec 2018 14:29:54 - 1.336
> +++ user.list 4 Jan 2019 14:15:12 -
> @@ -339,3 +339,4 @@ id user group port options
> 828 _ossecm security/ossec-hids
> 829 _ossecr security/ossec-hids
> 830 _pdns_recursor _pdns_recursor net/powerdns_recursor
> +831 _postsrsd_postsrsd mail/postsrsd
Sorry for the slow reply. A couple of quick comments, otherwise OK:
- trailing whitespace in COMMENT
- typo in README, s/postrsd/postsrsd/ in "Enable postrsd"
- I wondered about lib/postsrsd, I see it is just used as a chroot
directory. It maybe better to put it under /var as the filesystem
flags are usually a bit safer in /var and this would make it more
obvious what the empty dir is used for.
So I would add this to CONFIGURE_ARGS:
-DCHROOT_DIR=${LOCALSTATEDIR}/postsrsd
and change lib/postsrsd/ in PLIST to @sample ${LOCALSTATEDIR}/postsrsd/
Re: UPDATE: xschem 2.8.1 -> 2.8.2
to 7. helmik. 2019 klo 0.30 Klemens Nanni (k...@openbsd.org) kirjoitti:
>> On Wed, Feb 06, 2019 at 09:00:41PM +0200, Hannu Vuolasaho wrote:
> > I also noticed the move of the examples and pcb,
> > So they shouldn't
> > be cluttering system library.
> Nonetheless there is a clear seperation between documentation and
> example (configuration). All ports install them into the appropiate
> locations and I see no reason here to make an exception for xschem.
You are quite correct. After re-reading porter's guide, I also think that
examples belong to examples directory.
Below diff which patches them to examples.
Best regards,
Hannu Vuolasaho
Index: Makefile
===
RCS file: /cvs/ports/cad/xschem/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile4 Jan 2019 20:35:47 -1.1.1.1
+++ Makefile7 Feb 2019 22:18:20 -
@@ -2,7 +2,7 @@
COMMENT =hierarchical schematic capture program
-DISTNAME =xschem-2.8.1
+DISTNAME =xschem-2.8.2
CATEGORIES =cad
@@ -41,6 +41,5 @@ NO_TEST =Yes
pre-configure:
${MODTCL_WISH_ADJ} ${WRKSRC}/src/xschem.tcl ${WRKSRC}/utile/utile.tcl
-${SUBST_CMD} ${WRKSRC}/doc/manpages/xschem.1
.include
Index: distinfo
===
RCS file: /cvs/ports/cad/xschem/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo4 Jan 2019 20:35:47 -1.1.1.1
+++ distinfo7 Feb 2019 22:18:20 -
@@ -1,2 +1,2 @@
-SHA256 (xschem-2.8.1.tar.gz) = ojF15ukLA0JZWEOnFRAHe2ZgQFD2jRwWQiiXQ5mJUzY=
-SIZE (xschem-2.8.1.tar.gz) = 2411252
+SHA256 (xschem-2.8.2.tar.gz) = NDcxy6DUgzJorKPgzq3pmeO0uVDs4MeLWUIomgbSCgI=
+SIZE (xschem-2.8.2.tar.gz) = 3741517
Index: patches/patch-Makefile_conf_in
===
RCS file: patches/patch-Makefile_conf_in
diff -N patches/patch-Makefile_conf_in
--- /dev/null1 Jan 1970 00:00:00 -
+++ patches/patch-Makefile_conf_in7 Feb 2019 22:18:20 -
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+Right place for examples
+
+Index: Makefile.conf.in
+--- Makefile.conf.in.orig
Makefile.conf.in
+@@ -41,6 +41,8 @@ LDFLAGS=@/local/xschem/ldflags@
+ BINDIR=$(DESTDIR)$(install_root)$(PREFIX)/bin
+ SHAREDIR=$(DESTDIR)$(install_root)$(PREFIX)/share
+ DOCDIR=$(DESTDIR)$(install_root)$(PREFIX)/share/doc
++EXAMPLESDIR=$(SHAREDIR)/examples
++XEXAMPLESDIR=$(EXAMPLESDIR)/xschem
+ XSHAREDIR=$(SHAREDIR)/xschem
+ XDOCDIR=$(DOCDIR)/xschem
+ MANDIR=$(SHAREDIR)/man
Index: patches/patch-doc_manpages_xschem_1
===
RCS file: patches/patch-doc_manpages_xschem_1
diff -N patches/patch-doc_manpages_xschem_1
--- patches/patch-doc_manpages_xschem_14 Jan 2019 20:35:47 -1.1.1.1
+++ /dev/null1 Jan 1970 00:00:00 -
@@ -1,28 +0,0 @@
-$OpenBSD: patch-doc_manpages_xschem_1,v 1.1.1.1 2019/01/04 20:35:47 kn Exp $
-
-Index: doc/manpages/xschem.1
doc/manpages/xschem.1.orig
-+++ doc/manpages/xschem.1
-@@ -117,7 +117,7 @@ sets TCL frontend debug
-
- .TP
-
--.B $PREFIX/share/xschem/xschemrc
-+.B ${PREFIX}/share/xschem/xschemrc
- default configuration
- .TP
-
-@@ -134,11 +134,11 @@ settings not overridden will remain as set from the sy
- or user config
- .TP
-
--.B $PREFIX/share/xschem/systemlib
-+.B ${PREFIX}/share/xschem/systemlib
- builtin essentials, such as font and missing symbol graphics
- .TP
-
--.B $PREFIX/share/xschem/utile
-+.B ${PREFIX}/share/xschem/utile
- TODO
- .TP
-
Index: patches/patch-src_xinit_c
===
RCS file: patches/patch-src_xinit_c
diff -N patches/patch-src_xinit_c
--- patches/patch-src_xinit_c4 Jan 2019 20:35:47 -1.1.1.1
+++ /dev/null1 Jan 1970 00:00:00 -
@@ -1,16 +0,0 @@
-$OpenBSD: patch-src_xinit_c,v 1.1.1.1 2019/01/04 20:35:47 kn Exp $
-
-Fix stylistical compiler warnings
-
-Index: src/xinit.c
src/xinit.c.orig
-+++ src/xinit.c
-@@ -686,7 +686,7 @@ int source_tcl_file(char *s)
- char tmp[1024];
- if(Tcl_EvalFile(interp, s)==TCL_ERROR) {
- fprintf(errfp, "Tcl_AppInit() error: can not execute %s, please
fix:\n", s);
--fprintf(errfp, Tcl_GetStringResult(interp));
-+fprintf(errfp, "%s", Tcl_GetStringResult(interp));
- fprintf(errfp, "\n");
- my_snprintf(tmp, S(tmp), "tk_messageBox -icon error -type ok -message \
-{Tcl_AppInit() err 1: can not execute %s, please fix:\n %s}",
Index: patches/patch-xschem_library_Makefile
===
RCS file: /cvs/ports/cad/xschem/patches/patch-xschem_library_Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 patch-xschem_library_Makefile
--- patches/patch-xschem_library_Makefile4 Jan 2019 20:35:47 -
1.1.1.1
+++ patches/patch-xschem_library_Makefile7 Feb 2019 22:18:20 -
@@ -1,22 +1,30 @@
$OpenBSD: patch-x
Re: UPDATE: Nextcloud-15.0.4
Gonzalo L. Rodriguez writes: > Hello, > > Update for Nextcloud to 15.0.4: > > https://nextcloud.com/changelog/ > > OK? Comments? Upgrade went fine here, OK abieber@ > > Cheers.- -- PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE
Re: UPDATE: x265 3.0
On 1/27/2019 1:23 PM, Brad Smith wrote: Here is an update to x265 3.0. ping.
go uses too many CPUs
Go tries to use NCPU cpus. Unfortunately, half of them are turned off because
hw.smt=0 by default, and then go spends a lot of time fighting against itself.
The diff below, against go/src/runtime, changes to use the number of CPUs
online. It's possible for this number to change, and thus become stale, but
that's unlikely, and not the default.
(This sysctl was added in 6.4.)
--- os_openbsd.go.orig Fri Feb 8 00:02:27 2019
+++ os_openbsd.go Fri Feb 8 00:06:21 2019
@@ -85,8 +85,8 @@
_KERN_OSREV = 3
_CTL_HW = 6
- _HW_NCPU = 3
_HW_PAGESIZE = 7
+ _HW_NCPUONLINE = 25
)
func sysctlInt(mib []uint32) (int32, bool) {
@@ -101,7 +101,7 @@
func getncpu() int32 {
// Fetch hw.ncpu via sysctl.
- if ncpu, ok := sysctlInt([]uint32{_CTL_HW, _HW_NCPU}); ok {
+ if ncpu, ok := sysctlInt([]uint32{_CTL_HW, _HW_NCPUONLINE}); ok {
return int32(ncpu)
}
return 1
Re: go uses too many CPUs
How horrible.
We had about 20 things depending on the old mix of "all cpus all the time",
and this one fell through the cracks.
> Go tries to use NCPU cpus. Unfortunately, half of them are turned off because
> hw.smt=0 by default, and then go spends a lot of time fighting against itself.
>
> The diff below, against go/src/runtime, changes to use the number of CPUs
> online. It's possible for this number to change, and thus become stale, but
> that's unlikely, and not the default.
>
> (This sysctl was added in 6.4.)
>
> --- os_openbsd.go.origFri Feb 8 00:02:27 2019
> +++ os_openbsd.go Fri Feb 8 00:06:21 2019
> @@ -85,8 +85,8 @@
> _KERN_OSREV = 3
>
> _CTL_HW = 6
> - _HW_NCPU = 3
> _HW_PAGESIZE = 7
> + _HW_NCPUONLINE = 25
> )
>
> func sysctlInt(mib []uint32) (int32, bool) {
> @@ -101,7 +101,7 @@
>
> func getncpu() int32 {
> // Fetch hw.ncpu via sysctl.
> - if ncpu, ok := sysctlInt([]uint32{_CTL_HW, _HW_NCPU}); ok {
> + if ncpu, ok := sysctlInt([]uint32{_CTL_HW, _HW_NCPUONLINE}); ok {
> return int32(ncpu)
> }
> return 1
>
Re: go uses too many CPUs
On Fri, Feb 08, 2019 at 12:10:02AM -0500, Ted Unangst wrote:
> Go tries to use NCPU cpus. Unfortunately, half of them are turned off because
> hw.smt=0 by default, and then go spends a lot of time fighting against itself.
>
> The diff below, against go/src/runtime, changes to use the number of CPUs
> online. It's possible for this number to change, and thus become stale, but
> that's unlikely, and not the default.
>
> (This sysctl was added in 6.4.)
Yes, please,
-Otto
>
> --- os_openbsd.go.origFri Feb 8 00:02:27 2019
> +++ os_openbsd.go Fri Feb 8 00:06:21 2019
> @@ -85,8 +85,8 @@
> _KERN_OSREV = 3
>
> _CTL_HW = 6
> - _HW_NCPU = 3
> _HW_PAGESIZE = 7
> + _HW_NCPUONLINE = 25
> )
>
> func sysctlInt(mib []uint32) (int32, bool) {
> @@ -101,7 +101,7 @@
>
> func getncpu() int32 {
> // Fetch hw.ncpu via sysctl.
> - if ncpu, ok := sysctlInt([]uint32{_CTL_HW, _HW_NCPU}); ok {
> + if ncpu, ok := sysctlInt([]uint32{_CTL_HW, _HW_NCPUONLINE}); ok {
> return int32(ncpu)
> }
> return 1
>
Re: [NEW] sysutils/node_exporter 0.17.0
* Ralf Horstmann [2019-02-04 23:14]: > Hi ports, > > attached is a new port of node_exporter, a monitoring agent for > the Prometheus monitoring system. It provides collectors for > hardware and OS metrics (cpu, load, filesystem, interrupts, > memory, network) > > Tested on i386 and amd64. Here is a new tarball with a patch to add a diskstats collector for OpenBSD. I have submitted the diskstats collector upstream and it has been included for next release. comments? node_exporter.tgz Description: application/tar-gz
