man-pages: 6.05.01 -> 6.7

[trofi]

Description of changes

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[marsam]

Apparently, this bump breaks man-pages on Darwin. I guess /dev/stdin behaves different on Darwin.

...
INSTALL         /nix/store/3s28l9ijlkmsq8256zdxjvl173gkn37c-man-pages-6.7/share/man/man3/addseverity.3
INSTALL         /nix/store/3s28l9ijlkmsq8256zdxjvl173gkn37c-man-pages-6.7/share/man/man3/adjtime.3
install: skipping file '/dev/stdin', as it was replaced while being copied
make: *** [share/mk/install/man.mk:54: /nix/store/3s28l9ijlkmsq8256zdxjvl173gkn37c-man-pages-6.7/share/man/man3/addmntent.3] Error 1
make: *** Waiting for unfinished jobs....
install: skipping file '/dev/stdin', as it was replaced while being copied
make: *** [share/mk/install/man.mk:54: /nix/store/3s28l9ijlkmsq8256zdxjvl173gkn37c-man-pages-6.7/share/man/man3/acosh.3] Error 1
install: skipping file '/dev/stdin', as it was replaced while being copied
install: skipping file '/dev/stdin', as it was replaced while being copied
install: skipping file '/dev/stdin', as it was replaced while being copied
...

Would you mind marking it as broken on Darwin?
Edit: not a blocker for merge

[Pablo1107]

Apparently, this bump breaks man-pages on Darwin. I guess /dev/stdin behaves different on Darwin.

...
INSTALL         /nix/store/3s28l9ijlkmsq8256zdxjvl173gkn37c-man-pages-6.7/share/man/man3/addseverity.3
INSTALL         /nix/store/3s28l9ijlkmsq8256zdxjvl173gkn37c-man-pages-6.7/share/man/man3/adjtime.3
install: skipping file '/dev/stdin', as it was replaced while being copied
make: *** [share/mk/install/man.mk:54: /nix/store/3s28l9ijlkmsq8256zdxjvl173gkn37c-man-pages-6.7/share/man/man3/addmntent.3] Error 1
make: *** Waiting for unfinished jobs....
install: skipping file '/dev/stdin', as it was replaced while being copied
make: *** [share/mk/install/man.mk:54: /nix/store/3s28l9ijlkmsq8256zdxjvl173gkn37c-man-pages-6.7/share/man/man3/acosh.3] Error 1
install: skipping file '/dev/stdin', as it was replaced while being copied
install: skipping file '/dev/stdin', as it was replaced while being copied
install: skipping file '/dev/stdin', as it was replaced while being copied
...

Would you mind marking it as broken on Darwin? Edit: not a blocker for merge

Shouldn't have this been a blocker for merge tho?

Is there any workarounds for us Nix Darwin users?

[trofi]

Looking at the failure.

[trofi]

Filed https://bugzilla.kernel.org/show_bug.cgi?id=218730 upstream.

[alejandro-colomar]

Huh! I'm quite surprised that this is the only issue you experience in Darwin. Since the fix seems easy for the man-pages project, I'll fix it. I'll try to have a release soon, so that you don't need to be patching it.

[alejandro-colomar]

Also, would you mind reporting a bug to your install(1) vendor? I don't think I'm doing anything unreasonable by installing /dev/stdin.

[alejandro-colomar]

Since I'm here...

Would you mind reporting any other inconveniences that you may be suffering or patching from the Linux man-pages, and which you'd like to be fixed upstream?

Have a lovely day!
Alex

[eli-schwartz]

Would you mind reporting any other inconveniences that you may be suffering or patching in the Linux man-pages, and which you'd like to be fixed upstream?

Simple Makefiles are not actually simple. This is a pretty big inconvenience. :)

Also, would you mind reporting a bug to your install(1) vendor? I don't think I'm doing anything unreasonable by installing /dev/stdin.

Not all the world's a cookie-cutter GNU/Linux. Why do you think it's a bug?

Note this error message comes from GNU coreutils, not Apple.

[alejandro-colomar]

Would you mind reporting any other inconveniences that you may be suffering or patching in the Linux man-pages, and which you'd like to be fixed upstream?

Simple Makefiles are not actually simple. This is a pretty big inconvenience. :)

If you can point to specific inconveniences of this Makefile, such as non-standard behavior, I may be able to help.

