Re: textproc/xpdf: reduce warning spam
Hi Klemens,
since you Cc:ed me on this one, here is some quick feedback, even
though this feels so technical in both the compiler sense and the
ports sense that i'm hardly the right person to provide an OK.
Since you seem to care about technical details of the port quite
a bit, i wonder whether maybe you want to take MAINTAINER?
Klemens Nanni wrote on Sun, Oct 22, 2023 at 03:22:19PM +:
> Silence the wall of warnings on amd64 and other clang architectures.
> sparc64/ports-gcc doesn't print them, so don't suppress them there.
>
> Feedback? OK?
In general, i'm not convinced tweaking warning settings for individual
ports always makes maintenance easier, unless there are specific
reasons. Then again, this really reduces noise a lot, making
some potentially more relevant warnings stand out more, so if people
think it's worth the additional lines in the Makefile, i'm not opposed.
> Index: Makefile
> ===
> RCS file: /cvs/ports/textproc/xpdf/Makefile,v
> retrieving revision 1.98
> diff -u -p -r1.98 Makefile
> --- Makefile 22 Oct 2023 15:16:54 - 1.98
> +++ Makefile 22 Oct 2023 15:20:38 -
> @@ -47,3 +47,8 @@ do-install:
> ${PREFIX}/share/examples/xpdf/xpdfrc
>
> .include
> +
> +.if ${CHOSEN_COMPILER} == "base-clang"
> +# reduce warning spam, 86% less build log (1262 -> 179 lines)
For the full build log (make package 2>&1) i get 1530 -> 644 on amd64,
but i doubt this discrepancy matters.
Yours,
Ingo
> +CXXFLAGS+= -Wno-writable-strings
> +.endif
Re: textproc/xpdf: don't build/install too much
Hi Klemens,
Klemens Nanni wrote on Sat, Oct 21, 2023 at 03:30:19AM +:
> Instead of tossing a bunch of utilities, pass the ones we want.
> Makefile and Makefile.in patch gets simpler, no package change.
I like the idea, tested on amd64, looked at the build log and diff(1)ed
it to make sure there is no suspicious output (the amount of useless
compilation appears to be reduced), and checked that there is
no +CONTENTS change.
> Feedback? OK?
OK schwarze@
Ingo
> diff --git a/textproc/xpdf/Makefile b/textproc/xpdf/Makefile
> index b2d76aeb4..0c99b603e 100644
> --- a/textproc/xpdf/Makefile
> +++ b/textproc/xpdf/Makefile
> @@ -32,18 +32,18 @@ COMPILER =base-clang ports-gcc base-gcc
>
> NO_TEST= Yes
>
> -post-install:
> +# others are already in popper-utils
> +PROGS= xpdf pdfdetach pdftopng
> +ALL_TARGET= ${PROGS}
> +
> +do-install:
> +.for prog in ${PROGS}
> + ${INSTALL_PROGRAM} ${WRKBUILD}/xpdf/${prog} ${PREFIX}/bin/
> + ${INSTALL_MAN} ${WRKSRC}/doc/${prog}.1 ${PREFIX}/man/man1/
> +.endfor
> + ${INSTALL_MAN} ${WRKSRC}/doc/xpdfrc.5 ${PREFIX}/man/man5/
> ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/xpdf
> ${INSTALL_DATA} ${WRKSRC}/doc/sample-xpdfrc \
> ${PREFIX}/share/examples/xpdf/xpdfrc
> -# already in poppler-utils
> -.for i in pdffonts pdfimages pdfinfo pdftoppm pdftops pdftotext
> - rm ${PREFIX}/man/man1/$i.1
> - rm ${PREFIX}/bin/$i
> -.endfor
> -# forgotten in Makefile.in (there's also a pdfthtml, but it conflicts
> -# with poppler-utils):
> - ${INSTALL_PROGRAM} ${WRKBUILD}/xpdf/pdftopng ${PREFIX}/bin
> - ${INSTALL_MAN} ${WRKSRC}/doc/pdftopng.1 ${PREFIX}/man/man1
>
> .include
> diff --git a/textproc/xpdf/patches/patch-Makefile_in
> b/textproc/xpdf/patches/patch-Makefile_in
> index 9116dbe9c..065cec7fe 100644
> --- a/textproc/xpdf/patches/patch-Makefile_in
> +++ b/textproc/xpdf/patches/patch-Makefile_in
> @@ -1,18 +1,16 @@
> Makefile.in.orig Mon Aug 15 23:08:52 2011
> -+++ Makefile.in Thu Aug 18 21:10:22 2011
> -@@ -102,13 +102,8 @@ install: dummy
> - $(INSTALL_DATA) $(srcdir)/doc/pdfimages.1
> $(DESTDIR)@mandir@/man1/pdfimages.1
> - -mkdir -p $(DESTDIR)@mandir@/man5
> - $(INSTALL_DATA) $(srcdir)/doc/xpdfrc.5 $(DESTDIR)@mandir@/man5/xpdfrc.5
> ---mkdir -p $(DESTDIR)@sysconfdir@
> --@if test ! -f $(DESTDIR)@sysconfdir@/xpdfrc; then \
> --echo "$(INSTALL_DATA) $(srcdir)/doc/sample-xpdfrc
> $(DESTDIR)@sysconfdir@/xpdfrc"; \
> --$(INSTALL_DATA) $(srcdir)/doc/sample-xpdfrc
> $(DESTDIR)@sysconfdir@/xpdfrc; \
> --else \
> --echo "# not overwriting the existing
> $(DESTDIR)@sysconfdir@/xpdfrc"; \
> --fi
> -+-mkdir -p $(PREFIX)/share/examples/xpdf
> -+$(INSTALL_DATA) $(srcdir)/doc/sample-xpdfrc
> $(PREFIX)/share/examples/xpdf/xpdfrc
> +Index: Makefile.in
> +--- Makefile.in.orig
> Makefile.in
> +@@ -67,6 +67,12 @@ pdfdetach:
> + cd @UP_DIR@splash; $(MAKE)
> + cd @UP_DIR@xpdf; $(MAKE) pdfdetach$(EXE)
>
> - clean:
> - -cd goo; $(MAKE) clean
> ++pdftopng:
> ++cd goo; $(MAKE)
> ++cd @UP_DIR@fofi; $(MAKE)
> ++cd @UP_DIR@splash; $(MAKE)
> ++cd @UP_DIR@xpdf; $(MAKE) pdftopng$(EXE)
> ++
> + pdftoppm:
> + cd goo; $(MAKE)
> + cd @UP_DIR@fofi; $(MAKE)
Re: update lang/fennel; move man pages to a -docs subpackage
Hi Omar, Omar Polo wrote on Tue, Sep 19, 2023 at 02:30:08PM +0200: > I have to note that one could end up installing only the -docs > package, is it a concern? If a user explicitely says "pkg_add fennel-docs" without saying "pkg_add fennel", sure, they only get the documentation installed. But that's what they asked for, so i don't see a problem there. Occasionally, it might even be useful, for example when a user on a very slow network connection wants to look at the documentation before deciding whether they really want to download the code (and the other dependencies like lua). Maybe not the usual case - when you want to study documentation, you usually also want to play around a bit with the program - but clearly not harmful. It certainly won't be the only package containing documentation only and no code. Consider, for example, books/man-pages-posix. Yours, Ingo
Re: update lang/fennel; move man pages to a -docs subpackage
Hi Omar,
Omar Polo wrote on Tue, Sep 19, 2023 at 10:10:44AM +0200:
> The update itself is straightforward and all tests are passing.
> However, upstream added three more man pages (for a total of four now)
> which would get shipped in all of four fennel flavors (lua5[1-3]).
>
> Now, this is practice works, i.e. even if you have installed all the
> flavors `man fennel-api' works and since all the manpages are
> identical it's not really important if mandoc chooses fennel-5.1-api
> or fennel-5.4-api.
>
> However, I disliked to ship the same set of man pages four times, so
> here's an attempt to move them to a -docs subpackage. (thanks sthen@
> for pointing me at www/squid)
I wouldn't consider saving the diskspace for three manual pages the
main benefit, even though that hardly hurts, either. It seems more
important that your approach of making a subpackage prevents apropos(1)
from listing multiple pages and making the user wonder whether they
differ, possibly wasting their time running diff(1).
This is even likely to become worse in the near future when man(1)
starts warning that there are multiple manual pages of the same name
in the same section.
However, *if* you expect that the pages are likely to actually
become different in the future, that might be a reason against
making this subpackage. Then again, if that happens, it would
also be an option to merge them back in after it happens.
> Note that RUN_DEPENDS-docs is needed otherwise (via lua.port.mk and
> global RUN_DEPENDS) it ends up depending on lang/lua,${FLAVOR} and
> that will break subsequent build (the plist register the deps on one
> flavor, when building the next one the plist would differ)
Again, i don't think these technical considerations are the only
reason for RUN_DEPENDS-docs. I general, i stongly feel that if
you say "pkg_add food", that should absolutely install all the
documentation for the "foo" daemon. I mean, how is the user
supposed to use it if there is no documentation? We want sane
defaults, and installing software without documentation is not
exactly sane. Why should we send the user on a wild goose chase
to search for a "foo" documentation package after they alraedy
said they want food?
I certainly don't want to emulate the bad habit of some Linux
distros to not install documentation unless the user goes an extra
mile specifically asking for it.
> However, I'm not sure I'm overthinking it and just rename the three
> new manpages to fennel-${V}-XYZ instead of doing a subpackage would be
> preferred.
I did not audit this ports-wise, but i do like your general idea.
It doesn't feel like overengineering to me, there appear to be actual
benefits from the user perspective.
Yours,
Ingo
Re: Update documentation for ruby-module.5
Hi Jeremy, Jeremy Evans wrote on Wed, Sep 06, 2023 at 09:42:09PM +: > This updates ruby-module.5 to update it for recent changes and > make other improvements: > > * Sort the list of variables. > > * Remove mention of variables removed from ruby.port.mk, and > mention of jruby now that jruby support has been removed. > > I plan on committing this after the ruby.port.mk diff I sent, > assuming there are no objections. Definitely no objection here. When having a very brief look at the page, i noticed a very unusual style: first there is a giant list of variables with no explanation, then references to them scattered around the rest of the text. Wouldn't something like .Bl -tag -width Ds .It Ev MODRUBY_REV The ruby version for a non-gem port. The default is 3.2. The other supported values are 3.0 and 3.1. For a gem port, use a .Ev FLAVOR like .Ql ruby31 instead. be easier to read, more concise, look more familiar, be easier to maintain and easier to search at the same time? Right now, for example, ":t MODUBY_REV" does not work, and making mandoc(1) cope with the present style looks very difficult to me. Yours, Ingo
Re: UPDATE: x11/fvwm3 to 1.0.7
Hi,
Stuart Henderson wrote on Mon, Sep 04, 2023 at 11:07:52AM +0100:
> On 2023/09/04 11:05, Stefan Hagen wrote:
>> $ man 1 autoconf
>> There is more than one version of this manpage available (show with -w).
> oh that's a decent alternative.
Indeed, in particular in combination with the other idea of only giving
the heads-up for clashes *with the same section number*.
That reduces the waste of screen real estate to a single line,
even that is only printed when it really matters, and there are
only a handful of cases in the base system:
genuine clashes in base:
ld(1)- ld.1 and ld.bfd.1
perldelta(1) - perldelta.1 and perl5361delta.1
documentation bugs in base, same function documented twice:
CRYPTO_EX_dup(3), pem_password_cb(3), tls_reset(3)
See below for an improved patch, resulting in:
$ man FvwmPager
Multiple versions of FvwmPager(1) are available; list them with -w.
FvwmPager(1) General Commands Manual FvwmPager(1)
NAME
FvwmPager - the FVWM Pager module
[...]
$ man autoconf
AUTOCONF(4) Device Drivers Manual (amd64)AUTOCONF(4)
NAME
autoconf - diagnostics from the autoconfiguration code
[...]
$ man 1 autoconf
Multiple versions of autoconf(1) are available; list them with -w.
AUTOCONF(1) FSF AUTOCONF(1)
NAME
autoconf - Generate configuration scripts
[...]
$ man CRYPTO_EX_dup
Multiple versions of CRYPTO_EX_dup(3) are available; list them with -w.
CRYPTO_SET_EX_DATA(3) Library Functions Manual CRYPTO_SET_EX_DATA(3)
NAME
CRYPTO_EX_new, CRYPTO_EX_free, CRYPTO_EX_dup, CRYPTO_get_ex_new_index,
CRYPTO_set_ex_data, CRYPTO_get_ex_data, CRYPTO_free_ex_data,
CRYPTO_new_ex_data - functions supporting application-specific data
[...]
Lightly tested so far.
>> Then you could stop after the second match in the same section.
Actually, i think that's not even worth bothering.
The main performance penalty is that, even when one page is found in
the base system, parsing the Xenocara and ports databases is still
needed - but on modern hardware, the delay is only a few milliseconds.
It almost never happens that there are two pages with matching names
and section numbers in the base system, so the optimization would
almost never trigger.
Consequently, it makes more sense to drop the optimization outright.
Yours,
Ingo
Index: main.c
===
RCS file: /cvs/src/usr.bin/mandoc/main.c,v
retrieving revision 1.263
diff -u -p -r1.263 main.c
--- main.c 4 Sep 2023 13:08:11 - 1.263
+++ main.c 4 Sep 2023 14:36:19 -
@@ -500,16 +500,23 @@ main(int argc, char *argv[])
continue;
}
- /* Search for the best section. */
+ /*
+* Prioritize when displaying only one page.
+* Penalty 2000 for a wrong filename extension
+* 1000 for a wrong directory name
+* 10 per manpath index
+*1 per section number index
+*/
- best_prio = 40;
+ best_prio = INT_MAX;
for (ib = i = 0; i < resnsz; i++) {
sec = resn[i].file +
strlen(conf.manpath.paths[resn[i].ipath]);
sec += strcspn(sec, "123456789");
if (sec[0] == '\0')
continue; /* No section at all. */
- prio = sec_prios[sec[0] - '1'];
+ prio = resn[i].ipath * 10 +
+ sec_prios[sec[0] - '1'];
if (search.sec != NULL) {
ssz = strlen(search.sec);
if (strncmp(sec, search.sec, ssz) == 0)
@@ -517,7 +524,7 @@ main(int argc, char *argv[])
} else
sec++; /* Prefer without suffix. */
if (*sec != '/')
- prio += 10; /* Wrong dir name. */
+ prio += 1000; /* Wrong dir name. */
if (search.sec != NULL) {
ep = strchr(sec, '\0');
if (ep - sec > 3 &&
@@ -525,14 +532,23 @@ main(int argc, char *argv[])
ep -= 3;
if ((size_t)(ep - sec) < ssz + 3 ||
strncmp(ep - ssz, search.sec,
-ssz) != 0) /*
Re: UPDATE: x11/fvwm3 to 1.0.7
Hi Marc, Marc Espie wrote on Mon, Sep 04, 2023 at 12:11:52AM +0200: > On Sun, Sep 03, 2023 at 08:54:55PM +0200, Ingo Schwarze wrote: >> In addition to that, showing the complete list from man -w would >> force man(1) to do additional work, slowing down display of the >> manual page. When any of the -w, -a, or -k options is given, man(1) >> always searches through the whole MANPATH. By contrast, in standard >> mode, i.e. without any of these three options, it ends the search >> after the first database that returns a match and displays that >> match right away. For example, if you type "man printf", only the >> base system manual page database is inspected and you do not have to > How much work is that actually ? I mean with the current database system > if you just say "man something" it ought to be fairly quick, no ? > > (especially with just 3 databases) Actually, you have a point here. On my notebook, measuring the difference isn't even trivial. I managed to do it by inserting calls to clock_gettime(CLOCK_PROCESS_CPUTIME_ID, ...) into the code. On my notebook, the variation of the times is quite large while the times themselves are rather small, but anyway, here are the results for a simple name lookup, not including times for reading, parsing, and formatting the actual manual page file - all times in milliseconds: program startup time until the program reaches main(): 2 - 4 ms prep work before opening the database (option parsing etc.): 0.4 - 0.6 ms lookup time in the base system database: 1 - 3 ms lookup time in the Xenocara database: 0.5 - 1.5 ms lookup time in the ports database: 0.9 - 2.3 ms It looks like the difference is measureable. I performed no rigorous statistics, but a crude estimate might be that skipping the Xenocara and ports databases as we currently do saves about half the lookup time, or in absolute terms about 2 milliseconds on average on my notebook. Frankly, i don't have a luna88k machine, but at least on modern hardware, it looks like this doesn't matter at all. So *if* we want to show this information to the user, i guess i could just take that micro-optimization out and always scan all databases. However, nobody told me so far that they like the idea of showing this information, but one developer told me privately that they are not a fan. By the way, the point of getting rid of that optimization would be that in a situation like this, $ man -w FvwmPager /usr/X11R6/man/man1/FvwmPager.1 /usr/local/man/man1/FvwmPager.1 we would get, with the patch and without the optimization, $ man FvwmPager Showing: /usr/X11R6/man/man1/FvwmPager.1 See also: /usr/local/man/man1/FvwmPager.1 FvwmPager(1) General Commands Manual FvwmPager(1) NAME FvwmPager - the FVWM Pager module [...] That looks neat for the FVWM case - however, i fear some people might like exactly the same feature less in this case: $ man ls Showing: /usr/share/man/man1/ls.1 See also: /usr/local/man/man1/gls.1 LS(1) General Commands Manual LS(1) NAME ls - list directory contents [...] So, if many people use neither -w nor -a, how do you usually find out that there are multiple manual pages for the name you are looking for? Are you using man -f printf # but i would have expected that to be even less known? man -k Nm=printf # but that can be quite noisy IMHO... Or? Yours, Ingo
Re: UPDATE: x11/fvwm3 to 1.0.7
Hello Stefan, Stefan Hagen wrote on Sun, Sep 03, 2023 at 04:19:07PM +0100: > I think Espies suggestion is more discoverable because the user gets a > message on install he might see. Granted. Then again, rumour has it that people rarely heed post-install messages from pkg_add(1). > Ingos suggestion is technically "more correct". However, I asked 6 devs > and only one knew what -a/w does. So I don't think this is used. Interesting and astonishing to me. The -w option originated in Version 7 AT UNIX and -w in 4.3BSD-Tahoe. I certainly use both of them *very* often, usually many times every day, and feel surprised that people apparently get along without using them. Still, useful to know for the maintainer of a tool if an option is known to and used by few people. > From a user perspective, I think it would be nice if we cold make the > manpage display a tiny bit dynamic and show the output of man -w at the > bottom. > > Example > > MANPAGE VERSIONS: > fvwm3-FvwmButtons(1), FvwmButtons(1) Hm, that's an interesting idea, and i kind of like it. However, showing such information at the bottom feels like a dubious choice to me, in particular if many people are unaware of the -w and -a options. If there is more than one match, the user may be about to read the wrong one, and they likely want that information up front, rather than first reading the whole thing and then being told at the end: "Got you! This wasn't the page you were looking for." In addition to that, showing the complete list from man -w would force man(1) to do additional work, slowing down display of the manual page. When any of the -w, -a, or -k options is given, man(1) always searches through the whole MANPATH. By contrast, in standard mode, i.e. without any of these three options, it ends the search after the first database that returns a match and displays that match right away. For example, if you type "man printf", only the base system manual page database is inspected and you do not have to wait for a scan of the Xenocara and ports databases. So, here is a patch that displays a heads-up message up front - but only if more than one result is found in the same database. Besides, nothing changes in -w, -a, and -k mode, this only tweaks the default mode. For example: $ man printf Showing: /usr/share/man/man1/printf.1 See also: /usr/share/man/man3/printf.3 See also: /usr/share/man/man9/printf.9 PRINTF(1) General Commands Manual PRINTF(1) NAME printf - formatted output [...] $ man chmod chown Showing: /usr/share/man/man1/chmod.1 See also: /usr/share/man/man2/chmod.2 CHMOD(1) General Commands Manual CHMOD(1) NAME chmod - change file modes [...] BUGS There's no perm option for the naughty bits. OpenBSD 7.3 September 2, 2019 OpenBSD 7.3 Showing: /usr/share/man/man8/chown.8 See also: /usr/share/man/man2/chown.2 CHOWN(8) System Manager's Manual CHOWN(8) NAME chown - change file owner and group [...] $ man boot Showing: /usr/share/man/man8/amd64/boot.8 See also: /usr/share/man/man9/boot.9 BOOT(8)System Manager's Manual (amd64) BOOT(8) NAME boot, boot.conf - amd64-specific second-stage bootstrap [...] As a matter of fact, that's slightly similar to what man.openbsd.org has already been doing for quite some time, even though some details regarding presentation and priorities differ, consider: https://man.openbsd.org/printf https://man.openbsd.org/boot Even with the patch, such headers will *not* be displayed with explict commands like $ man 3 printf $ man -s 2 chmod chown $ man -S luna88k 8 boot or when there is only one match, like in $ man ls $ man -S sparc64 boot Does this make sense to you? By the way, i think showing the full path (just like in man -w) is better than just showing printf(1), printf(3), and printf(9). In complicated cases, for example when architecture dependent, preformatted, or compressed pages, or sections with suffixes are involved, seeing the full path may help the user to understand at first sight what is going on. Even in simple cases, seing right away whether the clash happens in base, Xenocara, ports, or in some custom tree (which can be configured via man.conf(5), MANPATH, -m, or -M) may also help. On the other hand, its trivial to figure out that to get at /usr/share/man/man3/printf.3, "man 3 printf" will work. Then again, if people insist on showing "printf(1), printf(3), ..." only, i can certainly tweak the patch. Similarly, moving the information after each manual page is trivial, but not better IMHO. > This would bring discoverability to Ingos solution. And we could freely > rename manpages, because our man(1) is clever enough to find them > anyway. (compared to
Re: UPDATE: x11/fvwm3 to 1.0.7
Hi Stefan, Stefan Hagen wrote on Wed, Aug 30, 2023 at 09:41:20AM +0200: > There's no good way to handle a conflict that's introduced with an > update. So what we would do is to move the manpages into the install > directory. (thanks to espie@ for the suggestion) Actually, i regard that as bad advice, espie@ shouldn't say such things. Moving ports manual pages out of the standard /usr/local/man/ tree is a last resort measure that should be reserved for the most extreme cases - for example, language systems having huge numbers of manual pages, many of which conflict with base system manual pages (like lang/tcl, or to a lesser degree, plan9/plan9port) and for collections of manual pages that simply don't document the system they get installed on (like books/man-pages-posix). For a small application-level port like x11/fvwm3, i regard moving a handful of manual pages out of /usr/local/man/ as totally inappropriate: * Almost nobody ever bothers with putting "manpath" directives into man.conf(5). And that's a good thing. Having to maintain a list of manual page trees would be cumbersome. Besides, the more trees you configure, the more error prone and the less efficient manual page searching and lookup becomes. And there isn't really any problem that needs to be solved with this configuration option. Looking up manual pages ought to work by default, without users having to worry about configuring anything - and porters can indeed help making things work by default. The consequence is that, if you move some manual pages out of /usr/local/man/, most users simply won't ever see them, not even when they are actively searching for them. * Even if a user is aware where these pages are and wants to look at them specifically, the simplest command achieving that is man -M /usr/local/share/fvwm3/man FvwmPager That's an awful lot to type, even with the help of tab completion. For people coding in tcl a lot, doing something like alias tm='man -M /usr/local/lib/tcl/tcl8.5/man' in a shell initialization file would arguably be acceptable even if not particularly elegant, but for fvwm3, such a concoction would be quite the overkill. I have occasionally considered making commands like man -M tcl open work, but the design isn't as trivial as it seems, getting it right on the first try matters, and demand is so limited even for stuff like tcl and man-pages-posix that i did not do it yet, even though eventually, i certainly hope to. Even if we had that already, it would seem unlikely to me that people would remember using if for fvwm3. > You'll then get a nice little info to add this path to your man path > when the package is installed: > > --- +fvwm3-1.0.7 --- > You may wish to add /usr/local/share/fvwm3/man to /etc/man.conf I absolutely hate that message. It is not nice at all, and it is almost always bad advice. You even get that message for tcl and for man-pages-posix, where it makes absolutely zero sense. And for a simple port like fvwm3, you would really be willing to manually edit a system configuration file merely to read a handful of manual pages contained in that port? I certainly wouldn't do that, it feels so insulting. Fortunately, there is a simple solution: > +@man share/fvwm3/man/man1/FvwmAnimate.1 > +@man share/fvwm3/man/man1/FvwmAuto.1 > +@man share/fvwm3/man/man1/FvwmBacker.1 > +@man share/fvwm3/man/man1/FvwmButtons.1 > +@man share/fvwm3/man/man1/FvwmCommand3.1 > +@man share/fvwm3/man/man1/FvwmConsole.1 > +@man share/fvwm3/man/man1/FvwmEvent.1 > +@man share/fvwm3/man/man1/FvwmForm.1 > +@man share/fvwm3/man/man1/FvwmIconMan.1 > +@man share/fvwm3/man/man1/FvwmIdent.1 > +@man share/fvwm3/man/man1/FvwmMFL.1 > +@man share/fvwm3/man/man1/FvwmPager.1 > +@man share/fvwm3/man/man1/FvwmPerl.1 > +@man share/fvwm3/man/man1/FvwmPrompt.1 > +@man share/fvwm3/man/man1/FvwmRearrange.1 > +@man share/fvwm3/man/man1/FvwmScript.1 Change the file names of the above to fvwm3-FvwmPager.1 etc. and install them /usr/local/man/. Whether you use FvwmCommand3.1 or fvwm3-FvwmCommand3.1 is a matter of taste, both seem fine. It would be ideal to do it in such a way that, for consistency, bot of these work: man FvwmCommand3 man fvwm3-FvwmCommand3 > +@man share/fvwm3/man/man1/fvwm3-convert-2.6.1 > +@man share/fvwm3/man/man1/fvwm3-menu-desktop.1 > +@man share/fvwm3/man/man1/fvwm3-menu-directory.1 > +@man share/fvwm3/man/man1/fvwm3-menu-xlock.1 > +@man share/fvwm3/man/man1/fvwm3-perllib.1 > +@man share/fvwm3/man/man1/fvwm3-root.1 > +@man share/fvwm3/man/man1/fvwm3.1 > +@man share/fvwm3/man/man1/fvwm3all.1 > +@man share/fvwm3/man/man1/fvwm3commands.1 > +@man share/fvwm3/man/man1/fvwm3menus.1 > +@man share/fvwm3/man/man1/fvwm3styles.1 Those can go to /usr/local/man/ without any tweaking, i guess. That way, man -a FvwmPager will display all three FvwmPager(1) manual pages when both ports are installed,
Re: ports: pkg/SCREENSHOTS proposal
Hi Stuart, Stuart Henderson wrote on Thu, Jun 23, 2022 at 08:21:45AM +0100: > On 2022/06/22 08:05, Landry Breuil wrote: >> Le Tue, Jun 21, 2022 at 07:59:45PM +0100, Stuart Henderson a écrit : >>> On 2022/06/21 17:46, Solène wrote: Such a database could be integrated into AppManager maybe. I wonder if repology or a similar package database could provide pictures we could reuse (after hosting it somewhere else if licence allows this) >>> If done, it would certainly make sense for this to be some kind of >>> resource shared between package systems rather than OpenBSD-specific. >> like https://screenshots.debian.net/ ? > oh, nice. This (i.e. a website that accepts uploads) should use much less > developer resources on an ongoing basis than committing new files in the > ports tree. It seems to work, too. For testing purposes, yesterday, i submitted three new screenshots. Now, the https://screenshots.debian.net/ home page says: Newest upload: mandoc: BSD manpage compiler toolset If you read this message with significant delay, see https://screenshots.debian.net/package/mandoc I'm sure people *must* have screenshots before they would consider switching from man-db/groff (the Debian defaults) to mandoc... =;c) It appears the site displays screenshots in reverse chronological order, last submitted first, which results in a really weird ordering for mandoc but may make sense when GUI software has been around for a long time and people submit new screenshots showing the latest functionality. It appears that even though OpenBSD and Debian have significantly different project goals, project size, project culture, technical foundations and technical methodologies, relevant synergies have been developing on the fringes of the projects for some time now. For example, we have become prolific users of https://codesearch.debian.net/ in particualar for LibreSSL, but certainly not for LibreSSL only, and https://manpages.debian.org/ uses the mandoc mdoc(7), man(7), tbl(7) and eqn(7) parsers and the mandoc HTML renderer (even though it uses its own database and searching code and its own CSS file). And *of course* Debian is using OpenSSH and pf(4) by default. Oh wait... :) Yours, Ingo
Re: Is there a way to display the block of another man page inside a man page
Hi, Tilo Stritzky wrote on Tue, May 03, 2022 at 08:45:05AM +0200: > On 02/05/22 01:46 Tom Smyth wrote: >> while documenting nsh and its features, >> I wanted to display the command switches of telnet command inside the >> manual page for nsh, > Within more/less you can get a shell by typing: > |.command > [pipe + period + command] > > That way you can nest as many manpages as you like in a single terminal. I have rarely seen worse advice regarding the design and writing of manual pages. To start with, Tom's idea of including substantial parts of the text of one manual page into another one was a bad idea, and he already admitted as much and settled for a much better solution for his actual task. Then, even if your idea worked, it would include the whole manual, including even headers and footers, and not just the parts Tom asked for. Most importantly, the mdoc(7) source code of a manual page obviously cannot issue less(1) commands. If it could, that would be a major security hole in mandoc(1), so massive that it would probably be the first time ever that a mandoc bug would have to be fixed by an OpenBSD erratum. Or would that be a bug in less(1)? Likely, but probably an erratum either way. To go on, for security reasons, the OpenBSD version of less(1) does not support escaping to a shell. If you press the "exclamation mark" key in OpenBSD less(1), it just beeps and does nothing. Even on Linux, your advice does not work: $ uname -a Linux login-1 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28) x86_64 GNU/Linux $ man man [...] [ optionally hit the space bar here ] [ now type !.ls as you suggested and hit RETURN ] /bin/sh: 1: .ls: not found !done (press RETURN) [ press the RETURN KEY] [...] Manual page man(1) line 80 (press h for help or q to quit) [ now type !ls (without the dot) and hit RETURN ] [ it now displays a list of my files, then ] !done (press RETURN) [ press the RETURN KEY] [...] Manual page man(1) line 80 (press h for help or q to quit) Of course, even without your "period" (no idea where you got that from), it does not display anything "inside the manual page" but switches back and forth between either displaying the manual page or displaying the result of the shell command. Please guys, when you provide advice to others on our mailing lists, you should at least bother to test your own advice before posting. Yours, Ingo
Re: Is there a way to display the block of another man page inside a man page
Hi Tom, Tom Smyth wrote on Mon, May 02, 2022 at 01:46:50AM +0100: > while documenting nsh and its features, > I wanted to display the command switches of telnet command inside the > manual page for nsh, Don't. This is not a technical problem: "how can i technically do this" is the wrong question to ask. This is a problem of manual page design and content organisation. Having a large amount of identical text in two manual pages is a bad idea because readers will wonder whether the text is indeed identical or whether there are subtle differences. They will likely waste time by starting to compare the two pages to track down the differences. Besides, displaying lots of content from one page in another is bad documentation design because it detracts from the topic of the other page. Instead, explain in the other page which content of the first page also applies here, as precisely as possible. > I would like to display , the contents of the > telnet , name synopsis and description sections from the telnet > manpage in the nsh man page without copying the contents of the man > page. (so that the command line switches / arguments are up to date > for a given OpenBSD version > > for now i have done telnet client documentation in nsh as follows > .Tg telnet Most likely, .Tg is not needed right in front of .Ic with the same argument. Does :t telnet not work without it? > .Ic telnet > .Op -a That should be ".Op Fl a"; the same applies below. > .Op -b host-alias > .Op -l user-name > .Ar host-name Just ".Ar host" is enough; it may not even be a name. > .Op Ar port > .Pp > Open a telnet client session to the remote host host-name. Better: Open a .Xr telnet 1 session to the remote server .Ar host , which can be specified by name or IP address. > Where host-name can be a name or IP address of the remote host. > port is the TCP port on the remote host which you wish to connect and port > can be within the range 0-65535. > The > .Ic -a > switch will attempt an automatic login if the setup permits it. > The > .Ic -b host-alias > will bind the source IP telnet client session to a specific ip address alias > rather than the primary ip address on a given interface. > See the > .Xr telnet 1 > man page for a comprehensive list of telnet command options. Yes, that is how to do it. Nits: s/man/manual/; s/command/command line/ I think i would trim this down even more. The -a and -l options are unimportant because nobody should use telnet(1) with authentication. The -b option is unimportant because the automatically selected source address is almost always just fine. So just .Ic telnet .Op Ar options .Op Ar host Op port .Pp Open a .Xr telnet 1 session to the given TCP .Ar port on the remote server .Ar host , specified by name or IP address. The .Ar options are documented in the .Xr telnet 1 manual page. seems better to me: precise and concise. > .Bd -literal -offset indent > nsh(p)/!man telnet > .Ed This example is probably superfluous at this point. Escaping to a shell (i guess that is what "!" means) ought to be documented in a different part of this manual page, and apart from that, the example is trivial. > any thoughts / advice welcome Hope this helps, Ingo
Re: nsh manual rewrite in mandoc draft feedback requested style ideas etc
Hi Tom, Tom Smyth wrote on Mon, Apr 25, 2022 at 11:08:26AM +0100: > I have been translating the txt of MANUAL of nsh port to mandoc In fact, you have started translating it to mdoc(7) - which is a markup language - rather than to mandoc(1) - which is a parsing and formatting program for multiple markup languages including mdoc(7). > there is quite alot of features and syntax to document Wow, indeed. What a beast! > so I figured that before I complete the first redraft (that is fit for > human consumption) I would get feedback on what I have done so far. > > do you like the bullets are they too much My impression is that bullet lists are indeed overused. > what I should do more of? > what i should do less of? I suggest making sure that features are described completely and consisely and not only demonstrated by examples. You certainly do not need to add more examples. Wording, grammar, and punctuation might profit from some polishing throughout. Some text feels rather wordy and repetitive for a manual page but somewhat vague at the same time. In a manual page, the DESCRIPTION needs particular attention because it's the first part readers look at. Choosing a good order and weeding out repetions is particularly important in that section. > any advice comments would be appreciated OK, let's have a stab at it: > .\" NSH is BSD licensed Instead of this line, insert the complete text of the license that applies to the manual page file, including a "Copyright" line. Look in /usr/share/man/man8/ for examples. > .Nd Network configuration shell Use lower case instead of sentence case in the .Nd line. > .Bk -words ... .Ek No need for that, just delete both the .Bk and the .Ek line. > .Op Fl i Ar rcfile > .Op Fl c Ar rcfile Use different placeholder names for different option arguments. Make them as descriptive as possible. > for other daemons into one place, providing an alternative > to /etc/netstart and parts of /etc/rc. Make that an alternative to .Xr netstart 8 and parts of .Xr rc 8 . > .sp Never use .sp in manual pages. Use .Pp instead. > .Nm > encapsulates the following daemons and services: Very subtle markup bug here: outside literal context, you almost never want to start a line in roff(7) code with a space character. In roff(7), a leading space character means "break the output line and indent the next line by a space character - look at the output: nsh encapsulates the following daemons and services: That's very ugly and a bit confusing. Search your file for lines starting with spaces, there are several more examples. > pf, ospfd, ospf6d, bgpd, ripd, ldpd, relayd, ipsecctl, iked, rtadvd, > dvmrpd, sasyncd, dhcpd, snmpd, sshd, ntpd, ifstated, tftp-proxy, > ftp-proxy, tftpd, npppd, resolv.conf, inetd, smtpd, ldapd, ifstated Ouch, what a monster. I'd probably do something like this: .Bd -ragged -offset indent .Xr pfctl 8 , .Xr ospfd 8 , .Xr ospf6d 8 , .Xr bgpd 8 , .Xr ripd 8 , ... .Ed Consider some kind of sorting, maybe alphabetically. This is bad because it destroys conciseness of the DESCRIPTION. Maybe say something like .Nm encapsulates the functionality of more than two dozen network-related programs. See the .Sx SEE ALSO section for a complete list. > .sp > .Sh COMMAND LINE ARGUMENTS No .Pp is needed right before .Sh. Besides, command line options must *not* get their own .Sh. The list of command line options is crucial content of the DESCRIPTION section and must never be moved elsewhere. > .Bl -tag -width 4 For the option list, ".Bl -tag -width Ds" is customary. I see no reason to be different here. > nsh will operate with verbose output Missing full stop (not only here, there are several more instances). Avoid future tense if you can (not only here, the document is full of "will"). No need to repeat the command name here. This would be better: .It Fl v Produce verbose output. The description of -c and -i needs to be improved. I don't understand what the difference between the two might be. > .Nm > when run with out any arguments When run without any command line arguments, .Nm does foobar... > left right keys allow for Is it using the editline library? In that case, consider .Xr'ing to editline(7) rather than re-explaining how command line editing works. If it uses some other library, link to that. > .Bl -bullet > .It > nshprompt/show i > .It > % Ambigious argument i > .El Code examples and examples of interactive use should not use bullet lists but ".Bd -unfilled" or ".Bd -literal". I guess "nshprompt/" is the prompt? That's exceedingly ugly. Can you use a better prompt for the manual page, ideally one that ends in a space character and is much shorter? For example: .Bd -unfilled -offset indent nsh/ show i % Ambigious argument i .Ed The bullet list after "commandline completion display" could be formatted like this: .Bd -literal -offset indent nsh(p)/ i ifstate
Re: [new] devel/libfixposix
Hi Omar, Omar Polo wrote on Fri, Dec 03, 2021 at 08:00:03PM +0100: > Woops, I identified a correct issue in unistd.c, but the fix was wrong. > Updated tarball attached and upstream notified :) > > (update: upstream has accepted one of the two patches) > > Also enabling the built-in tests this time, I haven't noticed them the > first time because without --enable-tests `make test' was successful and > listed 0 tests available. (The mkstemp test fails because why check > what malloc returns?) Failing to check return values is bad, too, but not the root cause of the failure. That test is attempting to allocate (2^24 - 1) * 15 = 251658225 bytes of memory in a single malloc(3) call, about 240 MB, because on OpenBSD, TMP_MAX is 0x7fff. Running that particular test makes no sense until upstream fixes it. The test src/tests/buildinfo.bats is also broken. It assumes that, if you have a file "./utility" that start with the first line "#!/bin/sh" and a file "./argument" that starts with the first line "#!./utility" and then run "./argument", that the kernel would run "#!/bin/sh ./utility ./argument". But our kernel runs "#!/bin/sh ./argument" instead. The buildinfo.bats issue is more or less unfixable because on the one hand, the automake infrastructure in Makefile.am and the script config/aux/tap-driver.sh require that the TESTS make variable must contain the name of the test *data* file, but then turn around and tell the kernel to *execute* that data file. To make that portable, upstream needs to completely restructure that maze of indirections and abstractions. On top of that, the tests require gmake(1) and bash(1) while nothing in the actual software requires those. So half the tests (2 out of 4) are broken and completely non-portable. The "select" test is completely trivial and certainly does not test select(2) in any meaningful way. So what remains as potentially working and non-trivial is one single test, the "spawn" test. I don't think that is worth depending on gmake and bash and all the trouble i described above. Consequently, i suggest to just forget about the tests until upstream gets their shit together and makes sure they are portable, work, and test some non-trivial features. I mean, come on, this is supposed to be a portability library - but all the same, the test suite is thoroughly Linux-only... Next problem to consider for upstream: when run with automake 1.16 and autoconf 2.71, the build complains loudly: configure.ac:53: warning: The macro `AC_PROG_CC_C99' is obsolete. configure.ac:53: You should run autoupdate. /usr/local/share/autoconf-2.71/autoconf/c.m4:1662: AC_PROG_CC_C99 is expanded from... configure.ac:53: the top level configure.ac:67: warning: The macro `AC_LANG_C' is obsolete. configure.ac:67: You should run autoupdate. /usr/local/share/autoconf-2.71/autoconf/c.m4:72: AC_LANG_C is expanded from... config/m4/ax_pthread.m4:283: AX_PTHREAD is expanded from... configure.ac:67: the top level configure.ac:67: warning: The macro `AC_TRY_LINK' is obsolete. configure.ac:67: You should run autoupdate. /usr/local/share/autoconf-2.71/autoconf/general.m4:2921: AC_TRY_LINK is expanded from... config/m4/ax_pthread.m4:283: AX_PTHREAD is expanded from... configure.ac:67: the top level So that is apparently newer than the autotools versions they are aiming for. But when trying to use the autotools versions advertised in README.md, automake-1.10 and autoconf-2.67, the build crashes instantly, so those are apparently too old. There are more problems with the software. For example, in src/lib/install_signalfd.c, i spotted a signal handler that calls snprintf(3). I don't doubt there is more. Then again, correctness of upstream code isn't really a requirement for a port... I'm suggesting the version of the Makefile appended below, with the following changes: * Remove BUILD_DEPENDS = devel/check The build does not need it, only the tests might, some day. * Remove USE_GMAKE = Yes Again, the build does not need it, only the tests do. * Add SEPARATE_BUILD = Yes Upstream strongly recommends that, and faq/ports/testing.html recommends it, too. * Add CONFIGURE_ENV += ac_cv_prog_GIT= That achieves the same as patch-config_m4_custom_checks_m4 , but in a much simpler way. Do forget to remove that patch if you agree with this change. * Add a comment explaining why the test suite makes no sense just yet, with an incomplete list of changes that would be needed to enable it, all commented out, such that we don't forget what we already found out. * Add a comment about the autotools versions. I think someone should talk to upstream and find out which versions this software is actually designed for. Feel free to use part or all of this in any way you want. I don't want to commit it, but you might. :-) Yours, Ingo # $OpenBSD$ COMMENT = thin wrapper over libc functions and macros GH_ACCOUNT =
Re: [new] devel/libfixposix
Hi Omar, Omar Polo wrote on Fri, Dec 03, 2021 at 09:07:02AM +0100: > % pkg_info libfixposix > Information for inst:libfixposix-0.4.3 > > Comment: > thin wrapper over POSIX syscalls > > Description: > The purpose of libfixposix is to offer replacements for parts of POSIX > whose behaviour is inconsistent across *NIX flavours. Without looking at the code: This sounds totally scary to me. Wouldn't it be better to provide a dummy instead that just passes the calls through? I mean, decisions about OpenBSD deviating from POSIX are usually made for a reason, aren't they? For example, the first things coming to my mind are rand(3) and gets(3) and printf(%n), and i feel certain there are several more. Software depending on POSIX behaviour that we intentionally disabled should not just patch it back, right? I think it is better to have such software fail to build (or even, admittedly less conveniently, crash at run time). Then, the actual problems can be investigated and fixed properly. Wouldn't this port essentially implement security mitigation countermeasures, as the famous saying by tedu@ goes? This is not an objection, just a question. > Maintainer: The OpenBSD ports mailing-list For such a scary beast, shouldn't there at least be a maintainer who does basic auditing of the library, making sure that it does not cause a security disaster, and making sure that future versions do not introduce vulnerabilities either? To me, this feels like sending a Mastiff to promenade alone in the park instead of leading it on a leash? Yours, Ingo
Re: OpenBSD wrapper for Linux/FreeBSD sendfile?
Hi, Steve Williams wrote on Thu, Nov 18, 2021 at 06:04:26PM -0800: > I'm trying to compile a Linux/FreeBSD application (zoneminder) under > OpenBSD 7.0. > > I'm slowly working through it but have gotten stuck at the point where > it has a dependency on sendfile(2) which OpenBSD doesn't have. Judging from the Linux manual page https://man.bsd.lv/Linux-5.13/sendfile you should be able to trivially implement a replacement function for sendfile(2) using lseek(2), read(2), and write(2). Of course, that will be slower than doing the copying inside the kernel as sendfile(2) does. But it should get you going in order to make the program run at all. Try that unless somebody else has a better idea. > Doing some research, I found one reference that sosplice(2) might be > able to be used in place of sendfile. A system call soplice(2) does not exist. The sosplice(9) manual page describes kernel internals, so to implement sendfile(2) based on sosplice(9), you would have to do some real kernel hacking. Given the questions you are asking, you are clearly not up to that, and even if you were - hacking up the kernel just to port some software is usually not the best idea. Yours, Ingo
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: schwa...@cvs.openbsd.org2021/09/19 15:54:18 Modified files: editors/cooledit: Makefile Added files: editors/cooledit/patches: patch-editor_editoptions_c patch-editor_options_c patch-editor_shell_c Log message: avoid sprintf(%n); OK both Theos (tb@ and deraadt@); committing quickly to stay away as far as possible from the upcoming lock
cooledit printf(%n) fixes
Hi Marc, hi Naddy,
Christian Weisgerber wrote on Sun, Sep 19, 2021 at 09:23:18PM +0200:
[...]
> Let's focus on fixing bugs!
> This includes the list of remaining ports with %n warnings:
>
> editors/cooledit
[...]
I think the patch appended below fixes those crashes in cooledit
that are directly related to printf(%n).
OK?
Note that the port is very low quality in general. The code is full
of insecure idioms and the program is full of bugs that make even
minimal testing rather painful. I don't think anybody can use this
port for serious work in its present state.
* It sometimes has outrageous startup times, up to around 20 seconds
on my notebook.
* Putting it into the background with Ctrl-Z does not work.
* Sometimes, it just freezes totally.
* When assigning keys, it sometimes closes the window that is
intended to capture the key combination when pressing a modifier
key, which means that binding keys sometimes does not work.
* Sometimes, it segfaults on exit (plain segfault, not SIGABRT).
* And that is merely what i stumbled across without even trying
to use it for real...
There are many other places in the codebase where %n occurs, but i
failed to find any others related to printf(3). It has large numbers
of its own printf-like wrapper functions and clearly sometimes assembles
format strings dynamically in temporary buffers, but i did not find
indications that %n might be put into such dynamically-built format
strings. Consequenly, i'm not completely sure that this patch resolves
all printf(%n) issues in the code base, but it does not seem unlikely
either. Even if were not 100% complete, committing this would seem
better than doing nothing.
Yours,
Ingo
Index: Makefile
===
RCS file: /cvs/ports/editors/cooledit/Makefile,v
retrieving revision 1.48
diff -u -p -r1.48 Makefile
--- Makefile23 Feb 2021 19:39:21 - 1.48
+++ Makefile19 Sep 2021 20:40:00 -
@@ -3,7 +3,7 @@
COMMENT = easy to use, graphical editor
DISTNAME = cooledit-3.17.17
-REVISION = 4
+REVISION = 5
CATEGORIES = editors
Index: patches/patch-editor_editoptions_c
===
RCS file: patches/patch-editor_editoptions_c
diff -N patches/patch-editor_editoptions_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-editor_editoptions_c 19 Sep 2021 20:40:00 -
@@ -0,0 +1,28 @@
+$OpenBSD$
+
+Do not use sprintf(3) %n.
+
+Index: editor/editoptions.c
+--- editor/editoptions.c.orig
editor/editoptions.c
+@@ -378,15 +378,15 @@ int save_user_defined_keys (struct key_list k_list[],
+
+ for (i = 0; k_list[i].key_name[0]; i++) {
+ if (k_list[i].keycode2) {
+- sprintf (p, "%s\t%x %x %x %x %x %x\n%n", k_list[i].key_name,
k_list[i].state0, k_list[i].keycode0,
+- k_list[i].state1, k_list[i].keycode1, k_list[i].state2,
k_list[i].keycode2, );
++ n = sprintf (p, "%s\t%x %x %x %x %x %x\n", k_list[i].key_name,
k_list[i].state0, k_list[i].keycode0,
++ k_list[i].state1, k_list[i].keycode1, k_list[i].state2,
k_list[i].keycode2);
+ p += n;
+ } else if (k_list[i].keycode1) {
+- sprintf (p, "%s\t%x %x %x %x\n%n", k_list[i].key_name,
k_list[i].state0, k_list[i].keycode0,
+- k_list[i].state1, k_list[i].keycode1, );
++ n = sprintf (p, "%s\t%x %x %x %x\n", k_list[i].key_name,
k_list[i].state0, k_list[i].keycode0,
++ k_list[i].state1, k_list[i].keycode1);
+ p += n;
+ } else if (k_list[i].keycode0) {
+- sprintf (p, "%s\t%x %x\n%n", k_list[i].key_name, k_list[i].state0,
k_list[i].keycode0, );
++ n = sprintf (p, "%s\t%x %x\n", k_list[i].key_name,
k_list[i].state0, k_list[i].keycode0);
+ p += n;
+ }
+ }
Index: patches/patch-editor_options_c
===
RCS file: patches/patch-editor_options_c
diff -N patches/patch-editor_options_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-editor_options_c 19 Sep 2021 20:40:00 -
@@ -0,0 +1,35 @@
+$OpenBSD$
+
+Do not use sprintf(3) %n.
+
+Index: editor/options.c
+--- editor/options.c.orig
editor/options.c
+@@ -405,22 +405,22 @@ int save_setup (const char *file)
+
+ for (i = 0; string_options[i].name; i++) {
+ if (*string_options[i].value) {
+- sprintf (p, "%s = %s\n%n", string_options[i].name,
*string_options[i].value, );
++ r = sprintf (p, "%s = %s\n", string_options[i].name,
*string_options[i].value);
+ p += r;
+ }
+ }
+ for (i = 0; integer_options[i].name; i++) {
+ if (integer_options[i].type == TYPE_HIDDEN_HEX_VALUE)
+- sprintf (p, "%s = 0x%X\n%n", integer_options[i].name,
*integer_options[i].value, );
++ r = sprintf (p, "%s = 0x%X\n", integer_options[i].name,
Re: editors/nedit: avoid *printf %n
+Cc: MAINTAINER
Hi Theo,
Theo Buehler wrote on Wed, Sep 15, 2021 at 11:59:36PM +0200:
> Straightforward.
OK schwarze@.
Given that we are approaching a lock, i don't think you should wait
for feedback from the MAINTAINER.
Alessandro, i suspect buffer overflow issues in util/misc.c,
function CreateGeometryString(). The arguments are (int) and can
likely be provided from outside the program, but the buffer being
printed to is only 24 bytes long. I didn't poke around long enough
to figure out whether this can crash the program (or worse), but as
the MAINTAINER, it might make sense that you have a closer look.
But that seems unrelated to the present patch.
There is much opportunity for additional cleanup to be done upstream:
for example, strcpy(3) in conjunction with pointer arithmetics is all
over the place, and invariants are quite non-obvious if any exist.
Yours,
Ingo
Testing done:
Before:
$ /obin/ncl tmp.txt
Abort trap (core dumped)
$ /obin/nedit -g 80x24+100+100
Abort trap (core dumped)
After:
$ ncl tmp.txt # works
$ nedit -g 80x24+100+100 # works
> Index: Makefile
> ===
> RCS file: /cvs/ports/editors/nedit/Makefile,v
> retrieving revision 1.82
> diff -u -p -r1.82 Makefile
> --- Makefile 12 Apr 2020 14:46:04 - 1.82
> +++ Makefile 13 Sep 2021 16:06:53 -
> @@ -5,7 +5,7 @@ COMMENT= a fast, compact Motif/X11 plai
> DISTNAME=nedit-5.7
> P_V= 0.5
> EPOCH= 0
> -REVISION = 0
> +REVISION = 1
> DISTFILES= ${DISTNAME}-src${EXTRACT_SUFX} \
> nedit_patterns-${P_V}.tgz:0
>
> Index: patches/patch-source_nc_c
> ===
> RCS file: /cvs/ports/editors/nedit/patches/patch-source_nc_c,v
> retrieving revision 1.2
> diff -u -p -r1.2 patch-source_nc_c
> --- patches/patch-source_nc_c 28 Feb 2019 23:00:47 - 1.2
> +++ patches/patch-source_nc_c 13 Sep 2021 16:04:55 -
> @@ -27,3 +27,28 @@ Index: source/nc.c
> #endif /*VMS*/
>
> /* Structure to hold X Resource values */
> +@@ -778,10 +778,10 @@ static void parseCommandLine(int argc, char **argv, Co
> +The "long" cast on strlen() is necessary because size_t
> +is 64 bit on Alphas, and 32-bit on most others. There is
> +no printf format specifier for "size_t", thanx, ANSI. */
> +-sprintf(outPtr, "%d %d %d %d %d %ld %ld %ld %ld\n%n",
> lineNum,
> ++charsWritten = sprintf(outPtr, "%d %d %d %d %d %ld %ld %ld
> %ld\n", lineNum,
> + read, create, iconic, isTabbed, (long) strlen(path),
> + (long) strlen(toDoCommand), (long) strlen(langMode),
> +-(long) strlen(geometry), );
> ++(long) strlen(geometry));
> + outPtr += charsWritten;
> + strcpy(outPtr, path);
> + outPtr += strlen(path);
> +@@ -816,9 +816,9 @@ static void parseCommandLine(int argc, char **argv, Co
> + * iconic state (and optional language mode and geometry).
> + */
> + if (toDoCommand[0] != '\0' || fileCount == 0) {
> +-sprintf(outPtr, "0 0 0 %d %d 0 %ld %ld %ld\n\n%n", iconic, tabbed,
> ++charsWritten = sprintf(outPtr, "0 0 0 %d %d 0 %ld %ld %ld\n\n", iconic,
> tabbed,
> + (long) strlen(toDoCommand),
> +-(long) strlen(langMode), (long) strlen(geometry),
> );
> ++(long) strlen(langMode), (long) strlen(geometry));
> + outPtr += charsWritten;
> + strcpy(outPtr, toDoCommand);
> + outPtr += strlen(toDoCommand);
> Index: patches/patch-util_misc_c
> ===
> RCS file: patches/patch-util_misc_c
> diff -N patches/patch-util_misc_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-util_misc_c 13 Sep 2021 16:01:48 -
> @@ -0,0 +1,37 @@
> +$OpenBSD$
> +
> +Index: util/misc.c
> +--- util/misc.c.orig
> util/misc.c
> +@@ -1488,25 +1488,25 @@ void CreateGeometryString(char *string, int x, int y,
> + int nChars;
> +
> + if (bitmask & WidthValue) {
> +-sprintf(ptr, "%d%n", width, );
> ++nChars = sprintf(ptr, "%d", width);
> + ptr += nChars;
> + }
> + if (bitmask & HeightValue) {
> +-sprintf(ptr, "x%d%n", height, );
> ++nChars = sprintf(ptr, "x%d", height);
> + ptr += nChars;
> + }
> + if (bitmask & XValue) {
> + if (bitmask & XNegative)
> +-sprintf(ptr, "-%d%n", -x, );
> ++nChars = sprintf(ptr, "-%d", -x);
> + else
> +-sprintf(ptr, "+%d%n", x, );
> ++nChars = sprintf(ptr, "+%d", x);
> + ptr += nChars;
> + }
> + if (bitmask & YValue) {
> + if (bitmask & YNegative)
> +-sprintf(ptr, "-%d%n", -y, );
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: schwa...@cvs.openbsd.org2021/09/15 08:14:22 Modified files: misc/uniutils : Makefile Added files: misc/uniutils/patches: patch-ExplicateUTF8_c Log message: remove %n format specifier and fix a portability bug on the same line; OK nicm (MAINTAINER), and also tested by Stefan Hagen
Re: misc/uniutils fix %n
Hi Stefan, Stefan Hagen wrote on Tue, Sep 14, 2021 at 07:37:20PM +0200: > I really appreciate you (and Theo) taking the time to explain > these things. You are welcome, and thank you for trying to help fix stuff (i think i forgot saying that in my previous mail because i got a bit worked up about the horrible code in that file, which has nothing to do with you). > I noticed the weird output, In such a case, it is useful to add a sentence like this: With my patch, it no longer crashes for me, but i'm not completely sure whether it is right because the output looks weird. It prints far too many '0' characters (32 too many if i count correctly) - compare the size of the 0-padding printed to the desired size mentioned in the text "..." printed in the first half of the line before the base-2 number. In general, if you have specific doubts, mentioning them specifically is better than just asking "is it better?" > but couldn't make sense of it as the > upstream version crashes (abort trap) here. > > Regarding my terrible C skills, I think I'll step back from trying to > fix C code for a bit. I'm wasting peoples time here to educate me on > topics I could as well learn elsewhere. (Except you tell me to continue > submitting bad fixes and learn here...). Well, your patch was still half-useful in so far as it correctly spotted the one place in the code that needs to be fixed (i did extensive grepping anyway to make sure, but it is reassuring that we both came to the same conclusion). There is a saying here "bad patches trigger good ones". Also, bug reports that contain *only* a verbal description of the problem or *only* a patch often leave me wondering what the sender is driving at. When *both* a verbal description and a patch are supplied together, even if the patch is bad, it very rarely happens that the intention of the sender remains nebulous. > I feel embarrassed, because I can't even explain why I used > snprintf there. I guess you looked at the rest of the code in the file, which uses lots and lots of superfluous static buffers and lots of pointless snprintf(3). Existence determines consciousness: what code one reads influences what kind of code one writes (though not deterministically, and of course it isn't the only factor). So make sure you read sufficient amounts of good code. Either way, learning from feedback is better than feeling too embarassed. > Your fix looks good to me. But my opinion doesn't matter at this point. Well, a test report from a real-world user is always useful, can make the difference between committing quickly and waiting for more feedback from developers, and is usually acknowledged by something like OK some_developer@, and also tested by <...@...> in the commit message. So thanks for testing and reviewing. Yours, Ingo
Re: misc/uniutils fix %n
Hi,
Stefan Hagen wrote on Sat, Sep 11, 2021 at 09:00:18AM +0200:
> Is this better?
No, it is no good whatsoever.
* It introduces yet another pointless static buffer.
* It pointlessly uses snprintf(3) where printf(3)
is obviously sufficient.
* It introduces error checking for operations
that obviously cannot fail when done properly.
* It needlessly does pointer arithmetic.
So far, so bad, but the worst part is that it apparently wasn't
tested on a 64-bit platform (a platform where sizeof(long) == 64,
for example amd64). On such a platform, there is another bug on
the very same line. The function binfmtl() has platform-dependent
behaviour and does not behave as intended on a 64-bit platform and
prints 32 spurious zero-digit characters, breaking the desired
output alignment and making the content of the output
self-contradictory on top of that.
Rather than try to change binfmtl(), which is mostly pointless
in the first place, let's just trivially inline the desired
functionality, it's just two lines of very simple C code.
OK?
Ingo
P.S.
Usually, we would want to upstream such a bugfix. But the overall
quality of this code is so abysmal that i'm not sure upstreaming
anything is worth the hassle. Doing minimal cleanup of the most
glaring style issues in this code would require changing 99% of it,
and given how it is written throughout, my suspicion is that it is
likely full of bugs, and having two bugs on this one line may not
be an exception. Just look at the totally ridiculous tempstr
gymnastics right below, which is incredibly stupid. Or look just
a few lines above and admire the hand-rolled code handling six-byte
UTF-8 characters (which are invalid according to the standard).
The code is just very, very bad throughout in large numbers of
respects.
I'm ashamed to admit that i have occasionally been using this port
myself, and after looking at the code, i'm no longer convinced i
should do that. Not sure yet what to do about that. Cleaning this
up looks like a project of significant size, and quite a painful one.
I just looked up the author of this code:
https://en.wikipedia.org/wiki/William_Poser
https://billposer.org/
It looks like he is probably an eminent linguist, but he is clearly
not a software developer by any stretch of the imagination.
Index: Makefile
===
RCS file: /cvs/ports/misc/uniutils/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- Makefile28 Jun 2021 21:34:19 - 1.9
+++ Makefile14 Sep 2021 15:52:32 -
@@ -3,7 +3,7 @@
COMMENT= Unicode utilities
DISTNAME= uniutils-2.27
-REVISION= 3
+REVISION= 4
CATEGORIES=misc
HOMEPAGE= http://billposer.org/Software/unidesc.html
Index: patches/patch-ExplicateUTF8_c
===
RCS file: patches/patch-ExplicateUTF8_c
diff -N patches/patch-ExplicateUTF8_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-ExplicateUTF8_c 14 Sep 2021 15:52:32 -
@@ -0,0 +1,30 @@
+$OpenBSD$
+
+Remove %n format specifier
+and stop using the platform-dependent function binfmtl().
+We want 32 bits here, not whatever sizeof(long) might be.
+
+Index: ExplicateUTF8.c
+--- ExplicateUTF8.c.orig
ExplicateUTF8.c
+@@ -87,7 +87,7 @@ main(int ac, char **av){
+ int UsefulBits;
+ unsigned char c[6];
+ int i;
+- UTF32 ch;
++ UTF32 ch, mask;
+ unsigned char *cptr;
+ unsigned char ShiftedByte;
+ char tempstr[33];
+@@ -214,7 +214,10 @@ main(int ac, char **av){
+ printf("%s ",tempstr);
+ }
+ printf("\n");
+- printf("This is padded to 32 places with %d zeros:
%n%s\n",(32-GotBits),,binfmtl(ch));
++ spaces = printf("This is padded to 32 places with %d zeros: ",(32-GotBits));
++ for (mask = 1UL << 31; mask; mask >>= 1)
++putchar(ch & mask ? '1' : '0');
++ putchar('\n');
+ sprintf(tempstr,"");
+ sprintf(tempstr,"%08lX",ch);
+ tempstr[28] = tempstr[7];
Re: sysutils/bat
Theo de Raadt wrote on Tue, Jul 27, 2021 at 09:12:58AM -0600:
> Ian Darwin wrote:
>> On Tue, Jul 27, 2021 at 04:47:46PM +0200, Ingo Schwarze wrote:
>>>> Changes by:st...@cvs.openbsd.org 2021/07/27 05:55:36
>>>>
>>>> Modified files:
>>>>sysutils/bat : Makefile
>>>>
>>>> Log message:
>>>> set sysutils/bat to ONLY_FOR_ARCHS=${LP64_ARCHS}, one of the 147
>>>> dependencies (sys-info) has a 32 vs 64 bit issue when checking
>>>> the number of CPUs online
>>> Wait, a cat with 147 dependencies? Looks like it's a rabbit after all!
>>> At least there can be no doubt that it inhabits a rabbit hole, doesn't it?
>>>
>>> Besides, isn't a program that stops working once your machine has
>>> more than four billion CPUs utterly useless in the 31st century?
>>>
>>> If it didn't constantly trip up otherwise busy porters, this port
>>> would be a really good laugh.
>>>
>>> *Looking at the calendar*
>>> No, it's unlikely to be the Easter bunny.
>>> We are not that close to Apil 1.
>> And to think that Rob Pike once wrote a paper "cat -v considered harmful"
>> since it added unnecessary functionality to cat, whose only job is
>> to catenate files...
> bat is my favorite rust program
>
> please continue maintaining it in ports,
> i don't want the standup comedy to end
I didn't mean to summon tedu@ regarding the port,
quite to the contary, i might even contribute to it!
https://github.com/sharkdp/bat/pull/1756
Re: sysutils/bat
> Changes by: st...@cvs.openbsd.org 2021/07/27 05:55:36
>
> Modified files:
> sysutils/bat : Makefile
>
> Log message:
> set sysutils/bat to ONLY_FOR_ARCHS=${LP64_ARCHS}, one of the 147
> dependencies (sys-info) has a 32 vs 64 bit issue when checking
> the number of CPUs online
Wait, a cat with 147 dependencies? Looks like it's a rabbit after all!
At least there can be no doubt that it inhabits a rabbit hole, doesn't it?
Besides, isn't a program that stops working once your machine has
more than four billion CPUs utterly useless in the 31st century?
If it didn't constantly trip up otherwise busy porters, this port
would be a really good laugh.
*Looking at the calendar*
No, it's unlikely to be the Easter bunny.
We are not that close to Apil 1.
Re: make documentation
Hi, Reuben ua Brig wrote on Sun, Jun 27, 2021 at 09:47:01PM +1000: >> Date: Sun, 27 Jun 2021 10:29:12 +0100 >> From: Stuart Henderson Judiging from marc.info and from my own mailbox, i fail to find the original copy of this posting by Stuart. Reuben, did you publicly quote a private mail, or am i missing something? >> Seems I was (and the port Makefile) was wrong about it being tbl No, Stuart, you were spot-on. For example, consider gmdiff man0p/complex.h.0p gmdiff man1p/awk.1p >> vut there aee some big problems with equations e.g. in float.h, math.h. As far as i am aware, and according to the extract from my ports notes file that i posted recently, the problems with eqn(7) are mostly excessive spacing caused by weird syntax involving useless quoted space characters in the eqn source code. That's likely much easier to fix than the very serious tbl parsing issues, but hardly high priopity given that i don't recall ever having seen similar input syntac anywhere else. >> btw the source manpages *are* installed but (probably due to how >> pkg_create handles manpages in USE_GROFF ports) they're tarred up. Yes, they are installed, but only for licensing reasons in the past (that may no longer exist). The reason they are tarred up is that we don't consider it useful to install two copies of the same text. When cat pages are needed, we don't want the sources alongside. So zhuk@ decided to waste as little space as the license allowed when he set up the port in 2014. > having only seen float.h, mandoc did slightly better in one place where > it included a sum where the cat file only had . Yes. I improved handling of mathematical symbols and Greek letters in both mandoc and groff terminal output not long ago, but eqn(7) handling for the terminal is likely better with mandoc than with groff: i spent significant work on that based on the excellent foundations that Kristaps laid. > personally i would like to patch man so that it calls make Over my dead body. > (with a > special makefile), so it could be extended to e.g. cat pkg-readmes; I dimly remember that moving pkg-readmes into a dedicated section of the manual pages was proposed in the past and rejected; i don't remember why exactly, it may have been because the existing format is easier to handle for porters, and the texts are so short that it usually matters relative little for users; not sure. > but first i will see how posix-man-pages and v7man go. I don't think i understaood all you said, some of your code snippets seemed cryptic and of unclear purpose. Try to write complete sentences that are as clear as possible, please. Regarding v7man, are you referring to https://man.bsd.lv/?query=.=1=UNIX-7 Anything wrong with that? Yours, Ingo
Re: make documentation
Hi Reuben, Reuben ua Brig wrote on Sun, Jun 27, 2021 at 05:26:29PM +1000: > From: Stuart Henderson >> Maybe not for man-pages-posix, it looks like embedded tbl(7) support >> is needed. mandoc doesn't do this, so they still need to be formatted >> with groff. > cheers. will see what i can do. i have not noticed any problems with > the output of man so far (havent tried html etc.), All output modes are wqually broken because these are parsing issues rather than formatting issues. > and am not familiar with roff, so are have you noticed any problem > pages in particular? See my last mail to you, it contains some examples - not a full list though since even drafting a full list would cause significant work, of limited usefulness given how difficult it is to fix all that. If something is so difficult that there is no chance fixing it any time soon, spending lots of effort on describing all the problems in detail is a waste of time. > p.s. just tried MANPAGER=w3m man -T html 3p sigaction; and the table > for struct sigaction looks alright, though there are too many empty > lines in the C text under `Establishing a Signal Handler'. That's a relatively minor, purely HTML formatting issue that would definitely not stand in the way of using mandoc. In general, -Tascii and -Tutf8 output have a much higher quality and are much more important than HTML output (even though mandoc HTML output is vastly superior to groff HTML output, and lots of work was spent, and is being spent, on improving HTML output). What you are reporting here are valid concerns in the mandoc roff(7) to HTML formatter, which is among the youngest formatting modules. Using inside for .nf may be less than ideal, and representing .P inside .nf by closing and reopening the even less so. It's not completely trivial because it likely can't be solved in roff_html.c alone but the interactions with html.c and possibly man_html.c and maybe even mdoc_html.c need to be considered. So i added your report to the TODO file for now: - HTML formatting of .nf should avoid and not close and re-open on .P Reuben ua Brig 27 Jun 2021 17:26:29 +1000 loc ** exist ** algo * size * imp ** Thanks for the report, Ingo
Re: make documentation
Hi, Stuart Henderson wrote on Sun, Jun 27, 2021 at 08:17:40AM +0100: > On 2021/06/26 22:06, Mike Larkin wrote: >> On Sun, Jun 27, 2021 at 12:40:21PM +1000, Reuben ua Brig wrote: >>> i would like to prefix this by saying i am writing this as a user >>> giving feedback and not a developing giving patches and anyone who has >>> a problem with that can go shove it rather than telling me to shut up. >>> >>> i noticed for a lot of the ports to openbsd, even in base, a lot of >>> documentation is either missing or, how shall i put it, over-compiled. This remark is amazing. I literally spent years of my life improving that. Please read http://www.openbsd.org/papers/bsdcan18-mandoc.pdf slides 35 to 40. Page 36 documents that i improved what you are asking for by a factor of 180 (it is now one hundred and eighty times better than it used to be). What you are talking about is literally the last 3 permille, the last 30 ports out of 9000. >>> some examples in my memory are: >>> >>> texlive* installs e.g. PDF documenation and removes TeX sources, even >>> though in many cases the TeX sources are an integral part of the >>> documentation. Texlive is *the* ultimate monster port (as far as *individual* ports go; there are no doubt *groups* of ports maintained by individual people or small teams that are even worse, far worse, like GNOME and KDE and mozilla - and OK, admittedly, there are a few other individual monsters, like chrome). I admire Edd for maintaining texlive over all those many years. Nothing about that beast is simple, not even understanding the vast amount of stuff it contains. And yes, texlive documentation is definitely a maze, half a continent of swamps and deserts scattered among jungles of code, containing no end of wild beasts and beautiful gems. Improving that is... some kind of an undertaking, you know. >>> man-pages-posix installs cat files rather than man files. As a matter of fact, it installs *both*. For the 2013-a version, it was forced to do so by this annoying former requirement in the file POSIX-COPYRIGHT: [...] Redistribution of this material is permitted so long as this notice and the corresponding notices within each POSIX manual page are retained on any distribution, *and the nroff source is included*. [...] (my emphasis) In the 2017-a version, that requirement was removed, which jasper@ apparently missed when updating the port last November. I guess i should send a patch to no longer install the source tarball. >>> (b.t.w. the man tools do work with section 0, you just need change >>> the file extension: i would suggest .3p for compatibility with >>> current section.) That's a non-issue as long as mandoc cannot handle the POSIX manuals at all. Besides, 3p is Perl in OpenBSD, so that would a bad choice. >>> anyway i think users would benefit from including more documentation >>> when it is in the sources, You don't say? :-) By the way, it's not just mandoc. For example: https://undeadly.org/cgi?action=article=20190419101505 In particular, after reading the piece, look at the last use case at the very bottom. "The /usr/xenocara/ tree contains about 250 DocBook files. Some of them might contain information worth extracting. I plan to look into that together with matthieu@." After that, look at stuff like man fonts man XKB-Config man XKB-Enhancing man shapelib man synclib man xtest1 man Xmu man drmAvailable man drmHandleEvent man drmModeGetResources man 7 drm man drm-kms man drm-memory man xtrans That's all documentation that was made available in manual page form not too long ago, exactly as you are asking for. Admittedly, the effort stalled somewhat. The task here is extracting the gems from the swamp. Not all of these 250 documents are likely to really benefit users, and we don't want to promote crap. >>> but, you know, its your time, so dont do it >>> if you dont want, just dont be prissy about it. >> your diff to implement what you are asking for is welcome! > Maybe not for man-pages-posix, Right, Stuart, thank you for clarifying that. Improving mandoc(1) such that it becomes able to handle man-pages-posix is among the hardest remaining tasks to solve in mandoc. You are welcome to help improve mandoc if you want to, but you are definitly not welcome to try to make mandoc work with man-pages-posix. Even if you manage to, the diff will be so large, complicated, and intrusive that i won't have the time to review it properly. Here is the mandoc TODO lists: https://cvsweb.bsd.lv/~checkout~/mandoc/TODO?rev=HEAD As a beginner, look for entries that say "loc * exist * algo * size *". But be aware that even those aren't trivial and most of them pose traps for the unwary. If something is really easy, most of the time, it doesn't make it into the file at all but tends to gets fixed on the spot. My rating for making man-pages-posix work is "loc *** exist ** algo *** size **", i.e. it's a cross-module
Re: libc++ 10.0: textproc/groff
Hi Christian, [textproc/groff maintainer speaking] Christian Weisgerber wrote on Wed, Jan 06, 2021 at 05:24:22PM +0100: > textproc/groff fails to build with libc++ 10.0. groff blocks over > a thousand package paths, so this needs to be fixed before we can > switch to the newer libc++. > > Analysis: > > groff includes a copy of gnulib. gnulib provides *.h wrappers for > some standard header files. Those wrappers are not standalone. > They are intended to be included in a source file after "config.h" > has been included. This is correct. I recently saw this statement explicitly confirmed by members of the gnulib project, and it has also been supported by gnulib documention for a long time. The GNU troff project has been disregarding this documented requirement, but i don't think disregarding it is intentional. > In particular, gnulib has a wrapper for math.h, but not for stdlib.h. > > In libc++ 10, includes . When building groff, > this include directive picks up the gnulib math.h wrapper. Since > is included from some source files that do not include > the local config.h, the math.h wrapper will then error out: > error: "Please include config.h first." > > Possible solutions: > > Cherrypick the libc++ upstream patch that untangles the interactions > between the two header files and stops stdlib.h from including math.h. > https://github.com/llvm/llvm-project/commit/c490c5e81ac90cbf079c7cee18cd56171f1e27af > That patch looks very sensible, but as the commit history shows > there were problems related to "local submodule visibility" and I > don't know what that is and how it affects us. I do not object to doing that if people consider it sensible, but i can't say whether or not it should be done. What you say seems to indicate it should be carefully considered rather than rushed. > In the groff port, we could add #include "config.h" to all files > that don't do so already and include . This is relatively > clean, but will touch a number of files. I agree that this is clean and poses little risk. I am certain that it will quickly be picked up upstream because the GNU troff project recently already discussed that "config.h" needs to be included in more files for reasons resembling these but not identical to these, and there was no opposition to including "config.h" in more files when there are good reasons. I plan to prepare, test, and post patches for the groff port when i find time (which will not take more than two days), but if others beat me to it, i do not object to such paches being committed at once. After our port is patched, i'll also send patches upstream. > In the groff port, we could alternatively copy FreeBSD's pragmatic > solution and simply add #include "config.h" to the math.h wrapper. > That's not correct in some larger gnulib sense, but should suffice > for the purposes of the port. That sounds dirtier to me for no good reason, and it seems harder to judge whether that might cause unanticipated side effects. Why not use the cleaner solution that will also be committed upstream when that is already known? This dosn't mean that i'm trying to veto a temporary addition to the math.h wrapper if you prefer that for some reason. > Since the problem originates with gnulib, it could affect ports > other than groff, too. However, a cursory search of the FreeBSD > ports tree shows only one other port with a gnulib math.in.h patch, > and that one is unrelated. Well, according to your analysis and according to what i know about gnulib, it results from a combination of two factors: 1. The trap that gnulib sets. 2. GNU troff walking into the trap by violating the documented gnulib requirement of including "gnulib.h" before standard headers. The rarity of the problem - if confirmed - might result from not all programs that use gnulib walking into trap. > Suggestions? Patch textproc/groff quickly, watch out for failures in other ports after upgrading to libc++ 10.0 (if any other ports are overlooked having the same problem, they are likely to be as easy to fix as groff) and optionally consider, free from haste, whether additional patching of gnulib itself is useful, needless, or even risky. Yours, Ingo
Re: upcoming textproc/groff-1.23.0
Hi Christian, thanks for the feedback! I really appreaciate that. I will look at making a leaner version of the port avoiding the TeXLive dependency. I'll explore the options and come back to you. It's not yet urgent because the release has not yet arrived, but it's very good that i already got your guidance. See below for a few details. Yours, Ingo Christian Weisgerber wrote on Sun, Nov 15, 2020 at 11:17:07PM +0100: > Ingo Schwarze: >> There is another reason why now is a good time to switch priorities. >> Upstream has been doing lots of work on documentation, and in that >> context, they decided to use newer makeinfo(1) features that our >> ancient /usr/bin/makeinfo does not support. The natural consequence >> is to make groff depend on the print/texinfo port and use the newer >> gmakeinfo(1) version contained in that port to format the groff >> documentation. (Yes, the irony that groff does *not* use roff for >> its own documentation but instead uses TeX is not lost on me.) > It is GNU project policy that distribution tarballs include > pre-formatted .info files so that makeinfo is NOT required. tar -tzvf groff-1.23.0.rc1.tar.gz | grep -F .info tells me the groff project doesn't include it in the tarball, but maybe i can convince them to do that in the future. > ... Although, I guess that groff wants to build HTML/PDF documentation? Yes, groff wants to do that, but i wouldn't consider that important. There is not much point in installing HTML and PDF files when the same information is also available in man(1) or info(1) form. > The need for a newer makeinfo will bite us more and more, especially > porters who are not as comfortable disentangling the dependencies > and touch(1)ing the correct files when upstream make a mistake while > creating the tarball and the autotools build cascade goes off and > wants to re-run makeinfo without need... >> Now, print/texinfo isn't exactly a lean port. Here is its >> list of dependencies according to "make full-all-depends": > Installing this monster for a newer makeinfo(1) will sooner or later > trap us in a recursive dependency. I did check that, right now, there is no recursive dependency. But i missed that fact that it sets a trap, so i'll work on a way to update to 1.23.0 without setting that trap. >> * Texinfo is needed to build the documentation. The alternative >>would be to ship groff without documentation and point people to >>https://www.gnu.org/software/groff/manual/html_node/ . >>But frankly, we don't generally like telling people "get the >>manual from the web" in OpenBSD. > Actually, we tend not to build documentation that requires pulling > in dependencies like Doxygen or, well, TeXLive. Duly noted. > (Admittedly, much Doxygen-generated documentation seems very poor > in the first place and just regurgitates header files.) Indeed, Doxygen is mostly useless.
upcoming textproc/groff-1.23.0
preconv(1),
but we used to exclude them to keep the port lean. They are
less useful on OpenBSD than elsewhere because we do not support
non-UTF-8 character encodings in the first place, but they are
not quite as heavy as gmakeinfo(1) and may come in handy
occasionally when dealing with foreign files.
* The change to MASTER_SITES is temporary and will of course
never get committed.
* I adjusted the order of variables to match the template.
* Adding ghostscript makes a lot of sense because it contains fonts
that people expect when doing real PostScript/PDF typesetting.
Those issues keep causing frequently asked questions on the
groff lists, so i really think we should provide them out of
the box.
* The other three RUN_DEPENDS are less important but may occasionally
come in handy when creating HTML output (netpbm), PDF output
(poppler-utils), or PostScript output (psutils), and the groff
build systems wants them. So why not.
* Texinfo is needed to build the documentation. The alternative
would be to ship groff without documentation and point people to
https://www.gnu.org/software/groff/manual/html_node/ .
But frankly, we don't generally like telling people "get the
manual from the web" in OpenBSD.
* ac_cv_path_mkdir=/bin/mkdir now appears to be the default,
and so does --with-awk=awk .
* ac_cv_prog_MAKEINFO and ac_cv_prog_INSTALL_INFO are needed
because upstream only looks for makeinfo and install-info,
finds our old versions, and those kill the build.
* PAGE=letter avoids random behaviour, which would othervise
depend on whatever the default is for the user doing the build.
* Several patches have been included upstream or are no longer
needed for other reasons.
* The groffer(1) script had such an abysmal code quality and was
so useless in the first place that upstream decided to delete
it without any replacement. Just use groff(1) itself, it isn't
that hard.
* By virtue of the new dependencies, lots of additional documentation
in HTML and PDF format can now be installed.
* The classical -ms tutorial by Larry Kollar was rediscovered
and is now installed to /usr/local/share/doc/groff/ms.ps .
* There are large numbers of additional fonts that weren't available
before because we avoided the ghostscript dependency.
So, here we go:
Index: Makefile
===
RCS file: /cvs/ports/textproc/groff/Makefile,v
retrieving revision 1.50
diff -u -p -r1.50 Makefile
--- Makefile21 Oct 2020 21:21:59 - 1.50
+++ Makefile13 Nov 2020 18:31:51 -
@@ -1,10 +1,10 @@
# $OpenBSD: Makefile,v 1.50 2020/10/21 21:21:59 jca Exp $
COMMENT = GNU troff typesetter
-VERSION = 1.22.4
+VERSION = 1.23.0
SUBST_VARS = VERSION
-DISTNAME = groff-${VERSION}
-REVISION = 4
+DISTNAME = groff-${VERSION}.rc1
+PKGNAME = groff-${VERSION}
CATEGORIES = textproc
DPB_PROPERTIES = parallel
@@ -15,28 +15,31 @@ MAINTAINER = Ingo Schwarze https://alpha.gnu.org/gnu/groff/
# Groff does not use C++, but merely pre-1995 C with classes.
COMPILER = base-clang base-gcc
-MASTER_SITES = ${MASTER_SITE_GNU:=groff/}
+MODULES = perl
+LIB_DEPENDS = converters/libiconv \
+ textproc/uchardet
+RUN_DEPENDS = graphics/netpbm \
+ print/ghostscript/gnu \
+ print/poppler,-utils \
+ print/psutils
+BUILD_DEPENDS =${RUN_DEPENDS} \
+ print/texinfo
MAKE_FLAGS += docdir=${PREFIX}/share/doc/groff \
- exampledir=${PREFIX}/share/examples/groff \
- ac_cv_path_mkdir=/bin/mkdir
+ exampledir=${PREFIX}/share/examples/groff
-MODULES = perl
CONFIGURE_STYLE = gnu
-CONFIGURE_ARGS += --with-awk=awk --without-gs \
- --without-libiconv-prefix --without-uchardet \
- --without-urw-fonts-dir --without-x \
- pnmcrop=missing pnmcut=missing pnmtopng=missing \
- pnmtops=missing psselect=missing
-CONFIGURE_ENV += ac_cv_prog_PDFFONTS= \
- ac_cv_prog_PDFIMAGES= \
- ac_cv_prog_PDFINFO= \
- ac_cv_prog_XPMTOPPM=
+CONFIGURE_ENV += ac_cv_prog_MAKEINFO=gmakeinfo \
+ ac_cv_prog_INSTALL_INFO=ginstall-info \
+ PAGE=letter
TEST_TARGET = check
pre-configure:
Index: distinfo
===
RCS file: /cvs/ports/textproc/groff/distinfo,v
retrieving revision 1.5
diff -u -p -r1.5 distinfo
--- distinfo24 Dec 2018 10:42:00 - 1.5
+++ distinfo13 Nov
Re: Allowing multiple providers of libraries - BLAS/LAPACK
Hi Aisha, Aisha Tammy wrote on Wed, Oct 28, 2020 at 01:12:15PM -0400: > Here is a preliminary version update of math/lapack to 3.9.0 > with some patches from debian and gentoo. While FORTAN used to be my favourite language until about 1998, i got out of the habit of using it after that, so i can't really comment on the port in general, but ... > Current caveats > (1) I've had to remove the man pages installation. 1. Why? In general, if a major change is needed when updating a port, it is useful to mention the reason. 2. Isn't that a blocker? For a programming library, having section 3 documentation seems crucial to me. What is the point of an undocumented public API? Yes, i am aware that lapack is among the last 20 or so ports that require USE_GROFF, and among the worst handful of these because the man(7) code is both unusually problematic from a qualitative standpoint (.ti nested inside .TP head, ...) and also hard to handle from a perspective of quantity - the library is so large that even reviewing the manual pages regarding which problems are contained in them isn't easy. But none of that should be your problem, nor should it prevent formatting the manual pages with groff and installing them. Yours, Ingo
minimally adapt misc/tkman to OpenBSD
Hi,
while the misc/tkman port isn't totally broken on OpenBSD, nobody
did even minimal porting work on it, either. In many respects, it
disregards even the most basic aspects of how OpenBSD documentation
works.
So, i decided to put some of my fingers where my mouth is and do a
few initial, minimal steps of actually porting this thing. There
can't be the slightest doubt that much more can be done before this
can be called an adequate port. Even with these minimal patches,
it is still doing lots of stuff that is rather absurd on OpenBSD,
so much more work would be useful.
But these initial patches already make it more useful in so far as
they repair some of the most blatant misconfigurations and delete
some of the most misleading warnings.
With this patch, try this:
a) type tkman and press ENTER;
this now actually shows the tkman welcome page without warnings
b) then type "any=MAP_STACK" into the input box,
press the "man" button and hold it down until the menu appears,
select "apropos" from the menu, and relese the mouse button:
mandoc-style semantic searching works
c) then typ "erf" into the input box and hit enter:
look at the formula in the DESCRIPTION: UTF-8 works
My reasons for non deleting this port are that
1. the tkman program contains a number of interesting
ideas and concepts;
2. even though personally, i dislike GUIs, many users like them,
and this is the most interesting man(1) GUI i have seen so far;
3. at least for simple tasks, it is already fit for practical
use, even though i still expect *lots* of rough edges
The patch below
* uses mandoc for formatting rather than having a hidden
dependency on groff;
* produces UTF-8 for output rather than LATIN-1, which we don't even support
* reorders the manual search path ("mastermen") in our default order;
* deletes a bogus warning about stray cats
* deletes bogus warnings about the absense of whatis files
* no longer errors out when MANPATH is unset
* regenerates the gui.tcl patch without Windows CR gore
OK?
Ingo
P.S.
I do not promise that i'll do all the additional cleanup that should
be done all by myself, but at least i wanted to get this started.
Index: Makefile
===
RCS file: /cvs/ports/misc/tkman/Makefile,v
retrieving revision 1.27
diff -u -r1.27 Makefile
--- Makefile3 Oct 2020 13:30:11 - 1.27
+++ Makefile3 Oct 2020 15:45:43 -
@@ -3,7 +3,7 @@
COMMENT = Tcl/Tk-based manual browser
DISTNAME = tkman-2.2
-REVISION = 1
+REVISION = 2
CATEGORIES = misc
HOMEPAGE = http://www.sourceforge.net/projects/tkman
MAINTAINER = Stuart Cassoff
@@ -20,7 +20,8 @@
NO_TEST = Yes
pre-patch:
- perl -pi -e 's!\r\n$$!\n!g;' ${WRKSRC}/Makefile
+ perl -pi -e 's!\r\n$$!\n!g;' ${WRKSRC}/Makefile \
+ ${WRKSRC}/{database,gui,manpath,tkmandesc}.tcl
do-install:
@${MODTCL_WISH_ADJ} ${WRKSRC}/tkman ${WRKSRC}/retkman
Index: patches/patch-Makefile
===
RCS file: /cvs/ports/misc/tkman/patches/patch-Makefile,v
retrieving revision 1.5
diff -u -r1.5 patch-Makefile
--- patches/patch-Makefile 3 Oct 2020 13:30:12 - 1.5
+++ patches/patch-Makefile 3 Oct 2020 15:45:43 -
@@ -16,37 +16,28 @@
# for a man pages and displaying its associated binaries (if any).
# Use this feature carefully as a large number of directories can slow down
startup.
-mastermen = "/usr/man /usr/local/man"
-+mastermen = "${PREFIX}/man /usr/share/man ${X11BASE}/man"
++mastermen = "/usr/share/man ${X11BASE}/man ${PREFIX}/man"
#mastermen = "/usr/man /usr/local/man /usr/sww/man /usr/share/man
/usr/kerberos/man"
-masterbin = "/usr/bin /usr/local/bin"
+masterbin = "/usr/bin ${PREFIX}/bin ${X11BASE}/bin"
#masterbin = "/usr/bin /usr/local/bin /usr/sww/bin /usr/sww/share/bin
/usr/sww/share/X11R5/bin"
-@@ -113,7 +113,7 @@ dpis = "75 100"
+@@ -113,7 +113,8 @@ dpis = "75 100"
# Lines are cached in .../man/cat@;
# that is, the line length is appended to the usual cache directory names
#manformat = {groff -te -Tascii -man /tmp/ll -}
-manformat = {groff -te -Tlatin1 -man /tmp/ll -}
+#manformat = {groff -te -Tlatin1 -man /tmp/ll -}
++manformat = {mandoc}
# Ultrix users should uncomment the following line (you don't have eqn)
#manformat = {tbl | nroff -man }
# HP-UX uses a number of macros that groff doesn't define, so use the builtin
nroff
-@@ -121,7 +121,7 @@ manformat = {groff -te -Tlatin1 -man /tmp/ll -}
- # space between the .de and the macro name, and groff doesn't like this.)
- #manformat = {tbl | neqn | nroff -man }
- # BSD macros (.Sh, .Ss, .PP, ...) need -mandoc
--#manformat = {groff -Tascii -te -mandoc}
-+manformat = {groff -Tascii -te -mandoc}
- # BSDI
- #manformat = {tbl | eqn -Tascii | nroff -man }
- # It's actually legal to leave this empty if all the pages you'll ever
-@@
Re: Remove textproc/glimpse?
Hi Klemens,
Klemens Nanni wrote on Sat, Oct 03, 2020 at 02:21:42AM +0200:
> On Sun, Sep 20, 2020 at 02:48:26PM +0200, Ingo Schwarze wrote:
>> Judging from patch-Makefile, it ought to be trivial to remove the
>> dependency on glimpse.
> True, so let's do that and keep the port as you outlined potential use
> for it.
> Feedback? OK?
OK schwarze@, this is already a clear improvement.
After this, more work should be done:
* Remove the hidden dependency on textproc/groff and use mandoc(1)
instead. Fixing patch-Makefile is probably sufficient to achieve
that.
So far, i did not investigate how the following can be achieved,
but they are clearly needed and i'd be surprised if they were hard:
* Remove the requirement to set MANPATH.
Use the default instead.
Or even better, use /etc/man.conf if feasible.
* Remove the warning that the "whatis" file is missing
* Remove warning about stray cats
* And probably more.
Also, there *are* formatting problem with the output the program
produces, for example with respect to line breaks.
So there is still a lot of work to do, but even without all that,
the port is already partially useable.
Yours,
Ingo
> Index: Makefile
> ===
> RCS file: /cvs/ports/misc/tkman/Makefile,v
> retrieving revision 1.26
> diff -u -p -r1.26 Makefile
> --- Makefile 12 Jul 2019 20:47:54 - 1.26
> +++ Makefile 3 Oct 2020 00:14:57 -
> @@ -3,7 +3,7 @@
> COMMENT =Tcl/Tk-based manual browser
>
> DISTNAME = tkman-2.2
> -REVISION = 0
> +REVISION = 1
> CATEGORIES = misc
> HOMEPAGE = http://www.sourceforge.net/projects/tkman
> MAINTAINER = Stuart Cassoff
> @@ -15,8 +15,7 @@ MASTER_SITES = ${MASTER_SITE_SOURCEFORGE
> MODULES =x11/tk
>
> RUN_DEPENDS =${MODTK_RUN_DEPENDS} \
> - textproc/rman \
> - textproc/glimpse
> + textproc/rman
>
> NO_TEST =Yes
>
> Index: patches/patch-Makefile
> ===
> RCS file: /cvs/ports/misc/tkman/patches/patch-Makefile,v
> retrieving revision 1.4
> diff -u -p -r1.4 patch-Makefile
> --- patches/patch-Makefile5 Jan 2011 17:34:17 - 1.4
> +++ patches/patch-Makefile3 Oct 2020 00:19:14 -
> @@ -1,6 +1,7 @@
> $OpenBSD: patch-Makefile,v 1.4 2011/01/05 17:34:17 stu Exp $
> Makefile.origFri Dec 10 19:26:34 2010
> -+++ Makefile Fri Dec 10 19:35:54 2010
> +Index: Makefile
> +--- Makefile.orig
> Makefile
> @@ -25,7 +25,7 @@ mintk = 8.4
>
> ### you need to localize the paths on these lines
> @@ -57,25 +58,16 @@ $OpenBSD: patch-Makefile,v 1.4 2011/01/0
> # printing string for preformatted pages without [tn]roff source
> #catprint = lpr
> #catprint = "lpr -h"
> -@@ -201,14 +201,15 @@ shortnames = 0
> - # the right-topmost menu's Rebuild Database/Glimpse Index menu choice.
> -
> +@@ -203,7 +203,7 @@ shortnames = 0
> # BY DEFAULT OFF
> --glimpse = ""
> -+#glimpse = ""
> + glimpse = ""
> # Glimpse on, with Boolean scope set to entire file
> -glimpse = "glimpse -W"
> +#glimpse = "glimpse -W"
> # give the full path, if you'd like
> #glimpse = /usr/sww/bin/glimpse
> # variations (refer to the Glimpse manual page)
> - # no characters treated as meta characters:
> - #glimpse = "glimpse -Wk"
> -+glimpse = "glimpse -z"
> - # compressed manual pages are handled automatically; don't add -z to above
> -
> - # glimpseindex indexes the manual pages, for each component of one's
> MANPATH,
> -@@ -460,7 +461,7 @@ install: tkman retkman
> +@@ -460,7 +460,7 @@ install: tkman retkman
> chmod +rx $(BINDIR)/tkman
> $(CP) retkman $(BINDIR)
> chmod +rx $(BINDIR)/retkman
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: schwa...@cvs.openbsd.org2020/10/02 14:18:32 Modified files: textproc/igor : Makefile textproc/igor/patches: patch-igor_1 Log message: 1. update a .Lk, patch from Alan ; upstream agrees 2. fix a wrong .Xr; i shall also report this upstream OK sthen@ tb@ kn@
local polishing of textproc/igor
Hi,
we rarely patch manual pages of ports, but the port textproc/igor
that i maintain is in a somewhat awkward situation right now
so i'd like to fix it locally.
1. I noticed a cross reference that is completely wrong
and quite likely to confuse users.
2. A web link given in the manual page went 404, and a replacement
is readily available but not especially easy to find.
This issue was reported by Alan .
I talked to upstream and Warren Block does not plan to roll a new
release in the forseeable future, so waiting for that is not helping
our users.
OK?
Ingo
Index: Makefile
===
RCS file: /cvs/ports/textproc/igor/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- Makefile12 Jul 2019 20:49:59 - 1.7
+++ Makefile2 Oct 2020 19:27:41 -
@@ -2,7 +2,7 @@
COMMENT = FreeBSD Documentation Project sanity check script
VERSION = 1.595
-REVISION = 0
+REVISION = 1
DISTNAME = igor-${VERSION}
CATEGORIES = textproc
HOMEPAGE = http://www.wonkity.com/~wblock/igor/
Index: patches/patch-igor_1
===
RCS file: /cvs/ports/textproc/igor/patches/patch-igor_1,v
retrieving revision 1.3
diff -u -p -r1.3 patch-igor_1
--- patches/patch-igor_129 Nov 2017 13:26:36 - 1.3
+++ patches/patch-igor_12 Oct 2020 19:27:41 -
@@ -1,11 +1,22 @@
$OpenBSD: patch-igor_1,v 1.3 2017/11/29 13:26:36 schwarze Exp $
-Chunks 1+3: Do not report contractions by default (local change).
-Chunks 2+4: Do not use /usr/local/etc/ (local change).
+Chunk 1: Correct wrong cross reference (also submitted upstream).
+Chunks 2 and 3(3): Do not report contractions by default (local change).
+Chunks 3(1) and 4: Do not use /usr/local/etc/ (local change).
+Chunk 3(2): Correct link to Debian wordlist (agreed with upstream).
Index: igor.1
--- igor.1.orig
+++ igor.1
+@@ -30,7 +30,7 @@ to detect a file's type and only runs the applicable t
+ Files compressed with
+ .Xr gzip 1
+ or
+-.Xr bzip 2
++.Xr bzip2 1
+ are automatically decompressed.
+ If multiple files are specified, filenames are displayed before each
+ is analyzed.
@@ -104,7 +104,7 @@ When ready for the actual commit, run
.Nm
without this option to check the date.
@@ -15,7 +26,7 @@ Index: igor.1
.It Fl z
Run all applicable non-whitespace
.Pq content
-@@ -154,7 +154,7 @@ documents.
+@@ -154,15 +154,21 @@ documents.
Additional files of misspelled words may be added with the
.Ev IGORSPELLFILES
environment variable, or placed in the
@@ -24,8 +35,10 @@ Index: igor.1
directory.
The first word on each line, including apostrophes, will be included in the
list of known misspellings to be checked.
-@@ -163,6 +163,12 @@ The Debian project has a list of words at
- .Li
http://anonscm.debian.org/gitweb/?p=lintian/lintian.git;a=blob_plain;f=vendors/debian/ftp-master-auto-reject/data/spelling/corrections;hb=HEAD
+ Blank lines and lines starting with a # character are ignored.
+ The Debian project has a list of words at
+-.Li
http://anonscm.debian.org/gitweb/?p=lintian/lintian.git;a=blob_plain;f=vendors/debian/ftp-master-auto-reject/data/spelling/corrections;hb=HEAD
++.Lk
https://salsa.debian.org/lintian/lintian/-/raw/master/data/spelling/corrections
.It Fl u
Identify contractions, which make translation more difficult.
+This test is off by default on
Re: Remove textproc/glimpse?
Hi Klemens, Klemens Nanni wrote on Sat, Sep 19, 2020 at 10:45:19PM +0200: > On Sat, Sep 19, 2020 at 08:08:43PM +0200, Stefan Hagen wrote: >> misc/tkman depends on textproc/glimpse. Judging from patch-Makefile, it ought to be trivial to remove the dependency on glimpse. >> This one would have to go too. >> I haven't found any other dependency. > Thanks for digging, tkman looks like a port we could zap: I can start > it with `MANPATH=/usr/share/man tkman' and the window appears for a few > seconds but then closes again without any error message or non-zero exit > code. I fail to reproduce the crash you report, but the window does contain lots of error messages when i start tkman(1): || Problems in component paths of MANPATH environment variable... || /usr/share/man -- no `whatis' file for apropos ||=> generate `whatis' with mkwhatis/makewhatis/catman The above basically means tkman is incompatible with OpenBSD at least in some respects, though patching that might be possible and perhaps even easy. It obviously requires an old-style "whatis" database which we deleted years ago. It doesn't respect our man.conf(5) either, instead hardcoding the manpath in patch-Makefile. Requiring MANPATH to be set is quite bad. People should *not* set MANPATH because that will sooner or later cause some manual pages to not be found. The MANPATH feature is only intended for rare and exotic tasks like reading non-English manual pages, like temporarily using non-standard trees (e.g. from the man-pages-posix port), or for debugging individual trees. || Stray cats (formatted pages in .../man/catN without corresponding || source in .../man/manN) || /usr/local/man/cat1 || mwm uil xmbind xwit That means it doesn't understand the concept of preformatted-only pages either (which is used for pages where the source code is of insufficient quality for installation, or unavailable in the first place). All that said, significant numbers of features (of which there are really many) work as advertised at least part-way, even some that i would have thought likely to fail outright. So even though i don't know how good the overall code quality really is, it does seem to be surprisingly robust. > Does anyone have a use for such an outdated manual browser/reader GUI > which does not work by default and requires another ancient port? There are some feature that may be interesting to some users, like * hypertext links * texinfo support * expandable/collapsable sections in manual pages * some fancy syntax highlighting (personally, i hate syntax highlighting, but i know many like it) * and several others At the very least, the port implements several interesting ideas that could inspire future development of manual page browsing tools, so it would seem a bit sad from where i stand to kill it. > OK to remove misc/tkman? I wouldn't very strongly object to deletion if porters think that the port makes their life harder or impedes progress, but given that it looks like the dependency on glimpse can easily be removed, i don't see which kind of trouble the port could cause. It could certainly benefit from an active maintainer who investigated and fixed issues. My impression is significant numbers of minor issues exist, but nothing that strikes me as making the port completely useless. Also, the patch-Makefile contains some very outdated decisions. For example, it explicitly uses groff for formatting rather than mandoc. Some work should be done on this one. I have to admit that personally, i care more about console support than about GUIs, but if somebody wants to improve GUI support for manual page display on OpenBSD, this port seems like child likely to reward some love shown to it. Also, i'm not aware of a better GUI to display manual pages. Yours, Ingo
Re: Update: devel/py-wcwidth 0.1.9 -> 0.2.5
Hi Kurt, Kurt Mosiejczuk wrote on Sat, Sep 12, 2020 at 06:28:30PM -0400: > Update py-wcwidth from 0.1.9 to 0.2.5 This library is a very bad idea, it should better not exist. Python should use native wcwidth(3) instead. PKG-INFO says: This library attempts to determine the printable width [...] using the very latest Unicode specification. [...] The libc version of `wcwidth(3)`_ is often several unicode releases behind, and therefor several levels of support lower than this python library. That's just not true on OpenBSD where wcwidth(3) is very diligently maintained by afresh1@ in a timely manner. Even on systems where libc *is* behind, using a newer version on the application level is a very bad idea because the goal must be to have consistent data between the application program and the terminal emulator. Now the terminal emulator is (hopefully) using libc and certainly not using this Python library, so using the latest and greatest on the application level achieves nothing but inconsistency and hence misformatting in the terminal, whereas using the same native libc function in both Python and the terminal emulator would yield better results, even if the Unicode data data were slightly outdated. Not sure this observation should stand in the way of a routine update - but it might potentially make sense to deliver a dummy version on OpenBSD instead that merely calls through to libc and does not attempt to do any work whatsoever on its own. Yours, Ingo
Re: Tons of empty man pages for new ports for LedgerSMB
Hi Chris, Chris Bennett wrote on Sun, Aug 30, 2020 at 11:17:24PM -0500: > On 2020/08/27 20:51, Chris Bennett wrote: >> I just found a bunch of new Locale perl modules added to the depends >> list. >> >> They all have empty man pages from no PODs. >> About 20ish ports, most are just relevant data files for each language. >> >> Should I just delete these from the PLISTs or is there an easier way to >> prevent their generation? [...] > The man page problem is from the modules only having just enough of a > POD to name the package. Nothing else. If i understand correctly what you are saying and if your assessment is correct (i didn't check), then essentially upstream is shipping empty manual pages. In such a case, commenting them out in the PLIST seems reasonable to me. Maybe put a comment similar to the following above them, to reduce the risk that upstream later adds content to them but we keep them commented out: @comment When updating, check whether these manuals are still empty. Yours, Ingo
Re: [NEW-WIP] p5-Plack-Request-WithEncoding mandoc errors, BUILD_DEPENDS question
Hi Andrew, hi Chris,
Chris Bennett wrote on Sun, Aug 16, 2020 at 01:01:07PM -0500:
> On Sat, Aug 15, 2020 at 09:39:58PM -0700, Andrew Hewus Fresh wrote:
>> On Wed, Aug 12, 2020 at 11:15:49AM -0500, Chris Bennett wrote:
>>> I submitted p5-Plack-Request-WithEncoding-0.13 previously.
>>> Newer version just went up. Upstream is friendly to changes.
>>>
>>> The POD has some problems that cause mandoc errors after noticing
>>> that the man page looked bad.
>> I think that's just the way the pod is written. It seems the author
>> likes a much wider terminal than I do and so things just wrap weird.
>> If I pull my terminal out to at least 150 columns it looks better.
>>
>> I think the only fix is to reformat the content into something that fits
>> into a more reasonably sized terminal.
I did not check the manual page (it seems the port is not yet
committed?), so unless someone says otherwise, i'll assume afresh1@
is right, this individual manual page is wrong, and this part is
not a formatter problem.
>>> # mandoc -T lint /usr/local/man/man3p/Plack::Request::WithEncoding.3p
>>> mandoc: /usr/local/man/man3p/Plack::Request::WithEncoding.3p:35:1: \
>>> ERROR: escaped character not allowed in a name: br\&
>>>
>>> I'm not familiar enough with POD to man to know what the right change
>>> is. Upstream accepted my previous documentation changes without a
>>> problem.
>> I'm pretty sure that's just what pod2man outputs, so the fix is probably
>> unrelated to this particular port. If you run that lint command against
>> any other 3p manpage and they are pretty much all the same.
Ouch. I just fixed that in mandoc, with the following commit.
Thanks for mentioning the issue.
Yours,
Ingo
Log Message:
---
Avoid artifacts in the most common case of closing conditional blocks
when no arguments follow the closing brace, \}.
For example, the line "'br\}" contained in the pod2man(1) preamble
would throw a bogus "escaped character not allowed in a name" error.
This issue was originally reported by Chris Bennett on ports@,
and afresh1@ noticed it came from the pod2man(1) preamble.
Modified Files:
--
mandoc:
roff.c
Revision Data
-
Index: roff.c
===
RCS file: /home/cvs/mandoc/mandoc/roff.c,v
retrieving revision 1.375
retrieving revision 1.376
diff -Lroff.c -Lroff.c -u -p -r1.375 -r1.376
--- roff.c
+++ roff.c
@@ -2362,7 +2362,9 @@ roff_cond_checkend(ROFF_ARGS)
while ((ep = strchr(ep, '\\')) != NULL) {
switch (ep[1]) {
case '}':
- if (rr)
+ if (ep[2] == '\0')
+ ep[0] = '\0';
+ else if (rr)
ep[1] = '&';
else
memmove(ep, ep + 2, strlen(ep + 2) + 1);
Re: Firefox and MIME
Hi Landry, Landry Breuil wrote on Thu, Jul 30, 2020 at 04:34:56PM +0200: > On Wed, Jul 29, 2020 at 11:22:20PM +0100, Laurence Tratt wrote: >> -section of about:support. For this feature, WebGL2 is necessary, so your >> +section of about:support. For this feature, WebGL2 is necessary, so your > Removed this extra space, dunno if there's a convention for this in pure > academic english but it looked wrong to me. *shrug* ? The spacing as you kept it, with the same horizontal spacing between sentences as between words, is usually called "French Spacing" in English. :) [That's a somewhat simplified statement.] French spacing was unusual in English typing and typesetting until about 1945, but in modern English typography, since at least the 1990, having a wider space between sentences is now almost universally regarded as needless and sometimes as somewhat old-fashioned (even though some, including myself, still like it). It is a not-so-productive but notorious matter of debate. Putting the double space after sentences is still useful in roff(7) input because that's the only practical way at all to tell the roff(1) program "a sentence ends here". How the typesetter will then represent the sentence space on the output side is a matter of output settings. For plain ASCII and UTF-8 text files, it doesn't really matter. Use whatever style you like. What definitely still matters is the related concept "new sentence, new line" in manual pages. Yours, Ingo > anyway, thanks for the improvements, appreciated ! That forced me to do > some needed port/Makefile cleanup... Indeed, nice.
Re: to Pandoc or not
Hi Marc, Marc Espie wrote on Wed, Jul 15, 2020 at 11:44:32AM +0200: > On Wed, Jul 15 '20 at 05.50 NZST, Ingo Schwarze wrote: >> I never found pandoc useful for anything - so much so that i never >> even felt a need to evalute its quality for real. I dimly remember >> that on rare occasions, i saw man(7) output generated by pandoc, >> and if i remeber correctly, that was of poor quality - but i'm not >> sure and it isn't terribly relevant because pandoc is used very >> rarely in practice in the first place. >> >> What do you want to do with it? > I have colleagues that use pandoc to produce docs, because it's simple > and heck, they've normalized on it. > > I myself prefer to generate documents straight from LaTeX, but it means > I can't directly work with them. > > That's most often the situation. > > I would also like a pandoc port. That does sound fair, and it teaches me that even for things where it may be hard to come up with a reasonable statement of the form "it's a good solution to solve problem X", there can indeed be a good reason to have a port. Even if "useful to send HTML email" sounds about as oxymoronic to me as it gets. =:-o > There are about 80 haskell dependencies for > it, none of it is in our ports tree yet. No way i'm going to help with a beast of that kind, of course. :) In the most important port i maintain (also in the textproc category and useful for documentation), i pay particular attention to make sure that it never grows a single dependency. Not even one. Yours, Ingo
Re: to Pandoc or not
Hi, sven falempin wrote on Tue, Jul 14, 2020 at 01:23:21PM -0400: > Is anyone working on that for openbsd ? > > https://github.com/freebsd/freebsd-ports/blob/master/textproc/hs-pandoc/Makefile I never found pandoc useful for anything - so much so that i never even felt a need to evalute its quality for real. I dimly remember that on rare occasions, i saw man(7) output generated by pandoc, and if i remeber correctly, that was of poor quality - but i'm not sure and it isn't terribly relevant because pandoc is used very rarely in practice in the first place. What do you want to do with it? Yours, Ingo
Re: fatal error: 'wordexp.h' file not found
Hi, deserter...@danwin1210.me wrote on Thu, Jul 09, 2020 at 05:38:18PM -: > wordexp.h is part of glibc: functions, constants and data types for word > expansion are declared in the header file `wordexp.h'. > > But it is not in my system! Is this by design? or an error? The absence of wordexp(3) from OpenBSD is intentional. https://marc.info/?l=openbsd-tech=127053352511782=2 "This patch adds support for wordexp(3) and wordfree(3) to libc." https://marc.info/?l=openbsd-tech=127056947124559=2 tedu@: "What a load of crap." https://marc.info/?l=openbsd-tech=127057160727771=2 deraadt@: "I think we should stand up to crap and not ever implement it." The interface is so outrageously ill-designed that we decided to not provide it, even though it is part of POSIX. Talk to the upstream program author and ask them to use a saner API instead. Yours, Ingo
Re: CVS: cvs.openbsd.org: ports
Ingo Schwarze wrote on Tue, May 05, 2020 at 06:58:09AM -0600: > CVSROOT: /cvs > Module name: ports > Changes by: schwa...@cvs.openbsd.org2020/05/05 06:58:09 > > Modified files: > www/youtube-dl : Makefile distinfo > > Log message: > update to youtube-dl-2020.05.03; > committing quickly to interfere as little as possible with the lock; > OK sthen@ Sorry! This was sent in by .
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: schwa...@cvs.openbsd.org2020/05/05 06:58:09 Modified files: www/youtube-dl : Makefile distinfo Log message: update to youtube-dl-2020.05.03; committing quickly to interfere as little as possible with the lock; OK sthen@
Re: keynav man page
Hi Damien, thanks for trying to help! However, there are large numbers of questions to answer and large amounts of work to do before this can usefully go anywhere. One thing up front: Damien Thiriet wrote on Sat, May 02, 2020 at 06:30:25PM +0200: > Since I am not a programmer, and cannot run -current, the only way for > me to contribute to the project is to deal with documentation Even for that, you need to run -current, and even for working on ports, you need sufficient programming skills to work on Makefiles. If you lack parts of the needed skills, learn! So, here is a plan for you: 1. This port had its last release in 2011. So on first sight, it appears to be abandoned, i.e. no longer maintained upstream. Please contact upstream, thank them for their work, tell them that you use and enjoy it, ask them whether they still maintain it, tell them that you have started to prepare improvements, and ask them whether they might consider integrating improvements and roll a new release if it turns out they like your work. 2.a) If they say they have abandoned their program and won't make a new release, or if they do not answer, your only real option to improve the program is to take over upstream maintenance. Ask yourself whether you want to do that, and if yes, do take over. 2.b) If upstream is still active, instead work with upstream to get your improvements integrated. 3. If at this point, we don't have an upstream maintainer, we need to decide whether to keep the port around or whether to delete it outright from the OpenBSD ports tree. Security-critical or large programs without an upstream maintainer are usually deleted from the ports tree. Keeping small, relatively harmless programs around may be acceptable even when they are dead upstream, but we don't usually try to improve programs in the ports tree that are dead upstream. So, even if we keep the port around, you have more or less come to a dead end with your work until you find someone who maintains the program in general, not just in our ports tree. Again, that can be you. 4. If you want to submit patches to the OpenBSD port, no matter of which kind, even to just improve documentation, you *must* run OpenBSD-current. There is no excuse. We just don't do updates for -stable ports (except to fix security issues, and that is only done *after* fixing them in -current, and never by external contributors). 5. The OpenBSD port is outdated. We have 20101014, upstream has 20110708. The very first thing to do in our ports tree would be to decide whether the port can and should be updated to 20110708. If yes, do it. If no, dependiing on which issues prevent an update, try to resolve them. 6. Upstream is doing a very stupid thing. They do have a manual page, but they fail to include it in the distribution tarball. The manual page file is called "keynav.pod". It is neither in mdoc(7) nor in man(7) format, but it is still a manual page, using the third-best perlpod(1) format. Get upstream to include that file in the distribution tarball for their next release. 7. In the meantime, while upstream is working on the next release, if you are in a hurry to get the manual page into the port, make the port * download the manual page during the "fetch" target, see bsd.port.mk(1) for details, look for the DISTFILES variable in there, https://man.openbsd.org/bsd.port.mk#DISTFILES * then format it with pod2man(1) during the "post-build" phase, see the fifth and seventh entries in TARGETS near the very top of bsd.port.mk(1) * then install it during the "post-install" phase * then use "make update-plist" * then submit a port update with a REVISION bump 8. If you want to switch the manual page from perlpod(1) to mdoc(7), work with upstream to do so. We will not change the markup language of the documentation in the ports tree as long as upstream sticks to a different language. 9. If you want to improve the content of the manual page, work with upstream to do so. > You'll find below a keynav.mdoc file as a proposal for keynav ports. > Any hints to improve the structure with regards to OpenBSD standards > welcome. >From an extremely brief glance at your work, i see dozens of serious problems with it where that work can be improved (even though it seems to be good work). Unless you confirm that you have established contact with upstream and they want to take patches, or until you have taken over upstream maintenance, i am not planning to invest the time needed to explain all those deficencies. > I read the mdoc(7) and mandoc(8) man pages, used pod2mdoc to convert > keynav.pod, looked at several base examples (cwm.1, cwm.5, ksh.1, > grep.1, tmux.1) and made the converted file fit mdoc recommandations,
Re: [UPDATE]: games/freeorion 0.49
Hi Tom, Tom Murphy wrote on Fri, May 01, 2020 at 01:34:08PM +0100: > Any update on this? Can it be committed? > (I am the maintainer) Thanks for working on this, but now is not the time to commit an Update because we are preparing the OpenBSD 6.7 release right now. Updating the game is non-essential for the release, and besdes, FreeOrion is a very massive beast. I think this should better wait until after the release has been rolled out of the door. Yours, Ingo > I believe the memory issues for compiling are just that > ulimit -d needs to be increased to allow it to compile.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: schwa...@cvs.openbsd.org2020/04/29 09:25:45 Modified files: mail : Makefile devel/quirks : Makefile devel/quirks/files: Quirks.pm infrastructure/db: user.list Removed files: mail/akpop3d : Makefile distinfo mail/akpop3d/patches: patch-Makefile_in patch-akpop3d_8 patch-authenticate_c patch-lock_maildrop_c patch-lock_maildrop_h patch-main_c patch-pop3_session_c patch-tcp_listen_c patch-tcp_listen_h mail/akpop3d/pkg: DESCR PLIST Log message: Delete mail/akpop3d. Alexei dot Malinin at mail dot ru reported a compiler warning that, in my opinion, probably indicates a security vulnerability, but due to an incomplete description of the affected feature in the documentation, it is unclear how it should be fixed. The program appears to be sloppily written, sloppily documented, and abandoned upstream 15 years ago. OK ajacoutot@ for deleting it.
Re: mail/akpop3d authenticate.c:user_in_file bug
Hi Alexei,
Alexei Malinin wrote on Tue, Apr 28, 2020 at 01:05:23AM +0300:
> I ported akpop3d to NetBSD and found the Subject.
> GCC warning was the following:
> authenticate.c: In function 'is_user_allowed':
> authenticate.c:110:11: warning: switch condition has boolean value
> [-Wswitch-bool]
This is a textbook example of how you must *not* react to a compiler
warning. Do not apply random patches just to shut up the compiler,
without understanding what the code does or what your patches change.
Such reckless behaviour is exactly how Debian produced the spectacular
security vulnerability in their port of OpenSSH several years ago.
>From pure code inspection, i conclude that what you report is very
likely a security vulnerability.
What the code currently does is this:
* If the file /etc/pop3.deny does not exist or an error occurs
reading from it, all users are denied access.
* If the file /etc/pop3.deny exists and can be read,
users listed in the file are denied access, but
*all* users *not* listed in the file are granted access.
* In either case, the file /etc/pop3.allow is totally ignored.
It may or may not exist, and if it does, the contents are
read, but whatever is in there makes no difference whatsoever.
* Note that the confusing condition
if ((allow == 0 && deny == 0) || (allow == 1 && deny == 0)) {
a few lines below is equivalent to just
if (deny == 0) {
and consequently, the assignments to the variable "allow" are
effectively dead stores.
>From the akpop3d(8) manual page, it remains totally unclear what
the desired behaviour is supposed to be, but the above cannot
possibly be right. It looks as if it was never tested at all.
The only effect of your change is as follows. With your change,
we get this in addition to the above:
* If the file /etc/pop3.allow does not exist or an error occurs
reading from it, all users are denied access.
* But if it can be read, its contents are still totally
ignored.
Quite obviously, that cannot possibly be correct behaviour either,
so if there is a vulnerability (hard to say given that desired
behaviour is unspecified), it seems unlikely that your change fully
fixes it.
Judging from the website, this program has been unmaintained for
more than 15 years.
I think we should delete the port completely, giving something like
"sloppily coded, sloppily documented, severely buggy and likely
vulnerable abandonware" as the reason for deletion.
Yours,
Ingo
Re: explanation of FETCH_PACKAGES in ports(7)
Hi Marc, Marc Espie wrote on Mon, Apr 27, 2020 at 10:20:13AM +0200: > Let's try anyway. Looks good to me except for the nits below. Yours, Ingo > Index: ports.7 > === > RCS file: /cvs/src/share/man/man7/ports.7,v > retrieving revision 1.127 > diff -u -p -r1.127 ports.7 > --- ports.7 16 Jun 2019 14:24:42 - 1.127 > +++ ports.7 27 Apr 2020 08:19:41 - > @@ -620,10 +620,24 @@ try to use as options to > .Xr pkg_add 1 > to install the missing packages from If you want, you can say "to install any missing packages from" because the idea of missing packages wasn't introduced earlier, so the definite article may not be ideal. > .Ev PKG_PATH . > -For instance: > +.Xr bsd.port.mk 5 > +does not set > +.Ev FETCH_PACKAGES , > +so even an empty value amounts to setting the variable. > +.Pp > +For instance, to run > +.Nm pkg_add Please make this line .Xr pkg_add 1 because "pkg_add" is not the topic of the present manual page, ports(7). Repeated .Xrs to the same target are not a problem. > +with default options > +.Pc : These two lines should be one: with default options: > .Bd -literal -offset indent > -make FETCH_PACKAGES= > +make FETCH_PACKAGES= Please do not add trailing whitespace. > .Ed > +.Pp > +or, to enforce the snapshots directory during the final beta period: Here, i suggest saying "to enforce using the snapshots directory", or, maybe even better, "to use the snapshots directory". > +.Bd -literal -offset indent > +make FETCH_PACKAGES=-Dsnap > +.Ed > +.Pp Please delete this .Pp, it is redundant before .It in a non-compact list. > .It Ev PATCH_DEBUG > If defined, display verbose output when applying each patch. > .It Ev INTERACTIVE
Re: [UPDATE] textproc/scdoc 1.10.1
Hi Raymond,
Raymond E. Pasco wrote on Wed, Apr 01, 2020 at 07:08:22AM -0400:
> Minor update. Patches are upstreamed and thus removed.
Committed, though patch-Makefile had to remain:
Upstream is still gratuitiously setting LDFLAGS+=-static.
Changelog is at: https://git.sr.ht/~sircmpwn/scdoc/refs/1.10.1
I looked through a diff of the tarballs and found nothing suspicious.
There are no functional changes except that the program now
prints an additional comment in the second line of output files
(which isn't very useful, but oh well, upstream's choice).
Running "make test" now succeeds without patching any tests.
Thanks for sending the update,
Ingo
> diff -u textproc/scdoc/Makefile mystuff/textproc/scdoc/Makefile
> --- textproc/scdoc/Makefile Fri Jan 31 01:17:06 2020
> +++ mystuff/textproc/scdoc/Makefile Wed Apr 1 06:59:35 2020
> @@ -1,7 +1,7 @@
> # $OpenBSD: Makefile,v 1.1.1.1 2020/01/25 16:44:51 schwarze Exp $
>
> COMMENT =convert scdoc text files to man(7) pages
> -VERSION =1.10.0
> +VERSION =1.10.1
> DISTNAME = scdoc-${VERSION}
> CATEGORIES = textproc
> HOMEPAGE = https://git.sr.ht/~sircmpwn/scdoc
> @@ -21,9 +21,5 @@
> MANDIR=${DESTDIR}${PREFIX}/man
>
> TEST_TARGET =check
> -
> -# will attempt to run the unpatched tests if they are not rm'd
> -pre-test:
> - rm ${WRKSRC}/test/*.orig
>
> .include
> diff -u textproc/scdoc/distinfo mystuff/textproc/scdoc/distinfo
> --- textproc/scdoc/distinfo Fri Jan 31 01:17:06 2020
> +++ mystuff/textproc/scdoc/distinfo Wed Apr 1 07:00:24 2020
> @@ -1,2 +1,2 @@
> -SHA256 (scdoc-1.10.0.tar.gz) = NILgi5lMxKUoyvPSDdcO/aLS7IazD2avdaHRkv7laFI=
> -SIZE (scdoc-1.10.0.tar.gz) = 12414
> +SHA256 (scdoc-1.10.1.tar.gz) = gOAhxzLMos1mWdzPMwbUb1nuy/j7qk2r21AvU3J4p48=
> +SIZE (scdoc-1.10.1.tar.gz) = 12422
> Only in textproc/scdoc: patches
> Common subdirectories: textproc/scdoc/pkg and mystuff/textproc/scdoc/pkg
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: schwa...@cvs.openbsd.org2020/04/04 10:58:27 Modified files: textproc/scdoc : Makefile distinfo textproc/scdoc/patches: patch-Makefile Removed files: textproc/scdoc/patches: patch-test_preamble Log message: minor update to textproc/scdoc-1.10.1; patch from Raymond E. Pasco on ports@
Re: pkg/PLIST automation
Hi Martin,
Martin wrote on Sat, Mar 21, 2020 at 06:07:57AM +:
> make fake -> make update-plist successfully generates PLIST but
>
> make package and make install produce an error:
>
> make: don't know how to make /usr/ports/packages/.tgz
> (prerequisite of: /usr/ports/packages/amd64/all/uhd-3.15.0.0p0)
It is hard to judge what exactly went wrong without seeing your
Makefile.
You are supposed to follow thw documentation (e.g. bsd.port.mk(5))
and also use it for debugging. If you can't find your mistake by
looking at the documentation, you can try looking at the code -
in this case /usr/ports/infrastructure/mk/bsd.port.mk - to find
out where exactly things break, then deduce from that what your
error might be and go back to the documentation how the specific
thing(s) that broke for you are supposed to be used correctly.
If you can't find your own mistake and ask for the help of others
to find them, you are supposed to provide complete information.
It is hard to find your error without seeing your Makefile.
Here is an example of how i might proceed to debug the message above
if the documentation wouldn't help me (assuming you did not
set MULTI_PACKAGES):
- search for "\.tgz" -> line 965
so ${FULLPKGNAME${_S}} seems to be empty
- without MULTI_PACKAGES, _S is "-"
(leaving it as an exercise why that is so)
- line 636: FULLPKGNAME- is set to ${FULLPKGNAME}
- line 611: FULLPKGNAME is set to ${PKGNAME}${FLAVOR_EXT}
So try to find out whether in your Makefile, you fiddled with
variables like PKGNAME or FULLPKGNAME in an invalid manner.
While reading bsd.port.mk, you can also use commands like
make show=FULLPKGNAME-
make show=FULLPKGNAME
make show=PKGNAME
to inspect various variables that file is using, to debug your Makefile.
I find it hard to be more specific given the amount of information
you provided.
If you did try to use MULTI_PACKAGES, first try to get it to work
without that, then add MULTI_PACKAGES once everything works without it.
Yours,
Ingo
Re: pkg/PLIST automation
Hi Martin, Martin wrote on Fri, Mar 20, 2020 at 03:59:42PM +: > Any automation suggestions for pkg/PLIST create for a new port? Read all of: https://www.openbsd.org/faq/ports/guide.html#PortsChecklist In this case, the answer to your question is in step 22. make update-plist Yours, Ingo
Re: HS_ENCODING in localeEncoding
Hi Greg, take this with a shovel of salt as i didn't test the port or anything with Haskell (and i'm unlikely to). So this is purely from code inspection. Greg Steuck wrote on Sun, Feb 02, 2020 at 10:00:06PM -0800: > Do you believe lang/ghc/patches/patch-libraries_base_cbits_PrelIOUtils_c > is still relevant? It may have been OK in 2015, but it looks rather bogus now. > I ran some test programs and both locale_charset() and The function locale_charset() appears to be part of the converters/libiconv package, but it appears to be totally undocumented. I failed to find any documentation whatsoever: neither in the package nor even with Google on the web. While iconv(3) is in POSIX, locale_charset() is not. I think we should avoid using stuff when it is unclear what it is, so consider forcing HAVE_LIBCHARSET to undefined in the port (i'm not saying you must do this, only that it could be considered). > nl_langinfo(CODESET) yield sensible results (at least for UTF8). And indeed, UTF-8 is the only non-POSIX charset that OpenBSD supports, and there are no plans to support any others in the future. Consequently, nl_langinfo(CODESET) will always return either "US-ASCII" or "UTF-8" on OpenBSD. > The > history of the patch seems to go back approximately 10 years, so maybe > OpenBSD locale support improved enough to consider dropping the patch? I think so. Three apsects of the patch look bogus in particular: 1. Avoiding nl_langinfo(3). There is no longer anything wrong with that function. 2. Inspecting HS_ENCODING. It appears the code wants to inspect the current locale. If any environment variable, then LC_ALL/LC_CTYPE/LANG should probably be inspected, not HS_ENCODING. The code in the patch gives me the impression that this is probably already done with setlocale(3) elsewehere in the program, so i'm not sure the environment should be inspected again. Also, using setlocale(3) is almost always preferable to manual inspection of environment variables. 3. Setting anything to "latin1". Given that we don't even support that locale at all, that's the worst of the three dubious aspects. > I'll rebuild GHC without that patch locally but also wanted to check > with you in the meantime. Right, and you might also try convincing ./configure (or whatever is used in the build system) to switch HAVE_LIBCHARSET off, unless that has unrelated detrimental effects. Yours, Ingo
Re: Issues with manuals+amd(8) for a handful of ports
Hi, are there any other users who have /usr/local or /usr/local/man as a symlink or mounted via amd(8)? Note that i do NOT recommend such very unusual configurations at all, they have caused trouble in the past, i'm merely asking for testing purposes. If you use such a configuration, please update your mandoc such that you have OpenBSD: mandocdb.c,v 1.215 (or later) (by installing a snapshot dated at least a full day after 2020/01/26 21:24:58 UTC or by compiling from source and installing in /usr/src/usr.bin/mandoc/) and try whether after installing packages that contain symlinks in manual page directories, man(1) works as expected on such manual pages even *without* running makewhatis(8) manually and *without* running weekly(8). And of course, watch out whether you see any regressions. It turned out the filescan() function in mandocdb.c is well suited as a habitat for worms, and if i have disturbed any of them with the commit below, i'd prefer appeasing them again ASAP, well before we approach release. Here are a few examples of manual pages that are good for testing: package manual page vim rgvim # as opposed to vim(1) itself python-2.7python2# as opposed to python2.7(1) openldap-client ldap_init # as opposed to ldap_open(3) texlive_texmf-minimal pdflatex # as opposed to pdftex(1) The following command may give you more examples of pages for testing on your system: $ find /usr/local/man -type l Please make sure that *after* updating mandoc, you pkg_delete(1) the package(s) in question and then pkg_add(1) them anew, and only test man(1) after that. Please report any cases where pages aren't found as expected, report any messages similar to man: outdated mandoc.db lacks rgvim(1) entry, run makewhatis /usr/local/man you may encounter, and report any other regressions. Always include output from "man -w" for the pages you are trying to read, in addition to describing your findings. In case any of this screws up your system, running makewhatis(8) manually without any arguments will almost certainly fix it (but please report first). Do not attempt to downgrade again in the unlikely case that testing reveals issues; that would be more likely to make matters worse rather than help. Finally, note that nothing is wrong in pkg_add(1), the issues were in makewhatis(8) only. Thanks, Ingo CVSROOT:/cvs Module name:src Changes by: schwa...@cvs.openbsd.org2020/01/26 14:24:58 Modified files: usr.bin/mandoc : mandocdb.c Log message: Repair more of the issues that i found in filescan() while investigating the report from on ports@: For a symlink, use the first of the following names that is available: 1. In -t mode, the symlink itself (unchanged). 2. When the (unresolved) symlink already resides inside the manpath, just strip the manpath and use the rest (unchanged). 3. When prefix(es) of the unresolved symlink point to the manpath, strip the longest such prefix and use the rest (new); this fixes situations where the manpath or one of its parent directories is a symlink and at the same time contains symlinks to manual pages. 4. Fall back to the fully resolved symlink, with the manpath stripped (new); this may for example happen when the command line passes symlinks from outside the manpath that point to manual pages inside the manpath, or if manual page trees contain symlinks to symlinks and not all of them are given on the command line. The fallback (4) isn't perfect. You can construct symlink spaghetti in such a way that this algorithm will not enter all manual page names into the database that a human would be able to deduce. But i do not expect such spaghetti to actually occur in practice (not even in ports), and a full fix would require re-implementing realpath(3) in terms of step-by-step readlink(2) calls, repeating the complicated algorithm (3) after each step. While here, also stop using PATH_MAX as the size of a static buffer in filescan(); on some systems, it can be unreasonably large. Instead, allocate path strings dynamically.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: schwa...@cvs.openbsd.org2020/01/25 09:55:32 Modified files: textproc : Makefile Log message: + scdoc
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: schwa...@cvs.openbsd.org2020/01/25 09:44:51 Log message: import scdoc-1.10.0 to convert scdoc text files to man(7) pages; based on work of Raymond E. Pasco and abieber@ using feedback from and sthen@; OK sthen@ Status: Vendor Tag: schwarze Release Tags: schwarze_20200125 N ports/textproc/scdoc/Makefile N ports/textproc/scdoc/distinfo N ports/textproc/scdoc/pkg/DESCR N ports/textproc/scdoc/pkg/PLIST N ports/textproc/scdoc/patches/patch-test_preamble N ports/textproc/scdoc/patches/patch-Makefile No conflicts created by this import
Re: Issues with manuals+amd(8) for a handful of ports
Hi Andreas,
Andreas Kusalananda wrote on Wed, Jan 22, 2020 at 08:58:26PM +0100:
> I mount my /usr/local directory from a remote server over NFS
> using amd(8). This means that I have the directories directly
> beneath /usr/local appear on demand as symbolic links into
> /tmp_mnt/eeyore/vol/local/pooh where the /usr/local for the local
> machine "pooh" is mounted over NFS from "eeyore" (and mounted/unmounted
> on demand).
>
> This works very well, but there is a handful of ports that misbehave
> with regards to manuals. Of the 70 or so pre-built packages that I've
> installed on my amd64-current system, the only ones misbehaving are
>
> databases/pkglocatedb (pkglocatedb-1.5)
> devel/git,-main (git-2.25.0)
> sysutils/p5-File-Rename-1.10(p5-File-Rename-1.10)
>
> When I do "man pkglocate", for example, I get
>
> man: /tmp_mnt/eeyore/vol/local/pooh/man//usr/local/man/man1/pkg_locate.1:
> SYSERR: open: No such file or directory
>
> ... and likewise for any other utility etc. from those ports. Commands
> like "git clone --help" gives similar diagnostics.
>
> The manuals are actually visible where they are supposed to be:
>
> $ ls -l /usr/local/man/man1/{git{,-clone},pkg_locate}.1
> -rw-r--r-- 1 root bin 20005 Jan 20 22:20 /usr/local/man/man1/git-clone.1
> -rw-r--r-- 1 root bin 50901 Jan 13 19:49 /usr/local/man/man1/git.1
> -rw-r--r-- 1 root bin 2845 Jan 19 08:14 /usr/local/man/man1/pkg_locate.1
>
> ... so it looks as if man(1) is, for whatever reason, looking in the
> wrong location for the file.
The man(1) manual page says:
The mandoc.db(5) database is used for looking up manual page entries.
In cases where the database is absent, outdated, or corrupt, man falls
back to looking for files called name.section.
However, when the database is present and in the correct format but
references non-existent files like
/tmp_mnt/eeyore/vol/local/pooh/man/usr/local/man/man1/pkg_locate.1
there is no fallback. The reason is that by the time it turns out
the file name found in the database is bogus, man(1) has progressed
beyond the stage where it can repeat the search using a different
method. Fallback to file system search only happens when no match
is found, not when the database contains a match but the path in
the database happens to be wrong.
> Manuals for other utilities, like rsync, pv, pwgen, openvpn, etc., do
> work as they should.
This sounds as if pkg_add(1) sometimes worked well but sometimes got
confused when running makewhatis(8) and consequently your database
is now corrupt in a weird way that i have never seen before.
Please show the output of
$ man -w pkglocate rsync
The expected, correct result is
$ man -w pkglocate rsync
/usr/local/man/man1/pkg_locate.1
/usr/local/man/man1/rsync.1
I expect you may see
/tmp_mnt/eeyore/vol/local/pooh/man//usr/local/man/man1/pkg_locate.1
/usr/local/man/man1/rsync.1
I suspect if you run
# makewhatis /tmp_mnt/eeyore/vol/local/pooh/man
the problem may go away, but after that, you may no longer be able
to reproduce the problem. Also, the problem might re-emerge when
you install more packages because pkg_add(1) will run makewhatis(8)
on /usr/local/man, not on /tmp_mnt/... - and so will weekly(8).
In general, makewhatis(8) dislikes symbolic links pointing outside
the respective manpath and uses realpath(3) to normalize them,
then rejects the files if they aren't in a valid location.
What's a bit weird is that here it apparently accepted the files
but then somehow constructed wrong filenames anyway.
I might have to do some experimentation with symlinks to figure
out what exactly is going on.
You could also go to
$ cd /usr/src/regress/usr.bin/mandoc/db/dbm_dump
$ man mandoc.db
$ man -l dbm_dump.1
$ rm -f obj
$ make cleandir
$ make obj
$ make cleandir
$ make
$ ./obj/dbm_dump /usr/local/man/mandoc.db | less
to look at the (probably) broken database in detail.
> I haven't created or changed any MAN* environment variables nor do I
> have a /etc/man.conf file. I haven't been able to figure out what's
> special about the manuals for these ports.
I don't expect anything to be special about these ports; i suspect
that makewhatis(8) was run in a slightly different way or under
slightly different circumstances. I'm not surprised that your
stunt of symnlinking /usr/local/man somewhere else turns out to be
fragile.
Yours,
Ingo
Re: reference pkg-readmes in manual pages
Hi, Claus Assmann wrote on Fri, Jan 24, 2020 at 05:18:14PM +0100: > On Fri, Jan 24, 2020, Ingo Schwarze wrote: >> Claus Assmann wrote on Fri, Jan 24, 2020 at 09:25:27AM +0100: >>> I didn't find a hint about pkg-readmes in the man pages :-( >>$ man -k any=pkg-readmes > I only tried > man -k pkg-readmes Right, the reason Nm,Nd= is the default with -k and not any= is that any= can be quite noisy (and in addition, there is tradition). The reason i used any= here anyway was that i wanted to check completeness of manual pages rather than merely read some. If you want to know what a file is that doesn't have its own manual page, try Pa=. Compare $ man -k Pa=words # explains /usr/share/dict/words $ man -k words # a small amount of random stuff $ man -k Nm,Nd=words# the same $ man -k any=words # lots of noise Yours, Ingo
reference pkg-readmes in manual pages
Hi, Claus Assmann wrote on Fri, Jan 24, 2020 at 09:25:27AM +0100: > On Thu, Jan 23, 2020, Landry Breuil wrote: >> have a look at the pkg-readme provided by the package. > I didn't find a hint about pkg-readmes in the man pages :-( $ man -k any=pkg-readmes update-plist(1) - create or update packing-list(s) for a given port bsd.port.mk(5) - ports tree master Makefile fragment packages(7) - overview of the binary package system Given that bsd.port.mk(5) and update-plist(1) are pages for porters rather than for users, it indeed seems to me that references to pkg-readmes are rather sparse. Also, the reference in packages(7) isn't all that prominent: https://man.openbsd.org/packages#Packages_install_to_/usr/local > (I also ran pkg_info to find out more about the firefox port). Indeed, i think pkg_add(1) and pkg_info(1) are among the first pages users are likely to look at when searching for information about packages. I think pkg_add(1) should list the most important directories it modifies, and pkg-readmes are certainly among those. And pkg_info(1) should list the most important directories containing information about packages. Again, pkg-readmes is among those, even though pkg_info(1) itself does not access it. I admit FILES sections tend to be slightly repetitive - not just in this case but in general because the files are typically also mentioned in the DESCRIPTION. But i still think listing them concisely, with a one-line description each, is helpful. Just like in this case, not all files are necessarily mentioned elsewehere, and such a section provides a nice, quick overview. OK? Ingo > And since the installation was automated, I also missed the hint > when firefox was installed -- my fault, thanks for pointing me to > it - that solved the problem. Index: pkg_add.1 === RCS file: /cvs/src/usr.sbin/pkg_add/pkg_add.1,v retrieving revision 1.162 diff -u -p -r1.162 pkg_add.1 --- pkg_add.1 4 Jan 2020 15:13:54 - 1.162 +++ pkg_add.1 24 Jan 2020 14:14:59 - @@ -820,6 +820,22 @@ but it is searched before .Ev PKG_PATH and waives any kind of signature checking. .El +.Sh FILES +.Bl -tag -width /etc/installurl +.It Pa /etc/installurl +default mirror server for package download +.It Pa /etc/signify/*-pkg.pub +public keys for package verification with +.Xr signify 1 +.It Pa /usr/local/ +default file system to install packages in +.It Pa /usr/local/share/doc/pkg-readmes/ +.Ox Ns -specific +information about individual packages +.It Pa /var/db/pkg/ +database of installed +.Xr packages 7 +.El .Sh SEE ALSO .Xr ftp 1 , .Xr pkg_create 1 , Index: pkg_info.1 === RCS file: /cvs/src/usr.sbin/pkg_add/pkg_info.1,v retrieving revision 1.60 diff -u -p -r1.60 pkg_info.1 --- pkg_info.1 4 Jul 2019 15:25:16 - 1.60 +++ pkg_info.1 24 Jan 2020 14:14:59 - @@ -269,6 +269,15 @@ but it is searched before .Ev PKG_PATH and waives any kind of signature checking. .El +.Sh FILES +.Bl -tag -width /var/db/pkg/ +.It Pa /usr/local/share/doc/pkg-readmes/ +.Ox Ns -specific +information about individual packages +.It Pa /var/db/pkg/ +database of installed +.Xr packages 7 +.El .Sh TECHNICAL DETAILS Package info is either extracted from package files named on the command line, or from already installed package information
Re: [NEW] textproc/scdoc
Hi, Jan Stary wrote on Fri, Jan 24, 2020 at 01:34:54PM +0100: > On Jan 24 00:19:40, schwa...@usta.de wrote: >> Obviously, this is only yet another low-quality man(7) generator >> (emitting pointless low-level roff(7) code, lots of bogus .P, >> incorrectly encoded dashes, using low-level font escapes rather >> than proper man(7) macros, failing to properly generate .MT >> and .UR, ... - and that's just from inspecting the thirty line >> file scdoc.1 itself) so using it certainly isn't encouraged. >> >> But given that some people use it anyway for documentating their >> software, i agree that a port is needed, even if only as a dependency >> for other, potentially more useful ports. > What ports are those? https://github.com/jasperla/openbsd-wip/tree/master/mail/aerc was already mentioned earlier in this thread. I admit there may not be many others, which isn't necessarily a bad thing given the above observations. Yours, Ingo
Re: [NEW] textproc/scdoc
Hi, Stuart Henderson wrote on Thu, Jan 23, 2020 at 11:26:12AM +: > On 2020/01/22 23:34, Raymond E. Pasco wrote: >> Having looked at it a bit more, I see other statically linked ports with >> empty WANTLIB (e.g. shells/tcsh), but that doesn't necessarily mean it's >> correct. Since I don't know, here's another tgz identical to the last >> but with WANTLIB=c (which, if you remove -static, is what it would >> require). > Please don't statically link it. The few ports doing this are special cases. OK, here we go, with the following changes to what Raymond sent: * Delete -static from LDFLAGS in the Makefile. I found no way to feed that in via the environment, so i patched the Makefile. * Polish the COMMENT. Saying just "generator" is not helpful because it doesn't say from which source format, and this is particularly relevant here because it uses an extremely unusual format that nothing else uses, so the claim "generator" is overly broad. Also make it clear that generating man pages actually means generating old 1979-style man(7) code. * Polish DESCR in the same vein. POSIX is irrelevant here; were are writing a decsription for OpenBSD. Obviously, this is only yet another low-quality man(7) generator (emitting pointless low-level roff(7) code, lots of bogus .P, incorrectly encoded dashes, using low-level font escapes rather than proper man(7) macros, failing to properly generate .MT and .UR, ... - and that's just from inspecting the thirty line file scdoc.1 itself) so using it certainly isn't encouraged. But given that some people use it anyway for documentating their software, i agree that a port is needed, even if only as a dependency for other, potentially more useful ports. OK? Ingo tmp.tgz Description: application/tar-gz
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: schwa...@cvs.openbsd.org2020/01/18 10:33:56 Modified files: textproc/groff/patches: patch-tmac_an-old_tmac patch-tmac_doc-common-u Log message: update comments after pushing patches upstream; no bump needed because the package does not change
Re: BoUML 7.9 for OpenBSD 6.6 x86_64
Hi Bruno, cont...@bouml.fr wrote on Sat, Jan 18, 2020 at 11:44:49AM +0100: > I am the author of BoUML [1], in the past up to the release 4.23 I > distributed it under the GPL license, them the releases 5.x was not > free, and finally since the release 7.0 BoUML is free of use but I > decided to not distribute the sources. > > On openBSD you still distribute the old release 4.23 (the last in open > source) http://openports.se/devel/bouml > > Few days ago a user asked me to package the last release (7.9) for > openBSD 6.6 x86_64, I made it and it is available on my site, see > https://www.bouml.fr/download.html#openBSD > > That user also said me I should submit the package to the ports list on > openBSD community, but I imagine this is not compatible with your > requirements because I do not give the sources, am I wrong ? There is no simple "yes" or "no" answer. In principle, all of the following can be included in the OpenBSD ports tree: - non-free software - non-open-source freeware (like yours IIUC) - free software (either copylefted and truely free) OpenBSD developer and porter time is limited, and sometimes even inclusion of very good software gets delayed because a porter needs to come round to it. If upstream authors make users jump through hoops (like by not making their software fully free), that may or may not dampen the interest of individual porters and hence may or may not delay inclusion, in the worst case indefinitely. (For example, personally, i strongly favor fully free and open software, but several ports of software that isn't fully free do exist and are not frowned upon, unless they cause undue maintenance burden.) There is a practical problem, though. Ports development is only done on OpenBSD -current. You cannot submit a port for any -stable release, not even for the latest one (6.6 currently). In the -current branch, there is no promise whatsoever of API or even ABI stability. For example, libc tends to have an API or ABI break every few months, and these are neither scheduled, nor is there any prior warning in public. For that reason, it is *much* easier to port software to OpenBSD when source code is available. You would probably have to do a formal upstream release right after every OpenBSD API/ABI break (not sure whether there is a simpler solution). Currently, there isn't even a developer maintaining our devel/bouml port. Of course, you could maintain it yourself if you are willing to do regular testing on OpenBSD-current and willing to answer questions about the port. Then, for each upstream release, you still need to attract the interest of a developer to get the update committed. Yours, Ingo -- Ingo Schwarze http://www.openbsd.org/ http://mandoc.bsd.lv/
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: schwa...@cvs.openbsd.org2019/12/30 05:34:55 Modified files: textproc/groff : Makefile textproc/groff/patches: patch-tmac_doc-common-u Log message: I'm sorry for the last commit; it caused havoc because cvs(1) mangled the "Mdocdate" contained in the doc-common patch. This commit rearranges the code such that cvs(1) won't break it again.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: schwa...@cvs.openbsd.org2019/12/26 17:48:04 Modified files: textproc/groff : Makefile textproc/groff/patches: patch-tmac_doc-common-u Log message: Bugfix: accept any number of arguments for .Dd (also submitted upstream). Needed to format 4.4BSD manual pages. Bug found and patch OK'ed by jsg@.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: schwa...@cvs.openbsd.org2019/12/16 00:09:49 Modified files: textproc/groff : Makefile textproc/groff/patches: patch-tmac_an-old_tmac Log message: bugfix, also submitted upstream: with the groff_man(7) macros, .AT and .UC did not work at all; bug reported and patch OK'ed by jsg@
Re: postgresql: libc collation issue, linking with ICU
Hi, Stuart Henderson wrote on Wed, Dec 11, 2019 at 07:19:16PM +: > On 2019/12/11 19:57, f.holop wrote: >> Ingo Schwarze - Wed, 11 December 2019 at 18:42:35 >>>> i have noticed that libc collation on OpenBSD is broken (also on macos) :( >>> It is intentional that OpenBSD does not support collation for locales >>> other than "C" in libc, and i'm not aware of any developer who might >>> have plans to add it in the future, not even in the long term. Even >> sounds like all the more reason to build postgresql with ICU. > Nothing in Ingo's mail contradicts that. Right. The reason i didn't comment on the suggestion to make postgresql depend on ICU is that i'm using postgres quite rarely and cannot contribute meaningful input to the tradeoff between another dependency of medium weight vs. the added functionality. *If* locale-dependent collation is considered important for the postgres database, then depending on ICU would agree well with my above reasoning, unless it causes other woes - the port is not a very easy and straightforward one and i have no idea which technical consequences adding that dependency might entail. Yours, Ingo
Re: postgresql: libc collation issue, linking with ICU
Hi, f.holop wrote on Tue, Dec 10, 2019 at 05:07:07PM +0100: > i have noticed that libc collation on OpenBSD is broken (also on macos) :( It is intentional that OpenBSD does not support collation for locales other than "C" in libc, and i'm not aware of any developer who might have plans to add it in the future, not even in the long term. Even the people who added collation support to the FreeBSD libc some years ago have been cursing loudly about it, even though FreeBSD is often quite ready to add bloat to their system. My personal opinion is that libc is a general-purpose programming and operating system support library, whereas locale-specific collation is a highly specialiced niche task that requires extremely complicated code, much too large and ugly for a library like libc. There is a lot of merit in keeping libc lean and simple, not least to help correctness, robustness, and security. For the intended behaviour of OpenBSD, please read: * locale(1) * setlocale(3), including the CAVEATS in that page * strcoll(3) * wcscoll(3) Yours, Ingo
Re: new: opensmtpd clamav filter
Hi Joerg, Joerg Jung wrote on Wed, Nov 13, 2019 at 02:55:17PM +0100: > martijn@ wrote: >> Also the manpage is incorrect. It states [address] [limit], while >> if you want to limit the address is non-optional (from reading the >> code). So this should be [address [limit]]. Strictly speaking, martijn@ is right. Per convention in manual pages, [...] [...] means that you can given none, or either of them, or both, while [... [...]] means that you can give none, or the first, or both, but not the second alone. Examples of [...] [...] with the meaning explained above include atrm(1), cal(1), grep(1), lpq(1), lprm(1), nc(1), systat(1), ... In such cases, often the syntax of both arguments is sufficiently different that it's clear which one is intended when only one is given (for example, a number vs. a string of letters); in other cases, the first argument can be left out when a certain option is specified, like grep(1) -e or nc(1) -l. That said, synopses sometimes cannot be absolutely precise without becoming excessively complicated. But i don't think there is a problem of that kind here. > I don't think that this is incorrect, but a rather common idiom found > in other man pages as well, because: >foo [bar [baz [bat [ban [address [limit]] I don't buy that argument. On the one hand, taking six arguments in a fixed order would seem pretty poor UI design to me. Usually, making them option arguments like foo [-a bar] [-b baz] [-c bat] [-d ban] [address [limit]] would be better UI design because it wouldn't force you to repeat all the defaults just to be able to specify a limit - and it wouldn't force users to learn the order. Besides, i quickly looked through /usr/share/man/man1/ and failed to find a single example where [...] [...] is used but [... [...]] is intended. Admittedly, i might have missed one, but it certainly doesn't look like a common idiom to me. On the other hand, i quickly found several examples of [... [...]]: cmp(1), colrm(1), gprof(1), ksh(1), patch(1), rs(1), split(1), su(1), tmux(1), tradcpp(1), xargs(1), ... > is just not very readable and multiple arguments have always > non-optional predecessors anyways. Absolutely not. That is clearly not true, see the examples above. > But I'm not a manpage syntax expert, > maybe Ingo or jmc can chime in and correct me to be wrong here. At your service. ;-) Admittedly, this is a fringe issue for a port and shouldn't hinder importing. I'm also slightly concerned about large corporations promoting non-portable software and languages and the possibly resulting vendor-lockin, but i'm not a language expert, so my opinion doesn't mean all that much in that respect. I don't doubt the argument, though, that portability ought to be *considered* when making decisions about tools to be used. Either way, even having chosen a poorly-portable language should not hinder committing a port; sometimes, even non-free software gets ported, after all. I can't comment on the port itself. Yours, Ingo
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: schwa...@cvs.openbsd.org2019/11/10 01:23:35 Modified files: devel/cvsweb : Makefile distinfo devel/cvsweb/pkg: PLIST README Removed files: devel/cvsweb/patches: patch-cvsweb_cgi patch-cvsweb_conf Log message: Update to cvsweb-2.1, including partial XSS mitigations; OK gonzalo@ brynet@. Note that autodetecting the location of the configuration file is no longer supported. Now, it must be set explicitly in the script.
Re: add pledge to devel/cvsweb
Hi Solene, Solene Rapenne wrote on Tue, Oct 01, 2019 at 02:15:02PM +0200: > I don't really want to work more on cvsweb, Fair enough, you get to choose what you want to work on. :-) > I did this because it's a cgi scripts run on official > cvsweb.openbsd.org website and I wanted to help there. Sure, thank you, so i'll integrate your work into 2.0.7 and 4.0.x when i find the time. Whether to commit it to the port until then - i leave that decision to other porters... > Altough it may be a good project for a port hackathon if > someone wants to read / debug some perl. Good idea. I might do that in Bukarest if people there consider it a useful idea. Yours, Ingo
Re: add pledge to devel/cvsweb
Hi Solene, Solene Rapenne wrote on Thu, Sep 26, 2019 at 05:27:08PM +0200: > Hi, now that we have OpenBSD::pledge I thought it would be nice to use > it in devel/cvsweb I think this is a thoroughly bad idea. Pledge is useful for well-understood high-quality code. But CVSweb, at this point, is very old, barely maintained, low-quality code. With such code, adding pledge is mostly calling for trouble in the form of crashes that result from unexpected, but required behaviour. Besides, the CVSweb we have in ports is an old version: 2.0.6 (September 2002) plus patches. The latest upstream version is 3.0.6 (September 2005), but upstream is long dead. Doing new development in the form of patches to the port looks like a very bad idea. Some time ago, i set up a new upstream: http://mandoc.bsd.lv/cvsweb/ I admit i got distracted, but i hope to return to it. If we want to improve CVSweb (which i do think makes sense), then the proper course of action, i think, is to 1. Commit such improvements as can be easily done and are quite useful to the FreeBSD-cvsweb-2_0-branch. Possibly, pledge can be part of that if we are really sure we understand what all the code does. Otherwise, i think step 6 below is the proper time for adding pledge. 2. Release 2.0.7 from that branch. This can be a short-term goal, the only reason it didn't happen yet is that i got distracted. 3. Update the port to 2.0.7. 4. Update the bsd.lv and possibly cvsweb.openbsd.org servers to 2.0.7. 5. Merge 2.0.7 into the MAIN branch (4.x revision numbers). 6. Develop and release cvsweb-4.0.0 as a medium-term project. 7. Update the port to 4.0.0. 8. Update the two servers. If you want to help with that, i'm happy to give you commit access to the upstream repository on mandoc.bsd.lv. If other porters think that solene's work should be committed directly to the port, i don't veto that, but i do not consider it useful either. I doubt that any running server will update to a new version of the port before the release of 2.0.7. Yours, Ingo
Re: include-what-you-use: ship docs, use python 3, other nits
Hi Klemens,
the authors of this tool absolutely do not understand how documentation
works. That said, i agree it is better to install whatever piss-poor
and disorganized musings they do provide rather than installing no
documentation whatsoever.
See below in-line for two questions, none of which are intended to
oppose or even delay your commit.
Yours,
Ingo
Klemens Nanni wrote on Mon, Jun 10, 2019 at 10:34:21PM +0200:
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/include-what-you-use/Makefile,v
> retrieving revision 1.15
> diff -u -p -r1.15 Makefile
> --- Makefile 16 Feb 2019 12:06:23 - 1.15
> +++ Makefile 10 Jun 2019 20:33:34 -
> @@ -3,28 +3,40 @@
> COMMENT= tool to analyse \#includes in C and C++ source files
> CATEGORIES= devel
> DISTNAME=include-what-you-use-0.11.src
> -PKGNAME= include-what-you-use-0.11
> -REVISION=0
> +PKGNAME= ${DISTNAME:.src=}
> +REVISION=1
>
> -HOMEPAGE=http://include-what-you-use.org
> +HOMEPAGE=https://include-what-you-use.org
> MASTER_SITES=${HOMEPAGE}/downloads/
> WRKDIST= ${WRKDIR}/include-what-you-use
>
> MAINTAINER= Jonathan Gray
>
> # BSD
> -PERMIT_PACKAGE_CDROM=Yes
> +PERMIT_PACKAGE= Yes
>
> -WANTLIB= c curses execinfo form m pthread z
> +WANTLIB= ${COMPILER_LIBCXX} c execinfo m pthread
> LLVM_V= 7.0.1
> BUILD_DEPENDS= devel/llvm>=${LLVM_V}
> RUN_DEPENDS= devel/llvm>=${LLVM_V}
Why does this have an unconditional dependency on ports LLVM?
For example, on amd64, it actually uses base LLVM unless i read
the build logs incorrectly.
I realize this is unrelated to your changes, just wondering...
Uh oh... Then again, is see stuff like
CMAKE_CXX_COMPILER_AR:FILEPATH=/usr/local/bin/llvm-ar
CMAKE_CXX_COMPILER_RANLIB:FILEPATH=/usr/local/bin/llvm-ranlib
CMAKE_C_COMPILER_AR:FILEPATH=/usr/local/bin/llvm-ar
CMAKE_C_COMPILER_RANLIB:FILEPATH=/usr/local/bin/llvm-ranlib
CMAKE_LINKER:FILEPATH=/usr/bin/ld
CMAKE_RANLIB:FILEPATH=/usr/bin/ranlib
Clang_DIR:PATH=/usr/local/lib/cmake/clang
LLVM_DIR:PATH=/usr/local/lib/cmake/llvm
in CMakeCache.txt - mixing toolchains like this makes me feel uneasy,
even if both clangs currently happen to be 7.0.1 on amd64.
Is this really safe, even if the two should occasionally diverge,
which they sometimes do according to what i have seen in the past?
> LIB_DEPENDS= devel/libexecinfo
>
> MODULES= devel/cmake lang/python
> +MODPY_BUILDDEP= No
> +MODPY_VERSION= ${MODPY_DEFAULT_VERSION_3}
> +MODPY_ADJ_FILES= *.py
> +
> COMPILER=base-clang ports-gcc
> COMPILER_LANGS= c++
>
> -MODPY_ADJ_FILES = fix_includes.py iwyu_tool.py
> +DOCDIR= ${PREFIX}/share/doc/include-what-you-use
> +
> +do-test:
> + cd ${WRKSRC} && ./run_iwyu_tests.py
> +
> +post-install:
> + ${INSTALL_DATA_DIR} ${DOCDIR}/
> + ${INSTALL_DATA} ${WRKSRC}/docs/* ${DOCDIR}/
> + ${INSTALL_DATA} ${WRKSRC}/README.md
> ${PREFIX}/share/include-what-you-use/
It feels like you install README.md to the wrong place.
Can you install it to /usr/local/share/doc/include-what-you-use/
instead, together with the other "documentation"?
Yes, the file is a total mess in so far as it mixes build instructions
(which shouldn't be installed at all) with usage instructions - which
ought to be in a section 1 manual page, include-what-you-use(1). But
given that it does contain some usage instructions, even though well
hidden among a lot of crap and very imprecise, i think it does
belong in ${DOCDIR}/.
Re: OpenBSD maintainers Spring cleaning
Hi Renaud, Renaud Allard wrote on Thu, Jun 06, 2019 at 07:47:24AM +0200: > I was also reluctant at answering because I didn't know the mail > address from the sender. In addition to what sthen@ said: if you receive an email message claiming to be *from an OpenBSD developer* and suspect a phishing attempt for whatever reason, you can always reply to the @openbsd.org address (in this case danj@) even when Reply-To: is not set. If it was not phishing - perfect, from the reply, you now know the other address is genuine, too. If it was phishing, the developer is likely interested to learn that somebody is trying to impersonate them. Either way, you should *really* reply to mail about your ports (as opposed to obvious spam, of course), even when you suspect some kind of phishing. A maintainer address is publicly advertised on the Internet anyway, so there is no point in trying to hide the fact from spammers that you do indeed reed incoming mail. Better answer once to a spammer by mistake than ignore a user asking a genuine question about your port. Yours, Ingo P.S. You see, me too, i'm typically sending From: a non-OpenBSD address without setting Reply-To: - because direct replies are faster. But there is certainly nothing wrong with writing to schwarze@, many people do that.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: schwa...@cvs.openbsd.org2019/05/22 06:56:29 Modified files: devel/elftoolchain: Makefile devel/elftoolchain/pkg: PLIST Added files: devel/elftoolchain/patches: patch-libdwarf_Makefile patch-libdwarf_dwarf_add_frame_fde_3 patch-libdwarf_dwarf_get_fde_list_3 patch-libdwarf_dwarf_get_ranges_3 patch-libelf_Makefile patch-libelf_elf_open_3 patch-libelf_gelf_xlatetof_3 patch-libelftc_Makefile Log message: Remove use of the moribund MLINKS bsd.man.mk feature and bump. Add a small number of missing .Nm lines to a handful of NAME sections. That this port used MLINKS in the upstream Makefiles was found when naddy@ grepped bulk build logs. OK naddy@.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: schwa...@cvs.openbsd.org2019/05/20 09:12:28 Modified files: devel/libexecinfo: Makefile devel/libexecinfo/patches: patch-examples_Makefile patch-libbacktrace_Makefile patch-libbacktrace_backtrace_3 devel/libexecinfo/pkg: PLIST Log message: Delete the needless MLINKS because the feature will soon be removed from base. Instead, add the missing .Nm macros to the NAME section of the manual page. Delete the misleading MANDIR variable and regenate the patches while here. Bump. OK sthen@ marco@
Re: The eternal great desktop thread
Hi Matthew, cho...@jtan.com wrote on Sat, May 11, 2019 at 04:18:07PM +0300: > The question remains but now with a wider audience - > I've posted a port to the mailing list, what next? Wait for feedback. > I'm happy to leave it in the porters' collective lap or begin > to take on some responsibility myself; I'm just not sure what > to do with it. Any of the following may happen next: a) A ports developer decides the port is useful and mature and commits it, with or without minor changes. b) Somebody thinks it is potentially useful but requires more work. That person will ask you to do specific work on it and resubmit once you have done that. c) You get no feedback whatsoever. d) A ports developer decides the software is inappropriate for the ports tree for some reason and explicitely says so. The outcome d) is relatively rare. For you, c) is the least desirable outcome, and it is *not* rare. It is undesirable because you won't know the reason: ca) Maybe nobody really noticed the submission, it simply fell through the cracks. It might still be a very good port. cb) Maybe some noticed, but weren't interested personally and had other things to do. It might still become a port if somebody becomes interested. cc) Maybe most who noticed considered it a dubious idea, but didn't care enough to explicitly oppose it. In case somebody finally picks it up, explicit opposition might start being discussed, but that's rare (just like d). Remeber that testing and committing a port requires time and effort, and more ports are being submitted than porters have time to deal with. Even short feedback requires spending some time. Personally, i'm in the cb) camp in this case, but that really doesn't tell you anything useful. If you submitted a port following the porting guide, all you can do is wait, then try again after three weeks, after three months, and after a year, in case you receive no feedback. > Incidentally it's useful to know that the split between base and ports > is/can be as distinct between the developers as it is between the > binaries. Thanks for the effort. It varies. Some developers are quite active in both areas, for example espie@, sthen@, jsg@. Some have a clear focus on one but still contribute regularly to the other, for example ajacoutot@ (ports) or myself (base). Some almost never commit to ports, for example deraadt@, millert@, jmc@. Some work almost exclusively on ports, for example landry@. Besides, what developers work on sometimes changes with time. Yours, Ingo
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: schwa...@cvs.openbsd.org2019/05/02 12:50:08 Modified files: textproc/docbook2mdoc: Makefile distinfo Log message: update to docbook2mdoc-1.1.0: new -s command line option and large numbers of improvements to whitespace handling OK bentley@ (MAINTAINER)
Re: p5-Unix-Pledge, this time 0.006
Hi Matthew, cho...@jtan.com wrote on Wed, May 01, 2019 at 07:42:40PM +0300: > Stuart Henderson writes: >> Missing license marker and WANTLIB. > What would I put in WANTLIB? The only dependency this module has is > OpenBSD 6.4's base system (well strictly speaking, a libc with the > pledge and unveil calls). > > I can't find examples of license markers I could use. Of the half dozen > or so ports I checked, none had anything like it in their Makefile. > bsd.port.mk(5) also has nothing to say about it. https://www.openbsd.org/faq/ports/guide.html Regarding WANTLIB, look at step 26 "Verify shared library dependencies". Regarding licensing, look at step 9 and at /usr/ports/infrastructure/templates/Makefile.template . Every port has a license marker. It's the comment line above PERMIT_*. For even more information, commands like $ man -k Ev=WANTLIB can be helpful. Yours, Ingo
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: schwa...@cvs.openbsd.org2019/04/30 04:45:53 Modified files: textproc/docbook2mdoc: Makefile distinfo Log message: update to docbook2mdoc-1.0.2: support for and and internal framework improvents, in particular for creating, editing, and moving nodes; now good enough for /usr/xenocara/doc/xorg-docs/general/input/XKB-*.xml; OK bentley@ (MAINTAINER)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: schwa...@cvs.openbsd.org2019/04/25 06:29:28 Modified files: textproc/docbook2mdoc: Makefile distinfo Log message: update to docbook2mdoc-1.0.1: support for file inclusion via "
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: schwa...@cvs.openbsd.org2019/04/17 20:06:48 Modified files: textproc/docbook2mdoc: Makefile distinfo Log message: update to docbook2mdoc-1.0.0; OK bentley@ (MAINTAINER)
Re: UPDATE mail/s-nail
Steffen Nurpmeso wrote on Wed, Apr 10, 2019 at 05:39:38PM +0200: > Steffen Nurpmeso wrote in <20190308210521.7ybvy%stef...@sdaoden.eu>: >> please find below an update to S-nail v14.9.13. > would someone be so kind an wave that through, please? No, absolutely not. The trees are locked for release.
Re: [Re: XSS vuln in cvsweb]
Hi,
Peter J. Philipp wrote on Sat, Mar 16, 2019 at 07:52:23AM +0100:
> On Fri, Mar 15, 2019 at 05:22:47PM -0700, Andrew Hewus Fresh wrote:
>> I looked this over and updated the patch to be against the port. It
>> seems to be good and I only found a couple other places that needed to
>> be escaped, the "stickyvars" section and the tr1/tr2 inputs in doLog,
>> although r1, r2, tr1 and tr2 are part of "unsafevars" so their content
>> is pretty limited already.
>>
>> It was a pretty quick look so I don't doubt that there are more, and I
>> didn't actually get a chance to test it out, so hopefully someone else
>> can.
> Thanks for the help! I have applied your patch and it went cleanly (commands
> were cd /usr/ports/devel/cvsweb; patch -p0 < cvsweb.patch), I then rebuilt
> the port with "make reinstall" no problem there either. The CGI is the newly
> built CGI as discovered with ls. A quick test shows that it applied the
> XSS escapes.
I committed the patches from both of you to
http://mandoc.bsd.lv/cgi-bin/cvsweb/?cvsroot=cvsweb
http://mandoc.bsd.lv/cvsweb/
in preparation for rolling a new release, then briefly looked at
the script myself. My impression is there are huge numbers of
additional candidates for missing escaping, see the incomplete list
below (which may of course also contain some false positives). I'm
not yet sure what to do about it (don't waste your time right now
trying to fix all the potential issues below).
Maybe just fix the most important ones, check and apply the additional
idea (adding some HTTP header) from sthen@, release 2.1.1 even if
it is not perfect, update the port, then move on to the 3.0 branch,
cleaning up things for real over there, aiming for a later 3.1.1
release?
That way, we would quickly get a 2.1.1 release that everybody could
update to without too much hassle, whereas updating to 3.1.1 might
not be easy for some, and besides releasing 3.1.1 will certainly
not be quick. At the same time, that plan would avoid wasting too
much time on 2.1.1. Not sure yet...
Yours,
Ingo
Additional candidates where escaping is likely missing:
---
sub clickablePath($$) {
$retval = "[$cvstree]";
$retval .= ' ' . ("[$cvstree]",
sprintf('%s/%s#dirlist', $scriptname, $query));
$retval .= $_;
sub cvswebMarkup($$$) {
print "Tag: ", $input{only_with_tag}, "\n"
sub doDiff($$) {
print $_;
sub getDirLogs($$@) {
print "$state:$_" if ($verbose);
print "$filename $rev Wanted: $revwanted ",
"Revbranch: $revbranch Branch: $branch ",
"Branchpoint: $branchpoint\n"
"File revision $rev found for branch
$branch\n"
print
"File info $rev found for $filename
sub readLog($;$) {
print if ($verbose);
print "R:", $_ if ($verbose);
print "D:", $_ if ($verbose);
print "L:", $_ if ($verbose);
print "E:", $_ if ($verbose);
sub link($$) {
sprintf '%s', hrefquote($url), $name;
sub printLog($;$) {
print "";
print "";
print "";
sprintf(
'%s?r1=%s%s', $scriptwhere,
$_, htmlquote($barequery)
)
print "Revision $_";
print "", $author{$_}, "\n";
print "Branch: ", $link ? link_tags($revsym{$br}) : $revsym{$br},
print "CVS Tags: ", $link ? link_tags($revsym{$_}) : $revsym{$_},
print "Branch point for: ",
$link ? link_tags($branchpoint{$_}) : $branchpoint{$_}, "\n"
print
"Changes since $prev: $difflines{$_} lines\n";
print ">${_}\n";
sub human_readable_diff($) {
print
"Diff for /$where_nd between versio
sub navigateHeader($) {
$path$filename - $title - $rev$css
print ($backicon, "$swhere$query#rev$rev");
print "Return to ", ($filename, "$swhere$query#rev$rev"),
sub chooseCVSRoot() {
print "\n"
print "CVS Root: [$cvstree]";
sub download_link($$$;$) {
print ">$textlink";
sub html_header($) {
$title
Re: Adding TEST_ENV/UTF-8 to various ports
Hi,
Remi Locherer wrote on Sat, Mar 16, 2019 at 11:26:54PM +0100:
> On Sat, Mar 16, 2019 at 09:48:21PM +, Stuart Henderson wrote:
>> On 2019/03/16 22:12, Remi Locherer wrote:
>>> Index: lang/python/python.port.mk
>>> ===
>>> RCS file: /cvs/ports/lang/python/python.port.mk,v
>>> retrieving revision 1.100
>>> diff -u -p -r1.100 python.port.mk
>>> --- lang/python/python.port.mk 4 Dec 2018 05:57:31 - 1.100
>>> +++ lang/python/python.port.mk 16 Mar 2019 20:40:34 -
>>> @@ -150,6 +150,7 @@ CONFIGURE_ENV +=PYTHON="${MODPY_BIN}"
>>> CONFIGURE_ENV += ac_cv_prog_PYTHON="${MODPY_BIN}" \
>>> ac_cv_path_PYTHON="${MODPY_BIN}"
>>> .endif
>>> +TEST_ENV +=LC_CTYPE=C.UTF-8
>> Do we actually support LC_CTYPE=C.UTF-8?
We do not recommend it; the locale(1) manual page only recommends
either leaving LC_* unset or setting LC_CTYPE=en_US.UTF-8.
But we do support it, just like we support LC_CTYPE=FooBar.UTF-8.
The locale(1) manual page says:
If the value of LC_CTYPE ends in ".UTF-8", programs in the OpenBSD
base system ignore the beginning of it, treating for example
zh_CN.UTF-8 exactly like en_US.UTF-8. Programs from packages(7)
may however make a difference.
Theoretically, it could happen that at some point in the future,
we might stop supporting LC_CTYPE=FooBar.UTF-8, though i do not
expect that. But i don't think we could ever stop supporting
LC_CTYPE=C.UTF-8. It seems too widespread in practice, and removing
support for it would no doubt break more than one thing in ports.
> According to "locale -a" we do.
The -a option of locale(1) is a scam. It should never be used as
an argument for or against anything. Its only purpose is to appease
ports who insist in inspecting it, but even for that purpose, it
is far from perfect.
> I proposed C.UTF-8 because I think this is what python prefers
> after skimming over https://www.python.org/dev/peps/pep-0538/ .
If that's what Python folks like, i think there is nothing wrong with
using it; on OpenBSD, it's just an alias for LC_CTYPE=en_US.UTF-8.
On other operating systems, it may or may not work, exactly like
LC_CTYPE=en_US.UTF-8 may or may not work elsewehere. I have seen
systems where LC_CTYPE=en_US.UTF-8 works and LC_CTYPE=C.UTF-8 does
not and vice versa; i think i have even seen systems where neither
work. Locale names are simply not standardized - except for "C"
and "POSIX".
I didn't speak up earlier because the last time i did a substantial
programming project in Python was about a decade ago, so i'm no
longer qualified to OK or to object to Python patches...
Yours,
Ingo
Re: [Re: XSS vuln in cvsweb]
Hi, the trouble with cvsweb is that it is important OpenBSD project infrastructure (consider cvsweb.openbsd.org) that has been abandoned upstream 13 years ago, our version is 16 years old, and the port has no maintainer. Does anybody consider it funny to run a software in production that is closely related to version control, but (according to my knowledge) is not currently under version control itself? Given that i'm still using it on bsd.lv, too, i'm willing to host a CVS repo for it and the release tarballs (historic and future) on bsd.lv, pick up upstream maintenance, and also maintain the port. Does that sound reasonable to people round here? If so, does anyone know whether a copy of the original CVS repository that it resided in still exists somewhere? It seems to have vanished from https://svnweb.freebsd.org/base/projects/ ... I don't consider the XSS urgent, but it would of course get fixed in the process. If people wanted, they could test and commit patches to the port beforehand, but i'm not sure it's needed. Yours, Ingo
Re: install(1) broken
Hi Marc, Marc Espie wrote on Sat, Feb 09, 2019 at 10:03:20PM +0100: > hey, your commit to install(1) broke something. > > Specifically lang/go-boostrap now produces a broken package which can't > be used to build go. > > All the go/bootstrap/pkg/tool/openbsd_amd64/* > have lost their x bit > > Relevant fake install information, it definitely looks like the last line > is now a no-op. [...] > install -c -m 755 -p [...] Sorry for the disruption. It looks like the bug was not caused, but merely exposed by my commit. I reverted my commit anyway such than we can first fix the bug without a hurry, then reapply my change. I did not revert the manual page change to minimize churn, expecting that the change will eventually be put back. A preliminary analysis indicates that 1. install -m 755 foo bar always applies 755 to bar 2. install -S-m 755 foo bar always applies 755 to bar 3. install -S -p -m 755 foo bar only applies 755 if the file content changes Item 3 looks like a bug to me. Similar effects may or may not apply to the owner and the flags. I will look in more detail later. Yours, Ingo
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: schwa...@cvs.openbsd.org2019/01/16 23:44:18 Modified files: devel/cutils : Makefile Log message: Identical formatting from groff and mandoc because escaped backslashes in high-level macro arguments now work as expected; so drop USE_GROFF and bump.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: schwa...@cvs.openbsd.org2019/01/12 10:01:35 Modified files: textproc/groff : Makefile textproc/groff/patches: patch-tmac_doc_tmac-u Log message: Correctly handle groff_mdoc(7) .Lk arguments starting with a dot; bug reported by jmc@; fix committed upstream, too.
Re: NEW: books/oeb
Hi, Anthony J. Bentley wrote on Mon, Jan 07, 2019 at 06:47:04AM -0700: > The Open English Bible I think adding this as a port is a bad idea. While "something is software that can be run on OpenBSD and that at least one developer or at least some users want to run on OpenBSD" may be a good enough reason to add something to ports (even though there are exceptions even to that, like certain kinds of web applications, or libraries used by no other ports), "something is a book and at least one developer wants to read it" does not look like a good enough reason to add something to ports/books. I think anything under ports/books ought to have at least some kind of a relation to OpenBSD, UNIX, or to major programming languages that can be used under OpenBSD. I don't see why ports/books should become a library of random books with no relation whatsoever to the project. Besides, i think Solene is right that installing mere PDF files provides relatively little benefit compared to having the user simply store them somewhere below /home/. A books port mostly makes sense when the contained files can be used in non-trivial ways with software. The best example probably being that man-pages-posix can be used with the man(1) -M option. Though i admit even that case is not fully convincing yet because mandoc(1) is still unable to properly format the POSIX standards documents, with the consequence that they have to be installed preformatted and support for semantic searching is unavailable. But you get the idea: the man-pages-posix port is potentially more useful than merely downloading a big PDF file. Yours, Ingo
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: schwa...@cvs.openbsd.org2018/12/25 17:49:22 Added files: textproc/groff/patches: patch-Makefile_in Log message: Add a missing prerequisite that could cause parallel builds to fail. Issue found and patch OK by sthen@.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: schwa...@cvs.openbsd.org2018/12/24 03:42:00 Modified files: textproc/groff : Makefile distinfo textproc/groff/patches: patch-tmac_an-old_tmac patch-tmac_troffrc textproc/groff/pkg: PLIST README Added files: textproc/groff/patches: patch-tmac_doc-common-u patch-tmac_doc_tmac-u Removed files: textproc/groff/patches: patch-Makefile_in patch-contrib_hdtbl_examples_common_roff patch-src_libs_libgroff_glyphuni_cpp patch-src_libs_libgroff_uniglyph_cpp patch-tmac_doc-common patch-tmac_doc-nroff patch-tmac_doc_tmac patch-tmac_groff_mdoc_man patch-tmac_groff_www_man patch-tmac_tty-char_tmac patch-tmac_tty_tmac Log message: update to the maintenance release groff-1.22.4; lots of small improvements, and most of our patches incorporated; tweaks to the port and OK bcallah@
maintainer update: textproc/groff-1.22.4
Hi,
after four years of development, groff-1.22.4 was released on
December 23, 2018. It contains lots of bugfixes, some minor
new features, and it incorporates most of our existing patches.
The patch below is +104 -571 LOC in the ports tree. :-)
I have been using groff-current for a long time for my own purposes,
so i'm quite convinced that it is stable. The release survives the
full mandoc test suite and also shows no regressions with my latest
conference slides.
OK to commit it?
Ingo
New optional dependencies that need to be disabled such that they
don't accidentally get picked up:
--without-uchardet # pointless on OpenBSD because we deliberately
# only support UTF-8 in the first place
--without-urw-fonts-dir # needed in order not to pick up stuff
# from print/ghostscript
CONFIGURE_ENV += ... # needed in order not to pick up stuff
# from print/poppler-utils and graphics/netpbm
README change:
Removed the quirk of putting "OpenBSD ports" into page footers,
it is simply "OpenBSD" now.
Patches that can be dropped:
Makefile_in # completely different build system now, automake-based
Merged upstream:
contrib_hdtbl_examples_common_roff
src_libs_libgroff_glyphuni_cpp
src_libs_libgroff_uniglyph_cpp
tmac_doc-nroff
tmac_groff_mdoc_man
tmac_groff_www_man
tmac_tty-char_tmac
tmac_tty_tmac
Patch substantially reduced:
tmac_doc_tmac-u
Index: Makefile
===
RCS file: /cvs/ports/textproc/groff/Makefile,v
retrieving revision 1.42
diff -u -p -r1.42 Makefile
--- Makefile25 Oct 2018 13:26:48 - 1.42
+++ Makefile24 Dec 2018 00:40:17 -
@@ -1,10 +1,9 @@
# $OpenBSD: Makefile,v 1.42 2018/10/25 13:26:48 sthen Exp $
COMMENT = GNU troff typesetter
-VERSION = 1.22.3
+VERSION = 1.22.4
SUBST_VARS = VERSION
DISTNAME = groff-${VERSION}
-REVISION = 12
CATEGORIES = textproc
DPB_PROPERTIES = parallel
@@ -28,12 +27,15 @@ MAKE_FLAGS += docdir=${PREFIX}/share/do
MODULES = perl
CONFIGURE_STYLE = gnu
-CONFIGURE_ARGS += --without-libiconv-prefix --without-gs --without-x \
- --with-awk=awk \
+CONFIGURE_ARGS += --with-awk=awk --without-gs \
+ --without-libiconv-prefix --without-uchardet \
+ --without-urw-fonts-dir --without-x \
pnmcrop=missing pnmcut=missing pnmtopng=missing \
pnmtops=missing psselect=missing
-
-MODGNU_CONFIG_GUESS_DIRS = ${WRKSRC} ${WRKSRC}/src/libs/gnulib/build-aux
+CONFIGURE_ENV += ac_cv_prog_PDFFONTS= \
+ ac_cv_prog_PDFIMAGES= \
+ ac_cv_prog_PDFINFO= \
+ ac_cv_prog_XPMTOPPM=
pre-configure:
find ${WRKBUILD} -name \*.pl -type f -print0 | \
Index: distinfo
===
RCS file: /cvs/ports/textproc/groff/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo6 Nov 2014 22:15:22 - 1.4
+++ distinfo24 Dec 2018 00:40:17 -
@@ -1,2 +1,2 @@
-SHA256 (groff-1.22.3.tar.gz) = Okip1sl3UL+9U1/utb4BEdtkBt23u3n8aAgJzabYKKU=
-SIZE (groff-1.22.3.tar.gz) = 4188772
+SHA256 (groff-1.22.4.tar.gz) = 5457TLfewxCEkAT6iIR8RHAejRM7XUwTBX2HbButApM=
+SIZE (groff-1.22.4.tar.gz) = 4137480
Index: patches/patch-Makefile_in
===
RCS file: patches/patch-Makefile_in
diff -N patches/patch-Makefile_in
--- patches/patch-Makefile_in 27 Aug 2018 00:16:24 - 1.8
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,24 +0,0 @@
-$OpenBSD: patch-Makefile_in,v 1.8 2018/08/27 00:16:24 schwarze Exp $
-chunk 1: src/devices/gropdf depends on arch/misc.
-chunk 2: avoid bogus "is up to date" during fake.
-Upstream code is completely different now.
Makefile.in.orig Tue Nov 4 09:38:35 2014
-+++ Makefile.inThu Sep 8 22:27:19 2016
-@@ -896,6 +896,8 @@ $(GNULIBDIRS): FORCE
- $(MAKE) ACLOCAL=: AUTOCONF=: AUTOHEADER=: AUTOMAKE=: $(do) ;; \
- esac
-
-+$(SHPROGDIRS): $(PROGDEPDIRS)
-+
- $(OTHERDIRS): $(PROGDEPDIRS) $(CCPROGDIRS) $(CPROGDIRS) $(SHPROGDIRS)
-
- $(INCDIRS) $(PROGDEPDIRS) $(SHPROGDIRS) $(OTHERDIRS): FORCE
-@@ -964,7 +966,7 @@ dist:
- # refer lookbib indxbib lkbib: libbib
- # $(LIBDIRS) $(PROGDIRS): include
-
--.PHONY: $(ALLDIRS) dot $(TARGETS) FORCE
-+.PHONY: $(ALLDIRS) $(OTHERDIRS) dot $(TARGETS) FORCE
-
- # Create a Makefile in $(subdir). This is useful for development since it
- # avoids running make recursively.
Index: patches/patch-contrib_hdtbl_examples_common_roff
===
RCS file: patches/patch-contrib_hdtbl_examples_common_roff
diff -N patches/patch-contrib_hdtbl_examples_common_roff
---
Re: [devel/cmake] errors caused by cmake-properties.7 during makewhatis
Hi,
unless i'm missing something, everything discussed in this thread
should be fixed now, with the commit appended below.
Ingo Schwarze wrote on Thu, Dec 20, 2018 at 07:35:22PM +0100:
> Raf Czlonka wrote on Thu, Dec 20, 2018 at 02:59:23PM +:
[...]
>> Rebuilding whatis databases:
>> makewhatis: man7/cmake-properties.7: ERROR: No such file or directory
[...]
> 1. The line number is missing, even though it is relevant.
> 2. Mentioning the .so request would be useful.
> 3. Mentining the file that was not found would be useful.
> 4. Most importantly, makewhatis(8) is not supposed
> to print mandoc(1) errors in this manner.
[...]
> Bug number 6: duoplicate reporting, two messages about the same problem
> in the input file, both with incomplete information. Not sure i can fix
> that one, but i shall try.
Fixing all that required much smaller code changes than i expected,
but explaining why these small changes do the job needed a substantial
commit message...
Speak up if you still see issues!
Thanks,
Ingo
Log Message:
---
Move the full responsibility for reporting open(2) errors from
mparse_open() to the caller. That is better because only the caller
knows its preferred reporting method and format and only the caller
has access to all the data that should be included - like the column
number in .so processing or the current manpath in makewhatis(8).
Moving the mandoc_msg() call out is possible because the caller can
call strerror(3) just as easily as mparse_open() can.
Move mandoc_msg_setinfilename() closer to the parsing of the file
contents, to avoid problems *with* the file (like non-existence,
lack of permissions, etc.) getting misreported as problems *in*
the file.
Fix the column number reported for .so failure:
let it point to the beginning of the filename.
Taken together, this prevents makewhatis(8) from spewing confusing
messages about .so failures to stderr, a bug reported by
Raf Czlonka on ports@.
It also prevents mandoc(1) from issuing *two* messages for every
single .so failure.
Modified Files:
--
mandoc:
main.c
read.c
Revision Data
-
Index: main.c
===
RCS file: /home/cvs/mandoc/mandoc/main.c,v
retrieving revision 1.313
retrieving revision 1.314
diff -Lmain.c -Lmain.c -u -p -r1.313 -r1.314
--- main.c
+++ main.c
@@ -510,7 +510,6 @@ main(int argc, char *argv[])
} else
thisarg = *argv;
- mandoc_msg_setinfilename(thisarg);
fd = mparse_open(curp.mp, thisarg);
if (fd != -1) {
if (use_pager) {
@@ -523,11 +522,13 @@ main(int argc, char *argv[])
conf.output.tag : *argv;
}
+ mandoc_msg_setinfilename(thisarg);
if (resp == NULL || resp->form == FORM_SRC)
parse(, fd, thisarg);
else
passthrough(resp->file, fd,
conf.output.synopsisonly);
+ mandoc_msg_setinfilename(NULL);
if (ferror(stdout)) {
if (tag_files != NULL) {
@@ -545,8 +546,9 @@ main(int argc, char *argv[])
outdata_alloc();
terminal_sepline(curp.outdata);
}
- }
- mandoc_msg_setinfilename(NULL);
+ } else
+ mandoc_msg(MANDOCERR_FILE, 0, 0,
+ "%s", strerror(errno));
if (curp.wstop && mandoc_msg_getrc() != MANDOCLEVEL_OK)
break;
Index: read.c
===
RCS file: /home/cvs/mandoc/mandoc/read.c,v
retrieving revision 1.207
retrieving revision 1.208
diff -Lread.c -Lread.c -u -p -r1.207 -r1.208
--- read.c
+++ read.c
@@ -372,8 +372,9 @@ rerun:
mparse_readfd(curp, fd, ln.buf + of);
close(fd);
} else {
- mandoc_msg(MANDOCERR_SO_FAIL, curp->line,
- pos, ".so %s", ln.buf + of);
+ mandoc_msg(MANDOCERR_SO_FAIL,
+ curp->line, of, ".so %s: %s",
+ ln.buf + of, strerror(errno));
ln.sz = mandoc_asprintf(,
".sp\nSee the file %s.\n.sp",
ln.buf + of);
@@ -633,7 +634,6 @@ mparse_open(struct mparse *curp, const c
/* Neither worked, give up. */
- mandoc_msg(MANDOCERR_FILE, 0, 0, "%s", strerror(errno));
return -1;
}
Re: [devel/cmake] errors caused by cmake-properties.7 during makewhatis
Hi Raf, Raf Czlonka wrote on Thu, Dec 20, 2018 at 02:59:23PM +: > Recently, I've noticed an odd-looking output from weekly(8): > > Rebuilding whatis databases: > makewhatis: man7/cmake-properties.7: ERROR: No such file or directory You are right, there are a number of bugs here. I feel tempted to call it a cloud of mosquitoes. Thanks for the analysis. 1. The line number is missing, even though it is relevant. 2. Mentioning the .so request would be useful. 3. Mentining the file that was not found would be useful. 4. Most importantly, makewhatis(8) is not supposed to print mandoc(1) errors in this manner. The MANDOCERR_FILE enum item gets special handling in the code in several ways, but the effects are less than pretty. I think i have to revisit how this error item is generated and handled. > "Strange", I thought, especially since > /usr/local/man/man7/cmake-properties.7 is "alive" and well: > > $ ls -l /usr/local/man/man7/cmake-properties.7 > -rw-r--r-- 1 root bin 202877 Dec 20 14:00 > /usr/local/man/man7/cmake-properties.7 In general, the file name at the beginning of a mandoc(1) message is the name of the *input* file in which the error occurred, not the name of a file which mandoc tried to use. Here is bug number 5: That wasn't clearly stated in the manual page below: https://man.openbsd.org/mandoc#DIAGNOSTICS That's the first thing i fixed following your report, see the commit below. > I've rebuilt the mandoc.db I guess you mean "with makewhatis -D"? > and got an output which was stranger still: > > makewhatis: man7/cmake-properties.7: ERROR: No such file or directory > /usr/local/man//man7/cmake-properties.7: Adding to database > > Huh!? Right, makewhatis is indexing the file even though the content of the file is buggy. But that's OK as far as it goes. > Time for 'mandoc -Tlint': Excellent idea. > $ mandoc -Tlint /usr/local/man/man7/cmake-properties.7 | head > mandoc: /usr/local/man/man7/cmake-properties.7:1131:2: WARNING: .so is > fragile, better use ln(1): so libraries. > mandoc: /usr/local/man/man7/cmake-properties.7: ERROR: No such file or > directory > mandoc: /usr/local/man/man7/cmake-properties.7:1131:15: ERROR: .so > request failed: .so libraries. > [...] Bug number 6: duoplicate reporting, two messages about the same problem in the input file, both with incomplete information. Not sure i can fix that one, but i shall try. > OK, let's see what on that line: > > $ sed -n 1131p /usr/local/man/man7/cmake-properties.7 > .so libraries. > > and including preceding line: > > Set the Android property that specifies directories to search for the > .so libraries. > > Right, so '.so' (unintentional pun) is treated as a macro here - No, not as a macro, as a roff(7) request - but that isn't what the author intended, either. > moving it to the line above, fixes the issue: > > Set the Android property that specifies directories to search for the > .so > libraries. > > Upstream uses reStructuredText but I hope this[0] does the trick. > > [0] https://gitlab.kitware.com/cmake/cmake/merge_requests/2756 That's not a fix but merely a workaround for a bug in reStructuredText. It is more important to report the bug to reStructuredText than to work around it in each and every project using reStructuredText. The reStructuredText program ought to emit Set the Android property that specifies directories to search for the \&.so libraries. for the input in question. > Anyway, thought this might be of interest. Indeed, thank you for reporting. Ingo Log Message: --- Explain what the fields in mandoc messages mean, rather than merely specifying the message syntax. Gap in documentation found while looking at a bug report from Raf Czlonka . Modified Files: -- mandoc: mandoc.1 Revision Data - Index: mandoc.1 === RCS file: /home/cvs/mandoc/mandoc/mandoc.1,v retrieving revision 1.232 retrieving revision 1.233 diff -Lmandoc.1 -Lmandoc.1 -u -p -r1.232 -r1.233 --- mandoc.1 +++ mandoc.1 @@ -714,13 +714,29 @@ Messages displayed by follow this format: .Bd -ragged -offset indent .Nm : -.Ar file : Ns Ar line : Ns Ar column : level : message : macro args +.Ar file : Ns Ar line : Ns Ar column : level : message : macro arguments .Pq Ar os .Ed .Pp -Line and column numbers start at 1. +The first three fields identify the +.Ar file +name, +.Ar line +number, and +.Ar column +number of the input file where the message was triggered. +The line and column numbers start at 1. Both are omitted for messages referring to an input file as a whole. -Macro names and arguments are omitted where meaningless. +All +.Ar level +and +.Ar message +strings are explained below. +The name of the +.Ar macro +triggering the message and its +.Ar arguments +are
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: schwa...@cvs.openbsd.org2018/11/29 16:12:59 Modified files: misc/pfm : Makefile Log message: Drop USE_GROFF and bump. Only insignificant formatting differences remain after the latest tbl(7) automatic column width improvements.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: schwa...@cvs.openbsd.org2018/11/29 08:22:31 Modified files: graphics/xmedcon: Makefile Log message: Drop USE_GROFF and bump: only unimportant white space differences in output. Likely fixed by the recent improvement of automatic column width assignments.
Re: [WIP/NEW] 1oom - Master of Orion 1 engine
Hi Max, Max Fillinger wrote on Sat, Nov 24, 2018 at 01:05:17AM +0100: >> * No MAINTAINER--do you want it? > What does that entail? I want to keep this port working and up to > date, if I can. That's exactly what being a good MAINTAINER means. > But I won't be any help if someone has, for example, a > problem on a non-i386/amd64 platform. If there is something you cannot solve or you are unsure about, you just ask for help. Nothing is wrong with a MAINTAINER who asks for help when he needs it. Yours, Ingo
