Bug#738286: Fix autologin to use getty
Ok,
I had a system crash but I was able to find the configs I used for this.
It only applies to sysvinit in the form I did it.
I modifed the file lib/live/config/0170-sysvinit so that it has the
following:
In function Configure_sysvinit:
# Configure autologin
sed -i -e s|^\([^:]*:[^:]*[^:]*\):\(.*getty\) \(.*getty\) \(.*\)$|\1:\2
${LIVE_USERNAME:+-a $LIVE_USERNAME }\3| /etc/inittab
Sorry, for taking so long, in part I thought I had at least already
posted this part of the details, but apparently not.
I'm unlikely to actually have the chance to make a patch anytime soon
though.
Regards,
Daniel
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775612: amanda-server: Depends on Tie/StdHash.pm which exists on NO package in debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Also note that the bug is intermittent which means the permission denied is probably a red herring or at least not the full story because I hadn't been changing the permssions. At this point I'm on wheezy because I rather need backups to work. Regards, Danie On 2015-01-25 2:41 PM, Daniel Curran-Dickinson wrote: Based on other issues it looks to me like something important is Jessie is misbehaving but I have no idea what. The *same* crypted RAID array works absolutely fine with Wheezy (3.2 kernel) - the only difference beetween Wheezy and Jessie on this box is the root filesystem and kernel it boots with. Therefore I have ruled out hardware issue and clearly seen an OS issue of some kind. Regards, Daniel On 2015-01-25 2:35 PM, Damyan Ivanov wrote: Control: severity -1 normal Control: tags -1 unreproducible -=| Daniel Dickinson, 17.01.2015 19:03:49 -0500 |=- Package: amanda-server Version: 1:3.3.6-4 Severity: serious Justification: depends on software not in debian Seen when attemping to do amrmtape, but also occurs when doing a flush: an't locate Tie/StdHash.pm: Permission denied at /usr/share/perl/5.20/base.pm line 97. ...propagated at /usr/share/perl/5.20/base.pm line 106. BEGIN failed--compilation aborted at /usr/lib/amanda/perl/Amanda/Config/FoldingHash.pm line 3. Compilation failed in require at /usr/lib/amanda/perl/Amanda/Config.pm line 753. BEGIN failed--compilation aborted at /usr/lib/amanda/perl/Amanda/Config.pm line 753. Compilation failed in require at /usr/sbin/amrmtape line 27. BEGIN failed--compilation aborted at /usr/sbin/amrmtape line 27. Note the error Permission denied. I think this is somehow related to your environment. StdHash.pm is not a file that exists in ANY package in debian according to apt-file. The Tie::StdHash package is defined in /usr/share/perl/5.20.1/Tie/Hash.pm, which is part of the 'perl-base' package. Definitely in Debian :) -- dam -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJUzeDuAAoJEIcvryNiYx3FVnAH/2tP7pBimaTbdq3bszD1DrUQ Qxe0Bg3RO4Y7TJzDvU9I2WL7lR5RMdWKhpFODAp8/LDqgnJcHJrpVtLOKrSEC1jT 2izxus2hIyvY/D7J8IL5NhT7fraZkegWKM+TN3+HSaa8Nm0pXrjXpLQHrJGN+xwG U3HRPzjXrcyHPQm2Szwri/PaJkMzAMXGYhehHYy4vTtAsiLaw7RRrCrFEjTOKU7J tfQygkiD4Yw7vBXrbZRnWgjapNwuOOyY+NJ5Vxwqo3pBXocSkWb71ZBmtJI4Mv8I cEZV0Jkb/DcCRUDbJHiJzAnF2XAgvG3IkeAKgMQMwcAMN7IdkXKZj5kjE3r4Z5w= =gjV4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774904: systemd: Some systems (upgrades?) fail to put journal into syslog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have confirmed that on both systems I still have that were upgraded from wheezy that rsyslog has a system unit that does not get enabled. I suspect the third also had the same issue (it had log issues) but I had to revert it to jessie due to what looks like a major kernel issues that eats data and what is probably different issues that causes my scsi card to reset while doing backups. Also there were some intermittent issues with amanda backup where perl was failing to find modules that were definitely present. It's not a hardware issue because with wheezy there are zero problems on the same crypted raid array - only the root filesystem is different (even the data lvm volumes are the same). Since backups need to work I kept the rootfs for investigations, but don't run jessie on the machine now. Regards, Daniel On 2015-01-08 4:10 PM, Michael Biebl wrote: control: tags -1 moreinfo Am 08.01.2015 um 22:00 schrieb Daniel Dickinson: Package: systemd Version: 215-8 Severity: normal As I mentioned in my previous bug report I've (at least temporarily) had to switch my system back to sysvinit because of issues with initscripts failing to start on some systems, however I still feel I ought to report the bugs I've found. This second bug is that on system systems (upgrades) the journal fails to go to the syslog. This seemed to have been resolved on the system where I originally observed it (and the bug on the topic closed), however it turns out that after a reboot the problem came back. In particular deluged and cyrus-imapd had no logs even though the information was in journalctl. deluged actually logs to a non-syslog file but errors with starting deluge go to journal (because it's before deluge is actually started and the init system that is doing the logs). Which syslog daemon is running on those systems, syslog-ng, rsyslog, ...? Which version of that package is installed? What is the output of systemctl status syslog.socket syslog.service? If you run logger foobar, does this end up in /var/log/syslog? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJUzd3VAAoJEIcvryNiYx3FtXAH/ifxS/T04W+Bpy653eGjwqYs lDmUOImlSOcv8LMdbKXLrmdoE3ICTEOKwfBnO0I+ECUNjBdWvJCD2IyjC1h8EpFq 33mN4dW+5BWvYFTIiX/jbXyQ9NnNnwu3Fhkz02Jr41XitMk5VfnDSuw0nk8NdACk XVO6997pjXrHOHSQLNkBBamLrqo3l2sCoBdAHGIKYXCRNZHcWMgssTlpSdDRM28F 4TV2z3PokxJayZ4AWwo7XAlyNvmG/4c25vPdgsEj4RswF6g8VRdpO2tPQAi45C3Y 3Tt/uGKP0tdBhuUavs3FMhAyvUJaV01j9OUJQvj0e+nrKwYpJ7qpnDGl2hxNaNk= =VtMY -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775612: Duplicate and kernel bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I believe, despite this difference in effect that this is a duplicate of #774329, which is also a permissions issue. The thing is that the issues are intermittent and therefore either the permissions are getting changed (unlikely as I have no processes which would do this) or, more likey, particularly in view of the fact the SCSI adapter resets frequently while attempting to do backups, it is some sort of kernel issue that affects filesystem access (ext4 on luks crypted raid array in this case). The scsi adapter does not hold the filesystem; it is only used for the tape drive. I believe this bug should be merged with #774329 and moved to the kernel (3.16 amd64). Regards, Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJUztI0AAoJEIcvryNiYx3FouYH/2j2vpz8GfPLecxxITV2ON5e WPwZYA794of/CYpelngQV6xV4X5ZjF+CPes0dmBEOVQEQ+CLN3wvUjmCwkjFWY+f kfu2r/TK9EeGerMR7GIu2dl71etz1jw8pEmgBIXH61b3i6l2UtWhH3KRJDUSKgs6 K8sim6hJsya0kaHeiXtsi9/esMVdx+5KVWQFP9zSMi9JOxl2a4Q1CYiarzGHsCz5 lNmMhNx8mD4JACqgkSCUandX+rn48QRGfGp7wOzRgd2+k/oGR5Vl1Mljp5hVWlkW GNSt+y2eNkeTpS6JOXPt5h0uyql3o4Vdm1F5/Ta5a3aVnNym+7g4P3k2JV8SJcA= =ZJOW -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774329: Duplicate and kernel bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I believe, despite this difference in effect that this is a duplicate of #775612, which is also a permissions issue. The thing is that the issues are intermittent and therefore either the permissions are getting changed (unlikely as I have no processes which would do this) or, more likey, particularly in view of the fact the SCSI adapter resets frequently while attempting to do backups, it is some sort of kernel issue that affects filesystem access (ext4 on luks crypted raid array in this case). The scsi adapter does not hold the filesystem; it is only used for the tape drive. I believe his bug should be merged with #775612 and moved to the kernel (3.16 amd64). Regards, Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJUztIyAAoJEIcvryNiYx3Fbl4IAKUFLbYj0+uj5ItL8QMkBg39 DQ8wM6w5ji/9VVPFZKOKW8D0XcgS4xGGAq3mkTeGRUBsHITgNOBe9w0TUTTlufnf pAayn7PruKB2Q6o6NLiFStdTpBluYq8yvXd47AwQSfEgFuJsQKl665f7WiwYlVVl 12eMeFCXrSu8gXGPfWIOgfH8LTA0HE9Z9UIGuUXR+MITT1n2vqkATT0Wx9utfsYX iafxvR26QyBoXBXtEFrmWVviHvB+RKqxqRfpLA++EHsPBrzxEkgMIZkXHM+N+ORF z8C7wVZZsigMmCPqBLJPCqPkvFIqmdmUxfCMiX8UmGJiG4pHacUgEJrBb7rFfHo= =g5y2 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776809: /usr/sbin/cyrus: sieve: :contains fails to actually match addresses
Package: cyrus-common
Version: 2.4.17+caldav~beta10-16
Severity: normal
File: /usr/sbin/cyrus
When using sieve scripts (managed using a Manage Sieve client)
conditions such as
if address :contains From @example.com
fail to be acted on (that is the match fails).
The compilation succeeds so there is no syntax issue, and :is works fine.
Regards,
Daniel
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/5 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages cyrus-common depends on:
ii adduser3.113+nmu3
ii db-upgrade-util5.3.0
ii db-util5.3.0
ii debconf [debconf-2.0] 1.5.55
ii dpkg 1.17.23
ii exim4-daemon-heavy [mail-transport-agent] 4.84-6
ii gawk 1:4.1.1+dfsg-1
ii libc6 2.19-13
ii libcomerr2 1.42.12-1
ii libdb5.3 5.3.28-7~deb8u1
ii libical1a 1.0-1.3
ii libkrb5-3 1.12.1+dfsg-16
ii libldap-2.4-2 2.4.40-3
ii libsasl2-2 2.1.26.dfsg1-12
ii libsasl2-modules 2.1.26.dfsg1-12
ii libsnmp30 5.7.2.1~dfsg-7
ii libsqlite3-0 3.8.7.1-1
ii libssl1.0.01.0.1k-1
ii libwrap0 7.6.q-25
ii libzephyr4 3.1.2-1
ii netbase5.3
ii perl 5.20.1-5
ii zlib1g 1:1.2.8.dfsg-2+b1
Versions of packages cyrus-common recommends:
ii cyrus-admin 2.4.17+caldav~beta10-16
ii cyrus-caldav 2.4.17+caldav~beta10-16
ii cyrus-imapd 2.4.17+caldav~beta10-16
Versions of packages cyrus-common suggests:
ii apt-listchanges2.85.13+nmu1
ii cyrus-admin2.4.17+caldav~beta10-16
ii cyrus-caldav 2.4.17+caldav~beta10-16
ii cyrus-clients 2.4.17+caldav~beta10-16
ii cyrus-doc 2.4.17+caldav~beta10-16
ii cyrus-imapd2.4.17+caldav~beta10-16
pn cyrus-murder none
pn cyrus-nntpdnone
pn cyrus-pop3dnone
pn cyrus-replication none
ii sasl2-bin 2.1.26.dfsg1-12
-- Configuration Files:
/etc/cyrus.conf changed:
START {
# do not delete this entry!
recover cmd=/usr/sbin/cyrus ctl_cyrusdb -r
# this is only necessary if idlemethod is set to idled in imapd.conf
#idled cmd=idled
# this is useful on backend nodes of a Murder cluster
# it causes the backend to syncronize its mailbox list with
# the mupdate master upon startup
#mupdatepush cmd=/usr/sbin/cyrus ctl_mboxlist -m
# this is recommended if using duplicate delivery suppression
delprunecmd=/usr/sbin/cyrus expire -E 3
# this is recommended if caching TLS sessions
tlsprunecmd=/usr/sbin/cyrus tls_prune
}
SERVICES {
# --- Normal cyrus spool, or Murder backends ---
# add or remove based on preferences
imapcmd=imapd -U 30 listen=localhost:imap prefork=0
maxchild=100
imaps cmd=imapd -s -U 30 listen=imaps prefork=0
maxchild=100
#pop3 cmd=pop3d -U 30 listen=pop3 prefork=0 maxchild=50
#pop3s cmd=pop3d -s -U 30 listen=pop3s prefork=0
maxchild=50
#nntp cmd=nntpd -U 30 listen=nntp prefork=0 maxchild=100
#nntps cmd=nntpd -s -U 30 listen=nntps prefork=0
maxchild=100
# At least one form of LMTP is required for delivery
# (you must keep the Unix socket name in sync with imap.conf)
#lmtp cmd=lmtpd listen=localhost:lmtp prefork=0
maxchild=20
lmtpunixcmd=lmtpd listen=/var/run/cyrus/socket/lmtp
prefork=0 maxchild=20
# --
# useful if you need to give users remote access to sieve
# by default, we limit this to localhost in Debian
sieve cmd=timsieved listen=0.0.0.0:sieve prefork=0
maxchild=100
# this one is needed for the notification services
notify cmd=notifyd listen=/var/run/cyrus/socket/notify
proto=udp prefork=1
# CalDAV / CardDAV / RSS
#http cmd=httpd listen=http prefork=0 maxchild=50
https cmd=httpd -s listen=0.0.0.0:30443 prefork=0
maxchild=50
# --- Murder frontends -
# enable these and disable the
Bug#774329: [Pkg-libvirt-maintainers] Bug#774329: libvirt-bin: Doesn't gracefully shutdown guests on upgrade restart
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry I didn't record that information at the time as I was in a hurry and have no further information I can give you. For now the bug will have to wait until someone else encounters it. Regards, Daniel On 2015-01-07 2:30 AM, Guido Günther wrote: On Thu, Jan 01, 2015 at 09:45:19AM -0500, Daniel Dickinson wrote: On 01/01/15 05:11 AM, Guido Günther wrote: On Wed, Dec 31, 2014 at 05:27:03PM -0500, Daniel Dickinson wrote: Package: libvirt-bin Version: 1.2.9-7 Severity: grave Justification: causes non-serious data loss If libvirt-bin has an upgrade requiring a restart it restarts and kills currently active guests without first gracefully shutting them down. This can result in data loss due to damaged filesystems (hence the grave report). This also happens with no warning so there is no opportunity to manually shutdown the clients. Libvirt keeps qemu guests running and reattaches to them. Please provide steps to reproduce. -- Guido Perhaps it's a systemd issue because after qemu-kvm session was killed systemd still had a unit hanging about for it that prevented me from restarting the vm until I rebooted the host. I did verify that no qemu/kvm was running after. Aside from that I have no 'special' steps to reproduce other than that I had libvirt-bin and a guest running, did an upgrade and discovered by guest was gone and I couldn't restart it. Please provide at least the version you upgraded from and the vm configuration. -- Guido -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJUzuUTAAoJEIcvryNiYx3FeiwH/3h5IKQH6zSmBuPJX5uCebpY xBrprH5kvtJuZ/IM3lGGAn3bqLj5n/OPw9XDCbqsxZSDbS8cswT8ZRo9A2vTeGLv YnSsJv8GIlddlLCbm9ngwTJwEcsxNiFhoX+WeILbiATZfS9RgLUadGjrNiFhsg/3 BBrEqI4Z8zhIbyYsADP1L1u4azGFYYltbmTOSREUNNrmMvkVuy3IyUieBTtZfiEx jif0jZ7+gm19XE0EiMLjpc92SJ53pRhfTtBb4dKzERNQBLNvcF0pZOVfl+QqyN/x 7vLC/Ch+IU82F5n2bRgZMRVlbtH+YUC18w7ENv5e70iSKz/QAPMH2e/oT6PleIA= =quKw -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776680: shorewall: Fails to start/restart on jessie; systemctl complains no shorewall.service
Package: shorewall Version: 4.6.4.3-1 Severity: grave Justification: renders package unusable A firewall that is never applied is useless hence a bug that stops shorewall from being applied under the default init system (systemd) is RC. In this case the issue is that /etc/init.d/shorewall restart (or start) OR systemctl restart shorewall OR systemctl start shorewall all give the following error message: Failed to restart shorewall.service: Unit shorewall.service failed to load: No such file or directoryFailed to restart shorewall.service: Unit shorewall.service failed to load: No such file or directory As I have mentioned on another bug report against systemd itself, for some old-style SystemV initscripts systemd fails to start or restart the service. I haven't had a chance to boot those systems with systemd to follow up on the bug report but the claim that systemd won't break existing initscripts is clearly false. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages shorewall depends on: ii bc 1.06.95-9 ii debconf [debconf-2.0] 1.5.55 ii iproute1:3.16.0-2 ii iproute2 3.16.0-2 ii iptables 1.4.21-2+b1 ii perl-modules 5.20.1-4 ii shorewall-core 4.6.4.3-1 shorewall recommends no packages. Versions of packages shorewall suggests: ii make-guile [make] 4.0-8.1 pn shorewall-doc none -- Configuration Files: /etc/default/shorewall changed: startup=1 OPTIONS= STARTOPTIONS= INITLOG=/dev/null SAFESTOP=0 /etc/shorewall/conntrack [Errno 13] Permission denied: u'/etc/shorewall/conntrack' /etc/shorewall/params [Errno 13] Permission denied: u'/etc/shorewall/params' /etc/shorewall/shorewall.conf [Errno 13] Permission denied: u'/etc/shorewall/shorewall.conf' -- debconf information: shorewall/dont_restart: shorewall/major_release: shorewall/invalid_config: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776680: shorewall: invalid_config is not true
Package: shorewall Version: 4.6.4.3-1 Followup-For: Bug #776680 Despite the debconf setting of invalid_config the config is in fact correct as evidenced by the fact that the shorewall compile and shorewall safe-restart commands compile and restart the firewall with no complaints or issues. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages shorewall depends on: ii bc 1.06.95-9 ii debconf [debconf-2.0] 1.5.55 ii iproute1:3.16.0-2 ii iproute2 3.16.0-2 ii iptables 1.4.21-2+b1 ii perl-modules 5.20.1-4 ii shorewall-core 4.6.4.3-1 shorewall recommends no packages. Versions of packages shorewall suggests: ii make-guile [make] 4.0-8.1 pn shorewall-doc none -- Configuration Files: /etc/default/shorewall changed: startup=1 OPTIONS= STARTOPTIONS= INITLOG=/dev/null SAFESTOP=0 /etc/shorewall/conntrack [Errno 13] Permission denied: u'/etc/shorewall/conntrack' /etc/shorewall/params [Errno 13] Permission denied: u'/etc/shorewall/params' /etc/shorewall/shorewall.conf [Errno 13] Permission denied: u'/etc/shorewall/shorewall.conf' -- debconf information: shorewall/dont_restart: shorewall/major_release: shorewall/invalid_config: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776680: shorewall: dpkg-reconfigure shorewall gets the firewall to start
Package: shorewall Version: 4.6.4.3-1 Followup-For: Bug #776680 The issue appears to be with debconf settings as dpkg-reconfigure shorewall and then /etc/init.d/shorewall restart works even dpkg-reconfigure doesn't actually do any prompts. Perhaps it is because shorewall packaging labels the configuration as invalid when first installed because there is no valid config in the default state. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages shorewall depends on: ii bc 1.06.95-9 ii debconf [debconf-2.0] 1.5.55 ii iproute1:3.16.0-2 ii iproute2 3.16.0-2 ii iptables 1.4.21-2+b1 ii perl-modules 5.20.1-4 ii shorewall-core 4.6.4.3-1 shorewall recommends no packages. Versions of packages shorewall suggests: ii make-guile [make] 4.0-8.1 pn shorewall-doc none -- Configuration Files: /etc/default/shorewall changed: startup=1 OPTIONS= STARTOPTIONS= INITLOG=/dev/null SAFESTOP=0 /etc/shorewall/conntrack [Errno 13] Permission denied: u'/etc/shorewall/conntrack' /etc/shorewall/params [Errno 13] Permission denied: u'/etc/shorewall/params' /etc/shorewall/shorewall.conf [Errno 13] Permission denied: u'/etc/shorewall/shorewall.conf' -- debconf information: shorewall/dont_restart: shorewall/major_release: shorewall/invalid_config: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775802: cifs-utils: Unsigned NTLMv2 mounting fails
Package: cifs-utils Version: 2:5.5-1 Severity: minor Mounting NTLMv2 shares for which signing is not enabled (e.g. older (including Wheezy) Samba deployments, or older Windows, or Windows with signing turned off for other compatibility reasons) fails with 'Invalid Paramater'. This is only a minor bug despite the fact that it causes previous working setups to fail because SMB signing is the recommended best practise anyway and it would be better to enable it in the server anyway. on the command line: root@hostname:/home/user# mount -t cifs //winhost/share /home/winshare -ouser=winuser,sec=ntlmv2 Password: mount error(22): Invalid argument Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) in the syslog: Jan 20 02:34:37 aildeb kernel: [ 9439.232441] Status code returned 0xc00d NT_STATUS_INVALID_PARAMETER Jan 20 02:34:37 aildeb kernel: [ 9439.232446] CIFS VFS: Send error in SessSetup = -22 Jan 20 02:34:37 aildeb kernel: [ 9439.258135] CIFS VFS: cifs_mount failed w/return code = -22 Once I enabled signing and used ntlmsspi things worked fine. Note however that ntlmv2i still fails. This is for accessing a Windows 8.1 host. -- System Information: Debian Release: 7.8 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages cifs-utils depends on: ii libc6 2.13-38+deb7u6 ii libkeyutils1 1.5.5-3+deb7u1 ii libkrb5-3 1.10.1+dfsg-5+deb7u2 ii libtalloc22.0.7+git20120207-1 ii libwbclient0 2:3.6.6-6+deb7u4 ii samba-common 2:3.6.6-6+deb7u4 Versions of packages cifs-utils recommends: ii keyutils 1.5.5-3+deb7u1 ii winbind 2:3.6.6-6+deb7u4 Versions of packages cifs-utils suggests: ii smbclient 2:3.6.6-6+deb7u4 -- 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#775612: amanda-server: Intermittently occurring
Package: amanda-server Version: 1:3.3.6-4 Followup-For: Bug #775612 This bug is rather strange as I have rerun using the exact commandline and now the command succeeds with no error message. I have been getting these messages in some but not all of my emails from amanda. There is something distinctly strange going on. Regards, Daniel -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages amanda-server depends on: ii amanda-common 1:3.3.6-4 ii bsd-mailx [mailx] 8.1.2-0.20141216cvs-1 ii libc6 2.19-13 ii libcurl3 7.38.0-4 ii libglib2.0-0 2.42.1-1 ii libssl1.0.01.0.1j-1 ii mailutils [mailx] 1:2.99.98-2 amanda-server recommends no packages. Versions of packages amanda-server suggests: ii amanda-client 1:3.3.6-4 ii cpio 2.11+dfsg-4 pn gnuplotnone ii mt-st 1.1-6 ii perl [perl5] 5.20.1-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#775612: amanda-server: Depends on Tie/StdHash.pm which exists on NO package in debian
Package: amanda-server Version: 1:3.3.6-4 Severity: serious Justification: depends on software not in debian Seen when attemping to do amrmtape, but also occurs when doing a flush: an't locate Tie/StdHash.pm: Permission denied at /usr/share/perl/5.20/base.pm line 97. ...propagated at /usr/share/perl/5.20/base.pm line 106. BEGIN failed--compilation aborted at /usr/lib/amanda/perl/Amanda/Config/FoldingHash.pm line 3. Compilation failed in require at /usr/lib/amanda/perl/Amanda/Config.pm line 753. BEGIN failed--compilation aborted at /usr/lib/amanda/perl/Amanda/Config.pm line 753. Compilation failed in require at /usr/sbin/amrmtape line 27. BEGIN failed--compilation aborted at /usr/sbin/amrmtape line 27. StdHash.pm is not a file that exists in ANY package in debian according to apt-file. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages amanda-server depends on: ii amanda-common 1:3.3.6-4 ii bsd-mailx [mailx] 8.1.2-0.20141216cvs-1 ii libc6 2.19-13 ii libcurl3 7.38.0-4 ii libglib2.0-0 2.42.1-1 ii libssl1.0.01.0.1j-1 ii mailutils [mailx] 1:2.99.98-2 amanda-server recommends no packages. Versions of packages amanda-server suggests: ii amanda-client 1:3.3.6-4 ii cpio 2.11+dfsg-4 pn gnuplotnone ii mt-st 1.1-6 ii perl [perl5] 5.20.1-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#775543: virt-manager: GUI fails with X11 Forwarding on SSH
Package: virt-manager Version: 1:1.0.1-3 Severity: normal Attempting to run virt-manager on a remote machine through an SSH tunnel with X11 forwarding fails. With --debug output shows: [Fri, 16 Jan 2015 21:03:02 virt-manager 4327] DEBUG (console:1494) Starting connect process for proto=spice trans=None connh ost=127.0.0.1 connuser=None connport=None gaddr=127.0.0.1 gport=5900 gtlsport=None gsocket=None (virt-manager:4327): GSpice-CRITICAL **: spice_session_set_shared_dir: assertion 'dir != NULL' failed [xcb] Extra reply data still left in queue [xcb] This is most likely caused by a broken X extension library [xcb] Aborting, sorry about that. python2: ../../src/xcb_io.c:576: _XReply: Assertion `!xcb_xlib_extra_reply_data_left' failed. Regards, Daniel -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages virt-manager depends on: ii dconf-gsettings-backend [gsettings-backend] 0.22.0-1 ii gconf2 3.2.6-3 ii gir1.2-gtk-3.0 3.14.5-1 ii gir1.2-gtk-vnc-2.0 0.5.3-1.3 ii gir1.2-libvirt-glib-1.0 0.1.9-4 ii gir1.2-spice-client-gtk-3.0 0.25-1+b1 ii gir1.2-vte-2.90 1:0.36.3-1 ii librsvg2-common 2.40.5-1 ii python-dbus 1.2.0-2+b3 ii python-gi3.14.0-1 ii python-gi-cairo 3.14.0-1 ii python-ipaddr2.1.11-2 ii python-libvirt 1.2.9-1 ii python-urlgrabber3.9.1-4.1 pn python2.7:anynone pn python:any none ii virtinst 1:1.0.1-3 Versions of packages virt-manager recommends: ii gnome-icon-theme 3.12.0-1 ii libvirt-daemon 1.2.9-7 ii python-spice-client-gtk 0.25-1+b1 Versions of packages virt-manager suggests: pn gnome-keyringnone pn python-gnomekeyring none pn python-guestfs none pn ssh-askpass none ii virt-viewer 1.0-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775543: virt-manager: Failure is when attempting to connect to Spice display
Package: virt-manager Version: 1:1.0.1-3 Followup-For: Bug #775543 I forgot to mention: The error occurs when connecting to a Spice display, not the virt-manager GUI main window. That is when looking at video on a running virtual machine instance, but only when using Spice. VNC displays do not have this problem. Regards, Daniel -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages virt-manager depends on: ii dconf-gsettings-backend [gsettings-backend] 0.22.0-1 ii gconf2 3.2.6-3 ii gir1.2-gtk-3.0 3.14.5-1 ii gir1.2-gtk-vnc-2.0 0.5.3-1.3 ii gir1.2-libvirt-glib-1.0 0.1.9-4 ii gir1.2-spice-client-gtk-3.0 0.25-1+b1 ii gir1.2-vte-2.90 1:0.36.3-1 ii librsvg2-common 2.40.5-1 ii python-dbus 1.2.0-2+b3 ii python-gi3.14.0-1 ii python-gi-cairo 3.14.0-1 ii python-ipaddr2.1.11-2 ii python-libvirt 1.2.9-1 ii python-urlgrabber3.9.1-4.1 pn python2.7:anynone pn python:any none ii virtinst 1:1.0.1-3 Versions of packages virt-manager recommends: ii gnome-icon-theme 3.12.0-1 ii libvirt-daemon 1.2.9-7 ii python-spice-client-gtk 0.25-1+b1 Versions of packages virt-manager suggests: pn gnome-keyringnone pn python-gnomekeyring none pn python-guestfs none pn ssh-askpass none ii virt-viewer 1.0-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773743: xfce4-power-manager: Package list
Package: xfce4-power-manager Version: 1.4.1-1 Followup-For: Bug #773743 In case it helps, here is this list of installed packages. Like I said I don't know what other information I can give you because the only thing I did that is 'special' that triggered the bug was enable the suspend option in xfce4-power-manager. I have *not* touched policykit or d-bus. accountsservice 0.6.37-3+b1 acl 2.2.52-2 acpi 1.7-1 acpi-support-base 0.142-6 acpid 1:2.0.23-2 adduser 3.113+nmu3 adwaita-icon-theme 3.14.0-2 aglfn 1.7-3 alsa-base 1.0.27+1 alsa-utils 1.0.28-1 amanda-client 1:3.3.6-4 amanda-common 1:3.3.6-4 amd64-microcode 2.20141028.1 anacron 2.3-23 apache2 2.4.10-9 apache2-bin 2.4.10-9 apache2-data 2.4.10-9 apache2-utils 2.4.10-9 apel 10.8+0.20120427-13 apg 2.2.3.dfsg.1-2 apparmor 2.9.0-3 apparmor-docs 2.9.0-3 apparmor-profiles 2.9.0-3 apparmor-profiles-extra 1.4 apparmor-utils 2.9.0-3 apt 1.0.9.5 apt-listchanges 2.85.13+nmu1 apt-utils 1.0.9.5 apticron 1.1.57 aptitude 0.6.11-1+b1 aptitude-common 0.6.11-1 aptitude-doc-en 0.6.11-1 aspell 0.60.7~20110707-1.3 aspell-en 7.1-0-1.1 at 3.1.16-1 at-spi2-core 2.14.0-1 attr 1:2.4.47-2 auditd 1:2.4-1+b1 augeas-lenses 1.2.0-0.2 auto-complete-el 1.3.1-2 autopoint 0.19.3-2 avahi-autoipd 0.6.31-4+b2 avahi-daemon 0.6.31-4+b2 base-files 8 base-passwd 3.5.37 bash 4.3-11+b1 bash-completion 1:2.1-4 bc 1.06.95-9 bind9-host 1:9.9.5.dfsg-8 binfmt-support 2.1.5-1 binutils 2.24.90.20141023-1 binutils-multiarch 2.24.90.20141023-1 blueman 1.99~alpha1-1 bluetooth 5.23-2 bluez 5.23-2 bluez-cups 5.23-2 bluez-firmware 1.2-3 bluez-hcidump 5.23-2 bluez-obexd 5.23-2 bluez-tools 0.2.0~20140808-3 bootlogd 2.88dsf-58 bridge-utils 1.5-9 browser-plugin-lightspark 0.7.2-6 bsd-mailx 8.1.2-0.20141216cvs-1 bsdcpio 3.1.2-10 bsdmainutils 9.0.6 bsdtar 3.1.2-10 bsdutils 1:2.25.2-4 btrfs-tools 3.17-1.1 btscanner 2.1-5.1 build-essential 11.7 bundler 1.7.4-1 busybox 1:1.22.0-9+b1 byobu 5.87-1 bzip2 1.0.6-7+b2 ca-certificates 20141019 ca-certificates-java 20140324 cabextract 1.4-4+b1 calendar-google-provider 31.3.0-1 ccache 3.1.10-1 cgmanager 0.33-2 cheese-common 3.14.1-2 cifs-utils 2:6.4-1 cli-common 0.9 coinor-libcbc3 2.8.12-1 coinor-libcgl1 0.58.9-1 coinor-libclp1 1.15.10-1 coinor-libcoinmp1 1.7.6+dfsg1-1 coinor-libcoinutils3 2.9.15-3 coinor-libosi1 0.106.9-1 collectd 5.4.1-6 collectd-core 5.4.1-6 colord 1.2.1-1+b2 colord-data 1.2.1-1 conntrack 1:1.4.2-2 conntrackd 1:1.4.2-2 console-setup 1.116 console-setup-linux 1.116 consolekit 0.4.6-5 coreutils 8.23-3 cowbuilder 0.73 cowdancer 0.73 cpio 2.11+dfsg-4 cpp 4:4.9.1-5 cpp-4.9 4.9.1-19 cpufrequtils 008-1 cracklib-runtime 2.9.2-1 crda 3.13-1 cron 3.0pl1-127 cryptsetup 2:1.6.6-4 cryptsetup-bin 2:1.6.6-4 cscope 15.8a-2 cscope-el 15.8a-2 cups 1.7.5-10 cups-browsed 1.0.61-4 cups-bsd 1.7.5-10 cups-client 1.7.5-10 cups-common 1.7.5-10 cups-core-drivers 1.7.5-10 cups-daemon 1.7.5-10 cups-filters 1.0.61-4 cups-filters-core-drivers 1.0.61-4 cups-pk-helper 0.2.5-2+b1 cups-ppdc 1.7.5-10 cups-server-common 1.7.5-10 curl 7.38.0-3 cvs 2:1.12.13+real-15 cvsps 2.1-6 dash 0.5.7-4+b1 dbus 1.8.12-3 dbus-x11 1.8.12-3 dc 1.06.95-9 dconf-editor 0.22.0-1 dconf-gsettings-backend 0.22.0-1 dconf-service 0.22.0-1 dctrl-tools 2.23 debconf 1.5.55 debconf-i18n 1.5.55 debhelper 9.20141022 debian-archive-keyring 2014.3 debian-el 35.12 debian-faq 5.0.3 debian-keyring 2014.08.31 debianutils 4.4+b1 debootstrap 1.0.66 debsums 2.0.52+nmu2 default-jre 2:1.7-52 default-jre-headless 2:1.7-52 deluge-common 1.3.10-2 deluge-gtk 1.3.10-2 desktop-base 8.0.2 desktop-file-utils 0.22-1 devscripts 2.15.1 devscripts-el 35.12 dh-python 1.2014-2 dict 1.12.1+dfsg-3 dictionaries-common 1.23.17 dictionary-el 1.10-2 diffstat 1.58-1 diffutils 1:3.3-1+b1 discover 2.1.2-7 discover-data 2.2013.01.11 distro-info-data 0.23 dleyna-server 0.4.0-1 dlocate 1.02+nmu3 dmeventd 2:1.02.90-2 dmidecode 2.12-3 dmsetup 2:1.02.90-2 dns-root-data 2014060201+2 dnsmasq-base 2.72-2 dnsutils 1:9.9.5.dfsg-8 doc-base 0.10.6 doc-debian 6.2 docbook-xml 4.5-7.2 docbook-xsl 1.78.1+dfsg-1 docutils-common 0.12+dfsg-1 docutils-doc 0.12+dfsg-1 dosfstools 3.0.27-1 dpkg 1.17.23 dpkg-dev 1.17.23 dpkg-dev-el 35.12 dput 0.9.6.4 e2fslibs 1.42.12-1 e2fsprogs 1.42.12-1 easy-rsa 2.2.2-1 ebtables 2.0.10.4-3 ed 1.10-2 efibootmgr 0.11.0-3 eject 2.1.5+deb1+cvs20081104-13.1 elserv 0.4.0+0.20011203cvs-17.2 emacs 46.1 emacs-goodies-el 35.12 emacs24 24.4+1-4.1 emacs24-bin-common 24.4+1-4.1 emacs24-common 24.4+1-4.1 emacs24-common-non-dfsg 24.4+1-2 emacsen-common 2.0.8 enchant 1.6.0-10.1 equivs 2.0.9 espeak-data 1.48.04+dfsg-1 etckeeper 1.15 ethtool 1:3.16-1 evince-common 3.14.1-1 evince-gtk 3.14.1-1 exfalso 3.2.2-1 exim4 4.84-6 exim4-base 4.84-6 exim4-config 4.84-6 exim4-daemon-light 4.84-6 exo-utils 0.10.2-4 expand-region-el 0.10.0-3 extlinux 3:6.03+dfsg-4 fakeroot 1.20.2-1 file 1:5.20-2 findutils 4.4.2-9+b1 firebird2.5-common 2.5.3.26778.ds4-5 firebird2.5-common-doc 2.5.3.26778.ds4-5 firebird2.5-server-common 2.5.3.26778.ds4-5 firmware-linux 0.43
Bug#773743: xfce4-power-manager: What can I look for (didn't change anything from default)
Package: xfce4-power-manager Version: 1.4.1-1 Followup-For: Bug #773743 Hi, Where do I start looking? Also I haven't changed any d-bus or policykit settings and this occurs with both systemd and sysvinit. Please note that when I first reported I hadn't done anything special except install additional packages, so this issue occurs with the default install/configuration at least with the packages I have installed. I have now done something special which is (at least temporarily) switched to sysvinit because of issues with systemd, and the problem persists, but the bug is independent of init system type. Regards, Daniel -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages xfce4-power-manager depends on: ii libc6 2.19-13 ii libdbus-1-3 1.8.12-3 ii libdbus-glib-1-2 0.102-1 ii libgdk-pixbuf2.0-02.31.1-2+b1 ii libglib2.0-0 2.42.1-1 ii libgtk2.0-0 2.24.25-1 ii libnotify40.7.6-2 ii libupower-glib3 0.99.1-3.1 ii libx11-6 2:1.6.2-3 ii libxext6 2:1.3.3-1 ii libxfce4ui-1-04.10.0-6 ii libxfce4util6 4.10.1-2 ii libxfconf-0-2 4.10.0-3 ii libxrandr22:1.4.2-1+b1 ii upower0.99.1-3.1 ii xfce4-power-manager-data 1.4.1-1 Versions of packages xfce4-power-manager recommends: ii libpam-systemd 215-8 ii xfce4-power-manager-plugins 1.4.1-1 xfce4-power-manager 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#774902: systemd: On some systems fails to start old-style initscripts
Package: systemd Version: 215-8 Severity: important I've had to (at least temporarily) switch to sysvinit because systemd fails to start old-style initscripts on some of my systems. I don't have the time at present to debug mostly because with systemd I have no idea where to even start troubleshooting and I need my systems to work *now* not three weeks or three months from now. (These are systems I use for doing paid work, so there is not option to leave them in a broken state to debug). Regards, Daniel -- Package-specific info: -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages systemd depends on: ii acl 2.2.52-2 ii adduser 3.113+nmu3 ii initscripts 2.88dsf-58 ii libacl1 2.2.52-2 ii libaudit1 1:2.4-1+b1 ii libblkid1 2.25.2-4 ii libc6 2.19-13 ii libcap2 1:2.24-6 ii libcap2-bin 1:2.24-6 ii libcryptsetup4 2:1.6.6-4 ii libgcrypt20 1.6.2-4+b1 ii libkmod218-3 ii liblzma55.1.1alpha+20120614-2+b3 ii libpam0g1.1.8-3.1 ii libselinux1 2.3-2 ii libsystemd0 215-8 ii mount 2.25.2-4 ii sysv-rc 2.88dsf-58 ii udev215-8 ii util-linux 2.25.2-4 Versions of packages systemd recommends: ii dbus1.8.12-3 ii libpam-systemd 215-8 Versions of packages systemd suggests: pn systemd-ui none -- 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#774904: systemd: Some systems (upgrades?) fail to put journal into syslog
Package: systemd Version: 215-8 Severity: normal As I mentioned in my previous bug report I've (at least temporarily) had to switch my system back to sysvinit because of issues with initscripts failing to start on some systems, however I still feel I ought to report the bugs I've found. This second bug is that on system systems (upgrades) the journal fails to go to the syslog. This seemed to have been resolved on the system where I originally observed it (and the bug on the topic closed), however it turns out that after a reboot the problem came back. In particular deluged and cyrus-imapd had no logs even though the information was in journalctl. deluged actually logs to a non-syslog file but errors with starting deluge go to journal (because it's before deluge is actually started and the init system that is doing the logs). Regards, Daniel -- Package-specific info: -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages systemd depends on: ii acl 2.2.52-2 ii adduser 3.113+nmu3 ii initscripts 2.88dsf-58 ii libacl1 2.2.52-2 ii libaudit1 1:2.4-1+b1 ii libblkid1 2.25.2-4 ii libc6 2.19-13 ii libcap2 1:2.24-6 ii libcap2-bin 1:2.24-6 ii libcryptsetup4 2:1.6.6-4 ii libgcrypt20 1.6.2-4+b1 ii libkmod218-3 ii liblzma55.1.1alpha+20120614-2+b3 ii libpam0g1.1.8-3.1 ii libselinux1 2.3-2 ii libsystemd0 215-8 ii mount 2.25.2-4 ii sysv-rc 2.88dsf-58 ii udev215-8 ii util-linux 2.25.2-4 Versions of packages systemd recommends: ii dbus1.8.12-3 ii libpam-systemd 215-8 Versions of packages systemd suggests: pn systemd-ui none -- 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#774906: network-manager: With bridges sometimes fails to use MAC address from first slave which breaks DHCP and mac-address based ACLs
Source: network-manager Version: jessie Severity: normal When creating bridges it is not possible to specify the bridge MAC address and sometimes on boot (actually a reboot rather than fresh boot) network-manager assigns some random MAC adress to the bridge device instead of the MAC address of the first slave. This breaks DHCP static leases as well as MAC-based ACLs (e.g. on enterprise-grade switch you can limit what MAC address combined with VLAN ID are allow to come in on a certain port on the switch, but this breaks if the MAC address is not known because it is some randomly assign MAC address that is in the ethernet frame). Regards, Daniel -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774440: xfce4-panel: Problem has gone away
Package: xfce4-panel Followup-For: Bug #774440 For whatever reason the problem has gone away and icons now appear in the notification area the way they are supposed to. Regards, Daniel -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages xfce4-panel depends on: ii exo-utils 0.10.2-4 ii libatk1.0-0 2.14.0-1 ii libc6 2.19-13 ii libcairo2 1.14.0-2.1 ii libdbus-1-3 1.8.12-3 ii libdbus-glib-1-20.102-1 ii libexo-1-0 0.10.2-4 ii libfontconfig1 2.11.0-6.3 ii libfreetype62.5.2-2 ii libgarcon-1-0 0.2.1-2 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libglib2.0-02.42.1-1 ii libgtk2.0-0 2.24.25-1 ii libice6 2:1.0.9-1+b1 ii libpango1.0-0 1.36.8-3 ii libsm6 2:1.2.2-1+b1 ii libwnck22 2.30.7-2 ii libx11-62:1.6.2-3 ii libxext62:1.3.3-1 ii libxfce4ui-1-0 4.10.0-6 ii libxfce4util6 4.10.1-2 ii libxfconf-0-2 4.10.0-3 ii multiarch-support 2.19-13 xfce4-panel recommends no packages. xfce4-panel 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#774676: [Pkg-utopia-maintainers] Bug#774676: policykit-1: systemd-shim does not eliminate hard dependency on libpam-systemd - systemd
As much as anything it was misunderstanding that systemd-shim doesn't eliminate the installation of systemd on the system; it just allows you to not use systvinit as your init system. Regards, Daniel On 06/01/15 04:26 AM, Michael Biebl wrote: control: forcemerge 774664 -1 Am 06.01.2015 um 05:00 schrieb Daniel Dickinson: Package: policykit-1 Version: 0.105-8 Severity: normal policykit has a hard dependency on libpam-systemd which has a hard dependency on systemd AND the dependency is NOT eliminated through the use of systemd-shim. It is probably intended that systemd-shim OUGHT to eliminate the depency on systemd HOWEVER THIS IS NOT THE CASE. I believe there is a packaging error in which libpam-systemd has been incorrectly specified in such a way that the dependency is not resolved through the use of systemd-shim. policykit-1 requires the org.freedesktop.login1 interface and the proper registration of a logind session upon login. This is provided by libpam-systemd. Therefor this dependency is correct, You might not like that, but this is not a bug. smime.p7s Description: S/MIME Cryptographic Signature
Bug#774751: debootstrap: Allow to exclude even base and required dependencies (so can avoid systemd for LXC which doesn't work with systemd)
Package: debootstrap
Version: 1.0.66
Severity: normal
The attached version of deboostrap makes exclude also exclude dependencies when
doing dependency resolution. This is necessary in order to exclude systemd and
substitude sysvinit which is *required* for LXC because systemd is currently
broken
on LXC.
#!/bin/sh
set -e
VERSION='1.0.66'
unset TMP TEMP TMPDIR || true
# might not be exported if we're running from init=/bin/sh or similar
export PATH
###
if [ -z $DEBOOTSTRAP_DIR ]; then
if [ -x /debootstrap/debootstrap ]; then
DEBOOTSTRAP_DIR=/debootstrap
else
DEBOOTSTRAP_DIR=/usr/share/debootstrap
fi
fi
DEVICES_TARGZ=$DEBOOTSTRAP_DIR/devices.tar.gz
.. $DEBOOTSTRAP_DIR/functions
exec 41
LANG=C
USE_COMPONENTS=main
KEYRING=
DISABLE_KEYRING=
VARIANT=
ARCH=
HOST_ARCH=
HOST_OS=
KEEP_DEBOOTSTRAP_DIR=
USE_DEBIANINSTALLER_INTERACTION=
SECOND_STAGE_ONLY=
PRINT_DEBS=
CHROOTDIR=
MAKE_TARBALL=
KEEP_DEBOOTSTRAP_DIR=
EXTRACTOR_OVERRIDE=
UNPACK_TARBALL=
ADDITIONAL=
EXCLUDE=
VERBOSE=
CERTIFICATE=
CHECKCERTIF=
PRIVATEKEY=
DEF_MIRROR=http://ftp.us.debian.org/debian;
DEF_HTTPS_MIRROR=https://mirrors.kernel.org/debian;
export LANG USE_COMPONENTS
umask 022
###
## phases:
## finddebs dldebs printdebs first_stage second_stage
RESOLVE_DEPS=true
WHAT_TO_DO=finddebs dldebs first_stage second_stage
am_doing_phase () {
# usage: if am_doing_phase finddebs; then ...; fi
local x;
for x in $@; do
if echo $WHAT_TO_DO | grep -q $x ; then return 0; fi
done
return 1
}
###
usage_err()
{
info USAGE1 usage: [OPTION]... suite target [mirror [script]]
info USAGE2 Try \`${0##*/} --help' for more information.
error $@
}
usage()
{
echo Usage: ${0##*/} [OPTION]... suite target [mirror
[script]]
echo Bootstrap a Debian base system into a target directory.
echo
cat EOF
--help display this help and exit
--version display version information and exit
--verbose don't turn off the output of wget
--download-onlydownload packages, but don't perform installation
--print-debs print the packages to be installed, and exit
--arch=A set the architecture to install (use if no dpkg)
[ --arch=powerpc ]
--include=A,B,Cadds specified names to the list of base packages
--exclude=A,B,Cremoves specified packages from the list
--components=A,B,C use packages from the listed components of the
archive
--variant=Xuse variant X of the bootstrap scripts
(currently supported variants: buildd, fakechroot,
scratchbox, minbase)
--keyring=Kcheck Release files against keyring K
--no-check-gpg avoid checking Release file signatures
--no-resolve-deps don't try to resolve dependencies automatically
--unpack-tarball=T acquire .debs from a tarball instead of http
--make-tarball=T download .debs and create a tarball (tgz format)
--second-stage-target=DIR
Run second stage in a subdirectory instead of root
(can be used to create a foreign chroot)
(requires --second-stage)
--extractor=TYPE override automatic .deb extractor selection
(supported: $EXTRACTORS_SUPPORTED)
--debian-installer used for internal purposes by debian-installer
--private-key=file read the private key from file
--certificate=file use the client certificate stored in file (PEM)
--no-check-certificate do not check certificate against certificate
authorities
EOF
}
###
if [ -z $PKGDETAILS ]; then
error 1 NO_PKGDETAILS No pkgdetails available; either install perl, or
build pkgdetails.c from the base-installer source package
fi
###
if [ $# != 0 ] ; then
while true ; do
case $1 in
--help)
usage
exit 0
;;
--version)
echo debootstrap $VERSION
exit 0
;;
--debian-installer)
if ! (echo -n 3) 2/dev/null; then
error 1 ARG_DIBYHAND If running debootstrap by hand,
don't use --debian-installer
fi
USE_DEBIANINSTALLER_INTERACTION=yes
Bug#774752: debootstrap: When --no-resolve-deps and include/exclude is used get error get find debs: some number
Package: debootstrap Version: 1.0.66 Severity: normal When using --no-resolve-deps and include and exclude lists deboostrap errors out with the message that it can't finds deb X where looks like a package size. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages debootstrap depends on: ii wget 1.16-1 Versions of packages debootstrap recommends: ii debian-archive-keyring 2014.3 ii gnupg 1.4.18-6 debootstrap 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#774664: closed by Michael Biebl em...@michaelbiebl.de (Re: [Pkg-utopia-maintainers] Bug#774664: policykit-1: Forces use of systemd via dependency on libpam-systemd)
Sorry but systemd-shim does NOT eliminate the dependency on libpam-systemd. This bug should be reopened because the bad dependency is not eliminated by systemd-shim. It probably is intended to be and it's probably an unintended packing error that libpam-systemd is required even when systemd-shim is installed. Regards, Daniel On 05/01/15 04:33 PM, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the policykit-1 package: #774664: policykit-1: Forces use of systemd via dependency on libpam-systemd It has been closed by Michael Biebl em...@michaelbiebl.de. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Michael Biebl em...@michaelbiebl.de by replying to this email. smime.p7s Description: S/MIME Cryptographic Signature
Bug#774676: policykit-1: systemd-shim does not eliminate hard dependency on libpam-systemd - systemd
Package: policykit-1 Version: 0.105-8 Severity: normal policykit has a hard dependency on libpam-systemd which has a hard dependency on systemd AND the dependency is NOT eliminated through the use of systemd-shim. It is probably intended that systemd-shim OUGHT to eliminate the depency on systemd HOWEVER THIS IS NOT THE CASE. I believe there is a packaging error in which libpam-systemd has been incorrectly specified in such a way that the dependency is not resolved through the use of systemd-shim. Regards, Daniel -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages policykit-1 depends on: ii dbus 1.8.12-3 ii libc6 2.19-13 ii libglib2.0-0 2.42.1-1 ii libpam-systemd 215-8 ii libpam0g 1.1.8-3.1 ii libpolkit-agent-1-00.105-8 ii libpolkit-backend-1-0 0.105-8 ii libpolkit-gobject-1-0 0.105-8 policykit-1 recommends no packages. policykit-1 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#774664: closed by Michael Biebl em...@michaelbiebl.de (Re: [Pkg-utopia-maintainers] Bug#774664: policykit-1: Forces use of systemd via dependency on libpam-systemd)
I think misunderstood you comment to mean you were claiming that with systemd-shim that systemd doesn't have to be installed. Are what you actually saying is that you can't avoid having systemd on the system, but you can use systemd-shim to allow you so can use sysvinit through appropriate grub config, but systemd will still be present on the system, but unused? Regards, Daniel On 05/01/15 04:33 PM, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the policykit-1 package: #774664: policykit-1: Forces use of systemd via dependency on libpam-systemd It has been closed by Michael Biebl em...@michaelbiebl.de. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Michael Biebl em...@michaelbiebl.de by replying to this email. smime.p7s Description: S/MIME Cryptographic Signature
Bug#774664: policykit-1: Forces use of systemd via dependency on libpam-systemd
Package: policykit-1 Version: 0.105-8 Severity: normal Lots of stuff depend on policykit and supposedly one is allowed to create systemd if one wants, however currently policykit depends on libpam-systemd which makes it impossible to have a meaningful desktop without system. libpam-systemd should not be a hard requirement or there should be shim like systemd-shim (which was created to avoid this type of scenario) which allows installing policykit without installing systemd. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages policykit-1 depends on: ii dbus 1.8.12-3 ii libc6 2.19-13 ii libglib2.0-0 2.42.1-1 ii libpam-systemd 215-8 ii libpam0g 1.1.8-3.1 ii libpolkit-agent-1-00.105-8 ii libpolkit-backend-1-0 0.105-8 ii libpolkit-gobject-1-0 0.105-8 policykit-1 recommends no packages. policykit-1 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#738286: use getty instead of login
On 10/12/14 04:21 AM, Daniel Baumann wrote: another ping on this.. what's the status? can you at least post your patch? Regards, Daniel Hi, Sorry I was working on this, but then finally got fed up with with the systemd/gnome pushers (which have already caused me hours of grief with stuff that has gotten broken by the whole fiasco) and the whole Poettering/Gnome political bullying dressed up as technical/business arguments that has push at least two other bad/half-assed solutions that I know about (pulseaudio was years of brokness, network manager is only now getting bridge support and it still has issues which occasionally results in the need for multiple boots get a working network). I briefly gave up on the linux desktop and moved my Windows Vms to main OS, but I have too many years invested in Linux/Debian to give up that easily. I am considering shifting to Plan9 though as philosophy seems to be more about best-of-breed rather than first/most popular solution out the door, which is what Poettering solutions are about (they get popular because they are first and have the most weight behind them, not because they are good (in fact I would argue they are first because they don't take time to do things right). Anyway enough of my rant, point is I was temporarily out of the picture as far as working in this goes. I'm not sure where my patch is at the moment. It is easily recreate, I just have to get things into a state where I can do it. Regards, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774483: byobu: Only occurs if TERM=screen
Package: byobu Version: 5.87-1 Followup-For: Bug #774483 The bug only occurs of TERM=screen before launching byobu (e.g. SSH to remote system from a system running byobu in the local terminal). If you do something like test if the connection is SSH and if set TERM=xterm if TERM=screen before the byobu-launch line in the profile, the problem goes away. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages byobu depends on: ii debconf [debconf-2.0] 1.5.55 ii gawk 1:4.1.1+dfsg-1 ii gettext-base 0.19.3-2 ii python 2.7.8-2 ii python-newt0.52.17-1+b1 ii screen 4.2.1-3 ii tmux 1.9-6 Versions of packages byobu recommends: pn run-one none ii screen 4.2.1-3 ii tmux 1.9-6 Versions of packages byobu suggests: pn apport none pn cczenone ii lsb-release 4.1+Debian13+nmu1 ii po-debconf 1.0.16+nmu3 pn ttf-ubuntu-font-family none pn update-notifier-common none ii vim 2:7.4.488-3 ii vim-nox [vim] 2:7.4.488-3 ii w3m 0.5.3-19 pn wireless-tools none -- debconf information: byobu/launch-by-default: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774483: byobu: can't disable date and time with tmux
Package: byobu Version: 5.87-1 Severity: normal It is currently impossible by any means (including hand editing .byobu/status and killing ..byobu directory logging out, and staring over) to disable the date and time displays in the tmux status bar. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages byobu depends on: ii debconf [debconf-2.0] 1.5.55 ii gawk 1:4.1.1+dfsg-1 ii gettext-base 0.19.3-2 ii python 2.7.8-2 ii python-newt0.52.17-1+b1 ii screen 4.2.1-3 ii tmux 1.9-6 Versions of packages byobu recommends: pn run-one none ii screen 4.2.1-3 ii tmux 1.9-6 Versions of packages byobu suggests: pn apport none pn cczenone ii lsb-release 4.1+Debian13+nmu1 ii po-debconf 1.0.16+nmu3 pn ttf-ubuntu-font-family none pn update-notifier-common none ii vim 2:7.4.488-3 ii vim-nox [vim] 2:7.4.488-3 ii w3m 0.5.3-19 pn wireless-tools none -- debconf information: byobu/launch-by-default: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774440: xfce4-panel: Multiple app icons do not display in system tray
Package: xfce4-panel Version: 4.10.1-1 Severity: normal It looks like some API or something has changed and failed to maintain backwards compability because a number of applications fail to show up on the system tray applet which ought to have icons there including hipchat (non-debian) and virt-manager (current jessie) and more. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xfce4-panel depends on: ii exo-utils 0.10.2-4 ii libatk1.0-0 2.14.0-1 ii libc6 2.19-13 ii libcairo2 1.14.0-2.1 ii libdbus-1-3 1.8.12-3 ii libdbus-glib-1-20.102-1 ii libexo-1-0 0.10.2-4 ii libfontconfig1 2.11.0-6.3 ii libfreetype62.5.2-2 ii libgarcon-1-0 0.2.1-2 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libglib2.0-02.42.1-1 ii libgtk2.0-0 2.24.25-1 ii libice6 2:1.0.9-1+b1 ii libpango1.0-0 1.36.8-3 ii libsm6 2:1.2.2-1+b1 ii libwnck22 2.30.7-2 ii libx11-62:1.6.2-3 ii libxext62:1.3.3-1 ii libxfce4ui-1-0 4.10.0-6 ii libxfce4util6 4.10.1-2 ii libxfconf-0-2 4.10.0-3 ii multiarch-support 2.19-13 xfce4-panel recommends no packages. xfce4-panel 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#774329: [Pkg-libvirt-maintainers] Bug#774329: libvirt-bin: Doesn't gracefully shutdown guests on upgrade restart
On 01/01/15 05:11 AM, Guido Günther wrote: On Wed, Dec 31, 2014 at 05:27:03PM -0500, Daniel Dickinson wrote: Package: libvirt-bin Version: 1.2.9-7 Severity: grave Justification: causes non-serious data loss If libvirt-bin has an upgrade requiring a restart it restarts and kills currently active guests without first gracefully shutting them down. This can result in data loss due to damaged filesystems (hence the grave report). This also happens with no warning so there is no opportunity to manually shutdown the clients. Libvirt keeps qemu guests running and reattaches to them. Please provide steps to reproduce. -- Guido Perhaps it's a systemd issue because after qemu-kvm session was killed systemd still had a unit hanging about for it that prevented me from restarting the vm until I rebooted the host. I did verify that no qemu/kvm was running after. Aside from that I have no 'special' steps to reproduce other than that I had libvirt-bin and a guest running, did an upgrade and discovered by guest was gone and I couldn't restart it. Regards, Daniel smime.p7s Description: S/MIME Cryptographic Signature
Bug#774329: libvirt-bin: Doesn't gracefully shutdown guests on upgrade restart
Package: libvirt-bin Version: 1.2.9-7 Severity: grave Justification: causes non-serious data loss If libvirt-bin has an upgrade requiring a restart it restarts and kills currently active guests without first gracefully shutting them down. This can result in data loss due to damaged filesystems (hence the grave report). This also happens with no warning so there is no opportunity to manually shutdown the clients. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libvirt-bin depends on: ii libvirt-clients1.2.9-7 ii libvirt-daemon-system 1.2.9-7 libvirt-bin recommends no packages. libvirt-bin suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774128: Bug#773937: cyrus-caldav: [PATCH] Fix Icedove+Lightening PROPFIND for DAV
On 30/12/14 03:16 PM, Ondřej Surý wrote: Hi Daniel, thanks for the time you have spent on this and for the patches. Could you please send those patches as diffs (or git diffs preferrably), it's better to have them unmangled by MUAs. Do you mean .diff attachments? Or do you mean package diffs (i.e. diffs against the whole package and not just individual patch file as found debian/patches)? BTW these patches (which are just what quilt produces and are in fact diffs) should not be mangled as send via vi and reportbug. There are serious issues if either those is mangling emails. Also please report those bugs you have reported here to the upstream: http://cyrusimap.org/mediawiki/index.php/Report_A_Bug I've reported the bugs upsteam, will add the upstream tags to the bugs when I get a chance. Regards, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774128: cyrus-caldav: [PATCH] dav: Fails with virtual domain for non-default domain users
Package: cyrus-caldav
Version: 2.4.17+caldav~beta10-13~dfd2
Severity: normal
Tags: patch
When cyrus is configured with virtual domains and you attempt to create/use
calendars
for users on domains other than the default domain, one gets a mailbox not
found error
due to the way the dav code constructs mailbox names for the calendars and
addressbooks.
The following patch fixes three such issues and gets virtual domains working
for me.
Description: Fix CalDAV/CardDAV with Virtual Domains
Fix CalDAV/CardDAV when user is in a virtual domain so that the virtual
domain gets used in the mailbox name. This fixes CalDAV failing
to create/open mailbox for calendars when user is not in default
or only domain.
There were three issues. The first was that if you specify a domain
in the calendar URI it is converted as if it it were a mailbox name
instead of cyrus domain part (e.g. with '.' separator '.' in domain
is converted to '^') of mailbox name.
This second was that in calendar lookups for scheduling the userid
part of the mailbox name got the domain part truncated due to
'@' being replaced by NUL (string terminator) in calendar lookup
function (caladdress_lookup).
The third was that in some cases mailboxname creation functions
didn't even consider the domain part of the userid and therefore
didn't handle domain mailbox name construction correctly
.
Author: Daniel Dickinson deb...@daniel.thecshore.com
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Origin: vendor|upstream|other, url of original patch
Bug: url in upstream bugtracker
Bug-Debian: https://bugs.debian.org/bugnumber
Bug-Ubuntu: https://launchpad.net/bugs/bugnumber
Forwarded: no|not-needed|url proving that it has been forwarded
Reviewed-By: name and email of someone who approved the patch
Last-Update: -MM-DD
Index: cyrus-imapd-2.4-2.4.17+caldav~beta10.new/imap/http_caldav.c
===
--- cyrus-imapd-2.4-2.4.17+caldav~beta10.new.orig/imap/http_caldav.c
+++ cyrus-imapd-2.4-2.4.17+caldav~beta10.new/imap/http_caldav.c
@@ -632,7 +632,7 @@ static void my_caldav_auth(const char *u
/* Auto-provision calendars for 'userid' */
strlcpy(ident, userid, sizeof(ident));
-mboxname_hiersep_toexternal(httpd_namespace, ident, 0);
+//mboxname_hiersep_toexternal(httpd_namespace, ident, 0);
/* calendar-home-set */
r = mboxlist_lookup(mailboxname, mbentry, NULL);
@@ -761,6 +761,10 @@ static int caldav_parse_path(const char
char *p;
size_t len, siz;
static const char *prefix = NULL;
+char userid[MAX_MAILBOX_BUFFER];
+char userdomain[MAX_MAILBOX_BUFFER];
+char *domain_start;
+int userlen, domainlen;
/* Make a working copy of target path */
strlcpy(tgt-path, path, sizeof(tgt-path));
@@ -857,13 +861,19 @@ static int caldav_parse_path(const char
p = tgt-mboxname;
siz = MAX_MAILBOX_BUFFER;
if (tgt-user) {
- len = snprintf(p, siz, user);
- p += len;
- siz -= len;
-
if (tgt-userlen) {
- len = snprintf(p, siz, .%.*s, (int) tgt-userlen, tgt-user);
- mboxname_hiersep_tointernal(httpd_namespace, p+1, tgt-userlen);
+ domain_start = strchr(tgt-user, '@');
+ if (domain_start != NULL) {
+ userlen = domain_start - tgt-user + 1;
+ domain_start++;
+ domainlen = tgt-userlen - userlen + 1;
+ strlcpy(userid, tgt-user, userlen);
+ strlcpy(userdomain, domain_start, domainlen);
+ len = snprintf(p, siz, %.*s!user.%.*s, (int) domainlen,
userdomain, (int) userlen, userid);
+} else {
+ len = snprintf(p, siz, user.%.*s, (int) tgt-userlen,
tgt-user);
+}
+ // mboxname_hiersep_tointernal(httpd_namespace, p+1, tgt-userlen);
p += len;
siz -= len;
}
@@ -1918,7 +1928,7 @@ static int caldav_post(struct transactio
if (!caladdress_lookup(organizer, sparam)
!(sparam.flags SCHEDTYPE_REMOTE)) {
strlcpy(orgid, sparam.userid, sizeof(orgid));
- mboxname_hiersep_toexternal(httpd_namespace, orgid, 0);
+ //mboxname_hiersep_toexternal(httpd_namespace, orgid, 0);
}
}
@@ -2134,7 +2144,7 @@ static int caldav_put(struct transaction
char ext_userid[MAX_MAILBOX_NAME+1];
strlcpy(ext_userid, userid, sizeof(ext_userid));
- mboxname_hiersep_toexternal(httpd_namespace, ext_userid, 0);
+ //mboxname_hiersep_toexternal(httpd_namespace, ext_userid, 0);
txn-error.precond = CALDAV_UNIQUE_OBJECT;
assert(!buf_len(txn-buf));
@@ -3909,7 +3919,7 @@ static int store_resource(struct transac
strcmp(cdata
Bug#774130: cyrus-caldav: [PATCH] dav: Fails when multiple accounts accessing private calendars from same client
Package: cyrus-caldav
Version: 2.4.17+caldav~beta10-13~dfd2
Severity: normal
Tags: patch
Due to strict interpretation/implementation of HTTP Auth RFC having private
calendars
from multiple accounts accessed by the same instance of a client (e.g. Icedove)
fails
with 403 Forbidden for any accounts accessed after the first.
This issue is why Mozilla added the about:config option
calendars.network.multirealm
option (which apparently is also apparently iCal's default behavior).
In short it is required to have HTTP Auth occur for different URI's not just
different
server names because calendars are not differentied by server name but instead
by
URI.
This attached patch is a hack that that re-requests HTTP Auth if the current
http userid
does not match the userid in the calender URI and HTTP header does not have a an
Authorization field.
Description: Fix CalDAV/CardDAV for multiple user's calendars from same client
Workaround for accessing different users' collections on the same server
with same hostname. Without this fix, this fails because HTTP auth is
only done once. This is the same issue that had Mozilla Lightning add
the calendar.network.multream option.
Basically interpretation of RFC's such that HTTP Auth is only done once
hostname:port reqardless of the URI causes CalDAV/CardDAV to fail when
one does not have a unique hostname:port per user and access to multiple
users' calendars is done from the same client, unless one opens up the
ACLS so that the calendars are all accessible from a single user (in
addition to the owner of the calendar)
This workaround forces an authentication request if the userid does not
match the user portion of the calendar/addressbook URI. It does require
that the client know enough to not use the same authorization for the
different calenders (e.g. Mozilla Lightning with multirealm enabled
or, apparently, iCal)
Index: cyrus-imapd-2.4-2.4.17+caldav~beta10.new/imap/httpd.c
===
--- cyrus-imapd-2.4-2.4.17+caldav~beta10.new.orig/imap/httpd.c
+++ cyrus-imapd-2.4-2.4.17+caldav~beta10.new/imap/httpd.c
@@ -919,6 +919,9 @@ static void cmdloop(void)
const struct namespace_t *namespace;
const struct method_t *meth_t;
struct request_line_t *req_line = txn.req_line;
+char collection_userid[MAX_MAILBOX_BUFFER];
+char *user_loc;
+ int has_authorization = 0;
/* Reset txn state */
txn.meth = METH_UNKNOWN;
@@ -1200,6 +1203,7 @@ static void cmdloop(void)
/* Perform authentication, if necessary */
if ((hdr = spool_getheader(txn.req_hdrs, Authorization))) {
+ has_authorization = 1;
if (httpd_userid) {
/* Reauth - reinitialize */
syslog(LOG_DEBUG, reauth - reinit);
@@ -1244,6 +1248,33 @@ static void cmdloop(void)
}
}
+ /* Workaround for accessing different users' collections on the same
server
+ with same hostname. Without this fix, this fails because HTTP auth
is
+ only done once. This is the same issue that had Mozilla Lightning
add
+ the calendar.network.multream option.
+ Basically interpretation of RFC's such that HTTP Auth is only done
once
+ hostname:port reqardless of the URI causes CalDAV/CardDAV to fail
when
+ one does not have a unique hostname:port per user and access to
multiple
+ users' calendars is done from the same client, unless one opens up
the
+ ACLS so that the calendars are all accessible from a single user (in
+ addition to the owner of the calendar)
+ This workaround forces an authentication request if the userid does
not
+ match the user portion of the calendar/addressbook URI. It does
require
+ that the client know enough to not use the same authorization for
the
+ different calenders (e.g. Mozilla Lightning with multirealm enabled
+ or, apparently, iCal)
+*/
+ if (!has_authorization httpd_userid) {
+ user_loc = strstr(txn.req_uri-path, /user/);
+ if (user_loc != NULL) {
+ user_loc += 6;
+ strlcpy(collection_userid, user_loc, strcspn(user_loc, /));
+ if (strcmp(collection_userid, httpd_userid)) {
+ *httpd_userid = 0;
+ }
+ }
+ }
+
/* Request authentication, if necessary */
switch (txn.meth) {
case METH_GET:
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/5 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages cyrus-caldav depends on:
ii
Bug#773766: systemd: Real problem is lack of information when service fails
On 26/12/14 08:48 PM, Michael Biebl wrote: Am 26.12.2014 um 06:11 schrieb Daniel Dickinson: On 25/12/14 01:27 PM, Michael Biebl wrote: Messages appeared in journal (journalctl) however there was no output in syslog. I have noticed that *none* of the boxes / vms I have upgraded from wheezy to jessie output the journal to syslog. I suppose this may be a systemd upgrade bug. Which syslogger do you have installed, rsyslog, syslog-ng? rsyslog with config that had been edited but reverted to defaults (however probably detected as changed and therefore new defaults not installed). What is the output of systemctl status syslog.socket syslog.service Er, sorry, no longer have the non-working configs. Reverted rsyslog configs completely to defaults using dpkg -i --force-confnew and it all works now. Regards, Daniel smime.p7s Description: S/MIME Cryptographic Signature
Bug#773766: systemd: Real problem is lack of information when service fails
On 23/12/14 04:40 PM, Michael Biebl wrote: Am 23.12.2014 um 02:49 schrieb Daniel Dickinson: Package: systemd Followup-For: Bug #773766 It turns there was a permissions problem on the log file directory for deluged causing deluged failing to start, however there was a lack of information about the failure in the canonical place to look for for such information (syslog). It's great and all to have the systemctl status command, once you finally find out about it, but such information should also be in the logs. Does deluged log the error to syslog directly or to stdout/stderr? To a file in /var/log/deluged/deluged.log This file was empty (deluged was never starting and before the config is active it logs to stdout/err I believe, which is why the output is only in journalctl) In both cases the error should end up in the journal, and can be queueried via systemctl status deluged.service and journalctl (in the latter case, you can use the builtin filter mechanisms like -u deluged.service or the path to the deluged binary). If a syslogger like syslog-ng or rsyslog is installed, the journal messages should also end up in the syslog (depending on the configuration, you should check files like /var/log/daemon.log,syslog,messages). Are you saying, that no log messages appeared in the journal and/or syslog? Messages appeared in journal (journalctl) however there was no output in syslog. I have noticed that *none* of the boxes / vms I have upgraded from wheezy to jessie output the journal to syslog. I suppose this may be a systemd upgrade bug. Regards, Daniel smime.p7s Description: S/MIME Cryptographic Signature
Bug#773937: cyrus-caldav: PROPFIND 405 Method Not Allowed according to upstream configure is not finding necessary prequisites
Package: cyrus-caldav Version: 2.4.17+caldav~beta10-12 Severity: important Currently cyrus-caldav is unusable as CalDAV/CardDAV support fails with PROPFIND 405 Method Not Allowed in the server logs. According to http://permalink.gmane.org/gmane.mail.imap.cyrus/37870 this is most likely caused by configure failing to find the necessary prerequisites (e.g. libical-dev and libsqlite3-dev) in order for the caldav support to actually be compile into cyrus. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/5 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cyrus-caldav depends on: ii cyrus-common 2.4.17+caldav~beta10-12 ii dpkg 1.17.22 ii libc6 2.19-13 ii libcomerr21.42.12-1 ii libdb5.3 5.3.28-7~deb8u1 ii libical1 1.0-1.1 ii libkrb5-3 1.12.1+dfsg-16 ii libsasl2-22.1.26.dfsg1-12 ii libsqlite3-0 3.8.7.1-1 ii libssl1.0.0 1.0.1j-1 ii libwrap0 7.6.q-25 ii libxml2 2.9.1+dfsg1-4 ii zlib1g1:1.2.8.dfsg-2+b1 cyrus-caldav recommends no packages. cyrus-caldav 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#773766: systemd: Real problem is lack of information when service fails
On 25/12/14 01:27 PM, Michael Biebl wrote: Messages appeared in journal (journalctl) however there was no output in syslog. I have noticed that *none* of the boxes / vms I have upgraded from wheezy to jessie output the journal to syslog. I suppose this may be a systemd upgrade bug. Which syslogger do you have installed, rsyslog, syslog-ng? rsyslog with config that had been edited but reverted to defaults (however probably detected as changed and therefore new defaults not installed). This is likely true for all hosts which I've upgraded so far. Regards, Daniel smime.p7s Description: S/MIME Cryptographic Signature
Bug#773946: /usr/sbin/amstatus: Log spam about uninitialized values (unsure of impact)
Package: amanda-server Version: 1:3.3.6-4 Severity: normal File: /usr/sbin/amstatus amstatus is reporting all kinds of unitialized value errors, which since I have cron job that runs amstatus regularly to determine if a wake on lan is needed on clients that might be being backed up, I get tons of log spam (since every run of amstatus results in errors such as the ones below). I'm not sure yet of the actual impace of these errors. ** (process:16121): WARNING **: Use of uninitialized value in numeric ne (!=) at /usr/sbin/amstatus line 407, AMDUMP line 2452. ** (process:16121): WARNING **: Use of uninitialized value in numeric eq (==) at /usr/sbin/amstatus line 407, AMDUMP line 2452. ** (process:16121): WARNING **: Use of uninitialized value in numeric ne (!=) at /usr/sbin/amstatus line 407, AMDUMP line 2461. ** (process:16121): WARNING **: Use of uninitialized value in numeric eq (==) at /usr/sbin/amstatus line 407, AMDUMP line 2461. ** (process:16121): WARNING **: Use of uninitialized value in numeric ne (!=) at /usr/sbin/amstatus line 407, AMDUMP line 2470. ** (process:16121): WARNING **: Use of uninitialized value in numeric eq (==) at /usr/sbin/amstatus line 407, AMDUMP line 2470. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages amanda-server depends on: ii amanda-common 1:3.3.6-4 ii bsd-mailx [mailx] 8.1.2-0.20141216cvs-1 ii libc6 2.19-13 ii libcurl3 7.38.0-3 ii libglib2.0-0 2.42.1-1 ii libssl1.0.01.0.1j-1 ii mailutils [mailx] 1:2.99.98-2 amanda-server recommends no packages. Versions of packages amanda-server suggests: ii amanda-client 1:3.3.6-4 ii cpio 2.11+dfsg-2+b1 pn gnuplotnone ii mt-st 1.1-6 ii perl [perl5] 5.20.1-3 -- 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#773947: source:cyrus-imapd: debian/rules clean fails then dpkg-buildpackage fails due to unreverted changes to source files
Package: source Version: 2.4.17+caldav~beta10-12 Severity: important The package build system incorrectly modifies source files and fails to revert them on clean, resulting in a situation where dpkg-buildpackage followed by make -f debian/rules clean followed by dpkg-buildpackage fails. This is probably actually RC since IIRC it's a probably a failure of a MUST directive of Debian Policy for packaging but I'm disinclined to look it up so just marking it as important. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/5 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773937: cyrus-caldav: [PATCH] Fix Icedove+Lightening PROPFIND for DAV
Package: cyrus-caldav
Followup-For: Bug #773937
The actual bug is an upstream bug. It turns out that cyrus' DAV implementation
only allows PROPFIND on / or /dav/ however Icedove+Lightening doesn't do the
discovery mechanism at the top level and instead requires a full path to the
calendar to be accessed, but still issues a PROPFIND on the URI.
Since cyrus only allows PROPFIND on / or /dav/ Icedove+Lightening will
always fail.
The attached patch (first again debian source tree, the second is only the
actual patch which goes in debian/patches) fixes this by allowing
PROPFIND on any URI beginning with /dav/ not only /dav/ itself.
diff -Naur cyrus-imapd-2.4-2.4.17+caldav~beta10.old/debian/changelog
cyrus-imapd-2.4-2.4.17+caldav~beta10.new/debian/changelog
--- cyrus-imapd-2.4-2.4.17+caldav~beta10.old/debian/changelog 2014-12-25
22:48:18.65600 -0500
+++ cyrus-imapd-2.4-2.4.17+caldav~beta10.new/debian/changelog 2014-12-26
00:39:18.45200 -0500
@@ -1,3 +1,14 @@
+cyrus-imapd-2.4 (2.4.17+caldav~beta10-13~dfd1) unstable; urgency=low
+
+ * Fix DAV PROPFIND for Icedove/Thunderbird Lightening plugin
+which applies PROPFIND at the calendar level instead of at
+the top-level /dav/ URI (i.e. Lightening requires a full
+path AND issues PROPFIND on the full path rather than as a
+discovery mechanism at the top level. Cyrus currently only
+allows PROPFIND in / or /dav
+
+ -- Daniel Dickinson deb...@daniel.thecshore.com Thu, 25 Dec 2014 22:41:11
-0500
+
cyrus-imapd-2.4 (2.4.17+caldav~beta10-12) unstable; urgency=medium
* Add Breaks/Replaces for old cyrus-imapd-2.2 dummy packages
diff -Naur
cyrus-imapd-2.4-2.4.17+caldav~beta10.old/debian/patches/fix-icedove-thunderbird-lightening-propfind.patch
cyrus-imapd-2.4-2.4.17+caldav~beta10.new/debian/patches/fix-icedove-thunderbird-lightening-propfind.patch
---
cyrus-imapd-2.4-2.4.17+caldav~beta10.old/debian/patches/fix-icedove-thunderbird-lightening-propfind.patch
1969-12-31 19:00:00.0 -0500
+++
cyrus-imapd-2.4-2.4.17+caldav~beta10.new/debian/patches/fix-icedove-thunderbird-lightening-propfind.patch
2014-12-25 22:59:18.33600 -0500
@@ -0,0 +1,46 @@
+Description: Fix DAV PROPFIND for Icedove/Thunderbird Lightening
+ Fix DAV PROPFIND for Icedove/Thunderbird Lightening plugin
+ which applies PROPFIND at the calendar level instead of at
+ the top-level /dav/ URI (i.e. Lightening requires a full
+ path AND issues PROPFIND on the full path rather than as a
+ discovery mechanism at the top level. Cyrus currently only
+ allows PROPFIND in / or /dav
+ .
+ cyrus-imapd-2.4 (2.4.17+caldav~beta10-12~dfd1) unstable; urgency=low
+ .
+ * Fix DAV PROPFIND for Icedove/Thunderbird Lightening plugin
+ which applies PROPFIND at the calendar level instead of at
+ the top-level /dav/ URI (i.e. Lightening requires a full
+ path AND issues PROPFIND on the full path rather than as a
+ discovery mechanism at the top level. Cyrus currently only
+ allows PROPFIND in / or /dav
+Author: Daniel Dickinson deb...@daniel.thecshore.com
+
+---
+The information above should follow the Patch Tagging Guidelines, please
+checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
+are templates for supplementary fields that you might want to add:
+
+Origin: other
+Bug: url in upstream bugtracker
+Bug-Debian: https://bugs.debian.org/bugnumber
+Bug-Ubuntu: https://launchpad.net/bugs/bugnumber
+Forwarded: no|not-needed|url proving that it has been forwarded
+Reviewed-By: name and email of someone who approved the patch
+Last-Update: -MM-DD
+
+--- cyrus-imapd-2.4-2.4.17+caldav~beta10.orig/imap/httpd.c
cyrus-imapd-2.4-2.4.17+caldav~beta10/imap/httpd.c
+@@ -3690,8 +3690,11 @@ static int meth_propfind_root(struct tra
+
+ #ifdef WITH_DAV
+ /* Apple iCal and Evolution both check / */
++/* Thunderbird checks full path under /dav/... so limit
++ URI check to /dav/ portion of URI (if present)
++ */
+ if (!strcmp(txn-req_uri-path, /) ||
+- !strcmp(txn-req_uri-path, /dav/)) {
++ !strncmp(txn-req_uri-path, /dav/, 5)) {
+ /* Array of known live properties */
+ const struct prop_entry root_props[] = {
+
diff -Naur cyrus-imapd-2.4-2.4.17+caldav~beta10.old/debian/patches/series
cyrus-imapd-2.4-2.4.17+caldav~beta10.new/debian/patches/series
--- cyrus-imapd-2.4-2.4.17+caldav~beta10.old/debian/patches/series
2014-12-25 22:48:18.66000 -0500
+++ cyrus-imapd-2.4-2.4.17+caldav~beta10.new/debian/patches/series
2014-12-25 22:59:44.97200 -0500
@@ -34,3 +34,4 @@
parse-GUID-for-binary-appends-as-well.patch
use-system-unicodedata.patch
TLS-configuration.patch
+fix-icedove-thunderbird-lightening-propfind.patch
diff -Naur cyrus-imapd-2.4-2.4.17+caldav~beta10.old/imap/httpd.c
cyrus-imapd-2.4-2.4.17+caldav~beta10.new/imap/httpd.c
--- cyrus-imapd-2.4-2.4.17+caldav~beta10.old/imap/httpd.c 2014-12-25
22:48:18.68400 -0500
+++ cyrus-imapd-2.4-2.4.17
Bug#758870: linux: /sbin/request-key not called
Source: linux Version: 3.16.0-4 Followup-For: Bug #758870 I have investigated further and determined that /sbin/request-key never gets called (I intercepted calls to /sbin/request-key which a program which first logs and it didn't even get triggered once despite using NFSv4, in this with sec=sys). As you might guess, in my case ls -al of the offending nfs dirs fails to translate the uid/gid into local username and group and instead, for e.g. remote id #1000 uses local uid #1000's username instead of translating into the also present #1012 local uid (remote #1000) It appears there is also some issue with rpc.idmapd since that is supposed to be the fallback in case request-key fails (however I suspect what is happening is that request_key is returning 'nothing to do here' not 'failure'. Between the mentioned 3.8 and 3.12 versions there are several new conditions added in linux/security/keys/request_key.c that could potentially jointly or severally be responsible for the bad behaviour. It looks like a clearly upstream issue. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773739: xfce4-settings: 'Startup and Sessions' changes to not 'take'
Package: xfce4-settings Version: 4.10.1-2 Severity: important Dear Maintainer, Changing things in 'Startup and Sessions' (e.g. checking or unchecking items in the startup list, or adding item) fails to actually do anything. When you exit and reenter the dialogue no change has occurred for checking/unchecking, and in the case of adding an item the dialogue reports that it was unable to add 'autostart/item.desktop'. Perhaps it is attempting to acess /etc/xdg/autostart intead of ~/.config/autostart? -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xfce4-settings depends on: ii libc6 2.19-13 ii libcairo2 1.14.0-2.1 ii libdbus-1-3 1.8.12-1 ii libdbus-glib-1-20.102-1 ii libexo-1-0 0.10.2-4 ii libfontconfig1 2.11.0-6.3 ii libgarcon-1-0 0.2.1-2 ii libgarcon-common0.2.1-2 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libglib2.0-02.42.1-1 ii libgtk2.0-0 2.24.25-1 ii libnotify4 0.7.6-2 ii libpango-1.0-0 1.36.8-3 ii libx11-62:1.6.2-3 ii libxcursor1 1:1.1.14-1+b1 ii libxfce4ui-1-0 4.10.0-6 ii libxfce4util6 4.10.1-2 ii libxfconf-0-2 4.10.0-3 ii libxi6 2:1.7.4-1+b2 ii libxklavier16 5.2.1-1 ii libxrandr2 2:1.4.2-1+b1 ii xfconf 4.10.0-3 Versions of packages xfce4-settings recommends: ii x11-utils 7.7+2 ii xfce4-volumed 0.1.13-5 xfce4-settings 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#773743: xfce4-power-manager: Suspend fails (requests authentication in order to suspend)
Package: xfce4-power-manager Version: 1.4.1-1 Severity: important Suspend mode is never entered via power-manager due to the fact that when it comes times to suspend an authentication dialogue requesting authorization to suspend pops up instead of suspend occurring. This is on a non-laptop so perhaps there is something in the laptop config that would make this work (haven't tried that yet). -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xfce4-power-manager depends on: ii libc6 2.19-13 ii libdbus-1-3 1.8.12-1 ii libdbus-glib-1-2 0.102-1 ii libgdk-pixbuf2.0-02.31.1-2+b1 ii libglib2.0-0 2.42.1-1 ii libgtk2.0-0 2.24.25-1 ii libnotify40.7.6-2 ii libupower-glib3 0.99.1-3.1 ii libx11-6 2:1.6.2-3 ii libxext6 2:1.3.3-1 ii libxfce4ui-1-04.10.0-6 ii libxfce4util6 4.10.1-2 ii libxfconf-0-2 4.10.0-3 ii libxrandr22:1.4.2-1+b1 ii upower0.99.1-3.1 ii xfce4-power-manager-data 1.4.1-1 Versions of packages xfce4-power-manager recommends: ii libpam-systemd 215-8 ii xfce4-power-manager-plugins 1.4.1-1 xfce4-power-manager 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#773739: xfce4-settings: Issue is with debian-installer creating home dir with root permissions
Package: xfce4-settings Followup-For: Bug #773739 This bug can be closed. My ~/.config directory had root ownership for some reason. Will have to investigate if due to debian-installer issue or an issue with an bad copy (or something wrong with xfce when creating a config based on defaults at the first login prompt). -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xfce4-settings depends on: ii libc6 2.19-13 ii libcairo2 1.14.0-2.1 ii libdbus-1-3 1.8.12-1 ii libdbus-glib-1-20.102-1 ii libexo-1-0 0.10.2-4 ii libfontconfig1 2.11.0-6.3 ii libgarcon-1-0 0.2.1-2 ii libgarcon-common0.2.1-2 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libglib2.0-02.42.1-1 ii libgtk2.0-0 2.24.25-1 ii libnotify4 0.7.6-2 ii libpango-1.0-0 1.36.8-3 ii libx11-62:1.6.2-3 ii libxcursor1 1:1.1.14-1+b1 ii libxfce4ui-1-0 4.10.0-6 ii libxfce4util6 4.10.1-2 ii libxfconf-0-2 4.10.0-3 ii libxi6 2:1.7.4-1+b2 ii libxklavier16 5.2.1-1 ii libxrandr2 2:1.4.2-1+b1 ii xfconf 4.10.0-3 Versions of packages xfce4-settings recommends: ii x11-utils 7.7+2 ii xfce4-volumed 0.1.13-5 xfce4-settings 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#773750: nut-client: Fails to install
Package: nut-client Version: 2.7.2-1+b3 Severity: serious Justification: Fails to install due to failing to start The package fails to configure on install due to ups-monitor service failing to start due to lack of configuration and failed to gracefully handle case of no valid configuration. This causes to package installation to fail which is a violation of debian packaging guidelines. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages nut-client depends on: ii adduser 3.113+nmu3 ii init-system-helpers 1.22 ii libc62.19-13 ii libupsclient42.7.2-1+b3 ii lsb-base 4.1+Debian13+nmu1 Versions of packages nut-client recommends: ii bash-completion 1:2.1-4 Versions of packages nut-client suggests: ii nut-monitor 2.7.2-1 -- Configuration Files: /etc/nut/nut.conf [Errno 13] Permission denied: u'/etc/nut/nut.conf' /etc/nut/upsmon.conf [Errno 13] Permission denied: u'/etc/nut/upsmon.conf' /etc/nut/upssched.conf [Errno 13] Permission denied: u'/etc/nut/upssched.conf' -- 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#770628: deluged: Says starting via deluged.service (systemd) but no deluged.service file exists
Package: deluged Version: 1.3.10-2 Followup-For: Bug #770628 Deluged fails to start when doing service restart or /etc/init.d/deluged restart. The message says that it is starting via systemctl deluged.service however no deluged.service file exists which I suspect is why the service fails to start. Ownership on /var/lib/deluged/config is debian-deluged:debian-deluged. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages deluged depends on: ii adduser3.113+nmu3 ii deluge-common 1.3.10-2 ii lsb-base 4.1+Debian13+nmu1 ii python-libtorrent 0.16.18-1 pn python:any none deluged recommends no packages. deluged suggests no packages. -- Configuration Files: /etc/default/deluged changed: ENABLE_DELUGED=1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773766: systemd: Fails to start unconverted scripts in init.d
Package: systemd Version: 215-8 Severity: important At least in the instance of deluged for which there is an initscript in /etc/init.d/deluged but no deluged.service doing /etc/init.d/deluged start gives the message starting by systemctl deluged.service however such a file does not exist anywhere on the filesystem and deluged fails to start. This is a rather serious regression if systemd is only going to start services which have been converted to systemd. -- Package-specific info: -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii acl 2.2.52-2 ii adduser 3.113+nmu3 ii initscripts 2.88dsf-58 ii libacl1 2.2.52-2 ii libaudit1 1:2.4-1+b1 ii libblkid1 2.25.2-4 ii libc6 2.19-13 ii libcap2 1:2.24-6 ii libcap2-bin 1:2.24-6 ii libcryptsetup4 2:1.6.6-3 ii libgcrypt20 1.6.2-4+b1 ii libkmod218-3 ii liblzma55.1.1alpha+20120614-2+b3 ii libpam0g1.1.8-3.1 ii libselinux1 2.3-2 ii libsystemd0 215-8 ii mount 2.25.2-4 ii sysv-rc 2.88dsf-58 ii udev215-8 ii util-linux 2.25.2-4 Versions of packages systemd recommends: ii dbus1.8.12-1 ii libpam-systemd 215-8 Versions of packages systemd suggests: pn systemd-ui none -- 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#773770: git-daemon-run: Depend on runit which fails to install due to missing inittab
Package: git-daemon-run Version: jessie Severity: normal This packages depend on runit which depends on the existence of inittab which is not longer true with systemd. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773146: exim4-daemon-heavy: exiscan spamd acl maxes cpu with large messages for 10 minute even though spamc 1 second
Package: exim4-daemon-heavy Version: 4.80-7+deb7u1 Severity: normal Using exim4-daemon-heavy to use the exiscan patch that allows to use spamd filtering in acl's fails with large emails. I don't know the exact cutoff but with a 4.5M email that a command line invocation of spamc can process in 1 second, spamd takes about 10 minutes at max cpu for one core. This is clearly a flaw in the way exim/exiscan is handling the email rather than a limitation of spamassassin/spamd. The email in question is just a firewall log summary from repeated blocks of a misconfigured program and is a pure text file of kernel log entries. -- Package-specific info: Exim version 4.80 #2 built 24-Jul-2014 03:28:02 Copyright (c) University of Cambridge, 1995 - 2012 (c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2012 Berkeley DB: Berkeley DB 5.1.29: (October 25, 2011) Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS move_frozen_messages Content_Scanning DKIM Old_Demime Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp Fixed never_users: 0 Size of off_t: 8 Configuration file is /var/lib/exim4/config.autogenerated # /etc/exim4/update-exim4.conf.conf # # Edit this file and /etc/mailname by hand and execute update-exim4.conf # yourself or use 'dpkg-reconfigure exim4-config' # # Please note that this is _not_ a dpkg-conffile and that automatic changes # to this file might happen. The code handling this will honor your local # changes, so this is usually fine, but will break local schemes that mess # around with multiple versions of the file. # # update-exim4.conf uses this file to determine variable values to generate # exim configuration macros for the configuration file. # # Most settings found in here do have corresponding questions in the # Debconf configuration, but not all of them. # # This is a Debian specific file dc_eximconfig_configtype='smarthost' dc_other_hostnames='' dc_local_interfaces='127.0.0.1 ; ::1; 192.168.128.108' dc_readhost='' dc_relay_domains='' dc_minimaldns='false' dc_relay_nets='' dc_smarthost='redacted::666' CFILEMODE='644' dc_use_split_config='true' dc_hide_mailname='false' dc_mailname_in_oh='true' dc_localdelivery='mail_spool' mailname:redacted.private -- System Information: Debian Release: 7.7 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/3 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages exim4-daemon-heavy depends on: ii debconf [debconf-2.0] 1.5.49 ii exim4-base 4.80-7+deb7u1 ii libc6 2.13-38+deb7u6 ii libdb5.1 5.1.29-5 ii libgnutls262.12.20-8+deb7u2 ii libldap-2.4-2 2.4.31-1+nmu2 ii libmysqlclient18 5.5.40-0+wheezy1 ii libpam0g 1.1.3-7.1 ii libpcre3 1:8.30-5 ii libperl5.145.14.2-21+deb7u2 ii libpq5 9.1.14-0+deb7u1 ii libsasl2-2 2.1.25.dfsg1-6+deb7u1 ii libsqlite3-0 3.7.13-1+deb7u1 exim4-daemon-heavy recommends no packages. exim4-daemon-heavy suggests no packages. -- debconf information: exim4-daemon-heavy/drec: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750847: owncloud-client: Is looking for icons which do not exists in any package
Package: owncloud-client
Version: 1.6.2+dfsg-1
Followup-For: Bug #750847
The client is looking for owncloud.png, state-offline.{png|svg},
state-error.{png|svg}, and state-ok.{png|ok}
which according to apt-file do not exist in any package.
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages owncloud-client depends on:
ii libc6 2.19-10
ii libgcc1 1:4.9.1-12
ii libowncloudsync0 1.6.2+dfsg-1
ii libqt5core5a 5.3.1+dfsg-3
ii libqt5dbus5 5.3.1+dfsg-3
ii libqt5gui55.3.1+dfsg-3
ii libqt5network55.3.1+dfsg-3
ii libqt5sql5-sqlite 5.3.1+dfsg-3
ii libqt5widgets55.3.1+dfsg-3
ii libqt5xml55.3.1+dfsg-3
ii libstdc++64.9.1-12
ii owncloud-client-l10n 1.6.2+dfsg-1
owncloud-client recommends no packages.
owncloud-client 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#738286: use getty instead of login
On 14/06/14 01:45 AM, Daniel Baumann wrote: Gentle reminder.. did you have time/can you make time for a patch? Regards, Daniel FYI, The fix would only be applicable to systemv not to systemd. Is it still worth doing? I haven't boot a live system with systemd yet but from the code I don't see you currently doing autologin for me to apply the patch there, judging from the code. Regards, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761026: gpa: GPGME Error at keytable.c:150 'Unsupported certificate' renders GPA unusable
Package: gpa Version: 0.9.5-1 Severity: normal Even moving away my keyring does not solve the issue that on start GPA says The GPME library returned an unexpected error at keytable.c:150. The was: Unsupported certificate This is either an installation problem or a bug in GPA. GPA will now try to recover from the this error. After which no key can created (when .gnupg empty) OR other times I can't even close that dialogue. Also occurs with existing .gnupg and *.gpg -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gpa depends on: ii gnupg2 2.0.26-2 ii gpgsm 2.0.26-2 ii libassuan0 2.1.2-2 ii libc6 2.19-10 ii libgdk-pixbuf2.0-0 2.30.8-1 ii libglib2.0-02.40.0-5 ii libgpg-error0 1.13-4 ii libgpgme11 1.5.1-2 ii libgtk2.0-0 2.24.24-1 ii zlib1g 1:1.2.8.dfsg-1 gpa recommends no packages. gpa 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#761026: [Pkg-gnupg-maint] Bug#761026: gpa: GPGME Error at keytable.c:150 'Unsupported certificate' renders GPA unusable
On 09/09/14 11:23 PM, NIIBE Yutaka wrote: On 2014-09-09 at 23:09 -0400, Daniel Dickinson wrote: The GPME library returned an unexpected error at keytable.c:150. The was: Unsupported certificate I think that it is GNOME keyring which gets the connection to gpg-agent (and produced the error). Please see the message below and try to disable GNOME Keyring: http://lists.gnupg.org/pipermail/gnupg-devel/2013-May/027658.html Sorry in advance, if my analysis is incorrect. You are in fact correct, with the caveat I am using XFCE and had the XFCE startup option (Start GNOME Services) enabled which automatically runs gnome-keyring with all options (including gpg agent) and there doesn't seem to be a way to deselect that unless you turn off that option and only select the gnome-keyring services you specifically want (in my case gnome-keyring, for network-manager). Perhaps the error message could be improved to suggest such an issue/solution so that users know where to look. Especially given the error message that is thrown it didn't occur to me that it was not a bug or other packaging error (since the error claims it is). Regards, Daniel signature.asc Description: OpenPGP digital signature
Bug#738286: use getty instead of login
On 09/09/14 11:57 PM, Daniel Baumann wrote: On 09/10/2014 03:40 AM, Daniel Dickinson wrote: FYI, The fix would only be applicable to systemv not to systemd. Is it still worth doing? yes. we still support and will support sysvinit for quite some time (at least until jessie+1 EOL, which is at least until about 2020 or so). I haven't boot a live system with systemd yet but from the code I don't see you currently doing autologin for me to apply the patch there, judging from the code. we do there, but there's a slight bug with systemd still.. but i'm taking care of that. so your patch for sysvinit would be still be much appreciated. Ok, I'll let you know once I've tested the patch to verify the patch is done correctly. I got sidetracked by gnome keyring issue (I was trying to update my gpg email addresses to reflect current reality and both GUIs I tried failed) since I was building live-config and noticed my keys weren't up to date. Regards, Daniel signature.asc Description: OpenPGP digital signature
Bug#761029: seahorse: Pulls old key from server before pushing updated (local) version which undoes edits to userids
Package: seahorse Version: 3.12.2-1 Severity: normal If I remove userid from my private+public key and then do a sync, seahorse pulls the old key from the keyserver and adds back the userids before pushing my changes to the server. This causes the edit to be undone on the public side of the key. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages seahorse depends on: ii dconf-gsettings-backend [gsettings-backend] 0.20.0-2 ii gcr 3.12.2-1 ii gnome-keyring3.12.2-1 ii gnupg1.4.18-2 ii libassuan0 2.1.2-2 ii libatk1.0-0 2.12.0-1 ii libavahi-client3 0.6.31-4 ii libavahi-common3 0.6.31-4 ii libavahi-glib1 0.6.31-4 ii libc62.19-10 ii libcairo-gobject21.12.16-3 ii libcairo21.12.16-3 ii libgck-1-0 3.12.2-1 ii libgcr-base-3-1 3.12.2-1 ii libgcr-ui-3-13.12.2-1 ii libgdk-pixbuf2.0-0 2.30.8-1 ii libglib2.0-0 2.40.0-5 ii libgpg-error01.13-4 ii libgpgme11 1.5.1-5 ii libgtk-3-0 3.12.2-3+b1 ii libldap-2.4-22.4.39-1.1+b1 ii libp11-kit0 0.20.3-2 ii libpango-1.0-0 1.36.6-1 ii libpangocairo-1.0-0 1.36.6-1 ii libsecret-1-00.18-1 ii libsoup2.4-1 2.46.0-2 Versions of packages seahorse recommends: ii openssh-client 1:6.6p1-7 seahorse 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#761031: seahorse: Editing keys fails with unknown error when gnome-keyring's gpg-agent is active
Package: seahorse Version: 3.12.2-1 Severity: normal Editing userids present on a key fails during passphrase entry when gnome-keyring's gpg-agent is active. If you disable gnome-keyring's gpg support then this issue goes away (i.e thing work). This problem also affects gpa and is a general problem due to the fact that gnome-keyring has not kept pace with changes in gnugp (and native gnupg-agent actually does all the 'addon' features of gnome-keyring except the gnome-keyring core functionality and programs (or perhaps libgpgme) are written for gnupg-agent not gnome-keyring)). -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages seahorse depends on: ii dconf-gsettings-backend [gsettings-backend] 0.20.0-2 ii gcr 3.12.2-1 ii gnome-keyring3.12.2-1 ii gnupg1.4.18-2 ii libassuan0 2.1.2-2 ii libatk1.0-0 2.12.0-1 ii libavahi-client3 0.6.31-4 ii libavahi-common3 0.6.31-4 ii libavahi-glib1 0.6.31-4 ii libc62.19-10 ii libcairo-gobject21.12.16-3 ii libcairo21.12.16-3 ii libgck-1-0 3.12.2-1 ii libgcr-base-3-1 3.12.2-1 ii libgcr-ui-3-13.12.2-1 ii libgdk-pixbuf2.0-0 2.30.8-1 ii libglib2.0-0 2.40.0-5 ii libgpg-error01.13-4 ii libgpgme11 1.5.1-5 ii libgtk-3-0 3.12.2-3+b1 ii libldap-2.4-22.4.39-1.1+b1 ii libp11-kit0 0.20.3-2 ii libpango-1.0-0 1.36.6-1 ii libpangocairo-1.0-0 1.36.6-1 ii libsecret-1-00.18-1 ii libsoup2.4-1 2.46.0-2 Versions of packages seahorse recommends: ii openssh-client 1:6.6p1-7 seahorse 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#756224: libnss-myhostname: Causes apps that need FQDN to fail
On 28/07/14 09:40 AM, Joachim Breitner wrote: BTW, what should the FQDN even be here? My laptop doesn’t have a FQDN that resolves to it, so the concept seems to be dubious at least. Actually unless your laptop is not connected to a network via DHCP there is a 90% probability that if libnss-hostname is not installed that you will resolve to DHCP-hostname.DHCP-handed-out-domain. DHCP almost always hands out a domain which is used to create an FQDN for devices connected to that network. If the DHCP server does not auto-update the DNS server with the client supplied hostname from the laptop then it is possible you will fail to have DNS resolution but that is because DNS doesn't know about your laptop not because you don't and/or can't have an FQDN. The issue with laptops and mobile devices is not that that they do not have a domain (and hence FQDN) but that not all routers automatically create local DNS entries AND the domain depends on what work the device is attached to and hence is a changeable beast. From the perspective of the network administrator of properly administred network the FQDN makes perfect sense, the issue is that on a lot of home networks the FQDN is of little value - OTOH the hostname is also of little or no value on such network and really that isn't a good argument for ditching FQDN. The changeable nature of FQDN for mobile devices means that it would be silly to rely on client-reported FQDN without some sort of verification of the device, but that is an entirely separate issue from having an FQDN in the first place. The fact is that any argument against FQDN on a mobile device could be made about hostname on mobile device. So forget about mobile devices in the argument and consider that lack of FQDN breaks important and core things like email on permanently connected networks. Dealing with mobile devices is what things like SMTP-AUTH are for, but that does not invalidate the usefulness or importance of FQDN as a concept nor as something that should be considered broken any more than hostnames themselves. Regards, Daniel Re signature.asc Description: OpenPGP digital signature
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
I think you're wrong. Setting hostname via dhcp (usually not enabled) is different than getting domain from dhcp (usually enabled AIUI). They are completely configuration items in the dhclient and similar tools. Regards, Daniel On 08/09/14 05:54 AM, Vincent Lefevre wrote: On 2014-09-08 04:53:08 -0400, Daniel Dickinson wrote: On 28/07/14 09:40 AM, Joachim Breitner wrote: BTW, what should the FQDN even be here? My laptop doesn’t have a FQDN that resolves to it, so the concept seems to be dubious at least. Actually unless your laptop is not connected to a network via DHCP there is a 90% probability that if libnss-hostname is not installed that you will resolve to DHCP-hostname.DHCP-handed-out-domain. I disagree on this probability. At the Debian installation, the FQDN (specified at the installation) is put in /etc/hosts on the 127.0.1.1 line (unless this has changed recently). This means that the nodename will resolve to the configured FQDN and won't depend on DHCP, unless the DHCP client has been configured to update the nodename from the DHCP server, which is a very bad idea as this breaks various programs: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635322 Well, that's for IPv4. I'm wondering whether there's a glibc bug, which does not make the nodename resolvable with IPv6 via files as well. Otherwise one might be able to see problems similar to what libnss-hostname gives. signature.asc Description: OpenPGP digital signature
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
On 08/09/14 01:18 PM, Daniel Dickinson wrote: I think you're wrong. Setting hostname via dhcp (usually not enabled) is different than getting domain from dhcp (usually enabled AIUI). They are completely configuration items in the dhclient and similar tools. Sorry, I meant completely different... Regards, Daniel On 08/09/14 05:54 AM, Vincent Lefevre wrote: On 2014-09-08 04:53:08 -0400, Daniel Dickinson wrote: On 28/07/14 09:40 AM, Joachim Breitner wrote: BTW, what should the FQDN even be here? My laptop doesn’t have a FQDN that resolves to it, so the concept seems to be dubious at least. Actually unless your laptop is not connected to a network via DHCP there is a 90% probability that if libnss-hostname is not installed that you will resolve to DHCP-hostname.DHCP-handed-out-domain. I disagree on this probability. At the Debian installation, the FQDN (specified at the installation) is put in /etc/hosts on the 127.0.1.1 line (unless this has changed recently). This means that the nodename will resolve to the configured FQDN and won't depend on DHCP, unless the DHCP client has been configured to update the nodename from the DHCP server, which is a very bad idea as this breaks various programs: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635322 Well, that's for IPv4. I'm wondering whether there's a glibc bug, which does not make the nodename resolvable with IPv6 via files as well. Otherwise one might be able to see problems similar to what libnss-hostname gives. signature.asc Description: OpenPGP digital signature
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
On 08/09/14 01:18 PM, Daniel Dickinson wrote: I think you're wrong. Setting hostname via dhcp (usually not enabled) is different than getting domain from dhcp (usually enabled AIUI). They are completely configuration items in the dhclient and similar tools. Speaking of which, perhaps to resolve this libnss-myhostname issue perhaps libnss-myhostname should *only* touch hostname and have a separate libnss-mydomain for getting FQDN via same mechanism, in the absence of it being defined elsewhere (like DHCP), though obviously myhostname and mydomain shouldn't be lowest on the totem pole. Regards, Daniel Regards, Daniel On 08/09/14 05:54 AM, Vincent Lefevre wrote: On 2014-09-08 04:53:08 -0400, Daniel Dickinson wrote: On 28/07/14 09:40 AM, Joachim Breitner wrote: BTW, what should the FQDN even be here? My laptop doesn’t have a FQDN that resolves to it, so the concept seems to be dubious at least. Actually unless your laptop is not connected to a network via DHCP there is a 90% probability that if libnss-hostname is not installed that you will resolve to DHCP-hostname.DHCP-handed-out-domain. I disagree on this probability. At the Debian installation, the FQDN (specified at the installation) is put in /etc/hosts on the 127.0.1.1 line (unless this has changed recently). This means that the nodename will resolve to the configured FQDN and won't depend on DHCP, unless the DHCP client has been configured to update the nodename from the DHCP server, which is a very bad idea as this breaks various programs: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635322 Well, that's for IPv4. I'm wondering whether there's a glibc bug, which does not make the nodename resolvable with IPv6 via files as well. Otherwise one might be able to see problems similar to what libnss-hostname gives. signature.asc Description: OpenPGP digital signature
Bug#760901: apache2: On kfreebsd fails to start with default config due to wrong locking mechanism
Package: apache2.2-common Version: 2.2.22-13+deb7u3 Severity: normal Apache fails to start due to unimplemented function in the default configuration when run on kfreebsd (at least amd64 but probably all). The solution is to add AcceptMutex fcntl in a file in /etc/apache2/conf.d Regards, Daniel -- Package-specific info: List of enabled modules from 'apache2 -M': alias auth_basic authn_file authz_default authz_groupfile authz_host authz_user autoindex cgi deflate dir env mime negotiation reqtimeout setenvif status -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.2-RELEASE-p10 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages apache2 depends on: ii apache2-mpm-prefork 2.2.22-13+deb7u3 ii apache2.2-common 2.2.22-13+deb7u3 apache2 recommends no packages. apache2 suggests no packages. Versions of packages apache2.2-common depends on: ii apache2-utils 2.2.22-13+deb7u3 ii apache2.2-bin 2.2.22-13+deb7u3 ii lsb-base 4.1+Debian8+deb7u1 ii mime-support 3.52-1 ii perl 5.14.2-21+deb7u1 ii procps 1:3.3.3-3 Versions of packages apache2.2-common recommends: ii ssl-cert 1.0.32 Versions of packages apache2.2-common suggests: pn apache2-doc none pn apache2-suexec | apache2-suexec-custom none ii w3m [www-browser] 0.5.3-8 -- 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#738286: use getty instead of login
I have finally got things calmed down I ought to be able to make time sometime in the next two weeks to work on this and do some personal live image stuff (i.e. actually use live-build). I also plan on further investigating the apt thing that causes 'suggests' to end up in the image - from what I remember from the discussion is that apparently apt doesn't remove suggests if they have added by a package pulled in by a recommends later removed (i.e. if something causes a package to be added but later gets pruned, the pruning doesn't prune suggests). Regards, Daniel On 14/06/14 01:45 AM, Daniel Baumann wrote: Gentle reminder.. did you have time/can you make time for a patch? Regards, Daniel signature.asc Description: OpenPGP digital signature
Bug#663012: procps: Occurs for kfreebsd inside freebsd jail
On 05/09/14 07:42 AM, Craig Small wrote: On Thu, Sep 04, 2014 at 09:21:52AM -0400, Daniel Dickinson wrote: I will have to further testing to confirm this, but from outside the jail I can see that procfs is mounted on jail's proc. Since FreeNAS runs on FreeBSD that looks to me like FreeBSD's procfs is mounted on jail's /proc and is likely why the mount of linprocfs from inside the jail (by freebsd-utils) fails (assuming of course the it's not actually a case of needing to hack on things so that linprocfs gets mounted prior to jail startup). OK then, you might find its not a compatible procfs in any case then. That would mean you'd need to use the native freebsd tools, which would understand that partition better. - Craig This bug can be closed. This issue was that linprocfs (the freebsd linux-compatibility layer procfs) wasn't getting mounted so there was no standard-linux-tool compatible procfs on /proc. I was able to fix this so that linprocfs was mounted instead of freebsd procfs and ps and friends all work properly now. If linprocfs had not been the problem the solution wouldn't have been a simple switch to native tools (assuming freebsd ps and friends are even available in debian?) because even tools like start-stop-daemon and postfix's postmulti rely on linux-kernel-isms to determine the process name (and even start-stop-daemon that can work purely from PID is normally called with --exec or --name which requires knowing the process name). In any event once I tracked down the misbehaving jail mount the solution was easy enough (use the linux-compatible procfs). Perhaps longer-term for the kfreebsd-* ports it would be a good idea to adapt process querying/manipulating tools but my guess is it would likely require more work than it'd be worth. Regards, Daniel signature.asc Description: OpenPGP digital signature
Bug#760223: Acknowledgement (/etc/init.d/dovecot: Use of --name $DAEMON in start-stop-daemon for stop/restart causes failure to stop/restart in certain virtualized environments)
On 01/09/14 06:30 PM, Debian Bug Tracking System wrote: Thank you for filing a new Bug report with Debian. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. As you requested using X-Debbugs-CC, your message was also forwarded to debian-b...@daniel.thecshore.com (after having been given a Bug report number, if it did not have one). Your message has been sent to the package maintainer(s): Dovecot Maintainers jaldhar-dove...@debian.org If you wish to submit further information on this problem, please send it to 760...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. This can be downgraded to lowest, maybe even wishlist priorty as, at least in the scenario I'm in, which is the only one I have sufficient information to base an assessment on, the jail wasn't using linprocfs (freebsd linux compability profs) but instead the freebsd native procfs. Given that linprocfs exists and things work properly when using it, there is no great urgency, on kfreebsd, to mess with a whack of initscripts and/or system tools (like start-stop-daemon). Regards, Daniel signature.asc Description: OpenPGP digital signature
Bug#760225: Acknowledgement (/etc/init.d/nfsiod: Reliance on --name $DAEMON in start-stop-daemon stop/restart causes failure inside freebsd jails)
On 01/09/14 06:36 PM, Debian Bug Tracking System wrote: Thank you for filing a new Bug report with Debian. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. As you requested using X-Debbugs-CC, your message was also forwarded to debian-b...@daniel.thecshore.com (after having been given a Bug report number, if it did not have one). Your message has been sent to the package maintainer(s): GNU/kFreeBSD Maintainers debian-...@lists.debian.org If you wish to submit further information on this problem, please send it to 760...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. This can be downgraded to lowest, maybe even wishlist priorty as, at least in the scenario I'm in, which is the only one I have sufficient information to base an assessment on, the jail wasn't using linprocfs (freebsd linux compability profs) but instead the freebsd native procfs. Given that linprocfs exists and things work properly when using it, there is no great urgency, on kfreebsd, to mess with a whack of initscripts and/or system tools (like start-stop-daemon). Regards, Daniel signature.asc Description: OpenPGP digital signature
Bug#760220: Acknowledgement (clamav-freshclam: Use of --name in start-stop-daemon for stop and restart causes failure to stop in certain virtualized environments)
On 01/09/14 06:24 PM, Debian Bug Tracking System wrote: Thank you for filing a new Bug report with Debian. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. As you requested using X-Debbugs-CC, your message was also forwarded to debian-b...@daniel.thecshore.com (after having been given a Bug report number, if it did not have one). Your message has been sent to the package maintainer(s): ClamAV Team pkg-clamav-de...@lists.alioth.debian.org If you wish to submit further information on this problem, please send it to 760...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. This can be downgraded to lowest, maybe even wishlist priorty as, at least in the scenario I'm in, which is the only one I have sufficient information to base an assessment on, the jail wasn't using linprocfs (freebsd linux compability profs) but instead the freebsd native procfs. Given that linprocfs exists and things work properly when using it, there is no great urgency, on kfreebsd, to mess with a whack of initscripts and/or system tools (like start-stop-daemon). Regards, Daniel signature.asc Description: OpenPGP digital signature
Bug#760221: Acknowledgement (clamav-milter: 760219 also applies to clamav-milter)
On 01/09/14 06:27 PM, Debian Bug Tracking System wrote: Thank you for filing a new Bug report with Debian. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. As you requested using X-Debbugs-CC, your message was also forwarded to debian-b...@daniel.thecshore.com (after having been given a Bug report number, if it did not have one). Your message has been sent to the package maintainer(s): ClamAV Team pkg-clamav-de...@lists.alioth.debian.org If you wish to submit further information on this problem, please send it to 760...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. This can be downgraded to lowest, maybe even wishlist priorty as, at least in the scenario I'm in, which is the only one I have sufficient information to base an assessment on, the jail wasn't using linprocfs (freebsd linux compability profs) but instead the freebsd native procfs. Given that linprocfs exists and things work properly when using it, there is no great urgency, on kfreebsd, to mess with a whack of initscripts and/or system tools (like start-stop-daemon). Regards, Daniel signature.asc Description: OpenPGP digital signature
Bug#760219: Acknowledgement (clamav-daemon: use of --name in init.d's stop-start-daemon causes failure to stop in certain virtualized environments)
On 01/09/14 06:21 PM, Debian Bug Tracking System wrote: Thank you for filing a new Bug report with Debian. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. As you requested using X-Debbugs-CC, your message was also forwarded to debian-b...@daniel.thecshore.com (after having been given a Bug report number, if it did not have one). Your message has been sent to the package maintainer(s): ClamAV Team pkg-clamav-de...@lists.alioth.debian.org If you wish to submit further information on this problem, please send it to 760...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. This can be downgraded to lowest, maybe even wishlist priorty as, at least in the scenario I'm in, which is the only one I have sufficient information to base an assessment on, the jail wasn't using linprocfs (freebsd linux compability profs) but instead the freebsd native procfs. Given that linprocfs exists and things work properly when using it, there is no great urgency, on kfreebsd, to mess with a whack of initscripts and/or system tools (like start-stop-daemon). Regards, Daniel signature.asc Description: OpenPGP digital signature
Bug#663012: procps: Occurs for kfreebsd inside freebsd jail
On 04/09/14 07:45 AM, Craig Small wrote: On Sun, Aug 31, 2014 at 10:01:08PM -0400, Daniel Dickinson wrote: If you install debian/kfreefsd-amd64 inside a freebsd jail (sort of like LXC/chroot-on-steroids) then attempts to use the commands from procps gives the error that /proc/version does not exist even thogh linprocfs is in fact mounted. It mustn't be mounted correctly then. libprocps needs the version file detect procfs is mounted but also the version of procfs. Shouldn't the jail copy this file across? Any idea why this file doesn't appear in the jail while other procfs file do? - Craig It seems that the distro (FreeNAS) automounts FreeBSD procfs on /proc of FreeBSD jails so the mount of linprocfs never actually happens. I will have to further testing to confirm this, but from outside the jail I can see that procfs is mounted on jail's proc. Since FreeNAS runs on FreeBSD that looks to me like FreeBSD's procfs is mounted on jail's /proc and is likely why the mount of linprocfs from inside the jail (by freebsd-utils) fails (assuming of course the it's not actually a case of needing to hack on things so that linprocfs gets mounted prior to jail startup). Regards, Daniel signature.asc Description: OpenPGP digital signature
Bug#663012: procps: Occurs for kfreebsd inside freebsd jail
Package: procps Version: 1:3.3.3-3 Followup-For: Bug #663012 If you install debian/kfreefsd-amd64 inside a freebsd jail (sort of like LXC/chroot-on-steroids) then attempts to use the commands from procps gives the error that /proc/version does not exist even thogh linprocfs is in fact mounted. I can manually cat /proc/pid/cmdline to determine the running processes but obvious would prefer that process listing worked. /proc in this case contains only PIDs and curproc (symlink to current process' PID) The process table clearly is accessible from /proc/PID contents but procps makes the fatal assumption/requirement of more than this. -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.2-RELEASE-p9 Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages procps depends on: ii initscripts 2.88dsf-41+deb7u1 ii libc0.1 2.13-38+deb7u4 ii libncurses5 5.9-10 ii libncursesw5 5.9-10 ii libprocps01:3.3.3-3 ii libtinfo5 5.9-10 ii lsb-base 4.1+Debian8+deb7u1 Versions of packages procps recommends: ii psmisc 22.19-1+deb7u1 procps 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#760219: clamav-daemon: use of --name in init.d's stop-start-daemon causes failure to stop in certain virtualized environments
Package: clamav-daemon Version: 0.98.4+dfsg-0+deb7u2 Severity: normal /etc/init.d/clamav-deamon uses --name in it's start-stop-daemon calls for stop and restart. This fails when process names are not available due to use of certain virtualized environments use as kfreebsd in freebsd jail (others have the same issue from reports I've read however this is what I am use) due to limited /proc. Changin relying solely on PIDFILE fixes the issue (i.e. drop --name $DAEMON) -- Package-specific info: --- configuration --- Checking configuration files in /etc/clamav Config file: clamd.conf --- LogFile = /var/log/clamav/clamav.log StatsHostID = auto StatsEnabled disabled StatsPEDisabled = yes StatsTimeout = 10 LogFileUnlock disabled LogFileMaxSize = 4294967295 LogTime = yes LogClean disabled LogSyslog disabled LogFacility = LOG_LOCAL6 LogVerbose disabled LogRotate = yes ExtendedDetectionInfo = yes PidFile = /var/run/clamav/clamd.pid TemporaryDirectory disabled DatabaseDirectory = /var/lib/clamav OfficialDatabaseOnly disabled LocalSocket = /var/run/clamav/clamd.ctl LocalSocketGroup = clamav LocalSocketMode = 666 FixStaleSocket = yes TCPSocket disabled TCPAddr disabled MaxConnectionQueueLength = 15 StreamMaxLength = 26214400 StreamMinPort = 1024 StreamMaxPort = 2048 MaxThreads = 12 ReadTimeout = 180 CommandReadTimeout = 5 SendBufTimeout = 200 MaxQueue = 100 IdleTimeout = 30 ExcludePath disabled MaxDirectoryRecursion = 15 FollowDirectorySymlinks disabled FollowFileSymlinks disabled CrossFilesystems = yes SelfCheck = 3600 DisableCache disabled VirusEvent disabled ExitOnOOM disabled AllowAllMatchScan = yes Foreground disabled Debug disabled LeaveTemporaryFiles disabled User = clamav AllowSupplementaryGroups disabled Bytecode = yes BytecodeSecurity = TrustSigned BytecodeTimeout = 6 BytecodeUnsigned disabled BytecodeMode = Auto DetectPUA disabled ExcludePUA disabled IncludePUA disabled AlgorithmicDetection = yes ScanPE = yes ScanELF = yes DetectBrokenExecutables disabled ScanMail = yes ScanPartialMessages disabled PhishingSignatures = yes PhishingScanURLs = yes PhishingAlwaysBlockCloak disabled PhishingAlwaysBlockSSLMismatch disabled PartitionIntersection disabled HeuristicScanPrecedence disabled StructuredDataDetection disabled StructuredMinCreditCardCount = 3 StructuredMinSSNCount = 3 StructuredSSNFormatNormal = yes StructuredSSNFormatStripped disabled ScanHTML = yes ScanOLE2 = yes OLE2BlockMacros disabled ScanPDF = yes ScanSWF = yes ScanArchive = yes ArchiveBlockEncrypted disabled ForceToDisk disabled MaxScanSize = 104857600 MaxFileSize = 26214400 MaxRecursion = 10 MaxFiles = 1 MaxEmbeddedPE = 10485760 MaxHTMLNormalize = 10485760 MaxHTMLNoTags = 2097152 MaxScriptNormalize = 5242880 MaxZipTypeRcg = 1048576 MaxPartitions = 50 MaxIconsPE = 100 ScanOnAccess disabled OnAccessIncludePath disabled OnAccessExcludePath disabled OnAccessExcludeUID disabled OnAccessMaxFileSize = 5242880 DevACOnly disabled DevACDepth disabled DevPerformance disabled DevLiblog disabled DisableCertCheck disabled Config file: freshclam.conf --- StatsHostID disabled StatsEnabled disabled StatsTimeout disabled LogFileMaxSize = 4294967295 LogTime = yes LogSyslog disabled LogFacility = LOG_LOCAL6 LogVerbose disabled LogRotate = yes PidFile = /var/run/clamav/freshclam.pid DatabaseDirectory = /var/lib/clamav Foreground disabled Debug disabled AllowSupplementaryGroups disabled UpdateLogFile = /var/log/clamav/freshclam.log DatabaseOwner = clamav Checks = 24 DNSDatabaseInfo = current.cvd.clamav.net DatabaseMirror = db.local.clamav.net, database.clamav.net PrivateMirror disabled MaxAttempts = 5 ScriptedUpdates = yes TestDatabases = yes CompressLocalDatabase disabled ExtraDatabase disabled DatabaseCustomURL disabled HTTPProxyServer disabled HTTPProxyPort disabled HTTPProxyUsername disabled HTTPProxyPassword disabled HTTPUserAgent disabled NotifyClamd = /etc/clamav/clamd.conf OnUpdateExecute disabled OnErrorExecute disabled OnOutdatedExecute disabled LocalIPAddress disabled ConnectTimeout = 30 ReceiveTimeout = 30 SubmitDetectionStats disabled DetectionStatsCountry disabled DetectionStatsHostID disabled SafeBrowsing disabled Bytecode = yes Config file: clamav-milter.conf --- LogFile = /var/log/clamav/clamav-milter.log LogFileUnlock disabled LogFileMaxSize = 1048576 LogTime = yes LogSyslog disabled LogFacility = LOG_LOCAL6 LogVerbose disabled LogRotate = yes PidFile = /var/run/clamav/clamav-milter.pid TemporaryDirectory = /tmp FixStaleSocket = yes MaxThreads = 10 ReadTimeout = 120 Foreground disabled User = clamav AllowSupplementaryGroups = yes MaxFileSize = 26214400 ClamdSocket = unix:/var/run/clamav/clamd.ctl MilterSocket = /var/run/clamav/clamav-milter.ctl MilterSocketGroup = clamav MilterSocketMode = 666 LocalNet disabled OnClean = Accept OnInfected = Quarantine OnFail = Defer RejectMsg disabled AddHeader = Replace ReportHostname disabled VirusAction disabled Chroot
Bug#760220: clamav-freshclam: Use of --name in start-stop-daemon for stop and restart causes failure to stop in certain virtualized environments
Package: clamav-freshclam Version: 0.98.4+dfsg-0+deb7u2 Severity: normal Use of --name $DAEMON in start-stop-daemon calls to stop/restart/reload the daemon results in failure to stop/restart/reload when process names are not available due to limited /proc. This occurs in a number of virtualized environments, in my specific case for debian/kfreebsd-amd64 in a freebsd jail even with linprocfs mounted. Dropping --name $DAEMON and relying solely on PIDFILE solves the issue. -- Package-specific info: --- configuration --- Checking configuration files in /etc/clamav Config file: clamd.conf --- LogFile = /var/log/clamav/clamav.log StatsHostID = auto StatsEnabled disabled StatsPEDisabled = yes StatsTimeout = 10 LogFileUnlock disabled LogFileMaxSize = 4294967295 LogTime = yes LogClean disabled LogSyslog disabled LogFacility = LOG_LOCAL6 LogVerbose disabled LogRotate = yes ExtendedDetectionInfo = yes PidFile = /var/run/clamav/clamd.pid TemporaryDirectory disabled DatabaseDirectory = /var/lib/clamav OfficialDatabaseOnly disabled LocalSocket = /var/run/clamav/clamd.ctl LocalSocketGroup = clamav LocalSocketMode = 666 FixStaleSocket = yes TCPSocket disabled TCPAddr disabled MaxConnectionQueueLength = 15 StreamMaxLength = 26214400 StreamMinPort = 1024 StreamMaxPort = 2048 MaxThreads = 12 ReadTimeout = 180 CommandReadTimeout = 5 SendBufTimeout = 200 MaxQueue = 100 IdleTimeout = 30 ExcludePath disabled MaxDirectoryRecursion = 15 FollowDirectorySymlinks disabled FollowFileSymlinks disabled CrossFilesystems = yes SelfCheck = 3600 DisableCache disabled VirusEvent disabled ExitOnOOM disabled AllowAllMatchScan = yes Foreground disabled Debug disabled LeaveTemporaryFiles disabled User = clamav AllowSupplementaryGroups disabled Bytecode = yes BytecodeSecurity = TrustSigned BytecodeTimeout = 6 BytecodeUnsigned disabled BytecodeMode = Auto DetectPUA disabled ExcludePUA disabled IncludePUA disabled AlgorithmicDetection = yes ScanPE = yes ScanELF = yes DetectBrokenExecutables disabled ScanMail = yes ScanPartialMessages disabled PhishingSignatures = yes PhishingScanURLs = yes PhishingAlwaysBlockCloak disabled PhishingAlwaysBlockSSLMismatch disabled PartitionIntersection disabled HeuristicScanPrecedence disabled StructuredDataDetection disabled StructuredMinCreditCardCount = 3 StructuredMinSSNCount = 3 StructuredSSNFormatNormal = yes StructuredSSNFormatStripped disabled ScanHTML = yes ScanOLE2 = yes OLE2BlockMacros disabled ScanPDF = yes ScanSWF = yes ScanArchive = yes ArchiveBlockEncrypted disabled ForceToDisk disabled MaxScanSize = 104857600 MaxFileSize = 26214400 MaxRecursion = 10 MaxFiles = 1 MaxEmbeddedPE = 10485760 MaxHTMLNormalize = 10485760 MaxHTMLNoTags = 2097152 MaxScriptNormalize = 5242880 MaxZipTypeRcg = 1048576 MaxPartitions = 50 MaxIconsPE = 100 ScanOnAccess disabled OnAccessIncludePath disabled OnAccessExcludePath disabled OnAccessExcludeUID disabled OnAccessMaxFileSize = 5242880 DevACOnly disabled DevACDepth disabled DevPerformance disabled DevLiblog disabled DisableCertCheck disabled Config file: freshclam.conf --- StatsHostID disabled StatsEnabled disabled StatsTimeout disabled LogFileMaxSize = 4294967295 LogTime = yes LogSyslog disabled LogFacility = LOG_LOCAL6 LogVerbose disabled LogRotate = yes PidFile = /var/run/clamav/freshclam.pid DatabaseDirectory = /var/lib/clamav Foreground disabled Debug disabled AllowSupplementaryGroups disabled UpdateLogFile = /var/log/clamav/freshclam.log DatabaseOwner = clamav Checks = 24 DNSDatabaseInfo = current.cvd.clamav.net DatabaseMirror = db.local.clamav.net, database.clamav.net PrivateMirror disabled MaxAttempts = 5 ScriptedUpdates = yes TestDatabases = yes CompressLocalDatabase disabled ExtraDatabase disabled DatabaseCustomURL disabled HTTPProxyServer disabled HTTPProxyPort disabled HTTPProxyUsername disabled HTTPProxyPassword disabled HTTPUserAgent disabled NotifyClamd = /etc/clamav/clamd.conf OnUpdateExecute disabled OnErrorExecute disabled OnOutdatedExecute disabled LocalIPAddress disabled ConnectTimeout = 30 ReceiveTimeout = 30 SubmitDetectionStats disabled DetectionStatsCountry disabled DetectionStatsHostID disabled SafeBrowsing disabled Bytecode = yes Config file: clamav-milter.conf --- LogFile = /var/log/clamav/clamav-milter.log LogFileUnlock disabled LogFileMaxSize = 1048576 LogTime = yes LogSyslog disabled LogFacility = LOG_LOCAL6 LogVerbose disabled LogRotate = yes PidFile = /var/run/clamav/clamav-milter.pid TemporaryDirectory = /tmp FixStaleSocket = yes MaxThreads = 10 ReadTimeout = 120 Foreground disabled User = clamav AllowSupplementaryGroups = yes MaxFileSize = 26214400 ClamdSocket = unix:/var/run/clamav/clamd.ctl MilterSocket = /var/run/clamav/clamav-milter.ctl MilterSocketGroup = clamav MilterSocketMode = 666 LocalNet disabled OnClean = Accept OnInfected = Quarantine OnFail = Defer RejectMsg disabled AddHeader = Replace ReportHostname disabled VirusAction disabled Chroot
Bug#760221: clamav-milter: 760219 also applies to clamav-milter
Package: clamav-milter Version: 0.98.4+dfsg-0+deb7u2 Severity: normal Bug #760219 also applies to clamav-milter. -- Package-specific info: --- configuration --- Checking configuration files in /etc/clamav Config file: clamd.conf --- LogFile = /var/log/clamav/clamav.log StatsHostID = auto StatsEnabled disabled StatsPEDisabled = yes StatsTimeout = 10 LogFileUnlock disabled LogFileMaxSize = 4294967295 LogTime = yes LogClean disabled LogSyslog disabled LogFacility = LOG_LOCAL6 LogVerbose disabled LogRotate = yes ExtendedDetectionInfo = yes PidFile = /var/run/clamav/clamd.pid TemporaryDirectory disabled DatabaseDirectory = /var/lib/clamav OfficialDatabaseOnly disabled LocalSocket = /var/run/clamav/clamd.ctl LocalSocketGroup = clamav LocalSocketMode = 666 FixStaleSocket = yes TCPSocket disabled TCPAddr disabled MaxConnectionQueueLength = 15 StreamMaxLength = 26214400 StreamMinPort = 1024 StreamMaxPort = 2048 MaxThreads = 12 ReadTimeout = 180 CommandReadTimeout = 5 SendBufTimeout = 200 MaxQueue = 100 IdleTimeout = 30 ExcludePath disabled MaxDirectoryRecursion = 15 FollowDirectorySymlinks disabled FollowFileSymlinks disabled CrossFilesystems = yes SelfCheck = 3600 DisableCache disabled VirusEvent disabled ExitOnOOM disabled AllowAllMatchScan = yes Foreground disabled Debug disabled LeaveTemporaryFiles disabled User = clamav AllowSupplementaryGroups disabled Bytecode = yes BytecodeSecurity = TrustSigned BytecodeTimeout = 6 BytecodeUnsigned disabled BytecodeMode = Auto DetectPUA disabled ExcludePUA disabled IncludePUA disabled AlgorithmicDetection = yes ScanPE = yes ScanELF = yes DetectBrokenExecutables disabled ScanMail = yes ScanPartialMessages disabled PhishingSignatures = yes PhishingScanURLs = yes PhishingAlwaysBlockCloak disabled PhishingAlwaysBlockSSLMismatch disabled PartitionIntersection disabled HeuristicScanPrecedence disabled StructuredDataDetection disabled StructuredMinCreditCardCount = 3 StructuredMinSSNCount = 3 StructuredSSNFormatNormal = yes StructuredSSNFormatStripped disabled ScanHTML = yes ScanOLE2 = yes OLE2BlockMacros disabled ScanPDF = yes ScanSWF = yes ScanArchive = yes ArchiveBlockEncrypted disabled ForceToDisk disabled MaxScanSize = 104857600 MaxFileSize = 26214400 MaxRecursion = 10 MaxFiles = 1 MaxEmbeddedPE = 10485760 MaxHTMLNormalize = 10485760 MaxHTMLNoTags = 2097152 MaxScriptNormalize = 5242880 MaxZipTypeRcg = 1048576 MaxPartitions = 50 MaxIconsPE = 100 ScanOnAccess disabled OnAccessIncludePath disabled OnAccessExcludePath disabled OnAccessExcludeUID disabled OnAccessMaxFileSize = 5242880 DevACOnly disabled DevACDepth disabled DevPerformance disabled DevLiblog disabled DisableCertCheck disabled Config file: freshclam.conf --- StatsHostID disabled StatsEnabled disabled StatsTimeout disabled LogFileMaxSize = 4294967295 LogTime = yes LogSyslog disabled LogFacility = LOG_LOCAL6 LogVerbose disabled LogRotate = yes PidFile = /var/run/clamav/freshclam.pid DatabaseDirectory = /var/lib/clamav Foreground disabled Debug disabled AllowSupplementaryGroups disabled UpdateLogFile = /var/log/clamav/freshclam.log DatabaseOwner = clamav Checks = 24 DNSDatabaseInfo = current.cvd.clamav.net DatabaseMirror = db.local.clamav.net, database.clamav.net PrivateMirror disabled MaxAttempts = 5 ScriptedUpdates = yes TestDatabases = yes CompressLocalDatabase disabled ExtraDatabase disabled DatabaseCustomURL disabled HTTPProxyServer disabled HTTPProxyPort disabled HTTPProxyUsername disabled HTTPProxyPassword disabled HTTPUserAgent disabled NotifyClamd = /etc/clamav/clamd.conf OnUpdateExecute disabled OnErrorExecute disabled OnOutdatedExecute disabled LocalIPAddress disabled ConnectTimeout = 30 ReceiveTimeout = 30 SubmitDetectionStats disabled DetectionStatsCountry disabled DetectionStatsHostID disabled SafeBrowsing disabled Bytecode = yes Config file: clamav-milter.conf --- LogFile = /var/log/clamav/clamav-milter.log LogFileUnlock disabled LogFileMaxSize = 1048576 LogTime = yes LogSyslog disabled LogFacility = LOG_LOCAL6 LogVerbose disabled LogRotate = yes PidFile = /var/run/clamav/clamav-milter.pid TemporaryDirectory = /tmp FixStaleSocket = yes MaxThreads = 10 ReadTimeout = 120 Foreground disabled User = clamav AllowSupplementaryGroups = yes MaxFileSize = 26214400 ClamdSocket = unix:/var/run/clamav/clamd.ctl MilterSocket = /var/run/clamav/clamav-milter.ctl MilterSocketGroup = clamav MilterSocketMode = 666 LocalNet disabled OnClean = Accept OnInfected = Quarantine OnFail = Defer RejectMsg disabled AddHeader = Replace ReportHostname disabled VirusAction disabled Chroot disabled Whitelist disabled SkipAuthenticated disabled LogInfected = Off LogClean = Off SupportMultipleRecipients disabled Software settings - Version: 0.98.4 Optional features supported: MEMPOOL IPv6 FRESHCLAM_DNS_FIX AUTOIT_EA06 BZIP2 JIT Database information Database directory: /var/lib/clamav daily.cvd: version 19318, sigs:
Bug#760223: /etc/init.d/dovecot: Use of --name $DAEMON in start-stop-daemon for stop/restart causes failure to stop/restart in certain virtualized environments
Package: dovecot-core
Version: 1:2.1.7-7+deb7u1
Severity: normal
File: /etc/init.d/dovecot
The use of --name $DAEMON in start-stop-daemon commands for
stopping/restarting/reloading daemon results
in failures to a) install (due to failure of initscript) and b) failure to
stop/restart/reload daemon
when process names are not available due to limited /proc such as when running
debian/kfreebsd-amd64
in a freebsd jail (some other virtualized environments apparently experience
the same issue also
due to limited /proc).
linprocfs is mounted however /proc is not completely availabe for security
reasons.
Dropping --name $DAEMON and relying solely on $PIDFILE solves the issue
-- Package-specific info:
dovecot configuration
-
# 2.1.7: /etc/dovecot/dovecot.conf
# OS: GNU/kFreeBSD 9.2-RELEASE-p9 x86_64
mail_location = mbox:~/mail:INBOX=/var/mail/%u
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character
vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy
include variables body enotify environment mailbox date ihave
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox Sent Messages {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix =
}
passdb {
driver = pam
}
plugin {
sieve = ~/.dovecot.sieve
sieve_dir = ~/sieve
}
protocols = imap lmtp sieve
service imap-login {
inet_listener imap {
address = 192.168.153.36
}
inet_listener imaps {
address = 192.168.153.36
}
}
service pop3-login {
inet_listener pop3 {
address = 192.168.153.36
}
inet_listener pop3s {
address = 192.168.153.36
}
}
ssl_cert = /etc/dovecot/dovecot.pem
ssl_key = /etc/dovecot/private/dovecot.pem
userdb {
driver = passwd
}
-- System Information:
Debian Release: 7.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 9.2-RELEASE-p9
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages dovecot-core depends on:
ii adduser 3.113+nmu3
ii libbz2-1.0 1.0.6-4
ii libc0.1 2.13-38+deb7u4
ii libpam-runtime 1.1.3-7.1
ii libpam0g1.1.3-7.1
ii libssl1.0.0 1.0.1e-2+deb7u12
ii openssl 1.0.1e-2+deb7u12
ii ucf 3.0025+nmu3
ii zlib1g 1:1.2.7.dfsg-13
dovecot-core recommends no packages.
Versions of packages dovecot-core suggests:
pn dovecot-gssapinone
ii dovecot-imapd 1:2.1.7-7+deb7u1
pn dovecot-ldap none
ii dovecot-lmtpd 1:2.1.7-7+deb7u1
ii dovecot-managesieved 1:2.1.7-7+deb7u1
pn dovecot-mysql none
ii dovecot-pgsql 1:2.1.7-7+deb7u1
pn dovecot-pop3d none
ii dovecot-sieve 1:2.1.7-7+deb7u1
pn dovecot-solr none
pn dovecot-sqlitenone
ii ntp 1:4.2.6.p5+dfsg-2
Versions of packages dovecot-core is related to:
ii dovecot-core [dovecot-common] 1:2.1.7-7+deb7u1
pn dovecot-dbgnone
pn dovecot-devnone
pn dovecot-gssapi none
ii dovecot-imapd 1:2.1.7-7+deb7u1
pn dovecot-ldap none
ii dovecot-lmtpd 1:2.1.7-7+deb7u1
ii dovecot-managesieved 1:2.1.7-7+deb7u1
pn dovecot-mysql none
ii dovecot-pgsql 1:2.1.7-7+deb7u1
pn dovecot-pop3d none
ii dovecot-sieve 1:2.1.7-7+deb7u1
pn dovecot-sqlite none
-- Configuration Files:
/etc/init.d/dovecot changed:
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DESC=IMAP/POP3 mail server
NAME=dovecot
DAEMON=/usr/sbin/dovecot
DAEMON_ARGS=
SCRIPTNAME=/etc/init.d/$NAME
CONF=/etc/dovecot/${NAME}.conf
[ -r /etc/default/$NAME ] . /etc/default/$NAME
[ -x $DAEMON ] || exit 0
[ -f $CONF ] || exit 0
[ $ENABLED != 0 ] || exit 0
[ $ALLOW_COREDUMPS != 1 ] || ulimit -c unlimited
.. /lib/lsb/init-functions
if [ ! -r ${CONF} ]; then
log_daemon_msg ${CONF}: not readable $NAME log_end_msg 1;
exit 1;
fi
if [ -f /etc/inetd.conf ]; then
# The init script should do nothing if dovecot or another imap/pop3 server
# is being run from inetd, and dovecot is configured to run as an imap or
# pop3 service
for p in `sed -r s/^ *(([^:]+|\[[^]]+]|\*):)?(pop3s?|imaps?)[ \t].*/\3/;t;d
\
/etc/inetd.conf`
do
for q in `doveconf -n -h protocols`
do
if [ $p = $q ]; then
log_daemon_msg protocol ${p} configured both in inetd and in dovecot
$NAME log_end_msg 1
exit 0
fi
done
done
fi
PIDBASE=${PIDBASE:-`doveconf -n -c ${CONF} -h base_dir`}
PIDFILE=${PIDBASE:-/var/run/dovecot}/master.pid
do_start()
{
# Return
# 0 if daemon has been started
#
Bug#760225: /etc/init.d/nfsiod: Reliance on --name $DAEMON in start-stop-daemon stop/restart causes failure inside freebsd jails
Package: freebsd-nfs-common
Version: 9.0+ds1-11~deb7u1
Severity: normal
File: /etc/init.d/nfsiod
Use of --name $DAEMON in start-stop-daemon start/stop/reload causes those
functions of the initscript
to fail when inside a freebsd jail due to limited /proc for which process names
are not avaiable.
Relying solely on PIDFILE resolves this issue.
This is with linprocfs mounted BTW.
-- System Information:
Debian Release: 7.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 9.2-RELEASE-p9
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages freebsd-nfs-common depends on:
ii libbsd00.4.2-1
ii libc0.12.13-38+deb7u4
ii libtirpc1 0.2.2-5
ii rpcbind0.2.0-8
freebsd-nfs-common recommends no packages.
freebsd-nfs-common suggests no packages.
-- Configuration Files:
/etc/init.d/nfsiod changed:
PATH=/sbin:/bin
DESC=local NFS asynchronous I/O server
NAME=nfsiod
DAEMON=/sbin/nfsiod
DAEMON_ARGS=
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
[ -x $DAEMON ] || exit 0
[ -r /etc/default/$NAME ] . /etc/default/$NAME
.. /lib/init/vars.sh
.. /lib/lsb/init-functions
do_start()
{
# Return
# 0 if daemon has been started
# 1 if daemon was already running
# 2 if daemon could not be started
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON
--test /dev/null \
|| return 1
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
$DAEMON_ARGS \
|| return 2
# Add code here, if necessary, that waits for the process to be ready
# to handle requests from services started subsequently which depend
# on this one. As a last resort, sleep for some time.
}
do_stop()
{
# Return
# 0 if daemon has been stopped
# 1 if daemon was already stopped
# 2 if daemon could not be stopped
# other if a failure occurred
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile
$PIDFILE
RETVAL=$?
[ $RETVAL = 2 ] return 2
# Wait for children to finish too if this is a daemon that forks
# and if the daemon is only ever run from this initscript.
# If the above conditions are not satisfied then add some other code
# that waits for the process to drop all resources that could be
# needed by services started subsequently. A last resort is to
# sleep for some time.
start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec
$DAEMON
[ $? = 2 ] return 2
# Many daemons don't delete their pidfiles when they exit.
rm -f $PIDFILE
return $RETVAL
}
case $1 in
start)
log_daemon_msg Starting $DESC $NAME
do_start
case $? in
0|1) log_end_msg 0 ;;
2) log_end_msg 1 ;;
esac
;;
stop)
log_daemon_msg Stopping $DESC $NAME
do_stop
case $? in
0|1) log_end_msg 0 ;;
2) log_end_msg 1 ;;
esac
;;
status)
status_of_proc $DAEMON $NAME exit 0 || exit $?
;;
restart|force-reload)
#
# If the reload option is implemented then remove the
# 'force-reload' alias
#
log_daemon_msg Restarting $DESC $NAME
do_stop
case $? in
0|1)
do_start
case $? in
0) log_end_msg 0 ;;
1) log_end_msg 1 ;; # Old process is still running
*) log_end_msg 1 ;; # Failed to start
esac
;;
*)
# Failed to stop
log_end_msg 1
;;
esac
;;
*)
echo Usage: $SCRIPTNAME {start|stop|status|restart|force-reload} 2
exit 3
;;
esac
:
-- 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#759776: xfce4-session: recommends xscreensaver but that has 'won't fix' bug against power manager
Package: xfce4-session Version: 4.10.1-8 Severity: normal xcfe4-session still recommends xscreensaver despite that fact that for years xscreensaver has prevented (even with DPMS settings turned off) prevented xfce's power manager from shutting of the display or going into sleep mode due to taking over the xidle timer. xscreensaver's maintainer, in a bug about this, has expressed his opinion that it's not a bug and he has no intention of fixing it. Therefore xscreensaver is broken for xfce and should be replace, perhaps by light-locker now that it is avialable. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xfce4-session depends on: ii libatk1.0-02.12.0-1 ii libc6 2.19-9 ii libcairo2 1.12.16-2 ii libdbus-1-31.8.6-2 ii libdbus-glib-1-2 0.102-1 ii libfontconfig1 2.11.0-6 ii libfreetype6 2.5.2-1.1 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libglib2.0-0 2.40.0-4 ii libgtk2.0-02.24.24-1 ii libice62:1.0.9-1 ii libpango-1.0-0 1.36.6-1 ii libpangocairo-1.0-01.36.6-1 ii libpangoft2-1.0-0 1.36.6-1 ii libpolkit-gobject-1-0 0.105-6.1 ii libsm6 2:1.2.2-1 ii libwnck22 2.30.7-1 ii libx11-6 2:1.6.2-3 ii libxfce4ui-1-0 4.10.0-5 ii libxfce4util6 4.10.1-1 ii libxfconf-0-2 4.10.0-2 ii multiarch-support 2.19-9 ii xfce4-settings 4.10.1-2 ii xfconf 4.10.0-2 Versions of packages xfce4-session recommends: ii dbus-x11 1.8.6-2 ii libpam-systemd 208-8 ii systemd-sysv 208-8 ii upower 0.99.0-3 ii x11-xserver-utils 7.7+3 ii xfdesktop4 4.10.2-3 ii xfwm4 4.10.1-2 ii xscreensaver 5.26-1 Versions of packages xfce4-session suggests: pn fortunes-mod none ii sudo 1.8.9p5-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759768: xfce4-settings: Desktop fails to display backgrounds images on dual head displays
Package: xfce4-settings Version: 4.10.1-2 Severity: normal With a dual head system setting desktop backgrounds to image lists that are supposed to change every minutes results in both displays having only grey background. Gnome has a similar problem with backgrounds on dual head - perhaps there is some common thing that is a problem for both? -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xfce4-settings depends on: ii libc6 2.19-9 ii libcairo2 1.12.16-2 ii libdbus-1-3 1.8.6-2 ii libdbus-glib-1-20.102-1 ii libexo-1-0 0.10.2-3 ii libfontconfig1 2.11.0-6 ii libgarcon-1-0 0.2.1-1 ii libgarcon-common0.2.1-1 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libglib2.0-02.40.0-4 ii libgtk2.0-0 2.24.24-1 ii libnotify4 0.7.6-2 ii libpango-1.0-0 1.36.6-1 ii libx11-62:1.6.2-3 ii libxcursor1 1:1.1.14-1 ii libxfce4ui-1-0 4.10.0-5 ii libxfce4util6 4.10.1-1 ii libxfconf-0-2 4.10.0-2 ii libxi6 2:1.7.4-1 ii libxklavier16 5.2.1-1 ii libxrandr2 2:1.4.2-1 ii xfconf 4.10.0-2 Versions of packages xfce4-settings recommends: ii x11-utils 7.7+2 ii xfce4-volumed 0.1.13-5 xfce4-settings 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#758598: libvirt-bin: isolated network fails to start due to xtables lock
Package: libvirt-bin Version: 1.2.4-3.2 Severity: normal I observed that libvirt-bin's networks failed to autostart despite being so configure and when I attempted to manually (via virsh) start the network I got: error: Failed to start network vmpriv error: internal error: Failed to apply firewall rules /sbin/iptables --table filter --insert INPUT --in-interface virbr1 --protocol tcp --destination-port 67 --jump ACCEPT: Another app is currently holding the xtables lock. Perhaps you want to use the -w option? After some time virsh is able to start the network but it appears that is another process does firewall work (e.g. firewall is slow to start), then virsh fails to start network due to the new xtables locking mechanism and failure of libvirt to use the -w (wait) option. Regards, Daniel -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libvirt-bin depends on: ii adduser 3.113+nmu3 ii gettext-base 0.19.2-1 ii init-system-helpers 1.20 ii libapparmor1 2.8.0-5.1+b1 ii libaudit11:2.3.7-1 ii libavahi-client3 0.6.31-4 ii libavahi-common3 0.6.31-4 ii libblkid12.20.1-5.8 ii libc62.19-7 ii libcap-ng0 0.7.3-1.1 ii libdbus-1-3 1.8.6-1 ii libdevmapper1.02.1 2:1.02.85-2 ii libfuse2 2.9.3-15 ii libgnutls-deb0-283.2.16-1 ii libnetcf11:0.2.3-4 ii libnl-3-200 3.2.24-2 ii libnl-route-3-2003.2.24-2 ii libnuma1 2.0.9-1 ii libparted2 3.2-4 ii libpcap0.8 1.6.1-1 ii libpciaccess00.13.2-3 ii librados20.80.5-1 ii librbd1 0.80.5-1 ii libreadline6 6.3-8 ii libsasl2-2 2.1.26.dfsg1-11 ii libselinux1 2.3-1 ii libssh2-11.4.3-3 ii libsystemd-daemon0 208-6 ii libudev1 208-6 ii libvirt0 1.2.4-3.2 ii libxen-4.3 4.3.0-3+b1 ii libxenstore3.0 4.3.0-3+b1 ii libxml2 2.9.1+dfsg1-4 ii libyajl2 2.1.0-1 ii logrotate3.8.7-1 Versions of packages libvirt-bin recommends: ii bridge-utils1.5-9 ii dmidecode 2.12-3 ii dnsmasq-base2.71-1 ii ebtables2.0.10.4-3 ii iproute 1:3.16.0-1 ii iptables1.4.21-2 ii libxml2-utils 2.9.1+dfsg1-4 ii netcat-openbsd 1.105-7 ii parted 3.2-4 ii pm-utils1.4.1-15 ii qemu2.1+dfsg-2 ii qemu-kvm2.1+dfsg-2 Versions of packages libvirt-bin suggests: pn apparmor none pn auditd none ii policykit-1 0.105-6.1 ii radvd1:1.9.1-1.3 ii systemd 208-6 pn systemtapnone -- Configuration Files: /etc/default/libvirt-guests changed [not included] /etc/init.d/libvirt-guests changed [not included] /etc/libvirt/qemu.conf [Errno 13] Permission denied: u'/etc/libvirt/qemu.conf' -- 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#756885: Wrong arg count harmless
Note that the id mapping issue is not actually caused by the wrong arg count. The wrong arg count appears to be harmless (no effect). The id mapping was failing because the nfs server being accessed was in fact using the wrong domain name. Regards, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757065: smart-notifier: Single degree in temperature should be supressable (i.e. not sufficient to trigger notification)
Package: smart-notifier Version: 0.28-5 Severity: wishlist I got a notice of drive health change which I tracked down in the syslog to single degree increase in temperature. That's a little too paranoid for me. I'd like to be able to skip single degree temperature (there's that much variation depending on load and ambient temperature changes and in fact today in Ontario it was probably the change in ambient temperature that did it. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages smart-notifier depends on: ii dbus1.8.6-1 ii gir1.2-gtk-3.0 3.12.2-1+b1 ii python 2.7.8-1 ii python-dbus 1.2.0-2+b3 ii smartmontools 6.2+svn3841-1.2 smart-notifier recommends no packages. smart-notifier 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#757070: gnome-control-center: Time change desktop background doesn't change
Package: gnome-control-center Version: 1:3.12.1-4 Severity: minor The advertised functionality of the default background (changes to a different background periodically) is not present, at least with dual monitor setup. That is the background just stays on the same shades of green geometric background that is the default always instead of periodically cycling through backgrounds despite what the labels and tool tips say. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-control-center depends on: ii accountsservice0.6.37-2 ii apg2.2.3.dfsg.1-2 ii colord 1.2.1-1 ii desktop-file-utils 0.22-1 ii gnome-control-center-data 1:3.12.1-4 ii gnome-desktop3-data3.12.2-2 ii gnome-icon-theme 3.12.0-1 ii gnome-icon-theme-symbolic 3.12.0-1 ii gnome-menus3.8.0-2 ii gnome-settings-daemon 3.12.2-1 ii gsettings-desktop-schemas 3.12.2-1 ii libaccountsservice00.6.37-2 ii libatk1.0-02.12.0-1 ii libc6 2.19-7 ii libcairo2 1.12.16-2 ii libcanberra-gtk3-0 0.30-2 ii libcanberra0 0.30-2 ii libcheese-gtk233.12.2-1 ii libcheese7 3.12.2-1 ii libclutter-1.0-0 1.18.2-2 ii libclutter-gtk-1.0-0 1.5.2-2 ii libcolord-gtk1 0.1.25-1.1+b1 ii libcolord2 1.2.1-1 ii libcups2 1.7.4-1 ii libdbus-glib-1-2 0.102-1 ii libfontconfig1 2.11.0-5 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libgl1-mesa-glx [libgl1] 10.2.4-1 ii libglib2.0-0 2.40.0-3 ii libgnome-bluetooth13 3.12.0-5 ii libgnome-desktop-3-10 3.12.2-2 ii libgoa-1.0-0b 3.12.2-1 ii libgoa-backend-1.0-1 3.12.2-1 ii libgrilo-0.2-1 0.2.10-1 ii libgtk-3-0 3.12.2-1+b1 ii libgtop2-7 2.28.5-2 ii libibus-1.0-5 1.5.7-1 ii libkrb5-3 1.12.1+dfsg-5 ii libmm-glib01.2.0-1 ii libnm-glib-vpn10.9.10.0-1 ii libnm-glib40.9.10.0-1 ii libnm-gtk0 0.9.10.0-2 ii libnm-util20.9.10.0-1 ii libpango-1.0-0 1.36.3-1 ii libpangocairo-1.0-01.36.3-1 ii libpolkit-gobject-1-0 0.105-6.1 ii libpulse-mainloop-glib05.0-2 ii libpulse0 5.0-2 ii libpwquality1 1.2.3-1 ii libsmbclient 2:4.1.9+dfsg-2 ii libsoup2.4-1 2.46.0-2 ii libupower-glib20.99.0-3 ii libwacom2 0.8-1 ii libx11-6 2:1.6.2-2 ii libxi6 2:1.7.4-1 ii libxml22.9.1+dfsg1-4 Versions of packages gnome-control-center recommends: ii cups-pk-helper 0.2.5-2 ii gkbd-capplet 3.6.0-1 ii gnome-online-accounts 3.12.2-1 ii gnome-user-guide 3.12.2-1 ii gnome-user-share 3.8.3-1 ii iso-codes 3.55-1 pn libnss-myhostname none ii mesa-utils 8.2.0-1 ii mousetweaks3.12.0-1 ii network-manager-gnome 0.9.10.0-2 ii ntp1:4.2.6.p5+dfsg-3 ii policykit-1-gnome 0.105-2 ii realmd 0.15.1-1 ii rygel 0.22.2-2 ii rygel-tracker 0.22.2-2 ii system-config-printer 1.4.3-4 Versions of packages gnome-control-center suggests: ii gstreamer1.0-pulseaudio 1.4.0-1 ii libcanberra-gtk-module 0.30-2 ii libcanberra-gtk3-module 0.30-2 ii x11-xserver-utils7.7+3 -- 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#757071: gnome-control-center: Fails to change background of both monitors on dual monitor setup
Package: gnome-control-center Version: 1:3.12.1-4 Severity: normal Right-clicking change background and selecting a background only affects the primary monitor at least when you have manually selected what is by default the secondary monitor as the primary monitor. Right-clicking on the secondary monitor (by default the primary) and selecting change background changes the primary (which is by default the secondary monitor) monitor's background, and so do right-clickingon the primary (by default secondary) monitor. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-control-center depends on: ii accountsservice0.6.37-2 ii apg2.2.3.dfsg.1-2 ii colord 1.2.1-1 ii desktop-file-utils 0.22-1 ii gnome-control-center-data 1:3.12.1-4 ii gnome-desktop3-data3.12.2-2 ii gnome-icon-theme 3.12.0-1 ii gnome-icon-theme-symbolic 3.12.0-1 ii gnome-menus3.8.0-2 ii gnome-settings-daemon 3.12.2-1 ii gsettings-desktop-schemas 3.12.2-1 ii libaccountsservice00.6.37-2 ii libatk1.0-02.12.0-1 ii libc6 2.19-7 ii libcairo2 1.12.16-2 ii libcanberra-gtk3-0 0.30-2 ii libcanberra0 0.30-2 ii libcheese-gtk233.12.2-1 ii libcheese7 3.12.2-1 ii libclutter-1.0-0 1.18.2-2 ii libclutter-gtk-1.0-0 1.5.2-2 ii libcolord-gtk1 0.1.25-1.1+b1 ii libcolord2 1.2.1-1 ii libcups2 1.7.4-1 ii libdbus-glib-1-2 0.102-1 ii libfontconfig1 2.11.0-5 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libgl1-mesa-glx [libgl1] 10.2.4-1 ii libglib2.0-0 2.40.0-3 ii libgnome-bluetooth13 3.12.0-5 ii libgnome-desktop-3-10 3.12.2-2 ii libgoa-1.0-0b 3.12.2-1 ii libgoa-backend-1.0-1 3.12.2-1 ii libgrilo-0.2-1 0.2.10-1 ii libgtk-3-0 3.12.2-1+b1 ii libgtop2-7 2.28.5-2 ii libibus-1.0-5 1.5.7-1 ii libkrb5-3 1.12.1+dfsg-5 ii libmm-glib01.2.0-1 ii libnm-glib-vpn10.9.10.0-1 ii libnm-glib40.9.10.0-1 ii libnm-gtk0 0.9.10.0-2 ii libnm-util20.9.10.0-1 ii libpango-1.0-0 1.36.3-1 ii libpangocairo-1.0-01.36.3-1 ii libpolkit-gobject-1-0 0.105-6.1 ii libpulse-mainloop-glib05.0-2 ii libpulse0 5.0-2 ii libpwquality1 1.2.3-1 ii libsmbclient 2:4.1.9+dfsg-2 ii libsoup2.4-1 2.46.0-2 ii libupower-glib20.99.0-3 ii libwacom2 0.8-1 ii libx11-6 2:1.6.2-2 ii libxi6 2:1.7.4-1 ii libxml22.9.1+dfsg1-4 Versions of packages gnome-control-center recommends: ii cups-pk-helper 0.2.5-2 ii gkbd-capplet 3.6.0-1 ii gnome-online-accounts 3.12.2-1 ii gnome-user-guide 3.12.2-1 ii gnome-user-share 3.8.3-1 ii iso-codes 3.55-1 pn libnss-myhostname none ii mesa-utils 8.2.0-1 ii mousetweaks3.12.0-1 ii network-manager-gnome 0.9.10.0-2 ii ntp1:4.2.6.p5+dfsg-3 ii policykit-1-gnome 0.105-2 ii realmd 0.15.1-1 ii rygel 0.22.2-2 ii rygel-tracker 0.22.2-2 ii system-config-printer 1.4.3-4 Versions of packages gnome-control-center suggests: ii gstreamer1.0-pulseaudio 1.4.0-1 ii libcanberra-gtk-module 0.30-2 ii libcanberra-gtk3-module 0.30-2 ii x11-xserver-utils7.7+3 -- 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#756885: nfsidmap: request-key command line wrong arg count
Package: nfs-common Version: 1:1.2.8-6 Severity: normal idmapd does not work (fails to use correct domain depsite configure in idmap.conf) because /etc/request-key.d/id_resolver.conf has incorrect number of arguments. Syslog says: Aug 2 22:19:04 host nfsidmap[29796]: Bad arg count. Check /etc/request-key.conf Aug 2 22:20:19 host nfsidmap[32515]: nss_getpwnam: name 'root@local' does not map into domain 'domain' d And no host and domain are not the actual host and domain. -- Package-specific info: -- rpcinfo -- program vers proto port service 104 tcp111 portmapper 103 tcp111 portmapper 102 tcp111 portmapper 104 udp111 portmapper 103 udp111 portmapper 102 udp111 portmapper 1000241 udp 34716 status 1000241 tcp 42067 status 1000211 udp 40190 nlockmgr 1000213 udp 40190 nlockmgr 1000214 udp 40190 nlockmgr 1000211 tcp 51570 nlockmgr 1000213 tcp 51570 nlockmgr 1000214 tcp 51570 nlockmgr -- /etc/default/nfs-common -- NEED_STATD=no STATDOPTS= NEED_IDMAPD=yes NEED_GSSD=no -- /etc/idmapd.conf -- [General] Verbosity = 0 Pipefs-Directory = /run/rpc_pipefs Domain = domain [Mapping] Nobody-User = nobody Nobody-Group = nogroup -- /etc/fstab -- sniponly relevant bit is sec=sys -- /proc/mounts -- [no relavant bits] -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nfs-common depends on: ii adduser 3.113+nmu3 ii initscripts 2.88dsf-53.2 ii libc6 2.19-7 ii libcap2 1:2.24-3 ii libcomerr2 1.42.11-2 ii libdevmapper1.02.1 2:1.02.85-2 ii libevent-2.0-5 2.0.21-stable-1 ii libgssglue1 0.4-2 ii libk5crypto31.12.1+dfsg-5 ii libkeyutils11.5.9-4 ii libkrb5-3 1.12.1+dfsg-5 ii libmount1 2.20.1-5.8 ii libnfsidmap20.25-5 ii libtirpc1 0.2.3-2 ii libwrap07.6.q-25 ii lsb-base4.1+Debian13 ii rpcbind 0.2.1-4 ii ucf 3.0030 Versions of packages nfs-common recommends: ii python 2.7.8-1 Versions of packages nfs-common suggests: pn open-iscsi none pn watchdognone -- Configuration Files: /etc/default/nfs-common changed [not included] -- 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#756889: openocd: USB 0403:6001 incorrectly assigned to plugdev; is FTDI serial converter
Package: openocd Version: 0.7.0-2 Severity: normal Product:Vendor 0403:6001 is incorrectly assigned to plugdev by openocd udev rules. This is in fact a generic FTDI serial convert product:vendor and as such should be assigned to 'dialout' as with all other ttyUSB devices. In openOCD it is listed as a 'Caloa Systems USB-A9260-C02 Bus Pirate' because apparently that particuly device maker neglected to use their own product:vendor numbers. Regards, Daniel -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages openocd depends on: ii libc6 2.19-7 ii libftdi1 0.20-1+b2 ii libusb-0.1-4 2:0.1.12-24 ii libusb-1.0-0 2:1.0.19-1 openocd recommends no packages. openocd 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#756224: libnss-myhostname: Causes apps that need FQDN to fail
Fair enough, but the argument seems to consist of 'if you don't obey the rules bad behaviour results, ergo the rule is bad' which is kind of like arguing that making people obey the law is bad because some people got to jail. Basically the arguments are political not technical, even if it is dressed up as technical, which is why the arguments end up being political. Regards, Daniel On 29/07/14 03:22 AM, Joachim Breitner wrote: Hi, Am Dienstag, den 29.07.2014, 00:22 -0400 schrieb Daniel Dickinson: Yeah but the guy claiming FQDN broken is the same Lennart who seems hell bent on destroying every *nix idiom. I wouldn't go by his opinion. and I won’t discuss technical issues on this level. Greetings, Joachim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
Here is a specific for-instance: Evolution does not send a FQDN in EHLO unless it has an FQDN. Postfix for example is generally configured to require an FQDN from email sender (as a spam prevention measure). Therefore sending mail from Evolution via a reasonably configured Postfix fails with libnss-myhostname. Regards, Daniel On Sun, 2014-07-27 at 20:25 +0200, Joachim Breitner wrote: Hi, Am Sonntag, den 27.07.2014, 13:53 -0400 schrieb Daniel Dickinson: Package: libnss-myhostname Version: 0.3-6 Severity: serious Takes over names resolution of local host's name and causes apps that need FQDN instead of just hostname to fail (becuase myhostname fails to include a domain). Can you explain the problems in more detai: What programs are affected? What precisely do these program look up, what do they expect, and what do they get with libnss-myhostname? Did they previously work out-of-the box without libnss-myhostname and an unmodified /etc/hosts, or did you have to modify /etc/hosts (i.e. add the FQDN there)? If so, what happens if you still add them to /etc/hosts? Greetings, Joachim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
Might I add that even Winblows systems that are attached to a network with DHCP-supplied domain name (or which are configured manually with a domain name and use static addresses) have FQDN's The only things that don't have FQDN on normal networks are link-local networks and brokenly configured *nix systems (or systems not actually on a network). Also there seems to be some trouble so at risk of repeating mysql: Evolution fails to send FQDN in EHLO to SMTP server when using libnss-hostname. This break SMTP to sites that require FQDN (which is a common spam prevention measure). Regards, Daniel On Sun, 2014-07-27 at 20:25 +0200, Joachim Breitner wrote: Hi, Am Sonntag, den 27.07.2014, 13:53 -0400 schrieb Daniel Dickinson: Package: libnss-myhostname Version: 0.3-6 Severity: serious Takes over names resolution of local host's name and causes apps that need FQDN instead of just hostname to fail (becuase myhostname fails to include a domain). Can you explain the problems in more detai: What programs are affected? What precisely do these program look up, what do they expect, and what do they get with libnss-myhostname? Did they previously work out-of-the box without libnss-myhostname and an unmodified /etc/hosts, or did you have to modify /etc/hosts (i.e. add the FQDN there)? If so, what happens if you still add them to /etc/hosts? Greetings, Joachim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
Please note there are other 'basic networking type apps (which is what I consider email/postfix)' that break without FQDN I just cannot remember the details since at the time I was more concerned with getting my network behaving and I thought libnss-myhostname was a fringe project that sounded good but wasn't worth pursuing or spending time on because of the issues that became readily apparent. I guess it's not as fringe as I thought and should have filed bug reports then. On Sun, 2014-07-27 at 20:25 +0200, Joachim Breitner wrote: Hi, Am Sonntag, den 27.07.2014, 13:53 -0400 schrieb Daniel Dickinson: Package: libnss-myhostname Version: 0.3-6 Severity: serious Takes over names resolution of local host's name and causes apps that need FQDN instead of just hostname to fail (becuase myhostname fails to include a domain). Can you explain the problems in more detai: What programs are affected? What precisely do these program look up, what do they expect, and what do they get with libnss-myhostname? Did they previously work out-of-the box without libnss-myhostname and an unmodified /etc/hosts, or did you have to modify /etc/hosts (i.e. add the FQDN there)? If so, what happens if you still add them to /etc/hosts? Greetings, Joachim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
On 27/07/14 02:25 PM, Joachim Breitner wrote: Hi, Am Sonntag, den 27.07.2014, 13:53 -0400 schrieb Daniel Dickinson: Package: libnss-myhostname Version: 0.3-6 Severity: serious Takes over names resolution of local host's name and causes apps that need FQDN instead of just hostname to fail (becuase myhostname fails to include a domain). Can you explain the problems in more detai: What programs are affected? I don't remember exactly which ones they were; there were a few and it was a hard to debug problem. I think one of them may have been amanda. I ditched libnss-hostname which I was installing myself sometime ago because of this issue. What precisely do these program look up, what do they expect, and what do they get with libnss-myhostname? They look up a hostname using glibc. You can get the same result by doing hostname --fqdn and observing that there is no domain part to returned hostname. THIS IS BROKEN. --fqdn should *always* have a domain part. Did they previously work out-of-the box without libnss-myhostname and an unmodified /etc/hosts, or did you have to modify /etc/hosts (i.e. add the FQDN there)? They worked out-of-the box without libnss-myhostname, with the DNS setup I had. If so, what happens if you still add them to /etc/hosts? It is actually the local hostname that is the issue and I have actually tried modifying /etc/hosts with ip-address name.domain name however hostname --fqdn *still* returns name with NO domain. libnss-hostname is BROKEN WRT to FQDN. Regards, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
Yeah but the guy claiming FQDN broken is the same Lennart who seems hell bent on destroying every *nix idiom. I wouldn't go by his opinion. Regards, Daniel On 28/07/14 09:40 AM, Joachim Breitner wrote: Hi, Am Montag, den 28.07.2014, 09:21 -0400 schrieb Daniel Dickinson: On 27/07/14 02:25 PM, Joachim Breitner wrote: They look up a hostname using glibc. You can get the same result by doing hostname --fqdn and observing that there is no domain part to returned hostname. THIS IS BROKEN. --fqdn should *always* have a domain part. Thanks. I can reproduce it here. It is actually the local hostname that is the issue and I have actually tried modifying /etc/hosts with ip-address name.domain name however hostname --fqdn *still* returns name with NO domain. libnss-hostname is BROKEN WRT to FQDN. Unfortunately, the upstream author believes that programs expecting a fully qualified domain names to exist are broken. So I guess we should add a conflicts to affected packages. If this causes problems with other packages depending on libnss-hostname, then maybe the dependency needs to be revisited. BTW, what should the FQDN even be here? My laptop doesn’t have a FQDN that resolves to it, so the concept seems to be dubious at least. Related references: https://bugzilla.redhat.com/show_bug.cgi?id=726054 Greetings, Joachim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
Package: libnss-myhostname Version: 0.3-6 Severity: serious Takes over names resolution of local host's name and causes apps that need FQDN instead of just hostname to fail (becuase myhostname fails to include a domain). This is now pulled in by Gnome which means it's bad behviour will break a lot of people -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libnss-myhostname depends on: ii libc6 2.19-7 ii multiarch-support 2.19-7 libnss-myhostname recommends no packages. libnss-myhostname 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#755750: [Pkg-telepathy-maintainers] Bug#755750: empathy: Missing menu in 'Contacts List'; incorrect application of Unity-specific change?
On 23/07/14 05:53 AM, Simon McVittie wrote: On 23/07/14 00:06, Daniel Dickinson wrote: There is no way to perform actions previously performed from the 'Contact List' menu because the top menu bar no longer displays. Are you using GNOME Shell? If you are, the application menu for application-wide things has moved to the top bar, between Activities and the clock. Ah, ok, I was looking in the wrong spot (I was unaware of this change but did look for an menu, but on the opposite side of the top bar, by the tray) This is a case of design changing and my not knowing the new design, so not a operational bug, but more of a problem of changing things for old users without telling them in a sufficiently visible way issue (if it's is the changelog or 'news' that's not particularly helpful when doing an upgrade from wheezy to jessie due to the sheer volume of changes that get reported by e.g. apt-listchanges). Regards, Daniel If not, what desktop environment are you using? The menu is meant to appear in the Contact List window under desktops not resembling GNOME Shell or Unity. Do other GNOME applications with only one menu have a similar issue? (gucharmap makes a good simple example) This is perhaps because of incorrect application of changes from Ubuntu for Unity (where the menus appear in the top bar instead of in individual application menus) GNOME 3.x (for sufficiently large values of x) has an analogous design: application-wide menu items move to the application menu in the Shell, window- or document-oriented menu items stay in the window. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755387: [Pkg-libvirt-maintainers] Bug#755387: libvirt-bin: Wheezy guest doesn't ACPI power button events
I'll try to get some time to do some debugging. The strange thing is that a freshly installed wheezy guest has no problem, so it's really only this one guest that is having issues, for no apparent reason. What's really weird part is that I'm not aware of having made any changes to that guest that should be remotely relevant. Regards, Daniel On 21/07/14 03:19 AM, Guido Günther wrote: On Sun, Jul 20, 2014 at 04:19:27AM -0400, Daniel Dickinson wrote: Package: libvirt-bin Version: 1.2.4-3 Severity: normal I have a Wheezy guest I can't shutdown cleanly from libvirt (i.e. without logging into VM and shutting down VM from within VM) because the guest is failing to get ACPI events. The guest didn't have issues before jessie (i.e. while on Wheezy) and does have acpid and I've even tried adding acpi-support to no avail. acpi is enabled as a feature in the XML. The strange thing is a Windows 8.1 guest is not having issues with this (it was created around the same time as the wheezy guest, while host was on wheezy). The command line generated by libvirt is: LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -name name -S -machine pc-1.1,accel=kvm,usb=off -m 256 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid uuid -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/name.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot order=cd,menu=on,strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=image,if=none,id=drive-virtio-disk0,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 -netdev tap,fd=25,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=mac,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-se r ia l,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:1 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 Neither libvirt nor the guest produce any logs as result of issuing the shutdown command from virt-manageer or virsh. Check https://wiki.debian.org/libvirt/Debugging to get more logs. I don't have any issues shuting down wheezy guests.. Cheers, -- Guido -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libvirt-bin depends on: ii adduser 3.113+nmu3 ii gettext-base 0.18.3.2-3 ii init-system-helpers 1.19 ii libapparmor1 2.8.0-5.1+b1 ii libaudit11:2.3.7-1 ii libavahi-client3 0.6.31-4 ii libavahi-common3 0.6.31-4 ii libblkid12.20.1-5.8 ii libc62.19-7 ii libcap-ng0 0.7.3-1.1 ii libdbus-1-3 1.8.6-1 ii libdevmapper1.02.1 2:1.02.85-2 ii libfuse2 2.9.3-12 ii libgcrypt11 1.5.3-4 ii libgnutls26 2.12.23-17 ii libnetcf11:0.2.3-4 ii libnl-3-200 3.2.24-2 ii libnl-route-3-2003.2.24-2 ii libnuma1 2.0.9-1 ii libparted0debian12.3-20 ii libpcap0.8 1.5.3-4 ii libpciaccess00.13.2-3 ii librados20.80.1-2 ii librbd1 0.80.1-2 ii libreadline6 6.3-6 ii libsasl2-2 2.1.26.dfsg1-11 ii libselinux1 2.3-1 ii libssh2-11.4.3-3 ii libsystemd-daemon0 204-14 ii libudev1 204-14 ii libvirt0 1.2.4-3 ii libxen-4.3 4.3.0-3+b1 ii libxenstore3.0 4.3.0-3+b1 ii libxml2 2.9.1+dfsg1-4 ii libyajl2 2.1.0-1 ii logrotate3.8.7-1 Versions of packages libvirt-bin recommends: ii bridge-utils1.5-9 ii dmidecode 2.12-3 ii dnsmasq-base2.71-1 ii ebtables2.0.10.4-3 ii iproute 1:3.15.0-2 ii iptables1.4.21-2 ii libxml2-utils 2.9.1+dfsg1-4 ii netcat-openbsd 1.105-7 ii parted 2.3-20 ii pm-utils1.4.1-15 ii qemu2.0.0+dfsg-6+b1 ii qemu-kvm2.0.0+dfsg-6+b1 Versions of packages libvirt-bin suggests: pn apparmor none pn auditd none ii policykit-1 0.105-6 pn radvdnone ii systemd 204-14 pn systemtapnone -- Configuration Files: /etc/default/libvirt-guests changed [not included] /etc/libvirt/qemu.conf [Errno 13] Permission denied: u'/etc/libvirt/qemu.conf' -- no debconf
Bug#756164: gnome-control-center: Display settings inoperable for dual monitors
Package: gnome-control-center Version: 1:3.8.3-7+b2 Severity: normal The display settings applet fails to actually be usuable with dual monitors. Click on the monitors fails to select that monitor to be operated on (i.e. clicks appear to have not effect). Also one cannot drag the monitor to refect e.g. differences in height or the monitor detected as secondary actually being on the left instead of right of the one detected as primary (to all appears the mouse actually has not effect). If one selects and deselects mirror mode one is able to select the secondary monitor, but if one changes the resolution of the secondary monitor and click apply (in my case the secondary monitor is larger and to the left of the primary) the follow messages pops up: Failed to apply configuration: %s GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such method 'ApplyConfiguration' -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-control-center depends on: ii accountsservice0.6.37-2 ii apg2.2.3.dfsg.1-2 ii colord 1.2.1-1 ii desktop-file-utils 0.22-1 ii gnome-control-center-data 1:3.8.3-7 ii gnome-desktop3-data3.12.2-2 ii gnome-icon-theme 3.12.0-1 ii gnome-icon-theme-symbolic 3.12.0-1 ii gnome-menus3.8.0-2 ii gnome-settings-daemon 3.12.2-1 ii gsettings-desktop-schemas 3.12.2-1 ii libaccountsservice00.6.37-2 ii libatk1.0-02.12.0-1 ii libc6 2.19-7 ii libcairo2 1.12.16-2 ii libcanberra-gtk3-0 0.30-2 ii libcanberra0 0.30-2 ii libcheese-gtk233.12.2-1 ii libcheese7 3.12.2-1 ii libclutter-gtk-1.0-0 1.5.2-2 ii libcolord-gtk1 0.1.25-1.1+b1 ii libcolord2 1.2.1-1 ii libcups2 1.7.4-1 ii libdbus-glib-1-2 0.102-1 ii libfontconfig1 2.11.0-5 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libgl1-mesa-glx [libgl1] 10.2.4-1 ii libglib2.0-0 2.40.0-3 ii libgnome-bluetooth11 3.8.1-3 ii libgnome-desktop-3-7 3.8.4-2 ii libgoa-1.0-0b 3.12.2-1 ii libgoa-backend-1.0-1 3.12.2-1 ii libgtk-3-0 3.12.2-1+b1 ii libgtop2-7 2.28.5-2 ii libibus-1.0-5 1.5.7-1 ii libkrb5-3 1.12.1+dfsg-5 ii libmm-glib01.2.0-1 ii libnm-glib-vpn10.9.10.0-1 ii libnm-glib40.9.10.0-1 ii libnm-gtk0 0.9.10.0-2 ii libnm-util20.9.10.0-1 ii libpango-1.0-0 1.36.3-1 ii libpangocairo-1.0-01.36.3-1 ii libpolkit-gobject-1-0 0.105-6.1 ii libpulse-mainloop-glib05.0-2 ii libpulse0 5.0-2 ii libpwquality1 1.2.3-1 ii libsmbclient 2:4.1.9+dfsg-1 ii libsocialweb-client2 0.25.20-6 ii libupower-glib10.9.23-2+b2 ii libwacom2 0.8-1 ii libx11-6 2:1.6.2-2 ii libxi6 2:1.7.2-1 ii libxml22.9.1+dfsg1-4 Versions of packages gnome-control-center recommends: ii cups-pk-helper 0.2.5-2 ii gkbd-capplet 3.6.0-1 ii gnome-online-accounts 3.12.2-1 ii gnome-user-guide 3.12.2-1 ii gnome-user-share 3.8.3-1 ii iso-codes 3.55-1 ii mesa-utils 8.2.0-1 ii mousetweaks3.12.0-1 ii network-manager-gnome 0.9.10.0-2 ii ntp1:4.2.6.p5+dfsg-3 ii policykit-1-gnome 0.105-2 ii rygel 0.22.2-2 ii rygel-tracker 0.22.2-2 ii system-config-printer 1.4.3-4 Versions of packages gnome-control-center suggests: ii gnome-screensaver3.6.1-1+b1 ii gstreamer1.0-pulseaudio 1.4.0-1 ii libcanberra-gtk-module 0.30-2 ii libcanberra-gtk3-module 0.30-2 ii x11-xserver-utils7.7+3 -- 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#755750: empathy: Missing menu in 'Contacts List'; incorrect application of Unity-specific change?
Package: empathy Version: 3.12.4-1 Severity: normal There is no way to perform actions previously performed from the 'Contact List' menu because the top menu bar no longer displays. This is perhaps because of incorrect application of changes from Ubuntu for Unity (where the menus appear in the top bar instead of in individual application menus) or a missing dependency (I've seen some mention of a notification or messaging icon that should be in the status bar that I do not have). -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages empathy depends on: ii dbus-x11 1.8.6-1 ii dconf-gsettings-backend [gsettings-backend] 0.20.0-2 ii empathy-common 3.12.4-1 ii geoclue-2.0 2.1.8-1 ii gnome-icon-theme 3.12.0-1 ii gsettings-desktop-schemas3.8.2-2 ii gstreamer1.0-pulseaudio 1.2.4-1 ii libc62.19-7 ii libcairo21.12.16-2 ii libcanberra-gtk3-0 0.30-2 ii libcanberra0 0.30-2 ii libchamplain-0.12-0 0.12.8-1 ii libchamplain-gtk-0.12-0 0.12.8-1 ii libcheese-gtk23 3.12.2-1 ii libclutter-1.0-0 1.18.2-2 ii libclutter-gst-2.0-0 2.0.12-1 ii libclutter-gtk-1.0-0 1.5.2-2 ii libcogl-path20 1.18.2-1 ii libcogl201.18.2-1 ii libdbus-glib-1-2 0.102-1 ii libenchant1c2a 1.6.0-10 ii libfarstream-0.2-2 0.2.3-3 ii libfolks-telepathy25 0.9.7.1-1 ii libfolks25 0.9.7.1-1 ii libgcr-base-3-1 3.12.2-1 ii libgcr-ui-3-13.12.2-1 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libgee-0.8-2 0.10.5-1 ii libgeocode-glib0 3.12.2-1 ii libglib2.0-0 2.40.0-3 ii libgnutls26 2.12.23-17 ii libgoa-1.0-0b3.12.2-1 ii libgstreamer-plugins-base1.0-0 1.2.4-1 ii libgstreamer1.0-01.2.4-1 ii libgtk-3-0 3.12.2-1+b1 ii libgudev-1.0-0 208-6 ii libmission-control-plugins0 1:5.16.2-1 ii libnotify4 0.7.6-2 ii libpango-1.0-0 1.36.3-1 ii libpulse-mainloop-glib0 5.0-2 ii libpulse05.0-2 ii libsecret-1-00.18-1 ii libsoup2.4-1 2.46.0-2 ii libtelepathy-farstream3 0.6.1-1 ii libtelepathy-glib0 0.24.0-1 ii libtelepathy-logger3 0.8.0-3 ii libwebkitgtk-3.0-0 2.4.4-2 ii libx11-6 2:1.6.2-2 ii libxml2 2.9.1+dfsg1-4 ii telepathy-logger 0.8.0-3 ii telepathy-mission-control-5 1:5.16.2-1 Versions of packages empathy recommends: ii gvfs-backends1.20.2-1 ii sound-theme-freedesktop 0.8-1 ii telepathy-gabble 0.18.2-1 ii telepathy-haze 0.8.0-1 ii telepathy-salut 0.8.1-2 Versions of packages empathy suggests: ii telepathy-idle 0.2.0-1 ii vino3.12.0-2 Versions of packages empathy is related to: ii telepathy-gabble [telepathy-connection-manager] 0.18.2-1 ii telepathy-haze [telepathy-connection-manager]0.8.0-1 ii telepathy-idle [telepathy-connection-manager]0.2.0-1 ii telepathy-rakia [telepathy-connection-manager] 0.8.0-2 ii telepathy-salut [telepathy-connection-manager] 0.8.1-2 -- 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#755763: network-manager: Keeps disconnection from wifi and failed to reconnect
Package: network-manager Version: 0.9.10.0-1 Severity: normal On a laptop that was working fine before Jessie and a wifi network for which other devices have no issues, network manager keeps dropping the wifi connectin AND does not automatically reconnect despite the wifi network being configured as 'Connect automatically' and being the only wifi network configured for auto-connection. There are two wired (NM-managed) bridges but there are currently no wires connected to either the onboard PCI ethernet nor the USB ethernet. The USB ethernet's bridge is manually configured, the other bridge is DHCP. There is also a Bluetooth adaptor that is enabled but not set to connect. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages network-manager depends on: ii adduser3.113+nmu3 ii dbus 1.8.6-1 ii init-system-helpers1.19 ii isc-dhcp-client4.3.0+dfsg-1 ii libc6 2.19-7 ii libdbus-1-31.8.6-1 ii libdbus-glib-1-2 0.102-1 ii libgcrypt111.5.3-4 ii libglib2.0-0 2.40.0-3 ii libgnutls-deb0-28 3.2.15-3 ii libgudev-1.0-0 208-6 ii libmm-glib01.2.0-1 ii libndp01.3-1 ii libnewt0.520.52.17-1 ii libnl-3-2003.2.24-2 ii libnl-genl-3-200 3.2.24-2 ii libnl-route-3-200 3.2.24-2 ii libnm-glib40.9.10.0-1 ii libnm-util20.9.10.0-1 ii libpam-systemd 208-6 ii libpolkit-gobject-1-0 0.105-6 ii libreadline6 6.3-6 ii libsoup2.4-1 2.46.0-2 ii libsystemd-daemon0 208-6 ii libsystemd-login0 208-6 ii libuuid1 2.20.1-5.8 ii lsb-base 4.1+Debian13 ii policykit-10.105-6 ii udev 208-6 ii wpasupplicant 1.1-1 Versions of packages network-manager recommends: ii crda 1.1.2-1 ii dnsmasq-base 2.71-1 ii iptables 1.4.21-2 ii modemmanager 1.2.0-1 ii ppp 2.4.6-2 Versions of packages network-manager suggests: ii avahi-autoipd 0.6.31-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
