Bug#769273: bsdutils: Dependency on libsystemd0 violates policy
Package: bsdutils Version: 1:2.25.2-2 Severity: serious Justification: Policy 2.5 Dear Maintainer, libsystemd0 dependancy violates constraint at the end of section 2.5 of the policy manual that requires packages not depend on packages with lower priority.. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages bsdutils depends on: ii libc62.19-13 ii libsystemd0 215-5+b1 Versions of packages bsdutils recommends: ii bsdmainutils 9.0.6 bsdutils suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769273: bsdutils: Dependency on libsystemd0 violates policy
On 12/11/14 14:29, Michael Biebl wrote: Am 12.11.2014 um 15:04 schrieb Andreas Henriksson: Hello Tim Wootton, release-team, et.al.! Thanks for your bug report. On Wed, Nov 12, 2014 at 11:00:16AM +, Tim Wootton wrote: Package: bsdutils Version: 1:2.25.2-2 Severity: serious Justification: Policy 2.5 Dear Maintainer, libsystemd0 dependancy violates constraint at the end of section 2.5 of the policy manual that requires packages not depend on packages with lower priority. This (general) problem has been discussed (several times?) on debian-devel already and as far as I remember and understood it was that raising the priority of the relevant systemd binary packages could be done but it did not solve any *practical* problem. Instead it seemed easier to just fix policy. I guess that's where everyone lost interest Indeed, it doesn't fix any actual problem, but raising priority of library and helper packages actually creates problems. Let's take rsyslog as an example, which is priority important, so raising all the library dependencies to = important now means, if I debootstrap a chroot and want to exclude rsyslog, I have to exclude all dependend libraries as well. Or if I remove rsyslog (e.g. because I switched to another syslogger or no syslogger), I have to manually uninstall the unused libraries. Please, let's not continue doing this non-sense and fix policy. or just build without the dependency in the 1st place like it used to be. After all it's not like it adds anything that's essential. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729088: printer-applet crashes on launch
Package: printer-applet Version: 4:4.8.4-1 Severity: grave Justification: renders package unusable Dear Maintainer, printer-applet crashes on launch for all users on both systems I've tested on. Trace from command-line execution: $ printer-applet KCrash: Application 'printer-applet' crashing... KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit sock_file=/home/my_username/.kde/socket-my_hostname/kdeinit4__0 $ Problem appears to be a SIGSEGV while attempting to write to an already closed and previously O_RDONLY file descriptor for the user's .kde/share/config/kdeglobals -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages printer-applet depends on: ii python 2.7.5-5 ii python-cups 1.9.63-1 ii python-kde4 4:4.10.5-1+b1 ii python-qt4-dbus 4.10.3-2 Versions of packages printer-applet recommends: pn hal-cups-utils none pn system-config-printer-kde none printer-applet suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#309321: approx: Approx stops processing TCP rx queue
Thanks Eric, As you predicted the 104 Connection Reset errors seem to have gone with the pipelining workaround. The original problem however persists, but at least one possible culprit has been eliminated. Tim # CONFIDENTIALITY NOTICE The information contained in this email is confidential and may also be privileged. It is intended to be for the exclusive use of the addressee(s) and access to it by any other person is unauthorised. If you are not the addressee please note that you must not distribute, copy, circulate or in any other way use or rely on the information contained in this email. If you have received this email in error please notify us by phone (+44 (0)870 445 1445) and then destroy the email and any copies of it. ##
Bug#309321: approx: Approx stops processing TCP rx queue
Hi Eric, Yep, no problem: Just to help here's a diagram of the initial setup +-+ +--++--+ +---+ |uk.debian.org||server01 |---|server02 ||client01 | +-+ |(approx ||(approx | |(client of | +---+ |client of ||client of | |server02) | |security.debian.org|--|localhost)||localhost)| | | +---+ +--++--+ +---+ I should also point out that server02 is shared by a number of other clients, not just client01. Is it possible that approx somehow marks a file as pending from upstream, when in fact the download has failed, or been interrupted? It could then permanently believe the file is not yet available, when it never will be. Syslog on server02 only thing that looks odd is a few utimes: Operation not permitted on Packages.gz files When I checked the perms the file is rw for user approx which seems right to me. Can fail at any point, sometimes in the download of packages files, sometimes in the fetch of the package.dpkg files. It may not be related, but even when things are working fairly ok, I do seem to get quite a few Error reading from server - read (104 Connection reset by peer) messages in aptitude/apt-get which I don't get if I switch back to apt-proxy. Each time it leaves a bunch of connections to it's upstream in the CLOSE_WAIT state. There remains, however only one connection in the ESTABLISHED state with a high value rx q. If I then repeat the run it will be all or most of the same downloads that fail. If I connect apt directly to the upstream, and the upstream is the remote debian mirror, that always works fine. Otherwise the same thing happens but not quite so regularly, I guess the problem can occur in any of the approx instances in the chain. For each instance you take out of the chain the lower the chance of bumping into a problem. Different remote? - see above, the debian mirror never fails. Wget seems to work ok on the files that are getting Error reading from server - read (104 Connection reset by peer) from aptitude/apt-get which is interesting. Hope this helps rather than confuses the issue, anything else you'd like me to try just let me know. Cheers, Tim # CONFIDENTIALITY NOTICE The information contained in this email is confidential and may also be privileged. It is intended to be for the exclusive use of the addressee(s) and access to it by any other person is unauthorised. If you are not the addressee please note that you must not distribute, copy, circulate or in any other way use or rely on the information contained in this email. If you have received this email in error please notify us by phone (+44 (0)870 445 1445) and then destroy the email and any copies of it. ##
Bug#309321: approx: Approx stops processing TCP rx queue
Hi Eric, I may have a clue on reproducing the problem: Try aborting apt-get or aptitude midway through a download and then re-try. This is seems to trigger the problem here. Tim # CONFIDENTIALITY NOTICE The information contained in this email is confidential and may also be privileged. It is intended to be for the exclusive use of the addressee(s) and access to it by any other person is unauthorised. If you are not the addressee please note that you must not distribute, copy, circulate or in any other way use or rely on the information contained in this email. If you have received this email in error please notify us by phone (+44 (0)870 445 1445) and then destroy the email and any copies of it. ##
Bug#309321: approx: Approx stops processing TCP rx queue
Package: approx Version: 1.15 Severity: grave Justification: renders package unusable Aprrox appears to hang, netstat shows that it's stoped emptying data from the rx queue: Proto Recv-Q Send-Q Local Address Foreign Address State tcp65664 0 lonspx01:35773 open.hands.com:www ESTABLISHED tcpdump shows only keepalives on the tcp connection - no data flow (assume window maxed out) Restarting approx will clear the condition, but it will reccur soon afterwards. I've left it overnight in this condition, but it dosn't recover. I'm not sure if it's relevant but the downstream client is another instance of approx with apt on that machine connecting to localhost. debug trace: # approx -f Config file: /etc/approx/approx.conf Port: Cache: /var/cache/approx Interval: 30 minutes Debug: true Connection from 10.97.16.254 Request /debian/dists/sarge/main/binary-i386/Packages.gz if-modified-since: Thu, 12 May 2005 10:28:46 GMT pragma: no-cache host: lonspx01: accept: */* http://ftp.uk.debian.org/debian/dists/sarge/main/binary-i386/Packages.gz HTTP/1.1 200 OK Date: Mon, 16 May 2005 10:33:02 GMT Server: Apache/1.3.33 (Debian GNU/Linux) PHP/4.3.10-2 mod_ssl/2.8.22 OpenSSL/0.9.7d Last-Modified: Sun, 15 May 2005 19:05:00 GMT ETag: 88445-334602-42879d5c Accept-Ranges: bytes Content-Length: 3360258 Content-Type: application/binary Content-Encoding: x-gzip HTTP proxy response: 200 Date: Mon, 16 May 2005 10:33:02 GMT Server: Apache/1.3.33 (Debian GNU/Linux) PHP/4.3.10-2 mod_ssl/2.8.22 OpenSSL/0.9.7d Last-Modified: Sun, 15 May 2005 19:05:00 GMT Content-Length: 3360258 Content-Type: application/binary Content-Encoding: x-gzip open cache debian/dists/sarge/main/binary-i386/Packages.gz approx appears to hang at this point approx.conf: # The following are the defaults, so there is no need # to uncomment them unless you want a different value. #port interval30 debug true # Here are some examples of remote repository mappings. debian http://ftp.uk.debian.org/debian non-US http://ftp.uk.debian.org/debian-non-US securityhttp://security.debian.org/debian-security -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Versions of packages approx depends on: ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libcurl37.13.2-2 Multi-protocol file transfer libra ii libidn110.5.13-1.0 GNU libidn library, implementation ii libpcre34.5-1.1 Perl 5 Compatible Regular Expressi ii libssl0.9.7 0.9.7e-3 SSL shared libraries ii wget1.9.1-11 retrieves files from the web ii zlib1g 1:1.2.2-4compression library - runtime -- no debconf information # CONFIDENTIALITY NOTICE The information contained in this email is confidential and may also be privileged. It is intended to be for the exclusive use of the addressee(s) and access to it by any other person is unauthorised. If you are not the addressee please note that you must not distribute, copy, circulate or in any other way use or rely on the information contained in this email. If you have received this email in error please notify us by phone (+44 (0)870 445 1445) and then destroy the email and any copies of it. ## -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
