Kamil Rytarowski | 22 Jun 09:28 2015
Picon

The <signal.h> header shall define the timespec structure as described in <time.h>

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html says:
'The <signal.h> header shall define the timespec structure as described
in <time.h>.'

For the following code:
#include <signal.h>
struct timespec ts;
int main(){}

I get:
error: storage size of ‘ts’ isn’t known
 struct timespec ts;

I added <sys/time.h> to <sys/siginfo.h>  to follow
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/sys/siginfo.h.diff?r1=1.5&r2=1.6&f=h

Is this change ok?

Index: sys/sys/siginfo.h
===================================================================
RCS file: /cvsroot/src/sys/sys/siginfo.h,v
retrieving revision 1.25
diff -u -r1.25 siginfo.h
--- sys/sys/siginfo.h	22 Nov 2013 21:04:11 -0000	1.25
+++ sys/sys/siginfo.h	22 Jun 2015 07:25:46 -0000
 <at>  <at>  -34,6 +34,7  <at>  <at> 

 #include <machine/signal.h>
 #include <sys/featuretest.h>
+#include <sys/time.h>
(Continue reading)

carsten.kunze | 9 Jun 16:51 2015
Picon

Aw: Re: Heirloom Troff for NetBSD (was: Removing ARCNET stuffs)

"James K. Lowden" <jklowden <at> schemamania.org> wrote:

> I didn't know Heirloom Troff produces PDFs directly, a feature I think
> is very valuable.  In that case, is there any reason not to substitute
> it for groff, apart from some engineering work and possibly some
> touch-up to a few documents?  

It does product PDF directly, if you pipe the output of dpost(1) to e.g. "ps2pdf - <PDF filename>" :-)

But it can put additional information for the PDF generation into the PS document with the pdfmark
operator.  This way e.g. hyperlinks and also bookmarks can be included (the table of contents that PDF
viewers show on the left side).  So the result has the features which had been addressed in this thread.  I
usually don't generate a PS document (but use the pipe to ps2pdf) because of the size of PS files.

Drawback is that ghostscript has a GNU license.

Carsten

carsten.kunze | 8 Jun 23:12 2015
Picon

Re: mom macors with heirloom-doctools

Hi Gerard,

