Re: Cant build subversion on OPENBSD_5_8

[sven falempin]

On Wed, Feb 10, 2016 at 5:25 AM, Stuart Henderson 
wrote:

> On 2016/02/09 21:42, sven falempin wrote:
> > Hello,
> >
> > Sorry to inform you something is broken, looks these problem already
> > happened
> > a long time ago because of Build.pm regexp of version. I am not sure if
> it
> > is iconv 0.2 ?
> > Without the FLAVOR it ask iconv '6' and fail too.
>
> I'm not sure what you have done to your system but you seem to be
> having quite a few problems that don't really make sense and aren't
> happening for other people.
>
> > ===>  Verifying specs:  lib/db4/db>=4 expat pthread apr-1=5 iconv>=2
> > Missing library for iconv>=2.0
>
> Is /usr/local/lib/libiconv.so.6.0 present on your system?
>
> Have you had any crashes which might have corrupted /var/db/pkg?
> If so, run pkg_check.
>
>
I am not sure either, it is a night build, it just build the system from
scratch.

Worked since 5.7 and updated to 5.8 no problem, i am just keeping it up to
date, and for some raeson
it breaks now.

With a few patches here and there (one of those was a rdomain compatibility
for isc-dhcp for example)
nothing fancy.

pkg_check is not happy, libiconv was absent make reinstall the package fix
the problem.

I will look more into it, thanks for support.

-- 
-
() ascii ribbon campaign - against html e-mail
/\

CVS: cvs.openbsd.org: ports

[Vadim Zhukov]

CVSROOT:/cvs
Module name:ports
Changes by: z...@cvs.openbsd.org2016/02/10 06:26:46

Modified files:
x11/qt4: Makefile 
x11/qt4/patches: 
 patch-src_network_socket_qnativesocketengine_unix_cpp 

Log message:
It's always better to commit from the right tree. POLLOUT, not POLLHUP.

Re: www/xombrero Segmentation fault (core dumped) on macppc -current from Feb 8.

[Christoph R. Murauer]

> If you want a 'graphical and user-friendly web browser' on macppc, try
> www/netsurf. That's the only viable option (besides
> dillo/links/lynx/etc..) - using it daily there.
>
> Landry
>
>

I tried near all available GUI based browsers and, all (not netsuf)
died with a segmentation fault.

Maybe we found someone (I could build / test things but I am not a
coder) who could look at webkit or, we learn to live without it.

xlsx2csv broken

[Antoine Jacoutot]