I know my simple makefiles are actually not that simple. But I still consider them simpler (and more useful) than the alternatives. We agree to disagree here. :)
Still, I'm willing to help to make any inconveniences in them less inconvenient, if possible. I recently reorganized them to be easier to understand.

Also, would you mind reporting a bug to your install(1) vendor? I don't think I'm doing anything unreasonable by installing /dev/stdin.

Not all the world's a cookie-cutter GNU/Linux. Why do you think it's a bug?

Because why would a pipe be a problem for installing? Just create the file, suck the input file in a loop, and write to file what you get from the input file (in this case the input pipe).

Note this error message comes from GNU coreutils, not Apple.

Hmm, more reason to fix the bug. At least we don't need to convince the fruit store.

[trofi]

Another inconvenience we had to do is to use "SHELL=env". By default nixpkgs passes SHELL=/path/to/bash which clobbered default value of:

GNUmakefile:SHELL       := /usr/bin/env
GNUmakefile:.SHELLFLAGS := -S '$(BASH) -Eeuo pipefail -c'

and the resulting errors was a big head scratch when bash started complaining about -S option.

nixpkgs does not provide /usr/bin/env binary in the build sandbox,

[eli-schwartz]

Because why would a pipe be a problem for installing? Just create the file, suck the input file in a loop, and write to file what you get from the input file (in this case the input pipe).

It's not a pipe, it's an on-disk file that is probably a symlink to something that resolves to the same thing that the stdin file descriptor does...

[alejandro-colomar]

Because why would a pipe be a problem for installing? Just create the file, suck the input file in a loop, and write to file what you get from the input file (in this case the input pipe).

It's not a pipe, it's an on-disk file that is probably a symlink to something that resolves to the same thing that the stdin file descriptor does...

AFAIK, install(1) behaves well (follows) on symlinks.

alx@debian:~/tmp/sl$ ls -l
total 4
-rw-rw-r-- 1 alx alx 4 Apr 16 00:58 a
lrwxrwxrwx 1 alx alx 1 Apr 16 00:59 b -> a
alx@debian:~/tmp/sl$ cat a
aaa
alx@debian:~/tmp/sl$ install -m644 b c
alx@debian:~/tmp/sl$ ls -l
total 8
-rw-rw-r-- 1 alx alx 4 Apr 16 00:58 a
lrwxrwxrwx 1 alx alx 1 Apr 16 00:59 b -> a
-rw-r--r-- 1 alx alx 4 Apr 16 00:59 c
alx@debian:~/tmp/sl$ cat c
aaa

So if it tries to read /dev/stdin, it should end up reading the input pipe. Why should it care about it changing while reading?

[alejandro-colomar]

Another inconvenience we had to do is to use "SHELL=env". By default nixpkgs passes SHELL=/path/to/bash which clobbered default value of:

GNUmakefile:SHELL       := /usr/bin/env
GNUmakefile:.SHELLFLAGS := -S '$(BASH) -Eeuo pipefail -c'

and the resulting errors was a big head scratch when bash started complaining about -S option.

nixpkgs does not provide /usr/bin/env binary in the build sandbox,

Hmmm. I can fix that one. Since make(1) doesn't need a path, and it works with just the program name, I can use env instead of /usr/bin/env. Out of curiosity, where do you have env(1)?

Also, since I don't need to specify the program path, calling bash directly might be just as good, and we can avoid the weirdness of using env(1).

How about this?

SHELL := bash
.SHELLFLAGS := -Eeuo pipefail -c

[alejandro-colomar]

Please try the following branch. It should fix both the install(1) and the $SHELL issues.

https://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git/log/?h=contrib

If you confirm it's good for you, I'll push the changes to master.

[eli-schwartz]

Please try the following branch. It should fix both the install(1) and the $SHELL issues.

https://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git/log/?h=contrib

I tried, but...

Warning: Potential Security Risk Ahead

Firefox detected a potential security threat and did not continue to www.alejandro-colomar.es. If you visit this site, attackers could try to steal information like your passwords, emails, or credit card details.

Is Jia Tan in your website? What happened to https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/ ?

[alejandro-colomar]

Please try the following branch. It should fix both the install(1) and the $SHELL issues.
https://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git/log/?h=contrib

I tried, but...

Warning: Potential Security Risk Ahead
Firefox detected a potential security threat and did not continue to www.alejandro-colomar.es. If you visit this site, attackers could try to steal information like your passwords, emails, or credit card details.

Is Jia Tan in your website?