> Can Peter Schaffter's mom macros[1] for groff be used with heirloom
> troff? These macros turned groff into a much more user-friendly and
> powerful typesetting system. The advantage of heirloom troff is that it
> does paragraph-at-once formatting while groff is still restricted to
> line-at-once formatting. Being able to use the mom macros in heirloom
> troff would make for a powerful combination. A tiny memory footprint
> producing documents almost on a par with those output by the much
> bigger TeX (Thierry Laronde's KerTex excepted, of course!).

I found the mail thread [1] where Gunnar confirms that -mom works with
heirloom troff.  Or at least had worked.  Peter had updated the macros
to few new groff features which are not yet in heirloom.  But it seems to
be not too complicated to add them.  And Peter agrees to give support
for his macros for the integration if needed.

Currently there is much work to do on heirloom troff becase of
requests from FreeBSD developers, but when this is done I'm going to
test compatibility with the mom macros.

Carsten

[1] http://lists.gnu.org/archive/html/groff/2008-01/msg00022.html

Frank Wille | 1 Jun 12:16 2015
Picon

slow multiuser boot

Hi,

some weeks ago I noticed that the rc-controlled multiuser boot in netbsd-7
and current has become very slow, which especially affects smaller single-
CPU platforms.

I think that much of the problem comes from the workaround for PR 48714,
which introduces a background process in rc, which sends a "nop" every
three seconds. Removing this passage from rc:

--- rc.orig     2015-01-16 22:17:31.000000000 +0100
+++ rc  2015-05-31 14:47:06.000000000 +0200
 <at>  <at>  -120,24 +120,6  <at>  <at> 
        kill -0 $RC_PID >/dev/null 2>&1 || RC_PID=$$

        #
-       # As long as process $RC_PID is still running, send a "nop"
-       # metadata message to the postprocessor every few seconds.
-       # This should help flush partial lines that may appear when
-       # rc.d scripts that are NOT marked with "KEYWORD: interactive"
-       # nevertheless attempt to print prompts and wait for input.
-       #
-       (
-           # First detach from tty, to avoid intercepting SIGINFO.
-           eval "exec ${_rc_original_stdout_fd}<&-"
-           eval "exec ${_rc_original_stderr_fd}<&-"
-           exec </dev/null >/dev/null 2>&1
-           while kill -0 $RC_PID ; do
-               print_rc_metadata "nop"
-               sleep 3
(Continue reading)

William Orr | 1 Jun 08:21 2015

gettext(1) implementation

Hey,

For testing some of my changes, I ended up writing a BSD-licensed gettext(1)
implementation. I'm not sure how useful people will find it, but I found it
very useful for testing gettext extraction.

Currently, I've implemented the same features that exist in the GNU gettext(1)
command. I'm thinking of adding more (easier message context support, for one)
if this gets merged.

Thanks,
William Orr

William Orr | 23 May 17:51 2015

libintl updates

Hey,

Here is some of my initial work on updating libintl. The first two patches are
small updates that remove some extraneous NULL checks. The third adds the
gettext functions that take a context argument to libintl, as detailed in
https://www.gnu.org/software/gettext/manual/gettext.html#Contexts

Let me know what I need to fix up.

Thanks,
William Orr

Pierre Pronchery | 21 May 12:30 2015

Buffering in standard streams

		Hi tech-userlevel <at> ,

I just read this nice article from a coreutils maintainer:
http://www.pixelbeat.org/programming/stdio_buffering/

After detailing issues about buffering and pipes, it mentions a tool,
stdbuf(1), which was introduced in coreutils and then imported to
FreeBSD (since 8.4).

Do we want this too?
http://www.unix.com/man-page/freebsd/1/stdbuf/

HTH,
--

-- 
khorben

William Orr | 19 May 08:42 2015

libintl updates

Hey,

I've started working on an update to libintl. Currently, I've 
implemented the new functions/macros that were added in GNU gettext that 
take a context argument as described: 
https://www.gnu.org/software/gettext/manual/gettext.html#index-dcpgettext

As far as I can tell from the NEWS shipped with gettext, this covers the 
major API changes.

My plan now is to start working on tests for the lib, and then tackle 
implementing the gettext(1), msgfmt(1) and msgunfmt(1) tools.

Regarding the project page: 
https://wiki.netbsd.org/projects/project/libintl/

- What other extensions were added to the .mo format? I couldn't find 
any major changes in the gettext NEWS or Changelog files.

- Are there any other major API items that I'm missing? Looking at 
gettext.h from GNU gettext, it seems that was it.

Here's the code, in case anyone wants to give me early feedback before I 
submit:
https://gitlab.com/worr/libintl

Thanks,
William Orr

(Continue reading)

Pierre Pronchery | 18 May 00:34 2015

Patch from FreeBSD for el_gets() in libedit

			Hi tech-userlevel <at> ,

FreeBSD patched their own copy of libedit about a month ago, see:
https://svnweb.freebsd.org/ports/head/devel/libedit/files/patch-src_eln.c?revision=382458&view=markup
(patch attached)

If I get this right (I have never used libedit myself) the value
returned in the "nread" argument (called "count" in the corresponding
manual page) may be wrong if any wide-character was encountered.

I did not find where el_wgets() is implemented. Would anyone know?

In pkgsrc I saw a folder called "libedit" in net/tnftp/files/libedit,
and it has a completely different implementation of el_gets().

Ok to commit?

Cheers,
--

-- 
khorben
--- src/eln.c.orig	2015-03-25 21:02:28.000000000 +0100
+++ src/eln.c	2015-03-28 11:42:29.913925000 +0100
 <at>  <at>  -75,12 +75,17  <at>  <at>  public const char *
 el_gets(EditLine *el, int *nread)
 {
 	const wchar_t *tmp;
+	int nwread;
+
(Continue reading)

Richard PALO | 17 May 13:26 2015
Picon

pdksh

After first soliciting Amitai's and Tobias' opinion, it was felt best to start here.

First the problem statement:

I came across some issues with pkgsrc using pdksh as primary TOOLS_PLATFORM sh/ksh
under SunOS (illumos).

For example, it segfaults in configure when trying to build ffmpeg010 on i386 (ABI=32).

I isolated it to a problem in the function 'tenter' found in table.c.

In 'struct table' both size and nfree are 'short', so for grins I first tried
simply 'min' with INT32_MAX then decided on setting size & nsize as unsigned shorts 
(avoiding for the moment changing the size of the structure):

> richard <at> omnis:/home/richard/src/pkgsrc/shells/pdksh$ git diff files/table.c
> diff --git a/shells/pdksh/files/table.c b/shells/pdksh/files/table.c
> index 1ac8fc3..9a9e459 100644
> --- a/shells/pdksh/files/table.c
> +++ b/shells/pdksh/files/table.c
>  <at>  <at>  -7,6 +7,9  <at>  <at> 
>  #include "sh.h"
>  
>  #define        INIT_TBLS       8       /* initial table size (power of 2) */
> +#ifndef min
> +#define        min(a, b)       ((a) > (b) ? (b) : (a))
> +#endif
>  
>  static void     texpand     ARGS((struct table *tp, int nsize));
>  static int      tnamecmp    ARGS((void *p1, void *p2));
(Continue reading)

Emmanuel Dreyfus | 13 May 10:27 2015
X-Face
Picon

Increase PTHREAD_KEYS_MAX

Hello

pthread_key_create() will refuse to create to create more than 
PTHREAD_KEYS_MAX pthread_key_t. I encountered situations
where some Apache setup with various modules could not work 
reliabily on NetBSD because the value is too low. From time
to time the server enters a state where it will not be able
to serve requests.

POSIX mandates PTHREAD_KEYS_MAX to be at least _POSIX_THREAD_KEYS_MAX, 
which should be 128 according to POSIX:
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html
Oddly it is 256 in NetBSD's <limit.h>

The values are:
NetBSD 256
Linux: 1024
MacOS X: 512

Obviously we lag behind and software will suit NetBSD less and less over the
time. Since it is often the result of shared usage by modules from different 
developers, we cannot blame anyone for overflowing _POSIX_THREAD_KEYS_MAX
usage as a requirement.

I suggest for netbsd-7
- fix _POSIX_THREAD_KEYS_MAX to be 128 instad of 256
- increase PTHREAD_KEYS_MAX to 2048 so that we lead again for some time
  this would increase memory footprint of programs linked with -lpthread
  of 14 kB on ILP32 systems, and 28 kB on LP64 systems.

(Continue reading)


Gmane