===> textproc/xlsx2csv
===> xlsx2csv-20150225p1 depends on: go-xlsx-* -> go-xlsx-20151010p0
===> xlsx2csv-20150225p1 depends on: go-* -> go-1.5.3
go-1.5.3
go-xlsx-20151010p0
(Junk lock released for exopi-5 at 1455127136)
distfiles size=8682
>>> Running build in textproc/xlsx2csv at 1455127136
===> textproc/xlsx2csv
===>  Checking files for xlsx2csv-20150225p1
`/exopi-cvs/ports/distfiles/xlsx2csv-20150225.tar.gz' is up to date.
===>  Extracting for xlsx2csv-20150225p1
===>  Patching for xlsx2csv-20150225p1
mkdir -p /exopi-obj/pobj/xlsx2csv-20150225/go/src/github.com/tealeg; mv 
/exopi-obj/pobj/xlsx2csv-20150225/xlsx2csv-4d67bed54074c9f55a5443623155e57d4723901b
 /exopi-obj/pobj/xlsx2csv-20150225/go/src/github.com/tealeg/xlsx2csv;
===>  Configuring for xlsx2csv-20150225p1
===>  Building for xlsx2csv-20150225p1
unset GOPATH; export 
GOPATH="/exopi-obj/pobj/xlsx2csv-20150225/go:/usr/local/go-pkg"; go install -x 
github.com/tealeg/xlsx2csv
WORK=/tmp/go-build67122
mkdir -p $WORK/github.com/tealeg/xlsx/_obj/
mkdir -p $WORK/github.com/tealeg/
cd /usr/local/go-pkg/src/github.com/tealeg/xlsx
/usr/local/go/pkg/tool/openbsd_amd64/compile -o $WORK/github.com/tealeg/xlsx.a 
-trimpath $WORK -p github.com/tealeg/xlsx -complete -buildid 
90518c0c038b7176e8b01fb5b752aef4df0eb80d -D 
_/usr/local/go-pkg/src/github.com/tealeg/xlsx -I $WORK -pack ./cell.go ./col.go 
./date.go ./doc.go ./file.go ./hsl.go ./lib.go ./reftable.go ./row.go 
./sheet.go ./style.go ./templates.go ./theme.go ./write.go ./xmlContentTypes.go 
./xmlSharedStrings.go ./xmlStyle.go ./xmlTheme.go ./xmlWorkbook.go 
./xmlWorksheet.go
===> Exiting textproc/xlsx2csv with an error
mkdir -p /usr/local/go-pkg/pkg/openbsd_amd64/github.com/tealeg/
cp $WORK/github.com/tealeg/xlsx.a 
/usr/local/go-pkg/pkg/openbsd_amd64/github.com/tealeg/xlsx.a
go install github.com/tealeg/xlsx: open 
/usr/local/go-pkg/pkg/openbsd_amd64/github.com/tealeg/xlsx.a: permission denied
*** Error 1 in textproc/xlsx2csv (/exopi-cvs/ports/lang/go/go.port.mk:66 
'do-build')
*** Error 1 in textproc/xlsx2csv 
(/exopi-cvs/ports/infrastructure/mk/bsd.port.mk:2769 
'/exopi-obj/pobj/xlsx2csv-20150225/build-amd64/.build_done')
*** Error 1 in textproc/xlsx2csv 
(/exopi-cvs/ports/infrastructure/mk/bsd.port.mk:2495 'build')
*** Error 1 in /exopi-cvs/ports (infrastructure/mk/bsd.port.subdir.mk:147 
'build')
Error: job failed 256


No idea what's going on here.
# ls -al /usr/local/go-pkg/pkg/openbsd_amd64/github.com/tealeg/xlsx.a   

 
-r--r--r--  1 root  bin  1113336 Feb 10 18:56 
/usr/local/go-pkg/pkg/openbsd_amd64/github.com/tealeg/xlsx.a


-- 
Antoine

Re: alpha-1.ports.openbsd.org bulk build report

[Matthieu Herrb]

On Wed, Feb 10, 2016 at 10:21:47AM +, Stuart Henderson wrote:
> On 2016/02/10 10:57, Karel Gardas wrote:
> > > It has been fixed upstream:
> > >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66140
> > 
> > looks like in 5.1.1 which is GPL3 so probably not usable to be merge
> > into the OpenBSD's GPL2 4.2.1? But well, I'm not the lawyer here i
> > just see two different licenses so it raises red flag here...
> > 
> 
> We can't copy the patch directly. But it wouldn't be a big surprise
> if given the description of the bug someone else came up with a
> very similar diff though it would probably not have the whitespace
> change that is also in it.
> 
> Problem is that get_aligned_mem() and get_unaligned_address() need
> to look for replacements in memory addresses.

FWIW, even if we can't distribute the patched version, I could try it
on my alpha and the patch doesn't seem to fix libGL build.
.
-- 
Matthieu Herrb


signature.asc
Description: PGP signature

Re: xlsx2csv broken

[Christian Weisgerber]

No such error on amd64.p.  The build log looks different.

>>> Building on amd64-1 under textproc/xlsx2csv
 BDEPENDS = [textproc/go-xlsx;lang/go]
 DIST = [textproc/xlsx2csv:xlsx2csv-20150225.tar.gz]
 FULLPKGNAME = xlsx2csv-20150225p1
(Junk lock obtained for amd64-1 at 1455088818)
>>> Running depends in textproc/xlsx2csv at 1455088818
   last junk was in textproc/hs-polyparse
/usr/sbin/pkg_add -aI -Dunsigned -Drepair go-1.5.3 go-xlsx-20151010p0
was: /usr/sbin/pkg_add -aI -Dunsigned -Drepair go-1.5.3 go-xlsx-20151010p0
/usr/sbin/pkg_add -aI -Dunsigned -Drepair go-1.5.3 go-xlsx-20151010p0
>>> Running show-prepare-results in textproc/xlsx2csv at 1455088821
===> textproc/xlsx2csv
===> xlsx2csv-20150225p1 depends on: go-xlsx-* -> go-xlsx-20151010p0
===> xlsx2csv-20150225p1 depends on: go-* -> go-1.5.3
go-1.5.3
go-xlsx-20151010p0
(Junk lock released for amd64-1 at 1455088822)
distfiles size=8682
>>> Running build in textproc/xlsx2csv at 1455088822
===> textproc/xlsx2csv
===>  Checking files for xlsx2csv-20150225p1
`/usr/ports/distfiles/xlsx2csv-20150225.tar.gz' is up to date.
===>  Extracting for xlsx2csv-20150225p1
===>  Patching for xlsx2csv-20150225p1
mkdir -p /usr/obj/ports/xlsx2csv-20150225/go/src/github.com/tealeg; mv 
/usr/obj/ports/xlsx2csv-20150225/xlsx2csv-4d67bed54074c9f55a5443623155e57d4723901b
 /usr/obj/ports/xlsx2csv-20150225/go/src/github.com/tealeg/xlsx2csv;
