Bug#708831: upgrade-reports: [sid-sid] left system barely unusable (manually fixed with dpkg --install)
On Sun, May 19, 2013 at 21:10:50 +0200, Matthias Klose wrote: so for now, I'm adding the libc6 dependency as a pre-dependency in python2.7-minimal, like perl-base is doing. perl-base is Essential, meaning it has to work when only unpacked. Not so for python2.7. I think python-defaults should be modified to make prerm scripts not call /usr/bin/python (which I guess means rewriting /usr/bin/pyclean in shell, perl or C). And debconf in wheezy should be updated to not use dh_python2's scripts... Cheers, Julien signature.asc Description: Digital signature
Bug#708831: upgrade-reports: [sid-sid] left system barely unusable (manually fixed with dpkg --install)
Hi, The dpkg/status file before the upgrade could be helpful for reproducing. You can (hopefully) find it in /var/backup/ Helpful config options (I case someone wants to try) -o dir::state::status=./dpkg/status -o debug::pkgdpkgpm=true # displays dpkg calls rather than executing them -o debug::pkgorderlist=true # first stage order choices -o debug::pkgpackagemanager=true # second (and final) stage order choices On Sun, May 19, 2013 at 3:50 PM, Aurelien Jarno aurel...@aurel32.net wrote: /usr/bin/python: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found (required by /usr/bin/python) /usr/bin/python: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.16' not found (required by /usr/bin/python) dpkg: warning: subprocess old pre-removal script returned error exit status 1 While APT usually avoids it, its actually fine to have dependencies not satisfied for half-installed packages and prerm scripts do only give you the guarantee that your dependencies will be at least half-installed. In the case of debconf, we don't even have a dependency on python, so its even more fine to choose this order for unpack. I haven't had the time yet to debug why APT is choosing this route (and as said, dpkg/status file would help), but while this might not be ideal its not a bug in APT. This smells more like a bug in dh_python2 which adds this prerm code which assumes that pyclean can be executed even if it isn't configured (aka that it behaves like an essential application), but I am not in the mood for bug-ping-pong so just CC'ed python maintainers for now, so they can have a look and comment on it while we will see whats up with APT to decide on this route (did I mention that a dpkg/status file would help? ;) ). Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708831: upgrade-reports: [sid-sid] left system barely unusable (manually fixed with dpkg --install)
On Sun, May 19, 2013 at 05:15:35PM +0200, David Kalnischkies wrote: Hi, The dpkg/status file before the upgrade could be helpful for reproducing. You can (hopefully) find it in /var/backup/ Helpful config options (I case someone wants to try) -o dir::state::status=./dpkg/status -o debug::pkgdpkgpm=true # displays dpkg calls rather than executing them -o debug::pkgorderlist=true # first stage order choices -o debug::pkgpackagemanager=true # second (and final) stage order choices On Sun, May 19, 2013 at 3:50 PM, Aurelien Jarno aurel...@aurel32.net wrote: /usr/bin/python: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found (required by /usr/bin/python) /usr/bin/python: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.16' not found (required by /usr/bin/python) dpkg: warning: subprocess old pre-removal script returned error exit status 1 While APT usually avoids it, its actually fine to have dependencies not satisfied for half-installed packages and prerm scripts do only give you the guarantee that your dependencies will be at least half-installed. In the case of debconf, we don't even have a dependency on python, so its even more fine to choose this order for unpack. I don't think that debconf is relevant there. The problem is that the new python needs a new libc6 package, and thus if it is unpacked before libc6, it doesn't work anymore. This means that every python script on the system will fail (being called from a maintainer script or not), until the dependency is satisfied again. I haven't had the time yet to debug why APT is choosing this route (and as said, dpkg/status file would help), but while this might not be ideal its not a bug in APT. I really thought if a package A depends on package B, B has to be unpacked before A is unpacked. Otherwise it means that for example if the package dash starts to depend on a new libc6 version, while it is unpacked before this new version, all maintainer scripts written in shell will fail. This smells more like a bug in dh_python2 which adds this prerm code which assumes that pyclean can be executed even if it isn't configured (aka that it behaves like an essential application), but I am not in the mood for bug-ping-pong so just CC'ed python maintainers for now, so they can have a look and comment on it while we will see whats up with APT to decide on this route (did I mention that a dpkg/status file would help? ;) ). The problem there is that /usr/bin/python exists is not a dead symlink. Just that it fails to be executed. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708831: upgrade-reports: [sid-sid] left system barely unusable (manually fixed with dpkg --install)
reassign 708831 python retitle 708831 dh_python should not assume that pyclean works thanks On Sun, May 19, 2013 at 05:34:31PM +0200, Aurelien Jarno wrote: On Sun, May 19, 2013 at 05:15:35PM +0200, David Kalnischkies wrote: Hi, The dpkg/status file before the upgrade could be helpful for reproducing. You can (hopefully) find it in /var/backup/ Helpful config options (I case someone wants to try) -o dir::state::status=./dpkg/status -o debug::pkgdpkgpm=true # displays dpkg calls rather than executing them -o debug::pkgorderlist=true # first stage order choices -o debug::pkgpackagemanager=true # second (and final) stage order choices On Sun, May 19, 2013 at 3:50 PM, Aurelien Jarno aurel...@aurel32.net wrote: /usr/bin/python: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found (required by /usr/bin/python) /usr/bin/python: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.16' not found (required by /usr/bin/python) dpkg: warning: subprocess old pre-removal script returned error exit status 1 While APT usually avoids it, its actually fine to have dependencies not satisfied for half-installed packages and prerm scripts do only give you the guarantee that your dependencies will be at least half-installed. In the case of debconf, we don't even have a dependency on python, so its even more fine to choose this order for unpack. I don't think that debconf is relevant there. The problem is that the new python needs a new libc6 package, and thus if it is unpacked before libc6, it doesn't work anymore. This means that every python script on the system will fail (being called from a maintainer script or not), until the dependency is satisfied again. I haven't had the time yet to debug why APT is choosing this route (and as said, dpkg/status file would help), but while this might not be ideal its not a bug in APT. I really thought if a package A depends on package B, B has to be unpacked before A is unpacked. Otherwise it means that for example if the package dash starts to depend on a new libc6 version, while it is unpacked before this new version, all maintainer scripts written in shell will fail. So it seems that packages from the essential set have a pre-depends exactly for that. This means the bug is in dh_python, which should not assume that pyclean works, even if the script exists. Reassigning. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708831: upgrade-reports: [sid-sid] left system barely unusable (manually fixed with dpkg --install)
On Sun, May 19, 2013 at 5:15 PM, David Kalnischkies kalnischkies+deb...@gmail.com wrote: I haven't had the time yet to debug why APT is choosing this route (and as said, dpkg/status file would help), but while this might not be ideal its not a bug in APT. Should I simply attach the whole file, grep something out, or send it to you off-list? -- Richard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708831: upgrade-reports: [sid-sid] left system barely unusable (manually fixed with dpkg --install)
On Sun, May 19, 2013 at 5:34 PM, Aurelien Jarno aurel...@aurel32.net wrote: I don't think that debconf is relevant there. The problem is that the new python needs a new libc6 package, and thus if it is unpacked before libc6, it doesn't work anymore. This means that every python script on the system will fail (being called from a maintainer script or not), until the dependency is satisfied again. That's basically what I experienced, as well. vim (compiled with Python support on Debian) didn't work any more, I had to fall back on nano. I am just glad that dpkg and apt don't depend on Python ;) Richard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708831: upgrade-reports: [sid-sid] left system barely unusable (manually fixed with dpkg --install)
On Sun, May 19, 2013 at 7:01 PM, Richard Hartmann richih.mailingl...@gmail.com wrote: Should I simply attach the whole file, grep something out, or send it to you off-list? Sent off-list, if anyone else needs it poke me. -- Richard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708831: upgrade-reports: [sid-sid] left system barely unusable (manually fixed with dpkg --install)
Control: reassign -1 python2.7-minimal Am 19.05.2013 17:15, schrieb David Kalnischkies: Hi, The dpkg/status file before the upgrade could be helpful for reproducing. You can (hopefully) find it in /var/backup/ Helpful config options (I case someone wants to try) -o dir::state::status=./dpkg/status -o debug::pkgdpkgpm=true # displays dpkg calls rather than executing them -o debug::pkgorderlist=true # first stage order choices -o debug::pkgpackagemanager=true # second (and final) stage order choices On Sun, May 19, 2013 at 3:50 PM, Aurelien Jarno aurel...@aurel32.net wrote: /usr/bin/python: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found (required by /usr/bin/python) /usr/bin/python: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.16' not found (required by /usr/bin/python) dpkg: warning: subprocess old pre-removal script returned error exit status 1 While APT usually avoids it, its actually fine to have dependencies not satisfied for half-installed packages and prerm scripts do only give you the guarantee that your dependencies will be at least half-installed. well, only seen on i386, and apparently libc6-i686 is installed. Now why aren't the new libc6 packages unpacked first? I would assume to see more reports for this upgrade path. In the case of debconf, we don't even have a dependency on python, so its even more fine to choose this order for unpack. I haven't had the time yet to debug why APT is choosing this route (and as said, dpkg/status file would help), but while this might not be ideal its not a bug in APT. This smells more like a bug in dh_python2 which adds this prerm code which assumes that pyclean can be executed even if it isn't configured (aka that it behaves like an essential application), but I am not in the mood for bug-ping-pong so just CC'ed python maintainers for now, so they can have a look and comment on it while we will see whats up with APT to decide on this route (did I mention that a dpkg/status file would help? ;) ). so for now, I'm adding the libc6 dependency as a pre-dependency in python2.7-minimal, like perl-base is doing. Matthias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708831: upgrade-reports: [sid-sid] left system barely unusable (manually fixed with dpkg --install)
On Sun, May 19, 2013 at 9:10 PM, Matthias Klose d...@debian.org wrote: Am 19.05.2013 17:15, schrieb David Kalnischkies: The dpkg/status file before the upgrade could be helpful for reproducing. You can (hopefully) find it in /var/backup/ Helpful config options (I case someone wants to try) -o dir::state::status=./dpkg/status -o debug::pkgdpkgpm=true # displays dpkg calls rather than executing them -o debug::pkgorderlist=true # first stage order choices -o debug::pkgpackagemanager=true # second (and final) stage order choices On Sun, May 19, 2013 at 3:50 PM, Aurelien Jarno aurel...@aurel32.net wrote: /usr/bin/python: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found (required by /usr/bin/python) /usr/bin/python: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.16' not found (required by /usr/bin/python) dpkg: warning: subprocess old pre-removal script returned error exit status 1 While APT usually avoids it, its actually fine to have dependencies not satisfied for half-installed packages and prerm scripts do only give you the guarantee that your dependencies will be at least half-installed. well, only seen on i386, and apparently libc6-i686 is installed. Now why aren't the new libc6 packages unpacked first? I would assume to see more reports for this upgrade path. Its caused by the remove of libescpr1 (src:epson-inkjet-printer-escpr) in Richards case, which ignoring the ubuntu-popcon spike has a 25.000 score, so not installed by everyone and even if you have it installed you might have upgraded your libc6 earlier (as the libescpr1 drop is just two days old) or APT chooses a different package to handle first [removes are done relatively early compared to other actions]. I guess there are other situations where you can reach this problem, but you need to be a bit lucky. Describing exactly whats going on is not only offtopic, but also complicated, so lets just say that APT is choosing here a bad way of handling things, but while its not a good idea its a valid one. (people wanting to explore the misery can follow the word DepRemove) This smells more like a bug in dh_python2 which adds this prerm code which assumes that pyclean can be executed even if it isn't configured (aka that it behaves like an essential application), but I am not in the mood for bug-ping-pong so just CC'ed python maintainers for now, so they can have a look and comment on it while we will see whats up with APT to decide on this route (did I mention that a dpkg/status file would help? ;) ). so for now, I'm adding the libc6 dependency as a pre-dependency in python2.7-minimal, like perl-base is doing. While this should work to fix this exact bug, its still papering over the problem indicated by the bug: python isn't essential, so pre* scripts can't assume that python is working. Usually you are lucky enough that it works by accident, but bugs like this one show that you can very well be in a system state which is allowed by policy but python isn't working. (assuming the chosen order is better, e.g. loops can trigger this) To really fix this you have to ensure that a) python always works even in half-installed state OR b) all packages using dh_python2 prerm snippets pre-depend on python OR c) cleaning is moved to post* scripts and just depend on python OR d) the dh_python2 prerm snippet works without a configured python by using shell/perl/$essential tools only. Same goes for python3 and dh_python3. I am CCing the debconf maintainers btw as their prerm script looks really strange with 3 different ways of cleaning up pyc and pyo files – one handwritten shell and two added by dh_python2 (one requiring python and a fallback in shell). Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708831: upgrade-reports: [sid-sid] left system barely unusable (manually fixed with dpkg --install)
Package: upgrade-reports Severity: grave Justification: renders package unusable Broken Python upgrade left me without working debconf. Full log at http://paste.debian.net/5060/ Fixed by manually installing libc6 packages and locales*.deb Fetched 520 MB in 21min 17s (407 kB/s) Reading changelogs... Done apt-listchanges: Mailing root: apt-listchanges: news for rockhopper Extracting templates from packages: 100% Preconfiguring packages ... (Reading database ... 212752 files and directories currently installed.) Preparing to replace libpython2.7 2.7.3-8 (using /libpython2.7_2.7.5-2_i386.deb) ... Unpacking replacement libpython2.7 ... Preparing to replace python2.7 2.7.3-8 (using /python2.7_2.7.5-2_i386.deb) ... Unpacking replacement python2.7 ... Preparing to replace python2.7-minimal 2.7.3-8 (using /python2.7-minimal_2.7.5-2_i386.deb) ... Unpacking replacement python2.7-minimal ... dpkg: warning: unable to delete old directory '/etc/python2.7': Directory not empty Selecting previously unselected package libpython2.7-minimal. Unpacking libpython2.7-minimal (from /libpython2.7-minimal_2.7.5-2_i386.deb) ... Preparing to replace mime-support 3.52-2 (using /mime-support_3.54_all.deb) ... Unpacking replacement mime-support ... Preparing to replace debconf 1.5.49 (using .../debconf_1.5.50_all.deb) /usr/bin/python: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found (required by /usr/bin/python) /usr/bin/python: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.16' not found (required by /usr/bin/python) dpkg: warning: subprocess old pre-removal script returned error exit status 1 dpkg: trying script from the new package instead ... /usr/bin/python: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found (required by /usr/bin/python) /usr/bin/python: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.16' not found (required by /usr/bin/python) dpkg: error processing /var/cache/apt/archives/debconf_1.5.50_all.deb (--unpack): subprocess new pre-removal script returned error exit status 1 /usr/bin/python: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found (required by /usr/bin/python) /usr/bin/python: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.16' not found (required by /usr/bin/python) dpkg: error while cleaning up: subprocess installed post-installation script returned error exit status 1 Processing triggers for man-db ... Processing triggers for desktop-file-utils ... Errors were encountered while processing: /var/cache/apt/archives/debconf_1.5.50_all.deb -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.7-trunk-686-pae (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
