[arch-general] What update left mandb scrambled?
This was odd,
$ apropos memcmp memcmp: nothing appropriate.
In fact, no man pages were available (checked 2 arch installs). I ended up having to rebuild the database with 'mandb' and now all is well.
My question is -- what did this? It must have occurred in the last couple of days.
man memcmp is available on my Arch install.
I did not just run "apropos", if I run "man" I get the memcmp manual page.
[rocketmouse@archlinux ~]$ apropos memcmp TIFFmemory (3tiff) - memory management-related functions for use with TIFF files gnutls_memcmp (3) - API function memcmp (3) - compare memory areas memcmp (3p) - compare bytes in memory wmemcmp (3) - compare two arrays of wide-characters wmemcmp (3p) - compare wide characters in memory [rocketmouse@archlinux ~]$ sudo pacman -Syu [snip] :: Starting full system upgrade... warning: fluidsynth: ignoring package upgrade (1.1.11-3 => 2.0.4-1) warning: gvfs: local (2013.08.18-1) is newer than extra (1.38.1+9+gd4dab113-2) warning: ignoring package replacement (hunspell-en-7.1-3 => hunspell-en_AU-2018.04.16-5) warning: ignoring package replacement (hunspell-en-7.1-3 => hunspell-en_CA-2018.04.16-5) warning: ignoring package replacement (hunspell-en-7.1-3 => hunspell-en_GB-2018.04.16-5) warning: ignoring package replacement (hunspell-en-7.1-3 => hunspell-en_US-2018.04.16-5) warning: hunspell-en_US: local (2018:06.29-1) is newer than extra (2018.04.16-5) warning: linux: ignoring package upgrade (4.20.11.arch2-1 => 4.20.12.arch1-1) warning: linux-headers: ignoring package upgrade (4.20.11.arch2-1 => 4.20.12.arch1-1) warning: mate-calc: ignoring package upgrade (1.8.0-2 => 1.20.3-1) warning: pulseaudio: local (2013.08.18-1) is newer than extra (12.2-2) warning: pulseaudio-bluetooth: local (2017.12.19-1) is newer than extra (12.2-2) warning: x42-plugins: ignoring package upgrade (20161230-1 => 20190206-1) resolving dependencies... looking for conflicting packages...
Packages (31) brltty-6.0-1 dpf-plugins-1.1-3 getmail-5.13-1 git-2.21.0-1 glm-0.9.9.3-1 lib32-mesa-18.3.4-1 lib32-vulkan-icd-loader-1.1.101-1 libnfs-4.0.0-3 libnm-1.14.6-1 libnm-glib-1.14.6-1 libssh-0.8.7-1 libxkbcommon-0.8.4-1 libxkbcommon-x11-0.8.4-1 linux-docs-4.20.12.arch1-1 mariadb-10.3.13-1 mariadb-clients-10.3.13-1 mariadb-libs-10.3.13-1 mesa-18.3.4-1 networkmanager-1.14.6-1 projectm-3.1.0-4 python-anytree-2.6.0-2 python-atspi-2.30.0-2 python-markupsafe-1.1.1-1 python2-markupsafe-1.1.1-1 qemu-3.1.0-2 qt5-quickcontrols-5.12.1-2 tar-1.32-1 tracker-2.2.0-3 vlc-3.0.6-4 vulkan-icd-loader-1.1.101-1 xf86-video-intel-1:2.99.917+860+g3a2dec17-1
[snip] [rocketmouse@archlinux ~]$ apropos memcmp TIFFmemory (3tiff) - memory management-related functions for use with TIFF files gnutls_memcmp (3) - API function memcmp (3) - compare memory areas memcmp (3p) - compare bytes in memory wmemcmp (3) - compare two arrays of wide-characters wmemcmp (3p) - compare wide characters in memory [rocketmouse@archlinux ~]$
On Tue, Feb 26, 2019 at 8:57 AM David C. Rankin drankinatty@suddenlinkmail.com wrote:
This was odd,
$ apropos memcmp memcmp: nothing appropriate.
In fact, no man pages were available (checked 2 arch installs). I ended up having to rebuild the database with 'mandb' and now all is well.
My question is -- what did this? It must have occurred in the last couple of days.
After https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/man-... , you have to manualy enable man-db.timer
On Tue, 2019-02-26 at 14:33 +0200, Edvinas Valatka via arch-general wrote:
On Tue, Feb 26, 2019 at 8:57 AM David C. Rankin drankinatty@suddenlinkmail.com wrote:
This was odd,
$ apropos memcmp memcmp: nothing appropriate.
In fact, no man pages were available (checked 2 arch installs). I ended up having to rebuild the database with 'mandb' and now all is well.
My question is -- what did this? It must have occurred in the last couple of days.
After https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/man-... , you have to manualy enable man-db.timer
Seemingly not ;), see
[rocketmouse@archlinux ~]$ systemctl status man-db.service ● man-db.service - Daily man-db regeneration Loaded: loaded (/usr/lib/systemd/system/man-db.service; static; vendor preset: disabled) Active: inactive (dead) Docs: man:mandb(8) [rocketmouse@archlinux ~]$ sudo systemctl enable man-db.service [sudo] password for rocketmouse: The unit files have no installation config (WantedBy=, RequiredBy=, Also=, Alias= settings in the [Install] section, and DefaultInstance= for template units). This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are: • A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. • A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. • A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...). • In case of template units, the unit is meant to be enabled with some instance name specified.
On Tue, 2019-02-26 at 13:43 +0100, Ralf Mardorf wrote:
On Tue, 2019-02-26 at 14:33 +0200, Edvinas Valatka via arch-general wrote:
On Tue, Feb 26, 2019 at 8:57 AM David C. Rankin drankinatty@suddenlinkmail.com wrote:
This was odd,
$ apropos memcmp memcmp: nothing appropriate.
In fact, no man pages were available (checked 2 arch installs). I ended up having to rebuild the database with 'mandb' and now all is well.
My question is -- what did this? It must have occurred in the last couple of days.
After https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/man-... , you have to manualy enable man-db.timer
Seemingly not ;), see
[rocketmouse@archlinux ~]$ systemctl status man-db.service ● man-db.service - Daily man-db regeneration Loaded: loaded (/usr/lib/systemd/system/man-db.service; static; vendor preset: disabled) Active: inactive (dead) Docs: man:mandb(8) [rocketmouse@archlinux ~]$ sudo systemctl enable man-db.service [sudo] password for rocketmouse: The unit files have no installation config (WantedBy=, RequiredBy=, Also=, Alias= settings in the [Install] section, and DefaultInstance= for template units). This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are: • A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. • A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. • A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...). • In case of template units, the unit is meant to be enabled with some instance name specified.
My apologies. it's "timer" not "service" :D.
[rocketmouse@archlinux ~]$ systemctl status man-db.timer ● man-db.timer - Daily man-db regeneration Loaded: loaded (/usr/lib/systemd/system/man-db.timer; disabled; vendor preset: disabled) Active: inactive (dead) Trigger: n/a Docs: man:mandb(8) [rocketmouse@archlinux ~]$ sudo systemctl enable man-db.timer Created symlink /etc/systemd/system/timers.target.wants/man-db.timer → /usr/lib/systemd/system/man-db.timer. [rocketmouse@archlinux ~]$ systemctl status man-db.timer ● man-db.timer - Daily man-db regeneration Loaded: loaded (/usr/lib/systemd/system/man-db.timer; enabled; vendor preset: disabled) Active: inactive (dead) Trigger: n/a Docs: man:mandb(8)
On 02/26/2019 06:33 AM, Edvinas Valatka via arch-general wrote:
After https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/man-... , you have to manualy enable man-db.timer
+# probably not required +# install -d -m755 ${pkgdir}/usr/lib/systemd/system/multi-user.target.wants +# ln -s ../man-db.timer ${pkgdir}//usr/lib/systemd/system/multi-user.target.wants/man-db.timer
That would then seem to be an update that requires user-intervention and have some note listed on https://www.archlinux.org/.
The most recent note under "Latest News" is getting quite stale.
I scan the pacman Upgrade output and don't recall seeing a note there either.
I don't see the logic in not enabling the timer by default. If the man pages are installed, they need to be usable without further user intervention. It would make more sense to have the people that DON'T want to use the man pages disable the timer rather than force everybody who wants working man pages to enable it. Otherwise RTFM means little if they are broken.
On 2/26/19 1:13 PM, David C. Rankin wrote:
On 02/26/2019 06:33 AM, Edvinas Valatka via arch-general wrote:
After https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/man-... , you have to manualy enable man-db.timer
+# probably not required +# install -d -m755 ${pkgdir}/usr/lib/systemd/system/multi-user.target.wants +# ln -s ../man-db.timer ${pkgdir}//usr/lib/systemd/system/multi-user.target.wants/man-db.timer
That would then seem to be an update that requires user-intervention and have some note listed on https://www.archlinux.org/.
The most recent note under "Latest News" is getting quite stale.
I scan the pacman Upgrade output and don't recall seeing a note there either.
I don't see the logic in not enabling the timer by default. If the man pages are installed, they need to be usable without further user intervention. It would make more sense to have the people that DON'T want to use the man pages disable the timer rather than force everybody who wants working man pages to enable it. Otherwise RTFM means little if they are broken.
It is not a news item and it is not a "you have to manually enable basic system functionality", it is a bug report.
Although I have been using Graysky's mandb-ondemand timer for long enough that I guess I did not notice this myself.
Actually ISTR an IRC conversation with another packager, who discovered the same thing and who said he would get in touch with the the mandb maintainer about this.
On Tue, 2019-02-26 at 00:57 -0600, David C. Rankin wrote:
This was odd,
$ apropos memcmp memcmp: nothing appropriate.
In fact, no man pages were available (checked 2 arch installs). I ended up having to rebuild the database with 'mandb' and now all is well.
My question is -- what did this? It must have occurred in the last couple of days.
Hey,
Like Edvinas said you need to enable `man-db.timer`. You can also run `sudo mandb` manually.
https://wiki.archlinux.org/index.php/Man_page#Searching_manuals
Filipe Laíns 3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2
participants (5)
-
David C. Rankin
-
Edvinas Valatka
-
Eli Schwartz
-
Filipe Laíns
-
Ralf Mardorf