Re: Error al instalar man-db en jessie (quizás problema de ext4???)
El Fri, 12 Dec 2014 20:56:00 +0100, José Miguel (sio2) escribió: El Fri, 12 de Dec de 2014, a las 06:05:35PM +, Camaleón dijo: No es una estupidez siempre y cuando lo hagas como prueba para comprobar si el raid 1 funciona como debe o no. Lo que ya no me parece tan normal es que lo tengas de manera constante roto (con un sólo disco), ya que de esa forma estás forzando al sistema a que use ciclos de cpu para que dmraid intente reconstruir continuamente el raid 1 (si tienes configurado el rebuild automático), algo que no puede hacer porque sólo hay un disco. Sólo el concepto me parece hasta macabro :-) No lo tengo roto, quiero decir, que el raid no es un raid de dos discos al que le falta uno: Es un raid constituido por un sólo disco: # cat /proc/mdstat Personalities : [raid1] md0 : active raid1 sda1[0] 5240064 blocks super 1.2 [1/1] [U] unused devices: none He dicho que es estúpido, porque conceptualmente necesitas dos discos. Jo*er. Pues entonces no entiendo el motivo del raid 1, ¿quieres estresar al disco, al kernel, al LVM? ¿Quieres probar los módulos del kernel para el raid? Lo raro es que con un único disco no se queje :-? ¿Por raid enclenque te refieres a un raid por software? No, no... me refiero dmraid (si es que es ese el que usas). Dmraid es un falso raid, el peor de todos los que puedes usar y que resulta únicamente útil si tienes un sistema dual con windows y has habilitado el raid en la bios para windows. No, no es un falso raid (ya he dicho que estoy usando kvm). Vale... Me confundió en mensaje del OOPS: *** Aborting journal on device dm-0-8. EXT4-fs (dm-0): Remounting filesystem read-only *** Ese dm-0 suena a... pues eso, a dm (falso raid) ;-) Por otra parte, el hecho de usar KVM no implica nada, es decir, podrás configurar un raid con dm o con md. ¿Eso se hace con reportbug? No lo he hecho nunca. Hummm, sí, puedes usar reportbug (esta aplicación genera un correo electrónico que se enviará al BTS con todos los datos, la pega que tiene es que debe que ejecutarse/instalarse en el mismo equipo donde has encontrado el bug para que obtenga todas las variables de entorno correctamente) o puedes hacerlo manualmente a través de un correo electrónico con los datos adecuados para que lo reconozca el BTS como informe de fallo: https://www.debian.org/Bugs/Reporting Pues entonces sospecho que no podré usar reportbug, porque al producirse el fallo se me vuelve totalmente inservible la máquina. Por ese motivo no me gusta reportbug, prefiero hacer un informe a mano y enviarlo por e-mail aunque cueste un poco más de tiempo. Por cierto que he probado a usar qemu-nbd para montar el fichero, he ensamblado el raid, cargado el LVM y al actualizar con: # apt-get -o RootDir=/punto/montaje upgrade se ha actualizado sin problemas. Pero dentro del kvm no hay forma. :/ Porque lo que falla es el sistema de archivos ejecutado dentro del volumen de la VM, no del host, aunque tratándose de KVM no sé hasta qué punto están separados host/guest... Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.13.17.45...@gmail.com
Error al instalar man-db en jessie (quizás problema de ext4???)
Un saludo a la lista. Tengo una jessie en una máquina virtual (kvm) para pruebas. Es una jessie limpita después de una instalación que hice hace cosa de un mes. No tiene entorno gráfico. Para instalarla monté un RAID1 (aunque forcé a que sólo hubiera un disco), sobre él un LVM y ya sobre los volúmenes lógicos monté los sistemas de ficheros (/, /home, /var/lib/lxc, /var/lib/mysql, /boot/grub, /srv/www y la swap). Todos están en ext4 excepto el dedicado a lxc que está sobre btrfs. Hoy he ido a cacharrear con ella y que querido actualizar el sistema. Al hacerlo he obtenido errores y se me ha montado el sistema raíz en modo sólo lectura. Mirando cuál era el culpable he visto el error se produce al instalar man-db, incluso aunque decida actualizar sólo man-db: #v+ # aptitude install man-db [...] (Leyendo la base de datos ... 32148 ficheros o directorios instalados actualmente.) Preparing to unpack .../man-db_2.7.0.2-4_amd64.deb ... Unpacking man-db (2.7.0.2-4) over (2.7.0.2-3) ... dpkg: error processing archive /var/cache/apt/archives/man-db_2.7.0.2-4_amd64.deb (--unpack): no se puede hacer «sync» del directorio '/var/lib/dpkg/triggers': Sistema de ficheros de sólo lectura [...] #v- Y luego se siguen escupiendo muchos errores producidos porque el sistema raíz se ha puesto en sólo lectura. He intentado unas cuantas veces la operación a partir de la jessie sin actualizar y siempre ocurre lo mismo. He mirado con dmesg a ver si se ve cuál es el culpable de que el sistema pase a sólo lectura y he visto lo siguiente: #v+ [...] [ 120.039299] EXT4-fs error (device dm-0): ext4_mb_generate_buddy:757: group 4, block bitmap and bg descriptor inconsistent: 2 vs 0 free clusters [ 120.040757] Aborting journal on device dm-0-8. [ 120.041690] EXT4-fs (dm-0): Remounting filesystem read-only [ 120.042380] [ cut here ] [ 120.042413] WARNING: CPU: 0 PID: 948 at /build/linux-Y9HjRe/linux-3.16.7/fs/ext4/ext4_jbd2.c:260 __ext4_handle_dirty_metadata+0x18e/0x1d0 [ext4]() [ 120.042415] Modules linked in: nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc ppdev vmwgfx ttm drm_kms_helper drm evdev pcspkr psmous e serio_raw snd_intel8x0 snd_ac97_codec processor parport_pc parport pvpanic thermal_sys snd_pcm snd_timer i2c_piix4 snd soundcore ac97_bus i2c_core but ton autofs4 ext4 crc16 mbcache jbd2 crc32c_generic btrfs xor raid6_pq dm_mod raid1 md_mod sg sd_mod crc_t10dif crct10dif_generic crct10dif_common sr_mod cdrom ata_generic virtio_net ata_piix uhci_hcd ehci_hcd floppy libata virtio_pci virtio_ring virtio usbcore usb_common scsi_mod [ 120.042453] CPU: 0 PID: 948 Comm: dpkg Not tainted 3.16.0-4-amd64 #1 Debian 3.16.7-2 [ 120.042455] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014 [ 120.042457] 0009 81506b43 81065717 [ 120.042460] 88001cfc6c58 ffe2 88001c41a328 [ 120.042462] a0308de0 a02e961e 88001c09dc80 88001ec35800 [ 120.042465] Call Trace: [ 120.042472] [81506b43] ? dump_stack+0x41/0x51 [ 120.042476] [81065717] ? warn_slowpath_common+0x77/0x90 [ 120.042485] [a02e961e] ? __ext4_handle_dirty_metadata+0x18e/0x1d0 [ext4] [ 120.042493] [a02c3235] ? ext4_dirty_inode+0x25/0x60 [ext4] [ 120.042502] [a02f1c17] ? ext4_free_blocks+0x5e7/0xb90 [ext4] [ 120.042511] [a02e4d14] ? ext4_ext_remove_space+0x804/0x1080 [ext4] [ 120.042519] [a02e7558] ? ext4_ext_truncate+0x98/0xc0 [ext4] [ 120.042527] [a02c16d1] ? ext4_truncate+0x391/0x3e0 [ext4] [ 120.042535] [a02c2249] ? ext4_evict_inode+0x459/0x4b0 [ext4] [ 120.042539] [811bf0ec] ? evict+0xac/0x170 [ 120.042542] [811baf28] ? __dentry_kill+0x188/0x1f0 [ 120.042544] [811bb02e] ? dput+0x9e/0x170 [ 120.042548] [811b3118] ? SYSC_renameat2+0x498/0x530 [ 120.042552] [8116ca25] ? vm_munmap+0x45/0x50 [ 120.042556] [8150cc2d] ? system_call_fast_compare_end+0x10/0x15 [ 120.042558] ---[ end trace c529a23b4e86a4ed ]--- [ 120.042560] EXT4: jbd2_journal_dirty_metadata failed: handle type 5 started at line 244, credits 29/29, errcode -30 [ 120.043431] EXT4: jbd2_journal_dirty_metadata failed: handle type 5 started at line 244, credits 29/29, errcode -30 [ 120.044841] EXT4-fs error (device dm-0) in ext4_free_blocks:4901: Journal has aborted [...] #v- Parece un problema de ext4 más que de man-db, pero no alcanzo a entender mucho. He mirado por internet y sólo he visto este enlace que pueda que tenga que ver (aunque hace referencia al kernel 3.17) http://patchwork.ozlabs.org/patch/390765/ ¿Alguien sabe algo al respecto? No sé muy bien cómo buscar en bugs.debian.org si es un bug o no. De hecho, no me atreve a actualizar mi sistema real, no me vaya a ocurrir algo parecido (he visto que man-db está pendiente de actualización). Un saludo
Re: Error al instalar man-db en jessie (quizás problema de ext4???)
El Fri, 12 Dec 2014 17:59:08 +0100, José Miguel (sio2) escribió: (...) Para instalarla monté un RAID1 (aunque forcé a que sólo hubiera un disco), sobre él un LVM y ya sobre los volúmenes lógicos monté los sistemas de ficheros (/, /home, /var/lib/lxc, /var/lib/mysql, /boot/grub, /srv/www y la swap). Todos están en ext4 excepto el dedicado a lxc que está sobre btrfs. (...) Hoy he ido a cacharrear con ella y que querido actualizar el sistema. Al hacerlo he obtenido errores y se me ha montado el sistema raíz en modo sólo lectura. Mirando cuál era el culpable he visto el error se produce al instalar man-db, incluso aunque decida actualizar sólo man-db: (...) Y luego se siguen escupiendo muchos errores producidos porque el sistema raíz se ha puesto en sólo lectura. He intentado unas cuantas veces la operación a partir de la jessie sin actualizar y siempre ocurre lo mismo. He mirado con dmesg a ver si se ve cuál es el culpable de que el sistema pase a sólo lectura y he visto lo siguiente: (...) #v+ [...] [ 120.039299] EXT4-fs error (device dm-0): ext4_mb_generate_buddy:757: group 4, block bitmap and bg descriptor inconsistent: 2 vs 0 free clusters [ 120.040757] Aborting journal on device dm-0-8. [ 120.041690] EXT4-fs (dm-0): Remounting filesystem read-only (...) [ 120.042560] EXT4: jbd2_journal_dirty_metadata failed: handle type 5 started at line 244, credits 29/29, errcode -30 [ 120.043431] EXT4: jbd2_journal_dirty_metadata failed: handle type 5 started at line 244, credits 29/29, errcode -30 [ 120.044841] EXT4-fs error (device dm-0) in ext4_free_blocks:4901: Journal has aborted [...] #v- Parece un problema de ext4 más que de man-db, pero no alcanzo a entender mucho. He mirado por internet y sólo he visto este enlace que pueda que tenga que ver (aunque hace referencia al kernel 3.17) http://patchwork.ozlabs.org/patch/390765/ ¿Alguien sabe algo al respecto? No sé muy bien cómo buscar en bugs.debian.org si es un bug o no. De hecho, no me atreve a actualizar mi sistema real, no me vaya a ocurrir algo parecido (he visto que man-db está pendiente de actualización). Yo interpreto lo siguiente: se te ha caído el raid 1 (por el motivo que sea, primer problema a analizar, es decir, comprobar si realmente el raid está caído o se debe a su estado forzado a un sólo disco ¿?) y el sistema se ha puesto en modo de sólo lectura por lo que no vas a poder realizar operaciones que escriban a disco. Después, tienes un kernel oops (segundo problema a analizar) como una casa que te dice algo relacionado con los metadatos y el journal. Partiendo de la base de que me gusta nada la combinación de dm-raid (raid enclenque) con LVM es posible que la caída del volumen (o el fallo en el sistema de archivos) lo provoque el kernel oops por lo que podría ser un bug del que convendría que informaras en Debian (si lo haces incluye el enlace al parche que indicas arriba). Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.12.17.19...@gmail.com
Re: Error al instalar man-db en jessie (quizás problema de ext4???)
El Fri, 12 de Dec de 2014, a las 05:19:40PM +, Camaleón dijo: Yo interpreto lo siguiente: se te ha caído el raid 1 (por el motivo que sea, primer problema a analizar, es decir, comprobar si realmente el raid está caído o se debe a su estado forzado a un sólo disco ¿?) Hay una explicación para esta aparente estupidez: es una máquina virtual de pruebas que en el futuro quizás monte en un sistema real. mientras no está en una máquina virtual prefiero solamente tratar con un disco (fichero) en vez de con dos. De todos modos probaré a añadirle el segundo disco y ver si sigue fallando. Partiendo de la base de que me gusta nada la combinación de dm-raid (raid enclenque) con LVM ¿Por raid enclenque te refieres a un raid por software? ¿Cuál es la alternativa sin usar un raid por hardware? Yo la única que conozco es btrfs, pero aún es pronto para ponerlo en producción. Además, btrfs no soporta cuotas por usuario, y en /srv las necesitaría (en /home me puedo apañar con las cuotas por subvolumen) es posible que la caída del volumen (o el fallo en el sistema de archivos) lo provoque el kernel oops por lo que podría ser un bug del que convendría que informaras en Debian (si lo haces incluye el enlace al parche que indicas arriba). ¿Eso se hace con reportbug? No lo he hecho nunca. Saludos, Saludos y gracias. -- Flérida para mí dulce y sabrosa, más que la fruta de cercado ajeno. --- Garcilaso de la Vega --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141212174724.ga1...@cubo.casa
Re: Error al instalar man-db en jessie (quizás problema de ext4???)
El Fri, 12 Dec 2014 18:47:25 +0100, José Miguel (sio2) escribió: El Fri, 12 de Dec de 2014, a las 05:19:40PM +, Camaleón dijo: Yo interpreto lo siguiente: se te ha caído el raid 1 (por el motivo que sea, primer problema a analizar, es decir, comprobar si realmente el raid está caído o se debe a su estado forzado a un sólo disco ¿?) Hay una explicación para esta aparente estupidez: es una máquina virtual de pruebas que en el futuro quizás monte en un sistema real. mientras no está en una máquina virtual prefiero solamente tratar con un disco (fichero) en vez de con dos. De todos modos probaré a añadirle el segundo disco y ver si sigue fallando. No es una estupidez siempre y cuando lo hagas como prueba para comprobar si el raid 1 funciona como debe o no. Lo que ya no me parece tan normal es que lo tengas de manera constante roto (con un sólo disco), ya que de esa forma estás forzando al sistema a que use ciclos de cpu para que dmraid intente reconstruir continuamente el raid 1 (si tienes configurado el rebuild automático), algo que no puede hacer porque sólo hay un disco. Sólo el concepto me parece hasta macabro :-) Partiendo de la base de que me gusta nada la combinación de dm-raid (raid enclenque) con LVM ¿Por raid enclenque te refieres a un raid por software? No, no... me refiero dmraid (si es que es ese el que usas). Dmraid es un falso raid, el peor de todos los que puedes usar y que resulta únicamente útil si tienes un sistema dual con windows y has habilitado el raid en la bios para windows. Para todo lo demás, Master Car... estooo, md que es el softare raid nativo de linux, probado, verificado y libre como los pajaritos :-) ¿Cuál es la alternativa sin usar un raid por hardware? Yo la única que conozco es btrfs, pero aún es pronto para ponerlo en producción. Además, btrfs no soporta cuotas por usuario, y en /srv las necesitaría (en /home me puedo apañar con las cuotas por subvolumen) Para linux, mdraid es la opción más segura y fiable (sin contar un raid por hardware, claro). es posible que la caída del volumen (o el fallo en el sistema de archivos) lo provoque el kernel oops por lo que podría ser un bug del que convendría que informaras en Debian (si lo haces incluye el enlace al parche que indicas arriba). ¿Eso se hace con reportbug? No lo he hecho nunca. Hummm, sí, puedes usar reportbug (esta aplicación genera un correo electrónico que se enviará al BTS con todos los datos, la pega que tiene es que debe que ejecutarse/instalarse en el mismo equipo donde has encontrado el bug para que obtenga todas las variables de entorno correctamente) o puedes hacerlo manualmente a través de un correo electrónico con los datos adecuados para que lo reconozca el BTS como informe de fallo: https://www.debian.org/Bugs/Reporting Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.12.18.05...@gmail.com
Re: Error al instalar man-db en jessie (quizás problema de ext4???)
El Fri, 12 de Dec de 2014, a las 06:05:35PM +, Camaleón dijo: No es una estupidez siempre y cuando lo hagas como prueba para comprobar si el raid 1 funciona como debe o no. Lo que ya no me parece tan normal es que lo tengas de manera constante roto (con un sólo disco), ya que de esa forma estás forzando al sistema a que use ciclos de cpu para que dmraid intente reconstruir continuamente el raid 1 (si tienes configurado el rebuild automático), algo que no puede hacer porque sólo hay un disco. Sólo el concepto me parece hasta macabro :-) No lo tengo roto, quiero decir, que el raid no es un raid de dos discos al que le falta uno: Es un raid constituido por un sólo disco: # cat /proc/mdstat Personalities : [raid1] md0 : active raid1 sda1[0] 5240064 blocks super 1.2 [1/1] [U] unused devices: none He dicho que es estúpido, porque conceptualmente necesitas dos discos. ¿Por raid enclenque te refieres a un raid por software? No, no... me refiero dmraid (si es que es ese el que usas). Dmraid es un falso raid, el peor de todos los que puedes usar y que resulta únicamente útil si tienes un sistema dual con windows y has habilitado el raid en la bios para windows. No, no es un falso raid (ya he dicho que estoy usando kvm). Para todo lo demás, Master Car... estooo, md que es el softare raid nativo de linux, probado, verificado y libre como los pajaritos :-) Pues eso. ¿Eso se hace con reportbug? No lo he hecho nunca. Hummm, sí, puedes usar reportbug (esta aplicación genera un correo electrónico que se enviará al BTS con todos los datos, la pega que tiene es que debe que ejecutarse/instalarse en el mismo equipo donde has encontrado el bug para que obtenga todas las variables de entorno correctamente) o puedes hacerlo manualmente a través de un correo electrónico con los datos adecuados para que lo reconozca el BTS como informe de fallo: https://www.debian.org/Bugs/Reporting Saludos, Pues entonces sospecho que no podré usar reportbug, porque al producirse el fallo se me vuelve totalmente inservible la máquina. Por cierto que he probado a usar qemu-nbd para montar el fichero, he ensamblado el raid, cargado el LVM y al actualizar con: # apt-get -o RootDir=/punto/montaje upgrade se ha actualizado sin problemas. Pero dentro del kvm no hay forma. :/ Saludos. -- El más seguro bien de la fortuna es no haber tenido vez alguna. --- Alonso de Ercilla --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141212195600.ga17...@cubo.casa
Re: Le paquet Git installé me crée des erreurs via man-db.
Le 24 janvier 2009 02:40, Thomas Preud'homme thomas.preudho...@celest.fr a écrit : Alors moi je suis pas contrariant et je vérifie ce qu'on me dit : # file /usr/share/man/man1/git.1.gz /usr/share/man/man1/git.1.gz: broken symbolic link to `/etc/alternatives/git.1.gz' Il est possible qu'il ait existé plusieurs alternatives pour git à une époque et que maintenant git n'utilise plus d'alternative. Le mieux pour s'en assurer serait de purger puis réinstaller le paquet. Si tu ne veux rien supprimer alors fait un ln -s /usr/share/man/man1/git.transition.1.gz /etc/alternatives/git.1.gz Effectivement, Il existait une alternative : voici le message que j'avais noté au moment de l'installation : [---] Il y a 2 alternatives fournissant « git ». SélectionAlternative --- *+1/usr/bin/git.transition 2/usr/bin/git-scm Appuyez sur Entrée pour conserver la valeur par défaut[*] ou choisissez le numéro sélectionné :2 Utilisation de « /usr/bin/git-scm » pour fournir « git ». [---] (Oui je note tout lol) tu peux remplacer git.transition.1.gz par n'importe lequel des fichier (qui n'est pas un lien symbolique) git*.1.gz se trouvant dans /usr/share/man/man1 * représentant n'importe quoi Je vais essayer ça. Le paquet git concerné avait le nom suivant : git_4.3.20-10_i386.deb, le paquet n'a pas été mis a jour à ma connaissance. J'ai regardé le contenu du paquet : # dpkg-deb --contents /var/cache/apt/archives/git_4.3.20-10_i386.deb et dedans aucun lien symbolique à ce nom ... J'ai aussi vérifié les paquet git-core et cogito que j'avais installé le même jour et rien non plus. Les liens symboliques pour les alternatives sont gérés par les scripts d'installations des paquets Debian. En fait je me demande même si la Debian policy autorise un lien symbolique a être mis dans un paquet Debian Apparemment oui puisque les paquets Debian en contienne, exemple sur le paquet git : [---] $ dpkg-deb --contents git_4.3.20-10_i386.deb ... lrwxrwxrwx root/root 0 2006-08-21 11:17 ./usr/share/man/man1/gitrfgrep.1.gz - gitrgrep.1.gz ... [---] En revanche, il est possible que le nettoyage puisse être mal fait : en effet à ma première installation de git, j'ai installé le paquet git.transition qui était par défaut puis je l'ai enlevé pour mettre git-scm qui correspondait plutôt à ce que je voulais. C'est à ce moment que le lien n'a pas du être supprimé. Merci pour tes explications. Kévin -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to debian-user-french-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Le paquet Git installé me crée des erreurs via man-db.
The Wednesday 21 January 2009 10:06:05 Kevin Hinault, you wrote : Bonjour, Je viens avec un sujet qui me gène depuis quelques temps sur ma Debian Etch : j'ai installé il y a quelques mois le paquet git via apt-get et depuis à chaque nouveau paquet que j'installes, j'ai le lendemain un mail de man-db qui détecte une erreur : /etc/cron.daily/man-db: mandb: attention: /usr/share/man/man1/git.1.gz est un lien symbolique flottant Alors moi je suis pas contrariant et je vérifie ce qu'on me dit : # file /usr/share/man/man1/git.1.gz /usr/share/man/man1/git.1.gz: broken symbolic link to `/etc/alternatives/git.1.gz' Il est possible qu'il ait existé plusieurs alternatives pour git à une époque et que maintenant git n'utilise plus d'alternative. Le mieux pour s'en assurer serait de purger puis réinstaller le paquet. Si tu ne veux rien supprimer alors fait un ln -s /usr/share/man/man1/git.transition.1.gz /etc/alternatives/git.1.gz tu peux remplacer git.transition.1.gz par n'importe lequel des fichier (qui n'est pas un lien symbolique) git*.1.gz se trouvant dans /usr/share/man/man1 * représentant n'importe quoi Voila l'explication : mon lien est cassé puisque /etc/alternatives/git.1.gz n'existes pas chez moi ... Bien sûr, je pourrais le supprimer et ignorer l'erreur mais ça m'embête. Je considère apt et dpkg comme de bons outils travaillant bien et installant tout bien comme il faut là où il faut aussi je suppose une erreur dans le paquet git non ? C'est possible. J'ai déjà eu plusieurs fois des soucis d'alternatives. Notament sur java, et j'ai dû réparer les mains à la main puisque si une seule alternative existe sur un système, la commande update-alternative ne veut pas recréer le lien symbolique même si celui-ci ne pointe pas sur l'alternative existante. En gros j'avais /etc/alternatives/javac qui pointait vers un programme javac inexistant (du moins pas à cet endroit) et quand je disais à update-alternative de configurer l'alternative pour javac il me disait qu'une seule alternative était dispo et ne corrigeait pas le lien cassé. Le paquet git concerné avait le nom suivant : git_4.3.20-10_i386.deb, le paquet n'a pas été mis a jour à ma connaissance. J'ai regardé le contenu du paquet : # dpkg-deb --contents /var/cache/apt/archives/git_4.3.20-10_i386.deb et dedans aucun lien symbolique à ce nom ... J'ai aussi vérifié les paquet git-core et cogito que j'avais installé le même jour et rien non plus. Les liens symboliques pour les alternatives sont gérés par les scripts d'installations des paquets Debian. En fait je me demande même si la Debian policy autorise un lien symbolique a être mis dans un paquet Debian Quelqu'un à des idées autres que de supprimer le lien ? (Je n'aime pas ignorer des erreurs :p) Cf ci-dessus. Kévin Cordialement, Thomas Preud'homme Cordialement, Thomas Preud'homme -- Why debian : http://www.debian.org/intro/why_debian signature.asc Description: This is a digitally signed message part.
Le paquet Git installé me crée des erreurs via man -db.
Bonjour, Je viens avec un sujet qui me gène depuis quelques temps sur ma Debian Etch : j'ai installé il y a quelques mois le paquet git via apt-get et depuis à chaque nouveau paquet que j'installes, j'ai le lendemain un mail de man-db qui détecte une erreur : /etc/cron.daily/man-db: mandb: attention: /usr/share/man/man1/git.1.gz est un lien symbolique flottant Alors moi je suis pas contrariant et je vérifie ce qu'on me dit : # file /usr/share/man/man1/git.1.gz /usr/share/man/man1/git.1.gz: broken symbolic link to `/etc/alternatives/git.1.gz' Voila l'explication : mon lien est cassé puisque /etc/alternatives/git.1.gz n'existes pas chez moi ... Bien sûr, je pourrais le supprimer et ignorer l'erreur mais ça m'embête. Je considère apt et dpkg comme de bons outils travaillant bien et installant tout bien comme il faut là où il faut aussi je suppose une erreur dans le paquet git non ? Le paquet git concerné avait le nom suivant : git_4.3.20-10_i386.deb, le paquet n'a pas été mis a jour à ma connaissance. J'ai regardé le contenu du paquet : # dpkg-deb --contents /var/cache/apt/archives/git_4.3.20-10_i386.deb et dedans aucun lien symbolique à ce nom ... J'ai aussi vérifié les paquet git-core et cogito que j'avais installé le même jour et rien non plus. Quelqu'un à des idées autres que de supprimer le lien ? (Je n'aime pas ignorer des erreurs :p) Kévin -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to debian-user-french-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: /etc/cron.daily/man-db: /var/cache/man: Permission denied
I think it's a problem with the way exim is configured. Exim is mailing the report locally. So that's why we couldn't find anything about cron-daily, man-db, or file permissions ! I can see the same error on two freshly installed Debian unstable boxes, with completely different archs and settings. I need to track it further, just wnated to drop a note to the archives. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=209185 keep it rolling micha -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /etc/cron.daily/man-db: /var/cache/man: Permission denied
| Thanks for your suggestion, i'll report if it worked. No, sorry, even with /var mounted 'suid' i got still the same error mail... /etc/cron.daily/man-db: find: /var/cache/man: Permission denied -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
/etc/cron.daily/man-db: /var/cache/man: Permission denied
(Please first cc to me, if i got a reply i will switch to reading the archive) Hello, This is Debian Sid, and since a few months i got this error message (sent via local mail): /etc/cron.daily/man-db: find: /var/cache/man: Permission denied and i just can't come up with any explanation. Perhaps somone can give me a hint ? This is what i can find so far: /var is mounted as: /dev/hda10 on /var type ext2 (rw,nosuid,nodev,errors=remount-ro) The permissions are: drwxr-xr-t 17 root root 4.0K 2006-04-02 03:00 /var drwxrwxr-x 26 root root 4.0K 2006-08-12 20:49 /var/cache/ drwxr-sr-x 16 man root 4.0K 2006-08-18 00:06 /var/cache/man The last one contains: drwxr-sr-x 2 man root 4.0K 2004-05-25 02:03 cat1 drwxr-sr-x 2 man root 4.0K 2004-05-15 16:49 cat2 drwxr-sr-x 2 man root 4.0K 2004-05-15 16:49 cat3 drwxr-sr-x 2 man root 4.0K 2004-02-02 10:48 cat4 drwxr-sr-x 2 man root 4.0K 2004-05-24 02:25 cat5 drwxr-sr-x 2 man root 4.0K 2003-07-23 02:36 cat6 drwxr-sr-x 2 man root 4.0K 2004-03-11 07:47 cat7 drwxr-sr-x 2 man root 4.0K 2004-05-25 02:03 cat8 drwxr-sr-x 2 man root 4.0K 2004-05-17 04:07 cat9 drwxr-sr-x 3 man root 4.0K 2006-08-18 00:06 fsstnd -rw-r--r-- 1 man root 2.0M 2006-08-16 00:15 index.db drwxr-sr-x 3 man root 4.0K 2006-08-18 00:06 local drwxr-sr-x 3 man root 4.0K 2006-08-18 00:06 oldlocal drwxr-sr-x 2 man root 4.0K 2002-03-18 13:08 opt drwxr-sr-x 7 man root 4.0K 2006-05-07 15:58 X11R6 None of the subdirectories of /var/cache/man contains any file, (besides some index.db ). Apparently, manpages are stored in /usr/hsare/man, instead, but that has drwxr-xr-x 34 root root 4.0K 2006-05-28 13:00 man/ on all levels. - Which seems a little bit weird to me; but /var/cache/man seems to have been installed by package man-db, too. I can see man-db 2.4.3-3 and manpages 2.34-1 are installed. Well, maybe that's not actually Sid but 'testing' since i downgraded the sources list to 'testing' some week ago, but it will last some more weeks until a full turnover, and the error message was sent afterwards and all the time anyway. The cron.daily script will re-create a missing /var/cache/man with exactly the existing permissions: if ! [ -d /var/cache/man ]; then # Recover from deletion, per FHS. mkdir -p /var/cache/man chown man:root /var/cache/man chmod 2755 /var/cache/man and /etc/crontab has all cron scripts running as root. Maybe this here is the bit of the script which leads to the error ? start-stop-daemon --start --pidfile /dev/null --startas /bin/sh \ --oknodo --chuid man -- -c \ find /var/cache/man -type f -name '*.gz' -atime +6 -print0 | \ xargs -r0 rm -f I have lrwxrwxrwx 1 root root 4 2006-07-24 18:21 /bin/sh - bash* The 'man' command is aliased for 'root' by a function here (invoking pinfo) but i assume system calls it always by full path: lrwxrwxrwx 1 root root 17 2006-08-12 20:50 /usr/bin/man - ../lib/man-db/man -rwxr-xr-x 1 root root 85K 2005-09-21 14:23 /usr/lib/man-db/man So...what ? ° /\/
Re: /etc/cron.daily/man-db: /var/cache/man: Permission denied
On Fri, 18 Aug 2006 03:16:08 +0200 Micha [EMAIL PROTECTED] wrote: /etc/cron.daily/man-db: find: /var/cache/man: Permission denied Cron likely runs with no (or low level) permissions. /var is mounted as: /dev/hda10 on /var type ext2 (rw,nosuid,nodev,errors=remount-ro) Hmm. nosuid on mounts may just not honor the set user id for executables. On the other hand, the manual page tells me that nosuid makes it ignore suid bits. (see man mount). So, semantically, those permissions are just rwxr-x-r-x, and even if yuur user is in the 'root' group, he cannot view the directory contents (because 'x' in a directory means permission to enter view the contents). First, try mounting /var without the nosuid part. The permissions are: drwxr-xr-t 17 root root 4.0K 2006-04-02 03:00 /var drwxrwxr-x 26 root root 4.0K 2006-08-12 20:49 /var/cache/ drwxr-sr-x 16 man root 4.0K 2006-08-18 00:06 /var/cache/man OK, that's the same permissions that are set on my 'etch' box. And, even though 'dfox' is not a member of the root or man groups, user dfox (that's me) can run 'find man' in /var/cache/, which lists all subdirectories underneath man, or find . inside man, which lists a number of directories where local man pages are kept (that's what the directory is for, by the way). Even so, the permisions would seem correct (the third r-x is other, and since I am not a man :) or a root, I am an other, and this is all good, because I can view files (-r) or go into the directorty (-x) but an unable to write anything therein. drwxr-xr-x 34 root root 4.0K 2006-05-28 13:00 man/ on all levels. - Which seems a little bit weird to me; but /var/cache/man seems to have been installed by package man-db, too. All my man directories (under /var/cache/man) are set like: drwxr-sr-x 2 man root 48 2005-11-12 05:24 cat1 drwxr-sr-x 2 man root 48 2005-11-12 05:24 cat2 drwxr-sr-x 2 man root 48 2005-11-12 05:24 cat3 drwxr-sr-x 2 man root 48 2005-11-12 05:24 cat4 drwxr-sr-x 2 man root 48 2006-05-07 06:30 cat5 I don't see that the system is working, for one - see the dates on those directories? The way this ought to work (and I thought it did) was for example, a hypothetical user looks at a frequently used man page (like man ls). Since it takes more time to process the man page than display it, a local copy is in /var/cache/man/appropriate sect4ion (in this case, cat1) for later perusal. Man would see that a processed page was in the appropriate place, and display it. After a time, the old entries in those cache directories would be deleted. But, I have 0 bytes in all directories, and an overall usage of 1464K, because of a large index.db. (That file was changed 2 days ago.) -- David E. Fox Thanks for letting me [EMAIL PROTECTED]change magnetic patterns [EMAIL PROTECTED] on your hard disk. --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /etc/cron.daily/man-db: /var/cache/man: Permission denied
David E. Fox [EMAIL PROTECTED]: | Hmm. nosuid on mounts may just not honor the set user id for | executables. On the other hand, the manual page tells me that nosuid | makes it ignore suid bits. (see man mount). So, semantically, those | permissions are just rwxr-x-r-x, and even if yuur user is in the 'root' | group, he cannot view the directory contents (because 'x' in a | directory means permission to enter view the contents). I see, some years ago I configured /var in fstab like: /dev/hda10 /var ext2 owner,exec,errors=remount-ro and though i knew i din't think too much about that 'owner' implies nosuid. | First, try mounting /var without the nosuid part. (How do i trigger a normal cron man-db run ?) ... I'll see tomorrow. | The way this ought to work (and I thought it did) was for example, | a hypothetical user looks at a frequently used man page I seem to remember in the past one got asked at installation time if manpages should be cached that way, or not, and i used to asnwer yes. But AFAIKR there wasn't such a question at the last etch install i did (few days agao). Maybe they ditched it altogether. Thanks for your suggestion, i'll report if it worked. micha ° /\/
cron.daily/man-db problems
Get a whole series of messages like: mandb: warning: /usr/share/man/man1/xtrapinfo.1x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory I tried recreating the db, still happens. How to fix? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cron.daily/man-db problems
On Tue, May 16, 2006 at 10:22:39 +0300, David Baron wrote: Get a whole series of messages like: mandb: warning: /usr/share/man/man1/xtrapinfo.1x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory I tried recreating the db, still happens. How to fix? The problem is that a number of manpages still contain symlinks which assume the old(er) directory structure. You would have to change them yourself, for example /usr/share/man/man1/xtrapinfo.1x.gz is only one line: .so man1x/xtrap.1x This line should be: .so man1/xtrap.1x You can also just wait; the bug is known and it will probably be fixed soon. (I can't seem to connect to bugs.debian.org right now, therefore I cannot provide a link. xbase-clients should be the relevant package.) -- Regards, Florian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cron.daily/man-db problems
On Tuesday 16 May 2006 11:48, Florian Kulzer wrote: On Tue, May 16, 2006 at 10:22:39 +0300, David Baron wrote: Get a whole series of messages like: mandb: warning: /usr/share/man/man1/xtrapinfo.1x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory I tried recreating the db, still happens. How to fix? The problem is that a number of manpages still contain symlinks which assume the old(er) directory structure. You would have to change them yourself, for example /usr/share/man/man1/xtrapinfo.1x.gz is only one line: .so man1x/xtrap.1x This line should be: .so man1/xtrap.1x You can also just wait; the bug is known and it will probably be fixed soon. (I can't seem to connect to bugs.debian.org right now, therefore I cannot provide a link. xbase-clients should be the relevant package.) So ... how about ln -s man1 man1x in the /usr/share/man directory.?? Looking for a man3x as well :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cron.daily/man-db problems
On Tue, May 16, 2006 at 12:00:15 +0300, David Baron wrote: On Tuesday 16 May 2006 11:48, Florian Kulzer wrote: On Tue, May 16, 2006 at 10:22:39 +0300, David Baron wrote: Get a whole series of messages like: mandb: warning: /usr/share/man/man1/xtrapinfo.1x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory I tried recreating the db, still happens. How to fix? The problem is that a number of manpages still contain symlinks which assume the old(er) directory structure. You would have to change them yourself, for example /usr/share/man/man1/xtrapinfo.1x.gz is only one line: .so man1x/xtrap.1x This line should be: .so man1/xtrap.1x You can also just wait; the bug is known and it will probably be fixed soon. (I can't seem to connect to bugs.debian.org right now, therefore I cannot provide a link. xbase-clients should be the relevant package.) So ... how about ln -s man1 man1x in the /usr/share/man directory.?? Looking for a man3x as well :-) That is probably the quickest workaround. I am always a bit hesitant to mess around in the system directories, but since /usr/share/man/man1x does not seem to exist anymore it should be safe enough. -- Regards, Florian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
man-db confused by X man page relocation
I use a PC with a AMD Athlon64 3500+ chip and up-to-date Debian unstable i386 port. Each day I get an email from cron that says: /etc/cron.daily/man-db: mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory mandb: warning: /usr/share/man/man1/xtrapinfo.1x.gz: bad symlink or ROFF .so' request mandb: can't open /usr/share/man/man1x/bitmap.1x: No such file or directory mandb: warning: /usr/share/man/man1/bmtoa.1x.gz: bad symlink or ROFF .so' request mandb: can't open /usr/share/man/man1x/bitmap.1x: No such file or directory mandb: warning: /usr/share/man/man1/atobm.1x.gz: bad symlink or ROFF .so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory mandb: warning: /usr/share/man/man1/xtrapin.1x.gz: bad symlink or ROFF .so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory mandb: warning: /usr/share/man/man1/xtrapproto.1x.gz: bad symlink or ROFF .so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory These manpages have been relocated from /usr/share/man/man1x to /usr/share/man/man1. For example the xtrap man page is now at /usr/share/man/man1/xtrap.1x.gz. This is clearly a bug. But I don't have a clue which package the bug belongs with. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: man-db confused by X man page relocation
Edward C. Jones [EMAIL PROTECTED] wrote: I use a PC with a AMD Athlon64 3500+ chip and up-to-date Debian unstable i386 port. Each day I get an email from cron that says: /etc/cron.daily/man-db: mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory mandb: warning: /usr/share/man/man1/xtrapinfo.1x.gz: bad symlink or ROFF .so' request mandb: can't open /usr/share/man/man1x/bitmap.1x: No such file or directory mandb: warning: /usr/share/man/man1/bmtoa.1x.gz: bad symlink or ROFF .so' request mandb: can't open /usr/share/man/man1x/bitmap.1x: No such file or directory mandb: warning: /usr/share/man/man1/atobm.1x.gz: bad symlink or ROFF .so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory mandb: warning: /usr/share/man/man1/xtrapin.1x.gz: bad symlink or ROFF .so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory mandb: warning: /usr/share/man/man1/xtrapproto.1x.gz: bad symlink or ROFF .so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory These manpages have been relocated from /usr/share/man/man1x to /usr/share/man/man1. For example the xtrap man page is now at /usr/share/man/man1/xtrap.1x.gz. This is clearly a bug. But I don't have a clue which package the bug belongs with. AFAIK the package is xbase-clients and the bug is already reported Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Man-DB is crazy
Kevin B. McCarty wrote: Please CC replies to me as I'm not subscribed. Once a day I get the following email message from the man-db cron job: /etc/cron.daily/man-db: mandb: warning: /usr/share/man/man1/x-terminal-emulator.1.gz is a dangling symlink This in spite of all the evidence: It would be a lot easier to use the -L option and do it in one command. ls -lL /usr/share/man/man1/x-terminal-emulator.1.gz -rw-r--r-- 1 root root 1369 2005-03-10 14:55 /usr/share/man/man1/x-terminal-emulator.1.gz Anyone have any idea what man-db's problem is and how to fix it? In spite of your evidence to the contrary I believe that the link in question must really be dangling. I just can't believe otherwise because of the series of symlinks. I feel certain there was a mistake in there somewhere. Bob signature.asc Description: Digital signature
Re: Man-DB is crazy
Bob Proulx wrote: Kevin B. McCarty wrote: Once a day I get the following email message from the man-db cron job: /etc/cron.daily/man-db: mandb: warning: /usr/share/man/man1/x-terminal-emulator.1.gz is a dangling symlink It would be a lot easier to use the -L option and do it in one command. ls -lL /usr/share/man/man1/x-terminal-emulator.1.gz -rw-r--r-- 1 root root 1369 2005-03-10 14:55 /usr/share/man/man1/x-terminal-emulator.1.gz Thanks, that's a useful option to ls! I learn something every day :-) In spite of your evidence to the contrary I believe that the link in question must really be dangling. I just can't believe otherwise because of the series of symlinks. I feel certain there was a mistake in there somewhere. Unfortunately I get the exact same thing you did: benjo[3]:~% ls -lL /usr/share/man/man1/x-terminal-emulator.1.gz -rw-r--r-- 1 root root 1369 2005-03-10 16:55 /usr/share/man/man1/x-terminal-emulator.1.gz (I take it you're using gnome-terminal too.) So I'm still not convinced of man-db's sanity. Although I didn't get such an error message in my email this morning, so maybe the situation has resolved itself somehow (maybe I installed another package that caused man-db to rebuild its database???) I hate when computers act non-deterministic. regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Man-DB is crazy
On Tue, 13 Sep 2005 09:44:15 -0400 Kevin B. McCarty [EMAIL PROTECTED] wrote: Hi list, Once a day I get the following email message from the man-db cron job: /etc/cron.daily/man-db: mandb: warning: /usr/share/man/man1/x-terminal-emulator.1.gz is a dangling symlink This in spite of all the evidence: benjo[1]:~% ls -l /usr/share/man/man1/x-terminal-emulator.1.gz lrwxrwxrwx 1 root root 42 2005-09-09 10:05 /usr/share/man/man1/x-terminal-emulator.1.gz - /etc/alternatives/x-terminal-emulator.1.gz You might need to follow the links. This happens occasionally over here, and I wondered about it as well. Try looking in /etc/ alternatives, you may find that the file x-terminal-emulator.1.gz points nowhere, or is nonexistant. Or, it points back to a manpage in / usr/share/man/man1 that does not exist. Here, I have a message that refers to the manpage for ftpd(8) being a dangling symlink (/usr/share/man/man8/ftpd.8.gz) $ [EMAIL PROTECTED] ls -l ftpd* lrwxrwxrwx 1 root root 27 Oct 3 2004 ftpd.8.gz - /etc/alternatives/ ftpd.8.gz [EMAIL PROTECTED] ls -l ftpd* lrwxrwxrwx 1 root root 17 Oct 3 2004 ftpd - /usr/sbin/wu-ftpd lrwxrwxrwx 1 root root 32 Oct 3 2004 ftpd.8.gz - /usr/share/man/ man8/wu-ftpd.8.gz OK, so far so good - let's see what is in /etc/alternatives now: $ [EMAIL PROTECTED] ls -l ftpd* lrwxrwxrwx 1 root root 17 Oct 3 2004 ftpd - /usr/sbin/wu-ftpd lrwxrwxrwx 1 root root 32 Oct 3 2004 ftpd.8.gz - /usr/share/man/ man8/wu-ftpd.8.gz Now, we need to check where ftpd.8.gz points to: [EMAIL PROTECTED] ls -l wu* ls: wu*: No such file or directory [EMAIL PROTECTED] Bingo. There's the dangling symlink. In my case, I'm not going to be veryworried about this as I don't really have a need for an ftp server (and there are better ones than wu-ftpd AFAIK). But I did find one relating to vi - jsut had to correct the /etc/alternatives/vi.1.gz to point to the right flavor of vi on my system (vim). Please CC replies to me as I'm not subscribed. OK, done. -- David E. Fox Thanks for letting me [EMAIL PROTECTED]change magnetic patterns [EMAIL PROTECTED] on your hard disk. --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Man-DB is crazy
David E. Fox wrote: On Tue, 13 Sep 2005 09:44:15 -0400 Kevin B. McCarty [EMAIL PROTECTED] wrote: benjo[1]:~% ls -l /usr/share/man/man1/x-terminal-emulator.1.gz lrwxrwxrwx 1 root root 42 2005-09-09 10:05 /usr/share/man/man1/x-terminal-emulator.1.gz - /etc/alternatives/x-terminal-emulator.1.gz You might need to follow the links. This happens occasionally over here, and I wondered about it as well. Try looking in /etc/ alternatives, you may find that the file x-terminal-emulator.1.gz points nowhere, or is nonexistant. Or, it points back to a manpage in / usr/share/man/man1 that does not exist. You snipped the part of my email where I did follow the links :-) I eventually got to the OK-looking existing file /usr/share/man/man1/gnome-terminal.1.gz . Thanks, though, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Man-DB is crazy
Hi list, Once a day I get the following email message from the man-db cron job: /etc/cron.daily/man-db: mandb: warning: /usr/share/man/man1/x-terminal-emulator.1.gz is a dangling symlink This in spite of all the evidence: benjo[1]:~% ls -l /usr/share/man/man1/x-terminal-emulator.1.gz lrwxrwxrwx 1 root root 42 2005-09-09 10:05 /usr/share/man/man1/x-terminal-emulator.1.gz - /etc/alternatives/x-terminal-emulator.1.gz benjo[2]:~% ls -l /etc/alternatives/x-terminal-emulator.1.gz lrwxrwxrwx 1 root root 39 2005-08-30 10:38 /etc/alternatives/x-terminal-emulator.1.gz - /usr/share/man/man1/gnome-terminal.1.gz benjo[3]:~% ls -l /usr/share/man/man1/gnome-terminal.1.gz -rw-r--r-- 1 root root 1369 2005-03-10 16:55 /usr/share/man/man1/gnome-terminal.1.gz Anyone have any idea what man-db's problem is and how to fix it? I'm running Debian Sarge, and as far as I remember haven't modified the scripts in /etc/cron.daily. Running /etc/cron.daily/man-db directly (as root) produces no output. Please CC replies to me as I'm not subscribed. Thanks, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
dangling symlink in man-db
How do I clean this up? /etc/cron.daily/man-db: mandb: warning: /usr/share/man/man3/Judy.3x.bz2 is a dangling symlink mandb: warning: /usr/share/man/man3/judy.3x.bz2 is a dangling symlink mandb: warning: /usr/share/man/man3/Judy1.3x.bz2 is a dangling symlink mandb: warning: /usr/share/man/man3/judy1.3x.bz2 is a dangling symlink mandb: warning: /usr/share/man/man3/J1T.3x.bz2 is a dangling symlink mandb: warning: /usr/share/man/man3/J1S.3x.bz2 is a dangling symlink mandb: warning: /usr/share/man/man3/J1U.3x.bz2 is a dangling symlink -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dangling symlink in man-db
On Fri, Sep 05, 2003 at 11:31:10AM -0400, [EMAIL PROTECTED] wrote: How do I clean this up? /etc/cron.daily/man-db: mandb: warning: /usr/share/man/man3/Judy.3x.bz2 is a dangling symlink mandb: warning: /usr/share/man/man3/judy.3x.bz2 is a dangling symlink mandb: warning: /usr/share/man/man3/Judy1.3x.bz2 is a dangling symlink mandb: warning: /usr/share/man/man3/judy1.3x.bz2 is a dangling symlink mandb: warning: /usr/share/man/man3/J1T.3x.bz2 is a dangling symlink mandb: warning: /usr/share/man/man3/J1S.3x.bz2 is a dangling symlink mandb: warning: /usr/share/man/man3/J1U.3x.bz2 is a dangling symlink Er, make those files not be dangling symlinks any more? File a bug against whatever package provides those symlinks (not man-db!) if necessary ... -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: after upgrade man-db seg faults
On Sun, Aug 10, 2003 at 03:03:30PM -0400, John covici wrote: Well, tell me the steps -- it will be easier that way and I'll get the source and rebuild. As root: # apt-get install build-essential debhelper flex gettext groff libdb3-dev As an ordinary user: $ apt-get source man-db $ cd man-db-2.4.1 $ debian/rules build As the 'man' user: $ cd /WHEREVER/YOU/DID/THE/ABOVE/src $ gdb ./mandb (gdb) run --no-purge --quiet [ ... and with any luck it will now segfault in the same way, so ... ] (gdb) bt [ ... you might want to leave this gdb open and get in touch with me now, in case I want some more debugging information ... ] If you have trouble building the package, let me know and I'll produce a debugging build for you, but it would be easier if you could get it working on your system. I mailed this because I couldn't believe I was the only one and figured it would be fixed or worked around by now. I'm using 2.4.1-12 myself, and haven't had any other reports. Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: after upgrade man-db seg faults
On Sun, Aug 10, 2003 at 09:00:11AM -0400, John Covici wrote: Hi. After upgrading to 2.4.1-12 of man-db it seg faults in the cron.daily script at the start-stop-daemon line. 2.4.1-12, really? I know that there was a problem with the woody backport but was not aware of anything in unstable. Do you know how to build man-db from source and apply gdb to it? If not, mail me and I'll walk you through it; I want to fix this. BTW, filing a bug report is better than mailing debian-user for this sort of thing. It happens that I read debian-user but many maintainers don't. Cheers, -- Colin Watson (man-db maintainer) [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: after upgrade man-db seg faults
Well, tell me the steps -- it will be easier that way and I'll get the source and rebuild. I mailed this because I couldn't believe I was the only one and figured it would be fixed or worked around by now. on Sunday 08/10/2003 Colin Watson([EMAIL PROTECTED]) wrote On Sun, Aug 10, 2003 at 09:00:11AM -0400, John Covici wrote: Hi. After upgrading to 2.4.1-12 of man-db it seg faults in the cron.daily script at the start-stop-daemon line. 2.4.1-12, really? I know that there was a problem with the woody backport but was not aware of anything in unstable. Do you know how to build man-db from source and apply gdb to it? If not, mail me and I'll walk you through it; I want to fix this. BTW, filing a bug report is better than mailing debian-user for this sort of thing. It happens that I read debian-user but many maintainers don't. Cheers, -- Colin Watson (man-db maintainer) [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- John Covici [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
after upgrade man-db seg faults
Hi. After upgrading to 2.4.1-12 of man-db it seg faults in the cron.daily script at the start-stop-daemon line. I am using kernel 2.4.21 vanilla if it makes any difference. Thanks. -- John Covici [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: man-db
Frédéric Bothamy wrote: * Jeremie Koenig [EMAIL PROTECTED] [2003-01-15 09:18] : On Wed, Jan 15, 2003 at 08:21:33AM +0100, Raymond Gree wrote: voila depuis quelques jour mon PC WOODY fonctionne 24/24 j'obtiens depuis le message: /etc/cron.daily/man-db: start-stop-daemon: user `man' not found run-parts: /etc/cron.daily/man-db exited with return code 2 je pense que c'est une operation periodique mais je n'arrive pas a trouver la cause de l'erreur - dois je creer un user man? Il y a un paquet debian (peut-etre bien base-files ou qqc comme ca) qui verifie que tous les utilisateurs standard existent dans son postinst. Peut etre que reinstaller le paquet en question serait une bonne idee. (info complementaires quelqu'un ?) J'aurais bien dis base-config, seulement je ne trouve pas la trace de cette vérification/modification dans les fichiers de /var/lib/dpkg/info/base-config*. Par contre, je me souviens bien que lors de la mise à jour d'un paquet, il est demandé quelque chose comme : Voulez-vous mettre à jour votre fichier /etc/passwd ? Ceci est fortement recommandé Trouvé, ce n'est pas base-config, c'est base-passwd. Et il suffit de lancer update-passwd pour normalement ajouter les entrées manquantes au fichier /etc/passwd. Encore, une dernière info, le fichier master des entrées nécessaires est dans /usr/share/base-passwd/passwd.master. Fred Merci Fred Jeremie, j'ai fait le update-passwd et je n'ai pas eu de warning ce matin Raymond
man-db
Bonjour a tous, voila depuis quelques jour mon PC WOODY fonctionne 24/24 j'obtiens depuis le message: /etc/cron.daily/man-db: start-stop-daemon: user `man' not found run-parts: /etc/cron.daily/man-db exited with return code 2 je pense que c'est une operation periodique mais je n'arrive pas a trouver la cause de l'erreur - dois je creer un user man? merci pour votre aide Raymond
Re: man-db
On Wed, Jan 15, 2003 at 08:21:33AM +0100, Raymond Gree wrote: voila depuis quelques jour mon PC WOODY fonctionne 24/24 j'obtiens depuis le message: /etc/cron.daily/man-db: start-stop-daemon: user `man' not found run-parts: /etc/cron.daily/man-db exited with return code 2 je pense que c'est une operation periodique mais je n'arrive pas a trouver la cause de l'erreur - dois je creer un user man? Il y a un paquet debian (peut-etre bien base-files ou qqc comme ca) qui verifie que tous les utilisateurs standard existent dans son postinst. Peut etre que reinstaller le paquet en question serait une bonne idee. (info complementaires quelqu'un ?) -- Jeremie Koenig [EMAIL PROTECTED]
Re: man-db
* Jeremie Koenig [EMAIL PROTECTED] [2003-01-15 09:18] : On Wed, Jan 15, 2003 at 08:21:33AM +0100, Raymond Gree wrote: voila depuis quelques jour mon PC WOODY fonctionne 24/24 j'obtiens depuis le message: /etc/cron.daily/man-db: start-stop-daemon: user `man' not found run-parts: /etc/cron.daily/man-db exited with return code 2 je pense que c'est une operation periodique mais je n'arrive pas a trouver la cause de l'erreur - dois je creer un user man? Il y a un paquet debian (peut-etre bien base-files ou qqc comme ca) qui verifie que tous les utilisateurs standard existent dans son postinst. Peut etre que reinstaller le paquet en question serait une bonne idee. (info complementaires quelqu'un ?) J'aurais bien dis base-config, seulement je ne trouve pas la trace de cette vérification/modification dans les fichiers de /var/lib/dpkg/info/base-config*. Par contre, je me souviens bien que lors de la mise à jour d'un paquet, il est demandé quelque chose comme : Voulez-vous mettre à jour votre fichier /etc/passwd ? Ceci est fortement recommandé Trouvé, ce n'est pas base-config, c'est base-passwd. Et il suffit de lancer update-passwd pour normalement ajouter les entrées manquantes au fichier /etc/passwd. Encore, une dernière info, le fichier master des entrées nécessaires est dans /usr/share/base-passwd/passwd.master. Fred
man-db install error
Hi everyone. Error installing man-db. Can anyone please tell me how to fix this problem: Fetched 334kB in 1m6s (4997B/s) Selecting previously deselected package man-db. (Reading database ... 33532 files and directories currently installed.) Unpacking man-db (from .../man-db_2.3.16-4_i386.deb) ... Setting up man-db (2.3.16-4) ... chown: man.root: invalid user this error dpkg: error processing man-db (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: man-db E: Sub-process /usr/bin/dpkg returned an error code (1) Not long ago, a whole stack of system user accounts appeared on the KDM login screen. After, messing around in KDE tools, I got rid of them, but think that I have killed them all. However, besides this error, my system seems to run per usual, with no problems. Thanks in advance. D.Radel.
Re: man-db install error
Satz- und Datentechnik Günter Knab B|ro f|r Systemanalyse und angewandte Mathematik Geiselhofer Strasse 5 92272 Lintach tel:+49.9627.91261 fax:+49.9627.91262 mailto:[EMAIL PROTECTED] http://www.asamnet/~knabguen On Mon, 11 Feb 2002, D E Radel wrote: Hi everyone. Error installing man-db. Can anyone please tell me how to fix this problem: Fetched 334kB in 1m6s (4997B/s) Selecting previously deselected package man-db. (Reading database ... 33532 files and directories currently installed.) Unpacking man-db (from .../man-db_2.3.16-4_i386.deb) ... Setting up man-db (2.3.16-4) ... chown: man.root: invalid user this error dpkg: error processing man-db (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: man-db E: Sub-process /usr/bin/dpkg returned an error code (1) Not long ago, a whole stack of system user accounts appeared on the KDM login screen. After, messing around in KDE tools, I got rid of them, but think that I have killed them all. However, besides this error, my system seems to run per usual, with no problems. looks like an missing entry in /etc/passwd: --- /etc/passwd on _my_ system man:x:6:100:man:/var/cache/man:/bin/sh --- May be this entry was accidently deleted, just add it again with your favorite editor. Reinstallation of the package schould finish without error -- gk
Re: man-db install error -FIXED
looks like an missing entry in /etc/passwd: --- /etc/passwd on _my_ system man:x:6:100:man:/var/cache/man:/bin/sh --- May be this entry was accidently deleted, just add it again with your favorite editor. Reinstallation of the package schould finish without error -- gk Thank you! Thank you! Thank you! I looked at my /etc/passwd file to find only TWO entries! Man!! I reverted to /etc/passwd.bak file. I don't know which app backed up my /etc/passwd file but I am grateful! Thanks for your help!
Re: man-db cron.daily job
On Sat, Sep 29, 2001 at 02:42:33AM +0100, Carlos Sousa wrote: Colin Watson wrote: (can't have been any vaguely recent version of man-db, as none of them run with root privileges ...). man-db can certainly work around it, my 'man' apparently runs with root privileges: $ ll /usr/lib/man-db total 220 drwxr-xr-x2 root root 4096 Sep 26 00:55 ./ drwxr-xr-x 131 root root36864 Sep 26 14:33 ../ -rwxr-xr-x1 root root90684 Sep 19 02:20 man* == -rwxr-xr-x1 root root70844 Sep 19 02:20 mandb* -rwxr-xr-x1 root root 4328 Sep 19 02:20 wrapper* No, the binary's just owned by root, and isn't setuid. No problem there. Oh, I guess man won't be dropping privileges, then, as it's configured to when it's setuid ... that could explain this bug. Better fix that before woody releases. However, *.gz files are still not created for ordinary users, only for root. Doesn't keep me awake at night, but it's a symptom for something not right. If man is running as the ordinary user that called it, it seems logical that it can't create files in a directory with write permission only for user 'man'?... man needs to be setuid to do that, which is now turned off by default for security reasons. This is not to say it's necessarily an exploit waiting to happen; I usually run it setuid myself - but there've been enough security holes that I felt non-setuid was a safer default. Unfortunately this means disabling cached preformatted pages by default too. If you want to change this, run 'dpkg-reconfigure man-db'. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: man-db cron.daily job
On Sun, Sep 30, 2001 at 07:30:57AM -0500, Colin Watson wrote: On Sat, Sep 29, 2001 at 02:42:33AM +0100, Carlos Sousa wrote: my 'man' apparently runs with root privileges: $ ll /usr/lib/man-db total 220 drwxr-xr-x2 root root 4096 Sep 26 00:55 ./ drwxr-xr-x 131 root root36864 Sep 26 14:33 ../ -rwxr-xr-x1 root root90684 Sep 19 02:20 man* == -rwxr-xr-x1 root root70844 Sep 19 02:20 mandb* -rwxr-xr-x1 root root 4328 Sep 19 02:20 wrapper* No, the binary's just owned by root, and isn't setuid. No problem there. Oh, I guess man won't be dropping privileges, then, as it's configured to when it's setuid ... that could explain this bug. Better fix that before woody releases. This was enough of a clue for me to work out why /var/cache/man/* directories sometimes end up owned by root. It's now fixed in man-db 2.3.20-4 in unstable. -- Colin Watson [EMAIL PROTECTED]
Re: man-db cron.daily job
It shouldn't. Could you show me the permissions on /var/cache/man/cat8 (using 'ls -ld')? drwxr-sr-x 15 manroot 4096 Sep 28 07:48 /var/cache/man/ drwxr-sr-x 2 root root 4096 Sep 28 08:28 /var/cache/man/cat1/ drwxr-sr-x 2 root root 4096 Aug 22 21:20 /var/cache/man/cat2/ drwxr-sr-x 2 root root 4096 Aug 22 21:20 /var/cache/man/cat3/ drwxr-sr-x 2 root root 4096 Aug 22 21:20 /var/cache/man/cat4/ drwxr-sr-x 2 root root 4096 Sep 27 23:30 /var/cache/man/cat5/ drwxr-sr-x 2 root root 4096 Sep 27 23:30 /var/cache/man/cat6/ drwxr-sr-x 2 root root 4096 Sep 27 23:30 /var/cache/man/cat7/ drwxr-sr-x 2 root root 4096 Sep 27 23:30 /var/cache/man/cat8/ You might like to file a bug report against the man-db package, where we can sort this out in more detail. Is it man-db or is it me? I've been following this list for some time now, and I can't remember anyone complaining about this... Also, what version of man-db are you using? man-db 2.3.20-2 I've been playing around a little more with this and found out that the cached .gz files are only created for user root, an not for other users. That's not right, is it? Might be a clue... [EMAIL PROTECTED]:~$ ll /var/cache/man/cat2/ total 8 drwxr-sr-x2 root root 4096 Aug 22 21:20 ./ drwxr-sr-x 15 man root 4096 Sep 28 07:48 ../ [EMAIL PROTECTED]:~$ man 2 syslog Reformatting syslog(2), please wait... [EMAIL PROTECTED]:~$ ll /var/cache/man/cat2/ total 8 drwxr-sr-x2 root root 4096 Aug 22 21:20 ./ drwxr-sr-x 15 man root 4096 Sep 28 07:48 ../ [EMAIL PROTECTED]:~$ su -c 'man 2 syslog' Password: Reformatting syslog(2), please wait... [EMAIL PROTECTED]:~$ ll /var/cache/man/cat2/ total 12 drwxr-sr-x2 root root 4096 Sep 28 09:09 ./ drwxr-sr-x 15 man root 4096 Sep 28 07:48 ../ -rw-r--r--1 man root 2286 Jun 11 00:17 syslog.2.gz Thanks, Thank you Carlos
Re: man-db cron.daily job
On Fri, Sep 28, 2001 at 09:14:03AM +0100, Carlos Sousa wrote: Colin Watson wrote: It shouldn't. Could you show me the permissions on /var/cache/man/cat8 (using 'ls -ld')? drwxr-sr-x 15 manroot 4096 Sep 28 07:48 /var/cache/man/ drwxr-sr-x 2 root root 4096 Sep 28 08:28 /var/cache/man/cat1/ drwxr-sr-x 2 root root 4096 Aug 22 21:20 /var/cache/man/cat2/ drwxr-sr-x 2 root root 4096 Aug 22 21:20 /var/cache/man/cat3/ drwxr-sr-x 2 root root 4096 Aug 22 21:20 /var/cache/man/cat4/ drwxr-sr-x 2 root root 4096 Sep 27 23:30 /var/cache/man/cat5/ drwxr-sr-x 2 root root 4096 Sep 27 23:30 /var/cache/man/cat6/ drwxr-sr-x 2 root root 4096 Sep 27 23:30 /var/cache/man/cat7/ drwxr-sr-x 2 root root 4096 Sep 27 23:30 /var/cache/man/cat8/ They shouldn't be owned by user root, but by user man: [EMAIL PROTECTED] ~]$ ls -l /var/cache/man total 900 drwxr-sr-x7 man root 4096 Sep 28 06:32 X11R6 drwxr-sr-x2 man root 4096 Sep 28 01:11 cat1 drwxr-sr-x2 man root 4096 Sep 27 06:31 cat2 drwxr-sr-x2 man root 4096 Sep 28 01:13 cat3 drwxr-sr-x2 man root 4096 Jul 9 06:28 cat4 drwxr-sr-x2 man root 4096 Sep 28 01:13 cat5 drwxr-sr-x2 man root 4096 Sep 23 20:38 cat6 drwxr-sr-x2 man root 4096 Sep 26 06:31 cat7 drwxr-sr-x2 man root 4096 Sep 28 01:13 cat8 drwxr-sr-x7 man root 4096 Aug 26 06:47 fsstnd -rw-r--r--1 man root 864256 Sep 28 06:32 index.bt drwxr-sr-x2 man root 4096 Jul 1 04:45 local drwxr-sr-x3 man root 4096 Sep 28 06:32 oldlocal drwxr-sr-x2 man root 4096 Jul 1 04:45 opt You might like to file a bug report against the man-db package, where we can sort this out in more detail. Is it man-db or is it me? I've been following this list for some time now, and I can't remember anyone complaining about this... I'm not sure what caused the permissions to be that way originally (can't have been any vaguely recent version of man-db, as none of them run with root privileges ...). man-db can certainly work around it, though; if nothing else I can 'chown -R' that directory in the postinst. Also, what version of man-db are you using? man-db 2.3.20-2 I've been playing around a little more with this and found out that the cached .gz files are only created for user root, an not for other users. That'll be the same cause. Thanks - I'll file a bug and see if I can squeeze in a fix before the base system freezes. 'chown -R man /var/cache/man' will fix your problem for now. -- Colin Watson [EMAIL PROTECTED]
Re: man-db cron.daily job
Colin Watson wrote: (can't have been any vaguely recent version of man-db, as none of them run with root privileges ...). man-db can certainly work around it, my 'man' apparently runs with root privileges: $ ll /usr/lib/man-db total 220 drwxr-xr-x2 root root 4096 Sep 26 00:55 ./ drwxr-xr-x 131 root root36864 Sep 26 14:33 ../ -rwxr-xr-x1 root root90684 Sep 19 02:20 man* == -rwxr-xr-x1 root root70844 Sep 19 02:20 mandb* -rwxr-xr-x1 root root 4328 Sep 19 02:20 wrapper* though a ps aux shows the man process as belonging to the current user: carlos 15166 0.0 0.6 1696 772 pts/0 S 02:23 0:00 man 1 chown 'chown -R man /var/cache/man' will fix your problem for now. Thanks, that solved my initial problem (the man-db cron job not being able to delete stale files). However, *.gz files are still not created for ordinary users, only for root. Doesn't keep me awake at night, but it's a symptom for something not right. If man is running as the ordinary user that called it, it seems logical that it can't create files in a directory with write permission only for user 'man'?... I can always uninstall and reinstall the man-db package, that'll clear the time-space warp that's clearly the cause of this thing :) Thanks for the help, Colin. Carlos
Re: man-db
on Thu, Sep 27, 2001 at 01:15:03AM +1000, Craig W ([EMAIL PROTECTED]) wrote: Hi, I am having problems with man-db, could someone please advise on why this is happening any solutions, pointers I can try. Cron [EMAIL PROTECTED] test -e /usr/sbin/anacron || run-parts --report /etc/cron.weekly X-Cron-Env: SHELL=/bin/sh X-Cron-Env: PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin X-Cron-Env: HOME=/root X-Cron-Env: LOGNAME=root Message-Id: [EMAIL PROTECTED] Date: Sun, 23 Sep 2001 06:47:29 +1000 run-parts: /etc/cron.weekly/man-db exited with return code 3 There was a post regarding mandb on list a month or so back. Had to do with a corrupted mandb file someplace IIRC. Check archives. Peace. -- Karsten M. Self kmself@ix.netcom.comhttp://kmself.home.netcom.com/ What part of Gestalt don't you understand? Home of the brave http://gestalt-system.sourceforge.net/Land of the free Free Dmitry! Boycott Adobe! Repeal the DMCA! http://www.freesklyarov.org Geek for Hire http://kmself.home.netcom.com/resume.html pgp6Akk8YXbyd.pgp Description: PGP signature
man-db cron.daily job
On my machine root keeps getting email from cron saying rm: cannot unlink `/var/cache/man/cat8/(whatever).gz': Permission denied. I've traced this behaviour to the man-db cron job trying to remove stale files from the /var/cache/man tree while running as user 'man', because running the command mannualy with '--chuid man' generates the error messages, while using '--chuid root' makes it succeed. The strange thing about this is that the cached man files are owned by 'man', so why should the rm command fail when run as user 'man'? Further inspection shows that the /var/cache/man directories are SGID root, and the cached files are owned by user 'man' and group 'root' (instead of group 'users'). Unfortunately I don't know what a SGID directory means, so I can't relate it to my problem. I could solve this matter by either: 1) changing the man-db cron file so that the command is run as root (inelegant), 2) removing the SGID bit from the /var/cache/man directory and subdirectories (seems dangerous) Could you advise on a better solution? TIA Carlos
Re: man-db cron.daily job
On Fri, Sep 28, 2001 at 12:04:19AM +0100, Carlos Sousa wrote: On my machine root keeps getting email from cron saying rm: cannot unlink `/var/cache/man/cat8/(whatever).gz': Permission denied. I've traced this behaviour to the man-db cron job trying to remove stale files from the /var/cache/man tree while running as user 'man', because running the command mannualy with '--chuid man' generates the error messages, while using '--chuid root' makes it succeed. The strange thing about this is that the cached man files are owned by 'man', so why should the rm command fail when run as user 'man'? It shouldn't. Could you show me the permissions on /var/cache/man/cat8 (using 'ls -ld')? Further inspection shows that the /var/cache/man directories are SGID root, and the cached files are owned by user 'man' and group 'root' (instead of group 'users'). Unfortunately I don't know what a SGID directory means, so I can't relate it to my problem. The setgid directory should be irrelevant (it causes files created in that directory to be owned by that group - I've been wondering whether the sgid bit is necessary there for a while now, but haven't had the nerve to change it this close to the freeze in case something weird breaks). I could solve this matter by either: 1) changing the man-db cron file so that the command is run as root (inelegant), 2) removing the SGID bit from the /var/cache/man directory and subdirectories (seems dangerous) Could you advise on a better solution? You might like to file a bug report against the man-db package, where we can sort this out in more detail. Also, what version of man-db are you using? Thanks, -- Colin Watson [EMAIL PROTECTED]
man-db
Hi, I am having problems with man-db, could someone please advise on why this is happening any solutions, pointers I can try. Cron [EMAIL PROTECTED] test -e /usr/sbin/anacron || run-parts --report /etc/cron.weekly X-Cron-Env: SHELL=/bin/sh X-Cron-Env: PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin X-Cron-Env: HOME=/root X-Cron-Env: LOGNAME=root Message-Id: [EMAIL PROTECTED] Date: Sun, 23 Sep 2001 06:47:29 +1000 run-parts: /etc/cron.weekly/man-db exited with return code 3 Regards, CraigW P.S. I thought this was pretty cool. Makes me feel better even though I can't get what I am looking for. http://www.luftgitarr.se/5_annonser/
Re: man-db
Hello Craig, On Wednesday, September 26, 2001 at 5:15:03 PM, you wrote (at least in part): Hi, I am having problems with man-db, could someone please advise on why this is happening any solutions, pointers I can try. ... run-parts: /etc/cron.weekly/man-db exited with return code 3 my '/etc/cron.weekly/man-db' contains only one _executed_ line: /usr/bin/nice /usr/bin/mandb --create 2/dev/null /dev/null if yours does too try this line without the '2/dev/null /dev/null' or even with an additional '--debug' so it looks like this /usr/bin/nice /usr/bin/mandb --create or /usr/bin/nice /usr/bin/mandb --create --debug execute is manually and see what 'mandb' has to moan about. HTH -- Best regards Peter
Re: man-db
On Wed, Sep 26, 2001 at 06:08:17PM +0200, Peter Palmreuther wrote: On Wednesday, September 26, 2001 at 5:15:03 PM, you wrote (at least in part): I am having problems with man-db, could someone please advise on why this is happening any solutions, pointers I can try. ... run-parts: /etc/cron.weekly/man-db exited with return code 3 What version of man-db is this? my '/etc/cron.weekly/man-db' contains only one _executed_ line: /usr/bin/nice /usr/bin/mandb --create 2/dev/null /dev/null if yours does too try this line without the '2/dev/null /dev/null' or even with an additional '--debug' so it looks like this /usr/bin/nice /usr/bin/mandb --create or /usr/bin/nice /usr/bin/mandb --create --debug execute is manually and see what 'mandb' has to moan about. I'll second that. With exit code 3 (CHILD_FAIL), chances are that gzip is failing to decompress a man page somehow. -- Colin Watson [EMAIL PROTECTED]
Man-db cofigure error
dselect automatically upgrades man-db. But, it cannot be configured, display this error messge. - Setting up man-db (2.3.16-1.1) ... chown: man.root: invalid user dpkg: error processing man-db (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: man-db --- How can this problem be fixed? -- Sang-Kyun Kim Imazic Research Staff, [EMAIL PROTECTED]
Re: Man-db cofigure error
Sang-Kyun Kim [EMAIL PROTECTED] wrote: dselect automatically upgrades man-db. But, it cannot be configured, display this error messge. - Setting up man-db (2.3.16-1.1) ... chown: man.root: invalid user dpkg: error processing man-db (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: man-db --- How can this problem be fixed? The 'man' user should always exist, as it's created by base-passwd (an essential package). Are you doing something odd with your password file that might overwrite this? If so, fix it so that 'man' exists - base-passwd makes it userid 6, so you should stick with that. -- Colin Watson [EMAIL PROTECTED]
man-db mentions a number of bad Symlinks
Hello all. This is my third week to debian and 6th month to Linux, but I'm having a little problem. When I run man some file I periodically see warnings smiliar to these. man: can't open /usr/man/man8/upgrade-windowmaker-defaults.8: No such file or di rectory man: warning: /usr/man/man8/upgrade-windowmaker-defaults.8.gz: bad symlink or ROFF `.so' request About 50 or so of these warnings flash by each with a different symlink. I know what you're going to say. The file (above) upgrade-windowmaker-defaults.8.gz is obviously a dangling symlink and should be removed. I did this just a fw days ago. In fact I removed every bad symlink in each man directory, yet now they are back. It is as if man-db is doing this to me. can anyone explain what exactly man-db does. Obviously it compacts my man files. DOes it keep the originals anywhere? Anyone else have this problem?
Re: I can config man-db, the man command is unavaliable.
I've just installed man-db and manpages from the following URL http://www.debian.org/Packages/stable/doc/ follow the instructions, then man command IS avaliable with comfort. Alan Tam. ayin wrote: Dear Sir When I install the man-db package , the dselect utility tell me that I should have groff. But groff need libg++272. The problem is that I have installed libg++272( the dselect show installed) , but the groff item still shows that libg++272 does not appear in the installed packages list, and be unavaliable. So that I can not run man utiltiy, then how can I do? Give me some advice , Please . ayin from Shanghai -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null
Re: I can config man-db, the man command is unavaliable.
On: Thu, 15 Oct 1998 16:53:15 +0800 ayin writes: Dear Sir When I install the man-db package , the dselect utility tell me that I should have groff. But groff need libg++272. The problem is that I have installed libg++272( the dselect show installed) , but the groff item still shows that libg++272 does not appear in the installed packages list, and be unavaliable. So that I can not run man utiltiy, then how can I do? Probably your installed libg++272 is older than the one excpected by groff. I have a newer version than you, but my groff: Depends: libc6, libstdc++2.8 (= 2.90.26-1) i.e., any installed libstdc++2.8 (the successor of libg++ in some way) older than 2.90.26-1 will not be accepted. Compare the output of: dpkg -l libg++272 and the depends line of your groff (can be found using: less -p Package: groff /var/lib/dpkg/available ). Torsten
I can config man-db, the man command is unavaliable.
Dear Sir When I install the man-db package , the dselect utility tell me that I should have groff. But groff need libg++272. The problem is that I have installed libg++272( the dselect show installed) , but the groff item still shows that libg++272 does not appear in the installed packages list, and be unavaliable. So that I can not run man utiltiy, then how can I do? Give me some advice , Please . ayin from Shanghai
man-db
Hola a la lista He estado recompilando el dsc 66 de man-db, y me ha ocurrido una cosa curiosa El configure que viene incluido, no soporta --with-db=db2, pero si lo borro, se regenera y entonces si lo soporta, es como si el configure y el configure.in no tuvieran que ver uno con otro. ¿Puede ser un bug? Saludos.
Re: man-db
On Sat, Aug 29, 1998 at 08:52:14AM +0200, Angel Vicente Perez wrote: El configure que viene incluido, no soporta --with-db=db2, pero si lo borro, se regenera y entonces si lo soporta, es como si el configure y el configure.in no tuvieran que ver uno con otro. ¿Puede ser un bug? Desde mi punto de vista, sí, porque al dar $ dpkg-source -x paquete_version-release.dsc $ cd paquete-version $ debian/rules binary lo que se produce en ../paquete_version-release_arch.deb no es igual (funcionalmente) al paquete oficial (lo que quiere decir que en otras arquitecturas no se produce un paquete igual). Es probable que el problema venga de algo similar a lo que yo hago con algunos paquetes míos que usan autoconf. Al decir debian/rules clean, yo borro configure, pues si lo dejo allí, el diff.gz es innecesariamente grande. Eso sí, me aseguro que el configure sea regenerado a partir del configure.in. Si lo que estás haciendo es lo que dice arriba, entonces es un bug. Si estas haciendo otra cosa (como ./configure --blah, y luego make) entonces no. Marcelo
man-db
Hola a la lista... Estoy viendo el paquete man-db_2.3.10-65, en su version fuente, y he visto que el instalable que genera es de la forma: man-db_2.3.10-63*.deb ¿Esto es un error? En el fichero rules, se establece la variable my-version=63. Saludos. Angel Vicente Perez Dpto. Informática KNIPPING ESPAÑA S.A. Tfno. +34-1-6070-311 Fax +34-1-6070-331 e-mail [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
man-db config problems
I keep getting this error whenever I try to configure anything through dselect: Checking for languages ... de_DECan't locate Getopt/Long.pm in @INC at /usr/sb in/chmanconfig line 38. BEGIN failed--compilation aborted at /usr/sbin/chmanconfig line 38. dpkg: error processing man-db (--configure): subprocess post-installation script returned error exit status 2 Errors were encountered while processing: man-db dpkg --configure returned error exit status 1. -Jeff * | Jeff Schreiber | There is freedom and there is responsibility. | | aka - Spectre | You have obviously figured out the first | | [EMAIL PROTECTED] | but not the latter.| | | (Rob Schmunk - [EMAIL PROTECTED]) | * -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null
Man-db and hamm
In my old bo man-db package I was able to select the manual pages I get using the LANG variable. For example, after installing manpages-de and setting LANG=de_DE I was getting the german version if available. In the hamm version of man-db (2.3.10-63) this no longer works. Now it seems that man-db only finds pages beneath de but not beneath de_DE. I'd have to change the MANPATH for each single user or modify the manpath.conf to put the german path before the others making the chance globally regardless how the users LANG variable is set. I didn't make any chance to the old and the new mandb.config file. Does anybody know the reason for this strange behaviour of the new version? Is the newer version of manpages-de package to be accused? BTW: The manual pages beneath de are the man-db ones. The other as installed from the manpages-de packages are stored beneath de_DE. Torsten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A need to manualy run /etc/cron.weekly/man-db
On Wed, Feb 25, 1998 at 11:02:08PM +, [EMAIL PROTECTED] wrote: And after I turned on the power, rebooted and logged again, I got a segmentation fault whenever I tried to man -w something. Only after manualy running the script the man -w something worked. Has someone else experienced this ? Yes. Please refer to the Debian-user faq: http://www.debian.org/cgi-bin/fom?file=58showEditCmds=1 it´s because the database of man-db is corrupted. The above reference (fom?...) is claims that the DB is getting corrupted and that rebuliding it solves the problem. This is seems to an answer. However, it is also said that the DB corruption is due to a failed search. But my claim is that the corruption appears after using the reboot or shutdown command from an xterm. Furthere, when I reboot or shutdown the machine from a VT (after switching to a VT using ctrl+alt+F?), the DB does not get corrupted. Is this a bug ? This reference to the reboot (and a previous one to running xman) make me suspicious. I wasn't able to corrupt the db even when turnung off the machine during use of man. The only corruption that I have seen is the one drived by use of the utility info which is solved by version 2.3.10-45 . which version are you running ( dpkg -s man-db can tell you)? However the newest version of man-db for bo (libc5) is available in bo-unstable (2.3.10-59bo61) toghether with a safer version of groff. fab -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Líder Minimo del Pluto- Debian Developer Happy Debian User | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E more than 34 months are needed to get rid of the millennium. [me] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: A need to manualy run /etc/cron.weekly/man-db
On a previous posting I said that I needed to run the mentioned cron script manualy. Now I found out when I had to run this script manualy. It turned out that it happaned after a shutdown command when I was logged to an xterm (and su to root). Prior to the shutdown I also had an xman window opened. And after I turned on the power, rebooted and logged again, I got a segmentation fault whenever I tried to man -w something. Only after manualy running the script the man -w something worked. Has someone else experienced this ? Yes. Please refer to the Debian-user faq: http://www.debian.org/cgi-bin/fom?file=58showEditCmds=1 it´s because the database of man-db is corrupted. The above reference (fom?...) is claims that the DB is getting corrupted and that rebuliding it solves the problem. This is seems to an answer. However, it is also said that the DB corruption is due to a failed search. But my claim is that the corruption appears after using the reboot or shutdown command from an xterm. Furthere, when I reboot or shutdown the machine from a VT (after switching to a VT using ctrl+alt+F?), the DB does not get corrupted. Is this a bug ? -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
man-db installation problem ...
I tried to install the man page package (got too tired doing gunzip -c |groff -Tascii -man), and received the following message from dselect. I had libdb1, groff, bsdmainutils already installed prior to installing the manpaged. positive messages deleleted Checking for languages ... de_DECan't locate Getopt/Long.pm in @INC at /usr/sbin/chmanconfig line 38. BEGIN failed--compilation aborted at /usr/sbin/chmanconfig line 38. dpkg: error processing man-db (--install): subprocess post-installation script returned error exit status 2 Thanks, Nebu -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: man-db installation problem ...
On Wed, Feb 25, 1998 at 09:17:31PM -0500, Nebu John Mathai wrote: I tried to install the man page package (got too tired doing gunzip -c |groff -Tascii -man), and received the following message from dselect. I had libdb1, groff, bsdmainutils already installed prior to installing the manpaged. positive messages deleleted Checking for languages ... de_DECan't locate Getopt/Long.pm in @INC at /usr/sbin/chmanconfig line 38. BEGIN failed--compilation aborted at /usr/sbin/chmanconfig line 38. dpkg: error processing man-db (--install): subprocess post-installation script returned error exit status 2 You need to have perl installed. A bug has already been filed. Adam Klein -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: man-db installation problem ...
Checking for languages ... de_DECan't locate Getopt/Long.pm in @INC at /usr/sbin/chmanconfig line 38. BEGIN failed--compilation aborted at /usr/sbin/chmanconfig line 38. dpkg: error processing man-db (--install): subprocess post-installation script returned error exit status 2 You need to have perl installed. A bug has already been filed. Just as additional followup, if you don't need any additional language support just comment out the section in the /var/lib/dpkg/info/man-db.postinst script that deals with languages and run the dselect configure packages option and man-db will install without errors. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: man-db installation problem ...
On Wed, Feb 25, 1998 at 07:34:54PM -0800, Adam Klein wrote: On Wed, Feb 25, 1998 at 09:17:31PM -0500, Nebu John Mathai wrote: Checking for languages ... de_DECan't locate Getopt/Long.pm in @INC at /usr/sbin/chmanconfig line 38. You need to have perl installed. A bug has already been filed. ... a long history ... I avoid to comment on the request to have a pure debian system (without perl) that made changes into bo (1.3) which can be without perl installed (previous couldn't). This bug (which was passed as a hot potato between man-db, boot-floppies and perl-base), came to an end with hamm, where there will be a basic perl essential, but lacking the missing modules :-) Thus from man-db = 2.3.10-59 the perl script has been thrown away. fab -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Líder Minimo del Pluto- Debian Developer Happy Debian User | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E more than 34 months are needed to get rid of the millennium. [me] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: A need to manualy run /etc/cron.weekly/man-db
[EMAIL PROTECTED] writes: On a previous posting I said that I needed to run the mentioned cron script manualy. Now I found out when I had to run this script manualy. It turned out that it happaned after a shutdown command when I was logged to an xterm (and su to root). Prior to the shutdown I also had an xman window opened. And after I turned on the power, rebooted and logged again, I got a segmentation fault whenever I tried to man -w something. Only after manualy running the script the man -w something worked. Has someone else experienced this ? Yes. Please refer to the Debian-user faq: http://www.debian.org/cgi-bin/fom?file=58showEditCmds=1 it´s because the database of man-db is corrupted. HTH, Jens --- [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 2048/E451C639 Jens Ritter Key fingerprint: 5F 3D 43 1E 24 1E CC 48 1E 05 93 3A A7 10 73 37 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
A need to manualy run /etc/cron.weekly/man-db
On a previous posting I said that I needed to run the mentioned cron script manualy. Now I found out when I had to run this script manualy. It turned out that it happaned after a shutdown command when I was logged to an xterm (and su to root). Prior to the shutdown I also had an xman window opened. And after I turned on the power, rebooted and logged again, I got a segmentation fault whenever I tried to man -w something. Only after manualy running the script the man -w something worked. Has someone else experienced this ? -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
help with man-db
Hi. I'm having problems with Motif man pages which I installed on my system. If I run, say, man XmString I get the following error messages: Reformatting XmString(3x), please wait... zsoelim: /usr/X11R6/man/man3/XmString.3x:292: \\$1: No such file or directory zsoelim: \\$1.gz: No such file or directory zsoelim: /usr/X11R6/man/man3/XmString.3x:292: warning: failed .so request zsoelim: /usr/X11R6/man/man3/XmString.3x:329: /tmp/pI.tmp.: No such file or directory zsoelim: /tmp/pI.tmp..gz: No such file or directory zsoelim: /usr/X11R6/man/man3/XmString.3x:329: warning: failed .so request input in flex scanner failed And then only part of the page is displayed. Meanwhile, zcat /usr/X11R6/man/man3/XmString.3x.gz | groff -Tascii -tmandoc - | less works perfectly. If anyone have any idea on how to fix that, I would be very obliged. I can send the example of the problem page, if needed. Thanks a lot. Alex Y. -- _ _( )_ ( (o___ +---+ | _ 7 |Alexander Yukhimets| \()| http://pages.nyu.edu/~aqy6633/ | / \ \ +---+ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: man-db ocassionally needs to be re-installed.
This is a little off-topic, but related to man-pages, too. My problem is that - when running man -a as I always do - I often get to see man pages multiple times. See this as an example: ~man -w rename /usr/man/man2/rename.2.gz /var/catman/cat2/rename.2.gz /usr/man/man3/rename.3tcl.gz /var/catman/cat3/rename.3tcl.gz /usr/man/man3/rename.3tcl.gz /var/catman/cat3/rename.3tcl.gz /usr/man/man3/rename.3tcl.gz /var/catman/cat3/rename.3tcl.gz I don't know when this started to happen, and I have no idea what has gone wrong. For example, I never anything in manpath.config A trimmed down output of dpkg -l '*man*' is here: pn man none (no description available) un man-aeb none (no description available) un man-browser none (no description available) ii man-db 2.3.10-38 Display the on-line manual. ii manpages1.15-4 Section 2, 3, 4, 5 and 7 manpages pn manpages-de none (no description available) pn manpages-es none (no description available) pn manpages-fr none (no description available) pn manpages-it none (no description available) Hm, now this is funny, since I do have (some) german manpages. Oh, boy, this confuses me. HELP! :-) Maybe, the contents (without comments) of manpath.config will help: # man_db.config MANDATORY_MANPATH /usr/man MANDATORY_MANPATH /usr/X11R6/man MANDATORY_MANPATH /usr/local/man MANPATH_MAP /bin/usr/man MANPATH_MAP /usr/bin/usr/man MANPATH_MAP /sbin /usr/man MANPATH_MAP /usr/sbin /usr/man MANPATH_MAP /usr/local/bin /usr/local/man MANPATH_MAP /usr/local/sbin /usr/local/man MANPATH_MAP /usr/local/bin/X11 /usr/local/man MANPATH_MAP /usr/X11R6/bin /usr/X11R6/man MANPATH_MAP /usr/games /usr/man MANDB_MAP /usr/man/de_DE /var/catman/de_DE MANDB_MAP /usr/man/it_IT /var/catman/it_IT MANDB_MAP /usr/man/var/catman MANDB_MAP /usr/local/man /var/catman/local MANDB_MAP /usr/X11R6/man /var/catman/X11R6 Thanks a lot in advance, Andy. Andy Spiegl, University of Technology, Muenchen, Germany E-Mail: [EMAIL PROTECTED] OR: [EMAIL PROTECTED] URL:http://www.appl-math.tu-muenchen.de/~spiegl PGP fingerprint: B8 48 24 7B DB 96 6F 1C D9 6D 8E 6C DB C2 E7 E9 o _ _ _ - __o __o /\_ _ \\o (_)\__/o (_) --- _`\,__`\,__(_) (_)/_\_| \ _|/' \/ -- (_)/ (_) (_)/ (_) (_)(_) (_)(_)' _\o_ ~~~ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: man-db ocassionally needs to be re-installed.
Andy Spiegl wrote: This is a little off-topic, but related to man-pages, too. My problem is that - when running man -a as I always do - I often get to see man pages multiple times. Yes, and if you skip one choosing Ctrl-D its entry disappear from the next run (and from the whatis database). All are known problems, fixed in the latests versions. I've built bo (aka for Debian 1.3) version numbered 42-51, while the hamm are numbered 52 . Latest ( -44 ) went installed just yesterday into: project/experimental/man-db_2.3.10-44_i386.deb You can have the .deb binary also from ftp://ftp.icenet.fi/private/fpolacco/debian/libc5 FYI, here is a list of recent changes (post -38 in 1.3.1), from the changelog file (in reverse order, recent on top): * avoided bashism in debian/rules. * deleted bogus files with spaces embedded in name (#13888) * applied patch for alpha by [EMAIL PROTECTED] #13851 * zsoelim.l - added new start condition to avoid expansion of .so requests inside a macro definition. (fixes #2969 and #13812) * added quote around var in mkcatdirs (fixes #13738, tx M.Konarski) * added removal of tempfiles from handler for SIGINT (fixes bug#13352 Thanks to John Goerzen) * changed way to call groff adding -P-g so grops can guess a page size (fixes #13563 uncorrectly assigned to groff, thx John Kallal) * solved deletion of entries in index when skipping their display (#10483) * wiped wrong message displayed when skipping display of manpage. * avoided redundant searches for section names longer than one char. * Added removal of tempfiles via atexit(). * restored original order in search sections (3 before 2) changed by previous maintainer (don't know why) (#12192 thx Juan Cespedes) * redirecting unusefull error messages in postrm and preinst (#12224) * doesn't provide gencat anymore, but can't use libc6's gencat. (#9841) * Changed tests in postinst to work with ash (#12212 thx Herbert Xu) * Changed define of debian version for use in non-debian systems (thanx to Albert Chin-A-Young); added file include/version.h * (Italian version) Minori correzioni a mandb.m da parte di Borto. * several corrections to it's = its typos in manpages [man(1), manpath(1), zsoelim(1), mandb(8)] Fixes Bug#11440 thanx to David Damerell. * Restore correct NAMN swedish parse for whatis (bug introduced by me fixing #6497 on version -34) Thanx to John F. Bunch. (fixes #12069) * Fixed segfault using an empty arg to -S option (Bug#12074, Thx Herbert Thielen) * Fixed wrong manpath behaviour (Bug#10377, Thanx to Michael Lachmann) * reduced output in postinst (Bug#11902). * included execution of chmanconfig (which adds MANDB_MAP lines for lang manpages) inside mkcatdirs (which creates catdir hierarchies). * added debian version info to option -V * corrected a couple of italian messages that didn't work (Grazie Borto) * added nlsutils in Replaces: field of control file (fixes Bug#9943) * Ugly typo in debian/rules that made .dwww-index disappear from last version (-38): my fault! (sigh) (autoBug#10130) * dropped scan of current directory if explicitly present in PATH both as an empty entry or an explicit dot; this used to left index files here and there. (fixes Bug#10039, thanks to Giuliano Procida) * allowed non man dirs if in manpath.config (now accepts manpages hierarchies like /usr/share/ucbman) fixes Bug#9947, thanks to Richard Kettlewell. Cheers, Fabrizio -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: man-db ocassionally needs to be re-installed.
[EMAIL PROTECTED] wrote: Monthly, or more often, since installing Bo 1.3 on new system, I have had to re-install man-db, after getting segmentation faults whenever executing man. I don't believe this is related to libc6, as has been reported. It happens at almost random times. Perhaps certain package upgrades have caused this? Or is it bit rot? I have found that when man seg faults, I only have to run /var/lib/dpkg/info/man-db.postinst, and everything as fine again. Actually, you only have to run mandb (as root, I think), and it fixes the problem. You might want to refer to bug reports #10483, #11278, etc at http://www.debian.org/Bugs/db/pa/lman-db.html - the maintainer is aware of the problem, and I hope he figures out a fix soon. -- see shy jo -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: man-db ocassionally needs to be re-installed.
Joey Hess wrote: You might want to refer to bug reports #10483, #11278, etc at http://www.debian.org/Bugs/db/pa/lman-db.html - the maintainer is aware of the problem, and I hope he figures out a fix soon. I have all the reports, but I wasn't able to reproduce the problem in any way. I've prepared an unstripped executable that could permit you to debug the core (or reproduce the segfault while in gdb) to help me figure what's the problem. It's in ftp://ftp.icenet.fi/private/fpolacco/debian/temp/man.gz It looks that the problem is related to a corrupted database (thus rebuilding it with mandb -c fixes the problem), but it's not clear how the database went corrupted. The installation of other manpages could be the trigger because man tryes to upgrade the database when it notices a new manpage. The bug should be related with bad behaviour for unexpected input. Finding the manpage that produces this could help a lot. Fabrizio -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
man-db ocassionally needs to be re-installed.
Monthly, or more often, since installing Bo 1.3 on new system, I have had to re-install man-db, after getting segmentation faults whenever executing man. I don't believe this is related to libc6, as has been reported. It happens at almost random times. Perhaps certain package upgrades have caused this? Or is it bit rot? I have found that when man seg faults, I only have to run /var/lib/dpkg/info/man-db.postinst, and everything as fine again. Alan Davis -- I consider that the golden rule requires Alan E. Davis that if I like a program I must share itMarianas High School with other people who like it AAA196, Box 10001 Saipan, MP 96950 ---Richard StallmanNorthern Mariana Islands GMT+10 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
can't configure man-db, Long.pm missing
I've installed 1.3.1 on a small (40MB) partition on my laptop. I did the base install, exited immediately from dselect, and have used dpkg to install just the packages I feel I need to have a real OS available. Configuration of man-db fails for lack of Long.pm (which is _not_ on my system, although there are many other *.pm files scattered about). This is what I've added to base: +++-===-==- ii bsdmainutils3.2-0 More utilities from 4.4BSD-Lite. ii doc-debian 1.5-0 Debian Manual, FAQ and other documents ii doc-linux 97.03-1Linux FAQ, HOWTOs and mini-HOWTOs. ii gpm 1.10-6 General Purpose Mouse Interface ii groff 1.10-3 GNU troff text-formatting system. ii less321-2 A file pager program, similar to more(1) ii libg++272.7.2.1-8 The GNU C++ libraries (ELF version). ii libgpm1 1.10-6 General Purpose Mouse Library ii lrzsz 0.12b-1zmodem/ymodem/xmodem transfer package ii lynx2.7.1-1Text-mode WWW Browser iF man-db 2.3.10-38 Display the on-line manual. ii manpages1.15-4 Section 2, 3, 4, 5 and 7 manpages ii mc 3.5.17-1 Midnight Commander - A feature-rich full-scr ii minicom 1.75-2 Clone of the MS-DOS Telix communications p ii slang0.99.340.99.38-2 A C programming library for user interfaces Help??? Thanks. Cheers, Pann -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: can't configure man-db, Long.pm missing
Pann McCuaig [EMAIL PROTECTED] writes: I've installed 1.3.1 on a small (40MB) partition on my laptop. I did the base install, exited immediately from dselect, and have used dpkg to install just the packages I feel I need to have a real OS available. Configuration of man-db fails for lack of Long.pm (which is _not_ on my system, although there are many other *.pm files scattered about). Install perl. This has already been reported as a bug (#10658). -- James -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: man-db install script problem (chmanconfig)
Thank you, Christian. Yes, man-db's unspecified dependency on perl appears to be the problem. And so it seems, as BG Lim pointed out (thank you), that this is a small packaging bug. Thanks, folks. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: man-db install script problem (chmanconfig)
On Jun 19, John M. Rulnick wrote Checking for languages ... de_DECan't locate Getopt/Long.pm in @INC at /usr/sbin/chmanconfig line 38. Hi, did you install perl ? Or did you stick with the perl which comes with the installation disks and didn't install the rest of perl ? I have dpkg -s perl Package: perl Status: install ok installed Priority: important Section: interpreters Installed-Size: 5399 Maintainer: Darren Stalder [EMAIL PROTECTED] Version: 5.003.07-10 Replaces: io Provides: io Pre-Depends: ldso (= 1.8.0-0), libc5 (= 5.4.0-0), libdb1, libgdbm1 Suggests: perl-suid, perl-debug Conflicts: io and it did succeed installing man-db. Greetings, Christian -- Christian Meder, email: [EMAIL PROTECTED] What's the railroad to me ? I never go to see Where it ends. It fills a few hollows, And makes banks for the swallows, It sets the sand a-blowing, And the blackberries a-growing. (Henry David Thoreau) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: man-db install script problem (chmanconfig)
The problem is that the script needs Long.pm, which (I think), is a Perl script. Install Perl from interpreters and it should be fine. I think this is a bug, because perl is big and not many people esp newbies want it or need it, just to install man, which shoudl be the first thing any newbie installs. I emailed the maintainer but has not got a response. BG -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
man-db install script problem (chmanconfig)
Summary of problem: -- Installation of the current (bo/1.3) man package fails. In particular, with a fresh install of Debian 1.3, both dpkg -i man-db_2.3.10-38.deb and dpkg -i man-db_2.3.10-39.deb yield failed configuration due to failure of /usr/sbin/chmanconfig. Problem details: --- The output of 'dpkg -i man-db_2.3.10-39.deb' ends with: ... Manual page hierarchy: /usr/X11R6/man Cat page hierarchy: /var/catman/X11R6 Cat sections:cat1 cat3 cat5 install /var/catman/X11R6/cat1 /var/catman/X11R6/cat3 /var/catman/X11R6/cat5 Checking for languages ... de_DECan't locate Getopt/Long.pm in @INC at /usr/sbin/chmanconfig line 38. BEGIN failed--compilation aborted at /usr/sbin/chmanconfig line 38. dpkg: error processing man-db (--install): subprocess post-installation script returned error exit status 2 Errors were encountered while processing: man-db I find no mention of this on the user mailing list archives of May or June. All ideas and suggestions are welcome. Thank you. John -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
