Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On 15/05/2023 19:00, Simon McVittie wrote: > On Sun, 14 May 2023 at 23:37:34 +0200, Josh Triplett wrote: >> People build things on Debian that are not Debian packages. People >> compile binaries on Debian, and expect them to work on any system that >> has sufficiently new libraries. > > *raises hand* > > Hello, I represent an example of those people. With my $work hat on, > I'm involved in maintaining a family of Debian derivatives (the Steam > Runtime) that is used to run Steam games on arbitrary distributions, > including but not limited to Debian. Some of these binaries are built > on a Debian derivative, but run on an arbitrary other distribution, > using a RPATH[1] to find their non-glibc dependencies. As another much smaller example, which I hope is still relevant, I have taken binaries from Debian stable or oldstable armel and run them for diagnostic purposes on embedded boards which only have Busybox installed and for which I don't have a convenient build environment. Regards, Roger PS Apologies if I've followed up incorrectly - I read debian-devel through an NNTP gateway.
Bug#1021842: Finalizing 'inhibit-automatic-native-compilation'
On Mon, Feb 20, 2023, 4:34 PM Stefan Monnier wrote: > > Just to be clear, this condition should be checked before emacs is > > willing to use the temporary directory in question. No unprivileged > > user should be able to overwrite a directory entry the uid of the > > emacs process creates at any point in the path to the temporary file. > > AFAIK we usually consider it's up to the user/system to make sure this > is the case. That seems like a pretty aggressive assumption for this functionality. Lynn
Bug#1021842: Finalizing 'inhibit-automatic-native-compilation'
On Mon, Feb 20, 2023 at 11:02 AM Stefan Monnier wrote: > > So I guess one could remove the file after the first creation and make > > it a link pointing to some other file waiting for libgccjit to do > > its write. > > "One" as in "an attacker"? In `/tmp` an attacker should not be able to > do that because it's supposed to be using the sticky bit so that only > the owner of a file can remove it. Just to be clear, this condition should be checked before emacs is willing to use the temporary directory in question. No unprivileged user should be able to overwrite a directory entry the uid of the emacs process creates at any point in the path to the temporary file. Lynn
Bug#947771: unbound: cannot restart daemon under sysvinit-core when apparmor is enforced
Followup-For: Bug #947771 Package: unbound Version: 1.13.1-1 On Fri, 03 Jul 2020 19:27:17 +0900 Stephane Lapie wrote: I worked around this issue by adding --remove-pidfile to the "start-stop-daemon --stop" commands. On Thu, 28 Jan 2021 02:19:05 +0800 Gedalya wrote: - if start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE --name $NAME --retry 5; then + if start-stop-daemon --stop --quiet --oknodo --remove-pidfile --pidfile $PIDFILE --name $NAME --retry 5; then Thank you, this fixed it for me. This bug would appear to be related to that described at https://github.com/NLnetLabs/unbound/issues/303 but that was apparently fixed in 1.13.0. Regards, Roger
Bug#992886: r8169: no dedicated PHY driver found for PHY ID 0xc1071002
On 05/09/2021 09:07, Salvatore Bonaccorso wrote: On Wed, Sep 01, 2021 at 10:59:19PM +0100, Roger Lynn wrote: On Wed, 25 Aug 2021 08:07:48 +0200 Heiner Kallweit wrote: > A number of Gigabyte boards from ~2009 have broken BIOS support, resulting in the PHY > reporting an invalid PHY ID. Realtek / Gigabyte don't release errata information, > therefore there's not much that can be done. In bugzilla.kernel.org you can find > workarounds that helped for some users, else use the r8168 driver. In https://bugzilla.kernel.org/show_bug.cgi?id=207203 it was suggested to enable the boot ROM in the BIOS and/or reinsert the r8169 kernel module. Neither of these worked for me. Fortunately the r8168-dkms package does work. Thank you for the suggestion, as I was not aware of this driver. According to the discussion, there is not something to patch on the kernel side and rather likely a BIOS bug. So closing the bug. The r8168-dkms package asks for bugs to be filed when it works but the in-kernel driver doesn't. I guess this bug already counts for that.
Bug#992378: /etc/apparmor.d/usr.sbin.cupsd: Prevents Let's Encrypt certificates from being used
On 06/09/2021 11:05, Didier 'OdyX' Raboud wrote: CUPS appears to already have access to everything in /etc/ssl/ on all systems, which is where I used to keep my CAcert certificates. This doesn't feel any different. You're absolutely right; that's convincing to me! Reopening, and will fix in the next upload. Excellent! Thank you.
Bug#993819: release-notes: Please document the removal of wicd
Package: release-notes Severity: important Hi, Please document the removal of wicd in Bullseye. This seems particularly dangerous if the upgrade is being done over a network connection being managed by wicd as it seems likely that the connection will be lost when wicd is removed (due to dependency problems). It would also be helpful if alternatives could be suggested. Thanks, Roger
Bug#992886: r8169: no dedicated PHY driver found for PHY ID 0xc1071002
On Wed, 25 Aug 2021 08:07:48 +0200 Heiner Kallweit wrote: A number of Gigabyte boards from ~2009 have broken BIOS support, resulting in the PHY reporting an invalid PHY ID. Realtek / Gigabyte don't release errata information, therefore there's not much that can be done. In bugzilla.kernel.org you can find workarounds that helped for some users, else use the r8168 driver. In https://bugzilla.kernel.org/show_bug.cgi?id=207203 it was suggested to enable the boot ROM in the BIOS and/or reinsert the r8169 kernel module. Neither of these worked for me. Fortunately the r8168-dkms package does work. Thank you for the suggestion, as I was not aware of this driver. Roger
Bug#992378: /etc/apparmor.d/usr.sbin.cupsd: Prevents Let's Encrypt certificates from being used
On 27/08/2021 14:33, Didier 'OdyX' Raboud wrote:> Control: tags -1 +wontfix Using Let's Encrypt is fine, allowed, and (apparently) working with CUPS, but as that's clearly not a default way of working for CUPS, I'd be _very_ reluctant to allow CUPS to access "all the Let's Encrypt certificates" on all systems it gets installed to. Furthermore, /etc/apparmor.d/usr.sbin.cupsd is a configuration file, freely modifiable by the local system administrator. In other words, imposing that a local system administrator needs to update that file to enable a specific type of certificates is reasonable. CUPS appears to already have access to everything in /etc/ssl/ on all systems, which is where I used to keep my CAcert certificates. This doesn't feel any different. On 29/08/2021 08:31, Didier 'OdyX' Raboud wrote: Le vendredi, 27 août 2021, 18.31:17 h CEST Roger Lynn a écrit : The documentation is definitely lacking - I've been trying to work out why my configuration broke since upgrading to Buster 3 months ago! Even with the loglevel set to "debug", the logs were utterly unhelpful. Let's Encrypt is the most popular source of signed certificates and the upstream documentation at https://www.cups.org/doc/encryption.html explicitly says: "CUPS also supports certificates created and managed by the popular Let's Encrypt certificate service, which are stored in the /etc/letsencrypt/live directory." Right. Where do you suggest this needed apparmor edition should be documented? README.Debian or cups-files.conf(5) seem appropriate. A mention in NEWS.Debian would have been useful, but it's probably a bit late for that now. Thanks, Roger
Bug#992378: /etc/apparmor.d/usr.sbin.cupsd: Prevents Let's Encrypt certificates from being used
The documentation is definitely lacking - I've been trying to work out why my configuration broke since upgrading to Buster 3 months ago! Even with the loglevel set to "debug", the logs were utterly unhelpful. Let's Encrypt is the most popular source of signed certificates and the upstream documentation at https://www.cups.org/doc/encryption.html explicitly says: "CUPS also supports certificates created and managed by the popular Let's Encrypt certificate service, which are stored in the /etc/letsencrypt/live directory."
Bug#992886: r8169: no dedicated PHY driver found for PHY ID 0xc1071002
Package: src:linux Version: 5.10.46-4 Severity: normal File: /lib/modules/5.10.0-8-amd64/kernel/drivers/net/ethernet/realtek/r8169.ko I've just upgraded this machine to Bullseye and it seems unable to load the ethernet driver: [6.548031] r8169 :02:00.0: can't disable ASPM; OS doesn't have ASPM control [6.566607] libphy: r8169: probed [6.566613] r8169 :02:00.0: no dedicated PHY driver found for PHY ID 0xc1071002, maybe realtek.ko needs to be added to initramfs? [6.590372] r8169: probe of :02:00.0 failed with error -49 [6.590412] r8169 :03:00.0: can't disable ASPM; OS doesn't have ASPM control [6.592984] libphy: r8169: probed [6.592987] r8169 :03:00.0: no dedicated PHY driver found for PHY ID 0xc1071002, maybe realtek.ko needs to be added to initramfs? [6.626342] r8169: probe of :03:00.0 failed with error -49 This is long after the filesystem has been mounted, so the initramfs should be irrelevant, but I tried adding the realtek and r8169 modules to the initramfs and the only difference was that the error was earlier in the boot sequence. The machine is 12 years old and has worked with every stable Debian release in that time. The old Buster kernel, 4.19.0-17-amd64, running with Bullseye reports: [ 10.604259] r8169 :02:00.0: can't disable ASPM; OS doesn't have ASPM control [ 10.616071] libphy: r8169: probed [ 10.616222] r8169 :02:00.0 eth0: RTL8168d/8111d, 00:24:1d:1e:99:33, XID 281000c0, IRQ 25 [ 10.616223] r8169 :02:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko] [ 10.616921] r8169 :03:00.0: can't disable ASPM; OS doesn't have ASPM control [ 10.619251] libphy: r8169: probed [ 10.619384] r8169 :03:00.0 eth1: RTL8168d/8111d, 00:24:1d:1e:99:31, XID 281000c0, IRQ 26 [ 10.619385] r8169 :03:00.0 eth1: jumbo features [frames: 9200 bytes, tx checksumming: ko] ... [ 17.134036] r8169 :02:00.0: firmware: direct-loading firmware rtl_nic/rtl8168d-1.fw [ 17.134559] Generic PHY r8169-200:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=r8169-200:00, irq=IGNORE) [ 17.285430] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 17.286173] Generic PHY r8169-300:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=r8169-300:00, irq=IGNORE) [ 17.437417] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready [ 20.009162] r8169 :02:00.0 eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 20.009180] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Thanks, Roger -- Package-specific info: ** Version: Linux version 5.10.0-8-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.46-4 (2021-08-03) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-8-amd64 root=UUID=cc5ea548-3370-40b7-b244-7fb88e5b310e ro radeon.dpm=1 quiet ** Not tainted ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: Gigabyte Technology Co., Ltd. product_name: GA-MA790FXT-UD5P product_version: chassis_vendor: Gigabyte Technology Co., Ltd. chassis_version: bios_vendor: Award Software International, Inc. bios_version: F8n board_vendor: Gigabyte Technology Co., Ltd. board_name: GA-MA790FXT-UD5P board_version: ** Loaded modules: udp_diag tcp_diag inet_diag cpufreq_userspace cpufreq_powersave cpufreq_conservative cpufreq_ondemand uinput it87 hwmon_vid loop msr i2c_dev snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio ax88179_178a usbnet snd_hda_codec_hdmi mii snd_hda_intel snd_intel_dspcfg soundwire_intel soundwire_generic_allocation snd_soc_core edac_mce_amd snd_compress soundwire_cadence kvm_amd snd_hda_codec ccp r8169 rng_core snd_hda_core kvm firewire_ohci firewire_core snd_hwdep wmi_bmof realtek soundwire_bus mdio_devres libphy sr_mod crc_itu_t irqbypass snd_pcm snd_timer cdrom pcspkr ohci_pci ohci_hcd ata_generic snd sg ehci_pci ehci_hcd sp5100_tco watchdog pata_atiixp usbcore acpi_cpufreq soundcore button usb_common wmi i2c_piix4 k10temp ext4 crc16 mbcache jbd2 crc32c_generic sd_mod t10_pi crc_t10dif crct10dif_generic crct10dif_common radeon i2c_algo_bit drm_kms_helper cec ahci ttm libahci libata drm evdev psmouse scsi_mod serio_raw ** Network interface configuration: *** /etc/network/interfaces: auto lo iface lo inet loopback allow-hotplug eth0 iface eth0 inet static address 192.168.0.3 netmask 255.255.255.0 network 192.168.0.0 broadcast 192.168.0.255 gateway 192.168.0.2 allow-hotplug eth1 iface eth1 inet static address 192.168.2.1 netmask 255.255.255.0 ** Network status: *** IP interfaces and addresses: 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forev
Bug#959949: sensord: not available in stable o testing
Package: sensord Version: 1:3.4.0-3+b1 Followup-For: Bug #959949 Hi, The last version of sensord still seems to work perfectly for logging temperatures. Is there any other package that will do this instead? Thanks, Roger -- System Information: Debian Release: 9.13 APT prefers oldoldstable APT policy: (500, 'oldoldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-16-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages sensord depends on: ii libc62.24-11+deb9u4 ii librrd8 1.6.0-1+b2 ii libsensors4 1:3.4.0-4 ii lm-sensors 1:3.4.0-4 ii lsb-base 9.20161125 sensord recommends no packages. Versions of packages sensord suggests: pn rrdtool -- no debconf information
Bug#992378: /etc/apparmor.d/usr.sbin.cupsd: Prevents Let's Encrypt certificates from being used
Package: cups-daemon Version: 2.3.3op2-3+deb11u1 Severity: normal File: /etc/apparmor.d/usr.sbin.cupsd Adding /etc/letsencrypt/archive/** r, seems to fix this. I only discovered what was causing the problem when I stumbled across https://askubuntu.com/questions/1079957 Thanks, Roger -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages cups-daemon depends on: ii adduser3.118 ii bc 1.07.1-2+b2 ii init-system-helpers1.60 ii libavahi-client3 0.8-5 ii libavahi-common3 0.8-5 ii libc6 2.31-13 ii libcups2 2.3.3op2-3+deb11u1 ii libdbus-1-31.12.20-2 ii libelogind0 [libsystemd0] 246.9.1-1+debian1 ii libgssapi-krb5-2 1.18.3-6 ii libpam0g 1.4.0-9 ii libpaper1 1.1.28+b1 ii lsb-base 11.1.0 ii procps 2:3.3.17-5 ii ssl-cert 1.1.0+nmu1 Versions of packages cups-daemon recommends: pn avahi-daemon pn colord pn cups-browsed pn ipp-usb Versions of packages cups-daemon suggests: ii cups 2.3.3op2-3+deb11u1 ii cups-bsd 2.3.3op2-3+deb11u1 ii cups-client2.3.3op2-3+deb11u1 ii cups-common2.3.3op2-3+deb11u1 ii cups-filters 1.28.7-1 pn cups-pdf ii cups-ppdc 2.3.3op2-3+deb11u1 ii cups-server-common 2.3.3op2-3+deb11u1 ii foomatic-db-compressed-ppds [foomatic-db] 20200820-1 ii ghostscript9.53.3~dfsg-7 ii poppler-utils 20.09.0-3.1 pn smbclient ii udev 247.3-6 -- Configuration Files: /etc/cups/cups-files.conf changed: CreateSelfSignedCerts no SystemGroup lpadmin LogFileGroup adm AccessLog /var/log/cups/access_log ErrorLog /var/log/cups/error_log PageLog /var/log/cups/page_log -- no debconf information
Bug#987316: Fwd: Re: Bug#987316: initscripts: tmpfs has wrong size
Sorry, I failed to send this to the bug. Resending... Forwarded Message Subject: Re: Bug#987316: initscripts: tmpfs has wrong size Date: Wed, 21 Apr 2021 22:11:12 +0100 From: Roger Lynn To: Thorsten Glaser On 21/04/2021 18:38, Thorsten Glaser wrote: • add “set -x” as first and “set +x” as last line to /lib/init/tmpfs.sh • perhaps also add “grep Total /proc/meminfo” in there for extra debugging • reboot with serial console, so we can actually capture all the debug messages I suspect one of the operations involved fails for you, or swap is initialised later. Hrm. Swap is apparently initialised later. There are three calls to that script recorded by bootlogd and on all of them SwapTotal is 0 kB. It then prints the lines for "Mounting local filesystems", "Activating swapfile swap, if any" and "Cleaning up temporary files". Do you still need the full debug output? Regards, Roger
Bug#987316: initscripts: tmpfs has wrong size
On 21/04/2021 16:56, Thorsten Glaser wrote: To “provide no value” you have to actually do… TMPFS_SIZE= … in /etc/defaults/tmpfs because the commented-out value is default. Perhaps rewording tmpfs(5) to say “If this is explicitly set to the empty string, the kernel default…” is in order? Thanks for the clarification. I think that reduces this bug to "Why is my tmpfs set to 20% of physical RAM rather than 20% of total virtual memory?" (And the rewording of the manual page would be nice too.) I've now tried uncommenting the default TMPFS_SIZE line, and that makes no difference. An empty value does give 50% of physical RAM, as expected based on Thorsten's explanation. Regards, Roger
Bug#232584: /usr/bin/svnserve: Need an init.d script?
On 06/04/2021 22:34, Roger Lynn wrote: I've written a new version of the script for Bullseye, based on Yubao Liu's version and the template in init-d-script(5). Attached should be the /etc/init.d/svnserve script and /etc/defaults/svnserve file. I am not an expert on scripting, but it seems to work. It still needs Yubao Liu's logrotate file. And... that version didn't handle restarts properly. Here is a another attempt... Regards, Roger #!/usr/bin/env /lib/init/init-d-script ### BEGIN INIT INFO # Provides: svnserve # Required-Start:$syslog $remote_fs $local_fs $network # Required-Stop: $syslog $remote_fs $local_fs $network # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: SVN server daemon service # Description: Debian init script to start the daemon #serving Subversion repositories. ### END INIT INFO DAEMON=/usr/bin/svnserve LOG_FILE=/var/log/svnserve.log START_ARGS="-c svn:svn" do_start_prepare() { DAEMON_ARGS="-d -T -r $REPOS_DIR --config-file=$CONFIG_FILE --log-file=$LOG_FILE $SVNSERVE_OPTIONS" if [ ! -f "$LOG_FILE" ]; then touch $LOG_FILE chown svn:adm $LOG_FILE chmod 640 $LOG_FILE fi } do_restart_prepare() { do_start_prepare }
Bug#987316: initscripts: tmpfs has wrong size
Package: initscripts Version: 2.96-6 Severity: normal X-Debbugs-Cc: ro...@rilynn.me.uk Hi, I think this bug is not the same as #688412 because /etc/fstab is NOT involved here. As shown in the configuration files below, I have configured RAMTMP with the default size settings. tmpfs(5) says: TMPFS_SIZE Maximum size for all tmpfs filesystems if no specific size is provided. The default is 20%VM (20% of virtual memory, includ‐ ing swap space). If no value is provided here, the kernel de‐ fault (50% RAM) will be used. I find this confusing, because the default in /etc/defaults/tmpfs is: #TMPFS_SIZE=20%VM Which is commented out, so presumably the default is for the kernel default to be used, which should give me 50 % or 2 GB of my 4 GB of RAM: $ free totalusedfree shared buff/cache available Mem: 396 264432 6665121524 3033500 3435280 Swap:8388604 19784 8368820 However my tmpfs is only 775 MB: $ df Filesystem 1K-blocks Used Available Use% Mounted on ... tmpfs 792880 0792880 0% /dev/shm ... tmpfs 792880 856792024 1% /tmp Which appears to be only 20 % of my physical RAM. Have I misunderstood something or is there a bug here? This is a recent Bullseye installation. Thanks, Roger -- System Information: Debian Release: bullseye/sid APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages initscripts depends on: ii lsb-base 11.1.0 ii sysv-rc 2.96-6 Versions of packages initscripts recommends: ii e2fsprogs 1.46.2-1 ii psmisc 23.4-2 initscripts suggests no packages. -- Configuration Files: /etc/default/tmpfs changed: RAMTMP=yes -- no debconf information
Bug#986493: /etc/init.d/ufw: init script does not depend on nftables
Package: ufw Version: 0.36-7.1 Severity: important File: /etc/init.d/ufw Justification: renders package unusable X-Debbugs-Cc: ro...@rilynn.me.uk Hi, ufw apparently depends on nftables but the init script does not declare it. This results in errors from ip-tables-restore when ufw starts: Starting firewall: ufw... iptables-restore v1.8.7 (nf_tables): line 42: CHAIN_USER_ADD failed (No such file or directory): chain ufw-before-logging-input line 42: CHAIN_USER_ADD failed (No such file or directory): chain ufw-before-logging-output line 42: CHAIN_USER_ADD failed (No such file or directory): chain ufw-before-logging-forward line 42: CHAIN_USER_ADD failed (No such file or directory): chain ufw-before-input line 42: CHAIN_USER_ADD failed (No such file or directory): chain ufw-before-output line 42: CHAIN_USER_ADD failed (No such file or directory): chain ufw-before-forward line 42: CHAIN_USER_ADD failed (No such file or directory): chain ufw-after-input line 42: CHAIN_USER_ADD failed (No such file or directory): chain ufw-after-output line 42: CHAIN_USER_ADD failed (No such file or directory): chain ufw-after-forward line 42: CHAIN_USER_ADD failed (No such file or directory): chain ufw-after-logging-input line 42: CHAIN_USER_ADD failed (No such file or directory): chain ufw-after-logging-output line 42: RULE_APPEND faied (No such file or directory): rule in iptables-restore: line 3 failed iptables-restore: line 3 failed iptables-restore: line 4 failed failed. startpar: service(s) returned failre:ufw ... failed! Adding "nftables" to the Required-Start: and Required-Stop: lines in /etc/init.d/ufw resolves the problem: # Required-Start:$local_fs nftables # Required-Stop: $local_fs nftables Thanks, Roger -- System Information: Debian Release: bullseye/sid APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages ufw depends on: ii debconf [debconf-2.0] 1.5.75 ii iptables 1.8.7-1 ii lsb-base 11.1.0 ii python33.9.2-2 ii ucf3.0043 ufw recommends no packages. Versions of packages ufw suggests: ii rsyslog 8.2102.0-2 -- Configuration Files: /etc/default/ufw changed: IPV6=yes DEFAULT_INPUT_POLICY="REJECT" DEFAULT_OUTPUT_POLICY="ACCEPT" DEFAULT_FORWARD_POLICY="REJECT" DEFAULT_APPLICATION_POLICY="SKIP" MANAGE_BUILTINS=no IPT_SYSCTL= IPT_MODULES="" /etc/init.d/ufw changed: set -e PATH="/sbin:/bin" [ -d /lib/ufw ] || exit 0 . /lib/lsb/init-functions for s in "/lib/ufw/ufw-init-functions" "/etc/ufw/ufw.conf" "/etc/default/ufw" ; do if [ -s "$s" ]; then . "$s" else log_failure_msg "Could not find $s (aborting)" exit 1 fi done error=0 case "$1" in start) if [ "$ENABLED" = "yes" ] || [ "$ENABLED" = "YES" ]; then log_action_begin_msg "Starting firewall:" "ufw" output=`ufw_start` || error="$?" if [ "$error" = "0" ]; then log_action_cont_msg "Setting kernel variables ($IPT_SYSCTL)" fi if [ ! -z "$output" ]; then echo "$output" | while read line ; do log_action_cont_msg "$line" done fi else log_action_begin_msg "Skip starting firewall:" "ufw (not enabled)" fi log_action_end_msg $error exit $error ;; stop) if [ "$ENABLED" = "yes" ] || [ "$ENABLED" = "YES" ]; then log_action_begin_msg "Stopping firewall:" "ufw" output=`ufw_stop` || error="$?" if [ ! -z "$output" ]; then log_action_cont_msg "$output" fi else log_action_begin_msg "Skip stopping firewall:" "ufw (not enabled)" fi log_action_end_msg $error exit $error ;; restart|force-reload) log_action_begin_msg "Reloading firewall:" "ufw" output=`ufw_reload` || error="$?" if [ ! -z "$output" ]; then log_action_cont_msg "$output" fi log_action_end_msg $error exit $error ;; status) output=`ufw_status` || error="$?" if [ ! -z "$output" ]; then log_action_cont_msg "$output" fi log_action_end_msg $error exit $error ;; *) echo "Usage: /etc/init.d/ufw {start|stop|restart|force-reload|status}" exit 1 ;; esac exit 0 -- debconf information: * ufw/enable: true * ufw/allow_known_ports: SSH ufw/allow_custom_ports: * ufw/existing_configuration:
Bug#232584: /usr/bin/svnserve: Need an init.d script?
Package: subversion Version: 1.14.1-3 Followup-For: Bug #232584 X-Debbugs-Cc: ro...@rilynn.me.uk I've written a new version of the script for Bullseye, based on Yubao Liu's version and the template in init-d-script(5). Attached should be the /etc/init.d/svnserve script and /etc/defaults/svnserve file. I am not an expert on scripting, but it seems to work. It still needs Yubao Liu's logrotate file. -- System Information: Debian Release: bullseye/sid APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages subversion depends on: ii libapr1 1.7.0-6 ii libaprutil1 1.6.1-5 ii libc62.31-11 ii libsvn1 1.14.1-3 subversion recommends no packages. Versions of packages subversion suggests: ii db5.3-util 5.3.28+dfsg1-0.8 pn libapache2-mod-svn ii patch 2.7.6-7 ii subversion-tools1.14.1-3 -- no debconf information #!/usr/bin/env /lib/init/init-d-script ### BEGIN INIT INFO # Provides: svnserve # Required-Start:$syslog $remote_fs $local_fs $network # Required-Stop: $syslog $remote_fs $local_fs $network # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: SVN server daemon service # Description: Debian init script to start the daemon #serving Subversion repositories. ### END INIT INFO DAEMON=/usr/bin/svnserve LOG_FILE=/var/log/svnserve.log START_ARGS="-c svn:svn" do_start_prepare() { DAEMON_ARGS="-d -T -r $REPOS_DIR --config-file=$CONFIG_FILE --log-file=$LOG_FILE $SVNSERVE_OPTIONS" if [ ! -f "$LOG_FILE" ]; then touch $LOG_FILE chown svn:adm $LOG_FILE chmod 640 $LOG_FILE fi } REPOS_DIR=/srv/svn/repositories CONFIG_FILE=/srv/svn/svnserve.conf SVNSERVE_OPTIONS=""
Bug#986482: /usr/bin/svnserve: Need an init.d script?
Package: subversion Version: 1.14.1-3 Followup-For: Bug #232584 I've written a new version of the script for Bullseye, based on Yubao Liu's version and the template in init-d-script(5). Attached should be the init script and defaults file. I am not an expert on scripting, but it seems to work. -- System Information: Debian Release: bullseye/sid APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages subversion depends on: ii libapr1 1.7.0-6 ii libaprutil1 1.6.1-5 ii libc62.31-11 ii libsvn1 1.14.1-3 subversion recommends no packages. Versions of packages subversion suggests: ii db5.3-util 5.3.28+dfsg1-0.8 pn libapache2-mod-svn ii patch 2.7.6-7 ii subversion-tools1.14.1-3 -- no debconf information #!/usr/bin/env /lib/init/init-d-script ### BEGIN INIT INFO # Provides: svnserve # Required-Start:$syslog $remote_fs $local_fs $network # Required-Stop: $syslog $remote_fs $local_fs $network # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: SVN server daemon service # Description: Debian init script to start the daemon #serving Subversion repositories. ### END INIT INFO DAEMON=/usr/bin/svnserve LOG_FILE=/var/log/svnserve.log START_ARGS="-c svn:svn" do_start_prepare() { DAEMON_ARGS="-d -T -r $REPOS_DIR --config-file=$CONFIG_FILE --log-file=$LOG_FILE $SVNSERVE_OPTIONS" if [ ! -f "$LOG_FILE" ]; then touch $LOG_FILE chown svn:adm $LOG_FILE chmod 640 $LOG_FILE fi } REPOS_DIR=/srv/svn/repositories CONFIG_FILE=/srv/svn/svnserve.conf SVNSERVE_OPTIONS=""
Bug#691407: closed by Christian Göttsche (Re: logrotate(8) does not mention all reasons for ignoring included files)
On 10/09/2019 17:05, Christian Göttsche wrote: To better document this in the man page, I created https://github.com/logrotate/logrotate/pull/265 Thank you. Also must not be group writeable. This is what caught me out (making the file group writeable in the first place was an accident). Roger
Bug#691407: closed by Christian Göttsche (Re: logrotate(8) does not mention all reasons for ignoring included files)
On 08/09/19 16:48, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the logrotate package: #691407: logrotate(8) does not mention all reasons for ignoring included files It has been closed by Christian Göttsche . Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Christian Göttsche by replying to this email. Subject: Re: logrotate(8) does not mention all reasons for ignoring included files From: Christian Göttsche Date: 08/09/19 17:45 +0200 To: 691407-d...@bugs.debian.org To: 691407-d...@bugs.debian.org Closing due to no response. No response due to not being copied on the email in question! In the BTS, I see that on Wed, 22 Aug 2018 22:54:02 +0200, Christian Göttsche apparently wrote: Control: tags -1 moreinfo unreproducible Hi, by some unspecified "bad" file modes, which include being group writeable. do you mean configuration files or log files? In my tests logrotate does rotate logs which are group writeable and errors out when a configuration file has insecure permissions. I don't remember filing this bug seven years ago, but the section of the man page quoted in the original report was clearly referring to configuration files. You have reproduced the error, which was a result of a requirement which I could not find in the the man page. If this bug is unreproducible, does that mean you were able to find where in the man page this is documented? Having left cron to run overnight with an erroneous logrotate.d file I see that an error is now reported without needing to resort to adding "-v" to various scripts: "error: Ignoring vsftpd because of bad file mode - must be 0644 or 0444." and it now states what the file mode requirements are, which it did not before. As a result it would probably be reasonable to downgrade this bug to minor severity. Previously no error was reported when the script was run by cron, when "-v" was added to logrotate the error message given did not state what was wrong with the file mode and this requirement is not mentioned in the man page. This made it difficult to work out why logrotate was not working. Regards, Roger
Bug#918824: distributed-net: logorate scipt attempts to call unimplemented "reload" target in /etc/init.d/distributed-net
Package: distributed-net Version: 2.9112.521-1 Severity: normal Hi, Every week, distributed-net causes the following email to be sent: /etc/cron.daily/logrotate: /etc/init.d/distributed-net: 165: /etc/init.d/distributed-net: 3: Bad file descriptor invoke-rc.d: initscript distributed-net, action "reload" failed. error: error running non-shared postrotate script for /var/log/distributed-net.log of '/var/log/distributed-net.log ' run-parts: /etc/cron.daily/logrotate exited with return code 1 There are a couple of reasons for this. The first is that /etc/logrotate.d/distributed-net contains the line "invoke-rc.d distributed-net reload >/dev/null", but "reload" is not implemented in /etc/init.d/distributed-net, despite that script's usage message claiming that it is. The other reason is that when called with an unrecognised parameter, /etc/logrotate.d/distributed-net attempts to run line 165: "echo "Usage: $SCRIPTNAME {start|stop|status|restart|reload|force-reload|fetch|flush|update}" >&3", but file descriptor 3 does not exist. I presume that it's trying to redirect to stderr and that the >&3 should be >&2. Also the string claims that "reload" is a valid parameter, which it isn't. Thanks, Roger -- System Information: Debian Release: 9.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages distributed-net depends on: ii bind9-host [host] 1:9.10.3.dfsg.P4-12.3+deb9u4 ii debconf [debconf-2.0] 1.5.61 ii libc6 2.24-11+deb9u3 Versions of packages distributed-net recommends: ii logrotate 3.11.0-0.1 Versions of packages distributed-net suggests: ii acpid 1:2.0.28-1+b1 pn apmd -- debconf information: * distributed-net/fullconfig: false
Bug#712564: spamassassin: Add feature to run spamassassin as debian-spamd user
On 14/12/2018 12:35, Christian Weiske wrote: When spamassassin is running in daemon mode (spamd) as root, the default behaviour is to setuid to the user running spamc. This lets spamd to load and examine the per-user configuration files as the user. So by default, the effective UID is sent to spamd from spamc. This is only necessary when you have a 1:1 mapping between email recipients and users on the system, and not at all useful when there is a virtual user setup via database or MySQL. Even if you are in a non-virtual setup, the question is if users really use their own configuration files for spamassassin, or if they rather rely on the admin to configure SA correctly. This. exim connects to spamd at SMTP time, when there might be several local recipients, so there is no single local user to run spamd as. And I don't expect each of my users to set up their own spamassassin configuration. If the main usage scenario of spamassassin on debian installations is virtual user databases, then the default could be changed to let spamd run the children as debian-spamd. I adjusted /etc/default/spamassassin and ajusted OPTIONS: OPTIONS="--username=debian-spamd --group debian-spamd ..." I have always added "-u debian-spamd" to all my spamassassin installations, and now I'm wondering if I need to add --group too, but it appears to be unnecessary. Regards, Roger
Bug#880047: postgrey: Regression - Postgrey doesn't start after installing new stable proposed-update
On 08/11/18 19:34, Adrian Bunk wrote: Tanks a lot for trying stretch-proposed-updates and reproting bugs you find! This is a regression that is also in 1.36-5 in unstable. The proposed 1.36-3+deb9u1 update has now been dropped from the upcoming stretch point release. Thank you for your work on this package. I think the reason my system was badly affected by the new release is because I had used the example unix socket location given in /usr/share/doc/postgrey/README.exim, which conflicted with the new directory created in the init script (although to be fair, the README does warn that the socket location might need to be changed). Regards, Roger
Bug#880047: postgrey: Regression - Postgrey doesn't start after installing new stable proposed-update
Package: postgrey Version: 1.36-3+deb9u1 Followup-For: Bug #880047 On a Stable system installed about a year ago, Postgrey 1.36-3 has always run fine. When installing 1.36-3+deb9u1 I get: Setting up postgrey (1.36-3+deb9u1) ... Installing new version of config file /etc/init.d/postgrey ... [] Starting postfix greylisting daemon: postgreymkdir: cannot create directory ‘/var/run/postgrey/’: File exists invoke-rc.d: initscript postgrey, action "start" failed. # /etc/init.d/postgrey stop [] Stopping postfix greylisting daemon: postgreystart-stop-daemon: unable to open pidfile /var/run/postgrey/postgrey.pid (Not a directory) # /etc/init.d/postgrey start [] Starting postfix greylisting daemon: postgreymkdir: cannot create directory ‘/var/run/postgrey/’: File exists $ ls -al /var/run/postgrey srw-rw-rw- 1 postgrey postgrey 0 Oct 27 23:14 /var/run/postgrey After deleting /var/run/postgrey Postgrey will start, although subsequent restarts give: # /etc/init.d/postgrey start [] Starting postfix greylisting daemon: postgreyPid_file "/var/run/postgrey/postgrey.pid" already exists. Overwriting! . ok Thanks, Roger -- System Information: Debian Release: 9.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages postgrey depends on: ii adduser3.115 ii debconf [debconf-2.0] 1.5.61 ii libberkeleydb-perl 0.55-1+b2 ii libnet-dns-perl1.07-1 ii libnet-server-perl 2.008-3 ii libnetaddr-ip-perl 4.079+dfsg-1+b1 ii perl 5.24.1-3+deb9u4 ii ucf3.0036 Versions of packages postgrey recommends: ii exim4 4.89-2+deb9u3 ii libnet-rblclient-perl 0.5-3 ii libparse-syslog-perl 1.10-2 postgrey suggests no packages. -- debconf information: postgrey/1.32-3_changeport:
Bug#848690: related
On 20/04/18 18:46, Herman van Rink wrote: > This seems to be hitting more users... > > https://github.com/monitoring-plugins/monitoring-plugins/issues/1142 > > https://github.com/nagios-plugins/nagios-plugins/issues/329 > > https://bugs.launchpad.net/ubuntu/+source/nagios-plugins/+bug/1367791 > > > The addition of 'discard minimum 1' to ntp.conf ad Stuart suggests > resolves this. If the original report is accurate, the bug is in the Nagios plugin, so this bug is against the wrong package. Roger
Bug#892788: e2guardian: Please enable MITM Filtering HTTPS
Package: e2guardian Version: 3.4.0.3-2 Severity: wishlist Hi, Please configure and compile e2guardian with the --enable-sslmitm=yes flag set. Without this a content filter is not very useful on the modern internet. Thanks, Roger -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages e2guardian depends on: ii adduser 3.115 ii clamav 0.99.4+dfsg-1+deb9u1 ii libc6 2.24-11+deb9u3 ii libgcc1 1:6.3.0-18+deb9u1 ii libpcre32:8.39-3 ii libstdc++6 6.3.0-18+deb9u1 ii perl5.24.1-3+deb9u2 ii zlib1g 1:1.2.8.dfsg-5 e2guardian recommends no packages. Versions of packages e2guardian suggests: ii clamav-freshclam 0.99.4+dfsg-1+deb9u1 ii squid 3.5.23-5+deb9u1 -- Configuration Files: /etc/e2guardian/e2guardian.conf changed: languagedir = '/usr/share/e2guardian/languages' language = 'ukenglish' loglevel = 2 logexceptionhits = 2 logfileformat = 1 dstatlocation = '/var/log/e2guardian/dstats.log' filterip = 192.168.0.2 filterports = 8080 proxyip = 127.0.0.1 proxyport = 3128 proxytimeout = 20 proxyexchange = 20 pcontimeout = 55 usecustombannedimage = on custombannedimagefile = '/usr/share/e2guardian/transparent1x1.gif' usecustombannedflash = on custombannedflashfile = '/usr/share/e2guardian/blockedflash.swf' filtergroups = 1 filtergroupslist = '/etc/e2guardian/lists/filtergroupslist' bannediplist = '/etc/e2guardian/lists/bannediplist' exceptioniplist = '/etc/e2guardian/lists/exceptioniplist' showweightedfound = on urlcachenumber = 1000 urlcacheage = 900 scancleancache = on phrasefiltermode = 2 preservecase = 0 hexdecodecontent = off forcequicksearch = off reverseaddresslookups = on reverseclientiplookups = on logclienthostnames = on prefercachedlists = off maxcontentfiltersize = 1024 maxcontentramcachescansize = 16384 maxcontentfilecachescansize = 65536 filecachedir = '/tmp' deletedownloadedtempfiles = on initialtrickledelay = 20 trickledelay = 10 downloadmanager = '/etc/e2guardian/downloadmanagers/fancy.conf' downloadmanager = '/etc/e2guardian/downloadmanagers/default.conf' contentscanner = '/etc/e2guardian/contentscanners/clamdscan.conf' contentscannertimeout = 60 contentscanexceptions = off recheckreplacedurls = off forwardedfor = off usexforwardedfor = off logconnectionhandlingerrors = on logsslerrors = off logchildprocesshandling = off maxchildren = 180 minchildren = 20 minsparechildren = 16 preforkchildren = 10 maxsparechildren = 32 maxagechildren = 500 maxips = 0 ipcfilename = '/tmp/.e2guardianipc' urlipcfilename = '/tmp/.e2guardianurlipc' ipipcfilename = '/tmp/.e2guardianipipc' nodaemon = off nologger = off logadblocks = off loguseragent = off softrestart = off mailer = '/usr/sbin/sendmail -t' cacertificatepath = '/etc/e2guardian/ssl/my_rootCA.crt' caprivatekeypath = '/etc/e2guardian/ssl/private_root.pem' certprivatekeypath = '/etc/e2guardian/ssl/private_cert.pem' generatedcertpath = '/var/log/e2guardian/generatedcerts/' /etc/e2guardian/e2guardianf1.conf changed: groupmode = 1 groupname = '' bannedphraselist = '/etc/e2guardian/lists/bannedphraselist' weightedphraselist = '/etc/e2guardian/lists/weightedphraselist' exceptionphraselist = '/etc/e2guardian/lists/exceptionphraselist' bannedsitelist = '/etc/e2guardian/lists/bannedsitelist' greysitelist = '/etc/e2guardian/lists/greysitelist' bannedsslsitelist = '/etc/e2guardian/lists/bannedsslsitelist' greysslsitelist = '/etc/e2guardian/lists/greysslsitelist' exceptionsitelist = '/etc/e2guardian/lists/exceptionsitelist' bannedurllist = '/etc/e2guardian/lists/bannedurllist' greyurllist = '/etc/e2guardian/lists/greyurllist' exceptionurllist = '/etc/e2guardian/lists/exceptionurllist' exceptionregexpurllist = '/etc/e2guardian/lists/exceptionregexpurllist' bannedregexpurllist = '/etc/e2guardian/lists/bannedregexpurllist' picsfile = '/etc/e2guardian/lists/pics' contentregexplist = '/etc/e2guardian/lists/contentregexplist' urlregexplist = '/etc/e2guardian/lists/urlregexplist' refererexceptionsitelist = '/etc/e2guardian/lists/refererexceptionsitelist' refererexceptionurllist = '/etc/e2guardian/lists/refererexceptionurllist' embededreferersitelist = '/etc/e2guardian/lists/embededreferersitelist' embededrefererurllist = '/etc/e2guardian/lists/embededrefererurllist' urlredirectregexplist = '/etc/e2guardian/lists/urlredirectregexplist' !! Not compiled !! authexceptionsitelist = '/etc/e2guardian/lists/authexceptionsitelist' !! Not compiled !! authexceptionurllist = '/etc/e2guardian/lists/authexceptionurllist' blockdownloads = off exceptionextensionlist = '/etc/e2guardian/lists/exceptionextensionlist' exceptionmimetypelist = '/etc/e2guardian/lists/exceptionmimetypel
Bug#889487: linux-image-4.14.0-2-amd64: please enable CONFIG_X86_MCELOG_LEGACY
On 04/02/18 02:00, Jon DeVree wrote: > On Sun, Feb 04, 2018 at 01:03:59 +0100, Ben Hutchings wrote: >> This was unintentional, but I think it's correct. The Kconfig says to >> use rasdaemon which is already packaged and in stable. > > rasdaemon has a hard dependency on systemd, it isn't installable on > machines still running sysvinit. Yes it is installable. It depends on systemd, not systemd-sysv. systemd is co-installable with sysvinit-core. I have it installed on a Stretch sysvinit system (it then complains that it can't find a debugfs). > Not sure if thats a hard dep or if it only just means rasdaemon is > missing a sysvinit script. Roger
Bug#879462: plasma-desktop: xterm bell opens KDE Accessibility Tool confirmation dialog
Package: plasma-desktop Version: 4:5.8.6-1 Severity: normal Hi, Since upgrading from Jessie to Stretch, a bell in an xterm (commonly generated by tab completion or pressing ^G) always opens "Warning - KDE Accessibility Tool", which asks 'Do you really want to activate "Sticky keys" and "Mouse Keys"?' Selecting "Deactivate All AccessX Features & Gestures" and choosing "No" does not stop the dialog appearing again. In "Accessibility - System Settings", "Activation Gestures" tab, "Use gestures for activating sticky keys and slow keys" is turned off. This is also mentioned at https://unix.stackexchange.com/questions/246305/tab-in-xterm-under-kde-always-brings-up-accessibility-tool-dialog Thanks, Roger -- System Information: Debian Release: 9.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages plasma-desktop depends on: ii breeze 4:5.8.5-2 ii kactivitymanagerd5.8.4-1 ii kde-cli-tools4:5.8.4-2 ii kded55.28.0-1 ii kio 5.28.0-2 ii libc62.24-11+deb9u1 ii libcanberra0 0.30-3 ii libfontconfig1 2.11.0-6.7+b1 ii libgcc1 1:6.3.0-18 ii libkf5activities55.28.0-1 ii libkf5activitiesstats1 5.28.0-1 ii libkf5archive5 5.28.0-2 ii libkf5auth5 5.28.0-2 ii libkf5baloo5 5.28.0-2 ii libkf5bookmarks5 5.28.0-1 ii libkf5codecs55.28.0-1+b2 ii libkf5completion55.28.0-1 ii libkf5configcore55.28.0-2 ii libkf5configgui5 5.28.0-2 ii libkf5configwidgets5 5.28.0-2 ii libkf5coreaddons55.28.0-2 ii libkf5dbusaddons55.28.0-1 ii libkf5emoticons-bin 5.28.0-1 ii libkf5emoticons5 5.28.0-1 ii libkf5globalaccel5 5.28.0-1 ii libkf5guiaddons5 5.28.0-1 ii libkf5i18n5 5.28.0-2 ii libkf5iconthemes55.28.0-2 ii libkf5itemmodels55.28.0-2 ii libkf5itemviews5 5.28.0-1 ii libkf5jobwidgets55.28.0-2 ii libkf5kcmutils5 5.28.0-2 ii libkf5kdelibs4support5 5.28.0-1 ii libkf5kiocore5 5.28.0-2 ii libkf5kiofilewidgets55.28.0-2 ii libkf5kiowidgets55.28.0-2 ii libkf5newstuff5 5.28.0-1 ii libkf5notifications5 5.28.0-1 ii libkf5notifyconfig5 5.28.0-1 ii libkf5parts5 5.28.0-1 ii libkf5people55.28.0-1 ii libkf5peoplewidgets5 5.28.0-1 ii libkf5plasma55.28.0-2 ii libkf5plasmaquick5 5.28.0-2 ii libkf5quickaddons5 5.28.0-1 ii libkf5runner55.28.0-1 ii libkf5service-bin5.28.0-1 ii libkf5service5 5.28.0-1 ii libkf5solid5 5.28.0-3 ii libkf5sonnetui5 5.28.0-2 ii libkf5wallet-bin 5.28.0-3 ii libkf5wallet55.28.0-3 ii libkf5widgetsaddons5 5.28.0-3 ii libkf5windowsystem5 5.28.0-2 ii libkf5xmlgui55.28.0-1 ii libkfontinst54:5.8.6-1 ii libkfontinstui5 4:5.8.6-1 ii libkworkspace5-5 4:5.8.6-2.1 ii libpackagekitqt5-0 0.9.6-1 ii libphonon4qt5-4 4:4.9.0-4 ii libpulse-mainloop-glib0 10.0-1+deb9u1 ii libpulse010.0-1+deb9u1 ii libqt5concurrent55.7.1+dfsg-3+b1 ii libqt5core5a 5.7.1+dfsg-3+b1 ii libqt5dbus5 5.7.1+dfsg-3+b1 ii libqt5gui5 5.7.1+dfsg-3+b1 ii libqt5network5 5.7.1+dfsg-3+b1 ii libqt5printsupport5 5.7.1+dfsg-3+b1 ii libqt5qml5 5.7.1-2+b2 ii libqt5quick5
Bug#878569: spamassassin: Can't set TxRep directory for site wide use
On 18/10/17 21:02, Roger Lynn wrote: > I've found https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7383 which > contains a very small patch which apparently fixes the bug. Without this the > TxRep plugin is unusable. Applying the attached patch appears to have fixed this issue. I have now run into https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7164 which means I get two perl warnings for every message I receive. Roger --- spamassassin-3.4.1.orig/lib/Mail/SpamAssassin/Plugin/TxRep.pm +++ spamassassin-3.4.1/lib/Mail/SpamAssassin/Plugin/TxRep.pm @@ -932,7 +932,7 @@ across all users. my ($self, $key, $value, $line) = @_; unless (defined $value && $value !~ /^$/) {return $Mail::SpamAssassin::Conf::MISSING_REQUIRED_VALUE;} if (-d $value){return $Mail::SpamAssassin::Conf::INVALID_VALUE; } -$self->{txrep_path} = $value; +$self->{auto_whitelist_path} = $value; } });
Bug#878569: spamassassin: Can't set TxRep directory for site wide use
I've found https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7383 which contains a very small patch which apparently fixes the bug. Without this the TxRep plugin is unusable. Thanks, Roger
Bug#851096: [pkg-ntp-maintainers] Bug#851096: update-leap tries to fetch https:// using a module without HTTPS support
On 01/04/17 00:11, Kurt Roeckx wrote: > You should probably use the file from tzdata instead: > /usr/share/zoneinfo/leap-seconds.list Thank you for pointing this out. Is there any reason why the NTP package shouldn't use it by default? Roger
Bug#760415: cups: Need to "reset" the printer between 2 jobs (very similar to STR #3964)"
Package: cups Version: 2.2.1-8 Followup-For: Bug #760415 Hi, Unfortunately I still encounter this bug with a fresh installation of Stretch: if I don't power cycle my Lexmark E232 between jobs I get hundreds of pages of raw PCL when I try to print a second document. Regards, Roger -- System Information: Debian Release: 9.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages cups depends on: ii cups-client2.2.1-8 ii cups-common2.2.1-8 ii cups-core-drivers 2.2.1-8 ii cups-daemon2.2.1-8 ii cups-filters 1.11.6-3 ii cups-ppdc 2.2.1-8 ii cups-server-common 2.2.1-8 ii debconf [debconf-2.0] 1.5.61 ii ghostscript9.20~dfsg-3.2+deb9u1 ii libavahi-client3 0.6.32-2 ii libavahi-common3 0.6.32-2 ii libc-bin 2.24-11+deb9u1 ii libc6 2.24-11+deb9u1 ii libcups2 2.2.1-8 ii libcupscgi12.2.1-8 ii libcupsimage2 2.2.1-8 ii libcupsmime1 2.2.1-8 ii libcupsppdc1 2.2.1-8 ii libgcc11:6.3.0-18 ii libstdc++6 6.3.0-18 ii libusb-1.0-0 2:1.0.21-1 ii poppler-utils 0.48.0-2 ii procps 2:3.3.12-3 Versions of packages cups recommends: pn avahi-daemon pn colord ii cups-filters [ghostscript-cups] 1.11.6-3 ii printer-driver-gutenprint5.2.11-1+b2 Versions of packages cups suggests: pn cups-bsd pn cups-pdf ii foomatic-db-compressed-ppds [foomatic-db] 20161201-1 pn hplip pn printer-driver-hpcups pn smbclient ii udev 232-25+deb9u1 -- debconf information: * cupsys/raw-print: false * cupsys/backend: usb
Bug#878569: spamassassin: Can't set TxRep directory for site wide use
Package: spamassassin Version: 3.4.1-6 Severity: normal Hi, I have a site wide installation of Spamassassin, running as user debian-spamd. Pyzor and Razor correctly use debian-spamd's home directory, but Bayes and TxRep do not. Fortunately Bayes respects the "bayes_path" option. According to http://truxoft.com/resources/txrep.htm (linked from https://wiki.apache.org/spamassassin/TxRep ) the "auto_whitelist_path" option should set the TxRep directory. However, having set it to "/var/lib/spamassassin/.spamassassin/tx-reputation", which is what the documentaion says the default should be, spamd logs: rules: failed to run TXREP test, skipping: (locker: [...] safe_lock: cannot create lockfile /nonexistent/.spamassassin/tx-reputation.mutex: No such file or directory ) "/nonexistent/" is also the directory Bayes uses by default. I guessed that perhaps the option should be "txrep_path", but that just resulted in: config: failed to parse line, skipping, in "/etc/spamassassin/local.cf": txrep_path /var/lib/spamassassin/.spamassassin/tx-reputation The "auto_whitelist_path" option did work correctly with the Auto-WhiteList function in Jessie. Thanks, Roger -- System Information: Debian Release: 9.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages spamassassin depends on: ii adduser 3.115 ii curl 7.52.1-5+deb9u1 ii init-system-helpers 1.48 ii libhtml-parser-perl 3.72-3 ii libhttp-date-perl6.02-1 ii libmail-dkim-perl0.40-1 ii libnet-dns-perl 1.07-1 ii libnetaddr-ip-perl 4.079+dfsg-1+b1 ii libsocket6-perl 0.27-1+b1 ii libsys-hostname-long-perl1.5-1 ii lsb-base 9.20161125 ii perl 5.24.1-3+deb9u2 ii perl-modules-5.24 [libarchive-tar-perl] 5.24.1-3+deb9u2 Versions of packages spamassassin recommends: ii gnupg 2.1.18-8~deb9u1 ii libio-socket-inet6-perl 2.72-2 ii libmail-spf-perl 2.9.0-4 ii libperl5.24 [libsys-syslog-perl] 5.24.1-3+deb9u2 ii sa-compile3.4.1-6 ii spamc 3.4.1-6+b1 Versions of packages spamassassin suggests: ii libdbi-perl 1.636-1+b1 ii libencode-detect-perl1.01-4+b3 ii libgeo-ip-perl 1.50-1+b1 ii libio-socket-ssl-perl2.044-1 ii libnet-patricia-perl 1.22-1+b3 ii libperl5.24 [libcompress-zlib-perl] 5.24.1-3+deb9u2 ii pyzor1:1.0.0-2 ii razor1:2.85-4.2+b2 -- Configuration Files: /etc/default/spamassassin changed: ENABLED=1 OPTIONS="-u debian-spamd --allow-tell" PIDFILE="/var/run/spamd.pid" CRON=1 /etc/spamassassin/local.cf changed: time_limit 50 use_txrep 1 auto_whitelist_path /var/lib/spamassassin/.spamassassin/tx-reputation ok_locales en ok_languages en score GTUBE 4.0 score BAYES_00 0 0 (-0.5) (-0.5) score BAYES_05 0 0 (-0.5) (-0.5) score BAYES_80 0 0 (0.5) (0.5) score BAYES_95 0 0 (0.5) (1.0) score BAYES_99 0 0 (1.5) (2.0) score BAYES_999 0 0 (0.2) (0.2) score MICROSOFT_EXECUTABLE(1.0) score MIME_SUSPECT_NAME (0.5) clear_report_template report Host "_HOSTNAME_", requires _REQD_ points. report _SUMMARY_ trusted_networks192.168/16 trusted_networks90.155.73.34 trusted_networks81.187.30.29 internal_networks 192.168/16 90.155.73.34 lock_method flock required_score 0.0 bayes_ignore_header X-Spam-Score bayes_ignore_header X-Spam-Report bayes_path /var/lib/spamassassin/.spamassassin/bayes bayes_auto_learn_threshold_nonspam 0.0 bayes_auto_learn_threshold_spam 6.0 normalize_charset 1 ifplugin Mail::SpamAssassin::Plugin::Shortcircuit endif # Mail::SpamAssassin::Plugin::Shortcircuit /etc/spamassassin/v310.pre changed: loadplugin Mail::SpamAssassin::Plugin::Pyzor loadplugin Mail::SpamAssassin::Plugin::Razor2 loadplugin Mail::SpamAssassin::Plugin::SpamCop loadplugin Mail::SpamAssassin::Plugin::AntiVirus loadplugin Mail::SpamAssassin::Plugin::AutoLearnThreshold loadplugin Mail::SpamAssassin::Plugin::TextCat loadplugin Mail::SpamAssassin::Plugin::WhiteListSubject loadplugin Mail::SpamAssassin::Plugin::MIMEHeader loadplugin Mail::SpamAssassin::Plugin::ReplaceTags /etc/spamassassin/v320.pre changed: loadplugin Mail::SpamAssassin::Plugin::Check loadplugin Mail::SpamAssassin::Plugin::HTTPSMismatch loadplugin Mail::SpamAssassin::
Bug#873064: dovecot-imapd: Can't connect from older MacOSX and iOS devices to imap 993
On 24/08/2017 08:26, Peter Chubb wrote: > After upgrading dovecot, MacOSX El Capitan and IOS versions below 8 can > no longer connect. The error in the log is: > SSL_accept() failed: error:1417D18C:SSL > routines:tls_process_client_hello:version too low, session=... This is due to a bug introduced in OpenSSL 1.1.0f-4, which you presumably updated at the same time. As I am not a Debian Developer I will leave it to someone else to reassign this bug. > How can I reenable TLSv1 ? The obvious > ssl_protocols = TLSv1, TLSv1.1, TLSv1.2, !SSLv2, !SSLv4 > doesn't work for me. I would assume that downgrading openssl and libssl1.1 to version 1.1.0f-3 (available from snapshot.debian.org) should work... Roger
Bug#760415: cups: Need to "reset" the printer between 2 jobs (very similar to STR #3964)"
Package: cups Version: 1.7.5-11+deb8u2 Followup-For: Bug #760415 I also have this problem with a Lexmark E232 with both Jessie and Wheezy. I can't remember if it occurred in Squeeze and I haven't tried Stretch yet. I'll try to remember to report back when I upgrade to Stretch. Thanks, Roger -- System Information: Debian Release: 8.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-proposed-updates'), (500, 'oldstable') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages cups depends on: ii cups-client1.7.5-11+deb8u2 ii cups-common1.7.5-11+deb8u2 ii cups-core-drivers 1.7.5-11+deb8u2 ii cups-daemon1.7.5-11+deb8u2 ii cups-filters 1.0.61-5+deb8u3 ii cups-ppdc 1.7.5-11+deb8u2 ii cups-server-common 1.7.5-11+deb8u2 ii debconf [debconf-2.0] 1.5.56+deb8u1 ii ghostscript9.06~dfsg-2+deb8u5 ii libavahi-client3 0.6.31-5 ii libavahi-common3 0.6.31-5 ii libc-bin 2.19-18+deb8u10 ii libc6 2.19-18+deb8u10 ii libcups2 1.7.5-11+deb8u2 ii libcupscgi11.7.5-11+deb8u2 ii libcupsimage2 1.7.5-11+deb8u2 ii libcupsmime1 1.7.5-11+deb8u2 ii libcupsppdc1 1.7.5-11+deb8u2 ii libgcc11:4.9.2-10 ii libstdc++6 4.9.2-10 ii libusb-1.0-0 2:1.0.19-1 ii lsb-base 4.1+Debian13+nmu1 ii poppler-utils 0.26.5-2+deb8u1 ii procps 2:3.3.9-9 Versions of packages cups recommends: pn avahi-daemon pn colord ii cups-filters [ghostscript-cups] 1.0.61-5+deb8u3 ii printer-driver-gutenprint5.2.10-3 Versions of packages cups suggests: pn cups-bsd pn cups-pdf ii foomatic-db-compressed-ppds [foomatic-db] 20150411-1 pn hplip pn printer-driver-hpcups pn smbclient ii udev 215-17+deb8u7 -- Configuration Files: /etc/cups/cupsd.conf.default 9ffef7ab095f3f35dcd108ba52de6295 [Errno 2] No such file or directory: u'/etc/cups/cupsd.conf.default 9ffef7ab095f3f35dcd108ba52de6295' /etc/default/cups 2b436fbb1a32b82b6aba45a76a1d7e40 [Errno 2] No such file or directory: u'/etc/default/cups 2b436fbb1a32b82b6aba45a76a1d7e40' -- debconf information: * cupsys/backend: lpd, socket, usb, snmp, dnssd * cupsys/raw-print: true
Bug#865042: sensord: Sensord package is missing in Debian Stretch
Package: sensord Version: 1:3.3.5-2 Followup-For: Bug #865042 Hi, Removing the whole package because one particular use-case has some problems seems like a bit of an over-reaction, especially when that usage isn't even mentioned in the package description and the required dependency is only a suggests. Unfortunately I assume it's unlikely to be reintroduced into Stretch and we will have to wait for Buster. :-( Thanks, Roger -- System Information: Debian Release: 8.8 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-proposed-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages sensord depends on: ii libc62.19-18+deb8u10 ii librrd4 1.4.8-1.2 ii libsensors4 1:3.3.5-2 ii lm-sensors 1:3.3.5-2 ii lsb-base 4.1+Debian13+nmu1 sensord recommends no packages. Versions of packages sensord suggests: pn rrdtool -- Configuration Files: /etc/logcheck/ignore.d.workstation/sensord [Errno 13] Permission denied: u'/etc/logcheck/ignore.d.workstation/sensord' -- no debconf information
Bug#786791: re
I have a Contract for you worth US$5.2m, contact me now for more information.
Bug#851620: partman-md: doesn't warn about not being able to embed in the end
On 16/01/17 22:00, Samuel Thibault wrote: > partman-md doesn't warn when disks to be used for RAID are partitioned > with GPT without a bios boot partition for embedding (and I haven't seen > documentation about the issue in the installer manual). Is this the same problem that was reported in installation-report bug #768624 "grub core.img won't fit in the embedding area which is required for LVM"? Roger
Bug#820983: /usr/share/doc/samba/NEWS.Debian.gz: "smb signing" is an "unknown parameter"
Package: samba Version: 2:4.2.10+dfsg-0+deb8u1 Severity: normal File: /usr/share/doc/samba/NEWS.Debian.gz Hi, The NEWS file states: Finally, two important configuration options should be considered, that we were unable to silently change defaults for: - smb signing = required - ntlm auth = no However smb signing is not a recognised parameter: .../lib/param/loadparm.c:743(lpcfg_map_parameter) Unknown parameter encountered: "smb signing" Searching through SMB.CONF(5), it appears the intended parameter is: client signing = mandatory Is this correct? According to the NEWS file this option has security implications, so should be considered important. Thanks, Roger -- System Information: Debian Release: 8.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages samba depends on: ii adduser 3.113+nmu3 ii dpkg 1.17.26 ii libacl1 2.2.52-2 ii libattr1 1:2.4.47-2 ii libbsd0 0.7.0-2 ii libc62.19-18+deb8u4 ii libcups2 1.7.5-11+deb8u1 ii libhdb9-heimdal [heimdal-hdb-api-8] 1.6~rc2+dfsg-9 ii libldap-2.4-22.4.40+dfsg-1+deb8u2 ii libldb1 2:1.1.20-0+deb8u1 ii libpam-modules 1.1.8-3.1+deb8u1+b1 ii libpam-runtime 1.1.8-3.1+deb8u1 ii libpopt0 1.16-10 ii libpython2.7 2.7.9-2 ii libtalloc2 2.1.2-0+deb8u1 ii libtdb1 1.3.6-0+deb8u1 ii libtevent0 0.9.25-0+deb8u1 ii libwbclient0 2:4.2.10+dfsg-0+deb8u1 ii lsb-base 4.1+Debian13+nmu1 ii multiarch-support2.19-18+deb8u4 ii procps 2:3.3.9-9 ii python 2.7.9-1 ii python-dnspython 1.12.0-1 ii python-ntdb 1.0-5 ii python-samba 2:4.2.10+dfsg-0+deb8u1 pn python2.7:any ii samba-common 2:4.2.10+dfsg-0+deb8u1 ii samba-common-bin 2:4.2.10+dfsg-0+deb8u1 ii samba-dsdb-modules 2:4.2.10+dfsg-0+deb8u1 ii samba-libs 2:4.2.10+dfsg-0+deb8u1 ii tdb-tools1.3.6-0+deb8u1 ii update-inetd 4.43 Versions of packages samba recommends: ii attr 1:2.4.47-2 ii logrotate 3.8.7-1+b1 ii samba-vfs-modules 2:4.2.10+dfsg-0+deb8u1 Versions of packages samba suggests: pn bind9 pn bind9utils pn ctdb pn ldb-tools ii ntp1:4.2.6.p5+dfsg-7+deb8u1 pn smbldap-tools pn winbind -- debconf information: * samba/run_mode: daemons samba-common/title:
Bug#232584: new svnserve init.d script
On Sun, 25 Mar 2012 05:33:14 +0800 Liu Yubao wrote: > Share my svnserve init.d script. > > First, I use user "svn" and group "svn" for svnserve: > > [ "`getent group svn`" ] || addgroup --system svn > > [ "`getent passwd svn`" ] || adduser --system --home /srv/svn \ > --shell /bin/false --ingroup svn --disabled-password \ > --disabled-login --gecos "svnserver server account" svn > > Some file paths embedded in /etc/init.d/svnserve and can be adjusted in > /etc/default/svnserve: > repository root: /srv/svn > pid file: /var/run/svnserve.pid > log file: /var/log/svnserve.log > config file: /srv/svn/svnserve.conf (I used --config-file option > because I wouldn't like to manage */conf/svnserve.conf) > > Files attached, hope that's useful for somebody:-) > /etc/init.d/svnserve > /etc/default/svnserve > /etc/logrotate.d/svnserve > > The /etc/init.d/svnserve is modified from /etc/init.d/skeleton. Thank you for the script, which I have been successfully using for several years. I've just upgraded to Jessie and svnserve now appears to require write access to the directory containing the PID file. Also PID files have moved to /run. I have therefore modified the script to create /run/svnserve with owner svn:svn and moved the PID file to /run/svnserve/svnserve.pid Roger #! /bin/sh ### BEGIN INIT INFO # Provides: svnserve # Required-Start:$local_fs $remote_fs $network $syslog # Required-Stop: $local_fs $remote_fs $network $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: svnserver daemon service # Description: Starts, stops or restarts the svnserve daemon. The #daemon serves requests from subversion clients. ### END INIT INFO # Author: Yubao Liu # # Do NOT "set -e" # PATH should only include /usr/* if it runs after the mountnfs.sh script PATH=/sbin:/usr/sbin:/bin:/usr/bin DESC="svnserver daemon service" NAME=svnserve PIDDIR=/run/$NAME PIDFILE=$PIDDIR/$NAME.pid LOGFILE=/var/log/svnserve.log DAEMON=/usr/bin/$NAME DAEMON_ARGS="-d -T -r /srv/svn --config-file=/srv/svn/svnserve.conf --pid-file=$PIDFILE --log-file=$LOGFILE" SCRIPTNAME=/etc/init.d/$NAME # Exit if the package is not installed [ -x "$DAEMON" ] || exit 0 # Read configuration variable file if it is present [ -r /etc/default/$NAME ] && . /etc/default/$NAME # Load the VERBOSE setting and other rcS variables . /lib/init/vars.sh # Define LSB log_* functions. # Depend on lsb-base (>= 3.2-14) to ensure that this file is present # and status_of_proc is working. . /lib/lsb/init-functions # # Function that starts the daemon/service # do_start() { # Return # 0 if daemon has been started # 1 if daemon was already running # 2 if daemon could not be started if [ "$STARTUP" != "yes" ]; then echo -n " [STARTUP isn't \"yes\" in /etc/default/svnserve]" return 2 fi start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null \ || return 1 mkdir -p $PIDDIR chown svn:svn $PIDDIR touch $PIDFILE $LOGFILE chown svn:svn $PIDFILE $LOGFILE chmod 640 $LOGFILE start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -c svn:svn -- \ $DAEMON_ARGS \ || return 2 # Add code here, if necessary, that waits for the process to be ready # to handle requests from services started subsequently which depend # on this one. As a last resort, sleep for some time. } # # Function that stops the daemon/service # do_stop() { # Return # 0 if daemon has been stopped # 1 if daemon was already stopped # 2 if daemon could not be stopped # other if a failure occurred start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME RETVAL="$?" [ "$RETVAL" = 2 ] && return 2 # Wait for children to finish too if this is a daemon that forks # and if the daemon is only ever run from this initscript. # If the above conditions are not satisfied then add some other code # that waits for the process to drop all resources that could be # needed by services started subsequently. A last resort is to # sleep for some time. start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec $DAEMON [ "$?" = 2 ] && return 2 # Many daemons don't delete their pidfiles when they exit. rm -f $PIDFILE return "$RETVAL" } # # Function that sends a SIGHUP to the daemon/service # do_reload() { # # If the daemon can reload its configuration without # restarting (for example, when it is sent a SIGHUP), # then implement that here. # start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --name $NAME return 0 } case "$1" in start)
Bug#800376: scala-doc documents scala.reflect, but none of the other seperate standard libraries.
Package: scala-doc Version: 2.11.6-1 Severity: wishlist Dear Maintainer, scala-doc documents the library scala.reflect, but doesn't document the following standard libraries. scala.xml scala.swing scala.util.continuations scala.util.parsing scala.actors It would be helpful if scala-doc also documented these libraries. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
Bug#797699: frogatto: Seg faults when entering Dungeon Gateway
Package: frogatto Version: 1.3.1+dfsg-2+b3 Severity: important Tags: upstream Dear Maintainer, If I enter the Dungean Gateway level the game will seg fault within a second or so. Restarting the game or resaving does not fix the problem. Here's the last few lines of the debug output. mapping palette 15 get palette mapped: tiles/dungeon-pillars.png, 15 -> 0x42f1220 mapping palette 15 get palette mapped: tiles/dungeon-walls1.png, 15 -> 0x49c78b0 mapping palette 15 get palette mapped: tiles/dungeon-floor.png, 15 -> 0x34b5740 mapping palette 11 get palette mapped: tiles/cave2.png, 11 -> 0x438ab40 mapping palette 11 get palette mapped: tiles/cave1.png, 11 -> 0x3359870 mapping palette 15 get palette mapped: tiles/cement.png, 15 -> 0x3674e10 done level constructor: 64 CREATE OBJ: dungeon_side_doorway LOADTEXTURE: props/dungeon-interior-exit.png -> 0x3beaff0 CREATE OBJ: trashcan_milgram LOADTEXTURE: props/furniture-castle2.png -> 0x2635670 CREATE OBJ: kitty_npc LOADTEXTURE: enemies/kitty-npc.png -> 0x42d5860 CREATE OBJ: broom LOADTEXTURE: props/furniture.png -> 0x2635ea0 SET STARTING CYCLES: 0 mapping palette 15 get palette mapped: props/piston-machine.png, 15 -> 0x4334b10 mapping palette 11 get palette mapped: props/save_toilet.png, 11 -> 0x341ba70 mapping palette 11 get palette mapped: props/rocks-background-cubic.png, 11 -> 0x260ef00 mapping palette 11 get palette mapped: props/rocks-foreground-cubic.png, 11 -> 0x39e3640 mapping palette 11 get palette mapped: props/rope-platform.png, 11 -> 0x3294960 mapping palette 11 get palette mapped: wip/basket-mockup2.png, 11 -> 0x3a4d500 mapping palette 11 get palette mapped: props/rope-vertical.png, 11 -> 0x46a1260 mapping palette 15 get palette mapped: props/chainbit.png, 15 -> 0x4c20330 mapping palette 11 get palette mapped: props/rope-vertical-dark.png, 11 -> 0x484f6d0 mapping palette 15 get palette mapped: props/elevator-track.png, 15 -> 0x3fd4680 mapping palette 15 get palette mapped: props/torch.png, 15 -> 0x3ab0b00 mapping palette 11 get palette mapped: effects/particles3.png, 11 -> 0x197fa10 mapping palette 11 get palette mapped: props/cave-foreground-stalagmites.png, 11 -> 0x3abc3c0 mapping palette 15 get palette mapped: props/gate.png, 15 -> 0x36b8360 mapping palette 15 get palette mapped: props/dungeon-interior-exit.png, 15 -> 0x20c40e0 mapping palette 15 get palette mapped: props/furniture-castle2.png, 15 -> 0x3db8a60 mapping palette 11 get palette mapped: props/stalactites.png, 11 -> 0x42def00 RUNNING GARBAGE COLLECTION FOR 167 OBJECTS... PASS 1: 83 OBJECTS SAFE PASS 2: 101 OBJECTS SAFE PASS 3: 102 OBJECTS SAFE PASS 4: 103 OBJECTS SAFE PASS 5: 104 OBJECTS SAFE PASS 6: 105 OBJECTS SAFE RAN GARBAGE COLLECTION IN 1ms. Releasing 62/167 OBJECTS PLAY: 0x4b0dd60 ambient/cave.ogg -> 0 PLAY: 0x341cc40 ambient/torch.ogg -> 1 zsh: segmentation fault frogatto -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages frogatto depends on: ii fonts-freefont-ttf20120503-4 ii frogatto-data 1.3.1+dfsg-1 ii libboost-regex1.55.0 1.55.0+dfsg-4 ii libboost-system1.55.0 1.55.0+dfsg-4 ii libc6 2.19-19 ii libgcc1 1:5.1.1-14 ii libgl1-mesa-glx [libgl1] 10.6.3-1 ii libglew1.10 1.10.0-3 ii libglu1-mesa [libglu1]9.0.0-2 ii libpng12-01.2.50-2+b2 ii libsdl-image1.2 1.2.12-5+b5 ii libsdl-mixer1.2 1.2.12-11+b1 ii libsdl-ttf2.0-0 2.0.11-3 ii libsdl1.2debian 1.2.15-11 ii libstdc++65.1.1-14 ii libx11-6 2:1.6.3-1 ii zlib1g1:1.2.8.dfsg-2+b1 frogatto recommends no packages. frogatto suggests no packages. -- no debconf information
Bug#795196: pcsxr crashes on x86-64 systems.
Package: pcsxr Version: 1.9.92-4 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** After a linux image update to 4.1.0-1 amd64, whenever I try to load a game it throws the following error for XMona and i3 window systems: pcsx: ../libpcsxcore/ix86_64/ix86-64.c:158: MEMADDR_OP: Assertion `!isreg || reg != 0' failed. On KDE it will just hang. I tried changing the graphics backend between X and openGL to no avail. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pcsxr depends on: ii libc6 2.19-19 ii libgdk-pixbuf2.0-02.31.5-1 ii libgl1-mesa-glx [libgl1] 10.6.3-1 ii libglade2-0 1:2.6.4-2 ii libglib2.0-0 2.44.1-1.1 ii libgtk2.0-0 2.24.28-1 ii libpango1.0-0 1.36.8-3 ii libsdl1.2debian 1.2.15-11 ii libx11-6 2:1.6.3-1 ii libxext6 2:1.3.3-1 ii libxtst6 2:1.2.2-1+b1 ii libxv12:1.0.10-1+b1 ii libxxf86vm1 1:1.1.4-1 ii multiarch-support 2.19-19 ii zlib1g1:1.2.8.dfsg-2+b1 pcsxr recommends no packages. pcsxr suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#789862: Error: Message creation failed, not sending
Package: reportbug Version: 6.6.3 Severity: normal Hi, I've just upgraded to Jessie and after editing a bug report for vsftpd 3.0.2-17 I got the following output: Report will be sent to "Debian Bug Tracking System" Attachments: conf-file attached log-file attached Submit this report on vsftpd (e to edit) [Y|n|a|c|e|i|l|m|p|q|d|t|s|?]? Warning: opening 'conf-file attached' failed: No such file or directory. Warning: opening 'log-file attached' failed: No such file or directory. Error: Message creation failed, not sending Traceback (most recent call last): File "/usr/bin/reportbug", line 2211, in main() File "/usr/bin/reportbug", line 1081, in main return iface.user_interface() File "/usr/bin/reportbug", line 2203, in user_interface self.options.envelopefrom) File "/usr/lib/python2.7/dist-packages/reportbug/submit.py", line 316, in send_report msgname = os.path.expanduser(outfile) or ('/var/tmp/%s.bug' % package) File "/usr/lib/python2.7/posixpath.py", line 261, in expanduser if not path.startswith('~'): AttributeError: 'NoneType' object has no attribute 'startswith' My bug report appears to have been deleted from /tmp. My reportbug configuration has not changed since Wheezy. Thank you, Roger -- Package-specific info: ** Environment settings: INTERFACE="text" ** /home/roger/.reportbugrc: reportbug_version "4.12.6" mode advanced ui text -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages reportbug depends on: ii apt 1.0.9.8.1 ii python2.7.9-1 ii python-reportbug 6.6.3 pn python:any reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail pn debconf-utils pn debsums pn dlocate pn emacs23-bin-common | emacs24-bin-common ii exim4 4.84-8 ii exim4-daemon-light [mail-transport-agent] 4.84-8 ii file 1:5.22+15-2 ii gnupg 1.4.18-7 pn python-gtk2 pn python-gtkspell pn python-urwid pn python-vte ii xdg-utils 1.1.0~rc1+git20111210-7.4 Versions of packages python-reportbug depends on: ii apt 1.0.9.8.1 ii python-debian 0.1.27 ii python-debianbts 1.12 pn python:any python-reportbug suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787404: ntp_intres.request: permission denied
On 01/06/2015 09:16, Klaus Ethgen wrote: > This is a successor of bug #571469. All is said there. NTP needs running > DNS when it starts. Please add $named to Required-Start in init script. What if a $named is not installed? Shouldn't it be Should-Start? Roger (Not an NTP maintainer or a Debian Developer) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#785193: mailman depends on cron instead of cron-daemon
On 14/05/2015 14:41, Joost van Baal-Ilić wrote: > "Using the cron-daemon virtual package is clearly where we want to end up", > wrote Russ Allbery in Message-id <87r3y5dwm3@hope.eyrie.org>. > > So that would be a "Depends: cron-daemon|cron" for mailman afaik. > > See https://lists.debian.org/<30446027.mNS7mfypdK@antec> for some background > information. It would be nice to be able to ship a "fixed" mailman in > stretch. > No hurry for now though, I'd guess. Shouldn't the real package be listed before the virtual package in the dependency field? It would be similar to the dependencies mailman already has on "apache2 | httpd" and "exim4 | mail-transport-agent", to give "cron | cron-daemon". Roger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#782450: ppp: Buffer overflow in radius plugin
On 14/04/2015 07:48, Emanuele Rocca wrote: > NMU diff attached. > ppp_2.4.6-3.1-nmu.diff > diff -Nru ppp-2.4.6/debian/patches/rc_mksid-no-buffer-overflow > ppp-2.4.6/debian/patches/rc_mksid-no-buffer-overflow > --- ppp-2.4.6/debian/patches/rc_mksid-no-buffer-overflow 1970-01-01 > 01:00:00.0 +0100 > +++ ppp-2.4.6/debian/patches/rc_mksid-no-buffer-overflow 2015-04-14 > 08:27:53.0 +0200 > @@ -0,0 +1,23 @@ > +Description: Fix buffer overflow in rc_mksid() > + rc_mksid converts the PID of pppd to hex to generate a pseudo-unique string. > + . > + If the process id is bigger than 65535 (), its hex representation will > be > + longer than 4 characters, resulting in a buffer overflow. > + . > + The bug can be exploited to cause a remote DoS. > + . > +Author: Emanuele Rocca > +Bug-Debian: https://bugs.debian.org/782450 > +Last-Update: <2015-04-14> > + > +--- ppp-2.4.6.orig/pppd/plugins/radius/util.c > ppp-2.4.6/pppd/plugins/radius/util.c > +@@ -77,7 +77,7 @@ rc_mksid (void) > + static unsigned short int cnt = 0; > + sprintf (buf, "%08lX%04X%02hX", > +(unsigned long int) time (NULL), > +- (unsigned int) getpid (), > ++ (unsigned int) getpid () % 65535, Shouldn't this be 65536? If you're trying to limit to 0x then 65535 too small. "getpid () & 0x" might be clearer than using the modulus operator and should have exactly the same effect. > +cnt & 0xFF); > + cnt++; > + return buf; Roger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#782450: ppp: Buffer overflow in radius plugin
On 14/04/2015 07:48, Emanuele Rocca wrote: > NMU diff attached. > ppp_2.4.6-3.1-nmu.diff > diff -Nru ppp-2.4.6/debian/patches/rc_mksid-no-buffer-overflow > ppp-2.4.6/debian/patches/rc_mksid-no-buffer-overflow > --- ppp-2.4.6/debian/patches/rc_mksid-no-buffer-overflow 1970-01-01 > 01:00:00.0 +0100 > +++ ppp-2.4.6/debian/patches/rc_mksid-no-buffer-overflow 2015-04-14 > 08:27:53.0 +0200 > @@ -0,0 +1,23 @@ > +Description: Fix buffer overflow in rc_mksid() > + rc_mksid converts the PID of pppd to hex to generate a pseudo-unique string. > + . > + If the process id is bigger than 65535 (), its hex representation will > be > + longer than 4 characters, resulting in a buffer overflow. > + . > + The bug can be exploited to cause a remote DoS. > + . > +Author: Emanuele Rocca > +Bug-Debian: https://bugs.debian.org/782450 > +Last-Update: <2015-04-14> > + > +--- ppp-2.4.6.orig/pppd/plugins/radius/util.c > ppp-2.4.6/pppd/plugins/radius/util.c > +@@ -77,7 +77,7 @@ rc_mksid (void) > + static unsigned short int cnt = 0; > + sprintf (buf, "%08lX%04X%02hX", > +(unsigned long int) time (NULL), > +- (unsigned int) getpid (), > ++ (unsigned int) getpid () % 65535, Shouldn't this be 65536? If you're trying to limit to 0x then 65535 too small. "getpid () & 0x" might be clearer than using the modulus operator and should have exactly the same effect. > +cnt & 0xFF); > + cnt++; > + return buf; Roger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755722: systemd must sync systemclock to RTC on shutdown
On 13/02/2015 06:54, Martin Pitt wrote: > Control: severity -1 normal > > I still disagree with critical: > > - If the hardware clock is so broken that at the next boot it has an >earlier time than on the previous boot/ntpdate, then writing it >once more at shutdown isn't going to entirely fix this problem, as >it will again go sufficiently wrong if you don't reboot immediately >but after some time. A good hardware clock can easily lose many minutes over a year. A not particularly bad one could lose an hour over a year and several minutes over a month. That is not at all broken and will cause time to go backwards on every reboot. Every machine with a hardware clock that does not run fast will eventually run into this problem every time they reboot if the hardware clock has not been written since installation, especially if they boot quickly. The user can not easily monitor the status of the hardware clock and will see that the time on the computer appears to be accurate. There is no reason to assume that the hardware clock is more accurate when the user can only monitor the system clock. Roger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#773334: pcsxr: pcsx does not open ISO file from command line
Package: pcsxr Version: 1.9.92-4 Severity: normal Tags: upstream Dear Maintainer, pcsx does not open Playstation ISO files (.bin) when they are given as arguments. The -cdfile option also does not work. Giving the full pathname also had no effect. The only effective work around is to load the ISO file after pcsx has already started. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pcsxr depends on: ii libc6 2.19-13 ii libgdk-pixbuf2.0-02.31.1-2+b1 ii libgl1-mesa-glx [libgl1] 10.3.2-1 ii libglade2-0 1:2.6.4-2 ii libglib2.0-0 2.42.1-1 ii libgtk2.0-0 2.24.25-1 ii libpango1.0-0 1.36.8-3 ii libsdl1.2debian 1.2.15-10+b1 ii libx11-6 2:1.6.2-3 ii libxext6 2:1.3.3-1 ii libxtst6 2:1.2.2-1+b1 ii libxv12:1.0.10-1+b1 ii libxxf86vm1 1:1.1.3-1+b1 ii multiarch-support 2.19-13 ii zlib1g1:1.2.8.dfsg-2+b1 pcsxr recommends no packages. pcsxr suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#770069: Bug#769672: hdapsd: Doesn't start at boot
On 02/12/14 14:01, Roger Lynn wrote: > On 02/12/2014 13:47, Evgeni Golov wrote: >> On 11/26/2014 08:28 AM, Evgeni Golov wrote: >>> Thanks. Could you please test the following patched version: >>> https://people.debian.org/~evgeni/tmp/hdapsd_20141024-3~test1_amd64.deb >>> >>> What I do not really understand: read() should be interrupted on >>> SIGTERM/SIGUSR1, so we already should jump out of the loop!? > > As far as I remember from when I looked at the code, a signal will interrupt > the read() to call the signal handler. The signal handler sets a global > variable and returns, which means the read() continues to wait. When the > read() eventually returns the global variable is checked at the end of the > main while loop which means that the program can finish. > >> Could any one of you confirm the package as working (properly stoping) >> now, compared to the -2 version currently found in Debian? >> I'd like to get it into Jessie, but can't test properly w/o the hardware. > > Sorry, I missed your previous email. I'll try to test it in the next day or > two. It stops immediately now, although the ordering of the logs is a little strange. Here are the syslogs after starting and stopping it. Note the last line and timings: Dec 2 23:00:50 brahms hdapsd[15249]: Selected interface: FREEFALL Dec 2 23:00:50 brahms hdapsd[15249]: Uses hardware logic from /dev/freefall Dec 2 23:01:09 brahms hdapsd[15249]: Terminating hdapsd Dec 2 23:01:09 brahms systemd[1]: hdapsd.service: main process exited, code=exited, status=255/n/a Dec 2 23:01:09 brahms systemd[1]: Unit hdapsd.service entered failed state. Dec 2 23:01:09 brahms hdapsd[15249]: Tue Dec 2 23:00:50 2014: Starting hdapsd Thanks, Roger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#770069: Bug#769672: hdapsd: Doesn't start at boot
On 02/12/2014 13:47, Evgeni Golov wrote: Hi, On 11/26/2014 08:28 AM, Evgeni Golov wrote: Thanks. Could you please test the following patched version: https://people.debian.org/~evgeni/tmp/hdapsd_20141024-3~test1_amd64.deb What I do not really understand: read() should be interrupted on SIGTERM/SIGUSR1, so we already should jump out of the loop!? As far as I remember from when I looked at the code, a signal will interrupt the read() to call the signal handler. The signal handler sets a global variable and returns, which means the read() continues to wait. When the read() eventually returns the global variable is checked at the end of the main while loop which means that the program can finish. Could any one of you confirm the package as working (properly stoping) now, compared to the -2 version currently found in Debian? I'd like to get it into Jessie, but can't test properly w/o the hardware. Sorry, I missed your previous email. I'll try to test it in the next day or two. Roger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#769672: hdapsd: Doesn't start at boot
On 17/11/14 17:00, Evgeni Golov wrote: > On 11/17/2014 04:24 PM, Roger Lynn wrote: >> On 17/11/2014 11:12, Whoopie wrote: >>> It looks like hdapsd doesn't terminate in time, it get's KILLed after >>> 30 seconds, see the do_stop() function in /etc/init.d/hdapsd: >>> start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile >>> $PIDFILE --name $NAME >>> >>> strace shows: >>> 17912 --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=18045, >>> si_uid=0} --- >>> 17912 rt_sigaction(SIGTERM, {0x402cb0, [TERM], SA_RESTORER|SA_RESTART, >>> 0x7f779b2aec30}, {0x402cb0, [TERM], SA_RESTORER|SA_RESTART, >>> 0x7f779b2aec30}, 8) = 0 >>> 17912 rt_sigreturn()= 0 >>> 17912 read(3, >>> 17912 +++ killed by SIGKILL +++ > > This is > ret = read(freefall_fd, &count, sizeof(count)); > line 1249 from hdapsd.c > >>> Adding some debugging output, the SIGTERM handler is called, but the >>> while loop is not stopped, as the new "running" value doesn't find its >>> way into the main process. But here, my coding skills stop, sorry. > > read() blocks until there is something to read from /dev/freefall. > >> I started looking at this yesterday, but ran out of time. I assume the >> code is getting stuck in a loop or function call, which means it never >> returns to the main while loop in main(). This is slightly worrying: if >> the main loop is not running does that meant the hard disc protection is >> not working? > > No, it should be working, because in the case the hardware logic detects > a fall, the read will unblock. I can confirm that shaking the laptop while waiting for hdapsd to to terminate does make it unblock. Thanks, Roger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#769672: hdapsd: Doesn't start at boot
On 16/11/14 17:09, Evgeni Golov wrote: On 11/16/2014 06:00 PM, Evgeni Golov wrote: Right, how about this: The correct patch would be: diff --git a/debian/README.Debian b/debian/README.Debian index 97ea7cf..f914834 100644 --- a/debian/README.Debian +++ b/debian/README.Debian @@ -1,6 +1,16 @@ hdapsd for Debian - +disable hdapsd +== + +hdapsd can be disabled on boot, if you want to start it manually. + +To disable hdapsd under systemd, use systemctl disable hdapsd.service. +For inits using the init.d scripts, adjust /etc/default/hdapsd to have + START=no +in it. + hdapsd with kernels <= 2.6.27 = diff --git a/debian/rules b/debian/rules index fdbeae1..a7c6726 100755 --- a/debian/rules +++ b/debian/rules @@ -14,10 +14,3 @@ override_dh_auto_install: override_dh_auto_clean: dh_auto_clean rm -f $(CURDIR)/misc/*.service - -override_dh_systemd_enable: - # Do not enable the file by default on purpose. - # The user should enable it only after making sure the configuration is - # appropriate for his/her computer. - # This corresponds to START=no in /etc/default/hdapsd - dh_systemd_enable --no-enable That would also enable hdapsd after installation on systemd, which is what you actually want. That looks reasonable. I had found the START=yes line, which didn't help me on systemd. I can't think of any reason why you would install the package and want it to not run. The default configuration looks as if it should work for the majority of cases and I assume it's not going to do any harm if it's incorrectly configured or if the hardware doesn't exist. It's not as if it is opening network ports with security implications. I've never used systemd before and I'm not enjoying it. I'm not convinced the Debian packaging is ready yet for a stable release. systemd packaging or hdapsd packaging? systemd. I am surprised at how much sysvinit configuration is apparently not implemented in systemd. And I'm struggling with the lack of configuration files with only a binary interface through systemctl. Roger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#769672: hdapsd: Doesn't start at boot
On 17/11/2014 11:12, Whoopie wrote: I can reproduce the issue: $ sudo /etc/init.d/hdapsd start * Starting IBM Hard Disk Active Protection System (HDAPS) daemon hdapsd [ OK ] real0m2.059s user0m0.050s sys 0m0.023s $ time sudo /etc/init.d/hdapsd stop * Stopping IBM Hard Disk Active Protection System (HDAPS) daemon hdapsd [ OK ] real0m30.079s user0m0.083s sys 0m0.285s It looks like hdapsd doesn't terminate in time, it get's KILLed after 30 seconds, see the do_stop() function in /etc/init.d/hdapsd: start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME strace shows: 17912 --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=18045, si_uid=0} --- 17912 rt_sigaction(SIGTERM, {0x402cb0, [TERM], SA_RESTORER|SA_RESTART, 0x7f779b2aec30}, {0x402cb0, [TERM], SA_RESTORER|SA_RESTART, 0x7f779b2aec30}, 8) = 0 17912 rt_sigreturn()= 0 17912 read(3, 17912 +++ killed by SIGKILL +++ Adding some debugging output, the SIGTERM handler is called, but the while loop is not stopped, as the new "running" value doesn't find its way into the main process. But here, my coding skills stop, sorry. I started looking at this yesterday, but ran out of time. I assume the code is getting stuck in a loop or function call, which means it never returns to the main while loop in main(). This is slightly worrying: if the main loop is not running does that meant the hard disc protection is not working? Any signal apart from SIGTERM and SIGUSR1 is not caught and causes an immediate exit without shutting down nicely. Should the instructions at: https://www.debian.org/doc/manuals/debian-reference/ch12.en.html#_debugging_the_debian_package build me a package with debugging enabled? Roger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#769672: hdapsd: Doesn't start at boot
On 16/11/14 13:53, Evgeni Golov wrote: > Hi Roger, > > [ CCing Whoopie because he has more experience with the freefall code ] > > On 11/15/2014 03:07 PM, Roger Lynn wrote: > >> After adding hdapsd to a newly installed Jessie laptop, it is not being >> started at bootup, with nothing being logged. > > hdapsd is installed "disabled", you need to call "systemctl enable > hdapsd" if you want to use it, I might have not documented that part > properly, sorry. I couldn't find anything in either README file or the man page. I've never used systemd before and I'm not enjoying it. I'm not convinced the Debian packaging is ready yet for a stable release. >> Running "/etc/init.d/hdapsd start" starts it as expected: >> Nov 15 14:01:36 brahms hdapsd[10763]: Selected interface: FREEFALL >> Nov 15 14:01:36 brahms hdapsd[10763]: Uses hardware logic from /dev/freefall > > Cool, which HW is this? Dell Latitude E6540. The drive is a ST500LM000-1EJ162. Do you want any more details? >> However stopping hdapsd fails. Both shutting the laptop down or running >> "/etc/init.d/hdapsd stop" results in a 90 second timeout after which the >> process is killed: >> Nov 15 14:06:48 brahms systemd[1]: hdapsd.service stop-sigterm timed out. >> Killing. >> Nov 15 14:06:48 brahms systemd[1]: hdapsd.service: main process exited, >> code=killed, status=9/KILL >> Nov 15 14:06:48 brahms systemd[1]: Unit hdapsd.service entered failed state. > > Interesting. I do not have any "freefall"-capable HW here, so I never > tried the code myself. I guess there is something fishy in the "lets end > now" code when running on freefall, but I have no direct clue. > > Does this happen with sysvinit too? I've not tried. It's a new installation which defaulted to systemd. I'm debating whether to attempt to replace systemd with sysvinit. Thanks, Roger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#769672: hdapsd: Doesn't start at boot
Package: hdapsd Version: 1:20141024-1 Severity: important Hi, After adding hdapsd to a newly installed Jessie laptop, it is not being started at bootup, with nothing being logged. Running "/etc/init.d/hdapsd start" starts it as expected: Nov 15 14:01:36 brahms hdapsd[10763]: Selected interface: FREEFALL Nov 15 14:01:36 brahms hdapsd[10763]: Uses hardware logic from /dev/freefall However stopping hdapsd fails. Both shutting the laptop down or running "/etc/init.d/hdapsd stop" results in a 90 second timeout after which the process is killed: Nov 15 14:06:48 brahms systemd[1]: hdapsd.service stop-sigterm timed out. Killing. Nov 15 14:06:48 brahms systemd[1]: hdapsd.service: main process exited, code=killed, status=9/KILL Nov 15 14:06:48 brahms systemd[1]: Unit hdapsd.service entered failed state. Regards, Roger -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages hdapsd depends on: ii init-system-helpers 1.21 ii libc62.19-13 ii libconfig9 1.4.9-2 Versions of packages hdapsd recommends: pn tp-smapi-dkms | tp-smapi-source hdapsd suggests no packages. -- Configuration Files: /etc/hdapsd.conf changed: device="sda"; adaptive=true; syslog=true; -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#767331: get-iplayer: useless after BBC API changes
Hi, Is there any chance of getting this fixed in Jessie please? I would have expected that a freeze exception would be granted for this bug and I believe uploads fixing 'important' bugs are still allowed. Thanks, Roger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766838: ntpdate runs before network is up
On 26/10/14 08:53, Torquil Macdonald Sørensen wrote: >4264 Oct 26 08:36:48 lenovo ntpdate[371]: Can't find host ntp.uio.no: Name > or service not known (-2) I recently noticed a similar problem caused by ntpdate being run before my DNS server (maradns at the moment) is started. I've worked around it by telling ntpdate not to use the ntpd configuration and giving it some IP addresses instead. Looking at your logs it's not clear to me whether your problem is a lack of connectivity or just no DNS, but I'm no expert. Roger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737921: [TLS1.2] gnutls only likes SHA1 and SHA256 certificates
On 23/10/2014 04:46, Desai, Jason wrote: I ran into this bug too - not fun. I was not able to find a work around until I started investigating how to disable SSLv3 to protect against POODLE. Since it seems that the issue is with TLS 1.2 and SHA512, I think you can disable the TLS 1.2 protocol altogether as a work around until this gets fixed properly. Don't forget to disable SSLv3 while you're at it. Thanks for the tip. I have only recently discovered that CACert have been offering SHA256 certificates for several months, but the option is only shown when you add a new server. This provides an alternative work around for those trying to use CACert certificates. For details see: http://blog.cacert.org/2014/06/selection-of-hash-algorithm-during-certificate-creation/ Roger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#761580: RFP: iceape -- The Iceape Internet Suite
Package: wnpp Severity: wishlist * Package name: iceape Version : 2.29 * URL : http://www.seamonkey-project.org/ * License : MPL/GPL/LGPL Programming Lang: C++/XUL Description : The Iceape Internet Suite The Iceape Internet Suite is an unbranded Seamonkey Internet Suite suitable for free distribution. The SeaMonkey project is a community effort to develop the SeaMonkey all-in-one internet application suite (see below). Such a software suite was previously made popular by Netscape and Mozilla, and the SeaMonkey project continues to develop and deliver high-quality updates to this concept. Containing an Internet browser, email & newsgroup client with an included web feed reader, HTML editor, IRC chat and web development tools, SeaMonkey is sure to appeal to advanced users, web developers and corporate users. Under the hood, SeaMonkey uses much of the same Mozilla source code which powers such successful siblings as Firefox and Thunderbird. Legal backing is provided by the Mozilla Foundation. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#748944: [Pkg-xfce-devel] Bug#748944: lightdm: Attempt to login fails to get past greeter
On Thu, May 22, 2014 at 07:41:08PM +0200, Yves-Alexis Perez wrote: > On jeu., 2014-05-22 at 18:12 +0100, James Lynn wrote: > > > > /etc/X11/Xsession was not executable. After making it executable, > > lightdm now works. > > Any idea how it happened? > > -- > Yves-Alexis None, I'm afraid. I've no memory of changing it, and I don't normally go round making random files non-executable to see what happens. As I said, it worked like that with gdm3, and I've been running that or gdm for a very long time, so assuming it also worked with gdm, it could have happened ages ago. -- James Lynn -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#748944: [Pkg-xfce-devel] Bug#748944: lightdm: Attempt to login fails to get past greeter
On Thu, May 22, 2014 at 05:09:46PM +0200, Yves-Alexis Perez wrote: > On jeu., 2014-05-22 at 15:50 +0100, James Lynn wrote: > > In case there was something running causing the problem, I tried > > configuring lightdm to be the default dm and re-booting, which gave a > > ligthdm greeter with the same symptoms. > > Well I'm afraid I can't help you much here… You'll have to debug > why /etc/X11/Xsession startxfce4 is failing here. It first tries to > execute the script in /etc/X11/Xsession.d so you might want to take a > look there. Aha. /etc/X11/Xsession was not executable. After making it executable, lightdm now works. Thanks. -- James Lynn -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#748944: [Pkg-xfce-devel] Bug#748944: lightdm: Attempt to login fails to get past greeter
On Thu, May 22, 2014 at 04:17:22PM +0200, Yves-Alexis Perez wrote: > > [+139.22s] DEBUG: Registering session with bus path > /org/freedesktop/DisplayManager/Session2 > [+139.22s] DEBUG: Session pid=31375: Running command /etc/X11/Xsession > startxfce4 > [+139.22s] DEBUG: Creating shared data directory /var/lib/lightdm-data/james > [+139.22s] DEBUG: Session pid=31375: Logging to .xsession-errors > [+139.25s] DEBUG: Activating VT 7 > [+139.25s] DEBUG: Activating login1 session > /org/freedesktop/login1/session/_320 > [+139.35s] DEBUG: Session pid=31375: Exited with return value 0 > [+139.35s] DEBUG: Seat: Session stopped > > Can you provide a relevant .xsession-errors? I think there might be some > leftovers from gdm (like a gnome-session or something like that) > preventing the correct startup of Xfce session manager. .xsession-errors (and .xsession-errors.old) is an empty file. The timestamp is consistent with the attempt to login. In case there was something running causing the problem, I tried configuring lightdm to be the default dm and re-booting, which gave a ligthdm greeter with the same symptoms. -- James Lynn -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#748944: lightdm: Attempt to login fails to get past greeter
Package: lightdm Version: 1.10.1-2 Severity: normal Dear Maintainer, Hi, I have been using gdm3 as a display manager, but wished to switch to lightdm, so I installed lightdm (initially from testing, but when it gave the symptoms described below also from unstable, which was installed for this bug report). I then ran /etc/init.d/gdm3 stop, logged out, and from a root shell ran dpkg-reconfigure lightdm (to make it the default) and systemctl start lightdm (the init system is sytemd.) I was presented with a greeter with boxes for username and password. I selected xfce as the desired session and typed my username and password into the boxes. The greeter screen disappeared, but instead of an xfce session appearing, the greeter screen reappeared. I again typed my username and password into the boxes and attempted to login but the same thing keeps happening. I eventually switched back to the root shell, stopped lightdm, restarted gdm3 and logged in without problems. I attach the log files found in /var/log/lightdm. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lightdm depends on: ii adduser3.113+nmu3 ii consolekit 0.4.6-4 ii dbus 1.8.2-1 ii debconf [debconf-2.0] 1.5.53 ii libc6 2.18-5 ii libgcrypt111.5.3-4 ii libglib2.0-0 2.40.0-3 ii libpam-systemd 204-8 ii libpam0g 1.1.8-3 ii libxcb11.10-2 ii libxdmcp6 1:1.1.1-1 ii lightdm-gtk-greeter [lightdm-greeter] 1.8.5-1 Versions of packages lightdm recommends: ii xserver-xorg 1:7.7+7 Versions of packages lightdm suggests: ii accountsservice 0.6.37-1 ii upower 0.9.23-2+b2 -- debconf information: * shared/default-x-display-manager: gdm3 lightdm/daemon_name: /usr/sbin/lightdm [+0.00s] DEBUG: Logging to /var/log/lightdm/lightdm.log [+0.00s] DEBUG: Starting Light Display Manager 1.10.1, UID=0 PID=31142 [+0.00s] DEBUG: Loading configuration dirs from /usr/share/lightdm/lightdm.conf.d [+0.00s] DEBUG: Loading configuration from /usr/share/lightdm/lightdm.conf.d/01_debian.conf [+0.00s] DEBUG: Loading configuration dirs from /usr/local/share/lightdm/lightdm.conf.d [+0.00s] DEBUG: Loading configuration dirs from /etc/xdg/lightdm/lightdm.conf.d [+0.00s] DEBUG: Loading configuration from /etc/lightdm/lightdm.conf [+0.00s] DEBUG: Using D-Bus name org.freedesktop.DisplayManager [+0.00s] DEBUG: Registered seat module xlocal [+0.00s] DEBUG: Registered seat module xremote [+0.00s] DEBUG: Registered seat module unity [+0.00s] DEBUG: Registered seat module surfaceflinger [+0.01s] DEBUG: Adding default seat [+0.01s] DEBUG: Seat: Starting [+0.01s] DEBUG: Seat: Creating greeter session [+0.01s] DEBUG: Seat: Creating display server of type x [+0.01s] DEBUG: Could not run plymouth --ping: Failed to execute child process "plymouth" (No such file or directory) [+0.01s] DEBUG: Using VT 7 [+0.01s] DEBUG: Seat: Starting local X display on VT 7 [+0.01s] DEBUG: DisplayServer x-0: Logging to /var/log/lightdm/x-0.log [+0.01s] DEBUG: DisplayServer x-0: Writing X server authority to /var/run/lightdm/root/:0 [+0.01s] DEBUG: DisplayServer x-0: Launching X Server [+0.01s] DEBUG: Launching process 31147: /usr/bin/X :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch [+0.01s] DEBUG: DisplayServer x-0: Waiting for ready signal from X server :0 [+0.01s] DEBUG: Acquired bus name org.freedesktop.DisplayManager [+0.01s] DEBUG: Registering seat with bus path /org/freedesktop/DisplayManager/Seat0 [+0.01s] DEBUG: Loading users from org.freedesktop.Accounts [+0.01s] DEBUG: User /org/freedesktop/Accounts/User1002 added [+0.01s] DEBUG: User /org/freedesktop/Accounts/User1000 added [+0.02s] DEBUG: User /org/freedesktop/Accounts/User1001 added [+0.02s] DEBUG: User /org/freedesktop/Accounts/User10 added [+0.87s] DEBUG: Got signal 10 from process 31147 [+0.87s] DEBUG: DisplayServer x-0: Got signal from X server :0 [+0.87s] DEBUG: DisplayServer x-0: Connecting to XServer :0 [+0.87s] DEBUG: Seat: Display server ready, starting session authentication [+0.87s] DEBUG: Session pid=31156: Started with service 'lightdm-greeter', username 'lightdm' [+0.91s] DEBUG: Session pid=31156: Authentication complete with return value 0: Success [+0.91s] DEBUG: Seat: Session authenticated, running command [+0.91s] DEBUG: Session pid=31156: Running command /usr/sbin/lightdm-gtk-greeter [+0.91s] DEBUG: Creating shared data directory /var/lib/lightdm-data/lightdm [+0.91s] D
Bug#740160: gnutls unusable with cacert SHA2-512 sigs
Package: libgnutls26 Version: 2.12.20-8+deb7u1 Followup-For: Bug #740160 Hi, I've just renewed the CAcert certificate on my production server and found this bug. At this point my options would appear to be to move to a different GNU/Linux distribution or move to a new certificate provider. Is that correct? Thanks, Roger -- System Information: Debian Release: 7.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libgnutls26 depends on: ii libc6 2.13-38+deb7u1 ii libgcrypt111.5.0-5+deb7u1 ii libp11-kit00.12-3 ii libtasn1-3 2.13-2 ii multiarch-support 2.13-38+deb7u1 ii zlib1g 1:1.2.7.dfsg-13 libgnutls26 recommends no packages. libgnutls26 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742446: vim-runtime: Changelog filetype plugin NewChangelogEntry has a syntax error
Package: vim-runtime Version: 2:7.3.547-7 Severity: normal Tags: patch Dear Maintainer, I was using Vim for editing a changelog. I found the NewChangelogEntry command and executed it. Upon execution I was given an error saying that the field variable was not defined in the passwd_field function. I fixed this by changing the references to field to a:field in the passwd_field function in the file $VIMRUNTIME/ftplugin/changelog.vim. -- System Information: Debian Release: 7.4 APT prefers stable APT policy: (1001, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash vim-runtime depends on no packages. Versions of packages vim-runtime recommends: ii vim2:7.3.547-7 ii vim-gtk [vim] 2:7.3.547-7 ii vim-tiny 2:7.3.547-7 vim-runtime suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741675: clamav-base: Missing quoting and bogus generated config file
Package: clamav Version: 0.98.1+dfsg-1+deb7u2 Followup-For: Bug #741675 This update also trashes the clamd.conf file, see below for its contents. I've had to manually insert it as it also seems to upset reportbug: Gathering additional data, this may take a while... ERROR: Incorrect argument format for option LogRotate ERROR: Missing argument for option at line 10 Spawning sensible-editor... These are the messages I got from aptitude: Preparing to replace libclamav6 0.98.1+dfsg-1+deb7u1 (using .../libclamav6_0.98.1+dfsg-1+deb7u2_i386.deb) ... Unpacking replacement libclamav6 ... Preparing to replace clamav-daemon 0.98.1+dfsg-1+deb7u1 (using .../clamav-daemon_0.98.1+dfsg-1+deb7u2_i386.deb) ... [ ok ] Stopping ClamAV daemon: clamd Waiting . . . Unpacking replacement clamav-daemon ... Preparing to replace clamav-base 0.98.1+dfsg-1+deb7u1 (using .../clamav-base_0.98.1+dfsg-1+deb7u2_all.deb) ... Unpacking replacement clamav-base ... Preparing to replace clamav-freshclam 0.98.1+dfsg-1+deb7u1 (using .../clamav-freshclam_0.98.1+dfsg-1+deb7u2_i386.deb) ... [ ok ] Stopping ClamAV virus database updater: freshclam. Unpacking replacement clamav-freshclam ... Preparing to replace clamav 0.98.1+dfsg-1+deb7u1 (using .../clamav_0.98.1+dfsg-1+deb7u2_i386.deb) ... Unpacking replacement clamav ... Processing triggers for man-db ... Setting up libclamav6 (0.98.1+dfsg-1+deb7u2) ... Setting up clamav-base (0.98.1+dfsg-1+deb7u2) ... /var/lib/dpkg/info/clamav-base.postinst: 403: [: 10: unexpected operator Replacing config file /etc/clamav/clamd.conf with new version Setting up clamav-freshclam (0.98.1+dfsg-1+deb7u2) ... /var/lib/dpkg/info/clamav-freshclam.postinst: 353: [: 10: unexpected operator Disabling old logrotate script for clamav-freshclam Replacing config file /etc/clamav/freshclam.conf with new version [] Starting ClamAV virus database updater: freshclamERROR: Missing argument for option at line 10 ERROR: Can't open/parse the config file /etc/clamav/freshclam.conf failed! Setting up clamav-daemon (0.98.1+dfsg-1+deb7u2) ... [] Starting ClamAV daemon: clamd ERROR: Incorrect argument format for option LogRotate ERROR: Can't open/parse the config file /etc/clamav/clamd.conf failed! Setting up clamav (0.98.1+dfsg-1+deb7u2) ... Restoring my old clamd.conf and freshclam.conf files from backups appears to allow clamav to work. Thanks, Roger -- Package-specific info: --- configuration --- Checking configuration files in /etc/clamav Config file: clamd.conf --- #Automatically Generated by clamav-base postinst #To reconfigure clamd run #dpkg-reconfigure clamav-base #Please read /usr/share/doc/clamav-base/README.Debian.gz for details LocalSocket /var/run/clamav/clamd.ctl FixStaleSocket true LocalSocketGroup clamav LocalSocketMode 666 # TemporaryDirectory is not set to its default /tmp here to make overriding # the default with environment variables TMPDIR/TMP/TEMP possible User clamav AllowSupplementaryGroups true ScanMail true ScanArchive true ArchiveBlockEncrypted false MaxDirectoryRecursion 30 FollowDirectorySymlinks false FollowFileSymlinks false ReadTimeout 180 MaxThreads 4 MaxConnectionQueueLength 8 LogSyslog false LogRotate 10 clamav-base/LogRotate doesn't exist LogFacility LOG_LOCAL6 LogClean false LogVerbose false PidFile /var/run/clamav/clamd.pid DatabaseDirectory /var/lib/clamav SelfCheck 3600 Foreground false Debug false ScanPE true MaxEmbeddedPE 10 clamav-base/MaxEmbeddedPE doesn't exist ScanOLE2 true ScanHTML true MaxHTMLNormalize 10 clamav-base/MaxHTMLNormalize doesn't exist MaxHTMLNoTags 10 clamav-base/MaxHTMLNoTags doesn't exist MaxScriptNormalize 10 clamav-base/MaxScriptNormalize doesn't exist MaxZipTypeRcg 10 clamav-base/MaxZipTypeRcg doesn't exist ScanSWF 10 clamav-base/ScanSWF doesn't exist DetectBrokenExecutables false ExitOnOOM false LeaveTemporaryFiles false AlgorithmicDetection true ScanELF true IdleTimeout 30 PhishingSignatures true PhishingScanURLs true PhishingAlwaysBlockSSLMismatch false PhishingAlwaysBlockCloak false DetectPUA false ScanPartialMessages false HeuristicScanPrecedence false StructuredDataDetection false CommandReadTimeout 5 SendBufTimeout 200 MaxQueue 100 ExtendedDetectionInfo true OLE2BlockMacros false ScanOnAccess 10 clamav-base/ScanOnAccess doesn't exist OnAccessIncludePath OnAccessExcludePath OnAccessMaxFileSize OnAccessExcludeUID AllowAllMatchScan 10 clamav-base/AllowAllMatchScan doesn't exist ForceToDisk 10 clamav-base/ForceToDisk doesn't exist DisableCertCheck 10 clamav-base/DisableCertCheck doesn't exist StreamMaxLength 50M LogFile /var/log/clamav/clamav.log LogTime true LogFileUnlock false LogFileMaxSize 0 Bytecode true BytecodeSecurity TrustSigned BytecodeTimeout 6 OfficialDatabaseOnly false CrossFilesystems true Config file: freshclam.conf --- # Automatically created by the clamav-freshclam postinst # Comments will get lost when you reconfigure the clamav-freshclam package DatabaseOwner clamav Update
Bug#708852: how helping?
On 24/01/2014 10:30, Stéphane Grégoire wrote: > How can I help to package latest version? > > Iceape is very important because I think it's better than iceweasel + > icemonkey. Agreed. The Linux/x86_64 version from http://www.seamonkey-project.org/releases/#contrib seems to work for me on AMD64 Wheezy running out of my home directory, but I've no idea if the built in updater will work[0] or what the dependencies are. I'm surprised that Mozilla apparently can't produce a 64 bit build themselves when most Linuxes have been 64 bit for many years. Roger [0] At least I should be able to just delete the old version and download a new one if necessary as it doesn't try to install files all over the system. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#695472: samba: cups smb:// printers broken after upgrading server to wheezy
Package: samba Version: 2:3.6.6-6 Followup-For: Bug #695472 Hi, After upgrading from Squeezy to Wheezy printing from 32b WinXP and 64b Win7 Pro inexplicably stopped working, the Windows queue list simply saying "Error" and not giving any further details. With the default logging levels nothing to explain the problem was being logged by Samba or Cups. I have no idea what the problem was, but adding "use client driver = yes" to smb.conf seems to have fixed it, which I was only able to find thanks to this bug. I am using the Windows drivers for the printer. Thanks, Roger PS Having just finished browsing to the end of the bug list, this would appear to be the same as bug 709613. I will attempt to merge them. -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages samba depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.49 ii dpkg 1.16.10 ii libacl12.2.51-8 ii libattr1 1:2.4.46-8 ii libc6 2.13-38 ii libcap21:2.22-1.2 ii libcomerr2 1.42.5-1.1 ii libcups2 1.5.3-5 ii libgssapi-krb5-2 1.10.1+dfsg-5+deb7u1 ii libk5crypto3 1.10.1+dfsg-5+deb7u1 ii libkrb5-3 1.10.1+dfsg-5+deb7u1 ii libldap-2.4-2 2.4.31-1+nmu2 ii libpam-modules 1.1.3-7.1 ii libpam-runtime 1.1.3-7.1 ii libpam0g 1.1.3-7.1 ii libpopt0 1.16-7 ii libtalloc2 2.0.7+git20120207-1 ii libtdb11.2.10-2 ii libwbclient0 2:3.6.6-6 ii lsb-base 4.1+Debian8+deb7u1 ii procps 1:3.3.3-3 ii samba-common 2:3.6.6-6 ii update-inetd 4.43 ii zlib1g 1:1.2.7.dfsg-13 Versions of packages samba recommends: ii logrotate 3.8.1-4 ii tdb-tools 1.2.10-2 Versions of packages samba suggests: pn ctdb pn ldb-tools ii openbsd-inetd [inet-superserver] 0.20091229-2 pn smbldap-tools -- debconf information: * samba/run_mode: daemons * samba/generate_smbpasswd: false samba-common/title: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708174: gnutls26: with priority SECURE128 fails to negotiate a cipher suite with itself
On 13/05/13 18:28, Roger Lynn wrote: > Running > gnutls-serv -d 255 -p 1234 --x509certfile /etc/ssl/certs/rilynn.pem > --x509keyfile /etc/ssl/private/rilynn.key > and > gnutls-cli -d 255 -p 1234 --priority SECURE128 rilynn.me.uk > on the same box fails to negotiate a cipher suite. A priority string of > NORMAL appears to work. Interestingly, SECURE256 also seems to work. Roger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708174: gnutls26: with priority SECURE128 fails to negotiate a cipher suite with itself
Package: gnutls-bin Version: 3.0.22-3+really2.12.20-7 Followup-For: Bug #708174 Hi, I am testing on two machines, an old Pentium 3 system from which I originally reported this bug and a new Xeon system from which I am sending this, both running up to date Wheezy. I get the same results on both. On 14/05/13 02:21, Daniel Kahn Gillmor wrote: > On 05/13/2013 01:28 PM, Roger Lynn wrote: >> Source: gnutls26 >> Version: 2.12.20-6 >> Severity: normal >> >> Running >> gnutls-serv -d 255 -p 1234 --x509certfile /etc/ssl/certs/rilynn.pem >> --x509keyfile /etc/ssl/private/rilynn.key >> and >> gnutls-cli -d 255 -p 1234 --priority SECURE128 rilynn.me.uk >> on the same box fails to negotiate a cipher suite. A priority string of >> NORMAL appears to work. > > Hm, i'm not able to replicate this, using gnutls-bin > 3.0.22-3+really2.12.20-6 (the version currently in wheezy/jessie/sid, > which i think is the same version as the source package version > mentioned above. Sorry for the confusion, this message includes the details of the gnutls-bin that I'm using. > is it possible that your test is not connecting to the system you're > testing? I don't think so. > here's how i ran my test: > > certtool -p > x.key > echo 'cn=127.0.0.1' > template.cfg > certtool -s --load-privkey x.key > x.cert --template template.cfg > gnutls-serv -d 255 -p 1234 --x509certfile x.cert --x509keyfile x.key > > and then in another terminal: > > gnutls-cli -d 255 -p 1234 --x509cafile x.cert --priority SECURE128 > 127.0.0.1 > > And the connection succeeded, selecting the following parameters: > > - Version: TLS1.2 > - Key Exchange: DHE-RSA > - Cipher: AES-128-CBC > - MAC: SHA256 > - Compression: NULL That works for me, which suggests (to me at least) that this might have something to do with the keys or certificates. I have tested with two, both created with OpenSSL and signed by CAcert. The newer one was created on 11 Oct 2012 on up to date Wheezy with the script at http://svn.cacert.org/CAcert/Software/CSRGenerator/csr >> Using a priority string of SECURE128 for outgoing SMTP connections in Debian >> exim also fails between two Wheezy boxes, which is how I noticed the problem >> in the first place. > > hmm, this seems particularly worrisome! I will try to set this up and > test it. what sort of failure are you seeing specifically? can you > share (the relevant parts of) your configurations that show this error? On the sending end I get the universal gnutls error message: TLS error on connection to mail.fundamentalsltd.co.uk [217.169.26.194] (gnutls_handshake): A TLS packet with unexpected length was received. /etc/exim4/conf.d/transport/30_exim4-config_remote_smtp has had the following added: tls_require_ciphers = SECURE128 On the receiving end I get: TLS error on connection from rilynn.me.uk [90.155.73.34] (gnutls_handshake): Could not negotiate a supported cipher suite. /etc/exim4/conf.d/main/00_local_options contains: MAIN_TLS_ENABLE = defined MAIN_TLS_CERTIFICATE = /etc/ssl/certs/mail_server.pem MAIN_TLS_PRIVATEKEY = /etc/exim4/mail_privatekey.pem >> Also, gnutls appears to prefer to use the weakest available cipher instead of >> the strongest, which seems a bit odd. > > This also sounds worrisome, but it might be due to a misinterpretation > of how the priority string is supposed to work. --priority SECURE128 in > gnutls26 appears to mean *only* the ciphersuites with 128-bit ciphers, > not those ciphers and above. This seems counter-intuitive, as the expected action would be to select a minimum cipher length, which is what is suggested at http://www.gnutls.org/manual/html_node/Priority-Strings.html However that presumably applies to a newer version of the software. What is the correct way to exclude weaker ciphers? > i note that there is no gnutls-doc/*really2.12.20-6 package in wheezy > to compare with :/ That seems like it might make debugging or writing > code that targets gnutls26 a serious challenge. Is gnutls26-doc is what you are looking for? Thanks for looking into this, Roger -- System Information: Debian Release: 7.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnutls-bin depends on: ii libc6 2.13-38 ii libgcrypt11 1.5.0-5 ii libgnutls26 2.12.20-7 ii libp11-kit0 0.12-3 ii libreadline6 6.2+dfsg-0.1 ii libtasn1-32.13-2 ii zlib1g1:1.2.7.dfsg-13 gnutls-bin recommends no packages. gnutls-bin suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#709236: /usr/bin/apt-cdrom: Replaces tabs with spaces in /etc/apt/sources.list
Package: apt Version: 0.8.10.3+squeeze1 Severity: minor File: /usr/bin/apt-cdrom Hi, apt-cdrom has replaced all the tabs with spaces in my nicely formatted sources.list, messing up the appearance. It should not modify lines which it is not specifically editing the contents of. Thanks, Roger -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "1"; APT::Install-Suggests "0"; APT::Acquire ""; APT::Acquire::Translation "environment"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image.*"; APT::NeverAutoRemove:: "^kfreebsd-image.*"; APT::NeverAutoRemove:: "^linux-restricted-modules.*"; APT::NeverAutoRemove:: "^linux-ubuntu-modules-.*"; APT::Never-MarkAuto-Sections ""; APT::Never-MarkAuto-Sections:: "metapackages"; APT::Never-MarkAuto-Sections:: "restricted/metapackages"; APT::Never-MarkAuto-Sections:: "universe/metapackages"; APT::Never-MarkAuto-Sections:: "multiverse/metapackages"; APT::Never-MarkAuto-Sections:: "oldlibs"; APT::Never-MarkAuto-Sections:: "restricted/oldlibs"; APT::Never-MarkAuto-Sections:: "universe/oldlibs"; APT::Never-MarkAuto-Sections:: "multiverse/oldlibs"; Dir "/"; Dir::State "var/lib/apt/"; Dir::State::lists "lists/"; Dir::State::cdroms "cdroms.list"; Dir::State::mirrors "mirrors/"; Dir::State::extended_states "extended_states"; Dir::State::status "/var/lib/dpkg/status"; Dir::Cache "var/cache/apt/"; Dir::Cache::archives "archives/"; Dir::Cache::srcpkgcache "srcpkgcache.bin"; Dir::Cache::pkgcache "pkgcache.bin"; Dir::Etc "etc/apt/"; Dir::Etc::sourcelist "sources.list"; Dir::Etc::sourceparts "sources.list.d"; Dir::Etc::vendorlist "vendors.list"; Dir::Etc::vendorparts "vendors.list.d"; Dir::Etc::main "apt.conf"; Dir::Etc::netrc "auth.conf"; Dir::Etc::parts "apt.conf.d"; Dir::Etc::preferences "preferences"; Dir::Etc::preferencesparts "preferences.d"; Dir::Etc::trusted "trusted.gpg"; Dir::Etc::trustedparts "trusted.gpg.d"; Dir::Bin ""; Dir::Bin::methods "/usr/lib/apt/methods"; Dir::Bin::dpkg "/usr/bin/dpkg"; Dir::Media ""; Dir::Media::MountPath "/media/apt"; Dir::Log "var/log/apt"; Dir::Log::Terminal "term.log"; Dir::Log::History "history.log"; Dir::Ignore-Files-Silently ""; Dir::Ignore-Files-Silently:: "~$"; Dir::Ignore-Files-Silently:: "\.disabled$"; Dir::Ignore-Files-Silently:: "\.bak$"; Dir::Ignore-Files-Silently:: "\.dpkg-[a-z]+$"; DPkg ""; DPkg::Pre-Install-Pkgs ""; DPkg::Pre-Install-Pkgs:: "/usr/bin/apt-listchanges --apt || test $? -ne 10"; DPkg::Pre-Install-Pkgs:: "/usr/sbin/dpkg-preconfigure --apt || true"; DPkg::Tools ""; DPkg::Tools::Options ""; DPkg::Tools::Options::/usr/bin/apt-listchanges ""; DPkg::Tools::Options::/usr/bin/apt-listchanges::Version "2"; CommandLine ""; CommandLine::AsString "apt-config dump"; -- /etc/apt/preferences -- Package: * Pin: release a=lenny-backports Pin-Priority: 200 -- /etc/apt/sources.list -- #deb cdrom:[Debian GNU/Linux squeeze-di-beta2 _Squeeze_ - Official Beta amd64 DVD Binary-1 20101203-17:44]/ squeeze contrib main #deb cdrom:[Debian GNU/Linux 5.0.1 _Lenny_ - Official amd64 CD Binary-1 20090413-02:50]/ lenny main deb cdrom:[Debian GNU/Linux 7.0.0 _Wheezy_ - Official amd64 CD Binary-1 20130504-14:44]/ wheezy main deb http://ftp.uk.debian.org/debian squeeze main contrib non-free deb http://ftp.uk.debian.org/debian squeeze-updates main contrib non-free deb http://ftp.uk.debian.org/debian squeeze-proposed-updates main contrib non-free #deb http://ftp.uk.debian.org/debian-volatile squeeze/volatile main contrib non-free #deb http://ftp.uk.debian.org/debian-volatile squeeze/volatile-sloppy main contrib non-free ##deb http://ftp.uk.debian.org/backports.org lenny-backports main contrib non-free #deb http://ftp.uk.debian.org/debian-backports lenny-backports main contrib non-free deb http://security.debian.org squeeze/updates main contrib non-free ##deb http://security.eu.debian.org lenny/updates main contrib non-free deb-src http://ftp.uk.debian.org/debian squeeze main contrib non-free deb-src http://ftp.uk.debian.org/debian squeeze-updates main contrib non-free deb-src http://ftp.uk.debian.org/debian squeeze-proposed-updates main contrib non-free deb-src http://security.debian.org squeeze/updates main contrib non-free ##deb http://volatile.debian.org/debian-volatile lenny/volatile main contri
Bug#708174: gnutls26: with priority SECURE128 fails to negotiate a cipher suite with itself
Source: gnutls26 Version: 2.12.20-6 Severity: normal Running gnutls-serv -d 255 -p 1234 --x509certfile /etc/ssl/certs/rilynn.pem --x509keyfile /etc/ssl/private/rilynn.key and gnutls-cli -d 255 -p 1234 --priority SECURE128 rilynn.me.uk on the same box fails to negotiate a cipher suite. A priority string of NORMAL appears to work. The server reports: Set static Diffie-Hellman parameters, consider --dhparams. Echo Server listening on IPv4 0.0.0.0 port 1234...done Echo Server listening on IPv6 :: port 1234...bind() failed: Address already in use |<4>| REC[0x9224138]: Allocating epoch #0 * Accepted connection from IPv4 192.168.0.1 port 50714 on Mon May 13 18:07:09 2013 |<2>| ASSERT: gnutls_constate.c:695 |<4>| REC[0x9224138]: Allocating epoch #1 |<7>| READ: Got 5 bytes from 0x5 |<7>| READ: read 5 bytes from 0x5 |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[0x9224138]: Expected Packet[0] Handshake(22) with length: 1 |<4>| REC[0x9224138]: Received Packet[0] Handshake(22) with length: 113 |<7>| READ: Got 113 bytes from 0x5 |<7>| READ: read 113 bytes from 0x5 |<7>| RB: Have 5 bytes into buffer. Adding 113 bytes. |<7>| RB: Requested 118 bytes |<4>| REC[0x9224138]: Decrypted Packet[0] Handshake(22) with length: 113 |<6>| BUF[HSK]: Inserted 113 bytes of Data(22) |<6>| BUF[REC][HD]: Read 1 bytes of Data(22) |<6>| BUF[REC][HD]: Read 3 bytes of Data(22) |<3>| HSK[0x9224138]: CLIENT HELLO was received [113 bytes] |<6>| BUF[REC][HD]: Read 109 bytes of Data(22) |<6>| BUF[HSK]: Inserted 4 bytes of Data |<6>| BUF[HSK]: Inserted 109 bytes of Data |<3>| HSK[0x9224138]: Client's version: 3.3 |<2>| ASSERT: gnutls_db.c:326 |<2>| ASSERT: gnutls_db.c:246 |<2>| EXT[0x9224138]: Parsing extension 'SERVER NAME/0' (17 bytes) |<2>| EXT[0x9224138]: Parsing extension 'SAFE RENEGOTIATION/65281' (1 bytes) |<2>| EXT[0x9224138]: Parsing extension 'SESSION TICKET/35' (0 bytes) |<2>| EXT[0x9224138]: Parsing extension 'SIGNATURE ALGORITHMS/13' (6 bytes) |<2>| EXT[SIGA]: rcvd signature algo (4.1) RSA-SHA256 |<2>| EXT[SIGA]: rcvd signature algo (2.2) DSA-SHA1 |<2>| ASSERT: gnutls_handshake.c:3348 |<1>| Could not find an appropriate certificate: Insufficient credentials for that request. |<3>| HSK[0x9224138]: Removing ciphersuite: DHE_DSS_ARCFOUR_SHA1 |<3>| HSK[0x9224138]: Removing ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 |<3>| HSK[0x9224138]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA1 |<3>| HSK[0x9224138]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA1 |<3>| HSK[0x9224138]: Removing ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1 |<3>| HSK[0x9224138]: Removing ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1 |<3>| HSK[0x9224138]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA256 |<3>| HSK[0x9224138]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA256 |<3>| HSK[0x9224138]: Removing ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[0x9224138]: Removing ciphersuite: DHE_RSA_AES_128_CBC_SHA1 |<3>| HSK[0x9224138]: Removing ciphersuite: DHE_RSA_AES_256_CBC_SHA1 |<3>| HSK[0x9224138]: Removing ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1 |<3>| HSK[0x9224138]: Removing ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1 |<3>| HSK[0x9224138]: Removing ciphersuite: DHE_RSA_AES_128_CBC_SHA256 |<3>| HSK[0x9224138]: Removing ciphersuite: DHE_RSA_AES_256_CBC_SHA256 |<3>| HSK[0x9224138]: Removing ciphersuite: RSA_ARCFOUR_SHA1 |<3>| HSK[0x9224138]: Removing ciphersuite: RSA_ARCFOUR_MD5 |<3>| HSK[0x9224138]: Removing ciphersuite: RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[0x9224138]: Removing ciphersuite: RSA_AES_128_CBC_SHA1 |<3>| HSK[0x9224138]: Removing ciphersuite: RSA_AES_256_CBC_SHA1 |<3>| HSK[0x9224138]: Removing ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 |<3>| HSK[0x9224138]: Removing ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 |<3>| HSK[0x9224138]: Removing ciphersuite: RSA_AES_128_CBC_SHA256 |<3>| HSK[0x9224138]: Removing ciphersuite: RSA_AES_256_CBC_SHA256 |<2>| ASSERT: gnutls_handshake.c:921 |<2>| ASSERT: gnutls_handshake.c:586 |<2>| ASSERT: gnutls_handshake.c:2358 |<2>| ASSERT: gnutls_handshake.c:2991 |<6>| BUF[HSK]: Cleared Data from buffer Error in handshake Error: Could not negotiate a supported cipher suite. |<4>| REC: Sending Alert[2|40] - Handshake failed |<4>| REC[0x9224138]: Sending Packet[0] Alert(21) with length: 2 |<7>| WRITE: enqueued 7 bytes for 0x5. Total 7 bytes. |<7>| WRITE FLUSH: 7 bytes in buffer. |<7>| WRITE: wrote 7 bytes, 0 bytes left. |<4>| REC[0x9224138]: Sent Packet[1] Alert(21) with length: 7 |<2>| ASSERT: gnutls_record.c:276 |<6>| BUF[HSK]: Cleared Data from buffer |<4>| REC[0x9224138]: Epoch #0 freed |<4>| REC[0x9224138]: Epoch #1 freed The client reports : Resolving 'rilynn.me.uk'... Connecting to '192.168.0.1:1234'... |<4>| REC[0x89c9238]: Allocating epoch #0 |<2>| ASSERT: gnutls_constate.c:695 |<4>| REC[0x89c9238]: Allocating epoch #1 |<3>| HSK[0x89c9238]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA256 |<3>| HSK[0x89c9238]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1 |<3>| HSK[0x89c9238]: Keeping ciphersuite: D
Bug#684164: ppp: Please package upstream snaphots (was: rp-pppoe 3.11 allows 1500B MTU on PPPoE (RFC4638))
Hi, Once wheezy was released I was going to request for upstream snapshots to be packaged, as upstream appears to be stable, slow moving and releasing very infrequently. I have been successfully running the latest upstream using the Debian packaging for a PPPoE connection for the last six months without any apparent problems on a moderately busy office server. Quite a few of the Debian patches are included in the current upstream, so the packaging is actually cleaner. Thanks, Roger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#701508: nginx: Please provide httpd-cgi virtual package
On 23/02/2013 22:47, Roger Lynn wrote: > Many packages which should work with nginx cannot be installed with it because > they depend on httpd-cgi. Nginx can run CGI applications, yet the only way to > do this seems to be to install another webserver and then disable it. I had forgotten that fcgiwrap is also required in order to use CGI with nginx, so I am not sure which package should provide httpd-cgi - but probably nginx, which should at least suggest fcgiwrap. Thanks, Roger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#701508: nginx: Please provide httpd-cgi virtual package
Package: nginx Version: 1.2.1-2.2 Severity: important Hi, Many packages which should work with nginx cannot be installed with it because they depend on httpd-cgi. Nginx can run CGI applications, yet the only way to do this seems to be to install another webserver and then disable it. Thanks, Roger -- System Information: Debian Release: 7.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nginx depends on: ii nginx-full 1.2.1-2.2 nginx recommends no packages. nginx suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#699641: unbound: Returns SERVFAIL for every query if there was no internet access when started
On 02/02/13 20:07, Robert Edmonds wrote: > Robert Edmonds wrote: >> Roger Lynn wrote: >> > Every query returns SERVFAIL even after internet access appears and even >> > for >> > queries which are forwarded to a local server. Unbound has to be restarted >> > after internet access appears before it will work. >> > >> > This is a significant problem as if there is no internet access when >> > unbound >> > is started then there is no DNS at all for the local network until internet >> > access can be restored. >> >> i agree, that's definitely an issue. it looks like there might have >> been some relevant fixes in unbound 1.4.19, do you think you could >> install unbound 1.4.19-1 from unstable and see if it behaves any better? >> i believe the dependencies are all the same, so you ought to be able to >> just pin the unbound packages from unstable. > > by the way, i believe you can set the "domain-insecure" option on your > local domains in order to prevent DNSSEC failures from impacting the > resolution of those domains. I've tested this again this after adding 'domain-insecure: "mydomain.co.uk"' to the configuration and upgrading to 1.4.17-3 from Testing. I still get the following lines logged after a starting with no internet access: Feb 22 18:25:34 alphonse unbound-anchor: /var/lib/unbound/root.key has content Feb 22 18:25:34 alphonse unbound-anchor: fail: the anchor is NOT ok and could not be fixed Feb 22 18:25:35 alphonse unbound: [3910:0] notice: init module 0: validator Feb 22 18:25:35 alphonse unbound: [3910:0] notice: init module 1: iterator Feb 22 18:25:35 alphonse unbound: [3910:0] info: start of service (unbound 1.4.17). But I no longer get the lines about "failed to prime trust anchor -- could not fetch DNSKEY rrset . DNSKEY IN". Resolution of local domains now works, presumably because of the addition of the "domain-insecure" option. When an internet connection is established then all DNS requests work as normal, without having to restart unbound, so this problem seems to have gone away. I don't understand why, as the changelog suggests an unrelated minor update. As I am no longer able to reproduce the original problem I am happy for this bug to be closed, unless you think there is a need for further investigation. Thank you for your time, Roger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#700729: swat: Password management has stopped working
On 18/02/2013 00:00, Andrew Bartlett wrote: > On Sat, 2013-02-16 at 18:24 +, Roger Lynn wrote: >> At some point in the last month server password management using Swat has >> stopped working. Swat can be logged into and the old and new server passwords >> entered, but choosing "Change Password" appears to just reload the page >> without changing anything. Entering the wrong old password or mismatching >> new passwords does the same thing. >> >> The only relevant logging I can find is in /var/log/samba/log. which has >> recently started getting lots of lines like this when Swat is used: >> >> [2013/02/16 15:02:30.297508, 0] passdb/secrets.c:76(secrets_init) >> Failed to open /var/lib/samba/secrets.tdb > >> As my only use of Swat is to allow users to change their passwords, this has >> had a major affect on the usability of the package. > > Please report upstream. We may somehow be able to obtain the CSRF token > and store it in memory before we become the non-privileged user. > > Just to be sure, are you running SWAT as root, from xinetd? SWAT is being run by stunnel, which is running in daemon mode. I couldn't get it to work from inetd. The relevant part of my stunnel configuration looks like this: [swat] accept = 192.168.10.1:901 exec= /usr/sbin/swat execargs = swat -P According to ps SWAT is running as user root. It used to work and I don't think anything has changed here so I presume SWAT has the necessary privileges. I will attempt to report this upstream. I'd be grateful if any fixes could be backported to Debian Wheezy, release policy permitting, as this appears to be a regression caused by a security update. Thanks, Roger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#700729: swat: Password management has stopped working
Package: swat Version: 2:3.6.6-5 Severity: important Hi, At some point in the last month server password management using Swat has stopped working. Swat can be logged into and the old and new server passwords entered, but choosing "Change Password" appears to just reload the page without changing anything. Entering the wrong old password or mismatching new passwords does the same thing. The only relevant logging I can find is in /var/log/samba/log. which has recently started getting lots of lines like this when Swat is used: [2013/02/16 15:02:30.297508, 0] passdb/secrets.c:76(secrets_init) Failed to open /var/lib/samba/secrets.tdb # ls -l /var/lib/samba/secrets.tdb -rw--- 1 root root 430080 Aug 24 23:30 /var/lib/samba/secrets.tdb 24 August is the date I first installed Samba. Swat is running through stunnel, which has always occasionally logged SSL errors, but there don't appear to have been any recent changes to stunnel or its dependancies. While I don't know the Samba code, it looks at least possible to me that the problem was introduced by the patch for CVE-2013-0214. My smb.conf file looks like this: [global] workgroup = FUNDAMENTALS server string = %h server interfaces = 127.0.0.0/8, bond0 bind interfaces only = Yes obey pam restrictions = Yes pam password change = Yes unix password sync = Yes syslog = 0 log file = /var/log/samba/log.%m max log size = 1000 load printers = No os level = 65 preferred master = Yes domain master = Yes dns proxy = No wins support = Yes panic action = /usr/share/samba/panic-action %d idmap config * : backend = tdb invalid users = root [Service] comment = Service files path = /srv/smb/service read only = No create mask = 0775 force create mode = 0664 directory mask = 0770 force directory mode = 0770 oplocks = No level2 oplocks = No There are several other similar share definitions. Apart from the security update, the only other recent changes I can think of are adding the "level2 oplocks = No" parameter, but I can't imagine that affecting Swat, and I briefly tried "max protocol = SMB2" but reverted that when it appeared to negatively impact reliability in Windows. As my only use of Swat is to allow users to change their passwords, this has had a major affect on the usability of the package. Thank you for your assistance, Roger -- System Information: Debian Release: 7.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing-proposed-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages swat depends on: ii dpkg 1.16.9 ii libc6 2.13-37 ii libcap2 1:2.22-1.2 ii libcomerr21.42.5-1 ii libcups2 1.5.3-2.14 ii libgssapi-krb5-2 1.10.1+dfsg-3 ii libk5crypto3 1.10.1+dfsg-3 ii libkrb5-3 1.10.1+dfsg-3 ii libldap-2.4-2 2.4.31-1 ii libpam0g 1.1.3-7.1 ii libpopt0 1.16-7 ii libtalloc22.0.7+git20120207-1 ii libtdb1 1.2.10-2 ii libwbclient0 2:3.6.6-5 ii openbsd-inetd [inet-superserver] 0.20091229-2 ii samba 2:3.6.6-5 ii zlib1g1:1.2.7.dfsg-13 Versions of packages swat recommends: ii samba-doc 2:3.6.6-5 swat suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#700350: dovecot-core: fails to upgrade from squeeze to bpo: Can't locate feature.pm in @INC
On 12/02/2013 17:20, gregor herrmann wrote: > On Mon, 11 Feb 2013 23:40:38 +0100, Andreas Beckmann wrote: >> during a test with piuparts I noticed your package fails to upgrade from >> 'squeeze'. >> It installed fine in 'squeeze', then the upgrade to 'squeeze-backports' >> fails. > >> Can't locate feature.pm in @INC (@INC contains: /etc/perl >> /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 >> /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 >> /usr/local/lib/site_perl .). > > Interesting. > feature is in perl-modules (5.10.1) or perl-base (5.14 and 5.16): > > perl-base: /usr/share/perl/5.14.2/feature.pm > perl-base: /usr/share/perl/5.16.2/feature.pm > perl-modules: /usr/share/perl/5.10.1/feature.pm > > (And the /usr/share/perl/5.10 in your @INC output is a symlink to > /usr/share/perl/5.10.1 where the file is.) > > Is this some timing issue, like the old perl-modules half uninstalled > or something? perl-modules probably isn't installed at all as dovecot-core in backports doesn't appear to have a dependency on it and I can see no sign of it in the piuparts log. perl-base in squeeze is 5.10.1 and presumably doesn't contain the required file. Roger (Just a Dovecote user) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#699641: unbound: Returns SERVFAIL for every query if there was no internet access when started
On 02/02/13 20:07, Robert Edmonds wrote: > Robert Edmonds wrote: >> hi, roger: >> >> i agree, that's definitely an issue. it looks like there might have >> been some relevant fixes in unbound 1.4.19, do you think you could >> install unbound 1.4.19-1 from unstable and see if it behaves any better? >> i believe the dependencies are all the same, so you ought to be able to >> just pin the unbound packages from unstable. > > by the way, i believe you can set the "domain-insecure" option on your > local domains in order to prevent DNSSEC failures from impacting the > resolution of those domains. Thank you for the suggestions and the quick response. It may be a couple of weeks before I have an opportunity to carry out further testing. Roger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#699641: unbound: Returns SERVFAIL for every query if there was no internet access when started
Package: unbound Version: 1.4.17-2 Severity: normal If there is no internet access when unbound is started (which there isn't on my server immediately after a reboot), then unbound logs: Feb 1 18:19:23 alphonse unbound-anchor: /var/lib/unbound/root.key has content Feb 1 18:19:23 alphonse unbound-anchor: fail: the anchor is NOT ok and could not be fixed Feb 1 18:19:23 alphonse unbound: [8860:0] notice: init module 0: validator Feb 1 18:19:23 alphonse unbound: [8860:0] notice: init module 1: iterator Feb 1 18:19:23 alphonse unbound: [8860:0] info: start of service (unbound 1.4.17). Feb 1 18:19:25 alphonse unbound: [8860:0] info: failed to prime trust anchor -- could not fetch DNSKEY rrset . DNSKEY IN Feb 1 18:19:25 alphonse unbound: [8860:0] info: failed to prime trust anchor -- could not fetch DNSKEY rrset . DNSKEY IN Feb 1 18:19:25 alphonse unbound: [8860:0] info: failed to prime trust anchor -- could not fetch DNSKEY rrset . DNSKEY IN Feb 1 18:19:25 alphonse unbound: [8860:0] info: failed to prime trust anchor -- could not fetch DNSKEY rrset . DNSKEY IN Feb 1 18:19:25 alphonse unbound: [8860:0] info: failed to prime trust anchor -- could not fetch DNSKEY rrset . DNSKEY IN Feb 1 18:19:25 alphonse unbound: [8860:0] info: failed to prime trust anchor -- could not fetch DNSKEY rrset . DNSKEY IN Every query returns SERVFAIL even after internet access appears and even for queries which are forwarded to a local server. Unbound has to be restarted after internet access appears before it will work. This is a significant problem as if there is no internet access when unbound is started then there is no DNS at all for the local network until internet access can be restored. Thanks, Roger -- System Information: Debian Release: 7.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing-proposed-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages unbound depends on: ii adduser 3.113+nmu3 ii libc6 2.13-37 ii libevent-2.0-5 2.0.19-stable-3 ii libgcc1 1:4.7.2-5 ii libldns11.6.13-1 ii libpython2.72.7.3-6 ii libssl1.0.0 1.0.1c-4 ii openssl 1.0.1c-4 ii unbound-anchor 1.4.17-2 unbound recommends no packages. unbound suggests no packages. -- Configuration Files: /etc/unbound/unbound.conf changed: server: # The following line will configure unbound to perform cryptographic # DNSSEC validation using the root trust anchor. auto-trust-anchor-file: "/var/lib/unbound/root.key" # verbosity number, 0 is least verbose. 1 is default. verbosity: 1 # print statistics to the log (for every thread) every N seconds. # Set to "" or 0 to disable. Default is disabled. statistics-interval: 86400 # print one line with time, IP, name, type, class for every query. # log-queries: yes # specify the interfaces to answer queries from by ip-address. # The default is to listen to localhost (127.0.0.1 and ::1). # specify 0.0.0.0 and ::0 to bind to all available interfaces. # specify every interface[@port] on a new 'interface:' labelled line. # The listen interfaces are not changed on reload, only on restart. # interface: 2001:DB8::5 interface: 127.0.0.1 interface: 192.168.10.1 interface: 192.168.11.1 # specify the interfaces to send outgoing queries to authoritative # server from by ip-address. If none, the default (all) interface # is used. Specify every interface on a 'outgoing-interface:' line. # outgoing-interface: 192.0.2.153 # outgoing-interface: 2001:DB8::5 # the time to live (TTL) value lower bound, in seconds. Default 0. # If more than an hour could easily give trouble due to stale data. cache-min-ttl: 60 # the time to live (TTL) value cap for RRsets and messages in the # cache. Items are not cached for longer. In seconds. cache-max-ttl: 172800 # control which clients are allowed to make (recursive) queries # to this server. Specify classless netblocks with /size and action. # By default everything is refused, except for localhost. # Choose deny (drop message), refuse (polite error reply), # allow (recursive ok), allow_snoop (recursive and nonrecursive ok) access-control: 0.0.0.0/0 refuse access-control: 127.0.0.0/8 allow access-control: 192.168.10.0/23 allow # Use 0x20-encoded random bits in the query to foil spoof attempts. # This feature is an experimental implementation of draft dns-0x20. # use-caps-for-id: no # Enforce privacy of these addresses. Strips them away from answers. # It may cause DNSSEC validation to additionally m
Bug#695061: decode2text.sh: /usr/local/libexec/dovecot/xml2text is actually in /usr/lib/dovecot/
Package: dovecot-core Version: 1:2.1.7-2 Severity: normal File: /usr/lib/dovecot/decode2text.sh Hi, /usr/lib/dovecot/decode2text.sh references /usr/local/libexec/dovecot/xml2text which is packaged in /usr/lib/dovecot/ Thanks, Roger -- Package-specific info: dovecot configuration - # 2.1.7: /etc/dovecot/dovecot.conf # OS: Linux 3.2.0-4-amd64 x86_64 Debian wheezy/sid auth_username_format = %Ln first_valid_uid = 1000 last_valid_uid = 1 listen = 127.0.0.1, 217.xxx.xxx.xxx mail_access_groups = sharedmail mail_location = maildir:~/Maildir mail_plugins = " zlib fts fts_squat acl" managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date ihave namespace { list = children location = maildir:/home/%%n/Maildir:INDEX=~/Maildir/shared/%%n prefix = shared/%%n/ separator = / subscriptions = no type = shared } namespace inbox { inbox = yes location = prefix = separator = / type = private } passdb { driver = pam } plugin { acl = vfile acl_anyone = allow acl_shared_dict = file:/var/lib/dovecot/shared-mailboxes antispam_backend = pipe antispam_pipe_program = /usr/bin/spamc antispam_pipe_program_notspam_arg = --reporttype=revoke antispam_pipe_program_spam_arg = --reporttype=report antispam_pipe_tmpdir = /tmp antispam_spam = Junk;Junk E-mail antispam_trash = Trash;Deleted Items fts = squat fts_decoder = decode2text fts_squat = partial=4 full=10 sieve = ~/Maildir/dovecot.sieve sieve_before = /etc/dovecot/before.sieve sieve_dir = ~/Maildir/sieve } protocols = " imap lmtp sieve" service auth { unix_listener auth-client { user = Debian-exim } } service decode2text { executable = script /usr/lib/dovecot/decode2text.sh unix_listener decode2text { mode = 0666 } user = dovecot } ssl_cert = ii dovecot-imapd 1:2.1.7-2 pn dovecot-ldap ii dovecot-lmtpd 1:2.1.7-2 ii dovecot-managesieved 1:2.1.7-2 pn dovecot-mysql pn dovecot-pgsql pn dovecot-pop3d ii dovecot-sieve 1:2.1.7-2 pn dovecot-solr pn dovecot-sqlite ii ntp 1:4.2.6.p5+dfsg-2 Versions of packages dovecot-core is related to: ii dovecot-core [dovecot-common] 1:2.1.7-2 pn dovecot-dbg pn dovecot-dev pn dovecot-gssapi ii dovecot-imapd 1:2.1.7-2 pn dovecot-ldap ii dovecot-lmtpd 1:2.1.7-2 ii dovecot-managesieved 1:2.1.7-2 pn dovecot-mysql pn dovecot-pgsql pn dovecot-pop3d ii dovecot-sieve 1:2.1.7-2 pn dovecot-sqlite -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#688634: roundcube-sqlite upgrade causes serious data-loss
On 24/11/2012 15:03, Dominik George wrote: >> I have asked people that did successfuly upgrade real sqlite databse to >> MySQL if they could provide directions or a script but they don't >> remember how they did it exactly. If nobody can come up with a script, >> we will just have to put a note in the release notes about this. I >> personnaly don't think that there are large installations using SQLite >> databases. > > Honestly, I think making a release note out of it is the way to go. Admins > should be capable of migrating the data themselves. I installed the sqlite version of Roundcube at work because I don't understand databases (we are too small to employ a sysadmin, and if we did we would probably end up with a Windows server). At the rate things are going my (20) users are going to lose data and I wish I had installed Squirrelmail as I did at home. Roger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#691852: openbsd-inetd: inetd -l segfaults when internal services are enabled
Package: openbsd-inetd Version: 0.20091229-2 Severity: normal When internal services such as daytime or echo are enabled and OPTIONS="-l" is set, openbsd-inetd segfaults when a connection is made to the service. For example, "telnet localhost daytime" gives in syslog: kernel: [1040052.300462] inetd[15842]: segfault at 0 ip 7fb847ada35c sp 7fff6dcf0d68 error 4 in libc-2.13.so[7fb8479c2000+17d000] The relevant line in inetd.conf reads: daytime stream tcp nowait rootinternal This is on an up to date Wheezy machine installed with the Wheezy Beta1 installer. Thanks, Roger -- System Information: Debian Release: wheezy/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing-proposed-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages openbsd-inetd depends on: ii libc6 2.13-35 ii libwrap0 7.6.q-24 ii lsb-base 4.1+Debian7 ii tcpd 7.6.q-24 ii update-inetd 4.43 openbsd-inetd recommends no packages. openbsd-inetd suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#691469: fetchmail apprently uses mboxo format, which irrecoverably corrupts mail
On 26/10/2012 02:24, Christoph Anton Mitterer wrote: > This is basically the same as Debian bugs #690741 and #633799. > I used severity critical, as the mboxo format causes irrecoverable > mail corruption, which is unknown to most users. I don't think the severity of critical is justified. This is an artefact of the way email has been stored for decades. Just because Christoph was not previously aware of it does not suddenly make it a critical bug. This is also the way mail is handled by the default MTA in a standard Debian installation. Not that I'm saying it shouldn't be improved, just that it hasn't yet caused the world to end. Roger (Just a Fetchmail user. Not speaking for Debian or Fetchmail) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#691409: shorewall refresh ignores AUTOMAKE option
Package: shorewall Version: 4.5.5.3-2 Severity: normal Hi, >From the documentation, shorewall refresh appears to be intended to be a lighter version of restart, however unlike restart it always performs the compilation step, ignoring the AUTOMAKE option. In addition refresh has no -f option which suppresses compilation during a restart. Thanks, Roger -- System Information: Debian Release: wheezy/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing-proposed-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages shorewall depends on: ii bc 1.06.95-2+b1 ii debconf [debconf-2.0] 1.5.46 ii iproute20120521-3 ii iptables 1.4.14-3 ii perl-modules 5.14.2-14 ii shorewall-core 4.5.5.3-2 shorewall recommends no packages. Versions of packages shorewall suggests: ii linux-image-3.2.0-3-amd64 [linux-image] 3.2.23-1 ii make 3.81-8.2 ii shorewall-doc4.5.5-1 -- Configuration Files: /etc/default/shorewall changed: startup=0 OPTIONS="" STARTOPTIONS="" RESTARTOPTIONS="" INITLOG=/dev/null SAFESTOP=1 /etc/shorewall/params [Errno 13] Permission denied: u'/etc/shorewall/params' /etc/shorewall/shorewall.conf changed: STARTUP_ENABLED=Yes VERBOSITY=1 BLACKLIST_LOGLEVEL=debug LOG_MARTIANS=No LOG_VERBOSITY=1 LOGALLNEW= LOGFILE=/var/log/ulog/syslogemu.log LOGFORMAT="Shwl:%s:%s:" LOGTAGONLY=No LOGLIMIT="10/sec:10" MACLIST_LOG_LEVEL=info RELATED_LOG_LEVEL= SFILTER_LOG_LEVEL=info SMURF_LOG_LEVEL=info STARTUP_LOG=/var/log/shorewall-init.log TCP_FLAGS_LOG_LEVEL=info CONFIG_PATH="${CONFDIR}/shorewall:${SHAREDIR}/shorewall" GEOIPDIR=/usr/share/xt_geoip/LE IPTABLES= IP= IPSET= LOCKFILE= MODULESDIR= PATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin" PERL=/usr/bin/perl RESTOREFILE=restore SHOREWALL_SHELL=/bin/sh SUBSYSLOCK= TC= ACCEPT_DEFAULT=none DROP_DEFAULT=Drop NFQUEUE_DEFAULT=none QUEUE_DEFAULT=none REJECT_DEFAULT=Reject RCP_COMMAND='scp ${files} ${root}@${system}:${destination}' RSH_COMMAND='ssh ${root}@${system} ${command}' ACCOUNTING=Yes ACCOUNTING_TABLE=filter ADD_IP_ALIASES=No ADD_SNAT_ALIASES=No ADMINISABSENTMINDED=Yes AUTO_COMMENT=Yes AUTOMAKE=Yes BLACKLISTNEWONLY=Yes CLAMPMSS=No CLEAR_TC=Yes COMPLETE=Yes DELETE_THEN_ADD=Yes DETECT_DNAT_IPADDRS=No DISABLE_IPV6=No DONT_LOAD= DYNAMIC_BLACKLIST=Yes EXPAND_POLICIES=No EXPORTMODULES=Yes FASTACCEPT=Yes FORWARD_CLEAR_MARK= IMPLICIT_CONTINUE=No IPSET_WARNINGS=Yes IP_FORWARDING=On KEEP_RT_TABLES=No LEGACY_FASTSTART=No LOAD_HELPERS_ONLY=Yes MACLIST_TABLE=filter MACLIST_TTL= MANGLE_ENABLED=Yes MAPOLDACTIONS=No MARK_IN_FORWARD_CHAIN=No MODULE_SUFFIX=ko MULTICAST=No MUTEX_TIMEOUT=30 NULL_ROUTE_RFC1918=Yes OPTIMIZE=31 OPTIMIZE_ACCOUNTING=Yes REQUIRE_INTERFACE=No RESTORE_DEFAULT_ROUTE=Yes RETAIN_ALIASES=No ROUTE_FILTER=Yes SAVE_IPSETS=No TC_ENABLED=Internal TC_EXPERT=No TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2" TRACK_PROVIDERS=No USE_DEFAULT_RT=No USE_PHYSICAL_NAMES=No ZONE2ZONE=2 BLACKLIST_DISPOSITION=DROP MACLIST_DISPOSITION=REJECT RELATED_DISPOSITION=ACCEPT SMURF_DISPOSITION=DROP SFILTER_DISPOSITION=DROP TCP_FLAGS_DISPOSITION=DROP TC_BITS= PROVIDER_BITS= PROVIDER_OFFSET= MASK_BITS= ZONE_BITS=0 IPSECFILE=zones -- debconf information: shorewall/dont_restart: shorewall/major_release: shorewall/invalid_config: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#691407: logrotate(8) does not mention all reasons for ignoring included files
Package: logrotate Version: 3.8.1-4 Severity: normal Under the include directive, logrotate(8) says: "The only files which are ignored are files which are not regular files (such as directories and named pipes) and files whose names end with one of the taboo extensions, as specified by the tabooext directive." This is not true. It would appear that files are also ignored because of some unspecified "bad" file modes, which include being group writeable. Unfortunately logrotate does not mention that it is ignoring these files unless it is especially run in verbose mode, which makes tracking down this problem more difficult. Other configuration errors usually generate notification emails. Thanks, Roger -- Package-specific info: Contents of /etc/logrotate.d total 96 -rw-r--r-- 1 root root 173 Jun 29 13:31 apt -rw-r--r-- 1 root root 79 Jun 9 11:14 aptitude -rw-r--r-- 1 root root 215 Oct 27 2010 checksecurity -rw-r--r-- 1 root root 209 Oct 11 20:20 clamav-daemon -rw-r--r-- 1 root root 230 Oct 11 20:20 clamav-freshclam -rw-r--r-- 1 root root 232 Jun 17 10:05 dpkg -rw-r--r-- 1 root root 147 Aug 26 01:21 exim4-base -rw-r--r-- 1 root root 146 Jun 23 18:16 exim4-base.dist -rw-r--r-- 1 root root 146 Jun 23 18:16 exim4-base~ -rw-r--r-- 1 root root 126 Jun 23 18:16 exim4-paniclog -rw-r--r-- 1 root root 150 Oct 16 17:04 local -rw-rw-r-- 1 root root 142 Oct 16 17:00 local~ -rw-r--r-- 1 root root 356 Aug 4 17:17 nginx -rw-r--r-- 1 root root 94 Jun 22 22:44 ppp -rw-r--r-- 1 root root 88 Nov 15 2011 razor -rw-r--r-- 1 root root 536 Oct 16 17:02 rsyslog -rw-r--r-- 1 root root 515 Jun 9 20:54 rsyslog.dist -rw-r--r-- 1 root root 517 Aug 26 01:20 rsyslog~ -rw-r--r-- 1 root root 322 Aug 5 18:07 samba -rw-r--r-- 1 root root 108 Jul 3 00:31 shorewall -rw-r--r-- 1 root root 85 Jul 3 00:29 shorewall-init -rw-r--r-- 1 root root 109 Jul 3 00:32 shorewall6 -rw-r--r-- 1 root root 298 Jun 3 19:38 stunnel4 -rw-r--r-- 1 root root 148 Jun 9 21:45 ulogd -- System Information: Debian Release: wheezy/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing-proposed-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages logrotate depends on: ii base-passwd 3.5.26 ii cron [cron-daemon] 3.0pl1-124 ii libc6 2.13-35 ii libpopt01.16-7 ii libselinux1 2.1.9-5 Versions of packages logrotate recommends: ii bsd-mailx [mailx] 8.1.2-0.2006cvs-1 logrotate suggests no packages. -- Configuration Files: /etc/logrotate.conf changed: weekly rotate 4 create tabooext + .dist include /etc/logrotate.d /var/log/wtmp { missingok monthly create 0664 root utmp rotate 1 } /var/log/btmp { missingok monthly create 0660 root utmp rotate 1 } -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#614582: harmless warning about acls from btrfs
Package: squashfs-tools Version: 1:4.2-5 Followup-For: Bug #614582 These warning also occur with ext4. Thanks, Roger -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages squashfs-tools depends on: ii libc6 2.13-35 ii liblzma5 5.1.1alpha+20120614-1 ii liblzo2-2 2.06-1 ii zlib1g 1:1.2.7.dfsg-13 squashfs-tools recommends no packages. squashfs-tools suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#690129: netplug: Please make clear the differences between netplug and ifplugd in the long description
Package: netplug Version: 1.2.9.2-1 Severity: wishlist Hi, Netplug claims to be better than ifplugd, but it does not support all of ifplugd's functions (in particular: "Can be configured to ignore short unplugged or plugged periods"). Please indicate which ifplugd fuctions are not supported in the package's long description. Thanks, Roger -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages netplug depends on: ii iproute 20120521-3 ii libc62.13-35 netplug recommends no packages. netplug suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#688789: /sbin/lvcreate: lvcreate/lvremove --quiet are not quiet
Package: lvm2 Version: 2.02.95-4 Severity: normal File: /sbin/lvcreate Every invocation of lvcreate --quiet or lvremove --quiet from a /bin/sh script called from bash outputs: File descriptor 3 (/usr/share/bash-completion/completions) leaked on lvcreate invocation. Parent PID 32675: /bin/sh Logical volume "backup" created or: File descriptor 3 (/usr/share/bash-completion/completions) leaked on lvremove invocation. Parent PID 32675: /bin/sh Logical volume "backup" successfully removed Having wasted quite a bit of time investigating this error message at least I know that is apparently meaningless and can be safely ignored. Perhaps this will be useful to other people encountering this error. Thanks, Roger -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lvm2 depends on: ii dmsetup 2:1.02.74-4 ii initscripts 2.88dsf-32 ii libc6 2.13-35 ii libdevmapper-event1.02.1 2:1.02.74-4 ii libdevmapper1.02.12:1.02.74-4 ii libreadline5 5.2-11 ii libudev0 175-7 ii lsb-base 4.1+Debian7 lvm2 recommends no packages. lvm2 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#586757: /usr/bin/mksquashfs: Re: please add --one-filesytem to mksquashfs
Package: squashfs-tools Version: 1:4.2-5 Followup-For: Bug #586757 Hi, It seems surprising that mksquashfs does not have a --one-file-system option when so many related commands include it and it would make using squashfs for backup purposes much easier. I am struggling to find any record of this issue being forwarded to the squashfs-devel mailing list in any list archives. When was this done? Thanks, Roger -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages squashfs-tools depends on: ii libc6 2.13-35 ii liblzma5 5.1.1alpha+20120614-1 ii liblzo2-2 2.06-1 ii zlib1g 1:1.2.7.dfsg-13 squashfs-tools recommends no packages. squashfs-tools suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#588349: shorewall: tcpri ports
On 07/07/2010 15:57, Roger Lynn wrote: > It would be useful if it was possible to specify source and destination > ports separately in /etc/shorewall/tcpri Upon rereading the documentation (shorewall-tcpri(5)) for this feature for a new installation, it is not clear whether the port column refers to the source or destination port and I may have previously misunderstood its function. If it is the source, as the adjacent address column is, then it is of limited use as the source port for connections is rarely predictable. Roger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#687437: shorewall: README.Debian gives wrong location for default configuration files
Package: shorewall Version: 4.5.5.3-1 Severity: minor README.Debian and upstream's documentation give the location of the default upstream configuration files as /usr/share/doc/shorewall/default-config/ whereas they actually appear to be in /usr/share/shorewall/configfiles/ Thanks, Roger -- -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages shorewall depends on: ii bc 1.06.95-2+b1 ii debconf [debconf-2.0] 1.5.46 ii iproute20120521-3 ii iptables 1.4.14-3 ii perl-modules 5.14.2-12 ii shorewall-core 4.5.5.3-1 shorewall recommends no packages. Versions of packages shorewall suggests: ii linux-image-3.2.0-3-amd64 [linux-image] 3.2.23-1 ii make 3.81-8.2 ii shorewall-doc4.5.5-1 -- Configuration Files: /etc/default/shorewall changed: startup=0 OPTIONS="" STARTOPTIONS="" RESTARTOPTIONS="" INITLOG=/dev/null SAFESTOP=1 /etc/shorewall/params [Errno 13] Permission denied: u'/etc/shorewall/params' /etc/shorewall/shorewall.conf changed: STARTUP_ENABLED=Yes VERBOSITY=1 BLACKLIST_LOGLEVEL=info LOG_MARTIANS=Yes LOG_VERBOSITY=2 LOGALLNEW= LOGFILE=/var/log/ulog/syslogemu.log LOGFORMAT="Shwl:%s:%s:" LOGTAGONLY=No LOGLIMIT=10/sec:10 MACLIST_LOG_LEVEL=info RELATED_LOG_LEVEL= SFILTER_LOG_LEVEL=info SMURF_LOG_LEVEL=info STARTUP_LOG=/var/log/shorewall-init.log TCP_FLAGS_LOG_LEVEL=info CONFIG_PATH="${CONFDIR}/shorewall:${SHAREDIR}/shorewall" GEOIPDIR=/usr/share/xt_geoip/LE IPTABLES= IP= IPSET= LOCKFILE= MODULESDIR= PATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin" PERL=/usr/bin/perl RESTOREFILE=restore SHOREWALL_SHELL=/bin/sh SUBSYSLOCK="" TC= ACCEPT_DEFAULT=none DROP_DEFAULT=Drop NFQUEUE_DEFAULT=none QUEUE_DEFAULT=none REJECT_DEFAULT=Reject RCP_COMMAND='scp ${files} ${root}@${system}:${destination}' RSH_COMMAND='ssh ${root}@${system} ${command}' ACCOUNTING=Yes ACCOUNTING_TABLE=filter ADD_IP_ALIASES=No ADD_SNAT_ALIASES=No ADMINISABSENTMINDED=Yes AUTO_COMMENT=Yes AUTOMAKE=Yes BLACKLISTNEWONLY=Yes CLAMPMSS=No CLEAR_TC=Yes COMPLETE=Yes DELETE_THEN_ADD=Yes DETECT_DNAT_IPADDRS=No DISABLE_IPV6=No DONT_LOAD= DYNAMIC_BLACKLIST=Yes EXPAND_POLICIES=No EXPORTMODULES=Yes FASTACCEPT=Yes FORWARD_CLEAR_MARK= IMPLICIT_CONTINUE=No IPSET_WARNINGS=Yes IP_FORWARDING=On KEEP_RT_TABLES=No LEGACY_FASTSTART=No LOAD_HELPERS_ONLY=Yes MACLIST_TABLE=filter MACLIST_TTL= MANGLE_ENABLED=Yes MAPOLDACTIONS=No MARK_IN_FORWARD_CHAIN=No MODULE_SUFFIX=ko MULTICAST=No MUTEX_TIMEOUT=30 NULL_ROUTE_RFC1918=Yes OPTIMIZE=31 OPTIMIZE_ACCOUNTING=Yes REQUIRE_INTERFACE=No RESTORE_DEFAULT_ROUTE=Yes RETAIN_ALIASES=No ROUTE_FILTER=Yes SAVE_IPSETS=No TC_ENABLED=Simple TC_EXPERT=No TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2" TRACK_PROVIDERS=No USE_DEFAULT_RT=No USE_PHYSICAL_NAMES=No ZONE2ZONE=2 BLACKLIST_DISPOSITION=DROP MACLIST_DISPOSITION=REJECT RELATED_DISPOSITION=ACCEPT SMURF_DISPOSITION=DROP SFILTER_DISPOSITION=DROP TCP_FLAGS_DISPOSITION=DROP TC_BITS= PROVIDER_BITS= PROVIDER_OFFSET= MASK_BITS= ZONE_BITS=0 IPSECFILE=zones -- debconf information: shorewall/dont_restart: shorewall/major_release: shorewall/invalid_config: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#679491: marked as done ([fetchmail] Spamassassin-Fetchmail depedenty boot order needs fixing)
On 30/08/2012 15:00, Debian Bug Tracking System wrote: > Closing this bug report. Imho this report is bogus and there has been no > further activity. Then how should one ensure that Fetchmail starts after Spamassassin, which is the only startup order that makes sense? Roger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684128: false advertising
On 08/08/2012 09:19, Herbert Kaminski wrote: > Please have a look at IEC 60027-2 (or Wikipedia) to make clear that > the wording is absolutely correct. So if anybody wants to change > the units of measurement, a change to the wording _and_ the code > is required. I don't think anyone has suggested that the wording is wrong, just not what is expected by many users. (Not that I agree with those standards, but that's irrelevant.) Roger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684128: false advertising
On 08/08/12 07:20, Didier 'OdyX' Raboud wrote: > Le mardi, 7 août 2012 22.46:03, Roger Lynn a écrit : >> This has caught me out in the past. When it says gigabyte I expect 2^30 >> bytes. Hopefully this time when I do an installation I will remember to get >> a calculator out. The people who don't care are mostly those who don't know >> what a gigabyte is. > > (FTR, that's near to be insulting in my standards…) I'm sorry, that was over the top. > I know what giga- and gibi-bytes are, but I still don't care right now; we > are > actually trying to get Wheezy out and there are other priorities (such as 572 > Release-Critical bugs) than this type of problem. Absolutely agreed. I wouldn't hope to see this fixed for Wheezy - even just changing the wording of the text requires an enormous amount of work at this stage - it's just frustrating to see it apparently being dismissed out of hand as not being a problem. Thanks, Roger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org