NEW: x11/lemonbar
Hi, please find attached a port for lemonbar. $ cat pkg/DESCR lemonbar (formerly known as bar) is a lightweight bar entirely based on XCB. Provides full UTF-8 support, basic formatting, RandR and Xinerama support and EWMH compliance without wasting your precious memory. https://github.com/LemonBoy/bar You can test it e.g. with echo "Hello World!" | lemonbar -p or i3status | lemonbar -p in case you have x11/i3status installed (and set output_format = "lemonbar"). Configuration tips: https://wiki.archlinux.org/index.php/Lemonbar One drawback is that it lacks XFT support (https://github.com/LemonBoy/bar/issues/188). Besides that it works fine. OK to import? Best regards, Ingo lemonbar.tar.gz Description: application/tar-gz
Re: ocamlyacc segfault triggered by ocaml-menhir's parser
On Tue, Feb 21, 2017 at 5:59 AM, Stuart Hendersonwrote: > I ran across this in an i386 bulk build, but it's easy to reproduce. > ocamlyacc segfaults when processing the parser from ocaml-menhir-20170101: Pretty nice detective work -- I'd never seen this segfault before. I checked with the previous version of ocaml-menhir that was in the tree (20160303) and it has the same behaviour. So the recent update doesn't look like it introduced a regression. > > $ cd /usr/ports/devel/ocaml-menhir; make > [..] > $ cd `make show=WRKSRC`/src/_stage1 > $ for i in `jot 200`; do ocamlyacc parser.mly || echo $i; done > Segmentation fault (core dumped) > 39 > Segmentation fault (core dumped) > 49 > Segmentation fault (core dumped) > 172 > Segmentation fault (core dumped) > 180 > > Output files are zero bytes, backtrace looks like this: > > Program terminated with signal SIGSEGV, Segmentation fault. > #0 set_first_derives () at closure.c:109 > 109 cword = *vrow++; > (gdb) bt full > #0 set_first_derives () at closure.c:109 > rrow = 0x199365ec1374 > vrow = 0x1992f74b2000 > j = 62 > mask = 0 > cword = 2164277248 > rp = 0x20 > rule = -1 > i = 62 > rulesetsize = > varsetsize = 1 > #1 0x1990ce60372f in generate_states () at lr0.c:155 > No locals. > #2 0x1990ce604215 in main (argc=2, argv=0x7f7d69f8) at main.c:456 > No locals. > > I know very little about OCaml so if someone's interested, could you take > a look and/or report upstream please? > I guess avsm@ might good to talk to. I've cc'd him on this thread. I also bcc'd Francois Pottier (ocaml menhir upstream) in case he has any interest in this thread. p.s. I did a local update of ocaml from 4.03.0 to 4.04.0 to see if anything's changed, but unfortunately doesn't seem to change much (at least on my end).
Re: possible chromium regression on -current
On 02/23/17 14:26, Bryan Steele wrote: On Wed, Feb 22, 2017 at 11:35:24AM +, Dimitris Papastamos wrote: Hi everyone, I think at some point in the last week a possible chromium regression was introduced. Youtube videos give a playback error. This is what I get in the log: [11087:-105893312:0221/190453.466753:ERROR:sync_control_vsync_provider.cc(144)] glXGetSyncValuesOML should not return TRUE with a media stream counter of 0. [70895:441591864:0221/190454.467559:ERROR:network_interfaces_posix.cc(63)] Not implemented reached in bool net::GetNetworkList(NetworkInterfaceList *, int) [97863:574132800:0221/190457.039780:ERROR:render_media_log.cc(25)] MediaEvent: PIPELINE_ERROR pipeline: initialization failed [11087:-105893312:0221/190457.133204:ERROR:sync_control_vsync_provider.cc(144)] glXGetSyncValuesOML should not return TRUE with a media stream counter of 0. [97863:574132800:0221/190457.459204:ERROR:render_media_log.cc(25)] MediaEvent: PIPELINE_ERROR pipeline: initialization failed [70895:441591864:0221/190500.474199:ERROR:network_interfaces_posix.cc(63)] Not implemented reached in bool net::GetNetworkList(NetworkInterfaceList *, int) Any ideas? I noticed this too and mentioned it on a ports dev chat, I remember it working a few weeks ago. But I'm not sure if it stopped working before or after the 56.0.2924.87 update.. It appears to affect only some HTML5 video streaming sites, like Youtube and Twitch, but embedded still works. It doesn't appear to be drm(4) obviously related either as WebGL demos work fine. At least a few people said it still works for them, so perhaps it's a certain hardware combination that's causing this? -Bryan. I'm experiencing this too: Thinkpad T430 on recent snapshots. inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 4000" rev 0x09 drm0 at inteldrm0 inteldrm0: msi inteldrm0: 1366x768, 32bpp wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) t/
Update to py-werkzeug-0.11.15 and take maintainership
¡Hola! Here's a diff to update to latest py-werkzeug release (it's a bit funny, .11 was released on August, then both .12 and .13 on Dec 26th and again on Dec 30th two releases, .14 and .15). ChangeLog: https://github.com/pallets/werkzeug/blob/master/CHANGES#L59 Comments? OK? Cheers, Daniel Index: Makefile === RCS file: /cvs/ports/www/py-werkzeug/Makefile,v retrieving revision 1.27 diff -u -p -r1.27 Makefile --- Makefile 3 Jan 2017 19:28:49 - 1.27 +++ Makefile 23 Feb 2017 03:32:40 - @@ -2,14 +2,15 @@ COMMENT = WSGI utility collection -MODPY_EGG_VERSION = 0.11.11 +MODPY_EGG_VERSION = 0.11.15 DISTNAME = Werkzeug-${MODPY_EGG_VERSION} PKGNAME = py-${DISTNAME:L} -REVISION = 0 CATEGORIES = www devel HOMEPAGE = http://werkzeug.pocoo.org/ + +MAINTAINER = Daniel Jakots# BSD PERMIT_PACKAGE_CDROM = Yes Index: distinfo === RCS file: /cvs/ports/www/py-werkzeug/distinfo,v retrieving revision 1.12 diff -u -p -r1.12 distinfo --- distinfo 31 Oct 2016 12:46:13 - 1.12 +++ distinfo 23 Feb 2017 03:32:40 - @@ -1,2 +1,2 @@ -SHA256 (Werkzeug-0.11.11.tar.gz) = ndGiqHO4zo1NHY3rkBXFu38ohNl6NKS4DNaHFe48BBg= -SIZE (Werkzeug-0.11.11.tar.gz) = 1171310 +SHA256 (Werkzeug-0.11.15.tar.gz) = VVAtRGu6j8FOFt2LNO5JrJiRUhUBSUFtmLQtnnub7+g= +SIZE (Werkzeug-0.11.15.tar.gz) = 1171456 Index: pkg/PLIST === RCS file: /cvs/ports/www/py-werkzeug/pkg/PLIST,v retrieving revision 1.11 diff -u -p -r1.11 PLIST --- pkg/PLIST 31 Oct 2016 12:46:13 - 1.11 +++ pkg/PLIST 23 Feb 2017 03:32:40 - @@ -1,10 +1,10 @@ @comment $OpenBSD: PLIST,v 1.11 2016/10/31 12:46:13 danj Exp $ -lib/python${MODPY_VERSION}/site-packages/Werkzeug-${MODPY_EGG_VERSION}.dev0-py${MODPY_VERSION}.egg-info/ -lib/python${MODPY_VERSION}/site-packages/Werkzeug-${MODPY_EGG_VERSION}.dev0-py${MODPY_VERSION}.egg-info/PKG-INFO -lib/python${MODPY_VERSION}/site-packages/Werkzeug-${MODPY_EGG_VERSION}.dev0-py${MODPY_VERSION}.egg-info/SOURCES.txt -lib/python${MODPY_VERSION}/site-packages/Werkzeug-${MODPY_EGG_VERSION}.dev0-py${MODPY_VERSION}.egg-info/dependency_links.txt -lib/python${MODPY_VERSION}/site-packages/Werkzeug-${MODPY_EGG_VERSION}.dev0-py${MODPY_VERSION}.egg-info/not-zip-safe -lib/python${MODPY_VERSION}/site-packages/Werkzeug-${MODPY_EGG_VERSION}.dev0-py${MODPY_VERSION}.egg-info/top_level.txt +lib/python${MODPY_VERSION}/site-packages/Werkzeug-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/ +lib/python${MODPY_VERSION}/site-packages/Werkzeug-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO +lib/python${MODPY_VERSION}/site-packages/Werkzeug-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/SOURCES.txt +lib/python${MODPY_VERSION}/site-packages/Werkzeug-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/dependency_links.txt +lib/python${MODPY_VERSION}/site-packages/Werkzeug-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/not-zip-safe +lib/python${MODPY_VERSION}/site-packages/Werkzeug-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt lib/python${MODPY_VERSION}/site-packages/werkzeug/ lib/python${MODPY_VERSION}/site-packages/werkzeug/__init__.py ${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/werkzeug/${MODPY_PYCACHE}/
Re: possible chromium regression on -current
On Wed, Feb 22, 2017 at 11:35:24AM +, Dimitris Papastamos wrote: > Hi everyone, > > I think at some point in the last week a possible chromium regression > was introduced. > > Youtube videos give a playback error. This is what I get in the log: > > [11087:-105893312:0221/190453.466753:ERROR:sync_control_vsync_provider.cc(144)] > glXGetSyncValuesOML should not return TRUE with a media stream counter > of 0. > [70895:441591864:0221/190454.467559:ERROR:network_interfaces_posix.cc(63)] > Not implemented reached in bool > net::GetNetworkList(NetworkInterfaceList *, int) > [97863:574132800:0221/190457.039780:ERROR:render_media_log.cc(25)] > MediaEvent: PIPELINE_ERROR pipeline: initialization failed > [11087:-105893312:0221/190457.133204:ERROR:sync_control_vsync_provider.cc(144)] > glXGetSyncValuesOML should not return TRUE with a media stream counter > of 0. > [97863:574132800:0221/190457.459204:ERROR:render_media_log.cc(25)] > MediaEvent: PIPELINE_ERROR pipeline: initialization failed > [70895:441591864:0221/190500.474199:ERROR:network_interfaces_posix.cc(63)] > Not implemented reached in bool > net::GetNetworkList(NetworkInterfaceList *, int) > > Any ideas? I noticed this too and mentioned it on a ports dev chat, I remember it working a few weeks ago. But I'm not sure if it stopped working before or after the 56.0.2924.87 update.. It appears to affect only some HTML5 video streaming sites, like Youtube and Twitch, but embedded still works. It doesn't appear to be drm(4) obviously related either as WebGL demos work fine. At least a few people said it still works for them, so perhaps it's a certain hardware combination that's causing this? -Bryan. radeondrm0 at pci1 dev 5 function 0 "ATI Radeon HD 3000" rev 0x00 drm0 at radeondrm0 name of display: :0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.4 server glx extensions: GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_swap_control client glx vendor string: Mesa Project and SGI client glx version string: 1.4 client glx extensions: GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync GLX version: 1.4 GLX extensions: GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync Extended renderer info (GLX_MESA_query_renderer): Vendor: X.Org (0x1002) Device: AMD RS780 (DRM 2.29.0 / 6.0) (0x9616) Version: 13.0.3 Accelerated: yes Video memory: 512MB Unified memory: no Preferred profile: core (0x1) Max core profile version: 3.1 Max compat profile version: 3.0 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.0 OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RS780 (DRM 2.29.0 / 6.0) OpenGL core profile version string: 3.1 (Core Profile) Mesa 13.0.3 OpenGL core profile shading language version string: 1.40 OpenGL core profile context flags: (none) OpenGL core profile extensions: GL_AMD_conservative_depth, GL_AMD_draw_buffers_blend, GL_AMD_performance_monitor,
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: d...@cvs.openbsd.org2017/02/22 19:51:11 Modified files: www/py-flask : Makefile distinfo www/py-flask/patches: patch-docs_conf_py www/py-flask/pkg: PLIST Log message: Maintainer update to py-flask-0.12
flake8 -> py-flake8 + py3 flavor
Hi, The only way to add a py3 flavor to flake8 is by renaming the port. Plan is: 1. import a py-flake8 which is flake8 + py-flake8.diff. 2. hook py{,3}-flake8 and unhook flake8 in devel/Makefile 3. commit devel/quirks 4. commit net/py-libcloud and www/youtube-dl (I didn't rev bump as it's TDEP only) 5. cvs rm devel/flake8 According to cvsweb, there have never been any py-flake8 before so things should be smoother than last time (-: Cheers, DanielIndex: Makefile === RCS file: /cvs/ports/net/py-libcloud/Makefile,v retrieving revision 1.14 diff -u -p -r1.14 Makefile --- Makefile 30 Dec 2016 11:31:06 - 1.14 +++ Makefile 23 Feb 2017 01:22:51 - @@ -23,7 +23,7 @@ MODPY_SETUPTOOLS= Yes RUN_DEPENDS= sysutils/py-lockfile -TEST_DEPENDS= devel/flake8 \ +TEST_DEPENDS= devel/py-flake8 \ devel/pep8 \ devel/py-mock \ sysutils/py-lockfile Index: Makefile === RCS file: /cvs/ports/www/youtube-dl/Makefile,v retrieving revision 1.162 diff -u -p -r1.162 Makefile --- Makefile 14 Feb 2017 20:30:11 - 1.162 +++ Makefile 23 Feb 2017 01:21:31 - @@ -21,7 +21,7 @@ MODULES = lang/python MODPY_SETUPTOOLS = Yes -TEST_DEPENDS += devel/flake8 \ +TEST_DEPENDS += devel/py-flake8 \ devel/py-nose do-test: Index: Makefile === RCS file: /cvs/ports/devel/quirks/Makefile,v retrieving revision 1.441 diff -u -p -r1.441 Makefile --- Makefile 19 Feb 2017 21:14:44 - 1.441 +++ Makefile 23 Feb 2017 01:20:08 - @@ -5,7 +5,7 @@ CATEGORIES = devel databases DISTFILES = # API.rev -PKGNAME = quirks-2.286 +PKGNAME = quirks-2.287 PKG_ARCH = * MAINTAINER = Marc EspieIndex: files/Quirks.pm === RCS file: /cvs/ports/devel/quirks/files/Quirks.pm,v retrieving revision 1.453 diff -u -p -r1.453 Quirks.pm --- files/Quirks.pm 19 Feb 2017 21:14:44 - 1.453 +++ files/Quirks.pm 23 Feb 2017 01:20:08 - @@ -410,6 +410,7 @@ my $stem_extensions = { 'u-boot' => 'u-boot-arm', 'ja-w3m' => 'w3m', 'markdown' => 'py-markdown', + 'flake8' => 'py-flake8', }; my $obsolete_reason = { Index: Makefile === RCS file: /cvs/ports/devel/flake8/Makefile,v retrieving revision 1.11 diff -u -p -r1.11 Makefile --- Makefile 19 Feb 2017 20:15:42 - 1.11 +++ Makefile 23 Feb 2017 01:38:41 - @@ -4,6 +4,8 @@ COMMENT = modular python code checker w MODPY_EGG_VERSION = 3.3.0 DISTNAME = flake8-${MODPY_EGG_VERSION} +PKGNAME = py-${DISTNAME} +REVISION = 0 CATEGORIES = devel @@ -19,17 +21,26 @@ MODULES = lang/python MODPY_PI = Yes MODPY_SETUPTOOLS = Yes +FLAVORS = python3 +FLAVOR ?= + TEST_DEPENDS = ${RUN_DEPENDS} \ - devel/py-test \ - devel/py-mock + devel/py-test${MODPY_FLAVOR} \ + devel/py-mock${MODPY_FLAVOR} + +RUN_DEPENDS = devel/py-codestyle${MODPY_FLAVOR} \ + devel/py-mccabe${MODPY_FLAVOR} \ + devel/pyflakes${MODPY_FLAVOR} + +.if ! ${FLAVOR:Mpython3} +RUN_DEPENDS += devel/py-configparser \ + devel/py-enum34 +.endif -RUN_DEPENDS = devel/py-codestyle \ - devel/py-configparser \ - devel/py-enum34 \ - devel/py-mccabe \ - devel/pyflakes +BUILD_DEPENDS = devel/py-test-runner${MODPY_FLAVOR} -BUILD_DEPENDS = devel/py-test-runner +post-install: + mv ${PREFIX}/bin/flake8{,${MODPY_BIN_SUFFIX}} do-test: cd ${WRKSRC} && PYTHONPATH=src ${MODPY_BIN} -m pytest tests Index: pkg/PFRAG.no-python3 === RCS file: pkg/PFRAG.no-python3 diff -N pkg/PFRAG.no-python3 --- /dev/null 1 Jan 1970 00:00:00 - +++ pkg/PFRAG.no-python3 23 Feb 2017 01:38:41 - @@ -0,0 +1,3 @@ +@comment $OpenBSD$ +@pkgpath devel/flake8 +@conflict flake8-* Index: pkg/PLIST === RCS file: /cvs/ports/devel/flake8/pkg/PLIST,v retrieving revision 1.4 diff -u -p -r1.4 PLIST --- pkg/PLIST 15 Nov 2016 08:23:50 - 1.4 +++ pkg/PLIST 23 Feb 2017 01:38:41 - @@ -1,5 +1,6 @@ @comment $OpenBSD: PLIST,v 1.4 2016/11/15 08:23:50 shadchin Exp $ -bin/flake8 +!%%python3%% +bin/flake8${MODPY_BIN_SUFFIX} lib/python${MODPY_VERSION}/site-packages/flake8/ lib/python${MODPY_VERSION}/site-packages/flake8-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/ lib/python${MODPY_VERSION}/site-packages/flake8-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO @@ -9,71 +10,77 @@ lib/python${MODPY_VERSION}/site-packages lib/python${MODPY_VERSION}/site-packages/flake8-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt lib/python${MODPY_VERSION}/site-packages/flake8-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt lib/python${MODPY_VERSION}/site-packages/flake8/__init__.py -lib/python${MODPY_VERSION}/site-packages/flake8/__init__.pyc
make search complains Re: CVS: cvs.openbsd.org: ports
On Tue, 21 Feb 2017 09:43:53 -0700 (MST), Marc Espiewrote: > CVSROOT: /cvs > Module name: ports > Changes by: es...@cvs.openbsd.org 2017/02/21 09:43:53 > > Removed files: > infrastructure/man/man1: retrieve-index.1 > infrastructure/bin: extract-dependencies find-build-order > retrieve-index > > Log message: > kill old cruft. keep portslogger as people still use it > $ make search name=foobar Can't open perl script "/usr/ports/infrastructure/bin/retrieve-index": No such file or directory *** Warning in /usr/ports: "${_CMD}" returned non-zero status (Makefile:29)
Remove audio/bladeenc?
Hi ports@, BladeEnc has been dead upstream for years [1], and the latest version is from 2001. Nothing depends on it. The main thing it had for it was speed, which is irrelevant on current hardware. Audio quality was always controversial. Besides us, only Gentoo and Pkgsrc still have packages for it. Comments? OK to remove it? [1] http://web.archive.org/web/20021211095709/http://bladeenc.mp3.no/skeleton/news.html
Re: HEADS UP: fetch/checksum/makesum tweaks
On Wed, Feb 22, 2017 at 07:37:09PM +0100, Jeremie Courreges-Anglas wrote: > I'd like to point out that it harms a process I have as a port user. If > projects published signatures for their releases, I want to check them, > because I can have a trust relationship with upstream. > So the process that involves ''make makesum'', verify the signature, > ''make makesum'' is now broken. Can I just set _MAKESUM=true in > /etc/mk.conf and be sure that I have the same workflow as before? If > so, I think this variable should be a documented user setting. Your process doesn't make sense. Neither does your suggestion. Where's the typo ?
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rpoin...@cvs.openbsd.org2017/02/22 12:17:05 Modified files: security : Makefile Log message: + SUBDIR += py-dfvfs
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rpoin...@cvs.openbsd.org2017/02/22 12:15:59 Log message: import py-dfvfs: Digital Forensics Virtual File System (dfVFS). ok benoit@. Status: Vendor Tag: rpointel Release Tags: rpointel_20170222 N ports/security/py-dfvfs/Makefile N ports/security/py-dfvfs/distinfo N ports/security/py-dfvfs/pkg/PLIST N ports/security/py-dfvfs/pkg/DESCR No conflicts created by this import
Re: ruby-raindrops on arm
On 02/22 01:52, Jeremie Courreges-Anglas wrote: > > Fails as in > > > http://build-failures.rhaalovely.net//arm/2017-02-02/www/ruby-raindrops,ruby22.log > > Prevent the build system to add -march=i486 and use libatomic_ops. > With this plus the missing test dep, tests pass on arm. > > I was tempted to restrict the BDEP to arm, but I guess it will probably > help on hppa too, and the dep is cheap anyway. > > ok? OK jeremy@ > > > Index: Makefile > === > RCS file: /d/cvs/ports/www/ruby-raindrops/Makefile,v > retrieving revision 1.13 > diff -u -p -r1.13 Makefile > --- Makefile 4 Nov 2016 21:46:42 - 1.13 > +++ Makefile 22 Feb 2017 12:48:52 - > @@ -14,10 +14,11 @@ MODULES = lang/ruby > > CONFIGURE_STYLE =ruby gem ext > > -# XXX only actually required for gcc2/3 arch > +# XXX fallback if arch doesn't provide atomic builtins > BUILD_DEPENDS += libatomic_ops-*:devel/boehm-gc,-atomic > > -TEST_DEPENDS = devel/gmake \ > +TEST_DEPENDS = devel/gmake \ > + www/ruby-rack,${MODRUBY_FLAVOR} \ > www/ruby-unicorn,${MODRUBY_FLAVOR} \ > ${FULLPKGNAME}:${BUILD_PKGPATH} > > Index: patches/patch-ext_raindrops_extconf_rb > === > RCS file: patches/patch-ext_raindrops_extconf_rb > diff -N patches/patch-ext_raindrops_extconf_rb > --- /dev/null 1 Jan 1970 00:00:00 - > +++ patches/patch-ext_raindrops_extconf_rb22 Feb 2017 12:18:26 - > @@ -0,0 +1,22 @@ > +$OpenBSD$ > +--- ext/raindrops/extconf.rb.origWed Feb 22 13:17:45 2017 > ext/raindrops/extconf.rb Wed Feb 22 13:18:16 2017 > +@@ -31,18 +31,6 @@ SRC > + if try_link(src) > + $defs.push(format("-DHAVE_GCC_ATOMIC_BUILTINS")) > + true > +- else > +-# some compilers still target 386 by default, but we need at least 486 > +-# to run atomic builtins. > +-prev_cflags = $CFLAGS > +-$CFLAGS += " -march=i486 " > +-if try_link(src) > +- $defs.push(format("-DHAVE_GCC_ATOMIC_BUILTINS")) > +- true > +-else > +- prev_cflags = $CFLAGS > +- false > +-end > + end > + end or have_header('atomic_ops.h') or abort <<-SRC > + > Index: patches/patch-pkg_mk > === > RCS file: /d/cvs/ports/www/ruby-raindrops/patches/patch-pkg_mk,v > retrieving revision 1.1.1.1 > diff -u -p -r1.1.1.1 patch-pkg_mk > --- patches/patch-pkg_mk 6 Jul 2011 01:14:09 - 1.1.1.1 > +++ patches/patch-pkg_mk 22 Feb 2017 12:18:26 - > @@ -1,9 +1,9 @@ > $OpenBSD: patch-pkg_mk,v 1.1.1.1 2011/07/06 01:14:09 jeremy Exp $ > pkg.mk.orig Mon Jun 27 10:49:35 2011 > -+++ pkg.mk Mon Jun 27 10:49:43 2011 > -@@ -146,7 +146,7 @@ all:: test > - test_units := $(wildcard test/test_*.rb) > - test: test-unit > +--- pkg.mk.orig Sun Jul 31 17:20:21 2016 > pkg.mk Wed Feb 22 13:15:38 2017 > +@@ -118,7 +118,7 @@ test_units := $(wildcard test/test_*.rb) > + test: check > + check: test-unit > test-unit: $(test_units) > -$(test_units): build > +$(test_units): > > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: HEADS UP: fetch/checksum/makesum tweaks
Marc Espiewrites: > I've recently streamlined a bit the fetch/checksum/makesum code... > too many tests. > > One *wanted* side-effect is to make it slightly harder to have distfiles > without checksum. > > Doesn't change anything for normal port users. I'd like to point out that it harms a process I have as a port user. If projects published signatures for their releases, I want to check them, because I can have a trust relationship with upstream. So the process that involves ''make makesum'', verify the signature, ''make makesum'' is now broken. Can I just set _MAKESUM=true in /etc/mk.conf and be sure that I have the same workflow as before? If so, I think this variable should be a documented user setting. Pretty please. :) -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
HEADS UP: fetch/checksum/makesum tweaks
I've recently streamlined a bit the fetch/checksum/makesum code... too many tests. One *wanted* side-effect is to make it slightly harder to have distfiles without checksum. Doesn't change anything for normal port users. When you're creating a new port, however, you will probably want to run "make makesum" right away. 1/ you will have to run makesum at some point 2/ fetch will normally just refuse files it doesn't know about, leading to ftp file, isn't mentioned in distinfo -> errors out (and make removes the file) Here is (more or less) the actual change. You'll noticed the corresponding logic is about half as long. (small print: internal variable _MAKESUM, if it's not set to true, size check in distinfo *ALWAYS* happens during fetch, so anything except makesum will fail if the file is not referenced correctly in there) Index: bsd.port.mk === RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v retrieving revision 1.1326 retrieving revision 1.1336 diff -u -p -r1.1326 -r1.1336 --- bsd.port.mk 13 Feb 2017 12:56:50 - 1.1326 +++ bsd.port.mk 21 Feb 2017 13:55:16 - 1.1336 @@ -181,7 +185,11 @@ _PROGRESS = -m _PROGRESS = .endif -FETCH_CMD ?= /usr/bin/ftp -V ${_PROGRESS} -k ${FTP_KEEPALIVE} -C +FETCH_CMD ?= /usr/bin/ftp -V ${_PROGRESS} -C + +# switch for fetching each distfile: avoid warnings for missing +# distinfo and wrong size when running makesum +_MAKESUM ?= false PKG_TMPDIR ?= /var/tmp @@ -658,16 +675,12 @@ _ALL_COOKIES = ${_EXTRACT_COOKIE} ${_PAT _MAKE_COOKIE = touch -# Miscellaneous overridable commands: GMAKE ?= gmake CHECKSUM_FILE ?= ${.CURDIR}/distinfo -# Don't touch !!! Used for generating checksums. -_CIPHERS = sha256 - -# This is the one you can override -PREFERRED_CIPHERS ?= ${_CIPHERS} +# Current digest algorithm +_CIPHER = sha256 PORTPATH ?= ${WRKDIR}/bin:/usr/bin:/bin:/usr/sbin:/sbin:${LOCALBASE}/bin:${X11BASE}/bin @@ -1974,11 +1976,12 @@ ${_FUPDATE_COOKIE${_S}}: .PRECIOUS: ${_PACKAGE_COOKIES} ${_INSTALL_COOKIES} -makesum: fetch-all +makesum: @${_warn_checksum} -.if !defined(NO_CHECKSUM) && !empty(MAKESUMFILES) @rm -f ${CHECKSUM_FILE} - @cd ${DISTDIR} && cksum -b -a "${_CIPHERS}" ${MAKESUMFILES} >> ${CHECKSUM_FILE} + @${MAKE} fetch-all _MAKESUM=true +.if !empty(MAKESUMFILES) + @cd ${DISTDIR} && cksum -b -a "${_CIPHER}" ${MAKESUMFILES} >> ${CHECKSUM_FILE} @cd ${DISTDIR} && \ for file in ${MAKESUMFILES}; do \ ${_size_fragment} $$file $$file >> ${CHECKSUM_FILE}; \ @@ -2250,49 +2235,41 @@ _internal-checksum: _internal-fetch exit 1; \ fi; \ done -. if !defined(NO_CHECKSUM) - @if [ -z "${DISTFILES}" ]; then \ - ${ECHO_MSG} ">> No distfiles."; \ - elif [ ! -f ${CHECKSUM_FILE} ]; then \ - ${ECHO_MSG} ">> No checksum file."; \ +. if empty(CHECKSUMFILES) + @${ECHO_MSG} ">> No DISTFILES nor PATCHFILES." +. else +.if !defined(NO_CHECKSUM) + @if [ ! -f ${CHECKSUM_FILE} ]; then \ + ${ECHO_MSG} 1>&2 ">> No ${CHECKSUM_FILE}."; \ exit 1; \ - else \ - cd ${DISTDIR}; OK=true; list=''; \ - for file in ${CHECKSUMFILES}; do \ - for cipher in ${PREFERRED_CIPHERS}; do \ - set -- $$(grep -i "^$$cipher ($$file)" ${CHECKSUM_FILE}) \ - && break || \ - ${ECHO_MSG} ">> No $$cipher checksum recorded for $$file."; \ - done; \ - case "$$4" in \ - "") \ - ${ECHO_MSG} ">> No checksum recorded for $$file."; \ - OK=false;; \ - "IGNORE") \ - echo ">> Error: checksum for $$file is set to IGNORE in distinfo"; \ - OK=false;; \ - *) \ - echo -n '>> '; \ - if ! echo "$$@" | cksum -c; then \ - echo ">> Checksum mismatch for $$file. ($$cipher)"; \ - list="$$list $$file $$cipher $$4"; \ - OK=false; \ - fi;; \ - esac; \ - done; \ - set --; \ - if ! $$OK; then \ - if ${REFETCH}; then \ - cd ${.CURDIR} && PKGPATH=${PKGPATH} ${MAKE} _refetch _PROBLEMS="$$list"; \ - else \ - echo "Make sure the Makefile and checksum file (${CHECKSUM_FILE})"; \ - echo "are up to date. If you want to fetch a good copy of this"; \ - echo "file from the OpenBSD main archive, type"; \ - echo "\"make REFETCH=true [other args]\"."; \ - exit 1; \ -
Re: more spring cleanup
On Tue, Feb 21, 2017 at 04:11:18PM +, Christian Weisgerber wrote: > On 2017-02-21, Marc Espiewrote: > > > A few oddities in bsd.port.mk > > > > - CDROM_SITE ? > > This is somewhat useful. Not for actual CDROM distribution, but > for opportunistically getting distfiles from a central NFS stash > if they happen to be there. Hmmm... However, it doesn't handle > DIST_SUBDIR... I think I have gone several times through the cycle > where I re-discovered CDROM_SITE, tried to use it, noticed the lack > of subdir handling, dropped the idea, and then subsequently forgot > all about it. So it would make more sense to GC it, and figure out a good way to handle what you need (with DIST_SUBDIR handling) and without the CDROM reference. > > - does anyone still use WRKOBJDIR= > > (which used to create w-* directly in each port's directory) > > - link-categories/unlink-categories ? > > - homepage-links ? > > I don't use any of these. Good, they're probably going to die soonish
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2017/02/22 07:34:34 Modified files: devel/libuv: Makefile Log message: Use lang/gcc for atomic builtins on arm.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2017/02/22 07:26:22 Added files: multimedia/libvpx/patches: patch-third_party_libyuv_include_libyuv_row_h Log message: Fix on arm, avoid broken vector support in old gcc versions. ok Brad (maintainer)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2017/02/22 07:28:30 Modified files: devel/libuv: Makefile devel/libuv/patches: patch-src_unix_openbsd_c Added files: devel/libuv/patches: patch-src_unix_tcp_c patch-src_unix_udp_c patch-test_test-udp-ipv6_c patch-test_test-udp-multicast-join6_c Log message: Fix IPv6 support.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2017/02/22 07:07:28 Modified files: x11/gnome/autoar: Makefile distinfo x11/gnome/autoar/pkg: PLIST Log message: Update to gnome-autoar-0.2.0.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2017/02/22 07:07:03 Modified files: x11/gnome/totem: Makefile x11/gnome/terminal: Makefile Log message: Sync WANTLIB.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2017/02/22 07:03:57 Modified files: graphics/evince: Makefile Log message: Some WANTLIB do not belong to the "light" FLAVOR.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2017/02/22 06:59:27 Modified files: mail/evolution-rss: Makefile Log message: Sync WANTLIB.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2017/02/22 06:25:36 Modified files: net/libpsl : Makefile Log message: Switch to libidn2
ruby-raindrops on arm
Fails as in http://build-failures.rhaalovely.net//arm/2017-02-02/www/ruby-raindrops,ruby22.log Prevent the build system to add -march=i486 and use libatomic_ops. With this plus the missing test dep, tests pass on arm. I was tempted to restrict the BDEP to arm, but I guess it will probably help on hppa too, and the dep is cheap anyway. ok? Index: Makefile === RCS file: /d/cvs/ports/www/ruby-raindrops/Makefile,v retrieving revision 1.13 diff -u -p -r1.13 Makefile --- Makefile4 Nov 2016 21:46:42 - 1.13 +++ Makefile22 Feb 2017 12:48:52 - @@ -14,10 +14,11 @@ MODULES = lang/ruby CONFIGURE_STYLE = ruby gem ext -# XXX only actually required for gcc2/3 arch +# XXX fallback if arch doesn't provide atomic builtins BUILD_DEPENDS += libatomic_ops-*:devel/boehm-gc,-atomic -TEST_DEPENDS = devel/gmake \ +TEST_DEPENDS = devel/gmake \ + www/ruby-rack,${MODRUBY_FLAVOR} \ www/ruby-unicorn,${MODRUBY_FLAVOR} \ ${FULLPKGNAME}:${BUILD_PKGPATH} Index: patches/patch-ext_raindrops_extconf_rb === RCS file: patches/patch-ext_raindrops_extconf_rb diff -N patches/patch-ext_raindrops_extconf_rb --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-ext_raindrops_extconf_rb 22 Feb 2017 12:18:26 - @@ -0,0 +1,22 @@ +$OpenBSD$ +--- ext/raindrops/extconf.rb.orig Wed Feb 22 13:17:45 2017 ext/raindrops/extconf.rb Wed Feb 22 13:18:16 2017 +@@ -31,18 +31,6 @@ SRC + if try_link(src) + $defs.push(format("-DHAVE_GCC_ATOMIC_BUILTINS")) + true +- else +-# some compilers still target 386 by default, but we need at least 486 +-# to run atomic builtins. +-prev_cflags = $CFLAGS +-$CFLAGS += " -march=i486 " +-if try_link(src) +- $defs.push(format("-DHAVE_GCC_ATOMIC_BUILTINS")) +- true +-else +- prev_cflags = $CFLAGS +- false +-end + end + end or have_header('atomic_ops.h') or abort <<-SRC + Index: patches/patch-pkg_mk === RCS file: /d/cvs/ports/www/ruby-raindrops/patches/patch-pkg_mk,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 patch-pkg_mk --- patches/patch-pkg_mk6 Jul 2011 01:14:09 - 1.1.1.1 +++ patches/patch-pkg_mk22 Feb 2017 12:18:26 - @@ -1,9 +1,9 @@ $OpenBSD: patch-pkg_mk,v 1.1.1.1 2011/07/06 01:14:09 jeremy Exp $ pkg.mk.origMon Jun 27 10:49:35 2011 -+++ pkg.mk Mon Jun 27 10:49:43 2011 -@@ -146,7 +146,7 @@ all:: test - test_units := $(wildcard test/test_*.rb) - test: test-unit +--- pkg.mk.origSun Jul 31 17:20:21 2016 pkg.mk Wed Feb 22 13:15:38 2017 +@@ -118,7 +118,7 @@ test_units := $(wildcard test/test_*.rb) + test: check + check: test-unit test-unit: $(test_units) -$(test_units): build +$(test_units): -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
possible chromium regression on -current
Hi everyone, I think at some point in the last week a possible chromium regression was introduced. Youtube videos give a playback error. This is what I get in the log: [11087:-105893312:0221/190453.466753:ERROR:sync_control_vsync_provider.cc(144)] glXGetSyncValuesOML should not return TRUE with a media stream counter of 0. [70895:441591864:0221/190454.467559:ERROR:network_interfaces_posix.cc(63)] Not implemented reached in bool net::GetNetworkList(NetworkInterfaceList *, int) [97863:574132800:0221/190457.039780:ERROR:render_media_log.cc(25)] MediaEvent: PIPELINE_ERROR pipeline: initialization failed [11087:-105893312:0221/190457.133204:ERROR:sync_control_vsync_provider.cc(144)] glXGetSyncValuesOML should not return TRUE with a media stream counter of 0. [97863:574132800:0221/190457.459204:ERROR:render_media_log.cc(25)] MediaEvent: PIPELINE_ERROR pipeline: initialization failed [70895:441591864:0221/190500.474199:ERROR:network_interfaces_posix.cc(63)] Not implemented reached in bool net::GetNetworkList(NetworkInterfaceList *, int) Any ideas?
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ben...@cvs.openbsd.org 2017/02/22 03:13:18 Modified files: devel/p5-Config-Any: Makefile distinfo Log message: Update to p5-Config-Any-0.28.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ben...@cvs.openbsd.org 2017/02/22 02:37:51 Modified files: security/py-paramiko: Makefile distinfo Log message: Update to py-paramiko-2.1.2.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2017/02/22 02:06:11 Modified files: devel/llvm : Makefile devel/llvm/patches: patch-tools_clang_lib_Basic_Targets_cpp Log message: Fix OpenBSD/aarch64 types. from Brad (maintainer)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2017/02/22 01:25:48 Modified files: net/py-botocore: Makefile distinfo Log message: Update to py-botocore-1.5.15.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2017/02/22 01:25:59 Modified files: sysutils/awscli: Makefile distinfo Log message: Update to awscli-1.11.52.