Nope :) It's documented here: http://www.alejandro-colomar.es/ssl (Edit: changed https to http link). You can verify the SSL certificate against my PGP key. If you find any issues trusting my SSL cert (maybe I issued it with some unsafe parameters; I'm no SSL expert at all), please let me know.

What happened to https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/ ?

There's the master branch, but I push changes to my own server before. Since this change is provisional, waiting for you to test it, I haven't pushed yet to <kernel.org>. All git commits are PGP-signed, so if the git server is tampered with, the signatures would be broken.

[alejandro-colomar]

Please try the following branch. It should fix both the install(1) and the $SHELL issues.
https://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git/log/?h=contrib

I tried, but...

Warning: Potential Security Risk Ahead
Firefox detected a potential security threat and did not continue to www.alejandro-colomar.es. If you visit this site, attackers could try to steal information like your passwords, emails, or credit card details.

Is Jia Tan in your website?

Nope :) It's documented here: http://www.alejandro-colomar.es/ssl (Edit: changed https to http link). You can verify the SSL certificate against my PGP key. If you find any issues trusting my SSL cert (maybe I issued it with some unsafe parameters; I'm no SSL expert at all), please let me know.

Now that I see that cert, it has Certificate Authority Yes. That's bad. I should emit a cert that's not a CA. If only openssl(1) was easier to use...

[pixelb]

What version of darwin is this? I can't repro on Darwin 21.6.0 (MacOSX 12.6).
The issue is that /dev/stdin returns a varying inode which GNU install(1) doesn't like

[trofi]

Please try the following branch. It should fix both the install(1) and the $SHELL issues.

https://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git/log/?h=contrib

If you confirm it's good for you, I'll push the changes to master.

I noticed it's already in master. Works for me as is on darwin test box. Tested againt commit edae09f52109d240facd2c71c2f13c062ed084ad "share/mk/: build-pdf-book: Fix chapter bookmarks".

Thank you!

One more minor problem I noticed is that darwin has a case-insensitive filesystem by default. It lumps these two together in a single file:

$ find -iname nan.3
./man3/NAN.3
./man3/nan.3
$ find -iname _Exit.2
./man2/_Exit.2
./man2/_exit.2

git complains that one of the file as always clobbered. And installed man page is probably incorrect.

Don't know if man allows for file names to differ from entries it contains.

[trofi]

What version of darwin is this? I can't repro on Darwin 21.6.0 (MacOSX 12.6). The issue is that /dev/stdin returns a varying inode which GNU install(1) doesn't like

This one is something older:

$ uname -a
Darwin tests-iMac.local 18.7.0 Darwin Kernel Version 18.7.0: Tue Jun 22 19:37:08 PDT 2021; root:xnu-4903.278.70~1/RELEASE_X86_64 x86_64

I'll ask what nixpkgs hydra CI uses.

[alejandro-colomar]

Please try the following branch. It should fix both the install(1) and the $SHELL issues.
https://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git/log/?h=contrib
If you confirm it's good for you, I'll push the changes to master.

I noticed it's already in master. Works for me as is on darwin test box. Tested againt commit edae09f52109d240facd2c71c2f13c062ed084ad "share/mk/: build-pdf-book: Fix chapter bookmarks".

Thank you!

You're welcome :-)

One more minor problem I noticed is that darwin has a case-insensitive filesystem by default. It lumps these two together in a single file:

$ find -iname nan.3
./man3/NAN.3
./man3/nan.3
$ find -iname _Exit.2
./man2/_Exit.2
./man2/_exit.2

Yup. I knew about this one. I guess you'll have to live with it. I don't see a solution. Maybe try to use a different file system.

git complains that one of the file as always clobbered. And installed man page is probably incorrect.

Yeah, I reproduced it in the past, when I had a macbook in a job. Also in a Windows computer (back when I used Windows for games :). I wasn't able to do man-pages' stuff there.

Don't know if man allows for file names to differ from entries it contains.

I'm not sure if I understand what you say. Can you reword?

[trofi]

Don't know if man allows for file names to differ from entries it contains.

I'm not sure if I understand what you say. Can you reword?

Does man 2 _Exit always have to imply _Exit.2 file name? Or is there a way to encode an indirection that would allow having a different file name?

[alejandro-colomar]

Don't know if man allows for file names to differ from entries it contains.

I'm not sure if I understand what you say. Can you reword?

Does man 2 _Exit always have to imply _Exit.2 file name? Or is there a way to encode an indirection that would allow having a different file name?

