Bug#1051076: dash: test does not support s1 < s2 or s1 > s2
severity 1051076 grave thanks Thinking about it, grave seems a more appropriate severity as the issue could cause data loss in case s2 happens to be the pathname of an existent file when using the form `test s1 > s2`.
Bug#1051076: dash: test does not support s1 < s2 or s1 > s2
Package: dash Version: 0.5.12-6 Severity: normal Tags: upstream dash supposedly implements test s1 < s2 and test s1 > s2 for string comparisons. A cursory glance at [0], [1] and [2] seems to confirm this. Anyway the shell redirection seems to take precedence so that the test is not actually performed. > dash $ type test test is a shell builtin $ ls -l bar ls: cannot access 'bar': No such file or directory $ test "foo" < "bar" dash: 2: cannot open bar: No such file $ test "foo" > "bar" $ ls -l bar -rw-r--r-- 1 gpiero gpiero 0 Sep 2 12:51 bar As a side note, '<' and '>' are not mandated by POSIX [3]. Thanks, Gian Piero. [0] https://git.kernel.org/pub/scm/utils/dash/dash.git/tree/src/dash.1 [1] https://git.kernel.org/pub/scm/utils/dash/dash.git/tree/src/bltin/test.1 [2] https://git.kernel.org/pub/scm/utils/dash/dash.git/tree/src/bltin/test.c (STRLT and STRGT) [3] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: OpenRC (via /run/openrc), PID 1: init LSM: AppArmor: enabled Versions of packages dash depends on: ii debianutils 5.11 ii dpkg 1.22.0 ii libc62.37-7 dash recommends no packages. dash suggests no packages. -- no debconf information
Bug#1012395: start-stop-daemon: matching only on non-root pidfile /run/netdata.pid is insecure
Package: netdata-core Version: 1.34.1-1+b1 Severity: normal Tags: patch Init: OpenRC (via /run/openrc), PID 1: init > ls -l /run/netdata.pid ls: cannot access '/run/netdata.pid': No such file or directory > sudo service netdata start Starting the netdata daemon...2022-06-06 12:09:40: netdata INFO : MAIN : CONFIG: cannot load cloud config '/var/lib/netdata/cloud.d/cloud.conf'. Running with internal defaults. done. > sudo service netdata status netdata is running. > sudo service netdata stop Stopping the netdata daemon...start-stop-daemon: matching only on non-root pidfile /run/netdata.pid is insecure failed (/usr/sbin/netdata died: process 12267 not running; or permission denied). > ls -l /run/netdata.pid -rw-r--r-- 1 netdata netdata 6 Jun 6 12:09 /run/netdata.pid > pgrep -l netdata 12267 netdata 12269 netdata Thanks, Gian Piero. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: OpenRC (via /run/openrc), PID 1: init LSM: AppArmor: enabled Versions of packages netdata-core depends on: ii init-system-helpers 1.63 ii libc62.33-7 ii libcap2 1:2.44-1 ii libcap2-bin 1:2.44-1 ii libjson-c5 0.16-1 ii libjudydebian1 1.0.5-5+b2 ii liblz4-1 1.9.3-2 ii libmnl0 1.0.4-3 ii libnetfilter-acct1 1.0.3-3 ii libssl3 3.0.3-6 ii libuuid1 2.38-4 ii libuv1 1.44.1-2 ii lsb-base 11.2 ii zlib1g 1:1.2.11.dfsg-4 Versions of packages netdata-core recommends: ii curl 7.83.1-1+b1 Versions of packages netdata-core suggests: ii apcupsd 3.14.14-3.1 ii iproute25.17.0-2 ii iw 5.16-1 ii lm-sensors 1:3.6.0-7 pn nc -- Configuration Files: /etc/netdata/netdata.conf changed [not included] -- no debconf information --- a/netdata 2022-04-15 22:03:48.0 +0200 +++ b/netdata 2022-06-06 12:23:43.413715597 +0200 @@ -46,8 +46,8 @@ log_action_begin_msg "Starting $DESC" - if start-stop-daemon --start --quiet --pidfile $PIDFILE --startas $DAEMON --test; then - if start-stop-daemon --start --quiet --pidfile $PIDFILE --startas $DAEMON -- $DAEMON_ARGS; then + if start-stop-daemon --start --quiet --pidfile $PIDFILE --name $NAME --startas $DAEMON --test; then + if start-stop-daemon --start --quiet --pidfile $PIDFILE --name $NAME --startas $DAEMON -- $DAEMON_ARGS; then log_action_end_msg 0 else log_action_end_msg 1 @@ -65,7 +65,7 @@ exit 0 fi - if start-stop-daemon --stop --quiet --pidfile $PIDFILE --retry=$STOP_SCHEDULE; then + if start-stop-daemon --stop --quiet --pidfile $PIDFILE --name $NAME --retry=$STOP_SCHEDULE; then log_action_end_msg 0 else log_action_end_msg 1 "$DAEMON died: process $pid not running; or permission denied"
Bug#963341: fixed 873699 in 3.15.2-3, fixed 963341 in 3.15.2-3
fixed 873699 3.15.2-3 fixed 963341 3.15.2-3 thanks Sorry, it seems I've messed up the changelog entries for 3.15.2-3. This must now be closed manually.
Bug#963341: cfengine3: New cfengine 3.15.2 package is broken and non-functional
Package: cfengine3 Followup-For: Bug #963341 Hi, just a friendly ping that https://salsa.debian.org/cfengine-team/cfengine3/-/merge_requests/2 fixes this (admittely also includes not strictly needed changes, tho). Ciao, Gian Piero. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'stable-updates'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-3-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages cfengine3 depends on: ii e2fsprogs 1.45.6-1 ii libacl1 2.2.53-8 ii libc6 2.31-3 ii liblmdb0 0.9.24-1 ii libpam0g 1.3.1-5 ii libpcre3 2:8.39-13 ii libpromises3 3.15.2-2.1 ii libssl1.1 1.1.1g-1 ii libvirt0 6.6.0-2 ii libxml2 2.9.10+dfsg-6 ii libyaml-0-2 0.2.2-1 ii lsb-base 11.1.0 Versions of packages cfengine3 recommends: ii python 2.7.17-2 cfengine3 suggests no packages. -- Configuration Files: /etc/default/cfengine3 changed: RUN_CFMONITORD=1 RUN_CFSERVERD=1 RUN_CFEXECD=1 CFMONITORD_ARGS="" CFSERVERD_ARGS="" CFEXECD_ARGS="" -- no debconf information
Bug#962909: 'Error: map definition does not specify mapping data type' with anonymous sets
Package: nftables
Version: 0.9.5-1
Severity: normal
Tags: upstream
Dear Maintainer,
since when v0.9.5 has entered sid, I've been experiencing:
---
$ sudo nft -f /etc/nftables.conf
/etc/nftables.conf:45:22-9: Error: map definition does not specify mapping data
type
iifname vmap {
$ tail -n+45 /etc/nftables.conf | head -n4
iifname vmap {
wlp2s0: jump in_wlan,
enp0s31f6: jump in_eth,
}
---
It should have been fixed in
http://git.netfilter.org/nftables/commit/?id=54eb1e16cc4787906fe8206858f0ea0bfb9c1209
Thanks,
Gian Piero.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'stable-updates'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages nftables depends on:
ii dpkg 1.19.7
ii libc6 2.30-8
ii libnftables1 0.9.5-1
ii libreadline8 8.0-4
nftables recommends no packages.
Versions of packages nftables suggests:
pn firewalld
-- Configuration Files:
/etc/nftables.conf changed [not included]
-- no debconf information
Bug#955135: TypeError: '<' not supported between instances of 'NotImplementedType' and 'int'
* [Sun, Mar 29, 2020 at 07:46:31PM +0200] Bálint Réczey: Could you please check the output of: sudo unattended-upgrade --download-only --verbose -d apt list --upgradable And tell which package (version) triggers the error? I tried reproducing it locally and I don't see it with the package set installed on my sid system. Hi Bálint, please find the output in the attached file. I had just performed a manual dist-upgrade, so the only blocked packages were libssl1.1 (which I had to block for unrelated reasons) and isc-dhcp-client/unstable 4.4.1-2.1+b2 amd64 [upgradable from: 4.4.1-2.1+b1] that seems to be the cause. Thank you, Gian Piero. $ sudo unattended-upgrade --download-only --verbose -d Starting unattended upgrades script Allowed origins are: o=Debian, n=sid Initial blacklist: Initial whitelist (not strict): Marking not allowed with -32768 pin Marking not allowed with -32768 pin Applying pinning: PkgFilePin(id=1, priority=-32768) Applying pin -32768 to package_file: Applying pinning: PkgFilePin(id=0, priority=-32768) Applying pin -32768 to package_file: Using (^linux-.*-[1-9][0-9]*\.[0-9]+\.[0-9]+-[0-9]+(-.+)?$|^kfreebsd-.*-[1-9][0-9]*\.[0-9]+\.[0-9]+-[0-9]+(-.+)?$|^gnumach-.*-[1-9][0-9]*\.[0-9]+\.[0-9]+-[0-9]+(-.+)?$|^.*-modules-[1-9][0-9]*\.[0-9]+\.[0-9]+-[0-9]+(-.+)?$|^.*-kernel-[1-9][0-9]*\.[0-9]+\.[0-9]+-[0-9]+(-.+)?$|^linux-.*-[1-9][0-9]*\.[0-9]+\.[0-9]+-[0-9]+(-.+)?$|^kfreebsd-.*-[1-9][0-9]*\.[0-9]+\.[0-9]+-[0-9]+(-.+)?$|^gnumach-.*-[1-9][0-9]*\.[0-9]+\.[0-9]+-[0-9]+(-.+)?$|^.*-modules-[1-9][0-9]*\.[0-9]+\.[0-9]+-[0-9]+(-.+)?$|^.*-kernel-[1-9][0-9]*\.[0-9]+\.[0-9]+-[0-9]+(-.+)?$) regexp to find kernel packages Using (^linux-.*-5\.4\.0\-4\-amd64$|^linux-.*-5\.4\.0\-4$|^kfreebsd-.*-5\.4\.0\-4\-amd64$|^kfreebsd-.*-5\.4\.0\-4$|^gnumach-.*-5\.4\.0\-4\-amd64$|^gnumach-.*-5\.4\.0\-4$|^.*-modules-5\.4\.0\-4\-amd64$|^.*-modules-5\.4\.0\-4$|^.*-kernel-5\.4\.0\-4\-amd64$|^.*-kernel-5\.4\.0\-4$|^linux-.*-5\.4\.0\-4\-amd64$|^linux-.*-5\.4\.0\-4$|^kfreebsd-.*-5\.4\.0\-4\-amd64$|^kfreebsd-.*-5\.4\.0\-4$|^gnumach-.*-5\.4\.0\-4\-amd64$|^gnumach-.*-5\.4\.0\-4$|^.*-modules-5\.4\.0\-4\-amd64$|^.*-modules-5\.4\.0\-4$|^.*-kernel-5\.4\.0\-4\-amd64$|^.*-kernel-5\.4\.0\-4$) regexp to find running kernel packages Checking: isc-dhcp-client ([]) falling back to adjusting isc-dhcp-client's dependencies An error occurred: '<' not supported between instances of 'NotImplementedType' and 'int' Traceback (most recent call last): File "/usr/bin/unattended-upgrade", line 1986, in main res = run(options, rootdir, mem_log, logfile_dpkg, File "/usr/bin/unattended-upgrade", line 2157, in run pkgs_to_upgrade = calculate_upgradable_pkgs(cache, options) File "/usr/bin/unattended-upgrade", line 1747, in calculate_upgradable_pkgs try_to_upgrade(pkg, File "/usr/bin/unattended-upgrade", line 1706, in try_to_upgrade cache.mark_upgrade_adjusted(pkg, from_user=not pkg.is_auto_installed) File "/usr/bin/unattended-upgrade", line 438, in mark_upgrade_adjusted self.call_adjusted(apt.package.Package.mark_upgrade, pkg, **kwargs) File "/usr/bin/unattended-upgrade", line 405, in call_adjusted self.adjust_candidate(self[dep]) File "/usr/bin/unattended-upgrade", line 345, in adjust_candidate if new_cand < pkg.candidate: File "/usr/lib/python3/dist-packages/apt/package.py", line 514, in __lt__ return self._cmp(other) < 0 TypeError: '<' not supported between instances of 'NotImplementedType' and 'int' Extracting content from /var/log/unattended-upgrades/unattended-upgrades-dpkg.log since 2020-03-29 20:17:20 Sending mail to root mail returned: 0 Traceback (most recent call last): File "/usr/bin/unattended-upgrade", line 2512, in sys.exit(main(options)) File "/usr/bin/unattended-upgrade", line 1986, in main res = run(options, rootdir, mem_log, logfile_dpkg, File "/usr/bin/unattended-upgrade", line 2157, in run pkgs_to_upgrade = calculate_upgradable_pkgs(cache, options) File "/usr/bin/unattended-upgrade", line 1747, in calculate_upgradable_pkgs try_to_upgrade(pkg, File "/usr/bin/unattended-upgrade", line 1706, in try_to_upgrade cache.mark_upgrade_adjusted(pkg, from_user=not pkg.is_auto_installed) File "/usr/bin/unattended-upgrade", line 438, in mark_upgrade_adjusted self.call_adjusted(apt.package.Package.mark_upgrade, pkg, **kwargs) File "/usr/bin/unattended-upgrade", line 405, in call_adjusted self.adjust_candidate(self[dep]) File "/usr/bin/unattended-upgrade", line 345, in adjust_candidate if new_cand < pkg.candidate: File "/usr/lib/python3/dist-packages/apt/package.py", line 514, in __lt__ return self._cmp(other) < 0 TypeError: '<' not supported between instances of 'NotImplementedType' and 'int' $ apt list --upgradable WARNING: apt does not have a stable CLI interface. Use with caution in scripts. Listing... isc-dhcp-client/unstable 4.4.1-2.1+b2 amd64 [upgradable from: 4.4.1-2.1+b1] libssl1.1/unstable 1.1.1e-1 amd64
Bug#955135: TypeError: '<' not supported between instances of 'NotImplementedType' and 'int'
Package: unattended-upgrades Version: 2.0 Followup-For: Bug #955135 Control: severity -1 grave Raising the severity as this bug prevents the installation of any upgraded package. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages unattended-upgrades depends on: ii debconf [debconf-2.0] 1.5.73 ii lsb-base 11.1.0 ii lsb-release11.1.0 ii python33.8.2-2 ii python3-apt1.9.10 ii python3-dbus 1.2.16-1 ii python3-distro-info0.23 ii ucf3.0038+nmu1 ii xz-utils 5.2.4-1+b1 Versions of packages unattended-upgrades recommends: ii anacron 2.3-29 ii cron [cron-daemon] 3.0pl1-136 Versions of packages unattended-upgrades suggests: ii bsd-mailx 8.1.2-0.20180807cvs-1+b1 ii dma [mail-transport-agent] 0.12-1 ii needrestart 3.4-6 ii powermgmt-base 1.36 ii python3-gi 3.36.0-1 -- debconf information: unattended-upgrades/enable_auto_updates: true
Bug#953534: SyntaxWarning: "is" with a literal. Did you mean "=="? after having upgraded python to 3.8.2-1
Package: python3-jmespath Version: 0.9.4-2 Severity: minor After having upgraded python3:amd64 from 3.7.5-3 to 3.8.2-1, launching an ansible playbook results in a lot of syntax warnings: --- /usr/lib/python3/dist-packages/jmespath/visitor.py:32: SyntaxWarning: "is" with a literal. Did you mean "=="? if x is 0 or x is 1: /usr/lib/python3/dist-packages/jmespath/visitor.py:32: SyntaxWarning: "is" with a literal. Did you mean "=="? if x is 0 or x is 1: /usr/lib/python3/dist-packages/jmespath/visitor.py:34: SyntaxWarning: "is" with a literal. Did you mean "=="? elif y is 0 or y is 1: /usr/lib/python3/dist-packages/jmespath/visitor.py:34: SyntaxWarning: "is" with a literal. Did you mean "=="? elif y is 0 or y is 1: /usr/lib/python3/dist-packages/jmespath/visitor.py:260: SyntaxWarning: "is" with a literal. Did you mean "=="? if original_result is 0: --- Thank you, Gian Piero. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages python3-jmespath depends on: ii python3 3.8.2-1 python3-jmespath recommends no packages. python3-jmespath suggests no packages. -- no debconf information
Bug#953530: samba-common-bin: post-install fails with "lock directory /run/samba does not exist"
Package: samba-common-bin Version: 2:4.11.5+dfsg-1+b1 Severity: normal While upgrading samba-common-bin from 2:4.11.5+dfsg-1 to 2:4.11.5+dfsg-1+b1: --- Performing actions... Setting up samba-common-bin (2:4.11.5+dfsg-1+b1) ... Checking smb.conf with testparm Load smb config files from /etc/samba/smb.conf Loaded services file OK. ERROR: lock directory /run/samba does not exist ERROR: pid directory /run/samba does not exist Server role: ROLE_STANDALONE dpkg: error processing package samba-common-bin (--configure): installed samba-common-bin package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: samba-common-bin E: Sub-process /usr/bin/dpkg returned an error code (1) --- samba-common-bin was installed as a dependency of smbclient, the "server role" message is misleading as I don't have any need for a SMB server (and for any lock or pidfile, afaik). Thank you, Gian Piero. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages samba-common-bin depends on: ii libbsd00.10.0-1 ii libc6 2.29-10 ii libgnutls303.6.12-2 ii libldap-2.4-2 2.4.49+dfsg-2 ii libncurses66.2-1 ii libpopt0 1.16-14 ii libreadline8 8.0-4 ii libtalloc2 2.3.0-5 ii libtdb11.4.2-3+b1 ii libtevent0 0.10.1-4 ii libtinfo6 6.2-1 ii libwbclient0 2:4.11.5+dfsg-1+b1 ii python33.8.2-1 ii python3-samba 2:4.11.5+dfsg-1+b1 ii samba-common 2:4.11.5+dfsg-1 ii samba-libs 2:4.11.5+dfsg-1+b1 Versions of packages samba-common-bin recommends: ii samba-dsdb-modules 2:4.11.5+dfsg-1+b1 Versions of packages samba-common-bin suggests: pn heimdal-clients ii python3-dnspython 1.16.0-2 pn python3-markdown -- no debconf information
Bug#941344: xsane-common: does not ship xsane-startimage.pnm, preventing the preview from working
Package: xsane-common Version: 0.999-7 Severity: important Dear Maintainer, xsane-common 0.999-7 does not ship /usr/share/sane/xsane/xsane-startimage.pnm, resulting in a preview window not working. $ dpkg -l xsane\* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==--- ii xsane 0.999-7 amd64featureful graphical frontend for SANE (Scanner Access Now Easy) ii xsane-common 0.999-7 all xsane architecture independent files $ dpkg -L xsane xsane-common |grep xsane-startimage $ $ xsane [xsane] ERROR: xsane-startimage not found. Looks like xsane is not installed correct. Downgrading to 0.999-6/0.999-6+b1 solves the issue: $ dpkg -l xsane\* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==--- ii xsane 0.999-6+b1 amd64featureful graphical frontend for SANE (Scanner Access Now Easy) ii xsane-common 0.999-6 all xsane architecture independent files $ dpkg -L xsane-common|grep xsane-startimage /usr/share/sane/xsane/xsane-startimage.pnm Thank you, Gian Piero. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled xsane-common depends on no packages. Versions of packages xsane-common recommends: ii xsane 0.999-7 xsane-common suggests no packages. -- no debconf information
Bug#935498: burp: missing default file
Package: burp Version: 2.2.18-2 Severity: normal Dear Maintainer, the current burp package *does* contain a sysvinit script (as reported in the changelog for v2.2.18-2), but misses the default file that's referenced by the sysvinit script: $ sudo invoke-rc.d burp status burp disabled; edit /etc/default/burp $ dpkg -l burp | grep ^ii ii burp 2.2.18-2 amd64Simple cross-platform network BackUp and Restore Program $ dpkg -L burp | grep default || echo "NOT PRESENT" NOT PRESENT I would suggest to reintroduce the default file as it was in previous versions of the package: --8<-- # Defaults for burp initscript # sourced by /etc/init.d/burp # installed at /etc/default/burp by the maintainer scripts # # This is a POSIX shell fragment # RUN=no # Additional options that are passed to the Daemon. DAEMON_ARGS="-c /etc/burp/burp-server.conf" --8<-- I also suggest adding a comment before the RUN= assignement along the line of: # Change to RUN=yes in order to run the burp server Thanks, Gian Piero. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages burp depends on: ii init-system-helpers 1.57 ii libacl1 2.2.53-4 ii libc62.28-10 ii libncurses6 6.1+20190803-1 ii librsync22.0.2-1 hi libssl1.11.1.1a-1 ii libtinfo66.1+20190803-1 ii lsb-base 11.1.0 ii zlib1g 1:1.2.11.dfsg-1+b1 Versions of packages burp recommends: ii openssl 1.1.1c-1 burp suggests no packages. -- Configuration Files: /etc/burp/burp-server.conf [Errno 13] Permission denied: '/etc/burp/burp-server.conf' /etc/burp/burp.conf [Errno 13] Permission denied: '/etc/burp/burp.conf' /etc/burp/clientconfdir/incexc/example [Errno 13] Permission denied: '/etc/burp/clientconfdir/incexc/example' /etc/burp/clientconfdir/testclient [Errno 13] Permission denied: '/etc/burp/clientconfdir/testclient' -- no debconf information
Bug#923438: tinc: breaks after upgrading libssl1.1 to v1.1.1b-1
Package: tinc Version: 1.1~pre17-1.1 Severity: grave Justification: renders package unusable Dear Maintainer, after having upgraded libssl1.1 to 1.1.1b-1 (currently in sid), tinc breaks with: > Error while decrypting: error:060A7094:digital envelope > routines:EVP_EncryptUpdate:invalid operation Downgrading libssl1.1 to 1.1.1a-1 solves the issue. Please feel free to reassign to libssl1.1 if you think it should be fixed on their side. Thanks, Gian Piero. *** 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 *** -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages tinc depends on: ii libc6 2.28-7 ii liblzo2-2 2.10-0.1 ii libminiupnpc17 2.1-1+b1 ii libncurses6 6.1+20181013-2 ii libreadline77.0-5 ii libssl1.1 1.1.1a-1 ii libtinfo6 6.1+20181013-2 ii zlib1g 1:1.2.11.dfsg-1 tinc recommends no packages. tinc suggests no packages. -- Configuration Files: /etc/default/tinc changed: LIMITS="-l 32768 -n 512" -- no debconf information
Bug#873930: linux-image-4.9.0-3-amd64: nf_conntrack_sane does not work anymore
Package: src:linux Version: 4.9.30-2+deb9u3 Severity: normal Dear Maintainer, I've recently noted that after having upgraded my home server to stretch, I cannot use the scanner attached to the server remotely via network anymore. Like FTP in passive mode, the saned daemon listens on a control port for commands, then opens up a data port for letting the client retrieve the output file. nf_conntrack_sane is regularly loaded, but with kernel linux-image-4.9.0-3-amd64 it fails to recognize the connection trying to connect to the data port as related as the established connection to the control port. Booting back with the linux-image-3.16.0-4-amd64 from jessie fixes the issue. Thanks, Gian Piero. -- Package-specific info: ** Version: Linux version 4.9.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) ** Command line: BOOT_IMAGE=/vmlinuz-4.9.0-3-amd64 root=/dev/mapper/valentina_main-root ro quiet ** Not tainted ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: HP product_name: ProLiant MicroServer product_version: chassis_vendor: HP chassis_version: bios_vendor: HP bios_version: O41 ** Loaded modules: nf_conntrack_netlink nfnetlink cpufreq_powersave cpufreq_conservative cpufreq_userspace ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 nf_log_ipv6 ip6table_filter ip6_tables xt_multiport xt_recent xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack ipt_REJECT nf_reject_ipv4 nf_log_ipv4 nf_log_common xt_LOG xt_hashlimit iptable_filter nf_conntrack_sane nf_conntrack tun ip_tables x_tables loop parport_pc ppdev lp parport usblp amd64_edac_mod edac_mce_amd edac_core kvm_amd kvm irqbypass snd_hda_codec_hdmi snd_hda_intel amdkfd snd_hda_codec pcspkr radeon k10temp snd_hda_core evdev snd_hwdep joydev ttm snd_pcm snd_timer drm_kms_helper sg snd drm soundcore i2c_algo_bit sp5100_tco shpchp tpm_infineon button acpi_cpufreq ext4 crc16 jbd2 fscrypto lrw gf128mul glue_helper ablk_helper cryptd aes_x86_64 mbcache ecb cbc algif_skcipher af_alg dm_crypt dm_mod raid10 raid0 multipath linear hid_sunplus raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 uas usb_storage md_mod sr_mod cdrom sd_mod ata_generic hid_generic usbhid hid ohci_pci i2c_piix4 pata_atiixp tg3 ahci ptp pps_core libahci libphy libata ehci_pci ohci_hcd ehci_hcd scsi_mod usbcore usb_common ** PCI devices: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] RS880 Host Bridge [1022:9601] Subsystem: Hewlett-Packard Company RS880 Host Bridge [103c:1609] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- 00:01.0 PCI bridge [0604]: Hewlett-Packard Company Device [103c:9602] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel modules: shpchp 00:02.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] RS780 PCI to PCI bridge (ext gfx port 0) [1022:9603] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport Kernel modules: shpchp 00:06.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] RS780 PCI to PCI bridge (PCIE port 2) [1022:9606] (prog-if 00 [Normal decode]) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport Kernel modules: shpchp 00:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] [1002:4391] (rev 40) (prog-if 01 [AHCI 1.0]) Subsystem: Hewlett-Packard Company SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] [103c:1609] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: ahci Kernel modules: ahci 00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0
Bug#838437: bash: (readline) regression in the behaviour of ^W in vi-mode
Package: bash Version: 4.4-2 Followup-For: Bug #838437 According to [0], as a workaround you can re-enable the 4.3 behaviour by putting the following lines in your $HOME/.inputrc file (can confirm it works on my boxes): set bind-tty-special-chars Off set keymap vi-insert "\C-w": unix-word-rubout The downside is, obviously, the loss of the POSIX semantics for word boundaries. Ciao, Gian Piero. [0] http://lists.gnu.org/archive/html/bug-bash/2016-11/msg00024.html -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-1-amd64 (SMP w/2 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: sysvinit (via /sbin/init) Versions of packages bash depends on: ii base-files 9.6 ii dash 0.5.8-2.3 ii debianutils 4.8.1 ii libc62.24-7 ii libtinfo56.0+20160917-1 Versions of packages bash recommends: ii bash-completion 1:2.1-4.3 Versions of packages bash suggests: pn bash-doc -- no debconf information
Bug#844708: maildir-utils: `--clearlinks' option seems broken
Package: maildir-utils
Version: 0.9.17-1
Severity: important
Dear Maintainer,
thank you for your work on maildir-utils.
Version 0.9.17-1 seems to have broken the `--clearlinks' functionality,
at least on my system.
(ins) ~ $ mu find --muhome "${HOME}/.cache/mu" --format=links
--linksdir="${HOME}/.cache/mu/results" --clearlinks email
mu: failed to open /home/gpiero/.cache/mu/results/cur: No such file or
directory (73)
(cmd) ~ 73! mu find --muhome "${HOME}/.cache/mu" --format=links
--linksdir="${HOME}/.cache/mu/results" --clearlinks email
mu: failed to open /home/gpiero/.cache/mu/results/cur: No such file or
directory (73)
(cmd) ~ 73! mu find --muhome "${HOME}/.cache/mu" --format=links
--linksdir="${HOME}/.cache/mu/results" --clearlinks email
mu: failed to open /home/gpiero/.cache/mu/results/cur8: No such file or
directory (73)
(cmd) ~ 73! mu find --muhome "${HOME}/.cache/mu" --format=links
--linksdir="${HOME}/.cache/mu/results" --clearlinks email
mu: failed to open /home/gpiero/.cache/mu/results/curK: No such file or
directory (73)
(cmd) ~ 73! mu find --muhome "${HOME}/.cache/mu" --format=links
--linksdir="${HOME}/.cache/mu/results" --clearlinks email
mu: failed to open /home/gpiero/.cache/mu/results/cur: No such file or
directory (73)
(cmd) ~ 73! mu find --muhome "${HOME}/.cache/mu" --format=links
--linksdir="${HOME}/.cache/mu/results" --clearlinks email
mu: failed to open /home/gpiero/.cache/mu/results/curf: No such file or
directory (73)
Please note the seemingly random chars added at the end of the directory
path it cannot found. Maybe when not shown it's a non-printable char?
Anyway:
$ ls -ld /home/gpiero/.cache/mu/results/cur
drwx-- 2 gpiero gpiero 4096 Nov 18 11:23 /home/gpiero/.cache/mu/results/cur
Path exists w/ right permissions.
Without the use of the `--clearlinks' option it works (but links
have to be manually removed). Downgrading to 0.9.16-1+b1 re-enables the
right behaviour for `--clearlinks'.
Thank you,
Gian Piero.
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.8.0-1-amd64 (SMP w/2 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: sysvinit (via /sbin/init)
Versions of packages maildir-utils depends on:
ii dpkg1.18.15
ii guile-2.0-libs 2.0.13+1-2
ii install-info6.3.0.dfsg.1-1+b1
ii libc6 2.24-5
ii libgc1c21:7.4.2-8
ii libgcc1 1:6.2.0-13
ii libglib2.0-02.50.2-1
ii libgmime-2.6-0 2.6.20-8
ii libstdc++6 6.2.0-13
ii libxapian30 1.4.1-1
maildir-utils recommends no packages.
maildir-utils suggests no packages.
-- no debconf information
Bug#844440: mksh: make $( alias undefined-alias ) POSIX-compliant
Package: mksh Version: 54-2 Severity: wishlist Tags: upstream Dear Maintainer, thank you for your work on mksh. As for my reading of http://pubs.opengroup.org/onlinepubs/9699919799/utilities/alias.html, the behaviour of alias in mksh is not compliant when passed a not-existent alias. With bash 4.4-1 (as comparison): $ alias somecmd STDOUT: (nil) STDERR: -bash: alias: somecmd: not found RETCOD: 1 With mksh 54-2: $ alias somecmd STDOUT: somecmd alias not found STDERR: (nil) RETCOD: 0 The Open Group Specifications says: * STDOUT | The format for displaying aliases (when no operands or only name | operands are specified) shall be: | | "%s=%s\n", name, value As the alias was undefined, I think the bash behaviour (no STDOUT) is correct. * STDERR | The standard error shall be used only for diagnostic messages. Again, the bash behaviour seems more reasonable to me. * EXIT STATUS | The following exit values shall be returned: | | 0 Successful completion. | >0 One of the name operands specified did not have an alias | definition, or an error occurred. If I'm understanding it correctly, returning 0 in this context is a violation of this specification. Thank you, Gian Piero. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-1-amd64 (SMP w/2 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: sysvinit (via /sbin/init) Versions of packages mksh depends on: ii libc6 2.24-5 Versions of packages mksh recommends: ii ed 1.10-2.1 mksh suggests no packages. -- no debconf information
Bug#838437: bash: (readline) regression in the behaviour of ^W in vi-mode
Package: bash Version: 4.4-1 Severity: minor Dear Maintainer, bash 4.4-1 contains an allegedly regression wrt handling of ^W (Control-w) in vi-mode. After having red https://lists.gnu.org/archive/html/bug-bash/2016-09/msg00018.html, the obvious suspect seems to be > 2. New Features in Readline ... > m. The default binding for ^W in vi mode now uses word boundaries > specified by Posix (vi-unix-word-rubout is bindable command name). I could not find any documentation about 'vi-unix-word-rubout'. Anyway I'm not tagging this issue as 'upstream' as I haven't checked. $ set -o vi $ echo REMOVE maintain With bash-4.3-15 I can recall and modify the line positioning the cursor on the space between 'REMOVE' and 'maintain' and using ^W: Esc, k, e, e, l, i, Ctrl-w With bash-4.4-1 this doesn't work (does nothing), and I have to position the cursor on the start of the next word: Esc, k, w, w, i, Ctrl-w, Ctrl-w Anyway, it DOES work if I try to remove only part of the word (e.g.: leaving the last E): Esc, k, e, e, i, Ctrl-w Where it really becomes nasty is in presence of non alphanum chars: $ echo REMOVE .maintain Positioning the cursor on the dot succeeds in removing the space but then stop working: Esc, k, w, w, i, Ctrl-w, Ctrl-w OTOH, positioning the cursor on the char following the dot works (but in this case removes space and dot together as if there are no word boundaries): Esc, k, w, w, w, i, Ctrl-w, Ctrl-w Trying to modify a line like $ ls /tmp/ /var/ with ^W can be frustrating depending on where you start from. As from my limited tests, this issue does not seem affected by locale settings. Thanks, Gian Piero. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.7.0-1-amd64 (SMP w/2 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: sysvinit (via /sbin/init) Versions of packages bash depends on: ii base-files 9.6 ii dash 0.5.8-2.3 ii debianutils 4.8 ii libc62.24-3 ii libtinfo56.0+20160910-1 Versions of packages bash recommends: ii bash-completion 1:2.1-4.3 Versions of packages bash suggests: pn bash-doc -- no debconf information
Bug#822910: mutt-patched: silently dropped the sidebar-dotpathsep patch in favor of sidebar-dotted
severity 822910 wishlist retitle -1 mutt-patched: allow configurable delim_chars in sidebar thanks Hi Evgeni, thank you for your quick response. * [Fri, Apr 29, 2016 at 07:21:03PM +0200] Evgeni Golov: I personally prefer the sidebar-dotpathsep patch because: - has a summary listing # of unread/flagged/total messages instead of only unread/total Flagged should be supported according to docs, I never tried that, though. Yeah, sorry I've initially missed it. - has configurable mailboxes separator (in my case, the newly reintroduced patch does not correctly display maildirs containing a dot in the name) Did you try setting sidebar_folderindent? That worked fine here with dotted maildirs. Yes, this is the pseudo-diff of my config: - set sidebar_delim_chars = '/' + set sidebar_shortpath= yes + set sidebar_folderindent = yes Also, I'm not using dotted maildirs (dir.maildir1, dir.maildir2, ...), but nested dirs in which the leaf dirs are actually maildirs (dir/maildir1, dir/maildir2, ...). The name of some dirs contains a dot. i.e., the following tree (in which ham/spam are actually maildirs): .Junk/ ├── ham └── spam is rendered as: .Junk Junk/ham Junk/spam instead of: .Junk ham spam More important, the following tree (again, only inner dirs are maildir): domain.tld/ ├── server1 └── server2 is rendered as: tld tld/server1 tld/server2 instead of: domain.tld server1 server2 In this particular case, I'm "losing" infos about which domain the server belongs to. Anyway, while I think my directory tree is legit, I totally understand if you don't want to support this case. 'sidebar_delim_chars' is not valid anymore and 'sidebar_shortpath' can be used instead (sort of). I've added some details in https://anonscm.debian.org/cgit/pkg-mutt/mutt.git/commit/?id=00fe2d19fa615e25e10f9976a937358a42cd1be7 Could you have a look if that makes sense to you? Seems fine to me (maybe just use sidebar_delim_chars instead of delim_chars in order to point to the right option). As this is now documented, I'm downgrading the severity to wishlist. Thank you, Gian Piero.
Bug#823162: pseudo: wrong update-alternatives call in postinst
Package: pseudo Version: 1.7.5-4 Severity: grave Justification: renders package unusable Dear Maintainer, thank for your work on pseudo. This bug is presumably related to #805937, but I'm reporting it alone as it prevents a smooth installation of the package. During upgrade: Setting up pseudo (1.7.5-4) ... update-alternatives: error: alternative path /usr/bin/fakeroot-pseudo doesn't exist dpkg: error processing package pseudo (--configure): subprocess installed post-installation script returned error exit status 2 This is because of the update-alternatives invocation in postinst: configure) # continue below update-alternatives --install /usr/bin/fakeroot fakeroot \ /usr/bin/fakeroot-pseudo 5 \ --slave /usr/share/man/man1/fakeroot.1.gz \ fakeroot.1.gz /usr/share/man/man1/fakeroot-pseudo.1.gz ;; The pseudo package does not contain the fakeroot-pseudo wrapper (as a fix for #805937 ?): $ fgrep bin /var/lib/dpkg/info/pseudo.list /usr/bin /usr/bin/pseudolog /usr/bin/pseudodb /usr/bin/pseudo Thanks, Gian Piero. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.5.0-1-amd64 (SMP w/2 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: sysvinit (via /sbin/init) Versions of packages pseudo depends on: ii libc6 2.22-7 ii libpseudo 1.7.5-4 ii libsqlite3-0 3.12.2-1 pseudo recommends no packages. pseudo suggests no packages. -- no debconf information
Bug#822910: mutt-patched: silently dropped the sidebar-dotpathsep patch in favor of sidebar-dotted
* [Thu, Apr 28, 2016 at 10:32:17PM +0200] Gian Piero Carrubba: I personally prefer the sidebar-dotpathsep patch because: - has a summary listing # of unread/flagged/total messages instead of only unread/total Please disregard this, it seems I cannot see a number if it's just a few pixel away from where I suppose it should be. Ciao, Gian Piero.
Bug#822910: mutt-patched: silently dropped the sidebar-dotpathsep patch in favor of sidebar-dotted
Package: mutt-patched Version: 1.6.0-1 Severity: normal Dear Maintainers, thank you for your work on mutt. Mutt 1.6.0-1 is using the sidebar-dotted patch that was abandoned in 1.5.22-2 in favor of Gentoo's sidebar-dotpathsep. I personally prefer the sidebar-dotpathsep patch because: - has a summary listing # of unread/flagged/total messages instead of only unread/total - has configurable mailboxes separator (in my case, the newly reintroduced patch does not correctly display maildirs containing a dot in the name) Anyway, if even the reintroduction of the old patch was intentional, please document it in the NEWS.Debian file, noting that 'sidebar_delim_chars' is not valid anymore and 'sidebar_shortpath' can be used instead (sort of). Thank you, Gian Piero. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.5.0-1-amd64 (SMP w/2 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: sysvinit (via /sbin/init) Versions of packages mutt-patched depends on: ii libassuan02.4.2-3 ii libc6 2.22-7 ii libcomerr21.43~WIP.2016.03.15-2 ii libgnutls30 3.4.11-4 ii libgpg-error0 1.22-1 ii libgpgme111.6.0-3 ii libgssapi-krb5-2 1.13.2+dfsg-5 ii libidn11 1.32-3 ii libk5crypto3 1.13.2+dfsg-5 ii libkrb5-3 1.13.2+dfsg-5 ii libncursesw5 6.0+20160319-1 ii libsasl2-22.1.26.dfsg1-15 ii libtinfo5 6.0+20160319-1 ii libtokyocabinet9 1.4.48-10 ii mutt 1.6.0-1 mutt-patched recommends no packages. mutt-patched suggests no packages. -- no debconf information
Bug#821929: schroot: a probable race condition prevents instantiation of union chroots on linux 4.5
Package: schroot Version: 1.6.10-2 Severity: important Dear Maintainer, thank you for your work on schroot. After switching to linux 4.5, I cannot reliably use union chroots anymore. --- $ cat /etc/schroot/chroot.d/sid [sid] type=directory directory=/srv/chroot/cdeb/sid union-type=overlay users=gpiero source-users=gpiero setup.fstab=local/fstab --- Please note that the custom fstab option does NOT affect the issue. Also, the issue does NOT affect the source chroot: --- $ schroot -c source:sid -- cat /etc/debian_chroot sid $ schroot -c source:sid -- cat /etc/debian_chroot sid $ schroot -c source:sid -- cat /etc/debian_chroot sid $ schroot -c source:sid -- cat /etc/debian_chroot sid $ schroot -c source:sid -- cat /etc/debian_chroot sid --- It DOES affect the 'chroot' chroots, at least most of the times: --- $ schroot -c chroot:sid -- cat /etc/debian_chroot E: 15binfmt: update-binfmts: unable to open /var/run/schroot/mount/sid-56594f7b-8089-4ea1-949e-c9fdd521b5a7/bin/sh: Operation not permitted E: 20copyfiles: cp: cannot create regular file '/var/run/schroot/mount/sid-56594f7b-8089-4ea1-949e-c9fdd521b5a7/etc/resolv.conf': Operation not permitted E: 15binfmt: update-binfmts: unable to open /var/run/schroot/mount/sid-56594f7b-8089-4ea1-949e-c9fdd521b5a7/bin/sh: Operation not permitted E: sid-56594f7b-8089-4ea1-949e-c9fdd521b5a7: Chroot setup failed: stage=setup-start $ schroot -c chroot:sid -- cat /etc/debian_chroot E: Failed to execute “/bin/cat”: Operation not permitted $ schroot -c chroot:sid -- cat /etc/debian_chroot E: 20copyfiles: cp: cannot create regular file '/var/run/schroot/mount/sid-d29bf09f-51d4-4981-96db-4d3b8f423d85/etc/resolv.conf': Operation not permitted E: sid-d29bf09f-51d4-4981-96db-4d3b8f423d85: Chroot setup failed: stage=setup-start $ schroot -c chroot:sid -- cat /etc/debian_chroot E: 20copyfiles: cp: cannot create regular file '/var/run/schroot/mount/sid-e63468f6-8db0-4b68-ab9f-0fd8d9c6924e/etc/resolv.conf': Operation not permitted E: sid-e63468f6-8db0-4b68-ab9f-0fd8d9c6924e: Chroot setup failed: stage=setup-start $ schroot -c chroot:sid -- cat /etc/debian_chroot E: Failed to execute “/bin/cat”: Operation not permitted $ schroot -c chroot:sid -- cat /etc/debian_chroot sid --- Thanks, Gian Piero. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.5.0-1-amd64 (SMP w/2 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: sysvinit (via /sbin/init) Versions of packages schroot depends on: ii libboost-filesystem1.58.0 1.58.0+dfsg-5+b1 ii libboost-iostreams1.58.01.58.0+dfsg-5+b1 ii libboost-program-options1.58.0 1.58.0+dfsg-5+b1 ii libboost-system1.58.0 1.58.0+dfsg-5+b1 ii libc6 2.22-7 ii libgcc1 1:5.3.1-14 ii libpam0g1.1.8-3.2 ii libstdc++6 5.3.1-14 ii libuuid12.28-1 ii schroot-common 1.6.10-2 schroot recommends no packages. Versions of packages schroot suggests: pn aufs-tools | unionfs-fuse ii btrfs-tools4.4-1 ii debootstrap1.0.80 ii lvm2 2.02.146-1 pn qemu-user-static -- no debconf information
Bug#786590: dwb: segfaults with libwebkitgtk-3.0-0 2.4.9-1
Package: dwb Version: 20150419git-1 Severity: normal Hi, not sure this report belongs here or to the webkitgtk package, please reassign as appropriate. After having upgraded libwebkitgtk from version 2.4.8-2 to 2.4.9-1, dwb segfaults almost at everything. Program received signal SIGSEGV, Segmentation fault. 0x7320f540 in g_type_check_instance_cast () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 Downgrading libwebkitgtk-3.0-0:amd64 libwebkitgtk-3.0-common:amd64 and libjavascriptcoregtk-3.0-0:amd64 to version 2.4.8-2 fixes the issue. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.0.0-1-amd64 (SMP w/2 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: sysvinit (via /sbin/init) Versions of packages dwb depends on: ii libc6 2.19-18 ii libcairo2 1.14.2-2 ii libgdk-pixbuf2.0-0 2.31.4-1 ii libglib2.0-02.44.1-1 ii libgnutls-deb0-28 3.3.15-2 ii libgtk-3-0 3.14.5-1 ii libjavascriptcoregtk-3.0-0 2.4.9-1 ii libpango-1.0-0 1.36.8-3 ii libsecret-1-0 0.18.2-1 ii libsoup2.4-12.48.0-1 ii libwebkitgtk-3.0-0 2.4.9-1 ii libx11-62:1.6.3-1 Versions of packages dwb recommends: ii wget 1.16.3-2 ii xterm 318-2 dwb 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#786590: dwb: segfaults with libwebkitgtk-3.0-0 2.4.9-1
* [Sat, May 23, 2015 at 05:34:14PM +0200] Sebastian Ramacher: Does this also happen with other webkitgtk based browesers? Hi Sebastian, as far as I can see the only other browser depending on libwebkitgtk-3.0-0 is xombrero, and I can not reproduce the issue with it. Ciao, Gian Piero. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780103: maildirsync: please re-enable maildirsync.pl.diff patch
Package: maildirsync Version: 1.2-2 Severity: normal Dear Maintainer, when maildirsync starts, it outputs the following warning: UNIVERSAL-import is deprecated and will be removed in a future perl at /usr/bin/maildirsync line 13. From the changelog for version 1.2-2 it reads: * Deleted patch maildirsync.pl.diff, was aplied on the source. Unfortunately, it doesn't seem it was really applied. On the bright side, though, the patch is still there and the fix should be as easy as re-enabling it within the series file. Thank you, Gian Piero. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 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: sysvinit (via /sbin/init) Versions of packages maildirsync depends on: ii perl 5.20.2-2 Versions of packages maildirsync recommends: ii openssh-client [rsh-client] 1:6.7p1-3 Versions of packages maildirsync suggests: ii bzip2 1.0.6-7+b2 -- 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#758034: apticron: ok to Depend on cron-daemon rather than cron?
Hi Lorenzo, sorry I haven't still read the whole thread and all the related bug reports, so I'm not giving an informed advice. Anyway, given I'm the one to blame for the '--cron' option, I would like to explain the reasons for some of the choices. * [Mon, Sep 01, 2014 at 04:55:09PM +0200] Lorenzo: Btw, I was thinking that there's another possible solution to this bug: since /etc/cron.d/apticron runs every hour at some urandom minute, and checks a timestamp file to make sure it's not running more than once per day, couldn't it just run from /etc/cron.hourly? Well, it could. I opted differently in order, on one side, to distribute the burden on the Debian mirrors and, on the other hand, allow a not-blocking execution of apticron on hosts running it (as cron.hourly serializes the scripts). My opinion is that a randomized would be preferable, but, if that is not possible, this is an option. That should work even under systemd-cron, and it could __possibly__ be combined with a couple of additions to the --cron option: - sleep a random amount of time, up to an hour (since cron.hourly runs at a fixed minute every hor) I would suggest not to re-implement this, as this was the old behaviour and led to the filing of bug #440626 (the fix for which was the introduction of the '--cron' option). - flock(1) a file in /var/lock, to make sure there can never be two instances running (I don't remember when debian switched to /run/lock, so/var/lock should be safer) As said, I did not read the whole thread so I'm not sure about the case you're referring to. As a general note, I think this is not strictly needed as apticron is meant to be run by cron and if a user run it manually it's probably just for testing and can cope with an unfortunate timing. Anyway, this is probably part of a long-planned patch that I've never had the time/wish to implement (or I've simply forgotten about when I had the time). My intention is to work on it in the next month or two in order to let it enter at least Jessie (having missed Wheezy), but I cannot guarantee it. So it would be great if you could consider it while working on this issue. Long story short: if apticron run while dpkg/aptitude/apt-get is running, it will - update the timestamp (so it will not run in the next 24h) - fail - let the user receive a garbage mail In order to avoid these undesired effects, my opinion is that apticron should - at the beginning - take the lock - if '--cron' - check the timestamp - during the execution - collect STDOUT and STDERR (only if '--cron' ?) - at the end - if '--cron' - if execution was successful - produce an output - update the timestamp - else - produce an output for some errors but be silent for others - else - produce an output (?) - release the lock One critical part is the adding of a block that would _always_ run for removing the locks (so we need to trap all the relevant signals, not forgetting SIGERR for some shells). The tricky part is the discrimination of 'good' and 'bad' errors. Ciao, Gian Piero. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679876: sockstat always return Aborted
Package: sockstat
Version: 0.3-1.1
Followup-For: Bug #679876
Please find attached the (decoded) dump of ktrace. The problem seems the
lack of /proc/net/{tcp,udp,raw} pseudo files on kFreeBSD.
Thank you,
Gian Piero.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kfreebsd 10.0-1-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages sockstat depends on:
ii libc0.1:freebsd-amd64 2.19-10
sockstat recommends no packages.
sockstat suggests no packages.
2484 ktrace RET ktrace 0
2484 ktrace CALL execve(0x7fffd429,0x7fffd6a0,0x7fffd6b8)
2484 ktrace NAMI /usr/local/bin/sockstat
2484 ktrace RET execve -1 errno 2 No such file or directory
2484 ktrace CALL execve(0x7fffd42f,0x7fffd6a0,0x7fffd6b8)
2484 ktrace NAMI /usr/bin/sockstat
2484 ktrace NAMI /lib/ld-kfreebsd-x86-64.so.1
2484 sockstat RET execve 0
2484 sockstat CALL getuid
2484 sockstat RET getuid 1000/0x3e8
2484 sockstat CALL geteuid
2484 sockstat RET geteuid 1000/0x3e8
2484 sockstat CALL getgid
2484 sockstat RET getgid 1000/0x3e8
2484 sockstat CALL getegid
2484 sockstat RET getegid 1000/0x3e8
2484 sockstat CALL break(0x800825000)
2484 sockstat RET break -1 errno 12 Cannot allocate memory
2484 sockstat CALL
__sysctl(0x7fffd4d8,0x2,0x7fffd4cc,0x7fffd4d0,0,0)
2484 sockstat SCTL kern.osreldate
2484 sockstat RET __sysctl 0
2484 sockstat CALL getuid
2484 sockstat RET getuid 1000/0x3e8
2484 sockstat CALL access(0x80061cdcb,0F_OK)
2484 sockstat NAMI /etc/ld.so.nohwcap
2484 sockstat RET access -1 errno 2 No such file or directory
2484 sockstat CALL
mmap(0,0x2000,0x3PROT_READ|PROT_WRITE,0x1002MAP_PRIVATE|MAP_ANON,0x,0)
2484 sockstat RET mmap 34366173184/0x800623000
2484 sockstat CALL getuid
2484 sockstat RET getuid 1000/0x3e8
2484 sockstat CALL access(0x80061f7f0,0x4R_OK)
2484 sockstat NAMI /etc/ld.so.preload
2484 sockstat RET access -1 errno 2 No such file or directory
2484 sockstat CALL open(0x80061d2e2,0x10O_CLOEXEC,unused0)
2484 sockstat NAMI /etc/ld.so.cache
2484 sockstat RET open 3
2484 sockstat CALL fstat(0x3,0x7fffcd00)
2484 sockstat STRU invalid record
2484 sockstat RET fstat 0
2484 sockstat CALL mmap(0,0x8bd9,0x1PROT_READ,0x2MAP_PRIVATE,0x3,0)
2484 sockstat RET mmap 34366181376/0x800625000
2484 sockstat CALL close(0x3)
2484 sockstat RET close 0
2484 sockstat CALL getuid
2484 sockstat RET getuid 1000/0x3e8
2484 sockstat CALL access(0x80061cdcb,0F_OK)
2484 sockstat NAMI /etc/ld.so.nohwcap
2484 sockstat RET access -1 errno 2 No such file or directory
2484 sockstat CALL open(0x7fffcd10,0x10O_CLOEXEC,unused0)
2484 sockstat NAMI /lib/x86_64-kfreebsd-gnu/tls/x86_64/libc.so.0.1
2484 sockstat RET open -1 errno 2 No such file or directory
2484 sockstat CALL stat(0x7fffcd10,0x7fffcc80)
2484 sockstat NAMI /lib/x86_64-kfreebsd-gnu/tls/x86_64
2484 sockstat RET stat -1 errno 2 No such file or directory
2484 sockstat CALL open(0x7fffcd10,0x10O_CLOEXEC,unused0)
2484 sockstat NAMI /lib/x86_64-kfreebsd-gnu/tls/libc.so.0.1
2484 sockstat RET open -1 errno 2 No such file or directory
2484 sockstat CALL stat(0x7fffcd10,0x7fffcc80)
2484 sockstat NAMI /lib/x86_64-kfreebsd-gnu/tls
2484 sockstat RET stat -1 errno 2 No such file or directory
2484 sockstat CALL open(0x7fffcd10,0x10O_CLOEXEC,unused0)
2484 sockstat NAMI /lib/x86_64-kfreebsd-gnu/x86_64/libc.so.0.1
2484 sockstat RET open -1 errno 2 No such file or directory
2484 sockstat CALL stat(0x7fffcd10,0x7fffcc80)
2484 sockstat NAMI /lib/x86_64-kfreebsd-gnu/x86_64
2484 sockstat RET stat -1 errno 2 No such file or directory
2484 sockstat CALL open(0x7fffcd10,0x10O_CLOEXEC,unused0)
2484 sockstat NAMI /lib/x86_64-kfreebsd-gnu/libc.so.0.1
2484 sockstat RET open 3
2484 sockstat CALL read(0x3,0x7fffcf40,0x340)
2484 sockstat GIO fd 3 read 832 bytes
0x 7f45 4c46 0201 0109 0300 3e00 0100 1019
0200 4000 38ad 1500 4000
|.ELF...@...8...@.|
0x0036 3800 0a00 4000 5d00 5c00 0600 0500 4000
4000 4000 3002 3002
|8...@.].\.@...@...@...0...0...|
0x006c 0800 0300 0400 c0bc 1200
c0bc 1200 c0bc 1200 1d00 1d00
|..|
0x00a2 1000 0100 0500
bc36 1500
Bug#728205: xmobar: does not look for configuration file in XDG config dir
Package: xmobar
Version: 0.19-1
Severity: minor
Despite what stated in NEWS.Debian and in the man page, xmobar does not
search for the configuration file in $XDG_CONFIG_HOME/xmobar/xmobarrc.
~ $ ls -l .xmobarrc .config/xmobar/xmobarrc
ls: cannot access .xmobarrc: No such file or directory
-rw-r--r-- 1 gpiero gpiero 2602 May 31 08:42 .config/xmobar/xmobarrc
~ 2! echo ${XDG_CONFIG_HOME:-empty}
empty
~ $ xmobar
xmobar: /home/gpiero/.xmobarrc: file not found!
Usage: xmobar [OPTION...] [FILE]
[...]
~ 1! XDG_CONFIG_HOME=~/.config xmobar
xmobar: /home/gpiero/.xmobarrc: file not found!
Usage: xmobar [OPTION...] [FILE]
[...]
~ 1! export XDG_CONFIG_HOME=~/.config ; xmobar
xmobar: /home/gpiero/.xmobarrc: file not found!
Usage: xmobar [OPTION...] [FILE]
[...]
Ciao,
Gian Piero.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.11-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages xmobar depends on:
ii libc6 2.17-93
ii libffi6 3.0.13-4
ii libgmp10 2:5.1.2+dfsg-3
ii libiw30 30~pre9-8
ii libx11-6 2:1.6.2-1
ii libxext6 2:1.3.2-1
ii libxft2 2.3.1-1
ii libxinerama1 2:1.1.3-1
ii libxml2 2.9.1+dfsg1-3
ii libxrandr22:1.4.1-1
Versions of packages xmobar recommends:
ii curl 7.33.0-1
Versions of packages xmobar suggests:
ii xmonad 0.11-6
-- 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#607665: etckeeper: tracks permission changes to ignored files
* [Wed, Aug 28, 2013 at 10:16:26AM +0200] Zdenek Crha: + git ls-files --others --ignore --directory $ignorefile || true I guess this should read: + git ls-files --others --ignored --directory $patternsfile || true as I don't think you want to overwrite the .gitignore file. postfix disclaimer: not regurarly using git as my primary vcs. Ciao, Gian Piero. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721665: maildirsync: perl-5.18's hash randomization breaks the sample script (and common usage)
Package: maildirsync
Version: 1.2-1.1
Severity: important
Tags: upstream patch
As showed in the sample.sh script, maildirsync need a full
(bi-directional) synchronization whenever the local state file has
changed. This is needed in order to keep the state files on the two
hosts synchronized.
As a new state file is written at any run, the mtime/ctime/inode of the
state file cannot be used for determining if the content has changed.
The sample.sh script uses the md5 hash of the file for that aim.
Both because it's very often used for similar needs, and because of its
inclusion in the sample script, it's likely almost all the users of
maildirsync adopted the same solution.
Perl 5.18 anyway introduced a full hash randomization, meaning it's very
unlikely two runs of maildirsync produces the same state file content
even when no change has been performed on the file-system.
This patch sorts the hash keys when saving the new state file in order
to produce reproducible content (and, consequently, permitting md5
hashes comparisons).
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.10-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages maildirsync depends on:
ii perl 5.18.1-3
Versions of packages maildirsync recommends:
ii openssh-client [rsh-client] 1:6.2p2-6
Versions of packages maildirsync suggests:
ii bzip2 1.0.6-5
-- no debconf information
Mon Sep 2 23:20:48 CEST 2013 Gian Piero Carrubba gpi...@rm-rf.it
* Compatibility fix for Perl 5.18
As showed in the sample.sh script, maildirsync need a full (bi-directional)
synchronization whenever the local state file has changed. This is needed in
order to keep the state files on the two hosts synchronized.
As a new state file is written at any run, the mtime/ctime/inode of the state
file cannot be used for determining if the content has changed. The sample.sh
script uses the md5 hash of the file for that aim.
Both because it's very often used for similar needs, and because of its
inclusion in the sample script, it's likely almost all the users of maildirsync
adopted the same solution.
Perl 5.18 anyway introduced a full hash randomization, meaning it's very
unlikely two runs of maildirsync produces the same state file content even when
no change has been performed on the file-system.
This patch sorts the hash keys when saving the new state file in order to
produce reproducible content (and, consequently, permitting md5 hashes
comparisons).
diff -rN -u old-maildirsync-1.2/maildirsync.pl new-maildirsync-1.2/maildirsync.pl
--- old-maildirsync-1.2/maildirsync.pl 2013-09-02 23:21:05.266498292 +0200
+++ new-maildirsync-1.2/maildirsync.pl 2013-09-02 23:21:05.266498292 +0200
@@ -403,7 +403,7 @@
exit_with_error(Cannot open temporary state file for writing: $newfilename) if !$FH;
print $FH $STATE_FILE_FIRST_LINE;
print $FH join(\t,$_, $statedata-[ID]-{$_}, ($statedata-[IDSTORE]-{$_} || )).\n
-foreach keys %{$statedata-[ID]};
+foreach sort keys %{$statedata-[ID]};
close $FH;
chmod $listfile_perms, $newfilename
or exit_with_error(Cannot chmod temporary state file: $!);
Bug#704701: tinc: init script fails to pass extra arguments to tincd
Package: tinc Version: 1.1~pre6-1 Severity: normal Tags: patch Hi, when started by the init script, tinc does not honor the extra arguments set in /etc/default/tinc. Thanks, Gian Piero. -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages tinc depends on: ii dpkg 1.16.10 ii install-info 4.13a.dfsg.1-10 ii libc6 2.13-38 ii liblzo2-2 2.06-1 ii libncurses5 5.9-10 ii libreadline6 6.2+dfsg-0.1 ii libssl1.0.0 1.0.1e-2 ii libtinfo5 5.9-10 ii zlib1g1:1.2.7.dfsg-13 tinc recommends no packages. tinc suggests no packages. -- Configuration Files: /etc/default/tinc changed [not included] -- no debconf information Thu Apr 4 20:28:56 CEST 2013 Gian Piero Carrubba gpi...@rm-rf.it * init script fails to pass extra arguments to tincd + remove the '--' as it is passed unaltered to tincd, preventing it to read trailing parameters + pass extra arguments also when restarting the daemon diff -rN -u old-tinc-1.1~pre6/debian/tinc.init new-tinc-1.1~pre6/debian/tinc.init --- old-tinc-1.1~pre6/debian/tinc.init 2013-04-04 21:23:04.563013650 +0200 +++ new-tinc-1.1~pre6/debian/tinc.init 2013-04-04 21:23:04.563013650 +0200 @@ -41,7 +41,7 @@ egrep '^[ ]*[a-zA-Z0-9_-]+' $NETSFILE | while read net args; do echo -n $net case $1 in - start) $CONTROL -n $net start -- $EXTRA $args ;; + start|restart) $CONTROL -n $net $1 $EXTRA $args ;; *) $CONTROL -n $net $1 ;; esac done
Bug#704702: tinc: set process limits when started by ifupdown
Package: tinc
Version: 1.1~pre6-1
Severity: normal
Tags: patch
Hi,
just discovered that tinc supports ifupdown. Cool.
This is just a copy of #690685, but for the ifupdown script.
Copy-and-paste patch attached.
Thanks,
Gian Piero.
-- System Information:
Debian Release: 7.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages tinc depends on:
ii dpkg 1.16.10
ii install-info 4.13a.dfsg.1-10
ii libc6 2.13-38
ii liblzo2-2 2.06-1
ii libncurses5 5.9-10
ii libreadline6 6.2+dfsg-0.1
ii libssl1.0.0 1.0.1e-2
ii libtinfo5 5.9-10
ii zlib1g1:1.2.7.dfsg-13
tinc recommends no packages.
tinc suggests no packages.
-- Configuration Files:
/etc/default/tinc changed [not included]
-- no debconf information
Sun Mar 31 20:07:45 CEST 2013 Gian Piero Carrubba gpi...@rm-rf.it
* set process limits when started by ifupdown
diff -rN -u old-tinc-1.1~pre6/debian/tinc.if-pre-up new-tinc-1.1~pre6/debian/tinc.if-pre-up
--- old-tinc-1.1~pre6/debian/tinc.if-pre-up 2013-04-04 21:21:51.346494376 +0200
+++ new-tinc-1.1~pre6/debian/tinc.if-pre-up 2013-04-04 21:21:51.346494376 +0200
@@ -8,6 +8,21 @@
. /etc/default/tinc
+# Set process limits
+
+setlimits() {
+ while [ $# -gt 0 ]; do
+parm=$1 ; shift
+if [ -n $1 -a ${1#-} = $1 ]; then
+ value=$1 ; shift
+ ulimit $parm $value
+else
+ ulimit $parm
+fi
+ done
+}
+test -n $LIMITS setlimits $LIMITS
+
# Read options from /etc/network/interfaces
[ -n $IF_TINC_CONFIG ] EXTRA=$EXTRA -c $IF_TINC_CONFIG
Bug#704708: tinc: cannot remove the pid file when using --chroot and/or --user
Package: tinc Version: 1.1~pre6-1 Severity: normal Hi, when using --chroot / --user parameters, tincd cannot remove the pidfile at exit (being the creation of the file before - and the unlink after - the chroot and drop_privs calls). I suspect a proper patch is probably quite intrusive as the pidfile should be placed in a dir writeable by the unprivileged user and residing inside the chroot. On the other side, the config files should stay inside the chroot too, as for the reload functionality. Attached there's a simple workaround in order to let ifdown cleanly shut down the interface. -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages tinc depends on: ii dpkg 1.16.10 ii install-info 4.13a.dfsg.1-10 ii libc6 2.13-38 ii liblzo2-2 2.06-1 ii libncurses5 5.9-10 ii libreadline6 6.2+dfsg-0.1 ii libssl1.0.0 1.0.1e-2 ii libtinfo5 5.9-10 ii zlib1g1:1.2.7.dfsg-13 tinc recommends no packages. tinc suggests no packages. -- Configuration Files: /etc/default/tinc changed [not included] -- no debconf information Thu Apr 4 14:18:04 CEST 2013 Gian Piero Carrubba gpi...@rm-rf.it * workaround for avoiding ifdown exits with rc=1 when tincd is running with --chroot and/or --user diff -rN -u old-tinc-1.1~pre6/debian/tinc.if-post-down new-tinc-1.1~pre6/debian/tinc.if-post-down --- old-tinc-1.1~pre6/debian/tinc.if-post-down 2013-04-04 21:22:40.882845353 +0200 +++ new-tinc-1.1~pre6/debian/tinc.if-post-down 2013-04-04 21:22:40.882845353 +0200 @@ -6,7 +6,8 @@ tincctl -n $IF_TINC_NET stop sleep 0.1 i=0; - while [ -f /var/run/tinc.$IF_TINC_NET.pid ] ; do + pidfile=/var/run/tinc.$IF_TINC_NET.pid + while pgrep -F $pidfile -x tincd /dev/null 21; do if [ $i = '30' ] ; then echo 'Failed to stop tinc daemon!' exit 1 @@ -14,6 +15,7 @@ sleep 0.1 i=$(($i+1)) done + rm -f $pidfile fi exit 0
Bug#692745: maildirsync: shebang line should be changed to read `#!/usr/bin/perl'
Package: maildirsync Version: 1.2-1 Severity: normal Hi Carlos, we already had a private mail exchange about this a year ago and at the time you agreed changing the she-bang line in a future upload (needed for fixing #639978). Anyway, as no upload occurred since then (neither for #639978), I assume you didn't find a sponsor and/or lost interest in the package, so I'm filing this bug report as a reminder to yourself or as a note for next maintainer, whichever is appropriate. The she-bang line should be: #!/usr/bin/perl as suggested by policy §10.4. Thanks, Gian Piero. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages maildirsync depends on: ii perl 5.14.2-15 Versions of packages maildirsync recommends: ii openssh-client [rsh-client] 1:6.0p1-3 Versions of packages maildirsync suggests: ii bzip2 1.0.6-4 -- 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#690685: tinc: please allow raising shell limits in the init script
Package: tinc
Version: 1.0.19-2
Severity: wishlist
Tags: patch
A simple patch is attached. This way it should be possible to use both
--mlock and --user with an unprivileged user and more than few tinc
nodes without incurring in the problem reported in [0]_ (namely, Error
while processing METAKEY from ...).
As a side note, I think creating a `tinc' system user in the postinst
and defaulting to use `--user=tinc' would also be nice.
Thanks,
Gian Piero.
.. [0] http://www.tinc-vpn.org/pipermail/tinc/2012-September/003056.html
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages tinc depends on:
ii dpkg 1.16.8
ii install-info 4.13a.dfsg.1-10
ii libc6 2.13-35
ii liblzo2-2 2.06-1
ii libssl1.0.0 1.0.1c-4
ii zlib1g1:1.2.7.dfsg-13
tinc recommends no packages.
tinc suggests no packages.
-- Configuration Files:
/etc/default/tinc changed [not included]
/etc/init.d/tinc changed [not included]
-- no debconf information
Tue Oct 16 14:39:21 CEST 2012 Gian Piero Carrubba gpi...@rm-rf.it
* Set process limits on start
diff -rN -u old-tinc-1.0.19/debian/tinc.default new-tinc-1.0.19/debian/tinc.default
--- old-tinc-1.0.19/debian/tinc.default 2012-10-16 15:29:27.966757678 +0200
+++ new-tinc-1.0.19/debian/tinc.default 2012-10-16 15:29:27.970757719 +0200
@@ -1,2 +1,7 @@
# Extra options to be passed to tincd.
# EXTRA=-d
+
+# Limits to be configured for the tincd process. Please read your shell
+# (pointed by /bin/sh) documentation for ulimit. You probably want to raise the
+# max locked memory value if using both --mlock and --user flags.
+# LIMITS=-l 128
diff -rN -u old-tinc-1.0.19/debian/tinc.init new-tinc-1.0.19/debian/tinc.init
--- old-tinc-1.0.19/debian/tinc.init 2012-10-16 15:29:27.966757678 +0200
+++ new-tinc-1.0.19/debian/tinc.init 2012-10-16 15:29:27.970757719 +0200
@@ -54,6 +54,18 @@
done
}
+setlimits() {
+ while [ $# -gt 0 ]; do
+parm=$1 ; shift
+if [ -n $1 -a ${1#-} = $1 ]; then
+ value=$1 ; shift
+ ulimit $parm $value
+else
+ ulimit $parm
+fi
+ done
+}
+
start() {
$DAEMON $EXTRA -n $@
}
@@ -84,6 +96,7 @@
case $1 in
start)
+test -n $LIMITS setlimits $LIMITS
foreach_net Starting $DESC: start
;;
stop)
Bug#690685: tinc: please allow raising shell limits in the init script
* [Tue, Oct 16, 2012 at 04:44:41PM +0200] Guus Sliepen: On Tue, Oct 16, 2012 at 03:30:18PM +0200, Gian Piero Carrubba wrote: A simple patch is attached. This way it should be possible to use both --mlock and --user with an unprivileged user and more than few tinc nodes without incurring in the problem reported in [0]_ (namely, Error while processing METAKEY from ...). Indeed, that is a good idea. However, isn't /etc/security/limits.conf a better place to configure this? Sure, it would be cleaner. Problem is that /etc/security/limits.conf (or, better yet, /etc/security/limits.d/tinc.conf) is read by pam_limits and tincd does not invoke the pam stack (well, haven't dug into the source but as it isn't linked against libpam I guessed so). So, writing a parser for reading limits.conf in the init script seems a bit overkilling to me. If you're willing to wear your upstream hat, it would be great if you could add support for pam. But honestly I don't know if it's worth the pain. As a side note, I think creating a `tinc' system user in the postinst and defaulting to use `--user=tinc' would also be nice. That is also a good idea. At the moment testing is frozen, I will wait for wheezy to be released before uploading any of these changes to unstable, but I will probably upload to experimental them as part of tinc 1.1preX. Great. Thanks, Gian Piero. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690685: tinc: please allow raising shell limits in the init script
* [Tue, Oct 16, 2012 at 03:30:18PM +0200] Gian Piero Carrubba:
A simple patch is attached. This way it should be possible to use both
--mlock and --user with an unprivileged user and more than few tinc
nodes without incurring in the problem reported in [0]_ (namely, Error
while processing METAKEY from ...).
Sorry, the previous patch was wrong in that it does not set the limits
when restarting the daemon. Please find attached a corrected patch.
Ulimit is now always invoked when running the init script, even for
alarm or stop actions. Useless in those case, but it should not be
dangerous.
Thanks,
Gian Piero.
Tue Oct 16 18:47:59 CEST 2012 Gian Piero Carrubba gpi...@rm-rf.it
* Set process limits on start
diff -rN -u old-tinc-1.0.19/debian/tinc.default new-tinc-1.0.19/debian/tinc.default
--- old-tinc-1.0.19/debian/tinc.default 2012-10-16 18:50:31.215612570 +0200
+++ new-tinc-1.0.19/debian/tinc.default 2012-10-16 18:50:31.215612570 +0200
@@ -1,2 +1,7 @@
# Extra options to be passed to tincd.
# EXTRA=-d
+
+# Limits to be configured for the tincd process. Please read your shell
+# (pointed by /bin/sh) documentation for ulimit. You probably want to raise the
+# max locked memory value if using both --mlock and --user flags.
+# LIMITS=-l 128
diff -rN -u old-tinc-1.0.19/debian/tinc.init new-tinc-1.0.19/debian/tinc.init
--- old-tinc-1.0.19/debian/tinc.init 2012-10-16 18:50:31.215612570 +0200
+++ new-tinc-1.0.19/debian/tinc.init 2012-10-16 18:50:31.215612570 +0200
@@ -54,6 +54,18 @@
done
}
+setlimits() {
+ while [ $# -gt 0 ]; do
+parm=$1 ; shift
+if [ -n $1 -a ${1#-} = $1 ]; then
+ value=$1 ; shift
+ ulimit $parm $value
+else
+ ulimit $parm
+fi
+ done
+}
+
start() {
$DAEMON $EXTRA -n $@
}
@@ -82,6 +94,8 @@
start $@
}
+test -n $LIMITS setlimits $LIMITS
+
case $1 in
start)
foreach_net Starting $DESC: start
Bug#690685: tinc: please allow raising shell limits in the init script
* [Tue, Oct 16, 2012 at 09:17:00PM +0400] Michael Tokarev: +test -n $LIMITS setlimits $LIMITS Can't you just do test -n $LIMITS ulimit $LIMITS ? I guess so, if your /bin/sh is linked to bash or you only set one parameter or the shebang line is changed to be /bin/bash or well, something else :). Otherwise it can break when called with more than one parameter. At least it does with dash (and I suspect with other susv3 shells too, but didn't checked): $ ls -l /bin/sh lrwxrwxrwx 1 root root 4 Mar 1 2012 /bin/sh - dash $ sh $ ulimit -l 64 -n 2048 sh: 1: ulimit: too many arguments Ciao, Gian Piero. PS: please note that it _does_ subtly break when called with something like: LIMITS=-H -l 128 -S -p 512 but I guessed it doesn't make a lot of sense separately setting hard/soft limits in this context. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683495: Mass-filing bug against use of '/usr/bin/env perl' shebang line
Maintaining the cc: to debian-perl@l.d.o as the discussion has started there. Feel free to strip it out if you think isn't appropriate. * [Mon, Aug 06, 2012 at 08:38:56AM +0900] Charles Plessy: [...] Here are possible resolutions of this bug report. - Close, given that there is no internal contradiction within the Debian Policy nor the Perl policy. This seems fair enough, but ... - Reduce the Perl policy's must to a should. A should still disallows the use of /usr/bin/env with no justification. It is also in line with the fact that some packaged modules sometimes slip in Debian with scripts started with /usr/bin/env, without this being a serious bug requiring immediate action. - Change the Debian Policy's section 11.9 to require that the Perl policy must be followed. I think that this would require to correct the packages that would become buggy according to that change, including those with scripts starting with /usr/bin/env. But if it is a reachable target, why not ? ... imho, merging these two points would be better. I mean: - Change the Debian Policy's section 11.9 to require that the Perl policy must be followed. For the sake of clearness and because this way we can remove a sort of indeterminateness caused by a perl policy that should (and not must) be followed. As a general rule, I support the idea that also other specific (python/ruby/java/...) policies could be a must, so becoming a sort of appendixes to the general policy. AND [ regarding `/usr/bin/perl' in the shebang line ] - Reduce the Perl policy's must to a should. Because, apart from the reason above, I think there are some legitimate (though unusual) reasons for using /usr/bin/env. I'm thinking for example to a script that could copy itself to another (possibly not Debian nor Linux) host for remote execution. Something like what the sshuttle (python) script does. @debian-perl people: do you think the perl policy as it stands (minus eventually the shebang must) could be a must policy? Side remark: for Python, section 1.4.2 of its policy also restricts the use of /usr/bin/env under a should not directive, in line with Debian Policy's section 10.4 that requests the scripts to started with a shell, which /usr/bin/env is not. I was submitting a patch to lintian for including a check against the use of /usr/bin/env in perl scripts and just remembered this sentence from you. Could you please clarify the last point? $10.4 reads: All command scripts, including the package maintainer scripts inside the package and used by `dpkg', should have a `#!' line naming the shell to be used to interpret them. As for my interpretation, '#!/usr/bin/env perl' still names the shell, even if not giving the full path, so it does not violate that requirement. But if it's not the case, should we have a lintian check that warns about the use of /usr/bin/env whichever the real interpreter is ? Ciao, Gian Piero. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683570: debian-policy: [Packaging] Please include all the supplemental documentation
Package: debian-policy Severity: wishlist Please also include within the package all the documents listed under Supplemental Policy documentation in [0]. At the moment, the missing documents seem to be: - debconf specification - Emacsen policy - Java policy (request already present in #553619) - Python policy Thanks, Gian Piero. [0] http://www.debian.org/doc/devel-manuals#policy -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#662865: 'W: Failed to invoke browser.' when run under sudo
* [Wed, Mar 28, 2012 at 11:59:31PM +0200] Francesco Poli: Mmmh, I don't think we can assume that sudo is installed, just because we are within an sudo environment (with $SUDO_USER set). Maybe we are inside a chroot environment and we entered by using sudo from the outside. Package sudo is *not* necessarily installed *inside* the chroot environment... Oh, I see. More generally, this is an argument against the whole 'switching-the-user' point: the same user pointed by $SUDO_USER isn't guaranteed to exist inside the chroot. After rebuilding apt-listbugs with your proposed modification, I enter the chroot environment (B50shell_pdeb hook script), Thanks for the explanation, I was really puzzled by the mysterious behaviour :) In http://www.inventati.org/frx/progs/scripts/B50shell_pdeb I read: /bin/bash /dev/tty /dev/tty 2 /dev/tty Redirecting to/from the tty is evil, and chaining such redirections is double evil for sure. Or is it evil^2 ? Well, anyway too much evilness to defeat, I don't think there's a simple workaround for it (for some meaning of 'simple'). (even though I don't understand the use of the $n variable in read p v n...) Oh, nothing (actually, it stands for 'null' or 'notcaringabout'), just compulsory scripting for capturing the tail (if any) and not clobbering the previous variable. Or if you feel like: test -n $n || continue # These aren't the droids you're looking for Ciao, Gian Piero. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#662865: 'W: Failed to invoke browser.' when run under sudo
* [Sun, Mar 25, 2012 at 11:48:57PM +0200] Francesco Poli: For the time being, the only way to dodge this problem is maybe to avoid invoking su -c, even when in an sudo environment. This means that the browser will run as root, even when apt-listbugs is invoked through sudo. [...] What do you think about this proposal? Would you consider it as an acceptable interim fix, while waiting for the radical solution? Hi Francesco, considering it as a temporary work around, I suppose it is acceptable, even though I for myself am not excited launching a browser as root. Another possibility could be using sudo instead of su. As $SUDO_USER is set, it should be safe to think sudo is installed, unless the same variable is also used from some sudo-like alternatives (super or so). I didn't verify it. Anyway, having set apart for the moment a general solution, could you please give another try to the patch I've previously sent? I'm using it on some of my PCs and it seems to work correctly. Since from the report of the bad behaviour you've experienced, I had tried to reproduce it without success. I think the key of the failure could be the chroot environment, but until now I've failed to reproduce it both with schroot and a plain chroot. In the next day or two I plan to try again, but I'm a bit in shortage of ideas about the cause and I'm beginning to believe that either your environment is more esoteric than what I could think of or I'm really missing some trivial point. As for reference, I'm attaching the simple test I'm using when not testing the whole aptitude/apt-listbugs pair. The test.sh script should be run via sudo in order to emulate (at least I think so) aptitude. Could you please state if there's something clearly wrong with it? Thanks, Gian Piero. test.sh Description: Bourne shell script
Bug#662865: 'W: Failed to invoke browser.' when run under sudo
* [Sun, Mar 11, 2012 at 12:47:58AM +0100] Francesco Poli: Moving the /dev/tty out of the -c argument makes it possible to start the browser, but, at least when using a text-based web browser, such as w3m, the user is prevented from interacting with the browser itself: as soon as the user presses any key on the keyboard, w3m exits and the user is returned to the apt-listbugs prompt. Worse, it seems that the pressed keys are sent to the apt-listbugs prompt, without being visible on the terminal: this means that entering one of the possible commands will fail and print the help... I'm not sure why I don't experience the same disruptive behaviour, even using w3m myself. This could be due to some differences in invoking aptitude (I just use to run the curses ui of aptitude within sudo) or in the environment (/etc/sudoers?), but can't think of a reasonable explanation. Anyway ... At this point, I hope that a radical solution may be found to fix both this bug (#662865) and the other one (#662983). ... I agree that a more generic and possibly radical fix has to be found. Thanks, Gian Piero. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#662865: 'W: Failed to invoke browser.' when run under sudo
Package: apt-listbugs
Version: 0.1.6
Severity: normal
Tags: patch
Running aptitude (and consequently apt-listbug) via sudo, I'm not able
to display the bugs list in a browser:
Are you sure you want to install/upgrade the above packages? [Y/n/?/...] w
bash: /dev/tty: No such device or address
W: Failed to invoke browser.
su gpiero -c /usr/bin/sensible-browser /tmp/apt-listbugs27667.0.html
/dev/tty
Not sure when this bug has been introduced: it could be a while it
doesn't work for me, but this hunk of code seems to be here since ages
ago and I'm pretty sure I used it in the last years. I can only guess
su's behaviour has changed in the meantime.
Please consider applying the following patch or a similar one in order
to not include the shell redirection inside the command launched via su.
--- old-apt-listbugs-0.1.6/lib/apt-listbugs/logic.rb2012-03-06
21:56:13.735125556 +0100
+++ new-apt-listbugs-0.1.6/lib/apt-listbugs/logic.rb2012-03-06
21:56:14.099128219 +0100
@@ -620,10 +620,9 @@
tmp.close
puts Invoking browser for #{tmp.path} if $DEBUG
- browsercommandline =
- browsercommandline su #{ENV[SUDO_USER]} -c \ if ENV[SUDO_USER]
- browsercommandline #{@config.browser} #{tmp.path} /dev/tty
- browsercommandline \ if ENV[SUDO_USER]
+ browsercommandline = #{@config.browser} #{tmp.path}
+ browsercommandline = su #{ENV[SUDO_USER]} -c \ + browsercommandline + \ if
ENV[SUDO_USER]
+ browsercommandline/dev/tty
if system(browsercommandline)
puts successfully invoked browser if $DEBUG
else
Thanks,
Gian Piero.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages apt-listbugs depends on:
ii apt0.8.15.9
ii libdpkg-ruby1.80.3.8
ii libgettext-ruby1.8 2.1.0-2.1
ii libruby1.8 [libzlib-ruby1.8] 1.8.7.352-2
ii ruby-debian [libdpkg-ruby1.8] 0.3.8
ii ruby-httpclient2.2.1-1
ii ruby-xmlparser 0.7.2-1
ii ruby1.81.8.7.352-2
apt-listbugs recommends no packages.
Versions of packages apt-listbugs suggests:
ii chromium [www-browser] 17.0.963.56~r121963-1
ii debianutils4.2.1
ii iceweasel [www-browser]10.0.2-1
ii links [www-browser]2.5-1
ii links2 [www-browser] 2.5-1
ii netsurf-gtk [www-browser] 2.8-2
ii reportbug 6.3.1
ii uzbl [www-browser] 0.0.0~git.2028-2
ii w3m [www-browser] 0.5.3-5
-- 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#662865: 'W: Failed to invoke browser.' when run under sudo
* [Wed, Mar 07, 2012 at 01:05:38AM +0100] Francesco Poli: Not sure when this bug has been introduced: it could be a while it doesn't work for me, but this hunk of code seems to be here since ages ago and I'm pretty sure I used it in the last years. I can only guess su's behaviour has changed in the meantime. I am in a hurry now and I still have to try and reproduce the issue (something that I hope to do soon), but, from a first casual glance, it seems that this may be due to the fix for the security bug #628843. Yes, I suspect the same. Anyway the changelog is so long and honestly I didn't review the commits looking for the culprit. By the way I can confirm I cannot reproduce the problem (using the test case below) on a Debian stable. On the other hand, I *think* the fix should not harm if coupled with the old-behaviour su. === $ echo OK /dev/tty OK $ su gpiero -c echo OK /dev/tty Password: OK $ su gpiero -c echo OK /dev/tty Password: bash: /dev/tty: No such device or address === Thanks for providing a patch: if I understand correctly, you are proposing to move the /dev/tty out of the -c argument, so that it applies to su, rather than to the browser command-line. You're right. I am not sure why you reformatted the browsercommandline building steps so much, but anyway... Oh well, sure I'm not acquainted with ruby (I even had to google for the string concatenation operator) nor with the code style of apt-listbugs. The patch has been provided primarily for explaining the workaround. Thanks, Gian Piero. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623429: trayer: huge values in _NET_WM_STRUT_PARTIAL
package trayer tags 623429 fixed-upstream thanks This is fixed upstream, see [0]. Please consider including that patch. Thanks, Gian Piero. [0] https://github.com/sargon/trayer-srg/commit/9b0e69a192af68f132205c7dec5ed113b4393510 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623429: trayer: huge values in _NET_WM_STRUT_PARTIAL
package trayer unarchive 623429 reopen 623429 ! thanks This same bug is occurring again to me: $ xprop | grep STRUT _NET_WM_STRUT(CARDINAL) = 0, 25, 0, 0 _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 25, 0, 0, 1088, 0, 0, 25202240, 1088, 2832618272, 0, 4215058 As there's been no new version of trayer since a while, it seems obvious that a recent update of a related package has messed it up. Filtering the output of which-pkg-broke with time of the last reboot, one or more of the following packages seems to be the culprit: [UPGRADE] libglib2.0-0 2.28.8-1 - 2.30.2-4 [UPGRADE] perl-base 5.12.4-6 - 5.14.2-5 [UPGRADE] libfreetype6-dev 2.4.7-2 - 2.4.8-1 [UPGRADE] libgnutls26 2.12.14-2 - 2.12.14-3 [UPGRADE] libdatrie1 0.2.5-1 - 0.2.5-2 [UPGRADE] libthai-data 0.1.16-1 - 0.1.16-2 [UPGRADE] libthai0 0.1.16-1 - 0.1.16-2 Anyway it goes beyond my knowledge affirming this is a bug in one of the packages listed above or instead the fix previously implemented in trayer (working for me until now) should be revised. Thanks, Gian Piero. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623429: trayer: huge values in _NET_WM_STRUT_PARTIAL
package trayer reopen 623429 ! thanks This same bug is occurring again to me: $ xprop | grep STRUT _NET_WM_STRUT(CARDINAL) = 0, 25, 0, 0 _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 25, 0, 0, 1088, 0, 0, 25202240, 1088, 2832618272, 0, 4215058 As there's been no new version of trayer since a while, it seems obvious that a recent update of a related package has messed it up. Filtering the output of which-pkg-broke with time of the last reboot, one or more of the following packages seems to be the culprit: [UPGRADE] libglib2.0-0 2.28.8-1 - 2.30.2-4 [UPGRADE] perl-base 5.12.4-6 - 5.14.2-5 [UPGRADE] libfreetype6-dev 2.4.7-2 - 2.4.8-1 [UPGRADE] libgnutls26 2.12.14-2 - 2.12.14-3 [UPGRADE] libdatrie1 0.2.5-1 - 0.2.5-2 [UPGRADE] libthai-data 0.1.16-1 - 0.1.16-2 [UPGRADE] libthai0 0.1.16-1 - 0.1.16-2 Anyway it goes beyond my knowledge affirming this is a bug in one of the packages listed above or instead the fix previously implemented in trayer (working for me until now) should be revised. Thanks, Gian Piero. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623429: trayer: huge values in _NET_WM_STRUT_PARTIAL
* [Sun, Nov 20, 2011 at 12:55:47PM +0100] Gian Piero Carrubba: This same bug is occurring again to me: $ xprop | grep STRUT _NET_WM_STRUT(CARDINAL) = 0, 25, 0, 0 _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 25, 0, 0, 1088, 0, 0, 25202240, 1088, 2832618272, 0, 4215058 Downgrading libglib2.0-0 2.30.2-4 - 2.28.8-1 (and, for dependencies, glib-networking 2.30.1-3 - 2.28.7-2) seems to partially solve (or at least hide) the problem. While the output of xprop is still weird: $ xprop | fgrep STRUT _NET_WM_STRUT(CARDINAL) = 0, 25, 0, 0 _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 25, 0, 0, 1088, 0, 1088, 13105504, 1088, 2617232352, 0, 4215058 there's no bad interaction with xmonad anymore. I guess that the seventh field set to 1088 (instead of 0) had done the magic, by putting the noisy ghost panel out of the visible screen. My opinion, also supported by previous report from Andrew, is that the implemented fix has hidden the bug in some cases (like for my setup until now). Thanks, Gian Piero. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639978: Please change the default for `--maildirsync' option
Package: maildirsync Version: 1.2-1 Severity: wishlist IMHO it should be safe to assume that the remote system (when using maildirsync in remote mode) is Debian too. As such, the default for `--maildirsync' should be `maildirsync' instead of `maildirsync.pl'. @@ -30,7 +31,7 @@ backup-tree b:0 B 0 1 bzip2 s:bzip2 - 1 0 gzips:gzip - 1 0 -maildirsync s:maildirsync.pl- 1 1 +maildirsync s:maildirsync - 1 1 modei:0 - 0 0 rsh s:ssh R 0 0 verbose I:0 v 1 1 Thanks, Gian Piero. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages maildirsync depends on: ii perl 5.12.4-4 Versions of packages maildirsync recommends: ii openssh-client [rsh-client] 1:5.8p1-7 Versions of packages maildirsync suggests: ii bzip2 1.0.5-6 -- 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#626126: maildirsync: UNIVERSAL-import is deprecated
* [Sun, May 08, 2011 at 09:02:39PM -0600] Bob Proulx:
Package: maildirsync
Version: 1.1-2
Severity: normal
Tags: patch
Since a recent perl update I have been getting the following warnings.
UNIVERSAL-import is deprecated and will be removed in a future perl at
/usr/bin/maildirsync line 13
The documentation at the bottom here describes the deprecation and why.
http://perldoc.perl.org/UNIVERSAL.html
This page seems suggesting something like (sorry, cannot produce a real
diff just now):
use Scalar::Util 'reftype';
...
if ( reftype($OPT{$optname}) ne 'ARRAY' ) {
Any opinion on this?
CCing debian-perl for more hints. Also, as maildirsync has been
orphaned, could any of you prepare an NMU for taking care of this?
Thanks,
Gian Piero.
Below the patch from Bob for reference.
--- /usr/bin/maildirsync2007-07-20 08:55:47.0 -0600
+++ /usr/local/bin/maildirsync 2011-05-08 20:54:09.0 -0600
@@ -10,7 +10,6 @@
use IO::Handle;
use IPC::Open2;
use Fcntl qw(SEEK_SET);
-use UNIVERSAL qw(isa);
use strict;
require 5.006;
@@ -93,7 +92,7 @@
exit_with_error(Invalid parameter value: $optname: $value) if $value
!~ /^$regex$/;
}
verbose 4 = add option $optname = .($value || );
-if (!isa($OPT{$optname}, 'ARRAY')) {
+if (! eval { $OPT{$optname}-isa('ARRAY') }) {
$OPT{$optname} = $value;
} else {
push @{$OPT{$optname}}, $value;
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626126: maildirsync: UNIVERSAL-import is deprecated
* [Mon, May 09, 2011 at 03:20:51PM +0200] Gian Piero Carrubba: CCing debian-perl for more hints. Also, as maildirsync has been orphaned, could any of you prepare an NMU for taking care of this? Just to clarify, I meant: *if* you think an NMU is appropriate. Ciao, Gian Piero. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623429: libghc-xmonad-contrib-dev: avoidStruts leaves a gap on the left of the screen
Package: libghc-xmonad-contrib-dev Version: 0.9.2-2+b1 Severity: minor After switching to the last version of libghc-xmonad-contrib-dev, XMonad.Hooks.ManageDocks.avoidStruts seems to think there's a dock on the left of the screen. It correctly avoids drawing windows over xmobar and trayer (running on the top of my screen), but also inserts a gap on the left that I can't explain. Please find attached my xmonad.hs. The same config worked well with previous installed version (libghc6-xmonad-contrib-dev 0.9.1-1+b1). Thanks, Gian Piero. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libghc-xmonad-contrib-dev depends on: ii ghc [libghc-unix-dev-2.4. 7.0.3-1The Glasgow Haskell Compilation sy ii libc6 2.11.2-13 Embedded GNU C Library: Shared lib ii libffi5 3.0.9-4Foreign Function Interface library pn libghc-base-dev-4.3.1.0-9 none (no description available) pn libghc-containers-dev-0.4 none (no description available) pn libghc-directory-dev-1.1. none (no description available) pn libghc-extensible-excepti none (no description available) ii libghc-mtl-dev [libghc-mt 2.0.1.0-2+b2 Haskell monad transformer library pn libghc-old-locale-dev-1.0 none (no description available) pn libghc-old-time-dev-1.0.0 none (no description available) pn libghc-process-dev-1.0.1. none (no description available) pn libghc-random-dev-1.0.0.3 none (no description available) ii libghc-utf8-string-dev [l 0.3.6-5+b1 GHC libraries for the Haskell UTF- ii libghc-x11-dev [libghc-x1 1.5.0.0-3+b1 Haskell X11 binding for GHC ii libghc-x11-xft-dev [libgh 0.3-6+b1 Haskell Xft binding for GHC ii libghc-xmonad-dev [libghc 0.9.2-2+b1 A lightweight X11 window manager ii libgmp10 2:5.0.1+dfsg-7 Multiprecision arithmetic library ii libx11-6 2:1.4.3-1 X11 client-side library ii libx11-dev2:1.4.3-1 X11 client-side library (developme ii libxext6 2:1.2.0-2 X11 miscellaneous extension librar ii libxft2 2.2.0-2FreeType-based font drawing librar ii libxinerama-dev 2:1.1.1-1 X11 Xinerama extension library (de ii libxinerama1 2:1.1.1-1 X11 Xinerama extension library libghc-xmonad-contrib-dev recommends no packages. Versions of packages libghc-xmonad-contrib-dev suggests: ii libghc-xmonad-contrib-doc 0.9.2-2Extensions to xmonad; documentatio pn libghc-xmonad-contrib-profnone (no description available) -- no debconf information -- -- xmonad example config file. -- -- A template showing all available configuration hooks, -- and how to override the defaults in your own xmonad.hs conf file. -- -- Normally, you'd only override those defaults you care about. -- import XMonad import XMonad.Util.Run -- for spawnPipe and hPutStrLn import System.Exit import XMonad.Hooks.ManageDocks import XMonad.Hooks.DynamicLog import XMonad.Hooks.SetWMName import XMonad.Util.Loggers -- for ppExtras import XMonad.Layout.PerWorkspace import XMonad.Layout.Tabbed import qualified XMonad.StackSet as W import qualified Data.Mapas M -- The preferred terminal program, which is used in a binding below and by -- certain contrib modules. -- -- myTerminal = xterm -- myTerminal = lxterm -- myTerminal = lxterm -e /usr/bin/screen -xRR -- myTerminal = urxvt -e sh -c \if /usr/bin/tmux has-session ; then /usr/bin/tmux attach ; else /usr/bin/tmux; fi\ myTerminal = urxvt -e sh -c \/usr/bin/tmux attach || /usr/bin/tmux\ -- Width of the window border in pixels. -- myBorderWidth = 1 -- modMask lets you specify which modkey you want to use. The default -- is mod1Mask (left alt). You may also consider using mod3Mask -- (right alt), which does not conflict with emacs keybindings. The -- windows key is usually mod4Mask. -- -- myModMask = mod1Mask myModMask = mod3Mask -- The mask for the numlock key. Numlock status is masked from the -- current modifier status, so the keybindings will work with numlock on or -- off. You may need to change this on some systems. -- -- You can find the numlock modifier by running xmodmap and looking for a -- modifier with Num_Lock bound to it: -- -- $ xmodmap | grep Num -- mod2Num_Lock (0x4d) -- -- Set numlockMask = 0 if you don't have a numlock key, or want to treat -- numlock status separately. -- myNumlockMask = mod2Mask -- The default number of workspaces (virtual screens) and their names. -- By default we use numeric strings, but any string may be used as a -- workspace name. The number of workspaces is determined by the length --
Bug#623429: [Pkg-haskell-maintainers] Bug#623429: libghc-xmonad-contrib-dev: avoidStruts leaves a gap on the left of the screen
reassign 623429 trayer retitle 623429 trayer: huge values in _NET_WM_STRUT_PARTIAL thanks * [Wed, Apr 20, 2011 at 02:16:24PM +0530] Joachim Breitner: thanks for reporting the bug. Do you happen to have a non-rectangular screen, e.g. two screens of different size? There was a discussion about that on the xmonad mailing list. Hi Joachim, thanks for pointing me to the xmonad ml. Reading the thread you were referring to I could do some more test and now I'm pretty convinced it's probably caused by trayer's update, not xmonad's. Sorry for the noise, reassigning it. Back to the bug report: trayer 1.1-1 seems to set wrong values for _NET_WM_STRUT_PARTIAL. Not merging with #603447 as I'm experiencing different effects, but maybe the two bugs could be related. With 1.0-5 I get : $ xprop | grep STRUT _NET_WM_STRUT(CARDINAL) = 0, 0, 20, 0 _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 20, 0, 0, 0, 0, 0, 1224, 1440, 0, 0 while this is the result with 1.1-1 : $ xprop | grep STRUT _NET_WM_STRUT(CARDINAL) = 0, 20, 0, 0 _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 20, 0, 0, 1224, 0, 0, 9126352, 1224, 4212818, 0, 9448656 Following is the command line I use to start trayer: trayer --edge top --align right \ --widthtype percent --width 15 \ --heighttype pixel --height 25 \ --SetDockType true --SetPartialStrut true \ --transparent true --tint 0x33 --alpha 0 Thanks, Gian Piero. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587597: apticron dropped support for being run by anacron
unarchive 587597 reopen 587597 thanks The cron.daily snippet was in place for systems that aren't always on, so that apticron can be invoked by anacron (that doesn't run snippets in /etc/cron.d). The problem reported by the OP wasn't strictly due to the existence of /etc/cron.daily/apticron, but rather to the fact that during the commit for fixing #574461 the '--cron' parameter has gone missed. Well... ok, the existence of /etc/cron.d/apticron is someway relevant :) Attached you can find a ( bundle of ) patch(es) that restores support for anacron. [0] Anyway I have to admit that having both /etc/cron.d/apticron and /etc/cron.daily/apticron can be confusing, so I've attached a different set of patches. [1] This second bundle of patches modifies the cron.d snippet in order to run apticron once a hour. This way, a system that isn't up 24h a day get a chance to run apticron during its awakening hours. If you choose this solution, I suggest to also fill a NEWS entry. Please also note that both bundles should fix the just reopened #522961 (the second one implicitly, the first one by an explicit patch). Thanks, Gian Piero. [0] Disclaimer: sorry for posting many patches in a single report, but when digging for the cause I've found some other issues and most of them seem to be someway related (but I've to admit at least a bit of laziness is in place here, as some of them clearly aren't). I hope having separated them one per file can help you in reviewing and cherry picking. [1] Same disclaimer applies. bundle_1.tgz Description: application/gtar-compressed bundle_2.tgz Description: application/gtar-compressed
Bug#616646: imapfilter: only evaluates first occurrence when server returns multiple SEARCH tags
Package: imapfilter Version: 1:2.2.2-1 Severity: normal Tags: upstream Please consider applying the patch referred to in [0] ( removing line 550 from file response.c ). As for the OP for the linked thread, I'm hit by this bug while using davmail as IMAP server, but other servers could be interested too. Thanks, Gian Piero. [0] http://lists.hellug.gr/pipermail/imapfilter-devel/2011/000815.html -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.37-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages imapfilter depends on: ii libc6 2.11.2-13 Embedded GNU C Library: Shared lib ii liblua5.1-0 5.1.4-5Simple, extensible, embeddable pro ii libpcre3 8.12-3 Perl 5 Compatible Regular Expressi ii libssl0.9.8 0.9.8o-5 SSL shared libraries imapfilter recommends no packages. imapfilter suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600026: etckeeper: composed author email with hostname with duplicit dnsdomain part
* [Wed, Oct 13, 2010 at 09:51:32PM +0200] Václav Ovsík:
--- a/etckeeper/commit.d/50vcs-commit
+++ b/etckeeper/commit.d/50vcs-commit
[..]
-hostname=`hostname`
+hostname=`hostname|sed 's/\..*//;'`
[..]
will probably work everywhere.
Maybe just a matter of taste, but I'd prefer something in the line of:
hostname=`hostname`
hostname=${hostname%%.*}
in order not to fork another process. Not sure it will work everywhere,
but on POSIX shells it should.
Ciao,
Gian Piero.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529670: [wnpp] maildirsync has been orphaned again
package wnpp retitle 529670 ITA: maildirsync -- simple and efficient Maildir synchronisation utility owner 529670 ! thanks * [Thu, May 13, 2010 at 12:05:15AM +] WNPP Monitor: The maildirsync package in Debian has been orphaned again, and is looking for a new maintainer. Someone was interested in adopting it, but changed his mind. Not exactly: simply didn't found a sponsor for the first version uploaded to mentors.d.n. I'm been very busy in the last month or so, but I'm hoping to upload a new version in 1/2 weeks, then I'll look again for a sponsor. Cheers, Gian Piero. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579353: tmux: version 1.2-2 breaks software using waitpid()
Package: tmux Version: 1.2-2 Severity: critical Tags: sid Justification: breaks unrelated software Strange as it appears, it seems that version 1.2-2 interfers with software calling waitpid(). Just as an example, running reportbug inside tmux (inside urxvt) leads to: gpi...@caimano:~$ reportbug tmux Traceback (most recent call last): File /usr/bin/reportbug, line 40, in module from reportbug import utils File /usr/lib/pymodules/python2.5/reportbug/utils.py, line 46, in module import debianbts File /usr/lib/pymodules/python2.5/reportbug/debianbts.py, line 43, in module import checkversions File /usr/lib/pymodules/python2.5/reportbug/checkversions.py, line 37, in module from urlutils import open_url File /usr/lib/pymodules/python2.5/reportbug/urlutils.py, line 35, in module import webbrowser File /usr/lib/python2.5/webbrowser.py, line 498, in module register_X_browsers() File /usr/lib/python2.5/webbrowser.py, line 453, in register_X_browsers retncode = out.close() IOError: [Errno 10] No child processes The same command works outside tmux (I'm running it to write this bug report inside urxvt). Reverting back to version 1.2-1 makes this bug disappear. This bug affect a lot of unrelated software, but obviously only if run inside tmux. Thanks, Gian Piero. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-3-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF8, LC_CTYPE=it_IT.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages tmux depends on: ii libc62.10.2-7Embedded GNU C Library: Shared lib ii libevent-1.4-2 1.4.13-stable-1 An asynchronous event notification ii libncurses5 5.7+20100313-2 shared libraries for terminal hand tmux recommends no packages. tmux 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#577915: etckeeper: darcs message log should't be passed via '-m' option
Package: etckeeper Version: 0.44 Severity: normal Tags: sid Please revert the following change: * Use darcs record -m to specify commit message, instead of using a logfile as it breaks darcs commit. --- Prehook ran successfully. darcs: Patch names cannot contain newlines. E: Problem executing scripts DPkg::Post-Invoke 'if [ -x /usr/sbin/etckeeper ]; then etckeeper post-install; fi' E: Sub-process returned an error code --- At least for the current version of darcs shipped within Debian, the '-m' option is used for passing only the patch name (a single line), not the whole log. Thanks, Gian Piero. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-3-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF8, LC_CTYPE=it_IT.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages etckeeper depends on: ii darcs 2.4-1 a distributed, interactive, smart ii debconf [debconf-2.0] 1.5.32 Debian configuration management sy Versions of packages etckeeper recommends: ii cron 3.0pl1-109 process scheduling daemon etckeeper suggests no packages. -- Configuration Files: /etc/etckeeper/etckeeper.conf changed: VCS=darcs GIT_COMMIT_OPTIONS= HG_COMMIT_OPTIONS= BZR_COMMIT_OPTIONS= DARCS_COMMIT_OPTIONS=-a AVOID_DAILY_AUTOCOMMITS=1 HIGHLEVEL_PACKAGE_MANAGER=apt LOWLEVEL_PACKAGE_MANAGER=dpkg -- debconf information: * etckeeper/commit_failed: etckeeper/purge: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#577918: typo in /etc/etckeeper/commit.d/50vcs-commit
Package: etckeeper Version: 0.44 Severity: minor Tags: upstream sid In /etc/etckeeper/commit.d/50vcs-commit: 51 elif [ $VCS = darcs ] [ -d _darcs ]; then 52 if [ -n $USER ]; then 53 USER=root 54 fi I think it's supposed to be: 52 if [ -z $USER ]; then Thanks, Gian Piero. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-3-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF8, LC_CTYPE=it_IT.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages etckeeper depends on: ii darcs 2.4-1 a distributed, interactive, smart ii debconf [debconf-2.0] 1.5.32 Debian configuration management sy Versions of packages etckeeper recommends: ii cron 3.0pl1-109 process scheduling daemon etckeeper suggests no packages. -- Configuration Files: /etc/etckeeper/etckeeper.conf changed: VCS=darcs GIT_COMMIT_OPTIONS= HG_COMMIT_OPTIONS= BZR_COMMIT_OPTIONS= DARCS_COMMIT_OPTIONS=-a AVOID_DAILY_AUTOCOMMITS=1 HIGHLEVEL_PACKAGE_MANAGER=apt LOWLEVEL_PACKAGE_MANAGER=dpkg -- debconf information: * etckeeper/commit_failed: etckeeper/purge: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529670: RFS: maildirsync (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.2~20090613-1 of my package maildirsync. It builds these binary packages: maildirsync - simple and efficient Maildir synchronisation utility The package appears to be lintian clean. The upload would fix these bugs: 356207, 379091, 440364, 529670 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/maildirsync - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/maildirsync/maildirsync_1.2~20090613-1.dsc I would be glad if someone uploaded this package for me. Kind regards Gian Piero Carrubba -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100228130841.ga12...@caimano.rm-rf.it -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529670: RFA: maildirsync -- simple and efficient Maildir synchronisation utility
package wnpp retitle 529670 ITA: maildirsync -- simple and efficient Maildir synchronisation utility thanks On Wed, Feb 10, 2010 at 07:25:32PM +0100, Ola Lundqvist wrote: If I remember correctly Jose have no time for Debian work anymore, so we are really looking for someone to adopt this package instead of just helping out. However suggesting patches to problems is always welcome. :-) mmmh, ok, I think I can afford it... this package doesn't require a lot of work and, well, upstream has stopped developing it long ago and a more efficient alternative is now available via the syncmaildir package, so it's only a matter of a release cycle or so before safely removing it from the repository... Contacting upstream and asking for some advice on ment...@l.d.o... Ciao, Gian Piero. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100214161429.ga2...@caimano.rm-rf.it
Bug#529670: RFA: maildirsync -- simple and efficient Maildir synchronisation utility
(Ola, CCing you as maildirsync uploader, hoping I'm not generating too much noise) On Wed, May 20, 2009 at 06:33:35PM -0300, Jose Carlos Medeiros wrote: Package: wnpp Severity: normal Hi Jose, I'm wondering if you're interested in just some help with this package, instead of an adoption. If so, feel free to contact me, I'm willing to help. An updated package is available on mentors.d.n[1], please check it if you have some spare time. Ciao, Gian Piero. [1] http://mentors.debian.net/debian/pool/main/m/maildirsync -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#356207: maildirsync: failed to sync some mails
package maildirsync
tags 356207 patch
thanks
The attached patch should fix the reported problem.
Thanks,
Gian Piero.
Description: Accept any supposedly allowed name for message files
See http://cr.yp.to/proto/maildir.html for the original specification of
maildir format.
.
A message file name is in the form `uniq:info'.
`uniq' must be a unique name and can be anything that doesn't contain a
colon (or slash) and doesn't start with a dot.
`:info' is added when moving a message from new/ to cur/ and starts with
:1, (experimental) or :2, (standard semantics).
.
This patch is a bit relaxed in respect of the specification because:
- allows `:info' to be present in messages in new/ (i.e., this is the case in
mutt when you flag a new message without reading it);
- allows any character (but the slash) to be present in `:info' after the
required comma. See also Maildir filename extensions ( reference to
non-standard fields ) at http://wiki.dovecot.org/MailboxFormat/Maildir
Forwarded: no
Bug-Debian: http://bugs.debian.org/356207
Author: Gian Piero Carrubba gpi...@rm-rf.it
Last-Update: 2010-01-24
--- a/maildirsync.pl
+++ b/maildirsync.pl
@@ -458,7 +458,7 @@
}
sub pack_filedata ($) { my ($path) = @_;
-my ($message_id) = $path =~
m{.*/(\d+\..*?\.[[:alnum:]._-]+(?:,.*?)?)(?:\:.*)?$}
+my ($message_id) = $path =~
m{.*/(?:cur|new)/([^\.\:/][^\:/]*+)(?:\:(?:1|2),[^/]*)?+$}
or return (); # not valid
return ($message_id, $path);
}
Bug#518102: apticron: Please let the config files readable by everyone
Package: apticron Version: 1.1.27 Severity: minor The patch included in 1.1.21 was wrong wrt config files (/etc/cron.d/apticron, /etc/apticron/apticron.conf) permissions. Sorry for that. Having config files (that don't contain sensitive data) not readable by everyone is just a way to annoy people. The simple patch proposed fix this for new installations, but doesn't for upgrades. IMHO, the preferable (and simplest) way is to add a note in NEWS.Debian explaining that the sysadmin could change the file permissions by hand (including files in /var/lib/ucf/). Thanks, Gian Piero. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (990, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=it_IT.UTF8, LC_CTYPE=it_IT.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages apticron depends on: ii apt0.7.20.2 Advanced front-end for dpkg ii bsd-mailx 8.1.2-0.20071201cvs-3 A simple mail user agent ii cdebconf [debconf- 0.138lenny2 Debian Configuration Management Sy ii debconf [debconf-2 1.5.24Debian configuration management sy ii ucf3.0016Update Configuration File: preserv Versions of packages apticron recommends: ii apt-listchanges 2.83 package change history notificatio ii iproute 20080725-2 networking and traffic control too apticron suggests no packages. -- debconf information: * apticron/notification: apticron Tue Mar 3 18:58:22 CET 2009 Gian Piero Carrubba gpi...@rm-rf.it * Fix configuration files permissions for new installations. Ignore-this: 9519c232a52e8977ff7b858ed45309bf diff -rN -u old-apticron-1.1.28+wip1/debian/postinst new-apticron-1.1.28+wip1/debian/postinst --- old-apticron-1.1.28+wip1/debian/postinst2009-03-03 22:04:01.0 +0100 +++ new-apticron-1.1.28+wip1/debian/postinst2009-03-03 22:04:02.0 +0100 @@ -23,6 +23,7 @@ fi tmpfile=$( mktemp -t apticron.conf.XX ) + chmod 0644 $tmpfile cat EOF $tmpfile # apticron.conf @@ -94,6 +95,7 @@ fi tmpfile=$( mktemp -t apticron.crond.XX ) + chmod 0644 $tmpfile cat EOF $tmpfile # cron entry for apticron
Bug#517911: etckeeper: please fix the prompt displayed by uninit
Package: etckeeper Version: 0.33 Severity: minor The prompt requesting for a confirmation for the uninit sub-command reads: Are you sure you want to do this? [yN] This is a little confusing, as you need to enter the whole 'yes' word to confirm, not the single character. Thanks, Gian Piero. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (990, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=it_IT.UTF8, LC_CTYPE=it_IT.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages etckeeper depends on: ii cdebconf [debconf-2.0] 0.138lenny2 Debian Configuration Management Sy ii debconf [debconf-2.0]1.5.24 Debian configuration management sy pn git-core | mercurial | bzr none (no description available) etckeeper recommends no packages. etckeeper suggests no packages. Mon Mar 2 20:42:56 CET 2009 Gian Piero Carrubba gpi...@rm-rf.it * Fix prompt to make clear the user need to type 'yes' in order to uninit. Ignore-this: 2f0736b3347b57270d2a89e3f4fe8287 diff -rN -u old-etckeeper-0.33+wip2/uninit.d/01prompt new-etckeeper-0.33+wip2/uninit.d/01prompt --- old-etckeeper-0.33+wip2/uninit.d/01prompt 2009-03-02 21:47:09.0 +0100 +++ new-etckeeper-0.33+wip2/uninit.d/01prompt 2009-03-02 21:47:10.0 +0100 @@ -4,7 +4,7 @@ echo ** Warning: This will DESTROY all recorded history for $ETCKEEPER_DIR, echo ** including the $VCS repository and ignore file. echo -printf Are you sure you want to do this? [yN] +printf Are you sure you want to do this? (Type 'Yes' to confirm.) read answer case $answer in [Yy][Ee][Ss])
Bug#517914: etckeeper: typo in the README file (uninit section)
Package: etckeeper Version: 0.33 Severity: wishlist The explanation of the uninit sub-command in the README file contains a typo that reverts the meaning (terms 'former' and 'latter' have been inverted). Thanks, Gian Piero. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (990, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=it_IT.UTF8, LC_CTYPE=it_IT.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages etckeeper depends on: ii cdebconf [debconf-2.0] 0.138lenny2 Debian Configuration Management Sy ii debconf [debconf-2.0]1.5.24 Debian configuration management sy pn git-core | mercurial | bzr none (no description available) etckeeper recommends no packages. etckeeper suggests no packages. Mon Mar 2 20:47:06 CET 2009 Gian Piero Carrubba gpi...@rm-rf.it * Fix inverted former/latter in README (uninit section). Ignore-this: d67dd5d93a957cc4c6dd727d87b00d95 diff -rN -u old-etckeeper-0.33+wip2/README new-etckeeper-0.33+wip2/README --- old-etckeeper-0.33+wip2/README 2009-03-02 21:58:58.0 +0100 +++ new-etckeeper-0.33+wip2/README 2009-03-02 21:58:58.0 +0100 @@ -215,13 +215,13 @@ something you need to preserve, or can you afford to just blow it away and check the current /etc into the new VCS? -In the former case, you just need to follow three steps: +In the latter case, you just need to follow three steps: etckeeper uninit # deletes /etc/.git! vim /etc/etckeeper/etckeeper.conf etckeeper init -In the latter case, you will need to convert the git repository to the +In the former case, you will need to convert the git repository to the other VCS using whatever tools are available to do that. Then you can run `etckeeper uninit`, move files your new VCS will use into place, edit `etckeeper.conf` to change the VCS setting, and finally
Bug#510712: initscripts: inconsistent management of /etc/nologin file|symlink
Package: initscripts Version: 2.86.ds1-38+etchnhalf.1 Severity: normal Note: assigning this report to initscripts, but it's about the source package. Hope it's ok, otherwise feel free to clone this bug against the sysvinit binary package. For a long explanation, please see Joey Hess' mail in #510582[1]. In short: - initscripts treats /etc/nologin as a symlink to /var/lib/initscripts/nologin. The link is created by postinst (if not existent - doesn't touch it if it's a regular file). The init scripts only modify /var/lib/initscripts/nologin during boot/shutdown. - shutdown(8) treats /etc/nologin as a regular file and unlink() it if cancelled or before executing init. As a result, after the first reboot /etc/nologin doesn't exist anymore (either as a file or as a symlink) and the nologin feature during boot is gone. The nologin feature on shutdown works because of shutdown(8), but only in the last 5 min before init invocation. Digging in changelogs and old bug reports, and googling around a bit, I couldn't understand the rationale beyond /etc/nologin being a symlink and the real file being out of the root fs (as noted in a changelog entry), so in the following I'm guessing a lot. Please clarify on this matter, thank you. Some suggestions I can think of: 1. For the nologin feature to work also during the init phase of halt/reboot, shutdown(8) should only unlink it if cancelled (and *not* before invoking init). The nologin file should be removed by a late script during shutdown or an early script during boot if DELAYLOGIN=no (this way you can also address the fastdown case, when nologin isn't unlinked). 2. shutdown(8) could use /var/lib/initscripts/nologin or follow /etc/nologin if it's a symlink when unlinking (please note that it follows it - if still exists - when fopen-ing for writing). However, /var/lib/initscripts/nologin could be on a separate fs (possibly not mounted). I assume shutdown(8) should only operate on root fs. 3. As 2. above, but put the real file on root filesystem (reintroducing /etc/nologin.boot?). 4. Consistently treat /etc/nologin as a regular file. 5. If, for some reason, initscripts and shutdown(8) should treat /etc/nologin differently, put an early script that recreate the symlink. Thanks, Gian Piero. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510582 -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (990, 'stable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.24-king2 Locale: LANG=it_IT.UTF8, LC_CTYPE=it_IT.UTF8 (charmap=UTF-8) Versions of packages initscripts depends on: ii deb 2.17 Miscellaneous utilities specific t ii e2f 1.39+1.40-WIP-2006.11.14+dfsg-2etch1 ext2 file system utilities and lib ii lib 2.7-16 GNU C Library: Shared libraries ii lsb 3.1-23.2etch1Linux Standard Base 3.1 init scrip ii mou 2.12r-19etch1Tools for mounting and manipulatin ii sys 2.86.ds1-38+etchnhalf.1 System-V-like utilities Versions of packages initscripts recommends: ii psmisc22.3-1 Utilities that use the proc filesy -- 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#510582: etckeeper: maybe /etc/nologin should not be ignored by default
Package: etckeeper Version: 0.25 Severity: wishlist In the last debian releases /etc/nologin is just a symlink to /var/lib/initscripts/nologin, so it should exist for regular behaviour of the nologin feature. IMHO, a better default is to include it in the repository so to recreate it if needed. Thanks, Gian Piero. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (990, 'stable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.24-king2 Locale: LANG=it_IT.UTF8, LC_CTYPE=it_IT.UTF8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510032: etckeeper: please add support for darcs backend
Package: etckeeper Version: 0.25 Followup-For: Bug #510032 Updated patch for adding support for darcs backend. For reference, I've also attached a diff from the previous version. Thanks, Gian Piero. etckeeper_0.25_darcsbackend.diff.gz Description: Binary data etckeeper_0.23-0.25_darcsbackend.diff.gz Description: Binary data
Bug#509888: etckeeper: regression in filter_unknown() caused by fix for #509888
Package: etckeeper
Version: 0.24
Followup-For: Bug #509888
The fix for #509888 seems to let filter_unknown() stop working.
The attached patch should fix it.
Thanks,
Gian Piero.
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (990, 'stable'), (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.24-king2
Locale: LANG=it_IT.UTF8, LC_CTYPE=it_IT.UTF8 (charmap=UTF-8)
--- etckeeper-0.24/pre-commit.d/30store-metadata2008-12-27
20:30:13.0 +0100
+++ /etc/etckeeper/pre-commit.d/30store-metadata2008-12-31
12:47:50.0 +0100
@@ -3,11 +3,11 @@
# Filters out UNKNOWN users and groups, prints a warning on stderr.
filter_unknown() {
- CMD=$1
+ CMD=$1 $2
while read line; do
# if the first n chars of $line equal $CMD UNKNOWN ...
if [ $(printf %.$((9+${#CMD}))s $line) = $CMD UNKNOWN ];
then
- echo Bad $2 for $line 2
+ echo Bad $3 for ${line#$1 } 2
else
echo $line
fi
Bug#510032: etckeeper: please add support for darcs backend
Package: etckeeper Version: 0.23 Severity: wishlist Tags: patch The attached patch adds support for using darcs as backend. While darcs isn't the best choice for etckeeper (because of lack of support for file permissions - namely the exec bit - and simbolic links), it can be handy for people like me that use a vcs only once in a while and are used to darcs. Please note that the attached patch changes the apt pre-install invocation from 'Pre-Install-Pkgs' to 'Pre-Invoke'. It seems to me that etckeeper doesn't use the package names received on the stdin and I think there's no other (substantial) difference between these two hooks. OTH, this allows the use of darcs w/o the -a option to the record command (commit w/o confirmation) and it's useful for examining automatic pre-install commits. Thanks, Gian Piero. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (990, 'stable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.24-king2 Locale: LANG=it_IT.UTF8, LC_CTYPE=it_IT.UTF8 (charmap=UTF-8) etckeeper_0.23_darcsbackend.diff.gz Description: Binary data
Bug#510032: etckeeper: please add support for darcs backend
On Sun, Dec 28, 2008 at 05:33:56PM -0500, Joey Hess wrote:
+ printf %s\n find $NOVCS -type l -print | xargs rm -f {}
\\;
I don't think this is safe. It could delete symlinks that are in the tree but
not
committed.
+ find $NOVCS -type l -print | sort | while read link; do
+ dest=$( readlink $link )
+ printf ln -s '%s' '%s'\n $dest $link
Maybe this should use ln -sf in case dest exists?
Yes, this snippet is scary. It's a try to deal with removal of symlinks
in addition to add/modify. I thought it can be 'almost' safe because it
should only matter when checking-out a previous version, so you should
have a working repository (with all infos replayable). On second
thought, however, yes things can go bad. I think tomorrow I'll have time
to try a different approach. I'm thinking about add/move symlinks with
link -sf, as suggested, and just warn the user about
should-to-be-deleted symlinks. Do you think it's ok? Not sure if I need
another file to store just the link names. If needed (or easier), are
you fine with another file to be added in the repo, like .darcslinks or
.etckeeper.links?
OTH, this allows the use of darcs w/o the -a option to the record
command (commit w/o confirmation) and it's useful for examining
automatic pre-install commits.
I think that etckeeper should do the pre-install commit without confirmation,
unless there´s something significantly different about darcs.
It's fine to be able to configure darcs to confirm or do the commit
interactively.
Per default, darcs works interactively asking for confirmation for every
hunk (but you can answer a for all). I think it's good as an alternative
to $AVOID_COMMIT_BEFORE_INSTALL.
Using -a in $DARCS_COMMIT_OPTIONS, let darcs automatically commit w/o
asking.
Thanks,
Gian Piero.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509888: .etckeeper script should take in account ignored files
Package: etckeeper
Version: 0.23
Severity: normal
Tags: patch
There are cases when running `etckeeper init` fails while running
./.etckeeper because the referenced file (the one ./.etckeeper is trying
to chown|chgrp|chmod) doesn't exist. In that case, the chown|chgrp|chmod
cmd raises an error and etckeeper fails (because of set -e).
This could happen while running init on a cloned repository, if the file
is 'ignored' and doesn't have 'standard' ownership/permissions, or after
a checkout of a previous version, if the file is 'ignored', doesn't have
'standard' ownership/permissions and has been removed after the
just-checked-out commit.
IMHO, two workarounds exist:
1. make pre-commit.d/30store-metadata be aware of ignore-list when
generating .etckeeper
2. let .etckeeper test the existence of a file before trying to apply
stored metadata on it
The attached patch implements the latter one.
Thanks,
Gian Piero.
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (990, 'stable'), (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.24-king2
Locale: LANG=it_IT.UTF8, LC_CTYPE=it_IT.UTF8 (charmap=UTF-8)
Sat Dec 27 14:04:54 CET 2008 Gian Piero Carrubba gpi...@rm-rf.it
* pre-commit.d/30store-metadata:
- inside the generated .etckeeper, test if a file/dir exists before
trying to apply the metadata
diff -rN -u old-etckeeper-0.23-new/pre-commit.d/30store-metadata
new-etckeeper-0.23-new/pre-commit.d/30store-metadata
--- old-etckeeper-0.23-new/pre-commit.d/30store-metadata2008-12-27
14:13:17.0 +0100
+++ new-etckeeper-0.23-new/pre-commit.d/30store-metadata2008-12-27
14:13:17.0 +0100
@@ -14,6 +14,12 @@
done
}
+add_ifexists() {
+ while read cmd par file ; do
+ printf %s\n test -e $file $cmd $par $file
+ done
+}
+
generate_metadata() {
# This function generates the script commands to fix any files
# that aren't owner=root, group=root, or mode=0644 or 0755.
@@ -36,19 +42,19 @@
# Find all files and directories that don't have root as the owner
find $NOVCS \! -user root -exec stat --format=chown %U '{}' {} \; \
- | sort | filter_unknown chown owner
+ | sort | filter_unknown chown owner | add_ifexists
# Find all files and directories that don't have root as the group
find $NOVCS \! -group root -exec stat --format=chgrp %G '{}' {} \; \
- | sort | filter_unknown chgrp group
+ | sort | filter_unknown chgrp group | add_ifexists
# Find all directories that aren't 0755
find $NOVCS -type d \! -perm 0755 \
- -exec stat --format=chmod %a '{}' {} \; | sort
+ -exec stat --format=chmod %a '{}' {} \; | sort | add_ifexists
# Find all files that aren't 0644 or 0755 (we can assume the VCS will
# maintain the executable bit).
find $NOVCS -type f \! -perm 0644 \! -perm 0755 \
- -exec stat --format=chmod %a '{}' {} \; | sort
+ -exec stat --format=chmod %a '{}' {} \; | sort | add_ifexists
# We don't handle xattrs.
# Maybe check for getfattr/setfattr and use them if they're available?
Bug#505666: monkey: please add 'Provides:' field
Package: monkey Version: 0.9.2-2 Severity: minor Monkey should 'Provides: httpd, httpd-cgi', so to satisfy dependencies for packages requiring it. Thanks, Gian Piero. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-vserver-686 (SMP w/1 CPU core) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages monkey depends on: ii libc6 2.7-15 GNU C Library: Shared libraries monkey recommends no packages. monkey suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451341: txt2tags: new upstream version (2.4) available
As a side note, the diff from previous version applies cleanly and
only minimal changes are required in debian/.
Attached there's a a diff between diffs (ugh) generated by interdiff.
Ciao,
Gian Piero.
diff -u txt2tags-2.3/debian/changelog txt2tags-2.4/debian/changelog
--- txt2tags-2.3/debian/changelog
+++ txt2tags-2.4/debian/changelog
@@ -1,3 +1,15 @@
+txt2tags (2.4-0) unstable; urgency=low
+
+ * New upstream release (closes: #451341).
+- txt2tags-mode.el: added installation instructions (closes: #290806)
+- new mark %%% for commented blocks (closes: #290928)
+- fixed fatal error on empty table (closes: #434547)
+ * debian/rules:
+- exclude Mac OS resource fork file
+- install i18n manpages
+
+ -- Gian Piero Carrubba [EMAIL PROTECTED] Mon, 03 Dec 2007 11:23:07 +0100
+
txt2tags (2.3-1) unstable; urgency=low
* New upstream release (Closes: #290800)
diff -u txt2tags-2.3/debian/docs txt2tags-2.4/debian/docs
--- txt2tags-2.3/debian/docs
+++ txt2tags-2.4/debian/docs
@@ -1,6 +1,4 @@
README
-README-FIRST
-TEAM
TODO
extras/
doc/
diff -u txt2tags-2.3/debian/rules txt2tags-2.4/debian/rules
--- txt2tags-2.3/debian/rules
+++ txt2tags-2.4/debian/rules
@@ -46,7 +46,7 @@
# Add here commands to clean up after the build process.
#-$(MAKE) clean
rm -f po/*.mo
- rm -f txt2tags.1
+ rm -f txt2tags*.1
dh_clean
@@ -70,7 +70,7 @@
dh_testroot
dh_installchangelogs ChangeLog
dh_installdocs
- dh_installexamples
+ dh_installexamples --exclude=._t2tpowered-black.png
# dh_install
# dh_installmenu
# dh_installdebconf
@@ -82,8 +82,11 @@
# dh_installcron
# dh_installinfo
cd po $(MAKE) install BASEDIR=$(CURDIR)/debian/txt2tags
- cp doc/manpage.man txt2tags.1
- dh_installman txt2tags.1
+ for src in doc/manpage*.man ; do \
+ dst=$$( echo $${src##*/} | sed
's/manpage\(.*\)\.man/txt2tags\1.1/;s/-/./g;' ); \
+ cp $$src $$dst ; \
+ done
+ dh_installman txt2tags*.1
dh_link
dh_strip
dh_compress
Bug#440626: apticron: sleeps in /etc/cron.daily, delaying other scripts
Package: apticron Version: 1.1.20 Tags: patch Followup-For: Bug #440626 The attached patches implement a possible solution extracted from the thread the OP referenced to. IMHO, further enhancements can be: - ensure that the cron script run by night (say 22:00-06:00) - a minimal (60secs shouldn't hurt) random sleep in cron.daily so to deal with missed cron.d jobs The second patch adds dependencies on ucf, so don't apply the whole patch if you don't want to clash with bug #410404. Regards, Gian Piero. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18-13etch2-king-1 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages apticron depends on: ii apt 0.6.46.4-0.1Advanced front-end for dpkg ii apt-listchanges 2.72.5 Display change history from .deb a ii cdebconf [debcon 0.114 Debian Configuration Management Sy ii debconf [debconf 1.5.11 Debian configuration management sy ii iproute 20061002-3 Professional tools to control the ii mailx1:8.1.2-0.20050715cvs-1 A simple mail user agent apticron recommends no packages. -- debconf information: * apticron/notification: apticron apticron_1.1.20.1.diff.gz Description: Binary data apticron_1.1.20.2.diff.gz Description: Binary data
Bug#451341: txt2tags: new upstream version (2.4) available
Package: txt2tags Version: 2.3-1 Severity: wishlist A newer upstream version (2.4) is available at [1], please consider packaging it. AFAI understand, it should close bugs #434547 [2] and #290928 [3]. Thanks, Gian Piero. [1] http://prdownloads.sourceforge.net/txt2tags/txt2tags-2.4.tgz?download [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=434547 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=290928 -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18-13etch2-king-1 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages txt2tags depends on: ii python2.4.4-2An interactive high-level object-o txt2tags recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434631: bc: base ( obase, ibase ) error-by-one
Package: bc Version: 1.06-20 Severity: normal Maybe I haven't correctly understood the obase|ibase use, but this seems very strange to me: $ echo 'ibase=F ; E; F; 10; 11' | bc 14 15 15 16 $ echo 'obase=F ; 13; 14; 15; 16' | bc D E 10 11 Just discovered, no idea about where this behaviuor come from. Regards, Gian Piero. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18.dfsg.1-11-king-1 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages bc depends on: ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libncurses5 5.5-5Shared libraries for terminal hand ii libreadline55.2-2GNU readline and history libraries bc recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409862: Single letter hostnames are rejected as incorrect
Il giorno Thu, 15 Mar 2007 07:38:46 +0100 Ola Lundqvist [EMAIL PROTECTED] ha scritto: That should be [[:lower:][:digit:]]*(*([[:lower:][:digit:]_-])[[:lower:][:digit:]])) But this regex still allow -a, right? Mmh, no... well, it doesn't here :). Please use [:class:] instead of [a-z] as the latter is locale dependant and, while it seems reverted on recent bash, i think i can remember that a not-so-old release of bash broke it down ( well, the bash is/was right, the scripts aren't ). Hmm, well I'm not sure if I want to allow other letters than that. Not sure I'm following you here. [[:lower:]] is the same that [a-z], but better :): [EMAIL PROTECTED]:~/test$ touch a A b B y Y z Z [EMAIL PROTECTED]:~/test$ echo $LC_COLLATE C [EMAIL PROTECTED]:~/test$ ls [a-z] a b y z [EMAIL PROTECTED]:~/test$ ls [[:lower:]] a b y z [EMAIL PROTECTED]:~/test$ export LC_COLLATE=[EMAIL PROTECTED] [EMAIL PROTECTED]:~/test$ ls [a-z] a A b B y Y z [EMAIL PROTECTED]:~/test$ ls [[:lower:]] a b y z As said, it seems that now ( at least etch - bash 3.1dfsg-8 ) the case .. in match follows the COLLATE=C behaviour, but anyway [:class:] should be a safer choice. Do posix allow other letters? Tried to quickly dig into SUSv3 w/o finding any reference to it ( please note that I haven't found != there's none ). Anyway IMHO trying to melt down POSIX, DNS, RFC, conventions and various implementations is really a pain and I'm not sure the OP was kidding when said you, as the coder, have to take your decision ( i assume you already did, i.e., when allowed only lower characters ). As for my ( very personal ) thought I'd use [[:alnum:]]*(*([[:alnum:]-])[[:alnum:]]) ( note the lacking of dash and the case insensitive match ) that IMHO should be a valid rfc hostname ( apart from not enforcing an upper lenght limit ), as the 2-characters lower limit isn't so clearly affirmed ( think about the DN root servers ). Ciao, Gian Piero. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409862: Single letter hostnames are rejected as incorrect
Il giorno Fri, 16 Mar 2007 15:44:54 +0100 Ola Lundqvist [EMAIL PROTECTED] ha scritto: As for my ( very personal ) thought I'd use [[:alnum:]]*(*([[:alnum:]-])[[:alnum:]]) Agree in principle. ( note the lacking of dash and the case insensitive match ) Why the lack of dash? Because it isn't a valid character as for some DNS-related RFC. However, on second thought, I'm now remembering the homograph attack and so IDN and what that implies about allowed characters. While the above regex covers the majority of cases, it surely doesn't allow legitimate hostnames. Maybe letting the user be on his own about the choice of the hostname is the safest way, unless you also want to deal with IDNA. I think your suggestion above is fully ok, but I think I have to allow dash, at least for backwards compatibility. Good point. Ciao, Gian Piero. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409862: Single letter hostnames are rejected as incorrect
Package: vserver-debiantools
Version: 0.3.4
Followup-For: Bug #409862
Although this bus is tagged 'patch', i can't see an answer to your last
question, so i'm writing this followup. Please ignore it if i'm wrong.
Ola said:
But if you know a good way to accept
x
xa
x-a
but not
x-
-a
as hostname, that would be great.
That should be
[[:lower:][:digit:]]*(*([[:lower:][:digit:]_-])[[:lower:][:digit:]]))
However i don't know how to check the hostname lenght in the same regex
( so you need an extra check on ${#var} ).
Please use [:class:] instead of [a-z] as the latter is locale dependant
and, while it seems reverted on recent bash, i think i can remember that a
not-so-old release of bash broke it down ( well, the bash is/was right,
the scripts aren't ).
PS: Ola, are you working on this package these days ? If i'll have some
time on the next days i'd like to make some changes ( primarily move the
common functions in a /usr/lib script and make stripserver work with
non-legacy configurations ), so if you have a public repository/vs
please point me to it ( haven't found in /u/s/d/v-d/copyright ).
Ciao,
Gian Piero.
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.18.dfsg.1-11-king-1
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8)
Versions of packages vserver-debiantools depends on:
ii binutils 2.17-3 The GNU assembler, linker and bina
ii debootstrap 0.3.3.2Bootstrap a basic Debian system
ii rsync 2.6.9-2fast remote file copy program (lik
ii util-vserver 0.30.211-6 user-space tools for Linux-VServer
vserver-debiantools recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411886: bashism in /etc/init.d/monit
Package: monit
Version: 1:4.8.1-2.1
Severity: minor
Tags: patch
The '-e' option to echo isn't susv3 ( POSIX ) compliant
[ http://www.opengroup.org/onlinepubs/009695399/utilities/echo.html ].
As you can see below, my /bin/sh is linked to /bin/dash.
$ head -n1 /etc/init.d/monit
#!/bin/sh
$ sudo /etc/init.d/monit start
Starting daemon monitor: -e monit won't be started/stopped
unless it it's configured
-e please configure monit and then edit /etc/default/monit
-e and set the startup variable to 1 in order to allow
-e monit to start
While this is a violation of a 'must' clause of Debian Policy ( §10.4 ),
the impact is almost null, so a minor severity seems more than adequate
to me ( especially during freeze time ).
Please, change the she-bang line to '#!/bin/bash' or apply the attached
patch ( or a similar one ).
Thanks,
Gian Piero.
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.18-7-king-4
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8)
Versions of packages monit depends on:
ii libc6 2.3.6.ds1-11 GNU C Library: Shared libraries
ii libssl0.9.8 0.9.8c-4 SSL shared libraries
monit recommends no packages.
-- no debconf information
--- /etc/init.d/monit.orig 2006-11-13 13:55:37.0 +0100
+++ /etc/init.d/monit 2007-02-21 16:42:44.0 +0100
@@ -23,12 +23,12 @@
ARGS=-d $CHECK_INTERVALS -c $CONFIG -s /var/lib/monit/monit.state
monit_not_configured () {
-echo -e monit won't be started/stopped\n\tunless it it's configured
+printf %b\n monit won't be started/stopped\n\tunless it it's configured
if [ $1 != stop ]
then
-echo -e \tplease configure monit and then edit /etc/default/monit
-echo -e \tand set the \startup\ variable to 1 in order to allow
-echo -e \tmonit to start
+printf %b\n \tplease configure monit and then edit
/etc/default/monit
+printf %b\n \tand set the \startup\ variable to 1 in order to
allow
+printf %b\n \tmonit to start
fi
exit 0
}
Bug#396320: day 31 out of range
Package: spamassassin Followup-For: Bug #396320 Got the same log. However it turned out to be a spam message dated 31 Nov, as the date passed to timegm() comes from the Date: header. Ciao, Gian Piero. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.17-9-king-2 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#208939: acknowledged by developer (Bug#208939: fixed in acct 6.3.99+6.4pre1-1)
On Thu, 23 Mar 2006 15:33:21 -0800 [EMAIL PROTECTED] (Debian Bug Tracking System) wrote: - adjusted logfile path for logger call in init.d (Closes: #208939). The init script hasn't been changed accordingly. As on my original post i've wrongly attached a reverse patch, i'm unsure if it's a don't fix or a damn... if you want to post a patch, try to post the right patch bug :) Thanks, Gian Piero. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
