amd64 SBCs on which NetBSD would run ?

2019-05-03 Thread Mayuresh
I am using RPI2 with NetBSD for a certain requirement. There are some
rough edges (wifi support, usb hub not working, media player not working
etc.) Besides it's too slow to do any builds of pkgsrc.

Was wondering whether there are SBC boards where I can use my amd64
packages compiled on other devices. The board itself need not have a high
end configuration (RPI like configuration is good enough) - just that
NetBSD should work on it and it should have amd64 arch.

Tried searching, but most SBCs seem arm based. Among those that are amd64
based it's hard to figure out whether NetBSD would support it.

Please do share recommendations / experiences.

Mayuresh


BFD .. invalid string offset .. for section `.strtab'

2019-05-03 Thread Mayuresh
# uname -a
NetBSD pi 8.99.37 NetBSD 8.99.37 (RPI2) #1: Thu Apr 25 16:01:51 UTC 2019
root@pi:/usr/src/sys/arch/evbarm/compile/RPI2 evbarm


BFD: /usr/pkg/lib/libpango-1.0.so.0: invalid string offset 12338 >= 11106 for 
section `.strtab'
BFD: /usr/pkg/lib/libfribidi.so.0: invalid string offset 1447 >= 1158 for 
section `.strtab'

BFD: /usr/pkg/lib/libfribidi.so.0: invalid string offset 1652 >= 1158 for 
section `.strtab'
Core was generated by `netsurf-gtk'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x698315f0 in memcpy () from /usr/lib/libc.so.12
[Current thread is 1 (process 1)]
(gdb) where
#0  0x698315f0 in memcpy () from /usr/lib/libc.so.12
#1  0x000d9888 in __memcpy_ichk (len=, src=, 
dst=0x7fe8ef34) at /usr/include/ssp/string.h:82
#2  curl_start_cert_validate (certs=certs@entry=0x7fe906e0, f=, 
f=) at content/fetchers/curl.c:967
#3  0x000d9f20 in fetch_curl_done (result=CURLE_PEER_FAILED_VERIFICATION, 
curl_handle=) at content/fetchers/curl.c:1132
#4  fetch_curl_poll (scheme_ignored=) at 
content/fetchers/curl.c:1223
#5  0x000d6474 in fetch_fdset (read_fd_set=read_fd_set@entry=0x7fe907a8, 
write_fd_set=write_fd_set@entry=0x7fe907c8, 
except_fd_set=except_fd_set@entry=0x7fe907e8, 
maxfd_out=maxfd_out@entry=0x7fe907a4) at content/fetch.c:404
#6  0x00183bc0 in nsgtk_main () at frontends/gtk/gui.c:404
#7  0x002325e0 in main (argc=, argv=) at 
frontends/gtk/gui.c:1206

Above trace occurred on netsurf core dump.

There is a long chain of the "BFD:" errors on various libraries, only 2-3
samples of that are attached above.

I think during build of the packages I had seen those errors as well, but
not sure.

Please advise.

Mayuresh


Re: pkgsrc python default version -> 3.7

2019-05-03 Thread coypu
On Fri, May 03, 2019 at 12:48:42PM +0100, Sad Clouds wrote:
> On Fri, 3 May 2019 11:32:32 +
> co...@sdf.org wrote:
> 
> > On Fri, May 03, 2019 at 12:10:30PM +0100, Sad Clouds wrote:
> > > On Fri, 3 May 2019 11:02:49 +
> > > co...@sdf.org wrote:
> > > 
> > > > I'm not sure it's a good idea to apply that patch, though.
> > > > fixing util-linux is probably the right thing.
> > > 
> > > Solaris seems to have its own libuuid, can python use that instead?
> > 
> > The logic for searching for a util-linux style libuuid (as opposed to
> > the DCE standard uuid) isn't OS specific. if it doesn't pick it up it
> > probably doesn't like something about it...
> > 
> > it looks for util_generate in uuid/uuid.
> 
> Solaris man pages list the following, so no util_generate
> 
> INTERFACES
>The shared object libuuid.so.1 provides the public  interfaces
> defined below.  See Intro(3) for additional information on shared
> object inter- faces.
> 
>uuid_clearuuid_compare
>uuid_copy uuid_generate
>uuid_generate_random  uuid_generate_time
>uuid_is_null  uuid_parse
>uuid_time uuid_unparse
> 
> FILES
>/lib/libuuid.so.1   shared object
> 
>/lib/64/libuuid.so.164-bit shared object

Sorry, that's a typo, it looks for uuid_generate


Re: pkgsrc python default version -> 3.7

2019-05-03 Thread Sad Clouds
On Fri, 3 May 2019 11:32:32 +
co...@sdf.org wrote:

> On Fri, May 03, 2019 at 12:10:30PM +0100, Sad Clouds wrote:
> > On Fri, 3 May 2019 11:02:49 +
> > co...@sdf.org wrote:
> > 
> > > I'm not sure it's a good idea to apply that patch, though.
> > > fixing util-linux is probably the right thing.
> > 
> > Solaris seems to have its own libuuid, can python use that instead?
> 
> The logic for searching for a util-linux style libuuid (as opposed to
> the DCE standard uuid) isn't OS specific. if it doesn't pick it up it
> probably doesn't like something about it...
> 
> it looks for util_generate in uuid/uuid.

Solaris man pages list the following, so no util_generate

INTERFACES
   The shared object libuuid.so.1 provides the public  interfaces
defined below.  See Intro(3) for additional information on shared
object inter- faces.

   uuid_clearuuid_compare
   uuid_copy uuid_generate
   uuid_generate_random  uuid_generate_time
   uuid_is_null  uuid_parse
   uuid_time uuid_unparse

FILES
   /lib/libuuid.so.1   shared object

   /lib/64/libuuid.so.164-bit shared object



Re: pkgsrc python default version -> 3.7

2019-05-03 Thread coypu
On Fri, May 03, 2019 at 12:10:30PM +0100, Sad Clouds wrote:
> On Fri, 3 May 2019 11:02:49 +
> co...@sdf.org wrote:
> 
> > I'm not sure it's a good idea to apply that patch, though.
> > fixing util-linux is probably the right thing.
> 
> Solaris seems to have its own libuuid, can python use that instead?

The logic for searching for a util-linux style libuuid (as opposed to the
DCE standard uuid) isn't OS specific. if it doesn't pick it up it
probably doesn't like something about it...

it looks for util_generate in uuid/uuid.


Re: pkgsrc python default version -> 3.7

2019-05-03 Thread Sad Clouds
On Fri, 3 May 2019 11:02:49 +
co...@sdf.org wrote:

> I'm not sure it's a good idea to apply that patch, though.
> fixing util-linux is probably the right thing.

Solaris seems to have its own libuuid, can python use that instead?



Re: pkgsrc python default version -> 3.7

2019-05-03 Thread coypu
I'm not sure it's a good idea to apply that patch, though.
fixing util-linux is probably the right thing.


Re: pkgsrc python default version -> 3.7

2019-05-03 Thread Sad Clouds
On Fri, 3 May 2019 10:17:03 +
co...@sdf.org wrote:

> On Fri, May 03, 2019 at 07:30:54AM +0100, Sad Clouds wrote:
> > This totally fails on SPARC Solaris 11.3, due to util-linux where
> > random_get_bytes() conflicts with Solaris own function. Why does
> > Python depend on all these Linux packages? Not that I care that
> > much about Python, but it seems you can't build anything without
> > installing Perl and Python as well.
> 
> it can handle non libuuid-uuid implementation, too.
> but it will try to link libuuid if it's available.
> 
> maybe we want:
> 
> Index: Makefile
> ===
> RCS file: /cvsroot/pkgsrc/lang/python37/Makefile,v
> retrieving revision 1.8
> diff -u -r1.8 Makefile
> --- Makefile  30 Apr 2019 04:49:38 -  1.8
> +++ Makefile  3 May 2019 10:15:08 -
> @@ -4,6 +4,7 @@
>  
>  PKGNAME= python37-${PY_DISTVERSION}
>  CATEGORIES=  lang python
> +PKGREVISION= 1
>  
>  MAINTAINER=  pkgsrc-us...@netbsd.org
>  HOMEPAGE=https://www.python.org/
> @@ -170,13 +171,22 @@
>   ${DESTDIR}${PREFIX}/lib/libpython3.7.sl.1.0
>  .endif
>  
> +.if ${OPSYS} == "FreeBSD" || ${OPSYS} == "OpenBSD" ||
> \
> + ${OPSYS} == "DragonFly" || ${OPSYS} == "SunOS" ||   \
> + ${OPSYS} == "NetBSD" || ${OPSYS} == "Darwin"
> ||\
> + ${OPSYS} == "AIX"
> +# uuid functionality in libc, avoid detecting libuuid if installed
> +BUILDLINK_TRANSFORM+=rm:-luuid
> +.else
> +.include "../../devel/libuuid/buildlink3.mk"
> +.endif
> +
>  BUILDLINK_DEPMETHOD.readline=build
>  
>  .include "../../archivers/bzip2/buildlink3.mk"
>  .include "../../archivers/xz/buildlink3.mk"
>  .include "../../devel/gettext-lib/buildlink3.mk"
>  .include "../../devel/libffi/buildlink3.mk"
> -.include "../../devel/libuuid/buildlink3.mk"
>  .include "../../devel/readline/buildlink3.mk"
>  .include "../../devel/zlib/buildlink3.mk"
>  BUILDLINK_API_DEPENDS.openssl+=  openssl>=1.0.2
> 

OK if there is no hard requirement for libuuid, let me try without it
and I'll let you know how far I get.



Re: pkgsrc python default version -> 3.7

2019-05-03 Thread coypu
libuuid is a mess. I can't tell how many different variants of the the
library exists. we apparently know how to pick up the OS X one as a
builtin always, because we will look for uuid_generate on uuid.h.

but in this case, it doesn't need uuid_generate...


Re: pkgsrc python default version -> 3.7

2019-05-03 Thread coypu
On Fri, May 03, 2019 at 07:30:54AM +0100, Sad Clouds wrote:
> This totally fails on SPARC Solaris 11.3, due to util-linux where
> random_get_bytes() conflicts with Solaris own function. Why does Python
> depend on all these Linux packages? Not that I care that much about
> Python, but it seems you can't build anything without installing
> Perl and Python as well.

it can handle non libuuid-uuid implementation, too.
but it will try to link libuuid if it's available.

maybe we want:

Index: Makefile
===
RCS file: /cvsroot/pkgsrc/lang/python37/Makefile,v
retrieving revision 1.8
diff -u -r1.8 Makefile
--- Makefile30 Apr 2019 04:49:38 -  1.8
+++ Makefile3 May 2019 10:15:08 -
@@ -4,6 +4,7 @@
 
 PKGNAME=   python37-${PY_DISTVERSION}
 CATEGORIES=lang python
+PKGREVISION=   1
 
 MAINTAINER=pkgsrc-us...@netbsd.org
 HOMEPAGE=  https://www.python.org/
@@ -170,13 +171,22 @@
${DESTDIR}${PREFIX}/lib/libpython3.7.sl.1.0
 .endif
 
+.if ${OPSYS} == "FreeBSD" || ${OPSYS} == "OpenBSD" ||  \
+   ${OPSYS} == "DragonFly" || ${OPSYS} == "SunOS" ||   \
+   ${OPSYS} == "NetBSD" || ${OPSYS} == "Darwin" || \
+   ${OPSYS} == "AIX"
+# uuid functionality in libc, avoid detecting libuuid if installed
+BUILDLINK_TRANSFORM+=  rm:-luuid
+.else
+.include "../../devel/libuuid/buildlink3.mk"
+.endif
+
 BUILDLINK_DEPMETHOD.readline=  build
 
 .include "../../archivers/bzip2/buildlink3.mk"
 .include "../../archivers/xz/buildlink3.mk"
 .include "../../devel/gettext-lib/buildlink3.mk"
 .include "../../devel/libffi/buildlink3.mk"
-.include "../../devel/libuuid/buildlink3.mk"
 .include "../../devel/readline/buildlink3.mk"
 .include "../../devel/zlib/buildlink3.mk"
 BUILDLINK_API_DEPENDS.openssl+=openssl>=1.0.2



Re: pkgsrc python default version -> 3.7

2019-05-03 Thread Sad Clouds
On Wed, 24 Apr 2019 22:31:36 +
co...@sdf.org wrote:

> Hi folks,
> 
> The default Python version in pkgsrc is now 3.7, in preparation for
> the coming end of life date of Python 2.7 (the previous default) at
> the end of this year.
> 
> This means any package that can be built with Python 3.7 will be built
> with it, rather than Python 2.7.
> Packages with no Python 3.x support will continue to be built with
> Python 2.7.
> 
> Problems are not likely to occur as many developers have been using
> this default for a while.
> Let me know if there are any problems still.
> 
> To undo this change, if you have a need for it, add this line to your
> /etc/mk.conf:
> PYTHON_VERSION_DEFAULT=27
> 
> For binary packages named pyXX-packagename, a python 2.7 will still be
> built (py27-packagename), as well as all the other python versions
> available.

This totally fails on SPARC Solaris 11.3, due to util-linux where
random_get_bytes() conflicts with Solaris own function. Why does Python
depend on all these Linux packages? Not that I care that much about
Python, but it seems you can't build anything without installing
Perl and Python as well.

===> Building for libuuid-2.32.1
/opt/pkg/bin/bmake  all-recursive
Making all in po
  CC   lib/libuuid_la-randutils.lo
In file included from lib/randutils.c:29:
/usr/include/sys/random.h:71:12: error: conflicting types for
'random_get_bytes' extern int random_get_bytes(uint8_t *dbuf, size_t
dlen); ^~~~
In file included from lib/randutils.c:19:
./include/randutils.h:14:13: note: previous declaration of
'random_get_bytes' was here extern void random_get_bytes(void *buf,
size_t nbytes); ^~~~
*** [lib/libuuid_la-randutils.lo] Error code 1

bmake[2]: stopped
in /opt/pkgbuild/objects/devel/libuuid/work/util-linux-2.32.1 1 error

bmake[2]: stopped
in /opt/pkgbuild/objects/devel/libuuid/work/util-linux-2.32.1 ***
[all-recursive] Error code 1

bmake[1]: stopped
in /opt/pkgbuild/objects/devel/libuuid/work/util-linux-2.32.1 1 error

bmake[1]: stopped
in /opt/pkgbuild/objects/devel/libuuid/work/util-linux-2.32.1 *** [all]
Error code 2

bmake: stopped
in /opt/pkgbuild/objects/devel/libuuid/work/util-linux-2.32.1 1 error

bmake: stopped
in /opt/pkgbuild/objects/devel/libuuid/work/util-linux-2.32.1 *** Error
code 2

Stop.
bmake[4]: stopped in /opt/pkgbuild/pkgsrc/devel/libuuid
*** Error code 1

Stop.
bmake[3]: stopped in /opt/pkgbuild/pkgsrc/devel/libuuid
*** Error code 1

Stop.
bmake[2]: stopped in /opt/pkgbuild/pkgsrc/lang/python37
*** Error code 1

Stop.
bmake[1]: stopped in /opt/pkgbuild/pkgsrc/devel/glib2-tools
*** Error code 1

Stop.
bmake: stopped in /opt/pkgbuild/pkgsrc/wm/windowmaker