===>  Configuring for xlsx2csv-20150225p1
===>  Building for xlsx2csv-20150225p1
unset GOPATH; export 
GOPATH="/usr/obj/ports/xlsx2csv-20150225/go:/usr/local/go-pkg"; go install -x 
github.com/tealeg/xlsx2csv
WORK=/tmp/go-build373902295
mkdir -p $WORK/github.com/tealeg/xlsx2csv/_obj/
mkdir -p $WORK/github.com/tealeg/xlsx2csv/_obj/exe/
cd /usr/obj/ports/xlsx2csv-20150225/go/src/github.com/tealeg/xlsx2csv
/usr/local/go/pkg/tool/openbsd_amd64/compile -o 
$WORK/github.com/tealeg/xlsx2csv.a -trimpath $WORK -p main -complete -buildid 
f1961bbf00030cae8f3f181b2a00597c42a5cb16 -D 
_/usr/obj/ports/xlsx2csv-20150225/go/src/github.com/tealeg/xlsx2csv -I $WORK -I 
/usr/local/go-pkg/pkg/openbsd_amd64 -pack ./main.go
cd .
/usr/local/go/pkg/tool/openbsd_amd64/link -o 
$WORK/github.com/tealeg/xlsx2csv/_obj/exe/a.out -L $WORK -L 
/usr/local/go-pkg/pkg/openbsd_amd64 -extld=cc -buildmode=exe 
-buildid=f1961bbf00030cae8f3f181b2a00597c42a5cb16 
$WORK/github.com/tealeg/xlsx2csv.a
mkdir -p /usr/obj/ports/xlsx2csv-20150225/go/bin/
cp $WORK/github.com/tealeg/xlsx2csv/_obj/exe/a.out 
/usr/obj/ports/xlsx2csv-20150225/go/bin/xlsx2csv
>>> Running package in textproc/xlsx2csv at 1455088824
===> textproc/xlsx2csv
===>  Faking installation for xlsx2csv-20150225p1
install -d -m 755 /usr/obj/ports/xlsx2csv-20150225/fake-amd64
cp /usr/obj/ports/xlsx2csv-20150225/go/bin/* 
/usr/obj/ports/xlsx2csv-20150225/fake-amd64/usr/local/bin
===>  Building package for xlsx2csv-20150225p1
Create /usr/ports/packages/amd64/all/xlsx2csv-20150225p1.tgz
Link to /usr/ports/packages/amd64/ftp/xlsx2csv-20150225p1.tgz
Link to /usr/ports/packages/amd64/cdrom/xlsx2csv-20150225p1.tgz
>>> Running clean in textproc/xlsx2csv at 1455088826
===> textproc/xlsx2csv
===>  Cleaning for xlsx2csv-20150225p1

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: alpha-1.ports.openbsd.org bulk build report

[Christian Weisgerber]

On 2016-02-09, Jonathan Gray  wrote:

> /usr/xenocara/lib/mesa/src/mesa/main/format_pack.c:6890: internal compiler 
> error: in extract_insn, at recog.c:2077

Our usual workaround for these types of errors is to compile the
affected source file (and only that file, and only on that arch)
without any optimization.  Did this still fail?

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: update: databases/pgbadger 3.5 to 7.3

[Abel Abraham Camarillo Ojeda]

On Mon, Feb 8, 2016 at 9:59 PM, Abel Abraham Camarillo Ojeda
 wrote:
> hi
>
> attached patch updates pgbadger,
> also I'd like to take maintainership if no one
> cares.
> I'm unsure about the PLIST change, tough...
>
> comments, ok?
>
> thanks.

anyone?

thanks

Re: update: databases/pgbadger 3.5 to 7.3

[Abel Abraham Camarillo Ojeda]

On Thu, Feb 11, 2016 at 12:22 AM, Michael McConville  wrote:
> Abel Abraham Camarillo Ojeda wrote:
>> On Mon, Feb 8, 2016 at 9:59 PM, Abel Abraham Camarillo Ojeda
>>  wrote:
>> > hi
>> >
>> > attached patch updates pgbadger,
>> > also I'd like to take maintainership if no one
>> > cares.
>> > I'm unsure about the PLIST change, tough...
>> >
>> > comments, ok?
>> >
>> > thanks.
>>
>> anyone?
>>
>> thanks
>
> We're in release mode as of a few days ago, so I don't think this will
> be committed until the release is cut and the tree is unlocked.
>
> Thanks for the contribution! Feel free to poke me if no one gets back to
> you after unlock.
>
> Michael

Oh, didn't noticed... thank you!

Update: sysutils/monit 5.16

[Bryce Chidester]

Update to sysutils/monit 5.16. Currently running in production on a number
of 5.8/amd64 system.
https://mmonit.com/monit/changes/

Regards,
Bryce Chidester
br...@cobryce.com


Index: distinfo
===
RCS file: /cvs/ports/sysutils/monit/distinfo,v
retrieving revision 1.28
diff -u -p -u -r1.28 distinfo
--- distinfo24 Oct 2015 11:16:28 -  1.28
+++ distinfo11 Feb 2016 05:55:32 -
@@ -1,2 +1,2 @@
-SHA256 (monit-5.15.tar.gz) = 3q2oFT3H6HVfVyvE15AUOpLHqGaNzLVjrk29c69WaXw=
-SIZE (monit-5.15.tar.gz) = 1218043
+SHA256 (monit-5.16.tar.gz) = W5mOeWETziRMi1ddoJ06YrrBsnZUhP5kFvIktLqPOR8=
+SIZE (monit-5.16.tar.gz) = 1226329
Index: Makefile
===
RCS file: /cvs/ports/sysutils/monit/Makefile,v
retrieving revision 1.43
diff -u -p -u -r1.43 Makefile
--- Makefile24 Oct 2015 11:16:28 -  1.43
+++ Makefile11 Feb 2016 05:55:32 -
@@ -2,7 +2,7 @@

 COMMENT=   monitoring and managing daemons utility

-DISTNAME=  monit-5.15
+DISTNAME=  monit-5.16

 CATEGORIES=sysutils

Re: alpha-1.ports.openbsd.org bulk build report

[Jonathan Gray]

On Thu, Feb 11, 2016 at 08:09:42AM +0100, Matthieu Herrb wrote:
> On Wed, Feb 10, 2016 at 08:32:51PM +, Christian Weisgerber wrote:
> > On 2016-02-09, Jonathan Gray  wrote:
> > 
> > > /usr/xenocara/lib/mesa/src/mesa/main/format_pack.c:6890: internal 
> > > compiler error: in extract_insn, at recog.c:2077
> > 
> > Our usual workaround for these types of errors is to compile the
> > affected source file (and only that file, and only on that arch)
> > without any optimization.  Did this still fail?
> > 
> 
> Yes that was the 1st thing I tried of course.
> 
> Juest retried to be sure:
> 
> /share/OpenBSD/xenocara/lib/mesa/src/glsl/glsl_parser_extras.cpp:1697: error: 
> unrecognizable insn:
> (insn 57 56 58 3 
> /share/OpenBSD/xenocara/lib/mesa/src/glsl/glsl_parser_extras.cpp:1583 (set 
> (reg:DI 188)
> (ashift:DI (zero_extend:DI (const_int 1 [0x1]))
> (ashift:DI (reg/f:DI 183)
> (const_int 3 [0x3] -1 (nil)
> (nil))
> /share/OpenBSD/xenocara/lib/mesa/src/glsl/glsl_parser_extras.cpp:1697: 
> internal compiler error: in extract_insn, at recog.c:2077
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> 
> 
> Looking closer this is an atomic sync operation:
> 
> 1582:   if (ctx->Const.GenerateTemporaryNames)
> 1583: (void) 
> p_atomic_cmpxchg(_variable::temporaries_allocate_names,
> 1584:false, true);
> 
> Anyone has an idea to implement support for this ?

p_atomic_cmpxchg comes from /usr/xenocara/lib/mesa/src/util/u_atomic.h

which turns out to be __sync_val_compare_and_swap((v), (old), (_new))

There are kludged non atomic versions I added for other archs
that lack sync instructions under PIPE_ATOMIC_UNLOCKED

perhaps you could that version on alpha?

#define p_atomic_cmpxchg(_v, old, _new) ({  \
__typeof(*_v) _r = *(_v);   \
if (*(_v) == old)   \
*(_v) = (_new); \
_r; \
})

Here is the u_atomic_test.c test file out of the mesa source with
u_atomic.h included.  Should be easier to test against.

/**
 *
 * Copyright 2014 VMware, Inc.
 * All Rights Reserved.
 *
 * Permission is hereby granted, free of charge, to any person obtaining a
 * copy of this software and associated documentation files (the
 * "Software"), to deal in the Software without restriction, including
 * without limitation the rights to use, copy, modify, merge, publish,
 * distribute, sub license, and/or sell copies of the Software, and to
 * permit persons to whom the Software is furnished to do so, subject to
 * the following conditions:
 *
 * The above copyright notice and this permission notice (including the
 * next paragraph) shall be included in all copies or substantial portions
 * of the Software.
 *
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
 * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
 * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
 * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
 * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
 * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 *
 **/


