NEW: x11/lemonbar

2017-02-22 Thread Ingo Feinerer
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

2017-02-22 Thread Daniel Dickman
On Tue, Feb 21, 2017 at 5:59 AM, Stuart Henderson  wrote:
> 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

2017-02-22 Thread Tobias Brodel



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

2017-02-22 Thread Daniel Jakots
¡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

2017-02-22 Thread Bryan Steele
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

2017-02-22 Thread Daniel Jakots
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

2017-02-22 Thread Daniel Jakots
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 Espie 
 
Index: 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

2017-02-22 Thread Daniel Jakots
On Tue, 21 Feb 2017 09:43:53 -0700 (MST), Marc Espie
 wrote:

> 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?

2017-02-22 Thread Frederic Cambus
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

2017-02-22 Thread Marc Espie
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

2017-02-22 Thread Remi Pointel
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

2017-02-22 Thread Remi Pointel
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

2017-02-22 Thread Jeremy Evans
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

2017-02-22 Thread Jeremie Courreges-Anglas
Marc Espie  writes:

> 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

2017-02-22 Thread Marc Espie
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

2017-02-22 Thread Marc Espie
On Tue, Feb 21, 2017 at 04:11:18PM +, Christian Weisgerber wrote:
> On 2017-02-21, Marc Espie  wrote:
> 
> > 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

2017-02-22 Thread Jeremie Courreges-Anglas
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

2017-02-22 Thread Jeremie Courreges-Anglas
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

2017-02-22 Thread Jeremie Courreges-Anglas
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

2017-02-22 Thread Antoine Jacoutot
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

2017-02-22 Thread Antoine Jacoutot
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

2017-02-22 Thread Antoine Jacoutot
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

2017-02-22 Thread Antoine Jacoutot
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

2017-02-22 Thread Jeremie Courreges-Anglas
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

2017-02-22 Thread Jeremie Courreges-Anglas

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

2017-02-22 Thread Dimitris Papastamos
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

2017-02-22 Thread Benoit Lecocq
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

2017-02-22 Thread Benoit Lecocq
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

2017-02-22 Thread Antoine Jacoutot
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

2017-02-22 Thread Antoine Jacoutot
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

2017-02-22 Thread Antoine Jacoutot
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.