Bug#881904: xul-ext-useragentswitcher: does not work with modern versions of Firefox
Package: xul-ext-useragentswitcher Version: 0.7.3-3 Severity: grave Justification: renders package unusable This Firefox addon has not been updated in six years, and does not work with any version of Firefox available in the current release, even those prior to v57. This package is therefore useless, in its current form. Please replace it with one of the following: https://addons.mozilla.org/en-US/firefox/addon/user-agent-switcher-revived/ https://addons.mozilla.org/en-US/firefox/addon/custom-user-agent-revived/ -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xul-ext-useragentswitcher depends on: ii firefox 57.0-1 xul-ext-useragentswitcher recommends no packages. xul-ext-useragentswitcher suggests no packages. -- no debconf information
Bug#779544: phppgadmin: apache config needs "mod_dir" enabled
Package: phppgadmin Version: 5.1-1.1 Severity: critical Justification: breaks unrelated software Installing phppgadmin breaks the Apache webserver: # /etc/init.d/apache2 start [] Starting apache2 (via systemctl): apache2.serviceJob for apache2.service failed. See 'systemctl status apache2.service' and 'journalctl -xn' for details. failed! # # systemctl -l status apache2.service + apache2.service - LSB: Apache2 web server Loaded: loaded (/etc/init.d/apache2) Active: failed (Result: exit-code) since Sun 2015-03-01 20:15:35 PST; 13s ago Process: 15301 ExecStop=/etc/init.d/apache2 stop (code=exited, status=0/SUCCESS) Process: 15591 ExecStart=/etc/init.d/apache2 start (code=exited, status=1/FAILURE) Mar 01 20:15:35 quadlie apache2[15591]: Starting web server: apache2 failed! Mar 01 20:15:35 quadlie apache2[15591]: The apache2 configtest failed. ... (warning). Mar 01 20:15:35 quadlie apache2[15591]: Output of config test was: Mar 01 20:15:35 quadlie apache2[15591]: AH00526: Syntax error on line 5 of /etc/apache2/conf-enabled/phppgadmin.conf: Mar 01 20:15:35 quadlie apache2[15591]: Invalid command 'DirectoryIndex', perhaps misspelled or defined by a module not included in the server configuration Mar 01 20:15:35 quadlie apache2[15591]: Action 'configtest' failed. Mar 01 20:15:35 quadlie apache2[15591]: The Apache error log may have more information. Mar 01 20:15:35 quadlie systemd[1]: apache2.service: control process exited, code=exited status=1 Mar 01 20:15:35 quadlie systemd[1]: Failed to start LSB: Apache2 web server. Mar 01 20:15:35 quadlie systemd[1]: Unit apache2.service entered failed state. It appears that "mod_dir" needs to be enabled: http://httpd.apache.org/docs/2.4/mod/mod_dir.html#directoryindex You could do this manually, but shouldn't it happen automatically? -- System Information: Debian Release: 7.1 APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages phppgadmin depends on: ii libapache2-mod-php5 5.6.5+dfsg-2 ii libjs-jquery 1.7.2+dfsg-3 ii php5-pgsql 5.6.5+dfsg-2 Versions of packages phppgadmin recommends: ii apache2 [httpd] 2.4.10-9 ii postgresql-doc 9.4+165 Versions of packages phppgadmin suggests: ii postgresql 9.4+165 pn slony1-bin -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675016: ifupdown: don't use PPP updetach option by default
Package: ifupdown Version: 0.7~rc3 Severity: critical Justification: breaks the whole system I have specified this bug as "critical/breaks the whole system", because its effect is that if an external PPP link does not come up for some reason, the system boot fails. It actually gets wedged so hard that you cannot even boot into recovery mode to fix it; the problem can only be resolved with a rescue disk. This is completely unacceptable. According to the ifupdown package changelog, as of version 0.7~alpha4, "ifup -a" will use the "updetach" option for PPP interfaces. This may be an attempt to address the problem described in #127786, #287173, and #347594, wherein it is implied that other boot scripts which depend on the PPP link should be able to rely on it being up by the time they are run. This fails for two reasons. First, the termination of "pppd updetach" does not by any means guarantee that the PPP link is up, only that the attempt was made. It might have timed out and then failed, so other boot processes must be prepared to deal with that contingency anyway. Second, PPP links can go up and down depending on conditions on external WAN links and telephone lines, which are not in any way controllable by the local system or its human administrators. For maximum resiliency, it therefore makes sense to specify the PPP options "persist maxfail 0" in /etc/network/interfaces, so that if the link does not come up on boot, or goes down later, the PPP daemon will keep retrying indefinitely until it does come up. Unfortunately, the combination of these options, a broken WAN link, and the "updetach" option now baked into the ifup binary result in an unbootable system, which cannot even be gotten into recovery mode. This is unacceptable. It is quite inappropriate for "updetach" to be hard-wired into a binary executable, where it can only be removed with a hex editor. However, the patch for #196877, where this change is made, provides another solution to the network dependency problem: "Allow passing PPP options" (presumably in /etc/network/interfaces). If anybody wishes to have the "updetach" behavior, let them specify it there, without forcing it on other installations where it is quite possibly fatal. Suggestion for further work on network dependencies at boot: perhaps this is better handled in a general way for any type of network interface, through hotplug or udev, or something like that? What happens if /etc/network/interfaces specifies "auto eth0/iface eth0 inet dhcp", and the DHCP server is not responding for some reason? Does this also result in a boot failure? Is this not exactly analogous to the PPP situation described above? There seems to be some discussion of these issues in #245642. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ifupdown depends on: ii dpkg 1.16.3 ii initscripts 2.88dsf-22.1 ii iproute 20120105-1 ii libc62.13-32 ii lsb-base 3.2-28 ifupdown recommends no packages. Versions of packages ifupdown suggests: pn isc-dhcp-client [dhcp-client] 4.2.2.dfsg.1-5 pn net-tools 1.60-23 pn ppp2.4.5-5.1 pn rdnssd -- no debconf information -- debsums errors found: debsums: changed file /sbin/ifdown (from ifupdown package) debsums: changed file /sbin/ifquery (from ifupdown package) debsums: changed file /sbin/ifup (from ifupdown package) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#495049: grub-pc: does not boot because module "normal" is not loaded
Package: grub-pc
Version: 1.96+20080724-7
Severity: critical
Justification: breaks the whole system
I installed grub because lilo wouldn't boot any more.
My root fs is on lvm; I don't know if this is related.
After running "grub-install" and rebooting, grub drops into the
"grub rescue>" prompt. The "pc", "lvm", and "ext2" modules are loaded,
"ls" finds the root volume, and the variable "root" is set
appropriately.
Investigation shows that if the following commands are issued:
insmod normal
normal
-- then the boot menu specified by "grub.cfg" appears, and the system
boots properly. It turns out that the file "core.img" does not contain
the string "normal".
It seems like this problem should be easy to fix.
-- Package-specific info:
*** BEGIN /proc/mounts
/dev/mapper/volume11-root / ext3 rw,errors=remount-ro,data=ordered 0 0
/dev/mapper/volume11-root /dev/.static/dev ext3
ro,errors=remount-ro,data=ordered 0 0
/dev/mapper/volume11-home /home ext3 rw,errors=continue,data=ordered 0 0
/dev/mapper/volume11-usr /usr ext3 rw,errors=continue,data=ordered 0 0
/dev/mapper/volume11-var /var ext3 rw,errors=continue,data=ordered 0 0
/dev/mapper/volume11-work /work ext3 rw,errors=continue,data=ordered 0 0
*** END /proc/mounts
*** BEGIN /boot/grub/device.map
(hd0) /dev/sda
(volume11-root) /dev/mapper/volume11-root
*** END /boot/grub/device.map
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by /usr/sbin/update-grub using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
set default=0
set timeout=5
insmod lvm
set root=(volume11-usr)
search --fs-uuid --set b2a61cc9-be9a-43a2-9ca6-900dc4e01ea1
if font /share/grub/ascii.pff ; then
set gfxmode=640x480
insmod gfxterm
insmod vbe
terminal gfxterm
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_hurd ###
### END /etc/grub.d/10_hurd ###
### BEGIN /etc/grub.d/10_linux ###
insmod lvm
set root=(volume11-root)
search --fs-uuid --set cbcda803-4997-4932-bd61-f8bd0a168859
menuentry "Debian GNU/Linux, linux 2.6.26-1-amd64" {
linux /boot/vmlinuz-2.6.26-1-amd64 root=/dev/mapper/volume11-root ro
initrd /boot/initrd.img-2.6.26-1-amd64
}
menuentry "Debian GNU/Linux, linux 2.6.26-1-amd64 (single-user mode)" {
linux /boot/vmlinuz-2.6.26-1-amd64 root=/dev/mapper/volume11-root ro
single
initrd /boot/initrd.img-2.6.26-1-amd64
}
menuentry "Debian GNU/Linux, linux 2.6.25-2-amd64" {
linux /boot/vmlinuz-2.6.25-2-amd64 root=/dev/mapper/volume11-root ro
initrd /boot/initrd.img-2.6.25-2-amd64
}
menuentry "Debian GNU/Linux, linux 2.6.25-2-amd64 (single-user mode)" {
linux /boot/vmlinuz-2.6.25-2-amd64 root=/dev/mapper/volume11-root ro
single
initrd /boot/initrd.img-2.6.25-2-amd64
}
menuentry "Debian GNU/Linux, linux 2.6.18-6-amd64" {
linux /boot/vmlinuz-2.6.18-6-amd64 root=/dev/mapper/volume11-root ro
initrd /boot/initrd.img-2.6.18-6-amd64
}
menuentry "Debian GNU/Linux, linux 2.6.18-6-amd64 (single-user mode)" {
linux /boot/vmlinuz-2.6.18-6-amd64 root=/dev/mapper/volume11-root ro
single
initrd /boot/initrd.img-2.6.18-6-amd64
}
### END /etc/grub.d/10_linux ###
### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###
### BEGIN /etc/grub.d/40_custom ###
# This file is an example on how to add custom entries
### END /etc/grub.d/40_custom ###
*** END /boot/grub/grub.cfg
-- System Information:
Debian Release: lenny/sid
APT prefers stable
APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.26-1-amd64
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Versions of packages grub-pc depends on:
ii debconf [debconf-2.0]1.5.11etch2 Debian configuration management sy
ii grub-common 1.96+20080724-7 GRand Unified Bootloader, version
ii libc62.7-13 GNU C Library: Shared libraries
ii liblzo2-22.03-1 data compression library
ii libncurses5 5.6+20080713-1 shared libraries for terminal hand
grub-pc recommends no packages.
-- debconf information:
grub-pc/linux_cmdline: fillme
grub-pc/chainload_from_menu.lst: true
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#365134: confirmation of severe xdm bug
I'd like to confirm the seriousness of this bug. I have a pre-Xorg X-server, but I thought I would try upgrading xdm to see if that would fix some minor problems associated with "/etc/init.d/xdm restart". Instead, it broke the X-server completely. The original submitter is correct that xdm looks for some executables in the wrong places: # strings /usr/bin/xdm | grep usr /usr/bin/xrdb /usr/bin/xterm -ls /usr/bin/xterm /usr/lib/X11/xdm/chooser :0 local /usr/bin/X :0 /bin:/usr/bin:/usr/bin:/usr/ucb /etc:/bin:/usr/bin:/usr/bin:/usr/ucb /usr/lib/X11/xdm/libXdmGreet.so The file /etc/X11/xdm/Xservers has the same wrong location for the X-server binary. I was able to fix this with a few symlinks, but if I hadn't seen his report of what the problem was, I wouldn't have had a clue. # ls -l /usr/bin/X /usr/bin/xrdb lrwxrwxrwx 1 root root 5 2006-04-28 14:48 /usr/bin/X -> X11/X lrwxrwxrwx 1 root root 8 2006-04-28 14:48 /usr/bin/xrdb -> X11/xrdb In order to fix this reliably, why not give the PATH variable a reasonable value, and then let execlp() find the actual location of the executables? Either that, or have the xdm package create these same symlinks. As the original report says, it is also necessary to change the references in /etc/init.d/xdm and /etc/X11/default-display-manager from "/usr/bin/X11/xdm" to "/usr/bin/xdm". It's hard to see how this problem arose, because these files all come from the same package; there's no question of a version conflict. -- Ian Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343182: lilypond-data installation/removal is broken
Package: lilypond-data Bug #: 343182 I don't understand why this bug was closed. The explanation given makes no sense. Both installation and removal of this package require the file "/usr/bin/kpsewhich", which seems to come from either package "tetex-bin" or package "libkpathsea-perl". So either one of these packages needs to be listed as a Pre-Depends, or this command needs to be taken out of the installation/removal scripts. See also bug #325907, which reports the same problem, and points out that it constitutes a Debian Policy violation. Again, this bug has not been resolved, and should not have been closed. -- Ian Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