Hmmm. There's a way.

If man(7) cannot find a file with that name (ignoring case), it will try to find a page with that name by looking at the NAME sections of each page.

So you will need to store both pages with dummy file names, such as _exit_lowercase_dummy.2 and _exit_uppercase_dummy.2, and then, it will work.

See an experiment:

alx@debian:~/tmp/man$ ls
foo.7  qwe.7
alx@debian:~/tmp/man$ cat foo.7 
.TH bar 7 today experiment
.SH Name
baz
\-
Store a page with a different file name
alx@debian:~/tmp/man$ cat qwe.7 
.TH Bar 7 today experiment
.SH Name
Baz
\-
Store a page with a different file name
alx@debian:~/tmp/man$ sudo cp * /usr/local/man/man7
alx@debian:~/tmp/man$ sudo mandb >/dev/null
Updating index cache for path `/usr/local/man/man7'. Wait...done.
alx@debian:~/tmp/man$ man 7 bar | cat
No manual entry for bar in section 7
alx@debian:~/tmp/man$ man 7 baz | cat
bar(7)              Miscellaneous Information Manual             bar(7)

Name
     baz - Store a page with a different file name

experiment                       today                           bar(7)
alx@debian:~/tmp/man$ man 7 Baz | cat
Bar(7)              Miscellaneous Information Manual             Bar(7)

Name
     Baz - Store a page with a different file name

experiment                       today                           Bar(7)

But if you store a page with the name baz.7 or baZ.7 or anything like that, it will have preference always.

[alejandro-colomar]

Don't know if man allows for file names to differ from entries it contains.

I'm not sure if I understand what you say. Can you reword?

Does man 2 _Exit always have to imply _Exit.2 file name? Or is there a way to encode an indirection that would allow having a different file name?

Hmmm. There's a way.

If man(7) cannot find a file with that name (ignoring case), it will try to find a page with that name by looking at the NAME sections of each page.

So you will need to store both pages with dummy file names, such as _exit_lowercase_dummy.2 and _exit_uppercase_dummy.2, and then, it will work.

See an experiment:

alx@debian:~/tmp/man$ ls
foo.7  qwe.7
alx@debian:~/tmp/man$ cat foo.7 
.TH bar 7 today experiment
.SH Name
baz
\-
Store a page with a different file name
alx@debian:~/tmp/man$ cat qwe.7 
.TH Bar 7 today experiment
.SH Name
Baz
\-
Store a page with a different file name
alx@debian:~/tmp/man$ sudo cp * /usr/local/man/man7
alx@debian:~/tmp/man$ sudo mandb >/dev/null
Updating index cache for path `/usr/local/man/man7'. Wait...done.
alx@debian:~/tmp/man$ man 7 bar | cat
No manual entry for bar in section 7
alx@debian:~/tmp/man$ man 7 baz | cat
bar(7)              Miscellaneous Information Manual             bar(7)

Name
     baz - Store a page with a different file name

experiment                       today                           bar(7)
alx@debian:~/tmp/man$ man 7 Baz | cat
Bar(7)              Miscellaneous Information Manual             Bar(7)

Name
     Baz - Store a page with a different file name

experiment                       today                           Bar(7)

But if you store a page with the name baz.7 or baZ.7 or anything like that, it will have preference always.

However, there's a caveat: man _exit.2 or man '_exit(2)' will not work. See in my example:

$ man Baz.7 | cat
No manual entry for Baz.7
$ man 'Baz(7)' | cat
No manual entry for Baz(7)

And with real pages, both syntaxes work:

$ man printf.3 | head -n1
printf(3)               Library Functions Manual              printf(3)
$ man 'printf(3)' | head -n1
printf(3)               Library Functions Manual              printf(3)

[deliciouslytyped]

@trofi @marsam Why does this remove the manpath fix?
https://github.com/NixOS/nixpkgs/pull/300797/files#diff-3ba2ce83a72b6085a66e9971f4b5187c53b36fece5a7720ac968219d1b4657b2L21

I don't know if I'm dong something (else) wrong, but this breaks using nix-shell -p man-pages.

Please fix.

If it's appropriate to fix, it would be good to add the same fix to man-pages-posix and linux-manual as well.

[trofi]

man x25 seems to work as is on NixOS. I'll try to uninstall it systemwide, will check if nix-shell -p needs that bin back and have a look why PATH workaround is important.

[trofi]

Proposed the restored workaround as #308363