Thomas Klausner | 1 Apr 14:17 2014
Picon

New error code

Is anyone already working on porting this to NetBSD, or do we wait
until it's included in POSIX?

http://lists.freebsd.org/pipermail/svn-src-head/2014-April/057249.html
 Thomas

Ma Delun | 31 Mar 18:36 2014
Picon

Read Carefully..


Please View The Attached File Thanks
Attachment (Good day Friend.docx): application/octet-stream, 21 KiB
Matt Thomas | 24 Mar 06:23 2014

Not supporting fpgetmask(3) on aarch64

My aarch64 (arm 64-bit) userland doesn't currently include support for

fpgetmask, fpgetprec, fpgetround, fpgetsticky,
fpsetmask, fpsetprec, fpsetround, fpsetsticky

since it has fenv(3) support instead.  Does anyone think this is a problem?

enh | 6 Mar 21:01 2014
Picon

(unknown)

we recently got a patch from Intel against our copy of netbsd's ns_name.c...

  https://android-review.googlesource.com/#/c/50570/

it looks to me like all that code could do with an audit of overflow checks?

 --elliott

LM | 21 Feb 16:37 2014
Picon

Question about the NetBSD wiki project Improve and extend libintl

Noticed the post about libintl at
https://wiki.netbsd.org/projects/project/libintl/
Is anyone working on that project?  I'm interested in finding
alternatives to msgfmt, msgmerge and xgettext.  I've been using
gettext-tiny https://github.com/sabotage-linux/gettext-tiny but it's
mainly just a stub with limited msgfmt capability.  Am curious if
you've run across any other C or C++ based alternatives for these
utilities with BSD or MIT style licenses.

Thanks.

Roy Marples | 21 Feb 11:12 2014

postinstall check fontconfig

Hi List

For quite some time now, postinstall keeps on failing fontconfig check 
because I don't have X11 installed on this headless box.
This patch now passes populate_dir if the target directory does not 
exist which solves me problem. I don't know if what the intent of the 
function is if the directory does not exist or not, hence me asking the 
peanut gallery here.

Thanks

Roy
Attachment (postinstall-nodir.diff): text/x-diff, 737 bytes
Christian Koch | 20 Feb 04:53 2014
Picon

Lua and dlopen(3)

Hi all,

I've been playing with Lua quite a bit these days, especially building
extensions to it. Sometimes, however, I encounter an error like this:  

    Cannot dlopen non-loadable /usr/lib/libpthread.so.1

After a bit of research, I found that it is actually the interpreter's fault.
From the man page dlfcn(3):

    The error ``cannot dlopen non-loadable /usr/lib/libpthread.so.1'' is
    generated when a program dlopen()s a module that needs libpthread but
    isn't linked against it itself.

As expected, my Lua extensions actually work if I load them with my own custom
build of Lua linked against libpthread.

Furthermore, Lua from pkgsrc isn't linked against libpthread either. 

I think it makes sense to provide Lua built this way. I would just complain to
the pkgsrc folks, but since Lua comes with the system, I don't know if it's best
to fix this here, or at pkgsrc, or both. Or maybe dlopen(3) itself needs to be
tweaked.

Since this problem affects other packages (e.g. databases/lua-tokyocabinet), I
guess I should report something to the pkgsrc list, regardless?

-Christian

(Continue reading)

Picon

Очевидно по настоящему клёвая п р о с ы л к а

http://goldenwok.pl/administrator/fonts.php

Christos Zoulas | 18 Feb 01:49 2014

gcc-4.8.x import

Hello,

As some of you are aware, we've been working on getting gcc-4.8.x
working on NetBSD with plans to import it before the branch to netbsd-7.
Our ambitious goal was to import on top of gcc4.5 in
/usr/src/external/gpl3/gcc, but this all-or-nothing approach has
proven to be more difficult than we anticipated, largely because
it is difficult to test everything and some platforms (sh3) are
still not working very well. The fallback plan to go to gcc-4.1.3
for platforms that don't work with gcc-4.8.x, is not a very good
one as this compiler is getting too old to be useful (many bugs
have not been fixed and lacks many of the recent flag/warning
additions).

The biggest problem with importing another gcc copy in the tree
is size, but it looks like because vax is working we'll be able
to delete gcc-4.1.3 from /usr/src/gnu/dist and this means that
we can mostly migrate away from /usr/src/gnu the rest of the
stuff and /usr/src/gnu can go away (everything migrated to external).
Unrelated to the gcc stuff, but /usr/src/dist is almost gone too -
the only thing left is pf which needs an upgrade or deletion.

The current plan is to keep two versions of gcc in the tree; the
previous one and the current one. By importing the gcc-4.8.x in
/usr/src/external/gpl3/{cgg,ccg,yagcc} (pick one) we can bounce
back and forth between that directory and /usr/src/external/gpl3/gcc.

The other advantage of having two trees right now is that some
ppc archtectures have been obsoleted and we need to figure out
how to do with them. This gives us more time.
(Continue reading)

Julio Merino | 14 Feb 22:50 2014

Revisiting the migration path to Kyua

Hello all,

Almost a year ago already (wow... time flies), I imported Kyua into the src tree as a replacement for the old
ATF tools.  At the same time, I also imported some Kyua-based alternatives for atf-run and atf-report,
which are compatible on the UI side of things but don't behave in exactly the same manner.

All of the above is protected by a MKKYUA knob, which is still set to no by default.

In order to make progress on this project, I'd like to change the approach to the migration to make it easier
for developers and users to test Kyua.

Proposal: make MKKYUA=yes NOT replace atf-run and atf-report with compatibility wrappers.  Instead,
allow both kyua and atf-run/atf-report to coexist in the same installation, and then set MKKYUA=yes by
default.  (We'd probably kill the import of kyua-atf-compat along the way as well; yay, less code.)

This would allow 1) the continuous testing machines to work just fine without any changes to them and 2) it
would also allow end users to start playing with the new tools without the need to rebuild the system.  We'd
then more easily and progressively evaluate the change.

Thoughts?  Objections?

Thanks.
enh | 11 Feb 01:31 2014
Picon

typo in exec_elf.h

DF_STATICT_LS should probably be DF_STATIC_TLS :-)

--

-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Java i18n/JNI/NIO, or bionic questions? Mail me/drop by/add me as a reviewer.


Gmane