/* Force assertions, even on debug builds. */
#undef NDEBUG


#include 
#include 
#include 

/**
 * Many similar implementations exist. See for example libwsbm
 * or the linux kernel include/atomic.h
 *
 * No copyright claimed on this file.
 *
 */

#ifndef U_ATOMIC_H
#define U_ATOMIC_H

#include 

/* Favor OS-provided implementations.
 *
 * Where no OS-provided implementation is available, fall back to
 * locally coded assembly, compiler intrinsic or ultimately a
 * mutex-based implementation.
 */
#if defined(__sun)
#define PIPE_ATOMIC_OS_SOLARIS
#elif defined(_MSC_VER)
#define PIPE_ATOMIC_MSVC_INTRINSIC
#elif defined(__ARM_ARCH_4__) || defined(__ARM_ARCH_5__) || \
  defined(__hppa__) || defined(__sparc__) || defined(__sh__)
#define PIPE_ATOMIC_UNLOCKED
#elif defined(__GNUC__)
#define PIPE_ATOMIC_GCC_INTRINSIC
#else
#error "Unsupported platform"
#endif


/* Implementation using GCC-provided synchronization intrinsics
 */
#if defined(PIPE_ATOMIC_GCC_INTRINSIC)

#define PIPE_ATOMIC "GCC Sync Intrinsics"

