Re: UPDATE: x11/fvwm3 to 1.0.7
Ingo Schwarze wrote (2023-09-04 16:27 IST): > 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. Works as intended here. I'd be happy with this. I'm already finding new manpages. > >> Then you could stop after the second match in the same section. > > Actually, i think that's not even worth bothering. On a relatively fast laptop it's not noticeable. Without your patch: Benchmark 1: man -c FvwmButtons Time (mean ± σ): 8.9 ms ± 0.5 ms[User: 4.3 ms, System: 3.6 ms] Range (min … max): 7.6 ms … 11.5 ms800 runs With your patch: Benchmark 1: man -c FvwmButtons Time (mean ± σ): 9.8 ms ± 0.6 ms[User: 5.2 ms, System: 3.8 ms] Range (min … max): 8.4 ms … 14.8 ms800 runs Do you want to loop tech@ in on this? Or collect more feedback? I'm keeping this in my tree for now and will let you know if something unexpected happens. Best regards, Stefan
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
On 2023/09/04 11:05, Stefan Hagen wrote: > How about: > > $ man 1 autoconf > There is more than one version of this manpage available (show with -w). oh that's a decent alternative. > > AUTOCONF(1) FSF > AUTOCONF(1) > ... > > Then you could stop after the second match in the same section. > > Best regards, > Stefan
Re: UPDATE: x11/fvwm3 to 1.0.7
On 2023/09/04 02:42, Ingo Schwarze wrote: > 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. FWIW I like it. Even ignoring ports, we've had problems just in base where people have upgraded and not followed instructions about removing old files, and been left with e.g. the fw_update(1) manual being displayed with no indication that there's an fw_update(8). > 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? Typically locate/pkglocate for me, then sifting through the output. But I wouldn't run that unless I _already_ suspected there might be multiple manual pages for the name.
Re: UPDATE: x11/fvwm3 to 1.0.7
Ingo Schwarze wrote (2023-09-04 01:42 IST): > 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 Does it work for you like this? Because here it doesn't. It works for printf, but for FvwmPager / FvwmButtons, no alternatives are displayed. We should probably only display results from the same section. For other sections, the "SEE ALSO" part of the manpage is sufficient. This would also lead to the "feature" not run that often. Most of the time "man " should just show the manpage. For insanity reasons, I installed all autoconfs: $ man 1 autoconf Showing: /usr/local/man/man1/autoconf-2.52.1 See also: /usr/local/man/man1/autoconf-2.54.1 See also: /usr/local/man/man1/autoconf-2.56.1 See also: /usr/local/man/man1/autoconf-2.57.1 See also: /usr/local/man/man1/autoconf-2.58.1 See also: /usr/local/man/man1/autoconf-2.59.1 See also: /usr/local/man/man1/autoconf-2.60.1 See also: /usr/local/man/man1/autoconf-2.61.1 See also: /usr/local/man/man1/autoconf-2.62.1 See also: /usr/local/man/man1/autoconf-2.63.1 See also: /usr/local/man/man1/autoconf-2.64.1 See also: /usr/local/man/man1/autoconf-2.65.1 See also: /usr/local/man/man1/autoconf-2.67.1 See also: /usr/local/man/man1/autoconf-2.68.1 See also: /usr/local/man/man1/autoconf-2.69.1 See also: /usr/local/man/man1/autoconf-2.71.1 AUTOCONF(1) FSF AUTOCONF(1) ... Is this too much at the top of the man page? It should also be excluded for non-interactive use. Some web frontends do "man $thing | text2html > $thing.html" How about: $ man 1 autoconf There is more than one version of this manpage available (show with -w). AUTOCONF(1) FSF AUTOCONF(1) ... Then you could stop after the second match in the same section. Best regards, Stefan
Re: UPDATE: x11/fvwm3 to 1.0.7
On Mon, Sep 04, 2023 at 02:42:05AM +0200, Ingo Schwarze wrote: > 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. Let me guess. I know one guy who makes it known when he doesn't like something, but almost always in private. :) > 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 > [...] > Actually, I would argue it's even more useful in that case: it makes it obvious the manpage SHOULD be patched to have the installed command have the right name. And in case we have the same command name in several places, it's fairly easy to get confused and run the wrong one. Case in point: cups. Where all the commands are name exactly the same as stuff in base, but nothing behaves identically. It's fairly easy to get confused and lose a bit of time reading the wrong manpage. Having any kind of small indication that there are several of them could be a life-saver for lots of people. As for section stuff and things: we all got bitten years ago looking for printf and checking the section at top to figure out it was a shell command. That case is fairly obvious because the syntax is entirely different. But those things, imo, are fairly non-intuitive, and if we can help people avoid looking up the wrong information, that would be cool. Possibly in a much shrinked manner so it takes as little screen space as possible. But just because we got used to it by making the same mistake until we learnt doesn't mean Unix has to be unfriendly for newcomers.
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
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)
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
On Sun, Sep 03, 2023 at 04:19:07PM +0100, Stefan Hagen wrote: > Marc Espie wrote (2023-09-01 22:08 IST): > > On Thu, Aug 31, 2023 at 11:20:17PM +0200, Ingo Schwarze wrote: > > > 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. > > > > I don't know. The ability of install versioned manpages for the same > > software doesn't seem to be a bad idea to me. > > > > And /etc/man.conf does feature new default paths, so why not ? > > > > If adding new directories isn't the right level, maybe new sections ? > > or explicit versionned stuff. > > > > Yeah, we've installed several versions of tcl for a long time. > > > > Oh, and man has a "-a" option to display ALL manual pages. > > > > We have currently ZERO mechanism to desambiguate anything outside of > > sections... > > > > if you say, man foo, it will give you the first foo, not even hinting > > there might be a second food behind it. > > > > Yeah, we can rename stuff so that man doesn't get confused, but why > > does man get confused in the first place ? > > I think Espies suggestion is more discoverable because the user gets a > message on install he might see. > > 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. > > 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) > > 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 linux man, which can't do this) > > Another idea would be to print something to stderr when more than one > manpage for the search term is available. Either before the pager is > started or after the pager is closed. > > I don't like what some linuxes do: SuSE for example shows the user a > list and asks which one to display. This is annoying. > > --- > > I'm sending another diff with Ingos suggestion. I'm happy with this as > well. Both is inconvenient in a way, but at least the man pages are > there. > > OK? > > - Stefan Hi Stefan and everyone else involved, thanks for all the feedback and explanations! The latest revision by Stefan looks good to me, tested on amd64.
Re: UPDATE: x11/fvwm3 to 1.0.7
Marc Espie wrote (2023-09-01 22:08 IST):
> On Thu, Aug 31, 2023 at 11:20:17PM +0200, Ingo Schwarze wrote:
> > 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.
>
> I don't know. The ability of install versioned manpages for the same
> software doesn't seem to be a bad idea to me.
>
> And /etc/man.conf does feature new default paths, so why not ?
>
> If adding new directories isn't the right level, maybe new sections ?
> or explicit versionned stuff.
>
> Yeah, we've installed several versions of tcl for a long time.
>
> Oh, and man has a "-a" option to display ALL manual pages.
>
> We have currently ZERO mechanism to desambiguate anything outside of
> sections...
>
> if you say, man foo, it will give you the first foo, not even hinting
> there might be a second food behind it.
>
> Yeah, we can rename stuff so that man doesn't get confused, but why
> does man get confused in the first place ?
I think Espies suggestion is more discoverable because the user gets a
message on install he might see.
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.
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)
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 linux man, which can't do this)
Another idea would be to print something to stderr when more than one
manpage for the search term is available. Either before the pager is
started or after the pager is closed.
I don't like what some linuxes do: SuSE for example shows the user a
list and asks which one to display. This is annoying.
---
I'm sending another diff with Ingos suggestion. I'm happy with this as
well. Both is inconvenient in a way, but at least the man pages are
there.
OK?
- Stefan
Index: x11/fvwm3/Makefile
===
RCS file: /cvs/ports/x11/fvwm3/Makefile,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 Makefile
--- x11/fvwm3/Makefile 24 Jan 2023 18:05:35 - 1.8
+++ x11/fvwm3/Makefile 1 Sep 2023 15:51:43 -
@@ -1,6 +1,6 @@
COMMENT= multiple virtual desktop window manager
-VERSION= 1.0.6a
+VERSION= 1.0.7
DISTNAME= fvwm3-${VERSION}
CATEGORIES= x11
@@ -20,13 +20,14 @@ WANTLIB += readline rsvg-2 event_core ev
MASTER_SITES= https://github.com/fvwmorg/fvwm3/releases/download/${VERSION}/
+BUILD_DEPENDS+=textproc/asciidoctor
+
LIB_DEPENDS+= graphics/png \
x11/gnome/librsvg \
devel/libevent2
SUBST_VARS=VERSION
-SEPARATE_BUILD=Yes
CONFIGURE_STYLE= gnu
CONFIGURE_ARGS+= --enable-mandoc \
@@ -39,7 +40,14 @@ CONFIGURE_ENV+= CPPFLAGS="${CPPFLAGS} -
DEBUG_PACKAGES = ${BUILD_PACKAGES}
+USE_GMAKE =yes
+
post-install:
+ cd ${WRKINST}/${TRUEPREFIX}/man/man1 && for m in Fvwm*.1; \
+ do mv {,fvwm3-}$$m; done
+ cd ${WRKINST}/${TRUEPREFIX}/man/man1/ && \
+ mv fvwm3-FvwmCommand{,3}.1 && \
+ ln -s fvwm3-FvwmCommand3.1 FvwmCommand3.1
mv ${WRKINST}/${TRUEPREFIX}/bin/FvwmCommand{,3}
mv ${WRKINST}/${TRUEPREFIX}/share/FvwmScript-* \
${WRKINST}/${TRUEPREFIX}/share/fvwm3/
Index: x11/fvwm3/distinfo
===
RCS file: /cvs/ports/x11/fvwm3/distinfo,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 distinfo
--- x11/fvwm3/distinfo 22 Jan 2023 12:11:26 - 1.3
+++ x11/fvwm3/distinfo 1 Sep 2023 15:51:43 -
@@ -1,2 +1,2 @@
-SHA256 (fvwm3-1.0.6a.tar.gz) = RmWmYTPgcLeRkXsHlMxt9rdUZ56+kTBxhCfbZHm7W2g=
-SIZE (fvwm3-1.0.6a.tar.gz) = 4538100
+SHA256 (fvwm3-1.0.7.tar.gz) = OqzXz+/2DbG82cdzMtxXX+dxHS0wbwR5UlN43G2z0x4=
+SIZE (fvwm3-1.0.7.tar.gz) = 4512128
Index: x11/fvwm3/patches/patch-configure
===
RCS file: /cvs/ports/x11/fvwm3/patches/patch-configure,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 patch-configure
--- x11/fvwm3/patches/patch-configure 13 Oct 2022 16:00:45 - 1.3
+++ x11/fvwm3/patches/patch-configure 1 Sep 2023 15:51:43 -
@@ -1,7 +1,7 @@
Index: configure
--- configure.orig
+++ configure
-@@ -11779,7 +11779,7 @@ then :
+@@ -11726,7 +11726,7 @@ then :
else $as_nop
with_intl=maybe
Index:
Re: UPDATE: x11/fvwm3 to 1.0.7
On Thu, Aug 31, 2023 at 11:20:17PM +0200, Ingo Schwarze wrote: > 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. I don't know. The ability of install versioned manpages for the same software doesn't seem to be a bad idea to me. And /etc/man.conf does feature new default paths, so why not ? If adding new directories isn't the right level, maybe new sections ? or explicit versionned stuff. Yeah, we've installed several versions of tcl for a long time. Oh, and man has a "-a" option to display ALL manual pages. We have currently ZERO mechanism to desambiguate anything outside of sections... if you say, man foo, it will give you the first foo, not even hinting there might be a second food behind it. Yeah, we can rename stuff so that man doesn't get confused, but why does man get confused in the first place ?
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: UPDATE: x11/fvwm3 to 1.0.7
I wanted to say, no support in pkg_add for suddenly conflicting packages after an update is by design: there is no way this can't be seen as anything but a regression. Imagine: you install packages A and B, you go to update them, and suddenly the new versions conflict. The supported cases are classic cases of upstream fiddling with their bits, like for instance the new B is a merge of the old A and B. But anything else will require manual intervention: if the conflict is genuine, the user will have to make a choice. There are several cases where maintainers should be able to do something smart: - the conflict is accidental. Some peripheral files have the same names, which is usually fixed by either renaming/removing the extra files. - the conflicting files are the exact same thing in both packages... which means there is a common small package to build containing the files in question, and making both new packages depending on those common files will be enough. - one of the new packages suddenly provides the services of the other package "on the side", in a slightly different way. That's a perfect scenario for MULTI_PACKAGES obviously. In the case at hand, fvwm2 vs fvwm3, there are genuine use cases for wanting both: fvwm2 and fvwm3 are slightly tricky beasts, and I have BOTH installed on my machines at the same time, because I run into regression once in a blue moon. The main files do not conflict. Versioning the manpages will work. Note that we routinely do much much worse in order to be able to install, say, 10 versions of autoconf at the same time. Tl;dr: there is no tooling solution because it's not a tooling problem. There is some genuine human thought required to give us something that's not a crazy design.
Re: UPDATE: x11/fvwm3 to 1.0.7
Stuart Henderson wrote (2023-08-30 10:45 CEST):
> > > manually for now. Further some *.adoc files required setting the correct
> > > absolute path in the include statement which is what the sed run in
> ...
> > If you don't set SEPARATE_BUILD=yes, then the manpage generation happens
> > as intended and the mess goes away :)
>
> yes this is a classic case of the problems often caused by
> SEPARATE_BUILD. (another classic is tests failing).
>
> I would not normally recommend SEPARATE_BUILD unless a port takes so
> long to extract that "make clean=build" actually saves much real time
> compared to "make clean;make patch"..
>
> > 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)
> >
> > 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
>
> This does make sense for the manpages for libexec files. However
> I think it might be nice to keep the non-conflicting manuals in
> the old location, which is in the default search path, so that
> commands like "man fvwm3" work out of the box.
>
> i.e. mv man1/fvwm3*.1 and man1/FvwmCommand3.1 to prefix/man/man1.
We can do either an ugly roundtrip move:
mv ${WRKINST}/${TRUEPREFIX}/man/man1/* \
${WRKINST}/${TRUEPREFIX}/share/fvwm3/man/man1/
mv ${WRKINST}/${TRUEPREFIX}/share/fvwm3/man/man1/{fvwm3,FvwmCom}* \
${WRKINST}/${TRUEPREFIX}/man/man1/
Or some ugly globbing:
mv ${WRKINST}/${TRUEPREFIX}/man/man1/Fvwm{A,B,Con,E,F,I,M,P,R,S}* \
${WRKINST}/${TRUEPREFIX}/share/fvwm3/man/man1/
Patch below with the globbing solution.
I'll look further if I can make --mandir work. But this can be done in
tree as well.
OK/Comments for this patch?
- Stefan
Index: x11/fvwm3/Makefile
===
RCS file: /cvs/ports/x11/fvwm3/Makefile,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 Makefile
--- x11/fvwm3/Makefile 24 Jan 2023 18:05:35 - 1.8
+++ x11/fvwm3/Makefile 30 Aug 2023 17:29:54 -
@@ -1,6 +1,6 @@
COMMENT= multiple virtual desktop window manager
-VERSION= 1.0.6a
+VERSION= 1.0.7
DISTNAME= fvwm3-${VERSION}
CATEGORIES= x11
@@ -20,13 +20,14 @@ WANTLIB += readline rsvg-2 event_core ev
MASTER_SITES= https://github.com/fvwmorg/fvwm3/releases/download/${VERSION}/
+BUILD_DEPENDS+=textproc/asciidoctor
+
LIB_DEPENDS+= graphics/png \
x11/gnome/librsvg \
devel/libevent2
SUBST_VARS=VERSION
-SEPARATE_BUILD=Yes
CONFIGURE_STYLE= gnu
CONFIGURE_ARGS+= --enable-mandoc \
@@ -39,7 +40,13 @@ CONFIGURE_ENV+= CPPFLAGS="${CPPFLAGS} -
DEBUG_PACKAGES = ${BUILD_PACKAGES}
+USE_GMAKE =yes
+
post-install:
+ ${INSTALL_DATA_DIR} ${WRKINST}/${TRUEPREFIX}/share/fvwm3/man/man1
+ mv ${WRKINST}/${TRUEPREFIX}/man/man1/Fvwm{A,B,Con,E,F,I,M,P,R,S}* \
+ ${WRKINST}/${TRUEPREFIX}/share/fvwm3/man/man1/
+ mv ${WRKINST}/${TRUEPREFIX}/man/man1/FvwmCommand{,3}.1
mv ${WRKINST}/${TRUEPREFIX}/bin/FvwmCommand{,3}
mv ${WRKINST}/${TRUEPREFIX}/share/FvwmScript-* \
${WRKINST}/${TRUEPREFIX}/share/fvwm3/
Index: x11/fvwm3/distinfo
===
RCS file: /cvs/ports/x11/fvwm3/distinfo,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 distinfo
--- x11/fvwm3/distinfo 22 Jan 2023 12:11:26 - 1.3
+++ x11/fvwm3/distinfo 30 Aug 2023 17:29:54 -
@@ -1,2 +1,2 @@
-SHA256 (fvwm3-1.0.6a.tar.gz) = RmWmYTPgcLeRkXsHlMxt9rdUZ56+kTBxhCfbZHm7W2g=
-SIZE (fvwm3-1.0.6a.tar.gz) = 4538100
+SHA256 (fvwm3-1.0.7.tar.gz) = OqzXz+/2DbG82cdzMtxXX+dxHS0wbwR5UlN43G2z0x4=
+SIZE (fvwm3-1.0.7.tar.gz) = 4512128
Index: x11/fvwm3/patches/patch-configure
===
RCS file: /cvs/ports/x11/fvwm3/patches/patch-configure,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 patch-configure
--- x11/fvwm3/patches/patch-configure 13 Oct 2022 16:00:45 - 1.3
+++ x11/fvwm3/patches/patch-configure 30 Aug 2023 17:29:54 -
@@ -1,7 +1,7 @@
Index: configure
--- configure.orig
+++ configure
-@@ -11779,7 +11779,7 @@ then :
+@@ -11726,7 +11726,7 @@ then :
else $as_nop
with_intl=maybe
Index: x11/fvwm3/patches/patch-default-config_Makefile_in
===
RCS file: /cvs/ports/x11/fvwm3/patches/patch-default-config_Makefile_in,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 patch-default-config_Makefile_in
--- x11/fvwm3/patches/patch-default-config_Makefile_in 13 Oct 2022 16:00:45
- 1.3
+++
Re: UPDATE: x11/fvwm3 to 1.0.7
> > manually for now. Further some *.adoc files required setting the correct
> > absolute path in the include statement which is what the sed run in
...
> If you don't set SEPARATE_BUILD=yes, then the manpage generation happens
> as intended and the mess goes away :)
yes this is a classic case of the problems often caused by
SEPARATE_BUILD. (another classic is tests failing).
I would not normally recommend SEPARATE_BUILD unless a port takes so
long to extract that "make clean=build" actually saves much real time
compared to "make clean;make patch"..
> 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)
>
> 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
This does make sense for the manpages for libexec files. However
I think it might be nice to keep the non-conflicting manuals in
the old location, which is in the default search path, so that
commands like "man fvwm3" work out of the box.
i.e. mv man1/fvwm3*.1 and man1/FvwmCommand3.1 to prefix/man/man1.
> @bin libexec/fvwm3/${VERSION}/FvwmRearrange
> @bin libexec/fvwm3/${VERSION}/FvwmScript
> libexec/fvwm3/${VERSION}/FvwmTalk
> -@man man/man1/fvwm3-menu-directory.1
> -@man man/man1/fvwm3-menu-xlock.1
> -@man man/man1/fvwm3-perllib.1
> share/fvwm3/
> share/fvwm3/ConfigFvwmBacker
> share/fvwm3/ConfigFvwmButtons
> @@ -139,6 +136,35 @@ share/fvwm3/locale/zh_CN/
> share/fvwm3/locale/zh_CN/LC_MESSAGES/
> share/fvwm3/locale/zh_CN/LC_MESSAGES/FvwmScript.mo
> share/fvwm3/locale/zh_CN/LC_MESSAGES/fvwm.mo
> +@mandir share/fvwm3/man/
> +share/fvwm3/man/man1/
> +@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
> +@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
> share/fvwm3/perllib/
> share/fvwm3/perllib/FVWM/
> share/fvwm3/perllib/FVWM/Commands.pm
>
Re: UPDATE: x11/fvwm3 to 1.0.7
Michael wrote (2023-08-28 23:59 CEST):
> On Sun, Aug 27, 2023 at 11:19:22PM +0200, Stefan Hagen wrote:
> > Michael wrote (2023-08-27 02:07 CEST):
> > > On Fri, Aug 25, 2023 at 02:41:25PM +0200, Michael wrote:
> > > > Hi ports@,
> > > >
> > > > this is an update to the latest fvwm3 release [1].
> > > >
> > > > Unfortunately there was a bug [2] that caused consistent crashes on
> > > > OpenBSD. Reverting the commit in question seems to resolve that issue,
> > > > which is also what others [3] seem to be doing for now. Patch for this
> > > > is included as 'patch-fvwm_ewmh_names_c'.
> > > >
> > > > Tested on amd64.
> > > >
> > > >
> > > > [1] https://github.com/fvwmorg/fvwm3/releases/tag/1.0.7
> > > > [2] https://github.com/fvwmorg/fvwm3/issues/873
> > > > [3]
> > > > https://github.com/freebsd/freebsd-ports/commit/3e35051e913e46e0132df070d5a718d443bfd0b8
> > >
> > > Upstream commited a fix for the mentioned issue so let's use this
> > > instead, see 'patch-fvwm_ewmh_c'. Patch below.
> > >
> > > Tested on amd64.
> >
> > Works here. It starts and most buttons work (default setup). I have
> > not seen any crashes.
> >
> > OK sdk
> >
> > However, the default config could use some attention:
> > * It doesn't honor --program-transform-name (executables and manpages)
> > * It links to manpages that don't exist
> > * It links to manpages from base fvwm
> >
> > - Stefan
> >
>
> Thank you for your feedback Stefan. I had a look into this and it looks
> like manpages were never built at all. Enabling this required adding
> textproc/asciidoctor and switching to gmake. The wildcard expansion in
> doc/Makefile.in didn't seem to work so I put the file names in there
> manually for now. Further some *.adoc files required setting the correct
> absolute path in the include statement which is what the sed run in
> pre-configure is for. Those manpages should conflict with x11/fvwm2 so I
> think we need '@conflict fvwm2-*' in PLIST now. I am not sure if this
> requires adding an additional entry to quirks too?
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)
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 don't really like the patch or sed call to get the manpages built.
> Does someone have any ideas how to improve this? Then again it works
> for now...
If you don't set SEPARATE_BUILD=yes, then the manpage generation happens
as intended and the mess goes away :)
Patch below with the following changes:
- remove separate build
- move manpages to install dir (--mandir at configure time has no effect)
- rename FvwmCommand.1 man page to FvwmCommand3.1 to match the executable
Only build tested for now because I have to leave for work.
- Stefan
Index: x11/fvwm3/Makefile
===
RCS file: /cvs/ports/x11/fvwm3/Makefile,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 Makefile
--- x11/fvwm3/Makefile 24 Jan 2023 18:05:35 - 1.8
+++ x11/fvwm3/Makefile 30 Aug 2023 07:30:45 -
@@ -1,6 +1,6 @@
COMMENT= multiple virtual desktop window manager
-VERSION= 1.0.6a
+VERSION= 1.0.7
DISTNAME= fvwm3-${VERSION}
CATEGORIES= x11
@@ -20,13 +20,14 @@ WANTLIB += readline rsvg-2 event_core ev
MASTER_SITES= https://github.com/fvwmorg/fvwm3/releases/download/${VERSION}/
+BUILD_DEPENDS+=textproc/asciidoctor
+
LIB_DEPENDS+= graphics/png \
x11/gnome/librsvg \
devel/libevent2
SUBST_VARS=VERSION
-SEPARATE_BUILD=Yes
CONFIGURE_STYLE= gnu
CONFIGURE_ARGS+= --enable-mandoc \
@@ -39,7 +40,12 @@ CONFIGURE_ENV+= CPPFLAGS="${CPPFLAGS} -
DEBUG_PACKAGES = ${BUILD_PACKAGES}
+USE_GMAKE =yes
+
post-install:
+ ${INSTALL_DATA_DIR} ${WRKINST}/${TRUEPREFIX}/share/fvwm3/man/
+ mv ${WRKINST}/${TRUEPREFIX}/man/man1
${WRKINST}/${TRUEPREFIX}/share/fvwm3/man/
+ mv ${WRKINST}/${TRUEPREFIX}/share/fvwm3/man/man1/FvwmCommand{,3}.1
mv ${WRKINST}/${TRUEPREFIX}/bin/FvwmCommand{,3}
mv ${WRKINST}/${TRUEPREFIX}/share/FvwmScript-* \
${WRKINST}/${TRUEPREFIX}/share/fvwm3/
Index: x11/fvwm3/distinfo
===
RCS file: /cvs/ports/x11/fvwm3/distinfo,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 distinfo
--- x11/fvwm3/distinfo 22 Jan 2023 12:11:26 - 1.3
+++ x11/fvwm3/distinfo 30 Aug 2023 07:30:45 -
@@ -1,2 +1,2 @@
-SHA256 (fvwm3-1.0.6a.tar.gz) = RmWmYTPgcLeRkXsHlMxt9rdUZ56+kTBxhCfbZHm7W2g=
-SIZE (fvwm3-1.0.6a.tar.gz) = 4538100
+SHA256 (fvwm3-1.0.7.tar.gz) = OqzXz+/2DbG82cdzMtxXX+dxHS0wbwR5UlN43G2z0x4=
+SIZE (fvwm3-1.0.7.tar.gz) =
Re: UPDATE: x11/fvwm3 to 1.0.7
On Sun, Aug 27, 2023 at 11:19:22PM +0200, Stefan Hagen wrote:
> Michael wrote (2023-08-27 02:07 CEST):
> > On Fri, Aug 25, 2023 at 02:41:25PM +0200, Michael wrote:
> > > Hi ports@,
> > >
> > > this is an update to the latest fvwm3 release [1].
> > >
> > > Unfortunately there was a bug [2] that caused consistent crashes on
> > > OpenBSD. Reverting the commit in question seems to resolve that issue,
> > > which is also what others [3] seem to be doing for now. Patch for this
> > > is included as 'patch-fvwm_ewmh_names_c'.
> > >
> > > Tested on amd64.
> > >
> > >
> > > [1] https://github.com/fvwmorg/fvwm3/releases/tag/1.0.7
> > > [2] https://github.com/fvwmorg/fvwm3/issues/873
> > > [3]
> > > https://github.com/freebsd/freebsd-ports/commit/3e35051e913e46e0132df070d5a718d443bfd0b8
> >
> > Upstream commited a fix for the mentioned issue so let's use this
> > instead, see 'patch-fvwm_ewmh_c'. Patch below.
> >
> > Tested on amd64.
>
> Works here. It starts and most buttons work (default setup). I have
> not seen any crashes.
>
> OK sdk
>
> However, the default config could use some attention:
> * It doesn't honor --program-transform-name (executables and manpages)
> * It links to manpages that don't exist
> * It links to manpages from base fvwm
>
> - Stefan
>
Thank you for your feedback Stefan. I had a look into this and it looks
like manpages were never built at all. Enabling this required adding
textproc/asciidoctor and switching to gmake. The wildcard expansion in
doc/Makefile.in didn't seem to work so I put the file names in there
manually for now. Further some *.adoc files required setting the correct
absolute path in the include statement which is what the sed run in
pre-configure is for. Those manpages should conflict with x11/fvwm2 so I
think we need '@conflict fvwm2-*' in PLIST now. I am not sure if this
requires adding an additional entry to quirks too?
I don't really like the patch or sed call to get the manpages built. Does
someone have any ideas how to improve this? Then again it works for now...
Slightly tested on amd64, updated patch below.
Index: Makefile
===
RCS file: /cvs/ports/x11/fvwm3/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile24 Jan 2023 18:05:35 - 1.8
+++ Makefile28 Aug 2023 21:29:04 -
@@ -1,6 +1,6 @@
COMMENT= multiple virtual desktop window manager
-VERSION= 1.0.6a
+VERSION= 1.0.7
DISTNAME= fvwm3-${VERSION}
CATEGORIES= x11
@@ -20,6 +20,8 @@ WANTLIB += readline rsvg-2 event_core ev
MASTER_SITES= https://github.com/fvwmorg/fvwm3/releases/download/${VERSION}/
+BUILD_DEPENDS= textproc/asciidoctor
+
LIB_DEPENDS+= graphics/png \
x11/gnome/librsvg \
devel/libevent2
@@ -27,17 +29,22 @@ LIB_DEPENDS+= graphics/png \
SUBST_VARS=VERSION
SEPARATE_BUILD=Yes
+USE_GMAKE= Yes
CONFIGURE_STYLE= gnu
CONFIGURE_ARGS+= --enable-mandoc \
--disable-bidi \
- --program-transform-name='s/^fvwm-/fvwm3-/' \
- --localedir=${TRUEPREFIX}/share/fvwm3/locale
+ --localedir=${TRUEPREFIX}/share/fvwm3/locale \
+ --program-transform-name='s/^fvwm-/fvwm3-/'
CONFIGURE_ENV+=CPPFLAGS="${CPPFLAGS} -I${LOCALBASE}/include" \
LDFLAGS="${LDFLAGS} -L${LOCALBASE}/lib"
DEBUG_PACKAGES = ${BUILD_PACKAGES}
+
+pre-configure:
+ sed -Ei 's#^(include::)(.*\.ad)(\[.*\])#\1'${WRKBUILD}'/doc/\2\3#' \
+ ${WRKSRC}/doc/*.adoc
post-install:
mv ${WRKINST}/${TRUEPREFIX}/bin/FvwmCommand{,3}
Index: distinfo
===
RCS file: /cvs/ports/x11/fvwm3/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo22 Jan 2023 12:11:26 - 1.3
+++ distinfo28 Aug 2023 21:29:04 -
@@ -1,2 +1,2 @@
-SHA256 (fvwm3-1.0.6a.tar.gz) = RmWmYTPgcLeRkXsHlMxt9rdUZ56+kTBxhCfbZHm7W2g=
-SIZE (fvwm3-1.0.6a.tar.gz) = 4538100
+SHA256 (fvwm3-1.0.7.tar.gz) = OqzXz+/2DbG82cdzMtxXX+dxHS0wbwR5UlN43G2z0x4=
+SIZE (fvwm3-1.0.7.tar.gz) = 4512128
Index: patches/patch-configure
===
RCS file: /cvs/ports/x11/fvwm3/patches/patch-configure,v
retrieving revision 1.3
diff -u -p -r1.3 patch-configure
--- patches/patch-configure 13 Oct 2022 16:00:45 - 1.3
+++ patches/patch-configure 28 Aug 2023 21:29:04 -
@@ -1,7 +1,7 @@
Index: configure
--- configure.orig
+++ configure
-@@ -11779,7 +11779,7 @@ then :
+@@ -11726,7 +11726,7 @@ then :
else $as_nop
with_intl=maybe
Index: patches/patch-default-config_Makefile_in
===
RCS file: /cvs/ports/x11/fvwm3/patches/patch-default-config_Makefile_in,v
Re: UPDATE: x11/fvwm3 to 1.0.7
Michael wrote (2023-08-27 02:07 CEST): > On Fri, Aug 25, 2023 at 02:41:25PM +0200, Michael wrote: > > Hi ports@, > > > > this is an update to the latest fvwm3 release [1]. > > > > Unfortunately there was a bug [2] that caused consistent crashes on > > OpenBSD. Reverting the commit in question seems to resolve that issue, > > which is also what others [3] seem to be doing for now. Patch for this > > is included as 'patch-fvwm_ewmh_names_c'. > > > > Tested on amd64. > > > > > > [1] https://github.com/fvwmorg/fvwm3/releases/tag/1.0.7 > > [2] https://github.com/fvwmorg/fvwm3/issues/873 > > [3] > > https://github.com/freebsd/freebsd-ports/commit/3e35051e913e46e0132df070d5a718d443bfd0b8 > > Upstream commited a fix for the mentioned issue so let's use this > instead, see 'patch-fvwm_ewmh_c'. Patch below. > > Tested on amd64. Works here. It starts and most buttons work (default setup). I have not seen any crashes. OK sdk However, the default config could use some attention: * It doesn't honor --program-transform-name (executables and manpages) * It links to manpages that don't exist * It links to manpages from base fvwm - Stefan
Re: UPDATE: x11/fvwm3 to 1.0.7
On Fri, Aug 25, 2023 at 02:41:25PM +0200, Michael wrote:
> Hi ports@,
>
> this is an update to the latest fvwm3 release [1].
>
> Unfortunately there was a bug [2] that caused consistent crashes on
> OpenBSD. Reverting the commit in question seems to resolve that issue,
> which is also what others [3] seem to be doing for now. Patch for this
> is included as 'patch-fvwm_ewmh_names_c'.
>
> Tested on amd64.
>
>
> [1] https://github.com/fvwmorg/fvwm3/releases/tag/1.0.7
> [2] https://github.com/fvwmorg/fvwm3/issues/873
> [3]
> https://github.com/freebsd/freebsd-ports/commit/3e35051e913e46e0132df070d5a718d443bfd0b8
Upstream commited a fix for the mentioned issue so let's use this
instead, see 'patch-fvwm_ewmh_c'. Patch below.
Tested on amd64.
Index: Makefile
===
RCS file: /cvs/ports/x11/fvwm3/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile24 Jan 2023 18:05:35 - 1.8
+++ Makefile26 Aug 2023 22:20:01 -
@@ -1,6 +1,6 @@
COMMENT= multiple virtual desktop window manager
-VERSION= 1.0.6a
+VERSION= 1.0.7
DISTNAME= fvwm3-${VERSION}
CATEGORIES= x11
Index: distinfo
===
RCS file: /cvs/ports/x11/fvwm3/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo22 Jan 2023 12:11:26 - 1.3
+++ distinfo26 Aug 2023 22:20:01 -
@@ -1,2 +1,2 @@
-SHA256 (fvwm3-1.0.6a.tar.gz) = RmWmYTPgcLeRkXsHlMxt9rdUZ56+kTBxhCfbZHm7W2g=
-SIZE (fvwm3-1.0.6a.tar.gz) = 4538100
+SHA256 (fvwm3-1.0.7.tar.gz) = OqzXz+/2DbG82cdzMtxXX+dxHS0wbwR5UlN43G2z0x4=
+SIZE (fvwm3-1.0.7.tar.gz) = 4512128
Index: patches/patch-configure
===
RCS file: /cvs/ports/x11/fvwm3/patches/patch-configure,v
retrieving revision 1.3
diff -u -p -r1.3 patch-configure
--- patches/patch-configure 13 Oct 2022 16:00:45 - 1.3
+++ patches/patch-configure 26 Aug 2023 22:20:01 -
@@ -1,7 +1,7 @@
Index: configure
--- configure.orig
+++ configure
-@@ -11779,7 +11779,7 @@ then :
+@@ -11726,7 +11726,7 @@ then :
else $as_nop
with_intl=maybe
Index: patches/patch-default-config_Makefile_in
===
RCS file: /cvs/ports/x11/fvwm3/patches/patch-default-config_Makefile_in,v
retrieving revision 1.3
diff -u -p -r1.3 patch-default-config_Makefile_in
--- patches/patch-default-config_Makefile_in13 Oct 2022 16:00:45 -
1.3
+++ patches/patch-default-config_Makefile_in26 Aug 2023 22:20:01 -
@@ -1,7 +1,7 @@
Index: default-config/Makefile.in
--- default-config/Makefile.in.orig
+++ default-config/Makefile.in
-@@ -593,9 +593,10 @@ uninstall-am: uninstall-configDATA
+@@ -574,9 +574,10 @@ uninstall-am: uninstall-configDATA
install-data-hook:
cp -r $(srcdir)/images $(inst_location)/default-config
Index: patches/patch-fvwm_ewmh_c
===
RCS file: patches/patch-fvwm_ewmh_c
diff -N patches/patch-fvwm_ewmh_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-fvwm_ewmh_c 26 Aug 2023 22:20:01 -
@@ -0,0 +1,24 @@
+https://github.com/fvwmorg/fvwm3/commit/4d5a697fac3282af18cacebb6d061c92db410f1a
+Fixes https://github.com/fvwmorg/fvwm3/issues/873
+
+Index: fvwm/ewmh.c
+--- fvwm/ewmh.c.orig
fvwm/ewmh.c
+@@ -458,7 +458,7 @@ void *atom_get(Window win, Atom to_get, Atom type, int
+ int asize;
+
+ asize = atom_size(format_ret);
+- data = fxmalloc(num_ret * asize);
++ data = fxmalloc(num_ret * asize + 1);
+ if (format_ret == 32 && asize * 8 != format_ret)
+ {
+ int i;
+@@ -472,7 +472,7 @@ void *atom_get(Window win, Atom to_get, Atom type, int
+ {
+ if (data)
+ {
+- memcpy(data, retval, num_ret * asize);
++ memcpy(data, retval, num_ret * asize + 1);
+ }
+ }
+ XFree(retval);
UPDATE: x11/fvwm3 to 1.0.7
Hi ports@,
this is an update to the latest fvwm3 release [1].
Unfortunately there was a bug [2] that caused consistent crashes on
OpenBSD. Reverting the commit in question seems to resolve that issue,
which is also what others [3] seem to be doing for now. Patch for this
is included as 'patch-fvwm_ewmh_names_c'.
Tested on amd64.
[1] https://github.com/fvwmorg/fvwm3/releases/tag/1.0.7
[2] https://github.com/fvwmorg/fvwm3/issues/873
[3]
https://github.com/freebsd/freebsd-ports/commit/3e35051e913e46e0132df070d5a718d443bfd0b8
Index: Makefile
===
RCS file: /cvs/ports/x11/fvwm3/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile24 Jan 2023 18:05:35 - 1.8
+++ Makefile25 Aug 2023 12:22:31 -
@@ -1,6 +1,6 @@
COMMENT= multiple virtual desktop window manager
-VERSION= 1.0.6a
+VERSION= 1.0.7
DISTNAME= fvwm3-${VERSION}
CATEGORIES= x11
Index: distinfo
===
RCS file: /cvs/ports/x11/fvwm3/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo22 Jan 2023 12:11:26 - 1.3
+++ distinfo25 Aug 2023 12:22:31 -
@@ -1,2 +1,2 @@
-SHA256 (fvwm3-1.0.6a.tar.gz) = RmWmYTPgcLeRkXsHlMxt9rdUZ56+kTBxhCfbZHm7W2g=
-SIZE (fvwm3-1.0.6a.tar.gz) = 4538100
+SHA256 (fvwm3-1.0.7.tar.gz) = OqzXz+/2DbG82cdzMtxXX+dxHS0wbwR5UlN43G2z0x4=
+SIZE (fvwm3-1.0.7.tar.gz) = 4512128
Index: patches/patch-configure
===
RCS file: /cvs/ports/x11/fvwm3/patches/patch-configure,v
retrieving revision 1.3
diff -u -p -r1.3 patch-configure
--- patches/patch-configure 13 Oct 2022 16:00:45 - 1.3
+++ patches/patch-configure 25 Aug 2023 12:22:31 -
@@ -1,7 +1,7 @@
Index: configure
--- configure.orig
+++ configure
-@@ -11779,7 +11779,7 @@ then :
+@@ -11726,7 +11726,7 @@ then :
else $as_nop
with_intl=maybe
Index: patches/patch-default-config_Makefile_in
===
RCS file: /cvs/ports/x11/fvwm3/patches/patch-default-config_Makefile_in,v
retrieving revision 1.3
diff -u -p -r1.3 patch-default-config_Makefile_in
--- patches/patch-default-config_Makefile_in13 Oct 2022 16:00:45 -
1.3
+++ patches/patch-default-config_Makefile_in25 Aug 2023 12:22:31 -
@@ -1,7 +1,7 @@
Index: default-config/Makefile.in
--- default-config/Makefile.in.orig
+++ default-config/Makefile.in
-@@ -593,9 +593,10 @@ uninstall-am: uninstall-configDATA
+@@ -574,9 +574,10 @@ uninstall-am: uninstall-configDATA
install-data-hook:
cp -r $(srcdir)/images $(inst_location)/default-config
Index: patches/patch-fvwm_ewmh_names_c
===
RCS file: patches/patch-fvwm_ewmh_names_c
diff -N patches/patch-fvwm_ewmh_names_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-fvwm_ewmh_names_c 25 Aug 2023 12:22:31 -
@@ -0,0 +1,133 @@
+Revert b7ae07c34bb9172b8aba964023c2febc178f7f97 to work around
+https://github.com/fvwmorg/fvwm3/issues/873
+
+Index: fvwm/ewmh_names.c
+--- fvwm/ewmh_names.c.orig
fvwm/ewmh_names.c
+@@ -125,14 +125,15 @@ int EWMH_WMIconName(
+ {
+ int size = 0;
+ char *val;
+- char *text;
++ char *tmp_str;
++ FlocaleCharset *fc = NULL;
+
+ if (!FiconvSupport)
+ {
+ return 0;
+ }
+
+- text = val = ewmh_AtomGetByName(
++ val = ewmh_AtomGetByName(
+ FW_W(fw), "_NET_WM_ICON_NAME",
+ EWMH_ATOM_LIST_PROPERTY_NOTIFY, );
+
+@@ -141,25 +142,28 @@ int EWMH_WMIconName(
+ SET_HAS_EWMH_WM_ICON_NAME(fw,0);
+ return 0;
+ }
+- if (IS_ICON_FONT_LOADED(fw) && fw->icon_font != NULL &&
fw->icon_font->fftf.fftfont[0] == NULL)
++ if (IS_ICON_FONT_LOADED(fw) && fw->icon_font != NULL)
+ {
+- text = FiconvUtf8ToCharset(dpy, fw->icon_font->str_fc, val,
size);
+- free(val);
++ fc = fw->icon_font->str_fc;
+ }
+- if (text == NULL)
++
++ tmp_str = (char *)FiconvUtf8ToCharset(
++ dpy, fc, (const char *) val, size);
++ free(val);
++ if (tmp_str == NULL)
+ {
+ SET_HAS_EWMH_WM_ICON_NAME(fw, 0);
+ return 0;
+ }
+- if (strlen(text) > MAX_ICON_NAME_LEN)
++ if (strlen(tmp_str) > MAX_ICON_NAME_LEN)
+ {
+- text[MAX_ICON_NAME_LEN] = 0;
++ tmp_str[MAX_ICON_NAME_LEN] = 0;
+ }
+ SET_HAS_EWMH_WM_ICON_NAME(fw, 1);
+- if (fw->icon_name.name && strcmp(text, fw->icon_name.name) == 0)
++ if (fw->icon_name.name && strcmp(tmp_str, fw->icon_name.name) == 0)
+ {
+ /* migo: some apps update their names every second */
+- free(text);
++ free(tmp_str);
+ return 0;
+