#define p_atomic_set(_v, _i) (*(_v) = (_i))
#define p_atomic_read(_v) (*(_v))
#define p_atomic_dec_zero(v) (__sync_sub_and_fetch((v), 1) == 0)
#define p_atomic_inc(v) (void) __sync_add_and_fetch((v), 1)
#define p_atomic_dec(v) (void) __sync_sub_and_fetch((v), 1)
#define p_atomic_add(v, i) (void) __sync_add_and_fetch((v), (i))
#define p_atomic_inc_return(v) __sync_add_and_fetch((v), 1)
#define 

Re: alpha-1.ports.openbsd.org bulk build report

[Matthieu Herrb]

On Wed, Feb 10, 2016 at 08:32:51PM +, Christian Weisgerber wrote:
> On 2016-02-09, Jonathan Gray  wrote:
> 
> > /usr/xenocara/lib/mesa/src/mesa/main/format_pack.c:6890: internal compiler 
> > error: in extract_insn, at recog.c:2077
> 
> Our usual workaround for these types of errors is to compile the
> affected source file (and only that file, and only on that arch)
> without any optimization.  Did this still fail?
> 

Yes that was the 1st thing I tried of course.

Juest retried to be sure:

/share/OpenBSD/xenocara/lib/mesa/src/glsl/glsl_parser_extras.cpp:1697: error: 
unrecognizable insn:
(insn 57 56 58 3 
/share/OpenBSD/xenocara/lib/mesa/src/glsl/glsl_parser_extras.cpp:1583 (set 
(reg:DI 188)
(ashift:DI (zero_extend:DI (const_int 1 [0x1]))
(ashift:DI (reg/f:DI 183)
(const_int 3 [0x3] -1 (nil)
(nil))
/share/OpenBSD/xenocara/lib/mesa/src/glsl/glsl_parser_extras.cpp:1697: internal 
compiler error: in extract_insn, at recog.c:2077
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Looking closer this is an atomic sync operation:

1582:   if (ctx->Const.GenerateTemporaryNames)
1583: (void) p_atomic_cmpxchg(_variable::temporaries_allocate_names,
1584:  false, true);

Anyone has an idea to implement support for this ?

PS: I also had a look at trying to on;y build the indirect glx part of the
lib (since direct rendering part is useless without an X server, and
the error so far is in a file only used for direct rendering, but the
new Mesa build system doesn't provide support for that.


-- 
Matthieu Herrb


signature.asc
Description: PGP signature

Re: update: databases/pgbadger 3.5 to 7.3

[Michael McConville]

Abel Abraham Camarillo Ojeda wrote:
> On Mon, Feb 8, 2016 at 9:59 PM, Abel Abraham Camarillo Ojeda
>  wrote:
> > hi
> >
> > attached patch updates pgbadger,
> > also I'd like to take maintainership if no one
> > cares.
> > I'm unsure about the PLIST change, tough...
> >
> > comments, ok?
> >
> > thanks.
> 
> anyone?
> 
> thanks

We're in release mode as of a few days ago, so I don't think this will
be committed until the release is cut and the tree is unlocked.

Thanks for the contribution! Feel free to poke me if no one gets back to
you after unlock.

Michael

Re: alpha-1.ports.openbsd.org bulk build report

[Karel Gardas]

> It has been fixed upstream:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66140

looks like in 5.1.1 which is GPL3 so probably not usable to be merge
into the OpenBSD's GPL2 4.2.1? But well, I'm not the lawyer here i
just see two different licenses so it raises red flag here...

Re: www/xombrero Segmentation fault (core dumped) on macppc -current from Feb 8.

[Karel Gardas]

> would blow the same. No informations are needed, just someone brave (or
> foolish?) enough to pick up the ball and fix webkit on powerpc. I lost
> too many hours on this in the past and gave up.

I'm curious if the same happen on sparc64? i.e. maybe endianess issue
or if not, then directly ppc? If so, then if compiling xombrero with
new gcc/binutils helps or not?

Re: alpha-1.ports.openbsd.org bulk build report

[Stuart Henderson]

On 2016/02/10 10:57, Karel Gardas wrote:
> > It has been fixed upstream:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66140
> 
> looks like in 5.1.1 which is GPL3 so probably not usable to be merge
> into the OpenBSD's GPL2 4.2.1? But well, I'm not the lawyer here i
> just see two different licenses so it raises red flag here...
> 

We can't copy the patch directly. But it wouldn't be a big surprise
if given the description of the bug someone else came up with a
very similar diff though it would probably not have the whitespace
change that is also in it.

Problem is that get_aligned_mem() and get_unaligned_address() need
to look for replacements in memory addresses.

Re: Cant build subversion on OPENBSD_5_8

[Stuart Henderson]

On 2016/02/09 21:42, sven falempin wrote:
> Hello,
> 
> Sorry to inform you something is broken, looks these problem already
> happened
> a long time ago because of Build.pm regexp of version. I am not sure if it
> is iconv 0.2 ?
> Without the FLAVOR it ask iconv '6' and fail too.

I'm not sure what you have done to your system but you seem to be
having quite a few problems that don't really make sense and aren't
happening for other people.

> ===>  Verifying specs:  lib/db4/db>=4 expat pthread apr-1=5 iconv>=2
> Missing library for iconv>=2.0

Is /usr/local/lib/libiconv.so.6.0 present on your system?

Have you had any crashes which might have corrupted /var/db/pkg?
If so, run pkg_check.

Re: www/xombrero Segmentation fault (core dumped) on macppc -current from Feb 8.

[Landry Breuil]

On Wed, Feb 10, 2016 at 11:00:22AM +0100, Karel Gardas wrote:
> > would blow the same. No informations are needed, just someone brave (or
> > foolish?) enough to pick up the ball and fix webkit on powerpc. I lost
> > too many hours on this in the past and gave up.
> 
> I'm curious if the same happen on sparc64? i.e. maybe endianess issue
> or if not, then directly ppc? If so, then if compiling xombrero with
> new gcc/binutils helps or not?

sparc64 has different issues usually, more often alignment.

Landry

Re: www/xombrero Segmentation fault (core dumped) on macppc -current from Feb 8.

[Christoph R. Murauer]

> Webkit is broken on macppc since a good while, any browser using it
> would blow the same. No informations are needed, just someone brave
> (or
> foolish?) enough to pick up the ball and fix webkit on powerpc. I lost
> too many hours on this in the past and gave up.
>
> Landry
>
>

Not good but thanks for the information.

Re: www/xombrero Segmentation fault (core dumped) on macppc -current from Feb 8.

[Landry Breuil]

On Wed, Feb 10, 2016 at 09:06:29AM +0100, Christoph R. Murauer wrote:
> > Webkit is broken on macppc since a good while, any browser using it
> > would blow the same. No informations are needed, just someone brave
> > (or
> > foolish?) enough to pick up the ball and fix webkit on powerpc. I lost
> > too many hours on this in the past and gave up.
> >
> > Landry
> >
> >
> 
> Not good but thanks for the information.

If you want a 'graphical and user-friendly web browser' on macppc, try
www/netsurf. That's the only viable option (besides
dillo/links/lynx/etc..) - using it daily there.

Landry

Re: Cant build subversion on OPENBSD_5_8

[Stefan Sperling]

On Tue, Feb 09, 2016 at 09:42:18PM -0500, sven falempin wrote:
> # make install
> ===>  Checking files for apr-util-1.5.4p0
> `/usr/ports/distfiles/apr-util-1.5.4.tar.gz' is up to date.
> >> (SHA256) apr-util-1.5.4.tar.gz: OK
> ===>  Verifying specs:  lib/db4/db>=4 expat pthread apr-1=5 iconv>=2
> Missing library for iconv>=2.0
> Fatal error
> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2229
> '/usr/ports/pobj/apr-util-1.5.4/.buildwantlibs')
> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2575
> '/usr/ports/pobj/apr-util-1.5.4/.extract_done')
> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:1952
> '/usr/ports/packages/amd64/all/apr-util-1.5.4p0.tgz')
> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2508
> '_internal-package')
> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2488 'package')
> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:1969
> '/var/db/pkg/apr-util-1.5.4p0/+CONTENTS')
> *** Error 1 in /usr/ports/devel/apr-util (/usr/ports/infrastructure/mk/
> bsd.port.mk:2488 'install')

Works for me:

$ make
===> apr-util-1.5.4p0 depends on: metaauto-* -> metaauto-1.0p1
===> apr-util-1.5.4p0 depends on: autoconf-2.68 -> autoconf-2.68p0
===> apr-util-1.5.4p0 depends on: db->=4,<5|db->=4v0,<5v0 -> db-4.6.21p1v0
===> apr-util-1.5.4p0 depends on: apr-* -> apr-1.5.2
===> apr-util-1.5.4p0 depends on: libiconv-* -> libiconv-1.14p3
===>  Verifying specs:  lib/db4/db>=4 expat pthread apr-1=5 iconv>=2
===>  found lib/db4/db.5.0 expat.11.0 pthread.19.0 apr-1.5.0 iconv.6.0
===>  Checking files for apr-util-1.5.4p0
`/usr/ports/distfiles/apr-util-1.5.4.tar.gz' is up to date.
>> (SHA256) apr-util-1.5.4.tar.gz: OK
===>  Extracting for apr-util-1.5.4p0
===>  Patching for apr-util-1.5.4p0
>>> Can't find autoconf 2.68 signature in 
>>> /usr/ports/pobj/apr-util-1.5.4/apr-util-1.5.4/configure:
# Generated by GNU Autoconf 2.69.
generated by GNU Autoconf 2.69
generated by GNU Autoconf 2.69.  Invocation command line was
generated by GNU Autoconf 2.69.  Invocation command line was
configured by $0, generated by GNU Autoconf 2.69,
Running autoconf-2.68 in /usr/ports/pobj/apr-util-1.5.4/apr-util-1.5.4
Running autoheader-2.68 in /usr/ports/pobj/apr-util-1.5.4/apr-util-1.5.4
===>  Configuring for apr-util-1.5.4p0
Using /usr/ports/pobj/apr-util-1.5.4/config.site (generated)
configure: WARNING: unrecognized options: --disable-silent-rules, 
--disable-gtk-doc
configure: loading site script /usr/ports/pobj/apr-util-1.5.4/config.site
checking build system type... x86_64-unknown-openbsd5.8
checking host system type... x86_64-unknown-openbsd5.8
checking target system type... x86_64-unknown-openbsd5.8
checking for a BSD-compatible install... 
/usr/ports/pobj/apr-util-1.5.4/bin/install -c 
checking for working mkdir -p... yes
APR-util Version: 1.5.4
checking for chosen layout... apr-util

and so on...

Re: www/xombrero Segmentation fault (core dumped) on macppc -current from Feb 8.

[Christoph R. Murauer]

> On Wed, Feb 10, 2016 at 09:06:29AM +0100, Christoph R. Murauer wrote:
>> > Webkit is broken on macppc since a good while, any browser using
>> it
>> > would blow the same. No informations are needed, just someone
>> brave
>> > (or
>> > foolish?) enough to pick up the ball and fix webkit on powerpc. I
>> lost
>> > too many hours on this in the past and gave up.
>> >
>> > Landry
>> >
>> >
>>
>> Not good but thanks for the information.
>
> If you want a 'graphical and user-friendly web browser' on macppc, try
> www/netsurf. That's the only viable option (besides
> dillo/links/lynx/etc..) - using it daily there.
>
> Landry
>
>

True, tried browsers ... netsurf is the only working GUI browser.

Re: sox can't record audio with 24-bits precision

[Comète]

9 février 2016 23:40 "Alexandre Ratchov"  a écrit:
> On Tue, Feb 09, 2016 at 10:24:47AM +, Comète wrote:
> 
>> Hi,
>> 
>> i'm using openbsd 5.8 amd64 stable. I'm trying to record audio
>> with 24-bits precision with sox and it seems to be impossible:
>> 
>> rec -t flac -c 2 -r 48000 -b 24 test.flac
>> 
>> Input File : 'default' (sndio)
>> Channels : 2
>> Sample Rate : 48000
>> Precision : 32-bit
>> Sample Encoding: 32-bit Signed Integer PCM
>> 
>> In:0.00% 00:00:16.90 [00:00:00.00] Out:807k [ | ] Clip:0
>> 
>> It is always encoded with 32-bits precision, but if i try
>> specifying 16 instead of 24, it is well encoded in 16 bits.
> 
> This should fix the problem. If bits_per_sample is set, then use
> it to configure sndiod; otherwise, pick a value close to precision
> or the default sox precision.
> 
> OK?
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/audio/sox/Makefile,v
> retrieving revision 1.63
> diff -u -p -u -p -r1.63 Makefile
> --- Makefile 12 Dec 2015 08:17:34 - 1.63
> +++ Makefile 9 Feb 2016 22:24:19 -
> @@ -5,6 +5,7 @@ BROKEN-hppa = bend.c:155:12: internal co
> COMMENT= Sound eXchange, the Swiss Army knife of audio manipulation
> 
> DISTNAME= sox-14.4.2
> +REVISION= 0
> SHARED_LIBS += sox 4.0 # 3.0
> 
> CATEGORIES= audio
> Index: patches/patch-src_sndio_c
> ===
> RCS file: patches/patch-src_sndio_c
> diff -N patches/patch-src_sndio_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-src_sndio_c 9 Feb 2016 22:24:19 -
> @@ -0,0 +1,25 @@
> +$OpenBSD$
> +--- src/sndio.c.orig Mon Jan 30 04:01:44 2012
>  src/sndio.c Tue Feb 9 23:23:00 2016
> +@@ -113,8 +113,6 @@ static int startany(sox_format_t *ft, unsigned mode)
> + else
> + reqpar.rchan = ft->signal.channels;
> + }
> +- if (ft->signal.precision > 0)
> +- reqpar.bits = ft->signal.precision;
> + switch (ft->encoding.encoding) {
> + case SOX_ENCODING_SIGN2:
> + reqpar.sig = 1;
> +@@ -127,6 +125,12 @@ static int startany(sox_format_t *ft, unsigned mode)
> + }
> + if (ft->encoding.bits_per_sample > 0)
> + reqpar.bits = ft->encoding.bits_per_sample;
> ++ else if (ft->signal.precision > 0)
> ++ reqpar.bits = ft->signal.precision;
> ++ else
> ++ reqpar.bits = SOX_DEFAULT_PRECISION;
> ++ reqpar.bps = (reqpar.bits + 7) / 8;
> ++ reqpar.msb = 1;
> + if (ft->encoding.reverse_bytes != sox_option_default) {
> + reqpar.le = SIO_LE_NATIVE;
> + if (ft->encoding.reverse_bytes)


Thanks ! I will try this and give feedback.

Morgan

CVS: cvs.openbsd.org: ports

[Vadim Zhukov]

CVSROOT:/cvs
Module name:ports
Changes by: z...@cvs.openbsd.org2016/02/10 06:12:23

Modified files:
x11/qt4: Makefile 
Added files:
x11/qt4/patches: 
 patch-src_network_socket_qnativesocketengine_unix_cpp 

Log message:
Fix stack smashing happening when Qt4-based program opens more than
FD_SETSIZE (1024 by default) file descriptors. This is often the case
for KDE4 apps when using libinotify as directory monitoring backend.

Positive feedback from deraadt@, final okay sthen@